▶ 상태 다이어그램(State Diagram)이란 ?

사건이나 시간에 따라 시스템 객체 상태 변화를 표현한 그림. "단일 객체"의 상태를 나타냄. 시스템의 변화를 잡아내기 위하여 사용. 분석가, 설계자, 개발자 들이 시스템 내의 객체 행동을 이해하는데 큰 도움을 줌.


◎상태 다이어그램의 중요성

- 한 객체에서 일어날 수 있는 모든 변화의 양상을 잡아내어 모델링 함. 분석가, 설계자, 개발자들이 시스템내의 객체 행동을 이해하는데 도움을 줌. 클래스 다이어그램이 정적인 모습을 보여주는데 반해, 상태 다이어그램은 각 객체의 행동의 동적인 상황을 보여줌. 개발자 입장에선 각 객체들이 어떻게 행동하는지 쉽게 정확히 파악할 수 있게 만듦으로써 객체 구현에 있어서 고민을 덜어줌.


표현 

- 상태의 표현 : 모서리가 둥근 사각형으로 표현

- 상태 전이의 시작점 : 속을 칠한 원으로 표현

- 상태 전이의 종료점 : 속을 칠한 원을 둘러싼 원으로 표현 

- 상태 전이선 : 화살표 머리가 달린 실선


◎ 상태 아이콘에 넣는 정보

이름, 속성, 오퍼레이션의 세 영역으로 나누어 상세한 정보를 넣을 수 있다. 


이름 - 상태 이름 (필수) 

속성 - 상태 변수 (옵션) : 타이머나 카운터 처럼 상태 진행에 도움을 주는 데이터

오퍼레이션 - 활동(Activity - 옵션) : 사건(Event)과 동작(action)으로 이루어짐

예) 팩스 기계의 상태 정보의 표현과 전이

◎ 상태전이 선에 추가되는 정보 : 사건과 동작

사건(촉발사건 - Trigger event) : 전이가 일어나는 원인을 제공

연산(동작 -action) 실제로 수행되어 상태변화를 일으키는 연산


사건과 동작은 상태 전이 선에 가깝게 붙여준다. '/'을 사용하여 사건과 동작을 구분시킨다. 

◎ 상태 전이 선에 추가되는 정보 : 전이조건

어떤 조건에 따라 상태가 전이 될 때. 

조건에 따른 상태 전이의 분기가 일어날 때.

'[ ]' 를 사용하여 조건을 명시함

 

예) 앞의 GUI예에서 어떤 조건을 만족하면 스크린 세이버가 작동하는 상태로 됨.

◎ 하위상태 : 상태안에 상태가 있을때, 안에 있는 상태를 말함.


◎ 순차적 하위상태

- 하위 상태의 전이가 순차적으로 이루어짐. 

예) 앞의 GUI 예제에서 [작동] 상태의 하위 상태 전이를 나타낸다. 즉, [작동] 상태인 동안 사용자의 입력을 화면에 표현하는 하위 상태들의 전이 과정을 표현한 것이다. 

◎ 동시적 하위상태

- 하위 상태의 동시 진행성을 표현

동시 진행하는 순차적 하위 상태를 점선으로 구분지음

예) 위의 GUI 예제에서 "사용자 입력을 화면에 표현"하는 하위 상태전이 단계와 더불어 "시스템 내의 시간을 정해진 간격마다 화면에 표현" 하는 또 다른 하위 상태 전이가 일어나는 과정을 나타냄.

즉, 우리가 워드를 치는 동안 윈도우의 "시작 메뉴바" 오른쪽에 시계는 분 마다 바뀐 값을 표현하는 것을 말함

◎ 이력상태 (History State) 

주어진 객체가 복합 상태를 벗어날 때 활성중인 하위 상태를 기억해 두는 상태.


표현 : 원으로 둘러싸인 "H"문자로 표현

예) GUI 작동 중 일정 시간에 의해 스크린 세이버가 작동하다가 다시 원 상태로 되돌아 올 때 이전의 기억된 상태로 되돌아 오는 것을 나타냄


◎ 메시지와 신호 (Message & Signal)

메시지 : 한 객체가 다른 객체에게 전송하는 메시지 즉, 상태전이를 일으키는 촉발 사건을 말함

신호 : 메시지를 받는 객체의 상태 다이어그램에서 전이를 촉발시키는 메시지를 말함.

신호객체 (Signal Object)는 속성을 가지고 있다. 신호는 객체이기 때문에, 기존의 신호를 상속받아 새 신호를 만드는 일도 가능하다.


