Diagrama de Sequencia (aula_diagramadesequencia2013.1.pdf)

Prévia do material em texto

Disciplina: Analise e Projeto de 
Sistemas Orientado a Objetos 
Modelagem de UML 
Prof. Izaac Espíndola 
izaacesp@gmail.com 
05/10/2013 
Modelos, Visões e 
Diagramas 
Modelos, Visões, 
Diagramas 
Caso de Uso 
Componentes 
Distribuição 
Objetos 
Estado 
Classes 
Atividade 
Colaboração 
Sequência 
Iteração 
Visão do usuário 
Visão comportamental Visão de ambiente 
Visão estrutural Visão de implementação 
Diagrama de Sequência 
 
5 
• Diagrama de sequência representa como o sistema 
age internamente para que um ator atinja seu 
objetivo na realização de um caso de uso. 
• Documenta os aspectos dinâmicos do sistema; 
• Representam mensagens trocadas entre objetos para 
a execução de cenários dos casos de uso do sistema. 
• Mostra a interação entre os objetos tendo em vista a 
sequência das mensagens no tempo; 
Diagrama de Sequência 
6 
• A modelagem de um sistema OO normalmente contém 
diversos diagramas de sequência. 
• Ressalta a ordem cronológica das mensagens. 
Diagrama de Sequência 
Diagrama de sequência: 
mensagens enviadas no decorrer 
do tempo. 
7 
• O princípio básico da interação entre objetos é 
o conceito de Mensagem. 
 
• Um sistema OO pode ser visto como uma rede 
de objetos. Funcionalidades são realizadas 
pelos objetos, que só podem interagir através 
do envio de mensagens. 
Mensagens 
8 
• Uma mensagem representa a requisição de 
um objeto remetente a um objeto receptor 
para que este último execute alguma 
operação definida para sua classe. 
 
• Essa mensagem deve conter informação 
suficiente para que a operação do objeto 
receptor possa ser executada. 
Mensagens 
9 
• O fato de um objeto “precisar de ajuda” indica a 
necessidade de este enviar mensagens. 
• Na construção de diagramas de interação, 
mensagens de um objeto a outro implicam em 
operações que classes devem ter. 
Uma mensagem implica na existência de 
uma operação no objeto receptor. 
A resposta do objeto receptor ao 
recebimento de uma mensagem é a 
execução da operação correspondente. 
Mensagens versus 
Responsabilidades 
10 
Mensagens versus 
Responsabilidades 
11 
• Mensagem síncrona ( ) 
– É aquela em que o objeto remetente espera que 
o objeto receptor processe a mensagem antes de 
recomeçar o seu processamento, ou seja, o 
remetente fica bloqueado até que o receptor 
termine de atender a requisição. 
• Mensagem assíncrona ( ) 
– É aquela na qual o objeto remetente não espera 
a resposta para prosseguir com o seu 
processamento. 
Tipos de Mensagens 
12 
• Mensagem reflexiva (self) 
– É aquela enviada de um objeto para ele mesmo 
solicitando a execução de uma operação definida 
em sua própria classe. 
• Mensagem de retorno ( ) 
– Indica o final da execução de uma operação 
(retorno do fluxo de controle) 
Tipos de Mensagens 
13 
Tipos de Mensagens 
14 
• A especificação para o rótulo de uma mensagem deve seguir a 
seguinte sintaxe: 
 
 
 
• Onde expressão-sequência serve para eliminar ambiguidades 
acerca de quando a mensagem foi enviada em relação às 
demais. 
• Onde o termo recorrência pode ser uma condição ou um 
repetição (iteração): 
 
 
 
