DEV Community: Alex Ricciardi

A UML Use-Case Analysis of an Online Shopping System: Actors, Use Cases, and Relationships

Alex Ricciardi — Wed, 16 Apr 2025 00:11:38 +0000

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.

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

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

Review Cart Items - The system displays items, quantities, and prices from UC02-Cart.
Confirm Order Details - The Customer checks shipping address, billing address, and any taxes or fees.
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

Select PaymentMethod - The system includes UC12-PaymentMethod, prompting the Customer to choose or enter credit card/billing details.
Verify Payment - The system calls UC06-VerifyPayment, which sends the payment request to A05-PaymentGateway.
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). U_ML 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

Originally published at Alex.omegapy on Medium - Level UP Coding on January 12, 2025

IP Address Allocation in a Small Class C Network

Alex Ricciardi — Tue, 15 Apr 2025 23:52:11 +0000

This article provides a step-by-step guide to allocating IPv4 addresses within a small business network using a Class C subnet. It covers key concepts like subnet masks, networks, and broadcast addresses. It also provides an example of an IP addressing scheme for devices like servers, printers, and VoIP phones.

Regardless of the size of a network, proper IP address allocation is crucial for the efficiency and security of a network. This article examines a scenario where a network administrator needs to assign IPv4 addresses within a small Class C network (192.168.1.0/24 with a subnet mask of 255.255.255.0, providing 254 usable addresses). The network comprises 100 nodes, including four servers (a domain controller, a replica, a data server, and a web server), a network printer, and a VoIP phone system.

Overview of the network

It is important before assigning IP addresses to devices to understand the purpose of each device and a plan for IP address allocation. This section analyses the provided Class C network scheme.

Subnet Mask: 255.255.255.0 (or /24) — This is the classful subnet mask for a Class C network.

Table 1
IP Address class

Note: From “Lesson 5: IPv4 and IPv6 addresses. CompTIA Network+ Pearson N10–007 (Course & Labs) ” by uCertify (2019).

Network Address: 192.168.1.0 — This is a private C class network see the table below.

Table 2
Private IP Networks

Note: From “Lesson 5: IPv4 and IPv6 addresses. CompTIA Network+ Pearson N10–007 (Course & Labs) ” by uCertify (2019).

Host IP Addresses

Total Possible IP Addresses:
The /24 subnet mask represents the first 24 bits of the IP address that are used to identify the network, the last 8 bits (32 total bits — 24 network bits = 8 host bits) are used to identify the host IP addresses.
With 8 bits, you can have 28 (2 to the power of 8) or 256 IP address combinations.
Therefore, there are 256 possible IP addresses within the 192.168.1.0/24 network.

Reserved Addresses (Network and Broadcast):
Network Address: the first possible address is reserved for the network address. It has all the bits set to 0. For this example, it is 192.168.1.0.
Broadcast Address: The last possible address is reserved for the directed broadcast address. This address has all bits set to 1. For this example, it is 192.168.1.255.

Host Usable IP Addresses:
Since the network address and the broadcast address are reserved, they cannot be assigned to hosts.
Therefore, the number of usable host IP addresses is 256–2 = 254.
To calculate the total possible host IP addresses the following formula is used:
2ʰ-2
where h is the number of host bits in a subnet mask, for example, is:
2⁸–2 = 256–2 = 254
See the table below.

Table 3
Usable Host IP Addresses

Note: From “Lesson 5: IPv4 and IPv6 addresses. CompTIA Network+ Pearson N10–007 (Course & Labs) ” by uCertify (2019).

Number of Devices 100 nodes (4 servers, 1 printer, 1 VoIP system — assuming multiple phones, and the rest are workstations).

In summary:

Network: 192.168.1.0/24
Total IP Addresses: 256
Network Address: 192.168.1.0
Broadcast Address: 192.168.1.255
Usable IP Addresses: 254 (from 192.168.1.1 to 192.168.1.254)

Specific Device IP Address Requirements

This section examines possible solutions to specific devices’ IP Address requirements and proposed IP addressing schemes, by considering the device types and their roles within the network. The network needs to support servers, printers, a VoIP system, workstations, and mobile devices.

Servers typically require static IP addresses; this allows consistent access, enhances security, and simplifies management. It is especially important for the domain controller, which needs a fixed address for clients to connect reliably.

Printers can use dynamic IP addresses, however assigning a static IP address to the printer that has mobile printing capability ensures that mobile devices can consistently locate and connect to it.

VoIP Phone Systems require a set range of IP addresses to function correctly, for security reasons; it is also important that the allocated range is large enough to accommodate the number of phones and potential scaling. Workstations, laptops, and mobile devices typically use dynamic IP addresses. This allows devices to automatically receive IP addresses from a DHCP server, providing flexibility to the user and reducing network administrative overhead.

Devises IP address Scheme

Now that the device IP address requirements have been defined, the device IP address scheme can be set by diving the network range into logical pools:

Network infrastructure devices (e.g., Router, Firewall, Default Gateway)
192.168.1.1–192.168.1.9 (9 devices)
These addresses are reserved for network infrastructure devices such as the default gateway (for example, 192.168.1.1) or a firewall device.

*Servers *(Domain Controller, Replica, Data Server, Web Server)
192.168.1.10–192.168.1.14 (5 devices)
Static IP addresses are assigned to the servers.
Example:

Domain Controller: 192.168.1.10
Replica DC: 192.168.1.11
Data Server: 192.168.1.12
Web Server: 192.168.1.13

Network Printer(s)
192.168.1.15–192.168.1.17 (3 devices)
Static IP addresses to the printer and future printers.

VoIP phones
192.168.1.18–192.168.1.39 (22 devices)
This pool is used for VoIP phones.
DHCP Pool (Dynamic Addresses for Workstations, Laptops, Mobile Phones, etc.)
192.168.1.40–192.168.1.200 (161 devices)
It allows devices to receive addresses automatically, and the range can be adjusted in the DHCP server’s configuration. This covers the 100 hosts and adds 61 extra addresses for mobile devices and scaling.

Reserved for scaling
192.168.1.201–192.168.1.254 (54 devices)
Keep a block of addresses for future needs and scaling.

To summarize, this post explored the allocation of IP addresses within a small Class C network: 192.168.1.0/24 network. By understanding the scheme of the network, including its subnet mask, total and usable IP addresses, and the specific requirements of different devices, an IP addressing scheme was developed to accommodate the needs of the different types of devices and meet the requirements set by the given scenario.

References:

uCertify. (2019). Lesson 5: IPv4 and IPv6 addresses. CompTIA Network+ Pearson N10–007 (Course & Labs) [Computer software]. uCertify LLC. ISBN: 9781616910327

Originally published at Alex.omegapy on Medium - Level UP Coding on January 5, 2025

TCP/IP Open Port Scanning: Open Ports, Hidden Dangers

Alex Ricciardi — Tue, 15 Apr 2025 23:39:14 +0000

The article explores TCP/IP port scanning by considering its potential benefits and drawbacks. It emphasizes the importance of balancing proactive vulnerability identification with the potential impact on network performance and security systems.

TCP/IP ports are used by devices and applications on a network to communicate. In other words, they act as a gateway for devices, programs, and networks to broadcast information and communicate (Kolaric, 2024). However, as communication gateways, their open nature makes them vulnerable to exploitation by malicious actors. One potential solution to mitigate this risk is to regularly scan open ports. This post examines the efficiency and feasibility of scanning open TCP/IP ports, that is whether it helps secure them or creates more problems than it solves.

Before exploring port scanning, it is important to understand why TCP/IP ports are vulnerable in the first place. For example:

Unsecured (legacy) services, protocols, or ports such as 21 (FTP), 23 (Telnet), 110 (POP3), 143 (IMAP), and 161 (SNMPv1 and SNMPv2) are vulnerable because the protocols using these ports do not provide authentication, integrity, or confidentiality (cjs6891, n.d.).
Attackers often target default ports, that is ports used by services with default configurations such as databases like SQL Server and MySQL (ports 1433, 1434, and 3306), as well as services such as SSH (port 22), and HTTP (port 80). These ports are targeted because they are well-known and widely used as default ports for databases, services, and some applications.
Even secure protocols such as HTTPS (port 443) are vulnerable to attacks like cross-site scripting (XSS) and SQL injections, which exploit weaknesses that are part of web applications (Techa, 2024).

Attackers use various approaches to exploit open TCP/IP ports’ vulnerabilities. Methods such as credential brute-forcing (repeatedly trying to login with different login credentials), spoofing and credential sniffing (impersonating legitimate users to intercept and steal sensitive information), exploiting application vulnerabilities (listening on open ports to gain control of systems or steal data), and denial-of-service (DOS) (flooding open ports with traffic, overwhelming a system) (Murphy, 2023).

With so many potential threats targeting open TCP/IP ports, a potential proactive solution to mitigate this risk is TCP/IP port scanning. TCP/IP port scanning is a technique, a software, that runs a port scan on a network or server to identify which ports are open and listening (receiving information) as well as revealing the location or presence of network security devices, like firewalls (Paloalto, n.d.). This technique is also called fingerprinting. Fingerprinting can help identify open ports and the services running on them, revealing potential suspicious activities. For example, multiple unauthorized access or login attempts and the presence of unknown services. Port scanning can be used to verify that security devices are in place, functioning correctly, and that only authorized ports are open. It can also map active hosts and those hosts to their IP addresses revealing unknown IP addresses and active hosts, as well as detecting unauthorized changes to the network configuration. Therefore, port scanning can be used as a proactive security tool for identifying and addressing security vulnerabilities within a network.

