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

(1)

Curso de Análise e Projeto O.O. / Prof . Fábio Bianchi

Lição 3

Especificação e Modelagem de

Requisitos com UML

Análise e Projeto OO com UML

(2)

Curso de Análise e Projeto O.O. /

Prof

. Fábio

Bianchi

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.

(3)

Prof

. Fábio

Bianchi

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;

(4)

Prof

. Fábio

Bianchi

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;

(5)

Prof

. Fábio

Bianchi

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.

(6)

Prof

. Fábio

Bianchi

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,

(7)

Localização no MasterModel

MasterModel (Simplificado) Descrição do Negócio F1 Levantamento de Requisitos Modelagem do Negócio Modelagem de Requisitos F3 F2 F4 Análise Projeto da Arquitetura de Implementação Projeto do Componentes Visuais

Projeto dos Componentes de Serviços / Negócios

Projeto dos Componentes de Dados Integração e Testes Preliminares F5 F6 F7.1 F7.2 F7.3 F8 Case Case Case Descrição do Negócio Diagrama de Classes

(Negócio) Diagrama de Estados Diagramas de Sequência (Negócio) AF 1.1 AF 3.2 AF 3.4 AF 3.3

Modelos Use Cases (Negócio)

AF 3.1

Modelos de Interface (Protótipo Visual)

AF 4.2

Modelos Use Cases (Requisitos) AF 2.1 AF 4.1 Diagramas de Sequência (Análise) AF 5.1 Diagrama de Classes (Análise) AF 5.2

Diagrama dos Subsistemas AF 6.2 Relatório de Projeto AF 6.3 Diagramas de Processadores e Processos AF 6.1 Diagramas AF 7.1.2 Código Fonte AF 7.1.1 Diagramas AF 7.2.2 Código Fonte AF 7.2.1 Diagramas DDLs AF 7.3.2 AF 7.3.1 Fim da Iteração n Início da Iteração n

Este documento é parte integrante do curso de Análise e Projeto O.O

com UML

Versão: 3.0 Agosto/1999 Autor: Fábio Bianchi Campos

Testes de Carga e Otimizações V2 V4 V1 V3 V5 V6 F9 V7.1 V7.2 V7.3 V8 V9 Planilha Requisitos AF 4.3 Produto Final Versão X.Y AF 9.1 Fase: levantamento de requisitos Artefato: especificação

(8)

Prof

. Fábio

Bianchi

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;

(9)

Prof

. Fábio

Bianchi

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?

