논리적 구조 설계: 패키지도

Objectives

• 계층을 이용하여 논리적 아키텍처를 소개한다.

• UML 패키지 다이어그램을 이용하여 논리적 아키텍처를 표현한다.

2

객체 설계로 옮겨가기

• 교류도 (interaction diagram)를 그리는 일이 가장 중요.

• 교류도를 그린 후/혹은 그리면서 설계 클래스도를 작성.

• 교류도와 클래스도는 상호보완 하면서 반복적으로 정제.

• 산출물 : 설계 모델

3

객체설계 기술과 UML표기 기술의 비교

-UML 교류도를 그리는 것은 객체 설계에 관해 이미 결정한 내용을 단지 반영하는 과정일 뿐이다.

-UML 도를 그리는 것을 아는 것보다 객체 설계 기술이 더 중요하다.

-객체 설계를 위해서는 다음을 알아야 한다.

1. 책임 할당의 원리

2. 설계 패턴

문맥

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Vision Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

Domain Model

**

SupplementarySpecification

Use-Case Model

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view)

interaction diagrams(a dynamic view)

UIpackage diagramsof the logical architecture(a static view) Domain

Tech Services

Design Model

4

논리적 아키텍처는 보충명세서의 비기능적 요구사항에서 가져온다. -소프트웨어 컴포넌트, -사용자 인터페이스 -실행 구조 (웹 서비스, C/S) -프로그래밍 언어 -라이브러리 -프레임워크(Framework)

1. 예제 : 3계층 논리적 구조를 표현한 UML 패키지도.

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

5

자바 swing 클래스를 사용한 사용자 GUI 클래스들의 집합

Presentation Layer

Service Layer

Persistence Layer

Workflow Layer

depends on

2. 논리적 구조의 정의 및 계층구조

• 논리적 아키텍처의 정의

– 소프트웨어의 클래스들을 패키지 (네임스페이스), 서브시스템, 계층과 같은 큰 단위로 구성한 것.

– ‘논리적’이란 것은 소프트웨어의 설치 위치와 상관 없기 때문

– 물리적 구조는 배치도(deployment diagram)로 표현.

• 계층 구조

– 패키지가 계층구조로 사용되는 것으로, 상위 계층의 패키지의 클래스들이 하위 계층 패키지 안의 클래스들을 사용하고 그 반대의 경우는 허용하지 않을 때를 의미한다.

– 3 계층 구조

• UI (사용자 인터페이스) 계층 (최상위) (presentation layer)

– 액터 (사용자)와의 입출력을 담당하는 객체

• 응용 로직과 도메인 객체 계층 (business service layer)

– 예를 들어, POS의 판매기록을 담당하는 Sale 객체 등 도메인의 정보를 담당하는 소프트웨어 객체

• 기술적 서비스 계층 (persistency layer)

– 범용 객체, 데이터베이스 연결, 오류의 로깅 서비스들로서 응용에 독립적으로 여러 프로젝트에서 재사용이 가능하다.

6

3. 사례연구에서의 초점

• 도메인 계층 (응용 로직 계층)에 초점 – 도메인 객체는 문제영역마다 다른 정보와 다른 동작을 하기 때문에 설계가 많이 들어감

– 다른 계층은 이미 잘 정의된 객체가 존재.

• UI나 기술적 서비스 계층은 별도로 공부할 필요가 있음. – UI: Story Board, HCI(Human Computer Interface) 설계 방법, Web

Interface Design 등

– 기술적 서비스 계층 • Java 등에서 제공하는 응용 패키지 들

• C++에서의 STL 라이브러리

• ODBC Library

• DB Connection Pool Library

• 각종 미들웨어 API 등

• 개발자가 별도로 만든 라이브러리

• 개발 Framework

7

4. 소프트웨어 아키텍처란?

• 소프트웨어 아키텍처 (Software Architecture)

– 아키텍처는

• 1) 소프트웨어 시스템의 구성,

• 2) 시스템을 구성하는 구조적 요소와 이들의 인터페이스 및 요소들 간의 협력으로 명세 되는 행위에 대한 선택

• 3) 점진적으로 더 큰 서브시스템으로의 구조적인 요소와 행위적인 요소의 결함, 그리고

• 4) 이러한 요소와 인터페이스, 요소간의 협력, 요소의 결합에 대해 가이드라인을 제공하는 아키텍처 스타일에 대한 중요한 결정들의 집합이다.

• 공통적인 주제

– 시스템 안의 컴포넌트들이 서로 협력하여 시스템의 목적을 달성하는 구조

– 컴포넌트들은 서로 연결되어 있으며, 연결된 컴포넌트는 이들을 포함하는 더 큰 컴포넌트가 될 수 있다.

– 정적인 면이 강조됨 (구조적인 면)

8

5. UML의 적용: 패키지도 도식 방법

Domain::Sales

UI::WebUI::Swing

Sales

WebSwing

UI

Domain

DomainUI

Swing SalesWeb

9

:: 범주

포함

subset

UML 패키지도

• 패키지

– Namespace를 표현

• 예) java::util::Date 클래스

– Date 클래스는 util 패키지에 속하고, util 패키지는 java 패키지에 중첩되어 포함된다.

• UML 패키지도

– 클래스의 집합을 표현할 수도 있고 유스케이스 등 무엇이든 그룹을 짓고자 할 때 사용한다.

– 패키지는 중첩적으로 패키지를 포함할 수 있다.

10

UI Domain

UI 패키지 안의 클래스들의 연산에서 Domain 패키지 안의 클래스들을 사용한다. (즉, 의존한다.)

Domain 패키지의 클래스가 변경되면 UI클래스들의 코드도 바뀌어야 한다. (그 반대는 아니다.)

6. 가이드라인 : 계층을 이용한 설계

• 기본 아이디어 – 큰 규모의 시스템을 계층들로 조직화 하고, 각 계층들은 연관된 책임을 갖음

– 예) 하위 계층은 상위 계층에 단위 ‘서비스’를 제공하고, 상위 계층은 보다 응용에 종속적인 ‘서비스’를 담당한다.

– 고응집력을 갖도록 ‘관심영역’을 분리하는 기법을 사용

– 예) OSI 7 Layer : App – Presentation – Session – Transport - Network – Data Link – Physical

– Layered Pattern 이라고 함 • Rising, “Pattern Almanac 2000”, Addison-Wesley

• 장점 – 관심분리, 하위 수준과 상위 수준의 서비스 분리, 일반 서비스와 응용 종속적인 서비스의 분리 • 결합도와 의존관계 감소, 응집도 향상, 재사용성과 명료성이 좋아짐

– 관련된 복잡도를 캡슐화하여 분해할 수 있음

– 일부 계층만 새로운 구현으로 교체될 수 있다. (Web -> Flash)

– 하위 계층은 재사용가능한 기능들이 포함됨

– 일부 계층을 분산될 수 있음 (도메인, 기술적 서비스 계층)

– 팀 단위의 분할 개발이 쉬워짐

11

Layered Pattern

12

UI(AKA Presentation, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure, High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

· GUI windows· reports· speech interface· HTML, XML, XSLT, JSP, Javascript, ...

· handles presentation layer requests· workflow· session state· window/page transitions· consolidation/transformation of disparate

data for presentation

· handles application layer requests· implementation of domain rules· domain services (POS, Inventory)

- services may be used by just one application, but there is also the possibility of multi-application services

· (relatively) high-level technical services and frameworks

· Persistence, Security

· low-level technical services, utilities, and frameworks

· data structures, threads, math, file, DB, and network I/O

moreapp

specific

depe

nden

cy

Business Infrastructure(AKA Low-level Business Services)

· very general low-level business services used in many business domains

· CurrencyConverter

GUI 윈도우

보고서

음성인터페이스

HTML, XML, XSLT, JSP, Javascript

표현계층의 요청처리

워크플로

세션상태

윈도우/페이지전환

표현계층 데이터들의 합성 변환

응용 계층의 요청처리

도메인 규칙의 구현

도메인 서비스들 (POS, 재고관리) – 서비스는 단일 또는 다수의 응용에서 사용될 수 있다.

다양한 도메인에서 사용되는 일반적이며 낮은 수준의 비즈니스 서비스

예) 환율 변환기

(상대적으로) 높은 수준의 기술적 서비스와 프레임워크

