UML - Unified Modeling Language

Importância da Modelagem

  • Um modelo é uma simplificação da realidade

  • Construímos modelos para compreender melhor o sistema que estamos desenvolvendo

  • Objetivos alcançados com a modelagem

    • Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja

    • Os modelos permitem especificar a estrutura ou o comportamento de um sistema

    • Os modelos proporcionam um guia para a construção do sistema

    • Os modelos documentam as decisões tomadas.

  • Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade

Princípios da Modelagem

  • A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida

  • Cada modelo poderá ser expresso em diferentes níveis de precisão

  • Os melhores modelos estão relacionados à realidade

  • Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes

UML - Linguagem Unificada de Modelagem (Unified Modeling Language)

A UML é uma linguagem de modelagem com as seguintes características:

  • Absorveu influências de outras técnicas de modelagem :

    • Diagrama de Entidade e Relacionamento - DER

    • Modelagem de Negócio - WorkFlow

    • Modelagem de Objetos e Componentes

  • Incorporou idéias de diversos autores :

    • Peter Coad, Derek Coleman, Ed Yourdon,...

  • Criada a partir de outras ferramentas de modelagem

    • Booch´93

    • OMT-2

    • OOSE

  • Linguagem-padrão para a elaboração da estrutura de projetos de software.

  • Enfoque Orientado a Objetos

  • Utilizada para Visualizar, Especificar, Construir e Documentar artefatos que modelem sistemas de software.

  • UML é apenas uma linguagem de modelagem, não uma metodologia para desenvolvimento de sistemas.

  • Baseada em Diagramas (Ênfase Visual), onde vários aspectos fundamentais na modelagem de Sistemas são abordados, tais como : Funcional (estrutura estática e interação dinâmica), não funcional (tempo de processamento, confiabilidade, produção) e organizacional (organização do trabalho, mapeamento e código). Cada visão é descrita em um número de diagramas que contém informações enfatizando um aspecto em particular. Analisando o Sistema através de visões diferentes, é possível se concentrar em um aspecto de cada vez.

Diagramas da UML

  • Casos de uso (Use Cases) : Modelam o comportamento geral do Sistema, através dos relacionamentos com atores externos.

  • Classes : Modela classes, interfaces e seus relacionamento, representando uma visão estática da estrutura do Sistema.

  • Interação : modelam uma especificação comportamental representando a troca de mensagens entre objetos, em UML os Diagramas de Interação são representados por Diagrama de Sequência e Diagrama de Colaboração.

    • Sequência : modela a interação entre objetos através de seus relacionamentos e troca de mensagens. Demonstram a dinâmica do Sistema com ênfase na ordenação temporal das mensagens.

    • Colaboração : Semelhante ao diagrama de Sequência, sendo que sem observar a ordenação temporal das mensagens.

  • Estados : Modela uma máquina de estados, formado por : estados, transições e eventos

  • Atividades : Tipo especial de Diagrama de Gráfico de Estado

  • Diagramas de Implementação : Modelam a arquitetura lógica e física do hardware e software que implementam o Sistema.

    • Componentes : Exibe a organização e dependências existentes em um conjunto de componentes do Sistemas (Programas fontes, objetos, executáveis e bibliotecas)

    • Implantação : Mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes.

Casos de Uso (Use Cases)

Um caso de uso é um documento narrativo que descreve a sequência de eventos de um ator (agente externo) que usa um Sistema para completar um processo[Jacobson92]. Eles são histórias ou casos de utilização de um Sistema.

Casos de uso não são exatamente especificações de requisitos ou especificações funcional, mas ilustram e implicam requisitos na história que eles contam.

Figura (CasoDeUso)

Caso de Uso

Comprar Itens

Atores

Cliente, Caixa

Descrição

Um Cliente chega a um ponto de pagamento, com vários itens que deseja comprar. O Caixa registra os itens de compra, informa o total da compra ao cliente e recebe o pagamento.

Os detalhes dos casos de uso não são formalizados pela UML e podem ser adequados para satisfazer as necessidades e o espírito de documentação necessários (clareza de comunicação).

Os casos de uso podem ser detalhados através de uma Sequência Típica de Eventos

Sequência Típica de Eventos

Ação do Ator

Resposta do Sistema

1. Este caso de uso começa quando um Cliente chega a um ponto de pagamento (Equipado com um Post) com vários itens que deseja comprar.

2. O Caixa registra o código de cada item

Se houve mais de um exemplar do mesmo item, o Caixa também pode entrar a quantidade

3. Determina o preço do item e acrescenta a informação sobre o item à transação corrente de venda.

4. Ao término da entrada de itens, o Caixa indica ao POST que a entrada de itens está completa

5. Calcula e apresenta o total da venda

