소프트웨어 공학 (Software Engineering) 설계 원리와 아키텍처 문양세 강원대학교 IT대학 컴퓨터과학전공

Where are we in waterfall model? 설계 원리와 아키텍처 계 획 요구 분석 설 계 구 현 시 험 인수설치

In this chapter … 요구 분석이 끝나면, 소프트웨어의 내부 구조를 설계하여야 한다. 설계 원리와 아키텍처 요구 분석이 끝나면, 소프트웨어의 내부 구조를 설계하여야 한다. 지금까지는 “what”에 주안점이 있었다면, 지금부터는 “how”에 주안점을 두고 작업을 진행한다. 건축으로 치면, 설계 도면을 작성하는 작업이다.  방을 어디다 두고, 크기는 얼마로 하며, 어떤 모양으로 만들고, … We will cover … 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 객체지향 설계 (Ch. 6) 상세 설계와 UI 설계 (Ch. 7) 설계서

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

We are now … 설계 원리와 아키텍처 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

분석에서 설계로… 요구 분석서 - 시스템이 해결하려는 문제에 대하여 기술한 것 설계 원리와 아키텍처 요구 분석서 - 시스템이 해결하려는 문제에 대하여 기술한 것 설계 - 분석서에 기술된 문제를 해결 방안(설계 대안)으로 바꾸는 작업

설계 작업에서는? (1/2) 설계 원리와 아키텍처 설계란 “사용자의 요구를 만족시키기 위하여 제약 조건이 반영된 (최선의) 구현 대안을 창출하는 일”이다. 분 석 설 계 구 현 사용자 요구사항 제약 조건 구축 시스템 시스템의 본질정의 구현대안 설정 시스템 구축 분석모형 설계모형 설계자는 사용자와 개발자를 동시에 만족시켜야 한다. 사용자는 설계를 보고 시스템이 어떤 기능을 하는지 이해할 수 있어야 한다. (집 주인이 집 설계도를 보고 집이 어떻게 지어질지 알 수 있어야 한다.) 개발자는 시스템이 어떻게 동작하고, 어떻게 구현하는지 이해할 수 있어야 한다. (집 짓는 사람들이 설계도를 보고 집을 어떻게 지어야 하는지 알 수 있어야 한다.)

설계 작업에서는? (2/2) 설계 원리와 아키텍처 설계 작업은 정의된 문제에 대하여 설계 원리를 적용하여 주어진 여러 제약 조건을 잘 만족시키는 최선의 설계안을 선택하는 작업이다. 대규모 소프트웨어를 설계하기 위한 작업의 분류

We are now … 설계 원리와 아키텍처 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

설계 원리란? (1/2) 좋은 설계가 되도록 하기 위한 작업의 규범 (문제 분할, 모듈화, 추상화 등) 설계 원리와 아키텍처 좋은 설계가 되도록 하기 위한 작업의 규범 (문제 분할, 모듈화, 추상화 등) 경험에 의하여 터득한 원리(rule of thumb) (설계 결과를) 검토 및 평가 할 수 있는 기준

설계 원리란? (2/2) 설계 원리와 아키텍처 주요 설계 원리 문제의 분할, 단계적 분해(stepwise refinement): 처음엔 간단히, 차츰 세밀하게… ( 사칙연산  더하기  정수 더하기) 추상화(abstraction): 복잡한 문제를 일반화하여, 쉽게 이해할 수 있도록 하는 원리 ( 피타고라스 정리?) 모듈화(modularization): 모듈은 독립성을 가져야 함… ( 많은 라이브러리 함수를 생각하세요, 삼각함수 등) 정보 은닉(information hiding): 함수의 내부 변수 사용이 외부에 알려질 필요가 없다… ( 내정 간섭하지 마요~)

분할과 정복 (divide and conquer) 문제의 분할 설계 원리와 아키텍처 분할과 정복 (divide and conquer) 큰 문제를 한 덩어리로 다루기는 어려움 큰 문제를 작은 조각으로 나누고, 각 조각을 하나씩 해결(정복)함 분할의 결과 장점: 작은 조각(컴포넌트)은 해결이 용이함 단점: 여러 조각에 따른 통신 오버헤드가 발생함  설계자는 분할을 중지할 시점(단위)을 결정해야 함

