객체지향기술과 컴포넌트기반개발 - dbguide.net · -david a. taylor:...

02/01/23 나희동([email protected]) - 1 -

객체지향 기술과컴포넌트 기반 개발

2002년 1월 23일

투이컨설팅 /CBSE팀

팀장/정보처리기술사

나 희 동

목 차


• 객체지향 개념 ……………………………………………………………………………… 3

• UML구성……………………………………………………………………………………. 10

• 객체지향 모델링…………………………………………………………………………… 22

• 반복적 개발 생명주기와 객체지향 개발방법론………………………………………… 47

• 패턴기술과 아키텍쳐 스타일………………………………………………………………55

• CBD 정의 및 개념………………………………………………………………………….63

객체지향 개념(1/7)


I. 객체지향 정의

- Rumbaugh: ‘객체란 한 어플리케이션 분야에서 의미를 갖는 어떤 것을 지칭한다.

모든 객체에는 일체성이 있고 서로 구별할 수 있다.’

- Jacobson: ‘객체란 상태(정보)를 저장할 수 있는 실체로서, 이 상태를 조사하거

나 영향을 미치는 여러 오퍼레이션(행동)을 제공한다. 보통 객체는 송장, 자동차, 또

는 이동전화 등과 같은 현실 세계 실체 객체와 대응한다.’

- David A. Taylor: 객체란 일련의 프로시져와 데이타 집합을 포함한 소프트웨어 팩

키지이다.

- 데이터와 프로세스와 같이 세부적인 시스템 특징보다 실제 시스템을 구성하는 객

체를 중심으로 시스템을 정의

II. 객체지향 개념 유래

– 1950년대 프로그래밍 기법으로 개발하여 80년대 설계기법으로 발전

– 1990년대 분석/설계 기법을 발전함.

– 모듈의 개념을 확장하여 동적인 시스템 구조화를 위하여 구현과 설계를 분리



III. 객체지향의 주요 특징

가. 추상화(Abstraction)

- 다양한 객체들의 공통성을 도출하여 클래스라는 그룹으로 다룰 수 있게 함.

- 모든 객체는 유일성이 있어 독립적인 식별이 가능함.

나. 캡슐화(Encapsulation)

- 구현과 사용을 독립시켜 상세한 내부 로직과 상관없이 인터페이스만으로 사용할 수있게 함.

- 한 클래스는 공통된 속성만으로 구성되어 통일되고 완전한 기능들로 구성됨.

다. 모듈화(Modularity)

- 복잡한 시스템을 관리가능한 단위로 분리하여 다룰 수 있게 함.

라. 상속성(Generalization)

- 계층적 추상화 수준 분할을 통해 다양하고 복잡한 시스템을 일반화 시킴.

- 하나의 일반화된 클래스를 상세화 하여 여러 클래스로 분할 하게 함.

IV. 객체지향의 주요 개념

가. 객체

- 독립적으로 식별가능하고 (Identity)

- 상태(State)와

- 행위(Behavior)를 갖고 있는 모든 실체



나. Class(클래스)

– 하나의 개념이 적용되는 객체의 집합을 클래스라고 하고 때로는 객체 클래스라고

도 한다.

– 한 클래스의 객체들에는 동일한 속성과 행동 유형이 있다. 그리고 의미상 공통적인

목적과 특성을 공유한다.

– 객체를 흔히 클래스의 인스턴스라고 한다.

다. Attribute(속성)

- 클래스의 상태유형을 속성이라 하고

- 이 클래스의 인스턴스인 객체의 실제 상태 값을 속성 값이라 한다.

:CourseOfferingnumber = 101startTime = 900endTime = 1100

:CourseOfferingName = 104startTime = 1300endTime = 1500

CourseOfferingnumberstartTime endTime

Class

Attribute

Object

Attribute Value



라. Operation(오퍼레이션)

- 한 클래스의 행동유형을 오퍼레이션이라 함.

- 실행과정에서 객체는 오퍼레이션을 통해 상태를 변화시킴.

마. Stereotype(스테레오타입)

- 하나의 추상개념을 여러 개의 모델링 개념으로 분류

- 모델링 과정의 공통적 이해를 위해 사용

- 모든 모델링 요소에 적용가능

CourseOffering

addStudent deleteStudentgetStartTimegetEndTime

Class

Operation

<<boundary>>

<<boundary>>

<<trace>>DesignClass



바. Component(컴포넌트)

– 독립적으로 의미 있는 대체 가능한 부품으로서 잘 구조화된 아키텍쳐에서 명확한

한 기능을 수행

– 물리적으로 배치(Deployment)가능한 시스템의 부품

– 논리적 관리단위의 팩키지(Package)와는 다른 개념임

– 컴포넌트 개념을 확장하여 비즈니스 컴포넌트를 정의하기도 함.

사. Generalization(일반화)

– 구체적인 클래스들의 공통성을 추출하여 부모클래스로 일반화 시키는 것

ComponentNameComponent

Interface

Trucktonnage

GroundVehicleweightlicenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1ancestor

decendent

generalization

size



아. Polymorphism(다형성)

– 하나의 인터페이스로 많은 다른 구현을 숨기는 능력

Client Contractor

SubcontractorA

operation1()operation2()

operation1()operation2()

SubcontractorBoperation1()operation2()

Sub-subcontractorB1operation1()operation2()

Sub-subcontractorB2operation1()operation2()

contractor

• Contractor는상속된클래스들의추상인터페이스(abstract interface)를갖는다.• Contractor는상속된클래스들로다형성행위(polymorphic behaviors)를제공한다.• Contractor는구현클래스들과클라이언트를분리하여서로독립적인변경을가능하게한다.



V. 객체지향의 장점

가. A single paradigm

• 사용자, 분석가, 설계자, 구현자가 모두 하나의 개념을 사용한다.

나. 아키텍쳐와 코드의 재사용 기반을 제공

다. 훨씬 실세계와 가까운 모델을 제공

• 실제 기업의 데이터와 프로세스를 훨씬 정교하게 묘사 가능.

• 자연적인 구분기준에 따라 분해가능

• 이해와 유지보수가 훨씬 쉬움

라. 안정성(Stability)

• 간단한 요구사항 변화가 개발중인 시스템에 엄청난 변화를 초래하지 않는다.

• 잘 구조화된 객체지향 시스템은 매우 견고한(Robust) 아키텍쳐를 제공한다.

VI. 객체지향기술의 활용

- 재사용성 높고 다양한 가변 요소에 강건한(Robust) 컴포넌트는 객체지향 설계가 필

요함.

- 개발 생산성 향상을 위한 기반 아키텍쳐 구성과 컴포넌트 기반 개발에 적극적으로 사

용되고 있음.


UML(Unified Modeling Language) (1/12)

Ⅰ. UML(Unified Modeling Language)의 개요

가. UML의 정의

• 시스템 분석과 설계 및 구현을 위한 공학적인 모델링 작업을 지원하는 통합 모델링

언어

• 구조적 분석기법, 데이터 모델링 기법, 기능중심 모델링 기법 등의 모든 공학적 모

델링 활동을 포함하는 표준 모델링 언어

•1995년 Grady Booch와 James Rumbaugh, Ivar Jacobson이 제안하여 OMG를 통

해 표준 모델링 언어로 지정됨.

나. UML의 목표

1) 사용자들에게 사용하기 쉽고 표현이 풍부한 시각적 모형화 언어 제공

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

3) 특정 프로그래밍 언어나 개발 공정에 종속되지 않음

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

5) 고수준의 개념 지원(Collaboration, 프레임 웍, 패턴, 컴포넌트)

6) 산업계의 검증된 최상의 경험을 통합



Ⅱ. UML의 구성요소

가. UML의 계층 구조

모델화된 시스템의 서로 다른 모형View

Diagram View의 내용을 표현하기 위한 Graph notation

Model Element Diagram에서 사용된 개념들의 모델 요소

General Mechanism 모델요소에 대한 주석, 정보, 의미

나. View

코드 구성의 체계를 파악할 수 있도록 보여줌Component

병렬 시스템과 같이 커뮤니케이션과 동기화가 필요한

시스템에서 동시성 제공

Process

시스템을 컴퓨터와 노드로 구성하는 물리적 배치 구조를 보여줌Deployment

시스템의 정적 구조와 동적 행위의 시점에서 시스템 내부에

설계된 기능성 제공

Logical

외부 행위자에 의해 인지 되어진 시스템의 기능성 제공Use Case

내 용View



다. Diagram

요구

분석

정의

단계

클래스 및 컴포넌트 간의 순차적인 흐름을 표현Sequence

클래스의 인스턴스인 Object간의 관계를 표현Object

객체가 갖을 수 있는 모든 상태의 변화를 표현State

시스템내 클래스의 정적인 구조 표현Class

시스템과 행위자 사이의 관계를 표현Use Case

내 용Diagram

설계

시스템의 흐름을 표현, 각 활동들의 제어 흐름 표현

동기화 사용

Activity

시스템을 실제 구현 상태로 가시화하고 명세화Component

시스템 하드웨어와 스프트웨어 간의 물리적인 구조와관계를 표현

Deployment

클래스간의 관련성을 특정관점에서 요약 표현Collaboration



Ⅲ. Diagram 별 기능 설명

가. 유스케이스 도(Usecase Diagram)

- 컴퓨터 시스템과 사용자의 상호 작용 표현

- 업무의 흐름과 사용자 요구사항을 정리하기 위해 표현



나. 클래스도 (Class Diagram)

- 시스템 내부에 존재하는 클래스들을 선별하여 표현하고 클래스별 속성(Attribute)

과 행위(behavior) 표현

- 클래스간 관계 표현 : 연관관계(Association) , 상속관계(Generalization),

의존관계(Dependency)

Plane Tracking System

Flight

+ Destination : char+ Departure : char+ Flight_Path : char+ Flight_Date : int+ Flight_Time : int+ Flight_Price : int+ Flight_Seat_Quantity_Free :int+ Flight_Number : int

Aircraft

Aircraft_Identification_CodeAircraft_TypeAircraft_SizeAircraft_ID

Fly(void)Land(void)Refuel(void)Take_Off(void)

persistent

Ticket

+ Airline_Name : char+ Ticket_Price : int+ Vendor_Name : int+ Flight_Date : int+ Flight_Time : int+ Flight_Number : int+ Ticket_Number : int

persistent

Flight_Reservation

+ Passenger_Name : int+ Flight_Date : int+ Flight_Number : int+ Reservation_Number : int

persistent

Pilot

Pilot_RankPilot_NamePilot_ID

Fly_Plane(void)Land_Plane(void)New_Attributes(void)

persistent

Ticket_Vendor

+ Booking_Confirmation :int

Check_Availablity(void)Confirm_Reservation(void)Book_Seat(void)

Commercial_Aircraft

Airline_NameWeightowns

Knowing_stall_speed(void)

Airline_Ticket_Vendor

Airline_NameAirline_Address

persistent

Military_Aircraft

Squadron_Number

New_Attributes(void)

persistent

Passenger_Plane

Steward_QuantitySeat_Number

persistent Travel_Agent

Vendor_NameVendor_Address

persistent

Cargo_Plane

Capacity

persistent

Airline

Passenger

1

1..* Has1

1

uses

1

1..*

is bookedwith

reservation number1

1..*

reserves flight

1

1..* owns

1..*

flight number1

schedules



다. 순서도 (Sequence Diagram)

- 상관도 함께 시스템의 동적인 면을 나타내는 다이어그램

- 시스템이 실행시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는

메시지를 표현

- 횡축을 시간축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 둠



라. 상관도 (Collaboration Diagram)

- 시퀸스 다이어그램과 함께 메시지의 흐름을 나타내는 다이어그램

- 객체와 객체들 사이의 관계까지 표기



마. 상태도 (Statechart Diagram)

- 한 객체의 상태 변화를 다이어그램으로 나타낸 것

- 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간

동안의 상태를 표시



바. 활동도 (Activity Diagram)

- 플로우챠트가 UML에 접목된 것

- 시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건

등을 모두 포함

- 어떠한 행위에 따라 객체의 상태를 표기할 수 있음


사. 배치도 (Deployment Diagram)

- 실제 하드웨어적인 배치와 연결상태를 나타낸 다이아그램




아. 컴포넌트도(Component Diagram)

- 소프트웨어의 물리적 단위(Exe, dll 등 기타 library)의 구성과 연결상태를 나타낸

다이아그램



Ⅳ. UML의 발전 전망

가. UML은 객체지향 소프트웨어를 개발하기 위한 풍부한 분석과 설계 장치를 제공하고

있으므로 향후 산업계의 표준으로 활용 예상

나. UML은 기존 데이터 모델링 언어 및 기능중심 설계, 실시간 설계 언어 등을 수용하고

있어 향후 모든 공학적 모델링 언어를 수용하는 통합언어가 될 것임.

다. 기존 모델링 언어를 포함하여 개발공정의 가시화 및 산출물의 통일성 등을 감안한

최적화 한 UML을 구축할 필요가 있음.

객체지향 모델링 (1/25)


I. 객체지향 모델링 관계도

- UML과 함께 CrC Cards, ERD, 요구사항 정의서 등이 함께 사용됨.

- 기존의 단계적 개발과는 달리 다양한 개발 프로세스 가변요소를

고려하는 체계적 메커니즘을 제공함.

Requirements Use Cases

User InterfaceScreens

CRC Cards

SequenceDiagrams

CollaborationDiagrams

Class Diagrams

Relational DataModel

Physical DataModels

RelationalDatabase

ObjectDatabase

ImplementationCodeInteraction Diagram

ComponentDiagrams

DeploymentDiagrams

ImplementationDiagram

State Diagrams

ActivityDiagrams

GUI design

Specify Business Process

Possible code transition

Code Generation

Round-trip engineering

Access Methods

Access Methods

(Object Diagram)



II. 객체지향 모델링 활동 단계별 구조

가. 다섯가지 객체지향 모델링 활동

1) 비즈니스 모델링

• 비즈니스 유즈케이스 모형과 비즈니스 클래스 모형을 작성함.

• 시스템 배경을 이해하기 위해 업무를 모델링 함.

• 활동도(Activity Diagram)와 CrC Card 등의 다양한 모델링 기법을 함께 사용함.

• 비즈니스 클래스 모형은 정보공학의 개념적 모형에 해당함.

2) 요구사항 분석

• 시스템 유즈케이스 모형을 작성함.

• 사용자 인터페이스 (UI 설계)를 포함하면 보다 명확한 요구사항 기술이 가능.

• 사용자 요구사항 기술을 주 목적으로 함.

• 다양한 비기능 요건과 확장가능성 등을 표현함.

• 시스템으로 구현하고자 하는 범위만을 명세화 함.

3) 시스템 분석 및 설계

• 아키텍쳐 설계 및 시스템의 구조를 모델링 함.

• 시스템의 특성에 따라 다른 모델링 접근을 시도해야 함.

