[소프트웨어공학] 5장 시스템모델링(System Modeling)

앞에서 만든 요구사항(무엇을 해야 할지 정의)들을 토대로 동작시킬 시스템을 만들어야함

-> 요구사항을 반영해서 만든 소프트웨어를 모델링(그림을 많이 그림)함

우리가 무엇을 만들어야할지를 구체화하는 작업

 

대표주제

• Context models – 우리의 시스템이 무엇인가
• Interaction models – 다른 것들과 우리 시스템의 상호작용 or 내부 객체들 간의 상호작용
• Structural models – 위와 같은 것들을 그림으로 모델링 하는 것
• Behavioral models – 세부적으로 무엇을 기술할지를 정함
• Model-driven engineering – 모델링을 잘하면 그것이 바로 시스템 코드로 나옴

 

-모델링에 대한 다양한 방법들을 제시를 할 것임

-그림(약속되어 있음, UML)으로 기호로 소프트웨어를 모델링하는 것이 일반적임, UML(Unified Modeling Language)

 

모델링하는 타겟 2가지

-기존에 존재하는 시스템을 모델링하는 것(요구사항을 추출해야하는 이미 있는 것을 그림으로 놓고 하면 좀 더 이해가 수월해짐)

-새로운 시스템이 이렇게 될 것이다 라는 명확한 그림이나 기호를 만들어서 관련된 사람들에게 보여주어 이해를 돕고 개발자에게 전달하여 혼선이 생기는 것을 방지함

>>요구사항을 추출하는 작업에 사용될 수 있고, 소프트웨어를 설계하고 그것을 상대방에게 넘겨서 구현하게 하는 설계문서의 일환으로 사용할 수 있다!

 

우리는 없는 시스템을 정의하는데 요구사항만을 두고 그것을 시스템이라고 칭함

-시스템의 context(우리 회사의 시스템을 의미, 굉장히 높은 레벨에서 추상적으로 모델링) 또는 환경을 모델링하는 외부 관점입니다.(외부에서 바라보는 것)

-시스템과 그 환경 또는 시스템의 구성 요소 간의 상호작용을 모형화하는 상호작용 관점.

ex. 멘탈케어 시스템에서 사용자나 환경과 같은 외부적인 요소들과 상호작용함

-시스템의 구성이나 시스템이 처리하는 데이터의 구조를 모델링하는 구조적 관점.

위에서 외부를 봤으니 이제 내부적인 요소들(클라스, 객체)과 같은 정적인 요소들을 모델링하는 것

-시스템의 동적 거동 및 이벤트 대응 방식을 모델링하는 행동 관점.

이제 어떤 것들이 필요한지를 정의를 했으니 어떤 행동을 할지를 모델링함

 

그림을 많이 사용할 것임 -> UML

UML(Unified Modeling Language)이란?

객체지향프로그래밍 언어로 만들어진 것을 모델링하기 위해 만들어진 것

폭포수 모델이건 에이자일이건 두루 많이 쓰임

 

 

UML 다이어그램 종류

>Activity diagrams – 기능이 어떤 식으로 처리되는지를 보여줌

>Use case diagrams – 시스템이 어떤 시나리오를 통해서 표현되는 것이 아닌가?, 이 각각의 시나리오들 별로 모델링 하는 것

>Sequence diagrams – 일이 이루어 질 때 누가(엑터) 누구에게 무엇을 그래서 결과가 무엇인지 모델링

>Class diagrams – 객체지향에서 나타나는 객체 또는 인스턴스를 정의함에 있어 클래스 별로 모델링

>State diagrams – 상태(단계) 별로 구분을 해서 나타내는 모델링

>>도구적 관점에서 이해할 것!

 

언제 사용

-요구사항 공학에서도 사용

-소프트웨어를 설계하는 단계에서도 사용가능

-기존 시스템 표현과 새로운 시스템을 표현할 때도 사용가능

-그리고 기타 등등의 문서화 작업을 할 때에도 사용가능

