아키텍처 설계와 클래스 설계

아키텍처 설계

아키텍처란

• 건물의 뼈대뿐 아니라 특성을 결정짓는 기본 구조를 일컫는 말
• 아키텍처는 모든 기술 분야에 적용할 수 있고 종류도 다양하다.

아키텍처의 필요성

복합성의 문제

• 대형 프로젝트는 전체 시스템의 구조를 생각하며 균형과 조화를 이루도록 설계
• 대형 프로젝트가 복합성의 문제를 해결하는 법은 아래와 같다.
• 개발할 소프트웨어의 전체적 구조를 가장 먼저 생각한다.
• 소프트웨어의 구조를 이루는 각 구성 요소를 찾는다.
• 각 구성 요소 간의 명확한 관계를 설정한다.
• 일정한 규칙을 따른다.

아키텍처의 필요성

• 복잡하고 규모가 큰 소프트웨어를 개발하려면 전체적인 구조가 유기적으로 잘 구성되어야 한다.
• 잘 정의된 구조의 품질 좋은 소프트웨어를 만드려면 소프트웨어 아키텍처가 필요하다.
• 아키텍처 설계로 소프트웨어가 어떤 구조이고 어떻게 동작할 것인지를 예측할 수 있으며, 변경에 유연하게 대처가 가능하다.

아키텍처의 특징과 기능

아키텍처의 특징

• 소프트웨어의 골격을 나타내는 추상화된 전체 구조를 제공
• 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룬다.
• 인터페이스를 통해 소프트웨어의 구성 요소가 어떻게 상호작용하는지를 정의
• 세부 내용보다는 중요 내용(설계자가 주관적으로 판단하고 결정)만 다르다.
• 설계에 적용되는 원칙과 지침이 있다.

아키텍처 설계 시 고려 사항

• 모든 이해관계자 사이의 의사소통 도구로 활용할 수 있어야 한다.
• 구현에 대한 제약 사항(개발 비용, 기간, 조직의 역량 등)을 정의해야 한다.
• 모든 이해관계자의 품질 요구사항을 반영해 우선순위에 따라 시스템 품질 속성을 결정해야 한다 (성능, 사용성, 보안성, 안전성, 검증 가능성, 변경 용이성 등)
• 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용할 수 있도록 설계해야 한다.

아키텍처의 기대 효과

• 소프트웨어의 기본 골격이 만들어져 개발에 참여하는 사람들의 이해의 폭이 넓어지며 구현상의 문제점을 도출할 수 있다.
• 소프트웨어 아키텍처를 기반으로 분할 방법을 찾고 구조화를 위한 구체적인 방안을 생각할 수 있다.
• 설계의 원칙과 가이드를 제공할 수 있고 설계를 재사용할 수 있다.
• 소프트웨어 아키텍처를 기준으로 개발 조직을 만들 수 있다.
• 전사 조직을 소프트웨어 아키텍처에 맞게 재편할 수 있다.
• 품질 특성에 대한 평가 방법을 결정할 수 있다.

아키텍처 품질 속성

품질 속성의 개요

• 사용성, 이식성, 유지보수 용이성과 같이 이해관계자의 요구사항과 관심사를 반영한 것이다.
• 품질 요구사항 : 이해관계자들이 아키텍처에 요구하는 수준의 품질 속성, 가능한 정확한 수치로 제시되는 것이 좋다.

품질 속성을 반영하는 법

• 해당 프로젝트에서 중요하게 생각하는 품질 속성을 결정한다.
• 결정한 품질 속성을 어느 정도 수준으로 설계할 것인지 목표를 설정한다.
• 설정한 목표를 달성할 수 있는 방법을 서술한다.
• 품질 속성을 평가할 방법을 서술한다.

시스템 품질 속성

• 가용성
• 변경 용이성
• 성능
• 보안성
• 사용성
• 테스트 용이성

비즈니스 품질 속성

• 시장 적시성
• 비용과 이익
• 예상 시스템 수명
• 목표 시장
• 신규 발매(공개) 일정
• 기존 시스템과의 통합

아키텍처 품질 속성

• 개념적 무결성
• 정확성과 완전성
• 개발 용이성(구축 가능성)

아키텍처 4 + 1 관점

• 4 + 1 관점은 크루첸이 1995년에 쓴 논문에 처음 등장한다.
• 문제 영역의 1개 관점(시나리오 관점)과 해법 영역의 4개 관점(논리적 관점, 프로세스 관점, 개발 관점, 물리적 관점)으로 이루어진다.

UML의 4 + 1 관점

시나리오(유스케이스) 관점

• 최종 사용자가 인식하는 시스템의 기능을 의미한다.
• 시스템이 사용자에게 제공하는 기능에 주목하는 관점이다.
• 기능 하나하나가 유스케이스로 표현되기 때문에 유스케이스 관점이라 할 수 있다.
• 사용 다이어그램은 정적 표현과 동적 표현으로 나뉜다.
• 정적 표현 : 유스케이스 다이어그램
• 동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램

논리적(디자인) 관점

• 시스템의 기능에 관심이 있는 유스케이스 관점과 달리 시스템 내부를 들여다본다.
• 시스템의 기능을 제공하기 위해 필요한 클래스나 컴포넌트 및 이들의 관계에 초점
• 사용 다이어그램은 정적 표현과 동적 표현으로 나뉜다.
• 정적 표현 : 클래스 다이어그램, 객체 다이어 그램
• 동적 표현 : 상태 다이어그램(클래스 내의 동작 표현), 순차 & 통신 다이어그램 (클래스 간 상호 작용 표현), 활동 다이어그램(클래스의 연산 동작 표현)

 

 

개발(구현) 관점

• 물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈(원시 코드, 데이터 파일, 컴포넌트, 실행 파일 등으로 구성)이 서로 어떤 연관 관계가 있고 또 설계와 어떻게 연결 관계를 나타내는지에 관심을 가진다.
• 마찬가지로 사용 다이어그램은 정적 표현과 동적 표현으로 나뉜다.
• 정적 표현 : 컴포넌트 다이어그램
• 동적 표현 : 상태 다이어그램, 순차 & 통신 다이어그램, 활동 다이어그램

 

 

물리적(배치) 관점

• 시스템에서 필요한 하드웨어 환경을 포함해 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점을 둔다.
• 마찬가지로 사용 다이어그램은 정적 표현과 동적 표현으로 나뉜다.
• 정적 표현 : 배치 다이어그램
• 동적 표현 : 상태 다이어그램, 순차 & 통신 다이어그램, 활동 다이어그램

 

 

아키텍처 스타일

아키텍처 스타일은 각각의 특징이 있고 해당 스타일마의 구성과 모양을 가지고 있다.

아키텍처 스타일의 분류

데이터 중심형 스타일

• 가장 큰 특징은 주요 데이터가 리포지토리에서 중앙 관리된다는 점이다.
• 리포지토리와 여기에 접근하는 서브시스템으로 구성된다.
• 시스템에서 공동으로 활용하는 데이터는 리포지토리에 보관한다.
• 대량의 데이터를 공유하는 은행 업무 시스템 등에 매우 유용하다.
• 서브시스템과 리포지토리의 결합도가 높아 리포지토리를 변경하면 서브 시스템에 영향을 줄 수 있다는 단점이 있다.

클라이언트-서버 스타일

• 네트워크를 이용하는 분산 시스템 형태로 데이터와 처리 기능을 클라이언트와 서버에 분할해 사용한다.
• 서버, 서비스, 클라이언트로 구성되며 서브시스템(컴포넌트)이 서비스를 서로 요청하면서 상호작용한다.

서버 특성

• 클라이언트(서브 시스템)에 서비스를 제공하는 역할을 하므로 클라이언트의 요청을 처리하기 위해 대기한다.
• 요청을 처리한 후에는 결과를 클라이언트에 회신한다.
• 프린트 서버, 파일 및 FTP 서버, 메일 서버 DNS 서버 등이 이에 해당한다.

클라이언트 특성

• 사용자와 대화하기 위해 서버가 제공하는 서비스를 요청(호출)하는 시스템이다.
• 메시지나 원격 프로시저 호출을 통해 서비스를 요청하고 서버가 이 요청을 받아 수행하면 그 결과를 클라이언트에게 전송한다.
• 클라이언트가 서버에 서비스를 요청할 때는 서버의 이름과 제공 서비스를 알아야 한다.
• 인터넷을 통해 웹서버와 통신해 웹 페이지를 다운로드하고 사용자에게 보여주는 웹브라우저가 해당된다.

씬 클라이언트 스타일

• 데이터 관리가 서버에서 수행되며 클라이언트는 프레젠테이션 계층만 구현
• 데이터 관리가 거의 필요 없는 애플리케이션이나 응용 처리가 거의 필요 없는 데이터 중심의 애플리케이션의 경우에 적합하다.
• 서버와 네트워크에 걸리는 부하가 큰 것이 단점이다.

팻 클라이언트 스타일

