O documento apresenta os principais conceitos da programação orientada a objetos, incluindo classe, objeto, herança, sobrecarga, sobrescrita e polimorfismo. Além disso, discute o projeto orientado a objetos, modelagem UML, documentação e diagramas como classe, caso de uso e sequência.

1. Í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

2. 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

3. 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

4. }
4

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 18

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 40

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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