However, if used too aggressively port scanning can interfere with another security system such as Intrusion Detection Systems (IDS) triggering unwanted security alerts. It can also impact network performance by consuming network bandwidth and resources. Thus, it is essential to balance the use of port scanning with the appropriate frequency and scope of the scans. It is also essential to use the appropriate tools and techniques that are best suited to the specific characteristics of the network. Below is a table describing some of those tools and techniques.

Table 1
Tools and Techniques for Port Scanning

Note: Data from NMAP (n.d) and Kost (2024).

To summarize, TCP/IP port scanning is a proactive technique for assessing and improving network security. However, if used too aggressively port scanning can interfere with security systems and impact network performance. Therefore, it is essential to define the appropriate scope and frequency of scans and to select the right tools and techniques that are best suited to the specific characteristics of the network. When used properly port scanning can play a role in mitigating the risks associated with open TCP/IP ports and strengthening the overall security of a network.

References:

cjs6891 (n.d.). Cisco CCNA Cyber Ops SECFND 210–250, Section 3: Understanding Common TCP/IP Attacks. E17_blog. GitHub. https://cjs6891.github.io/el7_blog/texts/cisco-ccna-cyber-ops-secfnd-3/#:~:text=Examples%20of%20insecure%20services%2C%20protocols,authenticity%2C%20integrity%2C%20and%20confidentiality.

Kolaric, D. (2024, June 5). Identifying secure and unsecured ports and how to secure them. All About Security. https://www.all-about-security.de/identifying-secure-and-unsecured-ports-and-how-to-secure-them/

Kost, E. (2024, November 18). Top 5 Free Open Port Check Tools in 2024. UpGuard. https://www.upguard.com/blog/best-open-port-scanners

Murphy, D. (2023, December 11). Open Port Vulnerabilities: How to Secure Open Ports. Lepide Blog. https://www.lepide.com/blog/how-to-secure-open-ports-from-vulnerabilities/

NMAP Org. (n.d). TCP SYN (Stealth) Scan (-sS) | Nmap Network Scanning. NMAP Org.https://nmap.org/book/synscan.html#:~:text=TCP%20SYN%20(Stealth)%20Scan%20(,it%20never%20completes%20TCP%20connections

Paloalto (n.d.). What is a Port Scan? Palo Alto Networks. https://www.paloaltonetworks.com/cyberpedia/what-is-a-port-scan#:~:text=Running%20a%20port%20scan%20on,revealing%20the%20presence%20of%20security&text=Port%20scanning%20plays%20a%20crucial,can%20signal%20potential%20security%20vulnerabilities

Schrader, D. (2024, September 23). Identifying common open port vulnerabilities in your network. Netwrix. https://blog.netwrix.com/open-ports-vulnerability-list

Techa, M. (2024, November 11). Understanding common ports used in networks for TCP and UDP usage. Netwrix. https://blog.netwrix.com/common-ports

Originally published at Alex.omegapy on Medium - Level UP Coding on January 5, 2025

UML Diagrams: A Guide for Software Engineers

Alex Ricciardi — Tue, 15 Apr 2025 23:30:50 +0000

This article provides an overview of Unified Modeling Language (UML) diagrams, their types, and their applications in software engineering. It covers their types, applications, and use in software engineering and explains how UML diagrams help software developers visualize, design, and document complex systems.

In Software Engendering (SE), Unified Modeling Language (UML) diagrams are essential tools for communicating ideas and understanding systems. UML diagrams are integral to SE because they present a suite of modeling artifacts that are a globally accepted standard for SE (Unhelkar, 2018 a). In other words, they provide a standard visual language for representing the structure, behavior, and interactions within software systems (Tim, 2024). Furthermore, these diagrams are organized within distinct modeling spaces (MOPS, MOSS, and MOAS) that guide their application to specific aspects of the software development process (Unhelkar, 2018b). They help software developer teams to plan, design, and communicate with stakeholders. UML version 2.5 defines 14 types of diagrams, use case, activity, package, class, profile, sequence, communication, interaction overview, object, state machine, composite structure, component, deployment, and timing diagrams. The table below provides a brief description of each diagram.

Table 1
UML Diagrams

Note: Data from “Chapter 2 — Review of 14 Unified Modeling Language Diagrams” by Unhelkar (2018 a). Modify.

As shown in Table 1, there are two main categories of UML diagrams, structural and behavioral.A structural diagram illustrates the way a system is organized/structured whereas a behavioral diagram illustrates the flow of activity, actions, or interactions (behaviors) within the system (Unhelkar, 2018 a).A diagram can represent either a static or dynamic view of a system. Static diagrams illustrate the structure of a system at a specific point in time, whereas dynamic diagrams capture the system’s changes over a period of time or during execution, emphasizing its time-dependent aspects.

The diagram below categorizes the diagrams into structural and behavioral groups and adds the interaction subgroup to the behavioral category. An interaction diagram shows interactions between the components of a system, and it can also depict how a system as a whole interacts with external entities (Dwivedi, 2019).

Figure 1
UML Diagrams Diagram

Note: From “Unified Modeling Language (UML) Diagrams” by GeeksforGeeks (2024).

Each UML diagram plays a role in modeling different areas of a software system. These areas can be divided into three categories called modeling spaces with each diagram responsible for modeling within those spaces (Unhelkar, 2018 b). The three modeling spaces are:

Model of Process Space (MOPS) or Problem Space: It models “what” the business problem or user is. MOPS’ goal is to understand and model the business requirements.
Model of Solution Space (MOSS): It models “how” the solution of the problem will be implemented. MOSS’ goal is to represent the system’s structure, behavior, and interactions using diagrams like class diagrams, sequence diagrams, and object diagrams.
Model of Architectural Space (MOAS): It models the “big picture” and the overall technical environment. MOAS’ goals are to define architectural constraints, manage the project, and ensure quality.

These spaces are crucial for organizing and structuring the software development process, without them the use of UML can degenerate into incorrect or excessive modeling (Unhelkar, 2018 b).The figure below illustrates how the three models relate to each other, to the different actors, and to the software development process.

Figure 2
Modeling Spaces

Each UML diagram has varying levels of importance within the different modeling spaces. The table below maps each diagram to each modeling space, assigning up to 5 ‘’ to show the diagram’s level of importance within a mapped space, with 5 ‘’ being the highest level of importance (Utmost Importance).

Table 2
Importance of each UML Diagram to Respective Modeling Space (with 5 * for Utmost Importance to That Particular Space)

Note: From “Software Projects and Modeling Spaces: Package Diagrams. Software Engineering with UML,” Table 3.2, by Unhelkar (2018 b).

For example, in the Model of Solution Space (MOSS), the three most important diagrams are the class, sequence, and composite structure diagrams. Where each diagram plays a different role in modeling the solution:

Class diagrams illustrate detailed designs and programming constructs. They can also model relational database tables. Class diagrams define the system’s structure, showing the classes, their attributes, methods, and the relationships between them.
Sequence diagrams illustrate detailed models of interactions within the system. They depict the dynamic exchange of messages between objects over time.
Composite structure diagrams illustrate the internal structure of a classifier (like a class or component), that is the functionality of a group of objects and components, including their interfaces and realizations. It is only a UML diagram used to model the physical components of a system or business.
(Unhelkar, 2018 b)

For example, let’s explore the composite structure diagrams of a simple item class. See the figure below.

Figure 3
Item Class Composite Structure Diagram

Note: Te item class provides an interface for the website component of the project, allowing the website to access and display item information such as name, price, and availability. The figure below provides a basic illustration of the components that can be found in a UML composite structure diagram.

Figure 4
Basic Composite Structure Diagram Components

Note: From “Composite Structure Diagram” by Udacity (2015)

To summarize, UML diagrams are essential for communicating ideas and understanding systems. The 14 UML diagram types are categorized as either structural or behavioral and can represent either a static or dynamic view of a system. Additionally, these diagrams within modeling spaces — MOPS, MOSS, and MOAS — have varying levels of importance. Thus, selecting the most relevant diagrams for each stage of the software development lifecycle is essential. As shown in the example of the Item Class Composite Structure Diagram is an application of UML within the appropriate modeling space (MOSS in this case). Ultimately, the strategic use of UML diagrams throughout the software development lifecycle is essential to avoid incorrect or excessive modeling, as they guide, and empower software engineers to create representations of problems, solutions, structures, interactions, and relationships within complex systems.

References:

Dwivedi, N. (2019, September 9). Type of UML models. Software Design: Modeling with UML [Video]. LinkedIn Learning. https://www.linkedin.com/learning/software-design-modeling-with-uml/types-of-uml-models?u=2245842

GeeksforGeeks (2024, October 23). Unified Modeling Language (UML) diagrams. GeeksforGeeks. https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

Tim. (2024, November 5). Top 7 most common UML diagram types for software architecture. Icepanel. https://icepanel.io/blog/2024-11-05-top-7-most-common-UML-diagram-types

Udacity (2015, February 23). Composite structure diagram [Video]. YouTube. https://www.youtube.com/watch?v=pJyuKhD86Ro

Unhelkar, B. (2018 a). Chapter 2 — Review of 14 Unified Modeling Language diagrams. Software engineering with UML. CRC Press. ISBN 9781138297432

Unhelkar, B. (2018 b). Chapter 3 — Software projects and modeling spaces: Package diagrams. Software engineering with UML. CRC Press. ISBN 9781138297432

Originally published at Alex.omegapy on Medium by Level UP Coding on January 2, 2025

UML Use Case Diagrams: A Restaurant System Case Study

Alex Ricciardi — Sun, 09 Feb 2025 03:48:51 +0000

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).

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 Unified 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.

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

