Development Process & Design Patterns 고려대학교 컴퓨터 소모임 SYRES 2000 년 공개 세미나 고대 SYRES 2 기 이복연

대상 두세 가지 이상의 프로그래밍 언어를 다뤄 본 경험이 있고 즉석에서 간단한 예제 정도 는 구현할 수 있는 초급 개발자. 객체에 대한 기본적인 개념을 이해하고 있 으며 1 천 ~ 1 만 라인 미만의 단순한 객체지 향적 코딩의 경험은 있는자. 중규모 이상의 시스템 구축의 경험이 없고, 시스템 디자인적 측면에 대한 기초 지식이 전무 또는 부족한 사람.

목표 시스템의 개발 공정 및 디자인 패턴에 대한 간접 경험을 통해 시야의 폭을 넓히고 그 필 요성과 중요성을 인식시켜 보다 효율적이 고 능력있는 인재로 커나갈 수 있는 계기를 마련한다.

소프트웨어란 ? 유형성 - 코드를 인쇄시켜 볼 수도 있고 분석 / 설계 산출물로 가시화시킬 수 있다. 동적행위성 - 프로그램이 하드웨어에 의해 수행되 고 사용자와 상호작용할 때 비로소 소프트웨어가 된다. 상품성 - 사용자가 사용할 가치가 없다면 제품에 불과하다. 견고성 - 소프트웨어의 행위는 예측이 어렵고 수 정이 용이하지 않다. 비마모성 - 마모되지 않고 품질 저하가 없다.

소프트웨어 개발의 특성 비제조성 - 소프트웨어는 제조, 생산 되어지는 것 이 아니다. 하드웨어와 마찬가지로 좋은 설계를 바탕으로 만들어지지만 소프트웨어는 과정 자체 가 곧 품질로 연결된다. 비조립성 - 하드웨어는 부품의 조립으로 이루어지 는 반면 소프트웨어는 대부분의 경우에 개발에 머 물 뿐 조립의 단계는 아직 정착되지 못했다. 비과학성 - 조직, 인력, 시간, 비용, 절차 등이 중심 이되는 관리기술이 중요하다.

소프트웨어 위기 및 원인 개발예산의 초과 개발일정의 지연 소프트웨어 생산성의 저조함 소프트웨어 품질의 미흡 원인  소프트웨어 특성에 관한 이해의 부족  관리의 부재  프로그래밍에만 치중

소프트웨어공학 역사 (1) 1960 년대 : 개발 예산, 기간의 장기화 사태의 심각 성이 제기 1968 년 : NATO 회의에서 ' 소프트웨어공학 ' 이라는 단어를 탄생 (' 소프트웨어 위기 ' 를 인식 ) 1970 년대 : 프로그래밍 자체보다 분석, 설계 때의 결함이 더욱 심각함을 인식 ( 구조적 분석 / 설계의 개념이 각광을 받기 시작 ) 1973 년 : NCC, IFIP, ICSE 등 국제적 학술대회에 서 신기술 발표

소프트웨어공학 역사 (2) 1980 년대 전반 : 구조적 방법, 잭슨 방법, 워니어 - 오 방법 등 분석, 설계 방법들과 시험, 유지보수, 프로젝트 관리, 개발환경 등 전분야에 뚜렷한 기 술 발전 1980 년대 후반 : 객체지향 분석 / 설계 / 프로그래밍, 4GL, CASE, 피플웨어, 정보공학, 품질보증, 형상 관리, 프로토타이핑 등의 기술적 진보 1990 년대 : 객체지향, 정보공학, CASE 등의 본격 적인 활용 단계 및 소프트웨어 성능공학과 재공학, 사용자 인터페이스의 중요성 등도 강조

개발 공정 ( Development Process ) Plan & Elaborate ( 계획 및 상세화 ) Build ( 구축 ) Deploy ( 배포 )

계획 단계 (Plan) Preliminary Investigation Report Use Cases Use Case Diagrams Draft Conceptual Model Preliminary Investigation Report Prototypes Budget, Schedule Requirements Specifications Use cases Use Case Diagrams Glossary Draft Conceptual Model dependency Plan Glossary Prototype Requirements Specification

구축 단계 (Build) Refine Plan Sync Artifacts Analyze Design Construct Test

Waterfall Model (1) 개발 단계 : - 계획, 분석, 설계, 구현, 시험, 유지보수 한 번의 사이클로 전체 시스템을 구축. ( 한 번의 Development Cycle 을 거침 ) 소규모, 단편적인 시스템 구축에 적용. 개발 시 위험 부담이 크다. 유지보수에 어려움이 따른다.

Waterfall Model (2)

