OOAD와 UML에 대해 정리하기 전에 Unified Process를 좀 더 정리해보고자 합니다.

Unified Process, UP라고도 자주 부르는 녀석은 소프트웨어 공학 강의에서 자주 듣게되는 녀석입니다.


Wikipedia에서 검색해보니 아래와 같이 정의해 놓았습니다.


"Unified Process is a Popular iterative and incremental software development process framework."


인기있는 Iterative 소프트웨어 개발 방법론..? 정도로 이해하면 될 것 같습니다. 여기서 Iterative는 팀마다, 사람마다, 상황마다 다르겠지만 약 2~3주 정도의 고정된 시간을 두고 Iterative를 진행합니다. 


그럼 UP의 3가지 특성을 살펴보겠습니다.


1. Iterative and Incremental

UP는 위에서 정의된 바와 같이 iterative and incremental 개발 프로세스입니다. Elaboration, Construction, Transition 단계가 Iteration들 내에서 계속 반복됩니다. Water-fall의 경우 전체 개발 프로세스 중 Elaboration, Construction, Transition 등의 단계가 한번만 나타나지만 UP에서는 각 Iteration(2~3주 간격으로 반복되는..) 내에 Water-fall이 들어있어 Iteration마다 위 단계들이 반복된다고 생각하시면 됩니다.


2. Architecture-centric

UP는 Architecture가 시스템 구축을 위한 프로젝트의 중심에 있다고 주장합니다. 단일 모델만으로는 시스템의 모든 측면을 지원할 수 없으므로 통합 프로세스는 여러 아키텍처 모델과 보기를 지원합니다.
프로세스의 가장 중요한 결과 자료 중 하나는 Elaboration단계에서 생성되는 실행 가능한 아키텍처 기준선입니다. 이러한 부분적인 시스템 구현은 아키텍처를 검증하는 역할을 하며 남은 개발을 위한 기초 역할을 합니다.

3. Risk-forcused
UP는 프로젝트 팀이 프로젝트 진행 시 초기에 High-risk인 요소들을 해결하는데 주력합니다. high-risk인 요소들을 먼저 해결하기 위해서 각 Iteration의 Elaboration 단계에서 선택하게 됩니다.


UP는 프로젝트를 총 4가지 Phase로 나눠 진행합니다.  4가지의 Phase는 Inception, Elaboration, Construction, Transition이며 하나씩 설명드리겠습니다.

1. Inception
Inception은 프로젝트에서 가장 작은 phase로, 이상적으로는 매우 짧은 phase에 해당합니다. 만약 Inception phase가 길다면, 과도한 선행사양이 책정된 것이라 생각할 수 있으며 UP에 맞지 않는 것이라 판단할 수 있습니다. 이 단계에서 알맞는 vision과 Business case, scope등을 정리하게 됩니다.

2. Elaboration
Elaboration phase에서 프로젝트팀은 시스템 요구사항의 대부분을 포착해야 합니다. Elaboration phase의 주요 목표는 알려진 위험 요소를 해결하고 시스템 아키텍처를 확립하고 검증하는 것입니다. 이 단계에서 수행되는 일반적인 프로세스에는 Use-case Diagram, Conceptual Diagram 및 Package Diagram 작성이 포함됩니다. Architecture의 반복적인 구현을 통해 high-risk를 줄여나갑니다. 이 Architecture는 주로 구현을 통해 검증됩니다. 가장 구조적으로 중요한 핵심 구성 요소를 포함하는 시스템의 부분적 구현입니다. Elaboration Phase가 끝나면 시스템 아키텍처가 안정화 되어야하며 실행 가능 아키텍처 기준선은 아키텍처가 핵심 시스템 기능을 지원하고 성능, 확장 성 및 비용면에서 올바른 동작을 나타낼 수 있어야합니다.

