I need a tool (preferably online, but at that stage I don't care anymore) which allows me to modelize relationships (similar to BPMN) which can be represented as compound graphs (though most of the times, it will be a simpler nested graph). I can't seem to achieve my goal using BPMN formalism (swimlanes are the closest but they do not allow arbitrary nesting). I am thinking to reuse UML modelization tools but I don't know enough about UML to know if UML covers my use case.
Imagine an integrated circuit which is made of chips connected with wires. So three chips : A,B,C and Chip A -> Chip B, Chip C. Each chip has input ports and output ports, and some of the output ports of A are connected to the input ports of B, some are connected to those of C. Now Chip A itself can be considered as an integrated circuit, and as such can be decomposed in another graph : Chip A :: Chip A.1, Chip A.3 -> Chip A.2. Each Chip A.1 can also be decomposed etc. This is what is called a compound graph. Each node of a compound graph can have children which are themselves graphs.
I do know about the Harel's and UML's statecharts formalism, which allows for hierarchical graphs to describe hierarchical nested state machines (hence any nested graph can potentially be expressed with statechart formalism), though I do not know any online tool which allow to draw statechart. The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
Level 1
-------
---|ChipA|---ChipB---
| |---ChipC---
|-----|
Zoom on Chip A
-----ChipA.1---ChipA.2---- (...linked to ChipB input port
|--ChipA.3-| |-- (...linked to ChipC input port
An example of compound graph from the litterature :
In response to your comment,
The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
At the infrastructure level, it uses the Element::ownedElement association to represent containment. The Namespace::ownedMember associate subsets this association, as do the association between classes and their members, packages and nested packages, components and their contained items, and so on. All of these are conceptually compound graphs, but are not rendered in a similar way to you diagrams.
In terms of you 'Chip made up of chips', the CompositeStructures package in the UML superstructure ( section 9 of the 2.4.1 superstructure ) uses these association to create composites, or for a domain specific example built on top of UML then SysML is the UML dialect created for systems engineering.
A systems engineering block diagram consists of blocks created with ports and connectors; blocks can have internal structure of further network of blocks. The connectors carry flows, whic can be information, energy or matter.
An example block diagram for some plant shows the custom rendering used to show owned elements in the same diagram as their containers:
See http://www.omgsysml.org/ or http://sysmlforum.com/sysml-faq/ for further information.
Tools for sysml are listed on the http://sysml.tools/ site.
Start with the component diagram in UML.
Your chips can be treated as components, ports will be... well, ports ;-) but also you should define some sort of interfaces (functions offered/needed by those ports). As I understand it the arrow direction depicts some sort of dependency (so the chip at the end with arrowhead provides something and thus will have a provided interface while the other end will have a required interface and a proper connection between them).
If a specific port is realised with internal structure you'll use a delegation connector for that.
Related
I'm a little confused about difference between state machine diagram and activity diagram in this specific situation.
In a follow simple schema, can you distinguish between activity or state machine diagram? The symbols are present in both diagrams.
thanks
Mauro
I now can confirm that you can't tell. On p. 331 of the UML 2.5 spec you find an example of the receive event used in a SM. The very same symbol is used on p. 409 for an AD.
So the answer is: no, you can't tell which diagram type is being used from the above example.
And more generally (from the Annex on p. 683):
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
No, sometimes (like in a given example) you can't tell based only on shapes. However
usually you know upfront which diagram it is so it's not a problem actually
the names will be different. States will have nouns while actions/activities as behaviours are named with verbs
especially on SM usually there are other elements that make it distinguishable: events triggering, action within states (entry/do/exit), actions run on transitions, SM specific elements like history
while signal receipt/send signals are allowed in SM they are hardly ever used
I would like to make a component diagram for a multiple robot coordination system.
I would like to show on the component diagram that the sub-component "Perception" of each "Robot" component communicates through an interface with each other. Indeed, the sensors of all robots are used in order to estimate the position/velocity of each robot, it is a cooperative sensing.
How can I do that ? Should I have an interface which would be both provided and required by the component "Robot" ?
Thanks.
For this type of system you are in position to use full power of UML and make really effective documentation. You will most likely need some (or all) of the following diagrams:
Component diagram - to show the "big picture" and the main parts of your system ant their interfaces and dependencies. Components are "black boxes" here and will be detailed in the following diagram
Composite structure - are perfect to open up the components and show their internal structure. You can take "black boxes" and their interfaces as kind of input to this work. Each component (except the external ones) should be modelled internally. This kind of diagrams lets you use the whole-part paradigm to model internal structure as a network of interconnected elements. Previously detected interfaces will be used here to show how they are actually implemented.
Class diagrams. If you need to further specify the elements of internal structure (their attributes, methods, associations, etc), this is the diagram to draw.
State machines. In embedded real-time systems, lots of classes are active and have states. Identify those classes (or even components) and use state diagrams to show their internal logic.
Sequences and interactions. These diagrams will help you to specify how different elements of your system work together to implement different scenarios.
Deployment diagram. As robot is a piece of hardware and these components run on it (or them, if there are more than one hardware node) you might want to show how the components are distributed over the hardware structure.
You could also have a look on timing diagram, relativelly new one, designed especially for real-time systems. It might come on handy if you need to express time restrictions, durations, etc.
If you are new to UML, I would recommend to start with components and deployment. They are relativelly easy to learn. As you feel understanding and need to express your ideas further, dive in the composite structure and states. And finally classes.
Have fun!
EXAMPLE
This is how I understand your model and its elements. This extends my comments.
Explanations are in comments and in the diagram notes.
A component diagram:
A component instances' diagram:
Note that the first diagram should be extended with the "connectivity rules" that define all valid connectivity possibilities. Is there only one CentralManager? Must each Robot be connected to CentralManager? Can a Robot talk to itself? And so on...
These and other questions should be modelled separatelly. On class diagrams benavior diagams, according to concrete details.
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.
UML component diagrams are good at showing technical client-server-like inteface relationships between components, using the "lollipop" notation or dependency arrows.
Is there a notation in component diagrams for showing in which direction information flows through interfaces on business process level? Like a client can connect to a server and
put/push information,
get/pull information or
the interface is used bidirectionally.
How can that be depicted in component diagrams?
UML activity diagrams allow for in-flow and out-flow pins, however ommitting the bidirectional case. Would it be sane to use the pin notation on component ports?
Sure can, a high level conceptual line was added to UML at some point. They are called information flows. The direction of the arrow makes sense to business users as well. The OMG spec covers this pretty well. For the push, pull, etc meta data I would use keywords or stereotypes to convey this. Interfaces, Classes, Data Types can all be referenced by the Information flow as what is traveling between the two classifiers (Components, Classes, etc). Many tools have implemented this construct because of it's usefulness despite in being and auxiliary construct.
Link to OMG spec and location: Section 17.2 on printed page 609. Superstructure, ie what you use (http://www.omg.org/cgi-bin/doc?formal/09-02-02)
17.2 InformationFlows
The InformationFlows package provides mechanisms for specifying the exchange of information between entities of a
system at a high level of abstraction. Information flows describe circulation of information in a system in a general
manner. They do not specify the nature of the information (type, initial value), nor the mechanisms by which this
information is conveyed (message passing, signal, common data store, parameter of operation, etc.). They also do not
specify sequences or any control conditions. It is intended that, while modeling in detail, representation and realization
links will be able to specify which model element implements the specified information flow, and how the information
will be conveyed.
The contents of the InformationFlows package is shown in Figure 17.2. The InformationFlows package is one of the
packages of the AuxiliaryConstructs package.
What's the best way to represent a networked connection in a UML class diagram?
UML class diagrams are not appropriate to describe a topological notion as a "network"; they are better suited for hierarchies and interdependencies between objects. Or are you talking about a Connection class?
The Class Diagram is the wrong place to be trying to show network connections. A Class diagram will show only the classes in your software and how they relate to each other. You should use a Deployment Diagram to show how the elements of your software are going deployed across the network.
You could also include a Communication Diagram to show how the different parts of the software communicate with each other without regard to the deployment model.
Graph or a network is a structure in which any element (Class or object here in UM) may be connected to any other element. The "connection" can be any association other than "is a" in UML. As such, it is possible to represent the structure of graph or network using a set of classes and associations.
For example, consider a class of Places, an association "is connected by" and a class of Roads. With this any complex netwrok of Places and Roads can be represented by associating an instance of Place with another instance of Place and an instance of Road. RDF Tripples thus represent a semantic network.
Is there any other (special or specific) convention of representing a graph or network in OOAD / UML?
You should use a Deployment Diagram to show how the elements of your software are going deployed across the network.
Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed.
Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
http://search.aol.com/aol/image?s_it=topsearchbox.imageDetails&v_t=client_searchbox&imgsz=&imgtype=&imgc=&q=deployment+diagrama+uml
And You use the tool Rational Rose for get that.
All is for documentation, when something is changing in the network, and every know that you used Rational Rose and Deployment Diagram.
Structure diagrams emphasize the things that must be present in the system being modeled, and every Diagram has a function.
As mentioned above already UML is serving other purposes than representing physical infrastructure of a network or components.
Some examples of network diagrams can be found on creatley -> https://creately.com/diagram/example/hfgz8ekz/Network%20Architecture%20Diagram
I personally like to use https://www.draw.io/ to generate diagrams - it's web-based, very intuitive and has many features and a large library of image-sets.