[5] 응용 행동 모델링

1. [5] 응용 행동 모델링 • 20장. 사건과 신호 • 21장. 상태 머신 • 22장. 프로세스와 쓰레드 • 23장. 시간과 공간 • 24장. 상태도

2. 20장. 사건과 신호 (Event & Signal) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 신호 패밀리 모델링 • 예외 모델링 • 힌트와 조언

3. 사건 선언 Idle <<signal>> OffHook OffHook / dropConnection( ) Active 사건 시작하기 • 사건과 신호 (Events & Signals) • 사건(Event)이란 실 세계에서 발생하는 시간과 공간을 점유하는 의미 있는 일 • 신호란 사건에 발생하는 자극 • 사건은 동기 또는 비동기로 발생하며, 사건 Model은 Process Model과 Thread Model로 완성 됨 • 상태 머신(State Machine) 문맥에서는 사건을 이용하여 자극이 상태 전이를 발생 시키는 행위를 Model로 작성 함. • 사건에는 신호, 호출, 시간 경과, 상태 변경 등이 발생

4. Signal MovementAgent position velocity moveTo( ) <<send>> <<signal>> Collision force : Float Parameter Send Dependency 용어와 개념 • 사건 종류 (Kinds of Events) • 내부 사건 : System 내부의 Object 간에 발생하는 사건 • 외부 사건 : System과 Actor 간에 발생하는 사건 • UML의 사건 Model 종류 • Signal • Call • Pass of Time • Change in State • 신호 (Signal) • 한 Object에서 비동기로 전송하면 다른 객체에서 수신하는 것 • Signal은 Class와 유사하며 Instance를 만들 수 있고 일반화 관계를 이용하여 사건 계층 Model을 갖을 수 있음

5. startAutopilot(normal) Manual Automatic Event Parameter Time Event when (11:49 PM) / selfTest( ) Change Event after (2 seconds) / dropConnection( ) Idle Active • 호출 사건 (Call Events) • Operation이 발생되는 것 (동기적) • 한 Object가 State Machine이 있는 다른 Object에 속한 Operation을 Invoke(가동) 시키면 Control은 발송자로부터 수신자로 사건 전이 촉발 • Operation이 완료되면 수신자는 새로운 상태로 전이되며 제어는 발송자로 복귀 • 시간(Time) 사건과 변경(Change) 사건 • 시간 사건 : 시간의 경과를 나타내는 사건 • 변경 사건 : 상태의 변경 즉, 어떤 조건이 만족되는 것을 나타내는 사건

6. 활성 Class KeypadManager Signals pushbutton(b : button) powerUp powerDown Signal • 사건 보내기와 받기 (Sending and Receiving Events) • 신호 사건과 호출 사건은 적어도 두 Object와의 관련(신호를 보내거나 Operation을 기동 시키는 Object와 사건이 향하고 있는 Object가 존재) • Class에서 나오는 모든 Instance는 수신 Object에게 Signal을 보낼 수 있고 Operation을 기동 시킬 수 있으며 Class의 어떤 Instance이건 호출 사건 즉 Signal을 받을 수 있음

7. <<signal>> RobotSignal <<signal>> Collision sensor : Integer <<signal>> HardwareFault <<signal>> BatteryFault <<signal>> MovementFault <<signal>> VisionFault <<signal>> RangingFault <<signal>> MotorStall 보편적 모델링 기법 • 신호 패밀리 (Family of Signal) Modeling • 사건 중심 System에서 신호 사건은 계층적 임 • 신호 계층을 Modeling하면 다형성 사건을 명세화 할 수 있음 • Signal Family Modeling • 주어진 활동 Object가 응답할 수 있는 모든 종류의 신호를 고려 • 공통으로 사용되는 신호를 파악하여 상속을 이용해서 일반화/특수화에 배치 • 활성 Object의 State Machine에서 다형성이 될 수 있는 것을 파악

