Object-Oriented Software Engineering: Reuse, Architectures, and Quality

Fundamentals of Software Engineering and Quality

• The Nature of Software:

  • Intangibility: Software lacks physical properties, making progress and complexity difficult to visualize directly.

  • Cost Structure: The vast majority of cost resides in development rather than production; reproducing software is virtually free compared to traditional manufactured engineering products.

  • Labor-Intensive: Development depends heavily on human effort and remains resistant to complete automation.

  • Deterioration vs. Wear: Software does not undergo physical wear and tear. Instead, it deteriorates over time through unexpected, uncoordinated, or poorly executed modifications that increase structural complexity and introduce bugs.

  • Quality Visibility: Poor design can easily be masked in the short term because software can be patched together by untrained individuals, but long-term quality degradation inevitably causes failure.

• Defining Software Engineering:

  • Definition: Software engineering is the process of solving customers' problems by the systematic development and evolution of large, high-quality software systems within cost, time, and other constraints.

  • Solving Customer Problems: The primary objective is solving real user problems. Purchasing commercial software or avoiding unnecessary feature bloat is often preferable to custom development.

  • Systematic Development & Evolution: Engineering applies disciplined, standardized techniques (such as those codified by IEEE or ISO). Most software work involves evolving existing systems rather than building new ones.

  • Large-Scale Systems: Software engineering techniques are necessary because large systems exceed the capacity of a single mind to understand entirely, necessitating structured teamwork, domain breakdown, and subsystem integration.

  • Constraints: Real-world projects operate under finite budgets, strict time limits, and competitive market conditions, making accurate cost and schedule estimations critical.

• The Software Engineering Profession and Ethics:

  • The term Software Engineering was coined in 1968 to promote the application of formal engineering disciplines to software creation.

  • Engineering is typically a licensed profession designed to protect public safety and welfare by requiring adherence to scientific, mathematical, and economic principles.

  • The 8 Tenets of the Software Engineering Code of Ethics:

    1. Public Interest: Act consistently with the public interest.

    2. Client and Employer: Act in the best interests of the client and employer, consistent with public interest.

    3. Product: Ensure products meet the highest professional standards possible.

    4. Judgment: Maintain integrity and independence in professional judgment.

    5. Management: Promote an ethical approach to software development management.

    6. Profession: Advance the integrity and reputation of the profession.

    7. Colleagues: Be fair to and supportive of colleagues.

    8. Self: Participate in lifelong learning regarding the practice of the profession.

Software Quality Dimensions, Stakeholders, and Activities

• Dimensions of Software Quality:

  • Usability: The ease with which end-users can learn, operate, and accomplish tasks using the software.

  • Efficiency: The optimal utilization of system hardware resources, such as CPU processing cycles and memory allocation.

  • Reliability: The ability of the software to perform its required functions correctly without crashing or generating errors.

  • Maintainability: The ease with which software can be updated, bug-fixed, or restructured.

  • Reusability: The extent to which software components can be repurposed across other projects without redevelopment.

• Stakeholder Quality Perspectives:

*   **Developer**: Prioritizes clean design, ease of maintenance, and component reusability.
*   **User**: Prioritizes ease of learning, operational efficiency, and task assistance.
*   **Customer (Payer)**: Focuses on cost-effective problem resolution relative to money paid and resources consumed.
*   **Development Manager**: Focuses on customer satisfaction, sales potential, and minimizing development and maintenance expenditures.

• Quality Conflicts and Trade-Offs:

  • Quality goals frequently conflict with one another: increasing runtime efficiency can diminish maintainability or reusability; maximizing usability features can increase resource consumption and decrease efficiency.

  • Software engineers must establish explicit quality trade-off objectives early in development to avoid over-engineering.

