김군...

구글이 마이크로소프트(MS)의 웹브라우저인 ‘인터넷 익스플로러(IE) 6’ 버전 지원을 중단키로 하면서 국내 누리꾼들이 비상이 걸렸다. IE 6 사용자가 줄어들고 있는 외국과 달리 국내에선 여전히 IE 6 이용자 수가 많기 때문. 심지어 지난해 말부터는 다시 늘어나 누리꾼 절반 가까이가 IE 6를 쓰고 있는 실정이다.

■구글 “익스플로러 6, 3월부터 지원중단”

구글은 G메일과 구글 독스(Docs), 캘린더 등 자사 서비스가 오는 3월 1일부터 IE 6에 대한 지원을 중단할 예정이라고 지난달 30일(현지시간) 공지했다. 그간 구글은 유튜브와 자사 사이트들에서 익스플로러 사용자들에게 버전을 업그레이드할 것을 권고해 왔었다. IE 6가 웹표준을 지키지 않는데다 보안이 취약하다는 것이다.

그러나 구글이 아예 IE 6에 대한 배척에 나선 직접적인 계기는 최근 벌어진 중국에서의 해킹 사건 때문이다. 구글은 이날 공지를 통해 “최근 중국으로부터 브라우저의 취약점을 파고든 정교한 사이버 공격으로 문제가 발생했다”며 “향후 비슷한 사건의 방지를 위해서도 사용자들이 브라우저를 업그레이드할 것을 권장한다”고 밝혔다.
구글은 인터넷 익스플로러7 버전 이상, 파이어폭스 3.0 이상, 구글 크롬 4.0 이상, 애플 사파리 3.0 이상의 브라우저를 사용해 줄 것을 당부했다. 구글의 이런 조치에 앞서 프랑스와 독일은 자국민들에게 인터넷 익스플로러 사용을 자제하라고 권고한 바 있다.

■IE 6 사용비율, 세계 13%·국내 50%

IE 6는 2000년대 초반 돌풍을 일으킨 윈도XP 운영체제에 끼워 팔렸다. 그러나 뒤이어 나온 브라우저들에 비해 현저히 보안이 취약하고 웹표준을 지키지 않아 인터넷 환경을 악화시킨다는 지적을 받아 왔다. 심지어 제작사인 MS가 사용자들에게 익스플로러8 등 웹표준과 보안성을 강화한 제품으로 변경할 것을 권하고 있을 정도다.

이 때문에 IE 6에 대한 퇴출 운동은 그간 전세계적으로 진행돼 왔다. 해외에서 일어난 ‘IE 6 노모어(Nomore)’, ‘IE 6 머스트 다이(Must Die)’ 등의 캠페인에 이어 지난해 말엔 국내에서도 한 웹 개발자가 ‘익스플로러6 이제 그만’이라는 홈페이지(ie6nomore.kr)를 열고 100만명을 목표로 서명운동과 배너달기에 나서기도 했다.

그러나 이같은 캠페인으로 전세계 점유율은 지속적인 하락 추세를 그려왔지만 국내에서는 오히려 지난해 9월 이후 IE 6 사용자의 비율이 오르는 기현상이 벌어지고 있다. 시장조사기관 스탯카운터에 따르면 전세계 IE 6 이용자 비율은 지난해 1월 23%에서 올들어 13.4%로 꾸준히 감소했지만 국내 IE 6 이용자 비율은 지난해 9월 39%로 저점을 찍은 뒤 올 1월에는 50%로 다시 올랐다.

구글코리아 관계자는 “당장 IE 6로 구글 서비스를 이용하지 못하는 것은 아니나 앞으로 구글 서비스의 새로운 기능이 나와도 IE 6에서는 이를 사용하지 못할 가능성이 있다”며 “또 IE 6 사용으로 발생하는 버그를 수정하는 등의 지원책도 더 이상 제공되지 않을 것”이라고 설명했다. 이 관계자는 “국내 IE 6 이용자들도 버전을 업그레이드하거나 다른 브라우저를 이용할 것을 권장한다”고 덧붙였다.

[디자인 패턴]

=================================================================================

 디자인 패턴은 많은 프로그래머들이 성공적인 프로젝트에서 무수히 반복해 사용했던 문제 해결 기술을 발견해 정형화한 것이다.
 각 패턴은 특정 맥락의 문제를 효과적으로 해결할 수 있게 해주며, 패턴들은 해결하는

 문제의 맥락(GoF의 용어로는 Intent)이 다르다.

 분명 패턴을 잘 이해하고 사용하면, 수많은 개발자, 연구자들의 “아하(Aha)!” 경험을

 (그들이 들였던 노력에 비해서는) 손쉽게 사용할 수 있게 된다.
 하지만 패턴은 빈번히 발생하는 ‘특정’ 문제에 대해 적용할 수 있는 해결책이기
 때문에 객체들 간의 게임에 법칙에 관한 일반 룰까지 알려주지는 않는다.

 패턴이 좋은 게임의 규칙을 이용해 객체들의 관계를 맺고 있음은 분명하다
 (좋은 게임의 규칙을 사용하고 있지 않다면, 특정 문제에 대해서도 좋은 해결책이 나올 수 없다).
 그런데 이 때 패턴이 암묵적으로 사용하는 게임의 법칙을 모르면,
 패턴이란 고도의 게임 전술을 유용하게 구사할 수 없게 된다.
 패턴은 성공한 프로젝트 코드들에서 발견, 일반화되는 과정에서 코드에서
 디자인으로 추상화됐기 때문에 이들 다시 코드로 구체화하려면 패턴이 사용하는
 게임의 법칙을 알아야 한다.
 이를 모른다면 장님이 코끼리 다리 만지듯 패턴을 사용하게 될 위험이 있다.
 패턴을 사용해 프로그램을 만들었는데, 괜히 복잡해지기만 하던 걸? 글쎄….

 

===============================================================================================
[객체지향 설계의 원칙]
 
- 소프트웨어 설계 모델의 메타적인 원리가 디자인 패턴의 단위라고 한다면
  디자인 패턴에 등장하는 좋은 구조들에 대한 메타적인 원리가 (ISP, SRP, DIP, OCP, LSP)정도 된다.

=================================================================================================

 

- LSP::리스코프 치환 원리
  "서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다."
  상속은 구현 상속(extends 관계)이든 인터페이스 상속(implements 관계)이든
  궁극적으로는 다형성을 통한 확장성 획득을 목표로 한다.
  LSP 원칙도 역시 서브 클래스가 확장에 대한 인터페이스를 준수해야 함을 의미한다.
  다형성과 확장성을 극대화하려면 하위 클래스를 사용하는 것보다 상위의 클래스(인터페이스)를 이용하는 것이 좋다.

주의점::

 “서브 클래스에서는 기반 클래스의 사전 조건과 같거나 더 약한 수준에서 사전 조건을 대체할 수 있고,
   기반 클래스의 사후 조건과 같거나 더 강한 수준에서 사후 조건을 대체할 수 있다.”

=================================================================================================

 

