Análise do Sistema
description
Transcript of Análise do Sistema
Análise do Sistema
Alexandre Mota([email protected])
Desenvolvendo o Sistema
Documentode
Requisitos
...
Problema Solução
: EstudanteForm. Matrícula
1: entra id
2: verifica id
3: entra semestre atual4: cria novo cronograma
5: processa
Modelo dosrequisitos
Perspectiva do Usuário
Detalhes eDec. de projeto
Perspectiva do Desenvolvedor
Sub-sistemas
Modelo UML: “Visão 4+1”
Development View
Process View Physical View
Use Cases/Scenarios
Logical View
Class diagrams,Sequence diagrams Component diagrams
Deployment diagrams Deployment diagrams
Use Case diagrams,Sequence diagrams
Funcionalidade
Performance
Configuração
Topologia
Modelo
Para criarmos um modelo do sistema, temos que identificar: Objetos Classes
Atributos Métodos
Associações entre classes Outros relacionamentos entre classes
Classes
<< Estereótipo >>NomeDaClasse
+ atribPub: Tipo = Inicial# atribProt- atribPriv<< constructor>>new()<<query>>getRiscos(o: Cliente)
** pode ser:{persistent}
Semântica das Classes
A descrição da classe deve Focar em seu propósito
(funcionalidade) e não em sua implementação
Na análise, as classes só devem estar relacionadas ao domínio do problemaEssência é “O QUÊ” e não “COMO”Essência é “O QUÊ” e não “COMO”
Análise Projeto
Abordagem 1: Linguagem Para identificar objetos, classes e interfaces,
liste todos os nomes (substantivos), pronomes e frases do seu documento de requisitos/casos de uso
Nomes próprios e frases que indiquem unicidade representam objetos João, ela, minha conta, o elevador 1
Nomes comuns ou no plural indicam classes ou interfaces Clientes, contas, um elevador
Abordagem 1: Linguagem
Para identificar serviços (métodos), atente para os verbos ou frases verbais Clientes podem depositar na poupança
Para identificar atributos, analise as frases que expressam propriedades de objetos/classes Clientes possuem uma senha, ou
A senha do cliente deve ser de no mínimo 8 caracteres
Abordagem 1: Linguagem
Verbos também podem identificar associações entre objetos, classes ou interfaces Uma disciplina tem pelo menos 3 alunos
matriculados Assim como, relacionamentos de
herança, dependência, etc. Uma poupança é um tipo especial de
conta bancária
Infelizmente...
Na documentação informal, existirão nomes que não serão objetos, classes e nem interfaces
Não há um algoritmo que nos permita modelar um sistema da forma perfeita
Tudo depende de experiência e julgamentos corretos na hora de escolher o grau de abstração certo
Utilidade dos casos de uso Casos de uso são mais interessantes que
texto informal pois são mais estruturados e orientados a serviços
Casos de uso naturalmente são vistos como métodos
As intenções de um subconjunto de casos de uso revelam as classes
Demais elementos são obtidos pelos fluxos de ações ou diag. de seqüência
Diagrama de Seqüências
Gerente BDSistemaAbre Conta
Solicita Info Cliente
Info Cliente Fornecida
Solicita Tipo de Conta
Tipo de Conta Fornecida
Solicita Saldo Inicial
Saldo Inicial Fornecido
ConfirmaçãoCria Conta
Abordagem 2: Cartões CRC CRC vem de Class-Responsibility-
Collaboration Um cartão CRC mostra
Nome da classe e descrição Suas responsabilidades
Conhecimento interno (atributos) Seus serviços (métodos)
Os colaboradores das responsabilidades Um colaborador é uma classe cujos serviços são
necessitados por uma responsabilidade
Uma sessão CRC
Grupo de pessoas desenvolvem um cenário
Um cartão é criado para cada objeto no cenário
Cada participante é associado a grupo de cartões A pessoa torna-se a “classe”
Uma sessão CRC
Os cenários definidos são praticados pelos participantes
Os cartões são anotados com as responsabilidades e colaborações
Novos cartões surgem para novos objetos descobertos
Exemplo de CRC
Class Name Catalog
Responsibilities Collaborations
Catalog number
Remove Book
Add Book
Book
Catalog store{{
Atributos
Métodos
AtualizaçõesClass Name Catalog
Responsibilities Collaborations
Catalog number
Remove Book
Add Book
Book
Catalog store
Diagrama de Classes + Diagrama de Seqüências
{{
Atributos
Métodos
Evolução
Trabalho vai bem se . . . Todas as classes têm nomes
significativos, domínio específico e pequeno conjunto de colaboradores
Não há classes “instáveis” (uma classe que colabora com alguém precisa ser re-definida completamente)
Mudança nos requisitos só envolve classes
Evolução
E mal se . . . Várias classes não têm
responsabilidades Mesma responsabilidade atribuída a
várias classes Todas as classes colaboram com
todas as outras classes
Estereótipos (<< >>)
Um estereótipo representa a classificação de uma classe
Toda classe deve ter apenas um estereótipo
Mais comuns Boundary, Entity, Control, Exception,
Utility
Boundary Classe boundary modela a comunicação
entre a parte interna e externa do sistema
Mais comuns Windows (GUI) Protocolo de comunicação (interface do
sistema) Interface com a impressora Sensores Class Name
<<boundary>>
Boundary Informações entre ator e sistema
devem estar contidas em classe boundary Diagramas de seqüência são
examinados para identificar o conteúdo da classe : Estudante
Form. Matrícula
1: entra id
2: verifica id
3: entra semestre atual
4: cria novo cronograma
5: processa
Form. Matrícula<<boundary>>
Janelas Protótipos (desenhos) de janelas
podem ser criados para representar a classe boundary ao usuário
Interface com outros Sistemas
Classe boundary também pode ser usada para modelar interface com outros sistemas
Suas características são: Informação a ser comunicada com o
outro sistema Protocolo de comunicação usado
nesta transferência
Entidade Classe de entidade modela informação
geralmente “persistente” Valores de seus atributos são
freqüentemente fornecidos por um ator Exemplos seriam
Curso Estudante Professor Conta
Conta<<entity>>
Diagrama de Seqüência
Os diagramas de seqüência são atualizados Classes adicionais são incluídas no
diagrama Objetos no diagrama são associados a
classes
Diagrama Atualizado
John : Student
:Registration Form
:Catalogue :Course :Student Record
:Course Roster
:Schedule :BillingSystem
:Registration Manager
:Schedule Form
1: enter id2: validate id
3: enter current
4: create new 5: display
6: display
7: select course
8: process
16: registration complete
9: create schedule
10: get prerequisite
11: prerequisite taken ?
12: add student (John)
15: registration complete
13: print
14: send to billing system
Bibliografia
Sommerville, I. Software Engineering
Kruchten, P. The Rational Unified Process: An Introduction
Tepfenhart, W. et al. Practical Object-Oriented Development with UML and Java