Software Engineering – System Modeling

Bomin Seo·2022년 7월 26일
0
post-custom-banner

요구사항을 반영해서 만드는 소프트웨어를 모델링 한다.

System modeling

  • 추출한 요구사항을 구체적으로 풀어내는 과정
  • 말로 표현하는 것은 모호함을 주기 때문에 미리 약속된 기호(UML)을 사용하여 표현
  • 개발자나 고객들이 이해하는데 도움을 준다.

Exiting and planned system models

  • 이미 동작하는 시스템을 그림이나 표로 표현함으로써 현재의 시스템의 문제점이나 새로운 시스템의 요구 사항을 추출하는데 사용될 수 있다.
  • 새로 만들 시스템을 그림이나 표로 설명함으로써 이해당사자들에게 용이하게 설명하고 개발자들에게 전달함으로써 요구 사항이 무엇인지 간결하게 설명할 수 있다.
  • model-driven engineering 프로세스에서는 모델링으로 만들어진 기호를 그대로 코드로 구현함으로써 프로그래밍 언어로 구현할 필요가 없다.

System perspective

요구 사항은 이미 정의되었으며, 흩어져 있는 요구 사항을 하나로 묶어 시스템으로 만든다.

external 관점

  • 외부에서 하나의 전체적인 관점에서 바라보는 관점
  • 시스템이 기존에 없던 경우 요구사항을 묶어 하나의 시스템으로 보는 관점

interaction 관점

  • 시스템이 없는 환경에서는 사용자나 외부환경, 또 다른 시스템과 상호작용하는 관점으로 바라본다.
  • 시스템이 있는 경우나 구현이 잘 된 경우에는 시스템의 구성요소 간에도 상호작용을 정의할 수 있다.

structural 관점

  • 시스템 내부에서 어떤 기능, 클래스 등이 필요할지에 대해서 바라보는 관점

behavioral 관점

  • 시스템 내부에서 어떠한 일이 수행되어야하는지에 대해서 바라보는 관점

UML diagram types

  • 어떤 의미를 가지는지에 대해 이미 정의된 그림을 사용한다.
  • 객체지향프로그래밍을 모델링하기 위해 나온 그림/기호

Activity Diagram

  • 데이터 프로세싱이나 프로세스 중에 어떤 활동이 수반되는지 본다

Use case Diagram

  • 시나리오 중심으로 모델링, 환경과 시스템 사이의 상호작용을 본다

Sequence Diagram

  • 누가, 누구에게, 서로 무엇을 전달하는 지를 그림으로 그려서 표현

Class Diagram

  • 수많은 객체들이 존재할 텐데, class 중심으로 소프트웨어를 정의

State Diagram

  • 소프트웨어에는 여러 단계(상태)들이 존재하는 경우가 일반적이다. 프로그램을 현재 상태와 들어온 이벤트와의 관계로 모델링을 진행

Context Model

  • 추상적이고 상위의 레벨, 시스템의 바깥에서 상호작용을 정의한다.
  • 시스템의 경계선을 표현하며 사회적이나 집단의 이해관계가 시스템의 경계선을 결정하는데 영향
  • 경계선을 확정함으로써 중복성을 제거하고 재활용의 여부를 확인할 수 있다.
  • 전체적인 시스템 안에서 시스템이 어떻 위치에 있는지에 대해 표현한다.

Process model

  • context model에서 구체적인 정보가 부족할 때 사용할 수 있다.
  • 특정 상황에서 어떠한 절차를 거쳐 시스템이 동작하는지에 대해서 설명한다.
  • 다른 수많은 시스템 사이에서 해당 시스템이 어떻게 상호작용하며 어떻게 사용될지에 대해 고려

Interaction Model

  • 시스템과 외부환경이나 사용자와 어떻게 상호작용하는지에 대해 표현
  • 사용자의 요구 사항을 명확하게 파악할 수 있다.
  • 다른 외부 시스템과 상호작용시에 수정할 부분이 필요하며 서로 영향을 주고 받을 수 있어 상호작용에 대해 정의한다.
  • use case diagram과 sequence diagram이 도움이 많이 되는 다이어그램이다.

Use case modeling

  • 시스템이 특정 시나리오에 대해 행동하는 방식에 대해 모델링
  • 요구 사항 추출이나 UML에 통합하는데 사용된다.
  • 각각의 사용 케이스에 대해 표현한다.
  • 각 시나리오에 국한된 외부시스템이 정의되며, Actor는 시나리오를 발생시키고, 결과를 취해갈 대상의 의미한다.

