Scent of Life

1         개요

이 문서는 PowerDesigner의 기본 기능에 대한 간략한 소개와 작업 환경 설정, 툴 버튼 사용 등에 대한 간략한 안내와 함께 Object Oriented Model을 활용한 UML 작성법에 대한 샘플을 제시한다. 또한 UML 작성에 있어서 고민해볼 만한 몇 가지 이슈 사항을 정리한다.

현재 버전에서는 Activity Diagram 및 Use Case Diagram을 표현하기 위한 따라하기식의 샘플을 중심으로 작성되며 지속적으로 갱신한다.

2         PowerDesigner

2.1      주요 기능

2.1.1      Business Process Modeling

업무 담당자가 업무상의 요구사항을 기술할 수 있도록 하며, 업무 프로세스를 시뮬레이션 하거나 최적화하는데 활용될 수 있다.

2.1.2      Object-Oriented Model

정보기술 담당자, 개발자, 설계자, 디자이너가 어플리케이션을 분석하고 디자인할 수 있도록 한다. 또한 상용자 인터페이스, 업무 로직과 O/R 매핑(관계형 모델과의 연결)을 정의하고 어플리케이션 코드를 생성하는데 사용될 수 있다.

2.1.3      Conceptual Data Model 및 Physical Data Model

개념적, 논리적, 물리적 데이터 모델링을 수행하고, 데이터베이스 구조를 최적화하거나 데이터베이스를 생성하고 역공학 할 수 있는 기능을 제공 한다.

2.1.4      Data Liquidity Modeling

데이터 복제, 동기화, 데이터 이동, 가상의 데이터 소스, XML과 관계형 모델의 매핑 등을 지원한다.

2.1.5      XML Modeling

XML 스키마, DTD, DXR 등의 디자인을 지원한다.

2.1.6      Free Model

임의로 필요한 모델을 작성할 수 있다.

2.2      작업 환경(Window)

2.2.1      Workspace

작업공간(Workspace)은 현재 파워디자이너 세션의 이름이다. Workspace는 오브젝트 브라우저 트리뷰의 기본 노드이며 열고자 하는 새로운 모델은 Workspace에서 만들어지고 저장된다. 하나의 Workspace에는 연관있는 다수의 다양한 Model 들을 작성할 수 있다.

Workspace라는 루트 노드의 하위에 여러 개의 연관되어진 하위 폴더들을 가질 수 있으므로, Workspace를 하나의 폴더 개념으로 생각하면 된다. 여기서 연관되어진 하위 폴더는 파워디자이너의 모델 파일로 생각 할 수 있다.

2.3      환경 설정

2.3.1      옵션

일반 옵션의 경우 PowerDesigner 사용자들이 설정(특히 폰트 등)을 통일할 수 있도록 한다.

모델이 열려있는 경우 위와 같이 모델 옵션 창을 열어 관련 설정을 조정할 수 있다.

2.3.2      Toolbox

화면의 툴박스 영역의 컨텍스트 메뉴을 팝업하여 Layout을 선택하도록 한다. 그러면 아래와 같은 툴박스가 추가되며, 이것을 통해 모델의 각 요소들의 layout을 보다 쉽게 조정할 수 있다.

2.3.3      Plug-in

PowerDesigner는 eclipse, PowerBuilder 등에 쉽게 플러그인 할 수 있다.

3         작업 환경

3.1      Workspace 및 Model

Workspace 및 모델의 계층을 미리 생성한다. 하단의 workspace 구성은 임의로 작성된 예제이며 실제로는 개발 시스템을 포괄하는 정확한 카테고리 별로 구분하여 구성하도록 한다. 최초 구성된 워크스페이스 및 모델 등의 파일을 공유하여 작성하도록 해야 하며 추후 각 작업자의 결과물을 통합(XML import, export 사용)할 수 있도록 정책 수립이 필요하다.

3.1.1     Workspace 구성

l         서브 시스템 구성 (예)

Workspace에 필요한 시스템을 서브 폴더로 추가한다. 아래는 각 시스템이 추가된 후의 Workspace 모양이다.

l         모델 추가

서브 폴더(서브 시스템)에 Object-Oriented Model을 추가한다. 팝업된 컨텍스트 메뉴에서 Object-Oriented Model를 선택하면 신규 모델을 추가하기 위한 다이얼로그가 팝업된다. 모델명을 수정한 후 확인 버튼을 클릭한다.

이때, workspace의 선택한 폴더 하위에 위 다이얼로그의 First diagram으로 설정된 Use Case Diagram이 추가되었을 것이다. 적당한 이름으로 변경하도록 한다.

그리고 아래와 같이 모델의 컨텍스트 메뉴를 통해 Use Case Diagram 외에 모델에 필요한 diagram들을 미리 추가할 수 있다.

