z7 - aula07 - UML

(1)

ENGENHARIA DE SOFTWARE

Prof. Paulo Malcher

prcmalcher@gmail.com

https://sites.google.com/site/professorpaulomalcher/

(2)

(3)

(4)

(5)

Modelo – O que é?

• Construímos

modelos

para

compreender

melhor o sistema que estamos desenvolvendo.

• Um

modelo

é

uma

simplificação

da

(6)

(7)

(8)

(9)

Modelo de Software – Por que?

• Ajuda a ter uma visão geral do sistema.

• Permite

especificar

a

estrutura

e

o

comportamento do sistema.

• Proporciona um guia para a construção do

sistema.

(10)

Modelo de Software – Por que?

• Modelos

de

sistemas

complexos

são

construídos porque nem sempre é possível

compreendê-los em sua totalidade.

• Modelos auxiliam o entendimento dos sistemas

(11)

Modelo de Software – Por que?

Avião de papel Jato militar

(12)

UML – O que é?

• Unified Modeling Language (UML)

é...

• ...uma linguagem gráfica para visualizar,

especificar, construir e documentar os artefatos de um sistema de software.

(13)

UML – O que é?

• Unified Modeling Language (UML)

é...

• ...resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object-Oriented Software Engineering).

(14)

UML – O que é?

• Unified Modeling Language (UML)

é...

• ...adotada por grande parte da indústria de software e por fornecedores de ferramentas CASE como

(15)

UML – O que é?

• Unified Modeling Language (UML)

é...

• …utilizada com qualquer processo de

(16)

UML – O que é?

• Unified Modeling Language (UML)

é...

• ...uma linguagem fornece um vocabulário e as

regras para a combinação de “palavras” desse vocabulário, com o objetivo de comunicar algo.

(17)

UML - Linguagem

• Uma linguagem fornece um vocabulário e as

regras para a combinação de

” palavras ”

desse

vocabulário,

com

o

objetivo

de

(18)

UML - Linguagem

• O vocabulário e as regras de uma linguagem

de modelagem indicam como criar e ler

modelos bem formados, mas não apontam

quais modelos devem ser criados e nem em

que sequência.

(19)

UML - Linguagem

• Facilita a comunicação entre membros da

(20)

A UML é uma Linguagem para...

• ...visualização,

• especificação,

• construção e

• documentação...

...de artefatos de um sistema de software

http://www.uml.org/ http://www.omg.org/

(21)

A UML é uma Linguagem para...

• ...VISUALIZAÇÃO

• No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um sistema sem o uso de modelos que a represente.

• A UML fornece os símbolos gráficos para a representação de artefatos de software.

(22)

A UML é uma Linguagem para...

• ...VISUALIZAÇÃO

• Por trás de cada símbolo empregado na notação da UML, existe uma sintaxe e uma semântica bem-definidas.

• Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo, diminuindo a ambiguidade em sua interpretação.

(23)

A UML é uma Linguagem para...

• ...ESPECIFICAÇÃO

• No presente contexto, especificar significa construir modelos precisos, completos e sem ambiguidades.

• A UML atende a todas as decisões importantes em termos de análise, projeto e implementação, que devem ser tomadas para o desenvolvimento e implantação de sistemas complexos de software.

(24)

A UML é uma Linguagem para...

• ...CONSTRUÇÃO

• Os modelos de UML podem ser diretamente

“traduzido” para várias linguagens de programação.

• Isso significa que é possível mapear os modelos da UML para linguagens de programação tais como, Java, C++ e Visual Basic. Mapeamento para tabelas em um SGBDR ou armazenamento persistente em um SGBDOO.

(25)

A UML é uma Linguagem para...

• ...CONSTRUÇÃO

• Os modelos de UML podem ser diretamente

“traduzido” para várias linguagens de programação.

• Esse mapeamento permite a realização de uma

engenharia de produção: geração de código a partir de um modelo em UML.

• O processo inverso, a engenharia reversa, também é possível, com a reconstrução de um modelo a partir de sua implementação.

(26)

A UML é uma Linguagem para...

• ...DOCUMENTAÇÃO

• Documenta a arquitetura do sistema, requisitos, testes, planejamento do projeto e gestão de versionamento. Cada modelo criado é um artefato do software. Diagrama de Casos de Uso Diagrama de Classe GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fList 1 FileList add( ) delete( ) 1 File read( )

read() fill the code.. Diagrama de Seqüência user mainWnd fileMgr : FileMgr repository document : Document gFile

