28 분 소요

1주차. 소프트웨어 공학과 개발 프로세스

1) 프로그램

프로그램은 어떤 일을 처리할 순서와 방법을 지시하는 명령어 들의 집합을 의미

소프트웨어

소프트웨어는 하드웨어의 동작을 지시하고 제어하는 역할을 수행 소프트웨어 = 프로그램 + 프로그램 관련 절차, 규칙, 문서

소프트웨어의 분류

  1. 시스템 소프트웨어: 운영체제처럼 컴퓨터 하드웨어를 관리하고 동작시키는 작업을 하는 소프트웨어를 의미
  2. 응용 소프트웨어: 하드웨어를 건드릴 수는 없고 운영체제 위에서 컴퓨터가 원하는 작업을 할 수 있게 만든 소프트웨어를 의미

시스템

공통의 목적이나 목표를 달성하기 위해 여러가지 상호 관련된 요소들을 유기적으로 결합한 것

소프트웨어의 특징 🔥

  • 비가시성: 소프트웨어 구조는 외관으로 나타나 있지 않고 코드로 구성. 추상적인 무형의 형태로 존재
  • 복잡성: 소프트웨어 개발과정은 매우 복잡하고 다양
  • 변경성: 소프트웨어에 있는 소스코드에 접근할 수 있다면 얼마든지 수정, 조작이 가능
  • 순응성: 기술의 발전, 사용자의 요구, 사회적 흐름의 변화에 맞추어 적절히 변형
  • 복제성: 적은 비용 또는 무상으로 간단하고 다양하게 복제가 가능
  • 동적행위성: 프로그램은 정적이지만, 소프트웨어는 행동에 기반한 동적성을 가짐
  • 비마모성(소모가 아닌 품질 저하): 하드웨어-오래 사용하면 부품이 닳고 기능도 떨어짐 / 소프트웨어-닳지 않으며 시간이 지나도 고장 빈도가 높지 않다. 사용 시작 단계부터 사용자의 요구가 계속 발생

2) 소프트웨어 공학의 등장 배경 및 목표 🔥

1) 소프트웨어 위기 도래: 규모의 거대화, 복잡성 증가, 유지보수 소요 증가 2) 소프트웨어 위기의 극복을 위해 소프트웨어 공학 등장 3) 소프트웨어 공학에서 다루는 분야: 프로세스, 방법론, 도구 등 1) 목표: 품질, 비용, 일정, 생산성

소프트웨어 공학의 학문적 정의

  • 품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획,개발,유지 및 관리 하는 전 과정에서 공학,과학 및 수학적 원리와 방법을 적용해 필요한 이론과 기술 및 도구들에 관래 연구하는 학문

3) 소프트웨어 개발 생명주기 🔥

소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계에 이르기까지 일어나는 일련의 과정

  • 계획, 분석, 설계, 구현, 테스트, 유지보수 - 계분설구테유

요구 사항 분석 프로세스 🔥

1) 요구 분석 - 요구조건명세서 작성 2) 개념적 설계 - DBMS에 독립적 개념 스키마 설계도, 트랜잭션 모델링 (DBMS 선정) 3) 논리적 설계 - DBMS에 맞는 스키마 설계, 트랜잭션 인터페이스 설계 (정규화) 4) 물리적 설계 - DBMS에 맞는 물리적 구조 설계, 트랜잭션 세부 설계 5) 구현 - 특정 DBMS의 DDL로 DB생성, 트랜잭션 생성

4) 소프트웨어 개발 프로세스(폭포수,…)

폭포수 모델(선형 순차적 모델)

  • 다음단계로 넘어가는 모델 (고전적 생명주기)
  • 초기에 개발된 전통적인 모델
  • 표준 프로세스를 정해 소프트웨어를 순차적으로 개발

폭포수 모델의 개발 절차

  • 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식으로 진행
  • 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후 다음 단계로 나아감
  • 요구사항 분석 단계가 끝나면 ‘요구분석명세서’ 문서 작성
  • 명세서를 기준으로 사용자에게 이상 유무를 확인. 다음 설계 절차로 넘어감

진화적 프로세스 모델

  • 새로운 요구가 수시로 발생. 민첩하게 대응할 수 있는 방법
  • 초기의 사용자 요구에 따라 가상으로 초기 버전의 프로토타입을 작성
  • 사용자는 사용자 인터페이스 중심의 화면과 실행 후 나타나는 가상의 결과 화면 확인
  • 변경된 요구사항을 반영하거나 추가해 2차 프로토타입을 제작 후 사용자에게 보여줌
  • 모든 과정 반복. 20240313133044

프로토타입 모델

  • 대량 생선에 앞서 미리 제작해보는 원형 또는 시제품
  • 완전한 소프트웨어를 만들기 전에 사용자의 요구대로 일단 모형을 만들고 사용자와 의사 소통하는 도구로 활용
  • 예) 아파트 모델하우스

    프로토타이핑, 1차 프로토타입(입출력화면), 2차 프로토타입(요구사항 변화)

통합 프로세스 모델 🔥

반복적 개발 방법론 등장(폭포수 모델의 문제를 해결하기 위한 모델) 폭포수모델의 문제점: 각 단계별로 깔끔하게 정리 되어 있지만 사용자의 요구사항이 많으면 민첩하게 대처할 수 없다. R(요구사항 정의)->A(분석)->D(설계)->C(구현)->T(테스트)->M(유지보수) => R1->R2->,,,

  • 개발 프로세스에서 계획 대신 요구사항 정의가 들어감

    통합 프로세스 모델의 절차

  • 개발과정은 4단계 (도입, 구체화, 구축, 전이)
  • 각 단계도 여러 개의 작은 단위(반복)으로 나뉘어 각 반복 구간 하나씩
  • 반복 주기 시작전 기준선(베이스라인) 계획 설립
  • 반복 주기가 끝나면 실행 가능한 산출물 도출
  • 반복 구간 하나가 수행될 때 9개 개발 영역이 대부분 수행

통합 프로세스 모델의 개발 순서

  • 관리 가능한 소규모 단위
  • 수행될 작은 단위의 계획
  • 각 반복에서 작은 부분을 통합, 테스트, 실행

1) 도입 단계 1) 준비 단계, 인지 단계, 시작 단계, 발견 단계, 개념 정립의 단계 2) '비즈니스 모델링'과 '요구사항 정의' 관련 직업 2) 구체화 단계 1) 상세 단계, 정련 단계(2~4개의 반복 단위 구성) 2) 분석 및 설계 작업이 크게 이루어짐 3) 실행 결과에 따른 구현(코딩) 작업, 구현에 대한 단위 테스트 조금씩 시작 3) 구축 단계 1) 구현 작업 가장 많이 이루어짐 4) 전이 단계 1) 이행 단계; 사용자를 위한 제품을 완성 2) 완성된 제품을 사용자에게 넘겨주는 과정 수행 작업 20240313140611

5) 애자일 프로세스 모델과 폭포수 모델의 비교 🔥

