보뇨 다이어리

소프트웨어 설계의 정석 본문

컴퓨터 관련/개발지식 정보

소프트웨어 설계의 정석

보뇨 2024. 11. 18. 10:28
반응형

Chapter 2 설계의 목적

개발프로세스 선택과 진행

  • 워터폴 개발
    • 오래된 개발 프로세스, 요구사항 정의 -> 설계 -> 구현 -> 테스트를 기본적으로 한번의 흐름으로 진행
    • 단점이 한단계가 종료되지않는이상 다음 단계로 넘어갈수없음
  • 점진적 개발
    • 한번의 흐름으로 개발하는것이 아니라 iteration 이나 spiral 사이클을 돌리면서 개발
    • 업무 흐름 분석 -> 유스케이스 추출 -> [이터레이션 계획 -> 유스케이스 분석 -> 설계 -> 개발] (설계) -> 통합 테스트 -> 릴리즈
    • 구체적인 특징은 아래와 같음
      • 중간 규모 개발
      • 릴리즈는 마지막에 1회
      • 이터레이션 1회는 4개월
      • 이터레이션은 3~4회
      • 팀원 대부분이 유스케이스 분석 및 개발 가능한 역량 보유
  • 애자일 개발
    • 점진적 개발과 마찬가지로 반복하며 개발진행하는데 사이클이 몇주정도로 매우 짧음
    • 사이클 단축하기위해 커뮤니케이션을 중시, 설계 비중을 크게 줄임
    • 애자일 개발의 대표적인 예로 eXtreme Programming XP, Scrum, Crystal Clear, Feature Driven Development 등이 있음

해당 책에서 전제로 하는 개발 프로세스는 점진적 개발인데 워터폴은 흔하고 애자일은 구체적인 개발 프로세스를 선택해야하기 때문

설계의 목적!

  • 요구사항 정의 내용을 시스템에서 어떻게 구현할것인지 검토
    • 다음 단계인 프로그래밍을 위해
    • 내부 설계
  • 요구사항 정의에서 드러나지 않은 시스템 기능 검토
    • 이전 요구사항의 정의의 연속성을 위해
    • 외부 설계
  • 프로젝트 이해관계자 간 정보 공유
    • 개발 프로젝트를 운영하기 위해
    • 프로젝트 관리
  • 시스템 품질 향상
    • 다음 단계인 프로그래밍을 위해
    • 아키텍처
  • 유지보수를 위해 설계 정보 기록
    • 개발후 유지보수를 위해
    • 설계서 작성

기능요건과 비기능요건을 구분하여 찾아야한다

  • 기능요건: 시스템 사용자에게 제공되는 구체적인 가치로, 시스템 사용자의 특정 목적을 달성하기위해 사용된다. 유스케이스에서 정의되는것이 바로 기능조건
  • 비기능요건: 시스템 사용자가 기능을 이용할때 부가적으로 필요한 시스템의 특성이나 성능을 말함

2.6 설계 접근법

저자가 스스로 정의한 종류임
외부설계 = 기본 설계, 기능 설계, 개요 설계
시스템이 제공해야하는 기능을 구체적으로 설계하는 작업
내부 설계 = 상세 설계, 프로그램 설계
구체적으로 데이터 처리 방법, 관리 방법, 트랜잭션 방법, 디비 설계 등

플로차트, DFD 등 그냥 가볍게 찾아봐

데이터 기능
시스템에 의해 업데이트되는지 여부에 따라 내부논리파일(Internal Logical File: ILF), 외부 연계 파일(External Interface File: EIF) 라고 부름
내부논리파일: 시스템에서 참조, 업데이트하는 데이터 가능
외부연계파일: 시스템에서 참조만 하는 데이터 기능 -> 시스템 외부에 있는 읽기 전용 데이터

Chapter 3 외부 설계 방법

시스템 기능을 명확히 하기 위한 주요 작업은 아래와 같음

작업 결과물
작업 결과물
유스케이스 분석 유스케이스 목록, 작성, 비즈니스 규칙, 규칙 목록
개념 모델링 개념모델, 용어집
비기능 요구사항 비기능 요구사항 정의서
화면 설계 UI설계정책, 화면 전환 다이어그램, 화면 목록 ,화면 목업, 화면 입력 검사 명세서
외부 시스템 I/F 설계 (인터페이스) 외부 시스템 I/F 설계서
커맨드/배치 설계 배치 설계서
장표 설계 장표 설계서

