1. 분석 설계 & 모델링 2009 년 7 월

3. 객체지향에 대한 이해

4. UML에 대한 이해

6. * 갈수록 복잡해지는 소프트웨어

7. * 복잡하고 비용이 많이 들어가는 프로젝트일수록 모델링이 더욱 중요

8. Model 이란 ? : simplification of reality

9. Grady Booch :

10. * A model provides the blueprints of a system

11. * It may encompass detailed plans

13. * The basic reason for modeling is to get a better understanding of the system we are developing

14. * 시스템을 현재 또는 원하는 모습으로 가시화

15. * 시스템의 구조와 행위 명세화

16. * 시스템을 구축하는 기본 형태 제공 ( 과거 개발 시스템의 모델 활용 )

17. * 시스템 구축을 위한 결정 사항들에 대한 문서화

18. * 우리가 의도한대로 시스템을 구축하고 있는지에 대한 검토

19. # 모델의 특징 : 추상화 , 관점

21. * 1970 년대 : 구조적 개발

22. * 1980 년대 : 객체지향으로의 전환

23. * 1990 년대 : 객체지향 기술 환경 성숙

24. * 2000 년대 : Object Technology for WWW and EC

25. * 현재 : CBD, SOA, Product Line

27. * 소프트웨어에 대한 전통적 시각

28. o 프로그램 = 데이터 + 함수

29. o 상호 연관된 데이터와 함수를 별개 취급

30. * 소프트웨어에 대한 OO 적 시각

31. o 객체 = 데이터 + 함수

32. o 프로그램 = 객체 + 객체

34. * Object-Type : 인간의 인지내에서의 물체나 객체에 적용되는 어떤 생각이나 관념

35. * Class : Object-Type 에 대한 소프트웨어적인 구현 . 객체의 기본적인 성질을 추상화 한 것 . 객체를 만들어내는 틀 (Template) 제공

36. * Object : 실세계에 존재하는 실제적인 사물 또는 추상적인 사물

37. * Instance : 어떤 클래스에 속해있는 객체 . 종종 개별적인 객체를 묘사할때 사용됨

38. * Attribute : 객체의 상태를 표현하는 변수

39. * Operation : 객체가 할 수 있는 행위

40. * Method : Operation 을 실질적으로 동작할 수 있도록 구현한 것 .

41. * Message : 객체들간의 통신을 명세한 것

43. * Encapsulation : 관계있는 Data 와 Operation 을 하나로 묶음 . 객체를 추상화

44. * Information Hiding : 객체의 데이터는 내부에 숨기고 접근은 오퍼레이션을 통해서만

45. * Inheritance : 새로운 클래스를 처음부터 생성하는 대신 이미 존재하는 클래스를 사용하여 새로운 클래스 생성

46. * Polymorphism : 두 개 이상의 클래스가 같은 이름의 Operation 을 가질 수 있게 해줌

48. * Use Case Driven : The Use Case model represents the functional requirements and analysys, design, implement, test to realize the use cases

49. * Architecture Centric : The Use Cases drive the architecture, and the architecture guides which use cases can be realized

50. * Iterative Process : Iterative approach is risk-driven and the result of an iteration is an increment

52. * 소프트웨어 시스템의 산출물들을

53. o 시각화 (visualizing)

54. o 명세화 (specifying)

55. o 구축 (constructing)

56. o 문서화 (documenting)

57. 하기 위한 언어임 UML 은 Grady Booch, Jim Rumbaugh, Ivar Jacobson 의 방법론을 통합한 객체지향 개발을 위한 위한 통합 모델링 언어

59. * 개방형 표준임

60. * 전체 소프트웨어 개발 라이프사이클을 지원함

61. * 다양한 어플리케이션 분야를 지원

62. * 사용자들의 경험과 요구에 기반함

63. * 지원 도구가 많음

65. 1 모델링 요소

66. 2 관계

67. 3 확장성 메커니즘

68. 4 다이어그램

