2. O que é arquitetura de software?
• Nível de projeto preocupado com
• Questões além de algoritmos e estruturas de dados
• Projeto e especificação a estrutura do sistema
• Estrutura de controle global
• Protocolos de comunicação, sincronização
• Acesso a dados
• Atribuição de funcionalidade a elementos de projeto
• Distribuição física de elementos
• Desempenho e escala
3. Onde obter mais informações ...
• ARQUITETURA DE SOFTWARE
• Excelente ponto de partida:
• www2.umassd.edu/SECenter/SAResources.html
4. O que não é?
• Não é projeto “detalhado”
• Não é projeto de algoritmos
• Não é implementação
• Não é o modelo de dados
• Usa para assinatura de interfaces
• Não é o sistema físico (processadores, rede, ...)
• Usa para impacto de desempenho, confiabilidade, ...
• Não é a arquitetura de hardware
5. Representação
• Visão
• Descrição simplificada de uma perspectiva
• Construção civil
• Planta baixa
• Projeto elétrico
• Projeto hidráulico, ...
• Construção de software (segundo o RUP: “4+1”)
• Visão de UC
• Visão Lógica
• Visão de processos
• Visão de implementação
• Visão de implantação
6. Visões de Arquitetura
• Visão de Casos de Uso
• Ucs e cenários que ilustram itens “arquiteturalmente significantes”, riscos
técnicos, ...
• Visão lógica
• Classes + relevantes organizadas em subsistemas, packages e estes em
camadas. Realizações de Ucs.
• Visão de implementação
• Organização de componentes, executáveis, fontes,...
• Visão de processos
• Configuração e interação entre processos e threads
• Visão de implantação
• Alocação de tarefas a nós físicos, interação entre estes
7. Arquitetura concentra-se ...
• Na estrutura (subsistemas, camadas)
• Nos elementos essenciais (UC críticos, classes principais, mecanismos
comuns)
• Em cenários principais (fluxo de controle principal por todo o
sistema)
• Em serviços (captura modularidade, elementos opcionais, ...)
Visões de arquitetura são abstrações de todo o projeto
8. Por que é importante?
• Evolução do sistema
• Reutilização da arquitetura ou parte
• Avaliação de desempenho, disponibilidade, ...
• Organização do trabalho de construção
• Decisões acerca aquisição de componentes existentes
• Inserção em um sistema maior
9. Como descrever em UML?
• Visão lógica
• Diagramas de classes, DTEs e diagramas de objetos
• Visão de processos
• Diagramas de classes e objetos (processos,threads)
• Visão de implementação
• Diagramas de componentes
• Visão de implantação
• Diagramas de implantação
• Visão de casos de uso
• Diagramas de ucs, atores, diagramas de seqüência.
10. Visão de Caso de Uso
• Fornece base para planejamento de iterações
11. Visão de UC (exemplo)
Modelo de Processo
do Negócio
Casos de Uso
Vision Document
(SAD)
Arquitetura do sistema conforme
"percebida" pelos clientes.
Atores
12. Visão de UC
(Modelo de Processo do Negócio)
Aluno não
matriculado
Requisita
matrícula
Comprovante
de Matrícula
Requisicao
Matricula
Avalia Requisicao de
Candidato
Efetua
matrícula
Candidato apto
Requisicao
Matricula
Efetua
matrícula
Avalia Requisição
de Aluno
Aluno
matriculado
Fim de período
Requisita
matrícula
Comprovante
de Matrícula
[ aluno apto? ]
[ aluno inapto? ]
Fulano : Aluno (from Criar Programa)Sistema (from Criar Programa)Candidato (from Criar Programa)
15. Visão de processos
• Base para compreensão da organização de processos
NetScape 6.0
<<thread>>
Internet Explorer 5.5
<<thread>>
Apache Server
(from Software)
Browser
<<thread>>
1 n1 n
<<http>>
16. Refinamento da Visão de Processos
CORBA Server
(from Software)
JVM
(from Software)
JMS broker
(from Software)
Java Plug-In 1.3
<<thread>>
NetScape 6.0
<<thread>>
Internet Explorer 5.5
<<thread>>
Browser
<<thread>>
Apache Server
(from Software)
1 n1 n
<<http>>
Database
(from Software)
1
1
1
1
Servidor de Aplicação
<<process>>
1
n
1
n
Beans
(from beans)
<<thread>>
17. Visão de implantação
• Base para compreensão da distribuição física do sistema entre nós
Servidor SISPG
preemptive
Servidor Apache
Banco de Dados
Servidor de Aplicações Java
Coordenação de
Programa
Laser Printer
<<UFGNet>>
Câmera
Digital
Impressão de
DiplomasImpressora
de Diplomas
Navegante
<<Internet>>
Usuário
<<Internet>>
Servidor
CCPFJ
<<UFGNet>>
<<UFGNet>>
18. Desenvolvimento de
Arquitetura de Software
• Como produzir uma arquitetura de software?
• Como obter as visões de arquitetura?
• Quando ocorre?
• Quais as tarefas?
• Qual o processo?
• Quais os artefatos?
• ...
19. Quando ocorre?
• (após)
Requisitos (gera entrada para A&P)
• (início) Análise & Projeto
• Transformar req em projeto
• Obter uma arquitetura robusta
• (durante)
Fase de elaboração
Concepção
20. Quais as tarefas?
• Definir arquitetura candidata
• Criar uma versão inicial da arquitetura
• Definir elementos de arquitetura significantes
• Definir camadas e organização do sistema
• Definir realizações de casos de uso
• Identificar classes de análise
• Refinar a arquitetura
• Identificar elementos de projeto daqueles de análise
• Manter consistência e integridade da arquitetura
• Descrever elementos de implantação e execução do sistema
• Organizar o modelo de implementação
23. Definir arquitetura candidata
• Compreende
• Análise de arquitetura
• Análise de casos de uso
• Processo
• Após início com a análise de arquitetura
• Escolha casos de uso significantes
• Realize a análise de casos de uso em cada UC
• Atualize a arquitetura concomitantemente
24. Análise de Arquitetura
• Desenvolver visão geral da arquitetura
• Definir organização de subsistemas (high-level)
• Identificar mecanismos de análise
• Identificar abstrações principais
• Criar realizações de casos de uso
• Desenvolver modelo de implantação (high-level)
• Revisar resultados
1Definirarquiteturacandidata
INCLUI:
25. Análise de Casos de Uso
• Suplementar descrições de casos de uso
• Identificar classes de análise
• Distribuir comportamento em classes de análise
• Descrever responsabilidades
• Descrever atributos e associações
• Estabelecer associações entre classes
• Descrever dependências de eventos entre classes
• Avaliar resultados
1Definirarquiteturacandidata
INCLUI:
26. Visão geral da arquitetura
• Objetivo
• Explorar e avaliar opções de arquitetura
• Fornecer compreensão de alto nível da estrutura
• Pode ser criada cedo (fase de concepção)
• Reflete decisões e suposições acerca da implementação da Visão
• Decisões acerca da arquitetura lógica e física
• Ilustra “essência” da solução proposta
• Fornece “grandes blocos”
1.1AnálisedeArquitetura
28. Definir organização de subsistemas
• Objetivo
• Criar estrutura inicial para o modelo de projeto
• Modelo de projeto
• Geralmente organizado em camadas
• Neste ponto, focalize as camadas de aplicação e a camada específica ao
negócio
1.1.1AnálisedeArquitetura
30. Visão Lógica (Presentation Layer)
1.1.1AnálisedeArquitetura
Browser Java Applet
HTTP
<<provider>>
(from Business)
HTML Pages
Server Pages
(from Business)
IIOP
<<provider>>
(from Business)
JavaScript
XML docs
31. Visão Lógica (Business Objects Layer)
• Sabe-se que as interfaces CNPQ e CAPES são utilizadas por um
subconjunto dos objetos
• Na visão de implementação teremos componentes que
implementam estas interfaces
1.1.1AnálisedeArquitetura
32. Visão Lógica (Business Objects Layer)
1.1.1AnálisedeArquitetura
HTTP
<<provider>>
Web Server Server Pages
Application Server
<<provider>>
IIOP
<<provider>>
JavaBeans Mapeamento
Persistência
(from Data)
Business
Objects
CAPES
(from Logical View)
CNPQ
(from Logical View)
34. Identificar mecanismos de análise
• Identificação de padrões
• Persistência, gerência de transação, ...
• Identificar problemas possivelmente implícitos
• Não diretamente fornece funcionalidade
• Veja Design Patterns para detalhes.
1.1.1AnálisedeArquitetura
35. Exemplo (mecanismo de análise)
• Persistência (um mecanismo identificado)
• Analysis Patterns
Chapter 12 (Layered Architecture for Information Systems)
Martin Fowler
Addison-Wesley, 1997
• Object-Oriented Modeling and Design for Database Applications
Chapter 13 (Relational Databases: Basics)
Michael Blaha & Wiliam Premerlani
Prentice-Hall, 1998
• Mostra como implementar modelos orientados a objetos com bancos de dados
relacionais.
1.1AnálisedeArquitetura
36. Exemplo (observer pattern)
• Objeto deve notificar outros sem conhecer quem são estes outros
• Enviar e-mail após alteração, ...
1.1AnálisedeArquitetura
37. Identificar abstrações principais
• Identificar classes de análise oriundas de ...
• Requisitos
• Glossário
• Defina relacionamentos entre as classes
• Em geral, vários diagramas são utilizados
• Durante o projeto, tais classes sofrerão alterações
Poderão se tornar “classes”
• QUAL O OBJETIVO?
• Identificar “conceitos principais” que o sistema manipulará
• Ao analisar UCs outras classes e relacionamentos surgirão
1.1AnálisedeArquitetura
38. Exemplo (abstrações principais)
1.1AnálisedeArquitetura
ItemCalendárioCalendário
1..n1..n
Atividade
ncreditos
nome : String
TipoDisciplina
tipo
Programa
EstagioDocencia
OutraAtividade
descricao : String
AreaConcentracao
AtividadeCredito
minimo
maximo
obrigatoria
nome
1
n
1
n
Estrutura Curricular
11 11
Disciplina
ementa
1..n 1..n1..n 1..n
Classifica
nn
Executa
periodo
conceito
frequencia
Aluno
(from Academia)
n nn n
Requerimento Comprovante
Documento
Data : Date
Diploma Certificado
Informe
DataInicio : Date
DataFim : Date
39. Criar realizações de casos de uso
• Para cada UC, crie realização do UC
• O nome da realização deve ser o mesmo
• Crie uma dependência da realização para o UC
• É bom lembrar ...
• UC especifica funcionalidade visível externamente
• UC não fornece uma implementação
• Colaboração descreve
• Objetos que implementam o comportamento do UC
• Forma que interagem para obter este efeito
1.1AnálisedeArquitetura
40. Exemplo (realizações de UCs)
1.1AnálisedeArquitetura
Limpar base de informes
(from Informes)
Excluir informe
(from Excluir informe)
Excluir informe
(from Informes)
Editar informe
(from Editar informe)
Limpar base de informes
(from Limpar base de informes)
Criar informe
(from Criar informe)
Consultar informes
(from Consultar informes)
Consultar informes
(from Informes)
Criar informe
(from Informes)
Editar informe
(from Informes)
41. Desenvolver modelo de implantação
• Objetivo
• Visão da distribuição geográfica
• Entendimento da complexidade operacional do sistema
• Insumos
• Usuários (localizações)
• Dados do negócio
• Especificação Suplementar
• Requisitos não-funcionais
• Restrições
• Processo
• Atender usuários, casos de uso, acesso a dados, ...
1.1AnálisedeArquitetura
42. Exemplo (diagrama de implantação)
1.1AnálisedeArquitetura
Servidor
CCPFJ
Servidor SISPG
preemptive
Servidor Apache
Banco de Dados
Servidor de Aplicações Java
Coordenação de
Programa
Laser Printer
<<UFGNet>>
Câmera
Digital
Impressão de
Diplomas
<<UFGNet>>
Impressora
de Diplomas
Navegante
<<Internet>>
Usuário
<<Internet>>
<<UFGNet>>
43. Classe de Análise
• “Coisas” no sistema que possuem
• Responsabilidade
• Comportamento
• Abstração de um papel
• PAPEL: definição de comportamento e responsabilidade
• Pode se referir a mais de um papel
• Evolui em um ou mais elementos de projeto
• Classes
• Subsistemas
1.2AnálisedeUC
44. Classes de Análise (representação)
• Boundary class
• Interação entre ator e sistema
• Control class
• Comportamento específico de um ou mais UCs
• Objetos que controlam outros objetos
• Representa a dinâmica do sistema (fluxo de controle)
• Entity class
• Modela informação e comportamento associado
45. Classes de análise (exemplo)
: Gerencia Informes : Elemento de
Informação
: Tela Informes: Usuário
1: Requisita informes 2: Obtem Informes 3: Obtem descrição
4: Mostra descrição de informes
46. Considerações finais
• Arquitetura de software (item muito importante)
• concepção e ELABORAÇÃO
• Definição do “raio-x da organização do sistema”
• Faz uso de várias visões
• Orienta posteriores atividades de análise & projeto
• Fase de Elaboração
• Protótipo executável da arquitetura pode ser construído
• Provavelmente na primeira iteração
• Arquitetura estável deve ser atingida nesta fase