Análise e Projeto OO com UML. Lição 3 Especificação e Modelagem de Requisitos com UML

Transcrição

1 Análise e Projeto OO com UML Lição 3 Especificação e Modelagem de Requisitos com UML Prof. Fábio Bianchi Campos 1

2 Objetivos Gerais Apresentar as características básicas de uma especificação de requisitos; Apresentar os conceitos básicos da modelagem de requisitos, segundo a ótica dos Use Cases.; Apresentar o que são Use Cases e atores de requisitos; Apresentar os diagramas da UML que podem ser utilizados na modelagem de requisitos. 2

3 Roteiro O Levantamento de Requisitos e a Modelagem de Requisitos no Mastermodel; Conceitos básicos e caracterização das fases; Atividades das fases; Conceitos de Use Case e atores e UML para a fase; Os modelos da fase com exemplos; Verificações e a fase; Iterações e a fase; Referências. 3

4 Motivação Quando vamos desenvolver um sistema, precisamos inicialmente definir o que o sistema irá fazer antes de efetivamente iniciarmos o desenvolvimento; Precisamos entender os reais problemas que o sistema irá resolver; Precisamos saber claramente quem são as pessoas afetadas, direta e indiretamente pelo sistema; Para esclarecer os pontos acima que é criada uma especificação de requisitos. 4

5 Requisitos São características desejadas, propriedades, ou comportamentos de um sistema; É uma condição ou capacitação que um sistema ou componente do sistema precisa atender ou ter para satisfazer um contrato, especificação ou outro documento formalmente estabelecido. 5

6 Levantamento de Requisitos O que é: é a definição das características e propriedades desejadas para o sistema que será elaborado; Objetivos: Definir claramente o que se deseja do sistema a ser implementado; Quem participa: Contratantes do sistema, futuros usuários do sistema e analistas de requisitos; Técnicas utilizadas: Entrevistas e questionários, workshops de requisitos, interpretação de papéis, prototipação e outras. 6

7 Localização no MasterModel Início da Iteração n Fase: levantamento de requisitos Artefato: especificação de requisitos MasterModel (Simplificado) AF 1.1 AF 3.2 Diagrama de Classes Descrição do Negócio (Negócio) AF 3.4 Diagrama de Estados F1 F3 AF 3.3 Diagramas de Sequência (Negócio) Descrição Modelagem do do Negócio Negócio V1 V3 AF 6.1 Diagramas de Processadores e Processos AF 5.1 Diagramas de Sequência (Análise) F5 F6 AF 3.1 Modelos Use Cases (Negócio) Projeto da Análise Arquitetura de V5 Implementação V6 AF 4.2 Modelos de Interface AF 5.2 (Protótipo Visual) Diagrama de Classes (Análise) AF 4.3 Planilha Requisitos F2 F4 AF 6.2 Diagrama dos Subsistemas Levantamento Modelagem AF 6.3 de de Relatório de Projeto Requisitos Requisitos V2 V4 Este documento é parte integrante do curso de Análise e Projeto O.O com UML AF 4.1 Modelos Use Cases AF 2.1 (Requisitos) Especificação dos Requisitos do Sistema AF 2.2n Revisões dos Requisitos AF Case Diagramas AF Código Fonte F7.1 Projeto do Componentes Visuais V7.1 AF Case Diagramas F7.2 Projeto dos Componentes de Serviços / Negócios V7.2 AF Código Fonte F7.3 Projeto dos Componentes de Dados V7.3 AF AF Diagramas DDLs Case Versão: 3.0 Agosto/1999 Autor: Fábio Bianchi Campos AF 9.1 Produto Final Versão X.Y F9 F8 Integração Testes de e Carga Testes e Preliminares Otimizações V8 V9 Fim da Iteração n 7

8 Técnicas p/ Levantamento de Requisitos Uma das técnicas p/ levantamento de requisitos é a técnica FAST; Leia o Texto1.pdf (do livro Engenharia de software / Pressman) onde existem mais informações sobre esta técnica; Após ler o texto faça o exercício proposto 1. 8

9 Exercício Proposto 1 Qual a meta principal da técnica FAST? Quais são as 4 listas que os participantes de um encontro FAST são solicitados a elaborar? 9

10 Principais atividades do Levantamento de Requisitos Identificação e descrição do problema que o sistema pretende resolver; Descrição dos interessados no sistema e suas necessidades principais; Descrição das características do sistema para atendimento das necessidades dos interessados; Descrição dos requisitos funcionais do software; Descrição dos requisitos suplementares. 10

