Software Design에 대한 짧은 생각과 팁

  • 파생 클래스 생성에 부담이 느껴진다면, 여전이 클래스 계층에 대한 추상화가 덜 되어 있다는 증거다.
2008년 1월 2일 오후 4시 29일

 

  • 속성 맴버 변수를 외부로 노출시키지 말고 get/set 함수를 두어 접근하도록 하는 것이, 클래스간의 독립성을 유지하는데 도움이 된다. get/set 함수를 만드는 수고로움에 대한 보상으로 말이다.
  • Class Diagram의 작성은 “인터페이스의 정의”로 시작된다.

12월 6일 오전 9시 56분

 

  • 데이터베이스에서 한번 정의된 스키마의 변경에 많은 소요비행이 발생한다면, 소프트웨어 개발에서는 클래스 관계도와 같은 UML 설계문서가 아닌 “전제조건”의 변경에 많은 소요비용이 발생한다. 여기서 말하는 전제조건이란, 어떤 기능을 실행하기 위해 준비되어야할 조건이다.

    11월 27일 오후 5시

     

  • 두렵다. 구현 단계에서 결국은, 비록 길지는 않은 시간이지만, 짧지만도 않은 시간 동안 설계한 내용을 폐기해야할지도 모른다는 생각에…. 그래서 분석 설계는 최대한 간결하게 하라고 했나보다. “어차피 내일은 변하다”니말이다. 하지만 최소한 설계 단계가 의미있는 이유는 실제 구현단계에서 마주치게 될 위험요소를 미리 파악할 수 있다는 큰 장점이 있다는 점이다. 그래서 인지… 설계를 하면 할 수록 두렵다….

10월 4일 오전 11시 36분

  • 영업인력이 고객에게 기술적으로  감동을 줄 수 있도록 개발인력은 소프트웨어를 설계하고 개발해야 한다.

9월 19일 14시 55분

 

  • 예를들어, Base라는 클래스로부터 상속받은 Derived라는 클래스가 있다고 할때, Base의 생성자의 인자가 (int a, int b, int c, int d)라고 하면, Derived 클래스의 생성자도 Base의 생성자를 실행하기 위해 인자로써 (int a, int b, int c, int d)를 최소한 가져야 하는데.. 만약 Base의 생성자의 인자가 하나 추가되면 Derived의 생성자의 인자도 동일하게 추가되어야한다. 하나의 변경으로 두개 이상의 변경이 발생하는 이 문제를 해결하기 위해 Derived의 생성자의 인자로 바로 Base를 받아 해결할 수 있다.
9월 19일 10시 12분

 

  • 서술식 글쓰기도 설계 방법 중의 하나.. UML과 글쓰기의 적절한 결합이 필요하다..
    9월 18일 12시 49분

     

  • 어디 쓸만한 꽁짜 UML 툴없나… 지금 쓰고 있는 StarUML은 결과는 그런대로 산뜻하긴 한데, UML 스펙을 지원하지 않는게 넘 많다. 지원하는 척… 하곤 결국 완벽이 지원하지 않는 그런 모습. 언제 쓸만한 공짜 UML 툴 찾아봐야겠다.

    9월 14일 12시 57분

     

 

  • 소프트웨어 설계라는 것이 유지보수와 소프트웨어의 생명주기를 길게 하는 효과는 있으나, 소프트웨어의 성능에 오히려 방해가 되는 것 같다는 생각이 든다.

    9월 13일 9시 54분

     

 

XGE 4차 릴리즈 – 스타일

약 2주전쯤에 나온 결과물입니다. 아직은 만족스럽지 않은 결과인지라 올리지 않았는데요. 이번주부터 새로운 기능을 하게 되서 일단 정리차원에서 올립니다. 원본 이미지는 훨씬 큽니다. 클릭해 원본 크기로 봐주시길 바랍니다.






분위기는 밝은 파스텔 톤입니다. 이미지 심벌과 문자 라벨을 좀더 적절하게 적용하면 훨씬 나은 결과가 나오리라 기대해 봅니다. GDI+만을 사용했는데요. 처음엔 속도 문제가 걸려 일단 GDI+ 이전의 그리기 API인 GDI를 지원했습니다. 옵션에 따라 GDI+로 그릴때와 GDI로 그릴때로 구분해 줄 수 있습니다. 하지만 지금은 속도 문제보다는 느낌이 훨씬 더 나은 GDI+만을 사용하도록 되어 있습니다. 예전부터 느낀 것이지만 GDI+는 괜찬은 그리기 API라는 생각입니다. 위의 화면에 나타나지 않았는데… XGE의 그리기 기능 중에 하나인 복합심벌이 있습니다. 예를 들어서 단순한 라인인데.. 이 라인이 철도를 의미한다면 아래처럼 그려줄 수 있습니다.

