8. Software Engineering and Information System (ACtE08)

8.1 Software Process and Requirements

Software engineering is a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. It encompasses various processes and methodologies to ensure the creation of high-quality software that meets user needs.

Software Characteristics

• Functionality: The degree to which software provides functions that meet stated and implied needs when used under specified conditions. This includes suitability, accuracy, interoperability, security, and functional completeness.
• Reliability: The ability of software to perform its required functions under specified conditions for a specified period without failure. It includes maturity, fault-tolerance, and recoverability.
• Efficiency: The performance relative to the amount of resources used under stated conditions. This covers time behavior (response time, throughput) and resource utilization (CPU, memory, disk).
• Usability: The ease with which users can learn, operate, prepare input to, and interpret output from a system. It involves learnability, operability, user error protection, user interface aesthetics, and accessibility.
• Maintainability: The ease with which a software product can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. It includes modularity, reusability, analyzability, modifiability, and testability.
• Portability: The ease with which a software product can be transferred from one hardware or software environment to another. It involves adaptability, installability, and replaceability.

Software Quality Attributes (ISO 9126 Model)

The ISO/IEC 9126 standard (now superseded by ISO/IEC 25010) defined six main quality characteristics, each with sub-characteristics:

1. Functional Suitability: The degree to which a product or system provides functions that meet stated and implied needs.
2. Reliability: The degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.
3. Performance Efficiency: The performance relative to the amount of resources used.
4. Usability: The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
5. Security: The degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.
6. Maintainability: The degree to which a product or system can be modified by the intended maintainers.
7. Portability: The degree to which a system, product or component can be effectively and efficiently transferred from one hardware, software or other operational or usage environment to another.

Software Process Models

Software process models provide a structured approach to software development, each with its own advantages and suitable use cases.

• Agile Model:
  • Description: An iterative and incremental approach focusing on flexibility, collaboration, and rapid delivery of working software. It emphasizes customer collaboration, responding to change, and frequent feedback.
  • Diagram Concept: Series of short, fixed-length iterations (sprints), each delivering a potentially shippable increment. Each sprint involves planning, design, development, testing, and review.
  • Pros: High customer satisfaction, early and continuous delivery, flexibility to change, better quality through continuous testing.
  • Cons: Can be difficult in large organizations, requires active customer involvement, less documentation.
  • When to Use: Projects with evolving requirements, small to medium-sized teams, projects requiring rapid delivery, and those where customer collaboration is high.
• V-Model:
  • Description: An extension of the Waterfall model where each development phase has a corresponding testing phase. It emphasizes verification and validation activities throughout the lifecycle.
  • Diagram Concept: A V-shape where the left arm represents development phases (requirements, design, coding) and the right arm represents corresponding testing phases (unit, integration, system, acceptance testing).
  • Pros: Highly disciplined, easy to manage, clear verification and validation points, reduces defect injection.
  • Cons: Rigid, less flexible to changes, requires well-defined requirements upfront, delays defect discovery.
  • When to Use: Projects with stable and clear requirements, critical systems (e.g., medical, aerospace) where quality and reliability are paramount.
• Iterative Model:
  • Description: The software is developed in small, repeated cycles (iterations), where each iteration builds upon the previous one, adding functionality incrementally.
  • Diagram Concept: A series of repeating cycles (planning, analysis, design, implementation, testing, evaluation) where each cycle produces a new version of the software with enhanced features.
  • Pros: Accommodates changing requirements, early delivery of some functionality, easier to manage risks.
  • Cons: Requires good planning of iterations, potential for scope creep, high resource consumption in early stages.
  • When to Use: Large and complex projects, projects where initial requirements are not fully defined, projects with long development cycles.
