Software Engineering Design Principles, Architectural Styles, and UML Modeling

Foundations of Design Engineering

Design engineering encompasses the complete set of principles, concepts, and practices that leads to the development of a high-quality system or product. Within software engineering, design represents the critical phase where creativity rules, allowing customer requirements, business needs, and technical considerations to come together in the formulation of a physical or logical system. Design serves as the mechanism by which software engineers model the system or product prior to construction, making it the primary stage where software quality is formally established.

This material is structured for II Year B.Tech. CSE I - Sem under Unit-III of Software Engineering, covering design engineering fundamentals, architectural styles, component modeling, and standard Unified Modeling Language (UML) structural and dynamic diagrams.

Software Design Process and Quality Assurance

Software design is an iterative process through which software requirements are translated into a comprehensive blueprint for constructing the system. The design phase must fulfill three fundamental goals:

1. The design must implement all of the explicit requirements contained in the analysis model.

2. The design must be a readable, understandable guide for those who construct the code and test the system.

3. The design should provide a complete picture of the software, addressing data, functional, and behavioral domains from an implementation perspective.

To achieve high quality, a software design must adhere to clear guidelines. The architecture of the system should be created using recognizable architectural styles or patterns, composed of components that exhibit good design characteristics, and structured such that it can be implemented in an evolutionary fashion to facilitate building and testing. The design must be modular, containing distinct representations of data, architecture, interfaces, and components. Furthermore, it should lead to data structures appropriate for the target classes, produce components with independent functional characteristics, and establish interfaces that reduce connection complexity between internal components and external environments. A quality design must be derived using a repeatable method driven by information obtained during requirements analysis and represented using a notation that effectively communicates its meaning.

Software quality attributes are assessed using the FURPS model:

• Functionality: Evaluated by evaluating the feature set and capabilities of the program, the generality of the functions delivered, and the security of the overall system.

• Usability: Assessed by considering human factors, overall aesthetics, consistency, and documentation.

• Reliability: Evaluated by measuring the frequency and severity of failure, accuracy of output results, mean-time-to-failure (MTTF), ability to recover from failure, and predictability of the system.

• Performance: Measured by processing speed, response time, resource consumption, throughput, and efficiency.

• Supportability: Evaluated by maintainability, testability, flexibility, installability, and serviceability.

Core Software Design Concepts

Fundamental software design concepts provide the framework necessary to construct complex systems effectively:

• Abstraction: Software solutions exist at multiple levels of abstraction. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. Procedural abstraction refers to a sequence of instructions that have a specific and limited function. Data abstraction is a named collection of data that describes a data object.

• Architecture: Architecture refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Architectural models include:

  • Structured models: An organized collection of program components.

  • Framework models: Models that increase the level of design abstraction.

  • Dynamic models: Models that address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events.

  • Process models: Models that focus on the design of the business or technical process that the system must accommodate.

  • Functional models: Models used to represent the functional hierarchy of a system.

• Patterns: A design pattern describes a design structure that solves a particular design problem within a specific context and amid forces that may impact how the pattern is applied. The intent of each design pattern is to enable a designer to determine: whether the pattern is applicable to the current work, whether the pattern can be reused, and whether the pattern can serve as a guide for developing a similar, functionally or structurally different pattern.

• Modularity: Modularity involves dividing software into separately named and addressable components, sometimes called modules, which are integrated to satisfy overall problem requirements.

• Information Hiding: This concept dictates that information contained within a module is inaccessible to other modules that have no need for such information.

• Functional Independence: Functional independence is a direct outgrowth of modularity, abstraction, and information hiding. Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion provides an indication of the relative functional strength of a module. Coupling provides an indication of the relative interdependence among modules.

• Refinement: Program development occurs through successively refining levels of procedural detail. Refinement is essentially a process of elaboration, moving from high-level statement of function to low-level implementation details.

• Refactoring: Refactoring is a reorganization technique that simplifies the design of a component without changing its external function or behavior.

Design Class Principles and Categories

Software engineering teams define a set of design classes to fulfill two main roles: refining analysis classes by providing design details necessary for implementation, and creating a new set of design classes that implement a software infrastructure to support the design solution.

