análise e projeto de software - ufuflavio/esof-files/files/2014-02/07-analise e... · análise e...

2/2/2015

1

Engenharia de SoftwareProf. Flávio de Oliveira Silva, Ph.D.

Análise e Projeto de Software

363

Material preparado pelo Prof. Marcelo Maia


Análise e Projeto

364

2/2/2015

2


Projeto e Modelos

CIM

PIM

PSM

Código

Elicitação deRequisitos

Projeto do Sistema

Implementação

Análise deRequisitos


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

2/2/2015

3


Influências no Projeto Requisitos funcionais

Requisitos não-funcionais


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

2/2/2015

4


Software architecture The design process for identifying the sub-systems making up a

system and the framework for sub-system control and communicationis architectural design.

The output of this design process is a description of the software architecture.

Fonte: Sommerville


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

2/2/2015

5


Advantages of explicit architecture

Stakeholder communication Architecture may be used as a focus of discussion by

system stakeholders.

System analysis 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


Architecture and system characteristics

Performance Localise critical operations and minimise communications.

Use large rather than fine-grain components.

Security Use a layered architecture with critical assets in the inner

layers.

Safety Localise safety-critical features in a small number of sub-

systems.

Availability Include redundant components and mechanisms for fault

tolerance.

Maintainability Use fine-grain, replaceable components.

Fonte: Sommerville

2/2/2015

6


Architectural conflictsTrade-offs Using large-grain components improves

performance but reduces maintainability.

Introducing redundant data improves availabilitybut makes security more difficult.

Localising safety-related features usually means more communication so degraded performance.

Fonte: Sommerville


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

2/2/2015

7


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


Packing robot control system

Fonte: Sommerville

2/2/2015

8


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


Diagrama de ComponentesSistema Web

2/2/2015

9


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


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

2/2/2015

10


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


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

2/2/2015

11


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 sub-system relationships.

Distribution model that shows how sub-systems are distributed across computers.

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

2/2/2015

12


OSI reference model

Fonte: Sommerville


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

2/2/2015

13


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


Padrões de Arquitetura

2/2/2015

14


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


Classificação de PadrõesPadrõ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)

Seu foco é na fase de análise ou modelamento de negócio

Padrões ligados ao domínio do problema

Padrões de Arquitetura (Architectural patterns) Seu foco é na arquitetura do software

Padrões de Projeto (Design patterns) 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

390

2/2/2015

15


Classificação de PadrõesPadrões Padrões de Análise (Analysis patterns)

Martin Fowler , 1996

Padrões de Arquitetura (Architectural patterns) 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

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

392

2/2/2015

16


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)

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

394

2/2/2015

17


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

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

Estruturais 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

395


Layer Permite o desenvolvimento de forma independente de diferentes partes

do sistema de software

396

2/2/2015

18


Layer Usos com outros padrões

397


Estilos (padrões) de ArquiteturaCamadas

Fonte: Buschmann

2/2/2015

19


Camadas (Windows NT)


Pipes and Filters Arquitetura especializada em tratar fluxos de dados (data streams)

400

2/2/2015

20


Pipes and Filters Uso com outros padrões

401


Estilos (padrões) de ArquiteturaDutos e Filtros

Fonte: Buschmann

2/2/2015

21


Estilos (padrões) de ArquiteturaDutos e Filtros

Fonte: Buschmann


Dutos e FiltrosAtividade começando com o data source

Fonte: Buschmann

2/2/2015

22


Dutos e FiltrosAtividade começando com o data sink

Fonte: Buschmann


Dutos e FiltrosMix pull-push (Source/Sink passivos)

Fonte: Buschmann

2/2/2015

23


Dutos e FiltrosFiltros ativos

Fonte: Buschmann


Broker - estrutura

Fonte: Buschmann

2/2/2015

24


Broker – dinâmicarequisição de serviço pelo cliente

Fonte: Buschmann


Broker – dinâmicauso de pontes

Fonte: Buschmann

2/2/2015

25


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

411


Model-View-Controller Uso do MVC com outros padrões

412

2/2/2015

26


MVC - Estrutura

Fonte: Buschmann


MVC – Dinâmica –Inicialização

Fonte: Buschmann

2/2/2015

27


MVC – Dinâmica

Tratamento de eventos

Fonte: Buschmann


Microkernel Uso

Arquitetura com suporte para escalabilidade funcional e adaptável para diferentes cenários de implantação

