• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Granularity of the UML diagrams for Part II

 
Cyrill Ruettimann
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have a basic question about the granularity of the class diagram, sequence diagram and component diagram. I have searched the forum for some time now but have not found the message I am looking for.

Speaking of architecture and the view model (for example 4+1) you choose to describe your architecture and the deliverables for Part II, I have some concerns about the granularity of the UML diagrams to deliver. Do they expect in the class diagram just the Domain Model (Business Layer) or all classes involved in the use cases starting by a JSF view, diving down through all layers until I reach the integration layer? So then it's more about design than architecture? Normally the class diagram to describe an architecture just contains the Domain Model. And the sequence diagram to describe an architecture shows the components (Boundary/Control/Entity) instead of the classes like in a design.

In the specification for the component diagram they specify to include the major components/classes. So I can then use the class diagram just for the domain model and include the classes like Facades/Controllers/Services used in the sequence diagram in the component diagram like I will do it normally to describe an architecture? This is also the approach stated in the course documentation for SL-425.


Which granularity have you chosen?


Thanks very much!

Cyrill
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's up to you, you need to decide as a software architect.
 
Victor-OE Cardona
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi Cyrill

I think the evaluators expect a class diagram with servlets, services, integration, domain model classes and their relationships.

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I am an evaluator, I want to *understand* your architecture and design, that is all.
And I believe everybody want to *understand* when read an architecture and design document.

There are many ways to make your document easy to understand, IMO you should focus on that aspect.
 
Cyrill Ruettimann
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

It was too late I think. I have now reread the first sentence and the deliverables are the architecture plus the design!

All clear now ...


Regards,

Cyrill
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Answers to questions about granularity and what should be in a diagram need to be put in the context of a software development process. In that sense your assumptions should include some detail about the methodology you're using. For example, the Unified Process is very specific about the kinds of artifacts that should be produced at various phases, or milestones, in the project lifecycle. If you make this clear in your assumptions the examiner can't really argue about what is, or is not, in your diagram.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jonathan Aotearoa wrote:For example, the Unified Process is very specific about the kinds of artifacts that should be produced at various phases, or milestones, in the project lifecycle. If you make this clear in your assumptions the examiner can't really argue about what is, or is not, in your diagram.

Hm, I am not sure, does RUP specify about level of detail in diagrams?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic