I am currently working to create a UML model of an embedded system to aid the description of the related software requirements specification.
I have a physical pressure sensor which outputs a voltage with a determined relationship between the voltage value and the pressure measured. Since the model is used to elicit SwRS, I have decided model the pressure sensor through a class that abstracts the voltage-pressure relationship and exposes the currently measured pressure through its pressure property.
I used a property rather than an operation like getPressure():Real, because the pressure sensor measures that pressure continuously, not only when required.
The pressure sensor is considered broken if the pressure goes negative.
I would like to use UML to express a time constraint between this event and the time taken by the software to show an alarm message.
I believe that the event that I am after is the ChangeEvent, namely when(PressureSensor.pressure < 0).
I believe that the diagram type that can be used for this is the Sequence Diagram, but I am not able to express what I would like and complying with the UML 2.5 specs.
For example, if I use a sequence diagram I can express the concept in this way.
The problem is that pag. 572 of the UML 2.5 spec states that
The signature of a Message refers to either an Operation or a Signal.
This means that the signature cannot refer to a ChangeEvent, hence my diagram does not respect the UML 2.5 spec.
I also though of using an activity diagram, but from I could not figure out a proper way to use an activity diagram for my purpose.
You have a functional and a non-functional requirement:
"The UserInterface shall show a warning message if the pressure drops below 0."
"The pressure warning message shall be shown within 10ms after the pressure has dropped below 0."
Both can be expressed in a state diagram.
Here, PressureSensor.Pressure < 0 is a change event and UserInterface.showMessage("WARNING: Pressure below 0") is the effect.
The timing requirement is modeled as a constraint.
UML allows to include timing details in a SD like this:
I don't know whether Papyrus allows to depict it this ways (I used EA).
Related
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'm working on a basic embedded systems application. Where I have a sonar (ultrasonic) sensor to measure the distance between the sensor and X object. Ultasonic sensor has one job to do, calculate distance and return it. I would like to produce a state chart diagram for this but I cannot break it down into different states. This is one of those situations where you can't get your head around a simple task. Anyone have any idea?
It's not a strict law, but I've come identify a state of an object by a set of operations that may be performed on it. So if, under different conditions, different sets of operations can be performed, you have different states. This view is supported by most state diagram conventions, including UML, where, on each state, you may model operations that lead to the same or other states.
So the key question is: Are there conditions under which your ultrasonic sensor may perform only subsets of its functionality? Each such subset will define one state.
From my understanding, SysML 1.4 allows to have itemFlows between Block as well as Part
Here is an excerpt from pag 75 of the SysML 1.4 specs
which shows that it is possible to have itemFlow(s) between Blocks.
I am not sure about the semantic of this.
For example, referring to the excerpt from the SysML 1.4 specs, does it mean that every instance of Engine block requires an "itemFlow" connection to an instance of a Transmission block and that a Torque will flow between every Instance of Engine block to the associated instance of Transmission Block?
Yes, of course. At least if the Engine/Transmission are blocks instantiated from this model.
You are free to define other Engines/Transmissions where not Torque is transported (e.g. if you see a copper cable as transmission where current is transported rather than torque).
An item flow in general tells that "something physical" is moved from source to target. The above transports torque. You can also transport current, gas, fluid, etc. Even abstract information can be transported, though SysML is designed to map physical objects, rather than abstract things (where UML will be sufficient).
There is an association between Engine and Transmission. Since we don't see any multiplicity, we may assume that it is 1. That means every Engine instance must be linked to a Transmission instance and vice versa. This is not realistic, but hey, who wants models of reality ;-). In the real world the multiplicity is 0..1.
The item flow just says, that Torque can potentially flow across a link between the two instances.
By the way: This is also not realistic, since torque is the potential to flow, not the item flowing. The item is rather angular momentum. For reasons I don't understand, the potential (e.g. Torque) or the rate (e.g. Current) is often used in place of the item that is flowing in reality.
My requirement : I want to come up with a suitable UML diagram based on the case which is described below. I need to know which UML will best suit this condition.
The case : Two object A and B in the form of "Application Forms" interacts with each other.Certain event in object A triggers a state change of object B.Both object interacts with each other for a Use Case.
I tried using State Diagram but it fails as here 2 object interact with each other to change the state of one object, whereas State diagram is suitable to depict state change of one object only without showing interaction with another object which is causing state change.
My requirement is to show both interaction and state change together in the same diagram.Is it possible?
Any suggestion on this which UML diagram is suitable for this?
UML uses two different diagrams for each behavior, one for State (State Machine Diagram) and one for Interaction (could be the communication diagram or the sequence diagram).
Since the Interface of a class doesn't change when it's state changes (by applying the State Pattern for example), the interaction should not really change from the perspective of the caller, sure, internally all kinds of things might be going on, but that should not really matter.
The way I'd model this is to describe which states your objects are in and which scenario will play out. That will result in a few interactions and possibly state changes. Then pick a new scenario, either using the end-state of the previous one as a starting point, or describing a new starting state.
That way each scenario is clearly defined, the interaction diagram shows how the objects interact, and multiple State Diagrams with the active state highlighted can show the changes in state and thus behavior of the different objects.
There is no diagram that gracefully combines both, since one (the state machine) is a static diagram, showing all possible options, while the other describes the interaction.
Sure you could play around with creative naming, as suggested (ObjectA/State) as your different objects in the interaction type diagrams, but it would not result in a very clear picture. What you're trying to describe here is a story, a sequence of events and how those events impact the different states of the objects. So your scenario's are the story on a high level, the communication diagrams the stories on a much more detailed level and the state machine diagram the snapshots of specific situations.
Model your states in the state diagram as such: (Object / ObjectState).
For example:
States (A/uninitialized) , (A/initialized), ...
Should work then.
State diagram, sequence diagram, communication diagram and the whole answer by #jessehouwing is fine, but I think there is an easier and more natural way:
(1) http://agilemodeling.com/style/activityDiagram.htm, Figure 3. Submitting expenses
Note that this is UML 1.4 activity diagram. Current UML notation is slightly diferent. Dashed lines represent Object flow : Chapter 3.90.2.2 Object flow ...Objects that are input to or output from an action may be shown as object symbols. A
dashed arrow is drawn from an action state to an output object, and a dashed arrow is drawn from an input object to an action state. The same object may be (and usually is) the output of one action and the input of one or more subsequent actions...
and (2) http://www.uml-diagrams.org/document-management-uml-activity-diagram-example.html
show an examples of how you can combine object states and UML activity diagram. The pictures are activity diagrams and the orange rectangles highlight points where objects with states (the part in [some state]) are shown. The purple rectangles show authors who were robbed.
I want to model an activity, where there can be two several initiating events. These events has two several responsible actors. Is it allowed that a UML activity-diagram could have two initiating events and only one end? Could the action-flow be joined?
I want to know if I defy against the UML-modeling principles, if I do this.
Would be nice, if there are some hints for me.
Greetings,
Martin
The UML 2.3 superstructure specification (p389) says:
An activity may have more than one initial node.
and
If an activity has more than one initial node, then invoking the activity starts multiple flows, one at each initial node.
So according to the UML spec you're not violating the rules.
That said, #Dave is on the money - the most important thing is your model makes sense to you and those who will consume it. The UML specification is so riddled with inconsistency and ambiguity that it's questionable what 'being compliant' even means.
So long as you and all users of the model have a common understanding of what it's representing then don't get hung up on the UML's pseudo-semantics.
(Of course, this assumes you're using the model as a picture for communication, not as a formal specification that will be interpreted/compiled to code. If so, you'll need to formalise your own semantics for what it means).