Component-Level Design · 4. 영구적 데이터 소스 (데이터베이스와 파일)을...

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Component-Level Design

CSE4006 Software Engineering


What is Component ?

!2

• OMG UML Specification에서 컴포넌트를 아래와 같이 정의 : • “a modular, deployable, and replaceable part of a system that

encapsulates implementation and exposes a set of interfaces” • “구현을 캡슐화하고 일련의 인터페이스를 노출하는 모듈식이고, 배포가능하며, 교체 가능한 시스템의 일부”

• 객체지향 관점 • 컴포넌트는 협력하는 클래스들의 집합을 포함

• 전통적인 관점 • 로직, 프로세스 과정을 구현하기 위해 필요한 내부 자료 구조, 컴포넌트의 호출과 데이터 전달을 가능하게 하는 인터페이스


Object-Oriented Component

!3


Component-Level Design

!4


Basic Design Principles

!5

• Open-Closed Principle (OCP) - 개방-폐쇠 원칙• 모듈은 확장을 위해 열여 있어야 하지만 수정을 위해 닫혀 있어야 한다

• Liskov Substitution Principle (LSP) - 리스코프 치환 법칙 • 서브 클래스는 기본 (base) / 부모 클래스로 대체 가능해야 한다

• Dependency Inversion Principle (DIP) - 의존성 역적 법칙 • 구체에 의존하지 말고 추상화에 의존하라

• Interface Segregation Principle (ISP) - 인터페이스 분리 원칙 • 많은 클라이언트 특정 인터페이스가 하나의 범용 인터페이스 보다 낮다

• Release Reuse Equivalence Principle (REP) • 재사용의 작은 조각 (granule)은 릴리즈의 작은 조각이다

• Common Closure Principle (CCP) • 함께 변하는 클래스는 함께 속함

• Common Reuse Principle (CRP) • 함께 재사용되지 않는 클래스는 같이 그룹화해서는 안됨


Design Guidelines

!6

• 컴포넌트 • 아키텍처 모델의 일부로 지정된 컴포넌트는 명명 규칙 설정 후 컴포넌트 수준의 모델의 일부로 정제하고 정교화 - 아키텍처 컴포넌트 이름은 문제 도메인에서 가져와 모든 이해관계자에게 의미를 부여해야 함

- 인프라구조 컴포넌트 또는 진화된 컴포넌트 수준 클래스는 구현 특정 의미를 반영하여 명명해야 함

- 상세 설계 수준에서 컴포넌트의 본질 식별을 위해 스테레오 (stereotype) 타입 사용 가능

e.g., <<infrastructure>> <<database>> <<table>>


Design Guidelines

!7

• 인터페이스 • 상호작용 및 협업에 대한 중요 정보 제공 • 개방-폐쇠 원칙 (OCP) 달성을 위해

• 종속성 (dependencies)과 상속 (inheritance) • 가독성 (readability)을 높이기 위해

- 왼쪽에서 오른쪽으로 종속성 모델링

- 아래 (derived) 클래스에서 위 (base) 클래스로 상속관계를 모델링


Cohesion

!8

• 전통적인 방법 • 모듈의 “single-mindedness”

• 객체지향 방법

• 컴포넌트나 클래스는 서로 긴밀하게 연관된 속성과 연산들만 캡슐화 • 응집도 (Cohesion)의 종류

• 기능적 (functional) • 순차적 (sequential) : 첫 연산에서 다름 연산으로 데이터 전달 • 교환적 (communicational) : 동일한 데이터를 사용하는 연산의 모임 • 절차적 (procedural) : 같은 범주에 속하는 일들이 순차적으로 모임 (순차적과 비슷하나 데이터 전달이 없음)

• 시간적 (temporal) : 오류 처리 및 초기화와 같이 한번만 수행되는 요소들 • 우연적 (coincidental) : 관련 없는 연산들이 한 모듈에 모임


