Software Engineering 8 - MVC Architecture Pattern

 MVC(Model -View - Controller) : Architecture pattern
MVC를 구성하는 설계 패턴에는 observer pattern 등이 있다. MVC는 application object (model), UI(view), controller(user input 에 대한 UI reaction 정의)로 구성된다.
지난 시간에 배운 것 처럼 Non-UI layer(하위)를 UI layer(상위)가 사용하는 형태로 나타낼 수 있다. 메시지는 상위에서 하위로 흐른다. (상위가 하위를 호출하여 사용)
- Model : application의 여러 로직. 상태나 기능을 저장하여 다른 모듈에 제공(데이터 보관). data & business rule
- View : 실제 눈에 보이는 부분. model의 데이터를 display/rendering. 사용자의 입력을 받아 model이나 controller로 전달하는 역할. (실제 그 명령을 해석하지는 않음) 사용자의 눈에 보이는 모든 것들이 view.
- Controller : view의 behavior를 define (처리 해석), UI의 기능 하나마다 controller를 만들어 관리하는 방식으로 작동. 따라서 view가 보낸 user input에 대해 알맞은 행동을 결정하고 model을 호출하여 해당 행동을 처리하는 방식이다. (모델에 저장된 값을 변경)
유저가 화면에 보이는 버튼을 조작 -> view가 해당 행동을 controller에 전달 -> controller가 해당 행동에 알맞은 함수를 결정하고 model에서 함수 호출 -> model의 함수 호출에 의해 데이터가 알맞게 변경됨 -> 변경된 값을 다시 view가 참조하여 표시 (observer pattern) 단, non-ui layer는 ui layer를 알지 못하고(직접적으로 호출하지 않음) observe pattern의 interface만 알고 있음.
이런 구성은 UI를 변경했을 때 이 변경이 non-UI에도 영향을 미치지 않게 하고 싶기 때문이다. (dependency의 제한, change propagation) UI는 자주 업데이트 되지만 알고리즘과 자료구조는 그렇지 않다.
같은 데이터를 여러 다른 방식으로 표현하고, 이들과 사용자가 상호작용하여 값을 변경할 때, 각각의 표현방식에서 모두 동일한 변경이 일어나야 한다. 이를 효과적으로 해결할 수 있는 것이 바로 MVC방식이다. 데이터는 모두 model에 저장되어 있으므로 다른 방식의 view가 같은 곳을 참조하여 각각의 표현방식만 다르게 구현하면 되기 때문이다. 그래서 responsibility를 구분하였다.


Observer pattern(publisher & subscriber model)
publisher가 전파해야할 대상을 알지 못해도 업데이트 된 정보를 전달할 수 있게 하는 decoupling. 여기서 publisher(=subject)는 model이 되고, 업데이트 대상(subscriber = observer)은 view와 controller가 된다. 정보가 필요한 observer는 subject에게 구독신청을 하여 observer list에 포함되어 변경된 정보를 받을 수 있고, 필요 없어진다면 구독해제를 하여 더 이상 업데이트를 받지 않을 수도 있다. 이렇게 다이나믹하게 변경되는 one-to-many  구조이다.
이는 subject가 오직 observer interface만 알게 하여 구독자들이 이를 받아 구현하는 형식으로 이루어지기때문에 subject는 구체적인 것은 모르고 그냥 업데이트만 해줄 뿐, 실제 데이터를 가져가고, 참조하는 것들은 observer interface를 구현하는 구독자들이 하는 방식으로 구현된다.
설계 패턴은 일반적으로 코드 형식으로 구현되지 않고 지식의 재사용만을 의미하지만, observer pattern 처럼 너무 자주 사용되는 경우에는 코드로 구현되어 라이브러리 형태로 제공되기도 한다. java에서는 observable / observer class를 사용하여 이를 제공한다.
view/controller는 프레임워크마다 약간씩 담당하는 부분이 다를 수 있다. 그러나 UI - non UI의 구분은 확실히 해야 한다. 따라서 UI 부분을 들어내고 다른 UI로 교체하더라도 non UI는 어떤 행동을 할 필요도 없어야 한다. (litmus test - UI swap)

Object design
- dynamic model :logic/behavior of code/method를 정의. Interaction diagram(sequence / communication diagram) 이 해당.
- static model : package, class name, attribute, signature 등을 정의. UML class diagram이 해당.
interaction diagram을 먼저 그리고 class diagram을 그리는 것이 편리하다. (agile / up의 practice) 왜냐하면 interaction을 그리면서 각 클래스의 연관관계와 각 클래스에 어떤 method가 있어야 하는지 등을 정의할 수 있기 때문이다.


interaction diagram
앞서 살펴본 것 처럼 sequence/communication/timing/interaction overview의 네 가지로 구분할 수 있고, sequence와 communication은 같은 내용을 나타내지만 focus하는 것이 조금 다르다. (주로 이 둘을 많이 사용)
sequence diagram은 time sequence에 대해 object들의 collaboration을 나타냄. 반면에 communication diagram은 누가 누구와 (who - whom) message를 주고 받는지 더 중점을 둔다. 이 경우 시간 순서는 십진 분류법을 이용하여 나타낸다. 이 경우 상대적으로 공간을 적게 차지하므로 손으로 표현하기 편리하다.

- link : communication diagram에서 Link란 두 object 사이의 connection path를 나타낸다. class diagram에서 association 처럼 navigation과 visibility를 표현할 수 있으며 association, dependency, aggregation을 나타내는 instance와 같다. (inheritance는 아님)
- message : object 사이 오가는 메시지들은 link를 통해 전달되며 각 방향과 순서를 화살표와 숫자로 나타낸다. 맨처음 보내는 메시지는 숫자를 표시 안하는 경우도 있다. 이외에도 메시지가 특정 condition일 때 어떤 값을 가지거나, 혹은 전달되게 할 수도 있고, iteration을 설정하여 메시지가 전달되는 횟수를 설정할 수도 있다. 이런 것들은 sequence diagram에서 alt / opt / loop 등으로 설정했던 것과 모두 동일하다. (communication도 의미적으로는 동일하므로 모두 같은 feature를 표현할 수 있어야 한다.) 마찬가지로 object creation에 대한 메시지일 때는 따로 new나 make, creation 등을 따로 표기해준다. 그리고 static method를 사용할 때는 해당 object가 아니라 해당 클래스를 이용하는 것이므로 제공해주는 class에 <<meta class>>라는 것을 표기해준다.
또한 OOP에서 사용하는 Polymorphism 적인 메시지 전달(함수 사용)도 표현가능한데, {abstract}에서 정의된 함수를 메시지로 전달하고, 이를 구현하는 객체들이 같은 이름의 함수 메시지를 받은것으로 나타낼 수 있다. (별개의 diagram에서)
이런 것들은 sequence diagram에서도 동일하게 나타낼 수 있다. 그리고 일반적으로 method call은 return 값을 받을 때 까지 기다리는 synchronous call이다.


UML class diagram : conceptual perspective에서 domain model을 만드는데 사용할 수 있으며 design perspective에서 Design Class diagram (DCD- software perspective)를 만드는데도 사용할 수 있다. 전자는 전체적인 class의 종류와 관계, key feature 정도만 작성하지만, 후자는 개발의 관점에서 각각의 dependency 방향, 메서드 이름까지 모두 정의한다.
Keyword : textual adornment to categorize model element, 모델을 장식하여 부가적인 정보를 줌. 예를 들어 interface / abstract 등에 대해 <<actor>>, <<interface>>, {abstract} 등을 표시하는 것이 이 예시.
Stereotype : user가 작성할 수 있는 model의 refinement. UML의 extension mechanism을 제공하고 UML profile 내에 정의된다. (Keyword와 다른 점은 유저 정의, 확장이라는 점)  이는 도메인을 특화된 범위나 플랫폼에 확장/한정하여 쓰고 싶을 때 tag, constraint 등을 가지는 profile을 작성하여 나타내는 것이다. 그러므로 특정 분야의 개발을 할 때는 해당 profile이 어떤 것이 있는지 알고 사용하게 되면 더 편리하게 개발할 수 있다. 일반적으로 class/association 까지만 정의되어 있는 UML에 대해 각각을 더 세분화하여 나타내는 방식으로 stereotype을 사용하게 된다. (해당 클래스가 form인지, dialog box인지, button인지 등등을 더 자세하게 표시할 수 있다)