MODELAGEM DO SISTEMA: DIAGRAMA DE ATIVIDADES



Documentos relacionados
Modelagem do Processo de Negócio

DIAGRAMA DE ATIVIDADES

Guia de utilização da notação BPMN

Gerenciamento da Integração (PMBoK 5ª ed.)

COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO

Modelos de Sistemas Casos de Uso

UML & Padrões Aula 3. UML e Padrões - Profª Kelly Christine C. Silva

Desenvolvimento de uma Etapa

Resolução da lista de exercícios de casos de uso

DESENVOLVENDO O SISTEMA

Bem-vindo ao tópico sobre administração de listas de preços.

Casos de uso Objetivo:

Micro Mídia Informática Fevereiro/2009

2 Diagrama de Caso de Uso

REQUISITOS DE SISTEMAS

5 Exemplo de aplicação

BR DOT COM SISPON: MANUAL DO USUÁRIO

Diagrama de contexto

Editor de Seção: Editor de Seção. Na página Irá aparecer a página do usuário:

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

3.1 Definições Uma classe é a descrição de um tipo de objeto.

Modelagem Dinâmica com UML

Bem-vindo ao tópico Múltiplas filiais.

Nome do Processo: Recebimento de produtos em consignação

AGENDAMENTO PARA IMPORTAÇÃO DE NOTAS FISCAIS 1. PARÂMETROS DO ESTABELECIMENTO CONFIGURAÇÃO DO AGENDADOR... 3

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini prof.andre.luis.belini@gmail.com /

Agendador de Rotinas

Integração de livros fiscais com o Microsoft Dynamics AX 2009

Engenharia de Software III

Gerenciamento de Projetos Modulo III Grupo de Processos

3. Fase de Planejamento dos Ciclos de Construção do Software

ESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE

Unidade I Conceitos BásicosB. Conceitos BásicosB

UML Unified Modeling Language. Professor: André Gustavo Bastos Lima

Espaço do Coordenador

Atendimento WEB IAMSPE CEAMA v docx. Manual de Atendimento

Fundamentos de Teste de Software

Carrera Pessoal Guia de uso

Figura 1: tela inicial do BlueControl COMO COLOCAR A SALA DE INFORMÁTICA EM FUNCIONAMENTO?

IES-200. Tecnologia em Análise e Desenvolvimento de Sistemas Prof. Me. Álvaro d Arce alvaro@darce.com.br

Manual do Usuário. Protocolo

MODELAGEM DE SISTEMAS

Primeiros passos das Planilhas de Obra v2.6

Como criar um perfil de destaque no LinkedIn

Uma visão mais clara da UML Sumário

Manual Ilustrado Utilitários Controle de Infecção Hospitalar

COTAÇÃO DE COMPRAS COM COTAÇÃO WEB

1223o TUTORIAL PRÉ-VENDA. Realização: DEPARTAMENTO DE IMPLANTAÇÃO EQUIPE DE DOCUMENTAÇÃO

Aleph. Entre Bibliotecas. Reunião da REJE 09 de novembro de 2011

04/07/2015 UML. Prof. Esp. Fabiano Taguchi DEFINIÇÃO DE REQUSIITOS

Análise de Tarefas. Análise Hierárquica de Tarefas

Manual de uso do Borderô Credix

ISO 9001: SISTEMAS DE GESTÃO DA QUALIDADE

INSCRIÇÃO ON- LINE REVEZAMENTOS A PARTIR DE 2015 INDICADO PARA TÉCNICOS

Processos de gerenciamento de projetos em um projeto

Sumário FPD Formulário de projeto P&D...4

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

Engenharia de Requisitos Estudo de Caso

MANUAL DA SECRETARIA

Instruções de Uso do sistema Sirc-Cartório

O planejamento do projeto. Tecnologia em Gestão Pública Desenvolvimento de Projetos Aula 8 Prof. Rafael Roesler

