Younghoe.Info (final edition)

발췌한 글 논지의 중심에 선 그림은 아니지만, 글 자체보다는 이 그림이 확 시선에 들어왔다.

모델러가 모델을 그릴 때는 메타를 염두해야 한다.
메타(Meta)라는 말을 알 필요는 적다.
더구나 거북한 단어니까 가급적 남용할 필요도 없다.
다만, 어떤 기준을 가지고 모델을 도출하고 표현해야 하는데 그 기준이 곧 메타라 할 수 있다.

UML로 객체지향 모델링을 하면 가장 기본적인 단위가 클래스이다.
클래스 역시 일종의 타입이 된다.
모델링을 하면 구체적인 타입으로 클래스 이름이 부여된다.
클래스라는 타입과 개별 클래스 사이에서의 구분이 요구되는 경우는 거의 늘상 일어난다.
가령, 한국과 개별 번지 사이에 구분이 필요한 것처럼 세상은 무척 복잡하기 때문이다.

그래서, UML에서 확장방안으로 제공하는 것이 스테레오타입(stereotype)이다.
그렇다고, 반드시 스테레오 타입에 메타 타입을 부여해야 할 이유는 전혀 없다.
모델은 의사소통을 위한 것이라는 대전제를 잊지 않는한 그야말로 아무거나 부여할 수 있다.
'왜 그런 것을 스테레오타입으로 부여하느냐'라고 묻는 분들에게 대답을 준비할 필요는 있다.

하지만, 효용성의 관점과 형식적 완성이 늘 부합하지는 않는다.

그래도 우리는 선택의 자유가 있다. ^^

나는 대개의 경우 둘 사이의 조화를 찾으려고 노력한다. 조화가 궁극에 다다르면 오늘 조엘이 올린 글에 소개된 다리처럼 우아함을 갖게 된다.



하지만, 소프트웨어 개발에서는 우아함만 고수하기엔 현실이 척박하다. 따라서, 둘 중 하나를 포기해야 할 상황이 발생하고... 나는 어느 때고 효용성을 택한다. 그리고, 그래야 한다고 떠들고 다닌다. (그래서, Pragmatic 시리즈가 너무 좋다. ^^)

어디까지나 순전히 가상상황이지만, 내가 어떤 제품을 쓰는데 클래스나 메소드이름을 영문과 숫자가 섞인 12자리 암호로 정해야 한다면 어떻게 할 것인가? 스테레오타입에 한글 클래스명을 넣겠다. UML만 공부한 사람이 '쟤는 UML 알긴 하는거야' 라고 코웃음 칠 수 있지만... 나는 UML을 졸업했으니까, 굳이 규정(disciplines)에 얽매일 필요는 없다.

규칙과 원칙(principle)이 충돌하면, 원칙을 새우기 위해서 새 규정을 만들어야 한다.

마치 물개선생님의 댓글로 인해 글을 쓰는 듯 하여, 사람 무안하게 만든다는 인상을 줄까봐 한 템포 쉬었다 올리려다가 널리 이해하시리라 믿고... ^^

이글은 어제인가 정리하려던 내용이다. 얼마전 두 개의 솔루션 사이를 이어주는 일종의 연동 코드를 분석했다. 그 중 가장 중요한 시나리오를 그린 시퀀스는 아래 그림과 같다.

ORM 도입의 선행 조건

직업을 바꾸기 전까지는 잊지 않을 Principle of least privilege이라는 원칙은 모델링에도 적용된다.

more..

1. 모델링 활용 행태 반성을 위한 글
UML을 어떻게 써야 하는지...
모델링, 조립식 설명서, UML, ...


2. 모델링 잘 쓴 사례
Google's Master Plan
개념 모델링 최고의 도구는

UML을 어떻게 써야 하는지...라는 참으로 이 아저씨스러운 글을 올렸다.
자신만의 색깔이 있다는 것은 좋은 일이다.

이글은 일단 해학이 있다. 하지만, 난 해학의 뜻을 잘 모른다.^^
암튼 암호화 된 비아냥이 들어있다.
암호를 해독할 눈이 있는 경우에만 시원한 느낌을 받을 수 있다.
간혹 비아냥만 해석되는 사람도 있다.

이보다 내가 마음에 드는 점은 소녀풍으로 풀어냈다는 것이다.
내용이야 어쨌든 막판에 점수 내서 호들갑을 떨 수 있다는 것... 아찔한 순간이다.^^

학부시절에 작성해서 유명해질 욕심으로 올렸던 글이 있다.
당시는 전혀 유명해지지 않았다.

몇년이 지나고 나서 현업에서 활동할 때
강의를 듣는 분 중에 날 안다고 해서.. 어떻게?
했더니 그 강좌를 언급해서... 쪽팔려 죽는 줄 알았다.
개뿔도 모르면서 유명해지려고 나서면 당하는 댓가다.
네이버의 펌질은 어찌해볼 도리가 없었다. 한동안 쪽팔림 극복기가 요구되었다.

UML을 이용해 생업을 하는 입장에서 느낀 바는
UML이 아니, 정확하게는 객체지향 모델링이 사람들에게 받아들여지기가 무척 어렵다는 점이다.

성인남녀라면 8시간 정도면 누구나 UML을 마스타! 할 수 있다.
UML은 초간단 표기법일 뿐이다.
문제는 생각을 표현하는 것이 평소 훈련이 안된 사람들에게는 무척 어렵다는 점이다.

대부분의 사람들에게는 자신의 생각을 표현하는 것에 익숙하지 못한 듯하다.
그런 것도 몰라주고 짧은 시간에 다른 사람들도 이해할 수 있게끔 표현하라니
짜증이 앞서는 것이 더 문제인지도 모르지만.

나는 고객들로부터 단 한번도 생각을 표현하는 방법에 대한 질문을 받아본 일이 없다.
모두가 묻는 것을 한 마디로 요약하면

'이젠 어떻게 그려요?'

많은 사람들은 모델링을 CBD라고 부른다.
CBD는 방법론으로 통용된다. 고로, 상당수가 모델링을 방법론으로 이해한다.ㅡㅡ;

어릴 때 프라모델 완구를 '조립식'이라고 불렀던 기억이 안다.
저 아저씨가 모델링 지침을 조립식 설명서에 비유한 일이 있다.
참 적절한 비유라고 생각한 적이 있다.
더러는 생산성(아무나 짤 수 있게)을 위해서 작명 지침마저도 조립식 설명서처럼 만드는 경우가 꽤 있다.

요즘 들어 부정적인 글을 많이 올린다. 쩝. 한번쯤 마음을 정화할 필요가 있다.
사실 말하고 싶은 것은 다음의 한마디다.

모델링은 의사전달을 돕기 위한 것이지
의사소통을 피하기 위한 것 혹은 대치하기 위한 것은 아니고
더더군다나 작성만 하면 뭔가 도움을 주는 것은 절대 아니다.

UML은 그 용도에 맞춰쓸때 빛이 나기 마련이다.

스터디 발표를 듣다가 문득 '프라임(Prime)'이라는 말이 의미있게 다가왔다.
Prime은 소수(素數)나 으뜸을 칭하는 의미인데
왜 수학에서는 A에 상응하는 무언가를 표현할 때 A′(A 프라임)이라고 하는가?
학창 시절 수학시간에는 왜 이러한 의문이 들지 않았을까 하는 생각과 의문이 떠올랐다.

위키피디아를 보면, 인치와 피트를 나타내는 기호로 사용되고 영국에서는 대쉬로도 불린다고 한다.

민재님은 프라임에 대한 설명 대신에 유사하게 사용되는 Foo에 대해 알아봤던 과정을 공유했다.
어원에 대한 여러 가지 유추 중에 가장 의미있어 보이는 것은 "File Or Object"이다.
그 용도는
to represent an as-yet-unspecified term, value, process, function, destination or event but seldom a person
즉, 사람을 제외한 모든 것 중에서 아직 분명하게 설명/정의할 수 없는 것을 칭할 때이다.
(사람일 때는 홍길동을 써주기 바란다. ^^)

이러한 개념이 연이어 필요할 때는
Foo 이후에는 Bar,
그 이후는 Baz/Gazonk,
네 번째는 bop/Bat/Quux,
그 뒤는 Quuux, Quuuux, Quuuuux

많기도 하다.

재방송(원문 작성 일시:2006/01/12 (목) 12:22 )

• 변경을 위해서는 이 객체를 수정한다.
  
• 코드를 봐야 정보 전달 방식을 알 수 있어 추상화를 높여서 전체를 파악하는데 문제를 유발한다.
  
• 추상화를 높여 모델이나 메소드 내부를 배제한 인터페이스 수준에서 보면, 정보 전달이 일어나는 것을 간과하게 될 수 있다.

• HanRSS 190
• bloglines 27
• Rojo 6
• FISH 8
• Google 6
• newsgator 1
• Yahoo 1
• email 2

통계가 정확하다면 두 개 정도의 아이콘은 제 구실을 못한 것이지만
나머지는 횟수를 떠나 모두 쓰임을 했다.

블로그 방문자이면서 RSS리더 사용자인 User와 블로그 RSS 제공 시스템을 연결하는
User Interface의 기본적인 역할을 수행한 것이다.

보편적으로 한 사람의 사용자가 복수의 리더를 쓰지 않는다고 가정하면
위의 버튼 하나하나는RSS 구독 기능 관점에서는 별도의 인터페이스가 된다.