RFID 도입을 위한 표준화와 기술 동향

유비쿼터스 환경을 완성하기 위한 핵심기술이 바로 RFID다. 이미 50년 전의 기술이 차세대 네트워크 세상을 여는 첨병 역할을 맡고 있다. 1990년 중반부터 진행된 RFID의 표준화는 이제 그 결실을 맺어가면서, 각 주파수별로 유통/물류, 교통, 우편, 조달 등에서의 활용에 큰 혁신을 가져올 것으로 기대하고 있다.

RFID 태그를 리더를 통해서 판독하고 정보를 가져오는 RFID 기술로만 따진다면 바코드 업그레이드 수준에 지나지 않지만, 상품 정보가 EPCIS에 등록돼 RFID/USN이라고 불리우는 네트워크를 형성할 때, 제대로 차세대 네트워크 환경의 초석으로 자리잡게 된다.

RFID/USN은 모든 사물에 부착된 RFID 또는 센서를 초소형 무선장치에 접목해 이들 간의 네트워킹과 통신으로 실시간 정보를 획득, 처리, 활용하는 네트워크 시스템이다. RFID 기술은 90년대 중반부터 일부 응용분야에 대해 국제표준화기구(ISO)에서 표준화가 논의되기 시작했으며, 실생활에서 사용하고 있는 교통카드, 도어 개폐 장치 등의 비 접촉식 IC 표준이 이미 제정됐다. 한편 전파를 사용하는 RFID의 표준화는 ISO/IEC JTC1 SC31(자동인식기술분야)에서 국제표준화을 진행했으며, 2004년 9월에 5개 주파수에 대한 표준이 확정됐다.

국제표준 현황
ISO/IEC 18000의 표준의 주파수별 표준규격은 5개의 주파수대로 구성돼 있다. 18000-2는 저주파대역(135kHz 이하), 18000-3은 단파대역(13.56MHz), 18000-7(433MHz)과 18000-6(860∼960MHz), 18000-4(2.45GHz)는 UHF 대역의 주파수대에서 동작하는 시스템의 표준이다.

저주파대역의 국제표준인 18000-2는 사용주파수 대역이 135kHz이하를 사용하는 RFID로 상호유도(Inductively coupled) 방식을 이용하는 근거리용으로 주로 사용된다. 또한 데이터의 전송속도가 낮으므로 출입통제, 보안, 동물 인식과 추적, 재고자산추적과 같은 분야에서 사용되고 있는 표준이다. 단파대역의 국제표준인 18000-3은 13.56MHz 대역의 주파수를 사용하는 RFID 시스템은 10Cm이내의 근거리 접근성을 갖는 서비스 영역인 출입통제, 보안, 물류시스템에서 주로 사용되고 있다. 이 대역은 NFC(Near Field Communication)포럼이 노키아와 필립스, 소니의 주도하에 결성되면서 860～960MHz 대역의 UHF RFID와 많은 부분에서 경쟁하고 있다.

13.56MHz 대역의 RFID 태그는 보안 인증의 주요 장점을 갖고 있으나, 안테나와 칩의 복잡성이 UHF 대역보다 높고 생산의 정교성을 요구하고 있다. 이 대역의 RFID 태그 가격이 높아 버스 카드와 같은 스마트 카드 영역에 한정돼 발전할 것으로 보인다. RFID 관계자들은 13.56MHz의 문제점을 해결할 수 있는 기술이 바로 860∼960MHz 대역의 UHF RFID 태그가 될 것이라고 보고 있다. 이 대역의 태그는 안테나 구조가 간단하고 생산 방식이 다양해 비용 대비 성능이 좋다는 것이 가장 큰 장점이다. 또한 인식 거리도 휴대폰에 리더기를 내장할 경우, 1m에서 수cm까지 조절이 가능하기 때문에 응용 분야가 다양하다는 것이다. 현재까지 RFID 기술은 단방향으로 리더기가 RFID 태그를 읽어들이는 기술에서 읽고 쓸 수 있는 양방향의 NFC 기술까지 13.56MHz 대역을 중심으로 발전되어 왔다.

UHF대역을 이용한 433MHz 대역의 국제표준인 18000-7은 미국 등에서 컨테이너 관리용으로 사용되고 있다. 이 대역은 수출입 수하물인 컨테이너의 전자봉인과 유통 중 환경의 변화, 즉 온도, 습도와 충격 등의 추적에 사용해 테러방지를 위해 강제적으로 사용하려는 움직임이 있다. 최대 인식거리는 100m내외로 수출입 항만, 공항, 내륙컨테이너 기지 등에서 주로 이용된다.

시장논리 적용한 EPC글로벌 Gen2 표준 확실시

860∼960MHz 대역을 이용하는 18000-6 국제표준은 통상인식거리가 3-4m이며 5개의 국제표준 중 RF출력을 가장 크게 사용하는 방식의 RFID이다. 최대 4W EIRP(Effective Isotropic Radiated Power) 전력을 사용하며 최대인식거리는 10m까지로 알려져 있다.

