UML2007. 12. 26. 12:24
제가 블로그를 시작하고 나자 대학교 후배들이 선배를 알아보고는 이것 저것 물어보는게..
수업시간에 질문하지 않는것을 미덕으로 알았던 우리시대와는 많이 다르구나 하고
새삼 세월의 차를 느꼈습니다.
그래서 예전에 제가 잡지사에 기고한 글을 검색하여 올려봅니다.


우선 제가 이 글을 쓰게 된 이유는 절대로 잘난척을 하자고 하는것이 아닙니다.

그런것이 아니라 많은 분들이 아주 중요한 점인데도 불구하고 그냥 지나치시거나 혹은
잘못된 지식을 사실인것 마냥 알고 계신것이 안타까워서 입니다.

국내에 많은 분들이 SCJP, SCJD 자격증에 도전하시거나 가지고 계시지만 이러한 기초적인
차이점을 이해하지 못하여 시험에 떨어지거나 혹은 보다 더 좋은 구조를 설계하는데에
어려움을 가지고 있음을 저는 여러번 보아 왔으며, 저도 역시 그러하였습니다.

곰곰히 그 이유가 뭔지 살펴본 결과 내릴 수 있는 결론은 프로그래머로써 가져야할
기초적인 이론을 바탕으로 하여 자신의 실력을 쌓는것이 아니라 국내의 많은 프로그래머
분들이 이론은 무시한체, 테크닉이나 단순 활용법에만 의존하며 마치 그것이 대단한
실력인양 자랑을 하는것이 문제라고 생각하였습니다.

그래서 보다 많은 분들이 좀더 체계적인 이론을 배우시기 위해서 제가 가지고 있는
몇가지 지식들을 적어보고자 합니다.

아주 밑바탕 부터 올라올 수는 없기 때문에 어느정도 중간수준에서 설명을 하도록
하겠습니다.

"이론같은것 필요없어.. 기냥 짜면 되는거지.." 라고 생각하시는 분들은 여기까지만
읽으시기 바랍니다.



<<< Extends 와 Implements 의 의미와 차이 >>>

"에이 그거다 아는 거야.. 다중상속 ... 어쩌구 저쩌구.." 라고 많은 분들이 알고
계십니다. 그러나 진정 속뜻은 진정 그렇지 않습니다.

이 차이점을 알기 전에 우리는 우선 Type 이라는 것에 대해서 알 필요가 있습니다.

Type이란 뭘까요 ?

간단하게 말하면 Type이란 어떤 놈과 다른 놈이 "다르다" 라고 말할 수 있게 하는 근거,
혹은 이유 (에구 복잡하게 말해 버렸네요..) 라고 책에는 적혀 있습니다.

만약에 우리가 길을 가다가 어떤 돌멩이 A를 주웠고, 계속 길을 가다가 동전 B를
주웠다고 합시다.

그럼 우리는 어떻게 A와 B가 다르다고 말할수 있습니까 ?

모양이 다르고, 색깔이 다르고, 무게가 다르고, 비열이 다르고, 뭐뭐뭐...
그래서 "다르다" 라고 말한다면 아주 잘 말한 것입니다.

바로 타입이라는 개념이 등장하게 됩니다.
돌멩이란 타입은 생긴것은 못생겼고, 색깔은 회색에, 비열은 뭐에..
이다. 라고 말하는 것입니다.

즉 다시 말하자면 타입이라는 것은 일종의 행동양식에 대한 반응이라고도 말 할 수
있습니다. 외부로 부터의 같은 자극에 의해서 어떤 두 물체가 다르게 반응한다면 둘은
다른 타입이 되는 것입니다.

이제 타입이라는것에 대해서 어느정도 기본 개념이 잡혔다고 보고요

그럼 객체지향 프로그래밍 언어에서 말하는 타입이란 무었인가에 대해서 말해보도록 하죠.

앞에서 말한것과 거의 비슷한 내용입니다.
결국은 행동양식, 즉 외부로 부터의 자극에 대한 반응입니다.

그럼 우리가 타입이라는 것을 정의한다는 말은 어떤 물체를 새로 만드는 것임과 동시에
그 놈의 행동 방식을 정의한다라는 말이 됩니다.

Java 에서 말하는 Interface는 바로 "새로운 타입"을 정의하는 것이 본래 사명입니다.
(Abstract Class도 여기에 해당합니다)

"어 그럼 Class는 타입을 정의하는 것이 아닌가 ?" 라고 생각하시는 분들이 계실
것입니다.

네. 완전히 틀린 말은 아닙니다. 허나 클래스는 객체를 찍어내는 풀빵틀 이 목적이지
타입을 정의하는 것은 아닙니다.

그럼 implements한다는 말은 무엇을 의미하는지 설명하도록 하겠습니다.

다시 기본적 이론을 설명하겠습니다.

객체지향에서는 어떻게 재사용성과 확장성을 보장합니까 ?

"상속" 이라고 말하시는 분들은 어느정도는 알고 계신 분들이고 "Dynamic Binding" 혹은
"Subtype Polymorphism"이라고 말하시는 분들은 정확하게 알고 계신것입니다.

여기서 우리는 한가지 분류를 해야 합니다. 상속에는 두가지 종류가 있습니다 (모르셨죠 ?)

구현의 상속과 타입의 상속입니다. 구현의 상속이 아마도 많은 분들이 이해하고 계시는
상속이며 타입의 상속은 아마도 모르고 계실것 같습니다.

그럼 타입에 대한 상속에 대해서 말씀을 먼저 드리겠습니다.

타입에 대해서는 앞에서 정의를 해드렸습니다.
그럼 이놈을 상속하겠다는 말은 즉, 어떤놈의 행동양식은 그대로 가져오되, 행동양식에
대한 반응은 재정의 하겠다 라는 말이 됩니다. 재정의 즉 오버라이딩은 바로 여기서
나오는 말입니다.

다시 말해서 타입 X가 있고, 객체 A가 있을때 객체 A가 X를 상속한다는 말은 다시
말하자면 A는 X 타입이다. 라고 말하는 것입니다. (여기까지는 그대로 가져오는
것입니다)

그리고 필요에 의해서 A가 X 타입을 나타내는 행동양식에 대해서 특별히 다르게 반응을
보인다면 그 부분만 재정의 하는 것입니다.

예를 들어 보면)

포유류 라는 타입이 있습니다.
사람도 포유류 타입입니다.
코기리도 포유류 타입입니다.
오리너구리도 포유류 타입입니다.

포유류의 행동 양식에는 "모든 포유류는 새끼를 낳는다"가 있습니다.
사람도 새끼를 낳고,
코끼리도 새끼를 낳고,
그러나 오리너구리는 알을 낳습니다.

네 그렇습니다. 오리너구리도 포유류이지만 여기서 재정의가 일어 난것 입니다.

이것이 타입의 상속입니다.

여기서 또 중요한 개념이 등장하는데 타입을 상속한 놈과 상속 당한놈과의 관계를
Subtype 관계라고 합니다.

X 라는 타입이 있고 X'이 타입 상속을 했다면 X'는 X의 서브 타입이라고 말합니다.

그리고 이때부터 바로 객체지향의 진수인 Subtyping이 가능하게 됩니다.

Subtype Polymorphism이란 기존의 수학적 모델에서는 X 타입의 자리엔 X 타입만 대입할
수 있지만 이제는 X 타입의 자리에 X의 모든 서브 타입들도 올 수 있게 하는 것입니다.


X' a = new X';
X b = a;
라고 되는 것입니다.

그럼 이제서야 Implements의 의미를 알려드리게 되었습니다.

