최신의 UML 과 RUP · 2015-01-22 · 최신의 객체지향 방법론uml 과 rup (v 0.2) 쌍용정보통신 황남주 page : 6/46 를 엮으면서 이 문서는

최신의 객체지향 방법론UML과 RUP (v 0.2)

쌍용정보통신 황남주 Page : 1/46

최신의 객체지향 방법론

UML과 RUP

1999. 4. 쌍용정보통신 황남주



최신의 객체지향 방법론 UML과 RUP

이 책의 내용은 쌍용정보통신주식회사에서 제작한 것입니다.

ⓒ 1999 쌍용정보통신주식회사

개정이력 1999.3.17 버전 0.1 문서의 목적과 목차 설정 1999.4.9 버전 0.2 소개용 교육자료로 사용할 수 있도록 40여쪽으로 정리하다.

이 책의 내용은 사전 통지 없이 변경될 수 있습니다. 이 책의 내용에 오류가 또는 이의가 있을 경우 알려 주시면 감사하겠습니다.

Printed in Seoul, Korea.



차례

<UML과 RUP>를 엮으면서 ...............................................................................................................6

1. 들어가기................................................................................................................................................7

제 1부 객체지향 모델링 언어 UML................................................................................................8

2. UML 개요 .............................................................................................................................................9 2.1 UML이란 무엇인가?............................................................................................................................... 9 2.2 UML을 정의하게 된 동기.................................................................................................................. 10

2.2.1 모델링을 하는 이유 ................................................................................................................. 10 2.2.2 소프트웨어 산업의 경향......................................................................................................... 10 2.2.3 산업표준이 생기기 전............................................................................................................. 10

2.3 UML의 목표............................................................................................................................................ 12 2.4 UML의 범위............................................................................................................................................ 13

2.4.1 UML 산출물 ................................................................................................................................ 13 2.4.2 UML의 범위 바깥..................................................................................................................... 14

2.5 UML의 과거, 현재 그리고 미래 ...................................................................................................... 15

2.5.1 UML 0.8 – 0.91 ............................................................................................................................. 15 2.5.2 UML 1.0 – 1.1................................................................................................................................ 15 2.5.3 UML의 현재와 미래 ................................................................................................................ 16

3. 사용사례..............................................................................................................................................17 3.1 액터와 사용사례.................................................................................................................................... 17 3.2 사용사례 다이어그램 (Use Case Diagram)....................................................................................... 17 3.3 사용사례 기술 ........................................................................................................................................ 17

4. 클래스 다이어그램 ..........................................................................................................................18 4.1 연관 (Association)................................................................................................................................... 18 4.2 속성 (Attribute)........................................................................................................................................ 18 4.3 연산 (Operation)...................................................................................................................................... 18 4.4 일반화 (Generalization).......................................................................................................................... 18 4.5 제약 규칙 (Constraint Rule).................................................................................................................. 18

5. 상호작용 다이어그램 (Interaction Diagram) ............................................................................18 5.1 순차 다이어그램 (Sequence diagram) ................................................................................................ 18 5.2 협동 다이어그램 (Collaboration Diagram) ........................................................................................ 18 5.3 순차 다이어그램과 협동 다이어그램의 비교............................................................................... 18 5.4 언제 상호작용 다이어그램을 사용하는가?................................................................................... 18



6. 상태 다이어그램 (State Diagram)................................................................................................18

7. 활동 다이어그램 (Activity Diagram)...........................................................................................18

8. 컴포넌트 다이어그램 (Component Diagram)...........................................................................18

9. 배치 다이어그램 (Deployment Diagram)...................................................................................18

제 2부 객체지향 개발공정 RUP......................................................................................................18

10. RUP 개요 ..........................................................................................................................................18 10.1 RUP란 무엇인가? ................................................................................................................................ 18 10.2 공정 구조: 2차원................................................................................................................................. 18 10.3 RUP의 간략한 역사............................................................................................................................ 18

11. 정적 구조: 공정 기술...................................................................................................................18 11.1 RUP 모델 ................................................................................................................................................ 18 11.2 작업흐름................................................................................................................................................. 18

12. 동적 구조: 반복 개발...................................................................................................................18 12.1 반복 개발 공정에서의 단계와 이정표 ......................................................................................... 18 12.2 단계별 상세 내역................................................................................................................................ 18

12.2.1 인식 단계 .................................................................................................................................. 18 12.2.2 구체 단계 .................................................................................................................................. 18 12.2.3 구축 단계 .................................................................................................................................. 18 12.2.4 인도 단계 .................................................................................................................................. 18

13. 업무모델링 작업흐름....................................................................................................................18 13.1 목적.......................................................................................................................................................... 18 13.2 작업흐름................................................................................................................................................. 18 13.3 산출물 ..................................................................................................................................................... 18 13.4 업무모델에서 시스템으로 전이...................................................................................................... 18

14. 요구사항 작업흐름 ........................................................................................................................18 14.1 목적.......................................................................................................................................................... 18 14.2 작업흐름................................................................................................................................................. 18 14.3 산출물 ..................................................................................................................................................... 18

15. 분석 설계 작업흐름 ......................................................................................................................18 15.1 목적.......................................................................................................................................................... 18 15.2 작업흐름................................................................................................................................................. 18 15.3 산출물 ..................................................................................................................................................... 18

16. 구현 작업흐름.................................................................................................................................18 16.1 목적.......................................................................................................................................................... 18 16.2 작업흐름................................................................................................................................................. 18



16.3 산출물 ..................................................................................................................................................... 18

17. 시험 작업흐름.................................................................................................................................18 17.1 목적.......................................................................................................................................................... 18 17.2 작업흐름................................................................................................................................................. 18 17.3 산출물 ..................................................................................................................................................... 18

부록 ...........................................................................................................................................................18 A.1 용어의 번역............................................................................................................................................ 18 A.2 참고도서.................................................................................................................................................. 18



<UML과 RUP>를 엮으면서 이 문서는 UML과 RUP를 기반으로 최신의 객체지향 방법론을 설명하고자 만든 것이다. 이 문서는 교육교재로서의 목적을 가지고 있다. 추후 실행지침으로서 발전시킬 수 있다.

쌍용정보통신에서는 95년도에 Rational 사의 자문(consulting)을 받아 객체지향 패러다임을 적용한 파일럿 프로젝트를 수행하였다. 당시의 파일럿 프로젝트의 주제는 <클라이언트/서버 환경에서의 문서관리 시스템>이었으며 파일럿 프로젝트가 성공적으로 수행됨으로 인해서 이 설계 기법을 추후 제품 개발에 활용하게 되었다. 그렇게 해서 만들어진 제품들이 OA Master 3.0, CyberOffice 1.0, 2.0, 3.0, ImageArt 4.0 등의 제품들이다.

이러한 발전은 회사의 적극적인 지원이 있었기에 가능하였을 것이다. 파일럿 프로젝트를 수행하는데 드는 비용을 감수할 수 있었던 과감한 투자, 새로운 프로젝트를 새로운 패러다임으로 개발할 수 있도록 허락하는 상위 조직의 결단 등이 그러한 변화를 가능하게 하였을 것이다.

이제는 제품 개발 뿐 아니라 SI 전반에 걸친 대규모 프로젝트에 적용시킬 수 있는 쉬운 길잡이를 제시해야 할 것으로 생각한다. 현재의 교육 교재는 그러한 도약을 위한 준비작업의 하나이다.



1. 들어가기 소프트웨어 개발 방법론이란 소프트웨어를 개발하는데 적용되는 방법으로서 크게 모델링 언어(modeling language)와 공정(process)의 2 가지 영역으로 나눌 수 있다. 모델링 언어는 설계를 표현하기 위해 사용하는 주로 그림으로 된 표기법을 의미한다. 공정은 개발을 하는 단계별 지침을 의미한다.

