System Object Design  «Prev  Next»
Lesson 1

System Object Design Modeling Course

Welcome to Object Oriented Design: System and Object Design, the third course in the Object-Oriented Analysis and Design Fundamentals Series. This course covers the system analysis and object design phases of the software development project life cycle.
  1. Data dictionary: A data dictionary is a centralized repository of information about data, such as its meaning, relationships to other data, origin, usage, and format. It serves as a crucial reference for developers, analysts, and users to understand the structure and content of a database or information system.
  2. Use case diagram: A use case diagram in UML (Unified Modeling Language) visually represents the functional requirements of a system by showing how different users (actors) interact with the system to achieve specific goals. Each use case describes a particular function provided by the system, illustrating the scope and behavior of the system from an external perspective.
  3. Class diagram: A class diagram is a fundamental building block in object-oriented modeling that depicts the static structure of a system by showing its classes, their attributes, operations (methods), and the relationships between them. It provides a blueprint of the system's conceptual design, helping to organize and understand the system's components and their interactions.
  4. Sequence diagrams: A sequence diagram illustrates the interactions between objects in a chronological order, showing the sequence of messages exchanged between them to perform a specific function or use case. It is particularly useful for visualizing the flow of control and the lifetime of objects within a system's execution.

Levels of Models

Models take on different forms for various purposes and appear at different levels of abstraction. To determine the amount of detail that should be included in a model, you use a process called model abstraction or level-of-detail analysis. This is typically guided by the modeling purpose and target audience. A structured approach includes the following steps:
  1. Define the Modeling Objective
    • What is the purpose of the model?
    • Are you trying to communicate, analyze, design, or simulate something?

    📌 Example: A model for executive stakeholders will likely be high-level and conceptual; a model for developers will be low-level and detailed.

  2. Identify the Audience

    Tailor the level of detail to the knowledge and role of the audience:

    • Business users → Conceptual or logical model
    • System architects → Logical or technical model
    • Programmers or DBAs → Physical or detailed model
  3. Determine the Scope

    Clearly establish:

    • What entities or components must be included?
    • What relationships, constraints, or interactions must be shown?

    Avoid unnecessary elements that do not serve the purpose of the model.

  4. Select the Appropriate Level of Abstraction

    Three typical levels:

    1. Conceptual Model (high abstraction)
      • Focuses on business concepts and rules.
    2. Logical Model (medium abstraction)
      • Adds structure without implementation details.
    3. Physical Model (low abstraction)
      • Includes tables, keys, indexes, and platform-specific info.
  5. Apply the Principle of Sufficiency

    Include only what is sufficient to:

    • Achieve the modeling objective
    • Answer the stakeholders’ questions
    • Guide the next development phase
  6. Iterate and Refine

    Start with a high-level model and increase detail only as needed:

    • Use progressive elaboration
    • Validate with stakeholders to adjust the granularity

📌 Summary Decision Factors:
Factor Impact on Detail
Purpose of Model Drives conceptual vs. detailed focus
Stakeholders Affects technical depth
System Complexity Determines level of decomposition
Project Phase Early = abstract, Later = detailed

  • Guides to the Thought Process
    High-level models built early in a project serve to focus the thought process of the stakeholders and highlight options. They capture requirements and represent a starting point toward a system design. The early models help the originators explore possible options before converging on a system concept. As design progresses, the early models are replaced by more accurate models. There is no need to preserve every use case examined during the exploratory process. The purpose of high-level models is to produce ideas. However, the final "thinking models" should be preserved even after the focus shifts to design issues. Early models do not require the detail or precision of an implementation model[1], and they do not require a full range of implementation concepts.
    Such models use a subset of UML constructs, which represent a more limited subset than later design models. When an early model is a complete view of a system at a given precision (i.e., an analysis model of what must be done) then it should be preserved when development shifts to the next stage. There is an important difference between adding detail (in which case, the chain of reasoning should be preserved) and the normal random-walk process of exploring many dead ends before arriving at the right solution. In the latter case, it is usually overwhelming and unnecessary to save the entire history except in extraordinary situations in which complete traceability is required.

Structural Analysis

Course Goals

After completing this course, you will be able to:
  1. Execute the two steps of the design process: system analysis and object design
  2. Partition a system in preparation for the detailed design phase
  3. Partition the system by functional requirements using use cases and the class diagram
  4. Partition the functional areas into cooperating layers of technology
  5. Apply cohesion and coupling to assess and improve the quality of your design
  6. Refine the definition of objects using stereotyped behaviors
  7. Build design patterns like MVC by distributing responsibilities
  8. Apply design patterns to improve the flexibility of your application  

Object-Oriented Design is the third course in the Object-Oriented Analysis and Design Fundamentals Series. This series is designed to teach you practical object-oriented business analysis. By completing the series, you learn to fully define the
  1. scope,
  2. requirements,
  3. analysis, and
  4. design
for a business application using object-oriented models and techniques.

[1] implementation model: The implementation model is a collection of components, and the implementation subsystems that contain them. Components include both deliverable components, such as executables, and components from which the deliverables are produced, such as source code files.

SEMrush Software