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.
Related
I’m trying to prepare UML model for my project. It’s quite complex however I focus on one of use-case. In short term, use case name is “Edit patient results” and actor “Doctor” uses it. In fact, entering results triggers always the set of following actions:
List item
Normal Ranges calculation
Related Expression calculation
Interpretation merging
Assuming that I have my use-case diagram prepared as follows:
My questions are:
How shall I draw actions that are triggered automatically? As extended use-cases like this?
How shall I draw “Edit patient results” use-case realization? Each edit operation involves several software components interactions, shall I use collaboration diagrams? (how to join my main use-case with them), maybe something else?
How to draw sequence diagrams to show actions sequence and parameters passed? How to join these diagrams with my use-case.
What is the best way to show use-case realization
I'm using Enterprice Architect.
Thank You !!!
No. These are just activities which are part of scenarios inside the use case. Trying to make the use cases is functional analysis the wrong way. A use case synthesizes a number of steps under a common goal/added value.
A use case realization is a collaboration (bubble with dashed line border; along with the UC in the toolbox). The collaboration contains diagrams which show how the single classes communicate/collaborate to realize (parts of) the use case. Use a Realization from Collaboration to Use Case.
Put the SDs inside the collaboration and group/name them reasonably.
see above
As to your comments:
Edited 2.
I never found a good use for Collaboration Use and I've done a lot of successful UC modeling. So you can probably live without it as well.
Put Actions inside an Activity representing a scenario and connect them as desired. You might look into BPMN as well.
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.
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.
I would like to know which diagram from those two should be created first when designing large IT system.
In every article I read about UML, the component diagram is mentioned as almost last.
I think that, when designing a larger system is better to divide it to smaller parts/modules on the component diagram and then for every component create a detailed class diagram. Is that correct?
How it look in practice from your experiences?
Do you know of any article/tutorial that shows from beginning to end, the design of system using UML?
There is no mandatory order for UML diagram design - in fact, you will often find yourself creating several simple diagrams of different types, and refining them later. The process is generally iterative but doesn't have a follow a particular order.
That being said, some UML diagrams provide a more abstract view than others, and it may sometimes make sense to start with the most abstract views and work your way down to the most specialised ones. Use case diagrams typically come early, while object diagrams or state diagrams often come later in the design process, once the original, abstract solution has been refined.
You will also want to take a look at consistency between your diagrams: indeed, with several views you will introduce redundant elements, and it is important to make sure that they do not contradict each other. For example, if you have a sequence diagram and a class diagram, any call message in the former should correspond to an operation in the latter. See Alexander Egyed et al's work for automated consistency management and correction in UML models.
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.