쓰임새 (USE CASE) 란 ?

시스템의 사용에 대한 시나리오의 집합


목적

- 사용자의 관점에서 시스템을 모델링하기 위함. 즉, 사용자가 시스템에 대하여 바라는 바를 표현함으로써 사용자의 시점을 빨리 이해하고 쓸모있고 (Useful), 쓸 수 있는 (Useable) 시스템을 만들 수 있도록 함.


사용 

- 대게 의뢰인과 개발팀이 참조하는 설계문서의 한 부분으로 사용.

- 새로 만들어진 시스템을 테스트하는데 사용 : 사용자의 시스템 사용 시나리오를 표현한 것이기 때문에 테스트도 그 시나리오에 따라서 하면 됨


시스템 분석가와 사용자 힘을 합쳐 시스템의 사용 방법을 결정하는데 도움이 된다. 시스템이 가진 User Interface 설계 & 프로그래밍 방식에 매우 도움이 되는 다이어그램

[요구사항 수집]의 "시스템 요구사항 파악"의 과정과 [분석]과정에서의 출력물 → 사용자와의 대화를 통하여 얻어낸 정보를 표현한다. 



▶ USE CASE 의 분석과정 및 사용 방법 : 사용자를 만나 의견을 듣는것으로 시작 

1. 시스템 사용자를 시스템 분석과 설계의 초기 단계에 참여시킴

2. [요구사항 수집] 의뢰인과 대화 → 초기 클래스 다이어그램 → 사용하고 있는 용어를 통해서 개념정리 → 사용자 와의 대화가 유연해짐 

3. 사용자와 대화 → 설계하고자 하는 시스템을 가지고 어떤 일을 하는지 질문 → 얻어낸 대답은 미래에 USE CASE 다이어그램을 만드는대 토대로 사용

4. USE CASE 에 대한 간단한 설명을 붙임 → 설명이 많을 수록 사용자와 할 수 있는 대화의 밀도도 높아진다. 


USE CASE 의 재사용을 위한 방법 : 

- 포함(inclusion) : 다른 쓰임새를 구성하는 하나의 진행 과정으로 쓰임새를 사용.

- 확장(extension) : 기존의 쓰임새에 몇 개의 단계를 추가하여 새로운 쓰임새를 만듦.


※ USE CASE 만들때 주의사항

 - 해당 시나리오를 시작할때 만족 되어야 하는 선행조건

 - 시나리오가 완료될 때 만족되어야 하는 종료조건




행위자 (Actor)

시스템과 교류하는 사람이나 시스템 또는 장치, UseCase를 시작시키고, 구성하는 진행단계가 끝나면 그 결과를 받는다. 막대기로 사람모양을 표현, 행위자의 이름은 막대인간 아래에 쓴다. 


쓰임새 (UseCase) 

타원으로 표현, 쓰임새의 이름은 타원 안쪽 또는 아래에 쓴다. 쓰임새를 시작시킨 행위자는 왼쪽, 결과를 받는 행위자는 오른쪽에 표현. 행위자와 쓰임새 간의 연결은 실 선으로 그림. 


시스템 

쓰임새를 둘러싸는 사각형으로 표현, 행위자는 대게 시스템 외부에 있는 반면, 쓰임새는 시스템 내부에 존재한다. 즉, 쓰임새분석을 통하여 시스템과 외부세계와의 경계를 효과적으로 보여줄 수 있다.



[시나리오의 진행단계 나타내기]


- 쓰임새는 시나리오로 진행되며, 각 시나리오는 진행단계로 이루어진다. 

- USECASE를 구성하는 시나리오는 각각의 USECASE 다이어그램의 페이지에다가 텍스트로 적어둔다. 

- USECASE 다이어그램에  Note를 붙임으로써 표현할 수 있지만, 너무 지저분하게 보인다면 다이어그램의 생명인 '명확성'을 잃어버릴수 있다. 


 작성요령

1. USECASE를 시작하는 ACTOR

2. USECASE가 시작하는데 필요한 선행조건

3. 시나리오의 진행단계

4. 쓰임새가 끝나는데 필요한 종료조건

5. 쓰임새의 결과를 받는 행위자

6. 쓰임새의 가정 - Ex) "한번에 소비자 한명이 음료수 자판기를 사용한다" 등..

7. 간단한 한 문장 정도의 설명문


