4 분 소요

이 포스트에는 저번 Use Case 로는 부족한 Requirement와 Domain Model에 대해 다루려고 한다.

Other Requirements

Use Case 외에도 요구사항 분석 단계에서 다뤄지는 여러 가지 산출물

시스템 정의시에 Use Case만으로 부족하기에 추가적으로 필요한 문서/정보들을 나타냄.

1. Supplementary Specification

  • Use Case에서 다루지 않는 기타 요구사항들(주로 비기능 요구사항)을 정리하는 문서
  • URPS+가 포함
    • U : Usability (사용성)
    • R : Reliability (신뢰성)
    • P : Performance (성능)
    • Supportability (지원성)
    • + : constraints, standards, licensing, etc..
  • 보안, 국제화, 문서화
  • 성능, 복구성, 확장성
  • 법적 요구사항, 라이센스, 표준 등

비기능 요구사항이 아키텍처 결정에 큰 영향

2. Glossary

  • 시스템에서 사용하는 용어 정의 모음집
  • 데이터 사전 역할을 함.
  • 고객, 기획자, 개발자 간의 의사소통 오류를 줄이는 데 필수

3. Vision

  • 프로젝트의 전반적인 목표, 배경, 전략 방향을 요약한 문서
  • Executive Summary라고도 부르며, 왜 이 프로젝트를 하는지, 최종적으로는 무엇을 만들 것인지에 대한 큰 그림을 제시함

4. Business Rules

  • 시스템에 적용되는 비즈니스 정책/규칙을 정의
  • 시스템 로직과는 분리된 오랜 기간 유효한 규칙
  • 예 : 세금 법률, 할인 정책, 배송 조건, 회원 등급 기준 등..

Inception(시작 단계)에서만 요구사항을 철저히 분석해야 하는가?

NO

  • UP는 반복적이고 점진적인 개발 방법론
  • 요구사항을 한 번에 완벽하게 다 분석하지 않는다.
  • 오히려 초기에 일부만 정리하고, 개발과 테스트를 하면서 요구사항을 점진적으로 발전시켜나감.

Quailty Requirements and Architecture

핵심 문장 : 기능 요구사항은(FR, Functional Requirement)만으로는 아키텍처를 어떻게 설계해야 할지 결정할 수 없다.

  • 기능 자체는 ‘무엇을 해야한다’ 지만, 어떻게 나눌지는 정해주지 않음.
  • 기능만 따지면 굳이 시스템을 나눌 이유가 없다.

=> 즉, 우리는 실제로 시스템 설계를 계층, 컴포넌트, 클래스, 데이터베이스 등과 같이 협력하는 구조로 설계한다.

  • 단순한 기능을 구현하기 위함이 아닌, 다양한 품질 속성(quailty attributes)를 만족시키기 위해서

Availability Requirement

  • 시스템이 사용하고자 할 때 실제로 동작 가능하고 접근 가능한지를 의미함.

  • 즉, 시스템이 고장나지 않고, 언제든 사용할 수 있어야 한다는 비기능 요구사항

  • FURPS+ 에서 R(Reliability)에 해당

  • 공식 \(\text{Availability} = \frac{\text{MTTF}}{\text{MTTF} + \text{MTTR}}\)

    • MTTF(Mean Time To Failure)
      • 고장나기까지 걸리는 평균 시간
      • 시스템이 잘 돌아가는 시간
    • MTTR(Mean Time To Repair)
      • 고장 후 복구하는데 걸리는 평균 시간
      • 고장났을 때 고치는데 걸리는 시간
    • MTBF(Mean Time Between Failures)
      • MTTR + MTTF

    => Availability를 높이기 위해서는 MTTF가 높거나(고장이 잘 안나는 시스템), MTTR이 낮아야(고장이 나도 빨리 고친다.) 한다.

Quailty Attribute Secnario

  • 품질 요구사항을 시나리오 형태로 표현하여 정의, 우선순위 결정, 문서화하는 방법
  • 정상적이고 추상적인 품질 속성은 애매하기에 이를 구체적 시나리오로 표현해서 명확하게 정의
  • 시나리오를 통해 자극(Stimulus)과 반응(Response)에 대응
  • Basic Quality Attribute Scenario 구성 핵심요소 (위의 3가지가 제일 key)
    • measure : 시스템이 어떻게 반응했는지를 정량적으로 평가하는 기준
    • response : 시스템이 취하는 반응이나 처리 방법
    • stimulus : 시스템에 무언가 발생하거나 요청되는 사건
    • source : 자극을 유발하는 주체 로 사용자
    • artifact : 자극이 영향을 주는 시스템 구성요소
    • environment : 자극이 발생하는 시스템 상태 또는 맥락

Iteration 1

여기서는 Iteration 1 단계에서의 역할을 정의하고, Elaboration 단계에서의 핵심 개념을 정리한다.

반복 개발의 기본 원칙

  • 한 번에 모든 요구사항을 구현하지 않음.
  • 기능 일부만 반복적으로 개발
    • 동일한 Use Case도 여러 iteration에 걸쳐 점진적으로 완성됨.
  • 짧은 Use Case는 한 번에 끝날 수도 있음.

Inception 단계

  • 1주 이내의 짧은 단계
  • 주요 활동:
    • 요구사항 워크숍 (actors, goals, use cases 목록화)
    • Vision & Supplementary Specification v1 작성
    • 위험 식별 및 리스트 작성
    • 기술 실현 가능성 조사 (PoC, UI 프로토타입)
    • 구매/재사용/개발 판단
    • 초안 아키텍처/도구/1차 iteration 계획 수립

Elaboration 단계

  • 시스템의 핵심 구조(architecture)를 잡고, 위험 요소(risk)를 해결하며, 대부분위 요구사항을 명확히 하는 초기 반복
  • 핵심 아키텍처를 구현 및 테스트하는 초기 반복들
  • 주요 요구사항을 발견하고 안정화
  • Elaboration의 Artifacts
Artifact 설명
Domain Model 도메인 개념/엔티티 시각화
Design Model 클래스/객체/패키지 등 설계 다이어그램
Software Architecture Document 아키텍처 핵심 이슈 및 해결 요약
Data Model DB 스키마, 객체-비객체 매핑 전략
Use Case & UI Prototype UI 경로, 네비게이션, 사용성 모델

Use Case Ranking

선정 기준

  1. Risk : 기술적 복잡도, 불확실성, 사용성 등
  2. Coverage : 시스템의 주요 부분을 넓고 얕게 터치
  3. Criticality : 비즈니스 가치가 높은 기능을 우선해서 구현

이 기준을 통해 High, Medium, Low 로 나뉨

-> 이 Iteration에서 high ranking을 구현해야함.

Domain Model

Domain Model이란?

  • 시스템이 작동하는 문제 영역(도메인)의 개념과 구조를 시각적으로 표현한 모델

  • 즉, 현실 세계의 개체(객체)들 간의 관계를 객관적이고 개념적으로 그린 그림

  • OO analysis 안에 가장 중요한 classic model

  • Domain Model은 소프트웨어 객체를 포함하지 않음. (코드 중심 객체 모델이 아님)

    주 목적은 설명, 기능동작이 아니라 도메인에서 어떤 개체가 있고 어떤 관계가 있는지를 설명함.

    또한, domain과 domain layer만의 representation gap을 좁힐 수 있다.

  • Domain Model 예시

Domain Model

Create Domain Model

  1. 개념적 클래스 (Conceptual Classes)를 찾기
    • 기존 모델을 재사용하기(보편적 도메인을 참조하기)
    • Category List 사용하기
    • Noun Phrase 사용하기 -> Use Case Text에서 명사를 추출하여 후보 도출
  2. UML 클래스 다이어그램으로 표현하기
  3. 클래스에 속성과 연관관계(attributes and associations)를 추가하기
    • 개념적 클래스 (conceptual Class) : 실세계 개념
    • 속성 (Attribute) : 개념적 클래스의 정보 요소
    • 설명 클래스 (Description Class) : 다른 객체에 대한 정보를 설명하거나 정의하는 역할

도메인 모델링에서 흔히 하는 실수

  • 현실세계에서 X가 숫자나 텍스트로 여겨지지 않는다면, X는 개념적 클래스(conceptual class)일 가능성이 높다.
    • 개념이 현실에서 단순 문자열이나 숫자 => 속성(attribute)
    • 개념이 현실에서 독립된 실체, 조직, 장소 => 클래스(class)

Association (연관관계)

  • 두 클래스 사이의 의미 있는 연결
  • UML에서는 객체 간의 지속적인 의미 관계로 정의
  • 연관관계는 시스템이 기억해야 할 정보가 있는 경우에만 포함

하나의 클래스 쌍 사이에 여러 개의 연관관계도 가능함.

  • 도메인 모델 내 연관관계는 개념적 관점(conceptual perspective)의 관계
    • 즉, 코드로 구현되기는 하지만 개념적으로 이해하기 위한 관계 표현

Attributes (속성)

  • 객체(Object)의 논리적인 데이터 값 (logical data value)
  • 속성 표기법
    • visibility name : type multiplicity = default {property}

참고

Concurrency, Locks

8 분 소요

이번 포스트는 OS의 Concurrency와 Locks에 대해 다룬다.