- SRP::단일 책임 원리
  SRP는 하나의 클래스에 한 가지 책임을 가르치는 원칙이다.
  우리는 설계 관점에서 우리가 인식하지 못하는 SRP 위반을 자주 하게 된다.
  이 위반을 경계하기 위해 깊은 통찰력이 필요하지도 않다.
  단지 머리에 ‘책임’이란 단어를 상기하는 습관이면 된다. 

 

  적절한 책임 분배는 객체지향 원리들의 대전제 격인 OCP뿐 아니라 다른 원리들을 적용하는 기초가 되어준다

  설계자는 분리의 ‘크기(granularity)’를 고민한다.

  작은 단위로 섬세하게 사용할 수 있는 미세단위(fine-grained)로 구분할 것인가, 아니면 단순하지만

  입도가 큰(COARSE-GRAINED) 단위로 구분할 것인가에 대해서 말이다.
  이 문제의 경우 애플리케이션에서 문제 영역이 각각 서로 다른 케이스 바이 케이스로 이루어지기 때문에 명백히

  일관적으로 적용할 가이드라인을 제공하기 힘들다.

  하지만 그 기준은 대상에 대한 복잡도, 크기, 용도가 된다.
  복잡도가 높고 부피가 큰데 반해 그 용법이 단순하다면 COARSE-GRAINED가 적합하다.
  역으로 복잡도가 낮고 부피가 작으며 용법이 다양하다면 fine-grained가 적합하다.

 

 SRP 위반의 악취는
   -‘여러 원인에 의한 변경(divergent change)’
   -‘산탄총 수술(shotgun surgery)’
  을 들 수 있다.

 

  여러 원인에 의한 변경은 한 클래스를 여러 가지 다른 이유로 고칠 필요가 있을 때 발생한다.
  즉, 하나의 클래스에 여러 책임이 혼재하고 있어서 하나의 책임의 변화가 다른 책임에게 영향을 준다.

  산탄총 수술이란 하나의 책임이 여러 클래스에 분산되어 있기 때문에 발생한다.
  한 클래스가 너무 많은 책임을 맡고 있어도 곤란하지만,
  책임을 식별하지 못해 이를 담당할 클래스를 만들지 않고 여러 클래스에 흩뿌려 놓는 것 또한 문제가 있다.
  이는 보통 프로그램의 전체 책임을 올바로 분담하지 못해서 발생하게 된다.

 SRP를 적용하면 클래스의 숫자가 늘 수는 있다.
 하지만 클래스 숫자의 증가가 프로그램의 복잡도 증가와 비례하는 것은 아니다.
 오히려 SRP를 잘 따르는 프로그램은 적절한 책임 분배로 인해 클래스 숫자와
 프로그램의 복잡도가 반비례하는 경향이 있다고도 할 수 있게 된다.

====================================================================================================

 

- OCP::개방 폐쇄 원리
 소프트웨어 구성 요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 대해서는 개방돼야 하지만
 변경에 대해서는 폐쇄되어야 한다고 말한다.
 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화해야 한다는 의미다.
 목적은 앞의 예처럼 객체간의 관계를 단순화해 복잡도를 줄이고, 확장·변경에 따른 충격을 줄이는 데 있다.

 

주의점::

 OCP에서 주의할 점은 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려
 관계가 더 복잡해져서 설계를 망치는 경우가 있다는 것이다.
 설계자의 좋은 자질 중 하나는 이런 크기 조절과 같은 갈등 상황을 잘 포착하여
 (아깝지만) 비장한 결단을 내릴 줄 아는 능력에 있다.

 모듈 영역에서 예측하지 못한 확장 타입을 만났을 때 인터페이스 변경하려는 안과 어댑터를 사용하려는

 안 사이에서 갈등하게 된다.
 위의 두 예에서처럼 변경의 충격이 적은 후자를 택하는 경우가 대부분이다.
 한 번 정해진 인터페이스는 시간이 갈수록 사용하는 모듈이 많아지기 때문에 바꾸는

 데 엄청난 출혈을 각오해야 한다.
 자바의 deprecated API가 대표적인 경우다.

 즉, 인터페이스는 가능하면 변경해서는 안 된다.
 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요하다.
 물론 과도한 예측은 불필요한 작업을 만들고 보통, 이 불필요한 작업의 양은 크기 마련이다.
 따라서 설계자는 적절한 수준의 예측 능력이 필요한데, 설계자에게 필요한 또 하나의 자질은 예지력이다.
 

 인터페이스 설계에서 적당한 추상화 레벨을 선택하는 것이 중요하다.
 우리는 추상화라는 개념에 '구체적이지 않은' 정도의 의미로 약간 느슨한 개념을 갖고 있다.
 그래디 부치(Grady Booch)에 의하면 ‘추상화란 다른 모든 종류의 객체로부터 식별될 수 있는
 객체의 본질적인 특징’이라고 정의하고 있다.
 즉, 이 '행위'에 대한 본질적인 정의를 통해 인터페이스를 식별해야 한다.

=====================================================================================================
High Cohesion, Loose Coupling::높은 응집도, 낮은 결합도
=====================================================================================================

 

낮은 응집도를 갖는 구조는 변경이나,확장 단계에서 많은 비용을 지불해야 하며 높은 결합도의 경우도 마찬가지이다.

응집도는 ‘하나의 클래스가 하나의 기능(책임)을 온전히 순도 높게 담당하고 있는 정도’를 의미하며
이들은 서로 조화될수록 그 구조는 단순해진다.

응집도가 높은 동네에서 내부 개체가 변했을 때 다른 개체에 충격을 주는 것은 오히려 당연한 징후이다.
이들은 하나의 책임아래 서로 유기적인 관계를 갖고 있기 때문에 내부 개체가 변했을 때 다른 개체의 변경 확률이 높아진다.
마치 예쁜 부츠를 사면 부츠에 어울리는 치마를 입어야 하듯이…

응집도의 종류는 다양한데 다음은 권장할 만한 순기능적 응집 관계들이다.

 

* 기능적 응집(Functional Cohesion)
일관된 기능들이 집합된 경우를 말하며 <그림 3>의 데이터 맵퍼는 DB 처리라는 기능 항목의 높은 응집성을 갖는다.

 

* 순차적 응집(Sequential Cohesion)
한 클래스 내에 등장하는 하나의 소작업(메쏘드)의 결과가 다음 소작업(메쏘드)의
입력으로 사용되는 관계(파이프라인 방식의 처리 체인 관계).

 

* 교환적 응집(Communicational Cohesion)
동일한 입력과 출력 자료를 제공하는 메쏘드들의 집합을 말하며,
팩토리 클래스는 전형적인 교환적 응집도가 높은 인터페이스를 갖는다.

 

* 절차적 응집(Procedural Cohesion)
순서적으로 처리되어야 하는 소작업(메쏘드)들이 그 순서에 의해 정렬되는 응집관계

 

* 시간적 응집(Temporal Cohesion)
시간의 흐름에 따라 작업 순서가 정렬되는 응집관계

 

* 논리적 응집(Logical Cohesion)
유사한 성격의 개체들이 모여 있을 경우를 말하며 java.io 클래스들의 경우가 대표적인 예이다.

 

이와 반해 결합도는 ‘클래스간의 서로 다른 책임들이 얽혀 있어서 상호의존도가 높은 정도’
를 의미하며 이들이 조합될수록 코드를 보기가 괴로워진다.
이유는 서로 다른 책임이 산만하고 복잡하게 얽혀있기 때문에 가독성이 떨어지고 유지보수가 곤란해지기 때문이다.
이유는 필요 없는 의존성에 있다.
마치 키보드의 자판 하나가 고장나도 키보드 전체를 바꿔야 하는 것처럼.
하나의 변경이 엄청난 민폐를 야기하는 관계이다.

다음은 수용할 수 있는 수준의 결합 관계들이다.

 