Sequence diagram

  • interaction model을 표현하는데 많이 사용된다.
  • actor로 등장하는 객체는 사용자와 시스템 외부에 존재하는 것
  • 시스템을 분할하여 내부의 단계를 표현할 수 있다.

Structural Model

  • 소프트웨어의 내부구조로, class diagram으로 많이 표현된다.
  • 객체지향기법을 사용하면, 하나의 소프트웨어를 수많은 객체의 상호작용으로 정의할 수 있다.
  • 소프트웨어를 class들과 그들 간의 연관성(연결/링크)으로 설명할 수 있으며, 숫자의 의미는 대응관계를 보여준다.

Generalization (유전, UML상 삼각형으로 표현)

  • class diagram / structural model에서 많이 사용한다.
  • 상위 개념(class)가 하위 개념(class)들이 공통적으로 가지고 있는 기능들을 포함함으로써 추가적인 개발에 대한 작업의 양을 줄이고 복잡도를 관리한다.
  • 재사용과 중복성 제거(많이 사용하는 것을 상위에 모은다)가 중요 개념이다.
  • 상위 개념 : 일상 생활에서 구체적인 특징을 가진 객체보다 일반화된 객체로 특징을 설명한다.
  • is-relationship : 상위클래스(일반적, 추상적 개념)과 하위 클래스(구체적 개념)의 관계
    • 상속을 사용하여 관계성을 표시한다.
  • modeling system에서는 변화가 발생할 때 모든 클래스를 보는 것이 아닌 일반적인 클래스를 보는 것이 유용하게 동작한다.
  • 객체지향 프로그래밍 언어 관점에서는 상속의 개념으로 구현되어 있다.
  • 하위 개념의 클래스는 본인이 필요한 것을 특화하고 구체적이고 가시화한다.

Object class aggregation models(UML상 마름모로 표현)

  • 객체가 객체 안에 있는 개념(has relationship, part-of relationship)
  • C++에서는 정수나 실수와 같은 데이터 타입이 클래스가 아닌 데이터이기 때문에 중요하다
  • 자동차 내에 있는 부품에 해당하는 객체를 포함하는 경우
  • 코드는 재사용, 정보의 중복성 제거

Behavioral Model

  • 실행해야 될 동적인 행동들을 모델링하는 기법
  • 외부의 자극이 입력되었을 때, 어떤 행동을 하며 어떤 행동을 취할 것인지 보여준다.

자극의 2가지 분류

  • DATA : 어떤 데이터들은 시스템에 의해 가공되어야 한다.
  • EVENTS : 어떤 이벤트들은 시스템 프로세싱을 유발하며, 데이터와 관련되어 있을 수도 있다.

Data-driven modeling

  • 데이터를 처리(변경, 추출 등)하는데 방점을 찍은 시스템 모델링.
  • 인풋 데이터가 주어지면 원하는 아웃풋을 만들어 내는, end-to-end가 명확
  • 최근의 비즈니스 어플리케이션에도 많이 사용된다

Event-driven modeling

  • 전통적인 개발(Real-time system, GUI), Landline phone switching(전화, zoom)에 주로 사용
  • 이벤트의 발생에 따라 구체적인 동작을 모델링하는 기법으로, 상태 기반(State-transition 기반)의 모델링이라 할 수 있다.
  • State, Event(interval, external), Action 요소를 중심으로 시스템을 모델링.
  • State Diagram을 통해 표현할 수 있다.

Model-driven Engineering

모델링을 잘하면 프로그램을 바로 만들 수 있는 Engineering 기법

장점

  • 상위 레벨의 추상화를 가능하게한다.
  • 모델링에서 코드를 자동으로 생성하는 것은 새로운 플랫폼을 채택하는데 더 적은 비용이 든다.

단점

  • 모델은 추상화되어 있으며, 구현에 맞지 않다.

MDA 단계

  • A computation independent model (CIM)
    • System의 주요 domain에 대한 추상화를 진행한 모델
  • A platform independent model (PIM)
    • 구현과 무관한 system의 운영에 대한 모델
    • 내외부 event에 대한 반응과 시스템의 구조를 UML로 표현한다.
  • Platform specific models (PSM)
    • PIM을 각 플랫폼에 맞도록 변형한 모델
    • PIM에 Platform-specific한 세부 사항을 기재한 layer가 추가된다.
profile
KHU, SWCON
post-custom-banner

0개의 댓글