Engengaria de Software II 2 - Análise, Projeto e Arquitetura

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE PARA 
SI II
Análise, Projeto e 
Arquitetura de Software
Profa. Dra. Adicinéia Aparecida de Oliveira
2015/2
Roteiro 
 Análise e Projeto.
 Introdução à Arquitetura de Software.
 Estilos arquitetônicos.
 Tipos de arquitetura.
Motivação
“A parte mais árdua na construção de um sistema de
software é decidir o que construir. Nenhuma outra parte
do trabalho compromete mais o sistema se for feito de
forma imprópria. Nenhuma outra parte é mais difícil de
corrigir a posteriori”. 
F. P. Brooks Jr, 
“No Silver Bullet: Essence and Accidents 
in Software Engineering”, IEEE Computer.
“Se tivesse seis horas para cortar uma árvore, 
gastaria as primeiras quatro afiando o 
machado.” 
A. Lincoln
Introdução
Metodologias de desenvolvimento 
de sistemas
 Metodologia
 Dissertação sobre a maneira de se utilizar um conjunto de 
métodos para atingir um objetivo, de modo que se evite a 
subjetividade na execução do trabalho.
 Método
 Procedimento (conjunto de técnicas) a ser adotado para se 
atingir um objetivo.
 Técnica
 Modo apropriado de se investigar sistematicamente um 
determinado universo de interesse ou domínio de um 
problema. (faz uso de uma notação).
 Notação
 Conjunto de caracteres, símbolos e sinais formando um 
sistema convencionado de representação.
Conceitos
 Análise
 Descoberta (elicitação), modelagem, estudo ... de 
algo que já existe no mundo real.
 Projeto 
 Concepção detalhada de algo que ainda não existe, 
