Agile Object-Oriented Design

2006.05.27 발표자 : 김태현[email protected]

Agile Object-Oriented Design

A&D

Architecture & Design

생각해보자

“ 나는 디자인 없는 코딩이 쉬워요” 코딩이 쉬웠던 대가 . 저지르고 땜빵하기의 기나긴 역사

“ 돌아가기만 하면 되잖아 .” – 성수대교 방식 좋은 평가는 저지른 자에게만

풍토와 시스템의 문제 먹었으면 최소한 설거지라도 하자 . (

리팩토링 ) 안다 . 하지만 귀찮다 . = 용감한 사람

OOP 만으로 충분한가 ? OOAD 라는 게 있다 .


디자인이란 무엇인가

Jack 의 문제제기 디자인은 제일 먼저 소스코드에 의해서 문서화되고 ,

다이어그램들은 디자인 그 자체가 아니라 부수적인 것들이다 . ( 소스코드가 곧 디자인이다 .)

모든 소스는 디자인이 있다 . 다만 디자인이 있다고 좋은 것이 아니라 좋은 디자인이 있어야 좋은 것이다 .

디자인은 항상 먼저 해야 하는가 ? Agile 이 대세다 .

창조와 협업의 시대 . 모든 문제는 인간으로부터 나오고 인간으로만

해결된다 . 다만 , 대세라고 해서 영원한 진리는 아니다 . 하지만

영원한 진리가 아니라고 해서 못할 이유가 있는가 .


Agile Software Design

디자인은 다이어그램이 아니라 추상적 컨셉이다 . “ 디자인이 있다 .” vs “ 좋은 디자인이 있다 .”

디자인 활동의 결과로 디자인은 생성된다 . 디자인 활동에는 어떤 것들이 있을까 ?

ASD 는 과정이지 , 결과가 아니다 . 원칙 , 패턴 , 소프트웨어의 구조와 가독성을

향상시키기 위한 방식을 연속적으로 적용하는 활동이다 .

모든 시점에서 시스템 설계를 가능한 간단 , 명료하고 표현적으로 유지하려는 노력이다 .


나쁜 디자인 냄세

고구마줄기 : 변경이 힘들다 . 한번 고치면 줄줄이 고칠 것이 생긴다 .

젠가 : 뭘 바꾸기만 하면 문제가 생긴다 . 스파게티 : 재사용 부분을 빼내기 힘들다 . 수렁 : 좋은걸 적용하기 힘들고 계속 나쁜

것들만 늘어나기 쉽다 . 미로 : 쓸데없이 너무 복잡하다 . 복사신공 : 비슷한 것들이 자꾸 반복되어

나온다 . 암호 : 읽고 이해하기가 너무 힘들다 .


무엇이 좋은 디자인인가 ?

쉬운 것 보다 좋은 것은 없다 . 보기 좋은 떡이 먹기도 좋다 . Robert C. Martin 의 원칙

SRP (Single Responsibility Principle) OCP (Open-Closed Principle) LSP (Liskov Substitution Principle) DIP (Dependency Inversion Principle) ISP (Interface Segregation Principle)

결자해지 원칙 일을 벌인 클래스가 그 일을 마무리 해야 함 .


SRP (Single Responsibility Principle)

하나의 클래스가 하나의 책임만 져라 . Example

네트웍 검사 클래스가 네트웍 검사하고 검사 결과를 윈도우로 띄워주는 책임을 갖고 있는 경우 .

네트웍 검사 클래스는 검사의 책임을 맡고 , 결과를 윈도우로 띄우는 책임은 다른 클래스가 맡도록 한다 .

고구마줄기 , 스파게티 등 방지 . 하나의 책임만 맡기는 어렵다면 책임의 범위를

넓히되 비슷한 책임을 묶어서 하나의 책임이 훼손되지 않도록 한다 .

다양한 객체를 조립하여 작동을 구현하는 통합클래스는 다양한 책임을 가질 수 있 되 책임의 수와 규모를 최소로 유지하고자 노력해야 한다 .


OCP (Open-Closed Principle)

확장은 개방적 , 수정은 패쇄적 . OCP 가 잘 지켜졌다면 , 새로운 기능을

추가할 때 기존의 코드를 고치는 것이 아니라 단지 새로운 코드를 추가할 것이다 .

