This article provides an overview of UML State Machine Diagrams (SMDs), explaining their use in modeling the dynamic behavior of systems in software engineering. It covers the key concepts of SMDs, including notation, construction steps, common errors, and their relationship to sequence diagrams. Alexander S. Ricciardi February 8, 2025 In software engineering, Unified Modeling Language (UML) state machine diagrams, also known as state diagrams or statecharts, are used to model the dynamic of systems both in the problem space (MOPS) and the solution space (MOSS) (Unhelkar, 2018). UML State Machine Diagrams are helpful for visualizing how objects change state over time. This post explores UML State Machine Diagrams, including their notation, construction steps, common errors, and relationship to UML sequence diagrams. State Machine Diagrams Overview UML State Machine Diagrams (SMDs) are behavior diagrams that show the discrete behavior of a system by depicting the state transitions of a part of that system (UML®, n.d.). Two kinds of state machines are defined in UML. 2.5, behavioral state machine and protocol state machine. A behavioral state machine focuses on event-driven transition of an object (Dwivedi, 2019). A protocol state machine is a behavioral state diagram that specializes in modeling the sequence of event-driven transition of an object. This post focuses on behavioral state diagrams as they are more widely used and the notations of the two types are very similar. In software modeling, SMDs provide a dynamic illustration of the object within a system. They are used in MOPS (Model of Problem Space) to model the state states, conditions, and transitions of system entities, and in MOSS (Model of Solution Space), they are used to model the states, conditions, and transitions of objects including interface and control objects (Unhelkar, 2018). In other words, they are used to visualize the different states of objects within a system and how, in response to events, they transition between those states. Various components are utilized to create SMDs, the table below lists the main components that can be found in SMDs. Table 1 UML SMD Basic Notation Note: This table provides an illustration and a description of the basic notation elements that can be found within state machine diagrams. From several sources (Unhelkar, 2018; Dwivedi, 2019; GeeksForGeeks, 2025; Visual-Paradigm, n.d.; IBM, 2023, FastBitLab, 2022). When building an SMD, it is generally a good practice to follow these steps: Select an important/complex object. Understand the different stereotypes present in the selected object (Entity, boundary, control, or table). Identify states based on attribute values from the class documentation. Figure out how the object changes state. Draw transitions between states. Specify conditions for transitions, aka guards and related events and triggers. Group related states hierarchically using composite states. Clarify the diagram by adding notes. Consider modeling other objects/use cases. (Unhelkar, 2018) The table below lists the most common errors that can be made while building an SMD and how to rectify them. Table 2 SMD Common Error and Rectifications Note: The table lists the most common errors made while constructing an SMD and how to rectify them. From “Chapter 12 — Dynamic modeling With state Machine Diagrams. Software Engineering with UML” by Unhelkar (2028). Modified. The diagram below is an example of an SMD illustrating an online shopping order’s states. Figure 1 SMD Example of an Online Shopping Order Note: The figure is an illustration of a UML State Machine Diagram (SMD) depicting the states of an online shopping order. SMDs vs Sequence Diagrams Another type of UML diagram used to represent the dynamic aspect of a system is the sequence diagram. Sequence diagrams “provide a dynamic illustration of object interactions within a system. In SE, they are usually based on UML class diagrams and are used primarily to show the interactions between objects (classes) in the chronological order in which those interactions occur” (Ricciardi, 2025, p.1). These diagrams are also used in the MOPS to model the behavior of systems from the actors’ (users) perspective and in the MOSS to model objects' interactions in detail; details such as the sequence of messages (methods) within a system, the parameter list within messages, and the return values of the messages. Both the SMDs and sequence diagrams are useful for modeling the dynamic aspects of a system and depending on the specific needs of analysis and design task one is more suited than the other one. For example, to model the internal behavior of a single object, a state machine diagram is best, whereas to model multiple objects and the sequence of operations within a system, a sequence diagram is the better choice. To summarize, SMDs are used to understand and model the dynamic behavior of systems, particularly the state changes/transitions of individual objects. They help to model the states, transitions, events, and guard conditions of a system. Thus, software engineers need to understand the common errors that can occur when building SMDs and best practices, as well as the relationship to other UML diagrams like sequence diagrams. Ultimately, SMDs are a powerful tool for analyzing (in MOPS) and designing (in MOSS) the dynamic behavior of individual objects within systems. References: Dwivedi, N. (2019, September 9.). Software design: Modeling with UML. State machine diagram. Modeling with the Unified Modeling Language (UML) . LinkedIn Learning. https://www.linkedin.com/learning/software-design-modeling-with-uml/state-machine-diagram?u=2245842 FastBitLab (2022, January 20). FSM Lecture 11- UML state machine types of transitions. FasBitLab. https://fastbitlab.com/fsm-lecture-11-uml-state-machine-types-of-transitions/ GeeksforGeeks (2025, January 3). State machine diagrams | Unified Modeling Language (UML). GeeksforGeeks. https://www.geeksforgeeks.org/unified-modeling-language-uml-state-diagrams/ IBM (2023, September 2018). Creating transitions between states. IBM DevOps Model Architect. IBM Documentation. https://www.ibm.com/docs/en/dma?topic=diagrams-creating-transitions-between-states Ricciardi, A. (2025, January 27). A Guide to UML Sequence Diagrams: Notation, strengths, and Limitations. Code Chronicles - Omegapy. https://www.alexomegapy.com/post/a-guide-to-uml-sequence-diagrams-notation-strengths-and-limitations UML® (n.d.) State machine diagrams . UML diagrams. UML Diagrams Org. https://www.uml-diagrams.org/state-machine-diagrams.html Unhelkar, B. (2018). Chapter 12 — Dynamic modeling with state machine diagrams. Software engineering with UML . CRC Press. ISBN 9781138297432 Visual-Paradigm (n.d.). What is state machine diagram? Visual-Paradigm . https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/

This article explores the differences between Object-Oriented Databases (OOMDBs) and Relational Databases (RDBMS), highlighting their strengths and weaknesses and examines how Object-Relational Mapping (ORM) techniques can be used to bridge the gap between Object-Oriented Programming (OOP) and Relational Databases. Alexander S. Ricciardi January 30, 2025 Software engineers need to have a good understanding of how Object-Oriented Programming (OOP) relates to Object-Oriented Databases (OBDMS) and Relational Databases (RDBMS) to design efficient software systems . This article explores the core principles of the Object-Oriented concept (OO), the advantages and disadvantages of OBDMS and RDBMS, and Object-Relational Mapping (ORM) techniques for mapping object-oriented data to RDBMS. Overview of the Object-Oriented Concept In Software Engineering (SE), the Object-Oriented concept (OO) is a paradigm where systems and real-world entities (e.g. users) are defined as “objects.” These objects are abstractions that, in the context of a software application, encapsulate both data (attributes) and operations that can be performed on that data (methods). The data are the attributes that define the characteristics of the objects and the operation on the data are the methods (procedures or functions) that define the behavior of an object (Colorado State University Global, n.d.). In other words, objects contain both executable code (methods) and data (attributes). OO is composed of six main concepts: Classification ꟷType of objectꟷ Abstraction ꟷ Hiding the object's internal implementation details, including some of its attributes and the functionalities of its methods, while representing those attributes and methods internally ꟷ Encapsulation ꟷDefining the boundary of an object (modularization), defining an object’s attributes and methodsꟷ Association ꟷRelationships defining objects' interactions with each otherꟷ Inheritance ꟷRelationships defining objects as a generalization (parents) of other objects (children)ꟷ  Polymorphism ꟷHow objects respond differently to the same message (same method call)ꟷ The Differences Between OO, OOP, and OODB (ODBMS) Object-Oriented Programming (OOP) embodies the principles of the OO concept. OOP is a style of programming that encapsulates data (attributes) and code (methods) within classes which are blueprints for creating (instantiate) objects. In other words, the OO approach is a general concept, OOP is a specific way of implementing it. On the other hand, Object-Oriented Databases (OODBs) also called Object Database Management Systems (OBDMS) “store data as objects, similar to how certain programming languages manage data. Instead of tables with rows and columns like traditional databases, object databases use complex data structures to represent data” (MongoDB, n.d.). Overview of Object-Oriented Databas e OBDMS are databases based on the OO paradigm and store data as objects. They are “able to store objects together with their attribute values, operations, and relationships” (Unhelkar, 2018, p.219). The databases store objects “as they are” preserving the object's structure. In SE, this facilitates the design of OO-based software systems, as objects can be loaded directly from the database into memory and executed "as they are." This is useful in software design because, in addition to storing object-based data, OBDMS can directly store (“as they are”) other complex data types like Binary Large Objects (BLOBs) and unstructured data (e.g., video and audio). Unlike relational databases that use a tabular (rows and columns) format, which is not suited for storing these two data types. OBDMS have several other advantages besides storing complex data, as well as disadvantages, the table below lists these advantages and disadvantages. Table 1 ODBMS Advantages and Disadvantages Note: The table lists the advantages and disadvantages of Object Database Management Systems (ODBMS). From several sources (Colorado State University Global, n.d.; Unhelkar, 2018;  Worldlovely, 2024; Akshitakumawat, 2023) As shown by Table 1, OBDMS are ideal for storing complex data such as complex unstructured data (AD/CAM, multimedia, scientific databases). However, they lag the standardization, the simplicity, and the relatively low cost found in Relational Databases Management Systems. Overview of Relational Database Relational Databases (RBs) also called Relational Databases Management Systems (RDBMS) are databases that store and organize predefined relationships in the form of tables that store data points in pre-defined categories through rows and columns (Microsoft, n.d.; Google n.d.).  Relationships are established through logical connections between tables, typically using primary keys and foreign keys. RDBMS structure data based on these relationships, making it easier to query and manage data using Structured Query Language (SQL). RBMS uses the concept of primary key and foreign key. A primary key is a unique identifier for each record in a table (each row) (InterSystems, n.d.). A foreign key establishes a link between two tables, allowing related data to be accessed using the keys. RBMS have several advantages and disadvantages, the table below lists some of them. Table 2 RDBMS Advantages and Disadvantages Note: The table lists the advantages and disadvantages of Relational Databases Management Systems (InterSystems, n.d.; Pedamkar, 2023;  EASA, 2022; Google, n.d.; OCI, 2021; Singh; 2024, Pedamkar, 2023; Goray, 2012) RDBMS can be used to store object-based data; however, they store data in tables that are structurally different from objects, requiring objects to be translated from classes to tables (Unhelkar, 2018). Additionally, the data and behavior represented by a class cannot be directly transferred to a table because relational databases can only store data. However, it is possible to map object-oriented designs into RDBMS, but it is a difficult task. Mapping Objects to RDBMS Object-Relational Mapping (ORM) is a technique that bridges the gap between OOP and RDBMS (Rajputtzdb, 2024). One of the simplest ORM forms of mapping is one-to-one mapping, where classes are mapped to tables, class attributes are mapped to the table columns, and the instantiated objects are mapped to rows in the corresponding table. See Figure 1 for an example of it. Figure 1 RDBMS Object Mapping  Note: The figure depicts how objects are mapped to RDBMS table using the ORM One-To-One mapping form. To map and simulate object behavior with RDBMS ORM combined with the CRUD functions can be implemented. ORM the association relationships between classes using the foreign key in tables. The figure below depicts how foreign keys emulate the association relationship between classes Figure 2 Foreign Keys and OO Association Relationship  Note: the figure depicts how foreign keys emulate OO association relationships. To emulate the aggregation and other association relationships within RDBM, CRUD functions which stand for Create—creates an object. Read—search for an object (record) from storage based on a criterion (key). Update—search and update objects (records). Delete—locates and remove a persistent object  (Unhelkar, 2018) These operations are executed using languages such as SOL. The figure below depicts a class diagram illustrating how CRUD operations and association relationships are linked to RDBMS. Figure 3 CRUD and RDBMS Class Diagram Note: The figure depicts a class diagram illustrating how CRUD operations are emulated within objects and how association relationships are linked to RDBMS using CRUD and key attributes. To summarize, Object-Oriented Databases (ODBMS) directly support object data types; on the other hand, Relational Databases (RDBMS) are prevalent due to their widely adopted standards and robustness; however, they store data in tables that are structurally different from objects, requiring objects to be translated from classes to tables. Nonetheless, Object-relational mapping (ORM) allows RDBMS to effectively manage object-oriented data by bridging the gap between objects and tables.  References: Akshitakumawat (2023, May 1). Definition and Overview of ODBMS. GeeksForGeeks. https://www.geeksforgeeks.org/definition-and-overview-of-odbms/ Colorado State University Global (n.d.). Module 7.1  Data Storage Mechanisms. [Interactive lecture]. CSC470 Software Engineering, CSU Global, Departement of Computer Science. Canvas. Retrieved January 29, 2025, from: https://csuglobal.instructure.com/courses/104036/pages/7-dot-1-data-storage-mechanisms?module_item_id=5372300 EASA (2022, January 25). 8 advantages of a Relational Database. EASA Blog. https://www.easasoftware.com/insights/8-advantages-of-a-relational-database/ Google (n.d.). What is a relational database? Google Cloud. https://cloud.google.com/learn/what-is-a-relational-database InterSystems (n.d.). What is a relational database and why do you need one? InterSystems. https://www.intersystems.com/resources/what-is-a-relational-database/ Microsoft (n.d.). What is a relational database? Microsoft Azure. https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-relational-database MongoDB (n.d.). The basics of object-oriented databases. MongoDB. https://www.mongodb.com/resources/basics/databases/what-is-an-object-oriented-database#:~:text=An%20object%2Doriented%20database%20stores,data%20structures%20to%20represent%20data . OCI (2021, June 18). What is a relational database? (RDBMS)? Oracle. https://www.oracle.com/database/what-is-a-relational-database/ Pedamkar, P. (2023, July 6). Relational database advantages. EDUCBA. https://www.educba.com/relational-database-advantages/ Rajputtzdb (2024, February 28) What is Object-Relational Mapping (ORM) in DBMS? GeeksForGeeks. https://www.geeksforgeeks.org/what-is-object-relational-mapping-orm-in-dbms/ Singh, P. (2024, April 24). 15 Advantages and Disadvantages of RDBMS. Internshala Trainings Blog. https://trainings.internshala.com/blog/advantages-and-disadvantages-of-rdbms/ Goray, S. (2021, December 10). Top 10+ Advantages and Disadvantages of Using RDBMS. WAC. https://webandcrafts.com/blog/advantages-disadvantages-rdbms Unhelkar, B. (2018). Chapter 13 — Database modeling with class and sequence diagrams. Software engineering with UML . CRC Press. ISBN 9781138297432 Worldlovely (2024, December). Database management system [Discussion Post]. Hack The Forum. https://www.hacktheforum.com/database-management-system/object-oriented-dbms/#google_vignette

