[정보처리기사 실기] 1-2. 요구사항 확인_ 현행 시스템 분석

말하는 감자·2024년 12월 23일
실기정보처리기사
0

정보처리기사 실기

목록 보기
2/29
post-thumbnail

요구사항 확인 - 현생 시스템 분석

1. 현행 시스템 분석

현행 시스템 파악

현행 시스템 파악 절차

구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악

  • 구기인 소아 하네

소프트웨어 아키텍처

소프트웨어 아키텍처 개념

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.

소프트웨어 아키텍처 프레임워크 구성요소 해석

1. 1..*: 1개 이상

2. 0..1: 0 또는 1

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

1. 개념

: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

2. 구성요소

  1. 유스케이 뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는 데 사용되는 뷰
    • 사용자, 설계자, 개발자, 테스트 관점
  2. 논리 뷰: 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
    • 설계자, 개발자 관점
  3. 프로세스 뷰: 시스템의 비기능적인 속성으로서 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
    • 개발자, 시스템 통합자 관점
  4. 구현 뷰: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
  5. 배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는지를 매핑해서 보여주는 뷰

3. 소프트웨어 아키텍처 패턴 유형

  1. 계층화 패턴: 시스템을 계층으로 구분하여 구성하는 패턴
  2. 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트로 구성된 패턴
  3. 파이프-필터 패턴: 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
  4. 브로커 패턴: 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되ㄱ, 이 컴포넌트들은 원격 서비스 실행을 통해 상호작용이 가능한 패턴
  5. 모델-뷰-컨트롤러 패턴: MVC 패턴이라고도 하고 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴, 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행한다.

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

소프트웨어 아키텍처 비용 평가 모델 개념

: 소프트웨어 아키텍처 비용 평가 모델은 아키텍처 접근법이 품질 속성에 따르는 영향을 판단하고 적합성을 평가하는 모델

소프트웨어 아키텍처 비용 평가 모델 종류

  1. SAAM: 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
  2. ATAM: 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
  3. CBAM: ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족시키는 비용 평가 모델
  4. ADR: 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
  5. ARID: 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델
  • SACAA
    =사카린

디자인 패턴

디자인 패턴 개념

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

  • 디자인 패턴을 참고하여 개발하면 개발의 효율성과 유지보수성, 운용성이 높아지며 최적화에 도움이 된다.

디자인 패턴 유형

  1. 목적: 생성 구조 행위
  2. 범위: 클래스, 객체
    • 생선구이를 먹으면 행복하다
      =생구행

디자인 패턴 종류

생성 패턴

  1. Builder
    : 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함 으로써 동일한 생성절차에서 서로 다른 표현 결과를 만들 수 있다.
  2. Prototype
    : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정한다.
  3. Factory Method
    : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에 오버로딩하여 생성한다.
  4. Abstract Factory
    : 구체적인 클래스에 의존하지 않고 서로 연관된 객체들의 조합을 만드는 인터페이스를 제공하는 패턴이며 사용자들에게 인터페이스를 제공하고 구체적인 구현은 Concrete Product 클래스에서 이루어지는 특징을 갖는 디자인 패턴
  5. Singleton
    : 전역변수를 사용하지 않고 객체를 하나만 생성하고, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
    • 생빌 프로 팩앱싱
      = 생성(빌더/프로토타입/팩토리메서드/앱스트랙트/싱글톤)

구조 패턴

  1. Bridge
    : 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화 되 부분과 실제 구현 부분을 독립적으로 확장 할 수 있는 디자인 패턴
  2. Decorator
    : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
  3. Facade
    : 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 간의 결합도 낮춤
  4. Flyweight
    : 다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스화 하고 클래스 경량화 목적
  5. Proxy
    : 실제 객체에 대한 대리 객체, 정보 은닉 역할
  6. Composite
    : 트리구조로 객체 관계 표현
  7. Adapter
    : 호환되지 않는 기존 클래스를 재사용 할 수 있게 중간에서 맞춰주는 역할
    • 구부데패플프컴어
      구조:브릿지,데코레이터,패케이드,플라이웨이트,프록시,컴포지트,어댑터

