• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

The order of drawing seq. and component diag.?

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1906
3
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Duren Lee
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Duren Lee,

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

-- Dan
 
Duren Lee
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Not so fast naughty spawn! I want you to know about
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic