ENGENHARIA DE SOFTWARE

ORIENTADA A SERVIOS SOA

 MODELAGEM VISUAL UML 2.0

Prof. Fbio Minoru Sakamoto

fabio.skmt@gmail.com

2017
 PROFESSOR FBIO MINORU SAKAMOTO
Atuando profissionalmente h 14 anos no desenvolvimento de softwares.
Ps-Graduado em Enterprise Solution Provider em Objetos Distribudos
com Java FIAP
Graduado em Engenharia de Computao - UFSCar

Currculo Profissional:
Gerente de Projetos no Escritrio de Projetos de TI da Porto Seguro;
Docente na FIAP desde 2006;
TEMPLATE 2
Experincia em desenvolvimento de softwares como Arquiteto de Software,
Analista de Sistemas, Programador e Administrador de Dados;
Atuao nos ramos de Seguros de Automveis, Hospitalar, Financeiro, Mercado
Automotivo, Ensino Distncia e Telefonia Celular.
OBJETIVO DA DISCIPLINA

APRESENTAR CONCEITOS DE ENGENHARIA DE SOFTWARE ABORDANDO

LEVANTAMENTO DE REQUISITOS, ANLISE ORIENTADA OBJETOS E
PRTICAS DE UML NO DESENHO DE SOLUES.
CONTEDO PROGRAMTICO

ENGENHARIA DE SOFTWARE

LEVANTAMENTO DE REQUISITOS

MODELAGEM BASEADO EM CASO DE USO

ORIENTAO OBJETOS

DESENHO DA SOLUO BASEADA EM UML 2

PRTICAS DOS PRINCIPAIS DIAGRAMAS

 METODOLOGIA / AVALIAO

DINMICA
Apresentao de Conceitos do Tpico.
Prticas para Fixao.

AVALIAO
Exerccios propostos durante a disciplina.
Trabalho entregue no portal.
Premissas:
Prazo de entrega de 2 semanas aps o cadastro no Portal.
Nmero de integrantes: 4 pessoas.

* No sero concedidos abonos por falta, salvo excees citadas em regimento.

DESENVOLVIMENTO DE SOFTWARE
METODOLOGIAS DE DESENVOLVIMENTO

METODOLOGIA = Estudo do Caminho

QUEM faz O QUE, QUANDO e COMO
CAMINHO BSICO DE DESENVOLVIMENTO

Especificao

Projeto e
Evoluo
Implementao

Validao
 CONTEXTO DE ATUAO

ANALISTA DE NEGCIO
Requisitos e usurios finais

GERENTE DE PROJETO
Planejamento e controle dos riscos

ANALISTA DE SISTEMAS
Solues sistmicas para requisitos funcionais

DESENVOLVEDOR
Especialista em linguagem de programao

ANALISTA DE TESTES
Consultoria em qualidade de software

ARQUITETO DE SOFTWARE
Estrutura para atendimento dos requisitos funcionais e no funcionais
POR QUE COMETEMOS ERROS?
PAPEL DO ENGENHEIRO DE SOFTWARE
 ENGENHARIA DE SOFTWARE UMA ENGENHARIA

Engenharia de Software um processo de ENGENHARIA, mas...

Codificamos a partir de requisitos hipotticos
Gastamos horas e horas em cdigos extensos e remendados
No seguimos uma arquitetura padro
Produzimos sistemas que no condizem com a expectativa do cliente
Muitas vezes reinventamos a roda
ENGENHARIA QUE ERRA...

https://www.youtube.com/watch?v=damUucIQpC4
 MODELAGEM DE SISTEMA

Simplificao padronizada da realidade.

Variados pontos de vista.
Apresentar estruturas e fluxos.
Antecipar problemas estruturais.
Informao visual de definies.
Mensurar esforo e escopo.
Documentao das definies.
PARMETROS DE CUSTO X BENEFCIO DA MODELAGEM

COMPLEXIDADE
CUSTO DE CONSTRUO
TAMANHO DO TIME
MATURIDADE DO PROCESSO
LEVANTAMENTO DE REQUISITOS
DA NECESSIDADE AO SISTEMA
CAPTAO DOS REQUISITOS

Uma condio ou capacidade que o sistema deve atender.

Entendi !

Correto
NECESSIDADE
Completo
Eu preciso !
Consistente
Sem ambiguidades
NECESSIDADE REQUISITOS Verificvel
Classificvel
Modificvel
Rastrevel
NECESSIDADE
Entendvel
Estabelece e mantm o acordo entre o cliente e o time de projeto.
DEFINIES RELACIONADAS A REQUISITOS