• Software Project Types:

  • Evolutionary / Maintenance Projects (Majority of industry work):

    • Corrective: Fixing defects and system bugs.

    • Adaptive: Updating software to accommodate external changes in operating systems, databases, or regulations.

    • Enhancement: Developing new functionality and user features.

    • Reengineering / Perfective: Restructuring system interiors to enhance maintainability without altering external behavior.

  • Green-Field Projects (Minority of industry work): Building completely new systems from scratch without legacy constraints.

• Common Software Project Activities:

  • Requirements and Specification: Domain analysis, problem definition, requirements gathering from diverse sources, requirements analysis, and formal requirements specification writing.

  • Design: Systems engineering (hardware vs. software allocation), software architecture (subsystem breakdown and communication interfaces), detailed internal design, user interface (UI) design, and database schema design.

  • Modeling: Creating use case, structural, dynamic, and behavioral models.

  • Programming: Implementing source code using designated programming languages.

  • Quality Assurance: Code inspections, peer reviews, and systematic software testing.

  • Deployment: Packaging, distributing, and installing software systems.

  • Process Management: Steering project resource allocation, timelines, and personnel.

Object-Oriented Software Development Principles

• Procedural vs. Object-Oriented Paradigm:

  • Procedural Paradigm: Software is organized around procedures and functions operating on simple data structures. Abstraction is centered strictly on processing steps.

  • Object-Oriented (OO) Paradigm: Groups procedural abstractions inside data abstractions. Computations are executed through collaborating object instances.

• Classes and Objects:

  • Object: An instance of structured data in a running software system containing properties (state) and behavior (actions and reactions).

  • Class: A software abstraction unit representing similar objects. Defines instance structures (properties) and methods (behavior).

  • Class vs. Instance Decision Examples:

    • Film: Class (instances are individual movie titles).

    • ReelOfFilm: Class (instances are physical film spools).

    • Film reel with serial number SW19876: Instance of ReelOfFilm.

    • Science Fiction: Instance of Genre.

    • Science Fiction Film: Class (instances include Star Wars).

    • Showing of 'Star Wars' in the Phoenix Cinema at 7 p.m.: Instance of ShowingOfFilm.

  • Class Naming Conventions: Capitalized camel case (e.g., BankAccount), singular nouns, appropriate level of generality (e.g., Municipality instead of City), and unambiguous terms.

• UML Instance Diagrams:

*   Instance diagrams represent runtime snapshots. Object titles are underlined (`name:Class`).
*   Examples from instance models:
    *   `Jane:` (`dateOfBirth="1955/02/02"`, `address="99 UML St."`, `position="Manager"`).
    *   `Greg:` (`dateOfBirth="1970/01/01"`, `address="75 Object Dr."`).
    *   `Margaret:` (`dateOfBirth="1984/03/03"`, `address="150 C++ Rd."`, `position="Teller"`).
    *   `Savings account 12876:` (`balance=1976.32`, `opened="1999/03/03"`).
    *   `Mortgage account 29865:` (`balance=198760.00`, `opened="2003/08/12"`, `property="75 Object Dr."`).
    *   `Instant teller 876:` (`location="Java Valley Cafe"`).
    *   `Transaction 487:` (`amount=200.00`, `time="2001/09/01 14:30"`).

• Variables:

  • Instance Variables: Fields stored inside each object instance. Divided into Attributes (simple values like name) and Associations (links to other class instances like supervisor).

  • Variables vs. Objects: A variable holds a reference to an object. Multiple variables can reference the exact same object simultaneously.

  • Class Variables (Static Variables): Shared values across all instances of a class. Used for default/constant values (e.g., \r\n    \pi) or shared lookup tables. Overusing class variables undermines object-oriented design.

Object Hierarchy, Polymorphism, and Advanced OO Concepts

• Operations, Methods, and Polymorphism:

  • Operation: A high-level procedural abstraction specifying a type of behavior independent of implementation details (e.g., area calculation).

  • Method: The concrete implementation of an operation within a specific class.

  • Polymorphism: The mechanism by which an abstract operation executes different concrete methods depending on the runtime class of the target object, eliminating excessive if-else or switch statements.

