[소프트웨어분석 및 설계] UP Modeling 기법

 

SW 개발 방법론의 timeline

---

• ⭐소프트웨어 개발 방법론은 소프트웨어 개발 과정을 구조화하고 통제하기 위한 프레임워크이다

 

모델링언어–4 Layers

---

 

계층 (Layer)	설명 (Description)	예시 (Example)
meta-metamodel	메타모델을 정의하기 위한 언어를 정의하는 계층. 메타모델링 아키텍처의 기반 구조 제공	MetaClass, MetaAttribute, MetaOperation
metamodel	메타-메타모델의 인스턴스. 모델을 정의하는 언어를 명세	Class, Attribute, Operation, Component // 모델을 정의하기 위함
model	메타모델의 인스턴스. 특정 정보 도메인을 설명하는 언어를 정의	StockShare, askPrice, sellLimitOrder, StockQuoteServer
user objects (user data)	모델의 인스턴스. 실제 데이터를 의미하며, 특정 정보 도메인에 속함	<Acme_SW_Share_98789>, 654.56, sell_limit_order, <Stock_Quote_Svr_32123>

• meta-metamodel → metamodel: 메타모델을 정의하는 언어 제공
• metamodel → model: 모델을 정의할 수 있도록 도메인 언어 제공
• model → user object: 사용자 데이터를 구조화 및 해석

1. MOF Meta-Metamodel Layer

• UML과 같은 메타모델을 정의하기 위한 언어를 제공
• 예: <<metaclass>> Class, <<metaclass>> Attribute, <<metaclass>> Operation
• 👉 UML의 구조 자체를 설명하는 수준 (즉, 모델링 언어의 정의)

2. UML Metamodel Layer

• UML 모델을 구성하는 기본 요소 정의
• 예: Class, Attribute, Operation 등은 MOF의 metaclass 인스턴스
• 👉 분석 모델(예: PassengerTicket)을 만들기 위한 설계 언어

3. Analysis Model Layer (Model Layer)

• 사용자가 설계한 구체적인 모델
• 예: PassengerTicket 클래스는 Class의 인스턴스
• 👉 설계자(모델러)가 작성하는 실제 설계 모델

4. User Object Layer (Instance Layer)

• 실제 데이터 인스턴스를 표현
• 예: 45723990560: PassengerTicket 객체
• 👉 설계된 모델의 실행 또는 데이터 표현 결과

 

 

UP(Unified Process)

---

1. RUP(Rational Unified Process)에서 출발
   • Rational 사에서 개발한 소프트웨어 개발 프로세스
   • UP은 그 기본 틀을 따름
2. 반복적 활동 (Iterative & Incremental)
   • 소프트웨어 개발 과정을 반복(iteration)하면서 점진적으로(incremental) 완성해감
   • 각 반복(iteration)은 요구 분석, 설계, 구현, 테스트 등을 포함
3. 활동 기반 구성 (Activity-driven)
   • 프로젝트 전체는 다음 6가지 핵심 작업으로 구성됨
     • 비즈니스 모델링 (Business Modeling)
     • 요구 분석 (Requirements)
     • 설계 (Analysis & Design)
     • 구현 (Implementation)
     • 테스트 (Test)
     • 배포 (Deployment)
4. ⭐ 단계(Phase) 기반 진행
   • 각 반복 주기 안에서도 단계별로 명확한 목적이 있음
     • Inception (개념/개시): 범위 정의, 주요 리스크 식별
     • Elaboration (전개/정련): 아키텍처 정의, 설계 확정
     • Construction (구축): 시스템의 실제 구현
     • Transition (전환/전이): 사용자 배포 및 테스트

 

 

UP(Unified Process) 의 4단계 프로세스

---

1. Inception (개시)

• 프로젝트의 비전과 요구사항, 비즈니스 케이스, 범위, 대략적인 비용 추정을 정의하는 단계
• 목적: “무엇을 만들 것인가?”를 명확히 함

2. Elaboration (정련)

