[6] 아키텍쳐 모델링

1. [6] 아키텍쳐 모델링 • 25장. 컴포넌트 • 26장. 배치 • 27장. 협력 • 28장. 패턴과 프레임웍 • 29장. 컴포넌트도 • 30장. 배치도 • 31장. 시스템과 모델

2. 25장. 컴포넌트 (Component) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 실행 파일과 라이브러리 모델링 • 테이블, 파일, 그리고 문서의 모델링 • API 모델링 • 소스 코드 모델링 • 힌트와 조언

3. 시작하기 • Component • Component와 Deployment는 System의 물리적 관점을 Modeling하는 중요 요소 • 실행 File, Library, Table, File, document 같이 Node에 존재하는 물리적인 요소를 Modeling하는데 사용 • 물리적이며 교체 가능한 System의 한 부분 • 정의가 명확한 Interface로 추상 개념 정의하며 새롭고 호환성있는 Component로 교체하기 쉽게 작성 명칭 kernel32.dll

4. Simple Name fraudagent.dll Realizes FraudAgent FraudPolicy PatternSearch agent.java Path Name 확장 Component system::dialog.dll {version = 2.0.1.75} 용어와 개념 • 명칭 (Name) • 다른 Component와 구분하기 위한 문자열로 된 명칭이 반드시 필요 • 단일명과 Component가 속한 Package 명을 앞에 붙인 경로명사용 • Class와 마찬가지로 Tagged Value를 사용하며 구획을 추가 가능

5. Component Class 명칭 존재 존재 Interface 실현 가능 가능 관계 표현 의존, 연관, 일반화 의존, 연관, 일반화 중첩 가능 가능 Interaction 참여 가능 참여 가능 추상화 단계 논리적 물리적 추상화 정도 상세 비교적 상세 표현 속성, 오퍼레이션을 직접 표현 Interface를 통한 Operation fraudagent.dll Componet Class FraudAgent FraudPolicy PatternSearch • Component 와 Class • Component와 Class는 매우 유사함

6. Component와 Interface • Interface는 Operation의 모음으로써 Class와 Component의 Service를 명세화 하는데 사용 • Component를 함께 묶는 수단으로 Interface를 사용 • Interface를 통해 Service를 호출하는 다른Component들과 함께 그 Interface를 실현하는 Component들을 준비 • Interface간의 관계 표현 • 생략된 Icon형으로 표현 • Operation을 나타내는 확장된 형태로 표현 • Interface 종류 • Export Interface : Component가 실현하는 Interface를 말하며 다른 Component들에 대한 Service로 제공 • Import Interface : Component가 사용하는 Interface로써 외부 Component가 포함한 내용을 의존 사용하는 Interface

7. Icon 형태 image.java component.java ImageObserver 의존 현실화 확장 형태 Interface image.java <<interface>> ImageObserver abort : int{final static} error : int{final static} imageUpdate( ) : Boolean component.java

8. 이진 교차성 (Binary Replaceability) • Component 기반 Operating System의 기본 취지는 이진 교차 가능한 부분들로 System을 조립하게 하는 것 • System을 새로 구축하지 않고 새로운 Component를 추가하거나 존재하는 것을 교체하여 System을 발전 시킴 • Component는 Bit로 된 세계에 있으며 개념적인 것이 아닌 물리적인 것 • Component는 교체 가능(같은 Interface를 준수하는 다른 것으로) • 다른 Component와 협력하면서 Architecture 또는 기술적 상황에서 사용될 목적으로 존재하는 System의 한 부분 • Component는 전해진 Interface를 준수하고 구현 • Component 종류 • 배치(Deployment) Component : 동적 라이브러리(DLL), 실행 File과 같은 것으로 실행 가능한 System 구성에 필요/충분 한 것 • 작업 결과(Work Product) Component : 개발 Process의 산출물로써 배치 Compo nent를 생성하는 Source Code File 및 Data File 등이며 개발 작업에서 만들어진 산출물이며 실행 System을 생성하는데 사용 • 실행(Execution) Component : 실행 System의 수행 결과로 생성되는 Component

9. Component의 구성 • Class를 구성하는 것과 같은 방법으로 Component를 Package에 Group화하여 구성 가능 • Component 간의 의존, 연관, 일반화 관계, 구체화 관계를 명기하여 구성 가능 • 표준 요소 • 5가지 표준 Stereotype • Executable(실행) : Node에서 실행될 수 있는 Component를 명세화 • Library : 정적/동적 객체 Library를 명세화 • Table : Database Table을 나타내는 Component를 명세화 • File : Source Code 또는 Data를 포함하는 문서를 나타내는 Component를 명세화 • Document(문서) : 문서를 나타내는 Component를 명세화

10. dlog.dll animator.exe {version = 5.0.1} wrfrme.dll render.dll raytrce.dll 보편적 모델링 기법 • 실행 File과 Library Modeling • System에 포함되는 다수의 실행 File과 이들에 연관된 객체 Library로 구성 • 실행 File과 Library Model 구성 방법 • 물리적인 System을 어떻게 분할할 것인가를 확인(기술적, 형상관리, 재사용 측면) • 적합한 표준 요소를 사용하여 모든 실행 File과 Library를 Component로 Modeling • Component간 중요한 연결은 Interface로 Modeling • 실행 File, Library, Interface 간의 관계를 Model에 표현하고 의존성을 Model에 표현(변화에 대한 영향을 가시화)

11. animator.hlp dlog.dll animator.exe {version = 5.0.1} animator.ini wrfrme.dll Shapes.tbl render.dll raytrce.dll • Table, File, Document Modeling • 부수적 배치 Component로써 Data File, 도움말 File, Script Log File, 초기화 File, 설치/제거 File 등 을 Component로 표현 • Table, File, Document Model 구성 • 부수적 Component 확인 • 적합한 Stereotype 등을 이용하여 Component로 Modeling • 부수적 Component들과 실행 File, Library, Interface 간의 관계를 Modeling하고 의존성을 Model에 표현(변화에 대한 영향을 가시화)

12. IScripts animator.exe {version = 5.0.1} IRendering IApplication IModels • API(Application Programming Interface) Modeling • API는 Program 형태로 접합되는 부분을 나타내며 Interface와 Component를 사용하여 Modeling • API Model 구성 • System 내에서 Program 형태로 접합되어야 하는 부분을 확인 • 가시화해야 하는 중요한 Interface Property만 남김 • 특정 구현 물을 표현할 때에는 각 API의 구현 내역을 Model화

13. render.cpp {version = 5.3.7} rengine.h {version = 4.6} render.h {version = 5.3} poly.h {version = 4.1} colotab.h {version = 4.1} • Source Code Modeling • Source Code File의 구성을 Modeling • Source Code File 간의 Compile 의존성을 가시화 하거나 개발 경로의 분기, 결합에 따른 File을 분할/집합 등을 가시화 • Source Code Model 구성 • Compile 의존성과 더불어 개발 Tool 지정 방식에 따른 논리 요소들의 상세 내역을 저장하는 File을 확인 • Model들을 형상 관리 및 Version 제어 Tool과 접목하는 것이 중요하면 꼬리표 값을 이용 • 개발 Tool이 File들의 해당 관계를 관리하도록 하고 이들의 관계를 문서화할 떄 만 UML 이용

14. 힌트와 조언 • 구조가 좋은 Component • System의 물리적인 관점에서 얻어진 것들에 대한 명쾌한 추상 개념 제공 • 작고 정의가 명확한 Interface 구현 • Class 들을 직접 구현하며 해당 Class 들은 Interface가 갖는 의미를 수행 • Component 간의 결합도는 상대적으로 낮으므로 의존 관계와 현실화 관계만 이용 • Component를 그릴 때 • Interface가 제공하는 Operation을 명시적으로 나타낼 필요가 없으면 Interface Icon 사용 • 해당 Component의 의미를 이해하는데 필요한 Interface만 표현 • Library나 Source Code와 같은 것은 Version을 표현하고 Tagged Value 활용

15. 26장. 배치 (Deployment) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 프로세스와 장치의 모델링 • 컴포넌트 분산 모델링 • 힌트와 조언