Bug Fix..!!

버그를 잡다가, IDE도 덩달아 죽는 모습을 보면서.. 평소에는 그냥 의식하지 않던 위의 오류보고창의 글귀를 읽어보았습니다. “품질을 향상시키는데 도움이 됩니다”. 소프트웨어의 품질에 대해 생각을 하게 만듭니다. 소프트웨어의 품질이란 무엇일까? 품질… 얼마나 안정적인가? 또 일정한 수행 속도 퍼포먼스를 제공하는가? 딱 떠오르는게 이 두가지 항목입니다…

사실 위의 창을 캡쳐하여 블로그에 올리는 이유는, 오늘 잡았는지, 잡았다고 착각을 하고 있는지 확실하지도 않은….. 버그 2개를 잡으면서였습니다. 전부터 잡아야겠다고 버르고 있던 버그였는데, 이 버그가 영향을 미치는 새로운 기능 몇가지를 추가하기에 앞서… 이 버그를 잡아야 했던 까닭였지요. 9시에 출근해서 지금까지 이 두마리의 버그에 씨름을 했는데, 사실 한마리는 그냥 쉽게 해결되었고 또 다른 한마리 때문에 고생을 했습니다. 이런 버그는 잡기가 어렵다… 걍 포기할까? 꽁수를 부려볼까? 하는 유혹이들 무렴에.. 고맙게도 IDE가 죽으면서 위의 창이 뜨더군요. 품질향상은 단박!에 되는것이 아니고… 릴리즈된 이후에도 지속적으로 사용자의 피드백을 받아 향상되어야 한다는 MS의 가르침이랄까요?

아무튼, 오늘은 기능추가 하나 없이… 달랑 버그 2마리 잡았습니다. 그것도 정말 잡았는지, 잡은 듯 보이는지.. 애매하긴 하지만 말입니다. 여튼, 결론은 “단박에 버그 잡기는 희망 사항일뿐이므로, 너무 오늘 하루에 목매지마라” 입니다. 음… 끝으로 너무 피곤합니다………

[펌] 후회없으려면 ‘당신이 만든 길’ 가라

암으로 투병 중이던 성균관대 법학과 이기용(李起勇.50) 교수는 2007년 12월 5일 마지막 수업을 마친 뒤 오후 2시45분께 쓰러져 인근 병원으로 옮겨졌으나 숨졌다. 이 교수는 암 발병 사실을 알게 된 뒤에도 “강의를 모두 마치고 입원치료를 받겠다”며 수술 날짜를 종강 이후로 미뤄왔던 것으로 전해져 안타까움을 더하고 있다.

이 교수는 2개월 전 우연히 대장 내시경 검사를 받은 뒤 직장암 3기 판정을 받았지만 맡은 강의를 중단할 수 없다며 입원 치료를 거부한 채 병원을 오가며 방사선 및 항암 치료를 받았다. 그는 항암 치료를 받으며 2학기 대학원 강의와 학부 2과목 수업을 계속해 체력이 바닥난 상태에서도 성실하게 강의에 임했다. 쓰러지기 직전까지 담보물권법 마지막 강의를 마치기 위해 3시간 연속 수업을 했던 것으로 전해졌다.

또 2007년 9월 미국 카네기멜런대의 랜디 포시(47세, 컴퓨터공학) 교수는 삶이 몇 개월 남지 않았다는 시한부 판정을 받은 췌장암환자로서 마지막 강의를 해 주위를 감동시켰다. 포시는 이 날 전공 대신 인생 이야기를 중심으로 강의를 했으며, 그는 사람들이 자신들의 잠재력을 허비하고 있다며, 이를 일깨우라고 촉구했다. 그는 “어떤 성취든 이루는 과정에서 벽에 부딪히지만 벽이 있는 이유가 다 있다”며 “그 벽은 우리가 무언가를 얼마나 절실히 원하는지를 시험하는 기회”라고 말했다.

필자는 이 두 교수의 죽음에 대한 기사를 보면서 필자의 저서 <행복한 변화>에 적었던 글귀가 떠올랐다. ‘만약 내 생애 일주일을 남겨두고 있다면 나는 과연 무엇을 할 것인가?’에 대해 적어놓은 부분이 있었는데, 남은 일주일 중 이틀은 ‘내가 해오던 일’을 하고 싶다고 했다. 만약 돈벌이의 수단으로써 일을 선택했다면 도저히 불가능한 일이었을 것이다. 우리는 삶의 2/3를 일하면서 보내게 된다. 자신이 해오던 일을 하면서 죽음을 맞이할 수 있는 삶, 나는 가장 멋진 삶이라 생각한다.

