Aula 6 -_casos_de_uso
- 1. FUNDAMENTOS DE UML Profs: Edgar Gemo Zeferino Saugene UML
- 2. FUNDAMENTOS DE UML A Linguagem de Modelagem Unificada (Unified Modelling Language - UML) é uma linguagem de representação diagramática ou notação para especificar, visualizar e documentar modelos de sistemas de software Orientados à Objecto. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como desenhar seu sistema, mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objectos. A UML é controlada pelo Grupo de Gestão de Objecto (Object Management Group - OMG) e é um padrão da UML indústria para descrever graficamente software.
- 3. FUNDAMENTOS DE UML A UML é voltada para o desenho de software Orientado à Objecto e tem um uso limitado para outros paradigmas de programação. A UML é composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software. Os elementos UML são usados para criar diagramas, que representam um determinada parte, ou um ponto de vista do sistema. Os seguintes tipos de diagramas são suportados: Diagrama de Caso de Uso mostra actores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos; UML Diagrama de Classe mostra classes e os relacionamentos entre elas;
- 4. FUNDAMENTOS DE UML Diagrama de Sequência mostra objectos e uma sequência das chamadas do método feitas para outros objectos; Diagrama de Colaboração mostra objectos e seus relacionamentos, colocando ênfase nos objectos que participam na troca de mensagens; Diagrama de Estado mostra estados, mudanças de estado e eventos num objecto ou uma parte do sistema; Diagrama de Actividade mostra actividades e as mudanças de uma actividade para outra com os eventos ocorridos em alguma parte do sistema; Diagrama de Componente mostra os componentes de programação de alto nível (como KParts ou Java Beans); UML Diagrama de Distribuição mostra as instâncias dos componentes e seus relacionamentos.
- 5. Diagramas Use Cases Profs: Edgar Gemo Zeferino Saugene UML
- 6. Use Cases • Os Uses Cases ou ”casos de utilização” constituem em UML uma técnica para representar o levantamento de requisitos do sistema (Nunes, 2001) • Desde sempre que o correcto levantamento de requisitos no desenvolvimento de sistemas de informação tenta garantir que o sistema será útil para o utilizador final, estando de acordo UML com as suas necessidades (Nunes, 2001:13)
- 7. Requisito • O requisito num sistema é uma funcionalidade ou característica considerada relevante na óptica do utilizador (Nunes, 2001). UML
- 8. Requisitos • Os requisitos podem ser classificados em 3 categorias, de acordo com Bennet (2003): – Funcionais – Não funcionais – Facilidades de Utilização (Usability) UML
- 9. Requisitos Funcionais • Descrevem o que o sistema faz ou é esperado que faça. • Estes são os requisitos que inicialmente serão levantados, abrangendo a descrição de processamentos a efectuar pelo sistema, entradas e saídas de informação em papel ou em écran que derivam da interacção com pessoas e outros sistemas. UML
- 10. Requisitos Não Funcionais • Relacionados com as características qualitativas do sistema, descrevendo a qualidade com que o sistema deverá fornecer os requisitos funcionais. • Abrange medidas de desempenho como por exemplo, tempos de resposta, volume de dados ou considerações de segurança. UML
- 11. Requisitos de Facilidade de Utilização (Usability) • Garantem que existirá uma boa ligação entre o sistema desenvolvido, utilizadores do sistema e também as tarefas que desempenham utilizando o sistema UML
- 12. Diagrama de Use Case • Os diagramas de Use Case são utilizados para a apresentação de requisitos e para assegurar que tanto o utilizador final como o analista/desenvolvedor possuam um entendimento comum dos requisitos. • O seu objectivo é mostrar o que um sistema deve efectuar e não como o vai fazer. UML
- 13. Diagramas de Use Cases • São usados para modelar o contexto de um sistema, subsistema ou classe • São uma das maneiras mais comuns de documentar os requisitos do sistema – Delimitam o Sistema – Definem a funcionalidade do sistema UML
- 14. Diagrama de Use Case • Estes diagramas utilizam as seguintes abstracções de modelação: – Use Cases – Actores – Relações • Uses • Extends • Generalização UML
- 15. Use Case • Um Use Case deve definir o uso de uma parte da funcionalidade de um sistema, sem relevar a estrutura e o comportamento interno desse sistema UML
- 16. Use Case • Contém sequências de acções, interagindo com os actores que usam a aplicação • Inclui variantes, rotinas de erro, etc. que o sistema executa para produzir um resultado observável para um actor UML
- 17. Use Case: Representação Gráfica • A colecção dos use cases deverá especificar todas as formas existentes de uso do sistema Solicitar Verificar Matricular estudante histórico pré-requisitos UML
- 18. Actores • O sistema será descrito através de vários use cases que são executados por um número de actores. • Um actor representa uma entidade externa ao sistema que interage de alguma forma com um Use case. • Estes podem ser pessoas ou outros subsistemas que interagem com o sistema em UML desenvolvimento
- 19. Actores - Notação Sistema de controle de pre-requisitos UML Docente Secretária Estudante
- 20. Actores: Especialização • É possível definir tipos gerais de actores e especializá-los usando o relacionamento de especialização Cl ient e UML C li enteE s pec ial
- 21. Comunicação Actor – Use Case • A representação da comunicação entre um actor e os use cases pode ser uma simples linha recta ou recta cujas pontas indicam a direcção da comunicação: • Linha Recta Simples • Seta Unidireccional É normal usarmos tanto a primeira como a segunda alternativa. A primeira usa-se para casos mais simples, UML enquanto que a segunda para mais complexos.
- 22. Diagrama de Use Case Gerar Relatório Retornar Item Cliente Mudar Item Operador UML
- 23. Organizando Use Cases • Generalização • Inclusão - <<uses>> ou <<includes>> • Extensão - <<extends>> UML
- 24. Relação de <<uses>> • Os use cases podem estar relacionados entre si. • <<Uses>> significa que um determinado use case utiliza a funcionalidade disponibilizada num outro use case. • Alguns autores utilizam a relação <<includes>> em vez de <<uses>> UML
- 25. Relação de <<extends>> • A relação <<extends>> ocorre quando existe um comportamento opcional que deve ser incluído num use case. Este comportamento é definido num segundo use case e invocado pelo use case base, através de um mecanismo de pontos de extensão. UML
- 26. Generalização • A relação de generalização é utilizada quando existe um use case particular de um outro use case. • A generalização usufrui das mesmas propriedades que uma relação pai/filho, onde o use case “filho” herda ou substitui por completo o comportamento do use case “pai” UML
- 27. Estruturação Use Case Fazer Pedido Pontos de extensão Fazer Pedido Urgente set prioridade <<extends>> <<include>> Verificar é-um senha Validar usuário é-um Teste de retina Use Case Fazer Pedido Fluxo principal de eventos: inclui (Validar usuário). Receber do usuário os UML itens do pedido. (set prioridade). Submeter o pedido para processamento
- 28. Comparação entre Relacionamentos • A vantagem comum dos relacionamentos de inclusão, extensão e generalização é que eles possibilitam manter a descrição dos use cases o mais simples possível. • Porém, não se recomenda o uso em excesso destes relacionamentos, sob o risco de se obter um modelo de use case com vários relacionamentos e de difícil entendimento. UML
- 29. Comparação entre Relacionamentos • Uma dúvida comum é saber que tipo de relacionamento utilizar numa dada situação. Na verdade, não existem regras para saber quando utilizar um ou outro relacionamento; existem somente heurísticas: – Use inclusão quando o mesmo comportamento se repete em mais de um use case. Esse comportamento deve ser definido num novo use case, o chamado include use case. UML
- 30. Comparação entre Relacionamentos – Use extensão quando o comportamento opcional de um caso de uso tiver de ser descrito. Note que alguns cenários estendidos podem não usar esse comportamento opcional. O extensor faz referência ao estendido; o estendido não sabe que o extensor existe. – Use herança quando quiser identificar 2 casos de uso com comportamento semelhante e um deles for uma forma especial do outro. O caso de uso mais específico herda todo comportamento e relacionamento mais genérico, porém pode adicionar mais comportamento e ter seus próprios relacionamentos. O específico faz referência ao UML geral e o geral não sabe que ele existe.
- 31. Diagramas de Use Cases Solicitar <<extends>> Solicitar histórico do histórico semestre atual <<extends>> Solicitar histórico de todos os semestres Estudante Sistema de controle Matricular <<includes>> de pré-requisitos aluno Verificar dependências Secretária UML
- 32. Cenários • Cada use case identificado deve ser detalhado em termos de cenários de utilização. • Estes cenários são os possíveis caminhos seguidos dentro do use case, de forma a fornecer ao actor uma resposta (Sheneider e Winters, 1999) UML
- 33. Cenários • Um Cenário é uma execução específica de um use case; pode ser visto como uma instância de um use case. • Para cada use case podem existir diversos cenários • Estes cenários podem estar representados de 2 formas: • Forma Descritiva – descrição dos cenários usando um texto livre • Forma Estruturada – conjunto de passos numerados. Não existe uma estrutura padrão para esta forma, encontrando-se diversas formas diferentes de acordo com cada autor. • Esta descrição deve incluir todos os detalhes encontrados na análise (actores, dados, processo) de UML forma a aumentar a informação disponível
- 34. Descrição Estruturada Use case: Actor: Pré- Condição: Descrição: Variações: Pós- Condição: UML Descrição Estruturada de acordo com Larman (2001)
- 35. Exemplo de Descrição Estruturada Use case: Registar Inscrição Actor: Estudante, Secretaria Pré-Condição: Estudante está identificado pelo sistema Estudante requer inscrição Descrição: 1 – Estudante/secretaria solicita a realização da inscrição 2 – o sistema apresenta as disciplinas disponiveis para o semestre corrente 3 – o estudante/secretaria selecciona as disciplinas pretendidas e as submte-as para a inscrição 4 – O sistema valida a informação 5 – O sistema envia os dados do estudante para o sistema de facturação e envia mensagem de sucesso Variações: 4.1 – Informação Correcta 4.2 – Informação Incorrecta 4.3 – Informação Incompleta UML Pós-Condição: Estudante inscrito ou Mensagem de Erro
- 36. Exercicios • Considerando o sistema de registo académico do Ustm, descreva de forma estruturada o use case responsável pela inscrição de um estudante e o que regista um estudante no sistema e faca o diagrama de use case correspondente. • Suponha que existe um caso de uso Pagar Pedido num sistema, que é realizado por um actor Cliente. Neste caso de uso, o cliente realiza o pagamento de um pedido em algum momento do passado. Considerando este caso de uso, poderá pensar em algum outro caso de uso para este sistema? UML
- 37. Bibliografia • Bennett, S. et all (2002) object-oriented systems analysis and design using uml, U.S., Mc Graw-Hill Education • Bezerra, E. (2003), Princípios de Análise e Projecto de Sistemas com UML, Rio de Janeiro, Editora Campus Ltda • Neto, A.C. (2001), Análise e Projeto de Sistemas I, http://www.dcce.ufs.br • Nunes, M. e O´Neill (2001), Fundamental de UML, Lisboa, FCA - Editora de Informática • Larman, C. (2001); Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, USA, Prentice Hall PTR – 2ª Edição • Shneider, G. e winters, J. P. (1999), Applying Use Cases – A pratical guide, Addison Wesley UML