1과목 소프트웨어 설계 애플리케이션 설계 021 ~ 024

021. 소프트웨어 아키텍처

: 소프트웨어의 골격이 되는 기본 구조이자 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조

 

	상위 설계	하위 설계
별칭	아키텍처 설계, 예비 설계	모듈 설계, 상세 설계
설계 대상	시스템의 전체적 구조	시스템의 내부 구조 및 행위
세부 목록	구조, DB, 인터페이스	컴포넌트, 자료구조, 알고리즘

 

- 기본 원리

1) 모듈화 (Modularity): 시스템의 기능들을 모듈 단위로 나누는 것

** 모듈 : 분리된 시스템의 각 기능들. (서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등의 의미)

- 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 재사용성 향상.

- 기능의 분리가 가능하여 인터페이스가 단순해짐.

 

2) 추상화 (Abstraction): 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것.

추상화 유형 (제.과.자)

- 과정 추상화 : 자세한 수행과정 정의 X. 전반적 흐름만 파악

- 데이터 추상화 : 데이터의 세부적인 속성/용도 정의 X. 

- 제어 추상화 : 이벤트 발생의 정확한 절차/방법 정의 X.

 

3) 단계적 분해 (Stepwise Refinement): 문제를 상위 중요 개념으로부터 하위 개념으로 구체화시키는 분할 기법.

 

4) 정보은닉 (Information Hiding): 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법.- 모듈 독립적 수행 가능- 모듈 변경되더라도 다른 모듈에 영향 X.

 

- 소프트웨어 아키텍처의 품질 속성

1) 시스템 측면- 성능

- 변경 용이성

- 사용성

- 기능성

- 가용성

- 확장성

- 보안- 기타 속성 (테스트 용이성, 배치성, 안정성 등)(성능 좋은 폰으로 변경해서 용량이 사기가 확보됐다)

 

2) 비즈니스 측면

- 시장 적시성

- 비용과 혜택

- 예상 시스템 수명

- 기타 속성 (목표 시장, 공개 일정, 기존 시스템과의 통합 등)

 

3) 아키텍처 측면

- 개념적 무결성 : 전체 시스템 & 시스템 구성요소들 간의 일관성 유지

- 정확성, 완결성 : 요구사항 & 요구사항 구현 위해 발생하는 제약사항들 모두 충족

- 구축 가능성 : 모듈 단위 시스템을 적절하게 분배하여 유연하게 일정 변경 가능하도록

- 기타 속성 (변경성, 시험성, 적응성, 일치성, 대체성) 

 

- 소프트웨어 아키텍처 설계 과정

1) 설계 목표 설정

2) 시스템 타입 설정 : 대화형 시스템/ 이벤트 중심 시스템/ 변환형 시스템/ 객체 영속형 시스템

3) 아키텍처 패턴 적용

4) 서브시스템 구체화

5) 검토

 

022. 아키텍처 패턴 (아키텍처 스타일/ 표준 아키텍처)

: 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결방식 또는 예제. 

 

장점

- 시행착오 줄여 개발시간 단축/ 고품질 SW 생산

- 안정적인 개발 가능

- 의사소통 간편

- 시스템 구조 이해가 쉬워 개발에 참여하지 않은 사람도 손쉽게 유지보수 가능

- 시스템 특성을 개발 전에 예측 가능.

 

1) 레이어 패턴

: 시스템을 계층(Layer)으로 구분하여 구성하는 방법.

- 각각의 서브시스템들이 계층 구조를 이루고 하위 계층은 상위 계층에 대한 서비스 제공자가 됨. / 상위 계층은 하위 계층의 클라이언트가 됨.

- 변경 사항을 서로 마주보는 두 개의 계층만 변경하면 됨.

- 특정 계층만을 교체해 시스템 개선이 가능

- ex) OSI 참조 모델

 

 

2) 클라이언트 - 서버 패턴

: 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴.

- 사용자는 클라이언트와만 의사소통. 

- 서버는 클라이언트의 요청에 대비해 항상 대기상태 유지

- 클/서는 요청/응답을 위해 동기화 될 때 제외하고는 서로 독립적.

 

3) 파이프 - 필터 패턴

: 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴. 

- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이

- 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축 가능.

- 데이터 변환, 버퍼링, 동기화 등에 주로 사용.