Onde os problemas so definidos?

Viso
Onde os stakeholders e usurios so listados?
Onde os ambientes e plataformas so identificados?

Onde os requisitos no funcionais so registrados? Especificao

Suplementar

Especificao
Onde os casos de uso so mantidos? de Caso de Uso

Onde as terminologias comuns so registradas? Glossrio

Onde so capturadas as necessidades dos stakeholders? Requisitos dos

Stakeholders
REQUISITOS PROBLEMAS COMUNS
CUSTO DA QUALIDADE

0.5 1
Requisito

2.5
Anlise

5
Construo

10
Testes

25
Homologao

100
Produo
FORMANDO O REQUISITO DE SOFTWARE

Conectar usurio ao requisito.

Definir escopo do sistema.
Capturar o comportamento esperado.
Identificar os usurios do sistema.

New or changed Requirements New or changed

Requirements Process System
CASO DE USO

Sequncia de aes
executadas por um sistema que produz um
resultado mensurvel.

Sequncia de aes = atividades atmicas

Resultado mensurvel = gerao de valor
BENEFCIOS DO CASO DE USO

Prov contexto ao requisito.

Facilita o entendimento e a comunicao.
Documenta as decises tomadas.
ATOR

Representa um papel de
um humano, dispositivo ou
sistema.

Agente externo que informa

ou prov informaes.

Os usurios que realmente

pressionam a tecla. ?
PAPIS E RESPONSABILIDADES

O que estou tentando

fazer neste sistema?

Objetivo 1

ATOR

Objetivo 2
 MODELO DE CASO DE USO

Sistema

Caso de uso 1
Levantamento do Modelo
de Caso de Uso Ator 1
- descrio do levantamento
- lista de atores Ator 2
- lista de casos de uso Caso de uso 2

Caso de uso 3

Ator 3

Especif. Caso de Uso 1 Especif. Caso de Uso 2 Especif. Caso de Uso 3

- breve descrio - breve descrio - breve descrio
- fluxo de eventos - fluxo de eventos - fluxo de eventos
 DESENHANDO OS FLUXOS

Nome do UC
Breve descrio
Fluxo Bsico
1. Primeiro passo
2. Segundo passo
Numerar ou 3. Terceiro passo Estruturar o fluxo
demarcar passos em passos
A1 Fluxo alternativo 1
A2 Fluxo alternativo 2
A3 Fluxo alternativo 3

Fluxo Bsico
Fluxos de Alternativos
FLUXO DE EVENTOS

FLUXO BSICO
Comportamento primrio esperado do sistema.

FLUXOS ALTERNATIVOS
Situaes de deciso previstas para o sistema.

FLUXOS DE EXCEO
Situaes que no fazem parte do comportamento esperado do
sistema, mas que possuem tratamento, caso ocorram.
DIGRAMA DE CASO DE USO INVESTIMENTO
ESPECIFICAO DE CASO DE USO PARTE 1

Caso de Uso: Realizar Investimento

Breve descrio: Este caso de uso permite ao cliente do Internet Banking realizar o
procedimento de investir valores em um determinado tipo de investimento disponibilizado
para a conta do cliente.
Atores: Cliente
Interessados: Gesto de Conta Corrente, Gesto do Internet Banking
Pr-condies: O cliente deve ter acesso ao portal do Internet Banking e possuir uma
conta corrente ativa para movimentao. O computador do cliente deve estar habilitado
para realizar transaes no sistema de operaes.
Ps-condies: O cliente realizou o investimento com o valor requerido, sendo o valor
debitado da conta corrente e creditado no investimento selecionado.
ESPECIFICAO DE CASO DE USO PARTE 2

Fluxo Bsico:
1. O cliente seleciona a opo investimentos e seleciona o tipo de investimento.
2. O sistema apresenta a tela de investimentos e solicita o preenchimento do valor e a
data do investimento.
3. O cliente informa o valor e a data e seleciona a opo Investir.
4. O sistema valida a operao, vide UC Validar Operao.
5. O sistema realiza o investimento, exibe um recibo eletrnico da operao e as opes
de imprimir ou voltar.
6. O cliente seleciona a opo voltar.
7. O sistema finaliza a operao voltando tela de investimentos.
Fluxos Alternativos:
2a. A conta no possui autorizao para investimento.
1. O sistema exibe mensagem de erro, com opo de encerramento da operao.
2. O cliente aceita encerramento da operao.
3. O sistema finaliza a operao voltando tela principal do Internet Banking.
2b. O saldo insuficiente para o investimento selecionado.
1. O sistema exibe informa saldo insuficiente para o investimento selecionado.
2. O sistema volta ao fluxo no passo 2.
4a. A data informada no um dia til.
1. O sistema exibe informao de que o investimento ser agendado para o
prximo dia til.
2. O cliente aceita informao e retorna ao fluxo no passo 5.
REVISO DE CONTEDO

