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

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

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

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

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

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

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

This article explores the technology of Wi-Fi, detailing its evolution, relationship to other wireless technologies, and inherent security vulnerabilities. It provides an overview of common Wi-Fi security risks, solutions, and various authentication protocols, emphasizing the importance of proactive security measures for safe and reliable wireless network usage. Alexander S. Ricciardi January 9, 2025 In recent decades, wireless technology has infiltrated every aspect of daily life, becoming an integral part of how most of us communicate, access information, work, and interact with the world. Wireless technology refers to any technology that enables communication or data transfer without the use of wires or cables (Hasons, 2024). This post explores the widely used wireless technology Wi-Fi, how it relates to other wireless technologies, the challenges and security concerns associated with it, and how to address them. Type of Wireless Technologies and How They Relate to Wi-Fi Wireless technologies enable telecommunication, that is the transfer of information between two or more devices without the use of physical media such as wires and optical fiber. The five main types of wireless technology commonly used to transfer data today are cellular networks for mobile communication, Bluetooth for short-range device connection, satellite communication for broad coverage, and Wi-Fi for local area networking. All these technologies use radio waves instead of other electromagnetic signals such as infrared light used by remote controls or visible light used for Li-Fi as radio waves allow for longer ranges and better penetration through obstacles such as walls.  Wi-Fi is the most used telecommunication technology within Wireless Local Area Networks (WLAN). It uses specific radio frequencies (2.4GHz, 5GHz, and 6GHz) and has protocols optimized for creating local area networks. In other words, it can provide internet access locally (within a limited range) making it ideal for homes, offices, and public spaces. Wi-Fi has evolved and continues to evolve by increasing data rates and bandwidth. The table below shows the different Wi-Fi standards and how they have evolved.  Table 1 Wi-Fi Standards Note: data from “The Evolution of Wi-Fi Networks: From IEEE 802.11 to Wi-Fi 6E” By Links (2022). On a side note, Li-Fi is a relatively new technology, it is “bidirectional wireless system that transmits data via LED or infrared light. It was first unveiled in 2011” (Iberdrola, n.d., p. 1). Li-Fi is cheaper, faster, and has a larger data volume capacity than Wi-Fi. However, it cannot communicate through walls or other opaque materials as Wi-Fi does, because it relies on visible or infrared light instead of radio waves.   Wi-Fi Security Concerns Wireless networks have many advantages such as eliminating the need for physical cables (low installation cost), allowing greater flexibility in device placement, and providing mobility to users. However, unlike wired networks, where access is physically restricted by cables, in wireless networks electromagnetic signals such as radio waves can be intercepted by anyone within range using a compatible wireless device. Networks using Wi-Fi technology are practically vulnerable to unauthorized access (rogue access points), data interception (eavesdropping), Denial of Service (DoS) attacks, and malware. The table below illustrates the most common Wi-Fi risks and solutions Table 2 Wi-Fi Security Risk and Solutions Note: data from “Exploring Common Wi-Fi attacks: A deep dive into wireless network vulnerabilities” by ITU (2024) and “Introduction to Wireless Networks” by Grigorik (2016).  Wi-Fi Security Protocols As shown in Table 2, Wi-Fi networks are vulnerable to attacks if not secured properly. The IEEE 802.11 Wi-Fi standard provides various types of authentication protocols. Thus, it is essential to understand the difference between them to choose the right one that meets the security needs of specific wireless networks. For example, the WPA3 protocol offers the strongest security but requires new and expensive hardware. WPA2 provides AES encryption, it is the most recommended access protocol for users as it provides compatibility between older and newer security devices. The table below provides a description of the different main authentication protocols associated with the Wi-Fi standard, as well as their strengths, and weaknesses. Table 3  Wi-Fi Security Access Protocols Note: data from various sources (Freda, 2022; Raphaely, n.d.; Basan, 2024; AscentOptics, 2024). Not only is it important to understand the difference between the different Wi-Fi security protocols, it is also essential to keep informed about the latest security vulnerabilities and updates. For instance, at the beginning of 2024, a new Wi-Fi vulnerability was discovered by researchers (Migliano). The CVE-2023-52424 vulnerability affects all operating systems, it is categorized as a Service Set Identifier (SSID) Confusion attack, where Wi-Fi clients can be tricked to connect to an untrusted network. The table below describes what type of network and authentication are vulnerable to CVE-2023-52424. Table 4 Types of Wi-Fi Networks Vulnerable to SSID Confusion Attacks Note: from “New WiFi vulnerability explained: Protecting against SSID confusion attacks” by Migliano (2024). To defend against this new vulnerability the 802.11 Wi-Fi standard needs to be updated to incorporate the SSID as part of the 4-way handshake when connecting to protected networks, and the beacon protection needs to be improved to allow a client to store a reference beacon containing the network's SSID to verify its authenticity during the 4-way handshake (Lakshmanan, 2024). In conclusion, since wireless technology, more specifically the Wi-Fi standard, has become an indispensable part of modern life, it is important to understand the associated security risks, their solutions, and the authentication protocols used to secure Wi-Fi and other wireless networks. Ultimately, prioritizing security by proactively addressing wireless network vulnerabilities is essential for the safe use of this indispensable technology. References: AscentOptics. (2024, January 9). WEP, WPA, WPA2, WPA3: Classifying and comparing wireless protocols. AscentOptics Blog. https://ascentoptics.com/blog/wep-wpa-wpa2-wpa3-classifying-and-comparing-wireless-protocols/ Basan, M. (2024, April 29). Wireless Network Security: WEP, WPA, WPA2 & WPA3 Explained . eSecurity Planet. https://www.esecurityplanet.com/trends/the-best-security-for-wireless-networks/ Freda, A. (2022, February 14). WEP, WPA, or WPA2 — Which Wi-Fi security protocol is best? . AVG. https://www.avg.com/en/signal/wep-wpa-or-wpa2 Grigorik, I. (2016, April 27). Introduction to wireless networks. High Performance Browser Networking. https://hpbn.co/introduction-to-wireless-networks/ Hasons (2024, February 26). Wireless Technology – What is Wireless Technology? Hasons. https://hasonss.com/blogs/wireless-technology/ Iberdrola (n.d.). What is LiFi technology? LiFi, the internet at the speed of light . Iberdrola Group. https://www.iberdrola.com/innovation/lifi-technology ITU (2024, February 7). Exploring Common Wi-Fi attacks: A deep dive into wireless network vulnerabilities.  ITU Online IT Training. https://www.ituonline.com/blogs/common-wi-fi-attacks/ Lakshmanan, R. (2024, May 16). New Wi-Fi vulnerability enables network eavesdropping via downgrade attacks. The Hacker News. https://thehackernews.com/2024/05/new-wi-fi-vulnerability-enabling.html Links, C. (2022, May 19). The Evolution of Wi-Fi networks: from IEEE 802.11 to Wi-Fi 6E. Wevolver. https://www.wevolver.com/article/the-evolution-of-wi-fi-networks-from-ieee-80211-to-wi-fi-6e Migliano, S. (2024, May 14). New WiFi vulnerability explained: Protecting against SSID confusion attacks. https://www.top10vpn.com/research/wifi-vulnerability-ssid/?utm_source Raphaely, E. (n.d.). A complete guide to wireless (Wi-Fi) security. SecureW2. https://www.securew2.com/blog/complete-guide-wi-fi-security

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. Alexander S. Ricciardi January 1, 2025 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 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. It 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

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. Alexander S. Ricciardi December 19, 2024 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 strengthen 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 Scannin g. 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

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. Alexander S. Ricciardi December 17, 2024 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 Note: From “Software Projects and Modeling Spaces: Package Diagrams. Software Engineering with UML,” Figure 3.3, by Unhelkar (2018 b). 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 that the 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 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

