Checking Architectural Compliance in Component ... - Textcube

Document Sample
Checking Architectural Compliance in Component ... - Textcube Powered By Docstoc
					김은선
-   Software system의 architecture와 design/implementation 간의
    compliance를 체크하고 보장해야 한다.
-   현재 tool support의 한계 : inflexible
    ex) SonarJ




Component-based system의
architectural compliance 를 검사하기 위한



                          Rule-based approach
   Rule-based approach
   목표
다양한 architectural compliance와 artifacts에 대해
architectural compliance checking을 위한
매우 flexibility한 formal foundation을 제공.
   Issue
   다양한 artifacts에 대해 flexible해야 한다.
         artifacts와 컴포넌트 기반 description의 적절한 formalization을 세운
    다.

   수많은 constraints에 대해 flexible해야 한다.
        architectural rule 은 constraints의 공통특성을 추출함으로써 정의된
    다.
   Formalization
   Design model을 통한 formalize
   M={U, R} : U = entity들의 집합, R = U에 대한 관계 집합
   unary relation (R ⊂ U) : 단순히 엔티티들의 부분집합 ex) class
   binary relation (R ⊂ U*U) : 엔티티들의 쌍 집합 ex) inherit
   Design description
-   두 개의 컴포넌트 : c1, c2
-   컴포넌트가 제공하는 인터페이스 : i1, i2
-   컴포넌트와 인터페이스를 묶은 패키지 : p1, p2




   logic statement
-   UML 컴포넌트 다이어그램은 first order logic statement에 의해서 쉽게 해석.
-   extensional statement의 모델: expansion과 reduction 되지 않는다.
   Minimal design model
   extensional statement를 만족
   Minimal : extensional statement에 확실하게 엔티티와 각 관계들이 명시되었기
    때문에 추가적인 reduction이 없다.
   3개의 description에 의해 결정된다.
   Architectural Rules
   Architecture description에 대한 statement가 intensional한 constraints
    들을 정의.
   Intensional : 모든 시스템의 design description은 illegal dependency를
    갖는 시스템으로 확장될 수 있는 layer structure를 따른다.



                  illegalDependency
                  - mapping description과 design description으로
                     layer간의 dependency가 표현.
Architecture rule
   Non-local, first-order logic statement
   RCB 를 따르는 관계집합을 포함.
   Formalization
   1. Type Formalization
   2. Structure Formalization
   3. Behavior Formalization
   Actual behavior : method가 실행할수 있는 operations에 의해 정의.
   Finite structure
   Abstract interpretation을 제공하는 RCB를 따른다.




   다음의 issues와 관련된 architectural rules을 표현하기 충분하다.

   Structure of types and relationships
   Structure of communication between instances
   Lifecycle of instances
   Dependencies between Layers
   l이 m을 의존 : l의 인터페이스나 component가 m의 요소 사용

   polymorphism에 의한 의존성 : l의 메소드가 동기적으로 l의 메소드 호출.
   Architectural compliance checks
Design과 implementation이 의도된 logical architecture를 따르는 가에
대해 알아보기 위해서 시행.
-   Intended architecture의 informal description
-   UML models
-   layer(Architecture)와 UML package(Design description) 의 mapping
   Layer Dependency를 위한 Architectural Rule
   illegalDependency 의 정의 : RCB로 dependency의 다른 형태 표현

illegalDependency(l,m) = ┐allowedDependency(l,m) ∧ dependency(l,m)



   layer 간의 dependency 표현 : design description의 element간의
    dependency를 표현. (mapping description 또한 필요)

dependency(l,m) = ∃p,q : Package(p) ∧ Package(q) ∧ mapping(l,p) ∧
  mapping(m,q) ∧ packageDependency(p,q)
   Package간의 dependency 표현




   possible한 다른 dependency : depend1은 component와 interface사이
    의 dependency case를 다룬다.




   interface사이의 dependency
   Component간의 dependency 표현




   Parts의 dependency : Component가 Connector를 포함하고 있는지 확인




   Method Invocation의 dependency

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:4/17/2013
language:English
pages:20