• 정제된 비전, 핵심 아키텍처(구조)를 정의
• 대부분의 요구사항 범위를 식별
• 고위험 요소 식별 및 해결
• 목적: *“어떻게 만들 것인가?”*에 대한 기반 확립

3. Construction (구축)

• 반복적인 구현 수행
• 실제 제품을 개발하고 배포 준비
• 목적: “무엇을 구현할 것인가?”

4. Transition (전이)

• 베타 테스트, 실제 사용자 배포 진행
• 사용자 피드백을 반영하여 최종 조정
• 목적: “어떻게 사용자에게 전달할 것인가?”

이 네 단계는 순차적으로만 진행되는 것이 아니라 ⭐반복(iteration)되며 점진적으로 소프트웨어를 완성해 나가는 반복적·점진적 개발 방식

 

 

 

UP(Unified Process) - Inception (개시) 단계

---

1. 비전과 비즈니스 케이스 (Vision and Business Case)

• 상위 수준의 목표와 제약사항 명시
• 프로젝트가 왜 필요한지, 비즈니스 가치와 목적 정리

⭐2. 유스케이스 모델 (Use Case Model)

• 기본적인 요구사항 기술
• 전체 유스케이스 중 약 10% 분석
• 핵심 시나리오 우선 작성

3. 보충 명세서 (Supplementary Specification)

• 비기능적 요구사항 기술 (ex: 보안, 성능, 가용성 등)

4. 용어집 (Glossary)

• 도메인에서 사용되는 중요 용어 정의

5. 프로토타입과 개념 증명 (Prototypes and Proof of Concepts)

• 기술적 방안에 대한 탐색과 검증
• 비전 실현이 가능한지를 시사

6. Iteration 계획 (Iteration Plan)

• 다음 단계인 Elaboration의 첫 반복(Iteration)에서

 

 

UP(Unified Process) - Elaboration (정련) 단계

---

1. 개요

• 객체지향 시스템 구축에 필요한 기본적이고 공통적인 OOA(Object-Oriented Analysis) 기술에 중점을 둔다.
• 핵심 아키텍처를 정의하고 주요 유스케이스를 구현하는 단계이다.

2. 특징

• 반복적 개발(Iterative Development)을 통해 개발이 진행된다.
• 모든 요구사항을 한 번에 구현하지 않고, 핵심적인 시나리오부터 점진적으로 구현한다.
• 🌟하나의 유스케이스나 기능은 복잡할 수 있으므로, 여러 iteration에 나누어 구현된다.

3. 도표 설명

• "Use Case: Process Sale" 유스케이스가 여러 반복에 나누어 구현되고 있음
• "Feature: Logging" 등의 기능도 필요한 반복에 배정되어 개발된다.
• 반복적으로 점진적 완성 방식으로 프로젝트가 구성됨을 보여준다.

4. 목적

• 시스템의 핵심 기능과 아키텍처 안정화
• 주요 리스크 식별 및 제거
• 기술적 기반 확보와 안정적 개발 진행 준비

 

Elaboration 단계의 산출물

---

⭐1. Domain Model (도메인 모델)

• 정의: 문제 도메인(현실 세계)의 개체(Entity), 그 속성(Attribute), 관계(Relationship)을 시각적으로 표현한 모델입니다.
• 목적: 시스템이 다루어야 할 정보와 개념을 명확히 이해하고 분석하는 데 도움을 줍니다. 
• 예시:
  • 클래스: Customer, Order, Product
  • 관계: Customer는 여러 개의 Order를 가진다 (1:N)
• 활용: 유스케이스 모델과 연결되어 객체 중심의 설계로 이어지는 기초를 마련합니다.

 

⭐2. Design Model (설계 모델)

• 정의: 시스템의 구조적 설계를 다이어그램으로 표현한 것으로, 실제 구현을 위한 설계 청사진 역할을 합니다.
• 구성요소:
  • 클래스 다이어그램: 구현 클래스와 그 관계, 책임을 표현 → 구조 모델
  • 시퀀스 다이어그램 / 커뮤니케이션 다이어그램: 객체 간 메시지 교환 흐름 → 행위 모델
  • 패키지 다이어그램: 시스템을 구성하는 모듈 단위의 구조 → 구조 모델