This article explains how texture mapping in computer graphics applies 2D images to 3D models. It also discusses advanced techniques like environment and bump mapping, which improve surface detail using minimal computational resources. Alexander S. Ricciardi September 25, 2024 In computer graphics, texture mapping is a technique used to apply 2D images to the surface of 3D models. This technique allows the addition of complex patterns, detailed color schemes, and surface characteristics to 3D models’ surfaces without the overhead of implementing complex geometric to mimic intricate surfaces. Therefore, reducing computational cost while still enhancing the visual detail of objects and realism in scenes. On a side note, a similar technique is applying 3D textures onto 3D models; this technique is usually referred to as volume texturing; which could also be called texture mapping. However, the main difference between the two techniques is that 2D texture mapping applies flat images onto the surface of a 3D model, see Figure 1, while 3D texture mapping applies volumetric textures (3D Textures) throughout the 3D space of the model. Figure 1 2D Textue Applied to a 3D Box Note: The Quaker cereal box is an illustration of how a 2D texture is applied to a 3D object When using APIs such as WebGL, texture mapping is applied in several steps, such as creating a texture object and binding it to the 3D model, loading the texture image, assigning coordinates to the texture object, and then applying it to the object or model. Below are examples of JavaScript and GLSL WebGL code that illustrate the steps mentioned above. Step-1 Creating and binding the texture object. The texture object is created and stored in the GPU memory. WebGL uses functions like gl.createTexture() and gl.bindTexture() to create and bind the texture object. JavaScript var texture = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, texture); Step-2 Loading the Texture Image. The image is loaded into RAM by storing it in an image object, usually, the image is a PNG or JPEG. Then the image data is transferred to the GPU memory. JavaScript var image = new Image(); image.src = 'texture.png'; gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image); Step-3 Assigning Texture Coordinates (UV Mapping). In this step, the vertexes of the 3D model are assigned the texture telling the renderer what part of the texture corresponds to each point on the object’s surface. The shape below is a quadrilateral JavaScript var texCoords = [ vec2(0, 0), // bottom-left corner vec2(0, 1),  // top-left corner vec2(1, 1), // top-right corner vec2(1, 0)  // bottom-right corner ]; Step-4 Applying the Texture. This step is done in the fragment shader. The texture is applied to the surface of the object based on the interpolated texture coordinates. GLSL uniform sampler2D uTextureMap; // sampler for a 2D texture, holds the // texture data in vec2 vTexCoord; // Input texture coordinates passed from the vertex shader // used to look up the color from the texture // The final color out vec4 fragColor; void main() {    /* samples the texture at vTexCoord and assigns the resulting color to fragColor. The texture() function fetches the color from the uTextureMap. */ fragColor = texture(uTextureMap, vTexCoord); } In a few lines of code, APIs such as WebGL allow programmers to implement texture mapping which enhances significantly the detail of object surfaces without the overhead of complex geometry. It enhances the realism of models by simulating details like wood grain, bricks, or fabric patterns with an image. For example, a plain, untextured cube would look flat, but the same cube with texture could appear to have detailed brick patterns, with color variations and even surface roughness. Additionally, texture mapping allows for advanced effects such as environment mapping simulating reflections on shiny surfaces like metal or water. “Highly reflective surfaces are characterized by specular reflections that mirror the environment. [...] We can, however, use variants of texture mapping that can give approximate results that are visually acceptable through environment maps or reflection maps” (Angle & Shreiner, 2020, p197). Note that environment mapping is a technique that converts 3D environment information into a 2D texture format Furthermore, bump mapping, a 2D mapping technique used to create the illusion of surface irregularities and roughness by altering the normal vectors of a surface during shading. It gives the illusion of depth and texture without modifying the geometry. Bump mapping will show changes in shading as the light source or object moves, making the object appear to have variations in surface smoothness by using a grayscale texture (a bump map) to adjust the surface normals during lighting calculations (Angle & Shreiner, 2020). To summarize, in computer graphics, texture mapping is a technique that enhances the visual realism of 3D objects by applying 2D images to their surfaces. Furthermore, advanced 2D texture mapping techniques like environment mapping and bump mapping allow for further intricate surface detail, all while keeping the computational costs low by avoiding additional geometric complexity. All of these can be achieved with just a few lines of code using abstraction layers provided by APIs such as WebGL. References: Angel, E., & Shreiner, D. (2020). Chapter 7: Texture mapping.  Interactive computer graphics. 8th edition . Pearson Education, Inc. ISBN: 9780135258262