ANÁLISE DE SISTEMAS II

1. INTRODUÇÃO

A engenharia de software é a ciência e a arte de com economia, em tempo útil e de

forma elegante, especificar, projetar, implementar e manter atualizados e corretos,
programas, documentação e procedimentos operacionais para sistemas computacionais de
utilidade para a humanidade (Alan Brown, Anthony Earl e John McDermid). A
engenharia de software é definida, também, como "aplicação prática do conhecimento
científico no projeto e construção de programas e da documentação requerida para
desenvolver, operar e manter esses programas" (Boehm 80).
O estudo e sistematização do processo de desenvolvimento de software requer que se
conheçam as características do produto desejado e da tecnologia que será utilizada em seu
desenvolvimento.
Este processo é orientado pelo modelo de ciclo de vida, cujas funções primárias são a
de determinar as fases e a ordem das atividades envolvidas no desenvolvimento e o
estabelecimento de critérios para a transição das fases. Estes critérios de transição
incluem a determinação de diretrizes para o começo e a finalização das fases.
Os métodos, por sua vez, podem ser definidos como: "prescrições explícitas para a
realização de uma atividade ou conjunto de atividades do modelo de ciclo de vida"
[Charette 86]. Eles devem refletir um conjunto de diretivas para a aplicação sistemática
de técnicas e instrumentos. As técnicas podem ser definidas como um conjunto de
princípios para execução de uma tarefa específica do processo de desenvolvimento do
software. Os instrumentos tornam possível o uso de métodos e técnicas (Rocha 87),
(Crispim 92) .
Esta apostila abordará o processo de desenvolvimento de software em geral, através da
descrição de alguns modelos de ciclo de vida e de alguns métodos de construção de
sistemas.

2. MODELOS DE CICLO DE VIDA

Modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento de

sistemas e as atividades a serem realizadas em cada etapa. A definição dessas etapas e
atividades possibilitam prover marcos e pontos de controle para avaliação da qualidade e
gerência do projeto (Park 91).

Vera Werneck 4/20/2009 1

 ANÁLISE DE SISTEMAS II

O estudo do processo de desenvolvimento provocou o surgimento de várias propostas

de ciclo de vida que incluem desde o simples modelo artesanal de codificar e consertar
(Connors 92), (Pressman 92) até o modelo espiral (Boehm 88).
Inicialmente, o desenvolvimento de software era algo feito em pequena escala com
equipes pequenas ou, até mesmo, apenas com esforço individual. Neste momento, a
ênfase do processo estava na etapa de programação. Neste escopo o desenvolvimento de
software caracterizou-se pelo codificar e consertar, também chamado de
desenvolvimento artesanal ou ad-hoc, que consiste em se partir diretamente para a
codificação, seguida de correção. Esse ciclo é repetido até se completar o projeto
(Connors 92).
O aumento da complexidade e tamanho dos sistemas gerou algumas propostas de ciclo
de vida levando em conta o desenvolvimento de sistemas em grande escala envolvendo
grandes equipes. Isto acarretou uma mudança de enfoque com ênfase no desenvolvimento
de sistemas e não apenas de programas.
A primeira proposta deu origem ao modelo tradicional ou cascata. Nesse modelo as
fases são executadas sistematicamente de forma seqüencial como ilustrado na figura 1 e
normalmente tem as seguintes fases: Análise, Projeto, Construção, Avaliação e
Manutenção (Rocha 87), (Davis 90), (Ghezzi 91), (Pressman 92).

Análise

Projeto

Construção

Avaliação

Manutenção

Figura 1 - Modelo de Ciclo de Vida Clássico ou Cascata

Na fase de análise, também denominada análise de requisitos, são estabelecidos os

Vera Werneck 4/20/2009 2

 ANÁLISE DE SISTEMAS II

requisitos do sistema a ser desenvolvido. Nesta fase, o engenheiro de software necessita

