Aula 2

Prévia do material em texto

- -1
MODELAGEM DE SISTEMAS
USO E MODELAGEM DE REQUISITOS
- -2
Olá!
Bom dia!
Nesta aula, abordaremos os conceitos e classificação dos requisitos, como elemento fundamental para uma etapa
dentro do processo de desenvolvimento de software.
Vamos apresentar o diagrama de casos de uso, representante da UML para a visão de requisitos de sistemas.
Completaremos a aula aprendendo a identificar os casos de uso, os respectivos atores a eles relacionados e a
construir o diagrama a partir desta identificação.
Bons estudos!
Objetivos
•Definir o conceito e classificação de requisitos;
•Identificar a finalidade do diagrama de casos de uso;
•Reconhecer os elementos do diagrama de casos de uso;
•Aplicar os casos de uso, a partir de um contexto do sistema.
Requisitos de um sistema
O primeiro passo para a modelagem de um sistema é saber quais são os seus . Nesse processo, o requisitos
 adequado dos são passos fundamentais para olevantamento e mapeamento requisitos de um sistema 
sucesso do produto final a ser gerado: o software.
O precisa ter as adequadas para .software funcionalidades satisfazer as necessidades de seus usuários
Portanto, durante o processo de desenvolvimento de software é preciso ter cuidado e, se possível, garantias de
que os requisitos estão sendo corretamente capturados e compreendidos pelos analistas de sistemas.
Levantamento de requisitos
Fique ligado
A disponibiliza para esse fim o UML ( ) linguagem unificada de modelagem diagrama de
, cuja finalidade é casos de uso mapear as funcionalidades do sistema, evidenciando os
atores que com elas interagem.
- -3
De uma forma geral, os são requisitos necessidades dos usuários que os sistemas precisam atender.
As atividades de são fundamentais para todo olevantar e identificar os requisitos processo de
 pois uma vez poderemos desenvolvimento de sistemas, conhecidas as reais necessidades de seus usuários
desenvolver o sistema adequado.
Em contrapartida, se as necessidades identificadas não forem as reais, o sistema não atenderá ao que seus
 , e a tendência é que seja .usuários precisam descartado
Pense um pouco:
Apenas identificar os requisitos de um sistema corretamente é o suficiente?
Não
Pois temos de de forma a controlar o processo de desenvolvimento do software garantir que os requisitos
estão sendo interpretados, entendidos e implementados de forma adequada pela equipe de
.desenvolvimento
Ou seja, a garantia de atender aos usuários implementando adequadamente os requisitos que reflitam as suas
necessidades depende de que garantam a qualidade do software durante todo o procedimentos de controle
seu processo de desenvolvimento.
Levantar requisitos implica em sabermos o sistema precisa fazer para atender as necessidades de seuso que 
usuários. A qualidade do levantamento de , requisitos influencia todo o processo de desenvolvimento
especialmente as , necessárias ao longo do processo de desenvolvimento evalidações junto aos usuários
sobretudo na . adequação do software
Tipos de requisitos
O . Veja: levantamento de requisitos visa identificar dois tipos de requisitos
• Funcionais
Os requisitos funcionais representam as funcionalidades necessárias para atender as
necessidades dos usuários do sistema.
Veja :alguns exemplos de requisitos funcionais para um sistema de Folha de Pagamento
• Registro dos dados dos funcionários;
• Registro do salário bruto de cada funcionário;
• Cálculo da folha de pagamento;
• Cadastramento da tabela de imposto de renda;
• Emissão do recibo de pagamento;
• Dentre outras funções necessárias ao sistema.
• Não funcionais
•
•
•
•
•
•
•
•
- -4
Não funcionais
Apresentam restrições e qualidades do sistema e suas funcionalidades.
Eles representam os . Podem ser expressos em termos do sistemaatributos e propriedades do sistema
como um todo, como por exemplo: o sistema deve ser operado por uma tela de toque (touch screen),
denotando um requisito não funcional de usabilidade.
Os requisitos não funcionais podem representar também . Por propriedades de uma função específica
exemplo: o usuário pode ter a necessidade de especificar que a impressão do boleto de venda (função)
não deve demorar mais que 10 segundos (requisito não funcional), representando um requisito não
funcional que visa a performance do sistema.
Diagrama de casos de uso
Como vimos, o tem como objetivo .diagrama de casos de uso apresentar os requisitos funcionais do sistema
Ou seja, é um diagrama que começa a ser usado após o levantamento de requisitos, de forma a mapear as
funcionalidades do sistema, documentando o sistema faz. o que 
O é um dos mais informais e simples, dentre os diagramas propostos pela diagrama de casos de uso UML
, e sua(Linguagem Unificada de Modelagem) finalidade é apresentar as principais funcionalidades que o
sistema precisa ter.
Curiosidade!
O diagrama de casos de uso pode, ainda, ser usado durante determinadas técnicas de elicitação de requisitos,
como o JAD ( ), que visa extrair requisitos de usuários de forma coletiva e colaborativa.Joint Application Design
Saiba mais
Durante uma sessão JAD, componentes da equipe técnica, como engenheiros de requisitos e
/ou analistas de sistemas, podem desenhar diagramas de casos de uso, para identificar as
funcionalidades requeridas pelo sistema, de forma a atender as necessidades desses usuários.
Outra finalidade do diagrama de casos de uso é possibilitar que os requisitos possam ser
, de forma que se tenha certeza de que:validados junto aos usuários
Todos os requisitos funcionais foram identificados;
O entendimento da equipe de desenvolvimento, no que tange aos requisitos identificados, está
correto e corresponde à realidade.
Nesse diagrama, não mostramos detalhes de o sistema realizará suas funcionalidades.como 
- -5
Elementos do diagrama de casos de uso
Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de serem representados, que são:
• Os atores
• Os casos de uso
• Os relacionamentos
•
•
•
- -6
Ator
Vamos conhecer cada elemento do diagrama de casos de uso separadamente, e vamos iniciar pelo elemento .Ator
O , que . Um ator participa (realiza) umator é algo com comportamento interage diretamente com o sistema
ou mais casos de uso do sistema. A , é o ,representação do ator, no diagrama de casos de uso boneco
chamado de , conforme a figura abaixo:stickman
- -7
Um ator é o papel que o agente desempenha em relação ao sistema. Ele pode representar:
1 (Gerente de Compras) ou (Cliente e Fornecedor)Papéis internos externos 
2 (Contabilidade e Contas a Pagar), bem como Setores e departamentos da empresa funções
 (almoxarifado).desempenhadas na empresa
