IEEE에서 제작한 본 SWEBOK에는 무시하기 어려운 비판론이 제기된 상황입니다. 주된 비판 주체로 초기에 본 문서 제작에 참여했다 철수한 ACM이 있으며, Grady Booch, Cen Kaner가 보입니다. 비판의 핵심은 본 문서가 주장하는 바인 'Generally accepted'가 사실이 아니라는 점과 본 문서와 밀접히 연계된 licensing(CSDP)의 무효성입니다.

상기 비판론을 염두하여 문서에 대한 내용을 받아들이길 권장합니다.

Introduction

IEEE 610.12-90에 의하면, '설계'란 아키텍처, 컴포넌트, 인터페이스 및 시스템 또는 컴포넌트의 기타 특성을 정의하는 과정과 해당 과정의 결과임. 프로세스 관점에서 보면, S/W 설계는 작성(construction)의 기반이 되는 S/W 내부 구조에 대한 기술을 얻기 위해 요구사항을 분석하는 SWE 생명주기 활동임. S/W 설계는 컴포넌트로 분해되고 조직화된 방법을 기술한 S/W 아키텍처와 이들 컴포넌트간의 interface를 기술하며, 이는 실제 작성이 가능한 수준의 세밀도로 표현되어야 함.

솔루션에 대한 청사진의 역할을 하여 본 모델을 통해 다양한 요구사항을 충족 가능한지 여부를 분석, 평가하여 결정을 이루도록 함.

설계 프로세스를 통해 다양한 솔루션 및 trade-off에 대한 시험 및 평가를 이룰 뿐 아니라 작성과 시험의 시작점의 역할을 수행.

표준에서는(IEEE 12207 등의) S/W 설계 과정을 두 개의 활동으로 나눔

  • S/W 아키텍처 설계(Architectural Design; top level Design이라 부르기도) : S/W의 최상위 구조와 조직을 기술하고 다양한 컴포넌트를 식별
  • S/W 세부 설계(detailed design) : 각각의 컴포넌트에 대해 작성이 가능하도록 기술

Breakdown of topics

1. S/W 설계 기본(Software Design Fundamentals)

1.1. 일반 설계 개념(General Design Concepts)

설계가 관여되는 영역은 S/W 뿐 아니라 문제 해결, 목표, 제한조건, 대안, 대표 등 다양함

1.2. S/W 설계의 컨텍스트(The context of software design)

S/W 설계의 역할을 이해하기 위해서는 컨텍스트 - SWE 생명 주기에서 설계의 주변 타 영역 : 요구사항 분석, S/W 구성, 테스트 등 - 를 이해하는 것이 중요.

1.3. S/W 설계 공정(The software design process)

일반적으로 두 개의 과정, 즉 아키텍처 설계와 상세 설계로 나눔.

  • S/W 아키텍처 설계(Architectural Design; top level Design이라 부르기도)

1.4. S/W의 최상위 구조와 조직을 기술하고 다양한 컴포넌트를 식별

  • S/W 세부 설계(detailed design)각각의 컴포넌트에 대해 작성(construction)이 가능하도록 해당 컴포넌트의 행위를 기술.

1.5. 가능화 기술(Enabling techniques)

'원칙'을 뜻하는 본 토픽은 다양한 S/W 설계 접근법과 개념의 기본을 이룸.

  1. 추상화(Abstraction)

    이질적인 정보를 제외하여 동일한 부분만을 취하는 과정. S/W 설계에서 추상화는 매개변수화(parameterization)과 명세화(specification)임. 명세화에 의한 추상화는 procedural 추상화, data 추상화 그리고 제어(control; iteration) 추상화를 이루게 됨.

  2. 결합(coupling)과 응집(cohesion)

    결합은 모듈간 관계력(the strength of the relationships)로 정의되며 응집은 요소가 모듈을 어떻게 이루는지로 정의됨.

  3. 분할(Decomposition)와 모듈화(modularization)

    대규모 S/W를 독립적 소규모 부분으로 나누는 것으로, 보통 목표는 컴포넌트의 각기 다른 기능 또는 책임을 위치시키는 데 있음.

  4. 캡슐화(Encapsulation) / 정보 은닉(Information hiding)

    추상에 대한 요소 및 내부 세부 사항을 한 데 묶고(grouping and packaging) 세부 요소에 접근 불가능하도록 함을 뜻함.

  5. 인터페이스와 구현의 분리(Separation of interface and implementation)

    Client에 공개된 인터페이스를 지정하고 컴포넌트 구현의 방법에 대해서는 격리하는 기법

  6. 충분성(sufficiency), 완전성(completeness), 근원성(primitiveness)

    이들 속성은 S/W 컴포넌트가 추상물에 대한 모든 중요 특성을 갖추고 있음을 뜻함.