만약 이런 죽음의 순간이 당신에게도 찾아온다면 과연 당신은 무엇을 하겠다고 말하겠는가?

죽음을 앞에 두고 자신이 하던 일을 계속하겠다는 사람이 과연 몇이나 될까? 자신이 하는 일에 대한 소명의식이 있지 않는 한 참으로 어려운 질문이 아닐 수 없다.

최근에 창조경영이 화두가 되면서 21세기에 가장 불쌍한 사람은 ‘근면성실하기만 한 사람이다’라는 말까지 나오고 있다. 왜냐하면 근면성실해서 되는 일들은 이제 기계가 모두 대신해주고 있기 때문이다. 무조건 참고 인내하는 방식으로는 성공할 수도 없을뿐더러 삶이 지루해진다. 지금은 20세기가 아니다. 21세기를 살아가는 우리는 일하는 게 기뻐서 날뛰어야 한다. 일 자체가 목적이 될 수 있어야 한다. 그러면 저절로 근면해지고 성실해진다. 땀에 젖게 하는 인내도 중요하지만 그보다는 즐거움에 젖게 하는 것이 먼저다.

사람은 각자에게 주어진 길이 있다. 그 길을 모른다고 외면하지 마라. 그 길이 쉽게 찾아지지 않는다고 포기하지 마라. 찾지 못하는 가장 큰 이유는 절실하게 찾지 않기 때문이다. 우리 모두에게는 자신이 생각하는 것보다 훨씬 큰 잠재능력이 있다. 이미 태어날 때부터 가지고 태어난다. 그것을 찾아내어 완성해가는 것이 삶에 대한 우리의 책임이고 임무이다.

남들이 간 길만 쫓아가지 마라. 남의 발자국을 밟으며 가는 사람들은 자신의 발자국을 남기지 못한다. 먼저 앞서간 사람들의 길을 참고삼아 당신만의 새 길을 만들어 가라. 그것이 후회 없는 참다운 인생이다.

2007/12/13 12:45에 처음 작성했고 오늘에 다시 마음에 세겨봅니다……….

XGE 3차 릴리즈 – 밀도계산

XGE에 이번에 추가한 밀도계산 기능을 ArcGIS와 비교해 보았습니다. 아래는 ArcGIS의 Simple 방식의 밀도 분석입니다. 주제는 “교육”입니다. 학교의 분포이겠지요.

참고로 XGE는 국내 최고의 비지니스 GIS 솔루션 기술을 가진 GIS 전문 회사((주)오픈메이트)가 보유한 GIS 엔진의 차기 버전입니다. XGE는 현재 개발단계인지라.. Code Name이고, 추후 멋드러진 이름을 갖게 되겠지요~ ^^

아래는 동일한 데이터.. 즉, 위에 대한 XGE의 결과입니다.

밀도 계산중 심플 방식은 속도는 매우 빠르지만, 그 결과는 그리 Nice~ 하지 않습니다. 아래는 실제 밀도 계산에서 가장 많이 쓰이는 Kernel 방식이며 ArcGIS에서 얻은 결과입니다. 심플 방식에 비해 결과가 Nice~ 하지요..

아래는 위와 동일한 데이터와 밀도 계산을 위한 변수(셀해상도, 계산반경)에 대한 XGE의 결과입니다. 배경이 검정인 이유는 검색반경에 영향을 받지 않아 Null Value인 셀입니다. ArcGIS의 경우 이 Null Value인 셀에 대해서는 가장 낮은 값으로 할당한 색상으로 표현하고 있습니다.

아래는 서울 지역에 대한 은행분포를 나타낸 Kernel 방식의 밀도 계산이며 모두 XGE로 얻은 결과입니다. 감상(?) 해보시길 바랍니다. ^^ ArcGIS에서처럼 Null Value인 셀에 대해서도 최하위 단계의 색상으로 표현하고 있습니다.

25m 해상도, 1000m 검색반경
10m 해상도, 2000m 검색반경
25m 해상도, 3000m 검색반경
25m 해상도, 5000m 검색반경

보시면 은행이 중구에 가장 많이 밀집되어있고 그 다음에 강남구 쪽에 많이 밀집되어 있다는 것을 알 수 있습니다. 밀도 분석은 2차원에서 그 분포에 대한 가중치를 구해 다양한 분석에 활용될 수 있는 조건 계산법입니다.