소프트웨어 설계

3. 소프트웨어 설계의 중요성

소프트웨어 설계 문서는 코딩 전에 제약 조건, 명세, 요구 사항 등을 조정하기 위해 검토되거나 제시될 수 있다.^[3] 시뮬레이션이나 프로토타입을 프로그래밍한 후에 검토를 거쳐 재설계가 이루어질 수 있다. 계획이나 요구 사항 분석 없이 코딩 과정에서 소프트웨어를 설계하는 것도 가능하지만,^[3] 더 복잡한 프로젝트의 경우 이는 실현 가능성이 낮다. 코딩 전에 별도의 설계를 통해 다학제 디자이너와 전문가가 프로그래머와 협력하여 유용하고 기술적으로 건전한 소프트웨어를 제작할 수 있다.

이러한 과정을 통하여 프로그래밍을 시작하기 전에 제약 조건, 요구 사항 등이 명확해지고 검토된다. 또한 시뮬레이션이나 프로토타입 구축을 통해 설계 변경이 이루어지기도 한다. 요구 분석 및 계획 수립 없이 프로그래밍을 하면서 설계를 진행하는 것도 가능하지만, 복잡하고 대규모 프로젝트에서는 그러한 공정의 생략은 선택 사항으로 고려되지 않는 것이 일반적이다. 프로그래밍 전에 설계 공정을 둠으로써, 소프트웨어의 대상 영역 전문가와 설계자가 프로그래머와 공동으로 작업하여 소프트웨어의 편의성과 기술적 정당성을 높일 수 있다.

4. 요구 사항 분석

소프트웨어 설계의 한 요소는 소프트웨어 요구 사항 분석(SRA)이다. SRA는 소프트웨어 개발 프로세스의 일부로, 소프트웨어 공학에 사용되는 명세서를 나열한다.

분석 결과는 해결해야 할 더 작은 문제들이다.

설계는 기능에 초점을 맞추므로 동일한 문제에 대해 여러 개의 설계를 가질 수 있다. 환경에 따라 신뢰할 수 있는 소프트웨어 프레임워크를 기반으로 생성되거나 적절한 디자인 패턴으로 구현되는 등 설계가 달라지는 경우가 많다.

5. 설계 원칙

소프트웨어 설계에는 다양한 원칙이 적용된다. 주요 원칙들은 다음과 같다.

• 추상화: 특정 목적과 관련된 정보만 남기고, 배경 정보나 설명을 생략하여 필수적인 특징을 나타낸다.
• 개선: 기능을 단계별로 분해하여 계층 구조를 개발한다. 추상화와 개선은 상호 보완적이다.
• 모듈성: 소프트웨어 아키텍처를 모듈이라는 구성 요소로 나눈다.
• 소프트웨어 아키텍처: 소프트웨어의 전반적인 구조와 그 구조가 제공하는 개념적 무결성을 의미한다. 좋은 소프트웨어 아키텍처는 성능, 품질, 일정 및 비용 측면에서 좋은 결과를 가져온다.
• 제어 계층 구조: 프로그램 구성 요소의 구성을 나타내며 제어 계층 구조를 의미하는 프로그램 구조이다.
• 구조적 분할: 프로그램 구조를 가로 및 세로로 나눈다. 가로 분할은 각 주요 기능에 대한 별도 분기를 정의하고, 세로 분할은 제어 및 작업이 상향식으로 분산되어야 함을 의미한다.
• 자료 구조: 개별 데이터 요소 간의 논리적 관계를 나타낸다.
• 소프트웨어 프로시저: 각 모듈의 개별 처리에 초점을 맞춘다.
• 정보 은닉: 모듈은 해당 정보가 필요하지 않은 다른 모듈에서 접근할 수 없도록 설계해야 한다.

6. 설계 고려 사항

소프트웨어 설계 시 고려해야 할 사항은 다양하다. 이러한 요소들은 소프트웨어가 충족해야 할 목표와 기대치를 반영하며, 소프트웨어의 품질과 성공에 큰 영향을 미친다. 주요 고려 사항은 다음과 같다.