객체지향 방법론이 발전하면서 이 중에서 모델링 언어는 UML로 표준화되었다. 공정은 표준화되지는 않았으나 Rational에서 제시하는 RUP가 준표준으로 등장하고 있다.

프로젝트에 방법론을 적용할 때에 모델링 언어를 사용하기는 쉽지만 공정을 제대로 따르는 경우는 드물다. 따라서 많은 경우에 모델링 언어가 방법론에 있어서 중요한 역할 을 하고 있으며 또한 의사 소통에 있어서 핵심적인 부분이기도 하다.

이 글에서는 객체지향 방법론으로서 UML과 RUP를 설명한다.



제 1부 객체지향 모델링 언어 UML



2. UML 개요

2.1 UML이란 무엇인가? Unified Modeling Language (UML)은 소프트웨어 시스템, 더 나아가 업무 모델링, 기타 소프트웨어가 아닌 시스템의 산출물을 규정하고 시각화하며 구현하고 문서화하는 언어이다 (The UML is a language for specifying, visualizing, constructing, and documenting the

artifacts of a software systems, as well as for business modeling and other non-software systems). UML 은 복잡한 대형 시스템을 모델링하는데 성공적으로 증명된 공학적 기법들을 모아 제시한 것이다.

UML 은 80 년대 후반에서 90 년대에 이르는 기간 동안 나타난 객체지향 분석 설계 방법론의 흐름을 이어받은 객체지향 모델링 언어이다. 가장 영향력이 있던 Booch와 Rumbaugh, Jacobson 의 방법론을 직접적으로 통합하였으며 이외 방법론의 장점들을 모아서 표준화시킨 것이다. 99 년 3 월 현재 UML 은 OMG(Object Management Group)에 의해서 표준으로 확정되었으며 개정된 1.1 판이 제시된 상태이고 1.3 판의 개정 작업이 이루어지고 있다.

UML은 모델링 언어로서 방법론의 일부이다. 방법론의 다른 부분인 공정(process)은 표준화되어 있지 않으나 어떠한 방법론을 사용하든지간에 통일된 표기법을 제시하는 것이 UML의 역할이다.



2.2 UML을 정의하게 된 동기

2.2.1 모델링을 하는 이유 소프트웨어 시스템을 구축하거나 혁신하기 전에 모델을 개발하는 것은 건물을 지을 때 청사진을 그리는 것과 마찬가지로 필수적인 일이다. 좋은 모델은 아키텍처를 건전하게 하고 프로젝트 팀의 의사소통을 원활히 하는 데에 있어서 필수적이다. 복잡한 시스템의 모델을 만드는 이유는 그러한 시스템을 한번에 통째로 이해할 수 없기 때문이다. 시스템의 복잡성이 커질수록 좋은 모델링 기법의 중요성도 커지게 마련이다. 프로젝트의 성공을 위한 요소들이 많이 있지만 엄격한 모델링 언어의 표준화는 그 중 필수적인 요소이다. 모델링 언어는 다음과 같은 사항을 포함해야 한다.

모델 요소 – 기본적인 모델링 개념 및 의미

표기법 – 모델 요소의 시각적 표현

지침 – 업무에 맞춘 사용법

시스템의 복잡성이 증가하고 있는 현 시점에서 시각적 모델링은 더욱 필수가 되고 있다. UML 은 이러한 필요성에 부응하는 잘 정의되고 널리 받아들여지고 있는 표준으로서 객체지향, 컴포넌트 기반의 시스템을 구축하는 시각적 모델링 언어이다.

2.2.2 소프트웨어 산업의 경향

많은 회사에서 소프트웨어의 전략적 가치가 증가함에 따라 산업계는 소프트웨어의 생산을 자동화할 수 있는 기법을 찾게 되었다. 그 기법은 품질을 향상시키고 비용과 시간을 절감할 수 있는 기법들로서 컴포넌트 기술, 시각적 프로그래밍, 패턴, 프레임웍 등을 포함한다. 또한 시스템이 범위나 스케일이 증가하는 경우에도 그 복잡성을 다루어 낼 수 있는 기법이 필요했다. 특히, 반복해서 나타나는 아키텍처에 관련된 문제, 예를 들어, 물리적인 분산, 동시성, 복제, 보안, 로드 밸런싱, 고장 방지 능력(fault tolerance) 등을 해결하기 위한 필요성을 인식하게 되었다. 최근의 월드와이드 웹을 위한 개발경향은 몇 가지를 단순화시켰지만 아키텍처 문제는 더욱 심화되었다.

복잡성은 응용프로그램의 영역과 공정의 단계에 따라 다르게 마련이다. UML 개발자들에게 다가온 핵심적인 동기부여 중의 하나는 모든 영역에 걸쳐 모든 규모의 복잡한 아키텍처를 적절하게 처리할 수 있는 의미와 표기법을 창조해내는 것이었다.

2.2.3 산업표준이 생기기 전

UML 이전에는 뚜렷이 선도하는 모델링 언어가 없었다. 사용자들은 대동소이한 많은 모델링 언어 중에서 하나를 선택해야만 하였다. 대부분의 모델링 언어들은 많은



개념들을 공통적으로 사용하면서도 그것을 약간씩 다른 의미와 표기법을 통해 표현하였다. 이러한 통일성의 부족은 새로운 사용자들이 객체지향 모델링을 선택하는데 꺼리는 요소가 되었다. 사용자들은 일반적으로 사용되기에 적합한 산업계의 표준이 등장하기를 기다려 왔다. 즉 모델링을 위한 공통어를 원했던 것이다.

업체들 역시 비슷하면서 약간씩 다른 여러 모델링 언어를 지원해야 할 필요성 때문에 객체 모델링 분야에서 어려움을 느끼고 있었다. 따라서 많은 업체들이 통일된 모형화 언어로서의 UML의 개발을 지지하게 되었다.

UML은 프로젝트의 성공을 보장하는 것은 아니지만 많은 일들을 개선시킨다. 예를 들어, 프로젝트나 조직을 바꿀 때에 새로 교육하는 비용을 감소시킨다. 또한 여러 가지 도구나 공정, 영역 사이의 통합을 이끌어 낼 수 있다. 가장 중요한 것은, UML이 개발자들로 하여금 업무 가치를 생산하는데 집중할 수 있게 하고, 그것을 성취할 수 있는 패러다임을 제공한다는 데 있다.



2.3 UML의 목표

UML의 저자들이 UML을 설계하면서 주안점을 두었던 목표는 다음과 같다.

1. 사용자들이 의미있는 모델을 만들고 교환할 수 있도록 사용하기 쉽고 표현이 풍부한 시각적 모형화 언어를 제공한다.

2. 핵심 개념을 확장하기 위한 메커니즘을 제공한다.

3. 특정 프로그래밍 언어나 개발 공정에 종속되지 않아야 한다.

4. 모델링 언어를 이해하기 위한 공식적 기준을 제공한다.

5. 객체지향 도구 시장의 성장을 장려해야 한다.

6. 고수준의 개발 개념들, 예를 들어 협동(collaboration), 프레임웍, 패턴, 컴포넌트 등의 개념들을 지원한다.

7. 산업계의 검증된 최상의 경험들을 통합한다.



2.4 UML의 범위

Unified Modeling Language (UML)은 소프트웨어 시스템의 산출물을 규정하고 시각화하며 구현하고 문서화하는 언어이다.

첫째로, UML은 Booch, OMT, OOSE의 개념을 융합하여 널리 사용될 수 있는 공통된 단일 모델링 언어를 만든 것이다.

