1

Aspectos,  Perspec,vas,  Viewpoints,  ...    

João  Paulo  A.  Almeida  (jpalmeida@inf.ufes.br)  

Sistema  -‐>  Arquitetura  -‐>  Modelo  

Arquitetura Models

Models

Models

Arquitetura  •  Arquitetura  =  organização  de  um  sistema  em  termos  de  seus:  –  Componentes  (elementos)  –  Propriedades  –  Relações  entre  componentes  –  Princípios  de  organização  

•  Cuidado:  o  termo  é  usado  de  forma  irregular  na  literatura  (por  exemplo  para  falar  dos  níveis  mais  altos  de  abstração,  ou  mesmo  sem  precisão)  

•  Arquitetura  é  “aquilo  sobre  o  que  deveríamos  discu,r”  –  É  o  conteúdo  do  trabalho  do  ‘arquiteto’  

Técnicas  para  lidar  com  a  complexidade  e  instabilidade  da  realidade  •  Abstração    na  arquitetura  

–  Omi,r  detalhes  irrelevantes  –  Diferentes  níveis  de  abstração:  ou  seja,  “irrelevante”  é  rela,vo  

•  Separa,on-‐of-‐concerns  –  Separar  interesses  de  diferentes  stakeholders  em  suas  perspec,vas  

–  Separar  interesses  com  base  na  habilidade  do  ‘arquiteto’  (de  um  stakeholder)  em  raciocinar  sobre  o  sistema:  modularização  

Técnicas  para  lidar  com  a  complexidade  e  instabilidade  da  realidade  •  Uso  de  princípios  arquiteturais  adequados  

–  Ex.  organização  de  arquitetura  em  camadas  –  Pense  em  padrões  de  projeto  arquiteturais  

•  Generalização  –  Iden,ficação  de  caracterís,cas  comuns  –  Permite  separar  variações  

Elementos  de  estruturação  de  arquiteturas  •  Perspec,vas  •  Aspectos  •  Níveis  de  abstração  e/ou  níveis  arquiteturais  •  Views  e  Viewpoints  

•  Frameworks  

2

Perspec,vas,  aspectos,  níveis,  view(points)  •  Todos  termos  implicam  “parcialidade”  (o  oposto  de  “completude”)  

•  Se  é  a  descrição  é  parcial  precisamos  de  relações  entre  os  elementos  da  arquitetura!  

Arquitetura  Organizacional:    domínios  e  relações  

Some  Typical  Stakeholders  •  Client  •  Acquirer  •  Owner  •  User  •  Operator  •  Architect  •  System  Engineer  •  Developer  

•  Designer  •  Builder  • Maintainer  •  Service  Provider  •  Vendor  •  Subcontractor  •  Planner  

http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf

Frameworks  para  arquitetura  •  Frameworks  podem  ser  avaliados  por:  

–  Cobertura  dos  domínios  de  modelagem  –  Adequação  dos  conceitos  usados  para  os  domínios  –  Adequação  dos  aspectos,  perspec,vas,  e  outras  técnicas  de  separa,on-‐of-‐concerns    •  (mesmo  intra-‐domínios)  • níveis  de  abstração  

–  Qualidade  das  relações  entre  os  vários  domínios  

Zachman  framework  

http://www.zifa.com/

Framework  ArchiMate  

M. Lankhorst, H. van Drunen, Enterprise Architecture Development and Modelling Combining TOGAF and ArchiMate, Via Nova Architectura, Março 2007. http://www.via-nova-architectura.org/files/magazine/Lankhorst.pdf

3

Zachman  &  ArchiMate  

http://www.zifa.com/

Histórico:  “Enterprise  Architecture”  •  Assim  como  no  caso  da  arquitetura  de  sonware  surgiu  a  par,r  da  documentação  informal  

•  Conceito  de  “Informa,on  Systems  Architecture”  por    John  Zachman  em  ar,go  de  1987  

•  ARIS  (Architecture  of  Integrated  Informa,on  Systems)  •  DoDAF  (Department  of  Defense  Architectural  Framework)  /  MODAF  (Inglaterra)  

•  RM-‐ODP  (Reference  Model  for  Open  Distributed  Processing)  

•  TOGAF  (The  Open  Group  Architecture  Framework)  •  ArchiMate,  padrão  do  The  Open  Group  

RM-‐ODP  

system

•  Sistema  visto  por  diferentes  perspec,vas:  viewpoints  

  Enterprise   Information   Computational   Engineering   Technology

V1 V2 V3 V4 V5

A parte de RM-ODP inclui slides de Luís Ferreira Pires, usado com permissão

Viewpoints  •  Cada  viewpoint  tem  propósito  •  Cada  viewpoint  traz  seus  conceitos  •  Viewpoints  estão  relacionados  

