Difference between extending BDOM and altering BDOM

[Parag Doshi]

I wanted to understand the difference between extending a BDOM and altering/changing a BDOM. Are there are guidelines which specify the ways in extending a BDOM? I understand the concept from a single class point of view. i.e. extending a single BDOM class to its various smaller classes (eg. Customer --> customer profile --> AccountInfo--> Address etc). But, I am confused when it comes to relationship with other classes. For example, if A ---- B are associated, can I have C which extends from A and then C--B association? Would this be extending or changing the BDOM relationship?

Using the same example, if A----B is in a 1-1 relationship and if I introduce C aggregates A (* - 1 relationship), then can I do C---B 1-1?

In the current assignment I have come across many relationships which I would like to extend but am not sure whether I am extending or changing the BDOM !

Any input would be appreciated.

Thanks,
Parag

[Ajith Kallambella]

I think you're slitting hair here by trying to distinguish between two terms. Don't worry too much about terminology.

Here are a few guidelines( that I follow )

When you modify(extending, altering, tweaking, reafactoring ...) the BOM, you must not change, contradict or render vague original relationships ie.,Boy has a shirt should not become The shirt has a boy

Be ware of profusion of classes. Every new class you create must have a role in the overall application design. Use a CRC technique to decompose the BOM so that you always end up with "collaborating" classes, and not "isolated" classes.

Be ware of impedence mismatch problem - don't think of persistence, tables and their relationships while designing your class model. Object design is governed by a different set of rules and grammer than designing a relational database schema. Designing your class model based on table structures rather than leveraging on the business domain introduces impedence mismatch.

Pay close attention to relationship modeling such as 1-to-many versus aggregation, relationship attributes, navigability(owner of the relationship).

Avoid prematurely introducing specializations/generalizations. Let them surface naturally during refactoring.

As long as you follow this rule of thumb, you are free to do anything you like.

If you have time, money and patience, I highly recommend reading "Object Oriented Software Construction" by Bertrand Meyer.

Good luck!

[Parag Doshi]

Thanks Ajith. Your suggestion and recommendations made a lot of sense and I shall keep them in mind while designing the class diagram.


Thanks,
Parag

[Tomi Tuomainen]

Originally posted by Ajith Kallambella:

When you modify(extending, altering, tweaking, reafactoring ...) the BOM, you must not change, contradict or render vague original relationships ie.,Boy has a shirt should not become The shirt has a boy

My SCEA instructions don't prohibit changing the existing Business Domain Model. If the use cases contradict the BDM why shouldn't we change that? Of course we shouldn't model anything that's not right. But we should describe the relationships so that it corresponds to reality and the basic structure of the system as well as possible based on all the information we have. If that can be achieved by changing someone's earlier drawn BDM relationships, I think we should do it.

Or this some Sun's hidden rule that must be obeyed (no matter how stupid it sounds)...

Tomi

[Parag Doshi]

Originally posted by Tomi Tuomainen:


My SCEA instructions don't prohibit changing the existing Business Domain Model. If the use cases contradict the BDM why shouldn't we change that? Of course we shouldn't model anything that's not right. But we should describe the relationships so that it corresponds to reality and the basic structure of the system as well as possible based on all the information we have. If that can be achieved by changing someone's earlier drawn BDM relationships, I think we should do it.

Or this some Sun's hidden rule that must be obeyed (no matter how stupid it sounds)...

Tomi

Tomi,
Yeah, what you say makes a lot of sense. Initially, it was very hard for me to accept that I couldn't make any changes to the BDOM relationships, but, now after going through this forum and my entire thought process during the class design, I had come to a conclusion that I would have to tweak the BDOM relationship, if I intend to create a architecture which meets the need of the requirements as understood by me.
Unless, there is an unwritten rule as you had mentioned. I wonder if anyone has been failed in Part II, just because he/she has changed the BDOM to meet his/her needs.

Does anyone know of any such instance?


Parag

[Frank Silbermann]

Originally posted by Tomi Tuomainen:


My SCEA instructions don't prohibit changing the existing Business Domain Model. If the use cases contradict the BDM why shouldn't we change that?
Tomi

Reviewing my instructions, I now wonder why I believed we were forbidden to deviate from it. It says we cannot ask the Business Analyst for more analysis, and that we must draw an architecture from what we were given, but does it actually say that the class diagram should be a superset of the BDOM?

Originally posted by Tomi Tuomainen:
Of course we shouldn't model anything that's not right. But we should describe the relationships so that it corresponds to reality and the basic structure of the system as well as possible based on all the information we have. If that can be achieved by changing someone's earlier drawn BDM relationships, I think we should do it.

Tomi

For example, the BDOM shows a 1-1 relationship between "flight" and "equipment." This would imply disposable aircraft, no? Even if we ignore that fact that the airplane has to _return_, certainly it is going to travel the same path on different days!

Recently, I read in a Rational OOAD training manual that the BDOM is one deliverable, and the class diagram is another deliverable. The class diagram should be motivated by the BDOM, but may disagree where disagreement is mandated by further analysis. This suggests that "not modifying the BDOM" is trivially satisfied merely by recognizing that the BDOM and the class diagram reflect different iterations of design!

It appears that Sun is assuming that we know something about the Rational Unified Process (or an equivalent development process). Yet, I am not away of any such process description in the recommended reading.

