Orientações básicas na elaboração de um diagrama de classes

Este artigo orienta o estudante na elaboração de um diagrama de

classe, procurando estabelecer, de forma sintética, os principais pontos
para a abstração dos objetos e classes de um cenário específico...
Publicado em: 24/05/2011

RESUMO:
Este artigo orienta o estudante na elaboração de um diagrama de
classe, procurando estabelecer, de forma sintética, os principais pontos
para a abstração dos objetos e classes de um cenário específico. Neste
sentido, descreve-se seqüencialmente, os sucessivos componentes para
a construção de um diagrama de classe completo.

PALAVRAS-CHAVE: Diagrama. Objeto. Classe. Abstração

INTRODUÇÃO

Em programação, um diagrama de classes é uma representação da estrutura e relações das

classes que servem de modelo para objetos. Podemos afirmar de maneira mais simples que
seria um conjunto de objetos com as mesmas características, assim saberemos identificar
objetos e agrupá-los, de forma a encontrar suas respectivas classes. Na Unified Modeling
Language (UML) em diagrama de classe, uma classe é representada por um retângulo com
três divisões, são elas: O nome da classe, seus atributos e por fim os métodos. Vejam
abaixo na Figura1 sua representação:

Figura Error! Bookmark not defined.- Classe Clientes

Porque é tão importante encontramos as classes para o desenvolvimento de um sistema? É

simples, pois cada classe do diagrama representa uma tabela do banco de dados, por esse
motivo é tão importante encontrarmos. Observe também que para identificarmos uma
classe, precisamos antes identificar seus objetos com características semelhantes.

Ao analisarmos um cenário, poderemos identificar inúmeros objetos, contudo nem todo

objeto será útil para nosso diagrama de classe, essa classificação dos objetos que usaremos
é chamado de Abstração. Abstração é a forma de concentrarmos apenas nos aspectos
essenciais do nosso cenário.

Para o desenvolvimento do nosso diagrama de classe, precisaremos de um cenário

qualquer onde realizaremos um passo a passo até abstrairmos todas as classes, a partir
deste ponto, poderemos efetuar as ligações e cardinalidade.

CENÁRIO

Você trabalha para uma empresa de desenvolvimento como Analista de Sistemas. O

responsável pelo setor que você trabalha, em uma reunião, distribuiu tarefas para cada
membro da equipe. Sua tarefa foi desenvolver um diagrama de classe para que seja
iniciado o desenvolvimento de um novo software.

A empresa que nos contratou, deseja adquirir o certificado ISO 9001 em qualidade,
entretanto uma das normas repassadas foi que, deve ser obrigatório controlar os pedidos de
suporte/serviço que são feitos pelos clientes.

O ramo da empresa é Serviçe Desk1[1] o fluxo do processo segue abaixo:

O cliente entra em contato com a central através do telefone;

Um atendente tem um prazo curto para registrar esta solicitação, informando os dados do
cliente, o que foi solicitado, o nível de urgência, o grupo de atendimento, o técnico, um ou
mais equipamentos envolvidos na manutenção. Anotar toda a interação realizada no
equipamento, como por exemplo: Se ele conectar remotamente ao equipamento, deve
informar em um histórico e suponhamos que 3 segundos depois ele reinicie o equipamento,
deverá informar no histórico também. Resumindo: Toda interação deve ser anotada no
registro com data e hora.

Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk irá salvar o
registro com a situação de “Resolvido” encerrando o caso, contudo deverá em um local
específico do registro definir como ele resolveu o caso, informando que se tratava de um
Incidente2[2], Problema 3[3]ou Solicitação4[4]. O registro deve ser categorizado,
escolhendo dentre três classificações: Categoria >> Sub Categoria>> Item da categoria,
onde a categoria é uma lista de tipo de serviço, como por exemplo: Se foi Hardware ou
Software. A Sub Categoria está relacionada com a categoria, pois dependendo do que foi
escolhido na primeira lista será mostrada na segunda que será uma Sub Categoria, como
por exemplo: No caso da escolha de Hardware, seria informado na subcategoria algum tipo
de peça do equipamento que o técnico interagiu, tipo DVD/R, no caso de Categoria ser
Software a sub categoria deveria ser qual software, tipo: Word, Excel e etc...E no item da
categoria deveria ser escolhido o que foi realizado pelo técnico, no caso de Hardware >>
DVD/R, poderia ser SUBSTITUIDO, LIMPADO..etc. No caso de Software >> Word >>
INSTALADO,DESINSTALADO etc...

Caso o técnico do Service Desk não consiga resolver no seu prazo que será o mais curto,
deverá enviar o registro para outro grupo de atendimento onde existirão outros técnicos
que poderão ir até o equipamento fisicamente para resolver o problema com um prazo mais
extenso. Um grupo é composto por vários técnicos, no registro deve constar o grupo que
atendeu e o técnico, pois cada registro conta como receita em reais para o grupo sendo
apurado ao efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito
por quantidade de registros atendidos no prazo estipulado.

Se mesmo o grupo de atendimento físico tenta entrar em contato com o cliente, mas não o
obtiver sucesso, o técnico poderá deixar o registro agendado, para realizar esta tarefa deve
ser informado no registro à data e hora que será retornado o atendimento do chamado e
definir a situação do registro para “Pendente pelo cliente”, definir também a data e hora
para o próximo contato. Esta situação de pendência significa que o técnico não está
atendendo por culpa do cliente e o tempo em que o registro fica nesta situação será
debitado ao final do apuramento, a fim de beneficiar o grupo que o atende, pois cada grupo
tem um tempo para atender os registros e se ultrapassar este prazo recebe multa em cima
do valor do chamado.

Ao final caso o pedido tenha sido designado para outro grupo, ou esteja em andamento,
pendente, cancelado ou resolvido, deve-se informar em um campo específico o que foi
feito neste registro resumidamente. Se a situação do registro estiver definida como
“Resolvido”, uma pesquisa de satisfação deverá ser enviada para o solicitante.

IDENTIFICAR OS OBJETOS TANGÍVEIS

Para identificarmos um objeto, precisamos antes entender como vê-los, para isso, basta ter
como regra que: O objeto é algo tangível, que podemos percebê-lo a nossa frente, sendo
possível encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber
ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc.

Vamos tentar encontrar os objetos do nosso cenário, observe o primeiro item abaixo:

O cliente entra em contato com a central através do telefone;

Nesta frase acima, podemos identificar como objetos:

Cliente

Telefone

Cliente é considerado um objeto, pois é tangível e existem vários outros iguais a ele com as
mesmas características, assim como o telefone.
No segundo item do cenário identificamos:

Atendente

Solicitação

Grupo

Técnico

Equipamento

Histórico

O único item acima que gera dúvida se é ou não um objeto, seria histórico, pois não é
normal vermos este objeto, entretanto ele existe, veja o exemplo deste objeto no mundo
real: Na escola existe o histórico escolar ou na clínica existe histórico médico e etc.

No terceiro item do cenário identificamos:

Categoria

Sub Categoria

Item da categoria

Observe que estes objetos acima são difíceis de identificarmos no mundo real, mas preste
atenção no cenário de uma locadora de DVD veja que as placas com o gênero dos filmes
são categorias, aquelas placas são objetos tangíveis representando categorias que já seria
sua classe mãe.

Os itens quatro e cinco do cenário estão apenas explicando o processo, não identificamos
nenhum objeto novo.

No sexto e ultimo item do cenário identificamos os seguintes objetos:

Pedido

Pesquisa satisfação

IDENTIFICAR OS OBJETOS POR SEUS ATRIBUTOS

Após identificarmos os objetos que estavam visíveis no cenário, agora teremos que
encontrá-los através de seus atributos, onde os atributos são características do objeto,
suponhamos que no cenário acima, foi falado sobre algum objeto, contudo não foi
pronunciado seu nome, dificultando assim sua localização. Para encontrarmos teremos que
identificar atributos ou características, como por exemplo: se no cenário dado acima,
tivéssemos o atributo CPF, poderíamos identificar que esta característica pertence ao
cliente, identificando assim o objeto Cliente sem que seu nome houvesse sido pronunciado
no cenário.

Você deve repassar todo cenário novamente em busca destas características sem objetos,
abaixo segue alguns que identifiquei:

Data

Hora

Situação

Tipo de Serviço

Prazo

Observe que os atributos Data, Hora, Situação, Tipo de Serviço e Prazo são referente ao
pedido, sendo assim, para identificarmos novas classes a partir desses atributos, teremos
que realizar a seguinte pergunta para cada um deles: “Eu preciso uma lista de: Atributo ? ”,
onde no lugar de Atributo você substitui por atributos acima. Veja os testes abaixo:

Eu preciso uma lista de Data? = Não

Eu preciso uma lista de Hora? = Não

Eu preciso uma lista de Situação? = Sim

Eu preciso de uma lista de Tipo de Serviço? = Sim

Eu preciso uma lista de Prazos? = Sim

As perguntas com resposta Sim, serão novas classes, segue abaixo as novas classes
encontradas:

Situações

Tipo de Serviços

Prazos

LISTA COMPLETA COM TODOS OS OBJETOS ENCONTRADOS

Listaremos abaixo para facilitar nossa visualização, todos os objetos encontrados após
nossa abstração:

Cliente

Telefone

Atendente

Solicitação

Grupo

Técnico

Equipamento

Histórico

Categoria

Sub Categoria

Item da categoria

Pedido

Pesquisa satisfação

Situações

Tipo de Serviços

Prazos

AGRUPAR OS OBJETOS POR SEMELHANÇA

Nosso próximo passo é agrupar todos os objetos encontrados por características

semelhantes, como por exemplo: Mesa e Cadeira têm as mesmas características, sendo
classificadas como Móveis. Assim devemos trabalhar os itens acima:

Cliente, Atendente e Técnico = Pessoas