2. S/W 설계의 핵심 이슈(Key Issues in Software Design)

횡단 관심(cross-cutting concerns)의 기능을 이루는 aspect에 대하여(aspect; S/W의 기능적 분해에 따른 단위가 아닌, 컴포넌트의 성능이나 의미론(semantics)에 시스템적 방법으로 영향을 주는 속성). 아래 토픽의 나열은 알파벳 순서. (aspect이외의 사항에 대해서는 '1.4. 가능화 기술'이나 '6 S/W 설계 전략 및 방법'을 따름)

2.1. 동시성(concurrency)

S/W를 프로세스, 작업(task), 스래드(Thread)로 나누는 방법 및 효율성, 원자성, 일치성(synchronization) 및 일정 이슈에 관계된 사항을 다룸.

2.2. 사건의 제어 및 다루기(Control and handling of events)

암시적 실행(invocation) 및 콜백(call-back)와 같은 메커니즘을 통해, 데이터와 제어 흐름을 구성하는 방법과 반응적(reactive)/일시적(temporal) 사건을 처리하는 방법에 대해 기술.

2.3. 컴포넌트의 배분(Distribution of components)

H/W에 S/W를 배분하는 방법, 컴포넌트간 통신 방법, 이질적 S/W를 다룸에 있어 미들웨어를 어떻게 사용할지에 대해 기술

2.4. 오류(error) 및 예외 처리와 결함 복구(Fault tolerance)

결함(fault) 방지 및 복구, 예외 조건에 대한 처리에 대하여.

2.5. 상호작용(Interaction)과 표현(Presentation)

사용자와 표현계층 간에 상호작용을 위해 어떻게 구조 및 조직화를 이룰지에 대하여(예를 들어, MVC 접근법을 통해 표현계층과 업무 논리를 분리하기 등)

2.6. 데이터 지속성(Data persistence)

긴 수명의 데이터를 다루는 방법에 대하여.

3. S/W 구조 및 아키텍처(Software structures and Architecture)

1990년대 중반부터 S/W 아키텍처에 대한 일반적(generic) 패턴이 나타났으며, 이들의 최종 목적은 재사용에 있음.

3.1. 아키텍처 구조 및 관점(Architectural structures and viewpoints)

View란 S/W 시스템의 특정 속성을 보여주는 S/W 아키텍처의 단면으로서, 각각의 view는 S/W 설계에 연계된 각기 다른 이슈를 포함함. 예를 들어,

  • 논리 뷰(logical view)는 기능적 요구사항을 나타내고,
  • 공정 뷰(process view)는 동시성 이슈를 나타내며,
  • 물리 뷰(physical view)는 배분(distribution) 이슈를 보여주고,
  • 개발 뷰(development view)는 설계가 구현단위로 어떻게 분해되는지를 보여줌.

위와는 다른 용어로, 행위/기능적/구조적/데이터 모델링 뷰도 존재.

정리하자면, S/W 설계란 설계 공정을 통해 만들어지고 상대적 의존/독립적 뷰로 구성된 다면적 구조물(multi-faceted artifact)임.

3.2. 아키텍처 스타일(Architectural styles - macroarchitectural patterns)

아키텍처 스타일이란 아키텍처에 부과된 일련의 제한조건으로서, 이들 조건을 만족시키는 일련의 아키텍처 모임(아키텍처의 아키텍처)을 정의함(a set of constraints on an architecture that defines a set or family of architectures that satisfies them). 따라서 아키텍처 스타일은 S/W의 고수준 조직(macroarchitecture)를 제공하는 메타모델로 바라볼 수 있음. 종류로서,

  • 일반 구조(General structure) : layers, pipes and filters, blackboard
  • 분산 시스템(Distributed systems) : C/S, three tiers, broker
  • 상호작용 시스템(interactive systems) : MVC, PAC(Presentation-Abstraction-Control)
  • 적응적 시스템(Adaptive systems) : micro-kernel, reflection
  • 기타 : batch, interpreter, process control, rule-based 등이 있음.

3.3. 설계 패턴(Design patterns - microarchitectural patterns)

