8.4 Object-Oriented Fundamentals and Analysis

Object-oriented development is a methodology for designing and building software systems using the concept of "objects," which combine data and behavior. This approach emphasizes reusability, modularity, and maintainability. In object-oriented analysis, the focus is on understanding the system requirements and translating them into objects, their interactions, and the system behavior. Below are key components of object-oriented fundamentals and analysis.

1. Defining Models

In object-oriented analysis and design, models are created to represent the system's structure and behavior. These models serve as blueprints for development, helping to visualize and define the system.

  • Conceptual Models: Represent the overall structure and relationships of the system’s objects and their attributes. It provides a high-level overview without focusing on implementation details.

  • Behavioral Models: Focus on how objects interact with one another, describing the flow of data and control within the system.

Models are used to capture and communicate system functionality and ensure that developers and stakeholders understand the system.

2. Requirement Process

The requirement process in object-oriented analysis involves gathering, analyzing, and documenting requirements that the software must fulfill. This process typically includes:

  • Identifying Stakeholders: Recognizing all parties involved in the system's use and design, such as users, developers, and system administrators.

  • Eliciting Requirements: Gathering requirements through interviews, workshops, observations, and existing system analysis.

  • Documenting Requirements: Writing formal requirements specifications that describe the functionality and behavior of the system.

The object-oriented approach uses use cases to represent functional requirements and system behavior.

3. Use Cases

A use case is a description of a system’s behavior in response to external requests. It outlines the interactions between a user (or other system) and the system being developed. Use cases help capture functional requirements in a structured manner.

  • Use Case Diagram: Visualizes the actors (users or systems interacting with the system) and the use cases (functions the system performs in response to actor requests).

  • Use Case Descriptions: Detailed narratives explaining the sequence of events that occur during a use case, including the primary flow and alternative flows of actions.

Use cases help identify the key functionality that needs to be developed and serve as a basis for design.

4. Object-Oriented Development Cycle

The object-oriented development cycle refers to the stages through which the system evolves. The stages in this cycle include:

  • Analysis: Understanding the problem and gathering requirements. Focus on defining the system’s objects, their behaviors, and relationships.

  • Design: Creating a blueprint for the system, including the architecture, classes, methods, and relationships between objects.

  • Implementation: Writing the actual code that defines the objects, their attributes, and behaviors.

  • Testing: Verifying that the system functions as expected and meets the requirements defined during the analysis phase.

  • Maintenance: Updating the system after deployment to fix defects, improve performance, and add new features.

The iterative nature of the object-oriented development cycle allows for flexibility in addressing evolving requirements.

5. Unified Modeling Language (UML)

UML (Unified Modeling Language) is a standard graphical notation used to specify, visualize, construct, and document the design of object-oriented systems. UML provides a set of diagrams that help developers and stakeholders understand the system from different perspectives, such as structure, behavior, and interactions. It's widely used for software development, particularly for object-oriented design, and provides a common language for representing complex systems.

UML Diagrams

Unified Modeling Language (UML) includes various diagrams to model software systems, each designed to focus on different aspects of the system. These diagrams are grouped into Structural Diagrams and Behavioral Diagrams, serving distinct purposes in software design.

1. Structural Diagrams:

Structural diagrams focus on the static structure of a system, including its components, relationships, and organization. These diagrams answer the question: What is the system made of?

  • Component Diagram: Represents physical components and their interdependencies.

  • Class Diagram: Models the classes, their attributes, methods, and relationships.

  • Deployment Diagram: Visualizes hardware nodes and software deployment.

  • Object Diagram: Provides a snapshot of object instances and their relationships at a specific time.

  • Package Diagram: Organizes model elements into groups for better structure.

  • Composite Structure Diagram: Shows the internal structure of a class or component, including its parts and relationships.

  • Profile Diagram: Extends UML by defining custom stereotypes, tagged values, and constraints for specific domains.

2. Behavioral Diagrams:

Behavioral diagrams focus on the dynamic behavior of a system, including how components interact, processes flow, and the system evolves over time. They answer: How does the system behave?

  • Use Case Diagram

    • Purpose: Models the functional requirements of a system and interactions between external actors (users or systems) and the system itself.

    • Use: Captures high-level functionality and actors involved.

  • State Machine Diagram

    • Purpose: Describes the states of an object and transitions triggered by events.

    • Use: Useful for modeling object lifecycles or event-driven systems.

  • Activity Diagram

    • Purpose: Represents workflows or business processes using actions, decisions, and control flows.

    • Use: Visualizes step-by-step activities and decision points.

  • Interaction Diagrams

    Interaction diagrams depict communication and sequence of interactions among objects. These include:

    • Sequence Diagram

      • Purpose: Displays the order of messages exchanged between objects over time.

      • Use: Shows object interactions in a time-ordered sequence.

    • Communication Diagram (formerly Collaboration Diagram)

      • Purpose: Focuses on the relationships between objects and their interactions.

      • Use: Highlights the structure of communication over time.

    • Timing Diagram

      • Purpose: Depicts state changes or conditions of objects/events over a timeline.

      • Use: Analyzes real-time system behavior.

    • Interaction Overview Diagram

      • Purpose: Combines elements of activity and interaction diagrams to show control flow and sequence interactions in a broader context.

      • Use: Provides a high-level overview of interaction logic.

By categorizing diagrams into Structural and Behavioral, UML provides a comprehensive way to model both the architecture and functionality of a system.

Class Diagram (Structural Diagram)

  • Purpose: A class diagram represents the static structure of the system. It shows the classes, their attributes, methods, and the relationships between the classes (e.g., inheritance, associations, etc.).

  • Example:

    +-------------------+
