A UML é a linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação.
A UML disponibiliza uma forma padrão de modelagem de projetos de Sistemas, incluindo seus aspectos conceituais, tais como processos de negócios e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, processos de banco de dados e componentes de software reutilizáveis.
Histórico
As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de 1970 e o final da década de 1980; À medida que o pessoal envolvido com metodologia, diante de um novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais complexas, começou a experimentar métodos alternativos de análise e projeto. Na metade da década de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de métodos orientados a objetos, começaram a pegar as melhores idéias e partiram para a criação de uma linguagem unificada de modelagem.
- Apesar da UML ser hoje a linguagem padrão para se descrever sistemas orientados a objeto, não é correto se referir à UML como um método para desenvolvimento de software.
- Não se encontra na UML a descrição de passos que se deve seguir para se desenvolver um sistema, nem mesmo quais são as etapas para se modelar um sistema.
- A UML se limita, exclusivamente, a representar um sistema através de um conjunto de diagramas, onde cada diagrama se refere a uma visão parcial do sistema, que em conjunto forma um todo integrado e coerente.
Usos UML
Visualização
Comunicação de modelos conceituais e alguns aspectos de um sistema que não são deduzidos apenas na leitura do código.
Especificação
Construir modelos: precisos, não-ambíguos e completos.
Construção
Não é uma linguagem de programação, mas seus modelos podem ser ligados diretamente a uma.
Documentação
Arquitetura e todos os detalhes documentados, definição de requisitos e testes.
Principais Diagramas
Elementos essenciais
E
lementos Estruturais
Elementos Comportamentais
Elementos de Agrupamento
Elementos de Extensão e Anotação
Conceitos
Pode ser usada para:
Mostrar os limites de um sistema e suas principais funções usando casos de uso e atores;
Ilustrar a realização
de casos de uso, usando diagramas de interação;
Representar a figura
estática de um sistema, usando diagramas de classe;
UML pode ser usada também para:
Modelar o comportamento de objetos com diagramas de estados
Apresentar a implementação física e a arquitetura de um sistema, com diagramas de componentes e diagramas de distribuição;
Criar extensões para a notação, usando estereótipos.
Estudo de Caso: Ponto de Venda
Um sistema para um terminal de ponto de venda (POST)
Usado para registrar vendas e processar pagamentos de clientes em lojas de varejo
Inclui componentes de hardware (computador, leitora de código de barras) e o software para
rodar o sistema
Tarefa: criar o software para um POST
Ênfase
do Estudo de Caso: Camada de Lógica da Aplicação
Descrição de Requisitos
Alguns artefatos básicos:
Visão geral
Sumário descrevendo o propósito geral do projeto
Clientes
Quem encomendou ou está pagando pelo sistema
Objetivos
Objetivos a serem alcançados com o sistema
Funções
O que o sistema deve fazer
Atributos
Aspectos não funcionais
relevantes
Artefatos de Requisitos para o Sistema POST
Visão geral
O propósito deste projeto é criar um sistema para um terminal de ponto de venda a ser usado em lojas de varejo.
Clientes
ObjectStore, Inc., uma cadeia de lojas de venda de componentes de software reutilizáveis.
Objetivos
Redução do tempo de espera dos clientes nos caixas.
Análise rápida e acurada das vendas.
Controle automático de estoque.
Funções básicas
Funções de pagamento
Atributos
A UML permite ao analista representar o sistema seguindo difer entes visões.
Cada visão possui uma grande dependência das outras visões, garantindo assim a coerência e completeza do modelo, e conseqüentemente do sistema de software.
A relação entre os diagramas deve ser garantida pelo projetista, mas não é assegurada pela UML.
Este trabalho estuda a relação entre os diagramas de modo a garantir que o sistema projetado pelo conjunto de diagramas seja coerente.
Os diagramas podem ser agrupados segundo aspectos da visão que proporcionam em:
Diagrama de comportamento externo, que dão uma visão externa do sistema e dos objetivos que os atores externos tem do sistema.
Diagramas estruturais que dão uma visão estática da estrutura de suporte do sistema, sobre a qual ele será construído.
Diagramas de comportamento interno, que tratam dos processos que ocorrem entre as estruturas que compõem o sistema e dão uma visão da dinâmica interna do sistema, e
Diagramas de implementação que descrevem como estas estruturas são implementadas em software e hardware.
A figura a seguir mostra como os diagramas podem se integrar para descrever um sistema. Apesar de não propor um método, existe na UML uma interação forte entre os diagramas como mostra as setas da figura acima. Esta figura não faz parte da UML, mas pode ajudar a navegação entre os diagramas.
Relações entre os diagramas da UML
Casos de Uso
Descrições narrativas de processos do domínio da aplicação
Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início ao fim, um determinado processo;
Representação em UML:
Exemplo de um caso de uso de alto-nível:
Caso de uso:
Atores:
Tipo:
Descrição:
Comprar Itens (Buy Items)
Cliente, Operador primário
Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta o pagamento. Ao final, o Cliente sai com os itens.
A UML não especifica um formato rígido para os cabeçalhos e a estrutura de um caso de uso; Podem ser alterados de acordo com as necessidades de documentação; Exemplo de um caso de uso expandido:
Caso de uso: Comprar Itens com Dinheiro
Atores:
Cliente (Iniciador), Operador
Propósito:
Capturar uma venda e seu pagamento em dinheiro.
Descrição:
Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta um pagamento com dinheiro. Ao final, o Cliente sai com os itens.
Tipo:
primário e essencial
Referencia:
Funções:
R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
|
Típica Seqüência de Eventos Ação do Ator |
Resposta do Sistema |
| 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar. |
2. O Operador registra o identificador de cada item.Se há mais de um do mesmo item, o Operador também pode informar a quantidade.
3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento.Mostra a descrição e o preço do item corrente.
4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou.
5. Calcula e mostra o valor total da venda.
6. O Operador informa o total ao Cliente.
7. O Cliente entrega um paga-mento em dinheiro, possivelmente maior do que o valor total. 8. O Operador registra o valor recebido em dinheiro. 9. Mostra o troco devido.Emite um recibo.10. O Operador deposita o dinheiro e retira o troco devido. O Operador entrega o troco e o recibo ao Cliente.11. Registra a venda no log de vendas completadas.12. O Cliente sai com os itens comprados.
Se complexas, seqüências alternativas podem ser expandidas para formar os seus próprios casos de uso.
Atores
Entidades externas ao sistema que de algum modo participam da estória do caso de uso
Estimulam o sistema com eventos de entrada, ou recebem alguma coisa dele;
Designados pelo papel que exercem no caso de uso
Ex: Cliente, Operador, etc.
R
epresentação em UML:
Um caso de uso possui um ator iniciador, que gera o estímulo inicial, e possivelmente vários atores participantes
O ator iniciador deve ser indicado explicitamente na descrição do caso de uso
Algumas categorias típicas de atores incluem:
Papéis exercidos por pessoas
Sistemas de computação
Dispositivos elétricos e mecânicos
Identificando Casos de Uso
Normalmente não são eventos ou passos individuais, mas um processo completo;
Erro mais comum!
Método baseado em atores
1. Identificar os atores relacionados com o sistema ou organização
2. Para cada ator, identificar os processos que eles iniciam ou participam;
Método baseado em eventos
1. Identificar os eventos externos aos quais o sistema deve responder
2. Relacionar os eventos a atores e casos de uso
Exemplos do sistema POST
Operador:
Login,
Retirar Dinheiro;
Cliente:
Comprar Itens,
Devolver Itens;
Casos de Uso e Funções
Todas as funções do sistema identificadas na especificação dos requisitos devem ser alocadas a casos de usos
Idealmente, funções e casos de uso devem ser rastejáveis até a implementação e teste do sistema;
Um caso de uso descreve um objetivo que um ator externo ao sistema tem com o sistema.
Um ator pode ser um elemento humano ou não que interage com o sistema. O ator se encontra fora do escopo de atuação
do sistema, enquanto o conjunto de casos de uso formam o escopo do sistema.
A linha que separa os atores dos casos de uso é a fronteira do sistema.
O diagrama de casos de uso representa graficamente esta interação, e define o contexto do sistema.
Os atores são representados por representações simplificadas de uma figura humana, enquanto os casos de uso são elipses contendo cada uma o nome de um caso de uso. Os atores se comunicam com os casos de uso, que é representado por uma linha unindo os dois elementos.
Uma seta pode, opcionalmente, representar o fluxo principal de informação nesta interação e ajudar a leitura do caso de uso.
Como os casos de uso representam um objetivo do ator é comum dar como nome aos casos de uso frases verbais curtas no infinitivo (EmprestarMaterial) ou no gerúndio ( EmprestandoMaterial) onde o sujeito é normalmente o ator. Ex:
O usuário empresta material
O usuário pesquisa assunto
Cada caso de uso deve receber uma descrição textual que permita o entendimento do objetivo. Esta descrição pode ser detalhada em cenários.
Um cenário é uma instância de um caso de uso, isto é, é uma situação onde o ator utilizou o sistema para conseguir atingir o objetivo do caso de uso. Um cenário pode ser considerado otimista de o ator obteve sucesso no seu objetivo, pode ser pessimista se o ator não conseguiu e ocorreu uma situação de exceção.
Ou o cenário pode ser alternativo, quanto frente a uma situação de exceção o ator optou por caminhos alternativos.
Assim para cada caso de uso pode se descrever um texto com:
Cenários Otimistas
Cenários Pessimistas
Cenários Alternativos
Diagramas de Caso de Uso ilustram um conjunto de casos de uso e atores para um sistema e os relacionamentos entre eles
Diagrama parcial para o sistema POST:
Casos de Uso e o Limite do Sistema
Exemplo de um diagrama de caso de uso para o sistema POST, quando o limite de atuação é a loja inteira:
Casos de Uso no
Processo de Desenvolvimento
Passos da fase de Planejamento e Elaboração
1. Após as funções do sistema terem sido descritas, defina o limite de atuação do sistema e identifique atores e casos de uso.
2. Escreva todos os casos de uso
3. Desenhe um diagrama de caso de uso.
4. Relacione casos de uso e ilustre seus relacionamentos no diagrama de
caso de uso.
5. Escreva os casos de uso mais importantes ou críticos no formato expandido essencial.
6. Se estritamente necessário, escreva alguns casos de uso no formato real.
7. Ordene os casos de uso por prioridade de desenvolvimento.
Passos da fase de Construção
1. Análise — Escreva casos de uso expandidos essenciais para aqueles sendo atacados no ciclo de desenvolvimento corrente, se ainda não feito.
2. Projeto — Escreva casos de uso reais para aqueles sendo atacados no ciclo de desenvolvimento corrente, se ainda não feito.
Passos do Processo para o Sistema POST
Identificar atores e casos de uso
Passos do Processo para o Sistema POST
Escrever casos de uso no formato alto-nível
| Caso de uso: |
Comprar ItensAtores:Cliente (Iniciador), Operador
Tipo:
primário
Descrição:
Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta o pagamento. Ao final, o Cliente sai com os itens.
Caso de uso:
Inicializar (Start Up)
Atores:
Gerente (Manager)
Tipo:
primário
Descrição:
Um Gerente liga um POST para ser usado pelos Operadores. O Gerente certifica-se de que a data e hora estão corretos, após o que o sistema está pronto para uso.
Desenhar diagrama de caso de uso
Priorizando Casos de Uso
Atacar primeiro aqueles com maior influência na estrutura básica do sistema
Características que podem aumentar a prioridade de um caso de uso:
Impacto significativo no projeto da arquitetura;
Funções complexas, arriscadas, ou de tempo crítico;
Envolve novas pesquisas ou tecnologia emergente;
Representa processos primários de negócio;
Contribui diretamente para aumentar lucros ou diminuir custos;
Ordenação baseada em classificação simples de prioridades (ex: alta-média-baixa)
Diagramas de Classe
Um diagrama de classe ilustra as especificações de software para as classes e interfaces do sistema
Inclui:
Classes, associações e atributos;
Interfaces (com operações e constantes)
Métodos
Informação sobre o tipo dos atributos
Navegabilidade
Dependências
Diagrama parcial para as classes POST e Venda no sistema POST:
Modelo de Conceitual X Diagrama de Classe
Modelo conceitual: abstração de conceitos do mundo real
Diagrama de classe: especificação de componentes de software
Os diagramas de classe descrevem as classes que formam a estrutura do sistema e suas relações.
As relações entre as classes podem ser associações, agregações ou heranças.
As classes possuem além de um nome, os atributos e as operações que desempenham para o sistema.
Uma relação indica um tipo de dependência entre as classes, essa dependência pode ser forte com no caso da herança ou da agregação ou mais fraca como no caso da associação, mas indicam que as classes relacionadas cooperam de alguma forma para cumprir um objetivo para o sistema.
Sendo uma linguagem de descrição, a UML permite diferentes níveis de abstração aos diagramas, dependendo da etapa do desenvolvimento do sistema em que se encontram.
Os diagramas de classe podem exibir nas fases iniciais da análise apenas o nome das classes, e em uma fase seguinte os atributos e operações (como mostra a figura abaixo).
Finalmente, em uma fase avançada do projeto pode exibir os tipos dos atributos, a visibilidade, a multiplicidade das relações e diversas
restrições.
Ex:
O diagrama de classes, ao final do processo de modelagem, pode ser traduzido em uma estrutura de código que servirá de base para a implementação dos sistemas.
Observa-se, no entanto, que não existe no diagrama de classes uma informação sobre os algoritmos que serão utilizados nas operações, e também não se pode precisar a dinâmica do sistema porque não há elementos sobre o processo ou a seqüência de processamento neste modelo.
Estas informações são representadas em outros diagramas, como os diagramas de seqüência de eventos ou diagramas de estado.
Diagramas de Interação
Um diagrama de interação ilustra as interações de mensagens entre instâncias (e classes) no modelo de classes
Atribuição de responsabilidades aos objetos
Ponto de partida é o cumprimento das pós-condições especificadas nos contratos de operação
A UML define dois tipos (equivalentes) de diagramas de interação:
Diagramas de colaboração – Ilustra interações num formato de grafo ou rede
Diagramas de seqüência – Ilustra interações num formato de colunas
Diagramas de Seqüência
Um diagrama de seqüência ilustra a ordem das interações dos atores externos com o sistema
(representado como uma “caixa-preta”) e os eventos que eles geram.
Os casos de uso, como vimos, representam um conjunto de cenários que descrevem os diferentes processos que ocorrem no sistema.
O diagrama de seqüência de eventos permite modelar estes processos através da troca de mensagens (eventos) entre os objetos do sistema.
Os objetos são representados por linhas verticais e as mensagens como setas que partem do objeto que invoca um outro objeto.
As setas podem ser cheias para indicar uma mensagem de chamada ou tracejadas para indicar uma mensagem de retorno.
Devem ser desenhados tantos diagramas de seqüência quantos cenários foram levantados no diagrama de casos de uso.
Cada mensagem no diagrama de seqüência de eventos corresponde a uma operação no diagrama
de classes.
Como as mensagens são operações invocadas, elas devem estar presentes nos objeto de destino, que são ativadas pelas mensagens no objeto de origem.
Diagramas de Colaboração
Os diagramas de colaboração possuem essencialmente, a mesma informação que um diagrama
de seqüência de eventos, mas que é apresentada de uma outra forma.
Este diagrama também mostra as mensagens sendo trocadas entre as classes, mas agora em um
diagrama onde são apresentados os relacionamentos entre as classes, servindo de caminho para as mensagens.
Os diagramas de colaboração também servem para descrever os cenários identificados pelos casos de uso, e podem ser traçados em conjunto com o diagrama de classes.
Ex:
A figura mostra um diagrama de colaboração e nele vemos a numeração utilizada para facilitar a leitura e identificar a ordem em que as mensagens são trocadas.
A numeração decimal indica a seqüência de uma mensagem e os símbolos -> e <- a direção. Os diagramas de colaboração mostram o processo que não aparece nos diagramas de classe.
Diagrama de Estados
Os diagramas de transição de estados mostram a dinâmica interna de uma classe. Apenas os eventos e estados de uma única classe são apresentados neste diagrama.
Entende-se por eventos os fatos que ocorrem em uma classe, provocados por elementos externos (mensagens) ou internos como condições internas da classe que provocam uma troca de estado.
Uma classe pode ter vários estados, caracterizados por situações em que a classe se encontra.
O diagrama de estados pode possuir ainda estados especiais como o estado inicial e o estado final e outros estados de controle internos.
Exemplo:
Analogamente ao diagrama de classes é possível se extrair um código executável de um diagrama de estados, em uma linguagem de programação. Identificando condições, laços de repetição e chamadas de operações internas ou externas (mensagens) nos estados de espera e nas transições de estado (eventos).
Diagrama de Componentes
Os diagramas de componentes mostram os elementos reutilizáveis de software e sua interdependência. Um componente é formado por um conjunto de classes que se encontram implementadas nele. Um componente, assim como as classes que ele possui, dependem funcionalmente das classes de outro componente.
O diagrama de componentes mostra esta dependência. No diagrama de componentes também é possível mostrar a configuração de um sistema de software mostrando, graficamente, a dependência entre os diversos arquivos que compõem o sistema.
Diagrama de Distribuição
Os diagramas de distribuição mostram a distribuição de hardware do sistema, identificando os servidores como nós do diagrama e a rede que relaciona os nós. Os componentes de software vão estar mapeados nestes nós.
BIBLIOGRAFIA
Furlan, José Davi. Modelagem de Objetos através da UML- the Unified Modeling Language. São Paulo: Makron Books, 1998.
Deboni, José Eduardo Zindel. Tutorial de UML, SUCESU- SP COMDEX, 98. (Publicado na internet em www.voxxel.com.br/tutuml) 1998.
Deboni, José Eduardo Zindel. Modelando a Web com a UML. Apresentado no Objetos Distribuidos 99. São Paulo. (publicado na internet em www.voxxel.com.br/webuml) 1999.