• Onde v é uma variável que armazena o valor de retorno da 
operação. 
• O único termo obrigatório corresponde à operação. 
Sintaxe das Mensagens 
‘[’ cláusula-condição ‘]’ e ‘*’ ‘[’ cláusula-iteração ‘]’ 
expressão-sequência recorrência: v := operação(parâmetros) 
15 
• *[para cada f em F] desenhar() 
• *[enquanto x>0] transformar(x) 
• [senha é válida] abrirJanelaPrincipal() 
• 1: adicionarItem(item) 
• 3 [a > b]: trocar(a, b) 
• 2 *: desenhar() 
• 2 *[i := 1..10]: desenhar(i) 
• 1.2.1: x := selecionar(e) 
Sintaxe das Mensagens 
16 
Seq Condição de Guarda 
(cláusula-condição) 
Iteração 
(cláusula-iteração) 
Retorno:=operação(param) 
*[para cada f em F] desenhar() 
*[enquanto x>0] transformar(x) 
[senha é válida] abrirJanelaPrincipal() 
1 adicionarItem(item) 
3 [a > b] trocar(a, b) 
2 * desenhar() 
2 * [i := 1..10] desenhar(i) 
1.2.1 x := selecionar(e) 
Sintaxe das Mensagens 
17 
• Obter informações adicionais para completar 
e aprimorar outros modelos (principalmente 
o modelo de classes) 
– Quais as operações de uma classe? 
– Quais os objetos participantes da realização de 
um caso de uso (ou cenário deste)? 
– Para cada operação, qual a sua assinatura? 
– Uma classe precisa de mais atributos? 
– Fornecer aos programadores uma visão 
detalhada dos objetos e mensagens envolvidos 
na realização dos casos de uso. 
Objetivos do Diagrama de 
Sequência 
18 
• Assim como os outros diagramas da UML, o 
diagrama de sequência possui um conjunto de 
elementos gráficos. 
– Elementos básicos: 
• Atores 
• Objetos 
• Classes 
• Mensagens 
• Criação de objetos 
• Destruição de objetos 
Elementos Básicos 
19 
• Objetos são representados em um diagrama 
de sequência utilizando-se a mesma notação 
gráfica do diagrama de objetos. 
• Pode-se representar objetos anônimos ou 
objetos nomeados, dependendo da situação. 
• Classes também podem ser representadas. 
– Para o caso de mensagens enviadas para a classe 
em vez de ser enviada para um objeto. 
Elementos Básicos 
20 
vendas 
vendas : Departamento 
: Departamento 
Nome de um dado Objeto 
Nome de Objeto e Classe 
Objeto nomeado 
Objeto Anônimo da 
Classe Departamento 
Representação de Objetos e Classes 
Representação dos Elementos 
Departamento Classe Departamento 
21 
maria : Cliente 
: Cliente 
Nomeado: recebe um nome e 
necessita ser referenciado 
posteriormente. 
Anônimo: não recebe um nome 
específico 
Às vezes, uma mensagem é enviada para uma 
classe. Nesse caso, a operação a ser executada é 
uma operação de classe (estática). 
 Representação de Objetos e Classes 
Representação dos Elementos 
22 
• Mostra, baseado em um cenário: 
– Objetos e classes envolvidos; 
– A sequência de mensagens (simbolizadas por 
setas) trocadas pelos objetos, necessárias para 
desenvolver a funcionalidade do cenário. 
Diagrama de Sequência 
23 
• Mostra alguma coisa que acontecerá em um 
ponto específico da execução do sistema; 
 
• Consiste em um número de objetos mostrado 
em linhas verticais; 
 
• O decorrer do tempo é visualizado 
observando-se o diagrama no sentido vertical 
de cima para baixo. 
Diagrama de Sequência 
24 
• Os objetos participantes da interação são 
organizados na horizontal. 
 
• Abaixo de cada objeto existe uma linha, 
chamada de linha de vida. 
 
