Transcript PPT - DKE

8장: 객체지향 기초
- Software Engineering -
1
강의 개요
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
2
왜 객체지향 방법인가?
 소프트웨어 위기
 시스템을 쉽게 구축할 수 있는 방법
 문제를 정확히 해결
 적절한 작업
 유지보수 가능
 확장 가능
 재사용 가능
 응용문제를 더 쉽게 인식
 구현이 덜 복잡해짐
 자료구조와 함수의 결합이 자연스러움
 분석과 구현 사이의 차이가 적음
3
왜 객체지향 방법인가?
 잘 설계된 객체의 집합은 재사용과 변경이 용이
 의사교환이 효과적인 비주얼 모델링
 모델링 과정에 사용자와 개발자 사이에 공통으로 이해할 수 있는
용어와 개념
 객체모델을 이해하기 위하여 꼭 프로그래머일 필요 없음
 비용의 절감
객체는 이런 장점이 있지만 모든 것을 자동으로 제공하지는 않음
4
객체지향 기초
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
5
객체지향의 특징
 모형의 적합성
 객체중심 모형은 우리의 사고 방식과 유사
 뚜렷하게 구별되는 객체로 나누고 객체들의 메시지 패싱이
모여 프로그램이 됨
 재사용 용이
 openness, closeness를 다 갖춘 재사용 단위
 상속(inheritance), 다형성(polymorphism)
 Time – to – market
 종래의 폭포수모형은 단계가 길고 문서 작업이 많음
 클래스의 재사용과 확장에 의한 빠른 개발이 가능
 설계와 프로그램의 매핑
 개발 각 단계의 전환이 자연스럽고 신속
6
객체지향 기초
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
7
객체지향 시스템의 구조
 재래식 방법
 객체 지향 방법
 기능중심, 변경의 파급효과 큼
 자료와 관련 함수의 결합
프로그램= 자료구조 + 함수
프로그램= 자료구조 + 함수
자료
함수1
함수2
프로그램 = 객 체 + 객 체
자료
자료
함수
함수
자료
자료
함수
함수
함수3
8
객체지향
 절차적 패러다임
 소프트웨어가 프로시저 단위로 구성됨
 프로시저 추상
• 단순한 데이터에는 적합하나 복잡한 데이터를 가진 응용문제에는 부적합
 데이터 추상
• 특정한 의미를 이루는 데이터의 조각들을 모아 그루핑
• 시스템의 복잡도를 줄이는데 도움
– 예) 레코드나 구조체
 객체지향 패러다임
 프로시저 추상을 데이터 추상 관점으로 구성
9
객체지향 패러다임
문제를 해결하기 위한 모든 계산이
객체(object)라는 것을 기본으로 수행되는 방법
 객체는 클래스의 인스턴스. 클래스는
 자료가 추상화된 것이며, 동시에
 객체를 조작하는 프로시저에 대한 추상
 실행 프로그램은 특정 작업을 수행하기 위하여 모인 객체의 집합
10
구조 비교
절차적 패러다임
객체지향 패러다임
11
객체
 객체의 정의
 소프트웨어 모듈(객체) = 자료구조 + 함수
 객체는 상태(state), 능력(behavior), 정체성(identity)을 가진다.
 객체
 실행되는 소프트웨어 시스템에 존재하는 구조화된 데이터의 덩어리
 성질(property)를 가짐
• 객체의 상태(state)를 나타냄
 행위(behavior)를 가짐
• 어떤 식으로 작용하고 반응하는지를 나타냄
• 실세계에 존재하는 객체의 행위를 시뮬레이션 할 수도 있음
 정체성 : 구별 가능성
 객체 인스턴스(instance) = 객체
 비슷한 객체의 구조와 행동은 공통 클래스로 선언
12
객체
13
클 래 스(Class)

클래스
 객체지향 프로그램에서 추상화의 단위
직원클래스
 유사 객체들을 정의
•
인스턴스
 소프트웨어 모듈
•
•
인스턴스의 구조(속성)를 나타냄
행위를 구현하는 메소드를 가짐
 클래스(class) vs 인스턴스 (instance)
홍길동 객체
 클래스 : 객체의 타입(object type)
 인스턴스 : 클래스에 속하는 개개의 객체
 클래스의 속성(attribute)
 예 : 직원 클래스
