본문 바로가기

아키텍처

[SA강좌] Part 3-13 아키텍트의 의사 결정 항목 아키텍트의 의사 결정 항목 아키텍처가 결정해야 할 항목을 정의한다. J2EE에 대한 의사 결정 항목 그림 Ⅲ-41. JE22에 대한 의사결정 항목 성능에 대한 의사 결정 항목 Resource Demand Increase Computation Efficiency Reduce Computational Overhead Maintain Event Rate Control Frequency of Sampling Resource Management Introduce Concurrency Maintain Multiple Copies Increate Available Copies Resource Arbitration Scheduling Policy 가용성에 대한 의사 결정 항목 결함 검출 Ping/echo Heartbe.. 더보기
[SA강좌] Part 3-12 소프트웨어 아키텍처 설계 산출물 관계 소프트웨어 아키텍처 설계 산출물 관계 소프트웨어 아키텍처 설계 및 구현 산출물은 크게 두 개의 주요 카테고리로 구분할 수 있다. 이 두 개의 주요 카테고리는 요구사항 정의와 소프트웨어 아키텍처로 나뉜다. 요구사항 정의는 기능적 요구사항과 품질적 요구사항으로 나눌 수 있다. 요구사항 정의의 요구사항들을 살펴보면, 기능적 요구사항은 세가지(required, preferred, optional)의 우선순위로 분류가 된다. 품질적 요구사항은 시나리오 이력(profile)로 기술된다. 여기서 소프트웨어 아키텍처는 네 가지의 산출물로 구성된다. 소프트웨어 아키텍처는 시스템 컨텍스트, 아키텍처스타일, 아키텍처 스트럭처와 설계 의사결정으로 구성된다. 먼저 시스템 컨텍스트는 소프트웨어 시스템의 인터페이스가 컨텍스트로 정.. 더보기
웹기반 정보시스템 구축시에 꼭 필요한 다이어그램... 웹기반 시스템의 경우에는 아무리 간단하다고 하더라도... 구현관점이나 배치관점에서의 다이어그램을 명쾌하게 그려주는 것이 좋다. 컴포넌트 다이어그램이나 배치 다이어그램과 같은... ~.~ 웹시스템의 특성상... 유스케이스를 기반으로... 시퀀스와 액티비티 다이어그램을 그리면... 거의 대부분의 환경을 기술할 수 있다. 설계시에도... 가능한 단순하게 하며... 클래스가 명확히 필요한 영역에서만 클래스 다이어그램을 기술하는 것이 좋다. 그리고, 웹의 특성상 이벤트가 많이 발생하므로... 상호작용 다이어그램을 알차게 그린다면... ~.~ 웹기반 정보시스템에 대한 알찬 기술이 될것이다. 더보기
다이어그램의 활용범위... 아주 간단한 시스템의 경우에는 UML 다이어그램중에 어떤 것을 가장 필수적으로 그려야할까? 4+1 관점에서 살펴본다면 다음과 같이 구분할 수 있지 않을까 한다. 간단한 시스템의 경우... 대부분이 배치관점이나 구현관점이 단순해지므로... 굳이 이 부분의 다이어그램을 그릴 필요는 없다. 유스케이스 다이어그램과 설계시에 필요한 상호작용 다이어그램 정도만 그리면 깔끔하다. 사실상... 설계관점에서의 클래스 다이어그램이 사용되는 경우가 거의 없다면 이 부분도 생략하는 것이 좋다. 다만... 여기에... 이벤트나 반응성이 강한 내용이 첨가된다면... 가볍게.. 상태차트 다이어그램정도 추가하면 좋다. 정말로... 4+1 View 관점에서 전체 다이어그램을 다 그릴 정도로 분산환경이 복잡한 경우에나 필요한 것이지. .. 더보기
[SA강좌] Part 3-11 품질 요구사항 구조적 그룹핑 품질 요구사항 구조적 그룹핑 지금까지 소프트웨어 아키텍처를 아키텍처 관점에서 품질요구사항을 파악하여 최대 만족을 하고 반면에 도메인 기능적 변경이 최소화 되도록 아키텍처 전이 과정의 네 가지 카테고리를 살펴보았다. 결론은 각 아키텍처 전이 단계의 최종 활동은 divide-and-conquer 원칙을 적용한 품질 요구사항을 적용시키는 것이다. 시스템레벨에서 품질 요구사항은 시스템을 구성하는 서브시스템이나 컴포넌트로 재구성된다. 따라서 한가지 품질요구사항(X)은 X를 만족하기 위하여 여러 개의 컴포넌트(n)으로 재구성된다고 말할 수 있다. 그림 Ⅲ-39는 이러한 설계 결정물과 관련한 계층 관계를 도식화한 것이다. 그림 Ⅲ-39. 소프트웨어 아키텍처 전이 과정 구성요소 소프트웨어 아키텍처 전이 단계 동안의 산.. 더보기
[SA강좌] Part 3-10 아키텍처, 설계 패턴 적용 아키텍처 패턴 적용 아키텍처 스타일 적용은 소프트웨어 아키텍처를 전이하는 방법이며, 아키텍처의 품질요소를 개선하는 것이다. 두 번째 카테고리인 아키텍처 패턴 또는 아키텍처 메커니즘은 일반적으로 동시성 또는 지속성과 같은 기능화 측면을 다루기 위하여 어떻게 시스템을 특성화시킬 건지 규칙을 아키텍처에 적용한 것이다. 아키텍처 패턴은 아키텍처의 기능적 컴포넌트를 재구성화하는 것이 아니라, 오히려 기능적 컴포넌트를 변경하고 확장시키는데 초점이 있다. 따라서 이 패턴으로 필요한 기능을 담은 새로운 컴포넌트를 추가 또는 변경하는 과정이다. 아키텍처 패턴은 소프트웨어 아키텍처 또는 그 영향을 받는 컴포넌트에서 컴포넌트의 기능을 제한하고 동일한 기능을 수행하는 또 다른 아키텍처 구조상 패턴을 적용 또는 사용을 막는다... 더보기
소프트웨어아키텍처 입문... 델파이 연합 세미나 1시간짜리용 PT자료.. ~.~ 입문자료용으로 만든것인데... 원래 4시간짜리를 1시간짜리로 줄일려고 하니... 조금 이상한 모양이 되어버린듯. 흠... 머 좌우당간... 더보기
[SA강좌] Part 3-9 아키텍처스타일 적용 아키텍처 스타일 적용 소프트웨어 아키텍처 전이과정의 첫 번째 카테고리는 소프트웨어 아키텍처상 아키텍처 스타일의 적용과 관련이 있다. 이 카테고리는 아키텍처의 완전한 재구조화 과정이 된다. 따라서 모든 아키텍처 컴포넌트에 영향을 미치며 컴포넌트상의 기능적 재조정이 함께 적용되는 재구조화가 이루어진다. 따라서 컴포넌트 사이간 원래의 커넥션(연결점)이 영향을 받으며, 결과적으로는 아키텍처 스타일 적용이 대규모로 아키텍처 전반에 대한 영향을 미치는 전이 과정이 이루어진다. 여기서 아키텍처 스타일에 대한 가장 기본적인 스타일에 대해서 표로 정리해 보았다. 표 Ⅲ-12. 아키텍처 스타일 스타일 특징 Pipes and filters 파이프 및 필터 스타일은 화학공장에서 사용되는 정제탑을 생각하면 된다. 필터는 재료에.. 더보기
[SA강좌] Part 3-8 소프트웨어 아키텍처 상세화 소프트웨어 아키텍처 상세화 본 절차에서는 네 가지 형태의 아키텍처 전이 절차에 대해서 살펴볼 것이다. 아키텍처 전이는 시스템의 특성을 변화시키기 위하여 사용된다. 소프트웨어 아키텍처 개발 단계는 기능중심 아키텍처 설계 단계, 아키텍처 평가단계, 아키텍처 전이 단계로 구성된다. 첫 번째 기능중심 아키텍처 설계 단계에서는 도메인 분석을 기반으로 하여 설계를 진행하며, 소프트웨어 아키텍처 평가단계에서는 품질요소에 따른 요구사항과 비교하여 네 가지 방법 중 소프트웨어 아키텍트가 비교방법을 선택하고, 품질요소에 맞게 시나리오 프로필을 소프트웨어 아키텍처와 데이터 검증 및 시나리오 검증을 통하여 평가하게 된다. 마지막으로 소프트웨어 아키텍처 전이단계는 소프트웨어 엔지니어가 아키텍처를 분석하고 아키텍처 특성에 무슨 .. 더보기
도공과 아키텍트 "자신의 작품에 이름을 새길 떄에는 다음과 같은 조건을 갖추어야 한다. 태도(殆土)를 빚는 데서부터 그릇이 완성될 때까지의 과정 , 즉 풀레작업, 그림 작업, 가마에서의 소성작업은 모두 스스로 해야 한다. 자기 가마를 가지고 있는 이상 , 이중에 어느 한 과정이라도 타인에게 맡기면 안된다." - 기타오지 로산진, 1933년 - 로산진은 한가지 작업만 했다고 하네요. 고용한 도공이 다 만들어 놓으면, 작품에 도장 찍기가 자신의 유일한 작업이었다는... 그러면서도... 로산진의 경우에는 평가가 극과 극을 달린다고 합니다. 자기손으로 흙을 묻히지는 않지만... 그는... 정말 탁월한 그릇디자이너 였다는 점입니다. 그의 디자인이 무명의 도공의 손에 의해서 완성되었고. 남들이 시도하지 않은 파격적인 디자인까지.... 더보기