2022년09월17일 TIL - 정보처리기사 실기 정리

---

[02] 현행 시스템 분석

01. 현행 시스템 파악

(3) 소프트웨어 아키텍처

2. 소프트웨어 아키텍처 프레임워크

1. 소프트웨어 아키텍처 프레임워크(Software Architecture Framework) 개념
   • 시스템에서 아키텍처가 표현해야 하는 내용과 이들 간의 관계를 제공하는 아키텍처 기술 표준
2. 소프트웨어 아키텍처 프레임워크 구성요소
   • 아키텍처 명세서 (Architectural Description)
     • 아키텍처를 기록하기 위한 산출물들
     • 개별 뷰, 개괄 문서, 인터페이스 명세 등이 있음
   • 이해관계자 (Stakeholder)
     • 시스템 개발에 관련된 모든 사람, 조직
   • 관심사 (Concerns)
     • 시스템에 대한 이해관계자들의 서로 다른 의견과 목표
       • 사용자 입장: 기본적인 기능, 신뢰성, 보안, 사용성 등의 품질
       • 유지보수자 입장: 유지보수의 용이성
       • 개발자 입장: 적인 비용과 인력으로 개발
   • 관점 (Viewpoint)
     • 이해관계자들의 서로 다른 역할이나 책임으로 보고싶은 관점
   • 뷰 (View)
     • 서로 관련있는 관심사들의 집합이라는 관점에서 전체 시스템 표현
     • 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성
   • 근거 (Rationale)
     • 아키텍처 결정 근거
     • 회의 결과, 보고 결과
   • 목표 (Mission)
     • 환경안에서 한 명 이상의 이해관계자들이 의도하는 시스템의 목적, 사용, 운영 방법
   • 환경 (Environment)
     • 개발, 운영 등의 외부 요인 등으로 시스템에 영향을 주는 요인
   • 시스템 (System)
     • 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체

3. 소프트웨어 아키텍처 4+1 뷰

1. 개념
   • 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
   • 4개의 분리된 구조로 구성되는 아키텍처 개념을 제시하고, 서로 충돌되지 않는지, 요구사항을 충족시키는지 증명하기 위해 유스케이스를 사용
2. 구성요소
   • 4+1 에서 1은 유스케이스 뷰이고 4는 논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰
     • 유스케이스 뷰 (Usecase View)
       • 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰
       • 사용자, 설계자, 개발자, 테스트 관점
     • 논리 뷰 (Logical View)
       • 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
       • 설계자, 개발자 관점
     • 프로세스 뷰 (Process View)
       • 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
       • 개발자, 시스템 통합자 관점
     • 구현 뷰 (Implementation View)
       • 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
       • 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
     • 배포 뷰 (Deployment View)
       • 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

4. 소프트웨어 아키텍처 패턴

1. 개념
   1. 소프트웨어를 설계할 때 참조할 수 있는 해결방식
   2. 문제점들에 대한 일반화되고 재사용 가능한 솔루션
2. 필요성
   1. 생산성과 품질 확보
   2. 시행착오를 줄여 시간을 단축하고, 높은 품질의 개발
   3. 검증된 구조로 개발은 안정적으로 수행
   4. 시스템의 특성을 개발 전에 예측 가능
3. 유형
   1. 계층화 패턴 (Layered Pattern)
   2. 클라이언트-서버 패턴 (Client-Server Pattern)
   3. 파이프-필터 패턴 (Pipe-Filter Pattern)
   4. 브로커 패턴 (Broker Pattern)

5. 소프트웨어 아키텍처 비용 평가 모델

1. 비용 평가 모델 개념
   1. 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
2. 비용 평가 모델 종류
   1. SAAM (Software Architecture Analysis Method)
   2. ATAM (Architecture Trade-off Analysis Method)
   3. CBAM (Cost Benefit Analysis Method)
   4. ADR (Active Design Review)
   5. ARID (Active Reviews for Intermediate Designs)

(4) 디자인 패턴

1. 디자인 패턴(Design Pattern) 개념

• 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
• 개발의 효율성과 유지보수성, 운용성이 높아지며, 프로그램의 최적화에 도움

2. 디자인 패턴 구성요소

• 패턴의 이름
• 문제 및 배경
• 솔루션
• 사례
• 결과
• 샘플코드

3. 디자인 패턴 유형

• 목적
  • 생성
  • 구조
  • 행위
• 범위
  • 클래스
  • 객체

4. 디자인 패턴 종류

• 생성 패턴
  • Builder
  • Prototype
  • Factory Method
  • Abstract Factory
  • Singleton
• 구조 패턴
  • Bridge
  • Decorator
  • Facade
  • Flyweight
  • Proxy
  • Composite
  • Adapter
• 행위 패턴
  • Mediator
  • Interpeter
  • Iterator
  • Template Method
  • Observer
  • State
  • Visitor
  • Command
  • Strategy
  • Memento
  • Chain of Responsibility

(5) 현행 시스템 분석서 작성 및 검토

1. 현행 시스템 관련 자료 수집

수집 자료의 특성에 따라 33개의 팀을 구성한다.

• 정보시스템 구성/기능 및 인터페이스 자료 수집팀
  • 정보시스템 구성도
  • 정보시스템 기능 구성도
  • 정보시스템 인터페이스 현황
• 현행 시스템 아키텍처 및 소프트웨어 자료 수집팀
  • 현행 시스템 아키텍처 구성도
  • 소프트웨어 구성도