18000-6 국제표준은 전세계 유통/물류를 위해 주파수 대역도 100MHz나 되며, 각 나라에서는 860～960MHz의 범위에서 각국의 국내 환경에 알맞게 사용할 수 있도록 했다. 이렇게 전세계 시장에서 유통되면서 100MHz 대역의 넓은 주파수 범위에서 동작하도록 설계해야 하므로, 태그 설계와 태그 안테나에 대한 기술이 큰 이슈로 부각되고 있다. 그런데 이 표준에도 불구하고 EPC글로벌(global)에서 작업하고 있는 규격이 세계 유통/물류 시장에서 더 크게 확산될 전망이다. EPC글로벌은 기존의 MIT Auto-ID 센터에서 개발한 기술을 표준화하고 상용화를 추진하기 위해 2003년 10월에 설립된 기관으로 EPC(Electronic Product Code)를 기반으로 EPC 네트워크를 구성하기 위한 기술을 개발하고 표준화를 추진 중에 있다. EPC 코드는 기존의 바코드 관리 기관에서 제안한 RFID용 코드체계로서 64비트, 96비트, 256비트의 상품번호 체계에 기반을 두고 있으며, EPC글로벌은 여러 종류의 표준을 개발 중에 있고, 이 중에서도 EPC글로벌 5, 즉 UHF Gen2 규격은 월마트, 메트로 등 세계 유수 유통업체와 DoD, FDA 등이 규격채택을 선언해 900MHz대역의 사실상 표준으로 자리잡고 있다.

RFID/USN 기술 개념
RFID/USN은 모든 사물에 부착된 RFID 또는 센서를 초소형 무선장치에 접목해 이들 간의 네트워킹과 통신으로 실시간 정보를 획득, 처리, 활용하는 네트워크 시스템이다. RFID/USN에서는 사물의 이력정보뿐만 아니라 사물을 둘러싸고 변화하는 물리 환경계의 다양한 정보를 획득해 생산성, 안전성과 인간 생활 수준의 고도화를 실현한다.

RFID/USN은 먼저 인식정보를 제공하는 RFID를 중심으로 발전하고 이에 센싱 기능이 추가돼 이들 간의 네트워크가 구축되는 USN 형태로 발전할 것이라는 게 전문가들의 예상이다. 현재의 사람 중심에서 사물 중심으로 정보화를 확대하고 궁극적으로는 광대역망(BcN)과 통합해 유비쿼터스 네트워크가 가능한 환경을 구현하기 위한 것이다.

RFID/USN 산업은 RFID 태그, RFID 리더, 센서, 센서노드, 싱크노드, USN 게이트웨이를 개발하는 하드웨어 산업과 네트워크, 보안, 미들웨어, 소프트웨어를 개발하는 소프트웨어 산업, 시스템 통합과 서비스를 제공하는 서비스 산업 등으로 구성된다.

USN 하드웨어 산업은 센서와 RFID 태그/리더 공급업체, 센서노드와 싱크노드 공급업체, USN 게이트웨이 공급업체로 구성되며, USN 소프트웨어 산업은 네트워킹 및 보안 소프트웨어, 미들웨어와 각종 응용 소프트웨어를 개발 공급하는 업체, USN 서비스 산업은 SI 업체와 각종 응용 서비스 업체로 구성된다.

RFID 태그, Chipless Sensor로 진화
정보통신부는 'USN은 어느 곳에나 부착된 태그와 센서노드로부터 사물과 환경 정보를 감지, 저장, 가공, 통합하고 상황인식 정보와 지식 컨텐츠 생성을 통해 언제, 어디서, 누구나 원하는 맞춤형 지식 서비스를 자유로이 이용할 수 있는 첨단 지능형 사회의 기반 인프라'로 정의하고 있다. 이 개념에 따르면, RFID/USN을 정보통신의 획득과 유통을 위한 기본 인프라로 인식하고 있다는 점이며, 이를 통해 RFID는 다양한 응용 분야에서 적용할 수 있다.

USN은 초기에 RFID를 통해 개체를 식별하는 단계에서 센싱 기능을 부과해 환경 정보를 동시에 취득하는 단계를 거쳐 태그 상호간 통신으로 애드 혹(Ad hoc) 네트워크를 구축하고 기능이 적은 다른 태그를 제어하는 것으로 발전할 것으로 보인다.

이는 RFID 시스템의 특성인 네트워크 효과를 발휘하는 부가가치 창출의 기대 때문에 태그인식(Read) → 이력관리(Read/Write) → 환경정보 센싱(Sensing) → RFID 태그간 통신(Ad-hoc Network) → RFID 태그제어(Control) 순으로 발전하는 것이다. 태그를 발전단계에 따라 구분하면 수동형, 이력관리형, 센서/능동형, 네트워크형, 제어관리형의 5단계로 발전할 것으로 정의되고 있다.

