conjunto de aplicac¸˜oes pode ser criado para exercitar, no m´ınimo, todos os padr˜oes da linguagem de padr˜oes, inclusive seus variantes e sub-padr˜oes.
Framework Modelo de Análise
da Aplicação Específica
Programming
language Casos de Teste para a Aplicação específica Analisar Aplicação Específica Mapear aplicação específica para as classes do Framework Linguagem de Padrões Passo 2.4.1 Passo 2.4.2 Passo 2.4.3 Implementar Aplicação Específica Aplicação Específica Tabelas de Mapeamento "Cookbook" do Framework Passo 2.4.4 Test ar a Aplicação Específica Framework Testado Requisitos de uma aplicação específicas
Figura 4.6: Validac¸˜ao do Framework
Deve-se ressaltar que o processo de validac¸˜ao utiliza o mesmo processo de instanciac¸˜ao de aplicac¸˜oes, descrito na sec¸˜ao 4.4, j´a que, para testar o framework, ele deve ser instanciado para aplicac¸˜oes concretas do dom´ınio.
Para cada aplicac¸˜ao diferente a ser testada, seus requisitos s˜ao analisados com base na lingua- gem de padr˜oes, tendo como resultado seu modelo de an´alise. A seguir, faz-se o mapeamento entre esse modelo de an´alise e as classes do framework, utilizando as tabelas de “Mapeamento de Classes” e de “Mapeamento de M´etodos” criadas no passo anterior. A pr´oxima atividade ´e imple- mentar as classes concretas da aplicac¸˜ao, utilizando a mesma linguagem de programac¸˜ao na qual o framework foi implementado. O resultado ´e o c´odigo da aplicac¸˜ao espec´ıfica, que deve ser devida- mente testado. O teste n˜ao faz parte do escopo desta tese, mas sugere-se que seja selecionada uma estrat´egia de testes que leve em conta as particularidades de frameworks como, por exemplo, o fato de que os erros encontrados podem ser do framework ou da aplicac¸˜ao espec´ıfica em si. Feita a correc¸˜ao desses erros, novos testes devem ser feitos, em diversos ciclos, at´e que a decis˜ao de liberar o framework seja tomada, seja pelo desenvolvedor do framework ou pela gerˆencia do projeto.
4.3
Exemplo – GREN: Um Framework para Gest ˜ao de
Recursos de Neg ´ocios
O framework GREN (Gest˜ao de REcursos de Neg´ocios) foi desenvolvido com base na linguagem de padr˜oes GRN (ver Sec¸˜ao 3.5), usando o processo apresentado na Sec¸˜ao 4.2. ´E um framework
4.3 Exemplo – GREN: Um Framework para Gest˜ao de Recursos de Neg´ocios 69 caixa branca, j´a que o reuso ´e feito por meio de heranc¸a (ver Sec¸˜ao 2.2.2), e permite a criac¸˜ao de aplicac¸˜oes no dom´ınio de sistemas de gest˜ao de recursos de neg´ocios.
No primeiro passo do processo de construc¸˜ao do GREN, a linguagem de padr˜oes GRN foi a principal fonte para identificac¸˜ao dos pontos vari´aveis. A Tabela 4.1 mostra alguns dos qua- renta pontos vari´aveis identificados inicialmente. Deles, trinta e seis foram encontrados por meio da GRN. Os demais foram encontrados ao refinar e fazer a referˆencia cruzada na lista de pon- tos vari´aveis. Por exemplo, o segundo ponto vari´avel foi derivado do padr˜ao 2 – QUANTIFICAR O RECURSO (ver sec¸˜ao 3.5.2), pela an´alise de seus participantes, estrutura e sub-padr˜oes. Esse ponto vari´avel permite quatro tipos diferentes de quantificac¸˜ao para o recurso, de acordo com os quatro sub-padr˜oes apresentados na estrutura do padr˜ao: RECURSO SIMPLES, RECURSO MEN- SURAVEL´ , RECURSOINSTANCIAVEL´ e RECURSO EMLOTES. ´E um ponto vari´avel do tipo PAR- TIC OPCIONAL, porque o usu´ario do framework dever´a escolher qual das classes participantes utilizar´a, de acordo com a estrat´egia de quantificac¸˜ao desejada para o sistema alvo.
Tabela 4.1: Lista parcial dos Pontos Vari´aveis do Framework GREN
Nº P.V. Nome do Padr˜ao Descric¸˜ao Tipo Fonte na GRN Nº
Padr˜ao
1 Qualificac¸˜ao do Recurso
Um recurso pode ou n˜ao ter um tipo a ele relacionado. Pode tamb´em ter m´ultiplos tipos ou tipos aninhados.
PARTIC- ESCOLHA Participantes, Va- riantes 1 2 Quantificac¸˜ao do Recurso
Um recurso pode ser ´unico, pode ter m´ultiplas instˆancias, pode ser gerenciado em quantidades ou em lotes. PARTIC- ESCOLHA Participantes, Es- trutura, Variantes (sub-padr˜oes) 2 3 Armazenagem do Recurso
Pode ser ou n˜ao desej´avel que a aplicac¸˜ao gerencie a armazenagem do recurso.
PADR ˜AO- OPCIONAL
Grafo da Lingua- gem + Contexto
3
O segundo passo foi projetar o framework GREN, comec¸ando pelo projeto de sua arquitetura, que foi definida em trˆes camadas: a camada de persistˆencia, a camada de neg´ocios e a camada de interface gr´afica com o usu´ario (GUI), conforme ilustrado na Figura 4.7. A primeira vers˜ao do GREN n˜ao inclui aspectos de seguranc¸a, controle de acesso, distribuic¸˜ao e interface Web, sendo que esses aspectos poder˜ao ser incorporados em suas futuras vers˜oes.
A camada de persistˆencia possui classes para cuidar da conex˜ao com a base de dados, ge- renciamento dos identificadores dos objetos e persistˆencia dos objetos. A camada de neg´ocios comunica-se com a camada de persistˆencia sempre que precisa armazenar permanentemente um objeto. Dentro da camada de neg´ocios existem diversas classes derivadas diretamente dos padr˜oes de an´alise que comp˜oem a linguagem de padr˜oes GRN, ou seja, as classes e relacionamentos contidos em cada padr˜ao possuem a implementac¸˜ao correspondente nesta camada. A camada de interface gr´afica com o usu´ario cont´em as classes respons´aveis pela entrada e sa´ıda de dados, como formul´arios de interface, janelas e menus, que permitem a interac¸˜ao do usu´ario final com o sistema. Comunica-se com a camada de neg´ocios para obtenc¸˜ao de objetos a serem mostrados na interface com o usu´ario e para devolver informac¸˜oes a serem processadas pelos m´etodos da camada de
4.3 Exemplo – GREN: Um Framework para Gest˜ao de Recursos de Neg´ocios 70
GREN-Wizard Aplicações específicas
GREN - Persistência
GREN - Interface Gráfica com o Usuário
GREN - Negócios
JdmMySQLDriver
MySQL Smalltalk
Hardware / Sistema Operacional Apli- cações espe- cíficas Apli- cações espe- cífi- cas Recursos Básicos GREN e GREN- Wizard
Figura 4.7: Arquitetura do GREN
neg´ocios. Existe ainda o GREN-Wizard, apresentado em detalhes na sec¸˜ao 5.5, que situa-se acima da camada de interface gr´afica com o usu´ario, pois utiliza todas as demais camadas.
Aplicac¸˜oes espec´ıficas podem ser constru´ıdas a partir da camada de interface gr´afica com o usu´ario, usando (por meio de heranc¸a ou referˆencia a objetos) classes de todas as camadas do GREN, ou podem ser constru´ıdas com base na camada de neg´ocios, caso a camada de inter- face gr´afica com o usu´ario n˜ao seja reutilizada a partir do GREN, mas implementada separada- mente. Podem tamb´em ser implementadas por meio do GREN-Wizard, que se encarrega de fazer a comunicac¸˜ao com as demais camadas do GREN.
Definida a arquitetura do GREN, foi ent˜ao projetada sua hierarquia de classes, comec¸ando pela construc¸˜ao de um modelo de classes geral, englobando as classes de todos os quinze padr˜oes da GRN, e depois fazendo uso dos mecanismos de especializac¸˜ao e generalizac¸˜ao para refinar esse modelo. A seguir foram utilizados padr˜oes de projeto, como por exemplo oStrategy (Gamma et al.,
1995), para conseguir a flexibilidade necess´aria para atender aos pontos vari´aveis do framework. A Figura 4.8 mostra parte do diagrama de classes de projeto do GREN. Nesse exemplo em particular, s˜ao mostradas as classes relacionadas `a classe Resource (Recurso). A classe Persis-
tentObject foi criada para modelar a camada de persistˆencia, conforme o padr˜aoPersistenceLayer
(Yoder et al., 1998). As classes StaticObject e QualifiableObject foram criadas durante a etapa de generalizac¸˜ao/especializac¸˜ao, visto que diversas classes podem herdar seu comportamento. O
4.3 Exemplo – GREN: Um Framework para Gest˜ao de Recursos de Neg´ocios 71 padr˜ao de projeto STRATEGY (Gamma et al., 1995) foi utilizado para modelar o segundo ponto vari´avel do GREN, conforme descrito na sec¸˜ao 4.2.1. Cada objeto da classe Resource refere-se a um objeto da classe (QuantificationStrategy da Figura 4.8), o qual ´e respons´avel por seus aspectos de quantificac¸˜ao, permitindo que o framework implemente as quatro diferentes soluc¸˜oes reque- ridas. Outros padr˜oes de projeto foram utilizados na implementac¸˜ao do GREN, em especial os padr˜oesFactory Method e Template Method.
QuantificationStrategy isAvailable() PersistentObject isChanged isPersisted StaticObject idCode : integer description : String SingleResource status isAvailable() SimpleType MeasurableResource quantityInStock reSupplyLevel measureUnity isAvailable() MeasureUnity 0..* 1..1 0..* 1..1 ResourceLot number qtty LotableResource resourceLot isAvailable() 0..* 1..1 0..* 1..1 Resource isAvailable() quantification QualifiableObject NestedType ObjectType 0..* 0..* types 1..1 1..1 type do quantification.isAvailable
for each instance do: if status=Available
return true if quantityInStock >= 1 return true if status=Available return true ResourceInstance number allocation status InstantiableResource instances isAvailable() 1..* 1..1 1..* 1..1
Figura 4.8: Exemplo de algumas classes do GREN
O terceiro passo da construc¸˜ao do GREN foi a implementac¸˜ao de suas classes, que utili- zou a linguagem Smalltalk, mais especificamente o ambiente VisualWorks Non-Commercial 5i.4 (Cincom, 2001). A base de dados (relacional) utilizada na persistˆencia dos objetos ´e a MySQL (MySQL, 2001). A primeira vers˜ao do GREN possui aproximadamente 160 classes e 30 mil li- nhas de c´odigo. A hierarquia de classes do GREN, bem como mais alguns diagramas de classes, ´e apresentada no Apˆendice F.
A linguagem de padr˜oes GRN foi utilizada para implementar o GREN de forma gradual, se- guindo seq¨uencialmente seus quinze padr˜oes. A implementac¸˜ao do primeiro padr˜ao, IDENTIFICAR O RECURSO, deu origem a um pequeno framework que, ao ser instanciado, originava aplicac¸˜oes para manutenc¸˜ao de registro de recursos, como por exemplo, um sistema para controle de discos compactos (CDs) de um indiv´ıduo. Algumas operac¸˜oes poss´ıveis nesse sistema s˜ao: cadastrar
4.3 Exemplo – GREN: Um Framework para Gest˜ao de Recursos de Neg´ocios 72 os CDs, imprimir listagens de CDs em ordem alfab´etica, eliminar CDs, etc. A seguir foi imple- mentado o segundo padr˜ao, QUANTIFICAR O RECURSO, que estendeu o framework para tratar das poss´ıveis formas de quantificar o recurso, como as j´a mencionadas anteriormente nesta sec¸˜ao. Assim, no caso do sistema de controle de CDs, seria agora poss´ıvel cadastrar v´arias c´opias de um mesmo CD. Usando esse mesmo racioc´ınio, cada um dos demais padr˜oes da GRN foi implemen- tado, culminando com a vers˜ao final do framework GREN.
Para completar o passo de implementac¸˜ao do GREN, foi ent˜ao elaborada sua documentac¸˜ao segundo as diretrizes do processo proposto, o que resultou no Manual de Instanciac¸˜ao do GREN1,
denominado “Cookbook do GREN”. Ele cont´em quatro tabelas que permitem mapear a GRN ao
GREN. As duas primeiras tabelas correspondem `a “Tabela de Mapeamento de Classes” e as duas ´ultimas tabelas `a “Tabela de Mapeamento dos M´etodos”. Essas tabelas foram divididas para sepa- rar as classes da camada de neg´ocios das classes da camada de interface gr´afica com o usu´ario.
Uma amostra dessas duas primeiras tabelas ´e mostrada nas Tabelas 4.2 e 4.3. A Tabela 4.2 ´e utilizada na criac¸˜ao das classes concretas da camada de neg´ocios e a Tabela 4.3 na criac¸˜ao das classes da camada GUI. As classes da camada de neg´ocios preocupam-se apenas com a funcio- nalidade do sistema. Cada classe dessa camada pode ter uma ou mais classes correspondentes na camada GUI, voltadas aos aspectos de entrada e sa´ıda de dados. Deve-se notar que essas tabelas foram constru´ıdas com base na linguagem de padr˜oes GRN.
Tabela 4.2: Exemplo da documentac¸˜ao do GREN - Tabela usada para identificar novas classes da
aplicac¸˜ao
Padr˜ao Variante Classe do
Padr˜ao
Classe do GREN Cod.Ref.
1-Identificar o Recurso Todas Recurso Resource N1 Default, Tipos
M´ultiplos
Tipo de Recurso SimpleType N2 Tipos Aninhados Tipo de Recurso NestedType N2 2 - Quantificar o Recurso Recurso Instanci´avel Instˆancia do Re-
curso ResourceInstance N3 Recurso Mensur´avel ou em Lotes Unidade de Me- dida MeasureUnity N4 Recurso em Lotes Lote do Recurso ResourceLot N5 Recurso Simples nada a fazer – – 9 - Manter o Recurso Todas Manutenc¸˜ao do
Recurso
ResourceMaintenance N21 Origem SourceParty N6 Destino DestinationParty N14
Um exemplo das tabelas de mapeamento dos m´etodos do GREN ´e apresentado na Tabela 4.4. Ela lista os m´etodos a serem sobrepostos pelas novas classes criadas e deve ser percorrida seq¨uen- cialmente, usando informac¸˜oes sobre a hierarquia das novas classes da aplicac¸˜ao sendo instanci- ada. Quando encontra-se um m´etodo que pertence a uma classe abstrata do GREN, especializada 1BRAGA, R. T. V.; MASIERO, P. C. Manual de Instanciac¸˜ao do Framework GREN usando a GRN. ICMC-USP - S˜ao Carlos, documento de trabalho, 94p., 2002.
4.3 Exemplo – GREN: Um Framework para Gest˜ao de Recursos de Neg´ocios 73
Tabela 4.3: Exemplo da documentac¸˜ao do GREN - Tabela usada para identificar novas classes da
GUI
Padr˜ao Variante Cod.Ref. Classe GREN
1-Identificar o Recurso Default, Tipos M´ultiplos N2 StaticObjectForm Tipos aninhados N2 QualifiableObjectForm 2 - Quantificar o Recurso Recurso Simples N1 SingleResourceForm
Recurso Mensur´avel N1 MeasurableResourceForm Recurso Instanci´avel N1 InstantiableResourceForm Recurso em Lotes N1 LotableResourceForm Recurso Instanci´avel N3 ResourceInstanceForm Recurso Mensur´avel N4 MeasureUnityForm Recurso em Lotes N5 ainda n˜ao implementado
9 - Manter o Recurso Aplicando padr˜oes 14 e 15 N21 OneResourceMaintWPWTForm Sem apliar padr˜oes 14 e 15 N21 OneResourceMaintNPNTForm Todas N6 SourcePartyForm
Todas N14 DestinationPartyForm
durante a instanciac¸˜ao, ent˜ao esse m´etodo deve ser sobreposto. A coluna “Instˆancia/Classe” de- termina se o m´etodo ser´a invocado por instˆancias da classe ou pela pr´opria classe. A coluna “Coment´arios” descreve a func¸˜ao do m´etodo de forma suficiente para que o desenvolvedor possa codific´a-lo.
O “Cookbook do GREN” possui tamb´em algoritmos para serem utilizados em conjunto com as
tabelas, para permitir o uso disciplinado dessas tabelas na obtenc¸˜ao das classes e m´etodos a serem implementados. Um exemplo desse tipo de algoritmo ´e mostrado na sec¸˜ao 4.4.2.
Tabela 4.4: Exemplos de m´etodos a serem sobrepostos no GREN
Super-classe M´etodo Instˆancia/Classe Coment´ario
QualifiableObject typeClasses C retorna um objeto List com as classes que representam o tipo do recurso (zero ou mais).
ResourceMaintenance resourceClass C retorna a classe que representa o recurso sendo mantido. hasSourceParty C retorna um booleano, sendo true se o participante “Ori-
gem” foi utilizado durante a instanciac¸˜ao do padr˜ao 2, ou false caso contr´ario, j´a que esse participante ´e opcional nesse padr˜ao.
sourcePartyClass C retorna o nome da classe da aplicac¸˜ao que desempenha o papel de Destino no padr˜ao. Esse m´etodo somente deve ser sobreposto se o participante Destino foi utilizado du- rante a instanciac¸˜ao desse padr˜ao.
destinationPartyClass C retorna o nome da classe da aplicac¸˜ao que desempenha o papel de Destino no padr˜ao.
O quarto e ´ultimo passo da construc¸˜ao do GREN foi sua validac¸˜ao, com o intuito de verificar se aplicac¸˜oes produzidas a partir dele funcionavam corretamente. O GREN foi testado, pela pr´opria autora, para trˆes aplicac¸˜oes diferentes, escolhidas cuidadosamente de modo a exercitar todos os quinze padr˜oes da GRN. Entretanto, n˜ao foi poss´ıvel, durante esses testes, validar todos os varian- tes e sub-padr˜oes, o que pretende-se fazer em futuros esforc¸os. As aplicac¸˜oes utilizadas no teste foram: uma oficina de consertos de ve´ıculos, uma locadora de v´ıdeos e uma loja de venda e aluguel de produtos para festas. Ap´os o t´ermino desses testes, foram feitos alguns estudos com alunos de graduac¸˜ao e p´os-graduac¸˜ao, nos quais eles receberam a tarefa de desenvolver duas aplicac¸˜oes, mais
4.4 O Processo de Instanciac¸˜ao 74