아래는 몇 가지 모델들을 추가하고 필요한 diagram을 추가한 이후의 workspace 모양이다.

l         모델 삭제

모델의 컨텍스트 메뉴를 팝업하여 Detach from Workspace를 선택하면 기존의 모델을 삭제할 수 있다. 단, 경고 없이 바로 삭제되므로 주의하도록 한다.

l         Workspace 저장 및 열기

PowerDesgner의 file 메뉴를 통해 작성한 Workspace를 저장하거나 열 수 있다. 상, 하 그림은 각각 저장, 열기에 해당하는 다이얼로그 창의 모습이다. Workspace의 경우 저장하면 “*.sws”, 모델의 경우 “*.oom”의 확장명을 갖는다. 또한 저장된 workspace 파일을 더블 클릭하게 되면 PowerDesgner가 기동된다.

아래는 위에서 작성한 workspace가 실제 파일 시스템에 저장된 모습이다.

3.2      기본 동작

여기서는 편집과 관련한 간단한 사항만을 언급하며 자세한 사항은 “Object-Oriented Model UserGuide” 참고하도록 한다. 이 파일은 PowerDesigner를 기본값으로 설치한 경우 다음 경로에 위치한다.

C:\Program Files\Sybase\PowerDesigner 12\Documentation\Printable Docs\OOM_UserGuide.pdf

3.2.1      Diagram 열기

workspace에서 해당 Diagram을 더블 클릭하거나 컨텍스트 메뉴를 사용하여 로드할 수 있다.

3.2.2      Palette 공통 기능

각 diagram이 로드되면 해당 diagram의 맞춤형 palette가 함께 열리게 되는데, Diagram 편집작업은 주로 이 palette의 툴들을 사용하게 된다. 아래 그림의 좌측은 use case diagram의 palette이며 우측은 전체 palette에서 공통적으로 사용되는 툴들을 편집하여 붙여놓은 것이다.

3.2.3      편집

l         개체 추가

palette에서 개체 선택 후 Diagram에 마우스 좌클릭으로 추가한다. 클릭하는 만큼 개체가 반복해서 추가되며, 취소할 경우 마우스 우클릭한다.

l         개체 삭제

개체 선택 후 DEL 키를 누르면 확인 창이 팝업되는데 개체를 삭제할지 심볼만 삭제할지 결정할 수 있다.

l         개체의 선택 및 속성

개체는 마우스 좌클릭 하면 선택되며 복수의 개체를 선택할 때는 SHIFT, CTRL 키를 사용하거나 마우스를 드래그하면 된다. 개체의 속성을 보기 위해서는 개체 우클릭 시 팝업되는 컨텍스트 메뉴의 Properties를 선택하거나 선택 개체에서 ALT + ENTER 하면된다. 간단히 더블 클릭해도 속성 창이 팝업 된다.

l         개체의 order 변경

컨텍스트 메뉴의 “Order”를 선택하면 다음과 같이 개체의 순서를 변경할 수 있는 메뉴가 나타난다.

l         Item 정렬 및 교차선 처리

n         Layout Toolbar

u       fit to page

데이터 아이템의 개수가 많더라도, 한페이지에 출력 될 수 있도록 자동으로 줄여준다.

u       Auto-layout

다량의 Item 들이 존재하는 경우, 이것들을 자동으로 보기 좋도록 정렬해 주는 기능이다.

u       기타

Shift 키를 누른상태에서 Item 들을 여러 개 선택할 수 있으며, 아이템들 정렬을 하기 위해서는 처음에 선택한 Item 이 기준이 된다.

n         View Toolbar

u       Global view

전체 Item 들을 한눈에 알아보기 쉽도록 나타낸다. (Page Scale 을 줄이는 것과 동일한 효과를 나타낸다)

u       View Selection

선택한 Item 만을 크게 보여준다.

u       Current page

현재 사용중인 page 를 가운데 기준으로 보여준다.

u       Used page

사용되어진 page 전체를 한눈에 보여준다.

u       Browser

브라우져 창을 로드시킨다.

u       Output

모델 변환을 할때나, 모델을 로드할떄의 정보들이 나타나는 Output 창을 로드시키다.

u       Result list

일반적으로 보통때 사용되지 않아서 선택을 하지않으며, Check Model 이나 Find시 자동으로 로드되어진다.

n         선의 교차를 피하기 위한 라인 꺽기

라인의 원하는 지점을 CTRL 키를 누른채로 마우스 좌클릭한다. 반복하면 toggle 된다.

4         Diagram 샘플(UML 작성)

기본적으로 Use Case Diagram을 통해 작성한 하나의 Use Case를 하나의 활동도(Activity Diagram)로 도식화한다. 활동도의 활동(Activity)은 Use Case 시나리오로 작성하는 사건 흐름(flow of event) 상의 단일 스텝이란 원칙을 갖는 것이 좋다.