416

2/2/2015

28


Microkernel Uso com outros padrões

417


Microkernel

2/2/2015

29


MicrokernelCliente chamando serviço


MicrokernelServidor externo requisitando serviço

2/2/2015

30


Monolítico x Microkernel


JBoss - JMX

2/2/2015

31


JBoss – JMXCamadas - Microkernel


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

424

2/2/2015

32


Shared Repository Uso com outros padrões

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)

2/2/2015

33


Integração de Aplicações


Comparação das abordagens

2/2/2015

34


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)


Padrões para integração orientada a processosHub (broker) x Ponto a ponto

2/2/2015

35


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


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.

2/2/2015

36


Evolução de arquiteturas cliente-servidor


RPC requer o servidor sempre disponível...Middleware de Filas de Mensagens

2/2/2015

37


Adaptadores de formato


Message brokers

2/2/2015

38


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.


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.

2/2/2015

39


Evolução de EAI


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.

2/2/2015

40


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, implementation-independent interfaces.

Services are defined in a way that stress location and transport transparency.


SOA x Web Services

SOA

Architectural patterns for realizinga business design through theimplementation and composition ofsoftware services

A reference architecture model todecompose the functional componentsof an integration solution

A model for the life cycle andgovernance of services to help makereusability of services a reality

Web Services• A means to create well-

documented interfaces for services using standards such as Web services DefinitionLanguage (WSDL) anddocument-style SOAP

• A means to compose Web services using Business Process Execution Language for Web Services (WS-BPEL)

• Simple communication mechanisms that are location-transparent andinteroperable

2/2/2015

41


Evolução de EAI


444

SOAService Oriented Architecture

Consumidor Provedor

Registro

PublicaProcura

Interage

Contrato

2/2/2015

42


Abstrações de SOA


Elementos do serviço

2/2/2015

43


Elementos de SOA


Tipos de serviços

2/2/2015

44


Arquitetura tradicional x SOA


Exemplocompanhia aérea

2/2/2015

45


Evolução de EAI

• Providing a consumer view of a service decoupled from the deployed implementation of the underlying application or service

• Decoupling technical aspectsof service interactions

• Unifying access to applications using a common service model

• Providing dynamic access to services described in a service repository


SOA sem ESB

2/2/2015

46


SOA com ESB


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 consumersand service providers and recognize that consumers and providers may support or requiredifferent models.

Aggregate or disaggregate service requests and responses.

Support communication protocols between multiple platforms with appropriate qualitiesof service.

Provide messaging capabilities such as message correlation and publish/subscribe tosupport 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 event-driven integration, to extend the reach of the SOA.

2/2/2015

47


Visão de alto nível do ESB


Arquitetura de referência SOA

2/2/2015

48



Service component architecture

2/2/2015

49


Análise e Projeto Orientado a Objetos Utilizando UML 2.0

459


Orientação a ObjetosAlguns Conceitos OBJETO

MÉTODO

MENSAGEM

CLASSE

CLASSIFICAÇÃO

GENERALIZAÇÃO

ESPECIALIZAÇÃO

HERANÇA

POLIMORFISMO

SOBRECARGA

ENCAPSULAMENTO

ABSTRAÇÃO

MODULARIZAÇÃO

460

2/2/2015

50


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

461


Análise Orientada a Objetos (OOA)Projeto Orientado a Objetos (OOD) Exemplo

O conceito “Livro” em um sistema de biblioteca

462

2/2/2015

51


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

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;…)

464

2/2/2015

52


Análise Orientada a Objetos(OOA) IDENTIFICAÇÃO DE OBJETOS – CRITÉRIOS

1. RETENÇÃO DE INFORMAÇÃO – Objeto deve guardar informação que será utilizada pelo sistema

2. SERVIÇOS NECESSÁRIOS – Conjunto de operações identificáveis que podem mudar o valor de seus atributos

3. MÚLTIPLOS ATRIBUTOS – Objeto deve conter mais de um atributo

4. ATRIBUTOS COMUNS – Conjunto de atributos deve ser aplicado a todos os objetos

5. OPERAÇÕES COMUNS – Conjunto de operações devem ser aplicáveis a todos os objetos.

6. REQUISITOS ESSENCIAIS – Entidades externas que aparecem no espaço problema que consomem e/ou produzem informação

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

466

2/2/2015

53


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...

467



