UML의 모델링의 본질 다이어그램으로 쉽게 보이는 UML

참고문헌 UML의 모델링의 본질/성안당/Kimnobu Kodama 저/김성훈역

패키지 관련 있는 요소들을 묶는 수단이 필요하다. UML에서는 패키지를 사용하여 클래스들을 그룹화 할 수 있다.

패키지

패키지

패키지 다이어그램 패키지 다이어그램은 시스템의 서로 다른 패키지들 사이의 의존관계(dependency)를 보여준다.

패키지 다이어그램 패키지는 클래스와 같은 여러 모델 요소들을 그룹화 시킬 수 있는 수단이다. 패키지 내에 다른 패키지를 포함할 수 있다. 모든 구성요소는 단지 하나의 패키지에만 포함될 수 있다. 각 패키지는 하나의 네임 스페이스(name space)를 구성한다. 이 의미는 두개의 모델요소가 각기 다른 패키지에 속한다고 할 때 이들이 동일한 이름을 갖는 것을 허용한다는 것을 뜻한다. 패키지를 제거하면 패키지내의 모델요소도 함께 제거된다.

예제 Student Professor Department

의존관계(1) 패키지들 사이에는 의존관계(dependency relation)가 존재한다. 의존 관계는 점선 화살표로 나타낸다. 만약 패키지 A가 패키지 B와 의존관계에 있을 때에는 A에 포함된 클래스가 B에 포함된 클래스들을 이용한다는 의미이다. 즉, A의 어떤 클래스가 B의 클래스의 객체에 메시지를 보내거나 메소드의 인자로 사용할 때 또는 A의 클래스의 데이터 부분으로써 B의 클래스를 이용할 때 생긴다.

의존관계(2) 의존관계가 의미하는 것은 Client 패키지를 Server 패키지 없이 단독적으로 재사용할 수 없다. Server 패키지에 변화가 발생하면 Client 패키지에 영향을 미칠 수 있다.

이행 관계(transitive relation)? 패키지들간의 관계는 이행관계인가. 다음 그림에서 패키지 A는 B와 의존관계를 갖고 있고 패키지 B는 패키지 C와 의존관계를 갖고 있음을 알 수 있다. 그렇다면 패키지 A는 패키지 C와 의존관계가 성립하는가? 아니다. 이행관계는 성립하지 않는다. 패키지 A의 클래스는 패키지 C의 클래스를 이용하지 않는다. 이 점은 소프트웨어 아키텍쳐를 고려할 때 매우 중요한 의미를 갖는다.만약 이행 관계가 성립한다면 패키지 A는 패키지 C에 어떤 변화가 일어난다면 그에 따라 영향을 받을 것이다. 그러나 이행관계가 성립하지 않기 때문에 C의 변화에 직접적으로 영향을 받지 않게 설계할 수 있다.

순환적 의존관계(1) 다음의 패키지 관계는 바람직한가? 바람직하지 않다면 그 이유는 무엇인가. 해결 방법은? 바람직하지 않다. 그 이유는 어는 한 패키지에 변화가 발생하면 의존 관계를 갖고 있는 모든 패키지에도 영향을 미칠 수 있기 때문이다. 또한한 패키지를 의존 패키지 없이 재사용하는 것이 불가능하다. 만약 패키지 B를 재사용한다고 했을 때 어떤 일이 발생하는가 검토해보라!

순환적 의존관계(2) 순환적 의존관계를 없애는 방법은 새로운 패키지를 도입하는 것이다.

패키지 가시성 패키지 가시성은 패키지에 속한 클래스들이 다른 패키지에 의해 사용될 수 있는지를 나타낸다. Java 언어와 직접적으로 관련 있는 가시성으로 다음과 같은 것들이 있다. +public: 다른 패키지에 속한 클래스들에 의해서 사용될 수 있다. 이를 위해 사용하고자 하는 클래스를 가지고 있는 패키지를 반입(import)할 필요가 있다. -private: 동일한 패키지내의 클래스들에 의해서만 사용될 수 있다. Java에서는 이를 패키지 가시성(Package Visibility)를 갖는다라고 말한다.

패키지 가시성 myPackage에 두개의 클래스 ClassA와 ClassB가 있다. 만약, ClassA가 public 가시성을 가지고 있고 ClassB가 private 가시성을 가지고 있다고 할 때…... package myPackage; public class ClassA { ………………………. } package myPackage; class ClassB { ………………………. }

패키지 가시성 Public으로만 선언된 클래스들을 다른 패키지에서 접근할 수 있다.

패키지 가시성 다른 패키지에 있는 public 클래스를 사용하기 위해서는 import를 해야한다.

