설계2 (소프트웨어 공학)

소프트웨어 공학에서 구조적 설계는 소프트웨어 시스템을 개발할 때 전체 시스템의 구조와 구성 요소 간의 상호작용을 계획하고 설계하는 단계이다. 이는 소프트웨어 개발 프로세스의 중요한 부분으로 시스템의 복잡성을 다루며 유지보수할 수 있고 확장할 수 있는 소프트웨어 시스템을 만들기 위한 첫 번째 큰 단계 중 하나다. 이러한 구조적 설계는 앞서와 같이 모듈화와 추상화, 모듈 간 인터페이스 설계, 데이터 구조 설계, 제어구조 설계, 자료구조 설계 및 모듈의 응집도와 결합도 등으로 구성되어 있다. 특히 구조적 프로그래밍을 통해 GOTO 문을 최소화하고 대신 조건문과 반복문 등을 사용하여 프로그램 흐름을 명확하게 구조화한다. 이는 코드의 가독성과 디버깅 효율을 높이는 좋은 방법이다. 또한 일반적인 소프트웨어 설계 문제에 대한 해결책으로 사용되는 디자인 패턴을 활용하여 설계의 일관성과 재사용성을 향상한다.

구조적 설계는 소프트웨어의 크기와 복잡성을 관리하고 효율적인 개발 및 유지보수를 가능하게 해주는 중요 단계다. 이를 통해 개발자는 요구사항을 충족하면서도 확장 가능하고 품질 좋은 소프트웨어 시스템을 개발할 수 있다.

 




구조적 설계

구조적 분석은 설계 결과를 구조도로 나타낸다. 구조도는 시스템의 모든 모듈을 사각형의 박스로 표현하며 모듈의 호출 관계를 화살표로 나타내는 계층적 트리 형식의 표이다. 결국 소프트웨어 구조도는 시스템을 어떤 모듈들로 나누었는가를 명시적으로 나타내며 모듈들의 계층구조와 모듈 간 입출력, 인터페이스, 기능을 나타내는 이름들을 보여준다. 이러한 시스템 구조는 전체적으로 치우침 없는 균형을 이뤄야 한다. 그렇지 못한 경우 처리에 병목현상이 발생한다. 균형은 구조도의 폭과 깊이, 입출력 또는 처리 편중, 영향 범위 등에 의해서 결정된다. 시스템 구조도가 불균형인 경우 모듈의 역할이나 규모를 다시 나누어 균형을 이루도록 해야 한다.

구조의 깊이는 시스템 구조도의 레벨 수다. 깊이는 모듈 사이에서 호출하고 반환하는 과정이 길게 이어진다는 뜻이다. 따라서 깊이가 깊어지면 최하위 모듈까지 통신에 대한 부하가 늘어난다. 또한 구조의 넓이는 상위 모듈이 호출하는 모듈의 개수이다. 이를 보통 Fan-out이라 하며 한 모듈에서 호출하는 하위 모듈이 너무 많으면 호출하는 모듈이 제어할 때 병목 현상이 생길 수 있다. 제어의 범위를 너무 크지 않게 하는 것이 운용의 묘를 살리는 것이며 이 또한 매직넘버 7 내외를 유지하는 것이 좋고 이것이 Fan-out 수다. 여기서 호출하는 모듈수를 줄이려면 중간층의 모듈을 몇 개 두어 중간 모듈이 하위 모듈을 호출하도록 한다. 또한 하위 모듈 중 그룹화할 수 있는 모듈이 있거나 다른 모듈 등이 있다면 이를 분리한다.

구조적 설계는 분석 단계에서 생성된 자료 흐름도를 활용하여 소프트웨어 구조를 추출한다. 이에 두 가지 방법으로서 변환분석과 처리분석으로 구조를 추출한다. 

  • 변환분석(Transformation Analysis): 소프트웨어 시스템 내 데이터 변환과 이동을 분석하는 과정으로 시스템 모듈 간 어떻게 데이터가 전달되고 가공되는지를 파악하여 시스템의 데이터 흐름을 이해한다. 이를 통해 시스템의 기능과 동작을 정확하게 파악하고 데이터 변환 과정에서 발생할 수 있는 오류나 문제를 사전에 예측하고 방지할 수 있다. 
    • 데이터 흐름 다이어그램(DFD) 작성: 시스템 내의 데이터 흐름을 그래픽으로 표현하는 도구인 데이터 흐름 다이어그램을 작성한다. 다이어그램은 프로세스, 데이터 저장소, 데이터 흐름 등을 나타내어 시스템의 데이터 흐름을 시각화한다.
    • 프로세스 식별과 정의: 시스템 내의 각각의 프로세스(기능 또는 서비스)를 식별하고, 그들이 어떤 데이터를 입력으로 받고 어떤 데이터를 출력으로 생성하는지를 정의합니다.
    • 데이터 변환 및 가공 분석: 각 프로세스 내에서 데이터가 어떻게 변환되고 가공되는지를 분석합니다. 데이터의 가공 단계에서 발생할 수 있는 오류나 일관성 문제를 식별하고 이에 대한 대비책을 마련합니다.
    • 데이터 저장소 식별과 정의: 데이터 흐름 중간에 위치하는 데이터 저장소(파일, 데이터베이스 등)를 식별하고, 이들이 어떤 데이터를 저장하고 어떤 프로세스에 의해 엑세스되는지를 정의합니다.
  • 처리분석(Transaction Analysis): 소프트웨어 시스템 내에서 발생하는 트랜잭션을 분석하는 과정으로 시스템 사용자와 시스템 간의 상호작용을 이해하고 각각의 트랜잭션이 어떤 데이터와 기능을 요구하며 어떤 결과를 반환하는지를 파악한다. 이로써 시스템의 기능 요구사항을 정확히 파악하고 시스템의 응답 시간과 성능을 평가할 수 있다.
    • 트랜잭션 식별과 정의: 시스템 사용자의 작업 또는 요청을 트랜잭션으로 식별하고 각 트랜잭션이 어떤 데이터와 기능을 요구하는지 정의
    • 트랜잭션의 처리 흐름 분석: 각 트랜잭션이 어떤 프로세스나 모듈을 통해 처리되는지를 분석하며 트랜잭션의 처리 흐름을 파악하여 성능 병목 현상이나 오류 발생 가능성을 예측하고 대비책을 마련
    • 트랜잭션의 성능 분석: 각 트랜잭션의 응답 시간, 처리량 등의 성능을 분석하여 사용자 요구사항을 충족시킬 수 있는지 평가

 




소프트웨어 구조

흔히 스타일이라고 하면 설계와 시공을 위한 큰 밑그림을 그리는데 여기서 일관된 모양과 조화를 뜻한다. 이 스타일을 소프트웨어 구조에서도 사용할 수 있다. 소프트웨어 시스템이 복잡해지면서 시스템의 구조 문제는 더욱 중요해졌는데 왜냐면 일단 개발이 시작되면 이후 잘못된 부분을 바로잡기가 쉬지 않기 때문이다. 이런 문제의 중요성을 인식하여 소프트웨어 구조 개념이 나타났다. 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류처리 방침, 서브 시스템 간 통신 프로토콜을 포함한다. 이에 몇 가지 주요 스타일이 무엇이 있는지 살펴볼 필요가 있다.

  • 저장소 (Repository) 구조: 소스 코드, 문서, 데이터 등의 자원을 중앙 집중화하여 관리하는 구조로 팀원들은 동시에 작업하거나 버전을 관리하며 변경 사항을 추적할 수 있다. 버전 관리 시스템(VCS)인 Git과 같은 도구가 이 구조의 핵심 역할을 수행하며 이를 통해 협업과 코드 품질을 개선하며 변경 내역을 추적하여 문제를 해결하는 데 도움을 준다.
  • MVC (Model-View-Controller) 구조: 소프트웨어를 세 가지 주요 컴포넌트로 분리하여 구조화하는 패턴으로 코드의 재사용성, 유지보수성 및 확장성을 향상하며 시스템의 구성 요소 간의 결합 도를 낮추는 데 도움을 준다. 
    • Model: 데이터와 비즈니스 로직을 관리한다. 데이터의 상태와 조작 방법을 정의하고 시스템의 핵심 기능을 담당한다.
    • View: 데이터를 시각적으로 표현하는 역할을 한다. 데이터를 사용자에게 표시하거나 입력을 받을 수 있는 인터페이스를 제공한다.
    • Controller: 사용자의 입력을 처리하고 Model과 View 사이의 상호 작용을 조정한다. 사용자 요청을 해석하고 적절한 Model 업데이트 및 View 업데이트를 수행한다.
  • Client/Server 구조: 소프트웨어 시스템을 두 부분으로 분할하는 구조로 클라이언트는 사용자 인터페이스와 관련된 작업을 수행하고 서버는 데이터 처리 및 비즈니스 로직과 같은 작업을 수행한다. 클라이언트는 서버에 요청을 보내고 서버는 해당 요청을 처리하여 결과를 반환한다. 이 구조는 분산 처리 및 확장성을 가능하게 하며 다양한 플랫폼과 기기 간의 상호작용을 지원하는 가장 기초적인 구조이다.
  • 계층 (Layered) 구조: 시스템을 여러 계층으로 나누어 각 계층이 특정 기능을 수행하도록 하는 구조로 각 계층은 자신 바로 아래 계층과 상호작용하며 상위 계층은 하위 계층을 직접적으로 몰라도 된다. 이 구조는 코드의 모듈화와 재사용을 촉진하며 시스템의 유지보수 및 확장성을 개선하는 데 도움을 준다.
  • 파이프-필터 (Pipe-Filter) 구조: 데이터 처리를 여러 단계로 나누어 각 단계를 필터로 생각하고 각 단계 간 데이터를 파이프로 연결하여 처리하는 구조로 각 필터는 특정 작업을 수행하며 데이터를 받아 처리한 후 결과를 다음 필터로 전달한다. 이 구조는 시스템의 기능을 모듈화하고 데이터 처리를 효율적으로 관리하는 데 도움을 준다.