[Design Pattern] 소프트웨어 설계

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

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

이해 용이성 (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 디자인 패턴! 이렇게 활용한다] 책의 내용들을 순서대로 정리해 보았다. 하지만 이후로는 책의 순서를 따르지 않고 내가 필요한 것 위주로 디자인 패턴을 하나씩 포스팅 하고자 한다.