- 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드가 발생.

- ex) UNIX의 쉘

 

4) 모델 - 뷰 - 컨트롤러 패턴

: 서브시스템을 3개의 부분으로 구조화하는 패턴

- 모델 : 서브시스템의 핵심 기능과 데이터를 보관

- 뷰 : 사용자에게 정보 표시

- 컨트롤러 : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령 보냄.

- 대화형 애플리케이션에 적합

- 각 부분은 별도의 컴포넌트로 분리되어 있어 서로 영향 없이 개발작업 수행 가능.

 

기타

5) 마스터 - 슬레이브 패턴

: 마스터  컴포넌트는 동일한 구조의 슬레이브 컴포넌트로 작업 분할 & 슬레이브  컴포넌트에서 처리된 결과물을 다시 돌려받는 방식.

- 장애 허용 시스템, 병령 컴퓨팅 시스템에서 주로 활용

 

6) 브로커 패턴

: 사용자가 원하는 서비스/특성을 브로커  컴포넌트에 요청 > 요청에 맞는  컴포넌트와 사용자 연결.

- 원격 서비스 호출에 응답하는  컴포넌트가 여러 개 있을 때 적합

- 분산환경 시스템에서 주로 활용

 

7) 피어 - 투 - 피어 패턴

: 피어를 하나의  컴포넌트로 간주/ 각 피어는 클라이언트 OR 서버가 될 수 있는 패턴.

- 멀티스레딩 방식 사용.

 

8) 이벤트 - 버스 패턴

: 소스가 특정 채널에 이벤트 메시지를 받아 발행하면 > 해당 채널을구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식.

- 주요  컴포넌트 : 소스 (이벤트 생성), 리스너 (이벤트 수행), 채널 (이벤트 통로), 버스 (채널 관리)

 

9) 블랙보드 패턴

: 모든  컴포넌트들이 공유 데이터 저장소 & 블랙보드  컴포넌트에 접근 가능 > 검색을 통해 블랙보드에서 원하는 데이터를 찾음.

- 해결책이 명확하지 않은 문제를 처리할 때 유용

- 음성 인식, 차량 식별, 신호 해석 등에 주로 활용

 

10) 인터프리터 패턴

: 프로그램 코드의 각 라인을 수행하는 방법 지정/ 기호마다 클래스 갖도록 구성

- 특정 언어로 작성된 프로그램 코드를 해석하는  컴포넌트 설계할 때 사용.

 

023. 객체지향 (Object-Oriented)

: 현실 세계의 개체 (Entity)를 기계의 부품처럼 하나의 객체로 만들어 기계적인 부품들을 조립하여 제품 만들듯 소프트웨어 개발에서도 객체들을 조립해서 작성할 수 있는 기법.

 

- 주요 구성 요소

1) 객체(Object)

: 데이터와 데이터를 처리하는 함수를 묶어놓은 하나의 소프트웨어 모듈.

• 데이터 : 객체가 가지고 있는 정보. (속성/상태/변수/상수/자료구조)
• 함수: 객체가 수행하는 기능 (메서드/서비스/동작/연산)

- 독립적으로 식별 가능한 이름

- 객체가 가질 수 있는 조건을 상태라고 한다.

- 객체와 객체는 상호 연관성에 의한 관계가 형성

- 행위 : 객체가 반응할 수 있는 메시지의 집합. 객체는 행위의 특징을 나타냄.

- 객체는 일정한 기억장소가 있음

- 객체의 메서드는 다른 객체로부터 메시지를 받았을 때 정해진 기능 수행

 

2) 클래스

: 공통된 속성과 연산(행위)을 갖는 객체의 집합. 

- 데이터를 추상화하는 단위.

- 인스턴스 : 클래스에 속한 각각의 객체.

- 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것.

- 최상위 클래스는 상위클래스 없는 클래스

- 슈퍼 클래스 : 특정 클래스의 상위(부모)클래스 & 서브클래스 ; 특정 클래스의 하위(자식) 클래스

 

3) 캡슐화 (Encapsulation)

: 데이터와 데이터를 처리하는 함수를 하나로 묶는 것.

- 캡슐화된 객체는 세부 내용이 은닉되어 외부에서의 접근이 제한적.

- 재사용이 용이

