0110037apostilauml-120421121749-phpapp01.pdf

7/27/2019 0110037apostilauml-120421121749-phpapp01.pdf

1/64

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

Classe...............................................................................................................................................3Objeto...............................................................................................................................................3Generalizao...................................................................................................................................4

Herana........................................................................................................................................4Sobrecarga ( Overloading )......................................................................................................... 4

Assinaturas idnticas.............................................................................................................. 4Assinaturas diferentes.............................................................................................................4

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

Ocultao de informaes e Implementaes..................................................................................7Reteno de Estado..........................................................................................................................7Identidade de um Objeto..................................................................................................................8

O Projeto Orientado a Objetos..............................................................................................................8

Atividades Relacionadas ao Projeto OO..........................................................................................8UML Unified Modeling Language............................................................................................... 9Metas UML....................................................................................................................................10Especializao / Generalizao......................................................................................................11Incluso..........................................................................................................................................11Extenso.........................................................................................................................................12Documentos iniciais.......................................................................................................................12Modelo de um documento Viso................................................................................................... 13Diagrama de Caso de Uso..............................................................................................................16

O Ator .......................................................................................................................................16Consideraes sobre Atores...................................................................................................... 16

Como 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 Nvel Zero......................................................................... 21Exemplo Completo do Sistema de Controle Acadmico...............................................................22Documento Nomenclatura............................................................................................................. 23

Modelo (sugesto) para nomenclatura:..................................................................................... 23Convenes de nomeao para objetos de Banco de dados......................................................25O Documento Glossrio.................................................................................................................26Casos de Uso..................................................................................................................................27

Como um Caso de Uso deve ser escrito?..................................................................................28Quem deve fazer a extrao de casos de Uso ?.........................................................................28Como extrair um Caso de Uso.................................................................................................. 29

Diagrama de Classes ..................................................................................................................... 35A representaes da classe........................................................................................................ 35Classes ativas e inativas............................................................................................................ 35A representao de objetos........................................................................................................35

Atributos (Propriedades)........................................................................................................... 36Operaes (mtodos).................................................................................................................36Associaes de Classes............................................................................................................. 37

1


2/64

Agregao.............................................................................................................................38Composio..........................................................................................................................40Herana.................................................................................................................................42Esteretipos do Diagrama de Classes...................................................................................43Algumas regras para definio de classes para casos de uso................................................45Levantando Classes a Partir do Caso de Uso....................................................................... 46

Gerando Classes de Outro Caso de Uso....................................................................................47

Diagrama de Caso de Usos De Sistema Seguradora...........................................................................48O Diagrama de Classes do Diagrama de Casos de Uso.....................................................................49O Diagrama de Seqncia.................................................................................................................. 50

Componentes do Diagrama de Seqncia......................................................................................50Atores........................................................................................................................................ 50Objetos...................................................................................................................................... 51Linha da Vida............................................................................................................................51Foco de Controle ou Ativao...................................................................................................51Mensagens ou Estmulos...........................................................................................................52

Tipos de Mensagem..............................................................................................................52Imperativas........................................................................................................................... 52

Auto chamadas (ou Auto delegaes).................................................................................. 52Condies de Guarda (Operadores de Interao)................................................................. 53Diagrama de Seqncia para Abertura de uma Conta Comum............................................53

Bibliografia.........................................................................................................................................55

2


3/64

Conceitos Iniciais

O mundo orientado a objeto repleto de conceitos e termos novos e que devem ser de claroentendimento para que seja possvel pensar orientado a objeto. Na realidade no difcil, o grandeimpacto causado pela diferena de como vnhamos pensado nos projetos convencionais. O

pensamento OO, na realidade, at mais intuitivo. Afinal, nosso mundo constitudo por objetos...Somos preparados pela evoluo a lidar com eles. Ns 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 to facilmente.

Vamos ver brevemente o que significa cada termo usado no mundo Orientao a Objeto:

Classe

um modelo a partir do qual so criados (gerados) objetos. Cada objeto tem a mesma estrutura ecomportamento da classe da qual ele pertence. Se o objeto pertence classe, dizemos que ele umainstncia da classe.

As classes so elementos fundamentais na composio de softwares orientados a objetos. Elas soempregadas tanto na composio do projeto dos sistemas computacionais quanto em suaimplementao. Entretanto, ao contrrio dos objetos, as classes no se traduzem em elementosexecutores no cdigo de implementao.

Exemplo de Classe: O ExcelExemplo de Objetos: Suas planilhas

Uma classe precisa definir os atributos e os procedimentos dos futuros objetos que sero criados apartir dela. A definio da classe tambem permite estabelecer regras claras de visibilidade de seuscomponentes (atributos e procedimentos). A definio dos atributos, procedimentos e o controle da

visibilidade se resume, na verdade, a definio da classe.

Em eletrnica, classes podem ser comparadas com C I's. Eles so projetados para se encaixaremem diversos tipos de projetos, com inmeras aplicaes. Os C I's possuem uma coleo defuncionalidades (procedimentos) e precisam ser configurados (atributos) . Pensando em Java, osatributos so as variveis e os procedimentos so os mtodos.

Exemplo: Uma classe simples em Java:

public class Circulo {private double raio; // Atributo 1private double perimetro; // Atributo 2private double area; // Atributo 3public 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/64

}

4


5/64

Objeto

um representante material projetado com base em uma classe. Contrastando com as classes quenormalmente no existem como indivduos, os objetos so a populao que realmente sofre e causaefeitos.

Para reforar, no existe nenhum indivduo Aluno. O que existe so indivduos definidos conformereza a classe Aluno e que so objetos independentes entre si: Joazinho, Mariazinha, Pedrino etc.Todos os indivduos que so da classe Aluno tero propriedades como notas mensais, nome,endereo, dados dos pais etc. Tero que se submeter a procedimentos como avaliao bimestral,semestral, anlise de aprovao etc.

Os objetos so conhecidos tambm com instncias. 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 crculo: ,ci.getArea());

System.out.println (Area do segundo crculo: ,ci.getArea());

}}

Herana

o relacionamento (associao) entre uma classe e uma ou mais verses refinadas dessa classe, tambm a abstrao que permite partilhar semelhanas entre as vrias classes, mantendo as suasdiferenas.

Quando estamos caminhando para o mais alto nvel na estrutura hierrquica estamos generalizando.

Comum no comeo da fase de anlise.Procurar atributos e mtodos parecidos.Definem superclasses.Podemos definir mtodos obrigatrios.

Exemplo:

Um crculo trigonomtrico um caso particular de crculo. Um crculo trigonomtrico um crculode raio constante e igual a um. Possui rea e permetro e mais uma srie de outras propriedades emtodos. A idia aproveitar o que j foi feito para o crculo genrico e escrever apenas as

peculiaridades do crculo trigonomtrico.

Em Java, tratamos a classe da qual estendemos (Circulo) como superclasse e a classe estendida(Circulo trigonomtrico) como superclasse.

5


6/64

Exemplo:

public class CirculoTrigonometrico extends Circulo {private double arco;public CirculoTrigonometrico (double arco) {super(1); // Passando para a super classe o raio = 1this.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 mtodo em uma mesma classe (ou em alguma superclasse) com omesmo nome, mas com assinaturas diferentes. Desta forma, o compilador decide (portanto emtempo de compilao) qual dos mtodos sobrecarregados usar tomando como base a quantidadee/ou tipos dos argumentos.

A assinatura de um mtodo conhecida pela lista de argumentos no que concerne a sua quantidadetipo e ordem.

Exemplos:

Assinaturas idnticas

double calculaSalario (float valorHora, int quantidadeHoras);float calculaSalario (float var, int quant);

No exemplo acima, ambos os mtodos possuem a mesma quantidade e tipo de argumentos.Por este motivo, ambos os mtodos possuem a mesma assinatura. Note que o tipo do

retorno no considerado como fazendo parte da assinatura.

6


7/64

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 so os mesmos mas esto emordem diferente.

No terceiro exemplo, o mtodo possui um argumento a mais.

Exemplo (em UML e Java) de uma classe com sobrecaga de mtodos:

A classe abaixo, implementa uma srie de mtodos utilitrios para retornar o tipo dasvariveis primitivas passadas como argumento.

MostraTipo

+tipo (char a) : String

+tipo (int a) : String+tipo (long a) : String

+tipo (double a) : String

+tipo (float a) : String

+tipo (byte a) : String

A Classe em Java:

1.public class MostraTipo {

2.3. public String tipo (char a) {4. return "char";5. }6. public String tipo (int a) {7. return "int";8. }9. public String tipo (long a) {10. return "long";11. }12. public String tipo (double a) {

13. return "double";14. }15. public String tipo (float a) {16. return "float";17. }18. public String tipo (byte a) {19. return "byte";20. }21.}

7


8/64

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 hierrquica com herana.Tambm resolvida em tempo de compilao. Ocorre quando escrevemos mtodos geralmente demesma assinatura em nveis hierrquicos diferentes. O Compilador procura na classe atual aexistncia do mtodo invocado. Se encontrar usa, caso contrrio subir na hierarquia procurando ummtodo 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 mtodo na superclasse Quadrilatero chamado getDiagonal e outromtodo na subclasse Quadrado tambm chamado getDiagonal. Ambos de mesma assinatura. Omtodo getDiagonalda classe Quadrado est sobrescrito sobre o mtodo getDiagonaldasuperclasse Quadrilatero.

8


9/64

Nota sobre Sobrescrita e Sobrecarga:

Em Java, por ser uma linguagem praticamente interpretada, o tempo de compilao se confundecom o de execuo. Neste caso, a JVM precisa definir o mtodo a ser sobrecarrego ou sobrescritona hora.Associaes (relacionamentos)

Polimorfismo

a habilidade pela qual uma nica operao ou nome de atributo pode ser definido em mais de umaclasse e assumir implementaes diferentes em cada uma destas classes.

a propriedade por meio do qual um atributo ou varivel 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 execuo Dynamic binding), com o uso de uma refernciagenrica... Contudo existem duas formas de acesso polimrfico que no utilizam exatamente umareferncia genrica nem so resolvidas em tempo de execuo, mas selecionam um mtodo (maisadequado) em tempo de compilao.

Generalizao/Especializao

a construo de uma classe C de forma que uma ou mais das classes que ela utiliza internamente fornecida somente em tempo de execuo (no momento em que um objeto da classe C instanciado).

A generalizao consiste, portanto, no projeto de classes para que funcionem como superclasses que

possam ser utilizadas para estender outras classes mais especializadas.

Encapsulamento

o grupamento de idias afins em uma unidade, conceito esse que pode ento ser informado emuma s palavra. A construo de funes, procedures, performs etc, so exemplos deencapsulamento em outros paradigmas Em OO chegamos a um nvel muito mais sofisticado deencapsulamento.

Ocultao de informaes e Implementaes

a utilizao de encapsulamento para restringir a visibilidade externa de certos detalhes deinformaes ou implementaes, os quais so internos estrutura de encapsulamento.

Reteno de Estado

Capacidade de um objeto reter seu estado. Isto , quando existe um objeto criado (residente namemria, instanciado), este objeto mantm suas propriedades inalteradas at que alguma ao(mensagem) realize algum tipo de alterao. Podemos invocar mtodos do objeto quantas vezesforem necessrias que o objeto continuar existindo entre as chamadas. Veja que na programao

estruturada tradicional, quando chamamos uma funo, esta ganhar a CPU e a memria necessriapara realizar suas funcionalidades. Ao seu trmino seus dados (variveis automticas) serodescarregados da memria e funo no mais existir como entidade. O nico vestgio de sua

9


10/64

existncia 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. Anlise dos requisitos de usurios2. Desenho do software3. Construo do software

Reutilizao Confiabilidade Invariantes de classe. uma condio que todo objeto da classe deve satisfazer.

Exemplos:dataNascimento


11/64

principalmente controlar seus custos uma meta forte de qualquer corporao.

O projeto OO fornece os recursos de reutilizao, confiabilidade, robustez e estensibilidadecomo lastro para conseguir este objetivo.

5. Utilizao de Software

Relaciona-se com a ergonometria e, na prtica, est relacionado com a interface do softwarecom o usurio. Atualmente os usurios esperam uma interface grfica, o mais assemelhadapossvel com o que j lhe familiar em outras aplicaes (GUIs). O projeto OO se prestaparticularmente para este tipo de interface.

6. Gerenciamento de projetos de software

O uso correto de construes de projetos OO, demanda uma boa organizao e documentaodas bibliotecas de classes. O gerenciamento e todo este processo ganha uma enormeimportncia. O gerente no precisa necessariamente entrar em detalhes de cdigo das classesdesenvolvidas, mas, sem dvida, deve conhecer suas caractersticas e estensibilidade.

O uso de UML, por exemplo, uma forte ferramenta de gerenciamento de projetos. Quandouma fbrica de software passa a adotar OO, o pessoal de desenvolvimento passa a seespecializar em determinado grupo de classes que atendem a problemas especficos a ounegcios ou sub ramo de um negcio. A integrao 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 anlise estruturada de sistemas para escrever seus projetos.As ferramentas de anlise existentes (Os CASES da vida) no estavam preparadas para a novaarquitetura e no correspondiam as necessidades dos projetistas. Muitos cientistas da OOdesenvolveram algumas propostas de modelagem, mas, por um ou outro motivo, no se tornaramsuficientemente populares para que fossem consideradas como padres.

Mesmo assim, UML no um padro 100% final. Existem dezenas de variaes, pequenas verdade, mas suficientes para causar alguma frustrao em quem estuda UML em muitas fontes.

Mesmo assim raramente as diferenas podero trazer alguma diferena que venha a provocar umam interpretao do desenho. O que se recomenda que a empresa que estiver adotando UML deveescolher uma das variaes que parecer mais simptica ou se ajustar melhor a linguagem usadanas aplicaes.

Ns projetistas de software, quando mergulhamos no estudo da UML, inicialmente ficamosincrdulos com a possibilidade de uma simples coleo de abstraes e diagramas possa representarcom fidelidade projetos complexos de sistemas. medida que nos aprofundamos a idia vai ficandocada vez mais factvel...

UML foi escrito e proposto no final da dcada de 90 pelo trio Grady Booch, Ivar Jacobson e Jin

Rumbaugh. E hoje um padro adotado pelo OMG, Object-Management Group.

11


12/64

Metas UML

1. Prover aos usurios 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 especificao para ampliar os conceitos centrais

Os usurios precisam saber:

1. construir modelos que utilizam conceitos centrais sem utilizar mecanismos paraextenso na maioria das aplicaes normais2. acrescentar novos conceitos e notaes para temas no cobertos pelo ncleo3. escolher entre interpretaes variantes de conceitos existentes, quando no houverum claro consenso.4. especificar os conceitos, as notaes e as restries, para domnios de aplicaes

particulares.

3. Ser independente de linguagem de programao 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 nvel mais alto, tais como colaboraes,

estruturas, modelos e componentes.7. Integrar as melhores prticas.

12


13/64

Especializao / Generalizao

O relacionamento de Especializao/Generalizao uma forma de Associao entre casos de usona qual existe dois ou mais casos de uso com muitas caractersticas semelhantes, apresentandocontudo algumas diferenas importantes entre si. Quando tal situao ocorre, costumamos definirum Caso de Uso Geral que descreve as caractersticas comuns a todos os casos de uso envolvidos.Depois descrevemos os demais casos de uso destacando apenas as diferenas ao Caso de UsoGeral.

Desta forma no necessrio colocar a mesma documentao para todos os Casos de Usoenvolvidos porque toda a estrutura de um caso de uso generalizado herdada pelos casos de usoespecializados. Alm disso, os casos de uso especializados herdam tambm quaisquer possveisAssociaes de incluso ou extenso que o Caso de uso Geral venha a possuir, bem como quaisquerAssociaes com os Atores que utilizem o caso de uso geral. A Associao deGeneralizao/Especializao representada por uma seta que une o Caso de Uso Geral (para ondea seta aponta) Aos casos de uso especializados

Exemplo:

Incluso

A Associao de incluso costuma ser utilizada quando existe um servio, situao ou rotinacomum a mais de um Caso de Uso. Quando isso ocorre, a documentao desta rotina colocada emcaso de uso especfico para que outros casos de uso simplesmente os inclua.

Exemplo:

13

Abertura contaespecial

Abertura contapoupana

Abertura deconta

Depsito

Cliente

Saque

Registrarmovimento

Banco


14/64

Como vimos na figura acima, tanto Saque quanto Depsito so casos de uso que devem serregistrados como movimento. Fica claro que o caso de uso Registrar Movimento ser includo noscasos de uso de Depsito e Saque. A associao de incluso evitar a repetio da documentao deRegistrar Movimento dentro de cada um. Veja que o caso de uso Registrar Movimento serexecutado necessariamente toda vez que um Saque ou Depsito seja realizado.

A expresso entre sinais de > so conhecidos como esteretipos e servem para descreverclaramente o tipo de associao.

Extenso

Associaes de Extenso so utilizadas para descrever cenrios opcionais de um caso de uso. Oscasos de uso estendidos descrevem cenrios que somente ocorrero em situaes especficas.

Os casos de uso estendidos dependem de uma condio no caso de uso base para que seja possveldeterminar qual dos casos de uso estendidos sero executados.

Exemplo

Veja que para que seja possvel encerrar uma conta corrente temos que zerar o saldo do cliente.

Poder ser necessrio realizar um depsito, 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 osesteretipos sobre as linhas de associao.

Documentos iniciais

Documento Viso

um relato resumido com os principais tpicos a que o negcio a ser automatizado deve fornecer.

Normalmente faz parte do contrato (ou ordem de servio) de desenvolvimento. comum que estedocumento aborde aspectos de tecnologia (linguagem banco etc). Deve ser resumido e de linguagemacessvel para leitura de pessoal de nvel gerencial, no necessariamente tcnico.

O analista poder, a seu critrio, detalhar mais ou menos cada item de acordo com a sua importnciaestratgica 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 Viso. Asverses das vises devem ser salvas com o prefixo V seguido do nmero da verso. A identificao

14

Encerrar conta

Saque Depsito

ClienteBanco


15/64

da viso pode ser composta no formato que for mais conveniente para o pessoal envolvido.Recomendamos que a codificao de verso definida seja tal que os arquivos possam ficar emordem quando listados no Explorer. Sugerimos o uso de composio de mnemnico do projeto, V,(data corrente no formato AAMMDD e nmero seqencial da verso). Mas importante que sejacolocada disposio de todos os envolvidos sempre a verso mais atualizada e tambm as antigas

para que as pessoas possam tomar conhecimento de eventuais mudanas e fazer comparaes.Apesar de todos este cuidados, a viso no deve sofrer grandes modificaes. Quando o projeto

entrar na fase de codificao, mudanas na viso podem ser desastrosas.Se for possvel disponibilizar o acesso s vises em uma intranet isso deve ser feito.

Modelo de um documento Viso

0. Cabealho

V05120501 (Verso da viso)

Nome do sistemaData

Requisitante(s):

Analista responsvel:

1. Introduo

Descrio geral do trabalho realizado

2. EscopoRelacione os principais mdulos. (sero detalhados mais tarde no item 8)

3. Definies de acrnimos e abreviaturas

Todos os termos da rea de informtica devem ser explicados aqui. uma espcie deglossrio. Mesmo assim, evite no restante do documento abuso de termos tcnicos.

4. Referncias

Relate a(s) fontes no qual o documento se baseou. Se existe uma ordem de servio ou umcontrato. Seu nmero, responsveis etc. Se foi ordem verbal, relate as pessoas queencomendaram o projeto.

5. Oportunidade de negcio

Descreva a oportunidade de negcio. Qual a motivao para o projeto, o que se pretendeganhar, melhorar. Que problema est sendo solucionado.

6. Descrio do pessoal envolvido. (Usurios, 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 usurios, tentando listar por ordemdecrescente de importncia estratgica do elemento para o projeto.

6.16.2

15


16/64


17/64

Exemplo:

Vinte estaes 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. Observaes.Acrescente qualquer observao que voc ache pertinente e no encontrou local maisespecfico para lanar.

8. Mdulos

Numere, nomeie e descreva as perspectivas de cada mdulo do projeto. Procure descrever oque o mdulo faz, para que serve e como se relacionar com outros mdulos, se isso forimportante. Cada mdulo ser um componente no diagrama de Caso de Uso.

Tente listar os mdulos na ordem que sero desenvolvidos (No necessariamente naordem de importncia estratgica)

8.1 ...

8.2 ...

.....

8.n ...

9. Precedncia e prioridades.

Indique a ordem de prioridade dos mdulos (item 8) e se ela ser a mesma ordem deprecedncia para desenvolvimento ou no. Explique os critrios que voc usou para definiros critrios, principalmente se um mdulo mais importante teve que ser desenvolvido depois

de um menos importante. Descreva as razes tcnicas para isso.10. Requisitos no funcionais

Descreva aqui as dependncias 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 emquesto. Defina aqui o sistema operacional, banco de dados, linguagem de programao,servidor de aplicao, servidor de Internet, softwares de segurana. As necessidades mnimasde hardware como memria, capacidade em disco, placa de rede, conexes de rede e

Internet, velocidade nas conexes 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 Memria mnimas

11.2.2 Espao em HD

11.2.3 Placa de rede... etc

17


18/64

18


19/64

12. Insira uma figura com disposio dos mdulos

Diagrama dos mdulos descritos no item oito e seus relacionamentos.

As tcnicas para preparao deste diagrama sero vistas mais adiante.

13.Assinatura do Solicitante do Projeto (Cliente)

19


20/64

Diagrama de Caso de Uso

O modelo de caso de uso um instrumento eficiente para determinao e documentao dosservios a serem desempenhados pelo sistema. tambm um bom meio de comunicao comclientes e demais envolvidos que no sejam da rea de informtica.

Para iniciarmos a confeco de qualquer diagrama de UML, necessrio conheceremos a suanotao, ou seja, a forma como devemos represent-lo e suas semnticas.

O Ator

O Ator pode ser uma pessoa, um sistema ou mesmo uma Entidade Externa (um banco, umainstituio 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 retngulo com o nome do autor abaixo do esteretipo :

Aluno

Exemplos de Atores:

Pessoas: Usurio, secretria, aluno, professor, administrador etc.

Dispositivos: impressoras, mquina ou equipamentos etc.

Hardwares: Modens, roteadores, placas de controle etc.

Softwares: SGBDs, Aplicativos de controle de processo etc.

Consideraes sobre Atores

importante observar que atores representam, na verdade, papis desempenhados quando estivereminteragindo com o sistema. O ator no representa um elemento particular, mas qualquer um queesteja realizando aquele papel naquele momento. Em um sistema em que o ator seja ,

por exemplo, tratar como qualquer pessoa que seja ou represente o aluno. Assim oresponsvel ou um representante legal ser considerado aluno em um sistema que defina como autor.

Na fase de projeto, um ator uma classe no um objeto. Isso significa que o ator deve representarum grupo (uma classe) e no um indivduo (um objeto). O ator o Encarregado, no o Sr. Joo.

O ator interage com o sistema sempre atravs de mensagens. (Lembrando: Mensagens so atributose/ou retorno de mtodos)

Como identificar os Atores ?

Quem utilizar a funcionalidade principal do sistema ? Quem Precisar de suporte do sistema para fazer suas tarefas dirias ? 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


21/64


22/64


23/64

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

Exemplo:

Quando a relao entre os casos de uso de dependncia, 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 funcionrio. O sentido da seta do dependente para ofuncionrio.

Podemos especificar incluso de um caso de uso (ou parte) em outro caso de uso. Isso quer dizerque o caso de uso Calcular Salrio utilizar integralmente a forma de clculo de Clculo doSalrio Famlia . Desta forma evitamos refazer (reeditar) o caso de uso que foi includo.

Muitas vezes um caso de uso uma particularizao de um outro j documentado. Estendendo o

caso de uso existente para um novo, editamos apenas o que for acrescentado. Este exemplo servlido apenas se consideramos que o correntista necessite inicialmente abrir uma conta comum paradepois convert-la para conta corrente especial.

23

ImpressoraSecretria

Emitir Histrico Escolar

Registrar Novo Aluno

CadastrarFuncionrio

CadastrarDependente

Calcular SalrioClculo do Salrio

Famlia

Incluir cenrio principal: Clculo do Salrio Famlia>

Conta CorrenteConta Corrente

Especial

Estender cenrio Conta Corrente especial de Conta Corrente>


24/64

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 nvel zero referido no modelo de Viso

Ns j vimos que UML prev a possibilidade de ligao entre atores. Contudo, consideramos quese no existir um caso de uso entre eles, no ser possvel desenvolver cdigo para esta ligao,muitas vezes a ligao entre atores acaba ganhando um Caso de Uso. Por exemplo, se o fornecedor

necessitar conhecer o estoque atual de filmes na locadora poderia interagir com o site diretamente(que em nosso exemplo um ator). Fica clara a necessidade de um caso de uso para viabilizar oacesso do fornecedor ao site com esta finalidade.

Mesmo que realmente no exista um caso de uso codificvel entre os atores, normalmenterepresentamos estes relacionamentos quando precisamos representar comunicaes importantes parao entendimento do negcio.

O diagrama de Casos de Uso no tem reflexo direto em codificao. Ele um instrumento devisualizao da complexidade a abstrao da complexidade. Contudo, ao ser analisado e aprovadoo diagrama de nvel zero e a viso como um todo, estamos prontos para a anlise propriamente dita.Esta fase se inicia na confeco do documento Nomenclatura.

24

Locar DVD

EntregarLocao

AdministrarPromoes

AdministrarMultas

Devoluo

ControlarEstoques

AdministrarMarketing

Sistema de Locao de DVDs Via WEB

Cliente Site

Fornecedor


25/64

Mais um exemplo de Caso de Uso de Nvel Zero

O Diagrama de Estudo de Caso de Nvel Zero, se preocupa com os grandes casos de uso. Estescasos de uso, no detalhamento, podero 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 nvel zero foi suprimido. O que se faz definir e representar os sub casos de uso(incluso, excluso e alterao 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 ligao com outros caso de uso.

Normalmente os diagramas de nvel zero mostram apenas os casos de uso diretamente ligados aatores.

O limite do sistema (fronteira) no foi desenhado apenas para diminuir a poluio do desenho.

25

Cadastrar aluno

Cadastrar professor

Cadastrar curso

Registrar matrcula

Emitir confirmao

Emitir dirio de classes

Registrar notas

Emitir histrico escolar

Emitir confirmao

Secretria

Impressora

SGBD

Sistema de Controle Acadmico


26/64

Exemplo Completo do Sistema de Controle Acadmico

Nota: Todos os detalhes deste diagrama sero vistos a medida que nosso estudo avanar.

26

Cadastrar aluno

Incluir Aluno Alterar AlunoExcluir Aluno

Cadastrar Professor

Incluir ProfessorAlterar Professor

Excluir Professor

Cadastrar Curso

Incluir Curso Alterar CursoExcluir Curso

Registrar Matrcula

Registrar Nota

Emitir Dirio de Classe

Emitir Confirmao deMatrcula

Emitir Histrico Escolar

Impressora

Secretaria

SGBD

Login


27/64

Documento Nomenclatura

Este documento usado para criarmos um padro de prefixos e sufixos para todas as palavrasenvolvidas em estrutura de cdigo. Nomeao de classes, objetos, variveis, tabelas, colunas,chaves etc. Neste documento tambm criamos padres para visibilidade de variveis, classes emtodos e tambm tipos de variveis locais e atributos .

Em Java no existe variveis globais. Isso facilita a documentao e melhora a segurana do cdigo.

Este documento normalmente consiste de tabelas onde listamos os tipos e os prefixos e/ou sufixosque sero usados. bom lembrar que Java sensvel ao caso de maisculas.

Naturalmente este documento s pode ser elaborado se a linguagem utilizada j estiver definida.

Modelo (sugesto) 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


28/64

Tipos de classes e outros tipos Prefixo

BigDecimal bd

Collection col

Exception Ex

Date dt

List lst

RuntimeException rte

String, String[] s

Time tm

Vector vt

Button btn

Checkbox chk

Dialog dlg

Label lbl

TextBox txt

Classe cls

Pacote pct

ListBox lstb

ComboBox cmb

Tabela (grid) tb

RadioBox rdb

Nota:

Contadores de loop esto dispensadas de prefixo. Usar necessariamente i para contador. Se foremnecessrias mais variveis de controle usar a seqncia i, j, k, l, m, n etc.

No caso de prefixos e sufixos para tabelas e colunas existem muitas variaes de padronizao. Dequalquer forma se recomenda que no nome da coluna exista identificao da tabela a que pertence,se chave primria ou estrangeira. recomendvel que, com o uso de sufixos, identificar o tipo decada coluna. Naturalmente, caso seja feita alguma modificao do tipo da coluna durante a fase de

codificao, toda a documentao (e cdigo) dever ser revista e, se for o caso, renomeada. Estaaparente desvantagem no final se mostra muito prtico, pois ser mais fcil identificar os possveisimpactos relacionados com a modificao e, desta forma, fazer as correes necessrias.

28


29/64

Convenes de nomeao para objetos de Banco de dados

Prefixo para nome do objeto Prefixo

Tabela t

View v

Trigger tg

Stored Procedure sp

Function f

Regras para criarNome da objetos de banco de dados:

Prefixo + _ + Mnemnico de 3 letras + NomeObjeto

Exemplos:

tcli_clientes (Tabela de clientes)vpea_pedidosativos (Viso: Pedidos Ativos)

Notas:

No estamos utilizando letras maisculas nos nomes das tabelas devido ao fato de que algunsbancos de dados no operarem bem com tabelas e colunas grafadas com letras maisculas.(PostgreSQL, por exemplo)

O mnemnico do nome da tabela (3 letras) devem ser usados nas queries quando se usar aliasses.

Exemplo:SELECT

ped.ped_descricaos, cli.cli_nomesFROMtped_pedidosped, tcli_clientes cli

WHEREped.fkcli_codigoi = cli.kcli_codigoi

Identificao Prefixo

Coluna comum Mnemnico de 3 letras da tabela + '_

Chave primria 'k' + Mnemnico de 3 letras da tabela + '_

Chave estrangeira 'fk' + Mnemnico de 3 letras da tabela origem + '_

Exemplos:

kped_codigoi (Chave primria: Cdigo do pedido, inteiro)

fkcli_codigoi (Chave estrangeira: Cdigo do cliente, inteiro)

fkfor_codigoi (Chave estrangeira: Cdigo do fornecedor, inteiro)

ped_quantidadei (Quantidade de itens no pedido, inteiro)

29


30/64

O Documento Glossrio

comum que os termos tcnicos utilizados pelos analistas no sejam interpretados corretamentepelos clientes e usurios.

O Glossrio serve para traduzir em uma linguagem nica todos os termos utilizados nadocumentao. importante para no permitir duplas interpretaes. Deve ser de acesso fcil,

disponibilizado em intranet ou pasta no servidor com acesso para todos os envolvidos.O Glossrio, na realidade, no 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 Glossrio normalmente organizado em ordem alfabtica, mas pode tambm ser por ordem derelevncia.

Exemplo de Glossrio

Data ltima atualizao: DD/MM/AA

Software: Sistema de DVDs pela Internet

Locao

Ato de alugar uma ou mais unidades de DVD.

Usurio Locador

Aquele que aluga um ou mais DVDs

Cliente Locador

Mesmo que Usurio Locador

BeneficirioAquele agregado por designao de um Cliente Locador

Cliente Contratante

Aquele que fez a requisio do sistema

Locatrio

Cliente Contratante

Equipamento de DVD

Aparelho que permite a execuo de discos de DVD.

DVD Lanamento

Aquele disco de DVD que apresenta data de lanamento do filme inferiora trs meses

30


31/64

DVD Catlogo

Aquele disco de DVD que apresenta data de lanamento do filme superiora trs meses

Multa

Valor pago por dia de atraso pelo locador ao locatrio.

FidelidadePrograma que visa estimular a fidelidade do Cliente Locador comdescontos e prmios.

Casos de Uso

Para 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 anlise estruturada).

O Ator realiza uma atividade e sempre atua sobre um Caso de Uso

Portanto, o Ator algum ou alguma coisa que atua ou interage com outras pessoas ou coisas de

modo que algo seja realizado.

Um caso de uso pode ser entendido como uma macroatividade que encerra diversas tarefas ouatividades. Estas tarefas visam consecuo dessa macroatividade.

Um caso de uso pode ser, tambm uma representao descrita de variadas aes para realizaodessa macroatividade. Enquanto tivermos afinidade entre as aes realizadas, teremos um Caso deUso.

Exemplo:

Supondo o seguinte Caso de Uso: Pagamento de compras com carto de dbito bancrio:As atividades relacionadas a este caso de uso podem ser listadas:

Coletar as informaes do carto (eletronicamente)

Verificao dos dados do carto pela instituio financeira

Validao do carto pelo banco.

Digitao do valor que vai ser debitado

Solicitao de digitao da senha do cliente

Verificao da senha pela instituio financeira

Verificao do saldo do cliente pelo banco

Retorno da instituio da concluso (ou no) da operao

O preenchimento da nota fiscal um outro caso de uso disparado pelo Caso de Uso dePagamento.

Finalmente a impresso do documento um terceiroCaso de Uso.

Note que os Atores envolvidos nos dois ltimos Casos de Uso no so os mesmos envolvidos noprimeiro.

31


32/64

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 no quer dizer que deveser escrito um tratado. Por outro lado, a objetividade no deve suprimir nenhuma informao

nem tornar a descrio da atividade nebulosa.

Devemos procurar utilizar a abstrao. A abstrao : Princpio de ignorar os aspectos de umassunto no relevantes para o propsito em questo. Assim, devemos tratar cada abstrao, emrelao ao que estamos analisando, como um negcio intrnseco a outro maior. Esteja sempre emmente que um sistema pertence a um negcio a ser automatizado. Ao aplicarmos a abstrao

podemos dividi-lo em vrias macro atividades: Os Casos de Uso.

Quem deve fazer a extrao de casos de Uso ?

Esta atividade pertence ao analista de negcios.A extrao de casos de uso pode ser feita de duas formas:

Pela observao do negcios (Operaes repetitivas)

Por intermdio de entrevistas.

Quando o analista de negcios vai a campo fazer suas entrevistas, este dever estar preparado paraas mais diversas reaes de seus futuros interlocutores. Uma o abordagem errada pode gerar umareao negativa do entrevistado que pode dificultar muito o trabalho. Saber o nome do entrevistado,alguma informao sobre a pessoa do tipo: Conhecer seu time de futebol, saber se tem famlia,filhos, suas idades aproximadas e outras particularidades pode trazer identidade e empatia fazendo

com que as informaes coletadas sejam mais fidedignas e completas.

Tambm importante saber ouvir, evitando cortar o raciocnio 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 espao para amenidades, a entrevista deve iniciar com aexplanao do objetivo da entrevista e o destino que ser dado as informaes coletadas.

32


33/64

Como extrair um Caso de Uso

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

1. Nome Referncia:

Verbo no infinitivo (Informar, comprar, pagar...)

O nome codificado (ID) do Caso de Uso ser usado em alguns documentos e comoreferncia como um trecho de cdigo se referir a ele. Tambm pode ser usado comochave primria se for armazenado em um banco de dados.

Exemplo: UC0086 - Cadastrar internautas e permitir alterao de senha e e-mail.

2. Breve descritivo

Do que se trata o caso de uso ?

Voc pode considerar esta descrio como insero de palavras chave para localizao

rpida 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 alterao de senha e e-mail.

3. Pr-condies:

O que necessrio acontecer para dar incio ao Caso de Uso ? Quais ospr requisitos ?

Qualquer ao ou reao 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 nmero de segurana

alm de ter 18 anos completos.

4. Atores envolvidos

Procure listar os atores separados por vrgula 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 maisgenrico possvel como Aluno, Gerente, Secretria, Funcionrio, Chefia, Coordenador,Professor, Operador etc. O nome deve ser usado sempre no corpo do documento. No se

preocupe em melhorar a elegncia do texto usando sinnimos 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/64

5. Cenrio principal

Qual a atividade bsica e sem alternativas ou excees? (Verbos nopresente do indicativo ou substantivos, iniciando a frase com (Registra,Compra Seleciona, Informa...)

Descreva as tarefas. Cada cenrio principal se refere a uma tarefa. Evite informaesvagas. Faa (e obtenha as respostas) as trs perguntas bsicas: O que ? , Para que? ou

Por que?, Como ?Lembre-se que o que for descrito aqui e seu nvel de detalhes deve ser suficiente para queas classes sejam codificadas. Caso alguma informao fique pendente, marque com umnmero seqencial entre colchetes. No tem 12 (pendncias) descreva cada uma delas.

Exemplo:

1. Cadastramento: Ao clicar no cone de cadastramento, o internauta encaminhado para atela de cadastro onde solicitado que digite: Nome, Sobrenome, Nick Name, Data denascimento (DD/MM/AA), sexo (implementado em radio button), CPF (semformatao), endereo de e-mail, um login (usurio) e uma senha que ser digitada emduplicata para validao. O internauta ainda deve copiar e digitar um nmero mostrado(obtido aleatoriamente [3] de uma base de figuras FIG_Figuras). Este procedimento visaevitar cadastro automtico de internautas. Ao clicar no boto de confirmar, estando

preenchidos todos os campos obrigatrios e tambm correto o nmero de segurana, 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 ( UC0056). Osistema identifica o internauta e mostra a tela de troca de senha. Aguarda a digitao emduplicata da nova senha. Esta dever possuir no mnimo 6 e no mximo 8 dgitos, sendo

pelo menos um dgito alfanumrico. Ser pedido tambm, opcionalmente, que o

internauta 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 so criptografadas (algoritmo XPTO 766) e salvas na Base.

3. Alterao de e-mail: Ao clicar no cone de troca de e-mail o internauta encaminhadopara a tela de login. O internauta se 'loga' ( UC0056), no sistema identifica ointernauta que encaminhado para a tela de mudana de e-mail. O internauta se 'loga' natela e depois digita o novo e-mail. O sistema identifica, consiste os dados e enviaconfirmao para o novo e-mail.

Nota importante:

Apesar de em nosso exemplo mostrar-mos 3 cenrios diferentes,no muito comum um caso de uso com muitos cenrios. O maisadequado seria considerar os cenrios Troca de Senha e Alteraode E-mailcomo casos de uso diferentes.

34


35/64

6. Cenrio alternativo e de excees

Em que casos no acontece como descrito no Cenrio Principal ?

Aqui devem ser tratadas as excees e situaes alternativas. Cada cenrio deve sertratado individualmente separando em sub-itens relacionados aos itens do CenrioPrincipal.

Exemplos:

1.1. Nick Name est em branco: Sistema preenche como o primeiro nome do internauta.

1.2. Nmero de segurana diferente do mostrado. Desviar para UC0034.

1.3. Data de aniversrio digitada invlida. Mostra caixa de mensagem para reconhecimentocom OK, limpa o campo, coloca o foco.

1.4 . Internauta tem mais de 100 anos (provvel erro de digitao) ou menos que 18 (menorde idade). Mostra aviso que no possvel o cadastro e o motivo e sai.

1.5. Senha de confirmao no bate: Os campos so limpos e o internauta redigita ambas assenhas.

1.6. Qualquer dos campos em branco (que no o Nick Name): O Internauta digita o campoem branco. O foco ser colocado no primeiro campo em branco. Os campos preenchidossero mantidos para que o internauta no 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 no bate. Limpar o campo, colocar o foco nele e pedir novadigitao.

1.9. Radio Button de sexo no est selecionado: apresentada uma caixa de dilogocomunicando o fato. O internauta reconhece com OK e o foco ser direcionado ao RadioButton de seleo de sexo.

2.1. Falha de login: Solicita novo login. (No controla quantidade de tentativas)

2.2. Senha invlida. (Menos que 6 dgitos e/ou no existe dgito alfanumrico) Mostra alertacom as regras para criao de senha, limpa os campos e solicita nova digitao

2.3. Senhas duplicadas no batem: Mostra aviso, limpa os campos de senha e solicita novadigitao.

2.4. O internauta cancela. Nenhuma ao realizada. O sistema volta para tela anterior.

3.1. Falha de login: Solicita novo login.

3.2. O e-mail ilegal (No tem dgito '@', tem espaos, nada antes do '@', nada depois do'@'). Mostra aviso e pede nova digitao.

3.3. O e-mail cadastrado na base j existe para outro internauta. Mostra aviso e finaliza.

35


36/64

7. Requisitos especiais

Existe alguma situao que no foi contemplada no cenrio principal nemno alternativo ?

Aqui colocamos as observaes que o entrevistado destacou como importante ou detalhedelicado. Alguma observao de segurana ou ponto de ateno especial.

Exemplo:

1. O tempo para apresentar as telas de ser o mnimo. A demora em retornar para o internautapode fazer com que desista de se cadastrar no site.

2. A informao de sexo deve ser um conjunto de dois 'Radio Buttons' sem inicializao.(Ambos no selecionados)

2. As senhas digitadas no 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 Includos

Liste aqui os casos de uso includos por este

Os casos de uso includos so os que em algum momento so usados integralmentedurante a descrio do cenrio principal ou alternativo. Seria o caso do login que, emalguns casos, pode ser evocado pelo caso de uso corrente. No se preocupe de darexplicaes ou justificativas. Apenas liste os casos de uso. (Veja: )

Exemplo:UC0023 Login do Internauta

UC0034 Trata Nmero de segurana

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, definssemos outros trs: Um paraincluso, outro para alterao e mais um para excluso. Como no caso de includos, nose preocupe em dar explicaes ou justificativas. Apenas liste os casos de uso (Veja:)

36


37/64

10. Dados

Tipos de dados que foram encontrados durante a descrio do caso deuso. Aqui informamos: texto (com tamanho), nmero (com preciso),moeda, data (com formato), etc.

Objetos de classes de biblioteca tambm devem ser listados aqui.(Repare em Date, Combo box, Text box etc)

Os componentes grficos relevantes, isto , que serviro para que osatores entrem ou recebam dados, tambm devem ser listados aqui.

Importante: Para cada componente grfico, crie pelo menos umavarivel para receber seus dados.

Exemplo:

Descrio Nome Tipo Banco deDados

Cdigo Usurio 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 BoxNick Name nNickName String Varchar (25)

txtNickname Text Box -

Data aniversrio dtNascimento Date Datetime

Sexo cSexo char Varchar (1)

rbSexoMasc Radio Button -

rbSexoFem Radio Button -

Palavra secreta String Varchar (20)

Nota: As clulas destacadas em cinza, servem para identificar grupos de smbolosrelacionados entre si.

11. Observaes

Suas observaes caso seja necessrio.

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/64

12. Pendncias

Existe alguma pendncia ?

Liste aqui as pendncias referenciadas na descrio do caso de uso. Numere no local dotexto (entre colchetes) as pendncias a medida que apaream. importante tentarestabelecer datas para soluo. A medida que as pendncias forem sendo resolvidas, o

analista edita o texto definitivo no corpo do Caso de Uso (normalmente no cenrioprincipal ou no cenrio alternativo) retirando os toquens de sinalizao de pendncias. Averso do Caso de Uso deve ser salva sem eliminao da anterior, batizando o documentodo Caso de Uso com nome no formato:

UCnnnnnAAMMDD.doc (nnnnn = Nmero UC, AA = ano, MM = mes, DD = dia)

Nota: Use o nome do arquivo acima no campo Verso do rodap.

Exemplo:

1. Layout da tela de login ainda em construo. Prazo para trmino: 04/04/052. Falta definir a tabela onde ser armazenada a palavra secreta e a forma de utilizao.

Reunio marcada para definio em 10/04/05

3. Algoritmo de seleo randmica de figuras na base de dados ser definida at 15/04/05 Responsvel: Sr Andr..

13. Rodap

Analista responsvel ________________________________________

Entrevistado: ________________________________________

rea: ________________________________________

Data: ________________________________________

Verso: ________________________________________

38


39/64

Diagrama de Classes

A representaes da classe

NomeClasse

Ou

NomeClasse

Usamos um retngulo com o nome da classe escrito internamente (na forma reduzida) ou umretngulo com 3 divises (na forma plena). Escrevemos o nome da classe na primeira diviso. Se

necessrio, podemos adicionar nesta repartio mais alguma informao relevante.

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

Classes ativas e inativas

Classes ativas so as que inicializam e controlam o fluxo de dados e atividades.

Classe passivas so classes que apenas armazenam dados e serve a outras classes.

Caso seja necessrio assinar uma classe como classe ativa use uma borda (externa) mais espessa no

diagrama:

NomeClasse

A representao de objetos

nomeObjeto:NomeClasse

Ou

nomeObjeto:NomeClasse

Representao de uma instncia (objeto) na forma plena e reduzida. Notem que os nomes no estoem negrito, mas sublinhados. Usamos o nome do objeto ligado ao nome da classe com um caractere

dois pontos (:)

39


40/64

40


41/64

Atributos (Propriedades)

Como sabemos, os atributos so variveis e/ou objetos que declaramos como instncias da classe.

Representamos os atributos no retngulo intermedirio do diagrama (apenas da forma plena). Almde representar o nome do atributo, representamos tambm 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 pblico. O sinal de indica que oatributo privado e # que protegido.

O sinal de/ antes do atributo idade significa que este atributo alm de privado tambm no ter ummtodo 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.

Operaes (mtodos)

As operaes ganharam o terceiro e ltimo retngulo do diagrama.

NomeClasse

+nome: String

-dataNascimento: Data

#altura: inteiro

/idade: inteiro

+getIdade () : Inteiro

+setNome (nome:String)

+getNome () : String

+setAltura (altura:inteiro)

+getAltura () : Inteiro

Notas:

O atributo idade possui um mtodo get, mas no possui um mtodo set. Os atributos nome e altura possuem ambos os mtodos get e set. Apesar do nome ser, no exemplo, uma propriedade pblica (o que no recomendado),

vamos definir o par de mtodos get/set para ele tambm.

41


42/64

Associaes de Classes

No POO muito comum (e recomendvel) que uma classe defina como atributos objetos de outrasclasses. Chamamos a isto de Associao de Classes. Representamos a associao ligando as duasclasses com uma linha.

Falando mais formalmente, uma associao na UML representa uma populao variada de vnculos(links) de relacionamento entre instncias de classe.

Por exemplo, vamos imaginar uma classe de DVDs (Ttulos) de uma locadora e outra classe deClientes da locadora. O processo de locao uma associao entre as duas classes. As locaes soum conjunto de muitos vnculos. Cada vnculo representa uma locao.

Clientes Locao Ttulos (DVDs)

Podemos representar tambm a proporo da associao, ou seja, um cliente pode alugar um ou

mais filmes. Mas um filme no pode ser alugado por mais de um cliente ao mesmo tempo. Podemosindicar estas propores usando a seguinte sintaxe:

1 No mais que uma

0..1 Nenhuma ou uma

* Muitas

0..* Nenhuma ou muitas

1..* Uma ou muitas

Exemplo:

Clientes Locao Ttulos (DVDs)

1 1..*

Como vimos, para que haja uma locao ser indispensvel existncia de um cliente. Este clienteter que alugar pelo menos um ttulo para que seja caracterizada a locao. O cliente pode entrar nalocadora e no alugar nenhum filme... Na classe Titulos no seria 0..* ? Porque no ?

Mas prestando mais ateno, vemos que Locao poderia ser uma classe com objeto Cliente eobjetos Ttulos definidos como seus atributos. A classe que representa a associao (Locacao) deveser ligada a ambas por intermdio de uma linha pontilhada como mostra o diagrama abaixo.

Locao

. . .

. . .

|

|

|

Cliente Aluga | 1..* Ttulos (DVDs)

1 alugado

42


43/64

O estudo das associaes se preocupa em entender como objetos de diferentes classes podem serelacionar. Como o projetista poder usar estas associaes da melhor forma.

Existem basicamente quatro formas de associaes: (Que veremos com mais detalhes a seguir)

1. Simples ou Binria: (nNria) Associao simples entre classes. Representa os casos emque uma classe referencia a outra. As classes podem se referenciar mutuamente ou no.

No muito comum mas podemos ter mltiplas associas entre classes.

Exemplo: Produto e Fornecedor em uma classe de ItensPedido.

2. Composio: Temos uma composio quando o objeto de uma classe s existe enquantoos objetos hspedes existam, isto , as partes so essenciais para a existncia do todo.

Exemplo: Motor de um avio. Um avio no um avio sem motor. (pode ser nomximo um planador). Uma cadeira no uma cadeira sem os ps (Mas uma cadeirasem os braos Os braos no compoem a cadeira so agregados).

3. Agregao: Temos uma agregao quando o objeto agregador pode continuar existindomesmo que seus agregados deixem de existir. A variao no nmero de scios de umclube, funcionrios em uma empresa ou ovelhas em um rebanho no interfere naexistncia do objeto que os contm.

Exemplo: Um clube (e seus scios), um colgio (e seus alunos) , um departamento deuma empresa (e seus funcionrios).

4. Herana: Na herana, perguntamos se a classe candidata a ser uma subclasse um casoparticular da provvel superclasse. Se a provvel superclasse possui atributos que comcerteza a subclasse ir compartilhar.

Exemplo: Mamfero superclasse de PrimataPrimata superclasse de Ser Humano

Agregao

Como a agregao uma composio 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 agregao uma associao grupo/membro,onde o grupo (ou agregado) um objeto e seus membros(ou constituintes) outros objetos .

As caractersticas mais importantes da agregao so:

O objeto agregado pode potencialmente existir sem seus objetos constituintes.

Exemplo: O departamento de uma empresa: possvel demitir todos os funcionrios de umaempresa, mas o departamento ainda continuar existindo... No poderamos dizer isso dafloresta.. ai o exemplo da floresta no se aplica... E um rebanho de ovelhas sem ovelhas ?

Um objeto pode ser constituinte de mais de um agregado . o caso de um cidado poder serscio de mais de um clube... Mas no seria o caso de uma ovelha pertencer a mais de umrebanho...

As agregaes tendem a ser homogneas. Isso quer dizer que os constituintes de um agregadotpico so todos de uma mesma classe. (rvores, ovelhas, casas, cidados, tens de pedido)

43


44/64

Vamos agora ao diagrama de uma associao:

Usamos um pequeno losango vazio (diamante) na extremidade da linha de associao doagregado prximo ao agregado.

As classes do agregado (Relatrio gerncia e do constituinte (Pargrafo), aparecem nasrespectivas extremidades da linha de associao. O papel do objeto constituinte parteDoTexto

tambm aparece na extremidade do constituinte da linha de associao. Com a agregao, devemos mostrar a multiplicidade em ambas as extremidades da linha de

associao porque no possvel assumir a multiplicidade em todos os lugares. Veja que umpargrafo pode pertencer a muitos relatrios de gerncia ao mesmo tempo ou pode pertencer aum relatrio ou a nenhum. A multiplicidade na extremidade do constituinte tambm 0..*.Isso significa que um relatrio pode compreender muitos pargrafos, ou um pargrafo ounenhum ( relatrio vazio )

Exemplo

Neste exemplo, a agregao existe apenas entre a classe Pedido e a classe Itens Pedidos (veja olosango). A classe Produto possui apenas uma associao binria comum com a classe itensPedido. Note que os itens do pedido no podem existir sem que um pedido os tenha gerado.Portanto, item pedido faz parte de pedido. Veja que a classe Produto no depende de Pedidonem de Itens Pedido.

A agregao tipicamente homognea So objetos idnticos

44

RelatororioDeGerencia

Pargrafo

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

Compe

1.. *


45/64

Composio

Constitui-se em uma variao da associao de agregao. Ela procura representar um vnculo maisforte entre o objeto-todo e os objetos parte, procurando demonstrar que os objetos-parte tem de

pertencer exclusivamente a um nico objeto-todo com que se relacionam.

Alguns objetos so montados a partir de outros objetos formando um conjunto com uma claraidentidade. Como exemplo podemos citar um computador. A idia de um computador , para umagrande maioria das pessoas, o conjunto: Teclado + torre + terminal de vdeo. Usando um exemplomais prximo... um e-mail uma composio de corpo, cabealho, arquivos anexados etc.Podemos ver ainda o cabealho como a composio de assunto, remetente, destinatrio, cc, cpiaoculta, data hora etc.

Usando o nosso exemplo do e-mail, Na composio chamamos o objeto e-mail de composto e osobjetos que o compem (assunto, remetente etc.) de objeto componente.

Em uma composio, um mesmo objeto-parte no pode associar-se a mais de um objeto todo.Neste caso usamos um losango (diamante) preenchido.

Principais Caractersticas das Composies:

1. O objeto composto no existe sem seus componentes. Um computador sem teclado torre emonitor no um computador. Assim, o tempo de vida de um de seus componentes no podeultrapassar o tempo de vida dos seus componentes.

2. parte de um objeto composto no poder pertencer a mais de um objeto composto .

3. A composio sempre tipicamente heterognea. Uma composio de muitos objetosidnticos seria o caso de um array (ou vetor) de objetos. Isso quer dizer que as partesnormalmente no so do mesmo tipo.

Vamos dissecar esta figura para ver como o UML funciona.

Cada associao aparece no diagrama como uma linha de associao, com um losango(diamante) encostado no lado do objeto composto.

A classe do objeto composto, Planador, aparece em uma extremidade da linha de associao. 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 composio aparece na extremidade do componente na linhade associao. Os papis asaEsquerda e asaDireita so objetos da classe Asa. Cada um

45

Planador

Fuselagem Cauda Asa

fuselagem1 cauda 1 asaEesquerda asaDireita11


46/64

desempenhando um papel diferente em um planador. Voc pode (e deve) exibir multiplicidade na extremidade do componente de cada linha de

associao. Caso a multiplicidade seja omitida, assume-se como 1. As linhas de associao no tem qualquer nome... o que corresponde a uma norma tanto para

composio quanto para agregao. Notem que as partes: Fuselagem + Cauda + Asa(s), compem 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 composio

Observando-se a figura baixo, percebe-se que um objeto da classe Revista Cientfica refere-se no mnimo um objeto da classe Edio, podendo referir-se a muitos objetos desta classe, e quecada instncia de classe Edio relaciona-se nica e exclusivamente a uma instncia especfica daclasse Revista Cientfica, no podendo relacionar-se com nenhuma outra.

Notamos ainda que um objeto da classe Edio deve relacionar-se com no mnimo 5 e nomximo10 objetos da classe Artigo. Este tipo de informao se torna til como documentao eserve como uma forma de validao, que impede que uma revista seja publicada sem ter no mnimo5 artigos e no mais que 10. No entanto, um objeto da classe Artigo refere-se unicamente a umobjeto da classe Edio. Isto tambm uma forma de documentao, j que uma edio de umarevista cientfica s deve publicar trabalhos inditos, assim lgico que no possvel a um mesmo

objeto da classe Artigo relacionar-se a mais de um objeto da classe Edio.

A composio tipicamente heterognea So objetos diferentes

46

Revista Cientfica

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

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

Edio

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

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

Artigo

+registrar()+consultar()

-titArt : String-pagIniArt : int

1.. *

Contm

5..10

Publica


47/64

Herana

A Associao de Herana conceitualmente bem diferente de composio e agregao. Em ambasdeclaramos explicitamente objetos de outras classes como propriedades. A herana na realidadeabsorve uma outra classe.

Veja o diagrama:

As associao de herana representada acima esquematicamente (e que no tem nada a ver comUML), mostra que um gorila uma espcie de primata, que por sua vez uma espcie demamfero que por sua vez uma espcie de vertebrado e assim por diante. Isso significa quequando instanciamos um gorila, estamos instanciando todas suas superclasses junto com ele... Nanatureza o conceito de herana fica assinalado pelo DNA das espcies. Todos os primatas, porexemplo, compartilham uma grande seqncia idntica de seu DNA entre si. Boa parte deste DNA compartilhado por todos mamferos que por sua vez compartilham um parte ainda menor com osvertebrados e assim por diante...

J o diagrama acima representa (parcialmente) a associao de classes no formato UML (Excetopela graduao de tons de cinza demonstrando graduao da classe mais interna (cinza escuro) paraa mais externa(cinza claro) que minha inveno).

Espero que esteja claro que o diagrama acima representa apenas uma pequena parte da rvore deheranas da vida animal na natureza.

Estudaremos outros aspectos da herana mais a frente em Generalizao.

47

Primatas

Vertebrados

Mamferos

Gorilas

Aves

Felinos

Orangotangos

Vertebrados

Mamferos

Primatas

Gorilas

Orangotangos

FelinosAves


48/64

Levantamento de Classes

Uma vez levantados os autores e os casos de uso, podemos partir para a codificao das classes.

A definio das classes necessrias para a realizao de todas as funcionalidades do sistema envolveo processo de sntese, ou seja, criao. No existem regras claras e inequvocas para retirar classesde casos de uso. responsbilidade do projetista, baseadoem seu bom senso, criatividade e

experincia, determinar quais classes iro compor o sistema. A definio das classes exige ummestudo detalhado dos requisitos do sistema e das possibilidades de separao dos dados e processosem classes.

Esteretipos do Diagrama de Classes

So 'labels'escritos entre >. Servem para esclarecer o significado de associaes, diagramasde classes e de outros elementos de UML.

Escrevemos os esteretipos sobre o nome da classe em fonte menor que a fonte usada para escrevero nome da classe.

Vamos estudar alguns exemplos de esteretipos usados em diagramas de classes:

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 explcito que uma classe uma entidade, ou seja, a classe contem informaesrecebidas ou geradas por meio do sistema. Significa tambm que normalmente possuiromuitos objetos e que estes possivelmente tero um longo perodo de vida. Isto pode serinterpretado como uma indicao que estas propriedades sero total ou parcialmente

preservadas (por tempo de vida, no em banco de dados)

Persistente: Com este esteretipo estamos indicando que 100% das propriedades seropreservadas. Isso praticamente implica no uso de banco de dados.

Exemplo:

Conta Comum

#nrConta: long

#vlSaldo: double

#tipo: int

48


49/64

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 restries. Isso feito declarando oesteretipo de e a restrio .

49


50/64

Exemplo:

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

Fronteira: Tambm conhecido como esteretipo de fronteira. Identifica uma classe queserve de comunicao entre atores externos e o sistema propriamente dito. Muitas vezes umaclasse associada prpria interface do sistema.

Identifica classes cujo papel realizar o interfaceamento com entidades externas (atores) .Este tipo de classe contm o protocolo necessrio para comunicao com atores comoimpressora, monitor, teclado, disco, porta serial, modem etc.

Uma classe de importao de tabelas de um sistema para outro tambm um exemplo declasse .

Controle: Identifica classes que servem de intermdio entre classes e asoutras classes do sistema. Objetos so responsveis por interpretar os eventosocorridos sobre os objetos , como os movimentos do mouse, o

pressionamento de um boto e retransmit-los para objetos das classes de entidades quecompem o sistema.

De outra forma, identifica classes cujo papel controlar a execuo de processos. Estasclasses contm, normalmente, o fluxo de execuo de todo ou parte de casos de uso ecomandam outras classes na execuo de procedimentos.

Exemplo:

Interface do Caixa Eletrnico

Controlador do Caixa Eletrnico

50


51/64

Algumas regras para definio 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 secretria:

Interface grfica. (tela)

Para a impressora:

Configurao da impressora, protocolo, tipos de impressoras, portas etc.

Para SGBD

Abertura e fechamento de conexo etc.

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

Cada caso de uso implica em um encadeamento de aes a serem realizadas pelo sistema. Asregras de negcio a ser automatizado tero que estar definidas em alguma parte do sistema.Este conhecimento pode estar distribudo em vrios componentes do sistema, oucentralizado em um ou poucos componentes. A vantagem de centralizar as regras do negcioem um ou poucos componentes a maior facilidade de entendimento do processo ealteraes e/ou manutenes futuras. Pensando nesta linha, pode-se criar uma classe decontrole para cada caso de uso de forma que ela contenha a descrio 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 faa-se uma anlise dos dados

manipulados e identifique-se grupos que sero representados, cada um, por uma classe.

51


52/64

Levantando Classes a Partir do Caso de Uso

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

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

Trs classes (detalhamento) estendidas de ControleCadAluno (Regra 3.)

Uma classe de entidade para cuidar do aluno. Como o SGBD no uma entidade real, no necessrio criar uma classe para ele. (Regra 4.)

52

Cadastrar Aluno

Secretria SGBD

CInterfaceSecretaria

CInterfaceSGBD

CControleCadAluno

CControleIncluiAluno

CControleAlteraAluno

CControleExcluiAluno

CAluno


53/64

Gerando Classes de Outro Caso de Uso

Vamos trabalhar com o caso de uso: Emitir Dirio de Classe:

No exemplo anterior j foram criadas as classes de interface da secretria e do SGBD. Dasinterfaces falta apenas a classe de interface da impressora.

Diferentemente do caso de uso Cadastrar Aluno, no ser necessrio desdobrar a classe de controlepois ela no se justifica devido a sua simplicidade.

53

Emitir Dirio de Classe

Secretria

Impressora

SGBD

CInterfaceImpressora

-CodigoTurma: String-listaAlunos : CAluno

CDiarioClasse

-CodigoTurma: String-listaAlunos : CAluno

CDisciplina

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

-codigoTurma: String-listaAlunos : CAluno[]

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

CProfessor

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

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

CAluno

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


54/64

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 esttico. Evita-se com isso linhas muito emaranhadasque, certamente, poluiriam o diagrama.

Um fator muito importante do projeto de um sistema, a cronologia, no est contemplada neste tipode diagrama. Podemos perceber que no diagrama que acabamos de descrever so apresentados

processos que ocorrem pelo menos em trs momentos diferentes do sistema, o momento em que ocliente solicita uma aplice de seguro, o momento em que ele paga uma parcela da aplice e omomento em que ele informa a ocorrncia de um sinistro.

O Diagrma de Casos de Uso no foi imaginado para representar a temporalidade. Seu objetivo identificar todas as possveis funes que o sistema ir oferecer sem se preocupar muito com otempo em que elas ocorrero. No prximo captulo trataremos dos Diagramas de Seqnciaimaginados exatamente com esta finalidade.

54


55/64

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

0110037apostilauml-120421121749-phpapp01.pdf

Documents

Transcript of 0110037apostilauml-120421121749-phpapp01.pdf