análiseemodelaçãodesistemas - w3.ualg.ptw3.ualg.pt/~mzacaria/tutorial-uml/aulas/t12-2011.pdf ·...
TRANSCRIPT
ì Análise e modelação de sistemas
Classe T13: Passando da análise ao Desenho
Programa
ì Organizando os diagramas
ì Da análise ao desenho ì Estereó;pos ì Classes de análise vs classes de desenho ì Estereó;pos das classes de desenho
ì Pacotes
Modelação
2
Organização dos diagramas I
ì Construir um diagrama de topo (nível 0) com < 15 classes
ì Construir diagramas de nível 1 a par;r das classes no centro do diagrama de topo rodeiadas por 5 ou 10 classes de suporte e a sua relação com a classe do diagrama de topo
ì Mostrar agregações complexas em diagramas separados
Modelação
3
Organização dos diagramas II
ì Mostrar heranças complexas em diagramas separados
ì Caso os diagramas de nível 1 forem complexos com mais de 10 classes de suporte, crie um novo nível.
ì Cada diagrama de endereçar um tópico ou ideia
ì Mostrem os pressupostos temporais
Modelação
4
Da análise ao desenho
ì Análise ì Domínio do problema
ì Desenho ì Domínio da solução
ì Passamos da análise ao desenho quando começamos a organizar e detalhar as classes de forma a construir o sistema ì Classes de desenho ou classes da aplicação
ì Os casos de u;lização são transformados no desenho dum sistema através dos diagramas de análise
Modelação
5
Classes de Análise
Modelação
6
+ + - -
Classes de desenho
Modelação
7
Análise vs desenho
Classes de Análise ì Representam o domínio do
problema ì Conceitos e relações do
domínio que o SI vai suportar
ì Menos detalhadas
ì Independentes da linguagem da programação
ì Mapeamento indirecto com implementação
Classes de desenho ì Representam o domínio da
solução ì Conceitos e relações do SI
ì Muito + detalhadas
ì Reflectem arquitectura do SI e linguagem de programação
ì Mapeamento directo com classes a implementar
Modelação
8
Análise vs desenho
Modelo de análise ì Evitam aspectos de
implementação
ì Aplicável a vários desenhos
ì Menos formal
ì + barato
ì Poucas camadas
ì Criado manualmente
ì É abandonado a par;r dum ponto do desenvolvimento
Modelo de desenho ì Esquema da implementação
ì Especifica um único desenho
ì Mais formal
ì + caro
ì + camadas
ì Desenvolvido itera;vamente junto com a programação
ì É man;do ao longo de todo o processo de desenvolvimento Modelação
9
Análise vs Desenho: Multi-‐Banco
Modelação
10
Classes de Análise: Multi-‐banco
Modelação
11
Classes de desenho: Multi-‐Banco
Modelação
12
Análise vs Desenho: Multi-‐banco
Modelação
13
Análise
Desenho
Modelação
14
Diagrama de sequência de análise
Modelação
15
Diagrama de sequência de desenho
Model-‐View-‐Controller
Modelação
16
Diagrama de classes com MVC
Modelação
17
Classes MVC
Modelação
18
MVC -‐ NetBeans
Modelação
19
Modelação
20
Diagrama de sequência de desenho arquitectural MVC
Relembrar Estereótipos
ì Mecanismo para extender UML
ì Cria novos elementos a par;r dos existentes com um conjunto de propriedades específicas adequadas para problemas par;culares
ì Iden;ficados com << nome estereó;po >> acima do nome do elemento ou até com um icone diferente
ì Atributos ì Tag defini;ons (estereó;pos) ì Tagged values (elementos estereo;pados)
Modelação
21
Estereótipos de classes
Modelação
22
Modelação
23
Mais estereótipos…. Uso de icones
Mais estereótipos…. Uso de cores
Estereótipos MVC
Modelação
24
VIEW MODEL CONTROLLER
Pacotes…
ì Mecanismo genérico para agrupar os dis;ntos elementos dos modelos
Modelação
25
Pacotes
ì Mecanismos de agrupação de classes e/ou diagramas
ì Usados tanto na análise como no desenho
ì Critérios de agrupamento dependem de: ì Fases do desenvolvimento ì Tipos de diagrama ì Controlo de versões
Modelação
26
Pacotes (UML / SysML)
ì Os diagramas de pacote mostram a organização dos elementos do modelos de análise e desenho, assim como as suas inter-‐dependências
Modelação
27
Pacotes e estrutura do projecto
Modelação
28
Relações entre pacotes…
Modelação
29
Pacotes e casos de uso…
Modelação
30
Da Análise ao desenho: Pacotes
ì Desenvolver pacotes de análise ì Agrupamento de classes por tópicos, ideias, interligações,
etc. ì Agrupamento de use cases por actor
ì Reorganizar os pacotes para o desenho do sistema ì Reagrupar use cases e classes pensando nos programadores,
a fase do desenvolvimento e a arquitectura prevista para o sistema
Modelação
31
Da Análise ao desenho: Pacotes
ì Converter os pacotes em sub-‐sistemas
ì Analise as inter-‐dependências
ì Re-‐organize os sub-‐sistemas para incrementar as dependências (performance) ou diminui-‐las (modularidade), ou para reflec;r um padrão arquitectural específico. Detalhe os sub-‐sistemas
Modelação
32
Pacotes de análise e desenho
ì Análise ì Classes de domínio
ì Hierarquias ì Agregações ì Conceitos persistentes
ì Agrupe os use cases por actor
ì Desenho ì Aplicações (;pos de classe view, controller, domain,
boundary) ì Tipos de dados comuns (enumerações, classificação de
dados e ;pos de dados abstractos. Modelação
33
Actividades do desenho
ì Definir prioridades de desenho
ì Analisar sistema actual
ì Decompor o sistema em subsistemas
ì Definir a arquitectura do sistema
ì Definir objectos persistentes
ì Definir interface entre subsistemas
ì Definir estratégias do sistema ì Início e fecho ì Gestão de falhas
Modelação
34
Critérios para definir sub-‐sistemas
ì Agrupação de use-‐cases semelhantes ì Colocar os use cases onde
são mais frequentemente u;lizados
ì Criar um sub-‐sistema para o use-‐case.
ì Hardware and sofware ì Sub-‐sistemas para gerir um
;po de disposi;vo específico ì Sub-‐sistemas para gerir:
ì Sofware novo ì Sofware legado ì Sofware comercial
ì Data de implementação ì Dono ì Equipamento (web/
applica;on/data servers, machines, etc)
ì Prioridades de desenho Modelação
35
Prioridades de desenho
ì Requisitos funcionais
ì Modularidade ì Flexibilidade, extensibilidade, manutenção ì + tempo e custos
ì Escalabilidade, confiabilidade, disponibilidade
ì Performance
ì Custo
ì Tempo
Modelação
36
Examine as inter-‐dependências ì Dependência, Co-‐dependência , Independência
ì Acoplamento: um sub-‐sistema fortemente acoplado tem muitas dependências
ì Coesão: um sub-‐sistema altamente coeso tem todas as classes que precisa para cumprir com as suas responsabilidades.
ì Há que encontrar um balance apropriado entre coesão e acoplamento. Isto se faz reorganizando as classes até chegar lá.
ì Este balance depende de requisitos e critérios de desenho
Modelação
37
Alguns padrões arquitecturais ì Three ;er
ì Dados, lógica, apresentação
ì Façade (Interface simples para esconder detalhes internos ì Interface + sub-‐sistemas/componentes/classes
ì Adapter (interface web para aplicação em Cobol) ì Adaptar a interface dum sistema an;go (adaptee-‐>
adaptor)
ì Master-‐slave ì Um sub-‐sistema mestre e o resto são escravos
Modelação
38
Outros padrões arquitecturais
ì Pipe-‐filter (execução de sequências passo a passo) ì Cada sub-‐sistema é um passo ì Os dados estão num sub-‐sistema aparte
ì Padrão “Broker” ì Os objectos invocam objectos remotos através de
intermediários ì Ex: o desenho usando o padrão “proxy”
ì Padrão “peer-‐to-‐peer”
Modelação
39
Pacotes de subsistemas de Multi-‐banco
Modelação
40