Renata Araujo UNIRIO Projeto e Construção de Aplicações com Ambientes de Programação 2002.1 Unified Modeling Language

Renata Araujo

UNIRIOProjeto e Construção de Aplicações com Ambientes de Programação

2002.1

Unified Modeling Language

2

Introdução

UML é uma linguagem para Especificar Visualizar Construir

.... Artefato de sistemas de software

Oferece uma notação para a modelagem de sistemas seguindo os conceitos da orientação a objetos.

3

Introdução

A UML tem sido encarada como um padrão. Inicialmente, um esforço de integração dos principais

autores de métodos OO: Ivar Jacobson, Grady Booch e Jim Rumbaugh

A partir de 1997, foi submetida como candidata a padrão à OMG (Object Management Group)

www.omg.org

A UML é uma linguagem para modelagem; ela não guia o desenvolvedor em como fazer a análise e projeto orientado a

objetos, ou qual processo de desenvolvimento deve ser seguido

A UML é uma linguagem para modelagem; ela não guia o desenvolvedor em como fazer a análise e projeto orientado a

objetos, ou qual processo de desenvolvimento deve ser seguido

4

Diagramas da UML

Visão Externa Diagrama de Casos de Uso

Visão Estrutural (Estática) Diagrama de Classes

Visão Comportamental (Dinâmica) Diagrama de Estado Diagrama de Atividade

Visão de Interação Diagrama de Sequência Diagrama de Colaboração

Visão da Arquitetura (Implementação) Diagrama de Componentes Diagrama de Implantação Diagrama de Pacotes

5

Diagramas de Caso de Uso

Especificam a visão externa do sistema Descrevem como o sistema é percebido por seus

usuários Descrevem as interações entre os usuários e o

sistema

Consulta de saldo

Ator

Solicitação de extrato

Interações

6

Diagramas de Classe

Descrevem a parte estática do sistema, ignorando seu processamento

Apresentam Classes (objetos) Atributos Relacionamentos

Herança Agregação Associação

Serviços

7

Diagramas de Estado

Apresentam as sequências de estados que um objeto assume em sua existência em resposta a estímulos recebidos

Complemento das descrições estáticas de classes

Relacionam os possíveis estados que os objetos de uma classe podem ter e quais os eventos que causam mudanças em seu estado.

Pedido Registrado

Pedido em Análise

Pedido para análise requisitado

Pedido enviado

Pedido em Aprovação

Pedido para aprovação

Aprovação emitida

Pedido Aprovado

Pedido será atendido

Classe Pedido

8

Diagramas de Sequência

Apresentam a interação entre os objetos no decorrer do tempo

Mostra a sequência de mensagens entre objetos

Vendedor

Janela Pedido Nota Fiscal Fatura Cliente

1: situação financeira do cliente 2: obter pedidos

(cliente)

3: obter notas fiscais (pedido)

4: obter faturas vencidas (nota fiscal)

5: obter faturas a vencer (nota fiscal)

6: obter limite de crédito (cliente)

9

Diagrama de Classes

Passos para confecção

Identificação de Classes

Identificação de relacionamentos

Definição de atributos

Definição de serviços

10


O domínio do problema Um determinado domínio de problemas inclui informações

relativas ao mundo real

Os requisitos da aplicação Considerados os objetivos da aplicação a ser construída,

apenas um subconjunto dessas informações necessita ser representado

11


Cliente Nome Endereço Altura Peso Idade Sexo Renda Mensal Cor dos Cabelos Número de Dependentes ...

Cliente Nome Endereço Idade Sexo Renda Mensal Número de Dependentes

No mundo real Em uma dada aplicação/sistema

12


No mundo real Numa aplicação/sistema

Cliente

Endereço

Carro Dependentes

Time

Nome

Cliente

Nome

Endereço

13


O que procurar? Objetos

Ex. Pessoas, clientes, turmas, cursos, produtos etc. Agentes

Ex. cliente, atendente etc. Unidades organizacionais

Ex. local para entrega, setor etc. Eventos

Reclamação do cliente, pedido pago etc.

“Quaisquer conceitos que serão armazenados e “lembrados” pelo sistema.”

14


O que Considerar? Armazenamento necessário

O sistema precisará armazenar informações sobre os objetos desta classe?

Mais de um objeto em uma classe É possível identificar facilmente os objetos desta classe? Evite classes que representem um só objeto

Atributos sempre aplicáveis Todos os atributos identificados para a classe são aplicáveis a

todas as suas instâncias?

15


Notação de classe

Nome da Classe

<lista de atributos>

<Lista de serviços/operações>

16


Recomendações Nomenclatura de classes

Nome da classe deve descrever claramente o conceito representado

Uso de termos de conhecimento de todos Evitar abreviaturas Estabelecimento de padrões para nomeação de classes Evitar ambigüidades (dupla interpretação)