O software SafeHome possibilita que o dono da casa configure o sistema de segurançaquando 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çãocontidas 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 introduzidospara 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 eventoque 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çãocom 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...

468

2/2/2015

54


Análise Orientada a Objetos(OOA)

469

NOME CRITÉRIOdono da casa Papel ou entidade externasistema de segurança Coisasensores Entidade externateclado Entidade externateclas de função Entidade externapainel de controle Entidade externanúmero Atributo do sensorTipo Atributo do sensorsenha mestra Coisanúmeros telefônicos Coisaevento sensor Ocorrênciaalarme sonoro Entidade externatempo de espera Atributo do sistemaServiço de monitoração Unidade Organizacional ou Ent. Externainformações sobre o local Atributo do sistema

natureza do evento Atributo do sistemasubsistema Entidade externaentrada Entidade externachaves de função Entidade externamensagens Entidade externamostrador de cristal líquido Entidade externa


Análise Orientada a Objetos(OOA)NOME CRITÉRIO

dono da casa Rejeitado: 1 e 2 falham embora 6 se aplique

sistema de segurança Aceito: Todas se aplicamsensores Aceito: Todas se aplicamteclado Aceito: Todas se aplicamteclas de função Aceito: Todas se aplicam

painel de controle Aceito: Todas se aplicamnúmero Rejeitado: 3 falhaTipo Rejeitado: 3 falhasenha mestra Rejeitado: 3 falha

números telefônicos Rejeitado: 3 falhaevento sensor Aceito: Todas se aplicamalarme sonoro Aceito: 2, 3, 4, 5 e 6tempo de espera Rejeitado: 3 falha

Serviço de monitoração Rejeitado: 1 e 2 falham embora 6 se apliqueinformações sobre o local Rejeitado: 3 falhanatureza do evento Rejeitado: 3 falhasubsistema Aceito: Todas se aplicam

entrada Rejeitado: 3 falhachaves de função Aceito: Todas se aplicammensagens Aceito: Todas se aplicammostrador de cristal líquido Aceito: Todas se aplicam

470

2/2/2015

55


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

471

class Classes

Sistema

- atributos

+ metodos() : void

PainelControle

- atributos

+ metodos() : void

Sensor

- atributos

+ metodos() : void

Ev entoSensor

- atributos

+ metodos() : void

AlarmeSonoro

- atributos

+ metodos() : void



472

Necessário estudar e analisar a descrição do sistema

Pergunta Importante – “Quais informações definem este objeto?”

class Classes

Sistema

- senhaMestra- tempoEspera- numerosTelefonicos- informacoesLocal- naturezaEvento

+ metodos() : void

PainelControle

- atributos

+ metodos() : void

Sensor

- tipo- numero

+ metodos() : void

Ev entoSensor

- atributos

+ metodos() : void

AlarmeSonoro

- atributos

+ metodos() : void

2/2/2015

56


Definição dos Métodos Necessário estudar e analisar a descrição do sistema

Verbos são potenciais operações

473

class Classes

Sistema


+ programar() : void+ armar() : void+ desarmar() : void+ monitorar() : void+ dispararAlarme() : void+ discar() : void

Configure sentido

Instalado dispara

Monitora especificado

Ligados configuração

Interage disca

Instalação registrando

“programar” detectado

configurar Discado

programada ligação

armar interações

desarmar gerenciadas

introduzidos interação

serem discados lê

ocorrer fornecida

exibe


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.

474

2/2/2015

57



À medida que são registrados buracos de rua, eles recebem um número de identificaçãoe 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).



475


Identificação dos Objetos

476

NOMES CLASSIFICAÇÃO ANÁLISEdepartamento Unidade Organizacional Rejeitado: 1 e 2 Falhamsistema coisa Aceito: Todas se aplicamburacos coisa Aceito: Todas se aplicamnúmero de identificação coisa Rejeitado: 3 falhaendereço da rua coisa Rejeitado: 3 falhatamanho coisa Rejeitado: 3 falhalocalização coisa Rejeitado: 3 falhabairro bairro Rejeitado: 3 falhaprioridade coisa Rejeitado: 3 falhaordem de trabalho coisa Aceito: Todas se Aplicamnúmero de identificação da equipe coisa Rejeitado: 3 falhanúmero de pessoas coisa Rejeitado: 3 falhaequipamentos coisa Rejeitado: 3 falhahoras coisa Rejeitado: 3 falhaquantidade coisa Rejeitado: 3 falhacusto coisa Rejeitado: 3 falhaarquivo de danos estrutura Aceito: Todas se aplicamnome do cidadão coisa Rejeitado: 3 falhaEndereço coisa Rejeitado: 3 falhanúmero telefônico coisa Rejeitado: 3 falhatipo de dano coisa Rejeitado: 3 falha

