Board index » delphi » Model-driven architecture outside of the enterprise?

Model-driven architecture outside of the enterprise?


2003-12-31 05:38:16 AM
delphi197
I've been watching the advent of model-driven architecture.
My big reservation is that I do small projects, either for small
businesses or single departments of large enterprises.
Although I may do a lot of work for one client during the course of a
year, it is still an accumulation of small projects.
So what I am looking for is upfront efficiences that result in
cost-reductions. The clients don't want to pay for long-range benefits.
My clients often say they don't have time to look at a model or
prototype or plan, and if they do, they do not discover errors at the
conceptual stage anyway.
It's all about bang-give them what they asked for cheap, then
bang-change it when they need more or realize they asked for the wrong
thing.
There are a few exceptions, and for these clients, I give them what will
actually produce the highest ROI for their businesses: sometimes talking
them into less than what they think they wanted and sometimes more.
These are the smart managers and business-owners, who focus on ROI on
the project including revenue-increases, staff-productivity and
software-maintenance, and not just software-development costs.
For the rest, it is mostly about competing on price. The fact that the
competition are flakes who won't be around next year to fix the problems
they created does not enter into the decision-making process, because
everyone is free to make the same claims of reliability and track-record
that I make whether their claims are true or not.
When MDA advances to the point of a 4GL where I define the app and the
app pops out, then there will be a productivity gain for me.
So, to the point: where does model-driven architecture fit into the
scenario described?
 
 

Re:Model-driven architecture outside of the enterprise?

Quote
>When MDA advances to the point of a 4GL where I define the app and the
>app pops out, then there will be a productivity gain for me.
When this happens, the model will be as complicated as the application. In
other words, this will never happen. Not in the forseable future.
Personally, for small applications I'd see more of a gain in using CRC
and Use Case analysis and use rapid prototyping and XP style refactoring to
improve productivity and quality.
Now if you can buy completely into a pardigm provided by a single MDA
enviroment such as Bold, you can see significant benefits. But with those
benefits come short comings. One reason I never liked Bold was that I had
to use Bold aware components for RAD. Bold should have been dataset aware
like Instant Objects.
My 2 cents,
Trevor
 

Re:Model-driven architecture outside of the enterprise?

Trevor de Koekkoek writes:
Quote
Now if you can buy completely into a pardigm provided by a single
MDA enviroment such as Bold, you can see significant benefits.
But with those benefits come short comings. One reason I never
liked Bold was that I had to use Bold aware components for RAD.
Bold should have been dataset aware like Instant Objects.
ECO is Interface aware - no longer restricted to specific display
components.
-Brion
 

Re:Model-driven architecture outside of the enterprise?

Quote
So, to the point: where does model-driven architecture fit into the
scenario described?
You get to feed more people. Also makes some clients
(mostly indoctrinated enterprise freaks) feel good.
Kostya
 

Re:Model-driven architecture outside of the enterprise?

Richard Grossman writes:
Quote
I've been watching the advent of model-driven architecture.

My big reservation is that I do small projects, either for small
businesses or single departments of large enterprises.
So, to the point: where does model-driven architecture fit into
the scenario described?
My thoughts - and I have not put these into trial yet, mostly
because I don't have Delphi 8 yet! <g>:
I am also paid to work on small apps. Generally, the smaller the
better, because big apps are never "finished". The difference
being I am on salary with the company.
ECO strikes me as having two advantages for me. One is the
modeling itself. I am in the "diagram it on a napkin or whiteboard"
school - people never understand from a "requirements document"
what it is they're talking about. Drawing a few simple pictures is
usually key, and often is the best requirements document I could
ever produce around here. Having a formal way to document these
pictures, and better yet having them updated and reproducible next
year for version n+1 will save me a lot of time, I think.
The second is the database maintenance. Most of my applications
revolve around databases - either consolidating from multiple
databases or persisting ancillary information into a database. ECO
offers scripts to evolve an existing database into a version n+1
database. Those scrips can be saved in a VCS and built into the
install package, so you don't have to manually figure out how to
transform the production database into whatever the test database
wound up looking like.
I do wonder how much overhead this is going to take. Too often,
the RAD prototype becomes the adopted application. On the one
hand, this is the wonder of Delphi, that a quick throwaway
prototype can be stable and robust enough to be the production app.
On the other hand, I can not take time to do it "right", good enough
is always going to be preferable on a time & money basis.
-Brion
 