유스케이스 분석

사전 조건이나 사후 조건을 붙히는 경우가 좋을수가있음 (없는경우엔 빼도됨)

작업 결과물
작성자 아무개
작성일 2024년 10월 10일
유스케이스 이름 주문 배송하기
주요 액터 배송 담당자
사전 조건 주문이 이미 접수된 상태여야 한다
주요 시나리오 1. 배송 담당자가 주문 목록을 검색한다. 2. 시스템은 주문 날짜가 오래된 것부터 주문 목록을 표시한다. 3. 배송 담당자는 이전 주문의 세부 사항을 표신한다. 4. 시스템은 주문 세부 사항을 표시한다. 5. 배송 담당자는 주문한 상품의 배송을 지시한다. 6. 시스템은 배송센터에 상품 배송 지시를 통보한다.
확장 시나리오
성공시 보증

비즈니스 규칙

예를들어 상품 종류별로 배송 센터가 다른경우 비즈니스 규칙을 작성한다.

| :-: | :-: |
| 작성자 | 아무개 |
| 작성일 | 2024년 10월 10일 |
| 유스케이스 이름 | 주문 배송하기 |
| 주요 액터 | 배송 담당자 |
| 사전 조건 | 주문이 이미 접수된 상태여야 한다 |
| 주요 시나리오 | 1. 배송 담당자가 주문 목록을 검색한다. 2. 시스템은 주문 날짜가 오래된 것부터 주문 목록을 표시한다. 3. 배송 담당자는 이전 주문의 세부 사항을 표신한다. 4. 시스템은 주문 세부 사항을 표시한다. 5. 배송 담당자는 주문한 상품의 배송을 지시한다. 6. 시스템은 배송센터에 상품 배송 지시를 통보한다. |
| 확장 시나리오 | |
| 성공시 보증 | |
| 비즈니스 규칙 | 비즈니스 규칙: 상품 종류별 배송센터 |

유스케이스를 작성하면 시나리오가 복잡해지기 때문에 시스템개발하기 위한 필요한 정보를 이렇게 비즈니스 규칙으로 정리하여 작성

예시 1
| | |
| :----------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| 비즈니스 규칙 이름 | 상품 종류별 배송센터 |
| 내용 | 상품 종류에 따라 배송지시에 사용하는 배송센터가 다르다.
상품 종류 코드와 배송센터 코드의 대응은 다음과 같다.
가전제품(IT01) = 물류센터(DS01)
서적잡지(IT02) = 배송센터(DS02)
CD/DVD(IT03) = 물류센터(DS03) |

예시 2
| | |
| :----------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| 비즈니스 규칙 이름 | 로그인 ID 입력 규칙 |
| 내용 | 로그인 ID 는 반드시 고유해야 한다.
로그인 ID 는 사용자가 직접 입력한다.
로그인아이디는 변경 가능하다.
로그인 아이디에는 다음 문자만 사용할수있다. (숫자, 알파벳등)
로그인 아이디 입력에 3번 실패하면 계정을 잠근다. |

유스케이스 세분화 수준

유스케이스 작성시 어려운점은 아래와 같음

  • 유스케이스의 수준이 혼란스러워짐
  • 어디부터 어디까지 유스케이스로 기술해야할지 모름

유스케이스는 작성 목적에 따라 아래와 같이 구분됨
당연하게도 비즈니스가 더 포괄적이고 시스템은 세밀한 관점에서 작성한다.
해당 책에서 설명하고있는건 시스템 유스케이스.

  • 비즈니스 유스케이스
    • 기업 활동을 동작을 작성하는것이 목적
  • 시스템 유스케이스
    • 어떤 시스템의 동작을 작성하는것이 목적

유스케이스를 추출할때는 다음 관점에서 부족함이 없는지 파악
예를들어 '상품을 반품한다' 라는건 액터가 유스케이스에 참여하지않는경우라서 잊어지기 쉽다.

  • 특정 목적을 실현하기위한 유스케이스가 충분한지
  • 특정 액터의 생애주기에서 유스케이스가 충분한지
  • 모든 트리거에 대한 유스케이스 도출되어있는지
  • 관계자의 승인을 받았는지

개념 모델링