com o objetivo de construir esse algo.
 Termo com dois significados. Inglês: design (cf. 
project). Português: projeto ou desenho (cf. projeto 
(atividade) e projeto (resultado da atividade).
Análise e Projeto
Análise — “o quê”
Investigação do problema e 
dos requisitos
Requisitos
Casos de uso
Restrições
Vocabulário
Projeto — “como”
Descrição de uma solução 
lógica
Objetos
Arquitetura
Instalação & Operação
Interface do usuário
 Termos “Análise” e “Projeto” não são fixos, 
mas usados ao longo de um contínuo.
 Significados variam de metodologia para 
metodologia.
 Distinção é útil na prática, mas debater 
definições rígidas não é construtivo.
Conflito de terminologias
Mais orientado
a análise
Mais orientado 
a projeto
Objetivos da Análise
 Especificação de requisitos mais precisa.
 Descrita usando linguagem de 
desenvolvedores.
 Proporciona maior entendimento, facilidade de 
mudanças e manutenções.
 Primeiro passo para o modelo de projeto.
 Primeiras interações da fase de elaboração.
Princípios de Análise
1. O domínio da informação de um problema precisa ser 
representado e entendido (Domínio da informação).
2. As funções a serem desenvolvidas pelo software devem 
ser definidas (Modelagem Funcional). O comportamento 
do software precisa ser representado (Modelagem 
Comportamental).
3. Os modelos que mostram informação, função e 
comportamento devem ser particionados
(Particionamento).
4. O processo de análise deve ir da informação essencial 
até o detalhe de implementação (Visão Essencial e de 
Implementação).
Modelagem
Modelos Funcionais- o software transforma a informação, assim 
precisa realizar 3 funções: entrada, processamento e saída.
Modelos Comportamentais – são formados pela característica de 
estímulo/resposta (estado que o sistema está)
Para que servem?
 auxilia o analista no entendimento da informação, função e 
comportamento de um sistema;
 é o foco para as revisões  completeza, consistência e precisão 
das especificações;
 base para o projeto (essência mapeada para a implementação).
Modelagem de sistemas
 Modelo funcional
 Perspectiva das funções do sistema
 Modelo de dados
 Perspectiva dos dados do sistema
 Modelo de controle
 Perspectiva dos controles de estados do sistema
Modelo de Análise
Objetivos:
 descrever o que o cliente deseja;
 estabelecer uma base para a criação de um 
projeto de software;
 definir um conjunto de requisitos que pode ser 
validado quando o software for construído.
Metodologias de desenvolvimento 
de sistemas
 Uma boa metodologia deve definir:
 As fases de trabalho a serem adotadas (ciclo de vida).
 Quem faz o quê, quando e como.
 O papel dos técnicos, dos usuários e dos gerentes.
 Pontos de controle e verificação.
 Níveis de qualidade.
 Um conjunto de padrões pré-estabelecidos.
 Evitar o problema dos “donos do sistema”.
As técnicas é que devem ser estáveis e não os técnicos.
Metodologias de desenvolvimento 
de sistemas
 A metodologia deve definir quais as fases do trabalho.
 Para cada fase, quais as técnicas:
 Análise estruturada, análise essencial, análise OO, análise OA...
 Para cada técnica, quais as ferramentas:
 DFD, DER, DTE, Diagrama de contexto...
 Para cada ferramenta, quais modelos:
 Modelo funcional, modelo de dados, modelo de controle...
Modelagem de sistemas
Classificação importância dos modelos na especificação do 
sistema:
 Centrado nas funções
 Maior preocupação nas funções.
 Centrado nos dados
 Maior preocupação nos dados e seus relacionamento.
 Centrado nos controles
 Maior preocupação nos controles do sistema.
Nos sistemas de informações administrativos as principais 
perspectivas estão nos dados e nas funções.
Abordagens da análise
 Método Estruturado;
 Método Essencial;
 Método Orientado a Objetos;
 Método Orientado a Agentes;
 Método Orientado a Aspectos...
Metodologias
Metodologias
Estruturada e Essencial x OO
 Nos métodos de análise estruturada e 
essencial, o comportamento do sistema e seus 
dados são considerados separadamente.
 Na orientação a objetos, comportamento e 
dados são integrados, encapsulando detalhes 
internos de um objeto.
Estruturada e Essencial x OO
Projeto do Software 
 Inicia a conversão da especificação em um 
sistema executável, projetando um Software a 
implementará.
 Define:
 a Arquitetura
 a Interface 
 os Componentes
 as Estruturas de Dados
 os Algoritmos
Projeto de Software
 Primeira das 3 atividades técnicas: projeto, 
geração de código e teste.
 O projeto é o lugar onde a qualidade é 
fomentada durante o processo de 
desenvolvimento.
 Transforma a informação do modelo de 
domínio (análise) em estruturas que requerem 
ser implementadas no software.
Projeto de software
 Segundo SWEBOK – É o processo de 
definição da arquitetura, dos componentes, da 
interface e de outras características dos 
componentes do sistema e do resultado 
esperado, para resolver o problema 
identificado na fase de requisitos.
 Como será feito! 
Projeto de software
 A essência do projeto de software é tomar 
decisões sobre a organização lógica do 
software.
 Grandes sistemas – vários subsistemas.
 O processo inicial de projeto identificar esses 
subsistemas e estabelecer um framework para 
o controle e a comunicação de subsistemas –
projeto de arquitetura.
Importância do Projeto
 O projeto fornece representações do 
software que podem ser avaliadas quanto à 
qualidade.
 É a única maneira pela qual pode-se traduzir 
com precisão os requisitos de um cliente num 
produto de software acabado.
Requisitos críticos
 O estilo e a estrutura específicos escolhidos 
para uma aplicação podem, depender dos 
RNF do sistema.
 Desempenho.
 Proteção.
 Segurança.
 Disponibilidade.
 Facilidade de manutenção.
 Obviamente há conflitos potenciais entre 
algumas dessas arquiteturas.
Resumindo...
 Uma especificaçãode requisitos pode ser 
satisfeita por vários projetos.
 Um projeto pode ser satisfeito por várias 
implementações.
 Algo que não é especificado ou projetado, é 
satisfeito por qualquer implementação!
Decisões de projeto de 
arquitetura
 Existe uma arquitetura genérica?
 Como o sistema será distribuído ao longo de vários 
processadores?
 Qual ou quais estilos de arquitetura são apropriados para o 
sistema?
 Qual será a abordagem fundamental usada para estruturar o 
sistema?
 Como as unidades estruturais de um sistema são decompostos em 
módulos?
 Qual estratégia será usada para controlar a operação das unidades 
no sistema?
 Como o projeto de arquitetura será avaliado?
 Como a arquitetura do sistema deve ser documentada?
Produto do projeto de 
arquitetura
 Documento de projeto de arquitetura que pode 
incluir várias representações gráficas do 
sistema junto com texto descritivo associado. 
Pode incluir:
 Um modelo estático de estrutura.
 Um modelo dinâmico de processo.
 Um modelo de interface.
 Modelos de relacionamentos.
 Um modelo de distribuição.
Arquitetura
 O termo arquitetura é utilizado aqui para 
descrever os atributos de um sistema da 
forma como é visto pelo programador, isto 
é, sua estrutura conceitual e seu 
comportamento funcional, ao contrário da 
organização do fluxo de dados e controles, 
do projeto lógico e da implementação 
física.
 IBM SYSTEMS JOURNAL, 1964
Arquiteturas de Software
 “Descobrimos que compreender a arquitetura 
de software é a chave do desenvolvimento de 
muitas soluções de software importantes.” 
Peters, 1991
 São consideradas no início de um processo 
de projeto de software. 
 Esta etapa começa com a seleção das 
arquiteturas e dos elementos arquitetônicos.
Concepções errôneas sobre a 
arquitetura…
 Arquitetura é somente um papel.
 Arquitetura e projeto são as mesmas coisas.
 É minha tecnologia preferida.
 Arquitetura não pode ser medida ou 
validada.
 Arquitetura é simplesmente a estrutura.
 Arquitetura é uma arte.
O que é arquitetura de 
software?
“Consiste de elementos arquiteturais, as 
interações entre estes elementos, e as 
restrições sobre estes elementos e sobre 
as suas interações.” [Perry 92]
O que é arquitetura de 
software?
“Arquitetura de software é a estrutura de um 
programa ou um sistema, seus 
relacionamentos e os princípios que guiam o 
seu projeto e a sua evolução no tempo.” 
[Garlan 95]
O que é arquitetura de 
software?
 Estabelece o contexto para o design e 
implementação.
 Decisões arquiteturais são as mais 
significantes.
CÓDIGO
IMPLEMENTAÇÃO
DESIGN
ARQUITETURA
O que é arquitetura de 
software?
 Arquitetura também envolve…
 Funcionalidade.
 Usabilidade.
 Desempenho.
 Reuso.
 Facilidade de compreensão.
 Restrições.
 Equilíbrio de fatores econômicos e tecnológicos.
Qual a importância?
1) Integridade e Qualidade.
2) Controle da Complexidade.
3) Previsibilidade.
4) Testabilidade.
5) Reuso.
6) Comunicação.
7) Organização e Gerência de Projetos.
8) Evitar ou Reduzir custos.
Visões da Arquitetura
Visões da Arquitetura
 Múltiplas realidades, múltiplos interessados com 
