soft fluent development white paper

8/8/2019 Soft Fluent Development White Paper

1/22

How Model-Drcan help

CodeFlue

SoftFluent Marketing Te

Version 1.0June 2010

oftFluent

iven Software Develoyour projects succeed

t Entities White Pap

am

ment

er


2/22

Executive Summary

The objective of this white paper icauses and show how SoftFluent afactory and associated methodolog

The first half of the document expla

In chapter 1, we explain th In chapter 2, we comment In chapter 3, we detail ou

new technology (whose op In chapter 4, we propose a

It is interesting to note that thidevelopment at large and not depeit.

In the second half of the documentchallenge:

In chapter 5, we presentovercome the limits of past

In chapter 6, we detail theapproach for modeling, de

In chapter 7, we list typicalusing the CodeFluent Entiti

In the end, CodeFluent Entities asuccess. Possibly, this recipe is notcustomers so far.

SoftFluent, June 2010 - Do not du

CodeFluent Entities is a registered t trademarks or registered trademar

The material presented in this docuintended for general information o

June 2010

to describe the software development challenge,dresses it through its CodeFluent Entities model-d.

ins the market challenge and why this is a difficult

structural nature of the software development ch

n the common approaches that exist on the markefield observations of project failures, particularlynness bear more risks than traditional constrained

"Success Equation" as a model for summarizing the

s part is widely applicable for people interestendent on our offering, and does not require any kn

we explain the solution we have built to structura

ur tenets that have been guiding the design of CASE approaches,different steps of our methodology using the Codeloping and industrializing,situations to illustrate the concrete benefits thats approach.

ims to be a concrete recipe for software develounique, but having one has proved to be of gre

plicate without permission.

rademark of SoftFluent. All other company and pros of their respective holders.

ent is summary in nature, subject to change, not cly and does not constitute a representation.

clarify its rootriven software

usiness issue:

llenge,

t,frequent withlegacy),

se elements.

d in softwareowledge about

lly address the

ur solution to

Fluent Entities

one will get by

pment projectt value to our

uct names are

ontractual and


3/22

Table of Content

I. The software development c

II. Common approaches ............A. RAD Tools ----------------B. CASE Tools ---------------C. Off-shore -----------------

III. Our field experience of failurA. Lack of skills -------------B. Lack of experience andC. Over-engineering and

IV. A proposed model for the S

V. SoftFluent Tenets ..................

VI. CodeFluent Entities Agile MeA. CodeFluent Entities priB. Agility with CodeFluenC. Recommended steps f D. Recommended steps f

VII. CodeFluent Entities benefits

June 2010

allenge .....................................................................

...................................................................................------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

s................................................................................--------------------------------------------------------------------geek attitude ----------------------------------------------rameworks ----------------------------------------------------

ccess Equation ........................................................

...................................................................................

hodology ..................................................................nciples ----------------------------------------------------------Entities --------------------------------------------------------r basic usage -------------------------------------------------r advanced usage -------------------------------------------

hrough 12 scenarios .................................................

...................... 4

...................... 5------------------ 5------------------ 5------------------ 5

...................... 7------------------ 7------------------ 7------------------ 8

....................10

....................11

....................12---------------- 12---------------- 13---------------- 14---------------- 18

....................21


4/22

I. The software developme

Being in charge of a business sof enviable job in the world. On the o

under increasing constraints.As each business sector is makisophisticated functional requiretechnology and usability expectaticonsumers. The fact that packagedusers with significant investmentexpectations for their business user

As a matter of fact, the developmto-use solutions for its users. Theinnovation is accelerating, with an i

Completing the picture by the addand timeframes , everyone canbetween growing functional expect

Coming to that point, you mightrecommend you do so if you can!continue the reading.

June 2010

nt challenge

tware development team in the 2010 decade ise hand, user expectations keep inflating, whereas

g progress, this unavoidably translates into ments . Meanwhile, business users have highe

ons , consistently with what they experience at hosoftware they use in their personal life is producedoes not help much an IT team to argue about l

s at work.

nt team must digest technology innovation , andhallenge is getting harder and harder as the pace