Solicitação, Histórico, Pedido e Pesquisa de Satisfação = Documentos

Telefone = Equipamentos
Veja que alguns dos objetos acima não foram classificados, devido a não necessidade de
tal processo, pois já está em sua classificação correta, devemos apenas usar o plural, pois
normalmente uma classe está no plural devido sua origem em agrupas vários objetos.

ELIMITAR CLASSES DESNECESSÁRIAS OU REPETIDAS

Observe no item anterior que muitas classes são do mesmo gênero, fazendo com que esteja
repetida no diagrama e se uma classe se repete no banco de dados será uma tabela criada
sem propósito nenhum.

Para eliminar, vejamos primeiro as classes que agrupamos por semelhança:

Observe que Pedido e Solicitação no cenário fez referência a uma mesa coisa, assim podem
então eliminar uma das duas, eu eliminei a solicitação.

Veja que Telefone é um item de equipamentos, sendo assim podemos também eliminá-la:

Abaixo a nova lista de classes:

Pessoas

Cliente

Atendente

Grupo

Técnico

Equipamento

Histórico

Categoria

Sub Categoria

Item da categoria

Pedido

Pesquisa satisfação

Situações
Tipo de Serviços

Prazos

MONTANDO O DIAGRAMA DE CLASSE

Para iniciarmos os primeiros passos de nosso diagrama de classe, desenhe em uma folha de
papel um retângulo com três divisões para cada classe.

Veja abaixo na Figura2, como deve ficar:

Figura Error! Bookmark not defined.- Diagrama de classe sem ligações e cardinalidade

REALIZANDO AS PRIMEIRAS LIGAÇÕES

Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos por
características semelhantes, como por exemplo: Clientes, Atendentes e Técnicos se
relacionam com pessoas, segue abaixo as ligações:
Figura Error! Bookmark not defined.- Parte do diagrama de classe envolvendo pessoas

Figura Error! Bookmark not defined.- Parte do diagrama de classe envolvendo

documentos

EFETUANDO AS LIGAÇÕES ENTRE AS CLASSES

Este ponto é trabalho, pois devemos testar classe por classe em busca de ligações, veja
abaixo como realizar esta tarefa:

Sabemos que o cliente entra em contato com o atendente que gera um pedido. Com esta
informação observamos que um pedido foi gerado da interação entre cliente e atendente,
onde um cliente pode solicitar vários pedidos para um atendente e um atendente atende a
vários clientes. Sua cardinalidade será N para N, onde N quer dizer muitos, sendo: Muitos
para Muitos, quando ocorre esse tipo de cardinalidade nasce uma nova tabela ou classe,
entre esses dois foi a classe pedidos, que já havíamos identificado antes. O importante
sobre a N para N é que a classe que nasceu recebe os códigos da classe que o fez relação,
ficando a classe “Pedido” com o código do cliente e o código da atendente.

Sabemos também que esse pedido será repassado para um técnico que o atenderá, sendo
assim um técnico pode atender a vários pedidos e um pedido pode ser atendido por um
técnico, sendo representado por 1-N, lembrando que a classe que recebe o N herda o
campo chave da outra classe como chave estrangeira, sendo assim ficará a tabela de
pedidos com mais um campo chamado: código do técnico.

Faça o processo para todas as classes, use sempre a pergunta dessa forma:

Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” um ou vários “nome

da classe”

Como ficaria entre Pedidos e situação:

Um pedido pode ter uma ou várias situações?

Resposta: Várias, pois ao abrir está em andamento, em outro ponto do tempo pode ficar
pendente e ser concluída ao final do serviço.

DIAGRAMA DE CLASSE COMPLETO

Figura Error! Bookmark not defined.- Diagrama de classe completo

CENÁRIO PARA EXERCITARMOS

Você trabalha para uma empresa coorporativa, seu cargo é Analista de Sistemas. O
responsável pelo setor Ativos 5[5] lhe enviou um email solicitando o desenvolvimento de
um software para resolver um problema que o setor tem constantemente enfrentado com as
auditorias internas, esta medida é de suma importância e o desenvolvimento deve ser
realizado o mais breve possível antes que auditoria externa faça a próxima visita. Sua
tarefa foi desenvolver um diagrama de classe para que seja iniciado o desenvolvimento
deste novo software.

Abaixo segue o cenário informado pelo responsável do projeto:

A empresa que nos contratou, deseja adquirir o certificado ISO 9001 em qualidade,
entretanto um dos itens de verificação é o registro de movimentação dos ativos.

Segue abaixo o que foi explicado pelo responsável:

O cliente entra em contato com a central através do telefone solicitando vários tipos de
serviço para a TIC6[6], alguns deles são: remanejamento/instalação/alienação 7[7] de
Ativos (computadores, monitores, impressoras e etc.);

Quando um equipamento é instalado ou movido, seu histórico de movimentação deve ser

registrado e em um software central, também deve ser possível saber exatamente sua
localização.

A localização do equipamento é dividida por “cidade, imóvel, andar e sala”, por exemplo:
Suponhamos que a empresa tenha filiais em cidades distintas sendo que em cada cidade
existem outros imóveis desta mesma filial, sendo estes imóveis divididos por andares e
cada andar pode ter várias salas separadas.

No cadastro do Ativo deve ser informada esta localização detalhadamente, a ponto do

auditor ao verificá-lo saiba exatamente a localização do equipamento.

Quem envia as solicitações de movimentação são os técnicos da TIC, tendo em vista que
são eles que fazem esta instalação ou movimentação do Ativo. Um usuário que não seja da
TIC, é proibido de tomar esta ação. Ao enviar a solicitação ele deve informar a etiqueta do
ativo e a localização de destino para o setor de Ativos, assim através desta solicitação que
ficará com situação de pendente até que seja movida pelo funcionário do setor de Ativos é
possível alterar o cadastro do Ativo para a nova localização.

O funcionário do setor de Ativo deve de posse da movimentação enviada para mover o

ativo, acessar o cadastro do ativo e alterar sua localização de acordo com o solicitado e
também alterar a situação da solicitação do técnico da TIC para a nova situação:
MOVIDA.

O histórico destas solicitações deve ser classificado por etiqueta do ativo e pelo técnico da
TIC que o fez, a fim de posteriores conferências.

CONCLUSÃO

Neste artigo conferimos as orientações básicas na elaboração de um diagrama de classe,

onde o ponto chave foi a usar o processo de abstração com aliado na busca dos objetos
espalhando em um contexto do cenário. Vimos ainda como classificar as classes eliminar
duplicidades, identificar por atributos e etc.

A dica passada aqui é como identificar os objetos em um cenário a fim de projetar um

diagrama de classe sem falhas. Interessante dizer que crianças identificam objetos mais
facilmente do que os adultos, pois o processo nos cega, deixando alguns objetos invisíveis.

Lembre-se de aplicar os passos: Identificar Objetos, Classificá-los e eliminar duplicidade,

feito isso, você terá o mais complicado que são as classes, depois com ajuda de um bom
livro de análise ou um professor, realizar as cardinalidade não será problema algum.

REFERÊNCIAS

Melo, Ana Cristina. Desenvolvendo Aplicações com UML, 1 ºEdição, Brasport, 2002.

Melo, Ana Cristina. Desenvolvimento aplicações com UML 2.0: do conceitual à

implementação / Ana Cristina Melo. – 2. Ed. – Rio de Janeiro : Brasport, 2004.

ISO 9001.

UML - Unified Modeling Language - Requisitos, Classes e Objetos

Neste artigo vamos conhecer um pouco mais sobre análise de
requisitos, classes e objetos em UML.
Publicado em: 02/08/2005

Requisitos

Esta fase captura as intenções e necessidades dos usuários do

sistema a ser desenvolvido através do uso de funções chamadas "use-
cases". É a descrição das necessidades ou desejos de um determinado
sistema .
O princípio básico da análise de requisitos é identificar e documentar
o que é realmente necessário, desta forma comunicando a todos os
envolvidos no projeto da forma mais clara possível, de maneira não-
ambígua de modo que os riscos sejam identificados sem correr riscos de
imprevistos.

Através do desenvolvimento de casos de uso (em UML chamamos de

“use-cases”), as entidades externas ao sistema (em UML chamamos
de "atores externos") que interagem e possuem interesse no sistema
são modelados entre as funções que eles requerem, funções estas
chamadas de "use-cases". Veja figura abaixo:

Os atores externos e os "use-cases" são modelados com

relacionamentos que possuem comunicação associativa entre eles ou
são desmembrados em hierarquia. Descrevemos um “use-case” através
de um texto especificando os requisitos do ator externo que utilizará
este “use-case”. Um “use-case” tanto pode depender de um ou mais
“use-case” como pode ter seus dependentes. Através do diagrama de
“use-cases” mostraremos aos atores externos (futuros usuários), e o
que estes podem esperar do sistema.

A análise de requisitos também pode ser desenvolvida baseada em

sistemas de negócios, e não apenas para sistemas de software, e os
atores podem também ser sistemas ou outros softwares. Veja figura:
A fase de análise preocupa-se com as primeiras abstrações (classes e
objetos) e mecanismos presentes no contexto do problema.
Descrevemos as classes nos Diagramas de Classes e também para
ajudar na descrição dos “use-cases”, podendo estas estar ligadas uma
nas outras através de relacionamentos.

Nesta fase modelamos somente as classes que pertencem ao domínio

principal do problema, ou seja, classes técnicas mais detalhadas não
estarão neste diagrama.

O Projeto cria uma representação do domínio do problema do mundo

real e leva-a a um domínio de solução que é o software.

Nesta fase partimos para as soluções técnicas, através dos resultados

obtidos na fase da análise. Serão adicionadas novas classes para
oferecer uma infra-estrutura técnica tais como: interface do usuário e
periféricos, banco de dados, interação com outros sistemas, e outras
mais. É feita uma junção das classes da fase da análise com as classes
técnicas da nova infra-estrutura, podendo assim alterar tanto o domínio
principal do problema quanto a infra-estrutura.

