Software Modeling and Design Concepts

Briefing Document: Software Modeling and Design Concepts

Date: 2023-10-27

Subject: Review of Key Concepts from "Software Modeling and Design" by Hassan Gomaa (2011)

Source: Excerpts from "Hassan Gomaa - Software Modeling and Design_ UML, Use Cases, Patterns, and Software Architectures-Cambridge University Press (2011).pdf"

This briefing document summarises the main themes and important ideas presented in the provided excerpts, focusing on software development life cycle models, UML extension mechanisms, object-oriented design principles, software architecture, concurrent design, and testing, with particular emphasis on the case studies presented (Banking System/ATM and Automated Guided Vehicle System).

📚 Other Resources:

🔍 What Are UML Extension Mechanisms? | Customize UML in Software Modeling and Design Learn how stereotypes, tagged values, and constraints help extend UML for specific domains.
🎯 Software Modeling and Design Fundamentals Understand the foundations of modeling in software engineering, including key UML diagrams and design principles.

Key Themes and Concepts:

1. Software Development Life Cycle Models: The excerpts discuss various models for managing the software development process.

• The Waterfall Model (Figures 3.1 and 3.2) is presented as a traditional, sequential process model with distinct phases: Requirements Analysis & Specification, Architectural Design, Detailed Design, Coding, Unit Testing, Integration Testing, System & Acceptance Testing. Figure 3.2 shows a variant with iteration between phases.
• The Spiral Model (Figure 3.7) is introduced as a risk-driven model designed to address issues with earlier models like the waterfall model. It is described as intended to "encompass other life cycle models, such as the waterfall model, the incremental development model, and the throwaway prototyping model." The four key steps in each cycle of the spiral model are: 1. Define objectives, alternatives, and constraints, 2. Analyze risks, 3. Develop product, 4. Plan next cycle.
• Throwaway Prototyping (Figure 3.4) is mentioned as a technique that can be used within a life cycle model, particularly for clarifying requirements when they are "not well understood". An example shows it being applied during architectural design.
• Incremental Development (Figure 3.5) is another model, and the text notes the possibility of combining throwaway prototyping with incremental development (Figure 3.6).
• The COMET (Concurrent Object Modeling and Architectural Design Method) is presented with a use case-based software life cycle model (Figure 5.1), highlighting phases like Requirements Modeling, Analysis Modeling, Design Modeling, Incremental Software Construction, Incremental Software Integration, and System Testing, with active Customer/User participation and the potential for Incremental Prototyping or Throwaway Prototyping.
• The Requirements Modeling phase in COMET involves developing a requirements model using actors and use cases, with a narrative description for each use case. User inputs and active participation are crucial, and throwaway prototyping can be used for clarification.

1. UML (Unified Modeling Language) Extension Mechanisms: UML provides standard ways to extend the language for specific problems.

• The three mechanisms are stereotypes, tagged values, and constraints (Section 2.10).
• Stereotypes "define a new building block that is derived from an existing UML modeling element but tailored to the modeler’s problem". Examples of stereotypes like «wide area network» and «user interaction» are seen throughout the diagrams.

1. Object-Oriented Design Principles:

• The excerpts touch upon inheritance hierarchies, warning that they can lead to "ripple-effect problems with deep inheritance hierarchies" if errors are made high up in the hierarchy. The advice is to "limit the depth of class hierarchies".
• Polymorphism is illustrated with the example of a debit operation on an Account object (checking or savings), where "A different variant of the debit operation is executed for savings accounts than for checking accounts".

1. Software Architecture: The text explores architectural concepts, particularly in the context of the Banking System and Automated Guided Vehicle System case studies.

• Subsystem Structuring: Subsystems can be determined by factors like geographical distribution or server responsibility. A common example is the client/service architecture, where a "client subsystem and a service subsystem" are allocated to different geographical locations. The Banking System is given as an example of "geographical subsystem structuring", with the ATMClient subsystem at each ATM and the BankingService subsystem at the server (Figure 13.1).
• Layered Architecture: An example is given of a layered architecture for an Online Shopping System (Figure 12.6), showing layers like the User Interface Layer, Application Layer, Coordination Layer, and Service Layer. The Emergency Monitoring System is also described with a layered architecture (Section 24.5), including a Service Layer (Alarm and Monitoring Data Services) and a Monitoring Layer (Remote System Proxy and Monitoring Sensor Component) which requires the services in the layer below.
• Component-Based Architecture: The COMET method is noted as supporting the design of "distributed component-based software architectures". Components are often depicted in diagrams using stereotypes like «component».
• Concurrent Design: The design of concurrent services is discussed, where components (like the Bank Transaction Coordinator and business logic objects in the BankingService) are designed as separate demand-driven tasks that are activated on demand, allowing for concurrent processing (Figure 15.13, Figure 21.37, Section 21.14). This is an alternative design choice if a sequential design is insufficient for the transaction load.
• Task Architecture: The concept of tasks in a concurrent system is shown in diagrams using stereotypes like «demand» (demand-driven tasks), «event driven» (event-driven tasks), and «periodic» (periodic tasks). The task architecture for the ATM Client subsystem is illustrated (Figures 18.21, 21.30).
• Deployment Diagrams: These diagrams illustrate the physical deployment of software artifacts on hardware nodes. Figure 21.36 shows a deployment diagram for the Banking System, with multiple ATMClient nodes connected via a «wide area network» to a BankingService server node.

1. Modeling with UML Diagrams: The excerpts frequently use UML diagrams to illustrate concepts and the design process.

