2/2/2015
Análise e Projeto de
Software
Material preparado pelo Prof.
Marcelo Maia
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
363
Análise e
Projeto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
364
1
2/2/2015
Projeto e Modelos
Elicitação de
Requisitos
CIM
Análise de
Requisitos
PIM
Projeto do Sistema
PSM
Código
Implementação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Artefatos de Projeto


Razões das Decisões (Design Rationale)
Modelos de Projeto







Modelos Arquiteturais
Modelos de Dados
Modelos da Interface com Usuário
Modelos de Componentes
Modelos de Implantação
Padrões Arquiteturais
Padrões de Projeto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
2
2/2/2015
Influências no Projeto

Requisitos funcionais

Requisitos não-funcionais
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Architecture
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.” [SHA95a]
Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of methods
Extra-functional properties. The architectural design description should
address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
Fonte: Pressman
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
3
2/2/2015
Software architecture


The design process for identifying the sub-systems making up a
system and the framework for sub-system control and communication
is architectural design.
The output of this design process is a description of the software
architecture.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Architectural design

An early stage of the system design process.

Represents the link between specification and design
processes.

Often carried out in parallel with some specification
activities.

It involves identifying major system components and their
communications (structural properties)
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
4
2/2/2015
Advantages of explicit
architecture

Stakeholder communication


System analysis


Architecture may be used as a focus of discussion by
system stakeholders.
Means that analysis of whether the system can meet its
non-functional requirements is possible.
Large-scale reuse

The architecture may be reusable across a range of
systems.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Architecture and system
characteristics

Performance


Security


Localise safety-critical features in a small number of subsystems.
Availability


Use a layered architecture with critical assets in the inner
layers.
Safety


Localise critical operations and minimise communications.
Use large rather than fine-grain components.
Include redundant components and mechanisms for fault
tolerance.
Maintainability

Use fine-grain, replaceable components.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
5
2/2/2015
Architectural conflicts
Trade-offs

Using large-grain components improves
performance but reduces maintainability.

Introducing redundant data improves availability
but makes security more difficult.

Localising safety-related features usually means
more communication so degraded performance.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
System structuring

Concerned with decomposing the system into
interacting sub-systems.

The architectural design is normally expressed as
a block diagram presenting an overview of the
system structure.

More specific models showing how sub-systems
share data, are distributed and interface with each
other may also be developed.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
6
2/2/2015
Box and line diagrams

Very abstract - they do not show the nature of
component relationships nor the externally
visible properties of the sub-systems.

However, useful for communication with
stakeholders and for project planning.

Difficult for profound evaluation
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Packing robot control system
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
7
2/2/2015
Diagrama de componentes

Abstract, but they do show the nature of
component relationships and the externally
visible properties of the sub-systems.

Yet, useful for communication with stakeholders
and for project planning.
Better for more profound evaluation
 Next step: refine

Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Diagrama de Componentes
Sistema Web
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
8
2/2/2015
Architectural design decisions

Architectural design is a creative process so the process differs
depending on the type of system being developed.

However, a number of common decisions span all design processes.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Architectural design decisions








Is there a generic application architecture that can be
used?
How will the system be distributed?
What architectural styles are appropriate?
What approach will be used to structure the system?
How will the system be decomposed into modules?
What control strategy should be used?
How will the architectural design be evaluated?
How should the architecture be documented?
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
9
2/2/2015
Architecture reuse

Systems in the same domain often have similar architectures that
reflect domain concepts.

Application product lines are built around a core architecture with
variants that satisfy particular customer requirements.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Architectural styles
Architecture patterns

The architectural model of a system may conform
to a generic architectural model or style.

An awareness of these styles can simplify the
problem of defining system architectures.

However, most large systems are heterogeneous
and do not follow a single architectural style.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
10
2/2/2015
Architectural models

Used to document an architectural design.

Static structural model that shows the major system components.

Dynamic process model that shows the process structure of the
system.

Interface model that defines sub-system interfaces.

Relationships model such as a data-flow model that shows subsystem relationships.

Distribution model that shows how sub-systems are distributed across
computers.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Fonte: Sommerville
Reference architectures

Reference models are derived from a study of the application
domain rather than from existing systems.

May be used as a basis for system implementation or to
compare different systems. It acts as a standard against
which systems can be evaluated.

OSI model is a layered model for communication systems.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
11
2/2/2015
OSI reference model
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Key points

The software architecture is the fundamental framework for
structuring the system.

Architectural design decisions include decisions on the
application architecture, the distribution and the
architectural styles to be used.

Different architectural visions such as a structural model, a
control model may be developed.

System organisational models (patterns) include repository
models, client-server models and abstract machine models.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
12
2/2/2015
Key points



Modular decomposition models include object models and pipelining
models.
Control models include centralised control and event-driven models.
Reference architectures may be used to communicate domain-specific
architectures and to assess and compare architectural designs.
Fonte: Sommerville
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Padrões de Arquitetura
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
13
2/2/2015
Padrões




Nome do padrão
Problema: quando aplicar o padrão? Descreve o problema e
seu contexto.
Solução: elementos que definem o projeto, seus
relacionamentos, responsabilidades e colaborações. É como
um “template”que pode ser usado em várias situações.
Conseqüências são resultados e trade-offs (compromissos)
de se aplicar os padrões. Relacionadas aos trade-offs de
espaço e tempo. Como o reúso é um fator importante as
conseqüências incluem o impacto na flexibilidade,
estensibilidade e portabilidade do sistema.
Fonte: GoF
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Classificação de Padrões
Padrões

Os padrões de projeto podem ser classificados de acordo
com a fase de desenvolvimento em que são mais
adequados:

Padrões de Análise (Analysis patterns)



Padrões de Arquitetura (Architectural patterns)

Padrões de Projeto (Design patterns)



Seu foco é na fase de análise ou modelamento de negócio
Padrões ligados ao domínio do problema
Seu foco é na arquitetura do software
Foco no projeto de componentes do software
Muitas das vezes os padrões podem estar muito ligados tanto ao
domínio da solução, quanto do problema
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
390
14
2/2/2015
Classificação de Padrões
Padrões

Padrões de Análise (Analysis patterns)

Padrões de Arquitetura (Architectural patterns)




Martin Fowler , 1996
Apresentado inicialmente por Frank Buschmann et al., 1996
Computação Distribuída - Frank Buschmann et al., 2007
Padrões de Projeto (Design patterns)









GOF (Gang of Four) E. Gamma, R. Helm, R. Johnson, J. Vlissides – 1995
Aplicações Concorrentes e em Rede - Frank Buschmann et al. – 2000
Enterprise Integration Patterns – Gregor Hohpe, 2003
Real-time Design Patterns – Bruce Douglass, 2003
.Net Design Patterns - Christian Thilmany, 2003
J2EE Design Patterns - Deepak Alur, 2003
Web Services Patterns – Paul Monday, 2003
Ajax Design Patterns - Michael Mahemoff, 2006
SOA Design Patterns – Thomas Erl, 2009
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
391
Padrões de Análise
(Analysis Patterns)





Proposto por Martin Fowler, em livro publicado em 1996
Notação do Livro não é baseada em UML
Baseada em áreas (domínios) específicas como: manufatura; financeira e saúde
Mesmo assim, padrões podem apresentados podem ser úteis em outros
domínios
Alguns princípios apresentados





Um modelo não está certo ou errado, eles podem ser mais ou menos úteis
Modelos conceituais estão ligados a tipos (interfaces) e não implementações (classes)
Padrões são o ponto de partida, não o destino
Sempre que possível, quando existir um tipo e um supertipo, considere colocar os
recursos no supertipo, desde que isto faça sentido
Quando múltipos atributos possuam um comportamento relacionado e presente em
muitos tipos, combine estes atributos em um novo tipo fundamental
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
392
15
2/2/2015
Padrões de Análise
(Analysis Patterns)

Exemplos de alguns padrões de projeto














Quantity (3.1)
Conversion Ratio (3.2)
Compound Units (3.3)
Measurement (3.4)
Observation (3.5)
Range (4.3)
Name (5.1)
Account (6.1)
Transaction (6.2)
Summary Account (6.3)
Plan (8.4)
Contract (9.1)
Product (10.3)
Associative Type (15.1)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
393
Padrões de Arquitetura
(Architectural patterns)