3. Construction
Construction Phase는 프로젝트 진행 중 가장 큰 단계입니다. 이 단계에서는 시스템의 나머지 부분이 Elaboration된 기반 위에 구축됩니다. 시스템 기능은 Iteration으로 구현됩니다. 각 Iteration은 소프트웨어의 실행 가능한 결과물이 나오게 됩니다. 구축 단계에서 전체 Use-Case를 작성하는 것이 일반적이며, 각각은 새로운 Iteration의 시작이 됩니다. 이 단계에서 사용되는 UML (Unified Modeling Language) Diagram은 Activity, Sequence, State 다이어그램 등이 포함됩니다. 낮은 위험과 쉬운 요소에 대한 반복 구현이 수행됩니다. 최종 Construction 단계의 결과물은 Transition Phase에서 소프트웨어로 즉시 배치 할 수 있습니다.

4. Transition
프로젝트의 마지막 Phase입니다.  이 단계에서 시스템이 Client에게 배포됩니다. 초기 릴리스(또는 초기 릴리스)에서 받은 피드백은 여러 Transition의 Iteration 과정에서 추가 개선 사항이 통합될 수 있습니다. Transition phase 에는 시스템 전환 및 사용자 교육도 포함됩니다.

감사합니다.


Design Pattern을 공부하기 전에 Object-Oriented Principle에 대해 정리해 보고자 합니다. 


Abstraction, Encapsulation, Polymorphism 등을 이해하고 있다면 쉽게 이해할 수 있습니다. 우리가 OOAD, Design Pattern을 공부하고자 하는 이유가 객체지향 프로그래밍에서 좋은 설계를 하기 위한 요소로서 공부하고 있습니다. 


잘못된 설계는 추후 큰 문제를 일으키게됩니다. 잘못된 설계라는 것을 파악할 수 있는 요소는 여러가지가 있는데 시스템의 변경이 어려워 하나를 변경하고자 하면 그 문제가 큰 Rigidity, 시스템의 일부를 변경하면 다른 부분에 영향이 가는, 하위 클래스의 변경이 상위 클래스에 영향을 주는 Fragility, 시스템에서 각 컴포넌트 단위로 독립되어 있지 않아 분리가 어려워 재사용성이 어려운 Immobility, 설계의 잘못으로 인해 설계에 맞춰 코드 작성이 어려운 Viscosity, 불필요하게 모듈이 구성되어 있는 Needless Complexity, 동일한 로직들이 계속 반복되는 경우의 Needless Repetition, 개발자의 의도를 알 수 없는 코드들의 Opacity가 있습니다.


위와 같은 문제들은 여러 이유가 있겠으나 대부분 잘못 관리된 의존성에 의해 발생하게 되고 프로젝트의 실패로 이어지게 됩니다. SOLID는 이러한 문제들이 발생하지 않도록 기본적으로 객체지향에서 가이드해주는 원칙입니다. 서론이 길었네요.


SOLID는 OOP의 5대 원칙으로 자주 불리는 녀석입니다. Solid가 아닌 SOLID, 대문자로만 이뤄진 것을 보니 하나의 알파벳이 어떠한 약자들이란 예측이 되시나요?


각 알파벳의 약자는 아래와 같습니다.

    • S - Single Responsibility Principle, SRP, 단일책임원칙

    • O - Open Closed Principle, OCP, 개방폐쇄원칙

    • L - Liskov Substitution Principle, LSP, 리스코프치환원칙

    • I - Interface Segregation Principle, ISP, 인터페이스분리원칙

    • D - Dependency Inversion Principle, DIP, 의존성역전법칙


용어만 봐서는 어떤 원칙인지 잘 모르겠습니다. 그럼 하나씩 살펴보도록 하죠.


1. Single Responsibility Principle, SRP, 단일책임원칙

여러분들이 하나의 모듈을 개발할 때 다양한 기능을 할 수 있다면 좋을거라 생각할 수 있습니다. 한 녀석이 100가지 일을 할 수 있다면!! 일당백이라고 좋아할 수 있겠으나, 잘못된 생각입니다. 이 원칙은 이름을 보면 알 수 있듯이 한 녀석은 하나의 책임만을 가지고 있어야 하는 것입니다. 왜? 하나의 책임만을 가져야 할까요? 소프트웨어 개발 및 유지보수 하는 개발자 입장에서는 하나의 책임만을 가진 모듈을 수정할 시 수정할 부분이 최소화 되고 있습니다. 만약 많은 책임을 가진 객체라면 문제 발생 시 수정해야 할 부분이 굉장히 많겠죠, 소프트웨어 개발 시 변경을 최소화 하기 위해 고유한 책임을 부여하는 방법입니다.!