Com a elaboração do projeto obtemos detalhadamente as

especificações (requisitos), para dar inicio a fase de programação.

Tenha sempre em mente que o importante é entender o Usuário.

Agora que você já tem uma pequena noção de uma parte dos
Levantamentos de Requisitos , vamos abordar a prática das
Notações. Você vai conhecer os símbolos usados na UML.

Classes

Definição

Uma Classe, em linguagens Orientadas a Objeto, é a possibilidade de

combinar num único registro, campos de dados e campos que são
funções para operar os campos de dados do registro.

Em outras palavras, as classes são os blocos de construções mais

importantes de qualquer sistema orientado a objetos. Uma classe é uma
descrição de um conjunto de objetos que compartilham os mesmo
atributos, operações, relacionamentos e semântica. Podem ser
implementadas em uma ou mais interfaces.

Todos os objetos são instâncias de classes, onde a classe descreve as

propriedades e comportamentos daquele objeto.

Em UML as classes são representadas por um retângulo dividido em três

compartimentos:

 Nome : que conterá apenas o nome da classe modelada;

 Atributos : que possuirá a relação de atributos que a classe
possui em sua estrutura interna;
 Operações : que serão os métodos de manipulação de dados e
de comunicação de uma classe com outras do sistema.

A sintaxe usada em cada um destes compartimentos é independente de

qualquer linguagem de programação, embora podem ser usadas outras
sintaxes como a do C++ e Java.

Existem outras particularidades ligadas as Classes em UML, mas

deixemos isso para os artigos mais avançados.

Nomes

Todas as classes devem ter um nome que as diferencie das demais.

Usamos uma seqüência de caracteres para identificá-las. Uma classe
pode ter um nome simples, ou com caminho. O caminho identifica o
pacote ao qual a classe pertence.
Atributos

Um atributo é uma propriedade de uma classe, que descreve um

intervalo de valores que as instâncias da propriedade podem
apresentar. Uma classe pode ter qualquer número de atributos ou
nenhum. Um atributo representa o tipo de dados ou estados que cada
item de uma classe pode assumir, são representados logo após o nome
da classe.

Operações

As Operações são os processos que a classe pode realizar. As

Operações correspondem claramente a métodos em uma classe. No
nível de especificação, as operações correspondem a métodos públicos.
Normalmente, você não mostra as operações que simplesmente
manipulam atributos, porque elas podem ser freqüentemente inferidas.
Entretanto, você poderá ter que identificar seu um dado atributo é
somente para leitura (isto é, o seu valor nunca muda). No modelo de
implementação, você também pode querer mostrar operações
privativas (private) e protegidas (protected).

Uma classe pode ter várias operações ou até mesmo nenhuma, são
representadas logo após os atributos.
Na Prática

Para que uma fase de programação possa ter um bom desempenho,

necessitamos de um projeto bem elaborado, conseqüentemente
converteremos as classes da fase do projeto para o código da
linguagem orientada a objetos escolhida. Se o desenho foi elaborado
corretamente e com detalhes suficientes, a tarefa de codificação é
facilitada. A complexidade dessa conversão vai depender da capacidade
da linguagem escolhida, no entanto esta pode tornar-se fácil ou difícil
de se realizar.

Em UML durante a elaboração dos modelos de análise e projeto,

devemos evitar traduzi-los em códigos. Cabendo esta tarefa à fase de
programação.

Agora que você já tem uma pequena noção de uma parte das Classes
da UML, vamos abordar os Objetos, que nada mais são do que as
Classes em ação.
Objetos

Definição

Os objetos são elementos que podemos manipular, acompanhar seu

comportamento, criar, interagir com ele, ou até destrui-lo. Um objeto
pode existir no mundo real ou pode ser uma derivação de estudos da
estrutura e comportamento de outros objetos do mundo real.
Corresponde a qualquer coisa que tenha algum significado para uma
dada aplicação. Por exemplo, uma máquina, uma organização, ou
negócio.

Um objeto é simplesmente alguma coisa que faz sentido no contexto de

uma aplicação. Objeto é uma entidade independente, assíncrona e
concorrente, armazena dados, encapsula serviços, troca mensagens
com outros objetos, e é modelado para executar as funções finais do
sistema.

Abstração de um Objeto

Abstração é o princípio de ignorar os aspectos de um assunto não

relevante para o propósito em questão, tornando possível uma
concentração maior nos assuntos principais. Consiste na seleção que o
analista faz de alguns aspectos, ignorando outros. Existem duas formas
de abstração, de Procedimentos e de Dados.

Abstração de Procedimentos

Princípio de que qualquer operação com um efeito bem definido pode

ser tratada por seus usuários como uma entidade única, mesmo que a
operação seja realmente conseguida através de alguma seqüência de
operações de nível mais baixo.

Abstração de dados

Consiste em definir um tipo de dado conforme as operações aplicáveis

aos objetos deste tipo. Porém, estes objetos só podem ser modificados
e observados através destas operações.

Encapsulamento

Encapsular é omitir informações pelo princípio de que uma determinada

entidade esconde informações as quais são necessárias apenas à
mesma. É fundamental que o objeto proteja seus dados, não permitindo
que o usuário do objeto os acesse diretamente. Mas sim através de
métodos se houver necessidade.

Polimorfismo

É o conceito usado em linguagens de programação orientada a objetos

para denotar a característica de que a linguagem suporta a utilização do
mesmo identificador (o mesmo nome) para métodos de classes
diferentes.

Um conceito em teoria de tipo no qual um nome (como uma declaração

de variável) pode denotar objetos de muitas subclasses diferentes que
são relacionadas por alguma superclasse comum, assim, qualquer
objeto denotado por esse nome tem a capacidade de responder a algum
conjunto comum de operações de modos diferentes.

Objetos na UML

Em UML um objeto é mostrado como uma classe só que seu nome é

sublinhado, e o nome do objeto pode ser mostrado opcionalmente
precedido do nome da classe.

Precursores da analise orientada a objeto, defendiam que devíamos

estruturar programas de computador de acordo com o problema a ser
resolvido. O termo Orientação a Objetos sugere abstrações do mundo
real e trechos de programas de computador, ou objeto.

Um grande fator da orientação a objetos é a reusabilidade. Estamos

reutilizando códigos de programas desde o início da computação. As
técnicas de orientação a objetos nos permitem muito mais que a
reutilização de códigos, podemos reutilizar requisitos, análise, projeto,
planejamento de testes, interfaces de usuário e arquiteturas, ou seja
todos os componentes de engenharia de software podem ser
encapsulados como reutilizáveis.

Análise Orientada a Objetos

Análise é o estudo de um problema, antes de qualquer ação.

Análise é o estudo do domínio de um problema que leva a uma

especificação de comportamentos observáveis externamente. É uma
declaração completa, consistente e possível do que é necessário, um
conjunto de características operacionais quantificadas e funcionais.

Analisar é obter as necessidades de um sistema e o que este precisa ser

desenvolvido para satisfazer as necessidades do usuário. Analisar não é
definir como o sistema será desenvolvido, mas sim investigar o
problema

A AOO tem dois propósitos. Primeiramente formalizar uma “visão” do

mundo real dentro do qual o sistema será desenvolvido, estabelecendo
os objetos que servirão como principais estruturas organizacionais do
sistema de software e também as que o mundo real impõe. Em segundo
lugar, a AOO formaliza a colaboração de um dado conjunto de objetos
na execução do trabalho do sistema de software que está sendo
especificado. Esta formalização representa como cada objeto se
comunica com os demais.

O Projeto Orientado a Objetos (PjOO) é visto como o processo de

especificação das partes da construção, ou seja, instruções, guias,
recomendações, estipulações, qualificações, regras, etc.. Utilizamos
estes processos para implementar um sistema em um ambiente
específico, em busca da solução do problema

Durante a PjOO é dado ênfase na elaboração dos elementos lógicos do

software. Sendo implementados em uma linguagem de programação
orientada a objetos, os quais possuem atributos e métodos.

UML - Unified Modeling Language - Estados, Pacotes e Casos de

Uso (Cenários)
Neste artigo vamos conhecer um pouco mais sobre Estados, Pacotes e
Casos de Uso (Cenários) em UML.
Publicado em: 01/09/2005

Estados

Definição

Um estado é uma condição ou situação na vida de um objeto durante a

qual o objeto satisfaz alguma condição, realiza alguma atividade ou
aguarda um evento. Todos os objetos possuem um estado que significa
o resultado de atividades executadas pelo objeto, normalmente este
estado é determinado pelos valores dos atributos e ligações com outros
objetos.
Um objeto muda de estado quando acontece algo, o fato do objeto
alterar o seu estado chamamos de evento. Analisando as mudanças de
estado que um objeto pode sofrer, podemos prever todos os possíveis
comportamentos de um objeto de acordo com os eventos que o mesmo
possa sofrer.
Um estado pode ter três compartimentos: Nome do Evento, Atributos e
Atividades.
• Nome do Evento - mostra o nome do evento, geralmente este nome
descreve o que este estado realiza;
• Atributos – mostra as variáveis de estado, onde os atributos do
objeto em questão pode ser listados e atualizados;
• Atividades – o compartimento de atividades é onde podemos listar
os eventos e ações. Está dividido em três eventos padrões : Entrar, Sair
e Fazer.
Entrar : usado para definir atividades no momento em que o objeto
entra naquele estado;
Sair : usado para definir atividades que o objeto executa antes de
passar para o próximo estado;
Fazer : usado para definir atividades que o objeto executa enquanto se
encontra naquele estado.
Na Prática
O comportamento de uma Classe de Objetos é representado através
de um Diagrama de Transição de Estado, que descreve o ciclo de
vida de uma dada classe, os eventos que causam a transição de um
estado para outro e as ações resultantes da mudança de estado.
O espaço amostral dos estados de uma dada Classe corresponde a
enumeração de todos os estados possíveis de um objeto.
O estado de um Objeto é uma das possíveis condições na qual o objeto
pode existir. O estado compreende todas as propriedades do objetos
(estáticas) associadas aos valores correntes (dinâmico) de cada uma
dessas propriedades.
A notação UML para representar o estado de uma classe corresponde a
um retângulo com a bordas abauladas. Veja figura:

Exemplificando melhor

Estados e Atributos
Estados podem ser distinguidos pelos valores assumidos por certos
atributos.
Exemplo - O número máximo de estudantes por curso, no “Use Case”
Matrícula do Aluno, é igual a 10.
Estados e Ligações
Estados também podem ser distinguidos pela existência de certas
ligações.
Exemplo – A instância da Classe Professor pode ter dois estados:
 Ensinando: quando o Professor esta ministrando um Curso.
 Licenciado: quando não esta ministrando nenhum Curso.
Estados Especiais

Estado Inicial é o estado atribuído a um objeto quando é criado. O

estado Inicial tem as seguintes características:
 É mandatório
 Somente um estado Inicial é permitido.
 O estado Inicial é representado por um círculo preenchido.
Estado Final é o estado que indica o fim do ciclo de vida de um objeto.
O estado Final tem as seguintes características:
 É opcional.
 Pode existir mais de um estado final.
 O estado Final é representado por um “olho de boi”.
Eventos
Um evento é uma ocorrência que acontece em algum ponto no tempo e
que pode modificar o estado de um objeto, podendo gerar uma
resposta.

Exemplos:
 Adicionar um aluno a um curso.
 Criar um novo curso.
Transição
É a mudança do estado atual para o estado subseqüente como
resultado de algum estímulo. O estado subseqüente pode ser igual ao
estado original. Uma transição pode ocorrer em resposta a um evento.
As transições rotuladas com o nome dos eventos.
Condição de Guarda
A condição de guarda é uma expressão Boleana de valores de atributo
que permitem que a transição ocorra somente se a condição assumida
pela expressão é verdadeira.
Ações
É uma operação que está associada a uma transição, ocorrendo
instantaneamente e que não pode ser interrompida. Nome de uma ação
é mostrado, na seta indicativa da transição, precedida por um barra
inclinada (/).
Envio de eventos a partir de outro evento
Um evento pode provocar o envio de outro evento. O nome do evento
enviado é mostrado, na seta indicativa de transição, precedido por um
circunflexo (^) seguido pelo nome da Classe para onde o evento será
enviado, separados por um ponto.
Atividade
É uma operação que está associada a um estado, leva um tempo para
ser executada e que pode ser interrompida.
Envio de eventos a partir de atividade
Uma atividade também pode provocar o envio de um evento para um
outro Objeto.
Transição Automática
Algumas vezes, o único propósito da existência de um estado é
desenvolver uma atividade. Uma transição automática ocorre quando a
atividade é completada. Se múltiplas transições automáticas existem,
uma condição de guarda é necessária para cada transição e as
condições de guarda devem ser mutuamente exclusivas.

Pacotes

Definição

Imagine uma pasta no Windows. Pois bem, Pacote é um mecanismo de

propósito geral para organizar elementos de modelo em grupos,
podendo inclusive, estar aninhando dentro de outros pacotes (pacotes
subordinados). Esta abordagem facilita a análise à medida que o
número de Classes de Objetos cresce num do cenário.

Todos os modelos de elementos que são ligados ou referenciados por

um pacote são chamados de "Conteúdo do pacote". Um pacote possui
vários modelos de elementos, e isto significa que estes não podem ser
incluídos em outros pacotes, apenas referenciados.

Pacotes podem importar modelos de elementos de outros pacotes.

Quando um modelo de elemento é importado, refere-se apenas ao
pacote que possui o elemento. Na grande maioria dos casos, os pacotes
possuem relacionamentos com outros pacotes. Embora estes não
possuam semânticas definidas para suas instâncias. Os relacionamentos
permitidos entre pacotes são de dependência, refinamento e
generalização (herança).

O pacote tem uma grande similaridade com a agregação. O fato de um

pacote ser composto de modelos de elementos cria uma agregação de
composição. Se este for destruído, todo o seu conteúdo também será.

Alguns exemplos:

Pacote vazio:

Pacote composto por classes:

Pacote contendo vários outros itens:

Os Pacotes podem conter muito mais que apenas outros itens, podem
também conter Diagramas, Requisitos, Modelos de Dados, dentre
outros artefatos da UML.

Existem Ferramentas Case que usam o recurso dos Pacotes para

armazenar artefatos contendo Planos de Testes, Planos de Manutenção,
etc.

Exemplos:

Pacote de um Sub-Sistema:
Pacote de um Modelo:

Pacote de Framework:

Agora que você já tem uma pequena noção de Pacotes na UML, vamos
então abordar os Cenários das Use Cases, que nada mais são do que as
necessidades na execução de uma ou mais funcionalidades.

Casos de Uso (Cenários)

Definição

Casos de uso especificam o comportamento do sistema ou parte(s) dele

e descrevem a funcionalidade do sistema desempenhada pelos atores.
Você pode imaginar um caso de uso como um conjunto de cenários,
onde cada cenário é uma seqüência de passos a qual descreve uma
interação entre um usuário e o sistema. Os casos de uso são
representados em forma de elipse.

Não se deve detalhar muito um determinado caso de uso, o seu

detalhamento vai depender do risco que o mesmo corre, quanto maior o
risco, mais detalhes terá o caso de uso.

Ao definir os casos de uso a serem desenvolvidos, trate apenas dos

casos de usos mais críticos para o sistema, os casos de uso que são
tarefas rotineiras não precisam ser desenvolvidos. Dessa forma sua
documentação não se tornará monótona. Numericamente falando, em
modo geral trate apenas de 10 à 20(%) dos casos de uso mais críticos
de seu sistema, estes números citados é claro que podem variar
dependendo do sistema a ser desenvolvido.

Nos nomes dos casos de usos devemos sempre usar verbos, pois assim
facilitará no entendimento dos mesmos. Devemos possuir uma lista com
todos os nomes dos casos de usos para facilitar na identificação dos
mesmos. Preencher todos os requisitos de um caso de uso é de extrema
importância.

Os Cenários

Imagine vários caminhos para realizar alguma tarefa, algum requisito.

Isso são os Cenários, várias possibilidades de atividades, certas ou
erradas.

Exemplo: Abertura de uma conta em um determinado banco. Para essa

operação, você necessita realizar vários passos, que podem resultar em
sucesso ou em problemas. O chamado "caminho sem erros" é o Cenário
Básico, ou Cenário Principal, onde tudo ocorre sem nenhum problema.
Veja:

1. O Cliente solicita a abertura da conta;

2. O Gerente aprova a abertura;
3. O Gerente abre a conta;
4. O Cliente realiza o primeiro depósito;
5. O Cliente ganha o seu cartão magnético.

Percebeu que nesse processo não ocorreram problemas? Esse é o que

chamamos de Cenário Básico.

Agora imagine que no passo 2 do Cenário Básico, o Gerente encontre o

nome do Cliente no SPC, por exemplo, e não abra a sua conta. A essa
situação chamamos de Cenário Alternativo, onde ocorre algum
problema no fluxo do Cenário Básico. Então nosso Cenário Alternativo
fica assim:

1. No passo 2 do Cenário Básico, o Cliente é citado no SPC,

inviabilizando a abertura de sua conta.

Podemos ainda incluir mais situações no Cenário Alternativo:

1. No passo 2 do Cenário Básico, o Cliente é citado no SPC,

inviabilizando a abertura de sua conta;
2. No passo 3 o sistema informatizado do banco apresenta problemas,
retardando a abertura da conta do Cliente;
3. No passo 5 o banco está sem mídia do cartão, ou o cartão do Cliente
ainda não está pronto, retardando a entrega do mesmo ao Cliente.

Dentre outra situações, o importante é prever todas as que realmente

são importantes, que possam ocorrer no Cenário Básico.

UML - Unified Modeling Language - Casos de Uso (Pré e Pós-

requisitos)
Continuando com a séria de artigos vamos conhecer um pouco mais
sobre Pré e Pós-requisitos em Casos de Uso.
Publicado em: 05/09/2005

Casos de Uso (Pré-requisitos)

Definição
Como dito no artigo anterior, os casos de uso especificam o comportamento do
sistema ou parte(s) dele e descrevem a funcionalidade do sistema desempenhada
pelos atores. Você pode imaginar um caso de uso como um conjunto de cenários,
onde cada cenário é uma seqüência de passos a qual descreve uma interação
entre um usuário e o sistema.
Nos nomes dos casos de usos devemos sempre usar verbos, pois assim facilitará
no entendimento dos mesmos. Devemos possuir uma lista com todos os nomes
dos casos de usos para facilitar na identificação dos mesmos. Preencher também
todos os pré-requisitos de um caso de uso é de extrema importância.
Os Pré-requisitos
Imagine um cenário para realizar alguma tarefa. Agora imagine qual é o conjunto
de informações necessárias para realizar tal tarefa. Pois bem, a isso chamamos
de Pré-requisitos, ou os parâmetros de entrada de um cenário.
Exemplo: Novamente a abertura de uma conta em um determinado banco. Para
essa operação, você necessita realizar vários passos, que necessitam de vários
dados de entrada. Imagine os seguintes passos:
1. O Cliente solicita a abertura da conta;
2. O Gerente aprova a abertura;
3. O Gerente abre a conta;
4. O Cliente realiza o primeiro depósito;
5. O Cliente ganha o seu cartão magnético.
Para esses passos o que seria necessário existir, em se falando de informações?
Vamos relacionar:
Do passo 1 até o passo 3:
a) Nome do Cliente;
b) RG do Cliente;
c) CIC do Cliente;
d) Demais dados do Cliente;
e) Entre outras informações.
Percebeu que para um cenário executar as operações, ele necessita de algumas
informações iniciais?
Certo. E destas informações, quais são realmente necessárias para a abertura da
conta?
Certamente o Nome e Documentos do Cliente, pois os demais dados tais como
Endereço, etc., podem ser fornecidos depois, claro dependendo das exigências
do banco.
Dependendo da ferramenta em que você estiver trabalhando para modelar os
casos de uso, essas informações serão inseridas em pontos diferentes do
modelo. Mas temos que ter em mente que essas são informações importantes, e
que sem elas não ocorrem os processos do cenário.
Agora que você já tem uma pequena noção de Pré-requisitos das Use Cases na
UML, vamos abordar os Pós-Requisitos das Use Cases, que nada mais são do
que as condições finais, ou resultados na execução de uma ou mais
funcionalidades.

