What is the meaning and use cases of Car Wakeup which is described in the specification of the communication system.
(AUTOSAR_SWS_CANNetworkManagement and ...)
There parameter descriptions, but there is no definition of the word.
I can only speculate about your background in automotive communication, so please forgive me for starting at the basics.
The point of network management is to switch off communication networks that are not needed at a certain point in time. Colloquially speaking, you put those networks to sleep.
The switch-off can very well extend to the entire vehicle, or the vast majority of communication buses on a vehicle.
Of course, at some point the communication busses are needed again, and for this purpose, you "wake them up".
Related
This is a question confused me for a rather long time.
For the definition of stakehoder, I can understand that a stakeholder is not always an actor. For example, to build a nuclear power station, the National Nuclear Safety Administration may be a stakeholder, but it does not interact with the station, so it's not an actor.
But on the other hand, is an actor always a stakeholder?
Consider this: we build a underground cable system, and some rat bite the cable. In usecase analysis, I would like to model the rat as an actor, but it is definitely not a stakeholder of this system.
Well, the rat has an interest in not being electrocuted. So, it is a stakeholder. The question is, how important you consider it to be. Probably not so much.
Also, you would not analyse the use case "satisfy hunger for cables". Rather you should analyse how to "protect cable against rat bites". Both are valid use cases, but I assume, that you don‘t want your system to be used in the first way and therefore you should not model it. The second one is only a use case, if your system shall have functions to drive off rats.
The UML doesn‘t say much about how to describe use cases. I always recommend to describe them from the viewpoint of the stakeholder for whom the result is of value.
In short
Yes, every actor is always stakeholder. But not every stakeholder is an actor.
Some more thoughts:
First definition
In the UML specifications, there is no definition of stakeholders. But it is said that:
[A use case] specifies a set of behaviors performed by that subject [i.e. the system], which yields an observable result that is of value for Actors or other stakeholders of the subject.
This wording also suggests that actors are stakeholders: if they weren't, the word "other" wouldn't be needed.
By the way, this clearly eliminates the rat from the suspected actors, since the cabling system is not supposed to produce results of value for rats. And the result that could be observed on the rats is not of value for the other stakeholders.
How are stakeholders related to use cases?
Many systems produce an observable result that is of value for the actor interacting with the system: the actor benefits of cash after a withdrawal, the actor could achieve a task with the system, etc...
But the value is not always for the actor. If you walk through a body scanner at the airport, as a user you might not fully value the results of being scanned yourself. But the airport, the airline, homeland and security, and the other passengers may very well value the result of the use case. This shows that not all stakeholders who have interest in a system, are necessarily users.
Second definition
As strange as it may sound, the SWEBOK does not define the stakeholder either. They just enumerate some examples, such as users, customers, regulators etc. ISO 21500 does also have a definition by example.
Moreover, we must keep in mind that the interest of a stakeholder is not only the own benefit, but could be the opposite. If your neighbor installs a video surveillance system with a camera that captures the entry of your house, you're neither the customer, nor the user, but you will probably be a stakeholder perceiving a threat for your right to privacy.
A popular definition is therefore the PMI's:
An individual, group or organization that may affect, be affected or perceive itself to be affected by a decision, activity or outcome of a project, programme or portfolio.
We can cross check that according to this definition that all actors are stakeholders, since they will be affected by the future system.
And the rats?
Rats are in principle not actors of an underground cabling system, as the system is not build for providing them value nor to involve them to provide value to other stakeholders. Rats could be considered as stakeholders if we'd extend the concept to animals: they may be affected or think to be affected by all this cables. Bust most probably, they are simply a source of malfunctions in the system's environment.
This reminds me a story that an old system engineer told me 30 years ago, and that happened to him at the begin of his career, probably another 30 years before. It was on his first bigger computing project, a large electromechanical computer designed to compute the payroll of a large organisation. For some reasons, there were some mistakes every month, but never the same. After months of (expensive) debugging, they found out that some rats indeed have eaten the hull of some cables in the floor space under the very large computer, and if a rat by chance walked on the wires at the wrong moment, it closed random circuits that were supposed to stay open. A more modern version of the first bug?
In my UML model I have a system and its subcomponents that talk to each other. For Example, I have a computer and a RC robot where they talk via Bluetooth. Currently in the diagrams the flow is something like:
"Computer" triggers "setVelocity()" function of "RC car".
At this point, I want to refine the communication by saying that
computer sends "Movement" message
with velocity field is set to 100 and direction field is set to 0
which is acknowledged by RC car by sending ACK message
with message id "Movement" and sequence number X.
How do I do that?
EDIT: Clarification
Normally this is what my diagram looks like without protocol details:
But when I tried to add messages, there are at least 2 problems:
It seems like Computer first triggered the setVelocity() funciton and then sendBluetoothMessage() sequentially which are not sequential . The followings of setVelocity() are actually what happens inside that.
sendBluetoothMessage() is actually a function of Computer. But here it belongs to RC Car. (or am I wrong?) And the same things for ACK.
Thanks for the responses. You are gold!
Communication protocols in general
There are two main ways of representing the sending of a movement message between two devices:
A movement() operation on the target device, with parameters for the velocity and direction. You would typically show the exchange in a sequence diagram, with a call arrow from the sender to the receiver. The return message could just be label as ACK.
A «signal» Movement: Signals correspond to event messages. In a class diagram, they are represented like a class but with the «signal» keyword: velocity and direction would be attributes of that signal. ACK would be another signal. The classes that are able to receive the signals show it as reception (looks like an operation, but again with «signal» keyword).
In both cases, you would show the interactions of your communication protocol with an almost identical sequence diagram. But signals are meant for asynchronous communication and better reflect imho the nature of the communication. It's semantic is more suitable for your needs.
If you prefer communication diagram over interaction diagrams, the signal approach would be clearer, since communication diagrams don't show return messages.
Why signals is what you need (your edit)
With the diagrams, your edited question is much clearer. My position about the use of signals is unchanged: signals would correspond to the information exchanged between the computer and the car. So in a class diagram, you could document the «signal»Movement as having attributes id, velocity and direction:
In your sequence diagram, you'd then send and arrow with Movement (X,100,0). Signal allows to show the high level view of the protocol exchanges, without getting lost on the practical implementation details:
The implementation details could then be shown in a separate diagram. There are certainly several classes involved on the side of the computer (one diagram, the final action being some kind of sending) and on the side of the car (another diagram: how to receive and dispatch the message, and decode its content). I do not provide examples because it would very much look like your current diagram, but the send functions would probably be implemented by a communication controller.
If you try to put the protocol and its implementation in the same diagram, as in your second diagram, it gets confusing because of the lack of separation of concerns: here you say the computer is calling a send function on the car, which is not at all what you want. The reader has then difficulty to see what's really required by the protocol, and what's the implementation details. For instance, I still don't know according to your diagram, if setVelocity is supposed to directly send something to the car, or if its a preparatory step for sending the movement message with a velocity.
Last but not least, keep in mind that the sequence diagram represents just a specific scenario. If you want to formally define a protocol in UML, you'd need to create as well a protocol state machine that tells the valid succession of messages. When you use signals, you can use their name directly as state transition trigger/event.
If you really want to display this level of detail in a sequence diagram, it would look like this:
Notes:
For an asynchronous call, use an open arrowhead.
Use stacked bars to represent the call stack.
In the operation's argument list, write "argumentName=argumentValue" or just "argumentValue".
For messages for which the exact operation name is unknown or irrelevant, I use just a description without an argument list.
But be careful about which level of detail you want to show. Often, a sequence diagram becomes too complex if you display every operation in the call stack.
I was dealing with the same issue. I searched online and couldn't find something that I like. Hence I come up with this solution.
I show the communication ports on the sequence diagram and I draw communication dependent steps among port lines.
Here is a screenshot: my version of your problem.
Note: I haven't used bluetooth before so I am not sure about the acknowledge step. If this is something done automatically by the hardware( Like in the CAN Bus) I wouldn't draw it like this. I probabily wouldn't show it or I wouldn't add the function acknowledge(); and just draw the line between bluetooth port life lines.
So I was given a task of making a class diagram for a bicycle. I know what a class diagram is and the concepts behind one.
Now to me, a bike has three major components: the brake system, drive system and steering system. And each system has each own activators for actions: a brake handle, a pedal and a handlebar.
For my bike to actually brake, I need to go through the brake lever to trigger my brake system (pass data on how hard the lever is squeezed from the lever to the brake system). Same for the other two systems as well. This is what I've come up with so far:
My question: Is there a better way to illustrate the connection between the activators and the systems they're supposed to pass data to? Also the system works in isolation, meaning that external factors such as crashes or mechanical failures are not in the scope of the system.
Yes, there is "a better way to illustrate the connection between the activators and the systems they're supposed to" activate. These "activators" are, in fact, part of these subsystems. Consequently, you should not use plain UML associations on the first two levels of your composition break-down hierarchy, but rather UML composition relationships (with "black diamonds"), which are special associations representing part-whole relationships where parts are exclusive (= non-shareable).
Bicycle would be composed of BreakSystem, DriveSystem and SteerSystem. Then, for instance, BreakSystem would be composed of the "activator" BreakLever and Brake. Likewise, for the other subsystems.
Since you don't model a digital bike, better say that an activator (like break lever) causes a subsystem (like the break system) to react, instead of "activators are supposed to pass data to" these subsystems. In a mechanical system, it's about physical causation, and not about passing data.
See also https://www.uml-diagrams.org/composition.html for an explanation of the UML concept of composition, which often comes with, but does not imply, a life cycle dependency.
I have a system in which there is a controller and a robot that interact to do something. The system is self sufficient, in the sense that once online and functioning, the entity that we called controller takes decisions on its own on what the robot should do, so every "use case" in the diagram is "made" by the controller. Since the actor in a use case diagram is, by definition, an external entity that interact with the system, what is the right way to model my system with this diagram? The controller cannot be an actor since it's part of the system, but then how can I model the functionalities?
If the system is really autonomous you can ask it: what is the added value you get? I bet it can't answer. So it's not autonomous on itself (like you hopefully are). It acts on behalf of its constructor or purchaser. And they will have an added value. So that's the one perspective.
Now you implement a system. This is intended to fulfill the added value. It does not matter whether this is done autonomously or not.
What you can do, is to detail the system and construct technical use cases. So to control visual perception you have sub-systems with own use cases. Or to sense something. But that is a different level and not to be mixed up with the business logic behind it all.
According to UML specification sensor can be treated as an actor.
Your system presumably is not a complete black box. It reacts on some external events (usually - timer first of all) triggered by some sources. Straightforward way is to introduce sources of those events (timer, accelerometer, valves, etc) as actors who are triggering scenarios.
In your case the only involvement of such actors could be potentially denoted to only triggering the scenarios. If so take a shortcut and do not introduce the actors, just write in the use case trigger: "pressure drops below ..."
You may or may not want to separate the system actor to the robot and the controller actors (i.e. establish System under Discussion one level lower). Who will be reader of your documentation? Customers are not interested in what's inside the black box, but two development team writing each of the pieces will push you to separate and define precise interfaces.
Being new to telecommunication, this definition confused me as to what is the difference between a trunk and subscriber line. Please help! :)
definition of folded and non-folded network
Its not a particularly well explained term in that reference, but all it really means is that in a folded network the network is closed - in other words subscribers can only makes calls to other subscribers of the same network.
A non folded or open network means that subscribers can make calls to people outside the network being discussed.
Its mostly useful as a planning tool.
In real life, most network are not closed or folded for obvious reasons, although local exchanges might be modelled as closed or folded for planning and dimensioning purposes.
Dimensioning in telecoms is very important as telecoms equipment is traditionally expensive so most networks are blocking in one way or another - i.e. they are not engineered to allow every subscriber make a call at the same time as this would be a very rare occurrence and it would be costly to have much of the equipment sitting idle at all other times.
There is a better definition than the one you reference above with some diagrams etc here: http://www.newagepublishers.com/samplechapter/001222.pdf