ncreasing complexity which becomes hardly huma

itional pressure most IT teams face in terms of reuickly understand that developers are structur

ations and evolving technology.

be tempted to embrace another career path,But if this is too late for you as this is for us, w

not the mostmeans are put

re and morer and higher e as individualfor millions of

owering those

provide ready-of technology-manageable.

uced budgetsally squeezed

and we mightinvite you to


5/22

II. Common approaches

Software development is a 50 yetoday. Let us comment on the diffemain limits.

A. RAD Tools

As developer time reveals costly,accelerating this process through v

Some popular RAD tools, such as Papplications within quite shortdemonstrate results that look appe

However, if the application reachetools is not able to deal with featuhas been designed for, but totally clit.

The main issue for customers is trequirements for their applications

B. CASE Tools

Computer Aided Software Enginepopularized during the client/serve

Tools such as Powerbuilder, Progrtime. These tools had invested a lo

and encountered real success in tthese tools hid the complexityprogramming language at that time

But those CASE tools lost popularitmodel with the emergence of thelevel languages such as Java or C#,gains that had been achieved so far

Another reason is the fear of somtools usually provide their own pro

In the end, the main issue for cu

technology , as the footprint of thethere is no real efficient CASE toacceptable situation for customers.

C. Off-shore

Another approach that many compthe issue by lowering the cost of re

June 2010

r-old discipline, so one can wonder why solutionrent common approaches that have been tried and

here is a long history of software engineering toorious means, especially the one known as code gen

Soft Windev or 4D, have actually provided a goodimeframes. Different prototyping or RAD tool

aling with a simple process.

s a certain level of complexity, it is often found tre sophistication, as the tool is very efficient in dellosed to additional added-value if it has not been p

hen to be stuck with not being able to answer. This is usually not an acceptable risk for customer

ering tools have existed for long, and have ber wave of the 1990s.

ss, Magic, NS-DK or Centura gained a lot of moin providing a programming model for client/serv

rms of both market reach and productivity gainsf languages such as C++ which was a standa.

, mostly because of the emergence of a totally neeb. As a consequence, numerous customers refopushed by platform software vendors, losing in tby these higher abstraction tools.

customers of being locked in the vendor environramming language.

stomers is the fact of not being able to keep u

se offerings make them very slow to evolve. As aol to date for web applications. This, again, is

anies have tried especially during the 2000s decadources through moving development off-shore.

s do not existhighlight their

ling focused ateration.

way to delivers can quickly

at this kind of ivering what ite-designed for

the functional.

n numerously

entum at thatr applications,

. In particular,rd lower-level

programmingused on lower

he process the

ment, as these

-to-date with

matter of fact,sually not an

e is to address


6/22

Though it might look economicallacross geographies, this solution

In fact - when it works - it does nocosts on development resources, w

Complete books could be (and hastory short, putting the team furthour challenging equation.

On the contrary, experienced peapplication will encompass the coslast longer than the initial develop

And what might look like savings iagility over the long term. Any expdesigned application is weak and e

The main issue with off-shore is th

the expense of industrialization an

In our views, those 3 approaches btimeframe, scope and cost.

All those three parameters need tmethodology to address the softwa

June 2010

appealing initially, with labor costs varying of ahas been far from delivering on its promises.

fundamentally address the challenge, as it just lohile adding a lot of new difficulties and risks on the

e been) written on off-shore development, but, tr away does not increase its know-how and is not

ple in software development know that the tos incurred during the maintenance phase. This phent phase.

n the short term often turns out to be additionalrienced developer knows that the evolution capabch minor evolution becomes more and more costly

at it is often driven by cost reduction, with a proje

d maintenance .

ear intrinsic limits putting an excessive emphasis

o be balanced appropriately, and this is why were development challenge.

1 to 10 factor

ers perceivedproject.

o make a longthe answer to

tal cost of anse will usually

costs and lostility of a poorly.

ct delivered at

espectively on

favor another


7/22

III. Our field experience of f

Because we are experienced in sof .NET developments to analyze tscalability, its manageability in prod