• 역할: 로직 흐름과 책임 분배를 명확히 하여 객체지향 설계의 구체화를 지원

 

⭐3. Software Architecture Document (소프트웨어 아키텍처 문서)

• 정의: 전체 시스템의 핵심 설계 구조를 기술한 문서로, 품질 속성(성능, 보안, 유지보수성 등) 달성을 위한 아키텍처 결정을 담음
• 내용 예시:
  • 계층 구조 (프레젠테이션, 도메인, 인프라 등)
  • 주요 설계 패턴 사용 여부 (MVC, Singleton, DAO 등)
  • 시스템 간 인터페이스, 통신 방법
• 중요성: 개발 팀원 전체가 동일한 구조적 이해를 공유하게 하며, 유지보수성과 확장성을 고려한 설계를 담보합니다.

 

⭐4. Data Model (데이터 모델)

• 정의: 시스템에서 사용하는 데이터 구조를 기술하며, 특히 DB 구조와 객체 간 매핑을 표현
• 내용:
  • ER 다이어그램(개체-관계 모델)
  • 데이터베이스 스키마(SQL 기반 정의)
  • 클래스 ↔ 테이블 매핑 전략 (ORM 매핑 예: JPA, Hibernate)
• 활용:
  • 데이터베이스 설계 및 생성
  • DAO(Data Access Object) 계층 개발에 활용

 

⭐ 5. Storyboards, UI Prototypes (스토리보드 및 UI 프로토타입)

• 정의: 사용자와 시스템 간 상호작용을 시각적으로 묘사한 것으로, UI 흐름을 빠르게 확인할 수 있도록 도와줍니다.
• 내용:
  • 화면 설계 초안 (Wireframe, Sketch)
  • UI 흐름도 (Navigation Flow)
  • 버튼 클릭 → 다음 화면 전환 등 인터랙션 설명
• 장점:
  • 개발 전 사용자 피드백 수집 가능
  • 사용성을 사전에 검토 가능
  • 개발자 - 디자이너 - 고객 간 커뮤니테이션 도구 역할 

 

모델	설명	관계
Domain Model (Business Modeling)	개념적 객체 정의 (ex. Sale, SalesLineItem)	유스케이스와 설계모델의 기반이 됨
Use-Case Model (Require-ments)	사용자 행동 흐름 및 시스템 기능 요구	도메인 모델 참조 + 설계 모델의 동작 흐름을 정의
Design Model	객체 간 메시지 흐름 및 클래스 설계	유스케이스 동작을 코드 수준으로 구체화

 

 

UP(Unified Process) - construction (구축) 단계

---

 

Construction Phase (개발 단계)

목적

• 사용자에게 전달될 수 있는 실행 가능한 소프트웨어를 점진적으로 개발하는 것이 핵심
• 즉, 프로덕션 수준의 품질을 갖춘 제품을 목표로 구현합니다.

 

 

주요 산출물 (Deliverables)

항목	설명
반복주기의 검증기준	각 이터레이션(iteration)의 결과물이 목표 요건을 충족하는지 확인하는 품질 기준 문서.
실행 가능한 단위 배포	실제 시스템의 부분 구현. 테스트 및 피드백 수집을 위해 사용자 또는 테스트 환경에 배포 가능한 실행 파일 또는 모듈.
동적 프로토타입	기능적으로 동작하는 부분 시스템 시제품으로, UI 흐름이나 핵심 기능을 테스트.
품질 보증 결과물	테스트 결과, 코드 리뷰, 통합 테스트 등 QA 활동의 산출물. 신뢰성과 안정성 확보를 위한 증거 자료.
시스템 문서 / 사용자 문서	- 설계서, 구성도, 배포 문서 등 개발자 또는 운영자를 위한 기술 문서. -메뉴얼, 도움말 파일 등 일반 사용자를 위한 사용 지침.

 

 

특징 요약

