8장: 객체지향 기초 - Software Engineering -

강의 개요 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

왜 객체지향 방법인가? 소프트웨어 위기 시스템을 쉽게 구축할 수 있는 방법 응용문제를 더 쉽게 인식 구현이 덜 복잡해짐 문제를 정확히 해결 적절한 작업 유지보수 가능 확장 가능 재사용 가능 응용문제를 더 쉽게 인식 구현이 덜 복잡해짐 자료구조와 함수의 결합이 자연스러움 분석과 구현 사이의 차이가 적음

왜 객체지향 방법인가? 잘 설계된 객체의 집합은 재사용과 변경이 용이 의사교환이 효과적인 비주얼 모델링 모델링 과정에 사용자와 개발자 사이에 공통으로 이해할 수 있는 용어와 개념 객체모델을 이해하기 위하여 꼭 프로그래머일 필요 없음 비용의 절감 객체는 이런 장점이 있지만 모든 것을 자동으로 제공하지는 않음

객체지향 기초 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

객체지향의 특징 모형의 적합성 재사용 용이 Time – to – market 설계와 프로그램의 매핑 객체중심 모형은 우리의 사고 방식과 유사 뚜렷하게 구별되는 객체로 나누고 객체들의 메시지 패싱이 모여 프로그램이 됨 재사용 용이 openness, closeness를 다 갖춘 재사용 단위 상속(inheritance), 다형성(polymorphism) Time – to – market 종래의 폭포수모형은 단계가 길고 문서 작업이 많음 클래스의 재사용과 확장에 의한 빠른 개발이 가능 설계와 프로그램의 매핑 개발 각 단계의 전환이 자연스럽고 신속

객체지향 기초 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

객체지향 시스템의 구조 재래식 방법 객체 지향 방법 자 료 함수1 함수2 함수3 기능중심, 변경의 파급효과 큼 자료와 관련 함수의 결합 프로그램= 자료구조 + 함수 프로그램 = 객 체 + 객 체 자료 함 수 프로그램= 자료구조 + 함수 자 료 함수1 함수2 함수3

객체지향 절차적 패러다임 객체지향 패러다임 소프트웨어가 프로시저 단위로 구성됨 프로시저 추상 데이터 추상 소프트웨어 공학 객체지향 절차적 패러다임 소프트웨어가 프로시저 단위로 구성됨 프로시저 추상 단순한 데이터에는 적합하나 복잡한 데이터를 가진 응용문제에는 부적합 데이터 추상 특정한 의미를 이루는 데이터의 조각들을 모아 그루핑 시스템의 복잡도를 줄이는데 도움 예) 레코드나 구조체 객체지향 패러다임 프로시저 추상을 데이터 추상 관점으로 구성 (C) Eun Man Choi, 2002

객체지향 패러다임 문제를 해결하기 위한 모든 계산이 객체(object)라는 것을 기본으로 수행되는 방법 객체는 클래스의 인스턴스. 클래스는 자료가 추상화된 것이며, 동시에 객체를 조작하는 프로시저에 대한 추상 실행 프로그램은 특정 작업을 수행하기 위하여 모인 객체의 집합

구조 비교 절차적 패러다임 객체지향 패러다임

객 체 객체의 정의 객체는 상태(state), 능력(behavior), 정체성(identity)을 가진다. 소프트웨어 모듈(객체) = 자료구조 + 함수 객체는 상태(state), 능력(behavior), 정체성(identity)을 가진다. 객체 실행되는 소프트웨어 시스템에 존재하는 구조화된 데이터의 덩어리 성질(property)를 가짐 객체의 상태(state)를 나타냄 행위(behavior)를 가짐 어떤 식으로 작용하고 반응하는지를 나타냄 실세계에 존재하는 객체의 행위를 시뮬레이션 할 수도 있음 정체성 : 구별 가능성 객체 인스턴스(instance) = 객체 비슷한 객체의 구조와 행동은 공통 클래스로 선언

객 체