implements 한다말은 여러분이 짐작 하셨겠지만 타입을 상속하겠다는 말입니다.
(만약 일부 재정의를 하시려면 Abstract Class 를 사용하세요)

interfac Drawable {
void Draw(..);
}

이란 말은 Drawable 이란 타입을 정의하는데 그놈의 행동양식은 Draw할 수 있어야
한다라는 말입니다.

class Shape implements Drawable 이란 말은 이제부터 Shape도 Drawable 타입이란
말이며 Shape는 Drawable의 서브 타입이 되는 것이며 모든 Drawable자리에 Shape도
울 수 있게 됩니다.

이로써 재사용성과 확장성이 보장이 되는 것입니다.

그러나..
많은 OOP들에서는 타입의 상속과 구현의 상속을 구분하지 않고 있습니다. 하지만
자바에서는 Interface를 둠으로써 어느정도 구분을 하려 하였으나 역시 자바에서도
뚜렷이 구분되고 있지 않습니다.

그래서 가장 좋은 방법은 상속을 하실때는 Subtyping을 전제로 하여 하는것이 가장
좋습니다.
Posted by 알 수 없는 사용자
UML2006. 10. 31. 15:39

지금까지의 단계를 반복하여 기존의 시스템이나 개발해야될 새로운 시스템에 대한 분석하였다면, "무엇을"에 해당하는 부분을 이해했다고 생각할 수 있습니다. 보통의 프로세스들에서 지금까지의 단계는 일치합니다. 허나 이제 부터는 프로젝트의 성격에 따라서 많은 차이가 생기게 됩니다. 오늘 강좌에서는 여러 갈림길들 중에서 하나를 따라가기 전에 왜 제가 지금까지 "분석"을 그렇게 강조하였는지 쉬어가는 페이지겸해서 MDA (Model Driven Architecture)에 대해서 설명해보도록 하겠습니다.


1. MDA ?
OMG그룹에서 MDA Overview는 다음과 같이 간략하게 MDA가 무엇인지에 대해서 설명해주고 있습니다.

OMG members voted to establish the MDA as the base architecture for our organization's standards in late 2001. Software development in the MDA starts with a Platform-Independent Model (PIM) of an application's business functionality and behavior, constructed using a modeling language based on OMG's MetaObject Facility (MOF). This model remains stable as technology evolves, extending and thereby maximizing software ROI. MDA development tools, available now from many vendors, convert the PIM first to a Platform-Specific Model (PSM) and then to a working implementation on virtually any middleware platform: Web Services, XML/SOAP, EJB, C#/.Net, OMG's own CORBA, or others. Portability and interoperability are built into the architecture. OMG's industry-standard modeling specifications support the MDA: The MOF; UML, now at Version 2.0; the Common Warehouse Metamodel (CWM); and XML Metadata Interchange (XMI). OMG Task Forces organized around industries including Finance, Manufacturing, Biotechnology, Space technology, and others use the MDA to standardize facilities in their domains.


대충 핵심만 번역하자면, MDA라는 것은 시스템을 설계할때 그 비지니스 로직과 비지니스 객체를 중심으로 설계대상의 영역을 비지니스에 국한시킵니다. 이것을 플랫폼 독립적인 모델이다라고 해서 PIM이라고 부릅니다. 그리고 이 플랫폼 독립적인 모델에 웹서비스 환경이던지, 클라이언트/서버모델이던지, 닷넷, 자바, 등등 플랫폼을 적용시킨 모델을 PSM이라고 하는데 PIM에서 PSM으로의 변환을 프로그램에서 자동적으로 처리하거나 매뉴얼로 변환가능하게 하는 새로운 설계개념을 의미합니다.
이때 변환을 위해서는 변환법칙이라는게 필요한데 이 역할을 하는것이 MOF라고 보시면 됩니다.

조금더 쉽게 설명해보겠습니다.
지금 IT업계에서 수행되고 있는 대부분의 SI프로젝트들은 크게 두가지 종류입니다.
하나는 이미 동작하고 있는 시스템에서 새로운 기술을 적용시켜 업그레이드 시키는 종류와
이전에는 없었지만 새로운 요구나 필요에 의해서 무에서 새로운 시스템을 개발하는 종류입니다.
간단히 말해서 유->새로운 유, 무->유, 새로운 유 라고 할 수 있겠군요.
이러한 프로젝트는 IT업계의 기술발전이 정지하지 않는 한 결코 멈추지 않을 것입니다. 바꿔말하면 두 종류의 프로젝트는 무한히 계속된다는 것이죠. 그런데 가만히 생각해보면, 기술의 변화는 상당히 자주 일어나는데 반해서 비지니스 로직의 변화는 더딘것이 일반적입니다.
즉, 금융업무나 증권업무나 병원, 법원, 행정등등 IT기술이 적용될수 있는 대부분의 분야의 업무처리나 기능들은 아주 점차적인 변화인 반면, IT기술은 상당히 빠르고 진보적으로 발전되고 있습니다.
그래서 가끔은 구현해야할 기능은 동일한데 단순히 적용되는 기술이 다른 프로젝트도 있습니다.
예를들어 아무문제없이 멀쩡히 잘 돌아가는 물류관리 시스템을 웹이 유행이라는 이유만으로 웹상에서 동작하도록 구축하는 프로젝트도 보았습니다.

그래서, 기술과 업무를 분리하자는 것입니다.
즉 구현해야할 What과 수단인 How를 분리하는 것입니다.

이를 분리함으로써 얻게 되는 이득은 명백합니다.

반복되는 작업에서 재사용이 가능해집니다.

한번 MDA 개념을 사용해서 비지니스 기능을 설계해 PIM을 잘 구축해놓았다면, 엄청난 비지니스 로직의 변경이 없는한 관련된 새로운 프로젝트에서 설계단에서부터의 재활용이 가능해집니다. (단순 소스코드나 바이너리의 재사용이 아닌, 설계 단계에서부터 재사용이 가능해집니다)

그럼 이제 아주 간단한 MDA식 예제를 한번 보도록 합시다.
아주 아주 간단한 MDA의 핵심 개념만 보여주는 것이기 때문에 "이게 무슨 MDA냐 라고 딴지 거시지 마시길 바랍니다." 보다 자세한 개념들은 차차 살펴보도록 합시다.

위의 그림은 제가 첫 강좌에서 사용한 예제그립니다. 아주 평범한 Domain 객체 분석모델입니다.
우선 MDA개념을 적용하기 위해서는 Domain Model자체가 잘 분류되고 정의될 필요가 있습니다. 그래서 비지니스 객체들에게 스테레오 타입을 이용해서 약간의 카테고리를 지정해보았습니다.
머 별거 없는 예제입니다. 우선 스테레오타입을 이용해서 각각의 성질을 지정하였습니다. 일단 여기까지의 결과물을 PIM이라고 해봅시다. 그리고 지금부터 PSM을 적용해보도록 하겠습니다.
음... 웹 기반의 프로젝트라고 가정을 해서 PSM은 웹환경이 되겠습니다. 그리고 EJB를 사용한다고 합시다.
우리는 PIM을 재사용하기를 원합니다. 분류와 정의를 잘 다루어 놓았기 때문에 간단한 수준에서는 가능합니다. Persistance로 분류가 된것들은 퍼시스턴스 빈, Logic으로 분류가 된것들은 세션빈으로 충분히 변환이 가능합니다.
죄송합니다. 갑자기 귀차니즘이 발동하기 시작하네요.