- 객체들 간의 메시지를 주고받을 때 세부 내용을 알 필요가 없으므로 인터페이스가 단순해지고, 객체간의 결합도가 낮아짐.

 

4) 상속

: 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것.

- 상위 클래스의 속성/연산을 다시 정의하지 않고서도 즉시 자신의 속성으로 사용 가능.

- 상속받은 속성/연산 외에 새로운 속성/연산 첨가 가능

- 재사용을 높인다.

- 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성/연산을 상속받는 것.

 

5) 다형성 (Polymorphism)

: 메시지에 의해 객체가 연산을 수행할 때 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력.

- 객체들은 동일한 메서드명을 사용하며 같은 의미의 응답을 함. 

- 오버로딩 : 메서드의 이름은 같지만, 인수를 받는 자료형과 개수를 달리하여 여러 기능을 정의할 수 있다.

- 오버라이딩 : 상위 클래스에서 정의한 메서드와 이름은 같지만 안의 실행코드를 달리하여 자식 클래스에서 재정의하여 사용.

 

6) 연관성

: 두 개 이상의 객체들이 상호 참조하는 관계.

- 연관화 (Association) : is a member of / 2개 이상의 객체가 상호 관련

- 분류화 (Classification) : is instance of / 동일한 형의 특성을 갖는 객체들을 모아 구성

- 집단화 (Aggregation) : is part of / 관련 있는 객체들을 묶어 하나의 상위 객체를 구성.

- 일반화 (Generalization) : is a / 공통적인 성질들로 추상화한 상위 객체를 구성하는 것

- 특수화/상세화 (Specialization) : is a / 상위 객체를 구체화하여 하위 객체를 구성하는 것. 

 

024. 객체지향 분석(Object Oriented Analysis) 및 설계

: 사용자의 요구사항을 분석하여 > 요구된 문제와 관련된 모든 클래스, 관련 속성/연산, 그들 간의 관계 등을 정의하여 모델링하는 작업. => 객체, 속성, 클래스와 관련.

 

- 방법론

1) 럼바우 방법 : 모든 SW 구성 요소를 그래픽 표기법을 이용해 모델링. (객.동.기)

- 객체 모델링 : 시스템에서 요구되는 객체 찾아 속성/연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시.

- 동적 모델링 : 상태 다이어그램을 이용. 시간의 흐름에 따른 객체들 간의 제어흐름, 상호작용, 동작 순서 등의 동적인 행위 표현.

- 기능 모델링 : 자료흐름도(DFD) 이용. 다수의 프로세스들 간의 자료 흐름을 중심으로 처리과정 표현.

 

2) 부치 방법 : 미시적 개발 프로세스 & 거시적 개발 프로세스 모두 사용. 클래스/객체들을 분석, 식별하고 클래스 속성/연산을 정의.

3) Jacobson 방법 : Use Case 강조하여 사용.

4) Coad & Yourdon 방법 : E-R 다이어그램 사용하여 객체 행위 모델링, 객체 식별, 구조식별, 주제 정의, 속성-인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 분석.

5) Wirfs-Brock 방법 : 분석-설계 간의 구분 X. 고객 명세서 평가하여 설계 작업까지 연속적으로 수행.

 

- 객체지향 설계 원칙 (SOLID)

1) SRP(Single Responsibility Principle) 단일 책임 원칙 

- 객체는 단 하나의 책임만 가져야 한다.

- 응집도는 높고, 결합도는 낮게 설계

 

2) OCP(Open-Closed Principle) 개방-폐쇄 원칙

- 기존 코드를 변경하지 않고, 기능을 추가할 수 있도록 설계

- 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화

 

3) LSP (Liskov Substitution Principle) 리스코프 치환 원칙

- 자식 클래스는 최소한 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다.

- 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다.

 

4) ISP (Interface Segregation Principle) 인터페이스 분리 원칙

- 자신이 사용하지 않는 인터페이스와 의존관계/영향 X

- 인터페이스가 갖는 하나의 책임.

 

5) DIP (Dependency Inversion Principle) 의존 역전 원칙

- 각 객체들 간의 의존관계가 성립될 때  > 추상성이 높은 클래스와 의존 관계를 맺어야 한다.

- 인터페이스를 활용하면 이 원칙이 준수된다.