UML - Principais diagramas da linguagem

Uma grande parte dos desenvolvedores de software geralmente torcem o nariz para o trabalho de análise do projeto de software partindo diretamente para o trabalho de codificar, pois afinal, como dizem , isto é o que realmente importa.

Esta visão romântica e suicida hoje em dia não tem futuro. Devido ao aumento da complexidade dos projetos de software realizar um planejamento profundo do projeto é crucial. O cliente precisa entender o que o desenvolvedor esta fazendo e precisa ter condições de indicar alterações nas funcionalidades do projeto. Para isso é necessário um canal de comunicação onde a linguagem usada seja compreensível pela equipe de desenvolvimento e pelo cliente. A chave para este processo ser bem sucedido é organizar o processo de desenvolvimento de forma a envolver programadores, analistas e clientes no desenvolvimento do sistema usando uma linguagem que seja de fácil entendimento a todos.

Para isto é preciso adotar uma linguagem padrão que seja aceita e compreendida por toda a equipe de desenvolvimento e pelo cliente. A UML tem sido adotada como esta linguagem padrão.

A UML consiste de um certo número de elementos gráficos que se combinam para formar diagramas. Como a UML é uma linguagem, ela possui regras para combinar estes elementos nos diversos diagramas.

Nota: Para saber mais sobre UML acompanhe os artigos : UML - Unified Modeling Language e UML - Modelando sistemas - Casos de Uso

O objetivo dos diagramas é apresentar múltiplas visões do sistema sendo que este conjunto de múltiplas visões é chamado de modelo. Podemos dizer que um modelo UML pode ser visto como um conjunto de diagramas que podem ser examinados e modificados a fim de compreender e desenvolver um sistema de software.

Um modelo UML descreve o que o sistema fará mas não diz nada como implementar o sistema.

Vejamos a seguir os diagramas da UML:

Uma classe é uma categoria ou grupo de elementos(coisas) que possuem o mesmo atributo e comportamento. Nesta linha de raciocínio a classe máquina de lavar roupa conterá elementos que possuem atributos como nome, modelo, número de série e capacidade e deverá apresentar comportamento que inclui as operações como: "aceitar roupas", "aceitar sabão" , "ligar", "desligar".

Vamos aplicar a notação UML através dos seus diagramas a uma máquina de lavar roupa que é um objeto da classe máquina de lavar roupa.

1- Diagrama de Classes:

A notação UML que captura os atributos e comportamentos de um máquina de lavar roupa é mostrada a seguir e chama-se diagrama de classe. O retângulo é o desenho que representa a classe e ele esta dividido em três áreas :

1- A parte superior contém o nome da classe2- A parte do meio contém os atributos da classe3- A parte de baixo contém as operações(métodos) da classe   

O diagrama de classes permite aos analistas usarem uma notação de fácil compreensão pelo cliente estimulando-os desta a forma a revelar detalhes importantes sobre o problemaque necessita ser resolvido.

2- Diagrama de Objeto

Um objeto a é uma instância de uma classe - um elemento específico que possui valores dos atributos da classe. No caso da lavadora poderíamos ter os seguintes valores:

NomeWesthinghouse

Modelo Master

Número de Série

MLV05245

Capacidade 8 Kg

A UML representa um objeto usando o diagrama da figura abaixo. Um retângulo representa o objeto, e o nome é sublinhado. Podemos ainda ter duas variações:

a- O nome da instância específica do objeto, dois pontos seguido do nome da classe

b- dois pontos seguido do nome da classe. Neste caso temos um objeto anônimo, i.e, não é fornecido um nome para o objeto mas mostramos a classe a qual ele pertence.

1- nome do objeto: nome da classe 2- Objeto Anônimo

3- Diagrama de caso de uso

Um caso de uso é a descrição do comportamento do sistema do ponto de vista do usuário. Para os desenvolvedores os casos de uso são uma ferramenta muito útil pois ele pode ser considerado uma técnica do tipo tentativa e erro para obter os requisitos do sistema a partir do visão do cliente.

A seguir temos a representação UML para o caso de uso Lavar roupas:

- A figura que representa o usuário é chamado ator. O ator é a entidade que inicia o caso de uso e pode ser uma pessoa ou outro sistema.

- A elipse representa o caso de uso , no exemplo: Lavar Roupas.

Observe que o caso de uso esta no interior de um retângulo que representa o sistema e o ator esta fora do retângulo.

Caso de uso: Lavar Roupas

4- Diagrama de estado

Em um determinado momento um objeto possui um estado particular. No caso de uma pessoa ela pode ser: recém-nascida, criança, adolescente ou adulto. Uma máquina de lavar pode possuir os seguintes estados: colocar em molho, lavar , enxaguar e centrifugar ou desligar.

A representação UML que captura este comportamento chama-se diagrama de estado e esta representado abaixo:

O símbolo no topo da figura representa o inicio do estado e o símbolo na base da figura representao fim do estado.

As transições de um estado para outro nem sempre são lineares como representado para este exemplo.

4- Diagrama de seqüência

O diagrama de classe e o diagrama de objeto representam uma informação estática. Em um sistema funcional , no entanto, os objetos interagem uns com os outros, e , estas interações ocorrem a todo momento. O diagrama de seqüência UML é usado para representar estas interações e é composto basicamente por objetos e mensagens.

Um diagrama de seqüência descreve a maneira como os objetos colaboram em algum comportamento ao longo do tempo e registra o comportamento de um único caso de uso. Esse diagrama é simples e lógico, com o objetivo de óbvios a seqüência e o fluxo de controle.

Continuando com o exemplo da máquina de lavar roupa podemos identificar os seguintes componentes na máquina: (Podemos considerar estes componentes como objetos)

O Timer A Bomba d'agua (que introduz a água na máquina) O Tambor (onde são colocadas as roupas)

Vejamos então o que acontece quando invocamos o caso de uso "Lavar Roupas", assumindo que já tenhamos incluído as roupas na

máquina, o sabão e a mesma tenha sido ligada. Podemos descrever a seguinte seqüência de operações: (São apenas considerações)

1. No ínicio da operação "Colocar de Molho", a água entra no Tambor pela Bomba d'agua;

2. O Tambor permanece estacionário por 5 minutos aproximadamente; 3. No final da operação "Colocar de Molho" a água para de entrar no

Tambor; 4. No início da operação "Lavar" o Tambor inicia a rotação

alternada por 15 minutos; 5. No final da operação "Lavar" o Tambor joga a água com sabão

para fora; 6. O Tambor para a sua rotação; 7. No início da operação "Enxaguar" a água começa a entrar novamente

no Tambor 8. O tambor inicia a rotação alternada; 9. Depois de 15 minutos a água para de entrar no Tambor; 10. No final da operação o Tambor joga a água para fora; 11. O Tambor pára de efetuar a rotação alternada; 12. No início da operação "Centrifugar" o Tambor inicia a rotação

continua no sentido horário por 15 minutos; 13. No final da operação "Centrifugar" o Tambor para de efetuar a

rotação; 14. A lavagem de roupas esta completa

Assumindo que o timer, a bomba d'agua e o tambor são objetos e que cada objeto possui uma ou mais operações podemos perceber que estes objetos trabalham em conjunto enviando mensagens uns para os outros para que a tarefa seja realizada com êxito.

A seguir vamos definir as operações nas quais atuam cada objeto :

a- O Timer

tempo de molho (Colocar de Molho); tempo de lavagem (Lavar); tempo de enxugamento (Enxugar); tempo de centrífuga (Centrifugar);

b- A bomba d'agua

Iniciar o fluxo de água; Parar o fluxo de água;

c- O Tambor

Armazenar água; Rotacionar alternadamente; Rotacionar no sentido horário; Parar de rotacionar; Jogar água para fora;

A seguir temos o diagrama de seqüência que captura as mensagens entre os objetos : Timer, Bomba d'gua e o Tambor. Cada seta representa uma mensagem que é enviada de um objeto para outro. O tempo transcorre do topo para a base do diagrama, sendo exibida em seqüência as mensagens trocadas ao longo do tem po.

- O objeto Timer envia mensagens para ele mesmo

5- Diagrama de Atividades

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como um atividade depende uma da outra.

A seguir temos o diagrama de atividades representando as atividades do objeto Tambor da máquina de lavar descrita nos passos 4 a 6:

As atividades que ocorrem dentro do caso de uso ou no comportamento do objeto ocorrem em uma seqüência conforme descritos no item anterior.

6- Diagrama de Comunicação

Os elementos do sistema trabalham em conjunto para cumprir os objetos do sistema e um linguagem de modelagem precisa poder representar esta característica. O diagrama de comunicação procura capturar este comportamento. O diagrama mostrado a seguir procura mostrar as mensagens trocadas entre o objeto timer, a bomba d'agua e o tambor. O digrama mostra a ordem das mensagens usando uma numeração para indicar a sua ordem.

Os diagramas de seqüência e de comunicação mostram as interações entre os objetos, por este motivo a UML se refere as estes diagramas como diagramas de interação.

7- 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 nele implementadas. 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." (VOXXEL). As relações de dependência são usadas nos diagramas de componentes para indicar os diversos arquivos que compõe o sistema.

A UML reconhece cinco estereótipos de componentes:

Um executável: Um componente que pode ser executado (um programa).

Uma biblioteca: Uma biblioteca de classes ou funções, dinâmica ou estática.

Um tabela: Uma tabela de um banco de dados. Um documento: Uma parte da documentação (texto livre,

diagramas, documentos de ajuda, etc.) Um arquivo: Outros arquivos, geralmente, se trata de um arquivo de

código fonte, mas pode ser também um arquivo de dados, um ``script'' ou outros arquivos.

Exemplo de um diagrama de componente exibindo os componentes para um sistema de locadora na web :

8- 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". (VOXXEL)

Ele permite apresentar a topologia de uma rede de máquinas'' e qual processo (um componente executável) cada máquina'' vai rodar. As maquinas'' são chamadas de nos. Um nó apresenta uma fonte computacional, sendo normalmente um processador com alguma memória.

A UML é uma importante ferramenta de modelagem , através dela podemos obter diversas visões de um sistema de software. Neste artigo procurei apresentar os principais diagramas usados na UML de forma a que você tenha uma visão geral de sua utilização.

Modelando Sistemas em UML - Casos de Uso

Neste artigo vou falar um pouco sobre modelagem de sistemas usando UML focando exclusivamente os diagramas de casos de uso .

A primeira coisa que devemos ter em mente que os princípios aqui discutidos não se referem a uma linguagem específica ; estamos focando é claro a análise orientada a objetos onde conceitos como encapsulamento de atributos e métodos , alta coesão e baixo acoplamento , herança e polimorfismo devem esta bem assimilados.

