Baixe o app para aproveitar ainda mais
Prévia do material em texto
E-book 2 ANÁLISE E PROJETO DE SISTEMAS Gláucia Silva Bierwagen Neste E-Book: INTRODUÇÃO ���������������������������������������������� 3 ELICITAÇÃO DE REQUISISTOS DE SISTEMAS ORIENTADOS A OBJETOS ��4 Elicitação de um requisito ���������������������������������������6 Técnicas para elicitação de requisitos �������������������8 Dificuldades para elicitação de requisitos ���������� 11 ESPECIFICAÇÃO DE REQUISISTOS DE SISTEMAS ORIENTADOS A OBJETOS ������������������������������������������������������13 Requisitos �������������������������������������������������������������� 13 A especificação de requisitos ������������������������������ 15 As especificações estruturadas ��������������������������� 17 Estrutura de documentos de especificação de requisitos ��������������������������������������������������������������� 20 ANÁLISE DE REQUISITOS ���������������������� 22 VALIDAÇÃO DE REQUISITOS ����������������26 FERRAMENTAS DE MODELAGEM �������28 CONSIDERAÇÕES FINAIS ����������������������30 SÍNTESE ��������������������������������������������������������31 2 INTRODUÇÃO Neste módulo você aprenderá o que é elicitação ou levantamento de requisitos – uma fase muito impor- tante na elaboração de softwares e sistemas� Ela envolve muito diálogo entre desenvolvedores, clientes e usuários finais para que o produto tenha sucesso. Você estudará, também, quem são os principais atores envolvidos no desenvolvimento de um siste- ma, como projetistas, gerentes, etc.; conhecerá as principais técnicas de elicitação de requisitos, como entrevistas, observações, dentre outras. Além disso, compreenderá melhor o que são requisitos e quais são os seus principais tipos; bem como os tipos de escrita na especificação de requisitos, ou seja, a fase de escrita da documentação� Em seguida, você compreenderá que na análise de projetos é necessário identificar fases que auxiliam a ter detalhes pormenorizados do projeto, como: pro- jeto de algoritmos, de interface gráfica, entre outros. Você conhecerá as principais verificações e técnicas de validação de requisitos e, por fim, estudará alguns exemplos de ferramentas de modelagem. Aproveite a leitura! 3 ELICITAÇÃO DE REQUISISTOS DE SISTEMAS ORIENTADOS A OBJETOS Neste tópico você aprenderá que, para que um pro- jeto de desenvolvimento de sistema dê certo, é im- portante que ele atenda o cliente� Sendo assim, é preciso que se registre e valide – por meio de do- cumentação – todas as necessidades do cliente� Isso é muito importante, pois, durante a finalização e entrega do produto, o cliente pode expressar que aquele não foi o produto que solicitou� Mas, como é possíviel comprovar que o produto elaborado está compatível com o que foi solicitado? A solução para isso é fazer um levantamento de do- cumentação chamada de requisitos. O que é isso? Requisitos é o nome que se dá ao conjunto de docu- mentos de descrições dos serviços que serão ofere- cidos pelo sistema e suas restrições operacionais, de modo que satisfaça as necessidades/desejos do cliente. Os requisitos do usuário referem-se às necessidades dos clientes, e os requisitos do siste- ma relacionam-se às descrições mais detalhadas das funções, serviços e restrições operacionais do próprio sistema� Essa documentação deve estar alinhada e ser vali- dada pelo cliente e a equipe de desenvolvimento de softwares ou sistemas� É importante que você saiba que, dentro do escopo dos requisitos, é necessário 4 manter a rastreabilidade entre os elementos, visto que os demais elementos são evoluções do docu- mento, no decorrer do projeto (GONÇALVES, 2015; BEZERRA, 2007; FOWLER, 2005). FIQUE ATENTO É importante que você saiba que o termo de rastreabilidade é usado para realizar um mape- amento que é feito entre os elementos que se re- lacionam� Esse mapeamento pode ser feito por planilhas e por pares, por exemplo, requisitos fun- cionais versus casos de uso (SOMMERVILLE, p. 2019, p. 78). A geração de um documento de requisitos é realizada a partir do levantamento, mediante informações dos usuários. Após a criação desse documento, faz-se a especificação de casos de uso (ou história dos usuários). A seguir, temos os seguintes passos: 1. Criação de diagramas da UML para cada especi- ficação de caso de uso. 2. Desenvolvimento de códigos a partir dos diagra- mas gerados e da especificação de caso de uso (ou história do usuário). 3. Criação de planilhas de teste, tendo como base a especificação de caso de uso (ou história do usuário). 4. Validação pelo cliente do software desenvolvi- do, sendo que os requisitos que foram aceitos por 5 ele são utilizados como parâmetro para validar o sistema� 5. Finalmente, quando o software encontra-se em estágio de evolução, o documento de requisi- tos é a raiz das mudanças a serem implementadas (GONÇALVES, 2015; SOMMERVILLE, 2019). Em seguida, você estudará as principais técnicas e tecnologias envolvidas na Elicitação de Requisistos, ou seja, o levantamento e a compreensão destes� Elicitação de um requisito Para fazer o levantamento ou elicitação de requisitos é necessário que os profissionais envolvidos no de- senvolvimento de software relacionem-se diretamen- te com os clientes – que podem somente contratar os sistemas e não usá-los, ou serem os usuários finais do sistema – para aprender sobre o domínio da aplicação, as funcionalidades do sistema, o de- sempenho esperado e as restrições de infraestrutura. Nesta fase de levantamento é importante saber que o trabalho colaborativo de vários profissionais trará uma visão mais abrangente para elencar todos os requisitos. A reunião de informações virá de docu- mentação e interação com stakeholders, ou seja, o público de interesse para levantamento de requisitos� Mas, quem são os principais atores da equipe de desenvolvimento? Podemos ter os seguintes profissionais: 6 ● Gerentes de Projetos: são os profissionais respon- sáveis pela gerência ou coordenação das atividades necessárias à construção do sistema; elaboração de orçamentos, cronogramas de execução das ati- vidades, definição do processo de desenvolvimento, atribuições da equipe, os recursos de hardware e software, etc� ● Analistas: são os profissionais que compreendem os problemas do domínio do negócio para que pos- sam definir os requisitos do sistema a ser desen- volvido. São profissionais que, além de ter conhe- ciemtno básico da área de domínio, devem ter boa comunicação com os especialistas do domínio para obter conhecimento acerca dos problemas e das ne- cessidades envolvidas na organização empresarial. ● Projetistas: são os integrantes da equipe de de- senvolvimento cujas funções são: (1) avaliar as al- ternativas de solução (da definição) do problema resultante da análise e (2) gerar a especificação de uma solução computacional detalhada. ● Arquitetos de software: são profissionais que ela- boram a arquitetura do sistema como um todo� Este profissional é quem toma decisões sobre quais se- rão os subsistemas que compõem o sistema como um todo e quais serão as interfaces entre esses subsistemas� ● Programadores: são os profissionais responsáveis pela implementação do sistema. Podem ser profi- cientes em uma ou mais linguagens de programação, 7 além de conhecer banco de dados. Um projeto mais complexo poderá ter vários programadores. ● Especialistas de domínio ou especialistas de ne- gócio: são os profissionais que possuem conheci- mentos sobre a área ou do negócio em que o sistema em desenvolvimento estará inserido� ● Avaliadores de qualidade: são profissionais que asseguram a adequação do processo de desenvol- vimento e do produto de software, conforme os pa- drões de qualidade estabelecidos pela organização (BEZERRA, 2007, pp. 31-35). Além da equipe responsável pelo desenvolvimento, temos outros atores envolvidos, como os stakehol- ders, que são o público de interesse para o levanta- mento de requisitos� Além deles, outras fontes de requisitos são: ambientefísico, documentação (for- mulários, por exemplo), dados existentes, recursos existentes, sistemas legados e Segurança. Realizar a extração dos requisitos do domínio do problema não é uma tarefa fácil� Mas, o que pode contribuir para isso? Vamos conferir? Técnicas para elicitação de requisitos ● A realização de entrevistas – a equipe análise de sistemas reúne-se com o(s) stakeholder(s) para uma conversa sobre as necessidades e expectativas em relação ao sistema a ser desenvolvido� 8 ● A observação do ambiente onde a aplicação irá funcionar, com o objetivo de captar informações acerca do funcionamento dos processos da empresa� ● Etnografia de uma imersão total no ambiente dos clientes, por meio de observação� ● A demonstração de tarefas específicas pode ser mostrada detalhadamente e repetidas vezes. Diante desse cenário, a técnica de demonstração de tarefa é utilizada; os stakeholders fazem a demonstração das tarefas aos analistas de sistemas� ● Estudo de documento em papel – formulários de cadastro e relatórios já utilizados auxiliam bastante a atividade de elicitação de requisitos, uma vez que estes podem revelar um conjunto de dados esperado para uma funcionalidade� ● Substituição do usuário (role playing) em tarefas específicas e complexas, em que o analista repete os passos, sendo auxiliado pelo usuário em relação às dúvidas que possam surgir. ● A aplicação de um questionário que pode consistir em um conjunto de perguntas que devem ser respon- didas pelos usuários� Serve para tirar dúvidas com relação aos requisitos já elicitados ou na descoberta de novos� ● A técnica de brainstorming (tempestade de ideias) permite que os participantes de diferentes perfis em uma reunião, durante um período de tempo estabele- cido, possam ditar ideias, que são escritas de modo que todos visualizem. Quando a sessão se encerra, 9 as repetições de ideias são retiradas e as que geram dúvidas são explicadas. As melhores ideias esco- lhidas coletivamente são analisadas, melhoradas e aproveitadas� Figura 1: Brainstorming. Fonte: Pexels. ● A prototipação consiste na criação de um esboço inacabado que demonstre uma determinada fun- cionalidade do sistema� Normalmente, esse esboço representa a parte de interface gráfica, com os for- mulários, com botões e campos de texto; no entanto, sem acesso a banco de dados, tratamento de cam- pos ou processamento de cálculos� ● Os workshops ou oficinas de requisitos podem reunir todos os envolvidos durante um período cur- to, mas intensivo e focado� Nesse período, várias técnicas mencionadas podem ser aplicadas se- 10 https://www.pexels.com/pt-br/foto/brainstorm-comodo-complexo-complicado-212286/ quencialmente (BEZERRA, 2007; GONÇALVES, 2015; SOMMERVILLE, 2019). Dificuldades para elicitação de requisitos A elicitação e a compreensão dos requisitos dos stakeholders e análise desses é um processo com feedback contínuo de cada atividade para as outras atividades, que começa com a descoberta de requi- sitos e termina com sua documentação� No entanto, essa tarefa não é fácil, pois stakeholders: 1. costumam não saber o que querem de um siste- ma computacional; eles podem achar difícil articular o que querem que o sistema faça, e, como não sabem o que é viável e o que não é, podem fazer exigências inviáveis� 2. expressam requisitos em seus próprios termos e com o conhecimento implícito de seu próprio trabalho. 3. de vários perfis podem ter requisitos diferentes e podem expressar essas diferenças de várias ma- neiras. Os analistas de requisitos precisam descobrir todas as potenciais fontes de requisitos e descobrir as semelhanças e conflitos (SOMMERVILLE, 2019, p. 71). Além destes, fatores políticos – como a posição de um stakeholder – podem influenciar os requisitos 11 do sistema. O ambiente econômico e empresarial – que são dinâmicos – podem interferir na análise, suprimindo, alterando, ou no surgimento de outros requisitos� Podcast 1 Em seguida, você analisará quais são os tipos de requisitos e a Especificação de Requisitos, ou seja, a documentação escrita dos requisitos� 12 https://famonline.instructure.com/files/707594/download?download_frd=1 ESPECIFICAÇÃO DE REQUISISTOS DE SISTEMAS ORIENTADOS A OBJETOS Neste tópico, você aprenderá sobre quais são os tipos de requisitos e a Especificação de Requisitos, ou seja, a documentação escrita de requisitos� Requisitos Como estudamos anteriormente, existem os requisi- tos de usuários e os do próprio sistema� Você apren- derá também o que são os requisitos funcionais e não funcionais� Vamos lá? ● Requisitos funcionais são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações ou não deve fazer. ● Requisitos não funcionais são restrições aos ser- viços ou funções oferecidos pelo sistema. Incluem restrições de timing, restrições no processo de desen- volvimento do software, e restrições impostas pelas normas das organizações e legislações. Ao contrário das características individuais ou serviços do sis- tema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo� São requisitos usados para garantir a confiabilidade e o desempe- nho do sistema, a segurança e a usabilidade. 13 ● Requisitos de domínio, por sua vez, refletem ne- cessidades relacionadas ao domínio da aplicação e incluem uma terminologia específica de domínio ou fazem referência a conceitos do domínio. Podem estar relacionados com: velocidade de execução, confiabilidade, interoperabilidade com outros siste- mas e leis que estejam relacionadas ao domínio da aplicação (vide figura 2) (SOMMERVILLE, 2019, p. 60). Requisitos de eficiência Requisitos de confiança Requisitos de proteção Requisitos reguladores Requisitos éticos Requisitos de usabilidade Requisitos organizacionais Requisitos não funcionais Requisitos legais Requisitos de desenvolvimento Requisitos operacionais Requisitos ambientais Requisitos de segurança/ proteção Requisitos contábeis Requisitos externos Requisitos de produto Diagrama de Implantação Diagrama de Pacotes Figura 2: Figura 2. Tipos de requisitos não funcionais. Fonte: Sommerville (2019) adaptado. 14 A especificação de requisitos Durante a especificação dos requisitos – ou seja, a documentação escrita de requisitos – é necessário que o texto seja escrito com muita clareza para evitar ambiguidades que, eventualmente, ocorrem na escri- ta de textos em Língua Portuguesa. A escrita clara evita má interpretação e a criação de elmentos de forma errada. Que elementos são esses? Diagramas, códigos, protótipos de interface e planilhas de testes. Duas propriedades são muito importantes para evitar ambiguidades na escrita: completeza e consistên- cia. Completeza significa que tudo que o usuário precisa que seja implementado esteja definido, e consistência significa que os requisitos não devem ter definições contraditórias. FIQUE ATENTO Observe como exemplo a seguinte definição con- traditória, escrita em um documento de requisi- tos: “Inicialmente, nenhum usuário deve vir pré- -cadastrado no sistema”; mas, em outro trecho, lemos uma informação contraditória: “O primeiro acesso ao sistema deve ser feito com o perfil de adminstrador, que deve vir pré-cadastrado”� O uso de jargões e siglas computacionais também deve ser evitado na escrita dos requisitos� Você per- ceberá que, para auxiliar a escrita, convém que se crie um formato-padrão que garanta que todas as definições de requisitos estejam adequadas a ele. 15 O requisito deve ser expresso em uma única frase. A justificativa do requisito pode incluir informações sobre quem o propôs (a fonte do requisito), para saber quem consultar, caso ele tenha de ser muda- do� Pode-se destacar as partes fundamentais do requisito usando negrito, itálico ou cores� E, sempre que possível, tentarassociar uma lógica a cada um dos requisitos para identificá-los. Isso ajuda muito, quando eles são alterados (SOMMERVILLE, 2019). Você sabe quais são os tipos de escrita para a espe- cificação dos requisitos de sistemas? Se não sabe, observe: Notação Descrição Sentenças em linguagem natural Os requisitos são escritos em frases nume- radas em linguagem natural� Cada frase deve expressar um requisito. Linguagem natural estruturada� Linguagem natural estruturada Os requisitos são escritos em linguagem natural em um formulário-padrão ou template� Cada campo fornece informações sobre um aspecto do requisito� Linguagem de descrição de projeto Essa abordagem usa uma linguagem como de programação, mas com características mais abstratas, para especificar os requisitos, definindo um modelo operacional do sistema. É útil para especificações de interface. Notações gráficas Para definição dos requisitos funcionais para o sistema são usados modelos gráficos, suple- mentados por anotações de texto; diagramas de caso de uso e de sequência da UML são comumente usados� 16 Notação Descrição Especificações matemáticas Essas notações são baseadas em conceitos matemáticos, como máquinas de estado finito ou conjuntos. Embora essas especificações inequívocas possam reduzir a ambiguidade de um documento de requisitos, a maioria dos clientes não entende uma especificação formal. Eles não podem verificar que elas re- presentam o que eles querem e são relutantes em aceitá-las como um contrato de sistema� Tabela 1: Escritas da especificação de requisitos. Fonte: Sommerville (2019) Vamos verificar, a seguir, as especificações estruturadas� As especificações estruturadas A linguagem natural estruturada trata-se de uma for- ma de escrever que permite certa liberdade, mas é limitada, pois segue um formato-padrão� Isso garante a expressividade e a compreensão de uma linguagem natural, mas, ao mesmo tempo, faz com que exista uma regularidade na especificação. É possível usar templates para especificar requisitos do sistema e construções de linguagens de programação para mostrar alternativas e iteração. A especificação pode ser estruturada em torno dos objetos, das funções desempenhadas e de eventos processados pelo sis- tema (SOMMERVILLE, 2019). 17 REFLITA Vamos fazer uma pausa e pensar um pouco. Você consegue visualizar mentalmente qual se- ria a importância de usar requisitos em um pro- jeto de desenvolvimento de sistemas? E qual é a diferença entre Elicitação e Especificação de requisitos? Pense nisso! No uso de formulários-padrão para especificar re- quisitos funcionais, devemos incluir as seguintes informações: 1. A descrição da função ou entidade a ser especificada. 2. Uma descrição de suas entradas e de onde elas vieram� 3. Uma descrição de suas saídas e para onde elas irão� 4. Dados sobre a informação necessária para o pro- cessamento ou outras entidades usadas no sistema� 5. Uma descrição da ação a ser tomada� 6. Se uma abordagem funcional é usada, uma pré- -condição define o que deve ser verdade antes que a função seja chamada, e é chamada uma pós-condi- ção, especificando o que é verdade depois da função. 7. Uma descrição dos efeitos colaterais da operação (caso haja algum) (SOMMERVILLE, 2019, p. 69). Vamos observar, a seguir, um exemplo de uma espe- cificação baseada em formulários que, nessa situa- 18 ção, define a forma de calcular a dose de insulina a ser fornecida quando o açúcar no sangue está dentro de uma faixa de segurança. Nesse sistema, deve- -se medir o açúcar no sangue e fornecer insulina, se necessário, a cada dez minutos; a cada minuto, exe- cutar uma rotina (r) de autoteste com as condições a serem testadas e as ações associadas. Bomba de insulina/Sofware de Controle Função: Calcula doses de insulinas: nível seguro de açúcar. Descrição: Calcula a dose de insulina a ser fornecida quando o nível de açúcar está na zona de segurança entre três e setes unidades� Entradas: Leitura atual de açúcar (r2), duas leituras anteriores (r0 e r1). Fonte: Leitura atual da taxa de açúcar pelo sensor. Outras leituras da memória� Saídas: CompDose – a dose de insulina a ser fornecida� Destino: Loop principal de controle. Ação: CompDose é zero se o nível de açúcar está estável ou em queda ou se o nível está aumentando, mas a taxa de aumento está diminuindo. Se o nível está aumentando e a taxa de aumen- to está aumetando, então CompDose é calculado dividindo-se a diferença entre o nível atual de açúcar e o nível anterior por qua- tro e arredondando-se o resultado� Se o resultado é arredondado para zero, então CompDose é definida como a dose mínima que pode ser fornecida� Requisitos: Duas leituras anteriores, de modo que a taxa de varia- ção do nível de açúcar pode ser calculada� Pré-condição: O reservatório de inslina contém, no mínimo, o máximo de dose única permitida de insulina. Pós-condições: r0 é substituída por r1 e r1 é substituída por r2� Efeitos colaterais: Nenhum. Tabela 2: Especificação estruturada de um requisito para uma bomba de insulina. Fonte: Sommerville (2019) 19 Estrutura de documentos de especificação de requisitos Vamos entender (Tabela 2) como se pode estruturar um documento de especificacão de requisitos. Capítulo Descrição Prefácio Deve definir os possíveis leitores do documento e descrever seu histórico de versões, incluindo uma justificativa para a criação de uma nova versão e um resumo das mudanças feitas em cada versão� Introdução Deve descrever brevemente as funções do sistema e explicar como ele vai funcionar com outros sistemas� Também deve descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da organização que encomendou o software� Glossário Deve definir os termos técnicos usados no documento. Você não deve fazer suposições sobre a experiência ou o conhecimento do leitor� Definição de requisitos de usuário Deve descrever os serviços fornecidos ao usu- ário. Os requisitos não funcionais de sistema também devem ser descritos nessa seção� Essa descrição pode usar a linguagem natural, diagramas ou outras notações compreensí- veis para os clientes� Normas de produto e processos que devem ser seguidos devem ser especificados. Arquitetura de sistema Deve apresentar uma visão geral, em alto nível, da arquitetura do sistema previsto, mostrando a distribuição de funções entre os módulos do sistema� Componentes de arquitetura que são reusados devem ser destacados� Especificação de requisitos do sistema Deve descrever em detalhes os requisitos funcionais e não funcionais� Se necessário, também podem ser adicionados mais detalhes aos requisitos não funcionais� Interfaces com outros sistemas podem ser definidas. 20 Capítulo Descrição Modelos do sistema Pode incluir modelos gráficos do sistema que mostram os relacionamentos entre os compo- nentes do sistema, o sistema e seu ambiente� Exemplos de possíveis modelos são modelos de objetos, modelos de fluxo de dados ou mo- delos semânticos de dados. Evolução do sistema Deve descrever os pressupostos fundamen- tais em que o sistema se baseia, bem como quaisquer mudanças previstas, em decorrência da evolução de hardware, de mudanças nas necessidades do usuário, etc� Essa seção é útil para projetistas de sistema, pois pode ajudá-los a evitar decisões capazes de restringir possí- veis mudanças futuras no sistema� Apêndices Deve fornecer informações detalhadas e específicas relacionadas à aplicação em desen- volvimento, além de descrições de hardware e banco de dados, por exemplo. Os requisitos de hardware definem as configurações mínimas ideais para o sistema� Requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre esses dados� Índice Vários índices podem ser incluídos no docu- mento. Pode haver, além de um índice alfabéti- co normal, um índice de diagramas, de funções, entre outros pertinentes�Tabela 3: Estrutura de documento de especificação de requisitos. Fonte: Sommerville (2019, p. 65) adaptado. Acompanhe, a seguir, quais são as principais estra- tégias para análise de requisitos� 21 ANÁLISE DE REQUISITOS Após a especificação de requisitos, com o documen- to em mãos, os analistas poderão estudá-lo, a fim de fazer um detalhamento e um refinamento por meio de modelos para, por fim, chegarem a uma aproxi- mação da solução final. A análise é muito importante porque permite que se compreenda melhor os re- quisitos para auxliar no posterior projeto do siste- ma. Podemos dizer que a fase de análise faz uma tradução das especificações dos requisitos que se encontram na linguagem do cliente para uma repre- sentação que use a linguagem do desenvolvedor. Os modelos de casos de uso são exemplo de represen- tação de funcionalidades para os desenvolvedores (BEZERRA, 2007). FIQUE ATENTO Você sabe qual é a diferença entre a fase de aná- lise e de projeto? A fase de análise busca respon- der as seguintes perguntas, do ponto de vista da equipe de desenvolvimento: O quê? O que o siste- ma deve fazer? O que o sistema deve ser? O que o sistema realiza? Já a fase de projeto buscará responder as seguintes perguntas: Como? Como o sistema fará? Como o sistema será? Como o sis- tema realiza? 22 A arquitetura de sistema caracteriza a organização e a disposição em camadas de classes, componen- tes, e demais elementos do sistema� A arquitetura de sistemas pode ter o padrão Modelo de Visão e Controle que prevê a separação dos sistemas em três camadas: ● Visão: Nesta camada é mantido o código relacio- nado à visualização gráfica dos elementos; ● Controle: Esta camada mapeia as ações requisi- tadas pela visão ao Modelo e vice-versa; ● Modelo: Esta camada é responsável por acessar o banco de dados (ou outras formas de persistência) e pela lógica de negócio (BEZERRA, 2007). ● Existem propostas para identificar as diferentes entidades do sistema. Dentre elas temos: ○ A análise gramatical do documento de requisitos, que consiste em definir que as classes e os atributos são representados por substantivos nos documentos de requisitos e os verbos representam as operações (Métodos). Por exemplo: O usuário pode salvar e editar disciplinas para cursar. Nesse exemplo, o subs- tantivo disciplinas representa uma classe e salvar e editar representam operações a ser implantadas. ○ As entidades de domínio devem ser levadas em consideração quando têm significado para sistemas, como tipos de veículos em um sistema de transporte rodoviário� ○ A análise baseada em cenários faz com que cada um deles seja identificado e analisados um por vez. 23 Por exemplo, em uma entidade disciplina analisamos suas atribuições, que podem ser: conhecer seus pré- -requisitos; seu nome; a quantiade de créditos e seu código (BEZERRA, 2007, GONÇALVES, 2015). Na fase de projeto é possível fazer um refinamento dos elementos criados durante a análise, especifican- do de maneira pormenorizada os modelos gerados e concluindo o projeto de arquitetura iniciado na fase anterior� Podem ser criados outros diagramas para complementar e prosseguir com o desenvolvimento� Existem algumas definições das atividades específi- cas da fase de projeto. Dessa forma, temos: ● Refinamento dos Aspectos Estáticos e Estruturais que consiste no detalhamento do modelo de classes de análise, definindo-se atributos e métodos, além dos relacionamentos entre as classes como herança, por exemplo. ● Projeto de algoritmos é a especificação de quais algoritmos serão usados para determinados elemen- tos dos diagramas� ● Detalhamento dos Aspectos Dinâmicos está re- lacionado à forma como a aplicação deve se com- portar, ou seja, preocupa-se em expressar o fluxo de execução de uma determinada funcionalidade, de um caso de uso ou do sistema inteiro� ● Inclusão de Padrões de Projeto descreve uma situ- ação problema recorrente no desenvolvimento, junta- mente com a solução genérica adequada, exemplos de uso e outros padrões relacionados. 24 ● Inclusão de Frameworks trata-se de um conjunto de classes concretas, classes abstratas e interfaces para facilitar o desenvolvimento de um determina- do foco específico dentro do projeto. Existem fra- meworks de interações de usuários e de persistência de dados que mapeiam as relações dos atributos de objetos e os campos de banco de dados� ● Persistência dos dados consiste em garantir que os dados persistentes sejam armazenados com con- sistência e eficiência. ● Projeto de interface gráfica é quando existe a pre- ocupação de que a interface seja projetada para ter uma identidade visual com os usuários� Deve ter por objetivo utilizar termos e conceitos que as pessoas que mais utilizarão o sistema conheçam além da manutenção de operações semelhantes. Preocupa-se também com a padronização de cores, de mensagens de erro, logotipo que deve aparecer, posicionamento dos campos, etc� (BEZERRA, 2007; GONÇALVES, 2015). Podcast 2 Acompanhe, a seguir, quais são os principais tipos de verificação de requisitos. 25 https://famonline.instructure.com/files/707595/download?download_frd=1 VALIDAÇÃO DE REQUISITOS Você sabe o que é validação de requisitos? É o pro- cesso pelo qual se verifica se os requisitos que fo- ram definidos são o que o cliente realmente quer. A validação é muito importante, pois pode se consta- tar erros antes de finalizar o projeto. No decorrer do processo de validação, existem diferentes tipos de verificações que necessitam ser realizadas com os requisitos no documento de requisitos� Dentre as verificações, temos: 1. Verificações de validade: por meio de uma aná- lise mais aprofundada é possível identificar fun- ções necessárias, adicionais ou diferentes. Os sis- temas têm diversos stakeholders com diferentes necessidades� 2. Verificações de consistência: os requisitos no do- cumento não devem entrar em conflito, ou seja, não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema� 3. Verificações de completude: o documento de requisitos deve incluir requisitos que definam todas as funções e as restrições pretendidas pelo usuário do sistema� 4. Verificações de realismo: os requisitos devem ser verificados mediante uso de tecnologias para assegurar que realmente podem ser implementados, considerando o orçamento e o cronograma para o desenvolvimento do sistema� 26 5. Verificabilidade: para reduzir o potencial de conflito entre o cliente e o contratante os requisi- tos do sistema devem ser passíveis de verificação (SOMMERVILLE, 2019, p. 77). Destacamos técnicas de validação de requisitos que podem ser usadas individualmente ou em conjunto: 6. Revisões de requisitos, ou seja, analisá-los siste- maticamente por meio de uma equipe de revisores que verifica erros e inconsistências. 7. Prototipação é uma abordadem que possibilita a demonstração para usuários finais e clientes de um modelo executável do sistema. Dessa forma, estes podem verificar se o sistema atende suas necessidades� 8. Geração de casos de teste, ou seja, os requisitos devem ser testáveis� Se os testes forem concebidos como parte do processo de validação, isso frequen- temente revela problemas de requisitos� Se é difícil ou impossível projetar um teste, isso normalmente significa que os requisitos são difíceis de serem implementados e devem ser reconsiderados� Vamos estudar, agora, algumas das principais ferra- mentas de modelagem� 27 FERRAMENTAS DE MODELAGEM Existem ferramentas que auxiliam a criação de códi- gos e possibilitam o aumento da produtividade dos desenvolvedores� Normalmente são ferramentas desenvolvidas para detectar erros nas linhas de co- mando realizadas pelos programadores. Conforme estudado anteriormente, são chamadas de ferra- mentas CASE, ou seja, ajudam nas atividades de en- genharia de software, desde a análise de requisitos, modelagem, programação e testes� No caso específicodas ferramentas de modelagem, também auxiliam os desenvolvedores, pois propiciam a boa formação dos modelos gerados, reduzindo erros e aumentando a produtividade na execução das atividades de análise e projeto� SAIBA MAIS Para saber mais sobre ferramentas CASE, leia a PARTE III (páginas 235-236), do livro “Utilizando UML e padrões”, de Craig Larman, que traz o con- ceito de ferramentas CASE e exemplos em que são usados UML. O livro está disponível em sua biblioteca virtual (Minha Biblioteca). Podemos citar algumas ferramentas que têm por base a modelagem de UML: 28 ● Astah – desenvolvida por uma empresa japonesa. Possui uma versão gratuita e uma versão trial apenas para teste� É bastante usada na comunidade acadê- mica e industrial� Possui tutoriais com boa facilidade de entendimento. Está disponível em: http://astah.net. ● ArgoUML – é uma aplicação open source, ou seja, de código aberto� Possui recursos cognitivos para construção de modelos. Está disponível em: http:// argouml.tigris.org. ● Umbrello – auxilia no processo de modelagem e pode gerar códigos a partir dos diagramas� Pode ser trabalhada com linguagens como C++, Java, PHP5, dentre outras. Está disponível em: http://uml.sour- ceforge.net� 29 http://astah.net. http://argouml.tigris.org. http://argouml.tigris.org. http://uml.sourceforge.net http://uml.sourceforge.net CONSIDERAÇÕES FINAIS Por meio dos estudos explorados neste módulo, você aprendeu que a elicitação (ou levantamento de requisitos) é uma fase muito importante na ela- boração de softwares e de sistemas� Percebeu que ela envolve muito diálogo entre desenvolvedores, clientes e usuários finais para que, assim, o produto possa ter sucesso� Você descobriu quem são os principais atores en- volvidos no desenvolvimento de um sistema: proje- tistas, gerentes, dentre outros; além de conhecer as principais técnicas de elicitação de requisitos, como entrevistas, observações, etc. Com a leitura deste material, você estudou os requisi- tos e identificou seus principais tipos, assim como os tipos de escritas da especificação de requisitos, na fase de escrita de documentação. Verificou, também, que, por meio da análise de projetos, é necessário identificar as fases que ajudam a ter detalhes porme- norizados do projeto, como elaboração de algoritmos, projeto de interface gráfica, dentre outros; com isso, você conheceu as principais verificações e técnicas de validação de requisitos, bem como alguns exem- plos de ferramentas de modelagem� Espero que tenha aproveitado o conteúdo! 30 SÍNTESE ESPECIFICAÇÃO, DOCUMENTAÇÃO, VISUALIZAÇÃO E CONSTRUÇÃO DE PROJETOS DE SISTEMAS DE SOFTWARES COM UML 1) Requisitos é a nomeção dada ao conjunto de documentos de descrições dos serviços que serão oferecidos pelo sistema e restrições operacionais de modo que satisfaça as necessidades/desejos do cliente� 3) Principais atores no desenvolvimento de sistemas: gerentes de projetos, analistas, projetistas, arquitetos de softwares, progradores, especialistas de domínio e negócios� 5) A Especificação de requisistos de sistemas orientados a objetos é a documentação escrita de requisitos, evitando-se o uso de jargões e siglas computacionais� 2) A Elicitação de um requisito ou levantamento de requisitos é quando a equipe de desenvolvimento relaciona-se com os clientes e usuários para ouvir e levantar quais são as suas necessidades� 4) Técnicas para elicitação de requisitos: entrevistas, observação do ambiente, etnografia, estudo de documentos em papel (formulários, relatórios, etc), demonstração de tarefas específicas, aplicação de questionários, brainstorming, prototipação, dentre outras� 6) A análise de requisitos permite que se compreenda melhor os requisitos para auxliar no posterior projeto do sistema� Podemos dizer que a fase de análise faz uma tradução das especificações dos requisitos que encontram-se na linguagem do cliente para uma representação que use a linguagem de desenvolvedor� 7) Fases de refinamento dos elementos criados durante a análise: especificação de algoritmos, fluxo de execução de funcionalidades, padrões de projetos e projeto de interfáce gráfica� 8) Validação de requisitos é o processo pelo qual se verifica se os requisitos que foram definidos são o que o cliente realmente quer� ANÁLISE E PROJETO DE SISTEMAS Referências Bibliográficas & Consultadas BEZERRA, E� Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: EIsevier, 2007. FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de obje- tos. 3. ed. Porto Alegre: Bookman, 2005. [Minha Biblioteca] GONÇALVES, E. J. T. Análise e projeto de sistemas� 3. ed. Fortaleza: EdUECE, 2015. GUEDES, G� T� A� UML 2: uma abordagem prática. 2. ed. São Paulo: Novatec, 2011. LARMAN, C. Utilizando UML e padrões� 3� ed� Porto Alegre: Bookman, 2004. [Minha Biblioteca] MARINHO, A. L. Análise e modelagem de sis- temas. São Paulo: Pearson Education do Brasil, 2016. [Biblioteca Virtual] MEDEIROS, E. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson Makron Books, 2004. [Biblioteca Virtual] PAGE-JONES, M. Fundamentos do desenho orien- tado a objeto com UML. 1. ed. São Paulo: Makron Books, 2001. [Biblioteca Virtual] PAULA FILHO, W. P. Engenharia de software: funda- mentos, métodos e padrões. 3. ed. Rio de Janeiro: LTC, 2009. Disponível em: [Minha Biblioteca] PRESSMAN, R� S�; MAXIM, B� R� Engenharia de sof- tware: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. [Minha Biblioteca] SOMMERVILLE, I. Engenharia de software� 10� ed� São Paulo: Pearson Brasil, 2019. [Biblioteca Virtual] Introdução Elicitação de requisistos de sistemas orientados a objetos Elicitação de um requisito Técnicas para elicitação de requisitos Dificuldades para elicitação de requisitos Especificação de requisistos de sistemas orientados a objetos Requisitos A especificação de requisitos As especificações estruturadas Estrutura de documentos de especificação de requisitos Análise de requisitos Validação de Requisitos Ferramentas de modelagem Considerações finais Síntese
Compartilhar