Search Results for 'S/W Architecture'

6 POSTS

  1. 2007.06.22 S/W Architecture 2
  2. 2007.05.04 요즈음 나는 .... 2
  3. 2007.01.12 2월까지 봐야 할 책들 7
  4. 2006.09.03 Module view Style은 무엇인가 ?
  5. 2006.08.30 view type의 종류에 대한 간단한 그림
  6. 2006.08.30 오늘은 View, ViewType and Styles

S/W Architecture

Posted 2007. 6. 22. 14:14

※ 아키텍처는 소프트웨어 아키텍처를 뜻합니다.

최근 아키텍처에 대한 품질 평가를 하면서 몇몇 새로운 것들을 느끼고 있다.

엔지니어들이 느끼는 아키텍처란게 무얼까? 6년전에 만든 아키텍처 문서를 보면서 품질팀에서 아키텍처에 대한 품질을 검사 할 수 없음을 다시 한번 느끼고 있다.

아키텍트는 아키텍처의 품질 담당자이며 이로 인해 아키텍트가 책임을 지는 일은 상당히 크다라고 할 수 있다.

어떤 품질에 포커스를 하느냐에 따라 QA( Quality Attribute ) 의 느낌감도 (?) 는 상당히 다르다는 것이다.

어떤 이는 ATAM을 너무나 쉽게 거론하기도 한다.

최근 모 회사의 아키텍처 문서를 평가하면서 많은 것들을 느꼈는데… 최근에 제품위주(COTS) 의 아키텍처가 아키텍트들의 머리에 또 다른 사고를 만든다는 것도 알았다.

그러기 위해서는 COTS를 위한 아키텍처가 필요하며 이에 맞는 적절한 평가가 필요하다고 생각된다. 페이지수가 많거나 학구적이라고 해서 아키텍처 문서라고 하기엔 너무나 고리타분하고…. 외국서적에 나온 듯이 그대로 배낀 패턴이나 스타일로 뒤덮힌 아키텍처 문서도 난무하며… 정말 그런 문서들이 아키텍처 문서인지는 잘 모르겠다.

개발자입장에서 디자인패턴을 써놓는다고 해서 아키텍처라는 말을 붙이기엔 아키텍처라는 말이 너무나 광범위하고 어떤 면에서는 협소하다고 생각한다.

최근 몇 년간 SEI 에서 나온 시리즈 물을 몇 번 정독하고…

포사1.2를 쪼개고…

각종 Object문서를 봐도 봐도…

현장에서의 아키텍처문서엔 어떠한 면에선 현실적인 내용이 들어가긴 힘들다는 것이다.

그저 현학적인 문서들….. 책을 아무리 많이 봐도 익혀지지 않는 것들이 많은 것은

책의 장수만을 세거나 아니면 너무나 현학적인 책을 봐서 아닐까….. 반성해야 한다.

아키텍처 문서에는 이러한 것들이 들어있으면 좀더 많은 이해관계자들이 공감하기 좋을 것이다.

  • 1.여러 이해관계자가 이해가 가능한 View를 가진 문서
  • 2.비 전문가가 봐도 어느 정도 이해 가능한 합리적이고 쉬운 아키텍처 문서
  • 3.회사나 집단의 아키텍처적인 의사평가를 내리는 과정이나 기술적인 평가를 위해 쓰이게 될 문서
  • 4.회사의 아키텍처 전략 ( 품질속성 ) 을 내포하며 이를 지키기 위해서 어떠한 것들이 내재 되어야 하는지 어떠한 것들이 패턴화 되었는지 등등에 대한 문서, 이를 위한 대안이나 원칙, 정의 등이 포함된 문서
  • 5.비즈니스와 기술을 연결하기 위해 최적의 메커니즘 효율성을 찾아내는 메커니즘적인 문서
  • 6.기타 등등


하도 많아서 기술하기 힘들지만…. 대략 저러하다.