• Communication Diagrams: Used to show the interactions between objects or components for a particular use case, illustrating message passing. Examples are shown for the Make Order Request use case (Figures 9.8, 9.9, 9.10) and the ATM Client Withdraw Funds use case (Figure 21.16, 21.17). Concurrent communication diagrams are also used to show interactions between concurrent tasks (Figures 16.16, 24.14, 21.25, 21.30, 21.35).
• Sequence Diagrams: Another type of interaction diagram showing the sequence of messages between objects over time (Figure 9.10 for Make Order Request).
• Statecharts (State Machine Diagrams): Used to model the dynamic behaviour of an object or system by showing its states and transitions between them in response to events. The statechart for ATMControl is detailed, illustrating the states related to PIN validation and transaction processing (Figures 11.9, 21.22). The AGV System's Vehicle Control statechart models the vehicle's states (Figure 24.5, 24.7). The text explains that the statechart is developed by considering the states as an actor proceeds through use cases.
• Class Diagrams: Used to show the static structure of a system, including classes, their attributes, operations, and relationships (Figures 14.5c, 15.12, 21.31).
• Component Diagrams: Used to show the high-level structure of a system in terms of its components and their relationships (Figure 24.15).
• Stereotypes are used extensively in these diagrams to denote the type or role of the modeled element (e.g., «subsystem», «service», «client», «coordinator», «business logic», «data abstraction», «state dependent control», «user interaction», «external user», «external I/O device», «I/O», «passive»).

1. Testing:

• Unit Testing: Test cases are developed during "detailed design and coding" to test individual units (components) using "white box test cases" that examine internal algorithms based on coverage criteria like executing every line of code and every decision outcome.
• Black Box Testing: Test cases based on use cases are developed, focusing on system functionality without regard to internal implementation. An example of a black box test case for the Validate PIN use case in the Banking System is provided, describing the steps and alternative sequences to be tested (invalid PIN attempts, card issues).
• The excerpt mentions using "test stub object[s]" to simulate external components during testing (e.g., simulating the card reader and the user for PIN input).

1. Case Studies (Banking System/ATM and Automated Guided Vehicle System): These systems are used repeatedly throughout the excerpts to illustrate the application of modeling and design concepts.

• Banking System/ATM:Described as a client/server system with geographically distributed ATMs connected to a central server via a WAN (Section 21.1).
• Functional requirements include withdrawing cash, querying balance, and transferring funds.
• Detailed description of the PIN validation process, including card recognition, expiration date check, PIN matching, and handling lost/stolen cards and multiple invalid PIN attempts. "The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails." Cards reported lost or stolen are also confiscated.
• Withdrawal approval criteria include sufficient funds, daily limit checks, and sufficient cash in the dispenser.
• Transfer approval criteria include having at least two accounts and sufficient funds in the debit account.
• Approved transactions result in a receipt being printed and the card being ejected. Customers can cancel transactions at any time.
• Customer, account, and debit card records are maintained at the server.
• Illustrations of communication diagrams (Figures 21.16, 21.17, 21.25), statecharts (Figures 11.9, 21.22), class diagrams (Figure 21.31), concurrent communication diagrams (Figures 18.21, 21.30, 21.35, 21.37), and a deployment diagram (Figure 21.36) are provided for this system.
• Automated Guided Vehicle (AGV) System:Used to demonstrate dynamic state machine modeling (statecharts) (Figure 24.5, 24.7) and concurrent communication patterns (Figure 24.14).
• The system involves a Vehicle Control component that executes a state machine representing the vehicle's operational states (idle, moving, loading, unloading, etc.).
• Interactions are shown with external systems (Supervisory System, Arrival Sensor, Display System) and internal components (Vehicle Status, Arm Interface, Motor Interface, timers) via communication diagrams (Figure 24.6) and concurrent communication diagrams (Figure 24.14).
• The AGV System is described as a "composite component that contains eight simple part components", with most being concurrent tasks (Section 24.7.5, Figure 24.15).

Most Important Ideas/Facts:

• Software development can follow different life cycle models, each with its strengths and weaknesses. The Spiral model is risk-driven and can incorporate aspects of other models.
• UML is an extensible modeling language, and stereotypes are a key mechanism for defining domain-specific modeling elements.
• Object-oriented design benefits from principles like polymorphism, but deep inheritance hierarchies should be limited.
• Software architecture defines the high-level structure of a system, often involving subsystems and their relationships. Client/server and layered architectures are common patterns.
• Concurrent design is important for systems requiring parallel processing and responsiveness, often involving task-based architectures.
• UML diagrams (Communication, Sequence, Statechart, Class, Component, Deployment) are essential tools for modeling different aspects of a software system throughout the development process.
• Testing strategies include both white box (examining internal implementation) and black box (based on functional requirements/use cases) approaches. Test stubs can be used to simulate parts of the system.
• The Banking System and AGV System case studies provide concrete examples of how the discussed modeling and design principles are applied in practice, illustrating subsystem structuring, dynamic behavior modeling (statecharts), and concurrent communication. The detailed description of the ATM PIN validation process and the vehicle state machine are key examples of behavioral modeling. The illustration of the client-server split in the Banking System is a clear example of architectural design.

This briefing provides a high-level overview of the key concepts covered in the provided text excerpts, focusing on the processes, tools, and architectural considerations in software modeling and design, exemplified by the case studies.

© 2025 Nguyen Duc Tuan – Sharing practical knowledge on Software Engineering, UML, and System Design.

💡 Recommendation: The articles on this blog provide general overviews and learning direction. To gain a more detailed and accurate understanding, it is highly recommended to read official textbooks, academic resources, and industry-standard UML references. This is the best way to grasp the core concepts and apply them effectively in real-world projects.

📧 Email: nguyenductuan11012003@gmail.com

🔗 Follow me on:

YouTube