구분 애자일 프로세스 모델 폭포수 모델
추가 요구사항의 수용 추가 요구사항을 수용할 수 있는 방법으로 설계 요구사항 분석이 완전히 완료된 후에 설계 단계로 넘어가므로 추가 요구사항을 반영하기 어려운 구조
릴리스 시점 가능하면 자주, 빨리 제품에 대한 프로토타입을 만들어 사용자에게 보여준다. 자주 릴리스 요구사항에 대한 과정이 끝나고 최종 완성된 제품을 릴리스
시작 상태 계속적인 추가 요구사항을 전제로 하는 방식, 점차 완성도가 높아짐 시작 단계의 완성도가 매우 높다.
고객과의 의사소통 사용자와 많은 대화를 하면서 개발을 진행 사용자에게 더는 추가 요구가 없다는 확답을 받고 개발, 사용자와의 대화는 적다.
진행 상황 점검 개발자와 사용자는 지속적으로 진행 상황을 공유 단계별 산출물에 대한 결과로 개발의 진척 상황을 점검
분석, 설계, 구현 진행 과정 분석, 설계, 구현이 한꺼번에 진행. 다만 어떤 단계에서는 분석이 적고 구현이 많다는 차이 분석, 설계, 구현 과정이 명확. 단계가 명확히 구별되어 있다.
모듈(컴포넌트) 통합 개발 초기부터 빈번한 통합을 통해 문제점을 빨리 발견하고 수정하는 방식. 비용을 절감할 수 있다는 장점 V 모델에서 설명한 것처럼 구현이 완료된 후에 모듈 간의 통합 작업을 수행

2주차. UML

1) UML의 역할 🔥(키워드 중요)

  • 소프트웨어의 전체를 판단할 수 있는 12개의 다이어그램 제시
  • 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트 간의 관계 등을 시각적으로 나타낸 도면
    • 구조 다이어그램 / 행위 다이어그램 / 상호작용 다이어그램 20240416161157

2) 유스케이스 다이어그램

보조자료 중점 글→다이어그램 or 다이어그램을 보고 설명.

액터의 종류

사용자 액터

  • 사용자 액터는 사람의 역할 의미
  • 액터와 유스케이스 관계는 화살표(→) 표현(액터→유스케이스)

    시스템 액터

  • 데이터를 주고받는 등 서로 연동 되는 또 다른 시스템
  • 유스케이스가 시스템 액터를 사용(참조)하는 것 (유스케이스→시스탬 액터)

    주요 액터 (능동적)

  • 시스템에게 작업의 실행을 요구하는 능동적 입장 액터
  • 대부분 액터 해당

    보조 액터 (수동적)

  • 유스케이스로 부터 요청을 받거나 메시지를 전달 받아 수동적 작업 액터

    프록시 액터

  • 액터와 시스템의 중간 위에서 무언가 대신해주는 액터
  • 시스템 등록 가능 접근 권한 부여된 경우

유스케이스

  • 사용자가 시스템을 통해서 사용하고 싶은 기능
  • 유스케이스 → 서브시스템 → 개발시스템
  • 전체시스템: 유스케이스를 모아 놓은 것

유스케이스→시스템 액터 관계

액터의 일반화 관계 일반화: 개별적인 것에서 공통적인 특징을 뽑아 이름을 붙인 것(반대: 특수화) 20240416163126

  • 일반화 개념은 액터 사이에 먼저 적용할 수 있음 20240416163150
  • 간결하게 일반화해 복잡함을 줄이면 이해하기가 쉽고 새로운 액터도 간단하게 추가할 수 있음 20240416163210

무인 도서 대출 반납 시스템 예제 🔥

그려보고 풀어보기

유스케이스 다이어그램은 유스케이스, 액터, 시스템, 시나리오, 이벤트 흐름 등의 구성요소

20240423141646

20240423141732 20240423141905

유스케이스 다이어그램 예제

20240423142035

예제 문제 도출

20240423142240 20240423142314

  • 유스케이스 다이어그램 ppt 참고

3) 클래스 다이어그램

  • 소프트웨어의 기본 구성 단위인 시스템에서 사용하는 클래스를 정의
  • 클래스들이 서로 어떻게 연결되어 있고 어떤 역할을 하는지 다이어그램으로 표현

클래스

  • 데이터(속성)와 메서드를 묶어 놓은 것
  • 세 칸의 직사각형 모양
  • 첫 번째 칸에는 클래스 이름
  • 두 번째 칸에는 클래스의 속성
  • 마지막 칸은 클래스가 제공하는 기능인 메서드 20240416163816

클래스 이름*

  • 클래스는 다른 클래스와 구별되는 유일한 이름을 가짐
  • 이름에 명사나 명사구를 사용하며 두 단어를 사용할 때는 붙여쓰되 각 단어의 첫 글자는 대문자로 씀
  • 복수형, 소유격, 형용사는 가급적 쓰지 않음

    속성*

  • 클래스가 갖는 정적인 특성
  • 속성의 이름은 소문자로 나타내며 두 단어를 사용할 때는 두 번째 단어의 첫 글자는 대문자로 씀

    메서드*

  • 클래스가 외부의 다른 객체에게 제공할 서비스와 기능
  • 외부 클래스는 메서드를 통해 해당 클래스에 접근할 수 있음
  • 외부에서 이 기능을 요구하는지에 따라 메서드로 도출할지 판단

    가시성 🔥

  • 속성과 메서드의 접근 권한을 지정하는 방식
  • public(공개)과 private(은닉)의 명확한 구분!
가시성 설명
공개(public, +) 같은 시스템에 있는 모든 클래스에 접근할 수 있다.
은닉(private, -) 같은 시스템 내의 다른 클래스는 직접 접근할 수 없고 해당 클래스의 메서드를 통해서만 접근할 수 있다. 클래스에서 대부분의 속성은 private으로 설정한다.
부분 공개(protected, #) 다른 클래스가 접근할 수 없고 해당 클래스의 메서드와 클래스를 상속받은 하위 클래스만 접근할 수 있다.

클래스 다이어그램의 예

20240416164801

  • 학생은 여러 과목을 수강할 수 있음
  • 학생은 하나의 학교에 소속되어 있음
  • 교수는 하나의 학교에 소속되어 있음
  • 교수 한 명은 여러 과목을 강의
  • 교수 한 명은 여러 명의 학생을 상담

4) 활동 다이어그램

활동 다이어그램

  • 흐름도와 비슷하나 객체의 행위를 나타낸다는 점에서 다름
  • 상위 수준에서는 업무의 흐름을 표현하고 분석 단계에서는 유스케이스의 구체적인 흐름(이벤트 흐름)을 나타냄
  • 설계 단계에서는 클래스 내부 동작에 대한 알고리즘이나 구체적인 로직을 표현

활동 다이어그램의 구성요소

시작/종료 상태, 활동

  • 시작/종료 상태, 활동
  • 시작점: 활동의 시작을 나타내며 속이 채워진 원으로 표기
  • 종료점: 활동의 종료를 나타내며 이중 원으로 표기
  • 활동: 일의 처리와 실행을 나타내며 모서리가 둥근 사각형으로 표기
  • 전이: 활동 간의 이동을 나타내며 화살표로 표기

20240416215348

분기와 병합

  • 분기 : 조건에 의해 두 가지 경로로 나뉘는 위치이며 마름모를 사용 / 조건문은 마름모 옆에 « » 기호로 작성
  • 병합 : 분기되어 각 활동을 수행하다가 합쳐지는 위치를 나타내며 분기와 같이 마름모를 사용 / 생략이 가능

. image 20240416220413

활동 다이어그램

활동 다이어그램의 구성요소

  • 동기화 막대
    • 여러 활동을 병행할 때 사용하는 것으로 동시 처리의 시작과 끝을 나타냄

. image 20240416220745

신호 🔥

  • 활동 사이의 거래는 제어 신호를 보내는 방식으로 이루어짐

. image 20240416220913

구획면 🔥

  • 수영장의 레인을 의미하는데 수영 선수가 자신의 레인을 넘어가면 안 되는 것처럼 해당 레인을 책임지는 객체가 있음