* 자료 결합(Data Coupling)
두 개 이상의 클래스가 매개변수에 의해서 결합 관계를 가지므로 낮은 수준의 결합도로 연관되는 경우

 

* 스탬프 결합(Stamp Coupling)
자료 결합의 경우에서 매개변수 일부만을 사용하는 경우

 

* 제어 결합 (Control Coupling)
두 클래스간의 제어 이동이 매개변수를 이용하여 사용되는 경우로 커맨드 패턴이 대표적인 사례이다.

구글이 크롬OS라는 새로운 운영체제를 발표했습니다. 구글이 지난 7월에 처음 크롬 OS의 존재를 이야기하면서 안드로이드와는 전혀 별개의 새로운 운영체제라고 하여 많은 사람들이 의아해 했습니다. 이미 안드로이드가 큰 이슈가 되며 채택되어가고 있는데 왜 구글은 전혀 별개의 새로운 운영체제를 개발하는지 두개가 상충되는 부분은 없는지 궁금해 했습니다. 안드로이드는 모바일폰에서부터 넷북까지 아우를 수 있는 플랫폼으로 알려져 있는데 새로운 넷북용 OS를 개발한다고 하니까요.

구글의 대답은 서로 다른 장치를 위한 서로 다른 운영체제라는 것이었습니다. 안드로이드는 작은 스크린 사이즈를 가지는 모바일 폰을 위주로 개발되었고, 크롬은 10인치 가량의 큰 스크린 사이즈를 가지는 넷북을 위해 적합하게 개발되어 서로 충돌하지 않는다고 했습니다. 하지만 크롬 OS가 공개되기전 이미 몇몇 PC 제조사들이 안드로이드 넷북을 개발하여 출시했습니다. 물론 구글이 말한대로 현재의 안드로이드는 작은 스크린 크기를 가지는 장치들에 적합하기 때문에 출시된 넷북들은 아직 쓸모있는 수준이 못되었습니다. 가능성만을 살짝 보여주었을 뿐이지요. 그래도 안드로이드 기반의 넷북 개발에 들어간 업체들은 크롬OS가 신경쓰일 수 밖에 없었습니다.

마침내 크롬OS가 공개되었고 그동안의 우려는 깨끗이 사라졌습니다. 크롬OS는 ‘웹브라우저가 OS였고 웹페이지가 애플리케이션’이었습니다.

새로운 형태의 애플리케이션 프레임워크나 API가 존재하는 운영체제가 아니었기에 충돌할 부분은 별로 없었습니다. 이 새로운 운영체제는 장기적으로 구글이 클라우드 컴퓨팅 시장으로 가고자 하는 비전을 명확히 보여주었습니다. 하지만 각광을 받고 있는 안드로이드와는 달리 당장은 틈새 시장을 위한 제품으로 윈도우즈와 인텔이 장악하고 있는 시장과 산업 구조에 큰 영향을 주기는 힘들것 같습니다. 하지만 앞으로는 어떨까요?

크롬OS를 공개할때 구글의 창업자인 세르게이 브린은 공식 발표 이후에 “안드로이드와 크롬OS는 시간이 지나며 서로 수렴하게 될 것이다”고 말을 했습니다. 이것은 폰이 점점 PC를 닮아가고 있고 PC가 점점 이동성과 연결성이 중요해지고 있다는 흐름과도 맞아 떨어집니다. 또한 두 프로젝트에 모두 리눅스와 웹킷(WebKit)이 사용되니 가능성은 충분하죠.

하지만 현재는 전혀 다른 두개의 프로젝트로 관리되고 있고 언제쯤 이 두개의 프로젝트가 합쳐질수 있을지, 기술적으로 가능할지, 뚜렷한 목표가 있는지에 대해서는 아직 알수가 없습니다. 언젠가 이 두개가 만났을때의 그 가능성에 대해서는 많은 기대와 상상을 하게 됩니다. 저는 안드로이드에 대해서 ‘모바일 컴퓨팅도 클라우드로 간다. 그 흐름에 가장 적합한 플랫폼이 안드로이드이며 남보다 앞장서 갈것이다”라고 항상 이야기를 하는데 그 길에서 크롬 OS와 만나게 될것 같습니다.

‘왜 애초에 하나의 궁극적인 플랫폼을 내놓지 않았는가’에 대해서는 웹에 기반한 구글의 소프트웨어 개발 방식이 잘 들어가 있다고도 볼 수 있습니다. 지구를 지배할 궁극의 플랫폼을 개발하는데는 5년이 걸릴지 10년이 걸릴지 모릅니다. 대신 일단 불완전하더라도 제품을 내어놓고 하나둘씩 발전시켜 나아가는 방식을 구글은 운영체제에도 적용하고 있네요. 구글맵이 처음 나왔을 때 웹에서 지도 정보를 검색하는 것 정도로 봤지, 지금 처럼 턴바이턴 내비게이션 회사들을 한방에 몰아세울지 생각도 못했습니다. 안드로이드와 크롬OS가 발전하여 하나가 되는 것은 먼 훗날일지 모르겠지만 큰 혁신이 될 것이라는 것은 짐작할 수 있습니다.

요즈음의 안드로이드로 돌아와보면, 안드로이드는 폰을 위한 플랫폼이라고 했는데 그 부분은 이제 상당 부분 완료가 되어가고 있습니다. 안드로이드는 단계적으로 다른 형태의 장치를 지원해가고 있는데 2.0 버전에서 나온 결과물을 봤을때 내년 안드로이드 3.0 에서는 공식적인 형태의 안드로이드 MID가 출현할 수 있을 것 같습니다. 루머에 의하면 다음 버전의 안드로이드는 국내 제조사와 작업하고 있다는 이야기도 있으니 더 기대가 됩니다.

M3
- MOF(Meta Object Facility)
- M2 수준에 속한 메타 모델을 정의하는 메타메타 모델

M2
- UML 기반 설계를 가능케하는 모델 요소를 정의하는 메타 모델

M1
- 사용자 모델을 도식화하는 모델 계층

M0
- 런타임 인스턴스 계층
- 모델이  코드를 생성하고, 그것을 실행하는 단계

 