compreender o domínio do problema no qual está trabalhando. Os requisitos e a
modelagem conceitual do sistema são documentados e, posteriormente, revisados pelo
usuário.
A análise de requisitos começa ao se reconhecer que um problema necessita da
tecnologia de informação como solução ou ao surgir uma idéia de um novo negócio ou de
um novo sistema de informação na empresa. Esta fase é concluiída ao se ter uma
descrição completa do comportamento do software a ser construído documentado na
Especificação de Requisitos. Nesta fase são realizadas as atividades de análise do
problema, descrição do produto e avaliação da especificação do produto.
O projeto do software é, na realidade, um processo de múltiplos passos que reforça
quatro atributos importantes: estrutura de dados, arquitetura do software, detalhe
procedural e projeto da interface. A fase de projeto tem por objetivo traduzir os requisitos
definidos em uma representação de software com detalhes suficientes para que possa ser
implementado. Como os requisitos, o projeto é documentado (Especificação de Projeto),
sendo este realizado com base na Especificação de Requisitos. Pode-se verificar que
quanto mais refinado (detalhado) for a fase de projeto, mais clara será a fase de
construção.
Na fase de construção, os programas são codificados, as bases de dados criadas e os
módulos do software integrados. Uma vez que o código foi gerado, segue-se a fase de
avaliação da qualidade do software. Esta avaliação deve ser realizada através de
certificação utilizando inspeção, walkthrough, ou prova formal1 ou através de execução
experimental (testes).
Os testes concentram-se em validar os procedimentos lógicos internos do programa,
garantindo que todos os comandos foram testados e que o comportamento funcional
externo do sistema produz os resultados esperados para determinadas entradas de dados.
Teste é um elemento crítico no controle da qualidade de software e representa uma
revisão final das fases de análise, projeto e construção. A intenção da realização de testes
é achar erros e para que os testes sejam eficazes é necessário que estes sejam planejados
com seus objetivos claramente definidos. Na análise dos resultados deve-se procurar
identificar a falha que causou o erro evidenciado pelo teste. Testar exaustivamente e

1
Certificações e técnicas de avaliação da qualidade são definidos na seção 4 desta apostila

Vera Werneck 4/20/2009 3

 ANÁLISE DE SISTEMAS II

completamente um software nem sempre é possível, por isso os testes não podem
assegurar a correção total de um sistema. Entretanto, a utilização de testes combinados
com algumas técnicas de controle da qualidade contribuem para se obter um nível
aceitável de confiabilidade.
O sistema é entregue ao usuário após se chegar a um resultado satisfatório na fase de
avaliação, com um certo grau de confiança. É claro que o sistema ainda passará por
alterações, devido principalmente a erros observados pelo usuário, ou por mudanças
necessárias para melhor adaptação ao ambiente do usuário, ou por problemas de
desempenho. A manutenção do software pode invocar novamente as outras fases do ciclo,
conforme indicado pelas setas na Figura 1.
O modelo de ciclo de vida evolucionário surgiu propondo um desenvolvimento que
expandisse o sistema gradativamente, permitindo que se obtivessem modelos do
comportamento do software antecipadamente, os denominados protótipos. A
prototipagem é uma forma de desenvolvimento incremental e contém quatro tipos
diferentes: ilustrativo (telas), simulado (acesso ao banco de dados é simulado), funcional
(subconjunto limitado) e evolucionário (começa pequeno e cresce). Os três primeiros
tipos são construídos para se atingir objetivos propostos a priori, sendo considerados
protótipos descartáveis. O protótipo evolucionário se tornará ao final um produto
operacional.
Na figura 2, pode-se observar a seqüência de eventos verificada no paradigma da
prototipagem (Pressman 92). Tal como o processo de desenvolvimento convencional de
software (modelo cascata), a prototipagem se inicia com a etapa de definição dos
requisitos. Todos os objetivos a serem atingidos pelo software são definidos, sendo
identificadas as áreas que merecem uma definição mais refinada.
A partir dos requisitos levantados na fase de definição, um projeto inicial é construído
e apresentado ao usuário, refletindo os aspectos visíveis do software. Este projeto rápido
leva à construção de um protótipo, que será avaliado pelo usuário e usado para refinar os
requisitos do software a ser desenvolvido. O processo de refinamento dos requisitos traz
benefícios para ambas as partes envolvidas no processo de desenvolvimento do software.
O usuário, ao participar do processo de desenvolvimento, tem condições de contribuir
para um maior refinamento dos requisitos, gerando maior confiança no software em
desenvolvimento. Outro benefício é que o desenvolvedor do software pode compreender