간단히 이야기해서 설계 패턴이란 특정 컨텍스트 내의 일반적(common) 문제에 대한 일반적(common) 해결법임. Macro 수준의 패턴을 논하는 아키텍처 스타일에 비해 micro 수준을 논함. 종류로서,

  • 생성 패턴(builder, factory, prototype, singleton)
  • 구조 패턴(adaptor, bridge, composite, decorator, façade, flyweight, proxy)
  • 행위 패턴(command, interpreter, iterator, mediator, observer, state, strategy, template, visitor)가 있음

3.4. 프로그램과 프레임워크의 일족(Families of Programs and Frameworks)

S/W 설계와 컴포넌트에 대한 재사용을 가능케 하는 또 다른 방법으로서, S/W 일족을 설계하는 SPL(Software Product Lines)이 있음. 이는 해당 일족(family)의 멤버 사이에서 일반성(commonality)을 식별하고, 가변성(variability)을 위한 재사용/커스터마이징 가능 컴포넌트를 사용함으로 이룸.

  • 프로그래밍에서 이에 관련된 주요 개념은 프레임워크임 : hot spot이라 불리는 특정 플러그인의 실행을 통해 확장 가능한, 부분적으로 완성된 S/W 하위 시스템(subsystem)4. S/W 설계 품질 분석 및 평가(Software Design Quality Analysis and Evaluation)

4 . S/W 설계 품질 분석 및 평가(Software Design Quality Analysis and Evaluation)

4.1. 품질 속성(Quality attributes)

고품질의 설계를 얻기 위해서는 여러 품질 속성을 고려해야. 가능성(~ilities)을 나타내는 요소로 maintainability, portability, testability, traceability가 있으며, 상태(~ness)를 나타내는 요소로, correctness, robustness 및 'fitness of purpose' 등이 있음.

  • Run-time에 나타나는 속성: performance, security, availability, functionality, usability
  • 비 run-time 요소: modifiability, portability, reusability, integrability, testability
  • 이들은 아키텍처에 내재된 품질(conceptual integrity, correctness, completeness, buildability)에 관계됨.

4.2. 품질 분석 및 평가 기법(Quality analysis and evaluation techniques)

S/W 설계 품질을 검증하기 위한 다양한 도구와 기법이 존재

  • S/W 설계 검토(review) : 종종 그룹을 지어 설계물의 품질을 검증(verify and ensure)하는 비형식/반형식적 기법. 설계 검토, 인스펙션, 시나리오 기반 기법, 요구사항 추적 등.
  • 정적 분석 : 형식/반형식적 정적(비 실행) 분석으로서, 설계 평가를 위해 수행(오류-트리 분석 또는 자동화된 교차검토(cross checking)이 있음)
  • 시뮬레이션/프로토타이핑 : 설계 평가를 위한 동적 기법(ex. 성능 시뮬레이션, 타당성 프로토타이핑)

4.3. 측정기준(Measures)

측정기준은 S/W 설계의 크기, 구조, 품질 등의 다양한 면을 평가하기 위해 사용함. 대부분의 측정기준은 설계 접근법에서 기인하며 크게 두 개의 카테고리로 분류됨.

  • 기능지향(Function-oriented(structured)) 설계 측정기준 : 기능적 분할을 통해 설계 구조를 얻으며 때론 계층도(Hierarchical diagram)라 일컫는 구조 차트(structure chart)가 대표적
  • 개체지향(Object-oriented) 설계 측정기준 : 클래스 다이어그램이 대표적. 측정은 각 클래스의 속성에 대해 이루어짐.

5. S/W 설계 표기법(Software Design Notations)

많은 표기법이 각각의 상황(구조/행위, 아키텍처/세부 등)에 맞게 존재함.

5.1. 구조 기술(Structural descriptions - static view)

주요 컴포넌트를 식별함과 동시에 이들이 어떻게 상호작용하는지를 기술

  • 아키텍처 기술 언어(ADL; Architectural Description Language) : 텍스트 기반의 (형식적; formal)언어로 컴포넌트와 연결자(connector)를 통해 아키텍처를 기술
  • 클래스 & 개체 다이어그램 : 클래스 간 또는 개체 간 관계 기술
  • 컴포넌트 다이어그램 : 컴포넌트 간 관계 기술(component; 물리적이고 교체 가능한 시스템의 일부로, 일련의 interface를 구현, 제공, 준수)
  • CRCs(Class responsibility collaborator cards) : 컴포넌트(또는 클래스)의 이름과 해당 책임, 관련 컴포넌트 이름을 기입하는 데 사용
  • ERD(Entity-relationship diagram) : 정보시스템에 저장된 데이터에 대한 개념 모델을 표현
  • IDL(Interface description language) : 프로그래밍적 언어로 S/W 컴포넌트의 인터페이스를 정의
  • Jackson structure diagram : 순차, 선택, 반복을 통해 데이터 구조를 기술
  • Structure Chart : 프로그램 내 모듈 간 호출 구조를 기술

