Apostila UML

8.579 visualizações

Publicada em

Estudo básico sobre UML

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
8.579
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
462
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Apostila UML

  1. 1. ÍndiceConceitos Iniciais................................................................................................................................. 3 Classe............................................................................................................................................... 3 Objeto...............................................................................................................................................3 Generalização...................................................................................................................................4 Herança........................................................................................................................................4 Sobrecarga ( Overloading )......................................................................................................... 4 Assinaturas idênticas.............................................................................................................. 4 Assinaturas diferentes.............................................................................................................4 Sobrescrita ( Overriding )............................................................................................................6 Polimorfismo...............................................................................................................................7 Encapsulamento ......................................................................................................................... 7 Ocultação de informações e Implementações.................................................................................. 7 Retenção de Estado.......................................................................................................................... 7 Identidade de um Objeto.................................................................................................................. 8O Projeto Orientado a Objetos..............................................................................................................8 Atividades Relacionadas ao Projeto OO..........................................................................................8 UML – Unified Modeling Language............................................................................................... 9 Metas UML....................................................................................................................................10 Especialização / Generalização......................................................................................................11 Inclusão.......................................................................................................................................... 11 Extensão.........................................................................................................................................12 Documentos iniciais.......................................................................................................................12 Modelo de um documento Visão................................................................................................... 13 Diagrama de Caso de Uso..............................................................................................................16 O Ator .......................................................................................................................................16 Considerações sobre Atores...................................................................................................... 16 Como identificar os Atores ?.....................................................................................................16 O Caso de Uso...........................................................................................................................17 Identificando Casos de Uso (Use cases)....................................................................................17 Como encontrar um caso de uso ?.............................................................................................17 Desenhando o diagrama............................................................................................................ 18 Relacionamentos entre Atores e Casos de Uso..............................................................................18 Relacionamento entre Atores.................................................................................................... 18 Relacionamento entre atores e Casos de Uso............................................................................18 Mais um exemplo de Caso de Uso de Nível Zero......................................................................... 21 Exemplo Completo do Sistema de Controle Acadêmico...............................................................22 Documento Nomenclatura............................................................................................................. 23 Modelo (sugestão) para nomenclatura:..................................................................................... 23 Convenções de nomeação para objetos de Banco de dados...................................................... 25 O Documento Glossário.................................................................................................................26 Casos de Uso..................................................................................................................................27 Como um Caso de Uso deve ser escrito?.................................................................................. 28 Quem deve fazer a extração de casos de Uso ?.........................................................................28 Como extrair um Caso de Uso.................................................................................................. 29 Diagrama de Classes ..................................................................................................................... 35 A representações da classe........................................................................................................ 35 Classes ativas e inativas............................................................................................................ 35 A representação de objetos........................................................................................................35 Atributos (Propriedades)........................................................................................................... 36 Operações (métodos).................................................................................................................36 Associações de Classes............................................................................................................. 37 1
  2. 2. Agregação.............................................................................................................................38 Composição.......................................................................................................................... 40 Herança.................................................................................................................................42 Estereótipos do Diagrama de Classes...................................................................................43 Algumas regras para definição de classes para casos de uso................................................45 Levantando Classes a Partir do Caso de Uso....................................................................... 46 Gerando Classes de Outro Caso de Uso....................................................................................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......................................................................................50 Atores........................................................................................................................................ 50 Objetos...................................................................................................................................... 51 Linha da Vida............................................................................................................................ 51 Foco de Controle ou Ativação...................................................................................................51 Mensagens ou Estímulos...........................................................................................................52 Tipos de Mensagem..............................................................................................................52 Imperativas........................................................................................................................... 52 Auto chamadas (ou Auto delegações).................................................................................. 52 Condições de Guarda (Operadores de Interação)................................................................. 53 Diagrama de Seqüência para Abertura de uma Conta Comum............................................ 53Bibliografia......................................................................................................................................... 55 2
  3. 3. Conceitos IniciaisO 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 Excel Exemplo de Objetos: Suas planilhasUma 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 Is. Eles são projetados para se “encaixarem”em diversos tipos de projetos, com inúmeras aplicações. Os C Is 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. 4. } 4
  5. 5. 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
  6. 6. Exemplo: public class CirculoTrigonometrico extends Circulo { private double arco; public CirculoTrigonometrico (double arco) { super(1); // Passando para a super classe o raio = 1 this.arco = arco; } public double getSeno() { return Math.sin(arco); } public double getCosseno () { return Math.cos(arco); } public double getTangente() { return getSeno()/getCosseno(); } public double getArco() { return arco; } }Usando a classe CirculoTrigonometrico: public class Teste { public static void main (String args[]) { CirculoTrigonometrico ct1 = new CirculoTrigonometrico(30); System.out.println (“Seno de ” + ct1.getArco() + “ = “ + ct1.getSeno()); } }Sobrecarga ( Overloading )Podemos escrever mais de um método em uma mesma classe (ou em alguma superclasse) com 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 do retorno não é considerado como fazendo parte da assinatura. 6
  7. 7. Assinaturas diferentesvoid setDadosConta(String nome, long numConta);void setDadosConta(long numConta, String nome);void setDadosConta(String nome, long numConta, double valDeposito);• No segundo exemplo a quantidade e tipos de argumentos são os mesmos mas estão em ordem diferente.• No terceiro exemplo, o método possui um argumento a mais.Exemplo (em UML e Java) de uma classe com sobrecaga de métodos:A classe abaixo, implementa uma série de métodos utilitários para retornar o tipo 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) : StringA Classe em Java:1.public class MostraTipo {2.3. public String tipo (char a) {4. return "char";5. }6. public String tipo (int a) {7. return "int";8. }9. public String tipo (long a) {10. return "long";11. }12. public String tipo (double a) {13. return "double";14. }15. public String tipo (float a) {16. return "float";17. }18. public String tipo (byte a) {19. return "byte";20. }21.} 7
  8. 8. Usando Sobrecarga: 1.public class TesteSobrecarga { 2. static public void main (String args[]) { 3. long a = 12344L; 4. int b = 45; 5. float c = 3F; 6. MostraTipo t1 = new MostraTipo(); 7. System.out.println(a + " é um " + t1.tipo(a)); 8. System.out.println(b + " é um " + t1.tipo(b)); 9. System.out.println(c + " é um " + t1.tipo(c)); 10. } 11.}Sobrescrita ( Overriding )A sobrescrita só pode ser caracterizada quando temos uma estrutura hierárquica com herança.Também é resolvida em tempo de compilação. Ocorre quando escrevemos métodos geralmente 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() : floatObserve 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
  9. 9. 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 EstadoCapacidade 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
  10. 10. 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 ObjetosAtividades Relacionadas ao Projeto OO1. 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 <= dataAtual litrosAbastecer <= capacidadeTanque - litrosAtual • Robustez Diz respeito principalmente à capacidade do software de se recuperar de falhas (Tratamento de exceções) • Estensibilidade Ajuste doa solução ao problema. O principal recurso para se obter estensibilidade é a herança. Exemplo: Existia apenas a classe Clientes. Por necessidade do negócio estendemos a classe para ClientesNacionais e ClientesEstrangeiros sem modificar a classe Clientes, mas estendendo ambas dela. • Distribuitividade Possibilidade de classes poderem ser utilizadas em múltiplas plataformas e ambientes. Padronização de protocolos de troca de mensagens entre objetos etc. Utilizando os padrões criados para garantir Distribuitividade é possível até utilizar classes desenvolvidas em linguagens diferentes. (CORBA) • Armazenabilidade Ai moram os gerenciadores de Banco de dados orientados a objeto. (ODBMS). Esta característica que nos permite salvar objetos inteiros em bases de dados e depois, quando necessário, recuperá-los. Em bancos de dados OO não usamos o SQL como conhecemos, mas uma variação: OQL.4. Manutenção de Software Como todos que trabalham com software sabem, a manutenção de software é um poderoso dreno de recursos e paciência em todas a corporações. O esforço para minimizar e, 10
  11. 11. principalmente controlar seus custos é uma meta forte de qualquer corporação. O projeto OO fornece os recursos de reutilização, confiabilidade, robustez e estensibilidade como lastro para conseguir este objetivo.5. Utilização de Software Relaciona-se com a ergonometria e, na prática, está relacionado com a interface do software com o usuário. Atualmente os usuários esperam uma interface gráfica, o mais assemelhada possível com o que já lhe é familiar em outras aplicações (GUIs). O projeto OO se presta particularmente para este tipo de interface.6. Gerenciamento de projetos de software O uso correto de construções de projetos OO, demanda uma boa organização e documentação das bibliotecas de classes. O gerenciamento e todo este processo ganha uma enorme importância. O gerente não precisa necessariamente entrar em detalhes de código das classes desenvolvidas, mas, sem dúvida, deve conhecer suas características e estensibilidade. O uso de UML, por exemplo, é uma forte ferramenta de gerenciamento de projetos. Quando uma fábrica de software passa a adotar OO, o pessoal de desenvolvimento passa a se especializar em determinado grupo de classes que atendem a problemas específicos a ou negócios ou sub ramo de um negócio. A integração operacional e funcional de todas estas equipes pode ser muito facilitada com o gerenciamento utilizando as ferramentas UML desenvolvidas exatamente com esta finalidade.UML – Unified Modeling LanguageA 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
  12. 12. Metas UML 1. Prover aos usuários uma linguagem de modelagem visual expressiva e pronta para uso, de forma que eles possam desenvolver e intercambiar modelos significativos. 2. Prover mecanismos de estensibilidade e especificação para ampliar os conceitos centrais Os usuários precisam saber: 1. construir modelos que utilizam conceitos centrais sem utilizar mecanismos para extensão na maioria das aplicações normais 2. acrescentar novos conceitos e notações para temas não cobertos pelo núcleo 3. escolher entre interpretações variantes de conceitos existentes, quando não houver um claro consenso. 4. especificar os conceitos, as notações e as restrições, para domínios de aplicações particulares. 3. Ser independente de linguagem de programação e processos de desenvolvimento particulares. 4. Prover uma base formal para entendimento da linguagem de modelagem; 5. Estimular o crescimento do mercado de ferramentas OO 6. Suportar conceitos de desenvolvimento de nível mais alto, tais como colaborações, estruturas, modelos e componentes. 7. Integrar as melhores práticas. 12
  13. 13. 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 especializadosExemplo: Abertura de conta Abertura conta Abertura conta especial poupançaInclusã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: Saque <<include>>Cliente Banco Depósito Registrar <<include>> movimento 13
  14. 14. 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 Encerrar conta <<extend>> <<extend>> Banco Cliente Saque DepósitoVeja 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 iniciaisDocumento 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
  15. 15. da visão pode ser composta no formato que for mais conveniente para o pessoal envolvido.Recomendamos que a codificação de versão definida seja tal que os arquivos possam ficar 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ão0. 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 realizado2. Escopo Relacione os principais módulos. (serão detalhados mais tarde no item 8)3. Definições de acrônimos e abreviaturas Todos os termos da área de informática devem ser explicados aqui. É uma espécie de glossário. Mesmo assim, evite no restante do documento abuso de termos técnicos.4. Referências Relate a(s) fontes no qual o documento se baseou. Se existe uma ordem de serviço ou um contrato. Seu número, responsáveis etc. Se foi ordem verbal, relate as pessoas que “encomendaram” o projeto.5. Oportunidade de negócio Descreva a oportunidade de negócio. Qual a motivação para o projeto, o que se pretende ganhar, melhorar. Que problema está sendo solucionado.6. Descrição do pessoal envolvido. (Usuários, clientes, fornecedores,facilitadores etc). Nos itens 6.1 a 6.n descreva elemento por elemento. Cargo, nome completo, telefone, e-mail etc. Procure listar primeiro os clientes depois os usuários, tentando listar por ordem decrescente de importância estratégica do elemento para o projeto. 6.1 6.2 15
  16. 16. 6.3 Ambiente (de hardware e software) atual dos clientes. Se existirem diversos ambientes,indicar cada tipo de ambiente e o percentual em relação ao conjunto. 16
  17. 17. Exemplo: Vinte estações de trabalho. Cinco com Windows XP, 250Mb em rede com acesso web (25 %). Dez com Windows 98 com 128Mb em rede com acesso a web (50 %) Cinco com Windows 95 com 64Mb sem rede mais com acesso a web. (25 %)7. Observações. Acrescente qualquer observação que você ache pertinente e não encontrou local mais específico para lançar.8. Módulos Numere, nomeie e descreva as perspectivas de cada módulo do projeto. Procure descrever o que o módulo faz, para que serve e como se relacionará com outros módulos, se isso for importante. Cada módulo será um componente no diagrama de Caso de Uso. Tente listar os módulos na ordem que serão desenvolvidos (Não necessariamente na ordem de importância estratégica) 8.1 ... 8.2 ... ..... 8.n ...9. Precedência e prioridades. Indique a ordem de prioridade dos módulos (item 8) e se ela será a mesma ordem de precedência para desenvolvimento ou não. Explique os critérios que você usou para definir os critérios, principalmente se um módulo mais importante teve que ser desenvolvido depois de um menos importante. Descreva as razões técnicas para isso.10. Requisitos não funcionais Descreva aqui as dependências de softwares externos, particularidades de performance esperadas, necessidade de treinamento e outras que forem pertinentes.11. Requisitos de sistemas e ambientes. Necessidades de software e hardware para viabilizar a operacionalidade do sistema em questão. Defina aqui o sistema operacional, banco de dados, linguagem de programação, servidor de aplicação, servidor de Internet, softwares de segurança. As necessidades mínimas de hardware como memória, capacidade em disco, placa de rede, conexões de rede e Internet, velocidade nas conexões etc. Separe cada item (Sistema operacional, banco de dados etc em subitens separados) 11.1 Requisitos de software 11.1.1 Sistema operacional. 11.1.2 Browser 11.1.3 etc... 11.2 Requisitos de hardware 11.2.1 Memória mínimas 11.2.2 Espaço em HD 11.2.3 Placa de rede... etc 17
  18. 18. 18
  19. 19. 12. Insira uma figura com disposição dos módulos Diagrama dos módulos descritos no item oito e seus relacionamentos. As técnicas para preparação deste diagrama serão vistas mais adiante.13.Assinatura do Solicitante do Projeto (Cliente) 19
  20. 20. Diagrama de Caso de UsoO 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 AtorO 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 AlunoExemplos 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
  21. 21. O Caso de Uso• Um caso de uso é um padrão de comportamento que o sistema apresenta: Cada caso de uso é uma seqüência de transações relacionadas que normalmente são executadas através de um diálogo entre um ator e o sistema.• Os casos de uso capturam a funcionalidade do sistema na visão dos usuários (atores humanos)• Eles descrevem e validam o que o sistema irá fazer.• Os atores devem ser estudados para identificar suas necessidades e assim identificar os casos de uso relacionados a eles: - Funcionário: Cadastra Turmas - Professor: Lança Notas - Aluno: Efetua matrícula - Sistema financeiro: Valida Situação do AlunoIdentificando 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 do sistema?• Quais as entradas e saídas do sistema? De onde elas vem e para onde elas vão ?• Quais os maiores problemas com a implementação atual do sistema? 21
  22. 22. 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 Nome do Caso de UsoRelacionamentos 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 AtoresNormalmente 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: Solicita histórico Aluno SecretáriaO 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: Professor CoordenadorRelacionamento 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
  23. 23. 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: Emitir Histórico Escolar Registrar Novo Aluno Impressora SecretáriaQuando 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. Cadastrar Cadastrar Funcionário DependentePodemos 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. Cálculo do Salário Calcular Salário Família Incluir cenário principal: Cálculo do Salário Família << include >>Muitas vezes um caso de uso é uma particularização de um outro já documentado. Estendendo 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. Conta Corrente Conta Corrente Especial Estender cenário Conta Corrente especial de Conta Corrente << extend >> 23
  24. 24. Para exemplificarmos um diagrama de um sistema completo com seus casos de uso, atores erelacionamentos vamos examinar o projeto de uma locadora de DVDsEste seria o diagrama de nível zero referido no modelo de Visão Sistema de Locação de DVDs Via WEB Administrar Locar DVD Promoções Entregar Locação Administrar MultasCliente Site Devolução Administrar Controlar Marketing Estoques FornecedorNó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
  25. 25. Mais um exemplo de Caso de Uso de Nível Zero Sistema de Controle Acadêmico Cadastrar aluno Cadastrar professor Cadastrar curso Registrar matrícula SGBD Emitir confirmação Secretária Emitir diário de classes Registrar notas Emitir histórico escolar Impressora Emitir confirmaçãoO 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
  26. 26. Exemplo Completo do Sistema de Controle Acadêmico Cadastrar aluno <<include>> Incluir Aluno Excluir Aluno Alterar Aluno <<include>> Cadastrar Professor <<include>> <<include>> Alterar Professor Incluir Professor Login Excluir Professor <<include>> Cadastrar Curso Incluir Curso Excluir Curso Secretaria Alterar Curso <<include>> Registrar Matrícula SGBD <<include>> Registrar Nota Emitir Diário de Classe Emitir Confirmação de Matrícula Emitir Histórico Escolar ImpressoraNota: Todos os detalhes deste diagrama serão vistos a medida que nosso estudo avançar. 26
  27. 27. Documento NomenclaturaEste 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 Dados Prefixo Primitivos boolean b char, char [] c byte, byte[] by Short, short[] t int, int[] i long, long[] l float, float[] f double, double[] d void V 27
  28. 28. Tipos de classes e outros tipos Prefixo BigDecimal bd Collection col Exception Ex Date dt List lst RuntimeException rte String, String[] s Time tm Vector vt Button btn Checkbox chk Dialog dlg Label lbl TextBox txt Classe cls Pacote pct ListBox lstb ComboBox cmb Tabela (grid) tb RadioBox rdbNota: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
  29. 29. Convenções de nomeação para objetos de Banco de dados Prefixo para nome do objeto Prefixo Tabela t View v Trigger tg Stored Procedure sp Function fRegras para criar Nome da objetos de banco de dados: Prefixo + “_” + Mnemônico de 3 letras + NomeObjetoExemplos: tcli_clientes (Tabela de clientes) vpea_pedidosativos (Visão: Pedidos Ativos)Notas:• Não estamos utilizando letras maiúsculas nos nomes das tabelas devido ao fato de que alguns bancos de dados não operarem bem com tabelas e colunas grafadas com letras maiúsculas. (PostgreSQL, por exemplo)• O mnemônico do nome da tabela (3 letras) devem ser usados nas queries quando se usar aliasses. Exemplo: SELECT ped.ped_descricaos, cli.cli_nomes FROM tped_pedidos ped, tcli_clientes cli WHERE ped.fkcli_codigoi = cli.kcli_codigoi Identificação Prefixo Coluna comum Mnemônico de 3 letras da tabela + _’ Chave primária k + Mnemônico de 3 letras da tabela + _’ Chave estrangeira fk + Mnemônico de 3 letras da tabela origem + _’Exemplos: kped_codigoi (Chave primária: Código do pedido, inteiro) fkcli_codigoi (Chave estrangeira: Código do cliente, inteiro) fkfor_codigoi (Chave estrangeira: Código do fornecedor, inteiro) ped_quantidadei (Quantidade de itens no pedido, inteiro) 29
  30. 30. 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árioData última atualização: DD/MM/AASoftware: Sistema de DVDs pela InternetLocação Ato de alugar uma ou mais unidades de DVD.Usuário Locador Aquele que aluga um ou mais DVDsCliente Locador Mesmo que Usuário LocadorBeneficiário Aquele agregado por designação de um Cliente LocadorCliente Contratante Aquele que fez a requisição do sistemaLocatário Cliente ContratanteEquipamento de DVD Aparelho que permite a execução de discos de DVD.DVD Lançamento Aquele disco de DVD que apresenta data de lançamento do filme inferior a três meses 30
  31. 31. DVD Catálogo Aquele disco de DVD que apresenta data de lançamento do filme superior a três mesesMulta Valor pago por dia de atraso pelo locador ao locatário.Fidelidade Programa que visa estimular a fidelidade do Cliente Locador com descontos e prêmios.Casos de 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çãoO 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
  32. 32. Como um Caso de Uso deve ser escrito?Um caso de uso deve ser bastante detalhado. Seu detalhamento será usado por todas as outras 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
  33. 33. Como extrair um Caso de UsoProcure seguir o exemplo abaixo para suas entrevistas e a formatação final do caso de uso:1. Nome Referência: Verbo no infinitivo (Informar, comprar, pagar...) • O nome codificado (ID) do Caso de Uso será usado em alguns documentos e como referência como um trecho de código se referir a ele. Também pode ser usado como chave primária se for armazenado em um banco de dados. Exemplo: UC0086 - Cadastrar internautas e permitir alteração de senha e e-mail.2. Breve descritivo Do que se trata o caso de uso ? • Você pode considerar esta descrição como inserção de palavras chave para localização rápida em caso de pesquisas por palavra chave. Mesmo pensando em palavras chave, procure construir algumas frases com sentido para o leitor. Exemplo: Cadastrar o internauta no site e permitir alteração de senha e e-mail.3. Pré-condições: O que é necessário acontecer para dar início ao Caso de Uso ? Quais os pré requisitos ? • Qualquer ação ou reação de um subsistema ou ator que start o Caso de Uso.. Exemplo: O internauta visitar o site (home) e clicar no ícone de cadastro. Para que o cadastramento se efetive, o internauta deverá reconhecer e digitar um número de segurança além de ter 18 anos completos.4. Atores envolvidos • Procure listar os atores separados por vírgula para facilitar futuras buscas. O entrevistado deve sempre estar entre os atores envolvidos. Procure nomes simples. Evite nomes compostos como Secretaria Executiva, Diretor Geral etc. Prefira nomes curtos e o mais genérico possível como Aluno, Gerente, Secretária, Funcionário, Chefia, Coordenador, Professor, Operador etc. O nome deve ser usado sempre no corpo do documento. Não se preocupe em melhorar a elegância do texto usando sinônimos para o nome dos autores. Sempre que se referir a um ator use o seu nome grafado exatamente da forma descrita. Exemplo: Internauta, Site, SGBD. 33
  34. 34. 5. Cenário principal Qual a atividade básica e sem alternativas ou exceções? (Verbos no presente do indicativo ou substantivos, iniciando a frase com (Registra, Compra Seleciona, Informa...) • Descreva as tarefas. Cada cenário principal se refere a uma tarefa. Evite informações vagas. Faça (e obtenha as respostas) as três perguntas básicas: O que é? , Para que? ou Por que?, Como ? Lembre-se que o que for descrito aqui e seu nível de detalhes deve ser suficiente para que as classes sejam codificadas. Caso alguma informação fique pendente, marque com um número seqüencial entre colchetes. No ítem 12 (pendências) descreva cada uma delas. Exemplo: 1. Cadastramento: Ao clicar no ícone de cadastramento, o internauta é encaminhado para a tela de cadastro onde é solicitado que digite: Nome, Sobrenome, Nick Name, Data de nascimento (DD/MM/AA), sexo (implementado em radio button), CPF (sem formatação), endereço de e-mail, um login (usuário) e uma senha que será digitada em duplicata para validação. O internauta ainda deve copiar e digitar um número mostrado (obtido aleatoriamente [3] de uma base de figuras FIG_Figuras). Este procedimento visa evitar cadastro automático de internautas. Ao clicar no botão de confirmar, estando preenchidos todos os campos obrigatórios e também correto o número de segurança, o sistema salva o novo internauta no SGBD [2] envia um e-mail ao internauta confirmando o cadastro e retorna. 2. Troca de senha: Ao clicar no ícone de troca de senhas o internauta é encaminhado para a tela de login [1]. O internauta se loga com a senha atual (<<include>> UC0056). O sistema identifica o internauta e mostra a tela de troca de senha. Aguarda a digitação em duplicata da nova senha. Esta deverá possuir no mínimo 6 e no máximo 8 dígitos, sendo pelo menos um dígito alfanumérico. Será pedido também, opcionalmente, que o internauta digite uma “palavra secreta” para ajudá-lo a relembrar a senha no caso de esquecimento. No caso do internauta clicar em confirmar, o sistema consiste os dados e estando tudo OK a senha e a palavra secreta são criptografadas (algoritmo XPTO 766) e salvas na Base. 3. Alteração de e-mail: Ao clicar no ícone de troca de e-mail o internauta é encaminhado para a tela de login. O internauta se loga (<<include>> UC0056), no sistema identifica o internauta que é encaminhado para a tela de mudança de e-mail. O internauta se loga na tela e depois digita o novo e-mail. O sistema identifica, consiste os dados e envia confirmação para o novo e-mail. Nota importante: Apesar de em nosso exemplo mostrar-mos 3 cenários diferentes, não é muito comum um caso de uso com muitos cenários. O mais adequado seria considerar os cenários Troca de Senha e Alteração de E-mail como casos de uso diferentes. 34
  35. 35. 6. Cenário alternativo e de exceções Em que casos não acontece como descrito no Cenário Principal ? • Aqui devem ser tratadas as exceções e situações alternativas. Cada cenário deve ser tratado individualmente separando em sub-itens relacionados aos itens do Cenário Principal. Exemplos: 1.1. Nick Name está em branco: Sistema preenche como o primeiro nome do internauta. 1.2. Número de segurança diferente do mostrado. Desviar para UC0034. 1.3. Data de aniversário digitada é inválida. Mostra caixa de mensagem para reconhecimento com OK, limpa o campo, coloca o foco. 1.4 . Internauta tem mais de 100 anos (provável erro de digitação) ou menos que 18 (menor de idade). Mostra aviso que não é possível o cadastro e o motivo e sai. 1.5. Senha de confirmação não bate: Os campos são limpos e o internauta redigita ambas as senhas. 1.6. Qualquer dos campos em branco (que não o Nick Name): O Internauta digita o campo em branco. O foco será colocado no primeiro campo em branco. Os campos preenchidos serão mantidos para que o internauta não necessite redigitar. 1.7. Login selecionado já existe na base do sistema. Desvia para o caso de uso UC0032 1.8. Check-digit de CGC não bate. Limpar o campo, colocar o foco nele e pedir nova digitação. 1.9. Radio Button de sexo não está selecionado: É apresentada uma caixa de diálogo comunicando o fato. O internauta reconhece com OK e o foco será direcionado ao Radio Button de seleção de sexo. 2.1. Falha de login: Solicita novo login. (Não controla quantidade de tentativas) 2.2. Senha inválida. (Menos que 6 dígitos e/ou não existe dígito alfanumérico) Mostra alerta com as regras para criação de senha, limpa os campos e solicita nova digitação 2.3. Senhas duplicadas não batem: Mostra aviso, limpa os campos de senha e solicita nova digitação. 2.4. O internauta cancela. Nenhuma ação é realizada. O sistema volta para tela anterior. 3.1. Falha de login: Solicita novo login. 3.2. O e-mail é ilegal (Não tem dígito @, tem espaços, nada antes do @, nada depois do @). Mostra aviso e pede nova digitação. 3.3. O e-mail cadastrado na base já existe para outro internauta. Mostra aviso e finaliza. 35
  36. 36. 7. Requisitos especiais Existe alguma situação que não foi contemplada no cenário principal nem no alternativo ? • Aqui colocamos as observações que o entrevistado destacou como importante ou detalhe delicado. Alguma observação de segurança ou ponto de atenção especial. Exemplo: 1. O tempo para apresentar as telas de ser o mínimo. A demora em retornar para o internauta pode fazer com que desista de se cadastrar no site. 2. A informação de sexo deve ser um conjunto de dois Radio Buttons sem inicialização. (Ambos não selecionados) 2. As senhas digitadas não devem ser case sensitive 3. Caso o internauta erre mais que 3 vezes a senha, registrar este fato em arquivo de log e enviar um e-mail para o internauta comunicando este fato.8. Casos de uso Incluídos Liste aqui os casos de uso incluídos por este • Os casos de uso incluídos são os que em algum momento são usados integralmente durante a descrição do cenário principal ou alternativo. Seria o caso do login que, em alguns casos, pode ser evocado pelo caso de uso corrente. Não se preocupe de dar explicações ou justificativas. Apenas liste os casos de uso. (Veja: <<Include>>) Exemplo: UC0023 – Login do Internauta UC0034 – Trata Número de segurança UC0032 – Trata login existente9. Casos de uso Estendidos Liste aqui os casos de uso estendidos por este • Um caso de uso estendido normalmente detalha um sub processo. Um exemplo seria o caso de a partir do caso de uso cadastro do Internauta, definíssemos outros três: Um para inclusão, outro para alteração e mais um para exclusão. Como no caso de incluídos, não se preocupe em dar explicações ou justificativas. Apenas liste os casos de uso (Veja: <<Extend>>) 36
  37. 37. 10. Dados Tipos de dados que foram encontrados durante a descrição do caso de uso. Aqui informamos: texto (com tamanho), número (com precisão), moeda, data (com formato), etc. Objetos de classes de biblioteca também devem ser listados aqui. (Repare em Date, Combo box, Text box etc) Os componentes gráficos relevantes, isto é, que servirão para que os atores entrem ou recebam dados, também devem ser listados aqui. Importante: Para cada componente gráfico, crie pelo menos uma variável para receber seus dados. Exemplo: Descrição Nome Tipo Banco de Dados Código Usuário iUsuario String Varchar (20) Senha sSenha String Varchar (6) E-mail sEmail String Varchar (100) CGC sCgc String Varchar (11) Nome sNome String Varchar (25) txtNome Text Box - Sobrenome sSobrenome String Varchar (50) txtSobrenome Text Box Nick Name nNickName String Varchar (25) txtNickname Text Box - Data aniversário dtNascimento Date Datetime Sexo cSexo char Varchar (1) rbSexoMasc Radio Button - rbSexoFem Radio Button - Palavra secreta String Varchar (20) Nota: As células destacadas em cinza, servem para identificar grupos de símbolos relacionados entre si.11. Observações Suas observações caso seja necessário. Exemplo: Rever o caso de uso UC0023 – Login do Internauta O Sr. José ficou de enviar via e-mail até 12/04/05 o layout do arquivo de log de senhas. 37
  38. 38. 12. Pendências Existe alguma pendência ? • Liste aqui as pendências referenciadas na descrição do caso de uso. Numere no local do texto (entre colchetes) as pendências a medida que apareçam. É importante tentar estabelecer datas para solução. A medida que as pendências forem sendo resolvidas, o analista edita o texto definitivo no corpo do Caso de Uso (normalmente no cenário principal ou no cenário alternativo) retirando os toquens de sinalização de pendências. A versão do Caso de Uso deve ser salva sem eliminação da anterior, batizando o documento do Caso de Uso com nome no formato: UCnnnnnAAMMDD.doc (nnnnn = Número UC, AA = ano, MM = mes, DD = dia) Nota: Use o nome do arquivo acima no campo Versão do rodapé. Exemplo: 1. Layout da tela de login ainda em construção. Prazo para término: 04/04/05 2. Falta definir a tabela onde será armazenada a “palavra secreta” e a forma de utilização. Reunião marcada para definição em 10/04/05 3. Algoritmo de seleção randômica de figuras na base de dados será definida até 15/04/05 – Responsável: Sr André..13. Rodapé Analista responsável ________________________________________ Entrevistado: ________________________________________ Área: ________________________________________ Data: ________________________________________ Versão: ________________________________________ 38
  39. 39. Diagrama de ClassesA representações da classe NomeClasse Ou NomeClasseUsamos 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 inativasClasses 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: NomeClasseA representação de objetos nomeObjeto:NomeClasse Ou nomeObjeto:NomeClasseRepresentaçã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. 40. 40
  41. 41. Atributos (Propriedades)Como sabemos, os atributos são variáveis e/ou objetos que declaramos como instâncias da classe. Representamos os atributos no retângulo intermediário do diagrama (apenas da forma plena). Alémde representar o nome do atributo, representamos também seu tipo e visibilidade entre outras coisas. NomeClasse +nome: String -dataNascimento: Data #altura: inteiro /idade: inteiroO 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
  42. 42. Associações de ClassesNo 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 muitasExemplo: 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
  43. 43. 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 em que uma classe referencia a outra. As classes podem se referenciar mutuamente ou não. Não é muito comum mas podemos ter múltiplas associas entre classes. Exemplo: Produto e Fornecedor em uma classe de ItensPedido. 2. Composição: Temos uma composição quando o objeto de uma classe só existe enquanto os objetos “hóspedes” existam, isto é, as partes são essenciais para a existência do todo. Exemplo: Motor de um avião. Um avião não é um avião sem motor. (pode ser no máximo um planador). Uma cadeira não é uma cadeira sem os pés (Mas é uma cadeira sem os braços – Os braços não compoem a cadeira – são agregados). 3. Agregação: Temos uma agregação quando o objeto agregador pode continuar existindo mesmo que seus agregados deixem de existir. A variação no número de sócios de um clube, funcionários em uma empresa ou ovelhas em um rebanho não interfere na existência do objeto que os contém. Exemplo: Um clube (e seus sócios), um colégio (e seus alunos) , um departamento de uma empresa (e seus funcionários). 4. Herança: Na herança, perguntamos se a classe candidata a ser uma subclasse é um “caso particular” da provável superclasse. Se a provável superclasse possui atributos que com certeza a subclasse irá compartilhar. Exemplo: Mamífero é superclasse de Primata Primata é superclasse de Ser HumanoAgregaçãoComo 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 uma empresa, mas o departamento ainda continuará existindo... Não poderíamos dizer isso da floresta.. ai o exemplo da floresta não se aplica... E um rebanho de ovelhas sem ovelhas ?• Um objeto pode ser constituinte de mais de um agregado. É o caso de um cidadão poder ser sócio de mais de um clube... Mas não seria o caso de uma ovelha pertencer a mais de um rebanho...• As agregações tendem a ser homogêneas. Isso quer dizer que os constituintes de um agregado típico são todos de uma mesma classe. (Árvores, ovelhas, casas, cidadãos, ítens de pedido) 43
  44. 44. Vamos agora ao diagrama de uma associação: RelatororioDeGerencia ◊ 0..* {ordenado} parteDoTexto 0..* Parágrafo • Usamos um pequeno losango vazio (diamante) na extremidade da linha de associação do agregado próximo ao agregado. • As classes do agregado (Relatório gerência e do constituinte (Parágrafo), aparecem nas respectivas extremidades da linha de associação. O papel do objeto constituinte parteDoTexto também aparece na extremidade do constituinte da linha de associação. • Com a agregação, devemos mostrar a multiplicidade em ambas as extremidades da linha de associação porque não é possível assumir a multiplicidade em todos os lugares. Veja que um parágrafo pode pertencer a muitos relatórios de gerência ao mesmo tempo ou pode pertencer a um relatório ou a nenhum. A multiplicidade na extremidade do constituinte também é 0..*. Isso significa que um relatório pode compreender muitos parágrafos, ou um parágrafo ou nenhum ( relatório vazio ) Exemplo Pedido Itens Pedido 1.. * -nroPedido : long -datPedido : date -qtdItem : double -datEntPedido:date -valUniItem : double 1.. * Compõe Produto -desPro : String -qtdPro : double -valPro : doubleNeste 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
  45. 45. ComposiçãoConstitui-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 e monitor não é um computador. Assim, o tempo de vida de um de seus componentes não pode ultrapassar o tempo de vida dos seus componentes.2. À parte de um objeto composto não poderá pertencer a mais de um objeto composto.3. A composição é sempre tipicamente heterogênea. Uma composição de muitos objetos idênticos seria o caso de um array (ou vetor) de objetos. Isso quer dizer que as partes normalmente não são do mesmo tipo. Planador 1 1 1 fuselagem cauda 1 asaEesquerda asaDireita Fuselagem Cauda AsaVamos dissecar esta figura para ver como o UML funciona.• Cada associação aparece no diagrama como uma linha de associação, com um losango (diamante) encostado no lado do objeto composto.• A classe do objeto composto, Planador, aparece em uma extremidade da linha de associação. A classe de cada componente – Fuselagem, Cauda e Asa. Note que asa é uma classe composta por dois objetos: asaDireita e asaEsquerda.• O papel do objeto componente na composição aparece na extremidade do componente na linha de associação. Os papéis asaEsquerda e asaDireita são objetos da classe Asa. Cada um 45
  46. 46. desempenhando um papel diferente em um planador.• Você pode (e deve) exibir multiplicidade na extremidade do componente de cada linha de associação. Caso a multiplicidade seja omitida, assume-se como 1.• As linhas de associação não tem qualquer nome... o que corresponde a uma norma tanto para composição quanto para agregação.• Notem que as partes: Fuselagem + Cauda + Asa(s), compõem 100% do planador.Veja que a classe poderia ter os seguintes atributos declarados dentro dela: Planador -fuselagem: Fuselagem -cauda: Cauda; -asaEsquerda:Asa; -asaDireita:Asa; ...Exemplo de composiçãoObservando-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Àho1

×