O que so requisitos?

Qual a diferena entre requisito Funcional e No Funcional?

Por que o levantamento completo do requisito importante?

O que um caso de uso?

Para que serve uma especificao de caso de uso?

ORIENTAO OBJETOS
O QUE PARADIGMA?

Abordagem de SOLUO para um determinado PROBLEMA.

 PARADIGMA ORIENTAO OBJETOS

Baseado na ANALOGIA BIOLGICA.

Pensamento do final dos anos 60.
Como seria um sistema que funciona como um ser vivo?
Clulas autnomas de tipo definido.
Troca de mensagens.

Alan Kay
 DESENVOLVIMENTO ORIENTADO OBJETOS

Ruptura com o paradigma Procedural.

No se restringe linguagem de programao.
Envolve a Modelagem e Construo.
Baseado nos pilares
Abstrao;
Modularidade;
Hierarquia;
Encapsulamento.

um conjunto de princpios que guiam a construo de um software aliado

linguagem de programao, base de dados e outras ferramentas que
suportam estes princpios.
CONFORMIDADE SOCIAL

https://www.youtube.com/watch?v=hYHo8XXBeMw
 BENEFCIOS

Escopo bem definido dos itens de sistema.

Reuso de estruturas.
Facilidade na manuteno.
Organizao e flexibilidade.
Conexo com o mundo real.
SISTEMAS ORIENTADOS OBJETOS
INVERSO DO PARADIGMA

A abordagem baseada em objetos preocupa-se

primeiro em identificar os objetos contidos no
domnio da aplicao e depois em estabelecer os
procedimentos relativos eles.
Rumbaugh [94]
 OBJETO

Representao clara de uma entidade do mundo real.

Escopo bem definido.
Caractersticas especficas.
Pode ser criado, manipulado e destrudo em memria.
 ESTRUTURA DO OBJETO

ESTADO (Atributos): Caractersticas encapsuladas no objeto.

COMPORTAMENTO (Operaes): Interface de borda do objeto para
mudana de estado.
 MAPEAMENTO DE INFORMAES RELEVANTES

Tipo de Informao
Distino entre instncias nico
Domnio do objeto abstrao
Condio atual estado
Repositrio de informaes referncia

Como entro em contato com o Victor ???

MTODOS RESPONSABILIDADES DE UM OBJETO

O que o objeto pode fazer?

O que pode ser feito no objeto?
ABSTRAO BEM SUCEDIDA DE UM PROCESSO
 CLASSE ESTRUTURA BSICA

Definio de um objeto.
Tipo especfico.
Responsvel pela criao da instncia (OBJETO).
PILARES DA ORIENTAO OBJETOS
ABSTRAO
ENCAPSULAMENTO
MODULARIDADE
HIERARQUIA
APLICAO DA ORIENTAO OBJETOS
 POLIMORFISMO

Vrias respostas dependendo do contextos.

Uma mesma forma de requisio.
 HERANA

Classe filha herda os atributos e operaes da(s) classe(s) pai(s).

Herana Simples: apenas uma superclasse.
Herana Mltipla: mais de uma superclasse.

Simples Mltipla
 INTERFACE

Contrato do escopo semntico de um conjunto de classes.

 OO REVISO DE CONTEDO

Como a Orientao Objetos promove o reuso e facilita a manuteno?

O que um objeto? O que uma classe?
O que um atributo? Qual o propsito de mtodo com relao ao atributo?
O que polimorfismo? Exemplifique.
Qual o benefcio da herana na orientao objetos?
Explique o propsito da interface.
APLICANDO O CONHECIMENTO

OK!
MAS COMO EU FAO ISSO?!?!?!
UNIFIED MODELING LANGUAGE UML
 O QUE UML ?

UML - Unified Modeling Language