Vera Werneck 4/20/2009 4

 ANÁLISE DE SISTEMAS II

melhor o domínio sobre o qual está trabalhando e, a partir das questões levantadas pelo
usuário, bem como suas sugestões, poderá desenvolver um produto de melhor qualidade e
mais próximo ao produto requisitado.

Figura 2 - Prototipagem (Pressman 92)

A rapidez na construção de um protótipo pode ser obtida com a reutilização de

software e ferramentas que automatizem a geração do protótipo.
Reutilização de software é o processo de desenvolvimento de software cujo objetivo é
utilizar a experiência adquirida e os produtos obtidos anteriormente, para o
desenvolvimento de novos produtos, podendo ser aplicada nas fases de Análise, Projeto,
Construção ou Avaliação. Assim sendo, a reutilização utiliza: código já testado
anteriormente, projetos validados, especificações de requisitos, e/ou planos para testes
(Pressman 92).
A expressão "reutilização de software" indica uma atividade particular no
desenvolvimento do software. As mudanças observadas no ciclo de vida do software são
mostradas na figura 3.

Vera Werneck 4/20/2009 5

 ANÁLISE DE SISTEMAS II

Análise

Projeto

Construção

Avaliação

Manutenção

Repositório

Figura 3 - Ciclo de Vida com Reutilização

Outra forma de desenvolvimento é caracterizada pelo modelo de síntese automática

(figura 4) que transforma as especificações em programas (Balzer 81), (Boehm 88),
(Bersoff 91), (Connors 92).

Análise

Projeto

Construção
Síntese de
Projeto Avaliação

Manutenção
Síntese de
Projeto e Código

Síntese completa do Software

Figura 4 - Ciclo de Vida com Síntese Automática

O modelo em espiral proposto por Boehm (Boehm 88) mostrado na figura 5, fornece
uma estrutura de trabalho para a produção de software baseada em processo e níveis de
risco permitindo a análise dos riscos em várias etapas do desenvolvimento. Esse modelo
pode ser considerado um meta-modelo pois pode abranger diferentes outros modelos,
desde o modelo cascata até os vários tipos de protótipos. É um modelo cíclico.

Vera Werneck 4/20/2009 6

 ANÁLISE DE SISTEMAS II

A análise dos modelos de ciclo de vida pode ser feita considerando-se a identificação
monolítica ou incremental do processo de desenvolvimento. Na estrutura de trabalho
monolítica, os detalhes de cada fase são completados em sua totalidade, antes do início da
etapa seguinte. Sendo assim, o comportamento do software só pode ser avaliado no final
do desenvolvimento. Na estrutura incremental, os detalhes podem ser retardados com o
benefício de se produzir antecipadamente um protótipo mostrando o funcionamento do
produto (Connors 92).

Figura 5 - Modelo Espiral (Boehm 88)

Vera Werneck 4/20/2009 7

 ANÁLISE DE SISTEMAS II

3. MÉTODOS DE DESENVOLVIMENTO

