Model이란, 현실을 단순화 한 것이다. 주어진 추상화(abstraction) 수준에서 핵심 측면(assential aspects)을 포착한다.
모든 시스템은 다양한 모델을 사용해서 다른 측면에서 설명될 수 있다.
복잡한 시스템의 모델을 만드는 이유는 그 시스템을 전체적으로 이해하기 어렵기 때문이다.
모델링을 통해 우리는 네 가지 목표를 달성한다.
- 시스템을 시각화(visualize)하여 현재의 모습이나 원하는 모습을 볼 수 있게 한다.
- 시스템의 구조나 행동을 명세(specify)한다.
- 시스템을 구축하기 위한 청사진을 제공한다.
- 우리가 내린 결정을 문서화한다.
어떤 모델을 만들지 선택하는 것은 문제를 어떻게 해결할지와 솔루션의 형태에 큰 영향을 미친다.
모든 모델은 다양한 정밀도(precision) 수준에서 표현될 수 있다.
복잡한 시스템은 단일 모델이 아닌 거의 독립적인 몇 개의 모델을 통해 접근된다.
Visual Modeling이란, 표준 그래픽 표기법을 사용해서 모델링하는 것이다.
Static models: 시스템의 구조적 특성을 설명
Dynaic models: 시스템의 행동적 특성을 설명
UML(Unified Modeling Language): 객체지향 모델링을 위한 표준 비주얼 모델링 언어
- 비주얼 표기법(notation)과 의미(semantics)
- 프로세스에 독립적이다.
핑크색 박스는 static model, 노란색 박스는 dynamic model을 뜻한다.
static model에는 다음과 같은 종류가 있다.
- Use Case Diagrams : 사용자의 관점에서 시스템의 기능을 나타냄
- Class Diagrams : 시스템 내의 객체와 그 관계를 나타냄
- Object Diagrams : 객체 간의 관계를 특정 시점에 나타냄
- Component Diagrams : 시스템의 구성 요소와 그 관계를 나타냄
- Deployment Diagrams : 소프트웨어가 물리적 환경에 배포되는 방식을 나타냄
- Package Diagrams : 시스템의 패키지와 그 관계를 나타냄
dynamic model은 다음과 같은 종류가 있다.
- Sequence Diagrams : 객체 간의 메시지 전달 순서를 나타냄
- Collaboration Diagrams : 객체 간의 협력을 중심으로 메시지 전달을 나타냄
- Statechart Diagrams : 객체의 상태 변화를 나타냄
- Activity Diagrams : 프로세스의 작업의 흐름을 나타냄
UML 2.0에서의 다이어그램은 Structure Diagram과 Behavior Diagram으로 나뉜다.
Structure Diagram에는 다음과 같은 종류가 있다.
- Class Diagram : 시스템 내의 객체와 그 관계를 나타냄
- Composite Structure Diagram : 복합 구조를 나타내며, 객체 내의 구성 요소와 그 관계를 표현함.
- Component Diagram : 시스템의 구성 요소와 그 관계를 나타냄
- Deployment Diagram : 소프트웨어가 물리적 환경에 배포되는 방식을 나타냄
- Object Diagram : 객체 간의 관계를 특정 시점에 나타냄
- Package Diagram : 시스템의 패키지와 그 관계를 나타냄
Behavior Diagram에는 다음과 같은 종류가 있다.
- Activity Diagram : 프로세스나 작업의 흐름을 나타냄
- Use Case Diagram : 사용자의 관점에서 시스템의 기능을 나타냄
- State Machine Diagram : 객체의 상태 변화를 나타냄
- Interaction Diagram
* Sequence Diagram : 객체 간의 메시지 전달 순서를 나타냄
* Interaction Overview Diagram : 객체 간의 협력을 중심으로 메시지 전달을 나타냄
* Interaction Overview Diagram : 여러 상호 작용 다이어그램을 결합하여 전체 흐름을 나타냄
* Timing Diagram : 객체의 상태 변화와 이벤트를 시간에 따라 나타냄
UML을 사용하는 방법
UML as sketch : 프로젝트의 초기 단계에서 개략적인 아이디어나 설계를 나타내기 위해 사용
UML as blueprint : UML을 사용하여 상세한 시스템 구조와 동작을 나타냄
UML as programming language : 코드 생성을 위한 도구와 함께 UML을 사용하여 실제 코드를 작성하기 전 로직과 구조를 정의
Forward engineering : UML 다이어그램을 그리고 나서 실제 코드를 작성하는 과정
Reverse engineering : 기존의 코드를 바탕으로 UML 다이어그램을 생성하여 해당 코드를 더 잘 이해하게 도와주는 과정
객체 지향 분석(OOA): 문제 도메인 및 요구사항의 조사(investigation), 이해(understanding), 발견(discovery)을 강조하는 분석 방법론으로, 구현에 대한 고려사항은 없다.
분석 과정에서 사용되는 모든 어휘(클래스 이름, 관계 등)은 문제 도메인(problem domain)에서 가져와야 한다. 시스템이 해결해야 할 실제 문제와 관련된 용어를 사용하여 요구 사항을 정확하게 표현하기 위함이다.
위 다이어그램은 Use-Case Diagram의 예시이다.
Cellular Phone System에는 Place phone call ... Search phone number가 있다.
User는 모든 요소와 상호작용하고, Cellular network는 Place phone call, Receive phone call과 상호작용 한다.
위 그림은 Domain model의 예시이다.
School은 하나 이상의 Department를 가질 수 있다.
Department는 0개 또는 1개의 chairperson(학과장)을 가질 수 있고, 하나 이상의 교수(Instructor)에게 할당된다.
Student는 School의 member이고, 하나 이상의 Course를 수강한다.
Instructor는 하나 이상의 Course를 가르친다.
객체 지향 설계는 창조(invention)와 적응(adaptation)의 과정으로, 개념적 해결책을 발명하고 적용하는데 초점을 맞춘다.
개발팀은 시스템의 행동 요구 사항을 만족시키기 위해 소프트웨어 객체와 그들이 어떻게 협력하는지 정의한다.
OOP와 OOD 기법이 일관되고 관련성이 있을수록 실제 환경에서 적용하기가 더 쉽다.
OOP는 구현 단계(implementation discipline)과 일치한다(corresponds)
클래스와 클래스 연산은 코드화되어 테스트되고 통합(integrated)된다.
객체는 분석 중에 실제 세계의 이해를 촉진시키기 위해 사용된다.
설계와 프로그래밍 중에는 논리적 해결책과 구현을 위한 기초를 제공한다.
문제를 객체로 분해하는 것에는 판단력(judgment)과 문제의 유형(nature of the problem)에 따라 달라진다. 즉 정확한 표현은 하나만 존재하는 것이 아니다.
'학교강의필기장 > OOP' 카테고리의 다른 글
| Domain Model (0) | 2023.12.10 |
|---|---|
| System Sequence Diagram (0) | 2023.12.10 |
| Use Case Diagram (0) | 2023.12.10 |
| 1. 객체 지향 패러다임 (0) | 2023.10.28 |
| 0. 객체지향개발론 개요 (1) | 2023.10.28 |