Vamos usar a UML que é um modelo de linguagem que define uma notação que são todos os elementos de representação gráfica vistos no modelo.

Estamos pois na fase de análise e não estamos preocupados com software nem hardware.

Caso de Uso - definições

Segundo Ivan Jacobson , podemos dizer que um caso de uso é  um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo".

Um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistema deve fazer . Ele é construído através de um processo interativo no qual as discussões entre o cliente e os desenvolvedores do sistema conduzem a uma especificação do sistema da qual todos estão de acordo.

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 têm que ser compreensíveis por usuários por que só eles sabem o que o sistema precisa fazer. Os casos de uso permitem verificar se o desenvolvedor e o usuário concordam sobre o que o sistema deve fazer. Isso é um problema importante no desenvolvimento de software. No mesmo tempo, casos de uso podem servir de "contratos'' entre os usuários e a equipe de desenvolvimento.

Os casos de usam tem por objetivo :

Decidir e descrever os requisitos funcionais do sistema. Fornecer uma descrição clara e consistente do que o sistema deve fazer. Permitir descobrir os requisitos funcionais das classes e operações do

sistema. (Casos de uso NÃO são requisitos)

Podemos dizer que os componentes de um modelo de casos de uso são :

Ator - é um papel que tipicamente estimula/solicita ações/eventos do sistema e recebe reações. Cada ator pode participar de vários casos de uso

Casos de uso - documento narrativo que descreve a seqüência de eventos feitos por um ator no uso do sistema.

Sistema - O sistema a ser modelado

Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os atores , os casos de uso e seus relacionamentos. Os elementos gráficos que representam atores, casos de uso e sistema são mostrados abaixo:

O nome de um caso de uso pode ser qualquer sentencia, mas a UML recomenda usar uma frase ativa curta (verbo + substantivo), por exemplo: "comprar itens'', "efetuar venda", ...

Os elementos principais do diagrama são uma elipse para representar um caso de uso e um pequeno boneco para representar

um ator

 

Nota: Abaixo temos uma estrutura de especificação que você pode usar para casos de uso. Não existe um padrão.

Nome do caso de uso Descrição do caso de uso (um parágrafo). Atores Lista dos nomes dos atores com descrição curta. Prioridade Seja este caso de uso muito importante no projeto ou acessório? Pre-Condições Lista de condições que têm que ser verificadas antes que o caso de uso começa. Fluxo de eventos Fluxo principal 1. Primeiro passo no caso de uso. 2. Segundo passo no caso de uso. 3. ... Fluxos alternativos Descrever os fluxos alternativos. Pós-Condições Lista de condições que têm que ser verificadas depois do fim do caso de uso. Pontos de extensão Lista dos pontos de extensão no caso de uso. Casos de uso incluídos Lista dos nomes dos casos de usos incluídos.

Nos primeiros contatos com os modelos de casos de uso surgem com frequência três perguntas para as quais não existe uma resposta absoluta , são elas ::

1 - Como identificar atores ?

Para identificar os atores que vão participar do modelo devemos fazer as seguintes perguntas :

- Quem usa o sistema ?- Quem inicia o sistema ?- Quem fornece os dados ?- Quem usa as informações ?

2- Como descrever atores ?

Geralmente descreve atores usando :

Nome do caso de uso tipo de uso (frequente, ocasional , etc...) descrição de seu papel no sistema

3- Como Identificar casos de uso ?

Os casos de uso são interações entre os atores e o sistema . Temos então ações do ator e ações do sistema. Sendo que os atores sempre iniciam a ação.

Vamos dar um exemplo prático para que tudo fique mais claro. Vamos supor , por questão de simplicidade , que temos que modelar usando casos de uso a compra de item em um a loja com um terminal de ponto de venda.

Quais são os atores ?

Quem usa o sistema é o cliente e ele usa um terminal de caixa .

Como podemos identificar o caso de uso ?

Podemos chamar este caso de uso de : Comprar Item (verto+substantivo)

Agora vamos a um descrição textual do caso de uso Comprar Item onde atual os atores cliente e caixa. (Aqui estou adotando uma estrutura de especificação bem simplificada por questões didáticas)

Caso de uso - Comprar ItemAtores - Cliente , CaixaDescrição - Este caso de uso começa quando um cliente chega ao terminal com itens que deseja comprar.                       O caixa registra os itens , recebe o pagamento e emite uma nota fiscal.                      O Cliente recebe os itens comprados.

Na UML temos o diagrama de caso de uso que pode ser representado para o caso acima da seguinte forma:

Algumas considerações :

- Nomeie um caso de uso começando com um verbo , para enfatizar que ele é um processo. Ex: Cadastrar Cliente , Comprar Item , etc.

- Para identificar claramente um ator iniciador e um evento , comece a descrição da sequência de um caso de uso usando o seguinte esquema:

- Este caso de uso começa quando o <Ator>  <Evento que inicia o caso de uso>

Ex: Este caso de uso começa quando um cliente chega com vários itens para comprar

Vamos a um outro exemplo:

Suponha que você tenha um almoxarifado de peças onde clientes façam pedido e onde um operador receba tarefas do sistema para buscar peças para os pedidos dos clientes e distribuir peças do setor de compras para o almoxarifado. (O exemplo é bem simples para facilitar o entendimento do conceito)