영구저장소, 보안장치

하위수준의 기술적서비스, 유틸리티 및 프레임워크

데이터구조, 쓰레드, 수학함수, 파일처리, DB, 네트워크 I/O

가이드라인: 응집력 있는 책임들; 관심분리 원칙에 맞춰 분해하라

• UI 는 윈도우 Widget이나 마우스, 키보드 인식 등 사용자의 입력을 처리하는데 집중한다.

• 응용 로직 계층은 세금의 계산이나, 판매 정보의 관리, 보드 게임에서 말을 이동시키는 규칙의 구현에 집중한다.

• UI 객체는 응용 로직을 수행해서는 안 된다.

– 예) Jframe 객체는 세금을 계산하거나 말을 움직이는 로직을 구현하면 안 된다.

– 관심의 분리, 높은 응집도에 위배

• MVC 패턴

– 모델: 데이터를 관리하는 데 집중

– 뷰: 데이터를 사용자에게 보여주고 입력을 받아들이는 데 집중

– 제어: 뷰 계층에서 입력된 데이터 및 처리 요구를 모델에 전달하는데 집중, 또는 UI 및 모델 층의 객체들을 제어하여 사용자와의 상호작용의 순서를 제어한다.

13

코드: 소스코드 구조를 계층 및 UML로 매핑

• 객체지향 언어(자바, C#,C++,Python 등)은 패키지를 지원

– C# 및 C++에서는 ‘네임스페이스’라고 부름

• 자바의 예

– UI 계층 (NEXTGEN POS)

• com.mycompany.nextgen.ui.swing

• com.mycompany.nextgen.ui.web

– 도메인 계층 (NEXTGEN POS)

• com.mycompany.nextgen.domain.sales

• com.mycompany.nextgen.domain.payments

– 기술적 서비스 계층

• 사내에서 개발된 데이터베이스 접근 계층

– com.mycompany.service.persistence

• 외부 패키지

– org.apache.log4j

– org.apache.soap.rpc

– 기반 계층

• com.mycompany.util

14

UML: 몇 가지 정의

• UML 도구: 역공학 (Reverse Engineering)

– 소스코드로부터 패키지도

– ui.* 은 UI 패키지도로 자동으로 생성

• 정의: 도메인 계층 대 응용 로직 계층?

– POS의 sale객체, Payment 객체 : 도메인 계층

– 응용로직 계층

• Workflow등 좀 더 복잡한 비즈니스 프로세스와 처리와 관련

• 예) 구매요구 구매심의 입찰 납품 검수 등의 작업 순서를 강제

15

정의: 티어, 계층, 구획면

• 티어(tier): 논리적 계층

• 계층(layer): 수직 (상하)로 분할한 조각

• 구획(partition) : 한 계층 내에서 상대적으로 병렬적인 서브시스템을 수평으로 분할하여 표현한 것.

– 예) 기술적 서비스는 보안과 보고서로 구획할 수 있다.

16

Persistence Security Logging

Technical Services

POS Inventory Tax

Domain

Vertical Layers

Horizontal Partitions

도메인 모델 vs. 도메인 계층

• 도메인 계층의 클래스 이름은 도메인 모델에서 가져옴.

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.

This reduces the representational gap.

This is one of the big ideas in object technology.

inspires objects

and names in

17

도메인 모델 내에서 지불은 하나의 개념이지만, 설계 모델에서는 소프트웨어 클래스이다. 이 둘은 다르지만, 소프트웨어 클래스는 도메인 모델에서 영감을 얻는다.

이렇게 하여 표현상의 차이를 줄일 수 있으며, 이는 객체 기술의 핵심 아이디어 중의 하나이다.

논리적 모델과 물리적 모델을 섞어 그리지 않는다.

Domain(s)

Technical Services

Foundation

MySQL Inventory

Persistence Naming andDirectory Services

Web AppFramework

Technical Services

POS Inventory

Domain(s)

Foundation

Worsemixes logical and deployment views

Bettera logical view

a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database.

첽omponentNovellLDAP

UML notation: A UML component, or replaceable, modular part of the physical system

UML notation: A physical database in the UML.

18

7. 가이드라인: 모델 – 뷰 분리 원칙

• 모델-뷰 분리 원칙

