Apesar do desenvolvimento de sorftware ser uma ciência exata, muitos desenvolvedores consideram algumas dessas soluções como mágicas devido a sua complexidade. Primeiramente gostaria de salientar que não existe mágica, e sim o emprego metódico de técnicas e princípios para o projeto de software que boa parte dessa “mágica” pode ser atribuído ao polimorfismo.

O que é Polimorfismo?

“Um conceito em teoria de tipo, no qual um nome (como uma declaração de variável) pode denotar objetos de muitas subclasses diferentes que são relacionadas por alguma superclasse comum, assim, qualquer objeto denotado por esse nome tem a capacidade de responder a algum conjunto comum de operações de modos diferentes” (Booch, 2000).
Em outras palavras, possibilita que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que as referenciam, esse comportamento também é conhecido como Generalização-Especialização.

Polimorfismo é uma solução para um problema comum em ciência da computação: “Variação condicional“.
Quando um programa é projetado com lógica condicional de estrutura if-else ou instrução case, quando surgir uma nova variação, ela exigirá uma modificação da lógica desses comandos, freqüentemente em vários lugares. Causando o aumento da complexidade ciclomática e manutenibilidade no sistema e diminuição do reuso de componentes.

Problema: Como tratar alternativas (variações condicionais) com base no tipo? Como criar componentes de software interconectáveis?

Solução: Quando alternativas ou comportamentos relacionados variam segundo o tipo (classe), atribua a responsabilidade pelo comportamento aos tipos para os quais o comportamento varia, usando operações polimórficas.

Exemplificando

Como caso de estudo, vou criar um simples sistema de exame virtual, onde iram existir 2 tipos de questões, numéricas e textos (descritivas).
Abaixo temos o modelo de domínio de nossa aplicação.

namespace Poliformismo
{
    public abstract class Question
    {
        public string Description { get; set; }
        public string Answer { get; set; }
        public bool Correct { get; set; }
 
        public abstract void AssessingAnswer();
    }
 
 
    public class Numeric : Question
    {
        public int CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            int number;
 
            bool isNumeric = int.TryParse(Answer, out number);
 
            if (isNumeric)
            {
                Correct = Equals(CorrectAnswer, number);
            }
        }
    }
 
 
    public class Text : Question
    {
        public string CorrectAnswer { get; set; }
 
        public override void AssessingAnswer()
        {
            Correct = Equals(CorrectAnswer.ToUpper(), Answer.ToUpper());
        }
    }
}

Vamos pensar no seguinte problema, as regras de avaliações de respostas para perguntas em texto se diferem das numéricas.
Seguindo o princípio do polimorfismo, devemos atribuir a responsabilidade de quem deve conhecer as regras aos tipos (no nosso caso a classe Text e Numeric ) utilizando operações polimórficas.
Para isso criamos a classe abstrata Question (Questão) é conceito geral, que pode representa qualquer um dos tipos de suas implementações (numérica ou texto).

using System;
using System.Collections.Generic;
 
namespace Poliformismo
{
    public class Exam
    {
        public Exam()
        {
            Questions = new List<question>();
            Questions.Add(new Numeric {Description = "Com quantos anos Nostradamos morreu?", CorrectAnswer = 47});
            Questions.Add(new Text {Description = "Qual a cor do cavalo branco de Napoleão?", CorrectAnswer = "Branco"});
        }
 
        public List</question><question> Questions { get; set; }
        public string Name { get; set; }
        public int Result { get; set; }
 
        public void ShowQuestions()
        {
            foreach (Question question in Questions)
            {
                Console.WriteLine(question.Description);
                string answer = Console.ReadLine();
 
                question.Answer = answer;
                question.AssessingAnswer();
            }
        }
 
        public void ShowResult()
        {
            Console.WriteLine();
            Console.WriteLine();
 
            Console.WriteLine("Correções da avaliação.");
 
            foreach (Question question in Questions)
            {
                Console.WriteLine("A resposta {0} esta: {1}", question.Answer, (question.Correct ? "Certa" : "Errada"));
            }
 
            Console.WriteLine();
            Console.WriteLine();
        }
    }
}
</question>

Reparem que para a classe Exam a manipulação das questões é transparente, nesse nível de abstratação, não importa se é uma questão do tipo numérica ou textual.
No método ShowQuestions quando o usuário digita a resposta, a classe Exam delega a classe Question a responsabilidade de verificar se a mesma esta correta. Assim cada tipo da operação aplica suas regras para validar a pergunta.