– 실시간 시스템인 경우 동적모델링을 중심으로 해야 함.

– 데이터 중심 시스템인 경우 구조모델링을 중심으로 해야 함.

• 구현언어(Java or C++ 등)에 종속된 상세수준의 클래스 모형을 작성해야 함.



4) 시스템 구현

• 시스템 구조화를 위한 컴포넌트 도출과 배치관계를 모델링

• 구현작업 편의성과 시스템 관리 편의성을 위한 팩키지 관점 모델링

• 비즈니스 컴포넌트와 소프트웨어 컴포넌트 등의 관계를 명시해야 함.

• 시스템 아키텍쳐를 기술아키텍쳐, 소프트웨어 아키텍쳐, 컴포넌트 아키텍쳐등으로 상세화 해야 함.

• 구현환경을 고려한 클래스, 컴포넌트, 노드 간의 관련성을 표현하고 각 구성요소 들 간의 상호 호출관계를 모델링 해야 함.

• 좋은 코드는 가장 잘 작성된 설계 모델임.

5) 테스트

• 테스트케이스를 작성해야 함.

• 유즈케이스를 참조하여 단위 컴포넌트 관점의 테스트케이스 도출

• 유즈케이스 팩키지 관점의 통합 테스트 케이스 도출

• 유즈케이스 비기능 요건을 참조하여 시스템 테스트케이스 도출

• 유즈케이스 기능요건을 참조하여 인수테이스 요건을 도출



나. 모델링 활동간 관계도

- 각 모델링 활동의 효과적인 수행을 위해 다양한 모델링 기법 및 모델언어를 이용

하게 됨.

- 모델활동의 최종 결과로 조직의 성숙도 수준과 개발생명주기에 적절히 최적화 한

다양한 산출물을 작성함.

OKOKFail

Realized ByImplemented

ByVerified By

ImplementationModel

Test ModelDesign Model

Use-Case Model

Models

Core Process Workflows TestImplemen-

tationAnalysis &

DesignRequirements

Business Use-Case Model

Business Modeling

Business Object Model

BBB

B

Realized By

AutomatedBy



III. 관점별 객체지향 모델링 절차

가. 행위 중심 모델링(Behavior Driven or UseCase Driven Modeling)

1) 개요

- 사용자 요구사항 명세화 관점에서 이벤트모델링, 기능중심 모델링 등을 수행

- 정보공학의 기능구조도, 이벤트 모델링을 포함하는 유즈케이스 모형을 중심

으로 순서도(Sequence Diagram), 상관도(Collaboration Diagram) 등의 동적

모형을 통해 클래스를 도출

- 초보자가 객체지향 모델링을 학습하기 쉬우나, 실질적 생산성 향상이 어려움

- CrC Cards 등을 이용한 Responsibility Modeling 등을 함께 이용하기도 함

2) 유즈케이스 중심 모델링 절차

• 유즈케이스 모델링

– 행위자 파악

– 유즈케이스 도출

– 유즈케이스 기술서 작성

• 동적 모델링

– 순서도(Sequence Diagram) 작성

– 상관도(Collaboration Diagram) 작성

• 개념적 클래스 모델링

– 클래스 도출

– 클래스 모델(Class Diagram) 작성



3) 유즈케이스 모델링

– 행위자(Actor)는 시스템과 상호작용을 하는 모든 것을 말한다.– 유즈케이스(use case, 쓰임새)는 시스템이 행위자에게 제공하는 명확한 가

치를 생산하는 일련의 활동들을 말한다.– 유즈케이스는 기능이 아니라 프로세스 이다.– 좋은 유즈케이스는 시간을 소모하며 한번에 수행되는 일이다.– 유즈케이스 모델은 최종사용자와 개발자가 시스템 개발초기부터 상호 의

사소통 수단으로 활용한다.– 유즈케이스 모델은 시스템의 본원적인 목적을 도출하고 시스템의 단계적

개발전략을 도출하기 위해 활용한다.– 유즈케이스 모델은 시스템의 요구사항을 분석하기 위해 사용된다. – 유즈케이스는 문제기술서나 시스템정의서, 사용자 및 업무전문가와의 인

터뷰, 업무기술서, 개인적인 업무지식, 기존시스템 등을 참조해서 도출할

수 있다.

4) 유즈케이스 기술서

– 유즈케이스를 구성하는 기본적인 주요 사건흐름과 몇 개의 대안 흐름들

로 구성된 유즈케이스 시나리오를 중심으로 기술



– 유즈케이스 시나리오는 행위자와 시스템의 상세한 이벤트의 흐름에 해당.

1. 개 요프로젝트특성치를프로젝트관리자가메뉴선택으로결정한다.유형별로준비된개발사례 DB와개발지침 DB를사용해서프로세스산출물을작성한다. 프로세스산출물은전체프로젝트의프로세스를규정하고진행의지침이된다

2. 행위자 : 프로젝트관리자, 프로세스관리자

3. 쓰임새모형

3.1 쓰임새 : 프로젝트특성치결정

(1) 작업흐름프로젝트advisor에게선택사항입력입력된사항을모아 “프로젝트특성치(DATA)”작성“프로젝트특성치”를 프로젝트관리자가검토프로젝트관리자가검토후승인여부결정

(2) 대안흐름각 advisor의입력오류“프로젝트특성치(HTML)”를만족치못함

3.2 쓰임새 : 프로젝트유형결정

(1) 작업흐름“프로젝트특성치(DATA)”를 “개발사례DB”와 같은스키마로재구성재구성한 DATA를 “개발사례DB”에조회 (유사점찾기)일정률이상(예 : 60%) 비슷하면사례와 같은유형이라고표시산출물( “프로젝트유형(DATA)”)의작성

(2) 대안흐름“프로젝트특성치(DATA)”와비슷한사례가없다 (60% 미만의경우 )

3.3 쓰임새 : 프로세스산출물제작

(1) 작업흐름“개발방법론DB”에서 같은유형의개발방법론을조회“작업별프로세스DB”에서 같은유형의작업별프로세스를조회“개발도구DB”에서 같은유형의개발도구를조회“산출물정의DB”에서 같은유형의산출물을조회조회된내용을모아서산출물제작 (프로세스지침서)프로세스관리자검토후승인여부결정“개발사례DB”에새개발프로젝트로등록“프로세스지침서”를프로젝트관리자에게전달



5) 유즈케이스 시나리오

- 각 유즈케이스는

– 하나의 정상적이고 기본적인 사건의 흐름과

– 몇 개의 다른 대안 흐름들로 구성된다.– 보통 몇 개의 예외적인 사건들과 무수히 많은 대안 흐름들이 있다.

– 선행조건이나 후행조건 들이 있을 수도 있다.

6) 클래스 도출 방법

• 데이터중심 접근법

– 데이터 모형

– 실체 관계형 모형

– 관계형 데이터 모형

– 주제영역별 데이터베이스 설계

• 행위중심 접근법

– CrC 카드

– 동적모형



7) 동적 모델링

• 시간, 순서, 제어 흐름과 관계 있는 시스템 측면의 모형이다.

• 궁극적인 목표는 어플리케이션 도메인에서 각 클래스의 행동을 발견하고 문서

화하는 것이다.

• 중간에 다음과 같은 절차가 있다:

– UML Sequence

– UML Collaborator

– UML State

– UML Activity

• 유즈케이스 시나리오를 통한 동적 모델 도출

– 행위자와 기대하는 시스템 행동을 알 수 있는 시스템 사이의 대화를 묘사

한다.