First of all, it is worth mentioning tthe amount of inefficiencies. We hquite common to conclude that at lthe appropriate libraries, most of t

An interesting point to note is adevelopment teams, that we sum u

A. Lack of skills

The first reason for failure is the lac

In some cases, even experienced dtechnical layers used to be propeadditional challenge of a great ope

In this situation, we observe thatperimeter or in capacity. Since codtime, maintenance is getting hardeteam eventually meets a wall.

In the mentioned failure case, this f

B. Lack of experience and ge

In other cases, we have observed ytechnologies. But they may lack enadopt a geek attitude, a behavior

In those situations, developers havits beauty, like writing a complex ithe developer but does not bear ait may increase maintenance costs.

These profiles often lose sight of thof interest, and they do not havemanageability and the necessity for

Because of this lack of experience,applications they design perform p

Applications developed this way aredesign in areas where performan

This case of failure is in fact a lack o

June 2010

ilures

ware development, we are often asked to lead aue quality level of an application, its evolutionuction.

at we are amazed by the great proportion of projave often met failures in the several million dollarleast half of the produced code could have been ae time in the .NET framework itself!

lso the existence of typical syndromes we havep hereunder.

k of skills.

evelopers may lack skills in new technology. As thly hidden in CASE tools, it is not the case any loness of environments, leading to many more pote

he code usually works until the project gets me is produced manually, with heterogeneous stylesr and harder and the cost of incremental change in

ailure is due to the first factor: skills .

ek attitude

oung developers that are rather clever and comforterprise experience and many of them have a strowhere people focus on each and every new piece o

e a strong technology bias and concentrate only onstruction within a single line of code, which satisy intrinsic value. In fact, it even holds potential ne

e functional objectives, because users are not theithe proper level of experience to understand thcode instrumentation.

they commonly underestimate some challenges of orly with high volumes of data or numerous users.

e usually hard to maintain and require targetedce is needed.

f a proven method .

dit missions oncapability, its

ct failures andrange and it isoided by using

observed for

complexity of nger, with thetial pitfalls.

re complex inchanging overflates until the

able with newg tendency tof technology.

the code andfies the ego of gative value as

primary pointchallenges of

scalability and

ptimization or


8/22

C. Over-engineering and fra

The last case often leads to the mon large accounts.

In this third syndrome, a genius so-

solution for the development teabecause he often believes he willstarts writing - potentially with aoptimal recipe for the project but t

Setting the appropriate abstractionthe schema hereunder:

The Where to stop? on the left iswrong, even though the idea of buil

Experience shows that:

Building a flexible framewtechnology is hard and risk

The risk of simply failingtunnel effect during frame

In most favorable cases, thwill not resist the next watechnology, and another ris

In almost all cases, the fra

June 2010

eworks

st costly situations. And in fact, it is the most obs

called architect (or several) has been hired to inven

. Usually, this architect is smart, and this is parbe able to invent all relevant solutions for the prteam of developers - a framework that is suppoat often goes too far.

level for a project requires placing the cursor at th

a critical question, as in our experience, this is whding a framework could look great.

ork that can face all needed situations with ne,ith a framework that does not work is huge, witork development, a phase that can last forever,

e framework will provide value for a certain technve, with the necessity of big reinvestment to keek of failure,ework cannot be maintained by someone else tha

rved situation

t a customized

t of the issue,oject. He thensed to be the

right place on

ere things turn

and evolving

h potentially a

logy wave andp up with new

the architect.


9/22

Though not always admitted, this si

If sometimes CASE Tools were percin syndrome described here is mperceived as much more worrisom

This case of failure is an over-invwhose complexity proves to always

June 2010

tuation leads to significant economic failures.

eived as a problem because of vendor lock-in, theuch worse. The risk of depending on an individthan depending on any third-party.

stment in tooling , a factor which is quite hard tbe under-estimated.

architect lock-ual should be

address, and


10/22

IV. A proposed model for th

Many studies about software ddevelopment projects. In a recent iof software development projects a

In fact, we could put the success prsimple formula such as:

If the global Know-how is abovesimple to understand.