2/2/2015

58


Identificação dos Atributos

477

NOMES CLASSIFICAÇÃO ANÁLISEdepartamento Unidade Organizacional Rejeitado: 1 e 2 Falhamsistema coisa Aceito: Todas se aplicamburacos coisa Aceito: Todas se aplicamnúmero de identificação coisa Rejeitado: 3 falha (ATRIBUTO)endereço da rua coisa Rejeitado: 3 falha (ATRIBUTO)tamanho coisa Rejeitado: 3 falha (ATRIBUTO)localização coisa Rejeitado: 3 falha (ATRIBUTO)bairro bairro Rejeitado: 3 falha (ATRIBUTO)prioridade coisa Rejeitado: 3 falha (ATRIBUTO)ordem de trabalho coisa Aceito: Todas se Aplicamnúmero de identificação da equipe coisa Rejeitado: 3 falha (ATRIBUTO)número de pessoas coisa Rejeitado: 3 falha (ATRIBUTO)equipamentos coisa Rejeitado: 3 falha (ATRIBUTO)horas coisa Rejeitado: 3 falha (ATRIBUTO)quantidade coisa Rejeitado: 3 falha (ATRIBUTO)

custo coisa Rejeitado: 3 falha (ATRIBUTO)arquivo de danos estrutura Aceito: Todas se aplicamnome do cidadão coisa Rejeitado: 3 falha (ATRIBUTO)Endereço coisa Rejeitado: 3 falha (ATRIBUTO)número telefônico coisa Rejeitado: 3 falha (ATRIBUTO)tipo de dano coisa Rejeitado: 3 falha (ATRIBUTO)


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.)

478

class Classes

Sistema

Buraco

- identificador- endereco- tamanho- localizacao- bairro- prioridade

+ metodos() : void

OrdemTrabalho

- localizacao- tamanho- equipe- equipamentos- horas- status- quantidadeMaterial- custo

+ metodos() : void

Dano

- cidadao- endereco- telefone- tipo- quantia

+ metodos() : void

Equipe

- numeroIdentificacao

+ metodos() : void

2/2/2015

59


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

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

480

2/2/2015

60


Análise Orientada a Objetos (OOA)Projeto Orientado a Objetos (OOD) Exemplo

O conceito “Livro” em um sistema de biblioteca

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


Definição de métodos

Comunicações entre objetos

482

2/2/2015

61


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;…)

483


Análise Orientada a Objetos(OOA) IDENTIFICAÇÃO DE OBJETOS – CRITÉRIOS

1. RETENÇÃO DE INFORMAÇÃO – Objeto deve guardar informação que será utilizada pelo sistema

2. SERVIÇOS NECESSÁRIOS – Conjunto de operações identificáveis que podem mudar o valor de seus atributos

3. MÚLTIPLOS ATRIBUTOS – Objeto deve conter mais de um atributo

4. ATRIBUTOS COMUNS – Conjunto de atributos deve ser aplicado a todos os objetos

5. OPERAÇÕES COMUNS – Conjunto de operações devem ser aplicáveis a todos os objetos.

6. REQUISITOS ESSENCIAIS – Entidades externas que aparecem no espaço problema que consomem e/ou produzem informação

484

2/2/2015

62


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

485



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...

486

2/2/2015

63



O software SafeHome possibilita que o dono da casa configure o sistema de segurançaquando 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çãocontidas 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 introduzidospara 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 eventoque 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çãocom 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...

487


Análise Orientada a Objetos(OOA)

488

NOME CRITÉRIOdono da casa Papel ou entidade externasistema de segurança Coisasensores Entidade externateclado Entidade externateclas de função Entidade externapainel de controle Entidade externanúmero Atributo do sensorTipo Atributo do sensorsenha mestra Coisa

números telefônicos Coisaevento sensor Ocorrênciaalarme sonoro Entidade externatempo de espera Atributo do sistemaServiço de monitoração Unidade Organizacional ou Ent. Externainformações sobre o local Atributo do sistemanatureza do evento Atributo do sistemasubsistema Entidade externaentrada Entidade externachaves de função Entidade externamensagens Entidade externamostrador de cristal líquido Entidade externa

