Thanks to Sam for the useful comments. I was working from previous experience
where the models drove the development. The models where used to generate Java
skeletons and DDL to created the database, so the models had to be detailed.
I am joining the party late and still learning about the project environment
and application. I can certainly focus more on the high level class
relationships and add some comments describing their purpose. I am planning on
publishing the model in the Developers section on the Mifos website. I'll
start with the high level view first.
I would also like to be involved in modeling new functionality as the
application evolves.
Kevin Shea
----- Original Message -----
From: Sam Lee<mailto:[EMAIL PROTECTED]>
To: Developer<mailto:[EMAIL PROTECTED]>
Cc: Mifos Functional Mailing
List<mailto:mifos-functional@lists.sourceforge.net>
Sent: Saturday, January 12, 2008 11:01 AM
Subject: Re: [Mifos-functional] [Mifos-developer] MIFOS Object Model -
RoughDraft
Given Adam's comment that the diagram is meant to be primarily for developers
/ architects as a high-level guide to mifos architecture and data model /
domain model, I'd suggest:
1. stress more on expressing the relationship between major concepts
(typically packages and/or major top level Business Object classes)
2. stress less at detailing on the specifics, say, all the specific
attributes of a class, and in some cases, relationship between minor classes.
The reasons are that given the existing resources: a) functional
specification and related requirements documents, and b) the actual codes, I
found:
1) there is no easy entry point to understand the big picture and
relationship. The functional specification (and various wikis) helped a bit in
understanding the high level domain model / data model, but they are scattered.
That's why I'd suggest we have some diagrams are often helpful in documenting
those relationship at high level.
E.g., chapter 2 model overview could be expanded a bit to illustrate the
relationship between these major packages / classes.
2) if I want the specific details (down to individual attributes and business
rules), the existing functional specification and actual codes are quite
detailed.
Therefore, I'd say having diagrams that are so detailed has much less value.
Plus, the specifics are going to evolve anyway so more than likely, the info in
diagrams can't catch up with the real life changes anyway.
E.g., in figure 6 (customer classes internal), chapter 5 customer classes,
the diagram could be less detailed in terms of specific attributes.
For figure 7 (customer class external relationship), the relationship is
great; the internal attributes of the customer class is probably just a
distraction (too much details), and we might want to expand a bit more on the
relationship, e.g., the diagram says client, group, and center are all specific
form of customers. It'd be great to let readers know the difference between
them at high level (be it via comments, highlighting attributes of the specific
case, etc.)
- sam
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace_______________________________________________
Mifos-functional mailing list
Mifos-functional@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-functional
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Mifos-functional mailing list
Mifos-functional@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-functional