Expressam uma organização fundamental de estrutura de um software
O ponto de partida da análise orientada a objetos é a criação do
chamado Domain Model
O “Domain Model” expressa as classes ligadas ao domínio do problema
Os padrões de arquitetura auxiliam na concepção do software e na
transição para o domínio da solução
Alguns padrões de arquitetura





Layers
Model-View-Controler (MVC)
Pipes and Filters
Microkernel
Shared Repository
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
394
16
2/2/2015
Padrões de Projeto
(Design Patterns)


Trabalho proposto inicialmente por Erich Gamma, Richard Helm, Ralph
Jonhson, John Vlissides (Gang of Four) em 1995
Famílias de Padrões

De Criação




Estruturais



Responsáveis pela criação de objetos
Permitem que o sistema fique independente da forma como os objetos são criados
Factory, Abstract Factory, Singleton, Builder, Prototype
Relacionados com a forma com que classes e objetos são compostos a fim de
formar estruturas maiores
Adapter, Bridge, Composite, Decorator, Facade, Proxy
Comportamentais



Relacionados com a atribuição de responsabilidades entre objetos
Descrevem a comunicação entre objetos
Chain of Responsibility, Command, Flyweigth, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, Template, Visitor
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
395
Layer

Permite o desenvolvimento de forma independente de diferentes partes
do sistema de software
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
396
17
2/2/2015
Layer

Usos com outros padrões
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
397
Estilos (padrões) de Arquitetura
Camadas
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
18
2/2/2015
Camadas (Windows NT)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Pipes and Filters

Arquitetura especializada em tratar fluxos de dados (data streams)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
400
19
2/2/2015
Pipes and Filters

Uso com outros padrões
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
401
Estilos (padrões) de Arquitetura
Dutos e Filtros
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
20
2/2/2015
Estilos (padrões) de Arquitetura
Dutos e Filtros
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Dutos e Filtros
Atividade começando com o data source
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
21
2/2/2015
Dutos e Filtros
Atividade começando com o data sink
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Dutos e Filtros
Mix pull-push (Source/Sink passivos)
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
22
2/2/2015
Dutos e Filtros
Filtros ativos
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Broker - estrutura
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
23
2/2/2015
Broker – dinâmica
requisição de serviço pelo cliente
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Broker – dinâmica
uso de pontes
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
24
2/2/2015
Model-View-Controller

Uso

Em situações onde a interface do usuário de uma aplicação pode
mudar de forma mais frequente que o seu domínio
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
411
Model-View-Controller

Uso do MVC com outros padrões
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
412
25
2/2/2015
MVC - Estrutura
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
MVC – Dinâmica –Inicialização
Engenharia de Software
Fonte: Buschmann
Prof. Flávio de Oliveira Silva, Ph.D.
26
2/2/2015
MVC – Dinâmica
Tratamento de eventos
Fonte: Buschmann
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Microkernel

Uso

Arquitetura com suporte para escalabilidade funcional e adaptável para
diferentes cenários de implantação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
416
27
2/2/2015
Microkernel

Uso com outros padrões
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
417
Microkernel
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
28
2/2/2015
Microkernel
Cliente chamando serviço
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Microkernel
Servidor externo requisitando serviço
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
29
2/2/2015
Monolítico x Microkernel
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
JBoss - JMX
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
30
2/2/2015
JBoss – JMX
Camadas - Microkernel
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Shared Repository

Uso



Aplicações em que partes operam e são coordenadas através de um
conjunto de dados compartilhados
Caso de aplicações orientadas a dados e onde a interação entre os
componentes não seguem regras específicas que possibilitem sua conexão
A conexão entre os componentes e aplicações é feita através dos dados
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
424
31
2/2/2015
Shared Repository

Uso com outros padrões
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
425
Integração de Aplicações

Orientada a processos

Enterprise Application Integration


Enterprise Service Bus
Orientada a Dados


ETL (Expose, Transform, Load)
EII (Enterprise Information Integration)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
32
2/2/2015
Integração de Aplicações
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Comparação das abordagens
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
33
2/2/2015
Enterprise Application Integration
(EAI)
 EAI
refers to
 message-based,
 transaction-oriented,
 application-to-application
integration
 using either an integration pattern
 point-
to-point or;
 a point-to-hub (brokering or bus)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Padrões para integração orientada a
processos
Hub (broker) x Ponto a ponto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
34
2/2/2015
Evolução de integração de
aplicações


1960 – Hardware incompatível implicava em reescrever tudo (ex: 1991)
Aplicações em batch (lotes) escrita em silos e compartilhamento através
de arquivos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Evolução de integração de
aplicações

Cliente-servidor



Escolhas da infra-estrutura de rede. No início não havia arquitetura de rede
amplamente aceita.
Funções de comunicação tinham que ser adicionadas na aplicação
requerendo maior habilidade dos programadores
As APIs eram bastante complexas, sendo necessário muito tratamento de
exceção e lógica de recuperação para se ter sucesso.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
35
2/2/2015
Evolução de arquiteturas clienteservidor
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
RPC requer o servidor sempre disponível...
Middleware de Filas de Mensagens
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
36
2/2/2015
Adaptadores de formato
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Message brokers
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
37
2/2/2015
Integração via
Business Process Management
Um requisição de serviço de um cliente pode
chegar por inúmeros canais, tais como, telefone,
mensagem de voz, fax, e-mail e até mesmo via
carta convencional.
 Tal evento precisa ser








capturado, categorizado e enviado pela organização
através de um caminho predefinido,
sendo monitorado por um sistema de gerenciamento
que garante que a solução (e satisfação do cliente)
serão atingidas dentro de certo prazo,
e que qualquer intercorrência
seja detectada, escalonada e remediada de acordo
com parâmetros específicos de níveis de serviço.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Impacto da Internet

Tecnologia para Web Services

Extensible Markup Language (XML)

SOAP (originally an acronym for Simple Object Access Protocol) is na
application-to-application protocol that isolates network, transport, programming
language, and platform differences to allow a client to call a remote service
without knowledge of how the service is coded or where the service is hosted.
The message format is XML.

Web Services Description Language (WSDL) is an XML-based interface and
interface description language. The service provider uses a WSDL document in
order to specify the operations a Web service provides, the parameters and data
types of these operations and the location and transport bindings to be used to
access the service.

Web Services Inspection Language (WSIL) is an XML-based specification about
how to locate Web services without the necessity of using UDDI. However, WSIL
can be also used together with UDDI, that is, it is orthogonal to UDDI and does
not replace it.

Universal Description, Discovery, and Integration (UDDI) is both a client-side
API and a SOAP-based server implementation that can be used to store and
retrieve information on service providers and Web services.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
38
2/2/2015
Evolução de EAI
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Service-oriented Architecture

SOA is an integration architecture approach
based on the concept of a service.

The business and infrastructure functions


are provided as services
that collectively, or individually, deliver application functionality
 to either end-user applications or other services.



Applications collaborate by invoking each other’s
services.
Services are composed into larger sequences to
implement business processes.
SOA requires a consistent mechanism for services to
communicate:


loosely coupled
use of explicit interfaces.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
39
2/2/2015
O que é serviço?

A service is a discrete function that is offered to an
external consumer.


Consumer: Web page, another business function, or a
collection of functions that together form a process.
Additional aspects:



Services encapsulate reusable business function.
Services are defined by explicit, implementationindependent interfaces.
Services are defined in a way that stress location and
transport transparency.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
SOA x Web Services
Web Services
• A means to create well-
SOA

documented interfaces for
services using standards such as
Web services Definition
Language (WSDL) and
document-style SOAP
• A means to compose Web
services using Business
Process Execution Language for
Web Services (WS-BPEL)
• Simple communication
mechanisms that are
Architectural patterns for realizing
a business design through the
implementation and composition of
software services

A reference architecture model to
decompose the functional components
of an integration solution

A model for the life cycle and
governance of services to help make
reusability of services a reality
location-transparent and
interoperable
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
40
2/2/2015
Evolução de EAI
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
SOA
Service Oriented Architecture
Registro
Procura
Consumidor
Contrato
Interage
Publica
Provedor
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
444
41
2/2/2015
Abstrações de SOA
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Elementos do serviço
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
42
2/2/2015
Elementos de SOA
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Tipos de serviços
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
43
2/2/2015
Arquitetura tradicional x SOA
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Exemplo
companhia aérea
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
44
2/2/2015
Evolução de EAI
• Providing a consumer view of a
service decoupled from the
deployed implementation of the
underlying application or service
• Decoupling technical aspects
of service interactions
• Unifying access to applications
using a common service model
• Providing dynamic access to
services described in a service
repository
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
SOA sem ESB
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
45
2/2/2015
SOA com ESB
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Funções de Middleware do ESB

