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

(1)

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

(2)

Objectives

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

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

(3)

객체 설계로 옮겨가기

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

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

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

•  산출물 : 설계 모델

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

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

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

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

1. 책임 할당의 원리

2. 설계 패턴

(4)

문맥

: 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

* *

Supplementary Specification Use-Case Model

Register ...

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

ProductCatalog ...

getProductSpec(...) ...

1 1

class diagrams (a static view)

interaction diagrams (a dynamic view) package diagrams UI of the logical architecture

(a static view) Domain

Tech Services Design Model

논리적 아키텍처는 보충명세서의 비기능적 요구사항에서 가져온다.

-소프트웨어 컴포넌트, -사용자 인터페이스

-실행 구조 (웹 서비스, C/S) -프로그래밍 언어

-라이브러리

-프레임워크(Framework)

(5)

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

Domain UI

Swing

not the Java

Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

자바 swing 클래스를 사용한 사용자 GUI

클래스들의 집합

Presentation Layer

Service Layer

Persistence Layer Workflow Layer

depends on

(6)

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

• 논리적 아키텍처의 정의

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

– ‘논리적’이란 것은 소프트웨어의 설치 위치와 상관 없기 때문 – 물리적 구조는 배치도(deployment diagram)로 표현.

• 계층 구조

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

– 3 계층 구조

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

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

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

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

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

– 범용 객체, 데이터베이스 연결, 오류의 로깅 서비스들로서 응용에 독립적으

로 여러 프로젝트에서 재사용이 가능하다.

(7)

3. 사례연구에서의 초점

• 도메인 계층 (응용 로직 계층)에 초점

– 도메인 객체는 문제영역마다 다른 정보와 다른 동작을 하기 때문에 설계가 많이 들어감

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

• UI나 기술적 서비스 계층은 별도로 공부할 필요가 있음.

– UI: Story Board, HCI(Human Computer Interface) 설계 방법, Web Interface Design 등

– 기술적 서비스 계층

• Java 등에서 제공하는 응용 패키지 들

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

• ODBC Library

• DB Connection Pool Library

• 각종 미들웨어 API 등

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

• 개발 Framework

(8)

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

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

– 아키텍처는

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

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

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

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

• 공통적인 주제

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

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

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

(9)

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

Domain::Sales UI::Web UI::Swing

Sales Web Swing

UI

Domain Domain

UI

Swing Web Sales

:: 범주

포함

(10)

UML 패키지도

• 패키지

– Namespace를 표현

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

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

• UML 패키지도

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

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

UI Domain

UI 패키지 안의 클래스 들의 연산에서

Domain 패키지 안의 클 래스들을 사용한다.

(즉, 의존한다.)

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

(11)

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

• 기본 아이디어

– 큰 규모의 시스템을 계층들로 조직화 하고, 각 계층들은 연관된 책임을 갖음 – 예) 하위 계층은 상위 계층에 단위 ‘서비스’를 제공하고, 상위 계층은 보다 응

용에 종속적인 ‘서비스’를 담당한다.

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

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

– Layered Pattern 이라고 함

• Rising, “Pattern Almanac 2000”, Addison-Wesley

• 장점

– 관심분리, 하위 수준과 상위 수준의 서비스 분리, 일반 서비스와 응용 종속적 인 서비스의 분리

•  결합도와 의존관계 감소, 응집도 향상, 재사용성과 명료성이 좋아짐

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

– 일부 계층만 새로운 구현으로 교체될 수 있다. (Web -> Flash) – 하위 계층은 재사용가능한 기능들이 포함됨

– 일부 계층을 분산될 수 있음 (도메인, 기술적 서비스 계층) – 팀 단위의 분할 개발이 쉬워짐

(12)

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)

· 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

more app specific

dependency

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

(13)

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

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

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

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

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

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

• MVC 패턴

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

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

– 제어: 뷰 계층에서 입력된 데이터 및 처리 요구를 모델에 전달하는데

집중, 또는 UI 및 모델 층의 객체들을 제어하여 사용자와의 상호작용

의 순서를 제어한다.

(14)

코드: 소스코드 구조를 계층 및 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

(15)

UML: 몇 가지 정의

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

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

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

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

– POS의 sale객체, Payment 객체 : 도메인 계층 – 응용로직 계층

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

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

(16)

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

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

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

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

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

Persistence Security Logging Technical Services

POS Inventory Tax

Domain

Vertical Layers

Horizontal Partitions

(17)

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

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

Payment amount

Sale date

time Pays-for

Payment amount: Money getBalance(): Money

Sale date: Date startTime: Time getTotal(): Money . . .

Pays-for UP Domain Model

Stakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design Model

The object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the

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

도메인 모델 내에서 지불은 하나

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

이렇게 하여 표현상의 차이를 줄 일 수 있으며, 이는 객체 기술의

핵심 아이디어 중의 하나이다.

(18)

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

Domain(s)

Technical Services

Foundation

MySQL Inventory

Persistence Naming and Directory Services

Web AppFramework Technical Services

POS Inventory

Domain(s)

Foundation Worse

mixes logical and deployment views

Better a logical view

a logical representation of the need for data or services related to these subdomains, abstracting implementation

decisions such as a database.

첽omponent Novell

LDAP

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

UML notation: A physical database in the UML.

(19)

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

• 모델-뷰 분리 원칙

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

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

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

• 즉,

– 모델 == 도메인 객체

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

• 예

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

• Observer 패턴

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

(20)

모델-뷰 분리 이유

• 유지보수

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

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

• 관심의 분리

– UI 개발은 사용자의 관점에서 최대한 편의성을 제공하는데 초점 – 모델의 개발자는 데이터를 정확하고 신속하게 처리하는데 초점

• 싱글 모델-멀티 뷰

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

– 섞어서 개발하면 매번 같은 데이터 처리를 반복, 그리고 데이터 처리

가 변하면 다른 뷰도 같이 바꾸어야 함

(21)

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

Domain

UI Swing

ProcessSale Frame ...

... 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

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

UC에 대한 UI 설계

내부 설계

(22)

9. Case Study: 34장 NEXTGEN POS의 Layers

Log4J Technical Services

Domain UI

Pricing PricingStrategy

Factory Text ProcessSale

Console

used in quick experiments

Persistence

DBFacade

쳃nterface ISalePricingStrategy

Taxes

쳃nterface ITaxCalculatorAdapter Services

Factory Sales

Register Sale Swing

ProcessSale Frame

Payments

CreditPayment

쳃nterface ICreditAuthorization

ServiceAdapter ServiceAccess

Inventory 쳃nterface IInventoryAdapter

Jess

A general purpose third- party rules engine.

POSRuleEngine

POSRuleEngineFacade

SOAP not the Java