Originally published at Alex.omegapy on Medium by Level UP Coding on November 22, 2024

OSI Model, TCP/IP Framework, and Network Topologies Explain

Alex Ricciardi — Sun, 09 Feb 2025 03:34:07 +0000

This article provides a detailed explanation of the OSI model and its seven layers. It also explores the TCP/IP model, compares it to the OSI framework, and examines network topologies, their characteristics, advantages, and applications.

In networking, the Open Systems Interconnection (OSI) model is a standardized reference framework that describes how data flows in networks or how networked devices communicate with each other. In 1977 the International Organization for Standardization (ISO) developed OSI to standardize the interoperability of multivendor communications systems into one cohesive model (uCertify, 2019 a). The OSI Model is a reference model, it is not a reverence model (Wallace, 2020). In other words, the model does not need to be revered as a framework where every network component or device must neatly fit. However, it can be used as a tool to explain and understand where different network components or devices reside. This makes the model very useful for diagnosing and fixing network issues as it helps isolate problems within its different layers.

The OSI model is composed of seven layers:

Layer 1: The physical layer
Layer 2: The data link layer
Layer 3: The network layer
Layer 4: The transport layer
Layer 5: The session layer
Layer 6: The presentation layer
Layer 7: The application layer

Note that the application layer is the last in the OSI queue, as it is the closest to the user. However, graphically the layers are usually represented as a stack, bottom-up, as illustrated in Figure 1.

Figure 1
OSI Layers

Note: From “The OSI reference model. CompTIA Network+ Pearson N10–007”, Figure 2.2, by uCertify. (2019 a).

Each layer represents a different network functionality as shown in Figure 2.

Figure 2
OSI vs. TCP/IP

Note: From “Objective 1.01 Explain, compare, and contrast the OSI layers” by vWannabe (n.d.).

In Figure 2, the OSI stack is compared to the TCP/IP stack model, which is a reference model based on the TCP/IP protocol suite. The TCP/IP model is used to describe communications on the Internet and simplifies the OSI layers into four categories which are Network Interface (Network access layer), Internet (Internet layer), Transport (Host-to-Host layer), and Application (Process/Application layer) see Figure 3.

Figure 3
OSI and TCP/IP

Note: From “The OSI reference model. CompTIA Network+ Pearson N10–007”, Figure 2.15, by uCertify. (2019 a).

The TCP/IP layers map to the OSI layers as follows:
Network Interface: Combines the physical and data link layers of the OSI model.
Internet: Corresponds to the network layer of the OSI model.
Transport: Maps directly to the transport layer of the OSI model.
Application: Consolidates the session, presentation, and application layers of the OSI model.

As shown above, for me, the OSI model is a great tool for understanding network systems and diagnosing issues. When connected to the TCP/IP model, it provides practical insights into troubleshooting and understanding Internet systems, which is where most of today’s networks operate.

Another important concept to understand is network topology. Topology classifies the arrangement of devices and connections within a network, either physically (physical topology) or logically (logical topology). Below is an illustration of the most common topologies:

Figure 4
Network Topologies

Note: From “Lesson 1: Computer Network Fundamentals. CompTIA Network+ Pearson N10–007,“ various Figures, by uCertify (2019 b). Modify.

The table below describes the characteristics, advantages, and limitations of various topologies.

Table 1
Network Topologies

Note: Data from “Lesson 1: Computer Network Fundamentals. CompTIA Network+ Pearson N10–007“ by uCertify (2019 b).

As shown in Table 1, each topology has its pros and cons depending on the needs, budget, and future goals of a business. One topology may be more suitable than another. Below, Table 2 is a comparison between Star and Generic Mesh Topologies, that showcases their advantages, disadvantages, and the types of business applications or use cases they are best-suited for.

Table 2
Comparison of Star and Generic Mesh Topologies

Note: Data from “Lesson 1: Computer Network Fundamentals. CompTIA Network+ Pearson N10–007“ by uCertify (2019 b).

As shown in Table 2 a star topology is better suited for Small-to-medium businesses due to its low cost as mesh topology is better suited for large enterprise networks, data centers, and IoT networks that require fault tolerance.

To summarize, the OSI model is a foundational framework for understanding network communication and diagnosing connection issues. It is particularly helpful when used in conjunction with the TCP/IP model to troubleshoot and understand modern Internet systems. Additionally, network topology helps to define the structure of networks by setting the arrangement of devices and connections, both physically and logically, enabling businesses to select the most suitable configuration based on their specific needs and goals.

References:

uCertify. (2019 a). Lesson 2: The OSI reference model._ CompTIA Network+ Pearson N10–007 (Course & Labs) _[Computer software]. uCertify LLC. ISBN: 9781616910327

uCertify. (2019 b). Lesson 1: Computer Network Fundamentals. CompTIA Network+ Pearson N10–007 (Course & Labs) [Computer software]. uCertify LLC. ISBN: 9781616910327

vWannabe (n.d.). Objective 1.01 Explain, compare, and contrast the OSI layers. vWannabe.com. https://vwannabe.com/2013/07/29/objective-1-01-explain-compare-and-contrast-the-osi-layers/

Wallace, K. (2020, December 11). Networking foundations: Networking basics [Video]. LinkedIn Learning. Retrieved from: https://www.linkedin.com/learning/networking-foundations-networking-basics/a-high-level-look-at-a-network?autoSkip=true&resume=false&u=2245842.

Originally published at Alex.omegapy on Medium by Level UP Coding on December 15, 2024

The Relationship Between Software Modeling and Software Development

Alex Ricciardi — Sun, 09 Feb 2025 03:21:20 +0000

This article explores the relationship between Software Modeling (SM) and Software Development (SD) within Software Engineering. It examines how SM, through techniques like UML diagrams, supports and enhances the SD process by improving communication, reducing errors, and providing essential documentation.

Software Engineering (SE) is the art of engineering high-quality software solutions. The Object Oriented (OO) approach, Software Development (SD) process, and Software Modeling (SM) are components of SE. This article explores these components, more specifically the relationship between SD and SM. How through this relationship software developer teams build systems that are efficient, robust, and provide high-quality software solutions to users.

Software Engineering

First, let’s define Software Engineering. “The goal of SE is to produce robust, high-quality software solutions that provide value to users. Achieving this goal requires the precision of engineering combined with the subtlety of art” (Unhelkar, 2018, p.1). SE involves a wide range of functions, activities, and tasks such as:

Project management, business analysis, financial management, regulatory and compliance management, risk management, and service management functions.
Functions are SE teams’ responsibilities or disciplines that often span the entire software development lifecycle.
Development processes, requirements modeling, usability design, operational performance, security, quality assurance, quality control, and release management activities.
Activities are SE actions taken during certain stages of the software development, they are often performed repeatedly in functions or processes.
Tasks are small SE’s actions taken during certain functions or processes. They are often individual steps necessary to perform a specific activity.

(Unhelkar, 2018)

As shown above, SE is a complex process that can be decomposed into four components which are essential to learn and to adopt SE. These components are fundamentals or object-oriented, modeling (UML standard), process (SDLC, Agile), and experience (case studies and team-based project work).

Figure 1
The Four Essential Components to Adopt Software Engineering

Note: From “Software Engineering Fundamentals with Object Orientation. Software Engineering with UML” by Unhelkar (2018, p.2).

Below is a brief definition of each component:

Object Oriented (OO)

Object Oriented is the concept of object orientation based on Object Oriented Programming (OOP) languages such as Java and Python. OO is composed of six fundamentals (encapsulation, inheritance, polymorphism, abstraction, composition, and association) that help in creating classes and programs that process and manipulate data and objects.

These OO fundamentals are as follows:

Classification (grouping)
Abstraction (representing)
Encapsulation (modularizing)
Association (relating)
Inheritance (generalizing)
Polymorphism (executing)

(Unhelkar, 2018, p.5)

Software Modeling (SM)

Software Modeling is a project modeling standard based on the Unified Modeling Language (UML) that is used the create diagrams to improve communication and participation from all project stakeholders. This also improves the quality of the software, reduces errors, and encourages easy acceptance of the solution by users. UML’s purpose in SE is modeling, developing, and maintaining software.

Figure 2
Purpose of Unified Modeling Language in Software Engineering

Note: From “Software Engineering Fundamentals with Object Orientation. Software Engineering with UML” by Unhelkar (2018, p.13).

UML in modeling purpose modeling, developing, and maintaining software can be listed as follows:

Visualizing: The primary purpose of the UML is to visualize the software requirements, processes, solution design, and architecture.
Specifying: UML is used to facilitate the specification of modeling artifacts. For example, a UML class diagram can specify/describe the attributes and methods of a class, along with their relationships.
Constructing: UML is used for software construction because it can be easily translated into code (e.g., C++, Java).
Documenting: UML diagrams can be used as detailed documentation for requirements, architecture, design, project plans, tests, and prototypes.
Maintaining: UML diagrams are an ongoing aid for the maintenance of software systems. Additionally, they provide a visual representation of a project’s existing system, architecture, and IT design. This allows the developer to identify the correct places to implement changes and understand the effect of their changes on the software functionalities and behaviors.

(Unhelkar, 2018)

Process or Software Development (SD)

Process or Software Development is the process that defines activities and phases, as well as providing directions to the different teams of designers and developers throughout the Software Development Lifecycle (SDLC). Methodologies, such as Waterfall and Agile are used to guide and give structure to the development process. Additionally, they help the development teams to complete projects in an efficient manner, meet standards, and meet user requirements. The waterfall methodological approach is linear and plan-driven whereas the Agile methodological approach is more flexible and adaptive.