Map service requests from one protocol and address to another.

Transform data formats.

Support a variety of security and transactional models between service consumers
and service providers and recognize that consumers and providers may support or require
different models.

Aggregate or disaggregate service requests and responses.

Support communication protocols between multiple platforms with appropriate qualities
of service.

Provide messaging capabilities such as message correlation and publish/subscribe to
support different messaging models such as events and asynchronous request/response.
E idealmente:

Support high volumes of individual interactions.

Support more established integration styles, such as message-oriented and eventdriven integration, to extend the reach of the SOA.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
46
2/2/2015
Visão de alto nível do ESB
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Arquitetura de referência SOA
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
47
2/2/2015
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Service component architecture
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
48
2/2/2015
Análise e Projeto Orientado a
Objetos Utilizando UML 2.0
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
459
Orientação a Objetos
Alguns Conceitos













OBJETO
MÉTODO
MENSAGEM
CLASSE
CLASSIFICAÇÃO
GENERALIZAÇÃO
ESPECIALIZAÇÃO
HERANÇA
POLIMORFISMO
SOBRECARGA
ENCAPSULAMENTO
ABSTRAÇÃO
MODULARIZAÇÃO
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
460
49
2/2/2015
Análise Orientada a Objetos (OOA)
Projeto Orientado a Objetos (OOD)


A utilização do orientação à Objetos solicita uma nova forma de abstrair e
entender o problema.
A linguagem UML é um padrão de diagramação para visualizar os
resultados da análise e projeto orientados à objetos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
461
Análise Orientada a Objetos (OOA)
Projeto Orientado a Objetos (OOD)

Exemplo

O conceito “Livro” em um sistema de biblioteca
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
462
50
2/2/2015
Análise Orientada a Objetos(OOA)

Objetivo básico


Identificar classes a partir das quais objetos serão representados como
instâncias
Envolve as seguintes tarefas




Identificação de Objetos
Especificação de Atributos
Definição de métodos
Comunicações entre objetos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
463
Análise Orientada a Objetos(OOA)

IDENTIFICAÇÃO DE OBJETOS







Entidades externas (Outros sistemas; dispositivos;Pessoas)
Coisas ligadas ao domínio do problema (Relatórios;Displays;…)
Ocorrências ou Eventos (Conclusão de um movimento;Alarme
disparado; Clique do mouse; etc.)
Papéis ou funções (Engenheiro; Gerente; Vendedor) desempenhados
por pessoas
Unidades organizacionais (Grupo; Equipe;…)
Lugares (Piso de fábrica; área de descarga)
Estruturas (Sensores; veículos de quatro rodas;…)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
464
51
2/2/2015
Análise Orientada a Objetos(OOA)

IDENTIFICAÇÃO DE OBJETOS – CRITÉRIOS
1.
2.
3.
4.
5.
6.
RETENÇÃO DE INFORMAÇÃO – Objeto deve guardar informação
que será utilizada pelo sistema
SERVIÇOS NECESSÁRIOS – Conjunto de operações identificáveis
que podem mudar o valor de seus atributos
MÚLTIPLOS ATRIBUTOS – Objeto deve conter mais de um atributo
ATRIBUTOS COMUNS – Conjunto de atributos deve ser aplicado a
todos os objetos
OPERAÇÕES COMUNS – Conjunto de operações devem ser
aplicáveis a todos os objetos.
REQUISITOS ESSENCIAIS – Entidades externas que aparecem no
espaço problema que consomem e/ou produzem informação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
465
Análise Orientada a Objetos(OOA)

Em uma especificação:




NOMES são potenciais objetos (e classes)
VERBOS são potenciais métodos
A regra acima deve ser utilizada apenas como referência.
O entendimento do contexto, das necessidades do usuário são
fundamentais para classificar possíveis objetos e métodos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
466
52
2/2/2015
Análise Orientada a Objetos(OOA)
Exemplo Especificação
O software SafeHome possibilita que o dono da casa configure o sistema de segurança
quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e
interage com o dono da casa através de um teclado (key pad) e teclas de função contidas
no painel de controle do SafeHome.
Durante a instalação o painel de controle é usado para “programar” e configurar o sistema.
A cada sensor é atribuído um número e um tipo, uma senha mestra é programada para
armar e desarmar o sistema e números telefônicos são introduzidos para serem discados
quando ocorrer um evento sensor.
Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado ao
sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as
atividades de configuração do sistema, o software disca um número telefônico do serviço
de monitoração, oferece informações sobre o local, registrando a natureza do evento que
foi detectado. O número será novamente discado a 20 segundos até que a ligação
telefônica seja completada.
Todas as interações com o SafeHome são gerenciadas por um subsistema de interação
com o usuário, que lê a entrada fornecida através do teclado e das chaves de função, exibe
mensagens de prompting e informações sobre o status do sistema no mostrador de cristal
líquido (LCD). A interação com o teclado assume a seguinte forma...
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
467
Análise Orientada a Objetos(OOA)
Exemplo Especificação
O software SafeHome possibilita que o dono da casa configure o sistema de segurança
quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e
interage com o dono da casa através de um teclado (key pad) e teclas de função
contidas no painel de controle do SafeHome.
Durante a instalação o painel de controle é usado para “programar” e configurar o
sistema. A cada sensor é atribuído um número e um tipo, uma senha mestra é
programada para armar e desarmar o sistema e números telefônicos são introduzidos
para serem discados quando ocorrer um evento sensor.
Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado
ao sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as
atividades de configuração do sistema, o software disca um número telefônico do serviço
de monitoração, oferece informações sobre o local, registrando a natureza do evento
que foi detectado. O número será novamente discado a 20 segundos até que a ligação
telefônica seja completada.
Todas as interações com o SafeHome são gerenciadas por um subsistema de interação
com o usuário, que lê a entrada fornecida através do teclado e das chaves de função,
exibe mensagens de prompting e informações sobre o status do sistema no mostrador de
cristal líquido (LCD). A interação com o teclado assume a seguinte forma...
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
468
53
2/2/2015
Análise Orientada a Objetos(OOA)
NOME
CRITÉRIO
dono da casa
sistema de segurança
sensores
teclado
teclas de função
painel de controle
número
Tipo
senha mestra
números telefônicos
evento sensor
alarme sonoro
tempo de espera
Serviço de monitoração
informações sobre o local
natureza do evento
subsistema
entrada
chaves de função
mensagens
mostrador de cristal líquido
Papel ou entidade externa
Coisa
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Atributo do sensor
Atributo do sensor
Coisa
Coisa
Ocorrência
Entidade externa
Atributo do sistema
Unidade Organizacional ou Ent. Externa
Atributo do sistema
Atributo do sistema
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
469
Análise Orientada a Objetos(OOA)
NOME
CRITÉRIO
dono da casa
sistema de segurança
sensores
teclado
teclas de função
painel de controle
número
Tipo
senha mestra
números telefônicos
evento sensor
alarme sonoro
tempo de espera
Serviço de monitoração
informações sobre o local
natureza do evento
subsistema
entrada
chaves de função
mensagens
mostrador de cristal líquido
Rejeitado: 1 e 2 falham embora 6 se aplique
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Aceito: 2, 3, 4, 5 e 6
Rejeitado: 3 falha
Rejeitado: 1 e 2 falham embora 6 se aplique
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Rejeitado: 3 falha
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
470
54
2/2/2015
Identificação de Objetos



Os objetos do painel de controle serão considerados separadamente.
Os objetos abaixo são o ponto de partida para o desenvolvimento do
sistema
Objetos ainda não possuem atributos e métodos
class Classes
Sistema
PainelControle
Sensor
-
atributos
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
+
metodos() : void
Ev entoSensor
AlarmeSonoro
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
Engenharia de Software
471
Prof. Flávio de Oliveira Silva, Ph.D.
Especificação de Atributos


