Transcript PPT

9장: 객체지향 분석과 설계
- Software Engineering -
1
강의 개요
 사용사례
 객체 모델링
 동적 모델링
 시스템 설계
 객체 설계
 디자인 패턴
2
소 개
 객체지향 개발
 반복 및 점증적 개발 프로세스를 사용
 설계와 구현 작업 사이에 공통의 개념들을 사용하기 때문에 전환이
용이
 객체지향 분석과 설계의 세가지 모델
객체지향 모델
기능 모델
사용사례
다이어그램
객체 모델
동적 모델
클래스 다이어그램 상태 다이어그램
순서 다이어그램
3
소 개
 성공적인 모델링을 위한 조건
 복잡한 문제라면 도메인을 잘 아는 전문가와 같이 모델링한다.
 각 모델의 목적을 잘 이해하고 모델링을 위하여 어떤 정보가 필요한지 잘 알아
둔다.
 한번 그린 모델로 만족하지 않고 계속 논의하고 향상시켜 나간다(refactoring).
 소그룹 회의를 열어 모델을 칠판에 그리고 토의한다.
 디자인 패턴을 잘 숙지하고 필요하면 이를 이용한다.
 개발 단계별 UML 다이어그램
모델종류
다이어그램
기능적모델
사용사례
객
정적모델
분석
설계
구현
체
클래스
컴포넌트
배
치
인터액션
동적모델
액티비티
상
태
4
사용 사례
 사용사례
 시스템이 수행할 것으로 기대되는 기능
 사용자 또는 시스템이나 기타 요소들이 시스템과 상호 작용하는 다이
얼로그를 모델링
 액터에 의해 구동
 구동된 후 발생되는 일연의 상호작용을 나타낸다는 의미에서 완전한
 이벤트의 흐름
 사용사례 다이어그램 구성
 액터, 사용사례, 확장관계, 포함관계
 사용사례 작성 과정
 액터찾기 -> 시나리오 찾기 -> 사용사례 작성 -> 사용사례 사이의
관계 찾기
5
액터 찾기
 액터
 시스템과 작용하는 외부 엔티티
 요구추출의 첫 단계
 시스템에 자료를 입력만 할 수도 있음
 시스템에서 정보를 받기만 할 수도 있음
 자료를 주고 정보를 받을 수 있음
 사람일 수도 있고 기계, 다른 시스템일 수도 있음
Rent Video
Add Video
Clerk
Return Video
Retire Video
Manager
6
시나리오 찾기
 시나리오
 사용 사례의 인스턴스
 단일 액터의 관점으로 시스템의 단일 기능을 비정형적으로 표현
 구체적인 상호작용 표현
 시나리오의 사용
 요구추출 과정
 리엔지니어링 작업에서 시스템을 이해할 때
 미래에 개발할 시스템에 대한 아이디어를 정리할 때
 구현된 시스템을 평가할 때
 교육을 위하여 단계적으로 사용 사례를 보여줄 때