• 하드웨어 및 네트워크 자료 수집팀
  • 하드웨어 구성도
  • 네트워크 구성도

2. 수집 자료의 분석

• 수집된 정보들을 취합/정제하고, 중복되거나 유효하지 않은 정보들은 삭제
• 불명확한 부분은 체크한 후 분석 및 설계 단계를 통해 구체적으로 조사
• 현행 시스템의 이슈 및 문제점 파악

3. 분석한 결과를 기반으로 산출물 작성

• 각 취득 자료를 분석한 결과를 기반으로 산출물 작성
• 현행 시스템의 이슈나 문제점을 산출물에 상세하게 포함하여 작성

4. 산출물에 대한 검토 수행

• 팀별로 작성된 산출물을 상호 검토하여 의견 제시
• 다른 팀의 검토 의견을 반영하여 산출물을 수정하고 최종 완료

2. 개발 기술 환경 정의

(1) 개발 기술 환경 현행 시스템 분석

1. 운영체제 현행 시스템 분석

1. 운영체제(Operating System)의 개념
   • 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 사용자와 하드웨어 간의 인터페이스를 담당.
2. 운영체제 현행 시스템 분석
   • 운영체제 현행 분석 시 품질 측면과 지원 측면 등을 고려한다.
     • 품질 측면
       • 신뢰도
       • 성능
     • 지원 측면
       • 기술 지원
       • 주변 기기
       • 구축 비용
3. 운영체제 종류 및 특징
   • PC
     • 윈도우즈 (Windows) - Microsoft
     • 유닉스 (UNIX) - IBM, HP, SUN
     • 리눅스 (Linux) - Linus Torvalds
   • 모바일
     • 안드로이드 (Android) - Google
     • iOS - Apple

리눅스(Linux) 기반 시스템이 하드웨어 및 소프트웨어 소유 비용이 가장 적게 소요된다.

2. 네트워크 현행 시스템 분석

1. 네트워크(Network)의 개념
   • 노드 간 연결을 통해 서로에게 데이터를 교환할 수 있도록 하는 기술
   • 광케이블과 같은 유선 매체 또는 와이파이(Wi-Fi)와 같은 무선 매체를 통해 확립
2. OSI 7계층(Layer)
   • 네트워크 통신에서 생긴 여러 가지 충돌 문제를 완화하기 위해 국제 표준화 기구 (ISO; International Standardization Organization)에서 제시한 네트워크 기본 모델
     • 응용 계층 (Application Layer)
     • 표현 계층 (Presentation Layer)
     • 세션 계층 (Session Layer)
     • 전송 계층 (Transport Layer)
     • 네트워크 계층 (Data Link Layer)
     • 물리 계층 (Physical Layer)
3. 네트워크 현행 시스템 분석
   • 네트워크 구성도를 통해 서버 위치, 서버 간 연결 방식 파악
   • 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석
   • 물리적인 위치 관계 파악, 조직 내 보안 취약성 분석 및 대응 가능
   • 네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용

3. DBMS 현행 시스템 분석

1. DBMS(Database Management System)의 개념
   • 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램이다.
2. DBMS의 기능
   • 중복 제어
   • 접근 통제
   • 인터페이스 제공
   • 관계 표현
   • 샤딩/파티셔닝
   • 무결성 제약 조건
   • 백업 및 회복
3. DBMS 현행 시스템 분석
   • 고려사항
     • 성능 측면 : 가용성, 성능, 상호 호환성
     • 지원 측면 : 기술 지원, 구축 비용

4. 미들웨어의 현행 시스템 분석

1. 미들웨어(Middleware)의 개념
   • 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
   • 운영체제와 소프트웨어 사이에 위치
   • 대표적인 미들웨어로는 WAS
2. 웹 애플리케이션 서버 (WAS; Web Application Server)의 개념
   • 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랙잭션 처리와 관리, 다른 이 기종 시스템과의 애플리케이션 연동을 지원하는 서버
3. 미들웨어의 현행 시스템 분석
   • 고려사항
     • 성능 측면: 가용성, 성능
     • 지원 측면: 기술 지원, 구축 비용

5. 오픈 소스 사용 시 고려 사항

• 라이선스의 종류, 사용자 수, 기술의 지속 가능성 고려
• 오픈 소스 소프트웨어의 전제 조건인 자유 배포, 소스 코드 공개, 파생작업 허용, 소스 코드 일관성 확보, 차별 금지, 라이선스 배포, 포괄적 허용을 고려해야함

(2) 개발 기술 환경 요구사항 파악

1. 기술 환경 정의를 위한 자료 수집

• 온라인 트랙잭션 처리(OLTP) 시스템 : 시스템 구축 형태, 사용자 수, 트랜잭션 수
• 웹/웹 애플리케이션 서버(WEB/WAS) : 시스템 용도 및 서비스 형태, 시스템 구성 형태, 접속자 수

2. 조사 자료 분석 및 개발 기술 환경 설정

• 운영체제(OS), 데이터베이스(DBMS), 웹 애플리케이션 서버(WAS) 등 결정
• 조사 자료 분석 시 각 항목별 고려 사항을 반영하여 개발 기술 환경을 결정

3. 요구사항 정의서, 목표 시스템 구성도 반영 및 검토

• 운영체제, 데이터베이스, 웹 애플리케이션 서버 등 시스템 용량 산정 결과를 요구사항 정의서, 목표 스프트웨어 구성도, 목표 하드웨어 구성도에 반영
• 상호 검토하여 의견 제시, 반영하여 산출물을 수정하고 최종 완료.