18. Refining The Requirements Model

Reuse in Object Orientation

---

Object Orientation에서 재사용(reuse)의 핵심 컨셉은 캡슐화이다.

Object Orientation에서는 모든 단위에 대해서 external interface를 제공한다.

Component 단위에서도 내부가 아니라, 외부 인터페이스만 제공한다.

내부가 어떻게 동작하는 지 알 필요 없고, 시스템과 서브 시스템이 상호작용할 수 있게 정의된 인터페이스가 가장 중요하다.

 

 

Component

---

그룹화된 독립적인 시스템을 Component 라고 한다.

인터페이스를 제공하는 것을 통해 자기 자신을 제외한 나머지와 사용할 수 있도록 해준다.

이를 Plugged Together 라고 한다.

 

Plugged Together

같이 꽂는다라는 말로, 단순히 연결(Plug)하는 것 만으로도 사용할 수 있게 된다.

예를 들면 유선 이어폰이 있다.

요즘에는 무선으로 바뀌면서 이어폰 구멍이 거의 다 사라졌지만, 유선 이어폰이 Plugged Together를 가장 잘 설명해준다. ▼

 

 

이어폰 잭을 연결하는 순간 소리가 핸드폰이 아닌 이어폰에서 나오게 된다.

어떤 이어폰이든, 단자만 맞는다면 똑같이 동작한다.

그런데 이렇게 하려면 간단하고 정제된 인터페이스가 제공되어야 한다.

유선 이어폰의 경우엔 3.5mm 단자로 인터페이스가 제공되었다.

 

특정 서비스를 요청하는 Component들은, 서비스를 제공해주는 Component가 어떤 방식으로 동작하는지 전혀 알 필요가 없다.

그저 깔끔하고 간단하고 정제되게 인터페이스만 제공받으면 된다.

 

 

Pattern

---

Pattern에 관한 글은 Desgin Patterns 라는 글에서 더 자세히 볼 것이다.

그래도 간단하게 알고 넘어가자.

 

보통 패턴은 반복되는 것을 말한다.

반복되는 것은 재사용을 통해 해결이 가능하기 때문에 Object Orientation의 재사용과도 관련이 있다.

패턴은 쉽게 말하면, 일반화된 문제의 솔루션이다.

특정 한 문제에 국한 되는 것이 아니라, 비슷한 여러 문제들에 대한 솔루션이기에 하나의 해결책으로 여러가지 문제를 해결할 수 있다.

 

 

Component Diagram

---

Component Diagram은 Component간의 관계(relationship)를 나타낸 것이다.

(Class Diagram도 Class 간의 관계를 나타낸 것이다.)

 

 

"그럼 Component간의 상호작용은 뭘로 표현할까?"

 

 

Component간의 상호작용은 함수(function)를 주고 받는 것을 말한다.

이를 그림으로 표현하면 아래와 같이 표현할 수 있다. ▼

 

 

스테레오 타입만 작성해도 되고, 아이콘만 써도 된다. ▼

 

 

관계는 이 요철과 비슷한 그림으로 표현한다. ▼

 

 

동그라미가 인터페이스이고, 오목한 것이 인터페이스를 받는다는 것이다.

그림에 나와있는 인터페이스의 이름은 Take Payment이다.

Bookings 쪽에는 TakePayment라는 인터페이스만 알면되고, Payments가 어떤 식으로 돌아가는지에 대해서는 알 필요가 없다.

 

예제

항공사 시스템

 

 

예약을 하려면 MakeBooking을 사용하면 된다.

평소에 비행기 예약할 때 어디서 하는 지를 생각해보자.

항공사 앱이 있다면 앱에서도 되고, 항공사 웹사이트, 그리고 ARS 서비스를 지원하는데도 있다면 전화로도 가능할 것이다.

이렇게 플랫폼이 분화되어있어도 모두 MakeBooking만 알고 있으면 예약 시스템을 사용할 수 있다.

위의 그림에는 각 플랫폼에서 사용하는 부분이 그려져있지는 않다. ▼

 

 

그렇지만 모든 내용이 꼭 시스템 내부에 있지 않아도 된다.

Component diagram을 다 그렸다면 이제 상호작용을 표시할 차례다. ▼

 

 

TakeUpBooking은 checkIn을 위해 5개의 함수를 제공해야한다.