전략 기본은 Abstraction & Polymorphism. State, Strategy 패턴 등 .

Example : cycle, rect, DrawAll()

Command, Decorator 패턴 등 . 고구마줄기 , 젠가 , 수렁 등 방지 .


LSP (Liskov Substitution Principle)

서브타입은 항상 베이스 타입이 대신할 수 있어야 한다 .

JAVA 및 C++ 에서 OCP 핵심 키워드인 Abstraction 과 Polymorphism 을 구현 하는 방법 중 하나는 상속이다 .

LSP 는 결국 OCP 를 가능하게 해준다 . 수렁 , 스파게티 등 방지


DIP (Dependency Inversion Principle)

하이레벨 모듈은 로 레벨 모듈에 의존해선 안 된다 . 둘 다 추상에 의존해야 한다 .

추상이 구체적인 것에 의존해선 안 된다 . 구체적인 것은 추상에 의존해야 한다 .

Example 범용 클래스인 소켓 클래스가 특정

프로젝트에 의존적인 클래스를 의존해서는 안 된다 .

고구마줄기 , 스파게티 , 수렁 등 방지


ISP (Interface Segregation Principle)

하나의 뚱뚱한 인터페이스를 수정하면 많은 클라이언트도 수정되어야 한다 .

하나의 인터페이스는 선택과 집중이 뚜렷해야 함 .

클라이언트 의존적 ,특정적 (specific) 인 인터페이스를 다른 인터페이스에 넣지 말지어다 .

스파게티 , 미로 등 방지 .


결국

나쁜 냄새가 없어진다 . 명료하고 간결하다 . 이해하기 쉬워진다 . 마침내 코딩 없이도 추상적 레벨 (

다이어그램 등 ) 에서 소프트웨어 디자인을 할 수 있다 . 디자인 먼저 , 코딩 나중도 가능

훌륭한 OO 디자이너의 소양 OOD 에 정통 숙련된 OOP 경험 플랫폼 의존적 지식


Before Demo1 - OOAD

Use Case Driven Architecture-centric iterative and incremental


Agile OOD 환경

듀얼모니터를 사용한다 . 한 모니터는 UML 설계화면 , 다른 모니터는

코딩화면으로 개발환경을 구축한다 . 장점

설계와 코딩을 동시에 할 수 있어 코드가 항상 설계된 상태로 유지될 수 있다 .

설계와 구현의 괴리가 적어진다 . 설계의 학습이 동시에 일어나서 빨리 교육된다 .

UML 모델은 하나만 사용 . Analysis, Design, Implement Model 을 따로 만들지

않고 하나의 모델에서 출발하여 완성해나간다 .(일반적인 방법에선 분석 , 설계 , 구현 모델이 별도로 있고 각 분석에서 설계로 설계에서 구현모델로 전이해나가며 각각이 추적성을 가진다 .) 추적이나 기록이 필요하다면 리파지토리를 이용하면 된다 .


Before Demo - Process


Agile OOD Demo

Usecase model Issue 고객의 요구사항이 무엇인가 ? 어떤 품질과 기능들이 필요할까 ?

Analysis Model Issue 개략적인 클래스와 전체 구조 도출

Design Model Issue 세부적인 클래스들의 역할과 관계 설정

Implement Model Issue 코드 - 클래스다이어그램 상호 작용

예제 ) 네트웍 체크 위자드 Next, prev, event, role Issue Activation Issue Progress UI Issue


프로세스를 논하다 .

OOD 가 만족 되었다 . 이제는 프로세스폭포수 X. 점진 반복 O 디자인먼저 , 코딩먼저에 얽매이지 마라 .

닭과 달걀 디자인 하면서 코딩 , 코딩 하면서 디자인 디자인은 추상적 컨셉 .


소프트웨어 아키텍처를 논하다 .

아키텍처는 품질과 구조의 문제 . 품질속성 아키텍처 기반 소프트웨어 개발

품질속성 도출 > 전략 수립 > 디자인 과 개발 > 평가와 전이

디자인의 결정은 품질속성에 기반한다 . 어떤 디자인을 따를 것인가는 어떤 품질속성을

만족시키는가에 달렸다 . 다양한 영역의 방법론들

프로세스 : RUP 구조 : CBD 문화 : XP 개발 : OOT (OOP & OOAD)

Documents

Agile Object-Oriented Design