S15 - Engenharia de Requisitos continuação cap.6

Transcrição

1 S15 - Engenharia de Requisitos continuação cap.6 ENGENHARIA DE SOFTWARE PRESSMAN, 2011 Gilberto Wolff UTFPR

2 Roteiro Análise de requisitos Modelagem baseada em cenários Modelos UML que complementam o Caso de Uso Conceitos de modelagem de dados Modelagem baseada em classes O Modelo CMMI (Capability Maturity Model Integration) Referências

3 Análise de Requisitos A Análise de Requisitos: Resulta na especificação de características operacionais do software; Indica a interface com outros elementos do sistema; e, Estabelece restrições que o software deve atender. Também permite que sejam elaboradas as necessidades básicas estabelecidas durante as tarefas de concepção, levantamento e negociação, que são parte da Eng.ª de requisitos

4 Análise de Requisitos A ação de modelagem de requisitos resulta em um ou mais dos seguintes tipos de modelos: Modelos baseados em cenários de requisitos Modelos de dados Modelos orientados a classes Cap.6 Modelos orientados a fluxos Modelos comportamentais Cap.7

5 Filosofia e objetivos gerais da Análise de Requisitos Na modelagem de requisitos o foco primário é no que e não no como Que interação com o usuário ocorre em dada circunstância? Quais objetos o sistema manipula? Que funções o sistema deve executar? Quais comportamentos o sistema apresenta? Que interfaces são definidas? e, Quais restrições se aplicam?

6 Filosofia e objetivos gerais da Análise de Requisitos O modelo de requisitos deve alcançar três objetivos primários 1. Descrever o que o cliente solicita 2. Estabelecer uma base para a criação de um projeto de software, e, 3. Definir um conjunto de requisitos que possa ser validado assim que o software for construído

7 Regras práticas que devem ser seguidas Segundo Arlow e Neustadt, 2002, apud Pressman, 2011, algumas regras práticas devem ser seguidas ao se criar o modelo de análise: O modelo deve enfocar as necessidades visíveis no domínio do problema ou do negócio Cada elemento do modelo de requisitos deve contribuir para o entendimento geral dos requisitos de software e fornecer uma visão do domínio de informação, função e comportamento do sistema Postergue considerações de infraestrutura e outros modelos não funcionais até a fase de projeto

8 Regras práticas que devem ser seguidas - continuação Minimize o acoplamento do sistema Certifique-se de que o modelo de requisitos agrega valor a todos os interessados. Cada participante tem um uso próprio para o modelo Mantenha o modelo o mais simples possível

9 Análise de domínio Para Firesmith, 1993, apud Pressman, 2011, análise de domínio de um software é a identificação, a análise e a especificação de requisitos comuns de um campo de aplicação específico, tipicamente para reutilização em vários projetos dentro deste campo de aplicação Lembrando que ocorre com frequência a recorrência de padrões de análise em muitas aplicações em um domínio de aplicação especifico O objeto da análise de domínio é encontrar ou criar classes de análise e/ou padrões de análise largamente aplicáveis de modo que possam ser reutilizados

10 Análise de domínio Entradas e Saídas da Análise de domínio

11 Abordagens à modelagem de requisitos 1ª Abordagem chamada análise estruturada, considera os dados e os processos que transformam os dados em entidades separadas Os objetos de dados são modelados de maneira que definam seus atributos e relacionamentos Processos que manipulam objetos de dados são modelados de maneira que mostrem como transformam dados à medida que os objetos de dados trafegam pelo sistema

12 Abordagens à modelagem de requisitos 2ª Abordagem denominada análise orientada a objetos, se concentra na definição de classes e na maneira pela qual elas colaboram entre si para atender às necessidades dos clientes A UML e o Processo unificado são predominantemente orientados a objetos O que é UML? O que é Processo unificado?

13 Abordagens à modelagem de requisitos elementos do modelo de análise

14 Abordagens à modelagem de requisitos elementos do modelo de análise Cada elemento do modelo de requisitos apresenta o problema segundo um ponto de vista Os elementos baseados em cenários representam como o usuário interage com o sistema e a sequência específica de atividades que ocorre à medida que o software é utilizado Os elementos baseados em classes modelam os objetos que o sistema irá manipular, as operações que serão aplicadas aos objetos para efetuar a manipulação, os relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas

15 Abordagens à modelagem de requisitos elementos do modelo de análise Os elementos comportamentais representam como os eventos externos mudam o estado do sistema ou as classes que nele residem Os elementos orientados a fluxos representam o sistema como uma transformação de informações, indicando como os objetos de dados são transformados à medida que fluem pelas várias funções do sistema

16 Quais são os possíveis diagramas e suas características da linguagem UML? Modelagem de requisitos baseada em cenários Embora o sucesso de um sistema ou produto baseado em computadores seja medido de muitas formas, a satisfação do usuário encontra-se no topo da lista segundo Pressman, 2011 Logo, se houver entendimento de como os usuários finais e outros atores querem interagir com um sistema ou produto, a equipe de software estará mais capacitada a caracterizar, de maneira apropriada, os requisitos e, a construir modelos de análise e projetos proveitosos Portanto, a modelagem de requisitos com UML inicia com a criação de cenários na forma de Casos de Uso, Diagramas de Atividades e, Diagramas de Raias O que são diagramas de atividades? O que são diagramas de raias?

