O documento descreve o workflow de análise e modelação de sistemas de informação, destacando a importância de criar um modelo que represente o comportamento desejado do sistema sem focar na implementação. Ele enfatiza a identificação de classes de análise e suas responsabilidades, sugerindo técnicas como análise substantivo/verbo e CRC para descobrir classes relevantes. Além disso, discute a função dos diagramas de classes e objetos na modelagem, incluindo a descrição da estrutura das entidades manipuladas pelos usuários.

1. O workflow de análise
Modelação de Sistemas de Informação - 2010 / 2011

2. Objectivo da análise
¤ Produzir um modelo de análise com
o comportamento desejado para o sistema Inception Elaboration Construction Transition
¤ O que o sistema faz e não como o faz
¤ na linguagem do negócio

3. Modelo de Análise
¤ No Modelo de Análise identificamos:
¤ Classes de análise
¤ Realizações de use cases
P3
P1
Analysis Model P4
P2
analysis class use case realization

4. Detalhe do workflow de Análise
Architectural analysis
Architect
Use Case Engineer Analyze a use case
Component Engineer Analyze a class Analyze a package

5. Linhas orientadoras para a Análise
¤ O modelo de análise está sempre na linguagem do
negócio. As abstracções encontradas no modelo de
análise deverão fazer parte do vocabulário do domínio
do negócio
¤ Os modelos devem "contar uma história". Cada
diagrama produzido deverá elucidar alguma parte
importante do comportamento desejado para o
sistema.
¤ Concentrem-se em capturar a "big picture". Não fiquem
presos nos detalhes de como irá funcionar o sistema –
será realizado na fase de design.

6. Linhas orientadoras para a Análise
¤ Num sistema de complexidade moderada podem surgir
entre 50 a 100 classes no modelo de análise
¤ Inclua apenas as classes que fazem parte do vocabulário
do domínio do problema
¤ Não se preocupe com classes que definam a forma como
algo é implementado – trataremos deste assunto no design
¤ Foque-se nas classes e associações
¤ Não se preocupe muito com a herança de classes
¤ "Keep it simple!"

7. Descoberta das classes de análise
Modelação de Sistemas de Informação

8. Analisar um Use Case
Business model
[or domain model]
Use case
engineer Analysis class
Requirements
model
Analyse a
use case
Use case model
Use case
realization
Architecture
description

9. O que são classes de análise?
¤ As classes de análise representam abstrações
claras do domínio do problema class name BankAccount
¤ podem vir a ser refinadas em uma ou mais
name
classes de desenho
attributes address
balance
¤ Todas as classes do modelo de análise devem
ser classes de análise
deposit()
operations withdraw()
¤ As classes de análise têm:
calculateInterest()
¤ Um conjunto de atributos de alto nível
¤ Operações que são especificações de alto
nível do conjunto de serviços fundamentais
que a classe terá que disponibilizar
¤ As classes de análise devem ser mapeadas dos
conceitos do negócio do mundo real

10. O que faz uma boa classe de análise?
¤ O seu nome reflete o seu objectivo
¤ É um mapeamento de uma característica do domínio do problema
¤ Tem uma alta coesão
¤ Tem um baixo acoplamento
¤ "Regras de ouro"
¤ 3 a 5 responsabilidades por classe
¤ cada classe colabora com outras
¤ cuidado com muitas classes pequenas
¤ cuidado com classes muito grandes
¤ cuidado com os "functoids" – funções disfarçadas de classes
¤ Cuidado com classes omnipotentes
¤ Evitar árvores de herança muito profundas

11. Descobrir Classes
¤ Efetuar a análise substantivo/verbo dos documentos
¤ Os substantivos são candidatos a classes ou atributos
¤ Os verbos são candidatos a responsabilidades ou operações
¤ Efetuar análise CRC – uma técnica de "brainstorming"
¤ Em ambas as técnicas ter cuidado com as "falsas" classes
¤ procurar sinónimos
¤ procurar homónimos
¤ Procurar as classes escondidas

12. Procedimento para análise substantivo/verbo
¤ Recolher todos os documentos relevantes
¤ Documento de requisitos,
¤ Use Cases
¤ Glossário do projeto
¤ etc.
¤ Fazer um lista de substantivos e sintagmas nominais
¤ São classes candidatas ou atributos
¤ Fazer uma lista de verbos ou sintagmas verbais
¤ São responsabilidades candidatas
¤ Tentar atribuir atributos e responsabilidades a classes

13. Procedimento de análise CRC
¤ CRC é uma técnica de "brainstorming" onde se capturam em post-its as coisas importantes do
domínio do problema.
¤ CRC - Class, Responsibilities and Collaborators
¤ Separa a recolha de informação da sua análise
¤ 1ª Parte: Brainstorm
¤ todas as ideias são boas
¤ Não discutir ou debater – apontar e analisar depois
¤ 2ª Parte: Analisar a informação e consolidar com a análise substantivo/verbo
Class Name: BankAccount
Responsibilities: Collaborators:
things the
Maintain balance Bank things the
class does class works
with

14. Descobrir classes de outras fontes
¤ Objetos físicos tais como aviões, pessoas, hotéis, etc.
podem vir a representar classes
¤ formulários e outro tipo de "papelada" – cuidado com a
abordagem
¤ Interfaces com o mundo exterior
¤ Entidades conceptuais que são fundamentais para a
operação do negócio mas que não se manifestam
como coisas concretas, e.g. LoyaltyProgramme

15. Criar uma "primeira versão" do modelo de análise
¤ Consolidar os outputs das diferentes análises
(substantivo/verbo, CRC, ou outras) num modelo UML
utilizando uma ferramenta de modelação

16. Diagramas de classes e de objectos
Modelação de Sistemas de Informação

17. Diagramas de classes
¤ É o ponto central do desenvolvimento OO.
¤ Em análise, tem como objectivo descrever a estrutura das entidades manipuladas pelos
utilizadores.
¤ No desenho, o diagrama de classes apresenta a estrutura de um código orientado por
objetos, ou num nível de detalhes maior, os módulos da linguagem de desenvolvimento.

18. Objetivo dos diagramas de classes
¤ Um diagrama de classes serve para modelar o vocabulário de um sistema, do
ponto de vista do utilizador/problema ou do implementador/solução
¤ Ponto de vista do utilizador/problema – na fase de captura e análise de requisitos, em
paralelo com a identificação dos casos de utilização
¤ Vocabulário do implementador/solução – na fase de projeto (design)
¤ Construído e refinado ao longo das várias fases do desenvolvimento do software,
por analistas, projetistas (designers) e implementadores
¤ Também serve para:
¤ Especificar colaborações (no âmbito de um caso de utilização ou mecanismo)
¤ Especificar esquemas lógicos de bases de dados
¤ Especificar vistas (estrutura de dados de formulários, relatórios, etc.)
¤ Modelos de objetos de domínio, negócio, análise e design

19. Exercício de diagrama de classes
¤ Um recibo tem um numero, uma data de emissão, o nome e o número
de contribuinte da empresa que passa o recibo e do cliente, um
subtotal, um total de IVA, um total e um conjunto variável de linhas
¤ Cada linha do recibo refere um só produto (podendo cada um destes
ser referido por mais do que uma linha do recibo) e contém a
quantidade do produto comprado, a sua descrição, a taxa de IVA (em
percentagem) paga por esse produto, o seu preço unitário e o preço a
pagar tendo em conta a quantidade comprada.
¤ Um recibo é passado por uma só Empresa a um Cliente (que pode ter
muitos recibos da mesma empresa passados em seu nome).
¤ A empresa é identificada por um número de contribuinte, tem um
nome, um endereço, um numero de telefone e um número de fax.
¤ O recibo deve poder ser impresso.

20. Solução possível

21. Diagramas de objetos
¤ Finalidade
¤ Um diagrama de objetos mostra instâncias de classes
(objetos) e de associações (ligações entre objetos)
¤ Utilizados para ilustrar cenários / configurações particulares
¤ Base para diagramas de colaboração

22. Exemplo: Árvore genealógica
1 0..*
Homem Casal Mulher ¤ Como se chama o
0..1
0..* 1
neto?
0..* -descendente
¤ Quem é o sogro da
Pessoa
-nome
Leonor?
João : Homem Maria : Mulher Pedro : Homem Manuela : Mulher
João & Maria : Casal Pedro & Manuela : Casal
-descendente -descendente -descendente -descendente
Afonso : Homem Leonor : Mulher Carlos : Homem Josefa : Mulher
Carlos & Leonor : Casal
-descendente
Filipe : Homem

23. Exercício diagrama de objetos
¤ Com base neste diagrama de classe, elaborar um diagrama de objetos,
elaborar um diagrama de objectos que corresponda à seguinte
situação: “A Delta satisfaz a encomenda 456, em 2009/03/31. A
encomenda 456, efectuada em 2009/02/10, tem dois itens: (i) produto
A, café lote diamante, 1000 unidades, 300€; (ii) produto B, café lote
normal, 500 unidades, 200€. Ambos os produtos são de tipo alimentar.”

24. Solução possível