6. O Caixa informa ao Cliente o total da compra

7. O Cliente dá um pagamento em dinheiro, possivelmente maior que o total da venda

8. O Caixa registra o montante de dinheiro recebido

9. Exibe o valor do troco a ser devolvido ao Cliente

10. O Caixa deposita o dinheiro recebido e retira o troco

11. Registra a venda completada

12. O Cliente sai com os itens comprados

Diagrama de Casos de Uso

Fornecem a visão externa do Sistema e suas interações com o mundo exterior, representando um visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário, ou seja modela o comportamento geral do Sistema. O Sistema é visto como uma caixa preta, onde nesse momento não é importante compreender como o sistema implementa os casos de uso ou como ocorre o funcionamento interno.

O propósito primário dos casos de uso são :

  • Descrever os requerimentos funcionais do sistema de maneira consensual entre usuários e desenvolvedores de sistemas;

  • Fornecer uma descrição consistente e clara sobre as responsabilidades que devem ser implementadas pelo Sistema, além de formar a base para a fase de desenho;

  • Oferecer as possíveis situações do mundo real para o teste do Sistema.

Os elementos básicos de um caso de uso são:

  • Ator : entidade externa ao sistema que, de alguma maneira, participa da história do caso de uso;

  • Caso de uso

  • Interação : 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 que um ator envia sua mensagem (estímulo);

  • Sistema : Domínio do problema modelado.

Arquivo Rose

CursoDeUML\DiagramaDeCasoDeUso\DiagramaDeCasoDeUso.mdl

Elementos Básicos

Caixa Eletrônico

Venda

Diagrama de Classes

São os diagramas mais importantes na modelagem orientada a objetos e representam a essência da UML. Um diagrama de classe mostra um conjunto de classes, interfaces, colaborações e seus relacionamentos, fornecendo uma visão estática do Sistema. Os diagramas de classes são importantes não só para visualização, especificação e documentação de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio da engenharia de produção de software.

Os elementos básicos de um diagrama de classes são:

  • Classes

  • Interfaces

  • Relacionamentos de associação, dependência, generalização/especialização e agregação (todo/parte)

Arquivo Rose

\CursoDeUML\ClientePedidoProduto\ClientePedidoProduto.mdl

Classe - Tipo abstrato formado por atributos e métodos.

Pacote - estrutura organizacional que agrupa elementos do diagrama de classes com o objetivo de melhor organizá-los

Arquivo Rose

\CursoDeUML\Classe\Classe.mdl

Interfaces - Tipos especial de classes possuindo apenas definições de métodos e/ou constantes.

Arquivo Rose

\CursoDeUML\Interface\Interface.mdl

Relacionamentos :

Associação - é um relacionamento estrutural, especificando que os objetos de uma classe estão conectados/vinculados a objetos de outra classe. Numa associação podem ser especificados os seguintes itens : um nome, o papel e multiplicidade em cada extremidade da associação, navegação e qualificação.

Dependência - indica a ocorrência de um relacionamento semântico entre dois elementos do modelo, onde uma classe cliente é dependente de serviços de uma classe fornecedora, mas não existe uma dependência estrutural interna com esse fornecedor. Indica que uma alteração na especificação de uma classe poderá afetar outra classe que a utilize, mas não necessariamente o inverso. A forma mais comum de dependência é quando uma classe utilizar parâmetros de uma outra classe em seus métodos.

Arquivo Rose

\CursoDeUML\Associação\ Associação.mdl

Agregação - é uma forma especial de associação utilizada para mostrar que um tipo de objeto é composto, pelo menos em parte, de outro em uma relação todo/parte. Indicando que o objeto parte "é um atributo" do objeto todo, onde o ciclo de vida do objeto parte é limitado ao ciclo de vida do objeto todo.

Arquivo Rose

\CursoDeUML\Agregação\ Agregação.mdl

Generalização/Especialização - Representa o conceito de herança da orientação a objetos e indica que uma classe estende outra.

Arquivo Rose

\CursoDeUML\Generalização\ Generalização.mdl

Classe de Associação - elemento da modelagem que tem associação e propriedades de classe, podendo ser vista tanto como uma associação que tem propriedades de classe, como uma classe que tem propriedades de associação. Apesar de ser desenhada como uma associação e uma classe, é apenas um único elemento do modelo e tem apenas um nome.

Arquivo Rose

\CursoDeUML\ClasseAssociação\\ClasseAssociação.mdl

Diagrama de Sequência

Diagrama de Colaboração

Arquivo Rose

\CursoDeUML\DiagramaDeInteração\ DiagramaDeInteração.mdl

Diagrama de Estados

