본문 바로가기

강의 정리/소프트웨어 분석 및 설계

소프트웨어 분석 및 설계 (3) 클래스 모델

01. Object behavoir와 메서드

 

1. 행위

: 객체가 어떻게 행동act하고 반응react하는지를 결정.

객체가 수행하는 오퍼레이션에 의해 표현.

스스로 수행하는 action과 상대의 반응에 대한 reaction의 차이가 있다.

 

* 데이터 + 행위 (attribute + operation/methods)

interaction(능동적인 행동): Object 1과 Object 2,3 등이 교류하는 것.

 

 

2. 메소드는 오브젝트의 행위를 구현한다. 메소드는 오브젝트가 수행하는 액션이다.

 

1) 메세지는 메소드를 트리거하는 정보이다.

2) 메세지는 본질적으로 한 오브젝트에서 다른 오브젝트로 가는 기능이다.

3) 메소드는 C언어에서의 기능과 유사하다.

 

메세지는 타겟 객체에게 어떠한 액션을 요청하기 위해 전달된다.

 

 

* Class는 객체를 생성하는 틀이다. 일종의 타입Type.

타입은 모두에게 있다. ex. Integer a = 10;

그리고 클래스명이 그 객체의 타입이 된다. -> String, int 같은 데이터타입 말고 Abstract Data Type = ADT

객체라는 데이터는 상식과는 다르기 때문에 (attribute + operation) 그렇게 전달되는 덩어리들을 메세지라고 부른다.

클래스가 정의될때 attribute와 operation으로 구성된다면, 그것이 다른 오브젝트로 전달될때를 메세지라고 한다. 

 

 

3. 메세지 큐의 예시

 

isEmpty()로 물어본다. 비어있니? true.

다시 물어본다. 비어있니? false. -> get()하고 nofication을 전달한다.

 

여기서 메세지는 무엇인가? put(nofication)에서의 nofication과 isEmpty()같이, "촉발자"의 역할을 하는 것이다. 

트리거 = 이벤트. 통상적으로 이벤트는 외부에서 나한테 전달되는 트리거를 말한다. 트리거가 떨어지면 = 이벤트가 발생한다.

 

isEmpty()는 누구의 operation/methods인가?

큐 혹은 메세지 프로세서일 것이다. 메세지 프로세서인 것 같지만 큐가 정답이다. 왜? 

a --> data --> b 는 여지없이 a로부터 b로 데이터가 이동.

a --> isEmpty() --> b 는 a가 b에게 isEmpty()를 해달라고 요구한다. b가 해보고 응, 비어있네. 하고 true값을 전달해주는 것.

 

이게 바로 interaction이며 객체의 행위이다. 

 

 

4. 다른 시각의 행위

 

aParent는 오브젝트 이름.

이때 a - 는 어떤 특정한을 말한다.

 

냉장고에서 재료를 꺼내고, 피넛버터도 꺼내고, 다 꺼내서 샌드위치를 만든다. 샌드위치는 런치로 만들어져 백에 들어가서 런치백에 넣어진다.

 

개별적인 객체들이 이렇게 작동한다는 걸 알 수 있다.

Q. 그럼 누가 이걸 이렇게 실행하는데? A. 메인 함수가 루틴을 보유해서 자동적으로 이렇게 실행한다.

=> 시퀀스 다이어그램. 나중에 배울것.

 

 

 

02. 캡슐화란 무엇인가?

: 프로세스 중심이거나 데이터 중심인 경향성을 가진 정보 시스템 발전의 전통적인 접근법이다. 

객체 지향적 접근은 프로세스와 데이터를 총체적인 객체로 결합한다.

캡슐화는 간단하게 프로세스와 데이터를 하나로 결합하는 것이다.

 

1. 캡슐화의 필요성

- 클래스 정의를 통해 오퍼레이션과 속성을 강제 분리한다.

오퍼레이션을 통해서만 접근할 수 있도록, 속성에 대한 배타적인 접근을 보장한다.

ex. void setTime(int, int, int);

 

- 멤버 데이터의 무결성을 보장할 수 있는 매커니즘을 메서드에 정의하여, 안전한 사용을 할 수 있도록 한다.

ex. hour = (h>=0 && h<24) ? h : 0

 

 

* 정보시스템을 표현할 때, 예전에는 패러다임Paradigm = Data / Process oriented로 분리했다.

이걸 다 합친 것이 객체 지향적인 페러다임이다. 그러나 객체 지향적 패러다임을 지향하면 UML로 분석, 설계, 구현어가 C language가 맞지 않기 때문에 부적절.

 

