Baixe o app para aproveitar ainda mais
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. • • •
Compartilhar