análise e projeto oo com uml lição 3 especificação e ... reference... especificação e...

Especificação e Modelagem de Requisitos com UML1

Curso de A

nálise e Projeto O.O

. / Prof. Fábio Bianchi

Lição 3Especificação e Modelagem de

Requisitos com UML

Análise e Projeto OO com UML

Prof. Fábio Bianchi Campos


Curso de A



Objetivos Gerais

• Apresentar as características básicas de umaespecificação de requisitos;

• Apresentar os conceitos básicos da modelagem derequisitos, segundo a ótica dos “Use Cases”.;

• Apresentar o que são “Use Cases” e atores derequisitos;

• Apresentar os diagramas da UML que podem serutilizados na modelagem de requisitos.


Curso de A



Roteiro

• O Levantamento de Requisitos e a Modelagem de Requisitosno 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.


Curso de A



Motivação

• Quando vamos desenvolver um sistema, precisamosinicialmente definir “o que” o sistema irá fazer antesde efetivamente iniciarmos o desenvolvimento;

• Precisamos entender os reais “problemas” que osistema irá resolver;

• Precisamos saber claramente quem são as pessoasafetadas, direta e indiretamente pelo sistema;

• Para esclarecer os pontos acima que é criada umaespecificação de requisitos.


Curso de A



Requisitos

• São características desejadas, propriedades, oucomportamentos de um sistema;

• É uma condição ou capacitação que um sistemaou componente do sistema precisa atender outer para satisfazer um contrato, especificação ououtro documento formalmente estabelecido.


Curso de A



Levantamento de Requisitos

• O que é: é a definição das características epropriedades desejadas para o sistema que seráelaborado;

• Objetivos: Definir claramente o que se deseja dosistema a ser implementado;

• Quem participa: Contratantes do sistema, futurosusuá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.


Curso de A



Localização no MasterModel

MasterModel (Simplificado)

Descrição do

Negócio

F1

Levantamentode

Requisitos

Modelagemdo

Negócio

Modelagemde

Requisitos

F3

F2 F4

Análise

Projetoda

Arquiteturade

Implementação

Projeto do ComponentesVisuais

Projeto dos Componentesde Serviços / Negócios

Projeto dos Componentesde Dados

Integraçãoe

TestesPreliminares

F5 F6

F7.1

F7.2

F7.3

F8

Case

Case

Case

Descrição do NegócioDiagrama 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 Requisitosdo Sistema

Revisões dos Requisitos

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 eProcessos

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

Fimda

Iteração n

Inícioda

Iteração n

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

com UML

Versão: 3.0Agosto/1999

Autor: Fábio Bianchi Campos

Testes deCarga

eOtimizações

V2 V4

V1 V3

V5 V6

F9

V7.1

V7.2

V7.3

V8

V9

PlanilhaRequisitos

AF 4.3

Produto FinalVersão X.Y

AF 9.1

Fase: levantamentode requisitos

Artefato: especificaçãode requisitos


Curso de A



Técnicas p/ Levantamento de Requisitos

• Uma das técnicas p/ levantamento de requisitos é atécnica FAST;

• Leia o Texto1.pdf (do livro Engenharia de software /Pressman) onde existem mais informações sobre estatécnica;

• Após ler o texto faça o exercício proposto 1.


Curso de A



Exercício Proposto 1

• Qual a meta principal da técnica FAST?

• Quais são as 4 listas que os participantes de umencontro FAST são solicitados a elaborar?


Curso de A



Principais atividades doLevantamento de Requisitos

• Identificação e descrição do “problema” que o sistemapretende resolver;

• Descrição dos interessados no sistema e suasnecessidades principais;

• Descrição das características do sistema paraatendimento das necessidades dos interessados;

• Descrição dos requisitos funcionais do software;

• Descrição dos requisitos suplementares.


Curso de A



Exemplo: Biblioteca estudantil

• Para melhor entendimento dos conceitos, utilizaremos umexemplo de um sistema “real” ao longo de todo o curso;

• Este sistema deverá informatizar algumas operações de umabiblioteca;

• Este “caso” servirá de referência para exercícios e trabalhosao longo do curso, portanto é importante a máxima atençãona compreensão do mesmo;

• Serão mostradas a seguir algumas partes importantes daespecificação, a título de exemplo.


Curso de A



Descrição resumida do Problema

