BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
'AOSA 세미나'에 해당되는 글 10건
2012.10.23 11:52

 

8장과 9장은 The Certified RSMer Candidate인 장회수씨가 정리해 주셨습니다.

정리된 내용은 다음 링크에서 보실 수 있습니다.

http://architect.tistory.com/713, http://architect.tistory.com/714

 

 

HDFS은 이름 그대로 분산 파일 시스템입니다.

컴퓨터 시스템의 중요 자원은 storage와 computation이니, 이를 분산시키고자 하는 노력은 당연한 것입니다. 무엇을 해야 할지 모두 알고 있는 상황에서는 어떻게 할 것인가가 경쟁의 승자를 결정합니다. 

어떻게는 제약 내에서 결정되어야 합니다. 현실은 이상이 아니고 항상 제약이 존재하기 때문입니다.

복잡하고 큰 시스템에서의 어떻게는 구조로 반영됩니다. 어떻게 하겠다는 것은 어떤 구조를 가지고 하겠다는 것입니다. 아키텍처링은 어떻게에 대한 중요한 구조적 의사결정을 하는 것입니다.

HDFS의 중요한 특징은 파일 시스템 메타데이터와 애플리케이션 데이터를 분리해서 저장하는 것입니다. 이러한 구조는 우연한 것이 아닙니다. HDFS가 분산시스템에 주어진 시대적 제약을 잘 이해했고 이를 구조적으로 반영한 결과인 것입니다. 

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

 

이번 장에서는 7.10. Design Reflections을 중심으로 진행합니다. 

 

성능 문제에 부딪혔을 때, 서투른 성능 최적화 보다는 설계를 향상시킬 수 있는 방법을 찾아라.

성능 문제에 부딪혔을 때, 이것을 단순히 성능 문제로 보고 성능을 최적화하는데 중점을 두면 얼마 안가서 한계에 부딪힙니다. 낮은 설계 수준에서 서투른 최적화는 좀 더 복잡한 성능 문제에 부닺혔을 때 옴짝달싹 못하게 만드는 원인이 될 수 있습니다.

I have run into many bottlenecks along the way but each time I look for improvements in design rather than speed-ups in performance. Donald Knuth famously said that premature optimization is the root of all evil.

 

문제를 예측하여 해결하려고 하지 말고, 문제가 생기면 그 때 해결하려고 해라.

미래는 우리의 예측을 벗어난 수준에서 변하기 때문에 예측이란 것은 맞지 않는게 기본입니다. 예측하지 않았을 경우 큰 위험에 처할 수 있는 것이라면 예측으로 인한 비용을 발생키기지 말고 빨리 현실화해야 합니다.

예측을 한다는 것은 아직 경험이 부족하다는 것입니다. 경험이 부족한 상태에서 예측을 하고 해결책을 계획하는 것입니다. 따라서 예측대로 문제가 일어나도 계획한 해결책이 드러맞지 않게될 가능성이 대단히 높습니다. 

물론 예측하지 않아 문제가 되기도 합니다. 처음 생각한 API가 시간이 지날 수록 맞지 않는 것으로 들어날 수 있다. 그래서 변화를 전제로 하는 소프트웨어 개발의 경우 버전에 대한 고려가 초기부터 이루어져야 한다.

버전에 대한 고려만으로 문제를 해결하기 어려운 시점도 옵니다. 개인적인 생각으로는 현재 버전의 아키텍처가 더이상 변화를 수용하기 어려운 시점이 오면 그때에는 이전 버전에 대한 고려 없이 아키텍처를 재구축해야 한다고 생각합니다.

However it can be useful to avoid solving problems you do not actually have yet, even if it seems likely that you soon will. The reason is that you can learn much more from closely studying actual failures than from theorizing about superior strategies. Problem solving is driven by both the empirical data we have at hand and our own knowledge and intuition. I've found that doubting your own wisdom sufficiently can force you to look at your empirical data more thoroughly.

 

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

 

이번 장에서는 CMake를 다룹니다. 아키텍처링에 대한 글이라고 하지만 소개글 정도 수준입니다. 그냥 생략하고 다음 장으로 넘어가고 싶습니다. 그래도 뭐든 건져보자는 생각으로 Lessons Learned을 간단히 정리하는 수준에서 진행합니다. 

 

