05 | 객체지향의 이해와 UML Class Diagram

* KOWC에 등록된 동국대학교 최은만 교수님의 강의내용을 공부목적으로 정리한 글임을 밝힙니다.
| 출처 : http://www.kocw.net/home/search/kemView.do?kemId=331697&ar=relateCourse 
 
 
 

전통적 분석기법과 객체지향의 차이

---

전통적 기법의 프로그램은 '처리(process)' 순서, 절차에 초점을 맞추어 프로그램이 데이터와 그러한 데이터를 조작하기 위한 함수들로 구성됨. 이때 데이터(자료)와 함수가 분리된 채 함수 간 데이터를 주고받다 보니 상호 간의 높은 의존성과 복잡성, 불필요한 중복, 낮은 재사용성 문제를 야기하며 프로그램 효율성/생산성 떨어뜨리게 됨
 
객체지향은 이러한 문제를 해결하기 위해 등장한 방법론으로, 전통적 기법의 프로그램이 함수의 집합체였다면, 객체지향 프로그램은 클래스(Class)의 집합임. 이는 같은 목적이나 기능을 하는 변수와 메소드를 하나로 묶어 객체를 만들고, 그 객체들끼리 필요한 데이터를 상속받는 등의 형태로 주고받음으로써 사람 입장에서도 보다 코드를 이해하기 쉽고, 모듈별로 컴팩트하게 분리가 가능해 상호 간 의존성이 감소하며, 불필요한 중복을 최소화 한 효율적 프로그램 개발 및 관리를 가능케 함
 
 

절차적 vs 객체지향

 
그림에서 보면 알 수 있듯이 절차적 프로그래밍 방식은 함수간 의존성이 높아 어느 한 타입이 변경되면 연관된 다른 모든 요소를 변경시켜야 하지만 객체지향의 경우 변경이 일어난 요소만 변경해 주면 되기에 요구사항 수정이나 추가요청 등이 들어와도 상대적으로 대응능력이 높음
 
 
 
 

클래스, 인스턴스, 객체, 메소드

---

클래스(class)

객체들이 갖는 자료와 오퍼레이션을 정의한 것, 객체 생성을 위한 템플릿 / 틀
 
| 붕어빵 기계 틀
 
 

인스턴스(instance)

메모리에 할당된 객체
(클래스로부터 객체를 선언하는 과정을 클래스의 인스턴스 화, 이렇게 선언된 해당 클래스 타입의 객체를 인스턴스라고 함)
 
| 내 붕어빵 : 붕어빵 틀에 의해 구워진 붕어빵
| 친구 붕어방 : 붕어빵 틀에 의해 구워진 또 다른 붕어빵
 
 

객체(object)

클래스의 인스턴스, 변수와 메소드를 그룹핑한 것
 
| 붕어빵
 
 

메소드(method)

특정 작업을 수행하기 위한 명령문의 집합으로, 클래스 함수 or 멤버 함수로도 불리며 클래스에 종속되어 있기에 해당 클래스에 대한 객체가 생성되어야 사용 가능
 
| 붕어빵 반죽을 만든다
| 반죽을 특에 굽는다
| 붕어빵을 뒤집는다
| 구워진 붕어빵을 봉투에 담는다
 
 
 
 

객체지향 특성

---

추상화(abstraction)

어떤 실체로부터 공통적인 부분이나 유의미한 특성을 추려낸 것 (ex. 지도, 노선도)
 
 

상속(inheritantance)

클래스 재사용하는 것
상위 클래스를 하위 클래스에서 상속받으면 상위 클래스의 멤버변수나 메소드 그대로 물려받을 수 있음
이는 코드 재사용성을 높여 생산성 향상 및 유지보수에 유리함
 
 

다형성 (polymorphism)

같은 모양의 함수가 상황에 따라 다르게 동작하는 것

• 오버라이딩 : 슈퍼 클래스의 메소드를 서브클래스마다 다르게 구현
• 오버로딩 : 같은 클래스 내에서 이름은 같으나 매개변수, 숫자, 타입 등을 달리해 다르게 작동하도록 구현

 

캡슐화(encapsulation)

비슷한 역할을 하는 속성과 메소드(객체)를 하나의 클래스로 모으는 것
** 은닉화 : 캡슐화에 속한 개념으로 캡슐 내부로직이나 변수를 감추고 외부에 기능(api)만 제공하여 함수를 통해서만 접근하도록 함으로써 외부 접근으로 부터 내부 객체 보호함

 
 
 
 

UML (Unified Modeling Language)

---

OMG(Object Management Group)에서 표준으로 채택한 통합모델링 언어로, 객체지향 분석 설계를 그림으로 표현하여  전체 시스템 구조 및 클래스 간의 의존성 파악에 도움을 줌
 

 

UML Diagram의 종류

크게 Structured Diagram과 Behavior Diagram로 구성

 

출처 : By Derfel73; Pmerson - This file was derived from: Uml diagram2.png, Public Domain, https://commons.wikimedia.org/w/index.php?curid=16417015

 
 

• Structured Diagram : 시스템의 개념, 관계측면에서 요소 나타내며, 각 요소들의 정적인 부분 보기 위함
• Behavior Diagram : 각 요소들 간의 변화나 흐름, 데이터 교환 등의 동작 보기 위함

 
 
 
 

UML Class Diagram 

---

객체지향 시스템에 존재하는 class 간의 관계(협력, 상속, 연결관계 등) 나타냄
 
 

클래스 구성요소

보통 클래스, attribute/field, opration/method  3 구획으로 나뉨
 

출처 : https://itwiki.kr/index.php?curid=6827

 

속성 (Attirbute)

의미 있는 명사형으로 표현

# 문법
<<stereotype>> visibility name : type[multiplicity] = value

# visibility : 접근제어
# name : 속성명
# type : 속성 타입
# multiplicity : 배열 개수
# value : default

 
 

스테레오 타입

UML에서 기본제공하는 요소 외에 추가적 확장요소 << content >> (* << >> : 길러멧, guillemet)으로 나타냄

 

자주 사용되는 스테레오 타입 

• <<interface>>
• <<utility>>
• <<abstract>>
• <<enumeration>>

 
 

추상클래스

1개 이상의 operation/method가 구현체 없이 명세만 존재하는 클래스
이탤릭체 or 클래스명 {abstract} or  <<abstract>> 으로 표시

 
 

Visibility (접근제어)

 
 

오퍼레이션 (Operation)

의미 있는 동사형으로 표현 (클래스가 수행할 수 있는 동작 기술)

# 문법
<<stereotype>> visibility name(parameters) : return_type

# 생성자나 리턴타입 void 인 경우 reuturn_type 생략

 
 

속성, 오퍼레이션 공통 사항

static variable(정적) 은 underline으로 표현
 
 
 
 

클래스 간 관계표현

---

 

 
 

Generalization (일반화) / Inheritance (상속)

 

출처 :&nbsp;By No machine-readable author provided. Noodlez84 assumed (based on copyright claims). - No machine-readable source provided. Own work assumed (based on copyright claims)., Public Domain, https://commons.wikimedia.org/w/index.php?curid=659677

 

• is a 관계
• 여러 클래스가 가진 공통적인 특징을 공통의 클래스로 일반화시키는 것
• 부모/자식 클래스(super class / sub class) 간의 상속관계 나타냄
  • 자식은 부모의 속성(attribute)과 행동(operation) 공유함
  • 자식은 부모가 갖고 있지 않은 속성과 행동 추가 가능 (specialization, 특수화)
  • 부모가 사용되는 곳은 어떤 자식으로든 대체가능 / 역은 성립 X

 
 
 

Realization (실체화) / Implementation

• * 인터페이스의 spec만 있는 Operation / method를 실제 기능으로 구현한 것
• 표기법 2가지
  • 1) 인터페이스를 클래스처럼 표기, 스테레오 타입 <<interface>> 추가, 클래스에서 인터페이스 쪽으로 연결
  • 2) 인터페이스를 원으로 표기, 인터페이스 이름 명시(접두에 I or 접미에 able 붙임), 인터페이스와 클래스 사이 실선 연결

표현법 1)&nbsp; 출처 : https://medium.com/@smagid_allThings/uml-class-diagrams-tutorial-step-by-step-520fd83b300b&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;표현법 2) 출처 : https://onecellboy.tistory.com/343

 

* 인터페이스?
   class or component 가 외부에 제공하는 기능(Operation, method) 만을 목록화한 것
   구조와 구현을 가지지 않고 행동이 선언만 된 추상클래스임 (Abstract class)
 
 
 

Dependency (의존)

 

출처 :&nbsp;By Samirsyed - Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=4667245

 
 

• 한 클래스의 변화가 이것을 사용하는 다른 클래스에 영향 미치는 관계, 역은 성립 X
•  구현 시 의존 클래스를 사용하는 클래스는 이를 참조하고 있는 인스턴스 변수를 유지하지 않음 (일시적) 
  • 한 클래스의 method가 다른 클래스를 인자로 받아 method 내에서 사용
  • 사용 후 의존 클래스의 객체 반환 시 의존 클래스의 인스턴스도 함께 사라짐 (의존 클래스를 생성/반환만 함, 유지 X)