Na literatura de engenharia de software (Ross 77), (Yourdon e Constantine 78), (Page-

Jones 80), (Chandersekaran e Linder 81), (Jackson 83), (Ward e Mellor 85), (Booch 86),
(Warnier 86), (Chen 87), (De Marco 89), (Jones 90), (Yourdon 90), (Hatley e Pirbhai 91),
(Coad 92), encontramos diversas propostas de métodos que podem atender diferentes
paradigmas (dados, funções, objetos), para diversos domínios de aplicação, com rigor de
expressão diferente e aplicação em fases específicas.
Esses métodos apoiam os desenvolvedores de software na análise e documentação do
problema provendo um mecanismo de abstração, particionamento e representação do
problema a ser desenvolvido pelo sistema.
A fase de análise de requistos é de suma importância no desenvolvimento de um
sistema, pois é a base para o desenvolvimento do software. Outro aspecto a considerar é
que o custo de correção de um erro encontrado nas fases posteriores à fase de projeto é
muito maior (2 a 40 vezes mais). Hoje em dia sabe-se que muitos erros (mais de 50%)
são cometidos na fase de análise e que estes podem ser facilmente detectados. As
consequências de não se detectar os erros nas fases de análise e projeto acarretam na não
satisfação do usuário, desentendimento entre os envolvidos, perda de tempo e dinheiro e
em até problemas jurídicos.
Por isso, os métodos de construção mais difundidos nos diferentes paradigmas e as
técnicas de elicitação dos requisitos serão abordados. Estas técnicas facilitam a
comunicação entre usuários e desenvolvedores, sendo fundamental principalmente por
ser a fase de análise uma atividade que requer uma intensa comunicação entre as partes
envolvidas.

3.1 SADT
SADT (Structured Analysis and Design Technique) foi desenvolvido no início dos
anos 70 por Ross, sendo utilizado inicialmente pela U.S. Air Force e pela ITT européia
(Ross e Schoman 77), (Ross 85).
A estrutura de trabalho do SADT utiliza a técnica top-down onde o desenvolvedor
inicia representando o sistema a nivel macro (diagrama de contexto), e depois refina
repetidamente cada diagrama representando um aspecto do sistema num nível mais

Vera Werneck 4/20/2009 8

 ANÁLISE DE SISTEMAS II

detalhado. Uma especificação com SADT é uma representação gráfica da estrutura

hierarquica do sistema.
SADT permite a modelagem em termos de função e de dados, possuindo como
instrumentos um diagrama de atividades e um diagrama de dados onde as atividades e os
dados são representados através de retângulos e setas. Uma definição suscinta deste
método pode ser encontrada em (Rocha 87) e (Davis 90)

3.2 MÉTODOS ESTRUTURADOS

Os métodos conhecidos como estruturados são Análise Estruturada (DeMarco 89),
Projeto Estruturado (Yourdon e Constantine 78), (Page-Jones 80), Análise Essencial
(Análise Estruturada Moderna) (McMenamim e Palmer 91), (Yourdon 90), Análise
Estruturada para Sistemas de Tempo Real (Ward e Mellor 85),.(Hatley 87).
A Análise Estruturada foi desenvolvida por Gane (Gane 77) e DeMarco (DeMarco 78)
e está intimamente relacionada ao método de projeto desenvolvido por Constantine e
Yourdon, denominado Projeto Estruturado (Yourdon 78).
A Análise Estruturada consiste de um conjunto de técnicas e instrumentos com o
objetivo de auxiliar na análise e definição do sistema. Este método é similar ao SADT.
Utiliza uma linguagem gráfica e fornecendo uma visão top-down e particionada do
sistema. A Análise Estruturada é composta dos seguintes instrumentos:
⇒ Diagrama de Fluxo de Dados, que representa o sistema como uma rede de
processos interligados entre si por fluxos de informação e depósitos de dados.
⇒ Dicionário de Dados que contém a definição dos dados utilizados no DFD.
⇒ Especificação de Processos que define a lógica dos processos representados no
DFD.
No final dos anos 80, a Análise Estruturada havia sido aplicada nos mais variados
tipos de problemas (Davis 90). Entretanto, alguns problemas foram encontrados e a
Análise Essencial (McMenamin 84) surge definindo alguns conceitos e facilitando a
modelagem conceitual do sistema:
⇒ Essência do Sistema ou Requisitos Essenciais é o conjunto de requisitos
verdadeiros, ou seja, requisitos que o sistema deve possuir para atingir o seu
propósito.
⇒ Requisitos Falsos são aqueles requisitos que o sistema não necessita para atingir

