프로젝트 관리… 라고 제목은 거창하지만, 그냥 하나하나 만드는 과정을 서술 할거에요. 툴 자체에서 제공하는 부분에 대한 설명을 할 때까지의 제가 현재 진행하고 있는 작업물을 예시로 할 거에요. 디테일한 제 작업물의 설계서는 추후에 따로 포스팅 할 예정이고, 여기서 만들 때는 설명을 위한 최소한의 것들만 작성 할 거에요.
물론, 여기에 있는 내용 중 사용 하지 않는 부분이라면 가상의 예시를 만들어서 작성 하려고 해요 :D
앞선 포스팅(StarUML 툴 구조)에서 프로젝트 만드는 방법에 대해서는 언급 했어요. 처음에 생성은 빈 프로젝트(Empty Project)를 선택 한 거로 부터 시작 할게요 :)
유즈케이스에 있는 요소에 대해서 정리하면서, 제 설계서의 시작이 만들어 졌네요^^ 물론 아직 한참 멀었지만 시작이 반이 잖아요~ :)
본디 한 포스팅에 다 설명하기 무리였던 것의 목차를 그리 짜놓아서(저의 무지 덕분에), 부득이 하게 포스팅을 나눠서 작성하게 되네요ㅠㅠ
참조 : StarUML 5.0 사용자 가이드
물론, 여기에 있는 내용 중 사용 하지 않는 부분이라면 가상의 예시를 만들어서 작성 하려고 해요 :D
앞선 포스팅(StarUML 툴 구조)에서 프로젝트 만드는 방법에 대해서는 언급 했어요. 처음에 생성은 빈 프로젝트(Empty Project)를 선택 한 거로 부터 시작 할게요 :)
-
프로젝트 이름 설정StarUML에서의 프로젝트는 전체 집합이에요. 비쥬얼스튜디오 에서 솔루션의 개념이죠.
프로젝트는 StarUML에서 다루는 가장 기본이 되는 단위를 의미 해요. 프로젝트는 하나 혹은 그 이상의 소프트 웨어 모델들을 관리하는 최상위 패키지(Top-level Package)로도 이해 할 수 있어요.
처음에 만들게 된 상태에서는 제목없음(Untitled)라는 이름으로 프로젝트의 이름이 설정되어 있는데, 이름을 바꿔 볼까요? 예제는 제가 현재 진행하고 있는 작업에 대해서 진행 할게요.
- Untitled를 클릭 합니다.
- Properties 창이 선택된 요소(현재는 프로젝트)에 대한 속성이 나오게 되는데, 여기서 Title 부분을 선택해서 이름을 바꿉니다.
- 그 외에 대한 정보를 넣으시려면 마찮가지로 클릭 후 이름을 변경 하면 됩니다.(하단에 작성자Author, 회사Company, 권리Copyright)
대략 작성 후 화면 이에요. 제목에 따라서 탐색기에서 프로젝트의 이름이 바뀐 것을 확인 할 수 있어요.
-
프로젝트 구성이제 프로젝트에 요소를 넣어야 겠죠?
- 프로젝트에 마우스 우클릭을 합니다.
-
나오게 되는 메뉴가 있는데, Add 에서 마우스를 올려 놓으면 위와 같은 3개의 메뉴가 나옵니다.
넣을 수 있는 구성 요소는 세 개에요. 각각은 아래와 같은 성격을 가지고 있어요.- 모델(Model) : 물리적인 시스템을 특정 목적(관점)에 의해 기술하기 위한 그룹화 요소. 예를 들어 시스템의 특정 관점(분석관점, 설계 관점, 사용자관점 등)에 따라 시스템을 표현할 수 있습니다.
- 서브시스템(Subsystem) : 물리적인 시스템의 부분 혹은 전체를 명세화 하기 위해 요소들을 그룹화 하는 요소.
-
패키지(Package) : 모델 요소들을 논리적으로 그룹화 하기 위한 요소. 요소들을 조직화 하기 위한 어떠한 용도로 사용 되어도 무방한 매우 일반적인 요소.
일단 관점은 설계에 의한 관점으로 잡았어요. 현재 작업하고 있는 프로젝트는 엔진코어에 관련된 부분과 그에 대해 잠시 확인 하는 UI로 구성이 되어 있으므로, 두 개의 Model을 만들 었어요.
-
다이어그램(Diagram)의 종류 별 사용
-
유즈케이스 다이어그램(Usecase Diagram)사용되는 요소 보기
거의 처음에 작성 해야 하는 다이어그램인데, 실제 사용자나 시스템이 행할 수 있는 행동이나 동작을 명세 하는 부분 에요. 이를 행하는 것(사용자 또는 시스템)을 액터(Actor)라고 하고, 행동을 유즈케이스(UseCase)라고 해요.
EngineCore_TestUI가 실질적으로 테스트하는 툴이니까 거기서 만들어 볼까요?
- EngineCore_TestUI(임의의 자신이 만든 특정 요소)에서 마우스 우클릭 한다.
- Add Diagram에 마우스를 올려 놓는다.
- Use Case Diagram을 마우스 좌클릭 한다.
이렇게 생성이 되었어요. 한글 지원을 하니까(툴자체는 영문이지만..ㅠㅠ) 원하는 이름으로 입력 하면 되요.
액터를 만들어 볼까요? 현재 이 작업물은 저 혼자만 사용하니까, 저를 액터로 만들 었어요 :D
- 좌측의 Toolbox에서 Actor를 클릭 한다.
- 원하는 사이즈 만큼 드래그 한다.
사이즈가 구지 필요가 없을 때는 그냥 클릭만 해서 만들어도 되요. 나중에 다이어그램이 Toolbar에 있는 버튼중에 자동으로 정렬 시키는 기능이 있기 때문에, 정말 중요해서 크게 그려야 한다 아니면, 클릭 한번!
액터를 생성하면 처음에 이름을 입력 할 수 있는 텍스트박스가 떠요. 이름을 지정하고 엔터(혹은 아무대나 클릭)
유즈케이스도 마찮가지 방법으로 넣으면 되요. 현재 제 작업물은 카메라 움직이는 거만 하기 때문에, 그거만 넣었어요.
제가 카메라만 움직이면 되는 아주 간단한 행동이니까 일반 관계만 맺어 주면 될 거에요.
- Toolbox의 Association을 클릭한다.
- 액터를 클릭 한 후, 유즈케이스로 드래그 한다.
그럼 액터와 유즈케이스 간에 관계가 형성 되요.
이런 관계는 단순히 다이어그램을 통해 보는 것 말고도, 요소의 컬렉션 에디터(Collection Editor)를 통해서도 가능 해요.
방법1. 위 쪽 Toolbar에 빨강색 상자 로 체크한 아이콘을 클릭한다.
방법2.- 요소에서 마우스 우클릭 한다.
- 나오는 메뉴 중 Colletion Editor를 마우스 좌클릭 한다.
방법3. 단축키 Ctrl+F5를 누른다.
현재는 액터를 기준으로 보는 관계도 인데, "카메라를 움직인다" 라는 유즈케이스를 중심으로 본다면, Other-side Element and Role은 "저님" 이라는 액터가 나오겠죠? :)
카메라를 움직이는 거 뿐만 아니라, 오브젝트도 움직일 거니까, 그 부분도 넣어 볼까요? 관계도 맺어 서요~
이건 나중에 다이어그램이 지저분 해지면 간간히 정리 하는 기능인데 좋아요. Toolbar 가운데즈음에 ∴모양으로 사각형 있는게 있어요. 그걸 클릭하면, 자동으로 다이어그램을 정리해 줘요. 물론, 시스템 내부적으로 정해 진 루틴을 따르기 때문에 자신의 배치와는 다를 수는 있지만 저는 괜찮더라구요 :)
그리고, 카메라의 값을 확인 할 수가 있어요. 그 유즈케이스도 넣어 둘게요.
일단은 이거 말고는 없어요 :) 이제 자세히 들여다 보면, 모든 것들은 하나의 시스템의 요소이기 때문에, 경계를 잡을 거에요. 개념적인 요소로 다른 사람에게 설명 하는 문서를 작성 하는 것이기에 만드는 거에요. 추후에 다른 시스템과 연동이 되는 부분이 생기게 되면 시스템 간의 경계도 필요하니까요.
- Toolbox에서 System Boundary를 클릭 한다.
- 원하는 영역을 드래그 한다.
뭔가 그럴싸한 문서가 만들어 지고 있어요 :D
보게 되면, 이 모든 것들은 입력을 통해서 이루어 지는 거에요. 그건 시스템 내부적으로 구성이 되어 있겠죠? 그래서 넣어줍니다~ 그 유즈케이스를~
액터가 짤렸군요 ㅎㅎ 이제 슬슬 커져가고 있어요…ㅋ
시스템 바운더리를 보게 되면, "키 입력 처리"가 주체가 되어 다른 행동(유즈케이스)을 하게 되는 거니까 그게 다른 유즈케이스들을 포함 하게 되는 거에요.
거꾸로 얘기 하자면, "카메라를 움직이려면, 키 입력 처리를 해야 한다." 가 되는 거죠.
키 입력 처리를 하는 것도 행동이므로 유즈케이스가 되구요:D
- Toolbox의 Include를 클릭 한다.
- 포함 시키는 쪽으로 부터, 포함 되는 쪽으로 마우스를 드래그 한다.
그럼, 점선의 화살표에 <<include>>라는 스테레오 타입이 생기게 되요.
스테레오 타입이라는 건 저도 아직 잘 이해 하지 못했어요ㅠ 그저 의미 확인용?
아래는 가이드에 있는 설명이에요.
스테레오타입은 특정 UML 요소에 붙여짐으로써 의미를 더 명확하게 하고 더불어 부차적으로 확장속성을 부여하여 더 정확한 모델링이 가능하도록 합니다.
오브젝트를 움직이거나, 카메라의 값을 확인하는 것 역시 키 입력으로 통해서 이루어 지므로 동일 작업 반복~
어? 그런데, "키 입력 처리" 를 하려면, "키를 입력" 해야 하잖아요? 유즈케이스로 들어가겠죠?ㅎ
여기서 일방 관계(Directed Association)가 들어가게 되요. 키 입력을 해야, 키 입력 처리를 할 수 있는 거니까요. 만드는 방법은 동일 하니까 설명은 하지 않을 게요.
만들고 나니까 선이 좀 지저분 하죠? 이때는 선 스타일을 따로 정해 줄 수가 있어요. MicroSoft 사의 Visio처럼 이쁘게 되진 않아도(개인적으로 눈에 보이는 건 제일 이쁘게 만든다고 생각해요:D), 적당히 봐줄만큼 만들 수 있어요.
- 해당 라인을 선택한다.
- Toolbar에서 Line Style 버튼을 클릭한다.
- RectLinear를 클릭한다.
짜잔~ 완전 까지는 아니지만, 적당히 보기 좋게 정리 되었어요 :)
(구지 만들고 싶은 생각은 없는 거지만, 유즈케이스 다이어그램의 설명을 위해서ㅋ)카메라가 움직일 때에는, 단순 이동이 있고, 회전이 있어요. 이 부분은 오브젝트도 마찮가지가 되는 내용 이겠죠ㅎ? 그럼 "카메라가 움직인다"는 "이동"과 "회전"으로부터 일반화(Generalization) 된 거죠.
원래는 "카메라를 이동 한다"지만 자리가 부족해서 이동만 적어 놨어요. 일반화를 좀 더 알기 쉽게 적용할 수 있는 거는 "is a"를 붙여 보면 되요 :D
"카메라를 이동하는 것" 은(is a) "카메라를 움직이는 거" 다.
"카메라를 회전하는 것" 은(is a) "카메라를 움직이는 거" 다.
그냥 다른 예를 들어 보자면,
사람은 동물이다.(Human is an animal.)
개는 동물이다.(Dog is an animal.)
(유즈케이스로 만든 건 예시로 들려고 만든거에요 :D)
이제, 키 입력에 대한 부분을 좀 더 발전 시켜 필요가 있을 거 같아요. 이런 경우에는 확장(Extend)관계의 유즈케이스가 필요해요.
기존에 있는 거는 그대로 둔 상태에서, 추가적인 행동을 하게 되는 거니까요.
"동시 키 입력을 한다" 라는 유즈케이스를 집어 넣을 거에요.
관계는 확장이 되겠죠? 확장의 경우에는 새로운 행동이 기존 행동으로 들어가는 모양을 하고 있어요.
좀 더 알기 쉬운 적용 방법은 "can be inserted into"를 붙여 보는 거에요:)
"동시 키 입력을 하는 거" 는 "키 입력을 하는 거" 에 들어 갈 수 있다.(can be inserted into)
저 역시 포함(include)과 헷갈리기는 하는데요, 위에서 언급 하지 않았지만 포함의 경우에는 "contains" 를 붙여보면 되요.
하지만, 그래도 헷갈리기는 매한가지 인데…. 저는 이렇게 이해 했어요.- 포함(Include) : 반드시 있어야 한다.
- 확장(Extend) : 있으면 좋겠다, 편하겠다, 등등.. :D
의존(Dependency)의 경우에는 유즈케이스에서 의미가 모호하다고 사용 되지 않네요. 엄청난 구글링을 해보았지만, 예시중에서 Dependency를 사용하는 경우는 찾지 못했구요(못 본 걸수도 있지만..;;). 대체적으로 의존이라는 집합안에 포함(Include)이나 확장(Extend)을 가지고 있다고 설명 하고 있어요.
일단, 이 부분에 대해서는 따로 언급하지 않을게요 :)
-
유즈케이스에 있는 요소에 대해서 정리하면서, 제 설계서의 시작이 만들어 졌네요^^ 물론 아직 한참 멀었지만 시작이 반이 잖아요~ :)
본디 한 포스팅에 다 설명하기 무리였던 것의 목차를 그리 짜놓아서(저의 무지 덕분에), 부득이 하게 포스팅을 나눠서 작성하게 되네요ㅠㅠ
참조 : StarUML 5.0 사용자 가이드
'Programming > Architecture' 카테고리의 다른 글
04 Statechart Diagram (2) | 2012.07.10 |
---|---|
03 Class Diagram 2 (6) | 2012.05.30 |
03 Class Diagram 1 (0) | 2012.05.26 |
02 Activity Diagram (0) | 2012.05.10 |
StarUML 툴 구조 (0) | 2012.04.27 |