• 스테레오 타입으로 dependency 목적/의미 명시 가능

 
 
 

Association (연관 관계), Directed Association (방향성 있는 연관)

 

[Bidirectional Association 예시]&nbsp; &nbsp;출처: By Esap at the English-language Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=16001562

 
 

• 클래스로부터 생성된 인스턴스들 간의 관계 표현
  • Dependency와 Generalization 은 단순히 클래스 간의 관계를 나타내며, 이들은 인스턴스에 대한 참조 유지하지 않으나 Associaiton 관계는 Clasifier (인터페이스, 클래스, 컴포넌트 등 인스턴스화될 수 있는 요소)로부터 생성된 인스턴스에 대한 참조(인스턴스 변수)를 유지한다는 차이가 있음
• 클래스 간에 연결된 선이 있으면 한 클래스의 객체(클래스의 인스턴스)가 다른 클래스의 객체 사용함을 암시
• 참조할 수 있는 attribute는 UML 상에서 표현 x (role name 이용)
• 방향(naviability)과 멀티플리시티(multiplicity) 표현 가능
  • Naviability
    • 양방향(Bidirectional Association) : 서로 상대의 인스턴스 가리키는 attribute(인스턴스 변수) 가짐
      | ex)  A - B : A와 B 상호 참조 가능 or 둘 다 참조 or 둘 다 참조 아님
    • 단방향(Unidirectional Association) : 한쪽 클래스만이 상대 쪽 인스턴스 가리키는 attribute(인스턴스 변수) 가짐
      | ex)  A -> B : A가 B를 참조
  • Multiplicity

 
 

Aggregation (집합)

 

 

• has a 관계, "contains"
• 전체(whole)와 부분(part)을 나타냄
• Association 관계 중 특별한 관계 (단반향 연관관계, 전체는 부분을 알지만 부분은 전체를 모름)
• 전체와 부분은 독립적, 따라서 부분 인스턴스는 다른 클래스와 공유될 수 있음
  | ex) 차 폐차해도 엔진, 바퀴는 다른데 달 수 있음, 영화관 사라져도 영화는 남아있음 (전체와 부분의 생명주기 상이)
• 포함하고 있는 클래스 쪽에 하얀 다이아 표시

** 다만 의미가 불분명하여 사용하지 않는 것이 좋다고 함 (UML 2.0에서는 거의 제외됨)

 
 

Composition (합성)

학부 24개라고 가정

 

•  Aggregation 보다 강한 관계
• 부분의 운명이 전체에 의해 좌우됨 (Agrregation과 달리 독립적이지 않고 전체 클래스 소멸 시 부분 클래스도 소멸)
  | ex) 대학이 없어지면 학부도 사라짐, 영화관 사라지면 매표소도 사라짐 (전체와 부분의 생명주기 동일)
• 따라서 부분 인스턴스는 다른 클래스와 공유될 수 없음 
• 포함하고 있는 클래스 쪽에 검은 다이아 표시

 
 
 

 
 
 

** 정리한다고 했는데 여전히 쉽지 않네요. 오류에 대해 지적해 주시면 너무나도 감사드리겠습니다

 
 
 
 
 
 

[출처]

 

** 클래스 다이어그램 명세/구현 차원에서 코드와 함께 설명 잘 되어있음 : https://www.nextree.co.kr/p6753/

UML: 클래스 다이어그램과 소스코드 매핑

 

** 관계설명 이해하기 쉽게 잘 되어있음 : https://onecellboy.tistory.com/343

[UML] Class Diagram 클래스 다이어그램

 
https://hyos-inside.tistory.com/42

[JAVA] :: 자바 기초 1 ::  객체 / 클래스 / 인스턴스 / 속성 / 함수 / 메소드

https://minni7.tistory.com/28

CH04. 객체지향, 클래스와 객체, 변수와 메서드,  오버로딩, 생성자, this레퍼런스, 변수 초기화

 
 
https://medium.com/@smagid_allThings/uml-class-diagrams-tutorial-step-by-step-520fd83b300b

UML Class Diagrams Tutorial, Step by Step

https://brownbears.tistory.com/577

[UML] 클래스 다이어그램 (Class Diagram)

 
https://itwiki.kr/w/%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8#/media/%ED%8C%8C%EC%9D%BC:%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8_%ED%81%B4%EB%9E%98%EC%8A%A4_%EC%98%88%EC%8B%9C.png

IT위키

https://en.wikipedia.org/wiki/Class_diagram

Class diagram - Wikipedia