Chapter #1 Object-Oriented Analysis and Design — Software Design and Architecture Specialization University of Alberta
Object-Oriented Thinking
Object-oriented thinking involves dissecting problems and concepts into component parts, viewing them as distinct objects. This approach, applicable beyond software development, aids in creating organized, flexible, and reusable code. Objects represent various entities, possessing specific attributes and behaviors, such as a person with details like name and occupation, or an electronic device responsible for powering on or off. Objects encapsulate their own details, fostering organized code. They enable flexibility, facilitating modular changes without affecting the rest of the code, and promote reusability, reducing the need for redundant code. In this paradigm, all entities, animate or inanimate, are treated as objects, and even inanimate objects possess self-awareness within the software. Practicing object-oriented thinking involves habituating oneself to conceptualizing the world in terms of objects and their associated attributes.
Design in the Software Process
In the software development process, a crucial aspect involves a systematic approach that follows iterative steps, converting a problem into a software-based solution. This approach typically includes understanding and defining requirements, creating conceptual design mock-ups and technical design diagrams, implementing the software, and subsequently testing it. Skipping over these steps often leads to project failure, emphasizing the significance of dedicating time to establish requirements and design, even if they are not fully refined. Coding without a clear understanding of requirements can result in rigid assumptions that are challenging to alter once development has commenced. Therefore, undertaking requirements and design activities helps in comprehending necessary assumptions, ensuring the creation of a fitting product. This process requires one to adopt an architectural mindset, focusing on the software’s structure and behavior, and may involve evaluating multiple solutions to outline the most suitable one.
Requirements
Requirements are vital conditions or functionalities that must be integrated into a product based on client or user demands. To elicit comprehensive requirements, it is imperative to actively probe the client’s vision, clarify unspoken aspects, and address potential considerations that may not have been initially raised. This approach allows for a complete understanding of the project’s scope and the client’s expectations before initiating the development process. Furthermore, it is essential to identify potential trade-offs, such as sacrificing certain features for improved performance. Neglecting the comprehensive gathering of requirements is a common reason for project failure, according to The Standish Group’s survey. A comparison drawn between requirements gathering and an architect planning a house underscores the importance of understanding not only what the client desires in terms of rooms but also the size, constraints, spatial arrangement, and orientation of the structure. Understanding these facets lays the groundwork for the subsequent design phase.
Design
When the initial set of requirements has been created, the next step in the process is to produce a conceptual design and a technical design. This results in the creation of two different kinds of artifacts: conceptual mock-ups and technical diagrams
- Conceptual Design
Conceptual designs serve as the foundational step before the technical design phase, focusing on the overall structure and responsibilities of the software product, while deferring intricate technical details. These designs are communicated through conceptual mock-ups, such as wireframes, which visually represent key features and relationships between components. The process of creating mock-ups facilitates the identification of missing components and aids in eliciting client feedback. Each component within the design holds specific responsibilities, while technical details are left for the subsequent technical design phase. Similar to the analogy of building a house, components include the lot, house, and rooms, while connections represent room accessibility. The house is responsible for providing power, water, and support, while individual rooms, like the kitchen, have specific responsibilities. However, technical intricacies like wiring and plumbing are not addressed in the conceptual design but are essential for the complete understanding of the mock-ups. A well-defined conceptual design leads to a more effective technical design and increases the likelihood of developing the software accurately.
- Technical Design
Technical design, building upon the conceptual design and requirements, focuses on defining the intricate technical details of the software solution. It involves breaking down major components into smaller, more specific elements to enable detailed design. This iterative process continues until each component is refined and specified with its particular technical attributes. Technical diagrams are used to communicate this refined information, offering visual representations that address specific issues for each component, as conceptual mock-ups lack this level of detail. These diagrams aid in coordinating development efforts and can encompass various types that elucidate the structure and behavior of components. In the context of designing a kitchen within a house, the technical design might emphasize the need for easily cleanable flooring, considering the potential mess associated with cooking activities, thereby illustrating the level of detail required in the technical design phase.
Compromise in Requirements and Design
During the design phase, compromises may be necessary to develop a viable solution that meets client requirements while adhering to existing constraints. Effective communication and feedback play a pivotal role in ensuring that the final design aligns with the client’s expectations. In the context of an architectural project, if a client desires an unobstructed open kitchen but structural requirements necessitate a post and beam, a compromise must be reached. If the technical design proves unattainable or fails to meet the set requirements, it may be essential to revise the design, highlighting the significance of revisiting conceptual mock-ups during the planning stage. Larger systems demand extended design time due to the complexity of managing numerous components and connections, often requiring further refinement into smaller, more manageable elements. Once an achievable design is established, technical diagrams serve as the foundation for constructing the intended solution, refining components into implementable functions, classes, or modules. Various design techniques are explored further in this specialization to optimize the design process.
Design for Quality Attributes
When developing software, it is important to take a broad view on how to achieve the desired requirements. This lesson examines how competing ideals, roles and perspectives, potential trade-offs, and project realities need to be taken into account and balanced in software design.
Trade-offs
In software development, trade-offs are crucial when dealing with design restrictions, necessitating a balance between various quality attributes such as performance, convenience, and security. This process involves assessing how these attributes may interact and compete within the proposed solution, ultimately leading to a well-informed compromise that aligns with the product’s requirements. Achieving this balance is an ongoing responsibility for software architects, often involving the prioritization of certain attributes, considering factors like project deadlines and feasibility. An illustration of this trade-off can be seen in the design of a house’s front door, where balancing security with convenience and performance requires avoiding excessive security measures that may impede usability.
Context and Consequences
Considering the context is crucial in determining the appropriate balance of qualities in software design, as the specific usage scenario may dictate different security requirements. Communication with stakeholders aids in establishing this context. Additionally, foreseeing consequences is essential, as choices made during design may lead to unforeseen issues, especially when scaling from small to large datasets. Seeking diverse perspectives through design reviews and testing various prototypes helps ensure a well-rounded implementation and allows for the identification of potential unintended consequences. Thorough testing, including examinations with both small and large datasets, can reveal system limitations and further aid in preventing adverse outcomes.
Satisfying Qualities
Satisfying qualities in software design necessitates meeting both functional and non-functional requirements, ensuring correctness for the former and emphasizing attributes such as performance, resource usage, and flexibility for the latter. These requirements may evolve through ongoing interactions with clients and users, often leading to necessary compromises in design. Effective communication with stakeholders aids in determining acceptable trade-offs. Reviews and tests serve to verify the fulfillment of required qualities during the design and implementation stages, while user feedback may also validate certain attributes. The analogy of different car types highlights how emphasizing specific non-functional requirements can significantly influence the final product, underscoring the impact of design choices on the overall outcome.
Compromise
In software design, it is crucial to acknowledge multiple perspectives, ensuring that the structure satisfies user and developer requirements alike. Balancing qualities involves understanding the trade-offs, such as the potential impact on performance and maintainability or on performance and security. Finding a balance between different qualities is essential, demanding the prioritization of specific attributes based on project requirements. Considering project constraints, such as available resources in terms of cost, time, and manpower, is necessary to achieve a balanced approach to quality while aligning with project realities. To aid in decision-making, questioning the possibility of adjusting one quality to accommodate another can help determine feasible compromises.
Class Responsibility Collaborator
This module has covered the initial stages of software development, emphasizing the elicitation of requirements and the use of conceptual design to outline potential solutions. It has also highlighted the process of refining components and connections in the technical design phase, considering various quality attributes. The upcoming lesson introduces CRC cards as a valuable technique for representing components, responsibilities, and collaborations at a high level during the conceptual design phase, aiding in the organization and refinement of software components.
CRC Cards
In the conceptual design phase, utilizing Class, Responsibility, Collaborator (CRC) cards is a valuable technique to not only identify but also represent and organize system components, responsibilities, and connections. These cards, akin to note cards, consist of three sections: the class name, responsibilities, and collaborators, and serve to systematically capture the interactions and dependencies between various classes. By continually creating and refining these CRC cards, designers are encouraged to break down components into smaller, more manageable classes, aiding in the comprehensive and detailed description of the system’s design.
Prototyping and Simulation
CRC cards offer a cost-effective and flexible approach for organizing information into manageable components during software design. One of their main advantages lies in their physical manipulability, allowing designers to reorganize the cards and explore different system arrangements, facilitating the identification of potential design flaws. Through this process, CRC cards can be utilized for prototyping and simulating a system during the conceptual design phase, often referred to as CRC models. These cards are particularly beneficial for team discussions, enabling visual explanations of system dynamics and the solicitation of valuable input from team members. While CRC cards represent a valuable tool, other design techniques exist, with the subsequent modules in this specialization exploring additional effective design strategies.
Ibrahim Can Erdoğan
