BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
195,318 Visitors up to today!
Today 34 hit, Yesterday 86 hit
daisy rss
'출판/RSM'에 해당되는 글 7건
2013.06.17 13:59

http://www.umlcert.com/product/rsm/preface


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2013.06.17 13:49

리얼소프트웨어모델링

Real Software Modeling


Initial Version(2004/02)
Version 6.0(2013/06)

 

 

 

 

 

 

 

NWC컨설팅

대표 컨설턴트 김현남

http://www.umlcert.com

kimhn@umlcert.com, @smarteasy

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.03.06 12:33

시작하기 전에

1. 팩트

2. 객체의 그래픽 표현

3. 객체의 팩트 표현

4. 객체의 프로그래밍 언어 표현

5. 링크

6. 링크의 그래픽 표현

7. 링크의 팩트 표현

8. 링크의 프로그래밍 언어 표현

9. 객체 다이어그램 작성

 

연습 1

다음은 팩트 표현입니다.

이에 대한 객체다이어그램을 작성합니다.

 

Poll, Justine, Tom, MaryPeople이다.

JustinePollTomteamLeader이고,

PollTomJustineteamMember이다.

JustineMaryhusband이고, MaryJustinewife이다.

 

연습 2

다음은 도메인 사실에 대한 객체다이어그램입니다.

이를 팩트 표현으로 작성합니다.

 

 




한 번 더 생각해 볼 것들

1.
객체 다이어그램은 도메인의 사실을 그래픽으로 표현한 것입니다.
도메인 전문가들이 문제영역을 객체, 값, 링크와 같은 것으로 설명해줄 것이라고 기대하기는 어렵습니다. 그들은 문장으로 구조화된 도메인에서 유효한 사실들을 우리에게 설명해줍니다.
우리는 객체지향으로 해결책을 구현할 것이기에 그들이 설명하는 사실을 가지고 객체, 값, 링크와 같은 개념으로 구조화해야 합니다.

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.02.23 16:57

RSM 서문(5.0) 4. 무엇을 알아야 하는가? 
RSM 서문(5.0) 3. 소프트웨어 모델링과 소프트웨어 개발 주기

RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?


리얼소프트웨어모델링은 앞에서 언급한 소프트웨어 모델링을 하기 위해 알아야 하는 3가지에 맞추어 총 3권으로 구성됩니다.  

