ÍndiceConceitos Iniciais................................................................................................................................. 3

Classe............................................................................................................................................... 3Objeto...............................................................................................................................................3Generalização...................................................................................................................................4

Herança........................................................................................................................................4Sobrecarga ( Overloading )......................................................................................................... 4

Assinaturas idênticas.............................................................................................................. 4Assinaturas diferentes.............................................................................................................4

Sobrescrita ( Overriding )............................................................................................................6Polimorfismo...............................................................................................................................7Encapsulamento ......................................................................................................................... 7

Ocultação de informações e Implementações.................................................................................. 7Retenção de Estado.......................................................................................................................... 7Identidade de um Objeto.................................................................................................................. 8

O Projeto Orientado a Objetos..............................................................................................................8Atividades Relacionadas ao Projeto OO..........................................................................................8UML – Unified Modeling Language............................................................................................... 9Metas UML....................................................................................................................................10Especialização / Generalização......................................................................................................11Inclusão.......................................................................................................................................... 11Extensão.........................................................................................................................................12Documentos iniciais.......................................................................................................................12Modelo de um documento Visão................................................................................................... 13Diagrama de Caso de Uso..............................................................................................................16

O Ator .......................................................................................................................................16Considerações sobre Atores...................................................................................................... 16Como identificar os Atores ?.....................................................................................................16O Caso de Uso...........................................................................................................................17Identificando Casos de Uso (Use cases)....................................................................................17Como encontrar um caso de uso ?.............................................................................................17Desenhando o diagrama............................................................................................................ 18

Relacionamentos entre Atores e Casos de Uso..............................................................................18Relacionamento entre Atores.................................................................................................... 18Relacionamento entre atores e Casos de Uso............................................................................18

Mais um exemplo de Caso de Uso de Nível Zero......................................................................... 21Exemplo Completo do Sistema de Controle Acadêmico...............................................................22Documento Nomenclatura............................................................................................................. 23

Modelo (sugestão) para nomenclatura:..................................................................................... 23Convenções de nomeação para objetos de Banco de dados......................................................25

O Documento Glossário.................................................................................................................26Casos de Uso..................................................................................................................................27

Como um Caso de Uso deve ser escrito?.................................................................................. 28Quem deve fazer a extração de casos de Uso ?.........................................................................28Como extrair um Caso de Uso.................................................................................................. 29

Diagrama de Classes ..................................................................................................................... 35A representações da classe........................................................................................................ 35Classes ativas e inativas............................................................................................................ 35A representação de objetos........................................................................................................35Atributos (Propriedades)........................................................................................................... 36Operações (métodos).................................................................................................................36Associações de Classes............................................................................................................. 37

1

Agregação.............................................................................................................................38Composição.......................................................................................................................... 40Herança.................................................................................................................................42Estereótipos do Diagrama de Classes...................................................................................43Algumas regras para definição de classes para casos de uso................................................45Levantando Classes a Partir do Caso de Uso....................................................................... 46

Gerando Classes de Outro Caso de Uso....................................................................................47Diagrama de Caso de Usos De Sistema Seguradora...........................................................................48O Diagrama de Classes do Diagrama de Casos de Uso.....................................................................49O Diagrama de Seqüência.................................................................................................................. 50

Componentes do Diagrama de Seqüência......................................................................................50Atores........................................................................................................................................ 50Objetos...................................................................................................................................... 51Linha da Vida............................................................................................................................ 51Foco de Controle ou Ativação...................................................................................................51Mensagens ou Estímulos...........................................................................................................52

Tipos de Mensagem..............................................................................................................52Imperativas........................................................................................................................... 52Auto chamadas (ou Auto delegações).................................................................................. 52Condições de Guarda (Operadores de Interação)................................................................. 53Diagrama 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 claroentendimento para que seja possível pensar orientado a objeto. Na realidade não é difícil, o grandeimpacto é causado pela diferença de como vínhamos pensado nos projetos convencionais. Opensamento 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 dadoobjeto pertence a uma classes. Sabemos na hora que um determinado objeto é uma caneta ou umacadeira 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 ecomportamento da classe da qual ele pertence. Se o objeto pertence à classe, dizemos que ele é umainstância da classe.

As classes são elementos fundamentais na composição de softwares orientados a objetos. Elas sãoempregadas tanto na composição do projeto dos sistemas computacionais quanto em suaimplementação. Entretanto, ao contrário dos objetos, as classes não se traduzem em elementosexecutores no código de implementação.

Exemplo de Classe: O ExcelExemplo de Objetos: Suas planilhas

Uma classe precisa definir os atributos e os procedimentos dos futuros objetos que serão criados apartir dela. A definição da classe tambem permite estabelecer regras claras de visibilidade de seuscomponentes (atributos e procedimentos). A definição dos atributos, procedimentos e o controle davisibilidade 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 defuncionalidades (procedimentos) e precisam ser configurados (atributos). Pensando em Java, osatributos 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

Objeto

É um representante “material” projetado com base em uma classe. Contrastando com as classes quenormalmente não existem como indivíduos, os objetos são a população que realmente sofre e causaefeitos.

Para reforçar, não existe nenhum indivíduo Aluno. O que existe são indivíduos definidos conformereza 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 queestamos 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 suasdiferenç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írculode raio constante e igual a um. Possui área e perímetro e mais uma série de outras propriedades emétodos. A idéia é aproveitar o que já foi feito para o círculo genérico e escrever apenas aspeculiaridades 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 omesmo nome, mas com assinaturas diferentes. Desta forma, o compilador decide (portanto emtempo de compilação) qual dos métodos sobrecarregados usar tomando como base a quantidadee/ou tipos dos argumentos.

