1. 아키텍처 설계
아키텍처 품질 속성
품질 속성을 달성해야함
1) 시스템 품질 속성
•
가용성 : 실패 없이 동작할 수 있는 확률
•
변경 용이성 : 새로운 요구사항을 요청했을 때 얼마나 쉽게 변경할 수 있는지
•
성능
•
보안성
•
사용성
•
테스트 용이성
2) 비즈니스 품질 속성
•
시장 적시성
•
비용과 이익
•
예상 시스템 수명
•
목표 시장
•
신규 발매 일정
•
기존 시스템과의 통합
3) 아키텍처 품질 속성
•
개념적 무결성
•
정확성과 완전성
•
개발 용이성
아키텍처의 4+1 관점
관점 : 시스템을 이루는 요소의 집합과 그들의 연관 관계를 추상적으로 표현한 것이다.
소프트웨어 아키텍처는 UML의 4+1관점을 이용해 설명한다.
시나리오 관점
•
사용자가 인식하는 시스템의 기능
•
다른 4개 관점에서 사용되는 다이어그램의 근간이 됨.
•
설계자가 사용자와 대화하는 데 사용되어 유스케이스 다이어그램을 더 세부적으로 구체화해나간다.
•
정적 표현 : 유스케이스 다이어그램
•
동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램
논리적 관점
•
시스템의 기능을 제공하기 위해 필요한 클래스나 컴포넌트 및 이들의 관계에 초점을 둠
•
시스템 내부를 들여다 본다.
•
정적 표현 : 클래스 다이어그램, 객체 다이어그램
•
동적 표현 : 상태 다이어그램(클래스 내 동작 표현), 순차 통신 다이어그램 (클래스간 상호작용 표현), 활동 다이어그램 (클래스의 연산 동작 표현)
프로세스 관점
•
논리적 관점과 같이 시스템 내부를 들여다 보지만, 독자적인 제어 스레드를 가질 수 있는 클래스에 초점을 맞춘 것.
•
시스템의 동시성과 동기화에 관심이 있다.
•
동적 표현 : 시간의 흐름에 따른 변화를 표현하는 상태 다이어그램, 순차 다이어그램, 협동 다이어그램, 활동 다이어그램
•
시스템 구성 표현: 구현을 위해 컴포넌트 다이어그램과 배치 다이어그램을 사용해 시스템 전체 구성을 표현
개발 관점
•
소프트웨어 모듈이 서로 어떤 연관 관계가 있고 또 설계와 어떻게 연결 관계를 나타내는지에 관심이 있다.
•
정적 표현 : 컴포넌트 다이어그램
•
동적 표현 : 상태 다이어그램, 순차 통신 다이어그램, 활동 다이어그램
물리적 관점
•
시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점을 둔다.
•
정적 표현 : 배치 다이어그램
•
동적 표현 : 상태 다이어그램, 순차 다이어그램, 통신 다이어그램, 활동 다이어그램
아키텍처 스타일
1) 데이터 중심형 스타일
주요 데이터가 레포지토리에서 중앙 관리됨
시스템에서 공동으로 활용한 데이터가 레포지토리에 저장되고 서브시스템이 레포지토리에 정보를 요청해서 연산 후 저장
•
데이터를 일관성 있게 관리
•
서브시스템 추가가 쉬움
•
리포지토리 병목현상
•
리포지토리를 변경하면 서브시스템에 영향 줄 수 있다.
2) 클라이언트 - 서버 스타일
•
서버 특성 : 클라이언트의 요청 처리 위해 대기
•
클라이언트 특성 : 서버가 제공하는 서비스를 요청하는 서브시스템
•
씬 클라이언트 스타일 : 모든 응용 처리 및 데이터 관리가 서버에서 수행되며 클라이언트는 프레젠테이션 계층만 구현. 서버에 부하가 큰 것이 단점
•
팻 클라이언트 스타일 : 서버에서 데이터만 관리하고 어플리케이션 로직과 프레젠테이션의 많은 부분이 클라이언트 쪽에서 구현된다. 관리하기 복잡하고 어플리케이션이 출시되면 모든 클라이언트에 배포 및 설치해야 한다.
3) 계층 스타일
기능을 몇개의 계층으로 나누어 배치
•
프레젠테이션 계층 : 사용자와 만나는 화면, 프론트엔드
•
비즈니스 로직 계층 : 기능 요구사항을 구현하는 곳, 미들웨어, 어플리케이션 로직을 실행하고 어떤 형태의 데이터가 필요하고 반환될 것인지 결정한다.
•
데이터 계층 : 데이터베이스에 접근해 데이터 처리와 관리를 하며 필요한 데이터를 제공한다. 백엔드
4) MVC 스타일
모델 뷰 컨트롤러 세 부분으로 이루어진 구조
1.
사용자는 제어에게 자료를 요청하거나 처리할 데이터를 전송
2.
제어(Controller)는 이를 처리하기 위해 모델을 호출
3.
모델(Model)은 DBMS를 이용해 데이터베이스의 자료를 수정하고 결과를 제어에게 반환
4.
제어는 사용자가 요청한 결과를 모델로부터 가져와 뷰를 호출하고 결과를 전달
5.
뷰는 처리 결과를 여러 형태로 사용자에게 보여준다.
5) 데이터 흐름 스타일
필터에 해당하는 서브시스템이 하나의 데이터를 입력으로 받아서 처리한 후 결과를 다음 서브시스템으로 넘겨주는 과정을 반복한다.
데이터를 변환하는 시스템에서 주로 사용
필터와 파이프로 나누어 개발할 수 있기 때문에 동시에 개발이 가능하다는 것이 장점
•
필터 : 데이터 스트림을 하나 이상 입력받아 처리후 데이터 스트림 하나를 출력
•
파이프 : 필터를 거쳐 생성된 데이터 스트림 하나를 다른 필터의 입력에 연결
6) 아키텍처 스타일의 장점
•
개발 기간 단축 및 고품질 소프트웨어 생산
•
수월한 의사소통
•
용이한 유지보수
•
검증된 아키텍처
•
구축 전 시뮬레이션 가능
•
기존 시스템에 대한 빠른 이해
2. 클래스 간의 관계
연관 관계
•
양방향 연관 관계 : 가장 단순한
•
역할이 부여된 연관 관계 : 연관 관계에서 각자에게 역할 부여
•
다중 연관 관계 : 다중성을 표기
◦
관계에 숫자를 적는다.
◦
다수는 1..*로 표기한다.
•
단방향 연관 관계 : 서로 아는 관계가 아니라 한쪽만 아는 관계
•
연관 클래스 : 연관 관계를 구체적으로 나타내고 싶을 때 사용
◦
점선을 이용한다.
일반화 관계
공통점을 갖고 있는 여러 클래스를 묶어서 새로운 클래스를 만들고 공통적인 이름을 만드는 것
개별 클래스와 공통 클래스 사이의 is a kind of 관계가 성립
집합 관계
상위 클래스가 하위 클래스로 구성될 때, is composed of
합성 관계
집합 관계와 유사하지만 전체 객체에 완전히 종속되어 독립된 객체로 존재할 수 없다.
의존 관계
연관 관계와 유사
연관 관계는 상대 클래스를 인식하기 위해 멤버 변수를 갖고 있다. 반면 의존 관계는 상대의 메서드를 갖고 있다.
1.
메서드가 객체를 인자로 받아 메서드를 사용하는 경우
2.
메서드 내부에서 다른 클래스의 객체를 만들어서 메서드를 사용할 경우
실체화 관계
인터페이스를 이용해 추상 메서드를 정의하고 하위 클래스에서 구체적인 실현을 구현하는 관계
3. 클래스 설계 원칙
단일 책임 원칙
클래스를 변경해야 하는 이유는 단 하나여야 한다.
책임 : 변경하는 이유
모든 클래스는 하나의 책임을 갖고 클래스는 그 책임을 완전히 캡슐화하여 설계한다.
클래스 안에 2개의 책임이 있다면 응집력이 떨어지는 설계이다.
개방 폐쇄 원칙
변경에는 닫혀있어야 하고, 확장에는 열려 있어야 한다.
1.
계속 바뀌는 것이 무엇인지 찾는다.
2.
클래스에서 이들을 호출해서 사용하도록 한다.
•
변경에 닫혀 있는 설계 : 계속된 추가 사항이 있어도 그들 끼리만 추가할 수 있도록 설계해야지 원래 있던 클래스를 수정하게 만들면 안된다.
•
확장에 열려있는 설계 : 새로운 클래스를 쉽게 추가할 수 있는 구조로 설계해야 한다.
리스코프 교체 원칙
상위 클래스의 객체는 언제나 하위 클래스로 교체할 수 있어야 한다.
상위 클래스의 객체가 들어갈 자리에 하위 클래스의 객체를 넣어도 문제 없이 잘 작동한다. (같은 결과가 나온다)
피터 코드의 상속 규칙 : 하위 클래스는 상위 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행한다.
의존 관계 역전 원칙
클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다.
고수준의 구성 요소가 저 수준의 구성 요소에 의존하면 안된다.
인터페이스 분리 원칙
클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안된다.
단일 책임 원칙은 클래스의 단일 책임을 강조하고 클래스로 분리되어 메서드의 구현도 같이 분리된다. 반면에 인터페이스 분리 원칙은 인터페이스의 단일 책임을 강조하는 것으로, 인터페이스 부분만 분리하고 구현하는 부분은 그대로 남아있다.