This article explores polymorphism in object-oriented software development, differentiating between compile-time and run-time polymorphism types, and describing the four categories of polyformism: subtype, ad hoc, parametric, and coercion. It also examines how UML class diagrams and pseudocode can be used to illustrate polymorphic relationships. Alexander S. Ricciardi January 19, 2025 In object-oriented software development, complex dependencies can exist between classes or objects (the instantiation of those classes) due to inheritance, association, and aggregation relationships (Labiche et al., 2000). Inheritance, in particular, often creates complex dependencies. However, polymorphism can be used to manage these dependencies particularly those related to inheritance. This article explores the concept of polymorphism within computer science, more specifically within object-oriented software development, through the use of pseudocode and UML class diagrams. Overview of Polymorphism in Computer Science The term polymorphism is derived from the Greek words "poly," meaning "many," and "morph," meaning "form" translating in English to many many-shape or many-forms. In computer science, polymorphism refers to the ability of data or a system to be processed in more than one form. Within computer science, polymorphism is an essential part of Object-Oriented Programming (OOP), it allows objects to respond to the same message (or method call) in their own way (Gupta, 2024). This polymorphic behavior can be achieved at compile-time, for example, through parameter overloading (static polymorphism), or at run-time through operator overloading and method overriding (dynamic polymorphism). Compile-time polymorphism, or static polymorphism, is when multiple methods have the same name but have different parameter numbers, types, or both (a method can handle values of many types without needing to be overridden). Whereas, compile-time polymorphism, or dynamic polymorphism, is when the functionality of a method is determined at runtime by the object invoking it. This type of polymorphism, method overring, is typically associated with the inheritance relationship, interfaces, and abstract class. It is important to understand that the relation between an interface and a class is a contract that specifies what the class should do based on a set of methods declared in the interface. Inheritance is a parent-child relationship or "is-a" relationship where the child class inherits the methods of the parent class. An abstract class is a class that can not be instantiated on its own, it is a superclass that serves as a blueprint for subclasses by defining methods, the relation between an abstract class and its subclass is a parent-child relationship. Types of Polymorphism in OPP Compile-time polymorphism and run-time polymorphism describe ‘when’ an object is transformed, but they also define ‘what’ component of an object is transformed. The ‘when’ and ‘what’ of an object transformation can be categorized into four different Polymorphism types. Figure 1 illustrates these four types and how they are related. Figure 1 Types of Polymorphism Note : The relationships illustrated in the diagram by the arrows are parent-child relationships. The inheritance relationships illustrated in Figure 1 are generalized and simplified illustrations of the relationships that exist between the different types of polymorphism. These relationships can be more complex depending on the programming language used to develop a particular software. Table 1, below, shows a more detailed description of the different types. Table 1 Types of Polymorphism Descrptions Note: Data from several sources(Johnson, 2020; Gupta, 2024; Umbarger, 2008) As shown in Table 1 defining the specific type of polymorphisms used by a relationship can be challenging and is often related to the programming language used to develop the software. Polymorphism in Software Development In software engineering, polymorphism is a fundamental concept that is defined as “the ability of an instantiated object (at runtime) to understand and interpret the message sent from a calling object. This interpretation of a message by an object depends on its own characteristics and definition” (Unhelkar, 2018 b, p. 182). When incorporating polymorphism in software design tools such as pseudocode and Unified Modeling Language (UML) class diagrams are often used to visualize and document polymorphic relationships. Pseudocode is defined as a step-by-step description of an algorithm (Kartik, 2024). It helps programmers to design easy-to-understand and easy-to-read code solutions to the problems. UML Class Diagram Overview UML class diagram is one of six types of structural diagrams used in software engineering (IBM, 2021). They are one of the most important diagrams as they can be used to model a software system's static structure (Shmallo & Shrot, 2020). In other words, they are the blueprints of systems and their subsystems (Ricciardi 2025). Moreover, in software engineering, they can be used within the problem space and the solution space. The table below describes the different components found in UML class diagrams. Table 1 UML Class Diagram Notation Note: This figure illustrates the different notation elements found in ULM class diagrams. From “UML Class Diagrams: Modeling Systems from Problem Space to Solution Space” by Ricciardi (2025). As shown in Table 1 UML class programs provide an extensive set of notations that can be used to represent classes (objects/entities), their attributes, their operations, and various types of relationships between them. Polymorphic Class Diagrams Polymorphic class diagrams are used within the solution space to illustrate polymorphic relationships. These diagrams must contain inheritance relationships, interfaces, abstract classes, or a partial or full combination of the three. The figure below, Figure 2, is a ULM class diagram of a simple order system. Figure 2 Order UML Class Diagram Note: the figure illustrates a shopping order system UML Class Diagram. Made with Lucidchart app. As shown in Figure 2, class diagrams do not show directly polymorphism details, they imply polymorphism such as subtype polymorphism by restating a parent method in a child class. For example, the child class CreditCarPayment restates the method processPayment(Double: amount) inherated from its parent abstract class ElectronicPayment implying that the method is overridden by it. To illustrate polymorphism in detail, developers often use pseudocode, which allows them to demonstrate the specific logic and behavior of each method. Example Pseudocode Psudeocode is unusually used in combination with class diagrams. Depending on the developers' preference, pseudocode can be generated before, after, or during the creation of class diagrams; however, both tools are used to develop the software source code in the programming language chosen for the project. Below is an example of the simple order system pseudocode. This pseudocode example focuses on illustrating, using mostly comments, where subtype polymorphism is implemented, rather than detailing the functionality of each method. Code Snippet 1 Simple Order System Pseudocode //------------------------------------------------------------------------------ // Order Class //------------------------------------------------------------------------------ class Order: private String orderId private Date orderDate private String orderStatus private Double amount private Boolean isPaid := false private Payment payment := Payment() // an object of the class Payment is instantiated // payment is declared as the parent type, // Subtype Polymorphism potential - Run-time Polymorphism // Constructor Order() //... Constructor logic calculateAmoun() // Runs methods protected calculateAmount(): amount := // ... Logic to calculate the amount public addPayment(String type, Payment paymentToAdd): payment := paymentToAdd(type, amount) isPaid := true //------------------------------------------------------------------------------ // Payment Class //------------------------------------------------------------------------------ class Payment: private String paymentId private String paymentType // Constructor Payment() //... Constructor logic //------------------------------------------------------------------------------ // PaymentProcessor Interface //------------------------------------------------------------------------------ Interface Class PaymentProcessor: /* The abstract keyword means the methods have no functionality implemented Subtype Polymorphism - potential (compile-time) */ public processPayment(Double amount): //... No logic implementation //------------------------------------------------------------------------------ // ElectronicPayment Abstract Class //------------------------------------------------------------------------------ abstract class ElectronicPayment extends Payment implements PaymentProcessor: private String transactionId private String electronicPaymentType // Constructor ElectronicPayment() //... Constructor logic // Subtype Polymorphism - Run-time Polymorphism @override public processPayment(Double amount) //... Logic to process electronic payment returns true //------------------------------------------------------------------------------ // CashPayment Class //------------------------------------------------------------------------------ class CashPayment extends Payment implements PaymentProcessor: // Constructor CashPayment() //... Constructor logic // Subtype Polymorphism - Run-time Polymorphism @override public processPayment(Double amount) //.... Logic to process a cash payment return true //------------------------------------------------------------------------------ // CreditCardPayment Class //------------------------------------------------------------------------------ class CreditCardPayment extends ElectronicPayment: private Integer cardNumber private Date expirationDate // Constructor CreditCardPayment(I) //... Constructor logic // Subtype Polymorphism - Run-time Polymorphism @override public processPayment(Double amount) /* ... Logic to process electronic payment ... Adds logic for to process credit card payment using cardNumber, expiryDate, and Amount */ return true /* Subtype Polymorphism - Run-time Polymorphism and Parametric Polymorphism (method-parameter overloading) - Compile-time Polymorphism */ @override public processPayment(Double amount, String currency) /* ... Logic to process electronic payment ... Adds logic for processing credit card payments using cardNumber, expiryDate, amount, and currency type */ return true //------------------------------------------------------------------------------ // PayPalPayment Class //------------------------------------------------------------------------------ class PayPalPayment extends ElectronicPayment: private String email // Constructor PayPalPayment() //... Constructor logic // Subtype Polymorphism - Run-time Polymorphism @override public processPayment(Double amount) : Boolean /* ... Logic to process electronic payment ... Adds logic to process PayPal payment using email */ return true //------------------------------------------------------------------------------ // Main class - Example usage of the code //------------------------------------------------------------------------------ class Main: public static main(): // 1. Create Orders (instantiate Order objects) Order myOrder1 Order myOrder2 Order myOrder3 / / 2. Create Payments (instantiate Payment objects) Payment payment1 Payment payment2 Payment payment3 /* 3. Let's assign electronic and cash payments to payment objects The compiler will check for these payment objects' relationships Payment class and the PaymentProcessor interface. It will ensure that the objects inherit all the methods defined in the abstract class (ElectronicPayment) and the methods declared in the interface (PaymentProcessor) As the inherited methods are transformed by the ElectronicPayment class, This can be considered Subtype Polymorphism (Run-time Polymorphism) Note that the electronic payment objects are instantiated as Payment/ElectronicPayment Objects with ElectronicPayment class functionality, as ElectronicPayment is an abstract class and it cannot be instantiated on its own. */ Payment1 := new ElectronicPayment() Payment2 := new ElectronicPayment() Payment3 := new CashPayment() /* 4. Let's assign credit card payments to electronic payments. This object inherited all the methods from Payment/ElectronicPayment objects, As the inherited methods are transformed by the CreditCardPayment class, this is can be considered a Subtype Polymorphism (Run-time Polymorphism) */ Payment1 := new CreditCardPayment() Payment2 := new CreditCardPayment() // 5. Let make a payment payment2.processPayment(myOrder3.amount) // cash /* => subtype of ElectronicPayment using the interface PaymentProcessor (Subtype Polymorphism - run time) */ payment1.processPayment(myOrder1.amount) /* => subtype of ElectronicPayment using the interface PaymentProcessor (Subtype Polymorphism - run time) */ // Use the overloaded processPayment payment2.processPayment(myOrder2.amount, "Euro") // currency /* => subtype of ElectronicPayment using the interface PaymentProcessor (Subtype Polymorphism - run time) => and method - parameter overloading (Compile-time Polymorphism) */ // 6. Assigned payment to order (aggregation) myOrder1.addPayment(payment1) myOrder2.addPayment(payment2) myOrder3.addPayment(payment3) Note: The code snippet is the pseudocode for a simple shopping order system. Polymorphism at Run-time Polymorphism at run-time is achieved through dynamic polymorphism, where the specific method to be executed is determined during program execution rather than at compile time. As shown by the Code Snippet 1 and Figure 1, in the context of SE, both tools are needed to show polymorphism at run-time. The class diagrams illustrate the relationships between classes, especially inheritance, a child-parent relationship, which is a fundamental concept in OOP and object-oriented design allowing classes to be derived from others, gaining their attributes and methods (Fallucchi & Gozzi, 2024). The inherited methods can be overridden by the child class at run-time, demonstrating subtype polymorphism (run-time polymorphism a type of dynamic polymorphism). This is also applicable to interfaces such as the interface classes in the Java programming languages. In the programming language C++, for example, “dynamic polymorphism is implemented by adding the virtual keyword to the function that is intended to be overridden” (Masri et al., 2918, p. 241). Additionaly, class diagrams can imply subtype polymorphism by restating a parent method in a child class. On the other hand, pseudocode can show polymorphism by illustrating the detailed behavior of a piece of code or a method. Therefore, in object-oriented design, both tools a re essential to completely represent and fully model the polymorphic structures of a system. Conclusion In object-oriented software development, the classes’ inheritance, association, and aggregation relationships create complex dependencies and polymorphism can be used to manage these dependencies particularly those related to inheritance. In computer science, polymorphism is the ability of a system to offer the same interface for accessing different underlying data, objects, processes, or functionalities forms; it is a cornerstone of object-oriented programming. Therefore, it is essential for software developers to understand the role polymorphism plays in OOP, to be capable of identifying and utilizing different types, such as subtype, Ad hoc, parametric, and coercion polymorphism. Furthermore, it is crucial to understand the difference between static and dynamic polymorphism and how to use tools like class diagrams and pseudocode to illustrate polymorphic relationships within systems. Ultimately, a firm understanding of polymorphism, coupled with the use of modeling tools like UML class diagrams and pseudocode, allows developers to analyze complex systems and tackle challenging software design projects. References Fallucchi, F., & Gozzi, M. (2024, June 11). Puzzle Pattern, a Systematic Approach to Multiple Behavioral Inheritance Implementation in Object-Oriented Programming . Applied Sciences, 14(12). https://doi.org/10.3390/app14125083 Gupta, E. (2024, March 11). Difference between inheritance and polymorphism. Shiksha online. https://www.shiksha.com/online-courses/articles/difference-between-inheritance-and-polymorphism-blogId-153349 IBM (2021, March 5). Class Diagrams. Rational software modeler. IBM Documentation. https://www.ibm.com/docs/en/rsm/7.5.0?topic=structure-class-diagrams Johnson, J. (2020, October 23). Polymorphism in programming. BMC Blogs. https://www.bmc.com/blogs/polymorphism-programming/ Kartik, (2024, September 12). What is pseudocode: A complete tutorial. GeeksForGeeks. https://www.geeksforgeeks.org/what-is-pseudocode-a-complete-tutorial/ Labiche, Y., Thévenod-Fosse, P., Waeselynck, H., & Durand, M.-H. (2000). T esting levels for object-oriented software. Proceedings of the 22nd International Conference on Software Engineering, 136–145. https://doi.org/10.1145/337180.337197 Masri, S. A., Nadi, S., Gaudet, M., Liang, X., & Young, R. W. (2018). Using static analysis to support variability implementation decisions in C++. Proceedings of the 22nd International Systems and Software Product Line Conference - Volume 1, 236–245. https://doi.org/10.1145/3233027.3233043 Ricciardi, A. (2025, January 18). UML class diagrams: Modeling systems from problem space to solution space. Omegapy. https://www.alexomegapy.com/post/uml-class-diagrams-modeling-systems-from-problem-space-to-solution-space Shmallo, R. S., & Shrot, T. (2020). Constructive Use of Errors in Teaching the UML Class Diagram in an IS Engineering Course. Journal of Information Systems Education, 31(4), 282–293. https://doi.org/https://www.jise.org/Volume31/n4/JISEv31n4p282.html Umbarger, D. (2008). An Introduction to Polymorphism in Java [PDF]. Computer Science Teacher. The College Board. https://apcentral.collegeboard.org/media/pdf/Intro_to_Polymorphismin_Umbargar.pdf Unhelkar, B. (2018 a). Chapter 1 — Software engineering fundamentals with object orientation. Software engineering with UML. CRC Press. ISBN 9781138297432 Unhelkar, B. (2018 b). Chapter 11 — Class model-3: Advanced class designs. S oftware engineering with UML . CRC Press. ISBN 9781138297432

