System Sequence Diagram
객체란 ?
책임의 존재(알아야 할 책임, 행해야 할 책임 2가지 - attribute와 method, static과 dianamic)
프로그램의 상태 천이
프로그램은 상태를 바꾼다. 즉, 컴퓨터는 상태를 변화시키는 머신이다.
기억되는 상태 -> 그 상태를 변화시키는 동작으로 이루어진다.
따라서, 변수를 짜려면 세상에 필요한 상태(변수)를 잘 파악해야 한다.
소프트웨어를 바라볼 때 기억하고 있는 것들(정보, 변수) 과 어떨 떄 이 정보가 변화하는지(메서드)
- 기억하고 있는 것들은 내가 임시적으로 기억해야 할 것들이 있고, 장기적으로 상태를 파악해야 하는 것들이 있다.(모든 변수를 잘 알아야 하는 것은 아니다, 장기적으로 기억해야 하는 것(변수)를 기억해야 한다.)
- 또한, 모든 상태로 천이가 일어나지 않는다. 모든 상태 변화를 프로그램으로 짜지 않아도 된다. 일부만 짜도 된다. (행해야 할 책임)
keyword : 책임의 존재, 알아야 할 책임, 행해야 할 책임, 프로그램의 상태 천이
Use Case는 알아야 할 책임이다 ? 행위에 대한 책임이다 ?
answer : 둘 다이다. 알아야 할 책임과 행위에 대한 책임 모두 있다. 심지어 quilty requerment도 존재한다.(프로그램으로 구현할 수 없는 것)
우리는 프로그램을 짤 때 상태와 행위를 분리해 내야 한다.
이것을 위해서 좋은 수단이 될 수 있는 것이 Domain Model이다. Domain model을 통해 알아야 할 것을 추출, 분리할 수 있다.(no 행위)
Domain model은 UML diagram 중 class diagram을 사용하는 것이다. 상태에 대한 책임을 그림
SSD
프로그램의 흐름을 파악하는 것이 System Sequense diagram이다. 여기서 System이란 진짜 우리가 구현해야 할 소프트웨어 시스템이다. black box임을 가정하고 (이미 구현되었다고 가정하고) actor와의 상호작용을 저근다.
UML diagram 중 sequence diagram을 사용한다.(행해야 할 책임을 그림), sequence diagram은 위에서 아래로 간다. 점선(위에서 아래)가 시간의 흐름을 나타내고 화살표는 메세지 샌딩(행위)이고, 점선은 return, 블락, 반복, 등등도 나타낼 수 있음.
System을 만들면 안됨.
black box : 우리가 시스템 내부를 잘 모르는 것, 일반 user들이 아는 것
white box : 인터페이스, 컴포넌트 등등 다 잘 파악하고 있는 것
SSDs are derived from use cases
Use case 글을 actor와 system 간의 interaction으로 표현하는 것
Use case는 얼터네이티브 표현이 가능함
따라서 Use case 하나에 보통은 SSD 하나이지만 여러 개로 표현할 때도 있다.
USE case 만들 때 적용해야 할 규칙 : EBP(한 사람(actor)이 한 장소에서 한 번에 할 수 있는 일)
System Events
SSD 중간에 선을 그리는데 이 선이 바로 system boundary이다.
Use case diagram 그릴 때 system boundary를 사용한다.
Use case에서 system boundary를 넘나드는 화살표를 그리는데 얘는 system I/O(프론트엔드)이다.
USE case가 여러 개면 SSD도 여러 개일 것이다. 얘를 뽑는 잘 그리고 SYStem I/O가 뭔지 잘 파악하는 게 중요하다.(REST API 그리는 게 중요함)
passive한 system, Syste events 하나하나가 sequence diagram의 시작이 됨.
- 소프트웨어를 묘사할 때는 흐름을 얘기하기는 쉽지 않음. 그러나 장면 장면을 이어줄 수는 있다. Precondition과 Postcondition을 주는 것이다. 이것을 Operation Contract라고 한다.
Operation contract
여기서 operation은 system operation이다.
지금까지 배운 내용
- Use case는 sequense diagram으로 표현되어 있음 -> 시스템이 뭘 해야하는지 단위가 나와 있음
- Domain model -> 시스템 내부에 어떤 게 필요한지
- Use case diagram
Operation : Name of operation and parameters
Cross References :
Preconditions : 그 직전에 있었던 Postcondition이 precondition이 된다.
Postconditions : Conceptial model을 수정해나갈 수 있음, 사소한 것을 적는 것은 본질을 흐릴 수 있다.
ex ) entersale 과정
pre : Sale가 만들어졌다., item id가 이미 시스템 안에 존재함
post : SaleslineItem이 만들어졌다.(파라미터로 itemId가 들어옴), item과ㅑ 연결되었다. l.price를 i.price로 설정되었다. quentity total도 계산해야 한다.(넣을지 말지 결정), 몇 개살지,
pre와 post 컨디션을 어떻게 다뤄야 할 것인지 정하는 일만 남음
operaation contract는 Use case 하나에 귀속되지는 않는다.
Use Case 1개 : N개의 SSD
N개의 SSD : N개의 Operation contract