Iterative Development (1) 폭포수, 프로토타이핑, 나선형 모델 등의 개념을 포괄하는 보다 진보된 개발 모델. 사용자 요구사항의 일부분, 또는 제품의 일부분을 반복적으로 개발하여 최종제품을 완성. 중 / 대규모 시스템 구축에 적합. 매 단계마다 프로덕트가 생산된다. 시스템의 복잡도가 과중되지 않는다. 손쉬운 피드백이 가능해 시장 변화에 효율적인 대 응이 가능하다.

Iterative Development (2) 각각의 사이클은 정해진 Time-Box 내에 수행 될 수 있도록 적절한 부하를 할당한다. (Time-Box 는 2 주 ~2 달 정도가 적절 ) Development Cycle Use Case A Simplified Version Development Cycle Development Cycle Use Case A Full version Use Case B … Use Case C …  Use case 를 기반 으로 구현 기능을 할당.  중요 Use case 는 초기 사이클에서 구현.

Iterative Development (3)

분석 (Analysis) Define Essential Use Case Refine Use Case Diagrams Refine Conceptual Model Refine Glossary Define System Sequence Diagrams Define Operation Contracts Define State Diagrams

Component Based 소프트웨어를 조립한다는 개념에 따른다. 최근에 등장하여 아직 표준화되지 않았다.

설계 (Design) Define real Use Case Define Reports UI and Storyboards Refine System Architecture Define Interaction Diagrams Define Design Class Diagrams Define Database Schema

패턴 (Pattern) 이란 ? 서술화된 형식을 사용해 어떤 특정한 문제를 해결하는 가장 일반적인 방법을 기술한 것 우리가 주변에서 반복적으로 부딪치는 특정한 문제를 기술하며, 그러한 문제를 해결하는 솔 루션의 핵심을 기술하며, 이 솔루션은 수 백만 번에 걸쳐 사용될 수 있다.

프레임웍 (Framework) 설계 패턴은 프레임워크보다 추상적이다. 프레임 워크는 코드에 내재되어 있지만 패턴의 예는 코드 로 되어있지 않다. 설계 패턴은 프레임워크보다 작은 아키텍쳐 요소 이다. 일반적으로 프레임워크는 여러 개의 패턴을 포함한다. 설계 패턴은 프레임워크보다 덜 전문적이다. 프레 임워크는 항상 특정 어플리케이션 영역만을 가지 고 있다. 반면 패턴은 비슷한 어플리케이션 영역 들에서 사용될 수 있다.

MVC Model

패턴 적용 시의 이점 시스템 디자인 시 자주 겪게 되는 문제점들을 해결하기 위한 경험적 지침. 선배 개발자들에 의해 검증된 기법. 비슷한 상황 / 문제에서는 대부분 무리없이 수 용할 수 있을 만큼 범용적. 구성 요소들의 배치, 관계, 책임할당 등을 효율 적으로 처리. 시스템 디자인적 관점에서의 재사용성 증대.

주요 역사 1987 : Using Pattern Languages for Object-Oriented Programs ( OOPSLA-87, Ward Cunningham, Kent Beck )  Design Pattern 을 세계 공식 학회에 첫 발표 1994 : Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, John Vlissides, Ralph Johnson) 1994 : PLoP(Pattern Languages of Programs) 학회 설립 1994 ~ : EuroPLoP, ChiliPLoP Conferences 설립 PLoP 중심의 정기적 모임이 이루어짐

Expert (pattern) Problem : OOD 에서 가장 근간이 되는 기 본 패턴은 무엇인가 ? Solution : 필요한 정보를 갖고 있는 클래스 (Expert) 에서 기능을 수행. Benefits : - 캡슐화에 유리 (Low Coupling 지원 ). - 경량 클래스의 제작이 용이. - 구조가 명확해저 유지보수비용 절감.

Creator (pattern) Problem : 객체 생성의 책임을 지울 클래스는 ? Solution : 다음과 같은 조건이 만족될 때 클래스 B 에게 클래스 A 의 인스턴스화를 맡긴다. - B 는 A 객체의 집합 (Aggregation) 이다 - B 가 A 객체를 포함한다 - B 가 A 의 인스턴스들에 대한 기록을 수행 - B 는 A 객체와 밀접하게 사용된다 - B 가 A 의 Expert 이다 Benefits : - Low Coupling 지원

Low Coupling (pattern) Problem : 재활용성이 높은 디자인을 원한 다. Solution : 의존도가 낮아지도록 책임을 할 당. Benefits : - 타 클래스들의 변화 ( 패치, 버전업 등 ) 에 영향을 받지 않는다 - 각각의 구성요소별 이해가 쉽다 - 재활용성이 증대된다