1. Backwards Compatibility

소프트웨어는 한 번 개발되고 끝나는 것이 아니라 계속적으로 진화해야 합니다. 진화의 과정에서 어떤 경우에는 이전 버전과는 구조적으로 큰 차이를 보일 정도의 변화를 겪을 수 있습니다. 이때 문제가 될 수 있는 것이 이전 버전과의 호환성입니다. 특히 API를 변경하거나 파일이나 데이터베이스의 저장 구조를 바꾸고자 할 경우 고민이 커집니다.

개발 초기부터 이전 버전과의 호환성에 대비하기 위해 API나 파일 또는 데이터베이스에 버전 정보를 갖도록 하는 것이 좋습니다.

2. Language, Language, Language

소프트웨어 내부적으로 사용하는 언어를 만들고 싶을 때가 있을 것입니다. 이미 유사한 목적을 위해 만들어진 언어들이 있을 수 있습니다.

소프트웨어 개발자 입장에서 보면 기존에 존재하는 것들이 불필요한 복잡성을 갖고 있다고 생각할 수 있습니다. 좀 더 단순하고 쉽게 사용할 수 있는 언어를 만들고 싶을 것입니다. 하지만 해당 소프트웨어를 사용하는 사용자 입장에서는 이미 다른 언어를 알고 있는데 그 언어를 새로 배워야 하는 부담을 가질 수 있습니다. 그리고 실제 만든 사람은 쉽다고 생각하지만 배우기에 쉽지 않을 수도 있습니다.

새로운 언어를 만들기에 앞서 이러한 문제를 깊이 생각해야 합니다. 사용자의 학습비용을 생각해야 합니다. 많이 사용하고 있는 언어들을 벤치마킹 할 필요가 있습니다.

3. Plugins Did Not Work

확장 가능한 구조를 만드는 방법들 중 가장 인기있는 것은  Plugin입니다. 좋다고 해서 무조건 쓸 수 있는 것은 아닙니다. 상황에 맞추어 써야 합니다.

4. Reduce Exposed APIs

기능을 많이 갖는 것이 좋아 보이지만 유지보수비용을 생각한다면 꼭 그렇지만은 않습니다. 장식에 해당하는 기능들 중에 유지보수비용을 크게 증가시키는 것들은 제거해야 합니다.  

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

 

이번 장에서 저자들은 Berkely DB 개발과정에서 얻은 14개의 Design Lesson을 제시하고 있습니다. 이번 장에서는 이들 Design Lesson들 중심으로 정리하고자 합니다.

 

Design Lesson 1

It is vital for any complex software package's testing and maintenance that the software be designed and built as a cooperating set of modules with well-defined API boundaries.

기본적으로 변화를 내포하고 있는 소프트웨어 개발에 있어 변화를 좀 더 쉽게 다루기 위해서는 자주 변하는 것과 그렇지 않은 것을 구분하는 것은 필수적인 것입니다.

심적으로 무엇을 해야 할 것인가는 쉽게 바뀌지 않겠지만 어떻게 해야 할 것인가는 기술의 변화에 따라 쉽게 바뀔 수 있습니다. 그래서 What과 How를 구분해야 합니다. What은 하나일 수 있으나 How는 여럿 있을 수 있습니다. What은 인터페이스이고 How는 구현입니다. 애플리케이션의 인터페이스에 해당하는 API를 잘 정의하는 것은 그래서 중요합니다.

 

Design Lesson 2

A software design is simply one of several ways to force yourself to think through the entire problem before attempting to solve it.

Regardless of the technique used, it's difficult to think clearly about program architecture after code debugging begins. Software architecture requires a different mind set from debugging code, and the architecture you have when you begin debugging is usually the architecture you'll deliver in that release.

소프트웨어 설계는 문제를 해결하기 위한 의사결정입니다. 의사결정한다는 것은 여러 가지 대안들이 있다는 것을 의미합니다. 여러 대안 중에 하나를 선택하기 위해 선택에 대한 의사결정을 하는 것입니다.

소프트웨어 개발은 소프트웨어 기술을 사용해서 도메인의 문제를 해결하는 것입니다. 문제를 해결하는 기술은 여럿 있을 수 있습니다. 여러 가지 해결기술 중에 하나를 선택하기 위해 의사결정하는 것입니다. 이러한 의사결정을 공학에서는 설계라고 합니다.

지식산업 종사자들은 모두 의사결정자들이기 때문에 의사결정이 중요합니다. 소프트웨어 개발은 대표적인 지식산업입니다. 의사결정들이라고 해서 모두 같은 것은 아닙니다. 어떤 의사결정은 다수의 의사결정들에 영향을 미칩니다. 따라서 의사결정을 분리할 필요가 있습니다. 소프트웨어 개발에서는 아키텍처에 대한 의사결정과 상세설계에 대한 의사결정을 나누고 있습니다.

구현이 시작되기 전에 가정을 통해 내려진 의사결정이 실제 구현과정에서 올바른 것이 되기는 쉽지 않습니다. 따라서 구현이 시작되기 전에 내려지는 의사결정을 위해 너무 많은 시간을 들이는 것은 낭비가 될 수 있습니다.

 

Design Lesson 3
Software architecture does not age gracefully. Software architecture degrades in direct proportion to the number of changes made to the software.

현재의 소프트웨어 아키텍처는 현재까지의 요구사항을 반영한 것입니다. 어느때까지 시간이 지남에 따라 변경되고 추가되는 요구사항들을 모두 잘 담아내는 아키텍처는 있을 수 없습니다. 어느 시점엔가는 재작성이 일어날 수 밖에 없습니다.

 

Design Lesson 4
It doesn't matter how you name your variables, methods, functions, or what comments or code style you use; that is, there are a large number of formats and styles that are "good enough." What does matter, and matters very much, is that naming and style be consistent.

소프트웨어 개발에 있어 코드는 자신이 생각한 것보다 훨씬 더 많이 읽혀 집니다. 읽기 쉬운 코드를 만들면 많은 수의 개발자들의 독해 시간을 줄여줍니다.

일관성은 몸에 익기 까지는 불편합니다. 몸에 일관성이 익혀진 개발자들만이 전문 개발자라고 할 수 있습니다. 일관성이 몸에 익지 않으면 사소한 의사결정을 위해 시간을 낭비해야 하기 때문에 전문적인 생산성을 낼 수 없습니다.

 

Design Lesson 5
Software architects must choose their upgrade battles carefully: users will accept minor changes to upgrade to new releases. But to make truly fundamental changes, you must admit it's a new code base and requires a port of your user base. Obviously, new code bases and application ports are not cheap in time or resources, but neither is angering your user base by telling them a huge overhaul is really a minor upgrade.

아키텍처를 변경시키는 요구사항은 비용이 큽니다. 따라서 아키텍트는 아키텍처를 변경시키는 요구사항과 그렇지 않은 요구사항을 구분할 수 있어야 합니다. 이것을 잘 하지 못하는 아키텍트는 프로젝트 관리자를  궁지로 몰 수도 있습니다.

 

Design Lesson 6
In library design, respect for the namespace is vital. Programmers who use your library should not need to memorize dozens of reserved names for functions, constants, structures, and global variables to avoid naming collisions between an application and the library.

클래스 이름에 특별한 접두어를 사용하는 방식 정도로는 이름 충돌을 제대로 피하기 어렵습니다. 좀 귀찮더라도 네임스페이스를 사용해야 합니다. 이번 레슨은 네임스페이스를 잘 사용하지 않는 C++ 개발자들에게 훌륭한 가르침이 될 것 같습니다.

 

Design Lesson 7
This illustrates three important design principles:

First, if you have functionality that appears more than once, write the shared functions and use them, because the mere existence of two copies of any specific functionality in your code guarantees that one of them is incorrectly implemented.

Second, when you develop a set of general purpose routines, write a test suite for the set of routines, so you can debug them in isolation.

Third, the harder code is to write, the more important for it to be separately written and maintained; it's almost impossible to keep surrounding code from infecting and corroding a piece of code.

 

Design Lesson 8
Write-ahead logging is another example of providing encapsulation and layering, even when the functionality is never going to be useful to another piece of software.

 

Design Lesson 9
Berkeley DB's choice to use page-level locking was made for good reasons.

Page-level locking limits the concurrency of the application as one thread of control modifying a record on a database page will prevent other threads of control from modifying other records on the same page, while record-level locks permit such concurrency as long as the two threads of control are not modifying the same record. Page-level locking enhances stability as it limits the number of recovery paths that are possible.

As Berkeley DB was intended for use as an embedded system where no database administrator would be available to fix things should there be corruption, we chose stability over increased concurrency.

아키텍처는 기능과 비기능에 의해 결정됩니다. 기능에 의해 논리적인 수준의 기능아키텍처가 결정되며, 비기능에 의해 기술아키텍처가 결정됩니다. 기능은 제약이 부여되지 않은 것으로 비기능에 의해 제약이 부여됩니다. 비기능은 제약이며 기술아키텍처는 이 제약을 만족시키는 것입니다. 따라서 기술아키텍처를 결정할 때는 제약에 해당하는 비기능을 중요하게 고려해야 합니다.

 

Design Lesson 10
Rather than adding special purpose code to the lock manager, we were able to create an alternate lock matrix that supported only the lock modes necessary for the API-level locking. 

 

Design Lesson 11
When you find an architectural problem you don't want to fix "right now" and that you're inclined to just let go, remember that being nibbled to death by ducks will kill you just as surely as being trampled by elephants. Don't be too hesitant to change entire frameworks to improve software structure, and when you make the changes, don't make a partial change with the idea that you'll clean up later—do it all and then move forward. As has been often repeated, "If you don't have the time to do it right now, you won't find the time to do it later." And while you're changing the framework, write the test structure as well. 

아키텍처 문제는 미루면 미룰 수록 작업을 더 어렵게 만듭니다. 바로 바로 문제를 해결해야 합니다.

그런데 사람은 미루기를 좋아합니다. 문제가 어렵거나 그 파생효과가 클때는 두려움까지 한 몫을 합니다. 아키텍처 문제는 그 파생효과가 크기 때문에 두려움이 행동하기를 막습니다. 버전관리와 테스트주도형개발은 다시 돌아갈 수 있는 길을 제공하고 어떠한 파생효과가 일어나는지를 드러냄으로 이 두려움을 없애줍니다.

 

Design Lesson 12
Building and maintaining significant pieces of software is difficult and error-prone, and as the software
architect, you must do everything that you can, as early as you can, as often as you can, to maximize the information conveyed in the structure of your software.

 

Design Lesson 13
There is rarely such thing as an unimportant bug. Sure, there's a typo now and then, but
usually a bug implies somebody didn't fully understand what they were doing and implemented the wrong thing. When you fix a bug, don't look for the symptom: look for the underlying cause, the misunderstanding, if you will, because that leads to a better understanding of the program's architecture as well as revealing fundamental underlying flaws in the design itself.

 

Design Lesson 14
Our goal as architects and programmers is to use the tools at our disposal: design, problem decomposition, review, testing, naming and style conventions, and other good habits, to constrain programming problems to problems we can solve.
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.08.06 17:47

 

이번 장은 The Certified RSMer Candidate인 서만수씨가 프레지로 멋지게 정리해 주셨습니다. 

 

정리된 내용은 다음 링크에서 보실 수 있습니다.

http://bit.ly/QEtn9f

저작자 표시 비영리 변경 금지
신고
Mickey | 2012.08.08 12:04 신고 | PERMALINK | EDIT/DEL | REPLY
혹시 접속했는데, appError 라고 뜨면 해당 링크를 인터넷 익스플로어에서 접속하면 됩니다. (아마도 현재 Prezi 서버쪽 문제가 있나보네요..)
Name
Password
Homepage
Secret
2012.07.24 15:41

 

Audacity is a popular sound recorder and audio editor.

 

시스템의 목적은 아키텍처에 영향을 미칠 수 있습니다. 아키텍처에 영향을 미치는 목적을 아키텍처적으로 중요한 목적이라고 합니다.