만약 여러분들이 개발하다보니 여러 개의 책임을 가진 모듈이 발생하게 된다면... 이 녀석의 책임을 여러 클래스로 찢어놓아야 합니다!


2. Open Closed Principle, OCP, 개방폐쇄원칙




3. Liskov Substitution Principle, LSP, 리스코프치환원칙




4. Interface Segregation Principle, ISP, 인터페이스분리원칙




5. Dependency Inversion Principle, DIP, 의존성역전법칙




UML은 Unified Modelling Language의 약자로서 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용합니다. 시스템의 구조적인 청사진을 그리기 위해 많이 사용되며 그외에도 매우 다양한 용도에 맞게 사용할 수 있습니다. 


많이 착각하시는 것 중 하나가 UML을 OOAD 개발 프로세스라고 생각하시는데 그 부분은 잘못된 부분입니다. UML은 소프트웨어를 개발하기 위한 방법이 아니기 때문입니다. 그리고 UML은 여러분 에게 Object-Oriented 한 사고를 가르쳐주지 않습니다. 어떻게 Operation과 Data를 가진 Object 구조를 그릴 수 있는가, 여러분이 디자인한 내용이 잘된것인가는 UML이 알려주지 않는다는 것이죠. 그럼 UML에 대해 조금씩 알아보겠습니다.


UML Semantics은 4개의 layer 구조(Instance -> model -> meta model -> meta-meta model)를 가집니다.

 - Layer M0 (Instance) : Application 영역, 즉 코드 레벨

 - Layer M1(model) :  UML model layer에 해당됩니다. 각 class간 관계등을 정의해 놓은 Layer. 실제 모델링하는 Layer

 - Layer M2(meta model) : 해당 요소가 class인지 abstract class인지 attribute인지 등등을 정의해놓은 Layer

 - Layer M3(meta-meta model) : Layer M2를 정의하는 meta data가 존재하는 Layer.

위 4가지를 이용해서 UML에서 semantic을 정의하게 됩니다.


UML을 적용하기 위한 3가지 방법이 있습니다. Sketch, Blueprint, Programming Language로 3가지 입니다. 보통은 Sketch, Blueprint에서 많이 사용합니다. Sketch는 Concept 측면에서 단순하게 Solution을 다른 사람과 공유하기 위한 방법으로 많이 사용되며, Blueprint는 명세서 수준으로 자세하게 작성하기 위한 용도입니다. Blueprint는 개발자가 코드로 작성하기 위한 바로 전 단계로서 정말 자세하게 작성하는게 좋습니다. Programming language 용도는 잘 사용되지 않기 때문에 패스하겠습니다 :-)


UML Diagram에 대해 하나씩 살펴봅시다. RML Diagram은 크게 structure diagram과 Behavior Diagram으로 나눠져 있으며 구조와 행위에 대해 어느 것을 강조하여 Diagram을 그릴 것 인가에 따라 선택하면 됩니다.


먼저, Structure Diagram에 속하는 Diagram을 알아봅시다.


Use Case Diagram

모든 Diagram의 시작이라고 할 수 있는 Use-Case diagram은 사용자가 시스템을 사용하는 경우에 대해 시나리오 형태로 명세해 놓은 diagram입니다. 즉 시스템 내부의 구현은 전혀 모르고 어떻게 사용할지, 어떻게 반응할지에 대해 사용자가 만족할 수 있도록 시나리오를 작성하는 것입니다. 사용자의 요구사항에 따라 정리 될 수 있습니다. 여기서 사용자는 개발하려는 시스템과 상호작용하는 사람, 기관, 다른 시스템 등이 될 수 있습니다. 


Class diagram