단계적 분해(Stepwise Refinement) 설계 원리와 아키텍처 기능을 최대한으로 떼어내어 생각 점진적으로(incrementally) 구체화 상세한 내역(알고리즘, 자료구조)는 가능한 뒤로 미룸 추상화 I CAD softrware tasks: user interaction task; 2-D drawing creation task; graphics display task; drawing file management task; end. 추상화 II procedure: 2-D drawing creation; repeat util <drawing creation task terminates> do while <digitizer interaction occurs> digitizer interface task; determine drawing request; line: line drawing task; circle: circle drawing task; . 추상화 III CAD system

추상화 (Abstraction) (1/2) (현실의) 복잡한 문제  추상화  개념 정립 설계 원리와 아키텍처 (현실의) 복잡한 문제  추상화  개념 정립 소프트웨어의 구조를 이루는 계층의 파악

추상화 (Abstraction) (2/2) 기능 추상화 자료 추상화 제어 추상화 입력자료를 출력자료로 변환하는 과정을 추상화 설계 원리와 아키텍처 기능 추상화 입력자료를 출력자료로 변환하는 과정을 추상화 부프로그램(subprogram)의 목적과 기능만 생각 자료 추상화 자료와 기능을 묶어서 생각 (data object 구성하는 방법)  OO Concept 제어 추상화 외부 이벤트에 대한 반응을 추상화  … 입력되면 …을 처리하고…

모듈화(Modularization) (1/6) 설계 원리와 아키텍처 1 4 1 2 3 2 1 5 4 4 5 6 3 6 2 3 5 6 문제영역 시스템 분해 시스템 구조 시스템 분해를 어떻게 해야 할 것인가?  모듈로 분해한다. 한 모듈의 규모는 어떠해야 하는가? 30 lines ~ 50 lines ??? 너무 길면 이해하기 어렵고, 너무 짧으면 성능이 저하됨

모듈화(Modularization) (2/6) 설계 원리와 아키텍처 모듈의 이식성(portability) 특정 환경에서만 동작하는 것이 아니라 일반적 환경에서 동작하면 이식성이 높다고 이야기한다. 이식성이 높은 S/W를 개발하는 것은 모든 S/W Engineer의 공통된 목표이다. 모듈을 어떻게 만들 것인가? 어떻게 모듈을 구성할 것인가?  모듈(내) 응집력(intra relationship)은 강하게,  모듈(간) 결합력(inter relationship)은 약하게 모듈의 응집력: 모듈 내 기능/요소들이 갖는 관계 모듈의 결합력: 모듈 간의 관계

모듈화(Modularization) (3/6) 설계 원리와 아키텍처 모듈의 응집력(Cohesion) 하나의 모듈은 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계해야… 모듈 내의 모든 요소는 하나의 목적을 가지고 있는 것이 바람직하다. Theme sentence: 한 문단의 주제를 담고 있는 문장 (vs. support sentence) 모듈의 응집력 구분 기능적 응집(functional cohesion): 잘 정의된 하나의 기능이 하나의 모듈을 이룬 경우 예) “판매 세금 계산”  (동사, 목적어) 한 쌍으로 구성 순차적 응집(sequential cohesion): 모듈 내 한 작업의 출력이 다른 작업의 입력이 되는 경우 예) “다음 거래를 읽고, 그 결과를 마스터 파일에 반영함” 교환적 응집(communication cohesion): 동일한 입력과 출력을 사용하는 여러 작업들이 모인 경우 예) “인사 기록 파일에 근무 성적을 기재하고, 급여를 갱신함” 응집력이 강함 응집력이 약함

모듈화(Modularization) (4/6) 설계 원리와 아키텍처 모듈의 응집력 구분 (계속) 절차적 응집(procedural cohesion): 공유하는 것은 없으나, 큰 테두리 안에서 같은 작업에 속하는 경우 예) “총계를 출력하고, 화면을 지우고, 메뉴를 뿌리고, 메뉴 선택 코드를 받음” 시간적 응집(temporal cohesion): 특정 시간에만 수행되는 기능을 묶어놓은 모듈 예) 초기화 루틴(변수 할당, 초기값 설정, …) 논리적 응집(logical cohesion): 유사 성격을 갖거나 특정 형태로 분류되는 처리 요소들을 하나의 모듈로 형성 예) “사칙연산에서 주어진 매개변수에 따라 다른 계산을 함”  연산간 관계가 없음 우연적 응집(coincidental cohesion): 아무 관련 없는 처리 요소들로 모듈이 형성된 경우  모듈 개념이 상실되어 이해 및 유지보수가 힘든 단점이 있음 응집력이 강함 응집력이 약함

모듈화(Modularization) (5/6) 설계 원리와 아키텍처 모듈의 결합도(Coupling) 모듈간의 상호 의존하는 정도를 의미한다. 모듈은 하나의 블랙 박스로 다른 모듈과의 독립성이 높아야 한다. 독립적인 모듈이 되기 위해서는 다른 모듈과의 결합도가 약해야 한다(loosely coupled). 모듈의 결합도 구분 자료 결합(data coupling): 모듈 간의 인터페이스가 자료 요소(파라메터)로만 구성된 경우 예) add(3, 5), sort(a) 스탬프 결합(stamp coupling): 모듈 간의 인터페이스를 통해 배열, 레코드가 전달되는 경우 (단, 배열, 레코드 내용 전체가 사용되면 “자료 결합”으로 볼 수 있음) 예) print_salary(인사 기록 레코드) 결합도가 약함 결합도가 강함

모듈화(Modularization) (6/6) 설계 원리와 아키텍처 모듈의 결합도 구분 (계속) 제어 결합(control coupling): 한 모듈이 다른 모듈에게 제어 요소(function code, switch, flag 등)를 전달하는 경우 예) integer_operation(‘+’, 3, 5) 공통 결합(common coupling): 공통된 자료 영역을 사용하는 경우  자료 영역의 보호가 어렵고, 자료 구조 변경 시 파급 효과가 큼 예) C/C++ 등에서 global 변수를 사용하는 예제, Shared Memory 사용 내용 결합(content coupling): 한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정하는 경우  공유 부분을 변경할 필요가 생기면 그 파급 효과가 가장 큼 예 1) 에셈블리어에서 한 모듈이 다른 모듈의 데이터를 참조하는 경우 예 2) 한 모듈에서 다른 모듈로 분기(goto)하는 경우 결합도가 약함 결합도가 강함

정보 은닉(Information Hiding) 설계 원리와 아키텍처 각 모듈의 자세한 처리 내용이 시스템의 다른 부분으로부터 감추어져 있어야 ( 내부적으로 어떤 변수를 쓰던…) 각 모듈이 다른 모듈에 구애 받지 않고 설계  I/F만 잘 정의하자. 인터페이스가 모듈 안의 구체적 사항을 최소로 반영 전역변수가 없어야 모듈의 입력이 1이면 입력, 2이면 출력, …  좋은 모듈 설계가 아님  모듈화와 연관 모듈 단위의 수정, 시험, 유지보수에 큰 장점 모듈 설계 평가에 기초 모듈을 독립적으로 시험할 수 있으며, 모듈 별로 개선 및 최적화 할 수 있음

We are now … 설계 원리와 아키텍처 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

구조적 설계 개요 (1/2) 설계 원리와 아키텍처 시스템을 이루는 모듈의 구조를 파악하는 방법  궁극적으로 S/W 모듈의 종류, 모듈 간의 관계를 파악하고자 함 모듈 분해의 계층적, 인터페이스 지향적 접근 데이터 흐름 형식에 중점 Source-transaction-sink: 변환 분석(transform analysis)  자료가 어디서 나와서 어떤 처리를 거쳐서 어디로 전달되는가? Transaction pattern: 처리 분석(transaction analysis)  처리하고자 하는 트랜잭션의 기능이 무엇인가?

구조적 설계 개요 (2/2) 설계 원리와 아키텍처 시스템 구조도(structure)의 도출  (관리자를 비롯한 높은) 사람들은 한 눈에 들어오는 구조를 원한다.  결국, 간단하게 흐름을 파악할 수 있는 구조를 그려주어야 한다. 시스템을 모듈 단위로 분할 모듈의 계층적(hierarchical) 구성 모듈 사이의 입출력 인터페이스 모듈의 이름과 기능 S4 S3 S2 S1 S5 Structure #1 S2 S1 S3 S5 S4 Structure #2 S1 S3 S5 S2 S4 Structure #3

시스템 구조도 기호 (1/3) 표준 기호 한 모듈이 다른 모듈을 호출하는 관계를 나타냄 설계 원리와 아키텍처 표준 기호 한 모듈이 다른 모듈을 호출하는 관계를 나타냄 자료(변수 및 자료 구조)의 흐름을 나타냄 제어(플래그, 태그)의 흐름을 나타냄 모듈을 나타냄 반복(iteration) 주석달기 선택(option) comment Module

시스템 구조도 기호 (2/3) 설계 원리와 아키텍처 예제 Main은 모듈 A, B, C를 호출하고, A는 W, X를 호출하며, C는 Y, Z를 호출한다. C는 Y와 Z를 반복적으로 호출할 수 있고, A는 W 혹은 X 중 하나를 호출한다. 제어 플래그 f는 W에서 A로 전달되고, 자료(데이터) a는 A에서 Main으로 전달된다. … Main A B C W X Y Z a b c f

시스템 구조도 기호 (3/3) 설계 원리와 아키텍처 기타 기호 미리 정의된 모듈(라이브러리) 입출력 모듈

시스템 구조도의 요건 (1/4) 전체적으로 균형을 이뤄야 함 ( Skew는 별로 좋지 않음) 설계 원리와 아키텍처 전체적으로 균형을 이뤄야 함 ( Skew는 별로 좋지 않음) 과다한 깊이를 가지면  하위 모듈까지 통신 오버헤드가 커짐

시스템 구조도의 요건 (2/4) 설계 원리와 아키텍처 과다한 너비를 가지면  병목현상이 나타날 수 있음 (Parallel Processing이 어려움) 입력 처리 출력

시스템 구조도의 요건 (3/4) 편중의 종류: 입력 편중, 처리(process) 편중, 출력 편중 입력 편중의 예 입력 처리 설계 원리와 아키텍처 편중의 종류: 입력 편중, 처리(process) 편중, 출력 편중 입력 편중의 예 입력 처리 출력

시스템 구조도의 요건 (4/4) 설계 원리와 아키텍처 처리 편중의 예 입력 처리 출력 출력 편중의 예 입력 처리 출력

변환 분석(Transform Analysis) 설계 원리와 아키텍처 자료의 변환 흐름(transformation flow) 입력 흐름 출력 흐름 변환 센터 변환 분석은 자료 흐름도를 입력 흐름, 변환 센터, 출력 흐름으로 분할하는 과정이다. 입력 흐름: 입력을 준비하는 단계(입력, 검증...) 출력 흐름: 출력을 위하여 준비되는 단계(포매팅, 출력) 변환 센터: 실제 자료가 변환

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

변환 분석 방법 (2/2) 예제: 최상위 시스템 구조도 예제: 프로그램의 구조 main() { ... 설계 원리와 아키텍처 예제: 최상위 시스템 구조도 예제: 프로그램의 구조 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) 단어 계산 단어개수 검증된 파일 이름 파일 이름 상태 단어개수 파일이름 입력,검증 단어개수 계산 단어 개수 편집,출력

변환 분석의 원칙 최상위 모듈을 위한 변환 분석 하위 모듈을 위한 변환 분석 설계 원리와 아키텍처 최상위 모듈을 위한 변환 분석 ① 입력 자료 흐름과 출력 자료 흐름을 파악하여 경계를 표시한다. 즉, 입력 흐름 및 출력 흐름을 경계로 변환 센터를 식별하는 것이다. ② 최상위 모듈에 의해 직접 호출되고 제어될 다음 단계의 세 개 모듈, 즉 입력 처리 모듈, 변환 제어 모듈, 출력 처리 모듈을 만든다. 하위 모듈을 위한 변환 분석 ① 입력 처리 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다. ② 출력 처리 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다. ③ 변환 제어 모듈을 분해한다.  마찬가지로, 다시 입력/변환/출력으로 분해한다.

구독자 관리 시스템 (1/3) 1) 자료 흐름의 요소를 분해 입력 자료 흐름, 출력 자료 흐름, 변환 센터 설계 원리와 아키텍처 1) 자료 흐름의 요소를 분해 입력 자료 흐름, 출력 자료 흐름, 변환 센터 두 개의 입력 자료, 하나의 최종 출력 자료 출력 흐름 구독자 레코드 준비 구독자 레코드 만료일 추출 새 만료일 계산 구독자 레코드 변경 만료일 새 만료일 입력 흐름 변경 레코드 갱신기간 구독 갱신기간 입력 레코드를 파일에 출력 변환 센터

구독자 관리 시스템 (2/3) 2) 구조도의 최상위층 작성 입력, 변환, 출력 흐름을 바탕으로 최상위 구조도를 그린다. 설계 원리와 아키텍처 2) 구조도의 최상위층 작성 입력, 변환, 출력 흐름을 바탕으로 최상위 구조도를 그린다. 구독 갱신 시스템 갱신 정보 추출 갱신 레코드 저장 구독 갱신

구독자 관리 시스템 (3/3) 3) 구조도의 상세화 구조도의 각 모듈을 지속적으로 분할하여 상세 구조도를 완성한다. 설계 원리와 아키텍처 3) 구조도의 상세화 구조도의 각 모듈을 지속적으로 분할하여 상세 구조도를 완성한다. 계속적으로 분할하는 것을 요소 분해(factoring)한다고 한다. 구독 갱신 시스템 갱신 정보 추출 갱신 레코드 저장 구독 갱신 새 구독 기간 입력 구독 만료일 준비 구독자 레코드 변경 레코드 파일로 출력 구독 레코드 추출 구독 만료일 추출

마스터 파일 변경 시스템 구조도 (1/2) 설계 원리와 아키텍처 자료 처리 흐름도 (DFD)

마스터 파일 변경 시스템 구조도 (2/2) 설계 원리와 아키텍처 시스템 구조도

처리 분석(Transaction Analysis) 설계 원리와 아키텍처 처리(transaction)? 자료 흐름도의 한 프로세스에서 여러 개의 자료 흐름이 유출되는 것  현금 자동 지급기의 경우 “선택”에서 여러 분기가 일어난다. 처리흐름 T 처리 경로(action path) 처리센터 방법 ① 자료 흐름도에서 처리 센터를 식별 ② 처리 모듈을 중심으로 구조도 작성 ③ 구조도를 상세화 - 하위 구조도를 작성

처리 분석 예제: 현금 자동 지급기 (1/2) 설계 원리와 아키텍처 자료 흐름도(DFD)

처리 분석 예제: 현금 자동 지급기 (2/2) 설계 원리와 아키텍처 시스템 구조도 (상위 구조)

설계 요령 (design heuristics) (1/2) 설계 원리와 아키텍처 모듈의 결합도는 줄이고 응집력은 높이도록 최대한 노력 High fan-out은 줄이도록 노력 ...... Redundancy와 complexity를 줄이기 위하여 모듈의 인터페이스를 점검

설계 요령 (Design Heuristics) (2/2) 설계 원리와 아키텍처 양파 모양의 구조가 일반적 복잡한 모듈의 연결은 피함 과다한 깊이를 가진 구조도 피함 모듈의 영향권을 그 모듈의 하위에 둔다. <잘못된 예> <잘된 예> 변경된 모듈 변경된 모듈 영향받는 모듈

사례: 비디오 대여점 (Level 0 변환 분석) 설계 원리와 아키텍처

사례: 비디오 대여점 (Level 1 변환 분석) 설계 원리와 아키텍처

사례: 비디오 대여점 (시스템 구조도) 설계 원리와 아키텍처

We are now … 설계 원리와 아키텍처 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

소프트웨어 아키텍처 설계 원리와 아키텍처 건축 설계로 본다면… 설계와 시공에 대한 가이드가 될 큰 밑그림 일관적인 모양과 조화를 위한 스타일을 정하는 작업 스타일이라는 개념을 소프트웨어 구조에도 적용  어떻게 동작해야 할 지의 동작 메커니즘의 큰 그림을 결정  중앙 DB를 두고? C/S 모델로? 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않음 소프트웨어 구조는 시스템 분할, 전체 제어 흐름, 오류 처리 방침, 서브시스템 간의 통신 프로토콜을 포함

아키텍처의 중요성 좋은 구조와 나쁜 구조의 차이 소프트웨어 개발 과정은 물론 최종 제품의 품질에 광범위한 영향을 미침 설계 원리와 아키텍처 좋은 구조와 나쁜 구조의 차이 소프트웨어 개발 과정은 물론 최종 제품의 품질에 광범위한 영향을 미침

저장소 구조 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 설계 원리와 아키텍처 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화 새로운 서브시스템도 저장소를 중심으로 위치함 사례 (주로 DB를 사용하는 경우) 급여 시스템 은행 시스템과 같은 데이터베이스 관리 시스템

MVC 구조 MVC(Model, View, Control) 분리하는 이유 모델 서브시스템: 도메인의 지식을 저장 및 보관 설계 원리와 아키텍처 MVC(Model, View, Control) 모델 서브시스템: 도메인의 지식을 저장 및 보관 뷰 서브시스템: 사용자에게 보여줌 제어 서브시스템: 사용자와의 상호 작용을 관리 분리하는 이유 사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문임 Excel에서 사용자는 표, 그래프, 차트 등으로 볼 수 있으나(뷰), 실제 저장은 한 군데 있으며(모델), 다른 뷰에서 각기 수정하여도(제어) 한 군데 반영됨

클라이언트 서버 구조 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공 설계 원리와 아키텍처 서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공 클라이언트: 사용자로부터 입력을 받아 범위를 체크하고 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집 서버: 트랜잭션을 수행하고 데이터의 일관성을 보장한다 우리가 매일 사용하고 있는 웹 환경이 대표적인 C/S 구조에 해당함

계층 구조 (Hierarchical Structure) 설계 원리와 아키텍처 각 서브 시스템이 하나의 계층이 되어 하위 층이 제공하는 서비스를 상위 층의 서브시스템이 사용 추상화의 성질을 잘 이용한 구조 대표적인 예: 네트워크의 OSI 7 Layer 구조 장점: 각 층을 필요에 따라 쉽게 변경할 수 있음 단점: 성능 저하를 가져올 수 있음

파이프 필터 구조 (Pipe Filter Structure) 설계 원리와 아키텍처 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복 서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 함 대표적인 예는 UNIX/Linux 쉘

파이프 사용 예제 (in Linux) 설계 원리와 아키텍처

We are now … 설계 원리와 아키텍처 분석에서 설계로 설계 원리 구조적 설계 소프트웨어 아키텍처 설계서

시스템 설계서 작성 1. 개요 2. 시스템 구조 3. 모듈 설계(각 모듈에 대한) 4. 화일 구조 또는 데이타베이스 설계 설계 원리와 아키텍처 1. 개요 1.1 시스템의 목표 1.2 하드웨어, 소프트웨어 1.3 소프트웨어의 주요 기능 1.4 설계상 제약사항 1.5 참조된 개발문서 2. 시스템 구조 2.1 시스템 구조 개요 2.2 시스템 구조도 2.3 자료사전 3. 모듈 설계(각 모듈에 대한) 3.1 모듈이름 3.2 모듈형 3.3 인터페이스 3.4 오류메시지 3.5 사용하는 파일 3.6 호출하는 모듈 3.7 기능설명 4. 화일 구조 또는 데이타베이스 설계 4.1 외부 화일(데이타베이스)의 논리적 구조 4.2 공유 자료 4.3 파일 접근 방법(데이타베이스 관리체제) 5. 요구분석 참조표 6. 제약사항 7. 참고사항 참고문헌 부록

Homework #3 Homework