Modelagem de Objetos Com UML

Modelagem de Objetos com UML – 1

Universidade Federal do Pará

Centro de Ciências Exatas e Naturais

Departamento de Informática

Modelagem de Objetos com UML

Prof. Rodrigo Quites Reis, M.Sc.

http://sites.uol.com.br/quites

Junho, 2000


Modelagem de Objetos com UML Autoria: Rodrigo Quites Reis

Última atualização: Maio/2000

Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma, seja mecânico ou eletrônico, fotocópia, gravação, ou outros, sem autorização, prévia, expressa e específica do Autor.

UNIVERSIDADE FEDERAL DO PARÁ

Centro de Ciências Exatas e Naturais

Departamento de Informática – http://www.ccen.ufpa.br

Fone: (91) 211-1409


SUMÁRIO

1 INTRODUÇÃO .................................................................................................................4

2 MODELO DE OBJETOS EM UML ...............................................................................5 2.1 Classes e seus relacionamentos.....................................................................................5 2.2 Tipos de Associações entre classes...............................................................................6 2.3 Multiplicidade (Cardinalidade) .....................................................................................7 2.4 Classes Associativas .....................................................................................................8 2.5 Qualificador ................................................................................................................10 2.6 Agregação ...................................................................................................................11

2.6.1 Agregação Compartilhada......................................................................................................... 12 2.7 Navegabilidade ...........................................................................................................12 2.8 Generalização/Especialização.....................................................................................13

2.8.1 Restrições de Herança ............................................................................................................... 14 2.9 Restrições ....................................................................................................................15 2.10 Interface ....................................................................................................................15 2.11 Resumo da Notação ..................................................................................................16 2.12 Estudo de Caso..........................................................................................................17

3 DIAGRAMAS DE CASOS DE USO (USE CASES) ....................................................19 3.1 Caso de Uso ................................................................................................................20 3.2 Interação em caso de uso ............................................................................................20 3.3 Exemplos de casos de uso...........................................................................................21

3.3.1 Caixa eletrônico [FUR98] ......................................................................................................... 21 3.3.2 Biblioteca [ERI98] .................................................................................................................... 22 3.3.3 Sistema de Vendas [TOG00]..................................................................................................... 23

4 DIAGRAMAS DE INTERAÇÃO..................................................................................24 4.1 Diagrama de Sequência...............................................................................................25 4.2 Diagrama de Colaboração...........................................................................................28

5 DIAGRAMA DE TRANSIÇÃO DE ESTADO.............................................................31 5.1 Elementos do diagrama de estado...............................................................................31

5.1.1 Estado........................................................................................................................................ 32 5.1.2 Eventos...................................................................................................................................... 32 5.1.3 Transições ................................................................................................................................. 33

5.2 Exemplos.....................................................................................................................33

6 ESTUDOS DE CASO E EXERCÍCIOS........................................................................36 6.1 Estudo de Caso 1: Locadora de Veículos....................................................................36 6.2 Estudo de Caso 2: Hospital .........................................................................................36

REFERÊNCIA BIBLIOGRÁFICA......................................................................................37


1 INTRODUÇÃO

O presente texto tem como objetivo apresentar uma visão geral das técnicas de modelagem de sistemas orientados a objetos chamada UML – Unified Modelling Language. Atualmente, UML consiste na principal linguagem para descrição de sistemas O.O., sendo definida como padrão do OMG1 em 1997.

Apesar deste não se propor a substituir qualquer um dos livros clássicos escritos nesta área, o objetivo deste texto é o de complementar as atividades realizadas em sala de aula, proporcionado uma visão geral dos conceitos de modelagem com UML. Além disso, somente os modelos UML mais importantes são apresentados, deixando de lado aqueles que possuem sua aplicação condicionada a sistemas com características específicas.

1 OMG = Object Management Group. Organismo internacional para definição de padrões da orientação a objetos.


2 MODELO DE OBJETOS EM UML

O modelo de objetos em UML é representado através de um diagrama de classes. Um diagrama de classes denota a estrutura estática de um sistema e as classes representam coisas que são manipuladas por esse sistema. A notação utilizada para representar o diagrama de classes em UML é fortemente baseada na notação de Diagramas Entidade-Relacionamento [CHE90] e no Modelo de Objetos de OMT [RUM94]. As seções a seguir apresentam resumidamente a notação utilizada nesta metodologia.

2.1 Classes e seus relacionamentos

Uma classe é representada por um retângulo sólido com três partes: uma para o nome da classe; outra para os atributos da classe; e a terceira para a declaração das operações definidas para a classe. A Figura 1 mostra a notação UML para classes.

Figura 1. Notação para classe em UML

Os tipos principais de relacionamentos entre classes são:

• Generalização/Especialização (Herança): Indica relacionamento entre um elemento mais geral e um elemento mais específico (superclasse e subclasse, respectivamente). A subclasse pode conter somente informação adicional acerca da superclasse. Por exemplo um médico é um funcionário;

• Agregação: Usada para denotar relacionamentos todo/parte. Por exemplo, um item de compra é parte de um pedido;


• Associação: Usada para representar relacionamentos entre as classes (por exemplo, um cliente pode alugar várias fitas de vídeo);

• Dependência: Um relacionamento entre um elemento independente e outro dependente, onde uma mudança no elemento independente afetará o elemento dependente.

2.2 Tipos de Associações entre classes

Uma associação descreve um conjunto de vínculos entre objetos das classes relacionadas. A associação entre duas ou mais classes permite um conjunto de ligações entre os objetos das classes. Os tipos de associação são:

Associação Unária: Relacionamento entre uma classe e ela mesma. Também conhecida como associação recursiva, cujo relacionamento pode conectar dois diferentes objetos de uma mesma classe. A figura a seguir mostra um exemplo de associação unária:

Figura 2. Exemplo de associação unária.

Associação Binária: Relacionamento entre duas classes distintas. A figura a seguir ilustra o exemplo de associação binária:

Figura 3. Exemplo de Associação binária.

Associação n-ária: Associação entre três ou mais classes. Neste caso a notação inclui um losango para representar a associação, como mostra a figura a seguir:

Funcionário 1

* supervisiona

Funcionário Departamento 0..* trabalha 4 1


Figura 4. Representação de associação ternária.

2.3 Multiplicidade (Cardinalidade)

A cardinalidade das associações em um diagrama de classes é denominada de multiplicidade e especifica quantas instâncias de uma classe podem participar da associação (semelhante à abordagem ER). A tabela 1 a seguir apresenta as multiplicidades.

Tabela 1 – Multiplicidades de associações entre classes.

Multiplicidade Significado

0..1 Zero ou um

1 Somente 1

0..* Maior ou igual a zero

* Maior ou igual a zero

1..* Maior ou igual a 1

1..15 (m..n) De 1 a 15 (m a n), inclusive

A figura a seguir mostra um exemplo de uso de multiplicidade onde a classe


financeira está associada a 0 ou mais vendas da classe venda através da associação financiamento. E a classe venda está associada a no máximo um elemento da classe vendedor através da associação venda (notar que o nome da associação pode ser um substantivo).

Figura 5. Exemplo de uso de multiplicidade.

2.4 Classes Associativas

São classes que representam a associação entre outras classes. Somente ocorrem instâncias da classe associativa quando ocorre a associação entre classes. Comparando com a abordagem Entidades-Relacionamentos (ER), uma classe associativa equivale a uma entidade associativa ou agregação de entidades. Da mesma forma, quando em um diagrama ER existe a necessidade de representar atributos de relacionamentos, em um diagrama de classes cria-se uma classe associativa.

A figura a seguir ilustra um exemplo de classe associativa onde quando ocorre um

casamento entre dois vendedores, então uma classe associativa armazena a data do casamento e o regime.

Figura 6. Exemplo de classe associativa em uma associação unária.


A figura a seguir mostra um exemplo de associação onde é representado que quando ocorre o financiamento de uma venda, são guardadas também as informações do financiamento. Deve-se notar que nem toda venda é financiada, e que a classe associativa também possui métodos.

Figura 7. Exemplo de classe associativa com associação binária.

A figura a seguir ilustra um exemplo de classe associativa em associação n:n. Neste exemplo os itens de venda são representados através de uma classe associativa.

Figura 8. Exemplo de classe associativa n:n.

Uma classe associativa pode ser transformada em uma classe regular conforme


mostra a figura a seguir.

Figura 9. Transformação de uma classe associativa em classe regular.

2.5 Qualificador

Qualificadores ou Associações Qualificadas são usadas com associações 1:N ou N:N. O qualificador distingue (divide) o conjunto de objetos do outro lado da associação. A figura a seguir ilustra um exemplo de qualificador. O modelo informa que um prédio possui vários números de andar. Um número de andar de um prédio está associado a exatamente um andar. Como consequência um andar é identificado pelo seu número e pelo prédio. Este conceito é análogo ao conceito de entidade fraca ou relacionamento identificador em modelos entidade-relacionamento.

Figura 10. Exemplo de uso de qualificador.

Outro exemplo de qualificador é apresentado na figura a seguir, onde um diretório está associado a vários nomes de arquivo, e cada nome de arquivo é associado a um arquivo. Cada arquivo está associado a um nome de arquivo e a um diretório.

Figura 11. Exemplo de qualificador.

Diretório Nome do arquivo Arquivo


2.6 Agregação É um caso especial de associação usado para representar a relação todo/parte entre

classes. Quando o todo é criado, as partes também o são (e quando é eliminado também). As partes não têm existência própria, somente associadas ao todo.

A notação de agregação é apresentada nas figuras a seguir:

Figura 12. Agregação regular ou relacionamento por referência.

Figura 13. Agregação de composição ou relacionamento por valor.

Um exemplo de agregação é apresentado a seguir:

Figura 14. Exemplo de agregação.

Todo Parte

Agregação Regular

Todo Parte

Agregação de composição


Outro exemplo de agregação com notação compacta é apresentado na figura a seguir, mostrando que ao invés de ligar várias linhas a um agregado, basta usar o símbolo de agregação uma única vez:

Figura 15. Agregação de várias classes com notação compacta.

2.6.1 Agregação Compartilhada

É um tipo de agregação onde as partes podem ser de vários “todos”. A figura a seguir mostra um exemplo onde um time é composto de vários membros e uma pessoa pode ser um membro de muitos times.

Figura 16. Exemplo de agregação compartilhada.

2.7 Navegabilidade

Uma instância de uma classe pode navegar a instâncias de outra classe e vice-versa. Navegabilidade é percebida freqüentemente por objetos que mantêm referências de algum tipo entre objetos associados. Uma seta é ligada entre duas classes para indicar o caminho de navegação entre elas. Em termos de implementação isso representaria que o objeto de uma classe conteria um apontador para o objeto da outra classe.

A figura a seguir mostra um exemplo onde as classes Pedido e Cliente possuem uma associação onde o sentido da navegação ocorre de Pedido para Cliente. Isto indica que um

membrosTime Pessoas

* *


pedido tem a responsabilidade de informar a qual cliente pertence, mas um cliente em

particular não precisa indicar quais pedidos possui.

Figura 17. Exemplo de Navegabilidade

2.8 Generalização/Especialização

Generalização/Especialização é um conceito também conhecido pelo nome de Herança. Trata-se de um relacionamento de classificação entre um elemento mais geral e outro mais específico. O elemento mais específico é completamente consistente com o mais geral somando-se informação adicional especializada.

As subclasses herdam atributos, operações e associações da superclasse e agregam atributos e operações particulares ao elemento de especialização a que se referem.

A figura a seguir mostra um exemplo do uso de herança onde Pessoa física e Pessoa jurídica são especializações de Cliente. As entidades especializadas herdam todas as propriedades (atributos, métodos, relacionamentos, generalizações) da entidade genérica.

Figura 18. Exemplo de generalização/especialização.

Pedido Cliente * 1

navegabilidade

fonte alvo


2.8.1 Restrições de Herança

Podem ser usadas restrições predefinidas para indicar condições semânticas entre subclasses. Uma lista de palavras-chaves separada por vírgula é colocada entre chaves próxima ao triângulo da herança ou próximo a uma linha tracejada que cruza a generalização (ver figura abaixo). As palavras-chaves que podem ser usadas são apresentadas na tabela 2.

Figura 19. Uso de restrição na herança.

Tabela 2 – Restrições de herança.

Palavra-chave Semântica