visões distintas e que precisam de 
visualizações diferentes.
 Exemplos de Stakeholders interessados:
 Usuário Final.
 Gerente de Projeto.
 Desenvolvedor.
 Arquiteto.
 Testador.
 Outros Sistemas.
Visões da Arquitetura
Visão de 
Implementação
Visão
Lógica
Visão de 
Distribuição
Visão de 
Processos
Visão de Casos 
de Uso
Analista de 
Sistemas
Funcionalidade
Programadores
Arquiteto
Escalabilidade,
Performance,
Eficiência
Topologia, 
Implantação, 
comunicação
Arquiteto
Estrutura, 
componentes
Arquiteto
Visões da Arquitetura
 Visão Lógica
 Retrato estático dos relacionamentos existentes 
entre as entidades do sistema.
 Foca nas funcionalidades e abstrações chaves.
 Pode possuir duas ou mais abstrações:
 Modelo conceitual;
 Esquema de banco de dados.
 Utiliza da UML:
 Diagrama de pacotes (partições maiores);
 Diagrama de classes (elementos significativos);
 Diagramas de Interação.
Visões da Arquitetura
 Visão de Processos: 
 Descreve aspectos de sincronização e 
concorrência.
 Descrição dos processos concorrentes.
 Foca em performance, escalabilidade e eficiência.
 Utiliza da UML:
 Diagrama de classes usando os esteriótipos 
<<process>> e <<threads>>.
 Diagramas de Atividades e Interação.
Visões da Arquitetura
 Visão de Implementação
 Foca nos componentes que serão utilizados e no 
ambiente de desenvolvimento.
 Utiliza da UML:
 Diagrama de classes (detalhado).
 Diagrama de componentes.
Visões da Arquitetura
 Visão de Distribuição: 
 Topologia dos sistemas de hardware onde o 
sistema executa.
 Distribuição dos componentes.
 Verificação da disponibilidade, confiabilidade e 
desempenho.
 Utiliza da UML:
 Diagrama de Implantação.
 Diagrama de componentes.
