개발자 Lim

설계패턴

• GoF 4명의 저자가 기술한 지금까지 소프트웨어의 중복되는 문제를 재사용 가능한 해결책으로 해결하기 위한 방법
• 해결 방법은 특정 언어로 종속되어서는 안되기에 언어와 관계 없는 내용으로 기술 할 필요성이 있음
• 그렇기에 UML을 통해 학습하는 것이 좋은 방법

UML: 모델링 기술 랭귀지 → 해결책 기술

• class Diagram(구조적 측면)
• sequence Diagram(동적인 측면)

필요성

• 유스케이스 다이어 그램이 전체적인 기능 요구 사항은 시각적으로 잘 표현하고 있지만 구체적인 동작은 알 수가 없기 때문이다.

작성법

• 기본 정보
  • 유스케이스 이름
  • 유스케이스 행위자(액터)
  • 유스케이스 상태(유스케이스 기술 단계)
  • 사전 조건: 해당 유스케이스의 필요 조건
• 개요: 해당 유스케이스의 기능 설명

• 시나리오 흐름
  • 기본 흐름: 개조식으로 유스케이스의 과정의 입력 대비 출력의 변화를 기술
    • 액터는 ~을 한다, 시스템은 ~을 한다 형식
  • 대안 흐름: 기본 흐름 도중 if, else로 나뉘는 상황
    • 조건 검사 후에 배치
  • 예외 흐름: 각 흐름에서 비정상정인 경우가 발생한 상황 try, catch
    • 조건 검사 전에 배치

모델링

• 코드를 작성하기 전 모델을 만드는 것
• 요구사항 분석 모델을 보는 순간 소스코드가 보여야한다.
• 요구사항의 50%는 결정된다.

UML(Unified Modeling Language)

• 객체지향 모델링을 위해 개발된 대표적인 표준 모델링 방법
• 객체 지향 프로그래밍에 익숙하다면 UML의 기능을 더 쉽게 이해 가능
• 분석 모델과 설계 모델의 표현 방법이 같다.

UML의 종류

• 구조 다이어그램
  • 클래스 다이어그램
• 행위 다이어그램
  • 유즈케이스 다이어그램
  • 기능 요구사항 분석 모델링
  • 사용자 관점에서 시스템의 기능을 구성한 것

유스케이스 다이어그램

• 구성요소
  • 시스템 범위
  • 액터 (사용자, 외부 시스템)
  • 유스케이스 (기능적 요구사항을 단순 명료하게 기술)
    • 기능이므로 ~한다와 같이 표현된다.
  • 관계 (엑터, 유스케이스들 관의 기능적 관계를 나타냄)
• 유스케이스 기술서: 유스케이스들의 구체적인 내용을 기술하는 명세서
• 과정
  • 시스템 경계 정하기
  • 액터 찾기
  • 유스케이스 찾기
  • 유스케이스 사이의 관계 찾기

유스케이스 다이어그램 관계

• 연관 관계: 액터와 유스케이스 간의 상호작용이 존재하는가?
• 포함 관계: 다른 유스케이스를 사용하기 위해 필요한 유스 케이스인 관계
  • ex: 상품 검색, 상품 주문 → 상품 조회(포함 관계)
  • 반드시 호출
• 확장 관계: 해당 유스케이스를 실행할 때 선택적으로 실행되는 유스케이스인 관계
  • ex: 상품 목록 조회, 구입 내역 조회 ← 상품 상세 조회(확장 관계)
  • 선택적 호출
• 일반화 관계
  • 유사한 유스케이스를 모두 수용할 수 있는 관계 (상속 관계)
  • ex: 상품결제 ← 신용카드 결제, 계좌 이체, 무통장 입금 결제
  • 부모 - 자식 관계

액터 모델링

• 고객(부모)
  • 회원(자식)
  • 비회원(자식)

소프트웨어 특성 정보

• 소프트웨어 개발 비용
  • 분석 및 설계 40%, 코드 개발 20%, 테스트 40%
• 소프트 웨어 개발 및 유지 보수
  • 개발 비용 33%, 운영 및 유지 비율 67%
• 소프트웨어 개발 시 오류의 근원
  • 문서화 및 기타 오류 35%, 코드 작성 오류 30%, 로직 설계의 오류 20%, 기능의 잘못된 이해 15%

소프트웨어 공학의 목표

• 사용자의 요구사항을 충족시키는 품질 좋은 소프트웨어 개발
  • 개발 대상의 명확화: 소프트웨어의 모호성을 없애주는 것이 중요하다!
  • 개발 과정의 체계화
  • 개발 수명주기 지원

소프트웨어 개발 순서

• 계획
• 요구사항 분석: 개발하고자 하는 소프트웨어에 대한 요구사항을 고객으로 부터 수집하고 명세하는 단계
  • How? 보다는 What에 초점을 
  • 요구 분석 절차: 자료수집 -> 요구사항 도출 -> 문서화 -> 검증
  • 요구 분석 분류
    • 기능 요구사항: 사용자가 원하는 기능 
    • 비기능 요구사항: 품질, 제약 사항 
• 설계: 고객의 요구사항을 만족하기 위한 여러 해결책을 제시하고 이 중에서 가장 최적화된 해결책을 선정하는 단계
  • What 보다는 How?에 초점을 둠