Casos de Uso (Pós-requisitos)

Definição
Como dito no artigo anterior, os casos de uso especificam o comportamento do
sistema ou parte(s) dele, e descrevem a funcionalidade do sistema
desempenhada pelos atores. Você pode imaginar um caso de uso como um
conjunto de cenários, onde cada cenário é uma seqüência de passos a qual
descreve uma interação entre um usuário e o sistema.
Nos nomes dos casos de usos devemos sempre usar verbos, pois assim facilitará
no entendimento dos mesmos. Devemos possuir uma lista com todos os nomes
dos casos de usos para facilitar na identificação dos mesmos. Preencher também
todos os pós-requisitos de um caso de uso é de extrema importância.
Os Pós-requisitos
Semelhante ao artigo anterior, imagine um cenário para realizar alguma tarefa.
Agora imagine qual é o conjunto de informações resultantes de tal tarefa. Pois
bem, a isso chamamos de Pós-requisitos, ou os parâmetros de saída de um
cenário.
Exemplo: Novamente a abertura de uma conta em um determinado banco. Essa
operação realiza vários passos, que consequentemente resultam em vários dados
de saída. Imagine os seguintes passos:
1. O Cliente solicita a abertura da conta;
2. O Gerente aprova a abertura;
3. O Gerente abre a conta;
4. O Cliente realiza o primeiro depósito;
5. O Cliente ganha o seu cartão magnético.
Esses passos poderiam retornar algumas informações. Por exemplo: do passo 3
ao passo 4, seria necessário saber qual é o número da conta, para que o primeiro
depósito possa ser realizado.
Percebeu que um cenário, ao executar as operações, ele retorna algumas
informações?
Certo. E destas informações, algumas são realmente necessárias para que outros
cenários possam realizar suas operações. Certamente o número da conta é
fundamental para que o banco valide o acesso do cartão à um caixa eletrônico,
por exemplo.
Dependendo da ferramenta em que você estiver trabalhando para modelar os
casos de uso, essas informações podem ser até definidas como não facultativas
no processo do Cenário.
Agora que você já tem uma pequena noção de Pós-requisitos das Use Cases
na UML, no próximo Artigo vamos abordar os Atores, que nada mais são do que
os Usuários ou outros Sistemas, que usam ou manipulam alguma funcionalidade
do Sistema.

UML - Unified Modeling Language - Atores, Atividades e

Componentes
Continuando com a séria de artigos vamos conhecer um pouco mais
sobre atores, atividades e componentes em UML.
Publicado em: 26/10/2005

Atores - Definição

Atores são usuários e/ou outros meios externos que desenvolvem algum papel
em relação ao sistema. Os meios externos são hardwares e/ou softwares que,
assim como os usuários, geram informações para o sistema ou necessitam de
informações geradas a partir do sistema.

Existem atores que podem desempenhar mais de um papel no sistema, quando

se pensar em atores é sempre bom pensar neles como papéis em vez de pensar
como pessoas, cargos, máquinas. No sistema podem ter usuários com diferentes
permissões, para isto é necessário criar um ator para cada diferente tipo de
permissões. Os atores são quem desempenham os casos de uso, um mesmo ator
pode estar em um ou mais casos de uso. Cada ator deve possuir um nome cujo
terá relação direta com a sua função, possuirá uma descrição que definirá o que
ele faz e com quem ele interage.
Vamos pensar em um exemplo:

Imagine um Professor. Ele pode ser um Ator em um Sistema.

Agora pense em que um Professor faz:

 Ministrar Aulas
 Corrigir Provas
 Informar Notas dos Alunos

Certo. Vamos criar mais um Ator em nossa estória: O Coordenador. Bem, um

Coordenador faz:
 Consultar Notas dos Alunos
 Emitir Certificados
 Coordenar Professores
Agora vejamos como fica tudo isso em um Diagrama de Caso de Uso
(aprenderemos Diagramas mais adiante):
Veja que o Professor informa as notas dos Alunos, enquanto o Coordenador
consultas as notas (repare nos sentidos das setas).
Suponha que exista mais um Ator no contexto. Um Ator que desempenha um
papel de um outro Sistema. Vamos inventar aqui um Sistema do Governo, e
imaginar que as notas dos Alunos devem ser informadas a esse Sistema,
representado pelo nosso Ator SIENEM - Sistema Integrado do ENEM. Conforme
nosso Diagrama abaixo, vemos que o Ator SIENEM consulta as notas informadas
pelo Coordenador.

Então, conforme dito acima, um Ator pode ser um Sistema ou um Usuário de um

Sistema.
Agora que você já tem uma pequena noção do que são os Atores na UML, no
próximo Artigo vamos abordar as Atividades, que nada mais são do que os
passos de um processo de alguma funcionalidade do Sistema.

Atividades - Definição

Uma Atividade é essencialmente parte de um fluxo, que interage com uma outra
atividade, podendo ser paralela a ela ou não.
Exemplo de Atividade:

Diagramas de Atividades
Os diagramas de atividades são um caso especial de diagramas de estado, onde
todos os estados têm uma ação interna e nenhuma transição tem um evento de
entrada. O propósito de um diagrama de atividades é focar nos fluxos dirigidos
pelo processamento interno e descrever o comportamento de processamentos
paralelos.

Diagramas de atividade capturam ações e seus resultados. Eles focam o trabalho

executado na implementação de uma operação (método), e suas atividades numa
instância de um objeto. O diagrama de atividade é uma variação do diagrama de
estado e possui um propósito um pouco diferente do diagrama de estado, que é o
de capturar ações (trabalho e atividades que serão executados) e seus resultados
em termos das mudanças de estados dos objetos.
Os diagramas de atividades são usados para detalhar classes, implementação de
operações e casos de uso, enquanto os diagramas de estado são usados para
especificar o comportamento global de um tipo.
Um diagrama de atividade é uma maneira alternativa de se mostrar interações,
com a possibilidade de expressar como as ações são executadas, o que elas
fazem (mudanças dos estados dos objetos), quando elas são executadas
(seqüência das ações), e onde elas acontecem (os divisores ou swimlanes).
Os Divisores

Os diagramas de atividades representam o que acontece, mas não representam

quem faz o que. Isso significa que o diagrama não diz qual classe é responsável
por cada atividade. Veja:

No exemplo acima “Cadastrar” e “Alterar” podem pertencer à mesma Classe.

Neste caso, os divisores contornam esse problema através da organização das
responsabilidades das atividades dentro de uma classe. Veja:
Através dos divisores podemos separar as atividades de acordo com as classes
responsáveis por essas atividades. Os divisores são representados por linhas
verticais tracejadas.

Aplicações

Um diagrama de atividade pode ser usado com diferentes propósitos inclusive:

 Para capturar os trabalhos que serão executados quando uma operação é
disparada (ações). Este é o uso mais comum para o diagrama de atividade.
 Para capturar o trabalho interno em um objeto.
 Para mostrar como um grupo de ações relacionadas pode ser executado, e
como elas vão afetar os objetos em torno delas.
  Para mostrar como uma instância pode ser executada em termos de ações
e objetos.
 Para mostrar como um negócio funciona em termos de trabalhadores
(atores), fluxos de trabalho, organização, e objetos (fatores físicos e
intelectuais usados no negócio).
Conclusão

O diagrama de atividade mostra o fluxo seqüencial das atividades, é normalmente

utilizado para demonstrar as atividades executadas por uma operação específica
do sistema. Consistem em estados de ação, que contém a especificação de uma
atividade a ser desempenhada por uma operação do sistema. Decisões e
condições, como execução paralela, também podem ser mostradas na diagrama
de atividade. O diagrama também pode conter especificações de mensagens
enviadas e recebidas como partes de ações executadas.

Agora que você já tem uma pequena noção do que são as Atividades na UML,
no próximo Artigo vamos abordar os Componentes, que nada mais são do que
aspectos físicos do Sistema sendo modelado.

Componentes - Definição

Segundo Furlan, os Componentes mostram aspectos físicos entre as partes de

um software.

Diagramas de Componentes

Os diagramas de componentes representam, de forma estática, aspectos físicos

do sistema sendo modelado. São importantes tanto para visualizar, especificar e
documentar sistemas, quanto para construir sistemas através de engenharia
reversa (reverse) e direta (forward). Os diagramas mostram um conjunto de
componentes e seus relacionamentos.

São tipicamente usados para:

 Modelar a organização do código fonte:
 Modelar lançamento de executáveis (versões):

 Modelar fisicamente um banco de dados:

Na realidade esse tipo de diagrama mostra o sistema por um lado funcional,
expondo as relações entre seus componentes e a organização de seus módulos
durante sua execução, descrevendo os componentes de software e suas
dependências entre si, representando a estrutura do código gerado. Os
componentes são a implementação na arquitetura física dos conceitos e da
funcionalidade definidos na arquitetura lógica (classes, objetos e seus
relacionamentos). Eles são tipicamente os arquivos implementados no ambiente
de desenvolvimento.
Um componente é mostrado em UML como um retângulo com uma elipse e dois
retângulos menores do seu lado esquerdo. O nome do componente é escrito
abaixo ou dentro de seu símbolo. Veja mais alguns exemplos:
Componentes são tipos, mas apenas componentes executáveis podem ter
instâncias. Um diagrama de componente mostra apenas componentes como
tipos. Para mostrar instâncias de componentes, deve ser usado um diagrama de
execução, onde as instâncias executáveis são alocadas em nodes.
Aprenderemos isso mais adiante.
Agora que você já tem uma pequena noção do que são os Componentes na
UML, no próximo Artigo vamos abordar os Adornos, que nada mais são do que
comentários presentes nas modelagens.

UML - Unified Modeling Language - Adornos e Nós

Continuando com a séria de artigos vamos conhecer um pouco mais
sobre adornos e nós em UML.
Publicado em: 09/12/2005

Adornos

Definição

Um Adorno é um comentário preso a um elemento ou a uma coleção de

elementos. Um Adorno não possui semântica, pois é apenas uma
"anotação".
Como a UML nunca será capaz de captar 100% das idéias reais do
Projeto, usamos os Adornos para expressar pequenos detalhes,
pequenas observações, visando complementar a informação presente
no elemento, no relacionamento entre elementos, etc.

É muito simples representar um Adorno. Basta desenhar um símbolo

semelhante a uma pequena folha, como uma anotação, e escrever em
seu interior as informações pertinentes. Veja alguns exemplos simples:

Figura 1 - Adorno em uma Classe

Figura 2 - Adorno em um Relacionamento

O mais importante é ser claro e objetivo, e usar esse recurso quando

for realmente necessário.

Agora que você já tem uma pequena noção do que são os Adornos na
UML, vamos abordar os Nós, que nada mais são do que notações de
objetos físicos presentes nas modelagens.

Nós

Definição

Um nó é um objeto físico em tempo de execução que representa um

recurso computacional, possuindo, geralmente, pelo menos uma
memória, bem como, uma capacidade de processo. Objetos em tempo
de execução e componentes podem residir em nó. Graficamente, um Nó
é representado pelo desenho de um Cubo. Veja um pequeno exemplo:

Figura 1 - Um Banco de Dados e um Servidor de Rede

A UML é, principalmente, destinada a modelar softwares intensivos,

continuados, embora também intimamente ligada ao fator Hardware,
pois de certa forma toda a arquitetura dos equipamentos faz parte da
análise do Sistema a ser modelado, sendo a UML completamente capaz
de expressar todo o Sistema fisicamente, em formatos stand-alone,
client-server ou distribuídos.

Veja abaixo um exemplo mais completo de uma pequena arquitetura

definida por meio de 2 Nós:
 Figura 2 - Um Banco de Dados, um Servidor de Rede, seguidos das
aplicações

Agora que você já tem uma pequena noção do que são os Nós na UML,
no próximo Artigo vamos abordar os Relacionamentos entre os
elementos da UML, que nada mais são do que as ligações existentes
entre os elementos estudados até agora. Vamos começar estudando os
Relacionamentos do tipo "Generalização".

UML - Unified Modeling Language - Generalização, agregação,

composição e dependência
Continuando com a séria de artigos vamos conhecer um pouco mais
sobre generalização, agregação, composição e dependência em UML.
Publicado em: 13/02/2006

Generalização
Definição
É a capacidade de se criar superclasses que encapsulam estrutura e/ou
comportamento comuns a várias subclasses.
Procedimentos
Os procedimentos para se obter a generalização são:
 Identificar similaridades de estrutura/comportamento entre várias Classes.
 Criar a superclasse para encapsular a estrutura/comportamento comum.
 As classes originais passam a ser subclasses da nova superclasse criada.
Uma maneira relativamente fácil de se entender isso, é comparando com a nossa
herança genética: Você possui algumas características de seus Pais. Mas seus
Pais não possuem suas características. Pois bem, você seria uma subclasse.
Outra maneira de se compreender é entendo o conceito de Herança.
Herança
É uma hierarquia de abstrações na qual uma subclasse herda a estrutura e/ou
comportamento de uma ou mais superclasses. Exemplo:

A classe VeículoTerrestre pode possuir as subclasses Carro e Caminhão, onde

as subclasses podem herdar os Atributos Peso e Comprimento.
A Classe Caminhão pode ter o Atributo Tonelagem próprio da Classe, herdando
Peso e Comprimento.
A Classe Carro pode não ter nenhum Atributo próprio, herdando Peso e
Comprimento da classe VeículoTerrestre.
Caminhão é uma espécie de VeículoTerrestre.
Carro é uma espécie de VeículoTerrestre.
Tipos de Herança
Herança simples é quando uma subclasse herda estrutura e/ou comportamento
de uma única superclasse.
Herança múltipla é quando uma subclasse herda estrutura e/ou comportamento
de mais de uma superclasse.
IMPORTANTE: Herança é uma relação entre Classes de Objetos, e não uma
relação entre instância das Classes.
Uma subclasse herda:
 Atributos
 Operações
 Relacionamentos
 Uma subclasse pode:
 Adicionar novos atributos, operações e relacionamentos.
 Redefinir operações herdadas.
Agora que você já tem uma pequena noção do que é um Relacionamento
Generalização na UML, vamos abordar o Relacionamento Agregação.

Agregação
Definição
É uma forma especializada de associação na qual um todo é relacionado com
suas partes. Também conhecida como relação de conteúdo.
Como representamos uma Agregação?
É representada como uma linha de associação com um diamante junto à Classe
agregadora. A multiplicidade é representada da mesma maneira que nas
associações. Veja a figura:

A Agregação é um caso particular da associação, indica que uma das classes do

relacionamento é uma parte, ou está contidaem outra classe. Aspalavras chaves
usadas para identificar uma agregação são: "consiste em", "contém", "é parte de".
Agregação Compartilhada: É dita compartilhada quando uma das classes é uma
parte, ou está contida na outra, mas esta parte pode estar contida na outra várias
vezes em um mesmo momento. Veja figura:
Agregação Reflexiva: Uma variação desse tipo de Relacionamento, quando o
Objeto de uma Classe é composto de Objetos da própria Classe. Veja figura:

Um objeto da Classe FormulárioDeRegistro contém um único objeto

FormulárioDeMatrícula. Um objeto FormulárioDeMatrícula está contido num
único objeto FormulárioDeRegistro.
Agora que você já tem uma pequena noção do que é uma Agregação na UML,
vamos abordar os Relacionamentos de Composição na UML, que nada mais são
do que um tipo de Agregação.

Composição
Definição
É uma agregação onde uma classe que está contida na outra "vive" e constitui a
outra. Se o objeto da classe que contém for destruído, as classes da agregação
de composição serão destruídas juntamente, já que as mesmas fazem parte da
outra.
Como representamos uma Agregação Composição?
É representada como uma linha de associação com um diamante preenchido
junto à Classe agregadora. A multiplicidade é representada da mesma maneira
que nas associações. Veja as figuras:
Veja um exemplo mais completo:

Agora que você já tem uma pequena noção do que é uma Agregação
Composição na UML, vamos abordar os Relacionamentos de Dependência.

Dependência
Definição
Uma dependência indica a ocorrência de um relacionamento semântico entre
dois ou mais elementos do modelo, onde uma classe cliente é dependente de
alguns serviços da classe fornecedora, mas não tem uma dependência estrutural
interna com esse fornecedor [Furlan, 1998]
Como funciona?
Por exemplo: Uma mudança no elemento independente irá afetar o modelo
dependente. Como no caso anterior com generalizações, os modelos de
elementos podem ser uma classe, um pacote, um use-case e assim por diante.
Na Prática
Quando uma classe recebe um objeto de outra classe como parâmetro, uma
classe acessa o objeto global da outra. Nesse caso existe uma dependência entre
estas duas classes, apesar de não ser explícita.
Graficamente
Uma relação de dependência é simbolizada por uma linha tracejada com uma
seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de
dependência que existe entre as duas classes. Veja a figura:

Agora que você já tem uma pequena noção do que é uma Dependência na UML,
vamos abordar os Esteriótipos na UML.

UML - Unified Modeling Language - Esteriótipo Include,

Esteriótipo Extend, Esteriótipo Realize
Continuando com a séria de artigos vamos conhecer um pouco mais
sobre esteriótipos.
Publicado em: 27/03/2006
Esteriótipo Include

Definição de Esteriótipo
Entenda Esteriótipo como sendo uma especialidade de .um
Relacionamento.

Definição de Include
Essa notação é usada para representar sub-fluxos complexos e comuns
a vários casos de uso, sempre usados, isto é, necessários.

Na Prática
O caso de uso "incluído" é referenciado no fluxo do caso de uso
"incluidor". Imagine isso como uma situação que ocorre sempre quando
uma outra situação também ocorre. O caso de uso A inclui o caso de
uso B quando B representa uma atividade complexa, comum á vários
casos de uso.

Exemplo
Na Figura abaixo, "Checar Senha" representa um comportamento
comum á "Sacar Dinheiro" e "Realizar Transferência". Veja:

Agora que você já tem uma pequena noção do que é um Esteriótipo

Include na UML, no próximo Artigo vamos abordar o Esteriótipo Extend.
Esteriótipo Extend

Definição
Essa notação é usada para representar sub-fluxos complexos e comuns
a vários casos de uso, usados eventualmente, isto é, facultativos.

Na Prática
O caso de uso "extendido" é referenciado no fluxo do caso de uso
"principal". Imagine isso como uma situação que pode ocorrer quando
uma outra situação também ocorre. O caso de uso B estende o caso de
uso A, apenas quando necessário.

Exemplo
Na Figura abaixo, "Realizar Primeiro Depósito" representa um
comportamento facultativo à "Abrir Conta Corrente". Veja:

IMPORTANTE: A ponta da seta sempre está para o lado do objeto que

recebe a funcionalidade estendida.

Agora que você já tem uma pequena noção do que é um Esteriótipo

Extend na UML, no próximo Artigo vamos abordar o Esteriótipo Realize.

Esteriótipo Realize

Definição
Este Esteriótipo é muito usado para definir uma Realização, quando
tipicamente um Caso de Uso realiza um Requisito.

Exemplo
Veja abaixo um exemplo de um Caso de Uso realizando um Requisito:
Agora que você já tem uma pequena noção do que é um Esteriótipo
Realize na UML, no próximo Artigo vamos abordar o Esteriótipo Table.

UML - Unified Modeling Language - Esteriótipo Table, Esteriótipo

Call, Esteriótipo Create
Continuando com a séria de artigos vamos conhecer um pouco mais
sobre esteriótipos.
Publicado em: 19/05/2006

Esteriótipo Table

Definição

Este Esteriótipo é simplesmente uma classe com características de uma

entidade de banco de dados, onde os atributos fazem o papel dos
campos da Tabela, e as operações são as Triggers e índices.

Exemplo

Veja abaixo um exemplo de Table. Repare que os Atributos (campos)

possuem seus tipos de dados, e alguns são marcados como chaves
primárias ou chaves estrangeiras:
Neste caso ainda existe uma chave estrangeira [CodigoTipo] na Tabela
[Cliente], que corresponde ao Tipo do Cliente, onde cada um dos
Clientes pode ser de um Tipo apenas, e cada Tipo pode ser usado por
vários Clientes.

Esteriótipo Call

Definição

Este Esteriótipo especifica que a operação de origem chama a operação

de destino.

Exemplo

Veja abaixo um exemplo de Call. Veja o sentido da seta no

Relacionamento:
Neste exemplo a Classe clsPrincipal do Projeto "chama" a operação
"abrirTela" nela mesma. Logo depois a Classe clsPrincipal "chama" a
operação "executaCadastro" dentro de uma outra Classe do Projeto
chamada "clsModulo". Este tipo de diagrama nós vamos estudar mais à
frente, a idéia aqui é exemplificar o esteriótipo Call.

Esteriótipo Create

Definição

Este Esteriótipo especifica que o objeto destino é criado, pelo evento ou

pela mensagem, do objeto origem.

Exemplo

Veja abaixo um exemplo do Create:

Neste exemplo a Classe clsPrincipal "cria" o objeto da Classe clsModulo,
abre a tela, e "chama" a operação "executaCadastro" dentro da Classe
criada. Este tipo de diagrama nós vamos estudar mais à frente, a idéia
aqui é exemplificar o esteriótipo Create.

Agora que você já tem uma pequena noção do que é um Esteriótipo

Create na UML, no próximo Artigo vamos abordar Diagramas, iniciando
pelo Diagrama de Atividade.

A importância do Modelagem de Objetos no Desenvolvimento de

Sistemas
Este artigo tem como objetivo expor a importância da modelagem na
produção de um software. Inicialmente são mostradas as vantagens da
utilização de modelos para um sistema e os problemas que podem
ocorrer quando não é realizada nenhuma modelagem ou quando se
utiliza modelagem incorreta. Depois, o artigo apresenta a técnica da
modelagem baseada em objetos e a relevância de sua utilização.
Publicado em: 27/04/2007
Compartilhe

1. INTRODUÇÃO

Para se construir uma casa ou um prédio de qualidade, é essencial fazer

um planejamento detalhado, com a finalidade de pensar sobre as
formas de construção, fazer estimativas de tempo e material para a
realização desse projeto.

O desenvolvimento de um software de qualidade é semelhante a este

processo, pois também se trata de uma questão de arquitetura e
ferramentas.

Softwares malsucedidos têm falhas específicas de cada um, mas todos

os projetos bem-sucedidos são semelhantes em diversos aspectos. Um
dos elementos que contribuem para o sucesso de um software é a
utilização da modelagem.

Para fazer bons modelos deve-se utilizar uma linguagem de modelagem

que seja dotada de diagramas que permitam a representação de
sistemas simples ou complexos sob as diferentes visões, pois isso
facilita o entendimento e padroniza a comunicação e a organização do
problema.

Este artigo apresenta uma abordagem sobre a importância da

modelagem de objetos em um projeto de software.

2. ABSTRAÇÃO

Abstração é o processo seletivo de determinados aspectos de um

problema.

O objetivo da abstração é isolar aspectos que sejam importantes para

algum propósito e suprimir os que não forem.

A abstração deve sempre visar um propósito para determinar o que é e

o que não é importante.

3. A MODELAGEM

Um modelo é uma simplificação da realidade. Os modelos podem

realizar planos detalhados, assim como planos mais gerais com uma
visão panorâmica do sistema. Um bom modelo inclui detalhes e
componentes de grande importância e omite os componentes menores
que não necessitam de representação em determinado nível de
abstração.

Na modelagem, podemos delimitar o problema que estamos estudando,

dividindo-o em vários problemas menores, restringindo a atenção a um
único aspecto por vez até chegar à solução.
Mesmo que não se utilize uma modelagem formal para desenvolver um
software, sempre é feito algum tipo de modelo, mesmo que de maneira
muito informal. Porém, esses modelos informais não oferecem uma
linguagem que pode ser compreendida por outras pessoas facilmente.

No setor de softwares comerciais, muitas vezes os programas são

inadequados para a empresa e não atendem às necessidades dos
usuários, devido à produtividade e facilidade oferecidas pelas
linguagens de programação visual, e quanto mais complexo for o
sistema, maior será a probabilidade de ocorrência de erros, no caso de
ter sido feito sem nenhum tipo de modelagem.

Na construção de um sistema simples, inicialmente a modelagem pode

não ser tão necessária, mas a tendência de um sistema funcional é que
ele se torne mais complexo ao longo do tempo, precisando de
atualização e aperfeiçoamento. Portanto, à medida que o sistema
evoluir e não houver nenhuma documentação com a modelagem, o
trabalho será muito maior e ainda com o risco de ter um sistema mal-
sucedido.

Qualquer projeto será beneficiado pelo uso de algum tipo de

modelagem. Os modelos auxiliam a equipe a ter uma visão mais
abrangente do funcionamento do sistema, e assim, desenvolvê-lo de
forma mais rápida e correta.

4. A MODELAGEM IDEAL

Qualquer sistema precisa de algum tipo de modelagem. Mas deve-se

escolher um tipo de modelagem que seja correto para o sistema.

Quando os modelos são adequados para o software que está sendo

desenvolvido, os problemas são resolvidos mais claramente, mas
quando se escolhe um modelo errado, ao invés de ajudar, ele pode
complicar ainda mais o problema, causando confusões e desviando a
atenção para detalhes que não são importantes para aquela situação.

Em qualquer situação, os melhores modelos são aqueles que permitem

escolher o grau de detalhamento. Dependendo do sistema, um modelo
que mostra a interação com o usuário, de execução rápida e simples,
pode ser o ideal, mas, em outros casos, será necessário retornar a
níveis mais baixos, como ao especificar interfaces para várias
plataformas ou quando o sistema se depara com congestionamentos em
uma rede.
5. DIFERENTES VISÕES

Um sistema pode ser analisado sob diferentes perspectivas, de acordo

com a visão de quem vai realizar a análise.

Um desenvolvedor de banco de dados tem uma perspectiva direcionada

a modelos de relacionamento entre entidades e tabelas, dando ênfase a
procedimentos de armazenamento e eventos que os iniciam.

Na perspectiva de um profissional de análise estruturada, o foco será

nos algoritmos, com o respectivo fluxo de dados de um processo para
outro.

Se um sistema é construído a partir da perspectiva de um

desenvolvedor orientado a objetos, provavelmente a arquitetura será
centrada na interação entre classes e como essas classes funcionam em
conjunto. Os conceitos baseados em objetos são os que resultam em
arquiteturas mais flexíveis porque podem ser aplicados durante todo o
ciclo de vida do sistema, desde a análise até o projeto e a
implementação. As mesmas classes podem ser conservadas em todas
as etapas, sem modificações, embora possam receber detalhes
adicionais nas etapas finais.

6. A TÉCNICA DE MODELAGEM DE OBJETOS

A técnica de modelagem de objetos é uma metodologia que combina

três tipos de modelos para descrever um sistema: modelo de objetos,
modelo dinâmico e modelo funcional. São modelos a partir dos três
pontos de vista mostrados anteriormente, que são relacionados, mas
diferentes entes si, cada um abrange importantes aspectos do sistema,
mas todos são necessários para uma descrição completa.

6.1 MODELO DE OBJETOS

O modelo de objetos descreve a estrutura estática de um sistema, isto

é, a estrutura de seus objetos e os relacionamentos existentes entre
eles em um determinado instante de tempo, os atributos e as operações
que caracterizam cada classe de objetos.

Este é o mais importante dos três modelos porque é o que melhor

representa a realidade, sendo mais adaptável às modificações.

Os modelos baseados em objetos apresentam uma intuitiva

representação gráfica e são úteis para a comunicação com os clientes e
para a documentação da estrutura do sistema.

Exemplo de um modelo de objetos representado por um diagrama de

classes:

6.2. MODELO DINÂMICO

O modelo dinâmico descreve os aspectos de um sistema examinado as

modificações ocorridas nos seus objetos e seus relacionamentos em
relação ao tempo.

Os principais conceitos da modelagem dinâmica são os eventos, que

representam os estímulos externos, e os estados, que representam o
intervalo entre esses eventos e especificam o contexto em que são
interpretados.

A representação gráfica é feita pelos diagramas de estados. Cada um

desses diagramas mostra seqüências de eventos, estados e operações
que ocorrem no interior de um sistema para cada classe de objetos.