따라서 Workspace의 하위 폴더(서브 시스템)에 존재하는 하나 이상의 모델 중 각 모델은 하나의 Use Case Diagram과 하나 이상의 Activity Diagram을 가질 수 있다.

4.1      Use Case Diagram

Use Case는 소프트웨어 시스템이 무엇을 만들어야 하는지, 어떠한 기능을 제공해야 하는지를 기술하는 표기법을 통칭해서 부르는 말이다. Use Case는 시스템을 사용하는 사용자와 구현하고자 하는 시스템 자체를 설명한다. Use Case에서는 시스템을 사용하는 사용자를 액터(actor)라 하고 시스템의 행동을 Use Case라고 한다. 그리고 구현하고자 하는 소프트웨어 시스템을 주제영역(subject)이라고 한다. 내가 만들 시스템에 대한 Use Case들은 주제영역 안에 존재하고 주제영역 밖의 액터와 연결된다. 주제영역은 시스템 경계를 구성한다.

4.1.1      Palette

Use Case Diagram의 맞춤형 palette이다.

4.1.2      주요 버튼

Use Case Diagram의 맞춤형 palette의 주요 버튼들은 아래와 같다.

각 개체에 나열된 이미지는 Palette 상의 아이콘과 개체의 표시 및 개체의 속성 창 순으로 되어 있다.

l          Actor

l          Use Case

l          Generalization

l          Association

l          Dependency

l          Rectangle

l          Note

4.1.3      샘플 작성

4.2      Activity Diagram

순서도의 일종으로 발생하는 활동을 강조하며 발생하는 활동들간의 전달되는 제어 흐름을 표현한다. 절차적 논리(procedural logic), business process, 작업 흐름을 기술하는데 사용되는 기법이다. Activity Diagram에서는 작업(activity)의 순서를 기술하며 작업간의 제어 흐름을 강조하여 기술해야 한다. 본질적으로는 시간에 흐름에 따라 발생하는 작업들을 강조하는 flow chart이나, 병렬적인 행위를 지원한다는 점에서 차이가 있다.

4.2.1      Palette

Activity Diagram의 맞춤형 palette이다.

4.2.2      주요 버튼

Use Case Diagram의 맞춤형 palette의 주요 버튼들은 아래와 같다.

각 개체에 나열된 이미지는 Palette 상의 아이콘과 개체의 표시 및 개체의 속성 창 순으로 되어 있다.

l          Activity

l          Transition

l          Decision

l          Synchronization

l          Start

l          End

l          Organization Unit Swimlane

4.2.3      샘플 작성

4.3      Class Diagram

4.3.1      Palette

4.3.2      주요 버튼

4.3.3      샘플 작성

4.4      Sequence Diagram

4.4.1      Palette

4.4.2      주요 버튼

4.4.3     샘플 작성

5         Use Case 작성 시 이슈

많이 작성해보진 않았지만, UML을 작성 경험에 근거하여 이슈가 될만한 몇 가지를 정리한다.

5.1      Use Case의 레벨

Use Case의 경우 초기에 레벨과 상세화 정도를 통일할 필요가 있다.

5.1.1      레벨의 설정

구현에 대한 상세한 내용이 담겨 있는 Use Case는 적절하지 않다. Use Case에 소스코드 레벨의 설명이 들어 있는 경우가 간혹 있는데 ‘왜’라는 물음을 통해 상위레벨의 Use Case로 만드는 것이 좋다.

상위에 제시한 Workspace 예를 기준으로 하여 전체 시스템(현재 프로젝트)의 하위에 있는 주문관리, 발주관리, 입하관리 등과 같은 서브 시스템 그룹의 경우를 “요약 레벨”이라 하고, 주문 관리 서브 시스템 하위의 주문데이터관리, 주문상태관리, 출고처리상태관리 등의 주요 기능 그룹을 “사용자 목적 레벨”, 주문데이터관리 하위의 또 다른 세부 기능들을 “하위 기능 레벨”이라고 할 때 “사용자 목적 레벨”이 작성하고자 하는 Use Case의 최적 레벨이라고 여겨진다.

그래서 예제에서도 최 하위 기능들은 생략되어 있다. 물론 전체 시스템을 요약하는 “요약 레벨”의 Use Case도 필요하다.

5.1.2      상세화의 설정

Use Case 작성자에 따라 상세화 정도가 달라져서는 안된다. 동일 레벨의 Use Case는 비슷한 정도의 범위와 비슷한 상세화로 기술될 필요가 있다. 어느 정도로 상세화할지 기준을 정립할 필요가 있다.

5.2      포함(include)과 확장(extend)의 구분