Necessário estudar e analisar a descrição do sistema
Pergunta Importante – “Quais informações definem este
objeto?”
class Classes
Sistema
PainelControle
-
senhaMestra
tempoEspera
numerosTelefonicos
informacoesLocal
naturezaEvento
+
metodos() : void
Sensor
-
atributos
+
metodos() : void
Ev entoSensor
-
tipo
numero
+
metodos() : void
AlarmeSonoro
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
472
55
2/2/2015
Definição dos Métodos


Necessário estudar e analisar a descrição do sistema
Verbos são potenciais operações
Configure
Instalado
Monitora
Ligados
Interage
Instalação
“programar”
configurar
programada
armar
desarmar
introduzidos
serem discados
ocorrer
sentido
dispara
especificado
configuração
disca
registrando
detectado
Discado
ligação
interações
gerenciadas
interação
lê
fornecida
exibe
class Classes
Sistema
-
senhaMestra
tempoEspera
numerosTelefonicos
informacoesLocal
naturezaEvento
+
+
+
+
+
+
programar() : void
armar() : void
desarmar() : void
monitorar() : void
dispararAlarme() : void
discar() : void
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
473
Análise Orientada a Objetos(OOA)
O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um
sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB).
À medida que são registrados buracos de rua, eles recebem um número de identificação e
são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10),
localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço da
rua) e prioridade de reparo (determinada a partir do tamanho do buraco).
Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e
tamanho do buraco, número de identificação da equipe de reparos, número de pessoas na
equipe, equipamentos designados, horas aplicadas ao reparo, status do trabalho (em
andamento, concluído, não concluído), quantidade de material de enchimento usado e
custo do reparo (computado a partir das horas trabalhadas, número pessoas, material e
equipamentos usados).
Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre danos
registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número
telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema on-line;
as consultas devem ser feitas interativamente.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
474
56
2/2/2015
Análise Orientada a Objetos(OOA)
O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um
sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB).
À medida que são registrados buracos de rua, eles recebem um número de identificação
e são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10),
localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço
da rua) e prioridade de reparo (determinada a partir do tamanho do buraco).
Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e
tamanho do buraco, número de identificação da equipe de reparos, número de
pessoas na equipe, equipamentos designados, horas aplicadas ao reparo, status do
trabalho (em andamento, concluído, não concluído), quantidade de material de enchimento
usado e custo do reparo (computado a partir das horas trabalhadas, número pessoas,
material e equipamentos usados).
Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre
danos registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número
telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema online; as consultas devem ser feitas interativamente.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
475
Identificação dos Objetos
NOMES
departamento
sistema
buracos
número de identificação
endereço da rua
tamanho
localização
bairro
prioridade
ordem de trabalho
número de identificação da equipe
número de pessoas
equipamentos
horas
quantidade
custo
arquivo de danos
nome do cidadão
Endereço
número telefônico
tipo de dano
CLASSIFICAÇÃO
Unidade Organizacional
coisa
coisa
coisa
coisa
coisa
coisa
bairro
coisa
coisa
coisa
coisa
coisa
coisa
coisa
coisa
estrutura
coisa
coisa
coisa
coisa
ANÁLISE
Rejeitado: 1 e 2 Falham
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se Aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
476
57
2/2/2015
Identificação dos Atributos
NOMES
departamento
sistema
buracos
número de identificação
endereço da rua
tamanho
localização
bairro
prioridade
ordem de trabalho
número de identificação da equipe
número de pessoas
equipamentos
horas
quantidade
custo
arquivo de danos
nome do cidadão
Endereço
número telefônico
tipo de dano
CLASSIFICAÇÃO
Unidade Organizacional
coisa
coisa
coisa
coisa
coisa
coisa
bairro
coisa
coisa
coisa
coisa
coisa
coisa
coisa
coisa
estrutura
coisa
coisa
coisa
coisa
ANÁLISE
Rejeitado: 1 e 2 Falham
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Aceito: Todas se Aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Aceito: Todas se aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Engenharia de Software
477
Prof. Flávio de Oliveira Silva, Ph.D.
Identificando Classes e Atributos

Além dos objetos mostrados a seguir que são identificados diretamente
a partir da especificação do sistema outros objetos podem ser
necessários dependendo de como o sistema será construído. (Ex.:
Equipe; Trabalhador; etc.)
class Classes
Sistema
OrdemTrabalho
Buraco
+
identificador
endereco
tamanho
localizacao
bairro
prioridade
-
localizacao
tamanho
equipe
equipamentos
horas
status
quantidadeMaterial
custo
+
metodos() : void
Dano
-
cidadao
endereco
telefone
tipo
quantia
+
metodos() : void
Equipe
-
numeroIdentificacao
+
metodos() : void
metodos() : void
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
478
58
2/2/2015
Identificando os Métodos

Verbos destacados







registrados
Recebem
Armazenados
Associados
Guardar
Consultar
Outras operações serão necessárias para que o sistema funcione
corretamente
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
479
Análise Orientada a Objetos (OOA)
Projeto Orientado a Objetos (OOD)



As técnicas tradicionais (Análise e Projeto Estruturado) não são
adequadas para o desenvolvimento de software utilizando a orientação à
objetos.
A utilização do orientação à Objetos solicita uma nova forma de abstrair e
entender o problema.
A linguagem UML é um padrão de diagramação para visualizar os
resultados da análise e projeto orientados à objetos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
480
59
2/2/2015
Análise Orientada a Objetos (OOA)
Projeto Orientado a Objetos (OOD)

Exemplo

O conceito “Livro” em um sistema de biblioteca
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
481
Análise Orientada a Objetos(OOA)

Objetivo básico


Identificar classes a partir das quais objetos serão representados como
instâncias
Envolve as seguintes tarefas




Identificação de Objetos
Especificação de Atributos
Definição de métodos
Comunicações entre objetos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
482
60
2/2/2015
Análise Orientada a Objetos(OOA)

IDENTIFICAÇÃO DE OBJETOS







Entidades externas (Outros sistemas; dispositivos;Pessoas)
Coisas ligadas ao domínio do problema (Relatórios;Displays;…)
Ocorrências ou Eventos (Conclusão de um movimento;Alarme
disparado; Clique do mouse; etc.)
Papéis ou funções (Engenheiro; Gerente; Vendedor) desempenhados
por pessoas
Unidades organizacionais (Grupo; Equipe;…)
Lugares (Piso de fábrica; área de descarga)
Estruturas (Sensores; veículos de quatro rodas;…)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
483
Análise Orientada a Objetos(OOA)

IDENTIFICAÇÃO DE OBJETOS – CRITÉRIOS
1.
2.
3.
4.
5.
6.
RETENÇÃO DE INFORMAÇÃO – Objeto deve guardar informação
que será utilizada pelo sistema
SERVIÇOS NECESSÁRIOS – Conjunto de operações identificáveis
que podem mudar o valor de seus atributos
MÚLTIPLOS ATRIBUTOS – Objeto deve conter mais de um atributo
ATRIBUTOS COMUNS – Conjunto de atributos deve ser aplicado a
todos os objetos
OPERAÇÕES COMUNS – Conjunto de operações devem ser
aplicáveis a todos os objetos.
REQUISITOS ESSENCIAIS – Entidades externas que aparecem no
espaço problema que consomem e/ou produzem informação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
484
61
2/2/2015
Análise Orientada a Objetos(OOA)

Em uma especificação:




NOMES são potenciais objetos (e classes)
VERBOS são potenciais métodos
A regra acima deve ser utilizada apenas como referência.
O entendimento do contexto, das necessidades do usuário são
fundamentais para classificar possíveis objetos e métodos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
485
Análise Orientada a Objetos(OOA)
Exemplo Especificação
O software SafeHome possibilita que o dono da casa configure o sistema de segurança
quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e
interage com o dono da casa através de um teclado (key pad) e teclas de função contidas
no painel de controle do SafeHome.
Durante a instalação o painel de controle é usado para “programar” e configurar o sistema.
A cada sensor é atribuído um número e um tipo, uma senha mestra é programada para
armar e desarmar o sistema e números telefônicos são introduzidos para serem discados
quando ocorrer um evento sensor.
Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado ao
sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as
atividades de configuração do sistema, o software disca um número telefônico do serviço
de monitoração, oferece informações sobre o local, registrando a natureza do evento que
foi detectado. O número será novamente discado a 20 segundos até que a ligação
telefônica seja completada.
Todas as interações com o SafeHome são gerenciadas por um subsistema de interação
com o usuário, que lê a entrada fornecida através do teclado e das chaves de função, exibe
mensagens de prompting e informações sobre o status do sistema no mostrador de cristal
líquido (LCD). A interação com o teclado assume a seguinte forma...
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
486
62
2/2/2015
Análise Orientada a Objetos(OOA)
Exemplo Especificação
O software SafeHome possibilita que o dono da casa configure o sistema de segurança
quando ele for instalado, monitora todos os sensores ligados ao sistema de segurança e
interage com o dono da casa através de um teclado (key pad) e teclas de função
contidas no painel de controle do SafeHome.
Durante a instalação o painel de controle é usado para “programar” e configurar o
sistema. A cada sensor é atribuído um número e um tipo, uma senha mestra é
programada para armar e desarmar o sistema e números telefônicos são introduzidos
para serem discados quando ocorrer um evento sensor.
Quando um evento sensor é sentido pelo software, ele dispara um alarme sonoro ligado
ao sistema. Após um tempo de espera, que é especificado pelo dono da casa durante as
atividades de configuração do sistema, o software disca um número telefônico do serviço
de monitoração, oferece informações sobre o local, registrando a natureza do evento
que foi detectado. O número será novamente discado a 20 segundos até que a ligação
telefônica seja completada.
Todas as interações com o SafeHome são gerenciadas por um subsistema de interação
com o usuário, que lê a entrada fornecida através do teclado e das chaves de função,
exibe mensagens de prompting e informações sobre o status do sistema no mostrador de
cristal líquido (LCD). A interação com o teclado assume a seguinte forma...
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
487
Análise Orientada a Objetos(OOA)
NOME
CRITÉRIO
dono da casa
sistema de segurança
sensores
teclado
teclas de função
painel de controle
número
Tipo
senha mestra
números telefônicos
evento sensor
alarme sonoro
tempo de espera
Serviço de monitoração
informações sobre o local
natureza do evento
subsistema
entrada
chaves de função
mensagens
mostrador de cristal líquido
Papel ou entidade externa
Coisa
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Atributo do sensor
Atributo do sensor
Coisa
Coisa
Ocorrência
Entidade externa
Atributo do sistema
Unidade Organizacional ou Ent. Externa
Atributo do sistema
Atributo do sistema
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Entidade externa
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
488
63
2/2/2015
Análise Orientada a Objetos(OOA)
NOME
CRITÉRIO
dono da casa
sistema de segurança
sensores
teclado
teclas de função
painel de controle
número
Tipo
senha mestra
números telefônicos
evento sensor
alarme sonoro
tempo de espera
Serviço de monitoração
informações sobre o local
natureza do evento
subsistema
entrada
chaves de função
mensagens
mostrador de cristal líquido
Rejeitado: 1 e 2 falham embora 6 se aplique
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Aceito: 2, 3, 4, 5 e 6
Rejeitado: 3 falha
Rejeitado: 1 e 2 falham embora 6 se aplique
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Rejeitado: 3 falha
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Engenharia de Software
489
Prof. Flávio de Oliveira Silva, Ph.D.
Identificação de Objetos



Os objetos do painel de controle serão considerados separadamente.
Os objetos abaixo são o ponto de partida para o desenvolvimento do
sistema
Objetos ainda não possuem atributos e métodos
class Classes
Sistema
PainelControle
Sensor
-
atributos
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
+
metodos() : void
Ev entoSensor
AlarmeSonoro
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
490
64
2/2/2015
Especificação de Atributos


Necessário estudar e analisar a descrição do sistema
Pergunta Importante – “Quais informações definem este
objeto?”
class Classes
Sistema
PainelControle
-
senhaMestra
tempoEspera
numerosTelefonicos
informacoesLocal
naturezaEvento
+
metodos() : void
Sensor
-
atributos
+
metodos() : void
Ev entoSensor
-
tipo
numero
+
metodos() : void
AlarmeSonoro
-
atributos
-
atributos
+
metodos() : void
+
metodos() : void
Engenharia de Software
491
Prof. Flávio de Oliveira Silva, Ph.D.
Definição dos Métodos


Necessário estudar e analisar a descrição do sistema
Verbos são potenciais operações
Configure
Instalado
Monitora
Ligados
Interage
Instalação
“programar”
configurar
programada
armar
desarmar
introduzidos
serem discados
ocorrer
sentido
dispara
especificado
configuração
disca
registrando
detectado
Discado
ligação
interações
gerenciadas
interação
lê
fornecida
exibe
class Classes
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Sistema
-
senhaMestra
tempoEspera
numerosTelefonicos
informacoesLocal
naturezaEvento
+
+
+
+
+
+
programar() : void
armar() : void
desarmar() : void
monitorar() : void
dispararAlarme() : void
discar() : void
492
65
2/2/2015
Análise Orientada a Objetos(OOA)
O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um
sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB).
À medida que são registrados buracos de rua, eles recebem um número de identificação e
são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10),
localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço da
rua) e prioridade de reparo (determinada a partir do tamanho do buraco).
Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e
tamanho do buraco, número de identificação da equipe de reparos, número de pessoas na
equipe, equipamentos designados, horas aplicadas ao reparo, status do trabalho (em
andamento, concluído, não concluído), quantidade de material de enchimento usado e
custo do reparo (computado a partir das horas trabalhadas, número pessoas, material e
equipamentos usados).
Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre danos
registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número
telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema on-line;
as consultas devem ser feitas interativamente.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
493
Análise Orientada a Objetos(OOA)
O departamento de obras públicas da cidade de Uberlândia decidiu desenvolver um
sistema de computador para rastreamento e conserto de buracos de rua (SIRCOB).
À medida que são registrados buracos de rua, eles recebem um número de identificação
e são armazenados de acordo com o endereço da rua, tamanho (numa escala de 0 a 10),
localização (no meio dar rua; na calçada; etc.), bairro (determinado a partir do endereço
da rua) e prioridade de reparo (determinada a partir do tamanho do buraco).
Dados de ordem de trabalho são associados a cada buraco, e eles incluem localização e
tamanho do buraco, número de identificação da equipe de reparos, número de
pessoas na equipe, equipamentos designados, horas aplicadas ao reparo, status do
trabalho (em andamento, concluído, não concluído), quantidade de material de enchimento
usado e custo do reparo (computado a partir das horas trabalhadas, número pessoas,
material e equipamentos usados).
Finalmente, um arquivo de danos ocorridos é criado para guardar informações sobre
danos registrados devido ao buraco, o qual inclui o nome do cidadão, endereço, número
telefônico, tipo de dano e a quantia em reais a ser paga. O SIRCOB é um sistema online; as consultas devem ser feitas interativamente.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
494
66
2/2/2015
Identificação dos Objetos
NOMES
departamento
sistema
buracos
número de identificação
endereço da rua
tamanho
localização
bairro
prioridade
ordem de trabalho
número de identificação da equipe
número de pessoas
equipamentos
horas
quantidade
custo
arquivo de danos
nome do cidadão
Endereço
número telefônico
tipo de dano
CLASSIFICAÇÃO
Unidade Organizacional
coisa
coisa
coisa
coisa
coisa
coisa
bairro
coisa
coisa
coisa
coisa
coisa
coisa
coisa
coisa
estrutura
coisa
coisa
coisa
coisa
ANÁLISE
Rejeitado: 1 e 2 Falham
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se Aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Aceito: Todas se aplicam
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Rejeitado: 3 falha
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
495
Identificação dos Atributos
NOMES
departamento
sistema
buracos
número de identificação
endereço da rua
tamanho
localização
bairro
prioridade
ordem de trabalho
número de identificação da equipe
número de pessoas
equipamentos
horas
quantidade
custo
arquivo de danos
nome do cidadão
Endereço
número telefônico
tipo de dano
CLASSIFICAÇÃO
Unidade Organizacional
coisa
coisa
coisa
coisa
coisa
coisa
bairro
coisa
coisa
coisa
coisa
coisa
coisa
coisa
coisa
estrutura
coisa
coisa
coisa
coisa
ANÁLISE
Rejeitado: 1 e 2 Falham
Aceito: Todas se aplicam
Aceito: Todas se aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Aceito: Todas se Aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Aceito: Todas se aplicam
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Rejeitado: 3 falha (ATRIBUTO)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
496
67
2/2/2015
Identificando Classes e Atributos