그리고 기타 EJB를 위해서 필요한 각종 인터페이스가 파인더 메소드, PK관련 설정등을 자동적으로 추가해줄 수 있습니다. 지금까지의 설계툴에서 보여줬던 여타다른 단순 EJB 코드 생성보다 훨씬더 설계가 유기적으로 결합된 느낌입니다.
반대로 EJB말고 서블릿 모델 2를 적용해서 DAO패턴을 적용시킬수도 있습니다.
C/S환경에서 DB Table 설계결과를 생성할 수도 있습니다. (정규화나 테이블 튜닝은 별개로 하고)
즉 PIM으로 부터 수 많은 PSM을 적용한 결과물을 산출해 낼 수 있습니다.

이런 일이 가능한 핵심이 바로 스테레오 타입에서 기술한 모델의 분류였습니다.
이 모델의 분류를 보다 체계적이고 구체화한 것이 MOF (MetaObject of Facility)입니다.
OMG에서 이러한 간단한 그림으로 표현했네요.. 지금까지의 설명으로 이해한 MDA의 개념과 아래의 그림을 통해서 한번 정리해보세요.


이것이 MDA의 핵심이라고 할 수 있습니다.

오늘 강좌는 여기까지 하겠습니다. 다음시간에는 무엇을 할지 조금 고민해 보아야 하겠습니다. MDA가 UML 2.0과 함께 중요한 개념이기 때문에 한번더 언급하고 다음강좌를 진행할지 아니면 바로 다음 강좌로 넘어갈지 잘 모르겠습니다.
그리고 보다 더 자세한 MDA에 관한 내용은 OMG의 홈페이지에 가보시면 지금까지 정의된 MOF는 물론 기타 관련 자료를 얻으실 수 있을 것입니다.
Posted by 알 수 없는 사용자
UML2006. 10. 27. 10:57
이번에는 지난 강좌에 이어서 완성된 Domain Model을 가지고 시스템의 설계를 검증하는 방법에 대해서 한번 알아 보겠습니다.

1. Story of Usecase
  이전 Usecase 단계에서 우리는 시스템의 전체적인 동작 시나리오를 작성했었습니다. 주로 액터와 시스템의 액션에 주목했었습니다. 이 스토리는 추상화 레벨이 아주  높으며 시스템 내부의 동작은 거의 블랙박스입니다. 하지만 이제 우리는 시스템 내부의 핵심 Domain Object들을 추출하였고 스토리에서 시스템 내부로 이어지는 부분에 대한 연결고리를 추출해 낼수 있게 됩니다.

2. System Realization
  바로 시스템 내부로 이어지는 부분에 대한 설계를 Realization이라는 영어를 써가며 표현하고 있지만, 사실은 머 확인이나 검증 정도로 생각해도 되겠습니다. Usecase에서 설명한 시스템의 스토리와 그 스토리를 Domain Object를 사용해서 표현할 경우 어느정도의 싱크로율을 보이는가에 따라서 지금까지의 설계가 어느정도 빈틈없이 튼튼하게 이루어졌는지 확인 할 수 있을 것입니다.
  사용되는 다이어그램은 주로 Sequence Diagram입니다.
아래의 예를 한번 보도록 하죠.
  <이전의 도메인 모델에서 설계한 DVD 대여점의 시나리오 일부분입니다>
  1. DVD의 대여신청
  1.1 액터가 시스템에 로그인한다.
  1.2 액터가 시스템에 대여하기를 원하는 DVD를 검색한다.
  1.3 시스템은 검색된 DVD를 화면에 표시한다.
  1.4 액터는 대여가 가능한 DVD를 선택하여 대여를 신청한다.
  1.5 시스템은 대여와 관련된 필요한 정보를 입력하는 화면을 표시한다.
  1.6 액터는 필요한 정보를 입력하고 최종적으로 대여를 신청한다.
  1.7 시스템은 입력된 정보들의 타당성을 검증하고
        결제시스템을 사용하여 결제한다음, 창고쪽에 새로 대여가 신청된 DVD의 출고 데이터를
        생성하여 전송한다.
  1.8 창고 관리 직원은 전송된 데이터에 따라 DVD를 포장하여 출고한다음
       출고가 최종적으로 완료되었음을 시스템에 입력한다.
  1.9 시스템은 출고된 DVD의 상태를 변경한다.

아주 간단하게 표시한것이지만, 대체적으로 Usecase의 시나리오는 이러한 형식을 크게 벗어나지 않습니다. 다만 각각의 단계에서 발생 할수 있는 예외상황에서 어떻게 일을 처리할 것인지를 명확히 표시하는것에서 차이가 있을 수 있겠습니다.
대부분 아주 중요한 스토리보드에서의 예외처리에만 집중을 하면 될것입니다. 예를 들어 잘못된 결제정보입력이라던지, 창고에서 신청된 DVD가 파손되었음을 뒤늦게 확인하였거나 분실되었음이 확인될 경우 등등이 되겠죠. 대신에 로그인에 실패할 경우 어떻게 하라등등 아주 일반적이고 상식적인 부분까지 설명할 필요는 상대적으로 적을것입니다.
자 그럼, 위의 시나리오를 우리가 설계한 Domain Object를 사용해서 한번 표현해 보도록 합시다.
그런데 이전의 강좌에서 산출한 최종결과물로는 위의 시나리오를 그대로 표현하기에 무리가 있습니다. 즉, Domain Object모델의 설계가 불완전하다는 이야기로 직결되죠.
그래서 Domain Object를 조금 더 추가하겠습니다. 렌탈시스템과 창고시스템을 추가하겠습니다.
이 두 시스템은 DVD대여 시스템의 서브 시스템들이며 충분히 Domain Object적인 성격을가지고 있습니다. 각각 시스템에서 이루어지는 자세한 usecase는 생략하기로 하고 전체적인 시스템 스토리 상에서의 역할은 대략 상식수준에서 가늠할 수 있는 그것이라 정의하겠습니다.
(
사실 여기서 귀차니즘이 발생했거든요, 그려놓은 파일을 날려먹어서 다시 그리기 귀찮아졌습니다.)
그럼 이제 Sequence다이어그램을 그려 보도록 하겠습니다. 하지만 시퀀스 다이어그램이 옆으로 길어지는 경향이 있어서 화면에 딱 맞에 표시가 되지 않더라구요. 그래서 나누어서 단계별로 한번 그려보겠습니다.
시스템에 로그인을 하면 스텝을 표현한 것입니다. 아주 쉽죠 ? 자 그럼 다음 스텝들을 차근차근 표현해 보도록 합시다.
DVD를 검색하는 단계까지 그려 보았습니다. 시나리오 상에서는 표면적으로 여기까지 기술되어져 있지만, 우리는 그 내부에서 무슨일이 일어날것인지 Domain Object를 사용해서 표현할 수 있습니다.
그려보는김에 두단계를 훌쩍 그려 보았습니다. DVD리스트를 검색하여 액터에게 반환하면 액터는 원하는 DVD를 대여신청합니다. 자 그럼 그 다음을 보도록 합시다.
후후 점점더 복잡해져 가고 있네요. 대여에 필요한 정보를 입력하면 렌탈시스템이 입력된 정보를 확인한다음 대여데이터를 생성해서 창고시스템에 출고를 위한 정보를 전달하게 됩니다. 자 그럼 마지막단계까지 한번에 달려가 보도록 합시다.
복잡해졌습니다., -_-; 그래도 이건 예외경우가 없으니까 간단한편입니다.
창고시스템은 전달된 대여신청건에 대해서 창고에 적재된 위치를 검색하여 창고관리자에게 화면이나 기타 수단을 사용하여 알리게 됩니다. 그럼 창고 관리자는 지정된 위치에서 해당 DVD를 꺼내온다음 입력된 주소정보나 기타 정보를 사용해서 택배를 보내게 되겠죠. 그리고 최종 정보를 시스템에 입력하게 되면 창고시스템은 그 정보를 렌탈시스템에게 전달하고 렌탈시스템은 택배정보를 회원에게 메일이나 웹을 통해서 확인할 수 있게 합니다.
창고관리자가 또 다른 액터로 등장해야 정상이지만 그림이 너무 복잡해지고 귀차니즘이 발생하였기 때문에 생략하였습니다.
예외상황의 처리는 여러분께서 한번 해 보시기 바랍니다.