Manual do Usuário. Sistema para Administração de Condomínios MANUAL USUÁRIO. Bancos do Condomínio. ENG Sistemas - 1 -

PEDIDOS WEB MANUAL DO USUÁRIO

1. Acessando o SIGPRH

GUIA DO COORDENADOR DE PROJETOS

Perfil Chefe de Transporte

Renda Variável ETF de Ações. Renda Variável. ETF de Ações

SISTEMA DE GESTÃO DO PROGRAMA BOLSA FAMÍLIA

A SEGUIR ALGUMAS DICAS PARA O DESENVOLVIMENTO DE UM PROJETO CIENTÍFICO

ECONTEXTO. Auditoria Ambiental e de Regularidade

Eduardo Bezerra. Editora Campus/Elsevier

Projeto da Disciplina Parte1: Estudo de Viabilidade. Um Estudo de Viabilidade

1. Funcionalidades da opção SAC 1

Sistema Integrado de Atendimento

paradigma WBC Public - compra direta Guia do Fornecedor paradigma WBC Public v6.0 g1.0

Escopo do Copilot Optimize - Elaboração de Relatórios

1. REGISTRO DE PROJETOS

PROJETO DE REDES

Sistema Ativo de Segurança Automotiva

LGTi Tecnologia. Manual - Outlook Web App. Soluções Inteligentes. Siner Engenharia

Manual do Usuário do Produto EmiteNF-e. Manual do Usuário

Especificação de Requisitos

Manual do Teclado de Satisfação Online WebOpinião

Leslier Soares Corrêa Estácio de Sá / Facitec Abril/Maio 2015

Manual do Usuário - ProJuris Web - Biblioteca Jurídica Página 1 de 20

NORMA BRASILEIRA DE CONTABILIDADE NBC TSC 4410, DE 30 DE AGOSTO DE 2013

Documento de Requisitos

Instruções para preenchimento do formulário Plano de Ação do Projeto. Secretaria - Escreva o nome da secretaria coordenadora do projeto.

Associados Comerciais estabelecidos fora dos Estados Unidos Número da Política: LEGL.POL.102

Manual do Sistema de Almoxarifado P á g i n a 2. Manual do Sistema de Almoxarifado Geral. Núcleo de Tecnologia da Informação

GUIA RÁPIDO DE UTILIZAÇÃO DO SIGPROJ VERSÃO USUÁRIO

MANUAL DIPAM A Versão de 10/05/2012

1. Release 10.2/ Instalação/ Logix Update 10.2/ Inovação 10.2/

Transcrição:

COLÉGIO ESTADUAL ULYSSES GUIMARÃES CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA ERINALDO SANCHES NASCIMENTO MODELAGEM DO SISTEMA: DIAGRAMA DE ATIVIDADES FOZ DO IGUAÇU 2013

LISTA DE FIGURAS FIGURA 1 DIAGRAMA DE ATIVIDADES DE UM SISTEMA DE CONSULTA.... 6 FIGURA 2 DIAGRAMA DE ATIVIDADES PARA AVALIAR PEDIDOS DE UMA COMPRA.... 8 FIGURA 3 DIAGRAMA DE ATIVIDADES DE APOIO TÉCNICO.... 9 FIGURA 4 ENVIAR CONTA APÓS 3 DIAS DA EXPEDIÇÃO DO PEDIDO.... 10 FIGURA 5 EVENTO TEMPORAL PARA ATUALIZAR A BARRA DE PROGRESSO.... 10 FIGURA 6 A ATIVIDADE PREPARAR PLACA-MÃE CHAMA A ATIVIDADE INSTALAR CPU.... 11 FIGURA 7 PROCESSO DE APROVAÇÃO DE PEDIDO.... 12 FIGURA 8 USO DE COMENTÁRIO PARA ESPECIFICAR UMA TRANSFORMAÇÃO.... 12 FIGURA 9 MUDANÇA DO OBJETO PEDIDO DE PENDENTE PARA APROVADO.... 12 FIGURA 10 PEDIDO COMO ENTRADA E SAÍDA DE UMA ATIVIDADE.... 12 FIGURA 11 AUTORIZAÇÃO DE UMA COMPRA POR CARTÃO DE CRÉDITO.... 13

