소프트웨어 공학 (7), System modeling

System modeling

개념적인 모델에서 상호작용하는 내용과, 세부적인 동작을, 시스템 구성 요소에 대한 정의하는 것

---

1. System modeling

1) System modeling이란?

- 요구사항을 반영한 시스템을 모델링하는 것으로 다른 단계에서 사용할 수 있는 도구가 된다.

- 상호작용도 반영한다.

- 여러 기법들이 존재하며, 이는 요구사항을 구체적으로 풀어가기 위한 단계가 된다.

- 각 모델의 특장점을 활용해서 적절하게 맞는 기법을 추출하는 것이 중요하다.

- 구체적인 그림을 가지고 서로의 생각을 표현할 것이다. ex) UML(unified modeling language)

- 방법 각각이 의미가 있으며 순차적으로 해도 의미있으며 requirement나 소프트웨어 디자인 등에서도 내용을 구체화하는데 사용가능하다.

 

 

2) existing and planned system models

(1) existing  system

이미 존재하는 시스템을 표나 구체적인 그림으로 표현하면 특장점, 개선이 필요한 점 등을 확인하기 쉬움

 

(2) planned system models

- 명확한 기호나 그림으로 만들어서 관련 사람에게 보여주면 새롭게 만들 시스템에 대한 설명이 가능하다.

- 개발하는 사람에게 전달함에 따라 개발 시 혼선을 빚는 것을 줄인다.

- 요구사항을 추출하거나 소프트웨어 디자인을 하는 설계 도구, 우리 생각을 문서로 남길 때에도 좋은 도구가 될 수 있다.

- 모델에 사용하는 것을 코드로 만드는 경우도 있고 일부 분야에서는 성공했다.

 

 

3) system perspectives

- 시스템은 요구사항으로부터 정의하고 구체화한다.

- 아래와 같이 순차적으로/개별적으로 정의할 수 있다.

(1) external perspective

- system은 높은 레벨에서 추상적으로 정의함 -> context modeling

- 각각의 요구사항을 하나로 모은 것을 system이라고 부름

 

(2) interaction perspective

- 사용자나 환경, 다른 사람과의 상호작용을 하기에 이를 정의해야한다. -> interaction perspective

- 백지 상태에서 시스템과 사용자 또는 외부 환경에 대해 정의하는 것을 의미한다.

- 조금 구체화된다면 시스템 내부에 존재하는 구성요소들 간의 상호작용을 정의하는 관점

 

(3) structural perspective

- 시스템 내부에서 무엇이 필요한지, 어떤 기능들이, 어떤 클래스들이, 어떤 객체들이 제대로 구성이 될지를 정적으로 펼쳐보는 관점

 

(4) behavioral perspective

- 그 안에서 무슨 일을 할지를 결정하는 관점

 

4) UML diagram types

- 1990년대부터 많이 사용되었으며 13개의 그림 형태에서 조금씩 확장되었다.

- 크게 다섯가지 종류가 존재한다.

(1) Activity diagram

각 프로세스가 수반하는 행동을 표현

 

(2) Use case diagram

시나리오를 그려서 표현

 

(3) Sequence diagram

액터가 무엇을 전달하는지 그림으로 그려서 표현

 

(4) Class diagram

소프트웨어를 클래스 중심으로 표현

 

(5) State diagram

소프트웨어는 상태 기반으로 동작하는 것이 많기에 상태를 그려서 표현

 

(6) Use of graphical models

- 기존 시스템을 표현하거나 새로운 시스템을 제안할떄, 문서를 표현할 때도 사용할 수 있음

- 소프트웨어를 설계하기 위한 방법으로 사용하기도 한다.

 

 

2. Context models

우리 시스템 내부에 있는지(개발), 외부에 있는지(상호작용)의 경계를 정하는 것

---

- 처음 시스템을 만들 때 상위 레벨에 존재하는 것

- 요구사항 관리에서도 배웠듯이 조직적, 정치적인 부분의 관여가 있을수도 있기에 경계를 정하는 것이 어렵고 중요하다.

- 외부 시스템과의 관계가 존재하다면 선을 긋는 것만으로도 충분하다.

 

1) System boundaries

