Rapid Application Development

Rapid Application Development

EDM Solution

ISEL, Outubro 2010Ricardo Neto (#26657) - Nuno Sousa (#31923) - Paulo Pires (#32223)

1. Introdução2. Caso Prático3. Arquitectura da Solução4. Codificação e Geração5. Observação de Resultados6. Utilização7. Conclusões8. Trabalhos Futuros

Agenda

1. Introdução

Identificação do Problema

• Software houses focadas na quantidade e rapidez de produção em detrimento da qualidade do produto final

1

• Aparecimento crescente de software mais barato

Introdução > Caso Prático > Arquitectura > Codificação e Geração > . . . . . . .

• Compromisso crescente das software houses com os seguintes factores:

PRAZO

QUALIDADE RECURSOS

1Redução dos custos associados ao desenvolvimento de soluções, permitindo permanência em mercado competitivo.

Solução?

Análise do Problema


Identificação da Solução• Opções disponíveis para conseguir redução de custos de desenvolvimento

1

• Diminuir exigência com recursos utilizados

• Automatização de processos de trabalho rotineiros

Menor qualidade no produto finalûMaior probabilidade de gastos com manutençãoû

Utilização de metodologia consistenteüDesenvolvimento estável, repetivel e previsivelü


• Automatização de tarefas repetitivas na fase de implementação do ciclo de desenvolvimento:

1

• Caracterização de tipos de dados e restrições de domínio

• Identificação e definição de entidades

• Relações entre entidades

• Especificação de processos

• Definição de mecanismos de persistência

• Esquema de segurança

Definição do Âmbito


• Definição de Dicionário de Dados (3D)

1

Objectivos Gerais

3DTipos de Domínio

Objectos de Domínio

Serviços Externos

Processos de Negócio

• Agregador dos outputs da análise do problema, estruturando-os em secções próprias


• Criação de template Visual Studio (Solução EDM)

1

Objectivos Gerais

• Possibilidade de sincronização com o dicionário de dados dando origem à geração de código fonte a ser distribuído por cada projecto da Solução EDM

•Possibilidade de geração do modelo físico de suporte à persistência

• Estrutura necessária à representação da solução, dividida em projectos com “especialidades” distintas


Objectivos Gerais

1

3D

•Tipos de domínio

Rtti•Obj

ectos de domínio e acesso a dados

Entity

•Primitivas de CRUD; processos de negócio; permissões de execução

Services

•Publicação de implementações do projecto Services na forma de webservices

Ws

•Verificação, através de testes unitários, das operações implementadas no projecto Services

UnitTest

• Estrutura da Solução EDM


2. Caso Prático

• FutureView opera no sector do retalho e adquire lojas físicas em zonas de elevada concentração populacional

2

Loja ALoja BLoja CLoja D

FutureView

• Especificidade do negócio implica investimento inicial elevado na expansão do negócio

Problema

Introdução > Caso Prático > Arquitectura > Codificação e Geração > . . . . . .

Administração

Registo

VendaProcessos

• Com vista à redução de custos, a FutureView passou a operar também em regime de parcerias num modelo e-commerce

2

Problema

Parceiro A

Parceiro n

InternetFutureView ...

• Opção por solução que dê suporte aos seus processos de negócio


2

Modelo Entidade Associação

Customer

Individual Business

IS-A

LastPasswords Contacts

ContactLastPassword

OrderHeader OrderItem

Orders

Items


Category SKU

Has

2


Contact

Address

Billing Shipping Customer Address

Phone

Fax Mobile Landline

Email

• Modelação da hierarquia da entidade Contact

IS-A IS-A

IS-A


3. Arquitectura da Solução

3

Sincronização

Base de Dados

Internet

Gerador

EDM.FoundationClasses.dll

Validação Segurança ORM Excepções

Serviços Testes Unitários Entidades TiposWeb

ServicesModelo

Físico

…NHibernate

SGBD

Solução EDM

.NET Framework 3.5

3D(Dicionário de Dados)

Transformação 1

Transformação n

Pipeline de geração

Arquitectura

. . . . > Caso Prático > Arquitectura > Codificação e Geração > Observação > . . . . .

4. Codificação e Geração

4

Demo• Codificação no dicionário de dados de:• Tipos de domínio• Suporte à persistência• Entidades e seus campos• Processos de negócio

. . . . > Arquitectura > Codificação e Geração > Observação de Resultados > . . . . . .

4

Processos de Negócio• Protótipo de operação a ser exposta pela solução

Validação de parâmetros

Execução do processo

Validação do retorno

Component A

Process A1

Process A2

Component B

Process B1

Process B2

Business ProcessParâmetros Retorno

• Garantia de validação de parâmetros e retorno respeitando as restrições de domínio


4

Modelo de Segurança• Exigência de permissão na execução de processos de negócio e operações CRUD sobre entidades com base em RBAC


Component X

Process A1

Process A2

Entity Y

Create

Read

Update

Delete

Internet

Acesso a A1Acesso a

Create de Y

Exigência da permissão “XA1”

Exigência da permissão “YCreate”

4

Relações 1 - 1• Relações de herança entre as entidades

A

B C

D

<entity type=“abstract" name=“A"> <fields> . . . </fields></entity>

<entity type=“dependent” name=“B“ baseEntity=“A"> <fields> . . . </fields></entity>

<entity type=“abstractdependent" name=“C“ baseEntity=“A"> <fields> . . . </fields></entity>

<entity type=“dependent" name=“D“ baseEntity=“C"> <fields> . . . </fields></entity>

E

<entity type=“base" name=“E"> <fields> . . . </fields></entity>


Relações 1 - 1• Representação em object model corresponde à herança entre classes

• Em modelo relacional representam-se numa única relação

TabelaA ( a1, a2, b1, b2, c1, c2, d1, d2 )

Campos de A

Campos de B

Campos de C

Campos de D

4. . . . > Arquitectura > Codificação e Geração > Observação de Resultados > . . . . . .

Relações 1 – n e n - 1• Diferentes materializações em object model e modelo relacional

BA

relA

…

A

…

B*_relA

<relation type=“OneToMany" name=“relA" oneEntity=“A" manyEntity=“B“ inverse=“false” minOccurs=“1" maxOccurs =“unbounded" nillable=“false"></relation>

“true“

1

A…

A

…

B

Object Model Modelo Relacional


Relações n – n• Necessária a criação de uma entidade associativa

<relation type=“ManyToMany" entityName=“AB“ minOccurs=“1" maxOccurs =“unbounded“> <entity name=“A" nillable=“false“ inverse=“false" relationName =“As“> <entity name=“B" nillable=“false“ inverse=“false" relationName =“Bs“></relation>

…

A

…

B

Object Model Modelo Relacional

BA AB

11

** …

B

_Bs

B

…

A

_As

A

…

AB

AB

“true““true“


Demo• Codificação no dicionário de dados de:• Relações entre entidades

• Sincronização do 3D com a Solução EDM• Geração do script de construção do modelo físico


5. Observação de Resultados

5

Sincronização

Base de Dados

Internet

Gerador

EDM.FoundationClasses.dll

Validação Segurança ORM Excepções

Serviços Testes Unitários Entidades TiposWeb

ServicesModelo

Físico

…NHibernate

SGBD

Solução EDM

.NET Framework 3.5

3D(Dicionário de Dados)

Transformação 1

Transformação n

Pipeline de geração

Arquitectura

Observação de Resultados

6. Utilização

Administração

Registo

Venda

Processos

6

ProblemaParceiro A

Parceiro n

InternetFutureView ...

Conclusões

Modelo Entidade AssociaçãoCustomer

Individual Business

IS-A

LastPasswords Contacts

LastPassword


Contact

Address


Phone

Fax Mobile Landline

Email

IS-A IS-A

IS-A

6

2


Contact

Address


Phone

Fax Mobile Landline

Email

• Modelação da hierarquia da entidade Contact

IS-A IS-A

IS-A


7. Conclusões

7Conclusões

1. É sustentável ter um desenvolvimento baseado em dicionário de dados.

2. Há um efectivo ganho de eficiência e eficácia no processo de desenvolvimento

3. O EDM não é apropriado a todo tipo de projectos.

8. Trabalhos Futuros

8Trabalhos Futuros

Trabalhos Futuros

1. Consolidar a solução EDM em casos reais

2. Contemplar a camada de apresentação na solução EDM.

3. Certificação do processo de desenvolvimento utilizando metodologia apropriada.

Documents

Rapid Application Development