• Prototype Model:
  • Description: A working model (prototype) of the system is built quickly to understand requirements and user expectations, then refined based on feedback.
  • Diagram Concept: Requirements gathering -> Quick Design -> Build Prototype -> Customer Evaluation -> Refine Prototype/Requirements -> Engineer Product.
  • Pros: Reduces risk of incorrect requirements, early user involvement, useful for complex UI/UX.
  • Cons: Can lead to "throwaway" code, users might expect the prototype to be the final product, difficult to manage scope.
  • When to Use: Projects with unclear or ambiguous requirements, projects requiring significant user interaction, where user interface design is critical.
• Big Bang Model:
  • Description: No formal process, planning, or schedule. Developers simply start coding and hope for the best.
  • Diagram Concept: A single, unstructured phase from start to finish.
  • Pros: Very simple for very small, experimental projects.
  • Cons: High risk, no clear path, not suitable for large or complex projects, difficult to manage.
  • When to Use: Extremely small projects with 1-2 developers, academic projects, or projects where requirements are minimal and no formal process is needed.

Computer-Aided Software Engineering (CASE) Tools

CASE tools are software applications that support software development and maintenance activities. They automate various tasks, improving productivity and quality.

• Examples:
  • Requirements Management: Jira, IBM DOORS Next
  • Design & Modeling: Enterprise Architect, Visual Paradigm, Lucidchart
  • Code Generation: Integrated Development Environments (IDEs) like Eclipse, IntelliJ IDEA, Visual Studio
  • Testing: Selenium, JUnit, TestRail
  • Configuration Management: Git, SVN, GitLab, GitHub
  • Project Management: Asana, Trello, Microsoft Project

Functional and Non-Functional Requirements

• Functional Requirements: Describe what the system does. They specify the functions that a system or component must perform.
  • Example: "The system shall allow users to log in with a username and password." "The system shall generate monthly sales reports."
• Non-Functional Requirements (NFRs): Describe how the system performs a function. They specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
  • Types:
    • Performance: How fast or responsive the system is. Example: "The system shall process a transaction within 3 seconds."
    • Security: How well the system protects against unauthorized access or data loss. Example: "User passwords shall be encrypted using AES-256."
    • Usability: How easy the system is to learn and use. Example: "The user interface shall be intuitive and require minimal training."
    • Other types include reliability, scalability, maintainability, portability, etc.

User Requirements, System Requirement, Interface Specification

• User Requirements: Statements in natural language plus diagrams of the services the system is expected to provide and the operational constraints under which it must function. They are written for customers and end-users.
• System Requirements: A more detailed description of the system's functions and services, and operational constraints. They are typically written for developers and are the basis for system design.
• Interface Specification: Details how different components or systems interact. This includes data formats, communication protocols, API definitions, and user interface layouts.

The Software Requirements Document (SRS Format, IEEE Standards)

A Software Requirements Specification (SRS) is a document that completely describes the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software.

• SRS Format (Typical Sections):
  1. Introduction: Purpose, scope, definitions, references, overview.
  2. Overall Description: Product perspective, product functions, user characteristics, general constraints, assumptions, and dependencies.
  3. Specific Requirements: Functional requirements, non-functional requirements (performance, security, usability, etc.), external interface requirements, logical database requirements.
  4. Appendices: Glossary, analysis models (e.g., UML diagrams).
• IEEE Standards: IEEE 830-1998 provides recommended practices for developing software requirements specifications.

Requirements Elicitation and Analysis

• Elicitation: The process of gathering requirements from stakeholders.
  • Interviews: Direct discussions with stakeholders to gather information.
  • Surveys/Questionnaires: Distributing structured questions to a larger group of stakeholders.
  • Observation: Watching users perform their tasks to understand their needs and workflows.
  • Prototyping: Building a preliminary version of the software to demonstrate functionality and gather feedback.
• Analysis: The process of refining and structuring the gathered requirements to detect inconsistencies, omissions, and ambiguities.

Requirements Validation and Management