A assinatura de um método é conhecida pela lista de argumentos no que concerne a sua quantidadetipo 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 doretorno 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 emordem 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 dasvariá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 demesma assinatura em níveis hierárquicos diferentes. O Compilador procura na classe atual aexistência do método invocado. Se encontrar usa, caso contrário subirá na hierarquia procurando ummé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 outrométodo na subclasse Quadrado também chamado getDiagonal. Ambos de mesma assinatura. Ométodo getDiagonal da classe Quadrado está sobrescrito sobre o método getDiagonal dasuperclasse Quadrilatero.

8

Nota sobre Sobrescrita e Sobrecarga:

Em Java, por ser uma linguagem praticamente interpretada, o tempo de compilação se confundecom 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 umaclasse 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 oidentificador de) objetos de diferentes classes em momentos diferentes.

Rigorosamente, consideramos como polimorfismo apenas os casos em que o objeto usado é definidotardiamente (ou seja, em tempo de execução – Dynamic binding), com o uso de uma referênciagenérica... Contudo existem duas formas de acesso “polimórfico” que não utilizam exatamente umareferência genérica nem são resolvidas em tempo de execução, mas “selecionam” um método (maisadequado) 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 quepossam 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 emuma só palavra. A construção de funções, procedures, performs etc, são exemplos deencapsulamento em outros paradigmas Em OO chegamos a um nível muito mais sofisticado deencapsulamento.

Ocultação de informações e Implementações

É a utilização de encapsulamento para restringir a visibilidade externa de certos detalhes deinformaçõ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 namemó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 vezesforem necessárias que o objeto continuará existindo entre as chamadas. Veja que na programaçãoestruturada tradicional, quando chamamos uma função, esta ganhará a CPU e a memória necessáriapara realizar suas funcionalidades. Ao seu término seus dados (variáveis automáticas) serãodescarregados 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 seridentificado 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ários2. Desenho do software3. Construção do software

• Reutilização• Confiabilidade• Invariantes de classe. É uma condição que todo objeto da classe deve satisfazer.

Exemplos: dataNascimento <= dataAtuallitrosAbastecer <= capacidadeTanque - litrosAtual

• RobustezDiz respeito principalmente à capacidade do software de se recuperar de falhas(Tratamento de exceções)

• EstensibilidadeAjuste 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 paraClientesNacionais e ClientesEstrangeiros sem modificar a classe Clientes, mas estendendoambas 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õescriados para garantir Distribuitividade é possível até utilizar classes desenvolvidas emlinguagens diferentes. (CORBA)

• Armazenabilidade

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

4. Manutenção de Software

Como todos que trabalham com software sabem, a manutenção de software é um poderosodreno 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 estensibilidadecomo 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 softwarecom o usuário. Atualmente os usuários esperam uma interface gráfica, o mais assemelhadapossível com o que já lhe é familiar em outras aplicações (GUIs). O projeto OO se prestaparticularmente 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çãodas bibliotecas de classes. O gerenciamento e todo este processo ganha uma enormeimportância. O gerente não precisa necessariamente entrar em detalhes de código das classesdesenvolvidas, mas, sem dúvida, deve conhecer suas características e estensibilidade.

O uso de UML, por exemplo, é uma forte ferramenta de gerenciamento de projetos. Quandouma fábrica de software passa a adotar OO, o pessoal de desenvolvimento passa a seespecializar em determinado grupo de classes que atendem a problemas específicos a ounegócios ou sub ramo de um negócio. A integração operacional e funcional de todas estasequipes pode ser muito facilitada com o gerenciamento utilizando as ferramentas UMLdesenvolvidas 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 odesenho de projeto orientado a objeto. Antes da UML os desenhistas de software tentavam ajustaros 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 novaarquitetura e não correspondiam as necessidades dos projetistas. Muitos cientistas da OOdesenvolveram algumas propostas de modelagem, mas, por um ou outro motivo, não se tornaramsuficientemente 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 umamá interpretação do desenho. O que se recomenda é que a empresa que estiver adotando UML deveescolher uma das variações que parecer mais “simpática” ou se ajustar melhor a linguagem usadanas aplicações.

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

UML foi escrito e proposto no final da década de 90 pelo trio Grady Booch, Ivar Jacobson e JinRumbaugh. 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, deforma 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 paraextensão na maioria das aplicações normais2. acrescentar novos conceitos e notações para temas não cobertos pelo núcleo3. escolher entre interpretações variantes de conceitos existentes, quando não houverum claro consenso.4. especificar os conceitos, as notações e as restrições, para domínios de aplicaçõesparticulares.

3. Ser independente de linguagem de programação e processos de desenvolvimentoparticulares.

4. Prover uma base formal para entendimento da linguagem de modelagem;5. Estimular o crescimento do mercado de ferramentas OO6. 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çãoO relacionamento de Especialização/Generalização é uma forma de Associação entre casos de usona qual existe dois ou mais casos de uso com muitas características semelhantes, apresentandocontudo algumas diferenças importantes entre si. Quando tal situação ocorre, costumamos definirum 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 UsoGeral.Desta forma não é necessário colocar a mesma documentação para todos os Casos de Usoenvolvidos porque toda a estrutura de um caso de uso generalizado é herdada pelos casos de usoespecializados. Além disso, os casos de uso especializados herdam também quaisquer possíveisAssociações de inclusão ou extensão que o Caso de uso Geral venha a possuir, bem como quaisquerAssociações com os Atores que utilizem o caso de uso geral. A Associação deGeneralização/Especialização é representada por uma seta que une o Caso de Uso Geral (para ondea seta aponta) Aos casos de uso especializados