포함(Include) - 쓰임새가 다른 쓰임새를 포함하는 관계

 여러 쓰임새에서 공통으로 중복되는 시나리오가 있다면 이 시나리오를 따로 분리하여 새로운 쓰임새로 만들고 , 새로 만든 쓰임새를 각 쓰임새 마다 포함시키면 됨. 사용하려는 쓰임새가 사용되어지는 쓰임새를 필수적으로 포함해야 한다. 


포함된 쓰임새는 절대로 단독으로 존재할 수 없으며, 전체 쓰임새의 부분으로만 존재한다. 


표현

- 포함관계에 있는 쓰임새 사이를 쇄선으로 잇고, 포함되어지는 쓰임새 쪽에 화살표 머리를 둔다.

연결선 위에는 스테레오 타입 <<include>>를 붙인다. 


Ex) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 USECASE 다이어그램

→ "내용물 보충하기" 쓰임새와 "수금하기" 쓰임새 시나리오에서 공통으로 중복된 보안장치 해제나 보안장치 관련 설정과 관련된 진행 단계들을 따로 떼어내서 새로운 쓰임새로 만들고 포함시켰다. 



확장(Extend) - 쓰임새와 그 쓰임새를 확장한 확장 쓰임새의 관계

쓰임새의 시나리오에서, 어떤 조건에 따라 특정한 진행 단계의 행위를 확장하고자 다른 쓰임새를 참조하는 것을 말함. 이 때 확장 용도로 사용하기 위하여 참조되는 쓰임새를 '확장 쓰임새' 라고 함. 이 확장 쓰임새를 참조하는 쓰임새를 기본(Base) 쓰임새라 한다. 확장 쓰임새를 참조하는 시나리오의 특정한 진행단계를 확장포인트(extend point)라 한다. 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으로, 어떤 조건이 부합되어야만 포함되는 쓰임새를 표현한다. 


따라서, 포함 관계의 쓰임새와 달리 확장 쓰임새와의 관계는 선택적이다. 

※ 기본 쓰임새에서 특정한 시나리오의 진행 단계의 확장이기 때문에 확장된 쓰임새는 절대로 단독으로 존재할 수가 없다.


표현   

두 쓰임새 사이를 쇄선으로 잇고, 기본 쓰임새 쪽에다가 화살표 머리를 둔다. 연결선 위에는 스테레오 타입 <<extend>> 를 붙입니다. 


예) 음료 자판기의 "내용물 보충하기" 쓰임새에서 각 음료수 마다 판매실적이 엇 비슷할 때는 문제가 없지만, 만약 음료수 마다 판매실적이 두드러지게 차이가 난다면, 우리는 판매실적이 따라 채우는 음료수의 양을 달리해야 할 것이다. 즉, 특정한 조건(판매실적 차이가 클 때) 이 만족 되었을 때 판매실적에 따라 달리 보충하도록 기존의 "내용물 보충하기" 쓰임새를 확장한 "판매실적에 따라 보충하기"라는 새로운 쓰임새를 만들고 확장관계를 가지게 했다. 


일반화 (Generalization) 


- 쓰임새를 상속하는 것을 의미 

- 상속을 해주는 쓰임새를 "부모 쓰임새"라 하고, 상속을 받는 쪽을 "자식 쓰임새"라고 한다. 

- 자식 쓰임새는 부모 쓰임새의 모든 행동과 의미를 물려 받으며, 여기에 자신만의 행동을 추가 할 수 있다. 

- 부모 쓰임새가 등장하는 곳에 자식 쓰임새를 대신 놓을 수 있다. 

- 두 쓰임새 사이를 실 선으로 연결하고, 부모 쓰임새 쪽에 속이 빈 화살표 머리를 붙인다. 

- 일반화 관계는 행위자(Actor)사이에도 적용할 수 있다. 

- 예) "음료수 사기" 쓰임새에서 상속받은 "음료수 자~알 사기" 쓰임새가 있다. 이 자식 쓰임새에는 "음료수 사기" 쓰임새의 모든 행동과 의미를 사지고 있고 추가적으로 '얼음추가', '여러 음료수 혼합하기' 등의 행동을 갖을 수 있다. 


예) 음료를 보충하는 '공급자'가 있고 수금을 하는 '수금원'이 있다. 그러나, 이 두 행위자 모두 음료수 제공 업체 직원으로 볼 수 있다. 


그룹화

관련된 쓰임새를 하나의 패키지로 그룹화 하는것. 시스템이 여러개의 서브 시스템으로 구성되어 있거나, 시스템에 대한 다양한 요구를 수집하기 위하여 사용자의 의견을 조사할 때 (즉, 요구사항이 각각의 쓰임새로 표현되기 때문에) 그룹화를 한다. 패키지 다이어그램에서 패키지 안에 관련되 쓰임새를 넣어서 표현