Enterprise  viewpoint  •  Obje,vo   Definir  o  propósito,  escopo  do  sistema  (em  termos  do  negócio  ao  qual  o  sistema  dá  apoio)   Quais  são  os  serviços  que  o  sistema  oferece  para  o  ambiente?   Como  ele  se  comunica  com  outros  sistemas?  

 Definir  o  papel  do  sistema  e  dos  usuários  e  definir  as  regras  (de  negócio)  que  se  aplicam  ao  sistema   O  que  é  feito  pelo  sistema  e  o  que  é  feito  pelos  usuários?   Quais  são  as  polí,cas  ou  regras  do  negócio  que  se  aplicam  ao  sistema?  

4

Enterprise  viewpoint  (exemplo)   Enterprise  viewpoint  (cont.)    Exemplos  de  requisitos  não  funcionais  fundamentados  no  negócio   Escalabilidade    

 Se  o  negócio  crescer,  como  podemos  planejar  a  capacidade  do  sistema  para  atender  à  demanda?  (o  banco  vai  crescer,  e  mais  terminais  de  atendimento  vão  ser  criados)  

 Vazão  (throughput)   Quantas  declarações  de  imposto  de  renda  são  processadas  por  dia?  

 Autorização   Quem  pode  fazer  o  que  no  sistema?  

 Segurança  (Confidencialidade,  Integridade,  Disponibilidade)   Quanto  vale  a  informação  para  outros?   Qual  o  prejuízo  de  se  perder  tais  informações?   Qual  o  prejuízo  do  sistema  ficar  indisponível  (o  sistema  caiu…)?  

  Conceitos  do  Enterprise  Viewpoint  incluem  agentes  (objetos),  artefatos,  processos,  obje,vos,  papéis,  polí,cas  (obrigação  e  proibiçoes),  comunidades  e  federação  

Informa,on  viewpoint  •  Obje,vo   Definir  os  objetos  de  informação  do  sistema  e  seus  relacionamentos    Em  terms  de  objetos,  regras  (invariantes,  regras  de  derivação)  e  schemas    Pensem  em  análise  orientada  a  objetos  e  projeto  de  dados  

Computa,onal  viewpoint  •  Obje,vo   Definir  a  decomposição  lógica  do  sistema  em  termos  de  objetos  que  interagem  através  de  interfaces   Abstraindo  da  localização  e  das  tecnologias  

 A  visão  da  aplicação  que  temos  normalmente  com  middleware!  

  Em  termos  de  objects,  interfaces,  interface  bindings,  etc.    Pense  em  projeto  em  vários  níveis  de  abstração  

Computa,onal  x  Informa,on  Viewpoints  •  Relação  

Engineering  Viewpoint  •  Obje,vo   Definir  os  mecanismos  e  as  funções  que  são  necessárias  para  apoiar  interações  (distribuídas)  entre  objetos   Perspec,va  do  projeto  de  soluções  de  integração  em  si!  

  Em  termos  de  objects,  channels,  stubs,  binders,  protocol  objects,  nodes,  clusters  e  capsules  

5

Engineering  Viewpoint   Computa,onal  and  Engineering  Viewpoints  

Object 1 Object 2

Computational viewpoint

Object 1 Object 2

Stub Stub

Binder Binder

Protocol Protocol Interceptor

Engineering viewpoint

Engineering  Viewpoint   RM-‐ODP  •  Neutro  com  relação  a  linguagens  

– Mas  existe  um  padrão  para  o  uso  de  UML  para  representar  os  viewpoints  

•  Neutro  com  relação  a  metodologias  

4+1:  Philippe  Kruchten,  Ra,onal  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

The logical view, which is the object model of the design (when an object-oriented design method is used), • the process view, which captures the concurrency and synchronization aspects of the design, • the physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect • the development view, which describes the static organization of the software in its development environment. The description of an architecture—the decisions made—can be

organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view.

Logical  View  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

6

Process  View  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

Development  View  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

Physical  View  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

Relação  

Fonte: Architectural Blueprints—The “4+1” View Model of Software Architecture IEEE Software 12 (6), November 1995, pp. 42-50

4+1  •  Foco  na  arquitetura  de  sonware  •  Framework  é  neutro  com  relação  a  linguagens  

–  Exemplicado  com  Booch  (e  atualmente  UML)  •  Mas  já  é  tendencioso  com  relação  a  metodologia  

IEEE  1471  

7

Viewpoints  em  Archimate  

From Archimate Resource Tree http://www.telin.nl/NetworkedBusiness/Archimate/ART/index.html (based on ideas in Schönhage, B. & Eliëns, A. (1998))

View:  Conteúdo  e  Apresentação  

1º  trabalho  •  Iden,ficar  na  literatura  definições  para:  

– Modelo  –  Visão  (view  e  viewpoint)  –  Diagrama  –  Aspecto  –  Perspec,va  –  Níveis  de  abstração  

•  E  iden,ficar  possíveis  técnicas  para  relacionar  esses  elementos  de  estruturação  de  arquiteturas  (concentre-‐se  em  views  e  viewpoints,  aspectos,  perspec,vas,  e  níveis  de  abstração)