{Sobreposição} Subclasses derivadas de uma superclasse podem ocorrer simultaneamente para uma mesma ocorrência da superclasse

{Disjunção} Subclasses derivadas de uma superclasse podem ocorrer de maneira mutuamente exclusiva para uma mesma ocorrência da superclasse

{Completo} Todas as subclasses foram especificadas. Nenhuma subclasse adicional é esperada

{Incompleto} Algumas subclasses foram especificadas mas a lista está incompleta.


2.9 Restrições

Uma restrição é um relacionamento semântico entre elementos de modelo que especifica condições e proposições que devem ser mantidas como verdadeiras.

Certos tipos de restrições são predefinidas em UML, mas há a possibilidade de definição de restrições por parte do usuário. Por exemplo, a Figura 20 mostra uma associação onde a restrição é definida para limitar a possibilidade de associação entre Pessoa e Cidadãos idosos.

Figura 20. Exemplo de uso de restrição.

Um exemplo de restrição bastante utilizada é a restrição {ou}. Ela indica que em uma associação, uma instância da classe só pode participar uma vez no máximo de uma das associações possíveis (cortadas pela linha tracejada). A figura a seguir ilustra um exemplo onde uma conta corrente pertence a um indivíduo ou a uma organização.

Figura 21. Uso de restrição {ou}

2.10 Interface Uma interface é um especificador para operações externamente visíveis de uma classe

ou componente. Um pacote, componente ou classe que possui uma interface conectada implementa ou suporta a interface através da implementação do comportamento definido na

Cidadãos Idosos

Pessoa

0 1 0 *

{pessoa.idade>60}

Indivíduo

Organização Conta

Corrente

0..*

0..1

0..* 0..1

{ou}


interface. A representação de interface é através de um pequeno círculo conectado a classe que a suporta. A classe que usa a interface implementada por outra classe é conectada através de um relacionamento de dependência conforme mostra a figura seguir.

Figura 22. Representação compacta de interface.

Além da representação compacta, uma interface pode ser representada da mesma forma que uma classe comum, porém como a palavra-chave <<interface>> antes do nome da classe e {abstrato} após o nome. Apenas o compartimento de métodos é preenchido nesta representação em virtude de não existirem atributos em interfaces.

<<interface>> nome da interface

{abstrato}

Método1 {abstrato} Método 2 {abstrato}

... Método N {abstrato}

Figura 23. Representação de interface.

2.11 Resumo da Notação

A figura a seguir mostra um resumo da notação utilizada para modelo de classes em UML. Os elementos da notação são identificados através do uso de um sistema de pedidos como exemplo.

Classe de implementação Nome da interface

Classe cliente

dependência


Figura 24. Resumo da notação UML para modelo de classes.

2.12 Estudo de Caso

A figura a seguir mostra um exemplo inicial do modelo de classes para uma universidade. Sugere-se como exercício a complementação do modelo.


Figura 25. Estudo de caso de Universidade.


3 DIAGRAMAS DE CASOS DE USO (USE CASES)

Os diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário.

A modelagem de caso de uso é uma técnica utilizada para descrever a funcionalidade de um sistema através de atores externos interagindo em casos de uso. Atores representam um papel e iniciam o caso de uso que, por sua vez, deve entregar um valor tangível de retorno ao ator. Atores e casos de uso estão conectados através de associações e podem ter relacionamentos de generalização que descreva o comportamento comum em superclasses herdadas por uma ou mais subclasses especializadas.

A modelagem de casos de uso é utilizada para capturar necessidades de um novo sistema ou acrescentar novas necessidades para criar uma nova versão. Neste sentido, a nova funcionalidade é adicionada ao contexto do modelo de caso de uso através da inserção de novos atores e casos.

Os objetivos principais de um diagrama de caso de uso são:

• Descrever os requisitos funcionais do sistema de maneira uniforme para usuários e desenvolvedores;

• Descrever de forma clara e consistente as responsabilidades a serem cumpridas pelo sistema, formando a base para a fase de projeto;

• Oferecer as possíveis situações do mundo real para a fase de testes do sistema.

Um diagrama de caso de uso é um gráfico de atores, um conjunto de casos incluído por um limite de domínio, comunicação, participação e associações entre atores, assim como generalizações entre casos de uso. Os elementos básicos de um diagrama de caso de uso são: ator, caso de uso, interação e sistema, todos ilustrados na figura a seguir.