Como poderíamos identificar os atores e os casos de uso para este exemplo?

Vamos identificar os atores .  Eles são :  Cliente ,  Operador ,  Sistema e Setor de Compras.

Certo ?

Não errado !!! No exemplo acima Sistema não pode ser um ator pois ele não se ajusta ao conceito dado a um ator : Um agente externo ao sistema.

Lembre-se que um ator é um papel que interage com o sistema mas não faz parte do sistema, então no lugar de Sistema poderíamos sugerir um administrador ou gerente. Então os atores seriam :   Cliente ,  Operador , Administrador e Compras. (Podem existir sub-sistemas que interagem com o sistema , neste caso eles seriam considerados atores.)

E os casos de usos , quais seriam ?

- solicita peças (ator Cliente)- entrega peças (ator Compras)- buscar pedidos (ator operador)- distribuir pedidos (ator operador)- cadastrar Tarefas (administrador)

Certo ? 

Errado !!!  No caso do ator operador ele não atua sobre o sistema nos casos de uso buscar pedidos e distribuir pedidos , ele atua sobre o sistema realizando Tarefa. Então o correto seria.

- solicita peças (ator Cliente)- entrega peças (ator Compras)- realiza Tarefa (ator operador)- cadastrar Tarefas (administrador)

Usando a representação UML para os diagramas de casos de uso teríamos :

Este seria o caso de uso preliminar(simplificado) pois não temos muito detalhamento nesta etapa do modelo. A próxima etapa seria realizar um refinamento do modelo a fim de obter o relacionamento entre os casos de uso através da generalização , inclusão ou extensão.

A partir do diagrama de casos de uso preliminar muitas vezes temos que definir casos de usos adicionais separadamente pois as operações se encontram duplicadas em outros casos de uso ou são complexas e longas e a separação nos ajuda a compreendê-las.

Os relacionamentos possíveis são :

1- Inclusão : Se um caso de uso inicia ou inclui o comportamento de outro , dizemos que ele usa o outro.

Ex: No caso de uso Comprar Item se o pagamento for feito com dinheiro podemos ter a inclusão PagarComDinheiro

O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>.

Então para o exemplo do cliente com o use case Solicitar Pedidos de peças teríamos:

As propriedades básicas da inclusão são :

realizar um decomposição funcional reduzir a complexidade de um caso de uso O caso de uso básico não pode executar sem a inclusão. Comportamento comum

2- Extensão - Define pontos de extensão que adicionam comportamento a um caso de uso base descrevendo uma variação do comportamento normal. O caso de uso base pode ser executado mesmo sem a extensão.

Ex: O caso de uso Comprar Produto pode apresentar a extensão Compra por um Cliente Regular. Abaixo temos o diagrama UML

Os pontos de extensão são indicados na linha entre os casos de uso do sistema.

3- Generalização - Indica um caso de base que possui diferentes especializações e inclui comportamento ou sobrescreve o caso de uso base.

O caso de uso Pagar fatura apresenta as generalizações : Pagamento com cartão  e Pagamento com Cheque , conforme o diagrama Abaixo:

Além disto temos também os relacionamentos entre atores onde um ator especializado pode acessar os casos de uso de um Ator base.

Abaixo temos um exemplo onde o Ator gerente acessa os casos de uso do ator funcionário

Espero que esta pequena introdução aos casos de uso amplie o seu horizonte para a modelagem UML.

Creio que uma das melhores ferramentas para modelagem é o Rational Rose, mas o preço é bem salgado. Como opção você pode usar uma das seguintes ferramentas :

UML - Unified Modeling Language e Visual Modeler

Se você é daqueles que quando vai desenvolver um sistema senta na frente do computador e já começa a codificar , eu lamento informá-lo , mas você já começou de forma errada e provavelmente vai terminar assim. Esta atitude somente se justifica para pequenos sistemas pessoais.

Um sistema profissional tem o seu início na modelagem dos dados onde você pode projetar , documentar e visualizar o sistema, independente da tecnologia que será usada para sua implementação quer seja Visual Basic , C , Java , etc...

Vamos dar uma pequena introdução aos conceitos da UML e abordar o Visual Modeler ; uma ferramenta que o VB oferece para modelar objetos ( somente a versão

Enterprise).

Introdução

A UML - Unified Modeling Language - é um modelo de linguagem para modelagem de dados orientado a objetos.Com ela podemos fazer uma modelagem visual de maneira que os relacionamentos entre os componentes do sistema sejam melhor visualizados e compreendidos e documentados.

Podemos dizer também que a UML é uma linguagem para especificar , construir , visualizar e documentar um sistema de software que surgiu com a fusão das metodologias já anteriormente usadas e tem como objetivo

1. Modelar sistemas usando os conceitos da orientação a objetos 2. Estabelecer um elo explicito entre os artefatos conceituais e os executáveis 3. Tratar questões de representar sistemas complexos de missão crítica 4. Criar um linguagem de modelagem que possa ser usada por homens e por

máquinas

A seguir algumas das notações mais usadas pela linguagem UML:

Pacote - Organiza as classes de objetos em grupos. É representado como um retângulo com uma aba no canto superior esquerdo.

OBS:

As classes são definidas dentro do pacote Pacotes diferentes podem ter classes com nomes iguais Para referenciar uma classe de um pacote usamos a

sintaxe: NomedoPacote :: NomeDaClasse

Visibilidade do Pacote :