– 주된 상호작용과 정보 교환을 보여준다.

– 먼저 ‘평범한’ 시나리오를 준비하고 그 다음에 오류상태나 응답이 없는

경우 등의 특별한 경우를 고려한다.



8) 책임 모델링(CrC Modeling)

• 여러 사람이 그룹으로 클래스의 동적인 흐름을 흉내내어 하는 토의식 역할 게임과 같다.

• 각 사람은 하나 이상의 클래스의 책임을 담당하고 다른 사람들과 서로 호출하고 특정 역할(오퍼레이션)을 수행하면서 주어진 일을 마친다.

• 분석단계 뿐만 아니라 설계단계에서도 사용할 수 있다.

• 시스템 도메인에 대한 이해가 다를 경우 공통적인 의견을 도출하기 위해 사용

한다.

Class Name Course

Responsibilities Collaborations

Add a student

Know where the course is held

Know when the course is held

Student

Know prerequisites

Service provided

Internal knowledge



나. 아키텍쳐 중심 모델링(Architecture Driven Modeling)

1) 개요

• 시스템 구현 초기에 기본적인 사용자 요구사항이 파악된 후에 아키텍쳐 설계를 시작할 수 있다.

• 유즈케이스 보다는 미래에 시스템특성에 영향을 줄 수 있는 Change Case를중심으로 설계해야 함.

• 도메인 유형별, 시스템 특성별로 참조 가능한 패턴(Best Practice Model)이 존재한다.

• 행위중심 모델링(UseCase Driven Modeling)과 구조중심 모델링(Structure Driven Modeling)을 연결하는 역할을 한다.

• 컴포넌트 기반 개발 프로세스와 연계하여 실질적인 생산성 향상과 품질 수준유지를 가능하게 한다.

2) 아키텍쳐 중심 모델링 절차

• 소프트웨어 아키텍쳐 모델링

– 아키텍쳐 평가기준 정립

– 대안 아키텍쳐 정의

– 대안 아키텍쳐 평가

– 최종 소프트웨어 아키텍쳐 결정



• 비즈니스 아키텍쳐 모델링

– 개념 클래스 모형 작성

– 비즈니스 컴포넌트 도출

• 시스템 아키텍쳐 설계

– 시스템 아키텍쳐 모형 작성

– 설계 템플릿 작성

3) 컴포넌트 식별

• 공통 유즈케이스, 배타적 공통 클래스에 대해 클러스터링 과정을 반복 하여 공통적인 아키텍쳐 구성 컴포넌트 식별

• 아키텍쳐 스타일, 유즈케이스를 참조하여 어플리케이션 계층 컴포넌트 식별

System-software

Middleware

Business-specific

Application-specificP1

P2

P3

P4

Application Layer

Business Layer

Common LayerE

F

A B C D



4) 소프트웨어 아키텍쳐 평가기준 정립

• 식별된 품질요소별로 중요도 및 우선순위를 부여하고 이를 토대로 아키텍쳐의평가기준을 정립

아키텍쳐품질요소식별

어떤시스템이나컴포넌트를얼마나쉽게변화시킬수있는가?

시스템이나컴포넌트를더큰규모나더넓은영역에서적용하도록할때용이한가?

시스템이얼마나빠르고효율적으로원하는기능을수행할수있는가?

특정시스템이나컴포넌트가사용요청을했을때동작할수있거나접근가능한정도는?

변경가능성 확장성

성능 가용성

특정시스템이나컴포넌트가설계된환경이아닌곳에서사용하기위해수정이용이한가?

유연성

당행업무는특수한데개선될수있나?시스템구축과정에서어떤일을해야하나?

유지보수성

특정시스템이나컴포넌트가다른시스템의개발에재사용할수있는가?

재사용성

특정컴포넌트를별도의코드수정없이다른컴포넌트로교체해도정상적으로동작하는가?

대체성



5) 대안 아키텍쳐 정의

• 아키텍쳐 스타일과 프레임워크를 참조하여 적절한 아키텍쳐 스타일을 선정하고 이를 통해 소프트웨어 아키텍쳐를 구성

• 하나 이상의 아키텍쳐 스타일이 복합적으로 사용됨

• 시스템의 주요 기능을 아키텍쳐 구성요소로 매핑하여 타당한 아키텍쳐를 결정

A pp R u le S y s tem< < F ram ew ork > >

F oundat ion< < F ram ew ork > >

A pp lic a t ion U I< < F ram ew ork > >

B us i n es s C o m p o n e n t< < F ram ew ork > >

D B M S

W A S

Legac yS y s tem

Application UI<<Framework>>

Foundation<<Framework>>

App Rule System<<Framework>>

Business Component<<Framework>>

DBMS

E vent Handling

LegacySystem

Repository ArchitectureLayered Architecture



6) 대안 아키텍쳐 평가

• 아키텍쳐 품질요소별로 대안 아키텍쳐의 장단점을 평가하여 최종 아키텍쳐를결정

• 대안 아키텍쳐별로 제약사항과 품질요소별 특성을 평가

• 시스템의 주요기능을 아키텍쳐 구성요소로 매핑

품질요소

성능

가변성

가용성

Add CORBA middleware in < 20 person monthsChange web user interfacein < 4 person weeks

Power outage at site1 requires

Restart after disk failure in < 5 mins

Network failure is detected andrecovered in 1.5 mins

Reduce storage latency

Deliver video in real time

traffic redirect to site2 in < 3 secs.

보안

on customer DB to 200 ms

Credit card transactions aresecure 99.999% of timeCustomer database authorizationworks 99.999% of time

Data Latency

TransactionThroughput

New product categoriesChange COTS

H/W failure

COTS S/Wfailures

Data

Dataconfidentiality

integrity



7) 설계 매커니즘 정의

• 아키텍쳐 최종 정의된 S/W 아키텍쳐를 구현하기 위한 지속성, 코딩방법, 프레임워크의 각 계층별 주요 용도 및 컴포넌트 캡슐화 방안, 재사용을 위한 컴포넌트 조정방법 등을 정의

S/W아키텍쳐 구현설계

기타 설계 메커니즘 정의

지속성 구현 방법 설계

가변성 구현 방법 설계



8) 설계 매커니즘 기술서 작성

• 구체적인 구현방법을 설명한 설계 메커니즘 기술서를 작성

load getConnection

aConnection

generateSQLgetSQL

getTableMappingTableMappings

SQLString

getDatabaseValuesResultSetofDBValues

newaName

MapAttributesconvertType

ConvertedTypeaName

: Name : PersistentObject : ConnectionManager : TableManager : TypeConverter : DatabaseComponents

load getConnection

aConnection

generateSQLgetSQL

getTableMappingTableMappings

SQLString

getDatabaseValuesResultSetofDBValues

newaName

MapAttributesconvertType

ConvertedTypeaName

: Name : PersistentObject : ConnectionManager : TableManager : TypeConverter : DatabaseComponents

P e r s i s t e n c y

D B M S

S t a t i s t i c sA n a l y s e r

L e g a c yS y s t e m

E v e n tM a i l e r

R e c u rt S y s t e m U I ( J S P )

A p p l i c a t i o n< < S B P a c k a g e > >

P e r s o n< < S B P a c k a g e > >

A n n o u n c e m e n t< < S B P a c k a g e > >

F o u n d a t i o n< < F r a m e w o r k > > W A S

I t e m S e r a r c h

B B S

A u t h o ri z a t i o nE r r o r H a n d l i n g

B u s i n e s s P r o c e s sC o m p o n e n t

지 속 성 메 커 니즘

