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.
Related
According to multiple sources, the Information Flow diagram is not part of the UML v2.5.1 taxonomy.
See examples here:
https://www.uml-diagrams.org/uml-25-diagrams.html
https://stackoverflow.com/a/44715082/4216654
According to the UML v2.5.1 (and v2.5.0) specification, it seems that the Information Flow diagram is part of the UML v2.5.1 taxonomy, when in v2.4.1 it was an auxiliary package.
Clause 20 of v2.5.1 describes everything about Information Flows. It's still described as a package but it doesn't talk about anything being auxiliary anymore.
It looks like this is something people missed in the transition from v2.4.1 to v2.5.0, but maybe I'm the one who missed something here.
If the Information Flow diagram is indeed part of the UML v2.5.1 taxonomy, it means that many comments, websites, books and software are wrong about it, so I would like to be extra sure about this point. It's likely that I'm wrong about this, so I would be glad to understand why.
I would appreciate any help about this.
No, Information Flow Diagrams don't exist in the UML specification.
These are the diagram types defined in UML v2.5.1, found on page 685
Information Flows however are part of the UML metamodel and are described in detail in §20 starting page 669.
There is simply no dedicated diagram type defined to show Information Flows. You can show them on other diagrams however such as Class Diagram, Component Diagram, etc..
In short
Information flows are specified in section 20 of the UML specifications. But apparently, they were not fit enough to survive in the UML diagram taxonomy as own diagram type.
However, you can create a class diagram and populate it only with information items and flows linking source items to target items. This ambiguity leads to contradictory claims: it'll be a real information flow diagram, but in the UML taxonomy it would still be a class diagram (see blue specialisation in your link).
Some more thoughts
What are information flows good for?
According to the UML specs:
The principal goal of InformationFlows is to convey that information moves from one area of a model to another. Consequently, the metamodel is intentionally very permissive about the realization of information channels and the types of information that can flow along them.
So it is to enrich other diagrams to explain how they relate to high level information, or to highlight some hidden «flow» relations (similar to dependencies).
Why didn't the own diagram make it?
In UML, there are better ways to model flows of "information" as soon as you're ready to use classes instead of information items:
Activity diagrams, which provide object flows,
Sequence diagrams, which provide flows of messages,
Communication diagrams, which is semantically equivalent to sequence diagrams, but with a different focus.
Moreover, UML specs explain:
An important use of InformationItems is to represent information during early design stages, possibly before the detailed modeling decisions that will ultimately define them have been made.
But in practice, unless you work in an organisation with extremely strong configuration management rules, there is no need for such information flows in a pragmatic use of UML with initial high-level sketching and iterative refinements.
I'd like to use UML to draw a high level diagram of my system's message driven architecture.
I am struggling to identify the correct diagram to draw a system of EIP microservices which exchange messages via message channels.
Which UML diagram is most appropriate for this?
When you say EIP, I assume you mean Enterprise Integration Patterns, I.e. a varied collection of patterns for enterprise application integration such as Message Router, Message Broker, Message Channel, Service Call and so on, as documented in several popular books and papers. If this is the case, then your reference to the Message Channel pattern makes sense and I think I understand what you mean.
The UML is a general-use language set, and can be used to represent many different aspects of your architecture, so the answer to your question depends on what you are attempting to show and at what level of abstraction. If your focus is on messaging (message timing, ordering and so on) then you need to use one the the behavioural languages within the UML; if you want to represent messages (structure, types, content etc) then you can do so with a structural language. The answer from 8bitjunkie suggests Communication Diagrams for the behavioural side, but you could also use Sequence Diagrams, Activity Diagrams and State Charts depending on your focus/need. Sequence Diagrams allow you to identify timing aspects more clearly than Communication Diagrams. For message structure I'd recommend Class Diagrams. The UML can also be extended through Tagged Values and Stereotypes to include much greater specificity and add structured detail if you would like; there is no real limit to the structured information you can capture in a UML model.
From the introduction of enterpriseintegrationpatterns.com:
The UML Profile for EAI [UMLEAI] enriches the semantics of
collaboration diagrams to describe message flows between components.
This notation is very useful as a precise visual description of a
system that can serve as the basis for code generation as part of a
model-driven architecture (MDA).
Collaboration diagrams are replaced in UML 2 with Communication Diagrams
However the introduction of enterpriseintegrationpatterns.com goes on to say:
We decided not to adopt this notation... {because} ...the UML
Profile does not capture all the patterns described in our pattern
language.
At the current time of writing (April 2019), it appears that the last time that the EAI profile for UML was published was March 2004. This predates the excerpts from enterpriseintegrationpatterns.com, which according to the way back machine was first published in August 2015.
This suggests that UML 2 is ill-equiped to describe message-driven system architectures which embody EIPs.
You can use a component diagram and/or a composite structure diagram. If, in your case, each microservice is instantiated only once, then you only need one of these diagrams. Otherwise, it would be good to have a component diagram show the class level and a composite structure diagram show the instance level. See question Component diagram dependency vs assembly.
A message queue can be modeled as a separate component with stereotype <<queue>>, or as an interface with stereotype <<queue>>. Modeling a queue as a separate component is the best choice if the queue is not owned by one service. However, if it is owned (only one service puts/publishes messages on it), then a separate queue-component clutters the diagram and it would be better to model it as an interface, provided by the message producer and required by the message consumers.
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.
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.