1

UML, Logic and Java 모델기반의 객체지향프로그래밍

Part I

한석현 PhD

umlspec@hotmail.com

July 2016

More slides from

http://umlspec3.wixsite.com/home

2

이 책은 지난 10 여년 동안 영국에서 UML 을 정복하기 위한 저자의 도전을 기록한 것입이다.

단지 UML 을 알기 위해서 영국으로 유학을 떠났는데, 수학(Mathematics)과

수리논리학(Mathematical Logic, 컴퓨터 사이언스의 기초학문)까지 연구를 해야만 될 줄은

저자도 몰랐었습니다. 하지만 행복한 도전 이었기에 저자의 경험을 여러분과 공유하고자

합니다.

영국에서 연구와 일을 하면서 계속해서 책을 쓰고 있었습니다. 언젠가는 한국에 가서 쓸 수

있는 강의 노트를 만들기 위해서 였습니다. 대부분 영어로 작성되어 있는데, 이번 여름부터

한글로 번역을 시작하고 있습니다. 일부 번역한 부분을 먼저 공개를 하는 것도 많은 분들에게

도움이 될 것 같아서 용기를 내었습니다.

이 책의 목적은 여러분들이 700 여 페이지 되는 UML 문서를 혼자서 읽을 수 있도록 도와 주는

것이며, 그래서 여러 분들을 메타모델리스트(meta model-ist, 메타모델을 즐기는 사람)로

만들어 주는 것이 저의 목표입니다. 또한 IBM Rational Software 에서 제공하는 Rational Software Architect, Rational Application Developer for Websphere, Rational Rhapsody, Rational Next Door

Generation 과 같은 멋진 개발 툴들을 여러 분들이 이제는 제대로 사용해서 객체지향

프로그래밍의 진짜 맛을 느끼게 해주고 싶습니다.

저자는 근래에 TOGAF(The Open Group Architecture Framework) 문서를 자세히 연구해 보고

있습니다. TOGAF 는 기업형(enterprise level) 소프트웨어를 만들 때 필요로 하는 아키텍쳐의

표준을 정해주는 문서입니다. 당연히 TOGAF 의 배경에는 UML 이 숨어 있습니다. TOGAF 문서를

읽으면서 저자가 너무 놀란 것이 한국의 어떤 기업도 이 표준화에 참여하고 있지 않다는

것입니다. 또한 UML 을 포함하는 OMG 에 등록되어 있는 어떠한 문서에도 한국 대학과 기업의

이름은 보이지 않습니다. 이것이 무엇을 뜻하는지는 독자 여러분들의 판단에 맡기겠습니다.

UML 이 처음 나온 이후부터 20 여년이라는 오랜 시간이 지났지만, 한국에서 바뀐 것은 너무

미미한 것 같습니다. 한국 엔지니어중에서 몇명이나 OMG 에서 만들어진 문서를 직접

이해하려고 노력하는지 궁금합니다. UML 과 관련해서, 아직도 따라하기 수준의 초보자들을

위한 책들만이 계속 출판되는 것이 한국의 현실입니다.

저자가 유럽에서 10 년 이상 지내면서 많은 학회와 세미나를 참석해 보면서, 가끔씩 한국

분들을 만났을 때 수리논리학을 연구하는 한국 분들이 있다는 것을 알고 많이 기뻐했습니다.

하지만 거의 모든 분들이 유럽과 미국에서 지내고 있는 분들입니다. 한국으로 돌아갈 계획은

거의 없는 것 같습니다. 한국의 어떤 기업도 수리논리학에 관심을 가져 주기 않기 때문입니다.

그러면서 기업들은 인재가 없다고 불평을 합니다. 근래에 삼성전자가 미국의 여러 소프트웨어

업체들을 수천억을 주고 사들이고 있는 것을 보면서, 가슴이 많이 아팠습니다. 차라리 그

돈으로 멀리 10 년을 내다보고 많은 한국 학생들을 유럽과 미국으로 보내서 수리논리학을 연구

3

할 수 있도록 도움을 주는 것이 낫지 않을까 싶습니다. 수리논리학은 소프트웨어 엔지니어들이

반드시 가져야 될 사고의 방법(reasoning skills)을 가르쳐주는 학문입니다.

UML 에 제대로 접근을 할 수 없는 이유가 무엇인지, 여러분들이 이 책을 통해서 많이 깨닫기를

바랄 뿐입니다. 하지만, 분명한 것은 저자 혼자서는 이 책을 마칠 수는 없다는 것입니다. 아마도

이글을 읽는 누군가가 꼭 같이 해보고 싶다는 마음이 생기도록 하기 위해서 이 책을 쓰기 시작

한 지도 모르겠습니다. 생각을 같이 하는 엔지니어를 찾고 싶은 것이 저자의 간절한

희망입니다.

July 2016

London

4

Contents 1 Introduction .................................................................................................................................... 5

2 Meta structure 1 ........................................................................................................................... 13

3 Formal system ............................................................................................................................... 20

4 Modelling language ....................................................................................................................... 26

5 UML 을 배우기 위한 5 개의 중요한 컨셉 .................................................................................. 32

5.1 Root ....................................................................................................................................... 32

5.2 Classifiers .............................................................................................................................. 36

5.3 Behaviours ............................................................................................................................ 40

5.4 Events .................................................................................................................................... 47

5.5 Stereotypes ........................................................................................................................... 48

6 Meta structure 2 ........................................................................................................................... 55

7 UML 을 배우는 궁극적인 목적 – 지적 재산권 ........................................................................... 57

5

1 Introduction

저자는 이 책을 통해서 OMG1에 공개되어 있는 다양한 모델링 언어(Modelling Languages)를

어떻게 배워야 하는지, 여러분과 함께 고민을 하면서 새로운 방법을 찾고자 이 글을 쓰기

시작했습니다. 먼저 현재 OMG 에서 인기가 많고, 저자가 가장 관심있게 보고 있는 모델링

언어를 몇가지 나열해 보았습니다.

UML (Unified Modelling Language)

SysML (System Modelling Language)

BPMN (Business Process Modelling Notation) with BPEL (Business Process Execution Language)

CMMN (Case Management Model and Notation)

DMN (Decision Model and Notation)

이러한 언어들 이외에도 SoaML, UPDM, SBVR, BMM 등이 OMG 에 등록이 되어있고, 더 많은

모델링 언어들이 계속 만들어질 것 같습니다. UML 을 제외하고는 한국의 소프트웨어 개발자

분들에게 이러한 다양한 모델링 언어들이 아마도 많이 생소할 것 같습니다. 이러한 모델링

언어를 기존의 프로그래밍 언어 C++/Java 를 배우 듯이 접근을 하면 성공할 수 없다는 것은

저자의 확신이고, UML 을 배워 보려고 몇년간 노력을 해보신 독자 분들 이라면 공감하리라

생각 됩니다. 또한 UML 도 이해하기 어려운데, 왜 이렇게 많은 모델링 언어들이 나오는지

한숨이 먼저 나올것도 같습니다.

UML 을 접하는 거의 모든 프로그래머들은 이미 객체지향프로그램을 경험한 개발자들입니다.

C++/Java 언어의 문법은 이미 전문가 수준이고, 아마도 10,000 라인 이상을 밤잠을 설쳐 가면서

코딩을 한 경험이 있을 것입니다. 이러한 분들은 분석/설계 과정의 중요성을 잘 알고 계십니다.

화이트보드에 또는 종이에 다양한 그림을 그려가면서 고객의 요구 사항을 분석하고, 어떻게

코딩을 전개해 나갈지 설계를 하게 됩니다. 하지만 이러한 분석/설계 과정에서 만들어진

결과물(software artifact) 들이 잘 정리된 문서로 남겨지는 것은 아주 드뭅니다. 어떤 결과로

이어질 지는 여러분들이 더 잘 알고 계십니다. 수시로 바뀌는 사용자들의 요구 사항을 반영하기

위해서 분석/설계 과정은 다시 시작되야 되고, 지겨운 코딩은 다시 반복됩니다. 이러한

분석/설계/코딩의 과정을 개선하기 위해서 만들어진 것이 UML 입니다. 그러니, 누구나 UML 을

배우고 싶어합니다. UML 은 개발 과정을 모델링/구현(implementation)이라는 두 과정으로

단순화한 것입니다. 하지만, 배우다 보면 이해도 않되고, 곧 좌절을 하는 것이 현실입니다.

1 Object Management Group

6

저자가 대학생이던 시절 1997 년 봄, OMG 에서 UML specification 문서를 처음 발표 했을 때

저자가 느꼈던 흥분, 두려움, 그리고 좌절감은 지금도 잊혀지지를 않습니다.

Unified Modelling Language (현재 version 2.5)

이 책을 읽는 독자들도 한번쯤은 수백페이지에 달하는 UML specification 문서를 읽어보려고

시도는 해 보았을 것이고, 곧 아래에 열거된 용어(terms)들을 보고 포기를 했을 것입니다.

C++/Java 언어를 배우면서, 전혀 만나지 못했던 단어들입니다.

Semantics meta-model Meta meta-model Stereotype Interface constraints Tagged value Context Part Port Association/connector/link Object / role Object token Control token Association class Action semantics Object constraint language constraints Well-formedness rules behavior component events Meta object facility classifiers

다음에 할 수 있는 것은 UML notations 을 쉽게 따라 해볼 수 있는 책을 찾으러 온라인 북 서적을

찾고, 책을 읽어보면서 조금씩 따라해 보았을 것입니다. 하지만 그것뿐이라는 것도 곧 알게

됩니다. 자신의 업무에 적용 하려고 하면 불가능 하다는 것을 곧 알게 됩니다. 대부분의 책들이

use case diagram 을 이용해서 무엇을 정보시스템으로 구현해야 되는지 추출해 내려고 합니다.

그 다음은 activity diagram 을 이용해서 정보 시스템으로 구현될 업무를 보다 자세히 분석하려고

합니다. 그 다음은 class diagram 을 통해서 프로젝트에 등장하게 될 클래스(class) 들을 찾아내고,

sequence diagram 을 통해서 클라스에 들어가게 될 메소드(methods)를 찾아냅니다. 그리고

다음은 코드를 생성하고, 아마도 당연히 텅 빈 메소드를 받아 들고, 이제부터 뭘 해야 하는지,

답답한 마음을 많은 분들이 경험을 해보았을 것입니다. 이 정도 코드 생성이라면 왜 굳이 UML

을 알아야 하는지, 직접 코딩을 하는게 더 나을 것 같다라는 생각을 하고, 현재 자신의

프로젝트에는 UML 을 사용할 수 없다는 것을 많은 분들이 경험들 하셨을 것입니다. 그러면서

UML 에서 점점 멀어지면서 포기하고, UML 은 단지 이상향일 뿐이라고 자신에게 변명하면서,

C++/Java 코딩의 세계로 다시 돌아갑니다.

UML 과 관련된 강의나 세미나를 참석해 보시면 가장 많이 듣는 질문이 UML 을 사용해서 만든

프로젝트의 예를 보여 달라는 것입니다. 너무나 어리석은 질문입니다. 마치 중고등학교

수학시간에 선생님께 칠판에 문제를 풀어 달라는 것과 같습니다. 그 다음부터 비슷한 문제를

만나면 같은 방법을 이용해서 따라 하겠다는 것입니다. Java 언어를 배울 때도 이러한 비슷한

과정을 통해서 교육을 받습니다. 가장 먼저 문법(syntax)를 배우고, 그 다음에 배우는 코스는

Java Design Pattern 입니다. 이미 공개되어 있는 자주 사용되는 알고리즘 들을 배우는

7

과정입니다. 아마 많은 분들이 알고리즘을 따라해 보면서 감탄을 했을 것입니다. 어떻게 이런

생각을 했을까 하고 놀라지만 그 뿐입니다. 본인 자신이 그러한 알고리즘을 만들어 내지는

못합니다. 현재 한국의 UML 교육이 비슷한 상황이 아닐까 합니다. UML 교육시간 동안에는

예를 보면서 이해하는 것 같지만, 막상 본인의 프로젝트에는 UML 을 사용할 수 없습니다. 다시

말해서 실전에서만 필요로 하는, 실제 프로젝트에 쓸 수 있는 몇개의 UML notation 만을

요약해서 배운다는 것은 아무 의미가 없는 노력입니다.

저자의 경험과 영국에서 박사과정을 통해서 배운 지식을 바탕으로, 다음에 제시된 단어들을

설명하지 않는 책을 여러분들이 읽고 있거나, 또는 이러한 단어들을 설명하지 않는 강의를

여러분들이 참석하고 있다면, 결과적으로 UML 의 핵심과 본질을 이해하는 데는 전혀 도움이

되지 않는다고 확신해서 말씀해 드릴 수 있습니다.

Element, Classifier, Composite structure/Component, Meta model, Action semantics, Object constraint language, Stereotype, Profile

우리 모두가 이미 알고 있듯이 화학에서 사용되는 표현의 기본 단위는 원자(atom) 입니다.

C++/Java 언어를 사용해서 프로그래밍을 할 때 가장 기본이 되는 것은 클래스(class) 입니다.

객체지향 프로그램은 단지 클래스와 클래스의 관계를 표현한 것뿐입니다. 그렇다면 UML

모델링의 가장 기본이 되는 개념이 무엇일까요? Element 입니다.

8

위의 다이어그램이 UML specification 문서에서 가장 먼저 등장하는메타모델(meta model)

입니다. 그 이름을 Root 라고 지었습니다. 즉, 모든 메타모델의 시작이 된다는 의도로 만들어진