70. # 구조적 요소 : UML 모델의 명사형으로써 모델의 정적인 부분이며 개념적이거나 물리적인 요소들을 표현

71. * Class, Interface, Use Case, Collaboration, Component, Node

72. # 행위요소 : UML 모델의 동사형으로써 모델의 동적인 부분이며 시간과 공간에 따른 행동요소들을 표현

73. * Interaction, State Machine

74. # 그룹핑 요소 : UML 모델을 조직하는 부분이며 모델을 분해하여 재 구성화 할 수 있는 단위 상자

75. * Package

76. # 기타 요소 : Note( 주석 )

80. # Stereotypen : UML 어휘를 확장하여 새로운 종류의 구성 요소를 생성

81. # Tagged Value : UML 구성요소가 갖는 Property 를 확장

82. # Constraint : UML 구성요소가 갖는 의미를 확장하여 새로운 규칙의 추가 및 기존 규칙 변경

83. UML 의 구성 > 다이어그램

84. * 뷰를 반영한 모델

85. * 특정이해관계자의 관점에서 나타낸 것

86. * 시스템의 일부를 표현한 것

87. * 다른 관점의 다이어그램과 의미적으로 일관성이 있음

89. # Use Case Diagram : 사용자 관점에서 시스템 기능을 나타냄

90. * 개발 초기 단계에 작성

91. * 목적

92. o 시스템 상황 (Context) 를 구체화

93. o 시스템 요건의 파악

94. o 시스템 아키텍쳐의 검증

95. o 구현 추진 및 테스트 케이스 생성

96. # Class Diagram : 시스템의 어휘 (vocabulary) 를 나타냄

97. * 개발기간 전체에 걸쳐 작성 및 보완

98. * 목적

99. o 시스템 내의 개념을 명명하고 모델링

100. o Collaboration 을 구체화

101. o 논리적 DB 구조 구체화

103. # Object Diagram : Instance 와 link 를 나타냄

104. * 분석 및 설계 기간에 작성

105. * 목적

106. o 데이터 / 객체 구조 묘사

107. o Snapshot 의 구체화

108. # Component Diagram : 물리적 구현 구조를 나타냄

109. * 아키텍쳐 사양의 일부로 작성됨

110. * 목적

111. o 소스코드 작성

112. o 실행 가능한 release 의 구축

113. o 물리적 DB 구체화

115. # Deployment Diagram : 시스템의 하드웨어 topology( 위상 ) 을 나타냄

116. * 아키텍쳐 사양의 일부로 작성됨

117. * 목적

118. o 컴포넌트 분포의 구체화

119. o 성능상의 bottleneck 파악

121. * Sequence Diagram : 동적 행동을 나타냄 ( 시간중심 )

122. o 목적

123. + Control 의 Flow 를 모델화

124. + 전형적 시나리오의 묘사

125. * Collaboration Diagram : 동적 행동을 나타냄 ( 메시지 중심 )

126. o 목적

127. + Control 의 Flow 를 모델화

128. + 객체 구조와 Control 의 코디네이션 묘사

130. # Statechart Diagram : 동적 행동을 나타냄 ( 이벤트 중심 )

131. * 목적

132. o 객체 라이프 사이클 모델링

133. o reactive 객체의 모델화

134. # Activity Diagram : 동적 행동을 나타냄 ( 행동 중심 )

135. * 목적

136. o 비지니스 workflow 모델링

137. o 운영 (operations) 을 모델링

139. # 정의 : 시스템을 Actor 와 Use Case, 이들 사이의 관계로 표현한 모델

140. # 목적

141. * 소프트웨어 개발자와 고객이

142. * 시스템에 대한 요구사항에 대하여 합의할 수 있도록 하며

143. * 합의의 결과물로서 존재

144. * 분석 , 설계 , 테스트 진행 시 기초 자료로 활용

145. # 구성

146. * Use Case Diagram : Actor, Use Case, Relationship

147. * Use Case 명세서

149. # Input : 프로세스 기능 분해도 , 작업흐름도 , 요구사항 정의서 , 용어사전

