t t a s t a n d a r d - committee.tta.or.kr...[그림 1] 객체지향 소프트웨어 개발...

T T

A S

t a n

d a

r d

정보통신단체표준 제정일: 1999 년 12 월 8 일

TTAS.KO-11.0015/R1 개정일: 2006 년 월 일

객체지향 소프트웨어 분석/설계 지침

(Guidelines for Object-oriented Software Analysis

and Design)

정보통신단체표준 제정일 : 1999 년 12 월 8 일

TTAS.KO-11.0015/R1 개정일 : 2006 년 월 일

객체지향 소프트웨어 분석/설계 지침

Guidelines for Object-oriented Software

Analysis and Design

본 문서에 대한 저작권은 TTA 에 있으며, 이 문서의 전체 또는 일부에 대하여 상업적 이익을

목적으로 하는 무단 복제 및 배포를 금합니다.

Copyrightⓒ Telecommunications Technology Associations(2005). All Rights Reserved.

정보통신단체표준

i TTAS.KO.11.0015/R1

서 문

1. 표준의 목적

본 표준은 객체지향 패러다임을 사용한 소프트웨어 개발 프로세스 내에서 체계적인

분석/설계 활동을 수행할 수 있도록 구체적인 절차, 산출물 등을 정의하여 제시함을

목적으로 한다.

2. 주요 내용 요약

본 표준은 객체지향 소프트웨어 개발 프로세스에서의 분석 설계 활동 및 분석 설계 활동에

대한 지침을 제시한다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 표준은 소프트웨어 개발 전 분야에 걸쳐 적용 할 수 있다. 객체지향 분석 설계를 통하여

보다 효율적이며 유지보수가 용이한 소프트웨어를 개발 할 수 있다.

4. 참조 표준(권고)

4.1 국외표준(권고)

없음

4.2 국내표준

없음

5. 참조표준(권고)과의 비교

5.1 참조표준(권고)과의 관련성

5.2 참조한 표준(권고)과 본 표준의 비교표

6. 지적재산권 관련사항

2006 년 8 월 31 일까지 확인된 지적재산권 없음

7. 적합인증 관련사항


ii TTAS.KO.11.0015/R1

없음

7.1 적합인증 대상 여부

7.2 시험표준제정여부(해당 시험표준번호)

8. 표준의 이력

판 수 제 개정일 제 개정판 내역

제1판 1999년 12월 8 일 제정

제2판 2006년 월 일 개정


iii TTAS.KO.11.0015/R1

Preface

1. The Purpose of Standard

This standard offers guidance on the procedures and products to perform analyzing

and designing activities using object-oriented paradigm. Project managers and

programmers can improve effectiveness and efficiency of object-oriented software

analysis and design by using the standard.

2. The summary of contents

This standard shows Analysis & Design Activities in OO Software Development Process

and guidelines for Analysis and Design Activities.

3. Applicable fields of industry and its effect

This standard plays a vital role in any software development. With object oriented

analysis and design , software is much more effective and easier to maintain.

4. Reference Standards (Recommendations)

None

4.1 International Standards (Recommendations)

None

4.2 Domestic Standards

None

5. Relationship to Reference Standards(Recommendations)

None

5.1 The relationship of Reference Standards

5.2 Differences between Reference Standard(recommendation) and this standard

6. The Statement of Intellectual Property Rights

None


iv TTAS.KO.11.0015/R1

7. The Statement of Conformance Testing and Certification

None

8. The History of Standard

Edition Issued date Contents

The 1st edition 1999. 12. 8. Established

The 2nd edition 2006. . . Revisied


v TTAS.KO.11.0015/R1

목 차

1. 개요 ···················································································· 1

2. 용어정의 ··············································································· 1

3. 객체지향 소프트웨어 개발 프로세스 내의 분석/설계 활동 ······················ 2

4. 분석 및 설계 활동 지침 ······························································ 2

4.1 개발 범위 정의 ···································································· 2

4.1.1 사용자 요구 수집 ·························································· 4

4.1.2 업무 분석 및 재설계 ······················································ 5

4.1.3 개발 시스템 정의 ························································· 6

4.1.4 프로젝트 타당성 분석 ······················································ 8

4.2 요구사항 분석 ··································································· 9

4.2.1 현행 시스템 분석 ·························································· 10

4.2.2 사용자 요구 정제 ························································· 12

4.2.3 분석 모형 작성 ··························································· 14

4.2.4 초기 아키텍처 정의 ······················································ . 16

4.2.5 사용자지침서 초안 작성 ················································ 20

4.3 아키텍처 정립 ···································································· 21

4.3.1 아키텍처 정의 ···························································· 22

4.3.2 아키텍처 검토 ····························································· 24

4.4 요구사항 정제 및 설계 ························································ 25

4.4.1 사용사례 정제 ···························································· 27

4.4.2 설계 클래스 추가 ························································· 28

4.4.3 클래스 정제 ······························································ 31

4.4.4 데이터베이스 설계(RDB) ················································ 33

4.4.4-1 데이터베이스 설계(OODB) ········································ 36

4.4.5 사용자 인터페이스 설계 ················································· 38

4.4.6 아키텍처 정제 ··························································· 39

부록 : UML 용어 한글 표기 ·························································· 43


vi TTAS.KO.11.0015/R1

CONTENTS

1.Overview ··············································································· 1

2.Definitions ············································································1

3. Analysis & Design Activities in OO Software Development Process ······ 2

4. Guidelines for Analysis and Design Activities ································· 2

4.1 Defining the Development Scope ··········································· 2

4.1.1 Gathering User Requirements ············································ 4

4.1.2 Business Process Analysis and Re-engineering ····················· 5

4.1.3 Defining the Development System ······································ 6

4.1.4 Feasibility Study for the Project ········································· 8

4.2 Requirement Analysis ·························································· 9

4.2.1 Analizing Legacy System ················································· 10

4.2.2 Refining User Requirements ············································ 12

4.2.3 Creating Analsis Models ·················································· 14

4.2.4 Defining Initial Architectures of the System ··························· 16

4.2.5 Writing Draft of the Users Manual ····································· 20

4.3 Establishing Architectures of the System ································· 21

4.3.1 Defining Architectures ··················································· 22

4.3.2 Reviewing Architectures ················································· 24

4.4 Refining Requirements and Designing ····································· 25

4.4.1 Refining Use Cases ······················································ 27

4.4.2 Adding Design Classes ·················································· 28

4.4.3 Refining Extracted Classes ············································· 31

4.4.4 Designing Database for the RDBMS ·································· 33

4.4.4-1 Designing Database for the OODBMS ····························· 36

4.4.5 Designing User Interfaces ·············································· 38

4.4.6 Refining Architectures ··················································· 39

Appendix : UML Terms and Definitions ··········································· 43


1 TTAS.KO.11.0015/R1

객체지향 소프트웨어 분석/설계 지침 Guidelines for Object-oriented Software

Analysis and Design

1. 개요

오늘날 정보기술의 주요한 방향중의 하나는 객체지향 기술의 표준화와 보급이다.

객체지향 기술은 복잡하고 분산된 시스템을 개발하고 관리하기 위한 기본적인 패러다임으로

인식되고 있다. 객체지향 언어, 분산 객체 기술, 객체지향 데이터베이스의 발전과 급속한

보급이 객체지향에 기반한 정보시스템의 개발을 가속화하고 있다.

본 표준은 객체지향 패러다임을 사용하는 소프트웨어 개발 프로젝트의 분석 및 설계

활동을 수행할 수 있도록 구체적인 절차, 산출물 등을 정의하여 제시하고 있다. 객체지향

소프트웨어의 분석 및 설계 활동을 지원하는 객체지향 문서화 방법으로 OMG(Object

Management Group) 객체지향 표기법 표준인 UML 의 표기법 및 다이어그램을 채택하였다.

그러므로 본 표준의 사용자는 객체지향 소프트웨어 개발 프로젝트를 위한 분석 및 설계를

계획하거나 수행하는 사람을 대상으로 한다.

이 표준의 채택을 고려하고자 하는 조직은 이 표준이 “ 객체지향 소프트웨어 개발

프로세스 지침” 에서 제시한 개발 프로세스와 연관이 있으며 이 중 분석 및 설계활동의 세부

작업들에 대한 절차 수행에 적용되고 있음을 인식하여야 한다.(개발 프로세스의 단계 및

활동 등은 “ 객체지향 소프트웨어 개발 프로세스 지침” 참조)

2. 용어 정의

UML 용어의 한글 표기는 별도로 부록으로 기술한다.

기법(Technique)

전문적인 절차와 개념, 기술을 사용하여 작업을 완수할 수 있는 수행 방법

단계(Phase)

프로젝트의 계속적인 진행을 위한 의사결정 시점으로, 한 단계가 종료되면 다음 단계의

진행을 위한 승인을 받아야 한다. 개발 단계는 병행해서 수행될 수 없으며, 하나 이상의

활동으로 구성된다.

미니 프로젝트(Mini-project)

활동들의 집합으로 제한된 시간 내에 사용자가 사용 가능한 형태의 시스템을 생성하는

단위이다. 시간적으로 소규모 팀 기준으로 2주에서 2달 정도의 기간에 수행하는

활동으로 하나 혹은 다수의 사용사례를 개발 대상으로 한다.


2 TTAS.KO.11.0015/R1

산출물(Product)

모형, 코드, 문서, 작업 계획과 같은 개발 작업의 수행 결과로 생성되는 문서나 제품을

의미한다. 산출물은 고객(사용자)에게 제시할 것을 전제로 하여 작성되는 것과 프로젝트

내부에서만 이용할 목적으로 작성되는 것으로 분류할 수 있다.

작업(Task)

한 사람(또는 한 팀)이 단일 목표를 성취하기 위한 일의 단위로써, 반드시 신규로

작성되거나 갱신되는 산출물을 제공하여야 한다.

활동(Activity)

단계 수행 시 중간 점검의 의미를 지닌 단위이며, 논리적으로 연관이 있는 작업들의

집합이다.

3. 객체지향 소프트웨어 개발 프로세스 내의 분석/설계 활동

객체지향 소프트웨어 개발 프로세스는 [그림 1]에서 보는 바와 같이 크게 4가지 단계로

구분할 수 있으며, 각 단계를 수행하기 위한 활동들로 세분화된다. 그림에서 활동은 단계

내부에 도식화되어 있는 사각형으로 표시되어 있다. 이 중 본 표준에서는 분석 및 설계

활동이 가장 활발하게 일어나는 개발범위 정의 활동, 요구사항 분석 활동, 아키텍처 정립

활동 및 요구사항정제 및 설계 활동을 중심으로 이들 활동의 목적, 활동 수행을 위한 세부

작업 및 절차, 입력물 및 출력물 등을 기술한다.

계획단계 정립단계 점진적 개발 단계 인도단계

계획단계 준비

개발범위 정의

프로젝트계획 수립

계획단계 점검

정립단계 준비

요구사항 분석

위험 분석

시제품 개발계획수립

시제품 개발미니프로젝트

아키텍처 정립

개발 계획 수립

정립단계 점검

미니프로젝트준비

요구사항 정제 및 설계

클래스 구현 및시험

지침서 및교재개발

통합 시험

시스템 시험

미니 프로젝트점검

인도단계 준비

시스템 설치

사용자 승인시험

사용자 교육

설치 후 관리

인도단계 점검

점진적 개발단계 점검 미니프로젝트

• 반복활동


3 TTAS.KO.11.0015/R1

[그림 1] 객체지향 소프트웨어 개발 프로세스 구성도

4. 분석 및 설계 활동 지침

4.1 개발 범위 정의

개발될 시스템의 비전, 목표를 정의한다. 새로운 시스템을 사용할 사용자의 범위, 관련

업무의 범위를 결정하고 관련된 자료들을 수집한다. 사용자의 요구사항과 관련 업무를

파악한다. 개발할 시스템의 기능적, 비기능적 요구사항을 정의한다. 개발할 시스템의 개발

범위 및 기능을 사용사례 모형을 중심으로 정의하고, 새로운 시스템 구축에 따르는 개발

비용 및 효과를 분석하여 타당성을 검토한다.

작업 구조

개발 범위 정의 활동은 모두 4 개의 작업과 15 개의 절차로 이루어져 있으며 세부 사항은

다음과 같다.

① 사용자 요구 수집

개발에 관련된 사용자의 요구사항을 조사하기 위하여 면담 및 설문 등의 작업을

수행하고 기처 자료를 수집한다.

사용자 규명

사용자 면담/설문 및 기초 자료 수집

현행 시스템 구조 추출

② 업무 분석 및 재설계

개발될 시스템의 사용자 업무 가운데 프로세스 개선이 필요한 업무를 분석하여 개선

아이디어를 정리하고, 해당 업무의 프로세스를 재설계한다..

업무 분석 대상 프로세스 선정

현행 업무 프로세스 분석

업무 프로세스 재설계

사용자와 재설계 프로세스 검토

③ 개발 시스템 정의

새로운 시스템의 개발 범위 및 기능을 사용 사례 모형을 중심으로 정의하고, 새로운

시스템의 운영환경을 정의한다.

시스템 목표 및 범위 설정

기능적 요구사항 정의

비기능적 요구사항 정의

시스템 운영 환경 정의

④ 프로젝트 타당성 분석

개발 시스템의 구축에 따르는 소요 비용 및 효과를 검토하고 프로젝트의 타당성을

검토한다.

소요비용 산정

개선효과 추출


4 TTAS.KO.11.0015/R1

상품성 분석

타당성 검토

업무 분석 및 재설계

개발 시스템 정의

프로젝트 타당성 분석

4.1.1 사용자 요구 수집

개요

시스템의 사용자를 파악하고, 관련 자료들을 수집하여 분석하는 작업이다.

시스템의 사용자를 파악하여 사용자 목록을 작성한다. 사용자별 요구 사항을 수집하기

위한 방안(설문 또는 면담, 관찰)을 결정하여 요구 사항 수집 활동을 수행한다. 이와

함께 시스템 개발에 관련된 문서, 양식, 규정 등의 관련 자료들을 수집하여 정리한다.

현재 사용하고 있는 시스템이 존재하는 경우, 현행 시스템의 분석 작업을 수행한다.

현행 시스템의 분석작업은 기존의 현행 시스템에 대한 문서들을 중심으로 수행한다.

절차 설명

① 사용자 규명

개발될 시스템의 사용자를 찾아내어 나열한다. 사용자 규명은 시스템 사용대상자의

범위를 결정한다.

개발될 시스템의 사용자를 유형별로 정리한다.

사용자정의서를 작성한다.

② 사용자 면담/설문 및 기초 자료 수집

사용자 요구사항을 수집하기 위한 방안을 결정한다. 면담 또는 설문의 계획을 세워

수행하고 결과를 분석한다. 이와 함께, 개발될 시스템과 관련된 양식, 보고서, 규정,

업무 매뉴얼 등을 수집하여 정리한다.

사용자 또는 사용자 그룹별로 요구 사항을 분석하기 위한 방안을 결정한다.

주요한 사용자에 대하여는 직접적인 면담을 수행한다. 사용자 그룹에 포함되는

사용자가 많은 경우에는 설문 방식을 취한다.

면담을 수행하는 경우, 면담 수행자와 면담 대상자, 면담 일정 등을 결정한다.

면담 수행자에게는 면담의 일반적인 수행 요령과 면담의 목적 등을 인지시킨다.

면담 수행 결과는 사용자면담서에 서술식으로 정리한다.

설문 조사가 필요한 경우, 조사 방법론에 근거하여 설문을 계획하고 수행하며

결과를 분석한다.

기초 자료 수집은 시스템 개발과 관련된 정보 및 지식들을 수집하는 단계이다.

개발되는 시스템과 관련된 양식, 보고서, 컴퓨터 출력물, 업무 규정 등이

포함된다. 특정 분야에 대한 지식이 필요한 경우에는 해당 분야에 관한 자료들을

수집하여 정리한다.

③ 현행 시스템 구조 추출

현재 운영 중인 시스템이 존재하는 경우, 현행 시스템에 대한 분석 작업을 수행한다.


5 TTAS.KO.11.0015/R1

현행 시스템의 분석 작업은 기존의 시스템 문서들을 최대한 활용하여 수행한다.

현행 시스템의 기술환경, 즉 하드웨어, 소프트웨어, 네트워크 환경 등을 검토한다.

현행 시스템의 시스템 구성을 파악한다.

현행 시스템의 데이터베이스 설계를 비롯한 자료 구조를 정리한다.

현행 시스템의 기능들을 나열한다.

현행 시스템의 문제점 및 해결 방안을 작성한다.

입력물/산출물

입력물 산출물

계획단계 작업계획서

조직도(사용자)

경영전략 및 사업 방향

사업 성공 요소

현행 시스템 문서

기존 관련 자료(양식, 보고서,

업무 매뉴얼, 규정)

자료사전

사용자요구사항명세서

- 현행시스템분석서

- 사용자요구수집서

. 사용자정의서

. 사용자면담서

. 사용자설문서

. 사용자설문계획서

. 사용자설문분석서

. 사용자료정의서

4.1.2 업무 분석 및 재설계

개요

개발될 시스템의 사용자 업무 가운데 프로세스 개선이 필요한 업무를 분석하여 개선

아이디어를 정리하고, 해당 업무의 프로세스를 재설계한다.

절차 설명

① 업무분석 대상 프로세스 선정

조직에는 많은 업무 프로세스가 있다. 동시에 너무 많은 프로세스를 대상으로

분석하면 초점과 경영측의 관심이 흩어지므로 소수의 프로세스를 선택하여

착수한다. 본 작업에서 대상으로 하는 업무 프로세스는 개발하고자 하는 시스템과

관련된 업무 프로세스만으로 한정한다.

시스템 개발과 관련된 모든 업무 프로세스를 나열한다.

나열된 업무 프로세스에 대하여 다음과 같은 평가기준으로 업무분석 대상

프로세스를 선정한다.

- 전략적으로 중요한 프로세스를 선택한다.

- 고객에게 영향을 미치는 프로세스를 선택한다.

- 종업원들의 불만이 많은 프로세스를 선택한다.

- 개선하기 쉬운 프로세스를 선택한다.

- 가용자원의 확보가 쉬운 프로세스를 선택한다.


6 TTAS.KO.11.0015/R1

② 현행 업무 프로세스 분석

선정된 프로세스들의 현재 작업방식과 성취도를 측정한다. 경영혁신의 기초가 되는

현 상태는 왜곡없이 정확한 이해가 이루어져야 된다. 특히 작업방식의 파악을

기초로 프로세스의 각 단위 작업별로 입력물, 산출물, 문제점들의 파악이 필요하다.

예외사항의 해결방식, 고객의 피드백에 대한 처리과정도 분석되어야 한다. 활동도와

업무프로세스 기술을 중심으로 업무 프로세스에 대한 이해 및 분석 작업을 수행한다

사용자와 함께 현행 업무 프로세스에 대한 활동도를 작성한다.

업무 프로세스의 작업별 투입물, 산출물, 문제점을 파악한다.

업무 프로세스의 평가 척도를 파악한다.

③ 업무프로세스 재설계

업무 프로세스의 재설계가 필요한 경우, 업무 프로세스 개선안을 작성한다.

개선안에는 개선모형을 활동도 형태로 작성하고 개선효과 등은 (개선)업무프로세스

기술에 정리한다.

해당 업무 프로세스의 개선을 위해서 활용 가능한 정보기술을 검토한다.

고객 입장에서 새로운 프로세스 개발을 시도한다.

긴 직렬조직은 병렬작업과 업무 통폐합을 이용하여 프로세스를 재설계한다.

개선 업무프로세스의 개선 효과를 프로세스 평가 척도를 기준으로 예측한다.

개선 업무프로세스의 타당성을 검토한다.

④ 사용자와 재설계 프로세스 검토

재설계된 업무 프로세스를 사용자와 함께 검토하고 사용자의 의견을 들어 보완한다.

사용자의 의견을 반영하여 개선 업무 프로세스를 보완한다.

필요한 경우 업무 프로세스의 실제 구축에 앞서 초기실험을 수행한다.

입력물/산출물

입력물 산출물

조직도(사용자)

업무 분장표

사업 성공 요소

사용자요구수집서

현행시스템분석서

자료사전

사용자요구명세서

- 사용자업무정의서

자료사전

4.1.3 개발시스템 정의

개요

시스템의 기능적 요구사항과 비기능적 요구사항을 정리한다. 기능적 요구사항은

사용사례 모형을 중심으로 기술하고, 비기능적 요구사항(제약조건, 성능 요구사항 등)은

비정형화된 서술 형태로 기술한다. 또한 사용사례와 비기능적 요구사항을 고려하여

시스템의 운영환경도 기술한다.


7 TTAS.KO.11.0015/R1

절차 설명

① 시스템 목표 및 범위 설정

개발요청서, 프로젝트개요서(계획단계작업계획서의 일부), 사용자요구사항수집서,

현행시스템분석서, 사용자업무정의서 등을 참조하여 개발할 시스템의 목표와

범위를 구체화 한다. 다음과 같은 내용들을 정리한다.

개발 시스템의 목표를 기술한다.

개발 시스템의 특징과 범위에 대하여 기술한다.

개발 시스템의 개요를 비정형적으로 기술한다.

② 기능적 요구사항 정의

개발 시스템의 기능적 요구사항을 사용사례 모형을 중심으로 기술한다.

사용자요구사항수집서, 현행시스템분석서, 사용자업무정의서를 참조하여 다음과

같은 내용을 작성한다.

개발 시스템의 행위자를 나열한다. 행위자에는 사용자, 인터페이스할 하드웨어,

소프트웨어, 디바이스 등이 포함된다.

개발 시스템이 포함할 기능을 사용사례로 한다.

사용사례도를 통해서 사용사례와 행위자간의 관계, 사용사례간의 관계를

정의한다.

각 사용사례에 대한 설명을 기술한다.

③ 비기능적 요구사항 정의

개발 시스템의 비기능적 요구사항을 비정형적인 서술로 기술한다. 다음과 같은

내용을 포함한다.

개발 시스템이 만족시켜야 하는 제약 조건(기술적 제약조건, 기존 하드웨어,

소프트웨어와 관련된 제약조건, 인터페이스할 시스템과 관련된 제약조건, 운영

및 관리 상의 제약조건, 기업전략적 제약조건 등)을 기술한다.

개발 시스템이 반드시 만족시켜야 하는 주요 성능 척도(반응시간, 저장 능력,

동시처리 능력)를 기술한다.

신뢰성, 확장성, 이식성, 보안과 관련된 요구사항을 기술한다.

개발 시스템이 만족시켜야 하는 제약 조건을 기술한다.

④ 시스템의 운영 환경 정의

사용사례와 비기능적 요구사항을 고려하여 시스템이 운영될 하드웨어, 소프트웨어

선정 기준을 정하고 지역간 네트워크도 정하여 시스템을 구성하는 하드웨어,

소프트웨어, 네트워크의 사양과 연관관계를 기술한다.

현재의 하드웨어, 소프트웨어, 네트워크 현황을 파악한다.

현재의 하드웨어, 소프트웨어, 네트워크에 대한 감가상각 및 기술적 가능성을

파악한다.

즉각적, 장기적으로 이익을 제공하여 줄 수 있는 기술이 무엇인지 파악한다.

개발 시스템과 인터페이스를 하기위한 제약 조건과 개발될 시스템이 갖추어야 할

특성들을 정리한다.


8 TTAS.KO.11.0015/R1

입력물/산출물

입력물 산출물

사용자요구수집서

현행시스템분석서

사용자업무정의서

자료사전


- 요구정의서

자료사전

4.1.4 프로젝트 타당성 분석

개요

프로젝트에 소요되는 규모를 계산하고, 사용자에게 가져다 주는 가치와 개선 효과를

기술하고, 개발 시스템의 타당성을 검증하는 작업이다.

프로젝트 소요비용은 신규 시스템의 요구사항정의서에 기술된 시스템의 주요 기능,

기술환경을 가지고 계산한다. 비용 효과는 정량적, 정성적으로 작성하며 프로젝트가

조직과 작업 수행 방식에 미치는 영향을 조사한다.

개발할 시스템이 COTS(Commercial Off The Shelf) 제품인 경우는 상품성을 분석한다.

개발할 시스템의 유형적, 무형적 효과를 분석하고, 개발 및 운영에 소요되는 비용을

추정하여 비용 대비 효과를 추정하여 비교한다.

절차 설명

① 소요비용 산정

시스템의 요구정의서에 의하여 인건비를 계산하고, 개발 지원도구, 하드웨어,

네트워크, 시스템 소프트웨어에 의하여 장비료를, 기타 출장 등 제비용 등을 합하여

개발비를 산정한다.

개발 규모를 산출한다.

직접 인건비를 산정한다.

제경비를 산정한다.

② 개선 효과 추출

시스템이 개발 완료되었을 경우를 가상하여 사용자에게 가져다 주는 효과를 유형

효과와 무형 효과로 나누어 기술하며 이는 사용자업무정의서의 개선 내역을

참조하여 작성한다.

신규 시스템의 개발로 사용자가 얻을 수 있는 이익을 계수화 한다.

산업계 평균이나 유사한 사용자의 경험을 기초로 하여 이익의 규모를 제시한다.

정의된 이익과 관련된 가정을 기술한다.

이익과 가정을 검토하고 정한다.

③ 상품성 분석

개발 시스템이 COTS(Commercial Off The Shelf) 제품인 경우 개발 시스템에 대한

상품성을 분석한다.


9 TTAS.KO.11.0015/R1

개발할 목표 제품과 유사한 경쟁 제품을 분석한다.

경쟁 제품에 대한 기능 및 성능 분석을 통하여 기술적 우위성을 갖는 지

검토한다.

원가 계산 및 원가 절감 방안을 마련하여 가격 경쟁력을 갖는지 분석한다.

시장 규모 예측을 통하여 확보 가능한 시장 규모를 파악한다.

이상의 기술적 우위성과 가격 경쟁력 분석 및 시장 수요에 대하여 개발하려는

목표 제품이 충분한 상품성을 갖는지 평가한다.

④ 타당성 검토

프로젝트 팀원들이 하는 작업으로 신규 시스템 요구정의서, 프로젝트 비용 산정서와

경제성 평가서를 가지고 타당성 검토를 한다. 이에는 주로 기술 검토, 사용자 조직

수행 검토, 사용자의 가치 검토, 수익 검토를 한다.

기능별 개선 대안을 기록한다.

요구사항에 대한 적합성 검토를 한다.

기능에 대한 목표 및 조직 변화 요소를 기록한다.

개선 효과 비용을 기술한다.

상품성 분석 결과를 기술한다.

전체적인 총평을 한다.

입력물/산출물

입력물 산출물





- 요구정의서

유사 제품 및 경쟁 제품 자료

자료사전

프로젝트타당성분석서

- 프로젝트비용산정서

- 경제성평가서

- 상품성분석서

- 타당성검토서

4.2 요구사항 분석

계획단계의 사용자요구명세서를 바탕으로, 사용자 요구사항을 추가로 획득하여 정제하고

초기 분석 작업을 수행하는 활동이다. 사용사례를 중심으로 시스템의 기능적 요구사항을

보완하고 비기능적 요구사항도 보완하여 기술한다. 사용사례와 시나리오의 분석을 통해서

문제 영역 내에 존재하는 객체들을 규명하고 그들 간의 관계를 클래스도로 표현한다. 또한

분석 결과들을 바탕으로 초기 아키텍처를 정의한다. 현행 시스템이 있는 경우, 현행시스템을

분석하여 그 결과를 참조한다.

작업 구조

요구사항 분석 활동은 모두 5 개의 작업과 23 개의 절차로 이루어져 있으며 세부사항은


10 TTAS.KO.11.0015/R1

다음과 같다.

① 현행 시스템 분석

현행 시스템과 관련된 자료를 수집하여 정리하고 현행 시스템의 문제점을 분석하여

해결 방안을 모색한다.

현행시스템 기술환경 분석

현행 시스템 자료구조 분석

현행 시스템 기능 분석

문제점 분석 및 해결 방안 모색

② 사용자 요구 정제

사용자와의 면담, 설문, 워크샵 등을 통해서 사용자의 요구사항을 추출한다. 사용자

요구사항은 기능적 요구사항(functional requirements)와 비기능적 요구사항(non-

functional requirements)으로 나눌 수 있다.

기능적 요구사항의 정제는 시스템의 외부행위자와 시스템의 상호작용을 나타내는

사용사례를 식별함으로써 이루어진다.

비기능적 요구사항은 시스템의 성능, 보안, 응답시간, 처리량 등 기능 외적인 것을

말한다.

기능적 요구사항 보완

비기능적 요구사항 보완

시스템 기술 환경 보완

③ 분석 모형 작성

사용자 요구 정제 작업에서 얻어진 시스템의 기능적 요구사항에 대해 분석 작업을

수행한다. 시나리오를 바당으로 순서도 및 협력도를 작성하여 사용자 요구사항을

분석 정제하고 상위 수준의 클래스도를 작성한다.

사용사례 상세 기술

사용자 인터페이스 정의

객체 추출 및 객체 상호작용 분석

클래스 식별

클래스 속성 및 연산 정의

클래스 관계 정의

클래스도 작성 및 검토

④ 사용자 지침서 초안 작성

사용자 요구사항의 정제 및 분석 결과를 바탕으로 사용자지침서의 초안을 작성한다.

구성항목 정의

항목별 내용 작성

사용자지침서 검토

4.2.1 현행 시스템 분석

개요


11 TTAS.KO.11.0015/R1

본 작업에서는 계획단계에서 수집한 현행 전산 시스템에서 운영중인

응용시스템(프로그램, 데이터베이스, 시스템 기술 환경 등)의 자료를 검토하여 미비한

자료는 추가로 수집하여 분석한다. 개발자가 현행 전산 시스템을 정확히 파악함으로써

개발 업무를 개선하고 문제점을 해결하는 지침이 된다.

절차 설명

① 현행 시스템 기술환경 분석

계획단계의 현행 시스템 기술서와 기존 시스템 문서를 바탕으로 현행 시스템이

개발되고 운영되는 전산 시스템 환경을 조사한다. 현행 시스템의 구성요소를

파악하여 각 구성 요소에 대해 분석한다. 도출된 현행 시스템 기술환경 자료는 개발

시스템의 아키텍처정의를 위한 기초자료가 된다.

정보 시스템 부서에서 관리하는 모든 정보 시스템 자원을 파악한다.

시스템을 구성하는 하드웨어, 시스템 소프트웨어, 주변기기, 단말기 등을 파악

한다.

모뎀이나 통신망 등 현행 시스템을 구성하는 통신 장비를 파악한다.

현행 시스템 구성도를 작성한다.

시스템 구성 요소(하드웨어, 시스템 소프트웨어, 주변기기 등)를 통신망으로

연결된 시스템 구성도를 작성한다.

시스템 구성도에서 정의된 구성 요소를 정의한다.

구성 요소별 상세 내역을 정리하여 현행 시스템 기술환경을 기술한다.

② 현행 시스템 자료구조 분석

사용자와의 면담을 통해 현행 시스템에 관한 자료를 수집하여 자료구조를 분석한다.

현행 시스템 문서와 업무를 파악한다.

현행 시스템과 관련된 자료구조를 파악하여 현행 시스템 자료구조를 작성한다.

③ 현행 시스템 기능 분석

현행 시스템이 제공하는 기능을 분석하고 문서화한다. 기능에 대한 분석을 통해

현행 시스템과 현행 업무 절차를 파악한다.

현행 시스템 문서를 조사한다.

시스템의 기능을 식별한다.

식별된 기능을 분류하여 현행 시스템 기능을 기술한다.

④ 문제점 분석 및 해결 방안 모색

현행 시스템의 문제점을 분석하여 사용자의 현행 시스템에 대한 불만사항 및 개선

아이디어를 검토한다.

현행 시스템 문서를 조사한다.

계획 단계의 사용자업무정의서의 개선업무활동도를 검토한다.

사용자와 현행 시스템의 문제점 및 개선 방향을 정리하여 문제점 및 해결방안을

작성한다.

앞 절차의 작업들을 정리하여 현행시스템분석서를 작성한다.


12 TTAS.KO.11.0015/R1

입력물/산출물

입력물 산출물

자료사전

현행시스템 문서

현행시스템분석서(계획단계)

사용자업무정의서

현행시스템분석서(보완)

자료사전(보완)

4.2.2 사용자 요구 정제

개요

계획 단계의 개발범위 정의 활동에서 작성된 요구정의서를 검토하고 더 상세하게

사용자 요구사항을 정제한다. 이를 위해 현행시스템분석서를 검토하고 면담, 설문, 관찰

등의 기법을 활용한다. 시스템의 행위자로서, 사용자 뿐만 아니라 개발될 시스템이

직접적으로 상호작용을 해야 하는 하드웨어, 소프트웨어들에 대한 분석 및 제약사항

등도 검토한다.

사용자 요구사항은 두 가지로 나누어 분류할 수 있는데 기능적 요구사항은 본질적으로

대상 시스템이 수행하여야 하는 일(기능)이 무엇인가를 의미하는 것으로 사용사례의

식별을 통해 추출할 수 있고, 비기능적 요구사항은 시스템의 기능 외적인 요구사항으로

성능, 품질, 비용, 운영, 환경, 보안, 분산(지역) 등과 관련되어 있다.

절차 설명

① 기능적 요구사항 보완

시스템과 외부 행위자가 상호 작용하는 것을 나타내는 사용사례를 규명하고

정제한다. 개발범위 정의 활동의 산출물인 요구정의서를 검토하고, 면담이나 설문

등을 사용하여 사용자와 의사소통을 충분히 한다. 만약 현행 시스템이 있다면, 현행

시스템에 대한 분석 작업 결과를 검토하여 반영한다.

사용자를 분류한다.

개발 시스템을 직접 사용하는 그룹을 식별하는 것으로 계획단계에서 파악된

사용자 목록, 사용자 면담서, 사용자 설문 분석서 등을 검토하여 사용자 그룹을

식별한다.

인터페이스 하드웨어, 소프트웨어를 규명한다.

개발 시스템이 어떤 하드웨어로 구성될 것인지, 연관되는 소프트웨어는 어떤

것이 있는지 식별한다. 이때 면담을 통해 사용자와 충분히 의견을 교환하는 것이

바람직하다. 만약 현행 시스템이 있는 경우 계획단계 또는 본 단계의 선행 작업인

현행시스템 분석 작업의 현행시스템분석서를 참조한다.

행위자를 식별한다.

행위자란 시스템과 상호작용하면서 어떤 서비스를 받는 객체로 볼 수 있다.

식별된 사용자 그룹과 인터페이스 시스템을 검토하고, 계획단계에서 작성된

행위자 목록을 참조하여 행위자 목록을 작성한다.


13 TTAS.KO.11.0015/R1

행위자 목록을 검토한다.

사용자와 함께 식별된 행위자를 검토한다. 누락되거나 중복되는 행위자는 없는지

불명확한 행위자는 없는지 검토하여 행위자 목록을 보완한다.

사용사례를 식별한다.

사용사례의 식별은 각 행위자별로 식별한다. 계획단계에서 식별된 사용사례를

충분히 검토하고 추가적으로 사용사례를 식별한다. 너무 복잡한 사용사례는

분할하여 세분화 시키고 각 사용사례별로 행위자와 사용사례가 어떻게 상호

작용하는 지를 개략적으로 기술한다.

사용사례 간의 관계를 규명한다.

사용사례 간의 관계를 규명하여 사용사례도를 작성한다. 이때 여러 사용사례에서

공통으로 쓰일 수 있는 사용사례는 따로 분리하여 <<uses>>관계를 설정하고,

예외 상황에 대한 사용사례는 <<extends>>관계를 설정한다.

② 비기능적 요구사항 보완

계획 단계의 요구정의서를 검토하고, 면담이나 설문 등의 기법을 사용하여 사용자와

의사소통을 충분히 하여 시스템의 비기능적 요구사항을 정리한다.

계획단계의 요구정의서의 비기능적 요구사항을 검토한다.

시스템이나 네트워크 등의 성능(처리량, 응답시간)이나 보안 등에 대해

불명확하거나 추가적인 요구사항이 있으면 보완한다.

시스템의 신뢰성, 확장성, 이식성 등 추가적인 요구사항이 있으면 기술한다.

개발될 시스템이 만족시켜야 하는 제약 조건을 기술한다.

기술적 제약조건, 기존 하드웨어, 소프트웨어와 관련된 제약조건, 인터페이스를

해야 하는 시스템과 관련된 제약조건, 운영 및 관리 상의 제약조건, 기업전략적

제약조건 등을 기술한다.

③ 시스템 기술 환경 보완

사용사례와 비기능적 요구사항을 고려하여 시스템이 운영될 하드웨어, 소프트웨어

선정 기준을 정하고 지역간 네트워크도 정하여 하드웨어, 소프트웨어, 네트워크

등의 연관을 나타내는 시스템 구성도와 시스템 사양을 기술한다.

현재의 하드웨어, 소프트웨어, 네트워크 현황을 파악한다.

현재의 하드웨어, 소프트웨어, 네트워크에 대한 감가상각 및 기술적 가능성을

파악한다.

즉각적, 장기적으로 이익을 제공하여 줄 수 있는 기술이 무엇인지 파악한다.

개발 시스템과 인터페이스를 하기위한 제약 조건과 개발될 시스템이 갖추어야 할

특성들을 정리한다.

입력물/산출물

입력물 산출물


14 TTAS.KO.11.0015/R1

자료사전

요구명세서(계획단계)




- 요구정의서

요구정의서(보완)

4.2.3 분석 모형 작성

개요

시스템의 기능적 요구 사항인 사용사례를 구체적으로 분석하는 작업이다. 각 사용사례에

대해서 관련 있는 행위자와 시스템간의 사건흐름을 규명하고, 실제 사건흐름의 예를

보여주는 시나리오를 작성한다. 이를 바탕으로 시스템을 구성하는 여러 객체를 식별하고

객체간의 상호작용(Interaction)을 분석하여 식별된 객체의 속성, 연산을 규명하여 상위

수준의 클래스도를 작성한다.

절차 설명

① 사용사례 상세기술

각 사용사례에 대해 사용자와 시스템 간의 상호작용을 나타내는 사건의 흐름을

기술하고, 사용사례가 실제로 이루어지는 여러 상황을 묘사하는 수준으로

시나리오를 상세하게 기술하여 사용사례를 구체화한다.

사건흐름규명

각 사용사례에 대해 행위자와 시스템이 구체적으로 어떻게 서로 상호작용을

하는지를 기술한다. 이때 무슨 사건이 일어나는지 혹은 서로 어떤 정보(what)를

주고 받는 지를 기술하는데 중점을 두어야 하며 그것이 어떻게(how) 이루어지는

지에 대한 상세한 내용은 배제해야 한다.

시나리오 작성

시나리오는 사용사례의 구체적인 실제 예를 기술하는 것이다. 사용사례별로

작성한다. 먼저 해당 사용사례에 대한 정상적인 사건흐름을 가능한 한 모두

포함할 수 있게 시나리오를 작성한다. 필요하다면 이를 위해 여러 시나리오를

작성할 필요도 있다.

그런 다음, 예외 상황이 발생할 수 있는 사건흐름을 기술한다. 가능한 한 모든

예외 상황(Alternative Scenario)을 기술하도록 한다.

시나리오 검토

각 사용사례별로 시나리오를 모두 작성한 후 누락되거나 불명확한 흐름이 없는지

사용자와 함께 검토한다.

② 사용자 인터페이스 정의

시나리오 작성 시에 개략적인 화면 구성이나 보고서 구성을 사용자와 함께 작성하여

참조한다. 화면 구성과 관련하여 사용자 인터페이스의 스타일(폰트, 색깔 등)도 함께

고려한다. 사용자 인터페이스가 중요한 시스템인 경우 관련된 별도의 전문가를


15 TTAS.KO.11.0015/R1

활용할 수도 있다. 일반적인 시스템의 경우, 본 작업에서는 너무 상세하게 정의할

필요는 없으며, 점진적 개발단계에서 여러 화면 간의 전이 관계 등을 포함하여

상세하게 정의한다.

화면, 보고서 양식의 식별

사용자 인터페이스와 관련된 시나리오를 검토하여 사용자에게 보여지는 화면과

보고서 양식을 식별한다. 사용자가 입력하는 모든 정보와 관련된 화면이 있어야

하며, 사용자에게 보여지는 모든 정보에 대한 화면이나 보고서 양식이 있어야

한다.

사용자 인터페이스 구성 정의

식별된 화면과 보고서 양식의 구성을 구체적으로 정의한다. 입출력화면의

구성으로 메뉴 바, 아이콘, 정보출력 창, 정보입력 창, 화면 하단의 메시지 바,

화면의 축소확대 아이콘 등 여러 가지가 있을 수 있다.

사용자 인터페이스 스타일 정의

화면의 해상도를 정하고 글자체, 글자 크기, 색깔 등을 정한다. 기타 개발

시스템과 관련된 로고 등이 있을 수 있다.

③ 객체 추출 및 상호작용 분석

각 시나리오로부터 객체를 추출하고 순서도 또는 협력도를 작성하여 객체간의

상호작용을 분석한다. 이때 주요한 화면들에 대해서는 사용자와 함께 화면 구성도를

참조하면서 내용을 명확히 한다.

객체를 추출한다.

시나리오에서 객체후보를 선정하여 객체로서 적절한지를 판단하여 객체를

선정한다. 각각의 객체에 대해 그 객체가 어떤 것인지 개략적인 설명을 기술한다.

객체 간에 주고받는 메시지를 식별한다.

시나리오에서 서술어는 객체와 객체사이의 메시지로 표현될 수 있다. 모든

서술어를 검토하여 적절한 메시지를 식별한다.

순서도/협력도를 작성한다

식별한 객체사이의 상호작용을 분석하는데 순서도나 협력도가 유용하다.

시나리오를 검토하고 사용자와 면담을 통해 각 객체와 객체사이의 메시지를

규명한다.

순서도/협력도 작성을 통해 새로 발견되는 객체가 있을 수 있으며 불분명했던

사건흐름이나 시나리오의 내용을 보완할 필요도 있다. 이렇게 사용사례를

분석하는 작업은 한번 만에 완성되기는 어려우므로 여러 번 반복 한다.

④ 클래스 식별

요구사항정의서와 위에서 작성된 사용사례분석서 등을 검토하여 클래스를 식별한다.

각 사용사례별로 관련된 모든 순서도, 협력도에서 객체를 클래스 후보로 나열하고,

클래스 후보 중에서 클래스로서 적절한 것을 선정한다. 식별된 클래스에 대해

개략적인 정의를 클래스명세서에 기술한다.

⑤ 클래스 속성 및 연산 정의

요구사항정의서와 순서도, 협력도 등을 검토하여 각 클래스의 속성과 연산을

식별한다.


16 TTAS.KO.11.0015/R1

순서도나 협력도에서 메시지는 그것을 수신하는 클래스의 연산이 될 수 있다.

메시지를 처리하기 위해 필요한 속성을 해당 클래스에 추가한다.

사용자요구사항명세서를 검토하여 추가적인 속성, 연산을 식별한다.

⑥ 클래스 관계 정의

요구사항정의서와 순서도, 협력도를 바탕으로 클래스 사이의 관계를 설정한다.

순서도, 협력도에서 메시지를 주고 받는 객체사이는 연관 관계가 있다.

추가적인 연관 관계를 식별한다.

클래스 사이에 집단화 관계를 식별한다.

클래스 사이의 다중성을 식별한다.

⑦ 클래스도 작성 및 검토

선정된 클래스의 정의를 바탕으로 사용사례별로 클래스도를 작성하고 시나리오를

검토하면서 누락된 클래스는 없는지, 클래스의 속성이나 연산은 명확하게

정의되었는지 검토한다. 그리고 클래스 간의 관계에서 누락되거나 잘못된 관계

설정은 없는지 확인한다.

사용사례별로 클래스도를 작성한다.

우선 사용사례별로 클래스도를 작성한다. 사용사례가 많고 복잡한 시스템의 경우

사용사례 단위로 클래스도를 작성하면서 각 클래스의 속성, 연산, 클래스 간의

연관관계 등을 다시 한번 검토하는 것이 유용할 것이다. 그러나 소규모의

시스템인 경우 이를 생략하고 바로 전체 시스템에 대한 클래스도를 작성할 수

있다.

전체 시스템에 대한 클래스도를 작성한다.

사용사례별로 정의한 클래스와 클래스도를 검토하여 중복되는 클래스를

식별하고, 전체 시스템에 대한 클래스도를 작성한다.

입력물/산출물

입력물 산출물

요구정의서 설계명세서

− 사용사례분석서

− 클래스명세서

4.2.4 초기 아키텍처 정의

개요

사용자 요구사항의 분석 결과를 바탕으로 개발 시스템의 개략적인 아키텍처를 정의한다.

아키텍처란 인터페이스를 통해 상호 작용하는 시스템의 주요 구성요소의 조직이나