Exemplo:

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

Exemplo:

13

Abertura conta especial

Abertura conta poupança

Abertura de conta

Depósito

Cliente

<<include>>

Saque

Registrar movimento

Banco

<<include>>

Como vimos na figura acima, tanto Saque quanto Depósito são casos de uso que devem serregistrados como movimento. Fica claro que o caso de uso Registrar Movimento será incluído noscasos de uso de Depósito e Saque. A associação de inclusão evitará a repetição da documentação deRegistrar 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 descreverclaramente o tipo de associação.

ExtensãoAssociações de Extensão são utilizadas para descrever cenários opcionais de um caso de uso. Oscasos 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íveldeterminar qual dos casos de uso estendidos serão executados.

Exemplo

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 nocaso do saldo estar positivo ou ainda nem um nem outro no caso do saldo da conta ser zero. Note osestereó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 estedocumento aborde aspectos de tecnologia (linguagem banco etc). Deve ser resumido e de linguagemacessí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ânciaestraté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. Asversões das visões devem ser salvas com o prefixo V seguido do número da versão. A identificação

14

Encerrar conta

Saque Depósito

ClienteBanco

<<extend>>

<<extend>>

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 emordem 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 sejacolocada à disposição de todos os envolvidos sempre a versão mais atualizada e também as antigaspara 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 projetoentrar 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 deglossá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 umcontrato. 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 pretendeganhar, 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-mailetc. Procure listar primeiro os clientes depois os usuários, tentando listar por ordemdecrescente 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 maisespecífico para lançar.

8. Módulos

Numere, nomeie e descreva as perspectivas de cada módulo do projeto. Procure descrever oque o módulo faz, para que serve e como se relacionará com outros módulos, se isso forimportante. 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 naordem 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 deprecedência para desenvolvimento ou não. Explique os critérios que você usou para definiros critérios, principalmente se um módulo mais importante teve que ser desenvolvido depoisde 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 performanceesperadas, 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 emquestã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ínimasde hardware como memória, capacidade em disco, placa de rede, conexões de rede eInternet, velocidade nas conexões etc.

Separe cada item (Sistema operacional, banco de dados etc em subitens separados)

11.1 Requisitos de software11.1.1 Sistema operacional.

11.1.2 Browser

11.1.3 etc...

11.2 Requisitos de hardware11.2.1 Memória mínimas

11.2.2 Espaço em HD

11.2.3 Placa de rede... etc

17

18

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 dosserviços a serem desempenhados pelo sistema. É também um bom meio de comunicação comclientes 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 suanotaçã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, umainstituiçã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 bonecomagro ou um retângulo com o nome do autor abaixo do estereótipo <<ator>>:

<<ator>>

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 estivereminteragindo com o sistema. O ator não representa um elemento particular, mas qualquer um queesteja 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 oresponsá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 representarum 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 atributose/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