These approaches are usually structured around 5 key components:

Requirements gathering and analysis
Design and architecture
Coding and implementation
Testing and quality assurance
Deployment and maintenance

(Institute of Data, 2023, p.2)

Experience

Experience or case studies and team-based project work is the process of learning a project’s best approaches and solutions through experimenting with UML and object-oriented fundamentals. “Experience in creating UML models, especially in a team environment, is a must for learning the art of SE” (Unhelkar, 2018, p.2)

How Software Modeling Supports Software Development

As described above, SD and SM are components of SE playing different roles in SDLC. The difference between SD and SM resides in SD being the methodological process that guides the creation and development of software, and SM being the representation of the software’s architecture and functionality through diagrams based on UML. SM’s primary role is to support SD by providing a visual representation of the project, reducing errors and scope creep, as well as providing documentation:

Project visualization: UML diagrams, especially case diagrams, allow stakeholders to visualize program functionality and behaviors at a high level (Fenn, 2017). This helps teams to focus on where they need more requirements, details, and analysis. It supports the SM phase of requirements gathering and analysis.
Reducing errors and scope creep: Software modeling can provide a clear model of the project by serving as a reference for the project requirements, minimizing errors, misunderstandings, and scope creep, particularly during the early stages of the software development process (Fenn, 2017). Scope creep is expanding or adding to the project requirements or objectives beyond the original scope. It supports the SM phase of design and architecture.
Providing documentation: UML diagrams can serve as living documentation for the project, describing the project functionality and behaviors as it is developed and after deployment. This documentation can help with decision-making for functionality/behavior implementation and maintenance of the software. It supports the SM phases of “coding and implementation” and “deployment and maintenance.”

By applying the concept listed above SM helps the SD process to create efficient, robust, high-quality software solutions that provide value to users.

UML Example

The following is a UML Class diagram of a simple banking manager Java program that utilizes the swing library, a graphical user interface (GUI) library. The program manages bank accounts and checking accounts with various functionalities such as creating accounts, attaching checking accounts, depositing and withdrawing funds, and viewing account balances.

In UML, class diagrams are one of six types of structural diagrams. Class diagrams are fundamental to the object modeling process and model the static structure of a system. Depending on the complexity of a system, you can use a single class diagram to model an entire system, or you can use several class diagrams to model the components of a system. Class diagrams are the blueprints of your system or subsystem. You can use class diagrams to model the objects that make up the system, to display the relationships between the objects, and to describe what those objects do and the services that they provide.

(IBM, 2021)

Figure 3
UML Class Diagram Example

Note: From “Module-4: Portfolio Milestone” By Ricciardi (2024, p.5)

To summarize, SE is the art of engineering high-quality software solutions through OO, SD, and SM. SM helps the SD process by providing clear visual representations of system requirements and architecture, reducing errors, minimizing scope creep, improving communication among stakeholders, and serving as living documentation throughout the software development lifecycle.

References:

Fenn, B. (2017, October). UML in agile development. Control Engineering, 64(10), 48. https://csuglobal.idm.oclc.org/login?qurl=https%3A%2F%2Fwww.proquest.com%2Ftrade-journals%2Fuml-agile-development%2Fdocview%2F2130716718%2Fse-2%3Faccountid%3D38569

IBM (2021, May 5) Rational Software Modeler 7.5.5. IBM. https://www.ibm.com/docs/en/rsm/7.5.0?topic=structure-class-diagrams

Institute of Data (2023, September 5). Understanding software process models: What they are and how they work. Institute of Data. https://www.institutedata.com/us/blog/understand-software-process-models/

Ricciardi, A. (2024, July 7). Module-4: Portfolio Milestone. CSC372: Programming 2. Depart of Computer Science. Colorado State University Global. https://github.com/Omegapy/My-Academics-Portfolio/blob/main/Programming-2-CSC372/Module-4%20Portfolio%20Milestone/Module-4%20Portfolio%20Milestone.pdf

Unhelkar, B. (2018). Software engineering fundamentals with object orientation. Software engineering with UML. CRC Press. ISBN 9781138297432

Originally published at Alex.omegapy on Medium by Level UP Coding on December 12, 2024

The Role of Probability in Decision-Making: A Blackjack Case Study

Alex Ricciardi — Sun, 09 Feb 2025 03:07:23 +0000

Uncertainty, by definition, is a nebulous concept; it encapsulates the unknowns and ambiguities. Probability plays a crucial role in quantifying uncertainty, helping establish degrees of belief –percentages– in the likelihood of an outcome or outcomes in a given scenario or set of scenarios. This paper explores the concept of probability by applying it to a easy to understand example involving the game of Blackjack.

Probability

Probability is the likelihood of something happening. It can also be defined as a mathematical method used to study randomness. In other words, probability is a mathematical method that deals with the chance of an event occurring (Illowsky et al., 2020). This section describes some of the fundamental concepts of probability. Starting with the concept of sample space, often donated Ω. It is the set of all possible outcomes from a scenario or a set of scenarios. An event denoted E or ω is a subset of the sample space, it consists of one outcome or multiple outcomes. In probability theory, the probability of a specific possible outcome donated P(E), from the sample space is a value between 0 and 1, inclusive (Russell &Norvig, 2021). With a ‘0’ probability meaning the outcome will never occur, a ‘1’ probability meaning the outcome will always occur, and a value between ‘0’ and ‘1’ meaning the likelihood of the outcome, the higher values the greater likelihood. This can be formulated as follows:

and

The probability method comes with a set of rules, proprieties, laws, and theorems that are fundamental principles used for computing the likelihood of events occurring. Below is a list of some of these rules, proprieties, principles, and theorems:

A and B are events.

Addition rule: Computes the probability of either one of two events from occurring (Data Science Discovery, n.d.).

For mutually exclusive events (events that cannot occur simultaneously):
P(A ∪ B) = P(A ∨ B) = P(A) + P(B)
For non-mutually exclusive events:
P(A ∪ B) = P(A ∨ B) = P(A) + P(B) — P(A ∧ B)

Multiplication rule: Computes “the joint probability of multiple events occurring together using known probabilities of those events individually” (Foster, n.d., p.1).

For independent events (the occurrence of one does not affect the other):
P(A ∩ B) = P(A ∧ B) = P(A) ∙ P(B)
For dependent events:(the occurrence of one does affect the other)
P(A ∩ B) = P(A ∧ B) = P(A) ⋅ P(B|A)
P(B|A): conditional probability (see below).

Complement rule: “The complement of an event is the probability that the event does not occur” (Elberly College of Science, n,d., Section 2.1.3.2.4).

P(¬A) = 1 — P(A)

Conditional probability: It is the probability of an event occurring given that another event has already occurred. The probability of A given B:
The Bayes’ Theorem: Computes the reverse of the conditional probability. It updates the probability of an outcome based on new evidence. It can also be defined as

Where:
P(A) is the prior probability of an event A.
P(B) is the probability of an event B.
P(B|A) is the probability of an event B occurring given that A has occurred.
P(A|B) is the probability of an event A occurring given that B has occurred.

(Dziak, 2024)

These rules, proprieties, principles, and theorems provide a range of tools to solve probabilistic problems in simple scenarios such as rolling dice and card games like Blackjack.

Blackjack Scenario

Let’s explore a Blackjack scenario when the dealer is showing a 10. In Blackjack, specific rules dictate when to take a hit or stand, especially when the dealer is showing a 10, that is the house hand is showing a 10. Suppose a single deck is in play, and four cards are already dealt. If you have a 10 and a 7 visible, and the dealer shows a 10, let’s calculate the probability that the dealer’s hidden card is an 8, 9, or a face card, and why it makes sense to hit on a 16 but to stand on a 17.

In this Blackjack scenario, the concepts of dependency and conditional probability play an essential role in calculating the probabilities. Two events are said to be dependent if the outcome of one event affects the probability of the other. In this scenario, the events are dependent because the cards are drawn without replacement being placed. This means that each card dealt to the player or the house hands changes the composition of the deck and thus affects the probabilities of future events.

Analyses of the Scenario

Now that the probability methods have been established let’s analyze the problem in more detail. In blackjack, the goal of a player is to finish the game with a higher hand than that of the house, without exceeding 21, as going over 21 is known as ‘busting’ and it is an automatic loss (Master Traditional Games, n.d.). The face cards have a value of 10 and Ace can either be treated as 1 or 11 with the player choosing the value. The player and the house can either hit or stand, the player or players go first, and after all the players stand the house goes next. Note that all players are playing against the house, not each other, and if the house’s hand matches a player’s hand it results in a draw between the player and the house. A standard deck of cards has 52 cards. The player’s hand has a 10 and a 7, totaling 17. The house has a 10 as the dealer up-card, and a fourth card is on the table, the dealer hole-card. Therefore 3 card values are known and 52 – 3 = 49 cards are unknown. The scenario calls to calculate the probability of the house’s other card, the dealer hole-card, being an 8, 9, or face card, as any of those cards would give to house a better hand than the player. A standard deck has 4 8s, 4 9s, 4 Jacks, 4 Queens, and 4 Kings. Mathematically, this can be translated to:

4(8s) + 4(9s) + 4(Jacks) + 4(Queens) + 4(Kings) = 20 house favorable cards.

This means that from a set of 49 unknown cards 20 of those cards are favorable to the house. Thus, the probability that the house’s other card, the dealer hole-card, is one of the house’s favorable cards is:

This means that the probability of the house having a better hand than the player is 40.82% when considering only the 8, 9, or face cards as the possible cards on the table.