Além dos objetos mostrados a seguir que são identificados diretamente
a partir da especificação do sistema outros objetos podem ser
necessários dependendo de como o sistema será construído. (Ex.:
Equipe; Trabalhador; etc.)
class Classes
Sistema
OrdemTrabalho
Buraco
+
identificador
endereco
tamanho
localizacao
bairro
prioridade
-
localizacao
tamanho
equipe
equipamentos
horas
status
quantidadeMaterial
custo
+
metodos() : void
Dano
-
cidadao
endereco
telefone
tipo
quantia
+
metodos() : void
Equipe
-
numeroIdentificacao
+
metodos() : void
metodos() : void
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
497
Identificando os Métodos

Verbos destacados







registrados
Recebem
Armazenados
Associados
Guardar
Consultar
Outras operações serão necessárias para que o sistema funcione
corretamente
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
498
68
2/2/2015
UML – Diagramas


Um diagrama é a apresentação gráfica de um conjunto de elementos,
onde os vértices são ITENS e os arcos RELACIONAMENTOS
UML 2.0 possui os seguintes diagramas:













Diagrama de Classes (Class Diagram)
Diagrama de Objetos (Object Diagram)
Diagrama de Componente (Component Diagram)
Diagrama de Implantação (Deployment Diagram)
Diagrama de Composição (Composite Struture Diagram)
Diagrama de Pacotes (Package Diagram)
Diagrama de Caso de Uso (Use Case)
Diagrama de Seqüência (Sequence Diagram)
Diagrama de Comunicação (Communication Diagram)
Diagrama de Atividade (Activity Diagram)
Diagrama de Estados (State Machine Diagram)
Diagrama de Interação (Interaction Overview Diagram)
Diagrama de Tempo (Timing Diagram)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
499
UML – Diagramas


Os diagramas da UML podem ser divididos em dois grandes
grupos: DIAGRAMAS ESTRUTURAIS e DIAGRAMAS
COMPORTAMENTAIS
DIAGRAMA ESTRUTURAIS


Permitem modelar os aspectos estáticos de um sistema.
DIAGRAMA COMPORTAMENTAIS


Permitem modelar os aspectos dinâmicos de um sistema.
Os aspectos dinâmicos são as partes do sistema que sofrem
alteração durante a utilização do sistema
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
500
69
2/2/2015
UML – Diagramas Estruturais






Diagrama de Classes (Class Diagram)
Diagrama de Objetos (Object Diagram)
Diagrama de Componente (Component Diagram)
Diagrama de Implantação (Deployment Diagram)
Diagrama de Estrutura Composta (Composite Struture
Diagram)
Diagrama de Pacotes (Package Diagram)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
501
UML – Diagramas Comportamentais







Diagrama de Caso de Uso (Use Case)
Diagrama de Seqüência (Sequence Diagram)
Diagrama de Comunicação (Communication Diagram)
Diagrama de Atividade (Activity Diagram)
Diagrama de Estados (State Machine Diagram)
Diagrama de Geral Interação (Interaction Overview Diagram)
Diagrama de Tempo (Timing Diagram)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
502
70
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso



Este diagrama representa um conjunto de casos de uso, atores e seus
relacionamento.
Permitem visualizar o comportamento de um sistema, subsistema ou
classe a fim de que desenvolvedores e usuários possam se comunicar.
Usos


Modelagem do Contexto do Sistema



Modelagem do Contexto do Sistema e Modelagem dos Requisitos de um
Sistema
Mostra o sistema considerando os atores que se encontram de fora do
mesmo e sua ligação com o sistema.
Este diagrama é semelhante a um DFD de contexto.
Modelagem dos Requisitos do Sistema


Neste caso o diagrama irá representar um requisito do projeto.
A preocupação não é “como” o sistema faz mas “o que” o sistema faz. Este
tipo de diagrama está ligado à fase de ANÁLISE de cada uma das iterações.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
503
UML – Diagramas Comportamentais
Caso de Uso

Normalmente os casos de uso possuem uma descrição que contém uma
combinação de nome/verbo


Os atores são aqueles que interagem com o caso de uso




Exemplo: Criar Conta; Realizar Venda; Efetuar Pedido
Exemplos: Pessoas; Equipamentos; Outros Sistemas;
Casos de uso definem o escopo do sistema, facilitando o entendimento
da complexidade e tamanho do mesmo.
A “soma” dos casos de uso deve ser igual ao sistema como um todo.
Desta forma o que não é mostrado como caso de uso, não é parte do
sistema
O caso de uso descreve “o que” um sistema (ou subsistema) faz, mas
não descreve “como” isto é feito
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
504
71
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso

Os casos de uso podem ser organizados segundo suas
características:






Casos de Alto Risco
Casos básicos da Arquitetura
Casos que utilizam amplas funcionalidades do sistema
Casos de uso que necessitam de pesquisa ou que utilizam novas
tecnologias
Casos de Uso Acessórios
A partir da classificação dos casos de uso as iterações
devem ser planejadas, com o foco nos casos de uso de
maior prioridade, conforme a classificação realizada
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
505
UML – Diagramas Comportamentais
Caso de Uso




Os casos de uso são utilizados para a comunicação entre o
desenvolvedor e os usuários, devido a sua simplicidade
Os caso de uso são a base do desenvolvimento, pois podem ser
utilizados para o planejamento de todas as fases do desenvolvimento e
de cada uma das iterações.
Os casos de uso podem ser utilizados como base a criação de testes do
sistema
Pode-se também utilizá-los como base para a criação da documentação
para o sistema.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
506
72
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso

Complexidade




Um caso de uso não deve ser complexo
Basicamente o caso de uso deve: “Satisfazer o objetivo do Ator”
Esta regra é valida principalmente nas etapas iniciais
Posteriormente, o caso de uso de pode ser decomposto e detalhado nas
etapas seguintes
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
507
UML – Diagramas Comportamentais
Caso de Uso

Complexidade

Considere uma série de iterações entre o usuário e um sistema para
saques bancários:








Inserir Cartão
Entrar com a Senha
Selecionar o Valor a ser sacado
Confirmar o valor a ser sacado
Remover o Cartão
Nas etapas iniciais não é necessário um caso de uso com tantos
detalhes.
A complexidade será tratada nas fases seguintes, inclusive,podendo
ser utilizados outros diagramas
O ideal é que o diagrama acima tenha apenas um caso de uso:
“Realizar Saque”
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
508
73
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso - Relacionamentos

Os seguintes relacionamentos são utilizados no diagrama de
casos de uso




Associação
Generalização
Extensão
Inclusão
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
509
UML – Diagramas Comportamentais
Caso de Uso - Relacionamentos

Associação


Representa a ligação entre um ator e um caso de uso
O ator pode ser um outro sistema, um usuário, um dispositivo de
hardware; etc.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
510
74
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso - Relacionamentos

Generalização



A generalização indica que o caso de uso filho herda o
comportamento do caso de uso pai
Porém o caso de uso filho contém terá comportamentos que
sobrescrevem aqueles do pai ou mesmo comportamentos
particulares.
A generalização pode ser aplicada tanto ao caso de uso como ao
ator.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
511
UML – Diagramas Comportamentais
Caso de Uso - Relacionamentos

Inclusão



Na relação de inclusão um caso de uso, inclui em seu
comportamento, o comportamento de outro caso de uso
A inclusão permite que o caso de uso se complemente adicionando o
comportamento do caso de uso incluído
O caso de uso depende do caso de uso incluído para efetuar suas
operações
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
512
75
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso - Relacionamentos

Extensão




A extensão de um caso de uso é utilizada para modelar um
comportamento opcional
Desta forma separa-se o comportamento obrigatório do
comportamento opcional
Os pontos em que o caso de uso pode ser estendido são conhecidos
como “pontos de extensão” e devem ser bem definidos
Através da extensão é possível adicionar diferentes comportamentos
a um caso de uso
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
513
UML – Diagramas Comportamentais
Caso de Uso - Exemplo

Diagrama de Contexto



Caso de uso que mostra a
visão geral de um sistema
com os seus principais
casos de uso e atores
envolvidos
Os casos de usos estão em
pacotes.
Alguns atores como TEF,
SPC e fornecedor na
realidade representam
outros sistemas
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
514
76
2/2/2015
UML – Diagramas Comportamentais
Caso de Uso - Exemplo


