달짱달짱

[요구사항 확인] 현행 시스템 파악 본문

정보처리기사 실기/[정리] 요구사항 확인

[요구사항 확인] 현행 시스템 파악

달콩쨩 2021. 6. 30. 15:22

I. 현행 시스템 파악 절차 

    a. 구성 / 기능 / 인터페이스 파악  

    b. 아키텍처 및 소프트웨어 구성 파악 

    c. 하드웨어 및 네트워크 구성 파악  

 

II. 소프트웨어 아키텍처 프레임 워크구성요소 : 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템 

 

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

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

    - 논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰 + 유스케이스 뷰  

 

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

    a. 계층화 패턴 : 시스템을 계층으로 구분하여 구성  

    b. 클라이언트 - 서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성  

    c. 파이프 - 필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용  

    d. 브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 이 컴포넌트 들은 원격 서비스 실행을 통해

                         상호작용 가능  

    e. 모델-뷰-컨트롤러 패턴 (MVC) : 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브시스템으로 구조화  

        ① 모델 : 핵심 기능과 데이터 보관  

        ② 뷰 : 사용자에게 정보 표시  

        ③ 컨트롤러 : 사용자로부터 요청을 입력받아 처리  

 

V.소프트웨어 아키텍처 비용 평가 모델 종류 : SAAM, ATAM, CBAM, ADR, ARID 

 

VI.디자인 패턴 : 자주 쓰이는 설계 방법을 정리한 패턴  

    a. 생성 패턴  

        ① Builder : 복잡한 인스턴스를 조립하여 만드는 구조. 생성과 표기를 분리해서 복잡한 객체를 생성 

        ② Prototype : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴

                           기존 객체를 복제함으로써 객체 생성 

        ③ Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의, 하위 클래스에서 인스턴스를

                                  생성하도록 하는 방식. 생성할 객체의 클래스를 국한하지 않고 객체를 생성 

        ④ Abstaract Factory : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는

                                     인터페이스를 제공하는 패턴. 동일한 주제의 다른 팩토리를 묶음  

        ⑤ Singleton : 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며 생성된 객체를 어디에서든지 

                          참조할 수 있도록 하는 패턴. 한 클래스에 한 객체만 존재하도록 제한  

    b. 구조 패턴 

        ① Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 

                    부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴. 구현뿐만 아니라,

                    추상화된 부분까지 변경해야 하는 경우 활용  

        ② Decorator : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴. 객체의 결합을 통해

                           기능을 동적으로 유연하게 확장  

        ③ Facade : 사용자 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 디자인 패턴.

                       통합된 인터페이스 제공 

        ④ Flyweight : ‘클래스 경량화’를 목적으로 하는 디자인 패턴. 여러 개의 가상 인스턴스를 제공하여 메모리 절감  

        ⑤ Proxy: 실체 객체에 대한 대리 객체. 특정 객체로의 접근을 제어하기 위한 용도로 사용  

        ⑥ Composite : 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴. 복합 객체와

                            단일 객체를 동일하게 취급 

        ⑧ Adapter : 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를

                         만드는 패턴  

    c. 행위 패턴  

        ① Mediator : 중재자에게 모든 것을 요구하여 통신의 빈도수를 줄여 객체지향의 목표를 달성하게 해주는 패턴.

                        상호작용의 유연한 변경을 지원 

        ② Interpreter : 언어의 다양한 해석. 구체적으로 구문을 나누고 그 분리된 구문의 해석을 맡는 클래스를 각각

                            작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴.  

        ③ Iterator : 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 패턴.  

        ④ Template Method : 상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행 

        ⑤ Observer : 일대 다의 의존성을 가지며 상호작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 패턴.

                          객체의 상태 변화에 따라 다른 객체의 상태도 연동. 일대다 의존.  

        ⑥ State : 객체 상태에 따라 행위 내용을 변경  

        ⑦ Visitor : 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 사용하는 디자인 패턴 

        ⑧ Command :실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를

                           설계하는 패턴. 요구사항을 객체로 캡슐화  

        ⑨ Strategy : 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환 

        ⑩ Memento : Undo 기능을 개발할 때 사용하는 패턴. 

        ⑪ Chain of Responsibillity : 한 요청을 2개 이상의 객체에서 처리