예) 가계부 시스템에서 통장 관리 관련된 쓰임새를 패키지로 그룹화 한것


[요구사항 수집]과 [분석] 영역에서의 USECASE 다이어그램


1. 의뢰인과의 인터뷰

2. 시스템 분야 (문제해결 대상이 되는 Domain)에 대한 기초가 되는 Class Diagram을 그림

3. 용어 정리후 사용자와의 인터뷰

4. 행위자의 추상적 수준의 USECASE 다이어그램을 그림으로써 기능적인 요구사항 정리

5. 사용자와의 계속적인 인터뷰를 통한 시스템 요구사항 구체화 → USECASE 모델은 상세한 자신의 시나리오를 가지게 되고, 포함관계 & 확장관계가 나타나게 됨.


* 그 분야에 대한 이해가 부족하게 되면 쓰임새가 쓸데없이 많아지게 되고 시스템 설계와 개발 작업에 오히려 발목을 잡히게 됨


1. 클래스 다이어그램


- 가장 중요한 다이어그램이며, 분석/설계 단계에서 모두 이용, 작성합니다. 이는 구현시 각 클래스로 표현됩니다. 초기 다이어그램은 객체와 클래스가 혼합되어 나타나지만 후반부로 가면서 구체화되어 시스템의 구현객체로 표현됩니다. 

- 클래스는 지식 도메인에 기반한 어휘와 용어로부터 만들어집니다. 시스템분석가는 의뢰인과 상담하여 그들이 가지고 있는 지식 도메인을 파악하여 정리하고, 그 도메인에서 발생되는 문제를 해결할 컴퓨터 시스템을 설계해 나가면서, UML에 사용할 용어를 선정하고 이것을 클래스로 모델링 하는 것입니다. 

- 의뢰인과 대화속에서 명사와 동사에 귀를 기울여햐 합니다. 명사는 클래스의 이름이 될 확률이 높기 때문이고 동사는 모델링한 클래스의 Operation이 될 가능성이 있습니다. 

- 클래스의 핵심이 되는 리스트(클래스 이름, 속성, 오퍼레이션)를 모두 정리한 다음에는 각각의 클래스가 의뢰인의 업무에서 어떤 역할을 할지에 대하여 묻도록 합니다. -> 이에 대한 대답은 클래스 책임 설명으로 적을 수 있습니다. 



명사 : 볼, 바스켓, 팀, 선수, 가드, 포워드, 센터, 슛, 슛시간, 3점 라인, 자유투, 파울, 자유투라인, 코트, 게임시간

동사 : 슛하다, 드리블 패스, 파울, 리바운드 (이 외에도 개인의 상식을 동원해서 클래스 모델링에 사용할 수 있습니다.)


다음은 이런 정보를 바탕으로 만든 Class 다이어그램입니다. 이렇게 만든 클래스 다이어그램은 나중에 다시 감독과 이야기할때 충분한 기본자료로 사용하여 더 많은 정보를 얻어내는데 도움을 줄 것입니다. 


연관 (Association)

클래스가 개념적으로 서로 연결되어 있음을 의미합니다.


- 각각의 클래스마다 역할을 표시할 수 있습니다. 

- 하나의 클래스가 여러클래스와 연관을 맺을 수 있습니다. 

- "->" 또는 <-" 화살표 표시를 사용하여 관계의 방향을 나타낼 수 있습니다. 



연관클래스


- 연관의 속성과 오퍼레이션을 모델링할때 사용합니다. 연관클래스는 연관선과 점선으로 연결되며, 다른클래스와의 연관을 가질수도 있습니다. 


객체가 클래스의 인스턴스인 것처럼, 연관도 자신의 인스턴스를 가질 수가 있습니다. 어떤 특정한 선수가 특정한 팀에 소속되어 있는 관계를 생각하면, 이때의 "운동하다" 연관관계를 링크(link)라고 부릅니다. 링크는 두 객체를 선으로 이어서 나타내며, 객체에 밑줄 긋듯이 링크에도 밑줄을 긋습니다. 



다중성(Multiplicity)


- 연관되어 있는 두 클래스 사이에서 한 클래스의 객체와 관계를 가질수 있는 다른 클래스의 객체 개수. 이것을 다이어그램에서 나타내면 해당 클래스 가까지에 객체의 수를 써줍니다. 예를 들면, 팀의 입장에서 보면 다섯명의 선수와 연관되어 있지만 선수의 입장에서 보면 한팀과 연관되어 있다는 것입니다. 