둘째로, UML은 기존 방법론들로 할 수 있었던 일의 영역을 확장시켰다. 예를 들어, UML의 저자들은 분산 병렬 시스템의 모델링을 목표로 삼았다.

셋째로, UML 은 표준 공정이 아니라 표준 모델링 언어에 초점을 맞추었다. 물론 UML은 어떤 공정의 문맥 안에서 적용되어야 하겠지만 경험상으로 보면 조직과 문제영역의 차이에 따라 다른 공정이 요구되기 때문이다. 그러므로, 의미를 통일시키는 공통 메타모델과 그 의미를 표현할 수 있게 하는 공통 표기법을 개발하는데 집중하였다. UML의 저자들은 사용사례 중심, 아키텍처 중심, 점진 반복적인 개발 공정을 권장한다.

UML은 객체지향 공동체의 일치된 의견을 핵심 모델링 개념에 통합한 모델링 언어이다. 그 확장 메커니즘에 따라 문제영역에 맞게 재단하여 사용할 수 있다.

2.4.1 UML 산출물

모델링은 관련된 부분에 집중하고 나머지는 무시하는 추상화를 통해 이루어진다. 모델의 특성에는 다음과 같은 것이 있다.

복잡한 시스템은 모델의 독립적인 뷰의 집합으로 표현될 수 있다. 하나의 뷰만으로는 충분하지 않다.

모든 모델은 상세함의 정도가 다른 여러 차원으로 표현될 수 있다.

좋은 모델은 실재를 잘 반영한다.

UML은 모델의 뷰라는 용어를 사용하여 다음의 그래픽 다이어그램을 정의한다. 다음 중 밑줄 친 8개의 다이어그램이 실제 산출물의 이름이다.

사용사례 다이어그램 use case diagram : 사용사례와 사용자의 관계를 표현하는 다이어그램

클래스 다이어그램 class diagram : 클래스의 관계를 표현하는 다이어그램

행위 다이어그램 behavior diagrams

상태차트 다이어그램 statechart diagram : 객체의 생명주기를 나타내며, 이벤트에 의해 변화하는 객체의 상태를 표현하는 다이어그램

활동 다이어그램 activity diagram : 객체에 작용하는 활동의 흐름을 표현



하는 다이어그램 상호작용 다이어그램 interaction diagrams

순차 다이어그램 sequence diagram : 객체들간의 상호작용을 시간적 순서를 강조하여 표현하는 다이어그램

협동 다이어그램 collaboration diagram : 객체들간의 상호작용을 공간적 협조 체계를 강조하여 표현하는 다이어그램

구현 다이어그램 implementation diagrams

컴포넌트 다이어그램 component diagram : 컴포넌트들의 관계를 표현하는 다이어그램

배치 다이어그램 deployment diagram : 시스템을 구성하는 물리적 객체나 장치들의 관계를 표현하는 다이어그램

위 다이어그램들은 분석 또는 개발 중인 시스템에 복합적인 관점을 제공한다. 모델은 이러한 관점들을 통합하여 일관성 있는 시스템이 개발될 수 있게 한다. 이 다이어그램들과 설명적인 문서들이 주된 산출물이 된다.

2.4.2 UML의 범위 바깥

프로그래밍 언어 UML 은 모델링 언어로서 프로그래밍 언어는 아니다. 복잡한 알고리즘 같은 것은 프로그래밍 언어로 표현하는 것이 나을 것이다. UML은 객체지향 언어와 긴밀하게 연결되어 있으므로 둘을 동시에 활용할 수 있어야 한다.

도구 언어의 표준화는 필연적으로 도구와 공정을 위한 기반이 된다. UML 이 제공하는 의미와 표기법은 도구의 개발과 호환성에 도움이 된다.

공정 UML 은 공정에 독립되어 공통어로 사용된다. 공정은 프로젝트의 성공을 좌우하는 중요한 요소이지만 조직과 문화, 그리고 주어진 문제 영역에 맞추어 재단되어야 한다.

Booch, OMT, OOSE 등 많은 방법론들은 잘 정의된 공정을 가지고 있으며 UML은 대부분의 방법론을 지원할 수 있다. 개발 공정에 대한 상당한 수렴이 있었지만 아직 표준화에 대한 합의에는 이르지 못했다. 아마도 최상의 경험들을 융합하여 개별적인 공정을 만들어낼 수 있는 공정 프레임웍이 도출될 가능성이 있다. UML은 특정한 공정을 지정하지는 않지만 사용사례 중심, 아키텍처 중심, 점진 반복적인 공정을 권장한다.



2.5 UML의 과거, 현재 그리고 미래

UML 은 Rational 과 그 협력사들에 의해 개발되었다. 이는 Booch, OOSE/Jacobson, OMT 와 그 외의 방법론에서 제시하던 모델링 언어를 계승 발전시킨 것이다. 많은 회사들이 UML 을 표준으로 받아들여 업무 모델링, 요구사항 관리, 분석 설계, 프로그래밍, 시험에 걸친 모든 범위에서 사용하고 있다.

2.5.1 UML 0.8 – 0.91 UML 이전

1970년대 중반부터 1980년대 후반에 걸쳐 몇 개의 객체지향 모델링 언어가 개발되어 객체지향 분석과 설계에 관한 다양한 접근방식을 제시하였다. 1994년에 이르러서는 모델링 언어가 50 개가 넘게 되었다. 이들은 어느 하나만을 가지고는 완전한 만족감을 줄 수가 없었으며 “방법론 전쟁”이라는 말이 나돌 정도였다. 그 와중에서 Booch ’93, OMT, Fusion의 방법론이 주목을 끌기 시작했고 이들은 서로 상대방의 기법을 융합하여 OOSE, OMT-2, Booch ’93의 이름으로 두드러지기 시작했다. 이들 각각은 나름대로 완전성을 갖추고 특정한 영역에 장점을 가진 것으로 인식되었다. 간단히 말하면, OOSE는 사용사례를 중심으로 하여 업무 엔지니어링과 요구분석에 탁월하였고, OMT-2는 분석과 자료 중심적인 정보시스템에 특히 풍부한 표현력을 가지고 있었다. Booch ’93 은 설계와 구현 단계에 특히 유용하고 공학 중심적인 응용프로그램 쪽에서 많이 사용되었다.

Booch, Rumbaugh, Jacobson이 힘을 합치다 UML의 개발이 시작된 것은 1994년 10월, Grady Booch와 Jim Rumbaugh가 Rational 사에서 자신들의 두 방법론을 통합하는 작업을 시작한 때이다. 이미 두 방법론이 세계적으로 가장 선도적인 위치에 있었기 때문에 이 작업은 통일의 큰 가능성을 보여주었다. 1995년 10월에 이 작업의 초안 0.8이 발표되었다. 1995년 가을에 Ivar Jacobson 과 그의 회사가 Rational 에 합류하여 UML 은 OOSE(Object-Oriented Software Engineering)까지 통합하게 되었다.

이들은 다른 사람들의 피드백을 받아들이며 1996년 6월과 10월에 UML 0.9와 0.91을 발표하였다.

2.5.2 UML 1.0 – 1.1 1996년에 Object Management Group(OMG)는 객체지향 모델링 언어의 표준화를 위한 제안요청서를 발행하였다. 이에 따라 Rational은 컨소시엄을 결성해 UML 1.0을 생산하고 이를 1997년 1월에 OMG에 제출하였다. 이 때 IBM & ObjecTime을 중심으로 한 다른 컨소시엄에서 따로 제안된 것이 있었으며 이 제안이 역시 UML에 통합



되어 1997년 UML 1.1로 개정되었다. OMG에서는 1997년 11월에 UML 1.1을 표준으로 승인하였다.

