A maior rede de estudos do Brasil

Grátis
117 pág.
O Essencial da Analise de Sistemas

Pré-visualização | Página 19 de 25

são usados para modelar o comportamento associado a um 
processo de negócio independente dos objectos. Muitas vezes, os diagramas de 
actividades podem ser vistos como diagramas de fluxos de dados sofisticados das 
metodologias de análise estruturada. Contudo, ao contrário dos diagramas de fluxos de 
dados, os diagramas de actividades incluem notação que proporciona a modelação de 
actividades paralelas, concorrentes e processos com decisões complexas. Com efeito, os 
diagramas de actividades podem ser usados para modelar tanto o fluxo de trabalho de 
alto nível que envolve diversos casos de uso como para detalhar um só caso de uso. 
Neste livro restringiremos os diagramas de actividades à modelação de alto nível de 
processos de negócio. 
Tabela 6.1: Elementos e notação dos diagramas de actividades. 
ELEMENTO NOTAÇÃO 
Acção: 
- É uma peça simples de comportamento, não 
decomponível; 
- É identificada pelo seu nome. 
Actividade: 
- É usada para representar um conjunto de acções; 
- É identificada pelo seu nome. 
 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 86 
 
Objecto Nó: 
- É usado para representar um objecto que está 
conectado a um conjunto de Fluxos de Objectos; 
- É identificado pelo seu nome de classe. 
Fluxo de Controlo: 
- Mostra a sequência da execução. 
Fluxo de objecto: 
- Mostra o fluxo de um objecto desde uma actividade 
(ou acção) para outra actividade (ou acção). 
 
Nó Inicial: 
- Ilustra o início de um conjunto de acções ou 
actividades. 
 
Nó de Actividade Final: 
- É usado para parar todos os fluxos de controlo e fluxos 
de objecto numa actividade ou acção. 
Nó de Fluxo Final: 
- É usado para parar um fluxo de controlo ou fluxo de 
objecto específico. 
Nó de Decisão: 
- É usado para representar um teste de condição para 
assegurar que o fluxo de controlo ou fluxo de objecto 
apenas segue um caminho; 
- É identificado com o critério de decisão para continuar 
nesse caminho. 
 
Nó de Fusão: 
- É usado para fundir diferentes caminhos de decisões 
que foram criados usando um nó de decisão. 
 
Nó de Desdobramento: 
- É usado para desdobrar o comportamento num 
conjunto de fluxos de actividades ou acções 
concorrentes ou paralelas. 
 
Nó de Junção: 
- É usado para juntar um conjunto de fluxos de 
actividades ou acções paralelas ou concorrentes. 
 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 87 
 
Pista: 
- É usado para quebrar um diagrama de actividades em 
linhas e colunas para atribuir actividades ou acções 
individuais a objectos que são responsáveis pela 
execução da actividade ou acção. 
 
 
Na construção de diagramas de actividades devem ser considerados os seguintes passos: 
1. Determinar o contexto ou foco do processo a ser modelado de modo a 
encontrarmos um nome adequado para o diagrama. 
2. Identificar as actividades, fluxos de controlo e fluxos de objecto que ocorram 
entre actividades. 
3. Identificar as decisões que fazem parte do processo a ser modelado. 
4. Identificar eventuais perspectivas de paralelismo no processo. 
5. Desenhar o diagrama. 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 88 
 
 
Figura 6.1: Diagrama de actividades para um sistema de agendamento de consultas. 
6.2.2 Descrições de Casos de Uso 
Os casos de uso são descrições simples das funções de um sistema a partir das visões e 
perspectivas dos utilizadores. Os diagramas de casos de uso são diagramas de funções 
que mostram as funções básicas do sistema em análise, ou seja, o que os utilizadores 
podem fazer e como o sistema deve responder às acções dos mesmos. 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 89 
 