패키지 가시성(무엇이 잘못되었는가?) Cookie 클래스는 food.dessert 패키지에 속함 package food.dessert; public class Cookie { public Cookie() { …..} private void decorate { ….} } import food.dessert.*; package restaurant; public class Dinner { public void makeDinner { Cookie c = new Cookie(); c.decorate(); } food.dessert.의 패키지에 있는 public 클래스들을 사용

패키지 importing

상호 작용 다이어그램 기능 요구를 실현하기 위해 객체들에게 어떻게 작업을 분담시킬 것인지를 검토하고 기술하는 데 사용 시퀀스 다이어그램 협력 다이어그램

협력 다이어그램

시퀀스 다이어그램

메시지 메시지 예 의미 [a==b]msg(“hello”, 123) a==b 일 때 “hello”와 123 인자를 넣어msg()라고 하는 메시지를 보낸다. *[i=0..5]:result := msg(i) I가 0부터 5사이 msg()라고 하는 메시지를 i를 인자로 하여 보내고 그 결과 값을 result에 보관

객체 생성과 소멸

상호작용 다이어그램 사용처 오브젝트 추출 로직 확인 클래스 다이어그램의 확인 책무 밸런스의 확인

참고

참고 UML 2.0

참고 UML 2.0

참고 UML 2.0

참고 UML 2.0

액티비티 다이어그램 소프트웨어의 처리나 워크 플로우 등의 순서가 있는 액티비티를 표현 흐름도와 비슷

액티비티 다이어그램 구성요소 액티비티 개시/종료상태 개시 상태는 반드시 하나이어야 하나 종료 상태는 여러 개가 될 수 있음 액티비티 다이어그램 구성요소 액티비티 개시/종료상태 개시 상태는 반드시 하나이어야 하나 종료 상태는 여러 개가 될 수 있음 이동 분기/합병 이동에 대한 조건 분기를 표현 조건은 배탁적이어야 함 분기와 합병은 생략 가능 포크/조인 여러처리를 동시에 실행하는 것을 표현 오브젝트 플로우 오브젝트의 흐름을 표현 구획면(Swinlanes) 액티비티 실행 책임/조직명/역할명 등

Basics: Action

Initial State

Initial State(2)

예

예

Decision point

Merge points

Alternative Approach

Sync States

예

Object flow/Object in state

Swimlanes

액티비티 다이어그램 사용처 업무 흐름의 모델화 유즈케이스 보완 로직의 모델화

액티비티 다이어그램 주의 사항 액티비티의 이름을 붙일 때 액티비티의 의도/목적을 액티비티의 명으로 할 것 회원카드읽기 회원식별 액티비티 다이어그램 주의 사항 액티비티의 이름을 붙일 때 액티비티의 의도/목적을 액티비티의 명으로 할 것 회원카드읽기 회원식별 대출대상 식별 비디오 바코드 읽기 대출기간 설정 몇박인지입력

액티비티 다이어그램 주의 사항 구획면의 명명 뒤에서 부터 그린다 비즈니스 모델링: 조직명/회사명 아키텍쳐: 게층명 액티비티 다이어그램 주의 사항 구획면의 명명 비즈니스 모델링: 조직명/회사명 아키텍쳐: 게층명 메소드레벨: 객체명 뒤에서 부터 그린다

스테이트 챠트 다이어그램 한 객체나, 유즈케이스 또는 전체 시스템의 라이프타임을 모델링

상태 대상물을 이해하기 위한 중요한 어떤 ‘상황’ 휴대전화 상태: ‘대기중’, ‘착신중’, ‘통화중’ 상태에 있는 동안 어떤 조건을 만족한다. 어떤 행위를 수행하거나 어떤 사건이 발생하기를 기다린다. 이름, entry, exit 행위, do 행위 등

전이 상태 간의 이동. 지정된 사건이 발생하고 기술된 조건이 만족되었을 때 어떤 행위를 수행하고 다른 상태로 이동.

전이

전이 내부 전이: 상태 이동 없음. 자기 전이와는 entry, exit 행위를 수행하지 않는 다는 점에서 다름 지연 전이:사건의 발생을 인지하나 다른 상태에 도달하기 까지 반응을 지연

액션을 사용하는 장소

복합 상태 다른 상태들을 포함하는 상태 복잡도를 줄일 수있음 순차적 또는 병행적 상태를 포함할 수 있음

히스토리 상태 전이가 복합 상태에 들어올 때 일반적으로 초기 상태에서 시작 때로 복합 상태를 떠나기 전의 마지막 (부) 상태를 기억 할 필요가 있음

병렬 상태 병렬로 수행하는 (부) 상태 만약 하나가 마지막 상태에 도달하면 다른 쪽이 종료되기를 대기

스테이트 챠트 사용처(1) 시스템 전체의 움직임을 파악

스테이트 챠트 사용처(2) 오브젝트의 라이프 사이클을 파악 이벤트의 취사 선택을 파악

MDA Model Driven Architecture UML로 그려진 모델을 이용하여 실행 가능한 시스템을 자동으로 생성

예제

컴포넌트 다이어그램 배치 다이어그램과 함께 물리적인 면을 모델링 컴포넌트의 두가지 해석 UML 관점:시스템을 구성하는 임의의 물리적인 요소 CBD(Component Based Development):인터페이스에 의해서 기능이 정의된 독립적으로 개발, 배포, 조립이 가능한 시스템의 구성단위

컴포넌트와 클래스 클래스는 논리적인 것을 추상화/컴포넌트는 물리적인 것을 표현 컴포넌트는 노드(또는 프로세서)에 존재할 수 있지만 클래스는 그렇지 않다 클래스와 컴포넌트의 관계는 의존관계를 사용해서 명시 클래스는 속성과 오퍼레이션을 가질 수 있지만 컴포넌트는 일반적으로 인터페이스만을 통해서만 접근

컴포넌트 다이어그램

예제: UML 2.0

예제

사용처 파일 구성의 검토

사용처 인스톨 순서의 검토

배치 다이어그램 컴포넌트 다이어그램과 함께 시스템의 물리적인 요소를 모델링 네트워크, 하드웨어 또는 소프트웨어들을 실행 파일 수준 컴포넌트들과 함께 표현 노드와 노드 간의 관계 표현 노드: 프로세서나 디바이스 관계: 네트워크 특성이나 프로토콜 표현

예제

예제