<그림 2.1 UML의 역사>

2.5.3 UML의 현재와 미래 OMG는 현재 UML 1.3을 확정하기 위해 노력하고 있으며 1999년 중반에 발표될 예정이다. UML은 독점되지 않으며 모두에게 개방되어 있다. 이미 전반적 차원에서 산업계의 표준으로 받아들여지고 있다.

비록 UML 이 정밀한 언어를 정의하고 있지만 그렇다고 해서 추후 개선의 여지가 없는 것은 아니다. 새로운 기법들이 차후 버전에 추가될 수 있을 것이며 현재의 UML은 그 핵심을 기반으로 확장해 나갈 수 있도록 되어 있다.

많은 도구들이 UML을 기반으로 함으로써 도구의 통합이 쉬어지고 구현을 위한 표준들이 가능해질 것이다. UML 은 많은 개념들을 통합시켜 왔으며 이에 따라 객체지향의 사용이 더욱 가속화될 것이다. 컴포넌트 기반의 개발은 객체지향 기술과 맞물려 있다. 최근 컴포넌트 기반의 재사용이 널리 확산되고 있지만 그렇다고 객체지향 기술을 대체하는 것은 아니다. 컴포넌트와 클래스는 의미에 있어서 단지 미세한 차이만을 갖고 있을 뿐이다.

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9June ´96

publicfeedback

Final submission to OMG, Sep ´97

First submission to OMG, Jan ´97UML 1.1

OMG Acceptance, Nov 1997UML 1.3

UML 1.0UML partners



3. 사용사례 3.1 액터와 사용사례

시스템의 요구사항은 누가 어떤 용도로 시스템을 사용하는지에 대한 명세서이고 이를 간단하게 액터와 사용사례의 관계로 표현할 수 있다.

액터는 개발하려고 하는 시스템과 상호작용하는 사용자 또는 외부시스템, 장치 등을 의미한다. 사용사례란 사용자와 컴퓨터 시스템간의 전형적인 상호작용을 의미하며 시스템의 기능을 분류해 주는 역할을 한다.

<그림 3.1 액터와 사용사례, 상호작용의 표현>

3.2 사용사례 다이어그램 (Use Case Diagram) 사용사례 다이어그램은 시스템의 요구사항을 액터와 사용사례의 관계로 시각적으로 표현한 것이다.

<그림 3.2 사용사례 다이어그램 예, 수강관리시스템>

3.3 사용사례 기술 사용사례의 구체적인 내용은 이벤트 흐름을 써서 기술한다.

과금 시 스 템

수 강등록과금 정 보학 생

수 강정 보

출 석 부요청

교수 강좌 선 택

교수

교수 관리

수 강편 람생성

학 생관리

커 리큘 럼관리

학 적 관

교수 정 보학 생정 보

강좌 정 보

액 터사용사례



4. 클래스 다이어그램 클래스 다이어그램은 시스템을 구성하는 객체들의 타입들과 그들간에 존재하는 다양한 정적 관계들을 기술한다. 정적인 관계에는 연관(association)과 하위타입(subtype)이 주로 사용된다. 연관이란 두 클래스가 관련이 있다는 것으로서 예를 들어 수강관리시스템에서 학생이 강좌를 신청할 수 있음을 의미한다. 하위타입이란 클래스간에 상속을 받는다는 것으로서 예를 들어 학생이 등록사용자의 일종임을 의미한다. 또한 클래스 다이어그램은 클래스의 속성과 연산 및 객체들의 연결 방법에 적용되는 제약조건들을 기술한다.

그림 4.1은 클래스 다이어그램의 예를 보여준다.

<그림 4.1 클래스 다이어그램의 예, 수강관리시스템>

4.1 연관 (Association) 연관은 클래스간에 관계가 있음을 나타낸다. 수강관리시스템에서 학생이 강좌를 신청한다거나 강좌에 따른 일정이 존재한다는 등의 예를 들 수 있다.

연관에는 관계에 참여하는 객체의 수를 멀티플리시티로 표시한다. 그림 4.1에서 보면, RegistrationUser 는 여러 개의 CourseOffering 을 신청할 수 있으며 한 CourseOffering에는 3명에서 10명까지의 RegistrationUser가 등록할 수 있음을 의미한

CourseRostersemesterstudentName

addStudent()print()

StudentSchedulesemestercourseName

addCourse()print()

RegistrationUser

namephoneaddressidNumber

(from Peop le)

CourseO ffe ringdaysOffe redtim eO fDaylocation

addStudent()addProfessor()isFull()

1

1

1

1

3..10

4

3..10

4

reg istersFor

CourseMaintenanceForm

setID()verifyID()addCourse()close()

(from Interfaces)

Regis trationForm(from Interfaces)

CourseSelectionForm(from Inter fa ces)

AddDropForm(from In te rfaces)

Course

namedescriptioncreditHours

create()

1

1

1

1

+primary

+alternate

0..*1..4 0..*1..4

0..*

1

0..*

1



다.

4.2 속성 (Attribute) 클래스의 속성은 클래스가 어떤 요소를 가지고 있음을 의미한다. 그림 4.1 에서, RegistrationUser의 name 속성은 RegistrationUser가 name을 가지고 있음을 의미한다.

UML에서는 visibility name: type = defaultValue와 같이 표기한다. 속성은 int나 real 같은 기본자료형일 수도 있고 string, date 등과 같은 작고 단순한 클래스일 수도 있다. 드물게는 크고 복잡한 클래스를 속성으로 가질 수도 있다.

4.3 연산 (Operation) 연산이란 클래스가 수행하는 처리로서 메소드라고도 한다.

UML에서는 visibility name (parameter-list) : return-type-expression { property-string }과 같이 표기한다. visibility에는 + (public), # (protected), – (private)의 세 종류가 있다.

4.4 일반화 (Generalization) 일반화는 공통된 속성 또는 연산을 가진 클래스들에서 공통 요소들을 추출하여 상위 클래스를 만들어내는 것을 의미한다. 학생, 교수 등의 클래스에서 등록사용자라는 클래스를 추출해내는 것과 같다. 이때 등록사용자에 대한 모든 사항은 학생에게도 똑같이 적용된다고 볼 수 있다. 공통 요소를 추출하는 것과 반대 방향으로 새로운 요소를 추가하여 하위클래스를 만들어내는 것은 특수화라고 한다.

명세 관점에서 보면 일반화란 하위타입의 인터페이스가 상위타입의 인터페이스로부터 모든 요소를 포함한다는 것을 의미한다. 구현 관점에서 보면 일반화는 프로그래밍 언어의 상속과 연관되어 있다. 하위클래스는 상위클래스의 모든 메소드와 속성을 상속받고 상속된 메소드를 재정의(override)할 수 있다.

4.5 제약 규칙 (Constraint Rule) 클래스 다이어그램에는 많은 제약사항을 기록한다. 그림 4.1은 한 CourseOffering에는 3명에서 10명까지의 RegistrationUser가 등록할 수 있음을 나타내고 있다. 연관, 속성, 일반화 등을 통해서 위와 같은 중요한 제약조건들을 규정할 수 있다.

그 외의 제약조건들은 중괄호 {} 사이에 기술한다. 특별한 문법은 정해져 있지 않으며 읽기 쉬운 자연어를 쓰든가 좀 더 명확한 논리적 기술 또는 단편적인 프로그램 코드를 사용해도 좋다.





5. 상호작용 다이어그램 (Interaction Diagram) 상호작용 다이어그램은 여러 객체들이 어떤 일을 처리하기 위해서 협동하는 행동양식을 기술하는 모델요소이다.