클 래 스(Class) 클래스(class) vs 인스턴스 (instance) 클래스의 속성(attribute) 객체지향 프로그램에서 추상화의 단위 유사 객체들을 정의 인스턴스 소프트웨어 모듈 인스턴스의 구조(속성)를 나타냄 행위를 구현하는 메소드를 가짐 클래스(class) vs 인스턴스 (instance) 클래스 : 객체의 타입(object type) 인스턴스 : 클래스에 속하는 개개의 객체 클래스의 속성(attribute) 예 : 직원 클래스 속성 : 이름, 직위, 월급, 전화 번호 등 함수 : 진급, 월급 인상, 전화 변경 등 클래스는 객체들이 갖는 속성과 적용 연산을 정의하고 있는 틀(templet) Employee Hong_kildong(); Employee* Hone_kildong = new Emplyoee(); 직원클래스 홍길동 객체

클래스 이름 붙이기 대문자로 시작 단수형 명사 일반적으로 적용되는 명사 오직 하나의 의미만 갖도록 명명 bankAccount(X) BankAccount(o) 단수형 명사 일반적으로 적용되는 명사 시/도 – Municipality(o), City(X) 오직 하나의 의미만 갖도록 명명 Bus – 노선, 버스차량

캡 슐 화(Encapsulation) 캡슐화의 정의 추상화의 수단 정보은닉(information hiding) 관련된 항목을 모아서 갭슐을 씌움 예> 학사 관리 시스템 데이터 : 학번, 이름, 주소 캡슐화 함수 : 평점 계산, 주소 변경, 수강 신청 캡슐화 추상화의 수단 세부사항은 차후에 생각 정보은닉(information hiding) 외부의 직접적 접근 불가, 일종의 블랙박스 구현에 따라 선택 가능 문법 : public, private, protected

상 속(inheritance) 상속의 의미 슈퍼클래스(superclass), 서브 클래스(subclass) 상위 클래스의 속성과 연산을 물려 받음 슈퍼클래스(superclass), 서브 클래스(subclass) 예>직원 : 슈퍼클래스 , 관리자 : 서브클래스 복수상속 (multiple inheritance) 두개 이상의 수퍼클래스에서 상속 받음 인사대상 교 수 학 생 대학원생 학부생 직 원

상 속 슈퍼 클래스 상속 구조 상속(inheritance) 서브 클래스의 공통적인 기능(feature)들을 가짐 슈퍼 클래스와 서브 클래스 사이의 관계를 나타냄 삼각형 화살표는 일반화(generalization)을 나타냄 상속(inheritance) 슈퍼 클래스에 정의한 기능들을 서브 클래스가 묵시적으로 소유하는 것

상속 구조의 예 상속(inheritance) Account MortgageAccount SavingsAccount ChequingAccount 상속(inheritance) 슈퍼 클래스에 정의한 기능들을 서브 클래스가 묵시적으로 소유하는 것

Is-a 관계 일반화를 확인하려면 Is-a 관계를 만족시키는지를 체크 “A saving account is an account.” (보통예금 구좌는 은행구좌의 일종이다.) “A graduate student is a student.” (대학원생은 학생의 일종이다.) “A school is a university.”가 성립하나? Is-a 관계가 아님. ‘대학교는 학교의 일종이다.’가 되어야 함

기하학에서의 상속구조

상속 구조 상속된 모든 기능이 서브클래스에서도 의미가 통하는지 확인

다 형 성(polymorphism) 같은 이름의 메시지를 다른 객체 or 서브클래스에서 호출 다형성의 정의 하나의 추상 오퍼레이션이 서로 다른 클래스에서 다른 방법으로 구현될 수 있는 객체지향의 성질 같은 이름을 가진 여러 개의 다른 메소드가 있어야 함 어떤 메소드가 실행될지는 변수 안에 있는 객체의 종류에 좌우 됨 If-else나 switch 문장을 줄여주는 효과 다형성의 정의 여러 형태를 가지고 있다 (=여러 형태를 받아들일 수 있다) 같은 이름의 메시지를 다른 객체 or 서브클래스에서 호출 예> getarea() 를 도형의 모양이 달라도 호출 메소드:특정한 클래스를 위하여 오퍼레이션을 구현 하나 이상의 메소드를 가진 오퍼레이션 매개변수나 객체가 속한 클래스의 이름으로 구분