* 오브젝트 고유의 접근 = 데이터와 프로세스를 합친 것. 즉 holistic entities 하나의 큰 덩어리 개념으로 합쳐진 것.

Q. 기술적으로 이걸 어떻게 합칠까? A. 프로세스와 데이터를 하나의 엔티티로 만든다.

 

* 클래스라는 개념은 데이터 타입이다. 실행때는 보이지 않는 개념이다.

 

 

 

03. 메세지 패싱

 

: 객체들이 상호작용하는 방법으로 메세지 전송(데이터를 담은 오퍼레이션의 호출)을 사용.

 

 

 

04. 클래스 구성요소

1) Class - Meta-class

2) Object - Aggregation

3) Association - Generalization/Specialization

4) Multiplicity

 

 

 

05. 상속

: 객체들 간의 공통적인 속성과 오퍼레이션을 분리한다. 개념의 재사용 단위.

 

* 상속은 분석개념이 아니다. 분석에서는 재사용을 하지 않아도 된다. 필요하다면 정의하지만.

즉 상속이라는 개념은 따라오지만 분석때부터 따라올 필요는 없다 - 있으면 좋다.

 

 

(1) 셋의 공통점을 가진걸 모아서 공유하면 더 편하지 않을까?

(2) 개념을 어떻게 표현해야 할까?

 

 

 

1. 상속은 일반화/특수화 관계의 표현이다.

 

- Parent Class: 오브젝트들의 공통적인 것을 표현하는 속성들이 모여있는 클래스.

= base class, super class.

 

- Child Class: 속성들이 상속되어졌고 다른 클래스들과 구분되어진 클래스.

= sub class, derived class, extended class.

 

Person과 Student와 Professor은 무엇도 공통점이 없는 것 같다.

하지만 전화기의 누르는 버튼과 스마트폰의 그래픽으로 나온 버튼, 전화기와 스마트폰의 이동성이 동일한 것을 알면, 전화기 이후 스마트폰을 전화기와의 공통점을 통해 익숙하게 접할 수 있게 되는 것처럼

-> 모르는 것을 접촉하면 아는 것과의 공통점으로 익숙함을 늘릴 수 있다.

 

즉 Person을 이해하면, 그 아래의 상속받은 것들을 이해하기가 더 쉽다.

코딩에서는 재사용의 목적이라면 분석에서는 이해의 목적으로 사용된다. 

 

- 이때 특이한 매커니즘이 하나 발생한다. 만약 부모 오브젝트가 없다면?

말이 안 되지만 그럼에도 불구하고 자식 오브젝트를 만들 수 있다고 주장하는 클래스가 발생한다.

이것을 Abstract Class 라고 부른다. 부모 클래스의 변형에 가까운 개념이다.

스스로는 오브젝트를 만들 개념이 없지만, 다른 클래스를 파생시키는 목적으로 만들어진다. 예외적인 경우.

 

 

 

06. 다형성

 

동일한 open()을 보내더라도 보내진 오브젝트에 따라 다른 해석을 하는 것이다.

문을 연다, 박스를 연다, 창문을 연다. 같은 이름을 다르게 해석한다.

 

서로 다른 객체에서 동일한 이름의 오퍼레이션을 제공할때, 동일한 이름이더라도 작동하는 방식은 객체에 따라 달라지게 된다.

 

개념은 좋지만 이걸 어떻게 구현할 것인가?

open()이 왔을때 누구에게 그것을 던져주느냐의 문제도 발생한다.

이때 binding - 정적 바인딩/동적 바인딩을 사용한다.

 

1) 정적 바인딩

 

이름은 똑같지만 타입이 다르다면 다르게 구분해야 한다.

이때는 아예 다른 함수로 구현되어 있다. 이것은 쉽고 간단하다.

 

 

2) 동적 바인딩: 실행시에 다르게 연결하기를 요구한다. 서로 실시간으로 돌아가는 상황에서는 굉장히 어렵다. 그럼에도 불구하고 사용되고 있다. 다형성은 그런 의미에서는 모델링에서도 가능하다.

 

장점: Circle, Triangle, Retangle 면적을 구하는 공식은 전부 다르지만 getarea()로 모두 동일하게 호출할 수 있다. 이때 좋은 것은 새로운 도형 오브젝트를 더하는 게 가능하다는 것이다.

 

 

 

07. 클래스 다이어그램의 연관

 

클래스는 수많은 관계들을 다른 클래스들과 가진다. 관계는 다음과 같은 타입이 있다.

 

 