유스케이스가 시스템의 동적 행위를 나타내는것이라면 개념 모델은 시스템의 정적 구조를 나타냄
예를들어 유스케이스상에서 회원, 주문, 배송, 반품등의 다양한 개념이 등장하는데 이것들이 개념 모델링에 해당하여 밝혀내야한다.
int, String 과 같은 속성타입을 붙히지않고 클래스다이어그램으로 표현할경우 행위(메소드)는 작성하지않는다.

개념 모델로 표현하는건 기본적으로 3가지이다.

  1. 개념 이름 정리하기
  2. 개념의 연관성 정리하기
  3. 개념간 연관성의 다중성 정리하기

개념 모델 작성법

UML 을 통해 클래스 다이어그램을 작성해보면 대충 이런내용

@startuml
class 회원 {
    회원ID : String
    이름 : String
    이메일 : String
}

class 주문 {
    주문번호 : String
    주문날짜 : Date
    총가격 : BigDecimal
}

class 주문번호 {
    value : String
}

회원 "1" --> "0..*" 주문 : "1:*"
주문 --> 주문번호 : "1:1"
@enduml

트랜잭션 제어

READ_UNCOMMITTED 는 커밋되지않은 데이터를 읽을수있다.
여기서 문제점이 커밋되지않은 데이터를 참조할경우 더티 리드(Dirty Read) 가 발생할수있다고함.

READ_COMMITTED 커밋된 데이터를 읽을수있다 즉, 커밋되지않은 데이터는 읽을수없다

만약 A 트랜잭션이 데이터를 한번 참조하고나서 그중에 B 트랜잭션이 갱신했을때
A 트랜잭션이 다시 참조할때는 값이 변경되는데 이 이슈가 논 리피터블 리드(non-repeatable read) 문제다.
이것을 해결하기위해서는 REPEATABLE_READ 를 사용

반면에 A 트랜잭션이 데이터를 참조할려는데 없다가 그중에 B 트랜잭션이 추가할때
A 트랜잭션은 다시 참조해서 확인하니 있는경우가 있는데 이때가 팬텀 리드(Phantom read) 문제이다.

데이터베이스 잠금

예를들어 재고관련해서 기능을 만든다고할때 재고를 차감하는 업데이트 쿼리가 나가야하는데 트랜잭션 제어 SERIALIZABLE 로 해봤자 여전히 문제 발생
그럴때는 SELECT FOR UPDATE 쿼리를 사용

테스트에는 화이트박스 테스트와 블랙박스 테스트가 있음.
이것들에 대한 정의는 책에 나와있지만 너무 어려워서 따로 찾아서 정리하도록

아키텍처의 목적

아키텍처란

쉽게말하자면 컴포넌트가 연동하기 위해 필요한 설계 개념에 따른 시스템의 기본 구조
아키텍처 구성을 통해 얻을수있는 이점은 다음과 같다.
가장 중요한건 첫번째와 두번쨰이고 이외에는 부수적인것이다.

  • 유지보수성 향상
  • 적합성 향상
  • 견적에 활용
    • 프로젝트가 실패하는 요인으로는 초기 견적 설정에 허술함에 있음. 이때 견적의 정확도가 떨어지는 원인은 아래와 같음
      • 요구사항 정의 부족
      • 개발 지식 부족
      • 개발 실적 부족
      • 프로젝트 매니저의 경험 부족
      • 고객의 입력
      • 경영 측면에 입각한 발주처의 판단
  • 기술 리스크 최소화
  • 소스 코드 자동 생성에 적용
  • 프레임워크에 적용

정말 설계가 필요한가

설계의 목적은 다음과 같다

  • 요구사항 정의의 내용을 시스템에서 어떻게 구현할것인지 검토 및 기술한다.
  • 요구사항 정의에서 명확하지 않은 시스템 기능을 검토 및 기술한다.
  • 시스템 품질을 높인다.
  • 프로젝트 이해관계자끼리 정보를 공유한다.
  • 유지보수를 위해 기술한다.

설계가 필요없는이유

애자일의 등장

애자일은 다음 항목들을 존중한다고 명시하고있음

  • 프로세스나 도구보다 개인과의 상호작용
  • 포괄적인 문서보다 동작하는 소프트웨어
  • 계약 협상보다 사용자와의 협력
  • 계획을 따르기보다 변화에 대응
반응형