EC205 Cap 5 Modelagem UML A2013 S1, Notas de estudo de Engenharia Informática
wellington-cassio-faria-8
wellington-cassio-faria-8

EC205 Cap 5 Modelagem UML A2013 S1, Notas de estudo de Engenharia Informática

146 páginas
50Números de download
1000+Número de visitas
Descrição
Modelagem - UML
40 pontos
Pontos de download necessários para baixar
este documento
Baixar o documento
Pré-visualização3 páginas / 146
Esta é apenas uma pré-visualização
3 mostrados em 146 páginas
Esta é apenas uma pré-visualização
3 mostrados em 146 páginas
Esta é apenas uma pré-visualização
3 mostrados em 146 páginas
Esta é apenas uma pré-visualização
3 mostrados em 146 páginas
Slide sem título

w w

w .i n

a te

l. b

r

Cap. 5 – Modelagem - UML

Profa. Valeska Pivoto Patta Marcondes

EC205 – Engenharia de

Software I

w w

w .i n

a te

l. b

r

• A modelagem é uma técnica de engenharia aprovada e bem-aceita.

• Construímos modelos de arquitetura de casas e de grandes prédios para auxiliar seus usuários a visualizar qual será o produto final. A modelagem não faz parte apenas da indústria de construção.

• Seria inconcebível fornecer um novo avião ou automóvel sem primeiro construir os respectivos modelos – desde modelos de computadores, modelos físicos de túneis de vento até protótipos em larga escala. Novos dispositivos elétricos, desde microprocessadores a sistemas de telefonia, demandam algum grau de modelagem com o propósito de permitir uma melhor compreensão do sistema e a comunicação dessas idéias a outras pessoas.

w w

w .i n

a te

l. b

r

• O que é um modelo?

– Um modelo é uma simplificação da realidade.

• Os modelos fornecem uma cópia do projeto de um

sistema. Os modelos poderão abranger planos detalhados,

assim como planos mais gerais com uma visão

panorâmica do sistema considerado.

• Um bom modelo inclui componentes que têm ampla

repercussão e omite os componentes que não são

relevantes em determinado nível de abstração.

• Todos os sistemas podem ser descritos sob diferentes

aspectos, com a utilização de modelos distintos, e cada

modelo será, portanto, uma abstração semanticamente

específica do sistema.

• Os modelos podem ser estruturais, dando ênfase à

organização do sistema, ou podem ser comportamentais,

dando ênfase à dinâmica do sistema.

w w

w .i n

a te

l. b

r

O que é?

UML é uma linguagem padrão da OMG para

visualização, especificação, construção e

documentação de software orientado a objetos.

"The Unified Modeling Language (UML) is a graphical language for visualizing,

specifying, constructing, and documenting the artifacts of a software-intensive

system.

The UML offers a standard way to write a system's blueprints, including conceptual

things such as business processes and system functions as well

as concrete things such as programming language statements,

database schemas, and reusable software components."

w w

w .i n

a te

l. b

r

• O ponto importante a observar aqui é que a UML é uma linguagem para especificar e não uma metodologia ou procedimento.

• A UML é usada para definir um sistema de software; para detalhar os artefatos do sistema, para documentar e construir.

• É a linguagem que permite que a “planta” do sistema seja criada; permite a criação de modelos.

w w

w .i n

a te

l. b

r

• Projetos de softwares mal sucedidos falham em relação a aspectos únicos e específicos de cada projeto, mas todos os projetos bem-sucedidos são semelhantes em diversos aspectos.

• Existem muitos elementos que contribuem para uma empresa de software de sucesso; um desses componentes é a utilização da modelagem.

Projetos de software precisam de modelagem?

w w

w .i n

a te

l. b

r

• A modelagem não se restringe a grandes sistemas: softwares bem simples

poderão receber os benefícios da modelagem. Porém, é absolutamente

verdadeiro que, quanto maior e mais complexo for o sistema, maior será a

importância da modelagem, por uma razão muito simples:

Todos os tipos de projetos de software precisam de modelagem?

Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade.

Existem limites para a capacidade humana de compreender complexidades. Com a ajuda da modelagem, delimitamos o problema que estamos estudando, restringindo nosso foco a um único aspecto por vez.

Em essência esse é o procedimento de “dividir-e-conquistar” que Edsger Dijkstra falava há anos: ataque um problema difícil, dividindo-o em vários problemas menores que você pode solucionar.

w w

w .i n

a te

l. b

r

Histórico

Início dos anos 90

• Criadores dos principais métodos de

orientação a objeto nos anos 90;

• Cada metodologia possuía notação,

processos e ferramentas próprias;

• Cada método possuía pontos fortes e

fracos;

w w

w .i n

a te

l. b

r

Histórico

Rational

Início dos anos 90 1995

• Unificação dos trabalhos

visando adoção por

ferramentas de

modelagem comerciais;

• Criação da Unified

Modeling Language

(UML);

• Ficaram conhecidos como

“The Three Amigos” na

engenharia de software;

w w

w .i n

a te

l. b

r

Histórico

Rational

Início dos anos 90 1995 1997

Unified

Modeling

Language

(UML)

OMG

• Deixa de ser proprietária;

• Aceita como uma

linguagem padrão de

modelagem pela OMG

(Object Modeling Group)

que passa a gerenciar sua

evolução;

OMG é um consórcio de

empresas que visa

estabelecer padrões para

engenharia de software;

w w

w .i n

a te

l. b

r

Histórico

http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm

w w

w .i n

a te

l. b

r

Composição da UML

