Applied Software Engineering: Information Systems, Object Orientation, and UML Use Case Modelling

Applied Software Engineering Module Framework and Administration

  • Institutional Context & Module Leadership:

    • Institution: University of West London.
    • Module Leader: Nasser Matoorian.
    • Module Subject: Applied Software Engineering.

  • Core Module Aims:

    • Deliver a practitioner-focused methodology to address the engineering challenges of software application construction.
    • Instill critical discernment regarding the contextual selection and deployment of engineering tools and techniques.
    • Introduce fundamental paradigms of software architecture, structural design, and their execution during implementation phases.
    • Synthesize foundational software development competencies from object-oriented and relational database paradigms.
    • Provide rigorous training across risk management, domain analysis, problem formulation, testing regimes, maintenance strategies, and design patterns.

  • Explicit Module Learning Outcomes:

    • Outcome 1: Analyze systemic risk factors across software development lifecycle (SDLC) phases and construct formal mitigation strategies via a structured risk management process.
    • Outcome 2: Design and implement component-based software architectures founded on formal software engineering methodologies.
    • Outcome 3: Appraise the function of design patterns and system architectures in contemporary software engineering, characterizing dominant architectural styles.
    • Outcome 4: Apply leading software verification and testing methodologies across development stages.
    • Outcome 5: Identify the root causes of software maintenance failures, evaluate reverse-engineering tools, and understand reverse-engineering limitations.
    • Outcome 6: Critically analyze sustainable software engineering dimensions, encompassing Individual, Social, Economic, Environmental, and Technical sustainability.
    • Outcome 7: Select and execute precise engineering methodologies for sustainable design and manufacturing.
    • Outcome 8: Evaluate industrial practices in Sustainable Software Engineering.

  • Assessment Structures and Deadlines:

    • Assessment 1:
    • Title: UML Modelling and Design Patterns.
    • Indicative Word Count: 15001500 words (or equivalent).
    • Submission Platform: Blackboard.
    • Submission Deadline: Week 8 – Tuesday 17th November 2026.
    • Grading Weighting: 50%50\%.
    • Feedback Turnaround: 1515 working days.
    • Professional, Statutory, and Regulatory Body (PSRB) Threshold: 30%30\% qualifying threshold (applicable strictly to Computer Science CP6CS19E).

Assessment 1 Specification Table

  • Assessment 2:
    • Title: Software design and implementation – Report and in-class Test.
    • Sub-components:
      • Written Report submission: Week 10 – Tuesday 1st December 2026.
      • In-class Closed Book Examination: Week 13 – Tuesday 5th January 2027.
    • Indicative Word Count: 15001500 words.
    • Submission Platform: Blackboard.
    • Feedback Turnaround: 1515 working days.
    • Grading Weighting: 50%50\%.
    • PSRB Threshold: 30%30\% qualifying threshold (Computer Science CP6CS19E only).

Assessment 2 Specification Table

  • Module Grading Criteria:
    • Total Composite Weighting: 100%100\%.
    • Overall Pass Mark: 40%40\%.
    • Assessment Completion: Attainment of module learning outcomes is validated strictly via completion of both formal assignments.
    • Academic Resource Portal: Real-time library inventory, recommended texts, and digital reading lists are hosted at https://uwl.rl.talis.com/index.html and the institutional Blackboard portal.

