Rodrigo Leite Durães. rodrigo_l_d@yahoo.com.br

O que é Análise de Software?

– É o estágio de um sistema que captura os requisitos e o domínio do problema, focalizando no que deve ser feito, não como faze-lo.

Objetivos da Análise de

Software

Análise de Software tem por objetivo analisar os requisitos previamente levantados, realizando refinamento e estruturação dos mesmos

_ Análise: decompor para obter entendimento O que se deseja? – Entendimento mais preciso dos requisitos

– Descrição dos requisitos fácil de manter e que ajuda a estruturar todo o sistema

_ incluindo arquitetura

Análise Orientada por Objetos

Elementos básicos

– Objetos Entidades do domínio

Outros itens importantes

– Classes Agrupamentos de objetos similares

Atributos

Métodos

Análise Orientada por Objetos

Identificação das classesExemplo (Engenharia de Software, Fundamentos, Métodos e Padrões, 2a. Edição)

1. O caixeiro faz a abertura da venda

2. O caixeiro registra os itens vendidos, informando a identificação e quantidade do item

3. O sistema totaliza a venda para o cliente da da mercearia

4. O caixeiro encerra a venda

5. O sistema emite o ticket de caixa para o cliente da mercearia

6. O caixeiro registra a forma de pagamento

7. O sistema faz a baixa no estoque das mercadorias vendidas

Análise Orientada por Objetos

Identificação das classes Especificação das classes encontradas – Definição clara e concisa

– Lista de responsabilidades (o que ela deve fazer)

– Lista de colaborações (com que outras classes ela interage)

– Regras ou restrições aplicáveis

– Possíveis exemplos.

Análise Orientada por Objetos

Identificação das classes Item de Venda, exemplo: – Descrição

Informação relativa a um item de venda – Responsabilidades Comandar baixa no estoque

Calcular impostos

Imprimir linha de ticket na nota fiscal – Colaborações Venda, Mercadoria – Regras e restrições Cada item de venda corresponde a uma linha do ticket de caixa e na nota fiscal

Todo item de venda deve corresponder a uma mercadoria no estoque – Exemplos Seis cervejas Rottenbeer em lata

Duas caixas de pregos número 2

Análise Orientada por Objetos

Revisão da Análise Consiste em validar o modelo de análise. Consiste em:

– Percorrer os casos de uso, verificando se existem caminhos para realizar todas as operações necessárias.

– Verificar, para cada campo de saída requerido nas interfaces, se existe uma maneira de obter esse campo através de alguma colaboração entre as classes.

Análise de Software –

Sumário

Modelagem de análise:

– Produz especificação mais precisa dos requisitos.

– Descrita utilizando a linguagem dos desenvolvedores, mais formalismo funcionamento interno do sistema.

Estrutura os requisitos

– Facilita entendimento e manutenção.

Primeiro esboço da modelagem de desenho – Embora seja uma modelagem por si só

– Estágio de um sistema que descreve como ele será implementado, em nível lógico superior ao do código.

O que é Desenho de

Software? Atenção a nomenclatura

– Tradução de Software design

– Alguns autores traduzem como projeto de software

Mas projeto é também a tradução de software project

Objetivos do Desenho de

Software

Adquirir um profundo entendimento das questões relacionadas aos requisitos não-funcionais

– linguagens de programação, reuso de componentes, sistemas operacionais, distribuição e concorrência, bancos de dados, interface do usuário, transações, etc.

Ponto de partida apropriado para a implementação

– subsistemas, interfaces e classes.

Decompor o trabalho de implementação em diversas partes gerenciáveis

– Nem sempre possível nos requisitos ou análise

Desenho de Software

Capturar as principais interfaces entre subsistemas

– Útil para arquitetura e sincronismo do trabalho de diferentes equipes.

Estar apto a visualizar e elaborar sobre desenho utilizando uma notação comum

Criar abstração correta da implementação do sistema,

– implementação torna-se refinamento direto do desenho. _ Resultado: modelagem de desenho

Desenho Orientado por

Objetos –

Detalhamento dos casos de uso

Resolver detalhes dos fluxos dos

casos de uso de desenho, considerando os componentes reais das interfaces.

Todos os fluxos alternativos devem ser detalhados, inclusive os de erro ou exceção.

Desenho Orientado por

Desenho das EntidadesTransformar as classes de entidade da modelagem de

Objetos – análise nas correspondentes da modelagem de desenho.

Inclui-se também: – Consideração de reutilização dessas classes

– Consideração de transformação dessas classes em componentes

– Decidir como serão representados os relacionamentos em caso de multiplicidades um para muitos

– Todos os detalhes que eram irrelevantes na análise,

Ex: visibilidade das classes, navegabilidade dos relacionamentos.

Desenho Orientado por

Desenho da PersistênciaDefinição de estruturas externas de armazenamento

Objetos – persistente

Problemas a resolver: – Definição física das estruturas persistentes externas Esquema de um banco de dados.

Realização de ponte entre o modelo de desenho orientado a objetos e paradigmas das estruturas de armazenamento (relacionais, por exemplo).

– Ponte feita pela camada de persistência, Pode ser reaproveitada em outros sistemas se bem desenhada.

Pode ser reaproveitada de outros sistemas com camadas bem desenhadas.

Desenho Orientado por

Realização dos casos de usoDetermina como os objetos das classes de

Objetos – desenho colaborarão para realizar os casos de uso:

– As classes da camada de controle conterão o código que amarra essas colaborações

– Diagramas de interação são usados para descrever as colaborações.

– Classes utilitárias ajudam a abstrair aspectos comuns.

_ Diferente da realização da análise - serve para validar muitas das decisões tomadas nas atividades anteriores.

Desenho Orientado por

Desenho das LiberaçõesDetermina como a construção do

Objetos – produto será dividida em liberações executáveis (releases). Divisão procura:

– Mitigar os maiores riscos

– Obter realimentação dos usuários a intervalos razoáveis

– Dividir as unidades de implementação entre as equipes de trabalho.

Comentários