SUMÁRIO 6. MODELAGEM DO SISTEMA: DIAGRAMAS DE ATIVIDADE... 3 6.1 MODELAGEM DO PROCESSO DE NEGÓCIO... 4 6.1.1 Elementos de um Diagrama de Atividade... 5 6.1.2 Atividades e ações... 6 6.1.3 Decisões e Junções... 7 6.1.4 Partições (Swinlanes)... 7 6.1.5 Eventos de tempo... 10 6.1.6 Chamando Outras Atividades... 10 6.1.7 Objetos... 11 6.1.8 Enviar e Receber Sinais... 13 6.2 DIRETRIZES PARA CRIAÇÃO DE DIAGRAMAS DE ATIVIDADES... 13 6.3 EXERCÍCIOS... 15 6.4 REFERÊNCIA BIBLIOGRÁFICA... 17

3 6. MODELAGEM DO SISTEMA: DIAGRAMAS DE ATIVIDADE Um diagrama de atividade pode ser usado para qualquer tipo de atividade de processo de modelagem. Modelos de processos descrevem como um sistema de negócio opera. Ilustram os processos ou atividades que são realizadas e como os objetos (dados) se movem entre eles. Um modelo de processo pode ser usado para documentar o sistema corrente, isto é, como é o sistema, ou o novo sistema em desenvolvimento, computadorizado ou não. Um caso de uso é uma maneira formal de representar a maneira pela qual um sistema de negócios interage com o seu ambiente. Ele ilustra as atividades realizadas pelos usuários do sistema. Como tal, a modelagem de caso de uso é muitas vezes visto como uma visão externa ou funcional do processo de negócio na medida em que mostra como os usuários veem o processo, em vez de os mecanismos internos pelos quais o processo e sistemas de apoio atuam. Diagramas de atividades e de casos de uso são modelos lógicos modelos que descrevem as atividades do domínio do negócio, sem sugerir como eles são conduzidos. Modelos lógicos são muitas vezes referidos como modelos de domínio do problema. Lendo um diagrama de atividade ou de caso de uso, em princípio, não deve indicar se uma atividade é informatizada ou manual, se um pedaço de informação é coletada por formulário em papel ou através da Internet, ou se a informação é colocada em um armário ou em um banco de dados. Estes detalhes físicos são definidos durante o projeto, quando os modelos lógicos são refinados em modelos físicos. Estes modelos fornecem informações que são necessárias para construir o sistema. Ao se concentrar primeiro em atividades lógicas, os analistas podem se concentrar em como o negócio deve ser executado sem se distrair com detalhes de implementação. Como primeiro passo, a equipe do projeto reúne os requisitos dos usuários. Em seguida, com os requisitos reunidos, a equipe do projeto modela o processo global de negócios utilizando diagramas de atividade. Em seguida, a equipe usa as atividades identificadas para identificar os casos de uso que ocorrem no negócio. Eles, então, preparar casos de uso de descrições e diagramas de caso de uso para cada caso de uso. Os usuários que trabalham de perto com a equipe do projeto criam os modelos de processos de negócio na forma de diagramas de atividades e