또다른 뷰에서 본다면 아키텍처 정의를 위한 문서들은 어려워서는 안되며 가장 쉬운 것으로 추상화되어 표현되어야 한다는거….

요즈음 나는 ....

Posted 2007. 5. 4. 20:02
1. 몸이 더 안좋아짐. 오늘은 회사를 쉬었음. 토비형을 보고 싶기도 했지만 도무지 보기가 힘든 상황
2. 최근엔 SOA의 SCA대해서 좀더 깊이 연구 하였음.
3. 스프링의 IoC에 대한 좀더 깊은 생각
4. 스프링의 컨트롤러에 대한 여러가지 생각을 하게 됨. - 내부 구조를 뜯다가 서블릿의 그 ( ? ) 구조가 생각나기도 했음. 그러나 스프링은 여전히 국내에서는 무력한 상태임. 참고로 스프링의 컨트롤러는 Servlet Controller는 아님.
5. 아침 스터디중 - TDD에 대한 또 다른 생각중
6. SQL Map - Abator 괘얀음. 그러나 유동성 없음. 조금 하다 보니 DAO를 생성해주는데 "SPRING" 으로 바꾸자 Spring의 JDBC Template를 이용해서 코딩이 Gen 되어 나옴 그런데 코드를 보고 약간 실망...T.T 자동 Gen의 한계가 아닐까라는 생각이 듬.
7. 제품에 대한 의존도및 이것들에 대한 유지보수에 대한 생각중 - 제품자체의 건강함을 위해서 코드는 간결하고 철학을 가져야 함. 내부적인 품질이 지켜지지 않은 모 회사의 제품은 철학도 없고... 사람힘들게 만드는 쓰레기 코드임이 틀림 없음. 이상...


걍 생각없이 읽어볼만한 pdf 임

2월까지 봐야 할 책들

Posted 2007. 1. 12. 00:13

사용자 삽입 이미지
1. 오늘 막 도착한 Head First Object-Oriented Analysis&Design 시간이 되어서 꼭 봐줘야 하는책 보고나서.... 나와 가장 친한 J군에게 모든걸 알려주려는 바로 그책...

다 읽고 J군에게 브레인덤프를 약속한 ......
1:1 강의를 해주기로 한 바로 이책... 2월이 가기전에 2번을 꼭 봐야 한다....



사용자 삽입 이미지

2. 요즈음 보고 있는 POSA 1 -
몇해전 보다가 포기했던 그 문제의 책...
답답하고 짜증나던 이 책...
몇권의 S/W 아키텍처 서적을 보고나서 이책이 조금씩 쉬워졌는데....그런데 지금은 너무나 흥미진진하고 재미있어지는 문제의 책... 또다른 J군과 같이 보는 이책....

최근들어서 애착이가는 바로 그책....
2번이상 정독해야 맛이 우러난다는 바로 이책....
쉬운 영어로 보이기 시작한 바로 이책....
아름다운 ( G 교수는 아름답다 했지만 B 교수는 아름다운게 아키텍처가 아니라고 했던 ) 문제의 이책....POSA 1



사용자 삽입 이미지

3. 앨빈토플러의 부의 미래 - 보고있으면 한없이 졸리다는 바로 그책.... 원칙적으로는 가장 먼저 봐야 하는 책이지만... 미루고 있는... 부끄럽다. T.T


사용자 삽입 이미지

4. IT ROI 투자가치 분석 - 한달째 쌓아두고 계속 봐야지 하고 있는 바로 그책...

5. 보기 싫은 주말작업을 위한 가트너 레포트, 포레스터 레포트 PDF 30개 분석.......

6. 그리고....화장실갈때 나의 성경처럼 나를 지켜주고....그래서  들고다니는 피터 드러커 흉아의 바로 그책.... 나에게 변비를 선물한 이책이 오늘의 핵심이라는거...
에센셜 드러커.... 안보신 분은 꼭 보시길....


그리고 아무도 모르게 순식간에 봐야 하는 그책....T.T 어쩌다..이런....
읽어야 하는 우선순위는