구조를 말하며 시스템의 제약사항과 시스템 구성요소의 조직이나 구조의 근거를

포함한다. 그리고 각 구성요소는 더 작은 구성요소와 인터페이스로 구성될 수 있다.

시스템의 아키텍처를 정의할 때는 여러 관점들을 함께 고려할 필요가 있다. 여기서는

사용사례 구조, 클래스 구조, 구현 구조, 분산 구조, 병행 구조 등으로 구분하여


17 TTAS.KO.11.0015/R1

아키텍처를 정의한다.

본 작업에서는 개발 시스템의 아키텍처에 대한 안들을 제시한다. 특히 사용사례 구조,

클래스 구조, 분산 구조 등의 관점의 기술에 주안점을 두며, 다른 아키텍처 관점 즉, 병행

구조와 구현 구조에 대해서는 다음 활동인 아키텍처 정립 활동에서 주로 다룬다. 만약

개발할 시스템과 유사한 시스템을 개발한 경험이 있으면, 그 시스템의 아키텍처를

참조하여 개발시스템에 대한 병행 구조나 분산구조를 정의할 수도 있다.

절차 설명

① 아키텍처 개요 작성

개발 시스템의 아키텍처 개요에 대해 기술한다. 만약 유사한 시스템의 개발 경험이

있다면 기존 시스템의 아키텍처정의서를 참고한다.

개발 시스템의 개요를 기술한다.

개발 시스템에 대한 개략적인 목표, 비전을 기술하고, 아키텍처정의서의 구성 즉,

이 문서에 포함된 아키텍처 관점에 대해 개략적인 내용을 기술한다.

아키텍처에 영향을 미치는 소프트웨어 요구사항과 목표를 서술한다.

시스템을 개발하기 위해 필요한 모든 소프트웨어를 개발할 필요는 없으며,

가능한 한 상용 소프트웨어를 많이 사용하는 것이 개발에 유리하다. 어떤 상용

소프트웨어를 사용할지, 그리고 시스템의 이식성이나 재사용성에 관한 목표를

기술한다.

기타 제약사항을 기술한다.

현행시스템분석서 및 요구정의서를 검토하고 사용자와의 면담을 통해 시스템의

제약사항은 어떤 것이 있는지(동시에 접근 가능한 사용자의 수나 처리량 등)를

기술한다.

② 초기 사용사례 구조 정의

사용자 요구 정제 작업을 통해 식별된 사용사례를 검토하여 시스템의 사용사례

구조를 정의한다. 각 사용사례의 크기나 사용사례 간의 관계가 적절히 설정되었는지

확인하고 필요한 경우 관련 있는 사용사례들을 패키징한다. 그리고 중요도를

고려하여 사용사례의 우선순위를 결정한다.

사용사례를 검토한다.

사용사례의 복잡도가 적절한지 먼저 검토해야 하는데 각 사용사례별로

시나리오를 검토하여 시나리오가 복잡하거나 많은 행위자로부터 사용되는

사용사례는 적절히 분할하도록 한다. 그리고 그 분할된 사용사례의 관계를

적절히 설정한다.

사용사례를 패키징한다.

사용사례가 많은 경우, 서로 관련 있는 사용사례를 분류하여 패키징할 수 있다.

어떤 정보를 공유하는 사용사례들을 한 패키지로 설정할 수도 있고 기능단위로

패키지를 설정할 수도 있다. <<extend>>관계에 있는 사용사례는 한 패키지에

할당하는 것이 좋으며, <<use>> 관계에 있는 사용사례는 정보교환이 많은 쪽의


18 TTAS.KO.11.0015/R1

사용사례와 같은 패키지에 할당한다.

사용사례의 우선 순위를 결정한다.

식별된 사용사례, 사용사례 기술서, 사용사례도를 사용자와 함께 검토하면서

그들 간의 우선순위를 정하는데 이때 우선 순위를 높음, 보통, 낮음의 3 등급으로

나타낼 수 있다.

개발 계획을 수립할 때 우선순위가 높은 사용사례부터 개발될 수 있도록 한다.

사용사례의 우선순위와 사용사례 패키지를 바탕으로 사용사례도, 사용사례기술

등을 검토하여 아키텍처정의서의 사용사례 구조를 기술한다.

③ 초기 클래스 구조 정의

클래스 구조는 사용자에게 필요한 기능을 제공하기 위해 시스템의 클래스들이

어떻게 구성되는지를 보여주는 것이다. 분석 모형 작성 작업에서 만들어진

클래스도를 바탕으로 관련 있는 클래스를 패키징하고, 각 패키지를 설정된 계층에

할당한다. 본 작업에서는 상위계층(Application Layer)의 클래스 패키지를 잘

정의하는 것이 중요하다.

개발 시스템에 적합한 클래스 계층을 정의한다.

클래스 구조의 계층을 몇 개로 정할지는 응용(Application)에 따라 다를 수

있으며, 각 계층사이에는 인터페이스가 잘 정의되어서 어떤 계층의 패키지를

수정했을 때 다른 계층의 패키지에게 가능한 한 적은 영향을 미치도록 해야 한다.

클래스들을 패키징하고 계층에 할당한다.

설계명세서의 클래스명세서를 바탕으로 관련 있는 클래스들을 패키징한다. 어떤

클래스가 여러 패키지와 관련이 있을 경우 이 클래스를 특정 패키지에

소속시키고 이 클래스와 관련 있는 다른 패키지들은 그 패키지와

<<import>>관계를 설정한다. 여러 패키지와 관련 있는 클래스를 어느 패키지에

소속시킬 지를 결정하기 위해서는 그 클래스와 다른 클래스와 주고받는 메시지의

빈도나, 메시지의 중요도, 패키지의 크기 등 여러 가지를 고려해서 결정한다.

그리고 상용 소프트웨어(COTS)나 기반 클래스(sets, lists, queues, …) 또는

오류처리 클래스들은 ‘ global’ 패키지로 설정한다.

클래스에 대한 패키지화가 끝나면 각 패키지를 적절한 계층에 할당한다.

패키지 간의 관계에서 사이클이 있으면 이를 해소한다.

패키지 사이의 종속 관계는 사이클이 없어야 바람직하다. 패키지 간의 종속

관계란 하나의 패키지가 변경되면 그것과 종속 관계가 있는 다른 패키지도 다시

컴파일하거나 재시험 해야 하는 의미이다. 만약 어떤 두(혹은 셋 이상의) 패키지

사이에 사이클 종속 관계가 있고 그 중 한 패키지를 수정하면 사이클 관계가 있는

모든 패키지에 대해 재시험 해야 한다. 사이클 종속 관계를 해소하는 방법은 만약

두 패키지의 종속 관계가 심하면 하나의 패키지로 만들고, 종속 관계가 심하지

않다면 사이클이 없어질 수 있도록 어느 하나의 패키지를 둘로 나누는 방법이

있다.

④ 초기 병행 구조 정의

시스템이 실행될 때 여러 프로세스가 병행적으로 수행될 수 있을 경우 이 병행성을

기술한다. 본 작업에서는 병행 구조에 대해 여러 가지 대안을 작성하고 이후 충분한


19 TTAS.KO.11.0015/R1

검토를 통해 확정한다.

프로세스를 정의한다.

병행 프로세스를 식별할 때 고려해야 할 것은 시스템의 비기능적 요구사항(성능,

처리량, 응답속도, 무결성, scalability, fault-tolerance 등등)과 하드웨어,

네트웨어 성능 등이며 이를 위해 시스템을 어느 정도로 분산시켜야 할지를

결정해야 한다.

분산된 시스템의 기능을 어떤 프로세스가 담당할지 식별하고 각 프로세스는 어떤

객체들을 포함하는 지 결정한다.

프로세스간의 통신 방식을 결정한다.

병행처리를 하는 프로세스 간에는 통신하는 방식이 필요하다. 각 프로세스간에

어떤 방식으로 통신할지 결정해야 하는데 많이 쓰는 통신 방식에는 사건중심,

메시지 전송, 원격프로시저호출, 공유 메모리 등이 있다.

⑤ 초기 구현 구조 정의

클래스 구조에서 계층으로 표현된 각 패키지가 실제 구현할 때 어떤 구성요소로

매핑될 수 있는 지를 기술한다. 클래스 구조에서의 패키지를 각 구성요소로 매핑할

수 있으면 가장 이상적이지만 성능 요구사항이나 개발자 조직의 필요에 의해 달라질

수 있다.

개발 시스템에 적합한 구성요소의 계층을 정의한다.

구현 구조에서의 계층 구조는 클래스 구조에서의 계층 구조와 거의 유사하나

구현에 관련된 구체적인 계층을 정의한다.

구성요소를 식별하고 적절한 계층에 할당한다.

클래스 구조의 패키지와 구현구조의 각 구성요소는 서로 매핑관계가 있다.

그러나 시스템 전체 성능이나 개발 조직과 관련해서, 특정 클래스 패키지가

분할되어 여러 구성요소로 개발되거나 몇몇 클래스 패키지를 통합하여 하나의

구성요소로 개발될 수도 있다.

구성요소 를 검토하고 그들 간의 관계를 기술한다.

구성요소사이의 종속 관계는 각 구성요소에 해당하는 클래스 패키지 간의 종속

관계와 밀접한 관계가 있다.

⑥ 초기 분산 구조 정의

소프트웨어가 실행되는 물리적 네트워크의 구성을 기술한다. 개발 시스템이 어떤

하드웨어로 구성되는지 그리고 그 하드웨어에는 어떤 프로세스가 수행되는지를

기술한다.

시스템이 운영될 각 하드웨어를 노드로 하는 네트워크를 기술한다.

병행구조에서 식별된 프로세스를 노드에 할당하는 것을 기술한다.

입력물/산출물

입력물 산출물

요구정의서 아키텍처정의서(초기)


20 TTAS.KO.11.0015/R1

4.2.5 사용자지침서 초안 작성

개요

사용자 요구사항의 분석 결과를 바탕으로 개략적인 사용자지침서를 작성한다. 사용자가

시스템을 쉽게 이해할 수 있도록 사용자지침서를 작성한다. 사용자지침서의 항목을

정의하고 각 항목별로 내용을 작성한다. 사용자지침서가 적절하게 작성되었는지


현 시점에서 작성하는 사용자지침서는 기본 골격이 정리되는 수준이며 최종적인 사용자

지침서는 점진적 개발단계에서 완성된다. 사용자지침서는 일반적으로 수행

기능별로(예; 회계관리, 인사관리 등) 작성되며 사용자 수준에 따라서 그 편성 표준이

다를 수도 있다. 무엇보다도 사용자의 업무 수행 절차가 잘 반영되어야 한다.

절차 설명

① 구성항목 정의

사용자가 시스템의 사용법을 쉽게 알 수 있도록 사용자지침서의 항목을 정의한다.

그리고 시스템의 관련 정보도 기술할 수 있도록 한다.

업무 및 수행 절차 파악

업무 기능 조정 작업에서 파악된 사용자 업무 및 수행 절차를 면밀히 검토한다.

사용자 지침서는 대개 사용자 업무별로 별도의 지침서가 만들어지고 업무 수행

절차가 사용자 지침서에 충분히 반영되어야 한다. 업무 파악 시 데이터 처리

지역도 고려하도록 한다.

작성 지침 설정

사용자 지침서는 업무 유형별로 다양하게 작성될 수 있으며 사용자 수준별로

다를 수도 있다. 이러한 다양성에 대한 사전 기준이나 지침이 없으면 편성 체제에

일관성을 유지하기가 어려울 수도 있다. 이러한 지침이나 기준은 사용자와

협의하여 설정해 둘 수도 있다.

사용자지침서의 일반사항(목차, 개요, 특징)에 대한 항목을 정한다.

시스템의 일반적인 기능(시작, 종료, 메뉴사용, 환경 설정)을 잘 설명할 수 있는

항목을 정한다.

앞서 파악한 업무를 원활히 수행할 수 있도록 응용시스템의 조작 방법을 쉽게 알

수 있도록 항목을 설정한다.

오류가 발생했을 때 대처방안을 기술할 수 있는 항목을 정한다.

② 항목별 내용 작성

정의된 구성항목의 내용을 작성한다. 사용자의 입장에서 가능한 한 쉽게 이해할 수

있도록 실행화면의 예를 함께 제시하여 기술한다. 만약 실제의 실행화면이 아직

개발되지 않았다면 개략적인 그림을 삽입한다.

화면 동작 특성이나 사용 키의 활용법에 대해서 충분히 설명될 수 있어야 한다.

③ 사용자지침서 검토

작성된 사용자지침서가 사용자 요구 사항의 내용을 충실히 반영하여 작성되었는지


21 TTAS.KO.11.0015/R1

검토한다. 사용자지침서에서 누락된 항목이 있는지, 각 항목의 내용이 적절한지


업무 유형별 조작방법 항목 및 설명 내용 검토

시작, 종료, 기타 화면에 대한 그림이 실제로 일치하는지 검토

검토의견 반영

입력물/산출물

입력물 산출물

요구정의서

사용자지침서(초안)

4.3 아키텍처 정립

아키텍처 정립 활동은 요구 분석 활동의 초기 아키텍처정의 작업과 시제품 개발

미니프로젝트 활동 및 위험 분석 활동의 결과를 바탕으로 개발될 시스템의 아키텍처를

정의한다. 아키텍처는 문제영역 전체에 대해 개발 과정에서 지켜야 할 원칙들을 정의하는

것이며, 개발자는 아키텍처에 정의된 원칙을 준수해야 한다.

아키텍처를 정의할 때 시스템을 보는 관점에 따라 사용사례 구조, 클래스 구조, 병행 구조,

분산 구조, 구현 구조 등을 기술한다.

작업 구조

아키텍처 정의서 작성 활동은 모두 2 개의 작업과 7 개의 절차로 이루어져 있으며 세부

사항은 다음과 같다.

① 아키텍처 정의

초기 아키텍처정의서를 바탕으로 시제품 개발의 결과를 검토하여 각 관점별 구조를

정의/보완한다. 다음과 같은 절차로 구성되어 있다.

사용사례 구조 정의

클래스 구조 정의

구현 구조 정의

분산 구조 정의

② 아키텍처 검토

아키텍처 정의서를 검토하여 미비한 부분의 있으면 보완한다. 이때 각 점검사항에

대해 다시 확인한다. 아키텍쳐 정의 작업을 통해 새롭게 발견되었가나 또는

잠재적인 위험이 있는지 확인 및 정의리하고 그 해결방안을 수립한다. 다음과 같은

절차로 구성되어 있다.

아키텍처정의서 검토 및 보완


22 TTAS.KO.11.0015/R1

위험분석서 검토 및 보완

4.3.1 아키텍처 정의

개요

이전 활동의 산출물인 초기 아키텍처정의서, 아키텍처 시제품 개발의 결과 등을

바탕으로 개발할 시스템의 아키텍처를 구체적으로 정의한다. 초기 아키텍처정의서에서

어떤 사항에 대해 대안이 만들어 졌다면 본 작업에서는 시제품 개발 결과를 검토하여

적절한 안을 결정한다.

시스템의 아키텍처에 대한 관점 중에서 사용사례 구조, 상위 계층의 클래스 구조, 분산