것입니다. 가장 먼저 눈에 뛰는 것이 Element 입니다. 위에 보이는 Element, Relationship,

DirectRelationship, Comment 를 모두 meta class 라고 부릅니다. 이 책에서 지금 여러분들에게

제가 처음으로 meta 라는 단어를 소개하고 있습니다. 앞으로 여러분들을 계속해서 메타의

세계로 이끌고 갈 예정이니, meta 가 나올 때 마다 많은 주의를 기울이셔야 합니다. meta 를

정확히 이해하는 것이 UML 을 정복하는 것입니다. 여러분께 첫번째 질문을 하겠습니다. 위의

메타모델을 보시면, 세 개의 단어(Element, Relationship, DirectRelationship)가 이탤릭체를

사용해서 옆으로 기울여 놓았습니다. 왜 그런지 잠시 고민을 하시기 바랍니다. 곧, 제 5.1 절

Root 에서 Element 를 자세히 설명할 예정입니다.

9

위의 그림은 UML specification 문서에 보이는 모든 메타모델들을 체계적으로 분류한 표입니다.

앞에서 이미 설명했듯이, 여러분이 UML 을 사용해서 다이어그램을 그린 후 코드를 생성했을

때, 텅빈 메소드를 가지게 되는 이유는, 바로 위 그림에 보이는 Actions 메타모델을 모르기

때문입니다. 제 5.3 절 Behaviors 에서 Actions 메타모델을 설명할 예정입니다.

여러분이 UML 관련 책을 보시거나 또는 강의를 가시면, 저자/강사분들이 Class 를 만드는

것에만 설명을 집중 하고 있습니다. 어떤 책도 Classifer, Composite structure, Component,

Requied Interface, Provided Interface, Port, Part, Connect 에 대해서 자세히 설명을 하는 것을 보지

못했습니다. 그것은 책을 쓰는 저자분들이, 위 그림에 보이는 Classifiers 메타모델을 정확히

모르기 때문입니다. 그리고 UML 을 설명하는 어떤 강사분도 Stereotype / Profile 을 Rational

Software Architect 와 함께 예를 들면서 설명을 하시는 분은 없습니다.

저자는 모델링 언어를 정복하기 위해서 여러분들이 이제까지 경험하지 못한 Computer Science

라는 과학의 세계로 독자분들을 데리고 가기를 원합니다. 과학 이라는 것은 아주 간단합니다.

가설(hypothesis)을 세우고 실험을 통해서 이 가설이 맞는지 증명을 하는 과정일 뿐입니다. 많은

독자분들이 의아해 하실 거라 생각이 드네요. 컴퓨터 영역에서 무슨 가설을 세우고, 어떻게

실험을 하라는 것인지? 저와 같은 이러한 생각을 하는 컴퓨터 엔지니어들을 유럽과 미국에서는

Theoretical Computer Scientist 라고 부릅니다. 이 책을 통해서 이러한 엔지니어들이 무엇을

10

연구하고 있는지 여러분에게 안내하는 것이 저의 역할이라고 생각이 듭니다. 이러한 접근

방법이 모델링 언어를 이해할 수 있는 지름길이기도 합니다.

현재 우리가 사용하는 언어를 간단히 정리해 보았습니다.

예 공통점 다른점

자연언어(natural language) 한국어, 영어, … 메타구조 (meta structure)

Textual language (문자를 사용)

인공언어 (artificial language)

Programming language

Java, c++, Cobol, …

Modelling language

UML, SysML, … Graphical language (도형을 사용)

위의 테이블에 적혀 있는 내용을 보면서 대충은 이해가 되지만 메타구조가 공통점이라는 점에

대부분의 독자분들이 이해가 되시지 않을 것입니다. 당연히 메타구조(meta structure)가

무엇인지 정확히 모르기 때문입니다. UML specification 문서에서 가장 많이 등장하는 단어는

meta 입니다. 위에서 말씀드린 Theoretical Computer Scientist 들이 연구하는 것이, 바로

컴퓨터에 사용이 되는 프로그래밍 언와 모델링 언어의 메타구조 입니다. 이러한 메타구조를

이해하는 것이 UML 언어를 정복하는 가장 빠른 길 임을 다시 한번 강조합니다.

모델링 언어를 배우는

목적은 독자분들도 이미

알다시피 Model Based

Development2 (MBD)를

도전하기 위함 입니다.

쉽게 말해서 MBD 는

프로그램을 개발하기

위해서 코딩이라는 단순

작업을 피하고 싶은,

많은 소프트웨어

엔지니어들의

이상입니다. Stakeholder3 의 요구사항(requirements)을 알아낸 이후, Rational Software Architect

또는 Sparx Enterprise Architect 와 같은 툴을 이용해서 UML 다이어그램을 그려주게 되면,

자동으로 프로그램 코드를 생성할 수 있다는 것이 개발자들의 MBD 에 이해입니다. 하지만

2 Some books said Model Driven Development 3 소프트웨어 개발을 발주한 회사, 최고 책임자, 소프트웨어를 사용하게 될 회사의 직원들, 그리고

사용하게 될 고객까지 포함하는 단어 입니다.

Modelling Languages

UML, SysML, BPMN, …

Domain Knowledge

Finance, Auto, Defence, Logistics, …

Methodologies

Rational Unified Process, IBM Jazz, Agile, Scrum, TOGAF,DODAF….

Tools

Rational Products(Doors, Team Concert, Architect,

Rapsody,…)

Sparx Enterprise Architect, …

11

현실적으로 MBD 를 할 수 없다는 것이 우리의 안타까운 상황이 아닐까 합니다. 이유는 아주

간단하면서도 어려운 것 같습니다. MBD 를 위해서는 위에 보여지는 네 가지를 완벽하게

준비하고 있을 때만 가능하다는 것이 저자의 경험입니다. 위의 네 가지 중에서 가장 중요한

것은 모델링언어(Modelling Languages)를 정확히 습득하는 것입니다. 아마도 한국에서

소프트웨어 엔지니어들이 MBD 에 진입할 수 없도록 만드는 가장 큰 장벽입니다.

OMG 에 공개되어 있는 UML specification 문서는 소트트웨어 벤더(vendors)들이 Rational

Software Architect / Sparx Enterprise Architect 와 같은 툴을 만들기 위한 지침서입니다. 하지만

보통의 사용자들도 UML specification 문서를 반드시 이해해야만 한다는 것이 저자의 견해이고,

이 책을 써나아가는 이유이기도 합니다.

1997 년 UML 1.0 문서가 처음 발표된 이후, UML 의 창시자라고 부르는 Booch, Rumbaugh,

Jacobson 은 두개의 책을 출판을 했습니다. UML 2.0 이 발표된 이후에도, 이 두 책을

업그레이드해서 다시 출판을 했습니다.

The Unified Modelling Language User Guide, 2nd edition

The UML User Guide: UML 실전 활용 테크닉(번역본)

The Unified Modelling Language Reference Manual, 2nd edition

왜 이 세분이 이러한 책들을 계속해서 출판하게 됐을까요? 저자의 개인적인 의견으로는,

Booch, Rumbaugh, Jacobson 는 보통의 소프트웨어 엔지니어들이 UML specification 문서를

이해하는 것은 불가능하다고 생각을 했던 것 같습니다. 그래서 보통의 UML 사용자들을 위해서

두개의 해설서를 쓴 것 같습니다. 본인 저자의 의견을 다시 독자들께 말씀드리면, 어느

누구에게도 이 두 권의 책을 읽어보라고 권하고 싶지는 않습니다. 왜냐하면 이 두 권을 다 읽은

후에도 역시나 UML 을 정확히 사용할 수 없는 것은 마찬가지 이기 때문입니다. 그 이유는

메타모델에 대한 설명이 전혀 없습니다.

UML 이 발표되기 이전에도 저자는 몇 년 동안 Booch, Rumbaugh, Jacobson 이 쓴 여러 원서들을

보면서 객체지향모델링(Object Oriented Modelling)이 무엇인지 몇년간 많은 고민을 하고

있었습니다. 이 세분이 만든 Booch method, OMT, OOSE 방법을 익혀가면서 객체지향 모델링

테크닉을 배웠지만, 그려진 모델들이 C++/Java 의 가장 기본이 되는 클래스 디자인과 어떻게

연결이 되는지 알 수가 없었습니다. 이 세분이 UML 의 탄생을 위해서 아이디어를 제공 했지만

그들이 쓴 책들은 도움이 되지 않는 다는 것이 저자의 결론입니다.

대신에 여기에서 한권의 책을 소개해 드리겠습니다.

12

UML 2 Certification Guide4, written by Tim Weilkiens

UML specification 문서에 등장하는 많은 메타모델 들을 직접 설명 하고자 노력을 하고 책입니다.

너무 좋은 책이니 독자분들께 꼭 권하고 싶습니다. 단지 문제가 UML 2.0 을 기반으로 설명을

했기에, 현재 UML 2.5 와는 조금 다를 수 있습니다. 하지만, 저자가 앞에서 언급한,

Element, Classifier, Composite structure/Component, Meta model, Action semantics, Object constraint language, Stereotype, Profile

이러한 중요한 개념에 대해서 유일하게 설명을 하는 책입니다. 이 책을 읽고 난후 UML

specification 문서를 보시면, UML 에 대한 많은 두려움이 조금씩 사라지고 있다는 것을 느끼실

수 있습니다.

소트트웨어 엔지너어는 더 이상 코딩만을 하는 기술자가 아니라 모델링을 하는 전문가라는

것을 우리 모두가 다시 깊이 생각을 했으면 합니다. 하지만 현실적으로 MBD 가 어느 정도

가능할 지는 개발자들이 수행하는 프로젝트에 따라서 많이 달라집니다. 저자의 경험으로

모델로부터 코드를 100% 생성시켜서 전혀 코딩을 할 필요로 하지 없는 그런 상황은 없습니다.

생성된 코드를 부분적으로 고쳐야만 되는 customizing 과정은 필수 입니다. 또한 모델링

단계에서 직접 Java 를 사용하기도 합니다. 예를 들어서, Action semantics 를 이용해서 activity

diagram 을 만들어 갈때, Java APIs 를 직접 쓰기도 합니다. 가장 간단한 예는 수학에서 나오는

공식들입니다. 이러한 기능을 Rational Software Architect 에서 Opaque Coding 이라고 합니다.

UML specification 문서에도 Opaque Behavior 에 대해서 자세히 설명을 하고 있습니다.

현실적으로 이러한 과정은 피할 수 없습니다. 왜냐하면 Java SE 5, EE6, ME7 에 이미 유용한

class/interface library 가 너무나 많아서 굳이 개발자가 다시 개발을 할 필요는 없습니다. 그러니

코딩을 계속해서 즐길 필요도 있고, Java APIs Library 를 계속해서 연구도 해야만 합니다. 하지만

MBD 를 이용하면 소프트웨어 엔지니어들의 개발 프로세스를 상당히 향상 시켜 주는 것은

확실합니다.

4 구글에서 검색을 해보시면 원본을 찾을 수 있으니, 꼭 읽어 보시기 바랍니다. 5 Standard edition 6 Enterprise edition 7 Mobile edition

13

2 Meta structure 1

우리는 C++/Java 를 사용하면서 전혀 메타구조에 대해서는 접해 본적이 없습니다. UML

specification 문서를 읽어가면서, 가장 먼저 접하는 이해하기 어려운 용어(term) 중의 하나가

메타모델(meta model) 입니다. 물론 Booch, Rumbaugh, Jacobson 책에서도 볼 수 없습니다.

그리고 UML 을 소개하는 한국 내에서 출판된 책들을 다시 자세히 보시기 바랍니다. 메타구조에

대한 언급은 거의 없을 것입니다. 아래에 제시된 2-layer 메타구조를 자세히 보시기 바랍니다.

메타구조는 수학에도 이미 있고, 또한 프로그래밍 언어에도 존재합니다.

메타구조가 무엇인지 설명을 할 때 가장 흔히 사용되는 예가 언어학에 있습니다. 언어학은

기호를 연구하고 그 기호의 의미를 연구하는 학문입니다. 아래의 예를 보시면, object-level 에

한국어 문장, “강아지들이 공을 가지고 놀고 있습니다” 가 놓여 있습니다. 그리고 meta-level 에서

주어 ‘강아지들이’에 대해서 설명을 하고 있습니다.

Meta-level : 한글에서 주어 ‘강아지들이’는 반드시 문장의 시작 부분에 나타나야 한다.

Object-level : 강아지들이 공을 가지고 놀고 있습니다.

한글로 작성된 문장을 한글로 설명을 하고 있습니다. Meta level 에서 한국어를 사용해서

한국어의 문법을 설명하고 있습니다. 물론 영어를 가지고도 한국어 문장을 설명할 수 도

있습니다. 이게 언어학에서 나타나는 메타 구조의 예입니다. 저자의 경험으로는 언어학자들은

Modelling languages:

UML / SysML

2 Layer meta structure Notations

Semantics

??

meta-level

Programming languages:

Java, C++

Notations

Semantics

Mathematical logic

mapping

Mathematics

Formal system

Semantics

Mathematical logic

Notations

Textual languages graphical languages

Is this a formal system ?

object-level

14

메타구조라는 표현을 쓰지 않습니다. 단지 인공지능을 연구하는 엔지니어들이 인간의 언어를

분석하기 위해서 메타구조라는 표현을 쓰고 있습니다.

다음은 Java 언어를 가지고 메타구조를 설명해 보겠습니다.

Meta-level : for(초기화식 ; 조건식 ; 반복식) { 문장 } - 조건식이 true 일 때까지 문장을 반복 실행

Object-level : for ( int i=0 ; I < 10 ; i++)

