소프트웨어 아키텍처의 설계
소프트웨어 아키텍처 (Software Architecture) : 소프트웨어의 골격이 되는 구조, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템 구조(체)
- 비기능적 요구사항 반영 + 기능적 요구사항 구현방법을 찾는 해결 과정
- 애플리케이션ㅁ의 분할 방법, 분할된 모듈에 할당될 기능, 모듈간의 인터페이스 등을 결정
기본 원리 : 모듈화, 추상화, 단계적 분해, 정보은닉
모듈화(Modularity)
- 시스템의 기능들을 모듈 단위로 나누는것
- 프로젝트의 재사용성을 향상
- 모듈 크기 ↑ : 개수 ↑, 통합 비용 ↓
- 모듈 크기 ↓ : 개수 ↓, 통합 비용 ↑
추상화(Abstraction)
- 문제의 전체를 설계 후 세분화하여 구체화하는 과정
= 불필요한 부분을 생략하고 필요한 부분을 강조하여 모델화 하는 것)
- 완전한 시스템을 구축 전 유사한 모델을 만들어 여러 가지 요인들에대한 테스트 가능
- 최소 비용으로 실제 상황에 대처, 시스템의 구조 및 구성을 대략적으로 파악
- 추상화 유형
1) 과정 추상화 : 전반적인 흐름만 파악
2) 데이터 추상화 : 데이터의 세부사랑은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체
3) 제어 추상화 : 이벤트의 발생의 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체
단계적 분해(Stepwise Refinement)
- 문제를 상위 중요 개념으로부터 하위의 개념으로 구체화하는 분할 기법
- 추상화의 반복에 의해 세분화
- 점차적으로 구체화하며 상세한 내역은 가능한 뒤로 미루어 진행
정보은닉(information Hiding) = 캡슐화
- 한 모듈 내부에 포함된 정보들을 감추어 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 다른 모듈과 커뮤니케이션을 할 때는 필요한 정보만 인터페이스를 통해 주고받음
- 모듈을 독립적으로 수행하기 때문에 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수가 용이
소프트웨어 아키텍처의 품질 속성
- 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지하고 보장할 수 있게 설계되었는지를 확인하기 위해 품질 요소들을 구체화 시켜놓은 것
소프트웨어 아키텍처의 설계 과정
* 시스템 타입 유형
- 대화형 시스템, 이벤트 중심 시스템, 변환형 시스템, 객체영속형 시스템
아키텍처 패턴의 개요
아키텍처 패턴 : 아키텍처를 설계할 떄 참조할 수 있는 전형적인 해결 방식 또는 예제
- 기본적인 윤곽을 제시
- 서브시스템들과 그 역할이 정의, 그 사이의 관계와 여러 규칙 및 지치 등이 포함되어 있음
- 아키텍처 패턴의 장점 : 개발시간 단축,
고품질의 소프트웨어 생산가능,
검증된 구조로 작업을 하여 안정적인 개발 가능,
시스템 구조를 이해하기 쉬워 개발에 참여하지 않아도 유지보수가 쉬움
아키텍쳐 패턴 종류
- 레이어 패턴
- 클라이언트-서버 패턴
- 파이프 필터 패턴
- 모델 뷰 컨트롤러 패턴 등(MVC 패턴)
레이어 패턴 (Layers pattern)
- 시스템 계층(Layer)으로 구분하여 구성하는 방법
- 각각의 서브시스템들이 계층 구조를 이룸
- 상위 계층은 하위 계층에 대한 서비스 제공자, 하위 꼐층은 상위 계층의 클라이언트가 됨
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐(변경 사항 적용도 해당 > 변경작업 용이)
- 특정 계층만 교체해 시스템을 개선하느 것이 가능
- ex) OSI참조 모델
클라이언트-서버 패턴 (Client-Server pattern)
- 하나의 서버 컴포넌트와 다수 클라이언트 컴포넌트로 구성되는 패턴
- 사용자 > 클라이언트 > 서버 > 클라이언트 > 사용자
- 서버는 클라이언트의 요청에 대비해 항상 대기상태
- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적
파이프-필터 패턴(Pipe-Filter Pattern)
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
- 재사용성이 좋고 추가가 쉬워 확장이 용이
- 다양한 파이프라인 구축 가능
- 데이터 변환, 버퍼링, 동기화등에 주로 사용 ex)UNIX의 쉘
모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)
- 서브시스템을 3개의 부분으로 구조화하는 패턴
- 모델 : 서브시스템의 핵심 기능과 데이터 보관
- 뷰 : 사용자에게 정보 표시
- 컨트롤러 : 사용자로부터 받은 입력 처리
- 각 부분은 별도로 분리되어 있어 서로 영향을 받지 않고 독립적인 개발 작업 수행
- 여러 개의 뷰를 만들 수 있어 한 개의 모델에 여러개의 뷰를 ㅍㄹ요로 하는 대화형 애플리캐이션이 적합
기타 패턴
| 마스터-슬레이브 패턴 | 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는방식 |
| 브로커 패턴 | 사용자가 서비스와 특성을 브로커 컴포넌틍에 요청하면 브로커가 요청에 맞는 컴포넌트를 연결 |
| 피어-투-피어 패턴 | 피어를 하나의 컴포넌트로 간주하여 각 피어는 클라이언트 또는 서버가 될 수도 있음 |
| 이벤트-버스 패턴 | 소스가 특정 채널에 이벤트 메세지를 발행하면 해당 채널을 구독한 리스너들이 메세지를 받아 이벤트를 처리하는 방식 |
| 블랙보드 패턴 | 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능하여 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음 |
| 인터프리터 패턴 | 프로그램 코드의 각 라인을 수행하는 방법을 지정하고 기호마다 클래스를 갖도록 구성 |
객체지향
- 현식 세계의 개체를 기계의 부춤처럼 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 객체를 조립하여 작성할 수 있는 기법
- 구조적 기법의 문제점을 해결하기 위해 사용
- 소프트웨어의 재사용 및 확장이 용이하며 고품질의 소프트웨어를 빠르게 개발할 수 있어 유지보수가 쉬움
- 복잡함 구조를 단계적이고 계층적이게 표현
- 멀티미디어 데이터 및 병렬 처리 지원
- 구성 요소 : 객체, 클래스, 캡슐화, 상속, 다형성
객체 (Object)
- 데이터와 데이터를 처리하는 함수를 묶어 캡슐화한 하나의 소프트웨어 모듈
- 데이터 : 객체가 가지고 있는 정보 ( = 속성, 상태, 변수, 상수, 자료 구조)
- 함수 : 객체가 수행하는 기능으로 데이터를 처리하는 알고리즘(= 메소드, 서비스, 동작, 연산)
- 객체의 메소드는 다른 객체로부터 메세지를 받았을떄 정해진 기능을 수행
객체의 특성
- 객체는 독립적으로 식별 가능한 이름을 가지고 있음
- 객체의 상태는 시가네 따라 변함
- 객체 간의 상호 연관성에 의해 관계 형성
- 객체가 반응할 수 있는 메세지의 집합을 행위라고 하며 객체는 행위의 특징을 나타낼 수 있음
- 객체는 일정한 기억 장소를 가지고 있음
클래스(Class)
- 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미
- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
- 인스턴스 : 클래스에 속한 각각의 객체
- 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것
- 슈퍼 클래스 : 특정 클래스의 부모(상위) 클래스
- 서브 클래스 : 특정 클래스의 자식(하위) 클래스
- 최상위 클래스 : 상위 클래스를 갖지 않는 클래스
- 동일한 클래스에 속한 인스턴스들은 공통된 속성과 행위를 가지고 있으면서 속성에 대한 정보가 다르기 때문에 동일 기능을 하는 여러가지 객체를 나타내게됨
캡슐화(Encapsulation)
- 데이터와 함수를 하나로 묶은 것
- 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적이기 때문에 외부에서 변경하기 어려움
상속(Inheritance)
- 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 하위 클래스는 부모 클래스의 모든 속성과 연산을 다시 정의하지 않고 사용할 수 있으며 상속받은 속성 외에 새로운 속성과 연산을 첨가하여 사용 가능
- 객체와 클래스의 재사용을 높이는 중요한 개념
- 다중상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것
다형성(Ploymorphism)
- 메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메세지에 대해 각각의 클래스가 가지고 있는 고유한 특성으로 응답할 수 있는 능력
- 객체들은 동일한 메소드명을 사용, 같은 의미의 응답을 함
- 객체지향의 오버로딩 개념
Ex) '+' 연산자의 경우 숫자 클래스에선 덧셈, 문자 클래스에선 문자열 연결의 기능으로 사용된다
모듈(Module)의 개요
- 모듈 : 모듈화를 통해 분리된 시스템의 각 기능들
- 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용
- 단독으로 컴파일 가능하며 재사용 할 수 있음
- 각 모듈의 기능이 서로 독립적이고 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함
- 독립성이 높을수록 모듈을 수정해도 다른 모듈에 영향이 없어 오류가 발생해도 쉽게 해결 가능
- 결합도 ↓, 응집도 ↑, 모듈의 크기 ↓= 모듈의 독립성 ↑
결합도 (Coupling)
- 모듈 간에 상호 의존도 또는 모듈 사이의 연관 관계
- 결합도와 품질은 반비례 관계
- 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움
응집도
- 정보 은닉 개념을 확장한 것으로 모듈의 내부 요소들의 서로 관련되어 있는 정도
- 모듈이 독립적인 기능으로 정의되어 있는 정도
- 응집도와 품질은 비례 관례
★ 팬 인/아웃 ★
- 팬 인 : 호출하는 모듈의 수
- 팬 아웃 : 호출되는 모듈의 수
공통 모듈의 개요
- 공통모듈 : 여러 프로그램에서 공통적으로 사용할 수 있는 모듈
- 자주 사용되는 계산식이나 매번 필요한 사용자 인증같은 기능들이 공통 모듈로 구성될 수 있음
- 공통 모듈의 명세 기법 : 정확성, 명확성, 완전성, 일관성, 추적성
재사용
- 비용과 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 개발에 사용하기 적합하도록 최적화 시키는 작업
- 재사용되는 대상은 외부 모듈과의 결합도는 낮고 응집도는 높아야함
효과적인 모듈 설계 방안
- 결합도는 줄이고 응집도는 높여 모듈의 독립성과 재사용성을 높임
- 하나의 입구와 하나의 출구를 가져야 함
코드
코드의 개요
- 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위해 사용되는 기호
- 코드의 기능 : 식별 기능 , 분류 기능 , 배열 기능
코드의 종류
| 순차 코드 | 일정 기준에 따라 최초의 자료부터 일련번호를 부여하는 방법 |
| 블록 코드 | 대상 항목에서 공통적인 것을 블록으로 구분하고 블록 내에 일련번호를 부여하는 방법 |
| 10진 코드 | 대상 항목을 0~9까지 10진 분할하고 다시 각가에 대하여 10진 분할을 필요한 만큼 반복하는 방법 |
| 그룹 분류 코드 | 일정 기준에 다라 대분류, 중분류, 소분류 등으로 구분하고 그룹 안에서 일련번호를 부여하는 방법 |
| 연산 코드 | 항목의 명칭이나 약호와 관계있는 숫자, 문자, 기호를 이용하여 코드를 부여하는 방법 |
| 표의 숫자 코드 | 항목의 성질(길이, 넓이, 부피 등)의 물리적인 수치를 그대로 코드에 적용시키는 방법 |
| 합성 코드 | 하나의 코드로 수행하기 어려운경우 2개이상의 코드를 조합하여 적용시키는 방법 |
코드 부여 체계
- 코드(이름)만으로도 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
- 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야함
디자인패턴
디자인패턴의 개요
- 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
- 개발 과정에 문제가 발생 시 새로 해결책을 구상하기보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더욱 효율적임
- 재사용할 수 있는 기본형 코드들이 포함되어 있음
생성 패턴
- 객체의 생성과 참조 과정을 샘플화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램의 유연성을 더함
| 추상 팩토리 | 구체적인 클래스에 의존하지 않고 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현 |
| 빌더 | 작게 분리된 인스턴스를 건축하듯이 조합하여 객체 생성 |
| 팩토리 메소드 | 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴 |
| 프로토타입 | 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 |
| 싱글톤 | 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할수는 없음 |
구조 패턴
- 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
| 어댑터 | 호환성이 없는 클래스의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴 |
| 브리지 | 구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴 |
| 컴포지트 | 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴 |
| 데코레이터 | 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴 |
| 퍼싸드 | 복잡한 서브 클래스들을 피해 더 상위 인터페이스를 구상함으로써 서브 클래스의 기능을 간편하게 사용할수 있도록 하는 패턴 |
| 플라이웨이트 | 인스턴스가 필요할 때마다 생성하는 것이 아닌 공유해서 사용함으로써 메모리를 절약하는 패턴 |
| 프록시 | 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴 |
행위 패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의한 패턴
| 책임 연쇄 | 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴 |
| 커맨드 | 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 |
| 인터프리터 | 언어에 문법 표현을 정의하는 패턴 |
| 반복자 | 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴 |
| 중재자 | 수많은 객체들 간의 복잡한 상호작용을 캡슐화 하여 객체로 정의하는 패턴 |
| 메멘토 | 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴 |
| 상태 | 객체의 상태에 따라 동일한 동작을 다르게 처리해야할때 사용하는 패턴 |
| 전략 | 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴 |
| 템플릿 메소드 | 상위 클래스에서 골격을 정의하고 하위 클래스에서 처리를 구체화하는 구조의 패턴 |
| 방문자 | 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도로 클래스로 구성하는 패턴 |
'정보처리기사 > 소프트웨어 설계' 카테고리의 다른 글
| 소프트웨어 설계 4장 인터페이스 설계 요약 1)시스템 인터페이스, 미들웨어 (0) | 2022.04.22 |
|---|---|
| 소프트웨어 설계 2장 화면 설계 요약 1) UI 설계, UI 프로토 타입 (2) | 2022.04.13 |
| 소프트웨어 설계 1장 요구사항 확인 요약 3)요구사항, UML (0) | 2022.04.12 |
| 소프트웨어 설계 1장 요구사항 확인 요약 2) 스크럼, XP(eXtreme Programming) (0) | 2022.04.12 |
| 소프트웨어 설계 1장 요구사항 확인 요약 1) 소프트웨어 생명 주기 모형 (0) | 2022.04.12 |