Foundations of Software Engineering and the Software Crisis

  • Formal Definitions of Software Engineering:

    • IEEE Definition [IEEE90a]: Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
    • Core Scope: Engineered resolution of complexities inherent in large-scale software construction, necessitating phased execution across analysis, architectural design, coding, testing, and evolution.

  • Attributes of High-Quality Software Systems:

    • Primary Benchmark: Consistent fulfillment of end-user operational requirements.
    • Useful and Usable: Generates measurable utility and financial/operational value for client stakeholders.
    • Reliable: Performs operational functions dependably under defined boundary conditions without unhandled faults.
    • Flexible: Adaptable to evolving business rules and technical environments.
    • Affordable: Acquisition, operational, and maintenance overheads remain economically justifiable.
    • Available: Accessible for operation within designated operational uptime schedules.

  • The Software Crisis Paradigm:

    • Definition: Chronic, systemic inability of the software engineering industry to reliably construct systems on schedule, within capital limitations, and to customer satisfaction.
    • Formal Criteria for Project Failure:
    • Schedule Overrun: Delivery schedule exceeded by more than 30%30\%.
    • Budgetary Overrun: Allocated capital exceeded by more than 30%30\%.
    • Functional Failure: Deployment of an end product failing core user requirements.
    • Formal Criteria for Project Success:
    • On-time delivery within verified scheduling parameters.
    • Construction completed within authorized budgetary boundaries.
    • Rigorous compliance with all functional and non-functional specifications.
    • Secondary Critical Dimensions of System Quality:
    • Reliability: Consistent functional precision over execution cycles.
    • Robustness: Graceful degradation and fault-tolerance against anomalous operational environments.
    • Maintainability [Upgradeability]: Ease of modifying or extending functional code.
    • Reusability: Adaptability of software assets across diverse operational domains.
    • Security: Defense of internal data assets against intrusion, corruption, or data exfiltration.
    • Efficiency: Optimized consumption of computational cycles (execution velocity) and hardware memory (storage footprint).
    • Usability: Frictionless interaction protocols via intuitive user interfaces.

  • Inherent Complexities of Software Engineering Projects:

    • Large scope requiring multi-tier coordination.
    • High business and technological complexity.
    • Low estimation accuracy, making temporal and budgetary forecasting difficult.
    • Uniqueness: Projects rarely duplicate prior historical architectures.
    • Team dependencies: Development performed by large, multidisciplinary, often globally dispersed or offshore development groups.
    • Elusive specifications: Customer requirements are difficult to extract, formalize, and stabilize.
    • Specialized skill requirements: Heavy reliance on distinct, rare technical competencies.
    • Verification limits: Exhaustive, branch-complete testing is mathematically and practically impossible.
    • Invisibility of progress: Abstract code states are difficult to track without structured metrics.

  • Systemic Project Management Countermeasures:

    • Deployment of senior project leadership possessing extensive software delivery experience.
    • Establishment of rigorous communication protocols starting on Day 1 across internal developers, external clients, and end-users.
    • Exhaustive initial and ongoing planning with high granularity.
    • Comprehensive documentation managed via formal document control repositories.
    • High-frequency review cycles to isolate architectural defects and schedule drift early.
    • Enforcement of structured software lifecycle architectures tailored to project characteristics.

Case Studies in Systems Failure and Empirical Risk Studies

  • Famous Historical Failures:

    • Prominent large-scale disasters include Therac-25 radiation overdoses, Taurus (London Stock Exchange settlement system), Denver International Airport baggage handling automation, Ariane 5 Flight 501 rocket failure (1996), and the London Ambulance Service dispatch failure (1992).

  • The London Ambulance Service Computer-Aided Despatch (CAD) Failure (1992):

    • System Architectural Objectives:
    • Digital map interface displaying emergency call box identification.
    • Automated identification and filtering of duplicate caller reports.
    • Automated real-time tracking and spatial location of fleet ambulances.
    • Automated resource status and crew allocation updates.
    • Human operator role minimized strictly to taking emergency calls and resolving non-standard exception cases.
    • Chronology of System Collapse:
    • Commissioned into live production on 26th October 1992.
    • System queues dropped critical emergency calls, triggering repeated call duplicates.
    • Emergency telephone callers remained on hold for up to 30 minutes30\,\text{minutes}.
    • Ambulance dispatch delays reached up to 11 hours11\,\text{hours}; multiple ambulances responded to single events while other emergencies received zero dispatches.
    • Rapid escalation of systemic exception logs overwhelmed operator capacity.
    • Within 36 hours36\,\text{hours} of deployment, the CAD system was taken offline.
    • Management transitioned operations to a hybrid semi-automated/manual fallback mechanism.
    • The automated subsystem subsequently collapsed without a redundant automated backup, forcing emergency services into full manual command-and-control.
    • Architectural and Engineering Root Causes:
    • Specification Errors: Systems analysts assumed near-perfect input quality from distressed emergency callers and presumed flawless operational data from telemetry tracking.
    • Design Errors: Cartographic databases lacked topological data for all London streets; ambulance tracking was inconsistent; excessive autonomous decision-making authority was delegated to software algorithms without human intervention checkpoints.
    • Interface Defects: Dispatchers had no scrolling UI mechanism to review dispatch queues and verify vehicle dispatches, leading to an ever-expanding exception log.
    • Testing Omissions: The end-to-end system was never subjected to realistic load testing or emergency stress profiles prior to deployment.

  • KPMG Empirical Information Technology Study (1997):

    • Documented widespread causes of IT project cancellation and catastrophic overruns.
    • Primary Drivers of Failure:
    • Severe schedule and capital overruns.
    • Absence of necessary specialized technical skills and engineering expertise within delivery teams.
    • Rapid turnover of mission-critical engineering personnel.
    • Low overall skill competencies and absence of project commitment among team members.
    • Total lack of a structured, disciplined software development methodology.
    • Key Statistical Findings:
    • 60%60\% of small-scale software projects ended in total operational failure.
    • Custom software development projects correlated directly with catastrophic budget inflations and delivery delays.

