Diferentes aplicações, diferentes visões dos dados

Este documento fornece orientação complementar quando diferentes aplicações têm diferentes visões dos requisitos de dados do software; cenários tipicamente relacionados a este tópico usam Web Services, Stored Procedures ou Views de banco de dados relacionais. Mas a situação não se limita a esses casos e responde perguntas como “Quando e como se mede um Arquivo de Interface Externa” na Análise de Pontos de Função.

Obter o artigo revisado pelo IFPUG

Quando as especificações de requisitos funcionais não estiverem disponíveis ou elas não cumprirem o seu propósito de capturar como o usuário enxerga o fluxo de informações por meio da aplicação, este documento ajudará a extrapolar os requisitos funcionais a partir de seu projeto.

Ele também provê clarificação ao Manual de Práticas de Contagem (CPM). O CPM é absolutamente claro quanto a diferentes aplicações com diferentes visões dos requisitos de armazenamento terem diferentes análises quando se determina a complexidade das funções de dados; cada uma pode ter uma quantidade diferente de tipos de dado (TD) e a informação contada como um TD para um ALI/AIE de uma aplicação pode ser contado como mais de um TD em outra aplicação.

Contudo, quando o CPM estabelece que um AIE deve ser contabilizado como um ALI em outra aplicação, ele não clarifica se ele deve ser um e apenas um ALI. Este documento assume a premissa de que o princípio para a regra é evitar a identificação de um arquivo de transações disparando uma ou mais EE ser contado como um AIE.

Problema

Há requisitos funcionais da Aplicação A (indicados por EE e SE na figura) que incluem na descrição de seus passos, um em particular que obtém um conjunto de dados D a partir de arquivos lógicos de outra aplicação B.  Na visão do usuário da aplicação A, trata-se de um grupo de dados único e coeso, logicamente relacionados na visão de seus usuários.

Na outra aplicação B, esses dados D estão espalhados em diferentes arquivos lógicos. O critério para segregação desses dados D em diferentes grupos lógicos de dados – conjuntamente com outros dados de interesse específico da aplicação B – é a visão do usuário da aplicação B. Adicionalmente, alguns campos de D são derivados no âmbito desta outra aplicação B como lustrado nos requisitos funcionais indicados por SE na figura.

Exemplo

O Sistema de Cadastro (GECAD) requer informações sobre os Contratos assumidos pelos indivíduos e organizações que compõe um Grupo Econômico para concluir o processo de Emitir Ficha Cadastral daquele grupo econômico.

O Saldo Devedor é funcionalmente dependente das informações sobre os contratos na visão do usuário da GECAD e desse conjunto ele requer uma fração para emitir a ficha cadastral (denominado Responsabilidades Assumidas na figura.

Os usuários do GECAD não sabem e não tem responsabilidade pela definição ou especificação das regras de negócio que se aplicam no levantamento desse saldo devedor. O conhecimento e responsabilidade por isso está no âmbito do Sistema de Contratos (GEFIN).

O Sistema de Contratos tem como parte de seus requisitos uma função para preparar uma visão integrada dos Contratos a partir dos vários diferentes arquivos lógicos que mantém aqueles dados na perspectiva de seus usuários (Solicitação de Apoio, Cadastro Financeiro, Planilha de Financiamento, etc.).

Em havendo uma especificação de requisitos funcionais, ela deveria refletir essa funcionalidade. A necessidade por essa funcionalidade foi identificada pelos usuários do GEFIN, porque várias são as aplicações que necessitam diferentes subconjuntos desses dados em uma visão integrada de contrato. A figura ilustra esse cenário.

Não Exemplo

Intermediário no acesso aos dados

Uma aplicação A necessita de obter dados em outra B para fins de validação e referência; B provê esses dados por meio de um Web Service ou então por uma View de banco de dados relacional.

Não há qualquer regra de negócio associada a essa construção e o motivo pelo qual a implementação dos requisitos de A se dá desta forma em B é por uma política corporativa de TI, que restringe o acesso de qualquer aplicação aos dados de outra de maneira direta.

Não fosse essa restrição, a aplicação poderia obter diretamente os dados sem qualquer intervenção por parte de B.

Esse caso ilustra um cenário que não se enquadra no assunto tratado nesta diretriz. Nele, não há CE/SE a ser medida em B e a medição em A deve ser realizada normalmente como se os dados fossem diretamente consultados de B.

Resultado do projeto (físico ou design)

Determinado comportamento se repete em diferentes requisitos funcionais; contudo, não especificamente associado a um objetivo do usuário (externo) é projetado e implementado em um componente reutilizável cujos serviços são consumidos por outros componentes internos à aplicação.

Independentemente do software responsável por esse comportamento que se repete estar empacotado como um Web Service, uma classe, uma sub-rotina ou qualquer outro tipo de unidade na arquitetura do projeto do software, a medição deve ser realizada observando a visão presente nos requisitos funcionais do usuário, ou seja, nas tarefas e serviços presentes no fluxo operacional definido para o negócio e incluídos no escopo da aplicação.

Solução

Um AIE deve ser medido na aplicação A e uma CE/SE deveria ser medida na aplicação B. No cenário descrito, é o caso de uma SE, porque há lógica de processamento para fórmulas matemáticas e cálculos relativos ao Saldo Devedor entre as regras de negócio que se aplicam. Caso contrário, se não houvesse qualquer das quatro lógicas de processamento exigidas para diferenciar uma SE de uma CE, então uma CE deveria ser identificada.

A definição de AIE no CPM exige que os dados sejam mantidos em um ALI de outra aplicação. A regra não especifica se é um e apenas um ALI em outra aplicação. A regra existe para evitar que um processo disparado por um evento externo como, por exemplo, transações recebidas em um arquivo, promova a contagem de um AIE referente a esse arquivo de transações.  O processo em si deve ser contado como uma (ou mais) EE em resposta aos dados recebidos do usuário (outra aplicação que enviou o arquivo com transações).

No que se refere a diferentes visões a respeito de diferentes campos, o CPM já é bastante claro sobre o assunto. Ele determina que as duas diferentes aplicações deveriam contabilizar diferentes quantidades de TD de acordo com as diferentes visões dos usuários.

Cenários de Implementação

O projeto (“design de arquitetura”) ou implementação desses requisitos pode utilizar:

• Web Services;
• Visões de banco de dados;
• Stored Procedures} de banco de dados;
• Sub rotinas exportadas para utilização externa à aplicação;

Não se trata de uma lista completa, e cada tecnologia/plataforma utilizada tem especificidades que permitem atender esses mesmos requisitos.