1. Privado - Só o pacote que define determinadas classes tem acesso a elas.

2. Protegido - Só os pacotes gerados a partir do pacote podem acessar suas classes.

3. Público - O conteúdo do pacote pode ser acessado por outros elementos

4. Implementação - Idêntico a definição do pacote privado com algumas restrições para o uso dos elementos do pacote.

Uma depêndencia entre as classes de dois pacotes leva a dependência entre os pacotes que podemos representar como na figura ao lado.

Estereótipo

É um elemento de modelagem que rotula tipos de classes de objeto sendo que uma Classe de objetos pode ter um ou mais tipos de estereótipos. É descrito entre os sinais << e >> ou como um ícone no canto superior direito.

Os estereótipos mais comuns são :

Classe Fronteiriça Classe de Entidade Classe de Controle Classe de Exceção Classe Utilitária

Nota - Comentário usado em um diagrama. É exibida como um retângulo com o canto direito superior dobrado.

Diagrama de Classe

A UML utiliza uma notação própria para construção de diagramas . Para representar uma Classe de objetos a notação é :

A classe de objeto é representada por um retângulo , subdividido em três áreas :

1. Nome da Classe 2. Atributos da classe 3. Operações da classe

O diagrama de classe é um gráfico que mostra a estrutura do sistema : classes , tipos e seus conteúdos e relações.

Para descrever os atributos a sintaxe é :

Visibilidade NomedoAtributo : TipoDeExpressao = ValorInicial {Propriedade}

A visibilidade pode ser:

+ Publica # protegida - privada

Diagrama de sequência

O diagrama de sequência mostra a interação entre os objetos ao longo do tempo e apresenta os objetos que participam da interação e a sequência de mensagens trocadas. A notação usada pela UML para representar o diagrama de sequência é :

1. Os objetos são representados por um retângulo com seus nomes sublinhados

2. As linhas de vida dos Objetos são representadas por linhas verticais tracejadas

3. As interações entre objetos são indicadas por flechas horizontais que são direcionadas da linha vertical que representa o objeto cliente para a linha do objeto fornecedor

4. As flechas horizontais são rotuladas com mensagens 5. A ordem as mensagens no tempo é indicada pela posição vertical , com a

primeira mensagem aparecendo no topo. 6. A numeração é opcional e baseada na posição vertical.

Abaixo um pequeno esboço de um diagrama de sequência :

Relacionamento

É a forma como as classes de objetos interagem entre si para formar o comportamento do sistema. Esse relacionamento é apresentado através de um Diagrama de classes. Os dois tipos principais de relacionamento sâo:

1- Associação : Representa uma dependência estrutural entre os objetos é representado por uma linha sólida entre as classes. O fluxo de dados pode ser uni ou bi-direcional através da conexão e entre duas classes pode existir mais de uma associação.

2- Agregação - Permite mostrar que uma classe é composta por objetos de outra classe. É representada por uma linha sólida com um losango ligado a classe cliente.

Diagrama de Caso de Uso (Use-Case)

Os diagrama de caso de uso exibem a visão externa do sistema e suas interações com o mundo exterior descrevendo seus requerimentos e suas responsalibilidades e possuem três elementos :

1. Ator - agente que interage com o sistema 2. Caso de Uso - o comportamento da classe 3. Interação - envio e recebimento de mensagens da comunicação ator -

sistema.

Exemplo de diagrama de Caso de uso

Eu não vou me estender mais pois estou consciente da complexidade do assunto , apenas quis dar uma visão básica sobre a UML . Se você quiser se aprofundar sugiro um bom livro sobre o assunto - Utilizando UML e padrões , autor Craig Larman , editora Bookman , ISBN - 85.7307-651-8 - Porto Alegre - RS.

Para concluir podemos dizer que a modelagem visual orientada a objetos agora tem um padrão simples e robusto para especificar e descrever a grande maioria das funções , relacionamentos e técnicas de desenvolvimento orientado a objetos.

Os fabricantes de ferramentas CASE com certeza irão suportar a UML e a fase de codificação será cada vez mais substituída pela geração de código automático pelas ferramentas CASE. Podemos citar dois exemplos destas ferramentas : ERviw/ERX da Logik Works e Rational Rose da Rational Software Corp.

Usando o Visual Modeler do VB

O Visual Basic apresenta na sua versão Entrerprise uma ferramenta gráfica que podemos usar para modelagem de dados orientada a objetos - Visual Modeler - . Esta ferramenta apresenta as seguintes características básicas :

1. Diagrama de classes - A notação para o diagrama fornecido pelo Visual Modeler é um subconjunto da modelagem definida pela UML

2. Geração de código - O Visual Modeler gera automaticamente código Visual Basic e C++ a partir do desenho de modelo criado.

3. Engenharia Reversa - O VM cria tem a habilidade de criar automaticamente ou atualizar o modelo com as mudanças feitas pelo código Visual Basic

4. A combinação da modelagem , geração de código e engenharia reversa.

Usando o Visual Modeler você pode modelar as classes do seu sistema e após isto pode gerar o respectivo código de maneira automática ou pode fazer o contrário : você cria o código de suas classes e gera automaticamente o diagrama de classes.

O Visual Modeler apresenta a visão de sistema de três formas diferentes:

1-) Visão Lógica - Aqui são descritas as classes e os relacionamentos

2-) Visão de componentes - Exibe a estrutura fisica do sistema : as bibliotecas e os executáveis