11 Exemplo: Biblioteca estudantil Para melhor entendimento dos conceitos, utilizaremos um exemplo de um sistema real ao longo de todo o curso; Este sistema deverá informatizar algumas operações de uma biblioteca; Este caso servirá de referência para exercícios e trabalhos ao longo do curso, portanto é importante a máxima atenção na compreensão do mesmo; Serão mostradas a seguir algumas partes importantes da especificação, a título de exemplo. 11

12 Descrição resumida do Problema O cadastramento de obras e o controle de empréstimos são as atividades principais de uma biblioteca. A medida que o volume de obras em uma biblioteca aumenta e o número de usuários também, as atividades de controle deste acervo vão se tornando intensas, dificultando a administração da biblioteca. Os usuários também enfrentam problemas, pois têm dificuldade em localizar as obras desejadas, tendo que muitas vezes se deslocar até a biblioteca e descobrir que o título desejado não existe no cadastro, ou as obras deste título estão emprestadas para outro usuário. O tempo elevado para a execução dos procedimentos operacionais da biblioteca tem dificultado bastante a sua administração, requerendo um grande número de funcionários. Os tempos de atendimento dos usuários da biblioteca têm ficado cada vez maiores, o que tem causado insistentes protestos dos alunos e professores que utilizam a biblioteca. 12

13 Identificação dos interessados Os operadores são os funcionários da biblioteca responsáveis pelas funções rotineiras como empréstimo de obras, cobrança de multas, cadastramento de usuários, cadastramento de obras, reservas e outros. Os usuários cadastrados podem reservar e retirar obras da biblioteca na forma de empréstimo. São aqueles que têm os seus dados cadastrados na biblioteca, como nome, endereço etc. Os administradores são os funcionários que gerenciam a biblioteca e terão acesso a dados globais como: quantitativos de livros emprestados, índices de atraso na devolução, índice de perdas de livros, livros mais solicitados, áreas mais solicitadas etc. São também os administradores que definem os parâmetros configuráveis do sistema, como limite de tempo para empréstimo, número de obras para empréstimo e etc. 13

14 Necessidades dos interessados Os operadores têm as seguintes necessidades básicas: Atender rapidamente os usuários cadastrados que desejam tomar obras emprestadas. Fazer um controle rápido e eficiente das multas a pagar pelos usuários devedores. Controlar as reservas de títulos feitas pelos usuários de maneira eficiente. Cadastrar novos usuários da biblioteca de maneira mais flexível, facilitando a alteração de dados do usuário. Cadastrar novos títulos e obras de maneira eficiente. 14

15 Características do sistema As principais características do sistema são: Manter atualizado o cadastro de títulos da biblioteca. Manter atualizado o cadastro das obras disponíveis destes títulos e o seu status. Manter atualizado o cadastro de usuários da biblioteca. Permitir pesquisas remotas via internet usando computadores pessoais dos usuários. Pesquisas locais (na biblioteca) a partir de computadores da biblioteca. Controlar o empréstimo de obras. Permitir reservas via internet ou locais para os usuários cadastrados. Manter o controle das multas dos usuários. Gerar estatísticas de uso da biblioteca. 15

16 Requisitos de software Reservar Título: O usuário cadastrado quando verificar que não há disponibilidade de obra do título desejado poderá fazer uma reserva para o mesmo. Esta reserva poderá ser feita tanto em terminais locais da biblioteca como via internet, pelo próprio usuário, ou poderá ser feita pelo operador, por solicitação do usuário. A reserva de títulos exige que o usuário ou o operador esteja previamente logados no sistema. Deve-se informar ao sistema o código do usuário que deseja fazer a reserva e posteriormente o código do título desejado, caso não haja nenhuma restrição ao usuário ou ao título, o mesmo será reservado. 16

17 Texto complementar 2 Leia o texto do arquivo Texto2.pdf (do livro managing software requirements - Dean Leffingwell) e responda as questões a seguir, sobre Requisitos de software. 17

18 Exercício proposto 2 De acordo com o autor, quais são as cinco categorias de requisitos que tornam os requisitos de software satisfatórios? Qual a importância para os desenvolvedores em transformar as características do sistema em Requisitos de Software? 18

