[0102-1] UML / 구조 모델 (클래스 / 객체 / 패키지 다이어그램)

UML 개요

구조 다이어그램 

클래스(Class)	클래스, 기능, 연관관계 기술
컴포넌트(Component)	컴포넌트 간 구조 및 연결관계를 기술
복합구조 (Composite structure)	런타임 시 클래스의 내부 구조를 기술
배치(Deployment)	물리적 산출물 배포
객체(Object)	객체(인스턴스)의 구성 예제
패키지(Package)	컴파일 시점의 계층적 구조

행위 다이어그램

액티비티(Activity)	순차 행동과 병렬 행동 기술
유스 케이스(Use case)	사용자가 어떻게 시스템과 상호작용 하는지 기술
상태머신(State machine)	이벤트에 따른 객체의 상태 변화를 기술
시퀀스(Sequence)	호출 순서를 중심으로 한 객체 간 상호작용 기술
커뮤니케이션(Communication)	객체 간 연결을 중심으로 한 상호작용 기술
교류 개요 (Interaction Overview)	시퀀스 다이어그램과 액티비티 다이어그램의 혼합
타이밍(Timing)	시간을 중심으로 한 객체간 상호작용 기술

객체 지향 시스템 분석

Divide and conquer : 시스템의 복잡도를 해결하기 위한 접근법

1. 기능적 분석

- 하나의 시스템은 다수의 모듈로 구성됨

- 각 모듈은 응용 도메인에서 주요 기능을 수행

- 모듈은 더 작은 모듈로 반복적으로 분할될 수 있음

2. 객체지향 분석

- 하나의 시스템은 다수의 클래스(객체)로 구성됨

- 각 클래스는 응용 도메인에서 주요 개체(entity)의 역할

- 클래스는 더 작은 클래스로 반복적으로 분해가능

UML과 개발 프로세스

- UML은 범용 모델링 언어로써 특정 SW 개발 프로세스를 정의/제한하지 않음

- UML은 RUP(Rational Unified Process)와 무관

- UML은 객체지향 개발 방법론에 뿌리를 두고 있으나 어느 개발 프로세스에도 적용 가능

SW개발 프로세스의 두가지 유형 (폭포수 모델, 반복적 모델)

구분	폭포수 방식(Waterfall Style)	반복적 방식(Iterative Style)
개념	순차적인 SW개발 프로세스(개발 흐름이 폭포수처럼 지속적으로 아래로 향함)	SW개발이 반복적/점진적으로 증가하는 방식의 개발 프로세스
프로젝트	activity 기준으로 구분분석 -> 설계-> 테스트 각 단계마다 기간 할당	기능의 부분 집합으로 정의하며 반복 총 3사이클을 가정하면, 각 주기별로 요구사항의 1/3을 분석/ 설계/구현/테스트를 거침
산출물	각 단계별 공식 산출물 존재	사이클을 거치면서 개발 산출물의 완성도 높아짐

폭포수 모델 

- 각 단계별 결과 확인 후 다음 단계로 진행

- 응용분야가 단순하거나 잘 알고 있는 경우에 적합

- 각 단계별 산출물 명확히 정의할 필요가 있음

반복적 모델

- 시스템을 여러번 나누어 릴리즈 하는 방식

- 중요하고 기초적인 기능을 우선 개발하여 사용, 점진적으로 기능을 추가로 개발

- 점증적 방식 : 일부 기능만 구현 후 기능을 추가해 나가는 형태

- 반복적 방법 : 전체 기능을 대상으로 하되 릴리즈마다 완성도를 높이는 방법

재작업은 반복적 개발에서 큰 문제임으로 해결방안이 필요

1. 자동 회귀 테스트 

 - SW 변경에 따른 결함 발생 여부를 확인하기 위한 시험

- 테스트 자동화 도구나 xUnit 프레임워크 사용

2. 리팩토링

- 기존의 SW를 변경하기 위한 체계적 가이드라인

3. 연속적 통합

- 팀원이 코드 베이스에 체크인 할 때마다 자동화된 빌드 프로세스가 실행될 수 있도록 함

- 자동 빌드가 하루에 여러번 수행되며, 자동 회귀 테스트가 연계될 수 있음

RUP (Rational Unified Process)

- 하나의 고정된 프로세스가 아니라, 적응이 가능한 프로세스 프레임워크 ( 프로젝트 팀이 필요한 프소레스의 요소들을 선택/ 적용)

- 4가지의 필수단계 

 1. 개념화 : 프로젝트에 대한 초기 평가 수행

 2. 상세화 : 주요 유스 케이스 도출, 반복적 SW개발 진행

 3. 개발 프로세스 반복, 완성도 있는 기능 구현

 4. 전이 : 반복 수행하지 않는 최종 단계 활동 수행( 데이터 센터 배치, 사용자 교육 등)