- 시스템의 내부에서 무슨 일이 벌어지고, 바깥의 등장인물은 누구인지 정의하는 것이 중요함

- 정치적인 부분이 될 수 있음

- 경계가 커지면 개발이 늘어나고, 상호작용은 줄어듦

- 경계가 작아지면 개발은 줄어들지만 상호작용은 늘어남

 

context of mentalcare system

- 우리 시스템인 mentcare 바깥쪽에 있는 것은 외부의 상호작용으로 여김

- 따라서 외부 시스템이 하는 것은 따로 개발하지 않고, 이를 활용함 -> 상호작용 관계를 고려함

 

 

2) process perspective

- context modeling만으로 정보가 부족하다고 판단되면 프로세스 모델링이라는 기법을 사용할 수 있다.

 

그림(프로세스 모델링 involuntary detention)

- UML 기반으로 그려져 있음

- 정신병원에서 구금을 하는 프로세스에 대한 과정이 나와있음

 

 

3. Interaction models

 

1) interaction models란?

우리 시스템과 바깥 시스템과의 상호작용

---

- 사용자가 언제 어떻게 무엇을 위해 우리 시스템을 사용하는지 명확히 해야한다.

- 외부 시스템의 인터페이스를 맞추는 등, 우리 system-to-system 상호작용에 대한 모델링이 필요하다.

- 외부 시스템을 사용함으로서 상대방에게 성능/보안/신뢰성 등에 영향을 주는 경우에는 해당 시스템 담당자와도 얘기해야한다.

- 상호작용 모델에 등장하는 그림은 Use case diagram과 sequence diagram이 상호작용 모델에서 도움이 되는 도구가 된다.

 

2) Use case modeling

우리가 만들 시스템의 특정 시나리오에 대해 정의하는 것

---

- 각각의 시나리오에 대해 분리하여 설명해야함

- 각 시나리오마다 필요한 외부 시스템을 정의하고 디테일한 설명을 진행하는 것임

- use case를 일으키는 사람은 actor로 정의함

 

- use case를 실행시키는 사람은 medical receptionist이다.

- transfer data가 해당 case가 된다.

 

Tabular description

- 조금 더 디테일하게 transfer data는 다음과 같이 정의할 수 있다.

 

 

Medical Receptionist에 대한 Role

- 일반적으로는 사용하지 않는 use case를 여러개 펼친 그림이지만 특수한 경우에 따라 다음과 같이 표현할수도 있다.

- 특정 actor와 관련된 use cases로서 sub context modeling과 비슷할 수 있다.

 

3) Sequence diagram

actor와 우리 시스템의 상호작용을 그림으로 그린 것이

---

- 더 디테일하게 표현하고자할 때는 이를 사용한다.

- 각각의 use case에 대해 한장한장 그림으로 그리는 것을 권장한다.

 

Sequence diagram for transfer data

- tansfer data를 쪼개서 표현함

- 위에서 아래로 내려가서 시간을 반영함

- 인증이 실패하는 경우에 대해서는 생략되었기에 두 가지 그림이 더 있어야할 것으로 보임

- personal information과 summary를 요구하는 경우 두 가지가 모두 있었기에 두 경우에대해 더 그림을 그려줌

- admission system이 외부에 존재했기에 authorization은 빼는게 맞을수도 있음

- 외부 액터와 내부 액터간에 주고받는 메세지, 데이터 정보, 시간의 흐름 등을 얘기함

 

View patient information

- 간단하게 sequence diagram을 그림

 

 

4. Structural models

1) Structural models란?

조금 더 구체적으로 시스템 내의 소프트웨어 요소들의 연결관계를 보여주는 모델

---

- 객체지향 프로그래밍과 긴밀한 연결이 있기에 Class diagram을 사용하여 보여주기도 한다.

 

 

2) Class diagram

- 수많은 클래스와 객체간의 상호작용 및 연결을 보여준다.

- 시스템을 클래스의 연합체로 보고, 클래스 간의 연결과 관계를 보여준다.

- class diagram에서의 연결되는 줄은 method가 된다.

- 클래스의 객체는 사람, 외부 시스템, 시스템 내의 구성요소 등이 될 수 있다.

 

UML class diagram

- 선은 관계를 의미한다.

