Bera의 개발 이야기

소트프웨어의 설계: 목적을 달성하기 위한 여러가지 방법 중 원하는 소프트웨어를 어떻게 만들어낼지를 결정하는 작업

[좋은 소프트웨어 설계의 특성]

이해 용이성 (Understandability)	전체 소프트웨어나 개별 구성 요소에 대해 쉽게 이해할 수 있어야 한다.
수정 용이성 (Modifiability or Flexibility)	요구 사항의 변경에 따른 수정이 용이해야 한다.
관리 용이성 (Maintainability)	소프트웨어 유지, 보수, 관리 단계에서 버그 수정이나 장애 대처, 요구 사항 변경, 성능 향상 등의 이유로 소프트웨어를 수정해야 할 경우 이를 쉽게 수행할 수 있어야 한다.
재사용 용이성 (Reusability)	개발된 소프트웨어 구성 요소들을 다른 소프트웨어를 개발할 때 쉽게 재사용 가능해야 한다.
테스트 용이성 (Testability)	소프트웨어가 원하는 동작이나 기능을 수행하는지 테스트하기 쉬워야 한다.
높은 안정성 (Reliability)	소프트웨어가 오류없이 원하는 작업을 수행할 수 있는 확률이 충분히 높아야 한다.

이 밖에도 소프트웨어는 기본적으로 원하는 목적을 정확히 만족시켜야 하고, 적은 자원을 사용해서 최대한의 성능을 발휘할 수 있도록 효율적이어야 하며, 상호 운영성 등도 뛰어나야 한다.

위 처럼 좋은 소프트웨어가 갖추어야 할 특성은 다양하지만, 이런 특성들을 모두 만족시킬 수 있게 소프트웨어를 설계하는 것은 어렵다. 왜냐하면 위의 특성들은 서로 상반되는 특징을 가진것들이 있는데, 예로 효율성을 강조하면 자료구조나 알고리즘이 복잡해지고, 이에 따라 이해 용이성이나 수정 용이성 등이 떨어질 가능성이 크다. 따라서, 최적의 설계(Optimal Design)를 하기 위해선 구체적인 목적이나 상황에 맞추어 위 특성들 중 가장 우선해야 할 것들을 선별하고 그에 따라 설계를 하는 것이라 할 수 있겠다.

[좋은 소프트웨어를 설계하기 위한 도구]

추상화(Abstraction)와 구체화(Refinement)

추상화란 구체적이고 복잡한 사실을 간략화시키는 것을 의미하고, 반대로 구체화란 구체적이고 상세한 사실을 계속해서 추가해나가는 것을 가리킨다.

좋은 소프트웨어를 설계하기 위해서는 여러 관점에서 소프트웨어를 설계할 필요가 있는데 이때 특정 관점과 무관한 사실들은 간략화시켜 생각하는 것이 편리하다. 반면 소프트웨어 개발은 주어진 목적을 달성하기 위해 점차 구체화되어가는 과정이라고 볼 수 있다. 따라서 좋은 소프트웨어를 설계하기 위해서는 추상화와 구체화를 적절히 적용할 필요가 있다.

모듈화(Modulariztion)와 계층화(Hierarchy)

모듈화란 소프트웨어를 모듈 단위로 분할(Decomposition)시키는 것을 의미한다. 여기서 모듈이란 소프트웨어의 요구 사항을 만족시키기 위한 개별 구성 요소를 가리킨다. 레고 블록을 다루는 것처럼 소프트웨어를 모듈 단위로 분리해서 다루는 것이 이해하기도 쉽고, 필요에 따라 재사용하거나 수정하기도 편리하기 때문이다.

이러한 모듈들은 상호 연관 관계가 너무 복잡해지면 이해하기 힘들어질 뿐만 아니라, 수정, 관리, 재사용이 어려워지기 때문에 모듈간 상호 연관 관계는 관리 가능한 형태로 구성하는 것이 바람직하다. 이를 위해서 필요한 도구로는 계층화가 있을 수 있다. 계층화란 비슷한 목적의 모듈들을 같은 계층에 배치하고 계층과 계층간은 트리와 유사한 형태로 사용 관계를 구성해주는 것을 의미한다.

[모듈들의 계층화(Hierarchy) 구성 형태 예]

정보은닉(Information Hiding)과 변경의 국지화(Localization of Change)

정보 은닉이란 소프트웨어 설계 시의 상세한 결정 사항을 모듈의 내부에 숨기고 외부에는 해당 모듈을 사용할 수 있는 인터페이스(Interface)만을 공개하는 것을 의미한다. 이 같은 정보 은닉의 목적은 모듈 내부의 결정 사항에 변동이 생겼을 경우 모듈 외부에는 그에 따른 영향을 받지 않게 하기 위한 것이다.

이처럼 소프트웨어 설계에 정보 은닉을 적용하게 되면 요구 사항의 추가나 변동에 따라 소프트웨어의 변경이 필요할 경우 그 수정 범위를 특정 모듈 내부로 한정시킬 수 있게 된다. 이와 같이 소프트웨어에 변경이 필요할 경우 그 수정 범위가 한정되도록 만들어주는 것을 변경의 국지화라고 하는데 이를 통해 소프트웨어는 수정이나 관리 및 재사용 등이 쉬워지게 된다.

방법론(Methodology, Method) 및 지침(Guideline)

방법론이나 지침은 말 그대로 소프트웨어의 생성부터 소멸까지 전 과정에서 수행해야 하는 일처리 방법이나 절차 등을 정리해놓은 것을 가리킨다. 따라서 소프트웨어 설계 과정에서도 이런 방법론이나 지침은 유용하다. 특히 방법론이나 지침은 수많은 경험을 바탕으로 이를 일반화시켜놓은 것이기 때문에 좋은 소프트웨어를 설계하고자 할 때 부족한 경험을 메꿀 수 있는 좋은 도구가 될 수 있다. 또한 정형화된 방법론이나 지침은 소프트웨어 개발을 표준화 시킬 수 있게 도와준다.

위의 내용들은 좋은 소프트웨어를 설계하기 위한 도구들이다. 하지만 여기서 끝이 아니고 아주 중요한 한가지가 더 필요하다. 그것은 바로 경험이다. 하지만 경험이란 많은 시간과 노력이 필요한 것이다. 하지만 이것을 빠르게 얻을 수 있는 방법이 있다. 그것은 많은 경험을 가진 사람들의 지식과 노하우를 공유하는 것이다. 그것이 바로 디자인 패턴이다. 앞서 이 세계를 개척해나간 선배 프로그래머들이 소프트웨어를 개발하는데 있어서 좀더 좋은 방법에 대해 지식과 노하우를 정리해 놓은 것이 디자인 패턴이라고 생각하면 된다.

이제까지 [GOF 디자인 패턴! 이렇게 활용한다] 책의 내용들을 순서대로 정리해 보았다. 하지만 이후로는 책의 순서를 따르지 않고 내가 필요한 것 위주로 디자인 패턴을 하나씩 포스팅 하고자 한다.

※ [GoF 디자인 패턴! 이렇게 활용한다 : C++로 배우는 패턴의 이해와 활용] 책을 보고 공부한 내용중 중요하다 생각되는 부분들을 적어놓았습니다.

소프트웨어 개발 과정은 일반적으로 아래와 같이 이루어진다.

요구사항 명세 -> 요구사항 분석 -> 기본 설계 -> 상세 설계 -> 구현 -> 테스팅 -> 유지 보수

이 과정도 프로젝트의 특성에 따라 여러 종류의 모델이 있다.

ex) 폭포수 모델, 프로토타이핑 모델, 점증적 모델, V 모형, 일정 중심 설계 모형, 진화적 출시 모형

이 뿐만 아니라 프로젝트 개발을 관리해주는 관리 프로세스 모델 또한 존재한다.

이와 관련해서는 나중에 포스팅을 하고자 한다.

소프트웨어 개발 과정을 구성하는 각 단계별 주요 작업 및 산출물은 아래와 같이 정리된다.

개발 단계	주요 작업	주요 산출물
요구 사항 명세	- 요구 사항의 정확한 이해 및 유도  - 과다하거나 불필요한 요구 사항에 대한 협상 및 조율  - 요구사항의 적합성 검토 및 향후 예측	- 전반적인 업무 흐름도  - 요구 사항 (상세)기술서  - 요구 사항 검토 의견서
요구 사항 분석	- 요구 사항에 대한 체계적이고 구체적인 분석  - 실제 실행 환경에 대한 분석	- 기능, 행위, 데이터 측면의 요구사항 분석 명세서  - 실행 환경 분석 보고서
기본 설계	- 시스템 아키텍쳐 설계  - 데이터베이스 설계  - 시스템 구성요소간 프로토콜 설계  - 사용자 인터페이스 설계	- 시스템 아키텍쳐 설계도  - 데이터베이스 스키마  - 프로토콜 설계도  - UI 설계 결과물
상세 설계	- 상세 자료구조 설계  - 상세 알고리즘 설계	- 자료구조 설계도(클래스 다이어그램)  - 알고리즘 명세서(슈도 코드 등)
구현	- 구현 언어 및 개발 환경 선정    (OS, 표준 라이브러리 등)  - 코딩	- 프로그램 소스코드
테스팅	- 단위 테스팅: 단위 모듈 테스팅  - 통합 테스팅: 모듈간 통합 테스팅  - 적합성 테스팅: 요구 사항과 일치성 여부 테스팅  - 시스템 테스팅: 시스템 복구 테스팅, 보안 테스팅, 스트레스 테스팅, 성능 테스팅	- 테스트 계획서  - 테스트 결과 보고서  - 수정된 최종 소스코드
유지 보수	- 추가, 수정 요구 사항 검토 및 반영  - 장애 및 오류 발생 시 대처와 복구  - 시스템 및 서비스 운영, 유지보수 보고  - 역공학 또는 재공학 필요성 검토	- 추가, 수정 요구 사항이 반영된 모든 개발 산출물  - 각종 보고서  - 역공학 또는 재공학을 위한 자료

- 요구 사항 명세 단계: 소프트웨어 개발의 목적을 명확히 이해하고 공유하며, 구체적인 요구사항에 대해 논리적이고 합리적인지를 검토하여 필요 시 요구 사항을 조율하거나 조정한다.

- 요구 사항 분석 단계: 기능(Function), 행위(Behavior), 데이터(Data) 측면에서 요구 사항을 체계적이고 구체적으로 분석하고, 실제 개발될 소프트웨어가 실행될 환경에 대해서도 분석, 검토를 수행한다.

- 기본 설계 단계: 개발할 소프트웨어의 전반적인 아키텍쳐를 구상하고, 구성 요소간 사용할 프로토콜을 정의하며, 사용자 인터페이스를 결정한다. 또한 데이터베이스를 사용할 경우 데이터베이스 스키마를 설계한다.

- 상세 설계 단계: 프로그램 구현을 위한 구체적인 자료구조와 알고리즘을 결정한다.

- 구현 단계: 상세 설계된 결과물을 실제 프로그래밍 언어를 사용해서 코딩한다.

- 테스팅 단계: 구현된 개별 모듈별 단위 테스트와 각 모듈들을 통합해서 제대로 동작하는지 여부를 점검하는 통합 테스트, 요구 사항과 정확히 일치하게 동작하는지 여부를 검증하는 적합성 테스트, 실제 실행 환경을 대상으로 장애 복구나 보안, 안정성, 성능 등에 대한 점검을 수행하는 시스템 테스트를 수행한다.

- 유지 보수 단계: 개발 완료된 소프트웨어에 대해 추가, 변경 요구 사항을 검토하고 반영하거나 장애나 오류 발생 시 이에 대한 대처 및 복구, 실행되는 소프트웨어의 지속적인 모니터링 및 시스템 운영 등을 수행한다.

※ [GoF 디자인 패턴! 이렇게 활용한다 : C++로 배우는 패턴의 이해와 활용] 책을 보고 공부한 내용중 중요하다 생각되는 부분들을 적어놓았습니다.

- 소프트웨어 개발을 위한 개념이나 철학은 크게 구조적 접근 방식과 객체지향적 접근 방식이 있다.

구조적인 접근 방식은 구현하고자 하는 기능, 목적 위주로 하향식으로 세분화, 구체화 시킴으로써 해결하는 방식이고 객체지향적인 방식은 소프트웨어를 데이터 위주의 관점으로 바라보면서 구체적인 데이터들간의 상호 관계를 정의함으로써 원하는 목적을 달성할 수 있는 방식이다.

- 구조적 접근 방식은 객체지향적 접근 방식보다 좀더 빨리 해결책을 만들어낼 수 있는데, 구조적 접근 방식은 원하는 목적을 직접적인 기능으로 세분화, 구체화 하여 해결책을 생각해나가는 데 반해, 객체지향 적븐 방식은 먼저 사용할 데이터와 그 데이터를 조작하기 위한 인터페이스를 객체로 정의한 후에 정의한 객체들간을 상호 관련시킴으로써 필요한 기능을 수행할 수 있는 해결책을 만들어내는 2단계 방식이기 때문이다.

- 구조적 접근 방식을 이용한 해결책이 객체지향적 접근 방식을 이용한 해결책보다 구조가 간단하다. 왜냐하면 구조적 접근 방식은 하향식으로 기능을 분할 정복하는 것이므로 해결칙이 트리 구조를 이루지만, 객체지향 접근 방식은 객체들간을 상호 관련지우면서 복잡한 네트워크 구조로 해결책이 만들어지기 때문이다.

아래에 구조적 접근 방식과 객체지향적 접근 방식의 차이점을 표로 비교해 놓았다.

비교 항목	구조적(Structured)	객체지향적(Object Oriented)
주요 관점	기능(Function 또는 Process) 위주	데이터(Data) 위주
접근 방법	하향식(Top Down)  분할정복(Divide and Conquer)	상향식(Bottom Up)  상호 관계 정의
산출물 구조	트리(Tree) 구조	그래프나 네트워크 구조
장점	- 처음부터 원하는 목적을 수행할 기능을 위주로 생각하므로 해결책을 구하기가 쉽다.  - 개발 기간이 짧아질 수 있다. 특히 요구사항을 잘 알고 있는 상태에서 시급히 개발이 필요할 경우 적합하다.	- 개발된 해결책의 유지보수 및 재사용이 편리하다.  - 요구 사항의 변화에 쉽게 대처할 수 있다.  - 분석과 설계 단게에서 사용되는 모델이 동일하므로, 분석에서 설계로 전이가 편리하다.  - 기존의 프로그램이나 상용 패키지를 상속하여 재사용하는 것이 쉽다.  - 설계를 강요한다.
단점	- 요구 사항 변화에 취약하며, 이로 인해 유지, 보수, 관리가 힘들다.  - 분석 결과로부터 설계로의 전이 과정이 매끄럽지 못하다.  - 알고리즘이나 기능을 중심으로 한 접근 방법이기 때문에 잦은 변경이 불가피하고, 한 부분의 변경에 의해 영향 받는 범위를 구분짓기 힘든다.	- 대형 시스템의 경우, 상속 구조나 객체간의 상호 작용이 너무 복잡해질 수 있으며, 다루어야 할 객체도 너무 많아질 수 있다.  - 서브시스템의 정의 방법이 아직 제대로 정립되지 않았다.  - 아직까지 시스템 전반적인 기능이나 행위 분석 방법이 제안된 것이 거의 없고, 적절한 객체를 정의하는 것도 힘들다.
실세계와 개념적 대응 용이성	기능 위주이므로 실세계와 개념적 대응이 힘들다.	객체를 통한 실세계와의 개념적 대응이 비교적 쉽다.
주요 응용 분야	계산이나 복잡한 알고리즘 중심의 응용 분야  ( 과학기술, 실시간 시스템 등 )	커뮤니케이션이 많은 분야 또는 시뮬레이션, 비즈니스 응용 분야

- 구조적 접근 방식은 트리 형태로 해결책이 만들어지므로, 특정 서브 트리를 서브시스템으로 정의할 수있지만, 객체지향 접근 방식의 경우에는 네트워크 형태로 해결책이 만들어지므로, 서브시스템을 구분짓기가 어렵다.

- 객체지향적 접근 방식이 구조적 접근 방식보다 유지, 보수가 쉽다. 그 이유는 객체지향 접근 방식의 경우 객체를 기준으로 수정해야 할 범위가 명백히 구분될 수 있고, 주로 수정이 일어나는 부분이 객체 내부로 한정되는데 반해 구조적 접근 방식은 하나의 기능을 수정하였을 경우, 그에 따라 영향을 받는 범위가 불명확하여 일일이 확인을 해야 하기 때문이다.

- 객체지향 접근 방식이 구조적 접근방식보다 재사용이 수월한 원인은 첫번째로 객체지향 접근 방식이 잘 변화하지 않는 데이터를 기준으로 객체를 정의했기 때문에 객체를 단위로 재사용이 이루어질 수 있기 때문이고, 다른 하나는 클래스 상속을 통해 기존 클래스를 재사용하여 확장하면서도 이전 프로그램을 수정할 필요가 없기 때문이다.