This article provides an overview of UML sequence diagrams, explaining their notation, strengths, and limitations in modeling dynamic system interactions. It also demonstrates their practical application through a detailed case study of a doctor-patient examination workflow within a Hospital Management System, including a corresponding class diagram and pseudocode. Alexander S. Ricciardi January 31, 2025 Unified Modeling Language (UML) sequence diagrams are extensively used in Software Engineering (SE) to model the dynamic interactions of objects within systems. They illustrate a sequence of messages between objects within an interaction (IBM, 2021). This essay provides an overview of UML sequence diagrams and a UML sequence diagram, along with its related pseudocode and class diagram, illustrating a doctor-patient examination interactions workflow within a hospital management system. UML Sequence Diagrams Overview UML Sequence Diagrams “are usually based on UML class diagrams and are used primarily to show the interactions between objects (classes) in the chronological order in which those interactions occur” (Ricciardi, 2025, p. 1). They provide a dynamic illustration of the interactions between classes (objects) within a given period of time. In SE, they are used, in the problem space, to analyze and model system behavior from the actor’s (user’s) viewpoint (Unhelkar, 2018). In the solution space, they are used to illustrate interactions within a system in more detail, such as the sequence of the inquiry messages illustrating method calls, the parameter messages within those methods, and the value returned by those methods. The diagram uses a system of notation such as actors (classes), lifelines (timelines), arrows denoting messages or method calls between these lifelines, activation bars indicating method execution, and optional annotations for conditions, loops, or return values. These elements work together to illustrate the flow interaction within a system. The elements are arranged vertically to illustrate the chronological order of interactions and horizontally to reflect the direction of the interactions between objects. The figure below, Figure 1, depicts the main elements of a UML sequence diagram. Figure 1 UML Sequence Diagram Notation Elements Note: The figure illustrates the elements that can be found in UML sequence diagrams and how they may interact within a diagram. From “A Guide to UML Sequence Diagrams: Notation, Strengths, and Limitations” by Ricciardi (2025). It is important to note that classes’ and objects' names are underlined and they can be illustrated by a stick figure for outside actors and internal actors can be encapsulated in a rectangle or represented by various circular shapes or icons representing specific stereotypes (e.g. boundary, control, and entity). A stereotype in UML “denotes a variation on an existing modeling element with the same form but with a modified intent” (Agile Modeling, 2023, p.1). Usually, stereotypes are represented using guillemets (<< >>) encapsulating a keyword; for instance, the specific stereotypes of a sequence diagram, represented by the circular shapes, are <>, <>, and <>. The table below, Table 1, provides detailed descriptions of the notation elements depicted in Figure 1, including the sequence diagram icon stereotypes. Table 1 UML Sequence Diagram Notation Descriptions Note: The table describes the notation elements that can be found in UML sequence diagrams. From “A Guide to UML Sequence Diagrams: Notation, Strengths, and Limitations” by Ricciardi (2025). Sequence diagrams have advantages and disadvantages, they are well-suited for modeling the dynamic behavior of a system by illustrating interactions between different actors or classes over a period of time. They help identify missing elements in class diagrams and they can be used for documentation (Ricciardi, 2025). On the other hand, they struggle to represent parallel processes or complex conditional flows. This is especially true for parallel interactions, as the dynamic and sequential nature of sequence diagrams makes it difficult to depict concurrent events within a system. Furthermore, trying to illustrate multiple concurrent and complex conditional flows using frames (or fragments) in a single diagram can make it cluttered and ultimately it may require the generation of several additional sequence diagrams. See Table 2 for a list of the main advantages and disadvantages of sequence diagrams. To summarize UML sequence diagrams are useful for illustrating dynamic interactions of objects within a system that have their advantages and disadvantages. The next section of this paper explores a hospital management system UML sequence diagram, including its related pseudocode and a UML class diagram. Table 2 Strengths and Limitations of UML Sequence Diagrams Note: The table describes the main advantages and disadvantages of UML sequence diagrams. Hospital Management System (HMS) is a digital application that helps hospitals manage daily operations efficiently (History Medical History, 2024). It is a platform that connects and manages all departments within a hospital, including medical, financial, patient, and administrative departments. As it will be nearly impossible to illustrate every interaction happening within the HSM using a single sequence diagram, this section explores through a sequence diagram how a doctor and a patient may interact with an HMS during an appointment. In other words, the sequence diagram illustrates a doctor-patient examination workflow within an HMS, showing how a doctor and a patient may interact with the HMS interfaces during an appointment. Figure 2 Doctor-Patient Examination HMS Class Diagram Version-2 Note: This UML class diagram, version 2, illustrates a doctor-patient examination system within a Hospital Management System (HMS). Made with Lucidchart app. As noted earlier in this paper sequence diagrams are usually based on UML class diagrams. Figure 2 depicts the class diagram that models the static structure of a doctor-patient examination system within a HMS. In Agile-Scrum methodology, this second iteration (version 2) of the class diagram, along with its associated pseudocode and sequence diagram, indicates that the doctor-patient examination feature was refined or modified during the design phase based on usage scenarios captured in the previous sequence diagram version. Below is the pseudocode associated with the feature. Code Snippet 1 HMS Doctor-Patient Examination System Pseudocode Version-2 Note: The pseudocode provides a code description of the interfaces and classes for the HMS Doctor-Patient Examination System. The full code can be found on GitHub here: HMS Doctor-Patient Examination System Pseudocode The HMS Doctor-patient examination system pseudocode comments label the Patient Class and the Patient Class as external actors as the objects instantiated by those start their interactions with the system by creating DoctorSysInterface and PatientSysInterface objects allowing them to interface with the HSM. Note that the PatientSysInterface Class and PatientSysInterface Class extend the HospitalSysManager Class. These relationships are illustrated in the class diagram by the aggregation and inheritance relationships, and it is these relationships that enable the Doctor and Patient actors to interact with the HMS Doctor-patient examination system as illustrated in the following sequence diagram. Figure 3 Doctor-Patient Examination HMS Sequence Diagram Version-2 Note: This UML sequence diagram, version 2, illustrates a doctor-patient examination interaction within a Hospital Management System (HMS). Made with Lucidchart app. The doctor-patient examination system HMS version-2 sequence diagram is a design level (solution space) UML sequence diagram that models the interactions between the external actors, a doctor and a patient, and a doctor-patient examination HMS. The interaction workflow initiates with the message from a found message represented by the method examine(Patient patient), a found message, in this context, is a message generated outside of the system. Similarly, the docApp(Doctor doctor) message initiates the workflow from the perspective of the patient. Note that this interaction could be represented as a parallel interaction in the diagram using a parallel (par) frame creating an interaction fragment within the diagram. However, this is not necessary as it will unnecessarily complicate the diagram and add cluttered to it without adding significant value to the understanding and illustration of the interaction. Additionaly, the diagram illustrates boundaries in the form of the interface "patInterface : PatienSysInterface", "docInterface : DoctorSysInterface" , and " diagnosisManager : DiagnosisManagerInterface" showing the layers of abstraction between the external actors themself (the doctor and the patient) and between them and the HMS core system (" aHospitalSysManager : HospitalSysManager" ), as well as with the schedule manage (" scheduleManager : ScheduleManagerInterface" ). The external also used those boundaries as interfaces to interact with the system. The diagram also illustrates combined fragments; for instance, the loop frame (" isSymptomDiagonsisDrugProcedure[0] = true" ) encapsulating the option frame " isSymptomDiagonsisDrugProcedure[0] = true " which further encapsulates the option frame "isSymptomDiagonsisDrugProcedure[1] = true". Furthermore, the sequence diagram illustrates well internal and external actors, objects, timelines, focus of controls, messages, self-messages, return messages, asynchronous messages, object destruction, steps (in a sequence), and notes effectively modeling the dynamic interactions within the doctor-patient examination process of the HMS. Conclusion UML sequence diagrams are useful for illustrating dynamic interactions of objects within a system. Sequence diagrams help in identifying missing elements, detailing object interactions, and modeling object destruction. However, they are less effective at representing parallelism, complex conditional logic, or entire complex systems in a single diagram. This essay has also explored the utility of UML sequence diagrams in modeling the dynamic behavior of systems, using a Hospital Management System's doctor-patient examination scenario. It provided a detailed sequence diagram, class diagram, and pseudocode demonstrating how these different tools can be used in the design phase to effectively represent complex interactions, and refine system requirements. As shown by the provided example, in software engineering, they are essential for designing, analyzing, and documenting interactions within a system. References: Agile Modeling. (2023, November 23). UML Stereotypes: Diagramming style guidelines. The Agile Modeling (AM) Method - Effective Strategies for Modeling and Documentation. https://agilemodeling.com/style/stereotype.htm IBM (2021, March 5). Sequence diagrams. Rational software modeler . IBM Documentation. https://www.ibm.com/docs/en/rsm/7.5.0?topic=uml-sequence-diagrams Ricciardi, A. (2025, January 27). A Guide to UML Sequence Diagrams: Notation, strengths, and Limitations . Code Chronicles - Omegapy. https://www.alexomegapy.com/post/a-guide-to-uml-sequence-diagrams-notation-strengths-and-limitations Medical History (2024, November 1). What is a hospital management system and how is HMS good for businesses? Smart Medical History. https://smartmedhx.ai/trends/what-is-a-hospital-management-system/ Unhelkar, B. (2018 ). Chapter 12 — Interaction modeling with sequence diagrams. Software engineering with UML . CRC Press. ISBN 9781138297432