{ System.out.print( i ) ; }

Object-level 에 for-loop 문장을 적어 놓았습니다. 그리고 meta-level 에는 for-loop 에 대해서

한국어로 설명을 해 놓았습니다. 여기서 많은 분들이 질문을 할 것 같습니다. Java 언어의

컴파일러를 디자인 하는 미국의 엔지니어들도 위의 예처럼 영어로 meta-level 을 표현을 해서

컴파일러를 만들까요? 분명히 아닙니다. 위의 표현은 단지 Java 를 설명하는 문법의 일부분일

뿐입니다.

다른 예를 더 들어 보겠습니다.

Object-level : 공을 강아지들이 가지고 놀고 있습니다.

Object-level : for ( i < 10 ; int i=0 ; i++)

{ System.out.print( i ) ; }

첫번째 예에서 주어와 목적어를 바뀌어 놓았습니다. 하지만 우리가 이해하는 데는 아무 문제가

없습니다. 두번째 예에서는 어떤 결과가 일어날까요? 당연히 컴파일러는 에러 메세지를 주고

컴퓨터는 더 이상 실행을 하지 않습니다. 여기서 분명히 자연언어와 인공언어의 차이점을

발견하게 됩니다. 자연언어에서는 object level 에서 문장을 구성할때, meta level 에서 설명이 된

데로 하지 않아도, 때때로 의미를 전달하는데는 문제가 없다는 것을 알게 되었습니다. 하지만

인공언어에서는 반드시 meta level 에서 지시된 데로 문장을 구성해야만 합니다. 그 이유는

프로그램 언어에 대해서 meta level 에서 이루어지는 설명은 반드시 formal system 이어야 하기

때문입니다. 더 구체적인 내용은 제 3 장 Formal system 에서 자세히 설명을 하도록 하겠습니다.

지금부터는 메타구조가 수학과 컴퓨터 사이언스에 왜 등장하게 되었는지 설명을 하고자

합니다. 우리 모두 잘 알고 있는 어린이 도서 ‘이상한 나라의 엘리스(Alice in Wonderland)’ 는

19 세기 후반에 영국의 수학자 루이스 캐롤(Lewis Carroll)에 의해서 쓰여 졌습니다. 수학자가

어린이 도서를 썻다는 것이 의아스러울 것입니다. 루이스 캐롤이 왜 이 책을 쓰게 됐을까

궁금하지 않나요? 루이스 캐롤은 수학 내부에서 이상한 일이 일어나고 있는 것을 보았고,

그것을 재미있게 책으로 만들어 낸 것입니다. 예를 들어서 엘리스는 도망을 치다가 아주 작은

문을 만나게 됩니다. 문이 너무나 작아서 통과 할 수 없게 되자 울게 됩니다. 너무 많이

15

울었습니다. 그러던 와중에 그녀 옆의 테이블에 놓여 있는 작은 약병(Drink me)을 보고 마시게

됩니다. 약병을 마신 후 그녀의 몸은 너무 작아져서 그녀가 흘린 눈물의 호수에 빠지게 되어

허우적거리게 됩니다. 엘리스의 눈물은 엘리스 몸의 일부분입니다. 하지만 엘리스의 몸이 너무

작아져서 엘리스가 눈물속에 빠져들게 됩니다. 이 예의 핵심은 전체와 부분이 혼란이 오고

있다는 것입니다.

19 세기 후반과 20 세기 초반에

유럽에서는 수학에 커다란 혼란이

일어나고 있었습니다. 수학에서 가장

중요한 것은 consistency (일관성) 입니다.

수학에서 명제(proposition or mathematical

statement) 는 반드시 참(true) 이거나

거짓(false) 이어야 합니다. 동시에

참이거나 거짓이 될 수는 없습니다. 또한

지금, 하나의 명제를 참이라고 증명을

하면 영원히 참 이어야만 합니다. 오랜

시간이 지난 후에 참과 거짓이 바뀔 수도

있는 명제는 수학에서 다루지 않습니다. 하지만 이러한 수학의 세계에서, 그 중에서도 가장

중요한 집합론(Set theory)과 대수학(Abstract algebra)에서 Inconsistency (비일관적) 가 발생하게

됩니다. 즉, 어떤 명제가 처음에는 참이었으나, 나중에 거짓이 되는 모순(contradiction)이

발생하게 되는 것입니다. 20 세기 초반, 네델란드 화가인 에셔( M.C.Escher8) 는 이러한 혼란을

그림으로 표현을 했습니다.

8 http://www.mcescher.com/

16

물은 위에서 아래로 흘러

내립니다. 하지만 그림을

자세히 보시면 폭포의

시작 부분과 끝부분이

같은 층인 것을 알게

됩니다. 흘러내린 물이

마치 거꾸로 올라가고

있는 듯한 느낌입니다.

현실속에서는 있을 수

없는 일들 입니다.

에셔의 홈페이지를

가시면 더 많은 이상한

그림들을 보실 수 있으니

즐겨 보시기 바랍니다.

이러한 일들이 일어나게

만든 장본인은 독일의

수학자 칸토르(Georg

Cantor) 입니다. 19 세기

후반 수학에 무한집합론

(infinite set theory)을

갖고 와서 많은 수학자들을 괴롭게 만듭니다. 우리의 상식으로 정수(integers)는

자연수(naturals) 보다 더 큰 집합입니다. 하지만 칸토르의 무한 집합론에 의하면 두 집합은 같은

크기의 집합입니다. 정수를 담은 그릇과 자연수를 담은 그릇에서 우리는 각각 하나의 숫자를

꺼내고, 일대일 대응을 통해서 나열을 할 수 있습니다. 이러한 일대일 대응을 더 이상 할 수 없을

때, 즉 한쪽의 그릇이 비워졌기에 우리는 어느 집합이 더 큰 지 결정을 할 수 있는 것입니다.

하지만 두 집합이 무한대라고 가정을 하면 이러한 일대일 대응은 계속되기 때문에 두 집합을

비교하는 것은 불가능합니다.

이러한 집합론의 혼란으로 인해서 그 위의 세워지는 대수학(abstract algebra)도 흔들리게 되고,

수학의 뿌리가 흔들리는 너무나 심각한 상황이었다고 합니다. 이러한 일련의 수학의 혼돈에서

17

수학자들이 사용한 것이 수리논리학(mathematical logic) 입니다. 당시 수학자들은

수리논리학을 이용해서 무한집합론으로 인해서 생긴 수학의 근본 적인 문제를 해결하고자

했던 것입니다, 즉 혼돈을 해결하기 위해서 수학의 윗부분(meta level)에서 수리논리학을

이용해서 수학(object level)을 다시 해석하고자 노력했던 것입니다. 메타구조가 수학에

처음으로 등장하게 되는 것입니다.

수리논리학에서 가장 기본이 되는 이론은 명제논리(Propositional logic)와 술어논리(Predicate

calculus) 입니다. 우리는 이미 고등학교때 수학시간에 명제논리의 아주 일부분을 배웠습니다.

아리스토텔레스(Aristotle)에 의해서 시작된 고전논리(classical logic)와는 아주 다릅니다.

아리스토텔리스 이후 논리학은 거의 2000 년 동안 많은 발전이 없었다고 합니다. 하지만

칸토르의 무한집합론으로 인해서 논리학은 다시 큰 발전을 하게 됩니다. 이렇게 새롭게 시작한

20 세기의 논리학을 수리논리학(mathematical logic) 이라고 부르는 것입니다. 하지만

아리스토텔레스의 그늘에서는 벗어나지 못했다고 합니다. 왜냐하면 수리 논리학도 연역적

사고(deductive reasoning)와 귀납적 사고(inductive reasoning)를 바탕으로 하기 때문입니다.

수학에서 필요로 하는 연역적 사고는 아주 간단합니다. 명제의 증명과정에서 왜 그렇게 사고를

진행하고 있는지, 정확히 이유를 밝히는 것입니다. 부록 A 에 삼각함수(trigonometric)와

관련해서 자주 사용되는 정리(theorem)를 적어 보았습니다. 각각의 스텝마다 이유가 적혀

있는 것을 꼭 확인해 보시기 바랍니다. 수학적 귀납법은 이 곳에 적지 않겠습니다, 왜냐하면

수리 논리학에 쓰이지 않기 때문입니다. 위키페디아에 가셔서 잠시 개념이 무엇인지 확인만

해보세요. 대신, 수리 논리학에는 귀납적 사고가 약간 변형된 너무 나도 중요한 개념이

등장합니다.

Structural recursion / structural induction

한국말로 이 두단어를 재귀적 귀납법이라고 부르기도 하지만, 저자는 영어를 사용하도록

하겠습니다. 이 두 단어는 마치 동전의 양면과도 같은 관계입니다. 또한 컴퓨터의 탄생을

알리는 중요한 계산 가능성 이론(computability)의 근간이 되는 개념입니다. 또한 현재 우리가

사용하는 모든 프로그래밍 언어가 이 개념을 가지고 만들어진 것입니다. 당연히 UML 과도 깊은

관련이 있습니다.

이러한 수학의 현대 역사와 수리논리학을 우리말로 이미 20-30 년 전에 한국에서 출판을 하신

두 분의 교수님 9이 계십니다.

9 이 두 분은 모두 오래전에 작고 하셨습니다. 따라서 두 권의 책도 아마 절판이 되어있을 것입니다. 서울

서초동에 있는 중앙 도서관에 가시면 이 책들을 찾으실 수 있습니다. 저자도 오래 전에 그곳에 가서 책을

통 채로 복사를 한 기억이 납니다.

18

집합론과 수학(현대 수학의 철학적 배경), 수학자 김용운,

현대 논리로의 길, 수학자 신홍철

많은 수학자들 조차도 수학의 현대 역사와 수리논리학에 대해서 잘 모릅니다. 그러니 여러

분들이 많이 걱정하지 않으셔도 됩니다. 하지만 프로그래밍 언어와 모델링 언어를 깊이 더

이해하고 싶으신 분들에게는 강력히 추천하는 책들입니다. 저자는 영국에서 컴퓨터 언어를

전공하는 많은 대학원 생들이 이러한 책들을 고등학교때부터 교양서적으로 이미 읽어 본 것을

알고 많이 놀란 경험이 있습니다.

다음 두 권의 책도 저자가 강력히 권하는 책입니다. 다행히 한국어로도 번역이 되어 있습니다.

꼭 원서와 함께 보시기 바랍니다.

Godel, Escher, Bach, written by Douglas Hofstadter

괴델, 에셔, 바흐 (번역본, 상/하)

Godel’s proof, written by Ernest Nagel and James Newman

괴델의 증명(번역본)

위 네 권의 책을 간략히 요약해 보겠습니다. 무한집합론으로 인해서 생긴 수학의 혼란을

극복하기 위해서 노력했던 당시의 수학자들 중에서 우리가 관심있게 봐야 될 수학자는, 20 세기

초반 최고의 독일 수학자 힐버트(David Hilbert) 입니다. 그는 공리론(Axiomatic system)을 제안

했습니다. 그는 공리(axiom)를 바탕으로 해서 어떠한 수학적인 명제도 증명을 할 수 있는

기계를 만들고자 했습니다. 즉, 이 기계가 존재한다면, 무한 집합론으로부터 만들어진 어떠한

명제도 inconsistency 없이 증명을 할 수 있을 것이라고 믿었습니다. 하지만 그의 꿈은 20 대

초반의 젊은 오스트리아 수학자 괴델(Kurt Gödel)에 의해서 무너지게 됩니다.

이 증명이 그 유명한 괴델의 불완전성정리(Incompleteness Theorem) 입니다. 이 증명이

유명하게 된 이유는, 앞으로 어느 수학자가 어떤 가설을 세워서 노력을 한다고 할지라도,

무한집합론으로 인해서 생긴 수학의 혼란을 막을 수 없다는 것을 보여 주었기 때문입니다.

우리 인간이 집합론에서 생기는 모든 명제를 증명할 수 없다는 것입니다. 다시 말해서

집합론에는 수학자가 증명을 할 수 없는, 즉 inconsistency 를 만들게 하는 명제가 반드시

존재한다는 것입니다. 어느 철학자는 우리 인간이 절대로 신이 될 수 없는 이유를 증명해

주었다고도 합니다. 문자 기호를 사용해서 생각을 하는 우리 인간의 사고에 대한 근본적인

한계를 증명해 보여 준 것이기 때문입니다.

19

그 이후로 수리논리학을 사용해서 인간의 사고 능력의 한계에 대한 연구가 급속도록

이루어지면서, 계산 가능성(Computability) 에 대한 이론이 등장하게 되는 것입니다. 그리고 2 차

세계 대전 말기에 영국 수학자 튜링(Alan Turing)에 의해서 독일군의 암호를 풀기 위해서

만들어진 튜링머신(Turing machine)이 등장하게 되는 것입니다. 이것은 컴퓨터 시대의 시작을

알리는 위대한 발명품입니다. 많은 독자들이 컴퓨터가 2 차 세계대전의 부산물로 생각하는

분들이 많이 있을 것입니다. 하지만 그 시작은 칸토르에서 부터 시작된 것입니다.

특히 위의 책 중에서 ‘괴델 에셔 바흐’를 읽으시면 집합론에서 일어나는 혼란이 오랫동안 우리

인류의 삶 속에 존재하고 있었다는 것을 알게 됩니다. 또한 제목에서 보듯이 바흐의 음악

속에서도 에셔의 그림에서 보았던 이상한 일들이 일어나고 있다고 합니다. 음악 악보를 볼 줄

모르는 저자로서는 많이 아쉬운 부분입니다. 음악을 아시는 분들은 이 책을 보면서 수학에서