Five distinct types of design classes are established:

1. User interface classes: Define all abstractions that are necessary for human-computer interaction (HCI).

2. Business domain classes: Refinements of the analysis classes defined during requirements modeling.

3. Process classes: Implement lower-level business abstractions required to fully manage the business domain classes.

4. Persistent classes: Represent data stores that will persist beyond the execution of the software.

5. System classes: Implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.

A well-formed design class exhibits four core characteristics:

• Complete and sufficient: Includes only those attributes and methods needed to realize the class abstraction, fully covering its intended responsibility.

• Primitiveness: Each method in the design class should focus on accomplishing a single, well-defined service.

• High cohesion: A cohesive class possesses a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.

• Low coupling: Design classes should minimize interdependencies with other classes, maintaining clean, well-defined communication channels.

Structure of the Design Model

The design model organizes software representations across two dimensions: the abstraction dimension and the process dimension. The abstraction dimension spans high-level abstractions down to low-level implementation details. The process dimension organizes design elements across four specific domains: architecture elements, interface elements, component-level elements, and deployment-level elements.

The elements of the design model encompass five key categories:

1. Data design elements: Create a model of data and/or information represented at a high level of abstraction. Data design spans three organizational levels: at the program component level, at the application level, and at the business level.

2. Architectural design elements: Serve as the equivalent of a house floor plan. The architectural model is derived from three main sources: information about the application domain for the software, specific analysis model elements (such as class diagrams or data flow diagrams), and the availability of architectural patterns.

3. Interface design elements: Equivalent to detailed architectural drawings for doors, windows, and external utilities. Interface design consists of three primary elements:

   • The user interface (UI);

   • External interfaces to other systems, devices, networks, or other producers or consumers of information;

   • Internal interfaces between various design components.

4. Component-level design elements: Equivalent to detailed interior structural drawings, fully describing the internal details, processing logic, and data structures of each software component.

5. Deployment-level design elements: Indicate how software functionality and subsystems will be allocated within the physical computing environment and hardware configuration that supports the system.

Architectural Specification and Data Design Principles

Software architecture represents the structure of data and program components required to build a computer-based system. Architectural design operates across two levels of the design pyramid: data design and architectural design. Software architecture is critical because it acts as an enabler for communication among all stakeholders, highlights early design decisions that exert a profound impact on subsequent engineering work and operational success, and constitutes a relatively small, intellectually graspable model of how the system is structured and how its components interact.

Data design translates data objects from the analysis model into specific data structures at the software component level and, when necessary, a database architecture at the application level.

• Data design at the Architectural Level: Focuses on establishing enterprise-wide or cross-functional databases and data warehouses, addressing the challenge of extracting useful information across organizational systems.

• Data design at the Component Level: Focuses on specifying data structures directly accessed and manipulated by individual software components.

Seven principles govern data specification:

1. Systematic analysis principles applied to function and behavior must also be applied to data.

2. All data structures and the operations to be performed on each should be explicitly identified.

3. A data dictionary should be established and used to define both data and program design.

4. Low-level data design decisions should be deferred until late in the design process.

5. The representation of a data structure should be known only to those modules that must make direct use of the data contained within the structure.

6. A library of useful data structures and the operations that may be applied to them should be developed.

7. A software design and programming language should support the specification and realization of abstract data types.

Architectural Styles and Structural Patterns

Software built for computer-based systems exhibits one of several architectural styles. An architectural style describes a system category that encompasses:

1. A set of components (e.g., databases, computational modules)

2. A set of connectors (e.g., procedure calls, network protocols)

3. Constraints that define how components can be integrated

4. Semantic models that enable a designer to understand the overall properties of a system

An architectural pattern differs from an architectural style in three fundamental ways:

1. The scope of a pattern is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety.

2. A pattern imposes a rule on the architecture, describing how the software will handle some aspect of its functionality at the infrastructure level.

3. Architectural patterns tend to address specific behavioral issues within the architectural context.

Taxonomy of Architectural Styles:

• Data-centered architectures: Feature a central data store (repository or blackboard) that is surrounded by independent client software components. The central repository holds data while client components perform operations, create, delete, or modify data in the store.

• Data-flow architectures: Applied when input data is transformed through a series of computational or manipulating components into output data. Subtypes include:

  • Pipes and filters: Uses filters to transform data streams and pipes to transmit data between filters.

  • Batch sequential: Processes data in discrete sequential steps, where each step reads an entire dataset before producing an output dataset for the next filter.

• Call and return architectures: Enables a control structure that is easy to modify and scale. Subtypes include:

  • Main program/subprogram architectures: Control flows top-down through a control hierarchy. Metrics include depth (number of levels), width (horizontal span), fan-out (number of sub-modules directly controlled by a top module $M$), and fan-in (number of modules that control or share a single module).

  • Remote procedure call (RPC) architectures: Components are distributed across multiple machines on a network.

• Object-oriented architectures: Components encapsulate data operations and state, communicating via message passing.

• Layered architectures: Organized into concentric or horizontal layers. The outer layer handles user interface operations, followed by application layers and utility layers, down to the core layer containing system and hardware interfaces.

Architectural Patterns for System Behaviors:

• Concurrency patterns: Operating system process management pattern, task scheduler pattern.

• Persistence patterns: Database management system pattern, application-level persistence pattern.

• Distribution patterns: Organization and refinement patterns establishing design criteria for assessing architectural designs.

Architectural Design Process and SafeHome Case Study

The architectural design process begins by placing the target system in context, identifying its archetypes, and systematically refining it into functional components.

Representing the System in Context: An architectural context diagram models the boundary between the target system and its surrounding environment. For the SafeHome Security Function target system:

• Superordinate systems: SafeHome Product, Internet-based system.

• Subordinate systems: Sensors (motion, door/window sensors).

• Peer systems: Surveillance function.

• External entities: Homeowner, Control panel.

Defining Archetypes: An archetype is a class or pattern that represents a core abstraction critical to the design of the system architecture. In the SafeHome system, core archetypes include Controller, Node, Detector, and Indicator. Controller aggregates Node and communicates with other controllers. Node acts as a base class that generalizes into specialized child classes Detector and Indicator.

Refining Architecture into Components: As the architecture is refined into components, the modular structure emerges. High-level components for SafeHome include:

• SafeHome Executive: Top-level manager driving function selection across modules.

• External Communication Management: Communicates with GUI and Internet Interface.

• Security: Manages Control panel processing, Detector management, and Alarm processing.

• Surveillance: Manages video monitoring functions.

• Home management: Handles home automation features.

Describing System Instantiations: Detailed instantiation elaborates lower-level sub-components. Control panel processing expands into Key pad processing and CP display functions. Detector management incorporates scheduler and physical sensor units. Alarm processing manages phone communication and physical alarm output hardware.

Conceptual Model of UML and Object-Oriented Principles

Unified Modeling Language (UML) is a standard modeling language used for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML builds upon standard Object-Oriented (OO) analysis and design concepts:

Core Object-Oriented Concepts:

• Objects: Basic building blocks representing discrete real-world or software entities containing state and behavior.

• Class: The blueprint or template used to instantiate objects.

• Abstraction: Simplification of complex real-world behaviors into essential characteristics.

• Encapsulation: The mechanism of binding data (attributes) and operations (methods) together while restricting direct access from external modules.

• Inheritance: The mechanism by which new classes derive properties and methods from existing superclasses.

• Polymorphism: The ability of different classes to respond to identical method calls in unique ways.

Object-Oriented Analysis and Design (OOAD) Process: OOAD represents an investigation of objects and their collaborations. The core objectives are to identify system objects, establish their relationships, and construct a design convertible into executable code using object-oriented languages. The process follows three sequential steps: $\text{OO Analysis} \rightarrow \text{OO Design} \rightarrow \text{OO Implementation using OO languages}$

Structural Modeling and Class Diagrams

Structural modeling captures the static framework of a software system. Structural diagrams encompass:

• Class diagrams

• Object diagrams

• Deployment diagrams