• Formada por 13 diagramas classificados em diagramas

estruturais e comportamentais;

• Cada diagrama apresenta uma visão diferente sobre o sistema:

– Estruturais - visão estática do modelo

– Comportamentais - visão dinâmica do modelo

w w

w .i n

a te

l. b

r

Composição da UML

Fonte: UML Superstructure Specification, v2.1.1, figure A.5, p. 680

w w

w .i n

a te

l. b

r

Composição da UML

Classe

Objeto

Componentes

Estrutura

Composta

Implantação Pacote Sequencia Comunicação

Visão geral

Interação

Tempo

Atividade

Caso de Uso Máquina de

Estado

Diagramas

UML

w w

w .i n

a te

l. b

r

Entender o

problema.

Identificar as

características que

a solução deverá

prover – O QUÊ?

Analisar a solução

– COMO?

Projetar e

Construir

a solução

Entregar a

solução

Como usar a UML?

Conforme já citado, a UML é uma linguagem para especificar e não uma

metodologia ou procedimento.

A UML é normalmente usada como parte de um processo de desenvolvimento de

software, com o apoio de uma ferramenta CASE (Computer-Aided Software

Engineering), para definir os requisitos, as interações e os elementos do sistema proposto. A natureza exata do processo depende da metodologia de

desenvolvimento utilizada. Como exemplo de processo poderia ter-se algo como o

seguinte:

w w

w .i n

a te

l. b

r

Entender o

problema.

Identificar as

características que

a solução deverá

prover – O QUÊ?

Analisar a solução

– COMO?

Projetar e

construir a

solução

Entregar a

solução

Exemplo de uso da UML

Especificação:

Requisitos,

Use Cases

Análise

Projeto

Entrega

Entendimento

do domínio do

problema

w w

w .i n

a te

l. b

r

Entendimento do domínio do

problema

Especificação

Análise

Projeto

Entrega

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Sequência

Visão geral da interação

Comunicação

Tempo

Diagramas - Comportamentais

Normalmente usado durante

levantamento e análise de requisitos.

 Identifica “atores” que de alguma

forma vão interagir com o software e

como o sistema irá responder a eles.

 Identifica funcionalidades a serem

