Design architecture

 

-Software Architecture

 

요구사항 분석에서 설계 단계로 가는 것은 그 반대와는 다르게 많은 창의성을 요구한다.

 

-정의

1) 설계유형(설계도) : 구조, 동작, 상호작용, 비기능적 속성

2) 설계 결정의 집합 : 분석에서 수집한 요구사항 목록, 모델은 큰 방향은 결정해주지만 빠진 부분들이 많다.

어떻게 채울 것인가-> 의사결정이 필요

설계할 때 하는 의사결정들의 집합.

 

-SA 예시1 : Windows MFC

Layered Architecture (계층 아키텍처) : 박스를 층층이 쌓아 놓은 것

 

Layered Architecture (계층 아키텍처)의 특징

: 바로 위,아래 박스로만 서로 호출, 리턴할 수 있는 관계

 

-SA예시2 : Android Apps

Component architecture (컴포넌트 아키텍처)

컴포넌트 : 스스로 자립해서 동작할 수 있는 모듈, 부품

 

 

Android 컴포넌트 4가지 타입

1) Activity : 화면

2) Service : 백그라운드 음악 재생

3) Broadcast Receiver : 문자 왔을 때 화면 위에 알림 메시지, 배터리 잔량 표시

4) Content Provider : 데이터베이스(주소록)

 

-SA의 장점

이것만 가지고도 어떻게 만들고 있는지 정확히 커뮤니케이션 할 수 있다.

 

 

-Architecture Design의 특징

1) 주요 요소들이 무엇이 있나, 어떻게 연결되어 있나 아키텍처에 잘 표현되어야 한다.

2) 설계, 개발, 유지보수에 도움이 된다.

3) 기능적 요구사항 뿐만 아니라 비기능적 요구사항(성능, 보안, ...)에도 큰 영향을 미친다.

 

Maintainability(유지보수)

회사에서 만들고 있는 모듈들 : C1, C2, C3, C4

만들고 싶은 기능들을 제3의 회사A(써드파티 컴포넌트)가 만들어 놓은 것이 있다.

그래서 구매해서 사용.

 

하지만 개발을 직접 하지 않았기 때문에 제3의 회사A가 망해버리면

다른 회사B 써드파티 컴포넌트를 사용한다.

그런데 A와 B는 기능적으로는 같지만 인터페이스가 다르다.

따라서 A회사 써드파티 컴포넌트에서 B회사로 바꾸는 유지보수 과정에서 인터페이스를 전부 바꿔야 한다.

 

이런 상황을 해결하기 위해

모든 컴포넌트들이 직접적으로 써드파티 컴포넌트에 의존하는 구조로 아키텍처를 만들지 않고 래퍼라는 자신의 회사가 만든 모듈에만 의존.

써드파티 컴포넌트가 바뀌면 래퍼만 변경.

=> 유지보수하기에 수월

 

 

-비기능적 요구사항을 만족시키기 위한 아키텍처 설계 방향

1) Performance(성능) : 중요한 operation들을 한 군데로 모으고 여러 모듈들 간의 커뮤니케이션을 최소화.

2) Security(보안성) : 계층 아키텍처를 사용하여 중요한 자산을 가장 아래쪽에 있도록.

3) Safety(안전성) : 생명에 영향을 미치는 기능들은 안전 검증 문제와 비용을 줄이기 위해 서브 시스템으로 몰아넣기.

4) Availability(24시간 이용가능성) : 모듈을 중복해서(redundant) 포함. 한 대가 고장나도 다른 한 대로 운영하면 되기 때문.

5) Maintainability(유지보수 가능성) :  작게 모듈화를 잘 하는 것. 모듈화가 잘 된 것들은 건들지 않고 새로운 것만 추가하는 식으로 할 수 있기 때문.

 

-SA예시 : Scalability(확장성) & Performance

이미지 호스팅 Application (ex instagram)

 

 

 

성능관련 : 업로드, 다운로드 2가지 서비스를 하는 모듈 -> 1가지씩 나눔

 

 

Availability관련 : redundancy시킴, 같은 일을 하는 모듈을 여러개 만듦.

 

성능관련 : 요청마다 다른 서버를 사용. ex) 유료고객에게 빠른 서버, 무료고객에게 최소한의 서비스만