1. POSA
2. 헤드퍼스트
3. IT ROI
4. 부의미래

순으로 읽어야....
그리고 2월부터 공부하는 경영공부...전략경영 , 이건 놓치지 말고 해야 하는....

■ 오늘 여러가지 레포트와 JBOSS아키텍처를 연구하다 오픈소스란 이런거야...
아.... 아름답다.... JBOSS의 아키텍처... 스프링을 보고 한번 감탄했다면.... 다른것도 엄청난게 많지만...JBOSS의 마이크로커널개념....
이전에도 그랬지만 오늘 또 놀라게 된다.

2000년 초반에 생각해낸것도 놀랍지만...커널 개념의 아키텍처라니... 이놈 혹시.... 어제 공부한 그 커널이 이 커널 아닐까....??? 현재 진행중인 모든 프로젝트들이 하나처럼 움직이는 건 이 커널때문일 것이다.
이미 소스에 오픈정신이 가득해 보인다.

JBOSS의 아키텍처가 오픈소스에 최적화(?) 되었다는 느낌이 또 들었고...
다시 솜털이 돋는다. Oracle이 탐낼만 하였다는....

사용자 삽입 이미지


<<----- 여자모델 맘에 안들어

Module view Style은 무엇인가 ?

Posted 2006. 9. 3. 02:33

1. 사용용도 :

1. 구축 : 소스코드를 위한 청사진으로 모듈과 소스파일 혹은 디렉토리와 같은 물리적인 구조는 종종 밀접한 관계를 가짐
2. 분석 : 추적성, 영향도분석의 도구로 사용되며 모듈은 시스템을 분할하기 때문에 그렇다. 시스템의 기능요구사항이 어떤 모듈에서 지원하는지 결정할수 있게 되므로 추적성을 가질수 있음.
또 한 모듈사이의 컨텍스트 다이어그램이 표기하듯 이러한 것을 통해 영향도 분석이 가능함.
3. 시스템을 처음 접하는 사람들에게 시스템의 기능을 설명하기 위한 도구로서 사용되기도 함.
4. 그런데 모듈뷰 스타일은 성능, 신뢰성등을 나타내는 런타임 속성을 나타내는 분석툴로서는 쓰이지 않음.

2. 모듈뷰의 모습은 무엇으로 표현하는가 ?

모듈뷰의 단위는 모듈이다. 이름에서 보는 바와같이....
그러면 모듈은 무엇인가 ? 모듈뷰의 구현요소이고 모듈에는 기능적인 책임이 할당되는데 이때 cohension 은 높이고 coupling은 낮춘다.
cohension은 응집력이라 하고 coupling은 결합도라고 하면 될듯
모듈뷰는 모듈간의 관계를 표시한다.
그리고 모듈 분할법이라는 있는데 나중에 설명함.
<<핵심어는 모듈뷰, 모듈, 모듈분할법임>>

3. 표현법은 ?

표현법은 크게 두가지이다.
1. 그래픽을 이용하는 방법
  uml을 이용하는 방법
  http://sparxsystems.com.au/resources/uml2_tutorial/uml2_classdiagram.html
  에 보면 클라스, 패키지, 서브시스템, 인터페이스 등의 모듈 표현이 보인다. 그리고 그 아래에 보면 is part of(composition) , depends-on(dependency) , is a (generalization) 관계등에 대해서 나온다.  
  비정형적인 방법은 모듈의 그림을 그려서 표현하는 방법등이 있다.  아래의 링크와 같이 말이다.        
   http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_adapters.doc/doc/mysap4/mysap4132.htm

2. 텍스트를 이용하는 방법
  모듈을 나열하고 책임을 나열한다. 바로 이전에 말한것중에 기능적인 책임과
  관계를 말한다고 써두었다. 바로 위에 참조
  텍스트로 표시하게 되면 is part of , depends on, is a 등이 있다.
  •   is part of - 복합모듈과 서브모듈간의 관계정의
  •   depend on - 종속성 표시 초기 설계중 표현하기 애매한경우 사용을 많이했음.
  •   is a -  일반모듈과 자식모듈을 말하며 uml로 보면 상속이 이에 해당