Uso Fast CasePrática

17

Definição de Atributos

Objetivo Identificar e formalizar a definição dos atributos de cada

classe presente no diagrama de classes

O que considerar? Necessidade do sistema em armazenar as características das

instâncias das classes

18


Representação gráfica

Nome da Classe



19


Notação de atributos

Visibilidade Nome do Atributo: Tipo de Expressão = Valor Inicial {Propriedade}

Visibilidade: Critério de acesso ao atributo Opcional

+ visibilidade pública (default) Atributo pode ser acessado por todos, inclusive por serviços de outras classes

# visibilidade protegida Atributo é acessado apenas pelos serviços da própria classe ou por serviços de classes

dentro de um mesmo pacote

- visibilidade privada Atributo é acessado por operações da própria classe

20




Visibilidade:

Aluno

+ Nome# Endereço- Créditos

21




Nome do atributo Obrigatório!!!! Necessidade de padronização Clareza de significado Evitar abreviaturas

Aluno

+ Nome# EndereçoDoAluno- CréditosObtidos

22




Tipo de Expressão Opcional Tipo de implementação do atributo

Inteiro String Real ... Aluno

+ Nome: string# EndereçoDoAluno: string- CréditosObtidos: int

23




Valor Inicial Valor inicial do atributo Opcional

Aluno

+ Nome: string# EndereçoDoAluno: string- CréditosObtidos: int = 0

24




Propriedade Opcional Maior detalhamento do atributo

Descrição Tipo

Estático Constante Variável

Domínio de Valores

Aluno

+ Nome: string# EndereçoDoAluno: string-CréditosObtidos: int = 0-NumMáximoDeCréditos: int = 70 {constant}

25


Notação de atributos Exemplo

Nome da Classe

AtributoAtributo:tipo do dadoAtributo:tipo do dado = valor inicial

Aluno

NomeEndereço:stringCréditos:inteiro = 0


26

Definição de Serviços

Objetivo Identificar e formalizar a definição das operações de cada

classe presente no diagrama de classes

O que considerar? Necessidade de cada classe em realizar operações que

atendam às funcionalidades do sistema

27


Representação Gráfica

Nome da Classe



28


Notação de serviços

Visibilidade Nome do Serviço (Parâmetro): Expressão de Tipo de Retorno {Propriedade}

Visibilidade: Critério de acesso ao serviço Opcional

+ visibilidade pública (default) Serviço pode ser acessado por todos, inclusive por serviços de outras classes

# visibilidade protegida Serviço é acessado apenas pelos serviços da própria classe ou por serviços de classes

dentro de um mesmo pacote

- visibilidade privada Serviço é acessado por operações da própria classe

29




Visibilidade:

Aluno

NomeEndereçoCréditos

+ InformarNome( ):string# InformarEndereço( ):string- CancelarCréditos( códigoCadeira )

30




Nome do serviço Obrigatório!!!! Necessidade de padronização Clareza de significado Evitar abreviaturas

Aluno


+ InformarNome( ):string# InformarEndereço( ):string- CancelarCréditos( códigoCadeira )

31


Notação de Serviços


Parâmetros Lista de valores utilizados pelo serviço

Aluno


+ InformarNome( ):string# InformarEndereço( ):string-CancelarCréditos( códigoCadeira )-AtualizarCréditos( códigoCadeira, ano, número de Créditos )

32




Expressão de tipo de retorno Tipo do valor de retonor do serviço

Aluno


+ InformarNome( ):string# InformarEndereço( ):string-CancelarCréditos( códigoCadeira )-AtualizarCréditos( códigoCadeira, ano, número de Créditos )

33




Propriedade Opcional Maior detalhamento do serviço

Classificação Construtor:

incializam/constroem instâncias da classe

Destrutor: destróem instâncias da classe

Modificador de atributos: modificam valores de atributos

Seletor de atributos: utilizam mas não modificam valores de atributos

Prés e pós condições Exceções Propriedades dependentes da

linguagem de programação

Aluno


+ CriarAluno( nome ) { construtor }+ InformarNome( ):string# InformarEndereço( ):string-CancelarCréditos( códigoCadeira ) { modificador }-AtualizarCréditos( códigoCadeira, ano, número de Créditos )

34


Persistência Objetos Persistentes – armazenado no banco de dados Objetos transientes – em memória

Construtores e Destrutores Coleta automática de lixo

Serviços para acesso a atributos


35

Identificação de Relacionamentos

Objetivo Identificar associações, agregações e relacionamentos de

generalização/ especialização (herança) entre classes

O que considerar? Necessidade do sistema em “lembrar” relacionamentos entre

as classes

O que procurar? Todos os relacionamentos entre instâncias de classes que

sejam relevantes para o sistema

36


Associação Relacionamentos simples entre instâncias de classes

