UML 강좌 #.4 ver 0.1 Written by 심 원도 1998년 2월 1일 copyright Plasticsoftware. Co.
안녕하세요. 강좌가 상당히 늦어진 것 양해를 구합니다. 주변의 잡다한 일 때문에 집중해서 글을 쓸 시간이 없었습니다. 이번 강좌는 프로젝트의 진행시 초반부에 그려지게 될 Use Case Diagram에 대해 알아보도록 하겠습니다. Use Case Diagram은 프로젝트의 초반에 작성되어 프로그램의 전반을 결정하게 되는 중요한 다이어그램이라 할 수 있습니다.
I. Use Case란?
1. Use Case의 정의.
기존 프로젝트의 실패원인을 들자면 여러가지가 있을것이다. 하지만 그 중의 하나가 의사소통의 부재를 들수 있다. 프로젝트의 시작시 프로젝트의 결과물을 사용하는 사용자 혹은 프로젝트를 맡긴 의뢰인과의 대화결여로 인하여 프로젝트 자체의 형태가 바뀌게 된다. 이러한 일을 막기 위해 우리는 Use Case Diagram을 사용하여 프로젝트의 기능적인 면을 담을 수 있을 것이다.
Use Case란 것은 말 그대로 사용의 사례로서 시스템 사용의 사례들을 그려 놓은 것이다.
예를 들어 어떠한 건물을 만든다고 생각하자. 실제로 이러한 건물은 먼저 설계를 하여야 한다. 건물의 설계에서 이 건물이 주로 어디에 어떻게 사용될지를 생각하게 된다. 이렇게 건물의 주요 용도를 사용자와의 상호작용으로 표시한 것을 Use Case라 한다.
2. Use Case의 특징.
1) 의사 소통 수단이다.
의뢰인 혹은 사용자와 개발자는 시스템의 형태에 대해서 결정하여야 한다. 이러한 결정을 위해서는 시스템의 주요기능이 나타날 수 있는 Diagram이 필요한데 이 Diagram이 Use Case Diagram이다.
2) 구현 독립적이다.
Use Case의 경우 외부에서 시스템을 바라보아서 그 기능을 나타낸다. 외부에서 볼 때 하나의 Use Case에서 Use Case의 내부적 수행 과정은 블랙박스로 외부에 나타나지 않아야 한다. 이처럼 Use Case Diagram을 그릴 때 시스템의 내부적인 수행 과정은 포함시키지 말아야한다.
시스템의 정확한 기능을 추출하기 위해 의뢰인은 Use Case Diagram을 보고 그 시스템의 기능을 완전이 이해할 수 있어야 한다. 시스템의 기능을 알려주기 위해서 그 내부의 구현까지 의뢰인에게 알려야 할 필요성은 없다. 오히려 의뢰인의 이해를 더 감소시키는 영향을 미치기도 한다.
반드시 Use Case Diagram에서 시스템의 내부는 숨겨져야 한다.
3) 테스트의 기본이다.
의뢰인과 개발자간의 합의로 인해 시스템의 기능이 확정된다. 이러한 확정된 기능은 앞으로 분석과 구현의 기본이 된다. 개발도중 중간결과를 초기에 정한 Use Case Diagram과 비교하여 오류를 수정할 수 있다.
이와 같이 Use Case Diagram은 앞으로 개발되는 중간결과물에 대한 테스트의 기본이 될 수 있다.
3. Process에서의 Use Case Diagram.
어떠한 시스템의 개발이던지 시스템 개발의 시작은 항상 시스템에 대한 요구의 분석으로 시작할 것이다. 혼자서 자기의 프로그램의 개발하는 형태라든가 아니면 의뢰인의 수주를 받아서 프로그램을 개발하는 형태등.. 여러가지의 어떠한 개발의 형태에도 적용되어야 할 것이 시스템의 어떠한 기능과 어떠한 크기등등의 여러가지 제반사항을 시스템 개발의 초기에 마련하는 것이다. 이러한 시스템에 대한 요구분석을 기록할 수 있는 Diagram이 Use Case Diagram이다. 결국 Use Case Diagram은 개발프로세스의 초기에 사용되어진다.
II. 표기와 의미.
1. Actor Notation과 의미.
1)
표기법.
[그림 1]
Actor의 표기는 그림 1과 같이 ‘Stick man’으로 표시하거나 Stereotype을 Actor로 가지는 Class로 표기한다.
2) 의미.
a. Actor는 시스템과 상호작용하는 어떤 사람이나 어떤 것이다. 시스템과의 상호작용이란 시스템과 어떠한 정보의 교환을 한다는 의미이다.
b. Actor는 시스템의 개인 사용자가 아니라 하나의 역할을 나타낸다. 예를들어 홍길동이란 사람이 보험회사에 보험을 들려고 한다. 여기서 홍길동이란 개인이 Actor가 되는 것이 아니라 그의 역할 보험가입자가 Actor가 되는 것이다.
3) 예제.
[그림 2]
2. Use Case Notation과 의미.
1) 표기법.
[그림 3]
Use Case의 표기는 그림 3과 같이 Use Case의 이름을 포함한 타원으로 표시한다.
2) 의미.
a. Use Case는 시스템의 핵심적인 기능을 표현한 하나의 단위이다. 이러한 핵심적인 기능은 Actor와의 상호작용에 의해서 나타내어진다.
b. Use Case는 사용자나 혹은 의뢰인의 입장에서 본 기능적인 요구사항이다. 시스템의 핵심적인 기능은 사용자나 의뢰인의 입장에서 반드시 필요한 사항이어야 한다.
3) 예제.
[그림 4]
3. Actor사이의 Relationship과 의미.
1) 표기법.
[그림 5]
Generalization Realtionship의 표기는 위의 그림과 같이 닫혀진 화살표로 나타낸다.
2) 의미.
Generalization의 의미는 상속의 의미와 유사하다. 위의 그림에서 볼 수 있듯이 Custormer와 Commercial Customer는 Generalization의 관계를 가진다. Customer의 일반적 역할을 가진 Actor의 모든 행위를 Commercial Customer의 Actor가 가지는 것이다.
3) 예제.
[그림 5]
4. Use Case사이의 Relationship과 의미.
1) 표기법
[그림 6]
그림 6의 Relationship은 Association Relationship으로 실선으로 표시한다.
[그림 7]
그림 7의 Relationship은 Extend Relationship으로 열린 머리의 점선 화살표로 나타낸다. 화살표 위에는 ‘<<Extend>>’를 적어준다.
[그림 8]
그림 8의 Relationship은 Include Relationship으로 열린 머리의 점선 화살표로 나타낸다. 화살표 위에는 ‘<<Include>>’를 적어준다.
[그림 9]
그림 9의 Relationship은 Generalization Relationship으로 닫힌 머리의 속이 빈 실선 화살표로 나타낸다.
2) 의미
a. Extend Relationship : Extend Relationship은 사용할려는 Use Case가 사용되어지는 Use Case의 행위를 선택적으로 포함하는 것을 의미한다.
b. Include Relationship : Include Relationship은 사용할려는 Use Case가 사용되어지는 Use Case이 행위를 필수적으로 포함하는 것을 의미한다.
c. Generalization Relationship : Generalization Relationship은 클래스들 사이의 상속관계와 유사한 관계로 자식 Use Case의 행위는 모든 부모 Use Case 의 행위를 받아오는 것이다.
3)
예제
[그림 10]
그림 10에서 보는 바와 같이 사용자 인증 Use Case의 행위는 반드시 주문처리 Use Case이 행위에 포함되어야 한다. 이것이 include relationship의 관계이다. 그리고 주문처리의 행위는 급한 주문 처리 Use Case의 행위의 어떤 조건에 부합되었을 때 포함되어진다. 이것은 extend의 관계가 된다. 패스워드 검색 Use Case의 행위는 사용자 인증 Use Case의 행위를 상속받아서 사용한다. 이것이 Generalization의 관계이다.
5. Actor와 Use Case사이의 Relationship과 의미.
1)
표기법.
[그림 11]
그림 11의 Relationship은 Association Relationship으로 실선으로 표시한다.
2) 의미.
Association Relationship은 Actor와 Use Case사이의 관계로 Actor와 Use Case간의 정보교환을 의미한다.
3) 예제.
세일즈맨의 Actor와 주문을 받다의 Use Case는 상호작용을 통해 정보를 주고 받는다.
III. 이외의 특징들.
1. Actor 추출법.
우리는 시스템과의 상호작용을 하는 Actor를 몇가지 질문을 통해 그 대상을 Actor로 간주할 수 있다.
1) 시스템의 주기능을 사용하는 사람은 누구인가?
2) 누가 시스템으로부터 업무 지원을 받는가?
3) 누가 시스템을 운영, 유지 보수하는가?
4) 시스템과 정보를 교환하는 외부 시스템은 무엇인가?
5) 시스템이 내어놓은 결과물에 누가 관심을 가지는가?
2. Use Case 추출법.
Actor와 같이 Use Case또한 여러가지 질문을 통해 찾아낼 수 있다.
1) Actor가 요구하는 시스템의 주요 기능은 무엇인가?
2) Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?
3) 시스템이 Actor에게 주는 어떠한 Event가 있는가?, Actor가 시스템에 주는 어떠한 Event가 있는가?
4) 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?
5) 시스템의 구현에서 가장 문제가 되는 점은 무엇인가?
3. Event Flow.
Actor와 Use Case가 추출이 다 되었다면 우리는 시나리오를 작성하기 위한 전 단계로 Event flow를 만들어야 한다. Event Flow란 Use Case의 행위들의 흐름을 나타낸다. Event flow내에 Use Case의 행위의 시작과 끝이 어떻게 나타나는지 표시하게 된다. Evnet flow에는 Main flow of Event와 Alternate Flow of Event, Exceptional flow of event의 세가지가 존재한다.
1) Main Flow of Event
Use Case의 행위의 중심적 흐름을 나타낸다. 인터넷 쇼핑몰 시스템의 예를들어 설명하면 다음과 같다.
사용자가 쇼핑몰 시스템을 로그온하면서 이 Use Case는 시작되고 시스템은 사용자의 암호를 확인하고 사용자가 살 물품을 선택하게 할 수 있도록 Select, Deselect, Deselect All, Cancel 의 선택사항을 표시한다.
2) Alternate Flow of Event
Main Flow of Event중 선택적인 상황이 발생할 경우를 나타낸다. 위의 예에 이어서 설명하면 다음과 같다.
사용자가 Select를 선택했을 경우 : 물품의 가격과 제반사항을 표시한다.
사용자가 Deselect를 선택했을 경우 : 물품을 선택하게 할 수 있는 표시를 한다.
사용자가 Cancel를 선택했을 경우 : ……..
3) Exceptional Flow of Event
예외적인 상황이 발생할 경우를 나타낸다. 위의 예에 이어서 설명하면 다음과 같다.
사용자가 선택한 물품을 다시 선택하였을 경우 : 사용자에게 적당한 경고의 문구를 표시한다.
4. Senarios.
한 시스템에서 여러가지의 Use Case가 나오고 그에 따라 이벤트의 흐름이 나타난다. 이벤트의 흐름은 앞 절에서 보았듯이 Main Flow 와 Alternative Flow가 있다. 이렇듯이 이벤트의 흐름은 여러가지가 나올 수 있다. 이러한 이벤트의 흐름을 실례(Instance)화하여 텍스트로 나타낸 것을 시나리오라고 한다. 시나리오 또한 여러가지가 나올 수 있다.
5. 실제화(Realization).
실제 Use Case 다이어그램에서는 구현에 관한 사항은 생각치 말고 표현하지 말아야 한다. 하지만 내부 구현이 필요한 경우 이것의 구현은 Collaboration으로 표현한다. Collaboration은 Use Case를 클래스나 오브젝트들 사이의 관계와 상호작용으로 나타낸다. 하지만 Use Case Diagram에서의 Collaboration의 표기는 점선 타원으로 표시한다. 이러한 Collaboration은 Interaction Diagram과 Activity Diagram을 표현하기 위한 기본이 된다.
이것으로 Use Case Diagram에 관한 내용을 모두 마치고 다음 강좌로 인터렉션 다이어그램에 관하여 설명하도록 하겠습니다.
새로운 강좌가 나오는 시간이 상당히 길어지는 것에 대한 것 그리고 강좌 내용에 대한 일관성의 부족… 많이 부족하다고 저도 느낍니다. 하지만 앞으로 이 강좌의 내용을 UML의 새로운 spec에 맞춰 구성과 내용을 계속 개선해 나갈 생각입니다. 앞으로의 강좌도 계속 보시고 많은 조언을 부탁드립니다.
강좌에서 오타나 잘못된 내용이 있으면 wideeye@www.plasticsoftware.com으로 연락주세요
이글을 인용하시거나 다른 곳에 올리실 때 저한테 멜한통만 보내주세요. – 부탁입니다.
마지막으로 한가지 부탁드릴 말씀이 있습니다. 이 글을 보시거나 아니면 다른 내용을 보시고 한글로 UML을 정리한 자료가 있으면 저한테 좀 보내주셨으면 합니다. 아직 국내에 한글화 된 자료가 많이 없더군요. UML을 입문하는 많은 사람들이 한글 자료를 원하고 있습니다. 저한테 자료를 보내주시면 반드시 UML 을 배우고 싶은 사람들을 위해 배포하도록 하겠습니다.
