Capítulo 9
n
Desenho Arquitetural
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction
with
Software Engineering: A Practitioner's Approach, 7/e.
Any other reproduction or use is
prohibited without the express written permission of the author.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2
Por que a Arquitetura?
A arquitetura não é o software operacional. Ao contrário,
é uma representação que permite ao engenheiro de
software:
(1) analisar a eficácia do desenho para atender aos
requisitos,
(2) considerer alternativas arquiteturais em um estágio
no qual a realização de mudanças arquiteturais é
relativamente mais fácil,
Por que a Arquitetura é Importante?
n
Representações da arquitetura do software são
facilitadores da comunicação entre os stakeholders
n
A arquitetura ressalta decisões prematuras de desenho
que terão profundo impacto em todo trabalho de
desenvolvimento posterior e, também, no sucesso do
software como uma entidade operacional
n
Arquitetura “constitue um modo relativamente pequeno,
intelectualmente gerenciável, sobre como o sistema é
estruturado e como seus componentes trabalham
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
Descrições Arquiteturais
n
A IEEE Computer Society propôs o padrão
IEEE-Std-1471-2000,
Recommended Practice for Architectural
Description of Software-Intensive System,
[IEE00]
n
para estabelecer um framework e vocabulário conceituais para
uso durante a elaboração da arquitetura do software,
n
para fornecer diretrizes detalhadas para representar uma
descrição arquitetural
n
para promover práticas relevantes de desenho arquitetural
n
O padrão define uma
Descrição Arquitetural
como uma
“coleção de produtos para documentar uma arquitetura”
n
A descrição é representada utilizando múltiplas visões, onde cada
Gêneros Arquiteturais
n
Gênero
implica uma categoria específica dentro
do domínio de software.
n
Dentro de cada categoria, é encontrada
diversas subcategorias.
n
Por exemplo, dentro do gênero de edificações, podem
ser identificados os seguintes estilos gerais: casas,
condomínios, edifícios residenciais, edifícios
comerciais, edifícios industriais, armazéns etc
n
Dentro de cada estilo geral, estilos mais específicos
podem ocorrer. Cada estilo apresenta uma estrutura
que pode ser escrita utilizando um conjunto de
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Estilos Arquiteturais
n
Arquiteturas focadas em dados
n
Arquiteturas de fluxo de dados
n
Arquiteturas de chamada e retorno
n
Arquiteturas orientadas a objetos
n
Arquiteturas em camadas
Cada estilo descreve uma categoria de sistema que abrange
(1) um conjunto de componentes (e.g., um banco de dados,
módulos computacionais que realizam alguma função
requerida por um sistema, (2) um conjunto de conectores
que
possibilitam “comunicação, coordenação e cooperação” entre
componentes, (3) restrições
que definem como os
componentes podem ser integrados para formar o sistema,
(4) modelos semânticos
que permitem ao arquiteto
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
Padrões Arquiteturais
n
Concorrência – aplicações precisam tratar múltiplas tarefas de
uma maneira que simula paralelismo
n
Padrão operating system process management
n
Padrão
task scheduler
n
Persistência— Dados persistem se eles permanecem após a
execução do processo que o criou. Dois padrões são comuns:
n
o padrão database management system
que utiliza a capacidade de
armazenamento e recuperação de um SGBD na arquitetura de uma
aplicação
n
um padrão application level persistence que estabelece
características de persistência para a arquitetura da aplicação
n
Distribuição— a maneira pela qual sistemas ou componentes
dentro de sistemas comunicam uns com os outros em um
ambiente distribuído
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
Desenho Arquitetural
n
O software precisa ser colocado em contexto
n
o desenho deve definir as entidades externas (outros
sistemas, dispositivos, pessoas) com os quais o
software interage e a natureza dessa interação
n
Um conjunto de arquétipos arquiteturais
devem ser identificados
n
Um
arquétipo
é uma abstração (similar a uma
classe) que representa um elemento do
comportamento do sistema
n
O arquiteto especifica a estrutura do sistema
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 16
Analisando o Desenho Arquitetural
1. Coletar cenários.
2. Detalhar requisitos, restrições e descrições de ambiente.
3. Descrever estilos/padrões arquiteturais que foram
selecionados para os cenários e requisitos:
• visão de módulo
• visão de processo
• visão de fluxo de dados
4. Avaliar atributos de qualidade considerando cada atributo de
forma isolada.
5. Identificar a sensibilidade de cada atributo de qualidade em
relação à vários atributos arquiteturais para cada estilo
arquitetural específico.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 18
Architectural Complexity
n
the overall complexity of a proposed
architecture is assessed by considering the
dependencies
between components within the
architecture [Zha98]
n
Sharing dependencies
represent dependence
relationships among consumers who use the same
resource or producers who produce for the same
consumers.
n
Flow dependencies
represent dependence relationships
between producers and consumers of resources.
n
Constrained dependencies
represent constraints on the
ADL
n
Architectural description language (ADL)
provides
a semantics and syntax for describing a software
architecture
n
Provide the designer with the ability to:
n
decompose architectural components
n
compose individual components into larger architectural
blocks and
n
represent interfaces (connection mechanisms) between
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 20
An Architectural Design Method
"four bedrooms, three baths,
lots of glass ..."
customer requirements
Deriving Program Architecture
Program
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 22
Partitioning the Architecture
n
“horizontal” and “vertical” partitioning are
Horizontal Partitioning
n
define separate branches of the module
hierarchy for each major function
n
use control modules to coordinate
communication between functions
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 24
Vertical Partitioning: Factoring
n
design so that decision making and work
are stratified
n
decision making modules should reside at
the top of the architecture
Why Partitioned Architecture?
n
results in software that is easier to test
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 26
Structured Design
n
objective:
to derive a program
architecture that is partitioned
n
approach:
n
a DFD is mapped into a program
architecture
n
the PSPEC and STD are used to
indicate the content of each module
Flow Characteristics
Transform flow
Transaction
flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 28
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map
DFD transforms into corresponding modules
add control modules as required
General Mapping Approach
n
Isolate the transform center by specifying incoming
and outgoing flow boundaries
n
Perform "first-level factoring.”
n
The program architecture derived using this mapping
results in a top-down distribution of control.
n
Factoring
leads to a program structure in which top-level
components perform decision-making and low-level
components perform most input, computation, and output
work.
n
Middle-level components perform some control and do
moderate amounts of work.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 30
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 32