This article provides an overview of UML sequence diagrams, a type of interaction diagram used in software engineering to model the flow of messages between objects within a system. It explores the notation, strengths, and limitations of these diagrams, highlighting their utility in visualizing dynamic system behavior while also acknowledging their constraints in representing parallel processes. Alexander S. Ricciardi January 24, 2025 Unified Modeling Language (UML) sequence diagrams illustrate the sequence of messages in an interaction (IBM, 2021). They are a form of interaction diagram used in Software Engineering (SE) to model the interactions between objects in a single use case. This post provides an overview of the UML sequence diagrams and their strengths and limitations in software development. UML Sequence Diagrams Overview UML sequence diagrams provide a dynamic illustration of object interactions within a system. In SE, they are usually based on UML class diagrams and are used primarily to show the interactions between objects (classes) in the chronological order in which those interactions occur. In the problem space, they are used to model the behavior of systems from the actors’ (users) perspective (Unhelkar, 2018). In solution space, the diagrams are more detailed and used to illustrate objects' interactions and their messages in detail such as the sequence of those messages, a parameter list within messages, and the return values of the messages. The figure below illustrates the different elements that can be found in a UML sequence diagram. Figure 1 UML Sequence Diagram Notation Note: The figure illustrates the different elements that can be found in UML sequence diagrams. Made with the Lucidchart app. The table below describes some of the main notation elements that can be found in UML sequence diagrams. Table 1 UML Sequence Diagram Notation Description Note: The table describes some of the main notation elements that can be found in UML. A stereotyped object or class is an object with a specific purpose or functionality defined by a stereotype (e.g. boundary, control, and entity). The data was collected from several sources (Visual-Paradigm n.d.; Unhelkar, 2018; rmb1905, 2009). Strengths and Limitations of UML Sequence Diagrams  UML sequence diagrams are excellent for visualizing the dynamic behavior of a system, particularly the interactions between objects or components over time. They can be used for analyzing and designing object interactions within a system, they are especially helpful in identifying missing elements in class diagrams and they can be used for documentation. See Table for a description of diagram strengths and limitations. For example, when designing a shopping cart system, they are especially useful at showing in detail the user (actor) interacting with the shopping cart and checkout system (objects). A sequence diagram can clearly depict the sequence of messages, for instance, addItem, viewCart, initiateCheckout, processPayment, etc., that is the exchanges between the user, the shopping cart, and the checkout system.  However, sequence diagrams also have their limitations, they are not well-suited for representing highly concurrent or parallel processes. Even though UML 2 implemented the parallel frame element, the dynamic nature of the diagrams makes it difficult to depict all the concurrent and parallel interactions that may exist in a complex system. In other words, trying to illustrate many concurrent and parallel interactions in a single diagram would make it extremely large and cluttered. Ultimately, it may require the generation of several additional sequence diagrams. Activity diagrams are better suited for such scenarios as they support parallel flows by using fork and join nodes. Table 2 Strengths and Limitations of UML Sequence Diagrams Note: The table describes the strengths and limitations of UML sequence diagrams. The data is from “Chapter-12 Interaction Modeling with Sequence Diagrams” by Unhelkar (2018). To summarize UML sequence diagrams are a useful tool for illustrating dynamic interactions of objects within a system. In SE, they are usually based on UML class diagrams and they are used in the problem space to model the behavior of systems from the user perspective, in solution space, the diagrams are more detailed and used to illustrate objects' interactions such as the sequence of the message, a parameter list within messages, and the return values of the messages. They help identify missing elements, detail object interactions, and model object deletion. However, the diagrams have limitations such as representing single flows or threads, they do not illustrate or model well parallelism, conditional logic, or loops, and using a single sequence diagram for an entire complex system can lead to confusion and errors. Nonetheless, they are an indispensable and powerful tool in the software engineer's toolkit, they are essential for designing, analyzing, and documenting interactions within a system. References: IBM (2021, March 5). Sequence diagrams. Rational software modeler. IBM Documentation. https://www.ibm.com/docs/en/rsm/7.5.0?topic=uml-sequence-diagrams rmb1905. (2009, March 10). 10.09_Fragments - parallels [Video]. YouTube. https://www.youtube.com/watch?v=mtVVf1mhYKk UML Diagrams Org. (n.d.). UML sequence diagram s. UML Diagrams Org. https://www.uml-diagrams.org/sequence-diagrams.html#execution   Unhelkar, B. (2018). Chapter 12 — Interaction modeling with sequence diagrams. Software engineering with UML. CRC Press. ISBN 9781138297432 Visual Paradigm (n.d.). Sequence diagram . Visual Paradigm. https://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html

This article explores the importance of network optimization and documentation for maintaining robust, efficient, and secure business operations. It outlines practical techniques, tools, and best practices that organizations can employ to enhance network performance, minimize downtime, and safeguard their digital infrastructure against cyber threats. Alexander S. Ricciardi January 24, 2025 From medium-size businesses to multinational corporations rely heavily on their networks for their daily operations. These networks manage critical functions, including data exchange, communication, and resource access, making their operation essential for business success Thus, it is crucial for network administrators to optimize network efficiency and maintain documentation to ensure the stability and security of their networks . This article explores network optimization techniques and the role of network documentation in maintaining a robust, reliable, and secure network. Network Optimization  Network optimization is a data-driven process that enhances network performance and efficiency (Kentik, n.d.). It is an ongoing process that involves measuring a network’s latency, throughput, and packet loss to identify bottlenecks and implement strategies to enhance the speed, reliability, and overall efficiency of the network. This involves adopting techniques or best practices such as load balancing, caching, traffic shaping, data compression, SD-WAN, protocol optimization, etc. See Table 1 for a complete list and description of network optimization techniques. Table 1 Network Optimization Techniques Note: the table describes different optimization techniques and how they help IT operations. Data from “What is Network Optimization?” by Solarwinds (n.d.). Importance of Network Documentation In addition to network optimization, it is crucial for network administrators to maintain documentation that facilitates managing and troubleshooting the network. Network documentation is the process of “tracking every bit of hardware, software, and cables. It can be as simple as a single spreadsheet you input manually or as complex as a software program to keep tabs on an entire large corporation’s computer and server network” (Lionguard, 2021, p. 1). Network documentation is necessary to keep a record of where devices/sections/parts of a network are and how they relate to each other. Making the use of tools and solutions faster. In other words, the more information is known about the network, the less time and money is wasted on troubleshooting a network issue. Not maintaining network documentation can have serious pitfalls such as: Increase in downtime and in troubleshooting time, when a network issue arises. Inconsistent network operations and increased communication errors, as not everyone on the IT team follows the same processes or procedures resulting in errors and network instability. Lack of standardized security documentation guiding the management of network protocols, communications, and data can increase vulnerability to cyberattacks and data breaches. Security vulnerabilities in the form of loopholes due to missing knowledge about network devices, device configurations, and protocols implemented. Security vulnerabilities from not-updated software and outdated hardware due to missing documentation about software versions and end-of-life device dates. To ensure proper network documentation is important to use templates and documentation tools. The tables below describe different templates and tools used for network documentation. Table 2 Network Documentation Template Examples Note: The table describes different templates used for network documentation. Table 3 Network Documentation Tools Note: The table describes different tools used for network documentation. To summarize, businesses need to maintain a robust and reliable network as they rely on their networks for their daily operations. Therefore, optimizing networks and maintaining thorough network documentation is crucial for ensuring a network's stable operations, minimizing downtime, and maintaining robust security. Ultimately, ensuring the success of businesses. References: Kentik (n.d). What is network optimization? 9 Techniques for improving network performance. Kentipedia. https://www.kentik.com/kentipedia/what-is-network-optimization/ Lionguard (2021, November 8). What is network documentation & why is it necessary? Lionguard Blog. https://www.liongard.com/blog/what-is-network-documentation/ Solarwinds (n.d). What is network optimization? Solarwinds. https://www.solarwinds.com/resources/it-glossary/network-optimization