1. 연관 assosiation

 

1) 텔레비전을 turn on한 순간 연결된다. 또는 두가지 이상의 관계로 연결이 가능하다.

 

2) 그냥 존재하던 오브젝트들을 연결해 meaning(sementics)을 설정한다. 서로간의 의미를 정의하고 이 정의한 의미대로 이해해달라는 분석가의 시그널이다.

 

3) Multiplicity 다중성: [prof] -- teach -- [student] 라는 두 클래스들을 묶었다고 하자.

aProf - aStudent뿐만 아니라Students도 가능하다.

즉 하나의 오브젝트가 생성되었을 때 몇개까지 대응할 수 있느냐. 1:1/1:n/n:1/n:n. 0:n까지 가능하다.

 

 

2. 집합연관 aggregation

 

: 집합연관은 연관 중 하나이다. 

 

(1) 시스템이란건 모니터, 키보드, 마우스, 기타 등등을 통칭해서 시스템이 된다.

(2) 도시란 개념을 이해하기 위해서는 - 자동차가 여러개가 있고(0 .. n) 나무가 여러개가 있다는(0 .. n) 집합연관 관계를 형성.

=> 1:n 아니면 0:n로 묘사된다. 

 

 

3. 복합연관 compositon

 

집합연관의 한 형태는 연관된 객체와 그것의 요소 객체와의 강한 관계를 말한다.

복합연관의 중요점은 객체가 다른 객체의 복합연관된 객체로만 존재하는 것이다. 

 

- 불가분의 관계이다.

-> (1) 사람이란 대상을 이해하기 위해서는 심장은 하나, 손은 둘이어야 한다. 

(2) 하나의 주문은 여러개의 메뉴를 포함할 수 있다. 

 

도시에서는 차 하나가 사라진다고 도시 객체에 영향이 가지 않는다. 개념적으로 하나 사라진다 해도 생긴다 해도 OK.

하지만 복합연관은 다르다.

 

 

4. 연관의 구분

연관, 집합연관, 복합연관은 모델링 시각에 따라 달라질 수 있다.

그러나 일반적으로 다음의 포함관계가 성립된다.

 

 

 

08. 의존 dependency

 

- 메소드의 코드에 종속이 되는 경우.

 

- 두개의 클래스에 존재할때, 하나의 구현이 변한다면 다른 클래스가 영향을 받느냐 안 받느냐.

영향을 받는다면 의존관계이다.

 

 

 

09. 실체화

 

내가 이 회사를 가지고 있습니다 - Owner.

상속과 비슷하지만 다르다. 부모 클래스의 설명을 보면 <interface>라고 적혀있는데 - 이것을 stereo type이라고 한다.

이 클래스는 다소 특이하다. 속성이 없다! opeation만 가지고 있다.

 

이것을 사용하는 이유: Person과 Corporation을 실체화로 묶기 위해서.

 

 

 

10. 표현 Visualizing

 

1. 클래스 표현

클래스 다이어그램은 클래스명을 포함한다.

클래스 집합을 패키지로 표현할 수 있다.

클래스의 경로이름을 표현하는 경우 '::' 표기를 사용한다.

 

2. 속성의 표현

속성은 클래스를 표현하는 중요 데이터 요소이다.

객체의 경우, '속성:값'의 쌍으로 표현된다.

속성은 경우에 따라 기본값을 부여할 수 있다.

 

3. 오퍼레이션의 표현

오퍼레이션 명과 시그니쳐를 표현한 경우.

시그니쳐는 함수 원형으로, 파라메터와 반환값 정보를 포함한다.

스테레오 타입을 표기할 수 있다.

 

4. Class 표현의 수준

 

어느 수준까지 하느냐에 따라 달라진다. 분석에서는 컨셉츄얼 정도에서 종료한다.

 

 

5. 어떻게 클래스를 찾아내느냐.

문제에 대한 (1) 이해, (2) 시스템 솔루션을 진행한다. 이러한 과정은 이해당사자와의 인터뷰를 통해 진행된다.

 

중요시하는 컨셉이 무엇인가 등등을 적는 서술서를 작성한다.

즉, 정보를 텍스트 형태로 작성한다.

 

- 속성은, 어떤 대상을 설명하는데 그 대상의 개념과 의미를 상세화 하는 경우 표현하는데 적합.

속성은 설명의 크기를 집합 관계로 표현 가능하다. 

 

- 행위의 경우 동사로 표현한다. 잘라내기, 복사하기, 붙여넣기.