• Validation: The process of checking that the gathered requirements accurately reflect the customer's needs and that the system built to these requirements will meet the customer's expectations.
  • Methods: Requirements reviews, prototyping, test case generation.
• Management: The process of managing changing requirements during the software development process.
  • Traceability Matrix: A document that links requirements to design, code, and test cases, ensuring that all requirements are implemented and tested.
  • Change Control: A formal process for proposing, evaluating, approving, and tracking changes to requirements.

8.2 Software Design

Software design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements.

Design Process

• Conceptual Design (High-Level Design): Focuses on the overall system architecture, identifying major components, their responsibilities, and how they interact. It defines the system's structure and major subsystems.
• Detailed Design (Low-Level Design): Elaborates on the components identified in conceptual design, specifying their internal structure, algorithms, data structures, and interfaces in detail.

Design Concepts

• Abstraction: The process of hiding the complex reality while exposing only the necessary parts. Example: A car's steering wheel abstracts the complex mechanics of turning the wheels.
• Modularity: The degree to which a system's components can be separated and recombined. A modular system is composed of discrete, independent, and interchangeable parts.
• Encapsulation: The bundling of data with the methods that operate on the data, and restricting direct access to some of an object's components. Example: A class encapsulates its data (attributes) and behavior (methods).
• Coupling: The degree of interdependence between software modules. Low coupling is desirable, meaning modules are relatively independent.
• Cohesion: The degree to which the elements within a module belong together. High cohesion is desirable, meaning a module performs a single, well-defined task.

Design Patterns

Reusable solutions to common problems in software design.

• Singleton: Ensures a class has only one instance and provides a global point of access to it. Example: A configuration manager or a database connection pool.
• Factory: Provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. Example: A factory method to create different types of shapes (circle, square) based on input.
• Observer: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Example: A stock market application where multiple clients observe stock price changes.
• MVC (Model-View-Controller): An architectural pattern that separates an application into three main logical components: the Model (data and business logic), the View (user interface), and the Controller (handles user input).

Design Heuristics

Rules of thumb for good design, often related to modularity.

• Modularity Rules: Strive for high cohesion and low coupling. Hide information (information hiding). Design for reusability. Minimize interfaces between modules.

Architectural Design Decisions

These are fundamental choices about the overall structure and organization of a software system. They include selecting architectural styles, defining major components, and specifying their interactions.

System Organization

• Layered Architecture: Organizes the system into layers, each providing services to the layer above it and using services from the layer below. Example: Presentation, Business Logic, Data Access, Database layers.
• Client-Server Architecture: A distributed application structure that partitions tasks or workloads between service providers (servers) and service requesters (clients).
• Peer-to-Peer (P2P): A distributed application architecture where tasks are partitioned among peers, which are equally privileged, equipotent participants in the application. Example: File sharing networks.

Modular Decomposition Styles

• Sequential Decomposition: Modules are arranged in a sequence, where the output of one module becomes the input of the next.
• Hierarchical Decomposition: Modules are organized in a tree-like structure, with a main module controlling sub-modules. (e.g., top-down design).
• Bus (or Broker) Decomposition: Modules communicate indirectly through a central communication bus or broker, allowing for flexible integration.

Control Styles

• Centralized Control: A single module or component is responsible for controlling the execution flow of the entire system.
• Event-Driven Control: The flow of control is determined by events (e.g., user input, sensor data). Components react to events they are subscribed to.
• Concurrent Control: Multiple activities or processes execute simultaneously, often managed by an operating system or runtime environment.

Reference Architectures

Predefined architectural patterns or templates that provide a common structure for systems within a specific domain or technology. Example: The J2EE (Java EE) architecture for enterprise applications.

Multiprocessor Architecture

In software design, this refers to designing software to effectively utilize systems with multiple processing units (CPUs or cores) through techniques like parallel processing and concurrency.

Client-Server Architectures (Tiers)

