Unified Modeling Language UML
Requisito Ator Caso de uso Associações Entre atores e casos de uso Entre casos de uso Inclusão: estereótipo <<include>> Extensão: estereótipo <<extend>> Generalização Diagrama de casos de uso Especificação de casos de uso
Faça uma breve pesquisa na Web sobre requisitos procurando compreender sua importância, principais características e a divisão conceitual entre requisitos funcionais e não funcionais.
Importância Características Claro Completo Preciso Classificação Funcionais Não funcionais
É qualquer entidade que interage com o sistema Pode ser um usuário, um hardware externo, outro sistema Representa uma classe de usuários (papel), não um usuário específico Algo sobre o que o sistema não tem controle
Várias pessoas podem ser representadas por um único ator Bruno é um cliente Caixa Correntista Ana Lúcia Eletrônico é uma cliente Sacar Dinheiro
Uma pessoa pode atuar como mais de um ator. Fulano é um cliente Correntista Caixa Fulano também é responsável pelo abastecimento da máquina Eletrônico Técnico responsável
Agrupe os indivíduos segundo a utilização do sistema Identifique os papéis que eles assumem ao utilizar o sistema: cada papel é um ator em potencial Cargo nem sempre é um papel Escolha nomes conhecidos dos usuários: não invente!
Nomes ruins INSS Recepcionista IN Cadastro de Títulos Paulo Bons nomes Auditor
Um Caso de Uso é a relação de uma seqüência de ações que um sistema executa produzindo um resultado de valor observável para um ator específico. Rational Unified Process RUP
Modela um diálogo entre ator e sistema Define o comportamento de um sistema ou de parte dele Descreve passo a passo como o sistema desempenha suas funções Possui cenários (instâncias) Define respostas que o sistema deve gerar para cada evento previsto Deve possuir uma especificação
Para cada um dos estudos de caso dados levante uma lista de atores e casos de uso Para cada um dos atores, pergunte: O <ator> usa o sistema para quê? Depois, relacione o ator com os seus casos de uso. No sentido oposto, para cada caso de uso, pergunte: Quem faz uso direto do <caso de uso>? Atualize e relacione as listas levantadas
Descrição Pré-condição Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo n Pontos de Extensão Pós-condição
Apresenta uma breve descrição do objetivo do caso de uso. Exemplo: Este caso de uso descreve o procedimento de saque de dinheiro em um caixa eletrônico.
É o estado do sistema requerido antes do caso de uso ser iniciado Deve ser um estado de valor mensurável; A pré-condição é uma restrição para o início do caso de uso e não o evento que inicia o caso de uso (um evento ter ocorrido pode ser uma pré-condição). Exemplo: Cliente identificado corretamente. Cliente ter solicitado a operação de saque.
Uma pós-condição é o estado no qual o sistema deve estar ao término da execução do caso de uso Deve ser um estado de valor mensurável Exemplo: Cartão devolvido ao cliente.
São os caminhos possíveis no diálogo atorsistema durante a execução do caso de uso: instância de um caso de uso Fluxo principal (ou básico) Fluxo onde tudo dá certo ; o mais freqüente Fluxos alternativos Variações na execução do fluxo básico Fluxos de exceção Erros que podem ocorrer nos fluxos básico e alternativo
Pré-condição Fluxo Principal Fluxos Alternativos Pós-Condição
Exemplo: 1. O Cliente informa a opção de Saque. 2. O Sistema solicita o valor do saque. 3. O Cliente informa o valor e confirma a operação. 4. O Sistema verifica o valor informado. 5. O Sistema verifica o saldo do cliente. 6. O Sistema debita o valor sacado do saldo do cliente. 7. O Sistema entrega o dinheiro. 8. Fim do caso de uso.
Exemplos: A1. Saldo insuficiente 1. No passo 5 do fluxo básico o Sistema verificou que o cliente não possui saldo. 2. O Sistema informa o saldo disponível. 3. O caso de uso volta para o passo 8 do fluxo básico. A2. Valor informado inválido 1. No passo 4 do fluxo básico o sistema verificou que o valor informado é inválido. 2. O sistema informa que o valor é inválido. 3. O sistema informa as regras para valores válidos. 4. O caso de uso volta para o passo 2 do fluxo básico.
Detalhes da interface gráfica com usuário GUI (útil apenas para protótipos) Objetivos de performance (requisito não funcional) Detalhes da arquitetura da aplicação: módulos, menus, componentes Quaisquer requisitos não funcionais: eventualmente, podem ser inserido por meio de notas explicativas
... O ator clica no botão OK...... O sistema exibe um JTable com os...... A resposta deverá ser retornada em menos de 10 segs...... O sistema inicia uma conexão com o servidor de aplicação...... O usuário deverá informar os códigos por meio da caneta ótica...
Identifique as interações do usuário: concentre-se nos objetivos do usuário: Sacar dinheiro... Transferir dinheiro entre contas... Cadastrar contas de débito automático... Descreva o quê o usuário espera do sistema Descreva as operações que criam, lêem, atualizam e excluem informações (manter, CRUD, etc.); Descreva como os atores são notificados sobre alterações de estado do sistema; Descreva como o ator necessitará informar ao sistema eventos ocorridos.
Crie listas de verificação e validação (V&V): O sistema fornece o comportamento correto às necessidades do negócio? Todas as necessidades são resolvidas pelos Casos de Uso que você identificou? Quais Casos de Uso suportarão as principais funcionalidades do sistema? Quais informações devem ser modificadas ou criadas no sistema? Aplicar as Listas de V&V para os casos de uso encontrados
Use uma frase que especifique o objetivo do ator Técnica O ator usa o sistema para... Utilize verbos concretos, fortes, ao invés de verbos genéricos e fracos, exemplos: Verbos fortes: criar, calcular, migrar, receber, arquivar, registrar e ativar Verbos fracos: fazer, relatar, controlar, gerenciar, administrar, organizar e processar Seja explícito Use termos específicos: Termos genéricos: formulário, dado e sistema Termos específicos: propriedade, pagamento e conta
Boas escolhas Depositar Dinheiro Conferir Movimentação Bancária Transferir Valores entre Contas Correntes Escolhas ruins Controle de Saque Controle de Saldo Transferência Bancária Gerir Algo Gestão Disso ou Daquilo
O cliente pode usar o caixa automático para sacar e transferir dinheiro e consultar o saldo Ator: Cliente Casos de uso: Sacar Dinheiro Transferir Dinheiro Consultar Saldo
Como base nas listas de casos de uso levantadas, crie um fluxo principal (ou básico) para cada um dos casos de uso. DEPOIS, estude e defina os fluxos alternativos convenientes para o funcionamento seguro do sistema. Para simplificar, considere os fluxos de exceção (ou de erro) como fluxos alternativos.
Indicar que o ator participa e se comunica com o sistema, conforme descrito no caso de uso A seta, quando houver, indica quem inicia a comunicação, não demonstram fluxo e setas duplas não são usadas
Seta do ator para o caso de uso: Ator dispara o caso de uso Ator estimula o sistema Ator principal Consultar Saldo Correntista
Seta do caso de uso para o ator: Sistema solicita ou envia informações Sistema sinaliza que espera uma ação do ator Ator secundário Consultar Saldo Correntista Sistema Mainframe
Sacar Dinheiro Correntista Depositar Dinheiro Pagar Título Técnico do Suporte Abastecer Numerário
Surgem da fatoração de casos de uso Três tipos: Inclusão <<include>> Extensão <<extend>> Generalização Objetivos: Reuso de parte do caso de uso Especialização de comportamento Descrição de procedimentos opcionais
Aluno Consultar Disponibilidade Atualizar Financeiro <<extend>> <<include>> Inscrever-se em Curso
A execução do caso de uso incluído é obrigatória O caso de uso base depende do caso de uso incluído Nem o caso de uso base, nem o incluído, acessam os atributos um do outro (baixo acoplamento) A inclusão é, na essência, um tipo de encapsulamento
No sistema de Caixa Bancário, os casos de uso Sacar, Depositar e Transferir precisam indicar que o cliente será identificado no sistema. Este comportamento pode ser fatorado em um caso de uso chamado Identificar Cliente, que os três casos de uso incluem. Da perspectiva dos casos de uso base, não importa qual método é utilizado para a identificação, se senha, cartão, identificação de retina, mas apenas o resultado. Da perspectiva do caso de uso incluído, não importa qual caso de uso o está utilizando (incluindo) ou como o resultado será processado.
Identificar Cliente <<include>> <<include>> <<include>> Sacar Dinheiro Transferir entre Contas Depositar Dinheiro
O comportamento incluído é inserido em uma localização específica do caso de uso base e é executado quando este passo é atingido. Caso de Uso base Instância Caso de Uso incluído
Indica que uma parte do caso de uso é um comportamento opcional do sistema Para mostrar que um comportamento é executado somente sob certas condições Para mostrar que podem existir tipos de comportamento que serão inseridos no caso de uso dependendo da interação do ator com o caso de uso
O caso de uso de extensão é inserido no caso de uso base em locais específicos chamados Pontos de extensão O caso de uso extensor depende do caso de uso estendido.
No sistema de Caixa Bancário, quando o cliente for identificado, o sistema precisa saber se ele já adquiriu seguro contra roubo de cartão e, caso negativo, oferecer a aquisição do seguro. Podemos demonstrar isso com a criação de um caso de uso chamado Adquirir Seguro que estende a funcionalidade de Identificar Cliente.
Identificar Cliente <<extend>> Aquirir Seguro
Quando a execução do caso de uso atinge o ponto de extensão, a condição do caso de uso é avaliada, e se for verdadeira o caso de uso é executado. Caso de Uso base Instância Ponto de extensão Caso de Uso <<extend>>
Freqüentemente nos deparamos com a dúvida entre um fluxo alternativo e um caso de uso estendido. Considerar o seguinte: O fluxo alternativo é complexo ao ponto de confundir o entendimento do caso de uso? A condição para execução do fluxo é muito excepcional? O valor semântico do modelo com extensão fica aprimorado?
Destacar o comportamento comum a mais de um caso de uso, mas com algumas particularidades adicionais Demonstrar formas mais específicas de comportamento do um caso de uso Relacionamento do tipo é-um entre um caso de uso base (pai) com um ou mais casos de uso filhos
Semelhante a herança entre classes O filho herda toda a estrutura, comportamento e relacionamentos do pai; O filho é totalmente dependente da estrutura do pai.
No caso de uso Cobrança de Pênalti, podem ser representados: (1) a cobrança de pênalti em tempo regulamentar e (2) a cobrança de pênalti como desempate. Esses dois casos de uso têm muito do seu comportamento em comum, mas com uma particularidade: a reposição da bola, que deve ser posta em jogo (1) ou não (2).
Cobrança de Penalti Cobrança de Penalti em tempo regulamentar Cobrança de Penalti em desempate
Cobrança de pênalti... 5. O Jogador cobra o pênalti 6. A bola entra no gol
Cobrança de pênalti no tempo regulamentar 1. O caso de uso base é executado até o item 6 2. O Juiz posiciona a bola no centro do campo para reinício da partida Cobrança de pênalti para desempate 1. O caso de uso base é executado até o item 6 2. O Juiz posiciona a bola para a próxima cobrança
O caso de uso pai é executado quando, no fluxo do caso de uso filho, existe generalização O caso de uso filho é executado quando, no fluxo do caso de uso pai, existe especialização Caso de Uso Pai Instância do Caso de Uso Caso de Uso Filho
É criado para representar o conjunto de associações entre atores e casos de uso e entre casos de uso São casos de uso associados que descrevem todas as formas de uso do sistema Fornece uma visão das funcionalidades de um sistema: ajuda a capturar os requisitos funcionais Constitui uma forma de comunicação bastante útil entre projetistas e clientes Ajuda na identificação de objetos, na execução de testes e na documentação
Indica que tipo de usuário (ator, perfil) usa quais funcionalidades: o quê o sistema deve fazer e para quem Deve ser completo: todas as funcionalidades devem estar presentes, mesmo que em diagramas separados que compõem o sistema É uma visão de alto nível: perspectiva externa e dos atores O mais informal dos diagramas da UML
Trata-se de uma representação dinâmica: é importante para a organização e modelagem de comportamentos do sistema Não há decomposições funcionais (explosões) Devem ter a complexidade controlada, podendo ser organizados de acordo com sua relevância, freqüência de utilização e valor para os usuários
Na locadora, os funcionários são identificados por CPF, nome, endereço, telefone. Já os veículos estão divididos em: popular, luxo e utilitário. Sobre os veículos deve-se saber: placa, tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel diário e semanal. Os funcionários serão responsáveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para um cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e uma quilometragem extra. O cliente é identificado por RG, nome, CPF, telefone, endereço, cidade. O cliente solicita o aluguel de veículo a um funcionário.
Alugar Carro: cliente solicita ao funcionário o aluguel do carro. O sistema verifica se o carro solicitado pelo cliente está disponível. Caso esteja, o processo de locação é concluído e o carro passa a estar indisponível. A data de aluguel deve ser guardada para cálculo do valor do aluguel na devolução. Dar Baixa: cliente faz devolução do carro para o funcionário e solicita nota fiscal com a quilometragem percorrida e o valor do aluguel. O funcionário coloca o status do carro novamente como disponível, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente.
Cadastrar Cliente: cliente solicita ao funcionário que o cadastre na locadora. O funcionário recebe os dados e efetua o cadastramento. Cadastrar Carro: funcionário cadastra o carro adquirido.
Sistema deve permitir: 1. o cadastro de usuários on-line 2. que o usuário se identifique 3. consultar a classe de vôo 4. consultar o trecho da viagem 5. consultar aeroportos 6. consultar as datas disponíveis de ida e volta 7. consultar as formas de pagamento 8. enviar aos usuários cadastrados e-mails promocionais 9. que usuário consulte o CEP no sistema dos correios 10. que o usuário faça a reserva on-line 11. gerar código de reserva 12. enviar e-mail para usuário confirmando a reserva com dados 13. que usuário cancele a reserva 14. que o administrador emita relatório de reservas confirmadas 15. que o administrador emita relatório de reservas canceladas 16. validar o pagamento com a operadora do cartão 17. que o administrador emita relatório de usuários cadastrados 18. que o usuário edite seus dados pessoais
Um cliente primeiramente se dirige à Clínica onde marca uma consulta com a secretária, fornecendo suas informações pessoais e do animal que deseja tratar. Se o cliente ou o animal ainda não estiverem cadastrados no sistema ou possuam algum dado que precise ser atualizado, a secretária deverá atualizar seus cadastros. Em cada sessão de tratamento (uma sessão equivale a uma consulta), o cliente deve informar os sintomas aparentes do animal e estes devem ser registrados. Um tratamento pode ser encerrado em apenas uma consulta, quando se tratar de algo simples ou pode se arrastar por muitas sessões dependendo do diagnóstico do médico-veterinário. Durante uma sessão o veterinário pode marcar exames para o animal, a serem trazidos na sessão seguinte, O pedido dos exames, bem como seus resultados devem ser registrados no histórico de tratamentos do animal. Após cada sessão, o histórico da consulta deve ser atualizado e gera-se uma conta a receber a ser paga pelo cliente. A manutenção das consultas é responsabilidade exclusiva do médico-veterinário que a realizou. É responsabilidade da secretária manter atualizados os cadastros de clientes, animais, médicos e espécies.
O sistema aceita submissões sobre diversos temas como Engenharia de Software, Banco de Dados, Hipermídia, sendo necessário, portanto manter um cadastro de todos os temas aceitos. Um autor pode realizar muitas submissões. Uma submissão pode constituir-se em um artigo, um mini curso ou palestra. As submissões só podem ser realizadas através da Internet. Ao acessar a página de submissão o autor pode logar-se, realizar uma submissão ou verificar a situação de trabalhos porventura já submetidos, no entanto, para poder utilizar os dois últimos serviços ele deverá antes executar o primeiro. Um autor deve registrar-se no sistema antes de poder se logar. Se já estiver registrado deverá então logar-se, informando seu login e senha. Toda submissão precisa ser avaliada por uma comissão de três avaliadores, responsável por analisá-la e fornecer notas. Um avaliador pode avaliar muitas submissões. As submissões são aprovadas de acordo com as maiores notas gerais. A nota geral de uma submissão será o resultado da média de todas as notas das avaliações de cada submissão. As n melhores notas de cada tema e tipo serão consideradas aprovadas. É necessário manter-se um cadastro de todos os avaliadores do congresso.
É responsabilidade do coordenador do evento definir quais avaliadores avaliarão quais submissões. E também responsabilidade do coordenador notificar os autores sobre a aceitação ou não de suas submissões no evento. O coordenador pode emitir o relatório das avaliações sempre que quiser, no entanto, a partir do momento em que selecionar a opção notificar autores, estes serão avisados se suas submissões foram ou não aprovadas. Sendo ou não aprovada, uma submissão pode ou não receber comentários dos avaliadores, referentes a possíveis alterações necessárias antes da submissão ser publicada e disponibilizada no congresso ou informações ao autor do por que da não aprovação de seu trabalho pelo avaliador. Um autor pode consultar o estado de suas submissões, ou seja, se elas estão ainda sob avaliação, foram aprovadas ou reprovadas. Um autor pode também, se assim o desejar, verificar os possíveis comentários dos avaliadores a respeito de uma submissão específica.
Observações Complementares: O Autor pode realizar login, registrar-se, realizar submissão, verificar submissões e verificar comentários. Observe que o Autor somente poderá se auto-registrar a partir a partir de uma tentativa realizar o login e assim mesmo se ainda não estiver registrado, o que indica o uso de uma associação e extensão. Da mesma forma, a consulta a comentários só pode ser feita a partir de uma consulta a submissões. A realização das submissões e o seu acompanhamento só podem ser feitos se o autor tiver logado. O avaliador para emitir seus comentários sobre as submissões deve ter informado sua avaliação previamente.
O aluno primeiramente solicita informações ao atendente sobre quais cursos a empresa oferece. Se o aluno se interessar por algum curso, pedirá informações a respeito de quais turmas, do curso em questão, estão abertas, qual o horário em que as aulas serão ministradas, qual a data prevista para início das aulas e qual o mínimo de alunos necessários para que uma turma inicie o curso. Caso o horário de alguma turma seja compatível com os horários do aluno, este realizará a matrícula em uma turma relativa ao curso em que se interessou. Caso o aluno nunca tenha feito nenhum curso na empresa e, portanto, não esteja cadastrado, o aluno deverá ser registrado antes de realizar a matrícula.
Um cliente (pessoa física ou jurídica que paga o advogado para defendêla ou para processar outra pessoa) procura o advogado. Se o cliente ainda não estiver cadastrado, o advogado deverá registrar seus dados pessoais. Em seguida, o cliente deve fornecer informações a respeito do processo que deseja que o advogado mova contra alguém ou que o defenda de outra pessoa. Obviamente o processo precisa ser registrado e receberá diversas adições enquanto estiver em andamento. O cliente deve fornecer também informações sobre a parte contrária (pessoa física ou jurídica que está processando ou sendo processada pelo cliente), que deverá também ser registrada, caso ainda não esteja. Observe que uma mesma pessoa física ou jurídica pode ser tanto um cliente como uma parte contrária em períodos diferentes, obviamente.
Um processo pode gerar custas (despesas com xérox, viagens etc.). Cada custa deve ser armazenada de forma a ser cobrada da parte contrária caso o processo seja ganho. Este sistema deve estar integrado a um sistema de contas a pagar e receber, cada custa gera uma conta a pagar. Caso o processo seja ganho, ele gerará uma ou mais contas a receber, dependendo da negociação com a parte contrária.
Crie um documento de requisitos hipotético e a partir dele encontre os atores e os casos de uso. Represente todas as associações em um diagrama de casos de uso, procurando identificar oportunidades para usar cada um dos tipos de associações.
Os casos de uso, mesmo no contexto de seus diagramas, são semanticamente limitados, dependendo de interpretação A especificação (documentação) é essencial para uma compreensão precisa Diagramas da UML, como o de atividades e o de seqüência, mais formais e precisos, podem ser usados na documentação O padrão de especificação, incluindo nível de detalhe exigido e informações obrigatórias, deve estar definido na metodologia
1. Descrição 2. Requisitos 3. Atores 4. Pré-condições 5. Evento que inicia 6. Fluxo Principal 7. Fluxos Alternativos 8. Extensões 9. Pós-condições 10. Regras de negócio
RF1 O sistema deve permitir a manutenção dos dados dos empregados, pelo gerente, conforme regras de negócio RN1 a RN6
RN1 Um empregado deve possuir obrigatoriamente os dados: código, nome, idade, data de admissão e estar associado a um cargo RN2 O código é o identificador do empregado na empresa e deve ser exclusivo RN3 O nome do empregado deve ser um nome válido de acordo com a legislação de registro de nascimentos
RN4 A idade deve ser um número inteiro maior ou igual a 16 e menor que 150 RN5 A data de admissão deve ser uma data válida, no formato dia, mês e ano e não pode ser posterior à data corrente, nem anterior à data corrente menos trinta dias RN6 O cargo do cliente deve ser selecionado entre os cargos cadastrados no sistema
Descrição: Permite consultar, incluir, alterar dados e excluir fisicamente empregados na base de dados do sistema Requisitos: RF1 Atores: Gerente Pré-condições: O ator deve estar identificado pelo sistema e ser um gerente Evento que inicia: Solicitação do ator Extensões e inclusões: não há
Pós-condições: A operação solicitada pelo ator é concluída com dados atualizados ou consultados, condicionado ao atendimento das regras de negócio Regras de Negócio: RN1 a RN6
Fluxo Principal: 1. O sistema lê todos os empregados e os apresenta com código, nome, idade e descrição do cargo, e as opções de consulta detalhada, alteração de dados, exclusão e inclusão 2. O ator encerra o sistema [A1] [A2] [A3] [A4] 3. Fim do Caso de Uso
Fluxos Alternativos: [A1] O ator escolhe um empregado para consulta detalhada 1. O sistema pesquisa e exibe todos os dados do empregado selecionado 2. O ator solicita retorno à relação de empregados 3. O sistema retorna ao passo 1 do fluxo principal
[A2] O ator escolhe um empregado para edição 1. O sistema pesquisa e exibe todos os dados do empregado selecionado, oferecendo as opções de edição dos dados exceto o código identificador 2. O ator edita os dados e solicita gravação [A5] 3. O sistema valida e grava os dados [A6] 4. O sistema retorna ao passo 1 do fluxo principal
[A3] O ator escolhe um empregado para exclusão 1. O sistema solicita confirmação 2. O ator confirma a exclusão [A7] 3. O sistema exclui o empregado e retorna ao passo 1 do fluxo principal
[A4] O ator escolhe a inclusão de um novo empregado 1. O sistema solicita os dados do empregado 2. O ator informa os dados e solicita gravação [A5] 3. O sistema valida e grava os dados [A6] 4. O sistema retorna ao passo 1 do fluxo principal
[A5] O ator solicita cancelamento da operação 1. O sistema retorna ao passo 1 do fluxo principal
[A6] Dados inválidos, conforme RN usadas no caso de uso 1. O sistema informa quais dados estão inválidos e porque 2. O sistema retorna à inclusão ou edição com os dados informados pelo usuário, mesmo que inválidos
[A7] O ator não confirma a exclusão dos dados 1. O sistema retorna ao passo 1 do fluxo principal