전형적으로 하나의 상호작용 다이어그램은 사용사례 하나의 행동양식을 포착하여 나타낸다. 다이어그램에는 사용사례에 관련된 객체들과 그들간에 주고받는 메시지가 표현된다.

상호작용 다이어그램에는 순차 다이어그램(sequence diagram)과 협동 다이어그램(collaboration diagram)의 두 종류가 있다.

5.1 순차 다이어그램 (Sequence diagram) 순차 다이어그램에서는 객체를 수직쇄선 위에 상자모양으로 표시한다.

<그림 5.1 순차 다이어그램의 예, 수강관리시스템>

이 수직선을 객체의 생존선(lifeline)이라고 하며 상호작용 동안의 객체의 생존을 나타낸다. 각 메시지는 두 객체 생존선간의 화살표로 표현한다. 이 메시지가 발생하는 순서는 위에서 아래로 순차적으로 표시한다.

그림에서 보듯이 순차 다이어그램은 무척 단순하고 즉각적인 시각적 매력을 갖고 있으며 따라서 자주 사용된다.

: 학 적 관Korean

Language : : Transac tion

Manager : DBCourse : Course

MaintenanceForm : Curriculum

Manager

1: setID ( )

2: verify ID (long)

3: addCourse ( )

4: addCourse (Course)5: create ( )

6: addCourse (Course)

7: saveCourse (Course)

8: close ( )



5.2 협동 다이어그램 (Collaboration Diagram) 협동 다이어그램은 순차 다이어그램과 같이 상호작용을 나타내는 또다른 표현기법이다. 순차 다이어그램에서와 같이 객체들은 상자모양 아이콘으로 표시한다. 객체들이 주고받는 메시지 역시 객체간의 화살표로 표시한다. 사용사례를 구현하기 위한 메시지의 순서는 메시지에 번호를 매겨 표시한다.

다음 그림은 앞의 순차 다이어그램과 같은 내용을 협동 다이어그램으로 다시 표현한 것이다.

<그림 5.2 협동 다이어그램의 예, 수강관리시스템>

메시지에 번호를 매기는 것은 순차 다이어그램보다 순서를 보기에 불편한 점이 있다. 반면에 객체들을 공간적으로 배치시킴으로써 아키텍처 등 다른 중요한 정보를 강조할 수 있다.

객체에 이름을 주는 규칙은 objectName : ClassName으로 한다.

5.3 순차 다이어그램과 협동 다이어그램의 비교 순차 다이어그램과 협동 다이어그램은 같은 내용을 다르게 표현하는 기법이다. 엄밀히 말하면 협동 다이어그램은 자료의 반환 흐름(data return flow)을 표현할 수 있다는 점이 다르다. 두 그림은 상황에 맞추어, 개인적인 취향에 따라, 바꾸어 사용할 수 있다.

5.4 언제 상호작용 다이어그램을 사용하는가? 상호작용 다이어그램은 하나의 사용사례 안에서 객체들의 행동양식을 표현할 때에 사용한다. 행동양식의 정밀한 정의를 표현하기에는 적절하지 않다.

여러 사용사례에 걸친 한 객체의 행동양식을 표현할 때에는 상태전이 다이어그램을 사용한다. 여러 사용사례에 걸쳐 있거나 쓰레드가 많은 행동양식을 표현할 때에는 활동 다이어그램을 사용한다.

: CourseMaint enanceForm

: 학 적 관

KoreanLanguage : Course

: CurriculumManager

: TransactionManager

: DBCourse

1: setID ( )

2: verify ID (long)

3: addCourse ( )


5: create ( )


7: saveCourse (Course)

8: c los e ( )



6. 상태 다이어그램 (State Diagram) 사용사례와 시나리오는 시스템의 행동양식 즉 객체들의 상호작용을 기술하는 기법이다. 때로는 한 객체의 행동양식을 기술할 필요가 있다. 상태전이 다이어그램은 한 객체가 자신의 생명주기 안에서 취할 수 있는 상태들과 그 상태간 전이를 일으키는 이벤트들, 그리고 상태간 변화에서 발생하는 작용들을 표현한다.

<그림 6.1 상태 다이어그램의 예, 수강관리시스템, 클래스 Course>

그림 6.1은 수강관리시스템에서 Course라는 클래스가 취할 수 있는 여러 상태와 그들간의 전이를 표현한 것이다.

상태 다이어그램은 시스템의 모든 클래스에 대해 그릴 필요는 없으며 의미있는 행동양식을 보여주는 주요 클래스들에 대해서 그린다. 가능한 상태나 이벤트 역시 필요에 따라 간단하거나 복잡한 수준으로 표현한다.

Initialized

do: initialize course

Canceled

do: Notify registered students

Open

ent ry : Reg ist er studentexi t: Increment count

addS tudent[ count < 10 ]

Closed

do: Report course is full

cancelCourse

Unassigned

do: Assign professor to course

cancelCourse

addStudent / numStudents = 0

RegistrationComplete

do: Generate c lass roster

cancelCourse

[ num Students = 10 ]

registrationClosed[ numStudents < 3 ]

registrationClosed[ numStudents >= 3 ]



7. 활동 다이어그램 (Activity Diagram) 활동 다이어그램은 작업흐름과 연계되어 병행 처리가 많은 행동양식을 기술하기에 특히 유용한 여러 기법들을 조합한 것이다.

<그림 7.1 활동 다이어그램의 예>

그림 7.1 은 음료를 마시는 활동에 대한 작업흐름을 표현한 활동 다이어그램이다. 그림에서 핵심 요소는 활동(activity)이다. 활동이란 개념적 관점에서 보면 사람이나 컴퓨터가 행하는 어떤 작업을 의미할 수도 있으며, 구현 관점에서 보면 클래스의 메소드를 의미할 수도 있다.

그림에서 [커피 찾기] 다음에 이어지는 [필터에 커피 넣기], [물통에 물 붓기], [컵 가져오기]의 세 활동은 병행 처리를 의미한다. 순서도(flowchart)가 보통 순차적인 프로세스에 제한되어 있는 반면에 활동 다이어그램은 병행 프로세스를 기술할 수 있다.

커 피 찾 기

필 터에커 피 넣기 물통 에물붓기 콜 라캔 가져 오 기

기계에필 터 설치

기계 켜 기

커 피 끓이기

컵 가져 오 기

콜 라 찾 기[ ]커 피 없 음

^ .커 피 포 트 켜 기

커 피 따르기 음 료마시 기

[ ]콜 라 있 음

[ ]콜 라 없 음



8. 컴포넌트 다이어그램 (Component Diagram) 컴포넌트 다이어그램은 시스템을 구성하는 실제 소프트웨어 컴포넌트간의 구성체계를 기술하므로 아키텍처를 표현하기에 좋다. 컴포넌트란 용어는 시스템의 물리적 구조를 구성하는 소스 코드 단위로부터 부시스템 같은 실행 프로그램에 이르기까지 다양하게 지칭한다. 예를 들어 개별 클래스의 헤더와 구현파일로부터 그들을 조합하여 만들어진 EXE, DLL 등까지 컴포넌트로 표시할 수 있다. 이러한 다양한 수준의 컴포넌트를 사용하여 시스템의 아키텍처를 표현한다.

컴포넌트 다이어그램에는 각 컴포넌트를 그리고 컴포넌트간의 의존성 관계를 화살표로 나타낸다.

<그림 8.1 컴포넌트 다이어그램의 예, 수강관리시스템>

그림 8.1은 수강관리시스템의 컴포넌트들을 의존성을 중심으로 간단하게 표현한 것이다. 시스템은 두 개의 EXE과 두 개의 DLL로 이루어져 있으며 각 DLL이 사용하는 클래스들을 표현하고 있다.

