ECO ...add creativity...

apatheticyogurtΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 5 χρόνια και 4 μήνες)

92 εμφανίσεις


...add creativity...

Capture all the important facts in one place

An industry standard format


Exact and no room for misinterpretation

10 years after the fact you can still read it as if
you had only written it last week

Do not optimize your language by reducing the
number of words

It is a beautiful thing to communicate; why make
it harder than it needs to be?

Your developers talking to stakeholders using
the their own lingo is essential to avoid

After all you are considered the expert, make
sure you are understood; learn the lingo and
stick to it throughout the project, in the model,
in the code, in the documentation, in the db

Database technology is mature

As long as you keep in the middle of the
feature stream you can switch as you go

Database manufacturers want to lock you in

make sure you keep a key to get out when
you want

Changing requirements is not necessarily the
sign of an indecisive client, it is you getting
more information

Tools like model evolution help you to feel
good about new facts

Do not worry, the rapid fluctuation of
requirements wears off as you home in on the
truth; once there you are robust

You do not have to maintain the database

You do not have to add extra fields to handle
ordered relations

You do not have to write the domain objects
with all their properties and associations

You do not have to write any persistence

You only need to solve domain specific issues,
more with your brain than with your fingers

Everyone agrees; keep business logic out of
the UI since it makes the logic hard to reuse
and maintain

The domain layer is largely maintained for
you, just fill in your own behavior code

Where should we place the physical tiers? You
are free to choose!

How should we communicate between tiers?
Again you are free to choose

Scrum & XP states that building software is a
chaotic process and only fools try to predict
everything needed to reach the yet to be
determined goal

But at the same time you will end up with
crap if you do not have a plan or architecture

Trust the framework for architecture and the
chaotic process for requirements

Both ends of associations are always maintained

Change state is tracked automatically

Lazy & eager load control

Association objects with lifetime control

Standard .NET model view pattern

Search domain layer with OCL

Search database with OCL

Subscription mechanism to catch and react to
domain layer changes

Domain layer transactions clears up ”execute &
verify” code

All professional apps have undo & redo

”It is not a problem to add it, but it will cost

Luckily the bluff is seldom called

Undo & Redo requires a good domain layer

We make no assumptions regarding UI in the
domain layer

We offer clear and easy access from all the UI

Statefull & stateless models are supported

You have a legacy database already

Reverse it to a model

Shift focus and develop the model instead of
the database

You can start a system based on the model


Debugger with OCL

State diagrams enables you to ”draw logic”
with triggers, transitions and guards

Transitions can have effects and update
properties and create objects

Derived attributes and associations give you
easy to read code

Ability to use the same data in different
aspects while keeping a normalized

Automatically maintained with subscription
and lazy evaluation

To keep old things fresh you will need to

With less man hours invested in the old code
and fewer expected man hours in the new
code you are more likely to actually do it

Support for model level refactoring

What is the business value of having the
human factor near the things we all agree on
and just expect to work?

are lousey at routine tasks; they will
always give it the ”personal touch” = bugs

Patterns of Enterprise Architecture (Martin
Fowler) sums up the basics

There is nothing controversial here

There are choices, we expose these as

Parent or child map inheritance

Optimistic locking or not

Type on persisted identity

To speed up unit testing you will want to
replace the persistence layer with a mock

The Service design pattern puts you in full

Add your own services

Replace existing implementations

Hand on heart

are you good at endless
repetitive tasks? Do you have the same
precision as a machine?

No more persistence or association bugs

Attributes that do not persist as expected

Associations set and saved, but fail on load

Cascading deletes that do not cascade

Domain bugs are left up to you

infrastructure bugs

Development should be a creative process

You turn user requirements into tools

Stay clear of all the old ways of working that
could keep you busy without knowing what
the supposed business value was

It works for developers using all .NET languages, but we
have templates for the following:



Prism (Delphi.Net)

Persisting their data in one of




Firebird, Nexus, SQLite, Xml

An open API to add more

It will increase quality

Your resources can be focused on the domain

The gaming industry has accepted game
engines ; and they live and breath
performance. Do you honestly believe we
have higher needs?

A normal part of the development cycle is to
isolate bottlenecks and deal with them, now
you will have more time to spend on this

Imagine the software developers at the
starship Enterprise from Star
Trek. Do you
think they hack persistence code by hand?

Good tools are addictive

After using ECO you will never consider using
a less competent tool again, let alone no tool
at all.

We will give you your money back if you are
not satisfied (...Yes we will require the tool

Think about it; your investment is creativity
and knowledge

kept in the industry
standard UML format
> safe

Your behavioral code that uses the terms and
facts from the model
> safe

Investments made in UI design

all .NET
pretty safe

Was the future ever this bright?