3 , como por exemplo hardware e servidores, ou , como sistemas.Dispositivos eletrônicos dispositivos lógicos
- -8
Identificando atores
O primeiro passo para a construção do modelo de casos de uso é a . Algumas perguntas identificação de atores
são úteis nesta situação, veja:
• Quais órgãos, empresas ou pessoas farão uso deste sistema de informação?
• Que sistemas ou equipamentos irão se comunicar com o sistema que será desenvolvido?
• Quem deve ser informado de alguma ocorrência no sistema?
• A quem pode interessar os requisitos funcionais do sistema?
Casos de uso
Outro elemento do diagrama são os casos de uso.
Segundo Jacobson, um dos criadores da UML, um caso de uso é uma descrição narrativa de uma sequência
.de eventos que ocorre quando um ator usa um sistema para realizar uma tarefa
Os casos de uso representam, através de , as , conforme a imagem a seguir:elipses funcionalidades do sistema
Sendo uma funcionalidade, o nome do caso de uso deve ser composto por um verbo no Infinitivo +
 como o exemplo acima: “Matricular em Curso”.complemento verbal,
Identificando casos de uso
Como já fizemos a identificação dos atores, podemos passar . Esse processoà identificação dos casos de uso
deve seguir duas etapas, veja:
1 Em primeiro lugar, podemos pensar nos casos de uso que representam os . Estescasos deobjetivos dos atores
uso representam os processos da empresa, e algumas perguntas são úteis neste momento:
• Quais as necessidades e objetivos de cada ator em relação ao sistema?
• Que informações serão produzidas pelo sistema?
•
•
•
•
•
•
- -9
• Quais as necessidades e objetivos de cada ator em relação ao sistema?
• Que informações serão produzidas pelo sistema?
• O sistema realizará alguma ação que ocorre de forma regular no tempo?
• Existe um caso de uso para atender cada requisito funcional?
2 Em seguida, podemos pensar nos casos de uso que não representam um benefício direto para os atores,
mas são necessários para o funcionamento do sistema. Tais casos de uso englobam emanutenção de cadastros 
de informações provenientes de outros sistemas.
Cenários
Um . Descreve uma . Cada caso de uso é um conjunto de cenários sequência de ações do ator e do sistema
sequência de ações é chamada de cenário.
Portanto, um que ilustra o .cenário é uma sequência específica de ações comportamento do caso de uso
Relacionamentos ou associações
O possibilita, ainda, a : diagrama de casos de uso existência de relacionamentos entre
• Atores e casos de uso
• Atores entre si
• Casos de uso entre si
A seguir, vamos conhecer cada tipo de relacionamento com mais detalhe!
Relacionamentos entre atores e casos de uso
Esse é o relacionamento mais comum, e é indicado por uma , que liga o ator ao caso de uso, linha sólida
denotando que o .ator interage com o caso de uso
A nesse relacionamento é , ou seja, o ator informa dados ao caso de uso e recebecomunicação bidirecional
informações por ele processadas.
Relacionamentos de atores entre si
Entre atores, é possível haver o relacionamento de generalização/ especialização, representado por uma linha
sólida com uma seta na extremidade que aponta para o ator geral, conforme ilustrado nesta imagem:
•
•
•
•
•
•
•
- -10
Observe que nesse exemplo, o ator geral é o “Funcionário” e o ator especialista, o “Gerente”. Este também exerce
as atividades de um funcionário, porém como gerente tem tarefas específicas a sua função.
Vamos analisar mais um exemplo de .relacionamento de generalização/ especialização entre atores
Observe a leitura desse diagrama:
- -11
- -12
- -13
Relacionamentos de Casos de uso entre si
Casos de uso podem conectar por três tipos de relacionamentos:
Inclusão (include ou uses);
Extensão (extend);
Generalização.
Relacionamentos entre Casos de uso por inclusão
Nesse tipo de relacionamento, um (principal) incorpora, explicitamente, o caso de uso comportamento de
 (incluído).outro caso de uso