-지금 돌아가는 시스템을 설명할 때에도 사용가능

-직접적으로 코딩과 연계될 수도 있다.

 

>Context models

처음 시스템을 만들 때 가장 상위 레벨에 존재하는 것, 추상적

우리가 만든 시스템이 하나의 등장인물로 정의되는 것 – 이 등장인물이 행동을 할 것이고 그것은 요구사항 공학에서 정의한 것을 기반으로 이루어진다.

-경계를 정하는 것이 중요하다. (내부에서 무슨 일이 일어날지 밖에서 무슨 일이 벌어질지 그곳에 있는 것은 무엇이며 어떠한 상호작용이 일어나는지 정의하는 것이 중요함)

-이러한 경계가 어떤 위치를 가지고 있는지를 알 수 있다.

-> 멘탈케어 시스템의 context 모델링

경계를 정해두고 우리가 해야 되는 것과 안 해도 되는 것을 분명하게 함

ex. 외부에서 일어나는 것

처방을 관리하는 시스템, 처방을 관리하는 시스템, 환자정보를 관리하는 시스템, 레포트를 관리하는 시스템, 통계정보를 관리하는 시스템이 있음

멘탈케어 시스템과 위에 외부의 시스템들과 상호작용을 정의함(외부 시스템이 하는 일은 하지 않는 것이 맞는 것이다 -> 중복성 제거)

프로세스 모델링(위에 것들을 파악할 때 사용하기도 함) -> ex. 멘탈케어 정보를 작업을 할 때 좀 더 구체적인 정보를 받길 원함

그럴 때 병원의 프로세스에서 멘탈케어 시스템이 어떤 역할을 하는지를 볼 수 있음

예시) 병원에서의 강제 구금 프로세스(UML기반)

꽉차있는 원이 시작지점 -> 결정을 내리는 과정을 함 -> 환자에게 본인의 권리를 설명 or 강제 구금에 대해서 시스템 상에 입력 -> (마름모 – 판단) -> 위험한지를 판단함 -> ( 위험하다면 경찰을 부르고 or 가능하다면 병원에서 강제로 구금을 시킴) or (위험하지 않다면 병원 내에서 입원을 함) -> 관련 사람들에게 정보를 알려줌 or 처리된 정보를 업데이트함 -> 다음 프로세스로 넘어감

>>기본적으로 선을 긋고 우리시스템과 외부시스템의 관계를 표시할 때 주로 사용됨.

>>서로의 포지션을 확인함

 

Interaction models(상호작용 모델링)

>>우리의 시스템과 바깥의 시스템이 어떻게 상호작용을 하는지를 구현함

>>사람들과의 상호작용도 파악해야 한다.

>>유스케이스 다이어그램, 시퀀스 다이어그램들이 많이 도움이 됨

 

>유스케이스 모델링

>>특정 시나리오들에서 어떠한 행동을 하는지 표현하는 것 – 유스케이스, UML을 주로 사용

>>시스템이 동작하는 것이 많다면 그 각각을 분리해서 유스케이스로 만든다.

>>각각의 유스케이스의 주체가 되는 엑터들을 정의한다.

ex. 멘탈케어 시스템

등장인물 : 유스케이스를 실행시키는 사람, 환자 정보를 저장하는 시스템

엑터들 사이에 동작(데이터 전송)을 놓는다.

>>위와 같은 예시를 표로 정리할 수 있음(page18)

ex. Transfer data에 대한 유스케이스 다이어그램

엑터 : 유스케이스를 실행시키는 사람, 환자 정보를 저장하는 시스템

전체적 묘사 : 권한이 있는지 없는지를 확인함, 환자의 주소, 전화번호 등을 전송함, 환자에 대한 처방 또한 갈 수가 있다.

데이터 : 환자에 대한 정보, 환자에 대한 처방 정보

어떻게 시작이 되는지 : 정보를 입력할 시

