[소프트웨어공학] #5 System modeling

5-1: System modeling

: 개발 과정에서의 산출물

시스템에 대한 추상적인 모델.

관점이 다양하니 여러가지 모델.

시각적인 표기법을 사용하여 표현

이해를 돕는다-시스템의 기능, 고객과의 소통.

 

기존 및 계획된 시스템 모델

기존 시스템의 모델은 요구사항 공학에서.

-기존 시스템이 무엇을 하는지, 장점과 약점을 논의할 기초로 사용될 수 있음.

-새로운 시스템의 요구사항 유도

 

새로운 시스템의 모델도 요구사항 공학에서 소개된 요구사항을 다른 시스템 stakeholder에게 설명하는것을 도움

-공학자는 이 모델들을 설계 proposal 논의에 사용, 구현을 위한 문서에 사용

 

모델기반 공학 프로세스에서, 시스템 모델에서 전체 혹은 일부 시스템 구현이 가능하다.

 

System perspectives

-external perspective: 시스템의 context나 환경을 어디서 모델삼았는지.

-interaction perspective: 시스템과 그 환경간 혹은 시스템의 component간 상호작용을 어디서 모델 삼았는지.

-structural perspective: 시스템의 조직이나 시스템이 처리할 데이터의 구조가 어디서 모델삼았는지

-behavioral perspective: 시스템의 직접적 행동이 어디서 모델삼았는지와 이벤트에 어떻게 대응하는지.

 

다이어그램 종류

존재하는/소개할 시스템에 대한 논의

존재하는 시스템에 대해 문서화할 방법

자세한 시스템 서술-시스템 구현을 생성할 수 있는

 

5-2: Context models

context(상황, 맥락): 있거나 일어나거나 하는 상황. 

특정 이벤트나 상황에 관계된 영향이나 이벤트

 

Context model: 시스템의 운영적인 맥락 표현. 시스템 경계 밖에 무엇이 있는지 보여줌.

사회적, 조직적 우려가 시스템 경계 위치의 결정에 영향.

구조적 모델은 시스템 및 그 시스템과 다른 시스템과의 관계를 보여줌.

 

System boundary

시스템의 안밖에 무엇이 있는지를 정의.

시스템 요구사항에 큰 영향

결정하는 것은 정치적 판단.

 

Process perspective

context 모델은 환경 내의 다른 시스템을 간단하게 보여줌.

Process model은 어떻게 시스템이 개발되어지는지를 넓은 비즈니스 프로세스에서 드러낸다.

UML 행위 다이어그램(activity diagram): 비즈니스 프로세스 모델을 정의하는데에 사용됨.

 

5-3: Interaction models(상호작용 모델)

사용자 상호작용 모델링은 사용자의 요구사항 식별에 중요

시스템-시스템 상호작용 모델링은 일어날 소통 문제를 강조한다.

요소 상호작용 모델링은 이해를 돕는다.

Usecase diagram과 시퀸스 diagram은 interaction 모델링에 사용된다.

 

Usecase modeling

use case는 요구사항을 이끌어내는 것을 돕기 위해 원래 개발됨. UML에 포함되어있다.

각 use case는 각 이산적인 task들-시스템과의 외부 상호작용을 포함한-을 표현

usecase의 Actor는 사람 또는 다른 시스템

use case의 overview를 나누고, 좀더 자세한 문자적 형태로.

 

Sequence diagrams

UML의 일부. 시스템의 actor와 object간의 상호작용 모델링.

상호작용의 sequence를 보여줌.

actor와 object는 다이어그램의 위쪽에 나열. 수직으로 점선.

object끼리의 상호작용은 주석달린 화살표로 표시

 

5-4: Structural models(구조적 모델)

시스템과 그 관계들로 만들어진 시스템 구조를 보여줌

정적(static): 시스템 설계의 구조를 보여줌

동적(dynamic): 실행 중일 때의 시스템 구조를 보여줌.

