Resumo: Requisitos Orientados a Objetos para Projeto Orientado a Objetos:
Uma Transição Fácil?
Object-Oriented Requirements to Object-Oriented Design: An Easy
Transition?
Alan M. Davis, UCCS, Colorado
Grupo 5
Christian Reis
Pedro M. S. Eleutério
Ramon Chiara
Ricardo J. M. Ribeiro
Wagner S. Bila
Resumo:
Este artigo [1] defende que a dificuldade inerente à passagem de
Requisitos levantados para um projeto de software é um problema natural a
qualquer processo de engenharia, e que o uso de uma Análise de Requisitos
Orientados a Objetos não trivializa o problema. O artigo ainda faz algumas
sugestões de como proceder para realizar esta transição.
Desde que a Orientação a Objetos (OO) foi proposta como um método para
programação, proponentes têm aplicado suas idéias a outras áreas da
Computação. O Projeto Orientado a Objetos incorporou os conceitos básicos da
OO ao tema Projeto de Software, e desta junção nasceram diversas técnicas de
Projeto Orientado a Objetos [2].
O passo seguinte tem sido adotar a filosofia OO e aplicá-la à Engenharia de
Requisitos. A Engenharia de Requisitos incorpora duas atividades principais:
Analise do Problema e Especificação de Requisitos. O uso de OO aplicada à
Engenharia de Requisitos ajuda o analista a entender melhor o escopo e domínio
do problema. No entanto, técnicas de engenharia de requisitos OO não
descrevem bem as características externas e o comportamento do sistema, e
por não apoiarem a especificação de requisitos em si, podem ser melhor
descritas como uma técnica para Análise do Problema.
O Projeto Orientado a Objetos tem como objetivo estimular reuso, manutenção
e estabilidade, objetivos que não são replicados por nenhuma etapa da
analise de requisitos. Durante a análise, os objetos são escolhidos de forma
a representar entidades do mundo real, de forma a otimizar a compreensão
do problema. Não existem necessariamente correspondentes diretos a estes
objetos durante a fase de projeto, principalmente porque os objetivos são
diferentes.
A maior parte dos proponentes à Orientação a Objetos levam a entender que a
passagem de Requisitos OO para o Projeto OO é simples e direta. Coad e
Yourdon [3], por exemplo, argumentam que a passagem da Análise
para o Projeto envolve principalmente expandir o modelo e seguir adicionando
componentes. Para Cox [4], requisitos existem somente para
congelar o progresso e inibir os projetistas.
O artigo defende a necessidade de uma Especificação de requisitos composta
após a Análise de requisitos. Enfatiza, além disso, o fato do documento de
requisitos já ser complexo o suficiente para ser assimilado ao projeto, onde
são contemplados problemas de eficiência, portabilidade e reusabilidade. A
opinião exposta no artigo é de que os requisitos constituem o (importante)
ponto de partida para o projeto, e que não têm (ou não deveriam ter) como
propósito limitar as opções dos projetistas.
A transição da Análise do Problema para e Especificação de Requisitos é
difícil, e não há uma solução direta para este problema. Da mesma forma,
passar de uma Especificação de Requisitos para o projeto do sistema é uma
atividade trabalhosa, que envolve escolher uma arquitetura ótima para
atender às necessidades apresentadas. As diferenças principais são:
- Objetos Diferentes
Os critérios para seleção dos objetos são diferentes durante a Análise e o
Projeto, principalmente porque os objetivos das etapas são também
diferentes: na Análise, objetos são escolhidos por serem importantes dentro
do domínio do problema. No projeto, são escolhidos por utilizarem
efetivamente as abstrações de dados da OO.
- O Objeto Sistema
Embora não exista objeto Sistema em nenhuma das fases, os motivos são
diferentes: durante a Análise, o problema em si não contempla sistema; no
Projeto, o que está sendo projeto efetivamente é o sistema.
- Agregação
O objetivo de relacionar objetos diferentes na fase de Análise é entender
melhor estes objetos. Durante a fase de Projeto, o objetivo é encapsular
para otimizar segurança, proteção da informação, integridade, etc.
- Instanciação
Quando especificamos objetos durante a Análise, assumimos muitas vezes que
há muitas instâncias destes. Durante o Projeto, a criação e destruição de
instâncias de objetos são sujeitas a condições muito importantes que devem
ser detalhadas explícitamente.
- Ênfase diferente em Técnicas e Serviços
Durante a Análise, é aceitável não especificar um algoritmo ou comportamento
dos serviços prestados prestados por objetos. Durante o Projeto, no entanto,
todo serviço associado a um objeto deve ser detalhadamente especificado.
- Genericidade dos Serviços e Nomes
O Overloading de operações e serviços é comum durante a Análise e
durante o Projeto. No entanto, é mais importante durante o Projeto, e é
feito com outro objetivo: maximizar a produtividade e o encapsulamento dos
dados.
- Verificação e Validação
Verificar e validar uma Análise envolve garantir que o modelo descreve bem o
ambiente do problema. Durante o Projeto, verificamos com o objetivo de
garantir que o sistema especificado satisfaça o problema e funcione para os
seus usuários.
O fato de grandes nomes da OO enfatizarem a facilidade de transferir
requisitos para projeto é um sintoma maior da indústria da Computação: que
existem panacéias para resolverem os problemas que enfrentamos. A passagem
da utilização de técnicas específicas à programação para as fases de Projeto
e Análise já ocorreu algumas vezes (Análise Estruturada, Jackson, OO), e no
caso de Requisitos OO, existem ainda menos argumentos práticos que comprovem o
método.
O objetivo do artigo é explicar porque a transição de Requisitos para
Projeto é difícil. Alguns conselhos para fazer esta transição menos difícil
seguem.
- Reconheça que a especificação de requisitos é difícil.
Requisitos OO enfocam Análise do Problema, e não a Especificação de
Requisitos. Não ignore a necessidade de elaborar uma Especificação antes de
passar para o Projeto.
- Não espere que criar a Especificação vá ser fácil.
Uma Especificação enfoca explicitar o problema a ser resolvido, e documentar o
comportamento externo do sistema. O Projeto é otimizado para as necessidades
detalhadas na própria especificação. Esta mudança de enfoque torna a
passagem realmente complexa.
- Use um processo de desenvolvimento apropriado.
A Análise OO é uma das técnicas que podemos utilizar para compreender o
domínio do problema. Outras técnicas incluem a Análise Estruturada e a
Prototipação. Compreender o domínio do problema, especificar o comportamento
externo do sistema, e projetar o sistema são fases importantes a serem
realizadas antes da elaboração da Especificação de Requisitos. Só então
podemos passar para projetar o software que será implementado; Projeto OO é
um candidato para esta fase, mas não necessariamente o único.
- Use alguns objetos levantados na Análise como um início.
Alguns objetos descritos na Análise OO podem ser bons candidatos a objetos
para o Projeto. Examine os objetos e decida quais auxiliariam a
funcionalidade, qualidade e manutenibilidade do sistema. Esta tarefa não é
fácil, e muitos objetos não serão reaproveitados.
- Adicione outros objetos da Especificação de Requisitos.
Como a Especificação captura as interfaces externas do sistema, podemos
determinar o ambiente no qual o sistema reside, e o conteúdo da informação
recebida e gerada pelo sistema. Da especificação, portanto, o projetista
pode escolher outros candidatos a objetos, mas este levantamento deve ser
feito lendo e derivando cuidadosamente.
- Projete
Criar uma arquitetura ótima para o sistema necessário não é fácil, e existem
muitas abstrações de dados que não correspondem a entidades do mundo real
e que ainda assim que são importantes para o Projeto e que devem ser
incluídas como objetos. Bons exemplos acadêmicos de abstrações
e objetos reutilizáveis que devem ser incluídos no projeto são filas,
pilhas, etc.
O artigo apresenta uma posição impopular de que a transição de Requisitos OO
para o Projeto OO é não-trivial, e que há bons motivos para não o ser.
Tentativas de trivializar o assunto são contra-produtivas: a análise de um
problema complexo é difícil, da mesma forma que é difícil especificar o
comportamento externo de um sistema, e escolher a arquitetura para este
sistema.
Um processo razoável para desenvolvimento envolve analisar o problema,
determinar o sistema apropriado, elaborar requisitos para descrever o
comportamento externo e só então projetar uma arquitetura apropriada para
aquele sistema.
- 1
- Alan M. Davis.
"Object-Oriented Requirements to Object-Oriented Design: An Easy
Transition?", The Journal of Systems Software 30, (1995) pp.
151-159.
- 2
- Sjaak Brinkkemper et al.
Object-Oriented Analysis and Design Methods: a Comparative Review,
http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html, 1995.
- 3
- Coad, P., Yourdon, E. Object Oriented Analysis,
Englewood Cliffs, NJ: Prentice Hall, 1991.
- 4
-
Cox, B., Object Oriented Programming, Reading, Mass: Addison-Wesley,
1986.
Christian Reis
2000-08-15