ABAPDoc2: Primeira Versão do Modelo
Nessa semana definimos a primeira versão do modelo de nosso projeto ABAPDoc2 (veja aqui maiores detalhes do nosso projeto). Você também pode encontrar nosso planejamento conferindo o progresso do projeto diretamente olhando o projeto no Code Exchange.
Abaixo eu comento um pouco mais sobre o modelo, decrevendo um pouco melhor o que cada classe faz.
Nesse projeto, estamos seguindo o paradigma MVC, Model-View-Controller.
ABAP Workbench Model
O objetivo do modelo é abstrair todos os tipos de objetos do ABAP Workbench, tais como pacotes, grupos de função e classes globais. Clique na figura abaixo, para visualizar o diagrama de classes do ABAPDoc2.
ABAPdoc Model - Versão 1
Comece identificando as classes que representam o objetos do ABAP Workbench, são aquelas que tem o nome começando com ZCL_WB_, onde WB significa workbench.
Representando os grupos de função, temos a classe ZCL_WB_FUNCTION_GROUP, que está associada a classe ZCL_WB_FUNCTION_MODULE, representando os módulos de função. A associação escolhida aqui foi a de composição, indicando que um módulo de função só pode existir se estiver associado a um grupo de função.
Isso deve ser levado em consideração no momento da implementação, sendo que muito provavelmente a classe ZCL_WB_FUNCTION_GROUP será responsável por criar os objetos da classe ZCL_WB_FUNCTION_MODULE. Mas isso é somente um detalhe que levaremos em consideração no momento da implementação.
A classe ZCL_WB_SOURCECODE representa o código fonte, seja ele como parte de um módulo de função ou implementação de um médoto.
A classe ZCL_WB_CLASS é responsável por prover os serviços relacionados a classes globais. De maneira semelhante aos grupos de função e módulo de função, a classe ZCL_WB_METHOD está relacionada com a classe ZCL_WB_CLASS. Sendo assim, um objeto da classe ZCL_WB_METHOD só pode existir se estiver associado a outro objeto ZCL_WB_CLASS.
O terceiro objeto do workbench é o pacote, que é representado pela classe ZCL_WB_PACKAGE. No ABAP Workbench, um pacote pode conter outros pacotes e também outros objetos. Mas para o nosso modelo, não representamos isso, pois ainda não conseguimos extrair/criar um pacote usando o SAPLink. Isso ficará para o próximo projeto.
Todas as classes WB herdam de uma única classe, ZCL_WB_OBJECT que por sua vez implementa a interface ZIF_WB_OBJECT. Esta interface define o nome e assinatura dos métodos que todas as classes do WB devem implementar. Com esse desenho, todos os objetos do WB possuem um atributo NAME e os métodos abaixo:
- LOAD( ), responsável por extrair as informações do sistema e carregar os atriutos da classe. Por exemplo, imagine que eu crie um objeto da classe ZIF_WB_CLASS, com atributo NAME = ‘CL_GUI_ALV_GRID’. Quando eu chamar o método LOAD( ), a implementação dele deve ler as informações da classe CL_GUI_ALV_GRID e carregar os atributos do objeto.
- SET_NAME( ) e GET_NAME( ), esses métodos são responsáveis por definir e retornar o atributo NAME.
- GET_HTML( ), esse método é responsável por gerar e retornar o código HTML.
Pela descrição acima podemos ver que os métodos LOAD( ) e GET_HTML( ) serão os métodos mais importantes.
Para coordenar todo os serviços do moldelo workbench, temos a classe ZCL_ABAPDOC_PROJECT, quem tem a responsabilidade por prover os serviços para geração do HTML e carregar todo o modelo WB.
Nos métodos, temos uma série de métodos SET e GET para definir e retornar os atributos. Aqui temos dois métodos muito importantes:
- LOAD_ALL( ), esse método irá passar por todos os objetos associados ao objeto ZCL_ABAPDOC_PROJECT e chamará o método LOAD( ). Se você achava que não usaríamos polimorfismo, aqui será vitar usá-lo.
- EXPORT_TO_HTML( ), será nesse método que os arquivos HTML serão gravados no computador do usuário.
Próximos Passos
Para esse release, o ABAPDoc2 irá apenas gerar arquivos HTML. Estamos planejando não gerar HTML, mas gerar um componente WebDynpro. Ainda não sabemos como isso será, mas temos certeza que o nosso modelo irá permitir qualquer tipo de saída, inclusive com uso de templates, para que as empresas possam customizar conforme as suas necessidades.
Muito interesse, gostei do approach que vocês estão dando para o ABAPDoc.
Seguem uma sugestão/cometário sobre a modelagem do sistema:
– Internamente no sistema do SAP você pode abrir qualquer código de qualquer objeto pela SE38, desde que você tenha o nome apropriado do objeto… então não é completamente errado dizer que todo código fonte se resume em uma “include”. Por conta disso, acho que seria mais parecido com o sistema SAP se dissermos que dentro do ABAPDoc uma classe/função/programa é um objeto e deve ter um código fonte. Então, a classe ZCL_WB_SOURCECODE deveria ser uma interface obrigatória para todos os objetos que tenham código, ou seja, classes de Funções, de Programas, de Exits, de BADIs…
– No futuro, se vocês forem implementar outros tipos de objeto no ABAPDoc, como por exemplo, objetos do DDIC, vocês poderiam criar uma interface ZIF_WB_DDIC, uma interface obrigatória para todos os objetos que sejam do DDIC. Isso ajuda com o polimorfismo, já que com um objeto do tipo SourceCode ou DDIC vocês podem utilizar tudo que tenha código fonte, ou que seja do dicionário de dados. Isso é só um exemplo, mas a idéia de transformar a SOURCECODE em interface pode salvar problemas com futuras alterações no sistema!
Animal o trabalho, vou começar a seguir o projeto no CodeEx 🙂
Abraços!
Mauricio Cruz
Olá Maurício,
Ótima sugestão. Vou discutir isso com a Claudia (que está implementando) e vamos incluir essa alteração nesse release já.
Muito obrigado pela participação!