• Inheritance Hierarchies & The "Isa Rule":

  • Superclasses consolidate common features. Subclasses implicitly inherit all features of their parent superclasses.

  • The Isa Rule: Every generalization relationship must satisfy the "isa rule" (e.g., "A checking account is an account" is valid; "A province is a country" is invalid and violates generalization rules).

• Abstract Classes and Method Overriding:

  • Abstract Operations & Classes: Declared at the highest applicable hierarchy level. If an operation lacks implementation, it is abstract, making the class abstract (cannot be instantiated). Leaf classes in an inheritance tree must be concrete and implement all inherited abstract operations.

  • Method Overriding: Subclasses replace inherited superclass methods for:

    • Extension: Adding behavior (e.g., SavingsAccount charging extra fees on debit operations).

    • Optimization: Substituting an efficient algorithm (e.g., simple getPerimeterLength() in Circle vs. complex formula in Ellipse).

    • Restriction: Restricting behavior (should generally be avoided).

  • Method Resolution Algorithm:

    1. Check for a concrete method implementation in the instance's class.

    2. If missing, check the immediate superclass.

    3. Repeat up the hierarchy until a concrete method is located.

    4. If no concrete method is found, raise a compilation or runtime error.

  • Dynamic Binding: The runtime decision determining which specific polymorphic method to execute based on the actual object stored in a variable.

• Key OO Terminology:

  • Abstraction: Mapping real-world objects to code entities, objects to classes, subclasses to superclasses, and methods to operations.

  • Modularity: Partitioning code into discrete classes and methods.

  • Encapsulation: Grouping data and behavioral logic inside class boundaries.

  • Information Hiding: Concealing implementation details behind public interfaces.

Core Java Programming Mechanics

• Historical Evolution of Java:

  • Simula-67: First object-oriented programming language, created for simulation systems.

  • Smalltalk (Xerox PARC, early 1980s): Introduced modern OO syntax, bytecode, platform independence via virtual machines, and garbage collection.

  • C++ (Bjarne Stroustrup, late 1980s): Integrated OO features into C.

  • Oak / Java (Sun Microsystems, 1991–1995): Originally named Oak for embedded consumer smart devices; rebranded as Java and launched at SunWorld '95 for web development.

• Core Java Language Constructs:

  • Documentation: API documentation generated automatically from code comments via Javadoc (supports embedded HTML).

  • Data Types: Primitive char represents single multi-byte Unicode characters; Character is its object wrapper; String stores character sequences with + overload for string concatenation.

  • Collections: Arrays are fixed-length structures. ArrayList provides dynamic resizing. Traversals use Iterator (hasNext(), next()); Enumeration was used previously.

  • Casting & Generics: Explicit casting e.g. (String)i.next() converts superclass references to subclass types. Generics eliminate casting e.g., ArrayList<String>.

  • Exceptions: Runtime errors raise instances of Exception. Structured handling uses try-catch blocks (e.g., catching ArithmeticException).

  • Interfaces: Pure abstract protocols containing no method implementations or instance fields. Classes can implement multiple interfaces (e.g., Runnable, Collection, Iterator, Comparable, Cloneable).

  • Packages & Visibility Modifiers:

    • public: Accessible by any class.

    • protected: Accessible within package and by subclasses.

    • (package-default): Accessible only within package.

    • private: Accessible only inside defining class.

  • Threads & Concurrency: Created by implementing Runnable or extending Thread, defining run(), and invoking start().

• Programming Style Guidelines:

  • Prioritize clarity and readability over clever or compact code.

  • Use descriptive, self-documenting variable and class names.

  • Maintain 25% to 50% comment density explaining non-obvious logic.

  • Organize classes consistently: variables, constructors, public methods, private methods.

  • Avoid code duplication (cloning); extract shared logic into methods.

  • Decouple user interface (UI) components strictly from non-UI domain business logic.

