From: H. S. Lahman on
Responding to Js...

> But still, it is little tricky not to consider technology choices
> available, esp technology that are proven and have longer shelf life
> than others, for building such systems. This becomes more relevant
> when we are talking of softwares with some specific requirement, like
> distributed, heterogeneity, Realtime, longevity etc.

I think it depends on where the observer is standing. B-)

In a translation shop one can provide an OOA model that fully resolves
all functional requirements and is fully testable for those
requirements. Such a model will not even <directly> identify distributed
boundaries, much less the technologies needed to communicate across
them. That's because translation OOA models need to be independent of
the computing environment to avoid the review team burning the designer
at the stake. One can then turn that model over to an MDA transformation
engine that will do full code generation for a particular computing
environment and will optimize for the specific technologies available there.

For example, probably the single most important architectural activity a
Systems Engineer does for a large project is define logical partitioning
of the system. That can be done at a very high level of abstraction
during OOA in a UML Component Diagram that is completely devoid of
technical detail. But that logical partitioning (subject matters, levels
of abstraction, flows of requirements) will drive distributed boundaries
and interface/communication strategies.

Even if one is doing manual elaboration development, in the OOD one
addresses nonfunctional requirements at the strategic level. So the
architectural decisions are around things like caching, memory
management, and distributed messaging strategies. One really doesn't get
to tactical design decisions like DCOM vs. CORBA until one implements
the OOD strategies during OOP.

[An oversimplification because the Systems Engineer/Architect is likely
to decree what technologies will be used much earlier in the development
cycle based on other factors than just functional and nonfunctional
requirements. Some would even argue that specifying a technology is a
nonfunctional requirement driven by the development environment (e.g.,
existing developer skills, tool costs, existing hardware and software,

There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
Pathfinder Solutions
"Model-Based Translation: The Next Step in Agile Development". Email
info(a) for your copy.
Pathfinder is hiring:

From: xpyttl on

"Phlip" <phlipcpp(a)> wrote in message
> Dmitry A. Kazakov wrote:
>> No, you can't sell TDD here.
>> Let me try to explain why.
> I stopped reading here.

as he covers his ears and sticks out his tongue -- nya, nya, nya


From: Johnny Willemsen on

> Thanks for the suggestions so far - the only really new one is Ruby on
> Rails, which I
> I had not considered for this type of system. I know very little about
> it, but the Ruby on Rails website
> states "Rails is all about infrastructure so it's a great fit for
> practically any type of web application Be it
> software for collaboration, community, e-commerce, content management,
> statistics, management." So
> it never struck me as as relevant. I may be wrong.

We as Remedy IT have a CORBA product available for Ruby, see With that solution we can also use and implement CORBA in


From: Markus Elfring on
> There's a couple of years detailed design yet to go.

Would you like to look at recent design methodologies to avoid any pitfalls?

From: Phlip on
Markus Elfring wrote:

>> There's a couple of years detailed design yet to go.
> Would you like to look at recent design methodologies to avoid any
> pitfalls?

You total process zealot! Don't you know that one size doesn't fit all, and
that many great _heroic_ projects have been delivered, on time and under
budget, with pure Waterfall??!