On a side note, the Ace card was not considered in this scenario, and an Ace can be treated as a 1 or 11. If the dealer hole card is Ace then the house’s hand would be 10 + 11 = 21, Blackjack. A card deck has 4 Aces, additionally, the 2 remaining 10 cards were also not considered in this scenario, this changes the number of house favorable cards to
20 + 4(Aces) + 2(10) = 26 and the probability to:

This considerably improves the probability of the house having a better hand than the player from 40.82% to 53.06%.

Why It Makes Sense to Hit on a 16 but Stand on a 17?

The scenario claims that it makes sense to hit on a 16 but to stand on a 17; if the house will stand on a 17 and above. Let’s explore the scenario where the player has a hand of 16. If the player decides to hit, they can improve their hand by drawing a 1 (Ace), 2, 3, 4, or 5, that is a total of 5 types of cards out of a set of 13 types of cards (Ace through King) are favorable to the player with a hand of 16. Note that this calculation is not based on the number of cards in a deck but on the number of types of cards found in a deck, 13, rather than the total number of cards left in the deck, as the specific card composition of the player’s hand of 16 is unknown. Therefore, the probability of the player hitting a favorable type of card is:

Thus, if the house’s hand is a 17 and above, it makes sense for the player to hit as they have an approximately 38.46% chance to draw a favorable card. If the player does not hit, they will automatically lose since the house has a better hand.

Now let’s explore the scenario where the player has a hand of 17. If the player decides to stand, they can improve their hand by drawing a 1 (Ace), 2, 3, or 4, a total of 4 types of cards out of set of 13 types of cards are favorable to the player with a hand of 17. Therefore, the probability of the player hitting a favorable card is:

Conclusion

Probability plays a crucial role in quantifying uncertainty; it helps establish the likelihood of an outcome or outcomes in a given scenario or set of scenarios. This paper explored the concept of probability, by applying its principles to a practical example, the game of Blackjack. This simple example shows how powerful the concept of probability can be; by demonstrating how probability can be used to evaluate risks, calculate potential outcomes, and make strategic choices. Probability as a tool for making decisions, can be apply not only in games but also in various real-world situations where uncertainty is a factor.

References:

Data Science Discovery (n.d.). Multi-event probability: Addition rule. University of Illinois at

Urbana-Champaign (UIUC). https://discovery.cs.illinois.edu/learn/Prediction-and-Probability/Multi-event-Probability-Addition-Rule/#Addition-Rule-Formula

Dziak M. Bayes’ theorem. Salem Press Encyclopedia of Science. 2024. Accessed November 18, 2024. https://search.ebscohost.com/login.aspx?direct=true&AuthType=ip,uid&db=ers&AN=89142582&site=eds-live

Elberly College of Science (n.d.). 2: Describing data, part 1. STAT 200: Elementary statistics. Department of Statistics, PennState Elberly College of Science. https://online.stat.psu.edu/stat200/lesson/2/2.1/2.1.3/2.1.3.2/2.1.3.2.4

Foster, J. (n.d.). Multiplication rule for calculating probabilities. Statistics By Jim. https://statisticsbyjim.com/probability/multiplication-rule-calculating-probabilities/

Illowsky, B., Dean, S., Birmajer, D., Blount, B., Einsohn, M., Helmreich, J., Kenyon, L., Lee, S., & Taub J. (2020, March 27) 1.1 Definitions of statistics, probability, and key terms. Statistics. OpenStax. https://openstax.org/books/statistics/pages/preface

Master Traditional Games (n.d.) The rules of Blackjack, Master of the Games. https://www.mastersofgames.com/rules/blackjack-rules.htm?srsltid=AfmBOoojETz5j0oD9X_OW-mIYhepbOfCZm3sH6Z4o2klRDmMLHYO6s5m

Russell, S. & Norvig, P. (2021). 12.2 Basic probability notation. Artificial intelligence: A modern approach. 4th edition. Pearson Education, Inc. ISBN: 9780134610993; eISBN: 9780134671932.

Originally published at Alex.omegapy on Medium by Level UP Coding on November 29, 2024

Taxonomy and Frames in Programming Languages: A Hierarchical Approach to Knowledge Representation

Alex Ricciardi — Mon, 27 Jan 2025 04:51:16 +0000

This article examines the application of taxonomy and frames in programming languages, focusing on Python and Java. It demonstrates how hierarchical taxonomies and frame-based representations organize and define relationships, properties, and attributes, providing a comprehensive approach to knowledge representation in computer science.

Taxonomy in computer science is the act of classifying and organizing concepts. For example, in software engineering, it is used to classify software testing techniques, model-based testing approaches, and static code analysis tools (Novak et al., 2010). In data management, it is used to organize metadata and categorize-manage data assets (Knight, 2021). In Artificial Intelligence it is used to guide models to recognize patterns in data sets.

Taxonomy can also be defined as the act of organizing knowledge within a domain by using a controlled vocabulary to make it easier to find related information (Knight, 2021), and it must:

“Follow a hierarchic format and provide names for each object in relation to other objects.
May also capture the membership properties of each object in relation to other objects.
Have specific rules used to classify or categorize any object in a domain. These rules must be complete, consistent, and unambiguous.
Apply rigor in specification, ensuring any newly discovered object must fit into one and only one category or object. -Inherit all the properties of the class above it but can also have additional properties.”

(Knight, 2021, p.1).

In this paper, taxonomic knowledge and frames are implemented in the domain of Programming Languages, focusing on Python. “A frame is a data structure that can represent the knowledge in a semantic net” (Colorado State University Global, n.d., p.2). To implement the taxonomic knowledge the paper follows three steps using first-order logic. The steps are Subset Information, Set Membership of Entities, and Properties of Sets and Entities. Then, the paper uses a tree-like structure to show how subcategories relate to parent categories. Additionally, it demonstrates how the hierarchical taxonomic structure interacts with frames, by illustrating how attributes and properties are defined in the Python frame and they align with the broader taxonomic categories. Finally, it explains how the combination of taxonomic relationships and frames provides a comprehensive representation of knowledge.

The Three Steps to Implement Taxonomic Knowledge

Note that the programming languages Java and Python are used as examples.

— Step 1: Subset Information

In this step to represent the subcategory, first-order logic is used.

1. Subcategory Relationships:

Compiled Languages and Interpreted Languages:
∀x High_Level_Compiled_Language(x) ⇒ Compiled_Language(x)
∀x Scripting_Language(x) ⇒ Interpreted_Language(x)

Programming Languages:
∀x Compiled_Language(x) ⇒ Programming_Language(x)
∀x Interpreted_Language(x) ⇒ Programming_Language(x)

Specific Languages:
∀x Java(x) ⇒ High_Level_Compiled_Language(x)
∀x Python(x) ⇒ Scripting_Language(x)

2. Additional Subcategories:

Functional Languages and Logic Programming Languages:
∀x Functional_Language(x) ⇒ Programming_Language(x)
∀x Logic_Programming_Language(x) ⇒ Programming_Language(x)

— Step 2: Set Membership of Entities

In this step, the category membership of specific languages is represented.

Instances of Programming Languages:

Java SE 23:

Java(JavaSE23)

Python 3.13:

Python(Python3_13)

Other Programming Languages (more examples):

C(C23)

Haskell(Haskell2010)

— Step 3: Properties of Sets and Entities
In this step, the properties of the categories and language program are represented.

1. Properties of Programming Languages:

All Programming Languages have Syntax and are used for Software Development:
∀x Programming_Language(x) ⇒ Has_Syntax(x)
∀x Programming_Language(x) ⇒ Used_For(x,”Software_Development”)

2. Properties of Compiled and Interpreted Languages:

Compiled Languages have Execution Model ‘Compiled’:
∀x Compiled_Language(x) ⇒ Execution_Model(x,”Compiled”)

Interpreted Languages have Execution Model ‘Interpreted’:
∀x Interpreted_Language(x) ⇒ Execution_Model(x,”Interpreted”)

4. Properties of Specific Languages:

Java has Static Typing Discipline:
∀x Java(x) ⇒ Typing_Discipline(x,”Static”)

Python has Dynamic Typing Discipline:
∀x Python(x) ⇒ Typing_Discipline(x,”Dynamic”)

Java Supports Paradigm ‘Object-Oriented’:
∀x Java(x) ⇒ Supports_Paradigm(x,”Object-Oriented”)

Python Supports Multiple Paradigms:
∀x Python(x) ⇒ Supports_Paradigm(x,”Multi-Paradigm”)

3.Properties of Entities:

Java SE 23’s Latest Version is 23:

Latest_Version(JavaSE23,”23")

Python 3.13’s Latest Version is 3.13:

Latest_Version(Python3_13,”3.13")

Hierarchical Taxonomy of Programming Languages

Below is a (text shorter version) tree-like hierarchical structure representing the relationships between different languages in the domain of programming languages:

— Programming Languages:

Compiled Language

High-Level Compiled Language
C
C++
Java
Rust

Low-Level Compiled Language
Assembly Language

Interpreted Language:

Scripting Language
Python
Ruby
Perl

Shell Scripting Language
Bash
PowerShell

Functional Language
Pure Functional Language
Haskell
Multi-Paradigm Functional Language
Scala
F#

Logic Programming Language

Prolog

Note that some languages, like Python and Java, can be considered both interpreted and compiled languages; however, for the scope of this exercise, they are categorized as interpreted and compiled languages, respectively.

Hierarchical Taxonomy Visualization

Figure 1
Hierarchical Taxonomy of Programming Languages

Figure 2
Python Frame

)
    Python
    Instance_Of: Scripting_Language;

    // Inherited properties and attributes
    Used_For: Software_Development
    Execution_Model: Interpreted
    Syntax: Easy_To_Use;

    // Properties and attributes specific to Python
    Creator: Guido van Rossum;
    First_Released: 1991;
    Typing_Discipline: Dynamic, Strong Typing;
    Paradigms: Object-Oriented, Imperative, Functional, Procedural, Reflective;
    License: Python Software Foundation License;
    Latest_Version: 3.13;
    Official_Website: www.python.org
)