5) 컴포넌트 다이어그램 🔥

컴포넌트 다이어그램 🔥

  • 구현 관점에서 정적 모델링을 할 때 사용하는 것
  • 어떤 실행 모듈이 존재하고 이들이 서로 어떤 연관성이 있는지의 종속 관계를 나타냄
  • 사용자에게 논리적 또는 물리적 시스템의 구조를 볼 수 있게 해줌

컴포넌트 다이어그램의 구성요소 🔥

컴포넌트

  • 컴포넌트는 시스템을 구성하는 물리적인 요소로 프로그램 코드를 포함
    • <<executable>> : 실행 파일(.exe)
    • <<library>> : DLL 같은 정적 또는 동적 객체 라이브러리
    • <<table>> : 데이터베이스 테이블
    • <<file>> : 원시 코드를 포함하는 파일

인터페이스

  • 클래스 모양으로 나타내거나 아이콘을 사용해 간략하게 표현할 수 있음

. image 20240416221725

의존 관계

  • 서로 영향을 주고받는 관계를 말함
  • 컴포넌트 간 연결은 점선 화살표로 나타내며 의존하는 쪽으로 화살표가 연결

. image 20240416221755

컴포넌트 다이어그램의 작성 과정

컴포넌트 대상 정의

  • 무엇을 컴포넌트로 할지 정함

    컴포넌트 찾기

  • 컴포넌트 다이어그램에 포함할 컴포넌트를 식별

    컴포넌트 배치

  • 컴포넌트 다이어그램에 컴포넌트를 배치하고 이름을 붙여줌
  • 필요하다면 인터페이스를 정의하고 컴포넌트와 실현 관계로 연결

    의존 관계 정의

  • 컴포넌트 간 의존 관계를 정의
  • 각 컴포넌트의 인터페이스를 원으로 표시하고 인터페이스에 대한 실현은 컴포넌트와 연결

. image 20240416221955

3주차. 계획

1) 비용 산정 기법2: 상향식 산정 기법 🔥

원시 코드 라인 수 기법

  • 소프트웨어 각 기능의 원시 코드 라인 수 LOC의 비관치, 낙관치, 중간치를 측정해서 예측치를 구하고 이를 이용해 노력, 개발 비용, 개발 기간, 생산성 등의 비용을 산정하는 기법
> 노력(인/월수^M/M) = (참여 인원/월) X 개발 기간 = 추정 LOC/1 인당 월평균 생산 코드 라인 수
> 개발 비용 = (M/M) X 단위 비용(1인당 월평균 인건비)
> 개발 기간 = (M/M) / 참여 인원
> 생산성 = LOC / (M/M)

예제 🔥

  1. 소프트웨어 개발 기간은 1년(12개월)이다. 5명의 개발자가 12개월 동안, 7명의 개발자가 5개월 동안 참여한다면 이 소프트웨어 개발의 노력M/M이 얼마인가?
    1. 풀이: (5명x12개월) + (7명x5개월) = 60M/M + 35M/M = 95M/M
  2. LOC 기법에 의해 예측한 총 라인이 50,000라인이고, 개발자가 10명 참여한다. 그리고 개발자들이 월평균 500라인을 코딩한다면 개발 기간은 얼마나 되는가?
    1. 노력^M/M = 원시 코드 라인 수 / (1인당 월평균 생산 코드 라인 수) = 50,000 라인 / 500라인 = 100M/M
    2. 개발 기간 = (M/M)/참여 인원 = 100(M/M)/10명 = 10개월

COCOMO 방법

고려사항

프로그램 유형에 따른 가중치 두기, 개발하려는 소프트웨어를 4가지 특성에 따라 15가지 분류 후 인건비 더 보정

가중치 반영하기

단순형 프로젝트
  • 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어가 이에 해당
  • 중소 규모 정도이고, 크기는 50KDSI 이하
    중간형 프로젝트
  • 일반 업무용 소프트웨어보다 복잡하고 규모가 더 큰 운영체제, 데이터베이스 관리 프로그램 등이 이에 해당
  • 규모나 복잡도가 중간 정도이고, 크기는 300KDSI 이하
    내장형(임베디드형) 프로젝트
  • 자동화 기기나 전자 제품과 같은 하드웨어와 밀접하게 관련 있는 내장형 소프트웨어가 이에 해당
  • 크기는 300KDSI 이상

2) COCOMO 방법

개발 인건비 초기 예측

  • COCOMO 방법에서 제시하는 공식을 사용하면 개발 인건비의 초기 예측 값을 계산
  • 규모가 같은 소프트웨어일 경우 기본형보다는 중간형에서, 중간형보다는 내장형에서 M/M이 더 많이 필요 . image 20240318141007

보정 계수 반영하기

EAF: Effort Adjustment Factor

  • 노력 조정 수치(EAF): 보정에 사용하는 값, 필요한 각 항목별 승수 값을 모두 곱한 값
  • 15개의 세부 항목에 따른 보정 값을 모두 정해놓음

. image 20240318141136

개발하려는 소프트웨어에 요구되는 신뢰도가 높고(1.15), 매우 복잡하며(1.30), 소프트웨어 공학 기술을 거의 사용하지 않고(1.24), 요구되는 개발 일정이 매우 촉박하고(1.10), 다른 요소들은 보통(1.00)일 경우 노력 조정 수치는 다음과 같다.

노력 조정 수치(EAF) =

1.15×1.30×1.24×1.10 = 2.04

노력 P/M

만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치(EAF)가 앞서 계산한 것처럼 2.04라면 노력(E: effort=P/M)은 다음과 같다.

PM = 3.0×(KDSI)1.12×EAF=3.0×(60)1.12×2.04 = 600.179

노력 조정수치가 반영된 노력 P/M을 구하는 공식

. image 20240318141449

총 개발 기간 산정하기

  • 보엠이 제시하는 총 개발 기간을 계산할 때는 개발할 소프트웨어 유형에 상관없이 모두 동일한 상수(2.5) 값을 곱함
  • 개발 기간은 소프트웨어 유형과 상관없음 . image 20240318141518 TDEV : Total DEVelpment time

앞서 사용한 예를 이용해 총 개발 기간을 구하면 다음과 같다. TDEV = 2.5×(PM)0.35 = 2.5×(600.179)0.35 = 23.461

3) COCOMO II 방법

애플리케이션 합성 모델

  • 1단계에서는 입출력 화면 중심의 사용자 인터페이스 개수 등을 계산해 다음의 객체 점수를 산출 
  • 개발 범위에 속한 객체(입출력 화면 등)를 찾음
  • 객체가 제공하는 기능의 복잡도를 3가지(단순형, 보통형, 복잡형)로 분류
  • 객체의 개수에 가중치(단순형, 보통형, 복잡형)를 부여해 결괏값을 산출

초기 설계 모델

  • 2단계는 초기 설계 단계에서 예측값을 구함
  • 초기 설계 단계쯤 되면 1단계보다는 시스템의 구조와 기능을 좀 더 상세히 알 수 있어 1단계보다 더욱 정확한 예측이 가능

구조 설계 이후 모델

  • 3단계에서는 이미 기능 점수가 나왔기 때문에 노력을 추정하는게 어렵지 않음
  • 기능 점수를 바탕으로 한 LOC를 추정해 소프트웨어 규모를 산정

애플리케이션 합성 모델 단계에서의 M/M 계산 샘플

. image 20240318141749

4) 기능 점수 산정 방법

기능 점수 산정 방법