• 실제 제품에 가까운 실행 가능한 버전을 점진적 반복(iteration) 을 통해 개발
• 테스트와 검증, 사용자 피드백을 반영하면서 위험 요소 제거
• 품질과 유지보수성이 보장된 코드를 생산하는 단계

 

 

Unified Process 의 구성

---

용어	의미	상세 설명
작업자 (Worker)	작업을 수행하는 사람 또는 역할	시스템 분석가, 설계자, 프로그래머, 테스터 등 역할 기반. 산출물의 책임자. 예: Designer
작업 (Activity)	수행해야 할 작업	명확한 목적을 가진 액션 단위. 예: Use-Case Analysis, Use-Case Design
산출물 (Artifact)	작업의 결과물	작업을 통해 만들어진 문서, 모델, 코드 등. 예: Use Case Realization
워크플로우 (Workflow)	작업 순서 흐름	작업 간의 논리적 실행 순서. 의미 있는 결과를 도출하는 작업 흐름 구성. 예: 요구분석 → 설계 → 구현

 

 

Unified Process 의 단계별 모델

---

⭐비즈니스 프로세스 모델 (Business Process Model)

• 목적: 실제 업무 절차와 흐름을 정의
• 설명: 소프트웨어가 해결해야 할 비즈니스 문제를 명확히 파악하고, 전체 시스템의 맥락을 이해하기 위한 모델
• 예시: 업무 흐름도, BPMN 등

⭐도메인 모델 (Domain Model)

• 목적: 문제 영역의 개념적 구조 정의
• 설명: 시스템이 다루는 개념(엔티티), 속성, 관계를 시각화. 클래스 다이어그램으로 표현됨
• 예시: 고객, 주문, 제품 등 비즈니스 객체

⭐유스케이스 모델 (Use Case Model)

• 목적: 사용자 관점에서 시스템 요구사항 정의
• 설명: 사용자가 시스템을 통해 어떤 기능을 사용할 수 있는지 정의. 기능 중심의 모델
• 예시: "주문하기", "결제하기", "상품 검색하기"

⭐분석 모델 (Analysis Model)

• 목적: 유스케이스 기반의 요구사항 분석
• 설명: 요구사항을 논리적 수준에서 구조화하여 시스템이 수행할 기능을 명확히 정의
• 기술: 클래스 다이어그램, 시퀀스 다이어그램 등

⭐설계 모델 (Design Model)

• 목적: 분석 모델을 기반으로 실제 시스템 구조 설계
• 설명: 컴포넌트 구조, 클래스 간의 책임 분리, 인터페이스 설계 등
• 도구: UML 설계 도구 (클래스, 컴포넌트, 패키지 다이어그램 등)

⭐아키텍처 모델 (Architectural Model)

• 목적: 전체 시스템 구조의 뼈대를 정의
• 예시: 3-tier 구조, MSA 구성도, 배포 다이어그램

⭐데이터 모델 (Data Model)

• 목적: 데이터 저장 구조 정의
• 설명: 시스템의 계층, 모듈 간 연결, 기술 스택, 주요 컴포넌트 구성 등을 시각화
• 설명: DB 테이블, 관계, 제약 조건 등을 정의
• 종류: ERD, 논리/물리 모델, 스키마

⭐구현 모델 (Implementation Model)

• 목적: 실제 시스템 구현
• 설명: 위 설계 내용을 기반으로 작성된 소스코드 및 구성 파일
• 도구: Git, Java/Python 코드, API 문서 등

구분	모델명	목적
비즈니스 프로세스 정의 요구사항 및 유스케이스 정의	비즈니스 프로세스 모델, 도메인 모델, 유스케이스 모델	문제 정의 및 요구사항 도출
분석/설계	분석 모델, 설계 모델, 아키텍처 모델, 데이터 모델	시스템 구조화 및 기술적 설계
구현	구현 모델	실제 소프트웨어 구현

 

 

 

 

 

UP - 비즈니스 프로세스 정의

---

• 비즈니스 프로세스란?
  • 조직 내에서 어떤 업무가 어떻게 수행되는지를 표현한 것
  • 추상적이지만 업무 수행 흐름에 대한 이해를 도와줌