• 2-Tier Architecture: Client directly communicates with the database server. Example: Desktop application connecting directly to a database.
• 3-Tier Architecture: Client (presentation tier) communicates with an application server (business logic tier), which in turn communicates with the database server (data tier). This provides better scalability and maintainability.
• N-Tier Architecture (Multi-Tier): Extends the 3-tier model by adding more specialized tiers for specific services, such as a web server, message queue, or security server.

Distributed Object Architectures

Systems where objects are distributed across different machines and communicate with each other over a network. Examples: CORBA (Common Object Request Broker Architecture), Java RMI (Remote Method Invocation).

Inter-Organizational Distributed Computing

Systems that involve computation and data exchange across multiple independent organizations. Examples: Business-to-business (B2B) e-commerce, supply chain management systems using web services or APIs.

Real-Time Software Design

Designing software systems that must respond to events within strict time constraints. Key considerations include predictability, concurrency, and handling of interrupts. Example: Flight control systems, industrial automation.

Component-Based Software Engineering (CBSE)

An approach to software development that relies on the reuse of pre-built, independent, and interchangeable software components.

• Pros: Increased reusability, faster development, reduced cost, improved reliability.
• Cons: Component integration challenges, dependency on third-party vendors, potential for "component bloat."

8.3 Software Testing, Cost Estimation, Quality Management, and Configuration Management

This section covers critical aspects of ensuring software quality, managing development costs, and controlling changes throughout the lifecycle.

Unit Testing

Testing individual components or modules of the software in isolation.

• White-Box Testing (Structural Testing): Tests the internal structure or working of an application.
  • Statement Coverage: Ensures every executable statement in the code is executed at least once.
  • Branch Coverage (Decision Coverage): Ensures every branch (e.g., if-else, loops) in the code is executed at least once, covering both true and false outcomes.
  • Path Coverage: Ensures all independent paths through a program's source code are exercised at least once. This is the most thorough but also the most complex.
• Black-Box Testing (Functional Testing): Tests the functionality of the application without regard to its internal structure.
  • Equivalence Partitioning: Divides input data into partitions of equivalent data, then selects one test case from each partition. Example: For an age input (1-100), partitions could be invalid (<1, >100), valid child (1-12), valid teen (13-19), valid adult (20-64), valid senior (65-100).
  • Boundary Value Analysis: Tests values at the boundaries of valid and invalid partitions. Example: For age 1-100, test 0, 1, 2, 99, 100, 101.

Integration Testing

Testing the interactions between integrated modules or components.

• Top-Down Integration: Modules are integrated from top to bottom, starting with the main control module. Stubs (dummy modules) are used for lower-level modules not yet developed.
• Bottom-Up Integration: Modules are integrated from bottom to top, starting with the lowest-level components. Drivers (dummy programs) are used to call upper-level modules not yet developed.
• Sandwich Integration: A hybrid approach combining top-down and bottom-up strategies, often by integrating critical middle layers first.

System Testing

Testing the complete, integrated system to evaluate its compliance with specified requirements.

• Performance Testing: Evaluates the system's responsiveness, stability, scalability, and resource utilization under various workloads.
• Stress Testing: Puts the system under extreme load to determine its breaking point and how it handles high-stress conditions.
• Security Testing: Verifies that the system protects data and maintains functionality as intended, preventing unauthorized access and data breaches.
• Usability Testing: Evaluates how easy the system is to use, learn, and understand by its target users.

Component Testing

Similar to unit testing, but often refers to testing larger, self-contained components that may have multiple internal units.

Acceptance Testing

Formal testing conducted to determine whether the system satisfies the acceptance criteria and to enable the customer to determine whether to accept the system.

• Alpha Testing: Conducted by internal employees (developers, QA staff) at the development site.
• Beta Testing: Conducted by real users in a real environment outside the development site.

Test Case Design and Test Automation

