Upload
edison-silva-filho
View
63
Download
0
Embed Size (px)
Citation preview
UML – Unifield Modeling Language
UML – Um enfoque prático
Depósito
Cliente
<<include>>
Saque
Registrar movimento
Banco
<<include>>
Porque modelar ?
A analogia com as engenharias; Maquetes Modelos matemáticos Storyboards na indústria
cinematográfica Modelos sociais Miniaturas de carros, aviões etc.
Comunicação com terceiros; Participação dos ‘clientes’
O que é um modelo ?
Modelo é a simplificação da realidade;
O modelo reduz a complexidade pela decomposição da realidade em elementos ‘fáceis de entender’. (abstração)
Diferentes aspectos definem um sistema, portanto, é necessário vários modelos para representar cada um destes aspectos;
Definição de modelo (Continuação)
Cada modelo mostra um abstração bem encapsulada no sistema
Um modelo pode demonstrar: Estrutura: Organização do sistema Comportamento: Dinâmica do sistema
Um modelo é expressivo através de uma linguagem Linguagem de modelagem
Linguagem de Modelagem
A linguagem para definição de modelos deve ter: Elementos do modelo – Conceito e
semântica fundamentais ao modelo. Notação dos elementos –
representação visual dos elementos do modelo
Guidelines – guias de como e onde usar a linguagem.
Princípios da Modelagem
A escolha de quais modelos criar influencia na forma como o problema é atacado e solução que é encontrada.
Todo modelo deve ser expresso em diferentes níveis de precisão.
Os melhores modelos são aqueles que refletem a realidade.
Não existe um modelo único. Até pequenos projetos precisam de vários modelos para serem representados.
Benefícios da Modelagem
Modelos comunicam a estrutura e o comportamento do aplicativo
Modelos permitem visualizar e controlar a arquitetura do aplicativo.
Modelos permitem entender melhor o aplicativo que estamos construindo, expondo oportunidades de simplificação e reusabilidade.
Modelos permitem gerenciar os riscos.
Evolução da UML 1997
Setembro: UML versão 1.1 em votação pela OMG (Object Manegement Group)
Novembro: UML 1.1 é adotada pela OMG. A responsabilidade pela manutenção passa a ser da OMG RTF (Revision Task Force) por Cris Kobryn
1998 – Versão 1.2 1999 – Versão 1.3 2001 – Versão 1.4 2004 – Versão 2.0 (Abril)
Definição da OMG-UML
É uma linguagem para especificar, visualizar, cosntruir e documentar sistemas através de modelos.
É não proprietária Representa uma coleção de praticas
de engenharia que comprovadamente se demonstraram eficientes na modelagem de sistemas complexos...
Metas de UML
Prover aos usuários uma linguagem de modelagem visual expressiva e pronta para uso.
Prover mecanismos de estensibilidade e especificação para ampliar os conceitos centrais
Ser independente de linguagem de programação e processos de desenvolvimento particulares.
Prover uma base formal para entendimento da linguagem de modelagem;
Suportar conceitos de desenvolvimento de nível mais alto, tais como colaborações, estruturas, modelos e componentes.
Integrar as melhores práticas.
Metas UML (Continuação)
Os usuários UML precisam saber:
Construir modelos que utilizam conceitos centrais sem utilizar mecanismos para extensão na maioria das aplicações normais
Acrescentar novos conceitos e notações para temas não cobertos pelo núcleo
Escolher entre interpretações variantes de conceitos existentes, quando não houver um claro consenso.
Especificar os conceitos, as notações e as restrições, para domínios de aplicações particulares.
Ferramentas de Modelagem
Estudo de Casos de Uso (Use Cases) Diagramas:
Casos de uso Classes Seqüência Objetos Máquina de estados Atividade Interação Comunicação Componente, Implantação, Estrutura Composição
(UML2)
Conceitos Importantes
Associação entre casos de uso: Especialização / Generalização
É uma forma de Associação entre casos de uso na qual existe dois ou mais casos de uso com muitas características semelhantes, apresentando contudo algumas diferenças importantes entre si.
Desta forma não é necessário colocar a mesma documentação para todos os Casos de Uso envolvidos porque toda a estrutura de um caso de uso generalizado é herdada pelos casos de uso especializados.
A Associação de Generalização/Especialização é representada por uma seta que une ao Caso de Uso Geral (para onde a seta aponta)
Especialização / Generalização
Exemplo:
Abertura conta especial
Abertura conta poupança
Abertura de conta
Associação Inclusão
A Associação de inclusão costuma ser utilizada quando existe um serviço, situação ou rotina comum a mais de um Caso de Uso.
Depósito
Cliente
<<include>>
Saque
Registrar movimento
Banco
<<include>>
Associação Extensão
Associações de Extensão são utilizadas para descrever cenários opcionais de um caso de uso. Os casos de uso estendidos descrevem cenários que somente ocorrerão em situações específicas.
Encerrar conta
Saque Depósito
ClienteBanco
<<extend>>
<<extend>>
O que é Orientação a Objeto ?
É uma “nova” forma de pensar na hora de desenvolver sistemas...
O mundo é orientado a objetos... Porque não os sistemas ?
Tudo em nossa volta são objetos que pertencem a determinadas classes...
De que é feita a OO ?
Classes Objetos Herança e Herança múltipla Encapsulamento Sobrecarga Sobrescrita Polimorfismo
O que é uma classe ? É um conjunto de propriedades
(características) e métodos (procedimentos) que caracterizam um grupo de objetos...
Exemplo:
Propriedades: raio perímetro área
Métodos: cálculo de área cálculo de perímetro
Qual o nome da classe ?
O que é um objeto ?
É uma entidade que compartilha exatamente as mesmas características e procedimentos de outros de mesma classe.Exemplos:
quadradoretângulotrapézio
São todos objetos de que classe ?Que características e métodos possuem em
comum ?
Herança
É a capacidade de uma classe ser estendida de uma outra.
Exemplos:
Um Círculo é um tipo de Figura.Um Retângulo é um tipo de Figura.Um Quadrado é um tipo de Retângulo.
Um Quadrado é um tipo de Figura ?
...e um Círculo é um Quadrado ?
Como representamos Herança ?
Figura
Retângulo Círculo
Quadrado
O que é herança múltipla ?
Uma classe é formada (estendida) a partir de outras duas ou mais...
Exemplo:
Rádio Relógio
Rádio Relógio
A Herança na vida
Vertebrados
Mamíferos
PrimatasGorilas
OrangotangosFelinos
Aves
Diagrama natural de herança
A Herança na vida...
Primatas
Vertebrados
Mamíferos
Gorilas
Aves
Felinos
Orangotangos
Diagrama convencional de herança
Encapsulamento
Possibilita o controle de visibilidade de atributos e procedimentos.
private public protected
Em java temos ainda o tipo default.
Sobrecarga (Overloading)
Exemplos:Assinaturas diferentes (São sobrecarga) void setDadosConta (String nome, long numConta); void setDadosConta (long numConta, String nome); void setDadosConta (String nome, long numConta, double valDeposito);
Assinaturas idênticas (Não são sobrecarga) double calculaSalario (float valorHora, int
quantidadeHoras); float calculaSalario (float var, int quant);
Sobrescrita (Overriding)
Quadrilatero-lado1 : float-lado2 : float-area : float-perimetro : float-diagonal : float
+Quadrilatero(lado1: float, lado2: float)+getArea() : float+getPerimetro() : float
+getDiagonal() : float
Retângulo Quadrado
+Retangulo(lado1 : float, lado2 : float)
+Quadrado(lado: float)+getDiagonal() : float
Polimorfismo
Capacidade de um método (ou seja, sua referência) poder representar métodos diferentes de acordo com o contexto...
Sobrecarga: Resolvida pelo compilador em tempo de compilação.
Polimorfismo: Resolvido pela lógica do código em tempo de execução
Retenção de estado
Capacidade de um objeto reter seu estado. Isto é, quando existe um objeto criado (residente na memória, instanciado), este objeto mantém suas propriedades inalteradas até que alguma ação (mensagem) realize algum tipo de alteração em suas propriedades.
Identidade de um Objeto
É a propriedade pela qual cada objeto (independentemente de sua classe ou estado) pode ser identificado e tratado como uma entidade distinta de software.
Os objetos podem ser da mesma classe... mas cada um tem sua identidade
Mensagens ou Estímulos
Mensagens são formas de comunicação do mundo exterior (atores) com os objetos. Os objetos podem tanto receber dados do mundo exterior (argumentos) quanto retornar para eles.
Tipos de Mensagem
Informativas
Normalmente são responsáveis por inicilalizar ou alterar atributos dos objetos. São tipicamente procedimentos com prefixo set.
Exemplos: void setMatricula (String matricula);
void setLimite (double valor);
Tipos de Mensagem
Interrogativas
São dados retornados pelos procedimentos. São tipicamente procedimentos com prefixo get. Podem retornar simplesmente atributos do objeto ou retornar algum processamento.
Exemplos:
double getSalario ();
String getMatricula();
Tipos de Mensagem
Imperativas
São mensagens usadas para realizar alguma operação de entrada e saída, inicializar algum status etc.. Normalmente não possuem retorno nem argumentos.
Exemplos:
void imprimeAluno ();void enviaDadosLinha();void clear();
Documentos Iniciais
Documento Visão É um relato resumido com os principais tópicos a
que o negócio a ser automatizado deve fornecer. Normalmente faz parte do contrato de
desenvolvimento. É comum que este documento aborde aspectos de tecnologia.
Deve ser resumido e de linguagem acessível para leitura de pessoal de nível gerencial, não necessariamente técnico.
O analista poderá, a seu critério, detalhar mais ou menos cada item de acordo com a sua importância estratégica no projeto. Mas todos os itens devem ser citados.
Itens do Documento Visão
Introdução. Escopo. (Relação de módulos) Definições de acrônimos e abreviaturas. Referências. (Documentos, contratos etc.) Oportunidade de negócio. Descrição do pessoal envolvido. Observações. Detalhamento dos Módulos (Levantados nos UCs) Precedências e prioridades. Requisitos não funcionais. (fora do escopo) Requisitos de sistemas e ambientes. Insira uma figura com disposição dos módulos.
(Diagrama de Caso de Uso Nível Zero). Assinatura do Solicitante do Projeto (Cliente).
Diagrama de Caso de Uso
O Ator pode ser uma pessoa, um sistema ou mesmo uma Entidade
O Ator é caracterizado por realizar uma atividade. Nos diagramas representamos o ator como um boneco magro ou um retângulo com o nome do autor abaixo do estereótipo:
Aluno
<< ator >>Aluno
Atores
Exemplos de Atores:
Pessoas: Usuário, secretária, aluno, professor, administrador etc.
Dispositivos: impressoras, máquina ou equipamentos etc.
Hardwares: Modens, roteadores, placas de controle etc.
Softwares: SGBDs, Aplicativos de controle de processo etc.
Considerações sobre Atores
Observe que atores representam papéis desempenhados quando estiverem interagindo com o sistema.
O ator não representa um elemento particular, mas qualquer um que esteja realizando aquele papel naquele momento. Em um sistema em que o ator seja <<aluno>> tratará como <<aluno>> qualquer pessoa que seja ou represente o aluno.
Na fase de projeto, um ator é uma classe não um objeto.
O ator interage com o sistema sempre através de mensagens.
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 ?
Identificando Casos de Uso
A identificação dos casos de uso não deve ser confundida com telas do sistema.
Para poder encontrar e dissecar os casos de uso, é fundamental a abstração. Dificuldade de abstração: Nossa natureza
tende a tratar os problemas mais complicados e relevantes .
A abstração de mãos dadas com a metodologia UML de extração de casos de uso é uma ferramenta que pode ajudar a equacionar problemas de grande
Um exemplo...
Locar DVD
Entregar Locação
Administrar Promoções
Administrar Multas
Devolução
Controlar Estoques
Administrar Marketing
Sistema de Locação de DVDs Via WEB
Cliente Site
Fornecedor
Modelo de Caso de Uso
Procure seguir o exemplo abaixo para suas entrevistas e a formatação final do caso de uso:
1. Nome Referência:Verbo no infinitivo (Informar, comprar, pagar...)
2. Breve descritivoDo que se trata o caso de uso ?
3. Pré-condições:O que é necessário acontecer para dar início ao Caso de Uso ?
Quais os pré requisitos ?
4. Atores envolvidosProcure listar os atores separados por vírgula para facilitar futuras
buscas. 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.
Modelo de Caso de Uso
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...)
Exemplo:
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. Ao clicar no botão de confirmar, estando preenchidos todos os campos obrigatórios, o sistema salva o novo internauta no SGBD [2] envia um e-mail ao internauta confirmando o cadastro e retorna.
Modelo de Caso de Uso
6. Cenário alternativo e/ou de exceçõesEm que casos não acontece como descrito no Cenário Principal ?
Exemplos:
1.1. Nick Name está em branco: Sistema preenche como o primeiro nome do internauta.
1.2. Data de aniversário digitada é inválida. Mostra caixa de mensagem para reconhecimento com OK, limpa o campo, coloca o foco.
1.3 . 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.4. Senha de confirmação não bate: Os campos são limpos e o internauta redigita ambas as senhas.
1.5. 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.6. Login selecionado já existe na base do sistema. Desvia para o caso de uso UC0032
Modelo de Caso de Uso
7. Requisitos especiais
Existe alguma situação que não foi contemplada no cenário principal nem no alternativo ?
Exemplo:
7.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.
7.2. As senhas digitadas não devem ser 'case sensitive'
8. Casos de uso Incluídos
Liste aqui os casos de uso incluídos por este
Exemplo:
UC0023 – Login do InternautaUC0034 – Trata Número de segurançaUC0032 – Trata login existente
Modelo de Caso de Uso
9. Casos de uso Estendidos
Liste aqui os casos de uso estendidos por este
10. DadosTipos 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.
Importante: Para cada componente gráfico (tela), crie pelo menos uma variável para receber seus dados.
11. ObservaçõesSuas observações caso seja necessário.Exemplo:Rever o caso de uso UC0023 – Login do InternautaO Sr. José ficou de enviar via e-mail até 12/04/05 o layout do
arquivo de log de senhas.
Modelo de Caso de Uso
12. Pendências
Existe alguma pendência ?
Exemplo:
Layout da tela de login ainda em construção. Prazo para término: 04/04/05
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
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: ________________________________________
Encontrando as classes...
<<boundary>>CInterfaceImpressora
-CodigoTurma: String-listaAlunos : CAluno
<<control>>CDiarioClasse
-CodigoTurma: String-listaAlunos : CAluno
<<entity>>CDisciplina
-codigoTurma: String-codigoDisciplina: String
-nomeDisciplina: String
-codigoTurma: String-listaAlunos : CAluno[]
-codigo: int-nome: String-categoria: byte
<<entity>>CProfessor
-codigo: int-nome: String-categoria: byte
-registro: int-nome: String-curso: char
<<entity>>CAluno
-registro: int-nome: String-curso: char
Emitir Diário de Classe
Secretária
Impressora
SGBD
Regras para encontrar classes para casos de uso
Regra 1Definir uma classe tipo fronteira para cada ator que
participe do caso de uso:
No exemplo da unidade de ensino, teremos duas classes de fronteira:
Para a secretária: Interface gráfica. (tela)
Para a impressora: Configuração da impressora, protocolo, tipos de impressoras,
portas etc.
Para SGBD Abertura e fechamento de conexão etc.
Regras para encontrar classes para casos de uso
Regra 2 Definir pelo menos uma classe tipo controle para cada
caso de uso
Cada caso de uso implica em um encadeamento de ações a serem realizadas pelo sistema. As regras do negócio a ser automatizado terão que estar definidas em alguma parte do sistema.
A vantagem de centralizar as regras do negócio em um ou poucos componentes é a maior facilidade de entendimento do processo e alterações e/ou manutenções futuras.
Desta forma, pode-se criar uma classe de controle para cada caso de uso, de forma que ela contenha a descrição e comando do processo associado ao caso de uso.
Regras para encontrar classes para casos de uso
Regra 3
Definir classes de controle auxiliares.
A medida que aumenta a complexidade das classes de controle, podemos criar classes mais especializadas detalhando melhor os sub-processos.
Regras para encontrar classes para casos de uso
Regra 4
Definir uma classe de tipo entidade para cada grupo de dados
Grupos de dados que juntos definem entidades abstratas ou do mundo real deveriam ser representados por classes. Sugere-se, portanto, que para cada caso faça-se uma análise dos dados manipulados e identifique-se grupos que serão representados, cada um, por uma classe.
Estereótipos do Diagrama de Classes
Classes tipo <<entity>>
O principal papel é armazenar dados que juntos possuem uma identidade. Este tipo de classe normalmente representa entidades do mundo real como aluno, professor, disciplina, curso etc.
Uma classe é uma entidade quando contem informações recebidas ou geradas por meio do sistema.
Normalmente possuirão muitos objetos e que estes possivelmente terão um longo período de vida. Isto pode ser interpretado como uma indicação que estas serão total ou parcialmente preservadas (por tempo de vida, não em banco de dados)
Estereótipos do Diagrama de Classes
Classes tipo <<persistent>>
Com este estereótipo estamos indicando que 100% das propriedades serão preservadas. Isso praticamente implica no uso de banco de dados.
Exemplo: <<persistent>>Conta Comum
#nrConta: long#vlSaldo: double#tipo: int
+abertura(saldo:double, tipo:int):long+encerramento():int+saque(valor:double):int+deposito(valor:double):double
Estereótipos do Diagrama de Classes
Classes tipo <<boundary>>
Identifica uma classe que serve de comunicação entre atores externos e o sistema propriamente dito.
Identifica classes cujo papel é realizar o interfaceamento com entidades externas (atores) . Este tipo de classe contém o protocolo necessário para comunicação com atores como impressora, monitor, teclado, disco, porta serial, modem etc.
Uma classe de importação de tabelas de um sistema para outro também é um exemplo de classe <<boundary>>.
Estereótipos do Diagrama de Classes
Classes do tipo <<control>>
Objetos <<control>> são responsáveis por interpretar os eventos ocorridos sobre os objetos <<boundary>>, como os movimentos do mouse, o pressionamento de um botão e retransmití-los para objetos das classes de entidades que compõem o sistema.
Identifica classes cujo papel é controlar a execução de processos. Estas classes contém, normalmente, o fluxo de execução de todo ou parte de casos de uso e comandam outras classes na execução de procedimentos.
<<boundary>>Interface do Caixa Eletrônico
<<control>>Controlador do Caixa
Eletrônico
Levantando Classes a Partir de um UC
Cadastrar Aluno
Secretária SGBD
Regra 1: Uma classe para cada ator:
<<boundary>>CInterfaceSecretaria
<<boundary>>CInterfaceSGBD
Levantando Classes a Partir de um UC
Uma classe de controle para gerenciar o cadastro como um todo
(Regra 2)
Três classes (detalhamento) estendidas de CControleCadAluno (Regra 3)
<<control>>CControleCadAluno
<<control>><<extend>>
CControleIncluiAluno
<<control>><<extend>>
CControleAlteraAluno
<<control>><<extend>>
CControleExcluiAluno
Levantando Classes a Partir de um UC
Uma classe de entidade para cuidar do aluno. Como o SGBD não é uma entidade real, não é necessário criar uma classe para ele. (Regra 4.)
<<entity>>CAluno
Diagrama de Classes
Representação de uma classe
Forma reduzida:
Forma completa:
NomeClasse
NomeClasse(Atributos)
(Procedimentos)
Representação dos atributos
Símbolos usados:Público ............................ +Privado ............................ -Protegido ......................... #Não modificável ................ /
Diagrama de Classes
NomeClasse+nome: String-dataNascimento: Data#altura: inteiro/idade: inteiro
Diagrama de Classes
Representando os procedimentos
NomeClasse+nome: String-dataNascimento: Data#altura: inteiro/idade: inteiro
+getIdade() : Inteiro +setNome(String nome)+getNome() : String+setAltura(Inteiro altura)+getAltura() : Inteiro
Associações de classes
Simples ou Binária: Exemplo: Produto e Fornecedor em uma classe de
ItensPedido. Composição:
Exemplo: Motor de um avião. Um avião não é um avião sem motor. Uma cadeira não é uma cadeira sem os pés (Mas é uma cadeira sem os braços – Os braços não compõem a cadeira – são agregados).
Agregação: Exemplo: Um clube (e seus sócios), um colégio (e seus
alunos) , um departamento de uma empresa (e seus funcionários).
Herança: Exemplo: Mamífero é superclasse de Primata. Primata é
superclasse de Ser Humano
A seguir veremos cada uma em detalhe…
Associações de classes
Simples ou binária
Clientes Locação Títulos 1 ... *
1 Não mais que uma
0…1 Nenhuma ou uma
* Muitas
0..* Nenhuma ou muitas
1…* Uma ou muitas
Composição Principais Características das Composições:
O objeto composto não existe sem seus componentes. À parte de um objeto composto não poderá pertencer a
mais de um objeto composto. A composição é sempre tipicamente heterogênea.
Fuselagem + Cauda + Asa(s), compõem 100% do planador.
Planador
Fuselagem Cauda Asa
fuselagem1 cauda 1 asaEesquerda asaDireita11
Exemplo de composição
Revista Científica
+registrar()+consultar(ISSNRev: long): int
-ISSNRev : long-titRev : String-periodicidadeRev:String
Edição
+registrar() : int+consultar(nroEdi: int, volEdi: int) : int
-nroEdi: int-volEdi: int-datEdi: Data-tiragemEdi: int
Artigo
+registrar()+consultar()
-titArt : String-pagIniArt : int
1.. *
Contém
5..10
Publica
A classe RevistaCientífica refere-se à no mínimo um objeto da classe Edição, podendo referir-se a muitos objetos desta classe, e que cada instância de classe Edição relaciona-se única e exclusivamente a uma instância específica da classe Revista Científica, não podendo relacionar-se com nenhuma outra.
O que acontece com a relação entre a classe Artigo e Edição ?
Agregação
Cacterísticas: O objeto agregado pode potencialmente existir
sem seus objetos constituintes. (pode existir uma empresa sem funcionários – E uma floresta sem árvores ?)
Um objeto pode ser constituinte de mais de um agregado. (uma pessoa pode trabalhar em mais de uma empresa)
As agregações tendem a ser homogêneas. (Normalmente são implementadas como arrays)
Agregação - Representação
RelatororioDeGerencia
Parágrafo
0..*
0..*parteDoTexto
{ordenado}
Usamos um pequeno losango vazio (diamante) na extremidade da linha de associação do agregado próximo ao agregado.
Agregação - ExemploPedido
-nroPedido : long-datPedido : date-datEntPedido:date
I tens Pedido
-qtdI tem : double-valUniI tem : double
Produto
-desPro : String-qtdPro : double-valPro : double
1.. *
Compõe
1.. *A agregação existe apenas entre a classe Pedido e a classe ItensPedidos (veja o losango no lado do Pedido).
A classe Produto possui apenas uma associação binária comum com a classe itens Pedido.
Note que os itens do pedido não podem existir sem que um pedido os tenha gerado.. Veja que a classe Produto não depende de Pedido nem de Itens Pedido.
Um diagrama de classes...
1 .. *
Pessoa
Professor Aluno
Faculdade Curso
Disciplina
0 .. *
1 .. *
1 .. *
0 .. * 0 .. *
1 .. *
1 .. *
O Diagrama de Seqüência
Até aqui não era relevante a ordem em que as coisas aconteciam.
Este Diagrama procura determinar: Ordem dos métodos para serem executados Condições devem ser satisfeitas e quais
A base para o Diagrama de Seqüência é o Diagrama de Caso de Uso.
Um caso de uso pode gerar um ou mais diagramas de seqüência
Normalmente temos um Diagrama de Seqüência para cada processo específico do sistema.
Nem sempre um Caso de Uso gera obrigatoriamente um Diagrama de Seqüência.
Nada impede que se defina um Diagrama de Seqüência exclusivo para um Caso de Uso utilizado por outros Casos de Uso através da associação <<include>>.
Componentes do Diagrama de Seqüência
Atores Objetos Linha da Vida Foco de Controle ou Ativação Mensagens ou Estímulos
Informativas Interrogativas Imperativas Auto chamadas
Atores
São exatamente os mesmos do Diagrama de Casos de Uso
Os atores são representados também como bonecos magros mas agora com uma barra sob ele. (Linha da vida)
Cliente
Objetos
Objetos representam instâncias das classes envolvidas no processo.
Os objetos são representados como retângulos contendo um texto que identifica o nome do objeto, em minúsculo, e depois o nome da classe, com letras iniciais maiúsculas. Ambos são separados entre si por um caractere : (dois pontos). Abaixo do objeto desenhamos uma linha pontilhada que representa também sua linha de vida.
pessoa1:PessoaFisica
Linha da Vida
Representa o tempo em que um objeto existiu durante um processo.
Alinha de vida é interrompida com um “X” quando o objeto é destruído.
Um objeto não precisa necessariamente existir quando o processo é iniciado podendo ser criado a qualquer momento durante o processo.
Representamos a existência ou não do objeto por segmento mais encorpado do segmento da linha de vida.
Foco de Controle ou Ativação
São retângulos finos sobrepostos sobre a linha pontilhada, representando o tempo em que um determinado objeto está ativo, ou seja, recebeu uma mensagem e está em processamento.
4: Validar CPF: ValCPF
1: Consulta cliente:ConCPF()
2: [se necessário] Dados do Cliente
3: [se necessário] Atualizar:Gravar()
5: Cliente atualizado
pessoa1:PessoaFisica Banco
Mensagens ou Estímulos Informativas
void setMatricula (String matricula); void setLimite (double valor);
Interrogativas (ou de retorno) double getSalario (); String getMatricula();
Imperativas void imprimeAluno (); void enviaDadosLinha(); void clear();
Auto chamadas (ou Auto delegações) São chamadas que um objeto envia para si mesmo.
Normalmente um método utilitário privado. Um método de check digit ou criptografia podem ser exemplos de auto delegação.
Condições de Guarda (if)
Indicam que uma mensagem só poderá ser enviada a um objeto se uma determinada condição for verdadeira.
As condições são descritas normalmente entre colchetes na mensagem, mas podem também ser representadas por meio de restrições.
Os operadores de interação são praticamente fragmentos de código (ou pseudocódigo) representados no diagrama.
Condições de Guarda (Exemplo)
DS Login
Região Crítica
[Se início de trabalho]
TerminaTrabalho(operador, maquina);
AutoDeteccaoProblema();
AcionaManutencao();
a:Operador ca:Manutencao b:Maquina
[Se término trabalho]
IniciarTrabalho (operador, maquina)
Um exemplo completo...
hist1:Historico
13: Abertura de conta concluída
10 : Registrar histórico : Gravar()
Cliente Bancopessoa1:PessoaFisica
conta1:ContaComum
1: Solicita Abertura de conta
7: Pedido aprovado
8: Fornecer valor de depósito e
senha
2: Consulta cliente:
ConsultaCPF()3: [Se existir] Dados do Cliente
4: [Se necessario] Atualizar: Gravar() 5: Validar CPF: ValCPF()
9: Abrir conta:Abertura()
6: Cliente atualizado
11: Histórico registrado OK12: Número de conta gerada