16. 시작하기 • 배치 (Deployment) • Node는 Component와 같이 현실 세계의 System의 물리적 관점을 Modeling 하는데 사용되며 어느 정도의 Memory와 자체 처리 능력을 갖는 전산 자원을 표현 • Node는 System이 실행되는 H/W의 총체적 구조를 Modeling하는데 사용하며 Component가 배치될 수 있는 Processor나 장치를 나타냄 • S/W 중심 System 설계 • 논리적 측면 : Class, Interface, Collaboration, Interaction, State Machine • 물리적 측면 : Component(논리적 및 물리적 요소의 Package화) Node(Component들이 배치되고 실행되는 H/W 표현) egb_server 명칭

17. sales Deploys pos.exe contacts.exe 단순명 kiosk_7 확장 Node Server::backup {remoteAdministrationOnly} 경로명 용어와 개념 • 명칭 (Name) • 다른 Node와 구분하기 위한 문자열로 된 명칭이 반드시 필요 • 단일명(Simple Name)과 Node가 속한 Package 명을 붙인 경로명(Path Name) • Class와 같이 Node에 Tagged Value사용 가능

18. Component Node 명칭 존재 존재 관계 표현 의존, 연관, 일반화 의존, 연관, 일반화 중첩 가능 가능 Instance 포함 포함 Interaction 참여 참여 가능 참여 가능 실행 구분 System 실행에 참여 Component 실행 표현 서로 다른 논리적 요소들을 물리적으로 Package화 Component의 물리적 배치 • Node와 Component • Node와 Component는 매우 유사함 • 분산(Distribution) Unit : 일체의 Object나 Component가 하나의 Group으로 Node에 위치할 때 Component sales pos.exe contacts.exe Node

19. Node의 구성 • Node를 Package로 Group화 하여 구성 • Node 간의 의존, 일반화, 연관 관계로 Node들의 관계 표현 • 연결 (Connection) • Node간의 관계를 표현하며 연관 관계가 일반적 임 • 연관 관계는 Ethernet, Serial Line, Shared Bus 등과 같은 Node간의 물리적 연결을 표현 kiosk RAID farm <<10-T Ethernet>> server console <<RS-232>> 연결

20. <<10-T Ethernet>> kiosk <<processor>> server RAID farm <<RS-232>> console 보편적 모델링 기법 • Processor와 장치의 Modeling • 독립형 System, 내장 System, Client/Server System, Distribution System 등의 형태를 구성하는 Processor(Component를 수행할 처리 능력을 갖는 Node) 와 장치 (처리 능력을 갖지 않는 Node)를 Modeling • Processor와 장치를 Modeling 하려면 • System의 Deployment View에 있는 Computing 요소들을 확인하고 각각을 Node화 • 일반적인 Process와 장치를 표현하면 Stereotype을 적용하여 설명 • 각 Node에 적용할 수 있는 Attribute와 Operation을 고려

21. : kiosk Deploys user.exe : RAID farm <<10-T Ethernet>> s : server processorSpeed = 300mHz memory = 128M Deploys dbadmin.exe tktmstr.exe c : console Deploys admin.exe config.exe <<RS-232>> • Component Distribution Modeling • System을 구성하는 Processor와 장치들에 설치된 Component들의 물리적인 분산을 가시화, 명세화 하여 System의 전반적인 구조를 Modeling • Component 분산을 Modeling 하려면 • System에 존재하는 중요한 Component를 Node에 배치 • 여러 Node의 Component들을 중복 배치하는 것을 고려 • 배치의 방법을 선택 • Component 배치를 나타내지 않고 각 Node의 명세서에만 보존 • 의존 관계를 사용하여 해당 Node가 배치하는 Component와 각 Node를 연결 • Node를 표시하는 요소에 새로운 구획을 추가하여 배치되는 Component를 나열

22. 힌트와 조언 • 구조가 좋은 Node • 해결 영역의 H/W에 나타나는 어휘에서 얻어진 것들의 명확한 추상 개념 제공 • Model을 만든 목적을 전달하기에 필요한 수준까지만 분해 • Modeling하려는 Domain에 적합한 Attribute와 Operation만 표현 • Node에 위치하는 Component들을 직접 배치 • 실 System의 전체 구조를 반영하는 형태로 다른 Node들과의 연결을 고려 • UML에서 Node 작성시 • Project나 전체 조직을 대상으로 Stereotype들을 적합한 Icon으로 정의 • 주어진 상황에서 해당 Node의 의미를 이해하기에 적합한 Attribute와 Operation만을 표현