Information Systems Architecture and Stakeholder Taxonomy

  • Definition and Structural Boundary of Information Systems:

    • An information system operates within an external environmental context while maintaining a clearly demarcated architectural boundary.
    • Executes continuous bidirectional environmental interactions via defined inputs and outputs.
    • Enforces internal control mechanisms designed to track performance metrics against predefined organizational targets.
    • Foundational Definition: An engineered system that converts unstructured real-world data into structured, meaningful information.

  • Functional Taxonomies of Information Systems:

    • Operational Systems: Process high-volume, everyday business transactions at foundational organizational levels.
    • Management Support Systems:
    • Decision Support Systems (DSS): Deliver analytical processing to evaluate operational scenarios.
    • Strategic Information Systems: Synthesize executive-level data for long-term organizational planning.
    • Real-Time Systems: Execute time-critical operations requiring deterministic execution and immediate sensor/actuator responsiveness.

  • Stakeholder Classifications in Software Projects:

    • Clients: Organizational bodies or executive agents financing and commissioning system construction.
    • Users: Operational actors directly interacting with the deployed software interface to execute business tasks.
    • Developers: Systems analysts, software engineers, and testers responsible for specifying, designing, and programming the solution.

Software Development Lifecycles and Process Models

  • Fundamental Software Engineering Process Activities:

    • Specification: Elicitation, definition, and validation of functional requirements and system boundaries.
    • Design: Architectural structuring, subsystem decomposition, and detailed interface specification.
    • Validation: Verification and testing to verify software compliance with client intent.
    • Evolution: Continuous modification, refactoring, and maintenance to satisfy changing business conditions.

  • Generic Process Paradigms:

    • Waterfall Model: Rigid, planar progression across discrete, decoupled phases.
    • Evolutionary Development: Concurrent, interleaved specification, design, and code generation.
    • Formal Systems Development: Mathematical transformation of formal specifications into verifiable executable software.
    • Reuse-Based Development: Architectural assembly and integration of pre-existing COTS or open-source software components.

  • The Waterfall Model:

    • Lifecycle Phases:
    1. Requirements analysis and definition.
    2. System and software design.
    3. Implementation and unit testing.
    4. Integration and system testing.
    5. Operation and maintenance.

Waterfall Model Diagram

  • Inherent Architectural Weaknesses:

    • Inflexible phase partitioning treats development as a linear progression.

    • Accommodating emergent customer requirements mid-lifecycle requires costly rework.

    • Feasible almost exclusively when functional and environmental requirements are fully understood, stable, and immutable from inception.

    • Iterative and Incremental Lifecycles:

  • Foundational Mechanics:

    • System scope is partitioned into functional increments, with each delivering a usable subset of system capabilities.
    • Requirements are prioritized: high-value, high-risk elements are allocated to initial iterations.
    • Once an increment begins active development, its specific functional requirements are frozen, while downstream increment requirements remain open to change.

  • Distinct Engineering Advantages:

    • Working software reaches customer production environments significantly earlier.
    • Operational increments serve as dynamic prototypes, guiding subsequent requirement discovery.
    • Reduces risks of total project abandonment.
    • Core services undergo cumulative regression verification across successive cycles.