- 숫자는 관계를 가지는 개수를 의미한다. *는 여러 개의 관계가 있을 수 있다는 의미이다.

 

구체적인 class diagram

- 우리가 다루고자하는 소프트웨어 세상에서의 객체가 존재한다.

- 클래스로 만들어져야하는 것은 파란 박스로 표시한다.

cf) General practitinoner: 수련의

ex) consultation에 참석하는 의사는 1명에서 4명까지 가능하다. // 환자의 증상은 여러 개가 나올 수 있다.

 

Consultation 클래스

- 또한 각 클래스에 대해 어떤 멤버변수, 멤버 메소드가 있는지도 표현해야한다.

 

 

 

3) 클래스

- 클래스를 기반으로 하여 클래스가 가져야할 데이터와 기능을 정의하고, 재사용과 중복성 제거를 위해 유전의 법칙을 사용하고, has relationship을 사용해 합성하는 것이 중요하다. 이것이 객체지향언어의 지향점이다.

 

(1) Generalization models

- 복잡성을 관리하기 위해 상위에 있는 클래스에 중복적인 기능을 추상적으로 정의하는 것을 의미한다. 

- is relationship를 의미한다.

- 유전(inheritance)의 법칙으로 base 클래스로부터 상속을 받아서 derived 클래스를 만들 수 있다.

- 유전을 사용하는 것은 재사용에 가장 큰 의의가 있다.

- base 클래스는 통상 현실 세계에서는 의미가 없기에 추상화하여 가상함수 등으로 만드는 경우가 많다.

- 통상 최상단의 클래스는 추상화하는 경우가 많다.

- 추가적인 개발을 최소화하기 위해 자식 클래스에서 모두 사용하는 공통적인 부분을 추상화하여 부모 클래스에 만들어 놓는 경우가 많다.

- 소프트웨어의 변화에 따른 시스템 전반적인 영향에 결부시킬 수 있다. ex) 최상단 클래스의 변화는 시스템에서 많은 영향을 미치고, 하단 클래스에서의 변화는 적은 변화를 일으킨다.

- 서브 클래스가 가져야할 공통적인 것들은 상단 클래스로 옮기고 각 서브 클래스들은 특화된 기능을 가지도록 하는 것이 요지이다.

- lower level 클래스는 구체화되고, 가시화되고, 특화되는 반면 base class는 추상화되고, 실제로 존재하지 않는 것으로 구성한다.

 

Generalization hierarchy

mental care system에서의 다양한 의사가 존재하기에 이를 generalization하게 만든다.

trainee doctor와 qualified doctor가 가장 많은 데이터와 정보를 가질 것이라고 합리적으로 추론할 수 있다.

- 삼각형은 상위에 있는 것을 의미하는 UML 기호이다.

 

구체적인 클래스 그림

 

 

4) Aggregation models

- has relationship (part-of relationship)

- 클래스 안의 멤버가 다른 클래스인 경우가 이에 해당한다.

ex) 자동차는 바퀴 네개를 가지고, 핸들을 가지고, 엔진을 가지고 있다. 자동차는 각각의 부품을 포함하고 있기에 이에 해당한다.

 

aggregation association

- 코드는 재사용 및 데이터는 중복성 제거해야한다.

- consultation은 각각 별도의 이벤트로 존재하고 여러 상담 기록을 하나의 patient record로 저장하는 것을 볼 수 있다.

- patient record는 patient와 consultation을 가지고 있다.

- 마름모는 연결되어있는 것을 has한다는 것을 의미한다.

 

 

 

5. Behavioral models

1) Behavioral models란?

동적인 내용에 대한 내용을 모델링하는 기법을 의미한다.

- 멤버 메소드와 관련된 내용

(1) Data

- 처리해야하는 데이터를 모으고 분석하여 비즈니스에 반영하기 위한 모델링이다.

- 사업 환경이 수시로 바뀌고, 이를 동적으로 반응해야하기에 최근에 많이 사용하는 모델링이다.

ex) 쿠팡, 아마존 등에서 데이터를 받고, 처리하는데 사용

- end-to-end를 데이터의 관점에서 모델링한다.

 

당뇨처리에 대한 과정