|    Person         |
+-------------------+
| - name: string    |
| - age: int        |
+-------------------+
| + speak(): void   |
| + walk(): void    |
+-------------------+

  • Components:

    • Class:

      • A class is a blueprint for creating objects, specifying what attributes (data) and methods (functions) the objects of that class will have.

      • A class is represented as a rectangle divided into three horizontal sections:

        • Top Section: Contains the name of the class.

        • Middle Section: Lists the attributes (properties/data) of the class.

        • Bottom Section: Contains the methods (functions) of the class.

    • Methods: speak() and walk().

      Methods (or functions) define the behavior of the class. They operate on the class's data and can perform actions, calculations, or interact with other objects.

      • Methods are listed in the bottom section of the class.

      • The format for defining a method is: visibility name(parameters): return_type.

        • Visibility: Similar to attributes, it defines the access level of the method.

        • Name: The name of the method.

        • Parameters: Any inputs that the method may accept.

        • Return Type: The type of value the method will return (e.g., void for no return value).

    • Attributes: name and age

      • Attributes are the characteristics or properties of a class. They define the state of an object.

      • They are listed in the middle section of the class rectangle.

      • The format for defining an attribute is: visibility name: type, where:

        • Visibility: Indicates the access level (+ for public, - for private, # for protected).

        • Name: The name of the attribute.

        • Type: The data type of the attribute (e.g., int, string, float).

    • Relationships: Relationships between classes are represented using lines and arrows:

      • Inheritance (generalisation): An open triangle at the parent class. This shows that the subclasses are specialisations of the parent class - they extend the parent class.

      • Implementation (realisation or execution): A dashed line with an open triangle at the blueprint class. This is used where a class implements the functionality of a ‘blueprint’ class, and may be implemented differently depending on each class that implements it.

      • Dependency: A dashed line with an open arrow. If the definition of class 2 changes, it will change class 1, but not the other way around (depends on).

      • Association: A solid line between two classes. Add arrows at either end or both ends to show that the classes are aware (or unaware) of each other.

      • Aggregation: An open diamond at class 1. A special type of association that shows that class 2 is a part of class 1.

      • Composition: A solid diamond at class 1. A special type of aggregation that shows that class 2 can not exist without class 1.

    • Common Multiplicity Notations

      In UML Class Diagrams, notations like 0..1, 1, 0..*, and others represent multiplicities. These specify how many instances of one class can be associated with instances of another class in a relationship. Here's what they mean:

      • 0..1 (Zero or One)

        • Meaning: An instance of a class can be associated with zero or one instance of the related class.

        • Example: A "Person" can have zero or one "Spouse".

        • (Exactly One)

          • Meaning: An instance of a class must be associated with exactly one instance of the related class.

          • Example: A "Car" must have exactly one "Engine".

      • 0..* or * (Zero or More)

        • Meaning: An instance of a class can be associated with zero or more instances of the related class (no upper limit).

        • Example: A "Library" can have zero or more "Books".

      • 1..* (One or More)

        • Meaning: An instance of a class must be associated with at least one, but possibly more, instances of the related class.

        • Example: An "Order" must have one or more "Items".

      • Specific Ranges (e.g., 2..4)

        • Meaning: An instance of a class can be associated with a minimum of 2 and a maximum of 4 instances of the related class.

        • Example: A "Team" must have between 2 and 4 "Players".

  • Example

Use Case Diagram (Behavioral Diagram)

  • Purpose: A use case diagram depicts the interactions between actors (users or other systems) and the system, illustrating the system’s functionality from the user's perspective.

  • Example:

  • In this example, the Customer can interact with the system to View Items, Make Purchase, Complete & Checkout, Login.

  • Components:

    • Actor: An entity that interacts with the system (e.g., a user or another system). Represented as a stick figure.

      • Example: In an Online Shopping System, typical actors could include a Customer, PayPal and other service provider.

    • Use Case: A specific action or task that the system performs, represented as an oval.

      • Example: In an Online Shopping System, common use cases could include View Items, Make Purchase, Complete & Checkout, Login.

    • System Boundary: Defines the scope of the system, represented as a rectangle enclosing use case.

      • Example: The Online Shopping System, system boundary will enclose use cases to show these are functionalities provided by the system.

    • Relationships:

      • Association: A line connecting an actor to a use case, indicating that the actor participates in that use case.

        • Example: If the Customer browses the catalog, there will be an association between the Customer actor and the Login use case.

      • Include: A relationship where one use case always includes the functionality of another.

        • Example: In a Complete Checkout use case, you may always include the Make Purchase use case. Every time a user checks out, payment is processed as part of that flow.

      • Extend: A relationship where one use case may extend the behavior of another under certain conditions.

        • Example: For a Complete Checkout use case, there may be an Apply Discount use case that extends the Complete Checkout process if certain conditions (e.g., promo code or sale) are met.

Sequence Diagram (Behavioral Diagram)

  • Purpose: A sequence diagram shows how objects interact in a particular sequence to accomplish a specific use case or functionality. It highlights the order of messages exchanged between objects over time.

  • Example:

    In the example, the Customer interacts with the Online Store to browse and add items to the cart, and then proceeds to the Payment Gateway to complete the purchase.

  • Components:

    • Objects:

      • Definition: These are the entities that interact with each other during the process.

        • Example: In an online store system, objects could include Customer, Online Store, and Payment Gateway.

    • Messages:

      • Definition: These represent the communication or interactions between objects.

        • Example: The Customer sends a message to the Online Store to Browse Catalog.

    • Lifelines:

      • Definition: These are vertical dashed lines that represent the existence of an object during the interaction. They indicate the time span an object remains active and involved in the process.

    • Activation Boxes:

      • Definition: These rectangular boxes on a lifeline represent when an object is actively performing a process or handling a task.

State Diagram (Behavioral Diagram)

  • Purpose: A state diagram represents the different states an object can be in and the transitions between those states in response to events. It's used to describe the lifecycle of an object.

  • Example:

    Consider a state diagram for an order processing system:

      +---------------------+   Payment Received   +----------------------+
  |     Order Placed    | -------------------> |   Payment Processed   |
  +---------------------+                       +----------------------+
           |
           | Order Shipped
           v
  +---------------------+   Order Delivered   +----------------------+
  |     Shipped         | -------------------> |     Delivered         |
  +---------------------+                       +----------------------+

  • Components:

    • States:

      • Definition: States represent the different conditions or statuses of an object during its lifecycle.

        • Example: For an order processing system, states might include:

          • "Order Placed"

            • "Payment Processed"

            • "Shipped"

            • "Delivered"

    • Transitions:

      • Definition: Transitions represent the change from one state to another in response to an event or condition.

        • Example: The transition might occur from "Order Placed" to "Payment Processed" when a payment event occurs.

    • Events:

      • Definition: Events are actions or conditions that trigger the transition of an object from one state to another.

        • Example: "Payment Received" might be an event that triggers a transition from "Order Placed" to "Payment Processed.

Activity Diagram (Behavioral Diagram)

  • Purpose: An activity diagram describes the flow of control or data in a system, particularly for processes and workflows. It is often used to model business processes or workflows.

  • Example:

      +-------------+      Payment Failed     +---------------+
  |  Waiting    | ----------------------> |   Failed      |
  | for Payment |                         | Payment       |
  +-------------+                         +---------------+
        |
        | Payment Received
        v
  +---------------+
  |  Payment      |
  |  Successful   |
  +---------------+

    In this example, the payment process can have three states: Waiting for Payment, Failed Payment, and Payment Successful. The object moves between these states based on events like receiving or failing to process payment.

  • Components:

    • Activities:

      • Definition: Activities represent tasks or actions that are performed as part of the workflow.

        • Example: "Waiting for Payment," "Payment Received," "Failed Payment," "Payment Successful."

    • Transitions:

      • Definition: Transitions represent the flow of control or data between activities.

        • Example: An arrow from "Waiting for Payment" to "Payment Received" shows the process flow when a payment is received.

    • Decision Nodes:

      • Definition: A decision node represents a branch point in the flow where the process chooses one of several paths based on a condition.

        • Example: After "Payment Received," the system checks if the payment is successful. If it is, the flow moves to "Payment Successful"; otherwise, it goes to "Failed Payment."

    • Forks and Joins:

      • Definition: Forks and joins represent the splitting and merging of flow when activities happen in parallel.

      • Fork: Splits the flow into multiple parallel flows.

      • Join: Merges multiple flows back into a single flow.

        • Example: If there are multiple actions (like sending an email, updating database records, and generating a report), the activity diagram will use a fork to split the flow, and a join to merge them after all actions are completed.

  • Example

Summary:

UML provides a variety of diagrams to model a system from different perspectives, helping to define the structure and behavior of objects, how they interact, and how processes flow. These diagrams serve as effective communication tools for stakeholders, ensuring that the system's design is well-documented and easy to understand for developers, managers, and clients alike.

  • Class Diagram: Defines the static structure of the system.

  • Use Case Diagram: Shows user-system interactions.

  • Sequence Diagram: Illustrates how objects interact over time.

  • State Diagram: Models object states and transitions.

  • Activity Diagram: Describes workflows and processes.

Together, these diagrams provide a comprehensive view of the system, helping to facilitate clear understanding and effective communication throughout the development lifecycle.

6. Building a Conceptual Model

Conceptual modeling is a key step in object-oriented analysis. It identifies core objects, relationships, and attributes that represent the system's functionality, linking requirements to a real-world representation.

1. Identifying Key Objects

  • Objects are derived from the system’s requirements and represent entities or concepts in the real world.

  • Objects are identified based on their relevance to the system's behavior and functionality.

Example: In a university management system:

  • Objects may include Student, Course, and Instructor.

2. Defining Relationships (Associations)

  • Relationships between objects represent how entities interact within the system. These can be categorized as:

    • Aggregation:

      • Represents a "whole-part" relationship where the part can exist independently of the whole.

      • Example: A Department contains multiple Employee objects, but an Employee can exist without a specific Department.

    • Inheritance:

      • Represents an "is-a" relationship where a child object inherits properties and behaviors from a parent object.

      • Promotes reusability and polymorphism.

      • Example: A Student "is-a" Person, inheriting attributes like name and age, while adding specialized behaviors.

    • Dependency:

      • Indicates that one object depends on another for functionality.

      • Example: A Car depends on an Engine to function, but the Engine can exist independently of a specific Car.

3. Adding Attributes

  • Attributes represent the properties or data associated with an object. These describe the object's characteristics and define its state.

  • Each object typically has attributes that align with its real-world properties.

Example: For a Person object:

  • Attributes may include:

    • name: The person’s full name.

    • age: The person’s age.

    • address: The person’s home address.

4. Refining Objects and Behaviors

Attributes and methods are refined to meet requirements and clarify object interactions. Example:

  • Book:

    • Behavior: checkAvailability() returns whether the book is available.

  • Loan:

    • Behavior: calculateDueDate() computes the due date for a borrowed book.

  • Member:

    • Behavior: borrowBook(Book) ensures only available books can be borrowed.

By combining objects, associations, attributes & refining the behaviours, the conceptual model provides a detailed representation of the system, forming the basis for design and development.

Conclusion

Object-oriented fundamentals and analysis provide the foundation for building modular, reusable, and maintainable systems. By defining clear models, using use cases, and utilizing UML diagrams, developers can structure and organize complex systems effectively. The object-oriented development cycle ensures that the system evolves through well-defined stages, while building a conceptual model and representing system behavior help communicate design decisions and ensure alignment with requirements.

Previous8.3 Software Testing, Cost Estimation, Quality Management, and Configuration ManagementNext8.5 Object-Oriented Design

Last updated