다 형 성(polymorphism) 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있음 Polygon Area getarea() Circle getarea() Rectangle getarea() 다형성의 예

다형성 Polymorphism Universal ad hoc parametric : General function 타입이 달라도 같은 code를 수행 ad hoc 타입이 다르면 다른 version의 code를 수행 parametric : General function inclusion : subtype, inheritance overloading : + (문자열의 더하기, 정수의 더하기) coercion : 3+4.0 => 3+4 또는 3.0+4.0으로 타입변환(coercion)

객체지향 기초 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

객체지향 프로세스 객체지향 프로세스의 특징 클래스에 대한 세가지 관점 분석, 설계, 코딩, 테스트 단계 라이프 사이클 유형 일관성 클래스에 대한 세가지 관점 정적 관점: 객체, 속성, 행위, 객체들의 관계 동적 관점: 객체 사이의 메시지 교환, 제어, 타이밍, 상태 변화 제한적 관점: 속성값, 다중도 등의 구조와 동적 행위 분석, 설계, 코딩, 테스트 단계 라이프 사이클 유형 폭포형, 나선형, RUP(Rational Unified Process)등

객체지향 분석 객체지향 요구분석 요구추출 요구분석(추출된 요구 정리) 사용자의 요구를 기능적 관점으로 파악하여 사용 사례 다이어그램으로 나타냄 요구추출 사용사례를 찾아내고 이를 다이어그램으로 작성 사용사례로부터 기능파악 요구분석(추출된 요구 정리) 객체를 찾고 객체 사이의 관계를 정리 순서다이어그램, 상태다이어그램을 작성하여 동적모형을 완성

객체지향 분석 요구 추출 요구 분석 사용사례 다이어그램 분석모형 (클래스, 순서다이어그램) ①액터찾기 ②시나리오 찾기 ③사용사례 찾기 ④사용사례 구체화 ⑤사용사례 관계 찾기 ⑥비기능 요구 찾기 ①객체찾기 ②객체 상호작용 모형화 ③객체 연관관계 ④객체속성 찾기 ⑤상태 다이어그램 작성 ⑥분석 모형 검토

객체지향 설계 분석 모형은 시스템의 기능에 대한 사용 사례 측면의 분석과 객체들의 관계 분석, 객체 사이의 상호작용 분석 분석 모형은 시스템의 기능에 대한 사용 사례 측면의 분석과 객체들의 관계 분석, 객체 사이의 상호작용 분석 설계 : 분석 모형을 시스템 설계 모형으로 변환 설계 모형 : 시스템 구조에 대한 모형, 객체 모형 솔루션 객체 파악 기술에 종속된 객체 사용자 인터페이스, 데이터베이스, 통신 프로토콜 등

객체지향 설계 ①설계 목표 정의 ②서브 시스템 파악 시스템 설계 ③자료 저장소 설계 패키지 다이어그램 객체 설계 ①객체 정의 상세화된 클래스 ①설계 목표 정의 ②서브 시스템 파악 ③자료 저장소 설계 ①객체 정의 ②부품선택 또는 최적화

객체지향 코딩과 테스트 객체모형, 클래스 다이어그램을 바탕으로 코딩 절차적 프로그램 테스트와 유사 시스템 서브 시스템 클래스 재사용을 위해 일반화 절차적 프로그램 테스트와 유사 단위테스트 → 통합 테스트 → 시스템 단위 테스트 시스템 서브 시스템 클래스 상속 구조 클래스 통합테스트 시스템 시험 단위 시험 인수테스트 추상화 수준

RUP(Rational Unified Process) 한 사이클이 끝날 때마다 테스트가 완료 통합 및 수행 가능한 시스템이 산출 각 사이클에서 요구분석, 설계, 구현, 테스트 반복(iteration) 피드백, 완성도 높은 시스템 점증적 반복 (incremental and iterative ) 요구분석 설 계 구현 및 테스트 설계 보완 통합 및 시스템테스트 요구분석 설 계 구현 및 테스트 설계 보완 통합 및 시스템테스트 반복1 반복2 시스템 V.1.0 시스템 V.2.0

