요구사항을 반영해서 만드는 소프트웨어를 모델링 한다.
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가 추가된다.
KHU, SWCON