다음 강좌에서는 지금까지 진행된 강좌에서 부족하다고 생각된 부분에 대해서 다시 다루겠습니다.
Posted by 알 수 없는 사용자
UML2006. 10. 22. 00:25
우선 강좌가 늦어진것 죄송합니다. 그동안 여러가지로 일들이 조금 바빠지는 바람에 낮에는 전혀 블로그 관리를 할 수 없었습니다. 저녁에도 개인적으로 중요한 일들이 많아서 시간이 좀 나지 않았었습니다. 하지만 한번 하기로 맘먹은 이상 만족할만한 결과물이 나올때 까지 한번 해 보겠습니다.

1. Domain Modeling이란
본격적인 개발단계에 들어가기 전까지 개발자들은 고객과의 긴밀한 협조를 하게 되는데 그 과정을 통해서 개발자가 얻고자 하는것은 대상 시스템에 대한 명확한 이해라고 할 수 있습니다. 도메인 모델링이란 유스케이스와 더불어 시스템에서 명확히 존재함이 들어나는 비지니스로직상의 객체들의 개념적 설계혹은 정의라고 할 수 있습니다.
쉽게 이야기 하면 도메인 모델링이란 개발 대상이 되는 시스템혹은 업무처리에서 사용되어지는 "어떤 것"들을 구체화시키는 작업이라 할 수 있습니다.

(설명이 잘 이해가 되지 않은것 같아서 예를 들어 설명해 보겠습니다.)

예1) DVD 대여점 시스템의 창고 관리.
보통 쉽게 생각해 봤을때 창고 관리 시스템은 DVD를 관리합니다. 즉 DVD가 우선 제일 간단히 생각해 낼 수 있는 비지니스 로직상의 개념입니다.
DVD는 여러가지 속성을 가지는데 제목이라던지 출연배우, 감독, 영화장르, 대여가격, 최근대여상태(누가 빌려갔는지, 창고에 있는지, 다른 문제가 있는지)등등이 있을것입니다.
이러한 점들을 정리하고 UML로 표현하면 도메인 모델링의 시작인것입니다.

예2) 흔히들 웹프로그래밍을 공부할때 관문처럼 되어버린 게시판 프로그램
게시판 그 자체가 비지니스 객체가 될수 있겠네요, 그리고 글, 리플들이 있을수 있고,
작성자 제목, 작성날짜 등등이 속성이 될수 있겠습니다.

2. Domain Modeling을 수행하는 방법
우선 명확한 비지니스 객체들을 파악하여 클래스 다이어그램이나 기타 다이어그램을 사용하여 설계할 수 있을것입니다. 그 다음에 해야 할 일은 객체들 사이의 관계들을 정의하는 것입니다. 구체적일 필요는 없으나 구체적이면 구체적일 수록 다음 단계가 수월해 질 것입니다.

그리고 반복되는 이터레이션을 통해서 좀더 자세하고 구체적인 점들을 명시합니다.

예를들어 간단한 DVD대여점의 창고 관리 시스템들 개발한다고 해봅시다.
우선 웹상에서 회원들이 가입을 하면 DB에 회원들의 정보가 저장이 되고,웹에서 자신이 대여하고 싶어하는 DVD들을 조회할 수 있으며, 대여가 가능한 DVD들을 신청할 수 있다고 합시다.
창고에서는 신청이 들어온 DVD들을 창고의 지정된 위치에서 꺼내와서 신청자의 주소로 물건을 발송한다고 합시다.
그리고 사용자가 DVD를 시청한 다음 반환하면 창고에서는 우선 DVD를 검사하여 고장이나 파손유무를 확인하고 창고의 적정위치를 검색하여 DVD를 창고에 입고시킵니다.

우선 제일 먼저 생각할 수 있는것은 회원, DVD, 창고 위치등등일 것입니다.
간단하게 Class Diagram으로 표현해 보도록 합시다.
그럼 이제 좀더 구체화를 시켜 보도록 하겠습니다.
여러분은 고객과의 계속되는 회의와 접촉을 통해서 다음과 같은 것들을 알게되었습니다.
회원은 자신의 고유 번호가 있고, 회원 가입을 할때 주소를 입력한다고 합니다.
DVD는 고유 상품번호가 있으며, 제목과 대여가격, 그리고 지금 대여가 가능한 상태인지 알수 있어야 한다고 합니다.창고 위치를 지정하기 위해서는 우선 섹터가 있고 각 섹터에는 5개 씩의 선반이 있으며 5개 씩의 선반은 층과 단으로 나뉘어 져 있다고 합니다.
그럼 이제 이 정보를 가지고 설계를 좀더 진행해 보도록 하겠습니다.
간단하죠 ?
충분히 이해하시리라 생각이 됩니다.
그럼 이제 아주 간단히 비지니스 객체들 사이의 관계를 한번 생각해 봅시다.
처음부터 너무 구체적으로 생각하려 하지 마시고 아주 아주 간단한 관계부터 시작해 봅시다.
우선, DVD는 창고에 저장이 된다고 하였습니다.
그러기 위해서는 DVD가 창고 어디에 있는지 알아야 되는데 어떻게든 그 정보를 가지고 있어야 할 것입니다. 즉 DVD와 창고 위치 사이에는 무언가 관계가 있는것 같습니다.
또한 회원은 DVD를 열람하고 대여를 신청할 수 있습니다. 즉 회원과 DVD사이에도 무언가 관계가 있습니다.
하지만 회원과 창고위치사이에는 지금까지의 스토리만으로는 어떤 관계가 있는지 알기 어렵군요.
지금까지의 분석을 통해서 알게된 사실들을 그림을 통해서 표현해 보도록 합시다.
정말 별것 없습니다. -_-; 제가 죄송할 정도이네요.
자 그럼 이제 조금더 자세히 파고 들어가 보겠습니다.
우선 회원과 DVD사이의 관계를 조금더 파고 들어가 보겠습니다.
앞서 우리가 알게 된것은 회원이 DVD를 대여 할수 있다는 것이었습니다.
"대여"라는 정보는 회원과 DVD가 관계를 가지기 때문에 발생하는 부수적 객체입니다. 애초에 회원이 DVD와 아무런 연관이 없었다면 대여신청을 할 수 없었겠죠.
바로 여기서 우리는 연관클래스라는 개념을 도입해서 다음과 같이 표현 할 수 있습니다.
그림은 금방 이해하시리라 생각이 됩니다. 대여 정보에는 누가 무엇을 대여신청했는지 알려주고 있습니다.
자 그럼 이제 DVD와 창고위치사이의 관계를 한번 살펴보겠습니다.
DVD는 창고에 저장이 됩니다. 그리고 창고를 떠나 회원에게 전달됩니다. 그리고 다시 창고에 들어옵니다. 들어올때에는 새로운 위치를 지정받게 될것입니다.
이는 아주 간단하게 생각하면 DVD의 속성으로 간주할 수 있습니다. 즉 DVD 자신이 어디에 입고될것인지에 대한 정보를 가지게 할 수 있습니다.
또 다른 관점은 앞서서 회원객체와 DVD객체사이에서 연관클래스를 유추해낸것 처럼 창고위치와 DVD사이의 관계도 동일한 관점으로 바라볼 수 있습니다.
이번 강좌에서는 일관성을 유지하기 위해서 다음과 같이 표현하겠습니다.
여기서 창고재고정보 클래스에서 위치 ID를 추가하였는데 이는 편의를 위해서 스토리상에서는 존재하지 않는 속성이지마나 객체들과의 1:1 관계를 보장하기 위해서 임의로 생성한 속성입니다.