Coupling

!9

• 전통적인 방법 • 컴포넌트가 다른 컴포넌트와 외부 세계에 연결되는 정도

• 객체지향 방법

• 클래스 사이 연결 정도의 질적 척도 • 결합도 (Coupling)의 종류

• 내용 (content) : 한 컴포넌트가 다른 컴포넌트의 데이터 수정

• 공통 (common) : 컴포넌트가 전역변수 사용

• 제어 (control) : A가 B를 호출하고 B에 제어신호 (control flag)를 전달 • 타입 사용 (type use) : A 클래스가 B 클래스에서 정의된 데이터 타입 사용

• 포함 (inclusion or import) : 컴포넌트 내용 및 패키지를 포함 (import or include)


Component Level Design

!10

1. 문제 도메인에 대응되는 모든 설계 클래스 식별

2. 인프라구조 도메인에 대응되는 모든 설계 클래스 식별

e.g., GUI, 운영체제, 객체 & 데이터 관리 컴포넌트 등

3. 재사용 가능 컴포넌트로 획득하지 않은 모든 설계 클래스 다듬기 (elaborate) i) 클래스나 컴포넌트가 협력할 때 메세지의 구체적 내용 기술

(collaboration diagram의 메세지 구체화)

ii) 각 컴포넌트에 적절한 인터페이스 식별

iii) 속성을 다듬고 구현에 필요한 데이터 타입과 데이터 구조 정의

iv) 각 연산의 처리 흐름 (activity diagram)을 상사하게 기술


Component Level Design

!11

4. 영구적 데이터 소스 (데이터베이스와 파일)을 기술하고 이를 관리하기 위해 필요한 클래스 식별

5. 클래스나 컴포넌트에 대한 동작의 표현 (state chart)을 개발하고 다듬기

6. 부가적인 구현 사항을 제공하기 위해 deployment diagram 다듬기

7. 모든 컴포넌트 수준의 설계를 리팩터링하고 항상 대안을 고려


Collaboration Diagram

!12


Refactoring

!13


Processing Flow in Activity Diagram

!14


Behavioral Representation in Statechart

!15


Object Constraint Language (OCL)

!16

• UML의 보완 : 정형 문법 및 구문을 사용하여 다양한 설계 모델 요소에 대한 모호하지 않은 서술을 구성

• 간단한 OCL 문장은 4부분으로 구성 :

1. context는 문장이 유효한 제한된 상황 정의

2. property는 상황 (context)의 특징 표현

(예 - context가 클래스라면 property는 속성)

3. operation (예 - arithmetic, set-oriented)은 property 를 처리하거나 권한을 줌

4. keyword (예 - if, then, else, and, or, not, implies)는 조건부 표현 (conditional expressions)을 기술하기 위해 사용


OCL Example

!17


Algorithm Design

!18

• 코딩에 가장 가까운 설계 활동 • 접근 방법 :

• 컴포넌트에 대한 설계 기술서를 검토 • 알고리즘 개발을 위한 단계적 정제 (stepwise

refinement) 사용 • 처리 절차 로직(procedural logic) 구현을 위해 구조적 프로그래밍 (structured programming) 사용

• 로직 증명을 위해 정형 기법 (formal method) 사용


Stepwise Refinement

!19


Algorithm Design Model

!20

• 품질 검토가 가능할 만큼의 세부 수준으로 알고리즘을 표현 • 표현 방식 :

• graphical (예 - flowchart, box diagram) • 수도코드 (pseudocode) (예 - PDL … 등 다양함) • 프로그래밍 언어 • decision table


Structured Programming for Procedural Design

!21

• 제한된 논리적 생성자 (logical constructs) 사용 • 순차 (sequence) • 조건 (conditional) : if-then-else, select-case • 순환 반복 (loops) : do-while, repeat until