disponibilizadas aos atores.

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Diagrama de Casos de Uso (Use Case diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

 Descreve passos a serem

percorridos até a conclusão de uma

atividade.

 Concentra-se no fluxo de controle

de uma atividade.

Sequência

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Diagrama de Atividades

(Activity diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

Também conhecido como diagrama

de estados.

Acompanha as mudanças sofridas

por um objeto dentro de um

determinado processo.

 Acompanha os estados pelos quais

passa uma instância de uma classe.

Sequência

Exemplo 1

Visão geral da interação

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

Também conhecido como diagrama

de estados.

Acompanha as mudanças sofridas

por um objeto dentro de um

determinado processo.

 Acompanha os estados pelos quais

passa uma instância de uma classe.

Sequência

Exemplo 2

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Exemplo 1

Diagrama de Máquina de Estados

(State Machine diagram)

Fonte: http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Exemplo 2

Diagrama de Máquina de Estados

(State Machine diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

 Representa o comportamento do

sistema ou parte do sistema como uma

série de passos ao longo do tempo;

Ele é usado para descrever o fluxo de

trabalho, a passagem de mensagens e

como elementos cooperam entre si para

alcançar um resultado.

Sequência

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Diagrama de Sequência

(Sequence diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

É uma variação do diagrama de

atividades;

Permite visualizar a cooperação entre

outros diagramas de interação

ilustrando o fluxo de controle de um

propósito mais abrangente.

Sequência

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Diagrama de Visão Geral da interação

(Interaction Overview diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

 Mostra a interação entre elementos em tempo de execução.

 É similar ao diagrama de sequência,

no entanto são usados para visualizar as

relações entre objetos, enquanto os

diagramas de seqüência são mais

eficazes na visualização do

processamento ao longo do tempo.

Sequência

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

Diagrama de Comunicação

(Communication diagram)

w w

w .i n

a te

l. b

r

Casos de Uso

Atividades

Máquina de Estados

Comunicação

Tempo

Diagramas - Comportamentais

 Define o comportamento de

diferentes objetos dentro de uma escala

de tempo.

Permite a visualização da mudança de

estado dos objetos ao longo do tempo.

Sequência

Visão geral da interação

w w

w .i n

a te

l. b

r

Diagramas - Comportamentais

http://www.uml-diagrams.org/timing-diagrams-examples.html

Timing Diagram Example - User Experience Website Latency

Diagrama de tempo

(Timing diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais  Captura a estrutura lógica do sistema, as

classes que compõem o modelo.

É um modelo estático, descrevendo o que

existe, quais atributos e comportamentos um

elemento possui, ao invés de como algo é

realizado.

Diagramas de classe são mais úteis para

ilustrar as relações entre classes e interfaces.

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de Classes (Class diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais

 Um diagrama de objeto está

intimamente relacionado com um

diagrama de classes, com a distinção que

retrata instâncias de objetos de classes e

seus relacionamentos em um ponto no

tempo.

Diagrama de classe

Diagrama de objetos

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de classe

Diagrama de Objetos (Object diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais

 Um diagrama de estrutura composta

reflete a colaboração interna de classes,

interfaces ou componentes para descrever

a funcionalidade.

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de Estrutura Composta (Composite Structure diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais

 Um diagrama de componente mostra as

partes do software, sua organização e

dependências, que formam o sistema.

O diagrama de componentes possui um nível

maior de abstração que um diagrama de classes;

geralmente um componente é implementado

por uma ou mais classes (ou objetos) em tempo

de execução.

Eventualmente um componente pode

abranger uma grande parte de um sistema.

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de Componentes (Component diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais

 Apresenta a organização de

elementos de modelo e suas

dependências;

Permite a visualização dos

“namespaces” correspondentes.

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de Pacotes (Package diagram)

w w

w .i n

a te

l. b

r

Classes

Objetos

Estrutura Composta

Componentes

Pacotes

Implantação

Diagramas - Estruturais

Um diagrama de implantação mostra

como e onde o sistema será

implantado, ou seja, sua arquitetura de

execução

Necessidades de hardware,

características físicas: servidores,

estações, topologia, protocolos, etc.

w w

w .i n

a te

l. b

r

Diagramas - Estruturais

Diagrama de Implantação

(Deployment diagram)

w w

w .i n

a te

l. b

r

Exercício

w w

w .i n

a te

l. b

r

Diagrama de Use Case

O diagrama de Use Cases captura as Use Cases (casos

de uso) e o relacionamentos com os atores.

Ele descreve os requisitos funcionais do sistema e a

maneira pela qual os atores interagem com o sistema.

Um Caso de Uso descreve a funcionalidade proposta de

um novo sistema.

Um Caso de Uso representa uma unidade discreta da

interação entre um usuário (humano ou máquina) e o

sistema. Essa interação é uma única unidade de trabalho

significativo, como Browse Book Catalogue ou Locate

Book by Title or Author.

w w

w .i n

a te

l. b

r

Elementos do diagrama de Use Case

Use Case ou Caso de Uso

Representada por uma elipse e um nome (que pode

estar dentro ou abaixo). Também pode ser

representada por um retângulo com uma elipse no topo

direito.

Descreve uma funcionalidade do sistema que é descrita

por um fluxo de eventos ou cenário.

w w

w .i n

a te

l. b

r

Elementos do diagrama de Use Case

A descrição de uma Use Case geralmente inclui:

• um identificador único;

• uma descrição geral da funcionalidade que a Use

Case representa;

• os requisitos associados;

• os atores associados;

• pré-condições para que o fluxo de eventos ocorra;

• pós-condições atingidas após a ocorrência do fluxo;

• cenários:

• cenário básico;

• cenários alternativos (casos de exceção e fluxos

alternativos);

w w

w .i n

a te

l. b

r

Elementos do diagrama de Use Case

Ator

Representado por um boneco, um retângulo (com o

estereótipo <<actor>> ou um ícone.

Um ator é um usuário do sistema: o usuário pode ser

uma pessoa, uma máquina, ou mesmo outro sistema.

Qualquer coisa que interaja com o sistema a partir de sua

fronteira é chamado de ator.

w w

w .i n

a te

l. b

r

Conectores principais

Associação:

Um conector do tipo Associação mostra que dois ou mais elementos do modelo

têm um relacionamento.

Uma associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se

da função do sistema representada pelo Caso de Uso.

Esse conector pode incluir nome de papéis no seu final, multiplicidade, direção e

restrição.

w w

w .i n

a te

l. b

r

Conectores principais

Associação:

Multiplicidade Restrição

(pré-condição)

Papel

w w

w .i n

a te

l. b

r

Generalização:

Um conector do tipo Generalização é utilizado para indicar herança.

É representado por uma seta partindo de uma fonte para um alvo: implica que a

fonte herda as características do elemento alvo.

Pode existir entre Use Cases e entre Atores.

Conectores principais

w w

w .i n

a te

l. b

r

Include:

Um conector do tipo Include é utilizado para indicar inclusão de comportamento.

É representado por uma seta tracejada partindo de em elemento fonte para um

alvo, com o estereótipo “include”; implica que o elemento fonte inclui as

funcionalidades do elemento alvo.

Pode existir entre Use Cases e é utilizado para evitar que o mesmo

comportamento tenha que ser repetido em várias Use Cases.

Conectores principais

w w

w .i n

a te

l. b

r

Include:

Conectores principais

http://sourcemaking.com/uml/modeling-it-systems/external-view/the-elements-of-view/use-case-diagram

w w

w .i n

a te

l. b

r

Extend:

Um conector do tipo Extend é utilizado para indicar extensão de comportamento.

É representado por uma seta tracejada partindo de em elemento base para outro,

com o estereótipo “extend” : implica que um elemento estende as funcionalidades

do elemento base.

Pode existir entre Use Cases.

É utilizado para representar fluxos complementares; o comportamento do elemento

base pode existir sem o comportamento estendido.

Conectores principais

w w

w .i n

a te

l. b

r

Extend:

Conectores principais

http://www.uml-diagrams.org/use-case-diagrams.html#include

opcionais

w w

w .i n

a te

l. b

r

Fronteira do sistema:

Fronteira (System Boundary) é um elemento classificador no qual atuam as Use

Cases nela incluídas.

É representada por um retângulo e o nome do “assunto” (que classifica o sistema).

Mais utilizado quando existem mais de um sistema (fronteira) a ser representado e

portanto para indicar quais use cases estão contidas em cada um deles.

Fronteira

w w

w .i n

a te

l. b

r

Fluxo de eventos (Fluxo principal e Alternativos)

Nome da Use Case [Nome da Use Case N]

Descrição Descreva detalhadamente o propósito da Use Case

Requisitos Associados Liste os requisitos que estão sendo atendidos por esta Use Case

Pré Condições Se existir uma ou mais pré-condições, descreva-as aqui

Pós Condições Se existir uma ou mais pós condições, descreva-as aqui

Atores Liste os atores que se relacionam com esta Use Case

Fluxo Principal

Ações RecebidasAções Realizadas

1. O ator X inicia a fluxo principal 2. O sistema recebe uma ação do ator e realiza algo;

3. ...

Fluxo Alternativo X

2 – O sistema inicia o fluxo alternativo 1

3 - ...

w w

w .i n

a te

l. b

r

Nome da Use

CaseSacar Dinheiro

DescriçãoResponsável por implementar a lógica de saque de dinheiro.

Requisitos

AssociadosReq. Funcional 001 – Permitir sacar dinheiro

Pré CondiçõesSistema disponível

Pós Condições1 - Dinheiro sacado;

2 - Dinheiro não sacado. AtoresCliente

Fluxo Principal

w w

w .i n

a te

l. b

r

Fluxo Principal

Ações RecebidasAções Realizadas

1 – Cliente solicita saque 2 – Sistema solicita que passe o cartão

3 – Cliente passa o cartão 4 – Sistema lê o cartão e valida os dados. Se

dados estiverem corretos, o sistema solicita a

senha. Caso contrário veja “Fluxo Alternativo

1”.

5 – Cliente digita a senha 6 – Sistema verifica senha. Se estiver correta

solicita a quantia. Caso contrário veja “Fluxo

Alternativo 2”.

7 – Cliente digita quantia 8 – Sistema verifica saldo. Se houver saldo

disponível, o sistema libera a quantia solicitada.

Caso contrário veja “Fluxo Alternativo 3”

9 – Caso de uso encerrado

w w

w .i n

a te

l. b

r

Fluxo Alternativo 1 – Dados do cartão inválidos

Ações RecebidasAções Realizadas

1 – Sistema apresenta mensagem informando

que os dados estão inválidos;

2 – Sistema pergunta se deseja passar o cartão

novamente ou cancelar a operação.

3 – Cliente passa cartão

novamente

4 – Sistema volta para operação “4” do “Fluxo

Principal”.

3 – Cliente solicita cancelar

a operação

4 – Sistema cancela a operação;

5 – Caso de uso encerrado.

w w

w .i n

a te

l. b

r

Fluxo Alternativo 2 – Senha inválida

Ações RecebidasAções Realizadas

1 – Sistema apresenta mensagem informando

que a senha está inválida;

2 – Sistema pergunta se deseja entrar com a

senha novamente ou cancelar a operação.

3 – Cliente digita senha

novamente

4 – Sistema volta para operação “6” do “Fluxo

Principal”.

3 – Cliente solicita cancelar

a operação

4 – Sistema cancela a operação;

5 – Caso de uso encerrado.

w w

w .i n

a te

l. b

r

Fluxo Alternativo 3 – Saldo insuficiente

Ações RecebidasAções Realizadas

1 – Sistema apresenta mensagem informando

que o saldo é insuficinete;

2 – Sistema pergunta se deseja entrar com a

quantia novamente ou cancelar a operação.

3 – Cliente digita quantia

novamente

4 – Sistema volta para operação “8” do “Fluxo

Principal”.

3 – Cliente solicita cancelar

a operação

4 – Sistema cancela a operação;

5 – Caso de uso encerrado.

w w

w .i n

a te

l. b

r

FA3

FA2

FA1

Fluxo Principal

Pós condição 1

Pós condição 2

Pós condição 2

Pós condição 2

w w

w .i n

a te

l. b

r

Fonte: http://www.uml-diagrams.org/use-case-diagrams.html#include

Exemplo 1

w w

w .i n

a te

l. b

r

Exemplo 2

Fonte: Enterprise Architect

w w

w .i n

a te

l. b

r

Fonte: UML Superstructure Specification, v2.3 – page 614

Exemplo 3

w w

w .i n

a te

l. b

r

Exemplo 4

Fonte: Enterprise Architect

w w

w .i n

a te

l. b

r

Exemplo 5

Fonte: Enterprise Architect

w w

w .i n

a te

l. b

r

Diagrama de Casos de Uso – Exercício 1

O sistema OPAC (Online Public Access Catalog) deverá ser uma aplicação web integrada ao

sistema IIS (Integrated Library System) da Universidade Federal de Brasília.

O sistema OPAC deverá permitir que o bibliotecário possa procurar catálogos contidos na IIS

para localizar vários recursos como livros, periódicos, material áudio-visual ou qualquer outro

item que esteja sob o controle do sistema IIS.

O bibliotecário também poderá reservar ou renovar um item, fornecer feedback e gerenciar a sua

conta no IIS.

1 – Qual o sistema a ser modelado?

2 – Quem irá interagir com o sistema?

3 – Existe alguma interação com outros sistemas?

4 – Quais são as funcionalidades fornecidas?

5 – Com quais funcionalidades as pessoas ou outros

sistemas poderão interagir?

6 – Existe relacionamento entre as funcionalidades?

Fronteira

Ator

Casos de Uso

Conectores

Ator

Conectores

w w

w .i n

a te

l. b

r

Diagrama de Casos de Uso – Exercício 2

• O sistema Catalog é um sistema web que permite a pesquisa de obras de arte do

museu Louvre. Qualquer pessoa pode acessar o sistema, mas para iniciar uma

pesquisa é necessário realizar um login, onde é passado o nome do usuário e sua

senha. Uma vez autenticado, o usuário tem disponível uma série de opções de

busca e informações sobre as obras. Se o usuário digitar um usuário e senha

inválidos (caso não tenha ou caso tenha esquecido) o sistema solicita o registro de

seus dados para que um novo nome e senha possam ser utilizados. Veja o fluxo de

eventos do módulo “Acessar sistema”:

Pede-se: faça o diagrama de

use cases e a sua

documentação.

Fonte: http://hoirul.its-sby.edu/ADBO/UseCase_Document_Template.doc

w w

w .i n

a te

l. b

r

Diagrama de Casos de Uso

Em que etapa de um processo de desenvolvimento

de software o diagrama de use cases mostra-se

mais eficaz?

?

w w

w .i n

a te

l. b

r

w w

w .i n

a te

l. b

r

Diagrama de Classes

O diagrama de Classes captura a estrutura lógica

do sistema, ou seja, como o sistema está

organizado para prover todas as suas

funcionalidades;

Um diagrama de classe pode ser criado com

diferentes níveis de abstração, ou seja,

normalmente os seus detalhes são inseridos

conforme as etapas de desenvolvimento do sistema

avançam;

Desta forma, pode-se criar diagrama de classes de

domínio, de análise e de projeto.

w w

w .i n

a te

l. b

r

Diagrama de Classes – níveis de abstração

Em nível de domínio podem ser exibidos somente os nomes das classes e

seus relacionamentos:

w w

w .i n

a te

l. b

r

Diagrama de Classes – níveis de abstração

Em nível de análise podem ser exibidos os nomes das classes, seus

atributos e relacionamentos:

w w

w .i n

a te

l. b

r

Diagrama de Classes – níveis de abstração

Em nível de projeto podem ser exibidos os nomes das classes, seus

atributos, métodos e relacionamentos:

w w

w .i n

a te

l. b

r

Elementos do Diagrama de Classes

Classe: representada por um retângulo com o ser nome

na parte superior;

Uma classe pode ter atributos (que representam os

dados) e métodos ou operações (que representam

comportamento);

Normalmente a classe é mostrada com 3

compartimentos: o compartimento central que apresenta

a lista de atributos e o compartimento inferior que

apresenta a lista de operações.

w w

w .i n

a te

l. b

r

Elementos do Diagrama de Classes

Os atributos da classe possuem características importantes, tais como,

como escopo (visibilidade) e tipo.

Escopo (visibilidade) tipo

nome

Publico (+)

Protegido (#)

Privado (-)

Pacote(~)

w w

w .i n

a te

l. b

r

Elementos do Diagrama de Classes

As operações de uma classe representam o comportamento ou serviços

que ela fornece.

Também possuem características importantes tais como escopo

(visibilidade), tipo.

Fonte: UML Superstructure Specification, v2.3 – page 52

w w

w .i n

a te

l. b

r

Elementos do Diagrama de Classes

Fonte: UML Superstructure Specification, v2.3 – page 52

w w

w .i n

a te

l. b

r

Conectores principais

Associação:

Um conector do tipo Associação mostra que dois ou mais elementos do modelo

têm um relacionamento.

Esse conector pode incluir nome de papéis no seu final, multiplicidade, direção e

restrição.

Uma associação entre duas classes é normalmente implementada como uma

variável de instância em uma classe.

w w

w .i n

a te

l. b

r

Generalização:

Um conector do tipo Generalização é utilizado para indicar herança.

A generalização relaciona um classificador específico para um classificador geral,

portanto, cada instância do classificador específico é também uma instância do

classificador geral.

Dessa forma as características especificadas para as instâncias do classificador

geral são implicitamente especificados para as instâncias do classificador

específico.

Conectores principais

Fonte: UML Superstructure

Specification, v2.3 – page 91

w w

w .i n

a te

l. b

r

Agregação:

Um conector do tipo Agregação é um tipo de associação que mostra que um elemento

contém ou é composto por outros elementos.

A agregação é representada por uma linha com um losango em sua extremidade (apontada

para o Todo).

Utilizada para indicar que um elemento mais complexo é construído a partir de uma coleção

de elementos mais simples.

Conectores principais

w w

w .i n

a te

l. b

r

Composição:

Um conector do tipo Composição é um tipo de agregação que mostra que um

elemento é construído por outros elementos.

A composição é representada por uma linha com um losango preenchido em sua

extremidade (apontada para o Todo).

Se o Todo for excluído, geralmente todas as suas partes são eliminados com ele,

no entanto, uma parte pode ser removida individualmente a partir de uma

composição sem ter que apagar toda a composição.

Conectores principais

w w

w .i n

a te

l. b

r

Exemplo 1

Fonte: Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

w w

w .i n

a te

l. b

r

Exemplo 2

Fonte: Princípios de Análise e Projeto de Sistemas com UML - 2ª edição

w w

w .i n

a te

l. b

r

w w

w .i n

a te

l. b

r

Diagrama de Classes

Como identificar as classes que irão compor um

sistema? ?

w w

w .i n

a te

l. b

r

Encontrando as classes do sistema...

A partir da análise do fluxo de cada Use Case é possível identificar classes

de análise, ou seja, que poderão vir a ser as classes de “projeto” do

sistema;

Com as classes de análise, inicia-se o processo de distribuição do

comportamento da use case em classes, que inicialmente pode apresentar

uma visão macro, e após repetidas analises, uma visão bem detalhada;

Dessa forma, classes de análise representam uma abstração de uma ou

mais classes de projeto;

As classes de annálise podem ser categorizadas conforme os seguintes

estereótipos da UML: <<boundary>>, <<entity>>, <<control>>

w w

w .i n

a te

l. b

r

Classes de Análise

• Classe de Fronteira: <<boundary>>

– Responsável pela comunicação entre Caso de Uso e Ator.

– Troca de informações entre Caso de Uso e Ator.

– Geralmente associada a janelas, formulários, sensores, terminais, APIs,

...

w w

w .i n

a te

l. b

r

Classes de Análise

• Classe de Entidade: <<entity>>

– Responsável por manter ou persistir as informações.

• Classe de Controle: <<control>>

– Atuam como uma “ponte de comunicação” entre

objetos de fronteira e objetos de entidade.

– Responsável pela lógica de execução da Use Case.

w w

w .i n

a te

l. b

r

Exemplo 1

Fonte: Enterprise Architect

w w

w .i n

a te

l. b

r

Exemplo 2 – parte 1

Fonte: Enterprise Architect

Basic Path: This use case begins when a

Client requests a display of their account

details. General account information is

displayed (i.e. ID, username, billing

address, delivery address etc).

Command buttons are displayed to allow

the user to view Open Orders or History.

The use case terminates when the user

selects the Exit or Back button.

w w

w .i n

a te

l. b

r

Exemplo 2 – parte 2

Fonte: Enterprise Architect

Vamos tentar? Basic Path: This use case begins when the user requests to view a

history of transactions against their

account. The account ID is used as a

key to lookup the appropriate records

in the database. The results are then

displayed sorted in date order.

w w

w .i n

a te

l. b

r

Exemplo 2 – parte 2

Fonte: Enterprise Architect

Basic Path: This use case begins

when the user requests to view a

history of transactions against their

account. The account ID is used as a

key to lookup the appropriate records

in the database. The results are then

displayed sorted in date order.

w w

w .i n

a te

l. b

r

Exemplo 2 – parte 3

Fonte: Enterprise Architect

Vamos tentar?

Basic Path: This use case begins

when the user request to view a

list of current transactions against

their account. The account ID is

used as a key to lookup the

appropriate records in the

database. The results are then

displayed sorted in date order.

w w

w .i n

a te

l. b

r

Exemplo 2 – parte 3

Fonte: Enterprise Architect

Basic Path: This use case begins

when the user requests to view a

history of transactions against their

account. The account ID is used as

a key to lookup the appropriate

records in the database. The

results are then displayed sorted in

date order.

w w

w .i n

a te

l. b

r

w w

w .i n

a te

l. b

r

Diagrama de Sequência

Um diagrama de seqüência é uma representação do

comportamento do sistema como uma série de etapas

seqüenciais ao longo do tempo.

Ele é usado para descrever o fluxo de trabalho, a

passagem de mensagens e como os elementos em

geral cooperam ao longo do tempo para alcançar um

resultado.

Cada elemento é organizado em uma seqüência

horizontal, com mensagens que passam para trás e para

frente entre os elementos.

w w

w .i n

a te

l. b

r

Diagrama de Sequência

Um elemento ator pode ser usado para

representar o usuário que inicia o fluxo de

eventos.

Elementos estereotipados, como

<<boundary>>, <<control>> e <<entity>>

podem ser usados para ilustrar as telas, os

controles e os itens de banco de dados,

respectivamente.

Diagramas de seqüência são comumente usados ​​como modelos

explicativos dos cenários das Use Cases.

w w

w .i n

a te

l. b

r

Elementos do diagrama de Sequencia

Ator

Representado por um boneco, um retângulo (com o

estereótipo <<actor>> ou um ícone.

Um ator é um usuário do sistema: o usuário pode ser

uma pessoa, uma máquina, ou mesmo outro sistema.

Qualquer coisa que interaja com o sistema a partir de sua

fronteira é chamado de ator.

w w

w .i n

a te

l. b

r

Elementos do diagrama de Sequencia

Linha de vida

Representa um participante individual na interação.

Podem ser elementos estereotipados (boundary, control,

entity).

Objetos destruídos têm sua linha de vida interrompida por

um “X

w w

w .i n

a te

l. b

r

• Linha de vida: Foco de Controle (Ativação)

– Indica os períodos em que um determinado objeto está participando

ativamente do processo (executando algum método).

Foco de

Controle

Elementos do diagrama de Sequencia

w w

w .i n

a te

l. b

r

• Mensagem

– Define a comunicação entre os elementos em uma interação;

– A comunicação pode ser, de exemplo, invocar uma operação, criar ou

destruir uma Instância.

Mensagens

Elementos do diagrama de Sequencia

w w

w .i n

a te

l. b

r

• Mensagens de Retorno

• Respondem a uma mensagem de estímulo recebida.

• Podem retornar informações específicas do método chamado ou

valores.

• Representada por uma seta tracejada

Diagrama de Sequência

w w

w .i n

a te

l. b

r

Diagrama de Sequência

conta1:Conta

2: Verifica conta: Consulta()

3: Saldo

4: [Saldo positivo]Sacar valor:

Saque()

7: Saque realizado

Cliente

1: Solicita saque

hist1:Historico

6: Histórico registrado

8: Saque concluído

Banco

w w

w .i n

a te

l. b

r

Diagrama de Sequência

conta1:Conta Cliente

hist1:Historico

2: Verifica conta: Consulta()

3: Saldo

4: [Saldo positivo]Sacar valor:

Saque()

7: Saque realizado

1: Solicita saque

6: Histórico registrado

8: Saque concluído

Mensagens

Banco

w w

w .i n

a te

l. b

r

Diagrama de Sequência

conta1:Conta Cliente

hist1:Historico

3: Saldo

7: Saque realizado 6: Histórico registrado

Mensagens de

Retorno

2: Verifica conta: Consulta()

4: [Saldo positivo]Sacar valor:

Saque()

1: Solicita saque

8: Saque concluído

Banco

w w

w .i n

a te

l. b

r

Diagrama de Sequência

conta1:Conta

2: Verifica conta: Consulta()

3: Saldo

7: Saque realizado

Cliente

1: Solicita saque

hist1:Historico

6: Histórico registrado

8: Saque concluído

4: [Saldo positivo]Sacar valor:

Saque()

Objeto criado

durante o

processo

Banco

w w

w .i n

a te

l. b

r

• Auto-mensagem

– Mensagens que um objeto envia a si mesmo.

Diagrama de Sequência

Auto-mensagem

w w

w .i n

a te

l. b

r

• Condição de Guarda

– Indica que uma dada mensagem só poderá ser enviada se uma

determinada condição for verdadeira.

Diagrama de Sequência

conta1:Conta

2: Verifica conta: Consulta()

3: Saldo

4: [Saldo positivo]Sacar valor:

Saque()

7: Saque realizado

Cliente

1: Solicita saque

hist1:Historico

6: Histórico registrado

8: Saque concluído

Banco

w w

w .i n

a te

l. b

r

Banco

• Condição de Guarda

– Indica que uma dada mensagem só poderá ser enviada se uma

determinada condição for verdadeira.

Diagrama de Sequência

conta1:Conta

2: Verifica conta: Consulta()

3: Saldo

4: [Saldo positivo]Sacar valor:

Saque()

7: Saque realizado

Cliente

1: Solicita saque

hist1:Historico

6: Histórico registrado

8: Saque concluído

Condição de

Guarda

w w

w .i n

a te

l. b

r

• Condição de Guarda

– Múltiplas ações: representa o disparo de uma mensagem a vários

objetos.

Diagrama de Sequência

pedido1:Pedido

Funcionário

item:Item Pedido

1: Confirmar pedido: Gravar()

2: *[Para cada item]: Gravar()

w w

w .i n

a te

l. b

r

Fonte: Enterprise Architect

Exemplo 1 – View Account Details

w w

w .i n

a te

l. b

r

Exemplo 1 – fluxo básico

Basic Path: This use case begins when a Client requests a display of their account details.

General account information is displayed (i.e. ID, username, billing address, delivery address

etc).

w w

w .i n

a te

l. b

r

Fonte: Enterprise Architect

Exemplo 1 – View Open Orders

Vamos tentar?

Basic Path: This use case begins when the user request to view a list of current

transactions against their account. The account ID is used as a key to lookup the

appropriate records in the database. The results are then displayed sorted in date

order.

w w

w .i n

a te

l. b

r

Fonte: Enterprise Architect

Exemplo 1 – View Open Orders Basic Path: This use case begins when the user request to view a list of current

transactions against their account. The account ID is used as a key to lookup the

appropriate records in the database. The results are then displayed sorted in date order.

w w

w .i n

a te

l. b

r

Exemplo 1 – View History

Vamos tentar?

Basic Path: This use case begins when the user requests to view a history of

transactions against their account. The account ID is used as a key to lookup the

appropriate records in the database. The results are then displayed sorted in date

order.

w w

w .i n

a te

l. b

r

Exemplo 1 – View History

Basic Path: This use case begins when the user requests to view a history of transactions

against their account. The account ID is used as a key to lookup the appropriate records

in the database. The results are then displayed sorted in date order.

Fonte: Enterprise Architect

w w

w .i n

a te

l. b

r

w w

w .i n

a te

l. b

r

Diagrama de Atividades

• Usado para descrever uma seqüência de

atividades com suporte para o

comportamento condicional e paralelo de

processos de workflow (processos de fluxo

de negócios), e também para permitir uma

radiografia de uma lógica de código,

mostrando essa lógica, como um

fluxograma, porém, com recursos mais

poderosos.

• Concentra-se no fluxo de controle da

atividade.

w w

w .i n

a te

l. b

r

• Formado por:

– Estados Inicial e Final

– Transições

– Barras de Sincronização

– Estado de Ação

– Ponto de Decisão

Elementos do Diagrama de Atividades

w w

w .i n

a te

l. b

r

• Estados Inicial e Final

– São estados abstratos que determinam o início e o fim de um

Diagrama de Atividades.

Diagrama de Atividades

Atividade 1

Estado Inicial

Estado Final

[Se falso]

[Se verdadeiro]

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Transição

– Interliga os estados de um diagrama.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Transição

– Interliga os estados de um diagrama.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Transições

Atividade 1

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Estado de Ação

– Representa a realização de uma ação dentro de um fluxo de

controle.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Estado de Ação

– Representa a realização de uma ação dentro de um fluxo de

controle.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

Estados de

Ação

w w

w .i n

a te

l. b

r

• Ponto de Decisão

– Representa um ponto do fluxo de controle onde deve ser

realizado um teste, uma tomada de decisão.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Ponto de Decisão

– Representa um ponto do fluxo de controle onde deve ser

realizado um teste, uma tomada de decisão.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

Ponto de

Decisão

w w

w .i n

a te

l. b

r

• Condição de guarda

– Trata-se de uma expressão lógica (pode ser verdadeira ou não), capaz

de determinar a transição para uma ou outra atividade.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

w w

w .i n

a te

l. b

r

• Condição de guarda

– Trata-se de uma expressão lógica (pode ser verdadeira ou não), capaz

de determinar a transição para uma ou outra atividade.

Diagrama de Atividades

[Se falso]

[Se verdadeiro]

Atividade 1

Atividade 3

Atividade 2

Condição de

Guarda

w w

w .i n

a te

l. b

r

• Barra de Sincronização

– Identifica o ponto a partir do qual o processo passou a ser executado em

paralelo, ou processos em paralelo se unem.

Diagrama de Atividades

Barra de

Sincronização Atividade 1 Atividade 2

w w

w .i n

a te

l. b

r

• Bifurcação (Fork)

– Identifica o ponto a partir do qual o processo passou a ser executado em

paralelo.

Diagrama de Atividades

w w

w .i n

a te

l. b

r

• Junção (Join)

– Identifica o ponto a partir do qual o processo paralelo foi sincronizado.

Diagrama de Atividades

w w

w .i n

a te

l. b

r

Exemplos - 1

w w

w .i n

a te

l. b

r

Exemplos - 2

w w

w .i n

a te

l. b

r

http://blog.tcavalcante.com/2009/a-importancia-da-modelagem-de-sistema/

http://www.omg.org/index.htm

http://www.sparxsystems.com/uml-tutorial.html

http://www.uml-diagrams.org/use-case-diagrams-examples.html

Enterprise Architect – EAExample

http://www.fernandoamaral.com.br/Default.aspx?Artigo=40

Referencias

w w

w .i n

a te

l. b

r

Edsger Wybe Dijkstra

http://en.wikipedia.org/wiki/Edsger_W._Dijkstra

Edsger Wybe Dijkstra (Roterdã, 11 de Maio de 1930 — Nuenen, 6 de Agosto

de 2002; foi um cientista da computação holandês conhecido por suas

contribuições nas áreas de desenvolvimento de algoritmos e programas, de

linguagens de programação (pelo qual recebeu o Prêmio Turing de 1972 por

suas contribuições fundamentais), sistemas operacionais e processamento

distribuído.

Entre suas contribuições para a ciência da computação está incluído o

algoritmo para o problema do caminho mínimo (também conhecido como

algoritmo de Dijkstra), o sistema operacional THE e a construção de semáforos

para coordenar múltiplos processadores e programas. Outro conceito

desenvolvido pelo cientista foi a auto-estabilização na área de sistemas

distribuídos, uma forma alternativa de garantir a confiança de um sistema.

O cientista também foi conhecido por seus ensaios sobre programação, tendo

sido o primeiro a alegar que programação é tão inerentemente difícil e

complexa que os programadores precisam realizar qualquer abstração possível

para gerenciar a complexidade com sucesso.

"Ciência da computação tem tanto a ver com o computador como a Astronomia com o

telescópio, a Biologia com o microscópio, ou a Química com os tubos de ensaio. A Ciência

não estuda ferramentas, mas o que fazemos e o que descobrimos com elas."

w w

w .i n

a te

l. b

r

Grady Booch

http://en.wikipedia.org/wiki/Grady_Booch

w w

w .i n

a te

l. b

r

Ivar Jacobson

http://en.wikipedia.org/wiki/Ivar_Jacobson

In 1967 at Ericsson Jacobson proposed the use of

software components in the new generation of software

controlled telephone switches Ericsson was developing.

In doing this he invented seqüência diagrams, and

developed collaboration diagrams. He also used state

transition diagrams to describe the message flows

between components.

Jacobson saw a need for blueprints for software

development. He was one of the original developers of

the Specification and Design Language (SDL). In 1967,

SDL became a standard in the telecoms industry.

At Ericsson he also invented use cases as a way to

specify functional software requirements.

w w

w .i n

a te

l. b

r

James Rumbaugh

http://en.wikipedia.org/wiki/James_Rumbaugh

James Rumbaugh (born 1947) is an American computer

scientist and object methodologist who is best known for his

work in creating the Object Modeling Technique (OMT) and

the Unified Modeling Language (UML).

w w

w .i n

a te

l. b

r

Rational Software

http://en.wikipedia.org/wiki/Rational_Software

Rational Machines was founded by Paul Levy and Mike Devlin in 1981 to provide tools to

expand the use of modern software engineering practices, particularly explicit modular

architecture and iterative development. Rational was sold for US$2.1 billion to IBM on

February 20, 2003.

...

In 1995, James Rumbaugh joined the company, and Rational acquired Ivar Jacobson's firm

Objectory AB from Ericsson. With Grady Booch already aboard, this brought within one

company three of the leading object-oriented software methodologists. These three

experts attempted to unify their work. To eliminate the method fragmentation that they

concluded was impeding commercial adoption of modeling tools, they developed Unified

Modeling Language (UML), which provided a level playing field for all tool vendors. It was

this collaboration effort that earned Rumbaugh, Jacobson and Booch the moniker "The

Three Amigos" within the software engineering industry. At its 1.0 release, the Unified

Modeling Language was contributed to the Object Management Group, which has managed

its subsequent development.

w w

w .i n

a te

l. b

r

Object Management Group

http://en.wikipedia.org/wiki/Object_Management_Group

OMG provides only specifications, and does not provide implementations. But before a

specification can be accepted as a standard by OMG, the members of the winning submitter

team must guarantee that they will bring a conforming product to market within a year.

This is an attempt to prevent unimplemented (and unimplementable) standards.

Other private companies or open source groups are encouraged to produce conforming

products and OMG is attempting to develop mechanisms to enforce true interoperability.

w w

w .i n

a te

l. b

r

Cap. 5 – Modelagem - UML

Profa. Valeska Pivoto Patta Marcondes

EC205 – Engenharia de

Software I

Até o momento nenhum comentário
Esta é apenas uma pré-visualização
3 mostrados em 146 páginas