Additionally, introducing the elemcould consider that:

Noting that each component is egrowing faster and faster by a cubi

Simplified this way, it gets crystal can approach that allows Know-ho

As a matter of fact, without a meteams to succeed over the long-ter

This is consistent with our observacosts are often exploding and themaintenance burden on developm

So is there any hope to keep up wit

Let us consider the know-how as bto us to be the major success factor

Our equation becomes sustainablethe method and the tools .

This is basically what we proposemodel-driven method, supportedDevelopment team responsibility isapproach, as part of the complexity

June 2010

Success Equation

evelopment confirm a high degree of failureternational study quoted by AFDEL, it is recognizere considered as successes, and only 13% are deliv

obability of a project into an equation that we woul

%

the Ambition, the project will be successful. This

nts mentioned above about expectations in the in

olving in an unfavorable direction, this means tc factor !

lear that software development projects cannot s to grow fast enough to keep up with the ambitio

thodological shift, there is not even a chance fom .

ions in the field, where in reality although somevolume of legacy obsolete code keeps growing,nt teams.

h the ambition or is this a lost battle?

eing the combination of 3 key components, the ons for development projects:

, at the imperative condition of perpetually impro

ith our software development approach, basedby a tool that improves the development

then to focus on maintaining the skills, a simplifiedof underlying technologies is hidden.

s in softwarethat only 30%red on time.

ld simplify by a

sounds pretty

troduction, we

he ambition is

cceed withoutn.

development

times hidden -increasing the

es that appear

ving the skills,

on an iterativeprocess itself.process in our


11/22

V. SoftFluent Tenets

Because at SoftFluent, we have spexperience to define a new recipe t

Our development approach is builcouple of structural differences tar

The way we address the key historithe heart of our model-driven deve

1. Business entities have lonthat will survive technoloapplication.

2. Business rules and processcontinuous maintenance sc

3. Efficient coupling of data,must be guaranteed by des

4. Coding patterns need tomaintenance can be perfor

1 SoftFluent founders are former Micro

June 2010

nt many years on development projects 1, we havehat will ensure project success, even with evolving

t on the success of past recipes, such as CASE toeted at addressing the limitations observed with th

al drawbacks of CASE tools are formalized into ourlopment methodology:

er lifecycles than technology and should be defiy shifts and allow supporting them without ree

changes need to occur through short cycles that caheme.model, and presentation layers including customiign .e standardized and their implementation autom

ed by standardized skills .

soft employees with a long track record in software deve

leveraged ourechnology.

ols, but with aose tools.

keys tenets, at

ed in formatsngineering the

n fit into a lean

ed code parts

ted to ensure

lopment.


12/22

VI. CodeFluent Entities Agil

Now that we have introduced our twill explain in this chapter how one

A. CodeFluent Entities princiCodeFluent Entities builds on SoftFl

Design of functional eleme Development of customiz

template customization for

As described in the schema hereun

Beyond the process itself, which isof CodeFluent Entities automated p

Model analysis and inferpowerful as this is what allthe combination of comple

Generation : the producerstotal consistency in the wa

Execution : the runtime librcomponents to make the d

June 2010

Methodology

enets and the key drivers that we have built our off works with CodeFluent Entities to design and deliv

les

uent tenets by proposing to concentrate the effort

nts in a manner that is mostly independent from ted code , mainly in the business layer for businesgenerated UIs or reports.

er, all other phases of the application life cycle are

concentrating the effort into two focused areas, thases is embedded at 3 different levels:

ence : though not visible, this automated phasows the extremely advanced generation process t

behaviors,generate ready-to-use components on all layersthose components integrate with each other,

aries provide advanced services that are leveragevelopment process more productive for the devel

ering upon, wer software.

on two areas:

chnology,s code and in

automated:

e added-value

is extremelyat follows and

chosen, with a

by generatedper.


13/22

B. Agility with CodeFluent En

CodeFluent Entities is not strictlyleverage the product using a classicbeen delivered with CodeFluentspecification phase.