• 호환성: 소프트웨어가 다른 제품과 상호 운용될 수 있어야 한다. 예를 들어, 이전 버전과의 하위 호환성을 고려해야 한다.^[3]
• 확장성: 기본 아키텍처를 크게 변경하지 않고도 소프트웨어에 새로운 기능을 추가할 수 있어야 한다.
• 모듈성: 소프트웨어는 잘 정의되고 독립적인 구성 요소로 구성되어야 유지 관리가 용이하다. 각 구성 요소는 격리되어 구현 및 테스트될 수 있으며, 이를 통해 소프트웨어 개발 프로젝트에서 작업을 분할할 수 있다.
• 내결함성: 소프트웨어는 구성 요소 오류에 대해 저항하고 복구할 수 있어야 한다.
• 유지 관리성: 버그 수정 또는 기능 수정을 얼마나 쉽게 수행할 수 있는지 나타낸다. 높은 유지 관리성은 모듈성과 확장성의 결과일 수 있다.
• 신뢰성 (소프트웨어 내구성): 소프트웨어는 지정된 기간 동안 명시된 조건에서 필요한 기능을 수행할 수 있어야 한다.
• 재사용성: 기존 소프트웨어의 일부 또는 전부를 수정 없이 다른 프로젝트에서 사용할 수 있어야 한다.
• 견고성: 소프트웨어는 스트레스 하에서 작동하거나 예측할 수 없거나 유효하지 않은 입력을 허용할 수 있어야 한다. 예를 들어, 메모리 부족 조건에서도 잘 작동하도록 설계할 수 있다.
• 보안: 소프트웨어는 적대적인 행위와 영향에 견딜 수 있고 저항할 수 있어야 한다.
• 사용성: 소프트웨어 사용자 인터페이스는 대상 사용자가 쉽게 사용할 수 있어야 한다. 매개변수의 기본값은 대다수의 사용자에게 적합한 선택이 되도록 해야 한다.^[7]
• 성능: 소프트웨어는 사용자가 허용할 수 있는 시간 내에 작업을 수행해야 하며, 너무 많은 메모리를 필요로 하지 않아야 한다.
• 이식성: 소프트웨어는 다양한 조건과 환경에서 사용할 수 있어야 한다.
• 확장성: 소프트웨어는 증가하는 데이터, 추가된 기능 또는 사용자 수에 잘 적응해야 한다. 마크 브루커(Marc Brooker)에 따르면 "시스템은 추가 작업 부하의 한계 비용이 거의 일정하게 유지되는 범위에서 확장 가능합니다." 서버리스 기술은 이러한 정의에 적합하지만 인프라 비용뿐만 아니라 총 소유 비용을 고려해야 한다.^[8]

7. 모델링 언어

모델링 언어는 정보, 지식 또는 시스템을 일관된 규칙 집합으로 정의된 구조로 표현하는 데 사용될 수 있다. 이러한 규칙은 구조 내의 구성 요소를 해석하는 데 사용된다. 모델링 언어는 그래픽 또는 텍스트 기반일 수 있다. 소프트웨어 설계를 위한 그래픽 모델링 언어의 예는 다음과 같다.

• 아키텍처 기술 언어(ADL)는 소프트웨어 아키텍처를 설명하고 표현하는 데 사용되는 언어이다.
• 비즈니스 프로세스 모델링 표기법(BPMN)은 프로세스 모델링 언어의 한 예이다.
• EXPRESS 및 EXPRESS-G (ISO 10303-11)는 국제 표준의 범용 데이터 모델링 언어이다.
• 확장된 엔터프라이즈 모델링 언어(EEML)는 여러 계층에서 비즈니스 프로세스 모델링에 일반적으로 사용된다.
• 순서도는 알고리즘 또는 기타 단계별 프로세스의 개략적인 표현이다.
• 기본 모델링 개념(FMC)은 소프트웨어 집약적 시스템을 위한 모델링 언어이다.
• IDEF는 모델링 언어의 일종으로, 가장 주목할 만한 언어는 기능 모델링을 위한 IDEF0, 정보 모델링을 위한 IDEF1X, 그리고 온톨로지 모델링을 위한 IDEF5를 포함한다.
• 잭슨 구조적 프로그래밍(JSP)은 데이터 스트림 구조와 프로그램 구조 간의 일치성을 기반으로 하는 구조적 프로그래밍 방법이다.
• LePUS3는 대규모 객체 지향(자바, C++, C#) 프로그램 및 디자인 패턴을 모델링하는 데 주로 적합한 객체 지향 시각적 디자인 설명 언어이자 형식 사양 언어이다.
• 통합 모델링 언어(UML)는 소프트웨어를 구조적으로, 행동적으로 모두 설명하는 일반적인 모델링 언어이다. 그래픽 표기법을 가지고 있으며 프로파일 (UML)로 확장이 가능하다.
• 알로이 (사양 언어)는 소프트웨어 시스템의 복잡한 구조적 제약 조건과 동작을 표현하기 위한 범용 사양 언어이다. 일계 관계 논리를 기반으로 간결한 언어 기반을 제공한다.
• 시스템 모델링 언어(SysML)는 시스템 엔지니어링을 위한 새로운 범용 모델링 언어이다.
• 서비스 지향 모델링 프레임워크(SOMF)

8. 디자인 패턴

소프트웨어 설계자는 이전에 다른 사람들에 의해 다루어졌거나 해결되었을 수 있는 설계 문제를 식별할 수 있다. 일반적인 문제에 대한 해결책을 설명하는 템플릿 또는 패턴을 디자인 패턴이라고 한다. 이러한 패턴을 재사용하면 소프트웨어 개발 속도를 높일 수 있다.^[10]

9. 설계 방법론

설계 방법론은 실제 시스템 설계에서 템플릿이나 프레임워크 역할을 한다. 실제 설계 과정을 단순화하고, 품질 향상을 위한 설계 원칙의 적용을 가능하게 한다.

• 모듈성, 응집도와 결합도, 소프트웨어 구성 요소를 활용하는 모듈화 설계
• 객체 지향 분석 설계
• 모델-뷰-컨트롤러, 다층 아키텍처
• 도메인 주도 설계

10. 코드와 설계의 관계

에츠허르 데이크스트라는 소프트웨어에서 "설계"라는 용어를 사용하는 것에 대해, 프로그램의 소스 코드가 프로그램이 생성하는 것에 대한 설계 '그 자체'라는 어려움이 있다고 언급했다.^[11] 이러한 관점에서 "소프트웨어 설계"는 설계의 설계를 의미한다.

도널드 커누스는 TeX를 작성한 경험을 바탕으로, 프로그램을 구현하기 전에 설계를 시도하는 것이 얼마나 헛된 일인지 다음과 같이 설명했다.^[12]
"TeX는 내가 그것을 단순히 명세하고 초기 구현에 완전히 참여하지 않았다면 완전히 실패했을 것이다. 구현 과정은 끊임없이 예측하지 못한 질문으로 이끌었고, 원래 명세를 어떻게 개선할 수 있는지에 대한 새로운 통찰력을 얻게 해주었다."

11. 한국적 특수성

한국은 IT 강국으로서, 소프트웨어 설계 분야에서도 특수한 환경과 조건을 가지고 있다. 이러한 특수성은 소프트웨어 설계 방식과 결과물에 큰 영향을 미친다.

11. 1. 기술 발전

참조

_[1] 논문 A proposal for a formal definition of the design concept Springer-Verlag
_[2] 논문 A Science of design for software-intensive systems
_[3] 간행물 A Proposal for a Formal Definition of the Design Concept Springer-Verlag
_[4] 서적 201 Principles of Software Development McGraw Hill
_[5] 서적 Object-Oriented Analysis and Design with Applications http://dl.acm.org/ci[...] Addison Wesley 2015-01-30
_[6] 서적 Refactoring for Software Design Smells Morgan Kaufmann 2014-11
_[7] 서적 Scenario-Based Design: Envisioning Work and Technology in System Development John Wiley & Sons
_[8] 서적 Building Serverless Applications on Knative O'Reilly Media
_[9] 서적 Service-Oriented Modeling: Service Analysis, Design, and Architecture Wiley & Sons
_[10] 웹사이트 C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems http://msdn.microsof[...] C# Books from O'Reilly Media 2012-05-15
_[11] 웹사이트 On the cruelty of really teaching computing science http://www.cs.utexas[...] 2014-01-10
_[12] 웹사이트 Notes on the Errors of TeX http://www.tug.org/T[...]