System Modeling

[System Modeling]

• A proces of developing abstract models of a system.
  • Each model presents a different view or perspective of the system.
  • Each model usually represent a system by using diagram types in UML.
    

[Models of both the existing system and the new system]

• Models of the existing system.

  • Clarifying what the existing system does.
  • Discussing the strengths and weaknesses of the existing system.

• Models of the new system.

  • Explaining the proposed requirements to other system stakeholders.
  • Discussing design proposals.
  • Documenting the system for implementation.

[Different perspectives for representing the system]

• An external perspective

  • Modeling the context or environment of the system.

• An interaction perspective

  • Modeling the interactions between a system and its environment.

• A structural perspective

  • Modeling the organization of a system or the structure of its data.

• A behavioral perspective

  • Modeling the dynamic behavior of the system.

[Different ways to use graphical models]

• Focusing discussion about an existing or proposed system.

  • The models may be imcomplete and use informal notation.

• Documenting an existing system.

  • The models do not have to be complete, but correct.

• Genergating a system implementation.

  • The models do have to be complete and correct.

UML (Unified Modeling Language) diagrams

[UML: A standard language for object-oriented modeling]

• Interaction model
  -> Use case diagrams, Sequence diagrams

• Structural model
  -> Class diagrams

• Behavior model
  -> Activity diagrams, State diagrams

• Use case diagrams

  • which show the interactions between a system and its environment

• Sequence diagrams

  • which show interactions between actors and the system and between system components.

• Class diagrams

  • which show the object classes in the system and the associations between these classes.

• Activity diagrams

  • which show the activities involved in a process or in data processing.

• State diagrams

  • which show how the system reacts to internal and external events.

Context Models

[Roles of Context models]

• Showing how a system is positioned in an environment with other systems and processes.
  

[Simple Context models]

• Do not show the types of relationships between the systems in the environment and the system that is being specified.

  • Producing data for or consuming data from the system.
  • Physical locations of the systems (e.g., same building)

• The relations affect the requirements and design of the system.

• <Simple context models are used along with other models, such as business process models.>

[Simple Context model + Activity model]

Interaction Models (Use case diamgrams, Sequence diagrams)

[Interaction Models]

• Use Case Modeling

  • Modeling interactions between a system and external agents (human users or other systems).

• Suequence diagram (둘이 비슷해 보이지만, Sequence diagram이 더 많은 정보를 갖고 있음)

  • Modeling interactions between system components, although external agents (may also be included).

Use case diagrams

[Roles of use case diagrams]

• Simply describing what a user expects from a system in the interaction.
• Giving a simple overview of an interaction.
  

[Example of use case diagrams]

• Actor
  • Primary actors
  • Secondary actors
• System
  

• Relationship

  • Association
    

  • Include

  • Extend
    

  • Generalization (Inheritance)
    

[Tabular description of the Transfer-data use case]

Sequence diagrams

[Roles of sequence diagrams]

• Modeling the interactions between the actors and the objects in a system and the interactions between the objects.
• Showing the sequence of interactions that take place during a particular use case.
  

[ATM system of sequence diagrams]

• 세로 축이 시간의 흐름

Structural Models (Class diagrams)

[Structural models]

• Showing the organization of a system in terms of the components that make up that system and their relationships.

[Class diagrams] -> Structural models의 예시

• Modeling the static structure of the object classes in a SW system.
• Developing an object-oriented system model to show the classes in a system and the associations between these classes.

Class diagrams

[Roles of class diagrams]

• Consists of class, attributes, methods, relationships
  • class, attributes, methods
    
  • relationships (Inheritance, Association)
    
  • relationships (Aggregation (not tightly coupled), Composition (tightly coupled))
    
  • relationships (Multiplicity)
    

Behavioral Models (Acitivity diagrams, State diagrams)

[Behavioral models]

• Models of the dynamic behavior of a system as it is executing.
• Showing what happens when a system responds to a stimulus.
  • Stimulus = data or events
• Many business systems are data-driven.
  • A phone billing system (calls -> cost calculation -> bill generation)
• Real-time systems are usually event-driven.
  • A landline phone switching system
    (handset activation -> a dial tone) (pressing keys -> capturing the number)

Data-driven modeling

[Data-driven modeling]

• Show the sequence of actions involved in processing input/output.

Activity diagram

• Consist of activity (rounded rectangles) and data flowing between these steps (rectangles).
  

Event-driven modeling

[Event-driven modeling]

• Showing how a system responds to external and internal events.
• Assuming that a system has a finite number of states and events cause a transition from one state to another.

State diagram

• System states (Rounded rectangles)
  • Including a brief description of the actions taken in the state.
• Trasition (labeled arrows)
  • Representing stimuli that force a trasition from one state to another.

[A state diagram of a microwave oven]

[A state model of the Operation state]

[States and stimuli for the microwave oven]

Model-driven Engineering

[Model-Driven Architecture (MDA)]

• A model-focused approach to software design and implementation

• Expectation or Hypothesis

  • The programs that execute on a SW platform are generated automatically from the models ????
  • MDA는 소프트웨어 개발 프로세스를 모델을 중심으로 설계하고, 모델을 사용하여 소프트웨어 시스템을 자동으로 생성하는 아키텍처적인 접근 방식

• 3 types of abstract system model for MDA
  

  • A computation independent model (CIM)

    • CIMs (a domain model) model the important domain abstractions used in a system (e.g., models of the actual people, places, things, of a domain)
    • CIM은 시스템에서 사용되는 도메인의 중요한 개념을 모델링합니다. 예를 들어, 사람, 장소, 물건과 같은 도메인의 실제 개념을 나타낼 수 있습니다. 이 모델은 시스템의 기능적 요구사항과 도메인 이해를 제공합니다.

  • A platform-independent model (PIM)

    • PIM enables its mapping to one or more platforms by defining a set of services in a way that abstract out technical details.
    • PIM은 시스템을 플랫폼과 독립적으로 모델링합니다. 기술적 세부 정보를 추상화하여 시스템의 서비스를 정의하고, 이를 하나 이상의 플랫폼에 매핑할 수 있게 합니다.

  • A platform-specific model (PSM)

    • A PSM combines the specifications in the PIM with the details required to stipulate how a system uses a particular type of platform.
    • PSM은 플랫폼에 특정한 사항과 세부 정보를 포함합니다. 이 모델은 PIM의 명세 사항과 함께 사용하여 시스템이 특정 유형의 플랫폼을 어떻게 활용할지를 정의합니다.

CMI는 도메인 추상화에 중점을 두고, PIM은 플랫폼 독립적인 서비스를 정의하며, PSM은 플랫폼별 구체화를 수행함

[MDA transformations]

[MDA is not a mainstream approach to SW development]

• The abstractions that are useful for discussions are not the right abstractions for implementation.
  토론에 유용한 추상화는 구현에 적합한 추상화가 아님

• For complex systems, implementation is not the major problem.
  복잡한 시스템의 경우, 구현은 주요 문제가 아님

  • ex) requirements engineering, security and dependabiltiy, testing, ...

• The widespread adoption of agile methods has diverted attention away from model-driven approaches.
  애자일 방법론의 광범위한 채택으로부터 모델 주도적 접근법에 대한 주목이 분산됨

Summary