최근들어 공부에 대한 의욕이 점점 사라지고 있다는걸 요즘 느끼고 있다.
그동안 내가 쓴 글들을 하나하나 읽어보았는데 모델링에 들어갈때까지는 되게 열정이 넘쳐서 내 경험에 빗댄 예시도 많이 들곤 했었지만, 최근 글은 전부 책에 있는 내용만 받아쓰기 한 느낌이다.
이제 곧 개강도 다가오고 여자친구도 생겨서 바쁠일이 되게 많을텐데 이제라도 다시 초심으로 돌아가 공부를 해야겠다.
소프트웨어 공학 카테고리의 거의 초반부분 글을 보면 개발의 단계는 크게 5가지로 나누어져 있는 것을 알 수 있다.
① 요구사항분석 (계획)
② 설계
③ 개발
④ 테스트
⑤ 유지 및 보수
이렇게 나누어져 있는데 지금까지는 여러가지 모델링을 통한 분석 과정을 배웠었다. 이제는 다음 단계인 '설계'이다.
앞서 설명했듯 설계와 계획은 비슷하면서도 다르다. 계획 단계에서도 완성된 작품을 정확히 인지하는것이 중요하지만, 개념적인 이해가 필요하고 설계 단계에서는 상품을 어떤 기술을 써서 어떠한 방식으로 만들겠다는 물리적인 계획이 필요하다.
먼저 설계는 관리적인 관점과 기술적인 관점으로 볼 수 있다. 관리적인 관점에서 본 설계는 두가지가 있고 기술적인 면의 설계는 4가지가 있다.
먼저 관리적인 관점에서 본 설계이다.
① 기본설계 : 상위설계 라고도 한다. 소프트웨어 시스템의 구조와 데이터를 규명하며 사용자 인터페이스를 정의한다.
- 산출물 : 기본설계문서
② 상세설계 : 각 모듈의 구체적인 알고리즘에 초점을 맞춘다. 시스템의 추상화 수준을 낮춘다.
- 산출물 : 상세설계문서
그리고 기술적인 관점에서는 4가지로 나눌 수 있다.
① 데이터설계 (기본, 상셰)
: 기본이 되는 설계로서 가장 우선적으로 이루어지는게 바람직하다. 정보 모델링에서 나타난 결과를 이용하여 자료 구조와 데이터베이스를 설계한다.
② 구조설계 (기본)
: 기능 모델링과 동적 모델링에서 나타난 결과를 이용하여 프로그램 구조상에 있는 각 모듈들 사이의 관계를 기술한다. 목적은 모듈화된 프로그램 구조를 개발하는 것이며 모듈 사이의 제어 및 인터페이스를 나타낸다.
③ 프러시저 설계 (상세)
: 각 모듈의 내부를 밝히고 어떤 알고리즘을 사용할지 결정한다. 데이터와 프로그램 구조가 설정된 후 이루어진다.
④ 사용자 인터페이스 설계 (기본, 상세)
: ② 구조 설계 이전에 하는것이 바람직하다. 사용자가 시스템의 기능에 접근하기 위한 인터페이스를 설계하는 것이다.
설계에서 요구되는 일반적인 가이드라인
- 모듈사이에 효과적인 제어를 가능하게 하는 계층구조를 가져야함
- 설계는 논리적으로 분할되어 모듈화되어야함.
- 모듈들 사이의 인터페이스가 최소화되어야함. 모듈 내부의 응집도는 높아야하고 모듈들 사이의 결합도와 인터페이스는 최소화되어야함
- 분석과정에서 나타난 결과를 활용해야함. 설계는 분석과정의 연장선으로 보아야하며 분석과정에서 얻은 뼈대에 살을 붙혀나가는 과정
설계의 관리적 관점
- 설계 단계에서의 가장 주요 산출물 = 설계문서
- 기본설계와 상세설계로 분할하기도 함
기본설계
- 데이터에 대한 설계
- 시스템에 필요한 정보를 자료구조와 데이터베이스 설계에 반영함
- 사용자 인터페이스 설계를 하는게 바람직함
- 시스템의 구조를 설정해야함 (구조설계 이전에 인터페이스 먼저)
- 모듈을 블랙박스로 보고 모듈의 입력과 출력을 고려하고 어떻게 수행되는지는 고려하지않음
상세설계
- 서브시스템에 대한 하부구조가 정의
- 하부 모듈들과 이들사이의 인터페이스가 정의
- 각 모듈의 실제적인 내부 구조가 설계되며 각 모듈에 대한 구체적인 알고리즘이 완성됨
*모듈 : 시스템의 기본단위로 실행코드, 자료구조 및 다른 모듈들과의 인터페이스로 구성
*서브 시스템 : 객체들의 모임
추상화
※ 재검토 필요
- 제어 추상화
: 제어구조를 추상화
- 과정 추상화
: 어떤 기능을 수행하는 과정을 추상화
- 데이터 추상화
: 상세정보를 감추는 것
정보은닉
: 필요하지 않은 정보를 은닉하여 한 모듈 또는 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계하는것
- 모듈사이의 독립성을 유지
은닉되어야 할 기본 정보
- 상세한 데이터구조
- 하드웨어 디바이스를 제어하는 부분
- 특정한 환경에 의존하는 부분
- 물리적 코드 ex) ip주소
단계적 정제
하향식 설계방법에 주로 사용된다. 프로그램의 구조에서 점점 모듈의 세부사항으로 내려가며 구체화한다.
구체화함으로서 추상화 수준은 낮아지며 각 기능이 분해되어 해결방안을 제시한다.
모듈화
모듈이란 시스템의 구성요소 예를 들자면 c언어의 printf조차 하나의 함수로서 모듈이 될 수 있다.
시스템을 모듈화할 때는 하향식 접근방식을 사용하여 기능 단위로 쪼개어 나간다.
이 경우에는 모듈 사이의 제어계층이 나타나게 된다.
프로그램 구조화
말 그대로 구조화 하는 것이다.
프로세스사이의 관계가 계층 구조의 모습을 띠게되며 제어 계층을 가진 프로그램 구조로 변환된다.
이때 트리(tree)와 유사한 그림으로 표시되는데 사각형은 모듈/ 선은 제어 관계를 나타낸다.
프로그램 구조를 측정하고 나타내는데 사용하는 용어는 그림과 같다
설계의 품질요소
품질이 향상되려면 설계를 잘 해야한다고는 수없이 말해왔었다. 그러면 어떻게 하면 설계의 품질이 올라갈까
좋은 설계란 정의하기가 매우 어렵다. 사람마다 특징이 전부 다른것처럼 누구에게는 이 설계도가 좋을 수도 있고 누구에게는 다른 설계도가 좋을 수있는것처럼 매우 주관적이다.
하지만 가장 이상적인 설계는 각 모듈의 응집도가 높아야하고 다른 모듈과 결합성이 떨어져야한다. 되게 익숙한 말 일수도 있는데 그동안 배웠던 객체지향과 같다.
독립성
- 각 모듈이 하나의 기능을 가진다.
- 다른 모듈과의 상호교류와 결합을 최소화 시킬때 독립성은 극대화된다.
응집도
- 모듈내부가 얼마나 단단히 뭉쳐져있는가
- 우연적 응집도 : 결합도가 매우낮음 그냥 코드 20줄씩 잘라 붙히면 우연적 응집도가 될 정도
- 논리적 응집도 : 무언가 결합은 되어있음. 하지만 서로 다른 기능을 가진 부분이 많음 ex) 입출력
- 시간적 응집도 : 서로 다른 기능을 같은 시간대에 함께 실행하는 경우. 초기화모듈에서 많이 보임
- 절차적 응집도 : 모듈 내 구성요소들이 연관성이 있음 특정 순서에 의해 수행되어야함
- 대화적 응집도 : 모듈 내 구성요소가 같은 입력자료를 이용하거나 동일한 출력데이터를 만들어냄
- 순차적 응집도 : 한 구성요소의 출력이 다른 구서요소의 입력이 되는 경우
- 함수적 응집도 : 한 기능을 수행하기 위해 모듈내 각 구성요소가 필요한 경우
결합도
- 결합도가 높으면 한 모듈에 문제가 생겼을 때 다른 부분까지 피해가 갈 수 있음.
- 다른 모듈과 연관을 두고싶다면 매개변수를 활용하는게 바람직함
결합도에 영향을 미치는 4가지 요인
- 모듈들 사이의 연결유형 : 한 모듈안에 있는 요소가 다른 모듈에 의해 참조될 때
- 인터페이스의 복잡도 : 인터페이스는 모듈들의 연결을 위해 꼭 필요한 정보만을 표시하여 복잡도가 최소화되어야함
- 정보 흐름의 유형 : 모듈 사이의 교류되는 정보는 데이터와 제어 신호로 나뉜다. 데이터의 결합도가 더 약하다. 데이터 < 제어신호
- 바인딩 시간 : 모듈 사이의 연결을 묶는 때를 말함 ex) 로딩,컴파일할때
* 인터페이스 : 사용자가 무엇을 행할 때 사용자의 입출력을 받아주는 창구역할 ex) 모니터
이해도
- 다른 프로그램 요소나 정보를 참조하지 않고 이해할 수 있는 정도
- 시스템의 응집도가 높을 수록 이해도 ↑
적응도
- 소프트웨어를 변경시킬 수 있는 용이성
- 유지보수를 용이하게 하기 위해 필요
- 새로운 환경에 쉽게 적응하는가
이번 단원의 가장 핵심 내용은 설계를 할 때 여러 모듈들이 각자의 응집도는 서로 높아야 한다는 것과 결합성은 낮아야 한다는 것이다.
응집도가 높으면 프로그램의 안정성이 높아진다. 프로그램의 속도가 빨라지거나 호출에 용이하다.
결합성이 낮으면 만약 하나의 모듈에 문제가 생겼을 경우 다른 모듈들이 피해를 입지 않을 수 있고, 그 모듈만 수정하면 된다는 이점이 있다.
끝~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'개발 > 소프트웨어 공학' 카테고리의 다른 글
| 디자인 패턴 (0) | 2022.01.23 |
|---|---|
| 자료 흐름 중심 설계와 데이터베이스 설계 (0) | 2022.01.21 |
| 유스케이스와 UML (0) | 2022.01.19 |
| 객체지향 분석 기법 (0) | 2022.01.17 |
| 정보 모델링 (0) | 2022.01.12 |
댓글