Note: This is a frame representation of Python’s properties and attributes. An example of an attribute is ‘Instance_Of’ and of a property is ‘Scripting_Language’.

For comparison, below is a representation of the Java frame.

Figure 3
Java Frame

Java
    Instance_Of: High_Level_Compiled_Language;

    // Inherited properties and attributes
    Used_For: Software_Development
    Debugging: Friendly
    Execution_Model: Compiled

    // Properties and attributes specific to Java
    Creator: James Gosling;
    First_Released: 1995;
    Typing_Discipline: Static, Strong Typing;
    Paradigms: Object-Oriented, Class-based, Concurrent;
    License: GNU General Public License with Classpath Exception;
    Latest_Version: 23;
    Official_Website: www.oracle.com/java/

Note: This is a frame representation of Java’s properties and attributes.

A hierarchical taxonomy organizes entities into a tree-like structure. In the Programming Language hierarchical taxonomy, the root class (category representing the domain) or the first node of the tree-like structure is ‘Programming Language’, with all other nodes as subclasses (subcategories) that inherit directly or indirectly from the ‘Programming Language’ root class. These relationships can be described as “is an instance of.” For example, all subclasses show the relation “is an instance of” ‘Programming Language’ such as ‘High-level Compile Language’ “is an instance of” ‘Compile Language’ “is an instance of” ‘Programming Language,’ therefore ‘High-level Compile Language’ also shows the relationship “is an instance of” ‘Programming Language’. This relationship is defined by the concept of inheritance where a subclass inherits the properties and attributes of its parent class and grandparent classes. Note that a subclass can have more than one parent class.

For example, the parent class ‘Compiled_Language’ has a property ‘Execution_Model’ with the attribute ‘Complied’, the subclass ‘High_Level_Compiled_Language’ and all the languages that are children of it will inherit the property ‘Execution_Model’ with the attribute ‘Complied’.

This can be translated into first-order logic as follows:

A hierarchical taxonomy organizes entities into a tree-like structure. In the Programming Language hierarchical taxonomy, the root class (category representing the domain) or the first node of the tree-like structure is ‘Programming Language,’ with all other nodes as subclasses (subcategories) that inherit directly or indirectly from the ‘Programming Language’ root class. These relationships can be described as “is an instance of.” For example, all subclasses show the relation “is an instance of” ‘Programming Language’ such as ‘High-level Compile Language’ “is an instance of” ‘Compile Language’ “is an instance of” ‘Programming Language,’ therefore ‘High-level Compile Language’ also shows the relationship “is an instance of” ‘Programming Language’. This relationship is defined by the concept of inheritance where a subclass inherits the properties and attributes of its parent class and grandparent classes. Note that a subclass can have more than one parent class.

∀x High_Level_Compiled_Language(x) ⇒ Compiled_Language(x) ⇒ Execution_Model(x,”Compiled”)

Where ‘x’ is the instance of a programming language (e.g. Java SE 23) and ‘⇒’ implies.

When exploring the Python frame we can see that one of its attributes is ‘Instance_Of’ with the property ‘Scripting_Language,’ this shows that Python is a subclass of the ‘Scripting_Language’ class, therefore Python inherits all the properties and attributes from ‘Scripting_Language’ which are ‘Syntax: Easy_To_Use’, ‘Execution_Model: Interpreted’, and ‘Used_For: Software_Development’. Additionally, the ‘Syntax: Easy_To_Use’ is specific to ‘Scripting_Language.’ On the other hand, ‘Execution_Model: Interpreted’ and ‘Used_For: Software_Development’ are inherited by ‘Scripting_Language’ from ‘Interprated_Language.’ Furthermore, ‘Execution_Model: Interpreted’ is specific to ‘Interprated_Language’ which inherits ‘Used_For: Software_Development’ from ‘Promming_Language.’

This can be translated into first-order logic as follows:

∀x Python(x) ⇒ Scripting_Language(x) ⇒ Syntax(x,Easy_To_Use)
∀x Python(x) ⇒ Scripting_Language(x) ⇒ Interprated_Language(x) ⇒ Execution_Model(x,Interpreted)
∀x Python(x) ⇒ Scripting_Language(x) ⇒ Interprated_Language(x) ⇒ Promming_Language ⇒ Used_For(x,Software_Development)

Where ‘x’ is the instance of a programming language (e.g. Python 3.13) and ‘⇒’ implies.

The rest of Python’s properties and attributes are specific to it.

On a side note, in polymorphism, a subclass can modify (override) the attribute’s value of a property inherited from a parent class. For example, a language could inherit ‘Syntax: Easy_To_Use’ from ‘Scripting_Language’ and modify the attribute ‘Easy_To_Use’ to ‘Hard_To_Use.’

Frame and Hierarchical Taxonomy Interactions Visualization

This section illustrates visually, the interactions between the hierarchical taxonomy and the Java and Python frames.

Figure 4
Frame and Hierarchical Taxonomy Interactions (Java and Python)

Note: The diagram illustrates the interactions between the hierarchical taxonomy and the Java and Python frames. Only the specific properties and attributes of the subclasses are listed in their node containers as the inherited properties and attributes can be listed in their parent class containers nodes. Data adapted from multiple sources: (Epözdemir, 2024; Foster, 2013; Gómez, n.d.; Peter Van Roy, 2008; Saxena, 2024; Startups, 2018; & Wikipedia contributors, 2024)

As shown in Figure 4, combining hierarchical taxonomic relationships and frames creates a powerful tool for representing knowledge. The hierarchical taxonomy illustrated the relationships between categories; for example, the ‘Scripting Language’ category is a subcategory of the ‘Interpreted Language’ which is a subcategory of the ‘Programming Language’ category making the ‘Scripting Language’ a sub-subcategory of the root category ‘Programming Language’ which represents the domain. Additionally, the implementation of frames into the diagram shows the entities’ properties and attributes and how they get inherited from another category. For example, Python’s specific properties and attributes are listed in its node containers, and its inherited properties and attributes are listed in its parent, grandparent, and great-grandparent class node containers. This creates a robust representation of knowledge that provides depth and clarity allowing users to navigate complex relationships effortlessly.

References:

Colorado State University Global. (n.d.). Module 4: Knowledge Representation [Interactive lecture]. Canvas. Retrieved November 1, 2024, from https://csuglobal.instructure.com/courses/100844/pages/4-dot-2-frames?module_item_id=5183634

Epözdemir, J. (2024, April 10). Programming Language Categories. Medium. https://medium.com/@jepozdemir/programming-language-categories-6b786d70e8f7

Foster, D. (2013, February 20). Visual Guide to Programming Language Properties. DaFoster. https://dafoster.net/articles/2013/02/20/visual-guide-to-programming-language-properties/

Gómez, R. (n.d.). Alphabetical List of Programming Languages • programminglanguages.info. https://programminglanguages.info/languages/

Knight, M. (2021, March 12). What Is Taxonomy? Dataversity. https://www.dataversity.net/what-is-taxonomy/

Novak, J., Krajnc, A., & Žontar, R. (2010, May 1).Taxonomy of static code analysis tools. IEEE Conference Publication | IEEE Xplore. https://ieeexplore.ieee.org/document/5533417

Peter Van Roy. (2008). The principal programming paradigms. https://webperso.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.pdf

Saxena, C. (2024, October 17). Top Programming Languages 2025: By Type and Comparison. ISHIR | Software Development India. https://www.ishir.com/blog/36749/top-75-programming-languages-in-2021-comparison-and-by-type.htm

Startups, A. (2018, June 20). Choosing the Right Programming Language for Your Startup. Medium. https://medium.com/aws-activate-startup-blog/choosing-the-right-programming-language-for-your-startup-b454be3ed5e2

Wikipedia contributors. (2024, November 3). List of programming languages by type. Wikipedia. https://en.wikipedia.org/wiki/List_of_programming_languages_by_type

Originally published at Alex.omegapy on Medium by Codex on November 28, 2024.

Minimizing Variable Scope in Java: Best Practices for Secure and Efficient Code

Alex Ricciardi — Mon, 27 Jan 2025 03:37:01 +0000

This article explains the importance of minimizing variable scope in Java to enhance code readability, maintainability, and security. It highlights Java’s object-oriented approach, contrasts it with languages like C++, and provides examples of best practices, including encapsulation and controlled access through methods.

In Java, the scope of a variable is the part of a program where the variable can be accessed (Mahrsee, 2024). The scope can be a Class scope, method scope, or block scope. Java does not have global variables like C++ does; global variables are variables that can be accessed from anywhere in the program. In other words, the variables have a global scope.

Java inherently minimizes scope by encapsulating everything in classes. Java is a strictly object-oriented programming (OOP) language rather than a procedural one like C. On the other hand, C++ supports both paradigms, OPP and procedural programming. Anyhow, scope minimization is an approach with the goal of improved readability, better maintainability, and reduced chance of errors (Carter, 2021). DCL53-J. SEI CERT Oracle Coding Standard for Java (CMU, n.d.) recommends minimizing the scope of variables to: “avoid common programming errors, improves code readability by connecting the declaration and actual use of a variable, and improves maintainability because unused variables are more easily detected and removed. It may also allow objects to be recovered by the garbage collector more quickly, and it prevents violations of DCL51-J. Do not shadow or obscure identifiers in subscopes.“

