[RSM 1권 핵심개념] 1장. 실체 I (5.0) 1절. 실체
[RSM 1권 핵심개념] 1장. 실체 I (5.0) 2절. 객체
[RSM 1권 핵심개념] 1장. 실체 I (5.0) 3절. 값
바로 바로 답하기
1. 객체는 ( ), ( ), ( )를 갖는다.
2. 값은 ( )만을 갖는다.
3. 변화를 이야기 하려면 ( )이 전제되어야 한다.
4. 정체성, 상태, 특성에 대한 영문 표기는?
5. 정체성이란?
좀 어렵게 자기동일성 이라고도 한다.
( )이 ( )인 것을 ( ) 방법
6. 상태란?
객체가 그때 또는 지금 ( )를 ( )으로 표현한 것
7. 객체의 상태를 표현하는데 사용되는 값을 객체의 ( )이라 한다.
8. ( )은 그룹특성으로 사용되는 값이다.
생각해 보고 답하기
1. 값은 변화에 대해서 말할 수 있는가? 그렇게 답한 이유는?
2. 객체와 값의 같은 점과 다른 점을 설명합니다.
객체와 값은 모두 실체, 그들을 나누는 기준은 정체성
3. 값이 객체와 같이 독립적인 존재로 인식될 필요 없이, 의존적인 존재로만 인식되어도 되는 이유를 설명합니다.
값이 어디에 사용되는지를 생각해볼 것
4. 객체와 값의 생명주기(life cycle)를 정체성과 상태의 유무를 가지고 설명합니다.
5. 칠판에 쓰인 3이라는 숫자를 객체로 다룰 때의 인식과 값으로 다룰 때의 인식이 어떻게 다른지를 설명합니다.
실전 모델링
1. 객체인가, 값인가?
객체인지 값인지를 아는 것은 모델링의 관문입니다.
모델링은 복잡한 대상을 다루는 방법입니다. 객체모델링은 객체와 값을 구분하고, 객체를 인식하는데 있어 값을 감춤으로 한 번에 드러나는(인식해야 하는) 대상의 수를 줄일 수 있습니다.
1.1 당신이 알고 있는 것보다 도메인이 중요합니다.
객체인지 값인지에 대한 구분은 인식의 문제입니다.
인식이라는 것은 어떠한 상황에 처해있느냐에 따라 달라질 수 있습니다.
동일한 주소라고 하더라도
배송회사에서 고객의 주소로 사용될 때와
우체국에서 관리되는 주소로 사용될 때는 인식이 달라집니다.
배송회사에서 주소에 대한 인식은 고객에 대한 인식 없이는 의미가 없습니다. 하지만 우체국에서 관리되는 주소는 의미 있게 독립적으로 인식될 수 있습니다.
어떠한 상황인가를 소프트웨어모델링 관점에서 살펴보면 모델링의 대상 즉 도메인(domain)을 의미합니다.
1.2 도메인에서 여러 개 중에서 선택할 수 있고, 이것저것으로 지칭한다면 객체입니다.
이것은 정체성을 갖는다는 의미이고, 정체성을 갖는 것이 객체이기 때문에 이런 기법이 성립됩니다.
정보 형태로 표현되어 있는 경우에는 목록에서 선택됩니다.
[RSM 1권 핵심개념] 1장. 실체 I (5.0) 1절. 실체
[RSM 1권 핵심개념] 1장. 실체 I (5.0) 2절. 객체
3절. 값
3.1 값은 실체이기 때문에 행위를 갖습니다.
3.2 값은 독립적 실체에 의존해서만 존재가 인식될 필요가 있는 의존적 실체입니다.
3.3 값은 독립적으로 인식될 필요가 없기 때문에 정체성을 갖지 않습니다.
3.4 값은 정체성을 갖지 않기 때문에 상태 또한 갖지 않습니다.
3.5 UML에서는 값을 기본형(primitive), 열거형(enumeration), 데이터값(data value)으로 구분합니다.
프로그래밍 언어이든 모델링 언어이든 기본적으로 제공되는 타입이 있고, 사용자가 정의할 수 있는 타입이 있습니다. 기본적으로 제공되는 타입을 기본타입이라 합니다.
UML은 기본타입으로 정수, 불린, 문자열 등을 제공합니다.
열거형은 색깔이나, 고객구분과 같이 한정된 목록 값에 사용됩니다.
데이터값은 관리를 편하게 하려는 목적으로 의미적으로 가까운 특성들을 하나의 그룹으로 묶은 값입니다.
[RSM 1권 핵심개념] 1장. 실체 I (5.0) 1절. 실체
2절. 객체
2.1 객체는 그 자체로 존재가 인식될 필요가 있는 독립적 실체입니다.
2.2 객체는 실체이기 때문에 행위를 갖습니다.
2.3 그 자체로 존재를 인식할 수 있으려면, 그 놈이 그 놈인 것을 알 수 있어야 합니다.
독립적으로 인식된다는 것은
어떠한 상황에서 그 자체를 지칭할 수 있다는 것입니다.
'이것’, ‘저것’과 같이 지칭했을 때 그것이 무엇인지를 알 수 있는 방법이 있다는 것입니다.
|
우리는 그놈이 그놈인 것을 아는 방법을 자기동일성 또는 정체성(identity)이라고 합니다. |
2.4 객체는 정체성을 갖습니다.
2.5 정체성을 갖는 객체는 여러 개 중에서 선택될 수 있습니다.
두 친구의 해바라기에 대한 이야기를 좀 더 들어봅니다.
“색깔이 참 노랗기도 하네!”
“무슨 색깔?”
“해바라기의 꽃잎 색깔”
“어떤 해바라기”
“저기 키 큰 해바라기”
“아, 저기 저 키 큰 해바라기”
그림 1.2
두 친구는 그림 1.2의 여러 해바라기들 중에서 한 해바라기를 선택했고, 그 해바라기를 지칭하면서 이야기 하고 있습니다.
2.6 변화는 정체성이 전제되어야 합니다.
다음날도 친구인 두 사람이 같은 장소를 지나갑니다.
한 친구가 이렇게 이야기 합니다.
“저 해바라기 꽃잎 색깔이 어제 보다 더 노래졌네.”
어제 본 해바라기의 꽃잎 색깔이 오늘 더 노래졌다고 하려면, 어제 보았던 해바라기와 오늘 본 해바라기가 같은 것이어야 합니다.
오랜만에 친구를 만나서 뒤통수를 치면서 “야! 이놈 많이 변했네!”라고 할 때에도 마찬가지입니다. 지금 내가 뒤통수 친 그놈이 옛날의 내 친구 그놈인지를 알아야만 이렇게 말할 수 있습니다.
2.7 변화 또한 인식되는 것입니다.
2.8 상태 비교를 통해서 변화를 인식할 수 있습니다.
해바라기의 꽃잎 색깔이 변했다고 하려면 어제의 꽃잎 색깔이 어떠했는지, 오늘의 꽃잎 색깔이 어떠한지를 비교할 수 있어야 합니다.
오랜 만에 만난 친구가 변했다고 하려면 변하기 전의 모습은 어떠했는지, 변한 후의 모습은 어떠한지를 비교할 수 있어야 합니다.
|
우리는 객체가 그때 또는 지금 어떠한지를 조건으로 표현한 것을 상태(state)라고 합니다. |
2.9 객체는 상태를 갖습니다.
2.10 비교하려면 비교할 수 있는 값이 있어야 합니다.
해바라기에 대해서 이야기 하던 두 친구 중 한 명이 다음날 다시 그 해바라기를 보고 혼잣말을 합니다.
“어제 보다 더 노래졌네!”
어제의 해바라기 꽃잎 색깔이 노랑이었다면 오늘의 해바라기 색깔은 더 노랑이라는 값입니다.
|
우리는 객체의 상태를 표현하는데 사용되는 값을 객체의 특성(property)이라 합니다. |
2.11 하나의 특성은 여러 개의 값을 가질 수 있습니다.
좋아하는 색깔은 여럿일 수 있습니다.
2.12 다수의 특성을 묶어 하나의 그룹 특성을 만들 수 있습니다.
도서주문이라는 도메인에서 배송을 위한 고객의 우편번호, 기본주소, 상세주소는 주소라는 그룹으로 묶어 관리할 수 있습니다.
|
우리는 그룹 특성으로 사용되는 값을 데이터값(Data Value)이라 합니다. |
[RSM 1권 핵심개념] 1장. 실체(Instance) I (5.0) 시작하기 전에
1절. 실체
1.1 모든 존재하는 것들은 목적을 갖습니다.
존재를 특정 철학에 비추어 설명하면,
우연적이거나 무의미한 존재도 있을 수 있습니다.
그러나 소프트웨어 개발자로서 우리는 이런 실체를 다루지 않습니다.
우리가 다루어야 할 실체는
소프트웨어 시스템 내에서 존재 목적을 갖고 있어야 합니다.
아무 이유 없이 존재한다면 그것은 버그이고, 제거되어야 합니다.
의미 있는 존재라면 아무 이유 없이, 아무 것도 하지 않도록 만들어지지 않습니다. 분명한 존재 목적을 가져야 합니다.
|
우리는 존재목적을 갖고 존재하는 것을 실체(instance)라 합니다. |
바로 바로 답하기
1. 실체에 대한 영문 표기는?
2. 실체란?
존재하는 것
( )을 갖고 존재하는 것
1.2 존재목적을 달성하려면 뭔가를 해야 합니다.
존재목적은 저절로 달성되지 않습니다.
실체가 무엇인가를 해야 합니다.
|
우리는 실체가 존재목적을 달성하기 위해 해야 하는 일을 행위(behavior)라고 합니다. |
1.3 실체는 객체와 값과 링크로 구분됩니다.
그림 1.1
친구인 두 사람이 길을 가면서 대화를 하고 있습니다.
“색깔이 참 노랗기도 하네!”
“무슨 색깔?”
“해바라기의 꽃잎 색깔”
해바라기가 있습니다. 해바라기의 꽃잎 색깔인 노랑도 있습니다. 해바라기도 노랑도 있다는 점에서는 같습니다. 즉, 다 존재하는 겁니다.
근데 이 둘을 따로 떼어 놓고 보면 큰 차이가 있습니다.
해바라기는 그 자체적으로 이 해바라기 저 해바라기 할 수 있습니다. 하지만 해바라기의 색깔에 대해서 이야기 할 때는 먼저 어떤 해바라기인지를 가리켜야 합니다.
|
우리는 어떠한 상황(context)에서 해바라기와 같이 그 자체로 존재가 인식될 필요가 있는 독립적 실체를 객체(object)라고 하고, 노랑과 같이 독립적 실체에 의존해서만 존재가 인식될 필요가 있는 의존적 실체를 값(value)이라고 합니다. |
객체들은 다른 객체들과 연결되어 있습니다.
연결 또한 목적을 갖고 존재하는 것으로 실체입니다.
연결실체입니다.
|
우리는 객체와 객체사이의 연결실체를 링크(link)라고 합니다. |
바로 바로 답하기
1. 실체는 세 가지로 구분된다. 그 세 가지는?
2. 객체와 값과 링크의 영문 표기는?
3. 객체와 값의 차이는?
객체는
( )에서
( ) 존재가 ( ) 있는 ( ) 실체
값은
( )에서
( )에 ( ) 존재가 ( ) 있는 ( ) 실체
4. 링크란?
( )와 ( ) 사이의 ( )
시작하기 전에
이 장은 실체에 대해 아는 것을 목표로 합니다.
좀 더 구체적으로는
1. 객체를 독립적실체로, 값을 의존적실체로, 링크를 객체와 객체를 연결하는 연결실체로 설명할 수 있고,
2. 객체와 값을 구분하여 설명할 수 있어야 합니다.
이 장에서 사용되는 용어들은 다음과 같이 표기됩니다.
우리는 object와 value를 외국어로 간주하고,
object를 객체로,
value를 값으로 표기합니다.
우리는 link를 외래어로 간주하여 링크로 표기합니다.
우리는 identity, state, behavior, property를 외국어로 간주하고,
identity는 정체성으로,
state는 상태로,
behavior는 행위로,
property는 특성으로 표기합니다.
1. 소프트웨어 모델링이란?
2. 무엇을 모델링할 것인가?
3. 소프트웨어 모델링과 소프트웨어 개발 주기
4. 무엇을 알아야 하는가?
5. 구성 및 당부사항
출력 가능한 pdf 버전은 아래 링크에서 다운받을 수 있습니다.
http://rsmer.tistory.com/77
RSM 서문(5.0) 4. 무엇을 알아야 하는가?
RSM 서문(5.0) 3. 소프트웨어 모델링과 소프트웨어 개발 주기
RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?
[1권 핵심개념]에서는 객체모델을 구성하는 핵심요소들에 대한 개념과 표현을 설명합니다.
핵심요소에 대한 용어나 개념은 UML 명세서를 우선시합니다.
모든 핵심요소들은 생성과 사용, 전체와 부분이라는 큰 개념적 틀 속에서 논리적인 연결고리를 가지고 설명됩니다.
[2권 행위형식화]에서는 개념에 투명한 객체모델링 기법인 행위형식화에 대해서 설명합니다.
[3권 소프트웨어 명세]에서는 행위형식화 결과를 어떻게 요구사항과 컴포넌트로 명세할 것인지를 설명합니다.
1. ‘우리’는 NWC 컨설팅과 저자인 김현남을 나타내고, ‘여러분’은 독자를 나타냅니다.
2. 기존의 잘 알려진 개념 정의가 개념 설명에 논리적인 연결고리를 제공하지 않는 경우에는 개념을 새롭게 정의합니다.
3. 영어로 들여온 용어는 외국어와 외래어로 구분해서 표기합니다.
object(객체)와 같이 용어에 대한 적합한 우리말이 있는 경우는 외국어로, 그렇지 않은 경우에는 외래어로 구분합니다.
4. 외국어지만, 우리말에 해당하는 용어가 원래 용어의 뜻을 분명하게 전달하지 못하는 경우에는 외래어로 구분합니다.
5. 복합 용어는 단어와 단어 사이를 붙여 씁니다.
6. 문단을 구분하지 않고 필요하면 행을 구분합니다. 이해를 돕는다면 하나의 문장을 여러 행으로 작성합니다.
7. 글자 색은 특별한 의미를 갖습니다.
주의를 기울여야 하는 중요 부분
주의를 더 많이 기울여야 하는 매우 중요한 부분
사색이 필요할 만큼 지속적인 주의를 필요로 하는 영감을 주는 부분
8. 각 장에 주어진 연습문제와 생각거리에는 답이 주어지지 않습니다.
연습문제는 본문의 내용을 정확히 이해했다면 풀 수 있어야 합니다. 또한 그 풀이에 대해 확신을 가져야 합니다.
자신이 확신을 가질 수 없다면 항상 자신보다 더 경험이 많아 보이고 좀 더 많이 아는 것처럼 보이는 사람이 있을 때 마다 불안해하고 확인을 받아야 합니다.
연습문제에 확신이 가지 않는다면 본문의 내용을 3회 정독합니다. 그래도 문제를 풀 수 없다면 내용에 대한 설명이 부족한 것입니다.
연습문제에 대한 답을 게재하지 않은 이유도 이 때문입니다. 연습문제를 푸신 분들이 어떤 면에서 확신을 갖지 못하는지 알고 그 부분을 보강하기 위한 것입니다.
연습문제를 풀면서 어떤 면에서 어려움을 겪고 있는지를 알려주시면 감사하겠고, 스스로 풀 수 있도록 가이드 해 드리겠습니다.
9. 작성 규칙을 정의해야 할 경우에는 UML 명세에서 사용하는 BNF 방식을 사용했습니다.
non-terminal 키워드는 <>로 에워쌉니다.
terminal 키워드는 ‘ ’로 에워쌉니다.
선택적인 항목이 작성될 경우에는 []를 사용합니다.
다수의 항목에서 선택될 수 있는 항목은 |를 사용합니다.
반복될 수 있는 항목은 항목 뒤에 *를 둡니다.
반복되지만 한 번은 반드시 나타나야 한다면 non-terminal과 []*의 조합을 사용합니다.
그룹으로 묶기 위해서는 ()을 사용합니다.
예) <특성 이름> [‘:’ <데이터타입>] ‘=’ <특성 값>
우리는 소프트웨어모델링에 대한 기존의 다양한 내용들에 대해서 여러분이 다 알기를 원하지도 않고, 그럴 필요도 없다고 생각합니다. 새 술은 새 부대에 담으라는 성경의 이야기처럼 우리는 새 부대를 준비했습니다.
여러분이 어떤 배경을 가지고 있든 여러분이 접한 내용은 우리 또한 이미 접했을 확률이 지극히 높습니다. 그럼에도 불구하고 기존과는 다른 방식과 내용으로 설명한 것은 기존의 것으로 새로운 내용을 담을 수 없었기 때문입니다. 좀 더 친절하게 비교 설명을 하고 싶은 욕망도 있었지만 불필요한 내용들을 다루어야 하는 부담감이 더 컸습니다.
남이 해 놓은 것은 비판의 대상이 될 수 있고, 정리된 내용이 쉽게 이해되고 간단할수록 별거 아닌 것으로 여겨질 수 있습니다. 사실 이해하기는 그리 쉽지 않을 수도 있습니다. 우리는 소프트웨어 모델링에 미쳐있었습니다. 이 책에서 설명되는 내용은 우리의 지난 십년 이상의 소프트웨어 모델링 경험과 다양한 학문 분야 특히 신학, 철학, 건축학, 소프트웨어공학 지식의 집대성이라 할 수 있습니다.
마음을 열고 스펀지처럼 내용을 빨아들이십시오. 다 빨아들이고 나면, 여러분의 생각을 채우십시오. 받아들일 것은 받아들이고 뱉을 것은 뱉으십시오.
우리는 이 책이 여러분에게 소프트웨어 모델링에 대해서 알려줄 뿐 아니라 더 큰 세상의 지혜를 얻는데 밑거름이 되길 바랍니다.
2004년 2월 NWC컨설팅을 시작하면서,
NWC컨설팅 대표컨설턴트 김현남
RSM 서문(5.0) 3. 소프트웨어 모델링과 소프트웨어 개발 주기
RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?
무엇을 알아야 하는가?
1. 객체모델을 구성하는 구성요소의 정확한 개념과 정확한 표현을 알아야 합니다.
오늘날 대부분의 객체모델링 방법들은 객체모델을 구성하는 구성요소들이 갖고 있는 개념을 정확히 설명하지 못합니다. 10년이 훨씬 더 지난 객체모델링 초기의 불명확한 개념을 그대로 설명하거나, 설명이 어려운 것은 몰라도 된다는 식으로 넘어갑니다.
객체모델은 UML 등장 이후, UML 명세서로 명세 되고 있습니다. 따라서 객체모델을 구성하는 구성요소들에 대한 개념과 표현은 UML 명세서를 따라야 합니다.
2. 개념에 투명한 객체모델링 기법에 대해서 알아야 합니다.
UML 명세서에는 불행하게도 어떻게 객체모델링을 해야 하는지는 명시하지 않고 있습니다. 이러한 이유 때문인지, 오늘날 대부분의 객체모델링 방법들은 개념 따로 기법 따로 움직입니다.
개념과 기법이 따로따로인 이러한 엉터리 객체모델링 방법을 익힌 사람들에게 나타나는 공통된 특징이 있습니다.
모델링을 하고 나서 불안해합니다. 제대로 했는지 자신이 없기 때문에, 자기보다 경험이 좀 더 많거나 잘 알 것 같은 사람에게 자신의 모델이 제대로 된 것인지 묻습니다.
그런 경험의 횟수가 늘면서 모델링은 답이 없다고 생각하게 됩니다. 답이 없기 때문에 경험이 중요하다고 생각합니다.
구성요소에 대한 개념을 분명히 하고, 그 개념의 범위를 벗어나지 않도록 구성된 기법을 익혔다면 검증은 필요 없게 됩니다. 개념 자체가 기법의 올바름을 정당화해줍니다.
이러한 방법을 익힌 사람이라면 동일한 대상에 대해 동일한 결과를 낼 것이기 때문에 경험은 검증에 있어서 중요하지 않게 됩니다. 경험은 속도를 높여줄 뿐입니다.
구성요소의 개념과 기법이 서로 논리적인 연결고리를 갖고, 그 연결고리가 분명하게 설명된다면 소프트웨어 모델링은 경험적인 것이 아니라 논리적인 것이 됩니다.
우리는 ‘소프트웨어 모델링은 논리적인 것이다.’라고 주장합니다.
3. 개발 프로세스에 따른 산출물을 작성할 수 있어야 합니다.
소프트웨어 모델링 결과에 대해 커뮤니케이션하기 위해 선정된 개발 프로세스에 따라 산출물을 작성할 수 있어야 합니다.
RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?
소프트웨어 모델링과 소프트웨어 개발 주기
소프트웨어 개발은 복잡한 문제해결로, 문제해결 과정에 요구되는 모든 단계를 갖습니다.
문제 이해를 위해 문제를 분석합니다. 해결책을 설계합니다. 해결책을 검증하고 구현합니다.
소프트웨어 모델링은 복잡한 대상을 다루는 기술로 소프트웨어 개발 단계의 어떠한 단계라도 복잡하다고 판단되면 모델링할 수 있습니다.
분석가는 복잡한 대상에 대한 분석기술로 모델링을 사용하고,
설계자는 복잡한 대상에 대한 설계기술로 모델링을 사용하고,
검증자나 구현자는 복잡한 대상에 대한 검증이나 구현기술로 모델링을 사용 할 수 있습니다.
무엇을 모델링할 것인가?
문제를 해결하려면 먼저 문제를 이해해야 합니다. 문제를 이해하기 위해서는 어떤 것이 문제에 포함되는지 그렇지 않은지를 구분하기 위해 문제영역을 분명히 해야 합니다. 문제해결을 위해 다루어야 하는 문제영역을 도메인이라고 합니다.
도메인 사실이 모델링 되어야 합니다.
문제를 이해한다는 것은 문제의 구조를 이해하는 것입니다.
문제의 구조를 이해한다는 것은 문제를 구성하는 구성요소들과 그들 사이의 관계를 이해하는 것입니다.
문제를 구성하는 구성요소들과 그들 사이의 관계는 물리적이던 개념적이던 문제영역에 실제로 존재하는 실체입니다.
문제영역의 실체는 도메인 전문가에 의해 표현됩니다.
도메인 전문가는 일반적으로 사람이지만 전문서적이나 표준과 같이 사람이 아닐 수도 있습니다.
사실은 생성되고 사용됩니다.
실체가 도메인에 존재하기 위해서는 도메인에 등장해야 합니다. 실체를 사실로 나타내면 실체의 등장은 사실의 생성에 해당됩니다.
소프트웨어 개발에 있어 아무것도 하지 않는 존재는 버그입니다. 실체는 어디에선가는 꼭 사용되어야 합니다.
도메인 지식이 모델링 되어야 합니다.
사실에 대한 생성과 사용을 소프트웨어적으로 다루기 위해서는 규칙의 형태로 존재해야 합니다. 사실에 대한 생성과 사용에 대한 규칙들을 우리는 도메인 지식이라 합니다.
사실은 생성에 대한 규칙으로 만들어지는 것이기 때문에 사실을 이해한다는 것은 생성에 대한 도메인 지식을 이해하는 것입니다. 따라서 생성에 대한 도메인 지식을 모델링하면 자동적으로 도메인 사실 또한 모델링 되는 것입니다.
문제 이해를 위해 도메인 행위를 모델링 합니다.
사실을 생성하고 사용하는 것은 행위입니다. 따라서 도메인 지식을 모델링한다는 것은 도메인 행위를 모델링하는 것입니다.
해결책 구축을 위한 의사결정을 모델링 합니다.
객체모델은 문제와 해결책에 동일한 사고를 사용함으로 문제를 구성하는 구성요소들을 그대로 해결책을 구성하는 구성요소로 가져올 수 있습니다. 따라서 해결책에서는 실체를 어떻게 구현하고 배치할 것인가에 대한 의사결정만을 모델링하면 됩니다.
