개요

프로젝트 경험이 많지 않은 팀에서 단순한 프로젝트에 LAYERED_ARCHITECTURE 와 함께 MODEL-DRIVEN-DESIGN 을 적용하기로 결정했다면 그프로젝트 팀은 매우 험악한 학습곡선에 직면할 것이다. 팀원들은 복잡한 신기술에 통달해야하고 객체모델링을 학습하는 과정에서 차질을 빚게 될 것이다. 인프로스트럭처 계층을 관리하는 데 따르는 부하탓에 매우 단순한 과업을 수행하는 데조차 시간이 오래 걸린다. 단순한 프로젝트에는 짧은 일정과 적당한 기대만이 따른다. 결국 팀에 할당된 과없을 완수하기도 전에 그러한 접근법이 가져다 줄 흥미진진한 가능성을 거의 보여주지 못한 채 프로젝트는 취소될 것이다. 설렁 그 팀에 시간을 더 주더라도 전문가의 도움 없이는 팀원들이 기술을 능숙하게 익히지 못할 가능성이 높다. 그리고 결국 그 팀이 이러한 문제를 국복하더라도 하나의 단순한 시스템만이 만들어질 것이다. 풍부한 기능을 요청한 적도 없는데 말이다. 그러므로 여건이 된다면 모든 업무로직에 사용자 인터페이스를 넣어라. 애플리케이션을 작은 기능으로 잘게 나누고, 나눈 기능을 각기 분리된 사용자 인터페이스로 구현해서 업무 규칙을 분리된 사용자 인터페이스에 들어가게 하라. 관계형 데이터베이스를 데이터의 공유 저장소로 사용하고 이용가능한 최대한 자동화된 UI 구축 도구와 시각적인 프로그래밍 도구를 사용하라.

장점

  • 애플리케이션이 단순한 경우 생산성이 높고 효과가 즉각적으로 나타난다.
  • 다소 능력이 부족한 개발자도 약간의 교육으로 이러한 방식으로 업무를 진행할 수 있다.
  • 요구사항ㅇ 분석 단계에서 결함이 발생하더라도 사용자에게 프로토타입을 배포한 후 요구에 맞게 제품을 변경해서 문제를 해결할 수 있다.
  • 애플리케이션이 서로 분리되므로 규모가 작은 모듈의 납기 일정을 비교적 정확하게 계획할 수 있다. 부가적이고 간단한 작업만으로도 시스템을 확장하기가 수월할 수 있다.
  • 관계형 데이터베이스와 잘어울리고 데이터 수준의 통합이 간으하다.
  • 4세대 언어 도구와 잘어울린다.
  • 애플리케이션을 인도했을때 유지보스 프로그래머가 이해하지 못하는 부분을 신속하게 재작업 할 수 잇다.

    단점

  • 데이터베이스를 이용하는 방식 말고는 여러 애플리케이션을 통합하기가 수월하지 않다.
  • 행위를 재사용하지 않으며 업무 문제에 대한 추상화가 이뤄지지 않는다. 업무 규칙이 적용되는 연산마다 업무규칙이 중복된다.
  • 신속한 프로토타입 작성과 반복주기가 SMART_UI 가 지닌 태생적인 한계에 도달하게 된다. 이는 추상화의 부재로 리팩터링 여지가 제한되기 때문이다.
  • 복잡성에 금방 압도되어 애플리케이션의 성장 경로가 순전히 부가적인 단순 응용으로만 향한다. 우아한 방법으로 더욱 풍부한 행위를 갖출 수 있는 방법은 없다.