Análise do Sistema
Alexandre Mota
([email protected])
Desenvolvendo o Sistema
Documento
de
Requisitos
Sub-sistemas
Problema
Solução
...
Form. Matrícula
: Estudante
1: entra id
2: verifica id
3: entra semestre atual
4: cria novo cronograma
5: processa
Modelo dos
requisitos
Detalhes e
Dec. de projeto
Perspectiva
do Usuário
Perspectiva do
Desenvolvedor
Modelo UML: “Visão 4+1”
Funcionalidade
Logical View
Development View
Class diagrams,
Sequence diagrams
Component diagrams
Configuração
Use Cases/
Scenarios
Use Case diagrams,
Sequence diagrams
Performance
Process View
Physical View
Deployment diagrams
Deployment diagrams
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 problema
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
Sistema
Gerente
BD
Abre Conta
Solicita Info Cliente
Info Cliente Fornecida
Solicita Tipo de Conta
Tipo de Conta Fornecida
Solicita Saldo Inicial
Saldo Inicial Fornecido
Confirmação
Cria Conta
Abordagem 2: Cartões CRC


CRC vem de Class-ResponsibilityCollaboration
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
Atributos
Métodos
{
{
Responsibilities
Catalog number
Catalog store
Add Book
Remove Book
Catalog
Collaborations
Book
Atualizações
Class Name
Atributos
Métodos
{
{
Responsibilities
Catalog number
Catalog
Collaborations
Book
Catalog store
Add Book
Remove Book
Diagrama de Classes + Diagrama de Seqüências
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 redefinida 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
<<boundary>>
Class Name
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
Form. Matrícula
: Estudante
1: entra id
2: verifica id
3: entra semestre atual
4: cria novo cronograma
5: processa
<<boundary>>
Form. Matrícula
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
<<entity>>
Conta
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
1: enter id
:Schedule
Form
:Registration
Manager
:Catalogue
:Course
:Student
Record
:Course
Roster
2: validate id
3: enter current
4: create new
5: display
6: display
7: select course
8: process
9: create schedule
10: get prerequisite
11: prerequisite taken ?
12: add student (John)
13: print
14: send to billing system
15: registration complete
16: registration complete
:Schedule
:Billing
System
Bibliografia



Sommerville, I. Software Engineering
Kruchten, P. The Rational Unified
Process: An Introduction
Tepfenhart, W. et al. Practical ObjectOriented Development with UML and
Java