1

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?

  • What are you trying to accomplish with this mental exercise of rearchitecting an existing system? Do you hope to put forth a plan to actual implement it? Are you trying to determine the cost difference had you done it the other way? I'd caution against assuming that anything on paper is remotely realistic without actually writing an implementation. – user1118321 Feb 17 '18 at 17:03
  • @user1118321 I may implement parts of it for learning. I agree that it may not be realistic on paper but I already know the pitfalls of development and can expect them to guide the process. What I'm trying to do is to put the OOA&D theory to practice. The book sounds like it would be easier to do that in a project of a simple web application backed by a database, I'm having difficulty translating its teachings to a multi-process system. – Piovezan Feb 17 '18 at 17:15
  • OOA&D is about breaking down a problem into a solution. You're asking for an architectural analysis to decide which of two working designs is better. OOA&D doesn't do that. It just gives you something that works while avoiding some common pitfalls. You'll find out which is better when you try maintaining both. – candied_orange Feb 18 '18 at 5:09
  • 1
    @Piovezan I wish I shared your faith. But all to often I've seen total nightmares created in the name of "following a method". Having a method isn't enough to ensure that the result is better. It must be a good method, it must be an understood method, and it must be a well applied method. And even then it is genuinely difficult to make an objective case about what makes the results better. The goal is working maintainable code. I can follow a good method faithfully and produce working code that causes you problems because I'm the only person on the planet that understands this method. – candied_orange Feb 18 '18 at 10:00
  • 2
    @Piovezan your personal improvement ambitions are not unreasonable. But I am hard pressed to think of a good way to answer this question. We like questions that are useful for others. – candied_orange Feb 18 '18 at 13:19
2

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.

  • Thank you very much for your answer. I agree that the system seems to perform one cohesive function. Regarding "The problem of connecting multiple brands is one of integration with external vendors, not one of system design", I'm not sure I agree; because the integration may affect the design (connecting everything to a single server or multiple servers). – Piovezan Feb 22 '18 at 19:50
  • One single server means every update will cause all alarms to mass reconnect instead of isolating by brand (unless some sort of dynamic classloading be adopted); on the other hand, code updates affecting all brands must be replicated across every brand's source code. To me those are all design decisions and not only integration decisions. – Piovezan Feb 22 '18 at 19:50
  • You mention the possibility of creating a separate "Vendor Communication System" which might require a review of architectural diagrams. This may be the subject of another question if the answer is not so straightforward, but since I'm not experienced at architecturing systems (other than this one), I'd need information on what to read about architecture to produce such diagrams and decide this. – Piovezan Feb 22 '18 at 19:51
  • I agree that administrators, security monitoring personnel, and end-users may be the actual primary actors, not the mobile app or the web application. However this comes from the requirements only and architecture says nothing about integration between those different software applications. I understand the objective of the book is not to discuss architecture but I miss a more detailed discussion of the requirements in terms of architecture, in which those integrations are discussed, for example. – Piovezan Feb 22 '18 at 19:51
  • Finally, could you please clarify this part? "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." – Piovezan Feb 22 '18 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.