•
•
속성 : 이름, 직위, 월급, 전화 번호 등
함수 : 진급, 월급 인상, 전화 변경 등
 클래스는 객체들이 갖는 속성과 적용 연산을 정의하고 있는 틀(templet)
 Employee
 Employee*
Hong_kildong();
Hone_kildong = new Emplyoee();
14
클래스 이름 붙이기
 대문자로 시작
 bankAccount(X)
 BankAccount(o)
 단수형 명사
 일반적으로 적용되는 명사
 시/도 – Municipality(o), City(X)
 오직 하나의 의미만 갖도록 명명
 Bus – 노선, 버스차량
15
캡 슐 화(Encapsulation)
 캡슐화의 정의
 관련된 항목을 모아서 갭슐을 씌움
• 예> 학사 관리 시스템
• 데이터 : 학번, 이름, 주소 캡슐화
• 함수 : 평점 계산, 주소 변경, 수강 신청 캡슐화
 추상화의 수단
 세부사항은 차후에 생각
 정보은닉(information hiding)
 외부의 직접적 접근 불가, 일종의 블랙박스
 구현에 따라 선택 가능
 문법 : public, private, protected
16
상 속(inheritance)
 상속의 의미
 상위 클래스의 속성과 연산을 물려 받음
 슈퍼클래스(superclass), 서브 클래스(subclass)
 예>직원 : 슈퍼클래스 , 관리자 : 서브클래스
 복수상속 (multiple inheritance)
 두개 이상의 수퍼클래스에서 상속 받음
인사대상
학생
학부생
교수
직원
대학원생
17
상속
 슈퍼 클래스
 서브 클래스의 공통적인 기능(feature)들을 가짐
 상속 구조
 슈퍼 클래스와 서브 클래스 사이의 관계를 나타냄
 삼각형 화살표는 일반화(generalization)을 나타냄
 상속(inheritance)
 슈퍼 클래스에 정의한 기능들을 서브 클래스가 묵시적으로 소유하는
것
18
상속 구조의 예
Account
SavingsAccount
ChequingAccount
MortgageAccount
 상속(inheritance)
 슈퍼 클래스에 정의한 기능들을 서브 클래스가 묵시적으로 소유
하는 것
19
Is-a 관계
 일반화를 확인하려면 Is-a 관계를 만족시키는지를 체크
 “A saving account is an account.”
(보통예금 구좌는 은행구좌의 일종이다.)
 “A graduate student is a student.”
(대학원생은 학생의 일종이다.)
 “A school is a university.”가 성립하나?
 Is-a 관계가 아님.
• ‘대학교는 학교의 일종이다.’가 되어야 함
20
기하학에서의 상속구조
21
상속 구조
 상속된 모든 기능이 서브클래스에서도 의미가 통하는지 확인
22
다 형 성(polymorphism)
 하나의 추상 오퍼레이션이 서로 다른 클래스에서 다른 방법으로 구현될 수
있는 객체지향의 성질
 같은 이름을 가진 여러 개의 다른 메소드가 있어야 함
 어떤 메소드가 실행될지는 변수 안에 있는 객체의 종류에 좌우 됨
 If-else나 switch 문장을 줄여주는 효과
 다형성의 정의
 여러 형태를 가지고 있다 (=여러 형태를 받아들일 수 있다)
 같은 이름의 메시지를 다른 객체 or 서브클래스에서 호출
 예> getarea() 를 도형의 모양이 달라도 호출
 메소드:특정한 클래스를 위하여 오퍼레이션을 구현
 하나 이상의 메소드를 가진 오퍼레이션
 매개변수나 객체가 속한 클래스의 이름으로 구분
23
다 형 성(polymorphism)
 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가
할 수 있음
Polygon
Area
getarea()
Circle
Rectangle
getarea()
getarea()
다형성의 예
24
다형성
 Polymorphism
 Universal
• 타입이 달라도 같은 code를 수행
 ad hoc
• 타입이 다르면 다른 version의 code를 수행
 Universal
 parametric : General function
 inclusion : subtype, inheritance
 ad hoc
 overloading : + (문자열의 더하기, 정수의 더하기)
 coercion : 3+4.0 => 3+4 또는 3.0+4.0으로 타입변환(coercion)