4 descrições de casos de uso que contêm todas as informações necessárias para começar a modelar o sistema. Uma vez que os diagramas de atividades e as descrições de casos de uso estão preparados, os analistas de sistemas transformam-nos em um diagrama de casos de uso. Em seguida, o analista normalmente cria diagramas de classe para criar um modelo estrutural do domínio do problema de negócio. 6.1 MODELAGEM DO PROCESSO DE NEGÓCIO Modelos de processos de negócios descrevem diferentes atividades que, quando combinadas, suportam um processo de negócio. Processos de negócio normalmente atravessam departamentos funcionais (por exemplo, a criação de um novo produto vai envolver diversas atividades que combinam os esforços de muitos funcionários em muitos departamentos). Além disso, a partir de uma perspectiva orientada a objetos, elas atravessam vários objetos. O único problema potencial de construção de modelos de processos de negócios, a partir de uma perspectiva de desenvolvimento de sistemas orientado a objetos, é que eles tendem reforçar uma mentalidade decomposição funcional. No entanto, na medida em que são utilizados de forma adequada, eles são uma ferramenta muito poderosa para comunicar o entendimento atual do analista com os requisitos dos usuários. Um processo de negócio é um conjunto de tarefas coordenadas que permitem atingir um objetivo de negócio, tais como expedição de pedidos de clientes. Algumas ferramentas de Gerenciamento de Processos de Negócio (Business Process Management BPM) permitem definir os processos de negócios utilizando os diagramas de atividades usando uma notação gráfica fácil. Diagramas de atividades são usados para modelar o comportamento de um processo de negócio independente dos objetos. Em muitos aspectos, os diagramas de atividades podem ser vistos como diagramas de fluxo de dados (DFD) sofisticadas que são usados em conjunto com a análise estruturada. No entanto, ao contrário dos diagramas de fluxo de dados, os diagramas de atividades incluem a notação que aborda a modelagem de atividades paralelas, simultâneas e processos de decisão complexos. Como tal, os diagramas de atividades podem ser usados

5 para modelar tudo a partir de um fluxo de trabalho de alto nível que envolve muitos casos de uso diferentes, para os detalhes de um caso de uso individual, todo o caminho até os detalhes específicos de um método individual. Em poucas palavras, diagramas de atividades podem ser usados para modelar qualquer tipo de processo. 6.1.1 Elementos de um Diagrama de Atividade Os diagramas de atividades retratam as principais atividades e as relações entre as atividades de um processo. Ação: peça simples de comportamento, não decomposta. Atividade: representa um conjunto de ações. Nó de objeto: representa um objeto que está ligado a um conjunto de fluxos de objetos. Fluxo de controle: mostra a sequência de execução. Fluxo de objeto: mostra o fluxo de um objeto a partir de uma atividade (ou ação) para outra atividade (ou ação). Nó inicial: retrata o início de um conjunto de ações ou atividades. Nó final de atividade: interrompe todos os fluxos de controle e de objeto em uma atividade (ou ação). Nó final de fluxo: interrompe um fluxo de controle específico ou de objeto. Nó de decisão: representa uma condição de teste, garantindo que o fluxo de controle ou de objeto só vai continua em um caminho. É rotulado com os critérios de decisão para continuar o caminho específico. Nó de junção: retorna diferentes caminhos de decisões que foram criados usando um nó de decisão. A Figura 1 representa um diagrama de atividades que modela o processo de um sistema de consulta. Nele é possível observar a representação gráfica dos elementos de um diagrama de atividades.

6 Figura 1 Diagrama de atividades de um sistema de consulta. 6.1.2 Atividades e ações A palavra atividade é muitas vezes erroneamente usada em vez de ação para descrever um passo em um diagrama de atividade, mas não são as mesmas coisas. A atividade é o processo que está sendo modelado. A ação é um passo na atividade global. Ações e atividades são executadas por alguma razão específica do negócio. Ações e atividades podem representar um comportamento manual ou computadorizado. Eles são representados em um diagrama de atividades como um retângulo arredondado.

