CH11. 소프트웨어 아키텍처 분석 및 설계 개요(구조적 방법론)

김유찬·2023년 6월 13일

소프트웨어 공학

목록 보기

10/12

■ 구조적 방법론 소개 및 적용 사례

■ 구조적 방법론 소개

top-down 기반
데이터를 우선 순위로 쪼갬

■ 구조적 분석 모델의 구조

데이터 분석
기능 분석
제어 분석
semi-formal

■ 데이터 분석 및 모델링

시스템에서 사용하는 데이터의 종류와 타입 등을 기록
시스템이 처리해야 할 데이터 확인

■ 데이터 흐름 분석 및 모델링(DFD)

데이터가 시스템을 이동하면서 어떻게 변환 되는지를 확인하기 위해 사용
데이터를 변환하는 함수를 구분하기 위해 사용
이제 더 이상 쪼갤 필요가 없을 때 PSPEC과 같이 알고리즘을 작성

■ 제어 흐름 분석(CFD)

이벤트의 시스템에서 어떻게 이동하는지를 확인하지 위해 사용
데이터 흐름 다이어그램과 같은 프로세스 사용
함수들을 어떻게 호출할 지

■ 데이터 흐름 다이어그램(DFD)

프로세스: 대부분 원이나 둥근 사각형, 프로세스의 이름을 내부에 기재, 함수라고 이해하면 됨
데이터 흐름: 두 프로세스 사이의 데이터 경로는 화살표로 표시, 화살표 위에 데이터 이름 기재
데이터 저장소: 한쪽이 열린 사각형, 혹은 한 쌍의 평행선, 저장소의 이름을 안에 기재
데이터 출처와 도착지: 직사각형, 내부에 이름 기재

공급자, 배급자: 데이터 출처, 도착지, 엘리먼트
식빵 공장: 프로세스
식빵 공장에 대한 1, 2차 구체화
식빵 공장 프로세스는 식빵 만들기, 식빵 포장, 빵을 배달과 같은 3가지의 하위 프로세스로 쪼개짐
식빵 만들기 프로세스는 옥수수 씻고 고르기, 반죽을 만듦, 버터와 버무림, 식빵을 구워냄 등의 4가지 하위 프로세스로 쪼개짐

■ DFD 특징

배경도: 대상 시스템 전체를 프로세스로 두고 외부의 데이터 입출력 관계를 표현한 DFD
원시 프로세스: 프로세스 중 더 이상 분할되지 않는 프로세스, 이후 미니 명세서 기술
미니 명세서: 원시 프로세스에 대한 상세한 설명을 기록하며 프로세스 명세서로 불림, Activity Diagram, 순서도, N-S차트 등을 사용

■ DFD 작성 원칙
● 추상화와 단계적 분해

같은 계층의 문제는 같은 수준의 상세함을 가져야 함
각 문제는 독립적인 문제로 분리되어야 함
부분 문제들의 해가 모여서 원래 문제를 해결할 수 있어야 함

● 명명 원칙

프로세스의 이름은 동사형 명사와 단일 직접 목적어를 사용하여 간결하게 함
어떤 경우에도 다 적용될 수 있는 포괄적인 명칭은 피함

● 변환된 데이터 흐름의 명칭

데이터 흐름은 프로세스를 거쳐 변환될 때마다 새로운 이름 부여

●데이터 흐름의 균형

프로세스를 중심으로 입력과 출력 데이터의 흐름은 어디서나 일치되어야 함

● 데이터 흐름의 분할 및 통합

데이터 흐름은 (구체화 정도에 따라) 분할 또는 통합이 가능

● 프로세스와 데이터 저장소 간의 데이터 흐름

프로세스 -> 데이터 저장소(자료 수정, 삽입, 삭제)
프로세스 <- 데이터 저장소(자료 검색)

● 블랙홀과 화이트홀은 없어야 함

블랙홀: 데이터의 입력만 있는 데이터 저장소
화이트홀: 데이터의 출력만 있는 데이터 저장소

● 단계적으로 나누어서 프로세스 표시

한 장의 분석서에 한 계층의 데이터 흐름도만 그림
한 장에 5 ~ 9 정도가 적당함

■ DFD 작성 개선

데이터 흐름이 하나만 나와서 다음 프로세스의 입력이 되는 프로세스는 과다하게 분할된 가능성이 높음으로 통합 가능성 높음
여러 프로세스가 동일한 외부 개체와 상호작용하고 프로세스 하나는 상호작용이 없는 경우 -> 데이터 흐름과 변환 과정 검토
여러 프로세스가 동일한 데이터 저장소에 접근하는 경우 -> 저장소에서 읽는 데이터 흐름을 비교하여 반복이 있으면 통합
여러 프로세스가 동일 저장소에 여러 번 데이터를 저장하는 경우 -> 같은 데이터를 쓰는지 검사하고 필요하면 재구성 및 통합
단순하고 과다하게 세분화된 프로세스의 경우 -. 이웃 프로세스와 통합

■ 데이터 사전

+: 자료요소가 아른 요소와 연결
|: or
'': 문자형 상수
[]: 선택형
{}: 안의 요소가 반복되는 것
{}x: x번 이상 반복
{}y: 많아야 y번 반복
x{}y: x번 이상, y번 이하
(): 선택적 = 0{}1

■ 미니 명세서
● 구조적 영어

영어에서 사용하는 단어 중에서 단어들을 제한적으로 도입하여 기술하는 방법
사실상 슈도코드

● 의사결정표 / 트리

● N-S 차트

● 전후 조건

■ DFD와 DD - context diagram

■ DFD와 DD - mini-spec - level 0

■ 상태전이 다이어그램

프로세스, 객체 등이 존재할 수 있는 상태의 전이 관계를 표현
객체와 전이 관계로 표현
전이 관계는 조건이 추가될 수 있음
FSM(sinite state machine)을 표현

● FSM

유한 상태 머신
-유한한 개수의 상태들로 구성된 하나의 간단한 기계
-하나의 입력을 받고 그에 따라 현태 상태로부터 다른 어떠한 상태로 전이하는 기계

● 밀리 기계

출력이 상태의 추이함수에 의해 결정

● 무어 기계

출력이 상태에 의해 결정

■ 설계의 이해

정의
-개발될 제품에 대한 의미 있는 공학적 표현
-고객의 요구사항으로 추적 가능해야 하며, 동시에 좋은 설계라는 범주에 들도록 품질에 대해서도 검증되어야 함 [IEEE-Std-610]
소프트웨어의 설계
-모듈 설게, 상세 설계라고 함
-시스템 각 구성 요소들의 내부 구조, 동적 행위 등을 결정
-구조적 설계 방법, 객체지향적 설계 방법
상위 설계
-구조 설계, DB 설계, 인터페이스 설계
하위 설계
-컴포넌트 설계, 자료구조 설계, 알고리즘 설계
구조적 설계
-시스템을 기능과 데이터 관점에서 다룸
-Top-Down 세분화
-업의 처리절차를 중심으로 설계의 구성 요소들을 구분
객체지향적 설계
-자료와 자료에 적용될 기능을 함께 추상화
-객체: 자료 + 기능
-시스템의 실제 객체 요소를 중심으로 설계
-Bottom-Up

■ 설계 원리
● 추상화

자세한 구현 전에 상위 레벨에서의 제품의 구현을 먼저 생각
복잡한 문제를 일반화하여, 쉽게 이해할 수 있도록 하는 원리
과정 추상화: 수행 과정의 자세한 단계를 고려하지 않고, 상위 수준에서 수행 흐름만 먼저 설계
데이터 추상화: 데이터 구조를 대표할 수 있는 표현으로 대체(날짜 구조 -> "날짜")
제어 추상화: 외부 이벤트에 대한 반응을 추상화(~입력되면 ~을 처리하고 ~를 수행한다)

● 단계적 분해

문제를 상위 개념부터 더 구체적인 단계로 분할하는 Top-Down원리
모듈에 대한 구체적 설계 시 사용
문제를 하위 수준의 독립된 단위로 나눔
점진적으로 구체화 작업을 계속 함

● 모듈화

모듈: 수행 가능 명령어, 자료구조 또는 다른 모듈을 포함하고 있는 독립 단위
독립적으로 컴파일, 다른 모듈을 사용할 수 있음, 다른 프로그램에서 사용할 수 있음

■ 효과적인 모듈화

모듈의 이식성: 특정 환경에서만 동작하는 것이 아니라 일반적인 환경에서 동작할 수 있을수록 이식성이 높음
모듈화의 목표: 모듈 내 응집력은 강하게, 모듈간 결합력은 약하게
● 모듈의 응집력: 하나의 모듈은 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계
정도: 기능적 > 교환적 > 절차적 > 시간적 > 논리적 > 우연적

● 응집력의 종류

기능적 응집: 모듈이 잘 정의된 하나의 기능만을 수행할 때 기능적 응집도가 높음(ex) 판매 세금 계산 모듈)
교환적 응집: 동일한 입/출력을 사용하는 작은 작업들이 모인 모듈에서 식별(ex) 인사 기록 파일에 근무 성적을 기재하고, 급여를 갱신하는 모듈)
절차적 응집: 모듈 안의 작업들이 큰 테두리 안에서 같은 작업에 속하고, 입출력을 공유하지 않지만 순서에 따라 수행될 필요가 있는 경우(ex) 총계를 출력하고, 화면을 지우고, 메뉴를 보이고, 메뉴 선택 코드를 받는 모듈)
시간적 응집: 프로그램의 포기화 모듈 같이 한 번만 수행되는 요소들이 포함된 경우(ex) 초기화 루틴이 포함된 모듈)
논리적 응집: 비슷한 성격을 갖거나 특정 형태로 분류되는 처리 요소(ex) 사칙 연산에서 주어진 매개 변수에 따라 다른 계산을 수행하는 모듈)
우연적 응집: 아무 관련 없는 처리 요소들로 모듈이 형성되는 경우

● 모듈의 결합도

모듈 간의 상호 의존도 정보를 의미
모듈은 하나의 블랙박스로 다른 모듈과의 독립성이 높아야 함
독립적인 모듈이 되기 위해서는 다른 모듈과의 결합도가 약해야 함
정도: 내용 > 공통 > 제어 > 구조 > 자료 / 정도가 약할수록 좋은 것임

● 결합도의 종류

자료 결합: 모듈 간의 인터페이스가 자료(파라미터) 전달을 위해서만 구성된 경우(ex) add(3,5))
구조 결합: 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달되는 경우(ex) print_salary(인사 기록 레코드))
제어 결합: 한 모듈이 다른 모듈에게 제어요소(function code 등)를 전달하는 경우(ex) integet_operation('+',3,5))
공통 결합: 여러 모듈이 공동 자료 영역을 사용하는 경우(ex) 전역 변수 사용, Shard memory 등)
내용 결합: 한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정하는 경우(ex) 한 모듈에서 다른 모듈로 분기가 발생하는 경우)