현행 시스템 분석

현행 시스템 파악

- 현행 시스템이 어떤 하위 시스템으로 구성되어있는지 등의 정보를 파악하는 활동

 : 소프트웨어 및 하드웨어 정보

 : 네트워크 구성

 : 제공 기능 등

 

- 절차

ㆍ1단계

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

ㆍ2단계

  : 아키텍쳐 및 소프트웨어 구성 파악

ㆍ3단계

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

 

 

소프트웨어 아키텍쳐

- 소프트웨어의 구성요소와 특성, 구성요소간 관계를 표현하는 시스템의 구조

 

 

소프트웨어 아키텍쳐 프레임워크

- 아키텍쳐가 표현해야하는 내용 및 이들 간의 관계를 제공하는 아키텍쳐 기술 표준

 

- 구성요소

ㆍ아키텍쳐 명세서

  : 이해 관계자들의 시스템에 대한 관점에 맞추어 작성한 뷰로 표현한 산출물

  : 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등

 

ㆍ이해관계자  : 시스템 개발에 관련된 모든 사람과 조직

 

ㆍ관심사

  : 이해관계자들의 의견과 목표

  : 사용자 입장 / 유지보수자 입장 / 개발자 입장

 

ㆍ관점

  : 개별 뷰를 개발할때 토대가 되는 양식

  : 이해관계자들의 관점

 

ㆍ뷰  : 관련있는 관심사들의 집합의 관점에서 전체 시스템 표현

 

ㆍ근거  : 아키텍쳐 결정 근거 (회의 결과, 보고 결과)

ㆍ목표

ㆍ환경

ㆍ시스템

 

 

 

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

- 고객의 요구사항 기반의 시나리오를 바라보는 4개 관점의 접근 방법

 : 체크방법으로 유스케이스 사용

 

- 뷰

ㆍ유스케이스 뷰

  : 유스케이스 또는 아키텍쳐를 도출하고 다른 뷰를 검증

  : 사용자 / 설계자 / 개발자 / 테스트 관점

 

ㆍ논리 뷰

  : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명

  : 설계자 / 개발자 관점

 

ㆍ프로세스 뷰

  : 시스템의 비기능적인 속성 (자원의 효율성 / 병행실행 / 비동기 / 이벤트 처리 등)

  : 개발자 / 시스템 통합자 관점 

 

ㆍ구현 뷰

  : 개발 환경 안에서 정작인 소프트웨어 모듈의 구성을 표현

  : 컴포넌트 구조와 의존성 및 컴포넌트에 관한 부가적인 정보 정의

 

ㆍ배포 뷰

  : 컴포넌트가 물리적인 아키텍쳐에 어떻게 배치되는가를 매핑해서 표시

 

 

 

소프트웨어 아키텍쳐 패턴

- 소프트웨어를 설께할 때 참조할 수 있는 전형적인 해결방식

 

- 패턴유형

ㆍ계층화 패턴

ㆍ클라이언트-서버 패턴

ㆍ파이프-필터 패턴

ㆍ브로커 패턴

ㆍ모델-뷰-컨트롤러 패턴 (MVC)

 

 

 

계층화 패턴

- 시스템을 계층으로 구분하여 구성하는 패턴

 

 

클라이언트-서버 패턴

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

 

 

파이프-필터 패턴

- 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴

 : 서브 시스템이 입력 데이터를 받아 처리하고 다음 서브 시스템으로 넘겨주는 과정 반복

 : 재사용성이 좋고 추가가 쉬워 확장이 용이

 

 

 

브로커 패턴

- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되는 패턴

 : 브로커 컴포넌트를 통해 컴포넌트간 통신

 : 참조 (2mukee.tistory.com/123)

 

 

 

모델-뷰-컨트롤러 패턴 (MVC 패턴)

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

 : 높은 재사용성과 컴포넌트의 독립성

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

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

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

 

 

 

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

- 아키텍쳐 접근법이 품질 속성에 미치는 영향과 아키텍쳐의 적합성을 평가

- 종류

ㆍSAAM : 변경 용이성 / 기능성 / 평가 용이성 / 무경험 조직 활용 가능

ㆍATAM : 아키텍쳐 품질 속성 만족에 대해 판단 및 품질 속성들의 이해 삭충 관계 평가

ㆍCBAM : ATAM 바탕으로 경제적 의사결정 요구 충족

ㆍADR : 소프트웨어 아키텍쳐 구성요소간 응집도 평가

ㆍARID : 특정 부분에 대한 품질요소에 집중

 

 

 

디자인 패턴

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

- 구성요소

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

- 유형

ㆍ생성 : 객체 인스턴스 생성에 관여 (클래스 정의 / 객체 생성 방식 구조화 / 캡슐화)

ㆍ구조 : 더 큰 구조 형성을 목적으로 클래스나 객체의 조합을 다룸

ㆍ행위 : 클래스나 객체들의 상호작용 방법과 역할 분담

ㆍ클래스 : 클래스간 관련성 (컴파일 타임에 정적으로 결정)

ㆍ객체 : 객체간 관련성 (런타임에 동적으로 결정)

 

 

 

생성 패턴

- Builder : 복합객체 생성 관련

- Prototype : 원형을 만들고 복사하여 필요한 부분만 수정해서 사용

- Factory Method : 상위 클래스의 인터페이스 정의하고 하위 클래스 인스턴스를 생성하는 방식

- Abstract Factory : 구체적인 클래스에 의존하지 않고 서로 연관된 객체를 조합하는 인터페이스 제공

- Singleton : 전역 변수를 사용하지않고 하나의 객체로 어디든 참조

 

 

 

구조 패턴

- Bridge : 기능의 클래스 계층과 구현의 클래스 계층 연결

- Decorator : 기존 클래스에 필요한 기능을 추가해 나가는 설계 패턴

- Facade : 복잡한 시스템에 대해 단순한 인터페이스 제공

- Flyweight : 클래스의 경량화

- Proxy : 실제 객체애 대한 대리 객체

- Composite : 객체간 관계를 트리구조로 구성

- Adapter : 클래스 재사용을 위해 중간에서 맞춰주는 역할의 인터페이스 생성

 

 

 

행위 패턴

- Mediator : 중재자를 두어 통신의 빈도수 감소

- Interpreter : 언어와 구문의 해석

- Iterator : 컬렉션 구현 방법을 노출시키지 않으면서 접근 방법 제공

- Template Method : 상위 클래스의 추상메서드를 통해 기능 골격 제공 / 하위 클래스 메서드에 대해 세부처리 구체화 

- Observer : 한 객체의 상태가 바뀔때 연관 객체에 연락이 가고 자동으로 내용 갱신

- State : 객체 상태를 캡슐화하여 클래스화

- Visitor : 각 클래스 데이터 구조로 부터 처리기능 분리

- Command : 실행될 기능을 캡슐화

- Strategy : 알고리즘 군 정의(추상클래스) / 같은 알고리즘을 각각 하나의 클래스로 캡슐화 / 필요할때 교환해서 사용

- Memento : Undo기능 개발 시 사용

- Chain of Responsibillity : 하드코딩 되어있는 처리 연결을 동적으로 변경

 

 

 

현행시스템 분석

- 취득자료

ㆍ정보시스템 구성 현황 / 정보시스템 기능 구성도 / 인터페이스 현황

ㆍ현행 시스템 아키텍쳐 구성도 / 소프트웨어 구성도

ㆍ하드웨어 구성도 / 네트워크 구성도

 

 

개발 기술 환경 정의

- 운영체제 

 : 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 인터페이스를 제공하는 프로그램

 : 품질측면과 지원 측면 분석

ㆍ품질측면 : 신뢰도 / 성능

ㆍ지원측면 : 기술지원 / 주변기기 / 구축비용

 

- 네트워크

 : 컴퓨터 장치들의 노드간 연결(데이터링크)를 이용하여 서로에게 데이터를 교환할 수 있도록 하는 기술

 : 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석

ㆍOSI 7계층

 

- DBMS

 : 데이터베이스라는 데이터의 집합을 만들고 저장 및 관리할 수 있는 기능들을 제공하는 응용프로그램

 : 가용성, 성능, 기술 지원, 호환성, 구축비용을 분석

 

- 미들웨어

 : 분산 컴퓨팅 환경에서 응용 프로그램과 환경간 원만한 통신을 위해 제어하는 소프트웨어

 : 가용성, 성능, 기술지원, 구축비용을 분석

ㆍWAS