XPACE

정의를 풀어 보면

1. S/W아키텍쳐 는 프로그램이나 컴퓨팅 시스템에 존재한다.

   제일 먼저 S/W 아키텍쳐는 프로그램이나 컴퓨팅 시스템과 관련되는 단어이다. 프로그램뿐 만아니라 칩에 녹아있는 프로그램들 임베디드 같은 곳에서도 논의되고 심지어 회로도에서도 이야기 될수 있는주제이다.

2. S/W아키텍쳐는 프로그램이나 컴퓨팅 시스템의 구조나 구조들을 의미한다. 시스템은 많은 구조를 갖는다. 아키텍쳐가 하나의 구조만을 갖는 것은 아니다. 아키텍쳐를 표현하기 위한 구조들의 후보 집합은 고정하거나 미리 예상할 수 있는 것이 아니다.
   • Runtime을 위한 구성요소나 그들의 관계는 : 전송 데이터, 상호 기동, 전달 신호(signal) process, tasks 등등
   • Non-runtime을 위한 구성요소나 그들의 관계는 : sub-module, 모듈간의 상속관계, 개발 팀별 구현 대상 할당 class, library 기타 등등

   이러한 구조를 이론적으로 3가지 종류로 구분한다.

   • Module structures : 이 구조에서 구성 요소는 모듈이라는 구현 단위이다. Module structure들은 시스템에서 필요한 코드 기반의 표현이다.
   • Component-and-connector structures : 시스템의 구성 요소는 실행 component와 connector이다. component는 컴퓨팅 단위이고 connector는 component간의 통신 경로이다.
   • Allocation structures : S/W 요소와 외부(non-software) 요소와의 관계를 보여준다. S/W는 하나나 그 이상의 외부 요소에서 만들(개발환경)어지고 실행(실행환경)된다.
3. 이 구조(들)은 S/W 구성요소들(조각), 구성요소들의 외부 속성(특성, 형태), 그리고 구성요소들간의 관계를 말한다.
   • S/W Elements : 이 단어가 처음에는 S/W Component 였다. 그런데 아마두 CBD와의 혼란때문에 또는 컴포넌트라는 단어의 복잡 다단한 정치적 의미때문인지는 몰라도 element로 변경되었다. 특이점은 size에 대한 언급이 없다. 따라서 시스템의 크기 관점에 따라 S/W element의 크기가 달라진다는 의미가 된다. 그래서 어떤 시스템에서는 서브시스템 구성도 정도가 되기도 하고 어떤 시스템에서는 개별 클래스 레벨에서 S/W아키텍쳐가 이야기된다. 사실 size에 대한 이야기는 잘 풀어가야할 숙제 중에 하나이다.
   • Externally Visible Properties : 하나의 구성요소는 다른 구성요소에 영향을 줌을 의미한다. 
     

     예를 들어: Service 제공, Performance 특성, 에러(fault) 제어, 공유 자원 사용 등을 의미하는데, 각 구성요소는 인터페이스를 통해서 다른 구성요소와 상호 작용한다.

     아키텍쳐는 분할된 구성요소에서 public side만을 고려한다. 반대로 보면 S/W아키텍쳐에서는 element 내부의 이갸기는 관심이 없다는 말이 된다. 그리고 S/W Element의 size를 어떻게 보느냐에 따라 visible prop는 크게 차이가 날 수 밖에 없다.

   • Relationships : S/W elements간의 관계를 의미한다. 그런데 이것 또한 element를 클래스로 보게 되면 그들 사이의 관계는 코드 상에서의 의존성에 치우치지만 거시적으로 보면 예를 들어 데몬, 연계 시스템들간의 관계등을 볼때는 통신 방법등에 집중하게된다. 어쨌거나 핵심은 S/W element에 대한 관점이다. 이점을 이해하면 S/W아키텍쳐 설계에 대해서 정확히 이해 할 수 있게 된다.

다른 정의들

http://www.sei.cmu.edu/architecture/definitions.html

• Scenario-based assessment

  시나리오 기반의 평가는 직접적으로 품질 요소(Quality Attribute)를 위해 정의된 Profile에 의존하여 평가하는 방식이다. 기술적으로 시나리오에 기반하고 있기 때문에 시나리오의 정밀함에 따라 평가 결과도 정밀해질 수 있다. ATAM이나 SAAM 등이 시나리오 기반의 평가 방법이다.

• Simulation-based assessment

  시뮬레이션 기반의 평가 방식은 간단하게 BMT를 연상할 수도 있다. 물론 시뮬레이션 기반의 방식은 일부 또는 추상화된 형태의 구현과 이를 기반으로 한 평가가 이루어진다.

• Mathematical model-based assessment

  수학적 모델을 기반으로 한 static 평가가 이루어진다. 기준의 모델을 기초로 다른 점들을 수치화하고 이를 기초로 평가하게 된다. 품질을 추정하는 데 사용될 가능성이 높다.

• Experience-based assessment

  제목 그대로 경험 기반의 평가 작업이다. 아키텍쳐 수립은 수학적인 활동과 예술적인 활동이 복합적으로 발생한다. 그래서 아키텍쳐 수립작업은 수학적 작업도 있지만 창조적/감각적으로 작업해야 하는 경우도 많다. 이런 감각적 작업에서 만들어진 결정들은 정량적인 분석이 어려운 경우가 많고, 품질을 평가하기 위해 정형화된 모델을 갖지 못하는 경우가 더 많다. 이러한 경우에 경험은 또 하나의 중요한 평가 수단으로 활용된다.

이러한 평가 방법들은 한가지만 사용되는 것이 아니라 복합적으로 적용되는 경향이 있다.

대표적인 평가 방법론

• Architecture Tradeoff Analysis Method(ATAM)
  • 시나리오 기반임
  • 모든 quality attributes를 평가함
  • 특히 다음 사항을 찾아내는데 중심을 둠
    sensitivity to various attributes exists
    quality attribute tradeoffs occur
  • 정량적/정성적 분석/평가를 수행함
  • 시스템의 quality attribute에 관심이 있는 모든 관련 당사자들을 평가에 참여 시킴
• Software Architecture Analysis Method(SAAM)
  • 단순하며, 시나리오 기반임
  • 주로 maintainability, modifiability, robustness,flexibility 등의 Quality에 관심을 둠
  • 주로 수정/변경에 필요한 리소스를 가정하고 이를 기반으로 평가함

1. 일련번호 채번은 개발 초기부터 중점 관리해야 한다.
2. 등록과 조회를 한 TX로 묶지 않는다.
3. 일괄 처리는 건수를 제한하고 가능한 한건씩 만 TX으로 묶는다.
4. 로그정책을 명확히 하고 디버그 로그량을 최소화 하며, 개발자들에게 로그가 성능에 미치는 영향을 인식 시킨다.
5. TP 서비스와 자바가 XA로 묶이는 경우 동일 TABLE을 Access하지 않도록 설계한다.
6. TX내에서 NONE-DB처리(파일,검색,SOCKET,압축 등)를 하지 않도록 한다.
7. 동적 SQL은 Query 튜닝을 어렵게 하는 경향이 있다.
8. TX 타임이 길다는 것은 Connection 점유시간과 Update Lock 타임이 길어 진다는 것을 의미한다.
9. 8번 상황에서 사용자가 동일 버튼을 중복 클릭시 Update Lock때문에 시스템에 부하를 가중시킬 수 있다.
10. WAS 인스턴스를 업무단위로 분리하지 말고, 전체 업무를 처리하는 인스턴스 수를 늘린다.(리소스 효율화)
11. TX 성격이 상이한 경우(long term vs short term) Connection Pool을 별도로 설정한다.
12. 대량의 로그를 생성하는 경우 단일 수행 시는 응답 속도가 빠르나, 부하가 증가할 경우 응답시간 지연의 원인이 된다.