Class diagram은 시스템을 구성하는 Class들의 구조를 명세해 놓은 diagram입니다. class간의 관계, class의 상태(attributes)와 행위(operations)을 작성해 놓은 것입니다. 여러분들이 자주 보시는 Diagram일 것이니 추가적인 설명은 생략하겠습니다.


Object Diagram

Object diagram은 특정 시점의 class들의 Instance를 보여주는 diagram입니다. 즉 시스템이 동작하는 중간의 Snapshot이라고 할 수 있죠. 지금 Object의 attributes가 어떠한 값을 가지고 있는지 등을 나타내는데 사용하는 Diagram입니다.


Package Diagram

Package diagram은 class의 그룹을 명세해 놓은 diagram입니다. 복잡하지 않고 오직 Package와 그 내부의 class를 나타내고 있는 간단한 diagram입니다. Package 내부에는 또 다른 Sub package가 존재할 수 있습니다. 


Component Diagram

Component diagram은 Package가 class들의 모음이라면 package는 런타임에 Component에 포함됩니다. 즉 package들이 모음을 명세해놓은 diagram이라고 봐도 될 것 같습니다. 복잡하고 큰 시스템에서 내부 의존성과 구조를 나타낼 수 있습니다.


Composite Structure Diagram

큰 시스템에서 Component들의 관계를 명세해놓은 Composite Structure Diagram입니다. Component Diagram을 좀 더 상세하게 그려놓은 diagram으로 data의 상호 통신(inter-communication) 등을 표현할 수 있습니다.


Deployment Diagram

Composite Structure Diagram 등을 작성하였다면 특정 시스템에서 실제로 동작하기 위해 하드웨어와 연결시켜 명세해 놓은 diagram입니다. 하드웨어의 OS나 어떠한 모델, 크게는 자동차, 선박, PC등으로 나뉘어서 나타내는 diagram입니다. DB 서버는 어떠한 프로그램을 사용하는지 등도 나타냅니다.



다음은 Behavior diagram에 속하는 Diagram들을 살펴보죠.


Sequence Diagram

Sequence diagram은 시간 흐름을 기반으로 object 간의 상호작용을 명세해 놓은 diagram입니다. Use-case에 대해 어떻게 sequence적으로 동작하는지 설명해 놓습니다. Object간 Operation 요청과 그에 맞는 return 등을 나타냅니다.


Communication Diagram

Sequence diagram과 유사하지만 Class diagram에서 attribute와 operation을 지운 Class들만 배치한 후 object간 Operation들을 순차적으로 넘버링하여 작성 및 나타냅니다. Sequence Diagram 보다 명세하기 훨씬 편하나 Sequence만큼 명확하게 나타내기는 어렵습니다.


State Diagram

State Diagram은 State Machine, State Chart Diagram으로도 불리며, 여기서 State는 말 그대로 상태를 나타냅니다. 상태의 변화에 따른 다양한 이벤트를 나타내는 Diagram으로 시스템이 상태에 따라 동작하게 된다면 이 Diagram으로 나타내면 좋습니다. 흔히 알고계신 유한상태머신이라고 생각하시면 됩니다.


Timing Diagram 

Timing을 보여주는 Diagram으로 어떤 시점에 object의 operation들이 동작해야 하는지를 나타낼 수 있습니다. 


Activity Diagram

선택, 반복 및 동시성을 지원하는 단계별 활동 및 동작의 워크 플로를 그래픽으로 표현한 것입니다. Flow-chart나 Data flow를 명세할 때 많이 사용합니다. 


Interaction Overview Diagram

Object간 상호작용의 흐름을 명세한 Diagram입니다. 


이상 UML Diagram의 종류들을 살펴보았습니다. 살펴본 많은 Diagram은 여러분들이 필요 시 선택하여 시스템을 명세하면 됩니다. 각 Diagram의 자세한 내용은 별도로 학습을 하며 UML을 그려나가시면 좀 더 빠르게 익히시고 그 차이를 알 수 있을 것 같습니다. 


긴 글 읽어주셔서 감사합니다.


+ Recent posts