Aacity의 중요한 목적으로 다음을 제시합니다. 사실 이는 RSM Smarteasy(http://rsmer.tistory.com/27) 개발에 있어서도 원하는 부분이라 관심을 갖고 본문의 내용을 읽어 보았습니다. 하지만 원하는 내용은 나오지 않는군요.   

One goal is that its user interface should be discoverable: people should be able to sit down without a manual and start using it right away, gradually discovering its features.

 

이 장에서는 다양한 대안들과 근거는 약하지만, 문제와 해결책 중심으로 설명하고 있습니다. 따라서 정리는 문제 해결책 중심으로 하겠습니다.

 

Adacity에 요구되는 모든 부분을 구현하기 보다는 이미 존재하는 것들은 외부 라이브러리로 사용하기로 합시다. 외부 라이브러리들은 제어하기 어려운 것들이 때문에 새로 개발하는 것들과 구분할 필요가 있습니다. 레이어로 이들을 분리합시다.  

선택적으로 사용되는 외부 라이브러리들도 있기 때문에 플러그인 방식을 지원하기로 합시다.

Adacity는 레이어는 아래 그림과 같습니다.  

 

 

오픈 소스 개발이기 때문에 개발에 활용할 수 있는 시간에 제한이 있습니다. 따라서 처음부터 아키텍처링하는데 시간을 많이 사용할 수 없습니다. 따라서, 해당 시점에서 기능 추가나 변경이 어려운 것과 같은 문제가 있다고 판단되면 아키텍처를 점진적으로 개선해 나가는 방식을 사용하도록 합시다.

 

wxWidget을 가지고 다이얼로그를 만들다 보니 복잡하고 중복된 부분도 많습니다. 개발 과정에서 발견하게 되는 일반화된 패턴을 지원하여 좀 더 쉽고 단순하게 다이얼로그들을 만드는 방법을 제공하도록 합시다. 그리고 이를 ShuttleGui라고 합시다.

wxWidget으로 오디오를 편집하는 복잡한 패널을 만들어 보니 크기를 줄이거나 패널내의 위젯을 이동하니 깜빡거림등이 생깁니다. 이를 해결하기 위해 Flyweight 패턴을 사용하여 경량 위젯들을 만듭시다. 이 위젯들을 구성해서 패널을 만들고 이를 TrackPanel이라고 합시다.

Audacity는 레코딩할 때 PortAudio로 부터 데이터 패킷들을 받고, 재생을 위해 PortAudio에 패킷들을 보냅니다. 여러 가지 처리가 동시에 일어납니다.. 어떤 것은 자주 일어나고 어떤 것은 적은 양을 데이터를 보내기도 하고, 많이 보내는 것도 있습니다. 시간이 중요한 것도 있고 그렇지 않은 것도 있습니다. 이 문제를 해결하기 위해 버퍼를 둡니다.

한 시간 정도로 긴 시간동안 레코딩된 오디오를 편집하기 위해 부분을 삽입하거나 삭제하려고 할 때 시간이 오래 걸리는 문제가 있습니다. 이를 해결하기 위해 큰 파일은 1MB 미만의 작은 파일로 나누고 이를 관리하는 마스터 파일을 둡시다. 마스터 파일은 XML 파일로 확장자는 .aup로 합시다. 이와 같은 방식으로 처리하는 것을 BlockFiles라고 합시다.

고객은 Audacity에 실시간 효과를 줄 수 있기를 원합니다. 실시간 효과를 오디오 파일 전체에 반영하려고 하니 실시간 효과를 주고 나서 사용자는 오랜 시간 대기해야 하는 문제가 발생합니다. 이를 해결하기 위해 오디오 효과가 재생될 때 필요시(on demand)에 계산될 수 있도록 합시다.

 

요약 부분에 아키텍처에 있어 중요한 두 가지 이야기를 하고 마무리 하고 있습니다.

Structural decisions are wider ranging than deciding how to structure new features. A decision about what not to include in a program can be as important. It can lead to cleaner, safer code.

Structural decisions also are driven by plans for future growth

저작자 표시 비영리 변경 금지
신고
Mickey | 2012.08.08 11:32 신고 | PERMALINK | EDIT/DEL | REPLY
무엇을 넣을 것인가가 아니라, 무엇을 뺄것인가에 대한 결정이 중요하다는 말...
스티브 잡스가 인용했던 "Simplicity is the ultimate sophistication." 이 떠오르네요...
비단 SW 만이 아니라 우리 인생에 무엇이든지 다 해당되는 사항 같습니다.
Name
Password
Homepage
Secret
2012.07.21 12:41

 

아키텍처는 고객의 기능/비기능 요구사항과 직접적으로 관련된 중요한 의사결정입니다. 의사결정을 한다는 것은 어떤 문제에 대한 해결책으로 선택할 수 있는 대안들이 여럿 있다는 것을 의미합니다. 여러개의 대안들 중에 하나를 선택하는 것이기 때문에 거기에는 그렇게 결정한 근거가 있어야 합니다.

아키텍처를 간접 경험한다는 것은 이러한 의사결정 과정을 간접 경험하는 것입니다. 어떤 문제에 대해 어떤 대안들이 있고 그 대안들에서 어떤 것을 왜 선택했는지를 연습하는 것입니다.

이 책은 실제적으로 사용되고 있는 다양한 오픈소스들을 대상으로 하고 있고, 책 제목에 아키텍처를 포함하고 있기 때문에 관심을 갖는 사람들이 많이 있습니다. 그래서 많은 기대를 가지고 시작했습니다. 하지만 책의 시작에 해당하는 1장의 내용은 실망이었습니다. 전체 내용을 이미 읽거나 세밀하게 검토하지 않고, 많은 사람들이 관심을 갖고 있는 책이라는 이유로 너무 성급하게 선택한 것이 아닌가하는 생각도 해봤습니다.

사실 1장의 Asterisk는 도메인도 관심 대상이 아니고, 이 장을 통해 무엇을 배울 수 있는가를 물었을 때 사실 뭘 배울 수 있는지 모르겠습니다. 해당 도메인에 관심을 가지고 이러한 시스템을 개발해야 하는 사람에게는 도움이 될 수 있을지는 모르지만, 책의 의도한 바와 같이 아키텍처에 대한 간접 경험을 얻기에는 많이 부족해 보입니다.

이러한 이유로 책의 내용을 정리하는 방식으로 진행하는 것은 좋지 않다고 생각이 듭니다. 조금이라도 뭔가를 배울 수 있으려면 적극적으로 '어떻게 해당 시스템에 대한 아키텍처를 구축할 수 있을까?'라는 관점으로 접근해야 할 것 같습니다.

 

온라인 세미나 진행은 참여자가 아키텍트가 되어 '해당 시스템을 어떻게 아키텍처링할 것인가'라는 관점을 가지고 접근할 것입니다. 아키텍처링을 하지만 그 결과는 책의 내용이 기준이 됩니다. 불필요한 세부사항은 생략함으로 세미나 진행자나 참여자들의 부담을 줄이도록 하겠습니다.

 

Asterisk is an open source telephony applications platform distributed under the GPLv2. In short, it is a server application for making, receiving, and performing custom processing of phone calls.

'Asterisk ' - 이 이름으로 부터 시스템이 무엇을 하는지 알기 어렵습니다. 대부분의 오픈소스들의 이름이 이렇게 지어지는 것 같습니다. 시스템 이름은 시스템의 존재목적이 반영되도록 하는 것이 좋습니다.

 

이 시스템을 만들어야 한다면 어떻게 해야 할까요?

구조에 대한 접근은 기능요구와 비기능요구를 분리해서 접근하는 것이 이러한 구분 없이 접근하는 것보다 쉽습니다. 기능요구에 의해 결정되는 구조는 도메인의 핵심구조가 됩니다.

Asterisk 사용자는 전화를 통해서 음성메일이나 전화통화를 할 수 있습니다. 음성메일이나 전화통화에는 어느정도 시간이 요구될 것이기 때문에 전화와 Asterisk 시스템 사이에 연결을 유지할 필요가 있다. 연결을 유지해주는 부분을 채널(Channel)이라고 합시다. 음성메일은 하나의 전화와만 연결되니 하나의 채널이 만들어지면 됩니다. 

전화통화는 두 개의 채널이 만들어져야 합니다. 전화통화를 위해서는 어떤 채널과 어떤 채널이 연결된 것인지를 알아야 하고, 그들 사이의 음성 전달이 요구됩니다. 이 역할을 하는 것을 채널을 연결한다는 의미로 채널브릿지(Channel Bridge)라 합시다.

고객은 전화들 사이에 음성 뿐만 아니라 비디오나 텍스트 또한 전달하기를 원한다고 합니다. 음성이나 비디오나 텍스트를 전달하는 기술은 어떤 전화를 사용하느냐에 따라 다양하다고 합니다. 이 요구사항을 만족시키기 위해서는 채널이 다양한 기술을 지원할 수 있어야 합니다.  즉, 전화 사용자들이  어떤 채널 기술을 사용하던지 상관없이 두 채널을 연결할 수 있어야 합니다.

다양한 채널 기술들에 상관 없이 브릿지할 수 있으려면 다양한 고려가 있어야 하고 이를 반영해야 하기 때문에 성능이 떨어질 수 있습니다. 만약 같은 기술의 채널들을 연결하는 경우라면, 불필요한 고려를 할 필요가 없습니다. 성능과 유연성을 모두 만족시키기 위해서 두 종류의 브릿지를 둡니다. 채널 기술에 상관 없이 브릿지하는 것을 generic bridge라고 하고 채널 기술에 종속되어 브릿지하는 것을 native bridge라고 합시다.

 

여기까지 진행하면 우리는 도메인의 핵심구조인 Channel, Channel Bridge를 식별할 수 있습니다.

 

고객은 Asterisk가 프레임워크가 되기를 원합니다. 따라서 프레임워크를 확장해서 만들어지는 애플리케이션들에서 쉽게 사용될 수 있도록 해야 합니다. 

애플리케이션에서는 특별한 채널 기술들에 대해서 알 필요가 없습니다.  따라서 Asterisk는 특별한 기술을 추상화한 수준에서의 인터페이스와 구체적인 기술이 반영된 클래스가 구분되도록 합니다(인터페이스와 구현의 분리). 이 구분에 따라 Abstract Channel Layer, Channel Technology Layer라는 두 개의 레이어를 둡니다.

채널은 공통의 인터페이스에 대한 다양한 구현이 존재할 수 있기 때문에 구체적인 채널의 생성을 위해 팩토리를 둡니다(팩토리 메소드 패턴).

 

중요한 비기능 요구사항은 성능에 대한 것으로 병행처리에 대한 고려만을 하라고 합니다. 멀티쓰레드로 병행처리를 다루기로 합니다. 다수의 사용자들에 의해 연결이 요청될 수 있기 때문에 네트워크 모니터링 하는 것과 채널 처리에 대해서 쓰레드를 둡니다.

저작자 표시 비영리 변경 금지
신고
Mickey | 2012.07.26 23:44 신고 | PERMALINK | EDIT/DEL | REPLY
"해당 시스템을 어떻게 아키텍처링 할 것인가?" 라...조금 고민도 되고 부담도 되는 것 같네요..^^;
Justine | 2012.08.02 11:18 신고 | PERMALINK | EDIT/DEL
꼭 그렇게 할 필요는 없습니다. 1장과 2장은 정리된 내용에 밝힌 것 같이 그럴 만한 이유가 있어서 그렇게 한 것입니다. 내용을 잘 전달하고, 그 내용을 통해 무엇인가 배울 것이 있도록 하는 것이 목표입니다. 그 목표를 가장 잘 달성할 수 있는 방법이면 됩니다.
Name
Password
Homepage
Secret
2012.07.05 21:15

 

프로그래밍과 소프트웨어 아키텍처가 어떻게 다른지 비교하면서 시작합니다.

Programming is also an exacting craft, and people can spend their entire lives learning how to do it well. But programming is not software architecture. Many programmers spend years thinking about (or wrestling with) larger design issues: Should this application be extensible? If so, should that be done by providing a scripting interface, through some sort of plugin mechanism, or in some other way entirely? What should be done by the client, what should be left tothe server, and is "client-server" even a useful way to think about this application? These are not programming questions.

 

모방은 실제적인 기술을 익히는데 있어 매우 훌륭한 방법입니다. 소프트웨어 아키텍처링 기술을 배우는데 있어 불리한 점은 학습을 위한 다양한 문서화된 예들이 없다는 것입니다. 이 책은 이러한 상황을 바꿔보고자 하는 시도의 결과입니다. 

Each chapter describes the architecture of an open source application: how it is structured, how its parts interact, why it's built that way, and what lessons have been learned that can be applied to other big design problems.

 

전체는 두 권으로 되어 있는데 1권에서 25개 2권에서 24개의 오픈소스를 다룹니다. 하나의 오픈소스에 대해 하나의 장을 할당합니다.

 

 

RSMer's Page

1. 오픈소스의 아키텍처에 대한 문서화는 original author나 그에 상응하는 사람이여야 할 것입니다. 따라서 저자가 많아질 수 밖에 없습니다. 저자가 많아 질 때 일관성 문제가 발생할 수 있습니다. 이 책에서는 일관성에 대해서는 크게 신경을 쓴 것 같지는 않습니다. 형식보다는 내용에 신경쓴 것 같습니다.

다양한 저자들 사이에 일관성을 맞추기는 어렵겠지만 정리하는 사람 입장에서는 일관성을 맞출 수 있지 않겠나 싶습니다. 개인적으로 Document Software Architecture의 문서화 방식을 좋아합니다. Document Software Architecture는 오프라인 세미나로 진행되었지만 정리된 내용이 남아있지 않습니다. 해당 내용을 정리해가면서 이 책에 일관성을 부여하는 것도 괜찮아 보입니다. 

 

2. 세미나의 주 참여자 최상호, 장회수, 서만수, 한동균, 김현남 입니다 .

참여자가 1권에서 다루는 장들은 다음과 같습니다. 2권은 1권을 마치는 시점에서 정하도록 하겠습니다.

최상호: 10장, 18장, 20장

장회수: 8장, 9장, 15장

서만수: 3장, 11장, 14장

한동균: 6장, 12장

김현남: 나머지

저작자 표시 비영리 변경 금지
신고
김규표 | 2012.07.10 12:46 신고 | PERMALINK | EDIT/DEL | REPLY
7월5일날 올라왔군요. 몰랐네요 ^^; 트위터에는 공지가 안되나요?
Justine | 2012.07.11 00:54 신고 | PERMALINK | EDIT/DEL
트위터로 공지되었습니다. 놓치신 것 같네요.
Mickey | 2012.07.11 21:36 신고 | PERMALINK | EDIT/DEL | REPLY
2장은 언제 하나요? 제가 3장이니 바로 그 다음이네요...^^
Justine | 2012.07.12 00:35 신고 | PERMALINK | EDIT/DEL
다음주까지 해야 하지 않나 싶네요. Mickey님도 다음주까지 끝낸다고 생각하시고 계획하시면 될 것 같습니다.
Name
Password
Homepage
Secret
2012.07.05 21:15

1. 참여자는 주 참여자와 일반 참여자로 구분합니다.

주 참여자들은 자신에게 부여된 장에 대해서 정리합니다. 일반 참여자는 별도의 신청 없이 트랙백이나 덧글 등으로 참여합니다.

주 참여자는 The Certified RSMer Candidate인 장회수, 최상호, 한동균, 서만수씨입니다.

 

2. 온라인으로 진행되고, 각 권 중간과 끝에 오프라인 세미나를 합니다.

오프라인 세미나시에는 참여신청을 받아 진행합니다.

 

3. 7월 1주부터 3개월간 진행합니다.

뭐든 혼자하기는 쉽지 않습니다. 이 기회에 해당 내용을 부담 없이 같이 공부하는 계기가 마련되었으면 합니다.

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

NWC컨설팅은 국내의 소프트웨어 개발 기술과 소프트웨어 모델링 기술의 발전에 조금이나마 도움이 되고자 여러 세미나들을 준비해왔습니다.

이번 세미나는 오픈소스 애플리케이션들에 대한 아키텍처를 살펴봄으로 아키텍처에 대한 실제적인 내용들을 간접경험해 볼 수 있는 좋은 기회가 될 것 같습니다.   

 

이번 'The Architecture of Open Source Applications' 세미나는 온라인과 오프라인을 병행해서 진행합니다. 

온라인으로 진행되는 부분은 신청을 받지 않고 자유롭게 누구나 참여할 수 있도록 하겠습니다. 오프라인으로 진행되는 부분은 추후 참여 신청을 받도록 하겠습니다.

온라인에서는 책의 내용을 정리하고, 해당 내용에 대한 참여자들의 의견을 블로그나 트위터 등을 통해서 공유하도록 하겠습니다. 진행은 매주 5개 정도의 주제를 다루어 2개월 정도에 마무리할 것입니다.

오프라인 세미나는 1권이 끝날 때와 2권이 끝날 때 두 번 진행하도록 할 것입니다. 



대상 도서
http://www.aosabook.org/en/index.html

세미나 기간

7월 첫 째주로 해서 책을 끝낼 때 까지


 

이후 세미나 계획

1. Software Factories

2. Objects, Components, and Frameworks with UML

3. Metapattern

4. The Nature of Order

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바