Figura 26. Componentes de um diagrama de caso de uso.


3.1 Caso de Uso

Cada caso de uso especifica um serviço que a classe fornece a seus usuários. São especificadas uma sequência completa iniciada por um usuário, as interações entre os usuários e as classes, bem como as respostas executadas pela classe. Um caso de uso também inclui possíveis variantes dessa sequência, como por exemplo sequências alternativas, comportamento excepcional, manipulação de erro, etc. O conjunto completo de casos de uso exibe todos os modos diferentes para utilizar a classe, o que significa que todo o comportamento da classe é expresso pelos seus casos de uso.

Cada caso de uso é uma sequência completa de cenários de interação mostrando como eventos externos iniciais são respondidos no caso. Um cenário é uma narrativa de uma parte do comportamento global do sistema e uma coleção completa de cenários é usada para especificar completamente um sistema. Um caso de uso está para um cenário assim como uma classe está para um objeto. Ou seja, um caso de uso representa uma declaração de um aspecto de comportamento que é caracterizado por um lote de cenários concretos.

Um ator é uma entidade externa ao sistema que de alguma forma participa de um caso de uso. Um ator estimula o sistema com eventos externos e tipicamente recebe algo do sistema. Um ator pode ser um ser humano, máquinas, dispositivos ou outros sistemas. Atores típicos são cliente, usuário, gerente, computador, impressora, etc.

3.2 Interação em caso de uso

O ator comunica-se com o sistema através do envio e recebimento de mensagens, sendo que um caso de uso é sempre iniciado a partir do momento em que o ator envia sua mensagem (estímulo). Projeta-se o fluxo de controle entre objetos de forma que as operações formais sejam invocadas nos momentos apropriados dentro da realização do caso de uso. Para isso é mostrado o sistema em diagramas de interação, mas também em diagramas de estado para as classes constituintes. As seguintes interações são importantes dentro de um diagrama de caso de uso:

• Comunicação: Um ator comunica-se com o caso de uso;

• Extensão: É usada para mostrar comportamento de exceção e casos especiais que aumentariam a quantidade de casos de uso no modelo. Trata-se de um relacionamento de um caso de uso para outro, especificando como o comportamento definido para o primeiro caso pode ser inserido no comportamento definido para o segundo. Um relacionamento de extensão do caso de uso A para o caso de uso B indica que uma instância de B pode incluir o comportamento especificado por A.

• Uso: Quando um número de casos de uso tem comportamento comum, esse comportamento pode ser modelado em um simples caso de uso que é utilizado


por outros casos. Um relacionamento de uso entre casos ocorre quando há uma parcela de comportamento similar entre eles sugerindo uma reutilização em vez de nova cópia da descrição do comportamento. É desenhado como uma seta de generalização do caso de uso que faz o uso ao caso de uso que é usado, etiquetada com <<usa>>. Um relacionamento de uso do caso de uso A para o caso de uso B indica que uma instância do caso de uso A também incluirá o comportamento como especificado por B

Na figura a seguir, “Requisitar catálogo de pedido” estende “Colocar pedido” e “Colocar Pedido” usa “Pedir Produto”.

Figura 27. Relacionamentos em caso de uso [FUR 98].

3.3 Exemplos de casos de uso 3.3.1 Caixa eletrônico [FUR98]

Colocar pedido Requisitar

catálogo do pedido

Pedir Produto

<<usa>>

<<estende>>


3.3.2 Biblioteca [ERI98]


3.3.3 Sistema de Vendas [TOG00]

Figura 28. Caso de uso de Sistema de vendas.


4 DIAGRAMAS DE INTERAÇÃO

Diagrama de Interação é um termo genérico que se aplica a vários tipos de diagramas que enfatizam interações de objetos. Uma interação é uma especificação comportamental que inclui uma sequência de trocas de mensagens entre um conjunto de objetos dentro de um contexto para realizar um proposito específico, tal como a realização de um caso de uso. As mensagens podem incluir sinais e chamadas implícitas decorrentes de condições e eventos de tempo.