아래 그림 예에서와 같이 주문 결제 Use Case는 액터가 결정한 결제 형태에 따라 현금 결제, 카드 결제, 포인트 결제 Use Case 중에 하나를 포함하게 된다. 포함 관계는 Use Case 간의 관계를 설정할 때 가장 쉽게 사용할 수 있는 관계 설정 방법이다.

또한 특정 작업을 수행하던 중 사용자가 도움말 버튼을 눌러서 도움말 내용을 확인하는 것 같은 작업이 전형적인 확장 관계이다.

화살표의 방향에 주의한다.

5.2.1     포함(include)

하나의 Use Case가 Use Case 내의 작업 흐름의 과정 안에 다른 Use Case의 작업 흐름을 포함하게 하는 관계이다.

Use Case는 액터와 시스템간의 상호 작용이나 시스템 내부의 작업 등을 기술한다. 이때 여러 Use Case에서 비슷한 작업이 공통으로 발생하는 경우가 있을 수 있다. 이때 이렇게 공통으로 발생하는 Use Case의 특정 부분을 하나의 Use Case로 따로 분리하고 포함 관계를 통해 정의하는 것이 가능하다. 이는 프로그램에서 서브 루틴을 호출하는 개념과 유사하다.

포함 관계에서 Use Case는 ‘포함하는(including) Use Case’와 ‘포함되는(included) Use Case’로 나눌 수 있다. Use Case는 액터가 그 작업 흐름을 기동시키는데, 포함 관계에서 ‘포함되는 Use Case’는 액터가 아닌 ‘포함하는 Use Case’가 작업 흐름을 기동시킨다. 그래서 ‘포함되는 Use Case’는 ‘포함하는 Use Case’가 없으면 제 구실을 하지 못하고 ‘포함하는 Use Case’에 합쳐져야 제 기능을 하게 된다.

l         기본 Use Case가 다른 Use Case 행동을 명시적으로 수용하는 것을 의미

l         포함된 Use Case는 기본 Use Case 일부로만 Instance를 작성할 수 있음

l         포함 관계는 위임을 뜻하며 System이 수행해야 할 책임들을 정한 후 해당 Use Case에서만 획득 가능하며 다른 Use Case에서도 기능이 필요하면 해당 책임 집합을 포함시킴

5.2.2      확장(extend)

하나의 Use Case의 흐름이 다른 Use Case 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계이다. 확장 관계는 확장하는 조건과 어떤 확장 지점으로 확장될 것인가에 대한 정보를 보유한다.

확장 관계에서 Use Case는 ‘확장되는 Use Case’와 ‘확장하는 Use Case’로 나눌 수 있다. ‘확장되는 Use Case’가 액터와 상호작용하면서 작업 흐름을 수행하던 중 확장하는 조건이 만족하게 되면 그 만족되는 시점에서 ‘확장하는 Use Case’가 ‘확장되는 Use Case’에 합쳐져서 작업 흐름을 수행한다.

확장 관계에서는 ‘확장하는 Use Case’가 ‘확장되는 Use Case’의 특정 지점으로 합쳐지게 되는데, 이 지점을 확장 지점(Extension point)이라고 한다. 확장 지점은 ‘확장되는 Use Case’에 위치하게 되고 ‘확장되는 Use Case’는 여러 개의 확장 지점을 가질 수 있다. ‘확장하는 Use Case’가 ‘확장되는 Use Case’의 어떤 확장 지점으로 확장될 것인가는 확장 관계에 표시한다. 확장 관계는 확장하는 조건과 어떤 확장 지점으로 확장될 것인가에 대한 정보를 보유한다.

l         기본 Use Case에서 간접적으로 명시한 곳에서 다른 Use Case 행동을 암시적으로 편입

l         기본 Use Case가 확장될 수 있는 지점을 Extension Point라 하며 미리 정해지므로 예측 가능

l         사용자가 선택적으로 보는 System 행동

5.2.3      포함(include) 과 확장(extend)의 차이

l         포함 관계는 ‘포함하는 유스케이스’가 주 흐름 유스케이스이고 ‘포함되는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것인 데 반해 확장 관계에서는 ‘확장되는 유스케이스’가 주 흐름 유스케이스이고 ‘확장하는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것이 된다.

l         포함 관계에서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 정상적으로 동작하기 위해서 반드시 필요한 필수 요소인 데 반해 확장 관계에서 ‘확장하는 유스케이스’는 선택 사항으로써 ‘확장되는 유스케이스’는 ‘확장하는 유스케이스’와 상관없이 독립된 기능을 수행할 수 있다.

5.3      기타

5.3.1      Use Case는 명사형

“~해야 한다”식은 지양.

5.3.2      UI는 배제

5.3.3      Actor와 연관 관계가 없는 Use Case

6         참고 사항