However, CodeFluent Entities is pamethodology. Agile methodologierequires delivering software thatthe scope is extended until the soproduction or released to the mark

CodeFluent Entities proposes sevconjunction with an agile methodol

Functional elements desigcomponents ,

Specifications do not needregenerated as necessary

Technical target architectproducers and layer-specifi

By design, CodeFluent Entities offemodeling and development integra

At many customers, business modfirst version of model thanks to the

June 2010

tities

ependent on following an agile methodology, asal V-Cycle methodology. As a matter of fact, severaEntities using traditional approaches based on

rticularly efficient in supporting projects driven ths are based on the principle of iterative develorks at the end of each iteration. One iteration aftware presented to users is satisfactory enought.

ral attributes that prove to be very interestingogy:

ned into CodeFluent Entities immediately gener

to be defined upfront because the model can bithout losing any customized code,res can be chosen later in the cycle by simply

c customized code.

rs an iterative process for development because of ed process.

eling is started directly with users and quickly traopportunity of showing them generated user interf

one can easilyl projects havea preliminary

rough an agilepment, whichfter the other,to be put into

when used in

te executable

enriched and

changing the

its continuous

nsforms into aaces.


14/22

C. Recommended steps for b

In this chapter, we describe the ususing CodeFluent Entities.

The first three steps are focused o

can be quickly presented to users f

The second series of steps is morework, and which might be more de

Important note: As explained in thmethodologies, which means thoslevel. Instead, these steps are uconcentrating mostly on the Mode

June 2010

sic usage

al steps that we recommend for delivering best cla

n working at model level, allowing generation of p

r validation.

focused on developing custom code that will requiendent on target platform.

previous paragraph, CodeFluent Entities is very f e steps are not intended to be sequential at thesually sequential within an iteration, with theling steps.

ss applications

rototypes that

re a little more

iendly to agileoverall projectfirst iterations


15/22

1. Designing a first version

The first step with CodeFluent EntiIn this initial version, most entitiidentified.

This step formalizes the key businmajor structural elements for yoinheritance, one can describe any k

It is also worth noting that even duseful as it is often needed to have

Usually, these elements are very st

2. Generating components

Once business entities have beenspecific architecture relevant to thserver or even cloud.

Thanks to the CodeFluent Entitiesfirst executable version of the appl

This version can then be presented

Additionally, as CodeFluent Entitiepossible to use these early prototy

It is quite often that in customer sirelevant target architecture, espeversion.

Doing pure web is the natural trparticular the investment that is neapplication. So going for a web vera failure of acceptance test by user

When fully investigating the expeccombine :

A full web version broadldeployment challenges,

A smart client application f data and manipulate them

A mobile application with a

This is why we see very high valuemodel-driven approach.

Note: Similarly, a storage system ca

June 2010

of model

t ies consists in building an initial version of the fus and major relevant properties , including enu

ss entities relevant for your domain, their relatior application. Using a classical Entity-Relations

ind of business with simple concepts.

ta instances can be defined in the model. This prsome specific records in the database.

ble over periods of time that can last more than a

towards a first architecture

odeled in CodeFluent Entities, the architect usualbusiness: web, smart client, Office, SharePoint, tra

odel-Driven approach, the architect can immediaication that will implement the functional model.

to users so as to validate the functional elements

s allows maximum flexibility with target architectes to guide the architecture choice (or choices).

tuations, we see a relatively important challenge iially when those applications are intended to re

end, but usually the consequences are not fullyeded to reach the same level of ergonomics than aion without measuring the readiness of users, ma, which is the last thing a development team needs

tations of our customers, we often find that opti

y proposed to occasional users with the merit

or advanced users who need to work every day onith maximum flexibility and visual tools,

specific reduced feature set within identified scena

in being able to show results quickly with the Cod

n be chosen at this stage and possibly changed late

ctional model.erations, are

nships and theip model and

ves to be very

decade.

ly chooses theditional client-

ely generate a

f the model.

ures, it is also

n choosing theplace a legacy

measured, inreal Windowstranslate into

.

al target may

of minimizing

some business

rios.

Fluent Entities

r in the cycle.


16/22

