소프트웨어 분석 및 설계 (4) 클래스 연관의 이해와 활용

01. 구조모델과 개념모델

구조적인 모델은 비즈니스 시스템에서 만들어지거나 사용되는 오브젝트를 보여주는 포멀한 방식이다.

분석가들은 이것은 어떻게 저장되고 만들고 조정되는지에 대한 디테일은 없이 실제 오브젝트들의 논리적인 구조를 보여주는 것인 컨셉츄얼 모델을 만든다.
왜냐하면 모델은 암시와 기술적인 테크닉으로부터 자유롭고, 분석가는 시스템의 진짜 비즈니스적인 요구에 알맞는 모델에 더 쉽게 주목할 수 있다.

 

실제 "비즈니스 문제"에 대해 반영하는 컨셉츄얼한 모델.

구조 모델의 초보적인 단계가 컨셉츄얼 모델. 구조 모델은 디자인 모델까지 끌고 간다. 

 

* UML 쓸 줄 모르는 개발자들도 존재. 수업시간에 배우지 않거나 20년 전에 했거나 객체지향을 하지 않거나. 보통은 이렇게 하십시오 하고 개발합니다.

 

 

1. 구조모델 - core elements

 

1) class) 공통된 속성/오퍼레이션/메소드/관계를 공유하는 오브젝트에 대한 묘사.

2) interface: 속성이 없는 오퍼레이션의 집단

3) component) 인터페이스에 대한 실체화를 제공하고, 함축을 제공하는 물리적인 위치 가능한 시스템의 일부분.

4) node: 설계때 피지컬한 것들을 표현.

 

1) 연관

2) 복합연관

3) 일반화

4) 의존

 

 

2. 상속

: 자식 클래스는 부모 클래스의 모든걸 상속받고 거기에 더해서 자신의 유니크함을 더한다.

 

 

! 일반화 <-> 특수화

이때 일반화는 상속과 가깝다.

 

ex. Employee is a person.

---> 일반화

<--- 특수화

is a = kind of = 관계.

 

다시 person이 뭐지?

person is a Human.

Human is an Animal.

---> 이렇게 개념의 일반화를 이어가는 것.

 

- 왜 해야하는가?

Employee를 이해하기 쉽다. 이미 존재하는 개념 안에서 이해되기 때문.

 

- 대체가능성(대체성)

Employee는 돈을 얻을 수 있습니다.

-> person은 돈을 얻을 수 있습니다.

고용자의 상당부분은 사람에게서 온다.

물론 아닐수도 있다. 고용되지 못하는 사람도 존재할 수 있다 -고용될수도 있고 고용되지 않을수도 있다. 이때는 대체관계 성립 불가능.

 

1) 선택적 상속은 불가능하다.

2) 부모가 두개 이상일 수 있다.

단일 상속, 다중 상속으로 구분.

 

 

 

3. 클래스 상속

 

오브젝트를 생성하지 못하는 클래스가 이론적으로 존재할 수 있다.

이때 플레이어는 개념적으로만 존재하고 가드/포워드/센터로 구현된다.

 

이것을 aggreagation(a-part-of) 연관관계로 이해할 수 있다.

 

 

4. 집합관계: 탄탄한 관계 <-> 느슨한 관계.

1) 복합연관

(1) 하부 클래스는 상위 클래스에 대해 종속적이다 -> 상위 객체 제거시 하위 객체 또한 제거된다.

(2) 상위 객체의 분해 관계로도 이해할 수 있다.

- 마름모가 가득 채워진 것으로 표현된다.

- 아주 strong한 관계.

 

이때 하부 객체가 사라지지 않으면?

2) 집합연관

(1) 하나 이상의 클래스가 모여 새로운 클래스를 형성할 경우에 표현한다.

(2) 복합관계와 유사하지만 느슨하다.

 

둘은 개념적으로 "상위 객체 삭제시"에 따라 분류.

 

 

5. 추상 클래스

 

1) 일반 클래스와는 달리 추상클래스는 객체를 생성하지 못한다 - 생성자/소멸자 등의 오퍼레이션을 정의하지 않는다.

2) 선언은 존재하지만 구현은 제공하지 않는다.

3) 다른 클래스를 정의할 때 규칙을 제시하는 용도로 사용.

 

틀=/=인스턴스.

아무리 데이터를 넣어도 인스턴스가 나오지 않는데 클래스가 맞는가?

맞다. 결국 다른 클래스를 만들때의 가이드라인으로 사용하는 것이 추상 클래스.

 