구조 등은 초기 아키텍처정의서의 내용을 검토하여 보완하며 하위 계층의 클래스 구조,

구현 구조, 병행 구조 등을 명확하게 정의한다.

절차 설명

① 사용사례 구조 정의

시제품 개발 미니프로젝트 활동의 결과 산출된 시제품의 개발문서 검토를 통해

사용사례 구조에 대해 보완할 내용을 식별하고 반영한다.

초기 사용사례 구조를 검토한다.

시제품 개발문서와 초기 아키텍처정의서를 검토하여 새로 발견되는 사용사례가

있는지 확인한다. 시제품을 개발한 결과 어떤 사용사례는 예상외로 훨씬 복잡하여

분할할 필요가 있다거나 어떤 사용사례는 다른 관련된 사용사례에 포함시킬

필요가 있다든지 등의 보완 사항이 있을 수 있다. 이때 사용자도 함께 검토해서 그

사용사례를 명확하게 이해할 수 있도록 해야 한다.

사용사례 구조를 보완한다.

사용사례구조에 대해 보완사항이 있는 경우 그것을 반영하여 사용사례도를

재작성하고 그에 따라 사건흐름, 시나리오 등도 보완한다. 이때 사용사례 간의

관계(uses, extends)도 적절한지 검토해야 한다. 그리고 사용사례를 패키지로

나누었을 경우 각 패키지도 적절한지 검토한다.

② 클래스 구조 정의

초기 아키텍처정의서에 기술된 클래스 구조가 적절한지 확인하고 보완사항이

있으면 반영한다.

각 클래스 속성, 연산을 보완한다.

클래스 관계를 보완한다.

시제품 개발을 통해 새로 식별된 각 클래스의 속성이나 연산을 반영하여

보완한다. 그에 따른 패키지 내의 클래스 간의 관계를 보완한다.

클래스 패키지를 보완한다.

새로운 클래스 패키지가 식별되거나 어떤 클래스 패키지의 분할 또는 병합할

필요가 있을 경우 검토하여 반영한다. 이때 패키지 간의 종속 관계에서 사이클이


23 TTAS.KO.11.0015/R1

없도록 해야 한다.

③ 병행 구조 정의

시스템이 여러 하드웨어에서 병행적으로 수행될 수 있을 경우 시스템의 병행성을

기술한다. 본 작업에서는 병행 구조에 대해 여러 가지 대안을 작성하고 이후 충분한

검토를 통해 확정한다.

프로세스를 정의한다.

시스템의 비기능적 요구사항(성능, 처리량, 응답속도, 무결성, 신뢰성, scalability

등등)과 하드웨어, 네트웨어 등의 성능을 고려하여 시스템이 어느 정도

분산되어야 할지 결정한다. 분산된 시스템의 기능을 어떤 프로세스가 담당할지

식별한다. 그리고 각 프로세스는 어떤 객체들을 포함하는지 결정한다.

프로세스간의 통신 방식을 결정한다.

병행처리를 하는 프로세스 간에는 통신하는 방식이 필요하다. 각 프로세스간에

어떤 방식으로 통신할지 결정해야 하는데 많이 쓰는 통신 방식에는

사건중심(event driven), 메시지 전송, 원결프로시저호출, 공유 메모리 등이 있다.

④ 구현 구조 정의

초기 구현 구조를 검토하여 보완한다. 구현 구조는 구현 환경에서 실제 소프트웨어

모듈(소스파일, 이진파일, 실행파일)의 구조를 기술한다. 클래스 구조에서 계층으로

표현된 각 패키지가 구현 구조에서 어떤 구성요소로 매핑될 수 있는 지를 기술한다.

적절하다면, 클래스 구조의 패키지를 구현 구조의 패키지로 매핑하는 것을 정의한다.

초기 구현 구조의 계층을 검토한다.

초기 아키텍처정의서에 기술된 구현 구조의 계층을 검토하여 변경사항이 있는

경우 보완한다.

추가되거나 변경되는 구성요소를 식별하고 적절한 계층에 할당한다.

시제품 개발을 통해 보다 구체적인 구성요소를 정의할 수 있다. 클래스 구조의

클래스 패키지와 구현구조의 각 구성요소는 서로 어느정도의 매핑관계가

있으므로 클래스 구조에서 새로 추가된 클래스 패키지에 해당하는 구성요소를

정의한다. 이때 시스템 전체 성능이나 개발 조직 등을 고려하여 적절히 조정한다.

구성요소를 검토하고 그들 간의 관계를 기술한다.

구성요소 사이의 종속 관계는 각 구성요소에 해당하는 클래스 패키지 간의 종속

관계와 밀접한 관계가 있다. 클래스 패키지와 바로 매핑되지 않는 구성요소는

구성요소 간의 관계 설정에 특히 유의한다.

⑤ 분산 구조 정의

시제품 개발에 의한 산출물과 초기 아키텍처정의서의 분산 구조를 검토하여 보완할

사항이 있는지 확인한다. 시스템의 구성 하드웨어 플랫폼이 변경되었는지 혹은 각

하드웨어에서 수행되는 프로세스에 변경이 필요한지 검토하여 시스템의 분산

구조를 정의한다. 그리고 시험이나 시뮬레이션을 위한 네트워크 구성도 포함한다.

시스템이 분산되었을 때 이 구조를 정의한다.

시스템이 운영될 하드웨어 네트워크를 작성한다.

병행구조에서 식별된 프로세스를 노드에 할당한다.


24 TTAS.KO.11.0015/R1

입력물/산출물

입력물 산출물

요구정의서

설계명세서

아키텍처정의서(초기)

위험분석서

시제품 개발문서

아키텍처정의서

4.3.2 아키텍처 검토

개요

아키텍처 정의 작업의 결과에 대해 각 관점별로 미비한 부분이 있으면 보완한다. 이때

각 점검사항에 대해 다시 확인한다.

이전 활동인 위험 분석 활동을 통해 발견된 위험 요소 중 시제품 개발 미니프로젝트

활동을 통해 해소된 위험이 있는지 확인하고 그 결과를 정리하며, 아키텍처 정의 작업을

통해 새롭게 발견되었거나 또는 잠재적인 위험이 있는지 확인 및 정리하고 그 해결

방안을 수립한다.

절차 설명

① 아키텍처정의서 검토 및 보완

사용사례 구조, 클래스 구조, 병행 구조, 분산 구조, 구현 구조에 대해 각 점검사항을

다시 확인하면서 미비한 사항이 있으면 보완한다.

각 구조에 대해 아키텍처 점검사항에 따라 검토를 실시한다.

개발 시스템의 특성에 따라 아키텍처에 대한 다른 관점의 구조를 정의할 필요가

있을 경우 기술한다. 예를 들면 사용자 인터페이스 구조나 보인 구조 등이 있을

수 있다.

② 위험분석서 검토 및 보완

시스템의 아키텍처를 정의하면서 새롭게 발견되거나 잠재적인 위험이 있으면 그

해소방안을 수립한다.

위험관리표를 점검하면서 해결된 위험에 대해 상황을 기록한다.

새로 발견된 위험요소나 잠재적인 위험이 있으면 그 위험요소를 평가한 후

해결방안을 수립하여 위험관리표에 기록한다.

입력물/산출물

입력물 산출물


위험분석서

아키텍처정의서(보완)

위험분석서(보완)


25 TTAS.KO.11.0015/R1

4.4 요구 정제 및 설계

해당 미니프로젝트에서 개발하고자 하는 사용사례들을 검토하여 사건흐름, 순서도,

시나리오를 정제하고 사용사례를 구현하기 위해 필요한 설계 클래스들을 식별하고 정의한다.

추가된 설계 클래스들을 고려하여 클래스들간의 메시지 교환, 즉 시스템의 동적인 측면을

정제한다. 설계클래스가 추가된 클래스도와 그에 따라 변경된 순서도/협력도를 검토하여

클래스의 속성, 속성의 타입, 속성의 가시성, 연산, 연산의 인수, 클래스들 간의 관계 등을

명확히 정의한다. 설계클래스 추가 작업과 클래스 정제 작업에 의해 설계된 지속성 클래스에

대해 데이터베이스를 설계한다. 정립단계의 설계명세서를 바탕으로 시스템의 구성 화면 및

시스템이 제공하는 보고서를 설계한다. 설계결과를 바탕으로 시스템의 아키텍처에 변경할

부분이 있으면 보완, 정제한다.

작업 구조

요구사항 정제 및 설계 활동은 모두 6 개의 작업과 30 개의 절차로 이루어져 있으며

세부사항은 다음과 같다.

① 사용사례 정제

해당 미니프로젝트에서 개발할 사용사례를 검토하여 사건의 흐름이나 순서도의

추가 또는 변경을 고려하여 사용사례를 정제한다.

사용자 요구 검토

사건 흐름 정제

시나리오 정제

사용자 인터페이스 정제

객체 상호작용 정제

② 설계 클래스 추가

해당 미니프로젝트에서 개발하고자 하는 사용사례를 구현하기 위해 필요한

설계클래스를 정의한다.

영역관련 클래스 정의

데이터베이스관련 클래스 정의

사용자 인터페이스 관련 클래스 정의

기타 설계 클래스 정의

③ 클래스 정제

설계클래스 추가 작업에서 식별된 클래스를 중심으로 해당 미니프로젝트의

사용사례별로 객체의 상호작용을 정제한다. 이를 바탕으로 해당 클래스 및 관련

클래스의 속성, 연산 등을 정제한다.

객체 상호작용 정제

속성 및 연산 정제

관계 정제

상태도 작성

연산 알고리즘 설계


26 TTAS.KO.11.0015/R1

④ 데이터베이스 설계(RDB)

설계 클래스 추가 작업과 클래스도 정제 작업에 의해 설계된 지속성 클래스를

관계형 데이터베이스의 테이블로 정의하고 물리적 데이터베이스 구조로 설계한다.

테이블 작성

자료량 및 접근 패턴 분석

사용자 뷰 설계

저장/접근 방법 선정

인덱스 및 데이터베이스 정의

성능개선 구조 조정

⑤ 데이터베이스 설계(OODB)

만일 객체지향 데이터베이스를 사용하고자 하는 경우, 사용하고자 하는 구체적인

DBMS를 검토하여 선정하고 자료량과 접근패턴 분석을 근거로 하여 적합한

저장/접근 방법을 선정하고 인덱스 및 데이터베이스를 정의한다.

자료량 및 접근 패턴 분석

저장/접근 방법 선정

인덱스 및 데이터베이스 정의

⑥ 사용자 인터페이스 설계

요구사항 분석 활동에서 만들어진 개략적인 화면 구성 및 보고서 구성을 바탕으로

사용사례와 관련된 화면 및 보고서를 설계한다.

사용사례분석서 검토

사용자 인터페이스 메타포어 선정

항해트리 작성

화면 및 보고서 설계

⑦ 아키텍처 정제

설계명세서를 검토하여 시스템의 아키텍처를 정제하고 사용사례와 클래스 및

구성요소의 관계를 나타내는 구성연관표를 보완한다.

설계 검토

사용사례 구조 정제

클래스 구조 정제

병행 구조 정제

구현 구조 정제

분산 구조 정제

사용사례분석서 검토

4.4.1 사용사례 정제

개요

해당 미니프로젝트에 할당된 사용사례를 개발하기 위하여 선택적으로 이 작업을

수행한다. 즉, 사용사례를 더욱 정확하게 개발하기 위해서 예외적인 사건 흐름이나

시나리오, 순서도, 협력도 등을 추가, 변경할 수 있다.


27 TTAS.KO.11.0015/R1

절차 설명

① 사용자 요구 검토

본 미니프로젝트 활동에서 개발할 사용사례가 어떤 것인지 확인하여 검토하고, 이전

미니프로젝트의 평가를 통해 새로운 사용사례가 추가되었으면 다른 사용사례와의

관계 등을 검토하여 요구사항정의서를 보완한다.

본 미니프로젝트에서 개발할 사용사례를 확인한다.

미니프로젝트 작업계획서를 검토하여 개발하는 사용사례가 어떤 것인지

확인하고 그 사용사례가 어떤 것인지, 다른 사용사례와의 관계 등을 검토한다.

요구정의서를 보완한다.

만약 이전 미니프로젝트 활동에 대한 평가 작업을 통해 새로운 사용사례가

추가되거나 기존 사용사례에 대한 변경이 요구되는 경우 요구정의서를 보완한다.

② 사건 흐름 정제

본 미니프로젝트에서 개발할 사용사례에 대해 불명확한 부분이 없는지 사용자와

함께 검토하고 정제한다.

사용사례의 사건흐름을 검토한다.

정상적인 사건흐름이 모두 명확한지 검토하고 비정상적인 사건흐름이 모두

명확한지 검토한다. 사용자가 입력하는 모든 정보가 분명한지 그 정보가 모두

명확하게 처리되는지 사용자와 충분히 검토될 수 있도록 한다.

사건흐름을 정제한다.

먼저 모든 정상적인 사건 흐름 중에 불분명한 부분을 보완하고, 비정상적인

사건흐름의 불명확한 부분에 대해 정제한다.

각 사용사례에 대해 행위자와 시스템이 구체적으로 어떻게 서로 상호작용을

하는지를 기술한다. 이때 무슨 사건이 일어나는지 혹은 서로 어떤 정보(what)를

주고 받는지를 기술하는데 중점을 두어야 하며 그것이 어떻게(how) 이루어지는

지에 대한 상세한 내용은 배제해야 한다.

③ 시나리오 정제

본 미니프로젝트 활동에서 개발할 사용사례에 대한 시나리오를 검토하고 보다

상세히 정제한다. 위의 작업에서 사건흐름이 보완되었다면 관련된 시나리오도

보완한다.

시나리오를 검토한다.

작성된 모든 시나리오가 사건흐름에 맞게 명확하게 기술되었는지를 사용자와

함께 충분히 검토하도록 한다.

사건 흐름에 대한 시나리오를 정제한다.

검토 내용을 바탕으로 시나리오를 작성한다. 사용사례의 사건흐름이 추가되었을

경우 추가된 사건흐름에 대한 시나리오를 작성한다.

가능한 한 사용자가 직접 시나리오를 작성 및 보완 하도록 하는 것이 좋다.

요구분석가는 그 시나리오가 사건흐름의 기술 내용과 비교하여 빠진 부분이

없는지 확인한다. 그러나 사용자가 시나리오를 기술하는데 익숙하지 않다면

요구분석가가 시나리오를 작성하고 반드시 사용자의 검토를 받도록 한다..


28 TTAS.KO.11.0015/R1

시나리오는 사건흐름의 구체적인 실제 예를 기술하는 것이다. 정상적인

사건흐름을 모두 포함할 수 있는 시나리오를 작성하며, 예외상황에 대한 가능한

시나리오도 작성한다.

④ 사용자 인터페이스 정제

위의 작업에서 정제된 시나리오를 검토하여 화면 구성이나 보고서 양식 등이 보완할

내용이 있는지 확인하고 각각을 상세하게 정의한다.

화면이나 보고서 양식에서 변경이나 추가된 것을 식별한다.

화면이나 보고서 양식의 구성을 구체적으로 정의한다.

