6. 객체지향 분석-기초설계

6.2 UML

6.2.1 UML 개요

UML(Unified Modeling Language): 시스템 설계를 그림으로 그리는 표준 모델링 언어. 분석가·설계자·개발자가 같은 그림 보고 얘기하려고 만든 공통어

6.2.2 UML 다이어그램 유형

UML 2.5 다이어그램: 구조·행위 두 계층, 총 14가지

• 구조 다이어그램: 시스템의 정적 구조. 뭐가 있고 어떻게 연결됐는지, 시간 흐름 없음 (예: 클래스 다이어그램)
  • 유형: 클래스, 객체, 패키지, 복합 구조, 컴포넌트, 배치, 프로파일 (7)
• 행위 다이어그램: 시간 흐름에 따라 시스템이 어떻게 움직이는지 (예: 시퀀스 다이어그램)
  • 유형: 사용사례, 활동, 상태 머신, 상호작용 (4)
  • 상호작용 다이어그램 세부: 시퀀스, 통신, 타이밍, 상호작용 개요 (4)
• 이 장에서 쓰는 셋: 사용사례 → 행위, 클래스 → 구조, 시퀀스 → 행위(상호작용)

6.2.3 UML 도구

• 상용·오픈소스 둘 다 있음: StarUML, Draw.io, Visio, Lucidchart 등
• 대표는 StarUML

6.2.4 StarUML

StarUML: 가장 인기 있는 UML 상용 소프트웨어. 민첩하고 간결한 모델링이 목표

• 기능: 다중 플랫폼(Mac·Windows·Linux), UML 2.x 준수, SysML, ERD·DFD·순서도, 오픈 API, HTML 문서 내보내기

6.3 기능 모델링: 사용사례 다이어그램

6.3.1 사용사례(Use Case) 다이어그램

기능 모델링: 사용자 눈높이에서 시스템이 "무엇을" 해주는지 그리는 것. 객체지향 분석에서는 사용사례 다이어그램으로 표현

사용사례(Use Case): 시스템이 액터에게 어떤 결과를 내주는 기능 하나 (예: 수강 신청하다). GUI 메뉴 하나 = 사용사례 하나

• 액터: 시스템 밖에서 시스템과 상호작용하는 역할. 막대 사람. 사람뿐 아니라 외부 시스템(DB, 문자인식시스템)도 액터
  • 그림에서: Student 막대 사람, Personal Information System 사각형
• 사용사례: 타원 + 이름. 한 사용사례에 액터 둘 이상 붙어도 됨
• 시스템 경계: 큰 사각형. 안에 사용사례, 밖에 액터. 이름은 <시스템명>
• 외부 시스템: 사각형 안에 이름. 경계 밖에 둠
• 직선(연관): 액터와 사용사례 사이. "이 액터가 이 사용사례를 수행"
• include: 점선 화살표 + <<include>>. 메인이 실행되면 반드시 같이 실행되는 하위 사용사례 (예: 수강 신청하다 → 로그인하다, 인식하다 → 전처리·세그먼테이션·분류·결과출력)
  • 방향: 메인 → 포함되는 하위
• extend: 점선 화살표 + <<extend>>. 예외적·선택적 확장. 메인이 실행돼도 안 불릴 수 있음 (예: 물품을 구매하다 ← 잔돈이 없는 경우, 수강 신청하다 ← 쇼핑카트에 넣다)
  • 방향: 확장 → 메인. include와 반대
• 일반화: 실선 + 빈 삼각형, 하위 → 상위. 공통 부분을 뽑아 상위로 올리는 상속
  • 네 가지: 액터 일반화(학생·교수 → 사람), 사용사례 일반화(청구서 지불 → 카드 결제·잔액 결제), 두 extend 사용사례 간, 두 include 사용사례 간
  • 액터 일반화는 다음 단계 클래스 다이어그램의 상속 관계 찾는 데 쓰임
• 슬라이드 주의: p.29~30은 로그인 뒤 수강신청·취소·변경·조회를 로그인의 extend로, p.32는 수강신청하다가 로그인하다를 include한다고 함. 그릴 땐 필수면 include, 선택이면 extend로 일관되게
• Front-end/Back-end(p.41): 사용사례 = front-end(JSP, PHP, 앱) 메뉴 액션, 클래스 메소드 = back-end(Java, C#, Python)의 삽입·삭제·갱신·검색

6.3.2 사용사례 다이어그램 예제: 수강 신청 관리시스템

• 그리는 순서: 이해관계자 → 액터, 요구사항 문장의 동사 → 사용사례, 모든 사용자 공통 기능(로그인)은 공유 사용사례
• 조교가 관리하는 강의실·교과목목록·개설교과목은 각각 등록(배정)·변경·삭제·조회 네 개씩. 슬라이드는 보라 타원 허브에 실선으로 묶음
• 쇼핑카트에 넣다는 교과목 조회·수강 신청하다의 extend

6.3.3 사용사례 다이어그램 예제: 온라인 쇼핑몰 관리시스템

• 외부 시스템 둘: 공급업체(공급하다), 결제시스템(결제하다)
• 물품 구매하다 → 결제하다는 include(필수), 쇼핑카트에 담다 → 물품 구매하다는 extend(선택)
• 슬라이드 p.40 주의: 고객에 "수강취소하다"가 남아 있음(복붙 실수), extends 화살표 방향이 본문 규칙(확장 → 메인)과 반대

6.3.4 사용사례 다이어그램 사용의 이점

1. 업무 목표 목록으로 시스템 복잡성·비용 산정
2. 설계 초기에 실제 요구사항 파악
3. 자연어 시나리오라 고객·경영진까지 이해
4. 확장 사용사례·예외 식별로 복잡한 요구사항 정의가 쉬워져 개발자 시간 절약
5. 개발 경계 식별로 범위 확장·축소 방지
6. "어떻게"가 아니라 "무엇을"에 집중, 섣부른 설계 방지
7. 사용사례를 테스트 케이스로 바로 변환

6.3.5 사용사례 명세

• 둘 다 사용자 식별·목표 설명에 쓰지만 서로 바꿔 쓸 수 없음

• 다이어그램의 타원 하나당 명세 표 하나
• Method Name이 있음 → 사용사례가 메소드로 이어짐. Brief Processing Descriptions가 6.6 알고리즘 명세로 이어짐
• Specific Requirements에는 비기능 요구(현금 이체 30분 이내)

6.4 구조적 모델링: 클래스 다이어그램

6.4.1 클래스 다이어그램의 구성 요소

구조적 모델링: 시스템의 정적인 뼈대(뭐가 있고 어떻게 연결됐는지)를 그리는 과정. 도구는 클래스·객체·배포·패키지·복합 구조·컴포넌트 다이어그램, 그중 제일 많이 쓰는 게 클래스 다이어그램

• 클래스 박스: 세 칸짜리 사각형
  • 그림에서: 위에서부터 이름, 속성, 연산
• 클래스 이름: 맨 위 칸. 첫 글자 대문자 (슬라이드 표기: Class 학생(Student))
• 속성: 가운데 칸. 첫 글자 소문자 (예: 학번, 성명, 주소, 전화번호, 소속학과)
  • 접근 제한자: private, protected, public. 속성은 보통 private
• 연산(메소드): 맨 아래 칸. 첫 글자 소문자, 이어지는 단어는 대문자 (예: getName, setAddress)
  • 기본 연산: 추가·삭제·갱신·검색 (insert, delete, update, retrieve)
• 분석 단계에선 연산 칸을 비워 두고 속성까지만 그려도 됨 (p.47 오른쪽, 예제 그림들도 두 칸)

6.4.2 클래스 간의 관계 유형

클래스 간 관계: 클래스 사이의 논리적 연결. 슬라이드 기준 6가지

• 연관 대응관계(다중성): 선 양 끝에 1, *, 0~*
  • 1:1 학생-이력정보, 1:0~N 직원-부양가족, 1:N 학과-학생, N:1 학생-학과, N:M 학생-개설교과목
• N:M 표현: E-R은 마름모(수강하다), 클래스 다이어그램은 중간에 연관 클래스(수강하다: 학번, 개설교과목번호, 구분, 연도, 학기, 성적)를 두고 양쪽을 1:N으로 품
• 일반화 vs 상세화: 그림·구현은 같음, 찾는 방향만 반대
  • 일반화: 학생·교수 보고 공통을 뽑아 사람을 만듦 (상향)
  • 상세화: 사람을 먼저 두고 학생·교수를 찾아냄 (하향)
• 집계 vs 컴포지션: 집계는 연관의 특별한 경우, 컴포지션은 집계의 특별한 경우. 차이는 부분의 생명주기가 전체에 묶이느냐
• 슬라이드 주의: p.49 심볼표는 집계·구성을 점선으로 그렸는데 p.54~55 예제는 실선. p.49의 점선 삼각형(상세화)은 실제 UML에선 인터페이스 구현 기호

6.4.3 클래스 다이어그램 예제: 수강 신청 관리시스템

• 순서: 요구사항 표(p.57) → 명사로 클래스 추출(p.58 구름: 학생, 교직원, 학과, 강의계획서, 교과목목록, 개설교과목, 사용 공간) → E-R → 클래스 다이어그램
• N:M은 전부 연관 클래스로: 수강하다(학생-개설교과목), 강의하다(교수자-개설교과목), 배정하다(개설교과목-강의실), 복수전공하다(학생-학과)
• 주의할 점(p.60)
  • 검색이 잦은 연관 클래스(수강하다, 강의하다)엔 일련번호 같은 속성을 추가해 검색 효율을 올림. 대신 데이터 중복이 조금 생김
  • 학생-학과는 N:1이지만 부전공·복수전공·교직·융합전공이 있으니 두 클래스 사이에 연관을 두 개 둠 (직접 선 하나 + 복수전공하다 경유 하나)

6.4.4 클래스 다이어그램 예제: 온라인 쇼핑몰 관리시스템

• 순서는 6.4.3과 같음: 요구사항 표(p.61) → E-R(p.62) → 클래스 다이어그램(p.63)
• 연관 클래스: 구입하다, 주문/납품, 배송하다, 반품/교환, 반품하다
• 반품/교환·반품하다는 0..1: 구입·주문 하나에 반품이 없을 수도 있음
• 슬라이드 주의: p.62 캡션이 "수강 관리시스템 클래스 추출"로 복붙돼 있음

6.5 동적 모델링: 시퀀스 다이어그램

6.5.1 시퀀스 다이어그램의 설계 대상

동적 모델링: 시간에 따라 시스템이 어떻게 움직이는지(작업의 시간·순서, 제어 흐름) 그리는 것

• 상태: 객체가 살아 있는 동안 특정 조건에 놓인 상황 (예: 주문 "결제 대기")
• 트랜지션: 상태가 바뀌는 것 (결제 대기 → 결제 완료)
• 이벤트: 트랜지션을 일으키는 사건 (결제 버튼 클릭)
• 액션: 이벤트로 일어나는, 중간에 안 끊기는 기본 연산
• 동적 모델링 다이어그램
  • 상호작용 다이어그램: 시퀀스 다이어그램, 협업 다이어그램(UML 2의 통신 다이어그램)
  • 상태전환 다이어그램
  • 슬라이드 주의: p.64는 "상태전환 다이어그램이 두 가지로 세분"이라 하지만 둘로 나뉘는 건 상호작용 쪽 (p.65)

시퀀스 다이어그램: 사용사례 하나가 실행될 때 사용자·화면·객체·외부 시스템이 어떤 메시지를 언제 주고받는지 시간 순서로 그린 것 (예: 수강 신청 버튼 누르면 메뉴 → 개설교과목 조회 → 장바구니 → 수강 저장)

• 사용사례 옆에 두고 그 사용사례의 처리 알고리즘 이해를 돕는 용도
• 결국 front-end 객체들 사이의 메소드 호출 순서

• 설계 대상 = 모든 사용사례: 사용사례 하나당 시퀀스 다이어그램 하나
  • 그림에서: 아래 front-end 사용사례 박스 하나하나가 시퀀스 다이어그램 하나, 위 back-end 클래스의 CRUD 메소드를 부름
• 연결: 6.3 사용사례 = front-end 메뉴, 6.4 클래스 = back-end 데이터·CRUD, 6.5 시퀀스 = 메뉴 하나 눌렀을 때 메소드 부르는 순서

• 액터: 막대 사람, 맨 왼쪽
• 객체: 사각형, :클래스명 (예: :Student = Student 클래스의 어떤 객체). 메뉴 화면도 객체로 섬
• 생명선: 객체 아래 세로 점선. 아래로 갈수록 시간이 흐름
• 메시지: 실선 화살표 + 메소드 이름 (예: check(id, pwd))
• 응답: 점선 화살표 + 리턴값 (예: ok, Not exists)
• 자기 호출: 자기한테 돌아오는 굽은 화살표. 객체 안에서 혼자 처리 (예: Input data, Choose(sectionId))

6.5.2 사용사례 '학생을 등록하다'에 대한 시퀀스 다이어그램

• 패턴: 로그인 확인 → check(id)로 중복 확인(Not exists) → 입력 → insert → ok

6.5.3 사용사례 '수강 신청하다'에 대한 시퀀스 다이어그램

• 패턴: 로그인 → retrieve로 개설교과목 조회 → Choose 자기 호출 → 장바구니 insert → :Takes(수강하다)에 insert(Cart) → ok
• :Section = 개설교과목, :Takes = 6.4 연관 클래스 수강하다, 장바구니 = 6.3 extend "쇼핑카트에 넣다"

6.5.4 사용사례 '제품을 구매하다'에 대한 시퀀스 다이어그램

• 6.5.3과 같은 패턴, 객체 이름만 다름: :ProductList → :OrdersSupply 조회 → :Cart → :Purchase
• 6.3.5 사용사례 명세 예제(PUR_101)와 같은 사용사례

6.5.5 사용사례 명세 방법

• 사용사례 명세의 Brief Processing Descriptions(알고리즘) 단계를 객체 간 메시지로 바꿔 그린 게 시퀀스 다이어그램 (슬라이드 없음, 양식은 6.3.5 그림)

6.6 메소드 알고리즘의 표현 방법

6.6.1 알고리즘 표현 방법

• 방법 4가지: 의사코드, 흐름도(flowchart), 자연어(영어·한국어), 일반 프로그래밍 언어

의사코드(pseudo code): 자연어와 프로그래밍 언어 구조를 섞어 쓴 "가짜 코드". 자연어보다 정확하고 간결하지만 표준은 없음 (예: IF 재고 > 0 THEN 판매 ELSE 품절 ENDIF)

6.6.2 요구사항분석 단계에서 알고리즘 명세

메소드 알고리즘 명세: 메소드마다 머리 주석 블록 + 본문 알고리즘을 붙이는 것 (예: insertionSort 머리 블록 + 삽입 정렬 코드)

• 머리 블록 항목: Method ID, Interface(함수 시그니처), Function(하는 일 한 줄), Parameter, Return value
• SRS 양식 9번 "클래스의 메소드 알고리즘 명세"에 이 형식으로 메소드마다 들어감

6.7 HW/SW/NW 외부 인터페이스 요구사항 명세

6.8 소프트웨어 요구사항명세서(SRS) 양식

• 전체 흐름: 개요 → 무엇을(기능·도메인) → 얼마나 잘(비기능) → 바깥과 어떻게(인터페이스) → 어떻게 만들지(기초설계) → 검토·결론. 15번은 4장 요구사항 분석, 69번은 6장 기초설계

SRS: 요구사항 분석 결과를 한 문서로 묶은 것. 개발팀과 고객이 "이걸 만든다"고 합의하는 기준

6.8.1 개요

• 1.1 개발 목표, 1.2 개발 범위 및 내용, 1.3 제품 가치, 1.4 대상 고객, 1.5 사용 시나리오, 1.6 업무분석표(WBS), 1.7 용어 정의

6.8.2 기능적 요구사항

• 2.1 사용사례 분석, 2.2 데이터 처리 흐름도, 2.3 시스템 작업 내용, 2.4 관리 기능, 2.5 트랜잭션 처리 작업, 2.6 모든 화면에 대해 수행되는 작업의 세부사항

6.8.3 도메인 요구사항

• 하위 항목 없음. 업무 분야 자체 규칙 (예: 학기당 최대 24학점)

6.8.4 비기능적 요구사항

• 15개: 성능, 신뢰성, 부하 및 스트레스, 보안, 운영(용량), 사용성, 호환성, 안정성 및 가용성, 확장성, 유지보수성, 설치, 복구, 법적 규정 및 환경, 위험 분석 및 제약, 문서 산출물

6.8.5 외부 인터페이스 요구사항

• 5.1 사용자 인터페이스 요구사항 및 GUI 명세(또는 설계), 5.2 하드웨어, 5.3 소프트웨어, 5.4 통신

6.8.6 소프트웨어 기초설계 내용

• 6 기능적 모델링: 사용사례 다이어그램, 사용사례 명세
• 7 구조적 모델링: 클래스 다이어그램, CRC 카드와 클래스 명세, DB 스키마 명세, Abstract·Interface 클래스 명세, 그 밖의 자료구조 명세
• 8 행위 모델링: 사용사례별 시퀀스 다이어그램, 액티비티 다이어그램(필수 아님)
• 9 클래스의 메소드 알고리즘 명세: 분량 제일 많음
• 10 요구사항 검토 결과 (기준은 6.9 평가지표), 11 결론, 부록, 참고문헌
• CRC 카드: Class·Responsibility·Collaborator. 클래스 하나를 카드 한 장에 이름·책임·협력 클래스로 적는 기법 (6장 본문엔 설명 없음)
• 6.5 제목은 "동적", SRS 양식에선 "행위" 모델링. 같은 것

6.9 소프트웨어 요구사항명세서 평가지표

SRS 평가지표: 요구사항명세서가 잘 쓰였는지 재는 기준. 슬라이드 기준 IEEE 830:2009 품질 모델, 6개

• 완전성 vs 정확성: 빠진 게 없나 vs 들어간 게 맞나
• 일관성 vs 검증 가능성: 요구사항끼리 충돌하나 vs 만든 뒤 확인할 수 있나
• SRS 10번 "요구사항 검토 결과"를 이 6개 기준으로 채움