3. 이전에 설명한 그림에서 모듈뷰타입이 분할, 사용, 일반화, 레이어 스타일이 있다고 했는데 이것을 어떻게 보이는지 실제 함 보자. 나도 이것이 상당히 궁금했었는데...말로만 구구절절 설명하니깐 말야... uml 로 설명한다. 그러나 uml로 아키텍처를 표기하기엔 너무나 벅찬면이 많아 나는 상세화 하기전엔 uml 로 표기를 하지 않고 있다. 그러나 여기엔 uml로 표기하여야 할듯
  • 분할 스타일 - is part of 관계가 주로 이 형태임
composition 관계에 대한 그림









이것은 패키지나 서브 시스템안에 모듈을 클라스 단위로 나눈 모습임 (aggregation module) 집합모듈임





is - part - of 관계에 초점을 맞추어 보면 책임이 모듈에서 어떻게 분할되는가를 알게 되는데 원래의 모듈이 떨어져나가 어떠한 관계를 가지는지 알게 해준다. 경험에 의하면 UML이 아니더라도 분할스타일을 이용하여 아키텍처를 설명하고 구축을 위한 준비하였었다.
이러한 스타일은 뭔가를 변경하거나 할때 주로 사용하기도 하고...구조화 할때도 사용하기도 한다.

  • use style - depend on
이것의 uml은 이전에 보아왔던 depend on 즉 class diagram그리고 스트레오타입으로 <<use>> 라고 해놓은것 ... 그냥 단순한것만이 아니고 이것을 쓰려면 아래와 같은 특성을 이해하여야 한다.

모듈사이에 사용을 표시하려면 상대방의 모듈이 잘 정의되어있고 쓸수있어야 가능하지 않을까 싶다.  이미 이것을 표시 했다면 종속관계가 성립된것이다. 가끔 이것을 그려놓은 설계자에게 이것이 뭐냐고 물어보면 호출이라고 말하는 사람도 있는데...호출포함, 데이타사용, 그리고 그냥 호출.... 이것도 포함... 이정도로 사용하고 있다.
  •   is a - generalization
이것의 경우 interface 구현이나 상속등으로 알고 있으며 uml 노테이션에서 설명하기론 realization으로 설명되는데 프레임웍을 만들다 보면 generalization의 관계는 무언가를 추상화하거나 혹은 일반화를 통해 뭔가 가변성을 주거나 할수 있다. 이러한 것을 사용하게 되면 객체의 특성상 많은 잇점 (상속이나 인터페이스 구현) 등에 많은 잇점이 있다.

  • 마지막으로 한번도 언급안한 layered style - 바로 이전에 블로깅한 글에 그림에 트리구조로 적어뒀음.
Tier와 Layer의 차이를 먼저 알아야 하는데 Tier를 보통 아키텍트들이 말할때 Web Tier, Web Application Tier등으로 말한다. 이렇게 말하는걸 보면 과거의 c/s 의 아키텍처를 연상시킨다. 웹에서 뭐 이렇게 표현한다고 하면 하는거지만....
아래의 예는 상당히 해깔리게 적어뒀는데 난 맘에 안든다. 일부는 티어가 맞지만 일부는 레이어가 맞기 때문이다. 바로 아래의 문서는 많이 해깔리게 적혀진 문서이다.
http://www.javagen.com/architecture.jsp;jsessionid=180ED4984F2CA44345B4820922ED04D4















아래의 문서는 레이어는 없지만 Tier를 잘 작성하여 나타내고 있다.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/introduction/introduction3.html