스타일(색깔, 글자크기, 글자체, 등등)을 상세히 정의한다.

각 화면 및 보고서 양식을 사용자와 함께 검토한다.

⑤ 객체 상호작용 정제

보완된 시나리오를 검토하여 새로 식별되는 객체가 있는지 확인하고, 객체간의

동적인 상호작용을 정제한다.

추가적인 객체를 식별한다.

메시지 흐름을 식별한다.

객체의 생성과 소멸이 명확한지 검토한다.

순서도나 협력도를 정제한다.

입력물/산출물

입력물 산출물

미니프로젝트 작업계획서

요구정의서

설계명세서

- 사용사례분석서

요구정의서(보완)

설계명세서

- 사용사례분석서(보완)

4.4.2 설계클래스 추가

개요

사용사례분석서와 미니프로젝트작업계획서에 기술된 개발 범위를 바탕으로 본

미니프로젝트에서 개발하고자 하는 사용사례를 구현하기 위해 필요한 설계 클래스들을

정의한다.

이 작업에서는 설계클래스를 크게 네 가지 그룹으로 나누어서 생각한다. 프로세스를

수행하는 영역클래스와 관련 있는 영역관련 클래스, 저장될 필요가 있는 지속성

클래스와 관련 있는 데이터베이스관련 클래스, 사용자 인터페이스 클래스와 관련 있는

사용자 인터페이스 관련 클래스 그리고 마지막으로 네트워크 기능, 보안 기능 등과 관련

있는 기타 설계클래스 등이다.

절차 설명

① 영역관련 클래스 정의


29 TTAS.KO.11.0015/R1

미니프로젝트 작업계획서의 개발 범위를 검토한 후 아키텍처정의서,

사용사례분석서, 클래스명세서를 검토하여 영역 클래스를 식별하고 영역과 관련된

클래스를 정의한다.

사용사례분석서의 시나리오, 순서도/협력도 등을 검토하여 영역 클래스를

식별한다.

식별된 영역 클래스를 바탕으로 영역과 관련된 클래스를 정의한다.

필요에 따라 기존의 클래스를 분할, 병합한다.

클래스의 속성이 새로운 타입(하나의 속성이 여러 개의 기본타입으로 구성된

경우)을 갖는 경우 클래스를 분할하여 새로운 클래스를 정의한다.

클래스가 하나의 클래스로 존재하는 것보다 다른 클래스의 속성으로 존재하는

것이 더욱 효과적인 경우가 있다. 이러한 경우 두개의 클래스를 병합한다.

식별된 설계 클래스들을 클래스도에 삽입하고 설계 클래스들을 고려하여

클래스도를 정제한다.

정의된 설계클래스 후보들 중 클래스로 합당한 것을 선정한다. 선정된

클래스들을 고려하여 클래스도의 패키지를 정제하고, 설계 클래스들을 각

패키지에 할당한다．설계클래스들과 기존의 클래스들과의 관계 및 설계

클래스들의 속성과 연산 등을 정의한다.

② 데이터베이스 관련 클래스 정의

미니프로젝트 작업계획서의 개발 범위를 검토한 후 아키텍처정의서,

사용사례분석서와 클래스명세서 등을 검토하여 지속성 클래스를 식별하고

데이터베이스와 관련된 클래스를 정의한다.

지속적으로 저장될 필요가 있는 지속성 클래스를 식별한다.

식별된 지속성 클래스를 바탕으로 데이터베이스와 관련된 클래스를 정의한다.

관계형 데이터베이스를 사용할 경우에는 관계형 데이터베이스와의 인터페이스를

위한 클래스를 정의한다.

객체지향 DBMS 를 사용할 경우 DBMS 의 특성을 파악하여 DBMS 가 지원하는

클래스들을 반영하여 설계클래스를 조정한다.

트랜잭션 처리를 위한 클래스, 질의를 위한 클래스 등 기타 데이터베이스와

관련된 클래스를 정의한다. 질의처리를 지속성 클래스의 연산으로 설계할 수도

있다.



정의된 설계 클래스 후보들 중 클래스로 합당한 것을 선정한다. 선정된

클래스들을 고려하여 클래스도의 패키지를 정제하고 설계 클래스들을 각

패키지에 할당한다．설계 클래스들과 기존의 클래스들과의 관계 및 설계


③ 사용자 인터페이스 관련 클래스 정의

미니프로젝트의 작업계획서의 개발 범위를 검토한 후 아키텍처정의서,

사용사례분석서, 클래스 명세서 등을 검토하여 사용자 인터페이스와 관련 클래스를

식별한다.


30 TTAS.KO.11.0015/R1

사용사례분석서의 시나리오, 순서도/협력도를 검토하여 사용자 인터페이스

클래스를 식별한다.

식별된 사용자 인터페이스 클래스를 바탕으로 사용자 인터페이스와 관련된







영역 클래스와 인터페이스를 위한 클래스를 정의한다.

GUI 를 설계하고자 할 때는 사용하고자 하는 GUI 도구를 고려하여 클래스를

정의한다.

식별된 설계 클래스들을 클래스도에 삽입하고 클래스도를 정제한다.



패키지에 할당한다．설계클래스들과 기존의 클래스들과의 관계 및 설계


④ 기타 설계 클래스 정의

위의 작업에서 식별된 클래스 외에 시스템의 설계에 필요한 클래스를 정의한다.

네트워크 기능을 지원하는 클래스들이나 시스템에서의 보안 기능을 위한


기존의 영역 관련 클래스, 데이터베이스 관련 클래스, 사용자 인터페이스 관련

클래스들을 구현하는 과정에서 시스템의 수행 능력이나 유지보수성, 재사용성의

향상 등을 해결하기 위한 클래스들을 정의한다.






실제 구현을 위해 부딪히게 되는 문제점들을 파악하고, 이를 해결하기 위해

필요한 설계 클래스를 정의한다.





패키지에 할당한다. 설계클래스들과 기존의 클래스들과의 관계 및 클래스 들의

속성과 메소드 등을 정의한다.

입력물/산출물


31 TTAS.KO.11.0015/R1

입력물 산출물


설계명세서


- 클래스명세서

설계명세서

- 클래스명세서(보완)

4.4.3 클래스 정제

개요

설계 클래스 추가 작업에서 설계를 위해 필요한 클래스들을 식별하고 나면, 이들간의

메시지 교환, 즉 시스템의 동적인 측면을 순서도/협력도를 이용하여 정제할 필요가 있다.

이는 새로운 클래스들이 식별되고, 따라서 기존에 정의되었던 순서도/협력도 상에서의

메시지 흐름이 상당 부분 변경되어야 할 필요가 생기기 때문이다.

절차 설명

① 순서도/협력도 정제

설계클래스 추가 작업에서 추가된 클래스들을 중심으로 객체 상호 작용을 정제한다.

새로 식별된 객체를 순서도/협력도에 추가한다.

시나리오를 검토하여 관련된 메시지를 식별하여 추가한다.

각 메시지의 흐름를 검토한다.

프로젝트의 각 사용사례의 시나리오를 바탕으로 추가된 설계클래스의

객체들간의 메시지 전달 과정을 묘사한다.

실시간 시스템과 같이 시간제약을 요하는 경우 요구명세서，요구정의서를

참조하여 시간 제약사항을 검토한다. 시간 제약사항을 기술하기 위해 UML 의

실시간 확장을 위한 표기법을 사용하여 순서도/협력도에 시간 제약사항을

나타낸다.

② 속성 및 연산 정제

설계클래스가 추가된 클래스도에 나타나는 모든 클래스의 속성과 연산을

순서도／협력도를 바탕으로 식별하여 클래스도에 추가한다．클래스의 속성,

속성의 타입, 속성의 가시성, 연산, 연산의 인수 등을 명확히 정의한다. 필요한 경우

중요한 연산의 알고리즘을 설계한다. 상태도가 작성되었다면 이를 참조하여 속성 및

연산을 정제한다.

순서도／협력도를 검토하여 추가된 설계클래스로 인하여 변경되거나

추가된 메시지가 있는지를 검토한다．

검토 내용을 바탕으로 속성 및 연산을 정제한다.

변경되거나 추가된 메시지를 처리하기 위해 요구되는 속성을 해당 클래스에

추가한다. 각 메시지를 수신하는 객체에 해당하는 클래스에 해당 메시지를

처리하기 위한 연산을 추가한다.

하나의 객체가 자기 자신에게 보내는 메시지(self-delegation)를 처리하기 위한

연산을 그 객체에 해당하는 클래스에 추가한다. 클래스의 상태도에 나타나는


32 TTAS.KO.11.0015/R1

트랜지션을 해당 클래스의 연산으로 추가한다.

순서도／협력도, 상태도, 아키텍쳐 정의서 등을 검토하여 속성의

가시성，속성값의 타입, 연산의 인수，연산의 가시성，클래스명,

속성명，연산명 등을 명확히 정의한다．

상속관계를 갖는 클래스들을 검토하여 상위 클래스의 연산을 하위클래스가

오버라이딩하는 지를 고려하여 연산을 정의한다.

③ 관계 정제

설계클래스를 고려하여 정제된 순서도/협력도를 바탕으로 클래스 사이의 관계 및

패키지 사이의 관계를 정제한다.

설계클래스가 추가되어 변경된 순서도/협력도 및 클래스도를 검토한다.

순서도/협력도에서 메시지를 주고 받는 객체 사이에는 관계가 있으므로

클래스도의 해당 클래스 사이에 관계가 있는지를 검토한다.

검토 내용을 바탕으로 클래스 사이의 관계를 정제한다.

메시지를 주고 받는 객체에 해당하는 클래스 사이에 관계가 정의되어 있지않다면

관계를 설정한다.

클래스 사이의 관계가 연관관계, 상속관계, 집단관계인지를 식별한다.

연관관계를 갖는 클래스들의 다중성, 역할명, 관계 명 등을 명확히 정의한다.

여러 클래스가 동일한 속성, 연산을 갖는 경우에는 동일한 부분을 하나의

클래스로 정의하여 상위 클래스로 정의한다. 하나의 클래스가 여러 클래스로

구성될 경우에는 집단관계를 정의한다.

클래스 사이의 관계를 바탕으로 패키지 사이의 관계를 설정, 정제한다.

④ 상태도 작성

상태변화가 중요한 클래스는 사건에 대한 상태변화를 상태도를 이용하여 표현한다.

상태변화가 중요하지 않은 시스템에서는 생략할 수 있다.

상태변화가 중요한 클래스를 식별한다.

상태도를 작성한 클래스가 나타나는 순서도를 식별한다.

순서도를 검토하여 클래스가 메시지를 송수신하는 동안 발생할 수 있는 상태들을

조사하여 상태도를 작성한다.

상태도를 검토한다.

⑤ 연산 알고리즘 설계

클래스의 연산 중에서 지극히 당연한 정도의 수준을 벗어나는 연산에 대하여 가능한

한 모두 알고리즘을 설계한다.

각 클래스의 연산을 검토하여 알고리즘이 필요한 연산을 식별한다.

식별된 각 연산에 대해 알고리즘을 설계한다.

설계한 알고리즘을 검토한다.

입력물/산출물

입력물 산출물


33 TTAS.KO.11.0015/R1


설계명세서



설계명세서

- 클래스명세서(보완)

4.4.4 데이터베이스 설계(RDB)

개요

설계클래스 추가 작업과 클래스 정제 작업에 의해 설계된 지속성 클래스를 관계형

데이터베이스의 테이블로 정의하고 물리적 데이터베이스 구조를 설계하는 작업이다.

지속성 클래스와 클래스 관계를 관계형 데이터베이스의 테이블로 정의한다. 정의된

테이블의 레코드 개수를 분석하고 해당 미니프로젝트의 사용사례별로 트랜잭션을

정의한다. 정의된 트랜잭션에 따라 데이터 접근 패턴을 분석하고 정의된 기본

테이블과는 별도로 해당 미니프로젝트에 맞는 뷰(View)를 설계한다. 사용하고자 하는

DBMS 의 검토 및 분석된 자료량과 접근패턴에 기초하여 적합한 저장/접근 방법을

선정한다. 인덱스 및 데이터베이스를 정의하고 성능 및 기능 개선을 위해 추가적인 구조

조정을 한다. 저장/접근 방법 선정, 인덱스 및 데이터베이스 정의 절차와 성능개선 구조

조정 절차를 반복적으로 수행된다.

절차 설명

① 테이블 작성

해당 미니프로젝트의 클래스도에 나타나는 지속성 클래스와 지속성 클래스 사이의

관계를 관계형 데이터베이스의 테이블 형태로 전환한다. 전환된 테이블의 테이블

정의서를 작성한다.

해당 미니프로젝트의 클래스도와 아키텍처 정의서를 검토하여 데이터베이스에

지속적으로 저장될 필요가 있는 지속성 클래스를 식별한다.

테이블 일람과 클래스도에 나타나는 지속성 클래스 및 지속성 클래스 사이의

관계를 비교, 검토하여 지속성 클래스 및 지속성 클래스 사이의 관계를 표현하는

테이블이 이미 정의되어 있는지 확인한다.

해당 미니프로젝트의 클래스도에 나타나는 지속성 클래스 및 관계를 나타내는

테이블이 이미 테이블 일람에 정의되어 있다면 관계형 데이터베이스 테이블 작성

절차를 생략할 수 있다.

그러나 만약 테이블이 이미 정의되어 있을지라도 테이블 정의서와 클래스를 비교,

검토해본 결과 클래스 속성의 추가, 생략, 또는 변경으로 인하여 테이블 컬럼의

변경이 필요한 경우 이를 고려하여 이미 정의되어 있는 테이블 정의를 변경해야

한다.

테이블 정의 기법을 이용하여 지속성 클래스를 테이블로 표현한다.

테이블 정의 기법을 이용하여 클래스 사이의 연관, 상속, 집단화 관계를 테이블로


34 TTAS.KO.11.0015/R1

표현한다.

정의된 각 테이블의 테이블정의서를 작성한다.

정의된 테이블을 테이블 일람에 추가한다.

② 자료량과 접근 패턴 분석

정의된 테이블의 자료량을 분석하고 해당 미니프로젝트의 사용사례와 관련된

트랜잭션을 처리하기 위한 데이터와 데이터에 대한 접근형태를 파악한다. 접근

형태들의 실행순서를 파악하여 논리적 접근도를 작성한다.

정의된 테이블의 자료량 즉, 레코드의 개수를 분석한다.

레코드의 개수는 테이블에 해당하는 클래스의 객체의 개수이므로 현행 시스템

자료와 사용자와의 협의를 통하여 객체의 개수를 파악한다.

분석된 자료량을 테이블 정의서의 최대 행 개수 항목에 기입한다.

순서도/협력도와 사용사례분석서를 이용하여 각 사용사례 내에서의 논리적

일관성에 따라 트랜잭션의 범위를 정의한다.

트랜잭션을 정의할 때 트랜잭션의 기간이 너무 짧거나 길지 않도록 하고

트랜잭션 내에서는 사용자 상호작용(interaction)을 피하도록 한다. 그리고

하나의 트랜잭션을 단일 갱신 작업 단위로 구성한다.

트랜잭션에서 사용되는 테이블들을 식별한다.