7
시나리오 찾기
시나리오 이름:
참여액터:
시작 조건:
사건의 흐름:
종료 조건:
normalRentVideo
lee: Clerk
스캐너를 이용
1. 점원 lee가 터미널에서 "비디오 대여" 기능을 활성시킨다.
시스템이 고객 ID 입력양식을 화면에 제시하여 반응한다
2. 점원인 lee가 비디오를 대여하려는 고객에게 전화번호의
끝 네자리를 물어 '1245'를 입력한다
3. 입력한 네자리로 찾은 이름, '이동국', '김한국'을 화면에
보여주고 맞는 것을 선택하도록 한다.
4. 고객이 '이동국'이라는 것을 알려주어 선택한다.
5. 스캐너를 이용하여 대여하려는 비디오 ID('A23-4567')를
입력한다.
6. 스캔된 비디오 정보(비디오 제목과 비디오 고유번호)가
화면에 출력되고 대여중인 비디오 데이터베이스에 기록한다.
대여할 비디오가 더 있으면 반복한다.
7. lee가 대여료를 받고 테이프를 건네준다.
8
사용사례 작성
사용사례 이름:
참여 액터:
시작 조건:
사건의 흐름:
종료 조건 :
RentVideo
User에 의하여 구동됨
스캐너를 이용
1. User가 터미널에서 "비디오 대여" 기능을 활성시킨다.
시스템이 고객 ID 입력양식을 화면에 제시하여 반응한다.
2. 점원인 User가 비디오를 대여하려는 고객에게 전화번호의
끝 네자리를 물어 입력한다.
3. 입력한 네자리로 찾은 이름들을 화면에 보여주고 맞는 것을
선택하도록 한다.
4. 연체료가 있다면 화면에 출력하고 없으면 스캐너를
이용하여 대여하려는 비디오 ID를 입력한다.
5. 비디오 ID를 이용하여 비디오 정보를 찾아 화면에 출력하고
대여중인 비디오 데이터베이스에 기록한다. 대여할
비디오가 더 있으면 반복한다.
6. User가 대여료를 받고 테이프를 건네준다
9
사용사례 관계
 통신관계
 액터와 사용사례 사이의 관계
 정보의 흐름 표현
 액터는 사용사례와 통신하는 다른 액터와 구별되어야 함
 클래스의 기능을 어떤 액터가 접근할 수 있는지 접근제어 표현
 확장관계
 예외 사항을 나타내는 관계
 이벤트를 추가하여 다른 사례로 확장
 시작 조건과 종료 조건 필요
10
사용사례 관계
 포함관계
 사용사례 사이의 중복 제거
 함수의 호출처럼 포함된 사용사례를 호출하는 의미
 확장관계와 포함관계의 차이
 관계의 방향(화살표 방향)
 포함관계 – 목표 사용사례가 구동되는 조건이 출발 사용사례에 기술
 확장관계 – 확장이 적용되는 조건이 확장 사용사례의 시작조건으로 기술
 예외적이며 선택적이며 거의 발생하지 않는 경우는 확장을 사용
 두 개 이상의 사용사례가 공유하는 동작은 포함관계를 사용
11
사용사례 관계
<<extend>>
Edit Customer Profile
Clerk
Sell Videos
<<include>>
Parental authorization
Pay Late Fees
<<include>>
Return Videos
<<include>>
Get Video ID
Rent Videos
<<include>>
Add Videos
<<include>>
Manager
Scan Barcode
Type ID
Retire Videos
12
객체 모델링
 객체 모델링
 사용사례를 작성하여 도메인 분석이 어느정도 된 후 객체를 찾고 관계를
정의하는 작업
 클래스가 될 수 있는 요소들
- 구조
- 외부 시스템
- 디바이스
- 역할
- 운용절차
- 장소
- 조직
- 완성된 시스템에 의하여 조작되어야 할 정보
 클래스 후보의 세가지 유형
 엔티티 클래스
 경계 클래스
 제어 클래스
13
엔티티 클래스
 엔티티 클래스
 시스템에서 계속 추적해야 할 자료가 들어 있는 클래스
 엔티티 클래스를 발견하는 휴리스틱
 사용사례를 이해하기 위하여 사용자와 개발자가 명확히 규정된 용어
 사용사례에서 반복되어 나오는 용어
 시스템이 계속 추적하여야 하는 실세계의 엔티티
 자료저장소 또는 단말
 자주 사용하는 응용 도메인의 용어
14
경계 클래스
 시스템 외부의 액터와 상호 작용하는 클래스로
사용자 인터페이스를 제어하는 역할
 액터와 연결된 시스템의 인터페이스 표현
 사용자 인터페이스를 개괄적으로 모형화
15
제어 클래스
 경계 클래스와 엔티티 클래스 사이에 중간 역할
 사용 사례의 초기에 생성되고 끝까지 존재
 경계 클래스로부터 정보를 받아 엔티티 클래스에 전달
 예) 양식의 순서, undo, 히스토리 저장 큐 등
 자료를 다른 클래스로부터 받아 처리하는 것이 주임무인 클래스
16
연관 관계
 두 개 이상의 클래스 사이에 어떤 관계가 있음을 표현
 연관관계의 속성
 이름 : 두 클래스 사이의 연관관계 표현. 연관관계의 이름은 생략될 수도 있으
