File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes The order of drawing seq. and component diag.? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "The order of drawing seq. and component diag.?" Watch "The order of drawing seq. and component diag.?" New topic
Author

The order of drawing seq. and component diag.?

Duren Lee
Greenhorn

Joined: Aug 24, 2005
Posts: 29
Hi,friends.
I'm working for Part II assignment, and have already finished the class diag. but i'm confused that the order of creating seq & component diag, i should first create seq diagram, or first create component diagram?
Another question, in my projects, component diags was not often drawn, i don't know how to find out some components from class drag, but i know some components related to design pattern and some interfaces with external subsystem should exist in component diag. could you please help me to clear these questions?

thanks in advance.

duren


SCJP2,SCWCD,SCEA
Theodore Casser
Ranch Hand

Joined: Mar 14, 2001
Posts: 1902

I don't think it really matters which direction you go, in the end. I actually started with the sequence diagrams and worked back through to the component and class diagrams, but your methodology might be different.


Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 309
Originally posted by Duren Lee:
... should first create seq diagram, or first create component diagram?

Hmmm, both ;-)
In theory component diagrams (like deployment diagrams) are "implementation diagrams"and therefore might be drawn after design and before deployment.

On the other hand there is no better way to initially sketch the overall architecture than by a component diagram.

After the initial sketching in many business projects only class and no sequence diagrams are drawn at all.
Sequence diagrams are usefull if a) the behaviour is complex / technical enough or b) you intend to generate code (method signatures) from the interaction diagrams.

Class diagrams are drawn (or implicitely constructed from interaction diagrams in code generating tools) all the time, not before or after other diagram types.

Finally your customer will ask you to draw refined component diagrams for getting a chance to understand and check the design and its dependencies.


Originally posted by Duren Lee:
i don't know how to find out some components from class drag...

The main criteria for a component are:
- it is _plugable_ (like a plug&play feature for your PC)
- it is _replaceable_
- it decouples code for protecting it against code change dependencies.


Originally posted by Duren Lee:
... some interfaces with external subsystem should exist in component diag.

Not only with _external_ subsystems or components. Each component must provide at least one interface and may require zero or more services (interfaces) from other components.


Excurs concerning initial sketching above:
In UML 1.x I [ab]used deployment diagrams for showing a first raw architecture and took into account the given hardware nodes. That made many things clearer.
In UML 2.0 deployment diagrams components still may reside in the deployment diagram, but not within its nodes. Therefore since UML 2.0 I use component diagrams for initially sketching the raw system.
Remember that a component is something like an EJB-jar, a deployment descriptor other paackage-jars, a db table, an .exe or other _types_. In UML 2.0 deployment diagrams they now distinct between "deployment spec" (the above deployment descriptor) and "artifact" (the rest of the above types), i.e. physical things that really do not matter at design time. So for component sketching use component diagrams instead now.
End of excurs.

Thomas.


www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
Duren Lee
Greenhorn

Joined: Aug 24, 2005
Posts: 29
Many thanks Theodore,Thomas for good advice and detailed explanation :-)

Thomas, according to your definiation of the component, a DB table is one type of the component, in Mark Cade's book, for eg. 'customer','product', i think, they might be mapped into DB tables, but in the study case, why not 'product' and 'customer' display in the compoent diag.?

many thanks

duren


Originally posted by Thomas Taeger:

Not only with _external_ subsystems or components. Each component must provide at least one interface and may require zero or more services (interfaces) from other components.


Excurs concerning initial sketching above:
In UML 1.x I [ab]used deployment diagrams for showing a first raw architecture and took into account the given hardware nodes. That made many things clearer.
In UML 2.0 deployment diagrams components still may reside in the deployment diagram, but not within its nodes. Therefore since UML 2.0 I use component diagrams for initially sketching the raw system.
Remember that a component is something like an EJB-jar, a deployment descriptor other paackage-jars, a db table, an .exe or other _types_. In UML 2.0 deployment diagrams they now distinct between "deployment spec" (the above deployment descriptor) and "artifact" (the rest of the above types), i.e. physical things that really do not matter at design time. So for component sketching use component diagrams instead now.
End of excurs.

Thomas.
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 309
Originally posted by Duren Lee:
... a DB table is one type of the component ...

Maybe it is a matter of forign languages, but a db table is NOT one type of _the_ component.

Components may be types or instances, at compiletime or at runtime.

In Component Diagrams I show {compiletime | runtime } types.

In Deployment Diagrams I show runtime { types | instances }.

A Jar is a type many realtime instances may be created with.

A db tables is a type of many realtime rows/instances.


Originally posted by Duren Lee:
... but in the study case, why not 'product' and 'customer' display in the compoent diag.?

I would not mind showing them as components except if they are allready given/existing and therefore are outside of the system _to be developed_.

Thomas.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1178
Duren Lee,

You are absolutely right � the top three classes: order, product and customer are not shown in the component diagrams.

-- Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Duren Lee
Greenhorn

Joined: Aug 24, 2005
Posts: 29
Originally posted by Dan Drillich:
Duren Lee,

You are absolutely right – the top three classes: order, product and customer are not shown in the component diagrams.

-- Dan


Hi,Dan
In Cade's case, I think, the reason is that the technical decision SLSB+DAO was chosen,but not 'SLSB+EntityBean' or 'SLSB+entitybean+DAO'.
if 'SLSB+EntityBean' is chosen, i.e. 'CustomerEntityBean', it must be presented as one component since it can be packaged as ejb jar file according to Thomas' explanation.
Do u think so?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: The order of drawing seq. and component diag.?