2016. 12. 17. 16:27
Use Case는 Delivering 매커니즘과 분리되어야 한다. Design Pattern&UML2016. 12. 17. 16:27
Use Case는 Delivering 매커니즘과 분리되어야 한다.
https://youtu.be/sYPsm93qIkY?t=9m23s
UI DB Framework Tool에 대한 결정은 Use Case와는 완전히 Decoupled 되어야 한다.
(Decoupled = 상관 없다 = 절연되어야 한다)
Use Case와 구현사항(UI FW WAS 등)이 분리되면 좋은 이유
1. 클라이언트에게 설명이 쉽다
2. 좋은 UI, FW, WAS 등의 결정을 미룰 수 있다(= 충분한 시간을 갖고 생각할 수 있다)
시장에서 통하는지 만들어 보는건 시간이 생명(변수명 아무렇게나, 카피&페이스트 권장)
여기까지는 굉장히 좋은데, 문제는 이 조잡한 시제품에 개발을 이어간다는 것.
새로 만들어야 하는데 그렇게 하지 않아서 문제 발생할 때 있음(리팩토링이라도 해야 하지만, 리팩토링보단 새로만드는게 훨씬 좋음)
'Design Pattern&UML' 카테고리의 다른 글
Concrete Class(구상 클래스) (0) | 2016.12.17 |
---|---|
UML 기호 정리 (1) | 2016.12.17 |
클린코더 영상 보고 공부중 - 디자인 (0) | 2016.12.17 |
디자인 패턴의 5대 원칙 - SOLID (0) | 2016.12.11 |
[UML] 기호 정리 (초안) (0) | 2016.12.04 |