며 유일한 이름을 붙일 필요 없음
 역할 : 연관관계의 양쪽 끝에 있는 클래스의 기능 표현
 다중도 : 연관관계를 구성하는 인스턴스의 개수
 연관관계는 상태를 나타내는 동사나 동사구로 표현
 By Abbott 휴리스틱
17
연관 관계
Customer
1
Rent
*
Video Tape
Rental
Customer와 VideoTape 클래스 사이의 연관관계
RentUI
1
display
*
Video Tape
RentUI와 VideoTape 클래스 사이의 연관관계
18
속성
 개별 객체들이 가지는 특성
 속성의 요소
 이름 : 객체 안에서 구별할 수 있는 속성의 이름
 간단한 설명 : 구현하는 프로그래머를 위하여 간단히 설명 첨가
 속성값의 타입 : 예를 들어 Name 속성은 스트링. 또한 Status는 열거형으로
rentable, rented, returned라는 값을 가질수 있다.
 소유격에 따라 나오는 구나 형용사절은 속성이 가능성 높음
 엔티티 객체의 경우, 시스템에 의하여 저장될 필요가 있는 것들은
모두 속성임.
19
동적 모델링
 클래스들의 상호작용이나 클래스의 상태 변화 등 시스템 내부의
동작
 동적 모델링의 세가지 다이어그램
 상호작용 다이어그램
 상태 다이어그램
 액티비티 다이어그램
20
상호작용 다이어그램
 객체 사이의 동작을 분산시키고 오퍼레이션을 찾는데 사용
 단일 사용사례에 대한 시스템의 동작 표현
:RentUI
:Rental
:Customer
:VideoTape
:TitleI
:Clerk
1.RentVideo()
1.Create()
3.getCustomerDetail()
return()
4. 고객정보
고객확인
4.바코드스캔
4.getVideoTapeDetails()
display()
return()
4.getTitle
return()
5.getTotal()
순서 다이어그램(비디오 대여 사용사례)
21
상호작용 다이어그램
 객체 간의 메시지 호출은 반드시 호출한 객체가 속하는 클래스 안에
메소드로 구현되어야 함
Person
1..*
+setCompensation(s: Salary)
employee
*
Company
employer
+assign(d: Department)
…
Assign(d: Department)
P:Person
:Company
메시지 호출과 오퍼레이션의 관계
22
상태 다이어그램
 객체가 가질 수 있는 가능한 상태 표현
 많은 속성값과 메시지를 가진 다이나믹한 작용을 하는 객체에게만
의미가 있음
 시작노드를
으로 종료 노드를
표시
 둥근 사각형은 상태를 표현
 조건은 화살표 위에 괄호 안에 기술, 화살표는 상태의 전환 의미
23
상태 다이어그램
 상태 다이어그램을 모델링하기에 적합한 속성의 조건
 속성의 값으로 가질 수 있는 종류가 적어야 한다.
 속성의 값에 따라 허용되는 오퍼레이션이 제한되어야 한다.
Athorizing
[age>18]
[age<=18]
그림 9.13 상태 다이어그램의 예
Athorizing
Athorizing
Athorizing
24
액티비티 다이어그램
 시스템의 동적이 부분을 모델링하는 목적으로 사용
 액티비티 사이의 제어흐름을 보여 주는 일종의 흐름도
 액티비티 다이어그램의 사용
 시스템의 수준에서 시스템과 상호작용하는 각 액터의 관점에서 모델링
 복잡한 오퍼레이션의 수행흐름을 표현
25
시스템 설계
 객체지향 설계
 시스템 설계 : 분석 모형을 시스템 설계 모형으로 변환
 객체 설계 : 시스템을 이루는 객체 부품을 설계
 시스템 설계
 시스템을 구성할 하드웨어와 소프트웨어 플랫폼을 정의하고
 시스템의 구조를 정의하며 서브 시스템으로 쪼개어 정의하는 작업
 시스템 설계의 구성
 설계 목표의 정의 : 시스템 구조를 설계하기 위한 시스템의 특성,
목표파악
 패키지 다이어그램 작성 : 컴포넌트를 파악하여 서브 시스템으로 분할
 배치 다이어그램 작성 : 서브 시스템에 프로세서를 할당
 자료 저장소의 정의 : 데이터베이스 설계
