Apostila UML

Índice
Conceitos Iniciais................................................................................................................................. 3
Classe............................................................................................................................................... 3
Objeto...............................................................................................................................................3
Generalização...................................................................................................................................4
Herança........................................................................................................................................4
Sobrecarga ( Overloading )......................................................................................................... 4
Assinaturas idênticas.............................................................................................................. 4
Assinaturas diferentes.............................................................................................................4
Sobrescrita ( Overriding )............................................................................................................6
Polimorfismo...............................................................................................................................7
Encapsulamento ......................................................................................................................... 7
Ocultação de informações e Implementações.................................................................................. 7
Retenção de Estado.......................................................................................................................... 7
Identidade de um Objeto.................................................................................................................. 8
O Projeto Orientado a Objetos..............................................................................................................8
Atividades Relacionadas ao Projeto OO..........................................................................................8
UML – Unified Modeling Language............................................................................................... 9
Metas UML....................................................................................................................................10
Especialização / Generalização......................................................................................................11
Inclusão.......................................................................................................................................... 11
Extensão.........................................................................................................................................12
Documentos iniciais.......................................................................................................................12
Modelo de um documento Visão................................................................................................... 13
Diagrama de Caso de Uso..............................................................................................................16
O Ator .......................................................................................................................................16
Considerações sobre Atores...................................................................................................... 16
Como identificar os Atores ?.....................................................................................................16
O Caso de Uso...........................................................................................................................17
Identificando Casos de Uso (Use cases)....................................................................................17
Como encontrar um caso de uso ?.............................................................................................17
Desenhando o diagrama............................................................................................................ 18
Relacionamentos entre Atores e Casos de Uso..............................................................................18
Relacionamento entre Atores.................................................................................................... 18
Relacionamento entre atores e Casos de Uso............................................................................18
Mais um exemplo de Caso de Uso de Nível Zero......................................................................... 21
Exemplo Completo do Sistema de Controle Acadêmico...............................................................22
Documento Nomenclatura............................................................................................................. 23
Modelo (sugestão) para nomenclatura:..................................................................................... 23
Convenções de nomeação para objetos de Banco de dados...................................................... 25
O Documento Glossário.................................................................................................................26
Casos de Uso..................................................................................................................................27
Como um Caso de Uso deve ser escrito?.................................................................................. 28
Quem deve fazer a extração de casos de Uso ?.........................................................................28
Como extrair um Caso de Uso.................................................................................................. 29
Diagrama de Classes ..................................................................................................................... 35
A representações da classe........................................................................................................ 35
Classes ativas e inativas............................................................................................................ 35
A representação de objetos........................................................................................................35
Atributos (Propriedades)........................................................................................................... 36
Operações (métodos).................................................................................................................36
Associações de Classes............................................................................................................. 37
1

Agregação.............................................................................................................................38
Composição.......................................................................................................................... 40
Herança.................................................................................................................................42
Estereótipos do Diagrama de Classes...................................................................................43
Algumas regras para definição de classes para casos de uso................................................45
Levantando Classes a Partir do Caso de Uso....................................................................... 46
Gerando Classes de Outro Caso de Uso....................................................................................47
Diagrama de Caso de Usos De Sistema Seguradora...........................................................................48
O Diagrama de Classes do Diagrama de Casos de Uso.....................................................................49
O Diagrama de Seqüência.................................................................................................................. 50
Componentes do Diagrama de Seqüência......................................................................................50
Atores........................................................................................................................................ 50
Objetos...................................................................................................................................... 51
Linha da Vida............................................................................................................................ 51
Foco de Controle ou Ativação...................................................................................................51
Mensagens ou Estímulos...........................................................................................................52
Tipos de Mensagem..............................................................................................................52
Imperativas........................................................................................................................... 52
Auto chamadas (ou Auto delegações).................................................................................. 52
Condições de Guarda (Operadores de Interação)................................................................. 53
Diagrama de Seqüência para Abertura de uma Conta Comum............................................ 53
Bibliografia......................................................................................................................................... 55

2

Conceitos Iniciais

O mundo orientado a objeto é repleto de conceitos e termos novos e que devem ser de claro
entendimento para que seja possível pensar orientado a objeto. Na realidade não é difícil, o grande
impacto é causado pela diferença de como vínhamos pensado nos projetos convencionais. O
pensamento OO, na realidade, é até mais intuitivo. Afinal, nosso mundo é constituído por objetos...
Somos preparados pela evolução a lidar com eles. Nós reconhecemos facilmente quando um dado
objeto pertence a uma classes. Sabemos na hora que um determinado objeto é uma caneta ou uma
cadeira e nem pensamos como conseguimos distingui-las tão facilmente.
Vamos ver brevemente o que significa cada termo usado no mundo Orientação a Objeto:

Classe
É um “modelo” a partir do qual são criados (gerados) objetos. Cada objeto tem a mesma estrutura e
comportamento da classe da qual ele pertence. Se o objeto pertence à classe, dizemos que ele é uma
instância da classe.

As classes são elementos fundamentais na composição de softwares orientados a objetos. Elas são
empregadas tanto na composição do projeto dos sistemas computacionais quanto em sua
implementação. Entretanto, ao contrário dos objetos, as classes não se traduzem em elementos
executores no código de implementação.
Exemplo de Classe: O Excel
Exemplo de Objetos: Suas planilhas
Uma classe precisa definir os atributos e os procedimentos dos futuros objetos que serão criados a
partir dela. A definição da classe tambem permite estabelecer regras claras de visibilidade de seus
componentes (atributos e procedimentos). A definição dos atributos, procedimentos e o controle da
visibilidade se resume, na verdade, a definição da classe.
Em eletrônica, classes podem ser comparadas com C I's. Eles são projetados para se “encaixarem”
em diversos tipos de projetos, com inúmeras aplicações. Os C I's possuem uma coleção de
funcionalidades (procedimentos) e precisam ser configurados (atributos). Pensando em Java, os
atributos são as variáveis e os procedimentos são os métodos.
Exemplo: Uma classe simples em Java:

public class Circulo {
private double raio; // Atributo 1
private double perimetro; // Atributo 2
private double area; // Atributo 3
public final double PI = 3.1415926535; // Atributo 4
public Circulo (double raio) { // Procedimento 1 (construtor)
this.raio = raio;
perimetro = 2 * PI * raio;
area = PI * raio * raio;
}
}
public double getRaio() { // Procerdimento 2
return raio;
}
public ddouble getPerimetro() { // Procedimento 3
return perimetro;

3

Objeto

É um representante “material” projetado com base em uma classe. Contrastando com as classes que
normalmente não existem como indivíduos, os objetos são a população que realmente sofre e causa
efeitos.
Para reforçar, não existe nenhum indivíduo Aluno. O que existe são indivíduos definidos conforme
reza a classe Aluno e que são objetos independentes entre si: Joazinho, Mariazinha, Pedrino etc.
Todos os indivíduos que são da classe Aluno terão propriedades como notas mensais, nome,
endereço, dados dos pais etc. Terão que se submeter a procedimentos como avaliação bimestral,
semestral, análise de aprovação etc.

Os objetos são conhecidos também com instâncias. Quando criamos um objeto, dizemos que
estamos instanciando um objeto.

Exemplo: Instanciando e usando objetos em Java:

public class Teste {
public static void main (String args[]) {
Circulo c1 = new Circulo (4),
c2 = new Circulo (10);
System.out.println (“Area do primeiro círculo: “,ci.getArea());
System.out.println (“Area do segundo círculo: “,ci.getArea());
}
}

Herança
É o relacionamento (associação) entre uma classe e uma ou mais versões refinadas dessa classe, é
também a abstração que permite partilhar semelhanças entre as várias classes, mantendo as suas
diferenças.

Quando estamos caminhando para o mais alto nível na estrutura hierárquica estamos generalizando.
Comum no começo da fase de análise.
Procurar atributos e métodos parecidos.
Definem superclasses.
Podemos definir métodos obrigatórios.

Exemplo:

Um círculo trigonométrico é um caso particular de círculo. Um círculo trigonométrico é um círculo
de raio constante e igual a um. Possui área e perímetro e mais uma série de outras propriedades e
métodos. A idéia é aproveitar o que já foi feito para o círculo genérico e escrever apenas as
peculiaridades do círculo trigonométrico.

Em Java, tratamos a classe da qual estendemos (Circulo) como superclasse e a classe estendida
(Circulo trigonométrico) como superclasse.
5

Exemplo:

public class CirculoTrigonometrico extends Circulo {
private double arco;
public CirculoTrigonometrico (double arco) {
super(1); // Passando para a super classe o raio = 1
this.arco = arco;
}
public double getSeno() {
return Math.sin(arco);
}
public double getCosseno () {
return Math.cos(arco);
}
public double getTangente() {
return getSeno()/getCosseno();
}
public double getArco() {
return arco;
}
}
Usando a classe CirculoTrigonometrico:

public class Teste {
public static void main (String args[]) {
CirculoTrigonometrico ct1 = new CirculoTrigonometrico(30);
System.out.println
(“Seno de ” + ct1.getArco() + “ = “ + ct1.getSeno());
}
}

Sobrecarga ( Overloading )
Podemos escrever mais de um método em uma mesma classe (ou em alguma superclasse) com o
mesmo nome, mas com assinaturas diferentes. Desta forma, o compilador decide (portanto em
tempo de compilação) qual dos métodos sobrecarregados usar tomando como base a quantidade
e/ou tipos dos argumentos.
A assinatura de um método é conhecida pela lista de argumentos no que concerne a sua quantidade
tipo e ordem.
Exemplos:

Assinaturas idênticas

double calculaSalario (float valorHora, int quantidadeHoras);
float calculaSalario (float var, int quant);
No exemplo acima, ambos os métodos possuem a mesma quantidade e tipo de argumentos.
Por este motivo, ambos os métodos possuem a mesma assinatura. Note que o tipo do
retorno não é considerado como fazendo parte da assinatura.

6

Assinaturas diferentes

void setDadosConta(String nome, long numConta);
void setDadosConta(long numConta, String nome);
void setDadosConta(String nome, long numConta, double valDeposito);

• No segundo exemplo a quantidade e tipos de argumentos são os mesmos mas estão em
ordem diferente.
• No terceiro exemplo, o método possui um argumento a mais.
Exemplo (em UML e Java) de uma classe com sobrecaga de métodos:
A classe abaixo, implementa uma série de métodos utilitários para retornar o tipo das
variáveis primitivas passadas como argumento.

MostraTipo

+tipo (char a) : String
+tipo (int a) : String
+tipo (long a) : String
+tipo (double a) : String
+tipo (float a) : String
+tipo (byte a) : String

A Classe em Java:

1.public class MostraTipo {
2.
3. public String tipo (char a) {
4. return "char";
5. }
6. public String tipo (int a) {
7. return "int";
8. }
9. public String tipo (long a) {
10. return "long";
11. }
12. public String tipo (double a) {
13. return "double";
14. }
15. public String tipo (float a) {
16. return "float";
17. }
18. public String tipo (byte a) {
19. return "byte";
20. }
21.}

7

Usando Sobrecarga:

1.public class TesteSobrecarga {
2. static public void main (String args[]) {
3. long a = 12344L;
4. int b = 45;
5. float c = 3F;
6. MostraTipo t1 = new MostraTipo();
7. System.out.println(a + " é um " + t1.tipo(a));
8. System.out.println(b + " é um " + t1.tipo(b));
9. System.out.println(c + " é um " + t1.tipo(c));
10. }
11.}

Sobrescrita ( Overriding )
A sobrescrita só pode ser caracterizada quando temos uma estrutura hierárquica com herança.
Também é resolvida em tempo de compilação. Ocorre quando escrevemos métodos geralmente de
mesma assinatura em níveis hierárquicos diferentes. O Compilador procura na classe atual a
existência do método invocado. Se encontrar usa, caso contrário subirá na hierarquia procurando um
método de mesmo nome e assinatura nas superclasses.
Exemplo:

Quadrilatero
-lado1 : float
-lado2 : float
-area : float
-perimetro : float
-diagonal : float
+Quadrilatero(lado1: float, lado2: float)
+getArea() : float
+getPerimetro() : float
+getDiagonal() : float

↑ ↑
Retangulo Quadrado

+Retangulo(lado1:float, lado2 : float) +Quadrado(lado: float)
+getDiagonal() : float

Observe que existe um método na superclasse Quadrilatero chamado getDiagonal e outro
método na subclasse Quadrado também chamado getDiagonal. Ambos de mesma assinatura. O
método getDiagonal da classe Quadrado está sobrescrito sobre o método getDiagonal da
superclasse Quadrilatero.

8

Nota sobre Sobrescrita e Sobrecarga:

Em Java, por ser uma linguagem praticamente interpretada, o tempo de compilação se confunde
com o de execução. Neste caso, a JVM precisa definir o método a ser sobrecarrego ou sobrescrito
“na hora”.Associações (relacionamentos)

Polimorfismo

É a habilidade pela qual uma única operação ou nome de atributo pode ser definido em mais de uma
classe e assumir implementações diferentes em cada uma destas classes.

É a propriedade por meio do qual um atributo ou variável pode apontar para (ou manter o
identificador de) objetos de diferentes classes em momentos diferentes.

Rigorosamente, consideramos como polimorfismo apenas os casos em que o objeto usado é definido
tardiamente (ou seja, em tempo de execução – Dynamic binding), com o uso de uma referência
genérica... Contudo existem duas formas de acesso “polimórfico” que não utilizam exatamente uma
referência genérica nem são resolvidas em tempo de execução, mas “selecionam” um método (mais
adequado) em tempo de compilação.

Generalização/Especialização

É a construção de uma classe C de forma que uma ou mais das classes que ela utiliza internamente é
fornecida somente em tempo de execução (no momento em que um objeto da classe C é
instanciado).

A generalização consiste, portanto, no projeto de classes para que funcionem como superclasses que
possam ser utilizadas para estender outras classes mais especializadas.

Encapsulamento
É o grupamento de idéias afins em uma unidade, conceito esse que pode então ser informado em
uma só palavra. A construção de funções, procedures, performs etc, são exemplos de
encapsulamento em outros paradigmas Em OO chegamos a um nível muito mais sofisticado de
encapsulamento.

Ocultação de informações e Implementações
É a utilização de encapsulamento para restringir a visibilidade externa de certos detalhes de
informações ou implementações, os quais são internos à estrutura de encapsulamento.

Retenção de Estado

Capacidade de um objeto reter seu estado. Isto é, quando existe um objeto criado (residente na
memória, instanciado), este objeto mantém suas propriedades inalteradas até que alguma ação
(mensagem) realize algum tipo de alteração. Podemos invocar métodos do objeto quantas vezes
forem necessárias que o objeto continuará existindo entre as chamadas. Veja que na programação
estruturada tradicional, quando chamamos uma função, esta ganhará a CPU e a memória necessária
para realizar suas funcionalidades. Ao seu término seus dados (variáveis automáticas) serão
descarregados da memória e função não mais existirá como entidade. O único vestígio de sua
9

existência seria algum valor retornado.

Identidade de um Objeto

É a propriedade pela qual cada objeto (independentemente de sua classe ou estado) pode ser
identificado e tratado como uma entidade distinta de software.

O Projeto Orientado a Objetos
Atividades Relacionadas ao Projeto OO

1. Análise dos requisitos de usuários
2. Desenho do software
3. Construção do software
• Reutilização
• Confiabilidade
• Invariantes de classe. É uma condição que todo objeto da classe deve satisfazer.
Exemplos:
dataNascimento <= dataAtual
litrosAbastecer <= capacidadeTanque - litrosAtual
• Robustez
Diz respeito principalmente à capacidade do software de se recuperar de falhas
(Tratamento de exceções)
• Estensibilidade
Ajuste doa solução ao problema. O principal recurso para se obter estensibilidade é a herança.

Exemplo:

Existia apenas a classe Clientes. Por necessidade do negócio estendemos a classe para
ClientesNacionais e ClientesEstrangeiros sem modificar a classe Clientes, mas estendendo
ambas dela.

• Distribuitividade

Possibilidade de classes poderem ser utilizadas em múltiplas plataformas e ambientes.
Padronização de protocolos de troca de mensagens entre objetos etc. Utilizando os padrões
criados para garantir Distribuitividade é possível até utilizar classes desenvolvidas em
linguagens diferentes. (CORBA)

• Armazenabilidade

Ai moram os gerenciadores de Banco de dados orientados a objeto. (ODBMS). Esta
característica que nos permite salvar objetos inteiros em bases de dados e depois, quando
necessário, recuperá-los. Em bancos de dados OO não usamos o SQL como conhecemos, mas
uma variação: OQL.

4. Manutenção de Software

Como todos que trabalham com software sabem, a manutenção de software é um poderoso
dreno de recursos e paciência em todas a corporações. O esforço para minimizar e,

10

principalmente controlar seus custos é uma meta forte de qualquer corporação.

O projeto OO fornece os recursos de reutilização, confiabilidade, robustez e estensibilidade
como lastro para conseguir este objetivo.

5. Utilização de Software

Relaciona-se com a ergonometria e, na prática, está relacionado com a interface do software
com o usuário. Atualmente os usuários esperam uma interface gráfica, o mais assemelhada
possível com o que já lhe é familiar em outras aplicações (GUIs). O projeto OO se presta
particularmente para este tipo de interface.

6. Gerenciamento de projetos de software

O uso correto de construções de projetos OO, demanda uma boa organização e documentação
das bibliotecas de classes. O gerenciamento e todo este processo ganha uma enorme
importância. O gerente não precisa necessariamente entrar em detalhes de código das classes
desenvolvidas, mas, sem dúvida, deve conhecer suas características e estensibilidade.

O uso de UML, por exemplo, é uma forte ferramenta de gerenciamento de projetos. Quando
uma fábrica de software passa a adotar OO, o pessoal de desenvolvimento passa a se
especializar em determinado grupo de classes que atendem a problemas específicos a ou
negócios ou sub ramo de um negócio. A integração operacional e funcional de todas estas
equipes pode ser muito facilitada com o gerenciamento utilizando as ferramentas UML
desenvolvidas exatamente com esta finalidade.

UML – Unified Modeling Language

A Unified Modeling Language - UML, veio para arrumar a casa da grande torre de babel que era o
desenho de projeto orientado a objeto. Antes da UML os desenhistas de software tentavam ajustar
os antigos diagramas DFDs usados na análise estruturada de sistemas para escrever seus projetos.
As ferramentas de análise existentes (Os CASES da vida) não estavam preparadas para a nova
arquitetura e não correspondiam as necessidades dos projetistas. Muitos cientistas da OO
desenvolveram algumas propostas de modelagem, mas, por um ou outro motivo, não se tornaram
suficientemente populares para que fossem consideradas como padrões.
Mesmo assim, UML não é um padrão 100% final. Existem dezenas de variações, pequenas é
verdade, mas suficientes para causar alguma frustração em quem estuda UML em muitas fontes.
Mesmo assim raramente as diferenças poderão trazer alguma diferença que venha a provocar uma
má interpretação do desenho. O que se recomenda é que a empresa que estiver adotando UML deve
escolher uma das variações que parecer mais “simpática” ou se ajustar melhor a linguagem usada
nas aplicações.

Nós projetistas de software, quando mergulhamos no estudo da UML, inicialmente ficamos
incrédulos com a possibilidade de uma simples coleção de abstrações e diagramas possa representar
com fidelidade projetos complexos de sistemas. À medida que nos aprofundamos a idéia vai ficando
cada vez mais factível...

UML foi escrito e proposto no final da década de 90 pelo trio Grady Booch, Ivar Jacobson e Jin
Rumbaugh. E hoje é um padrão adotado pelo OMG, Object-Management Group.

11

Metas UML
1. Prover aos usuários uma linguagem de modelagem visual expressiva e pronta para uso, de
forma que eles possam desenvolver e intercambiar modelos significativos.

2. Prover mecanismos de estensibilidade e especificação para ampliar os conceitos centrais
Os usuários precisam saber:
1. construir modelos que utilizam conceitos centrais sem utilizar mecanismos para
extensão na maioria das aplicações normais
2. acrescentar novos conceitos e notações para temas não cobertos pelo núcleo
3. escolher entre interpretações variantes de conceitos existentes, quando não houver
um claro consenso.
4. especificar os conceitos, as notações e as restrições, para domínios de aplicações
particulares.
3. Ser independente de linguagem de programação e processos de desenvolvimento
particulares.
4. Prover uma base formal para entendimento da linguagem de modelagem;
5. Estimular o crescimento do mercado de ferramentas OO
6. Suportar conceitos de desenvolvimento de nível mais alto, tais como colaborações,
estruturas, modelos e componentes.
7. Integrar as melhores práticas.

12

Especialização / Generalização
O relacionamento de Especialização/Generalização é uma forma de Associação entre casos de uso
na qual existe dois ou mais casos de uso com muitas características semelhantes, apresentando
contudo algumas diferenças importantes entre si. Quando tal situação ocorre, costumamos definir
um Caso de Uso Geral que descreve as características comuns a todos os casos de uso envolvidos.
Depois descrevemos os demais casos de uso destacando apenas as diferenças ao Caso de Uso
Geral.
Desta forma não é necessário colocar a mesma documentação para todos os Casos de Uso
envolvidos porque toda a estrutura de um caso de uso generalizado é herdada pelos casos de uso
especializados. Além disso, os casos de uso especializados herdam também quaisquer possíveis
Associações de inclusão ou extensão que o Caso de uso Geral venha a possuir, bem como quaisquer
Associações com os Atores que utilizem o caso de uso geral. A Associação de
Generalização/Especialização é representada por uma seta que une o Caso de Uso Geral (para onde
a seta aponta) Aos casos de uso especializados

Exemplo:
Abertura de
conta

Abertura conta Abertura conta
especial poupança

Inclusão
A Associação de inclusão costuma ser utilizada quando existe um serviço, situação ou rotina
comum a mais de um Caso de Uso. Quando isso ocorre, a documentação desta rotina é colocada em
caso de uso específico para que outros casos de uso simplesmente os inclua.

Exemplo:

Saque

<<include>>

Cliente
Banco
Depósito
Registrar
<<include>> movimento

13

Como vimos na figura acima, tanto Saque quanto Depósito são casos de uso que devem ser
registrados como movimento. Fica claro que o caso de uso Registrar Movimento será incluído nos
casos de uso de Depósito e Saque. A associação de inclusão evitará a repetição da documentação de
Registrar Movimento dentro de cada um. Veja que o caso de uso Registrar Movimento será
executado necessariamente toda vez que um Saque ou Depósito seja realizado.
A expressão entre sinais de << e >> são conhecidos como estereótipos e servem para descrever
claramente o tipo de associação.

Extensão
Associações de Extensão são utilizadas para descrever cenários opcionais de um caso de uso. Os
casos de uso estendidos descrevem cenários que somente ocorrerão em situações específicas.

Os casos de uso estendidos dependem de uma condição no caso de uso “base” para que seja possível
determinar qual dos casos de uso estendidos serão executados.

Exemplo

Encerrar conta

<<extend>>

<<extend>> Banco
Cliente

Saque Depósito

Veja que para que seja possível encerrar uma conta corrente temos que zerar o saldo do cliente.
Poderá ser necessário realizar um depósito, no caso da conta estar com saldo negativo, um saque no
caso do saldo estar positivo ou ainda nem um nem outro no caso do saldo da conta ser zero. Note os
estereótipos <<extend>> sobre as linhas de associação.

Documentos iniciais

Documento Visão

É um relato resumido com os principais tópicos a que o negócio a ser automatizado deve fornecer.
Normalmente faz parte do contrato (ou ordem de serviço) de desenvolvimento. É comum que este
documento aborde aspectos de tecnologia (linguagem banco etc). Deve ser resumido e de linguagem
acessível para leitura de pessoal de nível gerencial, não necessariamente técnico.
O analista poderá, a seu critério, detalhar mais ou menos cada item de acordo com a sua importância
estratégica no projeto. Mas todos os 13 itens devem ser citados. Mesmo que em apenas uma palavra.
Deverá ser criada uma pasta na rede com nome do projeto com sub-pasta com nome de Visão. As
versões das visões devem ser salvas com o prefixo V seguido do número da versão. A identificação

14

da visão pode ser composta no formato que for mais conveniente para o pessoal envolvido.
Recomendamos que a codificação de versão definida seja tal que os arquivos possam ficar em
ordem quando listados no Explorer. Sugerimos o uso de composição de mnemônico do projeto, ‘V’,
(data corrente no formato AAMMDD e número seqüencial da versão). Mas é importante que seja
colocada à disposição de todos os envolvidos sempre a versão mais atualizada e também as antigas
para que as pessoas possam tomar conhecimento de eventuais mudanças e fazer comparações.
Apesar de todos este cuidados, a visão não deve sofrer grandes modificações. Quando o projeto
entrar na fase de codificação, mudanças na visão podem ser desastrosas.
Se for possível disponibilizar o acesso às visões em uma intranet isso deve ser feito.

Modelo de um documento Visão

0. Cabeçalho

V05120501 (Versão da visão)
Nome do sistema
Data
Requisitante(s):
Analista responsável:

1. Introdução

Descrição geral do trabalho realizado
2. Escopo
Relacione os principais módulos. (serão detalhados mais tarde no item 8)
3. Definições de acrônimos e abreviaturas
Todos os termos da área de informática devem ser explicados aqui. É uma espécie de
glossário. Mesmo assim, evite no restante do documento abuso de termos técnicos.
4. Referências
Relate a(s) fontes no qual o documento se baseou. Se existe uma ordem de serviço ou um
contrato. Seu número, responsáveis etc. Se foi ordem verbal, relate as pessoas que
“encomendaram” o projeto.
5. Oportunidade de negócio
Descreva a oportunidade de negócio. Qual a motivação para o projeto, o que se pretende
ganhar, melhorar. Que problema está sendo solucionado.
6. Descrição do pessoal envolvido. (Usuários, clientes, fornecedores,
facilitadores etc).
Nos itens 6.1 a 6.n descreva elemento por elemento. Cargo, nome completo, telefone, e-mail
etc. Procure listar primeiro os clientes depois os usuários, tentando listar por ordem
decrescente de importância estratégica do elemento para o projeto.
6.1
6.2

15

6.3 Ambiente (de hardware e software) atual dos clientes. Se existirem diversos ambientes,
indicar cada tipo de ambiente e o percentual em relação ao conjunto.

16

Exemplo:
Vinte estações de trabalho.
Cinco com Windows XP, 250Mb em rede com acesso web (25 %).
Dez com Windows 98 com 128Mb em rede com acesso a web (50 %)
Cinco com Windows 95 com 64Mb sem rede mais com acesso a web. (25 %)
7. Observações.
Acrescente qualquer observação que você ache pertinente e não encontrou local mais
específico para lançar.
8. Módulos
Numere, nomeie e descreva as perspectivas de cada módulo do projeto. Procure descrever o
que o módulo faz, para que serve e como se relacionará com outros módulos, se isso for
importante. Cada módulo será um componente no diagrama de Caso de Uso.
Tente listar os módulos na ordem que serão desenvolvidos (Não necessariamente na
ordem de importância estratégica)
8.1 ...
8.2 ...
.....
8.n ...
9. Precedência e prioridades.
Indique a ordem de prioridade dos módulos (item 8) e se ela será a mesma ordem de
precedência para desenvolvimento ou não. Explique os critérios que você usou para definir
os critérios, principalmente se um módulo mais importante teve que ser desenvolvido depois
de um menos importante. Descreva as razões técnicas para isso.
10. Requisitos não funcionais
Descreva aqui as dependências de softwares externos, particularidades de performance
esperadas, necessidade de treinamento e outras que forem pertinentes.
11. Requisitos de sistemas e ambientes.
Necessidades de software e hardware para viabilizar a operacionalidade do sistema em
questão. Defina aqui o sistema operacional, banco de dados, linguagem de programação,
servidor de aplicação, servidor de Internet, softwares de segurança. As necessidades mínimas
de hardware como memória, capacidade em disco, placa de rede, conexões de rede e
Internet, velocidade nas conexões etc.
Separe cada item (Sistema operacional, banco de dados etc em subitens separados)
11.1 Requisitos de software
11.1.1 Sistema operacional.
11.1.2 Browser
11.1.3 etc...
11.2 Requisitos de hardware
11.2.1 Memória mínimas
11.2.2 Espaço em HD
11.2.3 Placa de rede... etc
17

12. Insira uma figura com disposição dos módulos
Diagrama dos módulos descritos no item oito e seus relacionamentos.
As técnicas para preparação deste diagrama serão vistas mais adiante.

13.Assinatura do Solicitante do Projeto (Cliente)

19

Diagrama de Caso de Uso

O modelo de caso de uso é um instrumento eficiente para determinação e documentação dos
serviços a serem desempenhados pelo sistema. É também um bom meio de comunicação com
clientes e demais envolvidos que não sejam da área de informática.
Para iniciarmos a confecção de qualquer diagrama de UML, é necessário conheceremos a sua
notação, ou seja, a forma como devemos representá-lo e suas semânticas.

O Ator
O Ator pode ser uma pessoa, um sistema ou mesmo uma Entidade Externa (um banco, uma
instituição externa etc). Um Ator pode ser um equipamento como uma impressora ou um roteador,
por exemplo. Pode ser um equipamento, um software como um aplicativo ou um SGBD. O Ator é
caracterizado por realizar uma atividade. Nos diagramas representamos o ator como um boneco
magro ou um retângulo com o nome do autor abaixo do estereótipo <<ator>>:

<<ator>>
Aluno
Aluno
Exemplos de Atores:
• Pessoas: Usuário, secretária, aluno, professor, administrador etc.
• Dispositivos: impressoras, máquina ou equipamentos etc.
• Hardwares: Modens, roteadores, placas de controle etc.
• Softwares: SGBDs, Aplicativos de controle de processo etc.

Considerações sobre Atores
É importante observar que atores representam, na verdade, papéis desempenhados quando estiverem
interagindo com o sistema. O ator não representa um elemento particular, mas qualquer um que
esteja realizando aquele papel naquele momento. Em um sistema em que o ator seja <<aluno>>,
por exemplo, tratará como <<aluno>> qualquer pessoa que seja ou represente o aluno. Assim o
responsável ou um representante legal será considerado aluno em um sistema que defina como autor
<<aluno>>.
Na fase de projeto, um ator é uma classe não um objeto. Isso significa que o ator deve representar
um grupo (uma classe) e não um indivíduo (um objeto). O ator é o Encarregado, não o Sr. João.
O ator interage com o sistema sempre através de mensagens. (Lembrando: Mensagens são atributos
e/ou retorno de métodos)

Como identificar os Atores ?
• Quem utilizará a funcionalidade principal do sistema ?
• Quem Precisará de suporte do sistema para fazer suas tarefas diárias ?
• Quem necessita administrar e manter o sistema funcionando ?
• Quais dispositivos de hardware o sistema precisará manipular ?
• Com que outros sistemas o sistema precisará interagir ?
• Quem tem interesse nos resultados que o sistema irá produzir ?

20

O Caso de Uso

• Um caso de uso é um padrão de comportamento que o sistema apresenta:
Cada caso de uso é uma seqüência de transações relacionadas que normalmente são
executadas através de um diálogo entre um ator e o sistema.
• Os casos de uso capturam a funcionalidade do sistema na visão dos usuários (atores humanos)
• Eles descrevem e validam o que o sistema irá fazer.
• Os atores devem ser estudados para identificar suas necessidades e assim identificar os casos de
uso relacionados a eles:
- Funcionário: Cadastra Turmas
- Professor: Lança Notas
- Aluno: Efetua matrícula
- Sistema financeiro: Valida Situação do Aluno

Identificando Casos de Uso (Use cases)
A identificação dos casos de uso não deve ser confundida com telas do sistema. Não é muito fácil,
para projetistas da velha guarda, principalmente para o pessoal que desenvolveu sistemas sem
desenho, (na unha, como se diz), entender claramente o conceito de caso de uso.
Para poder encontrar e dissecar os casos de uso, é fundamental a abstração. A abstração é a
capacidade de se focar uma parte de problema, que seja realmente relevante ao caso em análise.
Nem sempre isso é simples. Nossa natureza tende a tratar os problemas mais complicados e
relevantes. O problema é que quase sempre estes problemas são muito complexos e não se
relacionam claramente entre si nem entre seus atores... Isso acaba tirando a concentração e
objetividade do que se está analisando. Acabamos não chegando a nada, ou o que é pior: a soluções
equivocadas.
A abstração de mãos dadas com a metodologia UML de extração de casos de uso é uma ferramenta
que pode ajudar a equacionar problemas de grande complexidade, encontrando soluções simples e
fáceis de implementar, deixando a aparente complexidade do problema inicial para trás.
Outra grande vantagem do levantamento dos casos de uso e sua posterior apresentação em
diagramas, é o fato de que podem ser compreendidos sem muita dificuldade pelos usuários e
analistas de negócio menos técnicos.
A seguir, algumas questões que podem ajudar a extrair os casos de uso dos problemas do mundo
real.

Como encontrar um caso de uso ?
• Quais funções os atores requerem do sistema ?
• O que cada ator precisa fazer
• A ator precisa ler, criar, destruir, modificar ou armazenar algum tipo de informação no sistema ?
• O ator precisa notificar sobre eventos no sistema ou sobre alguma outra coisa ?
• O trabalho diário do ator poderia ser simplificado ou melhorado através de novas funções do
sistema?
• Quais as entradas e saídas do sistema? De onde elas vem e para onde elas vão ?
• Quais os maiores problemas com a implementação atual do sistema?

21

Desenhando o diagrama
Nos diagramas UML, o Caso de Uso é representado por uma elipse (as vezes colorida) com um
texto internamente identificando o caso de uso (algumas ferramentas UML escrevem o nome do
caso de uso não internamente mas sobre a elipse). O caso de uso deve estar ligado a outros casos de
uso ou a um Ator por uma linha contínua. Podemos usar uma seta de ponta vazia para indicar a
direção da relação entre os casos de uso

Nome do Caso de Uso

Relacionamentos entre Atores e Casos de Uso
Os relacionamentos em um diagrama de casos de uso podem envolver dois atores, dois casos de uso
ou um ator e um caso de uso.

Relacionamento entre Atores

Normalmente não se consegue “informatizar” o relacionamento entre dois atores, mas sem dúvida
este relacionamento deve ser considerado e documentado nos diagramas. Este relacionamento pode
ser verbal, por escrito ou até, um link entre equipamentos. É claro que, neste caso, a troca de
mensagem não pode ser via métodos.

Exemplo:
Solicita histórico

Aluno Secretária

O relacionamento pode ser também de generalização que representa uma relação conceitual
indicando que um ator é caso especial de outro ator mais genérico. Esta relação indica que o autor
especializado inclui todos os atributos do ator genérico e ainda atributos adicionais;

Exemplo:

Professor Coordenador

Relacionamento entre atores e Casos de Uso
Ao contrário do relacionamento entre ator e caso de uso, as relações entre casos de uso nunca serão
do tipo comunicação. Isto ocorre porque Casos de uso são aplicações completas do sistema e, por
conseqüência, não existe sentido de fazer-se comunicar dois “usos do sistema”. As comunicações
são sempre estruturais. Como veremos mais tarde, existem três tipos de comunicação entre casos de
uso: Inclusão, (<<include>>), Extensão (<<extend>>) e generalização.

22

O Relacionamento entre atores e casos de uso expressa sempre uma comunicação entre eles. Este
relacionamento é representado por uma reta (ou uma seta) unindo a Ator ao caso de uso.

Exemplo:
Emitir Histórico Escolar

Registrar Novo Aluno Impressora
Secretária

Quando a relação entre os casos de uso é de dependência, ou seja, quando um caso de uso depende
do outro para existir, usamos uma seta tracejada ligando ambos. No exemplo só podemos cadastrar
um dependente depois que cadastramos o funcionário. O sentido da seta é do dependente para o
funcionário.

Cadastrar Cadastrar
Funcionário Dependente

Podemos especificar inclusão de um caso de uso (ou parte) em outro caso de uso. Isso quer dizer
que o caso de uso Calcular Salário utilizará integralmente a forma de cálculo de Cálculo do
Salário Família . Desta forma evitamos refazer (reeditar) o caso de uso que foi incluído.

Cálculo do Salário
Calcular Salário Família

Incluir cenário principal: Cálculo do Salário Família
<< include >>

Muitas vezes um caso de uso é uma particularização de um outro já documentado. Estendendo o
caso de uso existente para um novo, editamos apenas o que for acrescentado. Este exemplo será
válido apenas se consideramos que o correntista necessite inicialmente abrir uma conta comum para
depois convertê-la para conta corrente especial.

Conta Corrente
Conta Corrente Especial

Estender cenário Conta Corrente especial de Conta Corrente
<< extend >>

23

Para exemplificarmos um diagrama de um sistema completo com seus casos de uso, atores e
relacionamentos vamos examinar o projeto de uma locadora de DVDs
Este seria o diagrama de nível zero referido no modelo de Visão

Sistema de Locação de DVDs Via WEB

Administrar
Locar DVD
Promoções
Entregar
Locação

Administrar
Multas

Cliente Site

Devolução

Administrar
Controlar Marketing
Estoques

Fornecedor

Nós já vimos que UML prevê a possibilidade de ligação entre atores. Contudo, consideramos que
se não existir um caso de uso entre eles, não será possível desenvolver código para esta ligação,
muitas vezes a ligação entre atores acaba ganhando um Caso de Uso. Por exemplo, se o fornecedor
necessitar conhecer o estoque atual de filmes na locadora poderia interagir com o site diretamente
(que em nosso exemplo é um ator). Fica clara a necessidade de um caso de uso para viabilizar o
acesso do fornecedor ao site com esta finalidade.
Mesmo que realmente não exista um caso de uso “codificável” entre os atores, normalmente
representamos estes relacionamentos quando precisamos representar comunicações importantes para
o entendimento do negócio.
O diagrama de Casos de Uso não tem reflexo direto em codificação. Ele é um instrumento de
visualização da complexidade é a abstração da complexidade. Contudo, ao ser analisado e aprovado
o diagrama de nível zero e a visão como um todo, estamos prontos para a análise propriamente dita.
Esta fase se inicia na confecção do documento Nomenclatura.

24

Mais um exemplo de Caso de Uso de Nível Zero

Sistema de Controle Acadêmico

Cadastrar aluno

Cadastrar professor

Cadastrar curso

Registrar matrícula
SGBD

Emitir confirmação

Secretária
Emitir diário de classes

Registrar notas

Emitir histórico escolar
Impressora

Emitir confirmação

O Diagrama de Estudo de Caso de Nível Zero, se preocupa com os grandes casos de uso. Estes
casos de uso, no detalhamento, poderão ser explodidos em outros casos de uso mais especializados.
No diagrama detalhado que será mostrado a seguir, observe que nenhum caso de uso existente no
diagrama de nível zero foi suprimido. O que se faz é definir e representar os “sub casos de uso”
(inclusão, exclusão e alteração de cada cadastro) e o(s) novo(s) caso(s) de detalhamento (No caso:
login)
Note que no diagrama acima, nenhum caso de uso tem ligação com outros caso de uso.
Normalmente os diagramas de nível zero mostram apenas os casos de uso diretamente ligados a
atores.
O limite do sistema (fronteira) não foi desenhado apenas para diminuir a poluição do desenho.

25

Exemplo Completo do Sistema de Controle Acadêmico

Cadastrar aluno
<<include>>

Incluir Aluno Excluir Aluno Alterar Aluno
<<include>>

Cadastrar Professor
<<include>>
<<include>>
Alterar Professor
Incluir Professor
Login Excluir Professor
<<include>>

Cadastrar Curso

Incluir Curso Excluir Curso
Secretaria Alterar Curso
<<include>>

Registrar Matrícula
SGBD
<<include>>

Registrar Nota

Emitir Diário de Classe

Emitir Confirmação de
Matrícula

Emitir Histórico Escolar

Impressora

Nota: Todos os detalhes deste diagrama serão vistos a medida que nosso estudo avançar.

26

Documento Nomenclatura

Este documento é usado para criarmos um padrão de prefixos e sufixos para todas as palavras
envolvidas em estrutura de código. Nomeação de classes, objetos, variáveis, tabelas, colunas,
chaves etc. Neste documento também criamos padrões para visibilidade de variáveis, classes e
métodos e também tipos de variáveis locais e atributos .

Em Java não existe variáveis globais. Isso facilita a documentação e melhora a segurança do código.
Este documento normalmente consiste de tabelas onde listamos os tipos e os prefixos e/ou sufixos
que serão usados. É bom lembrar que Java é sensível ao caso de maiúsculas.
Naturalmente este documento só pode ser elaborado se a linguagem utilizada já estiver definida.

Modelo (sugestão) para nomenclatura:

Tipos de Dados Prefixo
Primitivos
boolean b
char, char [] c
byte, byte[] by
Short, short[] t
int, int[] i
long, long[] l
float, float[] f
double, double[] d
void V

27

Tipos de classes e outros tipos Prefixo
BigDecimal bd
Collection col
Exception Ex
Date dt
List lst
RuntimeException rte
String, String[] s
Time tm
Vector vt
Button btn
Checkbox chk
Dialog dlg
Label lbl
TextBox txt
Classe cls
Pacote pct
ListBox lstb
ComboBox cmb
Tabela (grid) tb
RadioBox rdb

Nota:

Contadores de loop estão dispensadas de prefixo. Usar necessariamente i para contador. Se forem
necessárias mais variáveis de controle usar a seqüência i, j, k, l, m, n etc.

No caso de prefixos e sufixos para tabelas e colunas existem muitas variações de padronização. De
qualquer forma se recomenda que no nome da coluna exista identificação da tabela a que pertence,
se é chave primária ou estrangeira. É recomendável que, com o uso de sufixos, identificar o tipo de
cada coluna. Naturalmente, caso seja feita alguma modificação do tipo da coluna durante a fase de
codificação, toda a documentação (e código) deverá ser revista e, se for o caso, renomeada. Esta
aparente desvantagem no final se mostra muito prático, pois será mais fácil identificar os possíveis
impactos relacionados com a modificação e, desta forma, fazer as correções necessárias.

28

Convenções de nomeação para objetos de Banco de dados

Prefixo para nome do objeto Prefixo
Tabela t
View v
Trigger tg
Stored Procedure sp
Function f

Regras para criar Nome da objetos de banco de dados:
Prefixo + “_” + Mnemônico de 3 letras + NomeObjeto
Exemplos:
tcli_clientes (Tabela de clientes)
vpea_pedidosativos (Visão: Pedidos Ativos)

Notas:
• Não estamos utilizando letras maiúsculas nos nomes das tabelas devido ao fato de que alguns
bancos de dados não operarem bem com tabelas e colunas grafadas com letras maiúsculas.
(PostgreSQL, por exemplo)
• O mnemônico do nome da tabela (3 letras) devem ser usados nas queries quando se usar aliasses.
Exemplo: SELECT
ped.ped_descricaos, cli.cli_nomes
FROM
tped_pedidos ped, tcli_clientes cli
WHERE
ped.fkcli_codigoi = cli.kcli_codigoi

Identificação Prefixo
Coluna comum Mnemônico de 3 letras da tabela + '_’
Chave primária 'k' + Mnemônico de 3 letras da tabela + '_’
Chave estrangeira 'fk' + Mnemônico de 3 letras da tabela origem + '_’

Exemplos:
kped_codigoi (Chave primária: Código do pedido, inteiro)
fkcli_codigoi (Chave estrangeira: Código do cliente, inteiro)
fkfor_codigoi (Chave estrangeira: Código do fornecedor, inteiro)
ped_quantidadei (Quantidade de itens no pedido, inteiro)

29

O Documento Glossário
É comum que os termos técnicos utilizados pelos analistas não sejam interpretados corretamente
pelos clientes e usuários.
O Glossário serve para traduzir em uma linguagem única todos os termos utilizados na
documentação. É importante para não permitir duplas interpretações. Deve ser de acesso fácil,
disponibilizado em intranet ou pasta no servidor com acesso para todos os envolvidos.
O Glossário, na realidade, não deve ser feito para uma projeto, mas para todos. Ele deve ser
feito apenas uma vez e ir sendo atualizado à medida que aparecem as necessidades.
O Glossário normalmente é organizado em ordem alfabética, mas pode também ser por ordem de
relevância.

Exemplo de Glossário
Data última atualização: DD/MM/AA
Software: Sistema de DVDs pela Internet

Locação
Ato de alugar uma ou mais unidades de DVD.
Usuário Locador
Aquele que aluga um ou mais DVDs
Cliente Locador
Mesmo que Usuário Locador
Beneficiário
Aquele agregado por designação de um Cliente Locador
Cliente Contratante
Aquele que fez a requisição do sistema
Locatário
Cliente Contratante
Equipamento de DVD
Aparelho que permite a execução de discos de DVD.
DVD Lançamento
Aquele disco de DVD que apresenta data de lançamento do filme inferior
a três meses

30

DVD Catálogo
Aquele disco de DVD que apresenta data de lançamento do filme superior
a três meses
Multa
Valor pago por dia de atraso pelo locador ao locatário.
Fidelidade
Programa que visa estimular a fidelidade do Cliente Locador com
descontos e prêmios.

Casos de Uso
Para entender o conceito de Caso de Uso, precisamos entender o que é Ator. Como vimos o Ator
pode ser uma pessoa, um sistema ou mesmo uma Entidade Externa (da análise estruturada).
O Ator realiza uma atividade e sempre atua sobre um Caso de Uso
Portanto, o Ator é alguém ou alguma coisa que atua ou interage com outras pessoas ou coisas de
modo que algo seja realizado.

Um caso de uso pode ser entendido como uma macroatividade que encerra diversas tarefas ou
atividades. Estas tarefas visam à consecução dessa macroatividade.
Um caso de uso pode ser, também uma representação descrita de variadas ações para realização
dessa macroatividade. Enquanto tivermos afinidade entre as ações realizadas, teremos um Caso de
Uso.

Exemplo:
Supondo o seguinte Caso de Uso: Pagamento de compras com cartão de débito bancário:
As atividades relacionadas a este caso de uso podem ser listadas:
• Coletar as informações do cartão (eletronicamente)
• Verificação dos dados do cartão pela instituição financeira
• Validação do cartão pelo banco.
• Digitação do valor que vai ser debitado
• Solicitação de digitação da senha do cliente
• Verificação da senha pela instituição financeira
• Verificação do saldo do cliente pelo banco
• Retorno da instituição da conclusão (ou não) da operação

O preenchimento da nota fiscal é um outro caso de uso “disparado” pelo Caso de Uso de
Pagamento.
Finalmente a impressão do documento é um terceiro Caso de Uso.
Note que os Atores envolvidos nos dois últimos Casos de Uso não são os mesmos envolvidos no
primeiro.

31

Como um Caso de Uso deve ser escrito?

Um caso de uso deve ser bastante detalhado. Seu detalhamento será usado por todas as outras partes
do desenvolvimento de sistemas orientados a objeto utilizando UML. Isso não quer dizer que deve
ser escrito um “tratado”. Por outro lado, a objetividade não deve suprimir nenhuma informação
nem tornar a descrição da atividade nebulosa.

Devemos procurar utilizar a abstração. A abstração é: “Princípio de ignorar os aspectos de um
assunto não relevantes para o propósito em questão.” Assim, devemos tratar cada abstração, em
relação ao que estamos analisando, como um negócio intrínseco a outro maior. Esteja sempre em
mente que um sistema pertence a um negócio a ser automatizado. Ao aplicarmos a abstração
podemos dividi-lo em várias macro atividades: Os Casos de Uso.

Quem deve fazer a extração de casos de Uso ?
Esta atividade pertence ao analista de negócios.
A extração de casos de uso pode ser feita de duas formas:
• Pela observação do negócios (Operações repetitivas)
• Por intermédio de entrevistas.
Quando o analista de negócios vai a campo fazer suas entrevistas, este deverá estar preparado para
as mais diversas reações de seus futuros interlocutores. Uma o abordagem errada pode gerar uma
reação negativa do entrevistado que pode dificultar muito o trabalho. Saber o nome do entrevistado,
alguma informação sobre a pessoa do tipo: Conhecer seu time de futebol, saber se tem família,
filhos, suas idades aproximadas e outras particularidades pode trazer identidade e empatia fazendo
com que as informações coletadas sejam mais fidedignas e completas.

Também é importante saber ouvir, evitando cortar o raciocínio do entrevistado. Caso o assunto se
desvie muito, o entrevistador deverá, com habilidade, retornar ao assunto sem constranger o
entrevistado. Pessoas muito secas e objetivas raramente conseguem um bom Estudo de Caso.

Depois do primeiro contato, com algum espaço para amenidades, a entrevista deve iniciar com a
explanação do objetivo da entrevista e o destino que será dado as informações coletadas.

32

Como extrair um Caso de Uso

Procure seguir o exemplo abaixo para suas entrevistas e a formatação final do caso de uso:

1. Nome Referência:
Verbo no infinitivo (Informar, comprar, pagar...)
• O nome codificado (ID) do Caso de Uso será usado em alguns documentos e como
referência como um trecho de código se referir a ele. Também pode ser usado como
chave primária se for armazenado em um banco de dados.
Exemplo: UC0086 - Cadastrar internautas e permitir alteração de senha e e-mail.
2. Breve descritivo
Do que se trata o caso de uso ?
• Você pode considerar esta descrição como inserção de palavras chave para localização
rápida em caso de pesquisas por palavra chave. Mesmo pensando em palavras chave,
procure construir algumas frases com sentido para o leitor.
Exemplo: Cadastrar o internauta no site e permitir alteração de senha e e-mail.
3. Pré-condições:
O que é necessário acontecer para dar início ao Caso de Uso ? Quais os
pré requisitos ?
• Qualquer ação ou reação de um subsistema ou ator que 'start' o Caso de Uso..
Exemplo: O internauta visitar o site (home) e clicar no ícone de cadastro. Para que o
cadastramento se efetive, o internauta deverá reconhecer e digitar um número de segurança
além de ter 18 anos completos.
4. Atores envolvidos
• Procure listar os atores separados por vírgula para facilitar futuras buscas. O entrevistado
deve sempre estar entre os atores envolvidos. Procure nomes simples. Evite nomes
compostos como Secretaria Executiva, Diretor Geral etc. Prefira nomes curtos e o mais
genérico possível como Aluno, Gerente, Secretária, Funcionário, Chefia, Coordenador,
Professor, Operador etc. O nome deve ser usado sempre no corpo do documento. Não se
preocupe em melhorar a elegância do texto usando sinônimos para o nome dos autores.
Sempre que se referir a um ator use o seu nome grafado exatamente da forma descrita.
Exemplo: Internauta, Site, SGBD.

33

5. Cenário principal
Qual a atividade básica e sem alternativas ou exceções? (Verbos no
presente do indicativo ou substantivos, iniciando a frase com (Registra,
Compra Seleciona, Informa...)
• Descreva as tarefas. Cada cenário principal se refere a uma tarefa. Evite informações
vagas. Faça (e obtenha as respostas) as três perguntas básicas: O que é? , Para que? ou
Por que?, Como ?
Lembre-se que o que for descrito aqui e seu nível de detalhes deve ser suficiente para que
as classes sejam codificadas. Caso alguma informação fique pendente, marque com um
número seqüencial entre colchetes. No ítem 12 (pendências) descreva cada uma delas.
Exemplo:
1. Cadastramento: Ao clicar no ícone de cadastramento, o internauta é encaminhado para a
tela de cadastro onde é solicitado que digite: Nome, Sobrenome, Nick Name, Data de
nascimento (DD/MM/AA), sexo (implementado em radio button), CPF (sem
formatação), endereço de e-mail, um login (usuário) e uma senha que será digitada em
duplicata para validação. O internauta ainda deve copiar e digitar um número mostrado
(obtido aleatoriamente [3] de uma base de figuras FIG_Figuras). Este procedimento visa
evitar cadastro automático de internautas. Ao clicar no botão de confirmar, estando
preenchidos todos os campos obrigatórios e também correto o número de segurança, o
sistema salva o novo internauta no SGBD [2] envia um e-mail ao internauta confirmando
o cadastro e retorna.
2. Troca de senha: Ao clicar no ícone de troca de senhas o internauta é encaminhado para a
tela de login [1]. O internauta se 'loga' com a senha atual (<<include>> UC0056). O
sistema identifica o internauta e mostra a tela de troca de senha. Aguarda a digitação em
duplicata da nova senha. Esta deverá possuir no mínimo 6 e no máximo 8 dígitos, sendo
pelo menos um dígito alfanumérico. Será pedido também, opcionalmente, que o
internauta digite uma “palavra secreta” para ajudá-lo a relembrar a senha no caso de
esquecimento.
No caso do internauta clicar em confirmar, o sistema consiste os dados e estando tudo OK
a senha e a palavra secreta são criptografadas (algoritmo XPTO 766) e salvas na Base.
3. Alteração de e-mail: Ao clicar no ícone de troca de e-mail o internauta é encaminhado
para a tela de login. O internauta se 'loga' (<<include>> UC0056), no sistema identifica o
internauta que é encaminhado para a tela de mudança de e-mail. O internauta se 'loga' na
tela e depois digita o novo e-mail. O sistema identifica, consiste os dados e envia
confirmação para o novo e-mail.

Nota importante:
Apesar de em nosso exemplo mostrar-mos 3 cenários diferentes,
não é muito comum um caso de uso com muitos cenários. O mais
adequado seria considerar os cenários Troca de Senha e Alteração
de E-mail como casos de uso diferentes.

34

6. Cenário alternativo e de exceções
Em que casos não acontece como descrito no Cenário Principal ?
• Aqui devem ser tratadas as exceções e situações alternativas. Cada cenário deve ser
tratado individualmente separando em sub-itens relacionados aos itens do Cenário
Principal.
Exemplos:
1.1. Nick Name está em branco: Sistema preenche como o primeiro nome do internauta.
1.2. Número de segurança diferente do mostrado. Desviar para UC0034.
1.3. Data de aniversário digitada é inválida. Mostra caixa de mensagem para reconhecimento
com OK, limpa o campo, coloca o foco.
1.4 . Internauta tem mais de 100 anos (provável erro de digitação) ou menos que 18 (menor
de idade). Mostra aviso que não é possível o cadastro e o motivo e sai.
1.5. Senha de confirmação não bate: Os campos são limpos e o internauta redigita ambas as
senhas.
1.6. Qualquer dos campos em branco (que não o Nick Name): O Internauta digita o campo
em branco. O foco será colocado no primeiro campo em branco. Os campos preenchidos
serão mantidos para que o internauta não necessite redigitar.
1.7. Login selecionado já existe na base do sistema. Desvia para o caso de uso UC0032
1.8. Check-digit de CGC não bate. Limpar o campo, colocar o foco nele e pedir nova
digitação.
1.9. Radio Button de sexo não está selecionado: É apresentada uma caixa de diálogo
comunicando o fato. O internauta reconhece com OK e o foco será direcionado ao Radio
Button de seleção de sexo.

2.1. Falha de login: Solicita novo login. (Não controla quantidade de tentativas)
2.2. Senha inválida. (Menos que 6 dígitos e/ou não existe dígito alfanumérico) Mostra alerta
com as regras para criação de senha, limpa os campos e solicita nova digitação
2.3. Senhas duplicadas não batem: Mostra aviso, limpa os campos de senha e solicita nova
digitação.
2.4. O internauta cancela. Nenhuma ação é realizada. O sistema volta para tela anterior.

3.1. Falha de login: Solicita novo login.
3.2. O e-mail é ilegal (Não tem dígito '@', tem espaços, nada antes do '@', nada depois do
'@'). Mostra aviso e pede nova digitação.
3.3. O e-mail cadastrado na base já existe para outro internauta. Mostra aviso e finaliza.

35

7. Requisitos especiais
Existe alguma situação que não foi contemplada no cenário principal nem
no alternativo ?
• Aqui colocamos as observações que o entrevistado destacou como importante ou detalhe
delicado. Alguma observação de segurança ou ponto de atenção especial.
Exemplo:
1. O tempo para apresentar as telas de ser o mínimo. A demora em retornar para o internauta
pode fazer com que desista de se cadastrar no site.
2. A informação de sexo deve ser um conjunto de dois 'Radio Buttons' sem inicialização.
(Ambos não selecionados)
2. As senhas digitadas não devem ser 'case sensitive'
3. Caso o internauta erre mais que 3 vezes a senha, registrar este fato em arquivo de log e
enviar um e-mail para o internauta comunicando este fato.

8. Casos de uso Incluídos

Liste aqui os casos de uso incluídos por este

• Os casos de uso incluídos são os que em algum momento são usados integralmente
durante a descrição do cenário principal ou alternativo. Seria o caso do login que, em
alguns casos, pode ser evocado pelo caso de uso corrente. Não se preocupe de dar
explicações ou justificativas. Apenas liste os casos de uso. (Veja: <<Include>>)

Exemplo:
UC0023 – Login do Internauta
UC0034 – Trata Número de segurança
UC0032 – Trata login existente

9. Casos de uso Estendidos

Liste aqui os casos de uso estendidos por este

• Um caso de uso estendido normalmente detalha um sub processo. Um exemplo seria o
caso de a partir do caso de uso cadastro do Internauta, definíssemos outros três: Um para
inclusão, outro para alteração e mais um para exclusão. Como no caso de incluídos, não
se preocupe em dar explicações ou justificativas. Apenas liste os casos de uso (Veja:
<<Extend>>)

36

10. Dados
Tipos de dados que foram encontrados durante a descrição do caso de
uso. Aqui informamos: texto (com tamanho), número (com precisão),
moeda, data (com formato), etc.
Objetos de classes de biblioteca também devem ser listados aqui.
(Repare em Date, Combo box, Text box etc)
Os componentes gráficos relevantes, isto é, que servirão para que os
atores entrem ou recebam dados, também devem ser listados aqui.
Importante: Para cada componente gráfico, crie pelo menos uma
variável para receber seus dados.

Exemplo:
Descrição Nome Tipo Banco de
Dados
Código Usuário iUsuario String Varchar (20)
Senha sSenha String Varchar (6)
E-mail sEmail String Varchar (100)
CGC sCgc String Varchar (11)
Nome sNome String Varchar (25)
txtNome Text Box -
Sobrenome sSobrenome String Varchar (50)
txtSobrenome Text Box
Nick Name nNickName String Varchar (25)
txtNickname Text Box -
Data aniversário dtNascimento Date Datetime
Sexo cSexo char Varchar (1)
rbSexoMasc Radio Button -
rbSexoFem Radio Button -
Palavra secreta String Varchar (20)

Nota: As células destacadas em cinza, servem para identificar grupos de símbolos
relacionados entre si.
11. Observações
Suas observações caso seja necessário.
Exemplo:
Rever o caso de uso UC0023 – Login do Internauta
O Sr. José ficou de enviar via e-mail até 12/04/05 o layout do arquivo de log de senhas.

37

12. Pendências

Existe alguma pendência ?
• Liste aqui as pendências referenciadas na descrição do caso de uso. Numere no local do
texto (entre colchetes) as pendências a medida que apareçam. É importante tentar
estabelecer datas para solução. A medida que as pendências forem sendo resolvidas, o
analista edita o texto definitivo no corpo do Caso de Uso (normalmente no cenário
principal ou no cenário alternativo) retirando os toquens de sinalização de pendências. A
versão do Caso de Uso deve ser salva sem eliminação da anterior, batizando o documento
do Caso de Uso com nome no formato:
UCnnnnnAAMMDD.doc (nnnnn = Número UC, AA = ano, MM = mes, DD = dia)

Nota: Use o nome do arquivo acima no campo Versão do rodapé.

Exemplo:
1. Layout da tela de login ainda em construção. Prazo para término: 04/04/05
2. Falta definir a tabela onde será armazenada a “palavra secreta” e a forma de utilização.
Reunião marcada para definição em 10/04/05
3. Algoritmo de seleção randômica de figuras na base de dados será definida até 15/04/05 –
Responsável: Sr André..

13. Rodapé
Analista responsável ________________________________________
Entrevistado: ________________________________________
Área: ________________________________________
Data: ________________________________________
Versão: ________________________________________

38

Diagrama de Classes

A representações da classe

NomeClasse

Ou

NomeClasse

Usamos um retângulo com o nome da classe escrito internamente (na forma reduzida) ou um
retângulo com 3 divisões (na forma plena). Escrevemos o nome da classe na primeira divisão. Se
necessário, podemos adicionar nesta repartição mais alguma informação relevante.

Note que o nome da classe está em negrito. (O tipo da fonte e o tamanho é livre)

Classes ativas e inativas

Classes ativas são as que inicializam e controlam o fluxo de dados e atividades.
Classe passivas são classes que apenas armazenam dados e serve a outras classes.
Caso seja necessário assinar uma classe como classe ativa use uma borda (externa) mais espessa no
diagrama:

NomeClasse

A representação de objetos

nomeObjeto:NomeClasse

Ou

nomeObjeto:NomeClasse

Representação de uma instância (objeto) na forma plena e reduzida. Notem que os nomes não estão
em negrito, mas sublinhados. Usamos o nome do objeto ligado ao nome da classe com um caractere
dois pontos (:)

39

Atributos (Propriedades)

Como sabemos, os atributos são variáveis e/ou objetos que declaramos como instâncias da classe.
Representamos os atributos no retângulo intermediário do diagrama (apenas da forma plena). Além
de representar o nome do atributo, representamos também seu tipo e visibilidade entre outras coisas.

NomeClasse
+nome: String
-dataNascimento: Data
#altura: inteiro
/idade: inteiro

O sinal de + antes do nome do atributo indica que o atributo é público. O sinal de – indica que o
atributo é privado e # que é protegido.
O sinal de / antes do atributo idade significa que este atributo além de privado também não terá um
método para modificá-lo. Normalmente usamos este tipo de atributo para valores calculados ou
gerados internamente a classe. Neste caso a idade é calculada com base na data de nascimento e a
data corrente do sistema.

Operações (métodos)

As operações ganharam o terceiro e último retângulo do diagrama.

NomeClasse
+nome: String
-dataNascimento: Data
#altura: inteiro
/idade: inteiro
+getIdade () : Inteiro
+setNome (nome:String)
+getNome () : String
+setAltura (altura:inteiro)
+getAltura () : Inteiro
Notas:

• O atributo idade possui um método get, mas não possui um método set.
• Os atributos nome e altura possuem ambos os métodos get e set.
• Apesar do nome ser, no exemplo, uma propriedade pública (o que não recomendado),
vamos definir o par de métodos get/set para ele também.

41

Associações de Classes
No POO é muito comum (e recomendável) que uma classe defina como atributos objetos de outras
classes. Chamamos a isto de Associação de Classes. Representamos a associação ligando as duas
classes com uma linha.
Falando mais formalmente, uma associação na UML representa uma população variada de vínculos
(links) de relacionamento entre instâncias de classe.
Por exemplo, vamos imaginar uma classe de DVDs (Títulos) de uma locadora e outra classe de
Clientes da locadora. O processo de locação é uma associação entre as duas classes. As locações são
um conjunto de muitos vínculos. Cada vínculo representa uma locação.

Clientes Locação Títulos (DVDs)

Podemos representar também a proporção da associação, ou seja, um cliente pode alugar um ou
mais filmes. Mas um filme não pode ser alugado por mais de um cliente ao mesmo tempo. Podemos
indicar estas proporções usando a seguinte sintaxe:

1 Não mais que uma
0..1 Nenhuma ou uma
* Muitas
0..* Nenhuma ou muitas
1..* Uma ou muitas

Exemplo:

Clientes Locação Títulos (DVDs)
1 1..*

Como vimos, para que haja uma locação será indispensável à existência de um cliente. Este cliente
terá que alugar pelo menos um título para que seja caracterizada a locação. O cliente pode entrar na
locadora e não alugar nenhum filme... Na classe Titulos não seria 0..* ? Porque não ?
Mas prestando mais atenção, vemos que Locação poderia ser uma classe com objeto Cliente e
objetos Títulos definidos como seus atributos. A classe que representa a associação (Locacao) deve
ser ligada a ambas por intermédio de uma linha pontilhada como mostra o diagrama abaixo.

Locação
...
...

|
|
|
Cliente Aluga | 1..* Títulos (DVDs)
1 é alugado

42

O estudo das associações se preocupa em entender como objetos de diferentes classes podem se
relacionar. Como o projetista poderá usar estas associações da melhor forma.
Existem basicamente quatro formas de associações: (Que veremos com mais detalhes a seguir)

1. Simples ou Binária: (nNária) Associação simples entre classes. Representa os casos em
que uma classe referencia a outra. As classes podem se referenciar mutuamente ou não.
Não é muito comum mas podemos ter múltiplas associas entre classes.

Exemplo: Produto e Fornecedor em uma classe de ItensPedido.

2. Composição: Temos uma composição quando o objeto de uma classe só existe enquanto
os objetos “hóspedes” existam, isto é, as partes são essenciais para a existência do todo.

Exemplo: Motor de um avião. Um avião não é um avião sem motor. (pode ser no
máximo um planador). Uma cadeira não é uma cadeira sem os pés (Mas é uma cadeira
sem os braços – Os braços não compoem a cadeira – são agregados).

3. Agregação: Temos uma agregação quando o objeto agregador pode continuar existindo
mesmo que seus agregados deixem de existir. A variação no número de sócios de um
clube, funcionários em uma empresa ou ovelhas em um rebanho não interfere na
existência do objeto que os contém.

Exemplo: Um clube (e seus sócios), um colégio (e seus alunos) , um departamento de
uma empresa (e seus funcionários).

4. Herança: Na herança, perguntamos se a classe candidata a ser uma subclasse é um “caso
particular” da provável superclasse. Se a provável superclasse possui atributos que com
certeza a subclasse irá compartilhar.

Exemplo: Mamífero é superclasse de Primata
Primata é superclasse de Ser Humano

Agregação

Como a agregação é uma composição familiar por meio da qual os sistemas de software
representam estruturas da vida real. Por exemplo, uma cidade é um agregado de casas, uma floresta
é um agregado de árvores etc. Em outras palavras a agregação é uma associação grupo/membro,
onde o grupo (ou agregado) é um objeto e seus membros (ou constituintes) outros objetos .
As características mais importantes da agregação são:

• O objeto agregado pode potencialmente existir sem seus objetos constituintes.

Exemplo: O departamento de uma empresa: É possível demitir todos os funcionários de uma
empresa, mas o departamento ainda continuará existindo... Não poderíamos dizer isso da
floresta.. ai o exemplo da floresta não se aplica... E um rebanho de ovelhas sem ovelhas ?
• Um objeto pode ser constituinte de mais de um agregado. É o caso de um cidadão poder ser
sócio de mais de um clube... Mas não seria o caso de uma ovelha pertencer a mais de um
rebanho...
• As agregações tendem a ser homogêneas. Isso quer dizer que os constituintes de um agregado
típico são todos de uma mesma classe. (Árvores, ovelhas, casas, cidadãos, ítens de pedido)

43

Vamos agora ao diagrama de uma associação:

RelatororioDeGerencia

◊ 0..*
{ordenado}
parteDoTexto 0..*

Parágrafo

• Usamos um pequeno losango vazio (diamante) na extremidade da linha de associação do
agregado próximo ao agregado.
• As classes do agregado (Relatório gerência e do constituinte (Parágrafo), aparecem nas
respectivas extremidades da linha de associação. O papel do objeto constituinte parteDoTexto
também aparece na extremidade do constituinte da linha de associação.
• Com a agregação, devemos mostrar a multiplicidade em ambas as extremidades da linha de
associação porque não é possível assumir a multiplicidade em todos os lugares. Veja que um
parágrafo pode pertencer a muitos relatórios de gerência ao mesmo tempo ou pode pertencer a
um relatório ou a nenhum. A multiplicidade na extremidade do constituinte também é 0..*.
Isso significa que um relatório pode compreender muitos parágrafos, ou um parágrafo ou
nenhum ( relatório vazio )
Exemplo

Pedido Itens Pedido
1.. *
-nroPedido : long
-datPedido : date -qtdItem : double
-datEntPedido:date -valUniItem : double

1.. *

Compõe
Produto
-desPro : String
-qtdPro : double
-valPro : double

Neste exemplo, a agregação existe apenas entre a classe Pedido e a classe Itens Pedidos (veja o
losango). A classe Produto possui apenas uma associação binária comum com a classe itens
Pedido. Note que os itens do pedido não podem existir sem que um pedido os tenha gerado.
Portanto, item pedido faz parte de pedido. Veja que a classe Produto não depende de Pedido
nem de Itens Pedido.

A agregação é tipicamente homogênea – São objetos idênticos

44

Composição

Constitui-se em uma variação da associação de agregação. Ela procura representar um vínculo mais
forte entre o objeto-todo e os objetos parte, procurando demonstrar que os objetos-parte tem de
pertencer exclusivamente a um único objeto-todo com que se relacionam.
Alguns objetos são “montados” a partir de outros objetos formando um conjunto com uma clara
identidade. Como exemplo podemos citar um computador. A idéia de um computador é, para uma
grande maioria das pessoas, o conjunto: Teclado + torre + terminal de vídeo. Usando um exemplo
mais próximo... um e-mail é uma composição de corpo, cabeçalho, arquivos anexados etc.
Podemos ver ainda o cabeçalho como a composição de assunto, remetente, destinatário, cc, cópia
oculta, data hora etc.
Usando o nosso exemplo do e-mail, Na composição chamamos o objeto e-mail de composto e os
objetos que o compõem (assunto, remetente etc.) de objeto componente.
Em uma composição, um mesmo objeto-parte não pode associar-se a mais de um objeto todo.
Neste caso usamos um losango (diamante) preenchido.

Principais Características das Composições:

1. O objeto composto não existe sem seus componentes. Um computador sem teclado torre e
monitor não é um computador. Assim, o tempo de vida de um de seus componentes não pode
ultrapassar o tempo de vida dos seus componentes.
2. À parte de um objeto composto não poderá pertencer a mais de um objeto composto.
3. A composição é sempre tipicamente heterogênea. Uma composição de muitos objetos
idênticos seria o caso de um array (ou vetor) de objetos. Isso quer dizer que as partes
normalmente não são do mesmo tipo.

Planador

1 1
1 fuselagem cauda 1 asaEesquerda asaDireita

Fuselagem Cauda Asa

Vamos dissecar esta figura para ver como o UML funciona.

• Cada associação aparece no diagrama como uma linha de associação, com um losango
(diamante) encostado no lado do objeto composto.
• A classe do objeto composto, Planador, aparece em uma extremidade da linha de associação. A
classe de cada componente – Fuselagem, Cauda e Asa. Note que asa é uma classe composta por
dois objetos: asaDireita e asaEsquerda.
• O papel do objeto componente na composição aparece na extremidade do componente na linha
de associação. Os papéis asaEsquerda e asaDireita são objetos da classe Asa. Cada um
45

desempenhando um papel diferente em um planador.
• Você pode (e deve) exibir multiplicidade na extremidade do componente de cada linha de
associação. Caso a multiplicidade seja omitida, assume-se como 1.
• As linhas de associação não tem qualquer nome... o que corresponde a uma norma tanto para
composição quanto para agregação.
• Notem que as partes: Fuselagem + Cauda + Asa(s), compõem 100% do planador.
Veja que a classe poderia ter os seguintes atributos declarados dentro dela:

Planador
-fuselagem: Fuselagem
-cauda: Cauda;
-asaEsquerda:Asa;
-asaDireita:Asa;
...

Exemplo de composição
Observando-se a figura baixo, percebe-se que um objeto da classe Revista Científica refere-se à
no mínimo um objeto da classe Edição, podendo referir-se a muitos objetos desta classe, e que
cada instância de classe Edição relaciona-se única e exclusivamente a uma instância específica da
classe Revista Científica, não podendo relacionar-se com nenhuma outra.
Notamos ainda que um objeto da classe Edição deve relacionar-se com no mínimo 5 e no
máximo10 objetos da classe Artigo. Este tipo de informação se torna útil como documentação e
serve como uma forma de validação, que impede que uma revista seja publicada sem ter no mínimo
5 artigos e não mais que 10. No entanto, um objeto da classe Artigo refere-se unicamente a um
objeto da classe Edição. Isto é também uma forma de documentação, já que uma edição de uma
revista científica só deve publicar trabalhos inéditos, assim é lógico que não é possível a um mesmo
objeto da classe Artigo relacionar-se a mais de um objeto da classe Edição.

Edição
Revista Científica
-ISSNRev : long -nroEdi: int
1.. * -volEdi:int
-titRev : String
-periodicidadeRev:String -datEdi: Data
Publica -tiragemEdi: int
+registrar()
+registrar() : int
+consultar(ISSNRev:long):int
+consultar(nroEdi:int, volEdi: int) : int

Contém
5..10

Artigo
-titArt : String
-pagIniArt : int

+registrar()
+consultar()

A composição é tipicamente heterogênea – São objetos diferentes

46

Herança

A Associação de Herança é conceitualmente bem diferente de composição e agregação. Em ambas
declaramos explicitamente objetos de outras classes como propriedades. A herança na realidade
“absorve” uma outra classe.
Veja o diagrama:

Vertebrados
Mamíferos

Aves Gorilas
Felinos Primatas
Orangotangos

As associação de herança representada acima esquematicamente (e que não tem nada a ver com
UML), mostra que um gorila é uma espécie de primata, que por sua vez é uma espécie de
mamífero que por sua vez é uma espécie de vertebrado e assim por diante. Isso significa que
quando instanciamos um gorila, estamos instanciando todas suas superclasses junto com ele... Na
natureza o conceito de herança fica assinalado pelo DNA das espécies. Todos os primatas, por
exemplo, compartilham uma grande seqüência idêntica de seu DNA entre si. Boa parte deste DNA é
compartilhado por todos mamíferos que por sua vez compartilham um parte ainda menor com os
vertebrados e assim por diante...

Vertebrados

Aves Mamíferos

Felinos Primatas

Orangotangos Gorilas

Já o diagrama acima representa (parcialmente) a associação de classes no formato UML (Exceto
pela graduação de tons de cinza demonstrando graduação da classe mais interna (cinza escuro) para
a mais externa(cinza claro) que é minha invenção).
Espero que esteja claro que o diagrama acima representa apenas uma pequena parte da árvore de
heranças da vida animal na natureza.
Estudaremos outros aspectos da herança mais a frente em Generalização.

47

Levantamento de Classes
Uma vez levantados os autores e os casos de uso, podemos partir para a codificação das classes.
A definição das classes necessárias para a realização de todas as funcionalidades do sistema envolve
o processo de síntese, ou seja, criação. Não existem regras claras e inequívocas para retirar classes
de casos de uso. É responsábilidade do projetista, baseadoem seu bom senso, criatividade e
experiência, determinar quais classes irão compor o sistema. A definição das classes exige umm
estudo detalhado dos requisitos do sistema e das possibilidades de separação dos dados e processos
em classes.

Estereótipos do Diagrama de Classes

São 'labels' escritos entre << e >>. Servem para esclarecer o significado de associações, diagramas
de classes e de outros elementos de UML.

Escrevemos os estereótipos sobre o nome da classe em fonte menor que a fonte usada para escrever
o nome da classe.

Vamos estudar alguns exemplos de estereótipos usados em diagramas de classes:
<<entity>>

Entidade: Identifica classes cujo papel principal é armazenar dados que juntos possuem
uma identidade. Este tipo de classe normalmente representa entidades do mundo real como
aluno, professor, disciplina, curso etc.

Torna explícito que uma classe é uma entidade, ou seja, a classe contem informações
recebidas ou geradas por meio do sistema. Significa também que normalmente possuirão
muitos objetos e que estes possivelmente terão um longo período de vida. Isto pode ser
interpretado como uma indicação que estas propriedades serão total ou parcialmente
preservadas (por tempo de vida, não em banco de dados)

<<persistent>>

Persistente: Com este estereótipo estamos indicando que 100% das propriedades serão
preservadas. Isso praticamente implica no uso de banco de dados.

Exemplo:

<<persistent>>

Conta Comum
#nrConta: long
#vlSaldo: double
#tipo: int

48

<<persistent>>

Conta Comum
+abertura(saldo:double, tipo:int):long
+encerramento():int
+saque(valor:double):int
+deposito(valor:double):double

Uma outra maneira de fazer isso é por meio de restrições. Isso é feito declarando o
estereótipo de <<entity>> e a restrição <<persistent>>.

49

Exemplo:

<<entity>>

Conta Comum {persistent}
#nrConta: long
#vlSaldo: double
#tipo: int
+abertura(saldo:double, tipo:int):long
+encerramento():int
+saque(valor:double):int
+deposito(valor:double):double

<<boundary>>

Fronteira: Também conhecido como estereótipo de fronteira. Identifica uma classe que
serve de comunicação entre atores externos e o sistema propriamente dito. Muitas vezes uma
classe <<boundary>> é associada à própria interface do sistema.

Identifica classes cujo papel é realizar o interfaceamento com entidades externas (atores) .
Este tipo de classe contém o protocolo necessário para comunicação com atores como
impressora, monitor, teclado, disco, porta serial, modem etc.

Uma classe de importação de tabelas de um sistema para outro também é um exemplo de
classe <<boundary>>.
<<control>>

Controle: Identifica classes que servem de intermédio entre classes <<boundary>> e as
outras classes do sistema. Objetos <<control>> são responsáveis por interpretar os eventos
ocorridos sobre os objetos <<boundary>>, como os movimentos do mouse, o
pressionamento de um botão e retransmití-los para objetos das classes de entidades que
compõem o sistema.

De outra forma, identifica classes cujo papel é controlar a execução de processos. Estas
classes contém, normalmente, o fluxo de execução de todo ou parte de casos de uso e
comandam outras classes na execução de procedimentos.
Exemplo:

<<boundary>>

Interface do Caixa Eletrônico

<<control>>

Controlador do Caixa Eletrônico

50

Algumas regras para definição de classes para casos de uso

1. Definir uma classe tipo fronteira para cada ator que participe do caso de uso.

No exemplo da unidade de ensino, teremos doas classes de fronteira:

Para a secretária:
Interface gráfica. (tela)
Para a impressora:
Configuração da impressora, protocolo, tipos de impressoras, portas etc.
Para SGBD
Abertura e fechamento de conexão etc.

2. Definir pelo menos uma classe tipo controle para cada caso de uso

Cada caso de uso implica em um encadeamento de ações a serem realizadas pelo sistema. As
regras de negócio a ser automatizado terão que estar definidas em alguma parte do sistema.
Este conhecimento pode estar distribuído em vários componentes do sistema, ou
centralizado em um ou poucos componentes. A vantagem de centralizar as regras do negócio
em um ou poucos componentes é a maior facilidade de entendimento do processo e
alterações e/ou manutenções futuras. Pensando nesta linha, pode-se criar uma classe de
controle para cada caso de uso de forma que ela contenha a descrição e comando do processo
associado ao caso de uso.

3. Definir classes de controle auxiliares

A medida que aumenta a complexidade das classes de controle, podemos criar classes mais
especializadas detalhando melhor os sub-processos.

4. Definir uma classe de tipo entidade para cada grupo de dados

Grupos de dados que juntos definem entidades abstratas ou do mundo real deveriam ser
representados por classes. Sugere-se, portanto, que para cada caso faça-se uma análise dos dados
manipulados e identifique-se grupos que serão representados, cada um, por uma classe.

51

Levantando Classes a Partir do Caso de Uso

Vamos considerar o (simples) diagrama de caso de uso abaixo para analisar as classes que serão
propostas:

Cadastrar Aluno

Secretária SGBD

Levando em conta as quatro regras vistas acima, podemos imediatamente concluir as classes:
• Duas classes de fronteira. Uma para cada ator. (Regra 1)

<<boundary>> <<boundary>>
CInterfaceSecretaria CInterfaceSGBD

• Uma classe de controle para gerenciar o cadastro como um todo (Regra 2.)

<<control>>
CControleCadAluno

• Três classes (detalhamento) estendidas de ControleCadAluno (Regra 3.)

<<control>> <<control>> <<control>>
<<extend>> <<extend>> <<extend>>
CControleIncluiAluno CControleAlteraAluno CControleExcluiAluno

Uma classe de entidade para cuidar do aluno. Como o SGBD não é uma entidade real, não é
necessário criar uma classe para ele. (Regra 4.)

<<entity>>
CAluno

52

Gerando Classes de Outro Caso de Uso

Vamos trabalhar com o caso de uso: Emitir Diário de Classe:

No exemplo anterior já foram criadas as classes de interface da secretária e do SGBD. Das
interfaces falta apenas a classe de interface da impressora.

Diferentemente do caso de uso Cadastrar Aluno, não será necessário desdobrar a classe de controle
pois ela não se justifica devido a sua simplicidade.

SGBD

Emitir Diário de Classe

Secretária

Impressora

<<boundary>> <<control>> <<entity>>
CInterfaceImpressora CDiarioClasse CDisciplina

-codigoTurma: String
-CodigoTurma: String -codigoTurma: String
-listaAlunos :: CAluno[]
-listaAlunos CAluno
-CodigoTurma: String -codigoDisciplina: String
-listaAlunos : CAluno -nomeDisciplina: String

<<entity>> <<entity>>
CProfessor CAluno

-codigo: int -registro: int
-nome: int
-codigo:String -nome: String
-registro: int
-categoria: byte
-nome: String -curso: String
-nome: char
-categoria: byte -curso: char

53

Diagrama de Caso de Usos De Sistema Seguradora

Note que o ator Vistoriador aparece duas vezes no diagrama. Na realidade trata-se do mesmo ator. O
motivo para duplicar o ícone é meramente estético. Evita-se com isso linhas muito emaranhadas
que, certamente, poluiriam o diagrama.
Um fator muito importante do projeto de um sistema, a cronologia, não está contemplada neste tipo
de diagrama. Podemos perceber que no diagrama que acabamos de descrever são apresentados
processos que ocorrem pelo menos em três momentos diferentes do sistema, o momento em que o
cliente solicita uma apólice de seguro, o momento em que ele paga uma parcela da apólice e o
momento em que ele informa a ocorrência de um sinistro.
O Diagrma de Casos de Uso não foi imaginado para representar a temporalidade. Seu objetivo é
identificar todas as possíveis funções que o sistema irá oferecer sem se preocupar muito com o
tempo em que elas ocorrerão. No próximo capítulo trataremos dos Diagramas de Seqüência
imaginados exatamente com esta finalidade.

54

O Diagrama de Classes do Diagrama de Casos de Uso

Cliente 1 ... * Apolice 1 ... 4 Parcela
-nomCli:String -placaVei:String -nroPar : int
-endCli:String -kmVei:long -dtVencParcela : date
-telCli:String Segura -nroApolice:long Possui -valorParcela : double
-dtNascCli:String -dtApolice:date -quiPar : boolean
+consultar():int -dtValidadeApolice:date +consulta(nroPar:int) : int
+registrar():int -valorApolice:double +quitar(nroPar:int) : int
+excluir():int -sitApolice: boolean
+gerarApolice()
+consultar(nroApolice,long):int
+invalidar(nroApol:long):int
0 ... * 0 ... *
Sofre Pertence
Sinistro Modelo 1 ... * Marca
-dataSinistro:date -descMod:String Produz -descMar:String
-descSinistro:String
+registrar():int
+consultar():int
1 ... * Produz
Tem 0 ... *
Tipo Danos
-descTipo:String -descDano:String

Examinando o diagrama de Classes

Ao examinar-mos a figura percebemos que um cliente, para se Cliente, precisa possuir ao menos
um apólice, podendo possuir diversas. Uma apólice de seguro deve pertencer única e
exclusivamente a um cliente. Da mesma forma uma apólice pode ser paga em uma até 4 parcelas,
mas cada parcela refere-se a uma única apólice.
Podemos ainda observar que um cliente pode ou não sofrer sinistros (multiplicidade 0 ..*), no
entanto um sinistro refere-se a somente um cliente, Percebemos ainda que cada sinistro possui um
tipo, ou seja, uma classificação, como perda total ou roubo, por exemplo, sendo que pode haver
diversos sinistros de um mesmo tipo, mas um tipo exclusivo para cada sinistro.Além disso, um
sinistro pode ou não trazer danos ao veículo..., e estes devem ser discriminados.
Note que cada instância da classe Modelo relaciona-se única e exclusivamente com uma instância
da classe Marca, como demostra a associação de composição.

55

Diagrama de Interação

Diagramas de Classe e de Caso de uso são estáticos por natureza, úteis para capturar a estrutura de
um desenho de sistema de modo generalizado. Conseqüentemente, estes diagramas não são
apropriados para especificar exigências de tempo real ou restrições de desenho.

Diagrama de interação é um termo genérico que se aplica a vários tipos de diagramas que enfatizam
interações de objetos. Uma interação é uma especificação comportamental que inclui uma seqüência
de trocas de mensagem entre um conjunto de objetos dentro de um contexto para realizar um
propósito específico, tal como a realização de um caso de uso. As mensagens podem incluir sinais e
chamadas implícitas decorrentes de condições e eventos de tempo
O diagrama de interação tem aplicabilidade para cumprir com exigências de seqüência onde cada
instância específica de caso de uso constitui um caminho particular de funcionalidade do sistema.
Em modelagem comportamental, é comum descrever vários cenários para cada caso de uso.

Interação em um caso de uso

Para especificar uma interação, é necessário definir contexto de caso de uso e estabelecer os objetos
que interagem e seus relacionamentos. Com isso, diagramas de interação são aplicados para mostrar
a realização de casos de uso,e as possíveis seqüências de interação são especificadas em uma
descrição única que contém condicionais (ramificações ou sinais condicionais) ou através de
descrições múltiplas, cada uma detalhando um caminho particular pelos possíveis caminhos de
realização.
O diagrama de interação deve ser usado quando se deseja visualizar o comportamento de vários
objetos dentro de um único caso de uso a partir das mensagens que são passados entre eles. Para se
compreender o comportamento de um único objeto para muitos casos de é melhor utilizar o
Diagrama de Estado. Para se analisar o comportamento para muitos casos de uso ou muitas linhas, é
recomendado o diagrama de atividade. Um dos pontos fortes do diagrama de interação é sua
simplicidade.
Existem dois tipos de diagramas de interação que veremos a seguir.
• Diagrama de Seqüência
• Diagrama de Colaboração

56

O Diagrama de Seqüência
Até aqui nos preocupamos de encontrar e definir os casos de uso e extrair suas classes por
intermédio dos diagramas de classe. Até ai não era relevante a ordem em que as coisas aconteciam
(estávamos nos abstraindo...) Agora chegou o momento...
Este Diagrama procura determinar a seqüência de eventos que ocorrem em um determinado
processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados
entre os objetos envolvidos e em que ordem durante um processo específico. Assim, determinar a
ordem em que os eventos ocorrem, as mensagens que são enviadas, os métodos que são chamados e
como os objetos interagem entre si dentro de um determinado processo.
A base para o Diagrama de seqüência é o Diagrama de Caso de Uso. No entanto deve-se ter em
mente que o fato de haver normalmente um único Diagrama de Caso de Uso não significa ter apenas
um único Diagrama de Seqüência.
Normalmente temos um Diagrama de Seqüência para cada processo específico do sistema. Todavia,
nem sempre um Caso de Uso gera obrigatoriamente um Diagrama de Seqüência, como é, muitas
vezes o que ocorre com casos de uso do tipo <<include>>, porque estes têm que ser executados
juntamente com outros Casos de Uso que os utilizam e, por isso muitas vezes suas etapas são
descritas nos Diagramas de Seqüência relativos aos Casos de Uso que os utiliza. Porém nada
impede que se defina um Diagram de Seqüência exclusivo para um Caso de Uso utilizado por
outros Casos de Uso através da associação <<include>>

Componentes do Diagrama de Seqüência

Atores
São exatamente os mesmos do Diagrama de Casos de Uso, ou seja entidades externas que interagem
com o sistema ou com outro ator envolvido no processo.
Os atores são representados também como bonecos magros mas agora com uma barra sob ele que
representa o que chamamos de Linha de Vida.

Exemplo:

Cliente

57

Objetos
Objetos representam instâncias das classes envolvidas no processo ilustrado pelo Diagrama de
Seqüência. Os objetos são representados como retângulos contendo um texto que identifica
primeiramente o nome do objeto, em minúsculo, e depois o nome da classe, com letras iniciais
maiúsculas, a qual o objeto pertence. Ambos são separados entre sí por um caracter : (dois pontos).
Abaixo do objeto desenhamos uma linha pontilhada que representa também sua linha de vida.

pessoa1:PessoaFisica

Observe que existe um objeto chamado pessoa1 que é uma instância da classe PessoaFisica.

Linha da Vida
Representa o tempo em que um objeto existiu durante um processo. Alinha de vida é interrompida
com um “X” quando o objeto é destruído. Um objeto não precisa necessariamente existir quando o
processo é iniciado podendo ser criado a qualquer momento durante o processo. Desta maneira, os
objetos criados não são representados no topo do diagrama, como no exemplo da figura 5.2, mas só
a partir do momento em que forem instanciados.
Achamos desnecessário em projetos Java/C++ explicitar a “morte” do objeto porque ou ela é feita a
revelia do projetista (no caso de Java por exemplo) ou por simples assepsia de memória sem motivo
relevante par ao projeto. Mesmo assim, representamos a existência ou não do objeto por segmento
mais encorpado do segmento da linha de vida.

Foco de Controle ou Ativação.
São retângulos finos (da mesma largura da linha da vida dos Atores) sobrepostos sobre a linha
pontilhada, representando o tempo em que um determinado objeto está ativo, ou seja, recebeu uma
mensagem e está em processamento.

Banco

1: Consulta cliente:ConCPF()

2: [se necessário] Dados do Cliente

3: [se necessário] Atualizar:Gravar()

4: Validar CPF: ValCPF
5: Cliente atualizado

58

Mensagens ou Estímulos
Mensagens são formas de comunicação do mundo exterior (atores) com os objetos. Os objetos
podem tanto receber dados do mundo exterior quanto retornar para eles. Nos diagramas UML
representamos também mensagens entre atores (sem envolver objetos), mas não trataremo aqui.
Nos diagramas de seqüência, as mensagens são representadas por retas entre os dois componentes
envolvidos, contendo uma seta para indicar qual dos objetos disparou a mensagem. (A seta sai de
quem dispara para quem recebe). Sobre a seta descrevemos a descrição da mensagem e, se for o
caso, o nome do procedimento a ser implementado.

Tipos de Mensagem
Informativas

Normalmente são responsáveis por inicializar ou alterar atributos dos objetos. São
tipicamente procedimentos com prefixo set.

Exemplos:

void setMatricula (String matricula);
void setLimite (double valor);

Interrogativas (ou de retorno)

São dados retornados pelos procedimentos. São tipicamente procedimentos com prefixo get.
Podem retornar simplesmente atributos do objeto ou retornar algum processamento.
No diagrama são representadas por uma seta tracejada.

Exemplos:

double getSalario ();
String getMatricula();

Imperativas
São mensagens usadas para realizar alguma operação de entrada e saída, inicializar algum
status etc.. Normalmente não possuem retorno (Não são interrogativas) nem argumentos
(Não são informativas). São representadas no diagrama de seqüência por uma seta de linha
contínua.

Exemplos:

void imprimeAluno ();
void enviaDadosLinha();
void clear();

Auto chamadas (ou Auto delegações)
São chamadas que um objeto envia para si mesmo. Normalmente um método utilitário (que
pode até ser privado) e que roda chamado de dentro do próprio objeto. Um método de check
digit ou criptografia podem ser exemplos de auto delegação.

59

Condições de Guarda (Operadores de Interação)
Indicam que uma mensagem só poderá ser enviada a um objeto se uma determinada condição for
verdadeira. As condições são descritas normalmente entre colchetes na mensagem, mas podem
também ser representadas por meio de restrições. Os operadores de interação são praticamente
fragmentos de código (ou pseudocódigo) representados no diagrama.
Normalmente seu significado é bastante intuitivo. Alguns autores procuram “padronizar” as
condições de guarda mas raramente os projetistas se prendem muito as estas tentativas de
padronização.
Exemplo:

a:Operador ca:Manutencao b:Maquina

DS Login [se início de trabalho]
IniciarTrabalho (operador, maquina)

[Se término trabalho]
TerminaTrabalho(operador, maquina);

Região Crítica
AutoDeteccaoProblema();
AcionaManutencao();

Diagrama de Seqüência para Abertura de uma Conta Comum
Neste exemplo iremos nos focalizar no processo representado pelo caso de uso Abertura de Conta
Comum. Este processo irá trabalhar com as classes PessoaFisica, ContaComum e
Historico, além dos atores Cliente ( que pode ser um cliente ativo ou candidato a cliente) e Banco
(representado por seus funcionários).

Na abertura de uma conta em um banco, não existe impedimento de abertura de mais de uma conta
individual, nem muito menos participar de mais de uma conta conjunta na mesma instituição.
Assim, a existência do cadastro do cliente não está condicionado ao cliente ter ou ter tido algum tipo
de conta na instituição.

60

Exemplo:

Cliente Banco

1: Solicita Abertura de
conta 2: Consulta cliente:
ConsultaCPF()

3: [Se existir] Dados do
Cliente

4: [Se necessario]
Atualizar: Gravar()

5: Validar CPF: ValCPF()
6: Cliente atualizado
7: Pedido aprovado

8: Fornecer valor de
depósito e senha
9: Abrir conta: Abertura()
conta1:ContaComum

10 : Registrar histórico :
Gravar()
hist1:Historico

11: Histórico registrado OK

12: Número de conta gerada
13: Abertura de conta
concluída

Como podemos verificar, primeiramente o cliente que deseja possuir uma conta no banco,
encaminha um pedido (verbal) de abertura de conta, com a devida documentação necessária (1). O
banco (na pessoa do funcionário), então irá consultar o cadastro de clientes, disparando o método
ConsultaCPF() da classe PessoaFisica, passando como parâmetro o CPF, para determinar se o
cliente já se encontra cadastrado (2). Se já estiver na base, a consulta retornará suas informações,
caso contrário retornará um valor significando que o cliente realmente ainda não possui cadastro na
instituição (3). Em seguida o cadastro poderá ser atualizado (se já existir) ou podendo gerar uma
nova instância da classe Cliente, se o solicitante não estiver cadastrado, ou simplesmente atualizar
os dados do mesmo caso haja algum dado para ser atualizado (4). A classe PessoaFisica faz
consistência do check digit do CPF (5) e retorna para o banco (funcionário) se a atualização correu
bem. (6), Quando o banco informa ao cliente que o cadastro foi aprovado.(7) O Cliente informa o
valor do deposito inicial e a senha (8). O banco procede a abertura da conta (9) instanciando um
novo objeto conta1. Durante a criação da conta será instanciado um objeto da classe Historico (10)
retornando o status de OK (11). O objeto conta1 retorna o número da conta (12) e é finalizando o
procedimento comunicando ao cliente que a conta está aberta e operante.(13)
Observem que os objetos criados (pessoa1, conta1 e hist1) não foram criados todos ao mesmo
tempo mas obedeceram uma cronologia lógica. Os objetos são criados a medida que aparece a
necessidade de sua criação. Como se pode observar, só é possível instanciar um objeto conta caso já
exista um objeto pessoa. Por sua vez, só é possível gerar objeto histórico de uma conta
efetivamente criada.
61

Diagrama de colaboração
Um diagrama de colaboração é uma visão de um conjunto de elementos de modelagem relacionados
para um propósito particular em apoio a interações. Assim, um diagrama de colaboração mostra
uma interação organizada em torno de objetos e seus vínculos formando uma base de padrões.
Diagramas de seqüência e diagrama de colaboração expressam informação semelhante mas
apresentam de forma diferente. O primeiro exibe uma seqüência explicita de mensagens e é melhor
para especificações de tempo real e para cenários complexos, enquanto o segundo mostra os
vínculos entre objetos e é melhor para atender os efeitos em um determinado objeto.

Para decidir qual melhor diagrama (seqüência ou colaboração) , uma maneira usual é escolher
colaboração quando o objeto e seus vínculos facilitam a compreensão da interação, escolher o
diagrama de seqüência somente se a seqüência necessita ser evidenciada.

Ao contrário do diagrama de seqüência, um diagrama de colaboração mostra os relacionamentos
entre objetos, mas não trata o tempo como um dimensão separada. A seqüência de tempo é indicada
numerando-se as mensagens dentro de um diagrama de colaboração, os objetos são desenhados
como ícones, como ocorre em diagramas de seqüência, setas indicam mensagens enviadas entre
objetos para realizar um caso de uso.

62

Em um diagrama de colaboração, uma condicional é indicado com uma condição de guarda entre
colchetes, ou seja, exibe uma condição que deve ser satisfeita para causar o disparo de uma
transição associada. Apresenta a mesma notação usada para sincronizar com outra linha, que
também é um tipo de condição usada para sincronizar com outra linha, que também é um tipo de
condição de guarda com execução, e a mesma notação usada para condições de guarda de um
diagrama de estado. Cada ramificação de condição é etiquetada como uma linha separada, igual a
uma linha simultânea. Uma determinada seqüência nomeada nas mensagens indica uma única linha
de controle que sempre é executada consecutivamente.

63

Bibliografia

• Fundamentos do Desenho Orientado a Objeto com UML – MEILIR PAGE-JONES –
MAKRON Books
• Desenvolvendo Software com UML 2.0 Definitivo – Ernani Medeiros – PEARSON /
MAKRON Books
• UML – Uma Abordagem Prática – Gilleanes T. A. Guedes – NOVATEC Editora
• UML e C++ - Gua prático de Desenvolvimento Orientado a Objeto – Richard C. LEE e
Willian M. Tepfenhart.- MAKRON Books
• Notas de aula do professor Marcello Thirty – UNIVALI São José.
thiry@sj.univali.br

64

Apostila UML

Mais conteúdo relacionado

Mais procurados (18)

Destaque (20)

Semelhante a Apostila UML (20)

Último (8)

Apostila UML