The article examines the benefits of multithreading in optimizing workflows utilizing a restaurant dine-in scenario represented by a UML activity diagram. It shows how concurrent activities, depicted by fork and join nodes, can lead to reduced wait times, improved resource utilization, and a more responsive system. Alexander S. Ricciardi January 12, 2025 Unified Modeling Language (UML) activity diagrams describe the workflow behavior and dynamic aspect of systems (Thanakorncharuwit et al. 2016). They are similar to flowcharts in that they depict the flow of activities (IBM, 2021). However, activity diagrams can also illustrate a system's multithread components, showing parallel or concurrent flows, as well as alternate flows. The diagrams are used in software engineering and business modeling to describe and design the dynamic aspect of systems. This article analyzes the workflow and dynamic behavior of a customer's interaction with a restaurant system, focusing on the dine-in customer experience; by providing an activity diagram and analysis of it. The analysis examines the diagram's partitions, multithreading elements, and decision points. Additionaly, the essay discusses how multiple threads help to optimize workflows. UML Activity Diagrams Overview In the context of Software Engineering (SE), UML activity diagrams are used to show any flow or process in a system (Unhelkar, 2018). They are a great tool for modeling business processes or workflows within the organization, the flow within a use case by creating a visual representation of it based on the documentation of that use case, dependencies between use cases, and user interface navigation (storyboard) of an application. In other words, activity diagrams can be used in all three SE modeling spaces (MOPS, MOSS, and MOAS). However, they are mostly used in the Model of Process Space (MOPS) to model process flows and the Model of Solution Space (MOSS) to model multithreaded and multitasked processes. The table below, Table 1, describes some of the components that can be found in activity diagrams. These components consist of nodes representing different process controls that include activity states, decisions, forks, joins, and objects (Thanakorncharuwit et al. 2016). Table 1 UML Activity Diagram Components Note: The images were made in Lucichart App. Strengths and Weakness of UML Activity Diagrams Activity diagrams provide several advantages; however, they also have disadvantages, see Table 2 for a list of those advantages and disadvantages. In the context of SE, the main strength of the diagrams is their capacity for modeling process flows. On the other hand, their main weakness is that they have minimal structural characteristics and do not directly indicate how a system or its requirements are organized and prioritized (Unhelkar, 2018). Table 2 Strengths and Weakness of UML Activity Diagrams Note: data from “Chapter 7 — Activity Diagrams, Interaction Overview Diagrams, and Business Process Models. Software Engineering With UML” by Unhelkar (2018). UML Activity Diagram Example Activity diagrams are typically created after UML use case diagrams and actor/use case documentation (Vpadmin, 2023). In the context of SE, use case diagrams are part of the early stage of software development, as they play an important in capturing and modeling a system's behaviors (Ricciardi, 2025). They capture a system use cases and actors. These capture use cases and actors and the documentation associated with them can be used as a base for developing activity diagrams that illustrate the workflow of each use case or the overall workflow of a business process from the perspective of one or several actors. Figure 1 UML Restaurant Use Case Diagram Note: from “UML Use Case Diagrams: A Restaurant System Case Study” by Ricciardi (2025). Modified. Base UML Use Case Diagram Example The use case diagram from ”Restaurant Customer Service System Diagram” (Ricciardi, 2025), see Figure 1, and the A02-Dine-inCustomer actor documentation associated with it can be used as a basis to create an activity diagram. Below is the A02-Dine-inCustomer actor documentation from the “UML Restaurant Use Case Diagram”: - Actor Thumbnail: A02-Dine-inCustomer - Actor Type and Stereotype: Concrete, Primary, Person - Actor Description: The A02-Dine-inCustomer actor represents a customer wanting to dine in. The actor interacts with the restaurant's system to be seated, place an order, receive their food and drinks, make payment, and leave a tip. - Actor Relationships: Related to the abstract Actor “A01-Customer” Interacts with the following use cases: UC01-AskToBeSeated UC03-DineIn Service UC07-PlaceOrder UC10-Payment - Interface Specifications: The actor directly interacts with the restaurant staff (A05-Host, A04-Servers). The actor directly interacts with a menu. The actor directly interacts with a bill, but not with the printing of the bill and the payment validation process. Using the example above a business process activity diagram of the restaurant system from the perspective of a dine-in customer can be created, see Figure 2. Figure 2 Restaurant Dine-in Customer Activity Diagram The Activity Diagram Example Overview The “Restaurant Dine-in Customer Activity Diagram,” Figure 2, is an illustration of a restaurant business process from the perspective of a dine-in customer. In other words, the diagram provides a visualization of the workflow of a dine-in customer at a restaurant, from the moment they enter the establishment to when they leave. This activity diagram is based on the “Restaurant Customer Service System” use case diagram, Figure 1, and the “A02-Dine-inCustomer” actor documentation. The following list breaks down to diagram by component to provide a detailed overview of it: - Partitions and Actors: The diagram uses partitions (swimlanes) to partition activities by actors. A02-Dine-inCustomer: The primary actor, representing the customer who is dining in. A04-Server: Represents the waiter or waitress responsible for serving the customer. A05-Host: Represents the staff member responsible for greeting and seating customers. A07-Cooks: Represents the kitchen staff responsible for preparing the food. - Workflow and Activities: The diagram depicts the flow of activities, starting with the “A02-Dine-inCustomer” asking to be seated, “AskToBeSeated (UC-01).” Then the “A05-Host,” finds an available table, while the “A02-Dine-inCustomer” and “A04-Server” wait, after a table is found, the host seats the customer. Then the “A04-Server” hands the menu to the customer, answers questions, waits for the customer to pick drinks and food from the menu, and then takes their order. Note that The decision point “Special Dietary Request?” allows an alternate flow if the customer has specific dietary needs. - Multithreading, Parallelism, or Concurrency: The fork and join nodes illustrate multithreading and concurrent activities. For example: Fork-3: After taking the order the “A07-Cooks” “PrepareFood (UC09).” Fork-4: While the “A02-Dine-inCustomer” “waits to be served” and “A04-Server” “prepares the drinks” and “serves the drinks.” Join-4: After the “A04-Server” “serves the drinks” the “A02-Dine-inCustomer” “drinks and waits for the food, while the “A07-Cooks” “PrepareFood (UC09).” Join-3: After “A04-Server” “serves the food” Fork-5 starts, where “A02-Dine-inCustomer” “eats the food” and “A04-Server” “refills the drinks.” Note that the Fork-3 and Join-3 are encapsulated between the Fork-4 and Join-4 demonstrating how a multithread can be encapsulated in other multithread. - Decision Points and Alternate Flows: Decision points represent choices and alternate flows within the process. The “Special Dietary Request?” decision allows for a separate path where the customer can “AskForSpecialDietaryRequest (UC06).” The “Credit Card?” and “Payment successful?” decision points within the payment process (UC10) handle different payment scenarios, - Error Handling: The diagram does not handle errors, this can be implemented in different activity diagrams based on specific use cases. Multithread and Workflow Optimization In the context of the "Restaurant Dine-in Customer Activity Diagram," multithreads are represented by the fork and join components of the diagram, they illustrate the concurrent execution of different activities as shown in the activity diagram example overview. Multithreading enhances the efficiency, responsiveness, and resource utilization of a system. This is true for both business process modeling and software engineering. For instance, the concurrent processing enabled by multithreading reduces the overall time required to complete a process and reduces bottlenecks as activities are not performed sequentially. Additionally, multithreading makes a system more responsive by allowing actors (users, clients) to interact with the system in parallel. Furthermore, it allows for better utilization of available resources by allowing multiple tasks to be performed concurrently, maximizing the use of resources such as workers’ productive time or power. Thus, it is important to optimize workflows by implementing, when possible, multithreading. Examples of applications where multithreading is valuable include operating systems, where multithreading is extensively implemented to manage various system processes and user applications, and e-commerce applications, where it is implemented to handle multiple customer requests concurrently. Conclusion Whether in software engineering or business process modeling, UML activity diagrams are used to describe the workflow behavior and the dynamic aspects of systems. As shown in the "Restaurant Dine-in Customer Activity Diagram," activity diagrams can model business processes or workflows within an organization or system, by utilizing elements such as partitions, decision points, and fork and join nodes. They can depict the flow of activities, actor responsibilities, alternate paths, and concurrent processes. Additionaly, they can be used to optimize workflow by identifying multithreading opportunities; therefore, improving the overall efficiency of a system. UML activity diagrams are a powerful tool for not only understanding and documenting systems' behavior but also for improving and optimizing them. References IBM (2021, March 03). Activity diagrams. IBM Rational Software Architect documentation. IBM Documentation. https://www.ibm.com/docs/en/rational-soft-arch/9.6.1?topic=diagrams-activity Thanakorncharuwit, W., Kamonsantiroj, S., & Pipanmaekaporn, L. (2016). Generating test cases from UML activity diagram based on business flow constraints. Proceedings of the Fifth International Conference on Network, Communication and Computing, 155–160. https://doi-org.csuglobal.idm.oclc.org/10.1145/3033288.3033311 Ricciardi, A. S. (2025, January 2). UML Diagrams: A Guide for Software Engineers - Level up Coding. Medium. https://medium.com/gitconnected/uml-diagrams-a-guide-for-software-engineers-71220ffb775f Unhelkar, B. (2018). Chapter 7 — Activity diagrams, interaction overview diagrams, and business process models. Software engineering with UML. CRC Press. ISBN 9781138297432 Vpadmin. (2023, October 11). Unraveling Use cases: A Step-by-Step Guide to Elaboration through activity Diagrams - Visual Paradigm Guides. Visual Paradigm Guides. https://guides.visual-paradigm.com/unraveling-use-cases-a-step-by-step-guide-to-elaboration-through-activity-diagrams/

