I am using Microsoft Visio 2010.
I am drawing a UML sequence diagram.
I added object Lifeline and started drawing diagram. Because the diagram is very long, at one point there would not be any more connectors to connect the arrows to. See this picture:
I understand that probably it is not good idea to put so many processes on one diagram, but it seems to me to be the best way to describe the whole process. And I only need a bit more space to continue the diagram!
So, how to configure the lifeline to have more connectors?
You can read how to add more connection points at "Add, move, or delete connection points". This will allow you add connection points for the propose of creating the diagram however I don't know if this is sufficient for the UML model to know the source and destination of messages. This may be an issue if you are exporting the UML model to code or another tool.
Related
When designing flowchart models for my programing, I sometimes ask myself if I am drawing email communication between swim lanes the best way. Perhaps there are some who has better suggestions to describe the following process?
A wants a specific customer list from B. To do that, A has to send a request to B - it could be an email. B creates the list and sends it back to A.
UPDATE
My initial illustration wasn't UML so I try with this instead - ready for your comments:
Actually this is a perfect and overall used approach. Rather than using swim lanes, which are just graphical elements on the diagram, you should use ActivityPartitions (which are real UML elements) which you can classify with the actors in question.
Further you should use ActivityInitial (full circle) and ActivityFinal (hollow circle with large dot in center) to mark the start and end of your flow.
For more examples see here.
N.B. Just noticing this is tagged with Visio. Since Visio is a pure drawing tool you should consider using a real UML modeling tool instead.
P.S. I see that Geert removed the UML tag. So I may have been deceived by the question and thinking of this as being an UML activity diagram. So that's what my answer refers to. Anyhow, since flow charts are ancestors of activity diagrams this might help as well.
I know that an activity diagram is:
More simple;
More standardized;
Support concurrent flows.
compared to a flow chart.
But what are the possible reasons for using an activity diagram instead of a flow chart apart from those mentioned above?
An activity diagram is not simpler than a flow chart. A flow chart is a simpler (earlier) version of an Activity Diagram.
Flow charts were invented at least 20 years earlier and are commonly used by non-programmers to document workflows. Any business process where people have to make decisions can be described as a flow chart. So, for example, a clerk making decisions about how to file complicated information might have a flow chart on the wall.
Because a flow chart is a subset of an activity diagram, there's actually no decision to make. A flow chart naturally grows into an activity diagram if you need to add more complex descriptions.
Sparx have a good explanation of the range of things you can describe in an Activity Diagram
A UML Activity Diagram is a type of "flowchart" .. in UML, with bells and whistles. There is no such thing as a "UML Flowchart". If using UML it is an Activity Diagram. If using something else, then something else is being used.
[UML] Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency ..
.. Activity diagrams may be regarded as a form of flowchart.
For better or worse, UML is a standardization. This is nice because it is well, "standardized", but also means that it is not appropriate for all tasks: the chosen "flowchart" model (and extensions thereof) might be a better fit for a particular problem/domain.
An activity diagram assigns responsibilities to the objects involved in collaboration using swim lanes. So the diagram clearly shows the work to be done by each object in collaboration.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
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 am new to UML designing and read few articles on this. bit confused where to start..
Do i need to prepare all of the UML diagrams for a web application or is some diagrams are only essential for an application.
Thanks,
Start from Use Case - define, who will use your application(actors) and what they will do with it(use cases). Also, join close use cases into subsystems.
Component diagram - what main parts the system has and what info they will send to each other and if some part belongs to another
Go on with State machine - define what states will have your components and on what reasons can they change they states to other ones.
Deployment diagram will define on what PCs will these components live and about the connections/protocols/interfaces between them
Plan your user interfaces - now only the set of pages and frames and navigation between them and commands on them. Do not solve placing and colors yet
Class diagrams for every component
If for for some of your classes some instances are specifically important, use object diagram.
Draw the look of the UI
Code.
UML is there to help you. Pick only what you need. You'll hardly ever need all diagram types. Plus, it is convenient for the reader if he needs to know only a predefined UML subset to understand your draft.