Billing.exe Register .exe

Course.dl l People.dl l

Course CourseO ffe ring Student Professor



9. 배치 다이어그램 (Deployment Diagram) 배치 다이어그램은 인도될 시스템의 소프트웨어와 하드웨어 컴포넌트간의 물리적 관계를 표현한다.

<그림 9.1 배치 다이어그램의 표기법>

그림 9.1 은 배치 다이어그램의 모델링 요소를 표현한 것이다. 배치 다이어그램은 노드와 노드간 연결로 구성된다. 노드는 프로세서나 디바이스처럼 독립된 하드웨어 요소를 의미하며 보통 클라이언트 PC 나 서버 워크스테이션, 때로는 간단한 주변장치나 메인프레임을 표시하기도 한다.

<그림 9.2 배치 다이어그램의 예, 수강관리시스템>

그림 9.2는 수강관리시스템의 배치 다이어그램으로서 서버와 단말기 요소들을 표현하고 있다.

Regist rat ion Dat abase

Lib rary

Dorm it ory

MainBuilding

프 로세

서이름

노드

디바이

스 이름

노드연 결

라벨



제 2부 객체지향 개발공정 RUP

소프트웨어 개발 공정(process)은 다음과 같은 네 가지의 역할을 한다.1

팀의 활동 순서에 따른 지침을 제공한다.

개발해야 할 산출물과 그 시기를 규정한다.

개별 개발자들과 팀 전체의 작업을 지시한다.

프로젝트의 제품과 활동을 제어하고 측정할 수 있는 기준을 제시한다.

제대로 정의된 개발공정이 없다면 개발팀의 작업은 순서가 없이 중구난방식으로 진행될 것이며 제대로 성공하기 어려울 것이다.

반면에 제대로 정의된 개발공정을 사용하고 있는 조직이라면 복잡한 시스템도 그 공정에 따라 순조롭게 개발할 수 있다. 프로젝트에 반복해서 적용됨에 따라 조직 전반적으로 효율성과 생산성이 높아질 것이다.

1 Grady Booch, Object Solutions—Managing the Object Oriented Project. Reading, MA: Addison-Wesley, 1995.



10. RUP 개요

10.1 RUP란 무엇인가? Rational Unified Process(RUP)는 소프트웨어 개발 공정(process)으로서 개발 조직 내에서 작업과 책임을 할당하기 위한 규칙을 제시한다. 그 목적은 예정된 일정과 예산 내에서 고객의 요구를 충족시키는 고품질의 소프트웨어를 생산하는데 있다.

10.2 공정 구조: 2차원

RUP의 전반적인 구조는 다음과 같이 2차원으로 기술될 수 있다.

<그림 10.1: Rational Unified Process 구조>

수평축은 시간에 따른 변화, 동적인 생명주기 측면을 나타낸다. 시간의 흐름에 따라 단계(phase)로 나누고 단계별 이정표(milestone)를 제시한다.

수직축은 핵심적인 작업흐름(workflow)을 보여주며 이는 활동(activity)을 논리적으로 집단화시킨 것이다. 이것은 정적인 측면에서 공정 구성요소, 활동, 작업흐름, 산출물(artifact), 작업자(worker)들로 표현한다.



10.3 RUP의 간략한 역사

RUP 는 수년간의 축적된 경험에 의해 성숙되었다. 그 가계도를 그려보면 다음과 같이 간단하게 표현할 수 있다.

<그림 10.2: Rational Unified Process의 역사>

RUP는 Rational Objectory Process를 계승하면서 자료공학, 업무 모델링, 프로젝트 관리, 구성관리를 포함시킨 것이다.

Rational Objectory Process는 Rational사와 Objectory사가 합병하면서 각사가 보유하고 있던 Rational Approach 와 Objectory Process 를 통합하여 생겨난 것이다. Rational Objectory Process는 당시 작성되고 있던 UML 0.8을 최초 사용한 것이다.

Objectory Process는 1987년에 스웨덴에서 Ivar Jacobson에 의해서 생겨났다. 이 프로세스는 사용사례와 객체지향 설계에 주안점을 두고 있었으며 그 요약판이 1992년에 <Object-Oriented Software Engineering-A Use Case-Driven Approach>라는 책으로 출판되었다.

Rational ObjectoryProcess 4.1

Rational UnifiedProcess 5.0

Rational ObjectoryProcess 4.0

Rational Approach

ObjectoryProcess 3.8

1995

1996

1997

1998

OMTBooch

UML 0.8

Performance TestingBusiness Reengineering

Configuration and ChangeManagement

Objectory UI DesignData Engineering

UML 1.2

Requirements CollegeSQA Process

UML 1.0



11. 정적 구조: 공정 기술 11.1 RUP 모델

공정(process)은 누가 무엇을 언제, 어떻게 하는 것인지를 기술한다. RUP의 주요 모델링 요소는 다음 네 가지이다.

작업자(worker): 누가

활동(activity): 어떻게

산출물(artifacts): 무엇을

작업흐름(workflow): 언제

이 요소들을 예로 들어 표시하면 다음 그림과 같다.

<그림 11.1 : 작업자, 활동, 산출물간의 관계를 표현한 사례>

[작업자]란 개인 또는 여러 팀원들이 팀내에서 갖는 행위방식과 책임을 의미한다. 그 행위방식은 작업자가 수행하는 [활동]으로 표현되며 한 작업자는 여러 개의 응집된 활동과 연관되어 있다. “응집되어 있다”는 것은 한 사람이 수행할 때에 가장 잘 수행될 수 있는 활동임을 의미한다. 작업자의 책임은 그 작업자가 작성하는 [산출물]과의 관계로 표현된다.

11.2 작업흐름

작업흐름(workflow)은 가시적으로 가치있는 결과를 생산하는 순차적인 작업활동(activity)을 의미한다. 작업흐름은 UML 의 순차 다이어그램, 협동 다이어그램, 활동 다이어그램으로 표현할 수 있으며 RUP는 활동 다이어그램을 사용하여 표현한다.

Designer Use Case Analysis

Use Case Design

Use CaseRealization

Worker

Activities

Artifacts responsible for



RUP 는 작업자와 활동을 논리적으로 집단화시켜 9 개의 핵심 작업흐름(core workflow)으로 나눈다. 9개의 핵심 작업흐름은 6개의 핵심 엔지니어링 작업흐름과

3개의 핵심 지원 작업흐름으로 구분한다. 6개의 핵심 엔지니어링 작업흐름은 다음과 같다.

1. 업무 모델링 작업흐름 Business modeling workflow 2. 요구사항 작업흐름 Requirements workflow 3. 분석과 설계 작업흐름 Analysis and design workflow 4. 구현 작업흐름 Implementation workflow 5. 시험 작업흐름 Test workflow 6. 배치 작업흐름 Deployment workflow

3개의 핵심 지원 작업흐름은 다음과 같다.

1. 프로젝트 관리 작업흐름 Project management workflow 2. 구성 및 변경관리 작업흐름 Configuration and change menagement workflow 3. 환경 작업흐름 Environment workflow

프로젝트 전체 작업흐름은 위 9 개의 핵심 작업흐름을 번갈아 반복하며 각 반복(iteration)에서 강조점을 달리하게 된다.



12. 동적 구조: 반복 개발 동적 구조란 RUP 의 생명주기에 따른 구조, 즉 공정(process)의 시간에 따른 진행을 의미한다.

12.1 반복 개발 공정에서의 단계와 이정표 프로젝트 관리의 관점에서 보면 프로젝트의 중간에 그 진척 정도를 파악할 수 있어야 하며, 또한 현재까지의 결과에 대해서 방향성을 검증할 수 있는 이정표가 있어야 한다.

