Para usar UML, tive de fazer esta pequena resenha. Como é uma tradução livre, o leitor certamente encontrará incongruências e erros. Favor assinalá-los via mail para o autor .
    UML, ou Unified Modeling Language é a última buzz-word a chegar por estas plagas. O seu charme é a promessa de ser a última e definitiva metodologia de modelagem de sistemas. Outro apelo, é integrar todas as demais expressões (métodos empíricos todos eles) que atestam sua origem "nobre": orientação a objeto,  padrões, GRASP. Sendo posterior a todas elas, promete ser uma maneira de se atualizar sobre todas elas de uma só vez.
    Muitos dos exemplos, foram retirados de telas criadas com Rational Rose 98, uma ferramenta CASE da Rational. Convém mencionar que esta ferramenta não implementa inteiramente o UML, havendo diferenças de notação. Sempre que for o caso, a origem da imagem será indicada.
    Perto do final do semestre descobrimos em [HAR97] referência a outra ferramenta CASE, a SA/Object, disponível em www.popkin.com, mas não conseguimos avalia-la ainda.

    UML pretende:

    1- Modelar sistemas, sejam eles empresas ou softwares, usando conceitos de orientação a objeto.
    2- Estabelecer um acoplamento explícito tanto entre artefatos conceituais como executaveis (reais).
    3- Encaminhar as questões de escala (num intendi...) inerentes em sistemas complexos e/ou de missão crítica.
    4- Criar uma linguagem de modelagem usável por ambos: humanos e máquinas.
 
    Método é uma maneira explícita de estruturar ações e pensamentos. Um método diz o que fazer, como, quando e porque. Métodos contém modelos e estes modelos são usados para descrever algo e comunicar os resultados do uso do método.
    Um modelo é descrito em termos de uma linguagem de modelagem. Uma linguagem é composta por símbolos que compõem uma notação e regras sobre seu uso. Estas regras correspondem a três planos de entendimento:
 

    UML se vale de use cases; diagramas para capturar o requisitos do usuário. Através dos use cases, atores externos são modelados em suas interações com o sistema. Semelhante ao DFD contextual, mas usando bonequinhos de palitos para representar os atores/agentes externos. Não é tão simples assim, mas a semelhança é óbvia.

2) Análise:

    Nesta fase nos preocupamos com as abstrações primárias (classes e objetos)  e mecanismos no domínio do problema. As classes são identificadas e representadas no diagrama de classes. Também são representadas as relações e colaborações entre as classes, de modo que as funcionalidades descritas nos use cases sejam alcançadas. Também se vale dos diagramas dinâmicos (estado, seqüência, colaboração e de atividades).
    Na análise, somente classe do domínio do problema são modeladas. Aquelas que definem detalhes e soluções da implementação de software (interface, comunicação com banco de dados, concorrência, etc..) ficam para outra fase.

3) Projeto:
    Na fase de projeto (design), o resultado da análise é expandido para uma solução técnica. Novas classes são acrescentadas para prover uma infraestrutura técnica: interface, manipulação de dados em um banco de dados, salvamento de arquivos, comunicação com outros sistemas e dispositivos. Nesta etapa as classes da análise são "embutidas" (embedded) nesta infraestrutura técnica, sendo possível alterar ambas independentemente.
    O resultado é uma descrição detalhada para a fase seguinte, de programação.

4) Implementação:
    As classes são convertidas para código real em uma linguagem OO (procedural não é recomendado).

5) Teste:
    Idêntico a qualquer outro método de modelagem. Dividida em testes de unidades, testes de integração, teste de sistema e testes de aceitação.

Em amarelo, os diagramas estáticos. Em verde os dinãmicos.