[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컨설팅 대표컨설턴트 김현남

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.02.23 16:55

RSM 서문(5.0) 3. 소프트웨어 모델링과 소프트웨어 개발 주기
RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?


무엇을 알아야 하는가?

1. 객체모델을 구성하는 구성요소의 정확한 개념과 정확한 표현을 알아야 합니다.

오늘날 대부분의 객체모델링 방법들은 객체모델을 구성하는 구성요소들이 갖고 있는 개념을 정확히 설명하지 못합니다. 10년이 훨씬 더 지난 객체모델링 초기의 불명확한 개념을 그대로 설명하거나, 설명이 어려운 것은 몰라도 된다는 식으로 넘어갑니다.

객체모델은 UML 등장 이후, UML 명세서로 명세 되고 있습니다. 따라서 객체모델을 구성하는 구성요소들에 대한 개념과 표현은 UML 명세서를 따라야 합니다.

2. 개념에 투명한 객체모델링 기법에 대해서 알아야 합니다.
UML 명세서에는 불행하게도 어떻게 객체모델링을 해야 하는지는 명시하지 않고 있습니다. 이러한 이유 때문인지, 오늘날 대부분의 객체모델링 방법들은 개념 따로 기법 따로 움직입니다.

개념과 기법이 따로따로인 이러한 엉터리 객체모델링 방법을 익힌 사람들에게 나타나는 공통된 특징이 있습니다.
모델링을 하고 나서 불안해합니다. 제대로 했는지 자신이 없기 때문에, 자기보다 경험이 좀 더 많거나 잘 알 것 같은 사람에게 자신의 모델이 제대로 된 것인지 묻습니다.
그런 경험의 횟수가 늘면서 모델링은 답이 없다고 생각하게 됩니다. 답이 없기 때문에 경험이 중요하다고 생각합니다.

구성요소에 대한 개념을 분명히 하고, 그 개념의 범위를 벗어나지 않도록 구성된 기법을 익혔다면 검증은 필요 없게 됩니다. 개념 자체가 기법의 올바름을 정당화해줍니다.
이러한 방법을 익힌 사람이라면 동일한 대상에 대해 동일한 결과를 낼 것이기 때문에 경험은 검증에 있어서 중요하지 않게 됩니다. 경험은 속도를 높여줄 뿐입니다.

구성요소의 개념과 기법이 서로 논리적인 연결고리를 갖고, 그 연결고리가 분명하게 설명된다면 소프트웨어 모델링은 경험적인 것이 아니라 논리적인 것이 됩니다.
우리는 ‘소프트웨어 모델링은 논리적인 것이다.’라고 주장합니다.

3. 개발 프로세스에 따른 산출물을 작성할 수 있어야 합니다.
소프트웨어 모델링 결과에 대해 커뮤니케이션하기 위해 선정된 개발 프로세스에 따라 산출물을 작성할 수 있어야 합니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.02.23 16:45

RSM 서문(5.0) 2. 무엇을 모델링할 것인가?
RSM 서문(5.0) 1. 소프트웨어 모델링이란?



소프트웨어 모델링과 소프트웨어 개발 주기
소프트웨어 개발은 복잡한 문제해결로, 문제해결 과정에 요구되는 모든 단계를 갖습니다.
문제 이해를 위해 문제를 분석합니다. 해결책을 설계합니다. 해결책을 검증하고 구현합니다.

소프트웨어 모델링은 복잡한 대상을 다루는 기술로 소프트웨어 개발 단계의 어떠한 단계라도 복잡하다고 판단되면 모델링할 수 있습니다.

분석가는 복잡한 대상에 대한 분석기술로 모델링을 사용하고,
설계자는 복잡한 대상에 대한 설계기술로 모델링을 사용하고,
검증자나 구현자는 복잡한 대상에 대한 검증이나 구현기술로 모델링을 사용 할 수 있습니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.02.23 11:13
RSM 서문(5.0) 1. 소프트웨어 모델링이란?


엇을 모델링할 것인가?

문제를 해결하려면 먼저 문제를 이해해야 합니다. 문제를 이해하기 위해서는 어떤 것이 문제에 포함되는지 그렇지 않은지를 구분하기 위해 문제영역을 분명히 해야 합니다. 문제해결을 위해 다루어야 하는 문제영역을
도메인이라고 합니다.

도메인 사실이 모델링 되어야 합니다.
문제를 이해한다는 것은 문제의 구조를 이해하는 것입니다.
문제의 구조를 이해한다는 것은 문제를 구성하는 구성요소들과 그들 사이의 관계를 이해하는 것입니다.
문제를 구성하는 구성요소들과 그들 사이의 관계는 물리적이던 개념적이던 문제영역에 실제로 존재하는 실체입니다.
문제영역의 실체는 도메인 전문가에 의해 표현됩니다.
도메인 전문가는 일반적으로 사람이지만 전문서적이나 표준과 같이 사람이 아닐 수도 있습니다. 


사실은 생성되고 사용됩니다.
실체가 도메인에 존재하기 위해서는 도메인에 등장해야 합니다. 실체를 사실로 나타내면 실체의 등장은 사실의 생성에 해당됩니다.
소프트웨어 개발에 있어 아무것도 하지 않는 존재는 버그입니다. 실체는 어디에선가는 꼭 사용되어야 합니다.

도메인 지식이 모델링 되어야 합니다.
사실에 대한 생성과 사용을 소프트웨어적으로 다루기 위해서는 규칙의 형태로 존재해야 합니다. 사실에 대한 생성과 사용에 대한 규칙들을 우리는 도메인 지식
이라 합니다.

사실은 생성에 대한 규칙으로 만들어지는 것이기 때문에 사실을 이해한다는 것은 생성에 대한 도메인 지식을 이해하는 것입니다. 따라서 생성에 대한 도메인 지식을 모델링하면 자동적으로 도메인 사실 또한 모델링 되는 것입니다.

문제 이해를 위해 도메인 행위를 모델링 합니다.
사실을 생성하고 사용하는 것은 행위입니다. 따라서 도메인 지식을 모델링한다는 것은 도메인 행위를 모델링하는 것입니다.

해결책 구축을 위한 의사결정을 모델링 합니다.
객체모델은 문제와 해결책에 동일한 사고를 사용함으로 문제를 구성하는 구성요소들을 그대로 해결책을 구성하는 구성요소로 가져올 수 있습니다. 따라서 해결책에서는 실체를 어떻게 구현하고 배치할 것인가에 대한 의사결정만을 모델링하면 됩니다.


저작자 표시 비영리 변경 금지
신고
Justine | 2012.03.15 10:48 신고 | PERMALINK | EDIT/DEL | REPLY
20110315 변경내용:
'도메인 사실이 모델링 되어야 합니다.' 내용 일부

출력본은 버전 5.1에 반영됩니다.
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바