"DICA" sobre especificações de casos de uso

Mediante algumas circunstâncias, quando estamos pensando em software é melhor pensarmos na melhor maneira de comunicar nossas idéias. Clareza e objetividade são fatores fundamentais para que não haja mal entendidos quando o assunto seja requisitos de software. As necessidades do usuário e as funcionalidades do software são os elementos fundamentais, esses 'que tais' que denominamos requisitos de software devem ser comunicados com precisão absoluta para a equipe de desenvolvimento. Uma especificação de caso de uso é um artefato que deve apresentar com clareza, do ponto de vista do negócio, todas as regras ressaltadas pelo usuário, além de indicar com precisão a navegabilidade que se deseja atribuir ao produto software. Para isso, a especificação, deve evitar termos que não denotem precisão e, sobretudo, evitar repetições desnecessárias - redundâncias. O bom software é aquele que tem, claramente, determinadas as responsabilidades de cada um dos seus casos de uso. Essa determinação será definida no momento em que o Analista de Requisitos define as relações entre seus casos de uso. Nesse momento, o profissional assume, realmente, o seu papel e não deixa a responsabilidade para outros, nesse caso, a equipe de desenvolvimento.

A relações entre casos de uso são definidas em três formas básicas, quais sejam:

1. Generalização - esse tipo de relacionamento deve ser utilizado com cuidado, pois que, representa relacionamentos de polimorfismo que se não forem bem definidos poderão levar a conclusões equivocadas e confusas. O princípio fundamental da generalização consiste em concluir que uma 'idéia' mais particular está contida em uma 'ideía' mais geral. Desta feita, podemos exemplificar usando a seguinte analogia: Esse tipo de conclusão se aplicada no sentido inverso poderá levá-lo a concluir que todos animais são felinos, o que é uma inverdade.
2. Inclusão (include) - esse tipo de de relacionamento faz com que um caso de uso encapsule funcionalidades que são complementares a ação de outros casos de uso. Por exemplo, para efetuar uma transação de inclusão ou exclusão, usualmente será necessário, primeiramente, executar-se uma pesquisa a fim de verificar a existência do registro que será alvo da ação. Desta feita, para que não repitamos ações, isolaremos a pesquisa em um caso de uso e faremos com que os casos de uso de inclusão e exclusão o acione como include. A particularidade, com relação ao include está relacionada a obrigatoriedade de execução, ou seja, todas as vezes que os casos de uso de inclusão ou exclusão de registros forem acionados, obrigatoriamente, o include também será executado.
3. Extensão (extends) - o relacionamento de extensão muito se assemelha ao de inclusão. Esse relacionamento também visa complementar alguma ação isolada de um caso de uso. Porém a diferença fundamental consiste em que a sua execução será opcional.

Os casos de uso que tem como alvo o mesmo objeto, normalmente são agrupados em um caso de uso que usualmente denominados 'Manter'. Esse tipo de caso de uso que é também conhecido pela sigla na lingua inglêsa 'CRUD', que representa: C - Create; R - Retrieve; U - Update e D - Delete, tem esse agrupamento justificado porquê para as transações de criação, atualização e exclusão dever-se-á ser executada a transação de recuperação ou pesquisa da informação. Na verdade propomos que esse tipo de caso de uso em português seja denominado por 'DICA' - Deleção, Inclusão, Consulta e Atualização. Tenho dito!

Desvendando os Casos de Uso

Casos de Uso dizem respeito a funcionalidades que estão agrupadas em cenários comuns. Essas funcionalidades, certamente, devem ter afinidades entre sí, além de convergirem para um objetivo comum. Um Caso de Uso deve ser 'enxuto', ou seja, deve fornercer aos operadores funcionalidades que estão estritamente relacionadas com os objetivos a que se propõe.

O diagrama de caso de uso é a representação em UML (Unified Modeling Language) - Linguagem de Modelagem Unificada - desses cenários afins, cuja representação sustenta-se em três elementos fundamentais.

1. O caso de uso no estrito senso do termo, ou seja, o nome comum desse agrupamento de funcionalidades - cenários comuns;
2. Os atores - operadores do caso de uso, esses podem ser pessoas, outros sistemas (robôs etc.), outros casos de uso;
3. Indicador de interelacionamento - que índica a relação entre os atores e as funcionalidades do caso de uso.

Usamos denominar casos de uso segundo a seguinte forma: UC - mneumônico de Use Case - expressão que significa caso de uso na lingua inglesa e XX - numero seqüencial que indentifica o caso de uso, p ex.: UC01.

Freqüentemente, encontramos casos de uso cujos objetivos sejam 'Criar', 'Consultar', 'Editar' e 'Excluir' agrupados num único caso de uso, denominado 'Manter'. A esse agrupamento denominamos 'CRUD' - sigla a construída a partir das palavras da lingua inglesa: Create - Criar, Retrieve - Consultar, Update - Atualizar e Delete - Excluir. Esse agrupamento favorece a visão do contexto do sistema, necessitando que seja detalhado em nota explicativa específica. Abaixo vemos a representação de um diagrama de caso de uso.

De quê necessita o seu usuário

Quais são as necessidades dos stakeholders do software para o qual você está elicitando requisitos?

Muitas vezes, nem eles sabem!... E aí começam os problemas. Algumas vezes, as pessoas desejam realizar projetos e não têm a mínima idéia do quê e para o quê. E aí você, analista de requisitos, é convocado para levantar necessidades (NE) de não sei o quê, para não sei quem.

Como sobreviver nesse contexto?

Existe receita de bolo para esse problema?

Tenho que responder com um sonoro nãaaaaaao! Em algumas circustâncias você terá de se esforçar muito para sobreviver na função, na empresa etc.

Meu amigo, quando seu chefe mandar você elicitar requisitos com stakeholders que não sabem as necessidades dele em relação ao software, saiba que não haverá projeto. Pois que, tudo em software se resume numa palavra fundamental: Necessidade.

A pedra fundamental de um software se resume nisso, que chamamos necessidades dos usuários do software.

Em tempo: o termo Stakeholder diz respeito a todos envolvidos no projeto de software, desde de patrocinadores, usuários diretos, usuários indiretos, fornecedores, equipes de infra-estrutura, enfim todos aqueles que tem algum relacionamento direto ou indireto com o projeto.

O Que Seria Rastreabilidade 2ª parte

A relação entre os diferentes produtos e etapas da construção de um software, que aqui usamos denominar rastreabilidade, pode ser comparada a uma árvore em desenvolvimento. E no princípio era o verbo, ou seja, as Necessidades que os usuários expuseram à equipe de levantamento de requisitos, através de formulários, reuniões, workshopings, brainstorm etc. A partir dessas Necessidades, raízes fundamentais para a sustentação de nossa criação e que, estarão registradas em atas, derivarão os outros apêndices, quais sejam: Funcionalidades, Requisitos Funcionais, Requisitos não Funcionais, Regras de Negócios, enfim...

Essa interligação de fatores concluir-se-á com a construção do código - é claro que uma certa seqüência de código estará presente para resolver, em termos de Funcionalidade, uma certa Necessidade.

Finalmente, ao se objetar uma manutenção, seja evolutiva ou corretiva, todas as informações estarão interligadas facilitando a interpolação entre a documentação e o código do software.

A essência da reastreabilidade é percebida quando lidamos com o reuso de código, pois ficará claro onde ocorrerão impactos - efeitos colaterais - caso haja alteração em alguma parte desse código.