23. 27장. 협력 (Collaboration) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 쓰임새(Use Case)의 실체화 모델링 • 오퍼레이션의 실체화 모델링 • 메커니즘 모델링 • 힌트와 조언

24. 시작하기 • 협력 (Collaboration) • 협력은 Class, Interface 그리고 다른 요소들로 이루어진 공동체를 말하며 각 부분의 모든 행동을 합한 것 보다 큰 공동의 행동을 제공하기 위하여 함께 동작 • 협력을 사용하여 Use Case와 Operation의 현실화(Realization)를 상세히 기술하며, Architecture에서 중요한 System Mechanism을 Modeling • 분류자(Class, Interface, Component, Node, Use Case, …)나 Operation과 같은 요소가 실현되는 방법을 기술하는 명세서 • 실현은 특정 역할을 담당하는 분류자와 그들 간의 연관 관계에 의해 이루어 짐 • 패턴(Pattern) : 특정 상화에서 공통적 문제에 대한 공통적 해법 • Idiom : Program을 작성하는 공통 방법 • Mechanism : System Architecture의 개념적인 Group을 나타내는 설계 Pattern • Framework : 특정 Domain 내에서 Application 작성을 위하여 확장 가능한 Template를 제공하는 Architecture Pattern Inter-node messaging 명칭

25. TransportAgent sender received sendMessage( ) Interface 다중성 Role mailbox IDistributed Queue addMessage( ) removeMessage( ) count( ) * * 1 연관 Message ID header body * 일반화 의존 IncomingQueue OutgoingQueue 용어와 개념 • 명칭 (Name) • 다른 협력과 구분하기 위한 문자열로 된 명칭이 반드시 필요 • 단일명(Simple Name)과 협력이 속한 Package 명을 붙인 경로명(Path Name) • 구조 (Structure) • 협력의 두 가지 관점 • 구조적 부분 : 협력을 수행하기 위해 함께 동작하는 Class, Interface, Component, Node 등과 같은 다른 요소들과의 조합 관계를 표현 • 행동적 부분 : 요소들이 교류하는 방법의 동적인 관점을 명세화

26. Transport agents periodically remove message from their assigned queues, according to their scheduling policies. Actor Instance : Message : OutgoingQueue : TransportAgent create Message Note addMessage removeMessage Lifeline Focus of Control • 행동 (Behavior) • 협력의 행동적인 부분은 Interaction Diagram으로 표현 • 교류도는 Message들로 이루어지는 행동을 나타내고 있는 교류를 명세화하고 Message들은 지정된 목적을 수행하기 위해 특정 상황에서 Object들 간에 주고 받는 것

27. Place order Use Case Realization Order Management Collaboration <<refine>> Refinement Order Validation • 협력의 구성 • 적당한 크기와 정상적인 개수의 협력을 구성해야 • 협력의 두 가지 관계 • 현실화(Realization) 관계 • 정제(Refinement) 관계

28. 보편적 모델링 기법 • Use Case의 현실화 Modeling • Use Case들의 구체적인 구조와 행동을 현실화 • Use Case 현실화 Modeling • Use Case가 갖는 의미를 수행하는데 충분하면서 필요한 구조 요소 확인 • 구조 요소들의 구성을 파악하여 Class Diagram으로 표현 • Use Case가 나타내는 개별적인 Scenario를 고려 • Scenario의 동적인 활동을 파악하여 Interaction Diagram으로 표현 • 구조 요소와 행동 요소들을 하나의 협력으로 구성하면서 현실화 관계를 이용하여 해당 Use Case와 연결 Detect card fraud <<include>> Place order Order Management <<include>> Customer Validate transaction Generate bill

29. return (totalPolygons - renaming) / totalPolygons Ray trace RenderFrame setContents render progress • Operation의 현실화 Modeling • Object들이 협조해야 하는 Operation들에 대하여 Code화하기 전에 협력을 통한 구현 Model을 작성하는 것 • Operation 특유의 Parameter, Return Value 그리고 Object들은 해당 Operation의 현실화에 필요한 상황을 제공 • Operation 현실화 Modeling • Operation에 나타나는 Parameter, Return Value, Object를 확인 • 일반적인 것이면 Code 형태로 구현하여 Model과 별개로 기록 유지 또는 Note 이용 • Algorithm 집약적이면 Activity Diagram을 이용하여 현실화를 Model에 표현 • 복잡하거나 상세 설계가 필요하면 구현을 협력으로 표현하고 Class Diagram과 Interaction Diagram을 활용하여 협력의 구조적 부분과 행동적 부분을 학장

30. 힌트와 조언 • 구조가 좋은 Collaboration • 구조적 관점과 행동적 관점 모두로 구성 • System에서 식별이 가능한 교류에 대하여 명쾌한 추상 개념을 제공 • 다른 협력이 갖는 구조 요소들과 중복되게 표현 • 이해하기 쉽고 간단하게 • UML로 협력을 그릴 때 • 다른 협력, 분류자, Operation, System 전체에 대한 관계를 이해할 필요가 있을 때에만 협력을 명시 • 분류자나 Operation별로 협력을 구성하거나, System 전체와 연관되는 Package에 포함

31. 28장. 패턴과 프레임웍 • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 설계 패턴 모델링 • 아키텍쳐 패턴 모델링 • 힌트와 조언

32. <<framework>>Receivable Framework Billing Mechanism Reconciliation 시작하기 • 패턴과 프레임웍 (Pattern & Framework) • Pattern : 주어진 상황에서 공통적으로 발생하는 문제에 대하여 공통적으로 적용할 수 있는 Solution • Mechanism : 설계 Pattern으로써 Class들로 이루어진 공동체에 적용 • Framework : Architecture Pattern으로써 특정 Domain의 Application들을 위해 확장 가능한 Template를 제공 • Pattern을 이용하여 System Architecture를 형성하는 Mechanism과 Framework을 명세화 • Pattern의 사용자가 조정할 수 있는 동전 구멍(Slot), 줄(Tab), 손잡이(Knob), 숫자판(Dial)을 사용하여 접근이 쉽게 작성

33. Template TaskQueue Subject Subject Observer Observer Bind Collaboration SliderBar Observer Role 용어와 개념 • Pattern과 Architecture • Model-View-Controller Patter을 사용하여 추상 개념들을 구성하는 것이 좋은 방법 • 설계 Pattern은 Class들로 이루어진 공동체가 갖는 구조와 행동을 명세화(Mechanism) • Architecture Pattern은 전체 System의 구조와 행동을 명세(Framework) • Mechanism • 설계 Pattern의 다른 명칭이며 Class로 이루어진 공동체에 적용 • Mechanism의 두 가지 표현 • 일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 지정 • 일부 공통적이고 중요한 행동을 수행하기 위해 함께 동작하는 추상 개념들을 Template 으로 지정

34. Framework • Architecture Pattern이며 Domain에 있는 Application들을 위한 확장 가능한 Template을 제공 • Mechanism보다 규모가 크며 Mechanism을 포함하는 Micro Architecture의 일종 Pacemaker Bind <<framework>>CyclicExecutive Framework Client Handler Collaboration EventHandler CommonEvents

35. Client Command Invoker Receiver Application Client Command Command PasteCommand Command Receiver OpenCommand Invoker Document MenuItem 보편적 모델링 기법 • 설계 Pattern Modeling • 설계 Pattern은 Parameter 협력으로 표현되며, Pattern은 추상 개념을 제공하고, 추상 개념들이 갖는 구조와 행동은 함께 동작하여 일부 유용한 기능을 수행 • Parameter들은 해당 Pattern의 사용자가 반드시 결합 시켜 주어야 하는 요소들을 지정 • 설계 Pattern Modeling • 공통적인 문제에 대한 공통 해법을 찾고 이를 Mechanism으로 구체화 • Mechanism을 구조적이고 행동적인 관점을 제공하는 협력으로 Model화 • 지정된 상황에 있는 요소들과 반드시 결합하여야 하는 설계 Pattern 요소들을 확인하고 이들 협력의 Parameter로 표현

36. : Client c : Command : Invoker : Receiver new storeCommand(c) execute( ) action( ) 설계 Pattern의 구조적 관점 Modeling Client Command execute( ) Receiver action( ) Invoker addCommand( ) receiver 설계 Pattern의 행동적 관점 Modeling

37. Architecture Pattern Modeling • Framework은 Stereotype으로 지정된 Package로 표현, 하나의 Package로써 필요한 요소(Class, Interface, Use Case, Component, Node, Collaboration, 다른 Framework)들을 제공 • 줄(Tab) : 요소들 중에서 일부가 공용(Public) 타입이 되어Client가 의존할 수 있는 자원으로 표현(추상 개념들과 Framework을 연결) • 동전 구멍(Slot) : 공용 요소의 일부는 설계 Pattern이 되고 Client가 결합하는 자원을 표현하며 이는 설계 Pattern과 결합할 때 채워짐 • 요소들 중 일부는 보호 타입, 전용타입으로써 Capsule화 된 Flamework 요소들을 나타내며 이들은 외부 View에서 접근할 수 없도록 감추어져 있음 • Architecture Pattern Modeling • 현존하면서 검증된 Architecture에서 Framework을 도출 • Stereotype으로 지정된 Package로 Framework의 Model 작성 • Framework을 설계 Pattern과 협력의 형태로 변경하는데 필요한 Slot, Tab, Knob, Dial을 표현

38. <<framework>>Blackboard Knowledge Source Blackboard Control Blackboard Knowledge Source Reasoning engine Apply new knowledge source

39. 힌트와 조언 • 구조가 좋은 Pattern • 공통적인 방법으로 공통적인 문제를 해결 • 구조적 관점과 행동적 관점 모두 구성 • Slot, Tab, Knob, Dial을 나타내고 해당 관점들을 다시 표현하여 특정 상황에 적용 가능하도록 • 원자적(더 작은 Pattern으로 분할되지 않는 것) 구성 • System에 있는 개별적인 추상 내역들을 횡적으로 분할 • UML로 Pattern을 그릴 때 • 해당 상황에 적용하기 위해 변경해야만 하는 Pattern 요소들을 표현 • Pattern의 변경은 물론 이를 사용하기위해 필요한 Use Case를 제공하여 해당 Pattern에 접근이 용이하도록

40. 29장. 컴포넌트도 (Component Diagram) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 소스 코드 모델링 • 실행 배포판 모델링 • 물리적 데이터베이스 모델링 • 적응력 있는 시스템 모델링 • 순공학과 역공학 • 힌트와 조언

41. find.html Page 실행 File fine.exe <<hyperlink>> index.html neteng.dll dbacs.dll Component Library 시작하기 • Component Diagram • Component들 간의 구성과 의존을 정적인 Implementation View로 Modeling • 실행 File, Library, Table, File, Document 같은 Node에 존재하는 물리적인 구성 요소들을 Modeling • 본질적으로는 Class Diagram이며 System의 Component에 관점을 둠

42. 용어와 개념 • 공통 Property • 다른 Diagram들과 동일한 공통 Property를 공유하며 Component의 관계를 표현하며 Graphic으로는 꼭지점(Vertices)와 호(Arc)를 사용 • 내용 (Content) • 공통적 포함 내용 • Component • Interface • Relationship : Dependency, Generalization, Association, Realization • Note와 Constraint를 포함 • Package 또는 Sub-System 포함 가능 • 공통적 사용 • System 각 부분의 Configuration Management를 지원하는 정적인 Implementation View 작성에 활용

43. signal.h {version = 3.5} signal.h {version = 4.0} signal.h {version = 4.1} <<parent>> <<parent>> signal.cpp {version = 4.1} interp.cpp interp.cpp interp.cpp 보편적 모델링 기법 • Source Code Modeling • Source Code File들과 그들의 관계를 Modeling • Source Code Modeling • 중요한 Source Code File을 확인(Stereotype으로 지정된 Component로 Modeling) • System이 큰 경우에는 Package를 활용하여 Source Code File들을 Group화 • Source Code File의 Version No., 작성자, 변경일자 등을 Tagged Value로 표현 • 의존 관계를 사용하여 File들 간의 Compile 의존성을 모형화

44. path.dll collision.dll driver.dll {version = 8.1.3.2} IDrive ISelfTest • 실행 배포판(Executable Release) Modeling • 완전하고 모순 없는 산출물을 내부/외부에 인도하기 위한 Modeling • 고유한 각 Application을 공유할 수 있도록 하며 분산 System에서 흩어져 있는 많은 실행 File들 및 구성 요소들을 적절하게 배치(Deployment)하기 위한 도해 • 실행 배포판 Modeling • Model로 작성할 Component 확인 • 각 Component에 대해 Stereotype 고려 • 각 Component에 대해 인접한 Component와의 관계를 고려

