[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ormf-dev] Re: a couple of questions
|
Wolfgang,
Thank you for this, it is certainly a wake up call for what Barbara
and I have NOT yet got across to the team. We now need to rectify some
of this deficiency.
I am not going to reply to your queries point by point today; in fact
I am not sure yet how much value there is in a point by point reply in
general. I want to ponder this a consider what is the best way to
start setting this straight.
What I do want to assure you is that B. and I have put a great deal of
thought and effort into the domain model while developing Useme. The
problem is that much of is only documented in our minds and embodied
in the code. Not the easiest way to transfer knowledge :-)
Barbara is, as I hope everyone realises, working on a new domain
model. This will be documented, reviewed, critiqued and evolved over
the next couple of months. The reason we are also talking technical is
because we have a legacy implementation (Useme) that does represent
(at the GUI level) many of the concepts that we are hoping to part of
the framework. It was our opinion that there is "marketing" value in
having this be available as early as possible in order to garner
community interest and support.
Would you like to work with B. on the early versions of the domain
model?
Cheers,
Joel
On 6 Nov 2008, at 15:43, Ingenierubüro Ponikwar (ORMF) wrote:
Hi Joel,
thanks for your clarifications.
I have looked at the Useme model (ormf.shared.model package) but
still got my problems understanding what it is all about.
Unfortunately practically all classes lack documentation completely,
so I find myself guessing...
Let me try in my own words.
Basically every model type is a model element, sharing a set of
attributes and operations. OK, I got that.
I then find "DocumentInternal" types and a "DocumentParcel", which
seems to be a "Document" by itself, such as a "Glossary", "SRS" or
one of the other subclasses. However, how dos "Actor" or "UseCase"
fit in here? The "DocumentInternal" types are all pieces of a use
case description plus some additional elements, which seem to go
beyond a single use case. I do not see a "Document" type, why?
On the general structure I find a Project, but it doesn't seem to
encapsulate what I would expect to find under a project. It more
looks like a helper class to technically manage a collection of
documents and some server communication.
There is also the "AbstractCollection" type with its subclasses
UmlPackage (ok, I know what that is) and "Folder". So, these
collections are there to group model elements, I guess. What groups
those elements together to form a document, such as the "SRS" type
from the model? Or don't we have "documents" at all? We should have,
in my opinion, and it seems we have something likely by the "LOV"
class. I have no idea what "LOV" means, but it seems to represent a
DOM node - a part of some document model. Another question: why do
we have this dependency in the core model? Or is the DOM model
integral part of the ORMF "documents"?
What I am missing completely are "requirements" in any form and
general relationships. (BTW is this the "job" of the
RelationshipService from the architecture diagram?)
Maybe I am completely off here, but I expected find something
different as "core" model. I was actually expecting to find some
familiar elements and relationships I would associate with RM
activities. But maybe I'm just not getting the point. I understand
we must find a balance between generic and concrete. If we are too
concrete, we will unnecessarily narrow ORMFs application, but if we
are too generic the whole framework may be useless (who needs just
another application server?).
Please don't get me wrong here, this is no criticism of your work, I
am just having a hard time figuring out what we are doing here. I'm
so used to have a sound domain model and an operational concept
(call it a vision, business use cases, or whatever) to understand
what I'll be doing before I go into design or into the code that I
feel a bit lost here.
I must admit I am relatively unclear about what we want to achieve
with ORMF. Most of what I see in the architecture diagram is
infrastructure (reporting, update, authentication, persistency,
configuration, administration), only some services seem to relate to
RM (project, collection, document, relationship and LOV) - but I
have no clear understanding what those elements are all about.
I might have missed too much over the last couple of months on ORMF,
but I don't understand why we are spending time on a GUI testing
approach if we (or is it just me?) have no clear idea what the GUI
is to be used for. We are discussion technical problems and
libraries (which Eclipse lib goes with that approach) and other
things, but I am still missing the point.
What is the value ORMF will bring as opposed to any other
application server? Why do we believe there is value in what we are
doing? I thought, it would be the domain or data model. It would be
the integration of currently disparate aspects of RM. It would be
the seamless concept, allowing to work fluently from concept to use
case and further on to requirements. It would be the flexibility on
how to group, collect and present the requirements and the ease by
which one can manage change.
Instead we are talking about GUI tests, about how to solve technical
problems (OSGi, etc.), about components to be developed.
I may sound snobbish, but I feel we are not doing the right thing
for the time being. There will be a lot of tech talk, testing and
prototyping, but it will be after we have built our foundations.
After we all understand what we are going for, after we have put
down, discussed and agreed the requirements and expectations we have
on ORMF. After we have a common view on what makes ORMF stand out
from the many server frameworks.
I have read the ORMF proposal but for my own understanding there is
a too large gap between that high-level vision and the component
model Barbara presented in the architecture diagram.
Maybe we should take more care for our own requirements building a
requirements management framework?
Or am I just barely wrong?
Could you please bring some light into my darkness?
Cheers,
Wolfgang
Joel Rosi-Schwartz schrieb:
Hi Wolfgang,
On 5 Nov 2008, at 20:05, Ingenierubüro Ponikwar (ORMF) wrote:
Hi Joel,
some quick statements after my first run through the software
(just to help me see the picture):
All code represents UseMe and not what is proposed for ORMF,
correct?
Yes. I have started breaking these out into components, but I am
not quite ready to check them in yet.
That said, the whole architecture diagram does describe what
should be, with only limited representation in the code, also
correct?
Correct again.
If this is the case, going bottom-up from the code will not be of
much help finding out what to expect from each of the proposed
components, their interactions and dependencies in my opinion -
what do you think?
Actually this could be done, because the components actually map
fairly well to existing EJB Stateless Session beans. But the effort
may not be warranted. I will leave it to ponder further.
Maybe it's just myself - I like to see the picture, its structure
and composition before looking at each pixel. Assembling an
unknown image from individual pixels is hard and error-prone work,
to re-use this metaphor.
True enough.
Maybe I 'll start with some words about each of the proposed
components using Barbaras document on the architecture? You could
add to it and over time we'll assemble something like a set of
requirements for each component. At least I will feel better, once
I understand each component's resoponsibility and how everything
fits together.
This would be a very useful start.
Cheers,
Wolfgang
Ciao,
Joel