• Um retângulo na linha da vida representa o 
seu foco de controle que indica a duração da 
ação realizada pelo objeto. 
Diagrama de Sequência 
25 
• O topo do retângulo indica o início da execução 
da operação solicitada pela mensagem recebida e 
a base inferior do retângulo marca o fim da 
execução da operação. 
• As mensagens entre objetos são representadas 
com linhas horizontais rotuladas partindo da 
linha de vida do objeto remetente e chegando a 
linha de vida do objeto receptor. 
Diagrama de Sequência 
26 
• A posição vertical das mensagens permite 
deduzir a ordem na qual elas são enviadas. 
• Ordem de envio de mensagens em um 
diagrama de sequência pode ser deduzida a 
partir das expressões de sequência. 
• Criação e destruição de objetos podem ser 
representadas. 
O diagrama de sequência exibe 
uma visão dinâmica do sistema. 
Diagrama de Sequência 
27 
Forma Geral do Diagrama de 
Sequência 
28 
Forma Geral do Diagramade 
Sequência 
29 
Diagrama de Casos de Uso 
 Sistema Bancário 
• Caso de Uso – Criar Cliente 
30 
Especificação do Caso de Uso 
Criar Cliente 
Fluxo Principal 
1. O usuário solicita o cadastro de cliente. 
2. O sistema apresenta o formulário para preenchimento. 
3. O usuário entra com as informações necessárias do cliente no sistema e submete. 
4. O sistema valida o cadastro do cliente. (FE01) (FE02) 
5. O sistema armazena os dados do cliente. 
6. O sistema cria uma conta em nome do cliente 
7. O sistema notifica o usuário sobre o cadastro e o caso de uso termina. 
 
Fluxos de Exceção 
FE01 - Usuário cadastrado 
1. Se o cliente já estiver cadastrado, uma mensagem será exibida e o caso de uso termina. 
 
FE02 - Dados incompletos 
1. Se os dados estiverem incompletos, o sistema exibe uma mensagem para que o usuário 
forneça as informações completas e o caso de uso retorna ao passo 3 do fluxo principal. 
31 
Diagrama de Sequência – 
Criar Cliente 
Análise de robustez 
• Foi proposta por Ivar Jacobson 
• Fornece uma facilidade de entender e uma 
abordagem consistente para identificar as classes de 
analise do modelo de Use Case. 
• Há três tipos de classes da análise: 
– Classe limite 
– Classe controle e 
– Classe entidade 
• Na notação de UML, são classes estereotipo com 
seus próprios ícones específicos, Também é possível 
usar a notação de classes com o rótulo estereotipo. 
• Sua origem vem do padrão MVC 
Arquitetura MVC 
View 
Controller 
Model 
Inclui 
Informações 
Altera o 
modelo 
Disparo de 
evento ao 
ocorrer alteração 
no modelo 
 
Objetivo Arquitetura 
MVC 
• Separar: 
– dados ou lógica de negócios (Model); 
– da interface do usuário (View) e; 
– do fluxo da aplicação (Control) 
• O modelo do negócio não deve conhecer nada 
sobre as telas que exibem seu estado. 
 
Regras do negócio 
• São políticas, condições ou restrições que devem ser 
consideradas na execução dos processos existentes em 
uma organização. 
• Descrevem a maneira pela qual a organização funciona. 
• A descrição do modelo de regras do negócio pode ser feita 
utilizando-se texto informal, ou alguma forma de 
estruturação. 
• Regras do negócio normalmente têm influência sobre um 
ou mais casos de uso. 
• Os identificadores das regras do negócio devem ser 
adicionados à descrição do caso de uso. 
– Utilizando a seção “regras do negócio” da descrição do caso de 
uso. 
 
Regras do negócio 
• Alguns exemplos de regras do negócio: 
– O valor total de um pedido é igual à soma dos 
totais dos itens do pedido acrescido de 10% de taxa 
de entrega. 
– Um professor só pode estar lecionando disciplinas 
para as quais esteja habilitado. 
– Um cliente do banco não pode retirar mais de R$ 
1.000 por dia de sua conta. 
– Os pedidos para um cliente não especial devem ser 
pagos antecipadamente. 
Regras do negócio 
• Possível formato para documentação de uma 
regra de negócio. 
Nome Quantidade de inscrições possíveis (RN01) 
Descrição Um aluno não pode ser inscrever em mais de seis 
disciplinas por semestre letivo. 
Fonte Coordenador da escola de informática 
Histórico Data de identificação: 12/07/2002 
Análise de robustez 
• Classe limite 
• Classe controle 
• Classe entidade 
Classe Limite 
• Representa as relações entre os atores (mundo 
externo) e o sistema. 
• Dependendo do tipo do ator, uma classe do limite 
é requerida para representar interfaces com: 
– o usuário (atores humanos), 
– sistemas externos (sistema legado) ou 
– um dispositivo externo atrelado ao sistema.. 
• Esses objetos traduzem os eventos gerados por 
um ator em eventos relevantes ao sistema. 
• Também são responsáveis por apresentar os 
resultados de uma interação dos objetos em algo 
inteligível pelo ator. 
 
