Object-Oriented Design: Subsystems, Architecture, and MVC Pattern
Object-Oriented Design Steps
In object-oriented design, two major steps are needed to begin the design phase. These steps involve organizing the problem domain and subdividing it into packages with defined stereotypes.
When approaching the problem domain, the initial step is to partition the analysis model. This involves defining cohesive collections of classes, relationships, and behaviors, bundling them into packages or subsystems.
Important Considerations for Subsystems:
- A subsystem must have a well-defined interface through which all communication with the rest of the system occurs.
- Except for a small number of communication classes, the classes within a subsystem should primarily collaborate with other classes within the same subsystem.
- The number of subsystems should be kept small.
The second step involves grouping classes within each subsystem according to the type of function they fulfill in the system, that is, their stereotype.
Project Architectural Products
The architectural design involves allocating essential requirements to a particular technology. This includes determining which processes will run on which processors, where data is stored, and the communication required between processors.
Main products of a project architecture include:
- The geographical distribution of computational requirements.
- Hardware components for client machines.
- Hardware components for server machines.
- Configuration and number of layers in a client-server architecture.
- The software platform for implementation, including coding languages, user interface presentation, operating systems, communication mechanisms and languages, and database management system.
- The location of files.
- The location of physical data.
- Strategies for data synchronization in distributed environments.
Criteria for Designing Subsystems
When designing subsystems, consider the following criteria:
- Project Interfaces
- Coupling
- Architectural Style
- Maintainability
- Reusability (components and standards)
The MVC Architectural Pattern
The MVC (Model-View-Controller) pattern separates data or business logic (Model), the user interface (View), and the application flow (Controller).
The core idea is to enable the same business logic to be accessed and viewed through various interfaces. In the MVC architecture, the business logic (Model) is unaware of how many or what user interfaces are displaying its state. Given the diverse interface possibilities today, MVC is an essential tool for developing systems.
“THE LOGIC OF BUSINESS SHOULD NOT KNOW ANYTHING ON THE SCREEN THAT DISPLAYS YOUR STATE!”
The application is divided into three parts:
- Model: Business Logic
- View: User Interface Layer. This layer displays the state of the model and allows the user to interact with the business logic.
- Controller: Transforms events generated by interface actions into business actions, modifying the model.