UML

Aluno: Fernando Alves Michalak - 211010503

UML

1. História
   O UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. O UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.
   O UML ainda não é um padrão da indústria, mas esse objectivo está a tomar forma sob os auspícios do Object Management Group (OMG). O OMG pediu informação acerca de metodologias orientadas a objectos que pudessem criar uma linguagem rigorosa de modelização de software. Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.
   Os esforços para a criação da UML teve início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Método Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.

2. Blocos de construção
São 3 os tipos de blocos de construção:
Itens da UML: abstrações como cidadãos da primeira classe em um método;
Relacionametos: reúnem os itens;
Diagramas: agrupam coleções interessantes de itens;

a. Itens da UML
Estruturais: classes, interfaces, colaborações, casos de uso, classes ativas, componentes e nós

i. Comportamentais: interação, máquina de estado

ii. De agrupamentos: pacotes

iii. Anotacionais: nota

1. Relacionamentos

i. Dependência

ii. Associação

iii. Generalização

iv. Realização

1. Diagramas

i. Classes
Este diagrama lista todos os conceitos do domínio que serão implementados no sistema. O diagrama lista também as relações entre os conceitos: um cliente “reserva'' x lugar(es) para a data y. Em geral, conceitos são substantivos e relações são verbos.
O diagrama de classe é muito importante porque define a estrutura do sistema a desenvolver. A maioria dos outros diagramas vão usar as classes definidas no diagrama de classe.

ii. Objetos
Um diagrama de UML usa a mesma notação e relacionamentos de um diagrama de classes. Onde um diagrama de classes mostra o tipo de classes e seus relacionamentos, um diagrama de objetos mostra instâncias específicas e as ligações entre elas em algum momento da execução do sistema. Ou seja, abrangem uma visão estática da estrutura ou processo de um sistema. Um diagrama de objetos pode ser visto, então, como um exemplo de diagrama de classe.

Representação de um diagrama de Objetos Instanciados

Representação correta de um Objeto Instanciado

Um objeto é mostrado como uma classe, o nome é sublinhado, apesar de um nome de objeto poder ser mostrado opcionalmente precedendo o nome da classe : nome do objeto: nome da classe. O Objeto não precisa ser nomeado.

iii. Casos de uso
Este diagrama mostra como o sistema a ser desenvolvido vai interagir com seu ambiente (usuários ou outros sistemas). Ele é bastante importante porque vai ser a base do processo de desenvolvimento do sistema. O diagrama de classes especifica a estrutura do domínio e do sistema, os casos de usos vão ser a entrada para formalizar as funcionalidades que o sistema deve cumprir.
Um caso de uso descreve as operações que o sistema deve cumprir para cada usuário. Ele vai ajudar a formalizar as funções que o sistema precisa fazer.
Um caso de uso se apresenta como uma lista completa das interações entre um usuário e o sistema para cumprir uma tarefa. Lista completa significa que o caso de uso descreve as interações desde o início da tarefa, até o fim.
Casos de uso descrevem interações entre o sistema e atores. Um ator é “alguma coisa'' (usuário, outro sistema,...) que não faz parte do sistema e interage com ele.
Um usuário real pode cumprir vários papeis para o sistema (i.e. ser representado por vários atores). Um ator pode também representar várias pessoas, quando falamos de um “cliente'' tirando dinheiro do caixa eletrônico, é claro que esse ator representa qualquer pessoa.
É importante identificar todos os atores que vão interagir com o sistema. E para cada ator, é importante identificar que operações ele vai precisar. A pesquisa de caso de usos se faz a partir dos atores, não a partir das operações. Isso quer dizer que não vamos procurar qualquer funcionalidade abstrata que seria interessante para o sistema cumprir, mas vamos procurar funcionalidades concretas que um usuário realmente precisa.
Geralmente, um caso de uso é iniciado por um ator, não pelo sistema.
Um caso de uso só descreve as interações entre o ator e o sistema, não descreve como essas funcionalidades vão ser implementadas.
O nome de um caso de uso pode ser qualquer sentencia, mas a UML recomenda usar uma frase ativa curta (verbo + substantivo).
Esse diagrama é diferente dos outros porque contem poucos gráficos. Um caso de uso é principalmente composto de texto livre, ou pseudocódigo que descreve cada interação. Os elementos principais do diagrama são uma elipse para representar um caso de uso e um pequeno boneco para representar um ator. O nome do caso de uso pode ser dentro da elipse ou abaixo dele.

O diagrama não especifica os casos de uso, mas só apresenta qual ator interage com qual caso e organiza os casos entre eles (ex.: qual herda de um outro). Os casos de uso vão ser especificados em outros documentos. A UML não define precisamente a forma dessa descrição. Ela é um texto livre.
Casos de usos podem ser organizados em pacotes, ligados com a relação de generalização ou a relação de dependência. Tal organização de casos de uso será usada só para o desenvolvimento de sistemas amplos. Ela não é considerada importante nessa disciplina.

iv. Seqüências

