(i18n), Multiple Currencies

Posted 2006. 9. 20. 13:21

http://geosoft.no/software/ 각종 유틸리티에 대한 오픈소스 제공
i18n, 및 io등등 제공함


에 보면 어떠한 것들을 적용해야 하는지 범위들에 대해서 아키텍처 적으로 설명이 된것이 있습니다. 매우 유용한 정보인듯





아래는 PDF자료 이것도 유용함 i18N전략에 유효함.
많이 유용 ^^;;;
0
요즈음 일을 하면서 많은 생각을 한다.
아키텍트는 무엇인가 ?
ABC 하면 다인가? 흠...아래 그림은 ABC그림...

항상느끼지만 이거 말고도 아키텍트는 할일이 많다. 위의 그림은 Sun사의 아키텍트에 대한 ABC 에 대한 그림인데

요즈음 절실히 느끼는 나의 아키텍처에 대한 생각은 아래와 같다.

1. 대안 아키텍처는 준비 되어있는가? 반드시 준비 되어 있어야 한다.

2. 아키텍트는 어떤 자료를 수집(실제 수집이 아니고 거의 탐정의 추적에 가깝다고 생각함)하고 반영하여 현실세계의 아키텍처에 흡수 시키는가?

3. 아키텍트는 코드를 알아야 하는가 ?

4. 품질속성만 잘 비고하면 아키텍트로서의 일이 끝나는가 ?

5. 아키텍트와 업무와는 무슨 관계가 있을까? 나의 생각은 업무는 관계가 깊다. 라고 말하고 싶다.

6. 아키텍트는 어떠한 구도로 아키텍처 문서를 만들며 이를 아키텍처로서 가이드 할때 어떠한 뷰를 가져야 하는가? 아키텍트는 스테이크홀더 관점의 여러 뷰를 가져야 하며 스테이크홀더의 관점이 아니더라도 뷰를 여러가지로 판별 가능해야 한다. 사물은 한가지 모습이 아니라 여러가지 모습이며 보는 구도가 달라지면 많이 달라지므로 그렇다고 생각한다. 때문에 그들의 마음으로 그들의 언어를 써야 하며 그들의 생각을 이해하려고 노력해야 한다.

7. 스터디만 가지고 아키텍트는 가능한가?  

8. 전문 지식을 모르는 경영진에게 아키텍트로서 그들을 설득하고 기술을 이해하게 할수 있는가?

9. 아키텍처 혹은 아키텍트가 시스템과 개발 조직에 미치는 영향은 ?

8번의 능력은 특히 중요하다. 8번과 함께 아키텍트는 뷰로서 사물을 접근하고 그사물을 얼마나 추상화를 잘하며 실체화 하는지에 대한 스킬이 필수라는 생각이 지배적이다. 특히 문제의 접근과 해결에서 이것으로 인한 도움을 많이 받았기에 더더욱 그렇다.

최근엔 Ajax에 대한 문제가 많이 도출 되는데 많은 생각을 하며 아키텍처 정의서에 대안 아키텍처로서 비교를 하고 Ajax가 가지는 장단점과 현 아키텍처에 미치는 영향도 등을 조사하고 대안 기술에 대해서 생각을 다각도의 측면에서 가져야 한다. 더군다나 보안에 대해서 아무런 대책도 없이 이것을 쓴다면 차후 나타나는 결과는 뻔할듯....

그때 그때 기술을 준비하기 보다는 시간이 날때 이것들을 비판하고 이것을 사용하기 위한 대안및 비교자료를 만들어야 할것으로 생각된다.....
(항상 기술자료및 기술에 안테나를 세우고...이를 추상화하고 구체화하는 일을 해야 한다.)
스테이크홀더들에게 쉽게 이야기한 기술들이 많은 영향을 미치며 아키텍처가 흔들린다면 쓰지 않는 편이 낳을수도 있지 않을까 조심히 생각한다.

신기술을 사용하는 사람들은 그것을 쓰는것이 무섭지 않겠지만...
신기술을 하나 쓰고 안쓰고가 중요한것이 아니다. 전체 프로젝트에 미치는 영향과 그 영향도에 따른 파급효과 그리고 신기술로 인해 바뀌게 되는 문화 ( 요즈음은 문화까지도 고려해야 하는 시대가 되었나 보다. ) 그리고 개발조직의 밤샘시간.... 모든것을 고려 해야 한다. WEB 2.0 에 대한 많은 이야기가 나오고 문화에 대한 관점의 뷰가 많이 보인다.

이러한 문구가 와닫는 오늘 하루다.

  1. ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS
  2. ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION
  3. ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS
  4. ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT
  5. RAMIFICATIONS OF INFLUENCES ON AN ARCHITECTURE
  6. THE ARCHITECTURES AFFECT THE FACTORS THAT INFLUENCE THEM
    0
                                                        The Architecture Business Cycle

