Requisitos e UML Prof Msc Wollace Picanço. / Agenda Requisitos –O que é ? –Objetivos? –Atividades? –... UML –O que é ? –Modelos –... Casos de Uso –O que.

Apresentação em tema: "Requisitos e UML Prof Msc Wollace Picanço. / Agenda Requisitos –O que é ? –Objetivos? –Atividades? –... UML –O que é ? –Modelos –... Casos de Uso –O que."— Transcrição da apresentação:

1 Requisitos e UML Prof Msc Wollace Picanço

2 / Agenda Requisitos –O que é ? –Objetivos? –Atividades? –... UML –O que é ? –Modelos –... Casos de Uso –O que é ? –Componentes –… 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 8

9 Requisitos Construir um sistema de software com base em requisitos inconsistentes e mal definidos é como construir uma casa sem alicerce na areia... 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 14

15 UML Figura 1. Relações entre os diagramas da UML 17/01/2008Janaína Horácio © LES/PUC-Rio15

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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 fazere não como deve ser feito. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 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? 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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: – 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 >. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. > 17/01/2008 Janaína Horácio © LES/PUC-Rio 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 17/01/2008 Janaína Horácio © LES/PUC-Rio 25

26 Especificação de Caso de Uso 17/01/2008 Janaína Horácio © LES/PUC-Rio 26 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.

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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 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. 17/01/2008 Janaína Horácio © LES/PUC-Rio 30

31 SM: Obtendo o Diagrama de Casos de Uso 17/01/2008 Janaína Horácio © LES/PUC-Rio 31

32 SM: Obtendo o Diagrama de Casos de Uso 17/01/2008 Janaína Horácio © LES/PUC-Rio 32

33 SM: Especificando os casos de uso 17/01/2008 Janaína Horácio © LES/PUC-Rio 33

34 17/01/2008 Janaína Horácio © LES/PUC-Rio 34

35 https://jude.change-vision.com/jude- web/serviceDownloadLink.do 17/01/2008 Janaína Horácio © LES/PUC-Rio 35