This article explores the security risks posed by rogue devices on wireless networks. It explores how unauthorized devices like access points and peripherals can compromise network security. It provides practical guidance on preventing, identifying, and isolating these threats through network access controls, monitoring tools, and segmentation. Alexander S. Ricciardi January 16, 2025 Wireless networks are everywhere and have infiltrated every aspect of daily life as they provide convenience and flexibility at home and work. However, their convenient and flexible nature comes with security risks, particularly through rogue devices. The Information Technology Laboratory (n.d.) defines rogue devices as “an unauthorized node on a network.” These devices can be smartphones, laptops, Internet of Things (IoT) devices, or any other device capable of connecting to a network (Nile, n.d.). Focusing on wireless networks, this post explores rogue device types, prevention, identification, and isolation; the post also provides an overview of wireless monitoring tools. Wireless Types of Rogue Devices In the context of wireless networks, rogue devices can range from wireless access points, laptops, and smartphones to software like network sniffers or compromised IoT devices. Here are some common types: Table 1 Wireless Types of Rogue Devices Note: Data from several sources (Gratas, 2024; Ciarlone, 2023; uCertify, 2019). As shown in Table 1, rogue devices can be of various types, from unauthorized wireless access points to basic peripherals like modified wireless keyboards, with each type posing a unique set of security threats. Preventing Identifying and Isolating Rogue Devises With so many types of possible rogue devices, it is important for wireless network administrators to prevent, identify, and isolate them. Preventing rogue devices can be done by disabling Service Set Identifier (SSID) broadcasts making the network less discoverable by wardriving scans (uCertify, 2019). Rogue devices can be also prevented by implementing network access controls “to ensure that only authorized devices and users can connect to your network” (Nile, n.d., p.1). This can be done by implementing Network Access Control (NAC) appliances and strong authentication methods, such as 802.1x with EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) or PEAP (Protected Extensible Authentication Protocol). Other preventative measures are continuously monitoring the network for suspicious activity, identifying and categorizing devices on the network, and implementing a network segmentation policy such as dividing the network into smaller and isolated subnetworks, as well as implementing a guest Wi-Fi guest network for visitors and employees' personal devices.   Identifying and isolating rogue devices can be done by utilizing network scanning tools such as Nmap to scan for all devices connected to the network (Zamot, 2020). This allows a network administrator to identify unauthorized devices and isolate them. Intrusion Detection Systems (IDS) can also help to identify rogue devices by monitoring traffic and detecting suspicious activities (Solarwinds, n.d. a). Additionally, wireless rogue access points can be detected using a tool such as Firebox which measures the strength and characteristics of an access point and compares it to a list of trusted access points (watchguard, n.d.). The table below provides an overview of several tools used to detect wireless network anomalies. Table 2 Wireless Monitoring Tools Note: Data from several sources (Reddy, 2023; MetricFire Blogger 2023;  Sharma, 2023; NetSpot, n.d.; Goodman, 2018; Kismet Wireless, 2016, Netscout, n.d.; Solarwinds, n.d. b) To summarize the convenience and flexibility provided by wireless networks come with security risks, primarily from the threat of rogue devices. These devices can be unauthorized access points or peripherals such as printers and keyboards. Preventing, identifying, and isolating these rogue devices is crucial for network security. These security vulnerabilities can be mitigated by implementing network access controls, using monitoring tools, and implementing measures like network segmentation and dedicated guest networks. References: Ciarlone, J. (2023, December 29). Spotting the most common wireless network vulnerabilities. Hummingbird Networks. https://services.hummingbirdnetworks.com/blog/most-common-wireless-network-vulnerabilities-to-watch-for Goodman, D. (2018, November 18). Network Stumbler: A powerful broadband tool. Connected Nation. https://connectednation.org/press-releases/network-stumbler-a-powerful-broadband-tool Gratas, B. (2024, September 9). Rogue device detection in 5 simple steps . Invgate Blog. https://blog.invgate.com/unauthorized-asset-detection Information Technology Laboratory (n.d.). Rogue device. Glossary. NIST – U.S. Department of Commerce. https://csrc.nist.gov/glossary/term/rogue_device Kismet Wireless (2016). Kismet. Kismet Documentation. https://www.kismetwireless.net/static/documentation.shtml MetricFire Blogger (2023, October 12). 10 best tools for monitoring wireless access points. MetricFire. https://www.metricfire.com/blog/10-best-tools-for-monitoring-wireless-access-points/ Netscout (n.d.). AirMagnet Enterprise [PDF]. AirMagnet. https://assets.tequipment.net/assets/1/26/Documents/AirMagnet_Enterprise_Datasheet.pdf NetSpot (n.d.). Y our Wi-Fi planning and wireless site survey app [Video]. NetSpot. https://www.netspotapp.com/features.html Nile (n.d.). What are rogue devices? How to detect and prevent them. Nile. https://nilesecure.com/network-security/what-are-rogue-devices-how-to-detect-and-prevent-them Reddy, M. (2023, July 7). U nlocking the power of datadog: Understanding its key features. Nitor. https://www.nitorinfotech.com/blog/unlocking-the-power-of-datadog-understanding-its-key-features/ Sharma, A. A. (2023, July 4). PRTG Network Monitor: Why and how? DEVOPS DONE RIGHT. https://opstree.com/blog/2023/07/04/prtg-network-monitor-why-and-how/ Solarwinds (n.d. a). Detecting and preventing rogue devices [PDF]. Solarwinds Whitepaper. https://www.solarwinds.com/assets/solarwinds/swdcv2/licensed-products/user-device-tracker/resources/whitepaper/udt_wp_detect_prevent_rogue_devices.pdf Solarwinds (n.d. b). Wi-Fi Network Analyzer. Solarwinds. https://www.solarwinds.com/network-performance-monitor/use-cases/wifi-analyzer uCertify. (2019). 8.3 Securing wireless LANs. CompTIA Network+ Pearson N10-007 (Course & Labs) [Computer software]. uCertify LLC. ISBN: 9781616910327 Watchguard (n.d.) Rogue access point detection – Fireware Help. Watchguard.  https://www.watchguard.com/help/docs/fireware/12/en-us/Content/en-US/wireless/wireless_rogue_ap_detection_c.html Zamot, M. (2020, December 1). Finding rogue devices in your network using Nmap. Red Hat Blog. https://www.redhat.com/en/blog/finding-rogue-devices

This article explores the use of Unified Modeling Language (UML) class diagrams in software engineering, focusing on how they are used within the problem space and the solution space. It highlights the key differences between analysis and design class diagrams, emphasizing how they serve distinct purposes in modeling what a system does versus what a system needs to do. Alexander S. Ricciardi January 15, 2025 In Software Engineering (SE), Unified Modeling Language (UML) class diagrams are one of six UML types of structural diagrams (IBM, 2021). Class diagrams are used to model object processes and the static structures of a system and subsystems. In other words, they are the blueprints of systems. Moreover, these diagrams can be used in different stages of system design. This post gives an overview of the class diagram and explores the difference between class diagrams used in the problem space (MOPS), which can be used to analyze and capture a system's functional requirements and components, and those used in the solution space (MOSS), which focuses on designing a system by modeling what the system needs to do. Class Diagrams Overview Class diagrams are useful in many stages of the SE process, especially during the development life cycle. In the analysis phase (MOPS), they help analyze and capture problem requirements and components. In the design phase (MOSS), they help design solutions. IBM in its “Rational Software Modeler” documentation describes class diagrams as an essential tool for software development that can help: you to understand the requirements of your problem domain and to identify its components. In an object-oriented software project, the class diagrams that you create during the early stages of the project contain classes that often translate into actual software classes and objects when you write code. Later, you can refine your earlier analysis and conceptual models into class diagrams that show the specific parts of your system, user interfaces, logical implementations, and so on. Your class diagrams then become a snapshot that describes exactly how your system works, the relationships between system components at many levels, and how you plan to implement those components." (IBM, 2021, p1) In other words, class diagrams can be used to illustrate, define, and document the structural features of a system. UML class diagrams are the most widely used notation standard in SE for object-oriented modeling. UML Class Diagram Notation Overview In object-oriented based software development UML Diagram notation is used to illustrate advanced class diagrams and class-to-class relationships. The table below illustrates the different components found in a UML class diagram. Table 1 UML Class Diagram Notation Note: Data from several sources (Unhelkar, 2018; Dwivedi; 2019; Colorado State University Global, 2025). Shapes made with Lucid App. As shown in Table 1 UML class diagrams provide an extensive set of notations for modeling the static structure of a system, including classes, attributes, operations, and various types of relationships between them. These diagrams can be used to analyze and design systems. Differences Between Analysis and Design Class Diagrams In the context of SE, it is important to understand the difference between design classes and analysis classes. In problem space, class diagrams are used to analyze and capture a system's functional requirements and components. They act like detectives investigating and understanding the problem at hand (Navlaniwesr, 2024). In the solution space, they focus on what a system needs to do, without diving into how it will be done. In other words, analysis class diagrams focus on understanding the problem domain, while design class diagrams detail the solution.  Analysis Class Diagrams Analysis class diagrams are abstract. They are usually based on case diagrams, and they are often the initial step in understanding the problem domain and the detailed requirements of a system. They are characterized by the following: They focus on understanding the problem domain and capturing the requirements of a system (Navlaniwesr, 2024). They are illustrations of a system’s components, attributes, and relationships. They portray a high-level view of a system without delving into implementation specifics. They capture user needs, business processes (use cases), and external system interactions. Below is an example of analysis class diagrams illustrating a very simple product ordering system. Figure 1 Simple Product Ordering Analysis Class Diagram Note: the diagram shows basic entities/classes (Customer, Order, Product) with simple attributes. The relationships are basic associations. Design Class Diagrams  Design class diagrams are blueprints illustrating what a system needs to do. They contain more details than the class diagram developed during analysis in the problem space (Unhelkar, 2018). They model in detail relationships, objects' attributes, and functionality, as well as visualize multiplicities. They are characterized by the following: They model a system structure and operation signatures (Navlaniwesr, 2024).  A signature is the interface of an operation, that is the information needed to call a specific operation such as parameters and what the operation returns. They illustrate in detail a class’s methods, attributes, and interactions. They incorporate implementation details, such as data structures and algorithms. They translate functional requirements into structures that can be developed. Below is an example of design class diagrams illustrating the simple product ordering system used earlier to illustrate analysis class diagrams. Figure 2 Simple Product Ordering Design Class Diagram Note: the diagram added details to the design class diagram, an extra class “ItemOrder” with an aggregation relationship to the “order” class As shown by Figures 1 and 2, analysis and design class diagrams differ in detail. Most importantly, they differ fundamentally in their purpose, with analysis class diagrams focusing on “what” a system does, while design class diagrams focus on designing a solution or system by defining what the system needs to do. In other words, analysis class diagrams are used to analyze a system, while design class diagrams are used to design a system. To summarize, class diagrams are used to model systems and subsystems. They are the blueprints of systems and subsystems. They are visual blueprints representing system structure stages which are used in various stages of the development lifecycle, from the initial analysis of the problem domain (MOPS) to the detailed design of the solution (MOSS). Analysis and design class diagrams differ not only in detail but more importantly in their purpose, with analysis class diagrams modeling “what” a system does, and design class diagrams modeling a solution or system by defining what the system needs to do or “how” it needs to do it. In object-oriented software development, UML class diagrams are crucial for analyzing and designing complex systems, making them an indispensable tool in the software engineer's toolkit. References: Colorado State University Global. (2024). Module 5 - Software design concepts: Class designs [Interactive lecture]. CSU Global Computer Science Department Canvas. https://csuglobal.instructure.com/courses/104036/pages/module-5-overview?module_item_id=5372244 Dwivedi, N. (2019, September 23). Class diagrams: Relationships. Software design: Modeling with UML . LinkedIn Learning. https://www.linkedin.com/learning/software-design-modeling-with-uml/class-diagrams-relationships?resume=false&u=2245842 / IBM (2021, March 5). Class Diagrams. Rational software modeler . IBM Documentation. https://www.ibm.com/docs/en/rsm/7.5.0?topic=structure-class-diagrams Navlaniwesr (2024, April 18). What is the difference between design classes and analysis classes? GeeksforGeeks. https://www.geeksforgeeks.org/what-is-the-difference-between-design-classes-and-analysis-classes/ Unhelkar, B. (2018). Chapter 11 — Class Model-3: Advanced class designs. Software engineering with UML . CRC Press. ISBN 9781138297432