반복 공정은 단계로 구성되며 그림 11-1 에서 보는 바와 같이 각 단계는 요구분석, 설계, 구현, 시험 작업흐름들과 수직으로 엮어 있다. 각 단계는 이정표로 검증함으로써 끝난다.

각 단계별로 활동 사항, 이정표 등을 정리하면 다음과 같다.

단계 설명 활동 사항 이정표

인식

inception

시스템의 최종 목표(vision)와 업무 사례 규정. 프로젝트의 범위정의.

요구사항에 대한 전반적인 이해. 개발 범위 규정.

생명주기 목표

life-cycle objective (LCO)

구체

elaboration

활동과 자원에 대한 구체적인 계획 수립. 아키텍처 설계 및 구현.

요구사항 명세화. 기술적 위험요소 제거. 실행가능한 아키텍처 프로토타입 구현.

생명주기 아키텍

처 life-cycle

architecture (LCA)

구축

construction

목표에 따른 시스템 구축. 사용자 인도 준비.

설계와 구현. 초기 운영 능력

initial operational capability (IOC)

인도

transition

사용자에게 인도. 제품의 제조, 배달, 교육, 지원, 유지보수.

시스템의 목표 충족도 확인. 오류 수정, 교육, 기능 수정 및 추가.

제품 발표 product

release

위 네 단계를 합하여 개발 주기(development cycle)라고 하며 이 주기를 통하여 소프트웨어의 세대(generation)를 생겨난다.

초기 개발 주기와 진화 주기 소프트웨어 제품이 생성되는 주기를 초기 개발 주기라고 한다. 제품을 지속적으로 업그레이드할 경우 다시 새로운 주기를 거쳐 다음 세대로 진화하며 이 주기를 진화 주기(evolution cycle)라고 한다.



초기 개발 주기에 있어서 전형적인 시간 배분은 인식 단계 10%, 구체 단계 30%, 구축 단계 50%, 인도 단계 10% 정도로 한다.

12.2 단계별 상세 내역 12.2.1 인식 단계

(1) 목표 제품의 운영 개념, 인수 조건 등을 포함한 프로젝트의 범위 설정

시스템의 사용사례 식별

전체 프로젝트에 대한 비용과 일정 견적. 구체 단계에 대한 상세한 견적

잠재적인 위험 요소 식별

(2) 활동 프로젝트의 범위를 공식화한다. 배경과 요구사항, 제한 조건 등을 파악하고 최종 제품에 대한 인수 조건을 끌어낸다.

업무 사례를 식별하고 비용과 일정, 수익성 등을 평가한다.

시스템의 아키텍처로 사용할 후보들을 식별하고 비용과 일정, 자원에 견주어 개발/구매/재사용 등의 정책을 결정한다.

(3) 산출물 비전 문서(vision document). 시스템의 핵심적인 요구사항, 주요 특징, 제한 조건 등에 대한 일반적인 비전.

초기 사용사례 모델. 초기에 식별한 모든 사용사례와 액터들의 목록.

초기 용어집

업무 사례

업무 배경 성공 조건 (수익성, 시장성 등) 재정 상황 예측

초기 위험 평가서

프로젝트 계획. 단계와 반복 규정.

(4) 이정표 인식 단계의 마지막으로 생명 주기 목표를 점검한다. 평가 기준은 다음과 같다.

프로젝트 범위와 비용, 일정 등에 대한 의견 일치

초기 사용사례 모델에 나타난 요구사항에 대한 이해도

비용과 일정, 우선 순위, 위험 요소, 개발 공정에 대한 신빙성

프로토타입의 깊이와 범위



예상 지출과 실제 지출

만일 프로젝트가 이 평가에 합격하지 못하면 취소하거나 재고려할 수 있다.

12.2.2 구체 단계

(1) 목표 아키텍처의 정의, 검증, 기준선(baseline) 설정

구축 단계의 상세 계획 설정

기준선으로 설정된 아키텍처가 적절한 비용과 일정으로 시스템의 목표를 달성할 수 있는지 확인

(2) 활동 개발환경을 구축하고 공정, 개발 도구, 자동화 도구 등을 적절히 사용한다.

아키텍처를 정교화한다. 컴포넌트를 선택하여 주요 시나리오에 대하여 통합시키고 평가한다. 평가는 아키텍처의 재설계로 이어질 수 있다.

컴포넌트에 대한 개발/구매/재사용을 결정한다.

(3) 산출물 사용사례 모델. 모든 사용사례와 액터의 목록과 사용사례 설명.

보조 요구사항. 비기능적 요구사항이나 사용사례와 연관되어 있지 않은 요구사항들의 목록.

소프트웨어 아키텍처 기술서

실행가능한 아키텍처 프로토타입

개정된 위험 목록과 업무 사례

상세 개발 계획. 각 반복에서의 평가 기준 등을 포함.

사용설명서 (선택적)

(4) 이정표 구체 단계의 마지막으로 생명 주기 아키텍처를 점검한다. 평가 기준은 다음과 같다.

제품의 비전은 안정적인가?

아키텍처는 비전을 성취할 수 있는가? 또한 안정적인가?

중요한 기술적 위험 요소들이 해결되었는가?

구축 단계의 계획이 충분히 상세하고 정확한가?

예상 지출과 실제 지출이 적절한가?

만일 프로젝트가 이 평가에 합격하지 못하면 파기하거나 재고려할 수 있다.



12.2.3 구축 단계 (1) 목표

자원의 최적화와 불필요한 재작업을 줄임으로써 개발 비용 최소화

적절한 품질 획득

시험판 획득

(2) 활동 자원을 관리하고 공정을 최적화한다.

컴포넌트 개발을 완료하고 평가 기준에 따라 시험한다.

시험판(알파판, 베타판 등)을 발표하고 검수 기준에 따라 평가한다.

(3) 산출물 적합한 플랫폼에 통합된 소프트웨어 제품

사용설명서

제품 발표 설명서 (release description)

(4) 이정표 구축 단계의 마지막으로 초기 운영 능력을 점검한다. 평가 기준은 다음과 같다.

제품이 사용자에게 인도할 수 있을 만큼 안정적이고 기능이 모두 구현되었는가?


만일 프로젝트가 이 평가에 합격하지 못하면 다음 시험판 발표 때까지 인도 단계를 연기할 수 있다.

12.2.4 인도 단계

(1) 목표 사용자 검수를 거친 최종 제품 획득

(2) 활동 제품을 포장하고 배포한다.

오류를 수정하고 성능과 활용성을 보강한다.

(3) 산출물 소프트웨어 제품

(4) 이정표 인도 단계의 마지막으로 제품을 점검한다. 평가 기준은 다음과 같다.

사용자가 만족하였는가?




프로젝트에 따라 새 개발 주기를 시작할 수 있다.



13. 업무모델링 작업흐름 우리가 구축하는 소프트웨어가 유용한 도구가 되기 위해서는 업무영역에 대한 이해가 선행되어야 한다. 그것은 업무가 복잡한 시스템일수록 더욱 그러하다. 업무모델링은 업무영역에 대한 이해를 위해 조직의 업무를 묘사하는 것이다.

13.1 목적 조직의 구조와 업무절차를 이해한다.

고객, 사용자, 개발자가 조직에 대한 공통된 이해를 공유하게 한다.

조직 지원에 필요한 시스템 요구사항을 추출한다.

13.2 작업흐름

<그림 13.1 업무모델링 작업흐름>

13.3 산출물 업무 사용사례 모델: 업무 기능들의 모델. 조직에서 사용되는 역할과 생산물들을 식별하는데 사용된다.