Visões da Arquitetura
 Visão de Casos de Uso 
 Descreve o comportamento do sistema sobre a 
ótica dos usuários.
 Utiliza da UML:
 Diagrama de Caso de Uso.
 Diagrama de Atividades.
 Diagrama de Estados.
Visões da Arquitetura
 Nem todos os sistema requerem todas as 
visões…
 Pequeno programa (ignora implementação).
 Única máquina (ignora distribuição).
 Outros requerem visões adicionais…
 Visão dos Dados.
 Visão de Segurança.
Como definir a arquitetura?
 Definindo quais padrões utilizar…
Estilo Arquitetural
Padrões de Design
Idiomas
Elementos Arquitetônicos
 Processamento – Estruturas de software que 
transformam as entradas em saídas 
necessárias.
 Dados – Informações utilizadas no 
processamento ou informações a serem 
transformadas pelos elementos de 
processamento.
 Conexão – Elementos que são o amálgama 
que une as diferentes partes de uma 
arquitetura.
Processo do Projeto
 Deve fornecer uma estrutura interna clara para 
o software seja:
 Relativamente simples;
 Flexível;
 Extensível;
 Portável; e,
 Reutilizável.
Estilos Arquitetônicos
 Um estilo arquitetônico se caracteriza por:
 Tipos de componentes
 Elementos de processamento utilizados para transformar 
dados.
 Tipos de conectores
 Caminhos de controle e de dados entre os componentes.
 Restrições
 Quanto ao processamento, dados e formas permitidas para se 
unirem os componentes eletronicamente.
Modelos e estilos 
(Sommerville)
 Modelos de Arquitetura:
 Modelo de estrutura.
 Modelo de controle.
 Modelo de decomposição.
 Modelos 
Organizacionais:
 Modelos de repositórios.
 Modelos cliente-servidor.
 Modelos de máquina 
abstrata.
 Estilos de 
Decomposição: 
 Orientada a objetos.
 Orientada a funções.
 Modelos de Controle:
 Controle centralizado.
 Controle baseado em 
eventos.
 Arquiteturas de 
Referência
 Modelos genéricos.
 Modelos de referência 
Tipos de Arquiteturas
 Fluxo de Dados.
 Chamada e Retorno.
 Independente do Processo.
 Máquina Virtual.
 Repositório – Centrado nos Dados.
 Específica para o domínio.
Estilos Arquiteturais
 Fluxo de Dados
 Batch (Sequencial) – Processamento em lotes.
 Pipes and Filters (Tubos e Filtros).
 Controle de Processo.
 Criptógráfico.
 Chamada Retorno
 Programa Principal/Subrotina.
 Invocação Remota de Procedimento – Orientada a 
procedimentos.
 Camadas (Layered).
 Orientadaa objetos.
Estilos Arquiteturais
 Independente do processo ou Componentes 
Independentes
 Processos de comunicação.
 Sistema de evento-ação - Baseados em Eventos.
 Sistema distribuído.
 Processos paralelos.
 Agente.
Estilos Arquiteturais
 Máquina Virtual
 Interpretadores.
 Sistemas inteligentes.
 Sistema baseado em Regras.
 Máquina Abstrata.
 Química (MAC).
 Centrado nos Dados
 Repositório – Banco de Dados.
 Quadro Negro.
 Hipertexto.
 Arquivístico.
Estilos Arquiteturais
 Específica para o Domínio
 Xadrez (Deep Blue da IBM).
 Dama (Chinook).
 Orientada à Genética.
 Orientada a redes neurais.
Estilos Arquiteturais
 Fluxo de Dados
 O sistema realiza uma série de transformações 
sucessivas sobre uma cadeia de dados.
 A meta é reuso e modificabilidade.
Estilos Arquiteturais
 Fluxo de Dados > Batch
 Programas independentes executados em 
sequência.
 Dado transmitido por completo entre um 
programa e outro.
Jar JavaJavac
class{
}
Arquivos fonte
A$n3*
3N4*#
Bytecode
000
1001
1001
Arquivo Jar
executandoEmpacotandoCompilando
Estilos Arquiteturais
 Fluxo de Dados > Pipes and Filters
Código 
fonte Analisador
Léxico
Analisador
Sintático
Analisador
Semântico
Gerador de
código
intermediário
Otimizador
Intel backend
MIPS backend
SPARC backend
tokens Árvore sintática Árvore sintática c/ semântica
ExecutávelExecutável otimizado
Estilos Arquiteturais
 Fluxo de Dados > Pipes and Filters
 Trasnformação sequencial dos dados, efetuados 