Descrevem algum vínculo, relacionamento ou interdependência entre instâncias de classes

37


Associação - Representação Unária

Binária

Pessoa

Aluno

É pai de

0..*

1..2

Cadeira0..* Cursa

0..*

38


Associação - Representação N-ária

Avaliação

Funcionário Quesito

* *

Projeto

*

39


Agregação

Relacionamentos com uma semântica bem definida: a de composição

Relacionamentos que representem: montagens e suas partes

Ex. Um carro e suas partes

(motor, chassi, rodas …) recipientes e seus conteúdos

Ex. Vôo e passageiros conjuntos e seus membros

Ex. Turma e alunos

40


Agregação - notação

EmpresaDepartamento

“Todo”“Parte”

1..*

1

41


Herança O que procurar?

Diferenças e similaridades entre classes Várias classes com características comuns

Notação Veículo

Ano Cor

Carro Ônibus Caminhão

Ano Cor No de Assentos

Ano Cor Capacidade

Ano Cor No de Portas

42

Generalização / Especialização

O que procurar? (cont.) Uma classe com atributos aplicáveis apenas a subconjuntos de suas

instâncias

Funcionário

NomeNascSalárioProjeto

Funcionário_Maria Nome = ‘Maria’ Nasc = ‘16/02/70’ Salário = 2500

Projeto = ‘’

Funcionário_João Nome = ‘João’ Nasc = ‘10/05/65’ Salário = 3000

Projeto = ‘Call Center’Gerente

Projeto

43


Nome/Semântica do relacionamento

Multiplicidade 1 somente um * muitos (zero ou mais) 0..* muitos (zero ou mais) 0..1 opcional (zero ou um) 1..* maior ou igual a um M..N sequência específica

Ex. 1..27 (de um a 27), 23..* (acima de 23)

Papéis Navegabilidade Restrições


44

Diagramas de Estado

Objetos de uma classe possuem um “ciclo de vida” São gerados Assumem posições (estados) Dão origem a outros objetos Deixam de existir (são destruídos)

O estudo dos diferentes estados de um objeto de uma classe e das transições entre estes estados permite o levantamento de serviços adicionais a serem incorporados na classe

45

Diagramas de Estado

Notação

Estado: condição ou situação durante a vida de um objeto no qual

satisfaz alguma condição, executa alguma atividade em resposta a um evento ou espera pela ocorrência de algum evento.

<nome do estado>

Início

Fim

46

Diagramas de Estado

Notação

Evento: Ocorrência que deve ser reconhecida e gerar uma reação pelo

sistema em estudo. A ocorrência de um evento provoca a transição entre estados de

instâncias de alguma classe pertencente ao sistema

Estado 1

Estado 2

evento

47

Diagramas de Estado

Exemplo – Classe PedidoDeCompra

Pedido Registrado

Envio de pedido

Pedido cancelado

Pedido em Análise

Requisição de análise de

pedido

Pedido Pendente

Pedido não pode ser atendido neste

momento Pedido já pode ser atendido

Pedido Aprovado

Pedido é aprovado

Pedido cancelado

Pedido cancelado

Pedido cancelado

Pedido Atendido

Atendimento a Pedido


48

Diagramas de Sequência

Objetivo Identificar o envio de mensagens entre os objetos das

diversas classes do diagrama em resposta a cada caso de uso

Um diagrama de sequência mostra interações de objetos organizadas em uma sequência de tempo e de mensagens trocadas

49

Diagrama de Sequência

um objeto

outro objeto

Tempo(top-down)

ativação

Linha de vida

criar

mensagem

retorno

excluir

Símbolo de exclusão

ator

(evento)

50

Diagrama de Sequência

Vendedor

Janela Pedido Nota Fiscal Fatura Cliente

1: situação financeira do cliente 2: obter pedidos

(cliente)

3: obter notas fiscais (pedido)

4: obter faturas vencidas (nota fiscal)

5: obter faturas a vencer (nota fiscal)

6: obter limite de crédito (cliente)


51

Diagramas de Colaboração

Detalhamento da comunicação entre objetos para cumprir as tarefas solicitadas nos casos de uso.

Construção dos Diagramas de Colaboração da UML Descrevem os “algoritmos” ou operações a serem codificados na

fase seguinte de implementação

:POSTentrarItem(upc,qtd)

:Venda

1:[new venda] criar()3: criar ItemdeLinha(espec, qtd)

2: espec:=especificação (upc)

:Catálogode Produtos

:EspecificaçãodeProduto

2.1: espec:=enontrar (upc)

:LinhadeItemdeVenda

1.1: criar()

3.2: adicionar(lv)

:LinhadeItemdeVenda

3.1: criar(espec, qtd)

Documents

Renata Araujo UNIRIO Projeto e Construção de Aplicações com Ambientes de Programação 2002.1 Unified Modeling Language