17 Modelagem de requisitos baseada em cenários Sabe-se que um caso de uso descreve um cenário de uso específico, em uma linguagem simples, sob o ponto de vista de um ator definido, no entanto, Como saber: Sobre o que escrever? Quanto escrever a respeito? Com que nível de detalhamento fazer uma descrição? e, Como organizar a descrição? Essas questões devem ser respondidas quando casos de uso devem fornecer valor como uma ferramenta da modelagem de requisitos

18 Modelagem de requisitos baseada em cenários Pesquisem sobre Refinamento de um Caso de uso preliminar Criação de um Caso de uso formal

19 Modelos UML que complementam o Caso de Uso 1º Diagrama de atividade Um diagrama de atividade UML complementa o Caso de Uso por meio de uma representação gráfica do fluxo de interação em um cenário específico Similar ao fluxograma, usa retângulos com cantos arredondados para representar determinada função do sistema, setas para representar o fluxo de interação através do sistema, losangos de decisão para representar uma decisão com ramificação (cada seta saindo do losango é identificada) e as linhas horizontais cheias que indicam as atividades paralelas que estão ocorrendo

20 Modelos UML que complementam o Caso de Uso Ex. Diagrama de atividade

21 Modelos UML que complementam o Caso de Uso 2º Diagrama de raias É uma variação do Diagrama de Atividades Permite representar o fluxo de atividades descrito pelo Caso de Uso e, ao mesmo tempo, indicar qual ator ou classe de análise tem responsabilidade pela ação descrita por um retângulo de atividade As responsabilidades são representadas como segmentos paralelos que dividem o diagrama verticalmente, como raias de uma piscina

22 Modelos UML que complementam o Caso de Uso Ex. Diagrama de raias

23 Conceitos de Modelagem de Dados Se entre os requisitos de software houver a necessidade de criar, estender ou interfacear com um banco de dados ou se as estruturas de dados complexas tiverem de ser construídas e manipuladas, a equipe de software poderá optar por criar um Modelo de Dados como parte da modelagem de requisitos Um analista ou engenheiro de software define todos os objetos de dados processados no sistema, os relacionamentos entre os objetos de dados e outras informações pertinentes aos relacionamentos O Diagrama entidade-relacionamento (entity-relationship diagram) trata das questões e, representa todos os objetos de dados introduzidos, armazenados, transformados e, produzidos em uma aplicação

24 Conceitos de Modelagem de Dados objeto de dados É uma representação das informações compostas que devem ser compreendidas pelo software Informação composta é algo que tenha uma série de propriedades ou atributos diferentes Exemplo: Largura (único valor) não é um objeto de dados válido, mas, altura, largura e profundidade pode ser conceituado como um Largura= 1,0 m (não é objeto de dados o.d.); mas, Largura= 1,0m; Profundidade = 1,5m; e, Altura = 2,0m (é o.d.)

25 Conceitos de Modelagem de Dados atributos de dados Eles definem as propriedades de um objeto de dados e assumem uma das três características Eles podem ser usados para: 1º - Dar um nome a uma instância em outra tabela 2º - Descrever a instância, ou 3º - Fazer referência a uma outra instância em outra tabela Além disso, um ou mais dos atributos devem ser definidos como identificador Se torna uma chave quando se quer encontrar uma instância do objeto de dados

26 Conceitos de Modelagem de Dados atributos de dados Ex.

27 Conceitos de Modelagem de Dados relacionamentos Os objetos de dados são interligados de várias formas Considere os dois objetos de dados, pessoa e carro no exemplo a seguir

28 Conceitos de Modelagem de Dados relacionamentos Em (a) da figura anterior tem-se uma representação simplificada entre objetos de dados Por sua vez em (b), os relacionamentos possui e tem seguro para dirigir, definem as conexões relevantes entre pessoa e carro As setas indicadas em (b) informam a direção do relacionamento e, normalmente, reduzem a ambiguidade ou interpretações incorretas Pesquisem mais detalhes sobre o Diagrama entidade - relacionamento

29 Modelagem baseada em classes A modelagem baseada em classes representa os objetos que o sistema irá manipular, as operações/métodos/serviços que serão aplicadas aos objetos para efetuar a manipulação, os relacionamentos entre os objetos e as colaborações que ocorrem entre as classes definidas Os elementos de um modelo baseado em classes são: classes e objetos, atributos, operações, modelos classe-responsabilidadecolaborador (CRC), diagramas de colaboração e pacotes Pesquisem as características dos elementos baseados em classes, referidos acima

30 O Modelo Capability Maturity Model Integration (CMMI) É um metamodelo de processo abrangente, qualificado em uma série de capacidades de sistema e engenharia de software, que devem estar presentes à medida que as organizações alcançam diferentes níveis de capacidade e, maturidade de processo O CMMI representa um metamodelo de processo de duas maneiras diferentes: 1ª - Como um modelo contínuo 2ª - como um modelo encenado Quais são as características do modelo CMMI? Quais são as diferenças entre o CMM e o CMMI?

31 O Modelo Capability Maturity Model Integration (CMMI) Outros...

32 Referências ENGHOLM JÚNIOR, H. Engenharia de software na prática. São Paulo : Novatec Editora, Paula Filho, W. de P. Engenharia de software: fundamentos, métodos e padrões. 3.ed. Rio de Janeiro : LTC, PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7.ed. Porto Alegre : AMGH, 2011.