본문 바로가기

Project

SOA Programming ? 얼마전 회사 시스템부의 어떤분의 발표자료에 SOA Programming이라는 생소한 단어를 보았습니다. 대충 프레젠 내용은 프로그래밍의 발전단계를 설명하였는데, 구조적 프로그래밍 -> 오브젝트지향 프로그래밍 -> SOA프로그래밍 이라는 말과 함께 SOA프로그래밍은 서비스단위로 프로그래밍을 한다고 짧게 언급하였습니다. (전체 PPT 5페이지정도로 짧은내용이었습니다.) 그때는 내가 알고 있는 SOA와 프로그래밍과 전혀 연관되어 이해할수 없었기에 그냥 넘어갔었는데 오늘 제가 알고있는 OOP와 연관하여 조금 생각해보았습니다. 나에게 SOA가 OOP와 같은 새로운 패러다임으로 생각하냐고 묻는다면 아니라고 대답하겠습니다. 개발방법론에서 고려할수 있는 발전된 새로운 안이 아닐까 생각되는 입장입니다. 즉 OOAD(Ob.. 더보기
시스템 역학 (system dynamics) 시스템 역학은 우리 주변의 현상이나 사물을 공부하는 방법이다. 현상이나 사물을 작은 조각으로 분할하여 연구하는 다른 과학과 달리, 시스템 역학은 현상이나 사물을 전체속에서 파악한다. 시스템역학의 핵심 개념은 시스템의 구성요소들이 서로 어떻게 작용하는가를 이해하는 것이다. 여기에서 말하는 시스템은 증기기관 , 은행계좌 , 농구팀에 이르기까지 다양하다. 시스템의 구성요소와 사람은 한 변수의 변화가 시간의 흐름에 따라 다른 변수에 영향을 미치고, 영향을 받은 변수가 다시 처음의 변수에 다시 영향을 미치는 '순환관계 feedback loop'를 통하여 상호 작용한다. - 교육 프로젝트의 MIT시스템 역학, http://sysdyn.clexchange.org ( 제 4장에서 수정 인용 ) 죽음의 행진(death-.. 더보기
프로그래머의 생산성 1.뛰어난 설계자와 디버깅을 잘하는 사람은 다를수가 있다. 뛰어난 설계자 - 숲의 전체적인 모습을 보는데 뛰어남 디버거 - 나뭇잎을 보는데 뛰어남 2. 작은 규모의 프로그램을 작성하는 경우 문제의 종류에 따라 사람마다 최고 30배까지 차이가 있을수있다. 하지만 집요하게 문제를 파고들어야 하는 문제가 있는 반면에 큰그림에서 문제를 보아야할경우가 있기에 상황은 역전될수 있다. 비슷한 이야기로서 규모가 큰 문제(프로그램)를 해결하는 과정에서는 그 차이가 2-3배정도로 줄어들수있다. 규모가 큰 프로젝트에서는 프로그래머가 잘하는 문제와 못하는 문제가 있기 마련이다. 그 차이는 큰 규모의 프로젝트를 진행하며 줄어드는데 이런차이는 프로그래머의 능력차이보다는 외부요인에 의해 발생하는 경우가 많다. 출처 : 프로그래밍 .. 더보기
개념적 무결성 , 개념적 일관성? 맨먼스의 미신를 보며 떠오른 의문이다. 개념적 무결성(일관성)을 위해서는 소수가 결정해야 한다: 프로젝트의 개념적 일관성을 유지하기 위해서는 단 한 명의 설계자(또는 소소의 아키텍처 팀)가 프로젝트를 실제 구현하는 팀과는 완전히 별개 차원에서 아키텍처의 통일성에 관한 결정을 내릴 수 있어야 한다는 것이다. 맨먼스의 미신(The mythical man-month)에서 라고 언급하며 그 뒷부분에는 매킨토시의 인터페이스의 일관성에 대해 언급을하는데, 이 둘은 같은 뜻이였던가?-_- 먼저 맥의 인터페이스의 일관성과 프로젝트의 개념적 일관성은 예전에 일관성에 대해 쓴 글 에서 언급한 내적일관성 외적일관성과 같은 말인듯하다. 아마 저 글을 쓴 당시에는 구분하진 않고 저렇게 대략 개념적으로만 같다고 생각한듯. 무결성.. 더보기
소프트웨어의 공학의 관심사. 1. 일련의 프로그램을 시스템(system)으로 설계하고 구축하는 것 2. 프로그램이나 시스템을 견고히하고 테스트하고 문서화하고 지원받는 제품(product)으로 설계하고 구축하는 방법 3. 복잡성(complexity)에 대한 제어를 현명하게 유지하는것 맨먼스의 미신(The mythical man-month)에서 라고 소프트웨어 공학의 관심사에 대해 언급하고 있다. 위의것을 다시 쓰면 1. (특정한 동작을 하는)프로그램을 설계하고 구축하는 방법 2. 원하는 기능을 갖춘 제품을 만드는 일련의 과정 3. 복잡성의 제어 그런데 자세히보면 1번은 2번에 속하는것이 아닐까? 1에는 프로그램 레벨에서의 구현방법, 즉 design pattern 같은 구현기술과 시스템 레벨에서의 구현방법 , 즉 architecture.. 더보기
몇몇 기술적 링크들. composite message pattern강의 -정리하자면, DVM 분산 가상 머신,위에서 메세징 패스 및 처리를 어떻게 구현해야하는가에 대한 설명이다. 고려해야할 background지식을 생각해보면 왜 저러한 구조가 나올지 알수있다. 마지막 패킷문제는 아마 구현상 오버헤드를 어디에 두느냐에 대한 문제인듯. Patterns for Successful Framework Development (BOOK : Framework Design Guidelines) -framework에서 고려해야할 tradeoff항목들 framework의 유무에 따른 tradeoff 1.프레임워크를 개발하는데 드는 비용은 일반 어플리케이션을 개발시보다 보통 3배 이상이 들어간다. 따라서 반드시 최소 3개 이상의 어플리케이션에서 .. 더보기
요건정의 느낀점. 최근에 하는일은 요건정의,DB설계 작업에 들어가있다. 물론 내가 주가되어 회의를 진행하거나 하는것은 아니지만 같이 투입되어 회의에 들어가서 고객의 이야기를 듣고 제안을 하는일을 하고있다. 일을 한지는 얼마 안되지만 몇가지 느낀걸 정리하자면 (미리 전제하면 기존시스템이 있고 목표는 기존시스템을 개선하고 새로운 기능을 추가하는 것이다. 즉 내부 프로젝트에 가까워 일반적인 요건정의와는 틀린부분이 있다.) 1.요건정의는 고객의 모든 요구을 들어주는 작업이 아니다. 즉 단순히 고객의 원하는 모든 기능을 정리해서 제안하는 작업이 아니라, 비용과 시간을 생각하고 고객이 원하는 기능을 정리하고 우선순위를 부여받고 실현가능한 기능을 정리해가는 과정인것이다. 2. 고객은 준비되어있다. 내가 만나는 사람은 영업 컨설팅?일을.. 더보기
요구파악과 사양정의 Next engineer를 읽고 개인적인 정리. 1. 요구사항은 제품사양과 구별하라 즉 SRS(software requirement specification)와 SPS(software product specification)를 구분하여 정리해야한다. - 요구파악은 "급할수록 돌아가라" 비행기의 이륙을 생각 - 이륙속도가 되기전에 이륙할수없다, 비행을 위해 최대한 준비를 마쳐라. - 요구에 대한 응답이 제품 고객의 요구와 제품은 달라서는 안된다. - 표현방법의 다름 예) 매일 9시 뉴스를 녹화하고싶다 -> 뉴스방송의 시간에 티비 튜너를 제어해 방송을 수신 ,Mpeg2형식으로 디스크에 저장 - 최소의 표현으로 최대의 요구를 기록 2. 제품사양은 치밀하게 모델화하라 - 제품사양을 표현하기 위한 모델링기술 보는.. 더보기
어플리케이션에서의 일관성(application consistency) 어플리케이션에서 일관성(application consistency)의 종류 외적 일관성 - 사용자가 어플리케이션을 사용함에 있어서 일관적인 경험을 제공하는것이다. 즉 동일한 방법으로 접근할수 있음을 말한다. 예) 윈도우를 사용할때 esc 를 누르면 보통 취소를 뜻한다. 내적 일관성 - 어플리케이션의 내부적 구조의 일관성을 말한다. 즉 어플리케이션에서 같은 의미를 뜻하는 기능및 데이타는 다른 층(layer)안에서도 접근 및 사용함에 있어서 동일해야한다. 예) mvc에서 객체의 일관성, java collections 외적 일관성은 어플리케이션 UI를 구축할때 정형화된 지침서를 통해 가능하고, 내적 일관성은 설계단계에서 일관적인 모델링과 document, 구현단계에서는 framework를 통해 가능해 보인다... 더보기
사양은 고정되어 있는가? 이것도 짧은 마인드멥이다. 프로젝트의 요구 사양은 변화하는가? 만약 사양이 고정되어 있다면 사양을 분석하여 정교한 모델을 만드는데 시간을 투자하는 편이 만들고 테스트 하는 방법보다는 ROI가 높을것이다. 하지만 변화한다면 어떻게 만드는것이 가장 효율적일까? 먼저 개발하려는 사양을 2가지 분류로 나눈다. 1.고정된 사양 2.변화하는 사양 1.먼저 고정된 사양은 연역적 판단을 통해 개발가능하다. 하지만 문제는 사양의 연역적 추론을 통해 만들수 있는 아키텍쳐는 셀수없이 많다. 때문에 성공적인 아키텍쳐를 판단하는 기준이 필요한데 이러한 기준은 연역적 추론 가운데서도 연역적 논리보다 실험적 추론이 훨신 더 유효할 수 있다. *실험적 추론을 위해서는 어느정도 실패를 통한 정보가 필요하다. 2.변화하는 사양은 빠른 .. 더보기

티스토리툴바