Aula00 Apresentação UML

(1)

UML

Motivação

(2)

© LES/PUC-Rio

O que é um modelo?

• Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.

(3)

(4)

© LES/PUC-Rio

(5)

(6)

© LES/PUC-Rio

Por que modelar software?

• 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

(7)

O que é a UML?

• Unified Modeling Language (UML) é...

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

construir e documentar os artefatos de um sistema de

software.

... resultado da unificação das notações utilizadas nos métodos

Booch, OMT (Object Modeling Technique) e OOSE

(Object-Oriented Software Engineering).

... adotada por grande parte da indústria de software e por

fornecedores de ferramentas CASE como linguagem padrão de modelagem.

… utilizada com qualquer processo de desenvolvimento já que é independente dele.

(8)

© LES/PUC-Rio

A UML é uma Linguagem

• Uma linguagem fornece um vocabulário e as regras para a

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

• Uma linguagem de modelagem é uma linguagem cujo

vocabulário e regras têm seu foco voltado para a representação conceitual e física de um sistema.

• 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 seqüência.

• Facilita a comunicação entre membros da equipe de desenvolvimento.

(9)

A UML é uma Linguagem para...

...visualização, especificação, construção e documentação. http://www.uml.org/ http://www.omg.org/

(10)

© LES/PUC-Rio

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.

• 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 ambigüidade em sua interpretação.

(11)

A UML é uma Linguagem para

Especificação

• No presente contexto, especificar significa construir modelos precisos, completos e sem ambigüidades.

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

(12)

© LES/PUC-Rio

A UML é uma Linguagem para

Construção

• Os modelos de UML podem ser diretamente ” traduzidos” 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.

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

(13)

A UML é uma Linguagem para

Documentação

• Cada modelo criado é um artefato do software

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 UsuarioBlog -email:String +notificarExclusao:void Conteudo -dtCriacao:Date -texto:String -autor:UsuarioBlog +Conteudo +exibirConteudo:void Blog -dtCriacao:Date -titulo:String -dono:UsuarioBlog -conteudos:Vector +criarNota:void +exibirConteudo:void +comentar:void +lerComentarios:Vector +removerConteudo:void +lerNotas:Vector +Blog Nota -comentarios:Vector -attribute1:int +comentar:void +lerComentarios:Vector +finalize:void Comentario +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>> … …

(14)

© LES/PUC-Rio

Uma linguagem de 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

(15)

(16)

Uma colagem de diagramas UML

(17)

Vantagens da Utilização da UML

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

(18)

História dos métodos orientado a objetos e

notações

(19)

Breve História da UML

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

(20)

UML: Casos de Uso

(21)

UML – Casos de Uso

• Introdução – Casos de uso

• Elementos do diagrama de casos de uso

• Descrição de casos de uso

• Exemplo: Blog

• Ferramentas de modelagem

(22)

© LES/PUC-Rio

Introdução – Casos de Uso

• Os 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

 Dão uma visão externa do sistema

 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 especificam como isso deve ser feito

(23)

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama:

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

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

(24)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

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

(25)

Elementos – Diagrama de Casos de Uso

• 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

(26)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os atores

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

(27)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os atores

• E o cliente?

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

Gerente

Atendente

(28)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

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

(29)

Elementos – Diagrama de Casos de Uso

• 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

Notação:

(30)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os casos de uso

(31)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os casos de uso

Administrar estoque Vender CDs

(32)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

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

(33)

Elementos – Diagrama de Casos de Uso

• Relacionamento de 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

Dicas:

 NÃO use setas nas associações

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

Notação:

Ator

Caso de Uso

(34)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os relacionamentos de associação

(35)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando os relacionamentos de associação

Atendente

Gerente

Vender CDs

(36)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

(37)

Elementos – Diagrama de Casos de Uso

• Relacionamento de 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.

Dica: coloque os herdeiros embaixo

(38)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando generalização de atores

Atendente

Gerente

Vender CDs

(39)

Elementos – Diagrama de Casos de Uso

• Relacionamento de 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

Dica:

deve ser aplicada quando uma condição resulta na definição de

diversos fluxos alternativos.

(40)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando generalização de casos de uso

Novos requisitos:

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

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

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

(41)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Atendente

Vender CDs

Vender CDs à vista Vender CDs a prazo

(42)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando mais generalização de casos de uso

Novos requisitos:

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

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

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

(43)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

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

(44)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

(45)

Elementos – Diagrama de Casos de Uso

• Relacionamento de 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