25
객체지향 기초
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
26
객체지향 프로세스
 객체지향 프로세스의 특징
 일관성
 클래스에 대한 세가지 관점
 정적 관점: 객체, 속성, 행위, 객체들의 관계
 동적 관점: 객체 사이의 메시지 교환, 제어, 타이밍, 상태 변화
 제한적 관점: 속성값, 다중도 등의 구조와 동적 행위
 분석, 설계, 코딩, 테스트 단계
 라이프 사이클 유형
 폭포형, 나선형, RUP(Rational Unified Process)등
27
객체지향 분석
 객체지향 요구분석
 사용자의 요구를 기능적 관점으로 파악하여 사용 사례
다이어그램으로 나타냄
 요구추출
 사용사례를 찾아내고 이를 다이어그램으로 작성
 사용사례로부터 기능파악
 요구분석(추출된 요구 정리)
 객체를 찾고 객체 사이의 관계를 정리
 순서다이어그램, 상태다이어그램을 작성하여 동적모형을 완성
28
객체지향 분석
요구 추출
①액터찾기
②시나리오 찾기
③사용사례 찾기
④사용사례 구체화
⑤사용사례 관계 찾기
사용사례
다이어그램
⑥비기능 요구 찾기
요구 분석
①객체찾기
②객체 상호작용 모형화
③객체 연관관계
④객체속성 찾기
⑤상태 다이어그램 작성
⑥분석 모형 검토
분석모형
(클래스,
순서다이어그램)
29
객체지향 설계
 분석 모형은 시스템의 기능에 대한 사용 사례 측면의 분
석과 객체들의 관계 분석, 객체 사이의 상호작용
분석
 설계 : 분석 모형을 시스템 설계 모형으로 변환
 설계 모형 : 시스템 구조에 대한 모형, 객체 모형
 솔루션 객체 파악
 기술에 종속된 객체
 사용자 인터페이스, 데이터베이스, 통신 프로토콜 등
30
객체지향 설계
시스템 설계
①설계 목표 정의
②서브 시스템 파악
③자료 저장소 설계
패키지
다이어그램
객체 설계
①객체 정의
②부품선택 또는
최적화
상세화된 클래스
다이어그램
31
객체지향 코딩과 테스트
 객체모형, 클래스 다이어그램을 바탕으로 코딩
 재사용을 위해 일반화
 절차적 프로그램 테스트와 유사
 단위테스트 → 통합 테스트 → 시스템 단위 테스트
시스템
인수테스트
시스템 시험
서브 시스템
추상화 수준
클래스 상속 구조
통합테스트
단위 시험
클래스
32
RUP(Rational Unified Process)
 RUP는 객체지향 분석 설계 방법을 반복적인 라이프 사이클
로 만든 것
 한 사이클이 끝날 때마다 테스트가 완료
 통합 및 수행 가능한 시스템이 산출
 각 사이클에서 요구분석, 설계, 구현, 테스트 반복(iteration)
 피드백, 완성도 높은 시스템
 점증적 반복 (incremental and iterative )
요구분석
요구분석
설 계
설 계
구현 및 테스트
설계 보완
구현 및 테스트
설계 보완
반복1
통합 및 시스템
테스트
시스템 V.1.0
반복2
통합 및 시스템
테스트
시스템 V.2.0
33
RUP의 특징과 장점
 RUP특징과 장점
 반복 과정에서 높은 위험도를 잘 관리할 수 있다.
 반복 릴리스와 피드백을 통하여 요구 사항을 만족시킬 수 있다.
 초기 반복에서 소프트웨어 구조를 잘 확립할 수 있다.
 시스템을 가시적인 모델(즉, UML)로 표현할 수 있다.
 소프트웨어의 변경을 잘 관리할 수 있다.
개발 사이클
반복
개념정립
전
개
반복 종료지점
단계
구 축
중간 릴리스
전 환
최종제품 릴리스
34
RUP의 단계
 RUP의 단계
 개념정립(inception) - 비전, 비즈니스 케이스, 범위를 개략적
으로 파악하는 단계.각 사이클에서 요구분석, 설계, 구현, 테스
트 반복(iteration)
 전개(elaboration) - 비전을 구체화하고, 중심되는 소프트웨어
구조를 반복적으로 구현해 보아 시스템의 뼈대를 확립한다. 중
요한 요구를 찾아내고 범위를 정한다.
 구축(construction) - 남아 있는 덜 중요한 부분을 구현하고
