Análise e Projeto de Sistemas

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.


1

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.


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.


2

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.


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


3

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


• 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?


4

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.


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


5

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


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.


6

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.


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


7

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


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


8

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


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


9

• Associação:
– Ocorre entre um ator e um caso de uso;
– Representa a interação do ator com o 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. ...


10

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


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


11

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


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.


12

• Organizando o modelo com pacotes: • Organizando o modelo com pacotes:


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


13

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.


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


14


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



• 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


15


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



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


16


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



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


17


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



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


18


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



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


19


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



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


20


• 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



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


21


• Composição indica ciclos de vida • Composições reflexivas são composições de
dependentes. uma classe com ela mesma;



• Herança simples: • Herança múltipla:


22

Introdução a UML
Diagrama de classes (36/36)

• Dependências:


Aula expositiva 06



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.


23

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.

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


24

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.



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


25


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



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


26


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


Diagrama de Atividades (12/12)


Aula expositiva 07



27

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.



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


28


• Estados x atributos:
– O estado de um objeto pode ser caracterizado pelo
valor de um ou mais de seus atributos.



• 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:


29


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


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]


30

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



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


31


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


Diagrama de Estados (19/19)

• Crie diagrama de estados apenas para
classes com um comportamento dinâmico
significativo;

• Classes de Fronteira e Controle normalmente
possuem um comportamento dinâmico Aula expositiva 08
interessante de ser capturado em um
diagrama de estados.


32

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.



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

33

Diagramas de Seqüência (5/27) Diagramas de Comunicação (6/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.


34

Diagramas de Seqüência (11/27) Diagramas de Comunicação (12/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.


35


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



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


36


• 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()



• 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()


37

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.

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.


38

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

Análise e Projeto de Sistemas

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Análise e Projeto de Sistemas

Similar to Análise e Projeto de Sistemas (20)

Recently uploaded

Recently uploaded (6)

Análise e Projeto de Sistemas