– 이 원칙은 최소한 아래의 두 가지를 포함한다.

• 1. UI가 아닌 객체를 UI객체와 직접적으로 연결하거나 결합하지 않는다. 예를 들어 Sale 소프트웨어 객체 (‘도메인 객체’)가 윈도 객체인 Jframe을 참조하게 해서는 안 된다. 그 이유는 윈도우는 특정 응용과 관련되어 있는 반면, 비-윈도우 객체는 새로운 응용에 재사용되거나 새로운 인터페이스에서 사용될 수 있기 때문이다.

• 2. 세금 계산과 같은 응용 로직을 UI객체의 메소드로 넣지 마라. UI객체는 UI구성요소를 초기화하고 ,UI이벤트(예: 마우스 클릭)을 받고, UI가 아닌 객체에게 응용 로젝에 대한 요청을 위임하는 일만 수행해야 한다.

• 즉,

– 모델 == 도메인 객체

– 뷰 == 윈도우, 웹페이지, 애플릿, 기타 보고서와 같은 UI객체

• 예

– Sale, Register 객체는 뷰 객체가 아니므로, 화면에 표시하기, 색상 변경, 창 닫기 등을 요청할 수 없다.

• Observer 패턴 – 이 패턴은 모델 값의 변화에 반응해야 하는 뷰 객체를 PropertyListener 객체에 등록해 놓고, 모델 값이 변경되었을 때 등록된 모든 뷰 객체에 notify 를 보내 뷰의 상태를 변화시키고자 하는 패턴

– 모델이 직접 뷰를 관리하지 않고, 또한 PropertyListener 객체도 뷰 객체의 상세한 것은 모르지만 view 가 제공하는 update 메소드만 호출하므로서 모델과 뷰를 분리함.

19

모델-뷰 분리 이유

• 유지보수

– UI는 자주 변함, 데이터는 상대적으로 덜 변함

– 따라서,UI의 변화가 데이터 처리에 미치는 영향을 최소화하고자 함

• 관심의 분리

– UI 개발은 사용자의 관점에서 최대한 편의성을 제공하는데 초점

– 모델의 개발자는 데이터를 정확하고 신속하게 처리하는데 초점

• 싱글 모델-멀티 뷰

– 하나의 데이터로 여러 가지 다른 모습으로 사용자에게 보여주기 위해

– 섞어서 개발하면 매번 같은 데이터 처리를 반복, 그리고 데이터 처리가 변하면 다른 뷰도 같이 바꾸어야 함

20

8. SSD, 시스템 연산, 계층은 어떻게 서로 연결되는가?

Domain

UI

Swing

ProcessSaleFrame...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System: Cashier

endSale()

description, total

makeNewSale()

the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer

21

SSD에서 시스템이 처리할 시스템 연산은 UI계층으로부터 도메인 계층으로의 연산 호출을 나타낸다. UC에 대한

UI 설계

내부 설계

9. Case Study: 34장 NEXTGEN POS의 Layers

22

Log4J

Technical Services

Domain

UI

Pricing

PricingStrategyFactory

Text

ProcessSaleConsole

used in quick experiments

Persistence

DBFacade

쳃nterfaceISalePricingStrategy

Taxes

쳃nterfaceITaxCalculatorAdapter

ServicesFactory

Sales

Register Sale

Swing

ProcessSaleFrame

Payments

CreditPayment쳃nterface

ICreditAuthorizationServiceAdapter

ServiceAccess

Inventory

쳃nterfaceIInventoryAdapter

Jess

A general purpose third-party rules engine.

POSRuleEngine

POSRuleEngineFacade

SOAP

not the Java Swing libraries, but our GUI classes based on Swing

9. NEXTGEN POS 의존연관

Log4J

Technical Services

Domain

UI

Pricing

Persistence

DBFacade

Taxes

쳃nterfaceITaxCalculatorAdapter

ServicesFactory

Sales

Register Sale

Swing

ProcessSaleFrame

Payments

CreditPayment쳃nterface

ICreditAuthorizationServiceAdapter

ServiceAccess

Inventory

쳃nterfaceIInventoryAdapter

Jess

POSRuleEngine

POSRuleEngineFacade

SOAP

23