Classe Limite 
• É altamente dependente do ambiente 
• Normalmente têm as seguintes 
responsabilidades de: 
– Notificar aos objetos de controle de eventos 
gerados externamente ao sistema. 
– Notificar aos atores do resultado de interações 
entre os objetos internos. 
Classe Controle 
• Representa a lógica do caso do uso e coordena as outras 
classes. 
• Implementam as ações aplicadas as demais classes. 
• Separa as classes de interface das classes da lógica do 
negócio. 
• Responsáveis por controlar a lógica de execução 
correspondente a um caso de uso. 
• Decidem o que o sistema deve fazer quando um evento 
externo relevante ocorre. 
– Eles realizam o controle do processamento 
– Agem como gerentes (coordenadores, controladores) dos 
outros objetos para a realização de um ou mais caso de uso. 
Classe Controle 
• Traduzem eventos externos em operações que 
devem ser realizadas pelos demais objetos. 
• Podem também ter o objetivo de manter o 
estado da realização do caso de uso. 
• As instancias da classe controle, normalmente, 
têm vida curta, existem somente durante a 
realização de um caso de uso. 
Classe Controle 
• Responsabilidades típicas: 
– Realizar monitorações, a fim de responder a eventos 
externos ao sistema (gerados por objetos limite). 
– Coordenar a realização de um caso de uso através do 
envio de mensagens a objetos limite e objetos 
entidade. 
– Assegurar que as regras do negócio estão sendo 
seguidas corretamente. 
– Coordenar a criação de associações entre objetos de 
entidade. 
Classe Entidade 
• São classes básicas do domínio do problema. 
• Gerencia as informações que o sistema necessita 
para fornecer a funcionalidade requerida. 
• Geralmente as classes da entidade são específicas 
do negócio. 
• São informações especializadas e encapsulam o 
conhecimento do negócio. 
• Na maioria das vezes, classes da entidade são as 
classes persistentes que podem ser usadas para 
gerar diretamente o esquema da base de dados. 
• É um repositório para alguma informação 
manipulada pelo sistema. 
 
Classe Entidade 
• Atores não têm acesso direto a estes objetos. 
• Objetos de entidade normalmente participam de vários 
casos de uso e têm um ciclo de vida longo. 
• Responsabilidades de fazer típicas de objetos de 
entidade: 
– Informar valores de seus atributos a objetos de controle. 
– Realizar cálculos simples, normalmente com a colaboração 
de objetos de entidade associados através de agregações. 
– No caso de possuir subclasses (agregação por 
composição), criar e destruir objetos parte. 
46 
Diagrama de Sequência – 
Realizar Submissão 
Diagrama de seqüência 
Diagrama de seqüência 1/3 
Diagrama de seqüência 2/3 
Diagrama de seqüência 3/3 
Diagrama de 
Atividades 
• É o diagrama com maior ênfase ao nível de 
algoritmo da UML e provavelmente um dos 
mais detalhistas. 
• Era considerado um caso especial do 
Diagrama de Gráficos de Estados. 
• A partir da UML 2.0 tornou-se um diagrama 
totalmente independente. 
Diagrama de 
Atividades 
• Apresenta muitas semelhanças com os antigos 
fluxogramas. 
• Este diagrama preocupa-se em descrever os 
passos a serem percorridos para a conclusão 
de um método ou algoritmo específico e não 
um processo completo como é o diagrama de 
seqüência. 
Possui três estados 
obrigatórios 
• Estado inicial 
 
