SAD CH7

Purpose of Analysis and Design

• Purpose of Analysis: Determine what the business needs are.

• Purpose of Design: Decide how to build the system.

• Activity during Design: Evolving the set of analysis representations into design representations.

• Considerations During Design:

  • Integration with existing systems.

  • Data conversion from legacy systems.

  • Utilizing in-house skills.

Goals of Design

• Create a blueprint for an implementable system.

• Examine several design strategies:

  • Build from scratch.

  • Purchase and customize.

  • Outsource.

• Investigate viability of each alternative.

• Completion of detailed design of individual classes and methods:

  • Focus on storage and functionality.

Techniques for Detailed Design

• Techniques Include:

  • CRC (Class-Responsibility-Collaboration) Cards.

  • Class Diagrams.

  • Contract Specifications.

  • Method Specifications.

  • Database Design.

• These provide final design details necessary for the construction phase.

User Interaction in Design

• Activities include designing:

  • User Interface.

  • System Inputs.

  • System Outputs.

• Techniques for user interaction:

  • Storyboarding.

  • Prototyping.

Physical Architecture Decisions

• Decisions regarding:

  • Hardware and software for the system.

  • Processing organization: centralized, distributed, or both.

• Need to consider:

  • Global issues.

  • Security implications.

Interrelated Steps in Design

• Design steps are interrelated; analysts may go back and forth among them.

• For example, prototyping often reveals additional information required.

• Centralized systems may need extensive hardware/software if switching to a distributed model.

Common Design Mistakes

• Classic Mistakes to Avoid:

  • Reducing Design Time: Leads to missing important details.

  • Solution: Use timeboxing to eliminate or postpone non-critical features.

  • Feature Creep: 25% of requirements typically change.

  • Solution: Ensure awareness of changes' impacts on time and cost; defer non-vital changes.

  • Silver Bullet Syndrome: Believing tools will solve all problems and reduce time/cost drastically.

  • Solution: Be skeptical of claims that seem too good.

  • Switching Tools Mid-Project: Learning new tools may incur more costs and delays.

  • Solution: Only switch if absolutely necessary, accounting for learning time in the schedule.

Verifying and Validating Analysis Models

• Importance: Ensure analysis models faithfully represent the problem domain.

• Verification involves:

  • Checking fidelity among models (e.g., activity diagrams, use-case descriptions).

  • Ensuring correlation between behavioral state machines and class diagrams.

• The analysis models need to be verified before evolving them into design models.

Evolving Analysis Models into Design Models

• Purpose of analysis models: Represent business problems with collaborating objects, focusing on functional requirements.

• Design models must address both functional requirements and nonfunctional requirements, like performance.

• Design models refine analysis models by adding environment details.

Design Reflection on Classes

• Review existing classes for:

  • Necessity.

  • Completeness.

  • Optimization (attributes/methods).

• Verify attributes and methods through iterative analysis lens.

Techniques for Evolving Models

• Factoring: Create stand-alone modules by separating out common attributes/methods into new classes.

• Abstraction: Create higher-level classes from lower-level specifics (e.g., identify Employee class from Nurse, Receptionist).

• Refinement: Identify subclasses based on specific differences when needed.

Partitions and Collaborations

• Partitions: Equivalent to subsystems to reduce complexity of system representation.

  • Use packages and package diagrams to model.

• Individual classes can support multiple collaborations based on use cases.

• Review class diagrams for relationships among classes to identify opportunities for merging collaborations.

Identifying Layers in Design

• Introduce layers to represent software architecture without overwhelming complexity.

• Standard Layers:

  1. Foundation Layer

  2. Problem Domain Layer

  3. Data Management Layer

  4. Human-Computer Interaction Layer

  5. Physical Architecture Layer

Characteristics of Each Layer

• Foundation Layer: Basic classes necessary for object-oriented applications (e.g., data types, structures).

• Problem Domain Layer: Functional focus; requires refining classes for effective implementation.

• Data Management Layer: Addresses object persistence and storage options (types include relational databases, NoSQL).

• Human-Computer Interaction Layer: Classes for UI elements (buttons, windows). Important for usability and cross-platform design.

• Physical Architecture Layer: Software execution pertaining to network and hardware configurations (includes cloud considerations).

Packages and Package Diagrams

• Utilize UML for modeling collaborations, partitions, and layers.

• Package Characteristics:

  • Serve as organizational constructs for simplifying design.

  • Use dependency relationships to illustrate inter-package modifications.

Creating Package Diagrams

• Guidelines for package diagrams:

  • Logical organization of classes.

  • Clear dependency relationships.

  • Cohesiveness within packages, ensuring classes belong together.

Design Strategies

• Custom Development: Full control over design and flexibility; however, high risk and resource-intensive.

• Packaged Software: Efficient for non-unique business needs but may require significant organizational changes.

• Outsourcing: Least internal resource use, ideal for companies lacking relevant expertise; requires management and control over vendor.

Selecting a Design Strategy

• Assess based on:

  • Business needs (common vs. unique).

  • In-house experience and technical skills.

  • Project management abilities/requirements.

  • Timeline considerations.

Selecting an Acquisition Strategy

• Collect information on tools and solutions through networking and RFPs.

• RFPs should comprehensively detail the project.

• RFIs and RFQs serve as shorter, less detailed alternatives for gathering vendor information.

Utilizing an Alternative Matrix

• Use an alternative matrix to weigh and compare design alternatives.

• Include evaluative criteria, pros/cons, and weighting strategies for decision-making.

• Careful scoring to minimize bias in decisions.

Making Final Decisions

• Engage both business and technical stakeholders in final decision-making post-analysis of various alternatives.

• Ensure clarity in terms of requirements and anticipated outcomes for successful design implementation.