• O cadastramento de obras e o controle de empréstimos são as atividadesprincipais de uma biblioteca. A medida que o volume de obras em umabiblioteca aumenta e o número de usuários também, as atividades decontrole deste acervo vão se tornando intensas, dificultando a administraçãoda biblioteca. Os usuários também enfrentam problemas, pois têmdificuldade em localizar as obras desejadas, tendo que muitas vezes sedeslocar até a biblioteca e descobrir que o título desejado não existe nocadastro, ou as obras deste título estão emprestadas para outro usuário. Otempo elevado para a execução dos procedimentos operacionais dabiblioteca tem dificultado bastante a sua administração, requerendo umgrande número de funcionários. Os tempos de atendimento dos usuários dabiblioteca têm ficado cada vez maiores, o que tem causado insistentesprotestos dos alunos e professores que utilizam a biblioteca.


Curso de A



Identificação dos interessados

• Os operadores são os funcionários da biblioteca responsáveis pelas funçõesrotineiras 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 deempréstimo. São aqueles que têm os seus dados cadastrados na biblioteca, comonome, endereço etc.

• Os administradores são os funcionários que gerenciam a biblioteca e terão acesso adados globais como: quantitativos de livros emprestados, índices de atraso nadevolução, índice de perdas de livros, livros mais solicitados, áreas mais solicitadasetc. São também os administradores que definem os parâmetros configuráveis dosistema, como limite de tempo para empréstimo, número de obras para empréstimo eetc.


Curso de A



Necessidades dos interessados

Os operadores têm as seguintes necessidades básicas:

• Atender rapidamente os usuários cadastrados que desejamtomar obras emprestadas.

• Fazer um controle rápido e eficiente das multas a pagarpelos usuários devedores.

• Controlar as reservas de títulos feitas pelos usuários demaneira eficiente.

• Cadastrar novos usuários da biblioteca de maneira maisflexível, facilitando a alteração de dados do usuário.

• Cadastrar novos títulos e obras de maneira eficiente.


Curso de A



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 dosusuá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.


Curso de A



Requisitos de software

Reservar Título:

• O usuário cadastrado quando verificar que não há disponibilidade deobra do título desejado poderá fazer uma reserva para o mesmo. Estareserva poderá ser feita tanto em terminais locais da biblioteca comovia 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 ouo operador esteja previamente “logados” no sistema. Deve-se informarao sistema o código do usuário que deseja fazer a reserva eposteriormente o código do título desejado, caso não haja nenhumarestrição ao usuário ou ao título, o mesmo será reservado.


Curso de A



Texto complementar 2

• Leia o texto do arquivo Texto2.pdf (do livromanaging software requirements - Dean Leffingwell)e responda as questões a seguir, sobre Requisitos desoftware.


Curso de A



Exercício proposto 2

• De acordo com o autor, quais são as cinco categoriasde requisitos que tornam os requisitos de softwaresatisfatórios?

• Qual a importância para os desenvolvedores emtransformar as “características do sistema” em“Requisitos de Software”?


Curso de A



Especificação completa

• Uma versão completa da especificação de requisitosda biblioteca se encontra no arquivoespreq50_01.pdf, que pertence à lição número 3;

• Faça uma leitura rápida deste documento para ter umnoção do conteúdo de uma especificação;

• Este documento é o artefato produzido na faselevantamento de requisitos;

• Este documento será utilizado muitas outras vezes aolongo do curso, portanto é importante ter o mesmosempre disponível nas aulas.


Curso de A




• Qual item da especificação de requisitos(espereq50_01) você considera mais importante?

• Explique sua escolha.


Curso de A



Observações finais sobre requisitos

• O requisitos devem ser definidos de maneiraconservadora, isto é, deve-se centrar nas reaisnecessidades, e não em coisas que seriaminteressantes, mas que não são realmente necessárias;

• A Especificação de requisitos pode sofrer váriasmodificações no decorrer do sistema, estasmodificações devem ser documentadas econtroladas;

• A especificação de requisitos é puramente textual,portanto independente da UML.


Curso de A



Detalhamento dos requisitos

• Após o levantamento dos requisitos e elaboração daespecificação, os requisitos de software devem serdetalhados para facilitar a análise e projeto;

• O detalhamento destes requisitos será feito na fasemodelagem de requisitos;

• A técnica utilizada para a modelagem de requisitosserá a dos “Use Cases”.


Curso de A



Modelagem de requisitos

• O que é: Detalhamento dos requisitos funcionais definidos naespecificação de requisitos; A criação de modelos gráficosrepresentativos do que se deseja do sistema de informação a serimplementado

• Objetivos: Permitir uma estruturação preliminar do sistema deinformação que se quer desenvolver, do ponto de vista de quemutilizará o sistema;

• Quem participa: Contratantes do sistema, futuros usuários do sistemae analistas de requisitos;

• Característica:Abstração quanto a detalhes internos do sistema deinformação, dando mais importância ao ponto de vista externo dosistema.