• Partes opcionais: caso de uso estendido

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

Notação:

<<extends>>

(46)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando dependência: extensão

Novos requisitos:

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

– No caso de uma venda a prazo...

...Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras à vista.

(47)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando dependência: extensão

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

Vender c/ boleto Calcular desconto

<<extend>> <<extend>>

(48)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Relacionamento de 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

Notação:

<<includes>>

(49)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando dependência: inclusão

Novos requisitos:

– Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema.

(50)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando dependência: inclusão

Atendente

Gerente

Vender c/ cartão

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

(51)

Elementos – Diagrama de Casos de Uso

• Elementos do diagrama

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

(52)

© LES/PUC-Rio

Elementos – Diagrama de Casos de Uso

• Fronteira do Sistema

– Elemento opcional (mas essencial para um bom entendimento)

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

(53)

Elementos – Diagrama de Casos de Uso

Exemplo:

Loja de CDs

Identificando a fronteira do sistema

Atendente

Vender c/ cartão

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

(54)

© LES/PUC-Rio

Descrição de Casos de Uso

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

• UML não especifica padrão

• Pode ser:

– Informal

– Típica

(55)

Descrição de Casos de Uso

• Descrição Informal

– Contém o nome do caso de uso e

uma descrição textual de sua funcionalidade

(56)

© LES/PUC-Rio

Descrição de Casos de Uso

• 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

– Fluxos alternativos (se houver)

(57)

Descrição de Casos de Uso

