Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II: Infastructure classes

 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From I what I read in this forum I get the impression that some people include not only business logic classes into the class diagram but also the infrastructure classes like ServletController, EJBEventManager, etc...
The notorious Sun Arch. Study Guide includes only business class into its case study (which is very similar to the Part II project) and that includes only 12 classes. Then I hear people saying they have 20-25-30 classes in their diagrams.
Where do they come from? Do we really need to draw MVC classes along with business logic?
Because I can only count at most 6-8 classes (+ 6-7 classes if you decide to extend Equipment and Seat) on top of BDM to describe the business logic. So I have 7 (BDM) classes + ~7 (other business, explicitely described by the spec) + 7 (that extend abstract classes in BDM).
Does that seem right to you guys?
Any thoughts?
 
Bagwan Mehrat
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gennady,
Your assessment of the number of classes that you will end up with is premature!
For example, what kinds of persistent or state information would you require to handle things like emailing status, keeping itinerary, handling payments? There's much more to the assignment than just the business model. Go through your use cases more methodically while seriously considering how each requirement would need to be designed and implemented.
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thats what I am talking about. The Sun guide case study omits all that. And since it's by Sun I assume thats what they expect to see. It has only the data-model related classes.
It only goes as far as |Customer|<---|AccontMngr|,
where Account manager has dependency relationship to Customer and handles all seconary tasks like persistence.
My question again: should I include things like MVC, persistence and state management, blah blah?
P.S. My vote goes againts all container managed tasks since they are implicit service by J2EE.
 
Seema Hanji
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
which study guide are you talking about ?
can you provide the link to that ?
Thanks,
seema
 
Bagwan Mehrat
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're asking for canonical answers to things that you are given freedom to decide for yourself. The deliverables stated in the assignment are the last word on what you need to submit, and we all got the same assignment, so you know as much as anyone else here.
In my opinion, I don't think it's necessary to add MVC components, but from the grading criteria, I don't think that points will be taken off if you do. I think that if people start seeing 30 classes, though, that's clearly more that required.
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's what I think may be the best way present a complete class diagram that looks simple and clear: make a set of class diagrams for every 'functional view' of the system.
This could include 1) general data model which is extension of BDM. 2) MVC diagram that explains integration of Web and Swing front ends into EJB tier 3) session bean diagrams for use cases 4) entity beans and their relationships...things like that.
If anyone willing to share what else they think is essential please do.

This thread might appear like i am talking to myself but it really is very helpful.
 
Kaspar Lund
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like to illustrate the architecture according to the following method:
Architectural Blueprints�The �4+1� View
Model of Software Architecture
It is located at: Architectural Blueprints�The �4+1� View
Model of Software Architecture
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
lund -
Welcome to JavaRanch!
We ain't got many rules 'round these parts, but we do got one. Please change your display name to comply with The JavaRanch Naming Policy.
Thanks Pardner!
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gennady Shapiro:
From I what I read in this forum I get the impression that some people include not only business logic classes into the class diagram but also the infrastructure classes like ServletController, EJBEventManager, etc...
The notorious Sun Arch. Study Guide includes only business class into its case study (which is very similar to the Part II project) and that includes only 12 classes. Then I hear people saying they have 20-25-30 classes in their diagrams.
Where do they come from? Do we really need to draw MVC classes along with business logic?
Because I can only count at most 6-8 classes (+ 6-7 classes if you decide to extend Equipment and Seat) on top of BDM to describe the business logic. So I have 7 (BDM) classes + ~7 (other business, explicitely described by the spec) + 7 (that extend abstract classes in BDM).
Does that seem right to you guys?
Any thoughts?

That is exactly what I was thinking when started my class diagram. But now, I have 3 class diagrams, 20 classes on the main (16 of them are related to pure abstractions, no EJBs, no DAOs, no VOs). A little hint: if you will look again in your assignment - you'll understand the system based on use-cases proposed by business analyst will never be able to live in a real world. If you want to make complete and liveable system, you have to extend it... One more hint: for a moment, stop thinking about seats/flights/itineraries - what about transactions/air park/employees???
Alex.
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bagwan Mehrat:
Gennady,
Your assessment of the number of classes that you will end up with is premature!
For example, what kinds of persistent or state information would you require to handle things like emailing status, keeping itinerary, handling payments? There's much more to the assignment than just the business model. Go through your use cases more methodically while seriously considering how each requirement would need to be designed and implemented.

Heh. If I will start putting all my value objects to my class diagram - it will turn into mess (at least, it will be much more than 50 classes)...
Alex.
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex, can you elaborate on transactions/air park/employees?
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Your message was edited since you quoted content from the actual assignment. Please read our policy on SCEA questions and refrain from discussing actual assignment issues.
Thank You!

[ August 13, 2003: Message edited by: Ajith Kallambella ]
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex, I understand your desire to be thorough, but don't you think you get carried away just a little?
There is no requirement for keeping transactions, keeping track of the fleet, maintaining HR records. The goal here is to satisfy user's requirements not to come up with your own. I think you are going above and beyond.
I am saying this from SCJD experience where you get penalized for elaborate system if simple is satisfactory.
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gennady Shapiro:
Alex, I understand your desire to be thorough, but don't you think you get carried away just a little?
There is no requirement for keeping transactions, keeping track of the fleet, maintaining HR records. The goal here is to satisfy user's requirements not to come up with your own. I think you are going above and beyond.
I am saying this from SCJD experience where you get penalized for elaborate system if simple is satisfactory.


I am carried away, but only a little. It's re-engineering of the former system. The system was working for years. That means that it had enough functionality to live in a production. The same functionality is required from our system, as well. There are no other ways to reach it without extending architecture. At least, I am showing that my system is rather extensible, even if this components will never be implemented.
 
Jaspreet Singh UK
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are getting too carried away.
You are an architect and being one you don't have to do a detailed design. If you do one then whats the point of designers. You just need to sketch out an outline that can be followed to provide designers with enough information to start fleshing the system out. Getting into the in and outs of how to store seat numbers is wrong but providing an ability to store seat number is correct.
My class design is small < 20 classes and shows no
methods or attributes.

Jas
 
Tom Wesson
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I happen to know a building architect who can prepare very beautiful drawings. However, he seldom go to construction sites and even have no idea how tall a 10" brick wall can be constructed to withstand its own dead load together with the wind load without horizontal stiffeners. His assistants and the building contractors often go back to him asking to change his design features here and there in order to make the blueprint buildable. All final buildings were never look like he originally expected.
Jas, just providing an ability to store a seat number without knowing how it works is no more for him to design a carefully dimensioned brick wall and its intersection with other walls/structures, but without knowing its performance.
He is still working as an adorable architect. Hey, what can you say?
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you guys are describing extreme scenarios on opposite sides of the spectrum. A good architecture design is probably somewhere in the middle. Too little detail and your design is vague and you developers may end up building solutions inconsistent with your design, too much detail means stiffness and huge constrain on developers.
 
Jaspreet Singh UK
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree .. my example was not really a good one ..
One problem i've had working on my solution was that
of complexity and where does architecture stop and
design start. Fine line/Broad line?
If you read Mark Cades book he seems to keep things
simple without delving into too much detail.
Hence no attributes or methods in the class diagram.
Jas
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again, common sense should prevail.
The spec says you dont have to include all class attributes and methods in your classes in Class diagram. This may imply they expect to see some details.
For examle, I think attribute paidStatus in Itinenrary class is appropriate, getter and setters methods are not.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic