What's the difference between sequence diagrams and scenario diagrams in UML?
I think you mean System Sequence Diagram (SSD) and Sequence Diagram.
The purpose of SSD is to illustrate a particular use-case scenario in a visual format where the system appears as a black box.
Sequence Diagram, on the other hand, shows how system objects interact over time for achieving a particular scenario of a use-case.
"Scenarios" per your link aren't diagrams, they're narrative text. They're also called "Use Case Narratives" among other terms. They are approximately equivalent to other behaviour specifications (sequence diagrams, activity diagrams).
There are generally three differences:
Format. Scenarios are textual, sequence/activity diagrams are, well, diagrams
Content. Textual narrative is often used to describe the sequence of interactions between the user and the "system" in Use Case descriptions. Hence there are usually only two participants (User & System). In contrast, sequence diagrams are primarily used to show how behaviour is distributed among objects. Consequently there will usually be more than two participants.
Formality. Narratives are often used earlier in the cycle to get an idea of what's needed. Consequently they're often less formal than Sequence diagrams - which typically show inter-object messages ("method calls").
For examples of tools that do this, take a look at websequencediagrams.com. Or search for "free UML tools".
There is no diagram type called scenario. Maybe you are thinking of collaboration?
Sequence and collaboration diagrams are actually the same: the Sequence depicts the chronology while the Collaboration depicts the interactions between the collaborators. Together (a tool that was around a decade ago) used to let you literally just change the setting and see the diagram in the other mode.
I use OmniGraffle (Mac). It's great for class diagrams. Has support for Sequence diagrams but not Collaboration.
Related
I discuss with my friend our project and we are in a way to draw the sequence diagram ( UML 2).
He told me that the sequence diagram is drawn by the use case. It means that for each use case we should draw a Sequence Diagram.
Is it correct ?
Thank you for any suggestion.
Well, taken as dogma it is not correct. A sequence diagram (SD) shows the behavior of objects in the way they interchange messages (and also if needed their lifetime and some minor additional information). You "can" also use a sequence diagram to describe scenarios in use cases. But simply speaking, a SD is more technically oriented (class design/programmers) rather than business (business design/stakeholders). To visualize a use case scenario you're better off using activity diagrams (AD). And even better if you dive into BPMN (which brings ADs to a new level).
It is possible though, to convert ADs to SDs and vice versa without information loss (if you forget about the afore mentioned bits and pieces).
Now another point: you will not necessarily need a diagram for each use case. I found that often use cases are more easily (and even clearly) described in a textual way (see Cockburn or Bittner/Spence) rather than diagrammatically. Especially if you have UC scenarios that are very linear in their single actions. So you can leave out the AD for those and just fall back to simple text. You should further avoid describing UC scenarios in both ways (i.e. text and diagram) as this introduces unwanted redundancy (means you would need to maintain always both when changes happen; and they happen often; and people are lazy -> so which one holds the truth: text or diagram?).
Generally, as Thomas points out, use case detail is set forth in an activity diagram. As he also mentions, a use case scenario would use a sequence diagram, when necessary. A use case scenario is a single path through a use case.
Sequence diagrams aren't good at diagramming multiple simultaneous behaviors and multiple decision points, and use cases generally have both of these features in their behavior. Activity diagrams do these things very well. A single path through a use case, by definition, doesn't have simultaneous behaviors and decision points, so a sequence diagram is more appropriate.
Googling "use case scenario sequence diagram" gives a number of links that explain the use of sequence diagrams for use case scenarios in detail, of which this is an example.
UseCase is declaration of behavior (service or usefull behavior) of system which is executed by system with collaboration (interaction) with system's actors.
Any type of diagram defined in UML could by used to describe behavior on any level of abstraction. All of diagrams could be also used to describe both business or technical aspects of system.
UseCase is declaration of behavior, it means that UseCase does not define behavior at all. UML does not define scenarios of UseCase ,scenarios are usually defined in methodology not in UML.
If you need to describe behavior of system in context of UseCase you can use some of behavior diagrams defined in UML for each UseCase.
According to UML context diagram context diagram doesn't exists.
So my question is which one of UML diagrams is good to show something like this and how to paint this?
I've just found the following definition: http://en.wikipedia.org/wiki/System_context_diagram
That's probably what you need. :)
A context diagram defines a boundary between the system, or part of a system, and its
environment, showing the entities that interact with it.
There is no single diagram in UML that would map to this definition, but I have some good news - there are several diagrams (out of total of 14) that can show the frontier between the system and its surrounding world from different perspectives. This is much more flexible than only a context diagram.
First of all, I would mention a special UML element - a boundary. It can be used in any diagram type to show some kind of delimitation. You might want to optionally use it to visually delimit between the system and its environment, especially in situations when this is not explicit.
The following diagrams can show the boundary between the system and its environment:
Use case diagram (your example) support the context explicitly on the functional level. Use cases are elements of the system under development, while the actors are extern entities (systems or human users). Before mentioned boundary is often used to visually delimit between the system and its environment.
Component diagram is used to model some kind of software modules (applications, DBs, external systems, libraries, etc). You can use it to show both internal and external components and the way they interact. A boundary can be used to clearly draw the separation line.
Activity diagram can show your system/business/usage processes. Some activities can be performed internally, others externally. Here you don't need the boundary, but the so called swimlanes to depict who does what.
Sequence/collaboration diagrams are another option. They show the communication sequences between several objects. If you split those objects in internal and external ones and wrap them up with the boundaries, there is another context diagram. :)
UML is flexible, there are probably further options, but I think this is enough to get the idea.
Names of your association are services. UseCase in center of diagram is context of services definition. See usecase diagram:
It could be done with a use case
http://en.wikipedia.org/wiki/Use_case
EDIT:
Reconsidering it, use case diagram should be the next step once the operations are defined so first you shouls make a system sequence diagram.
http://en.wikipedia.org/wiki/System_sequence_diagram
If you're happy with going into the not complete superset of UML that is SysML, you can have proper Context diagrams there.
However, context diagrams in SysML are simply Block Diagrams showing system context… and Block Diagrams happen to be the same as UML2 Class diagram, where the classes are of stereotype «SysML::Block».
So you can define your context diagram in terms of aggregation of blocks to your system, with the relevant stereotypes, basing it on UML2 Class diagrams.
I tend to use collaboration diagrams for this. So for each major scenario of each use case, draw a collaboration diagram showing the actors, with the application as a single entity in the middle, and messages travelling around that show how the application interacts with the actors in order to fulfil the scenario.
(I don't put too much detail in the messages -- I only want to show that there is a delegation of responsibility and some kind of interaction, but I don't care about details of actual messages, views, data etc.)
I find the context diagram does have a particular appeal. It sits well with business users, showing them the scope & parties of a system in a very easy way. So, I tend to create a context diagram, even in contexts where UML is prevalent.
As i read through UML specification superstructure that there is sequence diagram and there is a collaboration diagram
so,What is the differences between
sequence diagram and collaboration diagram?
Sequence and collaboration diagrams both aim at describing the dynamic interactions between objects.
The information you can describe are basically the same, but the two models have a different focus:
Sequence diagrams highlight more the temporal aspect, by showing invocation and responses along a (vertical) timeline and by explicitly showing the activation time of objects.
Sequence diagrams show how objects communicate with each other in terms of a temporal sequence of messages. The time flow is the most visible aspect in these diagrams, as messages are sequenced according to a vertical timeline and also the lifespan of objects associated to
those messages is reported. The figure below (taken from our book) shows an example of a sequence diagram describing 3 objects (instances of classes Shipment, Invoice and PartList) and the messages exchanged between each other. Interaction diagrams describe execution scenarios of the system.
Collaboration diagrams aim at showing the communications that happen between objects, by defining messages that flow between each other. They basically consist of superimposing the communication actions upon an object diagram. The temporal aspect can be shown here too, by numbering the interactions with sequential labels.
A collaboration diagram shows the interactions between objects or classes in terms of links (solid undirected lines connecting the elements that can interact) and messages that flow through the links. This describes at the same time some kind of static structure (links and nodes) and dynamic behavior (messages) of the system. An example is shown below.
UML1: These diagrams are the same, but present data from different points of view.
UML2: The Collaboration diagram is renamed to Communication diagram (there were misunderstanding since people thought that Collaboration diagram was used to show collaborations).
These diagrams are almost the same, but present the Sequence diagram has much more possibilities for visualization (for example, combined fragments, state invariants).
Sequence diagrams specify interaction in a time sequence manner which may be among objects and/or classes. These diagrams are created during early elaboration phase where each flow of the use case is defined in terms of sequences , i.e. after each step what is going to happen next. This kind of representation is very helpful to understand & discuss the use cases with the customer, where both can come out with all possible functional aspects.
On the other hand collaboration diagram provides a direct interaction among the object. These diagram seem to used more in the design phase of the development when you are designing the implementation of the relationship.
There is a difference between sequence diagrams and collaboration diagrams. Sequence diagrams shows object interaction in timely manner(so no need of numbering the messages). But collaboration diagram doesn't show object interaction in timely manner. (need to numbering the messages).
NOTE:
Now Collaboration diagrams are also called as communication diagrams.
A Sequence diagram is dynamic, and, more importantly, is time ordered. A Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the objects and their association with other objects in the system apart from how they interact with each other. The association between objects is not represented in a Sequence diagram.
Link : http://www.developer.com/design/article.php/3102981/Collaboration-Diagram-in-UML.htm
Use sequence diagrams to show time and to emphasize the sequence or
the ordering of the interactions.
Use communication diagrams to emphasize the links among the
participants. Communication diagrams can be a helpful supplement
to the object diagrams.
I am not a big fan of UML. I believe UML is great in some rare instances, however I do not want to use a UML diagram to show a high level flow of calls through my application. Problem is - most of the tools (visio, lucidchart, websequencediagrams) force the user to either draw a very detailed UML diagram, or a sequence diagram. There is nothing that would be like a high-level version of a UML diagram. Or is there?
There is no such thing as a "higher level" UML diagram. UML has 12 (or was it 12? I can't remember) and you must choose from one of them, the best that fits your needs.
For a high level flow of calls I like activity diagrams, even though the objects that own the functions are harder to see. Sequence diagrams are a waste of time and space IMHO .
Is an activity diagram is considered algorithmic?
Strange question indeed. Taking a look at dictionary definitions:
Algorithmic: of or relating to or having the characteristics of an algorithm
Algorithm(1): a precise rule (or set of rules) specifying how to solve some problem
Algorithm(2): an effective method for solving a problem expressed as a finite sequence of steps.
So: can Activity Diagrams be used to describe "a method for solving problems expressed as a finite sequence of steps"? Yes - that's their purpose. They support all the usual control structures required to describe algorithms: sequence (A followed by B), alternation (either A or B), iteration. They also provide explicit support for parallel activity.
Areas where they may be considered weak:
The execution semantics are not precisely and unambiguously defined. Whilst the UML spec does provide some semantics, it leaves some points open.
There's no pre-defined set of primitive types defined for Activity Diagrams. Thus, the lowest level primitive activities (adding integers, concatenating strings, etc.) aren't pre-defined. In that sense Activity Diagrams on their own aren't computationally complete.
However: those are nitpicking theoretics. In practice, Activity Diagrams are a popular means to represent algorithms: from the design of software procedures to specifying business processes.
Of course, it all comes down to your definition of algorithmic. If you go with the general definitions above then ADs are algorithmic. If you go with something more specific they might not be.
hth.
OMG Meta-Models (i.e. UML, SysML, etc.), starting from the Meta-Meta-Modeling language by means of which they are described (MOF), consists of two different classes of models respectively aimed at definining:
The static structure of a system, or architecture (i.e. Class Diagram, Component Diagram, Block Diagram, etc.);
The dynamic of the system, or behaviours (i.e. sequence diagram, activity diagrams, state machine diagrams, object interaction diagrams, etc.)
Activity diagrams belong to the second class so they are aimed at describing behaviours.
an algorithmic is only of type of behaviour that can be described by means of an activity diagram
Activity diagrams complemented with the new UML executable standards can be used to represent any algorithm. Activity diagrams alone can be used to represent the overall control flow but not really the details of data management