Post on 07-Aug-2020
Linguagem de Modelagem Unificada
Rosemary Silveira Filgueiras Melo
rosesfmelo@hotmail.com
1
UML
Parte 1
Tópicos abordados
Paradigma Orientado a Objetos
Linguagem UML e seus principais diagramas
Diagramas de Casos de Uso
Diagramas de Classes
2
Contextualização
Sistemas de Informação cada vez mais complexo
Necessidade de planejamento e organização prévio para
desenvolver sistemas de informação
O uso da modelagem de Sistemas permite pensar, planejar e
organizar as soluções antes de implementar o software
A modelagem de sistemas está intimamente relacionada ao
paradigma de desenvolvimento e ao processo de
desenvolvimento em uso.
3
Contextualização - continuação
O foco do desenvolvimento de sistema sob o paradigma
orientado objetos está voltada para identificação e a
modelagem dos objetos do mundo real que afetam o
sistema.
A linguagem UML é mundialmente aceita para
modelagem de sistemas baseado no Paradigma
Orientado a Objetos.
4
Paradigma Orientado a Objetos
5
Objeto
Classe
Encapsulamento
Herança
Polimorfismo
Visibilidade
Princípios Fundamentais
• Representa as “coisas” a serem modeladas do mundo
real.
• Pode ser algo concreto ou abstrato
Concreto -> Ex.: aluno, professor, etc
Abstrato -> Ex.: turma, disciplina, etc
Objetos
Objetos
Objetos tem um estado (atributos)
Objetos possuem um comportamento (métodos)
Objetos possuem uma identidade
Objetos
Classes
Abstração da realidade na qual representamos algo do
mundo real.
Descrição de um conjunto de objetos que
compartilham os mesmos atributos, operações,
relacionamentos e semântica.
Objetos x Classes
Objeto é uma instância de uma classe
Classe é o Molde Objeto é a coisa real
CONJUNTO DE PESSOAS
• capacidade de ocultar dados de acesso indevido de
outros objetos.
• só permite que estes dados sejam acessados por
operações implementadas pelos seus próprios
métodos.
• protege os dados do objeto do uso arbitrário ou não
intencional.
• usuários tem conhecimento das operações que
podem ser requisitadas e o que elas realizam
• não é necessário saber como foram implementadas.
Encapsulamento
Interação entre objetos sem conhecimento dofuncionamento interno.
Encapsulamento
• Mecanismo usado para derivar novas classes a partir dadefinição de classes existentes.
• Uma classe derivada herda os atributos (dados) emétodos (operações) da classe base ou ancestral.
• Garante reutilização de código propiciando economiade tempo, dinheiro e mais segurança.
Herança
Herança
• Palavra derivada do grego, significa ”muitas formas”.
• Possibilidade de ter método com mesmo nome emclasses distintas com comportamentos diferente.
• Se uma classe herda atributos e métodos de uma oumais classe base ela tem o poder de alterar ocomportamento destes métodos.
Polimorfismo
Polimorfismo
• Define o que uma classe pode visualizar de outra classe.
• A visibilidade envolve a possibilidade de visualização tantode atributo, como de método.
• Tipos de Visibilidade:
- Pública: atributos e métodos podem ser visível a todasas classes.
- Privada: atributos e métodos só podem ser visível pelaprópria classe.
- Protegida: atributos e métodos visível somente pelasclasses descendentes.
Visibilidade
• o atributo Valor e método Pagar_conta da classe Pagamentosomente podem ser vistas pelas classes filhas ou subclasses destaclasse.
Visibilidade
Linguagem UML e seus principais diagramas
20
UML - Unified Modeling Language.
Desenvolvida pela Rational Software
Rumbaugh
Booch
Jacobson
Reconhecida pela OMG – Object Management Group em
1997.
UML
Booch – Grady Booch
OMT – James Rumbaugh / General Eletric
OOSE – Ivar Jacobson / Ericsson
UML – Rational Software / OMG
Origem da UML
23
Outros
Métodos
Booch’91 OMT-1 OOSE
UML reconhecida pela OMG
e com feedback do público.Nov/97
Set/97
Jan/97
Out/96
Jun/96
Out/95
Jan/91 Framentação
Unificação
Padronização
Industrialização
Booch’93 OMT-3
Unified Method 0.8
UML 0.9 & 0.91
UML 1.0
Parceiros
Da UML
UML 1.1
23
UML – Histórico
24
UML não é uma Metodologia
UML é uma Linguagem de Modelagem:Não proprietária e aberta
Independente da linguagem de programação
Independente do processo de desenvolvimento
Predominantemente visual e de fácil leitura
Apropriada para uso de conceitos OO
Abrange desde a modelagem conceitual até a implementação física
Composta por diagramas 24
UML - Características
2525
UML - Diagramas
26
Através da UML é possível:
Explicitar as fronteiras do sistema e suas principaisfuncionalidades (casos de uso e atores)
Ilustrar a realização dos casos de usos (diagramas deinteração)
Representar as estruturas estáticas do sistema(diagramas de classes)
26
UML – Expressividade
27
Além disso...
Modelar o comportamento dos objetos (diagramas detransição de estados)
Mostrar a arquitetura física da implementação(diagramas de componentes)
Capturar a topologia de hardware do sistema (diagramade implantação)
27
UML – Expressividade
Diagrama de
Casos de Uso
28
29
Apresenta uma visão das principais funções ou serviços oferecidas
pelo sistema
Considerado o mais abstrato e informal.
Utilizado principalmente nas etapas de Levantamento de requisitos e
Análise
Ajuda na identificação dos requisitos do sistema
Ferramenta para troca de informações entre clientes e equipe de desenvolvimento
Fornece a base para o planejamento dos testes29
Diagrama de Casos de Uso
30
Visa identificar:
o Os usuários que irão interagir com o sistema
o Os papéis que eles irão assumir
o As funcionalidades que serão requisitadas por cada
usuário específico.
30
Diagrama de Casos de Uso
31
Principais elementos do diagrama de Casos de Uso:
31
Diagrama de Casos de Uso
3232
Diagrama de Casos de Uso - Representação
Sistema Bancário
Realizar saque
Realizar depósito
Cliente
Ator Casos de uso
Associação
33
Agente externo que interage com o sistema
Comunica-se com o sistema enviando e recebendomensagens
Pode representar: pessoas, papéis, um hardware especial, outros sistemas, outros órgãos,etc...
Exemplo de Atores:
33
Diagrama de Casos de Uso - Atores
Gerente Funcionário Cliente
Caixa EletrônicoSistema de Contas
a Pagar e Receber
34
Tipos de atores:
principal: interessado nos resultados produzidospelo sistema (quem solicita o serviço), mas nãonecessariamente interage com o sistema.
Ex.: cliente
secundário: interage com o sistema e que não tem interesse em seus resultados.
ex.: funcionário contratado para atender os clientes
34
Diagrama de Casos de Uso - Atores
35
Referem-se aos serviços, tarefas ou funções que podem serutilizados de alguma maneira pelos usuários do sistema.
Utilizados para expressar e documentar oscomportamentos pretendidos para as funções do sistema.
35
Diagrama de Casos de Uso – Casos de Uso
Obter extrato de conta
Abrir conta
Casos de uso
36
Diagrama de Casos de Uso – Relacionamentos
O diagrama de Casos de Uso possibilita o
relacionamento entre:
o Atores e Casos de Uso
o Atores
o Casos de Uso
36
37
Diagrama de Casos de Uso – Relacionamentos
Tipos de relacionamento:
o Comunicação
Entre Ator e Caso de Uso
o Generalização/Especialização
Entre Atores
Entre Casos de Uso
o Inclusão
Entre Casos de Uso
o Extensão
Entre Casos de Uso
37
38
Diagrama de Casos de Uso – Relacionamentos
38
Relacionamento entre Ator e Casos de Uso
3939
Diagrama de Casos de Uso – Relacionamentos
Sistema de Matrícula
Emitir Comprovante de matrícula
Efetuar matrícula
Cliente
Ator Casos de uso
Relacionamento entre Ator e Casos de Uso
Só é permitido o relacionamento tipo Comunicação
Pode ser navegável:
em uma direção
em duas direções
40
Diagrama de Casos de Uso – Relacionamentos
40
Relacionamento entre Atores
41
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Atores - tipo Generalização
Só é permitido o relacionamento tipo Generalização
usada para representar a relação entre atores que realizaçãotarefas comuns, com pequenas diferenças entre si.
Ocorre a sobreposição de papéis no Ator que atua comoEspecialização.
41
42
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Atores – tipo Generalização
42
43
Diagrama de Casos de Uso – Relacionamentos
43
Relacionamento entre Casos de Uso
44
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Generalização
usada para representar a relação entre dois ou mais Casos de
Uso com características semelhantes, com algumas diferenças
entre si.
Pode ocorrer sobreposição de funcionalidade
44
45
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Generalização
45
46
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Inclusão
Utilizado quando existe um serviço comum a mais de um Casode Uso.
Deve ser colocado em um caso de uso específico para queoutros Casos de Uso utilizem-se desse serviço
A relação de inclusão implica em obrigatoriedade de execução
46
47
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Inclusão
47
48
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Extensão
Utilizado para descrever cenários opcionais de um Caso de Uso
Indica a necessidade de testar uma condição para determinarse é necessário executar o caso de uso estendido ou não.
Representam eventos que não ocorrem sempre, o que nãosignifica que eles sejam incomum
48
49
Diagrama de Casos de Uso – Relacionamentos
Relacionamento entre Casos de Uso – Tipo Extensão
49
50
Diagrama de Casos de Uso - Exemplo
50
51
Diagrama de Casos de Uso – Outro Exemplo
51
Documento de Especificação de Casos de Uso
Documento com a descrição textual de como ocorre a interação entre atores e sistema na realização de um caso de uso
Nele é possível :Indicar COMO e QUANDO o caso de uso se inicia e termina
quando o caso de uso interage com atores
quais objetos são transferidos
fluxo básico e alternativos do comportamento
Modelo de Documentação de Casos de Uso
Descrição detalhadaNomeDescrição sucintaAtoresPré-Condições Pós-Condições Fluxo Básico Fluxos Alternativo Fluxos de Exceção Estrutura de dados Regras de negócio Observações
Documentação de Casos de Uso
Fluxo Alternativo Alternativa ao fluxo principal
Fluxo de Exceção Possível consequência de uma alternativa escolhida previamente ou de um erro.
Regras de NegócioModo como realiza o negócio.
Diagrama de
Classes
55
56
Considerado o diagrama mais importante e utilizado da UML.
Enfoque na visualização das classes pertencentes ao sistema e
nas relações entre estas classes.
Fornece uma visão de como as classes pertencentes a um
sistema estão organizadas (visão estática do sistema).
Pode ser representado em vários níveis diferentes: nível
conceitual ou de domínio e nível de projeto.
Serve como base para a construção da maioria dos outros
diagramas da UML.56
Diagrama de Classes
5757
Diagrama de Classes
Exemplo de diagrama de classes representando um Sistema de Vendas
58
conjunto de objetos com propriedades comuns (atributos,
operações e relacionamentos).
representa os estados e comportamentos que os objetos podem
assumir:
o estado corresponde os atributos
o comportamento corresponde as operações
As classes podem ser usadas para representar: software,
hardware ou puramente itens conceituais.
58
Classes
5959
Representação básica
A classe é representada graficamente com um retângulo
contendo nome, atributos e operações.
A apresentação dos atributos e operações pode variar conforme
as necessidades e objetivos.
Nome
Atributos
Operações
6060
Nomes de Classes
Cada classe deve ter um nome único;
Classes em pacotes diferentes podem ter o mesmo nome;
Procure usar substantivos;
A primeira letra de cada palavra deve ser maiúscula.
Exemplos: Produto
Cliente
ItemPedido
6161
Atributos da Classe
Representam o estado das instâncias da classe
São valores que a classe e ou instâncias (objetos)
contém
Uma classe pode conter nenhum ou vários atributos;
6262
Operações da Classe
implementação de um serviço que pode modificar o
comportamento do objeto
pode ter nenhuma ou várias operações
Os nomes das operações inicia-se com verbos
Mesmo que não tenha parâmetros, finalizar com
parênteses “()”
6363
Operações da Classe
Sua assinatura é composta pelo seu nome, quantidade
de parâmetros e pelos tipos dos parâmetros
Iniciado em minúsculo, demais palavras com inicial
maiúsculo.
Exemplos:
apresentarCliente()
incluirNotaFiscal()
consultarPedido()
64
As marcações de acesso servem para especificar o tipo de
acesso permitido aos atributos e operações:
+ publico: visível a todos os classificadores
# protegido: visível ao próprio classificador e seus
descendentes
- privado: visível apenas ao próprio classificador
64
Visibilidade
65
vínculo que ocorre entre as classes com o intuito de
compartilhar informações e colaborarem umas com as outras
para executar tarefas.
Tipos de relacionamentos em diagramas de classes:
oAssociação
oGeneralização
oDependência
65
Relacionamentos
66
descreve o vínculo que ocorre entre as classes
Tipos de Associação:
o associação unária ou reflexiva (entre uma classe)
o associação binária (entre duas classes)
o associação ternária ou N-ária (entre três ou váriasclasses)
66
Associação
67
determina que as instâncias de uma classe estão de alguma formaligadas às instâncias das outras classes envolvidas na associação
pode haver troca de informações entre as classes e ocompartilhamento de métodos.
Nas extremidades da assoicação deve conter:
oOs papéis das classes naquela associação
oA multiplicidade
oA navegabilidade da associação.67
Associação
6868
Exemplo – Associação com Papel
Neste exemplo a classe estudante assume dois papéis
diferentes.
69
Define o limite de vezes que as instâncias de uma classe devemse relacionar com as instâncias de outra classe
Tipos de cardinalidade:
0..1 - Cardinalidade pode ser 0 ou 1
1 - Cardinalidade só pode ser 1
0..* - Cardinalidade pode variar de 0 até infinito
* - Cardinalidade pode variar de 0 até infinito
1..* - Cardinalidade pode variar de 1 até infinito
1..6 - Cardinalidade pode variar de 1 até 6
69
Multiplicidade
70
Quando não for definida a multiplicidade na extremidade darelação considera que a multiplicidade é 1.
70
Exemplo - Associação com Multiplicidade
71
Representada por uma seta na extremidade da linha que indica orelacionamento entre duas classes.
Expressa o sentido em que as informações são transmitidas entreas classes envolvidas.
Indica também as classes que cada classe pode enviarmensagem.
71
Navegabilidade
72
Associação Unidirecional (com navegabilidade em uma únicadireção)
o indica que só uma classe está ciente da relação
o as informações trafegam em uma única direação.
Associação Bidirecional (com navegabilidade nas duasdireçãoes ou sem navegabilidade)
o todas as classes estão ciente da relação
o as informações podem trafegar em todas as direções entre asclasses da associação
Por padrão as associações são bidirecional.
72
Navegabilidade
7373
Exemplo – Associação com Navegabilidade
A empresa sabe quais são seus funcionários, mas o funcionárionão sabe a que empresa pertence.
public class Empresa {
private string NomEmpresa;
public funcionario empregado[];
}
public class Funcionário {
private long Codigo;
private char Nome;
private long codChefe;
}
74
As associações podem ser modeladas da seguinte forma:
Associação Unária ou Reflexiva
Associação Binária
Classe de Associação (Classe Associativa)
Agregação
Composição
74
Associação
75
Uma mesma classe pode se relacionar com ela própria através deuma associação.
75
Associação Unária ou Reflexiva
76
Ocorre quando são identificados relacionamentos entre duasduas classes.
Constitui-se o tipo de relacionamento mais comum encontradonos diagramas de classe.
76
Associação Binária
77
Classes produzidas quando da ocorrência de associações quepossuem multiplicidade muitos (*) em todas as suasextremidades.
Necessárias para armazenar as informações produzidas pelaassociação, além dos atributos próprios da relação.
Válidas somente quando existe um único objeto associado a
duas instâncias associadas.
77
Classe de Associação (Classe Associativa)
78
.
78
Classe Associativa - Exemplo
Podem ser substitídas por classes normais só que permite vários objetosrelacionados a duas instâncias associadas.
No caso acima, um ator pode atuar no mesmo filme com vários papéisdiferentes.
.
79
Tipo especial de associação usado para modelar
relacionamentos do tipo todo-parte.
Usado para indicar que as informações de um objeto (objeto-
todo) precisam ser completadas pelas informações contidas em
um ou mais objetos de outra classe (objeto-parte).
Os objetos-parte podem ser compartilhados por mais de um
objeto-todo.
Indica obrigatoriedade de complementação das informações de
um objeto-todo por seus objeto-parte.
79
Agregação
8080
Agregação - Exemplos
Indica que sempre que uma pessoa for consultada, além de suas
informações serão apresentadas todas as contas referentes a esta
pessoa .
81
Constitui-se em uma variação da associação de agregação.
Representa um vínculo mais forte entre os objetos-todo e os
objetos-parte.
Demonstra que os objetos-parte tem de pertencer
exclusivamente a um único objeto-todo com que se relacionam
Em uma composição os objeto-parte não podem ser destruídos
por um objeto diferente do objeto-todo ao qual estão
relacionados.
81
Composição
8282
Composição - Exemplo
8383
Composição - Exemplo
84
Relacionamento utilizado para a modelar Herança
Herança é a habilidade de uma classe (classe filha) deherdar as propriedades de outra classe (classe pai), podendopossuir atributos e métodos próprios.
84
Generalização / Especialização
8585
Generalização / Especialização
86
Expressa um certo grau de dependência de uma classe com relação a
outra.
Implica que sempre que ocorrer uma alteração na classe da qual
uma outra depende, esta deverá também sofrer uma alteração.
Não costuma ser encontrado com muita frequência nos diagramas
de classes.
Deve-se modelar dependência apenas quando for relevante para o
contexto da aplicação.
86
Relacionamento de Dependência
8787
Dependência - Exemplo
O método Incluir da classe Disciplina usa o objeto Aluno como
parâmetro da classe Estudante
Qualquer mudança na classe Estudante poderá afetar a classe
Disciplina
8888
Representação de Restrição
Informações extras que definem condições a serem validadas
durante a implementação dos relacionamentos entres as classes.
Em geral, são representadas nos diagramas de classes por
textos limitados por chaves.
8989
Representação de Restrição - Exemplo
9090
Representação de Restrição - Exemplo
Indica que uma conta corrente pode tanto ser possuída por uma
pessoa física como uma pessoa jurídica, mas uma determinada
conta só pode pertencer a uma única pessoa.
9191
Representação de Restrição para classes especializadas
.
Indica que se uma pessoa for física, ela não pode ser jurídica e
vice-versa.
9292
Representação de Restrição para classes especializadas
.
Indica que um veículo pode ser tanto aéreo como aquático,
como é o caso de um hidro-avião.
9393
Visão Geral – Diagrama de Classes e seus elementos