3. Defining rules and custo

Once the major elements of the apcan be used to define the major rul

This mainly includes the ones th

advanced set of options to describe Existence rules, Basic format rules, More advanced format rule Integrity rules with options Computed properties.

At the end of this step, the busiincludes an important part of its co

Because the format used for storinresistant to future technology tren

4. Customizing data and le

Beyond the modeling of methods,data-access methods through:

Simple and intuitive CodeFl Custom views, Possibility to use native sto

Optionally, it is also possible to leve

Map naming to preserve ex Connect to legacy compon

5. Customizing business co

CodeFluent Entities embeds numeallows a significant level of definitio

Still, the philosophy of the productto introduce over-complicated mowhy CodeFluent Entities is designethe different layers. In particular,

custom rules or behaviors in the bSo this key step in implementing athe generated business object mo

June 2010

m methods

plication have been validated by users, the seconds and custom methods of the model.

t can be declaratively designed. CodeFluent Ent

:

s such as email for example,like Cascading updates or delete,

ess model , formalized as a CodeFluent Entitiese value , while being totally independent from tech

g this model is plain and simple XML, this makes its.

acy integration

odeFluent Entities proposes advanced mechanism

uent Query Language,

red procedure language where necessary.

rage particular options to:

isting legacy database schemas,nts instead of the generated database.

de

rous modeling concepts that simplify software den for custom methods and rules.

is that it is not possible (or should we say economeling concepts to deal with the most advanced usd to allow the classical implementation of custodeFluent Entities based applications usually con

siness object model, the central layer, to ensurepplications consists in developing the partial classel , in order to ensure the fulfillment of business re

agile iteration

ities offers an

odel, alreadynology.

very open and

s to customize

elopment and

ically relevant)e cases. This ismized code incentrate many

onsistency.s to completeuirements.


17/22

6. Customizing UI and repo

Though CodeFluent Entities comesinterfaces that can be used to maniscreens or pages that optimize the

CodeFluent Entities facilitates thispluggable to user interface contstandard controls delivered by MicInfragistics, DevExpress, Telerik or

Designing an optimal user interf flexibility , and this is why Codcomponents, while leveraging a sethe different supported architectur

Though customized user interfacsignificant portion of the screens"advanced usage scenarios", we wiusing templates.

CodeFluent Entities comes with anfile based on the principle of mixinServer Pages used to work before .this element is comparable to man

But it is even more powerful becaumodel available as an API, allowingin the graphical designer.

Additionally, the CodeFluent Entitiescape sequences, allowing an easperformance.

The Microsoft Office list producer Microsoft Excel and Microsoft Acce

June 2010

rts

with standard producers that directly produce opulate data, business applications usually require cusiness processes.

process by building a business layer and objectsrols available on the market. This approach wrosoft in the platform as well as all classical third-omponentArt.

ce for frequently used business processes requeFluent Entities developers usually assemblet of useful runtime services provided by CodeFlues (Web, rich-client, Silverlight, SharePoint).

s are generally needed, in many projects weonly require standard behavior and structure.

ll describe how one can automate the creation of

ntegrated template engine that allows the producthe text output with instructions that are execu

NET). Though being a relatively small part of Codecode generators that actually provide only this me

se the template engine is aware of the CodeFluentan easy leverage of all the elements modeled by

es template engine is RTF-friendly , as it deals corstrategy for Word reporting in your projects with

also provides a solution for integrated user interfass.

erational userustom-tailored

that are easilyrks well with

parties such as

ires maximumhe generatednt Entities for

see, usually ahis is why, in

user interfaces