• Package diagrams

• Composite structure diagrams

• Component diagrams

Class Diagrams: A Class Diagram is a static diagram showing a collection of classes, interfaces, associations, collaborations, and constraints. Its primary purposes are:

1. Analysis and design of the static view of an application.

2. Describing the responsibilities of system entities.

3. Serving as the foundation for component and deployment diagrams.

In a sample Order Management System class diagram:

• Customer class contains attributes name:String, location:String and methods sendOrder(), receiveOrder().

• Customer connects with multiplicity $1$ to $n$ with the Order superclass.

• Order class contains attributes date:Date, number:String and methods confirm(), close().

• Order serves as a superclass that generalizes into two subclasses: SpecialOrder (with methods confirm(), close(), dispatch()) and NormalOrder (with methods confirm(), close(), dispatch(), receive()).

Dynamic Modeling: Sequence and Collaboration Diagrams

Dynamic modeling captures the behavioral execution and temporal interactions of system objects over time.

Sequence Diagrams: A Sequence Diagram models object interactions arranged in time sequence. In an Order Management System sequence diagram:

• Objects represented along lifelines: :Customer, :Order, :SpecialOrder, and :NormalOrder.

• Control flow begins with an Initialization call triggering sendOrder() on :Customer.

• :Customer passes a message sendOrder() to :Order.

• :Order calls Dispatch() on :SpecialOrder (or :NormalOrder), which executes Confirm() via a self-call.

• :SpecialOrder returns execution flow to :Order, which subsequently returns to :Customer.

Collaboration Diagrams: A Collaboration Diagram (also called a Communication Diagram) emphasizes the structural organization of objects that exchange messages. Message sequencing is explicitly denoted using numbered sequence prefixes:

1. Initialization triggers :Customer.

2. Message 1:sendOrder() is sent from :Customer to :Order.

3. Message 2:confirm() is sent from :Order to :SpecialOrder.

4. Message 3:dispatch() represents a self-delegation operation on :SpecialOrder, terminating at End of Process.

Dynamic Modeling: Use Case Diagrams

Use case diagrams model system dynamics by encapsulating functionality through actors, use cases, and relationships.

Purposes of Use Case Diagrams:

1. Gather user and system requirements.

2. Depict the external operational view of the system.

3. Identify internal and external factors influencing system functionality.

4. Represent interactions between human actors, external services, and use cases.

Rules for Drawing Use Case Diagrams:

1. Assign pertinent and meaningful names to actors and use cases.

2. Define actor-to-use case communications in a clear, understandable manner.

3. Use standardized UML notations consistently.

4. Highlight the most significant interactions among actors and system use cases.

Subsystem Use Case Structure (Online Shopping):

• Actors: Web Customer (generalized parent of Registered Customer and New Customer), external services Authentication (<>), Identity Provider, Credit Payment Service, and PayPal.

• System Boundary: Online Shopping subsystem containing use cases View Items, Make Purchase, Checkout, and Client Register.

• Relationships: Make Purchase includes (<>) View Items and Checkout. New Customer interacts with Client Register.

Detailed Extension and Include Relationships:

• Use cases Search Items, Browse Items, View Recommended Item, Add to Shopping Cart, and Add to Wish List extend (<>) the base use case View Items.

• View Recommended Item and Add to Wish List explicitly include (<>) Customer Authentication.

• Add to Shopping Cart extends (<>) Customer Authentication.

Physical Modeling: Component Diagrams

Component diagrams model the physical aspects of a software system, representing physical elements such as executables, source code files, libraries, documents, and database schemas residing on hardware nodes.

Purposes of Component Diagrams:

1. Visualize software components and physical source/executable artifacts.

2. Support system implementation and build processes via forward and reverse engineering.

3. Describe physical organizational structure and file dependency relationships.

Sample Component Diagram (Order Management System Java Files): Physical implementation components represent Java files: Customer.java, Order.java, SpecialOrder.java, and NormalOrder.java. Arrows depict physical dependency connections: Customer.java depends on Order.java, while SpecialOrder.java and NormalOrder.java depend on Order.java and Customer.java.