namespace Poliformismo
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Exam exam = new Exam {Name = "Carlos Fernando"};
            exam.ShowQuestions();
            exam.ShowResult();
        }
    }
}

Esse princípio traz diversas vantagens para a arquitetura da aplicação. Além de diminuir a complexidade ciclomática da aplicação porque não utilizamos instruções condicionais (if-else) para tratar as variações condicionais (“se for questão do tipo texto ou se for questão do tipo numérica”). Também auxilia na arquitetura, pois facilita a extensão de novas funcionalidades. Se caso em momento futuro surja a necessidade de criar questões de múltiplas escolhas, não teremos que alterar o exame (Exam), e sim implementar uma nova classe onde implemente a abstração de questão.
Nesse exemplo, tratamos alternativas com base no tipo, para soluções de componentes de software interconectáveis, será realizado em um próximo post.

Conclusão

Polimorfismo é um princípio fundamental no projeto e desenvolvimento de um sistema, diminui a complexidade ciclomática de uma aplicação e ainda permite que seja facilmente estendido para tratar novas variações.
Esse princípio deve ser muito bem compreendido por desenvolvedores, pois muitos design patterns utilizam seus conceitos para implementações de soluções.

Padrões relacionados:

• Variações protegidas
• Vários padrões de projetos GOF

Um modelo de domínio não mostra artefatos ou classes de software. Note que modelo de domínio é diferente de camada de domínio, esta segunda representa uma camada de software com regras de negócio abaixo da camada de UI (UserInterface ou Apresentação).
O modelo de domínio não é um modelo de dados. Pode existir classes no modelo que não tenham atributos.

O que é Classe Conceitual
De modo informal, é uma idéia, coisa ou objeto. Mas formalmente uma classe conceitual pode ser considerada em termos do seu símbolo, da sua intensão e da sua extensão.

• Símbolo – palavra ou imagem que representa uma classe conceitual.
• Intensão – a definição de uma classe conceitual.
• Extensão - conjunto de exemplos aos quais a classe conceitual se aplica.

Exemplo:
Em um evento de transação de Emitir Nota Fiscal, podemos denomina-la como símbolo “Emitir NF”. A intensão de Emitir NF é “registrar de uma transferência de propriedade sobre um bem ou uma atividade comercial”. E a sua extensão são todas as “Notas Fiscais Emitidas” existentes no universo.

Referências

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Bookman, 2007.

Para se aprofundar mais sobre esse assunto recomendo a leitura do livro “Writing Effective Use Case – Cockburn, Alistair”.

Dentro os diversos modelos de Caso de Uso, podemos dizer que os principais tópicos que temos que escrever são:

Fluxo principal:

• Não contém nenhuma condição ou desvio;
• Típico caminho que satisfaz os objetivos dos interessados.

Pré-condição:

• Condições que antecedem o caso de uso e devem ser informados ao leitor;
• São sempre assumidas como verdadeiras;
• Descreve um estado do sistema.

Pós-condição:

• O que deve ser verdade ao termino do caso de uso bem sucedido ou estado final do caso de uso.

Fluxo alternativo ou extensões:

• Descreve as condições e exceções que o fluxo principal podem tomar;
• Relação de 1 pra N com o fluxo principal;
• Descreve condições como algo que poder ser detectado pelo sistema ou pelo autor;
• Quando o fluxo for grande, pode ser expressado como outro caso de uso.

Diretrizes:

• Utilizar estilo essencial de redação, onde é expresso a intenção do usuário e as responsabilidades do sistema;
• Deixe de fora a interface do usuário;
• Focar nos objetivos dos atores, pois os casos de uso devem descreve-los.

Exemplo: O cliente (ator) tem a intenção de adicionar produtos ao carrinho e depois compra-los.
Caso de Uso: Adicionar ao carrinho, Comprar o produto.

• Iniciar os nomes de caso de uso sempre com um verbo;
• Operações do tipo CRUD (Create, Restore, Update, Delete), crie um único caso de uso denominado gerenciar .

Exemplo: Gerenciar usuários

• Observações: Alguns autores utilizam o verbo manter ao invés de gerenciar para operações CRUD.

É o mapeamento das propriedades que um software deve ter para atender um problema em especial.

Ele deve descrever os entendimento dos objetivos dos usuários e traduzir esses objetivos em funcionalidades do sistema.

Definições:

• Condição ou capacidade necessária para o usuário resolver um problema ou atingir um objetivo.
• Condições ou capacidade que deve ser atingida ou possuída por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade.
• Representação documentada de uma condição ou capacidade.

Objetivos dos Requisitos:

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer.
• Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.
• Definir fronteiras do sistema (ou delimitar o sistema).
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.
• Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