기능 점수 산정 방법의 구분

  • 기능 점수의 기준이 되는 소프트웨어 기능은 크게 데이터 기능과 트랜잭션으로 구분 . image 20240320133924

  • SW사업 대가산정 가이드에서 제시하는 기능 점수 산정 방법 구분 . image 20240320133928

기능 점수 산정 방법

기능 점수 산정 방법의 장점

  • 사용자의 요구사항만으로 기능을 추출해 측정
  • 객관적인 요구사항만으로 측정
  • 모든 개발 단계에서 사용

기능 점수 산정 방법의 단점

  • 높은 분석 능력 필요
  • 기능 점수 전문가 필요
  • 내부 로직 위주의 소프트웨어에는 다소 부적합
  • 개발 공수보다 개발 규모 측정에 적합

데이터 기능 점수 계산

  • 이번 프로젝트에서 생성해 관리하는 데이터는 내부 논리 파일(ILF)

  • 이번 프로젝트에서 만들지 않고 다른 프로젝트에서 생성했으나 이번 프로젝트에서 참조하는 데이터는 외부 연계 파일(EIF) . image 20240320141304

  • 데이터 기능 점수는 내부 논리 파일의 개수와 외부 연계 파일의 개수에 각각의 평균 복잡도(가중치)를 곱해 계산

20240320141319

트랜잭션 기능 점수 계산 🔥

  • 기능 점수에서 트랜잭션 기능의 복잡도는 입력, 출력, 조회의 개수로 결정 20240320141456

외부 입력(EI)

  • 데이터베이스에 데이터를 등록하거나 수정·삭제하는 것(학생정보 등록, 수정, 삭제)

    외부 출력(EO)

  • 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능(학생 학점 조회)

    외부 조회(EQ)

  • 로직이 필요 없고 데이터베이스에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능(학생 주소 검색, 학생정보 조회) 20240320141540

미조정 기능 점수 계산(UFP)

  • 앞에서 구한 데이터 기능 점수와 트랜잭션 기능 점수를 합한 값
  • 단순히 기능적인 요구사항에 대해서만 계산했지, 여러 가지 특성에 대한 고려를 하지 않음 20240320141743

5) 일정계획(WBS), 네트워크/간트 차트

네트워크 차트(PERT/CPM) 🔥

네트워크 차트의 개요

  • WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 일의 중요도와 일정 관리를 명확히 하는 데 사용
  • 전체 작업 일정을 세분화해 지연을 사전에 예방할 수 있고, 개발 기간 단축에 활용해 일정을 효율적으로 관리할 수 있음
  • 유사성과 상호 장단점 때문에 PERT/CPM이라 해 두 기법을 혼합한 방법을 사용하기도 함

PERT (Program Evaluation and Review Technique) 🔥

  • 프로그램을 평가하고 검토하는 프로젝트 관리 기법
  • 프로젝트 진행 상황을 통계적인 방법으로 파악하고 이를 통해 일정 계획 및 통제를 할 수 있도록 고안

CPM (Critical Path Method) 🔥

  • 미 듀퐁사에서 화학 처리 공장의 건설 계획을 조직적으로 추진하기 위해 개발
  • 건설 공사와 같이 단위 작업이 확정적 소요 시간을 갖는 프로젝트인 경우에 적합

CPM 작업 과정

  • CPM으로 네트워크를 그리려면 학사관리 애플리케이션을 수행하는 데 필요한 작업, 선행 작업, 작업의 소요 기간이 필요

CPM 작업 과정 🔥

① CPM 네트워크를 그림

  • 노드와 간선을 이용해 초기의 CPM 네트워크를 그림
  • 노드는 작업을, 간선은 작업들 간의 선후 의존 관계를 나타냄

20240326164214

② ES값을 구함

  • ES: 가능한 빨리 시작할 수 있는 시간으로, 선행 작업이 완료되었을 때 해당 작업을 시작할 수 있는 가장 빠른 시점
  • ES 값을 구할 때는 맨 앞(작업 A)에서 끝 방향으로 가며 계산
  • ES에서 주의할 부분은 두 작업이 합류하는 지점의 작업 시작 시간은 두 작업이 모두 완전히 끝났을 때

20240326164328

③ EF값을 구함

  • EF: 가장 빠른 시작 시간(ES)으로 시작했을 때의 가장 빠른 완료 시간 (작업 시작 시간+작업 시간)

20240326164405

④ LS값을 구함

  • LS: 어떤 작업을 늦어도 시작해야 하는 시간, 즉 가장 늦게 시작할 수 있는 시간
  • 맨 뒤(작업 M)에서 앞(작업 A) 방향으로 계산
  • 두 지점으로 갈라지는 곳에서는 다음 작업의 시작 시간에 영향을 주지 않고 시작할 수 있는 시간을 찾아 기입

⑤ LF값을 구함

  • LF: 가장 늦게 시작할 수 있는 시간(LF)에 시작해 작업을 완료한 시간(LS+작업 소요 시간)

⑥ ST값을 구함

  • ST: 여유 시간, 각 작업에서 ‘가장 늦게 시작하는 시간’에서 ‘가장 빨리 시작하는 시간’을 빼면 구할 수 있음
  • 전체 작업 시간을 줄이고 싶을 때는 여유 시간이 존재하는 작업의 시간을 줄이면 됨

20240326164548

⑦ 임계 경로를 구함

  • 임계 경로: 여유 시간이 없는 경로(예시에서는 경로 ‘A-B-D-E-H-K-L-M’가 임계 경로)
  • 임계 경로에는 여유 시간이 없으므로 모든 일정 계획은 임계 경로에 좌우됨
  • 임계 경로에서 벗어난 활동을 수행하는 데 걸리는 시간이 한도 내에서 늦춰지거나 당겨 질 경우에는 전체 프로젝트 완료 시간에 변화가 없음

20240326164627

6) 일정 계획 기법 2: 간트 차트를 이용한 일정표 작성

간트 차트 🔥

  • 프로젝트 일정 관리를 위한 바 형태의 도구
  • 프로젝트의 주요 활동을 파악한 후, 각 활동의 일정을 시작하는 시점과 끝나는 시점을 연결한 막대 모양으로 표시
  • 전체 일정을 한눈에 볼 수 있음

20240326164712

4주차. 요구분석

1) 요구분석의 정의와 목적 🔥

시스템제공: 기능요구 품질: 비기능 요구

요구분석의 정의 🔥

  • 컴퓨터 용어사전: 시스템이나 소프트웨어의 요구사항을 정의하기 위해 사용자 요구사항을 조사하고 확인하는 과정
  • 요구분석은 소프트웨어 개발 성패의 열쇠

요구분석의 목적 🔥

  • 목적사용자에게서 필요한 요구사항을 추출해 목표하는 시스템의 모델을 만들고 요구분석명세서를 작성하기 위해서

    요구분석명세서

  • 요구분석 단계에서 생성 되는 최종 산출물로 시스템의 기능이 무엇인지(what)에만 초점을 두고 정리
  • 요구분석단계 후 설계 단계에서는 설계서가 만들어지는데 이 문서는 어떻게(how) 구현할지 기술

요구사항 수집

자료 수집

  • 가장 먼저 할 일은 A대학교의 현행 시스템에서 모든 업무의 입력 화면과 출력물을 받아 기본 기능을 분석하는 것
  • 관련 직원으로부터 현행 시스템의 문제점과 개선점, 새로 추가되어야 할 요구사항을 파악

인터뷰

  • 가능하면 먼저 자료를 수집한 후 이를 정리해 분석한 결과를 바 탕으로 각 부서 담당자를 인터뷰하는 것이 효율적
  • 미리 받은 자료를 토대로 대화를 해야 큰 줄기를 흩트리지 않고 계획대로 진행할 수 있음
  • 오랜 시간 동안 대화하기보다는 핵심 요구사항을 빨리 습득하는 것도 능력

설문 조사

  • 설문 조사를 통해 또 한 번의 요구사항을 도출할 수 있음
  • 중요한 것은 효율적인 설문 조사를 위해 설문 문항을 잘 만들어야 한다는 것

2) 요구분석 절차와 요구사항 분류 🔥

요구 분석 절차 🔥 - 자요문검

20240328094407

❶ 자료 수집   현행 시스템의 문제점 도출, 실무 담당자 인터뷰, 현재 사용하는 문서 검토 등을 통해 가능한 모든 자료를 수집

❷ 요구사항 도출   수집한 자료를 정리해 적절히 분류하고 개발에 반영할 요구사항을 도출

❸ 문서화   도출한 요구사항을 요구분석명세서로 작성

❹ 검증   요구분석명세서에 사용자 요구가 정확히 기록되어 서로 모순되는 사항은 없는지, 빠뜨리지 않고 전부 기록했는지 등을 점검

요구 분석 분류 🔥

  • 사용자 요구사항은 개발될 소프트웨어가 제공할 기능 요구사항과 성능, 제약 사항, 품질과 같은 비기능 요구사항으로 분류

20240328094458

기능 요구사항

  • 사용자가 원하는 기능
  • 완전성(사용자가 원하는 모든 기능 포함) / 일관성(요구사항 간 모순 X)

비기능 요구사항 🔥

기능

  • 수행 가능한 환경, 품질, 제약 사항 등
    신뢰성: 소프트웨어를 믿고 사용할 수 있는 것
    • 고장 회피 능력, 성능 회복, 정상 복구
      가용성 🔥
  • 소프트웨어가 총 운용 시간 동안 얼마나 정상적으로 고장 없이 가동되었는지를 비율로 나타냄

20240328104722 가용성 계산식: 가용성(%) = (MTBF/(MTBF+MTTR))X100(%)

MTBF(평균 정상 작동 시간 또는 고장 간 평균 시간)
  • 고장이 나서 수리 후 정상 작동 하다가 다시 고장이 날 때까지 작동한 시간
  • 정상 작동 시간의 합을 횟수로 나눈 값
  • MTBF와 비교되는 개념으로 고장까지의 평균 시간 (고장은 수리가 불가능한 상황에 해당)
    MTTR(평균 수리 시간)
  • 수리 시간의 합을 횟수로 나눈 값
  • 수리 시간: 고장 시점에서 수리가 완료되어 재가동되는 시점까지의 시간

3) 요구사항의 표현

모델링

UML 다이어그램을 사용한 표현 🔥

  • UML 다이어그램을 사용하면 개발할 소프트웨어를 가시적으로 볼 수 있고, 개발할 소프트웨어에 대한 문서화도 가능. 이 문서들은 분석 및 설계 과정에서 유용하며 검증 자료로도 활용

[3단계] 유스케이스 정렬

20240328115110

유스케이스 명세서 작성하기

  • 유스케이스 다이어그램을 작성하면 각각의 유스케이스에 대한 명세서를 작성해야 함
  • 유스케이스 명세서는 7개 항목으로 구성되며 각 유스케이스의 자세한 내용을 기술하는 문서

20240328115142

개요

  • 유스케이스가 제공하는 기능을 나타내는 것으로, 그 기능을 사용하는 사용자 액터까지 표현해야 함
유스케이스 개요
수강신청 학생은 시스템이 제공하는 개설과목 목록에서 수강할 과목을 선택한다. ‘과목삭제’와 ‘과목추가’ 기능이 포함되어 있다.
  • 개요는 유스케이스에 포함된 모든 기능을 액터까지 포함해서 표현해야 함
유스케이스 개요  
성적등록 교수는 학생의 성적을 입력한다 X
성적등록 성적을 입력하고 수정한다 X
성적등록 교수는 학생의 성적을 입력하고 수정한다 O
  • 유스케이스의 기능은 이벤트 흐름에서 별도로 자세히 표현하기 때문에 개요에서는 간략하게 나타냄

관련 액터

  • 유스케이스를 사용하는 액터를 나타냄
  • 관련 액터 항목에 나타낸 액터와 유스케이스 다이어그 램에서 연관 관계를 맺고 있는 액터는 일치해야 함

| 유스케이스 | 관련 액터 | | :—- | :—- | | 수강신청 | 학생 |

우선순위

  • 개발할 때의 순서를 나타낸 것
  • 기준을 정하고 그에 따른 개발 순서를 정한다면 프로젝트 관리 측면에서 도움이 됨
  • 우선순위는 사용자 관점에서 정할 수도 있고, 개발자 관점에서 정할 수도 있음
  • 중요도로 정하는 사용자 관점 우선순위: 일정 조절, 자원 배분, 인력 투입 등에서 균형 있게 프로젝트 관리를 할 수 있음
  • 개발 난이도로 정하는 개발자 관점 우선순위: 개발 난이도를 기준으로 ‘상’, ‘중’, ‘하’를 결정

선행 조건

  • 해당 유스케이스를 수행하기 위해 미리 만족해야 하는 상태나 조건
  • 해당 유스케이스를 수행하기 위한 직전의 선행 조건 유스케이스를 기입
유스케이스 선행 조건
수강신청 개설과목등록

후행 조건

  • 유스케이스 수행 후 만족해야 하는 상태
  • 상태나 수치의 바뀐 모습을 명확하고 구체적으로 작성
  • 모호하게 기술하지 않고 객관적으로 판단할 수 있게 작성
유스케이스 후행 조건
수강신청 수강신청을 한 총 학점이 표시되어야 한다

잘 만든 요구분석명세서의 특징 🔥 (키워드 중요)

1. 완전성

  • ‘완전하다’라는 말은 빠진 부분 없이 모두 있다는 의미
  • 요구분석명세서는 기능 요구사항 뿐 아니라 성능, 제약 사항 등의 비기능 요구사항이 빠지지 않고 모두 서술되어야 완전
  • 요구사항 정의 및 분석 과정에서 아주 드물게 발생할 수 있는 것까지도 찾아내 반영해야 완전성을 충족하는 요구분석명세서

    2. 일관성

  • 상반된 요구뿐 아니라 불일치하거나 중복된 요구가 존재하면 일관성이 없는 요구분석명세서
  • 예) 아무나 접근할 수 없게 보안을 매우 철저히 해주고 사용자들이 인증 절차를 번거롭지 않고 단순하게 사용할 수 있음

    3. 명확성

  • 요구분석명세서도 계약서와 같은 역할을 수행하므로 요구사항, 비용, 기간 등에서 문제가 발생하면 근거가 됨
  • 요구사항을 잘못 해석해 의도하지 않은 결과를 초래할 수 있으므로 누구나 같은 해석을 하도록 표현을 명확히 해야 함

4. 기능성

유스케이스 비기능 요구사항  
도서 검색 3초 이내에 결과가 나타나야 한다 X
도서 검색 1백만 권까지 3초 이내에 결과가 나타나야 한다 O
수강 신청 전교생이 동시에 접속해도 문제가 없어야 한다 X
수강 신청 수강신청 시 2,000명까지 동시 접속해도 1기가바이트 이상의 속도가 유지되어야 하고, 시스템이 멈추지 않아야 한다 O

5. 추적 가능성 🔥

추적이 가능하도록 요구분석명세서를 작성

6. 변경 용이성

  • 한 곳의 변경으로 인해 다른 곳에 미치는 영향이 작은 것
  • 요구사항끼리 영향을 덜 미치려면 서로 의존도가 낮고 독립적으로 서술되어야 함

    7. 검증 가능성

  • 요구분석명세서가 시스템이 요구사항을 만족하는지를 체계적으로 검사할 수 있다면 검증 가능성은 큼
  • 요구분석명세서가 모호한 표현이 많이 포함되게 작성되었다면 검증 가능성은 작음
  • 예) ‘많은 학생이 동시에 수강신청을 해도 문제가 없어야 한다’ 에서 ‘많은’은 주관적인 표현이므로 객관적인 수치로 변경

요구사항 검증

  • 여러 방법을 통해 추출하고 정리한 사용자의 요구분석명세서가 정확하고 완전하게 서술되었는지 검토하는 활동
  • 사용자 요구사항이 완전하게 서술되었는지 검증
  • 요구분석명세서를 작성할 때 문서 표준을 따랐는지 확
  • 설계에서 사용하기에 적합한지를 확인

20240328153219

  • 키워드 중요

5주차. 설계

1. 요구 분석과 설계의 차이 🔥

구분 요구분석 설계
산출물 요구분석명세서 설계서
관점 무엇(what) 어떻게(how)
특성 개념적, 추상적 사용 환경을 반영해 구체적
비고 미고려 대상: 운영체제, DBMS(오라클, MS-SQL Server 등), 프레임워크(NET, J2EE 등) 고려 대상: 비기능 요구사항, 제약 사항, 플랫폼: 운영체제, 미들웨어, 프레임워크

좋은 설계가 되기 위한 조건

  • 설계서는 요구분석명세서의 내용을 모두 포함해야 함
  • 유지보수가 용이하도록 추적이 가능해야 함
  • 변화에 쉽게 적응할 수 있어야 함
  • 시스템 변경으로 인한 영향이 최소화되도록 국지적이어야 함
  • 설계서는 읽기 쉽고 이해하기 쉽게 작성해야 함

2. 설계의 원리(추상화,정보은닉,상속,다형성,모듈화)

1) 객체지향 설계에서 추상화의 의미 🔥

유사한 특성을 가진 것끼리 그룹화한 뒤 공통점을 뽑아 이름을 붙이는 것

20240401133756

2) 캡슐화의 개요 🔥

  • 전자제품은 내부가 어떻게 구성되어 있으며 어떤 방식으로 돌아가는지 몰라도 기능과 사용법을 아는게 중요함
  • 사용자에게 해당 객체의 기능(서비스)과 사용법만 제공해 사용하기 쉽게 하고 내부는 함부로 변경할 수 없게 감추는 개념
  • 블랙 박스와 같은 것으로 클래스를 사용해 서로 관련된 정보와 처리 방식을 같이 묶고 외부에는 감추어두는 것

3) 정보은닉의 속성

+(공개, public)

  • public으로 설정된 요소는 같은 시스템에 있는 모든 클래스가 접근할 수 있음
  • 클래스는 클래스 이름, 속성, 메서드로 구성되는데 public으로 설정되는 부분은 주로 메서드

    -(은닉, private)

  • private으로 설정된 요소는 같은 시스템 내의 다른 클래스가 직접 접근 할 수 없음
  • 해당 클래스의 메서드를 통해서만 접근할 수 있음
  • 클래스에서 대부분의 속성은 private으로 설정

    #(부분 공개, protected)

  • protected로 설정된 요소는 다른 클래스가 접근할 수 없음
  • 해당 클래스의 메서드와 클래스를 상속받은 하위 클래스만 접근

20240404093216

4) 상속

  • 상위 클래스의 모든 것을 하위 클래스가 물려받아 내 것처럼 사용함
  • 상속 관계에 속한 클래스, 데이터, 메서드를 추가하기 쉬ㅏ움
  • 데이터와 메서드를 변경할 때 상위에 있는 것만 수정 가능

5) 다형성

  • 오버로딩(중복정의)
  • 오버라이딩(재정의)
    • 메서드 재정의
    • 리스코프 교체 원칙: 상위 클래스의 객체는 언제나 자신의 하위 클래스의 객체로 교체 가능

6) 모듈화 🔥

  • 규모가 큰 것을 여러 개로 나눈 조각, 소프트웨어 구조를 이루는 기본 단위
  • 독립 프로그램도 하나의 모듈이 될 수 있고 함수도 하나의 모듈이 될 수 있음

모듈의 특징

  • 다른 것과 구별되는 독립적인 기능을 갖는 단위
  • 유일한 이름을 가짐
  • 모듈에서 또 다른 모듈을 호출할 수 있음
  • 다른 프로그램에서도 모듈을 호출할 수 있음

모듈의 원칙

  • 모듈화를 하기 전에 먼저 어느 정도의 크기로 나눌 것인지를 생각함
  • 문제의 유형이나 특성을 고려해 결정
  • 모듈 간의 결합은 느슨하게
  • 모듈 내 구성 요소 간의 응집은 강하게

모듈화의 장점

  • 분할과 정복의 원리가 적용되어 복잡도가 감소
  • 변경하기 쉽고 변경으로 인한 영향도 적음
  • 프로그램을 효율적으로 관리할 수 있음
  • 설계 및 코드를 재사용할 수 있음
  • 문제를 이해하기 쉽게 만듬
  • 유지보수가 용이
  • 오류로 인한 파급 효과를 최소화할 수 있음

모듈화의 적정 수준

  • 모듈을 적절하게 나뉘어야 최소 비용을 맞출 수 있다. 20240403135559

모듈 간 관계

  • 호출 관계: 모듈 A가 모듈 B를 호출하는 관계
  • 데이터 전달: 매개변수 등을 이용한 데이터 전달로 이루어지는 관계
  • 제어: 모듈 A가 모듈 B에게 제어 플래그를 전달하는 것과 같은 제어를 통해 이루어지는 관계

모듈 평가 기준 1: 응집도 🔥

결합도 차이 문제, 응집도는 높은게 좋나 낮은게 좋나?

응집도의 개요
  • 모듈 내부에 존재하는 구성 요소 사이의 밀접한 정도, 즉 하나의 모듈 안에서 구성 요소 간에 뭉쳐 있는 정도로 평가
  • 응집도가 높을수록 꼭 필요한 구성 요소만 모여 있고, 응집도가 낮을수록 서로 관련성이 적은 구성 요소들이 모임
  • 응집도가 가장 높은 것은 모듈 하나가 단일 기능으로 구성된 경우
  • 응집도가 가장 낮은 것은 구성 요소가 필요에 의해 모듈에 존재하는 것이 아니라 우연히 함께 묶인 경우

20240403135738

  • 응집도가 높으면 필요한 구성 요소만 모여 좋다. 🔥
  • 응집도가 낮으면 서로 관련성이 적어 안좋다.
  • 응집도가 높거나 낮은 표현을 그림, 말로 작성

모듈 평가 기준 2: 결합도 🔥

결합도의 개요

  • 모듈과 모듈 사이의 관계에서 관련 정도를 나타냄
  • 모듈 간의 결합에도 간섭하는 관계와 좋은 관계(간섭이 적은) 가 있음
  • 모듈 간에는 관련이 적을수록 상호 의존성이 줄어 모듈의 독립성이 높아지고 독립성이 높으면 모듈 간에 영향이 적음 = 결합도가 낮음
  • 결합에서 좋은 관계는 데이터만 주고받는 관계 / 나쁜 관계는 필요한 데이터만 주지 않고 직접 관여(간섭)하는 관계

20240403141823

  • 결합도가 낮으면 상호의존성이 줄어 독립성이 높아져 좋다. 🔥
  • 결합도가 높으면 간섭을 많이 받아 안좋다.

모듈 간의 좋은 관계 🔥

  • 모듈 간에는 꼭 필요한 데이터만 주고받는 것이 좋음
  • 약한 결합을 유지하는 것이 바람직하므로 인터페이스의 수가 적고 복잡하지 않아야 함
  • 그러려면 매개변수로 제어 플래그를 사용하는 것보다 데이터를 사용하는 것이 유지보수의 용이성을 높일 수 있어 좋음
  • 결론적으로, 설계를 할 때 가장 좋은 형태는 모듈 간의 결합도는 낮게, 응집도는 높게 하는 것 🔥

6주차. 아키텍처 설계

1) 아키텍처의 특징과 기능 🔥

아키텍처의 특징

  • 소프트웨어의 골격을 나타내는 추상화된 전체 구조를 제공
  • 소프트웨어를 이루고 있는 여러 구성 요소(서브시스템, 컴포넌트)를 다룸
  • 인터페이스를 통해 소프트웨어의 구성 요소가 어떻게 상호작용하는지를 정의
  • 세부 내용보다는 중요 내용(설계자가 주관적으로 판단하고 결정)만 다룸
  • 설계에 적용되는 원칙과 지침이 있음

아키텍처 설계 시 고려 사항

  • 모든 이해관계자 사이의 의사소통 도구로 활용할 수 있어야 함
  • 구현에 대한 제약 사항(개발 비용, 기간, 조직의 역량 등)을 정의해야 함
  • 모든 이해관계자의 품질 요구사항을 반영해 우선순위에 따라 시스템 품질 속성을 결정해야 함
  • 성능, 사용성, 보안성, 안정성, 검증 가능성, 변경 용이성 등
  • 특정 문제 영역에 적합한 소프트웨어의 구성 요소를 표준화하고 패턴화해 재사용할 수 있도록 설계해야 함

비즈니스 품질 속성

시장 적시성 🔥

  • 적정한 시기에 소프트웨어를 출시해 경쟁력을 높이는 것
  • 아키텍처 설계를 할 때 구매한 컴포넌트들이 잘 맞을 수 있도록 범용성 높은 설계가 필요

    비용과 이익 🔥

  • 아키텍처를 설계할 때 비용을 많이 들여 유연한 설계를 할 것인지, 비용을 절감해 이익을 높일 것인지 판단
  • 개발 시점에서 비용을 더 들여 유연한 시스템을 만들면 나중에 수정 및 유지보수가 쉬운 시스템
  • 비용 절감에 초점을 두면 우선 개발 비용이 적게 드는 효과는 있지만, 유지보수를 할 때 비용 증가

아키텍처의 4+1 관점

시나리오(유스케이스) 관점 🔥

  • 최종 사용자가 인식하는 시스템의 기능을 의미
  • 시스템이 사용자에게 제공하는 기능에 주목하는 관점

    논리적(디자인) 관점 🔥

  • 시스템의 기능에 관심이 있는 유스케이스 관점과 달리 시스템 내부를 들여다봄
  • 시스템의 기능을 제공하기 위해 필요한 클래스나 컴포넌트 및 이들의 관계에 초점

2) 아키텍처 스타일(6-3) 🔥

  • 아키텍처 스타일은 각각의 특징이 있고 해당 스타일만의 구성과 모양을 가지고 있음

20240411163144

  • 어떠한 종류이고 서로의 특징차이를 비교하자

    1. 데이터 중심형 스타일

  • 가장 큰 특징은 주요 데이터가 리포지토리에서 중앙 관리된다는 점
  • 리포지토리와 여기에 접근하는 서브시스템으로 구성
  • 시스템에서 공동으로 활용하는 데이터는 리포지토리에 보관
  • 대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용
  • 서브시스템과 리포지토리의 결합도가 높아 리포지토리를 변경하면 서브시스템에 영향을 줄 수 있다는 단점

20240411163520

2. 클라이언트-서버 스타일

  • 네트워크를 이용하는 분산 시스템 형태로 데이터와 처리 기능을 클라이언트와 서버에 분할해 사용
  • 서버, 서비스, 클라이언트로 구성되며 서브시스템(컴포넌트)이 서비스를 서로 요청하면서 상호작용

서버 특성

  • 클라이언트(서브시스템)에 서비스를 제공하는 역할을 하므로 클라이언트의 요청을 처리하기 위해 대기
  • 요청을 처리한 후에는 결과를 클라이언트에 회신
  • 프린트 서버, 파일 및 FTP 서버, 메일 서버, DNS 서버 등이 이에 해당

클라이언트 특성

  • 사용자와 대화하기 위해 서버가 제공하는 서비스를 요청(호출)하는 서브시스템
  • 메시지나 원격 프로시저 호출을 통해 서비스를 요청하고 서버가 이 요청을 받아 수행하면 그 결과를 클라이언트에게 전송
  • 클라이언트가 서버에 서비스를 요청할 때는 서버의 이름과 제공서비스를 알아야 함
  • 인터넷을 통해 웹서버와 통신해 웹 페이지를 다운로드하고 사용자에게 보여주는 웹브라우저가 해당

20240411163603

3. 계층 스타일

  • 기능을 몇개의 계층으로 나누어 배치
  • 재사용 및 유지보수가 용이
  • 역할 분담이 명확, 각 계층 쉽게 변경 가능 20240423155535

4. MVC 스타일

  • 구성요소를 기능별 또는 특성별로 명확하게 분리해 유지보수를 쉽게하고 프로그램의 확장성과 유연성을 높임
  • [모델, 뷰, 제어] 의 세 부분으로 이루어짐

3) 클래스 설계 원칙

일반화 관계

일반화와 상속

  • ‘일반적’의 사전적 의미: 일부에 한정되지 아니하고 전체에 걸치는 것 , 보편적이고 상식적인 것
  • 클래스에서 일반화: 공통점을 가지고 있는 여러 개의 클래스를 묶어서 새로운 클래스를 만들고 공통적인 이름을 붙인 것
  • 일반화 관계는 상속 구조이며 하위 클래스는 상위 클래스의 모든 것(속성, 메서드)을 상속받아 사용
  • 아래에서 위로 추상화되는 것을 일반화, 반대로 위에서 아래로 구체화하는 것을 특수화라고 함
  • 개별 클래스와 공통 클래스 사이에 ‘is a kind of’ 관계가 성립되어야 함
  • is a kind of 관계 : ‘사각형은 도형의 일종이다’, ‘원은 도형의 일종이다’

20240412101545

집합 관계

집합 관계

  • ‘상위 클래스가 하위 클래스로 구성될 때의 관계로 ‘is composed of’가 성립되어야 함
    • is composed of 관계 : ‘컴퓨터는 모니터, 본체, 키보드로 이루어졌다’라고 할 때 말이 되는 관계
  • 모든 객체가 별개의 생명주기를 가지고 있으며 각각 독립적으로 동작하기 때문에 약한 결합 관계
  • 집합 관계에서 전체(컴퓨터)와 부분(모니터, 본체, 키보드)의 연결은 직선으로 하되 머리 부분은 속이 비어 있는 마름모 모양

20240412101819

합성 관계

합성 관계

  • 집합 관계와 많은 부분이 유사하지만 전체 객체에 완전히 종속되어 독립된 객체로 존재할 수 없다는 것이 다름
  • 모든 객체가 같은 생명주기를 가지고 있으므로 각각 독립적으로 동작할 수 없는 강한 결합 관계
  • 전체(노트북)와 부분(모니터, 본체, 키보드)의 연결은 직선으로 하되 머리 부분은 속이 채워진 마름모 모양

20240413181500

의존 관계 🔥

연관 관계와 의존 관계의 차이점

  • 서로 상대의 클래스를 사용(참조) 할 때의 관계로 클래스 A의 변화는 클래스 B의 변화로 연결되는 점에서 연관 관계와 유사
  • 연관 관계는 상대 클래스를 인식하기 위해 멤버 변수를 가짐
  • 클래스 A인 Repeater 클래스가 클래스 B인 Scan 클래스를 멤버 변수로 가지고 있음

20240413181604

연관 관계와 의존 관계의 차이점

  • 의존 관계는 상대의 메서드를 가지고 있음
  • 예시) 클래스 A의 메서드가 클래스 B의 객체를 인자로 받아 그 메서드를 사용할 경우
  • 색 글자로 표시된 부분을 보면 Scan 클래스를 인자(파라미터)로 받아 사용

20240413181655

  • 서로 참조 🔥
    • 연관: 서로 인식하기 위해 멤버 변수를 가짐
    • 의존: 상대의 메서드를 가지고 있음

연관 관계와 의존 관계의 차이점

  • 의존 관계는 상대의 메서드를 가지고 있음
  • 예시) 클래스 A인 Repeater 클래스의 메서드인 repeat() 내부에서 클래스 B의 객체를 생성해 메서드를 사용할 경우
  • 클래스 A인 Repeater 클래스는 클래스 B인 Scan 클래스를 지역 변수로 사용

실체화 관계

  • 특정 클래스에 기능을 추가하기 위해 메서드를 넣을때 하위 클래스가 상속을 무조건 받아야 하는 사태가 발생
  • 인터페이스 클래스는 메서드의 공통 특성을 묶어 새로운 인터페이스 클래스를 만들고 공통의 이름을 붙임
  • 이 클래스는 변수를 정의할 수 없고 추상 메서드를 가지며 이 메서드에 대한 구체적인 실현은 하위 클래스에서 구현
  • 스테레오타입으로 «»를 사용하고 하위 클래스와의 연관은 일반화 관계와 다르게 점선으로 나타냄
  • 화살표의 머리 부분은 하위 클래스에서 상위 클래스로 향하며 모양은 속이 빈 삼각형

20240413183018

4) 단일 책임 원칙 (SRP)

단일 책임 원칙: 클래스를 변경해야 하는 이유는 단 하나여야 한다.

단일 책임 원칙

  • 로버트 마틴: 책임의 의미는 변경하는 이유
  • 단일 책임의 원칙은 클래스를 설계할 때 변경하는 이유가 하나가 되도록 해야 한다는 것
  • 모든 클래스는 한 가지 책임, 즉 변경의 이유를 오직 하나만 갖도록 설계하고 클래스는 그 책임을 완전히 캡슐화하는 것
  • 클래스에 2개의 책임이 존재한다면 2개의 클래스로 분리해 ‘변경해야 하는 이유가 오직 하나 가 되도록’ 설계하는 것이 바람직

20240413183122

4) 개방 폐쇄 원칙 (OCP)

개방 폐쇄 원칙: 변경에는 닫혀 있어야 하고, 확장에는 열려 있어야 한다.

개방 폐쇄 원칙

어떤 것은 개방하고 어떤 것은 폐쇄하는 것

Video_Palyer 클래스의 예시: 원칙 위반

  • 처음에는 MP4만 지원하던 Video_Palyer 클래스에 지원가능한 파일 형식이 늘어날때마다 클래스를 수정
  • 개방 폐쇄 원칙을 따르지 않으면 지원 가능한 파일 형식이 늘어날 때마다 계속 클래스를 수정해야 함

20240413185235

Video_Palyer 클래스의 예시: 원칙 적용

  • 계속해서 바뀌는 것이 무엇인지를 찾고 그것들을 모아 상속 구조로 만들어 상위 클래스에 배치
  • 하위 클래스에는 코덱의 종류를 배치해 계속 추가할 수 있도록 함
  • Video_Player 클래스에서 이들을 호출해 사용하도록 설계

20240413185453

개방 폐쇄 원칙의 장점

  • 변경에 닫혀 있는 설계: 계속된 추가 사항이 있어도 그들끼리만 추가할 수 있도록 설계
  • 확장에 열려 있는 설계: 새로운 클래스를 쉽게 추가할 수 있는 구조로 설계
    • 변경은 어렵게 추가는 쉽게.

5) 인터페이스 분리 원칙 (ISP) 🔥

인터페이스 분리 원칙: 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안된다.

인터페이스 분리 원칙

  • 다수의 클라이언트가 일반적인 인터페이스 하나를 같이 사용하는 것보다 각각의 클라이언트가 필요한 대로
  • 여러 개의 구체적인 인터페이스로 분리해 사용하는 것이 더 낫다는 의미
  • 무조건 모든 클라이언트에게 각각의 인터페이스를 제공하는 의미가 아님
  • 각각의 클라이언트가 필요로 하는 메서드군이 존재할 때 인터페이스를 분리

인터페이스 분리 원칙의 장점 🔥

  • 용도가 명확한 인터페이스를 제공할 수 있어 클래스에 필요한 메서드만 선언할 수 있음
  • 시스템의 내부 의존성을 낮춰(낮은 결합) 리팩토링을 쉽게 해 재사용성을 높일 수 있음

학사관리 클래스의 예시: 원칙 위반 다이어그램 그리기 🔥

사용하지 않는 것은 연관 문제 X

  • 학사관리 클래스에 많은 메서드가 있고 이 메서드를 학생, 교수, 직원이 사용
  • 학생이 사용하는 것은 수강신청()과 성적조회() 뿐인데 사용하지 않는 다른 메서드와도 연관 관계 를 맺고 있음 (사용하지 않는 것은 연관 관계X)
  • 직원과 교수도 마찬가지로 사용하지 않는 메서드와 연관 관계를 맺고 있음

20240414205640

학사관리 클래스의 예시: 원칙 적용 🔥

  • 클래스 다이어그램에서는 사용자(학생, 직원, 교수)별로 인터페이스를 분리
  • 각 사용자는 오직 자신이 필요로 하는 메서드와 연관되어 있고 다른 메서드와는 관계가 없음
  • 학생 인터페이스의 수강신청(), 성적조회()의 구현은 학사관리 클래스에 그대로 남아 있음
  • 단일 책임 원칙 과 혼동해서는 안됨

20240414205713

  • 분리의 원칙(인터페이스 분리)

설계의 원리와 (클래스)설계 원칙의 차이점 비교🔥

20240423162044

< 설계의 원리 >

추상화,정보은닉,상속,다형성,모듈화 등

  • 소프트웨어 설계 전반에 걸쳐 적용할 수 있는 광범위한 지침

    목적

    소프트웨어 전체의 품질, 구조 개선

< (클래스) 설계 원칙 >

일반화, 상속, 연관관계, 의존관계, 단일책임원칙, 개방폐쇄원칙 등

  • 객체 지향 프로그래밍에서 클래스 설계할 때 적용되는 구체적인 지침

    목적

    객체지향적 특성 최대화 유지보수, 확장성 높임

댓글남기기

참고

LLMOps 란?

14 분 소요

LLMOps란 무엇인가요?