RUP의 특징과 장점 RUP특징과 장점 반복 과정에서 높은 위험도를 잘 관리할 수 있다. 반복 릴리스와 피드백을 통하여 요구 사항을 만족시킬 수 있다. 초기 반복에서 소프트웨어 구조를 잘 확립할 수 있다. 시스템을 가시적인 모델(즉, UML)로 표현할 수 있다. 소프트웨어의 변경을 잘 관리할 수 있다. 개발 사이클 반복 단계 전개 구 축 전 환 개념정립 반복 종료지점 중간 릴리스 최종제품 릴리스

RUP의 단계 RUP의 단계 개념정립(inception) - 비전, 비즈니스 케이스, 범위를 개략적으로 파악하는 단계.각 사이클에서 요구분석, 설계, 구현, 테스트 반복(iteration) 전개(elaboration) - 비전을 구체화하고, 중심되는 소프트웨어 구조를 반복적으로 구현해 보아 시스템의 뼈대를 확립한다. 중요한 요구를 찾아내고 범위를 정한다. 구축(construction) - 남아 있는 덜 중요한 부분을 구현하고 설치를 준비한다. 전환(transition) - 테스트, 설치, 다음 반복 단계 준비

객체지향 기초 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

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)를 제안 모델링 과정 : 객체지향으로 분석하고 설계하는 프로세스 모델링 언어 : 설계를 표현할 때 사용하는 그래픽 심볼 광범위 응용 분야에서 사용 데이터베이스 설계 표현, 실시간 시스템 등

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 개념을 소개한 방법

UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 사용 사례(use case) 다이어그램 액터와 사용 사례를 이용하여 시스템의 기능을 모델링 클래스 다이어그램 객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타냄 패키지 다이어그램 관련된 클래스를 패키지로 그루핑 하여 의존도를 낮추기 위하여 사용

UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 순차(sequence) 다이어그램 클래스 사이의 메시지 교환을 시간이 흐름에 따라 나타냄 협동 다이어그램 순차 다이어그램과 같은 내용을 나타내지만 모양이 네트워크 형태임 상태 다이어그램 외부 자극에 대한 시스템의 동적 상태 변화를 나타냄. 외부 이벤트에 대하여 민감하게 상태를 변화시키는 객체를 모델링

UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 액티비티(activity) 다이어그램 액티비티 단계별로 제어라는 흐름을 모델링 하여 시스템의 동적 특징을 나타냄 컴포넌트 다이어그램 소프트웨어 부품, 예를 들면 원시코드, 헌 타임 라이브러리, 실행 파일 등의 구성을 나타냄 배치 다이어그램 노드, 컴포넌트, 커넥터 등 시스템의 물리적 자원 배치를 나타냄

UML 기능 자세한 의미(semantic) 표현 확장 메커니즘 관련 텍스트 언어 UML의 목적은 Object Constraint Language(OCL) UML의 목적은 소프트웨어 설계 표현을 도와주는 것임 방법론이 아님

UML(Unified Modeling Language) 시스템 개발 모형 기능적 모형(functional model) - 사용자 측면에서 본 시스템 기능을 나타내며 UML에서는 사용사례 다이어그램으로 표현. 객체 모형(object model) - 객체, 속성, 연관 관계, 오퍼레이션에 의하여 시스템의 구조를 나타내며 UML에서는 클래스 다이어그램으로 표현한다. 동적 모형(dynamic model) - 시스템의 내부 동작을 나타낸다. UML에서는 순서 다이어그램, 상태 다이어그램, 액티비티 다이어그램으로 표현한다. 순서 다이어그램은 객체들 사이의 메시지 교환을 나타내는 반면 상태 다이어그램은 하나의 객체가 가질 수 있는 상태와 상태의 변화에 의하여 동작을 나타낸다. UML의 다이어그램 사용사례, 클래스, 순서, 상태, 액티비티 다이어그램