Num diagrama de seqüência, cada objeto é apresentado com uma linha vertical que representada a “vida'' do objeto. A cima dessa linha tem uma caixa representando o objeto. Enquanto o objeto tem o controle (ou esta esperando para uma operação retornar o controle a ele), a linha de vida é uma caixa vertical. Caso contrário, ela é apresentada com uma linha tracejada.
Nesse diagrama, o tempo vai de cima para baixo. não é necessário especificar os números de seqüência das mensagens porque eles são implícitos com o eixo vertical do tempo.
Mensagens são trocadas entre as linhas de vida dos objetos. O diagrama não apresenta explicitamente as conexões entre os objetos. A figura mostra várias mensagens: envio de um sinal (ex.: “introduzCartão''); chamada de operações (ex.: “escolherOperação()'', “entregarDinheiro()'', etc.); retorno de valor (ex.: “senha'') e criação e destruição (da instância de Operação).
Nessa figura, especificamos apenas o nome das operações, mas poderíamos também especificar o valor dos seus parâmetros.
Um objeto pode enviar uma mensagem a ele mesmo. Nesse caso a seta sai da linha de vida do objeto e retorna para essa mesma linha.
O diagrama permite especificar outras informações:
loop: acrescentar antes do nome da mensagem uma estrela e opcionalmente o teste de controle da loop.
condição: acrescentar a condição antes do nome da mensagem. Por exemplo: [i > 0] : setValue(). Várias mensagens podem ser enviadas com condições diferentes a partir do mesmo ponto. Nesse caso, cada condição tem que ser mutuamente exclusiva com as outras.
recursividade: desenhar uma outra caixa na linha de vida do objeto, um pouco deslocada na direita da caixa principal.

v. Colaborações
Ao contrario do diagrama de seqüência, nesse diagrama o foco não é sobre o tempo, mas a organização dos objetos. Por isso, esse diagrama mostra explicitamente as conexões entre os objetos (o que o diagrama de seqüência não faz), enquanto ele deve acrescentar números de seqüência às mensagens para indicar a ordem de chamada.
Uma outra diferencia é que no diagrama de seqüência se mostra explicitamente o retorno das mensagens enquanto o diagrama de colaboração não o faz.
A figura mostra várias noções interessantes desse diagrama:
Conexões podem ter estereótipos para clarificar como ou porque o objeto emissor da mensagem tem acesso ao objeto receptor. Tem cinco estereótipos possíveis: <<associação>> que é uma conexão normal, por causa de uma associação entre as classes dos objetos; <<self>> a conexão não existe realmente, o emissor esta enviando uma mensagem para ele mesmo; <<global>> a conexão não existe realmente, mas o receptor é disponível globalmente no contexto do emissor; <<local>> o receptor é disponível localmente (por exemplo, dentro de uma variável local à operação do emissor); <<parameter>> o receptor é disponível localmente por que foi recebido como parâmetro da operação do emissor.
Tem duas instâncias da classe Course, isso mostra a diferencia entre diagrama de objeto e diagrama de classe, e associação e conexão.
A instância “s'' da classe Student, é apresentada duas vezes porque ela muda de estado (o atributo registered mudou de valor). Isso é representado junto com uma mensagem de estereótipo <<become>>. Vamos discutir os estados no capítulo sobre diagrama de estados.
Três conexões de School até Course e Student não carregam mensagens. Elas são apresentadas apenas para explicitar como um Student tem acesso aos Course usando as associações entre, primeiro Student e School, e segundo School e Course.

vi. Diagrama de atividade, diagrama de estado
Os diagramas de atividade e de estado, especificam o comportamento de uma entidade só, seja um objeto instância de uma classe, uma operação, um sistema, etc.