을 적 용 하 여 코 딩

class MyDataQueryFactory implements DataQueryFactoryIF {

private static Hashtable classes = new Hashtable();

// populate the classes hashtable

static {

classes.put("INVENTORY", dataQuery.OracleQuery.class);

classes.put("SALES", dataQuery.SybaseQuery.class);

classes.put("PERSONNEL", dataQuery.OracleQuery.class);

classes.put("WHEATHER", dataQuery.JDBCQuery.class);

//...

}

public DataQueryFactoryIF createDataQueryImpl(String dbName) {

Class clazz = (Class)classes.get(dbName);

try {

return (DataQueryFactoryIF)clazz.newInstance();



9) 지속성(Persistency Mapping) 구현 방법 설계

• 데이타베이스(DBMS)에 지속성 관리를 요청하는 클래스의 수준에 따라 다음과 같이 나누어 설계를 해야 함.

– 객체지향형 지속성 메커니즘

– 객체관계형 지속성 메커니즘

– 관계형 지속성 메커니즘

Attribute MappingMethods

Type Conversion

Persistence Layer

OID ManagerTransaction

Manager

TableManager

ConnectionManager

SQL CodeDescription

ChangeManager

CRUD

사용값을 할당

키를 생성

변화를 관리

제공

트랜잭션관리

테이블명 획득

테이블명 획득연결 시 사용

필요 시 사용

생성

Attribute MappingMethods

Type Conversion

Persistence Layer

OID ManagerTransaction

Manager

TableManager

ConnectionManager

SQL CodeDescription

ChangeManager

CRUD

사용값을 할당

키를 생성

변화를 관리

제공

트랜잭션관리

테이블명 획득

테이블명 획득연결 시 사용

필요 시 사용

생성



10) 가변성(Variability) 구현 방법 설계

• 아키텍쳐의 가변 요구사항과 기본 아키텍쳐에서 수용하지 못하는 기능 요구사항 및 비기능 요구사항에 대한 구현 방법을 설계

• 다양한 디자인 패턴 등을 활용

B

A

B3

B2B1

Configuration ConfigLoadStrategy

ConfigLoadStrategyFile ConfigLoadStrategyDB

1..n1



11) 시스템 아키텍쳐 정의

• S/W 아키텍쳐를 포함하는 시스템아키텍쳐를 확정함.

• 요구사항정의 단계의 개발전략수립 활동에서 분산, 지속성, 보안, 구현을 고려한 기술아키텍쳐를 토대로 시스템 아키텍쳐를 확정

• 시스템 아키텍쳐는

비즈니스 컴포넌트 아키텍쳐 +

소프트웨어 아키텍쳐 +

기술아키텍쳐

로 구성됨

12) 데이터 모형 설계

• 개념적 객체모형을 토대로 지속성 클래스를 정의하고 개념적 실체관계도(ERD)를 생성

• 지속성 아키텍쳐를 고려하여 지속성 계층을 설계

• 비즈니스 컴포넌트 아키텍쳐를 고려하여 데이터 모형 설계

• 논리적 데이터 모형의 정규화 작업과 함께 물리적 수준의 비정규화 작업을 수행함. 이는 시스템 아키텍쳐가 이미 확정되어 있어 별도의 논리적 수준 데이터모형이 필요 없음을 의미함.



13) 지속성 클래스 설계

• 개념적 객체모형을 토대로 지속성 클래스(Persistent Class)를 정의하고 개념적 실체 관계도(ERD)를 생성

AddressName*1 *1

has

DatabaseComponentsTableManager

ConnectionManager

OIDManager

PersistentObjectobjectIdentifierisChangedisPersistedowningObject

save()delete()load()loadAll()loadAllLike()

**

**

**

TypeConverter

**

JD B C Q u e ry

O ra c le Q u e ry S y b a s e Q u e ry

D a ta Q u er y F a c t o ry IF

c re a te D a ta Q u e ryIm p l ( )D a ta Q u e ry

f a c to ry : D a t a Q u ery F ac t o ry IF

s e tF a c to ry()D a ta Qu e ry( )

D a ta Q u e r y I m p l IF

M y D a t a Q u e ry F a c t o ryc la s s e s : H a s h ta b le

c re a te D a ta Q u e ryIm p l ( )



다. 구조 중심 모델링 (Structure Driven Modeling)

1) 개요

• 개념 클래스 모형을 토대로 구현환경을 고려한 실제 실행 가능한 클래스로 설계한다.

• 아키텍쳐 모형을 근간으로 하여 클래스 모형을 작성한다.

• 유즈케이스를 통해 행위모형과정에서 도출한 동적모형과 상호 보완적인 모델링 작업을 한다.

• 물리적인 클래스와 1:1 대응한다.

• 실제 프로젝트에서는 구현기술과 개념적 클래스 모형과의 관계 이해를 돕기위해 리팩토링(Refactoring), 왕복공학(Round-trip Engineering) 등을 이용한다.

• 설계 수준의 CrC모델링이나 동적 모형을 이용하여 관련 클래스간의 관계를 모델링 할 수 있다.

2) 아키텍쳐 중심 모델링 절차

• 클래스 도출

– 데이터 모형을 중심으로 클래스 도출

– 유즈케이스 기술서를 토대로 클래스 도출

• 개념클래스 모형 작성

• 구현 수준 클래스 상세 속성 설계

• 컴포넌트 도출 및 구현 모델 작성



2) 클래스 모델링 절차

• 전체 클래스 정의

• 전체 연관성 정의

• 클래스 속성 정의

• 클래스 오퍼레이션 정의

3) 개념 클래스 모델링

• 객체 모형은 설계 구축의 기본틀이 된다.

• 분석단계에서는 객체모형의 오퍼레이션 들을 나타내지 않는다.

• 설계자는 동적 모형의 행위(Action)들과 활동(Activitie)들, 전이(Transition) 등을 클래스의 오퍼레이션으로 변환해야 한다.

4) 구현 모델링

• 팩키지 정의

• 클래스들을 몇 개의 그룹으로 분류하는 메커니즘.

• 여러 개발 도구 들이 팩키지를 물리적인 클래스 들의 구성단위로 사용한다. 예를 들어 자바 클래스들이 팩키지로 묶이는 것을 들 수 있다.

• 소프트웨어의 논리적인 묶음

» 예: *.cab, *.zip, *.jar



• 컴포넌트 정의

• 잘 정의된 인터페이스를 가진 소프트웨어 모듈

• 소프트웨어 모듈로 묶인 관련 클래스 들의 그룹

• 컴포넌트는 소스코드 이거나 이진코드 또는 실행 모듈일 수 있다.

• 소프트웨어의 물리적인 인식 단위

» 예: exe, dll, main programs, headers, modules, forms

5) 컴포넌트 모델링

• 코드의 구조 즉 소프트웨어 컴포넌트 들간의 의존관계를 나타낸다.

• 소프트웨어 컴포넌트 들을 그룹 하는 팩키지를 도출하기 위해 사용한다.

• 다음 과정을 통해 작성한다.

• 클래스 모델을 검토

• 팩키지를 결정

• 클래스 모델을 팩키지의 관련성을 추가하여 수정

• 컴포넌트들을 그룹화 함

• UML Component Diagram 을 작성

• 팩키지와 컴포넌트 들간의 관련성 표시

• 컴포넌트 들간의 관련성 표기

• Component diagram은 클래스와 객체들이 어떻게 컴포넌트로 구현되는지를보여준다. 또한 컴파일 시의 의존관계도 보여준다.



6) 배치 모델링(Deployment Diagram)