This article explores the differences and relationships between business processes and software development processes. It examines how business process modeling helps business operations achieve their goals, and how software development processes help design applications that support and enhance those operations. It also explores various modeling tools and methodologies used to define, illustrate, and improve both types of processes, including BPMN, UML diagrams, and Agile frameworks. Alexander S. Ricciardi January 6, 2025 Business processes are part of business analysis, and software development processes are part of software development. While similar and related, the business processes define how a business achieves its goals, software development processes’ goal is to build applications that support those business processes. This post also examines the difference between the two by defining their scopes, goals, and methodologies. Additionally, the post explores the various modeling tools used to define and illustrate these processes, including BPM methodologies, BPMN, UML diagrams (Use Case, Activity, and Interaction Overview), and SDLC frameworks like Agile. Definition of Business Processes and Software Development Process Business processes are sets of sequential activities performed by stakeholders (e.g., people, departments, systems) to achieve an organizational goal (Kissflow, 2024). They represent "how" a business achieves its objectives. In other words, they represent a business’s operations, workflow, and interactions among stakeholders.  On the other hand, software development processes are usually associated with the software development life cycle (SDLC) and the Agile methodology (Unhelkar, 2028). They can be defined as a series of steps for designing, creating, testing, and maintaining software applications (Browser Stack, 2024).  As shown by the definitions above, business processes and software development processes are related and interconnected but are distinct in their purpose. They have different scopes, focuses, and goals (business operations versus business software creation). Business Processes vs Software Development Processes The primary goal of business processes is to achieve a business objective, such as delivering a product or providing a service. On the other hand, the primary goal of software development processes is to design, develop, deploy, and maintain a software application that meets a business’ needs by meeting the business software requirements. Additionally, the scope of business processes includes the steps, activities, or tasks involved in achieving the business goal. On the other hand, the scope of software development processes includes capturing the functional and non-functional requirements of the business (user needs and business requirements) and the technical aspects of creating software, including coding, testing, deployment, and maintenance of the software. Furthermore, software development usually uses well-defined mythology such as Agile, Waterfall, and Scrum to capture and define processes. On the other hand, business modeling does not adhere to a single accepted "methodology" to define processes, instead various frameworks, approaches, and improvement techniques are used to define and describe a business’s processes.  Modeling Tools Business processes are often modeled and defined using Business Process Management (BPM) which describes various methodologies that are used to manage business processes (Nehra, 2020). Methodologies such as Lean, Six Sigma, and Total Quality Management (TQM) each having different approaches to business process improvement. To model and illustrate business processes, these methodologies often use Flowcharts, UML Use case diagrams, UML activity diagrams, and Business Process Management Notation (BPMN) diagrams. BPMN is a rich set of notations that are used to create business process models that can be embedded in standardized case tools, shared, and optimized (Unhelkar, 2018). See Figure 1 for the BPMN diagram’s main components. Figure 1 BPMN Diagram Main Components Note: from “Chapter 7 – Activity diagrams, interaction overview diagrams, and business process models. Software engineering with UML. CRC Press” by Unhelkar (2018). Modified. The BPMN diagram below illustrates a scenario of a customer calling, ordering, and eating at a Chinese restaurant Figure 2 BPMN Diagram Customer Calling, Ordering, and Eating at a Chinese Restaurant Note: from “Diagramming basics: A BPMN tutorial” by Lucidchart (n.d. a). Software development processes usually use SDLC methodologies such as Agile Scum to design, develop, deploy, and maintain a software application. These mythologies often use diagrams such as UML Use Case Diagrams, UML activity diagrams, and UML Interaction Overview Diagrams (IOD). Note that the UML use case and activity diagrams are also used by BMP methodologies. See Figure 3 for the activity diagram’s main components and Figure 5 for the IOD diagram’s main components. Figure 3 Activity Diagram Main Component Note: from “Chapter 7 – Activity diagrams, interaction overview diagrams, and business process models. Software engineering with UML. CRC Press” by Unhelkar (2018). The UML activity diagram below illustrates a scenario of a customer using a bank ATM machine. Figure 4 Activity Diagram of a Customer Using an ATM Machine Note : from “Activity diagram with swimlanes example” by Lucichart (n.d. b) Figure 5 Interaction Overview Diagrams Main Components Note: from “Chapter 7 – Activity diagrams, interaction overview diagrams, and business process models. Software engineering with UML. CRC Press” by Unhelkar (2018). The UML Interaction overview diagram below illustrates a scenario of a student using a college admission system.   Figure 6 UML Interaction Overview Diagram of a Student Using a College Admission System Note: from “Interaction Overview Diagrams | Unified Modeling Language (UML)” by Gurdee (2024). Modified. Finally, the table below summarizes the differences between business processes and software development processes. Table 1 Business Processes vs Software Development Processes In conclusion, business processes and software development processes are distinct but related. Business processes define how a business achieves its goals, while software development processes design applications to support those operations. Modeling and aligning these processes through methodologies like BPM and Agile, and utilizing tools such as BPMN and UML diagrams, is essential for improving efficiency. References: Browser Stack (2024, September 18). Understanding the software development process . BrowserStack. https://www.browserstack.com/guide/learn-software-development-process Gurdee (2024, March 4). Interaction overview diagrams | Unified Modeling Language (UML). GeeksForGeeks. https://www.geeksforgeeks.org/interaction-overview-diagrams-unified-modeling-language-uml/ Kissflow. (2024, December 24). Business Process 101 : Definition, Steps and Example [Guide for 2025].  https://kissflow.com/workflow/bpm/business-process/#:~:text=A%20business%20process%20is%20defined,attain%20a%20pre%2Ddefined%20objective . Lucidchart (n.d. a). Diagramming basics: A BPMN tutorial . Lucidchart. https://www.lucidchart.com/blog/diagrams-for-dummies-a-BPMN-tutorial Lucidchart (n.d. b). Activity diagram with swimlanes example [App]. Lucidchart App. https://lucid.app/lucidchart/1172f431-8bbd-4c8c-929f-b1f805cad037/view?anonId=0.268624821943df44f0a&sessionDate=2025-01-06T23%3A46%3A56.942Z&sessionId=0.d0e34dd81943df44f0c&fromMarketing=true&_gl=1*190v7rn*_gcl_aw*R0NMLjE3MzQ3OTM2NzAuQ2p3S0NBaUE2NW03QmhBd0Vpd0FBZ3U0SkdacVFra0lKcDFWLUt1c1pNeTNfU2dlUklMbmh2NGFrUDNya0Uzd0l3YVM4ZTlCZ3ZOaG5Sb0NuYWNRQXZEX0J3RQ..*_gcl_au*MTk2MTYzNDY4Ny4xNzM0MjA0OTQ3*_ga*MjYyMDU1OTQ3LjE3MzQyMDQ5NDk.*_ga_MPV5H3XMB5*MTczNjIwNjIwOS41LjEuMTczNjIwNzIxMC4wLjAuMA..&usecase=uml&page=0_0# Nehra, M. (2020, September 16). Business process management in software companies . ITChronicles. https://itchronicles.com/business-process-management/business-process-management-in-software-companies/ Unhelkar, B. (2018). Chapter 7 – Activity diagrams, interaction overview diagrams, and business process models. Software engineering with UML . CRC Press. ISBN 9781138297432

This article explores the application of Unified Modeling Language (UML) Use-Case Diagrams in designing an online shopping system, detailing the essential components like actors, use cases, and their relationships. It demonstrates how these diagrams capture functional requirements and illustrates typical user interactions with examples of main and alternative flows in use case documentation. Alexander S. Ricciardi January 5, 2025 Unified Modeling Language (UML) Use-Case Diagrams are used early within the UML-base Development (Dolques et al, 2012). In Software Development (SD), they model the behavior of a system helping to capture the functional requirements of the system (IBM, 2023). They are structured around the concept of actors and use cases, the diagrams illustrate the interactions and relationships between them within a system, with the primary goal to describe the system's functionality (Helm n.d). What the system does. This essay explores an online shopping scenario by providing a UML Use-Case Diagram of a hypothetical online shopping system, analyzing its actors, use cases, and relationships, and providing two use case documentation examples describing flow and alternative flow steps. UML Use-Case Diagrams Overview In the context of Software Engineering (SE), UML Use-Cases Digrams are part of the early stage of SD, and they play an important role in the software modeling of the Problem Space or Model of Process Space (MOPS). MOPS models “what” the business problem is and users are to understand and model the system or application requirements (Ricciardi, 2025). Use case modeling behind the identification of actors. An actor can be an individual or external/internal systems that interact with the system to fulfill a goal (Unhelkar, 2018 a). These are the main actors who benefit from the system—for example, The other components of a UML Use-Case Diagram are use cases and relationships. Use cases are illustrations of “what” a system does; however, they do not illustrate “how” the system does it. Relationships illustrate the interactions between actors, between use cases, and between actors and use cases. These relationships can be divided into four categories: Association relationships - illustrations of direct interactions between actors and use cases or between use cases. Include relationships - illustrations of interactions where use cases include the functionalities of other use cases. Extend relationships - illustrations of interactions where use cases are extended by other use cases under certain conditions. Generalization relationships - illustrations of interactions where use cases are generalized versions of other use cases or actors are generalized versions of other actors. This interaction can be defined as a parent-child relationship where the parent is the generalized version of a child. (Ricciardi, 2025, p. 2) On the next page sets Figure 2. It is a possible Use-Case Diagram for an online shopping scenario. It illustrates the actors, use cases, and their relationships within the online shopping system. The actors are depicted by a stick figure with a design starting with “A” followed by a number and name description. Use cases are depicted as an eclipse container with a design starting with “UC” followed by a number and name description. Relationships are depicted with lines and arrows with their name designation between “<< >>” if they represent an extend or include relationships, see Figure 1 for an illustration of them. Figure 1 Examples of Actors, Use Cases, and Relationships Figure 2 Online Shopping System Use Case Diagram Online Shopping System Analysis Before crafting a USE-Case Diagram for the online shopping scenario, it is important to identify the actors. Use case modeling begins with the identification and documentation of users or actors” The main purpose of developing a software solution is to provide for the needs of these users. The actor also indicates how the system will be used (hence the term use cases). Actors provide the core starting point for the rest of modeling, design, and development in a software project. (Unhelkar, 2018 a, p. 73). Actors can be internal or external to the system, primary actors are the ones for whom the system is built, while secondary actors support the system to help primary actors to achieve their goals (Unhelkar, 2018). Direct actors interact with the system directly through an interface, for example, while indirect actors do not interact with the system interface but may receive output/date/goods from the system. Finally, abstract actors are generalizations of actors that can model the behavior of other actors, while concrete actors inherit from abstract actors. See Table 1 for a description of the actors. Table 1 Online Shopping System Actors After defining a list of potential actors, use cases can be identified (Unhelkar, 2018). The actor documentation can help identify use cases because it provides information on actor-to-use-case relationships. See Table 2 for a description of the online shopping system use cases. Table 2 Online Shopping System Use Cases Use case documentation can help identify relationships. There are three main types of relationships: Actor-to-actor is always a generalization relationship or inheritance relationship. Actor to use case, called an association, is the relationship between an actor and a use case, also called communication as it can represent a communication between the actor and the system. Use case to use case are relationships relationships between two use cases that are defined by three specific types: include, extend, and inherit (generalization) relationships. These relationships were defined in the UML Use-Case Diagrams Overview section of this paper. (Unhelkar, 2018 b) The table below, Table 3, describes the relationships within the online shopping system diagram. Table 3 Online Shopping System Relationships Examples of Flows and Alternative Flows In use case documentation, flows (sometimes called “Main Flows” or “Basic Flows”) describe the happy path or the ideal flow (ProcessMaker, 2024). They document the usual or expected sequence of steps while Alternative Flows document exceptions, error conditions, or optional paths. Below are two examples of use case documentation describing the flows (main and alternative) for key use cases: Example: UC03–Checkout Main (Basic) Flow 1. Review Cart Items The system displays items, quantities, and prices from UC02-Cart. 2. Confirm Order Details The Customer checks shipping address, billing address, and any taxes or fees. 3. Proceed to Payment The system transitions to UC04-MakePayment, where the Customer will choose payment options. Alternative Flows A1: Cart Empty If the cart is empty, the system notifies the Customer and redirects them to UC01-BrowseProducts. A2: Session Timeout If the session expires during checkout, the system prompts the Customer to log in again via UC08-Login or create a new account if needed. Example: UC04–MakePayment Main (Basic) Flow 1. Select PaymentMethod The system includes UC12-PaymentMethod, prompting the Customer to choose or enter credit card/billing details. 2. Verify Payment The system calls UC06-VerifyPayment, which sends the payment request to A05-PaymentGateway. 3. Complete Payment On successful authorization, the system finalizes the order, linking back to UC10-ManageOrder or concluding the checkout process. Alternative Flows A1: Promotional Code The Customer opts to use UC05-ApplyPromotionCode (<>). If valid, the system recalculates the total; if invalid, it notifies the Customer. A2: Payment Declined The gateway returns a “declined” response. The system offers the Customer a chance to retry or choose a different payment method (UC12). For the seek of paper length, only two key use case documentation have been provided. However, the diagram illustrates several more use cases that could have been documented to provide examples of Main Flow and Alternative Flow scenarios. It is important to notice that “Use-Case Diagrams do not show any flow or dependencies in the system. They only provide a high-level picture of the system and have no features to represent the sequence of actions and alternative actions” (Unhelkar, 2018 b, p. 105) Conclusion UML Use-Case Diagrams are a powerful tool for modeling the functional requirements of a system. In Software Development (SD), they are used early within the modeling process to capture the behavior and the functionality of a system. The primary components of a Use-Case Diagram are actors, use cases, and the relationships between them. The main goal of the components is to describe what the system does. For instance, the Online Shopping System Use-Case Diagram illustrates how actors, use cases, and their relationships capture the functional requirements of an online shopping system, defining what the system does. Additionaly, the two use case documentation examples illustrate samples of Main Flows and Alternative Flows describing how actors use specific use cases. In essence, the UML Use-Case Diagram illustrates “what” the system does, while the use case documentation describes “how” users may interact with specific system functionalities. References: Dolques, X., Huchard, M., Nebut, C., & Reitz, P. (2012). Fixing Generalization Defects in UML Use Case Diagrams. Fundamenta Informaticae , 115(4), 327–356. https://doi-org.csuglobal.idm.oclc.org/10.3233/fi-2012-658cv Helm, J. (n.d.). Business use-case model. Rational unified process. Fall 2023 SWEN 5135 Configuration Management course. University of Houston at Clear Lake. https://sceweb.uhcl.edu/helm/RUP_Folder/RationalUnifiedProcess/process/modguide/md_bucm.htm IBM documentation (2023, September 21). Use-case diagrams. IBM Rational Software Architect documentation. IBM. https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=diagrams-use-case ProcessMaker. (2024, August 20). What is a happy path? ProcessMaker. https://www.processmaker.com/blog/what-is-a-happy-path/ Ricciardi, A. S. (2025, January 2). UML Diagrams: A Guide for Software Engineers. Level up Coding - Medium. https://medium.com/gitconnected/uml-diagrams-a-guide-for-software-engineers-71220ffb775f Unhelkar, B. (2018 a). Chapter 5 — Use case models-4: Actors and use cases. Software engineering with UML . CRC Press. ISBN 9781138297432 Unhelkar, B. (2018 b). Chapter 6 — Use case models-2: Use case diagrams and requirements modeling. Software engineering with UML . CRC Press. ISBN 9781138297432