업무 객체 모델: 업무 사용사례가 실현되는 절차를 기술하는 문서.

보충 업무 명세: 위 두 개의 모델에 포함되어 있지 않은 업무상 필요한 정의들 제시.

용어집: 업무에 사용되는 중요한 용어들의 정의.

13.4 업무모델에서 시스템으로 전이 업무작업자(business worker)는 시스템의 액터(actor)가 될 가능성이 있다.

업무작업자의 행위는 시스템의 사용사례를 찾는데 도움이 될 수 있다.

업무엔티티는 시스템이 유지해야 하는 물건을 의미하므로 시스템의 엔티티 클래스를 찾는데 도움이 될 수 있다.



14. 요구사항 작업흐름 요구사항이란 시스템이 갖춰야 할 조건이나 수행능력을 의미한다. 요구사항은 사용사례로 표현된다. 사용사례 모델은 시스템의 행위를 표현하는 모델로서 시스템과 상호작용하는 액터와 시스템이 액터에 의해 사용되는 방법을 정의하는 사용사례로 구성된다.

14.1 목적 시스템이 수행해야 할 기능에 대해 고객 및 사용자와 합의한다.

시스템의 기능을 정의한다.

개발자가 시스템의 요구사항을 명확히 이해한다.

반복 계획을 세울 수 있는 기술적 근거를 제공한다.

시스템을 개발하기 위한 비용과 시간을 견적할 수 있는 근거를 제공한다.

시스템의 사용자 인터페이스를 정의한다.

14.2 작업흐름

<그림 14.1 요구사항 작업흐름>

14.3 산출물 비전 문서

사용사례 모델: 액터, 사용사례, 사용사례 패키지로 표현



보충 명세서 (사용사례 형태에 들어맞지 않는 상세 요구사항까지 포함)

사용자 인터페이스를 정의하는 산출물로 다음과 같은 것이 있다.

사용사례 스토리보드

사용자 인터페이스 프로토타입



15. 분석 설계 작업흐름 분석 설계는 요구사항을 구현할 수 있도록 다리를 놓아주는 역할을 의미한다. 사용사례를 분석하여 객체를 식별하고 이를 통해서 클래스와 부시스템, 패키지를 정의한다. 이를 위해 해야 할 일은 아키텍처 설계, 상세 설계, 데이터베이스 설계로 구분된다.

설계 모델은 세 개의 아키텍처 뷰로 표현될 수 있다. 논리 뷰는 클래스, 부시스템, 패키지 등의 논리 요소들의 집합으로 표현된다. 프로세스 뷰는 위의 요소들을 시스템의 프로세스와 쓰레드에 대응시킨다. 배치 뷰는 프로세스를 실행환경의 노드로 대응시킨다.

15.1 목적 분석 설계 작업흐름의 목적은 요구사항을 구현방식을 기술하는 명세서로 번역하는 것이다. 이 번역을 위해 요구사항을 이해하고 가장 좋은 구현 전략을 선택하여 시스템 설계로 변환한다. 프로젝트 초기에 강건한 아키텍처를 확립하여 시스템의 설계가 이해하고 구축하고 전개하기 쉽게 한다. 그 다음으로는 구현 환경을 고려하여 성능, 강건함, 확장성, 시험성 등이 확보되도록 설계를 조정한다.

15.2 작업흐름

<그림 15.1 분석 설계 작업흐름>



15.3 산출물 설계 모델: 클래스와 패키지, 부시스템으로 표현. 관계형 데이터베이스를 사용할 경우 데이터 모델을 포함.

소프트웨어 아키텍처 문서



16. 구현 작업흐름 16.1 목적

하위시스템들의 구조에 맞추어 코드의 조직을 정의한다.

소스 파일, 바이너리, 실행 파일 등의 컴포넌트들로 클래스를 구현한다.

개발된 컴포넌트들을 단위별로 시험한다.

개별 구현자 또는 팀이 생산한 결과물을 실행가능한 시스템으로 통합한다.

구현 작업흐름의 범위는 개별 컴포넌트들의 단위 시험으로 제한된다. 시스템 시험과 통합 시험은 시험 작업흐름의 영역이다.

16.2 작업흐름

<그림 16.1 구현 작업흐름>

16.3 산출물 구현 부시스템: 실행가능한 컴포넌트

컴포넌트: 소프트웨어 코드(소스, 바이너리, 실행 파일)와 목록

통합 빌드 계획서: 컴포넌트와 부시스템을 구현하고 통합하는 순서를 정의하는 문서



17. 시험 작업흐름 시험은 제품의 품질을 높이기 위한 작업이다. 품질은 제품의 생산이 합의된 공정에 의해 이루어지며, 합의된 측정 기준으로 평가하여 합의된 요구사항을 만족 또는 능가하였음을 보여주는 특성이다.

그러므로 품질이란 고객의 요구와 기대를 만족시키는 것 뿐만이 아니다. 품질의 획득을 증명하기 위한 측정 기준의 식별과 제품이 바람직한 품질 등급을 획득하게 하는 공정의 구현을 포함한다.

품질은 모두의 책임이다.

17.1 목적 객체와 컴포넌트의 상호작용을 검증한다.

모든 컴포넌트의 적절한 통합을 검증한다.

모든 요구사항이 정확하게 구현되었음을 검증한다.

소프트웨어가 배치되기 전에 오류를 발견하고 발견된 오류가 모두 정정되었음을 확인한다.

17.2 작업흐름

<그림 17.1 시험 작업흐름>



17.3 산출물 시험 계획서

시험 모델: 시험 사례, 시험 절차, 시험 스크립트로 구성

시험 사례: 시험 사례는 사용 사례와 설계 문서 등에서 추출한다. 시험 자료와 실행 조건, 기대 결과 등을 포함한다.

시험 절차: 시험의 설정, 실행, 평가를 위한 상세 지시 시험 스크립트: 시험 자동화 도구를 사용할 때 시험 절차의 실행을 자동화하는 지시

시험 결과 보고서: 부적합 사항들을 포함



부록 A.1 용어의 번역

RUP 용어 번역어 설명

activity 활동 산출물을 생성하는 행위. process >>

activity >> task

actor 액터, 행위자

architecture 아키텍처 cf. structure

association 연관

collaboration diagram 협동 다이어그램, 협조 다이어그램

construction 구축

cycle 주기

deployment 배치

elaboration 구체, 정교, 발전

implementation 구현

inception 인식

life-cycle 생명주기

lifeline 생존선

milestone 이정표

multiplicity 멀티플리시티 다수성, 카디낼리티

phase 단계

process 공정 (참고로 절차는 procedure)

process >> activity >> task

sequence diagram 순차 다이어그램

structure 구조 cf. architecture

subsystem 부시스템 하위시스템, 하부시스템, 서브시스템

task 작업 process >> activity >> task

전이 ‘상태전이’에 쓰임 transition

인도 사용자에게 인도

worker 작업자

workflow 작업흐름



A.2 참고도서 Martin Fowler, <UML Distilled: Applying the Standard Object Modeling Language>, ISBN 0-201-32563-2,

Addison Wesley Longman, 1998. Philippe Kruchten, <The Rational Unified Process, An Introduction>, ISBN 0-201-60459-0, Addison Wesley

Longman, 1998. Terry Quatrani, <Visual Modeling with Rational Rose and UML>, ISBN 0-201-31016-3, Addison Wesley Longman,

1998. Rational et al, <UML Proposal to the Object Management Group>, version 1.1, 1997.

Documents

최신의 UML 과 RUP · 2015-01-22 · 최신의 객체지향 방법론uml 과 rup (v 0.2) 쌍용정보통신 황남주 page : 6/46 를 엮으면서 이 문서는