• 배치도 작성절차

• 어플리케이션 아키텍쳐를 검토하여 결정한다.

• 개발환경을 검토한다.

• 개발환경에서 팩키지와 컴포넌트를 적절한 노드로 할당한다.

• UML Deployment에 노드를 그리고 컴포넌트와 팩키지를 할당한다.

• 실행 시 시스템의 구조를 도식화 한다.

• 실행 프로세스와 소프트웨어 컴포넌트, 프로세스, 라이브러리 등을 기술한다.

• 물리적인 노드와 기존의 시스템 들간의 관계를 표현한다.

• Deployment diagrams은 실행 시에 존재하는 컴포넌트 들만을 표시한다.

• 컴파일 시나 링크작업 시에 존재하는 컴포넌트를 표현하는 것은 아니다.

• 한 노드에서 다른 노드로 이주하는 컴포넌트 들도 표현할 수 있다.

IV. 객체지향 모델링 현안

– 웹기반 소프트웨어 개발 환경에서 설계의 현실성때문에 객체지향 모델링이 선호됨.

– 향후 기존 정보공학 중심 모델링 등을 포괄적으로 수용하는 통합 객체지향 모델링이 선호될 것임.

– 컴포넌트 기반 개발프로세스의 성숙으로 객체지향 모델링이 부각됨.

– 아키텍쳐 중심 개발생산성 향상을 위해 객체지향 모델링이 중요시 됨.

반복적 개발생명주기와 객체지향 방법론(1/8)


I. 배경

가. 단계적 개발생명주기 한계

• 기존 단계적 개발생명주기(Waterfall Lifecycle Model)의 프로세스 가시성결여와 비현실성으로 새로운 개발 생명주기가 필요함.

• 90년대 초부터 전세계 개발자들은 반복적 개발생명주기를 변형한 In-house Methodology를 주로 사용하였음.

• 단계적 개발생명주기에서는 유사한 프로젝트를 반복 수행할 때 지식의 재사용 수준이 낮음.

Risk

Iterative Development

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration Post-deployment

Waterfall

Time



• 개발 초기단계에서 실제적 위험을 발견하지 못하여 시스템 구축단계에서 비현실적 개발일정을 수립하게 됨.

나. 단계적 개발생명주기와 반복적 개발생명주기 생산성 비교

Demo

Demo

시간(Months)

진척율(% Coded)

1009080706050403020

10

폭포수생명주기

Late DesignBreakage

5 25 30 35 40 45 501510 20

Demo

반복적생명주기

Final Qual Test Final Qual Test

Integration Begins

폭포수 vs 반복적



II. 반복적 개발생명주기 모형

가. 나선형 모형

• Bohem이 제안한 나선형 개발생명주기 모형은 개발과정에서 각 단계마다 위험요인을 분석하고 이를 적극적으로 완화하면서 개발을 진행하는 것임.

• 실제 프로젝트에서 기술적 위험, 공정상 위험, 조직적 위험, 업무적 위험 등의실제 위험을 구체적으로 밝혀내고 적극적인 대책을 수립하는 것이 관건임.

계획수립위험분석

엔지니어링

구축과 양도고객 평가

고객과의커뮤니케이션



나. 반복적 컴포넌트 어셈블리 모형

• 기존 반복적 개발생명주기에 컴포넌트 리파지토리를 근간으로 컴포넌트 조립을 통해 시스템을 구축하는 변형된 반복적 개발생명주기

• 컴포넌트 기반 개발 프로세스에 적용 가능함

계획수립위험분석

엔지니어링구축과 양도

고객 평가

고객과의커뮤니케이션

예상컴포넌트 들을

식별한다.

시스템의 n번째반복을

구성한다.

라이브러리에새로운 컴포넌트들을 삽입시킨다.

라이브러리에서컴포넌트 들을

찾는다.

이용 가능한컴포넌트 들을

추출한다.

이용할 수 없는컴포넌트 들을

구축한다.



다. 통합 개발 프로세스(Unified Process) 모형

• 반복적 개발 생명주기를 근간으로 작업단계와 주요 활동을 2차원으로 구성하여 프로세스 가시성을 높임.

• 실제 국내환경에서 이해가 쉽지 않고 조직 수준에 따라 프로세스 조정이 필요함.



III. 반복적 개발생명주기 적용

가. 개발 프로세스 현실화

• 기존 단계적 개발 생명주기 수행과정에서 실제 작업 수행내용과 개발공정상의표현내용이 다름.

• 실제 개발과정의 위험요소를 공정상에 표현해야 함.

• 반복적 개발생명주기를 사용할 경우 개발과정에서 프로젝트 관리자 들이 적극적인 공정관리 및 진척관리를 해야 함.

나. 개발생산성 향상

• 개발초기에 위험요인 파악과 이의 제거를 위한 적극적인 노력이 선행되어야생산성 향상을 기할 수 있음.

• 개발과정의 각 반복과정에서 재작업 부분을 최소화 하고 각 반복과정의 기준선 관리를 위해 아키텍쳐 중심 접근방법이 필요함.

• 행위중심 모델과 별도로 아키텍쳐 중심 접근 방법을 혼용해야 함.

다. 체계적 지식재사용 리파지토리 구축

• 재사용 가능한 컴포넌트 리파지토리를 구축해야 함.

• 각 비즈니스 컴포넌트들의 도출기준과 관리기준을 명시해야 함.

• 구현 아키텍쳐에 소프트웨어 아키텍쳐 정제작업을 통한 공통 프레임웍을 구축해야 함.



IV. 개발 생명주기 관련 현안

가. 프로세스 성숙도 모형과 개발생명주기 연계

• 미국 CMU에서는 CMM의 성숙도 향상을 위한 개인 수준의 프로세스 성숙도향상 모델로 PSP Framework을 제시하였으며, 이 프레임웍은 반복적 개발생명주기를 기반으로 만들어 짐.

• PSP에 따르면 Level3 수준에서 반복적인 개발을 적용할 수 있음.

• 조직의 프로세스 능력수준에 따라 초기에는 단계적 개발생명주기에서 높은 수준이 될수록 반복적 개발생명주기를 적용하게 됨.

Disciplined Cyclic DevelopmentLevel 3

Personal Quality ManagementLevel 2

Personal Planning ProcessLevel 1

Baseline Personal ProcessesLevel 0



나. 단계별 계약제도 필요

• 반복적 개발 생명주기 정착을 위해서는 프로젝트 단계 구분을 프로세스 중심으로 구분하기 보다 제품의 위험요인 완화수준을 중심으로 구분해야 함.

• 프로젝트 범위 확정 및 요구사항 도출

• 기반 아키텍쳐 개발과 컴포넌트 도출 완료

• 상세 컴포넌트 설계와 구현 완료

• 단계별 계약이 가능하도록 계약제도 변경이 필요함.

• 사업수행자와 별도로 프로젝트 공정관리 조직(Software Process Engineer) 및 아키텍쳐 관리조직(System Architect)을 별도로 계약함이 바람직 함.

• 감리컨설팅과 연계하여 프로젝트 진행 중에 진행감리 분야를 확대함이 필요.

다. 컴포넌트 기반 개발 프로세스 등장

• 실행 시에 컴포넌트 단위의 재사용과 대치성을 강화한 컴포넌트 기반 개발 프로세스(Component Based Development)가 등장함.

• 재사용 컴포넌트 리파지토리를 근간으로 한 반복적 개발프로세스가 필요.

• 소프트웨어 프로세스 성숙도 수준이 높아 갈수록 반복적 개발 생명주기의 효용이 커짐.

