객체지향 설계 원리: 도메인 중심의 분석 결과물을 소프트웨어 관점의 산출물로 전환하는 과정
추상화, 모듈, 정보 은닉, 인터페이스 분리, 의존관계 역전 등을 실시함.
- 소프트웨어 시스템을 구성하는 로직 설계 (클래스 & 메소드에 대한 설계)
- 사용자 인터페이스(UI) 설계
- 자료구조 or DB 설계
- 물리적 아키텍처 설계
등과 같은 활동을 포함함.
전통적인 설계 원리
단순성
- 복잡한 여러가지 요소를 단순환하거나 복잡함을 최소화
- 유지보수에 영향을 주는 가장 중요한 특성
- 범위를 한정 짓는 게 중요함 (우리 시스템의 범위가 어느 정도로 한정되어 있는지 알고 있는가?가 중간고사 context diagram의 채점 기준이었음)
효율성
- 처리 시간과 기억 공간(메모리)
- 사용하는 자원이 적정하고 효과적이도록 함 -> 작업 효율성 증진
ex. 알고리즘의 효율성
분할 및 계층화
- 다루기 쉬운 덩어리로 분리하여 계층화
ex. 정보 은닉
> 아키텍처: 시스템을 구성하는 컴포넌트와, 컴포넌트 상호작용의 집합
> 서브 시스템: 시스템의 복잡도를 줄이기 위해 분할한 것 (ppt p.9)
추상화: 사물의 대표적인 특징으로 대상물을 나타내는 것 (= 상세한 내용은 가리는 것)
- 시스템의 핵심 특성에 초점을 두어, 하나의 큰 시스템을 분할하는 원리
- 자세한 부분에 좌우되지 않도록 컴포넌트를 정의
- 여러 클래스의 부모 클래스를 생성하거나, 유사한 클래스를 묶어 하나의 패키지로 표현할 때 추상화 사용
=> 우리 시스템을 다른 사람에게 잘 전달할 수 있도록 하기 위함
ex. 모델 - 사물의 가장 대표적인 특성/특징을 뽑아서 표현 (p.10)
모듈화: 대상에 대하여 특정한 목적에 관련된 정보에 집중하고, 나머지는 무시하는 것
- 각 모듈이 외부와의 결합이 낮고, 내부 요소가 응집되도록 함
- 데이터나 절차적인 동작 관점으로 정의함
ex. 클라이언트 - 서버 간 정보 교환을 주고받는 메시지의 추상화 (p. 11)
캡슐화: 분할된 핵심 정보만을 노출 -> 큰 시스템을 잘 모듈화된 시스템으로 완성 (p. 12)
- 추상화된 대상이, 제공하는 서비스를 쉽게 접근할 수 있도록 하는 개념 (p. 14)
- 정보 은닉을 위해 사용됨
모듈화: 문제를 소프트웨어의 구성 요소가 될 만한 수준으로 분할하는 과정 - 즉, 소프트웨어를 작은 구성 요소(package or class)로 나누는 것 (p.12)
'한 클래스당 하나의 단일한 책임을 가지는가?'에 대해 초점을 둘 것.
아키텍처를 유지보수할 수 있게 하기 위한 기본 베이스가 모듈화임.
설계 과정에서 적용할 수 있는 기본 원리
단계적 상세화: 클래스 멤버들에 대한 제약 사항 설계, 메소드의 내부 로직 설계 등과 가튼 단계적인 구체화 작업을 진행하고, 구현과 관련된 정보들을 도출함
모듈화: 변경에 대처하고, 확장성을 높이기 위한 방법 - 추후 클래스 구성 요소에 대한 통합, 분리, 이동 등을 통해 모듈화를 높일 수 있음
정보 은닉: 외부에 꼭 필요한 사항만 공개함 - 클래스 멤버들에 대한 참조 범위(Public & Private 등과 같은) 선언 필요
관심사 분할: 상위 설계, 상세 설계 등 개발 과정에서 관심사를 분리하여 설계해야 함 ex. UI, 자료구조 등 소프트웨어 시스템 구성 요소 등에 대한 관심사 분리
분석 결과물을 설계 결과물로 발전시키기 위한 세 가지 기법
1. 팩토링
- 모델 요소의 유사점이나 차별점에 따라, 별도의 모듈(ex. class)로 분리하는 방법
- 새로운 클래스를 생성하는 방법
- 클래스들의 공통점을 추출하여 상위 클래스를 일반화
- 상호 관련성이 존재하는 요소들을 집합 관계로 정의하는 과정을 고려할 수 있음
- 추상 클래스 혹은 상위 클래스를 생성하기 위해 진행
- 한 클래스의 하위 클래스를 생성하기 위해 상세화 과정 진행
2. 파티셔닝 (분할)
- 큰 모델을 세부 모델로 나누는 과정
- 작은 모델은 시스템을 구성하는 서브 시스템이 될 수 있음
- 분할 과정에서 모듈화 개념을 적용함
- 모델 요소 간 메시지 전송이 많다면, 이들을 하나의 서브 시스템으로 통합하는 것이 유리함
3. 계층화 (사람이 인지할 수 있는 정보량을 기준으로)
- 시스템을 구성하는 요소들을 운영, 사용 환경 등을 고려하여 서로 다른 특징의 그룹으로 분리하는 과정
- 서비스 제공을 위한 내부 처리 로직과 UI를 분리함
- MVC(Model View Controller)와 같은 아키텍처로 시스템 설계 (p. 18)
- View: 사용자에게 처리 로직 결과를 제공
- Controller: 로직 수행을 위한 입력을 제공하는 부분
계층화는 3계층 아키텍처를 기반으로 진행함 (3-tier, State-Logic-Display라고도 함) -> UI 계층, 처리 로직 계층, 데이터 관리 계층으로 시스템을 분리하는 방법
객체지향 방법론을 근간으로 하는 소프트웨어 설계 과정
1. 구조 모델링의 결과물인 도메인 클래스 다이어그램을 설계 모델로 진화
- 클래스를 구성하는 요소들에 대한 상세 정보와 메소드를의 내부 로직을 설계
2. 구조 모델링의 결과물인 클래스 다이어그램 입력 (패키지 다이어그램 작성)
3. 클래스 다이어그램을 이용하여 대응하는 UI 클래스와 DB table 생성
4. 각 패키지를 하드웨어 플랫폼에 할당하는 배치 다이어그램 작성
5. SW 구현 시 필요한 적용 기술 스펙을 정의
UML(Unified Modeling Language): 객체 형태의 모델을 표현하는 언어 (p.25)
패키지 다이어그램: 관련 있는 요소들을 묶는 수단이 필요함. UML에서는 패키지를 사용해 클래스들을 그룹화함. (p. 28)
- 클래스 다이어그램의 클래스 간 관계를 고려해 서로 관련성이 높은 클래스들(즉, 클래스 간 응집력이 높은 것들)을 하나의 패키지로 묶어 표현한 것
- 전체 시스템을 상위 수준(혹은 서브 시스템 수준)에서 바라볼 수 있도록 지원함 -> 때문에 직관적으로 소프트웨어 구조를 이해하기 쉬움
- 추후 HW 장치에 SW를 할당(혹은 배치)하기 위한 기본 단위로 패키지를 사용함
패키지 다이어그램 작성 절차
1. 패키지 다이어그램을 작성할 대상물 선정 (도메인 클래스 다이어그램)
2. 클래스들의 관계를 고려하여 관련성이 높은 것들을 그룹핑해 패키지로 정의
- 일반화 관계: 해당 관계를 형성하는 모든 클래스는 하나의 패키지로 묶음
- 집합 관계: 해당 관계를 형성하는 모든 클래스는 하나의 패키지로 묶음
- 클래스의 의미적 속성: 클래스의 멤버 변수나 멤버 함수의 유사성을 고려하여 클래스를 패키지화할 것인지 결정함
3. 식별된 패키지에 적절한 명칭 부여 - 부여하기 어려운 패키지가 있다면 분리 가능성 고려
4. 패키지 간 관계 부여 - 서로 다른 패키지를 가로지르는 기존 클래스 간의 관계 타입을 고려하여 패키지 관계 결정
5. 패키지 관계 정의 - 다이어그램 프레임 사용하여 패키지 다이어그램 완성
계층화된 아키텍처 생성
- 소프트웨어 아키텍처: 소프트웨어를 구성하는 컴포넌트(구성 요소)와 이들 간의 관계를 체계화화여 표현
여기에는 3계층 아키텍처가 있음.
HCI(Human Computer Interaction) 계층: UI에 해당하는 클래스를 포함하는 계층
PD(Problem Domain) 계층: 분석 과정에서 도출된 도메인 클래스를 포함하는 계층
DM(Data Mainpulation) 계층: 파일 또는 DB table에 해당하는 데이터 클래스를 포함하는 계층
ex. p. 34
자료구조 설계
- 3계층 아키텍처에서 하위 계층 설계 시 필요
- 지속적으로 보관해야 하는 데이터를 유지관리하기 위해 필요함
- 파일 or DB table 설계
- PD 계층에 포함된 모든 클래스를 살펴봄
- 클래스 정보로부터 자료구조를 정의함
자료구조 설계 가이드
- 클래스 다이어그램으로부터 임시로 값을 저장하는 휘발성 변수 제거
- 모든 클래스를 하나의 DB table로 매핑
- 클래스의 멤버 변수는 테이블의 컬럼으로 매핑
- 클래스의 멤버 함수는 프로그램의 함수로 매핑 or DB의 저장형 프로시저로 매핑
- 일대일 관계에 있는 연관 관계 혹은 집합 관계를 테이블의 키 Key로 정의하는 컬럼 추가
- 다대다 관계에 있는 연관 관계 혹은 집합 관계에 대해 새로운 테이블을 생성하고, 관련된 클래스를 연결할 키를 저장하는 컬럼 생성
- 일반화 관계에 대해서는 하위 클래스의 대응 테이블에 키를 저장할 컬럼 추가 (p. 39)
- 위 규칙에 따라 DB table 구성
- 생성된 테이블에서 발생할 수 있는 이상 현상 anomaly 문제를 해결하기 위해 정규화 과정 거침
- 질의 처리에 대한 성능을 높이기 위해 인덱스 테이블을 구성하는 작업을 수행해 자료구조 설계 진행
인터페이스 설계 절차
1. 사용 시나리오(Use Scenario) 개발
- 시스템 사용자 입장에서 어떤 시나리오에 따라 시스템이 사용되는가를 기술한 것
- 사용자가 원하는 서비스를 수행하기 위해, 다수의 유스케이스와 연관성을 가짐
ex. 인터넷 쇼핑몰에서 특정 상품 주문 시 - 사용자는 검색 수행 후, 검색 결과에서 특정 상품의 상세 정보를 얻음
상품을 장바구니에 담거나 결제하여 구매하는 과정을 표현함
-> 이때 각 시나리오 스텝은 대응되는 유스케이스 시나리오 스텝과 연결됨
2. 인터페이스 구조 설계
- 도출된 모든 사용 시나리오의 각 스텝을 블록 다이어그램 형태로 도식화
- 윈도우 내비게이션 다이어그램 작성
ex. 쇼핑몰에서 제품 구매를 위한 윈도우 내비 다이어그램 (p. 43)
3. 인터페이스 프로토타입 개발 - 템플릿 기반으로 대상 시스템에 대한 인터페이스의 프로토타입을 개발함
4. 인터페이스 평가
- 개발된 프로토타입이 적절한지 평가를 거침
- 개발 팀 내부 평가 진행 후, 사용자 평가 혹은 시나리오 기반 평가 등
인터페이스 클래스 설계 (p. 46)
- 도메인 클래스의 모든 클래스에 대해 인터페이스 클래스로 정의함
- 한 클래스의 멤버 함수가 모두 프라이빗 메소드로 구성된다면, 별도의 인터페이스 클래스를 구성하지 않음
- 스테레오 타입 <<interface>>로 정의, 대응되는 도메인 클래스의 퍼블릭 메소드를 순수 가상 함수로 선언하여 포함함
- 인터페이스 클래스에 정의된 메소드는 사용자 인터페이스의 메뉴와 연결
- Java로 인터페이스 개발하는 경우, 인터페이스 클래스는 도메인 클래스와 상세화 관계를 형성
배치 다이어그램 (p. 49-52)
- 아키텍처에 나타난 모든 패키지 혹은 클래스를 플랫폼에 할당
ex. 클라이언트-서버 구조의 SW 시스템을 개발한다면, 어떤 패키지를 클라이언트에 배치하고 어떤 패키지를 서버에 배치할지 정하는 것
- 어떤 형태의 클라이언트-서버 형태로 구현하느냐에 따라 클라이언트 측에서는 UI 클래스만 탑재할 수도 있고, UI 클래스와 Data 클래스를 함께 탑재할 수도 있음
소프트웨어 시스템이 분산 환경(클라이언트-서버)에서 운영될 시,
서버 기반 모델, 클라이언트 기반 모델, 소형 클라이언트와 서버 모델, 강한 클라이언트와 서버 모델 중에서 어떤 모델이 가장 시스템 운영에 효과적인지 결정해야 함
배치 다이어그램 작성
노드: 실시간 계산하는 자원을 모델링함
- 메모리와 계산 능력을 가지고 있음
- CPU, 기기, 메모리 등을 구분하는 스테레오 타입을 가질 수 있음
- 산출물을 내포할 수 있음
관계: 통신 경로를 표현함 (선)
산출물
- 파일과 같은 물리적 개체를 모델링
- 사각형 모양과 <<artifact>> 키워드와 함께 사각형으로 표현함
- 노드 심볼 내에 산출물 심볼을 배치하여 진행 - DB, Web Page, 실행 가능한 개체, 스크립트 등이 될 수 있음
운영 플랫폼 선택 시 고려 요소
- 개발 비용 (HW 구매 비용 포함): 강한 클라이언트와 서버 모델이 상대적으로 높은 개발 비용 필요함
- 개발의 용이성: 윈도우 같은 개발 지원 도구가 용이함
- 보안 통제: 서버 기반 모델이 강화된 보안 메커니즘을 구현하는 데 용이함
- 확장성: 추후 사용자 증가 등에 대비하기 위해 통신 증가량을 고려한다면, 강한 클라이언트와 서버 모델이 상대적으로 유리할 수 있음
- 시스템 개발 초기에 정의한 비기능적 요구사항을 반드시 모두 고려하여 운영 플랫폼의 구졸르 선정하는 것이 좋음
- 운영 플랫폼을 결정했다면, SW 컴포넌트를 플랫폼에 배치
설계 단계의 마지막 활동: 기술 환경 명세 (HW 및 지원 DW에 대한 세부 사항을 명세, p. 55)