• 서버에서 데이터 관리만 관여하고, 애플리케이션 로직과 프레젠테이션의 많은 부분이 클라이언트 쪽에서 구현된다.
• 클라이언트에 더 많은 부하가 걸릴 수 밖에 없으므로 클라이언트 컴퓨터의 사양이 충분할 경우에 사용한다.
• 씬 클라이언트 스타일보다 관리하기가 복잡하고 새로운 버전이 출시되면 모든 클라이언트에 배포 및 설치해야 한다.

비중에 따른 클라이언트 서버 스타일

계층 스타일

• 기능을 몇 개의 계층으로 나누어 배치한다.
• DB를 많이 이용하는 소프트웨어는 3-계층으로 구성한다.
• 각 계층의 응집도는 높고 계층 간 결합도는 낮아 재사용 및 유지보수가 용이한 것이 장점이다.
• 계층 간 역할 분담이 명확해 각 계층을 쉽게 변경할 수 있다.
• 대부분의 운영체제와 통신 시스템이 계층 스타일을 이용한다.

프레젠테이션 

• 클라이언트 계층으로서 사용자와 직접 만나는 화면에 해당한다.
• 사용자 인터페이스를 지원하며 front-end라고도 한다.

비즈니스 로직 계층

• 기능 요구사항을 구현하는 곳으로 미들웨어라고도 한다.
• 애플리케이션 로직을 실행하고 또 어떤 형태의 데이터가 필요하고 반환될 것인지를 결정한다.

데이터 계층

• 데이터베이스에 접근해 데이터 처리와 관리를 하며 필요한 데이터를 제공한다.
• back-end라고도 한다.

계층 스타일

MVC스타일

• 구성요소를 기능별 또는 특성별로 명확하게 분리해 유지보수를 쉽게 하고 프로그램의 확장성과 유연성을 높인다.
• 모델, 뷰, 제어의 세 부분으로 이루어진다.
• 뷰와 모델을 독립적으로 분리해 변경에 대한 영향이 덜 미치도록 한 것이 장점이다.
• 약한 결합으로 설계하여 서로 영향을 덜 미치기 때문에 구조 변경을 요청할 때 수정하기가 쉽다.

MVC (Model, View, Controller)스타일의 사용 순서는 아래와 같다.

1. 사용자는 제어에게 자료를 요청하거나 처리할 데이터를 전송한다.
2. 제어는 이를 처리하기 위해 모델을 호출한다.
3. 모델은 DBMS를 이용해 DB의 자료를 수정하고, 그 결과를 제어에게 반환한다.
4. 제어는 사용자가 요청한 결과를 모델로부터 가져와 뷰를 호출하고 결과를 전달한다.
5. 뷰는 처리 결과를 여러 형태(테이블, 그래프, 엑셀 등)로 사용자에게 공개한다.

MVC 스타일

데이터 흐름 스타일

• 서브시스템이 하나의 데이터를 입력으로 받아서 처리한 후 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다.
• 일반적으로 데이터를 변환하는 시스템에 주로 사용하며, 전체 변환 작업은 독립적인 단계로 나눌 수 있다.
• 파이프와 필터를 조합해 만드는 아키텍처에 적합하고 사용자의 개입 없이 데이터 흐름이 전환되는 경우에 사용한다.
• 필터 또는 파이프 단위로 나누어 개발할 수가 있기 때문에 동시에 개발이 가능하다는 것이 장점이다.
• 필터 : 데이터 스트림을 하나 이상 입력받아 처리(변환)한 후 데이터 스트림 하나를 출력, 하나의 필터는 여러 포트로 데이터를 보낼 수 있다.
• 파이프 : 필터를 거쳐 생성된 데이터 스트림 하나를 다른 필터의 입력에 연결한다.

아키텍처 스타일의 장점

1. 개발 기간 단축 및 고품질의 소프트웨어 생산
2. 수월한 의사소통
3. 용이한 유지보수
4. 검증된 아키텍처
5. 구축 전 시뮬레이션 가능
6. 기존 시스템에 대한 빠른 이해

클래스 간의 관계

연관 관계

양방향 연관 관계

• 연관 관계에서는 역할을 부여할 수 있다.
• 물론 단순하게 표현하는 것도 가능하다.

역할이 부여된 연관 관계

다중 연관 관계

• 다중 관계는 다양하게 나올 수 있으며 선 위에 다중성을 표기해 나타낸다.
• 일 대 다 (1 : N) 관계의 예는 교수 1명이 여러 명의 학생을 가르치는 관계라 할 수 있다.
• 다 대 다 관계는 실제로 구현하기 어려우므로 일 대 다 관계를 변환해 사용한는 것이 좋다.