It seems to me that Part II requires quite a bit of reading far beyond that required for Part I -- not just a familiarity with the basic Gang of Four patterns but in fact a deep understanding of Core J2EE Patterns and development processes.

I found the lack of guidance quite frustrating. Perhaps Sun intends the exam only for experienced J2EE architects. That's quite different from merely modifying the original SCJA exam to emphasize EJB and Web technology rather than RMI and CORBA).

[Parag Doshi]

Originally posted by Frank Silbermann:


For example, the BDOM shows a 1-1 relationship between "flight" and "equipment." This would imply disposable aircraft, no? Even if we ignore that fact that the airplane has to _return_, certainly it is going to travel the same path on different days!

I think the 1-1 relationship is shown more on time bases. i.e. at a given point of time, a "flight" would use only one equipment (aircraft) to complete the journey. We can argue that there is a many-to-many relationship here, because a "flight" can use different equipments and the same equipment can be used by multiple flights. The question we need to ask is - whether there is a requirement in the system that needs that kind of information over time..i.e. are we required to store a list of all equipments which the flight operated on over time?
Thats my understanding of this requirement..and thats the criteria I have used to identify relationships between various entities. Because there are quite a few many-to-many relationships possible in this current model and I am always afraid to over-engineer a relationship than whats required of it.

Any thoughts on this? Am I thinking it right?

Parag

[Tomi Tuomainen]

Originally posted by Parag Doshi:


I think the 1-1 relationship is shown more on time bases. i.e. at a given point of time, a "flight" would use only one equipment (aircraft) to complete the journey. We can argue that there is a many-to-many relationship here, because a "flight" can use different equipments and the same equipment can be used by multiple flights. The question we need to ask is - whether there is a requirement in the system that needs that kind of information over time..i.e. are we required to store a list of all equipments which the flight operated on over time?

I guess BDOM is assuming that equipment is "disposal" so any information about the plane itself wouldn't have to be stored. On the other hand, for database integrity I definitely would create an equipment table and add foreign key in flight table (this prevents typos for plane information). And even if the requirements don't state anything, we must maintain flight information somehow and equipment participating in many flights makes a lot of sense.

But again... we are not supposed to think database structure since this is implementation "detail". But I think disposal equipment does not reflect the real business and is against common sense. So the big question is... should i do what Sun seems to like or go with my own opinions and try to defend them?

(We are talking about assignment details, "how"-questions again, but I hope that would be ok since we are just popping up more questions...)

Tomi
[ July 27, 2004: Message edited by: Tomi Tuomainen ]

[Frank Silbermann]

The equipment class could be needed so that the system knows which seats to include when creating a flight. (Presumably, this is done in some unspecified portion to be designed or implemented separately, or via raw SQL database inserts.)

Because an itinerary contains flight _instances_ (particular flights on specific days), and an airplane is used on more than one day's flight, the business domain model cannot be considered anything more than one analyst's flawed first stab at the problem.

It is taken for granted that nobody can get all the requirements or the design right the first time -- otherwise there'd be no need for prototypes and iterations in software analysis and design (OOAD).

A real architect would probably ask questions to clarify the requirements, but testing our ability to do this would be unmanageable and ungradeable. Therefore, we are asked to deduce what we think the business analyist _possibly_ meant when he drew his design. Perhaps our ability to recognize and make the needed adjustments is predictive of our ability to ask the right questions of the form: "When you wrote _this_, did you really mean to say _that_?".

I cannot think of any other explanation for the way they wrote the requirements. I just wish the Part II meta-requirements had been made more explicit.

[Parag Doshi]

Originally posted by Frank Silbermann:
The equipment class could be needed so that the system knows which seats to include when creating a flight. (Presumably, this is done in some unspecified portion to be designed or implemented separately, or via raw SQL database inserts.)

Because an itinerary contains flight _instances_ (particular flights on specific days), and an airplane is used on more than one day's flight, the business domain model cannot be considered anything more than one analyst's flawed first stab at the problem.

It is taken for granted that nobody can get all the requirements or the design right the first time -- otherwise there'd be no need for prototypes and iterations in software analysis and design (OOAD).

A real architect would probably ask questions to clarify the requirements, but testing our ability to do this would be unmanageable and ungradeable. Therefore, we are asked to deduce what we think the business analyist _possibly_ meant when he drew his design. Perhaps our ability to recognize and make the needed adjustments is predictive of our ability to ask the right questions of the form: "When you wrote _this_, did you really mean to say _that_?".

I cannot think of any other explanation for the way they wrote the requirements. I just wish the Part II meta-requirements had been made more explicit.

I had a couple of questions, which have arose in this discussion:

1.Do we need to show a relation to "unspecified portions" in our class diagram. For instance, where would the flight find out abt its equipment/seats for a particular trip? I am assuming (from this discussion) that a flight could use different equipments on different days. I understand from a database point of view that certain key tables will be populated with this information and would be retrieved by some joins/sub-queries while retrieving flights etc. Do we depict that relationship as we envision it in tables? I know its "implementation" related which shouldnt be brought out during class diagram, but I guess, I sometimes drift onto implementation aspects too.
2. Another thing which is concerning me is that as I think more and more about it, I see quite a few many-to-many relations...are others also seeing them or is it just me? I can give some examples, but not sure if that violates the forum rules..

any feedback would be appreciated.

Parag