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:
- Describe the diagrams used during design and explain how they interact with one another
- Explain why and how the statechart diagram is used during design
- Build a statechart from multiple sequence diagrams
- Apply the state design pattern to handle complex state-specific behavior