Inicialmente os utilizadores devem trabalhar juntamente com os analistas para 
escreverem as descrições dos casos de uso. Depois os analistas devem traduzir estas 
descrições de casos de uso em diagramas de casos de uso formais. Quer as descrições de 
casos de uso quer os diagramas de casos de uso são baseados nos requisitos 
identificados e nas descrições dos diagramas de actividades. 
Tipos de casos de uso 
Existem diferentes tipos de casos de uso, tendo em conta o propósito e a quantidade de 
informação: (1) visão geral versus detalhe; (2) essencial versus real. 
Um caso de uso de visão geral é usado para os analistas e os utilizadores chegarem a um 
acordo da visão geral dos requisitos de alto nível. Normalmente são criados no início do 
processo de determinação dos requisitos e somente documentam informação básica 
acerca do caso de uso, tal como nome, número de identificação, actor primário, tipo e 
uma breve descrição. Quando os utilizadores e os analistas acordarem a visão geral de 
alto nível dos requisitos, o caso de uso de visão geral deverá ser convertido num caso de 
uso de detalhe. Um caso de uso de detalhe normalmente documenta, tão detalhadamente 
quanto possível, toda a informação necessária para o caso de uso. 
Um caso de uso essencial é aquele que descreve o mínimo essencial necessário para 
entender a funcionalidade requerida. Um caso de uso real vai mais além, descrevendo 
um conjunto específico de passos reais. Por exemplo, um caso de uso essencial num 
consultório de dentista pode dizer que a “recepcionista deve tentar encontrar uma 
consulta no período que o paciente deseja”, enquanto que num caso de uso real pode 
dizer que a “recepcionista deve tentar encontrar uma consulta no período que o paciente 
deseja usando o MS Exchange”. A principal diferença é que o caso de uso essencial é 
independente da implementação, não prescrevendo tecnologia. Assim, os casos de uso 
reais tendem a ser explorados apenas na fase de concepção dos sistemas de informação. 
 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 90 
 
Elementos de uma descrição de caso de uso 
Uma descrição de caso de uso deve conter toda a informação necessária para a 
construção dos diagramas que se seguem, através de uma expressão menos formal, o 
que simplifica o entendimento pelos utilizadores. As descrições de casos de uso devem 
estruturar-se em três partes: visão geral, relacionamentos e fluxo de eventos. A tabela 
6.2 apresenta um exemplo. 
Caso de Uso: Marcar consulta ID: F11 Nível de Importância: Alta 
Actor Principal: Paciente Tipo de Caso de Uso: Detalhe, essencial 
Interessados: 
Paciente – deseja marcar, cancelar ou alterar uma consulta. 
Médico – deseja assegurar que as necessidades do paciente sejam satisfeitas atempadamente. 
Descrição resumida: Este caso de uso descreve como se marca uma nova consulta bem como se 
altera ou cancela uma consulta existente. 
Evento: Paciente telefona e pede uma nova consulta, ou pede alteração ou cancelamento de uma 
existente. 
Tipo: Externo / Temporal 
Relacionamentos: 
Associação: Paciente 
Inclui: Tratar das questões do pagamento 
Estende: Criar novo paciente 
Generalização: 
Fluxos de eventos normais: 
1. O Paciente contacta o consultório em relação a uma consulta. 
2. O Paciente fornece ao Recepcionista o seu nome morada. 
3. O Recepcionista verifica se o Paciente existe na base de dados. 
4. O Recepcionista executa o caso de uso Tratar das questões de pagamento. 
5. O Recepcionista pergunta ao Paciente se pretende uma nova consulta, ou cancelar ou 
alterar de uma existente. 
• Se o Paciente deseja marcar uma nova consulta, realizar sub-fluxo S-1. 
• Se o Paciente deseja cancelar uma consulta existente, realizar sub-fluxo S-2. 
• Se o Paciente deseja alterar uma consulta existente, realizar sub-fluxo S-3. 
6. O Recepcionista fornece os resultados da transacção ao Paciente. 
 
 
 
 
Álvaro Rocha (2008), O Essencial da Análise de Sistemas. UFP Página 91 
 
Subfluxos

Crie agora seu perfil grátis para visualizar sem restrições.