1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) Æ¯Á¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»ÇÑ´Ù. ÈÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äÃ»ÇÑ´Ù. È¸é °´Ã¼´Â ÀÐ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ º¸¿©ÁØ´Ù. Diagrama de Implantação Window95 ¹®¼°ü¸® Å¬¶óÀÌ¾ðÆ®.EXE Windows NT ¹®¼°ü¸® ¿£Áø.EXE Windows NT Windows95 Solaris ÀÀ¿ë¼¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌÅ¸º£ÀÌ½º¼¹ö Windows95 ¹®¼°ü¸® ¾ÖÇÃ¸´ ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Å¬¶óÀÌ¾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼¹ö, Åë½Å ¼¹ö Actor A Use Case 1 Use Case 2 Use Case 3 Actor B

(27)

A UML é uma Linguagem para...

• ...DOCUMENTAÇÃO

Diagrama de Seqüência : SIM : AnalisadorMatricula 2: adicionar(a,d ) 1: submeterFormulario(f) 0..* 1 autor 0..* 0..* 1 dono 0..* 1 usuario 0..* usa Us u ario Bl og -email:String +notificarExclusao:void Co nte ud o -dtCriacao:Date -texto:String -autor:UsuarioBlog +Conteudo +exibirConteudo:void Bl og -dtCriacao:Date -titulo:String -dono:UsuarioBlog -conteudos:Vector +criarNota:void +exibirConteudo:void +comentar:void +lerComentarios:Vector +removerConteudo:void +lerNotas:Vector +Blog No ta -comentarios:Vector -attribute1:int +comentar:void +lerComentarios:Vector +finalize:void C o men tari o +finalize:void Diagrama de Classes Diagrama de Casos de Uso

blogSystem Criar Comentario

Ler Conteudo

Remover Conteudo Remover Nota Remover Comentario Criar Blog Ler Comentario Ler Nota Criar Nota Usuario Dono do blog <<include>> <<include>> <<include>> … …

(28)

UML - Diagramas

Diagramas de Classe Diagramas de Colaboração Diagramas de Seqüência Diagramas de Estado Diagramas de Atividade Diagramas de Objetos Diagrama de Deployment Diagramas de Componentes

Diagrama de Casos de Uso _Modelos

Ponto de Vista Estático

(29)

(30)

(31)

(32)

UML Experiências de parceiros _{UML 1.0} (Jan. 1997) UML 1.1 (Set. 1997) UML 1.5 (Mar, 2003) UML 2.0 (2004) Outros Métodos Booch 1991 OMT - 1 OOSE Booch, 1993 OMT - 2 Feedback do público Unified Method 0.8 (OOPSLA, 1995) UML 0.9 (Jun, 1996) UML 0.91 (Out. 1996) and

UML - Histórico

(33)

UML - Histórico

1994 Método

de Booch (Rumbaugh)OMT (Jacobson) OOSE Outros métodos Unified Method 0.8 UML 1.0 UML 1.1 UML 1.4 UML 1.3 UML 0.9 UML 1.5 UML 2.0 1995 1996 1997 1999 2001 2003 2004 - 2005

(34)

UML - Histórico

Fusion Descrição de operações Numeração de mensagens Condições anteriores e posteriores Meyer Harel Diagrama de estados Wirfs-Brock Responsabilidades Embley Classes Singleton, Visão de alto nível

Odell

Classificação Ciclo de vida de objetos

Shlaer- Mellor Gamma, et.al Frameworks, padrões, notas Booch Rumbaugh Jacobson

Selic, Gullekson, Ward