또한 태그의 기능도 수동형(Passive) → 반 능동형(Semi-Active) → 능동형(Active) → Chipless Sensor 태그로 진화되고 있다. 초기에는 태그만을 인식하는 단계였으나 그 후에는 쓰기가 가능하고 주변 환경에 적응할 온도, 습도, 오염정보, 균열정보의 환경정보까지 탐지하는 등 유비쿼터스 네트워크가 가능하게끔 발전을 거듭하고 있다. 또한 주파수 대역별로 다른 국제 표준화 문제를 해결하기 위해서는 태그에 에너지가 필요하며, 주변환경별 인식률 에러 문제, 즉 제품별 재질, 포장 재질, 적재상태, 속도에 따른 리더로부터의 정보 수집문제가 최우선 과제다.

하지만 RFID/USN 기술의 발전에 비해 기술 이용에 따른 개인 프라이버시 침해, 개인의 환경, 안전, 보건과 관련한 유해, 노동생활과 고용변화, 사회 문화적 변화에 대비한 요구 또한 커지고 있다. RFID/USN 산업의 활성화를 위해서는 이런 사회적 요구에 따른 기술과 응용 서비스 개발이 적극적으로 추진해야 한다.

현재 국내 RFID 관련 기술개발은 정부와 국책연구기관의 주도로 추진되고 있으며, 국제 공동연구를 통해 기술력 차이를 극복하고, 상용화를 위해 산업체와 공동개발을 추진한다는 체계를 갖고 있다. 특히, 세계 IT시장에서 선구적인 위치를 확보하기 위해 2006년 u-IT 839 전략의 하나로, RFID/USN 기술개발을 선정해 신성장 동력으로 육성하고 있다. 센서 네트워크란 필요한 모든 사물과 위치에 RFID를 부착해 이를 통해 기본적인 사물의 인식정보는 물론 주변의 환경정보까지 탐지해 이를 실시간으로 네트워크에 연결하고, 그 정보를 관리하는 네트워크이며, 전자태그 기술의 연구개발, 표준화, 보급, 활성화 등을 중심으로 연구가 진행되고 있다.

작성자 :이대영 기자

작성일 : 2006년 4월호

원   문 :http://www.ionthenet.co.kr/newspaper/view.php?idx=10989

웹2.0 Startup들

invalid-file

 [관련링크]Web 2.0s Startup Fever

작성일 : 2006.04.14

출   처 :http://www.skyventure.co.kr/innovation2005/new_product/list.asp?Category=9

UML의 기초: Unified Modeling Language 소개

20세기 말을 되돌아보며 --
정확히 1997년 Object Management Group (OMG)이 Unified Modeling Language (UML)을 발표했다. UML의 목표 중 하나는 개발 커뮤니티에 안정적이고, 일반적인 디자인 언어를 제공하는 것이었다. UML은 IT 전문가들이 수년 동안 바라던 통합된 표준 모델링 표기법을 탄생시켰다. UML을 사용하여 IT 전문가들은 시스템 구조와 디자인 계획을 읽고 분산시킬 수 있다. 건축가들이 빌딩의 청사진을 사용하는 것처럼 말이다.

이제 21세기가 되었고 UML은 전문성을 확립하게 되었다. 내가 보고 있는 이력서의 75 퍼센트 정도가 UML을 알고 있다고 쓰여있다. 하지만 면접을 통해 이야기를 해보면 이들이 진정으로 UML을 알지 못하고 있다는 것이 명확해진다. 일반적으로 당시 이슈가 되는 키워드 로서 알고 있거나 표면적인 면만 알고 있는 경우가 대부분이었다. 이것이 바로 내가 이 글을 쓴 이유이다. 이 글을 다 읽었다고 해서 이력서에 UML을 충분히 알고 있다고 쓸 수는 없겠지만, 이 언어를 보다 심도 깊게 연구할 출발선에는 설 정도는 된 것이다.

배경 지식

UML은 컴퓨터 애플리케이션을 모델링 할 수 있는 통합 언어이다. 주요 작성자들은 Jim Rumbaugh, Ivar Jacobson, Grady Booch이고 이들은 원래 그들만의 꽤 괜찮은 방식(OMT, OOSE, Booch)을 갖고 있었다. 결국 이들은 힘을 합쳤고 개방형 표준을 만들었다. (어디서 많이 들어본 소리인가?

J2EE, SOAP, Linux도 비슷한 현상이다.) UML이 표준 모델링 언어가 된 한 가지 이유는 이것이 프로그래밍 언어에 독립적이라는데 있다. (IBM Rational의 UML 모델링 툴은 .NET 뿐만 아니라 J2EE에서도 사용된다.) 또한 UML 표기법 세트는 언어이지 방법론이 아니다. 언어인 것이 중요한 이유는 방법론과는 반대로 언어는 기업이 비즈니스를 수행하는 방식에 잘 맞는다.

