UML-Diagram(다이어그램)

UML-Diagram(다이어그램)

UML에서 다이어그램은 이제 사물과, 관계를 나타내는 기호를 활용해서 프로그램을 도식화 한 것을 말한다. 어따한 것을 요구하느냐, 무엇을 강조하느냐에 따라서 많은 종류의 다이어그램이 존재한다. 위의 그림 이외에도 더 찾아보니 더 많은 다이어그램들이 존재했고, 정적 다이어그램, 동적 다이어그램인지 또는 기능 다이어그램인지 분류한 경우도 있었다. 

이번 글을 쓰면서 공부할 겸 이전에 '급식관리프로그램'을 만들었던 것을 이용해서 몇가지 다이어그램을 그려보려고 한다. 찾아보면서 공부한 토대로 만들어본 다이어그램이기 때문에 정식 다이어그램과 조금 다를 수 있고, 잘못된 점도 있을 것이라 생각한다. 

[급식관리 프로그램] 급식관리프로그램은 학교 안에 있는 급식실의 식권을 예매를 통해 미리 구매할 수 있고, 학교에 있는 모든 식당의 메뉴를 알 수 있는 프로그램이다. 그리고 관리자 입장에서는 메뉴를 기재하고, 간단한 통계분석을 통해 매출 현황과 식권 구매수를 보면서 오늘 급식을 먹을 학생 수를 파악해볼 수 있다는 점에서 사용자과 관려자페이지가 따로 존재하는 급식관리 프로그램을 만 들어 보았다.  <사용자 대상>  급식 관리자와 급식 이용자 <요구 사항> 1. 간단한 회원가입과 로그인과 로그아웃이 필요하다. 2. 로그인 시에 관리자 권한일 때 통계 페이지와 식단 추가 페이지가 추가된다. 3. 마이페이지에서 사용자 정보를 알 수 있고, 현재 구매한 식권 수를 알 수 있어야한다. 4. 구매한 식권을 다시 돈으로 환전 또는 식권을 구매할 수 있는 기능이 있다. 5. 이번 달 식단을 확인 할 수있고, 세부사항으로 그 날의 식단과 사진을 볼 수 있다.  6. 밥을 먹은 사람 한에서 오늘의 식단에 댓글을 남길 수 있다. 7. 관리자는 식단을 추가할 수 있다. 그리고 통계페이지를 통해서 식권 구매 수,인기메뉴 등 통계정보를 파악할 수 있다.

[Use Case Diagram]

Use Case Diagram은 사용자가 상호작용하는 시스템의 모습을 기술한 것이다. 시스템이 제공하고 있는 기능과 관련한 외부 요소를 사용자의 관점에서 표현하는 다이어그램이다. 시스템분석가가 사용자와 함께 시스템의 사용방법을 결정하는 데 도움을 주는 도구 이용된다.

1. 특징

1) 사용자의 기능적 요구사항을 정의하는 직관적인 표현이다.

2) Use Case와 Actor간의 관계를 표현한다.

3) 주로 분석 단계에서 수행하기 때문에 시스템 개발 전의 단계에 영향을 준다.

4) 사용자와의 대화 수단이나 내부 기능을 예측하는 데 활용된다.

2. 구성요소

1) Actor : 사용자가 수행하는 역할을 말하며 시스템과 상호작용하는 사람 또는 사물이다. 예로는 사람, 외부시스템, 하드웨어장치, 이벤트 등이 있다.

2) Use Case : 시스템이 제공하는 서비스로 Actor가 시스템을 통하는 행위를 말한다.

3) System : 전체시스템의 영역을 표현한다.

3. 관계

1)Association(연관) : Use Case 와 Actor의 관계를 표현한다.

2)Extend(확장) : 기본 Use Case 수행 시에 특별한 조건을 만족할 때 수행하는 Use Case를 표현한다.

3)Include(포함) : 시스템의 기능이 별도의 기능을 포함한 것을 표현한다.

4)Generalization(일반화) : 하위 개념이 상위 개념에게 기능과 역할을 상속받은 것을 표현한다.

5)Grouping(그룹화) : 여러 개의 Use Case를 하나로 단순화 해서 표현한다.

4. Use Case 다이어그램