Object-Oriented Analysis and Design (OOAD) - incio dos anos 90.
Unificou os mtodos de Booch, Rumbaugh (OMT), and Jacobson (OOSE).
Padronizado pela OMG.
uma linguagem de modelagem e no um mtodo.
No indica a ordem de execuo ou como deve ser feito um projeto.
uma notao independente de processos, embora o RUP (Rational Unified
Process) tenha sido especificamente desenvolvido utilizando a UML.
LOS TRES AMIGOS

Grady Booch, Jim Rumbaugh e Ivar Jacobson

HISTRIA DA UML
DIAGRAMAS DA UML 2
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

1. Diagrama de Caso de Uso

 PROPSITO

Expectativa do cliente.
Funcionalidades macro do sistema.
Papis e Responsabilidades.
Visualizao simples e fcil para o cliente.
ABORDAGEM POR CASO DE USO

Quais funcionalidades devem ser includas e excludas?

Como o sistema se comunica com outros sistemas (arquitetura)?

Quem ser o usurio do sistema?

Quais so as dependncias do sistema?

Quais so os produtos e/ou resultados do sistema?

Quais so as funcionalidades utilizadas por cada usurio?

 NOTAO

Ator
Caso de Uso
Associao
<< include >>
<< extend >>
Generalizao
 ATOR

Agente externo ao sistema.

Pessoa, Sistema, Dispositivo ou Empresa.
Produzem estmulo ou provm informaes.
Ligado ao menos a um caso de uso.
HIERARQUIA DE ATORES
 CASO DE USO

Funcionalidade macro de um sistema.

O nome expressa um objetivo a ser atingido.
Aborda interfaces e no detalhes de implementao.
Sempre ligado ao menos a um ator.
 RELACIONAMENTO ATOR X UC ASSOCIAES

Comunicao entre o ator e o caso de uso.

Necessidade de tratamento de interface a cada ator.
 RELACIONAMENTO UC X UC INCLUDE

Relacionamento com elementos reutilizveis.

Diviso de elementos com muita responsabilidade.
 RELACIONAMENTO UC X UC EXTEND

Relacionamento com elementos que decidem quando executar.

Pontos de extenso: avaliao de atuao do caso de uso de extenso.

Caso de Uso de Extenso

Caso de Uso Base

Pontos de Extenso
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

2. Diagrama de Atividade
 PROPSITO

Processo de negcio de forma simples e clara.

Requisitos lgicos do sistema (workflow).
Base para manuais e treinamento.
 ATIVIDADE E TRANSIO

Atividade: passo no processo onde um trabalho feito.

Transio: seta que indica o prximo passo.
Condio de Guarda: condio a ser satisfeita.
PONTO DE INCIO E FIM
 ATIVIDADE E TRANSIO

Deciso: alternativas mutuamente exclusivas.

OU

Juno: convergncia das alternativas da deciso.

 ATIVIDADE E TRANSIO

Bifurcao: paralelizao de atividades.

Sincronizao: convergncia das atividades paralelas.

RAIAS
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

3. Diagrama de Classes
 PROPSITO

Recursos essenciais do sistema.

Relacionamento entre os recursos.
Insumo para gerao de cdigo.
Representao de uma engenharia reversa.
Foco de ataque para os outros diagramas.
COMPARTIMENTOS DE UMA CLASSE
COMPARTIMENTO I NOME

NOME
 COMPARTIMENTO I NOME DA CLASSE

nico e Coeso.
No singular (exceto colees).
Padronizao por camel case.
Indica o propsito no sistema.
Engloba o nome do Pacote (Pacote :: Classe).
 COMPARTIMENTO I ESTERITIPO

Semntica.
No impactam diretamente o empacotamento ou a codificao.
COMPARTIMENTO I PROPRIEDADES
COMPARTIMENTO II

ATRIBUTOS
 COMPARTIMENTO II SINTAXE DO ATRIBUTO

Sintaxe:
[visibility] [/] name [: type] [multiplicity] [=default] [{property-string}]
COMPARTIMENTO II VISIBILIDADE DO ATRIBUTO

- Privado: somente dentro da prpria classe

~ Pacote: somente dentro do mesmo pacote
+ Pblico: dentro do sistema
# Protegido: dentro da herana
 COMPARTIMENTO II ATRIBUTOS

Nome Tipo Padro

Visibilidade

Derivao
Multiplicidade
COMPARTIMENTO II PROPERTY-STRING
 COMPARTIMENTO II ATRIBUTO ESTTICO