설치를 준비한다.
 전환(transition) - 테스트, 설치, 다음 반복 단계 준비
35
객체지향 기초
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
36
4.1 UML이란?
 UML탄생
 1980년대 말부터 1990년대 초에 객체지향으로 모델링 하는 과정과 모델링 언
어 출현
 설계와 표현 방법의 급증으로 혼란을 초래
 Rumbaugh와 Booch가 1994년 두 가지 방법을 합병하기로 함
• Rational Software 라는 회사 설립
• OMT(Object Modeling Technique와, Booch, OOSE(Object-Oriented
Software Engineering) 방법의 통합
• Shlare/Mellor, Coad/Yourdon, Wirfs-Brock, Martin/Odell 방법의 영향
 1995년 Jacobson이 팀에 합류
• 사용 사례를 제안
 1997년 Object Management Group(OMG)이 UML 표준화 추진
 모델링 과정(modeling process)과 모델링 언어(modeling
language)를 제안
 모델링 과정 : 객체지향으로 분석하고 설계하는 프로세스
 모델링 언어 : 설계를 표현할 때 사용하는 그래픽 심볼
 광범위 응용 분야에서 사용
 데이터베이스 설계 표현, 실시간 시스템 등
37
UML이전의 OO 방법
 Shlaer와 Mellor가 제안한 반복적 설계 방법
 Coad와 Yourdon이 제안한 프로토타입 중심 방법
 Worfs-Brock 등 폴랜드의 Smalltalk 그룹이 제안한 의무 중심 설계 및
CRC(Class-Responsibility-Collaboration) 카드 방법
 Rational Software의 Booch가 제안한 Ada 설계 방법
 GE 연구소의 Rumbaugh가 중심이 되어 제안한 OMT
 Odell과 Martin의 정보공학을 기초로 한 방법
 Ericsson에서 일한 Jacobson의 use case 개념을 소개한 방법
38
UML 다이어그램
다이어그램 이름
개략적인 모양
설명
액터와 사용 사례를 이용하여
시스템의 기능을 모델링
사용 사례(use case) 다
이어그램
클래스 다이어그램
패키지 다이어그램
객체지향 시스템의 가장 근간이
되는 다이어그램으로 시스템의
정적인 구조를 나타냄
관련된 클래스를 패키지로 그루
핑 하여 의존도를 낮추기 위하
여 사용
39
UML 다이어그램
다이어그램 이름
개략적인 모양
설명
클래스 사이의 메시지 교환을
시간이 흐름에 따라 나타냄
순차(sequence) 다이어
그램
협동 다이어그램
상태 다이어그램
순차 다이어그램과 같은 내용을
나타내지만 모양이 네트워크 형
태임
외부 자극에 대한 시스템의 동
적 상태 변화를 나타냄. 외부 이
벤트에 대하여 민감하게 상태를
변화시키는 객체를 모델링
40
UML 다이어그램
다이어그램 이름
액티비티(activity) 다이
어그램
컴포넌트 다이어그램
배치 다이어그램
개략적인 모양
설명
액티비티 단계별로 제어라는 흐
름을 모델링 하여 시스템의 동
적 특징을 나타냄
소프트웨어 부품, 예를 들면 원
시코드, 헌 타임 라이브러리, 실
행 파일 등의 구성을 나타냄
노드, 컴포넌트, 커넥터 등 시스
템의 물리적 자원 배치를 나타
냄
41
UML 기능
 자세한 의미(semantic) 표현
 확장 메커니즘
 관련 텍스트 언어
 Object Constraint Language(OCL)
 UML의 목적은
 소프트웨어 설계 표현을 도와주는 것임
 방법론이 아님
42
UML(Unified Modeling Language)
 시스템 개발 모형
 기능적 모형(functional model) - 사용자 측면에서 본 시스템
기능을 나타내며 UML에서는 사용사례 다이어그램으로 표현.
 객체 모형(object model) - 객체, 속성, 연관 관계, 오퍼레이션
에 의하여 시스템의 구조를 나타내며 UML에서는 클래스 다이
어그램으로 표현한다.
 동적 모형(dynamic model) - 시스템의 내부 동작을 나타낸다.
UML에서는 순서 다이어그램, 상태 다이어그램, 액티비티 다
이어그램으로 표현한다. 순서 다이어그램은 객체들 사이의 메
시지 교환을 나타내는 반면 상태 다이어그램은 하나의 객체가
가질 수 있는 상태와 상태의 변화에 의하여 동작을 나타낸다.
 UML의 다이어그램
 사용사례, 클래스, 순서, 상태, 액티비티 다이어그램
43
클래스, 속성, 오퍼레이션 표현
 클래스 심볼 : 세 부분의 박스형태
 위 : 클래스 이름 , 중간 : 클래스 속성 , 아래 : 오퍼레이션
 객체는 클래스와 같은 형태로 나타내며 객체의 이름을
먼저 쓰고 어떤 타입의 클래스에 속하는지 표시
 외부 투명성을 위한 심볼
 +: public로 선언, 외부 접근 가능
 -: private로 선언, 외부 사용 불가능
 #: 상속된 클래스에서만 제한적으로 사용 가능
 추상 클래스 또는 오퍼레이션
 이름과 함께 {abstract} 표시
 스테레오 타입
Employee
+ Name :char
………..
+promote
(from,to) …..
 << >>로 표현
44
4.2 사용사례 다이어그램
 정의
 “순서있는 액션의 집합을 기술한 것으로 액터에게 혜택이 있는 결과
를 제공하여야 함” (UML user guide)
 목적
 시스템의 외부 기능을 나타냄, 사용자의 요구를 추출하고 분석
사용사례는 사용자가 주어진 작업을 완료하기 위하여 수행한 일련의
액션이나 이벤트
 사용 사례를 분석하는 목적은 시스템을 모델링 하는 것
• 특정 목적을 달성하려고 할 때
• 사용자가 시스템과 어떻게 상호작용 하는지에 대한 관점으로
 사용사례 모델은
• 사용사례 집합과
• 사용사례에 대한 설명, 사용사례 사이의 관계로 구성
45
사용사례
 일반적으로 사용사례는 작업의 시작부터 끝까지 전 단계를 커버하
여야 함
 사용자가 시스템과의 상호작용을 나타냄
 시스템이 실행하는 계산이 아님
 사용사례는 특정 사용자 인터페이스 설계와 독립적으로 작성되어야
함
 액터가 컴퓨터와 상호작용 하는 액션만을 포함하여야 함
46
사용사례 다이어그램
 구성요소
 사용사례(use case) – 액터에게 보이는 시스템의 기능, 외부동작
 액터(actor) – 시스템과 상호작용하는 외부 엔티티(사람이나 다른 시
스템, 하드웨어), 이름과 설명 필요
 통신 – 액터와 사용사례가 정보를 교환
 의미
 시스템의 범위를 정함
 사용사례 기술
 스크립트 형태, 자연어 사용
통신
액터
사용사례
47
사용사례 다이어그램 예
Video Store
Rent Video
Return Video
User
Store Manager
Add Video
48
사용사례 다이어그램의 관계
 포함관계(include)
 공통적인 기능
 표현 : 점선화살표, <<include>>
 확장관계(extend)
 어떤 사용사례가 확장되어 동작이 다름으로 인하여 여러 다른
인스턴스가 있을 때
 어떤 사용사례가 다른 사용사례를 포함할 때
Edit Customer Profile
 예외적인 조건
 표현 : 점선화살표, <<extend>>
 포함관계와 확장관계의 차이점
<<extend>
>
 의존관계를 어느쪽으로 할 것인가
Parental Authorization
49
사용사례의 장점
 시스템의 범위를 정하는데 도움이 됨
 개발 과정을 계획하는데도 사용됨
 요구를 개발하고 검증하는데 사용 됨
 테스트케이스를 정의하는데 기초가 됨
 사용자 매뉴얼 구성하는데 사용될 수 있음
50
클래스 다이어그램
 정의
 시스템을 구성하는 클래스의 구조를 나타냄
 객체들의 공통 구조와 동작들을 추상화 한 것
 목적
 시스템을 구현할 때 어떤 클래스가 필요한지
 클래스 사이의 관계를 나타냄
 구성요소
 객체, 클래스, 속성, 오퍼레이션, 연관관계
 의미
 클래스 다이어그램은 객체지향 프로그램의 골격(클래스 정의)
을 나타냄
51
클래스 다이어그램 예
1
1
has
ViedoSroreSystem
1
rent(videoId)
Inventory
*
1
rent(videoId,rental)
exist
1
*
Rental
has
Video
Title
Charge
category
*
1
date
add(videoTitle,
price)
Customer
name
address
changeAdd(address)
rent
*
Adult
Child
rent(rental)
52
클래스 다이어그램의 표현
 연관관계(association)
 클래스 사이의 관계, 링크로 나타냄(선으로 표현)
 역할(role)
 연관관계 표시 선분 끝에 역할을 표시(has, exist, rent)
 다중도(multiplicity)
 숫자로 표현, 연관된 링크의 개수 , * 는 다수(many)를 의미
Customer
1
*
Rental
53
클래스 다이어그램의 표현
 전제부분 관계(aggregation)
 전체 개념의 클래스 : Directory
 부분 개념의 클래스 : File
 일대 다인 경우가 많음, 다이아몬드로 표시
Directory
0
*
File
 일반화
 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의
관계
 공통속성과 오퍼레이션을 사용하기 위하여 상속 개념으로
클래스를 구성하는 것
54
순서 다이어그램
 정의
 시스템 동작을 정형화하고 객체들의 메시지 교환을 시각화
 목적
 참여객체(participating object)를 추가로 찾아내기 위하여
 객체사이에 일어나는 상호작용을 파악
 구성요소
 액터(왼쪽),객체,메시지(이름있는 화살표),수직선(시간의 흐름)
 의미
 클래스가 가져야 할 오퍼레이션을 파악하는데 사용 됨
 객체들 사이의 통신 패턴
 사용사례의 이벤트 흐름을 나타낸다
55
순서 다이어그램 예
:VideoStoreSystem
:Customer
:Inventory
:Video
rent(videoID)
Get CustomerID
ID
collect chrge
\
Get delay charge
delay charge
create
rent(videoID rental)
OK
:Rental
rent(rental)
add(title,price)
56
상태 다이어그램
 정의
 객체가 갖는 여러 상태와 상태 사이의 전환를 표현
 상태란 객체가 만족하는 조건
 목적
 단일 객체의 동작을 나타냄
 객체의 상태 변화를 점검하며 빠진 오퍼레이션 점검
 솔루션 도메인 객체를 표현
 구성요소
 원 - 객체의 상태 , 화살표 – 전환(transition)
 의미
 외부 사건의 결과로 일어나는 단일 객체의 상태 변화에 초점
 객체의 동작을 구체화
57
상태 다이어그램 예
Not rented
scan()
Being checked out
rent(videoId,rental)
Rented
rent(videoId,rental)
Returned(videoId)
Returned
reserve(videoId)
Reserved
58
액티비티 다이어그램
 액티비티
 시스템에서 수행되는 작업(오퍼레이션의 집합)
 클래스의 메소드
 액티비티 다이어그램
 시스템을 액티비티로 표현한 것
 액션 상태인 상태 다이어그램
 액티비티와 천이 사이의 제어흐름
 구성요소





원: 액티비티
화살표: 트랜지션(다른 액티비티로 전환)
동기 막대 : 제어흐름 동기화
다이아몬드 : 선택분기
시작, 종료
 외향천이
 액션상태, 액션상태의 이름은 동작이 일어남을 의미
59
액티비티 다이어그램 예
Go to counter
start
Identify tape
Prove Identification
Pay
60
객체지향 기초
 왜 객체지향 방법인가?
 객체지향의 특징
 객체지향 기본 개념
 객체지향 프로세스
 UML
 설계와 구현의 매핑
61
설계와 구현의 매핑
 객체지향 모델링의 관계
 연관(association)
 전체 부분(whole/part)
Window
 상속(inheritance)
 사용(use)
사용관계
Event
상속관계
ConsoleWindow
DialogBox
연관관계
User
전체부분 관계
Control
 객체사이의 관계를 프로그램에 반영
62
연관관계
 객체와 객체를 연결하는 구조적인 관계
 방향성과 다중도를 고려
Mother 1
Has a
Class Mother{
*
Child
Class Child{
………….
………….
private Child[] theKids = new Child[20];
private Mother mom;
public addChild(Child ch);
public setMom(mom);
}
}
배열 theKids는 Child에 대한 레퍼런스를 저장
변수 mom이 mother객체를 레퍼런스 함
배열의 크기가 Child의 수를 제한
Mom을 선언하므로 연관관계를 맺는다
63
연관관계
 연관관계 생성 코드
Mother theMom = new Mother();
 추적가능성(navigability) 확인
Child jim = new Child();
Child jennifer new Child();
 서버클래스의 표현을 바꿀때
클라이언트 코드를 변경할
필요 없다
theMom.addChild(jim);
theMom.addChild(jennifer);
Jim.setMom(theMom);
Jinnifer.setMom(theMom)
 배열로 표현된 theKids를
벡터로 바꿀 수 있다
 이때 theKids를 private로 선언하면 클라이언트 프로그램에
영향을 주지 않고 서버클래스(Mother)의 표현을 바꿀 수 있다.
64
전체부분 관계-구성관계
 전체부분관계
 구성관계(composition), 집합관계(aggregation)
 구성관계
 전체 개념 안에 구성요소 존재(테이블:4개의 다리+1개의 상판)
 연관관계의 일종으로 관계 표시는 없어도 된다
 방향성 ,추적가능성 고려, 컨테이너 객체 이용
 대부분 has, comprise, consist of의 의미
 구성관계의 특성
 구성요소가 없이 전체가 존재할 수 없다
 구성요소는 언제나 하나의 전체객체에 대한 부품이다
 구성관계는 이질적 구성요소로 되어 있다
 UML표현: 검은 다이아몬드
65
전체부분 관계-집합관계
 집합관계
 예> 숲은 나무의 집합, 시/도는 군/구의 집합
 컨테이너 클래스 사용
 전체 개념의 클래스로부터 구성요소를 찾을 수 있음
 집합관계의 특성
 구성요소가 없이 전체가 존재할 수 있다
 구성요소는 하나 이상의 전체집합에 소속 가능하다
 구성관계는 동질적 구성요소로 되어 있다
 UML표현: 흰 다이아몬드
66
전체부분 관계 UML
Table
4
Report
1
Leg
Top
구성관계
*
Chapter
집합관계
67
상속관계
 상속관계(= 일반화 관계)
 일반적 개념의 클래스와 더 구체적 클래스의 관계
 A kid of의 관계
Box
 명칭
 일반적인 클래스 : 베이스 클래스
 구체적인 클래스 : 파생된(derived) 클래스
 UML표현: 자식클래스에서 부모쪽으로 화살표
 상향식 화살표로 베이스 클래스 를포인트
Weighted
Box
 단일상속, 다중상속
 단일상속 : 하나의 베이스 클래스를 갖는다
 다중상속 : 두개 이상의 베이스 클래스를 갖는다
68
사용관계
 사용관계
 한 클래스가 다른 클래스를 코드 안에서 사용할 때
 의미
 코드상의 의존 관계
 종속된 관계
CourseSchedule
Course
Add(c: Course)
Remove(c: Cpurse)
 일반적 유형
 오퍼레이션의 매개변수로 다른 클래스를 사용하는 클래스
간의 연결
• 예>CourseSchedule클래스는 add과 remove 오퍼레이션을 위해
Course 클래스를 매개변수로 사용한다
 UML표현: 점선 화살표
69
관계의 비교
연관관계
전체부분 관계
관계
클래스 사이에
영구적인 의미가
있는 관계
명확한 전체 부분
개념
일반적, 구체적
관계
유지기간
클래스 상태의
일부분으로 객체
가 살아있는 동안
만 유지
클래스 상태의 일
부분으로 클래스
객체가 살아있는
동안만 유지
서브 클래스가 정 클래이언트나 서
의 될 동안 영구적 버 메소드가 활성
된 경우만 관계
유지
관련된 객체에 대
한 인스턴스 변수
를 정의, 다중도
를 위하여 컨테이
너 객체 사용
링크에 대한 레퍼
런스를 인스턴스
변수로 정의, 다중
도를 위하여 컨테
이너 객체 사용
상속을 사용, java
의 경우 서브클래
스가 슈퍼클래스
를 확장
구현
상속관계
사용관계
한 클래스에서
다른 클래스 객체
의 서비스를 사용
클라이언트 클래
스 메소드가 서버
클래스에 대한
레퍼런스를 매개
변수로 가짐
UML
70