I want to model sequence diagram for my ERP System that has twelve modules as follows:
CRM
HRM
SRM
Order Management
invoicing
reports generation
POS
accounts management
Inventory
Material management
Warranty claim
How to address/breakdown inter-module relationship and represent them in terms of sequence diagram?
Sequence diagram has a higher granularity than component or deployment diagram.
So if you want to represent your system in one single diagram, I would suggest going with a component diagram instead of the sequence diagram.
Sequence diagram represents communication flow between objects in
terms of messages which are more granular compared to each module in
your system.
Each module of your system will have multiple sequence diagram and representing entire system would be a too much complicated. UML diagrams are to represent the system in a most simpler way.
I hope this answers your question.
Thanks.
Related
I'm studying UML and I am confused.Could anyone explain me What is the difference between use-case diagram and sequence diagram in unified process model?
The use-case diagram shows the objectives that make external actors interact with the system. It‘s about relations with the outside world. Each use-case is independent and not sequenced with the others.
The sequence diagram shows a scenario of interaction between objects within the system. The interaction in the diagram correspond to message that are exchanged in a given sequence.
I am new to UML. I have studied more tutorials.I learned two broad categories like,
UML Diagrams:
1. Structural Diagrams
Class diagram
Object diagram
Component diagram
Deployment diagram
2. Behavioral Diagrams
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
But I dont know which one is high level design and low design. Anyone list out the UML diagram types based on priorities. (high-level diagrams to low level)
There is not really a well-defined order of higher-level versus lower-level diagram languages in UML. The same diagram language (e.g. class diagrams) can be used at different levels of abstraction. For instance, a conceptual information model, but also a Java data model, can be expressed as a class diagram.
Generally, a use case diagram is higher-level, since it describes requirements, while a deployment diagram is lower-level, since it describes system deployment structures.
But all other diagrams languages can be used at different levels of abstraction.
UML diagrams - from the most common to most detailed level.
Please, notice, that nowadays (the start of 2014) there are no special instrument for UI modelling. So, I'll explain how to do this part of work, too, with the tools we have. But they will be used in a less or more nonstandard way.
Human level. Use case diagrams and state machines. How people will work with the system.
Use cases are about what the system does, who works with it and maybe, grouping of those subjects. Subsystems can be defined here. Try not to show much structure or behaviour. Not to use any IT slang!
State machines show what states the system, subsystems and actors can have and what actions/events can happen in these states and to which other states can it lead. Not to use any IT slang!
Do not forget, that administrators, programmers and testers are users of the system, too. So, plan not only how the system helps to the work of the common user and his senior, but also to the installation/administration/testing/support processes. Don't forget to continue this work on all deeper diagraming levels. These use cases/state machines needn't be so human-oriented.
You can draw activities, sequence, timing diagrams for some dialogues between Actors and subsystems, if they are the part of the requirements. Or make them the part of requirements if they are important. Not to use any IT slang!
Draw the sketches for the UI and talk over them with client. The work on UI art design should be connected to UI planning and realization
Start to work on User Guide - create plan and structure. (I use class diagrams for that).
Deployment and component diagrams. Here you are starting to imagine the inner construction of your system
Components - What compact parts it has. It needn't have much in common with the subsystems, as user see them. Only some components are visible to the user. You could decide on the use of some interfaces between them. Think on the license problems of the third-party components.
Deployment - how the components could be distributed among PCs. The same question about interfaces, but more from the physical side.
A special deployment diagram for license politics of your product could be drawn, too. You can use other diagrams for it, as well. It is at your choice.
You could already plan your user interface by these diagrams, too. In MVC (model-viewer-controller) construction only the components of the controller level are mutually connected and obviously need this level modelling. But the viewer layer (UI) components are connected in a conceptual way, they should be, for the sake of user. So, it should be planned too, by the same diagrams.
On this level you also plan the architecture of the development environment. It consists of components, too.
Draw Interaction Overview and Communication diagrams to see the cooperation of components as a whole or in complex groups.
Package, activities, sequence, timing diagrams
Package diagrams are for planning the hierarchy of your code and mutual visibility of its parts. Don't forget the place for testing packages, too. Notice, that the structures of packages and components hierarchies are different, but they have to work together. It is very important part, frequently overlooked.
Use behavioral diagrams for better understanding how different processes could run.
System analysis - the class diagrams level.
Some important classes could appear on the previous level diagrams - as definitions of intercomponent interfaces or subjects of processes. But now you should do all of them. Minimally a diagram for a component. You should do these class diagrams, using ready package diagrams.
Plan the content of UI, defining elements and functonalities and connections between them WITHOUT choosing the concrete components. Use diagrams that you like. Class ones are usable, but in not standard reading.
Deeper insight
If you have instances with specific behavior, use Object diagrams for their planning.
If you have some very complex classes or their tight groups, use Composite Structure Diagrams.
UI: Plan the content of screen elements WITH choice of the UI components (frames, buttons and so on) and connecting functionalities to them. On this level you can again use class/object and sequence/timing diagrams.
Code. Really, the coding, at least on the prototype level starts already on the stage of component planning. You have to control if and how different technologies will cooperate. But the real coding should be done only after you are sure you understand what are you doing. And to create all or some correct diagrams is the best way to be sure in it.
Notice the rule of thumb - structure diagrams set the sequence of levels. Behavioral diagrams support them on all levels. You can use state machine on the lowest level and timing diagram for to discuss with a client. But try not to mix the levels with the structural diagrams!
Also, do not try to mix diagrams, especially behavioral with structural ones. You should clearly set the rules, by which you can say, what part of information can be on the diagram and what not. And break these rules really only in the most exceptional cases.
As gwag noted, there is no separation of UML diagrams into high and low levels. The different diagrams are used for describing different aspects, not different levels, of a (software) system.
But if you look at UML in a broader context, the Unified Modelling Language is just one of a whole family of modelling languages standardized by OMG. These different languages do have more specific scopes.
SysML (Systems Modelling Language) shares many features with UML and looks very similar, but is specifically intended for the higher levels of systems analysis / design. It also includes a visual representation of requirements, which are conspicuously absent from UML.
Another related language is BPMN (Business Process Model and Notation), which is used for business processes. So you could for instance use BPMN for business analysis, SysML for system design and UML for software design.
UML does not specify level of details you define in diagram. Every diagram can be used for description on business level, implementation or design level as well.
It is up to modeler, what type of diagram uses to descrbe modeled system. Information in diagrams must correspond with each other and all diagrams must give complet view on system.
For example, you can declare services of Bank company using UseCase on business level or use UseCase to declare services implemented by concret physical component of program writen in Java.
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.
As we known . The sequence diagram in UML is a kind of interaction diagram that shows how processes operate with one another and in what order Between the Class or Object.
Now I am trying to find a diagram in UML or some tools to describe interaction and operation order of distributed system. Is there any diagram or tools which model the interaction between Distributed system like sequence diagram ?Thanks.
Activity Diagrams are the UML diagram to use in this situation.
Wikipedia Activity Diagram
Agile Activity Diagrams
Sequence and communication diagrams aim to show how "things" interact. These "things" could be objects, components or complete systems
You can also use sequence diagrams to describe interaction between components in a distributed system, each lifeline designating one of the system components.
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.