• 읽고 테스트하기 쉬운 코드 생성으로 이어짐 • ‘정확성 증명’과 함께 사용 가능 • 높은 품질 달성에 중요하지만 충분하지는 않음


A Structured Procedural Design (Flow Chart)

!22


Decision Table

!23

• 컴포넌트 내 복잡한 조건이나 행위의 집합이 존제한다면 의사결정표 (decision table) 사용


Program Design Language (PDL)

!24

• 소스 코드와 결합이 용이 • 매우 상새한 부분까지 표현 가능 • machine readable, graphics 입력 불필요 • 시각화는 PDL로부터 생성 가능 • 데이터와 프로시저 선언을 가능하게 함 • 검토 및 유지보수 용이


Component-Based Development (CBD)

!25

• 재사용 가능성과 직면하면, 소프트웨어 팀은 : • 요구사항을 구현할 수 있는 상용 (commercial) off-the-

shelf (COTS) 컴포넌트가 존재하는가? • 요구사항을 구현할 수 있는 내부적으로 개발한 재사용 가능한 컴포넌트가 존재하는가?

• 구축할 시스템의 아키텍처에 호환되는 컴포넌트를 위한 인 인터페이스는 존재하는가?

• 동시에, 다음과 같이 재사용을 위한 장애물 (impediments)에 직면 …


Impediments to Reuse

!26

• 포괄적 소프트웨어 재사용 계획과 비슷하기라도 한것을 가진 회사 및 조직은 몇 안됨

• 현재 소프트웨어 재사용에 직접적인 지원을 제공하는 도구 혹은 컴포넌트를 판매하는 공급 업체는 늘고 있지만 대부분의 개발자는 이를 사용하지 않음

• 소프트웨어 엔지니어와 관리자가 재사용을 이해하고 적용하는데 도움이 되는 교육/훈련은 거의 없음

• 많은 실무자들은 '재사용의 가치 보다 문제가 더 크다’고 믿고 있음 • 많은 기업들이 재사용을 용이하게하지 못하는 소프트웨어 개발 방법론을 계속 장려함

• 소수의 기업들이 재사용 가능한 컴포넌트 생산에 인센티브 제공


Component-Based Software Engineering Process

!27


Domain Engineering

!28

1. 조사할 도메인 정의

2. 도에인에서 추출한 항목 분류

3. 도메인에서 응용프로그램의 대표 샘플 수집

4. 각 샘플 응용프로그램 분석

5. 객체에 대한 분석 모델 (analysis model) 개발


Identifying Reusable Components

!29

• 향후 구현 시 컴포넌트 기능이 필요한가? • 도메인 내에서 컴포넌트의 기능은 얼마나 공통적인가? • 도메인 내에서 컴포넌트의 기능 중복이 존재하는가? • 컴포넌트가 하드웨어 종속적인가? • 구현 간 하드웨어는 변경되지 않고 그대로 유지되나? • 하드웨어 사양을 다른 컴포넌트로 제거할 수 있는가? • 다음 구현을 위해 디자인이 충분히 최적화 되었는가? • 재사용 할 수 없는 컴포넌트를 매개 변수화하면 재사용이 가능한가? • 사소한 변경만으로 컴포넌트가 많은 구현에서 재사용 가능한가? • 수정을 통한 재사용이 가능한가? • 재사용 할 수 없는 컴포넌트를 분해하면 재사용이 가능한가? • 재사용을 위한 컴포넌트 분해가 얼마나 유효한가?


Component-Based Software Engineering

!30

• 컴포넌트의 라이브러리가 존재해야 함 • 컴포넌트는 일관된 구조를 가져야 함 • 다음과 같은 표준이 있어야 함 :

• OMG/CORBA • Microsoft COM • Oracle JavaBeans

Component-Level Design · 4. 영구적 데이터 소스 (데이터베이스와 파일)을...

Documents

Transcript of Component-Level Design · 4. 영구적 데이터 소스 (데이터베이스와 파일)을...