Para especificar uma interação, é necessário definir um contexto de caso de uso e estabelecer os objetos que interagem e seus relacionamentos. Portanto, diagramas de interação são aplicados para mostrar a realização de casos de uso e as possíveis sequências de interação entre objetos.

O diagrama de interação deve ser usado quando se deseja visualizar o comportamento de vários objetos dentro de um único caso de uso, a partir de mensagens passadas entre eles. Para se compreender o comportamento de um único objeto para muitos casos de uso, é melhor empregar um diagrama de estado; para se analisar o comportamento de muitos casos de uso é recomendado o diagrama de atividade. Os diagramas de interação são apresentados de duas formas (equivalentes) em UML:

• Diagrama de Sequência: Enfatiza o comportamento dos objetos em um sistema incluindo suas operações, interações, colaborações e histórias de estado em sequência temporal de mensagem e representação explícita de ativação de operações. Os objetos são desenhados como linhas verticais, as mensagens como linhas horizontais e a sequência de mensagens é lida de cima para baixo;

• Diagrama de Colaboração: Mostra o contexto completo de uma interação, inclusive os objetos e seus relacionamentos pertinentes a uma interação particular, sendo frequentemente melhores para propósitos de projeto.

A figura a seguir mostra um exemplo de um diagrama de sequência (enfatizando a ordem de chamamento) e um diagrama de colaboração (enfatizando a interação entre os objetos).


Figura 29. Diagramas de Sequência e Colaboração.

4.1 Diagrama de Sequência

Um diagrama de sequência mostra interações de objetos organizadas em uma sequência de tempo e de mensagens trocadas, mas não trata associações entre os objetos como os diagramas de colaboração.

A Figura 30 apresenta a notação utilizada para diagrama de sequência onde são mostrados os seus elementos básicos.


Figura 30 Elementos de um diagrama de sequência UML [FUR98]

Um exemplo de diagrama de sequência para o empréstimo de um livro em um sistema de bibliotecas é apresentado na figura a seguir. Neste exemplo, o bibliotecário acessa a janela de empréstimo que enviará mensagem para encontrar o título. Encontrado o título, busca-se a disponibilidade do item, identifica-se o usuário e faz-se o empréstimo. Outro exemplo de diagrama de sequência é mostrado na Figura 32, retratando o processo de venda.


Figura 31. Exemplo de diagrama de sequência para biblioteca [FUR 98].

Figura 32. Exemplo de diagrama de sequência para um sistema de vendas.


4.2 Diagrama de Colaboração

Um diagrama de colaboração mostra uma interação organizada em torno de objetos e seus vínculos formando uma base de padrões.

Diagrama de sequência e diagrama de colaboração expressam informação semelhante mas a apresentam de forma diferente. O primeiro exibe uma sequência explícita de mensagens e é melhor para especificações de tempo real (dimensão tempo) e para cenários complexos, enquanto o segundo mostra os vínculos entre objetos e é melhor para entender os efeitos em um determinado objeto (dimensão espaço). Para decidir qual diagrama deve ser utilizado para estudar uma interação, uma regra geral é escolher o diagrama de colaboração quando o objeto e seus vínculos facilitam a compreensão da interação, e escolher o diagrama de sequência somente se a sequência necessita ser evidenciada.

Ao contrário de um diagrama de sequência, um diagrama de colaboração mostra os relacionamentos entre os objetos, mas não trata o tempo como uma dimensão separada. A sequência de tempo é indicada numerando-se as mensagens. Em um diagrama de colaboração as classes e objetos são representados como mostra a figura a seguir.

Figura 33. Elementos de um diagrama de colaboração.

A Figura 34 mostra a chamada de métodos em um diagrama de colaboração e a Figura 35 mostra algumas convenções utilizadas quando um método é chamado. A Figura 36 mostra o uso de parâmetros de métodos no diagrama de colaboração, onde é possível chamar


um método com argumentos declarando a variável e o tipo de retorno.

Figura 34. Notação UML para diagramas de colaboração.

Figura 35. Convenções do diagrama de colaboração.


Figura 36. Parâmetros de métodos em diagramas de colaboração.


5 DIAGRAMA DE TRANSIÇÃO DE ESTADO