순서도/협력도와 클래스도로부터 테이블에 해당하는 클래스를 식별함으로써

테이블을 식별할 수 있다.

테이블에 대한 접근형태를 결정한다.

관련된 접근형태로는 READ(인스턴스의 정보를 읽음), CREATE(인스턴스의

생성), UPDATE(인스턴스의 정보 변경), DELETE(인스턴스 삭제)의 네가지

종류가 있다.

순서도/협력도를 이용하여 해당 트랜잭션의 접근 형태들의 순서를 결정한다.

접근 형태의 실행 순서가 무관한 경우도 있다. 이때에는 번호를 자유스럽게

부여하면 된다.

논리적 접근도를 작성한다.

논리적 접근도는 사용사례와 관련된 트랜잭션을 처리하는데 필요한 테이블과

테이블에 대한 접근형태 그리고 접근 형태들의 실행순서를 표현한다.

③ 사용자 뷰 설계

해당 미니프로젝트의 뷰를 작성한다. 데이터베이스는 전체 시스템이 필요로 하는

공용 데이터의 집합이라 할 수 있는데 뷰는 전체 시스템에 대한 해당

미니프로젝트의 데이터베이스의 구조를 뜻한다. 다시 말하면 뷰는 전체

데이터베이스의 부분 집합이다.

논리적 접근도, 화면 관련 문서를 검토한다.

논리적 접근도를 검토하여 트랜잭션을 처리하기 위해 필요한 테이블을 식별하고,

화면 관련 문서를 검토하여 화면에 표시될 항목이 해당하는 테이블을 식별한다.

검토결과를 바탕으로 필요한 뷰를 선정한다.

뷰를 구성하는 컬럼을 파악한다.

뷰 구성을 설정한다.


35 TTAS.KO.11.0015/R1

뷰의 계층구조는 상당한 융통성을 줄 수 있지만, 반면에 혼돈을 야기시킬 수도

있다. 하위계층에 있는 뷰나 테이블이 삭제되면 상위계층의 뷰도 삭제된다.

관계형 데이터베이스의 뷰는 기본테이블로 구성될 수 있고, 뷰로 구성될 수도

있으며 기본테이블과 뷰로 구성될 수도 있다.

뷰정의서를 작성한다.

뷰와 관련된 내용을 정리하여 문서화한다.

④ 저장/접근 방법 선정

효율적이고 실현 가능한 물리적 데이터베이스 구조를 개발하기 위하여 저장 방법 및

접근 방법을 선정한다.

스캐닝, 집중화, 해슁 등 상용 DBMS 제품이 제공하는 저장/접근 방법을

검토한다.

DBMS 제품이 제공하는 저장/접근 방법 중 적합한 것을 선정한다.

이때는 자료량 분석의 결과와 논리적 접근도를 검토하여 테이블을 저장하기 위해

적합한 저장/접근 방법을 선정한다.

특정 DBMS 가 필요한 접근 기법을 실제로 모두 제공하는 지 평가하기 위하여

벤치마크를 개발하는 것이 필요할 수도 있다.

⑤ 인덱스 및 데이터베이스 정의

인덱스를 정의하고 인덱스정의서를 작성한다. 파악된 DBMS 특성과 선정된

저장/접근 방법을 토대로 데이터베이스정의서를 작성한다. 인덱스 정의와

데이터베이스 정의는 성능개선 구조 조정 절차에서 테이블이 재정의되면 같이

갱신되도록 한다.

인덱스를 설정할 테이블을 선정한다.

인덱스화 할 테이블의 컬럼을 선정한다.

선정한 인덱스의 특성을 정의한다.

개별 데이터베이스에 저장할 테이블 및 인덱스를 파악한다.

데이터베이스의 테이블 및 인덱스 공간을 정의한다.

테이블 및 인덱스 공간 계산을 하고 설정한다.

인덱스정의서 및 데이터베이스정의서를 작성한다.

⑥ 성능개선 구조 조정

저장 방법 및 접근 방법을 추가하였다 하더라도 성능 및 기능 요구사항을 아직까지

충분히 반영하였다고는 할 수 없다. 따라서 성능 및 기능 개선을 위해 추가적인 구조

조정 작업을 한다.

중복을 통한 조정 작업을 한다.

중복 컬럼이나 중복 행의 형태로 정의된 테이블에 중복 데이터를 추가 할 수 있다.

우선 중복 데이터의 일반적인 형태인 중복 컬럼을 고려하고 그 다음 중복 행을

고려하도록 한다.

데이터베이스 구조 재정의를 통한 조정 작업을 한다.

컬럼을 선별적으로 재정의하거나 테이블 재배열의 변화는 설계의 안정성이나

DML(데이터 조작어) 질의 형태에 영향을 미칠 수도 있다. 또한 이런 변화는

데이터 무결성 확보를 위한 새로운 운영규칙의 정의 및 이행이 필요하게 된다.


36 TTAS.KO.11.0015/R1

따라서 데이터베이스 구조 재정의를 통한 조정 작업은 상당히 신중을 기해야

한다.

특정 요구사항 처리에 유리하도록 테이블 설계를 변경한다. 이러한 것은 특정

응용 처리 기능이나 성능 요구사항의 지원을 개선하기 위해 데이터베이스의

공용성을 의도적으로 줄이게 된다. 테이블 제거, 중복 테이블 추가, 테이블

구획(segmenting), 테이블 통합 등을 고려하도록 한다.

테이블정의서를 작성한다.

테이블 설계 작업에서 새로이 테이블이 정의될 때, 테이블정의서가 작성된

것처럼, 최종적인 테이블이 완성되면 이와 동일한 산출물들이 작성(갱신)되어야

한다. 그리고 저장/접근 방법 선정 절차와 인덱스 및 데이터베이스 정의 절차가

반복 수행된다.

입력물/산출물

입력물 산출물


설계명세서



데이터베이스설계서(RDB)

- 테이블정의서

- 논리적접근도(RDB)

- 뷰정의서

- 인덱스정의서(RDB)

- 데이터베이스정의서(RDB)

4.4.4-1 데이터베이스 설계(OODB)

개요

클래스의 인스턴스 즉, 객체의 개수를 분석하고 해당 미니프로젝트의 사용사례별로

트랜잭션을 정의한다. 정의된 트랜잭션에 따라 데이터 접근 패턴을 분석하고

사용하고자 하는 DBMS 검토 및 분석된 자료량과 접근패턴을 근거로 하여 적합한

저장/접근 방법을 선정하고 인덱스 및 데이터베이스를 정의한다.

절차 설명

① 자료량과 접근패턴 분석

지속성 클래스의 자료량을 분석하고 해당 미니프로젝트의 사용사례와 관련된

트랜잭션을 처리하기 위한 데이터와 데이터에 대한 접근 형태를 파악한다. 접근

형태들의 실행순서를 파악하여 논리적 접근도를 작성한다.

클래스도에 나타나는 지속성 클래스의 자료량 즉, 객체의 개수를 분석한다.

현행 시스템 자료와 사용자와의 협의를 통하여 객체의 개수를 파악한다.

분석된 클래스 자료량을 데이터베이스 명세서의 객체의 개수 항목에 기입한다.

순서도/협력도와 사용사례분석서를 이용하여 각 사용사례 내에서의 논리적

일관성에 따라 트랜잭션 범위를 정의한다.


37 TTAS.KO.11.0015/R1

트랜잭션을 정의할 때 트랜잭션의 기간이 너무 짧거나 길지 않도록 하고

트랜잭션 내에서는 사용자 상호작용(interaction)을 피하도록 한다. 그리고

하나의 트랜잭션을 단일 갱신 작업 단위로 구성한다.

트랜잭션에서 사용되는 클래스들을 순서도/협력도와 클래스도로부터 식별한다.

클래스에 대한 접근형태를 결정한다.

관련된 접근형태로는 READ(인스턴스의 정보를 읽음), CREATE(인스턴스의

생성), UPDATE(인스턴스의 정보 변경), DELETE(인스턴스 삭제)의 네가지

종류가 있다.

순서도/협력도를 이용하여 해당 트랜잭션의 접근 형태들의 순서를 결정한다.

접근 형태의 실행 순서가 무관한 경우도 있다. 이때에는 번호를 자유스럽게

부여하면 된다.

논리적 접근도를 작성한다.

논리적접근도는 사용사례와 관련된 트랜잭션을 처리하는데 필요한 클래스와

클래스에 대한 접근 형태와 접근 형태들의 실행순서를 표현한다.

② 저장/접근 방법 선정

효율적이고 실현 가능한 물리적 데이터베이스 구조를 개발하기 위하여 저장 방법 및

접근 방법을 선정한다.

스캐닝, 집중화, 해슁 등 사용 DBMS 제품이 제공하는 저장/접근 방법을

검토한다.

DBMS 제품이 제공하는 저장/접근 방법 중 적합한 것을 선정한다.

자료량 분석의 결과와 논리적 접근도를 검토하여 클래스의 객체들을 저장하기

위해 적합한 저장/접근 방법을 선정한다.

특정 DBMS 가 필요한 접근 기법을 실제로 모두 제공하는지 평가하기 위하여

벤치마크를 개발하는 것이 필요할 수도 있다.

③ 인덱스 및 데이터베이스 정의

인덱스를 정의하고 인덱스정의서를 작성하고 파악된 DBMS 특성과 선정된

저장/접근 방법을 토대로 데이터베이스정의서를 작성한다.

인덱스를 설정할 클래스를 선정한다.

인덱스화 할 클래스의 속성을 선정한다.

선정한 인덱스의 특성을 정의한다. 즉, 인덱스 형태(유일성, 비유일성, 집중화)를

구분하고 순서화된(ordered) 인덱스인 경우 순서를 결정한다.

개별 데이터베이스에 저장할 클래스 및 인덱스를 파악한다.

데이터베이스의 클래스 및 인덱스 공간 정의한다.

클래스 및 인덱스 공간 계산을 하고 설정한다.

인덱스정의서 및 데이터베이스정의서를 작성한다.

입력물/산출물

입력물 산출물

아키텍처정의서 데이터베이스설계서(OODB)


38 TTAS.KO.11.0015/R1

설계명세서



- 논리적접근도(OODB)

- 인덱스정의서(OODB)

- 데이터베이스정의서(OODB)

4.4.5 사용자 인터페이스 설계

개요

그래픽 사용자 인터페이스(GUI) 환경이 보편화 됨에 따라 사용자가 편리하게 사용하고

일관성이 있는 설계를 위하여 정립단계의 요구사항 분석 활동에서 만들어진 화면

구성도와 보고서 양식을 바탕으로 해당 미니프로젝트의 화면과 보고서를 설계한다.

사용사례 분석서의 시나리오를 검토하여 시스템의 기능을 직관적으로 잘 나타내는

메타포어를 선정하고, 각 메뉴에서 다른 메뉴로의 전이를 표현하는 항해트리를

작성한다.

절차 설명

① 사용사례분석서 검토

작성된 시나리오와 순서도/협력도 등을 검토하여 화면이나 보고서 양식 중에서

누락된 양식은 없는지 확인하고 미비한 부분은 보완한다.

시나리오를 검토하여 순서도/협력도에서 사용자 인터페이스 관련 객체가 누락된

것은 없는지 확인한다.

사용자 인터페이스와 관련된 모든 객체를 식별한다.

식별된 모든 객체에 해당하는 화면이나 보고서 양식이 존재하는지 검토한다.

화면, 보고서 양식을 사용자와 검토하면서 미비한 부분은 명확하게 정의한다.

② 사용자 인터페이스 메타포어 선정

사용사례분석서에 기술된 사용자 인터페이스 관련 내용을 검토하고, 개발할

사용사례의 기능과 특성 및 시나리오를 기반으로 최적의 메타포어를 선정한다.

메타포어는 사용자 인터페이스 객체들이 가지고 있는 시스템과 가장 효율적으로

입·출력할 수 있게 도와주도록 자체의 기능 및 모양을 갖는 것을 말한다. 한편,

시나리오에는 나타나 있지 않으나 설계자의 전문지식으로부터 유추할 수 있는

부분에 대해서는 설계자의 주관에 의해 삽입할 수도 있다. 사용자 인터페이스

메타포어란 시스템과 사용자 간의 가장 자연스럽고 효과적인 정보교류를 제공하기

위한 방식, 장치, 전략 및 수단이다. 다양한 그림의 형태로 나타낼 수 있다. 예로

풀다운 메뉴, 윈도우, 책, 지도, 테이블, 폴더 등이 있다.

사용자의 인터페이스에 대한 적용성, 사용성 등을 고려한다.

이미 나와 있는 요소들을 제외하고 해당 미니프로젝트에서 사용될 메타포어는

다른 미니프로젝트에서도 일관성 있게 적용할 수 있는 것을 선정한다.

사용자 인터페이스 시나리오를 통해서 만든 메타포어들이 기존의 클래스들의

속성이나 연산 등을 변경하거나 클래스들을 추가하게 되면 화면설계를 마친 후

사용사례 정제 작업과 클래스 정제 작업을 반복하면서 클래스들을 고쳐준다.

③ 항해 트리 작성


39 TTAS.KO.11.0015/R1

선택된 메타포어에 적합한 형태의 항해트리를 작성한다. 사용자 인터페이스 항해

트리는 정해진 메타포어에서 사용되는 사용자 인터페이스 관련 여러 구성요소 간의

모든 가능한 경로를 표시한 트리이다.

선정된 메타포어를 고려하여 항해 트리에 사용될 표기법을 작성한다.

표기법은 시스템에서 나타나는 주요 인터페이스 구성요소를 표현할 수 있어야

한다. 단, 실제 화면을 구성하는 것이 아니라 사용자 인터페이스의 흐름을

나타내는 것이 주된 목적이므로 세부적인 표현은 생략한다.

정의된 항해 트리 표기법을 사용하여 주화면을 기준으로 각 메뉴로의 전이

경로를 기술한다.

④ 화면/보고서 설계

사용자 인터페이스 구성요소는 선정된 사용자 메타포어를 구성하는 요소로 화면의

색깔, 폰트, 화면 상의 좌표, 윈도우들에 대하여 정의한다. 보고서의 내용을

정의하고 레이아웃을 정한다.

사용자 인터페이스 구성요소를 종류 별로 구분한다.

구성요소의 이름, 크기, 색상, 화면상의 좌표를 결정한다.

구성요소 특성을 고려하여 필요한 사항을 추가한다.

입력물/산출물

입력물 산출물

설계명세서



사용자인터페이스설계서

- 화면설계서

- 보고서설계서

4.4.6 아키텍처 정제

개요

설계명세서의 각 하위 산출물에 대해 일관성, 완전성, 정확성을 검토하여 정확히

설계되었는지 시스템의 비기능적 요구사항을 만족하는지를 점검한다. 그리고

설계명세서를 바탕으로 소프트웨어 구성요소의 실제 구현을 고려한 구현 구조를 명확히

정의하며 시스템의 성능과 관련하여 프로세스의 조정이 필요할 경우 병행구조를,

물리적 네트워크 구성의 변경이 필요할 경우 분산구조를 정제한다.

절차 설명

① 설계 검토

요구사항정제 및 설계 활동의 모든 산출물에 대해 일관성, 완전성, 정확성을

