Lesson 1

The object design phase is indeed the phase where you decide how to implement your system so that it conforms to your design expectations, especially from the perspective of object-oriented principles.
To break it down:
✅ What Happens in the Object Design Phase:

• Refinement of the Analysis Model: You take the conceptual model from the object-oriented analysis (OOA) phase, often including class diagrams, use cases, and object interactions—and refine it into a blueprint for implementation.
• Class Responsibilities and Collaborations (CRC): You define what each class is responsible for and how it collaborates with others.
• Design Decisions:
  • Inheritance vs. composition
  • Visibility (public, private, protected)
  • Interface vs. implementation
  • Relationships (aggregation, association, etc.)
• Design Patterns: If applicable, you introduce design patterns (like Singleton, Observer, Factory, etc.) to structure behavior and reuse common solutions.
• Conformance to Expectations:
  • Meeting functional requirements
  • Aligning with architectural principles (e.g., MVC)
  • Ensuring extensibility, reusability, and maintainability

🧠 In a Sentence:
The object design phase is where you **transform the abstract analysis model** into a **detailed, implementable design**, ensuring your application’s structure aligns with your intended system behavior and quality goals.

Remember that during design you are still not coding. Many people who progress through the ranks from programmer to designer to architect tend to think through every problem in terms of final code. But design is still a language and technology-independent activity. Of course, there is a relationship between implementation and the design. In an ideal world, you could create a pure design and go straight to code. In the real world, languages and technologies constrain the design by the features and mechanisms they employ. The goal of design is to establish the target for what the code must do. As the implementation choices are finalized, the design may need to be altered. Alterations will reflect the features of the implementation environment.
Your application should do what users expect it to do. Object design is the phase in which you decide how to make your application conform to these expectations. You have defined these expectations in project initiation using the use cases. You have defined all of the resources that the system needs to manage during problem analysis using the object model and the interaction diagrams. During architectural analysis you partitioned the system into units based on the problem domain use cases (domain partitions) and the architecture best suited to support the goals of the system. In the remainder of this course, you will learn about and practice the activities that make up the object design phase. You will work on each partition to define the control mechanisms within the software and the interfaces between these software pieces.
After completing this module, you will be able to:

1. Describe the diagrams used during design and explain how they interact with one another
2. Explain why and how the statechart diagram is used during design
3. Build a statechart from multiple sequence diagrams
4. Apply the state design pattern to handle complex state-specific behavior

Design, as a phase in software development, focuses on defining the structure, behavior, and interactions of a system without being tied to specific programming languages or technologies. It is a language- and technology-independent activity because it emphasizes abstract concepts, principles, and patterns that can be applied across various implementation contexts. Below is a description of how this independence manifests:

• Focus on Abstraction: Design involves creating high-level models (e.g., architecture diagrams, data flow diagrams, or class diagrams) that describe the system's components, relationships, and workflows. These models use universal concepts like modules, interfaces, and processes, which are not specific to any programming language or technology.
• Problem-Solving at a Conceptual Level: During design, the goal is to address requirements and constraints by defining solutions in terms of functionality, scalability, and maintainability. For example, deciding to use a modular architecture or a client-server model is independent of whether the system will be implemented in Python, Java, or C++.
• Use of Universal Design Patterns: Design patterns, such as Singleton, Observer, or Factory, are language-agnostic solutions to common problems. They provide a blueprint that can be adapted to any programming language or technology stack, ensuring the design remains flexible.
• Separation of Concerns: Design focuses on breaking down a system into logical components (e.g., presentation, business logic, data access) without specifying how each will be coded. This allows the same design to be implemented using different technologies, such as a web framework like Django or a desktop application framework like .NET.
• Technology-Agnostic Requirements: Design decisions are driven by functional and non-functional requirements (e.g., performance, security, usability) rather than the specifics of a language or tool. For instance, designing for high availability might involve redundancy and load balancing, concepts that apply regardless of whether the system uses AWS, Azure, or on-premises servers.
• Communication Through Common Notations: Designers often use standardized notations like UML (Unified Modeling Language) or BPMN (Business Process Model and Notation), which are independent of any programming language or technology. These notations allow stakeholders to understand and discuss the system without needing to know the eventual implementation details.
• Deferred Implementation Decisions: Design intentionally delays choices about specific languages, frameworks, or databases until the implementation phase. This ensures the design remains adaptable to future technological changes or constraints, such as switching from a relational database to a NoSQL database without altering the core design.

By focusing on these abstract, universal principles, design remains a flexible activity that prioritizes solving problems and defining system behavior over committing to specific coding details. This independence allows designers to create robust, reusable solutions that can be implemented in multiple ways, accommodating diverse languages and technologies as needed.