OOA&D: finding the systems and actors when multiple processes are involved

Question

I'm reading Applying UML and Patterns and trying to match the OOA&D principles in there to a project I've worked on. It is kind of a retroactive learning exercise.

The basic question I'm trying to answer is do I have the correct understanding of how to find the actors in this domain? Have I found them correctly?

The project's basic idea is to connect security alarms of various brands having generally similar behavior (although with significant differences) and distinct proprietary TCP protocols to a server or servers and control them via a mobile app (and also via a web application if you're not an end user).

So the user will be able to arm/disarm an alarm of any brand from her phone and perform similar commands, as well as be notified when the alarm goes off and other events. Additionally, events will be sent to monitoring centers (third-party). Users are clients of the monitoring centers.

An arm command sent by the phone will call a REST API which in turn will send the command to the server to be executed by interacting with the alarm through its protocol.

The server then exposes at least two ports, one for receiving commands and one for alarms of a given model to connect to it.

I see the following Systems under Discussion (SuD's): the mobile app, the web application containing the REST API, the model X alarms, the model Y alarms, the TCP server (there may be more than one).

The book talks about Primary actors. Those have user goals fulfilled through using services of the SuD.

I see the following primary actors:

• The user: her goal is to interact with the alarms through the mobile app.

• The mobile app: its goal is to interact with the alarms through the REST API.

• The web application: its goal is to command the panels through the TCP server and to register and manage users and alarms.

• The monitoring center: its goal is to register users and alarms.

• The administrator: its goal is to register monitoring centers and manage users and alarms.

The book talks about supporting actors. Those provide a service (for example, information) to the SuD.

I see the following supporting actors:

• The TCP server: accomplishes commands from the web application's REST API.

• The alarms: obey the TCP server.

Offstage actors: have an interest in the behavior of the use case, but are not primary or supporting. I see none.

Have I found the SuD's and actors correctly?

Answer 1

To some extent, this type of analysis is subjective, but becomes useful based on whether it truly helps people understand a system and either improve its design, eliminate problems, and/or enhance it beyond its current capabilities.

When a business has both a billing system and a payroll system, it is clear where to draw the line in the SuDs (Systems Under Design). Looking at this write-up, it feels to me as if you are trying to split apart what is essentially one system with a single goal into multiple SuDs simply for the sake of the exercise. My gut reaction is that what we have here is an alarm management system that interacts with both internal and vendor-owned system components. From this perspective, as written, there is only one goal and one SuD involved: "The Alarm Management System". The problem of connecting multiple brands is one of integration with external vendors, not one of system design.

Another way of looking at it is that integration with vendor products is complex enough to require a sub design in and unto itself. In this scenario, you may be looking at a "Vendor Communication System" and "An Alarm Management System." Which is right? That might require a review of architectural diagrams for the existing system to make this call.

Note that another analyst might divide this up differently. These are just my best interpretations of what you have written so far.

Actors have a specific goal within a system. In a database system, I may have software that performs queries against the DB using a specific login to perform some automated function without a user ever initiating the action. In that case, it would make sense for the software initiating the queries to be listed as an actor with the goal of its specific function being the "goal of the actor".

In this case, the mobile app and the web server feel like system components that are acted upon by administrators, security monitoring personnel, and end-users of the software service. Administrators manage user accounts, and as stated, do some kind of management of alarms. End users get to enable/disable alarms for all brands controlled by the over-arching system. Security monitoring personnel should be analyzed a bit more closely. Is this one role or several? What do they need to do and what info do they need to do it? These questions might allow for better elaboration of the actors within the monitoring centers.

For secondary actors, this article might help (see the revised definition after the original at the top):

https://blogs.oracle.com/oum/use-case-actors-primary-versus-secondary

To my way of thinking, the TCP servers and alarms might fit the earlier definition of secondary actors, but thinking about actual humans from the brands you are trying to control whose input might be needed to modify or enhance the system could better illuminate potential roadblocks to future design decisions.

I hope you find this helpful.