이러한 방식으로 조금씩 조금씩 비지니스 클래스들을 추가할 수 있을 것입니다.

자 그럼 이제 어느정도 설계가 완성된 아래의 그림을 보면서 오늘의 강좌를 정리해보도록 하겠습니다.
우선은 회원과 DVD사이의 카테고리를 정의하였습니다. 회원은 여러개의 DVD를 대여할 수 있기 때문에 1:N의 관계로 정의하였습니다. 그리고 DVD는 창고의 어느 한곳에만 입고가 될것이기 때문에 1:1의 관계로 정의하였습니다.
또한 우리는 앞선 스토리에서 고장안 DVD인지 판별한다고 했기 때문에 DVD의 한 종류중에 파손된 DVD라는 객체를 생성하였습니다. (DVD의 또 다른 속성으로 파손유무를 표현하게 할 수도 있습니다.) 그리고 DVD에는 여러장이 시리즈물인 경우가 있기 때문에 DVD가 다음편으로 연결이 되는지 재귀관계로 표현하였습니다.
또한 창고위치정보에 지금 그 위치에 물건이 있는지 없는지를 나타내는 속성을 추가하였고
이 속성과 창고재고 정보는 대여정보에서 영향을 많이 받는관계인데 그 이유를 설명하는 주석을
표시하였습니다.

비지니스 로직에 대해서 알면 알수록 도메인 모델링은 더욱 튼튼해지고 이후의 과정은 수월해 질 것입니다. 한번에 다 알아내려는것 보다는 조금씩 조금씩 이터레이션을 거치는 과정이 중요합니다.

다음 시간에는 이렇게 정의된 Domain Model을 이용해서 어떠한 작업을 추가로 진행해야 하는지 살펴보도록 합시다.

    
Posted by 알 수 없는 사용자
UML2006. 10. 10. 10:12
이번 시간에는 Usecase 다이어그램의 대략적인 구성에 대해서 살펴보겠습니다. ^_^

#들어가기에 앞서서#
프로젝트가 실패하는 가장 큰 이유중에 하나는 "비정상적으로 짧은 개발기간"이라고들 합니다. 네, 물론 그렇습니다. 아직까지 헝그리 정신으로 밤샘과 철야를 하루 세끼 밥먹듯이 하며, "까라면 까는거지"라는 마인드를 가지고 있는 과장이나 부장밑에서 힘들게 고생하시는 한국의 프로그래머들을 보면 제가 다 화가 납니다. 또 프로젝트가 실패하는 큰 이유중에 하나는 "말도 안되게 수시로 변경되는 고객의 과도한 기능요구"라도들 합니다. 이 역시 맞는 말입니다. 무슨 도깨비 방망이라도 되는줄 알고 "이런저런 것들도 들어갔으면 하는데 간단하죠?"라고 고객이 말하면 나오는건 한숨밖에 없죠. 하지만 제 생각에 후자의 경우는 프로젝트에대한, 즉 원래 고객이 요구한 시스템에 대한 정확한 이해만 있으면 유동적으로 대처 할 수 있다는게 제 생각입니다. 프로젝트 초기에 가능한한 정확히 고객의 요구를 파악하고, 어느정도 변경이나 추가적인 요구가 들어와도 충분히 받아들일 수 있는 설계를 지향하는 것입니다. 이를 위해서 반듯이 필요한것이 요구사항 분석인데, 사실 많은 개발그룹들이 요구사항 분석을 단순 "요구사항서 낭독"쯤으로 생각하고 있는것 같았습니다. 제가 지향하는 "요구사항 분석"은 고객이 원하고 또 알고있는 것이상의 개발 시스템에대한 전문가가 되는것입니다. 자 그럼, 함께 Usecase를 사용해서 시스템을 분석해 보도록 합시다.

1. Usecase 란
1.1 정의
뭐 복잡한 말 하지 않겠습니다. 간단히 말해서 Use case란 말 그대로 "기능"이라고 보면 되겠습니다. 기능을 어느정도 작게 나눌지, 크게 합쳐서 표현할지는 개발 시스템마다 다르겠습니다.
1.2 특징
1.2.1 시스템 개발의 기본적인 단위가 된다.
무슨 말인고 하니, 대부분의 프로세스에서 제일 먼저 하는 일이 요구사항 분석입니다. 그렇기 때문에 Usecase가 이후 진행되는 프로세스에서 모듈이라던지 패키지라던지 컴포넌트도 전이될 확률이 상당히 높다는 말이죠, 즉 Usecase가 복잡하면 할 수록 시스템의 복잡도도 올라간다라고 할 수 있는것입니다.
1.2.2 구현 단계로부터 독립된다.
이 역시 당연한 말입니다. 길게 설명하지 않겠습니다.

2. Notation
2.1 Actor
액터는 다음과 같이 표현합니다.
액터가 생긴것이 "사람"모양을 하고 있어서 처음 공부하시는 분들은 Actor를 사용자에 국한시키는 경우를 몇번 보았는데 - 저도 역시 그랬구요 - Actor는 시스템의 기능을 사용하는 "외부의 모든것"을 의미합니다. 다른 시스템의 특정 컴포넌트가 개발할 시스템의 특정 기능을 사용하게 되면 그 외부 시스템도 역시 Actor가 되는 것입니다.

2.2 Usecase
Usecase는 다음과 같이 표시합니다.
간단하죠 ? 그냥 옆으로 길쭉한 타원에다가 Usecase의 이름을 적으면 됩니다. ^_^

2.3 System
System은 다음과 같이 표시합니다.
이 사각형이 가지는 의미는 시스템의 경계입니다. 이 사각형안에 위치한 Usecase는 해당 시스템에서 구현되어야 함을 의미합니다.

2.4 Relationship
자 그럼 이제 각각의 요소들과 연관을 지어서 좀더 의미를 부여해 보도록 합시다.

2.4.1 extend and include
extend와 include라는 관계가 있습니다. 의미를 설명하기 전에 먼저 아래의 그림을 봅시다.


점선과 화살표로 표시를 합니다. 이게 조금 의미가 복잡해질 수 있는데 간단히 설명해서 특수한 경우 수행되는 분기문정도로 이해하시면 됩니다. 크게 Include와 비교가 많이 되는데 include는 반드시 포함되는 필수불가결한 요소를 의미하며, extend는 경우에 따라 선택적으로 수행되는 기능을 의미합니다. 아래의 예제를 보도록 하죠.

Write Article은 반드시 Store to DB 기능을 사용한다는 의미로 받아드리시면 됩니다.
이제 extend를 살펴보도록 합시다. 우선 먼저 다음의 예제를 보도록 하죠.

위의 의미는 신용카드로 결재를 하는 Order with Credit에서 신용카드에 적립된 포인트로 결재를 하기를 원할 경우 Order with Point of Credit로 분기한다는 의미입니다.