Reusable Technology, Frameworks, and Product Lines

• Levels of Software Reuse:

  1. Reuse of developer expertise.

  2. Reuse of standard software designs and algorithms.

  3. Reuse of procedure and class libraries.

  4. Reuse of language and OS built-in commands.

  5. Reuse of software frameworks.

  6. Reuse of fully realized applications.

• Framework Architecture:

  • Definition: A framework is reusable software that implements a generic solution to a generalized problem, serving as an incomplete foundation for complete applications.

  • Slots: Mandatory abstract methods or missing classes that application developers must implement to complete framework execution.

  • Hooks (Extension Points): Optional methods provided by the framework that developers can override to customize standard processing.

  • Application Programming Interface (API): The complete set of public methods provided by the framework classes to external application code.

• Product Lines and Framework Categorization:

  • Product Line (Product Family): A group of software products derived from a common framework base, configured via hooks and slots to target distinct markets (e.g., 'demo', 'lite', and 'pro' editions).

  • Horizontal Framework: Provides generic, domain-agnostic facilities usable across many application categories.

  • Vertical Framework (Application Framework): Provides domain-specific architectures tailored to a particular business area.

Client-Server Architecture and Distributed Systems

• Distributed Systems Concepts:

  • Distributed System: System where computations run across distinct software programs on separate hardware units connected over a network.

  • Server: Program listening on a communication channel to deliver services to connecting client applications.

  • Client: Program connecting to remote servers to access provided services.

  • Examples: World Wide Web (WWW), Email, Network File System (NFS), Transaction Processing Systems, Remote Display Systems, Communication Systems, Database Systems.

• Client-Server Behavioral Models:

• Thin-Client vs. Fat-Client Systems:

*   **Thin-Client**: Client application is minimal; computation occurs primarily on the server. Facilitates light network downloads.
*   **Fat-Client**: Workload is delegated primarily to client machines. Minimizes server processing requirements, enabling servers to support higher client concurrency.

• Communications Protocols & Client-Server Benefits:

  • Protocol: Rules and structured messaging languages used by clients and servers to communicate.

  • Key System Advantages: Work workload distribution across hardware, remote capability access, independent client/server development, flexible data centralization vs. distribution, concurrent server access, and client interoperability.

Low-Level Network Implementation in Java

• Networking Stack Constructs:

  • IP (Internet Protocol): Handshake-less packet routing protocol between nodes across networks. Splits large payloads into smaller data packets. Nodes are specified by Host Name and IP Address.

  • TCP (Transmission Control Protocol): Connection-oriented transport protocol running over IP ensuring ordered, reliable message delivery.

  • Ports: Identifiers ranging from $0$ to $65535$. Allows multiple server programs to co-exist on a single host machine. Clients require host name and port number to establish a connection.

• Java Sockets and Stream Operations:

  • java.net API:

    • Server initialization: ServerSocket serverSocket = new ServerSocket(port); followed by Socket clientSocket = serverSocket.accept();

    • Client connection request: Socket clientSocket = new Socket(host, port);

  • java.io Input/Output Streams:

    • Stream binding: output = clientSocket.getOutputStream(); and input = clientSocket.getInputStream();

    • Raw Byte I/O: output.write(msg); / msg = input.read();

    • Data Filter I/O: DataInputStream / DataOutputStream using output.writeDouble(msg); / msg = input.readDouble();

    • Object Filter I/O: ObjectInputStream / ObjectOutputStream using output.writeObject(msg); / msg = input.readObject();

The Object Client-Server Framework (OCSF)

• Architectural Overview:

  • OCSF contains three core classes: AbstractClient, AbstractServer, and ConnectionToClient. Developers using OCSF never modify these core classes directly. Developers create subclasses, call public controller methods, and override hook/slot methods.

