UML - Unifield Modeling Language- 2010

UML – Unifield Modeling Language

UML – Um enfoque prático

Depósito

Cliente

<<include>>

Saque

Registrar movimento

Banco

<<include>>

[email protected]

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.


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.


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


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


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.


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.


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.


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.


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)


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


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


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


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


CControleAlteraAluno


CControleExcluiAluno


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

UML - Unifield Modeling Language- 2010

Documents

Transcript of UML - Unifield Modeling Language- 2010