Requisitos de Software e UML Básico. Janaína Horácio

Transcrição

1 Requisitos de Software e UML Básico Janaína Horácio janaina@les.inf.puc-rio.br

2 Agenda Requisitos O que é? Objetivos? Atividades?... UML O que é? Modelos... Casos de Uso O que é? Componentes 2

3 Requisitos Descrição das necessidades ou dos desejos de um produto. É a parte mais crítica e propensa a erros no desenvolvimento de software Objetivo Identificar os requisitos que serão satisfeitos Documentar Facilitar a comunicação 3

4 Requisitos O processo de Engenharia de Requisitos é composto por quatro atividades de alto nível (Soares, 2005): Identificação. Análise e negociação. Especificação e documentação. Validação. 4

5 Requisitos Os seguintes artefatos são recomendados na fase de requisitos: Um texto de visão geral Clientes Objetivos Funções do sistema Atributos do sistema 5

6 Requisitos Onde Coletar os Requisitos? Fontes Humanas Ambiente onde o Sistema Funcionará Estudos de Viabilidade (técnica, financeira) Análises de Mercado Planos de Negócios Análise de Produtos Competidores Conhecimento do Domínio 6

7 Requisitos Requisito Funcional A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. Requisito Não-Funcional Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa e são difíceis de validar. 7

8 Requisitos Uma boa especificação de requisitos deve ser: Clara e não-ambígua Completa Correta Compreensível Consistente Concisa Confiável 8

9 Requisitos Construir um sistema de software com base em requisitos inconsistentes e mal definidos é como construir uma casa sem alicerce na areia... 9

10 UML Básico

11 UML A UML (Unified Modeling Language) é uma linguagem para especificação, documentação, visualização e desenvolvimento de sistemas orientados a objetos. A UML é controlada pelo Grupo de Gerenciamento de Objeto (Object Management Group - OMG) e é adotada por boa parte da indústria para descrever graficamente software. 11

12 UML Uma linguagem de modelagem é uma linguagem cujo vocabulário e regras têm seu foco voltado para a representação conceitual e física de um sistema. O vocabulário e as regras indicam como criar e ler modelos bem formados, mas não apontam quais modelos devem ser criados e nem em que seqüência. 12

13 UML A UML fornece os símbolos gráficos para a representação de artefatos de software. Por trás de cada símbolo empregado, existe uma sintaxe e uma semântica bem-definidas. Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo e qualquer outro será capaz de interpretá-lo sem ambigüidades. 13

14 UML Além dos modelos que descrevem o projeto, outros documentos, que fornecem informações importante sobre o sistema, também podem ser expressos com UML: os requisitos do sistema, a arquitetura do sistema e todos os seus detalhes, as atividades de planejamento do projeto, as atividades de realização de testes, o gerenciamento de versões. 14

15 UML Figura 1. Relações entre os diagramas da UML 15

16 Vantagens da UML Padrão aberto e não proprietário. Integração das melhores práticas de modelagem. Independência do processo de desenvolvimento. Aplicável a todas as fases do ciclo de desenvolvimento. Independência de linguagem de implementação. Suporte a conceitos de alto nível. É uma linguagem extensível. 16

17 Diagrama de Caso de Uso

18 Casos de Uso Segundo Ivan Jacobson, podemos dizer que um caso de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo". É uma técnica de modelagem usada para descrever o que um novo sistema deve fazer e não como deve ser feito. 18

19 Casos de Uso Os componentes de um modelo de casos de uso são : Ator - é um papel que tipicamente estimula/solicita ações/eventos do sistema e recebe reações. Cada ator pode participar de vários casos de uso Casos de uso - documento narrativo que descreve a seqüência de eventos feitos por um ator no uso do sistema. Sistema - O sistema a ser modelado 19

20 Como Identificar Casos de Uso Para cada ator identificado, quais são as tarefas nas quais o sistema estaria envolvido? O ator precisa estar informado sobre certas ocorrências no sistema? O ator precisa informar o sistema sobre mudanças externas repentinas? O sistema fornece ao negócio o comportamento correto? Todos as características podem ser realizadas pelos casos de uso identificados? Que casos de uso suportarão e manterão o sistema? Que informações devem ser modificadas ou criadas no sistema? 20

21 Casos de Uso Omitidos Início e fim do sistema. Manutenção do sistema. Por exemplo, adicionar novos usuários e configurar os perfis de usuário. Manutenção dos dados armazenados no sistema. Por exemplo, o sistema é criado para trabalhar junto com um sistema legado, e os dados precisam ser sincronizados entre os dois. Funcionalidade necessária para modificar o comportamento no sistema. Um exemplo seria a funcionalidade para criar novos relatórios. 21

22 Boas Práticas de Casos de Uso Nomeie um caso de uso começando com um verbo, para enfatizar que ele é um processo. Ex: Cadastrar Cliente, Comprar Item, etc. Para identificar claramente um ator iniciador e um evento, comece a descrição da seqüência de um caso de uso usando o seguinte esquema: <Ator> <Evento que inicia o caso de uso> 22

23 Relacionamentos de Casos de Uso Os relacionamentos possíveis são : Inclusão : Se um caso de uso inicia ou inclui o comportamento de outro, dizemos que ele usa o outro. O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>. 23

24 Relacionamentos de Casos de Uso Extensão - Define pontos de extensão que adicionam comportamento a um caso de uso base descrevendo uma variação do comportamento normal. O caso de uso base pode ser executado mesmo sem a extensão. <<extend>> 24

25 Relacionamentos de Casos de Uso Generalização especifica que um Caso de Uso herda as características do Super Caso de Uso, e pode sobrepor algumas delas ou adicionar novas 25

26 Especificação de Caso de Uso Caso de Uso 01 Cadastrando cliente (descrição típica) Ator Primário: Cliente Precondições: Nenhuma Fluxo Normal 1 Cliente preenche ficha cadastral. 2 Assistente de Cadastro informa recebimento de documentação cadastral. 3 Gerente de Cadastro informa aprovação do Cliente. Fluxo Alternativo: documentação incompleta ou com erro 2a Assistente de Cadastro informa documentação irregular. 2b Cliente envia documentação corrigida para cadastro. 2c Retorna ao passo 2. Fluxo Alternativo: irregularidade nos dados cadastrais 3a Gerente de Cadastro informa irregularidade nos dados cadastrais. 3b Cliente atualiza dados cadastrais. 3c Retorna ao passo 3. 26

27 Diagramas UML: Sistema de Matrícula (SM) Uma universidade requisita um sistema de matrículas: 1. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 27

28 SM: Identificando os atores Uma universidade requisita um sistema de matrículas: 1. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 28

29 SM: Identificando os atores Uma universidade requisita um sistema de matrículas: 1. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 29

30 SM: Identificando os casos de uso Uma universidade requisita um sistema de matrículas: 1. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 30

31 SM: Obtendo o Diagrama de Casos de Uso 31

32 SM: Obtendo o Diagrama de Casos de Uso 32

33 SM: Especificando os casos de uso 33

34 34

35 35