• Técnica utilizada: Use Cases


Curso de A



Localização no MasterModel

MasterModel (Simplificado)

Descrição do

Negócio

F1

Levantamentode

Requisitos

Modelagemdo

Negócio

Modelagemde

Requisitos

F3

F2 F4

Análise

Projetoda

Arquiteturade

Implementação

Projeto do ComponentesVisuais

Projeto dos Componentesde Serviços / Negócios

Projeto dos Componentesde Dados

Integraçãoe

TestesPreliminares

F5 F6

F7.1

F7.2

F7.3

F8

Case

Case

Case

Descrição do NegócioDiagrama 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 Requisitosdo Sistema

Revisões dos Requisitos

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 eProcessos

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

Fimda

Iteração n

Inícioda

Iteração n

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

com UML

Versão: 3.0Agosto/1999

Autor: Fábio Bianchi Campos

Testes deCarga

eOtimizações

V2 V4

V1 V3

V5 V6

F9

V7.1

V7.2

V7.3

V8

V9

PlanilhaRequisitos

AF 4.3

Produto FinalVersão X.Y

AF 9.1

Fase:modelagem derequisitos

Artefatos:


Curso de A



Modelagem de Requisitos

• A modelagem de requisitos é a representação emforma gráfica (Use Case Model), textual(Descrições)e visual(Interfaces) dos requisitos do sistema que sedeseja implementar;

• O foco é a modelagem dos requisitos funcionais dosistema.


Curso de A



Motivações para modelagem de requisitos

• Gerar um conjunto de diagramas e interfaces quefacilitem a definição dos requisitos;

• A partir dos diagramas facilitar a comunicação entreanalistas e contratante, tornando a captura derequisitos mais eficiente;

• Servir como base para a implementação de sistemasde informação, que irão realizar os requisitosmodelados.


Curso de A



Modelo de Requisitos

• Capturar os requisitos a partir de uma perspectiva dousuário;

• Como um potencial usuário irá utilizar o sistema;

• Participação ativa dos usuários no acompanhamentodo desenvolvimento do modelo;

• Onde toda a funcionalidade do sistema éespecificada.


Curso de A




• Pesquise no MasterModel (entregue na lição 2) eresponda as questões a seguir:

• Qual artefato deve ser produzido antes damodelagem de requisitos?

• Que artefatos são produzidos na Modelagem derequisitos?


Curso de A



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.


Curso de A



Conceitos fundamentaisda Modelagem de Requisitos

• Use Cases;

• Atores.


Curso de A



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


Curso de A




• Que diferentes papéis um mesmo funcionário de umalanchonete tipo Mac Donalds poderia desempenharem um dia de trabalho?

• Que diferentes papéis os funcionários da bibliotecapoderiam desempenhar?


Curso de A



Definição de Use Cases

• Quando um usuário utiliza o sistema, o mesmo irá conduziruma sequência de transações (na forma de diálogos) com osistema;

• A cada conjunto de transações com um objetivo específicochama-se de um “use case”;

• Cada “use case” representa uma maneira específica de seutilizar o sistema;

• Quando um usuário (no papel de um ator) gerar um estímuloinicial para o “use case” o mesmo irá iniciar a sequência detransações.


Curso de A



Exemplos de Use Cases (Banco)

• Terminal bancário:– Checar saldo;

– fazer saque;

– Tirar extrato;

– Depositar cheques;

– .....


Curso de A



Use Case segundo a UML

• Um “use case” é uma unidade coerente de funcionalidade,provida por um sistema, manifestada por uma sequência demensagens trocadas entre o sistema e um ou mais elementosde interação externo (atores), com ações executadas pelosistema;

• Um “use case” é a descrição de uma sequência de ações,incluindo as variações, que um sistema executa para atingirum resultado observável por um ator.


Curso de A



Definição original da UML

A use case is a coherent unit of functionality provided by a system, asubsystem, or a class as manifested by sequences of messagesexchanged 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 playwhen interacting with the entity. An actor has one role for each usecase it communicates with.


Curso de A



Atores segundo a UML

• Um ator é um objeto (ou objetos) fora do sistemadesempenhando papéis, que interagem diretamente com osistema como parte de uma unidade coerente que é o “usecase”;

• Um objeto pode desempenhar vários papéis sendo entãomodelado por diversos atores;

• Pode ser representado por um retângulo com <<actor>> e onome do ator dentro do retângulo,

• Também podem ser representados pelo “homenzinho” (stickman).


Curso de A



Diagrama de Use Cases e Atores

use case 1

use case 3

use case 2

ator 1 ator 2

fronteira do sistema


