3-4 아키텍처의 필요조건

소프트웨어 아키텍처란 소프트웨어 설계의 총괄적인 부분이면서 세부 사항을 포함하고 있는 틀이라고 필자는 정의한다.

http://www.ibm.com/developerworks/kr/library/feb06/eeles/index.html
(설명이 부족하여 링크를 첨부 한다, 우선 아키텍처란 구조이며, 이 구조는 다른 구조와의 연결이고, 이 관계이다, 소프트웨어 아키텍처란 각각의 시스템이고 이 시스템의 연결관계.. 뭐 구조이다.. 사실 정확하게 아키텍처에 대해서 정의하기 보다는, 세부 설계를 하기전 전체적인 틀이라고 생각된다.)


프로그램 구조
수천 개의 세목들이나 수 십 개의 모듈로부터 그림을 그린다면, 힘들지만, 이런것을 전체적인 틀을 만들고, 연관을 생각하며 그린다면 보다 편할것이다.
(물론 .. 이것도 힘들다.... 힘들다 그렇기 때문에 밤샌다.)

아키텍처는 결정된 최종 구조와 다른 대안들에 대한 이유를 설명해야 한다고 필자는 말하며, 한가지 비유를 든다.

- 비유 -
어떤 것에 대한 6살 짜리 꼬마에게 충분히 설명할 수 없다면, 정말로 이해하고 있는 것이 아니다.
- 알버트 아이쉬타인
(간담이 서늘해 지는 비유이다.. 아키텍처가 이해를 돕는것이 아니라, 이해된것을 증명하는 도구라고 나는 생각한다. 왜냐하면 이해가 되어야지만 도화지에 그림을 그릴수 있기 때문이다.)

변경 전략
아키텍처에서 변경사항이 나타날 경우, 아키텍처 변경시 이를 수용하는 방법에 대해서 명확히 언급해두어야 한다고 필자는 말한다.


구입 개발 결정
소프트웨어의 개발시 가장 빠른 방법은 구매하는것이다. 만약 아키텍처가 이미 있는 제품을 사용하는것이 아니라면, 이미 만들어져 있는 라이브러리를 능가하는 제품을 만들 수 있는 방법을 설명해야 한다.
(.. 예전에 봤던 어느 프로그래머의 이야기가 생각난다. 다른 사람이 만들어 놓은 코드가 있고, 그것에 문제가 없다면, 그냥 쓰는게 제일 좋다. 왜냐하면, 보다 좋은 프로그램을 짤수 있기 때문이다. 라는 이야기 였다.)


주요 데이터 구조
아키텍처는 사용 될 주요 파일, 도표, 데이터 구조에 대해 기술해야 한다.
1. 하나 이상의 모듈에서 데이터를 액세스 해서는 안된다.
2. 데이터 베이스에 엑세스 한다면 아키텍처는 그 데이터베이스의 구성과 내용을 명시해야 한다.
3. 데이터 보호에 대한 규칙이 고찰되어야 한다.

키 알고리즘
1. 어떤 키 알고리즘을 기초한다면 꼭 명시해야 한다.
2. 왜 사용하는지도 명시해야 한다.
3. 다른 알고리즘을 쓰지 않는 이유도 명시해야 한다.

주요 객체
1. 객체지향 시스템에서 아키텍처는 주요 객체를 기술해야 한다.
2. 클래스, 계층과 상태전이, 객체의 지속성에 대한 설명도 기술해야 한다.
3. 고려 대상이 됐던 다른 객체들과 선택된 구조를 선호하는 이유도 기술해야 한다.

일반적 기능성
1. 사용자 인터페이스
- 요구 분석시 명시 된다. 만약 없다면, 아키텍처에 기술되어야 한다. 이때 인터페이스는 출력과 연산과정에 영향을 주지 않도록 모듈화 되어야 한다.

2. 입력/출력
1. 현재 사용하게 될 구조와 향후 계획에 대해서 언급해야 한다.

3. 메모리 관리
1. 메모리 양을 추천해야 한다.

4. 문자열 기억 장소
1. 문자열 기억 장소는 대화식 시스템의 아키텍처에서 고려될 가치가 있다.
(게임의 경우 어마어마한 .. 문자열을 처리하기 위한 고려는 충분히 고려될꺼 같다)

예러 처리 : 현대 컴퓨터 과학의 가장 어려운 문제들중에 한가지라고 한다.
1. 에러처리가 수정을 포함하는가? 단지 검출만 하는가?
2. 에러 검출이 능동적인가? 수동적인가?
3. 프로그램은 에러 발생을 어떻게 전달 하는가?
4. 에러 메세지 처리에 대한 기준은 무엇인가?
5. 프로그램 내부의 어느 단계에서 에러를 처리하는가?
6. 입력데이터를 검증하는 각 모듈의 책임 단계는 무엇인가?
등등등을 고려해야 한다고 .. 필자는 설명한다.

견고성
에러 발생 후 계속 프로그램이 유지되는 능력을 말한다.

1. 오버-엔지니어링
프로그래밍은 어려 모듈로 만들어지게 되는데 어떤 모듈에서의 견고성이 제일 낮나다면, 프로그램은 전체적으로 경고성이 낮게 측정된다. 그렇기 때문에 아키텍쳐는 이 에러처리에 대해서 견고성을 매우 높게 만들거나, 현상자체를 막아야 한다.

2. Assertion 아키텍처는 프로그램이 사용할 assertion의 범위를 지정해야 한다.

3. 오류 방지 능력
아키텍쳐는 예측되는 고장 방지 능력을 기술해야 한다. ....


성능
성능이 고려사항이라면, 성능의 목표는 요구 분석에 기술되어야 한다.

일반적인 아키텍처의 질적 수준
좋은 아키텍처 스펙이란, 시스템 안의 모듈이나 각 모듈안에 수겨진 정보, 모든 가능한 설계 선택들을 포함하거나 제외한 설명에 의해 결정 된다.

아키텍쳐는 모든 주요 결정에 대한 동기를 기술해야 한다.
(왜 이런 결정을 내렸는지 주석을 달아야 한다는 것이다..)

예)
압둘은 어머님이 소금과 후추를 치고 양쪽을 자른 다음에 펜에 넣고 요리하라고 배웠다.
압둘의 아내 베스가 물었다.

베스 왈 : 왜 양쪽을 자르고 요리하죠?
압둘 왈 : 어머니가 그렇게 했으니까, 어머님게 여쭤 보겠소
어머님 왈 : 할머니가 그렇게 하셨으니, 할머님게 여쭤 보마
할머니 왈 : 난 너네가 왜 그렇게 하는지 모르겠구나, 난 후라이펜이 작아서 그랬던거야.
(... 주석의 필요성은 상상을 초월한다.)

좋은 소프트웨어 아키텍처는 언어와 기종에 독립적이다.
아키텍처는 시스템에 대해서 너무 자세히 설명되거나 그 반대가 되어서도 안된다.




............................
사실 이번 장은 너무 광범위하다. .. 어떻게 구조적으로 짜는지는 다자인 패턴을 통해서 공부 할수 있지만 디자인 패턴 역시 바로 읽고 이해할수 있는 수준이 아니다. 나의 가장 큰 문제는 경험이 적다는 것이고 두번째 문제는 이렇게 자세히 생각해볼 시간이 없다는것이고, 설계 자체를 할수 있는 위치도 아니라는것이다.

뭐 이런게 있으니, 실무에서 이런것을 배워야 겠구나.. 로 해석된다.