Aluno

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ãoexecutadas 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 deuso 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 semdesenho, (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 é acapacidade 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 erelevantes. O problema é que quase sempre estes problemas são muito complexos e não serelacionam claramente entre si nem entre seus atores... Isso acaba tirando a concentração eobjetividade do que se está analisando. Acabamos não chegando a nada, ou o que é pior: a soluçõesequivocadas.

A abstração de mãos dadas com a metodologia UML de extração de casos de uso é uma ferramentaque pode ajudar a equacionar problemas de grande complexidade, encontrando soluções simples efá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 emdiagramas, é o fato de que podem ser compreendidos sem muita dificuldade pelos usuários eanalistas de negócio menos técnicos.

A seguir, algumas questões que podem ajudar a extrair os casos de uso dos problemas do mundoreal.

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 dosistema?

• 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 diagramaNos diagramas UML, o Caso de Uso é representado por uma elipse (as vezes colorida) com umtexto internamente identificando o caso de uso (algumas ferramentas UML escrevem o nome docaso de uso não internamente mas sobre a elipse). O caso de uso deve estar ligado a outros casos deuso ou a um Ator por uma linha contínua. Podemos usar uma seta de ponta vazia para indicar adireção da relação entre os casos de uso

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

Relacionamento entre Atores

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

Exemplo:

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

Exemplo:

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

22

Aluno Secretária

Solicita histórico

Professor Coordenador

Nome do Caso de Uso

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

Exemplo:

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

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

Muitas vezes um caso de uso é uma particularização de um outro já documentado. Estendendo ocaso 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 paradepois convertê-la para conta corrente especial.

23

ImpressoraSecretária

Emitir Histórico Escolar

Registrar Novo Aluno

Cadastrar Funcionário

Cadastrar Dependente

Calcular SalárioCálculo do Salário

Família

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

Conta CorrenteConta Corrente

Especial

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

Para exemplificarmos um diagrama de um sistema completo com seus casos de uso, atores erelacionamentos vamos examinar o projeto de uma locadora de DVDs

Este seria o diagrama de nível zero referido no modelo de Visão

Nós já vimos que UML prevê a possibilidade de ligação entre atores. Contudo, consideramos quese 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 fornecedornecessitar 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 oacesso do fornecedor ao site com esta finalidade.

Mesmo que realmente não exista um caso de uso “codificável” entre os atores, normalmenterepresentamos estes relacionamentos quando precisamos representar comunicações importantes parao entendimento do negócio.

O diagrama de Casos de Uso não tem reflexo direto em codificação. Ele é um instrumento devisualização da complexidade é a abstração da complexidade. Contudo, ao ser analisado e aprovadoo 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

Locar DVDEntregar Locação

Administrar Promoções

Administrar Multas

Devolução

Controlar Estoques

Administrar Marketing

Sistema de Locação de DVDs Via WEB

Cliente Site

Fornecedor

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

O Diagrama de Estudo de Caso de Nível Zero, se preocupa com os grandes casos de uso. Estescasos 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 nodiagrama 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 aatores.

O limite do sistema (fronteira) não foi desenhado apenas para diminuir a poluição do desenho.

25

Cadastrar aluno

Cadastrar professor

Cadastrar curso

Registrar matrícula

Emitir confirmação

Emitir diário de classes

Registrar notas

Emitir histórico escolar

Emitir confirmação

Secretária

Impressora

SGBD

Sistema de Controle Acadêmico

Exemplo Completo do Sistema de Controle Acadêmico

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

26

Cadastrar aluno

Incluir Aluno Alterar AlunoExcluir Aluno

Cadastrar Professor

Incluir ProfessorAlterar Professor

Excluir Professor

Cadastrar Curso

Incluir Curso Alterar CursoExcluir Curso

Registrar Matrícula

Registrar Nota

Emitir Diário de Classe

Emitir Confirmação de Matrícula

Emitir Histórico Escolar

Impressora

Secretaria

SGBD

Login

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Documento Nomenclatura

Este documento é usado para criarmos um padrão de prefixos e sufixos para todas as palavrasenvolvidas 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 emé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 sufixosque 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 DadosPrimitivos

Prefixo

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 PrefixoBigDecimal 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 foremnecessá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. Dequalquer 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 decada coluna. Naturalmente, caso seja feita alguma modificação do tipo da coluna durante a fase decodificação, toda a documentação (e código) deverá ser revista e, se for o caso, renomeada. Estaaparente desvantagem no final se mostra muito prático, pois será mais fácil identificar os possíveisimpactos 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 PrefixoTabela 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 algunsbancos 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 PrefixoColuna 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 corretamentepelos clientes e usuários.

O Glossário serve para traduzir em uma linguagem única todos os termos utilizados nadocumentaçã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 serfeito 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 derelevâ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 inferiora três meses

30

DVD Catálogo

Aquele disco de DVD que apresenta data de lançamento do filme superiora 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 comdescontos e prêmios.

Casos de UsoPara entender o conceito de Caso de Uso, precisamos entender o que é Ator. Como vimos o Atorpode 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 UsoPortanto, o Ator é alguém ou alguma coisa que atua ou interage com outras pessoas ou coisas demodo que algo seja realizado.

Um caso de uso pode ser entendido como uma macroatividade que encerra diversas tarefas ouatividades. 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çãodessa macroatividade. Enquanto tivermos afinidade entre as ações realizadas, teremos um Caso deUso.

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

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

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 partesdo desenvolvimento de sistemas orientados a objeto utilizando UML. Isso não quer dizer que deveser escrito um “tratado”. Por outro lado, a objetividade não deve suprimir nenhuma informaçãonem tornar a descrição da atividade nebulosa.

Devemos procurar utilizar a abstração. A abstração é: “Princípio de ignorar os aspectos de umassunto não relevantes para o propósito em questão.” Assim, devemos tratar cada abstração, emrelação ao que estamos analisando, como um negócio intrínseco a outro maior. Esteja sempre emmente que um sistema pertence a um negócio a ser automatizado. Ao aplicarmos a abstraçãopodemos 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 paraas mais diversas reações de seus futuros interlocutores. Uma o abordagem errada pode gerar umareaçã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 fazendocom 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 sedesvie muito, o entrevistador deverá, com habilidade, retornar ao assunto sem constranger oentrevistado. 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 aexplanaçã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 comoreferência como um trecho de código se referir a ele. Também pode ser usado comochave 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çãorá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 ospré 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 ocadastramento se efetive, o internauta deverá reconhecer e digitar um número de segurançaalém de ter 18 anos completos.

4. Atores envolvidos

• Procure listar os atores separados por vírgula para facilitar futuras buscas. O entrevistadodeve sempre estar entre os atores envolvidos. Procure nomes simples. Evite nomescompostos como Secretaria Executiva, Diretor Geral etc. Prefira nomes curtos e o maisgené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 sepreocupe 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 nopresente 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çõesvagas. Faça (e obtenha as respostas) as três perguntas básicas: O que é? , Para que? ouPor que?, Como ?Lembre-se que o que for descrito aqui e seu nível de detalhes deve ser suficiente para queas classes sejam codificadas. Caso alguma informação fique pendente, marque com umnú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 denascimento (DD/MM/AA), sexo (implementado em radio button), CPF (semformatação), endereço de e-mail, um login (usuário) e uma senha que será digitada emduplicata 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 visaevitar cadastro automático de internautas. Ao clicar no botão de confirmar, estandopreenchidos todos os campos obrigatórios e também correto o número de segurança, osistema salva o novo internauta no SGBD [2] envia um e-mail ao internauta confirmandoo cadastro e retorna.

2. Troca de senha: Ao clicar no ícone de troca de senhas o internauta é encaminhado para atela de login [1]. O internauta se 'loga' com a senha atual (<<include>> UC0056). Osistema identifica o internauta e mostra a tela de troca de senha. Aguarda a digitação emduplicata da nova senha. Esta deverá possuir no mínimo 6 e no máximo 8 dígitos, sendopelo menos um dígito alfanumérico. Será pedido também, opcionalmente, que ointernauta digite uma “palavra secreta” para ajudá-lo a relembrar a senha no caso deesquecimento.

No caso do internauta clicar em confirmar, o sistema consiste os dados e estando tudo OKa 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 é encaminhadopara a tela de login. O internauta se 'loga' (<<include>> UC0056), no sistema identifica ointernauta que é encaminhado para a tela de mudança de e-mail. O internauta se 'loga' natela e depois digita o novo e-mail. O sistema identifica, consiste os dados e enviaconfirmaçã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 maisadequado seria considerar os cenários Troca de Senha e Alteraçãode 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 sertratado individualmente separando em sub-itens relacionados aos itens do CenárioPrincipal.

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 reconhecimentocom 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 (menorde 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 assenhas.

1.6. Qualquer dos campos em branco (que não o Nick Name): O Internauta digita o campoem branco. O foco será colocado no primeiro campo em branco. Os campos preenchidosserã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 novadigitação.

1.9. Radio Button de sexo não está selecionado: É apresentada uma caixa de diálogocomunicando o fato. O internauta reconhece com OK e o foco será direcionado ao RadioButton 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 alertacom 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 novadigitaçã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 nemno alternativo ?

• Aqui colocamos as observações que o entrevistado destacou como importante ou detalhedelicado. 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 internautapode 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 eenviar 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 integralmentedurante a descrição do cenário principal ou alternativo. Seria o caso do login que, emalguns casos, pode ser evocado pelo caso de uso corrente. Não se preocupe de darexplicaçõ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 ocaso de a partir do caso de uso cadastro do Internauta, definíssemos outros três: Um parainclusão, outro para alteração e mais um para exclusão. Como no caso de incluídos, nãose 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 deuso. 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 osatores entrem ou recebam dados, também devem ser listados aqui.

Importante: Para cada componente gráfico, crie pelo menos umavariável para receber seus dados.

Exemplo:

Descrição Nome Tipo Banco deDados

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ímbolosrelacionados 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 dotexto (entre colchetes) as pendências a medida que apareçam. É importante tentarestabelecer datas para solução. A medida que as pendências forem sendo resolvidas, oanalista edita o texto definitivo no corpo do Caso de Uso (normalmente no cenárioprincipal ou no cenário alternativo) retirando os toquens de sinalização de pendências. Aversão do Caso de Uso deve ser salva sem eliminação da anterior, batizando o documentodo 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 umretângulo com 3 divisões (na forma plena). Escrevemos o nome da classe na primeira divisão. Senecessá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 nodiagrama:

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ãoem negrito, mas sublinhados. Usamos o nome do objeto ligado ao nome da classe com um caracteredois pontos (:)

39

40

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émde 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 oatributo é privado e # que é protegido.

O sinal de / antes do atributo idade significa que este atributo além de privado também não terá ummétodo para modificá-lo. Normalmente usamos este tipo de atributo para valores calculados ougerados internamente a classe. Neste caso a idade é calculada com base na data de nascimento e adata 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 () : InteiroNotas:

• 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 outrasclasses. Chamamos a isto de Associação de Classes. Representamos a associação ligando as duasclasses 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 deClientes da locadora. O processo de locação é uma associação entre as duas classes. As locações sãoum 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 oumais filmes. Mas um filme não pode ser alugado por mais de um cliente ao mesmo tempo. Podemosindicar 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 clienteterá que alugar pelo menos um título para que seja caracterizada a locação. O cliente pode entrar nalocadora 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 eobjetos Títulos definidos como seus atributos. A classe que representa a associação (Locacao) deveser 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 serelacionar. 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 emque 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 enquantoos 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 nomáximo um planador). Uma cadeira não é uma cadeira sem os pés (Mas é uma cadeirasem 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 existindomesmo que seus agregados deixem de existir. A variação no número de sócios de umclube, funcionários em uma empresa ou ovelhas em um rebanho não interfere naexistência do objeto que os contém.

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

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

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

Agregação

Como a agregação é uma composição familiar por meio da qual os sistemas de softwarerepresentam 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 umaempresa, mas o departamento ainda continuará existindo... Não poderíamos dizer isso dafloresta.. 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 sersócio de mais de um clube... Mas não seria o caso de uma ovelha pertencer a mais de umrebanho...

• As agregações tendem a ser homogêneas. Isso quer dizer que os constituintes de um agregadotí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:

• Usamos um pequeno losango vazio (diamante) na extremidade da linha de associação doagregado próximo ao agregado.

• As classes do agregado (Relatório gerência e do constituinte (Parágrafo), aparecem nasrespectivas extremidades da linha de associação. O papel do objeto constituinte parteDoTextotambé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 deassociação porque não é possível assumir a multiplicidade em todos os lugares. Veja que umparágrafo pode pertencer a muitos relatórios de gerência ao mesmo tempo ou pode pertencer aum 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 ounenhum ( relatório vazio )

Exemplo

Neste exemplo, a agregação existe apenas entre a classe Pedido e a classe Itens Pedidos (veja olosango). A classe Produto possui apenas uma associação binária comum com a classe itensPedido. 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 Pedidonem de Itens Pedido.

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

44

RelatororioDeGerencia

Parágrafo

◊ 0..*

0..*parteDoTexto

{ordenado}

Pedido

-nroPedido : long-datPedido : date-datEntPedido:date

Itens Pedido

-qtdItem : double-valUniItem : double

Produto

-desPro : String-qtdPro : double-valPro : double

1.. *

Compõe

1.. *

Composição

Constitui-se em uma variação da associação de agregação. Ela procura representar um vínculo maisforte entre o objeto-todo e os objetos parte, procurando demonstrar que os objetos-parte tem depertencer 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 claraidentidade. Como exemplo podemos citar um computador. A idéia de um computador é, para umagrande maioria das pessoas, o conjunto: Teclado + torre + terminal de vídeo. Usando um exemplomais 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ópiaoculta, data hora etc.

Usando o nosso exemplo do e-mail, Na composição chamamos o objeto e-mail de composto e osobjetos 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 emonitor não é um computador. Assim, o tempo de vida de um de seus componentes não podeultrapassar 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 objetosidênticos seria o caso de um array (ou vetor) de objetos. Isso quer dizer que as partesnormalmente não são do mesmo tipo.

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. Aclasse de cada componente – Fuselagem, Cauda e Asa. Note que asa é uma classe composta pordois objetos: asaDireita e asaEsquerda.

• O papel do objeto componente na composição aparece na extremidade do componente na linhade associação. Os papéis asaEsquerda e asaDireita são objetos da classe Asa. Cada um

45

Planador

Fuselagem Cauda Asa

fuselagem1 cauda 1 asaEesquerda asaDireita11

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 quecada instância de classe Edição relaciona-se única e exclusivamente a uma instância específica daclasse 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 nomáximo10 objetos da classe Artigo. Este tipo de informação se torna útil como documentação eserve como uma forma de validação, que impede que uma revista seja publicada sem ter no mínimo5 artigos e não mais que 10. No entanto, um objeto da classe Artigo refere-se unicamente a umobjeto da classe Edição. Isto é também uma forma de documentação, já que uma edição de umarevista científica só deve publicar trabalhos inéditos, assim é lógico que não é possível a um mesmoobjeto da classe Artigo relacionar-se a mais de um objeto da classe Edição.

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

46

Revista Científica

+registrar()+consultar(ISSNRev:long):int

-ISSNRev : long-titRev : String-periodicidadeRev:String

Edição

+registrar() : int+consultar(nroEdi:int, volEdi: int) : int

-nroEdi: int-volEdi:int-datEdi: Data-tiragemEdi: int

Artigo

+registrar()+consultar()

-titArt : String-pagIniArt : int

1.. *

Contém

5..10

Publica

Herança

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

Veja o diagrama:

As associação de herança representada acima esquematicamente (e que não tem nada a ver comUML), mostra que um gorila é uma espécie de primata, que por sua vez é uma espécie demamífero que por sua vez é uma espécie de vertebrado e assim por diante. Isso significa quequando instanciamos um gorila, estamos instanciando todas suas superclasses junto com ele... Nanatureza o conceito de herança fica assinalado pelo DNA das espécies. Todos os primatas, porexemplo, 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 osvertebrados e assim por diante...

Já o diagrama acima representa (parcialmente) a associação de classes no formato UML (Excetopela graduação de tons de cinza demonstrando graduação da classe mais interna (cinza escuro) paraa mais externa(cinza claro) que é minha invenção).

Espero que esteja claro que o diagrama acima representa apenas uma pequena parte da árvore deheranças da vida animal na natureza.

Estudaremos outros aspectos da herança mais a frente em Generalização.

47

Primatas

Vertebrados

Mamíferos

Gorilas

Aves

Felinos

Orangotangos

Vertebrados

Mamíferos

PrimatasGorilas

OrangotangosFelinos

Aves

Levantamento de ClassesUma 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 envolveo processo de síntese, ou seja, criação. Não existem regras claras e inequívocas para retirar classesde casos de uso. É responsábilidade do projetista, baseadoem seu bom senso, criatividade eexperiência, determinar quais classes irão compor o sistema. A definição das classes exige ummestudo detalhado dos requisitos do sistema e das possibilidades de separação dos dados e processosem classes.

Estereótipos do Diagrama de Classes

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

Escrevemos os estereótipos sobre o nome da classe em fonte menor que a fonte usada para escrevero 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 possuemuma identidade. Este tipo de classe normalmente representa entidades do mundo real comoaluno, professor, disciplina, curso etc.

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

<<persistent>>

Persistente: Com este estereótipo estamos indicando que 100% das propriedades serãopreservadas. 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 oestereó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 queserve de comunicação entre atores externos e o sistema propriamente dito. Muitas vezes umaclasse <<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 comoimpressora, monitor, teclado, disco, porta serial, modem etc.

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

<<control>>

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

De outra forma, identifica classes cujo papel é controlar a execução de processos. Estasclasses contém, normalmente, o fluxo de execução de todo ou parte de casos de uso ecomandam 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. Asregras 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, oucentralizado em um ou poucos componentes. A vantagem de centralizar as regras do negócioem um ou poucos componentes é a maior facilidade de entendimento do processo ealterações e/ou manutenções futuras. Pensando nesta linha, pode-se criar uma classe decontrole para cada caso de uso de forma que ela contenha a descrição e comando do processoassociado ao caso de uso.

3. Definir classes de controle auxiliares

A medida que aumenta a complexidade das classes de controle, podemos criar classes maisespecializadas 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 serrepresentados por classes. Sugere-se, portanto, que para cada caso faça-se uma análise dos dadosmanipulados 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ãopropostas:

Levando em conta as quatro regras vistas acima, podemos imediatamente concluir as classes:

• Duas classes de fronteira. Uma para cada ator. (Regra 1)

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

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

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

52

Cadastrar Aluno

Secretária SGBD

<<boundary>>CInterfaceSecretaria

<<boundary>>CInterfaceSGBD

<<control>>CControleCadAluno

<<control>><<extend>>

CControleIncluiAluno

<<control>><<extend>>

CControleAlteraAluno

<<control>><<extend>>

CControleExcluiAluno

<<entity>>CAluno

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. Dasinterfaces falta apenas a classe de interface da impressora.

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

53

Emitir Diário de Classe

Secretária

Impressora

SGBD

<<boundary>>CInterfaceImpressora

-CodigoTurma: String-listaAlunos : CAluno

<<control>>CDiarioClasse

-CodigoTurma: String-listaAlunos : CAluno

<<entity>>CDisciplina

-codigoTurma: String-codigoDisciplina: String-nomeDisciplina: String

-codigoTurma: String-listaAlunos : CAluno[]

-codigo: int-nome: String-categoria: byte

<<entity>>CProfessor

-codigo: int-nome: String-categoria: byte

-registro: int-nome: String-curso: char

<<entity>>CAluno

-registro: int-nome: String-curso: char

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. Omotivo para duplicar o ícone é meramente estético. Evita-se com isso linhas muito emaranhadasque, certamente, poluiriam o diagrama.

Um fator muito importante do projeto de um sistema, a cronologia, não está contemplada neste tipode diagrama. Podemos perceber que no diagrama que acabamos de descrever são apresentadosprocessos que ocorrem pelo menos em três momentos diferentes do sistema, o momento em que ocliente solicita uma apólice de seguro, o momento em que ele paga uma parcela da apólice e omomento 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 otempo em que elas ocorrerão. No próximo capítulo trataremos dos Diagramas de Seqüênciaimaginados exatamente com esta finalidade.

54

O Diagrama de Classes do Diagrama de Casos de Uso

Cliente-nomCli:String

1 ... * Apolice-placaVei:String

1 ... 4 Parcela-nroPar : int

-endCli:String

-telCli:String

-dtNascCli:String

+consultar():int

+registrar():int

+excluir():int

Segura

-kmVei:long

-nroApolice:long

-dtApolice:date

-dtValidadeApolice:date

-valorApolice:double

-sitApolice: boolean

+gerarApolice()

+consultar(nroApolice,long):int

+invalidar(nroApol:long):int

Possui

-dtVencParcela : date

-valorParcela : double

-quiPar : boolean

+consulta(nroPar:int) : int

+quitar(nroPar:int) : int

0 ... *

Sofre

0 ... *

Pertence

Sinistro Modelo 1 ... * Marca-dataSinistro:date

-descSinistro:String

-descMod:String Produz -descMar:String

+registrar():int

+consultar():int

1 ... *

Tem

Produz

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 menosum apólice, podendo possuir diversas. Uma apólice de seguro deve pertencer única eexclusivamente 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 ..*), noentanto um sinistro refere-se a somente um cliente, Percebemos ainda que cada sinistro possui umtipo, ou seja, uma classificação, como perda total ou roubo, por exemplo, sendo que pode haverdiversos sinistros de um mesmo tipo, mas um tipo exclusivo para cada sinistro.Além disso, umsinistro 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ânciada 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 deum desenho de sistema de modo generalizado. Conseqüentemente, estes diagramas não sãoapropriados 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 enfatizaminterações de objetos. Uma interação é uma especificação comportamental que inclui uma seqüênciade trocas de mensagem entre um conjunto de objetos dentro de um contexto para realizar umpropósito específico, tal como a realização de um caso de uso. As mensagens podem incluir sinais echamadas 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 cadainstâ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 objetosque interagem e seus relacionamentos. Com isso, diagramas de interação são aplicados para mostrara realização de casos de uso,e as possíveis seqüências de interação são especificadas em umadescrição única que contém condicionais (ramificações ou sinais condicionais) ou através dedescrições múltiplas, cada uma detalhando um caminho particular pelos possíveis caminhos derealização.

O diagrama de interação deve ser usado quando se deseja visualizar o comportamento de váriosobjetos dentro de um único caso de uso a partir das mensagens que são passados entre eles. Para secompreender o comportamento de um único objeto para muitos casos de é melhor utilizar oDiagrama 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 é suasimplicidade.

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üênciaAté aqui nos preocupamos de encontrar e definir os casos de uso e extrair suas classes porintermé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 determinadoprocesso, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparadosentre os objetos envolvidos e em que ordem durante um processo específico. Assim, determinar aordem em que os eventos ocorrem, as mensagens que são enviadas, os métodos que são chamados ecomo 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 emmente que o fato de haver normalmente um único Diagrama de Caso de Uso não significa ter apenasum ú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 é, muitasvezes o que ocorre com casos de uso do tipo <<include>>, porque estes têm que ser executadosjuntamente com outros Casos de Uso que os utilizam e, por isso muitas vezes suas etapas sãodescritas nos Diagramas de Seqüência relativos aos Casos de Uso que os utiliza. Porém nadaimpede que se defina um Diagram de Seqüência exclusivo para um Caso de Uso utilizado poroutros Casos de Uso através da associação <<include>>

Componentes do Diagrama de Seqüência

AtoresSão exatamente os mesmos do Diagrama de Casos de Uso, ou seja entidades externas que interagemcom 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 querepresenta o que chamamos de Linha de Vida.

Exemplo:

57

Cliente

ObjetosObjetos representam instâncias das classes envolvidas no processo ilustrado pelo Diagrama deSeqüência. Os objetos são representados como retângulos contendo um texto que identificaprimeiramente o nome do objeto, em minúsculo, e depois o nome da classe, com letras iniciaismaiú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.

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

Linha da VidaRepresenta o tempo em que um objeto existiu durante um processo. Alinha de vida é interrompidacom um “X” quando o objeto é destruído. Um objeto não precisa necessariamente existir quando oprocesso é iniciado podendo ser criado a qualquer momento durante o processo. Desta maneira, osobjetos 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 arevelia do projetista (no caso de Java por exemplo) ou por simples assepsia de memória sem motivorelevante par ao projeto. Mesmo assim, representamos a existência ou não do objeto por segmentomais 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 linhapontilhada, representando o tempo em que um determinado objeto está ativo, ou seja, recebeu umamensagem e está em processamento.

58

pessoa1:PessoaFisica

4: Validar CPF: ValCPF

1: Consulta cliente:ConCPF()

2: [se necessário] Dados do Cliente

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

5: Cliente atualizado

pessoa1:PessoaFisica

Banco

Mensagens ou EstímulosMensagens são formas de comunicação do mundo exterior (atores) com os objetos. Os objetospodem tanto receber dados do mundo exterior quanto retornar para eles. Nos diagramas UMLrepresentamos 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 componentesenvolvidos, contendo uma seta para indicar qual dos objetos disparou a mensagem. (A seta sai dequem dispara para quem recebe). Sobre a seta descrevemos a descrição da mensagem e, se for ocaso, o nome do procedimento a ser implementado.

Tipos de MensagemInformativas

Normalmente são responsáveis por inicializar ou alterar atributos dos objetos. Sãotipicamente 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 algumstatus 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 linhacontí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 (quepode até ser privado) e que roda chamado de dentro do próprio objeto. Um método de checkdigit 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 forverdadeira. As condições são descritas normalmente entre colchetes na mensagem, mas podemtambém ser representadas por meio de restrições. Os operadores de interação são praticamentefragmentos de código (ou pseudocódigo) representados no diagrama.

Normalmente seu significado é bastante intuitivo. Alguns autores procuram “padronizar” ascondições de guarda mas raramente os projetistas se prendem muito as estas tentativas depadronização.

Exemplo:

Diagrama de Seqüência para Abertura de uma Conta Comum

Neste exemplo iremos nos focalizar no processo representado pelo caso de uso Abertura de ContaComum. Este processo irá trabalhar com as classes PessoaFisica, ContaComum eHistorico, 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 containdividual, 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 tipode conta na instituição.

60

DS Login

Região Crítica

[se início de trabalho]

TerminaTrabalho(operador, maquina);

AutoDeteccaoProblema();

AcionaManutencao();

a:Operador ca:Manutencao b:Maquina

[Se término trabalho]

IniciarTrabalho (operador, maquina)

Exemplo:

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). Obanco (na pessoa do funcionário), então irá consultar o cadastro de clientes, disparando o métodoConsultaCPF() da classe PessoaFisica, passando como parâmetro o CPF, para determinar se ocliente 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 nainstituição (3). Em seguida o cadastro poderá ser atualizado (se já existir) ou podendo gerar umanova instância da classe Cliente, se o solicitante não estiver cadastrado, ou simplesmente atualizaros dados do mesmo caso haja algum dado para ser atualizado (4). A classe PessoaFisica fazconsistência do check digit do CPF (5) e retorna para o banco (funcionário) se a atualização correubem. (6), Quando o banco informa ao cliente que o cadastro foi aprovado.(7) O Cliente informa ovalor do deposito inicial e a senha (8). O banco procede a abertura da conta (9) instanciando umnovo 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 oprocedimento 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 mesmotempo mas obedeceram uma cronologia lógica. Os objetos são criados a medida que aparece anecessidade 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 contaefetivamente criada. 61

Cliente Banco

pessoa1:PessoaFisica

conta1:ContaComum

hist1:Historico

1: Solicita Abertura de conta

7: Pedido aprovado

8: Fornecer valor de depósito e senha

13: Abertura de conta concluída

2: Consulta cliente:ConsultaCPF()

3: [Se existir] Dados do Cliente

4: [Se necessario] Atualizar: Gravar()

5: Validar CPF: ValCPF()

9: Abrir conta: Abertura()

6: Cliente atualizado

10 : Registrar histórico : Gravar()

11: Histórico registrado OK

12: Número de conta gerada

Diagrama de colaboraçãoUm diagrama de colaboração é uma visão de um conjunto de elementos de modelagem relacionadospara um propósito particular em apoio a interações. Assim, um diagrama de colaboração mostrauma 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 masapresentam de forma diferente. O primeiro exibe uma seqüência explicita de mensagens e é melhorpara especificações de tempo real e para cenários complexos, enquanto o segundo mostra osví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 é escolhercolaboração quando o objeto e seus vínculos facilitam a compreensão da interação, escolher odiagrama 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 relacionamentosentre objetos, mas não trata o tempo como um dimensão separada. A seqüência de tempo é indicadanumerando-se as mensagens dentro de um diagrama de colaboração, os objetos são desenhadoscomo ícones, como ocorre em diagramas de seqüência, setas indicam mensagens enviadas entreobjetos para realizar um caso de uso.

62

Em um diagrama de colaboração, uma condicional é indicado com uma condição de guarda entrecolchetes, ou seja, exibe uma condição que deve ser satisfeita para causar o disparo de umatransição associada. Apresenta a mesma notação usada para sincronizar com outra linha, quetambém é um tipo de condição usada para sincronizar com outra linha, que também é um tipo decondição de guarda com execução, e a mesma notação usada para condições de guarda de umdiagrama de estado. Cada ramificação de condição é etiquetada como uma linha separada, igual auma linha simultânea. Uma determinada seqüência nomeada nas mensagens indica uma única linhade 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 eWillian M. Tepfenhart.- MAKRON Books

• Notas de aula do professor Marcello Thirty – UNIVALI São José.

thiry@sj.univali.br

64