소프트웨어 설계 기법

Preface

 

이번 장은 프로그래밍 언어와 연관지어 이해해야 하는 개념이 생각보다 많았다.

운영체제와 자료구조, 프로그래밍 언어 등을 병행하지 않고 오로지 소프트웨어 공학만 공부하는 나에게 있어 관련 지식을 필요로 하는 개념들은 이해하기 쉽지 않았고 큰 스트레스로 다가왔다.

 

개발 지식을 독학하며 한 가지 느낀 점은 대학교에서 각 학기마다 전공 필수 교과목을 지정하여 수강하게 하는 이유가 있다는 것이다. 그렇기에 현재 상황에서 내가 내린 최선의 결론은 유튜브를 통해 프로그래밍 언어 공부를 병행하는 것이다.

 

소프트웨어 공학과 운영체제, 자료구조 공부를 마친 후 본격적으로 프로그래밍 언어를 학습할 계획이므로 체계적으로 시작하는 것이 아닌, 기본 틀을 잡는다는 생각으로 조금씩 접하다보면 이론 공부에 분명 도움이 될 것이라고 생각한다.  

---

- 설계 단계에선 어떻게(how to)에 초점을 맞춘다.

 

- 설계 단계에선 소프트웨어의 관점, 엔지니어의 관점에서 시스템을 기술한다.

 

- 요구사항 분석 과정 : 개념적

 

- 개발 과정 : 물리적

---

1. 소프트웨어 설계 개요

 

- 시스템 설계 : 시스템을 여러 서브시스템(subsystem)으로 나누고, 서브시스템의 요소를 하드웨어 및 소프트웨어로 할당하는 것

① 설계의 첫 단계

② 시스템 전체의 구조 결정

 

- 소프트웨어 설계 : 할당된 서브시스템을 설계하는 것

 

- 엔지니어링 과정 : 가장 높은 추상화 단계(문제 기술 단계)에서 가장 낮은 추상화 단계(프로그래밍 단계)로 가는 단계적 정제(refinement) 과정

 

- 설계의 산출물 : 설계 문서

---

2. 소프트웨어 설계 활동

 

- 설계의 관리적 관점

① 기본(상위) 설계 → 기본 설계 문서

② 상세 설계 → 상세 설계 문서

 

- 설계의 기술적 관점

① 데이터 설계 : 정보 모델링의 정보를 바탕으로 자료구조와 데이터베이스를 설계 → 우선적 수행

② 구조 설계 : 모듈화된 프로그램 구조 개발, 모듈 사이의 제어 및 인터페이스 표시

③ 프러시저 설계 : 각 모듈의 내부를 구체적으로 밝히고 사용할 알고리즘 결정

④ 사용자 인터페이스 설계 → 구조 설계 이전에 수행

 

[소프트웨어 설계의 기술적 츨면과 관리적 측면]

 

- 설계 단계에서의 일반적 가이드라인

① 소프트웨어 구성 요소(모듈) 사이에 효과적 제어를 가능하게 하는 계층 구조를 가져야 함

② 모듈화(modular)되어야 함

③ 모듈들 사이 또는 외부 환경과의 인터페이스가 최소화되어야 함

④ 분석과정의 결과를 바탕으로 설계가 이루어져야 함

 

- 서브시스템 : 독립적으로 기능을 수행하거나 컴파일될 수 있는 프로그램 구성 요소

① 자료 + 제어 구조

② 연관된 모듈들의 집합

③ 시스템을 추상화하는 데 사용되는 용어

④ 객체지향 시스템에선 객체들의 모임을 의미

 

- 컴파일(compile) : 특정 언어로 작성된 시스템을 다른 언어의 동등한 시스템으로 변환하는 것

 

- 서비스 : 공통적인 목표를 제공하기 위해 필요한 기능들의 모임

 

- 모듈 = 서브루틴 = 프러시저 = 함수 : 시스템의 기본 단위

 

- 기본 설계

① 구체적인 모듈들을 최대한 정의

② 모듈을 블랙박스로 보고 입·출력만을 고려하며, 어떻게 수행되는지는 고려 X

 

- 상세 설계

① 각 서브시스템에 대한 하부 구조 정의

② 하위 모듈들과 이들 사이의 인터페이스 정의

③ 각 모듈의 실제적 내부 구조 설계 → 각 모듈의 구체적 알고리즘 완성

---

3. 설계의 고려사항

 

※ 프로그래밍 언어 학습한 이후 재검토 필요

 

- 추상화 종류

① 제어 추상화 : 제어 구조를 추상화하는 것

② 과정 추상화 : 특정 기능을 수행하는 과정을 추상화하는 것

③ 데이터 추상화 : 상세 정보(데이터 표시 구조)를 감추는 것

 

- 정보 은닉 : 필요하지 않은 정보에 접근할 수 없도록 하여, 한 모듈 또는 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계하는 것

→ 설계 전략을 지역화하는 것

① 모듈들 사이의 독립성 유지

② 소프트웨어 전체의 구조를 설계하는 전략

 

- 설계에서 은닉되어야 할 정보

① 상세한 데이터 구조

② 하드웨어 디바이스를 제어하는 부분

③ 특정 환경에 의존하는 부분

④ 물리적 코드

 

- 단계적 정제 : 하향식 설계방법에 사용되는 방식으로, 점차 추상화 수준이 낮아지며 구체화됨

 

- 모듈화 : 하향식 접근방법 사용하며, 모듈들 사이에 제어 계층이 나타남

→ 모듈의 수가 과도하게 증가하면 각 모듈의 크기는 감소하고 상호 교류가 증가하여 시스템 성능 저하 및 과부하(overload) 현상이 나타남

 

- 프로그램 구조화

① 프로세스들 사이의 관계가 계층 구조를 띄게 됨

② 제어 계층을 가진 프로그램 구조로 변화됨

③ 사각형 : 모듈

④ 모듈들 사이의 선 : 제어 관계

 

[프로그램 구조 용어]

 

[구조의 용어]

 

[구조 도표와 순서도]

 

- 모스크(mosque) 모양의 시스템이 바람직하다고 알려져 있다.

① 상위 구조의 높은 팬-아웃

② 하위 구조의 높은 팬-인

 

- 데이터 구조 : 데이터들 사이의 관계

① 시간이 지나도 잘 변하지 않음

② 시스템의 핵심 부분

 

[데이터베이스 설계 구조]

---

4. 설계의 품질 요소

 

- 모듈들이 서로 독립적이고, 내부 응집력이 높아야하며, 결합도는 최소화되어야 한다.

 

- 독립성(independence) : 각 모듈이 하나의 기능만을 수행하며 다른 모듈과의 교류와 결합을 최소화

 

- 응집도(cohesion) : 모듈 내의 구성 요소들이 서로 얼마나 관련이 있는지 등의 연관 정도 

① 시간적 응집도 : 초기화 모듈이 대표적인 예시이며, 이 외의 시간적 응집 모듈은 피하는 것이 좋음

② 순차적 응집도 : 모듈 내 한 구성 요소의 출력이 다른 구성 요소의 입력이 되는 경우

cf. 절차적 응집도는 특정 순서에 의해 수행되어야 하는 경우를 나타냄

 

[응집도 스펙트럼]

 

- 결합도(coupling) : 모듈 사이의 상호 연관성의 복잡도

① 결합도가 높으면 파문 효과(ripple effect : 하나에 문제가 생겼을 때 다른 많은 것에 영향을 끼치는 것)가 발생할 가능성이 큼

② 다른 모듈과의 상호 교류가 필요할 땐 매개변수(parameter)를 통해 정보를 교환하는 것이 좋음

cf. 전역변수(global variable) : 모든 변수 영역에서 접근할 수 있는 변수

 

- 결합도에 영향을 미치는 4가지 요소

① 모듈들 사이의 연결 유형

② 인터페이스(결합부) 복잡도

③ 정보 흐름의 유형 : 모듈 간 교류되는 정보 유형은 주로 데이터와 제어 신호임 (제어 신호를 교류할 때 결합도가 더 크다)

④ 바인딩 시간 : 모듈 사이의 연결을 묶는 때

 

[결합도 스펙트럼]

 

- 이해도 : 다른 프로그램 요소 및 정보를 참조하지 않고 이해할 수 있는 용이성

 

- 적응도 : 새로운 환경에 대응하도록 소프트웨어를 변경시킬 수 있는 용이성

 

 

 

 

 

참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.298~334.