객체지향 CBD 개발 - pds10.egloos.compds10.egloos.com/pds/200901/14/88/a0105788_496df5c76ab77.pdf · 구현의산출물은프로그래밍언어(Java, C# 등)로표현된프로그램소스코드

One Step Ahead

객체지향객체지향 분석분석 및및 설계설계대학 정보시스템 개발을 통한 J2EE 이해

김상일

[email protected]

객체지향과 CBD 개요객체지향 기본 개념

CBD 개요

컴포넌트와 클래스

요약

3객체지향 분석 및 설계

- One Step Ahead -

Copyright ⓒ NEXTREE SOFT CO., LTD., 2007, All Rights Reserved.

1. 1. 시스템시스템 개발환경개발환경

J2EE 플랫폼 .NET 플랫폼

운영체제 Windows 2000 Professional

웹 애플리케이션 서버 BEA WebLogic 6.1IIS 5.0

.NET 프레임워크

DBMS MS SQL Server 2000

CASE 도구Rose 2002

Together 6.0

개발 도구

Rose 이용시 : JDK 1.3.1

Together 이용시 : Together 자체의 개발 환경 이용

Visual Studio.NET


- One Step Ahead -


2. CBD 2. CBD 개요개요CBD(Component Based Development)는 시스템을 구성하는 컴포넌트를 조립하는 방식으로 시스템을 구축하는 개발 방법을 말한다.

컴포넌트명확히 정의된 하나 이상의 인터페이스가 있는 소프트웨어의 부분

[Peter Herzum and Oliver Sims, 『Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise』(John Wiley & Sons, Incorporated, 1999)]

독립적으로 개발되고 배포되는 단위로써 조립/교환이 가능한 응집도가 높은 소프트웨어 산출물 [D.F.D’ Souza and A.C. Wills, 『Objects, Components, And Frameworks with UML – The Catalysis Approach』(Addison-Wesley, 1998)]

인터페이스가 있으며 다른 컴포넌트에 대한 명시적인 의존 관계 만을 가지는 조립의 단위. 소프트웨어 컴포넌트는 독립적으로 배포되며 제 3자에 의해서 조립되는 것을 가정한다. [C.Szyperski, 『Component Software: Beyond Object-Oriented Programming』(Addison-Wesley, 1998)]


- One Step Ahead -


3. 3. 컴포넌트컴포넌트독립적으로 개발되고 배포되는 단위로써 조립/교환이 가능한 응집도가 높은소프트웨어 산출물

시스템의 구성 단위로서의 컴포넌트

컴포넌트는 전체 시스템을 구성하는 하나의 구성 요소이다.

각 컴포넌트는 전체 시스템 기능의 일부분을 제공한다.

전체 시스템은 컴포넌트들을 조립함으로써 완성되고 정상적으로 동작한다.

컴포넌트 모델: EJB와 COM+CBD의 가장 큰 이점

개발된 컴포넌트를 다른 시스템을 구축할 때 재사용함으로써, 생산성 향상을 꾀할 수있다.

컴포넌트가 다른 시스템을 구축할 때 재사용되기 위해서는 기본적으로 컴포넌트가 운용될 수 있는 표준적인 환경이 일치해야 한다.

컴포넌트들이 조립되고 동작하기 위해서는 컴포넌트 모델을 지원하는 운영 환경이 갖추어져야 한다.


- One Step Ahead -


4. EJB 4. EJB 컴포넌트와컴포넌트와 COM+ COM+ 컴포넌트컴포넌트

EJB 컴포넌트 COM+ 컴포넌트

제안사 Sun Microsystems Microsoft

운영체제 JVM이 지원되는 운영체제 Windows 2000

운영환경

애플리케이션 서버

(Bea WebLogic, IBM WebSphere)

.NET 프레임워크

개발언어 Java C#, Visual Basic.NET 등

개발도구 JDK, JBuilder, Eclipse 등 Visual Studio.NET

컴포넌트의 기능이 이용될 수 있는 운영 환경에 컴포넌트가 설치되어 동작될 수 있게준비되는 과정을 배치(deployment)라고 부른다.

EJB : WebLogic 콘솔을 이용하거나 weblogic.deploy 클래스를 이용한다.

.NET : COM+ 컴포넌트를 배치할 때는 regsvcs 명령어를 이용할 수 있다.


- One Step Ahead -


5. 5. 인터페이스인터페이스 (1)(1)인터페이스(interface)는 컴포넌트들이 조립되어 동작되기 위한 컴포넌트 간의 표준규약이다.

인터페이스는 컴포넌트가 제공하는 기능에 대한 명세이다.

인터페이스에 의해서 정의된 기능을 컴포넌트가 실제로 제공하는 것을 실현(realization)이라고 한다.

인터페이스는 컴포넌트와 별개의 존재로써 명시적으로 정의한다.

인터페이스를 정의하는 개발자는 컴포넌트가 제공할 기능에 대한 명세를 하고, 컴포넌트 개발자는 정의된 기능을 실제로 구현하는 역할을 한다.

컴포넌트의 내부는 완전히 숨겨지며 인터페이스를 통해서만 컴포넌트를 활용할 수 있다.

인터페이스를 실현하는 컴포넌트와 인터페이스를 통하여 컴포넌트의 기능을 이용하는다른 컴포넌트 사이에서 인터페이스는 계약으로서의 역할을 한다.

컴포넌트는 실현하려고 하는 인터페이스의 기능을 정확하게 구현해야 하며, 컴포넌트를 이용하는 다른 컴포넌트는 인터페이스의 연산이 가정하는 조건을 충족시켜야만 한다.


- One Step Ahead -


5. 5. 인터페이스인터페이스 (2)(2)

COM+ 컴포넌트에서는 묵시적으로 인터페이스를 결정한다.즉, COM+ 컴포넌트에 포함된 공용(public) 클래스가 인터페이스가 된다.

각 공용 클래스의 공용 연산이 인터페이스의 연산이 된다.

따라서, COM+ 컴포넌트는 묵시적으로 논리적 측면에서 인터페이스를 실현하고 있는 것이다.

EJB 컴포넌트와 COM+ 컴포넌트의 인터페이스

EJB 컴포넌트의 인터페이스는 EJB 컴포넌트(JAR)에 포함된 세션빈과 엔티티빈의 리모트인터페이스(remote interface)의 집합이다.

COM+ 컴포넌트의 인터페이스는 어셈블리에 포함된 모든 공용 클래스의 집합이다.

모니터 컴포넌트 소프트웨어 컴포넌트

물리적 커넥터의 외형 컴포넌트 모델의 준수

논리적 커넥터로부터 수신된 신호의 인식

인터페이스 이름의 일치

각 인터페이스에 정의된 연산의 이름, 인자 타입과 반환 타입의 일치

기능적커넥터를 통하여 수신된 신호를 해석하여 모니터가 전자총을 제어하여 요구된이미지를 출력

인터페이스에 정의된 각 연산을 기능적으로 정확하게 구현


- One Step Ahead -


6. 6. 컴포넌트의컴포넌트의 이점이점컴포넌트는 기존의 함수(function), 클래스 등에 비하여 보다 큰 규모이므로 재사용을 하는 경우 재사용의 효과가 보다 크게 된다.

인터페이스만 동일하게 유지된다면 컴포넌트에 임의의 변경이 발생하여도 기존의 시스템은 영향을 받지 않는다.

컴포넌트는 항상 인터페이스를 통하여 다른 컴포넌트에 의해서 이용되기 때문에 컴포넌트 내부의 변경은 다른 컴포넌트로 전파되지 않는다.

기존 컴포넌트를 수정하는 대신에 아예 새로운 컴포넌트로 기존 컴포넌트를 대체하는것도 가능하다.

컴포넌트의 대체를 이용하면 기존에 오류가 있거나 성능 면에서 우수하지 못한 컴포넌트를 대신하여 정확하게 동작하거나 좋은 성능의 컴포넌트를 이용하여 시스템 전체를변경시키지 않고 변경할 대상의 컴포넌트만 대체함으로써, 전체 시스템을 유지보수하는 것이 가능하다.


- One Step Ahead -


7. 7. 컴포넌트와컴포넌트와 클래스클래스공통점

클래스가 제공하는 기능은 클래스의 연산에 의해서 정의됨

컴포넌트는 실현하는 인터페이스에 의해서 기능이 정의됨

차이점

클래스논리적인 단위

객체지향 방식으로 시스템을 분석하고 설계하는 모델링 활동의 결과물 측면의 의미가 강하다.

컴포넌트물리적인 단위

분석과 설계 활동의 논리적인 측면보다는 반드시 프로그래밍 된 결과로 존재해야 한다.

컴포넌트는 구현된 바이너리코드의 형태를 가진다.Java의 바이트코드로 구성된 클래스 파일과 .NET의 MSIL로 구성된 파일도 바이너리코드라고 간주된다. 따라서 컴파일의 과정이 필요 없이 바이너리 상태의 컴포넌트를 그대로 조립하여 시스템을 구성할 수 있다.

클래스는 컴포넌트를 구현하기 위한 효과적인 수단으로 사용된다.컴포넌트는 독립적으로 개발, 배포, 배치되는 소프트웨어의 구성 단위로써 컴포넌트가 제공하는 기능은 실현하는 인터페이스로 정의된다.


- One Step Ahead -


8. 4+1 View 8. 4+1 View 관점관점

설계 관점

관점 설명

유스케이스 관점 사용자가 인식할 수 있는 시스템이 제공할 기능 파악에 초점을 둔다.

설계 관점 요구된 기능을 제공하기 위한 시스템의 내부 구조 및 내부 기능에 초점을 둔다.

프로세스 관점 시스템을 구성하는 프로세스, 쓰레드 그리고 그들 간의 동기화와 통신 관계에초점을 둔다.

구현 관점 시스템을 구성하는 물리적인 컴포넌트 및 관계에 초점을 둔다.

배치 관점 시스템을 구성하는 물리적인 처리 장치와 각 처리 장치에 배치되는 컴포넌트에초점을 둔다.

구분 관심 사항 이용되는 다이어그램

정적인 측면 클래스 및 클래스들 사이의 관계

클래스 내의 동작

클래스 간의 상호작용

클래스의 연산의 동작

클래스 다이어그램

상태차트 다이어그램

시퀀스 다이어그램

협력 다이어그램

액티비티 다이어그램

동적인 측면


- One Step Ahead -


9. 9. 개발개발 활동활동, , 관점관점 그리고그리고 UMLUML개발 활동과 관점

모델링 프로그래밍

요구사항 정의

분석

설계

구현

유스케이스관점

설계관점

배치관점

구현관점

프로세스관점

설계관점


- One Step Ahead -


10. 10. 시스템시스템 유형유형 별별 UMLUML의의 사용사용

시스템의 유형

관점 UML 다이어그램간단한 시스템 반응적인 시스템 복잡한 분산 시스템

유스케이스 관점 유스케이스 다이어그램


상호작용 다이어그램

상태차트 다이어그램



구현 관점 컴포넌트 다이어그램

배치 관점 배치 다이어그램

프로세스 관점

설계 관점


- One Step Ahead -


11. 11. 웹웹 기반기반 정보시스템정보시스템 구축구축 시시 중요한중요한 관점관점 및및 UML UML 다이어그램다이어그램

관점 UML 다이어그램 사용 여부

유스케이스 다이어그램

시퀀스 다이어그램

액티비티 다이어그램



상태차트 다이어그램 -

클래스 다이어그램 -

상호작용 다이어그램 -

구현 관점 컴포넌트 다이어그램

배치 관점 배치 다이어그램

프로세스 관점

설계 관점

유스케이스 관점

시스템 개발 절차개요

요구사항 정의 활동

분석 활동

설계 활동

구현 활동

요약


- One Step Ahead -


1. 1. 개요개요개발 절차(Development Process)

주어진 요구사항을 충족시키는 소프트웨어 시스템을 구축하기 위하여 수행되는일련의 활동을 말한다.

개발 절차의 구성

소프트웨어개발프로세스는 효율적으로 소프트웨어 시스템을 구축하기 위한 절차다. 따라서 누가 무엇을 해서 어떤 결과를 내 놓아야 하는 가에 대해서 언급을해야 한다. 즉, 시스템을 구축하기 위해서 어떤 개발자들이 필요하며, 각 개발자가 수행해야 할 작업은 무엇이 있고, 이 작업의 수행 결과가 무엇인지를 정의해야한다. [Ivar Jacobson, Grady Booch and James Runbaugh, 『The Unified Software Development Process』(Addison Wesley, 1999)]

일반적인 소프트웨어 개발 절차

요구사항 정의

분석

설계

구현

시험


- One Step Ahead -


2. 2. 산출물산출물(Artifacts)(Artifacts)산출물(Artifacts)

프로젝트 수행의 모든 결과물을 뜻한다.

요구사항정의, 분석, 설계의 산출물은 또 다른 시스템을 구축할 때 재사용 될 수있다.

예를 들면, 도서관리시스템을 J2EE 기반으로 구축한 후에 .NET 기반으로 다시구축하는 경우, 처음 J2EE 기반 시스템을 구축할 때 얻은 요구사항정의/분석 산출물을 .NET 기반 시스템을 구축할 때 재활용할 수 있다. 개발과정중에서 요구사항정의, 분석은 J2EE 기반 시스템과 .NET 기반 시스템이 동일하므로 생략하고 기존 산출물을 이용하고, 설계 이후의 활동만 수행하면 된다.

요구사항 정의, 분석, 설계의 산출물은 대부분 UML 다이어그램으로 기술된다.

구현의 산출물은 프로그래밍 언어(Java, C# 등)로 표현된 프로그램 소스 코드형태이다.

개발 활동 중에서 요구사항 정의, 분석, 설계는 구체적인 소스 코드를 작성하는것이 아니고 개발될 소스 코드에 대한 각종 결정사항을 정의하는 활동이다. 이를모델링이라고 부른다.

요구사항 정의, 분석, 설계 단계의 활동은 모델링에 해당되므로 UML 다이어그램의 형식으로 산출물이 작성되고, 구현 활동에서는 소스 코드 및 구축된 시스템이 산출물에 해당된다.


- One Step Ahead -


3. 3. 요구사항요구사항 정의정의 활동활동 (1)(1)목적

요구사항 정의에서는 개발할 시스템에 대한 요구사항을 파악해서 명확하게 기술하는 것을목적으로 한다.

특징개발될 시스템에 대한 요구사항을 파악할 뿐이지 어떻게 요구사항을 만족하는 시스템을 구축할 것인가에 대해서는 언급하지 않는다.

구축될 시스템을 black box로 취급한다.구축될 시스템 내부에 어떤 것들이 있는 지는 관심 밖이며 다만, 어떤 기능을 시스템이 외부로 제공해야 하는 가에만 집중한다.

요구사항 정의에서는 시스템 외부로 보여져서 사용자가 인식할 수 있는 기능에만 초점을 맞춘다.

요구사항은 기능적(functional) 요구사항과 비기능적(non-functional) 요구사항으로 분류할 수 있다.

기능적 요구사항 – 시스템이 제공해야 하는 동작/행위에 대한 요구사항

비기능적 요구사항 – 시스템의 동작/행위 자체 보다는 성능, 유지보수성, 신뢰도와 같은 품질 요소에 대한 요구사항이다.

요구사항 모델

유스케이스모델, 유스케이스명세서, 이벤트흐름모델, 화면흐름모델


- One Step Ahead -


3. 3. 요구사항요구사항 정의정의 활동활동 (2)(2)유스케이스모델

요구사항 정의 활동에서 파악된 액터(actor)와 유스케이스를 표현한 유스케이스 다이어그램들을 유스케이스모델(use case model)이라고 부른다.

시스템과 상호작용을 하는 사용자와 외부 연동 시스템을 액터로 파악하고 시스템에서 제공하는 각각의기능을 유스케이스로 파악해서 이를 유스케이스 다이어그램에 표현한다.


- One Step Ahead -


3. 3. 요구사항요구사항 정의정의 활동활동 (3)(3)유스케이스명세서

유스케이스모델과 더불어 요구사항 정의활동의 또 다른 산출물은 유스케이스명세서(use case specification)다.

유스케이스명세서는 유스케이스 별로 작성되며 각 유스케이스에 대한 보다 자세한정보를 기술하는 문서 산출물이다.

개요 사용자는 등록된 아이디와 암호를 입력함으로써 시스템에 로그인을 한다.

관련액터 사용자(학생, 교수, 수업담당자, 학사담당자)

우선순위 상

선행조건 없음

이벤트흐름 기본흐름1. 사용자는 시스템에 접속한다.2. 시스템은 로그인 화면을 보여준다.3. 사용자는 아이디와 암호를 입력하고 로그인을 선택한다.

사용자 아이디 즉 학법/교수번호/직원번호는 다음과 같은 규칙을 가진다.학번 : 첫 문자는 ‘S’로 시작하고 이어서 3자리의 숫자가 나온다.교수번호 : 첫 문자는 ‘P’로 시작하고 이어서 3자리의 숫자가 나온다.직원번호 : 학사담당자는 ‘H’로 시작하고 이어서 3자리의 숫자가 나온다. 수업담당자는 ‘G’로 시작하고 이어서 3자리의 숫자가 나온다.

사용자 암호는 7자리의 영문자 및 숫자로 구성된다.4. 시스템은 입력된 아이디와 암호의 유효성(A1)과 정확성(A2)을 확인하고

사용자 별 메인 화면을 보여준다. 각 사용자 별 메인 화면은 다음과같다.학생 : 학생 메인 화면교수 : 교수 메인 화면학사담당자 : 학사관리 메인 화면수업담당자 : 수업관리 메인 화면

대안흐름(A1) 유효하지 않은 아이디 또는 암호인 경우

1. 시스템은 입력된 아이디 또는 암호가 허용되지 않은 값임을알려준다.

2. 사용자는 다시 아이디와 암호를 입력함으로써 로그인을 시도한다.(A2) 부정확한 아이디와 암호인 경우

1. 시스템은 아이디와 암호가 부정확함을 알려준다.2. 사용자는 다시 아이디와 암호를 입력함으로써 로그인을 시도한다.

후행조건 사용자는 시스템에 로그인이 되어, 시스템의 기능을 이용할 수 있다.

기타요구사항 없음


- One Step Ahead -


3. 3. 요구사항요구사항 정의정의 활동활동 (4)(4)이벤트흐름모델

유스케이스명세서에 기술된 이벤트 흐름은 유스케이스가 나타내는 시스템의 기능이 액터와 시스템간의상호작용으로 진행되는 과정을 보여준다.

각 유스케이스 별로 이벤트 흐름을 시퀀스 다이어그램으로 표현할 수 있으며, 이를 이벤트흐름모델(flow of event model)이라고 부른다.


- One Step Ahead -


3. 3. 요구사항요구사항 정의정의 활동활동 (5)(5)화면흐름모델

각 유스케이스 별로 사용자 인터페이스를 위하여 사용되는 화면들 간의 흐름 관계를 보여준다.


- One Step Ahead -


4. 4. 분석분석 활동활동 (1)(1)분석 및 설계 활동 vs 구현 활동

분석과 설계 활동

시스템을 구축할 때 내려야 할 모든 사항에 대한 결정을 내리는 활동

모델링

구현과 시험 활동

분석과 설계에서 결정된대로 코딩하여 프로그램을 작성(writing)하는 과정

실제 소스 코드를 프로그래밍하는 작업

분석 활동 vs 설계 활동

기능적 요구사항에만 초점을 맞추고 비기능적 요구사항은 설계 활동에서 고려된다.분석시에는 시스템에서 제공해야 하는 기능을 위해서 필요한 클래스들과 연산을 파악

클래스와 연산이 파악될 때 성능, 유지보수성, 신뢰도 등의 비기능적 요구사항은 고려되지 않는다.

분석클래스(analysis class)분석 활동에서 기능적 요구사항만을 고려하여 파악된 클래스

분석 객체 모델

분석 유스케이스 실현 모델

설계클래스(design class)설계 단계에서 비기능적 요구사항까지 고려해서 파악된 클래스


- One Step Ahead -


4. 4. 분석분석 활동활동 (2)(2)분석객체모델

분석 활동에서 파악된 분석클래스들을 표현한 클래스 다이어그램을 분석객체모델이라고 부른다.

유스케이스 분석 기법에서는 분석클래스가 경계(boundary)클래스, 제어(control)클래스, 실체(entity)클래스로 분류되며, 각각은 유스케이스가 나타내는 시스템의 기능을 프리젠테이션 로직 및 외부 시스템접속 로직, 비즈니스 로직, 데이터 접근 로직을 전담하여 제공한다.

분석클래스의 유형

종류 스테레오 타입 역할

실체클래스 <<entity>> 영속성이 있는 데이터에 대한 조작을 담당

경계클래스 <<boundary>> 시스템과 외부와의 연결을 담당

제어클래스 <<control>> 비즈니스 로직을 담당


- One Step Ahead -


4. 4. 분석분석 활동활동 (3) (3) -- 레이어레이어 구성구성(Layering)(Layering)세 가지 주요 레이어

MVC 모델

레이어 책임

데이터 소스 로직애플리케이션을 위한 태스크를 수행하는 다른 시스템과의 의사소통에 관한 것.

데이터베이스, 메시징 시스템, 트랜잭션 모니터, 다른 패키지와의 의사소통

프리젠테이션 로직사용자와 소프트웨어 사이의 상호작용을 다루는 방법에 관한 것.

서비스 제공, 정보 표시(예를 들어, 윈도우나 HTML에서 사용자 요청(마우스 클릭, 키보드 치기), HTTP 요청, 커맨드 라인 호출, 일괄 API)

도메인 로직

(Business Logic)

시스템의 요점인 로직

저장된 데이터를 기반으로 하는 계산, 프리젠테이션으로부터 오는 데이터에 대한 타당성 검증, 프리젠테이션으로부터 받은 명령에 따라 정확히 어떤 데이터 소스 로직을 보내야 하는지에 대한 결정 등을 포함한다.

분류 의미 Class Diagram의 Stereo Type 및 아이콘

Model데이터 레이어

(Data Layer)

프리젠테이션 레이어

(Presentation Layer)

비즈니스 레이어(Business Layer)

<<entity>>

일반적으로 시스템이 어떤 책임을 완수하기 위해

필요로 하는 클래스이다.

View<<boundary>>

시스템의 주변환경과 시스템 내부간의

상호작용을 다룬다.

Controller

<<control>>

순차적인 행위에 대해, 하나 또는 그 이상의

구체적인 바운더리 클래스와 엔티티클래스들을 연결하는 역할을 한다.


- One Step Ahead -


4. 4. 분석분석 활동활동 (4)(4)


- One Step Ahead -


4. 4. 분석분석 활동활동 (5)(5)분석 유스케이스 실현 모델

각 유스케이스 별로 해당 유스케이스의 기능을 실현하기 위한 객체들의 상호작용을 표현하기 위해서 사용되는 시퀀스 다이어그램을 분석 유스케이스 실현 모델이라고 부른다.

각 유스케이스 별로 해당 유스케이스의 기능을 구현하기 위해서 분석클래스들이 어떻게 메시지를 주고 받는지를 기술한다.


- One Step Ahead -


4. 4. 분석분석 활동활동 (6)(6)


- One Step Ahead -


5. 5. 설계설계 활동활동 (1)(1)설계 활동은 분석 활동과 함께 개발할 시스템의 내부 모습 즉, 클래스와 클래스 간의 관계 등을 정의하는 단계이다.

분석 활동

플랫폼에 무관하며 기능적 요구사항만을 기준으로 클래스를 파악

설계 활동

파악된 분석클래스를 비기능적 요구사항과 플랫폼에 맞추어(platform specific) 설계클래스로 발전시킨다.

산출물설계 모델 : 설계 객체 모델, 데이터 모델, 설계 유스케이스 실현 모델, 컴포넌트 모델, 배치 모델

설계객체모델분석 활동의 산출물인 분석객체모델과 구분하기 위해서 설계 활동에서 도출된 설계클래스와 설계클래스 간의 관계를 설계객체모델이라고 부른다.

설계 객체 모델은 플랫폼이 고려되어야 하므로, J2EE 플랫폼과 .NET 플랫폼에 따라서 각각 작성된다.

분석클래스의 설계클래스로의 대응 규칙

분석클래스 J2EE 플랫폼 기반 설계 .NET 플랫폼 기반 설계

실체클래스 엔티티 빈과 테이블 COM+ 클래스와 테이블

경계클래스 JSP 페이지 HTML 또는 ASP.NET 페이지

제어클래스 세션 빈 COM+ 클래스


- One Step Ahead -


5. 5. 설계설계 활동활동 (2)(2)로그인 유스케이스에 대한 설계객체모델 – J2EE 플랫폼


- One Step Ahead -


5. 5. 설계설계 활동활동 (3)(3)로그인 유스케이스에 대한 설계 객체 모델 – .NET 플랫폼


- One Step Ahead -


5. 5. 설계설계 활동활동 (4)(4)데이터 모델

대규모 시스템에서는 영속적인 정보를 관리하기 위하여 Oracle, MS SQL Server 등과같은 DBMS를 사용한다.

DBMS에서 테이블로 영속적인 정보를 저장하기 위해서는 우선 데이터 모델(data model)이 정의되어야 한다.

즉, 테이블, 테이블의 열 그리고 테이블 간의 관계 등을 정의해야 한다.

설계 활동에서는 실체클래스를 바탕으로 데이터 모델을 작성한다.실체클래스를 테이블로 대응시키는 것은 객체지향 방식으로 시스템을 개발하여도 영속적인 정보는 결국 관계형 데이터베이스의 테이블에 의해서 제공되기 때문이다.

일반화 관계, 포함 관계, 연관 관계 등으로 연결된 클래스들은 설계 활동에서 테이블과 테이블 간의 관계 즉, 데이터 모델로 대응되며, 이를 개체-관계 매핑(object-relational mapping)이라고 부른다.

데이터 모델의 테이블은 실체클래스에 표현된 데이터가 설계된 결과이며, 실체클래스의 연산으로 표현된 데이터 접근 로직은 J2EE 플랫폼에서는 엔티티 빈으로 설계되고, .NET 플랫폼에서는 COM+ 클래스로 설계된다.

J2EE 플랫폼과 .NET 플랫폼은 모두 Oracle 또는 MS SQL Server와 같은 관계형DBMS를 사용하므로 데이터 모델을 설계하는 방법은 플랫폼에 상관없이 동일하다.


- One Step Ahead -


5. 5. 설계설계 활동활동 (5)(5)데이터 모델


- One Step Ahead -


5. 5. 설계설계 활동활동 (6)(6)설계 유스케이스 실현 모델

설계 유스케이스 실현 모델은 파악된 설계클래스들이 어떻게 메시지를 주고 받으면서 시스템의 요구사항을 제공할 수 있는 지를 의미

시퀀스 다이어그램을 이용하여 표현

설계 객체들 간의 상호작용으로 유스케이스를 실현한다.

즉, 시퀀스 다이어그램의 상단에 배치되는 객체가 분석클래스의 객체가 아니라 설계클래스의 객체이며, 시퀀스 다이어그램에 표시된 메시지는 설계클래스에 정의된 연산에 해당된다.

분석 유스케이스 실현 모델분석 객체들 간의 상호작용으로 유스케이스를 실현


- One Step Ahead -


5. 5. 설계설계 활동활동 (7)(7)로그인 유스케이스에 대한 설계 유스케이스 실현 모델 – J2EE 플랫폼


- One Step Ahead -


5. 5. 설계설계 활동활동 (8)(8)로그인 유스케이스에 대한 설계 유스케이스 실현 모델 – .NET 플랫폼


- One Step Ahead -


5. 5. 설계설계 활동활동 (9)(9)컴포넌트 모델(component model)

시스템을 구성하는 각 컴포넌트와 컴포넌트 간의 관계의 의미

컴포넌트 다이어그램을 이용하여 표현

각 컴포넌트가 어떤 인터페이스를 실현하는 지 그리고 각 컴포넌트가 다른 컴포넌트의 어떤 인터페이스를 이용하고 있는 지를 보여준다.


- One Step Ahead -


5. 5. 설계설계 활동활동 (10)(10)컴포넌트 모델 – J2EE 플랫폼


- One Step Ahead -


5. 5. 설계설계 활동활동 (11)(11)배치 모델(deployment model)

전체 시스템을 구성하는 서버 및 클라이언트와 그들 간의 통신 방법 등을 의미

배치 다이어그램을 이용하여 표현


- One Step Ahead -


6. 6. 구현구현 활동활동구현 활동은 실제 프로그램 소스 코드를 작성하고, 컴파일 하여 시스템을 구현하는 활동이다.

순공학, 역공학, 순환공학

순공학 (Forward Engineering)설계 모델로부터 소스 코드를 자동으로 생성하는 것

역공학 (Reverse Engineering)소스 코드의 내용을 바탕으로 설계 수준의 클래스 다이어그램을 유도하는 것

순환공학(Round-Trip Engineering)순공학과 역공학을 번갈아 가면서 이용하여 설계객체모델과 소스 코드를 작성하는 것

클래스의 속성 또는 연산을 변경하는 것은 소스 코드의 수준이 아니라, 설계 수준의 변경이다.

실제로 시스템을 구축할 때는 순공학을 이용하여 설계객체모델로부터 소스 코드를 생성하고, 생성된 소스 코드를 수정하며, 수정된 소스 코드의 내용을 역공학을 이용하여 설계객체모델에 반영한다.

Rose와 Together의 J2EE 및 .NET 시스템 개발 지원

Together는 J2EE 플랫폼의 세 가지 유형의 컴포넌트인 EJB 컴포넌트(JAR), 웹 컴포넌트(WAR), 엔터프라이즈 컴포넌트(EAR)를 자동으로 빌드해 주는 기능도 제공한다.

Together에서는 C#, Visual Basic.NET 소스 코드에 대한 편집은 가능하지만 컴파일, 빌드, 실행, 디버깅 등의 기능은 지원되지 않는다.

J2EE 플랫폼 .NET 플랫폼

Rose 순환공학 지원 순환공학 지원

Together동시 순환공학 지원

EJB 컴포넌트 및 컴포넌트에 대한 배치 지원동시 순환공학 지원


- One Step Ahead -


7. 7. 요약요약 (1)(1)개발 활동, 모델링, UML의 관계

개발 활동 요약

개발 활동 요구사항 정의 분석 설계 구현

모델링 vs 프로그래밍 모델링 프로그래밍

표현 언어 UML Java 또는 C#

요구사항을 충족시키는 시스템의 구축

시스템에 대한 요구사항 파악

요구사항 정의 vs분석/설계/구현

플랫폼 고려

비기능적

요구사항도 고려

플랫폼 무시

기능적 요구사항만

고려

분석 vs 설계

각종 소스 코드개발, 컴포넌트빌드 및 배치

시스템에 대한 고안분석/설계 vs 구현

구현설계분석요구사항 정의개발 활동


- One Step Ahead -


7. 7. 요약요약 (2)(2)산출물 요약

산출물개발활동

산출물 명 세부 산출물 명 UML 다이어그램

유스케이스 모델 유스케이스 다이어그램

유스케이스명세서 N/A

이벤트 흐름 모델 시퀀스 다이어그램

화면 흐름 모델 액티비티 다이어그램

분석 객체 모델 클래스 다이어그램

분석 유스케이스 실현 모델 시퀀스 다이어그램

설계 객체 모델 클래스 다이어그램

데이터 모델 개체-관계 다이어그램

설계 유스케이스 실현 모델 시퀀스 다이어그램

배치 모델 배치 다이어그램

컴포넌트 모델 컴포넌트 다이어그램

소스 코드

컴포넌트

시스템

구현

설계 설계 모델

분석 분석 모델

요구사항 정의 요구사항 모델


- One Step Ahead -


8. 48. 4개의개의 ViewView와와 Model PropertiesModel Properties5개의 관점과 Rose 상의 표현 위치

개발 활동별 관점, 산출물, View

관점 Rose 상의 표현 위치

유스케이스 관점 Use Case View

설계 관점 Logical View

프로세스 관점 Logical View

구현 관점 Component View

배치 관점 Deployment View

개발 활동 관점 산출물 Rose 상의 위치

유스케이스 모델 Use Case View

이벤트 흐름 모델 Use Case View

화면 흐름 모델 Use Case View

분석 객체 모델 Logical View

분석 유스케이스 실현 모델 Logical View

설계 객체 모델 Logical View

데이터 모델 Logical View

설계 유스케이스 실현 모델 Logical View

배치 관점 배치 모델 Deployment View

구현 관점 컴포넌트 모델 Deployment View

설계 관점

설계 설계 모델

분석 설계 관점 분석 모델

요구사항 정의 유스케이스 관점 요구사항 모델


- One Step Ahead -


참고문헌참고문헌[ 1 ] 송태국, RUP 기반의 J2EE 애플리케이션 개발,

피어슨에듀케이션코리아, 2003.

[ 2 ] 채흥석, 객체지향 CBD 개발 Bible, 한빛미디어, 2003.

[ 3 ] 전병선, 객체지향 CBD개발 방법론, 영진닷컴, 2004.

[ 4 ] 컴포넌트비전, 실전 CBD Project, 영진닷컴, 2004.

[ 5 ] 조창현, RUP Development Solution, 영진닷컴, 2004.

Documents

객체지향 CBD 개발 - pds10.egloos.compds10.egloos.com/pds/200901/14/88/a0105788_496df5c76ab77.pdf · 구현의산출물은프로그래밍언어(Java, C# 등)로표현된프로그램소스코드