Um diagrama de gráfico de estados mostra uma máquina de estados, dando ênfase ao fluxo de controle de um estado para outro. Uma máquina de estados é um comportamento que especifica as sequências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com suas respostas a esses eventos. Um estado é uma condição ou situação na vida de um objeto durante a qual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algum evento. Um evento é uma especificação de uma ocorrência significativa para o objeto. No contexto de uma máquina de estados, um evento é uma ocorrência de um estímulo capaz de ativar uma transição de estado de um objeto. Uma transição de estado é um relacionamento entre dois estados, indicando que um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento específico ocorrer e as condições especificadas estiverem satisfeitas.

Tem como objetivo principal prover uma definição formal explícita de comportamento, permitindo uma verificação dos eventos e transições de estados aos quais um Sistema está sujeito. A existência de estados em um objeto implica que a ordem na qual as operações são executadas é importante, o que leva à idéia de objetos como máquinas independentes. Assim, para cada objeto, a ordem das operações no tempo é tão importante que pode-se formalizar a caracterização do comportamento de um objeto em termos de uma máquina de estado finita equivalente.

Uma desvantagem do diagrama de estado é ter de definir todos os possíveis estados de um Sistema, impossibilitando o seu para todo o Sistema, dessa forma, o Diagrama de Estados é utilizado para modelar apenas algumas situações.

Arquivo Rose

\CursoDeUML\DiagramaDeEstados\ DiagramaDeEstados.mdl

Diagrama de Atividade

Um Diagrama de Atividade é essencialmente um gráfico, mostrando o fluxo de controle de atividades (semelhante a um Fluxograma). Enquanto o Diagrama de Interação possui foco no relacionamento (troca de mensagens) entre objetos, o Diagrama de Atividade possui o foco nas Atividades. Uma atividade é uma execução não atômica em andamento em uma máquina de estado. As atividades ainda podem ser agrupadas em "Swimlanes" (Raias de natação) com o objetivo de mostrar em qual parte da organização um trabalho é executado ou mostrar explicitamente onde são encontradas ações (em qual objeto)

Arquivo Rose

\CursoDeUML\DiagramaDeAtividades\ DiagramaDeAtividades.mdl

Diagrama de Componentes

Arquivo Rose

\CursoDeUML\DiagramaDeComponentes\ DiagramaDeComponentes.mdl

Diagrama de Implantação

Arquivo Rose

\CursoDeUML\DiagramaDeImplantação\ DiagramaDeImplantação.mdl

Outros Tópicos

Estereótipo

Mecanismo para estender o vocabulário da UML, que permite a criação de novos tipos de blocos de construção derivados dos já existentes, mas que são específicos a determinado ambiente.

Nota e Ligação de Nota

Comentário colocado em componente gráfico para descrever elementos da UML

Arquivo Rose

\CursoDeUML\Estereótipo_e_Nota\ Estereótipo_e_Nota.mdl

Contratos

Documento que descreve o que uma operação se compromete a fazer. Usualmente, ele segue um estilo declarativo, enfatizando o que acontecerá, em vez de como será conseguido. É comum os contratos serem expressos em termos de mudanças de estado definidas por pré-condições e pós-condições. Um contrato pode ser escrito para um método individual de uma classe ou para uma operação mais abrangente do Sistema.

Contrato

Nome

entrarItem(código: String, quantidade : int)

Responsabilidade

Entrar (registrar) a venda de um item e acrescentá-lo à venda.

Exibir a descrição e o preço do item

Notas

Use acesso rápido ao Banco de Dados

Exceções

Se o código não for válido, indique erro

Saída

Pré-Condições

O código deverá ser válido

Pós-Condições

  • Se for uma nova Venda, uma Venda foi criada (criação de instância)

  • Se for uma nova Venda, a nova Venda foi associada ao Post (Formada uma associação)

  • Uma LinhaDeItemDeVenda foi criada (criação de instância)

  • A LinhaDeItemDeVenda foi Associada à Venda (Formada uma associação)

  • LinhaDeItemDeVenda.quantidade recebeu o valor quantidade (Modificação de atributo)

  • A LinhaDeItemDeVenda foi associada a uma EspecificaçãoDeProduto, baseada numa correspondência com o código (Formada Associação)

RationalRose 2000

Tools/Options

Editando

Use Case View

Logical View

Component View

Deployment View

Tools/Java/Project Specification

Tools/Java/Generate Java

Tools/Java/Reverse Engineer Java

Tools/Web Publisher

Estudo de Caso - Supermercado

Arquivo Rose

\CursoDeUML\EstudoDeCaso\Supermercado\Supermercado.mdl

Fontes Java

\CursoDeUML\EstudoDeCaso\Supermercado\Supermercado.jpr

25

Comentários