Minimizing the scope of a variable also adds a layer of security, as the variable is restricted to the context where it is needed. This reduces access, manipulation, or misuse by other parts of the program, limiting possible vulnerabilities. For example, in Java, declaring a class variable ‘private’ would restrict its scope within the class, preventing other classes from directly modifying or accessing it. However, if the variable needs to be accessed or modified, it can only be done through controlled methods, such as getters or setters, which encapsulate the variable or return a copy of it; additionally, they can implement an extra layer or validation or logic that ensures that the variable is properly utilized.

Below is an example of how to apply scope minimization in Java can look like:

public class Employee {
    // Private class variables to restrict access
    private String name;
    private double salary;

    // Constructor
    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    // Getter for name (read-only access)
    public String getName() {
        return name;
    }

    // Getter and setter for salary with validation
    public double getSalary() {
        return salary;
    }

    public void setSalary(double salary) {
        if (salary > 0) {
            this.salary = salary; 
        } else {
            throw new IllegalArgumentException("Salary must be greater than 0.");
        }
    }

    // Method to provide an increment with controlled logic
    public void applyBonus(double percentage) {
        if (percentage > 0 && percentage <= 20) {
            this.salary += this.salary * (percentage / 100);
        } else {
            throw new IllegalArgumentException("Bonus percentage must be between 0 and 20.");
        }
    }

    // Display employee details
    public void printDetails() {
        System.out.println("Name: " + name);
        System.out.println("Salary: $" + salary);
    }
}

public class Main {
    public static void main(String[] args) {

         // Create an Employee object
        Employee emp = new Employee("Alice", 50000);
        System.out.println("Initial Salary:");
        emp.printDetails();

        // Modify Salary
        emp.setSalary(55000); 
        emp.applyBonus(10);     
        System.out.println("\nUpdated Salary:");
        emp.printDetails();

        // Attempting to set an invalid salary
        System.out.println("\nInvalid salary (-10000):");
        try {
            emp.setSalary(-10000);
        } catch (IllegalArgumentException e) {
            System.out.println(e.getMessage());
        }
    }

Outputs:

Name: Alice
Salary: $50000.0

Updated Salary:
Name: Alice
Salary: $60500.0

Invalid salary (-10000):
Salary must be greater than 0.

To summarize, minimizing variable scope in Java code improves code readability, maintainability, and security by restricting access to where variables are needed most. Java is strictly object-oriented programming (OOP) language implying that it encapsulates data and variables within classes. This approach not only prevents unintended interactions and vulnerabilities but also aligns with best practices for efficient and secure programming.

References:

Carter, K. (2021, February 10). Effective Java: Minimize The Scope of Local Variables. DEV Community. https://dev.to/kylec32/effective-java-minimize-the-scope-of-local-variables-3e87

CMU — Software Engineering Institute (n.d.) DCL53-J. Minimize the scope of variables.
SEI CERT Oracle coding standard for Java. Carnegie Mellon University. Software Engineering Institute.

Mahrsee, R. (2024, May 13). Scope of variables in Java. GeeksforGeeks. https://www.geeksforgeeks.org/variable-scope-in-java/

Originally published at Alex.omegapy on Medium by Level UP Coding on November 22, 2024.

Searching vs. Sorting in Java: Key Differences and Applications

Alex Ricciardi — Thu, 16 Jan 2025 01:58:18 +0000

This article describes the differences between searching and sorting algorithms in Java, their distinct purposes, methodologies, and time complexities. It includes practical examples and implementations, such as Merge Sort for organizing data and Binary Search for efficient retrieval, demonstrating their roles in solving real-world problems.

In Java, understanding searching and sorting algorithms and how they differ from each other, is crucial for the correct functionality of the application and for effectively managing data. While searching focuses on locating specific data within a collection, sorting rearranges data. This article explores their differences in purpose, methodology, and applications, by providing examples.

The major differences between searching and sorting in Java lie in their purposes and outputs, as well as their efficiencies and time complexities. Please Table 1 for a detailed comparison.

Table 1
Searching vs Sorting in Java

Choosing between different searching or sorting algorithms often depends on the purpose or output wanted and the specific requirements of your application, such as the size of the dataset, and whether the data is already sorted.

The following table, Table 2, gives examples of pseudocode and time complexity for several searches and sort algorithms:

Table 2
Runtime Complexities for Various Pseudocode Examples

Note: In Java without using the Comparable Interface the code above would only be viable for primitive types. From Programming in Java with ZyLabs, 18.3 O notation, Figure 18.3.2 by Lysecky, R., & Lizarraga, A. (2022).

An example of a sort algorithm is the merge sort, which has the divide-and-conquer approach, it recursively divides a data array into smaller subarrays and sorts those subarrays, then merges the subarrays together to create a sorted array (GeeksforGeeks, 2020a).An example of a search algorithm is the binary search; which operates on a pre-sorted array by repeatedly dividing the search interval in half until the target element is found or determined to be absent (GeeksforGeeks, 2020b).

The example below sorts using merge sort an ArrayList of book objects by year of publication then searches the sorted list using binary:
Book.java

/**
 * Book object with a title and publication year. This class implements
 * Comparable to allow sorting based on the publication year.
 * 
 * @author Alexander Ricciardi
 * @version 1.0
 * @date 07/14/2024
 */
class Book implements Comparable {
    String title;
    int year;

    /**
     * Constructs a new Book object.
     *
     * @param title The title of the book.
     * @param year  The year the book was published.
     */
    public Book(String title, int year) {
    this.title = title;
    this.year = year;
    }

    /**
     * Compares this book with another book based on the publication year.
     *
     * @param other The book to compare with.
     * @return A negative integer, zero, or a positive integer as this book is less
     *         than, equal to, or greater than the specified book.
     */
    @Override
    public int compareTo(Book other) {
    return Integer.compare(this.year, other.year);
    }

    /**
     * Returns a string representation of the book.
     *
     * @return A string in the format "title (year)".
     */
    @Override
    public String toString() {
    return title + " (" + year + ")";
    }
}

BookSortingSearching.java

import java.util.ArrayList;
import java.util.Arrays;
import java.util.Scanner;

/**
 * Sorts and search a list of books. It implements merge sort for sorting and
 * binary search for searching.
 * 
 * @author Alexander Ricciardi
 * @version 1.0
 * @date 07/14/2024
 */
public class BookSortingSearching {

    /**
     * The main method that demonstrates sorting and searching on a list of books.
     *
     * @param args Command line arguments (not used).
     */
    public static void main(String[] args) {
    // Initialize the list of books
    ArrayList books = new ArrayList<>(
        Arrays.asList(
                     new Book("To Kill a Mockingbird", 1960), 
                     new Book("1984", 1949),
                     new Book("The Great Gatsby", 1925),
                     new Book("One Hundred Years of Solitude", 1967),
                     new Book("The Catcher in the Rye", 1951), 
                     new Book("Brave New World", 1932),
                     new Book("The Hobbit", 1937), 
                     new Book("The Lord of the Rings", 1954),
                     new Book("Pride and Prejudice", 1813), 
                     new Book("Animal Farm", 1945)
                 ));

    // Print the original list
    System.out.println("Original list:");
    books.forEach(System.out::println);

    // Sort the books using merge sort
    mergeSort(books, 0, books.size() - 1);

    // Print the sorted list
    System.out.println("\nSorted list by year:");
    books.forEach(System.out::println);

    // Perform binary search based on user input
    Scanner scn = new Scanner(System.in);
    System.out.print("\nEnter a year to search for: ");
    int searchYear = scn.nextInt();

    int result = binarySearch(books, searchYear);
    if (result != -1) {
        System.out.println("Book found: " + books.get(result));
    } else {
        System.out.println("No book found for the year " + searchYear);
    }
    scn.close();
    }

    /**
     * Sorts the given list of books using the merge sort algorithm.
     *
     * @param books The list of books to sort.
     * @param left  The starting index of the subarray to sort.
     * @param right The ending index of the subarray to sort.
     */
    private static void mergeSort(ArrayList books, int left, int right) {
    if (left < right) {
        int mid = (left + right) / 2;
        mergeSort(books, left, mid); // Sort left half
        mergeSort(books, mid + 1, right); // Sort right half
        merge(books, left, mid, right); // Merge the sorted halves
    }
    }

    /**
     * Merges two sorted subarrays of the books list.
     *
     * @param books The list of books containing the subarrays to merge.
     * @param left  The starting index of the left subarray.
     * @param mid   The ending index of the left subarray.
     * @param right The ending index of the right subarray.
     */
    private static void merge(ArrayList books, int left, int mid, int right) {
    // Create temporary arrays
    ArrayList leftList = new ArrayList<>(books.subList(left, mid + 1));
    ArrayList rightList = new ArrayList<>(books.subList(mid + 1, right + 1));

    int i = 0, j = 0, k = left;

    // Merge the two lists
    while (i < leftList.size() && j < rightList.size()) {
        if (leftList.get(i).compareTo(rightList.get(j)) <= 0) {
        books.set(k++, leftList.get(i++));
        } else {
        books.set(k++, rightList.get(j++));
        }
    }

    // Copy remaining elements of leftList, if any
    while (i < leftList.size()) {
        books.set(k++, leftList.get(i++));
    }

    // Copy remaining elements of rightList, if any
    while (j < rightList.size()) {
        books.set(k++, rightList.get(j++));
    }
    }