느끼는 혼란을 음악에서도 즐겨 보시기 바랍니다. 여기서 강조하고 싶은 것은, 이러한 혼란이

결국 컴퓨터의 탄생과 직접적인 관련이 있다는 것입니다. 즉 수리논리학의 발전을 통해서

컴퓨터의 계산 가능성을 알게 된 것입니다. 컴퓨터의 기초 학문은 수리 논리학이라는 것을 다시

한번 강조 드리고 싶습니다. 유럽과 미국에서 컴퓨터 학과에서는 아주 중요한 과목으로

가르치고 있습니다.

위의 책들을 읽으면서 다음의 단어들에 많은 주의를 기울이시면서 작은 요약노트를 만들어

보세요. 아마 OMG 에 공개되어 있는 모델링 언어의 문서를 읽어 나가는데 많은 도움이 되실

겁니다.

Classical logic, Aristotle,

Cantor, infinite set theory, naïve set theory, axiomatic set theory

Russell paradox,

Inconsistency,

propositional logic, predicate calculus

Hilbert’s axiom system,

Intuitionism,

Godel incompleteness,

Computability, Recursion

Turing machine,

Deductive / inductive reasoning

Structutural recursion / structural induction

Well-formedness rules

20

Axiom / Definition / Lemma / Theorem

Proof by induction/recursion

Type system

First order / second-order logic

Consistency / Completeness Correctness

Inference rules / context

3 Formal system

독자분들 중에 Java/C++ 가 어떻게 만들어 졌는지 고민을 해 보신적이 있는지 궁금합니다.

컴파일러는 어떤 과정을 통해서 만들어 지게 될까? 컴파일러를 디자인 하기 위해서는 무엇을

공부해야 될까? 이미 위에서 언급을 했듯이 프로그래밍 언어를 디자인 하기 위해서는

수리논리학(mathematical logic) 에 대한 전문 지식을 필요로 합니다. 하지만 한국의

전산과에서는 수리 논리학이 관심의 대상이 아닙니다. 프로그래밍 언어를 배운다는 것은 단지

문법(syntax)을 익히는 것뿐입니다. 어떻게 만들어지는지는 관심의 대상이 아닙니다. 단지

컴파일러를 제작하는 몇몇의 천재만 알면 된다고 우리는 이제까지 스스로에게 변명을 하고

있었습니다. 기초과학이 부족한 한국의 현실과도 연결이 되는 문제 입니다. 당장에

여러분들에게 현실로 다가온 문제는, 프로그램 언어를 배울때 하던 방식으로, 똑 같은 방법으로

UML 에 접근을 하고 있다는 것입니다.

지금부터는 formal system 에 대해서 간략히 설명을 하고자 합니다. formal system 을 알기 위한

가장 좋은 방법은 수리논리학을 학습하는 것입니다. 이 책의 두번째 시리즈에서 수리 논리학을

자세히 설명할 예정이지만, 과연 한글로 설명이 가능할 지 많이 두려운 부분입니다. 저자는 이

책에서, 수리논리학을 컴퓨터에 쓰이는 언어를 개발하는 관점에서 계속 설명을 하고 있습니다.

하지만 수리논리학은 현재 computer science 의 모든 분야에 적용이 되는 수학 입니다.

저자는 여기서 C++/Java 컴파일러와 Rational Software Architect 가 어떻게 만들어 지는지, 그

과정을 간략히 비교를 통해서 설명을 하고자 합니다. 여러분들이 여기에서 formal system 이

무엇인지 정확이는 알 수 없어도, 왜 필요한지 중요한 핵심은 잡을 수 있을 것이라고 생각이

듭니다.

21

object level – notation 을 나타내는 부분

C++/Java 컴파일러 Rational Software Architect

C++/Java 에 어떠한 문자기호(textual

symbol)를 사용할지 결정하는 단계입니다.

각각의 문자 기호가 무엇을 뜻하는지는 알 수

없습니다. Class, Interface, For, while, static, private, protect, int, float, extend,….

UML 에 등장하는 모든 도형 기호(graphical

symbol)를 결정하는 단계입니다. 마찬가지로

무엇을 뜻하는지는 알 수 없습니다.

meta level – Semantics 를 정의하는 부분

BNF syntax 를 통해서 위에서 만들어진

기호들을 어떠한 순서로 조합을 할지

결정을 합니다.

이 책의 부록 B 부분에 BNF syntax 의 예를

보실 수 있습니다.

이러한 조합의 과정을 structural

recursion 이라고 합니다.

이러한 Structural recursion 의 과정을

거쳐서 프로그램이 만들어 지기에

C++/Java 는 concrete syntax 를 가지고

있다고 합니다.

메타모델(meta model)을 기준으로 해서

위에서 정의된 기호들을 조합 합니다.

UML specification 문서에 등장하는 모든

class diagram 이 메타모델입니다. 예를

든다면, Figure7.1 Root, Figure 7.3 Templates, Figure7.5 Namespaces, ……..

이러한 조합의 과정을 structural recursion

으로 나타낼 수 없기에, UML 은 abstract

syntax 를 가지고 있다고 합니다.

메타모델에 등장하는 클래스(class)를

나타내는 직사각형의 도형을 meta

class 라고 부릅니다.

이러한 meta class 는 클래스와

마찬가지로 attribute, method, association

relationship, inheritance relationship 을

가지고 있습니다. 하지만 dependency

relationship 은 가질 수 없습니다.

22

컴파일러가 가장 먼저 하는 일은 코딩된

프로그램이 BNF syntax 에 제시된 조합을

따르고 있는지 체크를 하는 것입니다.

제 2.1 절 meta structure 1 에서 for-loop

예를 들어 보았습니다. 두번째 예에서

컴파일어가 에러 메세지를 보여주는

이유입니다.

Rational Software Architect 는 사용자들이

메타모델에 주어진 데로 도형을 그리고

있는지 실시간으로 체크를 합니다.

따라서, 메타모델에 맞지 않는 조합을

선택하면 아예 선택된 도형을 사용하지

못하도록 합니다.

이제부터는 만들어낸 문자의 조합이

무엇을 뜻하는지 의미를 불어 넣어

주어야 합니다.

문자의 조합이 나타내는 뜻을

수리논리학을 통해서 표현을 합니다. 즉

참과 거짓이 분명한 수학적인 명제를

기술하는 것입니다. 이러한 각각의

명제를 Definition, Lemma, Theorem

이라고 부르고, 이러한 명제들은 연역적

사고에 의해서 서로 연결이 됩니다.

다음은 기술된 명제를 증명하는 과정이

필요합니다. 이때 사용되는 방법이

structural induction 입니다. 앞에서 이미

설명 드렸듯이 structural recursion /

structural induction 은 동전의 양면과 같은

존재 입니다, 즉 같은 개념입니다. 하지만

프로그램 코드를 조합하는 과정에서는

structural recursion 이라고 부르고, 조합된

코드를 증명하고자 할 때는 structural

induction 이라고 부르는 것입니다.

도형의 조합이 무엇을 뜻하는지 대부분

자연언어인 영어를 사용해서 기술을 하고

있습니다.

따라서 영어로 작성된 semantics 를

해석하는데 있어서, 읽는 사람마다

조금씩 다르게 해석할 수 있는 위험이

존재합니다.

이러한 위험을 줄이기 위해서 만들어진

것이 Object Constraint Language (OCR)

입니다. 이것은 C++/Java 와 같은 문자

언어입니다.

각각의 도형의 조합이 무엇을 뜻하는지

영어를 사용해서 설명도 하고, OCR 을

통해서 기술을 하기도 합니다. 하지만

증명의 과정은 없습니다.

이렇게 OCR 로 작성된 문장을 UML

specification 에서는 Constraints 라고

부릅니다.

Formal system Non formal system 하지만 formal system 에 가까이 가도록

노력을 하고 있기에, UML specification

에서는 normative 라는 표현을 쓰고

있습니다.

23

컴파일러의 개발자들은 자신들이 정의한

BNF syntax 와 수학적인 방법으로 기술한

semantics 를 보통의 사용자들도 이해할

수 있도록 쉬운 영어를 써서 다시 기술을

합니다. 이것이 여러분이 이제까지

배우고 익혔던 C++/Java 문법책입니다.

위에서 설명했듯이 UML semantics 는

대부분 영어로 작성되어 있습니다. 굳이

UML 을 설명한 책을 따로 사서 읽을

필요는 없습니다.

메타구조에 대한 정확한 이해만 있으면

누구나 읽고 해석할 수 있습니다.

영어로 작성된 semantics 를 누군가가

다시 가공을 해서 책을 쓰고 출판을 하고

있습니다. 해석을 다르게 할 위험이

존재하는 것입니다. 이 책의 서두

부분에서 언급된 두 권의 Booch,

Rumbaugh, Jacobson 책이 대표적인

예입니다.

여러분들은 OCR 을 꼭 정확히 이해해야 만

하고, 또한 모델링 과정에서 자주

사용해야만 합니다. UML 에 제시된

도형만을 사용해서 우리의 업무를

분석/설계 하면 프로젝트 팀의 구성원

간에 이해와 해석을 다르게 할 수 있는

위험이 존재합니다. 따라서 OCR 을

통해서 도형과 함께 문자를 가지고

정확히 기술을 하는 것입니다.

여러분들이 BNF syntax 와

수리논리학으로 작성된 semantics 를

이해할 필요는 없습니다. 여러분들이

읽고 계신 문법책만으로도 C++/Java 를

사용하는 데는 아무 문제가 없습니다.

UML specification 에서 제시된 수십개의

메타모델을 직접 이해하려고 노력하는

것이 UML 을 정복하는 가장 좋은

길입니다.

또한 Object constraint language 가

무엇인지 알기 위해 도전해 보시기

바랍니다. OCR 은 거의 functional

programming language 와 비슷합니다.

OMG 에 등록이 되어 있는 다음의 OCR specification 문서를 한번 열어 보시기 바랍니다.

Object constraint language version 2.4

24

OCR 을 만든 개발자들이 아주 재미있게 문서를 작성한 것을 볼 수 있습니다. OCR 은

문자언어(textual language)입니다. 즉 concrete syntax 를 가지고 있습니다. 하지만 abstract

syntax 를 사용해서 OCR 을 설명하고자 하고 있습니다. 수리논리학을 모르는 보통의

사용자들을 위한 배려 입니다. 하지만 OCR specification 문서의 부록(appendix) A. Semantics

부분을 보시면 수리논리학으로 설명된 부분을 보실 수 있습니다. 여러분들이 직접 이해하지

않아도 됩니다. 단지 여러분이 하셔야 될일은 OCR specification 문서에서 제 7 장 OCR Language

Description 은 반드시 자세히 읽어 보셔야 합니다. 이 정도면 OCR 을 이해하고 사용하는 데는

아무 문제가 없습니다. 이해가 어려우시면 아래에 제시된 책을 읽어보시는 것도 많은 도움이 될

겁니다.

The Object Constraint Language: Getting Your Models Ready for MDA, by Jos Warmer

여러분이 OCR 을 이해하는데 어려움이 있다면, 그 이유는 OCR 이 functional programming

language 가 가지고 있는 여러 특징을 가지고 있기 때문입니다. Functional programming 언어의

대표적인 예가 Haskell 입니다. 아래에 또 한권의 책을 소개해 드립니다. 다행히 한국어로

번역이 되어 있습니다.

Programming in Haskell, by Graham Hutton

하스켈로 배우는 프로그래밍(번역본)

Functional programming 언어의 가장 큰 특징은 변수(variable)의 개념이 없습니다. 예를 든다면,

Int a;

a = a + 3;

즉, 값을 변수에 할당하는 assignment statement 가 존재하지 않습니다. C++/Java 에 익숙한

프로그래머들은 많은 혼란을 겪게 됩니다. 하지만 반대로 side effects 가 없다는 큰 장점을

가지고 있는 것입니다. 우리가 C++/Java 를 사용하면서 가장 많은 시간을 허비하는 과정이

logical bug 를 잡아내는 것입니다. 이 버그가 생기는 주된 이유가 assignment statement 입니다.

변수에 값을 할당하면서 우리는 많은 실수를 저지릅니다. 하지만 잘 보이지 않는 실수 입니다.

Functional programming 언어는 변수에 대한 개념이 없기에 logical bug 를 걱정을 할 필요는 아예

없습니다.

그 다음으로 functional programming 에 등장하는 중요한 개념은 lambda notation 입니다. 최근

Java 문법에도 lambda notation 이 등장을 했습니다. 하지만, 이것은 전혀 새로운 것이 아닙니다.

우리가 수학에서 이미 너무 많이 쓰던 표현입니다.

25

mathematics Functional programming Function abstraction

(함수정의) 𝒇𝒇(𝒙𝒙) = 𝒙𝒙𝟐𝟐 + 𝟑𝟑 f := fun(x:int) -> x^2 + 3

Function application 𝒇𝒇(𝟐𝟐) = 𝟐𝟐𝟐𝟐 + 𝟑𝟑 = 𝟕𝟕 f 2 returns 7

저자가 여기서 다시 강조 하고 싶은 것은 C++/Java 또는 OCR 같은 문자 언어를 배울 때는,

이것들을 어떻게 사용해야 되는지 문법을 익히는 것만으로도 충분하지만, UML 은 다르다는

것입니다. UML specification 에 제시된 semantics, 즉 메타모델을 직접 이해하는 것이 UML 을

가장 빨리 정확히 이해할 수 있는 지름길입니다. UML semantics 에는 수학적인 표현이

없습니다. OCR 만 알면 누구나 이해할 수 있습니다.

26

4 Modelling language

Paradigms Reasoning skills(생각하는 방법) Languages Imperative 순차, 반복, 선택 C, Matlab, …

Object-oriented UML, SysML C++, Java, … Functional, logical and Declarative

Function abstraction, function application And ,or, exclusive, all, existence, ….

Haskell, OCaml, OCR …

독자분들과 제가 여기서 만난 이유는 객체지향 모델링언어, 즉 UML 이 무엇인지 알기 위해서

입니다. 제가 여러분들에게 객체지향 패러다임이 다른 종류의 프로그램 언어와 무엇이 다른지

물어본다면, 여러분들은 어떻게 대답을 하시겠습니까? 아마 많은 분들이 난감해 하실 겁니다.

왜냐하면 우리가 오직 대학교에서 배운 것은 객체지향 언어 C++/Java 뿐이기 때문입니다. 예를

들어 여러 종류의 고기를 먹어봐야 소고기가 다른 고기와 무엇이 다른 지 우리가 설명을 할 수

있지 않을까요? 프로그래밍 언어의 세계도 마찬가지라고 생각이 듭니다. 여러 종류의

프로그램 언어를 사용해 보고 각각의 언어는 어떠한 reasoning skills 을 필요로 하는지 경험을

해봐야, 왜 우리가 UML 을 필요로 하는지 더 확실한 이유를 알 수 있지 않을까 합니다. 위의

표는 컴퓨터에 사용되는 대표적인 몇가지 언어를 나열한 것입니다.

우리가 C 언어를 사용해서 어떻게 프로그램을 만들었는지 잠시 되돌아보겠습니다. 아래에

제시된 Reasoning skill 을 이용해서, 우리의 도메인 영역을 분석하고, 다음은 플로우차트(flow-

chart) 를 그려서 바로 코딩을 할 수 있었습니다.

순차(sequence) / 반복(for-loop statement) / 선택(if-then-else statement)

이러한 reasoning skill 은 imperative 프로그래밍 언어를 사용할때 필요로 하는 방법들입니다.

하지만 저자가 우려하는 것은 한국에서 소프트웨어 엔지니어들을 교육 시킬 때 이러한 방법을

주로해서 아직도 객체지향 프로그래밍 언어를 가르치고 있다는 것입니다.

왜 UML 을 배워야 하는지, 그 이유를 말하기 위해서 아래의 그림을 다시 가지고 왔습니다.

우리는 이제까지 UML 을 객체지향 프로그램을 위한 모델링 언어로 알고 있었습니다. 더 정확히

설명하면, UML 은 우리에게 생각하는 방법을 제시하는 reasoning skill 입니다.

27

분명히 많은 독자분들이 반박을 하실 것입니다. 프로젝트의 종류에 따라서는 업무를 보고 바로

자바 클래스를 디자인 하는 것도 충분히 가능하다고 말씀 하실 수 있습니다. 하지만 현재의

기업형 (enterprise level) 소프트웨어의 개발을 위해서는 적절하지 않습니다. 현재, 소프트웨어

개발에 있어서, 가장 큰 핵심은 개발팀에 있는 구성원 간의 팀워크입니다. 당연히 팀워크의

가장 큰 핵심은 커뮤니케이션 입니다. 이러한 커뮤니게이션을 가능하게 하는 것은 모델링언어

입니다. 결론적으로 모델링 언어 UML 은 객체지향 프로그램 개발을 위해서 소프트웨어

엔지니어들이 가져야 될 reasoning skill 일 뿐만 아니라, 팀 구성원 간의 커뮤니케이션을 위한

중요한 수단 입니다. 하지만, 이러한 모델링 언어가 갖추어야 될 중요한 조건이 있습니다.

모델링과 코딩 과정이 자동으로 연결(mapping)이 되어 있어야만 한다는 것입니다.

예를 들어서, Java 를 사용하는 개발자들 중에서 interface 를 직접 정의해서 사용하신 분이 몇

명이나 될까요? 거의 없다는 것이 저자의 경험입니다. 그 이유는 간단합니다. Interface 는

모델링 단계에서 더 많이 사용되는 개념입니다. Composite structure diagram / component

diagram 을 그릴때 반드시 사용되어야만 하는 개념입니다. 한가지 더 예를 든다면, 자바언어에

generic programming 문법이 있습니다. 아마도 이것 또한 여러분들이 거의 쓰지 않습니다.

하지만, 이것 역시 모델링 단계에 더 어울리는 개념입니다. class diagram 을 그릴

때에 parameterised class 라고 부르는 옵션이 있습니다. 즉 모델링 단계에서 parameterized class

를 사용하면, 이것이 자바 언어의 generic programming 문법으로 자동으로 코드가 생성되는

것입니다.

Modelling languages:

UML / SysML

2 Layer meta structure Notations

Semantics

??

meta-level

Programming languages:

Java, C++

Notations

Semantics

Mathematical logic

mapping

Mathematics

Formal system

Semantics

Mathematical logic

Notations

Textual languages graphical languages

Is this a formal system ?

object-level

28

이러한 연결관계(mapping process)가 MOF(Meta Object Facility)에 자세히 설명되어 있습니다.

쉽게 말하면 UML 모델에 나타내는 다양한 도형을 XML10 언어로 변형을 시킵니다. XML

태그(tag)안에 모델링에 대한 정보를 기록하는 것입니다. 이러한 저장된 정보를 바탕으로

프로그래머가 원하는 객체지향 언어로 자동으로 코드를생성시켜 줍니다. 이러한 모든

아이디어를 가능하게 하는 것은 UML 이 formal system 에 가깝기 때문입니다. 이미 전에

언급했듯이 UML 은 formal system 은 아닙니다. UML specification 문서에도 formal system

이라는 용어는 쓰지 않고 있습니다. 대신에 ‘normative’ 라는 용어를 쓰고 있습니다. UML

specification 문서를 만든 엔지니어들의 고민을 엿볼 수 있는 부분입니다. 수학과 컴퓨터

사이언스 에서는 전혀 볼 수 없는 새로운 단어입니다. 이러한 모델링 언어의 진화과정을 자세히

적은 책이 있습니다.

Applied Meta modelling: A Foundation for Language Driven Development (Third Edition), Tony Clark11

독자분들께 처음 두 장 만을 꼭 읽어 보시라고 권해 드리고 싶습니다. 더 관심이 있으신 분은

계속해서 읽으셔도 됩니다. 이 책은 제목에서도 볼 수 있듯이 Language driven development 를

설명하고 있습니다. 위 책에서 저자의 의도는 Model driven(based) development 를 넘어서

새로운 아이디어를 찾으려고 하고 있습니다. 각자의 도메인 지식을 모델링해서 새로운

프로그래밍 언어를 자동으로 생성하고 싶어합니다. 즉 지식을 모델링 해서 domain specific

language 를 만들자는 것입니다. 기존의 컴파일러를 없애 겠다는 의도입니다. 이제 쉽게 누구나

자기만의 프로그래밍 언어를 만들 수 있다는 새로운 연구입니다. 조만간 더 발전된 모습을 보일

테고, 곧 OMG 에도 등록이 될 것 같습니다. 이렇게 모델링 언어는 현재 계속해서 발전하고

있습니다.

자바언어의 semantics 를 몰라도 이제까지 자바를 사용하는 데는 아무 문제 없었습니다. 심지어

수학자들도 수학의 메타구조에 대해서 잘 모릅니다. 하지만 모델링 언어는 다르다는 것이

저자의 경험입니다. Rational software architect 를 사용해서 모델링을 하는 과정에서 가장

자주하는 작업은 Property view 에 나오는 여러 조건들을 조절하는 것입니다. 하지만, Property

view 에 보이는 이러한 조건들은 UML specification 문서에 보이는 메타모델에 관한 것입니다.

즉, meta class 가 가지고 있는 attribute, method, association relationship, inheritance relationship

에 대한 것들입니다. UML specification 문서를 정확히 이해하지 않고 서는 도저히 Property view

를 정확히 콘트롤 할 수 없습니다.

10 Extended mark-up language 11 홈 페이지를 방문하셔서 밑으로 조금 내려가시면 이 책을 보실 수 있을 것입니다

29

마지막으로 여러분들이

UML 을 배우기 위해서

여러 책을 접하면서 자주

만나는 그림이 있습니다.

옆의 그림입니다. 아주

잘못된 것임을 꼭 기억해

두셨으면 합니다. 그

이유는 아주 간단 합니다.

첫째, meta level / object

level 은 서로

인스턴스(instance of)로

이루어지는 관계가

아닙니다.

둘째, 메타 구조는 오직 2-

layer 뿐입니다. 따라서,

주어진 4-layer 구조를

아래의 그림처럼 2-layer 구조로 다시 해석을 할 수 있어야만 합니다.

30

• M0/M1 구조 - 확실히 메타구조가 아닙니다. 단지 수평적인 mapping 관계입니다.

• M1/M2 구조 – UML specification 문서의 내용이고, 저자가 이 책을 통해서 설명하는

부분입니다.

meta level

object level

object level

object level meta level

meta level

No

?

Yes

meta-level

Programming languages:

Java, C++

Notations

Semantics

Mathematical logic

object-level

Modelling languages:

UML / SysML

Notations

Semantics

mapping

31

• M2/M3 구조 – 저자도 확신을 못하는 부분입니다. 그 이유는 Rational Software Architect

같은 툴을 개발해본 경험이 없기 때문입니다. 확실한 것은 저와 여러분이 굳이 알아야

될 필요는 없다는 것입니다. UML specification 문서에 meta - metamodel 이라는 용어를

써서 이러한 M2/M3 구조에 대해서 가끔씩 언급을 하고 있는 것을 볼 수 있습니다.

MOF(Meta Object Facility) 문서를 보시면 class diagram 을 이용해서 무언가를

설명하고자 하는 것을 볼 수 있기에 메타구조는 맞습니다. 하지만 이해할 필요가 없는

이유는 Rational Software Architect 를 사용하면서, 전혀 MOF 의 필요성을 느끼지

못했다는 것이 저자의 경험입니다. 이 부분에서 우리에게 도움이 되는 것이라면, UML

모델에 보이는 각각의 도형들이 어떻게 XML 코드로 전환이 되는지, 즉 XML schema

부분을 알고 있다면, 나중에 도움이 되는 개발 프로젝트가 있지 않을까 하는 것이

저자의 의견입니다. UML 툴을 개발하는 벤더들 사이에서 모델을 서로 호환할 수 있게

하기 위해서 XMI(XML Metadata Exchange) 표준을 정했을 것이고, 아마도 MOF 와 깊은

관련이 있을 것입니다.

32

5 UML 을 배우기 위한 5 개의 중요한 컨셉

5.1 Root

1) 이미 우리는 제 3.1 절 formal system 에서 object level 에서 앞으로 모델링에 사용될

도형의 형태를 결정하였습니다. 이러한 도형들에 이름을 주고 의미를 주는 것이

메타모델(meta model)입니다. 이러한 도형들이 meta level 에서 클래스를 나타내는

직사각형으로 표현이 되고 이름을 갖는 것입니다. 메타모델(meta model)에 보이는 모든

직사각형의 도형을 특히 meta class 라고 부릅니다. 왜냐하면 클래스 도형이 meta level

에 나타나기 때문입니다. 즉 UML 다이어그램에서 보여지는 모든 도형들은

메타모델에서 다음과 같은 이름을 가지면서 인식이 되는 것입니다. <<meta class>>Element, <<meta class>>Relationship, <<meta class>>DirectedRelationship, <<meta class>>Comment.

위의 Root 메타모델을 보시면, Element, Relationship, DirectedRelationship 은 모두

1

2

3

4

5

6

7 8

in UML 2.5 specification

33

이탤릭체로 적혀있습니다. 이것은 abstract 를 나타내는 것입니다. Java/C++ 문법에서

사용되는 추상적인 클래스(abstract class)와 정확히 같은 의미입니다. 우리가

자바언어에서 클래스를 추상적(abstract)으로 선언을 하면, 인스턴스(instance) 를

생성할 수 없습니다.

Root 메타모델에서 <<meta class>> Element 는

자바언어에서 Object 클래스와 똑 같은

개념입니다. 자바에서 정의가 되는 모든

클래스는 Object 클래스에서 상속된 것입니다.

하지만 Object 클래스를 가지고 인스턴스를

생성할 수는 없습니다.

Rational Software Architect 에 보이는,

comment 버튼을 제외한 모든 버튼들의 시조

조상이 되는 것이 <<meta class>>Element

입니다. 또한 <<meta class>>Element 는

abstract 이기 때문에, 이것에 대응하는 도형은

Rational Software Architect 의

팔레트(Palette)에 보이지 없습니다. 하지만

<<meta class>>Comment 는 concrete 로 정의가

되었기에 팔레트에 보입니다. <<meta

class>>Comment 는 UML 다이어그램에 추가적인 설명을 하고자 할때, 쓰이는

도구입니다.

자바에서 Object 클래스의 역할은, 앞으로 Object 클래스로 부터 상속이 되어서 정의가

될 모든 클래스들이 가지고 있어야 하는 중요한 속성(attribute)과 메소드(method)를

정의하고 있습니다. 위의 팔레트에 보이는 모든 버튼들은 <<meta class>>Element 에서

상속이 된 것입니다. 또한 concrete 로 정의가 되었기에 팔레트에 나타나는 것입니다. <<meta class>>Port <<meta class>>Part <<meta class>>Provided Interface <<meta class>>Connector ….

이러한 meta class 들은 모두 UML specification 의 여러 다른 메타모델에서 설명이 되고