26
설계 목표의 정의
 액터의 시각으로 본 시스템을 기술한 분석모형
 시스템 설계 작업의 두 가지 결과
 최적화 하여야 할 시스템의 품질을 기술
 소프트웨어의 구조 (서브시스템의 역할, 서브시스템 사이의 관계 하드웨어 매
핑, 제어구조, 저장소 등)
 비기능적인 요구나 응용 도메인으로부터 유추
 성능평가 기준
 시스템에 대한 속도와 기억공간에 대한 요구
27
설계 목표와 평가 기준
평가기준
성
능
의 존 성
설계조건
반응시간
처리량
기억공간
강인성
신뢰성
고장감내성
보안
안전
비
용
개발비용
설치비용
업그레이드비용
정
의
작업이 요청된 후 얼마나 빨리 확인되는가?
단위 시간 당 처리되는 작업의 량은?
시스템이 수행되기 위하여 필요한 기억공간은?
입력 오류에도 잘 작동할 수 있는 능력
명시된 동작과 실제 실행 동작의 차이
정상적인 작업을 수행하는 기간의 비율
오류 조건에도 제대로 작동할 수 있는 능력
악의가 있는 침입에도 견딜 수 있는 능력
오류와 오작동에도 인명에 위험을 주지 않는 능력
유지보수비용
운영비용
초판 시스템을 개발하는데 드는 비용
시스템을 설치하고 사용자를 교육하는데 드는 비용
과거 시스템의 자료를 전환하는데 드는 비용
과거 버전과의 호환성 확보 기준이 된다.
시스템에 대한 오류를 수정하고 향상시키는데 필요한 비용
시스템을 운영하는데 소요되는 비용
유지보수성
확장성
변경가능성
적응성
이식성
이해성
요구 추적가능성
시스템에 기능이나 새로운 클래스를 추가하기 쉬운가?
시스템의 기능을 얼마나 쉽게 변경할 수 있나?
다른 응용 도메인에 시스템을 얼마나 쉽게 이식 할 수있나?
다른 플랫폼에 시스템을 얼마나 쉽게 이식할 수 있나?
원시코드를 읽어 얼마나 쉽게 시스템을 이해할 수 있는가?
특정 요구를 원시코드에서 얼마나 쉽게 찾을 수 있는가?
사 용 성
유틸리티
사용용이성
사용자의 작업을 얼마나 잘 지원하는가?
시스템을 얼마나 쉽게 사용할 수 있나?
28
패키지 다이어그램
 UML에서 서브 시스템을 표현할 때 패키지라는 개념 도입
 패키지
 클래스를 의미 있는 관련된 그룹으로 구성하는 메커니즘
 패키지 사용의 장점
 복잡한 시스템을 서브시스템으로 나누어 적절히 컨트롤
 패키지 이름을 정의하여 알고 있으면 외부에서 패키지 안의 자세한 사항을 모
드더라도 import하여 사용가능
 소프트웨어 구조를 표현하는데 적합
 패키지가 클래스의 그룹이므로 높은 수준의 추상화된 서브 시스템을 표현 가
능
29
패키지 다이어그램
Clerk User Interface
(to Business
System)
Customer
<<façade>>
Business
System Client
myGUI
Java.awt
RentalUI
패키지 다이어그램에서의 의존관계
패키지로 그려진 서브 시스템
30
배치 다이어그램
 소프트웨어 컴포넌트가 어떤 하드웨어 노드에 배치되어야
하는지를 표현
 배치 서브 시스템은 객체와 서브 시스템의 하드웨어 할당 표현
:Store Server
Phone Clerk Terminal
:Clerk Client
Check Out Terminal
:Clerk Client
Server
DB
«TCP/IP»
«TCP/IP»
Store
Server
App
배치 다이어그램
31
저장소의 설계
 영구 데이터는 시스템의 수행이 끝난 뒤에도 보관
 데이터를 데이터베이스에 저장하면 대량의 데이터에 대하여
복잡한 질의 가능
 데이터베이스 관리 시스템의 선택
 전체 제어 방식과 병렬 관리를 확정하는 의미
 저장소를 구현하는 세 가지 방법
 파일, 관계형 데이터베이스, 객체지향 데이터베이스