    /**
     * Performs a binary search on the sorted list of books to find a book by its
     * publication year.
     *
     * @param books The sorted list of books to search.
     * @param year  The publication year to search for.
     * @return The index of the book if found, -1 otherwise.
     */
    private static int binarySearch(ArrayList books, int year) {
    int left = 0, right = books.size() - 1;
    while (left <= right) {
        int mid = left + (right - left) / 2;
        if (books.get(mid).year == year) {
        return mid; // Book found
        }
        if (books.get(mid).year < year) {
        left = mid + 1; // Search in the right half
        } else {
        right = mid - 1; // Search in the left half
        }
    }
    return -1; // Book not found
    }
}

Output:

To Kill a Mockingbird (1960)
1984 (1949)
The Great Gatsby (1925)
One Hundred Years of Solitude (1967)
The Catcher in the Rye (1951)
Brave New World (1932)
The Hobbit (1937)
The Lord of the Rings (1954)
Pride and Prejudice (1813)
Animal Farm (1945)

Sorted list by year:
Pride and Prejudice (1813)
The Great Gatsby (1925)
Brave New World (1932)
The Hobbit (1937)
Animal Farm (1945)
1984 (1949)
The Catcher in the Rye (1951)
The Lord of the Rings (1954)
To Kill a Mockingbird (1960)
One Hundred Years of Solitude (1967)

Enter a year to search for: 1951
Book found: The Catcher in the Rye (1951)

In other words, merge sort is efficient for sorting large sets of data due to its complexity of O(n log(n)), while binary search with its targeted approach to search is better suited for machine learning applications, such as those for training neural networks or finding the optimal hyperparameters for a model.

In summary, searching and sorting algorithms have interconnected roles in programming but serve different purposes. Sorting algorithms like Merge Sort organize the data, allowing searching methods such as Binary Search to be more efficient. Together, these algorithms are indispensable for solving real-world problems, from data analysis to application development.

References:

GeeksforGeeks. (2020a, November 18). Merge sort. GeeksforGeeks https://www.geeksforgeeks.org/merge-sort/

GeeksforGeeks. (2020b, February 3). Binary search. GeeksforGeeks. https://www.geeksforgeeks.org/binary-search/

Lysecky, R., & Lizarraga, A. (2022)._ Programming in Java with ZyLabs_[ Table]. Zyante, Inc.

Originally published at Alex.omegapy on Medium by Level UP Coding on November 22, 2024.

Bayes’ Theorem: Risk Prediction and AI in The Insurance Sector

Alex Ricciardi — Thu, 16 Jan 2025 01:48:26 +0000

The article explains Bayes’ Theorem as a mathematical formula used to update probabilities based on new evidence, illustrating its applications in risk prediction for insurance companies. It highlights the theorem’s integration into AI systems to enhance decision-making while addressing potential biases, privacy, and security concerns.

In probability theory, Bayes’ Theorem, also known as Bayes’ Rule or Bayes’ Law, is a mathematical formula that updates the probability of a hypothesis based on new evidence. In statistics, it is a way to revise or update existing predictions or theories based on new or additional evidence (Hayes, 2024), In other words, it is a mathematical formula for determining conditional probability. A conditional probability is the likelihood of an outcome occurring based on a previous outcome that occurred under similar circumstances. Thus, Bayes’ Theorem can also be defined as a mathematical property that allows conditional probability to be expressed in terms of the inverse of the conditional (Data Science Discovery, n.d.).

The Bayes’ Theorem formula:

Where:

P(A) is the prior probability of an event A.
P(B) is the probability of an event B.
P(B|A) is the probability of an event B occurring given that A has occurred.
P(A|B) is the probability of an event A occurring given that B has occurred.

Therefore, the Bayes’ Theorem computes the reverse of the conditional probability. That is the probability of a cause A given an effect B, P(A|B), when the overall probability of the cause, P(A), the probability of the effect, P(B), and the probability of the effect occurring given that the cause has occurred, P(B|A) are known.

Note:
P(B) = P(B∣A) P(A) + P(B∣¬A) P(¬A)

Where:

P(B∣¬A) — the probability of event B occurring given that ¬A event has occurred
P(B∣A) — the probability of event B occurring given that A event has occurred

(Taylor, 2023)

Another way to formulate Bayes’ Theorem is to base it on a hypothesis context:

Where:

H: The hypothesis
(e.g., a person has a certain disease)
E: Evidence
(e.g., the person tests positive in a diagnostic test)
P(H): Prior probability is the known probability about the hypothesis or the initial belief about the hypothesis, that is the beliefs before observing the evidence.
(e.g., the probability someone has a specific disease before considering specific symptoms or test results)
P(E): Marginal probability is the probability of observing the evidence under all possible scenarios. It may be thought of as an unconditional probability, or it is not conditioned on another event (Albright, n.d.).
P(E) = P(E∣H) P(H) + P(E∣¬H) P(¬H)
(e.g., the probability that a diagnostic test would show a positive result, whether or not the person actually has the disease).
P(E∣H): Likelihood is the probability of observing the evidence.
(e.g., a positive test result) given that the hypothesis is true. In other words, it is the likelihood of E being true based on H being true.
(e.g., the likelihood of a positive test result being accurate, knowing that the person has the disease; note that medical tests are not 100% accurate, false positive)
On the other hand, P(H∣E) is the likelihood of H being true based on E being true.
P(H∣E): The posterior probability is the updated probability of the hypothesis given the observed evidence.
(e.g., the probability that the person actually has the disease, given that they tested positive)

The formulated Bayes’ Theorem above can be used to assess risks by calculating the likelihood of an event, such as accidents, illnesses, or natural disasters. This information is very valuable for an insurance company, enabling it to better understand and predict potential risks.

The steps below describe how the theorem can be applied to predict the risk of a person developing a disease:

1 - Prior Knowledge:
Establish the disease hypothesis, such as the probability someone has a specific disease before considering specific symptoms or test results, then collect relevant data and compute the prior probability P(H) from it.

For example:
If 5 in 1,000 people in the general population have the disease, therefore the prior is 0.005.
P(H) = 0.005

2 - Incorporate the Evidence:
Incorporate evidence such as a positive result from a diagnostic test. That is the Likelihood, P(E∣H). That is the likelihood of a positive test result being accurate, knowing that the person has the disease.

For example:
The test is accurate 96% of the time.
P(E∣H) = 0.96

3 - Account for False Positives:
Compute The marginal probability P(E). That is the probability that a diagnostic test would show a positive result, whether or not the person actually has the disease.

True Positives P(E∣H)P(H), the test correctly identifies the disease.
False Positives P(E∣¬H)P(¬H), the test incorrectly identifies the disease. Then P(E) = P(E∣H) P(H) + P(E∣¬H) P(¬H)

For example:
P(E∣¬H) = 0.04 (4% false positive rate)
P(¬H) = 1 − P(H) =0.995
P(¬H) = 0.995.

P(E) = P(E∣H) P(H) +P(E∣¬H) P(¬H) = (0.96)( 0.005) +( 0.04)(0.995)
P(E)= 0.0048 + 0.0398 = 0.0446
P(E) = 0.0446

4 - Compute the Posterior:
Use Bayes’ Theorem to update the probability based on the evidence. That is the probability that the person actually has the disease, given that they tested positive.

For example:

P(H∣E) ≈ 0.1076

Thus, even though the test is 96% accurate the posterior probability P(H∣E) is equal to 10.76%. This is due to P(H) being only 0.5% (5 in 1,000 people in the general population have the disease). In other words, a person having a positive test result increases the person’s probability of having the disease from 0.5% to about 10.76%; however, it is still more likely that the person does not have the disease. For the insurance, it means that it needs to consider both test accuracy, P(E∣H) = 0.96, and disease prevalence, P(H), to not overestimate risks, as risks are low even with a positive test, and to set insurance premiums that represent a fair and accurate assessment of the probability of a person having the diseases.

As shown from the example above, the Bayes’ Theorem is a powerful tool that provides more accurate predictions than solely relying on simple probabilities or data alone.

An Artificial Intelligence (AI) Bayes’ Theorem implementation can transform and enhance the insurance company’s decision-making processes by providing:

More accurate predictions of risks, such as accidents, illnesses, or natural disasters real-time data processing.
More personalized and refined prediction-based individual-level data.
By analyzing vast amounts of data.- By automating systems streamlining claims processing and fraud detection.

However, a Bayes’ Theorem AI may invertedly create biases. Additionally, by using vast personal and private amounts of data such as medical history and financial information the AI system introduces privacy and security concerns, as well as data regulatory compliance challenges. These potential issues need to be carefully considered when using such systems.

To summarize, Bayes’ Theorem is a mathematical formula that updates the probability of a hypothesis based on new evidence providing a way to incorporate prior knowledge and observed data in real time into predictions. It is a powerful tool that provides more accurate predictions than solely relying on simple probabilities or data alone and when implemented in an AI model can transform and enhance the insurance company’s decision-making processes.

References:

Albright, E. (n.d.). Probability: Joint, marginal and conditional probabilities. ENV710 Statistics Review. Nicholas School of the Environment | Duke University. https://sites.nicholas.duke.edu/statsreview/jmc/

Data Science Discovery (n.d.). Bayes’ theorem. University of Illinois at Urbana-Champaign (UIUC). https://discovery.cs.illinois.edu/learn/Prediction-and-Probability/Bayes-Theorem/

Hayes, A. (2024, March 30)._ Bayes’ theorem: What it is, the formula, and examples_. Investopedia. https://www.investopedia.com/terms/b/bayes-theorem.asp

Taylor, S. (2023, November 21). Bayes’ Theorem. Corporate Finance Institute. https://corporatefinanceinstitute.com/resources/data-science/bayes-theorem/

Originally published at Alex.omegapy on Medium by CodeX on November 14, 2024.