The object-oriented design process involves strategizing, outlining, and implementing applications through the use of objects and classes. This methodology aims to increase flexibility and reusability of programs, encouraging modular design and promoting innovation. To better understand how this is accomplished, we will illustrate the object-oriented design process with examples, explaining every step from gathering requirements to creating a class diagram.
1. Gather Requirements
The first step in the object-oriented design process is gathering requirements. This phase decides what the application is required to do and what problem it is trying to solve. The output of this phase is a written, comprehensive document of what the app must do.
Functional and Non-Functional Requirements
Functional requirements specify the features and capabilities of the application. For instance, a healthcare application may be required to display the heart rate and temperature of a patient connected to a patient monitor. Similarly, an e-commerce application may need to allow users to search by product name or category.
Non-functional requirements refer to other elements that define the operation of the system. These can range from performance requirements (how many users the system must support or response times), support requirements (how the system should behave if it fails), security requirements, and compliance with relevant legal regulations. For example, an e-commerce system might need to respond to searches within two seconds, or comply with data privacy regulations.
FURPS+ (Functional, Usability, Reliability, Performance, Supportability, and Design, Implementation, Interface, and Physical requirements) is a model often used to categorize requirements and ensure a comprehensive list is created.
2. Describe the App
After gathering the requirements, the next step involves describing the app in a narrative, conversational language. This description is user-focused, detailing how users will achieve specific goals within the application. The key output of this step is a set of use-cases.
Use-Cases
A use-case is a detailed description of a system’s behavior as it responds to a request that originates from outside of that system. Each use-case is composed of a title (the goal), an actor (the one who desires the goal), and a scenario (how the goal is accomplished).
For example, in an online bookstore, a use-case might have the title “Purchase Books,” with the actor being a “Customer” and the scenario involving the steps the customer takes to search for books, add them to the cart, enter their payment details, and confirm their purchase.
A use-case can also include extensions, which are variations on the scenario. For instance, when a customer tries to purchase a book that is out of stock, the scenario could describe how the system responds to this condition. Preconditions, such as the customer having an account and being logged in, may also be described.
3. Identify the Main Objects
The third step in the process is to identify the main objects, which often become the classes in the final design. This process, called domain modeling, creates a conceptual model of the system that identifies the most critical objects.
For instance, in our online bookstore, we might identify “Customer,” “Book,” “Shopping Cart,” “Order,” and “Payment” as main objects.
These objects can be identified by parsing through the use-cases and underlining the nouns (possible objects). Once a list of candidate objects is compiled, obvious duplicates and attributes are removed, leaving the core objects to be diagrammed, and their relationships outlined. For example, a “Shopping Cart” may contain “Books,” or a “Customer” places an “Order”.
4. Describe the Interactions
Once the objects are identified, the next step is to describe the interactions between these objects. For example, a “Customer” initiates a “Payment” for an “Order”. This step is crucial for understanding the responsibilities of different objects and their behaviors.
A common method for detailing these responsibilities and interactions is through Class-Responsibility-Collaboration (CRC) cards. Each CRC card represents a class and contains information about its responsibilities and its interactions (collaborations) with other classes.
5. Create a Class Diagram
The final step is to create a class diagram that provides a visual representation of the classes, their attributes, operations, and relationships. These diagrams follow Unified Modeling Language (UML) specifications.
In our online bookstore example, a class diagram might include classes such as “Customer,” “Book,” and “Order,” each with their attributes (e.g., name, price, quantity) and operations (e.g., placeOrder(), addToCart()).
The relationships between classes are also illustrated. For instance, an “Order” is placed by a “Customer” and contains “Books”. These relationships can be one-to-one, one-to-many, or many-to-many, as required by the application’s design.
The class diagram serves as a blueprint for the final implementation of the system. It lays out the groundwork for writing the code in an object-oriented language, which, when adhering to these outlined principles and designs, results in a robust, scalable, and efficient system.
Overall, the object-oriented design process is a systematic approach to software development. It focuses on defining clear requirements, understanding user interactions, identifying key classes and their interactions, and then using this information to construct a class diagram. This careful planning and design stage sets the foundation for a successful implementation phase and a high-quality software product.