5.2. 행동 기술(Behavior descriptions - dynamic view)

대부분은 세부 설계 과정 중에 사용됨.

  • Activity diagrams : 활동(activity; 상태 기계 내에서의 비 원자적/계속적(on-going) 실행)에서 활동으로 이루어지는 제어 흐름을 보여줌
  • Collaboration diagrams : 개체 간 일어나는 상호작용을 표현하여 특히 객체, 연결 및 연결 내에서 발생하는 메시지 교환을 강조.
  • DFDs(Data flow diagrams) : 프로세스 간 데이터 흐름을 표현
  • Decision tables & diagrams : 조건과 행동의 복잡한 조합을 표현
  • Flowcharts & structured flowcharts : 제어 흐름과 수행될 관련 행동을 기술
  • Sequence diagrams : 개체 간 상호작용을 표현하지만 여기서는 메시지의 시간 순서에 중점을 둠
  • State transition & state-chart diagrams : 상태 기계 내에서의 상태 변이에 대한 제어 흐름을 표현
  • 정형 명세 언어 : 수학적 기본 표기법을 사용하여 엄격하고 추상적으로 S/W 컴포넌트의 인터페이스 및 행위를 표현. 종종 사전/사후 조건을 사용
  • 의사코드 및 PDLs(Program design language) : 구조적 프로그래밍을 띈 언어로 세부 설계 단계에서 프로시저의 행위를 기술

6. S/W 설계 전략 및 방법(Software Design Strategies and Methods)

다양한 설계 전략(strategy)이 일반적인 반면, 방법(method)은 특화되어 그 방법만의 표기법과 프로세스, guideline을 제공함. 이들 방법은 지식 전달의 수단과 S/W 개발 팀의 공용 프레임워크의 역할을 담당. [SWE 도구 및 방법 KA와 연계됨]

6.1. 일반 전략(General Strategies)

분할과 정복, 단계적 정제(stepwise refinement), 하향식/상향식, 데이터 추상화/정보 은닉, heuristic 사용, 패턴 및 패턴 언어 사용, 반복/점증 접근법의 사용 등

6.2. 기능 지향 설계(Function-oriented(Structured) Design)

분할을 중점으로 S/W의 주요 기능을 식별하고 하향식 방법으로 이들을 정제하는 기법. 구조적 분석 이후 수행되어 DFD 및 관련 프로세스 기술을 만들어냄.

다양한 전략(transformation analysis, transaction analysis 등)과 heuristic(fan-in/fan-out, 영향 범위 vs 제어 범위 등)은 DFD를 구조 차트로 표현되는 S/W 아키텍처로 변환하는 데 사용.

6.3. 개체 지향 설계(Object-oriented design)

1980 중반의 Object-based design(명사:object, 동사:method, 형용사:attribute)에서 시작하여, 추상과 다형이 핵심인 Object Oriented Design, 메타 정보가 정의되고 접근되는(reflection을 통해) CBD까지 이름.

OO Design은 데이터 추상화에서 출발하지만, 책임 주도 설계는 OO 설계의 대안으로 제안됨.

6.4. 데이터 구조 중심 설계(Data-structure centered designed)

Jackson, Warnier-Orr 등이 대표적인 본 방법은 기능이 아닌 데이터 구조 중심적임. 데이터 구조에 대한 입출력 기술(Jackson's 구조도)을 시작한 이후 프로그램의 해당 데이터 구조에 맞춰 제어 구조를 개발.

6.5. 컴포넌트 기반 설계(Component-based design)

S/W 컴포넌트란 잘 정의된 interface를 갖고, 독립적으로 구성/배포 가능한 의존성을 기반으로 만들어진 독립 단위임. 재사용 극대화에 초점.

6.6. 기타 방법(other methods)

다른 방법도 존재하지만 주류는 아님 : formal & rigorous 방법 및 transformational methods)

Comments