표기 

- UML은 "more"과 "many"를 표현하는 기호로써 '*' 를 사용합니다. 

예) 

- 1..* -> 1또는 그이상

- 2..7 -> 2이상 7까지

- 5,7 -> 5 또는 7


상속과 일반화(Generalization)


- 한 클래스는 다른 클래스로부터 속성과 오퍼레이션을 물려 받을 수 있습니다. 이것을 객체지향 개념에서는 "상속"이라 하고, UML 에서는 "일반화"라고 합니다. 상속관계에서 상속을 받는 쪽을 Child Class 또는 Sub Class라고 하고, 상속을 해주는 쪽을 Parent Class 또는 Super Class라고 합니다. Sub Class에서 Super Class 쪽으로 속이 빈 화살표를 연결합니다. 이러한 타입의 연결관계를 "...의 일종(is a kind of) 라고 부릅니다.


- 상속관계를 모델링 할 때에는, 반드시 서브 클래스가 수퍼 클래스에 대해 "is a kind of" 관계를 가지도록 만들어야 합니다. 

- 만약 두 클래스가 이 관계로 맺어지지 않는다면, 차라리 다른 타입의 관계를 맺어주는 것이 더 낫습니다. 


Root Class : Super Class를 가지지 않는 클래스

Leaf Class : Sub Class를 가지지 않는 클래스  



★ 어떤 Sub Class의 Super Class가 있을때, 만약 이 Super Class의 구체적인 인스턴스를 만들 필요가 없을때에는 "추상 클래스"로 만들자. 즉, 클래스의 객체를 생성하지 않는 클래스를 "추상 클래스"로 만듭니다. 

표기: 클래스명을 이탤릭체로 씁니다. 

의존관계(Dependency)

- 한 클래스가 다른 클래스를 사용하는 관계를 말합니다. 예를 들자면 "시스템"클래스와 "폼" 클래스가 있는데, "시스템"클래스는 '폼_출력(form:폼)' 이라는 Operation을 가지고 있을때, 이 "시스템"이 화면에 표시해주는 서식은 전적으로 "폼" 클래스에 따라 달라집니다. 이 상황을 UML로 표기하려면 "의존대상" 이 되는 클래스를 향해 점선으로 긋고 화살표 머리를 붙여주면 됩니다. 

집합연관(Aggregation)


 하나의 클래스가 여러개의 컴포넌트 클래스로 구성되어 있는 경우가 있습니다. 즉, 컴포넌트 클래스와 전체 클래스가 "부분-전체"연관 관계를 가질때 집합 연관이 됩니다. 

표기 : 컴포넌트 클래스와 전체 클래스를 선으로 잇고, 빈 마름모꼴을 전체 클래스 쪽에 붙여서 나타냅니다.

복합연관(Composition)


강한 집합연관으로써 각 컴포넌트 클래스가 오직 하나의 전체 클래스에서만 의미를 가질때, 복합연관으로 표현 합니다. 

표기 : 각각의 컴포넌트는 전체 클래스 쪽으로 향하여 안이 채워진 마름모 꼴의 화살표로 연결합니다. 


인터페이스와 실체화


- 어떤 클래스들이 동일한 Super Class와 관계를 가지지 않았는데, 같은 시그니처를 가진 Operation이 존재한다면 이것은 Operation의 재사용으로 간주 됩니다. 이런 재사용을 위한 Operation 의 집합을 인터페이스라고 합니다.


- 인터페이스는 클래스의 일정한 행동을 나타내는 Operation의 집합으로, 다른 클래스에서 사용될 수 있습니다. 자바에서 인터페이스는 method의 prototype 만 선언되어 있고, 인터페이스를 구현(Implementation)한 클래스에서 method를 정의합니다. 이것을 UML에서는 실체화(realization) 라고 합니다. 


가시성(Visibility)

-> 해당 클래스(혹은 인터페이스)의 속성과 오퍼레이션을 들여다 볼 수 있는 범위를 말합니다. 


표기 : 자바기준 

"+"  public : 모든 클래스에서 접근가능

"#"  protected : Package member Class와 Sub Class만 접근가능

"-"  private : member Operation만 접근가능

none : Package member Class만 접근가능 



* 위 자료는 백석대학교 이승형 교수님의 "소프트웨어 공학" 자료를 참고하였습니다.