검토하여 정확히 설계되었는지 시스템의 비기능적 요구사항을 만족하는지를

점검한다. 점검 결과를 바탕으로 설계 검토 의견서를 작성한다. 모든 설계 산출물을

정리하여 설계명세서를 보완한다.

설계 내용이 사용자 요구 사항을 충분히 반영했는지 검토한다.


40 TTAS.KO.11.0015/R1

요구사항 정제 및 설계 활동의 산출물을 검토하여 해당 미니프로젝트의

사용사례가 정확하게 설계되었는지 점검한다. 설계결과가 시스템의 비기능적

요구사항(성능, 처리량, 응답속도, 무결성, scalability, fault-tolerance 등)을

반영하고 있는지를 점검한다.

클래스도, 순서도/협력도, 상태도, 구성요소도, 전개도 등 산출물 각각의 완전성

및 정확성을 점검한다. 사용사례도, 클래스도, 순서도/협력도, 상태도,

구성요소도, 전개도 사이의 관계를 검토하여 사용자 요구사항부터 분석,

설계까지의 흐름이 일관성이 있는지 점검한다.

설계 내용이 아키텍처정의서의 내용에 부합되는지 검토한다.

아키텍처는 시스템의 개발 전체에 대해 지켜야 할 원칙들을 정의하는 것으로

개발자는 이 원칙을 준수해야 한다. 따라서 설계자는 아키텍처정의서에 기술된

각 관점의 구조에 따라 상세한 설계를 수행하게 한다. 만약 아키텍처의 각 관점의

구조 정의에 보완이 필요한 경우, ②~⑥의 절차에 의해 아키텍처정의서는 보완이

이루어져야 한다.

점검 결과를 바탕으로 설계 검토의견서를 작성한다.

설계 검토의견서를 바탕으로 설계명세서를 보완한다.

② 사용사례 구조 정제

요구사항의 추가, 변경이 있을 경우나 요구사항정제를 통해 사용사례 구조의 보완이

필요하다고 판단될 경우 사용사례 구조를 정제한다. 각 사용사례의 크기나 사용사례

간의 관계가 적절히 설정되었는지 확인하고 필요한 경우 사용사례 패키지를

보완한다. 그리고 각 사용사례의 우선순위를 검토한다. 가능한 한 사용사례 구조의

변화는 적어야 하며, 자주 변경된다는 것은 요구사항획득 과정에 문제가 있다고 볼

수 있으며 정상적인 프로젝트 수행에 큰 부담이 된다.

사용사례의 변경이나 새로 추가된 사용사례가 있으면 보완한다.

요구사항정의서를 검토하여 사용사례의 변경이나 새로운 추가된 사용사례가

있는 지 확인하고, 사용사례 구조의 보완이 필요한지 검토한다. 또한

사용사례분석서를 검토하여 특정 사용사례가 너무 복잡한 것은 적절히

분할하도록 한다.

사용사례 간의 관계 및 우선순위를 검토한다.

새로 추가되거나 변경된 사용사례와 다른 사용사례의 관계를 검토하여 사용사례

간의 관계를 적절히 설정하고 해당 사용사례의 우선 순위도 적절한지 확인한다.

③ 클래스 구조 정제

설계명세서의 클래스명세서를 검토하여 아키텍처의 클래스 구조를 보완할 필요가

있는 경우 보완한다. 클래스 패키지의 분할, 병합이나 새로운 클래스 패키지가

추가될 수 있다. 이때 클래스 간의 종속 관계에 유의하여 검토해야 한다.

클래스 패키지의 변경이 있는지 검토한다.

이전 작업의 설계를 통해 클래스 패키지의 분할, 병합이나 새로운 클래스

패키지가 추가될 수 있다. 이때 클래스 간의 종속 관계에 유의하여 검토해야 한다.

소속 패키지가 바뀌는 클래스가 있는지 검토한다.

클래스 구조에서는 클래스 패키지의 변화 뿐만 아니라 각 패키지에 속한


41 TTAS.KO.11.0015/R1

클래스가 필요에 따라 소속 패키지를 변경할 수도 있으며 이로 인한 패키지의

종속관계도 함께 고려되어야 한다.

클래스 패키지 사이의 종속 관계를 검토한다.

여러 패키지와 관련이 있는 특정 클래스는 그 클래스와 다른 클래스가 주고받는

메시지의 빈도나, 메시지의 중요도, 패키지의 크기 등을 다시 검토한다.

검토한 내용을 바탕으로 클래스 패키지를 보완하고 패키지 사이의 종속

관계에서 사이클이 있는지 확인한다.

클래스 패키지 간의 종속 관계에서 사이클이 있다면 어떤 패키지를 수정하면

사이클 관계가 있는 모든 패키지에 대해 재시험을 해야 한다.

사이클 종속 관계를 해소하는 방법은 만약 두 패키지의 종속 관계가 심하면

하나의 패키지로 만들고, 종속 관계가 심하지 않다면 사이클이 없어질 수 있도록

해당 패키지를 둘로 나누는 방법이 있다.

④ 병행구조 정제

시스템의 프로세스들의 병행성의 변화나 새로운 프로세스가 식별되거나 시스템의

유효성, 신뢰성, 성능, 시스템 관리, 동기화가 변경되면 병행구조를 보완한다. 또,

실행에 관련된 태스크와 그들 간의 상호작용, 구성 등을 검토하여 보완한다.

프로세스를 검토한다.

시스템의 비기능적 요구사항(성능, 처리량, 응답속도, 무결성, scalability, fault-

tolerance 등등)과 하드웨어, 네트웨어 성능 등을 고려하여 식별된 병행

프로세스를 검토하고 프로세스의 보완이 필요한지 검토한다. 그리고 각

프로세스가 포함하는 객체들은 적절한지 검토한다. 만약 새로운 객체가 있다면

적절한 프로세스에 할당한다.

프로세스 간의 통신 방식을 검토한다.

식별된 프로세스 간의 통신 방식이 적절한지 검토한다. 분산된 시스템의 경우

프로세스 간의 통신방식에 따라 성능에 영향을 미칠 수 있다.

⑤ 구현 구조 정제

설계 명세서를 바탕으로 구현 구조의 구성요소를 검토한 후, 변경이 있으면 구현

구조를 보완한다.

새로 정의된 클래스나 클래스 패키지를 식별하여 해당 구성요소를 정의한다.

클래스 구조를 검토하여 새로 정의된 클래스 및 클래스 패키지를 식별하여

적절한 구성요소에 할당하거나 새로운 구성요소를 정의한다.

개발 조직의 구성을 고려하여 구성요소의 정의를 보완한다.

각 구성요소는 한명의 프로그래머나 소수의 팀이 구현해야 한다. 그렇지 않은

경우 서로 간의 의사소통을 위한 노력이 많이 들어 구현이 어려워 진다.

재사용할 수 있는 구성요소를 식별한다.

정의된 각 구성요소가 이전 미니프로젝트에서 개발되었거나 상용제품(COTS)의

라이브러리를 재사용할 수 있는 것은 어떤 것인지 검토한다. 가능한 한 새로

개발하기 보다는 기존 구성요소를 재사용하는 것이 좋다.

설계 시에 식별되지 못한 종속관계가 있는지 검토한다.

시스템을 설계할 때는 발견하지 못한 구성요소 간의 종속관계를 구현을 고려할


42 TTAS.KO.11.0015/R1

때 식별될 수 있다.

구성요소 간의 종속관계에서 사이클이 있는지 검토한다.

클래스 구조에서 사이클 종속관계를 해소해야 하는 것과 마찬가지로 구성요소

간의 사이클 종속관계도 해소해야 한다. 사이클 종속 관계를 해소하는 방법은

만약 두 구성요소의 종속 관계가 심하면 하나의 구성요소로 만들고, 종속 관계가

심하지 않다면 공통적으로 관련되는 클래스들을 새로운 구성요소로 정의하는

방법이 있다.

각 구성요소의 종류별로 위치를 설정한다.

소스코드, 실행 코드, 이미지 파일, 이진 파일, 실행 파일 등을 저장할

위치(디렉토리 혹은 폴더)를 설정한다. 그리고 시험을 위한 데이터나 프로그램을

저장할 위치도 함께 설정한다. 시스템이 큰 경우 각 구성요소를 이루는 파일의

수가 많으므로 적절하게 그 위치를 설정해야 개발자 간의 혼선을 막을 수 있다.

미니프로젝트정의서의 구성연관표를 보완한다.

새로 추가되거나 변경된 구성요소에 대해 구성요소와 사용사례 및

미니프로젝트의 관계를 나타내는 구성연관표를 갱신한다. 이 구성연관표는 이후

시험을 위한 입력물로 사용된다.

⑥ 분산 구조 정제

물리적 네트워크의 구성에 변화가 생길 때와 프로세스의 물리적 노드 할당 구조가

변경되었을 때 분산구조를 보완한다. 소프트웨어가 실행되는 물리적 네트워크

구성에 변화가 있는지, 프로세스가 노드에 올바르게 할당되었는지를 검토한다.

시스템이 운영될 하드웨어 네트워크를 검토한다.

각 노드에서 실행되는 프로세스를 검토한다.

입력물/산출물

입력물 산출물

미니프로젝트정의서

설계명세서


미니프로젝트정의서(보완)

설계명세서(보완)

설계 검토의견서

아키텍처정의서(보완)


43 TTAS.KO.11.0015/R1

부록 : UML 용어 한글 표기

abstract class : 추상 클래스

abstraction : 추상화

Action : 활동

action expression : 활동식

action state : 활동 상태

Activation : 활성화

active class : 활성 클래스

active object : 활성 객체

activity diagram : 활동도

actor [class] : 행위자 [클래스]

actual parameter : 실매개 변수

aggregate [class] : 집단 클래스

aggregation : 집단화

architecture : 구조

argument : 인수

association : 연관화

association class : 연관 클래스

association role : 연관 역할

asynchronous message : 비동기 메시지

attribute : 속성

behavior model aspect : 행위 모형 측면

binary association : 이항 연관화

class : 클래스

class diagram : 클래스도

client : 클라이언트

collaboration : 협력

collaboration diagram : 협력도

communication association : 통신 연관화

component : 구성 요소

component diagram : 구성요소도

composite [class] : 복합 클래스

composite aggregation : 복합 집단화

composite state : 복합 상태

composition : 복합

concrete class : 구체 클래스

concurrency : 병행성

concurrent substate : 병행 하위 상태

constraint : 제약


44 TTAS.KO.11.0015/R1

dependency : 종속

deployment diagram : 전개도

derived element : 유도된 요소

development process : 개발 공정

diagram : 그림(도)

disjoint substate : 분리 하위 상태

distribution unit : 분산 단위

domain : 영역

dynamic classification : 동적 분류

element : 요소

enumeration : 열거형

event : 사건

export : 보내기

expression : 식

extends : 확장

fire : 촉발

focus of control : 제어 막대(활성화)

formal parameter : 형식 매개 변수

framework : 틀

generalization : 일반화

guard condition : 전이 조건

implementation : 구현

implementation inheritance : 구현 상속

import : 가져 오기

inheritance : 상속

instance : 인스턴스

interaction : 상호 작용

interaction diagram : 상호작용도

interface : 인터페이스

interface inheritance : 인터페이스 상속

layer : 층, 계층

link : 연결

link role : 연결 역할

message : 메시지

metaclass : 메타 클래스

meta-metamodel : 메타-메타 모형

metamodel : 메타 모형

metaobject : 메타 객체

metatype : 메타 유형

method : 메소드


45 TTAS.KO.11.0015/R1

model : 모형

model aspect : 모형 측면

model element : 모형 요소

module : 모듈

multiple classification : 다중 분류

multiple inheritance : 다중 상속

multiplicity : 다중성

n-ary association : 다항 연관화

namespace : 이름 영역

node : 노드

note : 주석

object : 객체

object diagram : 객체도

object lifeline : 객체 수명선

operation : 연산

package : 패키지

parameter : 매개 변수*

parameterized class : 매개 클래스

persistent object : 지속성 객체

postcondition : 사후 조건

powertype : 멱 유형

precondition : 사전 조건

primitive type : 원시 유형

projection : 투영

property : 특성

pseudo-state : 의사 상태

qualifier : 한정자

receive [a message] : 수신하다 [메시지]

receiver [object] : 수신자 [객체]

reference : 참조

refinement : 정제

relationship : 관계

requirement : 요구 사항

responsibility : 책임

reuse : 재사용

role : 역할

scenario : 시나리오

semantic variation : 의미 변이

send [a message] : 송신하다 [메시지]

sender [object] : 송신자 [객체]


46 TTAS.KO.11.0015/R1

sequence diagram : 순서도

signal : 신호

signature : 표시

single inheritance : 단일 상속

specification : 명세

state : 상태

state diagram : 상태도

state machine : 상태 기계

static classification : 정적 분류

stereotype : 스테레오 유형

string : 문자열

structual model aspect : 구조 모형 측면

subclass : 하위 클래스

substate : 하위 상태

subsystem : 하위 시스템

subtype : 하위 유형

superclass : 상위 클래스

supertype : 상위 유형

supplier : 제공자

swimlane : 활동 책임선

synchronous message : 동기 메시지

tagged value : 표지 값

template : 템플릿

thread [of control] : 스레드

time event : 시간 사건

time expression : 시간식

timing mark : 시간 표시

transient object : 임시 객체

transition : 전이

type : 유형

type expression : 유형 식

use case [class] : 사용 사례 [클래스]

use case diagram : 사용사례도

use case instance : 사용 사례 인스턴스

use case model : 사용 사례 모형

uses : 사용

utility : 유틸리티

value : 값

view : 뷰

view element : 뷰 요소


47 TTAS.KO.11.0015/R1

view projection : 뷰 투영

visibility : 가시성

표준작성 공헌자

표준 번호 : TTA.KO-11.0015.R1

이 표준의 제․ 개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분 성명 위원회 및 직위 연락처 소속사

과제

제안 장진호

S/W 컴포넌트프로젝트그룹(PG408

)

부의장

042-860-5274

[email protected] ETRI

표준

초안

제출

최성운 PG408 의장 031-330-6440

[email protected] 명지대

장진호

S/W 컴포넌트프로젝트그룹(PG408

)

부의장

042-860-5274


최윤정 선임

031-200-3475

[email protected]

m

삼성전자㈜

최유희 연구원 042-860-6389


하수정 선임 연구원 042-860-6095


표준

초안

검토 및

작성

김진삼 책임 연구원 042-860-5995


소영진 IT 응용 기술위원회 의장 [email protected] 한국전산원표준안

심의 외 기술위원회 위원

김선 팀장 031-724-0080

[email protected] TTA

사무국

담당 오선영 대리 031-724-0084

[email protected] TTA

정보통신(영문)단체표준

객체지향 소프트웨어 분석/설계 지침 (Guidelines for Object-oriented Software Analysis and Design)

발행인 : 김홍구

발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 서현동 267-2

Tel : 031-724-0114, Fax : 031-724-0019

발행일 : 2006.xx

t t a s t a n d a r d - committee.tta.or.kr...[그림 1] 객체지향 소프트웨어 개발...

Documents