2/2/2015

64


Análise Orientada a Objetos(OOA)NOME CRITÉRIO

dono da casa Rejeitado: 1 e 2 falham embora 6 se apliquesistema de segurança Aceito: Todas se aplicam

sensores Aceito: Todas se aplicamteclado Aceito: Todas se aplicamteclas de função Aceito: Todas se aplicampainel de controle Aceito: Todas se aplicam

número Rejeitado: 3 falhaTipo Rejeitado: 3 falhasenha mestra Rejeitado: 3 falhanúmeros telefônicos Rejeitado: 3 falha

evento sensor Aceito: Todas se aplicamalarme sonoro Aceito: 2, 3, 4, 5 e 6tempo de espera Rejeitado: 3 falhaServiço de monitoração Rejeitado: 1 e 2 falham embora 6 se aplique

informações sobre o local Rejeitado: 3 falhanatureza do evento Rejeitado: 3 falhasubsistema Aceito: Todas se aplicamentrada Rejeitado: 3 falha

chaves de função Aceito: Todas se aplicammensagens Aceito: Todas se aplicammostrador de cristal líquido Aceito: Todas se aplicam

489


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

490

class Classes

Sistema

- atributos

+ metodos() : void

PainelControle

- atributos

+ metodos() : void

Sensor

- atributos

+ metodos() : void

Ev entoSensor

- atributos

+ metodos() : void

AlarmeSonoro

- atributos

+ metodos() : void

2/2/2015

65



491

Necessário estudar e analisar a descrição do sistema

Pergunta Importante – “Quais informações definem este objeto?”

class Classes

Sistema


+ metodos() : void

PainelControle

- atributos

+ metodos() : void

Sensor

- tipo- numero

+ metodos() : void

Ev entoSensor

- atributos

+ metodos() : void

AlarmeSonoro

- atributos

+ metodos() : void


Definição dos Métodos Necessário estudar e analisar a descrição do sistema

Verbos são potenciais operações

492

class Classes

Sistema


+ programar() : void+ armar() : void+ desarmar() : void+ monitorar() : void+ dispararAlarme() : void+ discar() : void

Configure sentido

Instalado dispara

Monitora especificado

Ligados configuração

Interage disca

Instalação registrando

“programar” detectado

configurar Discado

programada ligação

armar interações

desarmar gerenciadas

introduzidos interação

serem discados lê

ocorrer fornecida

exibe

2/2/2015

66



À 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).



493



À medida que são registrados buracos de rua, eles recebem um número de identificaçãoe 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).



494

2/2/2015

67


Identificação dos Objetos

495

NOMES CLASSIFICAÇÃO ANÁLISEdepartamento Unidade Organizacional Rejeitado: 1 e 2 Falhamsistema coisa Aceito: Todas se aplicamburacos coisa Aceito: Todas se aplicamnúmero de identificação coisa Rejeitado: 3 falhaendereço da rua coisa Rejeitado: 3 falhatamanho coisa Rejeitado: 3 falhalocalização coisa Rejeitado: 3 falhabairro bairro Rejeitado: 3 falhaprioridade coisa Rejeitado: 3 falhaordem de trabalho coisa Aceito: Todas se Aplicamnúmero de identificação da equipe coisa Rejeitado: 3 falhanúmero de pessoas coisa Rejeitado: 3 falhaequipamentos coisa Rejeitado: 3 falhahoras coisa Rejeitado: 3 falhaquantidade coisa Rejeitado: 3 falhacusto coisa Rejeitado: 3 falhaarquivo de danos estrutura Aceito: Todas se aplicamnome do cidadão coisa Rejeitado: 3 falhaEndereço coisa Rejeitado: 3 falhanúmero telefônico coisa Rejeitado: 3 falhatipo de dano coisa Rejeitado: 3 falha


Identificação dos Atributos

496

NOMES CLASSIFICAÇÃO ANÁLISEdepartamento Unidade Organizacional Rejeitado: 1 e 2 Falhamsistema coisa Aceito: Todas se aplicamburacos coisa Aceito: Todas se aplicamnúmero de identificação coisa Rejeitado: 3 falha (ATRIBUTO)endereço da rua coisa Rejeitado: 3 falha (ATRIBUTO)tamanho coisa Rejeitado: 3 falha (ATRIBUTO)localização coisa Rejeitado: 3 falha (ATRIBUTO)bairro bairro Rejeitado: 3 falha (ATRIBUTO)prioridade coisa Rejeitado: 3 falha (ATRIBUTO)