ion of any textted (like ActiveFluent Entities,chanism.

Entities objectthe developer

rectly with thea high level of

ces in classical


18/22

D. Recommended steps for a

Though easy to start with, CodeFludemanding development projectsindustrialize the production of code

Though we recommend to implemwith the model-driven approach aachieved through advanced usage.

Most advanced usage scenarios incl

Multi-architecture scenario Dynamic modeling and patt User Interface automated g

June 2010

vanced usage

ent Entities actually includes very advanced featur. As it is a complete software factory, it offerat an unprecedented level.

nt the first project through a basic usage scenariod the product, on large projects, a huge leverag

ude:

s,erns,eneration.

s for the mosts solutions to

to get familiareffect can be


19/22

1. Defining multi-architect

Today, applications are usually desweb or rich web. Sometimes, thermobility. It is then often seen as an

In our view of software developmthrough our model-driven approaarchitectures, at least for part of th

For example, one could imagine for

Specialized business userflexibility,

All users in the enterprise Some scenarios will be dire

be deployed.

This kind of scenarios will be moversions if we anticipate a bit the fu

Using CodeFluent Entities, adding t

Adding new producers to g Completing only the code

2. Implementing dynamic

As explained in chapter 3, setting tThe good news with CodeFluent Eof powerful concepts at a later stag

The product being completely dtemplate-based approach explaineleverage effect: dynamic modeling .

Applying the template principlespatterns , an industrial way of adlocalization, tracking, text-based se

Whereas purely template-based gto templates of such a level of spaghetti code effect in Active SEntities for the production of t

hereunder.

June 2010

re target

igned for a specific architecture, such as client-serare specific extensions to support a particular scther version of the application.

ent, and also because it is made possible at a rch, future successful applications may often inm.

an HR ERP that:

will use a smart-client to manipulate data

ill access their data through a pure web-based self ctly integrated on mobile devices where the releva

e and more frequent, as well as their combinatiture.

ose new architecture scenarios is just a matter of:

enerate relevant components,arts concerned, especially customized UI .

odeling through patterns

e appropriate abstraction level requires to find thtities is that you can start very simple while gettie.

signed as an API , giving developers maximumd earlier can be applied to the model itself, bring

to the model itself, CodeFluent Entities allowsing behaviors to your entities. This includes behrch or any other custom need.

nerators are unable to combine these behaviorsomplexity that they are not maintainable (wellerver Pages), the different approach proposede business object model makes it industrial, a

er, rich client,nario, such as

asonable costlude different

ith maximum

-service portal,nt features will

on with cloud

right balance.g the benefits

flexibility, theing a powerful

you to defineviors such as:

ithout leadingknown as theby CodeFluents represented


20/22

Basic usage of the product alrea(which is not the case of manual ausage with dynamic modeling prowork with large models that compr

3. Defining UI templates fo

In many projects we see, thougsignificant portion of the screenstrue for back-office user interfaces

In that case, it is relevant to invest iUI and the common behaviors.interfaces as the one delivered in t

This way, the development and ma

For projects dealing with hundredwhole application cycle.

Thanks to the great flexibility of Cfor all user interfaces, using advatemplates. However, for complex sboth approaches, the architect bein

June 2010

y provides an economically viable solution overnd framework mode that we observe on the fieldide an even greater ROI for large projects that ase hundreds of entities.

r automated UI generation

customized user interfaces are generally neenly require standard behavior and structure. This

or management of reference date.

n a user interface template that will factorize the shis template will serve as a basis for the genee product.

intenance costs will not be correlated to the num

s of entities, this can provide major savings, espe

deFluent Entities architecture, this approach cannced product features, custom renderers and creens, it might be harder to maintain and this is wg able to balance the two at the optimal level for t

the long-termand advanced

re intended to

ed, usually ais particularly

tructure of theration of user

ber of entities .

cially over the

lso be appliedstom code in

hy we proposee project.


21/22

VII. CodeFluent Entities ben

Now that you understand why weusing CodeFluent Entities, let us givbenefit from it.

Scenario Without Co

Productmanagement orusers haveforgotten animportant propertyin an entity

You will needatabase scprocedures,business, seinterface la

Your application hasbecome successful.But the issue is thatyou now need tosupport 10,000concurrent userswith billions of records

You will neeadvanced pmechanismscreens andto propagatacross the l

Legal departmentnow requires you totrack all datachanges made bythe application

You will neespecific proplaces in thwhile evolvischema to sdata.

Users want to enterdata in a list modedirectly inside Excel

You will neespecific impintegrate M

All of your objectsnow need to respectcertain standardssuch as propertynames starting bythe entity name

You will neeelements ma tool to autprocess andthat your w100% right.

Your application hasbeen sold abroad,you need to support10 languages

You will neerespect of internationand find wadata in the

June 2010

fits through 12 scenarios

build CodeFluent Entities and how you can delive some classical example scenarios that will illustra

eFluent Entities With CodeFluent Entities

d to change theema, the storedmodify the

rvices and userers.

You just add the property tothe model and youregenerate. If your userinterface is custom, you simplyadd the property.

d to implementging and sortingon relevant

figure out howe the approachyers.

Leveraging built-in paging andsorting mechanisms of CodeFluent Entities, your workis limited to configuring themappropriately on relevantparts of the application.

d to hookessing at variousapplication

ng the databaseore the relevant

You just need to model thetracking data you need andimplement a pattern that willbe hooked in the businesslayer for all components onceand for all.

d to develop aort process toicrosoft Excel.

Using the Excel producer, youcan immediately generateupdateable lists that includechecking business rules.

d to rename allanually, or buildomate thetest it. It is likelyrk will not be

You can directly use namingconventions proposed byCodeFluent Entities and youwill get 100% compliance bydesign.

d to check the

lization ruless to localizingatabase.

Using Unicode types,messages for resources andthe CodeFluent Entitiesembedded localizationpattern, you will have asolution for allinternationalizationrequirements.

er applicationse how you will

Keywords

Model-DrivenConsistencyLayers

ScalabilityBest practicesConsistency

PatternsDynamicmodelingConsistency

OfficeproducerErgonomics

ConsistencyConventionQuality

LocalizationBest practicesPatterns


22/22

As part of apartnership withMicrosoft you nowneed to supportSilverlight

You will neeyour applicaarchitecturepoints suchcalls.

The application nowneeds to bedeployed onanother databasesystem

You will neewhat part ocode is speccurrent datreengineer tand potentimechanism(if needed).

Users want todeliver letters to

customers with dataextracted from theapplications

You will neeMicrosoft

a specific codeliver this

A new policychanges the rulechecking made on aproperty

You will neerule wherevpossibly botand the ser

Your last applicationhas been sosuccessful that youhave been asked toreengineer the 20year-old applicationto provide the sameergonomicsstandard

You will neeapplicationthough thebuilt over arepresentswork.

Investors haverequired yourapplication tosupport a cloudarchitecture withinthe next weeks

You will neethe differenavailable cloand possibldifferent veapplication.

June 2010

d to reengineertion for this new, including hardas asynchronous

Using CodeFluent Entitiessmart client object model,your work will be limited toconfiguring a new producerand adjusting UI elements.

d to figure outthe data access

ific to yourbase system,hose elementslly find a

to support both

CodeFluent Entities have beendesigned in a way to allowdifferent databasedeployment scenarios, whileoptimizing coding for eachRDBMS system. Only rawmethods that can be used foroptimizing specific processingneed to be revisited.

d to automateord or integrate

mponent toeature.

Using the Template producerwith RTF templates, you have

an immediate solution withcustomers being able to editletter templates in MicrosoftWord.

d to change thiser applicable,h on the clienter.

You add the constraint in themodel and regenerate. It ispossible to have rules checkedboth on client and server forbetter user experience.

d to redesign therom scratch,

odel has beendecade. This

huge amount of

Using CodeFluent Entitiesimporter on the databaseused for the existingapplication, you immediatelyhave a first model to startwith, that you can generate toquickly provide modernizedscreens for your application.You can reengineer theapplication progressively, byimproving the functionalmodel and working on thenew target architecture.

d to figure outcomponents of

ud architecturewrite a whollysion of your

Using CodeFluent Entities, youwill be able to generate themodel towards futureplatforms including cloudwithout writing a differentversion of the application.

ArchitectureSilverlightInnovation

Model-DrivenArchitectureOracle/SQL

RTF producerTemplates

Model-DrivenRuleArchitecture

LegacyImporterModernization

InnovationCloudArchitecture

soft fluent development white paper

Documents