Iterative and Incremental Development Framework

  • The Boehm Spiral Model:
    • Visualizes the development lifecycle as an expanding spiral across four analytical quadrants, rather than a linear sequence with ad-hoc backtracking.
    • Adapts phases dynamically based on continuous risk profiling, rather than adhering to rigid administrative milestones.

Boehm Spiral Model Lifecycle

  • The Four Operational Quadrants:
    • Quadrant 1: Determine Objectives, Alternatives, and Constraints:
      • Identify explicit operational targets, architectural alternatives, and business or financial boundaries for that cycle.
    • Quadrant 2: Evaluate Alternatives, Identify and Resolve Risks:
      • Perform risk analyses; construct dynamic prototypes (Prototype 1, Prototype 2, Prototype 3, Operational Prototype); execute simulations, models, and analytical benchmarks to validate feasibility.
    • Quadrant 3: Develop, Verify Next-Level Product:
      • Execute engineering activities using an appropriate process model. Progression tracks: Concept of Operation →\rightarrow Software Requirements →\rightarrow Requirement Validation →\rightarrow Product Design →\rightarrow Detailed Design →\rightarrow Coding →\rightarrow Unit Testing →\rightarrow Design V&V →\rightarrow Integration Testing →\rightarrow Acceptance Testing →\rightarrow Service Deployment.
    • Quadrant 4: Plan Next Phase:
      • Review progress, update requirements plans, validate life-cycle and testing plans, and configure resource allocations for subsequent spiral iterations.

Introduction to Modelling and the Unified Modelling Language (UML)

  • The Engineering Rationale for Abstract Modelling:

    • Modern software systems exhibit high structural complexity and scale, distributed offshore development, and multi-team collaboration.
    • Abstract visual models simplify system complexity by highlighting critical design structures while hiding non-essential implementation details.

  • Constituents of a Software Development Method:

    • Model Elements: Foundational conceptual constructs representing design semantics.
    • Notation: Standardized visual syntax used to represent model elements.
    • Process: Ordered procedural instructions for engineering the target system.
    • Patterns: Proven architectural idioms and structural templates.
    • Objective: Ensure repeatable, high-reliability production of software assets.

  • Structural Dynamics of Modelling Languages:

    • Model Definition: A precise, unambiguous abstract representation of system specifications or designs rendered from a specific perspective.
    • Syntax: The formal legal elements and structural composition rules of the language.
    • Semantics: The formal rules determining the conceptual and behavioural meaning of syntactically legal diagrams.
    • Core Requirements for an Effective Modelling Language:
    • Highly expressive across structural and dynamic domains.
    • Low cognitive load: Facilitates thought without notation-induced friction.
    • Unambiguous and rigorously formalized.
    • Comprehensive Computer-Aided Software Engineering (CASE) tool support.
    • Industry-wide ubiquity and vendor neutrality.

  • The Method Wars and UML Consolidation:

    • Historical Landscape (Method Confusion): The late 1980s and early 1990s saw competing methods, including SSADM, PRINCE, Information Engineering, Booch ('91, '93), Object Modelling Technique (OMT-1, OMT-2), Object-Oriented Software Engineering (OOSE), SA/SD, Catalysis, Fusion, DSDM, Eiffel, Component Architecture Method, Rapid Application Development (RAD), and Extreme Programming (XP).

Method Evolution and Confusion Cloud

  • Chronology of Object-Orientation Foundations:
    • 1966: Simula introduces initial object-oriented primitives.
    • Joseph Goguen advances formal research into Abstract Data Types (ADTs) and encapsulation.
    • 1980: Smalltalk-80 establishes the first dedicated pure object-oriented language.
    • Mid-1980s: Bjarne Stroustrup creates C++ (extending C with object macros), driving mainstream enterprise adoption of OOP.
  • Evolutionary Trajectory of UML:
    • OOPSLA '95: Grady Booch and James Rumbaugh unify Booch '93 and OMT-2 to release the Unified Method 0.8 documentation set.
    • June 1996: Ivar Jacobson integrates OOSE, culminating in the release of UML 0.9 web specifications.
    • OOPSLA '96: Release of the UML 1.0 beta specification.
    • January 1997: Submission of UML 1.0 to the Object Management Group (OMG) for standardization.
    • Standardization: Ratification of UML 1.1 through 1.5, culminating in the modernization of UML 2.0.