45. 물리적(Physical) Database Modeling • 논리적(Logical) Database Schema : System에서 보존할 Data의 관계가 갖는 의미와 함께 그들의 어휘에서 파악되는 저장 정보를 파악 • 물리적(Physical) Database Schema : 논리적 Database Schema를 저장 자료구조의 특성을 고려하여 System에 저장하기위한 정보 구조로 변환하는 것이며 논리적 Database Schema에 정의된 Operation들을 Mapping • 물리적 Database Modeling 전략 • 각 Class 당 하나의 Table을 별도로 지정 • 상속 관계를 제거하고 상속 계층에 속하는 Class들의 모든 Instance가 같은 상태(State)를 갖도록(Instance들에 불필요한 정보가 저장될 수 있음) • Parent와 Child 상태를 서로 다른 Table로 분리(교차적인 Table Join이 많이 발생) • 논리적 Operation들이 구현되는 방법 • 단순한 CRUD Operation의 경우는 표준 SQL 또는 ODBC 호출로 구현 • 복잡한 행동(업무 규칙)들은 Trigger 또는 Stored Procedure로 Mapping • 물리적 Database Modeling • 논리적 Database Schema를 나타내는 Class를 확인 • Class들을 Table로 Mapping하기 위한 전략을 선택 • Mapping 시킨 내역을 가시화, 명세화, 구축, 문서화하기 위한 Stereotype 지정 • 가능하면 Tool을 이용

46. school.db course department instructor school student

47. The school database on Server B replicates the database on Server A. : school.db {location = Server A} : school.db {location = Server B} <<copy>> • 적응력 있는 System Modeling • Component Diagram은 정적인 표현만을 표현하나 경우에 따라서는 다른 UML 일부 Diagram(Object Diagram, Interaction Diagram)들과 결합 사용하여 동적인 표현을 가능하도록 • 적응력 있는 System Modeling • Node에서 Node로 이동할 수 있는 Component들의 물리적인 분산을 고려(위치를 꼬리표 값으로 표현, Component Instance의 위치 명세화) • Component의 이동을 초래하는 활동들을 Model화 하려면 Component Instance를 포함하는 Interaction Diagram 생성

48. DataBinding HyperLink DataObject ContainedControls vbrun.dll PropertyBag ParentControls AsyncProperties SelectedControls AmbientProperties DataObjectFiles DataBindings • 순공학과 역공학 • Component Diagram 순공학 • 각 Component에 대해 해당 Component가 구현하는 Class나 Collaboration을 파악 • 해당 Component를 어느 것으로 순공학 처리할 것인가를 결정 • 가능하면 Tool을 사용 • Component Diagram 역공학 • 역공학 대상을 선택 • Tool을 활용하여 역공학 하려는 Code를 지정 • Tool을 사용하여 Model을 질의(Query) 하는 형식으로 Component Diagram 생성

49. 힌트와 조언 • 구조가 좋은 Component Diagram • System의 정적 구현 View 중에서 한가지 관점에만 초점 • 해당 관점을 이해하는데 꼭 필요한 요소들만 포함 • 내용을 이해하는데 꼭 필요한 장식(Adornment)만을 포함하여 해당 내용 추상화 수준과 일치하는 상세 내역 제공 • 너무 적지 않으며 충분한 내용을 포함하고 있어서 의미를 이해하기에 부족하지 않도록 • Component Diagram을 그릴 때 • 목적을 잘 알 수 있는 명칭 사용 • 교차선이 최소화 되도록 요소를 적절히 배치 • 의미적으로 밀접한 것들이 서로 가까이 존재하도록 공간을 활용한 배치 • 시각적 효과를 충분히 나타내도록(Note, Color, …) • Stereotype으로 지정된 요소들을 주의해서 사용

50. 30장. 배치도 (Deployment Diagram) • 시작하기 • 용어와 개념 • 보편적 모델링 기법 • 내장 시스템 모델링 • 클라이언트 / 서버 시스템 모델링 • 완전 분산 시스템 모델링 • 순공학과 역공학 • 힌트와 조언