2.4.3 generalization
객체지향에서 가장 중요한 의미인 상속입니다. 액터나 Usecase사이에서도 상속의 개념을 표현할 수 있습니다.
위의 그림을 보면 금방 이해하실 수 있으리라 생각됩니다. 관리자는 오퍼레이터의 기능을 가지면서 자신만의 고유한 기능을 또한 가지고 있습니다.

2.4.4 association
그럼 이제 액터가 시스템의 기능을 사용한다라는 가장 중요한 의미를 표현해 보도록 하겠습니다.
그림에서 액터와 Usecase사이의 실선이 바로 association입니다. 간단하죠 ? 그럼 이제 위의 그림을 설명해 보도록 하죠. 우선 시스템의 구현해야 할 기능들은 글을 쓰고, 고치고, 지우고 보여주는 기능입니다. User액터는 글을 읽을수만 있고, Writer액터는 글을 읽고, 쓰고, 지우고, 고칠 수 있습니다.
간단하죠 ?
간단한 예제이기 때문에 너무 그림자체에 몰두하지 말아 주시기 바랍니다. 아무 생각없이 그린 그림이라 의미가 이상하거든요.. 그냥 예제로만 보아주시기 바랍니다.
제대로된 그림은 차후 Case Study에서 한번 그려보자구요. ^_^

2.5 문서화
그럼 이제 그림은 대충 그렸는데, 문서화는 어떻게 해야 하는지 많은 분들이 물어 보십니다.
간단히 Usecase에 대해서 말씀드리면, 뭐 별거 없습니다. 기본적으로 Usecase는 액터와 시스템간의 상호 작용 - 바꿔말해서 시나리오 - 을 위주로 작성하시면 됩니다.
예) 1. 액터가 무엇을 한다.
    2. 시스템이 무엇을 한다.
    3. 액터가 뭘 한다.
    4. 시스템이 뭘 요구한다. 등등...

이 시나리오에서 객체라던지 모듈이라던지 등장할 필요은 없습니다. 하지만, GUI레벨 정도수준에서 무슨 화면이 나타난다 정도 기술해주시면 나중 작업이 상당히 수월해 집니다.
그리고 이때 도메인의 전문용어가 있으면 거침없이 사용해주시기 바랍니다. 나중에 수월해 집니다.

기회가 된다면 다음에 제가 사용하는 설계문서 포맷도 한번 올려 보도록 하겠습니다.

팁) 어떻게 Usecase와 Actor를 빨리 알아낼 수 있을까요 ?
다음의 Question List를 활용하실 수 있습니다.
1. Actor 추출

1)     시스템의 주기능을 사용하는 사람은 누구인가?

2)     누가 시스템으로부터 업무 지원을 받는가?

3)     누가 시스템을 운영, 유지 보수하는가?

4)     시스템과 정보를 교환하는 외부 시스템은 무엇인가?

5)     시스템이 내어놓은 결과물에 누가 관심을 가지는가?

2. Usecase 추출

1)     Actor가 요구하는 시스템의 주요 기능은 무엇인가?

2)     Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?

3)     시스템이 Actor에게 주는 어떠한 Event가 있는가?,  Actor가 시스템에 주는 어떠한 Event가 있는가?

4)     시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?

5)     시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

질문은 심원도선배님의 UML강좌에서 그냥 가져왔습니다. 기본적이고 다른 책에서도 많이 언급되고 있기 때문에 저도 그냥 따로 안만들었습니다.

휴우.. 오늘은 여기까지 하겠습니다. 다음 시간에는 Domain Modeling에 대해서 살펴보도록 하겠습니다.

'UML' 카테고리의 다른 글

About UML #04 - Domain Modeling 2.  (0) 2006.10.27
About UML #04 - Domain Modeling 1.  (0) 2006.10.22
About UML #02 Overview - 전체적인 구성 첫번째  (0) 2006.10.06
About UML #01 Overview - Why UML  (0) 2006.10.05
About StarUML  (1) 2006.10.05
Posted by 알 수 없는 사용자
UML2006. 10. 6. 13:44
안녕하세요. 지난 강좌에서는 왜 UML이라는 것이 중요한지 간단히 원론적으로 접근해 보았습니다. 이번시간에는 UML의 구성에 대해서 전체적으로 한번 다루어 보도록 하겠습니다. 조금 내용이 지루해질지도 모르겠지만, "No Pain, No Gain" 여러분 파이팅..

1. 개발 프로세스와 UML
왜 UML에 대해서 이야기를 하는데 또 듣기만 해도 골치가 아픈 프로세스 이야기를 꺼내는걸까요. 결코 제가 여러분을 괴롭히는것이 목적이라서 그런걸까요. ㅎㅎ 그렇지는 않습니다. (아냐 그럴지도 몰라요. ㅋㅋ 너무 저를 밎지 마세요)
앞서 시간에서 저는 UML의 가장 기초적인 의미에 대해서 언급하였습니다. 무엇인지 기억하십니까 ? 네에. 바로 의사소통을 위한 통일된 표기법이었습니다. 그럼 프로세스는 왜 언급한 것일까요 ?
바로 UML은 그 자체가 표기법이기 때문에, 어떤 표기법을 언제 사용하면 좋은지 알아야 될것 아닙니까 ? 그걸 모르고 어떻게 UML을 사용한다 하겠습니까? 마치 건물 설계도에서 화살표를 언제 써야 좋을지 모르는것과 마찬가지 상황이죠. (쓰고 나서 보니 참 황당한 상황이네요)
즉, 좀 어렵게 말한다면
UML자체가 프로세스가 아니라 단지 표기법이기 때문에, 프로세스가 진행됨에 따라 산출되는 결과물에 어떻게 UML을 적용하여 표현할지가 중요 포인트가 됩니다. 그걸 알기 위해서 이제부터 기본적인 프로젝트 진행 과정에 대해서 살펴 보겠습니당.

1.1 요구사항 분석
네, 바로 그 지겨운 요구사항 분석입니다. 다들 아시리라 생각합니다. 사용자가 요구하는 시스템을 이해하고 그 이해한 결과를 다시 표현하는 과정입니다. 이 과정이 중요한 이유는 고객이 생각하는 시스템과 개발자가 생각하고 있는 시스템을 일치시켜야 하기 때문이죠. 또한 개발해야될 시스템의 기능과 어디까지가 개발 대상인지 그 경계를 명확히 하기 위해서도 이 과정은 반드시 거쳐야 할 것입니다.
이 과정에서는 주로 Use Case Diagram이 많이 사용됩니다. 필요에 따라서 다른 다이어그램도 사용할 수 있습니다.

간단한 Usecase Sample

1.2 시스템 분석
분석단계에서는 이전 단계에서 고객의 요구를 정확히 파악했다는 전제하에, 개발해야될 시스템을 더욱 자세히 파고들어 세부부분들을 끌어내는 과정입니다. 이 과정에서 가능하다면 구현기술관련 분석은 하지 않는것이 좋습니다. 조금 어려운 말로 Domain을 분석한다라고도 말합니다.
조금 더 구체적으로 적어 보죠.
이 단계를 통해서 다음과 같은 일들을 수행 할 수 있을 것입니다.
 
  • 개발해야될 시스템에 대한 보다 자세한 세부점들을 파악해야 합니다. 가장 중요한것이 바로 비지니스 프로세스를 파악하는 것이겠죠.
  • 비지니스 클래스들을 파악할 수 있습니다. 비지니스 프로세스들을 파악한 클래스를 통해서 표현할 수 있습니다.
  • 여러번 이터레이션을 거치면서 보다 정확하고 정적인 클래스들관의 관계를 모델링 할 수 있습니다.
  • 그리고 이 단계에서 User Interface도 함께 디자인하여 최종결과물로서 GUI와 비지니스 클래스 들을 사용하여 비지니스 로직이 빠짐없이 수행될수 있도록 하면 됩니다.