시스템 아키텍처를 설계할 때에 시스템의 structural model을 제작

 

Class Diagram

: 객체지향 시스템 모델-시스템 내의 클래스가 어떻게 구성되었는지를 모델링

한 종류의 시스템 객체의 객관적 정의

association은 클래스들간의 연결

object(객체)는 실세계의 무언가.(환자, 의사 등등)

 

Generalization

: 복잡성을 관리하는 everyday technique

: 더욱 일반화된 클래스의 entity들을 위치시킴

공통 표기

Object class aggregation models

-aggregation 모델은 클래스들이 다른 클래스들로 구성되었는지 보여줌.

- part-of 관계와 유사함.(semantic data model)

 

5-5: Behavioral models

: 동작중인 시스템의 동적 행위를 모델링

-무슨 일이 일어나는지/일어날 것인지

Data 흐름: 어떤 데이터가 시스템에서 이동되는지

Events 흐름: 어떤 이벤트가 일어나는지.

 

Data-driven modeling

많은 비즈니스 시스템이 이런 형태

action의 순서들을 보여줌.

요구사항 도출에 유용하다.

 

Event-driven modeling

실시간 시스템에서 이벤트 처리. 데이터 처리가 적은 경우.

시스템이 어떻게 내외적 이벤트들에 반응하는지.

시스템은 유한한 상태나 이벤트를 가진다. 하나에서 다른 상태로 연결

 

State machine models(finite state machine-유한상태머신)

내/외부적 이벤트에 반응하는 시스템의 행동을 모델링

실시간 시스템들을 모델링-자극에 대한 시스템의 반응을 보여야함.

노드들로 시스템의 상태를, arc들로 그 노드들 사이의 이벤트들을 보여준다.

 

5-6: Model-driven engineering(MDE)

프로그램보다 모델을 중시.

프로그램은 모델에서 자동적으로 생성될 수 있음.

제안자 왈: 추상화 수준이 높아짐에 따라, 더이상 프로그래밍 언어의 디테일이나 실행 플랫폼에 대해 신경쓸 필요 없다.

 

아직 초기단계.

장점: 고수준에서 시스템 결정. 코드 자동화

단점: 정확한 구현 표현엔 한계가 있음. 코드 생성이 더 오래 걸릴 수 있다.

 

모델 기반 아키텍처

더욱 범용적 모델-기반 공학의 precursor

모델에 초점을 둔 approach-소프트웨어 설계와 구현

다른 수준의 추상화의 모델이 생성.

 

CIM/PIM/PSM

 

Agile methods and MDA

반복적 접근법을 개발을 위해 지원.->agile method와 함께 사용될 수 있음.

agile+모델 기반 공학 == 편--안

변환이 완전히 자동적이고, PIM에서 완전한 프로그램이 생성될 수 있다면

 

factor의 범위는 MDE/MDA 채택을 제한

특성화된 도구는 모델을 어떤 수준에서 다른 수준으로 변환하는데에 필요하다.

툴 유용성은 제한되고, 조직은 그들의 환경에 도구 적용과 커스텀을 필요로함.

MDA를 사용하여 개발된 긴생애주기의 시스템에서, 회사들은 그들 고유의 도구를 개발하는 것을 꺼려하거나, 폐업할 작은 회사들에 의존

모델은 소프트웨어 설계에 대해 토론을 용이케하는 좋은 방법.

(물론 토론하기 좋은 추상화가 구현에 좋은 추상화는 아님)

대부분의 복잡한 시스템에서, 구현이 주된 문제는 아님.(요구사항 공학, 보안, 의존성, 이전 시스템과 통합, 테스팅 등등)

플랫폼 독립적인 것은 크고, 긴 생애주기의 시스템에서 유효

MDA의 진화와 같은 기간에 광범위한 agile 채택은 모델 기반 방식에서 다른 곳으로 주의를 돌림.