[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ormf-dev] Re: a couple of questions
|
Hi Barbara,
you seem to be very busy at the moment, nevertheless, I'd like to come
back to our subject of the ORMF model. I guess, your day project has
taken precedence. However, I am still looking for a way to contribute
and I would be happy if I could help on the model. Any idea on when you
think we can pick up this task again? Are there other tasks (modeling,
technical, or whatever) I could do to help you?
Cheers,
Wolfgang
Barbara Rosi-Schwartz schrieb:
Hi Wolfgang. Thanks for being willing to work on this!
Given our panic over the day project, as Joel mentioned in a previous
email, I would like to take a little time and think about how to work
together on the model and get back to you early next week. Is this
acceptable?
Cheerio,
B.
On 7 Nov 2008, at 11:34, Joel Rosi-Schwartz wrote:
On 7 Nov 2008, at 11:27, Ingenierubüro Ponikwar (ORMF) wrote:
Joel,
thanks for the quick reply.
You are certainly right, a point by point reply was not what I
intended to stimulate.
If Barbara is currently working on the domain model I'd be happy to
participate there if she doesn't mind.
I will let the two of you work out how best to collaborate. - thanks
Cheers,
Wolfgang
Joel Rosi-Schwartz schrieb:
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