구조 모델 및 실습

1. 클래스 다이어그램 

- 클래스(시스템이 처리해야할 자료와 그 자료와 관련된 오퍼레이션을 정의한 작은 모듈)을 식별하여 기술

- 클래스의 특징기술 : 프로퍼티(멤버변수)와 오퍼레이션(멤버함수)를 포함

- 시스템의 객체의 타입과, 그들 간에 존재하는 다양한 정적인 관계를 기술

- 객체간 연결 관계의 제약사항 기술

클래스 이름	클래스의 이름
속성(데이터) (Attributes)	해당 클래스의 멤버 변수 속성/이름/초기값 등
행위/오퍼레이션 (Operation)	해당 클래스의 멤버 함수 속성/이름/파라메터 등
연관관계	관련된 여러 클래스 간 관계를 표현

1.1클래스의 프로퍼티

 - 클래스의 구조적 특징을 표현

 - 속성, 연관, 오퍼레이션,일반화 제약조건 등

1.2 속성

 - 클래스 내에 표시, 클래스의 데이터 타입 등 기술

 [형식] 가시성 이름 : 타입 다중성 = 기본 값

1.3 오퍼레이션 

 - 클래스가 수행하는 액션을 기술(메소드, 멤버함수 등에 매칭) 

1.4 연관 

 - 두 캘리스 사이를 실선으로 표시

 - 다중성 : 얼마나 많은 객체가 프로퍼티에 들어갈 수 있는지 표현 

 - 단순연관 관계 : 다른 객체의 참조를 가지는 인스턴스 변수를 의미

 - 연관관계의 특수한 유형

   집합 : 한 객체에 여러개의 독립적인 객체들이 구성되는 관계

   복합 : 한 객체의 보속으로서 여러 객체들이 구성되는 관계

    -> 일반 연관관계와 엄격하게 구분해서 사용하지는 않음

문제 ) 다음의 내용을 클래스 다이어그램으로 명세하시오

 - 학교(school)에는 교장(Principal), 많은 학생(Student), 많은교사(Teacher)가 있습니다. 이들 각자는 이름과 생년월일이 있으며 책(Book)을 빌려서 반환할 수 있습니다. 교사와 교장은 모두 봉급을 받습니다. 교장은 교사를 평가합니다. 학교 이사회(School board)는 여러 학교를 감독하고, 각 학교의 교장을 고용하고 해고할 수 있습니다. 학교에는 많은 방(Room)이 있습니다. 방의 종류는 화장실, 교실 및 카페테리아가 있습니다. 각 교실에는 많은 컴퓨터와 책상이있습니다. 

2. 객체 다이어그램(Object Diagram)

 - 시스템에 있는 객체들의 어떤 순간의 모습 (특정 시점의 스냅샷)

 - [형식] 이스턴스 이름 : 클래스 이름    (클래스 다이어그램과 다르게 아래에 밑줄이 있음)

 - 서로 연결된 객체의 예시를 보여줄 떄 유용 -> 클래스 다이어그램만으로는 구조를 명확하게 이해하기 어려울 때, 객체 다이어그램을 통해 이해를 도울 수 있음. 

3. 패키지 다이어그램 (Package Diagram)

- 모델 요소간 계층적 구성 (포함관계 등)을 명세

- 소스코드의 의존 관계 및 패키지 구조를 가시적으로 표현하기 위한 다이어그램

- 패키지 : 상위의 구성요소의 집합( ex. 클래스의 묶음)

         - java,c++ 등의 namespace s등과 대응

         - 클래스 : 단일 패키지의 멤버

         - 패키지 : 상위의 패키지의 멤버가 될 수 있음

- 패키지 명 표시를 위해 이중콜론 :: 을 사용 

.

패키지 합병 

- 둘 이상의 패키지를 합병하여 기존 패키지의 변경이 발생하는 것

- 합병하는 패키지(Source Package)와 합병이 되는 패키지(Target Package)간 의존 관계 발생시 수행

패키지 설계시 고려사항 

- 패키지 릴리즈/재사용 등가 원칙 : 동일한 릴리즈 또는 반복해서 재사용되는 클래스들을 하나의 패키지에 묶는 것이 효과적

- 공동 폐쇄 원칙 : 한 패키지의 클래스들의 변경 이유는 서로 유사해야함

- 공통 재사용 원칙 : 한 패키지의 클래스들은 함꼐 재사용되어야 함

- 의존 관계 비순환 원칙 : 패키지 간 의존관계로 인한 문제 예방을 위해 순환적 의존 관계를 제거해야 함.