꿈꾸는자의 생각의 파편들... :: '소프트웨어아키텍처' 태그의 글 목록 (4 Page)

달력

10

« 2018/10 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  

아키텍트의 의사 결정 항목

아키텍처가 결정해야 할 항목을 정의한다.

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
    • Heartbeat
    • Exception
  • 결함 복구
    • Voting
    • Active redundancy
    • Passive redundancy
    • Spare
    • Shaow operation
    • State resynchronization
    • Checkpoint/rollback
  • 결함에서 보호
    • Removal from service
    • Transactions
    • Process monitor

유지보수성에 대한 의사 결정 항목

  • 수정 사항을 국지화
    • Maintain semantic coherence
    • Antipate expected changes
    • Generalize the module
    • Limit possible options
  • Prevent Ripple Effects
    • Hide information
    • Maintain existing interfaces
    • Restrict communication paths
    • Use an intermediary
  • Deffer Binding Time
    • Runtime registration supports
    • Configuration files
    • Polymorphism
    • Component replacement
    • Adherence to defined protocols

보안에 대한 의사 결정 항목

  • 보안 원칙
    • Authentication
    • Authorization
    • Integrity
    • Availability
    • Confidentiality
    • Auditing
    • Nonreputation
  • 추가적인 보안 특성
    • Secure Single Sign-On
    • Merged audit logs and log analysis
    • Secure administration
    • Session protection
    • Uniform security granularity
  • Authentication
    • User IDs and Password
    • Tokens
    • Biometric Schems
    • Authentication Infrastructures
  • Authorizatiuon
  • Access Control
    • Mandatory Access Control
    • Discretionary Access Control
    • Role-based Access Control
    • Access Control Roles
  • 보안 아키텍처 패턴
    • Entity
    • Context Holder
    • Service Provider
    • Channel Elements
    • 플랫폼
  • 암호화
    • 대칭 암호화
    • 비대칭 암호화
    • 암호화 모드
    • 난수 발생 방법
    • Cryptographic Hash Functions
    • 전자 인증
    • 전자 서명
    • 관리
    • 암호 해석
  • Trusted Code
    • Java Sandbox
    • Microsoft Authenticode
    • Internet Explorer Zones
    • Self-Extracting Package
  • Secure Communication
    • Secure Communication 구조
    • Secure Socket Layer
    • IPSec
  • Middleware 보안
    • Infaliability 대한 가정
    • J2EE 보안
  • 웹에 대한 보안
    • 웹에 대한 보안 이슈
    • 어플리케이션 보안에 대한 선택 사항
    • 클라이언트에 대한 보안
    • 컨넥션에 대한 보안
    • 웹서버 호스트에 대한 보안
    • 웹서버에 대한 보안
  • 어플리케이션 보안
    • OS 대한 보안
    • 네트워크에 대한 보안
  • 데이터베이스 보안
  • 보안 컴포넌트
  • Enterprise 보안 아키텍처

Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처 설계 산출물 관계

소프트웨어 아키텍처 설계 및 구현 산출물은 크게 두 개의 주요 카테고리로 구분할 수 있다. 이 두 개의 주요 카테고리는 요구사항 정의와 소프트웨어 아키텍처로 나뉜다. 요구사항 정의는 기능적 요구사항과 품질적 요구사항으로 나눌 수 있다. 요구사항 정의의 요구사항들을 살펴보면, 기능적 요구사항은 세가지(required, preferred, optional)의 우선순위로 분류가 된다. 품질적 요구사항은 시나리오 이력(profile)로 기술된다. 여기서 소프트웨어 아키텍처는 네 가지의 산출물로 구성된다. 소프트웨어 아키텍처는 시스템 컨텍스트, 아키텍처스타일, 아키텍처 스트럭처와 설계 의사결정으로 구성된다. 먼저 시스템 컨텍스트는 소프트웨어 시스템의 인터페이스가 컨텍스트로 정의된다. 아키텍처스타일은 시스템을 구성하는 핵심 추상(core abstraction)으로 나타난다. 시스템 스트럭처는 아키텍처를 핵심 컴포넌트들과 그들간의 관계를 정의한 것으로 분해되는 것을 나타낸다. 설계 의사결정은 세가지로 구성되는데 전이, 제약조건과 규칙인 세가지 타입으로 구성된다.

 

그림 Ⅲ-40. 소프트웨어 아키텍처 설계 산출물 관계

Posted by 꿈꾸는자의 생각의파편들

웹기반 시스템의 경우에는
아무리 간단하다고 하더라도...

구현관점이나 배치관점에서의 다이어그램을 명쾌하게 그려주는 것이 좋다.

컴포넌트 다이어그램이나 배치 다이어그램과 같은...

~.~

웹시스템의 특성상...

유스케이스를 기반으로...
시퀀스와 액티비티 다이어그램을 그리면...
거의 대부분의 환경을 기술할 수 있다.

설계시에도...
가능한 단순하게 하며...

클래스가 명확히 필요한 영역에서만 클래스 다이어그램을 기술하는 것이 좋다.
그리고,
웹의 특성상 이벤트가 많이 발생하므로...
상호작용 다이어그램을 알차게 그린다면...

~.~

웹기반 정보시스템에 대한 알찬 기술이 될것이다.
Posted by 꿈꾸는자의 생각의파편들

아주 간단한 시스템의 경우에는

UML 다이어그램중에 어떤 것을 가장 필수적으로 그려야할까?

4+1 관점에서 살펴본다면 다음과 같이 구분할 수 있지 않을까 한다.

간단한 시스템의 경우...
대부분이
배치관점이나 구현관점이 단순해지므로...
굳이 이 부분의 다이어그램을 그릴 필요는 없다.

유스케이스 다이어그램과 설계시에 필요한 상호작용 다이어그램 정도만 그리면 깔끔하다.
사실상...
설계관점에서의
클래스 다이어그램이 사용되는 경우가 거의 없다면 이 부분도 생략하는 것이 좋다.

다만...
여기에...

이벤트나 반응성이 강한 내용이 첨가된다면...
가볍게..
상태차트 다이어그램정도 추가하면 좋다.

정말로...
4+1 View 관점에서 전체 다이어그램을 다 그릴 정도로
분산환경이 복잡한 경우에나 필요한 것이지.

실제 개발시에 이 모든 다이어그램을 다 그리는 경우는 극히 드믈다.

~.~
Posted by 꿈꾸는자의 생각의파편들

품질 요구사항 구조적 그룹핑

지금까지 소프트웨어 아키텍처를 아키텍처 관점에서 품질요구사항을 파악하여 최대 만족을 하고 반면에 도메인 기능적 변경이 최소화 되도록 아키텍처 전이 과정의 네 가지 카테고리를 살펴보았다.

결론은 각 아키텍처 전이 단계의 최종 활동은 divide-and-conquer 원칙을 적용한 품질 요구사항을 적용시키는 것이다. 시스템레벨에서 품질 요구사항은 시스템을 구성하는 서브시스템이나 컴포넌트로 재구성된다. 따라서 한가지 품질요구사항(X)은 X를 만족하기 위하여 여러 개의 컴포넌트(n)으로 재구성된다고 말할 수 있다. 그림 Ⅲ-39는 이러한 설계 결정물과 관련한 계층 관계를 도식화한 것이다.

그림 Ⅲ-39. 소프트웨어 아키텍처 전이 과정 구성요소

소프트웨어 아키텍처 전이 단계 동안의 산출물은 설계 결정물 전이 이다. 일반적으로 전이는 소프트웨어 아키텍처상 구조적 노력에 불과하다. 그러므로, 이 단계의 결과산출물은 소프트웨어 아키텍처의 일련의 부분 버전에 불과하다.

Posted by 꿈꾸는자의 생각의파편들

아키텍처 패턴 적용

아키텍처 스타일 적용은 소프트웨어 아키텍처를 전이하는 방법이며, 아키텍처의 품질요소를 개선하는 것이다. 두 번째 카테고리인 아키텍처 패턴 또는 아키텍처 메커니즘은 일반적으로 동시성 또는 지속성과 같은 기능화 측면을 다루기 위하여 어떻게 시스템을 특성화시킬 건지 규칙을 아키텍처에 적용한 것이다. 아키텍처 패턴은 아키텍처의 기능적 컴포넌트를 재구성화하는 것이 아니라, 오히려 기능적 컴포넌트를 변경하고 확장시키는데 초점이 있다. 따라서 이 패턴으로 필요한 기능을 담은 새로운 컴포넌트를 추가 또는 변경하는 과정이다. 아키텍처 패턴은 소프트웨어 아키텍처 또는 그 영향을 받는 컴포넌트에서 컴포넌트의 기능을 제한하고 동일한 기능을 수행하는 또 다른 아키텍처 구조상 패턴을 적용 또는 사용을 막는다. 즉 아키텍처 패턴은 시스템 행위의 한 측면만을 다룬다. 일반적으로 이 부분은 어플리케이션 도메인이 아니라, 컴퓨터 사이언스 도메인 측면이다. 컴퓨터 사이언스 측면은 주로 concurrency, persistence, synchronization, transactions, distribution, runtime binding, real time behavior, graphical user interface가 이에 속한다.

설계 패턴 적용

아키텍처 패턴에서 소프트웨어 아키텍처 전반에 걸친 영향을 미치는 전이 방법을 살펴보았다면, 설계 패턴은 전체 아키텍처 관점에서는 조금 덜 유동적인 전이과정이라고 할 수 있다. 이러한 설계패턴은 아키텍처 또는 시스템의 기능적(functionality)에 변경을 줄 수 없는 것이며, 단지 그 functionality의 구성이나 구조를 결정할 수 있다. 설계패턴은 이후 상세설계를 위한 설계패턴에서 더욱 자세하게 살펴보도록 한다.

 

품질요구사항의 기능화

원칙적으로 아키텍처 스타일과 설계 패턴은 아키텍처의 품질속성을 만족시키기 위하여 현재 기능화된 구조를 새로운 버전의 구조로 재구조화한다. 하지만, 이러한 활동이 항상 효과적이고 능률적인 것은 아니다. 어플리케이션 도메인과 관련된 것이 아니라 단순히 품질요소 개선을 위한 시스템의 추가된 기능화 과정일 수도 있다. 마지막 전이 카테고리는 품질 요구사항을 도메인과 관련된 것이 아니라 요구사항 수용이라는 아키텍처 확장이라는 의미를 가진 기능적 해결책으로 변환이다. 비록 이러한 형태의 해결책이 현 버전의 아키텍처를 마이너수준의 재구성화를 요구할지도 모르지만, 새로운 컴포넌트와 기능화의 추가가 원칙적인 해결책이다.

Posted by 꿈꾸는자의 생각의파편들

~.~


입문자료용으로 만든것인데...

원래 4시간짜리를 1시간짜리로 줄일려고 하니...
조금 이상한 모양이 되어버린듯.

흠...

머 좌우당간...
Posted by 꿈꾸는자의 생각의파편들

아키텍처 스타일 적용

소프트웨어 아키텍처 전이과정의 첫 번째 카테고리는 소프트웨어 아키텍처상 아키텍처 스타일의 적용과 관련이 있다. 이 카테고리는 아키텍처의 완전한 재구조화 과정이 된다. 따라서 모든 아키텍처 컴포넌트에 영향을 미치며 컴포넌트상의 기능적 재조정이 함께 적용되는 재구조화가 이루어진다. 따라서 컴포넌트 사이간 원래의 커넥션(연결점)이 영향을 받으며, 결과적으로는 아키텍처 스타일 적용이 대규모로 아키텍처 전반에 대한 영향을 미치는 전이 과정이 이루어진다.

 

여기서 아키텍처 스타일에 대한 가장 기본적인 스타일에 대해서 표로 정리해 보았다.

표 Ⅲ-12. 아키텍처 스타일

스타일

특징

  • Pipes and filters 
  • 파이프 및 필터 스타일은 화학공장에서 사용되는 정제탑을 생각하면 된다. 필터는 재료에서 화학물을 정제해 내는 과정과 같으며, 화학물의 이동통로는 파이프로 이해하면 된다.
  • 따라서 파이프/필터 스타일은 필터로 처리되고 파이프를 통하여 데이터 흐름이 데이터 네크웍에서 진행된다.
  • Layers 
  • 레이어드 아키텍처 스타일은 시스템을 수평적 레이어로 분해하는 것을 말하며, 각 레이어는 층을 나누기 위하여 몇 개의 레이어로 구분되며 상위 계층에서 하위계층으로의 연결은 인터페이스가 사용된다. 결과적으로 높은 수준의 추상화 단위작업은 수많은 lower-level 작업들로 분해된다. 이때 상속의 개념을 통하여 lower-level 작업은 일정한 폼을 형성한다.
  • Blackboard 
  • 인공지능 분야에서 시작한 블랙보드 스타일은 데이터나 지식을 공유하는 메커니즘을 사용한다. 따라서 블랙보드 스타일을 적용한 모델은 데이터 저장소(다수의)를 통하여 추론하게 된다.
  • Object-Orientation 
  • 객체 지향 스타일은 커뮤니케이션 객체란 용어로 시스템에 적용된다. 객체는 시스템의 상태를 저장하거나 상태에 접근 및 저장 및 변경을 하기 위한 함수 역할을 하는 엔터티로 표현된다.
  • Implicit invocation
  • 객체지향 스타일이 각 객체들간에 의존관계가 심화되기 때문에 사용되는 암시적 호출 스타일이다. 암시적 호출 스타일은 이벤트 발생, 저장용 데이터, 이벤트 소멸과 관련한 컴포넌트란 용어로 시스템을 구성한다.(대표적 예 : JavaBeans)
Posted by 꿈꾸는자의 생각의파편들

소프트웨어 아키텍처 상세화

본 절차에서는 네 가지 형태의 아키텍처 전이 절차에 대해서 살펴볼 것이다. 아키텍처 전이는 시스템의 특성을 변화시키기 위하여 사용된다. 소프트웨어 아키텍처 개발 단계는 기능중심 아키텍처 설계 단계, 아키텍처 평가단계, 아키텍처 전이 단계로 구성된다. 첫 번째 기능중심 아키텍처 설계 단계에서는 도메인 분석을 기반으로 하여 설계를 진행하며, 소프트웨어 아키텍처 평가단계에서는 품질요소에 따른 요구사항과 비교하여 네 가지 방법 중 소프트웨어 아키텍트가 비교방법을 선택하고, 품질요소에 맞게 시나리오 프로필을 소프트웨어 아키텍처와 데이터 검증 및 시나리오 검증을 통하여 평가하게 된다.

마지막으로 소프트웨어 아키텍처 전이단계는 소프트웨어 엔지니어가 아키텍처를 분석하고 아키텍처 특성에 무슨 문제점이 발생하는지를 결정하는 능력이 요구된다. 소프트웨어 아키텍처 전이단계에서는 이전 소프트웨어 아키텍처가 고객의 요구사항과 시스템 컨텍스트의 변경으로 인한 버전 별로 소프트웨어 아키텍처를 진화시키는 과정이라고 할 수 있다. 진화시키는 범위는 기능 중심 아키텍처 설계의 시스템 컨텍스트 및 도메인이 그 범위이며, 평가 방법 역시 이전에 실시한 동일한 방법에 따라 변경된 시스템 특성에 따른 특성치를 관리하게 된다.

결과적으로 아키텍처 전이 단계는 모든 소프트웨어 아키텍처 전이가 시스템 특성에 긍정적 또는 부정적 영향을 미치게 된다.

여기서 소프트웨어 아키텍처 전이단계의 네 가지 카테고리를 정리하고, 어떻게 하면 아키텍처 변경에 따른 영향(아키텍처 스타일, 아키텍처 패턴(메커니즘), 설계패턴, 품질요구사항의 기능사항변경)을 최소화할 것인지에 대하서 살펴보도록 하자.

 

아키텍처 스타일과 설계패턴과 관련한 아키텍처 전이 단계는 서로 독립적인 문제가 아니라, 문제파악, 해결책 선택, 해결책 적용 이란 큰 과정을 통하여 진행되게 된다.

첫 번째 과정은 품질요구사항이 현재버전의 소프트웨어 아키텍처로 만족하고 있는지 파악하는 데부터 시작하게 된다. 추가적으로 품질속성의 평가레벨과 요구사항의 불일치점을 수집 및 집계한다. 이러한 평가레벨과 각 품질속성에 대한 요구사항의 불일치점을 기반으로, 품질속성간 우선순위를 결정한다. 이 우선순위를 고려하여 어떤 품질속성을 먼저 아키텍처 전이단계로 수행할 것인지를 결정하게 된다. 각 품질속성에 대한 요구만족레벨과 평가레벨에 대한 이력을 남김으로써, 후에 소프트웨어 아키텍처 전이단계의 전이방법 선택과정에 도움을 줄 수 있도록 정리한다.

두 번째 과정은 각 품질 속에 대한 반복과정이다. 어느 하나의 품질속성이 단독으로 소프트웨어 아키텍처에 영향을 주기보다는 복합적으로 작용하여 영향을 주는 경우가 더 많으므로 유효한 품질속성을 기반으로 전이 선택에 영향을 주도록 평가한다. 두 번째 과정은 파악된 품질속성이 소프트웨어 아키텍처에 어느 컴포넌트(또는 서브도메인)이나 위치에 무슨 영향을 주는지를 파악해야 한다. 이것은 이전 평가방법에 따라 정량적 또는 정성적으로 파악할 수 가 있으면, 기초 데이터를 통하여 변경된 품질속성에 대해 예측 가능한 계산을 할 수 있다.