UML Evolutionary Timeline

  • The OMG Paradigm Shift:

    • Decoupled the modelling notation from specific development processes.

    • Establishes UML as a universal, method-independent modelling language.

    • Computer-Aided Software Engineering (CASE) Tooling:

  • Purpose: Automates and coordinates software engineering workflows.

  • Functional Modules: Graphical diagram editors, centralized data dictionaries, GUI prototyping environments, integrated debuggers, and automatic forward/reverse code generators.

  • Industry Challenges: Rapid iteration of UML standards imposes high maintenance costs on CASE tool vendors.

  • Industry-Standard Tool Examples: StarUML, Visual Paradigm.

  • Practical Scope: Focuses on two specific SDLC phases: Requirements Analysis and Software Design.

Principles and Foundations of Object Orientation

  • The Universal Scope of Object-Orientation:

    • Applied across the software lifecycle, from domain understanding and requirements specification to design, coding, and deployment.

  • Formal Axiomatic Definition of an Object:

    • Foundational Equation:   Object=Identity+Behaviour\text{Object} = \text{Identity} + \text{Behaviour}
    • Complete Formal Equation:   Object=Identity+Behaviour+Lifetime\text{Object} = \text{Identity} + \text{Behaviour} + \text{Lifetime}
    • Identity: An intrinsic property that keeps an individual object distinct from all others, even as its internal state changes.
    • Behaviour: The operational services, actions, and transformations an object performs.
    • Lifetime: The duration over which an object exists with continuous identity, provides services, and undergoes state modifications.

Object Lifetime and Identity Evolution

  • State Dynamics and Attribute Mutation:

    • State: The internal configuration of data values held across an object's defined properties (attributes).
    • Attribute Mutability: Attributes that change value across the object's lifecycle are mutable; those that remain static are immutable.
    • Analytical Example – The Book Object:
    • Immutable Properties: Title, Total Page Count, ISBN, Author.
    • Mutable Properties: Total pages read, Identity of active borrower.
    • Analytical Scenario – Estate Agency Customer Domain:
    • Context: Individual (Joe) registers with an agency to acquire real estate.
    • Lifecycle Bound: Created upon initial registration; destroyed when business engagement terminates.
    • Typical Attributes: Customer Name, Target Price Bracket, Preferred Location, Contact Number.
    • Dynamic Attribute Values: Real-time values stored within customer data fields.
    • Associated Behaviours: Search registered properties, schedule a viewing, submit an offer.

  • Classes Versus Instances:

    • Class: An abstract structural blueprint defining the shared attributes, operations, and constraints of a category of objects.
    • Instance: A distinct runtime entity created from a class blueprint (e.g., individual customer objects like Joe are instances of class Customer).

  • Encapsulation:

    • Definition: The bundling of state data together with the operations that read or modify it, hiding internal representations from direct external access.
    • The Post Box Metaphor:
    • Letters can only enter the post box via the front mail slot.
    • Letters can only be retrieved via the locked rear door using an authorized key.
    • External actors cannot access or modify internal letters outside these two defined entry points.

Post Box Encapsulation Metaphor

  • Architectural Interface Boundary:
    • Internal data fields are surrounded by an operational boundary.
    • External entities interact with internal state solely by sending messages to operations on the outer interface.

Object Encapsulation Topology

  • Message Passing:

    • The interaction mechanism linking objects within an object-oriented system.
    • Mechanics: The invocation of an operation on a target object, triggering it to read or modify its encapsulated data to satisfy user requirements.

  • Inheritance:

    • A structural mechanism where a derived subclass inherits attributes and operations from a base superclass.
    • Implementation dependency: Bound to the capabilities of the underlying programming language.
    • Advantages: Eliminates redundant code and supports incremental expansion.
    • The "Is A" Validation Rule: An inheritance relationship is conceptually valid only if the subclass adheres to the statement "Subclass Is A Superclass".

  • Polymorphism:

    • Etymological Root: Derived from Greek, meaning "taking many shapes".
    • Structural Operation: The ability of different subclasses in an inheritance hierarchy to implement an inherited operation differently.
    • Impact: Different objects can respond to the same message request with distinct, specialized behaviours.