Vera Werneck 4/20/2009 9

 ANÁLISE DE SISTEMAS II

seu propósito. Estes requistos podem ser tecnológicos ou arbitrários.

⇒ Tecnologia Perfeita é definida como a tecnologia que não possui limitações físicas.
⇒ Eventos e Respostas: um evento é uma mudança no ambiente externo que o sistema
deve responder e respostas é um conjunto de ações executadas pelo sistema ao
ocorrer um evento.
⇒ Essência do sistema é composta de atividades essenciais e da memória essencial. A
atividade essencial é aquela que o sistema deve executar para atingir o seu
propósito utilizando uma tecnologia perfeita. Memória Essencial são os dados
armazenados pelo sistema para executar as atividades essenciais.
⇒ Encarnação da Essência é um termo utilizado para representar a materialização dos
conceitos contidos no sistema, ou seja, o processo de desenvolvimento de sistemas
é redefinido nas seguintes etapas: definição da essência do sistema (análise),
selecão de uma encarnação da essência (escolha da tecnologia utilizada) e projeto
da implementação (projeto).
Esses conceitos possibilitaram algumas modificações na Análise Estruturada, surgindo
a denominada Análise Estuturada Moderna (Yourdon 90). Essas mudanças reconhecem
que:
⇒ a construção da modelagem física e lógica da situação atual pode paralizar, isto é,
pode acarretar uma produtividade muito baixa na fase de análise;
⇒ a estrutura top-down pura não é boa para sistemas complexos, podendo introduzir
decisões de implementação na fase de análise;
⇒ os diagramas de entidade e relacionamento são extremamente válidos para capturar
a complexidade dos dados e seus relacionamentos.
O processo de modelagem da Análise Estruturada foi alterado para uma estrutura
outside-in, onde se define primeiro o contexto do sistema em relação ao seu ambiente
(definição de seus eventos externos). E a seguir, para cada evento é definido o
comportanmento interno do sistema e criado o modelo comportamental que é composto
de: DFD’s particionados por eventos, hierarquia de DFD’s, Diagrama de Entidade e
Relacionamentos, Dicionário de Dados e Especificação de Processos.
Algumas aplicações são dependentes do tempo e por isso necessitam processar
informações sobre controle. Algumas extensões foram propostas para a Análise
Estruturada se adequar a sistemas de tempo real (Ward 85), (Hatley 87). Esses métodos

Vera Werneck 4/20/2009 10

 ANÁLISE DE SISTEMAS II

introduzem um novo diagrama, o Diagrama de Transição de Estados, que apresenta as

mudanças ocorridas no sistema dependentes do tempo. O conceito de fluxo de controle é
também introduzido, pois este não contém informação e sim um controle que dispara um
processo do sistema.
O Projeto Estruturado foi desenvolvido no início dos anos 70 por Constantine e
Yourdon (Yourdon e Constantine 78), (Page-Jones 80) e estabelece um conjunto de
características de qualidade de um bom projeto (coesão e acoplamento) e uma
linguagem para construir gráficos de estrutura. O objetivo do Projeto Estruturado é
projetar a arquitetura do sistema e de programas como estruturas de módulos de função
única e independentes. Esse método é utilizado na fase de projeto, principalmente ao
modelar o sistema com Análise Estruturada.

3.3 MODELAGEM DE DADOS

O modelo de dados conceitual mais usado é o Modelo de Entidades e
Relacionamentos (MER) desenvolvido por Chen em 1976 (Battini 92) e adotado em 1988
como modelo de dados padrão pela ANSI.
O MER utiliza um diagrama (Diagrama de Entidades e Relacionamentos, DER) que
contém uma estrutura simples e um conjunto de conceitos restritos:
⇒ entidades são qualquer objeto do mundo real sobre o qual se deseja guardar
informações;
⇒ atributos são as informações sobre as instâncias de entidades, podendo ser
propriedades, fatos ou características das entidades;
⇒ relacionamentos entre entidades é definido quando a informação desejada de uma
entidade A diz respeito a uma entidade B e a recíproca é verdadeira. Assim existe
um relacionamento entre a entidade A e B;
⇒ generalização/especialização define um conjunto de entidades que representam
objetos do mundo real que se subdividem em categorias com atributos parcialmente
distintos. Este foi um conceito introduzido em algumas extensões do MER;
⇒ agregação é utilizada ao se necessitar relacionar um conjunto de entidades e um
conjunto de relacionamentos. O mecanismo de agregação define uma nova classe a
partir de um conjunto de outras classes que representam seus componnentes, ou
seja, suas partes. Este também é um conceito introduzido, posteriormente, em

