I Need Feedback.

이번 PLoP 2009에서 받았떤 저희 Half-Push/Half-Polling 패턴의 저자 워크샾에서 받았던 실제 피드백 내용을 정리했습니다. 몇 개가 더 있지만, 영어적인 문제라 뺐습니다.    Eduardo  교수님께서 일일이 잡아주셨습니다.  Eduardo 교수님 정말 감사합니다.

이걸 참고하셔서 좀더 피드백을 주시거나, 아래의 리스트와 다른 새로운 피드백을 주시면 감사하겠습니다.

Alias

Upgrade Ticket, Push/Pull Updater

패턴 명칭을 좀더 자세히 설명하기 위해 꼭 Alias 표기를 부탁함

2. Example

서버와 클라이언트의 수량이 얼마일 때 어느 정도의 성능이 나왔는지 구체적인 예가 있었으면 좋겠다 – 이 부분을 과연 Example에 하는 것이 맞을까 한다고 해도 뒷 부분에 별도의 세션을 만들어서 하는 것이 좋을 것 같음

Security Policy  -> 이 부분을 그냥 Policy로 가져가면 어떨까?

아파트 그림의 문제 -> 미국에서는 아파트는 임대용 쪽방을 의미함, 그렇기 때문에 미국 정서에 맞는 다른 용어 선정이 필요함. (미국인에게 물어봐야 겠다.)

3. Context

Target 환경이 명확하지 않다.

왜 클라이언트가 요청하는가? 이미 약속된 시간인데 -> 이 부분은 misconcept임 등록한 모든 Client가 항상 살아있는가?    5. Solutin에서 명확히 표기할 것

5.Solution

5.1 Structure

Poller의 IsUpgradePossilbe에 대한 설명이 빠져있다. -> 이 부분을 AreYouAlive 로 바꾸고 설명을 바꾸자.

그림 1. Pusher / Poller의 의미가 명확하지 않다. -> Component 다이어그램으로 Boundary를 부가적으로 표현했지만, 별도의 설명을 추가해서 Boundary을 명확히 기술하는 것이 어떨까?

5.2 Dynamics

Sequence Diagram의 오해 -> Reactor 패턴과 같이 Initialization Step과 Execution Step을 구분하여 표기해 주고, IsUpgradePossilbe을 AreYouAlive로 바꾸자.

그림 2. PushFiles()에 있는 메소드가 꼭 파일 정보를 내려줘야 하나? 그냥 Client가 가져가면 안되나? -> 다양한 클라이언트인 경우 내려줘야 하는 파일 목록이 다르므로, 이렇게 표기했음  이 부분도 표시해줄 것

그림 2. Main Program 이름이 이상하다. -> Server Application으로 변경할 것

제 시간에 오지 못했을 때, 어떤 일이 일어나는가? -> 뒷 부분에 Alive Check Manager로 주기적으로 체크하는데 좀더 고려해 볼것

6. Implementation

Step 2. 에 다루는 것이 QoS. -> 그럼 이 QoS에 따라 적합한 Algorithm이 있으면 설명해 주면 좋을 것 같다.

그림 3. Composite Message 패턴의. FragmentationLayer 무엇인가? -> 참가자들이 Composite Message 패턴을 몰라서 그런 것이 아닌가..

그림 4. 왜 UML을 쓰지 않았는가?

10. Related Pattern

각각의 패턴에 대한 Reference를 다시 표기해 줄 것

Reference

왜 Ordering 되어 있지 않는가?