- 입력 데이터가 주어졌을 때 이를 가공하여 원하는 것을 추출하는 것을 볼 수 있다.

 

 

 order processing

- sequence chart도 data driven behaivor model을 표현할 때 사용할 수 있다.

- 정보가 왼쪽에서 오른쪽으로 흐르는 것을 알 수 있다.

 

 

(2) Events

- 수시로 발생하는 이벤트(클릭, 키보드 입력 , 센서 등)에 따른 이벤트를 처리하는 모델링이다.

- 전통적인 소프트웨어 공학적인 관점에서의 초점

- 정해진 시간 안에 해결해야하는 real-time system이 이에 해당한다.

- 따라서 전자제품, 임베디드 시스템, 전화 시스템 등이 이에 해당할 수 있다.

ex) 전화를 걸겠다 -> send 이벤트 발생

- external events와 internal events 모두 존재한다.

- 정해진 일을 확인하고 처리하는 것이 inturrupt event라 한다.

- graphic based 유저 인터페이스(마우스 클릭, 드래그 등)는 리얼 타임은 아니지만 event-driven이라고 할 수 있다.

- 외부의 자극을 통해 움직이는 시스템이다.

- state 기반의 모델링을 많이 한다.

 

State diagram(상태 천이도)

- 상태와 다른 상태들 간의 관계를 그림으로 그린다.

- 한 상태에서 어떤 이벤트가 주어졌을 때의 동작을 정의한다.

- 상태와 이벤트, 액션 세가지 요소로 시스템을 모델링하는 것이 state에 기반한 event modeling이라고 할 수 있다.

- 임베디드 시스템, 리얼타임 시스템, 그래픽 베이스 시스템에서 많이 사용한다.

- 위의 예제에서는 시작과 끝을 보여주기 위해서 동일한 상태를 그렸음

 

전자레인지 operation

- 하나의 상태 내부에서의 state transition diagram을 그린 것을 볼 수 있다.

- 하나의 상태 내부에서 또한 위계적으로 그림을 그린 것을 확인할 수 있다.

 

states and stimuli for the microwave oven

- 내용이 부족하다고 판단되면 이를 테이블로 상세하게 작성할 수 있다.

- 이벤트 또한 테이블로 정리할 수 있다.

 

 

 

6. Model-driven engineering(MDE)

1) Model-driven engineering이란?

UML 등으로 만든 것을 자동으로 프로그램으로 만드는 것

---

- 성공 사례가 일부 있지만 아직까지 working하는 것은 보기 어렵다.

- 장단점이 존재한다.

- 추상적인 내용을 다루는 것을 구현할 수 있는가에 대한 의문점이 들 수 있다.

 

- Model driven architecture(MDA)는 UML을 상세하게 작성하여 이를 구현하고자 했다.

 

2) type of model

(1) CIM

- 루틴화되고, 정형화될 수 있는 도메인 모델이라면 이를 모아서 구현과 상관없는 추상적인 모델을 만듦

 

(2) PIM

- 한 단계 내려와서 구현과는 밀결합되지는 않은 모델을 만듦

 

(3) PSM

- 자동으로 만듦

 

MDA transformations

- 각 translator들을 활용해서 이를 번역해야한다.

- 번역이 가능한가의 문제가 있음

 

Multiple platform-specific models

 

3) Agile methods and MDA

- Agile은 설계나 요구사항에서의 문서가 만드는 과정을 지양하기에 MDA와 상극인 면이 존재하기에 이러한 소프트웨어 개발환경이라면 이를 지양한다.

- 이를 구현할 수 있는 도구가 있는지가 가장 큰 문제점이다.

 

4) adoption of MDA

- 모델링은 추상적인 것을 추출하고, 가시화하여 이를 기반으로 구현하는 것을 의미하지만 실제로는 이러한 과정들이 일대일로 매칭이 되지 않는다.

- 내가 만드는 주요 기능과 더불어 모니터링, 보안, 네트워킹, 기존 시스템과의 호환성 등을 고려해야하는데 이를 반영하기 어렵다.

- 한번 만들어서 굉장히 오래가고 platfrom independence하고, 이를 사용할 수 있는 도구가 있다면 할 수 있다. 즉 제한적인 상황에서 사용할 수 있다.