[정처기]요구사항 확인 - 현행 시스템 분석(1)

현행 시스템 파악

⚡️ 현행 시스템 파악 개념

📖하위 시스템 구성 / 제공 기능 및 연계 정보 / 기술 요소 파악

⚡️ 현행 시스템 파악 절차(3)

• 1단계 : 구성/기능/인터페이스 파악
• 2단계 : 아키텍처 및 소프트웨어 구성 파악
• 3단계 : 하드웨어 및 네트워크 구성 파악

⚡️ 소프트웨어 아키텍처

🖥️ 소프트웨어 아키텍처 개념

📖구성요소 / 특성 / 관계를 표현하는 구조나 구조체

🖥️ 소프트웨어 아키텍처 프레임워크

• 개념 : 아키텍처가 표현해야 하는 내용 및 관계를 제공하는 기술 표준
• 구성요소(9)
  • 아키텍처 명세서 : 산출물 / 뷰로 표현 / 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등
  • 이해관계자 : 관련된 모든 사람 / 조직
  • 관심사 : 사용자 / 유지보수자 / 개발자 입장
  • 관점 : 패턴 또는 양식
  • 뷰 : 관심사들의 집합 / 전체 시스템 표현
  • 근거
  • 목표 : 목적 / 사용 / 운영
  • 환경
  • 시스템

🖥️ 소프트웨어 아키텍처 4+1 뷰

• 개념
  • 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 접근 방법
  • 체크방법으로 유스케이스 사용
• 구성요소
  • 유스케이스 뷰(Usecase View) : 다른 뷰 검증 / 사용자, 설계자, 개발자, 테스트 관점
  • 논리 뷰(Logical View) : 기능적 요구사항 제공 설명 / 설계자, 개발자 관점
  • 프로세스 뷰(Process View) : 비기능적인 속성 / 개발자, 시스템 통합자 관점
  • 구현 뷰(Implementation View) : 정적인 소프트웨어 모듈의 구성 / 컴포넌트 구조 및 의존성
  • 배포 뷰(Deployment View) : 컴포넌트 물리적 아키텍처 배치 매핑

🖥️ 소프트웨어 아키텍처 패턴

• 개념

  • 소프트웨어 설계 시 참조 할 수 있는 전형적 해결 방식
  • 일반화 / 재사용 가능 솔루션

• 필요성

  • 고객과 의사소통 -> 요구사항 만족 / 생산성 및 품질 확보
  • 시행착오 감소 -> 개발시간 단축 / 높은 품질
  • 검증된 구조 개발 -> 안정적 개발
  • 시스템 특성 예측 가능

• 패턴 유형(5)

  • 계층화 패턴

    • 시스템 -> 계층(Layer)로 구분
    • 하위 모듈 : 특정한 수준 추상화 제공
    • 서로 마주 보는 계층 사이에서만 상호 작용
      

  • 클라이언트-서버 패턴

    • 하나의 서버 / 다수의 클라이언트
    • 사용자 -> 클라이언트 -> 서버 -> 클라이언트 -> 서비스 제공
    • 서버 -> 클라이언트 요청 대기(지속)
      

  • 파이프-필터 패턴

    • 데이터 스트림 생성 및 처리
    • 서브 시스템 -> 입력 데이터 처리 -> 결과 전달(다음 서브 시스템)
    • 확장 용이
      

  • 브로커 패턴

    • 분리된 컴포넌트로 구성된 분산 시스템에서 사용
    • 원격 서비스 실행 -> 상호 작용 가능
    • 기능전달(서버 -> 브로커) -> 서비스 요청(클라이언트 -> 브로커) -> 리다이렉션(브로커 -> 클라이언트)
      

  • 모델-뷰-컨트롤러 패턴

    • MVC 패턴 / 대화형 어플리케이션
    • 각 부분이 별도 컴포넌트 -> 서로 영향을 받지 않고 개발 수행
    • 코드 재사용 / 여러개의 뷰 -> 대화형 어플리케이션 구축 적합
      

🖥️ 소프트웨어 아키텍처 비용 평가 모델

• 개념 : 아키텍처 접근법이 품질 속성에 미치는 영향 판단 -> 적합성 평가
  

• 종류(5)

  • SAAM : 변경 용이 및 기능성 집중 / 평가 용이
  • ATAM : 아키텍처 품질 속성 만족 여부 / 상충관계 평가
  • CBAM : ATAM 바탕 / 경제적 의사결정
  • ADR : 응집도 평가
  • ARID : 특정 부분 품질요소 집중

⚡️ 디자인 패턴

🖥️ 디자인 패턴 개념

소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

🖥️ 디자인 패턴 구성요소

이름 / 문제 및 배경 / 솔루션 / 사례 / 결과 / 샘플코드

🖥️ 디자인 패턴 유형

목적(3) / 범위(2)

• 목적패턴
  • 생성 : 클래스 정의 및 객체 생성 방식 구조화 / 캡슐화
  • 구조 : 객체의 조합
  • 행위 : 상호작용 및 역할분담
• 범위패턴
  • 클래스 : 컴파일 타임(정적)
  • 객체 : 런타임(동적)

🖥️ 디자인 패턴 종류

생성 / 구조 / 행위 패턴

• 생성패턴(생빌 프로 팩앱싱)
  • Builder : 객체 생성 및 구현 방법 분리 / 복잡한 객체 생성
  • Prototype : 복사한 후 필요 부분만 수정 / 기본형태가 있을 시 사용
  • Factory : 하위 클래스에 데이터 생성 책임 / 클래스를 국한하지 않고 생성
  • Abstract Factory : 의존적인 객체 조합 / Concreate Product 클래스
  • Singleton : 한 클래스에 한 객체만 존재
• 구조패턴(구 브데 퍼플 프록 컴 어)
  • Bridge : 기능과 구현의 클래스 계층 연결 / 추상화와 실제 구현 부분을 독립적 확장
  • Decorator : 기존 클래스에 필요한 기능 추가 / 기능을 동적으로 확장 / 상속의 대안
  • Facade : 단순한 인터페이스 제공 / 결합도를 낮추어 오류를 단위별로 확인
  • Flyweight : 클래스의 경량화 / 가상 인스턴스 제공
  • Proxy : 대리 객체 / 정보은닉의 역할 수행 / 실제 이용할 때 할당
  • Composite : 객체 관계 트리 구조로 구성 / 단일 및 복합 객체를 동일하게 다룸
  • Adapter : 기존 클래스 재사용 / 중간에서 맞춤 / 덧씌움
• 행위패턴(행 미인이 템옵 스테 비커 스트 메체)
  • Mediator : 느슨한 결합 / 중재자 / 통신의 빈도수 줄임
  • Interpreter : 구체적으로 구문을 나눔 / 여러 형태의 언어 구문 해석
  • Iterator : 반복자 사용 / 컬렉션 구현 방법 비노출
  • Template : 특정 단계 수행 내역 변경 / 추상 메서드 - 기능 골격 제공
  • Observer : 자동으로 내용이 갱신 / 일대 다의 의존성 / 느슨하게 결합
  • State : 객체 상태를 캡슐화 / 원시 코드의 수정을 최소화
  • Visitor : 각 클래스를 돌아다니며 특정 작업을 수행 / 기능만 따로 추가 확장
  • Command : 재사용성이 높은 클래스를 설계 / 각 명령에 맞는 서브 클래스 선택
  • Strategy : 알고리즘 군 정의 / 행위를 클래스로 캡슐화
  • Memento : Undo 기능을 개발 / 작업취소 요청 가능
  • Chain of Responsibility : 하드코딩 / 한 요청을 2개 이상의 객체에서 처리