Caso de uso que mostra uma
parte do sistema anterior em
maiores detalhes
O caso de uso principal –
“Vender Produto” foi um pouco
detalhado indicando diferentes
operações de venda que
podem ser realizadas e ainda
a possível necessidade de
atualizar o cadastro de cliente
no momento da venda.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
515
Praticando seus conceitos...

Considerando o sistema que você está trabalhando atualmente criar um
diagrama de caso de uso, utilizando os seguintes conceitos:


Associação; Generalização; Inclusão e Extensão
Considere um sistema na Web que será responsável por gerenciar
contatos.

Além de cadastrar os contatos é possível; consultar os contatos; alterar suas
informações; imprimir seus dados e finalmente enviar e-mail para um
determinado contato
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
516
77
2/2/2015
UML – Diagramas Estruturais
Classes



Mostra um conjunto de classes, interfaces e colaborações
bem como seus relacionamentos
O diagrama de classes representa aspectos estruturais de
um software
No uso da Orientação a Objetos em última análise o objetivo
das etapas concepção e Elaboração é estabelecer quais as
classes serão criadas, quais seus atributos e os seus
métodos, além dos relacionamentos entre estas várias
classes.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
517
UML – Diagramas Estruturais
Classes



A medida que um software é modelado as classes necessárias bem
como suas características como atributos e métodos vão sendo
detalhadas.
Existem classes que estão ligadas ao domínio do problema. Neste
caso as classes representam objetos existentes no mundo real e
ligados a um software em questão.
Exemplos: Pedido; Cliente; Produto; Empregado; Paciente; Curso;
etc.
Existem classe que estão ligadas ao domínio da solução e que existem
para representar objetos existentes do ponto de vista lógico para a
construção de um software.
Exemplos: Janela; Fila; Lista; Pilha; Aplicacao; Menu; Form;
Window; Vector; Conexao; HttpServlet; etc.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
518
78
2/2/2015
UML – Diagramas Estruturais
Classes - Usos


O diagrama de classes pode ser representado em vários níveis de detalhamento
Diagrama de Classes em nível de Modelamento do Negócio e Especificação
Requisitos


Diagrama de Classes em nível de Análise



Neste caso o diagrama contém poucos detalhes sobre cada classe, visto que as
características do sistema, seu escopo e requisitos ainda estão sendo especificados
Contém mais detalhes sobre as classes como seus atributos e alguns métodos
Em geral representa apenas classes ligadas ao domínio do problema
Diagrama de Classes em Nível de Projeto


Contém todos os detalhes referentes aos atributos e ao métodos como seu tipo, já
mapeado em alguma linguagem de programação, os parâmetros de cada método e
seu tipos de retorno
Contém classes ligadas tanto ao domínio do problema quanto ao domínio da solução.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
519
UML – Diagramas Estruturais
Classes - Usos

USOS: Modelamento do Vocabulário; Modelamento de colaborações;
Modelamento lógico do banco de dados





Modelamento do Vocabulário
 O diagrama de classes pode ser utilizado para a modelagem do vocabulário do
sistema que consiste nas classes, seus atributos e operações
Modelamento de Colaborações
 Um colaboração é um conjunto de classes que realizam determinados papéis.
Através do diagrama de classes é possível mostrar a sua parte estrutural
Modelamento Lógico do Banco de Dados
 Os diagramas de classes da UML são um superconjunto dos diagramas de
entidade-relacionamento (E-R). Os diagramas de classes vão um pouco além,
permitindo ainda a modelagem de comportamentos, que poderão ser tornar
procedimentos armazenados (stored procedures)
Um mesmo aspecto do sistema pode ser representado por diferentes diagramas
de classe.
Exemplo: um diagrama pode privilegiar apenas os relacionamentos de herança,
outro as dependências entre as classe e outro ainda as associações entre as
mesmas
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
520
79
2/2/2015
UML – Diagramas Estruturais
Classes - Exemplos

Diagrama de Classe em nível de Especificação de
Requisitos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
521
UML – Diagramas Estruturais
Classes - Exemplos

Diagrama de Classe em nível de Análise
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
522
80
2/2/2015
UML – Diagramas Estruturais
Classes - Exemplos

Diagrama de Classe em nível de Projeto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
523
UML – Diagramas Estruturais
Classes - Exemplos

Diagrama de Classe em nível de Projeto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
524
81
2/2/2015
Praticando seus conceitos...

Considere um sistema na Web que será responsável por gerenciar
contatos, conforme caso de uso anterior


Informações adicionais





Além de cadastrar os contatos é possível; consultar os contatos; alterar suas
informações; imprimir seus dados e finalmente enviar e-mail para um
determinado contato
Um usuário pode possuir vários contatos e o sistema deverá manter os dados
de cada usuário individualmente
Um contato pode possui até 4 diferentes endereços de e-mail e para cada email está associado um tipo (comercial; particular; prioritário; final de semana;
etc.)
As informações associadas ao contato são as seguintes: Nome; Telefone
Principal; Email
Construir os diagramas de classe em nível de análise
Construir um diagrama de classe que representa a modelagem de dados
Engenharia de Software
525
Prof. Flávio de Oliveira Silva, Ph.D.
Praticando seus conceitos...

Informações adicionais x Representação em UML
1.
2.
3.
Um usuário pode possuir vários contatos e o sistema deverá manter os dados de cada
usuário individualmente
Um contato pode possui vários endereços de e-mail e para cada e-mail está associado
um tipo (comercial; particular; prioritário; final de semana; etc.)
As informações associadas ao contato são as seguintes: Nome; Telefone Principal;
Email
class Contatos-Class-An...
class Contatos-Class-...
Contato
class Contatos-Class-Analysis
Usuario
Contato
-
Contato
1
nome: String
telefone: String
email: Email
1
0..*
1..*
Email
Regra 1
-
tipo: String
email: String
Regra 3
Regra 2
526
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
82
2/2/2015
Praticando seus conceitos...

Diagramas de classe em nível de análise
1.
2.
3.
Um usuário pode possuir vários contatos e o sistema deverá manter os dados de cada
usuário individualmente
Um contato pode possui vários endereços de e-mail e para cada e-mail está associado
um tipo (comercial; particular; prioritário; final de semana; etc.)
As informações associadas ao contato são as seguintes: Nome; Telefone Principal;
Email
class Contatos-Class-Analysis
Contato
Usuario
-
login: String
senha: String
+
login()
1
0..*
-
nome: String
telefone: String
email: Email
+
+
+
+
+
create() : void
read() : void
update() : void
delete() : void
sendMail() : void
Email
1
-
tipo: String
email: String
1..*
527
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
Praticando seus conceitos...

Diagrama de classe que representa a modelagem de dados
class Contatos-Class-DataModel
TContato
TUsuario
«column»
*PK id: ROWID
login: VARCHAR2(30)
senha: VARCHAR2(15)
«PK»
+
PK_TUsuario(ROWID)
+PK_TUsuario
(idUser = id) +FK_TContato_TUsuario
0..*
«FK»
1
«column»
*PK id: ROWID
FK idUser: ROWID
nome: VARCHAR2(50)
telefone: VARCHAR2(15)
«FK»
+
FK_TContato_TUsuario(ROWID)
+PK_TContato
1
«PK»
+
PK_TContato(ROWID)
(idContact = id)
«FK»
TEmail
+FK_TEmail_TContato
«column»
*PK id: ROWID
FK idContact: ROWID
tipo: VARCHAR2(30)
email: VARCHAR2(50)
0..*
«FK»
+
FK_TEmail_TContato(ROWID)
«PK»
+
PK_TEmail(ROWID)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
528
83
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Seqüência



Este diagrama mostra as interações entre um conjunto de
objetos e seus relacionamentos, incluindo as mensagens
que serão trocadas entre os mesmos.
Consiste de uma tabela que mostra objetos distribuídos no
eixo X e mensagens em ordem crescente de tempo no eixo
Y.
Os Diagramas de Seqüência são conhecidos também
como Diagramas de Interação e a partir de um diagrama
de seqüência é possível obter o diagrama de comunicação a
ele relacionado
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
529
UML – Diagramas Comportamentais
Diagrama de Seqüência - Exemplo