19 Especificação completa Uma versão completa da especificação de requisitos da biblioteca se encontra no arquivo espreq50_01.pdf, que pertence à lição número 3; Faça uma leitura rápida deste documento para ter um noção do conteúdo de uma especificação; Este documento é o artefato produzido na fase levantamento de requisitos; Este documento será utilizado muitas outras vezes ao longo do curso, portanto é importante ter o mesmo sempre disponível nas aulas. 19

20 Exercício proposto 3 Qual item da especificação de requisitos (espereq50_01) você considera mais importante? Explique sua escolha. 20

21 Observações finais sobre requisitos O requisitos devem ser definidos de maneira conservadora, isto é, deve-se centrar nas reais necessidades, e não em coisas que seriam interessantes, mas que não são realmente necessárias; A Especificação de requisitos pode sofrer várias modificações no decorrer do sistema, estas modificações devem ser documentadas e controladas; A especificação de requisitos é puramente textual, portanto independente da UML. 21

22 Detalhamento dos requisitos Após o levantamento dos requisitos e elaboração da especificação, os requisitos de software devem ser detalhados para facilitar a análise e projeto; O detalhamento destes requisitos será feito na fase modelagem de requisitos; A técnica utilizada para a modelagem de requisitos será a dos Use Cases. 22

23 Modelagem de requisitos O que é: Detalhamento dos requisitos funcionais definidos na especificação de requisitos; A criação de modelos gráficos representativos do que se deseja do sistema de informação a ser implementado Objetivos: Permitir uma estruturação preliminar do sistema de informação que se quer desenvolver, do ponto de vista de quem utilizará o sistema; Quem participa: Contratantes do sistema, futuros usuários do sistema e analistas de requisitos; Característica:Abstração quanto a detalhes internos do sistema de informação, dando mais importância ao ponto de vista externo do sistema. Técnica utilizada: Use Cases 23

24 Localização no MasterModel Artefatos: Fase:modelagem de requisitos Início da Iteração n MasterModel (Simplificado) AF 1.1 AF 3.2 Diagrama de Classes Descrição do Negócio (Negócio) AF 3.4 Diagrama de Estados F1 F3 AF 3.3 Diagramas de Sequência (Negócio) Descrição Modelagem do do Negócio Negócio V1 V3 AF 6.1 Diagramas de Processadores e Processos AF 5.1 Diagramas de Sequência (Análise) F5 F6 AF 3.1 Modelos Use Cases (Negócio) Projeto da Análise Arquitetura de V5 Implementação V6 AF 4.2 Modelos de Interface AF 5.2 (Protótipo Visual) Diagrama de Classes (Análise) AF 4.3 Planilha Requisitos F2 F4 AF 6.2 Diagrama dos Subsistemas Levantamento Modelagem AF 6.3 de de Relatório de Projeto Requisitos Requisitos V2 V4 Este documento é parte integrante do curso de Análise e Projeto O.O com UML AF 4.1 Modelos Use Cases AF 2.1 (Requisitos) Especificação dos Requisitos do Sistema AF 2.2n Revisões dos Requisitos AF Case Diagramas AF Código Fonte F7.1 Projeto do Componentes Visuais V7.1 AF Case Diagramas F7.2 Projeto dos Componentes de Serviços / Negócios V7.2 AF Código Fonte F7.3 Projeto dos Componentes de Dados V7.3 AF AF Diagramas DDLs Case Versão: 3.0 Agosto/1999 Autor: Fábio Bianchi Campos AF 9.1 Produto Final Versão X.Y F9 F8 Integração Testes de e Carga Testes e Preliminares Otimizações V8 V9 Fim da Iteração n 24

25 Modelagem de Requisitos A modelagem de requisitos é a representação em forma gráfica (Use Case Model), textual(descrições) e visual(interfaces) dos requisitos do sistema que se deseja implementar; O foco é a modelagem dos requisitos funcionais do sistema. 25

26 Motivações para modelagem de requisitos Gerar um conjunto de diagramas e interfaces que facilitem a definição dos requisitos; A partir dos diagramas facilitar a comunicação entre analistas e contratante, tornando a captura de requisitos mais eficiente; Servir como base para a implementação de sistemas de informação, que irão realizar os requisitos modelados. 26

27 Modelo de Requisitos Capturar os requisitos a partir de uma perspectiva do usuário; Como um potencial usuário irá utilizar o sistema; Participação ativa dos usuários no acompanhamento do desenvolvimento do modelo; Onde toda a funcionalidade do sistema é especificada. 27