Re:Model-driven architecture outside of the enterprise?

"Trevor de Koekkoek" <XXXX@XXXXX.COM>writes
Quote
Bold should have been dataset aware like Instant Objects.
Bold includes BoldDataset which is a TDataset descendant.
Regards,
Danny
 

Re:Model-driven architecture outside of the enterprise?

"Richard Grossman" <XXXX@XXXXX.COM>writes
Quote
When MDA advances to the point of a 4GL where I define the app and the
app pops out, then there will be a productivity gain for me.
I encourage you to take a look at Bold, if you haven't already. You make the
UML model, Bold generates the code & database and default forms - the app
pops out.
While these auto forms are not as polished as your client's would like, they
are still great aid during development.
Quote
So, to the point: where does model-driven architecture fit into the
scenario described?
I've been using Bold for almost 2 years now, and I am still impressed. It's
got so many features that I can not possibly list here, but I will try to
summarize:
You start with UML model, which you draw in ModelMaker or RationalRose.
Don't let the UML scare you if your unfamiliar with it, you only deal with
class diagrams, which are really simple. Bold will generate the code (class
declarations). You can then code the methods you have defined. OCL is of
great help here, and you will end up writing much less code. Database is also
generated by Bold (it supports Interbase, ADO, DBISAM, BDE) and it even
allows database evolution as your model changes. I already mentioned auto
forms.
The main advantage is the UML model and the separation of PD/GUI/DB layers.
This results in cleaner design and in turn allows better reuse, and
ultimately faster development.
It's not perfect, Bold is a complex beast and it takes time to figure out.
Expect to spend several months before you start being productive. There are
some bugs, not many, but without source they are a pain to deal with. Then
there's the issue of DCOM based n-tier support that everyone's complaining
about.
IMO the worst thing that happened to Bold is that it was bought by Borland.
Pre-Borland support was excellent and there were frequent updates/fixes. Now
it's all but abandoned and ECO is supposed to take it is place. ECO is
basically a complete rewrite of Bold, but is currently lacking in features
compared to Bold.
I encourage you to try it out, it is well worth the effort.
Regards,
Danny
 

Re:Model-driven architecture outside of the enterprise?

"Brion L. Webster" <XXXX@XXXXX.COM>writes
Quote
Trevor de Koekkoek writes:

>Now if you can buy completely into a pardigm provided by a single
>MDA enviroment such as Bold, you can see significant benefits.
>But with those benefits come short comings. One reason I never
>liked Bold was that I had to use Bold aware components for RAD.
>Bold should have been dataset aware like Instant Objects.

ECO is Interface aware - no longer restricted to specific display
components.
Aha! Very interesting. I will be upgrading to D8A in a couple of weeks.
 

Re:Model-driven architecture outside of the enterprise?

Brion L. Webster writes:
Quote
The second is the database maintenance. Most of my applications
revolve around databases - either consolidating from multiple
databases or persisting ancillary information into a database. ECO
offers scripts to evolve an existing database into a version n+1
database. Those scrips can be saved in a VCS and built into the
install package, so you don't have to manually figure out how to
transform the production database into whatever the test database
wound up looking like.
Interesting. I wrote this for myself several years ago.
When I distribute updates, the users download them and run the
installer, which runs the DMM (Database Maintenance Module), which
compares the new schema (database definition) with the one on their
computer, and updates their existing database to match the new schema.
Without this, I would have to manually update all those databases myself.
 

Re:Model-driven architecture outside of the enterprise?

:))
 

Re:Model-driven architecture outside of the enterprise?

Brion L. Webster writes:
Quote

