- 파생 클래스 생성에 부담이 느껴진다면, 여전이 클래스 계층에 대한 추상화가 덜 되어 있다는 증거다.
- 속성 맴버 변수를 외부로 노출시키지 말고 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를 받아 해결할 수 있다.
- 서술식 글쓰기도 설계 방법 중의 하나.. UML과 글쓰기의 적절한 결합이 필요하다..
9월 18일 12시 49분
-
어디 쓸만한 꽁짜 UML 툴없나… 지금 쓰고 있는 StarUML은 결과는 그런대로 산뜻하긴 한데, UML 스펙을 지원하지 않는게 넘 많다. 지원하는 척… 하곤 결국 완벽이 지원하지 않는 그런 모습. 언제 쓸만한 공짜 UML 툴 찾아봐야겠다.
9월 14일 12시 57분
-
소프트웨어 설계라는 것이 유지보수와 소프트웨어의 생명주기를 길게 하는 효과는 있으나, 소프트웨어의 성능에 오히려 방해가 되는 것 같다는 생각이 든다.9월 13일 9시 54분








아래는 동일한 데이터.. 즉, 위에 대한 XGE의 결과입니다.
밀도 계산중 심플 방식은 속도는 매우 빠르지만, 그 결과는 그리 Nice~ 하지 않습니다. 아래는 실제 밀도 계산에서 가장 많이 쓰이는 Kernel 방식이며 ArcGIS에서 얻은 결과입니다. 심플 방식에 비해 결과가 Nice~ 하지요..
아래는 위와 동일한 데이터와 밀도 계산을 위한 변수(셀해상도, 계산반경)에 대한 XGE의 결과입니다. 배경이 검정인 이유는 검색반경에 영향을 받지 않아 Null Value인 셀입니다. ArcGIS의 경우 이 Null Value인 셀에 대해서는 가장 낮은 값으로 할당한 색상으로 표현하고 있습니다.
아래는 서울 지역에 대한 은행분포를 나타낸 Kernel 방식의 밀도 계산이며 모두 XGE로 얻은 결과입니다. 감상(?) 해보시길 바랍니다. ^^ ArcGIS에서처럼 Null Value인 셀에 대해서도 최하위 단계의 색상으로 표현하고 있습니다.