ordem de trabalho coisa Aceito: Todas se Aplicamnúmero de identificação da equipe coisa Rejeitado: 3 falha (ATRIBUTO)número de pessoas coisa Rejeitado: 3 falha (ATRIBUTO)equipamentos coisa Rejeitado: 3 falha (ATRIBUTO)horas coisa Rejeitado: 3 falha (ATRIBUTO)quantidade coisa Rejeitado: 3 falha (ATRIBUTO)custo coisa Rejeitado: 3 falha (ATRIBUTO)arquivo de danos estrutura Aceito: Todas se aplicamnome do cidadão coisa Rejeitado: 3 falha (ATRIBUTO)Endereço coisa Rejeitado: 3 falha (ATRIBUTO)número telefônico coisa Rejeitado: 3 falha (ATRIBUTO)tipo de dano coisa Rejeitado: 3 falha (ATRIBUTO)

2/2/2015

68


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.)

497

class Classes

Sistema

Buraco

- identificador- endereco- tamanho- localizacao- bairro- prioridade

+ metodos() : void

OrdemTrabalho

- localizacao- tamanho- equipe- equipamentos- horas- status- quantidadeMaterial- custo

+ metodos() : void

Dano

- cidadao- endereco- telefone- tipo- quantia

+ metodos() : void

Equipe

- numeroIdentificacao

+ metodos() : void


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

498

2/2/2015

69


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)

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

500

2/2/2015

70


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)

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)

502

2/2/2015

71


UML – Diagramas ComportamentaisCaso 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 e Modelagem dos Requisitos de um

Sistema

Modelagem do Contexto do 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.

503


UML – Diagramas ComportamentaisCaso de Uso Normalmente os casos de uso possuem uma descrição que contém uma

combinação de nome/verbo Exemplo: Criar Conta; Realizar Venda; Efetuar Pedido

Os atores são aqueles que interagem com o caso de uso 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

504

2/2/2015

72


UML – Diagramas ComportamentaisCaso 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

505


UML – Diagramas ComportamentaisCaso 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.

506

2/2/2015

73


UML – Diagramas ComportamentaisCaso 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

507


UML – Diagramas ComportamentaisCaso 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”

508

2/2/2015

74


UML – Diagramas ComportamentaisCaso de Uso - Relacionamentos Os seguintes relacionamentos são utilizados no diagrama de

casos de uso Associação

Generalização

Extensão

Inclusão

509


UML – Diagramas ComportamentaisCaso 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.

510

2/2/2015

75


UML – Diagramas ComportamentaisCaso 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.

511


UML – Diagramas ComportamentaisCaso 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

512

2/2/2015

76


UML – Diagramas ComportamentaisCaso 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

513


UML – Diagramas ComportamentaisCaso 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

514

2/2/2015

77


UML – Diagramas ComportamentaisCaso 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.

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

516

2/2/2015

78


UML – Diagramas EstruturaisClasses 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.

517


UML – Diagramas EstruturaisClasses 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.

518

2/2/2015

79


UML – Diagramas EstruturaisClasses - 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 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

Diagrama de Classes em nível de Análise 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.

519


UML – Diagramas EstruturaisClasses - 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

520

2/2/2015

80


UML – Diagramas EstruturaisClasses - Exemplos Diagrama de Classe em nível de Especificação de

Requisitos

521


UML – Diagramas EstruturaisClasses - Exemplos Diagrama de Classe em nível de Análise

522

2/2/2015

81


UML – Diagramas EstruturaisClasses - Exemplos Diagrama de Classe em nível de Projeto

523


UML – Diagramas EstruturaisClasses - Exemplos Diagrama de Classe em nível de Projeto

524

2/2/2015

82


Praticando seus conceitos... Considere um sistema na Web que será responsável por gerenciar

contatos, conforme caso de uso anterior Além de cadastrar os contatos é possível; consultar os contatos; alterar suas


Informações adicionais 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

525


Praticando seus conceitos... Informações adicionais x Representação em UML

1. Um usuário pode possuir vários contatos e o sistema deverá manter os dados de cada usuário individualmente

2. 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.)

3. As informações associadas ao contato são as seguintes: Nome; Telefone Principal; Email