Tipos de Requisitos:

Funcionais: Definem a funcionalidade do software, função que o sistema deve realizar para tender os objetivos do usuário.
Definem O QUE o sistema deve fazer, sem a preocupação de COMO fazer.

Não funcionais: Definem as qualidades do software.

Classificação dos requisitos FURPS+

É um sistema para a classificação de requisitos, que auxilia o analista a identificar a qual propósito as informações obtidas (objetivos do usuário e caracteristica do software) se destinam.

Funcionalidade (Functionality):

• Representa todo o aspecto funcional do sistema.

Usabilidade (Usability):

• Tempo de treinamento para um usuário se tornar produtivo.
• Tempo de duração desejado para determinada operação no sistema.
• Ajuda on-line, documentação do usuário e material de treinamento.

Confiabilidade (Reliability):

• Disponibilidade.
• Tempo de correção – tempo permitido para indisponibilidade quando ocorre uma falha.
• Precisão.
• Número máximo de defeitos (bugs/KLOC – mil linhas de código).
• Categorias de bugs – bugs devem ser categorizados por nível de impacto.

Performace ou Desempenho (Performance):

• Tempo de resposta para uma transação.
• Troughput (ex: transações por segundos).
• Capacidade (ex: transações concorrentes).
• Operação Parcial (Situação do sistema aceitável quando estiver prejudicado de alguma forma).
• Uso de rescursos: memória, espaço em disco, comunicação, etc.

Suportabilidade (Supportability):

• Padrão de codificação.
• Convesão de nomenclatura.
• Bibliotecas de classes.
• Utilitários de manutenção.

+ (Plus):

• Outros(Design, implementação, interface, físicos).

Prorização de Requisitos:

Essencial: sistema não entra em funcionamento.

Importante: não impedem o funcionamento do sistema.

Desejável: não impedem a entrada em funcioanemto do sistema sem a sua implementação.

Como escrever os requisitos:

O PU (Processo Unificado) define alguns modelos de documentos e processos que auxiliam o analista (e todo a equipe de desenvolvimento) a identificar e escrever requsitos.

Dentre os diversos tipos de documentos a serem escritos, podemos citar:

• Documento de Visão
• Documento de Caso de Uso
• Especificação Suplementar
• Glossário

Até mais

Caso de uso é “uma seqüência de ações executadas por um sistema que gera um resultado de valor observável para um determinado agente” (RUP – Rational Unified Process).

Em outras palavras caso de uso é uma narrativa em texto, utilizada para descobrir e registrar requisitos. É uma coleção de cenários relacionados de sucesso e fracasso, que descreve um ator utilizando o sistema para atingir um objetivo.

“Note que casos de uso não são diagramas, são textos. Enfocar os diagramas de caso de uso UML, de valor secundário, em vez do importante texto do caso de uso, é um erro comum para novatos”. Craig Larman.

Casos de uso são requisitos funcionais (descrevendo funções do sistema e seu ambiente), sendo um dos principais meios para obtenção de captura de comportamentos do sistema. Ele serve como um contrato estabelecido entre o cliente e os desenvolvedores. É uma das principais fontes de informações atividades de análise, design e teste.

Por enfatizar nos objetivos e perspectivas do usuário, o Caso de Uso possibilita uma redução (ou extinção) das listas de detalhes de características usadas antigamente, e foca nas funcionalidades que aplicam estas características, tornando mais fácil sua leitura e entendimento.

Um dos pontos mais difíceis é aprender como determinar em que nível de detalhe os casos de uso devem “começar e terminar”. Onde as características terminam e os casos de uso começam, e onde os casos de uso terminam e o design começa? Os casos de uso ou os requisitos do software devem estabelecer “o que” o sistema executa, mas não “como” ele executa.

Definições

Ator: é qualquer coisa que apresente algum comportamento, pode ser por exemplo uma pessoa, um caixa, um computador, outro sistema.

Tipos de ator:

• Principal: satisfaz os objetivos do usuário por meio de serviços no sistema.
• Suporte: fornece um serviço para o sistema.
• Bastidor: tem interesse no caso de uso, mas não como um ator principal ou bastidor. Por exemplo, um orgão governamental responsável por impostos.

Cenários: é uma sequência específica de ações e interações entre atores e o sistema.

Segue um link para o blog de Antonio Passos, onde ele em alguns posts aborda conceitos de casos de usos e suas realizações sendo um ótimo complemento para o assunto abordado.

Referências

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Bookman, 2007.

RUP 2002.05.00 (Portugues)

Até o próximo