32
객체 설계
 응용 객체를 구현 객체로 바꾸는 작업
 객체 설계 작업의 구성
 객체 서비스 정의
 부품 선택
 재구조화
 최적화
33
객체 서비스 정의
 서브시스템의 서비스는 오퍼레이
션, 매개변수, 타입, 예외사항을
포함한 클래스 인터페이스로 정의
 서브시스템의 서비스 인터페이스
- API(Application Programmer
Interface)
Hashtable
-numElement: int
+put(key:Object entry:Object)
+set(key: Object): Object
+remove(key:Object entry:Object)
+containKey(key: Object): boolean
+size(): int
class Hashtable {
private int numElements;
 객체 설계 단계에는 타입과 가시
성을 추가하여 분석과 설계 모형
을 상세화
/* Constructors omitted */
public void put (Object key, Object entry) ..;
public Object get(Object key) ...;
public void remove(Object key) ...;
public boolean containsKey(Object key) ...;
public int size() ...;
/* Other methods omitted */
}
Hashtable 클래스의 정의(UML 클래스 모형과 Java 코드)
34
부품 선택
 컴포넌트를 선택하는 주요 목적
 가능한 많은 객체를 재사용하여 따로 개발하여야 하는 객체의 수를
줄이는 것
 프레임워크란?
 실정에 맞도록 커스터마이즈할 수 있게 고안된 재사용 가능한 부분적
인 응용 프로그램
 응용 프레임워크의 장점
 재사용과 확장
 프레임워크의 위치에 따른 세가지 분류
 인프로구조 프레임워크, 미들웨어 프레임워크,엔터프라이즈 응용 프
레임워크
 프레임워크를 확장하는데 사용되는 기술에 따른 분류
 화이트박스 프레임워크
 블랙박스 프레임워크
35
부품 선택
 화이트박스 프레임워크
 프레임워크의 내부 구조에 대한 사전 지식 필요
 완성된 시스템이 프레임워크의 상속 구조와 밀접하게 의존되어 있어
 프레임워크에 대한 변경이 있을 때 응용 시스템을 다시 컴파일하여야
함
 블랙박스 프레임워크
 화이트박스 프레임워크보다 사용 용이
 상속보다는 위임 방법 사용
 다양하게 사용될 인터페이스와 후크를 정의하여야 하기 때문에 개발이
어려움
 정적 클래스보다 동적 객체 관계를 강조하기 때문에 확장과 재구성이
용이
36
재구조화
 재구성에 필요한 세 가지 작업
 관계의 구현
 재사용도를 높이기 위한 상속 재검토
 구현 의존도를 낮추기 위한 상속 재검토
 상속
 유사한 클래스들 사이에 재사용을 가능하게 한다.
 설계가 잘된 상속의 장점
 많은 코드를 재사용할 수 있고 중복을 줄이며 오류 가능성을 줄인다.
 일반화 메커니즘을 사용된 경우는 응용과 의존도가 적어진다.
37
최적화
 최적화를 위해 필요한 세 가지 작업
 접근경로를 최적화하기 위하여 연관관계를 추가
 객체를 속성으로 축소
 복잡한 계산은 연기
 시스템의 효율성은 높이지만 시스템을 더 복잡하게 하고 이해하기
어렵게 함.
38
7.1 패턴 소개
 프로그램 개발에 자주 등장하는 문제를 기술하고 같은 작업을 반복
하여 설계하지 않고 여러 번 반복하여 사용할 수 있는 문제에 대한
솔루션을 기술한 것
 전문가의 노하우를 모아놓은 것
 전문가의 경험이므로 적용하여 좋은 설계가 되도록 도와 줌
• 코드가 더 견고하게 함
• 재사용 용이하게 함
 공통의 설계 목표를 만족시키는 클래스의 조합, 협력 알고리즘
 여러 번의 시행착오를 거치면서 비슷한 역할의 클래스를 자주 쓰게 됨
 이를 잘 모아 목록화 한 것
39
디자인 패턴
 패턴