• 비즈니스 프로세스 모델이란?
  • 이러한 업무 수행 흐름을 시각적 또는 모델링 기법으로 표현한 것
  • 시간, 공간, 역할자(Actor)를 중심으로 표현함

1. 업무 기능 분해
   • 조직 내에서 수행되는 업무를 기능 단위로 나누는 작업
   • 예: ‘주문 처리’, ‘재고 확인’, ‘결제 처리’ 등의 상위 기능 식별
2.  업무 역할 도출
   • 업무 기능을 수행하는 사람 또는 시스템(Actor) 식별
   • 예: 고객, 관리자, 재고 시스템 등
3. 행위 (action) 도출
   • 각 역할이 수행하는 구체적인 행동 또는 이벤트 도출
   • 예: 고객 → 주문 생성, 관리자 → 상품 승인
4. 업무 흐름도
   • 역할과 행위를 바탕으로 전체 비즈니스 프로세스 흐름을 시각화
   • 각 단계에서 어떤 역할이 어떤 작업을 수행하는지 나타냄
5. 도메인 모델
   • 위 과정에서 파악된 업무 개념을 기반으로 도출된 정적 모델
   • 즉, 개념적 클래스(객체), 속성, 관계들을 추상화하여 표현
   • 예: 주문, 고객, 상품, 결제 등

 

⭐ 도메인 모델 (Domain Model)

 

정의

• 비즈니스 영역에서 사용되는 개념들을 시각화한 모델
• 현실 세계의 객체, 속성, 관계 등을 개념적으로 표현한 것
• 소프트웨어 구조가 아닌, 업무와 개념 중심의 모델

특징

• ⭐현실 세계의 개념을 추상화한 것으로, 아직 소프트웨어 설계는 아님
• 예: 주문(Order), 고객(Customer), 상품(Product) 등
• 시스템이 아닌 업무 관점에서 '무엇이 존재하는가를 정의

목적

• 비즈니스 이해관계자와 개발자 간의 공통 이해 기반 형성
• 분석 및 설계의 출발점으로 사용됨

포함 요소

• 개념적 클래스: 도메인 내 존재하는 주요 객체들
• 속성: 각 객체가 가지는 고유한 특성
• 연관관계: 객체 간의 관계

예시 (온라인 쇼핑몰 도메인)

개념적 클래스	속성	관계
고객(Customer)	이름, 주소	주문을 한다(Order)
상품(Product)	이름, 가격	주문 항목(OrderItem)에 포함
주문(Order)	주문일, 배송상태	고객이 생성

 

 

UP - 요구사항 정의

---

유스케이스 모델을 통해 SW의 기능적인 요구사항을 모델링함

이를 통해 사용자 중심의 명세와 시스템 기능의 명세 모두 가능하게 함

 

유스케이스 모델의 목적

• SW의 기능적인 요구사항을 모델링하기 위한 방법
• 사용자 중심의 시스템 기능 명세 및 흐름을 명확히 정의할 수 있게 도와줌

흐름 설명

1. 요구사항 정의
   • 고객 또는 사용자의 입장에서 시스템에 기대하는 동작을 정의하는 단계
2. Actor 도출
   • 시스템과 상호작용하는 외부 주체 (예: 사용자, 외부 시스템 등)를 식별
   • 예: "관리자", "회원", "결제 시스템"
3. UseCase 도출
   • Actor가 시스템에 대해 요청하는 기능을 도출
   • 예: "상품 등록", "로그인", "예약 확인"
4. UseCase Diagram
   • 도출된 Actor와 UseCase를 연결하여 전체 기능 흐름을 시각적으로 표현
5. UseCase 명세서 
   • 각 유스케이스에 대해 시작 조건, 기본 흐름, 예외 흐름, 후조건 등을 문서화
6. UI 정의
   • 유스케이스를 기반으로 어떤 화면 요소(UI) 가 필요한지 정의
   • 예: 버튼, 입력창, 리스트 등

항목	설명
Actor	시스템 외부에서 상호작용하는 사용자나 외부 시스템
UseCase	Actor가 시스템에 요청하는 기능 단위
UseCase Diagram	기능 흐름을 시각화한 다이어그램
UseCase 명세서	각 UseCase의 세부 흐름 명세
UI 정의	UseCase 기반의 화면 설계 참고자료

 

UP -분석 모델링

---

 

분석 모델 구성 요소

⭐분석 모델은 초기 요구 사항을 바탕으로 만들어짐

 

객체지향 모델링을 통해 요구사항을 개발 시스템에 반영하기 위한 작업

1. 분석 클래스 도출
   • 시스템에서 주요 개체(class) 를 식별하여 모델링
   • 객체지향 시스템의 기반
2. 오퍼레이션 정의
   • 각 클래스에서 수행해야 할 기능(메서드) 정의
3. 데이터 타입 정의
   • 속성과 오퍼레이션에서 사용할 자료형 및 구조화된 타입 정의
4. 속성 정의
   • 클래스가 가지고 있는 데이터 항목(필드) 정의
5. 상호작용 설계
   • 클래스 간의 메시지 교환, 협력 관계 정의
   • 주로 시퀀스 다이어그램, 커뮤니케이션 다이어그램 등을 통해 표현
6. 객체 구조 설계
   • 클래스들 간의 연관 관계, 상속 관계, 구성(composition) 등을 정의
   • 전체 시스템의 정적 구조를 도식화함 (예: 클래스 다이어그램)

 

UP - 설계 모델링

---

SW 시스템의 구조와 이의 구성요소 , 그들의 관계를 표현한다

sw 아키텍처 모델은 SW 아키텍처를 추상화하여 표현함

 

 

클래스 종류

---

• 노란 원: Control 클래스 (제어 클래스)
  • 시스템 흐름과 비즈니스 로직을 담당
  • 예: 상품주문Ctr
• 회색 원: Entity 클래스 (엔티티 클래스)
  • 시스템 내 데이터 구조 표현
  • 예: 회원Ent, 주문Ent, 상품Ent
• 밝은 회색 원: Boundary 클래스 (경계 클래스)
  • 사용자 또는 외부 시스템과의 인터페이스
  • 예: 주문결제Bnd, 쿠폰적용Bnd

단계	설명
설계 클래스 도출	분석 모델 기반으로 실제 구현 클래스 정의
구현 오퍼레이션 정의	클래스별로 수행해야 할 기능(메서드) 정의
구현 상호작용 설계	클래스 간 메시지 흐름 설계 (시퀀스 다이어그램 기반)
구현 객체 구조 설계	클래스 간 상속, 집합 관계 등의 구조 설계
클래스 설계서	위의 내용을 문서화하여 명세서로 정리

 

 

설계 모델의 예

---

1. 유스케이스는 분석모델 구성의 기본을 제공한다.
2. 분석모델을 통해 요구사항을 구체화하고, 설계모델에서는 이를 실제 구현 클래스로 확장합니다.

• Use Case Model:
  • Customer가 사용하는 유스케이스: Withdraw money, Deposit money, Transfer between accounts
  • 단순한 기능 요구사항을 보여주는 유스케이스 다이어그램
• Analysis Model:
  • 유스케이스(Withdraw money)에 대한 분석모델
  • Boundary: Dispenser, Cashier interface
  • Control: Withdrawal
  • Entity: Account
  • ⭐분석모델 단계에서 유스케이스를 구체화하여 역할별 객체(Boundary, Control, Entity)로 분해

    3. Collaboration 모델은 관련 객체간의 역할을 가시화

    4. ⭐분석모델에 근간하여 설계모델의 클래스들을 확정한다

• Collaboration Model:
  • Customer의 행위 흐름을 시나리오처럼 표현
  • 각 객체들의 상호작용과 역할이 보임 (Control/Boundary/Entity)
• Analysis Model → Design Model (분석 모델 → 설계 모델)
  • Analysis Model: 추상적 객체 간 구조 (예: Withdrawal, Account, Dispenser)
  • Design Model: 실제 구현 클래스 구조