7 Devem ter um nome que começa com um verbo e termina com um substantivo. Os nomes devem ser curtos, mas conter informações suficientes para que o leitor possa facilmente entender exatamente o que elas fazem. A única diferença entre uma ação e uma atividade é que uma atividade pode ser decomposta ainda mais em um conjunto de atividades e/ou ações, enquanto que uma ação representa um simples pedaço não divisível do comportamento global que está sendo modelado. Normalmente, apenas as atividades são utilizadas para o processo de modelagem do negócio ou do fluxo de trabalho. Além disso, na maioria dos casos, cada atividade está associada a um caso de uso. Exemplo de atividade: lavar o carro. Exemplos de ações relacionadas à atividade: ensabolar, enxaguar, secar. 6.1.3 Decisões e Junções Os nós de decisão e junção apoiam a modelagem da estrutura de decisão de um processo de negócio. As decisões são usadas para executar uma sequência diferente de ações dependendo de uma condição. O nó de decisão é usado para representar a condição de teste real que determina qual dos caminhos que saem do nó de decisão é para ser seguido. Neste caso, cada caminho de saída deve ser rotulado com uma condição de guarda. Uma condição de guarda representa o valor do teste para que o caminho específico seja executado. O nó de junção é usado para retornar caminhos mutuamente exclusivos que foram divididos com base em uma decisão anterior. O diagrama de atividades representado pela Figura 2 avaliar pedidos, e é um exemplo de decisão e junção. 6.1.4 Partições (Swinlanes) As atividades podem envolver diferentes participantes, tais como diferentes grupos ou papeis em uma organização ou sistema.

8 Figura 2 Diagrama de atividades para avaliar pedidos de uma compra. Partições mostram qual participante é responsável por quais ações. As partições dividem o diagrama em colunas ou linhas e contem ações que são realizadas por um grupo responsável. As colunas ou linhas são muitas vezes referidas como swinlanes (raias). Em um fluxo de trabalho real, haveria atividades que deveriam ser associadas aos papéis das pessoas envolvidas no fluxo de trabalho (por exemplo,

9 funcionários ou clientes) e as atividades a serem realizadas pelo sistema de informação que está sendo criado. Esta associação de atividades com funções externas, os papéis internos, e o sistema é muito útil ao criar as descrições dos diagramas de casos de uso. Por exemplo, uma atividade de processamento de pedidos requer que o departamento de expedição envie os produtos e o departamento de contas cobre o cliente. A Figura 3 mostra a representação de um processo de apoio técnico, que requer diferentes níveis de suporte, incluindo 1º Nível de Suporte, Suporte Avançado, e Engenharia de Produto. Figura 3 Diagrama de atividades de apoio técnico.

10 6.1.5 Eventos de tempo Às vezes o tempo é um fator relevante em sua atividade. Você pode querer modelar um período de espera. Você também pode precisar modelar processos que começam em um intervalo de tempo regular. Um evento de tempo sem fluxos de entrada é um evento de tempo recorrente, ou seja, ele é ativado com a frequência. Um evento de tempo é uma forma alternativa para iniciar uma atividade. Use esta notação para modelar uma atividade que é lançada periodicamente. A figura 4 representa uma atividade que esperar três dias após expedir um pedido para enviar a conta. Figura 4 Enviar conta após 3 dias da expedição do pedido. Outro exemplo de evento temporal é uma atividade que realiza o backup semanal do sistema. Assim como atualizar a barra de progresso, como representado na Figura 5. Figura 5 Evento temporal para atualizar a barra de progresso. 6.1.6 Chamando Outras Atividades O diagrama pode se tornar muito grande, ou a mesma sequência de ações pode ocorrer mais de uma vez. Quando isso acontece, para melhorar a legibilidade, pode-se fornecer detalhes de uma ação em um diagrama separado, permitindo que o diagrama de nível superior permanecer menos desordenado. Um nó de atividade de chama a atividade correspondente ao nome do nó, semelhante à chamada de um procedimento de software. Associando um nó de chamada à atividade com a atividade que invoca, dando-lhes o mesmo nome.