8. <<exception>> Exception setHandler( ) firstHandler( ) lastHandler( ) item <<signal>> MovementFault Set add( ) remove( ) <<send>> <<signal>> VisionFault <<send>> <<signal>> RangingFault <<send>> • 예외 (Exception) Modeling • 하나의 Operation이 발생할 수 있는 예외 신호를 명세화 • 예외도 신호의 한 종류이며 Stereotype Class로 Model화 • Exception Modeling • 각 Class와 Interface나 요소들의 Operation에 대해 발생할 수 있는 예외 조건을 파악 • 예외들을 계층적으로 배열 • 각 Operation에 대하여 예외가 발생할 수 있는 것을 명세화

9. 힌트와 조언 • Event Model 만들 때 • 신호 계층을 구축하여 관련된 신호들에 있는 공통 Property를 발견 • 정상 제어 흐름을 대치하면서 신호를 보내거나 예외가 없도록 • 사건을 수신하는 각 요소마다 합당한 State Machine이 있는가 확인 • 사건을 수신하는 요소들을 Modeling하는 것 외에 사건을 발생하는 요소들을 Modeling • UML로 사건을 표현할 때 • 사건 계층은 명시적으로 표현하고 사용에 관한 것은 사건을 발송/수신하는 각 Class 또는 Operation의 이면(Backplane)에서 Model을 작성

10. 21장. 상태 머신 (State Machine) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 객체 생명 주기 모델링 • 힌트와 조언

11. Final State Initial State shutDown Idle Event Parameter Action State tooCold(desiredTemp) tooHot(desiredTemp) Heating Event atTemp Activating atTemp ready / turnOn( ) Cooling tooHot(desiredTemp) Active tooCold(desiredTemp) Nested State Transition 시작하기 • State Machine • State Machine을 이용하여 개별 Object의 행동(동적인 측면)을 Modeling하며 이는 Object가 생명주기 동안 통과하는 State들을 발생하는 순서대로 명시한 행동이며 Object는 사건이 도달되면 반응하고 사건에 응답 • State Machine의 두 가지 방법 • 활동도(Activity Diagram) : Object 안에서 발생하는 활동에서 초점을 두어 한 활동에서 다른 활동으로 전달되는 Control Flow를 강조 • 상태도(Statechart Diagram) : 사건 요구에 따른 Object가 취할 수 있는 행동에 초점을 두고 상태들 사이의 전이를 강조 - 반응 System 모형 작성에 유용

12. 용어와 개념 • State Machine : 상태가 순차적으로 발생하는 것을 명세화 한 행동이며 Object는 생명 주기 동안 사건에 따라 상태를 변경해 가며 사건에 대한 응답 수행 • State : Object가 생명 주기 동안 가질 수 있는 조건(상황)이며 특정 조건이 만족된 상태에서 활동을 수행하고 사건을 기다림 • Event : 시간과 공간에서 위치를 점유하고 있는 중요한 발생 명세서로써 자극이 발생되며 상태 전이를 촉발 • Transition : 두 상태 간의 관계로써 특정 상태에 있던 Object가 동작을 수행한 후 사건이 발생하고 정해진 조건이 만족되었을 때 다음 상태로 전환 • Activity : State Machine안에서 비 원자성으로 실행 • Action : 실행될 수 있는 원자성 연산으로 Model 상태를 변경하거나 Return 값을 발생 • 문맥 (Context) • Object가 생명 주기 동안에 다른 Object에 작용할 수 있고, 작용 받을 수 있는 동기적인 것을 포함하며 이들 Message들은 단순한 동기 Operation을 호출 • State Machine은 신호를 받을 수 있는 Class 들의 Instance와 활동 Object도 포함 • 비 동기적 자극이 오면 응답해야 하는 Object 행동이나 객체의 현 행동이 과거에 의존하는 경우 State Machine을 이용하여 명세화 하는 것이 바람직

13. shutDown keyPress Idle Running finished 상태 명칭 • 상태 (State) • Object 생명 주기 동안에 가질 수 있는 특정 조건(상황)이며 해당 기간 동안 Object는 조건이 만족된 상태에서 활동을 수행하고 다른 사건도 기다림 • 상태의 구성 • 명칭(Name) : 특정 상태와 다른 상태를 구분 짓는 문자열로 구성된 이름 • 진입/탈출 동작(Entry/Exit Action) : 상태에 들어오거나 나갈 때 수행되는 동작 • 내부 전이(Internal Transition) : 상태 변경을 초래하지 않고 처리되는 상태 내의 전이 • 하위 상태(Substate) : 중첩(Nested) 구조로 된 상태이며 배타적 하위상태(순차적 활성화)나 동시적 하위 상태(동시적 활성화) • 지연 사건(Deferred Event) : 사건 목록으로써 현 상태에서 처리되지 않고 다른 상태에서 처리하기 위하여 대기 Queue에 저장되는 사건 • 초기 상태와 종료 상태

14. 시간 사건 After (2 seconds) / send c.isAlive 재귀 전이 사건 Trigger Trigger 없는 전이 전송 신호 Idle noise Searching Engaging 매개 변수 있는 사건 Trigger 전이 조건 shutDown targetAt(p) [isThreat] / t.addTarget(p) Tracking contact Engaging 동작 • 전이 (Transition) • 특정 Object가 현 상태에서 어떤 동작을 수행한 후 지정된 상태가 발생하고 지정된 조건이 만족되었을 때 다음 상태로 들어가는 두 상태간의 관계 • 전이의 5 부분 • 원래 상태(Source State) : 전이에 의해 바뀌는 상태 • 촉발 사건(Event Trigger) : 원래 상태의 객체가 한 사건을 받았을 때 조건이 만족되어 전이를 합당하게 수행할 수 있는 조건 • 전이 조건(Guard Condition) : 촉발 사건이 수신되어 전이 촉발 시에 검토되는 Boolean 식(True이면 수행) • 동작(Action) : 실행 가능한 원자성 연산, Object에 직접 또는 간접적으로 발생하는 작용 • 목표 상태(Target State) : 전이가 완료된 후의 활성 상태

15. Tracking entry / setMode(onTrack) exit / setMode(offTrack) newTarget / tracker.Acquire( ) do / followTarget selfTest / defer 명칭 진입 동작 탈출 동작 내부 전이 활동 지연 사건 • 상태와 전이의 응용 (Advanced States & Transitions) • 행동 모형이 복잡해질 때 활용 • 고급 특성 • 진입 / 탈출 동작(Entry/Exit Action) : State에 들어갈 때 진입 동작 실행, State를 떠날 때 탈출 동작 실행 • 내부 전이(Internal Transition) : 재귀 전이와는 차이가 있으며 상태 내부에서 접하는 사건들을 처리하되 상태를 벗어나지는 않음 • 활동(Activity) : Object가 한 상태에 있을 때 유휴 상태에서 사건 발생을 기다리거나 진행중인 행동을 Model화 하는데 한 상태에 있는 동안은 상태에서 어떤 일을 수행하며 이는 Event가 도달하면 Interrupt가 발생 됨 • 지연 사건(Deferred Event) : 특정 사건이 동작되기 전에는 다른 사건들이 연기(대기)

16. 복합 상태 복합 상태의 전이 순차 하위 상태 cardInserted Idle Active Activating cancel [continue] maintain Selecting Processing Maintenance [not continue] Printing entry / readyCard exit / ejectCard 하위 상태로부터의 전이 • 하위 상태 (Substate) • 단순(Simple) 상태 : 하위 구조를 갖지 않는 상태 • 복합(Composite) 상태 : 하위 상태를 포함하는 중첩(Nested) 상태 • 복합 상태는 동시(직교성(orthogonal)) 하위 상태 또는 순차(배타적(Disjoin)) 하위 상태를 포함 • 순차 하위 상태(Sequential Substate) • Active 순차에 있는 모두로부터 나오는 전이를 한꺼번에 표현 • 순차 하위 상태들은 복합 상태의 사태 공간을 분할하여 배타적 상태가 됨

