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.

MVC - Fonte: http://www.fernandovalente.com.br/wordpress/2011/01/11/mvc-model-view-controller/

Fonte: http://web.archive.org/web/20110918232716/http://www.fernandovalente.com.br:80/wordpress/2011/01/11/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

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.

 

You may also like...

3 Responses

  1. 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

    • furlan says:

      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!

  1. December 16, 2011

    […] ABAPDoc2: Primeira Versão do Modelo – via ABAP 101 […]