Análise do Sistema Alexandre Mota

Visão Atual :C1:C2:C3 C1 Att1 M1 C2 Att2 M2 C3 Att3 M3

Relacionamentos Para um objeto enviar uma mensagem a outro, ele deve conhecê-lo Relacionamentos capturam as interdependências entre objetos e fornece os meios pelos quais os objetos conheçem uns aos outros

Tipos de Relacionamentos Generalização Relação entre classes (herança) Agregação Relação na qual um objeto é formado de outros objetos Associações Relação na qual um objeto conhece à respeito de outro

Generalização Caracteriza a relação “é um tipo de” E como já se sabe: Atributos, relações, serviços, e métodos são herdados da generalização (superclasse) pela especialização (subclasse)

Generalização Window open() close()... handleEvent() DialogBox Console

Propriedades Matemáticas Anti-simetria Se classe A é descendente de classe B, então classe B não pode sê-lo de classe A Transitividade Se classe C é descendente de classe B e classe B é descendente de classe A, então classe C é descendente de classe A.

Teste sobre Generalização Dado um par de objetos A e B, faz-se: Objeto A é um tipo de objeto B? Objeto B é um tipo de objeto A? As possíveis respostas serão: Sempre, as vezes ou nunca E a interpretação: A é B?B é A?Resultado SempreSempreSinônimos SempreAs vezesB é generalização de A As vezesSempreA é generalização de B

Agregação Captura a relação Todo-partes entre objetos Não há herança entre objetos de uma agregação Reduzem a complexidade por possibilitar tratar vários objetos como um único

Agregação Centro Departamento 1 *

Propriedades Estrutural As partes devem ter alguma relação estrutural/funcional com o todo Matemáticas Anti-simetria Se A é parte de B, B não pode ser de A Transitividade Se C é parte de B e B é de A, C é de A

Composição Window Frame 1 * Forma de agregação onde a relação todo-parte é forte (semântica) Partes sem multiplicidade fixa são criadas depois do todo. Após isso, sua existência depende totalmente da do todo, exceto se explicitamente eliminadas Objeto de uma parte só pertence a único todo

Associação Elo que permite um objeto conhecer outro Elo é bi-direcional Pode ter atributos e serviços (classe de associação)

Associações Pessoa Empresa Pessoa Empresa Trabalha para Pessoa Empresa Empregado Pessoa Empresa Empregador EmpregadoEmpregador 1..** Pessoa Empresa

Classe de Associação Pessoa Empresa EmpregadoEmpregador 1..** Função descrição dtContrat... salário

Sub-sistemas Há muitos problemas que são grandes para serem tratados diretamente Devemos então particioná-los em sub- sistemas, reduzindo a complexidade do modelo original em termos dos sub- sistemas criados As partes devem ter interface bem- definida Tal redução usa o conceito de domínio

Domínio Um domínio é um mundo real, hipotético, ou abstrato distinto habitado por um conjunto de objetos (distintos) que se comportam de acordo com regras e políticas que o caracterizam Cada domínio forma um todo distinto mas coeso

Exemplos de Domínio Gerenciamento de companhia aérea está relacionado à aeronaves, rotas e aeroportos, bem como com as políticas que regulam este serviço E GUI com janelas, menus, caixas de diálogos, etc.

Classificações Aplicação Visão do cliente/usuário Serviço Mecanismos genéricos e “utility functions” para suportar o domínio de aplicação Arquitetural Mecanismos genéricos e estruturas para manipular dados/controle do sistema como um todo Implementação Ling de programção, S.O., redes, e bibliotecas

Pontes Dois domínios separados são ligados através de uma ponte Fornecem os meios para os objetos em um domínio usarem os objetos em outro Tendem a ser específicas a aplicações

Organização Sistema pode ser decomposto em sub- sistemas usando a abordagem dividir para conquistar De maneira geral, reduz-se a: Partições verticais Camadas horizontais Combinação das duas

Camadas Horizontais Uma camada fornece serviços e suporte a camada acima e requisita serviços e suporte da camada abaixo Uma camada não pode requisitar um serviço a uma camada acima Cada camada é construída o quão independente for possível Protocolo OSI ou sistema interativo (cliente-servidor)

Partições Verticais Esta abordagem divide o sistema em um conjunto de sub-sistemas fracamente acoplados, cada qual fornecendo um tipo de serviço Em geral pode-se achar as partições verticais analisando cada nível horizontal, de acordo com tarefas mais específicas

Identificando Sub-sistemas As partições surgem admitindo que haja acoplamento entre objetos de mesmo domínio e fraco entre domínios diferentes Se um modelo capturar somente associações e agregações, encontraremos agrupamento de classes (cluster) Cada agrupamento é um sub-sistema em potencial

Agrupamentos C1 Att1 M1 C2 Att2 M2 C3 Att3 M3 C4 Att4 M4 C5 Att5 M5 C6 Att6 M6 Sub-sistema B??? Sub-sistema A???

Teste de Agrupamentos Atribua um nome ao domínio e prepare sua missão (objetivo) Encontre as pontes para este domínio Analise a consistência dos serviços em relação à missão (objetivo) Verifique se é possível trocar este conjunto de objetos por outro com a mesma missão

Documentação

Referências Kruchten, P. The Rational Unified Process: An Introduction. Booch, G. et al. The Unified Modeling Language User Guide. Lee, R. Practical Object-Oriented Development with UML and Java.