• Estado final 
 
• Estado de ação 
Fluxos de Controle 
• Quando a ação está completa, o fluxo de 
controle passa imediatamente à próxima ação. 
• O fluxo é especificado utilizando setas de fluxo 
para mostrar o caminho de uma ação 
seguinte. 
Ponto de decisão 
• Representa um ponto do fluxo de controle 
onde deve ser realizado um teste, uma 
tomada de decisão. 
• As transições geradas por um Ponto de 
Decisãonecessitam ser providas de uma 
Condição de Guarda(texto entre colchetes) 
para determinar qual a condição do teste. 
Exemplo – 
Ponto De Decisão 
Exemplo 
 Diagrama de Atividades 
Recomendações de 
Utilização do 
Diagrama De Atividades 
 
1. Modelagem dos processos do negócio 
2. Modelagem da lógica de um caso de uso 
3. Modelagem da lógica de uma operação 
complexa 
1. Modelagem dos 
 Processos do Negócio 
• O processo de negócio também é um processo 
de entendimento 
• Às vezes os modelos são construídos para 
melhorar o entendimento de um determinado 
problema 
• Nesse caso, o enfoque está em entender o 
comportamento do sistema no decorrer de 
diversos casos de uso 
Exemplo – 
Modelagem dos Processos 
do Negócio 
2. Modelagem da Lógica de um CDU 
 Na descrição de um caso de uso, não há uma 
sintaxe clara para indicar decisões, iterações e 
fluxos executados em paralelo. É comum utilizar 
frases como “O passo P ocorre até que a 
condição C seja verdadeira” ou “Vai para o passo 
9 do Fluxo Principal”. 
 Nessas situações, é interessante complementar a 
especificação do caso de uso com um diagrama 
de atividades. 
 O diagrama de atividades deve ser usado para 
complementar a especificação e não para 
substituí-la. 
Exemplo - Modelagem da 
 Lógica de um CDU 