ECO is Interface aware - no longer restricted to specific display
components.
If they could give it a more descriptive name (and mandatorily delete
the ugly 'E-word'), and for once try to actually *explain* what ECO is
and does (more than, or less than an integrated UML tool like e.g.
ModelMaker) - I'd be glad to listen.
As it stands now, 'ECO' sounds to me like or some sort of fancy
pseudotechnology to mix into your dough in order to impress your PHB.
Whereas I take it we're actually talking about a tool(set)?
It's offensively confusing.
--
Kristofer
 

Re:Model-driven architecture outside of the enterprise?

Daniel Mauric writes:
Quote

It's not perfect, Bold is a complex beast and it takes time to figure
out. Expect to spend several months before you start being
productive.
You've got to have a pretty solid understanding of need and benefits of
Bold before committing to such an investment in learning.
--
Kristofer
 

Re:Model-driven architecture outside of the enterprise?

"Kristofer Skaug" <XXXX@XXXXX.COM>writes
Quote
You've got to have a pretty solid understanding of need and benefits of
Bold before committing to such an investment in learning.
True, but you can not understand the benefits unless you spend some time
learning:) You may want to ask more specific questions at
borland.public.delphi.modeldrivenarchitecture.general
Most everyone agrees that Borland simply didn't market Bold enough (if at
all), probably due to the fact that they were working on ECO. This will
hopefully change, as I honestly think that ECO is the only clear advantage
over MS tools.
Regards,
Danny
 

Re:Model-driven architecture outside of the enterprise?

Brion L. Webster writes:
Quote

Drawing a few simple pictures is usually key, <...>
Having a formal way to document these pictures,
While I agree that a *good* diagram may reveal more about a system and
its specifications (or lack thereof) than a long list of requirements,
Unfortunately, once UML is used as a "methodology" instead of as a means
to document and//or promote understanding, diagrams of any nontrivial
software system quickly tend to degenerate into indeciphrable and often
ridiculously trivial assemblies of boxes and arrows, randomly
partitioned and/or formatted by the UML tool at hand.
The level of resolution and formatting required for clarity often
demands of the author the talent and ability to visually design and
filter e.g. a class diagram to emphasize the essential/characteristic
relationships and leave out the trivial/common ones. I have yet to
encounter a UML tool that offers any help at all in this respect. The
more "realism" you put into the model, the more trouble it becomes to
produce a legible and worthwhile (in terms of contents) diagram.
To give an example: In the design phase of my current project, I used
MagicDraw to produce a full blown UML model of the system - because our
customers demanded it. MD doesn't support Delphi code generation anyway,
so it was really just a documentation exercise. Now I found MD ok to use
(with some small side notes) but the trouble came when I started to draw
sequence diagrams showing interactions between components in the system.
Each major operation of the system consists of 10 or more major
sub-component operations. There are lots of timing constraints and
"wait-for" conditions. Recognising that the UML diagrams failed to
express what I wanted to communicate, I then re-drew the operation as a
GANTT chart using VISIO. This diagram became the single most
talked-about illustration in the whole document, and served as the
reference for all discussions on sequencing and dynamics of the
software. To me, this was a clear confirmation that technical UML
diagrams are often sufficient for effective communication of design
ideas.
--
Kristofer
 

Re:Model-driven architecture outside of the enterprise?

I'd like to expand on what I said,
It's easy to market visual controls, just put a screenshot of your nice grid
(or whatever) and everyone knows what it does, and pretty much how to use
it.
It's slightly more difficult with components like RemObjects, as you need to
explain what it does, and how we're supposed to use it.
Bold/Eco is very hard to market, as it is not something you can easily
explain. What's obvious immediately is that it is a complex framework that
requires you to change the way you work. This puts off most people before
they realize the benefits.
The only way to market it is to make a hype, something like MS has done with
.NET. Most people don't know (or didn't know) what .NET is, but were aware
of it, and that they're supposed to adopt it. In time they realize the
benefits, but it is the initial buzz that makes them think "Hey everyone's
talking about it, I better see what it is about'.
Regards,
Danny