행위 패턴

  1. Mediator
    : 느슨한 결합의 특성을 유지하기 위해 이를 통제하고 지시하는 역할인 중재자를 두는 패턴
  2. Interpreter
    : 언어의 다양한 해석, 구체적인 구문을 나누고 나눈 구문의 해석을 맡는 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 디자인 패턴, 문법 자체를 캡슐화하여 사용
  3. Iterator
    : 집합체 안에 들어있는 모든 항목에 순차적으로 접근 할 방법을 제공하는 패턴
  4. Template Method
    : 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴, 서브 클래스로 작업의 일부분을 수행
  5. Observer
    : 한 객체의 상태가 바뀌면 그 객체에 의존하는 일대 다 관계의 다른 객체에 연락이 가고 자동으로 내용이 갱신
  6. State
    : 객체 상태를 캡슐화하여 클래스화 함으로써 그것을 참조하게 하는 방식
  7. Visitor
    : 데이터 구조로부터 처리 기능을 분리하여 별도의 클래스를 만들어놓고, 해당 클래스의 메소드가 각 클래스를 돌아다니며 특정 작업을 수행
  8. Command
    : 하나의 추상 클래스에 메소드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징, 요구사항을 객체로 캡슐화 함
  9. Strategy
    알고리즘을 정의하고 캡슐화하여 필요할 때 서로 교환하며 사용, 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환
  10. Memento
    : 클래스 설계 시 객체 정보를 저장할 때 적용하는 디자인 패턴. #Undo 기능 개발시 사용
  11. Chain of Responsibility 책임연쇄 패턴
    : 정적으로 연결되어 있을 때, 하드코딩 되어 연결변경이 불가능 한데, 이것을 동적으로 연결되어 있는 경우에 따라 다르게 처리되게 함

2. 개발 기술 환경 정의

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

운영체제 현행 시스템 분석

운영체제의 개념

: 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램.

네트워크 현행 시스템 분석

OSI 7계층

  1. Physical(물리) 계층
  • 기능: 비트 전송, 전기적 신호화 물리적 매체간의 변환
  • 장치: 허브, 리피터
  1. Datalink(데이터링크) 계층
  • 기능: 프레임 전달, 에러 탐지 및 수정, 물리적 주소 지정
  • 장치: 스위치, 브리지
  1. Network(네트워크) 계층
  • 기능: 패킷 전달, 경로 선택, 논리적 주소 지정(IP)
  • 장치: 라우터, 게이트웨이
  1. Transport(전송) 계층
  • 기능: 데이터 전송의 신뢰성 제공, 흐름제어와 혼잡 제어
  • 장치: TCP(세그먼트 전송), UDP(데이터그램 전송) 프로토콜
  1. Session(세션) 계층
  • 기능: 세션 설정, 유지 및 종료, 동기화
  • 장치: API
  1. Presentation(표현) 계층
  • 기능: 데이터 변환, 암호화, 압축
  1. Application(응용) 계층
  • 기능: 사용자 인터페이스 제공, 애플리케이션 프로토콜 처리
  • 장치: 서버(웹,FTP,SMTP 등)

DBMS 현행 시스템 분석

  1. 가용성
    : 장기간 시스템 운영할 때 장애 발생 가능성
  2. 성능
    : 대규모 데이터 처리 성능
  3. 상호 호환성
    : 설치 가능한 운영체제 종류
  4. 기술 지원
    : 공급 업체들의 안정적인 기술 지원 여부
  5. 구축 비용
    : 유지 및 관리 비용
    • 가성비기호

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

미들웨어 개념

: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간 통신을 원만하게 하기 위한 소프트웨어

profile
말하는 감자
주니어개발자(?)
이전 포스트

[정보처리기사 실기] 1-1.요구사항 확인_소프트웨어 개발방법론

다음 포스트

[정보처리기사 실기] 1-3. 요구사항 확인_요구사항 확인

0개의 댓글