• Descrição Detalhada (Ex.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

(58)

(59)

Descrição de Casos de Uso

• Descrição Detalhada (Ex.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 • Observações Usar este tipo de descr ição de casos de uso nos trab alhos da discip lina!

(60)

(61)

(62)

(63)

Exemplo: Blog

• 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 informações: texto, data de criação e autor

• 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

(64)

© LES/PUC-Rio

Exemplo: Blog

blogSystem

Remover Conteudo Remover Nota

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

(65)

UML: Diagrama de Classes

(66)

© LES/PUC-Rio

UML – Diagrama de Classes

• Introdução – Diagrama de classes

• Elementos do diagrama de classes

(67)

Introdução - Diagrama de Classes

• 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

(68)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

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

(69)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

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

(70)

© LES/PUC-Rio

Elementos – Diagrama de Classes

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

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

Nome_da_classe atributo1 atributo2 ... metodo1 metodo2 metodo3 ...

(71)

Elementos – Diagrama de Classes

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:

(72)

© LES/PUC-Rio

Elementos – Diagrama de Classes

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:

(73)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

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

(74)

© LES/PUC-Rio

Elementos – Diagrama de Classes

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

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

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

(75)

Elementos – Diagrama de Classes

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

• Relacionamentos

E a navegabilidade? nome

(76)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Relacionamentos

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

Endereço

Cliente

₁ reside _*

(77)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

(78)

© LES/PUC-Rio

Elementos – Diagrama de Classes

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

(79)

Elementos – Diagrama de Classes

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

– m..n Faixa de valores (por exemplo: 4..7)

Pessoa 1..* Empresa

associação

multiplicidade

* trabalha para

(80)

© LES/PUC-Rio

Relacionamentos: Associação

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

(81)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

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

(82)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Relacionamento: Agregação

– É um tipo especial de associação

– Utilizada para indicar “todo-parte”

– um objeto “parte” pode fazer parte de vários objetos “todo”

Item

Pedido

1 1..*

agregação

(83)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

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

(84)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Relacionamento: 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

– Quando o “todo” morre todas as suas “partes” também morrem

Teclado

Notebook

Frame

Window

1 ₁ 1 _0..* 1..* 0..* errado

(85)

Elementos – Diagrama de Classes

• Relacionamento: Composição

Ex:

Janela

Scroll Título Corpo 1 0..1 2 1 Empresa Departamento Escritório 1 1..* 1..* 0..1 *

(86)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Agregação

X

Composição

Andar

1..n

Edifício

Mesa

Sala

1..n 11 1..n 1..n

(87)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

(88)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Relacionamento: 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

(89)

Elementos – Diagrama de Classes

• Elementos de um diagrama de classes

(90)

© LES/PUC-Rio

Elementos – Diagrama de Classes

• Relacionamento: Dependência

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

Ex:

Obs:

• 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

(91)

Exemplo: Sistema de Matrícula

A Universidade XYZ deseja informatizar seu sistema de matrículas:

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

• Estudantes selecionam 4 disciplinas.

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

• Todos os usuários do sistema devem ser validados.

(92)

© LES/PUC-Rio

Exemplo: Sistema de Matrícula

(93)

Exemplo: Sistema de Matrícula

Descrição do Caso de Uso “Matricular em Disciplina”

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

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

(94)

Exemplo: Sistema de Matrícula

Professor Coordenador Estudante

Turma Universidade Disciplina FormularioMatricula Curso AnalisadorMatricula SistemaRegistroAcademico ListaAlunos

(95)

Exemplo: Sistema de Matrícula

• Exemplos de candidatos a relacionamentos:

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

– A é um tipo de B.

(96)

Exemplo: Sistema de Matrícula

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

de matrícula

• O analisador de matrícula gerencia a disciplina

FormularioMatricula é-processado-por AnalisadorMatricula

1 0..*

Disciplina

FormularioMatricula é-processado-por AnalisadorMatricula

1 0..*

1

0..*

(97)

Exemplo: Sistema de Matrícula

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 Diagrama de Classes

(98)

Exemplo: Sistema de Matrícula

– 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

(99)

Exemplo: Sistema de Matrícula

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 Diagrama de Classes

(100)

Exemplo: Sistema de Matrícula

– Somente depois de modelar os diagramas de seqüência

SIM submeterFormulario(formulario) AnalisadorMatricula adicionar(aluno, disciplina) : SIM : AnalisadorMatricula 2: adicionar(a,d ) 1: submeterFormulario(f)

(101)

Exemplo: Sistema de Matrícula

• E a navegabilidade?

public class Turma {

private String codigo; private String sala;

private Estudante alunos[]; ...

}

Diagrama de Classes:

public class Estudante { private String nome;

private String matricula; ... }

Turma

Estudante

3..10

está-matriculado-em

3..10 4

(102)

Exemplo: Sistema de Matrícula

• Acrescentando generalizações:

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

Estudante matricula : Inteiro definirMatricula(matricula) obterMatricula() Usuario nome : Texto definirNome(nome) obterNome() Professor titulacao : Texto definirTitulacao(titulacao) obterTitulacao() Diagrama de Classes:

(103)

Exemplo: Sistema de Matrícula

SIM Usuario nome : Texto definirNome(nome) obterNome() FormularioMatricula obterEstudante() : Estudante

obterNomeDIsciplina(i : Inteiro) : Texto

Estudante matricula : Inteiro definirMatricula(matricula) obterMatricula() 1 1 é-preenchido-por 1 1 -aluno Professor titulacao : Texto definirTitulacao(titulacao) obterTitulacao() AnalisadorMatricula adicionar(aluno, disciplina) 11 11 usa 1 0..* ₁ 0..* é-processado-por Disciplina nome : Texto numCreditos : Inteiro estaCompleta() adicionar(aluno : Estudante) 0..* 1 0..* 1 gerencia Turma codigo : Texto sala : Texto horario : Horario numAlunos : Inteiro completa : Booleano estaCompleta() : Booleano 3..10 4 3..10 4 está-matriculado-em 0..3 1 0..3 1 responsável-por 1..* 11 1..*

(104)

Diagramas de Seqüência

(105)

Interações

• Comportamento que

– Envolve conjunto de mensagens trocadas entre objetos dentro de um determinado contexto

– Objetiva atingir resultado específico

• Acontecem em função da troca de mensagens entre objetos

• Usadas para a modelagem dos aspectos dinâmicos de um

(106)

Comunicação entre Objetos

• Mensagem

– Recepção de mensagem por um objeto

• Considerado instância de evento

– Decorrência da passagem de uma mensagem

• Repercute ação representada por um comando executável

• Comando Executável: abstração de procedimento computacional

Ident. Operação

Ident. Objeto Parâmetros

Mensagem =

mensagem

(107)

Diagramas de Interação

• Deseja-se representar o comportamento de vários

objetos

– Dentro de um único caso de uso

– A partir das mensagens que são passadas entre eles

• Objetivo

– Definir um contexto de caso de uso

– Estabelecer os objetos que interagem e seus

relacionamentos

• Termo genérico que se aplica a dois tipos de diagramas que

enfatizam interações entre objetos

– Diagrama de Seqüência

(108)

Duas formas de representação

• Informações bastante similares mas de maneira diferente

– Diagrama de Seqüência

• Interação enfatizando o tempo de seqüência

• Mostra objetos participando em interações de acordo com suas linhas de vida e as mensagens que trocam

– Diagrama de Colaboração

(109)

Diagrama de seqüência

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

(110)

Termos e conceitos

• Objetos

• Linhas de vida

• Mensagens

• Focos de controle

(111)

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”

• Objetos tem nomes

– obj:Classe

Ex.: joão:Dentista

:Floricultor (um objeto floricultor não identificado) obj1: (um objeto obj1 sem classe definida)

(112)

jose

Floricultor CentralFloriculturacentral

joao:Dentista floricultorPetropolis Floricultor 1.1: atendeCidade("Petropolis"):boolean 1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean 1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean

1.2:[se nao na cid...] getFloricultorNaCidade("Petropolis"):Floricultor

(113)

Linhas de Vida

• Dimensão vertical do diagrama

• Apresentam o tempo de vida dos objetos

• Pode apresentar a ativação ou a desativação dos objetos

– Indicam que os objetos estão executando algo

• Foco de controle

– Caixas de ativação podem ser empilhadas

• Indica chamada de método do próprio objeto

• Objeto jose no slide anterior

(114)

114 © LES/PUC-Rio pedido vendedor estoque 2.2: reservarItem 3.1: confirmarPedido 2.1: verificarDisponibilidade 4: 3: confirmarPedido 2:*[*] //adicionarItem 1:

Linhas de Vida

Linhas de vida new()

(Caixas de) Ativação

kill()

Criação

(115)

Mensagens

• 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

• 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

(116)

Mensagens - Tipos

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

– call

• Invoca uma operação sobre um objeto

– Objeto pode mandar uma chamada para si próprio

» Resultando na execução local de uma operação

– return

• Representa o retorno de um valor para o objeto que chamou a operação • Opcional – create • Criação de um objeto – destroy • Eliminação de um objeto new() <<create>> kill() <<destroy>>

(117)

Mensagens - Representações

Símbolo Significado

Mensagem síncrona

Mensagem assíncrona

(118)

Mensagens

mensagens Auto-delegação jose

Floricultor CentralFloriculturacentral

joao:Dentista floricultorPetropolis Floricultor 1.1: atendeCidade("Petropolis"):boolean 1.3: aceitaEncomenda("Rosas","Rua X,9"):boolean 1: enviarFlores("Rosas","Maria","Petropolis","Rua x, 9"):boolean

(119)

Mensagens – Condições de Guarda

• Mensagens podem apresentar condições de guarda

– condições em que a mensagem é enviada

– [condição de guarda]

:Aluno :Sistema _:Impressora

login() sistemaOk matricula() turmaCheia [sem vaga] matriculado imprimirRelatório() [com vaga] Matrícula

(120)

Mensagens - Iteração

• Uma mensagem pode ser enviada repetidas vezes

– * mensagem(...) pedido vendedor estoque 2.2: reservarItem 3.1: confirmarPedido 2.1: verificarDisponibilidade 4: 3: confirmarPedido 2:*[*] //adicionarItem 1: * adicionarItem pedido vendedor

(121)

Foco de Controle

• Período de tempo que o objeto executa uma ação

• Relação de controle entre ativação e o responsável pela sua

(122)

Diagrama de Seqüê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

(123)

Análise OO do RUP

• Objetivo

– Modelar o comportamento de cada caso de uso com o objetivo de detalhar os serviços de negócios oferecidos pelo sistema

• Uso de apenas 3 tipos de classes

– Fronteira (boundary)

• Classes de interface com o mundo externo (ex: GUI, sistemas externos)

– Controle (control)

• Coordenam o comportamento do caso de uso definindo uma interface entre classes fronteira e entidade

– Entidade (entity)

(124)

Blog - Casos de uso

blogSystem

Remover Conteudo Remover Nota

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

(125)

(126)

Blog - Diagrama de Seqüência: Criar blog

: UsuarioBlog

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

2: criarBlog(titulo, usuario)

(127)

Blog - Diagrama de Seqüência: Criar Nota

: 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()

(128)

Ferramentas de Modelagem

• Omondo – Plugin para Eclipse -

http://www.omondo.com/

• Jude -

https://jude.change-vision.com/jude-web/

• Together -

http://www.borland.com/products/downloads/download_together.html

• IBM Rational Rose -

http://www.ibm.com/software/rational

(129)

(130)

(131)

Bibliografia

• Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001.

• Fowler, M e Scott, K., UML Distilled – A Brief Guide to the standard

Object Modeling Language, Addison Wesley Longman, 2002

• Booch, G., Rumbaugh, J. and Jacobson, I., Unified Modeling

Language User Guide, 2nd Edition, Addison-Wesley Object