Use Case Modelling: Domain Concepts and System Boundaries

  • Domain Modeling Foundations:

    • Systems operate within the operational context of an overarching problem domain.
    • Alternative Terminology: Business Object Model; Business Type Model.
    • Scope: Captures real-world concepts, entities, and terminology used by domain stakeholders; typically constructed as the initial analytical perspective.
    • Techniques for Domain Information Gathering:
    • Direct observational immersion in the operational environment.
    • Collaborative brainstorming sessions.
    • Formal interviews with domain subject-matter experts.
    • Structural review of corporate documentation and procedures.
    • Empirical analysis of legacy applications deployed in the target environment.
    • Strategic Value of Use Case Domain Models:
    • Engages business stakeholders directly in system specifications.
    • Helps structure software deliverables into clear development increments.
    • Guides functional requirement prioritization.
    • Supplies test case criteria for downstream verification.

  • Actor Definitions and Constraints:

    • Position: Actors reside strictly outside the system boundary.
    • Role: Entities that trigger system operations, provide input data, and/or receive output data from the system.
    • Discovery: Identified through problem statements and conversations with users.
    • Distinction Between Actors and Roles: A single person can embody multiple actor roles, and a single actor role can be shared across multiple people.

  • Use Case Definitions:

    • Defines an interaction dialogue between external actors and the system.
    • Captures user actions that generate a discrete business event within a wider process.
    • Standard Formal Definition: A sequence of transactions performed by a system that yields a measurable result of value for an actor.
    • Communications Association: Visualized as a solid path linking an actor to a use case oval, designating bidirectional message flow.

  • Library System Exemplar:

    • Actors: Borrower, Librarian.
    • Use Cases: "Borrow a book copy", "Reserve a book", "Return a book".
    • Associations:
    • Borrower interacts with: "Borrow a book copy", "Return a book".
    • Librarian interacts with: "Borrow a book copy", "Reserve a book", "Return a book".

Library System Use Case Diagram

  • Actor Identification Heuristic Questions:

    • Who is interested in a certain requirement?
    • Where in the business is the system used?
    • Who will benefit from the use of the system?
    • Who will supply the system with this information, use this information, and remove this information?
    • Who will support and maintain the system?
    • Does the system use an external resource?
    • Does one person play several roles?
    • Do several people play the same role?
    • Does the system interact with a previous system?

  • Domain Analysis Case Study – Lekey & Wette Caravan Holidays Ltd:

    • Business Context:
    • Requires a software system to track caravan bookings.
    • Customer bookings remain provisional until an initial financial deposit is cleared.
    • Prospective customers search for caravans matching their criteria and submit initial reservations.
    • The system generates a temporary booking identifier that expires automatically after 3 days3\,\text{days} if no deposit is received.
    • The system processes credit card payments securely via a web interface.
    • Caravans are privately owned; dedicated Lekey & Wette sales representatives manage owner relationships.
    • Caravan owners coordinate with sales representatives to mark their units as available for specific rental dates.
    • Geographic regions contain multiple individual caravan parks.
    • Once a caravan booking is confirmed, the system processes and tracks subsequent installment payments.
    • Caravans belong to specific classification types and contain a customized selection of amenities drawn from a global facilities list.
    • Identical amenities appear across multiple caravan profiles.
    • Actor Identification Analysis:
    • Primary External Actors: Prospective Customer, Registered Customer, Caravan Owner, Sales Representative, Payment Gateway/External Financial Clearinghouse.

  • System Boundary Demarcation:

    • Delineates which business processes are automated inside the proposed software system and which remain external manual workflows.
    • Clarifies which actors interface directly with software operations versus those interacting via intermediate users.

