These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1
Capítulo 10
n
Desenho de Componentes
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.
O que é um componente?
n
OMG Unified Modeling Language Specification
[OMG01]
define um componente como
n
“… uma parte modular, implantável e substituível de um
sistema que encapsula implementação e expõe um
conjunto de interfaces.”
”
n
Visão OO:
um componente contém um conjunto de
classes que colaboram entre si
n
Visão convencional:
um componente contém lógica de
processamento, as estruturas de dados que são
necessárias para implementar a lógica de
processamento e uma interface que permite ao
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 5
Princípios Básicos de Desenho
n
Princípio Aberto-Fechado (OCP).
“Um módulo [componente]
deve ser aberto para extensão e fechado para modificação.
n
Princípio de Substituição de Liskov (LSP).
“Subclasses devem
ser substitutas para suas classes base.
n
Princípio de Inversão de Dependência (DIP).
“Dependa de
abstração. Não dependa de uma coisa concreta.”
n
Princípio da Segregação de Interface (ISP).
“Muitas interfaces
específicas são melhores que uma interface de propósito geral.
n
Princípio da Equivalência Liberação-Reuso (REP).
“ O grânulo do
reuso é o grânulo da liberação (release).”
n
Princípio da Clausura Comum (CCP).
“Classes que mudam junto
devem ser agrupadas.”
n
Princípio do Reuso Comum (CRP).
“Classes que não são
reutilizadas juntas não devem ser agrupadas.”
Diretrizes de Desenho
n
Componentes
n
Convenções de nome devem ser estabelecidas
para os componentes que são especificados como
parte do modelo arquitetural e são refinados e
elaborados como parte do modelo de componentes
n
Interfaces
n
Interfaces fornecem informação importante sobre
comunicação e colaboração (e ajudam a alcançar o
princípio OPC)
n
Dependências e herança
n
É uma boa ideia modelar dependências da
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 7
Coesão
n
Visão convencional:
n
o papel bem definido de um módulo
n
Visão OO :
n
coesão
implica que um componente ou classe encapsula
somente atributos e operações que são bem relacionados
uns com os outros e com a própria classe ou componente
n
Níveis de coesão
Acoplamento
n
Visão convencional:
n
O grau no qual o componente está conectado a outros
componentes e ao mundo externo
n
Visão OO:
n
uma medida qualitativa do grau no qual as classes estão
conectadas umas as outras
n
Níveis de acoplamento
n
Conteúdo
n
Comum
n
Controle
n
Carimbo
n
Dado
n
Chamada de Rotina
n
Uso de tipo
n
Inclusão or importação
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 9
Desenho de Componentes -I
n
Passo 1. Identificar todas as classes de desenho que
correspondem ao domínio do problema.
n
Passo 2. Identificar todas as classes de desenho que
correspondem ao domínio da infraestrutura.
n
Passo 3. Elaborar todas as classes de desenho que
não são adquiridas como componentes reutilizáveis.
n
Passo 3a. Especificar detalhes das mensagens
quando as classes ou componentes colaboram.
n
Passo 3b. Identificar interfaces apropriadas para
Desenho de Componentes-II
n
Passo 3c. Elaborar atributos e definir tipos de dados e
estruturas de dados necessários.
n
Passo 3d. Descrever o fluxo de processos dentro de
cada operação.
n
Passo 4. Descrever fontes de dados persistentes
(bancos de dados e arquivos) e identificar as classes
necessárias para gerenciá-los.
n
Passo 5. Desenvolver e elaborar representações
comportamentais para uma classe ou componente.
n
Passo 6. Elaborar diagramas de implantação para
fornecer detalhes adicionais de implementação.
n
Passo 7. Fatorar cada representação de componentes
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 15
Component Design for WebApps
n
WebApp component is
n
(1) a well-defined cohesive function that manipulates
content or provides computational or data processing
for an end-user, or
n
(2) a cohesive package of content and functionality
that provides end-user with some required
capability.
n
Therefore, component-level design for
Content Design for WebApps
n
focuses on content objects and the manner in which they
may be packaged for presentation to a WebApp end-user
n
consider a Web-based video surveillance capability
within
SafeHomeAssured.com
n
potential content components can be defined for the video
surveillance capability:
•
(1) the content objects that represent the space layout (the
floor plan) with additional icons representing the location of
sensors and video cameras;
•
(2) the collection of thumbnail video captures (each an
separate data object), and
•
(3) the streaming video window for a specific camera.
n
Each of these components can be separately named and
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Functional Design for WebApps
n
Modern Web applications deliver increasingly
sophisticated processing functions that:
n
(1) perform localized processing to generate content and
navigation capability in a dynamic fashion;
n
(2) provide computation or data processing capability that
is appropriate for the WebApp’s business domain;
n
(3) provide sophisticated database query and access, or
n
(4) establish data interfaces with external corporate
systems.
n
To achieve these (and many other) capabilities, you will
Desenhando Componentes Convencionais
n
O desenho da lógica de processamento é
governada pelos princípios básicos do
desenho de algoritmos e da programação
estruturada
n
O desenho de estruturas de dados é definido
pelo modelo de dados desenvolvido para o
sistema
n
O desenho das interfaces é governada pelas
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 19
Desenho de Algoritmos
n
a atividade de desenho mais próxima a
implementação
n
a abordagem:
n
revisar a descrição de desenho para o
componente
n
utilizar refinamentos sucessivos para
desenvolver o componente
n
utilizar a programação estruturada para
implementar a lógica procedural
n
utilizar estratégias para verificar a correção
Refinamentos sucessivos
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 21
Modelo de Desenho de Algoritmo
n
representa o algoritmo em um nível de
detalhes que pode ser revisado para
qualidade
n
opções:
n
gráfico (e.g. fluxograma, diagrama de caixas)
n
pseudocódigo (e.g., PDL)
... escolha de muitos
Programação Estruturada
utiliza um conjunto limitado de construções:
sequência
condicional
— if-then-else, select-case
laços
— do-while, repeat until
implica em código mais legível e testável
importante para alcançar alta qualidade, mas não
suficiente
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 23
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
Linguagem de Desenho de
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 27
Component-Based Development
n
When faced with the possibility of reuse, the
software team asks:
n
Are commercial off-the-shelf (COTS) components
available to implement the requirement?
n
Are internally-developed reusable components
available to implement the requirement?
n
Are the interfaces for available components
compatible within the architecture of the system to be
built?
n
At the same time, they are faced with the
Impediments to Reuse
n
Few companies and organizations have anything that even slightly
resembles a comprehensive software reusability plan.
n
Although an increasing number of software vendors currently sell
tools or components that provide direct assistance for software
reuse, the majority of software developers do not use them.
n
Relatively little training is available to help software engineers and
managers understand and apply reuse.
n
Many software practitioners continue to believe that reuse is “more
trouble than it’s worth.”
n
Many companies continue to encourage of software development
methodologies which do not facilitate reuse
n
Few companies provide an incentives to produce reusable program
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
Domain Engineering
1. Define the domain to be investigated.
2. Categorize the items extracted from the
domain.
3. Collect a representative sample of
applications in the domain.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 31
Identifying Reusable Components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the
domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes
reusable?
• Is the component reusable in many implementations with only
minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable
components?
Component-Based SE
n
a library of components must be available
n
components should have a consistent
structure
n
a standard should exist, e.g.,
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 33
CBSE Activities
Qualification
Before a component can be used, you must consider:
• application programming interface (API)
• development and integration tools required by the
component
• run-time requirements including resource usage (e.g.,
memory or storage), timing or speed, and network protocol
• service requirements including operating system interfaces
and support from other components
• security features including access controls and authentication
protocol
• embedded design assumptions including the use of specific
numerical or non-numerical algorithms
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 35
Adaptation
The implication of “easy integration” is:
(1) that consistent methods of resource
management have been implemented for all
components in the library;
(2) that common activities such as data
management exist for all components, and
(3) that interfaces within the architecture and
with the external environment have been
Composition
n
An infrastructure must be established to bind
components together
n
Architectural ingredients for composition include:
n
Data exchange model
n
Automation
n
Structured storage
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 37
OMG/ CORBA
n
The Object Management Group has published a
common
object request broker architecture
(OMG/CORBA).
n
An object request broker (ORB) provides services that
enable reusable components (objects) to communicate with
other components, regardless of their location within a
system.
n
Integration of CORBA components (without modification)
within a system is assured if an interface definition language
(IDL) interface is created for every component.
n
Objects within the client application request one or more
services from the ORB server. Requests are made via an
IDL or dynamically at run time.
n
An interface repository contains all necessary information
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 39
Microsoft COM
n
The
component object model
(COM) provides a
specification for using components produced by
various vendors within a single application running
under the Windows operating system.
n
COM encompasses two elements:
n
COM interfaces (implemented as COM objects)
n
a set of mechanisms for registering and passing messages
Sun JavaBeans
n
The JavaBeans component system is a portable,
platform independent CBSE infrastructure
developed using the Java programming language.
n
The JavaBeans component system encompasses a
set of tools, called the Bean Development Kit
(BDK), that allows developers to
n
analyze how existing Beans (components) work
n
customize their behavior and appearance
n
establish mechanisms for coordination and
communication
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 41
Classification
n
Enumerated classification
—components are
described by defining a hierarchical structure
in which classes and varying levels of
subclasses of software components are
defined
n
Faceted classification
—a domain area is
analyzed and a set of basic descriptive
features are identified
n
Attribute-value classification
—a set of
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 43