Curso de A



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.


Curso de A



Identificação preliminar de Use Cases (1)Exemplo da biblioteca

• Identificar as funcionalidades acessíveis a cada grupo deobjetos 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 eacesso total.


Curso de A



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 eobras - só pode ser funcionário-operador ) ;

• ......


Curso de A



Atores secundários

• Participam de “use cases” que não são fundamentaisdo 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 comomudar valor da multa diária, alterar cotas de empréstimo,etc...;


Curso de A



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;

– ...............


Curso de A



Cadastrador

Cadastrar Obra

atendente

Cadastrar Usuário

Emprestar de Obra

Devolver Obra UMLib

Diagrama preliminar dos Use Cases


Curso de A



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:


Curso de A



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 nosistema, e preenche (em um formulário na tela do seu computador deatendimento) o campo respectivo com o código do mesmo. Depois solicitaráao usuário que digite a sua senha no “keypad” .Posteriormente verifica naobra selecionada pelo usuário o número de tombo da mesmas entrando estenúmero no campo apropriado. Finalmente pressiona o botão para efetivar oempréstimo. Caso o usuário esteja habilitado ao empréstimo das obrassolicitadas, o sistema dará uma mensagem de sucesso. O atendente entãocarimbará as obras liberando as mesmas para o usuário.


Curso de A




• Com base na especificação de requisitos fornecida(espereq50_01.pdf) e no exemplo(UseCaseEmpObra.pdf) tente fazer um detalhamentosemelhante para o Use Case Reservar título.


Curso de A



Associações entre Use Cases

• Comunicação - relação entre um ator e um “usecase”;

• Extends - quando a funcionalidade embutida em um“use case” é uma opção de extensão dafuncionalidade de um outro “use case”;

• Include - indica que a funcionalidade de um “usecase” está incluída no outro, no curso principal.


Curso de A



Trabalho de pesquisa p/ casa

• Pesquise na norma UML e no livro texto do curso, asrelações Extend e Include entre Use Cases. Faça umresumo do significado de cada uma, cite em quecasos devem ser usadas e dê exemplos.

• Este trabalho deve ser feito até o dia 30/8 e enviadopor e-mail para [email protected] colocando na linhade assunto APSIIturmaTP1_matricula. Exemplo delinha de assunto APSIINKATP1_98123456. Colocarno corpo do trabalho o nome, matrícula e turma.


Curso de A



Protótipo das Interfaces

• Servem como complemento aos “use cases”;

• Pode ser utilizada a técnica de prototipação, para semostrar ao usuário uma sequência de telas ao se“executar” um “use case”.


Curso de A



Formulário Principal Emprestar Obra


Curso de A



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.


Curso de A



Verificações e inspeções

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

• Verificar coerência entre os use cases e as interfaces.


Curso de A



Iterações

• Na primeira iteração devem ser identificados emodelados os use cases mais significativos dosrequisitos, Ex: EmprestarObra, ReservarTitulo,DevolverObra, CadastrarTitulo, CadastrarObra eCadastrarUsuario,.......

• Deve-se também tentar nas primeiras iteraçõesidentificar os use cases que tenham maior interaçãocom os atores, que envolvam maiores riscos e quevenham a ter maiores impactos na arquitetura.


Curso de A




• No exemplo da biblioteca, qual Use Case você achaque teria um maior impacto na arquitetura dasolução? Explique sua escolha.


Curso de A



Prática de laboratório

• Após estudar no tutorial da ferramenta Rose comocriar um Use Case, um ator e um diagrama de usecases, criar (utilizando a versão 4.0 da ferramenta dolaboratório) um diagrama de use cases da biblioteca(como o da transparência 44) com pelo menos 8 UseCases da biblioteca. Descrever o resumo do fluxoprincipal de pelo menos 3 Use Cases.

• Obs: nesta fase não deve ser utilizada versão maisrecente da ferramenta.


Curso de A



Observações Finais

• Os use cases conduzem todo o desenvolvimento, oque permite uma coerência entre os modelos geradosnas diversas fases, pois todos estarão centrados emrefinar os use cases. Outras metodologias (ouprocessos) não têm esta abordagem, tentamidentificar todos os objetos, suas relações eposteriormente fazer algum tipo de modularização.


Curso de A



Referências

• Jacobson, Ivar; Booch, Grady; Rumbaugh, James. TheUnified Software Development Process. Addison-WesleyLongman, Inc, 1999.

• Kruchten, Philippe. The Rational Unified Process - AnIntroduction. Addisson Wesley Longman Inc, 1999.

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

análise e projeto oo com uml lição 3 especificação e ... reference... especificação e...

Documents