System modeling
- 시스템의 추상적 Model 작성
- UML ( Unified Modeling Language ) 를 사용한다.
기존 모델
- 기존에 존재하던 시스템의 Model은 요구사항 공학 과정에서 사용 가능하다.
- 새로운 시스템의 Model은 다른 시스템 이해관계자들에게 요구사항을 설명하는데 도움을 준다.
- Model 자체는 완벽하게 혹은 부분적으로 가능하다.
Context model
- 시스템과 다른 외부 시스템과의 상호작용
- 시스템 밖에서 작동을 모사한다.
- 환경 내부 다른 시스템은 단순하게 모사한다.
- 다른 시스템과의 관계를 보여주기 위한 Architecture model.
System boundaries
- 시스템의 안과 밖을 설정한다.
- 시스템이 관여하는 부분을 결정한다.
- 이를 정하는것은 시스템 정책의 설정과 같다.
Process model
- Context는 환경 내 다른 시스템을 간단히 모사
- 시스템 외부와 시스템이 어떻게 연결되어 있는지를 보여준다.
- UML Activity diagram < 프로세스/데이터 프로세싱 모사 > 를 통해 표현 가능하다.
Interaction model
- 사용자<>System, System<>System, Component<>Component 간 상호작용
Use case modeling
- 각각의 usecase는 외부에 어떤 기능을 제공할지를 수반한다.
- usecase의 actor는 다른 사람 혹은 다른 시스템이다.
- 환경과 시스템의 상호작용
예시
- 사각형으로 시스템을 감싼것은 바로 System boundary.
Structural model
- 시스템의 구조
- component와 그들의 관계
- 클래스 다이어그램으로 표시한다.
Behavioral model
- 기능에 따라 동작하는 행위와 이벤트에 반응하는것
- 데이터가 어떻게 흐르는지, 이벤트가 어떻게 흐르는지에 따라 정의한다.
Data Driven Modeling
- 데이터에 의해 이끌어진다 ( Driven by data )
- 입력 데이터를 받아 출력 데이터를 만들어내는 일련의 액션
- end-to-end 프로세스의 요구사항을 분석하는데 유리하다.
State machine model
- 상태와 전이를 통해 구성된다
- DFA / NFA
- 박스 안에 시작 상태가 존재한다.
UML Datagram 종류
Activity Diagram
- 데이터 프로세싱 및 프로세스 과정에서 수반되는 활동
Use case Diagram
- 시스템과 사용자간 상호작용
Sequence Diagram
- usecase에 대해 어떤 interaction이 일어나는지에 대한 순서
Class Diagram
- 프로그램 내 객체지향 클래스간 관계
State diagram
- 내/외부 이벤트에 시스템이 반응하는 방법
그래픽 모델의 사용
- 모호하지 않고 정확하게 작성 가능
- 구현이 쉽다
Object class aggregation<집합> model
- 클래스가 어떻게 다른 클래스들로 이루어졌는지를 표현
Model driven engineering
- 프로그램보다 Model에 중점을 둔 접근 방식
- 실제 동작하는 프로그램은 모델로부터 자동적으로 생성된다.
- 개발 초기단계에 해당한다.
장점
- 높은 단계의 추상화를 허용한다.
- 자동 코드생성을 통해 다른 플랫폼에 저렴히 구현 가능하다.
단점
- 추상화가 구현에 필요하지 않을수 있다.
- 코드 생성 번역기 개발이 어려울수 있다.
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가 추가된다.
만능 컴덕후 겸 번지 팬