아키텍처는 분명 진화하고 진보한다. 하지만 좋은 기술을 썼다고 진화하고 진보하는 것은 아닌듯 싶다는 조심스런 생각을 해본다.
오늘 하루도 상당히 힘든 하루

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 은 예제 );

    TimeZone 문제

    Posted 2006. 8. 29. 10:41

    도큐먼팅

    Posted 2006. 8. 29. 01:49
    아키텍처가 너무나 크고 힘든거 같다. 나에게는...
    하지만 재미있다. 항상 나에게 도전을 준다. 아 도전...듣기만...

    기업 아키텍처를 구축 하면서 가끔 document관련 책들을 읽는데 몇몇 문구가 눈에 확 보인다.
    컨설팅은 눈높이다. 눈높이라는 말은 고객의 관점에서 보는 사람의 관점에서 문서가 적혀지고 설명되어야 한다는건데 규칙은 이러하다.
    구구절절 옮은 이야기이고 컨설팅적인 기법이 아키텍처에도 그대로 쓰인다. 바바라민토 등

    1. 읽는 사람의 관점에서 문서를 써야한다. -- 이게 컨설팅에서 한 30%먹는듯하다.
    2. 불필요한 반복 줄이기... -- MECE
    3. 모호성을 피하기 -- 당근빠따다. MECE
    4. 표준 - 나는 이것에 원칙까지 첨부하고 싶다. 원칙없는 소프트웨어 아키텍처라니
    5. 설계이유구성 - 이것도 당근이다. MECE에 해당하는 기법이다.
    6. 문서를 최신으로 -.-  : 젤 지키기 어렵지만 꼭 해야 하는거다.
    7. 목적에 적합한 문서리뷰 - 이것도 당근빠따 어떤이는 이걸 소프트웨어 평가라고 하지만 다리잡고 말리고 싶다. 아키텍처 평가가 그리 쉬운게 아니기 때문에...


    결국 쓰고나면 또 컨설팅인가... 에헤라디야...

    아래글은 소프트웨어 아키텍처 인 프락티스와 소프트웨어 다큐먼팅 관련책에서 나온글들임

    RPC vs RMI

    Posted 2006. 8. 29. 00:36
    RMI is focused on Java, with connectivity to existing systems using native methods. This means RMI can take a natural, direct, and fully powered approach to provide a distributed computing technology that allows us to add Java functionality throughout the system. To get the cross-platform portability that Java provides, RPC requires a lot more overheads than RMI. RPC has to convert the arguments between architecture so that each computer can use its native datatype. RMI’s biggest limitation is it can only call methods in Java. To call methods written in other languages it has to rely on other technologies like JNI, JDBC, RMI-IIOP, RMI-IDL etc. Whereas RPC does not translate well into Distributed object systems, where program-level objects residing in different address space is needed.




    이전에 공부하던 자료인데 쓰려면 다 쓸데가 있나보다.
    미들웨어의 기초적 설명

    S/W Architecture and Architecture Trends

    Posted 2006. 8. 25. 20:06
    간단하게 설명한 아키텍처 문서 ( 내용은 빈약한 편임 그러나 간단하게 설명함 )
    http://www.surfscranton.com/architecture/ArchitectureHome.htm

    server side 닷 com의
    talk ... ^^
    http://www.theserverside.com/tt/talks/library.tss

    재미난 사이트들이 많다. ^^

    Okay, I wasn't planning on having a Part IV of my series on "Architecture Dilemmas:O/R Mapping." (Part I, Part II, and Part III are available here. In addition, a single PDF file is also available.)

    What prompted Part IV was my reading Ted Neward's blog on why he thinks O/R mapping is The Vietnam Of Computer Science. If you manage to read over the Vietnam history, Ted makes some interesting point on the problems of O/R Mapping. I tend to agree with most of them; in fact, I mentioned most of them as well (though maybe not as eloquently). It is also interesting in the light that I spent about two hours yesterday debating some of these issues in a meeting with several other architects.

    Toward the end of the article Ted offers the following solutions:

    1. Abandonment.
    2. Wholehearted acceptance. (move to an OODBMS)
    3. Manual mapping. (write code by hand - iBATis would fall here as well)
    4. Acceptance of O/R-M limitations. get the X% (50%,80% whatever) you can get out of O/R mapping
    5. Integration of relational concepts into the languages. (e.g. LinQ)
    6. Integration of relational concepts into frameworks. (embedded data-rows/data sets etc in classes to hold data, use typed data sets as well)

    Ted recommends going with solution #1 or in his words "...Worse, it is a quagmire that is simply too attractive to pass up, a Siren song that continues to draw development teams from all sizes of corporations (including those at Microsoft, IBM, Oracle, and Sun, to name a few) against the rocks, with spectacular results. Lash yourself to the mast if you wish to hear the song, but let the sailors row."

    The way I see it "Computer Science" now has more than 10 years of experience with O/R mapping technologies and the limitations of O/R mapping are well noted. In fact, the good O/R mappers "Accept O/R limitations" (#4 above) and provide mechanisms to by go directly at the data or provide hints for the database etc. And as I said in Part III there are situations where O/R mapping is not the best fit (e.g. reporting), but as someone at the meeting yesterday said, if you have serious reporting needs you would probably have a separate database (e.g. Datamart) just for that.

    I think Ted is too quick to forgo the savings of O/R mapping (those X percentile of code you don't need to write, the fact that you externalize the data model from your code etc.) and the fact that for many problems (yes, these are "just" the simple ones, but how many times all of y our application is complicated) O/R mapping will be sufficiently good out of the box--which is,by the way, exactly why tools like Rails are getting so popular. We don't need or want to write this rote code over and over again.

    I still think that if you don't expect O/R mapping to be a silver bullet which will absolve you of all your database pains--O/R mapping provides you with a good balance between benefits and costs.

    Posted by Arnon Rotem-Gal-Oz at 12:12 AM  Permalink | Comments

    « PREV : 1 : 2 : 3 : NEXT »