Atributo da classe.
Todas as instncias visualizam e modificam o mesmo valor.
Representao sublinhada.
COMPARTIMENTO III

OPERAES
 COMPARTIMENTO III SINTAXE DAS OPERAES

Sintaxe:
[visibility] name ([parameter-list]) ':' [return-result] [{properties}]
COMPARTIMENTO III OPERAES

Nome

Visibilidade

Retorno

Parmetros
 COMPARTIMENTO III OPERAES

No precisam de instncia.
Tratam apenas de atributos estticos.
Geralmente esto em classes utilitrias.
RELACIONAMENTOS ENTRE CLASSES

RELACIONAMENTOS
 RELACIONAMENTOS REALIZAO

Contrato de servios implementados pelas classes concretas.

Formalizao de assinaturas de funcionalidades.
 RELACIONAMENTOS ASSOCIAO

Estabelece uma ligao de conhecimento entre duas classes.

 RELACIONAMENTOS MULTIPLICIDADE

Nmero vlido de objetos nos lados da associao.

Multiplicidade Descrio
0..10 Zero a Dez (opcional)
1..20 Um a Vinte (mandatrio)
0..* ou * Zero ou Mais
2..* Dois ou Mais
1,3..6 Ou Um ou de Trs a Seis
RELACIONAMENTOS ASSOCIAO REFLEXIVA
 RELACIONAMENTOS AGREGAO

Relao hierrquica.
O TODO maior que a soma das PARTES.
Proteo a integridade da configurao dos objetos.
nico ponto de controle.
 RELACIONAMENTOS COMPOSIO

Mais forte que a Agregao.

O ciclo de vida das PARTES depende do ciclo de vida do TODO.
A PARTE no pode ser separada do TODO.
 RELACIONAMENTOS GENERALIZAO

Objetos com os mesmos propsitos.

Superclasse e subclasse (especializao).
 RELACIONAMENTOS DEPENDNCIA

Ligao temporria entre classes.

HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

4. Diagrama de Objetos
 PROPSITO

Suporta a investigao dos requisitos.

Base para a construo dos casos de testes.
Valida o diagrama de classes.
NOTAO

Opcional
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

5. Diagrama de Estrutura Composta

 PROPSITO

Revelar as partes de um componente complexo.

Revelar a interface para de um componente em sua estrutura.
Descrever os papis de cada um dos elementos na estrutura.
 NOTAO

Classe
Partes
Portas
Conectores
REGRA DE UM NVEL DE ANINHAMENTO
EXEMPLO DE ESTRUTURA COMPOSTA

House

:Window :Window

Kitchen Bath

:Window :Door

Passage

:Window

Hall Bedroom :Window

HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

6. Diagrama de Sequncia
 PROPSITO

Esclarecer questes especficas, comandos e dados no processo.

Comunicaes e interfaces envolvidos no processo.
Identificar os objetos participantes.
Identificar os parmetros enviados nas mensagens.
 LINHA DE VIDA

Tempo de existncia de um objeto para o sistema.

Cada objeto possui uma linha independente dos demais.
Posicionamento:
Topo: criao prvia;
Abaixo: criao durante o processo.
 MENSAGENS

Especificao formal de um estmulo.

Comunicao entre objetos:
Invocar uma operao;
Lanar um sinal;
Criar/destruir um objeto.
 MENSAGENS SNCRONAS

Chamada que aguarda em retorno.

 MENSAGENS ASSNCRONAS

Chamada que no aguarda retorno para seguir o processo.

 MENSAGENS ASSNCRONAS

O emissor e o receptor so referenciam o mesmo objeto.

Operao privada.
 BARRA DE ATIVAO OU FOCO DE CONTROLE

Tempo de processamento.
CRIAO / DESTRUIO DE OBJETOS

Criao

Destruio
EXEMPLO UML 1

Iterao
 NOTAO UML 2 FRAGMENTOS

Operadores:
alt : alternativa;
opt : opo;
loop : iterao;
break : quebra de loop;
par : processamento paralelo.
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

7. Diagrama de Comunicao
 PROPSITO

Revelar a estrutura de objetos para execuo de um processo.

Revelar as interfaces requeridas no processo.
Identificar mudanas estruturais necessrias para satisfazer a interao.
Identificar os parmetros enviados nas mensagens.
Diagrama de Colaborao na verso 1.4 e anteriores.
Diagrama de Sequncia (Isomrfico)
 NOTAES

