AULA2 MODELAGEM

Prévia do material em texto

Aula -2 – O uso e modelagem de requisitos 
O primeiro passo para a modelagem de um sistema é saber quais são os 
seus requisitos. Nesse processo, o levantamento e mapeamento 
adequado dos requisitos de um sistema são passos fundamentais para o 
sucesso do produto final a ser gerado: o software. 
O software precisa ter as funcionalidades adequadas para 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. 
A UML (linguagem unificada de modelagem) disponibiliza para esse fim o 
diagrama de casos de uso, cuja finalidade é mapear as funcionalidades do 
sistema, evidenciando os atores que com elas interagem. 
Levantamento de requisitos 
De uma forma geral, os requisitos são necessidades dos usuários que os 
sistemas precisam atender. 
As atividades de levantar e identificar os requisitos são fundamentais para 
todo o processo de desenvolvimento de sistemas, pois uma vez 
conhecidas as reais necessidades de seus usuários poderemos 
desenvolver o sistema adequado. 
Em contrapartida, se as necessidades identificadas não forem as reais, o 
sistema não atenderá ao que seus usuários precisam, e a tendência é que 
seja descartado. 
 
Pense um pouco: 
Apenas identificar os requisitos de um sistema corretamente é o 
suficiente? 
Não, Pois temos de controlar o processo de desenvolvimento do software 
de forma a 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 procedimentos de controle que garantam a qualidade do software 
durante todo o seu processo de desenvolvimento. 
Levantar requisitos implica em sabermos o que o sistema precisa fazer 
para atender as necessidades de seus usuários. A qualidade do 
levantamento de requisitos influencia todo o processo de 
desenvolvimento, especialmente as validações junto aos usuários, 
necessárias ao longo do processo de desenvolvimento e sobretudo na 
adequação do software. 
O levantamento de requisitos visa identificar dois tipos de requisitos. Veja: 
Funcional: 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 
Apresentam restrições e qualidades do sistema e suas funcionalidades. 
 
Eles representam os atributos e propriedades do sistema. Podem ser expressos em 
termos 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 propriedades de uma função 
específica. Por 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. 
Diagramas de Casos Usos 
Como vimos, o diagrama de casos de uso tem como objetivo 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 que o sistema faz. 
O diagrama de casos de uso é um dos mais informais e simples, dentre os diagramas 
propostos pela UML (Linguagem Unificada de Modelagem), e sua 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 (Joint Application Design), que visa extrair 
requisitos de usuários de forma coletiva e colaborativa. 
Para saber mais, clique no botão abaixo: 
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 validados junto aos usuários, de forma que se tenha certeza de que: 
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 como o sistema realizará suas 
funcionalidades. 
 
Elementos do diagrama de casos de uso 
Atores 
Casos de Uso 
Relacionamentos 
 
Ator 
O ator é algo com comportamento, que interage diretamente com o sistema. Um ator 
participa (realiza) um ou mais casos de uso do sistema. A representação do ator, no 
diagrama de casos de uso, é o boneco, chamado de stickman, conforme a figura ao 
lado: 
Papéis internos (Gerente de Compras) ou externos (Cliente e Fornecedor)
 
Setores e departamentos da empresa (Contabilidade e Contas a Pagar), bem como 
funções desempenhadas na empresa (almoxarifado). 
 
Dispositivos eletrônicos, como por exemplo hardware e servidores, ou dispositivos 
lógicos, como sistemas. 
 
Identificando Atores 
O primeiro passo para a construção do modelo de casos de uso é a identificação de 
atores. Algumas perguntas 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? 
Caso 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 elipses, as funcionalidades do sistema, 
conforme a imagem a seguir: 
Sendo uma funcionalidade, o nome do caso de uso deve ser composto por um verbo 
no Infinitivo + complemento verbal, como o exemplo acima: “Matricular em Curso”. 
 
Como já fizemos a identificação dos atores, podemos passar à identificação dos casos 
de uso. Esse processo deve seguir duas etapas, veja: 
Em primeiro lugar, podemos pensar nos casos de uso que representam os objetivos 
dos atores. Estes casos de 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? 
O sistema realizará alguma ação que ocorre de forma regular no tempo? 
Existe um caso de uso para atender cada requisito funcional? 
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 manutenção de cadastros e de informações provenientes de 
outros sistemas. 
Cenários 
Um caso de uso é um conjunto de cenários. Descreve uma sequência de ações do ator 
e do sistema. Cada sequência de ações échamada de cenário. 
Portanto, um cenário é uma sequência específica de ações que ilustra o 
comportamento do caso de uso.