다중 연관 관계 예시

단방향 연관 관계

• 두 클래스가 서로 아는 관계가 아니고 한쪽만 아는 관계를 나타낸다.
• 두 클래스 간의 연결선이 방향성을 나타내는 화살표가 있는 직선 실선이다.

단방향 연관 관계

연관 클래스

• 연관 관계를 더 구체적으로 나타내고 싶을 대 클래스를 추가해 사용하는 것이다.
• 점선을 통해 나타내며, 일반 클래스처럼 다른 클래스와도 연관 관계를 맺을 수 있다.

일반화 관계

• 클래스에서 일반화 : 공통점을 가지고 잇는 여러 개의 클래스를 묶어서 새로운 클래스를 만들고 공통적인 이름을 붙이는 것이다.
• 일반화 관계는 상속 구조이며 하위 클래스는 상위 클래스의 모든 것(속성, 메서드)를 상속받아 사용한다.
• 아래에서 위로 추상화되는 것을 일반화, 반대로 위에서 아래로 구체화되는 것을 특수화라고 한다.
• 개별 클래스와 공통 클래스 사이에 ' is a kind of ' 관계가 성립되어야 한다.
• is a kind of 관계 : '사각형은 도형의 일종이다' , '원은 도형의 일종이다'

일반화(상속) 관계 예시

집합 관계

• 상위 클래스가 하위 클래스로 구성될 때의 관계로 'is composed of' 가 성립되어야 한다.
• is composed of 관계 : '컴퓨터는 모니터, 본체, 키보드로 이루어졌다'라고 할 때 말이 되는 관계다.
• 모든 객체가 별개의 생명주기를 가지고 있으며 각각 독립적으로 동작하기 때문에 약한 결합 관계다.
• 집합 관계에서 전체(컴퓨터)와 부분(모니터, 본체, 키보드)의 연결은 직선으로 하되 머리 부분은 속이 비어 있는 마름모 모양이다.

집합 관계의 예

합성 관계

• 집합 관계와 많은 부분이 유사하지만 전체 객체에 완전히 종속되어 독립된 객체로 존재할 수 없다는 것이 다르다.
• 모든 객체가 같은 생명주기를 가지고 있으므로 각각 독립적으로 동작할 수 없는 강한 결합 관계다.
• 전체와 부분의 연결은 직선으로 하되 머리 부분은 속이 채워진 마름모 모양이다.

합성 관계의 예

의존 관계

연관 관계와 의존 관계의 차이점

• 서로 상대의 클래스를 사용(참조)할 때의 관계를 클래스 A의 변화는 클래스 B의 변화로 연결되는 점에서 연관 관계와 유사하다.
• 연관 관계는 상대 클래스를 인식하기 위해 멤버 변수를 가진다.
• 의존 관계는 상대의 메서드를 가지고 있다. (상대의 메서드를 사용한다)

실체화 관계

• 특정 클래스에 기능을 추가하기 위해 메서드를 넣을 때 하위 클래스가 상속을 받아야 하는 사태가 발생한다.
• 인터페이스 클래스는 메서드의 공통 특성을 묶어 새로운 인터페이스 클래스를 만들고 이를 공통의 이름을 붙인다.
• 이 클래스는 변수를 정의할 수 없고, 추상 메서드를 가지며 이 메서드에 대한 구체적인 실현은 하위 클래스에서 구현된다.
• 스테레오 타입으로 <<>>를 사용하고 하위 클래스와의 연관은 일반화 관계와 다르게 점선으로 나타낸다.
• 화살표의 머리 부분은 하위 클래스에서 상위 클래스로 향하며 모양은 속이 빈 삼각형이다.

실체화의 예시

클래스의 설계 원칙

• SRP 단일 책임 원칙 : 클래스를 변경해야 하는 이유는 단 하나여야 한다.
• OCP 개방 폐쇄 원칙 : 변경에는 닫혀 있어야 하고, 확장에는 열려 있어야  한다.
• LSP 리스코프 교체 원칙 : 상위 클래스의 객체는 언제나 자신의 하위 클래스의 객체로 교체할 수 있어야 한다.
• DIP 의존 관계 역전 원칙 : 클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다.
• ISP 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안 된다.

 

이상으로 6단원 복습 포스팅을 마칩니다. 감사합니다.

 

참고자료

쉽게 배우는 소프트웨어 공학 2판 (6단원 아키텍처 설계와 클래스 설계)

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791156645429 

쉽게 배우는 소프트웨어 공학 - 교보문고