O Processo Unificado - Análise
Engenharia de Sofwtare I Informática
Profa. Dra. Elisa H. M. Huzita Profa. Dra. Itana Gimenes
Análise
Objetivos da análise:
manter uma especificação precisa dos requisitos por meio do modelo de análise.
descrever o modelo de análise usando a linguagem dos desenvolvedores.
O modelo de análise:
estrutura os requisitos em uma forma que facilita seu
entendimento, preparando-os, modificando-os e mantendo- os consistentes.
é o primeiro passo para o modelo de projeto.
Captura de requisitos x análise
Modelo de Casos de Uso Modelo de Análise
Descrito utilizando a linguagem do cliente. Descrito utilizando a linguagem do desenvolvedor.
Visão externa do sistema. Visão interna do sistema.
Estruturado em casos de usos – oferece estrutura
para a visão externa. Estruturado em classes estereotipadas e pacotes – oferece estrutura a visão interna.
Utilizado como um contrato entre clientes e desenvolvedores sobre o que o sistema deve ou não fazer.
Utilizado pelos desenvolvedores para entender como o sistema deve ser concebido (projetado e implementado).
Pode conter redundâncias, inconsistências, etc.,
entre requisitos. Não deve conter redundâncias, inconsistências, etc., entre requisitos.
Captura as funcionalidades do sistema, incluindo funcionalidades significantes do ponto de vista de arquitetura.
Esboça como concretizar os casos de uso no sistema, incluindo funcionalidades significantes do ponto de vista de arquitetura – funciona como uma prévia do projeto.
Define os casos de uso que serão futuramente
analisados no modelo de análise. Define a concretização dos casos de uso, cada um representando a análise do modelo de caso de uso.
Análise
Modelo de Análise
Artefatos: classes de análise
As classes de análise são óbvias no contexto do domínio do problema. São mais conceituais e de granularidade maior do que as classes de projeto e implementação.
definem responsabilidades – dificilmente incluem operações.
definem atributos, em um nível mais alto nível.Os atributos são conceituais e reconhecíveis no domínio do problema. Podem se tornar classes no projeto e implementação.
estereótipos: de limite, de controle ou entidade
Classes de análise
Estereótipo de classes de análise
Artefatos: Use case realization - análise
Descreve como um caso de uso é executado em termos de classes de análise e da interação entre seus respectivos objetos.
Contém uma descrição textual do fluxo de eventos, um diagrama de classes participantes e um diagrama de colaboração.
Use-case realization - análise
Exemplo de um diagrama de classes de análise (Figura 8.11)
Exemplo de um diagrama de colaboração (Figura 8.12)
Artefatos: pacotes de análise
Consiste de classes de análise, use case realizations e outros pacotes de análise (recursivamente).
Organizar os artefatos do modelo de análise em pedaços gerenciáveis.
Deve ser coeso e fracamente acoplado.
pode representar uma separação de interesses:
diferentes desenvolvedores com diferentes conhecimentos do domínio.
reconhecidos pelas pessoas com conhecimento do domínio.
Artefatos: pacotes de serviço
Representam serviços providos pelo sistema ao cliente. Ex. verificar ortografia.
São entrada para as atividades de projeto e implementação subseqüentes.
Artefatos: descrição arquitetural
Contém uma visão da arquitetura do ponto de vista de análise incluindo os artefatos significativos do ponto de vista de arquitetura:
pacotes de análise e suas dependências.
as classes de análise chaves (entidade, limite e controle).
use case realization de uma funcionalidade crítica/
importante envolvendo pacotes de análise, ou foco sobre algum caso de uso importante e prioritário.
Papéis
arquiteto: responsável pela integridade
(correto, consistente e legível ) do modelo de análise.
engenheiro de caso de uso: responsável por um ou mais use case realizations.
engenheiro de componente:
Definir e manter classes de análise, pacotes de análise.
Artefatos e papéis
Workflow de Análise
Análise arquitetural
Análise de casos de uso
Análise de classes
Análise de pacotes
Workflow: análise arquitetural
Esboçar o modelo de análise e a arquitetura identificando os pacotes de análise, as classes de análise e os requisitos especiais.
Identificar os pacotes de análise:
Associar a porção de um caso de uso a um pacote em específico, o que implica em compreender a funcionalidade correspondente.
Analisar os casos de uso relacionados.
Workflow: análise arquitetural
Workflow: análise arquitetural
Identificar pacotes de serviço – funcionalidades comuns aos níveis superiores.
Workflow: análise arquitetural
Application-specific layer Application-general layer
Workflow: analisar casos de uso
Workflow: analisar casos de uso
Identificar as classes de análise necessárias para executar o fluxo de eventos do caso de uso.
Cada caso de uso é refinado como uma colaboração de classes de análise.
Capturar os requisitos especiais - não funcionais.
Exemplos:
A fatura deve ser persistente.
A classe Gerenciamento de Pedido deve ser capaz de manipular 10.000 transações por hora.
Workflow: analisar classes
Identificar e manter as responsabilidades de uma classe de análise com base em seu papel no use case realization.
Identificar e manter os atributos e
relacionamentos de uma classe de análise.
Capturar requisitos especiais na realização da classe de análise.
Workflow: analisar pacotes
Verificar se os pacotes são independentes.
Verificar se os pacotes de análise estão
consistentes com o propósito de concretizar um caso de uso ou uma classe de domínio.
descrever dependências de modo que o efeito de próximas modificações possam ser
estimadas.
Workflow: analisar pacotes
principais diretrizes:
definir e manter as dependências entre pacotes;
verificar se os pacotes contém as classes corretas;
limitar as dependências entre pacotes.
SUMÁRIO DO WORKFLOW ANÁLISE
Resultados:
Classes de análise e suas responsabilidades, atributos, relações e requisitos especiais
Diagrama de classes
Diagrama de colaboração
use case realization - análise
Descrição arquitetural contendo os pacotes de análise, de serviços , suas dependências e conteúdos.