클래스, 속성, 오퍼레이션 표현 클래스 심볼 : 세 부분의 박스형태 위 : 클래스 이름 , 중간 : 클래스 속성 , 아래 : 오퍼레이션 객체는 클래스와 같은 형태로 나타내며 객체의 이름을 먼저 쓰고 어떤 타입의 클래스에 속하는지 표시 외부 투명성을 위한 심볼 +: public로 선언, 외부 접근 가능 -: private로 선언, 외부 사용 불가능 #: 상속된 클래스에서만 제한적으로 사용 가능 추상 클래스 또는 오퍼레이션 이름과 함께 {abstract} 표시 스테레오 타입 << >>로 표현 Employee + Name :char ……….. +promote (from,to) …..

4.2 사용사례 다이어그램 정의 목적 사용사례는 사용자가 주어진 작업을 완료하기 위하여 수행한 일련의 액션이나 이벤트 “순서있는 액션의 집합을 기술한 것으로 액터에게 혜택이 있는 결과를 제공하여야 함” (UML user guide) 목적 시스템의 외부 기능을 나타냄, 사용자의 요구를 추출하고 분석 사용사례는 사용자가 주어진 작업을 완료하기 위하여 수행한 일련의 액션이나 이벤트 사용 사례를 분석하는 목적은 시스템을 모델링 하는 것 특정 목적을 달성하려고 할 때 사용자가 시스템과 어떻게 상호작용 하는지에 대한 관점으로 사용사례 모델은 사용사례 집합과 사용사례에 대한 설명, 사용사례 사이의 관계로 구성

사용사례 일반적으로 사용사례는 작업의 시작부터 끝까지 전 단계를 커버하여야 함 사용자가 시스템과의 상호작용을 나타냄 시스템이 실행하는 계산이 아님 사용사례는 특정 사용자 인터페이스 설계와 독립적으로 작성되어야 함 액터가 컴퓨터와 상호작용 하는 액션만을 포함하여야 함

사용사례 다이어그램 구성요소 의미 사용사례 기술 사용사례(use case) – 액터에게 보이는 시스템의 기능, 외부동작 액터(actor) – 시스템과 상호작용하는 외부 엔티티(사람이나 다른 시스템, 하드웨어), 이름과 설명 필요 통신 – 액터와 사용사례가 정보를 교환 의미 시스템의 범위를 정함 사용사례 기술 스크립트 형태, 자연어 사용 통신 액터 사용사례

사용사례 다이어그램 예 Video Store Rent Video Return Video Store Manager User Add Video

<<extend>> 사용사례 다이어그램의 관계 포함관계(include) 공통적인 기능 표현 : 점선화살표, <<include>> 확장관계(extend) 어떤 사용사례가 확장되어 동작이 다름으로 인하여 여러 다른 인스턴스가 있을 때 어떤 사용사례가 다른 사용사례를 포함할 때 예외적인 조건 표현 : 점선화살표, <<extend>> 포함관계와 확장관계의 차이점 의존관계를 어느쪽으로 할 것인가 Edit Customer Profile <<extend>> Parental Authorization

사용사례의 장점 시스템의 범위를 정하는데 도움이 됨 개발 과정을 계획하는데도 사용됨 요구를 개발하고 검증하는데 사용 됨 테스트케이스를 정의하는데 기초가 됨 사용자 매뉴얼 구성하는데 사용될 수 있음

클래스 다이어그램 정의 목적 구성요소 의미 시스템을 구성하는 클래스의 구조를 나타냄 객체들의 공통 구조와 동작들을 추상화 한 것 목적 시스템을 구현할 때 어떤 클래스가 필요한지 클래스 사이의 관계를 나타냄 구성요소 객체, 클래스, 속성, 오퍼레이션, 연관관계 의미 클래스 다이어그램은 객체지향 프로그램의 골격(클래스 정의)을 나타냄

클래스 다이어그램 예 1 1 1 * 1 1 * 1 * * rent(videoId) has Inventory Customer ViedoSroreSystem rent(videoId) 1 1 1 has Inventory rent(videoId,rental) * Customer name address changeAdd(address) 1 exist 1 has * Rental date add(videoTitle, price) rent Video Title Charge category rent(rental) 1 * * Adult Child

