Different diagram for Analysis / Design?

[sim_sim]

Hi All,

Are there different diagrams for Analysis / Design phase within project.

For eg. i saw that in Analysis phase some people make use of the boundary object, but in case of Design phase they use the object ?

Any commnets?

rgds,
Seema

[thomaskilian]

What do you mean? Different diagrams (you first paragraph) or different contents (2nd about boundaries)?

[Tuser]

Short answer; Yes.

In the Analysis (Specification) phase you should create your domain model, being a technology independent model of your system. Define interfaces and behaviour, but not the internals. Show overview of the system and connections, i.e. analysis diagrams.

In the Design phase you implement your components identified in the Analysis. Much more detail, and realization specific (do you have 1 or 2 component? Who does the archiving?), but is constrainted by the Analysis model.

The idea is that you can reengineer the details of your system without destroying all domain models; the Analysis model stays the same, the design changes. See example below



Analysis (top frame); The system is specified. One interface is provided.

Design (two lower frames); the system is designed (implemented) in two different approaches. Both meets the constraints of the analysis model.

Secondly take a look at Viewpoints to seperate the concerns of your models. There are no standard set of viewpoints; typically they are specified as part of a UML profile, specific for a domain.

But look for example as SysML. This is not so much seperation of Analysis/Design, more typically into (notice that to confuse everybody, different domains uses the same viewpoint name to specify different concerns)
- Information. Type specification.
- Functional. Abstract, technology independent model of your domain. Typically shows classes, components and their connections.
- Enterprise. Requirements.
- Communication. Used to model specific protocols, such as HTTP.
...

[jeshaw2]

I would suggest that you focus more on what is said by the model, than which modeling elements are used to say it.  

Business requirements should focus on what the system needs to do, and not how it does it.  I recommend looking at OMG's MDA and its corresponding CIM and PIM techniques.

[Tuser]

I would suggest that you focus more on what is said by the model, than which modeling elements are used to say it.

Can these two things be seperated?  

The elements used is an important indicator of what is meant. When I use a Interface modeling element in a structual diagram I indicate some very specific meaning in the desgn. Yes, you could take a normal class, but I wouldn't. Would confuse the meaning.

[jeshaw2]

Can these two things be seperated?

Apparently they can be seperated, if you go back to the original qusetion on this thread.

One may approach UML from two perspectives:  1) How do I draw a correct set of UML diagrams; and, 2) How can UML help me to communicate my thoughts to someone else.  Accomplishment of #1 (assuming one can figure out just what that is) does not guarantee acomplishment of #2 (effective communication).

My recommendation is to take the perspective of #2 and use UML where it is helpful.  If you use UML, stay close to the OMG standards; but those standards are incomplete (as evidenced by their work on UML 3), so some creativity is allowed.  It is more important to get your points accross to your readers than to be absolutely correct with the grammer.

[Tuser]

My recommendation is to take the perspective of #2 and use UML where it is helpful

I completly agree. Martin Fowler seperates the usage into sketch ('nice picture'), blueprint ('skeleton specification') and programming language ('MDA style'). I would always focus on the sketch, then move on to the blueprint.

My point is, that at some point the usage of the correct elements/diagrams will help you get your message across, i.e. the HOW supports the WHAT.

The wrong HOW will actually sometimes overshaddow the correct WHAT, i.e. people will get confused with your unorthodox style which you thourght would help bring the message across.

Apparently they can be seperated, if you go back to the original qusetion on this thread.

The original question was diagrams for analysis and design and thats very much a HOW question.

sim_sim didn't say much about seperating the HOW and WHAT; that all came from you... as a good advice which I would surely suggest to follow.

[ronnie]

Apparently they can be seperated, if you go back to the original qusetion on this thread.

One may approach UML from two perspectives:  1) How do I draw a correct set of UML diagrams; and, 2) How can UML help me to communicate my thoughts to someone else.  Accomplishment of #1 (assuming one can figure out just what that is) does not guarantee acomplishment of #2 (effective communication).
 
My recommendation is to take the perspective of #2 and use UML where it is helpful.  If you use UML, stay close to the OMG standards; but those standards are incomplete (as evidenced by their work on UML 3), so some creativity is allowed.  It is more important to get your points accross to your readers than to be absolutely correct with the grammer.

Absolutely - in the same way that we use 'English' to communicate these ides and there are many ways we can structure the arguments, points, premis', ideas etc. there are many ways that we can structure and present a model .

She may even sperll things wrong and use the wrong sounds in places but the dreams still get talked from us to them!

This is a concept that I am having difficulty getting accross in my team - there is a push to use UML and I have got everyone excited about EA but there is still a lot of questions along the lines of "How should I show X" and I answer with examples of similar shapes and patterns from books and previous works that do something similar and might show the answer in different ways.

Very rarely (in fact never) is the answer "In order to model X, draw these boxes and lines....."

Ronnie