이 장에서는 소프트웨어 설계프로세스를 본격적으로 살펴보기 앞서 공학(engineering)이나 건축과 같은 도메인에서의 설계프로세스를 살펴봅니다.
보통 설계하면 기술설계를 생각합니다. '설계가 환경을 바꾸는 것'이라는 관점을 가져야만 설계에 있어 기술 외에도 다양한 차원의 것들을 고려할 수 있습니다.
외부환경의 변경되면 설계 또한 이에 대응하여 변경되어야 합니다. 이런 관점에서 보면 설계는 의사결정이라기 보다는 sense making이라고 할 수 있습니다.
이런 관점에서 보면, 설계자 또한 환경의 일부가 되기 때문에 설계는 한 개인의 머리에서 나올 수 있는 것이 아닙니다.
설계는 단순히 정형화된 일련의 절차로 가능한 것이 아닙니다. 설계는 중요한 tension들에 대해 대응하는 것입니다.
As I have described it, design is characterized by its responses to its underlying tensions: form and context, the artistic and the analytic, the architect and his client, the activity and its management, the objectworld and the process-world.
설계는 모든 것을 다 아는 상태에서 시작하지 않습니다. 잘 모르는 상태에서 시작합니다. 잘 모르는 상태이니 실패하게 됩니다. 실패는 실패로 끝나지 않고 학습을 유도합니다. 실패를 통해 배웁니다. 학습을 통해 더 많은 것을 알게 되고 그에 따라 성공의 확률은 높아집니다. 성공은 해결책으로 반영됩니다.
RMSer's Page
RSM에서는 이러한 과정에 좀 더 인간적인 특징을 반영하여 대리라는 개념을 사용합니다.
사람들은 자신에게 주어진 상황속에서 문제를 이해하고 해결책을 설계해서 자신이 살아가고 있는 세상을 바꾸어 나갑니다. 이와 같은 이유로 설계과정의 상황성에 대해서 알아볼 필요가 있습니다.
저자는 이를 위해 이 장에서 액티비티 이론(activity theory), 성찰 실천(relective practice), 편향(bias)과 오류(error)와 이성의 역할(the role of the rational)을 살펴봅니다.
then conclude with an examination of bias, error, and the role of the rational.
읽기 쉽지 않은 텍스트 입니다. 액티비티 이론은 다음 두 개의 글을 먼저 읽고 시작하는 것이 좋을 것 같습니다. http://blog.naver.com/gaia92?Redirect=Log&logNo=120049911460, http://bit.ly/IB1Gox
저자는 액티비티 이론을 통해서 무엇을 말하고 싶은걸까?
왜 성찰(reflection)에 대해서 이야기하는가?
기술적 합리성 문제해결 모델에서는 우리가 지식체계를 가지고 특별한 문제에 대해 지식을 합리적으로 적용함으로 문제를 해결할 수 있다고 말합니다. 하지만 실제로 지식은 상황에 대한 대응으로 만들어집니다. 문제를 해결해야 하는 당사자의 이해를 벗어나는 상황이 발생했을 때 성찰을 통해서 상황과의 상호작용을 통해서 문제를 해결해 나갑니다.
왜 이성과 편향과 오류를 이야기 하는가?
인간은 상황에서 편향과 오류를 일으키는 존재입니다.
RSMer's Page
RSM의 전체와 부분, 컬레보레이션과 부분, 전체와 컬레보레이션이 부분의 컨텍스트가 된다는 것, 부분의 역할이 어떻게 주어지는지를 생각하면서 좀 더 깊이 있게 읽으면 좋겠습니다.
액티비티를 다음과 같이 세 수준으로 나누는 것은 인상적입니다.
Activity-Motive, Action-Goal, Operation-Condition(주어진 조건)
설계는 환경을 바꾸는 것입니다. 설계는 사람이 하는 활동으로 인간 환경을 바꾸는 것입니다.
왜 바꿀까요? 뭔가 문제가 있으니까 바꾸려고 하겠죠. 이런 관점에서 보며 설계는 문제에 대한 해결책을 구하는 것이라고 할 수 있습니다.
컴퓨터는 인간이 지식으로 표현할 수 있는 것에 기반하여 구축될 수 있습니다. 정형화된 지식이어야 합니다. 결국 우리는 소프트웨어를 개발하기 위해서 인간 지식의 성질을 알아야만 합니다.
이 장은 다양한 관점들(인지과학, 생태학, 전문성, 복잡성)을 가지고 인간의 문제해결에 대해서 살펴봅니다. 또 내용이 어려워 집니다. 저자는 여기서 다루는 것들에 대한 해결책으로 adaptive design을 제시합니다. 여기서 복잡하게 각각을 자세히 다루기 보다는 3부에서 필요한 부분만 취해서 이해하는 것이 더 쉬워보입니다.
RSMer's Page
컴퓨팅 기술에 대한 이해는 컴퓨터 이전에 있던 기술에 대한 경험을 기반으로 합니다. 이러한 이유로 소프트웨어는 컴퓨터 이전의 다른 제품들과 비교했을 때 타고난 유연성을 가졌음에도 불구하고 다른 제품을 만드는 방법과 유사하게 개발되어왔습니다.
소프트웨어 개발 방법은 기존의 방법들과는 다른 소프트웨어의 타고난 유연성을 적극적으로 활용하는 개발 방법이 요구됩니다. 저자는 이러한 개발 방법으로 adaptive design을 언급합니다.
소프트웨어는 환경을 바꾸기 위해 개발됩니다. 따라서 소프트웨어 설계에 있어 환경에 대한 고려가 있어야 합니다. 전통적인 설계방식은 technological design라고 합니다. 환경을 고려한 설계를 ecological design이라고 합니다.
인류는 근본을 찾기 위한 꿈을 가지고 있습니다. 그러나 그것은 단지 꿈일 뿐입니다. 우리가 아는 지식은 인식에 의한 것으로 인식의 컨텍스트를 갖습니다. 우리가 해야 할 최선은 아는 것을 더 정제하고 향상시키는 것입니다. 그것이 허용될 때 까지...
이후의 장들에서는 어떤 내용을 다룰까?
RSMer's Page
저자가 이 내용을 설명하기 위해 인용하는 Herbert Dreyfus 교수의 홈페이지가 있습니다. http://socrates.berkeley.edu/~hdreyfus/
이 내용과 관련해서 좀 더 깊이 있는 생각을 해 볼 필요가 있습니다. RSM의 다음 내용을 다시 한 번 깊이 있게 읽어보시기 바랍니다. http://umlcert.tistory.com/608
3장까지가 1부를 구성합니다. 1부의 목적은 새로운 설계의 시대에 필요한 통찰을 얻기 위해 과학과 기술에 대해 살펴보는 것입니다. 2장에서는 과학에 대해서 살펴보았고, 이번 장에서는 기술에 대해서 살펴볼 것입니다.
전통적인 관점에서는 과학이 지식을 발견하고, 기술이 그 지식을 적용하는 것으로 과학과 기술의 관계를 설명합니다.
오늘날에는 과학과 기술의 이러한 관계는 의심을 받기 시작합니다. 과학은 발견만 하는 것이 아니라 설계도 하고, 기술은 설계만 하는 것이 아니라 발견도 합니다.
Both physics and engineering science are discovery processes; the former is concerned with the natural phenomena of interest to the scientific community, and the latter concentrates on manmade and natural phenomena as they affect the artifacts to be designed. There is no division between the two categories of knowledge, and both disciplines engage in design. For science, it is design for discovery, and for technology it is discovery for design. Mirror-image twins.
저자는 과학의 목적은 실체에 대한 모델을 만드는 것이라고 합니다. 과학과 기술을 다른 것으로 보지 않기 때문에 이 둘의 목적은 모델을 만드는 것이라 할 수 있다고 합니다.
전통적인 관점에서의 과학은 수학과 논리에 의존해서 행할 수 있는 매우 좁은 범위의 실체에 대해 모델링해왔습니다. 소프트웨어 개발은 수학과 논리로 표현할 수 없는 모호한 부분 또한 모델링해야 하기 때문에 과학모델보다 더 나은 것을 찾아야 합니다.
RSMer's Page
멋지긴 한데 읽어내기는 쉽지 않습니다.
읽어내는데 너무 시간이 걸리면 정리된 내용만 확인하시고 넘어가셔도 됩니다.
저자는 두 가지 관점에서 과학을 다룹니다. 하나는 철학으로서의 과학이고 다른 하나는 인간제도로서의 과학입니다. 이장은 첫 번째 관점을 다루는 부분입니다. 두 번째 관점은 2부에서 다룹니다.
저자는 왜 과학에 집착하는 걸까?
The process begins with an idea, a concept, something that may defy a complete description, and it ends with the delivery of a formal model that executes in the computer. As we have seen, there is a fundamental tension in this transformation, a tension between what we want and how we make it work, between the requirements in the world and their realization in the computer, between the subjective and the objective, the conceptual and the formal. This book seeks to resolve that tension.
Science faces a similar problem, and so I start by examining its solutions. Science begins with something very complex and poorly represented—the real world—and its goal is to describe aspects of that reality with theories and models. We know that science is successful. It is reasonable to look, therefore, into its strengths and limitations for insight into resolving the software process' central tension.
왜 과학철학인가?
본문의 내용은 안 읽고 가는 것이 정신 건강에 좋을 것 같습니다. 이번 기회에 과학철학에 대해 관심을 가졌고, 그와 관련된 책 한 권 정도 읽은 것으로 만족하고 넘어가겠습니다.
과학철학을 살펴본 저자의 결과는 무엇인가?
RSMer's Page
소프트웨어 개발은 생성과 사용에 대한 것입니다. 문제영역인 도메인은 사용의 관점을 강조하고, 해결책 영역인 소프트웨어는 생성의 관점을 강조합니다. 저자가 말하는 tension은 생성과 사용이 무엇인지를 알고 그들이 어떻게 관련되는지를 알면 해소됩니다.
초창기에 비해 저자의 시대에도 computing은 매우 다르게 변해 있었고, 그 다음 50년에는 더 큰 변화가 있을 것입니다. computing은 세상을 바꾸고 있습니다. 저자는 특히 설계에 있어서의 변화에 주목합니다.
object; rather, it is the design of an object.
저자는 다음 50년을 준비합니다. 지금의 소프트웨어 개발 방법으로는 안된다고 생각합니다. computing이 급변하는 만큼 소프트웨어 개발 방법도 급변해야 된다고 생각합니다. 패러다임의 변화에 해당하는 변화가 있어야 된다고 합니다.
패러다임의 변화를 위해서는 기초부터 다시 세워야 합니다. 저자는 과학과 기술로 출발해서 컴퓨터 과학과 소프트웨어 공학을 살펴보려고 합니다.
science.
Once we agree on the essence of science, we then can determine its relationship to technology. From this we may derive a working appreciation of software engineering and its relation to computer science. Recall that my goal is to alter the process of design, which will restructure software engineering and perhaps even invalidate portions of computer science. The questions are, Is this possible, and, if yes, will we need a new computer science?
과학이 무엇인지를 살피다보니 과학철학으로 들어가게 됩니다. 1.3절 'An Engineering Discipline of Software' 부터는 과학철학에 대한 이해를 갖고 있다면 좀 더 쉽게 읽어낼 수 있습니다. 과학철학은 제가 잘 모르는 부분이기에 이 책을 이해하는데 어려움을 겪었습니다. 그래서 제임스 레디먼의 과학철학의 이해라는 책을 읽었습니다.
과학철학에 대한 내용은 본격적으로 2장과 3장에 등장합니다. 2장과 3장으로 들어가기 전에 과학철학에 대한 책을 하나 정도는 읽고 들어가는 것이 좋을 것입니다.
저자는 새로운 설계의 시대에 어떻게 설계를 하고자 하는 것일까요? 다음 대목은 그것을 알 수 있게 해주는 부분입니다.
I believe that software has unique features that, once exploited, will permit us to employ a better model, which I call adaptive design. Rather than relying on the two-step process of first create a specification in-the-world and then realize that specification in-the-computer, I see a one-step process that permits us to model what goes on in-the-computer as it affects us in-the-world. In this way we go beyond programming (in-the-computer) and concern ourselves only with how the programs behave in-the-world.
RSMer's Page
그에 비해, RSM은 도메인은 대부분 formal하고, 약간의 informal한 부분이 있다고 말합니다. 대부분 informal하게 보이는 것은 표현 방식이 달라 formal한 것이 informal하게 보이기 때문입니다.
RSM은 저자가 말하는 tension을 무효화시키기 때문에 tension을 줄이려는 노력이 필요없게 됩니다.
프롤로그는 저자가 왜 이렇게 책을 구성했는지를 알 수 있게 합니다.
저자는 자신을 소프트웨어 공학자라고 소개하고 있습니다.
소프트웨어 공학자는 소프트웨어를 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 읽고 고민하다보면 많은 깨달음을 줄 것입니다.
본격적으로 들어가기에 앞서, 이 책 전반에 걸쳐 등장하는 개념들을 다룹니다.
우리는 이 부분을 읽으면서 다음과 같은 질문에 대한 답을 얻으려고 노력해야 합니다.
아키텍처 뷰? 아키텍처 스타일?
잘 된 아키텍처 문서화?
소프트웨어 아키텍처?
아키텍처는 아직까지 하나의 통일된 정의를 갖지 못하고 있습니다. SEI 웹사이트에 150개가 넘는 정의를 수집해놓았다고 합니다. 이 책에서는 2003년에 출판된 Bass, Clements, Kazman의 Software Architecture in Pranctice 2nd ed의 정의와 비슷한 정의를 사용한다고 합니다.
By “externally visible properties,” we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. (Bass, Clements, and Kazman 2003, p. 27)
이 정의의 어떤 점이?
These structures, carefully chosen and designed by the architect, are the key to achieving and reasoning about the system’s design goals. And those structures are the key to understanding the architecture.
Therefore, they are the focus of our approach to documenting a software architecture.
Structures consist of elements, relations among the elements, and the important properties of both. So documenting a structure entails documenting those things.
아키텍처를 처음 접하는 분들이 많이 하는 질문 중의 하나는 '아키텍처와 설계가 어떻게 다른가"입니다.
저자는 이 부분에 대해서 명쾌한 설명을 합니다.
The architect draws the boundary between architectural and nonarchitectural design by making
those decisions that need to be bound in order for the system to meet its development, behavioral, and quality goals. All other decisions can be left to downstream designers and implementers.
Decisions are architectural or not, according to context. If structure is important to achieve your system’s goals, that structure is architectural.
But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.
다음과 같은 충고도 새겨 둘 만 합니다.
Try “nonarchitectural design” instead.
소프트웨어 아키텍처 문서화?
우리는 소프트웨어 아키텍처를 문서화하려고 이 책을 읽고 있기 때문에, 왜 소프트웨어 아키텍처를 문서화해야 하는지에 대해서는 간단히 몇 문장을 인용하고 넘어갑니다. 나중에 누군가를 설득할 필요가 있을 때 다시 이 부분을 읽으면 됩니다.
Fundamentally, architecture documentation has three uses.
1. Architecture serves as a means of education.
2. Architecture serves as a primary vehicle for communication among stakeholders.
3. Architecture serves as the basis for system analysis and construction.
아키텍처 뷰?
아키텍처는 한 번에 이해할 만큼 단순하지 않습니다. 복잡합니다. 다수의 관점을 가지고 다루어야 합니다.
아키텍처 뷰에는 여러가지가 있습니다. 그 중 잘 알려진 것이 4+1 뷰 입니다. 이 책에서는 Module, Component-and-Connector(C&C), Allocation과 같이 3개의 뷰를 제공합니다.
컴포넌트기반개발(CBD)을 경험한 적이 있는 사람이라면, CBD의 컴포넌트와 Module뷰의 모듈과 C&C 뷰의 컴포넌트를 비교하지 않도록 조심해야 합니다. 혼란에 빠질 수 있습니다. Module뷰의 모듈과 C&C 뷰의 컴포넌트에 대해서 알고 둘 사이의 차이를 비교할 수 있으면 됩니다.
아키텍처 스타일?
아키텍처 스타일과 아키텍처 패턴이 어떻게 다른지를 설명하는데, 크게 관심 갖지 않아도 될 것 같습니다. 사실 이 책에서 제시하는 스타일 중에 아키텍처 패턴에서 언급되는 것들이 많이 있습니다.
문서화를 잘하기 위한 7가지 규칙
2. Avoid unnecessary repetition.
3. Avoid ambiguity.
4. Use a standard organization.
5. Record rationale.
6. Keep documentation current but not too current.
7. Review documentation for fitness of purpose.
RSMer's Page
다수의 뷰를 가지고 아키텍처를 다룬다는 것은 모델링 기술을 사용한다는 의미를 담고 있습니다. 복잡한 것을 다수의 관점에 따라 추상화하는 것이 모델링입니다.
2. 아키텍처 결정이 무엇인지에 대해서 다음 문장을 통해 이해하고, 외우고, 입으로 말할 수 있도록 합니다.
Architectural decisions are ones that permit a system to meet its quality attribute and behavioral requirements. All other decisions are nonarchitectural.