여러 가지 상환에 적용될 수 있는 템플릿과 같은 것
문제에 대한 설계를 추상적으로 표현한 것
문제를 해결하려는 요소들을 일반화하여 잘 정리한 것
커스텀화된 객체나 클래스의 연결을 나타낸 것
 패턴의 구성 요소
 패턴의 이름과 구분 : 패턴을 부를 때 사용하는 이름과 패턴의 유형
 문제 및 배경 : 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의
미
 솔루션 : 패턴을 이루는 요소들, 관계, 협동 과정
 사례 : 간단한 적용 사례
 결과 : 패턴을 사용하면 얻게되는 이점이나 영향
 샘플 코드 : 패턴이 적용된 원시코드
40
패턴의 분류[Gamma, 1995]
목적에 의한 분류
생성유형
클래스
범위
객체
구조적
행위적
Factory method
Adapter(class)
Interpreter
Template method
Abstract factory
Singleton
Prototype
Builder
Adapter(object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
41
Visitor 패턴
 클래스에 속한 모든 객체들에 수행되는 오퍼레이션을 표현할 때
사용
 여러 종류의 노드 클래스 사이에 오퍼레이션이 분산되어 복잡한
시스템을 구성
 새로운 오퍼레이션을 추가하려면 모든 클래스에 코드를 추가하
고 컴파일을 다시 하여야 함
 해결책
 각 클래스로부터 관련된 오퍼레이션을 Visitor라고 불리는 분리된 객체로
떼어내어 패키지화 하면 효율적
42
Visitor 패턴
Node
TypeCkeck()
GenerateCode()
PrettyPrint()
VariableRefNode
TypeCkeck()
GenerateCode()
PrettyPrint()
AssignmentNode
TypeCkeck()
GenerateCode()
PrettyPrint()
그림 9.21 Visitor 패턴이 사용되어야 할 사례
43
Visitor 패턴
NodeVisitor
VisitAssignment(AssugnmentNode )
VisitVariable(VariableNode )
TypeCheckingVistor
CodeGeneratingVistor
VisitAssignment(AssugnmentNode )
VisitVariable(VariableNode )
VisitAssignment(AssugnmentNode )
VisitVariable(VariableNode )
Node
Acceot(NodeVisitor )
Program
AssignmentNode
Accept(NodeVisitor )
V->VisitConcreteElementA (this)
VariableRefNode
Accept(NodeVisitor )
V->VisitConcreteElementB (this)
그림 9.22 Visitor 패턴이 사용된 사례
44
Observer 패턴
 1대 다의 객체 의존관계를 정의한 것
 한 객체가 상태를 변화시켰을 때 의존관계에 있는 다른 객체들에게 자동적
으로 통지하고 변화시킴. 일명 publish-subscribe패턴
Subject
A ttach(O bserv er)
Detach(O bserv er)
Notify ()
Observer
Update()
for all o in observ er {
o->U pdate()
}
ConcreteObserver
O bserv erState
ConcreteSubject
subjectState
Update()
GetState()
SetState()
return subjectState
observ erState =
subject->GetState()
그림 9.23 Observer패턴
45
Observer 패턴
cC oncreteSubject
aC oncreteO bserv er
anotherC oncreteO bserv er
GetS tate()
Notify ()
U pdate()
SetS tate()
U pdate()
GetS tate()
그림 9.24 Observer패턴의 협동 과정
46
Factory 패턴
 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가
인스턴스화 될 것인지는 서브클래스가 결정하도록 하는 것
일명 Virtual Constructor이라고 부름
Document
Open()
Close()
Save()
Revert()
MyDocument
A pplication
CreateDocument()
NewDocument()
OpenDocument()
Document * doc =
CreateDocument();
docs.Add(doc);
doc->open();
MyApplication
CreateDocument()
Return new MyDocument
그림 9.25 Factory 패턴의 동기
47
Factory 패턴
 9.25와 같이 구현하면 클래스 Application이 일일이 MyDocument
라는 클래스의 객체를 생성하는 것을 신경 써야 한다.
서브 클래스가 이런 일을 담당하게 하고 싶을 때 사용하는 것이
바로 Factory패턴이다.
Creator
Product
ConcreteProduct
FactoryMethod()
AnOperation()
…
Product =
FactoryMethod();
ConcreteCreator
FactoryMethod()
Return newConcreteProduct
그림 9.26 Factory 패턴
48