UML은 방법론이 아니기 때문에 (IBM Rational Unified Process lingo의 "객체(artifacts)" 같은) 어떤 형식적인 작업 생성물들이 필요 없다. 하지만 정해진 방법론 안에서 쓰이면, 애플리케이션을 개발할 때 애플리케이션을 쉽게 이해할 수 있도록 도와주는 여러 가지 유형의 다이어그램을 제공한다.

이 다이어그램은 현재 사용하고 있는 것의 언어와 원리를 잘 소개하고 있다. 사용중인 방법론에서 생긴 작업 생산품들에 표준 UML 다이어그램을 배치하여 UML에 능숙한 사람들이 프로젝트에 쉽게 참여하여 생산성을 높일 수 있도록 한다. 가장 유용한 표준 UML 다이어그램은 사용 케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 스테이트 차트 다이어그램, 액티비티 다이어그램, 컴포넌트 다이어그램, 전개 다이어그램 등이 있다.

각 유형의 다이어그램을 자세히 설명하지는 않겠다. 대신, 각 다이어그램에 대한 일반적인 개념을 소개하고 자세한 것은 나중에 다루도록 하겠다.

사용 케이스 다이어그램

사용 케이스는 시스템에서 제공한 기능 단위를 설명한다. 사용 케이스 다이어그램의 주요 목적은, 다른 사용 케이스들 간 관계 뿐만 아니라 주요 프로세스에 대한 "액터(actors)" (시스템과 인터랙팅하는 사람)들과의 관계를 포함하여, 개발 팀들이 시스템의 기능적 요구 사항들을 시각화 하는 데 있다. 사용 케이스 다이어그램은 사용 케이스 그룹들을 보여준다.

완전한 시스템에 대한 모든 사용 케이스이거나 관련된 기능을 가진 특정 사용 케이스 그룹(예를 들어, 보안 관리에 관련된 사용 케이스 그룹)의 사용 케이스일 수도 있다. 사용 케이스 다이어그램에 대한 사용 케이스를 보여주려면 다이어그램 중간에 타원을 그려서, 타원의 중앙 또는 아래에 사용 케이스 이름을 적어놓는다. 사용 케이스 다이어그램에 액터(시스템 사용자)를 그리려면 다이어그램의 왼쪽이나 오른쪽에 사람 모양을 그려 넣는다. (얼마나 예쁘게 그리는가는 여러분에게 달려있다.) 액터와 사용 케이스들간 관계는 그림 1에 나타나있다.

사용 케이스 다이어그램은 시스템의 고급 기능과 시스템의 범위를 설명하는데 사용된다. 그림 1의 사용 케이스 다이어그램을 통해, 시스템이 제공하는 기능을 쉽게 표현할 수 있다. 이러한 시스템에서는 밴드 매니저가 밴드가 발매한 CD에 대한 판매 통계 리포트와 Billboard 200 보고서를 볼 수 있다. 또한 레코드 매니저는 특정 CD에 대한 판매 통계 보고서와 Billboard 200 보고서를 볼 수 있다. 이 다이어그램에서는 Billboard Reporting Service라고 하는 외부 시스템에서 우리 시스템이 Billboard 리포트를 전달하고 있다는 것도 볼 수 있다.

또한, 이 다이어그램에 사용 케이스가 없다는 것은 시스템이 수행하지 않은 일을 보여주고 있는 것이다. 예를 들어, 이 다이어그램은 밴드 매니저가 Billboard 200의 다른 앨범들에 수록된 노래를 듣는 방식은 나와있지 않다. Billboard 200에서 Listen to Songs 라는 사용 케이스에 대한 어떤 레퍼런스도 볼 수 없다. 이것은 중요한 포인트이다. 그와 같은 다이어그램에 제공된 명확하고 간단한 사용 케이스 설명을 통해 프로젝트 스폰서는 시스템에 필요한 기능이 존재하는지 여부를 쉽게 볼 수 있는 것이다.

클래스 다이어그램

클래스 다이어그램은 다른 엔터티들(사람, 제품, 데이터)이 서로 어떻게 관계를 맺고 있는지를 보여준다. 다시 말해서, 이것은 시스템의 정적 구조라고 할 수 있다. 클래스 다이어그램은 록밴드, 씨디, 라디오 연주를 논리적 클래스로 나타내는데 사용될 수 있다. 또는 대출, 주택 저당 대출, 자동차 대출, 이자율을 나타내는데도 쓰일 수 있겠다. 클래스 다이어그램은 주로 프로그래머들이 다루는 구현 클래스들을 보여주는데 쓰인다. 구현 클래스 다이어그램은 논리적 클래스 다이어그램과 같은 클래스를 보여준다. 하지만 이 구현 클래스 다이어그램은 같은 애트리뷰트로는 그릴 수 없다. Vectors와 HashMaps 같은 것에 대한 레퍼런스를 갖고 있기 때문이다.