Objetos.
Links.
Mensagens.
Numerao de sequencia obrigatria.
EXPRESSO DE ITERAO ( * )
CONDIO DE GUARDA ( [ ] )
 MODELAGEM DA COMUNICAO

1) Identificar objetos participantes;

2) Relacionar os objetos conforme diagrama de classes;
3) Adicionar a mensagem com uma seta do emissor para o receptor;
4) Numerar a ordem de execuo.
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

8. Diagrama da Interao Geral

 PROPSITO

Viso de alto nvel no progresso entre as interaes.

Encorajar o reuso das interaes.
Validar as decises tomadas nas
vises detalhadas.
 NOTAES

Interao.

Ocorrncia de Interao
 NOTAES

Ns de Bifurcao e Sincronizao

Decises e Juno
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

9. Diagrama de Mquina de Estados

 PROPSITO

Identificar respostas especficas do objeto.

Descobrir ou validar o domnio de valores de um objeto.
Detalhar comportamentos internos do objeto.
 NOTAES

Estado

Ns inicial e final
 TRANSIO

Sintaxe: nome ( [lista-parametros] ) [ [condio-guarda] ] / [ao]

Evento = gatilho

Condio de guarda = quando o gatilho est armado

Ao = consequncia do disparo do gatilho

REPRESENTAES DAS AES

Eliminar
Redundncia
* Aes que ocorrem durante a permanncia no estado.
AUTO TRANSIES
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

10. Diagrama de Tempo

 PROPSITO

Requisitos de tempo para mudana de estado.

Representao de eventos crticos.
 NOTAES

Linha do tempo.
Estados.
Eventos.
Restries.
Durao.
LINHAS MLTIPLAS
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

11. Diagrama de Pacotes

 PROPSITO

Dependncias funcionais e de dados de um sistema.

Identificar a partio em subsistemas ou fases do projeto.
Separao de utilitrios e componentes especficos do sistema.
Isolar as camadas definidas pela arquitetura.
 NOTAES

Pacote.

Aninhamento.
 VISES MACRO DE PACOTES

SUBSISTEMA: Diviso do sistemas em grandes partes gerenciveis.

MODELO: Organizao do sistema por pontos de vista.

HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

12. Diagrama de Componentes

 PROPSITO

Modelar o software fisicamente permitindo a anlise de distribuio.

Detalhar o relacionamento entre os componentes do sistema.
Identificar gargalos da arquitetura.
NOTAES

*representao do tipo Caixa Branca

 RELACIONAMENTO DE DEPENDNCIA

Nvel conceitual.
As interfaces no esto explcitas.
 RELACIONAMENTO POR INTERFACE

Interface Provida: servio oferecido pelo componente.

Interface Requerida: servio solicitado pelo componente.
EXEMPLO DIAGRAMA DE COMPONENTES
HIERARQUIA DE DIAGRAMAS
MODELAGEM COM UML

13. Diagrama de Implantao

 PROPSITO

Modelar a topologia de rede para o sistema.

Identificar capacidades de hardware definidas nos requisitos no funcionais.
 NOTAES

N >> Dispositivo >> Ambiente de Execuo >> Componente.

Caminho da Comunicao.
DIAGRAMA DE IMPLANTAO + COMPONENTES
NVEIS DE REPRESENTAO
HIERARQUIA DE DIAGRAMAS
ESTUDO DE CASO
 LOCADORA O VELHO E BOM EXEMPLO

O cenrio contm os seguintes atores :

Cliente e Atendente, onde o cliente o ator pai tendo como filho os atores Clientes
Loja e Clientes Telefone;
Use cases:
O Cliente pode executar o use case localizar filme, locar filme, abrir conta, devolver
filme.
O atendente pode executar qualquer um dos use cases alm do status da conta.
Locar filme demanda uma verificao para saber se o filme est no banco de dados e
se a cpia est na loja.
Localizar filme demanda uma verificao para saber se o filme est no banco de dados.
Abrir conta permite que tanto o cliente quanto o atendente abram uma nova conta.
Devolver filme faz com que o cliente devolva o filme para a loja e o atendente coloque
o filme no banco de dados como disponvel.
Status da conta executado apenas pelo atendente e verifica qual o status de um
determinado cliente, seus filmes locados e devolvidos.
Copyright 2008-2017 Prof. Fbio Sakamoto

Todos direitos reservados. Reproduo ou divulgao

total ou parcial deste documento expressamente
probido sem o consentimento formal, por escrito, do
Professor (autor) ou FIAP.