ENGENHARIA DO SOFTWARE I
Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
[email protected], D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel
Menezes de Sequeira.
Engenharia do Software I 2
Na aula anterior
Gestão de projectosActividades de gestãoPlaneamento de projectosCalendarização de projectosGestão do risco
2009/2010
Engenharia do Software I 3
Desenho arquitectónico
2009/2010
Engenharia do Software I 4
Sumário
Desenho arquitectónicoDecisões no desenho arquitectónicoOrganização de sistemasEstilos de decomposiçãoEstilos de controloArquitecturas de referência
2009/2010
Engenharia do Software I 5
Objectivos Apresentar desenho arquitectónico e discutir sua
importância
Explicar decisões tomadas no desenho arquitectónico
Apresentar três estilos arquitectónicos cobrindo organização, decomposição e controlo
Discutir arquitecturas de referência para comunicar e comparar arquitecturas
2009/2010
Engenharia do Software I 6
Arquitectura de software
Desenho arquitectónico é o processo de desenho queIdentifica subsistemas formando o sistemaIdentifica estrutura de controlo e
comunicação de subsistemasResulta em descrição da arquitectura do
software
2009/2010
Engenharia do Software I 7
Desenho arquitectónico Fase inicial do processo de desenho do sistema
Representa ligação entre processos de especificação e desenho
Frequentemente em paralelo com actividades de especificação
Identifica principais componentes do sistema e sua comunicação
2009/2010
Engenharia do Software I 8
Vantagens da arquitectura explícitaComunicação com partes interessadas
Arquitectura pode ser usada como foco de discussão pelas partes interessadas no sistema.
Análise do sistema Possível aferir se sistema pode cumprir requisitos não funcionais.
Reutilização em grande escala
Arquitectura pode ser reutilizada numa variedade de sistemas.
2009/2010
Engenharia do Software I 9
Características da arquitectura e do sistemaDesempenho Minimiza comunicações e confina operações
críticas. Usa granularidade grossa e não fina para componentes.
Segurança (security)
Usa arquitectura em camadas com activos críticos nas camadas interiores.
Segurança (safety)
Confina características críticas relativamente à segurança a pequeno número de subsistemas.
Disponibilidade Inclui componentes e mecanismos redundantes para ser tolerante a falhas.
Mantenibilidade Usa componentes com granularidade fina e substituíveis.
2009/2010
• Security: segurança face a actos de pessoas, por exemplo fraude, roubo ou acesso ilícito.
• Safety: segurança face a falhas e acontecimentos físicos.
Engenharia do Software I 10
Conflitos arquitectónicos Componentes com granularidade grossa
Melhor desempenhoMenor manutenibilidade
Dados redundantesMelhor disponibilidadeSegurança (security) mais difícil
Características de segurança (safety) confinadasNormalmente maior comunicaçãoMenor desempenho
2009/2010
Engenharia do Software I 11
Estruturação do sistema Foco na decomposição do sistema em
subsistemas interagentes
Desenho arquitectónico normalmente expresso como diagrama de blocos representando vista da estrutura do sistema
Pode desenvolver-se modelos mais específicos mostrando partilha de dados, distribuição e interface entre subsistemas
2009/2010
12Engenharia do Software I
Exemplo: Sistema de controlo de robot de embalamento
2009/2010
Sistema de visão
Sistema de identificação de objectos
Controlador do braço
Controlador da mão
Sistema de selecção de embalagens
Controlador de tapete rolante
Sistema de embalamento
Engenharia do Software I 13
Diagramas de caixas e linhas Muito abstractos, não mostram natureza
de relações entre componentes nem propriedades observáveis de subsistemas
No entanto, úteis para comunicação com partes interessadas e para planeamento de projectos
2009/2010
Engenharia do Software I 14
Decisões no desenho arquitectónico Desenho arquitectónico é processo
criativo
Processo varia com tipo do sistema em desenvolvimento
Mas há conjunto de decisões comuns a todos os processos de desenho
2009/2010
Engenharia do Software I 15
Decisões no desenho arquitectónico Há arquitectura aplicacional genérica
usável? Como distribuir sistema? Que estilos arquitectónicos se apropriam? Que abordagem para estruturar sistema? Como decompor sistema em módulos? Que estratégia de controlo usar? Como avaliar desenho arquitectónico? Como documentar arquitectura?
2009/2010
Engenharia do Software I 16
Reutilização de arquitecturas
Sistemas do mesmo domínio têm muitas vezes arquitecturas semelhantes reflectindo conceitos do domínio
Linhas de produto aplicacionais construídas em torno de arquitectura central com variantes satisfazendo requisitos particulares do cliente
2009/2010
Capítulo 13
Capítulo 18
Engenharia do Software I 17
Estilos arquitectónicos Modelo arquitectónico de sistema pode
conformar-se a modelo ou estilo arquitectónico genérico
Conhecer estilos pode simplificar definição de arquitecturas de sistemas
No entanto, muitos dos grandes sistemas são heterogéneos não seguindo estilo arquitectónico único
2009/2010
Engenharia do Software I 18
Modelos arquitectónicos
Documentam desenho arquitectónicoModelo estrutural estático mostrando
principais componentes do sistemaModelo dinâmico da estrutura de processos
do sistemaModelo das interfaces dos subsistemasModelo de relações entre subsistemas (e.g.,
modelo de fluxo de dados)Modelo de distribuição dos subsistemas
pelos computadores
2009/2010
Engenharia do Software I 19
Organização de sistemas
Reflecte estratégia básica usada para estruturar sistema
Três estilos organizacionais muito usadosRepositório partilhado de dadosServiços e servidores partilhadosMáquina abstracta ou estilo em camadas
2009/2010
Engenharia do Software I 20
Modelo de repositório Subsistemas têm de trocar dados
Duas formas possíveisDados em repositório ou base de dados central
partilhados por subsistemasCada subsistema mantém sua base de dados e
passa dados explicitamente a restantes subsistemas
Modelo de repositório partilhado mais comum quando se partilha grandes quantidades de dados
2009/2010
21Engenharia do Software I
Exemplo: Arquitectura de conjunto de ferramentas CASE
2009/2010
Editor de desenho
Gerador de código
Analisador de desenho
Gerador de relatórios
Editor de programas
Tradutor de desenho
Repositório do projecto
Engenharia do Software I 22
Vantagens do modelo de repositório Eficiente partilhar grandes quantidades de dados
Subsistemas não se preocupam com produção de dados
Gestão centralizada (cópias de segurança, segurança, etc.)
Modelo de partilha publicado como esquema (schema) do repositório
2009/2010
Engenharia do Software I 23
Desvantagens do modelo de repositório Subsistemas têm de acordar modelo de
repositório de dados (compromisso)
Evolução de dados difícil e onerosa
Não há espaço para políticas de gestão específicas
Difícil distribuir eficientemente
2009/2010
Engenharia do Software I 24
Modelo cliente-servidor Modelo distribuído de sistema mostrando como
dados e processamento se distribuem por conjunto de componentes
Conjunto de servidores isolados disponibilizando serviços específicos (impressões, gestão de dados, etc.)
Conjunto de clientes usando serviços
Rede para clientes acederem a servidores
2009/2010
25Engenharia do Software I
Exemplo: Mediateca
2009/2010
Cliente 1 Cliente 1Cliente 1Cliente 1
Servidor de catálogo
Catálogo da mediateca
Servidor de vídeo
Ficheiros de vídeo
Servidor de imagens
Fotografias digitalizadas
Servidor Web
Informação sobre média
Internet
Engenharia do Software I 26
Vantagens do modelocliente-servidor Distribuição de dados óbvia
Utilização eficaz de sistemas em rede
Pode requerer hardware mais barato
Fácil adicionar novos servidores ou actualizar existentes
2009/2010
Engenharia do Software I 27
Desvantagens do modelocliente-servidor Subsistemas com diferentes organizações
de dados, sem modelo partilhado de dados
Troca de dados pode ser ineficiente
Administração separada dos servidores
Pode ser difícil saber servidores e serviços disponíveis, sem registo central de nomes e serviços
2009/2010
Engenharia do Software I 28
Arquitectura Orientada por Serviços (SOA) Arquitectura
distribuída genérica baseada no paradigma pedido/resposta
Exemplos RPC DCOM CORBA Web Services WCF
2009/2010
Capítulo 12
Serviço de directório
Serviço Serviço
Parceiros de negócio
Outros fornecedores
Cliente
Serviço Serviço
Engenharia do Software I 29
Princípios arquitecturais da SOA
Encapsulamento Ligação fraca (loose coupling) Contratualidade Abstracção Reutilizabilidade Componibilidade Autonomia Descobribilidade
2009/2010
Engenharia do Software I 30
Modelo de máquina abstracta (em camadas) Subsistemas ligados através de interfaces
Organiza sistema em camadas (máquinas virtuais) fornecendo conjunto de serviços
Suporta desenvolvimento incremental de subsistemas: alteração de interface só afecta camada adjacente
Muitas vezes artificial para estruturar sistemas
2009/2010
31Engenharia do Software I
Exemplo: Sistema de controlo de versões
2009/2010
Gestão de configurações
Gestão de objectos
Bases de dados
Sistema operativo
Camadas de
sistema
Engenharia do Software I 32
Estilos de decomposição modular Decomposição de subsistemas em
módulos
Sem distinção rígida entre organização do sistema e decomposição modular
2009/2010
Engenharia do Software I 33
Subsistemas e módulosSubsistema Sistema cuja operação é independente dos serviços
fornecidos por outros subsistemas.
Módulo Componente de sistema que fornece serviços a outros componentes mas que por si só normalmente não se considera um sistema.
2009/2010
Engenharia do Software I 34
Decomposição modular Nível estrutural em que subsistemas se
decompõem em módulos
Dois modelos abordadosModelo de objectos – Decomposição em objectos em
interacçãoModelo de fluxo de dados – Decomposição em
módulos funcionais transformando entradas em saídas
Tentar adiar decisão sobre concorrência até implementação de módulos
2009/2010
Engenharia do Software I 35
Modelos de objectos Estruturam sistema em conjunto de objectos
fracamente ligados com interfaces bem definidas
Decomposição corresponde a identificar classes de objectos, seus atributos e suas operações
Na implementação, objectos criados via classes e modelo de controlo coordena operações dos objectos
2009/2010
36Engenharia do Software I
Exemplo: Sistema de processamento de facturas
2009/2010
Customer
- customerNumber- name- address- creditPeriod
Payment
- invoiceNumber- date- amount- customerNumber
Invoice
- invoiceNumber- date- amount- customer
+ issue()+ sendReminder ()+ acceptPayment()+ sendReceipt()
Receipt
- invoiceNumber- date- amount- customerNumber
Engenharia do Software I 37
Vantagens do modelo de objectos Objectos fracamente ligados, implementação
pode mudar sem afectar outros objectos
Objectos podem reflectir entidades reais
Linguagens de implementação orientadas por objectos muito usadas
Mas alterações em interfaces podem causar problemas e entidades complexas podem ser difíceis de representar
2009/2010
Engenharia do Software I 38
Fluxo de dados orientado por funções Transformações funcionais transformam
entradas em saídas
Também conhecido por modelo pipeline ou modelo pipe and filter (shell UNIX)
Variantes muito comuns: se transformações sequenciais, modelo em lote sequencial usado em sistemas de processamento de dados
Mas não apropriado para sistemas interactivos
2009/2010
39Engenharia do Software I
Exemplo: Sistema de processamento de facturas
2009/2010
Facturas Pagamentos
Ler facturas emitidas
Emitir recibos
Procurar pagamentos
devidos
Emitir lembrete de pagamento
Lembretes
Recibos
Identificar pagamentos
Engenharia do Software I 40
Vantagens do modelo de fluxo de dados Suporta reutilização de transformações
Organização intuitiva para comunicar com partes interessadas
Fácil adicionar novas transformações
Relativamente fácil de implementar em sistemas concorrentes e sequenciais
Mas requer formato comum para transferência de dados e difícil suportar interacção baseada em eventos
2009/2010
Engenharia do Software I 41
Estilos de controlo Focam-se no fluxo de controlo entre
subsistemas
Distintos do modelo de decomposição do sistema
2009/2010
Engenharia do Software I 42
Estilos de controloControlo centralizado Um subsistema tem responsabilidade
global pelo controlo e inicia e termina os outros subsistemas.
Controlo baseado em eventos
Cada subsistema responde a eventos gerados externamente com origem em outros subsistemas ou em ambiente do sistema.
2009/2010
Engenharia do Software I 43
Controlo centralizado
Subsistema de controlo com responsabilidade por gerir execução de outros subsistemas
2009/2010
Engenharia do Software I 44
Controlo centralizadoModelo invocação-retorno
Modelo descendente (top-down) de subrotinas em que controlo começa no topo da hierarquia de subrotinas. Aplicável a sistemas sequenciais.
Modelo de gestor Aplicável a sistemas concorrentes. Um componente do sistema controla paragem, arranque e coordenação de outros processos do sistema. Pode ser implementado em sistemas sequenciais como instrução de selecção múltipla.
2009/2010
45Engenharia do Software I
Modelo invocação-retorno
2009/2010
Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2
Programa principal
Rotina 1 Rotina 3Rotina 2
46Engenharia do Software I
Controlo de sistema em tempo real
2009/2010
Processos sensores
Processos actuadores
Processos de computação
Interface com utilizador
Gestor de anomalias
Controlador do sistema
Engenharia do Software I 47
Sistemas guiados por eventos Guiados por eventos gerados externamente
Instante de ocorrência dos eventos fora do controlo dos subsistemas que o processam
Dois principais modelosDifusãoGuiados por interrupções
Outros modelosFolhas de cálculoSistemas de produção
2009/2010
Engenharia do Software I 48
Modelos de sistemas guiados por eventosDifusão Cada evento difundido para todos subsistemas.
Qualquer subsistema pode lidar com evento.
Guiados por interrupções
Usados em sistemas de tempo real.Interrupções detectadas por gestor de interrupções e passadas a outro componente para processamento.
2009/2010
Engenharia do Software I 49
Modelo de difusão Eficaz para integrar subsistemas em diferentes
computadores de uma rede
Subsistemas registam interesse em eventos específicos; quando ocorrem, controlo transferido para subsistemas que com eles podem lidar
Política de controlo não está no gestor de eventos e mensagens; subsistemas decidem que eventos são do seu interesse
No entanto, subsistemas não sabem se e quando um evento será processado
2009/2010
50Engenharia do Software I
Difusão selectiva
2009/2010
Subsistema 1 Subsistema 4Subsistema 3Subsistema 2
Gestor de mensagens e eventos
Engenharia do Software I 51
Sistemas guiados por interrupções Usados em sistemas de tempo real onde é
essencial responder rápido a eventos
Um gestor definido para cada tipo de interrupções conhecido
Cada tipo associado a posição de memória; comutador hardware transfere para gestor associado
Permitem resposta rápida, mas complexos de programar e difíceis de validar
2009/2010
52Engenharia do Software I
Controlo guiado por interrupções
2009/2010
Vector de interrupções
Interrupções
Gestor 1 Gestor 2 Gestor 3 Gestor 4
Processo 1 Processo 2 Processo 3 Processo 4
Engenharia do Software I 53
Arquitecturas de referência Modelos arquitectónicos podem ser específicos de
um dado domínio de aplicação
Tipos de modelo específico de domínio Modelos genéricos Modelos de referência
2009/2010
Engenharia do Software I 54
Tipos de modelo específico de domínioModelos genéricos
Abstracções de uma quantidade de sistemas reais que incorporam as principais características desses sistemas. Usualmente são modelos ascendentes (bottom-up).
Modelos de referência
Modelos mais abstractos e idealizados. Informam acerca dessa classe de sistema e facilitam a comparação entre diferentes arquitecturas. São modelos descendentes (top-down).
2009/2010
Capítulo 13
Engenharia do Software I 55
Arquitecturas de referência Modelos de referência derivados do estudo do
domínio de aplicação e não de sistemas existentes
Usados como base para implementação de sistemas ou para comparar sistemas
São padrão de referência para avaliação de sistemas
Modelo OSI é modelo em camadas para sistemas de comunicação
2009/2010
56Engenharia do Software I
Modelo de referência OSI
2009/2010
Meio de comunicações
Físico
Dados
Rede
Transporte
Sessão
Apresentação
Aplicação
1
2
3
4
5
6
7
Físico
Dados
Rede
Transporte
Sessão
Apresentação
Aplicação
Físico
Dados
Rede
Engenharia do Software I 59
A reter Arquitectura de software é enquadramento
fundamental para estruturar sistemas
Decisões arquitectónicas de desenhoTipo de aplicaçãoDistribuição do sistemaEstilos arquitectónicos
Diferentes modelos arquitectónicosEstruturalDe controloDe decomposição
2009/2010
Engenharia do Software I 60
A reter
Modelos organizacionais de sistemasDe repositórioCliente-servidorDe máquinas abstractas
Modelos de decomposição modularDe objectosDe fluxo de dados
2009/2010
Engenharia do Software I 61
A reter
Modelos de controloControlo centralizadoGuiado por eventos
Arquitecturas de referência usadas para comunicar arquitecturas específicas de domínio e para avaliar e comparar desenhos arquitectónicos
2009/2010
Engenharia do Software I 62
A ler
Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006
Capítulo 11Capítulo 12
2009/2010