526

class Contatos-Class-Analysis

Usuario Contato

1 0..*

Regra 1

Regra 2

Regra 3

class Contatos-Class-...

Email

- tipo: String- email: String

Contato

1

1..*

class Contatos-Class-An...

Contato

- nome: String- telefone: String- email: Email

2/2/2015

83


Praticando seus conceitos... Diagramas de classe em nível de análise

1. Um usuário pode possuir vários contatos e o sistema deverá manter os dados de cada usuário individualmente

2. 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.)

3. As informações associadas ao contato são as seguintes: Nome; Telefone Principal; Email

527

class Contatos-Class-Analysis

Usuario

- login: String- senha: String

+ login()

Email

- tipo: String- email: String

Contato

- nome: String- telefone: String- email: Email

+ create() : void+ read() : void+ update() : void+ delete() : void+ sendMail() : void

1 0..* 1 1..*


Praticando seus conceitos... Diagrama de classe que representa a modelagem de dados

528

class Contatos-Class-DataModel

TUsuario

«column»*PK id: ROWID login: VARCHAR2(30) senha: VARCHAR2(15)

«PK»+ PK_TUsuario(ROWID)

TContato

«column»*PK id: ROWID FK idUser: ROWID nome: VARCHAR2(50) telefone: VARCHAR2(15)

«FK»+ FK_TContato_TUsuario(ROWID)

«PK»+ PK_TContato(ROWID)

TEmail

«column»*PK id: ROWID FK idContact: ROWID tipo: VARCHAR2(30) email: VARCHAR2(50)

«FK»+ FK_TEmail_TContato(ROWID)

«PK»+ PK_TEmail(ROWID)

+FK_TEmail_TContato

0..*

(idContact = id)

«FK»

+PK_TContato

1

+FK_TContato_TUsuario

0..*

(idUser = id)

«FK»

+PK_TUsuario

1

2/2/2015

84


UML – Diagramas ComportamentaisDiagrama 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

529


UML – Diagramas ComportamentaisDiagrama 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

530

2/2/2015

85


UML – Diagramas ComportamentaisDiagrama 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

531


UML – Diagramas ComportamentaisDiagrama 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

532

2/2/2015

86


UML – Diagramas ComportamentaisDiagrama 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

533


UML – Diagramas ComportamentaisDiagrama 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);

534

2/2/2015

87


UML – Diagramas ComportamentaisDiagrama 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.

535


UML – Diagramas ComportamentaisDiagrama 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

536

2/2/2015

88


UML – Diagramas ComportamentaisDiagrama 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

537


UML – Diagramas ComportamentaisDiagrama 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

538

2/2/2015

89


UML – Diagramas ComportamentaisDiagrama de Atividades - Ações Modelamento de Sinais (Estado de Ação)

539


UML – Diagramas ComportamentaisDiagrama 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

540

2/2/2015

90


UML – Diagramas ComportamentaisDiagrama 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

541


Praticando seus conceitos... Considere um sistema na Web que será responsável por gerenciar contatos,

conforme caso de uso anterior Além de cadastrar os contatos é possível; consultar os contatos; alterar suas


Informações adicionais 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

542

2/2/2015

91


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.

543


Visões da Arquitetura Cenários (Scenarios 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

Lógica (Logical View) Foco nas funcionalidades, normalmente dividida em subsistemas apresentando a estrutura (classes)

envolvidas

Diagramas: Classe, Pacotes

Processos (Process 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) Ú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

544

2/2/2015

92


Visões da ArquiteturaDiagramas UML

545

http://www.sparxsystems.com/downloads/whitepapers/FCGSS_US_WP_Applying_4+1_w_UML2.pdf


Disciplinas x Artefatos Modelagem de Negócios

Documento de Visão

Caso de Uso (Contexto do Sistema)

Requisitos Especificação de Casos de Uso

Modelo de Domínio (Diagrama de Classes)

Análise e Projeto 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 Planos de Testes

Casos de Testes

Implantação

546

2/2/2015

93


Visão de Cenários(Scenarios view)

547


Visão Lógica(Logical View)

548

2/2/2015

94


Visão de Processos(Process View)

549


Visão Implementação(Implementation View)

550

2/2/2015

95


Visão de Implantação(Deployment View)

551

análise e projeto de software - ufuflavio/esof-files/files/2014-02/07-analise e... · análise e...

Documents