이 단계에서 사용할 수 있는 다이어그램들은 Class Diagram, Sequence Diagram, Collaborate Diagram, State Diagram, Activity Diagram등이 있습니다.

간단한 Class Diagram Sample


1.3 시스템 설계
이 단계는 시스템 분석의 결과물에다가 보다 자세한 사항과 개발기술과 관련된 사항들을 접목시켜 한번더 시스템 설계를 확장하는 단계입니다. 좀더 쉽게 말한다면 어떻게 구현할 것인지를 이제부터 생각하면서 설계를 하는 것입니다. 이것을 MDA에서는 PIM, PSM이라고 하는데, 아직 그걸 이야기 할 정도 강좌가 진행된것은 아니지만 추상화 레벨을 달리하여, 시스템의 기능과, 그 기술적인 하부 구현부분을 분리하여 설계를 진행하면 추상화 레벨이 높은 부분의 분석단계의 결과물은 차후 재사용이 가능하다는 이점이 있습니다. (예를 들어 동일한 기능을 가진 시스템을 웹용, Windows용으로 개발할 경우 공통의 시스템 분석단의 결과물은 공유해서 재사용할 수 있다는 말입니다.)
구체적으로 다음과 같은 작업들을 수행 할 수 있습니다.
  • 클래스들을 package를 사용하여 그룹화 할수 있습니다.
  • 동시성의 경우 비동기적 메세지나 동기화 기술들을 고려하여 모델링 할 수 있씁니다.
  • 시스템의 인터페이스 (GUI, File, Network)등에 대해서 구체적으로 정의한다.
  • 예외처리에 대한 설계
  • 외부 라이브러리나 프레임워크 등을 표시한다.
이 단계에서 산출 할수 있는 결과물은 Class diagram, Sequence Diagram, Collaboration Diagram, State Diagram, Activity Diagram, Component Diagram, Deployment Diagram등이 있습니다.
이 단계역시 여러번의 이터레이션을 거치면서 설계를 견고하게 할 필요가 있습니다.

간단한 Class Diagram Sample

1.4 구현
이 단계는 머 별거 있나요.. 코딩하는 단계죠. 이전의 단계에서 자세하게 설계를 한만큼 이 단계에서 편하게 작업이 가능할 것입니다. 많은 개발자들이 지금까지의 앞단계를 무시하더가 대충 한다음에 바로 코딩으로 들어가는 경우가 많은데, 객체지향적 설계의 장점을 살리기위해서는 분석과 설계는 반드시 필요한 단계라고 할 수 있겠습니다.
구현하는 과정에서 설계가 변경될수 있는데, 이 경우 귀찮게 여겨질수도 있지만, 설계 문서의 변경도 반드시 해놓아야 할 것입니다. 이 단계에서 UML을 사용해서 따로 결과물을 생성하는 일은 아마 드물것입니다.

1.5 테스트
개발한 시스템을 테스트 하는 과정입니다. 요즘들어 테스트의 중요성이 다시 한번 확인되어지고 있는데요, 저는 테스트 시나리오 작성을 Sequence와 Activity를 통해서 작성했던 적이있습니다.

1.6 배포
Deploymeny Diagram을 사용하여 설계한 문서가 있다면 이 단계에서 그 문서를 사용할 수 있습니다.

휴우.. 오늘 강좌는 여기까지 하도록 하겠습니다. 글을 쓴다는것이 생각처럼 쉬운일이 아니네요.. 다음 시간에는 전체적인 다이어그램의 종류에 대해서 언급하겠습니다. 자 그럼... 바이 바이

'UML' 카테고리의 다른 글

About UML #04 - Domain Modeling 1.  (0) 2006.10.22
About UML #03 - Usecase  (0) 2006.10.10
About UML #01 Overview - Why UML  (0) 2006.10.05
About StarUML  (1) 2006.10.05
앞으로의 강좌 진행에 대해서  (4) 2006.10.05
Posted by 알 수 없는 사용자
UML2006. 10. 5. 22:36
많은 사람들이 저에게 물어본 질문중에 한가지는
박재진씨 UML을 쓰면 뭐가 좋아?
그럼 저는 이렇게 대답하곤 했었습니다.
별로 좋은것 없습니다.
?? 이게 도대체 무슨 말인지.. UML강좌를 시작한답시고 첫 서두에서 한다는 말이 UML을 써서 별로 좋을게 없다라니.. 강좌를 할 생각이있는건지 없는건지..
물론 강좌는 진행합니다. 안심하세요.
하지만 제가 강좌전에 하고 싶은 말은 UML이라는것이 엄청난 마법도구라서 개발이 엄청나게 편해진다거나, 단 몇번만의 클릭으로 모든것을 만들어주는 만능도구가 결코 아니라는 것입니다. 이점 하나만은 확실히 해두고 싶었습니다. 오히려 UML때문에 작업이 더 복잡해질수도 있고, 작성해야할 문서가 갑자기 늘어날 수도 있으며, 오히려 UML을 쓰고싶지 않게 될수도 있습니다.  

그럼 도대체 UML은 왜 쓰는건데 ??

이 질문에 대한 제 나름대로의 생각을 말하기 전에 먼저 여러분에게 묻고 싶습니다.

여러분은 도대체 왜 영어를 공부합니까 ?

영어라는 단어에 벌써 머리가 지끈거리시는 분이 계실지도 모르겠지만,
답은 간단합니다. 외국인하고 말할려고 배우는 것입니다.
좀더 구체적으로 말하자면, 글로벌시대에 지구에서 가장 널리 여러나라에서 사용되는 외국어인 영어를 배워서 글로벌한 의사소통을 할수없으면 대한민국에서는 먹고 살기(대학, 취직, 직장생활)가 좀 힘들어지기 때문이 아닙니까 ?

UML도 마찬가지 입니다.
  1. 혼자서 일당백으로 전체 시스템을 개발하던 시대는 지나갔다.
  2. 일당백이라 하더라도 자신의 머리속을 간단하게 정리하고 싶다.
  3. 긴 문장의 글보다 간결한 그림한장이 더 의미를 명확히 전달할수 있음을 알고 있다.
  4. 다른 프로그래머와의 개발관련 회의나 토론에서 서로 무슨말을 하는지 전혀 모르겠고 짜증이 난다.
  5. 문서화의 필요성을 알고 있으며, 보기에 그럴사한 문서를 만들고 싶다.
  6. 일관되고 널리 사용되는 표기법을 공부하고 싶다.
  7. 등등등.

위에 열거한 항목들에 동의를 하신다면 (아마 대부분 동의하시리라 생각하지만..)
UML은 좋은 솔루션이 될수 있습니다. (너무 원론적인 이야기였나요 ?)

그럼 함께 UML을 살짝 살펴보도록 할까요 ?

'UML' 카테고리의 다른 글

About UML #04 - Domain Modeling 1.  (0) 2006.10.22
About UML #03 - Usecase  (0) 2006.10.10
About UML #02 Overview - 전체적인 구성 첫번째  (0) 2006.10.06
About StarUML  (1) 2006.10.05
앞으로의 강좌 진행에 대해서  (4) 2006.10.05
Posted by 알 수 없는 사용자
UML2006. 10. 5. 16:59
강좌에 들어가기 앞서서
아주 유용한 기능들을 많이 가지고 있지만.. 주류가 아니라는 이유로
널리 사용되어지고 있지는 않는 비운의 StarUML에 대해서 간단히 소개해보고자 합니다. ^_^