Immutable이란.. Immutable이란 생성후 변경 불가한 객체입니다. 그래서 immutable에는 set 메소드가 없습니다. 멤버 변수를 변경할 수 없습니다. return type이 void인 메소드도 없습니다. 주로 void 메소드는 뭔가를 하고(하지 않을 수도 있고.. ) 멤버변수를 변경하는 역할을 하는 것이기 때문에 쓸 일이 거의 없습니다. (물론, 콘솔에 뭔가를 찍는 것과 같은 예외적인 void는 있을 수 있습니다.) Immutable을 쓰면, 멀티 쓰레드 환경에서 좀 더 신뢰할 수 있는 코드를 만들어 내기가 쉽습니다. 멀티 쓰레드 프로그램을 짜보셨다면 아시겠지만, 멀테 쓰레드 환경에서는 에러보다 비정상적 작동의 경우가 많습니다. 에러도 아니기 때문에 찾아내기도 어렵습니다. 게다가 항상 생기는 것도 아니고 백번에 한번 천번에 한번 식으로 문제가 생겨 정말 머리 아픈 경우가 한 두번이 아닙니다. Immutable을 쓰게 되면, 이런 요소들을 많이 줄일 수 있습니다. 대표적인 Immutable 클래스 String, Boolean, Integer, Float, Long 등등이 있습니다. 여기서 주의할 점은 변경불가라는 것은 heap 영역에서의 변경불가라는 뜻입니다. String a="a"; a="b"; 와 같이 재할당은 가능합니다. 이는 a가 reference하고 있는 heap 영역의 객체가 바뀌는 것이지 heap영역에 있는 값이 바뀌는 것이 아닙니다. String vs StringBuffer String과 StringBuffer에는 비슷한 메쏘드들이 많이 있어서 비슷해 보이지만, 결정적인 차이가 있습니다. String은 Immutable 입니다. StringBuffer는 아닙니다. StringBuffer가 String에 비해서 훨씬 빠르다는 얘기를 들어보셨나요? 그건 객체를 새로 생성할 필요가 없기 때문입니다. String에는 없고 StringBuffer에만 있는 대표적인 메소드는 append, delete 등일 겁니다. 멤버 변수를 변화시켜 값을 바꿀 수 있는 거죠. 그런데 잘 보며 이들의 리턴은 StringBuffer 타입입니다. 어차피 얘네도 객체를 새로 만들어낸다면, String과 별 차이가 없어보입니다. 그러나 객체를 새로 만들어 내는 것이 아닙니다.  아래 코드를 실행시켜보세요. StringBuffer b = new StringBuffer(); StringBuffer a = b.append("test"); System.out.println(a == b); true가 나옵니다. 객체를 새로 만드는 것이 아니라 return this 로 되어있습니다. 굳이 리턴을 하는 이유는 아래와 같은 코딩을 가능하게 해주려는 것 같습니다. StringBuffer test = new StringBuffer(); test.append("a").append("b").append("c").append("d"); 와 같은 식으로 여러줄 코딩을 한 줄로 할 수 있게 해주려는 것 같습니다.. 아님 말구요.-_-; Immutable의 유용성과 위험성 멀티쓰레드 환경에서 하나의 객체에 접근을 하는데 각각의 쓰레드끼리는 영향을 받으면 안 되는 경우가 있습니다. 그럴 때 한 번 만들어진 객체의 값이 변하지 않는다는 게 보장이 되면 편하겠죠. String a  = ""; while(어떤 조건문){     a += "머시기";     if(딴 조건문){         break;     } } 위와 같은 코드는 쓰면 안 됩니다. a+= "머시기" 구문이 문젭니다. 객체를 계속 생성해 냅니다. Immutable은 값이 계속 변경될 수 있는 곳에 쓰면 메모리 왕창 잡아먹습니다. 값이 완전히 정리된 후에 한 큐에 immutable로 만들어 내셔야 합니다. (물론, 가비지 컬레션이 돌면서 정리를 하기 때문에 치명적으로 위험한 수준의 행동은 아닙니다.) java.util.Collections 에 unmodifiable머시기 하는 메쏘드들이 있습니다. 얘네들을 이용하면, Set, List, Map 등을 immutable로 사용할 수 있습니다. 다만, add, put과 같은 메쏘드를 호출할 경우에는 UnsupportedOperationException 가 발생합니다. 예외 상황을 고려해야 합니다. Immutable은 보통 final 클래스로 정의합니다. 처음에 자바를 할 때 String이란 객체에 ltrim이란 메쏘드를 추가하고 싶었습니다. (왼쪽만 trim하는 메쏘듭니다.) 상속을 받아 새로운 클래스를 만들어 해결하려고 했습니다. 헛, 그런데 final로 정의가 되어있어서 상속을 받을 수가 없더군요. final로 정의가 되지 않으면, 상속을 받은 클래스가 Immutable을 깨버릴 수가 있기 때문입니다. 잘못된 Immutable의 구현 package immutable; import java.text.SimpleDateFormat; import java.util.Date; public final class WrongImmutable {     private final Date date;     private final SimpleDateFormat dateFormat;     public WrongImmutable(Date date){         this.date = date;         dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");     }     public String getMessage(){         return dateFormat.format(date);     } } 위의 소스를 보세요. date라는 변수가 final로 정의 되어있으며, setter가 없어 오직 생성자에서만 값을 지정할 수 있는 것 같아보입니다. 그러나 아래와 같은 테스트 클래스를 실행시켜보시면, 위의 코드가 잘못되었음을 알 수 있습니다. package immutable; import java.util.Date; public class WrongImmutableTest {     public static void main(String[] args) {         Date testDate = new Date();         WrongImmutable wrongImmutable = new WrongImmutable(testDate);         testDate.setTime(testDate.getTime() + 10000000);         System.out.println(wrongImmutable.getMessage());     } } WrongImmutable의 생성자에 인자로 넣은 Date를 외부에서 값을 변경시키면 WrongImmutable의 멤버 변수의 값이 변경이 되고 맙니다. Immutable에서는 멤버 변수가 외부로 공개되어 변경이 가능하면 안 됩니다. 그럼 처음에 원했던 대로 정상적인 Immutable이 되도록 하려면 인자로 받은 Date 객체를 그대로 사용하는 것이 아니라, 어떤 식으로든 복사를 해서 써야 합니다. 생성자에서 멤버 변수의 값을 할당하는 부분을 this.date = new Date(date.getTime()); 와 같이 바꿔야 합니다. 자바에 진짜 Immutable이란 건 없다! java의 reflection을 이용하면 변경 가능합니다. 다음 코드를 실행시켜 보세요. import java.lang.reflect.Field; public class EditUsingReflection {     public static void main(String[] args) throws IllegalArgumentException, SecurityException, IllegalAccessException, NoSuchFieldException {         String s = "string!";         edit(s);         System.out.println(s);     }     public static void edit(String s) throws IllegalArgumentException, IllegalAccessException, SecurityException, NoSuchFieldException {         Field stringValue = String.class.getDeclaredField("value");         stringValue.setAccessible(true);         stringValue.set(s, s.toUpperCase().toCharArray());     } }   [출처] Immutable에 대해서..|작성자 와니

이클립스 폴더의 실행파일의 위치에
eclipse.ini 파일이 있음.

그것을 열어보시면

-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m   
이부분에서
맨 마지막의 -Xms40m와 -Xmx512m을 각각 -Xms128과 -Xmx256m으로 고치기.

-Xms와 -Xmx는 JVM이 차지하는 최소메모리와 최대메모리를 설정하는 옵셥임.
최대메모리가 너무 높아 다른 프로그램의 메모리 영역과 충돌하여 발생하는 것임.

 

아키텍팅(architecting)”에 대한 기본적인 개념에 접근하는 총 4부 시리즈 중 첫 번째 글입니다. 필자는 핵심 용어들을 정의하고 잘 설계된 아키텍처가 전개 환경에 어떤 기여를 하는지를 조명합니다.

 

이 세계는 점점 더 소프트웨어에 의존하고 있다. 소프트웨어는 유비쿼터스 셀폰 뿐만 아니라 복잡한 항공 제어 시스템의 필수적인 요소이다. 사실 우리가 지금 당연하다고 여기는 많은 혁신들도 소프트웨어가 없었다면 존재하지 않았을 것이다. 금융, 유통, 공공 분야 같은 전통적인 조직도 소프트웨어에 깊이 의존하고 있다.

 

이러한 혁신과 기업들이 살아 남기 위해서, 소프트웨어는 필요한 기능을 제공해야 하고, 품질도 갖추어야 하고, 기대하는 대로 사용할 수 있어야 하며, 합리적인 가격에 제공되어야 한다.

 

이 모든 특성들은 소프트웨어의 아키텍처에 영향을 받는다. 나는 이 글에서 “소프트웨어 중심 시스템(software-intensive systems)”에 대해 이야기하고자 한다. IEEE는 다음과 같이 정의한다.

 

소프트웨어 중심 시스템(software-intensive system)은 소프트웨어가 디자인, 구현, 전개, 시스템의 진화에 중요한 영향을 미치는 시스템을 의미한다. [IEEE 1471. "아키텍처 정의" 섹션 참조]

 

이 글에서 “아키텍처”라는 용어는 “소프트웨어 아키텍처”의 동의어이다. 이 글에서는 소프트웨어 중심 시스템을 중심적으로 다루겠지만, 소프트웨어 중심 시스템 역시 신뢰성이나 퍼포먼스 같은 특정 품질을 제대로 이행하기 위해서는 하드웨어가 필요하다. 나중에 보다 자세히 설명하도록 하겠다.

 

아키텍처 정의

 

“아키텍처”에 대한 정의는 부족함이 없다. 정의만을 모아서 관리하는 웹 사이트가 있을 정도니까 말이다.1 이 글에 사용되는 정의는 IEEE Std 1472000- IEEE Recommended Practice for Architectural Description of Software-Intensive Systems(IEEE 1471)2에서 발췌하였다. 핵심 내용은 볼드체로 표시했다.

 

아키텍처는 컴포넌트로 구체화된 시스템의 기본적인 조직이며, 환경에 대한 관계이며, 디자인과 진화를 이끄는 원리이다. [IEEE 1471]

 

이 표준은 이 정의와 관련하여 다음 용어를 정의하고 있다.

 

시스템은 특정 기능이나 기능 세트를 달성하도록 조직된 컴포넌트의 컬렉션이다. 시스템이라는 용어에는 개별 애플리케이션, 전통적인 의미의 시스템, 하위 시스템, 시스템의 시스템, 제품 라인, 제품군, 전체 엔터프라이즈, 기타 이익의 집합 등을 아우른다. 시스템은 이 환경에서 한 개 이상의 미션을 수행하기 위해 존재한다. [IEEE 1471]

 

환경또는 컨텍스트는 그 시스템에 대한 개발, 작동, 정책, 기타 영향들의 설정과 환경을 결정한다. [IEEE 1471]

 

미션은 스테이크홀더가 목표를 달성하기 위해 시스템이 수행할 사용이나 연산이다. [IEEE 1471]

 

스테이크홀더는 시스템에 관련된 개인, 팀, 조직이다. [IEEE 1471]

 

우리들도 볼 수 있듯이, “컴포넌트”라는 용어는 이러한 정의 전반에 걸쳐 사용된다. 하지만 아키텍처의 대부분의 정의는 “컴포넌트”를 정의하지는 않는다. IEEE 1471도 예외는 아니다. 따라서 산업계에서 여러 가지 의미로 사용하기 때문에 매우 모호하다. 컴포넌트는 논리적이거나 물리적이거나, 기술 독립적이거나 기술적이거나, 대단위 이거나 소단위 이거나이다. 이 글의 목적상 나는 UML 2.0 스팩에서의 컴포넌트의 정의를 사용한다. 그리고 나는 우리가 마주칠 수 있는 다양한 아키텍처 엘리먼트를 아우르기 위해 매우 느슨하게 용어를 사용하겠다. 객체, 기술 컴포넌트(이를 테면, Enterprise JavaBean), 서비스, 프로그램 모듈, 레거시 시스템, 패키지 애플리케이션 등이 포함된다. 다음은 “컴포넌트”에 대한 UML 2.0D의 정의이다.

 

[컴포넌트는] 이것의 콘텐츠를 담고 있는 시스템의 모듈 부분이고 이것의 표현은 이것의 환경 내에서 대체 가능하다. 컴포넌트는 제공된 필수 인터페이스의 관점에서 작동을 정의한다. 컴포넌트는 유형으로서 작동하고 이것의 순응성은 필요한 인터페이스에 의해 정의된다. (정적 및 동적 의미로 정의된다.)

 

여기에 제공된 정의는 많은 다른 개념들을 아우른다. 이것은 이 글 후반에 논의되겠다. 산업계에는 “아키텍처”에 대해 일반적으로 동의된 정의가 없지만 다른 정의들도 고려하여 이들간 유사성을 관찰해 보는 것도 좋은 일이다. 중요한 내용은 볼드체로 표시했다.

 

아키텍처는 소프트웨어 시스템의 구성, 구조적 엘리먼트와 시스템을 구성할 인터페이스의 선택, 그러한 엘리먼트들간 협업에 지정된 것으로서 작동과 함께, 그러한 엘리먼트를 점진적으로 더 큰 하위 시스템으로의 구성, 이러한 조직을 이끄는 아키텍처 스타일, 이러한 엘리먼트와 인터페이스, 협업, 구성에 대한 중요한 결정 세트이다. [Kruchten]4

 

프로그램 또는 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 엘리먼트를 구성하는 시스템의 구조 또는 구조이자, 그러한 엘리먼트들을 외부로 보이는 속성이자 이들간 관계이다. [Bass et al] 5

 

[아키텍처는] 조직화된 구조이며 시스템의 제휴된 작동이다. 시스템의 제휴된 작동이다. 아키텍처는 인터페이스, 부분들과의 관계, 어셈블링의 제약조건 등으로 분할될 수 있다. 인터페이스를 통해 인터랙팅하는 부분들에는 클래스, 컴포넌트, 하위 시스템 등이 있다. [UML 1.5]6

 

시스템의 소프트웨어 아키텍처나 시스템의 컬렉션은 소프트웨어 구조와, 그 시스템을 구성하고 있는 구조들 간 인터랙션에 대한 중요한 디자인 결정들로 구성되어 있다. 디자인 결정은 원하는 품질을 보장해야 한다. 디자인 결정은 시스템 개발, 지원, 관리에 개념적인 기반을 제공한다. [McGovern]7

 

정의는 다소 다르더라도 우리는 여기에서 공통점을 발견하게 된다. 예를 들어, 모든 정의는 아키텍처는 구조와 작동에 관한 것이며, 중요한 결정들만 관여하며, 아키텍처 스타일에 순응하고, 스테이크홀더와 환경에 영향을 받으며, 이론적 근거에 입각하여 결정을 구체화 한다. 이제부터 자세히 설명하도록 하겠다.

 

아키텍처가 구조를 정의한다.

 

누군가가 당신에게 “아키텍처”에 대해 설명하라고 하면 십중팔구는 구조라고 말할 것이다. 이것은 빌딩 또는 다리 같은 도시 엔지니어링 구조와 관련이 있다. 작동, 적합성, 미학 같은 아이템의 다른 특성들도 물론 존재하지만 이것이 가장 익숙하고 자주 언급되는 구조적인 특성이다.

 

당신이 누군가에게 그가 작업하고 있는 소프트웨어 시스템의 아키텍처에 대해 설명하라고 요청하면 그는 시스템의 구조적 양상을 보여주는 다이어그램을 보여줄 것이다. 이 양상이 아키텍처 레이어든, 컴포넌트든, 분산 노드든 상관없이 말이다. 구조는 아키텍처의 진실로 중요한 특성이다. 아키텍처의 구조적 양상은 여러 가지 방법으로 드러나기 때문에 아키텍처에 대한 정의는 모호하다. 구조적 엘리먼트는 하위 시스템, 프로세스, 라이브러리, 데이터베이스, 전산 노드, 레거시 시스템, 제품 등이 될 수 있다.

 

아키텍처의 많은 정의들은 구조적 엘리먼트를 인정할 뿐만 아니라 구조적 엘리먼트의 구성, 이들의 관계, 인터페이스, 파티셔닝도 다루고 있다. 이들 각 엘리먼트들은 다양한 방식으로 제공될 수 있다. 예를 들어, 커넥터는 소켓이 될 수 있고, 동기식 또는 비동기식일 수 있으며 특정 프로토콜과 제휴될 수 있다.

 

그림 1은 구조적 엘리먼트의 예제이다. 이 그림은 주문 처리 시스템을 나타내는 구조적 엘리먼트들을 포함하고 있는 UML 클래스 다이어그램을 보여주고 있다. 세 개의 클래스 OrderEntry, CustomerManagement, AccountManagement가 있다. OrderEntry 클래스는 CustomerManagement 클래스와 AccountManagement 클래스에 의존하여 나타난다.

 

 

아키텍처가 작동을 정의한다.

 

아키텍처가 구조적 엘리먼트를 정의하는 것 외에도 구조적 엘리먼트들간 인터랙션을 정의한다. 원하는 시스템 작동을 제공하는 것이 이러한 인터랙션이다. 그림 2는 UML 시퀀스 다이어그램으로서 많은 인터랙션들을 보여주고 있다. 시스템은 주문 처리 시스템에서 주문의 생성을 지원할 수 있다. 여기에서 다섯 개의 인터랙션이 보인다. 첫 번째는 Sales Clerk 액터가 OrderEntry 클래스의 인스턴스를 사용하여 주문을 만든다. OrderEntry 인스턴스는 CustomerManagement 클래스의 인스턴스를 사용하여 고객의 상세를 얻는다. OrderEntry 인스턴스는 AccountManagement 클래스의 인스턴스를 사용하여 주문을 만들고, 주문 아이템들에 주문을 파퓰레이트 하고 주문을 한다.

 

 

그림 2는 그림 1의 연장선상에 있다. 그림 2에서 정의된 인터랙션에서 그림 1에서 보여준 종속관계를 이끌어 낼 수 있다. 예를 들어, 그림 2의 인터랙션을 보면 OrderEntry는 CustomerManagement의 인스턴스에 의존한다. 이러한 의존성은 상응하는 OrderEntry와 CustomerManagement 클래스 간 의존성 관계에 반영된다. (그림 1)

 

아키텍처가 중요한 엘리먼트에 집중한다.

 

아키텍처가 구조와 작동을 정의하지만 모든 구조와 모든 작동에 대해서 그렇게 하는 것은 아니다. 오직 중요한 엘리먼트들에만 그렇게 한다. 중요한 엘리먼트는 길고 지속적인 영향력을 갖고 있는 엘리먼트이다. 이러한 엘리먼트들은 필수 작동과 제휴되어 있고 신뢰성과 확장성 같은 중요한 품질을 다루고 있다. 일반적으로 아키텍처는 이러한 엘리먼트의 세분화된 상세를 신경 쓰지 않는다. 아키텍처 중요성은 경제적인 중요성도 띤다. 특정 엘리먼트를 다른 것보다 귀중히 여기는 이유는 생성 비용과 변경 비용이 관련되어 있기 때문이다.

 

아키텍처가 중요한 엘리먼트에만 집중하기 때문에 시스템 관점에서 생각해 봐야 한다. 이는 대부분 아키텍처와 관련이 있다.8 아키텍처는 아키텍트가 복잡성을 관리하는 것을 돕는 시스템의 추상화이다.

 

중요한 엘리먼트 세트는 정적이지 않고 시간이 지나면서 변한다. 변화하는 요구 사항, 리스크 분석, 실행 가능한 소프트웨어 구현, 레슨 등의 결과로 중요한 엘리먼트는 변하기 마련이다. 하지만 변화에 직면해서도 아키텍처가 안정적이라는 것은 좋은 아키텍처라는 신호이자, 아키텍팅 과정이 잘 실행되었다는 신호이며, 좋은 아키텍트라는 신호이다. 아키텍처가 비교적 소소한 변경 때문에 지속적으로 개정되어야 한다면 이것은 좋은 징조가 아니다. 하지만 아키텍처가 비교적 안정적이라면 정 반대이다.

 

아키텍처가 스테이크홀더의 필요를 조정한다.

 

아키텍처는 궁극적으로 스테이크홀더의 필요를 다루기 위해 만들어진다. 하지만 모든 필요를 다 맞추기는 불가능하다. 예를 들어, 스테이크홀더가 지정된 시간 안에 특정 기능을 요청하지만 이러한 두 가지 필요(기능과 타임프레임)은 상호 배타적이다. 스케줄러에 맞추기 위해 범위게 줄어들거나, 초과된 타임프레임에서 기능이 제공 될 수도 있는 것이다. 이와 비슷하게 다른 스테이크홀더들은 상충하는 필요를 표현하기 때문에 적절한 밸런스가 필요하다. 따라서 트레이드오프는 아키텍팅 프로세스와 협상의 중요한 측면이자 아키텍트가 갖추어야 할 자질이다.

 

스테이크홀더들의 필요에 대해 생각해 보자.

 

ㆍ 엔드 유저는 매력적이고 정확한 작동, 퍼포먼스, 신뢰성, 가용성, 보안 등에 관심이 있다.
ㆍ 시스템 관리자는 매력적인 작동, 관리, 모니터링 툴에 관심이 있다.
ㆍ 마케터는 경쟁력 있는 기능, 출시일, 다른 제품들과의 포지셔닝, 비용 등에 관심이 있다.
ㆍ 고객은 비용, 안정성, 스케줄에 관심이 있다.
ㆍ 개발자는 명확한 요구 사항, 간단하고 일관성 있는 디자인 방식을 원한다.
ㆍ 프로젝트 매니저는 프로젝트 예견, 스케줄, 효과적인 자원활용, 예산 등을 신경 쓴다.
ㆍ 유지 보수를 하는 사람들은 포괄적이고 일관되면서 문서화가 된 디자인 방식과 변경의 용이성 등을 생각한다.

 

이 리스트를 보면 알겠지만 아키텍트의 또 다른 도전은 스테이크홀더들이 시스템이 필요한 기능을 제공하는 것에만 관심을 갖는 것은 아니라는 점이다. 위에 제시한 관심 영역들은 비기능적이다. 시스템의 기능에는 어떤 기여도 하지 않는다. (비용과 스케줄링 등). 이 같은 영역은 시스템 품질이나 제약조건을 나타낸다. 비기능적 요구 사항들은 아키텍트에 있어서 가장 중요한 요구 사항이다.

 

아키텍처가 이론에 입각한 결정을 구체화 한다.

 

아키텍처의 중요한 측면은 단순히 최종 결과인 아키텍처에 있지 않다. 이론적 근거가 필요하다. 따라서 아키텍처와 결정에 대한 이론적 근거를 문서화 하는 것이 중요하다.

 

이 정보는 많은 스테이크홀더와 관련이 있다. 특히 시스템을 관리해야 하는 사람들과 관련이 있다. 이 정보는 결정에 대한 이론적 근거를 알고 싶어하는 아키텍트에게도 매우 귀중한 것이다. 예를 들어, 이 정보는 아키텍처가 리뷰 될 때와 아키텍트가 결정을 판단할 때 사용된다.

 

아키텍처가 아키텍처 스타일에 순응한다.

 

대부분의 아키텍처들은 비슷한 영역들을 공유하는 시스템에서 파생된다. 이러한 유사성을 아키텍처 스타일이라고 한다. 이는 특정 유형의 패턴으로도 생각할 수 있다. 종종 복잡한 합성 패턴일 때가 많다. (많은 패턴들이 함께 적용된다.) 패턴과 마찬가지로 아키텍처 스타일은 경험의 성문화를 나타내고, 아키텍트가 그러한 경험들을 재사용 할 기회를 찾는 것은 좋은 방법이다. 아키텍처 스타일의 예제에는 분산 스타일, 파이프와 필터 스타일, 데이터 중심 스타일, 규칙 기반 스타일 등이 있다. 시스템은 한 가지 이상의 아키텍처 스타일을 보여준다. Shaw 와 Garlan은 다음과 같이 설명한다.

 

[아키텍처 스타일]은 구조적 조직의 관점에서 시스템 군을 정의한다. 보다 구체적으로 말하면, 아키텍처 스타일은 컴포넌트와 커넥터 유형의 어휘를 정의하고 이들이 결합되는 방식에 대한 제약 조건들을 정의한다.

 

그리고 UML의 관점에서는

 

[패턴은] 주어진 상황에서 일어나는 일반적인 상황에 대한 일반적인 솔루션이다.

 

경험을 재사용 하는 것 외에도 아키텍처 스타일(또는 패턴)의 적용은 아키텍트의 삶을 더 풍요롭게 만든다. 스타일은 이론적 근거라는 관점에서, 그리고 작동의 관점에서 문서화되기 때문이다. (생각을 좀 덜해도 되고 스타일을 참조하기 때문에 아키텍처 문서들이 줄어든다.)

 

아키텍처가 아키텍처 스타일에 순응한다.

 

시스템은 환경 안에 거하고, 이 환경은 아키텍처에 영향을 미친다. 이것을 “정황 속의 아키텍처”라고 한다. 환경은 시스템이 운영되고 아키텍처에 영향을 미치는 바운더리를 결정한다. 아키텍처에 영향을 미치는 환경적 요인들에는 아키텍처가 지원할 비즈니스 미션, 시스템 스테이크홀더, 내부적인 기술 제약조건들(조직의 표준에 순응하는 제약조건 등), 외부적인 제약조건(외부 시스템에 대한 인터페이스의 필요라든가, 외부적인 규제 표준에 순응할 것 등) 등이 포함된다.

 

반대로, Bass, Clements, Kazman11이 설명한 것처럼 아키텍처도 환경에 영향을 미친다. 기술적인 관점에서 아키텍처의 생성이 환경을 변화시킬 뿐만 아니라, 아키텍처의 생성이 기능적인 관점에서 환경을 변경시킨다.

 

소프트웨어 중심 시스템의 경우 언제나 고려해야 하는 환경의 특정 측면이 있다. 유용한 소프트웨어가 되려면 실행될 수 있어야 한다. 실행될 수 있으려면 소프트웨어는 하드웨어에서 실행되어야 한다. 따라서 결과 시스템은 소프트웨어와 하드웨어의 결합이고, 신뢰성과 퍼포먼스 같은 속성들이 갖추어져야 한다. 소프트웨어는 하드웨어와 별개로 이를 달성할 수 없다.

 

IEEE Std 12207-1995, IEEE Standard for Information Technology -- Software Life Cycle Processes는 IEEE 1471 시스템 정의와는 다르게 시스템을 정의한다. (이것은 소프트웨어 중심 시스템에 초점이 맞춰져 있다.) 하지만 시스템 엔지니어링 분야에 대한 정의는 동의하고 있다.

 

[시스템은] 필요나 목적을 달성할 수 있는 기능을 제공하는 한 개 이상의 프로세스, 하드웨어, 소프트웨어, 장치, 사람들로 구성된 통합 구성체이다. [IEEE 12207]

 

Rational Unified Process for Systems Engineering (RUP SE)의 설정에도 비슷한 정의가 있다.

 

[시스템은] 기업이 비즈니스 목적이나 미션을 수행하기 위해 사용하는 서비스를 제공하는 일종의 리소스이다. 시스템 컴포넌트에는 하드웨어, 소프트웨어, 데이터, 작업자 등이 포함된다.

 

시스템 엔지니어링 분야에서, 소프트웨어, 하드웨어, 사람들간 상쇄 현상이 일어난다. 예를 들어, 퍼포먼스가 중요하다면, 소프트웨어나 사람이 아닌 하드웨어에 특정 시스템 엘리먼트를 구현하는 결정을 내리게 된다. 고객에게 유용한 시스템을 제공하려면 소프트웨어나 하드웨어에서 구현된 인터페이스 보다는 인간이라는 인터페이스를 제공하게 된다. 좀더 복잡한 시나리오의 경우는 소프트웨어, 하드웨어, 사람들이 결합을 해야 한다. (따라서 본 시리즈에서는 소프트웨어 외의 다른 엘리먼트도 참조할 것이다.)

 

시스템 엔지니어링이 소프트웨어와 하드웨어를(사람들도 포함) 피어로서 취급하고, 따라서 하드웨어가 소프트웨어 대한 제 2의 클래스로서 취급 받거나 소프트웨어를 실행하는 단순한 기구로서 취급 받게 되는 상황을 방지한다. 또는 소프트웨어가 하드웨어에 대한 제 2의 클래스이고 하드웨어를 위한 단순한 도구로 취급 받지 않도록 한다.

 

아키텍처가 팀 구조에 영향을 미친다.

 

아키텍처는 주어진 영역을 다루는 관련 엘리먼트들의 그룹핑을 정의한다. 예를 들어, 주문 처리 시스템을 위한 아키텍처는 주문 시작, 계정 관리. 고객 관리, 업무 수행, 외부 시스템과의 통합, 영속성, 보안에 대한 엘리먼트들을 그룹핑 한다.

 

이들 각각의 그룹핑은 다른 기능 세트를 필요로 한다. 따라서 소프트웨어 개발팀 구조가 정의되었다면 아키텍처로 정렬하는 것 맞다. 하지만 아키텍처는 초기 팀 구조에 의해 영향을 받는 경우가 종종 있다. 이것은 매우 위험한 일이다. 이상적인 아키텍처 상이 아니다. Conway의 법칙에서는 “컴파일러 상에 실행되는 네 개의 그룹이 있다면 4-pass 컴파일러를 갖게 된다.”라고 명시하고 있다. 실제로 우리는 의도하지 않았는데도 아키텍처를 만들어서 기업에 반영하는 아키텍처들을 만든다.

 

하지만 이렇게 다소 이상적인 뷰가 늘 실질적은 것은 아니다. 순전히 실제적인 이유로 인해 현재 팀 구조와 기능은 무엇이 가능한 지에 대한 매우 실질적인 제약조건을 나타내고 아키텍처는 이를 고려해야 한다.

 

아키텍처가 모든 시스템에 존재한다.

 

모든 시스템은 아키텍처를 갖고 있다. 아키텍처가 공식적으로 문서화 되지 않았더라도, 시스템이 하나의 엘리먼트로 구성된 아주 단순한 시스템이라도 말이다. 아키텍처에 대한 문서는 상당한 가치가 있다. 문서화된 아키텍처는 그렇지 않은 것 보다 조심스럽고 효과적으로 다루어져야 한다. 아키텍처의 기록 과정에서 통찰력이 생기기 때문이다.

 

반대로, 아키텍처가 문서화 되지 않으면 품질, 관리 가능성, 베스트 프랙티스의 채택 등을 입증할 방법이 없다. 오늘날 대부분, 아키텍처는 문서화 되지 않았으며 이는 의도적이기 보다는 일종의 사고다.

 

아키텍처가 특정 범위를 갖고 있다.

 

많은 종류의 아키텍처가 있다. 빌딩이나 도시 엔지니어링 건축물들도 아키텍처로 잘 알려져 있다. 소프트웨어 엔지니어링 분야에서도 우리는 다양한 형태의 아키텍처를 만나게 된다. 예를 들어, 소프트웨어 아키텍처의 개념 외에도, 엔터프라이즈 아키텍처, 시스템 아키텍처, 조직적 아키텍처, 정보 아키텍처, 하드웨어 아키텍처, 애플리케이션 아키텍처, 인프라 아키텍처등의 개념들을 보게 된다. 또한 특정 범위의 아키텍팅 행위를 정의하는 용어도 있다.

 

안타깝게도 산업계에는 이러한 용어나 서로간의 관계에 대한 어떤 동의도 없다. 따라서 같은 용어가 다른 의미를 갖게 되고 한 가지를 의미하는데 두 개 이상의 용어들이 생겨난다. 하지만 이러한 용어들의 범위는 그림 3처럼 한정된다. 이 그림과 그 뒤에 나오는 논의를 생각해 보면 여러분이 동의할 수 없는, 기업에서 다르게 사용했던 엘리먼트들이 많음을 알 수 있다. 그렇다. 이러한 용어들이 산업계에 존재하지만 의미에 대한 동의가 없다.

 

 

그림 3 의 엘리먼트:

 

ㆍ 소프트웨어 아키텍처. 이것은 이 글의 핵심 주제이다.
ㆍ 하드웨어 아키텍처. CPU, 메모리, 하드 디스크, 프린터 같은 주변 장치, 이러한 엘리먼트에 연결하는데 사용되는 엘리먼트 등이 있다.
ㆍ 조직적 아키텍처. 비즈니스 프로세스, 기업 구조, 역할과 책임, 기업의 핵심 능력 등이 여기에 속한다.
ㆍ 정보 아키텍처. 정보가 조직화 되는 구조를 의미한다.
ㆍ 소프트웨어 아키텍처, 하드웨어 아키텍처, 조직적 아키텍처, 정보 아키텍처. 이 모두는 전체적인 시스템 아키텍처의 하위 세트들이다.
ㆍ 엔터프라이즈 아키텍처. 하드웨어, 소프트웨어, 사람들 같은 엘리먼트를 갖고 있다는 점에서 시스템 아키텍처와 비슷하다. 하지만 엔터프라이즈 아키텍처는 비즈니스와 깊이 연결되어 있다. 비즈니스 목적의 달성에 집중하며 비즈니스 기민성과 조직의 효율성 같은 아이템과 관련이 있다. 엔터프라이즈 아키텍처는 기업 바운더리를 넘나든다.

 

물론 이에 상응하는 아키텍트(소프트웨어 아키텍트, 하드웨어 아키텍트)와 아키텍팅(소프트웨어 아키텍팅, 하드웨어 아키텍팅)이 있다.

 

지금까지 정의를 통해 고찰했다. 많은 의문점이 남아있을 것이다. 엔터프라이즈 아키텍처와 시스템 아키텍처의 차이는 무엇인가? 엔터프라이즈가 시스템인가? 데이터 중심 소프트웨어 애플리케이션에서 정보 아키텍처가 데이터 아키텍처와 같은 것인가? 불행히도 이러한 질문에 대한 정확하고 동의를 이룬 답은 없다.

 

현재까지는 다양한 용어들이 존재하지만, 이러한 용어들에 대한 일관된 정의와 관계 방식에는 동의 된 바가 없다. 따라서 여러분의 기업과 관련된 용어들을 선택하여 적절히 정의할 것을 권한다. 그렇다면 적어도 일관성은 이룰 것이고 오해로 빚어진 의사소통 문제도 줄어들 것이다.

 

요약

 

소프트웨어 아키텍처의 중심적인 특성을 정의하는 것에 대해 집중 조명해보았다. 하지만 아직도 많은 의문점들이 남아있다. 소프트웨어 아키텍트의 역할은 무엇인가? 아키텍트가 주로 하는 일은 무엇인가? “아키텍팅”의 효용성은 무엇인가? 이러한 질문에 대한 해답은 후속 시리즈에서 지속적으로 다루도록 하겠다.

 

Notes

1 Software Engineering Institute (SEI) Architecture Website -- http://www.sei.cmu.edu/architecture/definitions.html 참고

2 IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.

3 Object Management Group Inc., UML 2.0 Infrastructure Specification: Document number 03-09-15. September 2003.

4 Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley Professional 2003.

5 Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, Second Edition. Addison Wesley 2003.

6 Object Management Group Inc., OMG Unified Modeling Language Specification Version 1.5, Document number 03-03-01. March 2003.

7 James McGovern, et al., A Practical Guide to Enterprise Architecture. Prentice Hall 2004

8 역할에 대해서는 다음 시리즈에서 다룰 것이다.

9 Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline. Prentice Hall 1996.

10 Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide. Addison Wesley 1999.

11 Bass et al., Op. cit.

12 IEEE Computer Society, IEEE Standard for Information Technology -- Software Life Cycle Processes. IEEE Std 12207-1995.

13 Murray Cantor, "Rational Unified Process for Systems Engineering." The Rational Edge, August 2003. http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf

 

제공 : DB포탈사이트 DBguide.net 

 

ISO 9126

구분	분류	내용
ISO 9126-1	주특성과 부특성	- 소프트웨어 품질 특성과 Metrics
ISO 9126-2	External Metrics	-         소프트웨어가 사용될 때의 외부적 성질 표현 -         실행가능 소프트웨어 시험/운영으로 측정
ISO 9126-3	Internal Metrics	-         설계/코드와 관련된 소프트웨어의 내부 속성을 측정 -         설계/코딩 중인 소프트웨어 제품에 적용

	주특성	주특성 내용	부특성
품질 특성	기능성	소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능을 만족하는 기능을 제공하는 소프트웨어 제품의 능력	적절성
			적밀성
			상호 운용성
			준수성
			보안성
	신뢰성	소프트웨어가 규정된 조건에서 사용될 때 규정된 성능수준을 유지하거나 사용자로 하여금 오류를 방지할 수 있도록 하는 소프트웨어 제품의 능력	성숙성
			결함허용성
			회복성
			유용성
	사용성	소프트웨어가 규정된 조건에서 사용될 때, 사용자에 의해 이해되고, 학습되며 선호될 수 있게 하는 소프트웨어 제품의 능력	이해성
			학습성
			운용성
	효율성	규정된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력	시간행동
			자원이용
	유지보수성	소프트웨어 제품을 변경할 수 잇는 능력, 변경에는 운영환경과 요구사항 및 기능적 사양에 따름 소프트웨어의 수정, 개선, 혹은 개작 등이 포함된다.	분석성
			변경성
			안정성
			시험성
	이식성	다양한 환경에서 운영될 수 있는 소프트웨어 제품의 능력	적응성
			설치성
			병행 존재성
			적합성
			대체성