ì 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