프롤로그는 저자가 왜 이렇게 책을 구성했는지를 알 수 있게 합니다.
저자는 자신을 소프트웨어 공학자라고 소개하고 있습니다.
소프트웨어 공학자는 소프트웨어를 develop하고 maintain합니다.
저자는 소프트웨어 공학자로서 어떻게 소프트웨어를 develop하고 maintain해야 하는지에 대한 답을 찾기 위해 노력했고, 그 결과가 이 책입니다.
소프트웨어에 대한 다음과 같은 저자의 인식은 그가 왜 설계에 초점을 맞추는지를 알게 합니다.
저자는 근본 원리를 찾고 싶어 했던 것 같습니다.
무엇인가를 절실히 찾는다는 것은 현재 상황에 불만이 있다는 것입니다. 저자는 당시의 소프트웨어 개발 방식을 확 바꿔 버려야 된다고 생각했을 것입니다. ‘주먹구구식으로는 안 돼!’라고 말하고 싶었을 것입니다.
근본원리를 찾으려는 노력의 부산물이 이 책의 1부와 2부가 아닌가 생각해 봅니다.
당시의 소프트웨어 공학은 저자가 원하는 것에 초점을 맞추고 있지 못했을 것입니다. 이런 상황에서 저자는 먼저 소프트웨어 공학이 무엇인지를 분명히 정의하고 넘어가야 할 것입니다.
The application of tools, methods, and disciplines to produce and maintain an automated solution to a real-world problem.
소프트웨어 공학을 이야기하다보니 컴퓨터 과학이 등장했을 것입니다. 이로부터 공학과 과학을 다루기 시작했을 것이고, 이에 대한 저자의 지적탐험의 결과가 1부일 것입니다. 1부 내용이 어려운 이유가 다 있습니다.
self-realizing design으로 소프트웨어를 바라보는 저자가 어떻게 소프트웨어를 설계할 것인가에 집중하는 것은 너무도 당연한 일입니다.
저자는 설계의 인간적인 면을 먼저 다룬 후에 소프트웨어 설계를 본격적으로 다룹니다.
The focus is on the human aspects of responding to needs and designing satisfactory responses.
Part III, "Software Design."
RSMer's Page
소프트웨어 개발은 설계를 개발하는 것이고, 소프트웨어를 유지보수하는 것은 설계를 유지보수하는 것입니다.
Bruce I. Blum, Beyond Programming : To a New Era of Design, Oxford University, 1996 제목을 보면 저자는 프로그래밍 하는 것을 넘어서 설계의 시대로 가자고 하는 것 같습니다. 그것은 패러다임의 변화와 같은 것이라고 합니다. 무엇을 어떻게 바꾸자고 하는 것일까요? 이것을 아는 것이 이 책을 읽는 첫 번째 목적이 될 것입니다. 패러다임을 바꾸자고 했기 때문에 그 내용이 거창해질 수밖에 없을 것 같습니다. 책은 다음과 같이 세 부분으로 되어 있습니다. 1부. Science and Technology 2부. Ecological Design 3부. Software Design Each addresses a different set of questions: 1. What is the nature of science and scientific knowledge? 2. What are the human dimensions of design? 2. What is the essence of software engineering? 역시 거창합니다. 1부와 2부 내용은 만만치 않아 보입니다. 더 어렵게 하는 것은 그것이 관심사항이 아니라는 것입니다. 저자는 이것을 알고 3부부터 읽어도 된다고 하는군요. 저자가 1부와 2부를 이렇게 구성한 것은 다 이유가 있어서 일 것입니다. 우리는 정공법을 택합니다. 굴하지 않고 처음부터 하나씩 하나씩 진행하겠습니다. RSMer's Page 읽고 고민하다보면 많은 깨달음을 줄 것입니다.
[RSM 1권 핵심개념] 9장 행위 II 시작하기 전에
1절. 수행조건
1.1 수행조건은 제약으로 표현된 행위수행에 대한 요구사항입니다.
규정이나 규칙의 형태를 띤 요구사항은 직접적으로 수행방법에 반영됩니다.
동일한 요구사항에 대해 동일한 수행방법의 선택이 반복되면 규정이나 규칙으로 정형화됩니다.
품질속성이나 제약사항은 수행방법이 그렇게 될 수밖에 없는 근거가 되는 요구사항입니다.
|
우리는 품질속성과 제약사항을 묶어 비기능요구사항이라 합니다. 비기능요구사항은 RSM 3권. 소프트웨어 명세에서 다룹니다. |
1.2 행위수행에 대한 조건은 행위를 수행하기 전과 행위를 수행하는 중과 행위를 수행한 후에 부여될 수 있습니다.
|
우리는 행위를 수행하기 전에 만족되어야 하는 조건을 선행조건(precondition)이라 합니다.
우리는 행위를 수행하는 중에 만족되어야 하는 조건을 행위불변식(behavioral invariant)이라 합니다.
우리는 행위를 수행한 후에 만족되어야 하는 조건을 후행조건(postcondition)이라 합니다. |
1.3 요구정보에 대한 조건은 선행조건으로 명세 됩니다.
행위를 수행하기 전에 대리자는 의뢰자로부터 요구정보를 받습니다. 요구정보에 잘못이 있으면 행위를 성공적으로 수행할 수 없습니다.
1.4 행위수행 결과에 대한 조건은 후행조건으로 명세 됩니다.
대리자는 의뢰자가 요청한 행위를 수행합니다.
의뢰자가 행위수행의 결과를 요구할 경우에는 행위수행의 결과를 제공해야 합니다.
1.5 요구정보와 수행결과에 대한 요구사항을 제외한 모든 요구사항은 행위불변식으로 명세 됩니다.
1.6 수행조건에는 상태변화가 포함되어야 합니다.
행위수행에 의해 객체의 상태가 바뀔 수 있습니다.
행위수행에 의해 객체의 상태가 바뀐다면
행위수행 전에는 어떤 상태이어야 하는지,
행위수행 중에는 어떤 상태이어야 하는지,
행위수행 후에는 어떤 상태이어야 하는지를 명세해야 합니다.
행위수행 전의 상태는 선행상태로,
행위수행 중의 상태는 행위불변식으로,
행위수행 후의 상태는 후행상태로 명세 됩니다.
사실로 표현된 객체에 있어서 변화는 특성의 변화뿐입니다.
부분을 갖는 전체의 경우, 부분과 부분들 사이의 링크의 생성과 소멸, 부분의 특성 변화를 포함합니다.
시작하기 전에
이 장은 행위에 대해 알아야 하는 추가적인 것들에 대해서 아는 것을 목표로 합니다.
좀 더 구체적으로는
1. 행위명세의 세 가지 구성요소인 요구정보와 수행방법과 수행조건에 대해 좀 더 자세히 아는 것을 목표로 합니다.
이 장에서 사용되는 용어들은 다음과 같이 표기됩니다.
우리는 precondition, postcondition, invariant를 외국어로 간주하고, 각각을 선행조건, 후행조건, 불변식으로 표기합니다.
출력 가능한 pdf 버전은 아래 링크에서 다운받을 수 있습니다.
http://rsmer.tistory.com/73
[RSM 1권 핵심개념] 8장 행위 I 2. 대리된 일로서의 행위
[RSM 1권 핵심개념] 8장 행위 I 한 번 더 생각해 볼 것들
[RSM 1권 핵심개념] 8장 행위 I 4. 그래픽 표현
마치기 전에
그동안 우리는 행위에 대해서 너무나 단순하게 알아왔습니다.
행위는 구조를 결정할 만큼 중요한 요소이고, 모델요소들의 대부분은 행위와 관련된 부분입니다.
소프트웨어모델링은 행위에서 시작해서 행위로 끝난다고 할 수 있습니다. 아이러니하게도 행위에 대한 설명은 다른 기본개념을 설명하고 난 마지막에 가능합니다.
다음 사항을 확인하고 넘어갑니다.
대리 개념으로 행위를 설명하고, 행위명세의 구성에 대해 설명합니다. 제대로 말할 수 없는 부분은 다시 살펴봅니다.
다음 장에서는 행위에 대한 추가적인 이야기들을 다룹니다.
[RSM 1권 핵심개념] 8장 행위 I 2. 대리된 일로서의 행위
[RSM 1권 핵심개념] 8장 행위 I 한 번 더 생각해 볼 것들
4절. 그래픽 표현
4.1 오퍼레이션
다음과 같은 형식으로 작성합니다. 세부적인 표현은 속성 표현과 같습니다.
|
가시성 이름 ( 매개변수목록 ) : 리턴타입 다중성 { 특성문자열 } 예) + move(lastPoint: PointF) : PointF |
매개변수목록의 매개변수는 다음과 같은 형식으로 작성됩니다.
|
입출력방향 이름 : 타입 다중성 = 기본값 { 특성문자열 } |
입출력 방향
입력은 in, 출력은 out, 입출력은 inout을 사용합니다. in은 기본값입니다.
추상 오퍼레이션
추상 오퍼레이션은 추상 클래스와 같이 이름 부분이 이탤릭체로 표현됩니다.
4.2 유스케이스
그림 8.9와 같이 타원으로 표현합니다.
그림 8.9
UML에서는 사용자의 역할을 액터라고 합니다.
액터는 그림 8.10과 같이 막대사람 아이콘 아래에 액터 이름을 작성합니다.
그림 8.10
UML에는 행위를 명세할 수 있는 다양한 모델요소와 다이어그램을 제공합니다.
[RSM 1권 핵심개념] 8장 행위 I 2. 대리된 일로서의 행위
한 번 더 생각해 볼 것들
1. 의뢰자는 요구정보를 채워주기 위해 대리자를 사용합니다.
사용이란 것은 거창한 무엇이 아닙니다.
요구정보가 결정되며 대리자를 어떻게 사용할 것인지가 결정됩니다.
2. 대리자는 원래 의뢰자입니다.
대리자의 행위는 원래 의뢰자 행위의 일부였습니다. 대리자의 행위를 사용할 때만으로 국한해서 생각해보면 대리자와 의뢰자는 같은 것입니다.
3. 도메인 작업자는 소프트웨어 시스템의 사용자와 소프트웨어 시스템의 컴포넌트가 됩니다.
소프트웨어 시스템 개발은 도메인 행위를 소프트웨어 시스템에게 대리하는 것입니다. 도메인 행위는 도메인 작업자들에 의해 수행됩니다.
도메인 작업자의 행위에서 소프트웨어 시스템으로 대리할 수 있는 일과 대리할 수 없는 일을 구분합니다. 대리할 수 없는 일을 위해서 도메인 작업자는 소프트웨어 시스템의 사용자가 됩니다. 도메인 작업자는 소프트웨어 시스템을 사용하여 소프트웨어 시스템이 대리한 행위를 수행하기 위해 요구하는 정보를 채워줍니다.
소프트웨어 시스템으로 대리한 행위는 소프트웨어 시스템의 컴포넌트가 수행합니다. 대리자는 원래 의뢰자이기 때문에 시스템 컴포넌트는 도메인 작업자입니다.
경매담당자라는 도메인 작업자가 있고, 경매담당자의 행위 일부는 대리가능하고 일부는 대리가능하지 않다면, 소프트웨어 시스템의 사용자와 컴포넌트는 경매담당자가 됩니다.
[RSM 1권 핵심개념] 8장 행위 I 2. 대리된 일로서의 행위
3절. 행위명세
3.1 행위는 요구정보와 수행방법과 수행조건으로 명세 됩니다.
행위를 명세 한다는 것은
대리 가능한 형태의 행위 수준에서
행위의 모든 것에 대해서 설명하는 것입니다.
그림 8.8
하나의 행위는 의뢰자의 책임과 대리자의 책임으로 이루어집니다.
의뢰자는 대리자가 행위수행을 위해 요구하는 것(요구정보)을 제공해야 하고, 대리자에게 행위수행을 요청해야 합니다.
대리자는 의뢰자가 요청한 행위를 수행방법에 따라 수행하고, 행위수행의 결과를 제공해야 합니다.
행위수행에는 제약사항이 수행조건으로 요구될 수 있습니다.
|
그림 8.8에서 타원은 행위를 나타냅니다. 이 행위의 주변에 수행조건이 감싸고 있습니다. 행위는 요구정보와 수행방법으로 나누어져 있습니다.
행위는 요구정보와 수행방법으로 구성되고, 요구정보와 수행방법은 수행조건을 만족하도록 명세 되어야 합니다. |
3.2 행위명세는 방법론에 따라 다양한 이름을 갖습니다.
UML에서는 클래스의 행위명세를 오퍼레이션(operation)이라 합니다. 객체가 시스템 수준일 때, 목적행위에 대한 행위명세를 유스케이스(use case)라 합니다.
오퍼레이션은 행위명세를 함수로 표현한 것입니다.
[RSM 1권 핵심개념] 8장 행위 I 2. 대리된 일로서의 행위
한 번 해보기
두 사람이 짝을 이루어 한 사람은 의뢰자를 한 사람은 대리자 역할을 합니다.
의뢰자는 대리자에게 명령을 내리는 것처럼 대리를 시킵니다.
대리자는 의뢰자가 요청한 일을 할 수 있으면 얌전히 일을 하고 결과를 알려줍니다. 만약 의뢰자로부터 받은 요구정보와 정해진 수행방법으로 대리를 할 수 없다면 “뭐!, 어떻게 하라고”와 같이 강하게 반박합니다.
온라인 서점에 서평 쓰는 일을 대리시켜 봅니다.
의뢰자는 대리자에게 ‘서평 등록해줘’라고 합니다.
대리시키는 것이 쉽지는 않습니다.
아래 그림에서 의뢰자는 땀을 뻘뻘 흘리고 있습니다. 대리시키는 것이 쉽지 않습니다. 대리를 잘 못 시키면 대리자로부터 당장 반박 들어옵니다.
대리자에게 “서평 등록해줘”라고 하면, 아마도 대리자는 여러분의 얼굴을 빤히 쳐다보기만 할 것입니다. 그리곤 반박을 시작합니다.
여러분이 대리자가 자기 마음대로 온라인 서점을 선택하고, 아무 책이나 골라서 아무렇게나 서평을 작성하도록 하는 것을 원하지 않을 것입니다. 물론 그렇게 하고 싶다면, “서평 등록해줘”라고 한 마디만 하면 됩니다.
대리자의 반박에 따라, 아래 그림과 같이 대리자가 필요로 하는 정보를 알려줍니다.
아마도 여러분의 대리자는 여기까지 하고 나서도 “어디에 서평을 등록하라는 거야?”와 같이 서평을 등록하지 못하고 반박을 할 수도 있습니다.
우리의 대리자는 어떤 온라인 서점에 등록해야 하는지를 수행방법으로 알고 있었기 때문에 아무런 반박도 하지 않았습니다.
