Linguagem de Modelagem Unificada UML - Webnode.com.br...Encapsulamento Herança Polimorfismo...

Linguagem de Modelagem Unificada

Rosemary Silveira Filgueiras Melo

[email protected]

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


31

Principais elementos do diagrama de Casos de Uso:

31


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


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


38

Relacionamento entre Ator e Casos de Uso

3939


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


40

Relacionamento entre Atores

41


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


Relacionamento entre Atores – tipo Generalização

42

43


43

Relacionamento entre Casos de Uso

44


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


Relacionamento entre Casos de Uso – Tipo Generalização

45

46


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


Relacionamento entre Casos de Uso – Tipo Inclusão

47

48


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


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

Linguagem de Modelagem Unificada UML - Webnode.com.br...Encapsulamento Herança Polimorfismo...

Documents

Transcript of Linguagem de Modelagem Unificada UML - Webnode.com.br...Encapsulamento Herança Polimorfismo...