28 Exercício proposto 4 Pesquise no MasterModel (entregue na lição 2) e responda as questões a seguir: Qual artefato deve ser produzido antes da modelagem de requisitos? Que artefatos são produzidos na Modelagem de requisitos? 28

29 Atividades da Modelagem de Requisitos Definição dos candidatos a Use Cases e Atores; Elaborar diagrama preliminar com Use Cases e Atores; Descrição resumida dos atores, e descrição dos Use Cases Refinar o diagrama de Use Cases inicialmente elaborado; Elaborar protótipos visuais equivalentes aos Use Cases; Verificação geral dos diagramas. 29

30 Conceitos fundamentais da Modelagem de Requisitos Use Cases; Atores. 30

31 Definição de Atores Aquilo que existe fora do sistema; Os atores representam aquilo que interage com o sistema; Tudo que troca informações com o sistema; O Atores são usuários desempenhando papéis específicos; Um usuário pode desempenhar vários papéis; Atores interagem com os use cases. 31

32 Exercício proposto 5 Que diferentes papéis um mesmo funcionário de uma lanchonete tipo Mac Donalds poderia desempenhar em um dia de trabalho? Que diferentes papéis os funcionários da biblioteca poderiam desempenhar? 32

33 Definição de Use Cases Quando um usuário utiliza o sistema, o mesmo irá conduzir uma sequência de transações (na forma de diálogos) com o sistema; A cada conjunto de transações com um objetivo específico chama-se de um use case ; Cada use case representa uma maneira específica de se utilizar o sistema; Quando um usuário (no papel de um ator) gerar um estímulo inicial para o use case o mesmo irá iniciar a sequência de transações. 33

34 Exemplos de Use Cases (Banco) Terminal bancário: Checar saldo; fazer saque; Tirar extrato; Depositar cheques;... 34

35 Use Case segundo a UML Um use case é uma unidade coerente de funcionalidade, provida por um sistema, manifestada por uma sequência de mensagens trocadas entre o sistema e um ou mais elementos de interação externo (atores), com ações executadas pelo sistema; Um use case é a descrição de uma sequência de ações, incluindo as variações, que um sistema executa para atingir um resultado observável por um ator. 35

36 Definição original da UML A use case is a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor has one role for each use case it communicates with. 36

37 Atores segundo a UML Um ator é um objeto (ou objetos) fora do sistema desempenhando papéis, que interagem diretamente com o sistema como parte de uma unidade coerente que é o use case ; Um objeto pode desempenhar vários papéis sendo então modelado por diversos atores; Pode ser representado por um retângulo com <<actor>> e o nome do ator dentro do retângulo, Também podem ser representados pelo homenzinho (stick man). 37

38 Diagrama de Use Cases e Atores fronteira do sistema use case 2 ator 1 use case 1 use case 3 ator 2 38

39 Identificação preliminar de atores (1) Exemplo da biblioteca Os objetos externos que interagem com o sistema (biblioteca): Qualquer pessoa; Usuários cadastrados; Operadores; Administradores; Suporte. 39

40 Identificação preliminar de Use Cases (1) Exemplo da biblioteca Identificar as funcionalidades acessíveis a cada grupo de objetos externos: Qualquer pessoa: Pesquisar a existência de títulos; Usuários cadastrados: Pesquisar e Reservar obras; Operadores: Reservar e Emprestar obras; Cadastrar usuários; Receber obra, Receber multa... Administradores: Cadastrar funcionários e acesso a relatórios administrativos e acesso total. 40

41 Candidatos a atores, papéis (2) Atendente (Faz empréstimo, reserva, recebe retorno, - só pode ser funcionário-operador); Cadastrador (Faz cadastro de usuários, títulos e obras - só pode ser funcionário-operador ) ;... 41

42 Atores secundários Participam de use cases que não são fundamentais do ponto de vista dos usuários do sistema; Exemplo: Papéis executados pelos objetos como o administrador e pessoal de suporte, irão executar atividades internas como mudar valor da multa diária, alterar cotas de empréstimo, etc...; 42

43 Candidatos a Use Cases (2) Conjuntos de transações com um objetivo específico: Pesquisar a existência de uma obra; Reservar título; Emprestar Obra; Devolver obra; Pagar multa; Cadastrar calouro;... 43

44 Diagrama preliminar dos Use Cases Cadastrador Cadastrar Obra Cadastrar Usuário Emprestar de Obra atendente Devolver Obra UMLib 44