이것이 끝 난지는 : PRS자료가 제대로 올라갔는지 또는 잘 못 받았는지를 확인을 통해 알 수 있다.

추가정보 : 입력되는 정보에는 환자의 정보와 PRS에 접근 가능한 권한이 있어야함

-> 관계도 정도로 표현이 됨

 

>>위에 것을 좀 더 세세하게 보기위해 시퀀스 다이어그램이 사용됨

엑터로 등장하는 사람(시스템을 사용하는 사람들)

이들 간의 상호작용을 그림으로 표현한다.

 

그림예제 - 정보를 입력하는 사람이 환자의 정보를 입력하는 과정(위에서 아래로 감)

환자의 정보를 입력하는 사람이 PRS에게 정보를 전달하기 위해 로그인 함 -> 분리되어서 진행됨 -> 정보 업데이트 요청 -> 그에 대한 유저 정보를 가져옴 -> 유저의 정보를 확인함 -> 유저의 접근 권한을 확인 -> 확인이 끝나면 PRS로 정보가 업데이트 됨 (여기그림은 권한이 허용된 방법만 나옴)

P : 환자의 입력정보를 받음, D : 데이터베이스 정보에 접근 함, AS : 합법적인지를 검사

이것들까지 추가해서 엑터는 총 5명이다!

->전송을 마치면 로그아웃을 함

>>시간에 따른 정보의 처리 흐림이다.

>Structural models -> 위와 같은 것들을 그림으로 모델링 하는 것

내부로 들어옴

객체지향 시스템으로 설명을 함

클래스 다이어그램을 빈번하게 사용됨.

-> 어떤 클래스들이 있고 객체들과 어떤 상호작용을 하는지를 보여주는 것이 주를 이룬다. -> 연결되어 있는 링크를 보여줌

환자라는 클래스가 있다 환자정보 클래스와의 관계(1:1)가 맺고 있음

소프트웨어를 짜겠다는 구성을 제시함

1..*(1보다 많다)

>>등장인물들을 맴버 함수로 표현하고 일어나는 행동들을 맴버 메서드로 표현 한다

프로그래밍 클라스 -> 유전의 법칙(is-relationship)

(has-relationship) -> 클래스 안에서 클래스의 객체를 가지고 있는 것

 

 

>>generalization(유전의 법칙)

->Inheritance(유전)

사용하는 가장 큰 이유 -> 재사용

ex. 슈퍼클래스/베이스클래스(추상적, 서브 클래스의 공통적인 기능들을 최소화 할 수 있다-재사용) -> 서브/드라이브클래스(세분화, 슈퍼클래스의 메서드나 변수들을 사용할 수 있다.)

프로그래밍을 할 때 우리가 다뤄야할 개념들은 매우 복잡하다. -> 이런 상황에서 구현을 최소화하기 위한 방법(일반화, 중복성의 제거-재사용, 하위의 것들은 상위의 내용을 가지고 있다.)

 

modeling systems -> generalization -> 객체지향의 클래스에서 많이 사용 됨

>>하위레벨(특정)의 것들은 상위레벨(추상화)의 것을 재사용하고 자신들만의 것을 특화시킴.

ex. 의사에 대한 분류

빈 삼각형 표시 -> UML – 서로 상하 클래스 관계임을 알려줌

 

>>Aggregation models

>>>클래스 안의 객체도 클래스이다! - 객체가 객체를 안고 있다.(has relationship)

ex. 자동차는 각각의 핸들, 시트, 바퀴 등과 같은 클래스 객체들을 가지고 있다.

>>>재사용(코드), 중복성 제거(데이터)

-> UML 기호로 빈 마름모 모양을 가짐

>>>현재 객체지향 프로그래밍 기법의 시스템 모델이 됨.

 

 

>Behavioral models(동적인 특성 모델링)

2가지 기법

-Data(현 웹기반, 우리가 처리해야 될 것들)

-Events(전통적, 마우스, 키보드 등의 입력정보, 센서 정보들)

