Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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.
INTRODUÇÃO
CENÁRIO
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.
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.
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:
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.
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.
Pedido
Pesquisa satisfação
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:
As perguntas com resposta Sim, serão novas classes, segue abaixo as novas classes
encontradas:
Situações
Tipo de Serviços
Prazos
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
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.
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.
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:
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
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.
Figura Error! Bookmark not defined.- Diagrama de classe sem ligações e cardinalidade
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
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:
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.
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.
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.
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.);
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.
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 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
REFERÊNCIAS
Melo, Ana Cristina. Desenvolvendo Aplicações com UML, 1 ºEdição, Brasport, 2002.
ISO 9001.
Requisitos
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
Nomes
Operações
Uma classe pode ter várias operações ou até mesmo nenhuma, são
representadas logo após os atributos.
Na Prática
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
Abstração de um Objeto
Abstração de Procedimentos
Abstração de dados
Encapsulamento
Polimorfismo
Objetos na UML
Estados
Definição
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
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
Alguns exemplos:
Pacote vazio:
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.
Definição
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
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.
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.
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.
Ministrar Aulas
Corrigir Provas
Informar Notas dos Alunos
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.
Aplicações
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
Diagramas de Componentes
Adornos
Definição
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
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".
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:
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:
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.
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:
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:
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.
Esteriótipo Table
Definição
Exemplo
Esteriótipo Call
Definição
Exemplo
Esteriótipo Create
Definição
Exemplo
1. INTRODUÇÃO
2. ABSTRAÇÃO
3. A MODELAGEM
4. A MODELAGEM IDEAL
7. CONCLUSÃO
8. REFERÊNCIAS
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++.
Click com o botão direito sobre Top Package, no Model Explore e Altere
o Nome do pacote para RH.
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.
New->DataType.
Digite Genero, no campo Name, e altere o stereotype para
enumeration.
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.