This article uses a restaurant customer service system to illustrate how business use-case diagrams can effectively model business processes, including interactions between actors and use cases. It demonstrates how Unified Modeling Language (UML) use-case diagrams capture software requirements and discusses their advantages and limitations in Software Development (SD). Alexander S. Ricciardi December 15, 2024 Business use-case diagrams are used to model and illustrate interactions between business actors and processes within businesses. Their primary purpose is to describe how a business is used by its customers and partners (Helm n.d.). In Software Development (SD), use case diagrams are used to capture a system's requirements which is essential in the early stage of SD. This article explores the business use case of a generic restaurant, more specifically the restaurant customer service system by providing a Unify Modeling Language (UML) business use-case diagram and, based on the diagram, offers a critical analysis of the business actors and business interactions. Additionally, it provides a list of advantages and limitations of UML use-cases diagrams in SD. Definition of Use-Case Diagrams A use-case diagram illustrates the behavior of systems helping to capture the working requirements of those systems (IBM, 2023). In other words, the diagram describes the high-level functionality and the main scope of systems. Use-case diagrams also identify the interactions between systems use cases and their actors. Actors and use cases can be defined as follows: Actors can be people, organizations, or external or internal systems that interact with the business. Use cases can be specific functionalities or services that the business provides to the actors and other use cases. Furthermore, use cases can be divided into base use cases, which represent the core functionalities of the systems (can be modified by other use cases), and additional use cases are supplemental functionalities that can modify other use cases. Additional use cases can also be defined as supplemental functionalities that can modify other use cases. In UML use-case diagrams, the interactions between use cases are defined as relationships that can be divided into four categories: Association relationships are illustrations of direct interactions between actors and use cases or between use cases. Include relationships are illustrations of interactions where use cases include the functionalities of other use cases. Extend relationships are illustrations of interactions where use cases are extended by other use cases under certain conditions. Generalization relationships are illustrations of interactions where use cases are generalized versions of other use cases or actors are generalized versions of other actors. It is a parent-child relationship where the parent is the generalized version of a child. (Helm, n.d) Figure 1 Restaurant Customer Service System Diagram Critical Analysis of the Business Actors and Business Interactions The restaurant customer service system is one of several systems that are part of a restaurant; other systems are, for example, inventory management, accounting, and kitchen. Thus the restaurant customer service system represents one functionality of a restaurant organization. It is a process that involves external actors such as dine-in customers and takeaway customers, and internal actors such as servers, bussers, hosts, service managers, and cooks. Use cases include placing an order, making a payment, and preparing food. Relationships within the system include associations, includes, and extends. Additionally, the use case customer service system model showcased in this essay is based on a model that can be built upon. Use Cases Business use cases can be divided into base cases and additional cases; however, they can also be further categorized into three categories which are: Business processes the commercially important activities (Helm n.d.). Supporting activities that are not commercially important, but have to be performed. Management activities are a type of work that affects how the other business use cases are managed. The table below, Table 1, summarizes the use cases within the restaurant customer service system, categorizing them into business processes, supporting activities, and management activities Table 1 Use Cases Table As shown in the table above core business processes like customer service, fulfilling orders, and payment highlight the core functionalities of the business. Supporting activities such as order handling, credit card or cash payment processing, and handling special requests are important functions for the smooth operation of the restaurant and for customer satisfaction. Actors Business actors can represent individuals, organizations, and other businesses that interact with the business. Furthermore, actors who interact with the business but are not part of the business use case system are categorized as external actors, and actors who are an integral part of the use case system are categorized as internal actors. The table below, Table 2, summarizes the internal and external actors that interact with the restaurant customer service system. Table 2 Actors Table As shown in the table above, the interactions between external actors, customers, and internal actors like servers, bussers, and cooks are essential for the successful operation of the restaurant. Relationships Several relationships between actors and use cases, as well as user cases with other use cases and actors with other actors, are involved in the overall functionality of the restaurant customer service system. The relationships have been defined earlier in this essay. However, the generalization relationship can be defined further. It is a relationship that can be described as parent-child inheritance relationship and it can be divided into two categories: Use case generalization a relationship is where the properties of a parent use case or generalized use case, usually a base use case, are inherited by a specialized child use case. Actor generalization is a relationship where the properties of a parent actor or generalized actor are inherited by a specialized child a actors The table below, Table 3, summarizes the different relationships involved in the overall functionality of the restaurant customer service system. Table 3 Relationships Table As shown in the table above, relationships between actors and use cases, as well as user cases with other use cases and actors with other actors, demonstrate how complex interactions within the restaurant customer service system are. Additionally, these relationships showcase how the different components contribute to the overall functionality of the system. Use Cases Advantages and Limitations in Software Development The use case model, as illustrated in the restaurant customer service system example, is a powerful tool that can be used to model and visually represent interactions between business actors and processes within businesses or systems. In SD, more specifically at the early stage of development, UML use-case diagrams are used to capture system requirements (actors, use cases, and relationships) defining the “What” a system should do. However, they struggle to capture and illustrate “How” these requirements should be implemented. The “what” and the “How” distinctions illustrate the advantages and limitations of the use-case model in SD. The following sections list the main advantages and limitations of the model in SD. Advantages Actors and use case components of a UML use-case diagram provide a user-centric approach when modeling a system's requirements. This helps ensure that the correct system is developed by capturing the requirements from a user perspective (Firesmith, n.d). In addition to providing a user-centric approach they also provide the following advantages: Use cases and actors are easy to recognize and their descriptions are written in natural language making it easy to understand and providing an excellent way to communicate with customers and users (Firesmith, n.d.). The following list is from “Chapter 5 – Use Case Models-1: Actors and Use Cases. Software engineering with UML” (Unhelkar, 2018 b, p. 92): Use cases help the business analyst to document requirements in a commonly accepted format in the problem space of the project. The actor, through the use cases, specifies the suite of interactions with the system. Use cases capture the functional aspects of the system. More specifically, they capture the business processes carried out in the system. They are usually developed by domain experts and business analysts, resulting in the effective documentation of functionalities. Since use cases document the complete functionality of a system, no separate functional requirements document is needed (although additional operational and interface requirements or additional details such as the referenced material may be available or placed in a separate document). Use cases facilitate tracing of requirements. By providing well-organized documentation on the requirements, a use case provides a trace for a particular requirement throughout the system. This is especially helpful in creating and executing acceptance tests by users. Use cases can help in the creation of prototypes. Developers can select a use case and produce a proof-of-concept prototype of the system that will validate system requirements. Documentation of a use case provides a means for creating activity diagrams. The documentation of the flow within the use case can also be influenced and improved by the activity diagram(s) drawn for a use case. Specifications and documentation of use cases also provide a rich source of information for the identification of business entities. These business entities can be put together in a suite of class diagrams—providing vital information in the model of the problem space. Use cases can also provide a starting point for sequence diagrams—based on the scenarios (or instances of behavior) documented within a use case. Use cases are the basis for test case development. Use cases aid in requirement mapping: matching a requirement to a software feature to the approved test case. Limitations However, UML use cases also have some limitations. By primarily focusing on a system’s requirements, they may not capture non-functional requirements. In other words, while they capture well what the system should do, they do not demonstrate well how the system should do it. Non-functional requirements, such as performance, security, and usability are often not documented in use cases. In addition to not capturing non-functional requirements properly, UML use cases experience the following limitations. The following list is from “Chapter 5 – Use Case Models-1: Actors and Use Cases. Software engineering with UML” (Unhelkar, 2018 b, p. 92): Use case documentation is not standardized. This leads to confusion and debates on what makes up a good use case. Most projects proceed on the basis of a template (see previous discussion). Use cases are not object-oriented in nature. Therefore, they are not an ideal mechanism to model design-level constructs in the solution space (where object orientation plays an important role). Use cases do not have a granularity standard. Therefore, sometimes use cases are written as huge descriptive documents, resulting in the inability of modelers to capitalize on the reusable and organizational aspect of use case modeling. Alternatively, too brief a description will result in a large number of miniscule use cases—making them less comprehensible and manageable. Use cases do not provide a good basis for coding. Their documentation provides a foundation for subsequent modeling, but not for code generation. Summary Business use case diagrams are used to model and visually represent interactions between business actors and processes within businesses or systems. As shown by the critical analysis of the restaurant customer service system the use cases, actors, and their relationships give a deep insight into the processes, interactions, and dependencies within the restaurant customer service operations. Thus, business use case diagrams are a great tool for stakeholders to gain a deep understanding of the business or a system, identify potential issues, and make informed decisions about system design and development. Additionaly, UML use-case diagrams, with their actors, use cases, and relationships, provide a user-centric approach to capturing a system's requirements which is essential in the early stage of Software Development. They excel at illustrating and capturing the “what” a system should do. However, they are not efficient at capturing and illustrating the “How” these requirements should be implemented. More specifically, they struggle to capture non-functional requirements, and they do not provide a good basis for coding generation. References: Firesmith D., G. (n.d.). Use Cases: the pros and cons. Knowledge Systems Corporation. https://www.cs.hmc.edu/~mike/courses/mike121/readings/reqsModeling/firesmith.htm Helm, J. (n.d.). Business use-case model. Rational unified process. Fall 2023 SWEN 5135 Configuration Management course. University of Houston at Clear Lake. https://sceweb.uhcl.edu/helm/RUP_Folder/RationalUnifiedProcess/process/modguide/md_bucm.htm IBM documentation (2023, September 21). Use-case diagrams. IBM Rational Software Architect documentation . IBM. https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=diagrams-use-case Unhelkar, B. (2018 a). Chapter 6 – Use case models-2: Use case diagrams and requirements modeling. Software engineering with UML. CRC Press. ISBN 9781138297432 Unhelkar, B. (2018 b). Chapter 5 – Use case models-1: Actors and use cases. Software engineering with UML. CRC Press. ISBN 9781138297432