소프트웨어 공학 Lecture #5: 설계 원리와 아키텍처 Eun Man Choi emchoi@dgu.ac.kr 1

학습 목표 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

설계(Design) 작업 찾은 요구를 어떻게 구현할 것인가를 고민하는 단계 아키텍처 설계 모듈 설계 UI 설계 데이터 설계 소프트웨어 내부 구조 설계 - 아키텍처는 상위 수준의 설계이며 시스템의 컴포넌트와 이들의 커넥션에 초점 모듈 설계 모듈 안의 알고리즘, 자료구조 설계 UI 설계 데이터 설계 모듈, 애플리케이션이 공유하는 자료 설계

5.1 분석에서 설계로 요구 분석서 - 시스템이 해결하려는 문제에 대하여 기술한 것 설계 - 분석서에 기술된 문제를 해결 방안으로 바꾸는 작업

설계 작업 설계 작업은 정의된 문제에 대하여 설계 원리를 적용하여 주어진 여러 제약 조건을 잘 만족시키는 최선의 설계안을 선택하는 작업

좋은 설계는? 설계를 움직이는 힘은 복잡성 콘트롤 모든 소프트웨어 설계 기술의 목표는 복잡한 문제를 단순한 조각으로 자르는 것 성능을 높이는 열쇠는 복잡한 예외처리가 아니라 간결함 7가지 바람직한 설계 목표(Steve Connell) 복잡성 최소 느슨한 결합(Loose coupling) 강한 응집력(Strong cohesion) 확장성 재사용성 유지보수성 유연성

5.2 설계 원리 설계 원리란? 좋은 설계가 되게 하는 작업의 규범 경험에 의하여 터득한 원리(rule of thumb) 검토 평가 할 수 있는 기준

문제의 분할 분할과 정복(divide and conquer) 문제를 다루기 쉽고 풀 수 있는 작은 조각으로 나누는 것 큰 문제는 복잡하고 인간의 한계로 다루기 어려움 문제를 다루기 쉽고 풀 수 있는 작은 조각으로 나누는 것 단계적 분해(stepwise refinement) 문제를 기본 단위로 나눈다. 독립된 문제로 구별한다. 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룬다. 구체화 작업이 계속 점증적으로 일어난다는 것을 보인다.

추상화 복잡한 문제 ⇒ 추상화 ⇒ 개념 (현실) 소프트웨어의 구조를 이루는 계층의 파악 기능 추상화 자료 추상화 제어 추상화 복잡한 문제 ⇒ 추상화 ⇒ 개념 (현실) 소프트웨어의 구조를 이루는 계층의 파악 기능 추상화 입력자료를 출력자료로 변환하는 과정을 추상화 부프로그램의 시그네처와 기능만 생각 자료 추상화 자료와 기능을 묶어서 생각 제어 추상화 외부 이벤트에 대한 반응을 추상화

모듈화 시스템의 분해를 어떻게 할 것인가? 한 모듈의 규모 이식성 모듈의 응집력(cohesion)이 높게 1 4 1 2 3 2 1 5 4 4 5 6 3 6 2 3 5 6 문제영역 시스템 분해 시스템 구조 시스템의 분해를 어떻게 할 것인가? 한 모듈의 규모 이식성 모듈의 응집력(cohesion)이 높게 모듈 간의 결합력(coupling)은 약하게

모듈 응집력 모듈 안의 구성 요소들이 공동의 목적을 달성하기 위하여 관련되어 있는 정도 목 표 응집력의 단계 한 모듈이 단일 기능을 갖도록 설계 <예> finishup : 최종 보고서를 출력하고, 계산 결과를 디스크에 저장 응집력의 단계 ① 기능적(functional) 모듈의 기능이 한 문장으로 떨어짐 <예> 판매세금 계산 ② 순차적(sequential) 작업의 결과가 다른 작업에 입력 <예> 거래를 읽고 마스터 화일을 변경

모듈 응집력(계속) ③ 교환적(communicational) <예> 출력화일을 출력하고 저장 동일한 입력과 출력을 사용하는 작업의 모임 <예> 출력화일을 출력하고 저장 ④ 절차적(procedural) 같은 범주에 속하는 일들이 순서적으로 수행 <예> restart-RTN : 총계를 출력하고, 화면을 지우고 메뉴를 뿌리고, 메뉴 선택을 받음 ⑤ 시간적(temporal) 프로그램 초기화 ⑥ 논리적(logical) 유사한 성격의 작업을 한 모듈로 모음 ⑦ 우연적(coincidential) 아무 관련 없는 작업을 한 모듈에 모음

모듈 결합도 모듈 간의 관련 정도 설계 목표 결합의 단계 모듈 간의 결합도가 낮게 설계 ① 자료 결합(data coupling) 모듈들이 간단한 변수를 파라메터로 교환 ② 스탬프 결합(stamp coupling) 모듈 사이에 nonglobal 자료 구조를 교환 ③ 제어 결합(control coupling) 제어용 신호(flag)를 주고 받음 ④ 공통 결합도(common coupling) global variable을 사용 ⑤ 내용 결합(content coupling) 한 모듈이 다른 모듈 내의 값을 수정

5.3 구조적 설계 시스템을 이루는 모듈의 구조를 파악하는 방법 모듈 분해의 계층적, 인터페이스 지향적 접근 W. Stevens, G. Myers와 L. Constantine 데이타의 흐름 형식에 중점 source-transform-sink: 변환 분석(transform analysis) transaction pattern: 처리 분석(transaction analysis Functional Decomposition Design Criterion Design Heuristics + + (cohesion, coupling)

구조적 설계(계속) 시스템 구조도(structure chart)의 도출 시스템을 모듈 단위로 분할 모듈의 계층적 구성 모듈 사이의 입출력 인터페이스 모듈의 이름과 기능 S1 S4 S5 S4 S1 S2 S3 S4 S5 S3 S1 S2 S5 Structure #1 Structure #2 Structure #3 S2 S3

시스템 구조도 표준 기호 한 모듈이 모듈을 호출 자료 흐름(변수나 자료구조) 제어 흐름(플래그) 모듈 반 복 선 택 주석달기 반 복 선 택 주석달기 comment Module

구조적 설계(계속) 예 기타 사용되는 기호 미리 정의된 모듈(라이브러리) 입출력 모듈 Main c a b A B C a f f W X Y Z 기타 사용되는 기호 미리 정의된 모듈(라이브러리) 입출력 모듈

변환 분석 자료의 변환 흐름(transformation flow) 변환 분석은 자료 흐름도를 입력흐름, 변환센터, 출력흐름으로 분할하는 과정 입력 흐름: 입력을 준비하는 단계(입력, 검증...) 출력 흐름: 출력을 위하여 준비되는 단계(포매팅, 출력) 변환 센터: 실제 자료가 변환 입력 흐름 출력 흐름 변환 센터

변환 분석 방법 ① 자료흐름도에서 입력 자료 흐름과 출력 자료 흐름을 파악 ② 중앙 변환 부분을 식별 ① 자료흐름도에서 입력 자료 흐름과 출력 자료 흐름을 파악 ② 중앙 변환 부분을 식별 ③ 변환 중심부를 축으로 최상위 구조(first-cut) 작성 ④ 각 모듈의 하위 구조도 같은 방법으로 분석 ⑤ 설계 기준을 적용하여 수정, 최적화 예: 화일 안에 포함된 단어의 개수를 계산 화일 이름 읽음 단어개수 출력 화일이름 화일 이름 검증 단어개수 편집 입력 흐름 단어개수 계산 검증된 화일이름 단어개수 출력 흐름 변환 센터

변환 분석(계속) 프로그램의 구조 시스템 구조도 main() { ... read_file(file_name, status); count_word(file_name, &word_count); display(word_count); } read_file(char* file_name, boolean status) count_word(char* file_name, boolean status) display(int word_count) 시스템 구조도 단어 계산 단어개수 검증된 화일이름 화일이름 상태 단어개수 화일이름 입력,검증 단어개수 계산 단어 개수 편집,출력

구독자 관리 시스템 ① 자료 흐름의 요소를 분해 입력 자료 흐름, 출력 자료 흐름, 변환 센터 출력 흐름 구독자 레코드 준비 만료일 추출 새 만료일 계산 구독자 레코드 변경 만료일 새 만료일 입력 흐름 변경 레코드 갱신기간 구독 갱신기간 입력 레코드를 화일에 출력 변환 센터

구독자 관리 시스템(계속) 구조도의 최상위층 작성 구조도를 상세화 구독 갱신 시스템 구독 갱신 시스템 갱신 정보 추출 구조도의 최상위층 작성 구조도를 상세화 구독 갱신 시스템 구독 갱신 시스템 갱신 정보 추출 갱신 레코드 저장 구독 갱신 갱신 정보 추출 갱신 레코드 저장 구독 갱신 새구독 기간 입력 구독 만료일 준비 구독자 레코드 변경 레코드 화일로 출력 구독 레코드 추출 구독 만료일 추출

처리 분석 처리(transaction) 방법 자료 흐름도의 한 프로세스에서 여러 개의 자료 흐름이 유출되는 것 ① 자료 흐름도에서 처리 센터를 식별 ② 처리 모듈을 중심으로 구조도 작성 ③ 구조도를 상세화 - 하위 구조도를 작성 처리흐름 T 처리 경로(action path) 처리센터

설계 평가 기준 모듈의 크기 모듈 응집력(module cohesion) 모듈 결합도(module coupling) 소규모 시스템: 함수, 서브루틴 대규모 시스템: 독립 프로그램(하나의 수행 화일) 모듈 응집력(module cohesion) 모듈 안의 요소들이 강한 응집력을 갖도록 설계 모듈 결합도(module coupling) 다른 모듈과의 결합도가 약한 모듈이 되도록 설계 설계 요령(design heuristics)

설계 요령(design heuristics) first-cut(최상위) 모듈의 결합은 줄이고 응집은 높이도록 최대한 노력 high fan-out은 줄이도록 노력 redundancy와 complexity를 줄이기 위하여 모듈의 인터페이스를 점검 ......

설계 요령(계속) 양파 모양의 구조가 일반적 모듈의 영향권을 그 모듈의 하위에 둔다 복잡한 모듈의 연결은 피함 과다한 깊이를 가진 구조도 피함 모듈의 영향권을 그 모듈의 하위에 둔다 <잘못된 예> <잘된 예> 변경된 모듈 변경된 모듈 영향받는 모듈

사례: 비디오 대여점(Level 0 변환분석)

사례: 비디오 대여점(Level 1 변환분석)

사례: 비디오 대여점(시스템 구조도)

소프트웨어 아키텍처 건축 설계에 비유 아키텍처 스타일 아키텍처가 중요한 이유 범위 설계와 시공에 대한 가이드가 될 큰 밑그림 일관적인 모양과 조화를 위한 스타일을 정하는 작업 아키텍처 스타일 구조의 유형 아키텍처가 중요한 이유 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않음 범위 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브시스템 간의 통신 프로토콜을 포함

아키텍처의 중요성 좋은 구조와 나쁜 구조의 차이 광범위한 영향을 미침

아키텍처 관점 아키텍처를 표현하는 방법은 관점에 따라 다양함 소프트웨어 아키텍처 관점은 크게 세 가지[Clements]

저장소 구조 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화 사례 급여 시스템 은행 시스템과 같은 데이터베이스 관리 시스템

MVC 구조 MVC 분리하는 이유 모델 서브시스템: 도메인의 지식을 저장보관 뷰 서브시스템: 사용자에게 보여줌 제어 서브시스템: 사용자와의 상호 작용을 관리 분리하는 이유 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문

클라이언트 서버 구조 서버는 클라이언트에게 서비스를 제공 서비스의 요구 클라이언트 서버 원격 호출 메커니즘 CORBA나 Java RMI의 공통 객체 브로커 클라이언트 사용자로부터 입력을 받아 범위를 체크 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집 서버 트랜잭션을 수행 데이터의 일관성을 보장

계층 구조 각 서브 시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용 추상화의 성질을 잘 이용한 구조 대표적인 예: OSI 구조 장점 각 층을 필요에 따라 쉽게 변경할 수 있음 단점 성능 저하를 가져올 수 있음

파이프 필터 구조 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복 서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 함 대표적인 예는 Unix 쉘

Questions?