11 Chamadas a atividades essencialmente quebram uma ação em mais detalhes, sem ter que mostrar tudo em um diagrama. Embora seja aceitável omitir o quadro de atividade de nível superior para atividades, deve-se sempre mostrá-lo para as atividades invocadas. O nome da atividade no quadro de atividade ajuda a associar atividades invocadas com o invoker (invocador). A Figura 6 representa uma atividade de preparar a placa-mãe. Figura 6 A atividade preparar placa-mãe chama a atividade instalar CPU. 6.1.7 Objetos Objetos de dados são aspectos importantes do processo que está sendo modelado. Suponha que uma empresa decide vender um Sistema Gerenciador de Conteúdo como um produto comercial, e o desenvolvedor deseja definir um processo para a aprovação de pedidos recebidos. Cada passo no processo final de aprovação terá informações sobre o pedido, informações de pagamento e custo de transação. Isto pode ser modelado no diagrama de atividades com um objeto Pedido, que contém as informações de pedido necessárias para as etapas. Os objetos não precisam ser objetos de software. Um nó de objeto pode ser utilizado para representar um pedido de trabalho físico que inicia o processo. A Figura 7 mostra o objeto Pedido passando através do processo de aprovação de pedido.

12 Figura 7 Processo de aprovação de pedido. O objeto Pedido é a entrada para a ação aprovar pagamento e a saída da ação receber a ordem. A Figura 8 especifica que a ação de Aprovar Pagamento requer o objeto Custo como entrada e mostra como estes dados são obtidos a partir do objeto Pedido utilizando um comentário. Figura 8 Uso de comentário para especificar uma transformação. O foco do diagrama apresentado na Figura 9 é a mudança de estado do objeto Pedido em todo o processo para aprovação. Figura 9 Mudança do objeto pedido de pendente para aprovado. Além de atuar como entradas e saídas de ações, nós de objetos podem ser entradas e saídas de uma atividade. Esta notação é útil para enfatizar que toda a atividade requer entrada e fornece saída. A Figura 10 representa nós de objetos que são entradas e saídas de uma atividade. Figura 10 Pedido como entrada e saída de uma atividade.

13 6.1.8 Enviar e Receber Sinais As atividades podem envolver interações com pessoas, sistemas ou processos externos. Por exemplo, ao autorizar um pagamento com cartão de crédito, é preciso verificar o cartão através da interação com um serviço de aprovação fornecido pela empresa de cartão de crédito. A Figura 11 exemplifica uma atividade para aprovar uma compra com cartão de crédito. Figura 11 Autorização de uma compra por cartão de crédito. Em diagramas de atividades, os sinais representam interações com participantes externos. Os sinais são mensagens que podem ser enviadas e recebidas. O recibo de um pedido solicita que um processo de manipulação comece (recebido). O clique de um botão faz com que o código associado ao botão execute (recebido). O sistema notifica o cliente que o seu embarque foi adiado (enviada). Um sinal de recepção tem o efeito de despertar uma ação no diagrama de atividades. O destinatário do sinal sabe como reagir ao sinal e espera que o sinal chegue em algum momento, mas não sabe exatamente quando. Enviar sinais são sinais enviados para um participante externo. Quando a pessoa externa ou sistema recebe a mensagem, ele provavelmente faz algo em resposta, mas isso não é modelado em seu diagrama de atividades. 6.2 DIRETRIZES PARA CRIAÇÃO DE DIAGRAMAS DE ATIVIDADES 1. Um diagrama de atividades pode ser usado para modelar qualquer tipo de processo, por isso, o analista deve definir o contexto ou o âmbito da atividade