Diagramas de estado foram introduzidos por D. Harel e têm sido utilizados na orientação a objetos para prover uma definição formal explícita de comportamento. A modelagem da transição de estados de um sistema permite uma verificação dos eventos e transições de estados aos quais um sistema está sujeito.

A UML propõe o emprego de diagrama de estado de maneira individualizada para cada classe, com o objetivo de tornar o estudo simples o bastante para se ter um diagrama de estado compreensível. Modelos de estado são ideais para descrever o comportamento de um único objeto, mas não para descrever adequadamente o comportamento que envolve vários objetos (para isso é melhor usar um diagrama de interação ou atividade). A semântica e a notação da UML para diagramas de estado são as mesmas das máquinas de estado finitas de Harel com as seguintes modificações secundárias:

• Guardas em transições

• Transições propagadas

• Ações em transições

• Ações em estado inicial

• Atividades que acontecem desde que um estado esteja ativo

• Ações em um estado final

• Aninhamento de estados

• Concorrência

5.1 Elementos do diagrama de estado

A Figura 37 mostra os elementos da notação do diagrama de estado e as seções a seguir apresentam a definição e semântica de cada elemento.


Figura 37. Notação do Diagrama de Estado.

5.1.1 Estado

Todos os objetos possuem um estado. O estado é o resultado de atividades previamente realizadas e é determinado pelos valores dos atributos ou ligações com outros objetos. Uma classe pode conter um atributo específico de estado ou o estado pode ser determinado através de outros valores do objeto.

Os estados dos objetos são normalmente rotulados com verbos no gerúndio (por exemplo, discando, tocando) ou então com substantivos que claramente indiquem um estado para o objeto.

5.1.2 Eventos

Um evento é algo que pode acontecer e causar alguma ação. Por exemplo, apertar o botão “play” do CD player é um evento que faz com que o aparelho comece a tocar (ação). Existem quatro tipos de eventos em UML:

• Uma condição se torna verdadeira: Mostrado como uma condição de guarda na transição de estados;

• Recepção de um sinal explícito de outro objeto: O sinal é mostrado como uma assinatura de evento na transição de estado. Este tipo de evento é chamado mensagem;

• Recepção de uma chamada a uma operação por outro objeto (ou pelo próprio objeto): Mostrado como uma assinatura de evento em transições de estado. Também é uma mensagem;

Assinatura-de-evento [condição de guarda] /

expressão de ação ^ cláusula de envio

Nome-do-estado

entrar: ação de entradafazer: atividade Ano evento 1: ação 1...Sair: ação de saída

Estado inicial

Estado final


• Passagem de tempo: O tempo é calculado após um evento ou a passagem de um determinado período de tempo. Mostrado como uma expressão de tempo em uma transição de estado.

É importante notar que a semântica de eventos indica que são processados um de cada vez. Se um evento puder ativar mais de uma transição, apenas uma será ativada. Se um evento ocorrer, e a condição de guarda for falsa, então o evento será ignorado

5.1.3 Transições

Em um diagrama de estados, uma transição é uma seta ligando um estado a outro, etiquetada por uma sequência de transição cujo significado é:

• Assinatura de evento: contém o nome do evento mais parâmetros;

• Condição de guarda: Expressão booleana escrita em termos de parâmetros do evento de disparo, atributos e vínculos do objeto que possui a máquina de estado. Uma guarda é uma condição que deve ser satisfeita antes de ocorrer a transição;

• Expressão de ação: Expressão procedural executada no disparo da transição. Pode ser descrita em termos de operações, atributos e vínculos de objeto e parâmetros do evento de disparo. Deve ser uma operação atômica e pode vir acompanhada de outras expressões de ação separadas por “/”;

• Cláusula de envio: É um caso especial de ação com o formato:

Expressão de destino “.” Nome-do-evento-de-destino “(“argumento “.” ... “(“ Onde:

- Expressão-de-destino é uma expressão relacionada a um objeto ou a um conjunto de objetos. Pode ser escrita em termos dos parâmetros de evento de disparo e os atributos e vínculos do objeto considerado;

- Nome-do-evento-de-destino é o nome de um evento significativo para o objeto de destino.

5.2 Exemplos

A Figura 38 mostra exemplos de diagramas de estados para um sistema eleitoral e a figura 39 mostra o diagrama de estados do sistema de vendas.


Esperando

Votandoem prefeito

Votandoem vereador

Urna

Habilita voto

Voto prefeito

Voto vereador

Fecha urna

Apresentandodocumentos

Votandoem prefeito

Votandoem vereador

Eleitor

Habilita voto

Voto prefeito

Voto vereador

Aguardandocomprovante

Comprovante recebido

Figura 38 Estados para classes Urna e Eleitor de um sistema eleitoral


Figura 39. Diagrama de estados para uma venda no sistema de vendas.


6 ESTUDOS DE CASO E EXERCÍCIOS

6.1 Estudo de Caso 1: Locadora de Veículos

Modelar um sistema OO tomando por partida a definição abaixo:

“O cliente é sócio-proprietário de uma rede de locadora de carros que possui várias filiais espalhadas por vários estados brasileiros e países do Mercosul. Cada filial possui diversos carros para alugar. Existem vários tipos de carro: popular, luxo, utilitário, etc. Os carros possuem código (chapa do carro), tipo, modelo, ano, cor, chassis, km e valor do aluguel (diárias e semanais). Os clientes da locadora podem reservar e alugar carros. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguéis. Para cada aluguel é emitida uma nota fiscal com a quilometragem percorrida e o valor do aluguel. A locadora possui funcionários que trabalham nas filiais. As filiais são identificadas por código, nome cidade, endereço e telefones. Os clientes são identificados por código, nome, cpf, telefone, endereço, cidade. E os funcionários são identificados por código, nome, endereço, telefone, cidade.”

6.2 Estudo de Caso 2: Hospital

Modelar um hospital com vários setores e funcionários que presta vários tipos de serviço aos pacientes conforme características abaixo:

• Setores são compostos de vários sub-setores. Cada setor está dividido em salas. Existem salas de cirurgia, consultórios, apartamentos, etc.

• Os funcionários do hospital trabalham em setores e são médicos, enfermeiros e pessoal administrativo com diversos cargos. Existem equipes de médicos e enfermeiros com um médico como supervisor da equipe;

• Os pacientes são submetidos a procedimentos no hospital. Procedimentos são pagos por convênios ou pelo próprio paciente (particular) e podem ser:

- Cirurgias: ocupando salas de cirurgia com equipe médica responsável;

- Internações: ocupando enfermarias ou quartos e com tratamento prescrito (medicação e dieta);

- Consultas: com data, hora, diagnóstico, exames solicitados e receita médica, ocupando consultórios e com médico responsável;

- Exames: solicitados em consultas médicas, registrando os resultados;

- Outros procedimentos de hospital.

• Definir novos requisitos para o sistema


REFERÊNCIA BIBLIOGRÁFICA

[BOO94] BOOCH, G. Object-Oriented Analysis and Design with Applications. Benjamim-Cummings Publishing Co., 1994.

[BOO02000] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. São Paulo: Campus, 2000.

[CHE90] CHEN, P. Modelagem de Dados: A abordagem Entidade-Relacionamento para Projeto Lógico. Makron Books, 1990.

[COA98] COAD, P.; MAYFIELD, M. Projeto de Sistemas em Java: Construindo aplicativos e melhores applets. São Paulo: Makron Books, 1998.

[ERI98] ERIKSSON, H.; PENKER, M. UML Toolkit. Wiley Computer Publishing, 1998.

[FUR98] FURLAN, J.D. Modelagem de Objetos através da UML. São Paulo: Makron Books, 1998.

[GUE91] GUEZZI, C.; JAZAYERI, M. Fundamentals of Software Engineering. Prentice-Hall, 1991.

[HEU 99] HEUSER, C. A. Projeto Orientado a Objetos. Apostila de curso. Obtida em http://heuser.inf.ufrgs.br

[JAC92] JACOBSON, I. et. al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Publishing Co., 1992.

[JAC99] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Process. In: IEEE Software. p. 96-102. May/June 1999.

[RUM94] RUMBAUGH, J. et. al. Modelagem e Projetos Baseados em Objetos. São Paulo: Campus, 1994.

[TOG00] Together Inc. (http://www.togethersoft.com)

Modelagem de Objetos Com UML

Documents

Transcript of Modelagem de Objetos Com UML