por vários componentes (filtros) em sucessão.
 Os filtros realizam o processamento dos dados 
de entrada.
 Pipes conectam os filtros, transmitido os dados 
de saída de um filtro para as entradas de outro.
Estilos Arquiteturais
 Fluxo de Dados > Pipes and Filters
 Dificuldade para interatividade e cooperação 
entre os filtros.
 Baixa performance
 Melhorada através de buffers ou paralelização do 
sistema.
Estilos Arquiteturais
 Chamada Retorno
 Criam sistemas modificáveis e escaláveis.
 Maior parte dos sistemas utilizam essa 
abordagem.
Estilos Arquiteturais
 Chamada Retorno > Programa 
Principal/Subrotina
Programa principal
Subrotina 3Subrotina 1 Subrotina 2
Estilos Arquiteturais
 Chamada Retorno > Programa 
Principal/Subrotina
 Reutilização de subrotinas.
 Desenvolvimento independente de subrotinas.
Estilos Arquiteturais
 Chamada Retorno > Invocação Remota de 
Procedimento
Programa principal
Subrotina 1 Subrotina 2
192.168.10.11
Subrotina 3
192.168.10.8
Estilos Arquiteturais
 Chamada Retorno > Invocação Remota de 
Procedimento
 Subrotinas executam em outras máquinas 
conectadas a rede.
Estilos Arquiteturais
 Chamada Retorno > Camadas (Layered)
Aplicação
Apresentação
Sessão
Transporte
Rede
Dados
Física
Apresentação
Negócio
Armazenamento
ISO-OSI
Clássica
3 camadas
Estilos Arquiteturais
 Chamada Retorno > Camadas (Layered)
 Camadas se comunicam apenas com as 
camadas adjacentes.
 Alterações locais não são propagadas.
Estilos Arquiteturais
 Componentes Independentes > Comunicação 
de Processos
 Baseado na comunicação via troca de 
mensagens entre processos.
 Em geral via rede.
 Cliente – Servidor.
 Ponto-a-Ponto.
Estilos Arquiteturais
 Componentes Independentes > Comunicação 
de Processos > Cliente Servidor
Clientes
Servidor
Aplicação: Internet
Estilos Arquiteturais
 Componentes Independentes > Comunicação 
de Processos > Cliente Servidor
 Alta dependência do servidor pode ser um 
grande problema.
Estilos Arquiteturais
 Componentes Independentes > Comunicação de 
Processos > Ponto-a-Ponto
 Não há distinção entre nós.
 Cada nó é cliente e servidor ao mesmo tempo.
 Cada nó mantém seus próprios dados e endereços 
conhecidos.
Estilos Arquiteturais
 Componentes Independentes > Baseados em 
Eventos
 Produtores e consumidores independentes.
 Procedimentos disparados via mudança de 
estado.
 Escalabilidade no número de interessados.
menuDown
onMouseOver
onMouseClick
onMousePressed
onMouseReleased
onKeyUp
Estilos Arquiteturais
 Máquina Virtual > Interpretador
 Simular funcoinalidade não-nativa para 