3-) Visão de distribuição - Exibe os nós do sistema e suas conexões bem como a alocação dos processo para os nós.

Para iniciar o Visual Modeler você deve selecionar o menu Iniciar->Programas->Microsoft Visual Studio 6.0 -> Microsoft Visual Studio 6.0 Enterprise Tools -> Microsoft Visual Modeler

Ou , se preferir , pode carregar o VM como um add-ins do Visual Basic ; Inicie o VB e no menu Add-Ins selecione a opção Add-In Manager... .

Na janela Add-In marque para carregar (Startup/Loaded) os add-ins - Visual Modeler Add-in e Visual Modeler Menus Add-in. Pronto agora no VB estará visível a opção para carregar o VM.

Ao executar o Visual Modeler você deverá ver a janela principal do programa :

A visão padrão que o Visual Modeler oferece é a visão Logica onde temos as classes e seus relacionamentos.

Se você clicar expandir cada item terá o exibido na figura ao lado e verá o nome atual da visão lógica do modelo : Three Tired Service Model.

Para modificar clique com o botão direito do mouse e selecione - Rename - alterando o nome para o desejado.

Os três pacotes exibidos correspondem ás três camadas de uma aplicação multicadamada :

Users Services - Camada de Interface com o usuario

Business Services - Camada de regra de negócios

Data Services - Camada de dados

Cada camada já tem um pacote que mostra o conteúdo da camada. O nome de cada pacote é - Package Overview.

Você pode criar um novo modelo. Para isto clique com o botão direito do mouse sobre o item - Logical View - e selecione a opção - New - e a opção Class Diagram informando o nome do modelo.

A primeira coisa que você deve fazer para criar o seu diagrama é criar os pacotes relativos a ele. Os pacotes irão conter classes relacionadas. Para

fazer isto clique com o botão direito do mouse na camada onde deseja criar o seu pacote e selecione a opção - New - e a sub-opção Package e informe o nome do pacote.(Eu usei o nome

pacote1)

Veja as figuras ao lado.

Agora que você criou o pacote se clicar sobre o ele duas vezes verá a janela - Package Specification for Pacote1 que apresenta duas abas :

General - Aqui você define a documentação para o pacote Detail - Aqui você define se o pacote será Global. (Para isto marque a opção

Global)

Após definir estes detalhes se você clicar no item - Package Overview da camada relacionada verá o novo pacote criado.

Vamos agora inserir uma classe ; para isto selecione o pacote desejado e clique duas vezes ele . A área para entrada de classes irá surgir . Selecione a opção Tools do Menu , selecione a seguir Create e o item Class. O cursor irá mudar para o formato de uma cruz , arraste-o para a área do diagrama e clique para formar a classe.

Para incluir uma propriedade ou método na classe clique com o botão direito do mouse sobre a classe e selecione a opção New Property ou New Method.

A propriedade será inserida no diagrama dentro da classe e inserida na arvore. Se você quiser fazer qualquer alteração sobre as propriedades ou métodos clique duas

vezes sobre ela na árvore e altere os dados na janela que surgirá.

Para criar relacionamentos entre as classes basta selecionar na barra de ferramentas o tipo de relacionamento desejado e arraste o mouse da primeira para a segunda classe relacionadas. Ao lado temos os principais relacionamentos usados.

A visão de componentes

Além da visão Lógica o Visual Modeler exibe a visão de componentes onde um diagrama de componentes mostra a organização entre os componentes do sistema : bibliotecas , DLL´s , arquivos EXE . Além disto a visão de componentes mostra o comportamento e dependência entre os componentes. O diagrama de componentes é composto por :

1. Pacotes de componentes - representa os grupos de componentes relacionados

2. Componentes - representa os módulos de programa : DLL , EXE , etc 3. Interfaces - define os métodos visíveis de uma classe ou componente 4. Relacionamenteo de dependência - Exibe quando um componente usa

serviços de outo componente.

Para criar um novo componente você deve clicar com o botão direito do mouse sobre o item - Component View - e selecionar New -> Component Diagram

Para excluir , renomear um diagrama repita a operação acima e selecione - Rename ou Delete

Visão de distribuição

A visão de distribuição exibe um diagrama de distribuição que mostra os nós e as conexões entre os nós. Onde um nó pode ser um hardware e uma conexão um cabo entre o hardware e a interface.

Gerando o código para as classes automaticamente

O Visual Modeler tem um assistente que gera automaticamente o código para as classes que você criou no Visual Modeler . Vejamos um exemplo:

Para poder usar este recurso você vai ter que ter criado um componente no VM e ter associado ao componente as classes pertinente. Eu vou criar um componente e uma classe - teste - usando o - Class Wizard - no menu Tools.(Basta você clicar e seguir

as orientações para criar as propriedades e métodos da classe)

Após isto , para gerar o código para classe , selecione a classe criada e clique com o botão direito do mouse , selecionando a seguir a opção - Generate Code.(fig.1).

Na janela - Assign to new Component - selecione Visual Basic EXE e clique em OK.(fig.2)

Fig.1 Fig.2

A seguir o assistente de geração de código irá entrar em ação , você deve ir confirmando as opções e no final terá o código gerado para a sua classe.

Fazendo engenharia Reversa

Você pode gerar o diagrama para uma aplicação feita em VB. Para fazer isto você deve carregar os add-ins : Visual Modeler Add-ins e Visual Modeler Menus. Vejamos como fazer o serviço:

1-) Inicie o Visual Basic e carregue o projeto para o qual deseja realizar a engenharia reversa. Eu vou carregar um projeto que contém uma classe e um formulário.

2-) A seguir selecione a opção - New - e na janela - Reverse Engineering Wizard - Welcome - clique em Next  

3-) Na janela Reverse Engineering Wizard - Welcome - Selection of Project Items selecione os items para o qual que deseja o codigo e clique em Next

4- Na próxima janela arraste os itens do projeto para uma dos pacotes lógicos e clique no botão - Next

Clique no botão - Finish- e a seguir no botão - Close . Pronto o seu diagrama já esta quentinho !

Embora simples o Visual Modeler permite realizar algumas tarefas que vão fazer você ganhar tempo e ... dinheiro !

UML - Diagrama de Classes e objetos

 Resolvi falar um pouco sobre diagrama de classes e de objetos.. Não é uma tarefa trivial para ser desenvolvida em um pequeno artigo onde deve-se ter a preocupação de ser claro , objetivo sem ser superficial. 

Eu poderia começar dando de cara a definição do que é um diagrama de classes , mas creio que preciso falar sobre o conceito de classes , mas para isto preciso falar sobre o que são objetos... Estou falando para programadores e analistas , certo !!!  Então  nosso foco e  área de atuação será a Programação Orientada a Objetos. (POO) Em POO , os problemas de programação são pensados em termos de objetos , nada de funções , rotinas , nada disto , o assunto são os objetos , propriedades e métodos.  Nota: A preocupação da programação estruturada estava em procurar os processos que envolviam o problema e não os objetos que o compunham. Desta forma quando é colocado o problema de desenvolver um sistema para locadoras , por exemplo , devemos pensar como dividir o problema em objetos. Para este caso podemos ter os seguintes objetos :  Clientes , CDs e Fitas ,  etc..  A melhor maneira de conceituar estes termos é considerar um objeto do mundo real  e mostrar como podemos representá-lo em termos conceitos para POO. Começando com as definições : "Um objeto  é um termo que usamos para representar uma entidade do mundo real"  (Fazemos isto através de um exercício de abstração.) Vou usar como exemplo o meu cachorro Bilu. Posso descrever o Bilu  em termos de seus atributos físicos: é pequeno , sua cor principal é castanha , olhos pretos , orelhas pequenas e caídas,  rabo pequeno , patas brancas. Posso também descrever algumas ações que ele faz (temos aqui os métodos) :  balança o rabo quando chego em casa , foge e se deita se o mando sair debaixo da mesa, late quando ouve um barulho ou vê um cão ou gato,  atende e corre quando o chamo pelo seu nome. Temos abaixo a representação do Bilu. 

Temos aqui a representação de um objeto , no caso o meu cachorro Bilu , que possui as seguintes propriedades e métodos:

Propriedades : Cor do corpo : castanha  cor dos olhos : preto   altura: 18 cm   comprimento: 38 cm   largura : 24 cm

Métodos :  balançar o rabo , latir , deitar , sentar  

Meu cachorro Bilu   Em termos de POO para poder tratar os objetos começamos criando classes , neste caso irei criar a classe chamada Cachorro. "Uma classe representa um conjunto de objetos que possuem comportamentos e características comuns".

"Na UML o nome de uma classe é um texto contendo letras e dígitos e algumas marcas de pontuação. Na realidade, é melhor guardar os nomes curtos com apenas letras e dígitos. UML sugere capitalizar todas as primeiras letras de cada palavra no nome (ex.: ``Lugar'', ``DataReserva''). É melhor também manter nomes de classe

no singular, classes por default ``contem'' mais de um objeto, o plural é implícito.". [Nicolas Anquetil]

Uma classe descreve como certos tipos de objetos se parecem do ponto de vista da programação , pois quando definimos uma classe precisamos definir duas coisas:

1. Propriedades - Informações específicas relacionadas a uma classe de objeto. São as características dos objetos que as classes representam. Ex Cor , altura , tamanho , largura , etc...

2. Métodos: São ações que os objetos de uma classe podem realizar. Ex: Latir , correr , sentar , comer, etc.

 Você pode pensar em uma classe com um modelo para criar quantos objetos você desejar de um tipo particular. Pense em um carimbo com a imagem de um cachorro , quando você carimba e obtêm um desenho de cachorro você acabou de criar uma instância da classe e obteve um objeto daquela classe. O novo objeto possuirá todas as características e comportamentos definidos pela classe.(As classes especificam a estrutura e o comportamento (operações) dos objetos, que são instâncias das classes) 

 Aqui temos que Bilu é um objeto da classe Cachorro. Em termos de POO acabamos de criar uma instância da classe Cachorro e a chamamos Bilu.

Quando criamos uma nova instância de uma classe dizemos que estamos instanciando a classe.

 Geralmente em um sistema de médio porte serão identificados diversas classes que compõem o sistema. Neste contexto a UML surgiu como uma proposta de ser uma linguagem para modelagem de dados que usava diversos artefatos para representar o modelo de negócio ; um destes artefatos é o diagrama de classes. A representação de uma classe usa um retângulo dividido em três partes: 

nome atribut

os métod

os

  Podemos dizer que os diagramas de classes são os principais diagramas