Exemplo de um diagrama de estado:

Componentes:

6.3. MODELO FUNCIONAL

O modelo funcional abrange o que um sistema faz e mostra como os

valores de saída de um processamento derivam do processo de entrada,
independente da ordem em que os valores são processados.

É representado graficamente por meio do diagrama de fluxo de dados

(DFD), que mostra o relacionamento funcional entre dados em um
sistema, incluindo-se valores de entrada e saída e depósitos internos de
dados.
Exemplo de um diagrama de fluxo de dados:

7. CONCLUSÃO

Os modelos são construídos para compreender melhor o sistema que

está sendo desenvolvido.

A escolha dos modelos tem profunda influência sobre como uma

situação é resolvida, pois a modelagem tem que ser adequada para o
sistema.

Nenhum modelo único é suficiente. Um sistema pode ser analisado sob

diferentes perspectivas.

A técnica de modelagem baseada em objetos é uma combinação de três

modelos, a partir de três pontos de vistas, que podem ser estudados
separadamente, mas que funcionam em conjunto, por isso, proporciona
melhor entendimento dos requisitos, projetos menos complicados e
sistemas de manutenção mais fácil.

8. REFERÊNCIAS

[1] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML, guia do

usuário. Rio de Janeiro: Campus, 2000.

[2] RUMBAUGH, James; BLAHA, Michael; PREMERLANI, William; EDDY,

Frederick; LORENSEN, William. Modelagem e Projetos Baseados em
 Objetos. Rio de Janeiro: Campus, 1994.

[3] FURLAN, José Davi. Modelagem de Objetos através da UML. São

Paulo: Makron Books, 1998.

Aprenda a construir seus códigos a partir de modelos UML, com

o Visio 2003 / Visual Studio 2003 Architet
Através deste artigo pretendo demonstrar como ficou fácil gerar os seus
códigos através de um modelo UML.
Publicado em: 04/02/2004

Através deste artigo pretendo demonstrar como ficou fácil gerar os seus
códigos através de um modelo UML. Uma vez que você tiver com seu
modelo no Visio Architet, a versão que vem com o Visual Studio 2003
será só escolher a linguagem desejada e ele se encarregará de escrever
os códigos necessários. Atualmente é possível gerar códigos para C#,
VB e C++.

Vamos ver como isso funciona na pratica, passo a passo. Começaremos

criando um diagrama de Classe simples e em seguida veremos o código
que será gerado.

Primeiramente, criaremos uma classe chamada EMPREGADO, com os

seguintes campos: ID, Nome, Sexo, DataNasc, Salário, Função, etc.

Abra o Visio, escolhendo o tipo do diagrama ou através do menu:

File-> New-> Software-> UML Model Diagram.

Tela Inicial de um documento do Visio.

Click com o botão direito sobre Top Package, no Model Explore e Altere
o Nome do pacote para RH.

Em seguida arraste um Shapes classe para o diagrama, e dê duplo

click nele. Será apresentada a Janela de propriedades da classe. Digite
EMPREGADO, no campo Name.
Agora vamos informar os Atributos da Classe. Informe os seguintes
campos em Atributes: ID do tipo int e Salário tipo decimal e click no
botão OK deverá ficar como apresentado na seguinte figura:

Podemos agora verificar como ficará a classe gerada, apesar de que

ainda temos muito trabalho pela frente. Escolha Code Generation
Options, e escolha a linguagem desejada, exemplo C#, e clique no
botão preview code.
Resultado do código gerado

Vamos criar um novo tipo de Dados, antes disso porém precisamos

acrescentar um pacote novo, que conterá um novo tipo de dados.
Selecione o pacote RH, e com o botão direito do mouse, escolha a
opção New->Package, informe System no campo Name.
Agora façamos o seguinte, selecione o novo pacote System, e com o
botão direito escolha New->DataType. Na caixa de Propriedades no
campo name digite DateTime.

Agora retornamos a classe Empregado, dê um duplo click para mostrar

a caixa de propriedades, adicione um novo atributo DataNasc, e você
verá que agora será possível selecionar o novo tipo System::DateTime.
Vamos ver o código gerado novamente selecionando a opção Code
Generation Options, e depois click no botão Preview code. Você verá
que agora foi acrescentado o name space System no inicio da classe.

Vamos agora criar as propriedades, para que possam ser acessadas

pelos clientes da classe. Criaremos propriedades de retornam os valores
para ID, DataNasc e Salário. Dê um duplo clique na classe para chamar
a caixa de propriedades, em seguida selecione Operations, e informe os
Nomes e valores de retorno, idênticos aos campos definidos
anteriormente.
Marque a operação ID, click no botão Properties, para ter acesso as
propriedades desta operação, escolha Code Generation Opctions, altere
o campo Kind de procedure para property, e marque o check box,
Create Get Method, procedendo assim, estamos criando uma
propriedade de apenas leitura.

Para criar uma propriedade com atributo de leitura e gravação, marque

também o check box Cerate Set Method, mas neste exemplo não será
necessário. Click no botão Preview code, e você verá o código, que será
gerado para esta propriedade. Não se esqueça de clicar no botão OK, as
alterações somente terão efeito após esta confirmação.
Faltou, porém escrevermos o retorno dos dados para nosso GET.
Também poderíamos já ir documentando nosso código, preenchendo a
caixa de texto Documentation. Dê um duplo click na classe, para
apresentar a caixa de propriedades. Selecione Operations, marque a
Operação ID, click no botão Methods, Selecione a Linguagem no combo,
language para Code, e escreva o corpo do método, no nosso caso
return ID;

Ao solicitarmos o preview do código obteremos o seguinte código:

Vamos criar um método para efetuar a alteração do Salário do
empregado, para isso adicionaremos um novo método chamado
AlterarSalario.

Para este método incluiremos também um parâmetro chamado Valor,

que será o novo valor atribuído ao Salário do empregado. Marque a
operação AlterarSalario, click em Properties, digite o comentário, em
Documentation, e depois selecione Parameters, na caixa de Categories.
Click em New, e entre como o nome do parâmetro Valor, sendo do tipo
decimal.
Agora, digite o código abaixo no corpo de método para alterar o campo
salário da classe.

Veja agora como ficou o código gerado, selecione Code Generation

Options, e em seguida no botão Preview Code.
Agora criaremos uma interface chamada Pessoa, que define o
comportamento da Classe. Arraste o Shape Interface para o diagrama
ou click com o botão direito em RH, escolha New
Informe o Nome da interface no campo Name.

Agora definiremos as propriedades da interface pessoa que serão

herdadas e implementadas na classe Empregado. Note que na interface
temos apenas Operations.
Defina o tipo de retorno das operações Nome, CPF e RG para String.
Altere também o tipo das operações para Property, e defina como
leitura e gravação, marcando os dois checkbox, para criar os métodos
Get e Set, faça isso para todas as operações, não esquecendo de
confirmar com OK, pois somente será gerado o código após a
confirmação.

Veja como ficou o código gerado. Observe que no código não há a uma
implementação para os métodos Get e Set, pois isso será feito na classe
que usará esta interface.
Vamos vincular a interface pessoa a classe empregado. Selecione a
interface no diagrama, e com o botão direito do mouse, escolha a opção
Show as lolipop Interface, você obterá o seguinte resultado:
Observe que a interface é representada pelo Shapes na forma de um
pirulito.

Click, no pirulito e arraste para a classe empregado, até que o objeto

fique conforme a figura abaixo:

Ao soltar o botão do mouse, você verá que todos as operações da

interface automaticamente aparecerão na classe.

Selecione a interface pessoa e com o botão direito do mouse, solicite

para mudar a visão novamente para Show as Class-like interface, o
resultado será um relacionamento de dependência entre a classe
Empregado e a interface pessoa.
Veja também como ficou o código gerado para a Classe empregado.
Verá que o sistema definiu a classe empregado como sendo uma
herança da interface pessoa.

Definiremos agora os outros tipos de dados: Sexo, Endereço e Telefone.

Primeiro vamos criar um enumeração para sexo, faça isso selecionando
RH, e com o botão direito do mouse escolha:

New->DataType.
Digite Genero, no campo Name, e altere o stereotype para
enumeration.

Informe os valores possíveis: Masculino e Feminino, você também

poderá informar um valore literal para eles.
Volte na interface pessoa, adcione a operação Sexo, altere o tipo para
propriedade, defina o acesso para os métodos Get e Set e informe o

tipo de retorno Genero.

Repare que automaticamente, o tipo sexo da classe empregado

assumira o novo valor.
Acompanhe também como ficou o código gerado tanto na interface
como na classe, o Visio transforma UML em código.
Veja o código da classe agora gerado nas outras linguagens

VB.NET

C++
Obs: Os códigos do C++ apresentam alguns erros nos tipos dos dados,
deverão ser alterado para o tipo apropriado. Poderíamos também ter
definido os tipos comuns às várias linguagens, em vez de ter escolhido
especificamente tipos do C#, como fizemos, mas este exemplo tem
como finalidade de demonstração dos recursos do VS, portanto poderá
ser melhorado, mas isso, vou deixarei como exercício para os leitores.

Bem, agora as falta enviar o código gerado para o Visual Studio, já que
a versão atual do Visio não está integrada ao ambiente do VS, por
enquanto...
Selecione o menu UML, vá em CODE, escolha Generate, marque o
check box RH, e desmarque a System, não é necessário gerar o código
para o Framework. Altere a localização onde você deseja gerar a
solução.

Agora abra o Visual Studio, encontre e selecione o projeto que foi

gerado pelo Visio.

Veja que o projeto está ai, pronto para ser usado.

Espero que este artigo ajude os leitores a entender um pouco sobre os
recursos disponível neste maravilhoso produto. Em outra oportunidade,
falarei mais sobre outros conceitos, como herança, Associação,
composição e agregação. Até lá.