• 구현: 고객의 요구사항을 실제 서비스의 형태로 제공할 수 있도록 개발하는 단계
• 테스트: 개발된 프로그램이 고객의 요구대로 동작이 되는지를 시험하는 단계
• 유지보수
  • 수정 유지보수: 소프트웨어의 오류가 발견되었을 때 수정
  • 적응 유지보수: 운영체계나 인프라 환경 등이 변화되었을 때 이 변화를 수용하도록 프로그램을 수정하는 작업
  • 완전 유지보수: 기능이나 성능을 개선하거나 새로운 기능을 추가하기 위하여 프로그램을 수정하는 작업
  • 예방 유지보수: 수정 유지보수를 하지 않게 끔 오류 상황을 미연에 방지될 수 있도록 수행하는 작

Code-and-fix 모델

• 요구사항 분석 단계와 설계 단계가 없다
• 대상: 개발될 소프트웨어가 매우 소규모이면서 매우 간단한 경우에 사용된다.
• 요구사항에 대한 명세를 따로 작성하지 않기 때문에 매우 짧은 기간 동안만 사용되는 경우에 이용
• ex: 간단한 학교 주간 과제
• 우연히 발견된 오류를 수정하는 디버깅에 중심을 둠

waterfall 모델

• 가장 전통적인 모델
• 다른 모델의 기반
• 선형적
• 각 단계마다 생성되는 산출물에 확인 절차를 거친다.
• 요구사항분석
  • 초기 개발 단계에서는 고객의 모든 요구사항이 완벽하게 수집되어야 한다. (요구 분석 문서화)
  • 요구 분석 문서를 기준으로 사용자에게 이상유무를 확인 받고 설계 절차로 넘어간다.
• 설계
  • 아키텍쳐 설계(상위 설계)
  • 하위 설계(모듈 세부 내용)
  • 객체 지향 방법론에 따라 설계를 한다
• 구현
  • 실제 코딩을 하는 단계
  • 시큐어 코딩
• 테스트
  • 개발자 또는 사용자 시각에 따른 분류
  • 사용되는 목적에 따른 분류
  • 프로그램의 실행 요구 여부에 따른 분류
  • 품질 특성에 따른 분류
  • 소프트웨어 개발 단계에 따른 분류
• 유지보수
• 장점
  • 관리가 용이하다
  • 체계적으로 문서화할 수 있다.
  • 요구사항의 변화가 적은 프로젝트에 적합하다.
• 문제점: 고객의 모든 요구사항이 완벽하게 수집되어야 하며 일단 요구사항이 수집되고 분석되어 명세가 완료되었으면 더 이상 요구사항은 변경 되지 않아야 한다.
  • 요구사항의 변화에 기민하게 대처하지 못함
  • 앞 단계가 완료되어야 수행할 수 있음
  • 각 단계마다 작성도니 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류가 발생하지 않음
  • 사용자가 중간에 가시적인 결과를 볼 수 없어 답답해할 수 있다.

애자일 프로세스

• 반복적이고 점진적인 개발 방법
• 한번에 조립하는 방식에서 큰 규모의 작업을 짧은 주기를 갖는 이터레이션으로 분할 하고 점진적으로 규모를 키우면서 완성하는 방법
• 추구하는 가치
  • 포괄적인 문서화 보다는 동작하는 소프트웨어에 더 중요한 가치를 둔다.
  • 계획에 따르기보다는 변화에 대한 대응에 보다 많은 가치를 둔다
  • 코드 중심의 개발

결론

• 전통적 개발 방식은 제품을 만들기 위한 작업 단계들에 중점을 두고 있는 반면 애자일 방법은 제품에 의해 고객에게 전달되는 가치에 중심을 두고 있다.

SOLID

• 클린 코드로 유명한 로버트 마틴이 좋은 객체 지향 설계 5가지 원칙을 정리

SRP: 단일 책임 원칙 (Single Responsibility Principle)

• 한 클래스는 하나의 책임을 가져야 한다.
• 하나의 책임이라는 것이 모호하다.
  • 클 수 있고, 작을 수 있다.
  • 문맥과 상황에 따라 다르다
• 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
• 구현 객체를 생성하고 연결하는 책임을 지는 Class를 따로 만들어 관심사를 분리해야 함

관심사의 분리

• SRP 단일책임의 원칙을 지키기 위해서 사용한다.
• 애플리케이션의 전체 동작 방식을 구성하기 위해, 구현 객체를 생성하고 연결 하는 책임을 가지는 별도의 설정 클래스를 만들자
  • 코드를 사용영역과 구성영역으로 분리
• 생성자 주입 (DIP 의존관계의 역전 원칙)방법 사용

OCP: 개방-폐쇄 원칙 (Open Close Principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 다형성 활용
• 인터페이스를 통해 각각의 클래스를 구체화

OCP 문제점

• 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
• 분명 다형성을 지켰지만 OCP 원칙을 지킬 수 없다.
• 해결법: 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. (@Configuration)

LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다
• 어떤 프로그램에서 A를 사용할때 서브 클래스인 B를 사용하여도 아무 문제가 없어야 한다.
  • 예시: 공연(남주, 여주, 촬영장소) -> interface(역활) 남주, 여주, 촬영장소
  • -> 구현체 (차은후, 한성민), (김수연, 김혜린), (한성대학교, 아주대학교) 둘 중 어느걸 선택해도 기능에 문제가 없음

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
• 적당한 크기로 인터페이스도 분리가 필요하다.

DIP: 의존관계 역전 원칙 (Dependency Inversion Principle)

• 프로그래머는 추상화에 의존해야지 구체화에 의존해서는 안된다.
• 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다.
• 역활에 의존하게 해야 한다.
• 구현체의 의존하게 되면 변경이 아주 어려워진다.