• Test Case Design: Creating specific inputs, execution conditions, and expected results to verify a particular functionality or path.
• Test Automation: Using software tools to execute tests, compare actual outcomes with predicted outcomes, and report results.
  • Selenium: A suite of tools for automating web browsers, primarily for web application testing.
  • JUnit: A popular open-source framework for writing and running automated unit tests for Java applications.

Metrics for Testing

• Cyclomatic Complexity: A quantitative measure of the number of linearly independent paths through a program's source code. It indicates the complexity of a program and helps identify test cases.
  V(G) = E - N + 2P
  Where:
  • V(G) = Cyclomatic complexity
  • E = Number of edges in the control flow graph
  • N = Number of nodes in the control flow graph
  • P = Number of connected components (exit points, usually 1 for a single program)
• Code Coverage: A measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. Types include statement, branch, and path coverage.

Algorithmic Cost Modeling

Using mathematical formulas to estimate software development costs and effort.

• COCOMO Model (Constructive Cost Model): An algorithmic cost model that estimates software development effort, cost, and schedule.
  Effort = a * (KLOC)^b * EAF
  Where:
  • Effort = Effort in person-months
  • a, b = Constants based on the development mode (organic, semi-detached, embedded)
  • KLOC = Thousands of Lines of Code
  • EAF = Effort Adjustment Factor (based on cost drivers like reliability, complexity, developer capability)

Project Duration and Staffing

• Putnam Model: A software cost estimation model based on the "Norden/Rayleigh curve" which describes the relationship between effort, schedule, and team size. It suggests that effort is distributed in an S-curve over the project's lifetime.

Software Quality Assurance (SQA) Plan

A document that describes the activities and resources required to ensure and maintain software quality. It defines the quality standards, procedures, and responsibilities for a project.

Formal Technical Reviews

Systematic examination of software artifacts (requirements, design, code) by a team of peers to detect and remove defects.

• Walkthrough: An informal review where the author presents the artifact to the team, explaining its logic, and the team asks questions and points out potential issues.
• Inspection: A more formal and structured review process with defined roles, entry/exit criteria, and a checklist-driven examination of the artifact to find defects.
• Technical Review: A general term for a formal or informal review conducted by a team of technical experts to evaluate the technical suitability of a software product.

Formal Approaches to SQA

Rigorous, mathematically-based techniques to ensure software correctness. Examples: Formal methods (e.g., Z notation, VDM), Cleanroom Software Engineering (emphasizes formal specification, statistical quality control, and correctness verification).

Statistical Software Quality Assurance

Involves collecting and analyzing defect data to identify trends, predict future defects, and improve the software process. Example: Defect density analysis, root cause analysis of defects.

A Framework for Software Metrics

A structured approach to defining, collecting, and using software metrics to understand and improve software processes and products. Example: GQM (Goal Question Metric) approach, where specific goals are defined, questions are formulated to achieve those goals, and metrics are identified to answer the questions.

Metrics for Analysis and Design Models

Quantitative measures applied to analysis and design artifacts to assess their quality. Examples:

• Coupling Metrics: Measure the interdependence between modules/classes.
• Cohesion Metrics: Measure the functional relatedness of elements within a module/class.
• Complexity Metrics: (e.g., Cyclomatic Complexity applied to design components).
• Size Metrics: Number of classes, number of attributes per class, number of methods per class.

ISO Standards

• ISO 9001: A generic standard for quality management systems (QMS). It provides a framework for organizations to ensure they consistently provide products and services that meet customer and regulatory requirements.
• ISO/IEC 25010: An international standard that defines a quality model for software products and systems. It outlines seven characteristics of software quality (functional suitability, reliability, performance efficiency, usability, security, maintainability, and portability).

CMMI Levels (1-5)

Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improve their performance. It has five maturity levels:

• Level 1: Initial: Processes are unpredictable, poorly controlled, and reactive.
• Level 2: Managed: Processes are planned, performed, measured, and controlled at the project level.
• Level 3: Defined: Processes are well-characterized and understood, described in standards, procedures, tools, and methods.
• Level 4: Quantitatively Managed: Processes are measured and controlled using statistical and other quantitative techniques.
• Level 5: Optimizing: Focus is on continuous process improvement through incremental and innovative technological improvements.

Configuration Management Planning

The process of planning and defining how software configuration items (code, documents, test cases) will be identified, controlled, and managed throughout the project lifecycle.

Change Management, Version and Release Management

• Change Management: A systematic approach to dealing with changes to the software system, ensuring that all changes are identified, evaluated, approved, implemented, and verified in a controlled manner.
• Version Management: The process of creating and managing different versions of software components and systems. It ensures that changes are tracked, and previous versions can be retrieved.
• Release Management: The process of planning, scheduling, and controlling the movement of releases from development to testing and into the live environment.

CASE Tools for Configuration Management

Tools that automate and facilitate configuration management activities.

• Examples: Git, SVN (Subversion), Microsoft Team Foundation Server (TFS), GitLab, GitHub, Bitbucket.

8.4 Object-Oriented Fundamentals and Analysis

Object-Oriented (OO) approaches focus on modeling real-world entities as objects, encapsulating data and behavior.

Defining Models

• Domain Model: A visual representation of conceptual classes or real-world objects in a domain. It shows the most important concepts in the problem domain and how they relate. (Often represented as a UML class diagram).
• Use Case Model: Describes the functional requirements of a system in terms of use cases and actors. It defines the system's external behavior.

Requirement Process in OO

In OO development, requirements are often captured using use cases, which then drive the identification of objects and their interactions during analysis and design.

Use Cases

• Actors: Entities (human users, external systems) that interact with the system.
• Use Case Diagram: A UML diagram that shows the relationships among actors and use cases.
  • Include Relationship: Represents a mandatory inclusion of one use case's functionality within another. (e.g., "Process Order" includes "Validate Customer").
  • Extend Relationship: Represents an optional extension of a use case's functionality under specific conditions. (e.g., "Process Order" extends "Handle Special Discount").

Object-Oriented Development Cycle (OOA, OOD, OOP)

• OOA (Object-Oriented Analysis): Focuses on understanding the problem domain and defining the requirements by identifying objects, their attributes, and relationships. It results in a conceptual model.
• OOD (Object-Oriented Design): Focuses on creating a solution to the problem identified in OOA. It defines the software objects, their classes, interfaces, and collaborations.
• OOP (Object-Oriented Programming): The implementation phase where the design is translated into executable code using an object-oriented programming language.

Unified Modeling Language (UML) Diagram Types

A standard notation for modeling object-oriented systems.

• Structural Diagrams: Class, Object, Component, Deployment, Package.
• Behavioral Diagrams: Use Case, Activity, State Machine, Sequence, Communication (Collaboration), Interaction Overview, Timing.

Building Conceptual Model (Class Identification)

Identifying potential classes by analyzing the problem statement, often by looking for nouns (people, places, things, events) that are relevant to the system.

Adding Associations and Attributes

Once classes are identified, define the relationships (associations) between them and the relevant data (attributes) each class holds.

Representation of System Behavior

• State Diagrams (State Machine Diagrams): Show the lifecycle of an object, depicting all possible states it can be in and the transitions between those states triggered by events.
• Sequence Diagrams: Illustrate the order of messages exchanged between objects in a specific use case or scenario, showing the time ordering of interactions.
• Activity Diagrams: Model the flow of control or activities in a system, similar to a flowchart, showing the sequence of steps and decision points.

8.5 Object-Oriented Design

This phase transforms the analysis models into a detailed design that can be implemented.

Analysis to Design Transition

The conceptual models from OOA (e.g., domain model, use case model) are refined and elaborated into detailed design models (e.g., detailed class diagrams, interaction diagrams) that include implementation-specific details.

Describing and Elaborating Use Cases (Detailed Use Case Description)