있습니다. 이러한 모든 meta class 들이 가지고 있어야 될 공통된 특징들을 <<meta

comment

Class diagram 에서 보여지는 도형

34

class>>Element 에 기술하는 것입니다. 이러한 특징들이 위의 Root 메타 모델에 No 2 /

No 3 부분에 설명이 되어 있습니다.

2) 도형들이 다른 의미를 가지고 있는 도형을 포함할 수도 있다는 것입니다. 예를 들어

Component 를 나타내는 도형은 class, interface, part, port 를 포함할 수 있습니다. 또한

class 를 나타내는 직사각형이 attribute 와 methods 를 소유하는 것도 좋은 예가 될 수

있습니다.

3) 도형들이 코멘트를 가질 수 있다는 것입니다. 우리가 모델링을 하면서 자유롭게

코멘트를 적는 것입니다. 마치 자바를 쓰면서 코딩에 부가적인 설명을 더하는 것과

같습니다.

4) <<meta class>>Relationship 은 UML 다이어그램에서 그려지는 도형들 사이의 관계를

나타냅니다. 아래의 테이블에 이러한 관계들을 6 가지 영역(category)으로 분류해

보았습니다.

<<meta class>>Relationship 은 <<meta class>>Element 에서 상속이되고, 역시나 abstract

입니다. 즉, <<meta class>>Element 는 UML 다이어그램에 나타나는 모든 도형들의 1 대

조상이라고 했듯이, <<meta class>>Relationship 은 이러한 도형들 중에서

관계(relationship)를 나타내는 도형들의 시조 조상입니다.

따라서, <<meta class>>Relationship 은

<<meta class>>Element 이 가지고 있는

모든 특징을 물려 받습니다. 예를

들어서 association relationship 은

multiplicies 와 함께 반드시 그려져야

합니다. 또한 association relationship 도

Category Function

Activity edges Represent the flow between activities

Associations Indicate that instances of one model element are connected to instances of another model element

Dependencies Indicate that a change to one model element can affect another model element

Generalizations Indicate that one model element is a specialization of another model element

Realizations Indicate that one model element provides a specification that another model element implements

Transitions Represent changes in state

Association relation

multiplicities

35

역시 comment 를 가질 수 있습니다. 위의 6 가지 영역에 해당하는 도형들을 Rational

Software Architect 에서 찾아 보겠습니다. Class diagram 에 보여지는 관계를 나타내는

도형들은 use case, deployment, collaboration, component, composite structure

다이어그램에서도 사용이 되어 집니다.

5) <<meta class>>Relationship 이 갖는 특징입니다. 즉 관계(relationship)를 만들기 위해서는

두 개 이상의 다른 도형(element) 들이 참여 해야 한다는 것입니다.

6) <<meta class>>DirectedRelationship 은 관계 중에서 방향성을 가지고 있는 관계들을

나타냅니다. 위의 그림에 유일하게 방향성을 갖지 않는 relationship 을 표시해

두었습니다. 이외의 모든 relationship 방향성이 존재 합니다.

7) <<meta class>>DirectedRelationship 이 갖는 특징입니다. 즉 방향성을 가진 관계들은

반드시 시작(source)부분과 끝(target)부분이 있다는 것입니다.

8) 하나의 comment 가 여러 도형에 쓰일 수 있다는 것입니다.

Activity diagram Class diagram

Class diagram

Class diagram Statemachine diagram

유일하게 방향성을 갖지

않은 relationship

36

5.2 Classifiers

위 그림은 Classifiers 메타모델의 일부분을 보여주고 있습니다. 꼭 UML specification 문서와 함께

보시기를 바랍니다. <<meta class>>Classifier 는 위에서 보듯이 abstract 로 정의가 되어져

있습니다. <<meta class>>Classifier 는 Rational Software Architec 에서 제공되는 다음의

다이어그램에 나타나는 모든 도형(버튼)들의 가장 중요한 조상입니다.

Class diagram Composite structure diagram Component diagam Communication Diagram

Object diagram – UML specification 문서에 표준으로 정해져 있지 않은 다이어그램입니다.

하지만 Object Constraint Language 와 함께 사용하면 너무도 유용한

다이어그램입니다.

In UML specification

37

옆의 그림은 <<meta

class>>Classifier 에서부터

가장 위의 조상인 <<meta

class>>Element 까지 추적한

그림입니다. 따라서 <<meta

class>>Classifier 는 옆의

그림에 보여지는 모든 meta

class 들의 특징을 상속받은

것입니다.

concrete 로 정의된 <<meta class>>Class 가 옆에 보입니다.

많은 분들이 이미 잘 알고 있기에 더 설명은 하지

않겠습니다. 문제는 여러분들이 class diagram 밖에 그리지

못한다는 것입니다. 여러분이 시중에 출판된 책을 읽거나

또는 강의를 참석하시면, 대부분의 설명이 class diagram 에

집중이 됩니다. 아주 기초만 배운 것입니다. 그러니 본인의

프로젝트에 UML 을 적용하려고 해도 할 수 없는

이유입니다.

이 책을 통해서 여러분들에게 자세히 설명을 해야될 부분은

<<meta class>>Class 위쪽에 있는 abstract 로 정의되어 있는

<<meta class>>EncapsulatedClassifier, <<meta class>>StructuredClassifier, <<meta class>>Classifer

들이 가지고 있는 특징들입니다. 그 이유는 아주 간단

합니다. 이제부터는여러분들이 composite structure diagram

/ component diagram 을 그릴 줄 알아야 합니다. 이 두 다이어그램을 그리는데 있어서 중요한

38

역할을 하는 컨셉이 provided interface, required interface, part, port, connector 입니다. 자바

언어에는 등장하지 않는 개념들입니다. 즉 다시 말해서 자바언어에는 composite

structure/component 를 나타내는 어떠한 문법도 존재하지 않습니다. 그렇다면, 모델링

단계에서 보이는 provided interface, required interface, part, port, connector 들이 어떻게 자바

언어로 코딩이 될지, 앞으로 우리가 많은 고민을 해야될 부분입니다.

마지막으로 위의 그림에서 더 재미있는 것은 <<meta class>>Component 가 <<meta class>>Class

에서 상속이 되어 있다는 것입니다. 객체지향 언어를 배우면서 우리가 너무도 많은 들은 것이,

클래스를 이용해서 컴포넌트를 만들어야 된다고 합니다. 하지만 자바언어에는 component 에

해당하는 문법이 존재하지 않습니다. 많은 분들이 component 에 대해서 잘못알고 있는

것입니다. 위의 그림에서 상속관계를 다시 보시면 <<meta class>>Component 는 위 쪽에 있는

네개의 meta class 들이 가지고 있는 모든 특징들을 상속받은 아주 복잡한 개념입니다.

저자의 경험으로 composite structure diagram / component diagram 을 UML specification 문서를

읽어가면서 이해하는 것은 불가능하다고 봅니다. 설명을 이해하기가 너무 어렵고, 제시된 예도

정확하지도 않습니다. 저자가 composite structure diagram / component diagram 을 이해하기

위해서 몇년을 헤메던 중에, 다음의 책을 읽고 너무도 반갑고 고마웠던 기억이 납니다.

SysML Distilled: A Brief Guide to the Systems Modeling Language, by Lenny Delligatti

SysML(System Modelling Language)은 OMG 에 정식으로 등록이 된지, 10 년도 되지 않은 새로운

모델링 언어입니다. 2000 년대 초반에 자동차, 항공기, 기차, 군사 무기… 등등의 기계(system

engineering)를 디자인하는데 UML 을 사용 했다는 것에 저자도 처음에는 많이 놀랐습니다. 그

이후로 시스템 엔지니어들이 UML 을 약간 변형시켜서 새로운 모델링 언어의 표준을 만든 것이

SysML 입니다. 정식으로 영어로 적은 표현은 다음과 같습니다.

SysML is a profile (or extension) of UML.

Profile 은 스테레오 타입(stereotype)을 모아 놓은 패키지(pacakge) 입니다. 이번장의 뒷

부분에서 stereotype 을 설명할 예정입니다. UML 다이어그램에서 가장 기본이 되는 구성원이

class 이듯이, SysML 에서 가장 기본이 되는 구성원은 block 입니다.

Block definition is a stereotype of Class which is defined in UML.

다시 말해서 UML 에서 정의된 class 를 약간 변형시켜서 정의한 것이 block 입니다. UML 에서

우리가 class / composite structure / component 를 함께 이해하기 어려운 이유는, 우리 인간의

눈에 보이는 구체적인 사물을 모델링하기도 하지만, 눈에 직접 보이지 않는 부분을 모델링 해야

하는 경우가 실제로 더 많기 때문입니다. 그래서 class diagram /composite structure diagram

/component diagram 에 등장하는 도형들을 어떻게 사용해야 될지 혼란이 오는 것입니다.

39

하지만 SysML 에서는 이러한 혼란이 생기지 않습니다. SysML 은 우리 눈에 보이는 구체적인

기계를 디자인 하는 것이기에, SysML 을 배우는데 있어서 많은 개념들이 쉽게 이해가 됩니다.

위의 책을 읽으시면서 Block definition diagram / Structural diagram 을 집중해서 보시기

바랍니다. UML 에 등장하는 part, port, required interface, provided interface, connector 의

개념들이, 어떻게 SysML 에서도 구체적으로 사용이 되는지 이해가 쉽게 설명이 되어 있습니다.

<<meta class>>Classifier 를

이해하면서, 하나 더

중요하게 짚고 넘어 가야 될

부분이 있습니다. 옆의

그림을 보시면 <<meta

class>>Association 만이

<<meta class>>Classifier 에서

상속을 받고 있습니다.

Concrete 로 선언된 5 개

각각의 relationship 들이

자바언어로 어떻게 코딩이

될지 상상해 보시기

바랍니다. 특히 association

relationship 은 <<meta

class>>Classifer 로 인해서

자바언어에서 어떤 특별한

코딩이 이루어 질지 기대가 되어 집니다.

Concrete meta classes

40

5.3 Behaviours

Activity diagram, Sequence

diagram, statemachine diagram 을

그릴때 쓰여지는 도형들은 모두

<<meta class>>Behaviour 에서

상속된 것입니다. 즉, 가장 가까운

조상입니다.

In UML specification

1

2

3

41

1. 위의 Behaviors 메타모델을

보시면 <<meta class>>Behavior

가 <<meta class>>Class 로 부터

상속된 것을 볼 수 있습니다.

참으로 이해하기 어려운

부분입니다. 예를 들어서, 우리가

sequence diagram 을

그려보았는데, 여기에 class 가

가지고 있는 어떠한 특징을

가지고 있다고 합니다. 그 정답이

옆에 보여지는 <<meta

class>>AssociationClass 에 있지

않을까 합니다.

2. Behaviors 메타모델에서 두 가지 더 중요하게 언급할 부분이 있습니다. 첫째, <<meta

class>>OpaqueBehavior / <<meta class>>FunctionBehavior 입니다. 모두 concrete 로

정의되어있습니다. 서두부분에서 저자가 UML 다이어그램에 직접 Java/C++ 코드를 넣을 수

있다고 했습니다. 그 이유를 설명하고 있는 meta class 입니다.

3. 둘째는 <<meta class>>BehavioredClassifier 가 무엇인지 설명하는 것입니다. 쉽게 말해서,

sequence diagram, statemachine digram, activity diagram 을 누가 소유하고 있는지, 즉

<<meta class>>Classifier 로 부터 상속된 누군가를 말하는 것입니다. 여기에서 재미있는

부분이 이 누군가를 context 라고 부르는 것입니다. 한글로 쉽게 번역이 어려운 부분입니다.

수리논리학 책을 영어로 보셨던 분들이라면 아주 친숙한 단어 입니다. 하지만, 영어 사전에

제시된 번역으로는 설명이 되지 않기에 이 책의 두번쨰 시리즈(UML Common

Behavior)에서 저자가 주의 깊게 설명을 할 부분입니다.

다음은 Activity diagram 에 대한 설명입니다. 아마도 한국 엔지니어들이 Class diagram 과 함께

가장 많이 사용하는 다이어그램입니다. Activity diagram 은 두가지 용도가 있습니다.

Figure 11.25 Association in UML specification

42

첫째는 use case diagram 과 함께 사용해서, use case 를 구체적으로 모델링하는 것입니다. 즉,

정보시스템으로 구현해야될

비즈니스 프로세스를 구체적으로

설명하는 다이어그램입니다.

대부분의 UML 관련 서적들이

이것만을 설명하고 있습니다. 즉,

activity diagram 을 그릴때, 옆에

보여지는 control node 만을

사용하지, 절대로 object node 를

사용하지는 않습니다. 저자는

개인적으로 이러한 용도로 activity

diagram 을 사용하지는 않습니다.

이러한 용도로 사용할 수 있는 너무나도 좋은 방법이 있는데, 그것이 바로 BPMN(Business

Process Modelling Notation) 입니다. Rational Software

Architect 에서도 BPMN 다이어그램을 그릴 수 있도록

툴 박스를 제공하고 있습니다. 새로운 프로젝트를

만들어서 그려보시기 바랍니다. 왜 activity diagram

보다 훨씬 좋은지 꼭 확인을 하시기 바랍니다.

다음은 activity diagram 의 두번째 용도입니다. 여러분이 이미 알고 있듯이 sequence diagram 을

그리고 나서, 코드를 생성시키면 속이 텅빈 메소드만을 가지고 있는 클래스를 갖게 됩니다.

이러한 텅빈 메소드를 채우는 것이 activity diagram 의 주된 목적입니다.

Activity diagram

43