Vera Werneck 4/20/2009 11

 ANÁLISE DE SISTEMAS II

algumas extensões do MER

O MER é um modelo bastante elogiado mas existem também críticas. O conjunto de
conceitos incorporados no seu diagrama é uma vantagem, pois provê um modelo
poderoso de descrição da realidade. Entretanto, essa mesma simplicidade é criticada pois
alguns detalhes não pdem ser plenamente documentados no modelo. Outra crítica é a de
não existir um procedimento definido para construção do modelo (Batini 92).

3.4 MÉTODOS ORIENTADOS A OBJETOS

O conceito de Orientação a Objetos (OO) no desenvolvimento de software tem sua
raiz na linguagem Smalltalk. Nesse estrutura, os átomos da computação são objetos que
mandam mensagens entre si. Essas mensagens resultam na invocação de métodos, que
desempenham as ações necessárias. O objeto que envia a mensagem não necessita
conhecer como o objeto está organizado internamente, somente a resposta do objeto, isto
é, a mensagem específica enviada por esse objeto e seu formato (Colleman 94).
Objetos são grupados em classes quando elas compartilham a mesma interface,
respondem as mesmas mensagens da mesma forma. Isto permite que vários objetos
possam ser descritos em poucas classes. O modelo é dinâmico, pois quando o sistema
executa, objetos passam a existir, desempenham ações e depois cessam de existir ou
tornam-se inacessiveis. Objetos e classes de objetos possuem atributos, sendo que todos
os objetos de uma classe herdam os atributos das classses de que eles são membros.
Algumas vantagens da Orientação a Objetos são apontadas, tais como, flexibilidade,
reuso, extensibilidade e manutenibilidade. A abstração de dados, também é considerada
uma vantagem pois detalhes da representação das classes são visíveis somente para seus
métodos, permitindo que diferentes implementações de uma classe possa ser usada sem
modificação do código (Colleman 94).
Entretanto, alguns problemas também são mencionados: dificuldade de identificar
objetos e classes, necessidade de mudanças no gerenciamento do projeto e falta de
suporte para o trabalho em grupo (Colleman 94).
Na literatura existem várias propostas de métodos de análise e projeto orientado a
objetos: OOA/OOD (Object Oriented Analysis/ Object Oriented Design) de Coad e
Yourdon (1992), OMT (Object Modeling Technique) de Rumbaugh et alli (1991),
e OOIE (Object Oriented Information Engineering) de Martin e Odell (1992).

Vera Werneck 4/20/2009 12

 ANÁLISE DE SISTEMAS II

O método Fusion (Colleman 94) é um método para desenvolvimento OO considerado

de segunda geração que se baseou em outros métodos previamente definidos. Ele provê
suporte para três fases:
⇒ Análise, no qual identifica objetos e classes do sistema, descreve seus
relacionamentos e define as operações que o sistema deve desempenhar.
⇒ Projeto, onde se decide como representar as operações do sistema através da
interação com os objetos relacionados e como essses objetos ganham acesso entre
si.
⇒ Implementação, onde se codifica o projeto em uma linguagem de programação.
UML é uma linguagem padrão para modelagem orientada a objetos. Ela surgiu da
fusão de 3 métodos, do BOOCH,, OMT (Rumbaugh et al) e do Jacobson. E é adotada
como padrão para desenvolvimento orientado a objetos.

Vera Werneck 4/20/2009 13