프로그램을 사용하는 사람은 학생, 교직원, 관리자가 있다. 세 유형을 일반화하면 프로그램 사용자가 된다.

일반 사용자(학생, 교직원)가 사용할 수 있는 것과 관리자가 사용할 수 있는 서비스가 다르기 때문에 관리자가 볼 수 있는 것을 확장을 통해 표현했고, 식권 구매자만 댓글을 작성할 수 있도록 요구사항에 맞게 다이어그램을 그렸다. 로그인기능을 포함하는 회원가입, 회원수정, 로그아웃을 하나의 그룹으로 엮어 표현하였다.

[Activity Diagram]

개발하려는 프로그램의 시스템에 대한 작업 흐름을 표현하기 위한 모델링 도구이다. 개략활동도와 상세 활동도로 구성되어 있으며 활동들 간의 순차적 흐름뿐만 아니라 병행 흐름도 표현한다. 즉, 객체의 상태가 아닌 처리 로직이나 조건에 따른 처리 하름을 순서에 따라 정의한 다이어그램이다. 흔히 보는 알고리즘 순서표를 그리는 것을 생각하면 된다.

1. 특징

1)처리 흐름을 도식화해서 프로그램 로직 정의가 가능하다.

2) 비즈니스 프로세스의 정의가 된다. 업부의 As-is분석, To-be분석이 가능하다.

3) Use Case을 실현한 것이다.

2. 구성요소

1)Activity state(활동) : 행위나 작업 등 어떠한 일을 하고 있는 상태를 말한다.

2)Initial state(시작상태) : 처리의 흐름이 시작됨을 알려준다.

3)Final State(종료상태)  : 처리의 흐름이 종료됨을 알려준다.

4)Decision(선택점) : 논리의 결과에 따라 분기가 일어난 곳을 표현한다.

5)Transition(전이) : 하나의 상태에서 다른 상태로 제어 흐름과 상태들 사이의 흐름을 보여준다.

6)Swim lane(구획면) : 업무조직이나 개인의 역할에 따른 처리구분한다.

3. Activity Diagram

Activity Diagram의 예시로 사용자가 로그인을 하고 식권을 구매하는 처리흐름도를 그린 것이 아래 그림이다. 구획면을 사용자와 시스템을 나눠서 그려보았다. 

이 전에 Case Use 다이어그램에서 실현화 시킨 것이 Activity Diagram이 된다. 직접 그려보면 알고리즘 순서도와 아주 유사하다는 것을 알 수 있다.

[Class Diagram]

클래스 다이어그램은 시스템에서 사용되는 개체 타입을 정의하고 , 그들 간에 존재하는 정적인 관계를 다양한 방식으로 표현한 다이어그램이다. 시스템을 논리적인 구조를 표현해서 객체지향 개발에서 가장 공통적으로 많이 사용되는 다이어그램이다. 시스템의 프로세스도라고도 불린다.

클래스를 너무 자세하게 표현하고, 기능을 많이 포함하면 복잡해지므로 적절하게 구현할 필요성이 있다. 모델이 점점 증가할 때 관련 클래스는 패키지로 묶어줘야한다.

1. 특징

1) 클래스와 인터페이스, 공동작업 간의 관계를 나타내고, 객체지향 시스템을 모형화 해서 가장공통적으로 많이 쓰이는 다이어그램이다.

2) 시스템 내에서 클래스들의 정적인 구조를 표현한 것이다.

3) 작성 후에는 바로 코드로 변환할 수 있다. 

2. 구성요소

이전 게시물에 구성요소와 관계에 대해 정리했으므로 이 부분에 대해서는 생략한다.

3. Class Diagram

1)대략으로 전체 프로그램을 나타낸 Class Diagram

클래스의 많은 부분을 생략했지만 그렇지 않으면 굉장히 복잡해지고, 그리기 어려우므로 대략적으로 전체 프로그램에 대해 클래스다이어그램을 만들어봤다. 아직 다이어그램을 그리는 것에 미숙하기 때문에 잘못 표현한 것도 있을 것이다. 시간이 조금 걸렸지만, 그래도 직접 그려보면서 느낀점은 프로그램의 이해도가 훨씬 깔끔하게 잘보이는 것같다. 디자인패턴 공부를 하면서 앞으로 계속해서 클래스다이어그램을 그리는 스킬을 터득해야겠다.