3. Modelagem da Lógica de uma 
Operação Complexa 
• Em alguns casos, quando uma operação de 
uma classe de controle implementa uma regra 
de negócio, pode haver a necessidade de 
descrever a lógica dessa operação ou da 
própria regra de negócio. 
• Diagramas de atividades também podem ser 
usados com esse objetivo 
Descrição de uma Regra de Negócio: 
• A nota de um aluno em uma disciplina (um valor de 0 a 10) é obtida 
pela média de duas avaliações durante o semestre, A1 e A2, ou pela 
freqüência nas aulas. 
• Se o aluno obtiver nota maior ou igual a 7.0 (sete), será aprovado. 
• Se o aluno obtiver nota maior ou igual a 5.0 (cinco) e menor que 7.0 
(sete), deverá fazer a avaliação final. 
• Se o aluno obtiver nota menor que 5.0 (cinco) será reprovado. 
• Se o aluno obtiver uma freqüência menor que 75% em uma turma, será 
automaticamente reprovado. 
• Após a prova final, o aluno será considerado aprovado, se sua média 
final for maior ou igual a 6.0 (seis), caso contrário, será reprovado. 
Exemplo - Modelagem da Lógica de 
uma Regra de Negócio 
66 
Diagrama de Atividade 
• Um diagrama de atividade exibe os passos de uma 
computação. 
– Cada estado é um passo da computação, onde o sistema 
está realizando algo. 
– É orientado a fluxos de controle (ao contrário dos DTEs que 
são orientados a eventos). 
• Fluxogramas estendidos... 
– Além de possuir toda a semântica existente em um 
fluxograma, permite representar ações concorrentes e sua 
sincronização. 
• Elementos podem ser divididos em dois grupos: 
controle seqüencial e controle paralelo. 
67 
Diagrama de Atividade 
• Elementos utilizados em fluxos seqüenciais: 
– Estado ação (realizado instantaneamente) 
– Estado atividade (leva um certo tempo para ser 
finalizado) 
– Estados inicial e final, e condição de guarda 
– Transição de término 
– Pontos de ramificação e de união 
• Elementos utilizados em fluxos paralelos: 
– Barras de sincronização 
• Barra de bifurcação (fork) 
• Barra de junção (join). 
68 
Fluxos de Controle Sequenciais 
• Deve haver um estado inicial e pode haver 
vários estados finais e guardas associadas a 
transições. 
– pode não ter estado final, o que significa que o 
processo ou procedimento é cíclico. 
• Uma transição de término significa o término 
de um passo e o conseqüente início do outro. 
– ao invés de ser disparada pela ocorrência de um 
evento, é disparada pelo término de um passo. 
69 
Fluxos de Controle Sequenciais 
• Um ponto de ramificação ou de decisão, possui uma 
única transição de entrada e várias transições de saída. 
– Para cada transição de saída, há uma condição de guarda 
associada. 
– Quando o fluxo de controle chega a um ponto de ramificação, 
uma e somente uma das condições de guarda deve ser 
verdadeira. 
– Pode haver uma transição com [else]. 
• Um ponto de união reúne diversas transições que, direta 
ou indiretamente, têm um ponto de ramificação em 
comum. 
70 
Diagrama de Atividade 
71 
Exemplo de Diagrama 
de Atividade 
72 
Fluxos de Controle Paralelos 
• Fluxos de controle paralelos: dois ou mais fluxos sendo 
executados simultaneamente. 
• Uma barra de bifurcação recebe uma transição de 
entrada, e cria dois ou mais fluxos de controle paralelos. 
– cada fluxo é executado independentemente e em paralelo com 
os demais. 
• Uma barra de junção recebe duas ou mais transições de 
entrada e une os fluxos de controle em um único fluxo. 
– Objetivo: sincronizar fluxos paralelos. 
– A transição de saída da barra de junção somente é disparada 
quando todas as transições de entrada tiverem sido disparadas. 
73 
Fluxos de Controle Paralelos 
• Algumas vezes, as atividades de um processo podem ser 
distribuídas por vários agentes que o executarão. 
– processos de negócio de uma organização. 
• Isso pode ser representado através de raias de natação 
(swim lanes). 
• As raias de natação dividem o diagrama de atividade em 
compartimentos. 
• Cada compartimento contém atividades que são 
realizadas por uma entidade. 
74 
Exemplo (Raias de Natação) 
Seguradora OficinaSegurado
Acionar Seguro Recolher Automóvel
Consertar Automóvel
[else]
[perda total]
Depositar Valor Segurado
Pagar Franquia Cobrar Fraquia
Avaliar Danos
75 
Diagrama de 
Atividades X de Estados 
Diagrama de 
Atividades 
Diagrama de 
Estados 
 Ênfase no fluxo de uma 
atividade para outra; 
 Ênfase no fluxo de um 
estado para outro do 
objeto. 
 Não é necessário 
especificar os eventos; 
 Especificação 
obrigatória dos eventos; 
Diagrama de Comunicação 
Diagrama de 
Comunicação 
• O Diagrama de Comunicação era conhecido 
como Diagrama de Colaboração até a versão 
1.5 da UML, tendo seu nome modificado para 
Diagrama de Comunicação a partir da versão 
2.0. 
 