문제는 추상 클래스가 구현단계까지도 나타난다는 것.

 

 

- 추상 클래스의 코드 예

 

C++의 virtual로, Java의 abstract로.

 

Shape이 Item을 상속.

상속받은 하위 클래스가 알아서 책임지고 상속받은걸 정의한다.

 

(1) 확장성이 굉장히 뛰어나다.

(2) 컨트롤러 입장에서 디테일을 서로서로 알아서 구현하고 공통점은 공유하기 때문에 편리하다.

 

 

 

02. 클래스 다이어그램 vs 객체 다이어그램

객체 다이어그램은 클래스 다이어그램에 기반하여 작성되지만 - 객체간 특정 상황을 묘사한다.

 

-> 클래스 다이어그램

 

ChessPiece

Knight

Queen

Pawn

각 클래스마다 차이를 두고 있음

체스의 구조를 나타낸다.

 

 

-> 오브젝트 다이어그램

 

공격당할 수 있는 상황: 관계이름.

보호하고 있음: "

의도적으로 포지셔닝함: "

 

오브젝트들이 이러한 관계를 가진 상태로 있다.

즉, 현재 특정 상황을 묘사한다.

 

 

 

03. 인터페이스 클래스

1) 일련의 서비스를 제공하기 위해 여러개의 클래스가 상호작용하는 경우 사용된다.

2) 이 경우 컴포넌트 단위로 포장되는 것이 일반적이기 때문에 - 컴포넌트 서비스를 전담하는 클래스를 인터페이스 클래스라고 한다.

3) 컴포넌트 클래스는 실체화가 요구된다.

 

- 속성이 없다.

sus <-> [ ] <-> A,

                 <-> B,

                 <-> C

속성을 표현하면 너무 복잡해질때, 창구를 만들고 그 창구를 통해 접근하게 만들자는 목적이다.

그 창구에 접근해서 속성을 가져간다.

=> 설계 객체.

 

 

1. 인터페이스의 표현

 

- 세탁기의 예

세탁기와 세탁기 제어부는 논리적으로 분리된 두 클래스이다.

세탁기 제어부는 Control Knob이라 불리는 인터페이스 클래스로 표현 가능하다.

아래의 두 표현은 동일한 인터페이스를 표현한 것이다.

 

알아서 세탁하기를 누르면 내부에서 동작한다.

 

 

1) 인터페이스 클래스는 구현부/사용부 부분으로 구분되어 표현된다.

WashinMachine은 ControlKnob 인터페이스 클래스의 구현을,

Person은 ControlKnob 인터페이스의 사용을 표현한다.

 

2. 인터페이스 실체화

- 컴포넌트 스펙 부분과 구현 부분을 분리 -> 구현부의 변경이 발생해도 인터페이스를 사용하는 외부 클래스의 변경은 발생하지 않는다.

클래스의 유지보수에 도움을 주는 구조.

 

어떤 예약 시스템을 만들때.

과금 시스템, 고객 시스템, 호텔예약 시스템 전부 다 만들어져 있음.

가입 서비스만 만들어서 연결하면 OK.

 

Integration. 통합에 유리.

개발자가 굉장히 선호.

대부분은 이미 만들어져 있기 때문. 만들어져 있는 것 중, 어떤 것을 가져오면 되는지를 선택.

 

 

1) 인터페이스 클래스 구현시:

인터페이스 클래스는 다른 클래스 생성의 규약으로 사용된다.

이를 통해 다형성을 지원하고 - 코드의 유연성을 높인다.

 

 

- 클래스 모델 예 - worker task

 

한 사람당 한가지 일을 해야 하지만 - 아무도 워커가 아니어도 될때) 0 .. 1.

한 사람은 다수의 일을 해야 할때) *.

 

하나의 테스크는 다른 테스크와 relatedTo 관련이 있다.

 

Worker이 Task에 연결되는걸: 고용됐다고 한다.

이때 Agreement는 영관을 담당하며 파선으로 연결된다.

 

Date의 경우 어디로 연결되어 있지 않다. 속성으로 쓰이고 있으며, 굳이 연결되지 않고 참고하세요로 둬도 OK.

 

 

- 클래스 모델 예 - Buy Items

 

하나의 카탈로그에는 여러개의 상품들이 존재) 1:1..*.

하나의 스펙에는 여러개의 아이템들이 설명되고 있습니다) 1:*.

 

화살표가 없는건 양방향 해석을 해도 무관하다는 뜻.