1. 현행 시스템 파악
1) 현행 시스템 파악 개념
현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 연계 정보는 무엇이며, 어떤 기술 요소를 사용하는지, 사용하는 소프트웨어 및 하드웨어는 무엇인지, 네트워크 구성은 어떻게 되어있는지 에 대해 파악하는 활동
2) 현행 시스템 파악 절차
- 구성/기능/인터페이스 파악
- 아키텍처 및 소프트웨어 구성파악
- 하드웨어 및 네트워크 구성 파악
3) 소프트웨어 아키텍처
1. 개념
여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체
2. 소프트웨어 아키텍처 프레임워크
소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준
3. 소프트웨어 아키텍처 4+1 뷰
- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 접근
1: 유스케이수 뷰 - 설계하며 다른 뷰를 검증하는데 사용되는
4: 논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰
유스케이스 뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용하는 뷰
논리 뷰: 시스템의 기능적 요구사항이 어떻게 제공되는지 설명해주는 뷰
프로세스 뷰: 시스템의 비기능적 속성으로서 자원의 효율적 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
구현 뷰: 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
배포 뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰
4. 소프트웨어 아키텍처 패턴
개념:
소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식으로, 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션
패턴 유형
Layered Pattern:
- System을 계층으로 구분하여 구성하는 패턴
- 각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공
- 서로 마주보는 두 개의 계층 사이에서만 상호 작용이 이루어짐
Client-Server Pattern:
- 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면, 서버는 클라이언트에게 서비스를 제공
- 서버는 계속 클라이언트로부터 요청을 대기
Pipe-Filter Pattern:
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능한 패턴
- 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복
- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장에 용이
Broker Pattern:
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포턴트들은 원격 서비스 실행을 통해 상호 작용이 가능한 패턴
- 브로커 컴포넌트는 컴포넌트 간의 통신을 조정하는 역할 수행
- 서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주며(Publish), 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 Redirection 함.
MVC(Model View Controller Pattern):
Model: 핵심 기능과 데이터 보관
View: 사용자에게 정보 표시(하나 이상의 뷰가 정의될 수 있음)
Controller: 사용자로부터 요청을 입력받아 처리
- 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고, 개발 작업 수행 가능
- 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 여러 개의 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합
5. 소프트웨어 아키텍처 비용 평가 모델
1. 개념:
아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
2. 종류:
SAAM:
- Software Architecture Analysis Method
- 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델
ATAM: - Architecture Trade-off Analysis Method
- 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델
CBAM: - Cost Benefit Analysis Method
- ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델
ADR: - Active Design Review
- 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델
ARID: - Active Reviews for Intermediate Designs
- 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델
4) 디자인 패턴
1. 개념: 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
2. 패턴 구성요소:
[패턴 이름][문제 및 배경] [솔루션][사례] [결과][샘플 코드]
3. 패턴 유형
생성 / 구조 / 행위
4. 디자인 패턴 종류
"생성" 패턴
[Builder]
- 복잡한 인스턴스를 조립해 만드는 구조
- 복합 객체 생성 시: 객체를 생성하는 방법(과정) / 객체를 구현(표현)하는 방법을 분리 = 동일한 생성 절차에서 서로 다른 표현 결과 만드는 디자인 패턴
- 생성 / 표기를 분리해 복잡한 객체를 생성
[Prototype]
- 처음부터 일반적인 원형을 만들고, 그것을 복사 후 필요한 부분만 수정하여 사용하는 패턴
- 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정
- 객체를 생성 시, 갖추어야 할 기본 형태가 있을 때 사용하는 디자인 패턴
- 기존 객체를 복제함으로써 객체를 생성
[Factory Method]
- 상위 클래스: 객체를 생성하는 인터페이스 정의
- 하위 클래스: 인스턴스를 생성
- 하위 클래스에서 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 디자인 패턴
[Abstract Factory]
- 구체적 클래스에 의존하지 않고, 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
- 이를 통해 생성된 클래스에서는 사용자에게 인터페이스(API)를 제공하고, 구체적인 구현은 Concrete Product 클래스에서 이루어지는 특징을 갖는 디자인 패턴
- 동일한 주제의 다른 팩토리를 묶음
[Singleton]
- 전역 변수 사용 X
- 객체를 하나만 생성하도록 하고, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
- 한 클래스에 한 객체만 존재하도록 제한
"구조" 패턴
[Bridge]
- 기능의 클래스 계층 + 구현의 클래스 계층을 연결
- 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴
- 구현뿐만 아니라, 추상화된 부분까지 변경해야 하는 경우 활용
[Decorator]
- 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
- 기능 확장이 필요할 때 객체 간의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주어 상속의 대안으로 사용하는 디자인 패턴
[Facade]
- 복잡한 시스템 -> 단순한 인터페이스로
- 사용자와 시스템 간, 여타 시스템과의 결합도를 낮춤
- 시스템 구조에 대한 파악을 쉽게 하는 패턴
- 사용자의 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 디자인 패턴
- 통합된 인터페이스 제공
[Flyweight]
- 다수의 객체로 생성될 경우 모두가 갖는 본질적 요소를 클래스화
- 그 클래스를 공유하여 메모리를 절약하고, '클래스의 경량화'를 목적으로 하는 디자인 패턴
- 여러 '가상 인스턴스'를 제공하여 메모리 절감
[Proxy]
- '실체 객체에 대한 대리 객체'로 실체 객체에 대한 접근 이전에 필요한 행동을 취할 수 있게 함
- 이를 통해 미리 할당하지 않아도 상관없는 것들을, 실제 이용할 때 할당 -> 메모리 용량 절약
- 실제 객체를 드러나지 않게 하여 정보은닉의 역할도 수행하는 디자인 패턴
- 특정 객체로의 접근을 제어하기 위한 용도
[Composite]
- 객체의 관계 트리구조: 부분-전체 계층을 표현
- 사용자가 단일 객체, 복합 객체 모두 동일하게 다룸
- 복합 객체와 단일 객체 동일 취급
[Adapter]
- 기존의 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴
- 상속을 이용하는 클래스 패턴 / 위임을 이용하는 인스턴스 패턴
- 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스 + 기존 인터페이스에 덧씌움
"행위" 패턴
[Mediator]
- 객체 지향 설계 시 객체의 수가 너무 많아지면 복잡 -> 객체지향에서 중요한 '느슨한 결합' 특성 해침
- 이를 해결하기 위해 중간에 이를 통제하고 지시할 수 있는 역할을 하는 중재자를 둠
- 중재자에게 모든 것을 요구 -> 통신의 빈도수를 줄임
- 상호 작용의 유연한 변경 지원
[Interpreter]
- 언어의 다양한 해석, 구체적으로 구문을 나누고 분리된 구문의 해석을 맡은 클래스를 각각 작성하여 여러 형태의 언어 구문을 해석할 수 있게 만드는 디자인 패턴
- 문법 자체를 캡슐화하여 사용
[Iterator]
- collection 구현 방법을 노출시키지 않고 그 집합체 안에 들어있는 모든 항목에 반복자(iterator)를 사용하여 접근할 수 있는 디자인 패턴
- 내부 구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 행위 패턴
[Template Method]
- 서브 클래스 = 캡슐화
- 전체 일 수행하는 구조는 변화 X, 특정 단계 수행하는 내역은 변화
- 상위 클래스(추상 클래스) - 추상 메서드로 기능의 골격 제공
- 하위 클래스(구체 클래스) - 메서드의 세부 처리를 구체화
- 코드 양 줄이고, 유지보수 용이
[Observer]
- 객체 A 상태 변화 -> A 사용 중인 객체들에 연락, 자동 갱신: 일대 다의 의존성
- 상호작용하는 객체 사이는 느슨하게 결합
[State]
- 객체 상태 캡슐화 -> 클래스화 -> 참조
- 객체 상태에 따른 변경 시 원시 코드의 수정 최소화, 유지보수 편의성
[Visitor]
- 각 클래스 Data 구조에서 처리 기능 분리 -> 별도의 클래스 만들기
- 클래스의 메서드가 각 클래스 돌아다니며 특정 작업 수행
- 객체의 구조는 변경하지 않으나 기능만 추가, 확장
[Command]
- 실행될 기능(요구사항) -> 캡슐화, 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스 설계
- 명령이 들어오면 하나의 추상 클래스에 맞는 서브 클래스가 선택되어 실행
[Strategy]
- 알고리즘 군 = 추상클래스로 정의
- 같은 알고리즘 = 하나의 클래스로 캡슐화 -> 동적으로 행위 자유롭게 변환
[Memento]
- 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때, 적용하는 디자인 패턴
- Undo 기능을 개발할 때 사용
[Chain of Responsibility]
- 동적 연결되어 있는 어떤 기능에 대한 처리 요청을 2개 이상의 객체에서 처리
2. 요구사항
1) 개요
요구사항의 분류:
기능적: 시스템이 제공하는 기능
비기능적: 시스템이 수행하는 기능 외의 사항(시스템 구축에 대한 제약사항에 관한 요구사항)
비기능적 요구사항의 예시: 특정 함수의 호출시간은 3초를 넘지 않아야 한다 / 시스템은 운영되는 중에 패치 및 업그레이드를 할 수 있어야 한다 / 시스ㅔㅁ은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 한다.
2) 요구공학 프로세스
과정:
도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)
1. 도출 단계: Interview, Brainstorming, Delphi Method(전문가의 경험적 지식을 통한 문제해결), Role Playing, Workshop, Survey
2. 분석 단계
DFD(Data Flow Diagram)
DD(Data Dictionary)
UML(Unified Modeling Language)
3. 명세 단계
비정형 명세 기법: 사용자 요구 표현을 '자연어' 기반을 서술
정형 명세 기법: 수학적 원리오 ㅏ표기법으로 서술(Z-스키마/Petri Nets/상태차트)
명세 단계의 산출물 : !!요구사항 명세서!!
4. 확인 및 검증 단계
Validation: 확인
Verification: 검증
주요 기법
Peer Review
Walk Through
Inspection: 저작자 외 다른 전문가 또는 팀이 검사
5. 요구사항 관리
요구사항 협상 ->
기준선 설정(형상관리) ->
변경관리(형상통제 위원회) ->
요구사항 확인 및 검증