Use Case Specification, Structuring, and Granularity

  • Structural Syntax of Use Case Descriptions:
    • Name: Verb-noun construction (e.g., Take Order, Confirm Booking).
    • Goal: A 2–32\text{--}3 line summary defining the intended outcome.
    • Precondition: System states and environmental conditions that must be true before execution.
    • Trigger: The initiating event—typically generated by an actor—along with any input parameters.

Use Case Description Specification Pattern

  • Detailed Specification Example – Confirm Booking:

    • Name: Confirm Booking
    • Goal: Ensure that the provisional booking is now confirmed so that it is saved for the customer.
    • Precondition: The customer is registered and a provisional booking exists.
    • Trigger: Customer selects confirm option.
    • Primary Scenario Flow (Normal Path / "Happy Day"):
    1. Customer selects confirm booking option.
    2. Customer enters the "Booking Number" details.
    3. System displays the provisional booking details.
    4. Customer enters payment details.
    5. System informs customer that credit details are being checked.
    6. <<include>> Check Credit.
    7. System confirms that payment details have been processed and provides user with confirmation number.
    • Alternative Exception Paths:
    • 4.1: Customer cancels booking.
    • 7.1: System states that credit check has failed and an alternative card is to be used.

  • Use Case Structuring Mechanisms:

    • The <<includes>> (or <<include>>) Relationship:
    • Connects a base use case to an included use case, incorporating the target's behavior into the base flow.
    • Primary Purpose: Reuses common behavior and eliminates modeling redundancy.
    • Execution Semantics: Use case AA <<includes>> BB if tracing through AA automatically executes the steps in BB.
    • Abstract Use Cases: Included use cases designed solely for reuse and never invoked directly by actors.
    • Example: "Pay invoice" <<include>> "perform transaction"; "Cancel reservation" <<includes>> "Find Reservation".

Includes and Extends Relationship Diagram

Pay Invoice Includes Perform Transaction

  • The <<extends>> Relationship:

    • Conditionally inserts optional or exceptional behavior paths into a primary use case.

    • Modeling Guidance: Use with caution to avoid unnecessary diagrammatic complexity.

    • Example: "Make reservation" <<extends>> "Make Group Reservation".

    • Managing Use Case Granularity:

  • Granularity Range: Spans high-level enterprise functions down to low-level atomic tasks.

    • High Granularity (Enterprise Scope): Purchasing, Stock Control.
    • Medium Granularity (Business Processes): Raise Requisition, Monitor Stock.
    • Low Granularity (Atomic System Transactions): Find Supplier, Validate Stock Level.

Use Case Granularity Continuum

  • Criteria for Atomic Use Cases:

    • Involves input from a single actor.

    • Initiated by a single, discrete business event.

    • Runs as an uninterrupted transactional process without waiting on external business events.

    • Corresponds directly to a single software unit of work (transaction).

    • Decomposition Case Study – Open Account:

  • Initial Process Description:

    • Step 1: Customer requests to open account (Initial business event: account open request).
    • Step 2: Providing customer details are complete, Personal Banker uses system to find customer.
    • Step 3: If no matching customer, Personal Banker uses system to create customer record.
    • Step 4: Personal Banker initiates credit check.
    • Step 5: When credit clearance is received (New business event: credit check completed), Personal Banker asks system to create new account.
    • Step 7: Personal Banker requests check book.
    • Step 8: When check book printed (New business event: check book printed), Personal Banker sends confirmation letter and check book to customer.

Decomposing the Open Account Use Case

  • Decomposition Strategy:
    • Analyzing the process reveals time delays and distinct business triggers, showing that this workflow spans three separate atomic use cases.
    • Atomic Unit 1: "Request New Account" – Triggered by the customer's initial application.
    • Atomic Unit 2: "Perform Credit Check" – Triggered once asynchronous credit agency clearance is returned.
    • Atomic Unit 3: "Order Cheque Book" – Triggered when the physical cheque book printing cycle finishes.
  • Structured Model:
    • The parent "Open Account" use case associates with the Bank Clerk, while delegating functional tasks through <<includes>> relationships to "Request New Account" (involving the Prospective Customer), "Perform Credit Check" (involving an external Credit Check Company), and "Order Cheque Book".

Constructed Open Account Use Case Model