45 Descrição detalhada do Use Case Nome: Atores que interagem: Ator que inicia: Pré-condições: Dados consumidos e produzidos: Resumo do curso principal: Sub-fluxos: Alternativas: Requisitos especiais: 45

46 Resumo curso principal use case Emprestar obra (curso principal): Um usuário cadastrado após ter escolhido a obra que deseja levar como empréstimo, e estando de posse da mesma, solicitará ao funcionário (atendente) que efetive o empréstimo desta. O atendente solicita ao usuário o seu código no sistema, e preenche (em um formulário na tela do seu computador de atendimento) o campo respectivo com o código do mesmo. Depois solicitará ao usuário que digite a sua senha no keypad.posteriormente verifica na obra selecionada pelo usuário o número de tombo da mesmas entrando este número no campo apropriado. Finalmente pressiona o botão para efetivar o empréstimo. Caso o usuário esteja habilitado ao empréstimo das obras solicitadas, o sistema dará uma mensagem de sucesso. O atendente então carimbará as obras liberando as mesmas para o usuário. 46

47 Exercício proposto 6 Com base na especificação de requisitos fornecida (espereq50_01.pdf) e no exemplo (UseCaseEmpObra.pdf) tente fazer um detalhamento semelhante para o Use Case Reservar título. 47

48 Associações entre Use Cases Comunicação - relação entre um ator e um use case ; Extends - quando a funcionalidade embutida em um use case é uma opção de extensão da funcionalidade de um outro use case ; Include - indica que a funcionalidade de um use case está incluída no outro, no curso principal. 48

49 Trabalho de pesquisa p/ casa Pesquise na norma UML e no livro texto do curso, as relações Extend e Include entre Use Cases. Faça um resumo do significado de cada uma, cite em que casos devem ser usadas e dê exemplos. Este trabalho deve ser feito até o dia 30/8 e enviado por para bianchi@ucb.br colocando na linha de assunto APSIIturmaTP1_matricula. Exemplo de linha de assunto APSIINKATP1_ Colocar no corpo do trabalho o nome, matrícula e turma. 49

50 Protótipo das Interfaces Servem como complemento aos use cases ; Pode ser utilizada a técnica de prototipação, para se mostrar ao usuário uma sequência de telas ao se executar um use case. 50

51 Formulário Principal Emprestar Obra 51

52 revisão das atividades Definição dos canditados a Use Cases e Atores; Elaborar diagrama preliminar com Use Cases e Atores; Descrição resumida dos atores, e descrição dos Use Cases Refinar o diagrama de Use Cases inicialmente elaborado; Elaborar protótipos visuais equivalentes aos Use Cases; Verificação geral dos diagramas. 52

53 Verificações e inspeções Verificar coerência entre os modelos gerados e especificação de requisitos; Verificar coerência entre os use cases e as interfaces. 53

54 Iterações Na primeira iteração devem ser identificados e modelados os use cases mais significativos dos requisitos, Ex: EmprestarObra, ReservarTitulo, DevolverObra, CadastrarTitulo, CadastrarObra e CadastrarUsuario,... Deve-se também tentar nas primeiras iterações identificar os use cases que tenham maior interação com os atores, que envolvam maiores riscos e que venham a ter maiores impactos na arquitetura. 54

55 Exercício proposto 7 No exemplo da biblioteca, qual Use Case você acha que teria um maior impacto na arquitetura da solução? Explique sua escolha. 55

56 Prática de laboratório Após estudar no tutorial da ferramenta Rose como criar um Use Case, um ator e um diagrama de use cases, criar (utilizando a versão 4.0 da ferramenta do laboratório) um diagrama de use cases da biblioteca (como o da transparência 44) com pelo menos 8 Use Cases da biblioteca. Descrever o resumo do fluxo principal de pelo menos 3 Use Cases. Obs: nesta fase não deve ser utilizada versão mais recente da ferramenta. 56

57 Observações Finais Os use cases conduzem todo o desenvolvimento, o que permite uma coerência entre os modelos gerados nas diversas fases, pois todos estarão centrados em refinar os use cases. Outras metodologias (ou processos) não têm esta abordagem, tentam identificar todos os objetos, suas relações e posteriormente fazer algum tipo de modularização. 57

58 Referências Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addison-Wesley Longman, Inc, Kruchten, Philippe. The Rational Unified Process - An Introduction. Addisson Wesley Longman Inc, Unified Modeling Language - Notation Guide - V. 1.3 R9 January OMG. 58