Diagrama de Seqüência em
nível de modelamento de
negócio e especificação de
requisitos
Mostra um fluxo de trabalho,
indicando as mensagens
trocadas no tempo.
Neste caso as mensagens
ainda estão em um alto nível
de abstração
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
530
84
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Seqüência - Exemplo



Diagrama de Seqüência em
nível implementação
Realiza o modelamento de
um método (ou operação)
Neste caso as mensagens
ainda estão em um baixo
nível de abstração, sendo
que o diagrama está muito
próximo do código-fonte
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
531
UML – Diagramas Comportamentais
Diagrama de Comunicação



Este diagrama mostra as interações entre um conjunto de
objetos e seus relacionamentos, incluindo as mensagens
que serão trocadas entre os mesmos, considerando a ordem
seqüencial que estas mensagens ocorrem entre os vários
objetos.
Os Diagramas de Comunicação são conhecidos também
como Diagramas de Interação e a partir de um diagrama de
comunicação é possível obter o diagrama de seqüência a ele
relacionado
USOS: Modelagem de Fluxos de Controle Por Organização
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
532
85
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Comunicação - Exemplo


Diagrama de comunicação em nível de implementação
Este diagrama é análogo ao diagrama de seqüência
apresentado anteriormente
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
533
UML – Diagramas Comportamentais
Diagrama de Atividades





Este diagrama mostra o fluxo de uma atividade para outra.
Uma atividade é uma execução em andamento em uma
máquina de estados.
Um diagrama de atividades pode ser decomposto em outro
diagrama de atividades e além disso as atividades podem
conter operações de alto nível.
A utilização das “raias de natação” são úteis para mostrar
processos de negócio.
USOS: Modelagem de Fluxo de Trabalho (nível
especificação); Modelagem de uma Operação (nível projeto);
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
534
86
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Atividades

Modelagem do Fluxo de Trabalho




Através do diagrama é possível modelar os processo de negócios e regras,
considerando o relacionamento entre vários sistemas e atores
É possível especificar e detalhar regras de negócios em sistemas, que muitas das
vezes podem ser complexas, principalmente em sistemas de missão crítica e
corporativos
Pode ser utilizado para modelar os fluxos de um caso de uso
Modelagem de uma Operação


Neste caso o diagrama de atividades é semelhante a um fluxograma das ações de uma
operação.
A vantagem neste caso é que todos os elementos apresentados neste diagramas são
semanticamente relacionados com outros diagramas.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
535
UML – Diagramas Comportamentais
Diagrama de Atividades - Exemplo

Diagrama de Atividades em alto
nível


Pode ser utilizado para detalhar aspectos
de um caso de uso
Desta forma o diagrama auxiliará no
entendimento do caso de uso e nas
atividades que serão realizadas
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
536
87
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Atividades - Exemplo

Diagrama Atividades em nível de implementação


Neste caso a atividade representa a chamada de métodos
Pode ser utilizado para representar aspectos do código-fonte
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
537
UML – Diagramas Comportamentais
Diagrama de Atividades - Exemplo

Diagrama Atividades em nível de Especificação



Os diagramas abaixo mostram como podem ser utilizados sinais em um diagrama de
atividade.
Um sinal pode ser enviado, recebido, ou ainda ser um sinal que indica algum momento
no tempo
As junções (joint) e bifurcações (fork) podem ter associadas às mesmas critérios
(joinspec) indicando quando a junção ou bifurcação pode acontecer
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
538
88
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Atividades - Ações

Modelamento de Sinais (Estado de Ação)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
539
UML – Diagramas Comportamentais
Diagrama de Atividades – Reg. Expansão

Regiões de Expansão





Indicam atividades que serão executadas para cada item de uma coleção de
valores ou objetos
A execução pode ser:
iterativa(iteractive) – Execução das atividades são feitas de forma
seqüencial
Paralela (parallel) – Execução das atividades podem ocorrer de forma
concorrente
Fluxo (Stream) – Execução das atividades acontece de forma contínua
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
540
89
2/2/2015
UML – Diagramas Comportamentais
Diagrama de Atividades - Sinais



É possível indicar a existência de parâmetros de entrada e de saída em uma
atividade
Além disso é possível indicar nós de expansão que representam uma coleção
como parâmetro de entrada e/ou saída de uma região de expansão ou atividade.
Esta coleção será então utilizada por outra atividade
Finalmente uma atividade pode possuir um nó objeto, também chamado pin. O
Pin representa um objeto que é enviado de uma atividade para outra e
consiste de uma outra forma de representar o fluxo de objeto
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
541
Praticando seus conceitos...

Considere um sistema na Web que será responsável por gerenciar contatos,
conforme caso de uso anterior


Informações adicionais






Além de cadastrar os contatos é possível; consultar os contatos; alterar suas
informações; imprimir seus dados e finalmente enviar e-mail para um determinado
contato
Um usuário pode possuir vários contatos e o sistema deverá manter os dados de cada
usuário individualmente
Um contato pode possui até 4 diferentes endereços de e-mail e para cada e-mail está
associado um tipo (comercial; particular; prioritário; final de semana; etc.)
As informações associadas ao contato são as seguintes: Nome; Telefone Principal;
Email
Construir os diagramas de classe em nível de análise
Construir um diagrama de classe que representa a modelagem de dados
Construir os diagramas de atividade. Cada atividade será então realizada por um
diagrama de seqüência, neste caso o interesse são nos objetos envolvidos
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
542
90
2/2/2015
Praticando seus conceitos...
Sistema de Pedidos

Informações Gerais







Existem 3 níveis de usuário: Supervisor; Gerente e Diretor, com acesso a diferentes funcionalidades
Supervisor pode cadastrar pedidos. O gerente aprova pedidos deste que o mesmo não ultrapasse o
valor total associado ao cliente para cada pedido. Caso ultrapasse o diretor é o responsável pela
aprovação.
Um pedido é associado a um cliente e o mesmo contém os itens de pedido. Cada item de pedido
contém: Produto; Quantidade; Valor total.
Caso não seja aprovado o pedido poderá também ser cancelado.
Após realizar o login na página principal são mostradas os pedidos que necessitam de aprovação.
Um supervisor tem sob sua responsabilidade um ou mais clientes.
Pede-se:




Criar os Diagramas de Casos de Uso
Modelar as classes considerando os conceitos de: Interface; Polimorfismo; Sobrecarga
Construir os diagramas de atividade que demonstre os fluxos principais do sistema.
Criar o diagrama de seqüência para os fluxos de aprovação, levando em conta os objetos de
negócio envolvidos.
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
543
Visões da Arquitetura

Cenários (Scenarios view)




Lógica (Logical View)




Foco em aspectos não funcionais e de comunicação entre os subsistemas da arquitetura
Diagramas: Atividade; Sequencia (diagramas comportamentais da UML)
Implementação (Deployment View)




Foco nas funcionalidades, normalmente dividida em subsistemas apresentando a estrutura (classes)
envolvidas
Diagramas: Classe, Pacotes
Processos (Process View)


Apresenta uma visão próxima do usuário, descrevendo cenários de uso da aplicação
Normalmente é a primeira visão construída
Diagramas: Casos de Uso
Útil para gestão de configuração
Apresenta pacotes e componentes que serão implantados
Diagramas: Componente; Pacotes
Física (Physical View)


Consiste do mapeamento do software no hardware onde será implantado
Diagramas: Implantação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
544
91
2/2/2015
Visões da Arquitetura
Diagramas UML
http://www.sparxsystems.com/downloads/whitepapers/FCGSS_US_WP_Applying_4+1_w_UML2.pdf
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
545
Disciplinas x Artefatos

Modelagem de Negócios



Requisitos






Visões do Projeto utilizando linguagem UML
Protótipos de Tela; Esquema de Banco de Dados; Integrações
Documento de Arquitetura de Software
Implementação
Testes



Especificação de Casos de Uso
Modelo de Domínio (Diagrama de Classes)
Análise e Projeto


Documento de Visão
Caso de Uso (Contexto do Sistema)
Planos de Testes
Casos de Testes
Implantação
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
546
92
2/2/2015
Visão de Cenários
(Scenarios view)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
547
Visão Lógica
(Logical View)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
548
93
2/2/2015
Visão de Processos
(Process View)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
549
Visão Implementação
(Implementation View)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
550
94
2/2/2015
Visão de Implantação
(Deployment View)
Engenharia de Software
Prof. Flávio de Oliveira Silva, Ph.D.
551
95