Weitere ähnliche Inhalte Ähnlich wie Análise e Projeto de Sistemas (20) Análise e Projeto de Sistemas1. Introdução a UML
Definição (1/2)
• A UML (Unified Modeling Language) é:
– Linguagem de modelagem utilizada para especificar,
visualizar, construir e documentar os artefatos de um
Análise e Projeto de Sistemas sistema de software;
– Unificação das notações dos métodos de Booch,
OMT e OOSE, assim como as melhores idéias de um
grupo de metodologistas;
– Padrão industrial para a modelagem em todo o ciclo
Aula expositiva 04 de desenvolvimento de software.
– Sistema de notação dirigido à modelagem de
sistemas orientados a objetos.
Professor José Luiz Bastos – Captura a estrutura de sistemas orientados a objetos e
utiliza diversos diagramas para expressá-la e
fornecer múltiplas visões daqueles.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Definição (2/2) Modelagem visual (1/3)
• A UML tem se tornado um padrão mundial utilizado • Veja a seguinte descrição:
por desenvolvedores, autores e fornecedores de
– A classe Aluno possui os seguintes atributos:
ferramentas CASE, pois procura integrar as
melhores práticas existentes no mercado para matrícula (string), nome (string), data de nascimento
especificar, visualizar e construir os artefatos de (date), data de matrícula (date), valor da mensalidade
sistemas de software. (real);
• A UML é aplicável em: – E as seguintes operações:
– Modelagem de processos de negócio; matricular aluno, reajustar mensalidade (que recebe
– Modelagem de casos de uso; como parâmetro o percentual de reajuste), trancar
– Modelagem de classes e objetos; matricula, emitir boleto de pagamento (que recebe
– Modelagem de interação entre objetos; como parâmetro o mês/ano de referência).
– Modelagem de componentes;
– Modelagem de implantação de componentes.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
1
2. Introdução a UML
Modelagem visual (2/3) Diagramas da UML 2.0
• Cada diagrama da UML tem como objetivo
analisar o sistema sob uma perspectiva.
• Alguns apresentam uma visão externa do
sistema, outros apresentam uma visão mais
interna do sistema com características mais
técnicas ou detalhadas de partes do mesmo.
• Os diferentes diagramas da UML permitem a
descoberta de erros e a avaliação da
integração entre os modelos do sistema
ainda em projeto.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso
• Esse diagrama é utilizado para representar a
especificação funcional do sistema e se popularizou
devido à sua notação gráfica simples e à sua
descrição em linguagem natural, já que o seu
propósito primário é descrever as funções essenciais
do sistema, o seu comportamento dinâmico, bem
como os seus limites e abrangência.
• Ajuda a especificar, visualizar e documentar as
características, funções e serviços do sistema
através da perspectiva do usuário e de uma
linguagem simples, possibilitando a compreensão do
comportamento externo do sistema por qualquer
pessoa.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
2
3. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• As características anteriores permitem que o
diagrama de casos de uso seja utilizado nas
etapas de Levantamento e Análise de
Requisitos e que seja apresentado durante
as reuniões iniciais com os clientes, como
uma forma de ilustrar o comportamento do
sistema, facilitar a compreensão dos usuários
e auxiliar na identificação de possíveis falhas
de especificação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Ementa desta aula: SISTEMA:
– Sistema;
– Requisitos do Sistema;
– Caso de Uso;
– Fluxos do Caso de Uso;
– Fronteira do Sistema;
– Ator;
– Lista de Atores;
– Relacionamentos;
– Documentação de Casos de Uso;
– Requisitos Não Funcionais;
– Engenharia de Requisitos.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
3
4. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Requisitos do Sistema: • Desenvolvedor:
– Um requisito descreve uma condição com a qual o sistema – O que o é esperado desse sistema?
deve estar conforme; • Usuário:
– Esta condição pode ser uma necessidade dos usuários,
– Eu tenho uma loja de peças. Gostaria que o meu processo
estabelecida em um contrato, uma norma ou padrão, uma
de vendas fosse interligado com meu estoque e que eu
especificação, formalizado em algum documento;
pudesse, a qualquer momento, alterar valores das formas
– UML: Um requisito é uma funcionalidade desejada, uma de pagamento. Posso oferecer descontos a alguns tipos de
propriedade ou um comportamento do sistema; clientes, mas preciso autorizar essa operação.
– Uma vez que o Analista levante os requisitos com o usuário, – No fim do mês quero um relatório dos produtos que mais
é necessário documentá-los para entendimento e validação; venderam. Preciso também saber a estatística de vendas
– Essa documentação deve servir de base não ambígua para por forma de pagamento.
toda a equipe de desenvolvimento; – De tempos em tempos deve aparecer na tela do sistema
– A documentação de requisitos evita que informações uma promoção relâmpago que dê um brinde ao cliente.
importantes se percam. – Preciso que o sistema controle os pedidos também.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• O que é ambíguo ou não compreensível • Utilizando a modelagem de casos de uso, o
nessa descrição? desenvolvedor deve separar as
– Que tipos de clientes podem receber descontos? funcionalidades do sistema;
– Como seria feita esta autorização de desconto e por • Essas funcionalidades agrupam um conjunto
quem?
de ações que tenham um objetivo bem
– Que quantidade de produtos deve aparecer no
relatório dos mais vendidos? definido;
– A estatística leva em conta qual período (semanal, • Os casos de uso representam essas
quinzenal, mensal, etc.)? funcionalidades.
– Quanto tempo significa “de tempos em tempos”?
– Quais pedidos precisam ser controlados: os dos
clientes ou os feitos aos fornecedores?
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
4
5. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
Algumas funcionalidades que caberiam
para o exemplo dado:
• Sistema de Vendas:
– Consultar informações sobre um produto;
– Efetuar reserva;
– Emitir comprovante de reserva;
– Efetuar venda;
– Emitir nota fiscal;
– Realizar fechamento do caixa.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Cada caso de uso possui um conjunto de
ações que precisam ser executadas para que
o objetivo da funcionalidade seja alcançado;
• No caso de efetuar venda: identificar o
vendedor, identificar o produto, a quantidade
vendida, etc;
• Essas ações constituem os fluxos que são
realizados pelos casos de uso para
disponibilizar o resultado desejado.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
5
6. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Fluxo principal: Exemplo: Caso de Uso “Emitir Saldo”:
– Descreve uma seqüência de ações que serão Fluxo principal:
executadas, considerando que nada de errado
1. O sistema realiza a leitura do cartão
ocorrerá durante a execução da seqüência (o
chamado caminho “feliz” do caso de uso); magnético do correntista;
– Apenas 1 por caso de uso; 2. O sistema solicita a digitação da senha;
3. O sistema valida a senha digitada;
• Fluxos alternativos: 4. O correntista seleciona a opção de saldo;
– Representam sub-itens do fluxo principal; 5. O sistema questiona o tipo de saldo: conta
– Representam os tratamentos de exceção; corrente, poupança, aplicações;
– Nenhum ou vários por caso de uso. 6. O sistema processa e mostra o saldo
solicitado pelo cliente.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
Fluxo alternativo Problema na leitura do cartão Fluxo alternativo Senha inválida:
magnético:
1. Se o sistema não conseguir ler os dados do 1. Se a senha digitada pelo correntista não for
cartão magnético, tentar novamente por, no igual à senha cadastrada no sistema,
máximo, mais duas vezes; informar ao mesmo e solicitar nova digitação.
2. Caso persista o problema, encerrar o caso Esse processo pode ser repetido por no
de uso. máximo três tentativas (incluindo a primeira).
Após a terceira tentativa, a conta do usuário
deve ser bloqueada e o caso de uso
encerrado. Inclusão: Bloquear Conta.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
6
7. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
Fluxo alternativo Conta inexistente: TENHA EM MENTE!!!!
• Ao modelarmos um sistema, precisamos
saber até que ponto devemos nos preocupar;
1. Se o correntista não possuir o tipo de conta
selecionada, informar ao mesmo e encerrar o • Esses pontos-limite são a fronteira do
sistema. Exemplo:
caso de uso.
– Imagine que estamos modelando um Sistema de
Controle de Vendas;
– Em algum momento o Sistema de Controle de Vendas
emite o faturamento semanal ou mensal de cada
vendedor para o Departamento Pessoal;
– Não é responsabilidade do Sistema de Controle de
Vendas saber o que o Departamento Pessoal fará
com essa informação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Os sistemas recebem e enviam informações
FRONTEIRA para o mundo externo através de suas
fronteiras;
• Alguém ou algo deve ser responsável por
enviar e/ou receber informações do sistema;
• Na modelagem de casos de uso, esse papel
externo é exercido por um ator. Esse ator
representa um papel que pode ser:
– Uma pessoa;
– Um grupo de pessoas;
– Um outro sistema;
– Sensores.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
7
8. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Ator: • Um ator representa um papel exercido por
– Representa qualquer coisa que interaja com o sistema, um usuário ou outro sistema ao interagir com
ou seja, que troque dados ou eventos com o sistema; o sistema em questão. Exemplo:
– Atores não fazem parte do sistema; – Uma pessoa (João) pode assumir o papel de cliente
– Atores podem ser usuários ou outros sistemas; ao realizar um saque em um caixa de auto-
– Atores identificam elementos externos ao sistema; atendimento;
– Atores delimitam as fronteiras do sistema; – A mesma pessoa (João) pode assumir o papel de
– Atores podem ativar os casos de uso ou não. operador ao realizar a manutenção de um caixa de
auto-atendimento.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Outro exemplo:
– Em um Sistema de Controle Acadêmico, a rotina de
atualizar a frequência dos alunos pode ser executada
pelos funcionários da secretaria, pelo próprio professor
ou pelo Sistema de Avaliação On-line;
– Esses papéis são representados por atores.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
8
9. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Casos de uso: • Casos de uso:
– Devem descrever uma rotina bem definida do sistema; – Devem identificar com quais atores interagem, com
– Devem ser totalmente compreensíveis pela equipe e isso o projetista tem informação para criar os perfis de
pelos usuários; acesso ao sistema;
– Devem ser utilizados durante todo o processo de – Devem especificar como alcançar a realização de um
desenvolvimento: procedimento, sem relacionar detalhes de
• Criação dos modelos de análise e projeto; implementação;
• Criação dos modelos de implementação; – Exemplo:
• Criação das especificações de testes do sistema. • O cliente seleciona na lista o produto desejado.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Relacionamentos: Relacionamentos:
– Não devem representar validações que todo sistema já • Entre casos de uso:
possuir por padrão:
– Generalização;
• Exemplo: checar se a data é uma data válida do
calendário; – Extensão;
– Inclusão;
– Devem expressar validações que refiram às regras de
negócio; • Entre atores:
• Exemplo: a data de rescisão do contrato deve estar – Generalização;
dentro do mês corrente;
– Pode-se iniciar a modelagem por uma lista de casos • Entre atores e casos de uso:
de uso ou uma lista de atores. – Associação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
9
10. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Associação:
– Ocorre entre um ator e um caso de uso;
– Representa a interação do ator com o caso de uso.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Extensão: • Exemplo: Caso de Uso “Efetuar Venda”;
– Ocorre entre casos de uso; Fluxo Principal:
– Indica que um deles (caso de uso base) terá seu 1. ...
procedimento acrescido no ponto de extensão 2. Escolher a forma de pagamento;
especificado; 3. Se cliente VIP, calcular desconto especial;
– Os pontos de extensão são rótulos que aparecem nos Extensão: Efetuar desconto especial;
fluxos dos casos de uso;
4. Apresentar o valor total;
– É permitido colocar diversos pontos de extensão no
mesmo caso de uso. 5. ...
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
10
11. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Quando usar pontos de extensão: • Exemplo: no cadastro de uma venda, a rotina
– Para expressar rotinas de exceção; de desconto só pode ser executada pelo
– Para expressar fluxos alternativos; gerente.
– Para separar um comportamento obrigatório de outro
opcional;
– Para separar um trecho do caso de uso que será
usado somente em determinadas condições;
– Para separar trechos que dependam da interação com
um determinado ator.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Inclusão: • Exemplo: Caso de Uso “Matricular nos
– Ocorre entre casos de uso; cursos”;
– Indica que um deles terá o seu procedimento copiado Fluxo Principal:
em um local especificado em outro caso de uso; 1. ...
– São usados quando existem ações que servem a mais 2. O aluno digita a sua matrícula;
de um caso de uso;
3. O sistema verifica se a matrícula é válida e ativa;
– Evita a cópia de trechos idênticos nos fluxos de mais
Inclusão: Validar matrícula;
de um caso de uso;
4. Se matrícula é válida o sistema apresenta nos cursos;
– Ganha-se tempo em modelagem, implementação e
manutenção. 5. …
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
11
12. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Generalização:
– Ocorre entre casos de uso ou entre atores;
– Representa dois elementos semelhantes com um
deles realizando um pouco mais;
– É o mesmo conceito de herança da orientação a
objetos:
• Um caso de uso no qual C2 herda de C1, significa que
C1 é mais genérico e C2 é mais específico;
– Exemplo de generalização entre atores:
• Aluno, Aluno Matriculado, Aluno Ouvinte.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
IMPORTANTE:
• Os atores representam os papéis realizados pelos
usuários, e não a pessoa do usuário;
– Certo: Gerente, Funcionário, Estudante, Professor;
– Errado: Pedro, João, Maria, José.
• Uma vez identificado o caso de uso, descreva seu
fluxo principal;
• A partir do fluxo principal identifique e descreva os
fluxos alternativos;
• Caso descubra fluxos comuns utilize inclusão;
• Para casos de uso muito complexos utilize extensão.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
12
13. Diagramas da UML 2.0 Diagramas da UML 2.0
Diagrama de Caso de uso Diagrama de Caso de uso
• Organizando o modelo com pacotes: • Organizando o modelo com pacotes:
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas da UML 2.0
Diagrama de Caso de uso
• Organizando o modelo com pacotes:
Análise e Projeto de Sistemas
Aula expositiva 05
Professor José Luiz Bastos
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
13
14. Introdução a UML
Introdução Diagrama de classes (1/36)
• O diagrama de classes é considerado o mais • Uma classe é representada por um retângulo
importante diagrama da UML, pois serve de com três seções:
base para a maioria dos outros diagramas – Nome da classe;
desta linguagem de modelagem. Ele oferece – Atributos;
uma visão estática do sistema que permite a – Operações.
visualização das classes que o compõem,
seus atributos e as operações, bem como os
relacionamentos entre as mesmas.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (2/36) Diagrama de classes (3/36)
• Proteção de dados visa garantir o acesso • Um atributo é uma propriedade de uma
apenas sobre operações e atributos classe que descreve um conjunto de valores
disponibilizados pela interface da classe; que as instâncias da classe, objetos, podem
– Modificadores de acesso: Public (+); atribuir a essa propriedade.
– Protected (#);
– Package (~);
– Private (-).
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
14
15. Introdução a UML Introdução a UML
Diagrama de classes (4/36) Diagrama de classes (5/36)
• Um atributo derivado é um atributo cujo • Um atributo estático é um atributo cujo valor
valor pode ser calculado baseado no valor de é compartilhado por todas as instâncias,
outro(s) atributo(s): objetos, da classe:
– Atributo objA.média. – Atributo Funcionário.PISO_SALARIAL.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (6/36) Diagrama de classes (7/36)
• Um atributo não estático possui um valor • Uma operação é um serviço que pode ser
único para cada objeto, instância da classe: requisitado por qualquer objeto da classe
– Atributo objA.nome. para obter um comportamento:
– Operação objA.obterNome().
Operações
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
15
16. Introdução a UML Introdução a UML
Diagrama de classes (8/36) Diagrama de classes (9/36)
• Uma operação abstrata é aquela que não • Uma operação estática é independente de
possui um método que a implemente na objeto e acessa apenas atributos estáticos;
classe: • O acesso a operações estáticas é
– Operação objA.obterIdade(); independente de objeto:
• Uma classe que possui uma ou mais – Funcionário.obterPisoSalarial().
operações abtratas é dita classe abstrata:
– Classe Pessoa.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (10/36) Diagrama de classes (11/36)
• Um estereótipo define um novo elemento de • A especialização de objetos segundo os 3
modelagem em termos de um elemento estereótipos propostos por Jacobson auxilia
inicial; na construção de sistemas fáceis de serem
• Algumas vezes é necessário acrescentar estendidos e alterados;
novos elementos ao modelo para torná-lo • Estereótipos propostos por Jacobson:
mais aderente ao domínio da aplicação; – Fronteira;
• Os novos elementos são definidos a partir – Controle;
– Entidade.
dos elementos primitivos já existentes na
UML.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
16
17. Introdução a UML Introdução a UML
Diagrama de classes (12/36) Diagrama de classes (13/36)
• Uma classe de fronteira modela a
comunicação entre a vizinhança de um
sistema e seus componentes internos;
• As classes de fronteira provêem a interface
com o usuário ou outro sistema;
• Classes de fronteira típicas:
– Janelas e relatórios (interface com o usuário);
– Protocolos de comunicação (interface com o sistema);
– Interface com dispositivos de hardware.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (14/36) Diagrama de classes (15/36)
• Classes de entidade: • Classes de controle:
– Modelam itens importantes de informação: – Modelam o comportamento de controle específico a
• Geralmente são as primeiras levantadas na análise dos um ou mais casos de uso.
fluxos dos casos de uso; – Criam, iniciam e excluem objetos controlados;
– Tipicamente independentes da aplicação; – Coordenam a ação dos objetos controlados;
– Tipicamente essenciais:
• Necessárias para cumprir alguma responsabilidade do
produto; • Exemplos:
– Freqüentemente persistentes: – Controlador de conexão;
• Correspondem a entidades de bancos de dados. – Controlador de impressão;
– Controlador de matrícula;
– Controlador de pedido;
– Controlador de faturamento.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
17
18. Introdução a UML Introdução a UML
Diagrama de classes (16/36) Diagrama de classes (17/36)
• Classe abstrata: • Interfaces: O propósito de uma interface é
– O nome da classe aparece em itálico: encapsular um conjunto de operações
• Classe Pessoa. oferecidas pela classe;
– É comum apresentarmos na interface apenas parte
das operações;
– A interface especifica a assinatura das operações;
– O relacionamento utilizado é o de realização.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (18/36) Diagrama de classes (19/36)
• Uma outra classe que use ou requeira • Nome de relacionamentos:
operações supridas pela interface é ligada a – É mostrado próximo à linha do relacionamento, de
esta por uma dependência. forma centralizada;
– Deve ser um nome que exprima o significado do
relacionamento.
– Pode também ser um verbo, desde que esteja claro
qual é o sujeito e qual é o objeto.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
18
19. Introdução a UML Introdução a UML
Diagrama de classes (20/36) Diagrama de classes (21/36)
• Papéis em relacionamentos: • Multiplicidade é o número de instâncias
– Um papel denota o propósito ou capacidade em que possíveis em um relacionamento entre
uma classe se associa com outra; classes (é o número de instâncias de uma
– O nome de um papel é colocado ao longo da linha de classe relacionada a uma instância de outra
associação, próximo à classe referenciada;
classe);
– Um ou ambos os lados da associação podem ter
nomes de papéis.
• Para cada relacionamento devem ser
tomadas duas decisões de multiplicidade:
uma para cada lado da associação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (22/36) Diagrama de classes (23/36)
• Consiste de um conjunto de números inteiros
não-negativos;
• Se contiver um asterisco *, ele significa uma
faixa infinita de números inteiros não-
negativos;
1 ou 1..1 = exatamente 1
0..* = zero ou mais
1..* = um ou mais
0..1 = zero ou um
5..8 = intervalo específico
4..7, 9 = combinação (4,5,6,7,9)
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
19
20. Introdução a UML Introdução a UML
Diagrama de classes (24/36) Diagrama de classes (25/36)
• Navegabilidade:
– Os relacionamentos podem ser bidirecionais ou
unidirecionais;
– Uma seta é adicionada ao relacionamento quando a
navegação vem apenas em uma direção;
– Quando a seta é omitida a navegação é desconhecida
ou é bidirecional;
– Exemplo: Um eleitor deve saber em quem votou, mas
o candidato não deve saber quem votou nele.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (26/36) Diagrama de classes (27/36)
• Associação binária conecta duas classes; • Associações reflexivas são associações de
uma classe com ela própria.
• Associação n-ária possui três ou mais
classes ligadas pelo relacionamento.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
20
21. Introdução a UML Introdução a UML
Diagrama de classes (28/36) Diagrama de classes (29/36)
• Uma restrição XOR indica que apenas uma • Uma classe de associação é responsável
dentre as várias associações representadas por dados e comportamento de uma
pode ocorrer. Ambas não podem ocorrem ao associação;
mesmo tempo. • De um modo geral, surge como responsável
por atributos/serviços, resultado de um
relacionamento n-n entre duas classes.
OU
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (30/36) Diagrama de classes (31/36)
• Agregação é uma forma especial de • Agregações reflexivas são agregações de
associação onde o todo está relacionado às uma classe com ela mesma.
suas partes.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
21
22. Introdução a UML Introdução a UML
Diagrama de classes (32/36) Diagrama de classes (33/36)
• Composição indica ciclos de vida • Composições reflexivas são composições de
dependentes. uma classe com ela mesma;
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Introdução a UML Introdução a UML
Diagrama de classes (34/36) Diagrama de classes (35/36)
• Herança simples: • Herança múltipla:
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
22
23. Introdução a UML
Diagrama de classes (36/36)
• Dependências:
Análise e Projeto de Sistemas
Aula expositiva 06
Professor José Luiz Bastos
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Objetos (1/5) Diagrama de Objetos (2/5)
• Representa uma instância de um Diagrama • Deve mostrar apenas os objetos relevantes
de Classes em um determinado contexto; em um determinado contexto;
• Pada cada classe temos um objeto (sua • Notação UML para objetos:
instância); – nomeDoObjeto : nomeDaClasse;
• É útil para:
– Visualizar mais claramente a relação entre os objetos
das classes;
– Visualizar dados reais;
– Validar o modelo de classes;
– Identificar problemas na execução de uma aplicação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
23
24. Diagrama de Objetos (3/5) Diagrama de Objetos (4/5)
• Notação UML para atributos dos objetos: • Relacionamentos entre os objetos são feitos
nomeDoAtributo: tipo = valor; através de links;
• Se o tipo for citado, deve ser o mesmo da • Um link éuma instância de uma associação;
classe, mas pode ser omitido; • O nome do papel pode ser mostrado ao final
• Atributos cujos valores podem mudar durante do link;
o processamento apresentam uma lista de • O nome da associação pode ser mostrado
valores. próximo ao link;
• Multiplicidades não são mostradas pois os
links já são instâncias;
• Agregação, composição e navegação podem
ser mostradas.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Objetos (5/5) Diagrama de Atividades (1/12)
• Aplicação:
– Modelagem de workflow;
– Modelagem de processamento paralelo;
– Modelagem de fluxos de casos de uso;
– Descrição de algoritmos seqüenciais;
• Não devem ser usados em:
– Modelagem de comportamento de objetos (usar os
diagramas de interação neste caso) ;
– Modelagem do ciclo de vida de objetos (usar o
diagrama de estados neste caso).
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
24
25. Diagrama de Atividades (2/12) Diagrama de Atividades (3/12)
• Uma atividade é um estado de realização de • Comportamento condicional:
algo: – É delineado por desvios e intercalações;
– Um processo do negócio; – Desvio:
– Uma rotina de software; • Uma transição de entrada;
• Várias transições de saída guardadas;
• Somente uma transição de saída pode ser tomada;
• Um Diagrama de Atividades:
– Descreve uma seqüência de atividades;
– Suporta comportamento condicional e paralelo. – Intercalação:
• Múltiplas transições de entrada;
• Uma transição de saída;
• Marca o final de um desvio.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Atividades (4/12) Diagrama de Atividades (5/12)
• Comportamento paralelo:
– É indicado por separações e junções;
– Separação:
• Uma transição de entrada;
• Várias transições de saída;
• Uma transição de entrada dispara todas as transições de
saída;
– Junção:
• Múltiplas transições de entrada;
• Sincroniza as atividades que acontecem em paralelo;
• Separação e junção devem se completar.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
25
26. Diagrama de Atividades (6/12) Diagrama de Atividades (7/12)
• Thread condicional:
– Atividade com uma condição de guarda antes;
– Se a condição for falsa a atividade é considerada
completada;
– Permite que junções sejam feitas sem que atividades
paralelas sejam executadas.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Atividades (8/12) Diagrama de Atividades (9/12)
• Subatividades:
– Uma atividade pode ser dividida em subatividades;
– Pode-se usar estados de início e fim no subdiagrama;
– Pode-se projetar transições diretamente para dentro
ou para fora do subdiagrama.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
26
27. Diagrama de Atividades (10/12) Diagrama de Atividades (11/12)
• Raias:
– Dizem quem faz o quê;
– Deve-se organizar o diagrama em zonas verticais
separadas por linhas;
– Cada raia representa a responsabilidade de uma
classe, ator, departamento, etc.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Atividades (12/12)
Análise e Projeto de Sistemas
Aula expositiva 07
Professor José Luiz Bastos
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
27
28. Diagrama de Estados (1/19) Diagrama de Estados (2/19)
• O Diagrama de Estados descreve o • Estado:
comportamento de objetos em relação a – É uma condição detectada durante o ciclo de vida de
eventos; um objeto quando ele:
• Satisfaz alguma condição;
• Apresenta uma seqüência de estados e • Realiza alguma atividade;
ações que ocorrem durante a vida do objeto, • Aguarda por algum evento;
em resposta a eventos;
• O Diagrama de Estados mostra o ciclo de – O Estado de um objeto é uma das possíveis condições
vida de um objeto, ou seja, seus estados, os nas quais ele pode existir durante a sua vida.
eventos que causam a transição de um
estado para outro e as ações que resultam
de uma mudança de estado.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Estados (3/19) Diagrama de Estados (4/19)
• Um estado é representado graficamente Compartimentos:
como um retângulo com cantos • Um estado pode ser opcionalmente
arredondados; subdividido em compartimentos:
• O nome do estado é colocado no centro do – Compartimento de Nome:
mesmo. • Armazena o nome do estado, como uma string;
– Compartimento de transições internas:
• Armazena uma lista de ações ou atividades internas que
são executadas enquanto o objeto se apresenta no
estado em questão.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
28
29. Diagrama de Estados (5/19) Diagrama de Estados (6/19)
• Estados x atributos:
– O estado de um objeto pode ser caracterizado pelo
valor de um ou mais de seus atributos.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Estados (7/19) Diagrama de Estados (8/19)
• Estados podem ser caracterizados pela • Estado inicial:
existência de um relacionamento com outro – Indica o local de início do diagrama de estados;
objeto; – Cada diagrama deve possuir um e apenas um estado
inicial(exceto para diagramas aninhados);
• Representação: Um círculo preenchido.
• Diagrama de estados da classe Professor:
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
29
30. Diagrama de Estados (9/19) Diagrama de Estados (10/19)
• Estado final: • Transição:
– Indica o fim da existência de um objeto ou o final da – Relacionamento entre dois estados;
realização de uma atividade (para diagramas – Indica que haverá uma mudança de estado e que
aninhados); determinadas ações serão executadas;
– Um diagrama pode ter múltiplos estados finais. – Pode ocorrer como resultado de algum evento.
– Pode ter que satisfazer a alguma condição;
– O estado sucessor pode ser o estado original;
– É representada com uma seta do estado de origem
para o estado de destino.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Estados (11/19) Diagrama de Estados (12/19)
assinaturaDoEvento [condiçãoDeGuarda] / expressãoAção
• [condiçãoDeGuarda]
– Quando verdadeira, permite que a transição seja feita;
– Só é avaliada depois que o evento ocorre;
– Várias transições a partir do mesmo estado de origem,
identificadas com o mesmo evento, se diferenciam
pela condição de guarda;
– É colocada entre colchetes;
• Exemplo:
Checar Estoque [estoqueAtual <= EstoqueMínimo]
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
30
31. Diagrama de Estados (13/19) Diagrama de Estados (14/19)
assinaturaDoEvento [condiçãoDeGuarda] / expressãoAção
• expressãoAção:
– Somente é executada no início da transição, se esta
ocorrer;
– Pode ser descrita com operações;
– É precedida por uma barra /;
• Exemplo:
– Nota lançada [nota = 7.0] / FechaProvasRegulares()
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Estados (15/19) Diagrama de Estados (16/19)
• Transições internas: • Atividade:
– Atividades associadas ao estado e que devem ocorrer – É uma operação que leva tempo para terminar;
na entrada, na permanência, ou na saída do mesmo; – São associadas a um estado;
– São associadas com qualquer transição entrando ou – Começa quando o objeto entra no estado;
saindo do estado; – Pode executar até terminar ou pode ser interrompida
– São mostradas dentro do ícone do estado precedidas pelo disparo de uma transição.
pela palavra “entry”, “exit”ou “do”.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
31
32. Diagrama de Estados (17/19) Diagrama de Estados (18/19)
• Estados compostos:
– Estados compostos podem ser utilizados para
simplificar diagramas de estados;
– Um estado composto é um estado que engloba
estados internos concorrentes ou seqüenciais;
– Estados internos são denominados subestados;
– Cada região de um estado composto pode possuir
estados inicial e final;
– Uma transição para um estado composto representa
uma transição para o estado inicial do referido estado
composto.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagrama de Estados (19/19)
• Crie diagrama de estados apenas para
classes com um comportamento dinâmico
significativo;
Análise e Projeto de Sistemas
• Classes de Fronteira e Controle normalmente
possuem um comportamento dinâmico Aula expositiva 08
interessante de ser capturado em um
diagrama de estados.
Professor José Luiz Bastos
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
32
33. Diagramas de Interação (1/27) Diagramas de Interação (2/27)
• Interação corresponde a um conjunto de • Mostram as interações entre os objetos;
mensagens trocadas entre objetos, com o • Representam cenários de casos de uso e
objetivo de alcançar determinado propósito, são formados por:
respeitando-se o contexto do sistema; – objetos;
– mensagens;
– relacionamentos;
• Não confundir com iteração, que representa
repetição. • Podem ser representados de quatro formas:
– Diagrama de Seqüência;
– Diagrama de Comunicação;
– Diagrama de Interação;
– Diagrama de Temporização.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Interação (3/27) Diagramas de Interação (4/27)
• Diagrama de Seqüência: • Diagrama Sumário de Interação:
– Focaliza a ordem temporal de um fluxo; – É uma variação do Diagrama de Atividades;
– Enfatiza a seqüência de mensagens dentro de uma – Várias atividades são combinadas em seqüência
linha de tempo; criando interações sumário;
• Diagrama de Comunicação: • Timing Diagram:
– Focaliza a comunicação entre os objetos; – Focaliza a interação entre objetos e mudanças de
– Enfatiza os relacionamentos estruturais entre os estados destes objetos ao longo do tempo;
objetos, sem se preocupar com o tempo; – Provê uma visão sobre a interação entre objetos e
seus estados com outros objetos em um sistema.
• É interessante ressaltar que esses diagramas
apresentam formas diferentes de modelar os
mesmos elementos.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
33
34. Diagramas de Seqüência (5/27) Diagramas de Comunicação (6/27)
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Interação (9/27) Diagramas de Interação (10/27)
Mensagem: • As mensagens podem ir da esquerda para a direita
– Uma mensagem é representada por uma seta, com o ou da direita para a esquerda;
nome da mensagem; • A ordem das mensagens indica a seqüência
– O sentido da seta indica a origem da mensagem a temporal, sendo a primeira localizada mais acima;
partir do objeto considerado cliente nesta relação. O • Mensagem de retorno:
destino da seta indica o objeto servidor. – O diagrama pode incluir o retorno de uma mensagem;
– Caracterize o retorno apenas quando melhorar a
compreensão do diagrama.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
34
35. Diagramas de Seqüência (11/27) Diagramas de Comunicação (12/27)
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Interação (13/27) Diagramas de Interação (14/27)
• Linha de vida: • Foco de controle:
– Representa a vida do objeto dentro de um – Representa o tempo durante o qual um objeto fica com
determinado período de tempo. o controle do fluxo de execução.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
35
36. Diagramas de Interação (15/27) Diagramas de Interação (16/27)
• Notas: • Os diagramas podem ser melhorados através
– Um diagrama pode incluir anotações com o objetivo de de descrições;
adicionar informação.
• Descrições podem ser escritas em linguagem
natural ou pseudo-código.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Interação (17/27) Diagramas de Interação (18/27)
• Um objeto que já existe quando a transação • O objeto pode ser criado no momento do
tem início é mostrado alinhado ao topo do envio da mensagem;
diagrama, de forma a ficar acima da primeira • A seta da mensagem aponta diretamente
seta de mensagem. para o objeto em questão.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
36
37. Diagramas de Interação (19/27) Diagramas de Interação (20/27)
• O objeto pode ser destruído logo após o • Condições são colocadas dentro de
tratamento da mensagem, ou em qualquer colchetes;
momento antes do fim da interação; • A mensagem só será disparada se a
• Um X é colocado na linha de vida para condição for verdadeira;
indicar a destruição do objeto. • Exemplo 1:
– [Mensalidade.pago = true] EmitirAutorizacaoDeProva()
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Interação (21/27) Diagramas de Interação (22/27)
• Iteração:
– Repetição (não confundir com interação);
– Representa o envio da mesma mensagem diversas
vezes para o mesmo objeto;
– A iteração é representada entre colchetes, precedida
de um asterisco *;
– Dentro do colchete está a condição que determinará
quantas vezes a mensagem será passada;
– Exemplo:
• Calcular a média dos alunos da turma da seguinte
maneira: para cada aluno da turma chamar a operação
CalcularMedia();
* [para cada aluno da turma] CalcularMedia()
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
37
38. Diagramas de Comunicação (23/27) Diagramas de Seqüência (24/27)
• Outra maneira de visualizar a interação entre • Exemplo de fluxo: Exclusão de mercadoria;
objetos; – O Gerente de Compras seleciona excluir uma
mercadoria;
• A maioria das ferramentas CASE cria de
– O sistema verifica se existe algum pedido pendente
forma automática um Diagrama de que contenha esta mercadoria;
Comunicação a partir de um Diagrama de – Se não houver pedido pendente contendo a
Seqüência e vice-versa. mercadoria a ser excluída:
• O sistema desvincula a mercadoria dos fornecedores (os
fornecedores não mais fornecerão a mercadoria que
esta sendo excluída);
• O sistema faz a remoção da mercadoria;
– Se houver pedido pendente contendo a mercadoria a
ser excluída:
• O sistema emite uma mensagem de erro.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
Diagramas de Seqüência (25/27) Diagramas de Interação (26/27)
Operações:
• Mensagens nos diagramas de interação:
– São mapeadas em operações da classe receptora;
– Os nomes das operações devem ser relativos à classe
receptora;
– A criação das operações pode ser adiada enquanto se
discutem alternativas de realização.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.
38
39. Diagramas de Interação (27/27)
Relacionamentos:
• Podem ser descobertos através das
operações:
– Existência de mensagens entre objetos nos diagramas
de interação;
– Existência de algum tipo de relacionamento entre as
classes correspondentes.
© 2008 José Luiz G. Bastos Jr.
39