>>Data-driven modeling

>>>비즈니스 시스템

>>>데이터들을 기점으로 처리하는 방점을 둠

>>>입력데이터로부터 처리를 통해 원하는 출력 값을 만든다.(해야 될 일이 많음)

>>>end-to-end 과정을 데이터의 관점에서 한 것

ex. 인슐린 펌프 예시 (Data-driven behavioral model)

>입력 데이터(혈당센서) -> 센서 값을 가져옴 -> 센서 데이터를 가지고 혈당 레벨을 정의 -> 보낼 인슐린 양을 계산(새로운 데이터 추출) -> 인슐린 요구사항을 정의 -> 펌프 명령을 계산 -> 펌프 명령 -> 펌프 컨트롤 -> 인슐린 투여

 

시퀀스 차트(page39) - 주문 프로세스

 

>>Event-driven modeling

>>>real-time systems – 전통적인 전자제품, 임베디드 시스템, 전화 시스템, 운영체제

>>>이벤트가 발생을 함(내부 이벤트, 외부 이벤트로 나뉨)

>>>상태를 기반으로 모델링을 많이 함

>>>state diagram – 상태의 변화를 표현함

ex. 전자레인지

상태와 상태의 의미, 이벤트들의 설명을 테이블로 나타내었다

 

>Model-driven engineering(있다고만 알기)

>>지금까지의 모델링 기법을 접목하여 자세하기 나타내보는 것 (UML 등으로)

>>그럼 개발자가 필요가 없고 프로그램이 만들어진다.

>>모델의 종류

- CIM(간단한 독립적인 모델)

- PIM(플랫폼의 독립적인 모델)

- PSM(플랫폼의 세세한 모델)

>>이렇게 자동적으로 만듬(번역이 어려울 수 있음)

>>결론적으로 가장 중요한 것은 도구이다.

>>에이자일과 상극이다!

>>일반적이지 않다...

 

5장 요약

-모델은 시스템 상세정보를 무시하는 시스템의 추상적인 뷰이다. 보완적 시스템 모델은 시스템의 컨텍스트, 상호작용, 구조 및 동작을 보여주기 위해 개발될 수 있다.

- 컨텍스트 모델(Context models)은 모델링 중인 시스템이 다른 시스템 및 프로세스가 있는 환경에서 어떻게 배치되는지를 보여줍니다.

- 사용 사례 다이어그램(Use case diagrams) 및 시퀀스 다이어그램(sequence diagrams)은 설계 중인 시스템에서 사용자와 시스템 간의 상호 작용을 설명하는 데 사용됩니다. 사용 사례(Use case)는 시스템과 외부 행위자 사이의 상호작용을 설명한다. 시퀀스 다이어그램(sequence diagrams)은 시스템 객체 간의 상호작용을 보여줌으로써 이에 더 많은 정보를 추가한다.

-구조모델(Structural models)은 시스템의 구성과 구조를 보여줍니다. 클래스 다이어그램(Class diagrams)은 시스템 및 해당 연결에서 클래스의 정적 구조를 정의하는 데 사용됩니다.

- 동작 모델(Behavioral models)은 실행 중인 시스템의 동적 동작을 설명하는 데 사용됩니다. 이 동작은 시스템에서 처리한 데이터의 관점 또는 시스템에서 응답(responses)을 자극하는 이벤트에 의해 모델링될 수 있습니다.

- 활동 다이어그램(Activity diagrams)을 사용하여 각 활동이 하나의 프로세스 단계를 나타내는 데이터 처리를 모델링할 수 있습니다.

- 상태 다이어그램(State diagrams)은 내부 또는 외부 이벤트에 대한 시스템의 동작을 모델링하는 데 사용됩니다.

- 모델 주도 엔지니어링(Model-driven engineering)은 시스템이 실행 가능한 코드로 자동 변환될 수 있는 모델 집합으로 표현되는 소프트웨어 개발에 대한 접근법이다.