I have Use case like this.
This is an Emergency Monitoring Use Case and actors, which one is the external system actors?
I just learn Use Case Diagram, and I think the answer is Monitoring Operator, But I confused with the another actor, especially Monitoring sensor and Remote System? Is Another actor an external system actor too? But the option just :
a. Remote System
b. Monitoring Operator
c. Monitoring Sensor
d. Generate Alarm
Can you give a link, so I can read it, too prove my answer is true / wrong.
An actor is always external to the system. An external system actor is a non-human actor.
In your diagram, the Monitoring operator seems to be a security agent looking at the screen and reacting to what's happening.
The Remote service seems to be a non-human actor that interact with some use case, probably to automatically feed data into the system:
The diagram has a syntactic error: the arrow from Remote System and Monitoring sensor to Remote service needs to be a generalization arrow (normally a big white triangle. A use case does not allow to associate actors between them). This means that both are special forms of Remote service.
All these three remote actors are therefore candidate for an external system:
However, Remote service seems meant here more as a placeholder for its specializations. You could therefore as well omit it.
If the sensor interacts with a system as an actor, it should be complex enough to be autonomous. This means that it's not a passive sensor but could be conisdered as a small active system. I would name it as well.
And of course, the Remote system is without a doubt an external system actor.
Related
In the latest requirement document of Execution Manager of adaptive Autosar,
I am confused about function group and application.
in the document it says about function group and application like below
(from https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_ExecutionManagement.pdf)
Function Group
A Function Group is a set of coherent Processes, which
need to be controlled consistently. Depending on the state of
the Function Group, Processes are started or terminated.
Processes can belong to more than one Function Group
State (but at exactly one Function Group).
"MachineState" is a Function Group with a predefined
name, which is mainly used to control Machine lifecycle and
Processes of platform level Applications. Other Function
Groups are sort of general purpose tools used (for example) to
control Processes of user level Applications.
,
Application
An implementation that resolves a set of coherent functional requirements and is the result of functional development. An Application is the unit of delivery for Machine specific configuration and integration.
These concepts are really confusing to me.
based on my understanding I categorized applications in this way.
system applications
user applications - multiple applications in function groups
user applications - other applications
but I'm not sure this is right or not. help me to get fully understand about
function group and application so that I can categorize applications in a right way.
In the end, it is all about functions in the vehicle, which are distributed over multiple ECUs, including supporting functions and ECUs in between.
In order to save battery power, not all ECUs need to be running all the time. But it could be, that some ECUs implement multiple functions.
e.g.:
SRR (Short Range Radar, well nowadays also more than 150m range!) ECUs in the rear do BSD (BlindSpotDetection), LCA (LaneChangeAssist), RCTA (RearCrossTrafficAssist Alert/Brake), Freespace Detection, Collision Avoidance, OccupantSafeExit, Object Detection Output for 360° Vision and Fusion e.g. for AutomatedDriving ...
CentralECU, like a 360° Vision/Fusion ECU for Automated Driving, which has several sensoric ECUs like front LRR (Long Range Radar), front Cameras and front and rear SRRs connected. If this ECU is also the gateway of for the sensoric ECUs, and the rear SRRs are used for OSE, then the front ECUs can be shutdown, and the CentralECU can at least shutdown several high performance cores/processors, except the ones needed for routing between vehicle and the rear SRRs. After the driver/passenger leave the car, they can then shutdown shortly after too.
For the above scenarios, other gateways might also be involved. And also the SRRs and CentralECU need to be aware of, that other ECUs are off and not providing data like vehicle speed, yawrate, steering angle etc. and therefore, the messages are not transmitted on the networks anymore. Rx/Tx deadline monitoring should be disabled for functions which are turned off. Functions that are shutdown also in these SRRs or CentralECUs should also stop their functional messages to be transmitted.
That is, why you could have in one application multiple functions grouped into one or more function groups, because the ECU could be involved in several of them.
At least the AUTOSAR Adaptive is for the CentralECU, the SRR ECUs usually are low-price ECUs, which just run AUTOSAR Classic. But there is similar handling through PartialNetworking, VirtualFunctionCLusters and NetworkManagement.
Consider the following case:
I have a webservice that provides information about orders in an online shop. On another machine there is a windows service that retrieves orders from the webservice once an hour and writes the data to a database. Instead of a scheduled task a windows service is used, because it provides a tcp endpoint, so a client can manually (using a simple desktop application) command the service to retrieve data of a specific order.
I am unsure where I have to place the windows service. It is a primary actor calling the webservice in a given interval, but it is a secondary actor as it reacts to the command of a client.
How should I proceed creating a Use-Case-Diagram for this scenario?
The answer depends on what you consider as your system.
One system
If your system contains both the webservice and windows service as parts of your (multi-tiered) system, then neither is an actor. The functionality offered by the windows service will be one (or more, depending on the complexity of the service) use case. If you assume that webservice it might become a second use case, that is included by the windows service (a rare case but works here).
The mere fact that those parts are on separate machined doesn't change a thing. It's common approach that database has it's separate machines but no-one reasonable consider it to be separate from the system itself.
Two systems
If you treat windows service as a separate system then you will actually have two use case diagrams, one for each of the systems.
In this case the use case diagram of windows service will have the client as a primary actor and system containing the webservice as a secondary actor.
In the use case diagram of the system with webservice your primary actor would be the windows service system (again as a whole , not a service itself). In this diagram the client is not depicted at all as it does not interact with the system.
Component as a system
Even if you consider both windows service and webservice as a single system, you may still depict use cases of components rather than the system as a whole. In such case the aproach will be similar to the situation with two systems.
In addition to what #Ister said: Draw a boundary that represents your system under consideration. Now think about what is inside (the use case bubbles) and what is outside (the actors). For the latter there's the convention to place the primary actors to the left and the secondary ones to the right. Primary actors are usually considered the ones that start a workflow while the secondary ones are being triggered/informed in the course of any such workflow.
Are there best practices for implementation of eventsourcing gateways? The gateway is meant as infrastructure or service which allows to generate a set of events, proceeding from the status returned by some external service.
Even if application based on eventsourcing, some external uncontrollable entitles can still be present. For example, you want to synchronize users list from Azure AD, and perform prompt to service, which return users list. Then you get users list from projection, make difference with external state, and produce events to fill this difference.
Or your application is online-shop, and you should import actual USD/EUR/bitcoin ranks for showing prices. Gateway can poll some currencies provider and produce event. In simple case it's very easy, but if projection state is more complex structure, trivial import is not obvious.
Maybe is there common approach for this case?
Building integration adapters that use poll-emit is normal and I personally prefer this way of doing integrations in general.
However, this has little to do with event sourcing, since what you actually need to solve your integration problems is to simulate the desired functionality that the external system will emit events on its own and you can build a reactive system that consumes these events.
When these events come to your system from the adapter - you can do whatever you want with them but essentially, event sourcing assumes that you store your own object's state in event streams but in case the event comes from some external system - it is not your state. You can derive your system state from external events but these will be your own events.
I'm trying to develop a web-app and some desktop apps, all of these apps communicates via database or socket tcp. These desktop apps are running in background so, there is no use cases and the web-app is only used by remote users.
And, these desktop apps communicates with the web-app via the DB and vis versa.
Which UML diagrams may help me to conceptualize the work of the desktop apps, please?
I've tried to conceptualize this thing using the deploiement diagram, but, I think that it's unsufficient to explain the whole work in a report. Isn't it ?
Thanks a lot!
If you read up on the theory of use case diagrams and actors, you will see that an actor (something that interacts with a use case) can be a person or another system.
In this case, since your app is running in the background, is must be triggered by something: by a person or by a job scheduler (=a system). That means that the triggering is done by an actor, since an actor can be a person or another software system.
So that means you have a use-case (your app) and an actor (scheduler or person). In that way your background app can be described as a use case in a use-case diagram, together with the rest of your system.
As Rolf Schorpion told, you can still use use case diagrams with systemic actors. Just make sure that actor is something external to the system (or part of the system). A typical actor can be Timer (if it is time-controlled).
Besides there is a plenty of UML-diagrams you can use. From the short desctiption you posted, I'd recommend the following set of diagrams (at least these are the diagrams I'd asked you to prepare in order to better understand the system you briefly described):
Mandatory:
Component diagram - showing structural organization of your system and their dependencies (desktop app, WEB app, DB are components)
Deployment diagram - showing the network organization, servers and how the previously defined components are actually deployed on server nodes
Sequence diagram(s) - showing the important communication scenarios between the components. You mentiones TCP, so this can be further refined and displayed using one or more sequence diagrams. It there is a standard communication pattern, a single sequence can be enough. Otherwise, several sequences can be used to cover all significant communucation scenaria
Optional:
Class diagrams - to specify internal components structure - design (blue print of the source code). I recommend this one only if there is a complex design in each compoennt, worth this effort. If not, it could be costly to keep the model in sync with the actual code.
State disgrams - if a class of componen show a behavior that could be modelled as a set of discrete states (e.g. ON, OFF, IN REPAIR, OUT OF ORDER), this diagram is very powerfull and highly recommendedn
Activity diagram - if you have some interesting non-trivial algorithms or simply want to show an overall system logic in terms of sequenced tasks, use activita diagrams.
These are the most common UML diagrams. Besides you have a couple of them more that couls be used in some special conditions (timing for example), but I'm sure you can model almost everything using only these. Use case is far from the first choice for UML modelling.
If you have some further questions or doubts, just ask.
I'm developing a 3 tier based system , the user passes data to the server which performs server side processing and queries a database etc the usual stuff. I'm wonder should I include the database in the diagram as an actor ?. I have already included the server as well as the end user
Thanks.
If you're developing the full system then no, don't include the DB as an Actor. I wouldn't recommend showing the Server either.
The purpose of a UCD is to show the system context in terms of the features (Use Cases) it supports and for whom those features are provided (Actors). UCDs deliberately don't show internal structure - so you focus on the Users and their Needs without getting sidetracked by implementation concerns.
Since the Server and DB are part of your system they're "design detail" for how you realise the Use Cases. Therefore the don't sit outside your system, therefore they're not Actors. The only time I'd recommend putting other systems on a UCD is when (a) they're external to the system you're building and (b) provide or receive some value to/from it.
UML provides other diagrams for showing the internal components of the system:
Deployment diagrams show physical hardware and allocation of software components to them
Component Diagrams allow you to show the logical structure of the application
Sequence Diagrams or Activity Diagrams allow you to show how a Use Case is realised in terms of its logical components
(Note I'm not suggesting you use all those, just what's useful).
hth.
i think the web servers and the database should labeled as the system, users or external third parties could be actors!