그러기 위해서 사용해야될 버튼이 Object Node 버튼과 Actions 버튼입니다. 옆에 보여지는

것들입니다. 특히, Actions 밑에 있는 각각의 버튼을 클릭하시면, 수십개의 버튼이 있다는 것을

알게 됩니다.

이러한 버튼들을 사용하기 위해서

여러분이 반드시 Activity

메타모델과 Action 메타모델을

정확히 알아야만 합니다. 두

메타모델을 아래에 붙여

놓았습니다. 하지만, 두

메타모델을 이해하기가 처음에는

너무 어렵습니다. 그래서 저자가

이 두 메타모델에서 중요한 meta

class 만을 모아서, 새로운

다이어그램을 그려놓았습니다. activity diagram 을 그리기 위해서는 크게 두 부분의 중요한

개념이 필요하다는 것을 알게 될 것입니다.

저자가 UML 문서를 읽어 나가면서 가장 여려운 부분이면서, 이해를 한 후에 가장 기쁨을

느꼈던 부분이 Activity 메타모델과 Action 메타모델입니다. UML 을 사용함으로 인해서, 정말로

Java/C++ 코딩에서 벗어날 수 있는 길을 보았기 때문입니다. 단지, 버튼을 클릭만 해서, 우리가

필요로 하는 핵심 로직을 프로그래밍 할 수 있습니다.

Variable Actions 버튼을 한번 눌러

보세요. 여러개의 버튼이

보입니다. 직관적으로 각각의

버튼이 무엇을 위한 것인지,

우리가 쉽게 상상을 할 수

있습니다. 변수(variable)에 값을

집어넣고, 읽고, 지우고…. 우리가

이미 자바언어에서 하던

것들입니다. 하지만 이제 부터는 클릭만 하면 됩니다. Object Actions 버튼도 한번 눌러봐

주세요. Create Object 버튼은 정확히 자바에서 인스턴스를 생성하는 것과 일치합니다. 그리고,

Destroy Object 버튼은 자바에서 인스턴스를 지우는 것과 똑같습니다. 왜 Actions 메타모델을

이해해야 하는지, 여러분들이 이해하셨을 것이라고 믿겠습니다.

Activity diagram

44

In UML specification

Figure 15.1 Activities In UML specification

45

UML specification 문서의 Chapter 16 Actions 에

보이는 모든 메타모델들이 옆에 보이는 버튼을

위한 설명입니다.

Activity diagram

46

위에서 저자가 요약해 놓은 메타모델 다이어그램중에서 가장 이해하기 힘든 부분이, Activities

메타모델에 보이는 <<meta class>> ControlFlow / <<meta class>>ObjectFlow 입니다. 이 두 개념을

설명하기 위해서 UML specification 문서에서는 token 이라는 개념을 사용해서 설명을 하고

있습니다. 실제적으로 메타모델에 <<meta class>>Token 은 존재하지 않습니다. 그런데도 token

이라는 단어가 반복적으로 사용 되고 있기에, 많은 이들을 혼란에 빠트리게 합니다. 저자는

여기서 또 하나의 책을 소개하고자 합니다.

Real-Life BPMN: Using BPMN 2.0 to Analyze, Improve, and Automate Processes in Your Company, Jakob Freund

BPMN 을 배울 수 있는 초보자를 위한 책입니다. BPMN 에서도 token 개념이 등장하는 것을 보실

수 있습니다. 아주 쉬운 아이디어인데, UML specification 에서는 너무도 어렵게 설명을 하고

있습니다. 이 책을 권하는 더 큰 이유는 다음 절에서 설명하게될 UML 다이어그램에 등장하는

events 때문입니다. Events 역시 UML 문서에서 이해가 잘 되지 않는 부분입니다. 이 책을 통해서

token/events 에 대한 간단한 개념들을 정확히 익히시기를 바랍니다. UML 문서를 읽는데

있어서 가장 큰 문제는 영어에 대한 두려움입니다. 다른 쉬운 책을 읽음으로 인해서

UML 문서를 접근하는 것도 좋은 방법이기에 저자는이곳에 여러권의 책을 소개하는 것입니다.

마지막으로 왜 Action 메타모델이 중요한지, 더 설명을 하고자 합니다. Action 메타모델을 Action

semantics 라고도 부릅니다. 첫째는 이미 말했듯이, action semantics 와 함께 activity diagram 을

그리면, 우리는 보다 완성된 코드가 생성되는 것을 볼 수 있습니다. 두번째는 action

semantics 를 이용해서 자바언어에서 볼수 있는 unit test 를 모델링 단계에서도 할 수 있다는

것입니다. 즉, Java 코드를 생성시키지 않고도, Rational Software Architect 가 제공하는 object

diagram 과 Object constraint language 를 이용해서 unit test 를 할 수 있습니다. 다시 요약한다면,

프로젝트 초기 단계에서 사용자의 요구 사항을 모델링 한 후에, 우리가 만들어 놓은 모델이

요구사항을 정확히 반영하고 있는지 바로 모델을 검사하는 것입니다. 따라서, 소프트웨어 개발

프로세스 중에 debugging 또는 testing 과정에서 해야 될 많은 일들을 줄여주게 됩니다.

47

5.4 Events

UML specification 문서를 읽어가면서, 이해하기 어려운

부분중의 하나가 events 메타모델입니다. 위 메타모델을

보시면 여러개의 concrete meta class 가 존재합니다. 하지만

옆을 보시면 Rational Software Architect 이 제공하는 버튼은

오직 2 개뿐입니다. 그리고 <<meta class>>Event 는 <<meta

class>>Classifier 또는 <<meta class>>Behaviour 에서도

상속되지 않았습니다. 그런데 activity diagram 에 event 를

나타내는 버튼이 보입니다.

왜 IBM Rational Software 엔지니어들이 이렇게 툴을

만들었는지, 우리가 깊이 생각해봐야 할 부분입니다. 이 책의

두번째 시리즈(UML Common Behavior)에서 예제와 함께

자세히 설명을 하도록 하겠습니다.

앞에서도 이미 언급했듯이, event 를 이해하기 위해서 BPMN 책을 꼭 읽기를 권해드립니다.

BPMN 에서는 이벤트를 세가지 기준을 가지고 분류를 합니다. event 를 이해하는데 많은

도움이 됩니다.

1. Throwing event / Catching event 2. Start event / intermediate event / End event 3. Interrupted event / non-interrupted event

In UML specification

48

다음의 웹페이지를 방문하시면 BPMN 에 보이는 모든 도형을 보실 수 있습니다.

https://camunda.org/bpmn/reference/#overview

너무 많은 도형이 있어서 혼란스럽기도 하겠지만, 이벤트를 이해하는대 많은 도움이 됩니다.

또한, 앞에서 이미 언급한 SysML 에 관한 책을 보시면, Block definition diagram 에서 signal 을

어떻게 처리하는지 보실 수 있습니다. UML 다이그램에서 보이는 signal 과 똑 같은 개념이니 꼭

한번 보시기를 권해 드립니다.

5.5 Stereotypes

지금까지 우리는 Rational Software Architect 에서 제공하는 수많은 버튼들이 어떻게 만들어지게

되었는지, 그 이론적인 배경을 간단히 살펴보았습니다. 물론, 제 3 장에서부터는 보다 더

자세히 살펴볼 예정입니다. 이번장을 마치기 전에 어려운 주제 한가지를 더 다루려고 합니다.

UML specification 문서에 나오는 개념 중에서 가장 어려운 것입니다. 그것은 사용자 스스로가

Rational Software Architect 에 새로운 버튼을 추가하는 것입니다. 솔찍히 Rational Software

Architect 에서 제공하는 버튼 마저도 이해하기 힘든 것이 현실인데, 여기에 새로운 버튼을

추가한다고 하니 어려움을 느끼는 것은 당연합니다. 하지만, 우리는 때때로 다양한 도메인

영역을 만나서 모델링을 해야할 경우가 있습니다. 이러한 새로운 영역을 모델링하기에 때로는

Rational Software Architect 에서 기본적으로 제공하는 버튼들이 부족하다는 것을 저자는 경험을

통해서 알게 되었습니다. 따라서 우리는 이런 상황을 대비해서 새로운 의미를 지닌 버튼을

어떻게 만드는지 사용자가 꼭 알아야만 합니다. 이러한 주제를 다루는 것이 stereotype / profile

입니다. 그러나 저자의 경험으로 너무도 이해하기 어려운 개념입니다.

먼저, Rational Software Architect 에서

새로운 UML Profile Project 를 만듭니다.

저자는 프로젝트 이름을 MyProfileProject

로, 그리고 파일 이름을 MyProfile 로

타입을 했습니다.

49

Project Explore 를 보시면, 아래 그림처럼 uml 폴더 안에 UML specificiation 문서에 보이는 모든

meta class 가 이곳에 나열되어 있는 것을 확인 하실 수 있습니다. 그중에서, <<meta

class>>Class 를 클릭해 보았습니다. 그 안에 있는 attributes / methods 를 여러분이 지금 이해할

수 있다면, 여러분은 이미 상당한 수준에 올라와 있는 것입니다. 왜냐하면, UML

specficiation 문서에 나와 있는 Classes 메타모델을 이해하고 있다는 뜻이기 때문입니다.

50

그 In UML specification

51

다시 요약을 한다면, 위의 Classes 메타모델은 여러분이 class diagram 에서 그리게 될 class

버튼이 가지고 있어야 할 모든 특징을 설명하고 있는 것입니다. 이러한 특징들이 uml 폴더

아래에 있는 <<meta class>>Class 에서 attribute/method 를 이용해서 설명이 되고 있는 것입니다.

UML specification 문서에 보이는 모든 메타 모델이 class diagram 을 이용해서 설명이 되어

있습니다. 이러한 class diagram 에 보이는 모든 클래스는 meta class 입니다. 따라서, uml 폴더

안에 존재하는 모든 것에 <<meta class>> 기호를 붙여놓은 것입니다.

옆의 그림을 보시면 class

diagram 에 두개의 클래스를

그려놓았습니다. Class1 을

클릭하면, 이 클래스에 해당하는

Property view 를 볼 수 있습니다.

사용자는 네가지 (name, visibility,

abstract, leaf) 속성에 대해서

결정을 해야 됩니다. 여기서

주의 깊게 볼것이 abtract

속성입니다. 이 속성은 <<meta

class>>Class 에 정의되어 있습니다. 하지만 나머지 세개의 속성은 <<meta class>>Class 에는

보이지 않습니다. 당연히, 그 이유는 <<meta class>>Class 보다 위쪽에 있는 meta class 에서

세가지 속성을 물려받은 것입니다. 다시 강조하지만, 저자가 이 책에서 계속적으로 UML

specification 문서에 보이는 메타모델을 이해하도록 권하는 이유는, Property view 에 보이는

여러 설정을 사용자 분들이 어려움 없이 할 수 있어야만 하기 때문입니다.

이제부터 본격적으로 기존의

<<meta class>>Class 에

부가적인 의미를 부여한

새로운 meta class 를 만들어

보겠습니다. 이것을

stereotype 이라고 부르는

것입니다. 또한 stereotype 을

모아놓은 것이 profile 입니다.

UML specification 문서에서는

<<meta class>>Class 를 위해서

기본적으로 6 개의

sterotype 을 제공하고

52

있습니다. 또한 Rational software Architect 가 추가적으로 두개 <<stereotype>>Realization /

<<stereotype>>Specification 를 제공합니다. class diagram 을 그릴때 주어지는 팔레트에서

stereotyped class 를 클릭해보시면 모두 8 개가 있는 것을 확인하실 수 있습니다.

이제부터는 저자가 새로운 stereotype 을 만들어 보겠습니다. 앞에서 이미 만드신 UML Profile

project 로 가셔서, 새로운 class diagram 을 만들어 보세요. 중요한 일이 벌어지는 것을 보게

됩니다. UML Profile project 에서는 오직 class diagram 만을 그릴 수 있습니다. 또한 팔레트에

보여지는 버튼도 달라집니다. 여러분이 지금부터 처음으로 메타모델(meta model)을 스스로

만들고 있다는 것을 꼭 이해하시기 바랍니다.

Stereotype 에 나타낼수 있는 것은 오직 attribute / constraint 뿐입니다. 즉 기존의 <<meta

class>>Class 가 가지고 있는 특징에 attribute / constraint 를 추가하는 것입니다. 하지만

<<stereotype>>Server 에 추가되는 속성(attribute)은 <<meta class>>Class 에 보여지는 속성과는

아주 다른 개념을 가지고 있습니다. 그래서 attribute 보다는 tag definition 이라고 부릅니다.

Modelling in the meta level

Extension Tag definition

Constraints

53

위의 메타모델을 그린

이후, 다른 모델링

프로젝트를 만들어서

Property View 에서

MyProfile 파일을

링크시켜주어야만

합니다. 그러면, 옆에서

보듯이 새롭게

<<stereotype>>Server 가

생긴것을 확인하실 수

있습니다.

이제 이렇게 새롭게

들어진<stereotype>>Server

을 이용해서 class diagram

을 그려 보겠습니다. 옆에

보듯이 <stereotype>>

Server 에서 정의된 속성

RequiredCapacity 가

다이어그램 안에 보여지는

것을 볼 수 있습니다. 이때 설정되는 값을 tagged value 라고 부릅니다. 하지만 <<meta

class>>Class 에서 정의된 속성 abstract 는 Property view 에서 우리가 설정을 했었습니다. 어떠한

차이가 있는지, 여러분이 확인하셨을 것입니다. 만약 이해가 되신다면, 이제 UML 초보자는