Figura: Exemplos de diagrama de atividade (a esquerda) e diagrama de estado (a direita) na UML
A figura acima apresenta exemples muito simples dos diagramas de atividade e de estado. O diagrama de atividade apresentado contem estados de atividades (Ligar televisão, Assistir programa, etc.), um estado inicial (o círculo preto), um estado final (o círculo preto dentro de um outro círculo), transições entre esses estados e ramificações (``branch'') com expressões de guarda (``guard'': Programa interessante). O diagrama de estado apresentado contem dois estados (luzApagada, luzAcendeda), e dois transições com eventos (ligar, desligar).
Componentes básicos
Os componentes básicos dos dois diagramas:
Estado:A descrição de uma situação na vida do sistema ou de um objeto a um momento definido. O estado pode ser descrito como o conjunto de valores dos atributos do objeto, com um evento que ele esta esperando, ou para uma operação que ele esta executando. Nesse último caso, existem dois tipos de estados: estado de ação --enquanto o sistema ou o objeto estão executando uma ação-- e estado de atividade --enquanto o sistema ou o objeto estão executando uma atividade. Um objeto permanece num estado por um tempo finito.
Estado inicial:Um estado virtual que marca o ponto de entrada do diagrama.
Estado final: Um estado virtual que marca o(s) ponto(s) de saída do diagrama.
Ação: Uma execução atômica. Ela não pode ser interrompida e se considera que ela dura um tempo não significativo.
Os tipos de ações são: chamada de uma operação, envio de um sinal, retorno de um valor (avaliação de uma expressão, execução de um calculo), criação de um objeto, destruição de um objeto, ou modificação do valor de um atributo. Já vimos que os cinco primeiros corespondem ao envio de uma mensagem. Uma outra classificação seria de dizer que uma ação pode modificar o estado do sistema ou de um objeto ou retornar um valor.
Atividade: Uma execução não atômica composta de ações ou de outras atividades. Por exemplo, a execução de uma operação para um objeto é uma atividade.
Atividades podem ser interrompidas e se considera que suas execuções duram alguns tempos.
Evento: Alguma coisa que acontece. Tem quatro tipos de eventos: envio de um sinal, chamada de uma operação, passo do tempo e mudança de estado. Já vimos dois desses no capítulo precedente como tipos possíveis de mensagens: chamada de uma operação e envio de um sinal.
Uma chamada de operação é um evento sîncrono, o emissor pára sua execução e espera a resposta (retorno da operação) do outro objeto.
Sinal: Um objeto nomeado enviado (``thrown'') de maneira assîncrona por um objeto e recebido (``caught'') por um outro.
Sinais são eventos assîncronos --ao contrário das chamadas de operações que são eventos sîncronos-- o emissor envia o sinal mas continua sua execução sem esperar resposta, nem saber se o outro objeto esta pronto para receber o sinal.
Exceções (em Java ou outras linguagens) são sinais.
Transição: A passagem de um estado para um outro. As transições mostram o fluxo de controle de uma atividade (ou ação) para uma outra.
A passagem de uma atividade para uma outra pode ser automática (``trigerless'') enquanto a atividade terminou e o fluxo de controle passa para a atividade seguinte, ou pode ser provocada por um evento. Por exemplo a chamada de uma operação (um dos vários eventos possíveis) vai provocar uma mudança do fluxo de controle e vai iniciar uma nova atividade (execução da operação chamada).

vii. Componentes
O diagrama de componentes mostra a organização entre arquivos de código fonte, bibliotecas, tabelas de banco de dados, etc. A relação a mais usada é a de dependência, mostrando como um arquivo de código fonte depende de um outro que ele incluí, o como um executável depende de uma biblioteca por exemplo.
Um componente é um parte física do sistema. Muitas vezes um componente mostra um arquivo específico do sistema.
A UML reconhece cinco estereótipos de componentes:
executável: Um componente que pode ser executado (um programa).
biblioteca: Uma biblioteca de classes ou funções, dinâmica ou estática.
tabela: Uma tabela de um banco de dados.
documento: Uma parte da documentação (texto livre, diagramas, documentos de ajuda, etc.)
arquivo: Outros arquivos, geralmente, se trata de um arquivo de código fonte, mas pode ser tambem um arquivo de dados, um “script'' ou outros arquivos.
Figura: Os cinco tipos de componentes com os respectivos ícones na UML
Cada estereótipo tem um ícone definido na UML (ver a figura ). Esses ícones podem ser difícil de desenhar sem ferramentas especializadas. Nessa situação, se pode pensar em apresentar cada componente com um a caixa simples e o estereótipo apropriado.
O livro “UML User Guide'' apresenta também sugestões de ícones para outros estereótipos de componentes: Banco de dados, pagina web.
Componentes realizam e/ou dependem de interfaces. Por exemplo, na figura , o componente “component.java'', que corresponde a um arquivo de código fonte Java, implementa (realiza) a interface “ImageObserver''. Podemos dizer também que “component.java'' exporta a interface “ImageObserver''. Do outro lado, o componente “image.java'' depende da mesma interface, ele importa essa interface.

Figura: Componentes exportando e importando interface (copiado de “UML User Guide'', p. 348)
Graças a especificação das interfaces exportadas, componentes são substituíeis: uma biblioteca que realiza uma interface pode ser substituída por uma outra biblioteca realizando a mesma interface.

viii. Implantação
O diagrama de implantação é usado para sistema distribuídos. Ele permite apresentar a topologia de uma rede de “máquinas'' e qual processo (um componente executável) cada “máquina'' vai rodar.
Figura: Exemplo de um diagrama de distribuição (copiado de “UML User Guide'', p. 408)
As “maquinas'' são chamadas de nos. Um no apresenta uma fonte computacional, sendo normalmente um processador com alguma memória. Um no é representado por um cubo (ver figura acima). A relação entre um no e um componente que “roda'' sobre esse no é apresentada como uma relação de dependência.
Alguns usos mais comuns do diagrama de distribuição são:
Modelar um sistema “embarcado'' (“embeded system''). Esse tipo de sistema inclui sensores que vão receber informações do mundo exterior e partes agentes que vão agir sobre o mundo exterior. Cada parte precisa de “drivers'' e software especializado para funcionar com o resto.
Modelar sistemas distribuídos como no exemplo da figura acima, onde vários nos são inter-conectados numa rede de máquinas.
Modelar um sistema cliente/servidor. Esse tipo de sistema é um tipo particular de sistema distribuído onde as máquinas são classificadas em clientes, que interagem com o exterior (normalmente, os usuários), e os servidores que realizam os cálculos e o armazenamento dos dados e interagem com os clientes.