• Client Architecture (AbstractClient):

  • Implements Runnable and executes an internal message-listening loop in its run() method.

  • Public Control Methods: openConnection(), closeConnection(), sendToServer().

  • Public Accessor Methods: isConnected(), getHost(), setHost(), getPort(), setPort(), getInetAddress().

  • Callback Methods: connectionEstablished(), connectionClosed(), connectionException() (optional hooks); handleMessageFromServer(Object msg) (mandatory slot).

  • Internal State: Manages a Socket, ObjectOutputStream, ObjectInputStream, Thread, host name, and port number.

• Server Architecture (AbstractServer & ConnectionToClient):

  • AbstractServer:

    • Public Control Methods: listen(), stopListening(), close(), sendToAllClients().

    • Public Accessor Methods: isListening(), getClientConnections(), getPort(), setPort(), setBacklog().

    • Callback Methods: serverStarted(), clientConnected(), clientDisconnected(), clientException(), serverStopped(), listeningException(), serverClosed() (optional hooks); handleMessageFromClient(Object msg, ConnectionToClient client) (mandatory slot).

  • ConnectionToClient:

    • Represents client connection socket threads on the server side.

    • Public Control Methods: sendToClient(), close().

    • Public Accessor Methods: getInetAddress(), setInfo(String key, Object info), getInfo(String key).

  • Internal Server Mechanics: Uses HashMap inside ConnectionToClient for arbitrary data storage; uses synchronized methods for thread safety; uses ThreadGroup to manage instances of ConnectionToClient; pauses socket listening every $500\,\text{ms}$ to check if stopListening() has been called.

SimpleChat: Case Study of an Instant Messaging Application

• Server Implementation (EchoServer):

  • Extends AbstractServer.

  • The main() method initializes the server and invokes listen().

  • Implements handleMessageFromClient() to log incoming messages and echo them to all connected clients:

public void handleMessageFromClient(Object msg, ConnectionToClient client) {
  System.out.println("Message received: " + msg + " from " + client);
  this.sendToAllClients(msg);
}

• Client Implementation (ChatClient, ClientConsole, ChatIF):

  • ChatClient extends AbstractClient and implements handleMessageFromServer() by passing messages to the user interface:

public void handleMessageFromServer(Object msg) {
  clientUI.display(msg.toString());
}

*   `ChatIF` is an interface defining `display(String message)`.
*   `ClientConsole` implements `ChatIF` to provide a terminal interface, accepts keyboard input via `accept()`, and routes messages to `ChatClient` via `handleMessageFromClientUI()`:

public void handleMessageFromClientUI(String message) {
  try {
    sendToServer(message);
  } catch(IOException e) {
    clientUI.display("Could not send message. Terminating client.");
    quit();
  }
}

Engineering Risks in Software Reuse and Distributed Architectures

• Risks When Reusing Software:

  • Low-Quality Components: Reused code may contain hidden defects. Mitigate by verifying that component developers followed disciplined engineering practices and offer active support.

  • Breaking Compatibility: Dependency updates may break interfaces. Mitigate by avoiding obscure library features and adopting standard technologies.

• Risks When Developing Reusable Components:

  • Investment Uncertainty: Developing generic software requires upfront financial expenditure. Mitigate by treating reusable software development with formal project management processes.

  • Not-Invented-Here Syndrome: Developers may resist using external components. Mitigate by providing robust support, high quality, and responsiveness to user feedback.

  • Feature Divergence: Custom branches can fragment technology. Mitigate through advance general design, thorough testing, and code reviews.

• Risks in Distributed Client-Server Systems:

  • Security Vulnerabilities: Remote network access increases exposure to attack. Mitigate through encryption, firewalls, and authorization frameworks.

  • Adaptive Maintenance Issues: Client and server deployments evolve independently. Mitigate by enforcing strict forward and backward protocol compatibility across releases.