17. 얕은(Shallow) 이력 상태 첫번째 진입의 초기 상태 BackingUp Collecting H Command query Copying CleaningUp • 이력 상태(History State) • Object가 복합 상태를 떠날 때 활동한 마지막 하위 상태를 기억하고 있는 Object Model을 만들 필요가 있을 때 사용

18. Idle 분할(fork) 합류(join) maintain 복합 상태 Maintenance 동시 하위 상태 Testing Testing devices Self diagnosis Commanding [continue] Testing devices Self diagnosis keyPress [not continue] • 동시 하위 상태(Concurrent Substate) • 포함된 Object들의 문맥에서 동시적으로 실행되는 State Machine이 두개 이상 나타낼 때 사용 • 동시 하위 상태는 실행이 병렬도 진행되다 각 중첩 State Machine이 종료 상태에 도달

19. 보편적 모델링 기법 • Object 생명 주기(Lifetime) Modeling • Interaction은 함께 작동하는 Object 들의 행동 Modeling에 활용하며, State Machine은 한 Object Lifetime Modeling으로 Class의 Instance, Use Case, 전체 System Model의 사용자 Interface, Controller, Device 등을 대상으로 함 • Object Lifetime Modeling • State Machine의 문맥을 설정(Class, Use Case, 전체 System을 대상) • Object의 초기 / 종료 상태 설정 • Object가 응답할 수 있는 Event 파악 • 초기 상태에서 시작하여 종료 상태에 이르기까지의 Object 상태들을 배치 • 진입 동작과 탈출 방법을 식별 • 각 상태들을 하위 상태를 이용하여 필요한 만큼 확장 • State Machine에 표현된 각 사건들이 Object Interface에서 예견되는 사건들과 부합되는지 확인 • State Machine에 표현된 각 Action들이 Object를 내포한 관계와 Method, Operation에 의해 유지되는지를 점검 • State Machine을 Trace하면서 예견되는 사건 순차와 응답을 보면서 확인 • State Machine을 재 배치한 후에 예견되는 순차를 보면서 다시 점검하며 Object 의미가 바뀌지 않았는지를 확인

20. Initializing after(10 seconds) / selfTest Idle attention alarm(s) clear Command Active Checking attention Calling entry / callCenter(s) Entry / setAlarm exit / clearAlarm Waiting

21. 힌트와 조언 • 구조가 좋은 State Machine • 단순하며 State나 Transition이 과다하지 않을 것 • 문맥이 분명하며 내포된 Object에서 가시적인 모든 Object에 접근 가능 • 시간과 자원을 동작 요구에 최적으로 활용되도록 • System에 존재하는 어휘로 State나 Transition 명칭을 사용하여 이해하기 쉽도록 • 과다한 중첩을 피할 것 • 동시 하위 상태를 많이 사용하지 말 것(활용 Class 사용) • UML로 State Machine을 표현할 때 • 가능하면 Transition이 교차하지 않도록 • 복합 상태를 확장할 때는 Diagram을 이해하기 쉽게 하는 범위로 한정

22. 22장. 프로세스와 쓰레드(Process & Thread) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 다중 제어 흐름 모델링 • 프로세스간 통신 모델링 • 힌트와 조언

23. Active Class BackgroundController currentKnowledgeSource Signals blackboardIsSovned hasAHint Name Attribute Operation Signal 시작하기 • Process와 Thread • System Model의 Process View에 해당 • System의 병렬 및 동기화 Mechanism을 구성 시키는 Thread와 Process를 포함 • 독립된 각 제어 흐름은 활동 객체(Active Object)로 Modeling하며 제어 활동을 주도할 수 있는 Process나 Thread로 구성 • Process : 비교적 큰 흐름의 표현으로 다른 Process와 병행으로 실행 • Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread와 병행으로 실행