(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.

(11)

Prof

. Fábio

Bianchi

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.

(12)

Prof

. Fábio

Bianchi

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.

(13)

Prof

. Fábio

Bianchi

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

(14)

Prof

. Fábio

Bianchi

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.

(15)

Prof

. Fábio

Bianchi

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.

(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.

(17)

Prof

. Fábio

Bianchi

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.

(18)

Prof

. Fábio

Bianchi

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”?

(19)

Prof

. Fábio

Bianchi

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;

(20)

Prof

. Fábio

Bianchi

Exercício proposto 3

• Qual item da especificação de requisitos

(espereq50_01) você considera mais importante? • Explique sua escolha.

(21)

Prof

. Fábio

Bianchi

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;

(22)

Prof

. Fábio

Bianchi

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”.

(23)

Prof

. Fábio

Bianchi

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

(24)

Localização no MasterModel

MasterModel (Simplificado) Descrição do Negócio F1 Levantamento de Requisitos Modelagem do Negócio Modelagem de Requisitos F3 F2 F4 Análise Projeto da Arquitetura de Implementação Projeto do Componentes Visuais

Projeto dos Componentes de Serviços / Negócios

Projeto dos Componentes de Dados Integração e Testes Preliminares F5 F6 F7.1 F7.2 F7.3 F8 Case Case Case Descrição do Negócio Diagrama de Classes

(Negócio) Diagrama de Estados Diagramas de Sequência (Negócio) AF 1.1 AF 3.2 AF 3.4 AF 3.3

Modelos Use Cases (Negócio)

AF 3.1

Modelos de Interface (Protótipo Visual)

AF 4.2

Especificação dos Requisitos do Sistema

Modelos Use Cases (Requisitos) AF 2.1 AF 2.2n AF 4.1 Diagramas de Sequência (Análise) AF 5.1 Diagrama de Classes (Análise) AF 5.2

Diagrama dos Subsistemas AF 6.2 Relatório de Projeto AF 6.3 Diagramas de Processadores e Processos AF 6.1 Diagramas AF 7.1.2 Código Fonte AF 7.1.1 Diagramas AF 7.2.2 Código Fonte AF 7.2.1 Diagramas DDLs AF 7.3.2 AF 7.3.1 Fim da Iteração n Início da Iteração n

Este documento é parte integrante do curso de Análise e Projeto O.O

com UML

Versão: 3.0 Agosto/1999 Autor: Fábio Bianchi Campos

Testes de Carga e Otimizações V2 V4 V1 V3 V5 V6 F9 V7.1 V7.2 V7.3 V8 V9 Planilha Requisitos AF 4.3 Produto Final Versão X.Y AF 9.1 Fase:modelagem de Artefatos:

(25)

Prof

. Fábio

Bianchi

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.

(26)

Prof

. Fábio

Bianchi

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

(27)

Prof

. Fábio

Bianchi

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.

(28)

Prof

. Fábio

Bianchi

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?

(29)

Prof

. Fábio

Bianchi

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.

(30)

Conceitos fundamentais

da Modelagem de Requisitos

• Use Cases;

• Atores.

(31)

Prof

. Fábio

Bianchi

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;

(32)

Prof

. Fábio

Bianchi

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?

(33)

Prof

. Fábio

Bianchi

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

(34)

Prof

. Fábio

Bianchi

Exemplos de Use Cases (Banco)

• Terminal bancário: – Checar saldo; – fazer saque; – Tirar extrato; – Depositar cheques; – ...

(35)

Prof

. Fábio

Bianchi

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.

(36)

Prof

. Fábio

Bianchi

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.

(37)

Prof

. Fábio

Bianchi

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,

(38)

Prof

. Fábio

Bianchi

Diagrama de Use Cases e Atores

use case 1

use case 3 use case 2

ator 1 ator 2

(39)

Prof

. Fábio

Bianchi

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.

(40)

Prof

. Fábio

Bianchi

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:

(41)

Prof

. Fábio

Bianchi

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 ) ;

(42)

Prof

. Fábio

Bianchi

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...;

(43)

Prof

. Fábio

Bianchi

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; – ...

(44)

Curso de Análise e Projeto O.O. / Prof . Fábio Bianchi Cadastrador Cadastrar Obra Cadastrar Usuário Emprestar de Obra

(45)

Prof

. Fábio

Bianchi

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:

(46)

Prof

. Fábio

Bianchi

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.

(47)

Prof

. Fábio

Bianchi

Exercício proposto 6

• Com base na especificação de requisitos fornecida (espereq50_01.pdf) e no exemplo

(UseCaseEmpObra.pdf) tente fazer um detalhamento

(48)

Prof

. Fábio

Bianchi

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.

(49)

Prof

. Fábio

Bianchi

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 e-mail para [email protected] colocando na linha de assunto APSIIturmaTP1_matricula. Exemplo de linha de assunto APSIINKATP1_98123456. Colocar

(50)

Prof

. Fábio

Bianchi

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

(51)

Prof

. Fábio

Bianchi

(52)

Prof

. Fábio

Bianchi

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.

(53)

Prof

. Fábio

Bianchi

Verificações e inspeções

• Verificar coerência entre os modelos gerados e especificação de requisitos;

(54)

Prof

. Fábio

Bianchi

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.

(55)

Prof

. Fábio

Bianchi

Exercício proposto 7

• No exemplo da biblioteca, qual Use Case você acha que teria um maior impacto na arquitetura da

(56)

Prof

. Fábio

Bianchi

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.

(57)

Prof

. Fábio

Bianchi

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

(58)

Prof

. Fábio

Bianchi

Referências

• Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The

Unified Software Development Process. Addison-Wesley

Longman, Inc, 1999.

• Kruchten, Philippe. The Rational Unified Process - An

Introduction. Addisson Wesley Longman Inc, 1999.

• Unified Modeling Language - Notation Guide - V. 1.3 R9 January 1999. OMG.