Beyond the basic description, detailed use cases specify pre-conditions, post-conditions, the main flow of events, alternative flows, and exception flows. This level of detail guides design and testing.

Collaboration Diagram (Interaction between Objects)

A UML diagram (now often called Communication Diagram) that shows the interactions between objects as a series of messages, focusing on the structural organization of objects that send and receive messages. It emphasizes how objects are connected.

Objects and Patterns (Design Patterns in OO)

During OOD, designers leverage established design patterns (like Singleton, Factory, Observer, MVC) to solve recurring design problems, leading to more robust, flexible, and maintainable systems.

Determining Visibility (Public, Private, Protected in Design)

Specifying the access level for attributes and methods within a class. This enforces encapsulation and information hiding.

• Public: Accessible from anywhere.
• Private: Accessible only from within the class itself.
• Protected: Accessible from within the class and its subclasses.

Class Diagram

A UML diagram that shows the static structure of a system, depicting classes, their attributes, methods, and relationships.

• Attributes: Data members of a class.
• Methods: Functions or behaviors of a class.
• Relationships:
  • Association: A general relationship between two classes.
  • Aggregation: A "has-a" relationship where one object is part of another, but can exist independently (e.g., a "Department" has "Employees").
  • Composition: A strong "has-a" relationship where the part cannot exist without the whole (e.g., an "Order" has "OrderItems").
  • Generalization (Inheritance): An "is-a" relationship where a subclass inherits from a superclass.
• Multiplicity: Indicates how many instances of one class are associated with instances of another class (e.g., 1..*, 0..1, *).

8.6 Object-Oriented Design Implementation

This final stage involves translating the detailed design into working code.

Programming and Development Process

The actual coding phase, where developers write source code based on the design specifications, adhering to coding standards and best practices.

Mapping Design to Code

Translating the elements of the object-oriented design (classes, attributes, methods, relationships, interactions) into constructs of a chosen programming language.

Creating Class Definitions from Design Class Diagrams

Each class in the design class diagram is translated into a class definition in the programming language, with its specified attributes becoming member variables and methods becoming member functions.

// Example: Mapping a Class Diagram to Java Code
// Design Class: `Customer` with attributes `id` (int), `name` (String) and method `placeOrder()`
public class Customer {
    private int id;
    private String name;

    public Customer(int id, String name) {
        this.id = id;
        this.name = name;
    }

    public int getId() { return id; }
    public String getName() { return name; }

    public void placeOrder() {
        // Implementation for placing an order
        System.out.println(name + " is placing an order.");
    }
}

Creating Methods from Collaboration Diagram

The interactions and messages shown in collaboration (or sequence) diagrams guide the implementation of method bodies. Each message typically corresponds to a method call or an internal operation within a method.

Updating Class Definitions

During implementation, minor refinements or additions to class definitions (e.g., adding helper methods, constructors, getters/setters) might be necessary based on practical coding considerations, while ensuring the core design remains intact.

Classes in Code (Implementation)

The complete set of implemented classes, along with their relationships, forms the executable software system. This involves writing the logic for each method, handling data storage, and integrating with external systems.

Exception and Error Handling in OO

Designing and implementing mechanisms to gracefully handle unexpected events or errors during program execution. In OO languages, this often involves using try-catch blocks, custom exception classes, and designing methods to throw specific exceptions when invalid conditions occur.

// Example: Exception Handling in Java
public void processPayment(double amount) throws InsufficientFundsException {
    if (amount > accountBalance) {
        throw new InsufficientFundsException("Insufficient funds to process payment.");
    }
    // Logic to deduct amount and process payment
    accountBalance -= amount;
    System.out.println("Payment of " + amount + " processed. New balance: " + accountBalance);
}

// Custom Exception Class
class InsufficientFundsException extends Exception {
    public InsufficientFundsException(String message) {
        super(message);
    }
}