Quando modelos de casos de uso são usados no levantamento de requisitos (seção 5.4), já estamos tratando o sistema por uma perspectiva funcional. Podemos notar que DFDs e Modelos de Casos de Uso têm alguns aspectos em comum:
• Ambos os modelos mostram as fronteiras do sistema, delimitando o que está fora do sistema (atores nos modelos de casos de uso e entidades externas nos DFDs) e o que é responsabilidade do sistema (casos de uso nos modelos de casos de uso e processos nos DFDs).
• Ambos os modelos mostram quem (atores nos modelos de casos de uso e entidades externas nos DFDs) pode realizar alguma funcionalidade do sistema (casos de uso nos modelos de casos de uso e processos nos DFDs).
Entretanto, há diferenças significativas:
• Nos DFDs, elementos internos ao sistema (depósitos de dados e fluxos de dados ligados a eles) são mostrados. Isso não ocorre nos modelos de casos de uso que buscam modelar as funcionalidades do sistema a partir de uma perspectiva externa. • As associações entre atores e casos de uso não estabelecem que informação está
trafegando, enquanto nos DFDs essa informação é definida pelos fluxos de dados. Para a maior parte das situações, modelos de casos de uso são suficientes para representar a perspectiva funcional de um sistema. De fato, há muita crítica aos DFDs exatamente por misturarem perspectivas (pelo uso de depósitos de dados), bem como pelo nível de detalhe a que se propõem chegar (por exemplo, usando mini-especificações em português estruturado). Assim, quando, no levantamento de requisitos, for elaborado um modelo de casos de uso, os artefatos da modelagem funcional (DFDs particionados por eventos, DFDs organizados em níveis hierárquicos e especificação da lógica dos processos) passam a ser desnecessários. Neste caso, o modelo de análise pode conter apenas:
Diagramas de Entidades e Relacionamentos Diagramas de Estados
Dicionário de Dados
Outra importante questão a ser levantada é o problema da notação dos diagramas em questão (DER e Diagramas de Estado). Conforme citado anteriormente, a Análise Essencial não definiu um padrão de notação para a elaboração desses diagramas. Entretanto, mais recentemente, foi definida uma linguagem de modelagem unificada, a UML [8], que estabeleceu notações padrão para diversos tipos de diagramas, dentre eles os Diagramas de Estados. Assim, a notação apresentada na seção 5.7 já segue esse padrão.
Ainda que a UML não tenha definido um padrão para diagramas de entidades e relacionamentos, usando os diagramas de classes e os mecanismos de extensão oferecidos pela UML é possível definir uma notação que propicie uma interpretação mais universal,
ainda que não padronizada para a elaboração de DERs. Isso permite, por exemplo, o uso de ferramentas CASE com suporte à UML no desenvolvimento de sistemas segundo o paradigma estruturado. A tabela 5.2 mostra a correspondência entre a notação da UML e a notação apresentada na seção 5.6 e a figura 5.49 ilustra as notações da UML já ajustadas para representar DERs.
Tabela 5.2 – Representando DERs com a UML.
DER Notação UML
Entidade Classe Estereotipada <<entidade>> Atributo Atributo
Relacionamento Associação Cardinalidades: (X,Y) Multiplicidades: X ..Y
Agregado Classe Associativa Estereotipada <<agregado>>
Condicionantes Restrições entre Associações
Particionamento de Entidade Generalização
Entidade1 atributo1 atributo2 atributoN <<entidade>> AgregadoE1E2 atributoRelacionamento <<agregado>> Entidade4 <<entidade>> Entidade2 <<entidade>> 0..* 0..* 0..* 0..* nomeRelacionamento 1 0..* 1 Entidade3 <<entidade>> 1 0..* 1 0..* 0..* {Ou exclusivo} Entidade1.1 <<entidade>> Entidade1.2 <<entidade>>
Referências
1. R.S. Pressman, Engenharia de Software, Rio de Janeiro: McGraw Hill, 5ª edição, 2002.
2. I. Sommerville, Engenharia de Software, São Paulo: Addison-Wesley, 6ª edição, 2003.
3. S.L. Pfleeger, Engenharia de Software: Teoria e Prática, São Paulo: Prentice Hall, 2ª edição, 2004.
4. D.F.Togneri, “Apoio Automatizado à Engenharia de Requisitos Cooperativa”, Dissertação de Mestrado, Mestrado em Informática da UFES, 2002.
5. S. Pompilho. Análise Essencial: Guia Prático de Análise de Sistemas. IBPI Press, Editora Infobook, Rio de Janeiro, 1995.
6. E. Yourdon. Análise Estruturada Moderna. Editora Campus, 1990.
7. C.M.S. Xavier, C. Portilho. Projetando com Qualidade a Tecnologia de Sistemas de Informação. Livros Técnicos e Científicos Editora, 1995.
8. G. Booch, J. Rumbaugh, I. Jacobson; UML – Guia do Usuário. Editora Campus, 2000. 9. P. Chen. Gerenciando Banco de Dados: A Abordagem Entidade-Relacionamento para
Projeto Lógico. McGraw-Hill, 1990.
10. W. Setzer. Bancos de Dados. 2a Edição, Editora Edgard Blücher, 1987.
11. C. Gane, T. Sarson. Análise Estruturada de Sistemas. Livros Técnicos e Científicos Editora, 1983.
12. T. De Marco. Análise Estruturada e Especificação de Sistemas. Editora Campus, 1983. 13. C. Gane. Desenvolvimento Rápido de Sistemas. Livros Técnicos e Científicos Editora,
Capítulo 6 – Projeto de Sistemas
O projeto de software encontra-se no núcleo técnico do processo de desenvolvimento de software e é aplicado independentemente do modelo de ciclo de vida e paradigma adotados. É iniciado assim que os requisitos do software tiverem sido modelados e especificados, correspondendo à primeira dentre as três atividades do domínio da solução computacional – projeto, implementação e testes – requeridas para se construir um sistema de software [1].
Enquanto a atividade de análise pressupõe que dispomos de tecnologia perfeita (capacidade ilimitada de processamento com velocidade instantânea, capacidade ilimitada de armazenamento, custo zero e não passível de falha), a atividade de projeto envolve a modelagem de como o sistema será implementado, com a adição dos requisitos não funcionais aos modelos construídos na análise, como ilustra a figura 6.1. Assim, o objetivo do projeto é incorporar a tecnologia aos requisitos essenciais do usuário, projetando o que será construído na implementação. Para tal, é necessário conhecer a tecnologia disponível e as facilidades do ambiente de software no qual o sistema será implementado.
Figura 6.1 – Visão Geral da Atividade de Projeto.
O projeto de software é um processo iterativo. Inicialmente, o projeto é representado em um nível alto de abstração. À medida que iterações ocorrem, os refinamentos conduzem a representações de menores níveis de abstração.
Domínio do Problema Domínio da Solução Mundo Real Mundo Computacional Análise e Especificação de Requisitos (o que) Implementação Projeto (como)
Uma especificação de projeto deve:
• Contemplar todos os requisitos explícitos contidos no modelo de análise e todos os requisitos implícitos desejados pelo cliente;
• Ser um guia legível e compreensível para aqueles que irão codificar, testar e manter o software.
• Prover um quadro completo do software, tratando aspectos funcionais, comportamentais e de dados, segundo uma perspectiva de implementação.
No projeto de sistemas, um modelo de projeto é tipicamente gerado a partir dos modelos de análise, com o objetivo de representar o que deverá ser codificado na fase de implementação. Independentemente do paradigma adotado, o projeto deve produzir:
• Projeto da Arquitetura do Software: visa a definir os grandes componentes estruturais do software e seus relacionamentos.
• Projeto de Dados: tem por objetivo projetar a estrutura de armazenamento de dados necessária para implementar o software.
• Projeto de Interfaces: descreve como o software deverá se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usuário).
• Projeto Procedimental Detalhado: tem por objetivo refinar e detalhar a descrição procedimental dos componentes estruturais da arquitetura do software.
A seguir, cada uma dessas sub-atividades do projeto de sistemas é discutida à luz do paradigma estruturado.