1. 시스템 모델링
➡️ 시스템의 추상적인 모델을 개발하는 과정
각 모델은 시스템에 대한 서로 다른 관점을 보여준다.
주로, 각 모델들은 UML의 다이어그램 타입을 통해 시스템을 나타난다.
📌 현존하는 시스템과 새로운 시스템의 모델
✔️ Models of the Existing System
- 현존하는 시스템이 무엇을 하는 시스템인지 명확히 한다.
- 현존하는 시스템의 강점과 약점에 대해 논의한다.
✔️ Models of the New System
- 다른 시스템 이해관계자들에게, 새로운 시스템의 제안된 요구사항에 대해 설명한다.
- 디자인 제안을 논의한다.
- 구현과정을 위하여 시스템을 문서화한다.
📌 시스템을 나타내는 것에 대한 여러가지 관점들
✔️ External Perspective
시스템의 전후 사정(context)와 환경을 모델링한다.✔️ Interaction Perspective
시스템과 환경 사이의 상호작용을 모델링한다.✔️ Structural Perspective
시스템의 조직 체제나 데이터의 구조에 대해 모델링한다.✔️ Behavioral Perspective
시스템의 dynamic한 behavior, action, transition에 대해 모델링한다.
📌 Graphic Model을 사용하는 여러 방법들
✔️현존하는 혹은 제안된 시스템에 대한 논의에 초점을 맞춘다.
-> 이 모델은 불완전하고 공식적이지 않은 notation을 사용하고 있을 수 있다.(Incomplete & Informal)
✔️현존하는 시스템을 문서화한다.
-> 모델이 완전할 필요는 없지만, 틀리면 안 된다.(Don't have to be complete, but correct)
✔️시스템 구현을 생성한다. (Generate System Implementation)
-> 모델은 완벽해야 하고, 옳아야 한다. (complete & correct)
2. UML Diagram
✔️ UML이란? Object-Oriented 모델링을 위한 표준 언어!
📌 Use Case Diagrams
시스템과 그 환경 간의 상호작용을 보여준다.
📌 Sequence Diagrams
Actor와 System 간, 그리고 Sysem Component 간의 상호작용을 보여준다.
(Use Case보다 더 자세한 정보를 담는다.)📌 Class Diagrams
시스템의 Object Classe들에 대한 정보와, 그 class들 간의 관련성을 보여준다.
📌 Activity Diagrams
프로세스와 데이터 프로세싱과 관련된 Activity롤 보여준다.
📌 State Diagrams
어떻게 시스템이 외부적, 내부적 이벤트에 반응하는지 보여준다.
3-1. Context Model
어떻게 한 시스템이 다른 시스템/프로세스들이 있는 환경 안에서 위치해있는지 보여준다.
✔️ 해당 시스템과 환경 내의 시스템들 간의 관계 종류를 보여주지 않는다.
- 시스템의 producing data, consuming data나 시스템에서의 Physical Location에 대해 기재하지 않는다.
✔️ 그러나 해당 관계는 실제 시스템의 디자인과 요구사항에 영향을 미치기 때문에, simple context model은 단독으로 사용되지는 않으며 business process model 등 다른 모델들과 함께 사용된다.
예시 : Involuntary Detention에 대한 Simple Context Model + Activity Model
3-2. Interaction Model
1) Use Case Diagram
시스템과 external agent(human user/other system) 간의 상호작용을 모델링한다.
- 유저가 시스템과의 상호작용에서 어떤 것을 기대하는지 묘사한다.
- 상호작용의 간단한 overview를 보여준다.
✔️ Actor
Primary Actor(주도적 actor) ex. customer
Secondary Actor(수동적으로 request를 받는 actor) ex. Bank✔️ System
✔️ Relationship (Association)
Include : process a를 실행하면 b가 반드시 필요할 경우, a가 b를 'include'한다고 한다.
Extend : process b는 a에 의해 발생할 수도, 아닐수도 있는 프로세스일 경우 'extend'
Generalization : 상속 관계 표현✔️ Use Case
use case diagram은 매우 간단하기 때문에 tabular description과 함께 표현하면 좋다.
2) Sequence Diagram
✔️use case diagram의 자세한 버전
시스템 component간의 상호작용을 모델링한다.
시스템의 actor와 object간, 그리고 object와 object 간의 상호작용을 모델링한다.✔️use case diagram은 순서가 없지만, Sequence Diagram은 interaction의 순서를 보여준다.
✔️Alternative를 통해 조건문을 표현한다.
✔️Lifeline을 통해 각 actor, object의 활성화/비활성화 시기를 표현한다.
✔️Activation box를 통해 첫 interaction부터 마지막 interaction까지 activation 된 부분을 표현한다.
3-3. Structural Models
➡️ 시스템을 구성하는 컴포넌트들에 대해서, 그 시스템의 조직도를 보여준다.
구현 관점에서 가장 유용한 모델이다.
1) Class Diagram
SW 시스템에서 class의 static structure을 모델링한다.
시스템의 class과 class간 관계를 보여주는 object-oriented 시스템 모델링아더,
✔️Class, attributes, methods, realtionship으로 구성되어 있다.
✔️Visibility
-은 private 변수(해당 class 내에서만 사용), +는 public 변수(모든 class에서 이용가능), #은 protected 변수(해당 클래스+상속 받은 클래스에서만 사용)이다.
✔️ Relationship
Interitance : 상속
Association : 관계
Aggregation : 전체/파트의 관계이지만, 결합 정도가 약한 것
Composition : 전체/파트의 관계이지만, 결합 정도가 강한 것
Multiplicity : 대응 관계의 수 (몇대 몇 대응인지)
3-4. Behavioral Models
➡️ 시스템의 dynmaic한 behavior에 대한 모델.
시스템이 stimulus(data/event)에 대해 어떻게 반응하는지 보여준다.
많은 비지니스 시스템은 data-driven이고, 많은 real-time 시스템은 event driven이다.
📌 Data Driven Model
input과 output에 관련된 action의 sequence를 보여준다.
1) Activity Diagram
activity와 data의 flowing을 표현한 모델.
📌 Event Driven Model
어떻게 시스템이 external, internal event에 반응하는지 보여준다.
시스템이 유한한 개수의 state와 event를 갖고 있다고 가정한다.
2) State Diagram
✔️system state : state에서 벌어지는 action
✔️transition : 한 상태에서 다른 상태로 옮겨갈 때의 stimuli
4. Model-Driven Architecture
📌소프트웨어 디자인/구현에 대한 Model-focused approach
"Model이 있으면, model로부터 sw 플랫폼을 실행하는 데 필요한 프로그램 코드가 생성될 수 있다"를 가정으로 하고 주장한다.
✔️MDA에서의 3가지 System Model Type
CIM : 중요한 도메인 Abstraction (가장 general한 모델링)
PIM : 한 플랫폼에서 다른 플렛폼의 mapping (보다 specific)
PSM : PIM을 더 구체적인 디테일로 모델링(가장 구체적 modeling)