내가 지금까지 구분을 지어온 바에 의하면 물리적으로 구분이 되는경우 Tier , 논리적으로 구분되어 지면 Layer이며 Tier는 위의 그림에서 보는바와 같이 C/S구조에 쓰이게 된다.
위의 그림을 그저 그런 나의 실력으로 본다면 2Tier를 3Tier로 바꾸면서 나온그림으로 생각된다.  위의 그림이 잘 맞는다고 말하는 이유는 화살표가 서로 주고 받기 때문이다 이 화살표에 커넥터라는 말이 없어서 조금 유감이지만..... Layer는 이게 불가능하다. 단방향이 불가능하기에 양방향 통신은 티어만 가능함.  



오늘은 어제 썼던 내용을 다시 한번 정리 한다.
  • module view type - 코드단위로 어떻게 구성하는가 ??
  • component and connector view type - run time시 행위및 상호작용갖는 요소들의 집합을 어떻게 구성하나 ??
  • allocation view type - 시스템의 환경이 소프트웨어의 외적 환경에 어떠한 영향을 미치는가 ??


  • 이것들의 종류만 일단 나열한다. View Type & Style (클릭!!)


    다음에는 module view를 정리 해야 겠다.



    오늘은 View, ViewType and Styles

    Posted 2006. 8. 30. 01:08
    내일 회사가야 하는데... 내일도 늦으면 어케하지... 정리좀 해보까 한다.
    이책저책 복습하며 경험을 살려 이렇게 정리 했다. 음...

    DEFINITION
    - View
    A view is a representation of a set of system elements and the relationships associated with them.
    뷰는 사물을 볼때 혹은 시스템을 볼때 여러관점에서 보게 해준다. 이것은 소프트웨어 아키텍처 뿐만 아니라 다른곳에도 통용이 되는 것이라고 생각한다.

    DEFINITION - View Type
    A viewtype defines the element types and relationship types used to describe the architecture of a software system from a particular perspective.
    뷰타입은 특정한 관점에서 소프트웨어 시스템의 아키텍처를 기술하는데 사용하는 요소타입과 관계를 뜻하는데 3지가 있다. 이 3가지는 아래와 같다.

    이러한 3가지는 아키텍트가 설계해야 할 시스템을 3가지 관점에서 보는 것이다. 즉 아키텍트가 시스템을 생각하는 큰 카테고리 같은거다. 그게 3가지가 있다.
    흠... 그럼 도데체 이 3가지는 뭐냐하면

    • module view type - 코드단위로 어떻게 구성하는가 ??
    • component and connector view type - run time시 행위및 상호작용갖는 요소들의 집합을 어떻게 구성하나 ??
    • allocation view type - 시스템의 환경이 소프트웨어의 외적 환경에 어떠한 영향을 미치는가 ??

    그러면 아키텍처 스타일은 무엇인가 ? 말도 어려운데 가면 갈수록 힘들어진다.으흑

    DEFINITION - architectural style

    An architectural style is a specialization of element and relation types, together with a set of constraints on how they can be used.
    아키텍처 스타일은 element 하고 relation type을 함께 묶어서 특성화 한건데 이게 어떻게 쓰이는지에 대한 제약조건등을 포함한거다.

    viewtype이 넘 크니까 뷰타입내에서도 뭔가 다른 시스템에서 반복하는 형태가 발견되고 이것을 정리한건데 재사용가능성등으로 쓸려고 하는거다. 말이 좀 이상한지 모르겠지만 그렇다. 아래 그림 보면 좀 이해가 될듯
    스타일은 어떠한 시스템과도 동립적이다.
    재사용이라는 말에서 느낌이 꽂혔을지도 모르겠지만 흠...두개의 다른 시스템이 동일한 스타일을 사용할수도 있다.
    또 어떤 시스템은 하나이상의 스타일로도 구성되어 있다. 실제로 아키텍트로서 일을 하다보면 이러한 일을 많이 겪을수 있다. 단일화된 스타일은 없었다. 규모가 크면 클수록....

    그러면 도데체 view하고 이것들 하고 무슨 상관있냐 ??
    뷰는 스타일이 특정한 시스템에 묶여 표현되는것을 view 라고 한다.












                     component and connector view type 은 예제 );