Diagrama de 
Comunicação 
• Esse diagrama está amplamente associado ao 
Diagrama de Seqüência; na verdade, um 
complementa o outro. 
• As informações mostradas no Diagrama de 
Comunicação são, com freqüência, as mesmas 
apresentadas no Diagrama de Seqüência, porém 
com um enfoque diferente, visto que este 
diagrama não se preocupa com a temporalidade 
do processo, concentrando-se em como os 
objetos estão vinculados e quais mensagens 
trocam entre si durante o processo. 
Diagrama de 
Comunicação 
• Em um diagrama de comunicação o tempo 
não é mais representado por linhas verticais, 
mas sim através de uma numeração, que pode 
ser de duas formas: 
– simples (1,2,3,...) 
– composta (1.1, 1.2, 1.2.1, ...) 
Diagrama de 
Comunicação 
• Se a ênfase do diagrama for o decorrer do 
tempo, é melhor escolher o diagrama de 
seqüência, mas se a ênfase for o contexto do 
sistema, é melhor dar prioridade ao diagrama 
de colaboração. 
Diagrama de 
Comunicação 
• Um objeto é representado como um 
retângulo, contendo no seu interior um rótulo, 
que informa o nome do objeto e o nome da 
classe, separados por dois pontos 
Diagrama de 
Comunicação 
• Um vínculo é uma associação que identifica 
uma ligação entre dois objetos envolvidos em 
um processo. É caracterizado pelo envio ou 
recebimento de uma mensagem, ou ambos. 
Diagrama de 
Comunicação 
• Como ocorre em diagramas de seqüência 
existem setas que indicam as mensagens 
enviadasentre os objetos para realizar um 
Caso de Uso. 
• É possível adicionar condições, para 
representá-las basta adicionar a descrição 
entre colchetes na própria mensagem. 
Diagrama de 
Comunicação 
 
 
Diagrama de 
Comunicação 
• Um objeto pode disparar uma mensagem em 
si próprio, o que é reconhecido como 
autochamada. 
Diagrama de 
Comunicação 
• Na figura anterior é exibido o diagrama de 
comunicação do caso de uso realizar 
submissão. É mostrado as mensagens 
trocadas entre o Submissor, a página do 
congresso, o controlador do congresso, o 
tema e a Submissão. 
Exercício 
1. Leia, interprete a descrição do caso de uso 
abaixo e complemente a sua especificação 
através de um Diagrama de Atividades: 
Projeto: Controle de Cursos 
Nome: Manter Aluno 
Descrição: Este caso de uso permite a inclusão, exclusão, alteração e 
consulta de alunos, pela atendente 
Ator: Atendente 
Pré-condição: A atendente deverá estar devidamente identificada pelo 
sistema 
Exercício 
Fluxo Principal: 
1. A Atendente informa o código do aluno [A1] 
2. A Atendente solicita a busca 
3. O sistema pesquisa os dados do aluno 
4. O sistema exibe os dados do aluno [A2] 
5. A Atendente edita os dados do aluno [A3] 
6. A Atendente solicita a gravação dos dados 
7. O sistema valida os dados informados 
8. O sistema grava os dados do aluno [A4] 
9. Fim do caso de uso 
Fluxos Alternativos: 
A1. Novo Aluno 
1. A Atendente solicita a inclusão de um novo aluno 
2. O sistema solicita os dados do novo aluno 
3. A Atendente informa os dados do aluno 
4. Vai para o passo 6 do fluxo principal 
Exercício 
A2. Aluno não encontrado 
1. O sistema informa a situação à atendente 
2. Vai para o passo 1 do Fluxo Principal 
A3. Exclusão de Aluno 
1. Atendente solicita exclusão do aluno 
2. O sistema solicita confirmação da exclusão 
3. [se confirmação positiva] Sistema exclui aluno 
4. Vai para o passo 9 do fluxo principal 
A4. Dados inválidos 
1. Se algum dado do aluno estiver em desacordo com as regras de 
validações e restrições, o sistema informa situação à Atendente 
2. Vai para o passo 5 do fluxo principal 
Pós-condições: Os dados são incluídos, alterados ou excluídos 
conforme solicitação do aluno 
Exercício 
2. Construa um Diagrama de Atividades para o 
seguinte processo de negócio: 
• A autorização do pagamento tem início após um pedido ter sido 
realizado pelo cliente. 
• Ao mesmo tempo, a disponibilidade para cada um dos itens do pedido 
é verificada pelo depósito. 
• Se a quantidade requisitada de um determinado item existe em 
estoque, tal quantidade é associada ao pedido, caso contrário, a 
quantidade do item será alterada (se houver em quantidade menor), se a 
quantidade em estoque for igual a zero, o item será excluído. 
• O pedido é enviado pelo depósito ao cliente quando todos os itens 
estiverem associados e o pagamento estiver autorizado. 
• O pedido será cancelado se a ordem de pagamento não tiver sido 
autorizada.