150. Use Case Package 정의

151. Actor 도출

152. Use Case 도출

153. Use Case Diagram 작성

154. Use Case 상세화

156. 분석 모델의 정의

157. * Use Case Model 로 표시된 요구사항을 소프트웨어 개발자 관점에서 상세히 살펴보고

158. * 공통적으로 사용되는 자원을 비롯한 시스템 내부를 개념적인 객체 모델로 구조화하여 나타낸것

159. 분석 모델의 목적

160. * Refining and structuring the requirements

161. * Conceptual Object Model

162. * Desing 에 대한 Input 으로서의 역할

164. 분석단계 Package 정의 : 분석단계 Package 는 Use Case Realization, 분석 Class, 하위 분석 단계 Package 등으로 구성되며 시스템 내의 모든 object 들을 관리 가능한 단위로 분류하기 위한 매체로 사용됨

165. Use Case Realization 정의 : Use Case Realization 은 특정 Use Case 가 실현 (realize) 되기 위하여 어떤 class 들이나 object 들이 필요하고 어떻게 동작하는지를 기술하는 단위

166. 분석 단계 Class 도출 : 분석 단계 Class 는 Use Case Model 의 각 Use Case 를 실현하기 위해 분석단계에서 찾아낸 오브젝트들을 표현한 클래스

167. Interaction Diagram 작성

168. * 분석 클래스들 사이의 상호 작용을 명시

169. * Use Case 명세서 상의 Flow of event 를 통해 발견된 행동 (behavior) 을 표현함으로써 각 분석 클래스 간의 책임 (responsibility) 을 정의함

170. Operation / Attribute 정제

171. Class Diagram 정제

173. SW Architecture 의 필요성

174. # 사용자의 요구사항과 구현될 시스템 사이에서 발생하는 갭을 통제하여 예측 가능하도록 하기 위함

175. # 시스템이 커질수록

176. * 알고리즘과 데이터 스트럭쳐

177. 보다

178. * Overall System structure

179. * Organization of a system

180. * Global control structure

181. * Protocols for communication

182. 의 중요성이 커짐

184. S/W Architecture 의 정의

185. * 소프트웨어 시스템에 대한 상위 레벨의 구조적 / 행위적 모델

186. * 소프트웨어 솔루션 구조에 대한 커다란 그림을 보여줌

187. * 소프트웨어의 중요한 초기 설계 결정사항들을 표현

188. S/W Architecture 의 역할 #

189. * Communication among Stakeholders

190. * Early Design Decisions

191. * Transferable Abstraction of a System

192. * Architecture constrains design and implementation

193. Level of SW Architecture : Application Framework > 상용 S/W Architecture Framework > S/W Architecture Style

195. * 아키텍쳐 설계시 반복되는 유사한 조직적인 패턴이나 설계 스타일을 아키텍쳐 스타일 또는 아키텍쳐 패턴이라 함

196. * 작은 코드수준의 재사용 보다는 전체 시스템의 구조나 설계모형을 재사용하기 위한 구체적이고 체계적인 재사용 규약

198. * Dataflow systems : batch sequential, pipes and filters

199. * Call-and return systems : Main program and subroutine, OO systems, Hierarchical layers

200. * Independent components : Communicating process, Event systems

201. * Virtual machines : Interpreters, Rule-based systems

202. * Data-centered systems(Repositories) : Databases, Hypertext systems, Blackboards

204. * 예시 : JDBC, Servlet

205. * Framework 를 사용하는 이유 : 개별 Aplication 마다 공통적으로 적용시켜야하는 공통의 서비스 ( 로직 ) 를 제공하여 개별 Application 의 복잡성을 줄이고 생산성 향상

206. * Library 와의 차이 : 라이브러리는 개별 Application 에서 직접 호출하여야하며 호출순서나 방식에 대한 제약이 없음 . 반면 프레임워크는 실행주체가 프레임워크가 되고 주어진 api 에 맞게 개발된 application 이 실행 되어지는 형태