패턴기술과 아키텍쳐 스타일 (1/8)


I. 개요

가. 배경

• 재사용성이나 확장성을 고려하지 않은 설계를 바탕으로 구현한다면 변동사항이나 추가요구사항을 처리할 때 다시 디자인하는 최악의 경우가 발생할 것임. 따라서 가장 이상적인 경우는 자신이 설계했던 디자인 구조를 다시 수행할 솔루션에최대한 적용하는 것임.

나. 패턴기술 필요성

• 초보 개발자의 교육

• 개발자 간의 의사소통 역할

• 재사용성 및 유지보수성의 증대

• 객체설계 기술의 이론화

• 단순한 개발프로세스만으로 전문가를 양성하는 것은 불가능함.

다. 패턴언어(Pattern Language)

• 패턴들간의 관계를 명시하고 이들 패턴들을 이용하여 시스템을 체계적으로 설계할 수 있게 패턴언어를 기술하는 방법

• 패턴을 통해 표현하려는 추상수준에 대해 일련의 패턴들 간의 관계와 각 패턴들을 사용하는 방법을 설명

• 컴포넌트나 시스템의 상세설계, 업무이해와 비즈니스 컴포넌트 정의, 아키텍쳐 기술 등과 같은 각각의 추상수준에서 핵심적으로 기술해야 할 메터개념(Meta Concept)을 명시

• 87년 OOPSLA 컨퍼런스에서 제시됨.



II. 패턴 분류

가. 디자인패턴(Design Pattern)

• 시스템 설계과정에서 적용할 수 있는 패턴으로 고수준의 객체지향 클래스 구조를 재사용할 수 있게 함.

• 객체지향 프로그래밍 기술을 증진시킴.

패턴 이름 패턴 검색을 위한 색인

의도 패턴의 역할 및 제안된 의도, 설계 시 고려사항

별칭 패턴의 다른 이름

동기 기존 분석, 설계시의 문제점 및 패턴내의 객체들의 문제 해결 방법을 시나리오로 제공

적용 패턴이 적용될 수 있는 상황

구조 OMT의 표기법(class diagram) 및 object interaction diagram 사용

참여자들 패턴에 참가하는 객체들과 responsibility 기술

상호 협동 패턴 구성 요소들이 역할 수행 방법 소개

결과 패턴을 사용함으로써 얻는 장단점 기술

표본 코드 C++ 또는 Smalltalk



나. 분석 패턴(Analysis Pattern)

• Analysis 패턴 및 Supporting 패턴으로 구성됨

• 특별히 정의한 패턴 기술 포맷이 없음

– 자연어로 패턴의 이름, 적용이 필요한 상황을 설명

– UML-like 표기법을 사용하여 제안된 패턴의 구조 및 행위를 설명

– 1~2문장으로 기술된 “example”을 제안

• 비즈니스 모델링 과정에서 적용할 수 있는 패턴으로 기존의 데이터 모델링 등에서 활용하던 데이터 모델 패턴들을 확장한 개념으로 이해할 수 있음.

• Enterprise Modeling 등과 같이 새로운 업무적 메타모델을 정의하기 위해 활용됨.

• 분석패턴의 학습을 통해 새로운 업무영역에 대한 이해속도를 증진시킬 수 있음.

• 비즈니스 컴포넌트 도출 등에 사용하여 표준적인 비즈니스 아키텍쳐 설계를이룰 수 있음.

패턴 이름, 의도, 동기, 상황 자연어로 기술

구조 및 행위 UML-like 한 표기법을 사용

예제 1~2 문장으로 구성된 2~3개의 예제를 제시



다. 아키텍쳐 패턴(Architecture Pattern or Architecture Style)

• 소프트웨어 아키텍쳐 설계과정에서 재사용할 수 있는 표준적인 구조

• 아키텍쳐 스타일(Architecture Style)을 확장하여 다양한 설계지침을 포함함.

이름 및 별칭 Gamma 패턴의 이름 및 별칭과 동일

예제 실제 예제를 통하여 패턴의 제안 이유 설명

문맥 패턴이 적용되는 상황 설명

문제 패턴이 적용될 수 있는 문제들 언급

해결책 패턴이 기반하고 있는 문제 해결 원리 기술

구조 OMT 클래스 다이어그램 및 CRC 카드 기술

동적 행위 Object Message Sequence Chart 이용 기술

구현 패턴 구현 지침 설명

고려 사항 해결책에서 언급되지 않은 문제 해결 시 중요 고려 사항

변종 패턴의 전문화(specialization) 및 기존의 변종 기술

알려진 사례 기존의 사례를 통하여 알려져 있는 패턴 사용방법

결론 패턴이 제공하는 장단점 및 발생할 수 있는 문제점

참고 비슷한 종류의 문제를 다루는 다른 패턴 소개



라. 프로세스 패턴(Software Process Pattern)

• 소프트웨어 프로세스를 재사용할 수 있게 표준 템플릿을 제공하기 위해Ambler에 의해 제시됨.

• 통합 프로세스 관리 체계가 수립되기 위해 필요할 것임.

• 소프트웨어 개발과정에서 사용될 수 있는 개발프로세스의 핵심 모듈을 제시

• 개발생명주기, 단계, 활동, 작업 등의 프로세스 수준별로 상세화 되어 있지 못함.

• 기존 방법론 정립과는 다른 재사용 개발 프로세스만으로 이해해야 함.

패턴 이름 패턴 이름 및 개략적 설명 포함

초기 사용 상황 패턴 적용을 위한 초기 상황 및 패턴 적용을 위한 조건을 자연어로기술(pre-condition)

해결책 패턴 적용 방식을 상세하게 기술

사용 후 상황 패턴 적용이 끝난 후의 조건을 자연어로 기술(post-condition)

체크리스스 패턴 적용이 끝난 후 성공적인 적용 여부를 검사하기 위한 체크리스트



III. 패턴의 적용

가. 소프트웨어 아키텍쳐 설계

• 아키텍쳐 스타일 이나 아키텍쳐 패턴을 통해 기본 아키텍쳐와 대안 아키텍쳐를 설계함.

• 기 구축된 클래스들을 리팩토링(Refactoring)과 재구조화(Restructuring)를 하기 위해 아키텍쳐 패턴을 이용.

• 소프트웨어 아키텍쳐상의 단위 컴포넌트 및 아키텍쳐 상의 구현요소 들의 상세설계를 위해 디자인 패턴과 아키텍쳐 패턴을 적용하여 설계 메커니즘을 제시함.

나. 객체지향 컴포넌트 설계

• 디자인 패턴을 통해 재사용성 높고 요구변화에 강건한(Robust) 컴포넌트를 설계.

• 분석패턴을 통해 비즈니스 컴포넌트 도출 및 설계과정에서 강건한 컴포넌트를개발할 수 있음.

다. 소프트웨어 생산기술의 재사용 체계수립

• 아키텍쳐, 컴포넌트, 재사용 모델 등을 포함하는 패턴 카다로그(Pattern Catalog)를 구축하여 재사용 체계를 수립할 수 있음.

• 패턴 기술을 통해 체계적인 소프트웨어 생산기술 관리가 가능함.

• 조직의 소프트웨어 개발기술을 개인수준에서 조직수준의 통제가 가능하게 함.

• 짧은 개발일정에서 고수준의 품질을 달성하기 위한 커뮤니케이션 기반제공.



IV. 패턴기술의 확장

