꿈꾸는자의 새 블로그

2008년 11월 4일 화요일

호박 오리 구이...

꿈꾸는자가 어제 먹은 호박 오리 구이...

호박에...
오리를 넣고...

깻입으로 싸먹는 것인데...

.
.
.

흠..

얼마전...
행주산성에서 먹은 호박 오리 구이보다는 별루...

거기는 무조건 예약손님만 받는데...

여기는
걍...

나온다...

ㅡㅡ;

약간 데운정도...

머... 다양한 대책들에 대한 짜집기 하느라고 고생들은 그다지 한것으로 보이지 않는다고 해야하나?

실물경기 활성화대책에...
쭈욱 나열된 내용들을 보니.

역시... 건설에 대해서는 나름 해박(?)한 지식을 가지신 분들이 만든 대책이라서 그런것인지 모르겠지만.

역시... 대한민국은 부동산 로또... 아파트 로또 한판을 벌이는 것이 최선이라고 생각하시는듯.

서울시내에...
재개발을 엄청하면...

건설사들이 일할것들이 많아지니...

경기가 살아난다고 하는듯...

~.~

서울시내에 그렇잖아도...
뒤죽박죽인데...

그리고,

현재에도...
투기에 눈먼 국민들에게는 나름 보약이라고 생각하시는듯...

머...

어쩔 수 없는 그들만의 선택이라고 자평한다.

아무쪼록...

이번 대책으로...

다시금...
아파트 로또에 미친 사람들이 우르르 몰려다니며...
눈이 벌건 상태에서...

돈이 돈을 벌어야 똑똑한 짓이다라고...

이야기하는 어른들의 모습을 또 봐야한다니...

쩝...

좀 우울하기는 하다.

하긴...

그나마...

대운하를 파서 토목, 건설경기 부양하는 방안이 안나왔으니
그나마 다행일까?

아냐...

아마도...
내년초에 다시금...

'삽질'을 하지 않을까 한다...

요즘같이 실물경기 위험한 시기에도...
아파트 한탕을 꿈꾸는...
사람들이 많이 있을테니...

다시금 투기의 광풍이 불어서...
몇년후에...

정말 부동산 거품 한꺼번에 사라지는...

난리의 시대가 올려나보다..

에휴~~

다들 미쳐있으니...

에휴~

아! 오늘은 숙취때문에... ㅡ.ㅡ;

어질 어질...

ㅡ.ㅡ;

점심에...

해장은 뭐로 해야할려나...

ㅡ.ㅡ;

[SA강좌] Part 3-11 품질 요구사항 구조적 그룹핑

품질 요구사항 구조적 그룹핑

지금까지 소프트웨어 아키텍처를 아키텍처 관점에서 품질요구사항을 파악하여 최대 만족을 하고 반면에 도메인 기능적 변경이 최소화 되도록 아키텍처 전이 과정의 네 가지 카테고리를 살펴보았다.

결론은 각 아키텍처 전이 단계의 최종 활동은 divide-and-conquer 원칙을 적용한 품질 요구사항을 적용시키는 것이다. 시스템레벨에서 품질 요구사항은 시스템을 구성하는 서브시스템이나 컴포넌트로 재구성된다. 따라서 한가지 품질요구사항(X)은 X를 만족하기 위하여 여러 개의 컴포넌트(n)으로 재구성된다고 말할 수 있다. 그림 Ⅲ-39는 이러한 설계 결정물과 관련한 계층 관계를 도식화한 것이다.

그림 Ⅲ-39. 소프트웨어 아키텍처 전이 과정 구성요소

소프트웨어 아키텍처 전이 단계 동안의 산출물은 설계 결정물 전이 이다. 일반적으로 전이는 소프트웨어 아키텍처상 구조적 노력에 불과하다. 그러므로, 이 단계의 결과산출물은 소프트웨어 아키텍처의 일련의 부분 버전에 불과하다.

[SA강좌] Part 3-10 아키텍처, 설계 패턴 적용

아키텍처 패턴 적용

아키텍처 스타일 적용은 소프트웨어 아키텍처를 전이하는 방법이며, 아키텍처의 품질요소를 개선하는 것이다. 두 번째 카테고리인 아키텍처 패턴 또는 아키텍처 메커니즘은 일반적으로 동시성 또는 지속성과 같은 기능화 측면을 다루기 위하여 어떻게 시스템을 특성화시킬 건지 규칙을 아키텍처에 적용한 것이다. 아키텍처 패턴은 아키텍처의 기능적 컴포넌트를 재구성화하는 것이 아니라, 오히려 기능적 컴포넌트를 변경하고 확장시키는데 초점이 있다. 따라서 이 패턴으로 필요한 기능을 담은 새로운 컴포넌트를 추가 또는 변경하는 과정이다. 아키텍처 패턴은 소프트웨어 아키텍처 또는 그 영향을 받는 컴포넌트에서 컴포넌트의 기능을 제한하고 동일한 기능을 수행하는 또 다른 아키텍처 구조상 패턴을 적용 또는 사용을 막는다. 즉 아키텍처 패턴은 시스템 행위의 한 측면만을 다룬다. 일반적으로 이 부분은 어플리케이션 도메인이 아니라, 컴퓨터 사이언스 도메인 측면이다. 컴퓨터 사이언스 측면은 주로 concurrency, persistence, synchronization, transactions, distribution, runtime binding, real time behavior, graphical user interface가 이에 속한다.

설계 패턴 적용

아키텍처 패턴에서 소프트웨어 아키텍처 전반에 걸친 영향을 미치는 전이 방법을 살펴보았다면, 설계 패턴은 전체 아키텍처 관점에서는 조금 덜 유동적인 전이과정이라고 할 수 있다. 이러한 설계패턴은 아키텍처 또는 시스템의 기능적(functionality)에 변경을 줄 수 없는 것이며, 단지 그 functionality의 구성이나 구조를 결정할 수 있다. 설계패턴은 이후 상세설계를 위한 설계패턴에서 더욱 자세하게 살펴보도록 한다.

품질요구사항의 기능화

원칙적으로 아키텍처 스타일과 설계 패턴은 아키텍처의 품질속성을 만족시키기 위하여 현재 기능화된 구조를 새로운 버전의 구조로 재구조화한다. 하지만, 이러한 활동이 항상 효과적이고 능률적인 것은 아니다. 어플리케이션 도메인과 관련된 것이 아니라 단순히 품질요소 개선을 위한 시스템의 추가된 기능화 과정일 수도 있다. 마지막 전이 카테고리는 품질 요구사항을 도메인과 관련된 것이 아니라 요구사항 수용이라는 아키텍처 확장이라는 의미를 가진 기능적 해결책으로 변환이다. 비록 이러한 형태의 해결책이 현 버전의 아키텍처를 마이너수준의 재구성화를 요구할지도 모르지만, 새로운 컴포넌트와 기능화의 추가가 원칙적인 해결책이다.

2008년 11월 3일 월요일

큰아들 수철이와 함께 찾아간 세미나에 대한 추억...

2008년 델파이 연합 세미나 2008에 큰 아들 녀석과 같이 참석했네요.
~.~

아들녀석 손잡고.. 세미나에 참석하다니...
정말 색다른 경험이며...

큰 녀석에게 멋진 모습을 보여준 정말 좋은 기회였었네요.

10년후에...
이 곳에 다시금 성장한 모습으로...
나타날 수 있을까요?

~.~