1. StarUML 이란 ?

StarUML은 빠르고, 유연하고, 확장가능하며, 풍부한 기능에 Win32 플랫폼에서 무료로 사용할 수 있는 UML/MDA 플랫폼(툴)을 개발하기 위한 오픈 소스 프로젝트입니다. StarUML 프로젝트의 목적은 Rational Rose, Together와 같은 상업적 도구를 비싼 돈을 들여 사용하지 않더라도 그에 준하는 기능을 갖춘 오픈 소스 소프트웨어 모델링 도구 및 플랫폼을 개발하는 것입니다.

  • UML 2.0 : UML 은 OMG(Object Management Group)가 지속적으로 관리하는 통합 표준입니다. 최근에 UML 2.0이 릴리즈 되었으며 StarUML은 UML 2.0 을 지원하며 최신 UML 표준을 지원하고 있습니다.
  • MDA (Model Driven Architecture) : MDA는 OMG가 도입한 새로운 기술입니다. MDA의 장점을 얻기 위해서는 소프트웨어 모델링 툴은 많은 커스터마이징 요소들을 지원해야만 합니다. StarUML은 MDA를 지원할 수 있도록 설계되었고 UML 프로파일, 접근법, 모델 프레임워크, 표기법 확장, MDA 코드 및 문서 템플릿 등 수많은 커스터마이징 요소들을 제공합니다. 이러한 것들은 여러분의 조직문화, 프로세스 및 프로젝트에 툴을 맞출 수 있도록 도와줍니다.
  • 플러그-인 아키텍처 : 많은 사용자들이 소프트웨어 모델링툴에 더 많은 기능을 요구합니다. 이러한 요구사항에 부합하기 위해, 툴은 플래폼에 매우 잘 정의된 플러그를 가져야만 합니다. StarUML 은 누구든지 COM과 호환가능한 언어(C++, Delphi, C#, VB 등)에서 플러그인 모듈을 개발할 수 있게 단순하며 강력한 플러그인 아키텍쳐를 제공합니다.
  • 사용성 : 사용성은 소프트웨어 개발의 가장 중요한 사항입니다. StarUML은 퀵 다이얼로그, 키보드 조작, 다이어그램 오버뷰 등과 같이 많은 사용자들에게 친숙한 특징을 제공할 수 있도록 적용되었습니다.

StarUML 홈페이지에 나와있는 설명입니다. 과거 Plastic이란 이름으로 대학 선배들과 함께 만들었던 실력있는 프로그래머들의 노력과 집념의 결정체라고 한마디로 정의할 수 있겠습니다.
개발툴은 델파이를 사용하였죠. 많은 분들이 Delphi로 만들었다는것에 대해서 놀라시던데요.. 델파이는 여러분이 생각하는것보다 훨씬더 강력하고 유용한 개발툴이랍니다. ㅋㅋㅋ

2. StarUML 의 기능들
스크린샷들을 보면서 설명해보도록 하죠. ㅋㅋ

일단 기본적인 다이어그램들은 충분히 다 지원을 하며 화면 우측에 볼수 있듯이 편리한 접근 인터페이스를 제공하고 있습니다. 그리고 과거의 플라스틱 시절부터 지원해온 '퀵 다이얼로그'기능은 프로그래머들로부터 많은 찬사를 받아왔었습니다. 하지만 StarUML의 기능은 절대 이것만이 아닙니다.

지금까지의 기능은 빙산의 일각에 불과합니다.
StarUML의 진정한 강력함을 느껴보십시오.



무엇이라고 느끼십니까 ? StarUML에서는 ER-Diagram을 지원하지도 않고 자체적으로 아이콘으로 표시되는 기능을 가지고 있지도 않습니다. 다만 StarUML에서 지원하는것은 Profile기능을 지원하고 있을 뿐입니다.
이 Profile기능을 사용하여 보다 다양한 Notation을 지원할 수 있게 되는 것입니다.

요즘 Eclipse는 자바 플랫폼에서 표준 개발툴이 되다시피 널리 사용되어지고 있습니다. 저는 그것의 큰이유는 오픈 플랫폼이며 견고한 기반 설계와 놀라운 확장성이라고 생각합니다. Eclipse는 기반 프레임워크에 얼마든지 확장 기능을 덧 붙일수 있게 아주 잘 설계되어 있죠. 정말 켄트 벡이라는 사람을 존경할 수 밖에 없을것 같습니다.
그 놀라운 프러그인 기능이 StarUML 에서도 지원됩니다. 그것도 아주 훌륭하게 말이죠. 오픈 플랫폼이기 때문에 간단한 프로그래밍 실력이 있으신 분들이라면

누구라도 StarUML에서 동작하는 자신만의 필요를 채워줄 독특한 플러그인을 만들수 있습니다.

또 강력한 기능으로 문서화가 있습니다.
HTML, XML, WORD, Excel, 등등 자신이 원하는 문서서식대로 얼마든지 StarUML은 시스템설계문서를 생성해낼수 있습니다. 정말 대단하지 않습니까 ?

물론 자잘한 버그도 있고, 상용툴에 비해서 지원이 약한것도 사실이지만, 오픈소스로서 이만한 기능의 프로그램을 사용할 수 있는 기회는 많지 않습니다.
StarUML과 함께 UML의 세계로 빠져 봅시다. ^_^

'UML' 카테고리의 다른 글

About UML #04 - Domain Modeling 1.  (0) 2006.10.22
About UML #03 - Usecase  (0) 2006.10.10
About UML #02 Overview - 전체적인 구성 첫번째  (0) 2006.10.06
About UML #01 Overview - Why UML  (0) 2006.10.05
앞으로의 강좌 진행에 대해서  (4) 2006.10.05
Posted by 알 수 없는 사용자
UML2006. 10. 5. 14:35

Java와 UML강좌에 대해서 앞으로 이렇게 진행해 볼려고 합니다.

일단 UML Tool은 대학시절 젊음을 바쳐 만들었던 Plasticsoftware의 Plastic을 사용하겠습니다.지금은 이름이 바뀌어 StarUML입니다. www.staruml.org 입니다. 간혹 정말 당신이 참여해서 만들었었냐고 물으시는 분들이 계시는데..

정말입니다. -_-; 못믿겠으면 www.plasticsoftware.com에 저에 대해서 물어 보시기 바랍니다.
별로 한건 없지만 그런 사람 모른다고 하지는 않을겁니다.

대학 시절의 벤처라 정이 무지 무지 많이 가네요.

일단 첫 강좌와 앞으로의 몇회는 StarUML에 대해서 해 볼까 합니다.

UML을 사용하시는 분들중에서 아시는 분들이 얼마 안계시더라구요.. 슬픈 현실이지만..

그리고 요즘 Java에서 화두가 되고 있는 FrameWork에 대해서 끄적여 볼까 합니다.
이미 화두가 아닐지도 모르겠지만...

어딘가에는 도움이 되는 분이 계시리라 믿고.. 한번 해보겠습니당... ^_^
메일로 원하시는 강좌제목을 요청해 주셔도 무방합니다.
가능하다면 제가 알고 있는 한도내에서 원하시는 강좌도 한번 해볼까 합니당.

'UML' 카테고리의 다른 글

About UML #04 - Domain Modeling 1.  (0) 2006.10.22
About UML #03 - Usecase  (0) 2006.10.10
About UML #02 Overview - 전체적인 구성 첫번째  (0) 2006.10.06
About UML #01 Overview - Why UML  (0) 2006.10.05
About StarUML  (1) 2006.10.05
Posted by 알 수 없는 사용자