24. 용어와 개념 • Active Object : Process나 Thread를 소유하고 있는 Object로써 제어 활동을 주도 • Active Class : 자신의 Instance가 활성 객체인 Class • Process : 비교적 큰 흐름의 표현으로 다른 Process와 병행으로 실행 • Thread : 비교적 적은 흐름 표현으로 동일 Process 내의 다른 Thread와 병행으로 실행 • 제어 흐름 (Flow of Control) • 특정 순간에 발생하는 사건의 진행 • 순차 System의 제어 흐름은 한 개이며 동시 System에서는 두 개 이상 임 • Class와 Event • Active Class도 Class의 일종이지만 독립적인 제어 흐름을 갖는 다는 점이 다름 • Active Object는 Active Class의 Instance로써 Process와 Thread를 구현 • Active Object는 비활성(Passive) Object가 표현되는 곳이면 어디에서나 활용 가능하며 State Machine에서 사건의 목표를 표현할 수 있음 • 표준 요소 (Standard Element) • UML 확장 Mechanism은 모두 Active Class에 적용(Tagged Value 활용) • 적용 표준 Stereotype • Process • Thread

25. 통신 (Communication) • Object 간의 협력은 그들 Message를 서로 전달하며 교류 • 교류 방법 • 비활성 객체 비활성 객체 : Operation이 단순히 호출되는 것 • 활성 객체 활성 객체 : 한 활성 객체가 다른 객체 Operation을 동기로 호출 비동기로 신호를 보내거나 객체 Operation을 호출 • 활성 객체 비활성 객체 : 두 개 이상의 활성 객체가 한 순간에 각각의 제어 흐름을 비활성 객체로 통과 시키는 경우 • 비활성 객체 활성 객체 : 활성 객체에서 활성 객체로 Message를 통과시키는 것과 동일 Active Object b : Blackboard Synchronous Message Asynchronous Message c1 : initialize( ) 2 : placePartialSolution( ) 1 : hasAHint(k) c : BlackboardController : KnowledgeSource Flow Sequence c2 : startSearch( ) c3 : k.evaluate( )

26. Name Buffer size : integer add( ) {concurrent} remove( ) {concurrent} Attribute Operation Synchronization Property • 동기화 (Synchronization) • 흐름이 Operation을 통과할 때 주어진 한 순간의 제어 자취는 Operation에 있으며 Operation이 다른 Object의 활동을 유발 • 한 Operation은 각 제어흐름을 갖을 수 있고 또한 여러 제어 흐름이 존재 가능 • 한 Object 내에서 여러 제어흐름이 있을 때 서로의 흐름이 방해하지 않도록 • 순차(Sequential) : 호출자는 Object 외부와 조정을 하여 한 순간에 단 한 개의 흐름만 존재하도록 • 감시(Guarded) : 복수 제어 흐름이 존재할 때 Object의 감시를 받는 모든 Operation을 순차화 하여 Object 의미와 무결성 보장 • 동시(Concurrent) : 복수 제어흐름이 있을 때 Operation을 원자성으로 취급하여 객체 의미와 무결성 보장 • Process View • Active Process는 System의 Process View를 가시화, 명세화, 구축, 문서화 • System Process View는 동시성과 동기화 Mechanism을 형성하는 Thread와 Process를 포함(System의 성능, 신축성, 처리량 등을 포함)

27. s1 : postValue( ) c : CNNNewsFeed s : StockTicker s : StockTicker c1 : postBreakingStory( ) s2 : postAlert( ) m1 : postAlert( ) m : AlertManager t : TradingManager i2 : postAlert( ) i1 : postValue( ) i : IndexWatcher i : IndexWatcher 보편적 모델링 기법 • 다중 제어 흐름 (Multiple Flow of Control) Modeling • 복수 제어 흐름을 포함한 System은 동시 활성 객체의 작업 순서를 결정해야 하며 System의 활성 객체와 비 활성 객체와의 정확한 통신이 되도록 설계 • 제어의 다중 흐름 Modeling • 동시 활동 가능성을 식별 후 각 흐름을 구체화하여 Active Class로 구현 • Active Class 책임을 균형 있게 분산하고 각 Class 들이 정적으로 협조하고 있는 다른 Active Class와 Passive Class를 조사 • Active Class들을 명시적으로 부각시키며 정적인 결정 사항을 획득 • 각 Class Group 들이 서로 동적으로 협력하는 방법을 파악 • Active Class 간에 발생하는 Communication을 조사 • Active Class와 협력중인 Passive Class와의 동기화에 주의를 기울여 도식

28. Communicates across Beans messaging service CORBA ORD Server r2 : make( ) <<process>> r : ReservationAgent {location = reservation server} t1 : planTrip( ) Client <<process>> t : TicketingManager {location = airline server} r3 : postResults( ) <<process>> t : TripPlanner {location = client} r1 : make( ) <<process>> h : HotelAgent {location = hotel server} • 프로세스간 통신 (Interprocess Communication) Modeling • System에서 복수로 수용되는 제어 흐름을 상주하는 Object간에 통신하는 Mechanism 도식 • Process간 통신 Modeling • 복수 제어 흐름 Model 작성 • 활성 객체 중 Process와 Thread를 Stereotype을 이용하여 구분 • Message Model을 비동기 통신으로 하고 동기 통신으로 Remote Procedure CallModel 작성 • Note를 활용하여 하부 통신 Mechanism을 명세화

29. 힌트와 조언 • 구조가 좋은 Active Class와 Active Object • 독립 제어 흐름으로 표현하여 System 동시성의 잠재력을 높임 • 다른 활성 요소들이 복수로 표현될 정도로 적지 않도록 • 활성 요소들 간의 통신은 동기식과 비동기식 Messaging을 선택하여 표현 • 각 Object를 임계 지역(Critical Region)으로 주의 깊게 취급 • Process와 Thread 의미를 명시적으로 구분 • UML로 Active Class와 Active Object를 표현할 때 • 문맥 내의 추상 개념을 이해하기에 충분한 정도의 Attribute, Operation, Signal 들만 표현 • 모든 동기 Property를 명시적으로 표현

30. 23장. 시간과 공간 (Time & Scope) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 시간 제약 모델링 • 객체 분산 모델링 • 이주 객체 모델링 • 힌트와 조언

31. 위치 c : Client {location = console} m : MapServer {location = server} c : MapCache {location = missionserver} a : getMap(region) b : getMap(region) 시간 표시 {a.executionTime < 10ms} 시간 식 시간 제약 시작하기 • 시간과 공간 (Time & Space) • 시간과 공간 Model을 만드는 일은 실시간 / 분산 System에서는 필수 요소이며 시간 표시, 시간 표현식, 제약, 꼬리표 값 등을 포함하여 System 표현 • System의 시간과 공간 특성을 필요 / 충분하게 반영 • 실시간 분산 System • 실 시간 System • 분산 System

32. {every 1 ms} c1 : testKeys( ) 시간 제약 c : MIDIController : KeyCollection {executionTime < 10ns} c2 : testKey( ) k : Key c3 : add(k) {every 1 ms} t1 : remove( ) B : MIDIEventBuffer c : MIDITransmitter 용어와 개념 • 시간 표시(Timing Mark) : Event가 발생하는 시간 표시 • 시간 표현식(Time Expression) : 절대 시간 / 상대 시간을 검사하는 표현식 • 시간 제약(Time Constraint) : 시간과 관련된 모든 제약 • 시간 (Time) • System에서 시간상 규칙적 / 비 규칙적으로 발생할 내용 표현 • 사건에 대한 응답은 예측 가능한 절대 시간이나 사건에 상대적으로 예측 가능한 시간에 표현

33. <<processor>> KioskServer Deploys vision.exe log.exe selftest.exe Location by Nesting : LoadAgent {location = Router} Location Tagged Value • 위치 (Location) • 여러 지역에 분산되어 있는 System Node들의 물리적인 Component들을 표현

34. {a : startTime every 1 ms} S : SystemAgent P : ServerPage C : Camera a : refresh( ) b : getImage( ) {getImage.executionTime is proportional to image size.} {b.executionTime < 100ns} 보편적 모델링 기법 • 시간 제약(Timing Constraint) Modeling • 시간 제약을 이용하는 실 시간 System의 Time Critical Property • 사건의 절대 시간 Modeling • 사건간 상대 시간 Modeling • 한 동작을 수행하는데 걸리는 시간 Modeling • Timing Constraint Modeling • 교류에 있는 각 사건에 대해 절대 시간에 시작되어야 할 대상을 파악 • 교류에서 관심 대상인 Message의 각 순서에 대해 연관된 상대 시간을 파악 • 각 Class에 존재하는 시간이 급한 Operation에 대해 시간 복잡성을 파악

35. o : Order {location = Workstation} s : Sales {location = Workstation} a : ObserverAgent {location = Server} p : Product {location = Server} p : ProductTable {location = DataWarehouse} • 객체 분산(Distribution of Object) Modeling • 분산 System Topology를 만들 때 고려해야 할 Component와 Class Instance의 물리적 배치 • Object Distribution Modeling • System 관심 대상 Object들에 대해 참조의 지역성을 파악 • 관련 Object 집합에서 교류 Pattern을 파악하고 교류 정도가 높은 Object끼리 모음 • Node별 부하 균형을 고려하여 분산 • 보안, 취약성, Service 품질을 고려하여 Object 분산을 재 배치 • 배치도의 Node로 Object를 중첩 시키거나 꼬리표 값으로 Object 위치를 명시적 표기

36. 1 : bid( ) t : TravelAgent {location = United server} : Auctioneer {location = United server} 1.1 : <<become>> 2 : bid( ) t : TravelAgent {location = SAS server} : Auctioneer {location = SAS server} i : Itinerary {location = client server} 2.1 : <<become>> 3 : bid( ) t : TravelAgent {location = TWA server} : Auctioneer {location = TWA server} 3.1 : <<become>> 4 : tenderBid( ) t : TravelAgent {location = client server} • 이주 객체(Object that Migrate) Modeling • 분산 System 하에서 Class 들이 서로 다를 Node로 이동 • Object 들이 보다 좋은 결과를 산출하기 위해 • Node의 연결 실패, Node의 균형 잡힌 부하를 위하여 • Object Migrate Modeling • 물리적 Object들을 전송할 기반 Mechanism 선택 • 한 Node에 Object를 할당 시키되 꼬리표 값으로 위치를 명시적 표시 • Stereotype Message인 Become, Copy를 이용하여 한 Object를 새로운 Node에 할당 • 동기화 문제와 고유성 문제를 숙고

37. 힌트와 조언 • 구조가 좋은 시간과 공간 Property • System 행동 요구 획득에 필요 / 충분한 시간, 공간 Property만 표현 • Property 사용을 중앙에 위치시켜 찾기 쉽고 바꾸기 쉽게 • UML로 시간과 공간 Property를 표현할 때 • 시간 표시(Message Name)에 의미 있는 명칭 부여 • 상대 시간 표현식과 절대 시간 표현식을 명확히 구분 • 공간 Property는 주로 꼬리표 값으로 표현

38. 24장. 상태도 (Statechart Diagram) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 반응 객체 모델링 • 순공학과 역공학 • 힌트와 조언

39. Transition Idle Nested State Event State ringing Receiving sendFax Connected headerOk hangUp Event Transmitting Processing Error / printReport checkSumOk Action Cleaning up Entry / pickUp exit / disconnect Triggerless Transition Composite State 시작하기 • 상태도 (Statechart Diagram) • State Machine으로 System의 동적 측면 Modeling하는 것으로 반응(Reactive) Object의 행동 Model을 작성 • 활동도 와 상태도 • 활동도(Activity Diagram) : 활동에서 활동으로 가는 제어 흐름을 표현하는 상태도의 특별한 경우 • 상태도(Statechart Diagram) : 상태에서 상태로 가는 제어흐름을 표현

40. 용어와 개념 • 공통 (Common) Property • 다른 Diagram과 마찬 가지로 공통 성질을 공유 • 내용 (Contents) • 상태도에 포함되는 내용 • 단순 상태(State)와 복합 상태(Composite State) • Event, Action, Transition • Note, Constraint, .. • 공통 이용 (Common Use) • 동적 측면을 Modeling하는 것은 System Architecture 관점에서 어떤 종류의 Object에 있는 Event Sequence에 관한 행동을 모형화 • 반응 객체(Reactive Object) 즉, 사건 중심 객체는 문맥 외부에서 발송된 사건에 응답하는 것을 Modeling

41. 보편적 모델링 기법 • 반응 객체 (Reactive Object) Modeling • 반응 객체 명세화 세 가지 요소 • Object가 살아갈 수 있는 안정된 상태 • 상태에서 상태로 전이를 촉발시키는 사건 • 상태가 바뀔 떄 일어나는 동작 • Reactive Object Modeling • State Machine 문맥 결정 • Object의 초기 상태와 종료 상태 결정 • Object가 식별 가능한 시간동안 존재할 수 있는 조건을 고려하여 안정된 상태를 결정 • Object 생명 주기에서 안정 상태들이 부분적으로 의미 있도록 순서 결정 • 상태에서 상태로 전이를 촉발시키는 사건 결정 • 동작을 전이 또는 상태에 첨부하거나, 양쪽 모두에 첨부 • 하위 상태, 분기, 분할, 합류, 이력 상태를 이용하여 Machine을 단순화 시킬 방안 파악 • 사건들이 여러 조합으로 발생될 때 모든 상태에 도달될 수 있는가 파악 • Object 상태 중에서 어떤 사건이 발생하더라도 상태 밖으로 나갈 수 없는 상태가 없는가 확인 • State Machine을 추적해 가면서 사건 순서나 응답이 예상대로인지 확인

42. Waiting put(c) [c == ‘;’] / return false put(c) [c == ‘<‘] / return false put(c) [c /= ‘< ’] / return false GettingToken put(c) [c == ‘>’] / return false put(c) [c /= ‘>’] / token.append(c); return false GettingBody put(c) [c /= ‘;’] / body.append(c); return false

43. 순공학과 역공학 (Forward & Reverse Engineering) • 상태도에서 순공학 즉 Model에서 Code 생성하기는 가능 • 순공학 도구로 작성된 Message Parser Class에 대한 Java Code 예제 Class Message Parser { case GettingBody : public if (c == ‘;’) boolean put (char c) { state = Waiting ; switch (state) { else case Waiting : body.append(c) ; if (c == ‘< ’ { return true; state = GettingToken ; } token = new StringBuffer( ) ; return false ; body = new StringBuffer( ) ; } } break ; case GettingToken : if (c == ‘>’) state = GettingBody ; else token.append(c) ; break ;

44. StringBuffer getToken ( ) { return token ; } StringBuffer getBody ( ) { return body ; } private final static int Wating = 0 ; final static int GettingToken = 1 ; final static int GettingBody = 2 ; int state = Waiting ; StringBuffer token, body ; • 역공학은 이론적으로 가능하지만 실용적이지 못 함

45. 힌트와 조언 • 구조가 좋은 상태도 • System의 동적 측면을 표현하는데 초점 • 이해하는데 필수적인 요소만 표현 • 추상화 수준에 따라 일관성 있게 상세성 제공 • 형태간 균형 유지 • 상태도를 작성할 때 • 명칭 부여는 목적을 전달할 수 있도록 • Object의 안정된 상태 Modeling으로부터, 상태에서 상태로 적법한 전이 Modeling을 진행 • 요소 배열 시 교차되는 선이 최소화 되도록