아닙니다. Stereotype 에 대한 보다 더 자세한 설명은 이 책의 두번째 시리즈(UML Standard

Profile)에서 하도록 하겠습니다.

Modelling in the object level

Tagged vlaue

54

UML 을 가장 정확히 그리고 빨리 이해하는 방법을

다시 말씀드리고자 합니다.

첫째, UML specification 문서에 있는 메타모델을

보시면서, class diagram 보이는 meta class 의 특징을

학습할때, Rational Software Architect 가 제공하는

Profile 폴더를 함께 보는 것입니다. 앞에서 우리는 이미

예제로, <<meta class>>Class 를 비교해 보았습니다.

둘째, UML specification 문서에 존재하는 가능한 많은

예제를 Rational Software Architect 에 그려보도록

노력하는 것입니다. 이론과 함께 실제로 버튼을

눌러봄으로써 meta class 가 가지고 있는

속성(attribute)과 메소드(method)를 더 깊게 이해하실

수 있습니다.

All meta classes in UML

55

6 Meta structure 2

UML specification 문서의 대부분을 차지하는 메타모델(meta model) 을 보면서, 여러분이 다음과

같은 의심을 하고 있다면, 여러분은 이미 UML 전문가가 되신 것입니다.

왜 object level 에서 정의된 직사각형의 class 도형을 이용해서 meta level 의 semantics 를

설명하고 있을까?

이 책의 처음부분에서 저자가 나열한 모든 OMG 에서 만들어진 모델링 언어를 다시 한번

보시기 바랍니다. OMG 홈페이지에 가셔서 문서를 열어 보시기 바랍니다. 모든 문서가 class

diagram 을 이용해서 semantics 를 설명하고 있습니다.

제 2 장 meta structure 1 에서 한국어를 사용해서 한국어의 문법을 사용하는 것을 우리는 이미

보았습니다. 프로그램 언어도 마찬가지 입니다. 컴파일러를 디자인하는 엔지니어들도 수리

논리학을 이용해서 semantics 를 기술하지만, 역시나 object level 에서 사용되는 문자기호들이

semantics 에서 사용되는 것을 피할 수 없습니다.

우리 인간이 사용하는 언어와 기호의 한계를 여러분이 여기서 조금 느끼셨으면 합니다.

칸토르의 무한 집합론이 수학에 혼란을 야기하는 이유는 전체와 부분의 개념을 정확이 정의 할

수 없기 때문입니다. 이러한 일들이 우리의 언어에도 나타나고 있습니다. meta level 은

상위개념이고, object level 은 하위 개념입니다. 하지만, 위의 예들에서 보듯이 하위 개념들이

상위 개념에서 사용이 되고 있습니다. 전체와 부분의 혼란이 우리 인간이 사용하는 언어에서도

일어나고 있습니다.

괴델의 불완전성 정리를 등장하게 만드는 핵심 적인 이유입니다. 우리 인간은 언어를 사용하는

동물입니다. 신이 만들어 놓은 세계를 언어를 통해서 기술을 합니다. 하지만 이 언어에 뭔가

문제가 있습니다. 언어에 우리가 이해할 수 없는 블래홀이 있습니다. 제가 여러분을 과학의

세계로 인도하고 있다는 것을 이제 아셨을 것입니다.

여기에서 독자분들에게 한가지 더 중요한 질문을 던져 보겠습니다. 현재 컴퓨터 사이언스의

세계에는 너무나 많은 컴퓨터 언어와 모델링 언어가 존재합니다. 저자가 이제까지 배웠던

언어들을 아래에 나열해 보았습니다. 여러분들도 마찬가지 일거라고 생각이 듭니다.

C, Cobol, Fortran, C++, Java, Haskell, Ocaml, C#, Visual Basic, Matlab, TeX, Python, Coq, UML, SysML, BPMN, BPEL, …

새로운 언어가 나올 때 마다 우리는 그 문법을 배우느라 짜증날 때가 많았습니다. 한가지

언어만 있으면 얼마나 좋을까 생각을 해봅니다. 하지만 우리는 현실적으로 정보 시스템으로

구축 해야만 되는 다양한 도메인 영역을 만나게 됩니다. 따라서 각각의 필요에 따라 다양한

56

언어를 써야만 하는 것입니다. 예를 들어 저자의 경험으로 수학적인 모델과 관련된 프로그램을

만들 때 functional programming 언어가 훨씬 편하다는 것을 알게 되었습니다. 그래서

자바언어에 lambda notation 이 들어 왔을 때 너무 좋았던 기억이 납니다.

어떤 분들은 이런 상상도 하실 것입니다. 자바에 계속해서 새로운 문법을 추가해서 Super Java

언어를 만들면 되지 않을까 하고, 그래서 한가지 언어만 사용하면 얼마나 편할까하고 상상을

해봅니다. 하지만 이것이 불가능하다고 이미 100 년 전에 괴델에 의해서 증명이 됐습니다.

괴델의 불완전성 정리를 컴퓨터 프로그래밍 언어의 관점에서 다시 해석을 할 수 있습니다. 우리

인간이 새로운 도메인을 커버하기 위해서 자바언어에 새로운 문법을 추가 한다고 할지라도,

신은 한 발자국 더 나아가서 새로운 도메인 영역을 우리에게 주십니다. 결코 인간에게 추월

당하는 일을 허용하지 않습니다. 하지만 여기서 우리 인간은 이성의 한계에 좌절하지 않고

계속해서 앞으로 나아간다는 것이 괴델의 불완전성 정리의 진정한 의미 입니다.

프로그램언어와 모델링 언어도 마찬가지로 계속 진화하고 있다는 것입니다. 즉 수리논리학을

이용해서 새로운 formal system 을 계속 만들고 있습니다. 하지만 여러 분들에게 전달되는 것은

단지 새로운 언어의 문법뿐입니다. 이제는 여러분들이 이러한 프로그래밍 언어 습득의

반복적인 틀에서 벗어났으면 하는 바램 입니다. 앞으로 독자분들이 조금만 수리논리학에

관심을 가졌으면 하는 것이 저자의 바램이고, 그 시작이 UML specification 문서를 이해하는

것입니다.

57

7 UML 을 배우는 궁극적인 목적 – 지적 재산권

한국에서 객체지향 모델링을 할 수 있는 starUML 12을 만들었다고 했을 때, 저자는 많이 기쁘고

다행이라고 생각을 했었습니다. 하지만 여러분들에게 UML specification 문서를 이해한 이후,

툴을 만들어 보라고 도전을 권하고 싶지는 않습니다. 왜냐하면 Rational Software Architect /

Sparx Enterprise Architect 보다 더 좋은 툴을 만드는 것은 현재 불가능합니다. 한국에서 starUML

을 만든 분들을 존경합니다. 하지만 툴 개발은 이제 비즈니스 모델이 아니라고 생각이 듭니다.

현재 Rational Software Architect / Sparx Enterprose Architect 는 거의 무료로 사용하실 수

있습니다.

저자가 여러분들에게 권하고 싶은 것은 UML 을 사용해서 자신의 전문 영역인 분야에서 Library

를 구축하라는 것입니다. 이게 여러분을 강하게 만드는 재산이고, UML 을 배우는 이유입니다.

저자의 경험을 든다면, 저자는 금융 분야의 꽃 이라고 할 수 있는 파생상품에 대해서 library 를

구축하고 있습니다.

더 큰 바램이 있다면, OMG 문서의 표준화에 참여할 수 있는 한국인 소프트웨어 기술자와

기업이 많이 나왔으면 하는 것입니다.

12 www.starUML.io

58

8 두번째 시리즈에서 설명될 내용 1. Formal systems

• Mathematical logic • Functional programming • Object Constraint Language • Concrete syntax in structural recursion • Abstract syntax in meta models

2. UML Common Structure 3. UML values 4. UML classification 5. UML simple Classifiers 6. UML Structured Classifiers 7. UML Packages 8. UML Common Behaviour 9. UML StateMachines 10. UML Activities 11. UML Actions 12. UML Interactions 13. UML Usecases 14. UML Deployments 15. UML InformationFlows 16. UML Primitive Types 17. UML Standard Profile

59

부록 A

sin𝛼𝛼 = 𝑏𝑏𝑎𝑎

cos𝛼𝛼 = 𝑐𝑐𝑎𝑎

tan𝛼𝛼 = 𝑏𝑏𝑐𝑐

Definition 1. Trigonometric(삼각함수)

A trigonometric tells about the ratio between two sides of a right-angled triangle(직각

삼각형)

cosec𝛼𝛼 = 𝑎𝑎𝑏𝑏

sec𝛼𝛼 = 𝑎𝑎𝑐𝑐

cot𝛼𝛼 = 𝑐𝑐𝑏𝑏

Theorem 1.

sin2 α + cos2α = 1⬚

Proof. (LHS means Left Hand Side of the original equation) (RHS means Right Hand Side of the original equation)

𝐿𝐿𝐿𝐿𝐿𝐿 = �𝑏𝑏𝑎𝑎�2

+ �𝑐𝑐𝑎𝑎�2𝑏𝑏𝑏𝑏 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 1

= 𝑏𝑏2+𝑐𝑐2

𝑎𝑎2 𝑏𝑏𝑏𝑏 𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑠𝑠𝑑𝑑 𝑑𝑑𝑠𝑠𝑑𝑑𝑠𝑠𝑑𝑑𝑑𝑑𝑑𝑑𝑒𝑒𝑒𝑒𝑏𝑏 𝑒𝑒𝑎𝑎𝑑𝑑𝑏𝑏𝑒𝑒𝑒𝑒

= 𝑎𝑎2

𝑎𝑎2 𝑏𝑏𝑏𝑏 𝑃𝑃𝑏𝑏𝑑𝑑ℎ𝑒𝑒𝑎𝑎𝑑𝑑𝑒𝑒𝑒𝑒𝑠𝑠 𝑇𝑇ℎ𝑑𝑑𝑑𝑑𝑒𝑒𝑑𝑑𝑠𝑠 𝑏𝑏2 + 𝑐𝑐2 = 𝑒𝑒2

= 1 𝑏𝑏𝑏𝑏 𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑠𝑠𝑑𝑑 𝑑𝑑𝑠𝑠𝑑𝑑𝑠𝑠𝑑𝑑𝑑𝑑𝑑𝑑𝑒𝑒𝑒𝑒𝑏𝑏 𝑒𝑒𝑠𝑠𝑎𝑎𝑑𝑑𝑏𝑏𝑑𝑑𝑒𝑒𝑒𝑒

= 𝑅𝑅𝐿𝐿𝐿𝐿

60

부록 B

저자가 박사 과정을 마치면서 프로그램 언어를 디자인 했어야만 했습니다. 이 언어는 Java 와

Object constraint language 의 특징을 동시에 가지고 있는 언어입니다. 아래의 두 그림은 이

언어를 정의하기 위해서 사용했던 BNF syntax 입니다.

Theorem 2.

tan𝛼𝛼 = sin𝛼𝛼cos𝛼𝛼

Proof.

𝐿𝐿𝐿𝐿𝐿𝐿 = 𝑏𝑏 𝑎𝑎�𝑐𝑐 𝑎𝑎⁄

𝑏𝑏𝑏𝑏 𝑑𝑑ℎ𝑑𝑑 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 1

= 𝑏𝑏𝑐𝑐

𝑏𝑏𝑏𝑏 𝑑𝑑ℎ𝑑𝑑 𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑠𝑠𝑑𝑑 𝑑𝑑𝑠𝑠𝑑𝑑𝑠𝑠𝑑𝑑𝑑𝑑𝑑𝑑𝑒𝑒𝑒𝑒𝑏𝑏 𝑒𝑒𝑠𝑠𝑎𝑎𝑑𝑑𝑏𝑏𝑑𝑑𝑒𝑒𝑒𝑒

= tan𝛼𝛼 𝑏𝑏𝑏𝑏 𝑑𝑑ℎ𝑑𝑑 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 1

= 𝑅𝑅𝐿𝐿𝐿𝐿

Theorem 3.

1 + tan2 𝛼𝛼 = sec2 𝛼𝛼

Proof.

sin2 𝛼𝛼 + cos2 𝛼𝛼 = 1 𝑑𝑑𝑒𝑒𝑑𝑑𝑠𝑠 𝑑𝑑ℎ𝑑𝑑 𝑇𝑇ℎ𝑒𝑒𝑑𝑑𝑑𝑑𝑠𝑠 1

sin2 𝛼𝛼cos2 𝛼𝛼

+ cos2 𝛼𝛼cos2 𝛼𝛼

= 1

cos2 𝛼𝛼 𝑏𝑏𝑏𝑏 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑎𝑎 𝑑𝑑ℎ𝑑𝑑 𝑏𝑏𝑑𝑑𝑑𝑑ℎ 𝑠𝑠𝑑𝑑𝑑𝑑𝑑𝑑𝑠𝑠 𝑏𝑏𝑏𝑏 cos2 𝛼𝛼

�sin𝛼𝛼cos𝛼𝛼

�2

+ 1 = �1

cos𝛼𝛼�2

𝑏𝑏𝑏𝑏 𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑠𝑠𝑑𝑑 𝑑𝑑𝑠𝑠𝑑𝑑𝑠𝑠𝑑𝑑𝑑𝑑𝑑𝑑𝑒𝑒𝑒𝑒𝑏𝑏 𝑒𝑒𝑠𝑠𝑎𝑎𝑑𝑑𝑏𝑏𝑒𝑒𝑒𝑒

tan2 𝛼𝛼 + 1 = sec2 𝛼𝛼 𝑏𝑏𝑏𝑏 𝑑𝑑ℎ𝑑𝑑 𝐷𝐷𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 1

61

62