클래스 다이어그램의 표현 연관관계(association) 역할(role) 다중도(multiplicity) 1 * 클래스 사이의 관계, 링크로 나타냄(선으로 표현) 역할(role) 연관관계 표시 선분 끝에 역할을 표시(has, exist, rent) 다중도(multiplicity) 숫자로 표현, 연관된 링크의 개수 , * 는 다수(many)를 의미 Customer Rental 1 *

클래스 다이어그램의 표현 전제부분 관계(aggregation) 일반화 * Directory File 일대 다인 경우가 많음, 다이아몬드로 표시 일반화 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의 관계 공통속성과 오퍼레이션을 사용하기 위하여 상속 개념으로 클래스를 구성하는 것 * Directory File

순서 다이어그램 정의 목적 구성요소 의미 시스템 동작을 정형화하고 객체들의 메시지 교환을 시각화 참여객체(participating object)를 추가로 찾아내기 위하여 객체사이에 일어나는 상호작용을 파악 구성요소 액터(왼쪽),객체,메시지(이름있는 화살표),수직선(시간의 흐름) 의미 클래스가 가져야 할 오퍼레이션을 파악하는데 사용 됨 객체들 사이의 통신 패턴 사용사례의 이벤트 흐름을 나타낸다

순서 다이어그램 예 ID \ OK :VideoStoreSystem :Customer :Inventory :Video rent(videoID) Get CustomerID ID Get delay charge delay charge collect chrge \ create :Rental rent(videoID rental) rent(rental) OK add(title,price)

상태 다이어그램 정의 목적 구성요소 의미 객체가 갖는 여러 상태와 상태 사이의 전환를 표현 상태란 객체가 만족하는 조건 단일 객체의 동작을 나타냄 객체의 상태 변화를 점검하며 빠진 오퍼레이션 점검 솔루션 도메인 객체를 표현 구성요소 원 - 객체의 상태 , 화살표 – 전환(transition) 의미 외부 사건의 결과로 일어나는 단일 객체의 상태 변화에 초점 객체의 동작을 구체화

상태 다이어그램 예 scan() Not rented Being checked out rent(videoId,rental) Returned(videoId) Returned Reserved reserve(videoId)

액티비티 다이어그램 액티비티 액티비티 다이어그램 구성요소 외향천이 시스템에서 수행되는 작업(오퍼레이션의 집합) 클래스의 메소드 시스템을 액티비티로 표현한 것 액션 상태인 상태 다이어그램 액티비티와 천이 사이의 제어흐름 구성요소 원: 액티비티 화살표: 트랜지션(다른 액티비티로 전환) 동기 막대 : 제어흐름 동기화 다이아몬드 : 선택분기 시작, 종료 외향천이 액션상태, 액션상태의 이름은 동작이 일어남을 의미

액티비티 다이어그램 예 Go to counter Identify tape Pay start Prove Identification Pay Identify tape start

객체지향 기초 왜 객체지향 방법인가? 객체지향의 특징 객체지향 기본 개념 객체지향 프로세스 UML 설계와 구현의 매핑

설계와 구현의 매핑 객체지향 모델링의 관계 Window Event 객체사이의 관계를 프로그램에 반영 User Control 연관(association) 전체 부분(whole/part) 상속(inheritance) 사용(use) 객체사이의 관계를 프로그램에 반영 Window ConsoleWindow DialogBox User Event Control 사용관계 상속관계 전체부분 관계 연관관계

연관관계 객체와 객체를 연결하는 구조적인 관계 방향성과 다중도를 고려 Mother Child 1 * Has a Class Mother{ …………. private Child[] theKids = new Child[20]; public addChild(Child ch); } 배열 theKids는 Child에 대한 레퍼런스를 저장 배열의 크기가 Child의 수를 제한 Class Child{ …………. private Mother mom; public setMom(mom); } 변수 mom이 mother객체를 레퍼런스 함 Mom을 선언하므로 연관관계를 맺는다