가. 프레임웍(Framework)• 재사용 가능한 설계 구조와 이를 구성하는 클래스• 프레임웍은 특정 도메인에 상관없이 필요한 시스템에서 적용가능• 여러 개의 디자인 패턴을 통해 구현됨.• 소스코드에 직접 적용시킬 수 있을 만큼 디자인패턴 보다 구체적임• 예를들어 분산시스템 구축패턴, 동시성 프로그래밍 패턴 등을 들 수 있다.• 산업화 된 프레임웍으로는 IBM’s SanFrancisco, DPVER, FACE, TaLE,

FOIBLE, ET++ 등이 있음

나. 툴킷(Toolkit)• 범용적인 기능을 제공하도록 설계된 재사용성이 강한 클래스 라이브러리• 객체지향개발에서 어플리케이션은 하나이상의 툴킷을 활용함• 예를 들어 C++의 MFC나 Java의 Swing, JWL 등의 패키지 단위의 컴포넌트를

들 수 있음• 툴킷은 어플리케이션에서 구현되어야 할 기능을 대신 제공하므로 재사용성을

신중히 고려해서 개발해야 함. 따라서 디자인 패턴 등을 적용함

다. 비즈니스 컴포넌트 아키텍쳐

• 향후 도메인 아키텍쳐 표준 개발에 패턴기술을 적용해야 함.

• 국가적으로 재사용 가능한 패턴 개발에 적극 노력해야 함.

• 기존의 데이터 모델 템플릿 등과 관련한 제품(Product)중심 기술재사용 연장선으로 이해할 수 있음.



라. San Francisco Architecture

• 3개의 계층별로 사용자의 요구를 유연하게 수용할 수 있는 프레임웍을 제공함.

• 각 계층에는 일련의 컴포넌트 들이 팩키징 되어 있으며 적절히 패턴화 되어있음.

Solu

tion

Plat

form

(ISV) Application

Software

Finan-cials

Hardware/OS Platform

Servers:Clients: Lotus Notes Java/HTML OLE Others

AIX Windows NT OS/400 HP-UX Others

100

% C

usto

mer

Sol

utio

n

~ 60

%~

40%

Java Virtual Machine

IBMSan Francisco

Foundation

Common Business Objects

Core Business ProcessesLedger

Finan-cials

Logis-tics

Ord Wrh

HumanRess.

Hum.Res.

Manufac-turing

Manufact.

CostAccount.

Cost Acc.

OtherAppli-

cations/

Add.Frame-works

OtherAppli-

cations/

Add.Frame-works

CBD 정의 및 개념(1/4)


I. CBD 배경

가. CBD 유래

• 80년대 등장한 객체지향적 분석/설계 개념과 구조적 방법론, 정보공학 방법론의 개념을 수용하면서 새로운 웹 기반 개방형 아키텍쳐를 수용하려는 소프트웨어 공학적인 접근

• 기능적으로 응집력이 강하고 모듈간 상호작용이 최소화되어 대형시스템의 구축 및 유지보수에 재사용성과 대치성이 높은 체계적이고 공학적인 설계 절차

• 기존 객체지향적 분석/설계에서 상속을 제하고 인터페이스 중심 접근을 강화하여 컴포넌트 위주의 재사용 프레임웍

나. CBD 정의

• 인터넷 시대의 성공적인 기업이 필요로 하는 경영혁신, 신속한 사업기회의 포착, 관련기업 들과의 커뮤니케이션 등을 지원하기 위한 정보시스템의 구축전략

• 컴포넌트 단위의 개발, 조립, 유지보수를 통해 현대경영이 필요로 하는 정보시스템의 신속한 구축, 변경확장의 용이성,타 시스템과의 호환성을 달성하고자하는 소프트웨어 프로세스, 방법론 및 기술의 총체적 개념

- 삼성SDS 박준성 상무 -

• 컴포넌트를 중심으로 웹 기반 개방형 아키텍쳐 상에서 재사용성과 유지보수성, 생산성을 극대화하려는 소프트에어 공학적인 노력



II. CBD 기본 프로세스

가. 프로젝트 정의

– 업무영역 분석, 프로젝트 범위 정의, 비즈니스 모형작성

나. 아키텍쳐 설계

– 소프트웨어 아키텍쳐 개발, 재사용 컴포넌트 조사, 컴포넌트 아키텍쳐 설계

다. 컴포넌트 개발 및 통합

– 단위 컴포넌트 개발과 조립을 통한 시스템 통합

라. 시스템 인도

컴 포 넌 트

추 출도 메 인 분 석

컴 포 넌 트구 현

도 메 인 설 계컴 포 넌 트

설 계

컴 포 넌 트인 증

컴 포 넌 트배 포

컴 포 넌 트특 화

C BD설 계

애 플 리 케 이 션요 구 사 항

컴 포 넌 트 조 립

R etrieva l/Exp lanat ion

C lassificat ion

Configurat ion M anager

C om ponen t D esig n P a ttern

N ewApp lication

컴 포 넌 트개 발

컴 포 넌 트 기 반 의소 프 트 웨 어 개 발



III. CBD 적용 및 확장

가. 필요성

– 기존의 정보공학 방법론은 웹 기반 아키텍쳐를 지원하는 설계 개념이 없음.

– 객체지향 시스템 개발은 수준 높은 코드를 만들기 위해 초기 투입비용이 너무 크며지속적인 재사용 전략이 없음.

– 관련 업계나 도메인 단위의 재사용 전략이 없음.

– 시장의 변화를 리드하기 위한 IT차원의 기술적 기반은 컴포넌트 수준의 규모가 비교적 크고 독립적인 운용이 가능한 단위의 재사용 전략이 필요함.

나. 조직 수준별 CBD 적용방안

– 대부분 조직은 초기에는 UI컴포넌트 등의 구현 컴포넌트를 중심으로 재사용 체계를 구축함.

– 비즈니스 수준의 컴포넌트는 소프트웨어 아키텍쳐와 같은 기반 플랫폼이 제공되어야 함.

– 국내 대부분의 조직은 컴포넌트 기반 개발 프로세스의 핵심 역량인 반복적 개발 프로세스를 수용할 능력이 되지 못함.

– 재사용성 높고 요구변화에 강건한 객체지향 컴포넌트를 구현하기 위해서는 다양한패턴, 프레임워크, 아키텍쳐 스타일 등에 대한 노력을 기울여야 하나 이러한 기술은 조직의 프로세스 성숙도 수준이 CMM 2레벨 이상에서 가능함.

– 반복적 개발 프로세스는 CMM 3레벨 이상에서 팀 단위의 적용이 가능함.

– 국가적인 차원의 프로세스 성숙도 향상을 위한 노력이 필요하며, CBD를 이를 주도하기 위한 견인차로 이해해야 함.



다. Product Line

• 비즈니스의 변화를 수용하려는 공통 컴포넌트 기반 소프트웨어 개발기술로서다음과 같은 소프트웨어 개발관리 조직을 제안함

• 소프트웨어 아키텍쳐를 근간으로 체계적인 생산성 향상과 비즈니스 연계를 위한 조직적 기반을 제시

Marketers CustomerProduct linecapabilities

Requirements

Product capabilities

Asset capabilities

Systems

Customer needs

Core AssetsGroup

• understand domain• understand application• design with ease & skill• can abstract• are technically current• can mediate

Product ProductionGroup• understand application• understand customer problems• can engineer from

“building blocks”• can customize• have implementation expertise

develop assets choose assets

Assets

ManagersDirect vision Detailed

requirements

객체지향기술과 컴포넌트기반개발 - dbguide.net · -david a. taylor:...

Documents