김호쭈
DevForYou
김호쭈
전체 방문자
오늘
어제
  • 분류 전체보기 (321)
    • • 데이터베이스(DB) (9)
      • __SQL__ (9)
    • •알고리즘(Algorithm ) (117)
      • 문제풀이 (99)
      • 스터디 (14)
      • 알고리즘 팁 (4)
    • •Compter Science (57)
      • Operating System (25)
      • Computer Network (1)
      • Computer Vision (16)
      • Artificial Intelligence (14)
      • Software Technology (1)
    • • 독서 (36)
      • Design Pattern (24)
      • 객체지향의 사실과 오해 (1)
      • Object Oriented Software En.. (11)
    • • 개발 (26)
      • React (3)
      • node.js (6)
      • Django (11)
      • Spring boot (6)
    • • 개발Tip (4)
      • GitHub (0)
    • •프로젝트 (2)
      • 물물 (2)
    • •App (54)
      • 안드로이드 with Kotlin (50)
      • 코틀린(Kotiln) (4)
    • •회고 (8)
    • •취준일기 (3)
    • • 기타 (2)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

인기 글

태그

  • KMU_WINK
  • 깃허브데스크탑
  • GitHubDesktop
  • local저장소
  • ㄱ
  • 원격저장소
  • Remote저장소
  • 로컬저장소

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
김호쭈

DevForYou

[Object Oriented S/E] Chapter 5 - Domain Modeling
• 독서/Object Oriented Software Engineering

[Object Oriented S/E] Chapter 5 - Domain Modeling

2023. 4. 13. 03:03

 

# 범위

105page ~

# 내용

## 5.1 WHAT IS DOMAIN MODELING?

  • 도메인 모델링은 개념화 프로세스이다. 중요한 도메인 개념, 속성 및 개념 간의 관계를 식별하는 것을 목표로 하며, 결과는 도메인 모델이라는 다이어그램으로 표현된다.
  • 은행 시스템을 구조화 할때, 은행사업에 대한 이해가 필요할것이고 그걸 기반으로 entities나 object를 이해할 수 있을 것이다. 이러한 이해를 위해서 어플리케이션과 관련된 정보들을 수집하고 분석하고 모델을 세워야 하는데 이러한 활동을 하는 과정들이 도메인 모델링이다.

 

## 5.2 WHY DOMAIN MODELING?

  • 소프트웨어 엔지니어들은 프로젝트 내에서 다른 도메인에서 일하고, 그들의 배경이나 경험들에 따라서 도메인을 다른 관점으로 이해 할 여지가 있다.
  • 심지어 같은 회사의 비슷한 프로젝트에 참여하더라도 도메인이 다르다면( 보안을 예시로 들었음 ) 같은 단어를 다르게 이해할 여지가 있다.
  • 도메인 모델링은 개발 팀이나 분석가들이 어플리케이션과 어플리케이션 도메인을 이해하는데 도움을 준다.
  • 도메인 모델링은 팀원들이 공통 관점에서 어플리케이션이나 도메인을 바라보도록 한다.
  • 도메인 모델은 새로운 팀멤버가 어플리케이션과 어플리케이션 도메인을 이해하는데 돕는다.

 

## 5.3 OBJECT-ORIENTATION AND CLASS DIAGRAM

  • 도메인 모델링은 중요한 도메인 개념과 그들의 특성과 개념사이의 관계를 파악하는것을 목표로 한다. 그리고 이러한 것들은 UML로 표현된다.

### 5.3.1 Extensional and Intentional Definitions(확장 및 의도적 정의)

  • 개발자는 애플리케이션의 특정 인스턴스를 관찰하고 관찰된 인스턴스를 분류, 추상화 및 일반화하여 도메인 모델이라고 하는 개념 모델을 생성한다.
  • 분류는 중요한 단계중 하나이며, 클래스의 개념은 분류과정의 최종 산물이다.
  • 개념화 과정은 귀납적 과정이며 인스턴스를 열거하여 개념을 정의힌다.
  • 의도적 정의 개념은 인스턴스가 소유하는 특성과 행동의 명세를 통해 개념을 정의한다.
  • UML 클래스 다이어그램은, 클래스 클래스 속성 및 작동, 클래스 간의 관계를 나타낸다.

### 5.3.2 Class and Object 

  • Compact view와 expandes views로 나뉠 수 있으며, 상세한걸 보일 필요가 없을땐 Compact, 특성 및 작업을 보여야할땐 expandes를 사용한다.
  • 클래스의 특성및 작업들은 클래스의 기능이라고 부른다.
  • 클래스는 Type이다
    • 내장 타입이던, 사용자가 만든 타입이던

### 5.3.3 Object and Attribute

  • 때때로 어떠한것이 속성이여야하는지, 객체(클래스)여야 하는지 구분하는 것은 어렵다.
  • 색상은 자동차의 속성(attribute)일 수 있지만, 색상을 판매하는 상황에서는 객체(class)일 것이다.
  • Obejct는 어플리케이션이나 어플리케이션 도메인에서 독립적으로 존재하지만, 속성은 그렇지 않다.
  • 독립적인 존재(Independent existence) 은 객체의 대한 정보 또는 상태를 유지하는데 관심이 있다.
  • 속성은 키보드와 같은 입력 장치에서 입력할 수 있지만, 객체는 생성자를 호출하여 생성한다.

 

### 5.3.4 Association

  • 연관성은 하나 이상의 크래스 사이의 관계이며, 한클래스의 개체가 다른 클래스의 개체와 관련될 수 있음을 나타낸다.

### 5.3.5 Multiplicity and Role(다중성 과 역할)

은행 계좌를 예로 들때, 고객은 동일한 두개의 계좌를 가질 수 있을 수 있고, 또 그렇지 않을 수 있다. 이러한 다중성을 식별하고 지정해야 한다.

### 5.3.6 Aggreation(집계)

  • 실제 어플리케이션에서는 부분적 관계를 자주 접할 수 있다. 예를들어 엔진과 자동차, 책과 챕터와 같은 관계이다.

### 5.3.7 Inheritance (상속)

클래스간의 일반화 또는 전문화 관계를 나타내기 위해 "상속"이라는 용어를 사용한다.

### 5.3.8 Inheritance and Polymorphism

  • 다형성은 하나의 사물이 다른 형태를 취할 수 있다는 것을 의미한다.
  • 상속은 한 클래스(보통 자식 클래스)가 부모 클래스보다 더 구체적이다.
  • 다형성은 어떤 것이 다른 형태를 취할 수 있다

### 5.3.9 Association Class (연관 클래스)

  • 연결 자체에 대한 정보를 저장한다.
  • 연관 클래스는 연관 인스턴스에 대한 속성과 동작을 정의하는 특수한 클래스이다.

 

## 5.4 STEPS FOR DOMAIN MODELING (도메인 모델링 단계)

  1. 어플리케이션 도메인의 정보를 수집한다
  2. 브레인 스토밍한다
  3. 브레인 스토밍 결과를 클래스, 속성, 상속관계, 등등으로 분류한다.
  4. UML과 같이 도메인 모델을 시각화 한다.
  5. 도메인 모델을 리뷰한다.

위의 과정을 몇번씩 반복하여 실행한다.

 

## 5.5 PUTTING IT TOGETHER

  • 수도권 자동차 렌탈 서비스를 토대로, 브레인스토밍, 분류, 시각화의 과정을 보여줌

## 5.6 GUIDELINES FOR DOMAIN MODELING

  • 개인적인 활동이 아닌 팀적인 활동으로써 브레임 스토밍과 분류과정을 수행해야 한다.
  • 브레인 스토밍을 한후 분류한다
  • 각 브레인스토밍 및 분류 세션들은 1~2시간 동안 진행되어야 한다.
    • 브레인 스토밍과 분류를 동시에 진행하면 안된다
    • 2시간이 지나면 효율이 떨어진다
  • 토론이나 회의를 효율적으로 조정하는 중재가있어야 하고, 다른길로 세지 않게 해야한다.
  • 소프트웨어 갭라에서 내리는 모든 결정은 흑/백과 같이 완벽히 분류가 될 수 없는 문제와 결정들이다.

 

## 5.7 APPLYING AGILE PRINCIPLES

고객 및 사용자와 긴밀히 협력하여 고객의 애플리케이션 및 애플리케이션 도메인을 이해하낟.

도메인에 대한 팀원 모두의 이해가 있을때만 도메인 모델링을 수행하고, 간단하게 도메인 모델링을하고, 점차 확장해 나간다.

 

저작자표시 (새창열림)

'• 독서 > Object Oriented Software Engineering' 카테고리의 다른 글

[Object Oriented S/E] Chapter 7 - Deriving Use Cases from Requirements  (0) 2023.05.04
[Object Oriented S/E] Chapter 6 - Architectural Design  (0) 2023.04.28
[Object Oriented S/E] Chapter 4 - Software Requirements Elicitation  (0) 2023.04.06
[Object Oriented S/E] Chapter 3 - System Engineering(2)  (0) 2023.03.29
[Object Oriented S/E] Chapter 3 - System Engineering(1)  (0) 2023.03.27
    '• 독서/Object Oriented Software Engineering' 카테고리의 다른 글
    • [Object Oriented S/E] Chapter 7 - Deriving Use Cases from Requirements
    • [Object Oriented S/E] Chapter 6 - Architectural Design
    • [Object Oriented S/E] Chapter 4 - Software Requirements Elicitation
    • [Object Oriented S/E] Chapter 3 - System Engineering(2)
    김호쭈
    김호쭈
    공부하고 정리하고 기록하기

    티스토리툴바