O é parte integrante do caso de uso principal. A fatoração (separação desse caso de uso) caso de uso incluído 
acontece porque outros casos de uso também poderão incorporar o caso de uso incluído e, assim, evitar
repetições de fluxos.
O diagrama abaixo demonstra o relacionamento de casos de uso por inclusão:
- -14
- -15
Relacionamentos entre Casos de uso por extensão
Esse tipo de relacionamento é usado para ; uma descrever cenários opcionais em um caso de uso variação do
comportamento normal.
Veja a seguir uma descrição do relacionamento de casos de uso por :extensão
Um caso B (caso de uso estendido) estende A (caso de uso principal) quando alguma condição interrompe a
execução do caso A (caso de uso principal) para que B (caso de uso estendido) execute e retorne, ao final, ao caso
de uso A (caso de uso principal).
A interrupção é feita no chamado ponto de extensão. Esta imagem ilustra o relacionamento de extensão:
Exemplos de Casos de uso por extensão
Para que você entenda melhor como acontece o relacionamento de casos de uso por extensão, trouxemos dois
exemplos que iremos analisar. Veja:
- -16
O caso de uso “Enviar Informe de Dívida” estende o caso de uso “Cancelar Matrícula em Curso”.
Esse caso de uso somente será executado se o cancelamento do curso implica em pagamento de dívida do aluno;
caso o aluno esteja quite com o curso, o caso de uso não será executado.
- -17
Observe como os casos de uso “Pagar em Cheque” ou “Pagar em Cartão” estendem o caso de uso “Pagar
Mensalidade”.
Neste caso, haverá uma condição a ser avaliada, que é a forma de pagamento e, de acordo com o valor desta, será
executado um ou outro caso de uso: apenas um deles será executado, ou seja, são mutuamente exclusivos.
Relacionamentos entre Casos de uso por generalização
Esse tipo de relacionamento é usado quando , mas um caso de uso é semelhante a outro executa algumas
funções a mais.
Ele é pouco usado, pois seu uso confunde-se com o , na medida em que este também pode resolver essaextend
questão da variação de comportamento, neste caso um comportamento com adição de funcionalidade.
O diagrama a seguir ilustra o relacionamento de casos de uso por generalização:
- -18
Vamos analisar um exemplo de caso de uso por generalização. Observe:
O que vem na próxima aula
•A importância da especificação ou descrição textual do caso de uso, em complemento ao diagrama;
•As técnicas de descrição textual da interação dos atores com os casos de uso (funcionalidades do sistema).
CONCLUSÃO
Nesta aula, você:
• Reconheceu que o levantamento de requisitos é fundamental para a qualidade do software a ser 
Saiba mais
Para saber mais sobre os assuntos estudados nesta aula, acesse os seguintes sites:=
UML.
http://www.uml.org/
Versões do UML.
https://www.mindomo.com/pt/mindmap/versoes-%20uml-
164c4e92e9c8458ca29cd8e569b1511f
•
- -19
• Reconheceu que o levantamento de requisitos é fundamental para a qualidade do software a ser 
desenvolvido;
• Distinguiu os dois tipos de requisitos, caracterizando e exemplificando cada um deles;
• Identificou a importância do modelo de casos de uso para um adequado mapeamento dos requisitos 
funcionais, sob a forma do diagrama de casos de uso.
•
•
•