14 que está sendo modelado. Depois de determinar o escopo, o analista deve dar ao diagrama um título apropriado. 2. Identificar as atividades, fluxos de controle e fluxos de objetos que ocorrem entre as atividades. 3. Identificar quaisquer decisões que fazem parte do processo que está sendo modelado. 4. Tentar identificar quaisquer perspectivas de paralelismo no processo. 5. Desenhar o diagrama de atividade. Ao desenhar um diagrama de atividade, o diagrama deve ser limitado a um único nó inicial que inicia o processo a ser modelado. Este nó deve ser colocado na parte superior esquerda ou parte superior do diagrama, dependendo da complexidade do diagrama. Além disso, para a maioria dos processos de negócios, deve haver apenas um nó final único da atividade. Este nó deve ser colocado na parte inferior direita ou na parte inferior do diagrama. Como a maioria dos processos comerciais de alto nível é sequencial, não paralelo, a utilização de um nó de fluxo final deve ser limitado. Ao modelar processos de negócios de alto nível ou fluxos de trabalho, apenas as decisões mais importantes devem ser incluídas nos diagramas de atividades. Nesses casos, as condições de guarda associados com as saídas dos nós de decisão devem ser mutuamente exclusivas. Além disso, as saídas e condições de guarda devem formar um conjunto completo (todos os valores potenciais da decisão estar associados com um dos fluxos). As atividades no diagrama devem ser definidas em uma ordem da esquerda para a direita e/ou de cima para baixo, com base na ordem em que as atividades são executadas. Qualquer atividade que não tem quaisquer saídas ou quaisquer entradas deve ser recusada. Atividades sem saídas são referidas como atividades buracos negros. Se a atividade é verdadeiramente um ponto final no diagrama, a atividade deve ter um fluxo de controlo a partir dela para uma atividade final ou nó de fluxo final.

15 6.3 EXERCÍCIOS 1. Analise o Diagrama de Casos de Uso abaixo, referente a um módulo de matrícula e construa um Diagrama de Atividades para demonstrar a modelagem dos processos de negócio. 2. Leia e interprete a descrição do caso de uso abaixo e complete 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 principal: aluno. Pré-condição: a atendente deverá estar devidamente identificada pelo sistema. 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.

16 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. 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 do aluno 1. A atendente solicita a 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 a 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 a solicitação do aluno. Restrições e validações: 1. Nenhum campo poderá ser deixado em branco. 2. O campo CPF deverá ser preenchido somente com números. 3. O ano de nascimento deverá ser informado com 4 dígitos. 3. 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 existem 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.

17 4. Faça um Diagrama de Atividades para um sistema de vídeo locadora equivalente ao módulo de Locação de Mídia de Filmes considerando as seguintes regras: O cliente (sócio) deve informar se código de cadastro ou, caso não lembre, seu nome. O atendente checará a existência do registro do sócio e, caso não exista, sua locação será recusada. Caso o cliente esteja cadastrado, o sistema irá verificar se existe alguma locação pendente e, em caso afirmativo, a locação será recusada. Se o sistema não apresentar pendências do cliente, o atendente irá efetuar a locação, registrando o s itens (cópias de filmes) locados na mesma. 5. Faça um Diagrama de Atividades para um sistema de venda de passagens aéreas. 6. O cliente deve selecionar o local de origem (aeroporto e cidade). Em seguida selecionar o destino (aeroporto e cidade). Após isso, o cliente fará a consulta de todos os voos que estejam disponíveis. Caso o valor e horário satisfaça o cliente, este comprará uma passagem ou encerrará o processo. Se o cliente optar por comprar uma passagem, este deverá se identificar ou criar um novo registro. Em seguida, selecionar a forma de pagamento por meio da qual deseja pagar a passagem. Após, a passagem será gerada. 6.4 REFERÊNCIA BIBLIOGRÁFICA DENNIS, Alan; WIXON, Barbara H.; TEGARDEN, David. System Analysis Design UML Version 2.0, An Object-Oriented Approach, 3 rd Ed. USA: John Wiley & Sons, Inc. 2009. GOMMA, Hassan. Software Modeling and Design: UML, Uses Cases, Patterns, and Software Architectures. USA: Cambridge University Press, 2011.

LANGER, Arthur M. Guide to Software Development: Designing and Managing the Life Cycle. USA: Springer, 2012. 18