Midgard's final presentation
•Transferir como PPT, PDF•
0 gostou•205 visualizações
Presentation for out final school project: Midgard.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (14)
Destaque
Destaque (17)
Semelhante a Midgard's final presentation
Semelhante a Midgard's final presentation (20)
Último
Último (7)
Midgard's final presentation
- 1. 11 Alunos Nuno Silva - 24948 Pedro Santos - 24992 Tiago Sousa - 25126 Coordenadores Paulo Pereira Pedro Pereira
- 2. 2 • Motivação • Objectivos • Visão Geral • Arquitectura • Infra-Estrutura • Conclusão • Casos Práticos • Vídeo Estrutura da Apresentação
- 4. 4 Código Repetitivo Necessidade de criar sempre os mesmos componentes • Bases de dados • Acesso a dados • Internacionalização • Controlos para mostrar dados • etc
- 5. 5 • Baixo Acoplamento e Alta Coesão • Menos Código para o Programador Escrever • Desenvolvimento rápido • Diminuição dos erros • Combate à Redundância • Independência
- 12. 12 Componentes Gerados Projectos Gerados • Core • DataAccessLayer • Config • WebUserInterface Exemplo
- 13. 13 Componentes Gerados Core • Representação em classes do modelo de entidades DataAccessLayer • API de persistência de entidades Config • Aplicação de utilitários
- 14. 14 Web User Interface • Controlos extensíveis para a manipulação visual de entidades • Funcionalidades comuns em aplicações web • Autenticação/autorização • Internacionalização • Gestão de Excepções • Interface de Administração
- 16. 16 Edição e Listagem de Entidades EntityEditor
- 17. 17 Edição e Listagem de Entidades EntityList Output
- 19. 19 • Pontos Fortes • Mecanismos de Automatização • Fácil mudança de requisitos • Controlos ASP.NET versáteis • Independência de SGBD • Trabalho Futuro • Especificação do Fluxo de páginas • Independência de ferramentas exteriores
- 21. 21 MOVIE TIME!
Notas do Editor
- Motivação – o que nos levou a fazer este trabalho. Tudo no midgard tem uma razão de ser que é explicado ao longo da apresentação Objectivos – Com o Midgard que problemas pretendemos resolver. Visão Geral – Explica por alto o que é o midgard: Ficheiros de entrada Arquitectura – Blocos constituintes do Midgard Infra-Estrutura – Componentes gerados pelo midgard. Explicação e utilização Conclusão – Pontos fortes e trabalho futuro do Midgard
- Cansados de gerar componentes semelhantes sempre que se desenvolve uma aplicação Web. Alguns destes elementos são: - Bases de dados, - Acesso a dados - internacionalização - Controlos para mostrar dados - Gestão de Excepções - Backoffice Solução – geração automática
- Baixo Acoplamento – os componentes gerados são independentes entre sim (baixo acopolamento), ou seja, não possuem dependências entre eles o que significa que a alteração num dos componentes não afecta os restantes. Alta Coesão – Cada componente gerado realiza apenas a função a que foi destinado Com estes dois princípios temos código de baixa dependência, pouco impacto na mudança e reutilizável. Desenvolvimento rápido – grande parte do código é gerado pela ferramenta, remetendo o programador para tarefas que requeiram mais desafio. Menos Código para o Programador Escrever e Diminuição dos erros – como grande parte do código é gerado, menos código o programador faz, reduzindo assim a possibilidade de erros Combate à Redundância - Don't Repeat Yourself - Perceber o máximo a partir do minimo possível. Independência – O código gerado ao nível do acesso a dados é independente do SGDB, ou seja, o mesmo código dá suporte ao acesso a vários SGBD’s bastando para isso mudanças ao ficheiro de configuração e à connection string. Isto é possível graças à biblioteca NHibernate. Esta biblioteca é a responsável por a gestão deste acesso e oferece-nos todas estas facilidades.
- Descrição do Modelo de dados – descrição das entidades da aplicação Web que se pretende gerar. Este ficheiro pode ter um qualquer formato. Nativamente o Midgard suporta descrição na linguagem XMI. Ficheiro de configuração – Descrição de dados no formato XML. Este ficheiro possui 4 secções: - plugins de Loader – onde são especificados os plugins que vão ler a descrição do modelo de dados. - plugins de Codegenerator – onde são registados quais os plugins gerados de código que vão ser executados. Cada plugin destes corresponde a um componente. Por exemplo: mecanismo de acesso a dados, Interface de Administração, Gestão de excepções, etc... - plugins de BuildGenerator – onde são registados os plugins de geração de ficheiros de projecto (Visual Studio, ficheiro de build de nant) NHibernate e NVelocity - Bibliotecas que apoiam a geração e funcionalidades presentes no código gerado. NHibernate dá suporte a toda a infra-estrutura de acesso a dados. É este que simplifica os acessos à base de dados, NVelocity é uma framework de templates que permite de forma fácil fundir os dados (obtidos dos ficheiros de input) e os templates de ficheiros por forma a gerar todos os ficheiros de output.
- Tiago – Inputs e Output O porquê desta arquitectura: Como são criados os plugins dinamicamente através das factories; Os diferentes tipos de plugins e a suas funções; A necessidade de ter objectos de suporte; Conseguir a expansibilidade através desta arquitectura. O Midgard recebe 2 inputs e produz uma aplicação web. Os inputs são: o ficheiro de configuração/projecto que parametriza os componentes gerados, assim como outras parametrizações como a directoria de destino ou o tipo de SGBD utilizada; e o ficheiro contendo a informação do modelo de dados. Através da informação do ficheiro de configuração as factories criam dinamicamente os plugins necessários. O plugin do tipo Loader carrega a informação contida no modelo de dados e cria os objectos de suporte à informação contida no modelo de dados. Finalmente os plugins de Generate pegam na informação dos objectos de suporte e juntamente com os templates produzem os outputs.
- - Tiago - Explicar as diferentes fases do processo/fluxo de geração. Porquê dividir a leitura do ficheiro XML em duas fases. Porquê os plugins CodeGenerator terem diferentes fases de geração. Este diagrama representa o fluxo de geração. Inicialmente são carregados os parâmetros do projecto e identificados dos plugins a carregar. De seguida as factories carregam os plugins. O Processo de load e dividido em duas fases, uma primeira fase onde são passadas as parametrizações e a segunda onde é lido o modelo de dados e produzidos os objectos de suporte. Neste ponto é lido novamente o ficheiro de configuração, pois este contem informação relativa às entidades que só faz sentido depois dos objectos de suporte terem sido criados, por exemplo o campo name da tabela image só pode ter 10 caracteres. A partir deste momento está recolhida toda a informação necessária e pode ser inicializado o processo de geração.
- - Tiago - Utilização do padrão factory. O que fazer para acrescentar uma nova fábrica.
- - Tiago - Explicar a arquitectura de plugins. Diferentes tipos de plugins. O que fazer para acrescentar um novo plugin.
- - Tiago - A necessidade desta arquitectura (necessidades de informação para a geração). Raciocínio a utilizar se se pretendesse gerar outro tipo de informação. O que fazer para acrescentar nova informação à que já é gerada. Para descrever um diagrama UML que é a nossa descrição do modelo de dados o que é necessário? Um UML é composto por classes e Interfaces, logo uma entity é uma destas duas definições. Por sua vez uma classe ou interface pode implementar/derivar de outras interfaces. Uma entity pode conter campos e métodos e métodos podem ter parametros. No caso de se achar necessário retirar + informação do UML de entrada isso teria de se reflectir nesta arquitectura. Por exemplo se se desejasse acrescentar atributos às classes ou métodos teria de existir outra classe que tivesse uma associação múltipla com EntityClass e EntityMethod
- A forma automática como gera código. Num projecto pequeno (como os que vamos apresentar a seguir) pode dar origem a mais de 300 ficheiros. Adapta-se facilmente à mudança de requisitos – qualquer projecto tem mudança de requisitos. O Midgard permite a alteração de requisitos com simplicidade. O código gerado pelo utilizador é mantido, e os novos requisitos são adicionados. Há que esclarecer que o código gerado não é um código fechado. O código gerado pode ser alterado – acrescentar ou estender funcionalidade. Controlos ASP.NET versáteis que cobrem quase todas as funcionalidades que se pretende. Quando a funcionalidade gerada não é suficiente, a framework permite a sua extensão ( tal como o Pedro já referiu ). Independência do SGBD - Isto é bastante importante visto que não limita a utilização do Midgard. Especificação do Fluxo das páginas – ter uma maneira simples (talvez por meio de mais um ficheiro de input) de especificar o fluxo de páginas (quais são e como se relacionam) e também especificar, por página, o que é que esta vai fazer. Esta funcionalidade é mérito do NHibernate que disponibiliza esta funcionalidade de borla. Como o código gerado é dependente de templates de texto, significa que alterações podem ser feitas aos templates de geração sem necessidade de compilação da ferramenta. Isto permite não só personalização do código gerado, como facilidade de resolução de eventuais bugs e tudo sem tocar numa linha de código. Com esta funcionalidade implementada, ainda menos código é necessário o utilizador(programador) escrever, automatizando ainda mais o processo de desenvolvimento de uma aplicação web. “O objectivo de um programador é acabar com o seu trabalho” Independência de ferramentas exteriores– interessante mas não obrigatório