ROOM (Real-Time

(35)

UML - Vantagens

• Padrão aberto e não proprietário.

• Extensível.

• Independência

do

processo

de

desenvolvimento.

• Aplicável

a

todas

as

fases

do

ciclo

de

desenvolvimento.

• Independência

de

linguagem

de

(36)

UML - Vantagens

• Padrão aberto e não proprietário.

• Extensível.

• Independência

do

processo

de

desenvolvimento.

• Aplicável

a

todas

as

fases

do

ciclo

de

desenvolvimento.

• Independência

de

linguagem

de

(37)

UML - Vantagens

• A UML é independente de processo. Um

processo

beneficia

completamente

a

UML

quando ele é:

• guiado por casos de uso;

• centrado em arquitetura;

(38)

(39)

Cenário do Problema

• Uma empresa, para a qual será construído o

sistema, atua no ramo alimentício através de

vendas de pizzas e bebidas. Possui um quadro

de três funcionários fixos e dois momentâneos.

A Figura 1 mostra os cargos de acordo com a

organização

interna

da

empresa

e

as

(40)

(41)

Cenário do Problema

• No contexto da empresa, foi possível notar que

já existia um sistema, porém, não era utilizado

devido à falta de comunicação do computador

com a impressora multifuncional. Além disso, a

empresa não recebia nenhuma assistência

técnica em relação aos problemas existentes

no

sistema.

Quando

era

mencionado

um

encontro para resolução de problemas, o

desenvolvedor não comparecia nem justificava

o motivo da ausência. Tais circunstâncias

motivaram ao abandono do sistema.

(42)

Cenário do Problema

• Consequentemente,

a

empresa

faz

os

processos de anotação de pedidos e entregas

manualmente, registrando cada pedido em

bloco de notas individuais, havendo riscos de

trocar informações ou até mesmo perdê-las.

Depois de anotado, o pedido é repassado ao

pizzaiolo que prepara-o seguindo apenas as

referências contidas nos blocos de notas.

(43)

Cenário do Problema

• Por fim, cabe ao garçom identificar o destino

dos pedidos de cada cliente tomando como

base as anotações informadas por ele mesmo.

Ao fim da noite, aquelas anotações são jogadas

fora ou, pelo menos, a maioria delas, sem

possibilidade de consulta de dados, causando a

perda total dessas informações.

(44)

(45)

Cenário do Problema

• A partir do levantamento de requisitos foram

identificados vários problemas existentes no

sistema antigo. Por exemplo, ocorrem erros na

impressão de notas, devido a problemas de

comunicação do sistema com a impressora.

(46)

Cenário do Problema

• Quando

o

atendente

necessita

efetuar

a

impressão de um relatório ou cupom fiscal, o

sistema

exibe

uma

mensagem

de

erro,

informando que o dispositivo de saída da

impressora não é reconhecido no sistema,

ocorrendo falha na impressão. Além disso,

existem

problemas

com

identificações

de

clientes por telefone, onde o cliente deveria

aparecer no monitor com seus dados de

cadastro e histórico de informações durante

uma ligação.

(47)

Cenário do Problema

• Quando ocorre uma ligação, o sistema não

reconhece o cliente sendo atendido. Não há

suporte nem disponibilidade do criador do

software

para

assessorar

a

empresa

em

processos de manutenção. Quando o sistema

era usado, os usuários não tinham domínio das

funcionalidades

do

sistema,

dessa

forma,

(48)

Cenário do Problema

• Tarefa:

Desenvolver

uma

solução

para

o

problema da pizzaria de forma textual (lista de

requisitos) e realizar a modelagem do sistema

proposto sem utilizar nenhuma notação padrão.

Desenvolver modelos que sejam claros para

todos.

(49)

Cenário do Problema

• Pontos fortes:

• Definição das funcionalidades do sistema e de seus atores

• Definição de classes e objetos do sistema (Estados e Comportamento)

• Definição do Fluxo do Sistema

• Criatividade

(50)

UML

(51)

UML - Casos de Uso

• Introdução

– Casos de uso

• Elementos do diagrama de casos de uso

• Descrição de casos de uso

(52)

UML - Casos de Uso - Introdução

• CASOS DE USO

• Descrevem como os usuários interagem com o sistema (as funcionalidades do sistema)

• Facilitam a organização dos requisitos de um sistema.

(53)

UML - Casos de Uso - Introdução

• CASOS DE USO

• O conjunto de casos de uso deve ser capaz de comunicar a funcionalidade e o comportamento do sistema para o cliente.

• Descrevem o que o sistema faz, mas NÃO

(54)

UML - Casos de Uso - Elementos

• ELEMENTOS DO DIAGRAMA

• Atores • Casos de uso • Relacionamentos • Associação • Generalização

• Dependência: Extensão e Inclusão

(55)

UML - Casos de Uso - Elementos

• ATORES

• Representam os papéis desempenhados por elementos externos ao sistema

• Ex: humano (usuário), dispositivo de hardware ou outro sistema (cliente).

• Elementos que interagem com o sistema

Notação:

Secretária

(from Use Case View)

Diretor

Sistema de Relatórios

(56)

UML - Casos de Uso - Elementos

• ATORES - EXEMPLO: LOJA DE CDS

• Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

(57)

UML - Casos de Uso - Elementos

• ATORES - EXEMPLO: LOJA DE CDS

• Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

(58)

UML - Casos de Uso - Elementos

• ATORES - EXEMPLO: LOJA DE CDS

• Identificando os atores

• E o cliente?

• Não é ator pois ele não interage com o sistema!

Gerente

Atendente

(59)

UML - Casos de Uso - Elementos

• CASO DE USO

• Representa uma funcionalidade do sistema (um requisito funcional)

• É iniciado por um ator ou por outro caso de uso

• Dicas:

• Nomeie os casos de uso iniciando por um verbo

(60)

UML - Casos de Uso - Elementos

• CASOS DE USO - EXEMPLO: LOJA DE CDS

(61)

UML - Casos de Uso - Elementos

• CASOS DE USO - EXEMPLO: LOJA DE CDS

• Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

(62)

UML - Casos de Uso - Elementos

• CASOS DE USO - EXEMPLO: LOJA DE CDS

• Identificando os Casos de Uso

Administrar estoque Vender CDs

(63)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS

• Representa a relação entre atores e casos de usos ou entre casos de usos.

• Pode ser divididos em:

• Associação

• Generalização

(64)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• Indica que há uma interação (comunicação) entre um caso de uso e um ator.

• Um ator pode se comunicar com vários casos de uso.

Notação:

Ator

Caso de Uso

(from Use Case Vi ew)

(65)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

Notação:

Dicas:

 NÃO use setas nas associações

 Associações NÃO representam fluxo de informação

Ator

Caso de Uso

(from Use Case Vi ew)

(66)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• EXEMPLO: LOJA DE CDS

(67)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• EXEMPLO: LOJA DE CDS

• Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

(68)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• EXEMPLO: LOJA DE CDS

Atendente Gerente Vender CDs Administrar estoque

(69)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS

– GENERALIZAÇÃO

• GENERALIZAÇÃO DE ATORES

• Quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso

• Um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica.

(70)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• GENERALIZAÇÃO DE ATORES

Notação:

Dicas:

(71)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• EXEMPLO: LOJA DE CDS

(72)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• EXEMPLO: LOJA DE CDS

• Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.

(73)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• EXEMPLO: LOJA DE CDS

Atendente Gerente Vender CDs Administrar estoque

(74)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS

– GENERALIZAÇÃO

• GENERALIZAÇÃO DE CASOS DE USO

• O caso de uso filho herda o comportamento e o significado do caso de uso pai

• O caso de uso filho pode incluir ou sobrescrever o comportamento do caso de uso pai

• O caso de uso filho pode substituir o caso de uso pai em qualquer lugar que ele apareça

Notação: Pai

(75)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• GENERALIZAÇÃO DE CASOS DE USO

Notação:

Dicas:

 SEMPRE deve ser aplicada quando uma condição

resulta na definição de diversos fluxos alternativos

Pai

(76)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• EXEMPLO: LOJA DE CDS – NOVOS REQUISITOS

• As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma nota fiscal, entregue ao consumidor.

(77)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma nota fiscal, entregue ao consumidor.

(78)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

Atendente Vender CDs Gerente Vender CDs à vista Vender CDs a prazo Administrar estoque

(79)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

(80)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

(81)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

(82)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

Atendente Vender CDs Gerente Vender CDs à vista Vender CDs a prazo Administrar estoque Vender c/ cartão Vender c/ boleto

(83)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• EXTENSÃO

• Representa uma variação/extensão do

comportamento do caso de uso base.

• O caso de uso estendido só é executado sob certas circunstâncias.

• Separa partes obrigatórias de partes opcionais

• Partes obrigatórias: caso de uso base

(84)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• EXTENSÃO

• Fatorar comportamentos variantes do sistema (podendo reusar este comportamento em outros casos de uso).

(85)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

(86)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

(87)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

(88)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.

(89)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

Atendente Vender CDs Gerente Vender CDs à vista Vender CDs a prazo Administrar estoque Vender c/ cartão

Vender c/ boleto Calcular desconto

<<extend>>

(90)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• INCLUSÃO

• Evita repetição ao fatorar uma atividade comum a dois ou mais casos de uso

• Um caso de uso pode incluir vários casos de uso

(91)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• Para efetuar vendas ou administrar estoque, atendentes e

gerentes terão que validar suas respectivas senhas de acesso ao sistema.

(92)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• Para efetuar vendas ou administrar estoque, atendentes e

gerentes terão que validar suas respectivas senhas de acesso

(93)

UML - Casos de Uso - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

Atendente

Gerente

Vender CDs à vista Vender CDs a prazo

Vender c/ cartão

<<extend>> <<extend>> Fazer login Vender CDs Administrar estoque <<include>> <<include>>

(94)

UML - Casos de Uso - Elementos

• FRONTEIRA DO SISTEMA

• Elemento opcional (mas essencial para um bom entendimento).

• Serve para definir a área de atuação do sistema.

(95)

UML - Casos de Uso - Elementos

• FRONTEIRA DO SISTEMA

Atendente

Gerente

Vender CDs à vista Vender CDs a prazo

Vender c/ cartão

<<extend>> <<extend>> Fazer login Vender CDs Administrar estoque <<include>> <<include>>

(96)

UML - Casos de Uso – Descrição

• A descrição é mais importante do que o

diagrama.

• A UML não especifica padrão, pode ser:

• Informal

• Típica

(97)

UML - Casos de Uso – Descrição

• DESCRIÇÃO INFORMAL

• Contém o nome do caso de uso e

uma descrição textual de sua funcionalidade

(98)

UML - Casos de Uso – Descrição

• DESCRIÇÃO TÍPICA

• Contém:

• Identificação do ator que iniciou o caso de uso

• Pré-requisitos (se houver) do caso de uso

• Descrição textual do: Fluxo normal

(99)

UML - Casos de Uso – Descrição

• DESCRIÇÃO TÍPICA

(100)

UML - Casos de Uso – Descrição

• DESCRIÇÃO DETALHADA 1

• Contém:

• Identificação do ator que iniciou o caso de uso

• Objetivo

• Nível

• Pré-requisitos (se houver) do caso de uso

• Condições de disparo (triggers)

• Descrição textual do: Fluxo normal

(101)

(102)

UML - Casos de Uso – Descrição

• DESCRIÇÃO DETALHADA 2

• Contém: • Nome • Descrição sucinta • Atores • Pré-condições • Pós-condições • Fluxo básico • Fluxos alternativos • Fluxos de exceção • Estruturas de dados • Regras de negócio

(103)

(104)

(105)

(106)

UML - Exemplo de Casos de Uso

• Um blog é uma ferramenta de colaboração.

• Um blog é formado por um conjunto de

conteúdos:

• notas

• comentários sobre as notas

• Os

conteúdos

possuem

as

seguintes

(107)

UML - Exemplo de Casos de Uso

• Os usuários de um blog podem ser:

• Usuário: pode ler conteúdos de um blog, comentar uma nota, remover comentários, e pode criar um blog.

• Dono do blog: além de todas as funcionalidades de um usuário comum, o dono do blog pode criar notas e remover notas

• Para remover um conteúdo o usuário precisa

(108)

UML - Exemplo de Casos de Uso

blogSystem

Criar Comentario

Ler Conteudo

Remover Conteudo Remover Nota

Remover Comentario Criar Blog Ler Comentario Ler Nota Criar Nota Usuario Dono do blog <<include>> <<include>> <<include>>

(109)

UML

(110)

UML – Diagrama de Classes

• Introdução

– Diagrama de classes

• Elementos do diagrama de classes

(111)

UML - Diagrama de Classes - Introdução

• Mostra

um

conjunto

de

classes

e

seus

relacionamentos.

• É o diagrama central da modelagem orientada

a objetos.

Aluno nome: Texto matrícula: Inteiro definirNome(nome) obterNome() definirMatricula(matricula) obterMatricula Turma código: Texto sala: Texto horario: Horario estaAberta() definirProfessor(professor) incluirAluno(aluno) está-matriculado-em Professor nome: Texto titulação: Texto definirNome(nome) obterNome() definirTitulacao(titulo) obterTitulacao é-ministrada-por

(112)

UML - Diagrama de Classes - Elementos

• ELEMENTOS DO DIAGRAMA

• Classes • Relacionamentos • Associação Agregação Composição • Generalização • Dependência

(113)

UML - Diagrama de Classes - Elementos

• CLASSES

• Graficamente, as classes são representadas por retângulos incluindo nome, atributos e métodos.

• Devem receber nomes de acordo com o vocabulário do domínio do problema.

• É comum adotar um padrão para nomeá-las

Nome_da_classe atributo1 Atributo2 ... metodo1 metodo2 metodo3 ...

Ex: todos os nomes de classes serão substantivos singulares com a primeira letra maiúscula

(114)

UML - Diagrama de Classes - Elementos

• CLASSES - ATRIBUTOS

• Representam o conjunto de características (estado) dos objetos daquela classe.

• Visibilidade:

+ público: visível em qualquer classe de qualquer pacote.

# protegido: visível para classes do mesmo pacote.

- privado: visível somente para classe.

EXEMPLO:

(115)

UML - Diagrama de Classes - Elementos

• CLASSES - MÉTODOS

• Representam o conjunto de operações

(comportamento) que a classe fornece.

• Visibilidade:

+ público: visível em qualquer classe de qualquer pacote

# protegido: visível para classes do mesmo pacote

- privado: visível somente para classe

EXEMPLO:

(116)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS

• Os relacionamentos possuem:

• Nome: descrição dada ao relacionamento (faz, tem, possui,...).

• Sentido de leitura.

• Navegabilidade: indicada por uma seta no fim do relacionamento

(117)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS

• Os relacionamentos possuem:

• Multiplicidade: 0..1, 0..*, 1, 1..*, 2, 3..7

• Tipo: associação (agregação, composição), generalização e dependência.

• Papéis: desempenhados por classes em um relacionamento.

(118)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS

Pessoa 1..* Empresa Tipo: associação multiplicidade * trabalha para empregado papéis empregador sentido de leitura E a navegabilidade? nome

(119)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS

O cliente sabe quais são seus endereços, mas o endereço não sabe a quais clientes pertence.

(120)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• Uma associação é um relacionamento estrutural que indica que os objetos de uma classe estão vinculados a objetos de outra classe.

• Uma associação é representada por uma linha sólida conectando duas classes.

Pessoa Empresa

(121)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• Indicadores de multiplicidade:

• 1 Exatamente um

• 1..* Um ou mais

• 0..* Zero ou mais (muitos)

• * Zero ou mais (muitos)

• 0..1 Zero ou um

(122)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

Pessoa 1..* Empresa associação multiplicidade * trabalha para

(123)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• EXEMPLO

• Um Estudante pode ser um aluno de uma Disciplina e um jogador da Equipe de Futebol.

• Cada Disciplina deve ser cursada por no mínimo 1 aluno.

(124)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• AGREGAÇÃO

• É um tipo especial de associação.

• Utilizada para indicar “todo-parte”.

Item

Pedido

1 1..* agregação todo _parte

Um objeto “parte” pode fazer parte de vários objetos “todo”.

(125)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• COMPOSIÇÃO

• É uma variante semanticamente mais “forte” da agregação.

• Os objetos “parte” só podem pertencer a um único objeto “todo” e têm o seu tempo de vida coincidente com o dele.

Teclado

Notebook 1 1 Window 1 0..* Frame

1..* 0..*

(126)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• COMPOSIÇÃO - EXEMPLO Empresa Departamento Escritório 1 1..* 1..* 0..1 *

(127)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

• COMPOSIÇÃO - EXEMPLO

Janela

Scroll Título Corpo

1 0..1

(128)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - ASSOCIAÇÃO

(129)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - GENERALIZAÇÃO

• É um relacionamento entre itens gerais (superclasses) e itens mais específicos (subclasses).

“é um” “é um tipo de” superclasse subclasse Veículo Terrestre Aéreo

(130)

UML - Diagrama de Classes - Elementos

• RELACIONAMENTOS - DEPENDÊNCIA

• Representa que a alteração de um objeto (o objeto indepedente) pode afetar outro objeto (o objeto dependente).

cliente fornecedor

• A classe cliente depende de algum serviço da classe fornecedor. • A mudança de estado do fornecedor afeta o objeto cliente.

• A classe cliente não declara nos seus atributos um objeto do tipo fornecedor. • Fornecedor é recebido por parâmetro de método.

(131)

UML - Diagrama de Classes - Exemplo

• CENÁRIO

• A Universidade XYZ deseja informatizar seu sistema de matrículas e foi descoberto que:

• A universidade oferece vários cursos.

• O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre.

• Várias disciplinas são oferecidas em um curso.

• Várias turmas podem ser abertas para uma mesma disciplina, porém o número de estudantes inscritos deve ser entre 3 e 10.

(132)

UML - Diagrama de Classes - Exemplo

• CENÁRIO

• A FAPAN deseja informatizar seu sistema de matrículas e foi descoberto que:

• Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico (SRA) é notificado.

• Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas.

• Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas.

(133)

UML - Diagrama de Classes - Exemplo

(134)

UML - Diagrama de Classes - Exemplo

(135)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CASOS DE USO - DESCRIÇÃO

• Esse caso de uso se inicia quando o Estudante de Curso inicia uma sessão no sistema e apresenta suas credenciais.

• O sistema verifica se a credencial é válida.

• O sistema solicita que o estudante realize sua matrícula, selecionando 4 disciplinas.

• O estudante preenche um formulário eletrônico de matrícula e o submete para uma análise de consistência.

(136)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CASOS DE USO - DESCRIÇÃO

• O sistema analisa as informações contidas no formulário.

• Se as informações são consistentes, o estudante é incluído em turmas abertas de 4 disciplinas, iniciando pelas preferenciais.

• Se as informações não são consistentes, o sistema informa o motivo da inconsistência e solicita que o formulário seja alterado.

(137)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

(138)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Identificar Classes

Professor Coordenador Estudante

Turma Universidade Disciplina FormularioMatricula Curso AnalisadorMatricula SistemaRegistroAcademico ListaAlunos

(139)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

(140)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Identificar Relacionamentos

(141)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Candidatos?

A é parte física ou lógica de B.

A está contido fisicamente ou logicamente em B. A é uma descrição de B.

A é membro de B.

A é subunidade organizacional de B. A usa ou gerencia B.

A se comunica/interage com B.

A está relacionado com uma transação B. A é possuído por B.

(142)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• O formulário de matrícula é processado por um analisador de matrícula

1 0..*

(143)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• O analisador de matrícula gerencia a disciplina.

Disciplina

FormularioMatricula é-processado-por AnalisadorMatricula

1 0..*

1

(144)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Identificar Relacionamentos Professor Coordenador Estudante Turma Disciplina FormularioMatricula AnalisadorMatricula é-preenchido-por está-matriculado-em é-processado-por é-ministrada-por é-definida-por aluno gerencia 1 1 1 0..* 1 0..* 1 1..* 1 1..* 1 0..3 3..10 4

(145)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Identificar Atributos

• Os atributos podem ser encontrados examinando-se as descrições dos casos de uso e também pelo conhecimento do domínio do problema.

Cada turma oferecida possui um código, uma sala e um horário.

Turma

- código - sala - horário

(146)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

Coordenador FormularioMatricula AnalisadorMatricula é-preenchido-por está-matriculado-em é-processado-por é-ministrada-por é-definida-por aluno gerencia 1 1 1 0..* 1 0..* 1 1..* 1 1..* 1 0..3 3..10 4 Turma - código - sala - horário Professor - nome - titulação Estudante - nome - matricula Disciplina - nome - numCréditos

(147)

UML - Diagrama de Classes - Exemplo

• DIAGRAMA DE CLASSES

• Acrescentando Generalização

• Atributos, operações e/ou relacionamentos comuns podem ser movidos para uma classe mais geral.

(148)

(149)

UML

(150)

UML – Diagrama de Sequência

• Introdução

– Diagrama de sequência

• Elementos do diagrama de sequência

(151)

UML - Diagrama de Sequência -Introdução

• Mostra a interação entre os objetos.

• Determina

a

sequência

de

eventos

que

ocorrem em um determinado processo

• Quais condições devem ser satisfeitas ...

• Quais métodos devem ser disparados ...

(152)

UML - Diagrama de Sequência -Introdução

• Baseia-se no Diagrama de Casos de Uso

• 1 Caso de Uso  N Diagramas de Sequência

• Baseia-se, também, no Diagrama de Classes

(153)

UML - Diagrama de Sequência - Elementos

• ELEMENTOS DO DIAGRAMA

(154)

UML - Diagrama de Sequência - Elementos

• ATORES

• Exatamente os mesmos dos Casos de Uso

• Interagem  Solicitam serviços  Eventos  Processos

(155)

UML - Diagrama de Sequência - Elementos

• OBJETOS

• Representam as instâncias das classes.

• Retângulos contendo um texto.

• Primeira parte, em minúsculo, o nome do objeto

• Segunda parte, em letras iniciais maiúsculas, o nome da classe

• Informações separadas por dois pontos (:)

• Linha de vida

(156)

UML - Diagrama de Sequência - Elementos

• OBJETOS

• Apresentados na dimensão horizontal do diagrama.

• Ordem dos objetos não é considerada

• Dispô-los de forma a tornar o diagrama “mais legível”

(157)

UML - Diagrama de Sequência - Elementos

• OBJETOS

jose Floricultor c en tral CentralFloricultura joao:Den tista

floric ul torPe trop olis Floricultor

1.1: atendeCidade("Petropolis"):boolean

1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean 1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean

(158)

UML - Diagrama de Sequência - Elementos

• LINHAS DE VIDA

• Representa o tempo que um objeto existiu durante um processo

• Linhas finas verticais tracejadas

• Iniciam no retângulo que representa o objeto

• Interrompida por um “X” quando o objeto é destruído

(159)

UML - Diagrama de Sequência - Elementos

• LINHAS DE VIDA

p ed ido vendedor estoque 2.2: reservarItem 3.1: confirmarPedido 2.1: verificarDisponibilidade 4: 3: confirmarPedido 2:*[*] //adicionarItem 1: Linhas de vida new()

(Caixas de) Ativação

kill()

Criação

(160)

UML - Diagrama de Sequência - Elementos

• FOCO DE CONTROLE/ATIVAÇÃO

• Indica os períodos em que um determinado objeto está participando ativamente do processo

• Executando um ou mais métodos do processo

• Representados por extensões mais grossas/largas da Linha de Vida

(161)

UML - Diagrama de Sequência - Elementos

(162)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS

• Objetos interagem através da troca de mensagens.

• Setas sólidas que vão do objeto solicitante para o solicitado

Para o próprio objeto: auto-delegação

• Rotulados com os nomes dos estímulos mais os argumentos (ou valores dos argumentos) do estímulo

(163)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS

• Demonstram a ocorrência de eventos que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo.

• Mensagens entre:

• Ator e Ator

• Ator e Objeto

• Objeto e Objeto

(164)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS

• Sintaxe

• onde

• return é o nome do valor de retorno

• message é o nome da mensagem

• parameter é o nome de um parâmetro da mensagem

• parameterType é o nome do tipo desse parâmetro

• returnType é o tipo do valor de retorno

(165)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - TIPO

• Tipos de ação que uma mensagem pode representar

• Call: Invoca uma operação sobre um objeto

• Return: Representa o retorno de um valor para o objeto que chamou a operação

• Create: Criação de um objeto

(166)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - CALL

(167)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - RETURN

(168)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - CREATE

(169)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - DESTROY

• Mensagem que dispara um método destrutor – elimina um objeto não mais necessário.

(170)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - GUARDA

• Mensagem com Condição de Guarda

• condições em que a mensagem é enviada

(171)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - GUARDA

:Aluno :Sistema _:Impressora login() sistemaOk matricula() turmaCheia [sem vaga] matriculado imprimirRelatório() [com vaga] Matrícula

(172)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - ITERAÇÃO

• Uma mensagem pode ser enviada repetidas vezes

(173)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - ITERAÇÃO

* adicionarItem pedido vendedor p ed ido ven de do r e sto qu e 2.2: reservarItem 3.1: confirmarPedido 2.1: verificarDisponibilidade 4: 3: confirmarPedido 2:*[*] //adicionarItem 1:

(174)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS - REPRESENTAÇÃO

Símbolo Significado

Mensagem síncrona Mensagem assíncrona

(175)

UML - Diagrama de Sequência - Elementos

(176)

UML - Diagrama de Sequência - Elementos

(177)

UML - Diagrama de Sequência - Elementos

• MENSAGENS/ESTÍMULOS

mensagens Auto-delegação jose Floricultor c en tral CentralFloricultura joao:Den tista

floric ul torPe trop olis Floricultor

1.1: atendeCidade("Petropolis"):boolean

1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean 1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean

(178)

UML - Diagrama de Sequência - Elementos

Tempo (top-down) ObjetoA ObjetoB [se novo] <<create>> mensagem

mensagem (auto delegação) valor de retorno <<destroy>> (caixa de)ativação condição de guarda mensagem síncrona objeto símbolo de destruição linha de vida

(179)

UML - Diagrama de Sequência - Construção

• Escolher um caso de uso

• Identificar os objetos que fazem parte da

interação

• Identificar o objeto que começa a interação

• Identificar as mensagens trocadas entre os

objetos

(180)

UML - Diagrama de Sequência - Exemplo

blogSystem

Criar Comentario

Ler Conteudo

Remover Conteudo Remover Nota Remover Comentario Criar Blog Ler Comentario Ler Nota Criar Nota Usuario Dono do blog <<include>> <<include>> <<include>>

(181)

(182)

UML - Diagrama de Sequência - Exemplo

: UsuarioBlog

: UsuarioBlog : GUIBlog : GUIBlog : ControladorBlog : ControladorBlog : Blog : Blog 1: criarBlog(titulo, usuario)

2: criarBlog(titulo, usuario)

(183)

UML - Diagrama de Sequência - Exemplo

: UsuarioBlog

: UsuarioBlog : GUIBlog : GUIBlog : ControladorBlog : ControladorBlog : Blog : Blog _{: Nota}_{: Nota} 1: criarNota(usuario, idBlog, comentario)

2: criarNota(usuario, idBlog, comentario) 3: consultarBlog(idBlog)

4: getDono()

(184)

(185)

UML - Diagrama de Sequência – Exemplo 2

Fluxo Principal

1. O usuário solicita o cadastro de cliente.

2. O sistema apresenta o formulário para preenchimento.

3. O usuário entra com as informações necessárias do cliente no sistema e submete. 4. O sistema valida o cadastro do cliente. (FE01) (FE02)

5. O sistema armazena os dados do cliente. 6. O sistema cria uma conta em nome do cliente

7. O sistema notifica o usuário sobre o cadastro e o caso de uso termina.

Fluxos Alternativo

FA01 - Usuário cadastrado

1. Se o cliente já estiver cadastrado, uma mensagem será exibida e o caso de uso termina.

FA02 - Dados incompletos

1. Se os dados estiverem incompletos, o sistema exibe uma mensagem para que o usuário forneça as informações completas e o caso de uso retorna ao passo 3 do fluxo principal.

(186)

(187)

UML - Diagrama de Sequência – Revisão

:RegisterForCoursesForm :RegistrationController SWTSU Catalog :

CourseCatalogSystem

Objetos anônimos

Linhas de vida