estruturais da UML pois ilustram as classes , interfaces e relacionamentos entre elas.

 Os diagrama se classes ilustram atributos e operações de uma classe e as restrições como que os objetos podem ser conectados ; descrevem também os

tipos de objetos no sistema e os relacionamentos entre estes objetos que podem ser : associações e abstrações. Para poder representar a visibilidade dos atributos e operações em uma classe utiliza-se as seguintes marcas e significados:

+ público - visível em qualquer classe # protegido - qualquer descendente pode usar - privado - visível somente dentro da classe

Relacionamento entre classes

Os objetos tem relações entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relações são representadas também no diagrama de classe. [Nicolas Anquetil]

A UML reconhece três tipos mais importantes de relações: dependência, associação e generalização (ou herança).

Geralmente as classes não estão sós e se relacionam entre si. O relacionamento e a comunicação entre as classes definem responsabilidades , temos 3 tipos :

1. Associações :  Agregação e composição2. Generalização (herança)3. Dependências

As representações usam a seguinte notação : 

Associação : São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes. Podemos ter associação uniária , binária , etc.

A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.[Nicolas Anquetil] 

Dependência - São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe.

 ll Generalização (herança : simples ou composta) - Relacionamento entre um

elemento mais geral e um mais específico. Onde o elemento mais específico

herda as propriedades e métodos do elemento mais geral. A relação de generalização também é conhecida como herança no modelo a objetos. Como a relação de dependência, ela existe só entre as classes. Um objeto particular não é um caso geral de um outro objeto, só conceitos (classes no modelo a objetos) são generalização de outros conceitos. 

Agregação Regular - tipo de associação ( é parte de , todo/parte) onde o objeto parte é um atributo do todo ; onde os objetos partes somente são criados se o todo ao qual estão agregados seja criado. Pedidos é composto por itens de pedidos.

Composição - Relacionamento entre um elemento ( o todo) e outros

elementos (as partes) onde as parte só podem pertencer ao todo e são criadas e destruídas com ele.

O diagrama de de classes lista todos os conceitos do domínio que serão implementados no sistema e as relações entre os conceitos. Ele é muito importante pois define a estrutura do sistema a desenvolver. O diagrama de classes não surge do nada ele é consequência do prévio levantamento de requisitos , definição de casos de usos e classes. Como exemplo vamos supor que você tivesse que desenvolver um sistema para automatizar um consultório dentário. As etapas básicas envolvidas seriam:

Levantamento e análise de requisitos do sistema a ser desenvolvido. Entrevista com o dentista(s) e com as pessoas que trabalham no consultório

Definição dos objetos do sistema :     Paciente , agenda , dentista , serviço , contrato , consulta , pagamento , etc..

Definição dos atores do sistema : paciente, dentista , secretária Definição e detalhamento dos casos de uso: marcar consulta , confirmar

consulta , cadastrar paciente , cadastrar serviços , etc. Definição das classes :  paciente , dentista , exame , agenda , serviço Definir os atributos e métodos das classes :

Após toda esta análise você chega  no diagrama de classes do sistema (representado abaixo a título de exemplo ilustrativo) 

Atributo  

Um atributo representa uma propriedade que todos os objetos da classe têm (por exemplo, todos os cachorros tem pelo , orelhas , altura, ,etc. Mas cada objeto terá valores particulares para seus atributos (alguns cachorros são mais baixos , outros são maiores,  etc.).

Uma classe pode ter qualquer número de atributos. Na UML, o nome de um atributo é um texto contendo letras e dígitos e algumas marcas de pontuação. UML sugere de capitalizar todas as primeiras letras de cada palavra no nome menos a primeira palavra (ex.: "nome'', "nomeCachorro'').

Num modelo, os atributos devem ser de um tipo simples (inteiro, texto, talvez data), não podem conter outros objetos.

Métodos

Métodos são ações que implementam uma operação. Uma classe pode ter qualquer número de métodos e dois métodos em duas classes podem ter o mesmo nome. 

Todos os métodos que vão implementar a operação tem que respeitar exatamente a assinatura dela (mesmo nome, mesmo número de atributo, com os mesmo tipos e o mesmo ordem). Um método não pode acrescentar ou cortar um parâmetro. Isso seria um violação do polimorfismo. Para mandar a mensagem corretamente, teríamos que saber qual é a classe do objeto (cada classe tendo método com assinatura diferente). O que é possível, no caso de cortar um parâmetro, é simplesmente ignorá-lo na implementação. [Nicolas Anquetil]

Voltarei falar sobre UML nos próximos artigos onde iremos abordar os seguintes diagramas UML: 

Seqüência : Mostra interações entre vários componentes do sistema enfocando a sequência. Colaboração  : Mostra interações entre vários componentes do sistema enfocando a colaboração entre as classes. Atividade : Mostra como um sub-sistema ou um objeto realizam uma operação. Estados : Mostra como um sub-sistema ou um objeto realizam uma operação.  Componentes  : Mostra a organização dos componentes. Trata da implementação do sistema. Implantação : Mostra a configuração física sobre qual o sistema será instalado.  E estamos conversados....  

 Veja também a seção de UML-XML em : XML/UML

     Novas seções:

Vídeo-Aulas VB Prático

      Super CD Visual Basic  - Tudo sobre Visual Basic       Super DVD .NET - Tudo sobre VB .NET , ASP .NET 

 

 Para saber mais sobre o assunto veja também os seguintes artigos: