1. 설계의 이해
1.1. 설계의 목적
1.1.1. 요구분석 명세서를 기반으로 어떻게 구축할 것인가를 결정
1.2. 설계자의 역할
1.2.1. 다양한 제약 조건을 만족시킬 수 있는 최적의 설계안을 만드는 것이 중요
1.2.2. 설계를 평가할 수 있는 평가기준도 정량적으로 명시
1.3. 좋은 설계의 조건
1.3.1. 요구분석 명세서의 내용을 설계서에 모두 포함해야 한다 (완전성)
1.3.2. 유지보수가 용이하도록 추적이 가능해야 한다.
1.3.3. 변화에 쉽게 적응할 수 있어야 한다.
1.3.4. 시스템 변경으로 인한 영향이 최소화 되도록 국지적이여야 함
1.3.5. 설계서는 읽기 쉽고, 이해하기 쉽게 작성해야 함
1.3.6. 좋은 설계가 되려면?
1.3.6.1. 모듈의 독립성
1.3.6.2. Strongly Cohesion (높은 응집)
1.3.6.3. Loosely Coupling (낮은 결합)
1.4. 설계의 종류
1.4.1. 설계
1.4.1.1. 상위설계
1.4.1.1.1. 아키텍처 설계
1.4.1.1.2. 데이터설계
1.4.1.1.3. (시스템분할)
1.4.1.1.4. 인터페이스 정의
1.4.1.1.5. 사용자 인터페이스 설계
1.4.1.2. 하위설계
1.4.1.2.1. 모듈 설계
1.4.1.2.2. 자료구조 설계
1.4.1.2.3. 알고리즘 설계
2. 설계의 원리
2.1. 분할과 정복 (divided and conquer)
2.1.1. 의미
2.1.1.1. 큰 문제를 소단위로 나누고 소 단위의 작업을 하나씩 처리하여 전체 일을 끝내는 방법
2.1.1.2. 가장 세분화된 작은 시스템을 개발하고, 위로 올라가면서 완성시키는 방법으로 개발
2.1.1.3. 예) 대학 종합정보 시스템(학사, 회계, 인사관리로 나눔), 학사관리(수강, 수업, 성적 관리등으로 나눔)
2.1.2. 분할 기준 형태
2.1.2.1. Distributed system : Client와 Server로 분할(분산처리)
2.1.2.2. System : 여러 Sub-System으로 분할
2.1.2.3. Sub-System : 하나 이상의 Package로 분할
2.1.2.4. Package : 여러 Class로 분할
2.1.2.5. Class : 여러 Method로 분할
2.1.3. 분할 수준
2.1.3.1. 너무 많을 때
2.1.3.1.1. 통신횟수증가->복잡도증가->처리비용증가->분할 효과 감소
2.1.3.2. 너무 적을 때
2.1.3.2.1. 통신횟수감소->복잡도감소->처리비용감소->분할효과 감소
2.1.3.3. 적절한 모듈 수로 분할하는 것이 설계자의 몫(능력)이다.
2.2. 추상화 (abstraction)
2.2.1. 개념
2.2.1.1. 주어진 문제에서 현재의 관심사에 초점을 맞추기위해 특정한 목적과 관련된 필수 정보만 추출하여 강조하고 관련이 없는 세부사항은 생략함으로써 본질적인 문제에 집중할수 있도록 하는 작업
2.2.1.2. 객체지향
2.2.1.2.1. 객체들의 공통점을 뽑아 클래스라는 이름을 붙여놓는 행위를 추상화(abstraction)이라 한다.
2.2.1.2.2. 클래스로 부터 객체를 생성하는 과정을 인스턴스화(instantiation)이라 한다.
2.2.2. 종류
2.2.2.1. 과정 추상화 (Procedure Abstraction)
2.2.2.1.1. 대부분 주어진 문제에 대해 프로그래밍하기 전 상세부분은 생략하고 전체하름만 파악할 수 있는 알고리즘 형태로 작성하는것
2.2.2.1.2. 예) C언어의 함수호출
2.2.2.2. 데이터 추상화(Data Abstraction)
2.2.2.2.1. data와 method를 class형태로 캡슐화하여 숨겨놓고, 사용자에게는 꼭 필요한 기능만 사용할 수 있게 개방한 구조
2.2.2.2.2. 예) C++의 class
2.2.2.3. 제어 추상화 (Control Abstraction)
2.2.2.3.1. 프로그래밍 언어에서 쓰는 제어구조를 추상화 하는것
2.2.2.3.2. 예) 고급언어<-어셈블리어<-기계언어
2.3. 단계적 분해
2.3.1. 개념
2.3.1.1. 하향식 설계에서 사용되며 기능을 점점 작은 단위로 나누어 점차적으로 구체화하는 방법이다
2.3.1.2. ex) Data Flow Diagram
2.4. 모듈화
2.4.1. 개념
2.4.1.1. 규모가 큰 것을 여러개로 나눈 조각
2.4.1.2. SW 구조를 이루는 기본적인 단위
2.4.1.3. 하나 또는 몇 개의 논리적인 기능을 수행하기 위한 명령어들의 집합
2.4.1.4. 라이브러리 함수, 그래픽함수, 추상화된 자료, subroutine, procedure, object, method
2.4.1.5. 독립 프로그램도 하나의 모듈로 가능, 함수들도 하나의 모듈로 가능
2.4.2. 특징
2.4.2.1. 다른것들과 구별될 수 있는 독립적인 기능을 갖는 단위
2.4.2.2. 유일한 이름
2.4.2.3. 독립적으로 컴파일 가능
2.4.2.4. 모듈에서 또 다른 모듈을 호출 가능
2.4.2.5. 다른 프로그램에서도 모듈을 호출 가능
2.5. 정보은닉
2.5.1. 6장 하위설계에서 다룸.
3. 소프트웨어 아키텍처
3.1. 개념이해
3.1.1. Software architecture
3.1.2. 대규모 SW를 개발 -> 사용자의 니즈를 만족시키여야 함 -> 적시성, 유연성, 통합 특성을 만족시키려야 함 -> 이러한 복잡성을 해결하기위해 등장
3.1.3. 해결방안 1. 개발할 SW의 전체구조를 가장 먼저 생각 2. 그 구조를 이루는 각 구성요소를 찾음 3. 각 구성 요소들 간의 명확한 관계를 설정 4. 일정한 규칙을 따름
3.1.4. 자료구조, 알고리즘보다 전체 시스템의 구조를 생각하며 설계
3.2. 특징과 기능
3.2.1. 특징
3.2.1.1. 개발할 SW에 대한 전체적인 구조를 다룸
3.2.1.2. SW를 이루고 있는 여러 구성요소 (subsystem, component)를 다룸
3.2.1.3. 구성 요소들이 interface를 통해서 어떻게 상호작용하는지를 정의해야 함
3.2.1.4. 세부 내용보다는 중요한 부분을 다룸
3.2.1.5. 시스템 설계와 개발 시 적용되는 원칙과 지침이 있어야 함
3.2.2. 기능 (설계시 고려해야 할 사항)
3.2.2.1. 의사소통 도구로 활용할 수 있어야 함
3.2.2.2. 구현에 대하 제약사항을 정의해야 함
3.2.2.3. 품질 속성을 결정해야 함
3.2.2.4. 재사용할 수 있게 설계해야 함
3.2.3. 설계서 작성방법
3.2.3.1. 이해하기 쉽게 작성
3.2.3.2. 명확하게 기술
3.2.3.3. 표준화된 형식 사용
3.2.3.4. 문서 버전 명시
3.3. 품질 속성
3.3.1. 시스템 품질 속성
3.3.1.1. 1. 가용성 (availability) : 시스템이 운용될 수 있는 확률로, 시스템이 장애 발생없이 서비스를 제공할 수 있는 능력 (HW 이중화)
3.3.1.2. 2. 변경 용이성 (modifiability) : 변경 요구 사항을 받았을 때 쉽게 변경할 수 있는 능력
3.3.1.3. 3. 성능 (performance) : 사용자 요청과 같은 event 가 발생했을 때, 빠르고 적절하게 반응 할 수 있는 능력 (공유자원, 알고리즘에 영향을 크게받음)
3.3.1.4. 4. 보안성 (security) : 허용되지 않은 접근에 대응할 수 있는 능력
3.3.1.5. 5. 사용성 (usability) : SW를 사용할 때 혼란스러워 하거나 사용하는 순간에 고민하지 않게 하는 편의성
3.3.1.6. 6. 테스트 용이성 (testability) : 사용자가 요구하는 기능을 만족스럽게 잘 수행하고 있는지를 얼마나 쉽고 철저하게 테스트할 수 있는지의 속성
3.3.2. 비즈니스 품질 속성
3.3.2.1. 1. 시장 적시성 (time to market) : 정해진 날짜에 SW를 출시해 경쟁력을 높일 수 있는 정도
3.3.2.2. 2. 비용과 이익 (cost and benefit) : 비용을 더 들여 사용하고 효과를 볼 것인지, 아니면 비용을 절약하는 데 중심을 둘 것인지 선택
3.3.2.3. 3. 예상 시스템 수명 ( predicted lifetime of the system) : 수명이 중요한 시스템 개발 (변경용이성, 확장성, 이식성을 고려시 증가가능)
3.3.2.4. 4. 목표 시장 (targeted market) : 대표적으로 package SW가 있는데 기능성이 중요하며 다양한 시장을 위한 이식성또한 중요시된다
3.3.2.5. 5. 신규 발매 일정 또는 공개 일정 (rollout schedule) 현재 version에서는 기본기능만 제공하고, 추후에 기능을 추가하여 완성도를 높이려면 유연성과 확장성을 고려해야 한다
3.3.2.6. 6. 기존 시스템과의 통합 (integration with legacy system) : 통합을 충분히 고려한 설계가 필요하다
3.3.3. 아키텍처 품질 속성
3.3.3.1. 1. 개념적 무결성 (conceptual integrity) : 일관성이라고도 하며 전체 시스템과 구성요소가 일관되도록 함
3.3.3.2. 2. 정확성과 완전성 (correctness and completeness) : 사용자가 요구하는 기능을 충족시키는 정도로 요구분석 명세서와 일치 정도를 뜻함
3.3.3.3. 3. 개발 용이성 (구축 가능성, buildability) : 전체 시스템을 적절한 모듈로 분할한 후 분배햐여 기간내 와성하고 개발중 수정을 용이하게 하는것
3.3.4. 이해 관계자별 품질 속성
3.3.4.1. 1. 발주자 관점 : 개발비
3.3.4.2. 2. 사용자 관점 : 편리성
3.3.4.3. 3. 개발자 관점 : 새로운 플랫폼에서의 적용이 쉬운 것, 변경이 쉬운것
3.4. 구축 절차
3.4.1. 요구사항 분석 -> 아키텍처 분석 -> 아키텍처 설계 -> 검증 및 승인
3.4.2. 요구 사항 분석
3.4.2.1. 분석단계와 비슷한 절차이지만 품질속성과 같은 비기능적인 요구사항에 좀더 관심을 둠 [요구 사항 취득, 식별, 명세, 분류, 검증 / 기능적,비기능적 요구사항 분류 및 명세]
3.4.3. 아키텍처 분석
3.4.3.1. 위에서 서술한 품질속성을 식벌 -> 우선순위 결정 -> 반영 방법 개발
3.4.4. 아키텍처 설계
3.4.4.1. 관점정의 -> 아키텍셔 스타일 선택 -> 후보 아키택처 도출
3.4.5. 검증 및 승인
3.4.5.1. 아키텍처 평가 -> 아키텍처 상세화(반복) -> 아키텍처 승인
3.5. 4+1관점
3.5.1. 1. usecase 관점
3.5.1.1. 시스템이 사용자에게 제공하는 기능에 관심
3.5.1.2. 정적 표현 : 유스케이스 다이어그램 동적 표현 : 상태, 순차, 통신, 활동 다이어그램
3.5.2. 2. 논리적 관점
3.5.2.1. 시스템 내부를 들여다 봄 기능제공을 위한 class나 component의 종류와 관계에 초점
3.5.2.2. 정적 표현 : 클래스, 객체 다이어그램 동적 표현 : 상태 (클래스 내 동작), 순차/통신(클래스 간의 상호작용), 활동 (클래스의 연산동작) 다이어그램
3.5.3. 3. 구현 관점
3.5.3.1. 물리적 시스템에서 사용하는 SW subsystem의 module이 어떻게 구조화 되어있는가
3.5.3.2. 정적 표현 : 컴포넌트 다이어그램 동적 표현 : 상태, 순차, 통신, 활동 다이어그램
3.5.4. 4. 프로세스 관점
3.5.4.1. 실제 구동환경, 시스템 내부에 관심 모든 클래스가 아닌, 독자적인 제어 thread를 가질수 있는 클래스에 초점을 맞춤
3.5.4.2. 동적 표현 : 상태, 순차, 협동, 활동 다이어 그램(시간의 흐름에 따른 변화) 시스템 구성 표현 : 컴포넌트, 배치 다이어그램
3.5.5. 5. 배치관점
3.5.5.1. 시스템을 구성하는 처리장치간의 물리적인 배치에 초점 ( 노드간의 관계로 표현)
3.5.5.2. 정적 표현 : 배치 다이어그램 동적 표현 : 상태, 순차, 통신, 활동 다이어그램
3.6. 스타일
3.6.1. 개요
3.6.1.1. 아키텍처 스타일 등장 이전 :개발자들의 경험을 통해 각자의 스타일로 개발과 유지보수를 함
3.6.1.2. 개발자와 유지보수자가 다른경우 : 코드분석에 어려움이 생김
3.6.1.3. 해결안 : 검증된, 보편적인 아키텍처스타일을 사용해 아키텍처 설계
3.6.2. 장점
3.6.2.1. 1. 개발기간 단축, 고품질의 소프트웨어 생산 : 시행착오 감소
3.6.2.2. 2. 수월한 의사소통 : 공통된 아키텍처를 공유하여.
3.6.2.3. 3. 용이한 유지보수 문제 : 비지니스 로직만 알면 분석용이
3.6.2.4. 4. 검증된 아키텍처
3.6.2.5. 5. 구축전 시스템 특성에 대한 simulation가능
3.6.2.6. 6. 기존 시스템에 대한 빠른 이해
3.6.3. 기능
3.6.3.1. SW 시스템의 구조를 체계적으로 구성하기 위해 기본 스키마를 제공
3.6.3.2. 미리 정의된 subsystem 제공
3.6.3.3. 각 architecture pattern 간의 책임을 명시
3.6.3.4. pattern간의 관계를 조직화하는 규칙, 가이드 라인을 제시
3.6.3.5. 문제를 SW모듈 단위로 분해하는 방법 제시
3.6.3.6. 분해한 SW 모듈 단위가 상호작용하는 방법 제시
3.7. 모델
3.7.1. 기능의 분할과 배치
3.7.1.1. 데이터 중심형(repository model) 모델
3.7.1.1.1. 주요 data가 repository에서 중앙관리
3.7.1.1.2. ex) 학사관리 시스템, 급여 시스템, 은행업무 시스템
3.7.1.1.3. 장점 : 데이터를 모순없이 일관성있게 관리 / 새로운 subsystem 추가 용이
3.7.1.1.4. 단점 : repository 의 병목현상, 데이터의 변경이 시스템에 영향을 줌. (높은 결합도)
3.7.1.2. client-server 모델
3.7.1.2.1. 데이터 중심형 모델의 특수한경우 / 데이터와 처리기능을 client, server에 분할 사용
3.7.1.2.2. client는 server에게 서비스요청 : 서버와 서비스의 이름을 알아야함
3.7.1.2.3. UI / Application / DB 를 분배하는 모양이 다양
3.7.1.2.4. 데이터 중심형 모델과 의 차이 : 클/서 모델은 프로세스의 제한이 없음. ex) 크롬에서 여러개의 창 띄우는꼴.
3.7.1.3. 계층 (layering) 모델
3.7.1.3.1. 기능을 몇개의 계층으로 나누어 배치
3.7.1.3.2. 계층 간 역할이 명확 / 구분만 잘하면 재사용 가능
3.7.1.3.3. 3계층 모델 UI / APP / DB로 나누어짐
3.7.1.4. MVC (model / view / controller) 모델
3.7.1.4.1. 데이터 중심형 모델의 특수한 경우 / 제어 객체가 제어흐름을 제시
3.7.1.4.2. 같은 모델의 sub-system에 대하여 여러 view-system을 필요로 하는 시스템에 적합 ex) 같은 엑셀 데이터로 표, 그래프, 차트 등으로 컨트롤러를 통해 view에 띄우는 형태
3.7.1.4.3. 1. Model sub-system 최하단 계층으로 무언가의 호출에만 응답
3.7.1.4.4. 2. View sub-system 최상단 계층으로 사용자에게 보여지는 부분
3.7.1.4.5. 3. Controller sub-system m/v 간의 전달자 역할
3.7.1.4.6. 3계층 모델과는 다르게 최하단 계층에 data 와 logic이 같이 자리한다.
3.7.1.4.7. 장점 : 관심의 분리, loosely coupling 가능 단점 : 기본 기능 설계로 인한 class 수 증가에 따른 복잡도가 증가한다.
3.7.2. 제어관계
3.7.2.1. 데이터 흐름 모델
3.7.2.1.1. pipe and filter 구조