Chpt 7

Chapter 7: Moving on to Design

• The System Design phase follows system analysis.
• System design involves translating identified requirements into a blueprint for building the system.
• The goal is to determine the system's structure considering business needs and technical/environmental factors.

Steps in System Design

• Verify and Validate Analysis Model: Check if analysis models (use cases, diagrams, etc.) accurately represent the business requirements. This ensures consistency and reduces future development errors. Related diagrams should align to the same functional requirements.
• Evolving Analysis Models into Design: Analysis models evolve into design models. The focus transitions from capturing business needs to designing how the system operates within its environment (e.g., performance, security). This phase refines classes, attributes, methods, and their interactions. It moves from the analysis workflow towards the elaboration and construction phases.

Evolving Analysis Models into Design Strategies

• Factoring: Separating a module into a separate module (new class or method). Useful when multiple classes share similar attributes or methods. For instance, creating an "Employee" class from overlapping parts of "Nurse," "Doctor," and "Receptionist" classes.
• Partitions and Collaboration: Grouping similar elements in a system based on interactions (object-oriented equivalent of subsystems). A system can be decomposed into component systems (e.g., accounting, accounts payable, payroll). Example: Hospital management systems split into payroll, appointment scheduling, and patient records. This is driven by activity patterns among objects.
• Layers: Layers represent elements of the evolving software architecture (e.g., problem domain, data management, human-computer interaction, physical architecture). For instance, a system might have layers including DataInputStream, Date, Enumeration, Employee, Customer, Button, Panel, and Server. The primary focus of the design phase shifts from the problem domain to the system's environment including user interface and physical architecture.

Design Quality

• Coupling: The level of interdependence between modules (classes, objects, or methods). Tight coupling means changes in one module often necessitate changes in others. Loose coupling is preferred for adaptability and maintainability. Best practices include focusing on sending messages to closely related objects. Reducing the number of classes an object interacts with directly also minimizes interaction coupling. Inheritance coupling needs to be used carefully, as overuse leads to tightly coupled hierarchies.
• Cohesion: How closely related the responsibilities of a module are. High cohesion occurs when a module has a single, well-defined purpose. Conversely, low cohesion happens when unrelated tasks are combined. Best practices include grouping attributes and methods that directly relate to the module's purpose, ensuring methods have single purposes.
• Connascence: The degree to which different system parts must change together. Best practices include minimizing dependencies between modules and maximizing connascence within a module for control and limited scope. Encapsulating logic and data can prevent cascading changes across the system.

Design Strategies

• Custom Development: Building the system from scratch to fit specific business needs. Provides complete control and flexibility but is time-consuming and costly.
• Packaged Development: Using pre-built software and customizing for the organization. Faster implementation and cheaper than custom, but flexibility is limited.
• Outsourcing: Hiring external vendors to build or manage the system. Reduces internal workload, leverages expertise, but may have security risks and limited control.

Choosing the Right Strategy

• Consider the unique aspects of the business needs and required skills. Consider in-house expertise, required time frame. If there are common needs, then packaged software may be more efficient.

Roles in the Development Process

• IT manager is concerned with technical feasibility, integration, and maintenance.
• Software developer is focused on innovation and technical aspects.
• Project manager focuses on deadlines, resource management.
• Customer service representative focuses on creating user-friendly systems for customer service efficiency.
• Business owner (CEO) is concerned with overall business growth, cost-effectiveness, and quick implementation.

Class Exercises

• Students are asked to compare and contrast different class diagram visualizations, considering issues of cohesion, coupling, and connascence.
• The scenarios presented involve a retail company seeking a CRM system implementation, including a deadline pressure and resource limitations.
• Different roles within the organization (IT Manager, Developers, Project Manager) have specific issues and priorities, including budget, technical expertise and deadlines.