sequence diagram to classes diagram transition
On identifying the usecases and their relationships in the sytem, we moved to sequence diagrams. Generally the sequence diagrams are the visual representations of the descriptions provided for each usecase.
Now the problem is how to derive classes from sequence diagrams.
It would be easier to identify the business object(generally nouns) such as product, order etc. But how to identify the classes that provide services? For example, we require a class with API to list , delete and add products.
How we can use the sequecnce diagrams to identify these classes?
I'm not sure what u mean by 'identify'
Such a class is represented in a sequence diagram just as any other class. a box on top wiht a lifeline below .. or to the right if you use a 90degree turned representation.
If your asking how a diagram helps to find such classes for your model, I am afraid the answer is 'not at all', or at least 'not much'.
On technique I like is to specify the responsibilites of a potential class.
If you come up with a few responsibilites per class, you are on the right track.
Classes with no or only one really small responsibility should be removed from the model.
Classes with many or unrelated responsibilities should get split in multiple responsibilities.
At the very end you can use sequence diagrams or collaboration diagrams to check how your classes work together to perform a use case.
regards
Spieler
> I'm not sure what u mean by 'identify'
>
> Such a class is represented in a sequence diagram just
> as any other class. a box on top wiht a lifeline below
> .. or to the right if you use a 90degree turned
> representation.
>
> If your asking how a diagram helps to find such
> classes for your model, I am afraid the answer is 'not
> at all', or at least 'not much'.
>
> On technique I like is to specify the responsibilites
> of a potential class.
> If you come up with a few responsibilites per class,
> you are on the right track.
>
> Classes with no or only one really small
> responsibility should be removed from the model.
>
> Classes with many or unrelated responsibilities should
> get split in multiple responsibilities.
>
> At the very end you can use sequence diagrams or
> collaboration diagrams to check how your classes work
> together to perform a use case.
>
> regards
> Spieler
Hey , Speieler again.
thanks a lot for the reply.
Seems there is gap in my understanding.I used the word "Identify" in the sense "to find out the classes".
So on building the Usecases , the classes have to be FOUND OUT from the USECASE DESCRIPTIONS and then draw sequecnec diagrams, to represent how the classes work together to perform the usecase. Sequence Diagrams have got nothing to do with idenfication of classes but they are to show the interaction between the classes.Is my understanding of the your answer is correct ?
regards,
sprasad
> Is my understanding of the your answer is> correct ?Yes it is
Let me share a different perspective here.
From the technical use-cases we can identify the candidate classes, using these candidate classes we draw the collaboration diagram as to identify the operations to be exposed out of these candidate classes. These candidate classes are later can be realized as such or as a subsystem having exposed through the interface.
If you have a subsystem, based on the decided design attributes we can elaborate it into more concrete classes, iteratively the elaboration can be done. This is the place typically using the design patterns and idioms we make the system more reusable and measurable.
I find this way of elaboration is much more useful because it gives a must better cohesive outcome, and also the scoping and planning the interaction between them is very simpler.
- Karthicraja
This iterative aproach sounds reasonable for systems, where you can't 'see' individual classes from the beginning.But I don't see the relation to the original question. You don't even mention sequence diagrams in your post.regardsSpieler
>Let me share a different perspective here
Hi,
The technique suggested by karthicraja provides more details about building classes . But hope this is not differing with the basic view that sequecne diagrams are for to find how the the classes work together to perform a usecase, but NOT FOR FINDING OUT the classes.
regards,
sprasad
Prasad, Sequence Diagrams are not meant to Identify Classes.
"Using these candidate classes we draw the collaboration diagram as to identify the operations to be exposed out of these candidate classes"
I wrote "collaboration diagram" instead of "Sequence diagram" my mistake :-)
BUT Sequence Diagrams can help you identify Association Classes, have you tried this?
- Karthicraja
Spieler,
I wrote "collaboration diagram" instead of "Sequence diagram" my mistake :-(
Please see my comments inline.
"If your asking how a diagram helps to find such classes for your model, I am afraid the answer is 'not at all', or at least 'not much'."
[Agreed, the purpose of sequence diagram is to identify behavior of the system over time]
[But you can find association classes]
On technique I like is to specify the responsibilities of a potential class. If you come up with a few responsibilities per class, you are on the right track.
Classes with no or only one really small responsibility should be removed from the model.
Classes with many or unrelated responsibilities should get split in multiple responsibilities.
[You are discussing about a big class designed first then broken down to smaller pieces, I guess this approach would mislead the designer with size as the parameter to break]
[I am recommending identify the subsystems and define their interfaces, this defines the scope clearly, then you can elaborate these subsystems to more manageable pieces again repeating the same idea]
At the very end you can use sequence diagrams or collaboration diagrams to check how your classes work together to perform a use case.
[Sequence diagram is a tool to identify the behavior of the system as to define the scope, I don't really understand what do you mean by "check how your classes work together" can you please elaborate on what is the outcome of this activity]
"Where you can't 'see' individual classes from the beginning"
[I disagree with you Spieler, in a larger system how do you approach this]
[Even to a simple system for example, I want to design a simple object cache system, with a design attribute stating ?many types of storing & retrieval required?, can you give me a design from the candidate classes for this, I am afraid you would miss out few]
These are the reason I put my perspective in the forum, but I guess I made it bit vague.
- Karthicraja
> "If your asking how a diagram helps to find such
> classes for your model, I am afraid the answer is 'not
> at all', or at least 'not much'."
>
> [Agreed, the purpose of sequence diagram is to
> identify behavior of the system over time]
> [But you can find association classes]
How is that? Maybe I am misunderstanding the meaning of association classes? They are the classes that provide additional information to a association, right? Please explain a little more
>
> On technique I like is to specify the responsibilities
> of a potential class. If you come up with a few
> responsibilities per class, you are on the right
> track.
>
> Classes with no or only one really small
> responsibility should be removed from the model.
>
> Classes with many or unrelated responsibilities should
> get split in multiple responsibilities.
>
> [You are discussing about a big class designed first
> then broken down to smaller pieces,
Nope, I'm talking about testing an idea and modifying it according to the tests. To small classes go away, making other classes bigger.
Large classes get broken down.
> I guess this
> approach would mislead the designer with size as the
> parameter to break]
> [I am recommending identify the subsystems and define
> their interfaces, this defines the scope clearly, then
> you can elaborate these subsystems to more manageable
> pieces again repeating the same idea]
Again: I completely agree, but what I described is just the
case, when you don't have subsystems, because the system is small.
>
> At the very end you can use sequence diagrams or
> collaboration diagrams to check how your classes work
> together to perform a use case.
>
> [Sequence diagram is a tool to identify the behavior
> of the system as to define the scope, I don't really
> understand what do you mean by "check how your classes
> work together" can you please elaborate on what is the
> outcome of this activity]
In many cases people come up with a set of classes, but when they actually try to implement these classes, they find functions that they need, but don't belong to any of the planned classes. So the methods end up being patched to the wrong classes. You can detect this kind of problem with sequence diagrams, because you can see if all the informations and algorithms needed for a use case are available.
>
> "Where you can't 'see' individual classes from the
> beginning"
> [I disagree with you Spieler, in a larger system how
> do you approach this]
You confuse me! Designing a large system, as well as in very complex systems you can't easily define usefull classes, so as stated I would do what you described before: Break the system down into subsystems until the subsystems become small enough for identifying classes.
>
> [Even to a simple system for example, I want to design
> a simple object cache system, with a design attribute
> stating ?many types of storing & retrieval required?,
> can you give me a design from the candidate classes
> for this, I am afraid you would miss out few]
To be honest, I wouldn't even start designing with requirements like this. My first step would be to go to the customer and ask her what she really wants.
How would you identify your subsystem from such a one sentence requirement?
I still think our approaches are really the same, at least on the level
we are able to discuss in this forum
regards
Spieler
Good we got something to discuss & learn
Our approaches are very similar, and the difference I guess is in the direction of the approach in the decomposition.
My opinion is that, any method can lead to a solution, but a good method is the one that makes even the ordinary person accomplish the best. This is like a reviewer with a checklist can do consistent than the reviewer without a checklist.
In my view, we are different in the way of decomposing the subsystem.
A)
> Classes with no or only one really small
> responsibility should be removed from the model.
I guess this is not necessarily true, just take an example of command patter, it just abstracts one or more related behaviors
B)
> Classes with many or unrelated responsibilities should
> get split in multiple responsibilities.
I guess point A and B is consequences of each other, I feel it is really difficult to establish a perfect equilibrium without compensating reusability, scalability, coupling, cohesion etc. I guess your approach is typically a bottom-up decomposition. This can produce unnecessary levels of detail.
--
In many cases people come up with a set of classes, but when they actually try to implement these classes, they find functions that they need, but don't belong to any of the planned classes. So the methods end up being patched to the wrong classes. You can detect this kind of problem with sequence diagrams, because you can see if all the information and algorithms needed for a use case are available.
[Great, I got your point]
--
An association class is a class that is connected to an association. It is a full-fledged class and can contain attributes, operations and other associations. Association classes allow you to store information about the relationship itself. Such information is not appropriate, or does not belong, within the classes at either end of the relationship. The analysis classes can have association classes is my point. Like for e.g. Producer and Distributor can have contract as an association class that would have separate attributes and operations.
--
Often the Research Team gets requirements like this from the engineering team for building reusable component libraries. Where you have to think about building a component that will be flexible enough to the future needs. To test how things can go lets build a cache system that is capable of storing and retrieving objects. The lifetime of the object can vary based on the needs; it can be time based, touch based or permanent, etc.
- Karthicraja
> Our approaches are very similar,
I agree
> and the difference I
> guess is in the direction of the approach in the
> decomposition.
I still don't see a real difference
> A)
> > Classes with no or only one really small
> > responsibility should be removed from the model.
> I guess this is not necessarily true, just take an
> example of command patter, it just abstracts one or
> more related behaviors
Yeah, of course you are absolutely correct. It is a rule of thumb, not
more not less.
>
> B)
> > Classes with many or unrelated responsibilities
> should
> > get split in multiple responsibilities.
> I guess point A and B is consequences of each other, I
> feel it is really difficult to establish a perfect
> equilibrium without compensating reusability,
> scalability, coupling, cohesion etc. I guess your
> approach is typically a bottom-up decomposition. This
> can produce unnecessary levels of detail.
1. It is not about equilibrium, it is about identifying classes.
2. If you prefer you can replace the text 'class' with 'subsystem'
The simple point is: a class/subsystem that does printing and also monitors the system is probably a bad choice and should be splitt in two classes/subsystems
3. I'm not talking about bottom-up or top-down or anything else. I am talking about finding classes (subsystems if you prefer) and finding hints if one made a good choice. not more not less.
regards
Spieler
After briefly scanning the posts allow me to throw my $.02 (US) in.
I teach a class on Object Oriented Analysis and Design, and one of the topic I spend a considerable amount of time on is the transition from requirements (Use Cases) to design (class, sequence, state). Here is a condensed version of how I guide my students through the process.
Usually teams that are new to UML and OO will have less difficulty with understanding "concepts" (classes) than they will with "interactions" (sequences). This being the case, I use any one of several methods recommended by Grady Booch and others as a means of harvesting possible "concepts" from use case documentation. For example, if I have a use case for a banking system that talks about "Customer", "Teller", "Deposit", "Account", etc., it's easy to identify potential "concepts" by using noun-phrase identification (if it's a noun, stick it on a class diagram).
Once we have a diagram set up with anywhere from 5-10 "concepts" we start to talk about the relationships between the concepts. If there are identifiable relationships between "concepts", it strengthens the case for them becoming actual Classes.
Next, we make the jump to sequence diagrams (I prefer these over collaboration for many reasons that I won't go into here). In this exercise we pick out a specific limited scenario (i.e. a customer comes in and deposits $100.00). From there I guide the class through the creation of the sequence diagram, helping them with the semantics, but allowing them to determine which class instances are used. 99 times out of a hundred they will discover that there are concepts missing from the original class diagram, so as soon as we identify a missing concept we go back to the class diagram and add it.
Once you have sequences that cover all of the functionality identified by the use case, you can go back to see which "concepts" were never used in the sequences. These concepts are then removed, and the rest will usually become actual classes to be built by the developers.
That's how I teach it for new teams. Now let me go over how I do it (being the design guru that I am ;-) ):
Right from the use cases I start with sequence diagrams. This is because I focus much more on the behavior that is needed, as opposed to the concepts that are going to implement that behavior (not that the classes aren't important, but the interactions are much more valuable). After identifying all of the interesting behavior for the use case in sequence diagrams I'll go back to the class diagram and bring in the concepts from the sequences. From that point I usually only have to add one or two additional classes (usually data-specific) during the development process.
The major difference between the approaches is the fact that when you are designing OO systems, you really need to focus on the behavior, but for those that are new to OO, this is very difficult. So you start with something that is more familiar (concepts / classes ~= E/R diagrams) and then use that as a means of defining the actual interactions to get work done.
Hope this helps,
Regards,
Jonathan House
