I tried to model a diagram similar to the UML Sequence Diagram with Archimate.
https://forum.archimatetool.com/index.php?topic=288.0 and http://www.hosiaisluoma.fi/ArchiMate-Cookbook.pdf chap. 2.9.6 say that this is possible by using data flow relationships between application components.
So I tried to create 2 application components and 2 request-response dataflows between them:
component A and component B
request 1 from A to B
repsonse 1 from B to A
request 2 from A to B
response 2 from B to A
This was neither possible with ADOIT nor with Archi. Sparx EA allowed to create it. I could not find if the specification allows it, but in my experiance Archi is very much alligned with the spec, while EA is not.
So my questions are:
Which tool / diagram is correct according to the spec?
Is there another possibility to create a diagram similar to the UML Sequence Diagram with Archimate?
Metamodel
The metamodel of Archimate is less formally defined as for example UML, but we can find some information.
The first thing to look at is the metamodel for the Application Layer
Here we see triggers / flows to relations from/to the elements
Application Service
Application Event
Applicaiton Internal Behavior Element
An Application Component however is an Application Internal Active Structure Element as we learn from a more detailed view on the same page
So this metamodel does not allow flow relations between Application Components
Relationship Matrix
But these are not all the allowed relationships in ArchiMate. On this page there is an additional matrix with all the allowed relationships.
If you look closely you see that there is an f in the cell that represents represent Application Component x Application Component. f stand for flow
Conclusion
YES flow relations between Application Components are allowed.
BUT..
You can't simulate sequence diagrams using ArchiMate flows. A critical factor in sequence diagrams is, well the sequence. There is no way in Archimate to specify that one flow is supposed to be happen before another flow.
Related
I have this simple diagram, it doesn't follow any type of UML diagram. Its goal is to show all the parts of our solution, and how they're related.
In the image: the web scraper scraps the data in some websites and stores it in the database. The web application receives filter options and implement it using a Rest API that returns some data to be exported in xlsx and csv. The API uses the database populated by the web scraper.
I need to make a new diagram with the highlighted process above, using UML. I had a suggestion to use a package diagram, so I made this version:
Edit: In the image: Fonts -> Web Scraper -> Database -> Api(Filters(type of filters)) -> Front end (results, search options) -> User
Is it the right way of making a package diagram? I couldn't find a similar example or specific rules for this case.
Are packages the right modeling tool for your needs?
Packages are namespaces and aim to structure a model. A package diagram therefore does in not represent a process with data flows (dynamic behavior). The relations between packages are namespace relations such as «imports» and «merges» and dependencies.
Your package diagram certainly shows some valid decomposition of your design with nested packages. But you would normally not represent users (usario), or flows of data (dados) coming from a database (Banco de dados).
What are the better alternatives in UML?
Your initial diagram shows in one picture, using some flowcharting symbols, very different things:
conceptual classes of objects such as fonts, filters, or files
components such as web scraper, the database, front-end, back-end,
flows of objects like the webscraper that feeds the database that is queried by the backend, or interactions between freont-end suppliying filters and back-end that provides data.
If you want to represent this in UML you need to clarify the focus, because UML requires some precision since it separates structure and behavior. The answer will depend on what you want to show:
the flow of processes and data? Use an activity diagram (behavior). This is perfect to show the flow from the source to the end-result, but not so easily the parts of the system that are involved.
the relationship between components ? Use a component diagram (structure). This is perfect to identify the components, how these are nested, and how their interfaces are connected. But it does not show the order in which all this happens.
the interaction between components ? Use communication or sequence diagrams (behavior). Here you see what the components exchange in what order, but not so well how the components are structured.
Spontaneously, I'd go for components, since I have the impression that this dominates your original diagram. But in the end, you may use different diagrams for showing the different aspects.
Other alternatives
If you're looking for a single diagram to combine the different thoughts of your original diagram, alternatively to UML, you could consider C4 model diagrams.
It's less precise than UML, but very convenient for communicating the big picture of a system architecture. The C4 context diagram and the C4 container diagram in paticula allow to show the system's main components, and some high-level relations (including data flows) between them.
The good news is that C4 relies on UML for the the more detailed design of the identified components.
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.
Which UML diagram is the best for showing dependency between our IT system and other external IT systems?
For example I would like to show on diagram:
system A gets data from system B
system B can call some functionality from system A
I'm wondering between component diagram and sequence diagram.
What do you think?
your question is not very specific as all UML diagrams display some kind of dependency or pathway how to get data or make a call, so I'm not sure if I got substance of your question right
1. there is no such thing as one best UML diagram to show it all
There is usually one system that you are modeling (+ some black boxes in its surrounding environment) and one UML model. At best the tool you use should support Model Driven Architecture (MDA) and perhaps even Executable UML so that the result of your modeling can be more then set of "pictures". It can become skeleton of source code forming the backbone of the application or it can be even model-click-and-run product.
In order to provide full or sufficient description of the system you'll usually need more UML diagrams each representing different point of view with focus on different aspects with different level of detail (yet all of them being parts of one model).
(This ↑ was the hard part for me to understand)
2. before deciding which diagrams to use make some paper & pencil prototypes
It is quite importtant to make sure which diagram fits your needs before you start drawing it in a good looking sharable form using a tool. Even drawing in Enterprise Architect takes some time to get used to and to get it right.
Very good guide how to do a paper & pencil diagrams and which of them is used for what and how to spend only as much time as is needed:
Agile Modeling - Start Here
...
Agile Modeling - UML 2 Component Diagrams: An Agile Introduction
Agile Modeling - UML 2 Sequence Diagramming Guidelines
...
3. sequence diagrams are expressive simple and useful for programmers
There are even tools that can turn sequence diagrams into code or tools that can turn source code into a sequence diagram.
overview UML sequence diagrams overview of graphical notation
overview IBM Rational Edge - UML basics: The sequence diagram
tutorial Enterprise Architect - 14 minute video - Create Sequence Diagram
4. activity diagrams are expressive and useful for programmers
overview Debenedetti Emanuele, Activity diagrams in UML 2.0
background by Conrad Bock (one of UML authors), UML 2 Activity and Action Models, The Journal of Object Technology
UML 2 Activity and Action Models
UML 2 Activity and Action Models, Part 2: Actions
UML 2 Activity and Action Models, Part 3: Control Nodes
UML 2 Activity and Action Models, Part 4: Object Nodes
UML 2 Activity and Action Models, Part 5: Partitions
UML 2 Activity and Action Models, Part 6: Structured Activities
tool manuals
PaceStar UML Diagrammer, UML Diagramming Guide - http://www.pacestar.com/uml/udg60.pdf
Sparx Enterprise Architect, Using UML Part Two – Behavioral Modeling Diagram - http://www.sparxsystems.com.au/downloads/whitepapers/UML_Tutorial_Part_2_Introduction.pdf
Microsoft Visual Studio, UML Activity Diagrams - http://msdn.microsoft.com/en-us/library/vstudio/dd409360.aspx
5. high level overview diagrams useful for programmers and others (not UML)
poster Business Process Model and Notation
Wikipedia - Business Process Model and Notation
clear expressive language easy to comprehend ARIS Event-Driven Process Chain (EPC) (my favorite since the first time I met it back in 1999)
6. = 1 + 2 + you
make some paper & pencil sketches and decide yourself which diagrams best suit your needs
Further to your thoughts and what Aleks has said, people usually use a combination of both to articulate the inter-system relationships
EA allows you to reuse components in component diagram & Sequence diagram, which allows you to update model from one diagram and have the changes reflected in the other.
Below snapshots show how two components in the model are used in a component diagram (for structural relationships) and sequence diagram(for behavioral flow)
Components definitelly, and dependencies. Dependency does not go in direction of the data-flow, but from the component that "knows" other component (invokes something from it, creates an object, etc).
The following diagram shows the idea.
It is common (and highly recommendable) practice, to use interfaces between the components and channel dependencies through interface. This permits clearer specification and better design (if possible of course).
Sequence diagram can further be used to specify concrete usage scenario and is also recommendable. So, components for structural, static dependencies and sequence for dynamic behavior.
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.
Can anyone tell which UML diagram I should change if there is a slight change in the design of application.
The change is -> Earlier the application was using Active directory for authentication now I want to use the Membership provider instead.
I want to keep the change minimum in diagrams.
Thanks
Sounds like component diagrams or class diagrams. Check out the following topics and illustrations for VS 2010 Ultimate RC:
UML Component Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409390%28VS.100%29.aspx:
A component diagram shows the parts of a design for a software system. A component diagram helps you
visualize the high-level structure of the system and the service behavior that those pieces provide
and consume through interfaces.
UML Class Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
A UML class diagram describes the object and information structures used by your application, both
internally and in communication with its users. It describes the information without reference to any
particular implementation.
It will surely depend the diagrams at your disposal. Sound like a correction in one of the static diagram types, like the component diagram ...
This of course depends on how you structure your documents and your uml-diagrams.
In general I have a Conceptual model, Class Diagram and a Design Diagram which are diractly linked to the architecture. And then you should in most cases have System Sequence Diagrams and more. However, depending on how your structure is and to minimize the "changes" required.
I would suggest that you use something more generic for the parts that might be changed. Active Directory Authentication and Membership Provider Authentication is both Authentication methods, which means that you can, instead of displaying the whole sequence at the Authentication step, just use "Authentication".
Now, in the conceptual models and in the design + class diagrams, you will need to change and add some fields, tables or whatever is added. But it shouldn't matter if you need to add more or less, because the documents need to reflect upon your software as accurate as possible.
So, to minimize changes, use more generic types.