그림 2에서는 세 개의 섹션으로 클래스 다이어그램을 설명하고 있다. 위 섹션은 클래스의 이름을, 중간 섹션은 클래스의 애트리뷰트를, 가장 아래 섹션은 클래스의 연산(“그림 2에서는 세 개의 섹션으로 클래스 다이어그램을 설명하고 있다. 위 섹션은 클래스의 이름을, 중간 섹션은 클래스의 애트리뷰트를, 가장 아래 섹션은 클래스의 연산 ("메소드")을 보여주고 있다.

내 경험으로는 거의 모든 개발자들은 이 다이어그램이 무엇을 하고 있는지를 안다. 하지만 대부분의 프로그래머들은 관계도를 잘못 그리고 있다. 그림 3과 같은 클래스 다이어그램의 경우 상속 관계를 그릴 때에는 화살표 방향을 위로 향하게 하여 수퍼 클래스를 지시하게 하면서 화살표 모양은 완벽한 삼각형이 되도록 해야 한다. 상관 관계는 두 클래스들이 서로를 인식하고 있다면 일직선이 되어야 하고, 클래스의 한 편만 알고 있는 관계라면 화살표 표시가 되어있는 선을 그어야 한다.

그림 3에서, 상속 관계와 두 개의 상관 관계를 보았다. CDSalesReport 클래스는 Report 클래스에서 상속을 받고, CDSalesReport는 한 개의 CD와 관련이 되어 있지만, CD 클래스는 CDSalesReport에 대해 아무것도 모르고 있다. CD와 Band 클래스는 서로에 대해 알고 있고, 두 클래스는 서로 연관되어 있다.

클래스 다이어그램에는 이 보다 더 많은 개념들을 적용할 수 있다. 나중에 설명하도록 하겠다.

시퀀스 다이어그램

시퀀스 다이어그램은 특정 사용 케이스에 대한 상세한 흐름이나 심지어는 특정 사용 케이스의 일부분 까지도 보여준다. 대부분이 설명을 포함하고 있다. 시퀀스에서 다른 객체들 간의 호출관계를 보여주고 있고, 다른 객체들로의 다른 호출까지 상세하게 보여줄 수 있다.

시퀀스 다이어그램은 2차원으로 그려진다. 수직 차원은 발생 시간 순서로 메시지/호출 시퀀스를 보여주고 있다. 수평 차원은 메시지가 전송되는 객체 인스턴스를 나타내고 있다.

시퀀스 다이어그램은 그리기가 매우 간단하다. 다이어그램의 상단에 각 클래스 인스턴스를 박스 안에 놓아 클래스 인스턴스(객체)를 구분한다. (그림 4) 박스 안에 클래스 인스턴스 이름과 클래스 이름을 스페이스/콜론/스페이스 " : "로 분리시킨다. (예, myReportGenerator : ReportGenerator) 클래스 인스턴스가 메시지를 또 다른 클래스 인스턴스로 보내면 클래스 인스턴스를 받는 곳을 가리키는 화살표를 긋는다. 그 라인 위에 메시지/메소드 이름을 적는다. 중요한 메시지의 경우는 원래의 클래스 인스턴스를 다시 향하도록 점선 화살표를 그릴 수 있다. 점선 위에 리턴 값을 라벨링한다. 개인적으로는 리턴 값을 포함하곤 하는데 상세한 부분을 읽기 쉽기 때문이다.

시퀀스 다이어그램을 읽기는 매우 간단하다. 시퀀스를 시작하는 "드라이버(driver)" 클래스 인스턴스가 있는 왼쪽 상단 코너부터 시작한다. 그런 다음, 다이어그램 아래쪽을 각 메시지를 따라간다. 그림 4의 시퀀스 다이어그램 예제에서 전송 메시지에 대한 리턴 메시지는 선택적인 것임을 기억하라.

그림 4의 시퀀스 다이어그램을 읽다 보면 CD Sales Report가 어떻게 만들어지는지를 알 수 있다. aServlet 객체가 우리의 드라이버 예제이다. aServlet은 메시지를 gen이라고 하는 ReportGenerator 클래스 인스턴스로 보낸다. 이 메시지는 generateCDSalesReport 라는 라벨링이 붙는다.

ReportGenerator 객체가 이 메시지 핸들러를 구현한다는 의미이다. 자세히 보면, generateCDSalesReport 메시지 라벨은 괄호 안에 cdId가 있다. gen 인스턴스가 generateCDSalesReport 메시지를 받으면 CDSalesReport로 연속 호출을 하고 aCDReport 라고 하는 CDSalesReport의 실제 인스턴스가 리턴 된다. gen 인스턴스는 리턴된 aCDReport 인스턴스에 호출하면서 여기에 각 메시지 호출에 대한 매개변수를 전달한다. 시퀀스의 끝에서 gen 인스턴스는 콜러였던 aServlet에 aCDReport를 리턴한다.

그림 4의 시퀀스 다이어그램은 전형적인 시퀀스 다이어그램을 상세히 설명한 것이다. 하지만 충분히 이해할 수 있을 것이다. 또한 초보 개발자들에게는 각 레벨 마다 시퀀스를 끊어서 이해하는 것도 좋은 방법이다.

스테이트 차트 다이어그램

스테이트 차트 다이어그램은 클래스가 개입된 다양한 상태(state)를 모델링 하고 그 클래스가 상태간 어떻게 이동하는지를 모델링 한다. 모든 클래스는 상태를 갖고 있지만 각각의 클래스가 스테이트 차트 다이어그램을 가질 수 없다. "중요한" 상태, 말하자면 시스템 작동 중 세 개 이상의 잠재적 상태가 있는 클래스일 경우만 모델링 되어야 한다.

그림 5에서 보듯, 스테이트챠트 다이어그램에는 다섯 개의 기본 엘리먼트들이 사용된다. 시작점(짙은 원), 스테이트 간 이동(화살표), 스테이트(모서리가 둥근 직사각형), 결정 포인트(속이 비어있는 원), 한 개 이상의 종료점(원 내부에 짙은 원이 그려져 있음)이 바로 그것이다. 스테이트챠트 다이어그램을 그리려면 시작점과 클래스의 초기 상태를 향하는 화살표로 시작한다. 다이어그램 어디에나 이 스테이트를 그릴 수 있고 스테이트 이동 라인을 사용하여 연결한다.

그림 5의 스테이트 차트 다이어그램은 중요한 정보를 보여주고 있다. 예를 들어, 대출 프로세스가 Loan Application 상태에서 출발한다고 말할 수 있다. 결과에 따라 사전 승인 프로세스가 완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로 옮겨간다. 이동하는 동안 내린 결정은 결정 포인트로 보여진다. 이동 라인 상의 비어있는 원이 바로 그것이다. 이 예제를 보면 Loan Closing 상태를 거치지 않고는 대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로 갈 수 없음을 알 수 있다. 또한, 모든 대출이 Loan Rejected 상태 또는 Loan in Maintenance 상태에서 끝난다는 것도 알 수 있다.

액티비티 다이어그램

액티비티 다이어그램은 액티비티를 처리하는 동안 두 개 이상의 클래스 객체들 간 제어 흐름을 보여준다. 액티비티 다이어그램은 비즈니스 단위 레벨에서 상위 레벨의 비즈니스 프로세스를 모델링 하거나 저수준 내부 클래스 액션을 모델링 하는데 사용된다. 내가 경험한 바로는 액티비티 다이어그램은 기업이 현재 어떻게 비즈니스를 수행하는지, 또는 어떤 것이 비즈니스에 어떤 작용을 하는지 등의 고차원 프로세스를 모델링 할 때 가장 적합하다. 액티비티 다이어그램은 언뜻 보기에 시퀀스 다이어그램 보다는 덜 기술적이기 때문에 비즈니스 마인드를 가진 사람들이 빠르게 이해할 수 있다.

액티비티 다이어그램의 표기법은 스테이트 차트 다이어그램과 비슷하다. 스테이트 차트 다이어그램과 마찬가지로 액티비티 다이어그램은 초기 액티비티에 연결된 실선으로 된 원에서 시작한다. 이 액티비티는 모서리가 둥근 직사각형을 그려 그 안에 액티비티 이름을 적어 넣으면서 모델링 된다. 액티비티들은 이동 라인을 통해 다른 액티비티들에 연결되거나 결정 포인트의 조건에 제약을 받는 다른 액티비티들에 연결하는 결정 포인트로 연결될 수 있다. 모델링 된 프로세스를 종료하는 액티비티는 (스테이트 차트 다이어그램에서처럼) 종료 포인트에 연결된다. 이 액티비티들은 수영 레인으로 그룹핑 될 수 있다. 이것은 실제로 액티비티를 수행하는 객체를 나타내는데 사용된다. (그림 6)

그림 5의 스테이트 차트 다이어그램은 중요한 정보를 보여주고 있다. 예를 들어, 대출 프로세스가 Loan Application 상태에서 출발한다고 말할 수 있다. 결과에 따라 사전 승인 프로세스가 완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로 옮겨간다. 이동하는 동안 내린 결정은 결정 포인트로 보여진다. 이동 라인 상의 비어있는 원이 바로 그것이다. 이 예제를 보면 Loan Closing 상태를 거치지 않고는 대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로 갈 수 없음을 알 수 있다. 또한, 모든 대출이 Loan Rejected 상태 또는 Loan in Maintenance 상태에서 끝난다는 것도 알 수 있다.

액티비티 다이어그램 예제는 두 개의 객체(밴드 매니저와 리포팅 툴)에 의한 액티비티 제어를 나타내는 두 개의 수영 레인으로 되어있다. 프로세스는 한 밴드에 대한 판매 리포트를 보는 밴드 매니저로 시작한다. 리포팅 툴은 사람이 관리하는 모든 밴드들을 검색하여 디스플레이하고 이중 한 개를 고를 것을 요청한다. 밴드 매니저가 한 밴드를 선택하면 리포팅 툴은 판매 정보를 검색하여 판매 리포트를 디스플레이 한다.

컴포넌트 다이어그램

컴포넌트 다이어그램은 시스템을 물리적으로 볼 수 있도록 한다. 이것의 목적은 소프트웨어가 시스템의 다른 소프트웨어 컴포넌트들(예를 들어, 소프트웨어 라이브러리)에 대해 소프트웨어가 갖고 있는 종속 관계를 보여주는 것이다. 이 다이어그램은 매우 고급 레벨에서 볼 수 있거나 컴포넌트 패키지 레벨에서 볼 수 있다. 주 2

컴포넌트 다이어그램의 모델링은 이 예제에 잘 설명되어 있다. 그림 7은 네 개의 컴포넌트인 Reporting Tool, Billboard Service, Servlet 2.2 API, JDBC API를 보여주고 있다. Reporting Tool에서 출발하여 Billboard Service, Servlet 2.2 API, JDBC API로 가는 화살표는 Reporting Tool이 이들 세 개의 컴포넌트에 종속되어 있음을 나타낸다.

전개 다이어그램

전개 다이어그램은 하드웨어 환경에 시스템이 물리적으로 어떻게 전개되는지를 보여준다. 목적은 시스템의 다양한 컴포넌트들이 어디에서 실행되고 서로 어떻게 통신하는지를 보여주는 것이다. 다이어그램이 물리적 런타임을 모델링 하기 때문에 시스템 사용자는 이 다이어그램을 신중하게 사용해야 한다.

전개 다이어그램의 표기법에는 컴포넌트 다이어그램에서 사용되던 표기법 요소들이 포함된다. 이외에 노드 개념을 포함하여 두 가지 정도 추가되었다. 노드는 물리적 머신 또는 가상 머신 노드(메인프레임 노드)를 표현한다. 노드를 모델링 하려면 3차원 큐브를 그려 큐브 상단에 노드 이름을 적는다. 시퀀스 다이어그램에서 사용되던 네이밍 규칙([instance name] : [instance type]) (예, "w3reporting.myco.com : Application Server").

그림 8의 전개 다이어그램은 사용자가 로컬 머신에서 실행되고 기업의 인트라넷에서 HTTP를 통해 Reporting Tool에 연결되는 브라우저를 사용하여 Reporting Tool에 접근하는 것을 보여주고 있다. 이 툴은 물리적으로 w3reporting.myco.com 이라고 하는 Application Server에서 실행된다. 이 다이어그램은 IBM WebSphere 내부에서 그려진 Reporting Tool 컴포넌트를 보여준다. 이것은 결과적으로 node w3.reporting.myco.com에서 그려지게 되어있다. Reporting Tool은 자바를 사용하여 리포팅 데이터베이스를 IBM DB2의 JDBC 인터페이스에 연결하여 원시 DB2 통신을 사용하는 db1.myco.com 서버상에서 실행되는 실제 DB2 데이터베이스와 통신한다. 리포팅 데이터베이스와 통신하는 것 외에도 Report Tool 컴포넌트는 SOAP over HTTPS를 통해 Billboard Service와 통신한다.

결론

이 글은 Unified Modeling Language에 대한 간단한 입문서에 불과하지만 여러분이 이 정보를 실제 프로젝트에 적용하거나 더 깊게 UML을 연구하기를 바란다. UML 다이어그램을 소프트웨어 개발 프로세스에 통합시키는 여러 소프트웨어 툴이 있지만, 자동화된 툴이 없더라도 화이트보드에 마커와 펜을 사용하여 UML 다이어그램을 그려도 좋다.

참고자료

•http://www.uml.org/
•http://www.rational.com/uml/resources/documentation/index.jsp
•http://www-140.ibm.com/developerworks/rational/products/rose
•http://www-140.ibm.com/developerworks/rational/products/xde
•http://argouml.tigris.org/
•http://uml.sourceforge.net/index.php
•PDF 로 보기

작성자 : Donald Bel(IBM)

작성일 : 06/04/06

출   처 :http://www.dbguide.net/know/know102001.jsp?mode=view&pg=1&idx=2959

원   문 : 한국IBM

[웹 2.0은 없다] 오래된 미래 이야기

웹 2.0 열기가 뜨겁다. 닷컴이 지나온 긴 터널을 생각하면 모처럼의 활기가 나쁠리 없다.미국뿐 아니라우리나라에도 앵콜을 하는 컨퍼런스가 있는 가하면일반 언론들까지 웹 2.0을다루는데 가세했다. 아직은 미국 이야기지만 관련 업체에 대한 투자나 인수합병 열기도 뜨겁다. 하지만 다른 한쪽에서는 '컨퍼런스'가 최고의 수익 모델인‘거품 2.0(Bubble 2.0)’이라거나, 업체들이 자신을 포장하는데 써먹는 마케팅 용어일 뿐이라는 비판도 만만치 않다.

이런 갑론을박 속에서 사람들을 혼란스럽게 하는 것은 사실 아주 근본적인 질문이다.

대답이 길어지는 것은 언제나 분명한 답이 없기 때문이다. 하지만 언제까지 남의 용어를 빌려서 길잡이를 삼고, 그 다음이 어떻게 펼쳐질지 말해주기만 기다리면서 여행을 떠날 수는 없다. 누구나 자신만의 대답을 가져야 한다. 그래서 필자는 부족하지만 지난 2월 15, 16일웹 2.0 컨퍼런스에서나름의 대답을 시도했다. 그리고 그 내용을 기반으로 다시 글을 쓰려고 한다. 물론 이것만이 정답이라고 주장할 수는 없다. 하지만 필요한 분들이 좋은 답을 찾아가는 데 작은 디딤돌이 될 수 있기를 바란다.

웹 2.0 혹은 오래된 미래

과 달리 분명히 마케팅적이기도 하다. 사람들을 움직이는 힘이 있기 때문이다. 의식적이든 무의식적이든 '참여', '공유', '사람' 같은 광고 캠페인 용어들까지 전면에 배치되어 있다. 모호한 희망이 짙게 배어있다. 이렇다보니 "어떻게 적용하나?"나 "수익모델은?" 같은 질문에 곧바로 대답이 나오기 어려울 수 밖에 없다.

하지만 그럼에도 불구하고 웹 2.0은 잠깐 지나갈 유행으로 넘기기에는 의미가 너무 크다. 어떤 분들의 말처럼 차세대 웹이라서가 아니다. 오히려 웹의 본질을 짚어내고 있기 때문이다. 우선 웹 2.0이라는 말이 등장하게 된 배경부터 그렇다.

이 개념은 2004년 미국의 한 컨퍼런스에서 브레인스토밍을 하면서 시작되었다. 닷컴 거품이 붕괴된 후에도 살아남아서 발전하고 있는 구글이나 아마존 같은 기업들의 공통점을 찾던 것이 출발이었다. 마치 스티븐 코비가 200년 간의 성공 관련 문헌을 조사해서

양쪽의 차이는 생각보다 많지 않다. 성당과 시장이 프로그래머라는 특정 집단이 서로 협력하면서 응용 프로그램을 개발하는 방식이라면, 웹 2.0은 더 넓게 확장되어 일반 사용자들이 웹 서비스 위에서 다양하게 협력하는 것이다. 영역은 다르지만 근본 마인드는 같다. 성당과 시장의 주장 몇가지를 웹 2.0의 눈으로 살펴보자.

성당과 시장 웹 2.0 "사용자는 공동 개발자다." 플리커,위키피디어등에서 사용자는 공동 편집자다. "일찍 발표하고 자주 발표한다." 끊없는 베타(Perpetual Beta) 서비스가 되어야 한다. "자료 구조를 훌륭하게 만든다." 참여와 공유를 뒷받침하는 아키텍쳐가 필요하다. "완벽함은 더 이상 버릴 게 없는 상태를 말한다." 단순하고 모듈화 된 프로그래밍을 한다. "기존 것을 재사용한다." 에이잭스(AJAX)는 신기술이 아니라 신조합이다.

웹 2.0은 오래된 미래다. 역사에서 찾은 미래이며, 본질에서 찾은 성공 전략이다.(각주 3)피터 드러커는 인터넷 혁명을 전망하기 위해 철도 혁명을 되돌아 보았다.(각주 4)마케팅 전문가인 알 리스는 "미래를 예측하는 유일한 방법은 과거를 연구하는 것"이라고 했다. 웹 2.0을 신기술이나 새로운 혁명으로만 포장한다면 결국 또 한번의 실망으로 끝날 것이다.

웹의 미래를 보기 위해 본질로 눈을 돌려야 한다. 그 본질의 물꼬를 터주는 기술과 서비스를 지향해야 한다. 또한 웹 2.0이란 단어에 묶여 있을 필요도 없다. 그 단어는 불 붙이는 일로 생을 다하는 점화용 화두에 불과하다. 언덕 너머 세상은 팀 오라일리와 친구들 역시 알지 못한다.

부디 웹 2.0 논의가 짧은 욕심에 파묻히지 않고 웹다운 웹이 발전하는 전기가 되기를 바란다.

작성자 :전병국 (검색엔진마스터 대표)

작성일 :2006/03/08