세 번째 과정은 소프트웨어 아키텍처에 파악된 문제점을 해결할 전이 방법을 선택하는 것이다. 일반적으로 몇 가지 상이한 전이 방법이 사용되는데, 문제의 범위나 영향 정도에 따라서 그 방법이 결정된다. 소프트웨어 아키텍처가 선정한 아키텍처 전이 방법이 현재의 소프트웨어 아키텍처에 부정적 또는 긍정적 영향을 미칠 수 있으므로 주의 깊게 생각하여야 한다.

마지막 네 번째 과정은 전이를 실시하는 과정이다. 이것은 기능(functionality)을 선택된 아키텍처 스타일과 아키텍처 패턴, 변경된 아키텍처 기술서를 바탕으로 재구성하는 과정이다.

 

그림 6은 이러한 전이과정 범위를 도식화한 것이다. 이차원적인 도식에서 전이 과정은 영향의 범위 축. 즉 컴포넌트 수준의 변경인지 아니면 아키텍처 전반의 변경인지를 나타내는 축과 전이 형태-현 컴포넌트의 재구성 또는 컴포넌트에 기능 추가를 나타내는 축으로 구성된다. 4/4분면의 내용으로 영향범위와 전이형태의 정도에 따른 소프트웨어 아키텍처에 고려해야 할 방법이 네 가지로 분류할 수 있다.

그림 Ⅲ-38. 전이 카테고리 분류

결론은 소프트웨어 아키텍처 전이 과정은 네 가지 과정으로 정리될 수 있다. 첫 번째 과정은 고려하지 않은 품질요구사항의 파악, 두 번째 과정은 각 품질요구사항에 대한 영향을 주는 컴포넌트 및 위치를 파악, 세 번째 과정은 적합한 전이 방법 선택, 네 번째 과정은 전이를 실시하는 단계로 이루어진다.

Posted by 꿈꾸는자의 생각의파편들

 

"자신의 작품에 이름을 새길 떄에는 다음과 같은 조건을 갖추어야 한다.

  태도(殆土)를  빚는 데서부터  그릇이 완성될 때까지의 과정 , 즉 풀레작업,

  그림 작업, 가마에서의 소성작업은  모두 스스로 해야 한다.

  자기 가마를 가지고 있는 이상 , 이중에 어느 한 과정이라도 타인에게

  맡기면 안된다."

 

  - 기타오지 로산진, 1933년 -

 

로산진은 한가지 작업만 했다고 하네요.

고용한 도공이 다 만들어 놓으면, 작품에 도장 찍기가 자신의 유일한 작업이었다는...

그러면서도...

 

로산진의 경우에는 평가가 극과 극을 달린다고 합니다.

 

자기손으로 흙을 묻히지는 않지만...

 

그는... 정말 탁월한 그릇디자이너 였다는 점입니다.

 

그의 디자인이 무명의 도공의 손에 의해서 완성되었고.

남들이 시도하지 않은 파격적인 디자인까지...

정말 앞서 나간 사람이었다고 합니다.

 

더군다나... 그의 예술적인 재능은....

요리, 서각, 서예등... 42살에 도예에 입문하고 자신의 미식가 클럽도...

 

심지어는...

일본에서 인간국보에 대한 의견타진이 왔을때에..

'누가 나를 평가하느랴'며 거절했다는 그...

 

이 세상에는 물레를 잘 돌릴 수 있는 사람이 몇천, 몇만명이 있으나..

과연 로산진 수준의 작품을 만드는 사람이 몇이나 있을까?

 

건축가나 의상 디자이너는...

스스로 콘크리트를 다지거나 옷을 재봉하지 않지만..

그 작품은 분명 그들의 것이라는 것이죠.

 

그것은...

처음에 그들의 마음속에서 탄생시킨 것이..

형태가 되었기 때문인것...

 

건축가나 디자이너가...

분명 벽돌을 잘 올리고... 옷을 잘꽤매야겠지만...

 

직접 그 작업을 하지 않았다고 해서...

 

그의 작품이 아니라고 하지 않죠...

 

소프트웨어 아키텍트도...

그런것이 아닐까요?

이 글은 스프링노트에서 작성되었습니다.

Posted by 꿈꾸는자의 생각의파편들