High Cohesion (pattern) Problem : 복잡한 역할수행을 효과적으로 처리하 기고자 한다. Solution : 응집성이 높아지도록 책임을 할당 Detail : - Very low cohesion: 관련이 없는 많은 영역의 일들을 하나의 클 래스가 전담처리 - Los cohesion: 한 영역의 역할들을 한 클래스에서 처리 - High cohesion: 한 기능적 영역의 역할들을 적절히 세분화, 각 각을 다른 클래스에 맡기고 적절히 협력하여 전체 기능 수행 - Moderate cohesion: 개념적으로 비슷한 작은 영역들의 기능들 을 하나의 클래스에서 처리

Don’t talk to Stranger (pattern) Problem : 시스템 보안 / 효율성 증대 등의 이유로 특정 자원에 직접적 액세스를 막아 야 한다. Solution : 실 자원 또는 객체와 이를 이용 하려는 객체 사이를 매개해주는 인터페이 스 층을 추가하고 이를 통한 접근만을 허가 한다.

AbstractFactory (pattern) 의도 : 구체적인 클래스를 명시하지 않고 특정 객체에서 파생 또는 그에 의존적인 일련의 객 체들을 생성하기 위한 인터페이스를 제공한다.

Factory Method (pattern) 의도 : 인터페이스를 구현하는 객체를 생성시, 실제 생성할 객체의 타입 ( 클래스 ) 을 인터페이 스를 구현한 객체에서 선택 ( 객체생성위임 ).

Singleton (pattern) 의도 : 하나의 클래스에서 단 하나의 객체만이 생성되도록 보장하여 모든 외부 객체가 이를 공유할 수 있게 한다.

State (pattern) Solution : 상태 변화에 민감한 부분을 인터페 이스로 정의, 이를 구현한 클래스들을 상태별 로 각각 정의한다.  의도 : 특정 객체에 같은 메소드를 호출 시라도 내부 상태 변 화에 따라 다른 기능 을 수행해야 한다.

Decorator (pattern) 이미 생성된 객체에 동적으로 다양한 부가 기 능을 추가한다.

Decorator (pattern, 계속 )

Observer (pattern) 의도 : 특정 객체의 상태가 변화하면 그에 의존 된 다수의 객체들에 이를 통보 ( notify ) 한다.

Patterns of GoF (1) Creational Patterns - Abstract Factory - Builder - Factory Method - Prototype - Singleton

Patterns of GoF (2) Structural Patterns - Adapter - Bridge - Composite - Façade - Flyweight - Proxy

Patterns of GoF (3) Behavioral Patterns - Chain of Responsibility - Command - Interpreter - Mediator - Memento - Observer - State - Strategy - Template Method - Visitor

국내현황 (1) (from UML Korea) UML Korea 방문자만 이 설문 대상 설문자 중 60% 이상이 객체지향 방법론에 대 해 무지하다. 아직까지 객체지향 방 법론이 실제 프로젝트 에 적절히 적용되고 있 지 않다.

국내현황 (2) (from UML Korea) 설계 방법론에 대한 이 해 부족 방법론 적용 능력 부족 많은 시간과 풍부한 경 험 필요 방법론 자체의 개선 필 요

국내현황 (3) (from UML Korea) ¼ 가량만이 설계작업 을 적절히 적용 ¾ 은 시행착오 과정으 로 볼 수 있다. 많은 실경험 요구 지속적인 연구 / 투자 필 요

국내현황 (4) (from UML Korea) 60% 이상이 UML 기 반의 디자인을 하고 있 다. 디자인을 표현하기 위 한 세계 표준 언어로서 UML 의 중요성을 반영 하는 결과이다.

요약 / 정리 객체지향 패러다임에서 디자인 패턴의 위 상은 점점 커지고 있다. 패턴은 하나의 가이드라인 (Guideline) 일 뿐 절대적인 솔루션 (Solution) 이 아니다. 패턴 자체도 지속적인 추가 / 수정 / 보완이 이루어진다. ( 주로 PLoP 학회에서 ) 효율적인 패턴 적용을 위해서는 끊임없는 관심과 경험적 지식이 필요하다.

참고문언 Applying UML and Patterns (Craig Larman) Design Patterns (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) UML Distilled (Kendall Scott) UML Users Guide (Grady Booch, Ivar Jacobson, James Rumbaugh) 객체지향뉴스레터 (oonewsletter) ( 한국정보통신대학원대학교 ) 소프트웨어공학 따라잡기 ( 웹사이트 )

참고 사이트 SYRES 홈페이지 발표자