obter portabilidade.
public class Oi{
...
}
Arquivo “Oi.java”
Compilador Java
“javac.exe”
Êþº¾ 1 � � � <init>� �()V� 
�Code� �LineNumberTable�
�main� �([Ljava/lang/String;)...
Arquivo “Oi.class”
bytecode
Máquina
Virtual
Máquina
Virtual
Máquina
Virtual
Máquina
Virtual
Máquina
Virtual
INTERPRETA
Estilos Arquiteturais
 Máquina Virtual > Baseado em Regras
 Conjunto de regras sobre um estado.
 Definição do estado atual com base em dados de 
entrada.
 Regras alteram o estado.
Estilos Arquiteturais
 Máquina Virtual > Baseado em Regras
 Exemplo: Prolog, Sistemas Especialistas.
SE “HORA=21:00” 
ENTÃO “AÇÃO=LANCHE”
SE “HORA=22:00”
ENTÃO “AÇÃO=LIBERAR”
SE “HORA<19:00”
ENTÃO “AÇÃO=ESPERAR”
SE “HORA=19:00”
ENTÃO “AÇÃO=COMEÇAR”
HORA = ?
AÇÃO = ?
Máquina de
inferência
HORA=18:00
Base de Regras
Memória de trabalho
Estilos Arquiteturais
 Centrado nos Dados > Repositório
 Clientes operam sobre os dados.
 Integridade dos dados.
 Maior escalabilidade para incluir novos clientes.
Dados 
compartilhados
Cliente 1
Cliente 2
Cliente 3
Cliente n
Estado atual
consistente
Estilos Arquiteturais
 Centrado nos Dados > Quadro Negro
2 x (3+2)2 + 3 - 6 = ?
Sei somar!
Sei multiplicar!
Sei subtrair!
Sei 
exponencial!
+
-x
Controlador
Estilos Arquiteturais
 Centrado nos Dados > Quadro Negro
Quadro Negro
Ap 4
Ap 5
Ap n
Ap 3
Ap 2
Ap 1
Controlador
Estilos Arquiteturais
 Centrado nos Dados > Quadro Negro
 Sistemas complexos
 Resolução distribuída de problemas.
 Aplicações independentes
 Escalabilidade.
 Grande problema se ocorrer falhas no quadro 
negro.
 Bastante utilizada no paradigma de agentes.
Arquiteturas de referência
 Os modelos de arquitetura podem ser específicos para 
algum domínio de aplicação.
 Existe dois tipos de modelos de domínio específico
 Modelos genéricos que são abstrações de uma série de 
sistemas reais que englobam as caracterísiticas principais 
desses sistemas. Abordados no Capítulo 13.
 Modelos de referência são mais abstratos, é um modelo 
idealizado. Fornece um meio de informação sobre essa classe 
de sistema e sobre comparação de arquiteturas diferentes.
 Os modelos genéricos são geralmente modelos bottom-
up. Os modelos de referência são modelos top-down.
Arquiteturas de referência
 Os modelos de referência são derivados de 
um estudo de domínio de aplicação ao invés 
de sistemas existentes.
 Pode ser usado como base para a 
implementação de sistemas, ou comparar 
sistemas diferentes. Atua como um padrão 
contra o qual os sistemas podem ser 
avaliados.
 O modelo OSI é um modelo de camadas para 
sistemas de comunicação.
Modelo de referência OSI
Modelo CASE de referência 
 Serviços de repositório de dados
 Armazenamento e gerenciamento de itens de dados.
 Serviços de integração de dados
 Gerenciamento de grupos de entidades.
 Serviços de gerenciamento de tarefas
 Definição e aprovação de modelos de processo.
 Serviços de mensagens
 Comunicação ferramenta-ferramenta e ferramenta-ambiente.
 Serviços de interface de usuário
 Desenvolvimento de interfacede usuário.
O modelo de referência ECMA
Modelos de arquitetura
 Modelos diferentes de arquitetura podem ser 
produzidos durante o processo de projeto.
 Cada modelo apresenta perspectivas 
diferentes sobre a arquitetura.
Atributos de arquitetura
 Desempenho
 Localizar operações críticas e minimizar comunicações.
 Proteção
 Usar uma arquitetura em camadas com itens críticos nas 
camadas mais internas.
 Segurança
 Isolar componentes críticos de segurança
 Disponibilidade
 Incluir componentes redundantes na arquitetura.
 Facilidade de manutenção
 Usar componentes substituíveis e de baixa granulariade.
Pontos-chave
 A arquitetura de software é o framework fundamental 
para a estruturação de sistema.
 Decisões de projeto de arquitetura incluem decisões 
sobre o tipo de aplicação, a distribuição e os estilos de 
arquitetura a serem usados.
 Modelos diferentes de arquitetura, tais como um modelo 
de estrutura, um modelo de controle e um modelo de 
decomposição podem ser desenvolvidos.
 Modelos organizacionais de um sistema incluem 
modelos de repositório, modelos cliente-servidor e 
modelos de máquina abstrata.
Pontos-chave
 Modelos de decomposição modular incluem 
modelos de objetos e modelos de pipelining.
 Modelos de controle incluem modelos de 
controle centralizado e dirigidos a eventos.
 Arquiteturas de referência podem ser usadas 
para comunicar arquiteturas de domínio 
específico, avaliar e comparar projetos de 
arquitetura.
Referências
BEZERRA, E. Princípios de Análise e Projeto com UML. 
Novatec, 2007.
PRESSMAN, R. Engenharia de Software. McGraw Hill, 
2006.
SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. 
São Paulo: Addison-Wesley, 2007.