UML - Luciano Tucci

Propaganda
Histórico da UML
Os estudos sobre a tecnologia de objetos iniciaram-se na década de 1980 com ênfase nas linguagens de programação. No final da
mesma década começaram a surgir os métodos de análise e projeto. Os principais métodos foram de:
•
SHLAER & MELLOR (1989 e 1991);
•
COAD & YOURDON (1991);
•
COAD & NICOLA (1993);
•
COAD et al. (1995);
•
WIRFS-BROCK et al. (1990);
•
BOOCH (1994 e 1995);
•
RUMBAUGH et al. (1991 e 1996);
•
MARTIN & ODELL (1994 e 1995);
•
JACOBSON (1994 e 1995).
Todos os métodos eram muito similares, apesar da existência de diferentes notações para representar o mesmo conceito, o que
na verdade, causava muita confusão entre os técnicos e competição entre os metodologistas, o que provocou a "guerra dos
métodos".
Em 1994 James Rumbaugh e Grady Booch iniciaram o trabalho de unificação dos métodos Booch e OMT.
Em 1995 no OOPSLA , Booch e Rumbaught apresentaram a documentação da versão 0.8 do método unificado e anunciaram a
integração de Ivar Jacobson na equipe, formando assim o que eles denominaram de "Three amigos".
Durante 1996 eles trabalharam no método que passou a chamar de Unified Modeling Language (UML) e a Object Management
Group (OMG) iniciou um esforço para padronização na área de métodos.
Os esforços de Rumbaugh, Booch e Jacobson resultaram as versões 0.9 e 0.91 da UML em junho e outubro de 1996
respectivamente.
A UML é a sucessora da linguagem de modelagem encontrada nos métodos Booch, OOSE/Jacobson, OMT e outros como Modelos
de Entidades e Relacionamentos.
Cada um desses métodos era reconhecido mediante alguma forte característica. O OOSE é orientado a ‘use case’ e provê um
excelente recurso para a análise de requisitos. A OMT foi expressiva para análise e sistemas centrados a dados.
Durante 1996 a Rational Software Corporation contou com a participação de outras Instituições parceiras como: HewlettPackard, IBM, Microsoft, Oracle, Unisys, Platinum Technology, etc. Essa colaboração contribuiu para a produção da versão 1.0,
uma versão bem definida, expressiva, poderosa e aplicável, a qual foi submetida a OMG para adoção.
Em setembro de 1997 liberaram a versão 1. 1 da UML e em dezembro a mesma foi aprovada como padrão pela OMG.
Com a unificação dos métodos a UML alcançou dois objetivos:


Acabou com as diferenças existentes entre os métodos anteriores;
Unificaram as perspectivas entre os diferentes tipos de sistemas, fases de desenvolvimento e conceitos internos.
Método
A UML não é um método é uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um
sistema. A linguagem de modelagem é a notação que o método utiliza para expressar projetos enquanto que o processo indica
quais passos seguir para desenvolver um projeto.
A especificação da UML consiste de duas partes:


Semântica - especifica a sintaxe abstrata e a semântica dos conceitos de modelagem estática e dinâmica de objetos;
Notação – especifica a notação gráfica para a representação visual da semântica.
A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental é o processo de
desenvolvimento de sistemas em pequenos passos. Uma iteração é um laço de desenvolvimento que resulta na liberação de um
subconjunto de produtos que evolui até o produto final percorrendo as seguintes atividades:





Análise de requisitos
Análise
Projeto
Implementação
Teste
O detalhamento de cada etapa destas atividades define o método de desenvolvimento de sistemas.
Análise de requisitos
Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o
relacionamento entre o ambiente e o sistema. Deve ser uma definição de necessidades do usuário e não uma proposta de
solução. O usuário deve indicar os requisitos prioritários para o sistema.
O grupo de análise deve identificar as necessidades do usuário. Decisões do projeto impostas não são características essenciais
do domínio do problema.
A análise de requisitos compõe-se dos seguintes diagramas:



Diagrama de caso de uso;
Diagrama de seqüência;
Diagrama de colaboração;
Para realizar a análise de requisitos, primeiramente deve-se:






Identificar objetivo e características do sistema;
Identificar os requisitos essenciais;
Descrever as necessidades do usuário;
Elaborar diagrama de caso de uso;
Elaborar diagrama de seqüência;
Elaborar diagrama de colaboração
Conceitos
UML é uma linguagem visual para especificação (modelagem) de sistemas orientados a objeto. A UML privilegia a descrição de
um sistema seguindo três perspectivas:
1. Os diagramas de classes - (Dados estruturais);
2. Os diagramas de casos de uso (Operações funcionais);
3. Os diagramas de seqüência, atividades e transição de Estados (Eventos temporais).
Os casos de uso de um projeto de software são descritos na linguagem UML através de Diagramas de Casos de Uso (Use Case).
Diagrama de "Use Case": É um diagrama usado para se identificar como o sistema se comporta em várias situações que podem
ocorrer durante sua operação. Descrevem o sistema, seu ambiente e a relação entre os dois. Os componentes deste diagrama são
os atores, os "Use Case" e os relacionamentos. Casos de uso e Relacionamentos. Ainda pode-se usar as primitivas Pacotes e
Notas.
Ator: Representa qualquer entidade que interage com o sistema durante sua execução essa interação se dá através de
comunicações (troca de mensagens). Um ator pode ser uma pessoa (usuário, secretaria, aluno...), um dispositivo (impressora,
máquina...), hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc.
Algumas de suas características são descritas abaixo:




Ator
Ator
Ator
Ator
não é parte do sistema. Representa os papéis que o usuário do sistema pode desempenhar.
pode interagir ativamente com o sistema.
pode ser um receptor passivo de informação.
pode representar um ser humano, uma máquina ou outro sistema.
Representação:
OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outros quando interagem com o
sistema. Um ator cujo identificador seja ALUNO não representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja
interagindo com o sistema na qualidade de aluno.
Use Case: Como foi exemplificado acima, é uma seqüência de ações que o sistema executa e produz um resultado de valor para
o ator. Modela o dialogo entre os atores e o sistema; é um fluxo de eventos completos. Algumas de suas características são
descritas abaixo:




Um "Use Case" modela o diálogo entre atores e o sistema.
Um "Use Case" é iniciado por um ator para invocar uma certa funcionalidade do sistema.
Um "Use Case" é fluxo de eventos completo e consistente.
O conjunto de todos os "Use Case" representa todas as situações possíveis de utilização do sistema.
Relacionamento: Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os
relacionamentos podem ser dos seguintes tipos:


Associação: É uma conexão entre classes, e também significa que é uma conexão entre objetos daquelas classes. Em UML,
uma associação é definida com um relacionamento que descreve uma série de ligações, onde a ligação é definida como a
semântica entre as duplas de objetos ligados.
Generalização: É um relacionamento de um elemento mais geral e outro mais específico. O elemento mais específico
pode conter apenas informações adicionais. Uma instância (um objeto é uma instância de uma classe) do elemento mais
específico pode ser usada onde o elemento mais geral seja permitido.
Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de
uso e assim sucessivamente. O relacionamento é representado através de uma seta :
Exemplo: Diagrama de "Use Cases" para um sistema automatizado de Matrícula num Curso
Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando, por exemplo, que elas
"conhecem uma a outra", "estão conectadas com", "para cada X existe um Y" e assim por diante. Classes e associações são muito
poderosas quando modeladas em sistemas complexos
Associações Normais
O tipo mais comum de associação é apenas uma conexão entre classes. É representada por uma linha sólida entre duas classes. A
associação possui um nome (junto à linha que representa a associação), normalmente um verbo, mas substantivos também são
permitidos.
Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada para o lado onde a seta aponta.
Mas associações também podem possuir dois nomes, significando um nome para cada sentido da associação.
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão relacionados no link. O
intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11
(5..11) e assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). Se não for descrita nenhuma
multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1).
Duas classes se relacionando por associação normal
No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associação.
Associação Recursiva
É possível conectar uma classe a ela mesma através de uma associação e que ainda representa semanticamente a conexão entre
dois objetos, mas os objetos conectados são da mesma classe. Uma associação deste tipo é chamada de associação recursiva.
Exemplo de uma associação recursiva
Associação Ternária
Mais de duas classes podem ser associadas entre si, a associação ternária associa três classes. Ela é mostrada como uma grade
losango (diamante) e ainda suporta uma associação de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do
losango para a classe onde seria feita a associação ternária.
Exemplo de uma associação ternária
No exemplo acima a associação ternária especifica que um cliente poderá possuir 1 ou mais contratos e cada contrato será
composto de 1 ou várias regras contratuais.
Agregação
A agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está
contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de".



É uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como
relação de conteúdo.
É representada como uma linha de associação com um diamante junto à Classe agregadora.
A multiplicidade é representada da mesma maneira que nas associações.
Tipo de Relacionamento - Generalizações
A generalização é um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui
todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado
como uma instância do elemento mais geral. A generalização, também chamada de herança, permite a criação de elementos
especializados em outros.
Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São elas: generalização normal e
restrita. As generalizações restritas se dividem em generalização de sobreposição, disjuntiva, completa e incompleta.
Generalização Normal
Na generalização normal a classe mais específica, chamada de subclasse, herda tudo da classe mais geral, chamada de
superclasse. Os atributos, operações e todas as associações são herdados.
Exemplo de uma generalização normal
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico
onde as classes estão ligadas através de generalizações.
A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca
uma seta no lado da linha onde se encontra a superclasse indicando a generalização.
Generalização Restrita
Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e
estendida no futuro. As restrições a seguir definem as generalizações restritas com mais de uma subclasse:
Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma
superclasse por sobreposição, novas subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva é
exatamente o contrário da sobreposição e a generalização é utilizada como padrão
Exemplo de uma generalização de sobreposição

Generalizações Completa e Incompleta: Uma restrição simbolizando que uma generalização é completa significa que todas
as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A
generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem.
Diagrama de Seqüência
Em um sistema computacional orientado a objeto os serviços (casos de uso) são fornecidos através da colaboração de grupos. Os
objetos interagem através de comunicações de forma que juntos, cada um com suas responsabilidades, realizem os casos de uso.
O Diagrama de seqüência é uma ferramenta importante no projeto de sistemas orientados a objetos. Embora a elaboração dos
diagramas possa consumir um tempo considerável para sistemas maiores ou mais complexos, eles oferecem a seguir as bases
para a definição de uma boa parte do projeto como: os relacionamentos necessários entre as classes, métodos e atributos das
classes e comportamento dinâmico dos objetos.
Um diagrama de seqüência é um diagrama de objetos, ou seja, ele contém como primitiva principal um conjunto de objetos de
diferentes classes. O objetivo dos diagramas de seqüência é descrever as comunicações necessárias entre objetos para a
realização dos processos em um sistema computacional. Os diagramas de seqüência têm este nome porque descrevem ao longo
de uma linha de tempo a seqüência de comunicações entre objetos. Como podem existir muitos processos em um sistema
computacional, sugere-se proceder à construção dos diagramas de seqüência por caso de uso. Assim, tomar-se-ia separadamente
cada caso de uso para a construção de seus diagramas de seqüência. De uma forma geral, para cada caso de uso constrói-se um
diagrama de seqüência principal descrevendo as seqüências normais de comunicação entre objetos e diagramas complementares
descrevendo seqüências alternativas e tratamento de situações de erro.
Utiliza-se também o termo cenário associado com os diagramas de seqüência. Um cenário é uma forma de ocorrência de um caso
de uso. Como o processo de um caso de uso pode ser realizado de diferentes formas, para descrever a realização de um caso de
uso pode ser necessário estudar vários cenários. Cada cenário pode ser descrito por um diagrama de seqüência. No exemplo do
caso de uso Cadastrar Aluno do sistema de controle acadêmico, podem-se considerar os cenários de inclusão, alteração e
exclusão de aluno.
Notação UML para Diagramas de Seqüência
A notação UML para descrição de diagramas de seqüência envolve a indicação do conjunto de objetos envolvidos em um cenário
e a especificação das mensagens trocadas entre estes objetos ao longo de uma linha de tempo. Os objetos são colocados em
linha na parte superior do diagrama. Linhas verticais tracejadas são traçadas da base dos objetos até a parte inferior do
diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, à medida que se avança
para baixo evolui-se o tempo. Retângulos colocados sobre as linhas de tempo dos objetos indicam os períodos de ativação do
objeto. Durante um período de ativação, o objeto respectivo esta em execução realizando algum processamento. Nos períodos
em que o objeto não esta ativo, ele esta alocada (ele existe), mas não esta executando nenhuma instrução. A figura abaixo
ilustra a estrutura básica de um diagrama de seqüência para o cenário Inclusão de Aluno do caso de uso Cadastrar Aluno.
Outra primitiva importante dos diagramas de seqüência é a troca de mensagem. Esta primitiva é utilizada para indicar os
momentos de interação ou comunicação entre os objetos. Utiliza-se como notação para trocas de mensagens segmentos de retas
direcionadas da linha de tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta é colocada na
extremidade do objeto destino. As linhas representando troca de mensagens são desenhadas na horizontal, pois se presume que
a troca de uma mensagem consome um tempo desprezível.
O objeto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, no recebimento de uma mensagem o
objeto destino é ativado para tratamento da mensagem. A figura abaixo ilustra a troca de mensagens entre objetos e entre
atores e objetos.
As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter três significados:
· Chamada de Função ou Procedimento
Uma das interações mais freqüentes entre objetos é a chamada de função. Uma chamada de função significa que um objeto esta
solicitando a execução de uma função (um método) de um outro objeto. Este conceito segue estritamente o processo de
chamada de função ou de procedimento utilizado nas linguagens de programação. Obviamente, para que um objeto possa
chamar um método de outro objeto é necessário que o método seja declarado como publico na classe respectiva. Como será
visto a seguir, a sintaxe, no caso de mensagens que representem chamadas de função, é semelhante àquela das linguagens de
programação.
· Envio de Mensagem
Objetos também podem comunicar-se com outros objetos através do envio explıcito de uma mensagem. O envio de uma
mensagem, ao contrario da chamada de função, não é uma interação direta entre dois objetos. Na verdade, quando um objeto
envia uma mensagem a outro objeto, a mensagem é roteada ou encaminhada por algum mecanismo de entrega de mensagens.
Normalmente, este serviço é prestado pelo sistema operacional através de mecanismos como Message Queries (filas de
mensagens) ou serviços de notificação.
· Ocorrência de Evento
Existem também outras formas de interação entre objetos através de eventos. Esta é também a forma padrão de interação entre
objetos e atores. Basicamente, um evento é algum acontecimento externo ao software, mas que é a ele notificado, pois lhe diz
respeito. A notificação, ou seja, a indicação de que um determinado evento ocorreu é, na maioria dos casos, feita pelo sistema
operacional. Eventos podem também ser gerados pelo software para o sistema operacional. Exemplos são as saídas para
dispositivos (monitor, porta serial, disco) feitos através de serviços do sistema operacional.
Alguns exemplos de eventos são:
Evento
Origem
Destino
Clique do mouse
mouse
Algum objeto
Movimentação do mouse
mouse
Algum objeto
Dados no buffer do teclado
teclado
Algum objeto
Dados no buffer da serial
porta serial
Algum objeto
Projeção de dados no monitor.
Bip do alto-falante.
Algum objeto
Algum objeto
monitor
alto-falante
Colocação de dados no buffer da serial
Algum objeto
Porta serial
Interrupção
Dispositivo de
hardware
Algum objeto
Eventos do sistema operacional (timer)
Sistema operacional
Algum objeto
Tipos de Mensagens
Nos exemplos das figuras utilizou-se como notação gráfica para as trocas de mensagens segmentos de reta com uma seta aberta
em uma das extremidades. Esta é a notação genérica para mensagens que pode ser utilizada nas primeiras versões dos diagramas
de seqüência. Em diagramas mais detalhados, entretanto, será utilizada outra notação deforma a indicar também o tipo das
mensagens. Existem dois tipos de mensagens chamadas mensagens síncronas e assíncronas.
· Mensagens Síncronas
Mensagens síncronas são mensagens que implicam um sincronismo rígido entre os estados do objeto que envia a mensagem e os
do objeto de destino da mensagem. Um sincronismo entre objetos pode ser entendido, de uma forma geral, como uma
dependência na evolução de estado de um objeto sobre o estado de um segundo objeto. De uma forma mais direta, pode-se
dizer que uma mensagem síncrona implica que o objeto que enviou a mensagem aguarde a conclusão do processamento da
mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para então prosseguir seu fluxo de execução. O
exemplo mais comum de mensagem síncrona é a chamada de função. Em uma chamada de função o objeto que faz a chamada ü
empilhado e fica neste estado até a conclusão do processamento da função chamada. Trata-se, portanto, de um sincronismo
rígido entre o objeto chamador e o objeto chamado. Alguns sistemas operacionais oferecem também mecanismos de troca de
mensagens síncronas de forma que o objeto que envia a mensagem fique em estado de espera até a conclusão do tratamento da
mensagem.
A notação UML para uma mensagem síncrona é a de um segmento de reta com uma seta cheia em uma das extremidades
· Mensagens Assíncronas
Mensagens assíncronas são mensagens enviadas de um objeto a outro sem que haja uma dependência de estado entre os dois
objetos. O objeto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem
feita no objeto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais são o exemplo mais
comum deste tipo de mensagem. Além disso, de uma forma geral, todas as comunicações entre atores e objetos representam
trocas de mensagem assíncronas. Considere, por exemplo, uma operação para apresentação de uma mensagem no monitor. Um
objeto executa uma instrução print (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O objeto
prossegue seu processamento independentemente do desfecho na operação. Observe que os softwares não bloqueiam quando o
monitor não apresenta alguma informação. A notação UML para uma mensagem assíncrona é a de um segmento de reta com uma
meia seta em uma das extremidades.
· Autodelegação
Um objeto pode enviar mensagens para outros objetos e pode também enviar mensagens para ele próprio. Uma mensagem
enviada de um objeto para ele próprio chama-se uma Autodelegação. Mensagens de Autodelegação podem ser síncronas ou
assíncronas. O caso mais comum de mensagens assíncronas é o envio de uma mensagem de um objeto para ele mesmo através de
mecanismos de envio de mensagens do sistema operacional. O caso mais comum de mensagens de Autodelegação síncronas é a
chamada de função de um objeto pelo próprio objeto.
Diagrama de Colaboração
Mostra a interação organizada ao lado de cada classe de objetos e a ligação entre elas. Como o diagrama de seqüência, o
diagrama de colaboração mostra as mensagens trocadas por um conjunto de objetos durante um cenário. É uma representação
gráfica alternativa para mostrar um cenário. Descrevem grupos de objetos que colaboram através de comunicação.
Um diagrama de colaboração contém:




Objetos, que são representados por retângulos.
Ligações entre objetos, representadas por uma linha conectando os objetos.
Mensagens trocadas entre objetos em uma seqüência ordenada
Fluxo de dados entre objetos, se houver.
Através do diagrama de colaboração é mais fácil visualizar as mensagens trocadas entre os objetos, subsidiando assim a
elaboração do diagrama de classes de objetos. Os objetos e as mensagens são as mesmas do diagrama de seqüência. Utilizando o
diagrama de colaboração é possível identificar se existe algum objeto que não troca mensagens com outro. Caso isto aconteça
deve-se analisar o modelo de origem e verificar se este objeto é mesmo necessário. Os diagramas de seqüência e de colaboração
serão mais utilizados no desenvolvimento do projeto quando são projetadas as implementações dos relacionamentos.
O objetivo do diagrama de colaboração é agrupar as mensagens entre pares de objetos de forma a fazer-se um levantamento das
necessidades de comunicação.
Diagrama de Estado
O comportamento de uma classe de objetos é representado através de um diagrama de transição de estado, que descreve o ciclo
de vida de uma dada classe, os eventos que causam a transição de estado para o outro e as ações resultantes da mudança de
estado.
O estado de um objeto é uma das possíveis condições na qual o objeto pode existir. O estado compreende todas as propriedades
do objeto associadas aos valores correntes de cada uma dessas propriedades.
Segundo a UML a especificação da dinâmica do sistema deve ser feita através de diagramas de estados. Constrói-se um diagrama
de estado descrevendo o comportamento de cada classe e eventuais diagramas comportamentais para descrever a dinâmica de
todo o sistema ou de certos módulos.

Diagrama de estado é uma descrição global do comportamento dos objetos desta classe em todo o sistema;


Diagrama de estado; a especificação da dinâmica do sistema deve ser feita através de diagramas de classe;
Descreve-se o conjunto de estados de um objeto e também o conjunto de transações de estados existentes.
A UML utiliza como notação para diagramas de estados a notação proposta por Harel. Nesta notação, um diagrama de estados e
um grafo dirigido cujos nodos representam estados e cujos arcos representam transições entre estados. Estados são
representados graficamente por elipses ou retângulos com bordas arredondadas e transições são representadas por segmento de
retas dirigidas.
Download