연관관계 연관관계 생성 코드 추적가능성(navigability) 확인 서버클래스의 표현을 바꿀때 클라이언트 코드를 변경할 필요 없다 배열로 표현된 theKids를 벡터로 바꿀 수 있다 이때 theKids를 private로 선언하면 클라이언트 프로그램에 영향을 주지 않고 서버클래스(Mother)의 표현을 바꿀 수 있다. Mother theMom = new Mother(); Child jim = new Child(); Child jennifer new Child(); theMom.addChild(jim); theMom.addChild(jennifer); Jim.setMom(theMom); Jinnifer.setMom(theMom)

전체부분 관계-구성관계 전체부분관계 구성관계 구성관계의 특성 UML표현: 검은 다이아몬드 구성관계(composition), 집합관계(aggregation) 구성관계 전체 개념 안에 구성요소 존재(테이블:4개의 다리+1개의 상판) 연관관계의 일종으로 관계 표시는 없어도 된다 방향성 ,추적가능성 고려, 컨테이너 객체 이용 대부분 has, comprise, consist of의 의미 구성관계의 특성 구성요소가 없이 전체가 존재할 수 없다 구성요소는 언제나 하나의 전체객체에 대한 부품이다 구성관계는 이질적 구성요소로 되어 있다 UML표현: 검은 다이아몬드

전체부분 관계-집합관계 집합관계 집합관계의 특성 UML표현: 흰 다이아몬드 예> 숲은 나무의 집합, 시/도는 군/구의 집합 컨테이너 클래스 사용 전체 개념의 클래스로부터 구성요소를 찾을 수 있음 집합관계의 특성 구성요소가 없이 전체가 존재할 수 있다 구성요소는 하나 이상의 전체집합에 소속 가능하다 구성관계는 동질적 구성요소로 되어 있다 UML표현: 흰 다이아몬드

전체부분 관계 UML Table Leg Top 4 1 구성관계 Chapter Report * 집합관계

상속관계 상속관계(= 일반화 관계) 명칭 UML표현: 자식클래스에서 부모쪽으로 화살표 단일상속, 다중상속 일반적 개념의 클래스와 더 구체적 클래스의 관계 A kid of의 관계 명칭 일반적인 클래스 : 베이스 클래스 구체적인 클래스 : 파생된(derived) 클래스 UML표현: 자식클래스에서 부모쪽으로 화살표 상향식 화살표로 베이스 클래스 를포인트 단일상속, 다중상속 단일상속 : 하나의 베이스 클래스를 갖는다 다중상속 : 두개 이상의 베이스 클래스를 갖는다 Box WeightedBox

사용관계 사용관계 의미 일반적 유형 UML표현: 점선 화살표 한 클래스가 다른 클래스를 코드 안에서 사용할 때 코드상의 의존 관계 종속된 관계 일반적 유형 오퍼레이션의 매개변수로 다른 클래스를 사용하는 클래스 간의 연결 예>CourseSchedule클래스는 add과 remove 오퍼레이션을 위해 Course 클래스를 매개변수로 사용한다 UML표현: 점선 화살표 CourseSchedule Add(c: Course) Remove(c: Cpurse) Course

관계의 비교 연관관계 전체부분 관계 상속관계 사용관계 관계 유지기간 구현 UML 클래스 사이에 영구적인 의미가 있는 관계 명확한 전체 부분 개념 일반적, 구체적 한 클래스에서 다른 클래스 객체의 서비스를 사용 유지기간 클래스 상태의 일부분으로 객체가 살아있는 동안만 유지 클래스 상태의 일부분으로 클래스 객체가 살아있는 동안만 유지 서브 클래스가 정의 될 동안 영구적 클래이언트나 서버 메소드가 활성된 경우만 관계 유지 구현 관련된 객체에 대한 인스턴스 변수를 정의, 다중도를 위하여 컨테이너 객체 사용 링크에 대한 레퍼런스를 인스턴스 변수로 정의, 다중도를 위하여 컨테이너 객체 사용 상속을 사용, java의 경우 서브클래스가 슈퍼클래스를 확장 클라이언트 클래스 메소드가 서버 클래스에 대한 레퍼런스를 매개변수로 가짐 UML