Diagrama de Use Cases  (amarelos:diagramas estáticos)	Mostra atores externos e suas conecções com os use cases do sistema. Cada use case é a descrição de uma funcionalidade (um uso específico do sistema) que o sistema oferece.
Diagrama de Classes	Um diagrama de classes mostra a estrutura estática das classes. As classes são "as coisas" com as quais o sistema lida. São representadas por retângulos, com o nome da classe em negrito. Classes podem se relacionar umas com as outras de várias maneiras: associação, dependência, especialização ou empacotamento
Diagrama de Objetos	O diagrama de objetos se parece muito com o diagrama de classes, apenas mostra as classes instanciadas como objetos, como um snapshot possível da execução do sistema. A mesma notação é adotada, apenas o nome do objeto é escrito sublinhado.    Diagrama de objetos é utilizado em diagramas de colaboração
Diagrama de Estados verdes:diagramas dinâmicos	O diagrama de estados é tipicamente um complemento do diagrama de classes. Mostra todos os possíveis estados de uma classe e quais eventos causam a mudança de estados. Mudanças de estado são chamadas de transições   Ele é desenhado apenas para aquelas classes que tem um número bem definido de estados e cujo comportamento é mudado pelas transições.   Pode também ser desenhado para o sistema inteiro.
Diagrama de Seqüência	O diagrama de seqüência mostra uma colaboração dinâmica entre objetos. O aspecto mais importante é mostrar uma seqüência de mensagens trocadas entre os objetos. Objetos são descritos como linhas verticais e mensagens como linhas horizontais entre os objetos. A mensagen bifuracada (uma origem, vários destinos aparece em [ERI97], mas o Rose98 não foi capaz de representá-la.
Diagrama de Colaboração	Mostra uma colaboração dinâmica, exatamente como o diagrama de seqüência. Freqüentemente é uma alternativa ao diagrama de seqüência, quando se deseja mostrar os objetos e seus relacionamentos (chamado de contexto). Se o tempo é mais importante, escolhe-se o de seqüencia e caso o contexto seja mais importante, escolha o de colaboração.
Diagrama de Atividades	Mostra uma seqüência de atividades como um grafo, o que permite representar decisões (bifurcações) graficamente, bem como estado inicial e final.
Diagrama de Componente	Traz uma visão interna da estrutura física do código, em termos de componentes. Um componente pode ser um código fonte, um componente binário ou um executável. É um mapeamento entre a visão lógica e a visão de componentes. Dependências entre componentes são mostradas, tornando fácil analizar alterações.
Diagrama de Desenvolvimento/Entrega	Mostra a arquitetura física - hardware e software no sistema. Representa-se os computadores e dispositivos reais e as conecções entre eles.

    São os conceitos (o vocabulário) utilizados nos diagramas. Um elemento de modelo tem uma representação gráfica que o representa nos diagramas.
    São exemplos de elementos: classe, objeto, estado, caso de uso, nó, interface, package, nota, componentes.
    Também os relacionamentos são considerados elementos:  associação, generalização, dependência e agregação.

Notas:
    Uma nota pode ser acrescentada a qualquer diagrama, para lembrar de algo que a linguagem não possa representar. Como a UML e todas as suas predecessoras são abstrações limitadas, muitos detalhes do problema ficam de fora e precisam encontrar seu caminho dentro do projeto acomodadas, por exemplo, em notas acompanhado os diagramas.

Especificações:
    Os elementos de modelo têem propriedades que guardam valores sobre os elementos. Uma propriedade é definida por um valor etiquetado . Existe um certo número de propriedades pré-especificadas: documentação, responsabilidade, persistencia e concorrência.
    Tipicamente, é necessário acrescentar algum texto descritivo, existindo uma janela para este fim para cada elemento de modelo no Rose98.

    UML pode ser extendida para cumprir funções específicas. Em [ERI97] encontramos três exemplos destas extensões, que enriquecem a notação do Rose98:

    Esteriótipos:  é um mecanismo de extensão que traz uma semântica. Baseia-s em todos os elementos  básicos (classe, nós, componentes e notas), bem como nos relacionamentos (associação, generalização e dependência).
    É descrito colocando o seu nome entre << >> (referidos como guillemets, ou angle brackets), ou lhe atribuindo um ícone específico, como o do ator.

    Valores etiquetados: elementos podem ter propriedades que contém pares de nomes-valores, com informação sobre eles. São valores marcados ou valores etiquetados. Qualquer informação pode ser acrescentada nestas etiquetas: informações administrativas, informações específicas do problema, dados para outras ferramentas.
 
    Restrições: Um vínculo restritivo é uma limitação em um elemento, que resulta em limitação na sua associação. Por exemplo: a classe "grupo da terceira idade" relaciona-se com a classe "pessoa", com a restrição de que {idade > 60} (ou 110, para moradores do Caúcaso), ou seja, somente pessoas com mais de 60 anos podem participar da associação (ou funcionários-gerentes, outro exemplo).

Eduardo
UFRGS