소프트웨어 설계 1과목-3

품질 요구사항과 UI 프로토타입

- 요구 사항 분석 기법 : 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법

 

* 개념 모델링

- 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현하는 모델을 만드는 과정

- 개념 모델은 문제의 주체인 개체들과 그들 간의 관계 및 종속성을 반영

- 종류 : 유스케이스 다이어그램, DFD, 상태 모델 등

- 모델링 표기는 UML을 사용

 

* 요구사항 할당

- 개념 모델링을 통해 식별된 구성 요소들 간에 어떻게 작용하는지 분석하는 과정

 

* 요구사항 협상

- 요구사항이 서로 충돌할 경우 이를 적절히 해결하는 과정

 

* 정형 분석

- 구문과 의미를 갖는 정형화된 언어를 이용하여 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정

 

UI 프로토타입

- 프로토타입은 사용자의 요구사항을 개발ㅈ자가 맞게 해석했는지 검증하기 위한 것으로 최대한 간단하게 만들어야함

- 일부 핵심적인 기능만을 제공하지만 최종 제품의 작동 방식을 이해시키는데 필요한 기능은 반드시 포함되어야함

- 사용자의 요구사항이 모두 반영될 때까지 프로토타입을 계속하여 개선하고 보완해야함

- 실제 사용자를 대상으로 테스트하는 것이 좋다

- 사용자를 설득하고 이해시키기 쉬우며, 요구사항과 기능의 불일치 등으로 인한 혼선을 예방할 수 있어서 개발시간을 줄일 수 있다.

- 사용자의 모든 요구사항을 반영하기 위한 반복적인 개선 및 보완 작업 때문에 작업 시간을 증가 시킬 수 있고, 필요 이상으로 자워을 소모할 수 있다.

- 부분적으로 프로토타이핑을 진행하다보면 중요한 작업이 생략될 수 있다.

 

* 프로토타입 종류

- 페이퍼 프로토타입 : 아날로그적 방법으로 스케치, 그림, 글 등을 이용해 손으로 직접 작성하는 방법

- 디지털 프로토타입 : 파워포인트, 아크로벳 등과 같은 프로그램을 사용하여 작성하는 방법

 

* UI 프로토타입 제작 단계 

1단계 : 사용자의 요구사항 분석 단계

2단계 : 요구사항을 충족하는 프로토타입을 개발하는 단계

3단계 : 작성된 프로토타입이 요구사항을 잘 수행하고 있는지 사용자가 직접 확인하는 단계

4단계 : 작성된 프로토타입을 기반으로 수정과 합의가 이뤄지는 단계

  

* 품질 요구사항 표준 지침 - ISO/IEC 9126

- 소프트웨어의 품질은 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성이다.

- ISO/IEC 9126은 소프트웨어 품질에 대한 요구사항을 기술하거나 개발 중이거나 또는 개발이 완료된 소프트웨어의 품질 평가에 사용

※ ISO/IEC 25010 : 기존 ISO/IEC 9126 품질 특성에 호환성, 보안성을 강화한 개정된 품질 평가 표준 지침

 

소프트웨어 아키텍처 

- 소프트웨어의 골격이 되는 기본 구조

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

- 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자들의 의사소통 도구로 활용됨

- 소프트웨어 아키텍처의 설계는 사용자의 기능적 요구사항, 비기능적 요구사항으로 나타난 제약조건 등을 반영하고 구현하는 방법을 찾는 해결 과정

- 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈간의 인터페이스 등을 결정

- 설계 기본 원리 : 모듈화, 추상화, 단계적 분해, 정보 은닉

 

아키텍처 패턴

- 소프트웨어 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식

- 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시

- 아키텍처 패턴에는 서브 시스템들과 그 역할이 정의되어 있으며, 서브 시스템 사이의 관계와 여러 규칙/지침이 포함되어 있다

- 아키텍처 패턴은 시행착오를 줄여 개발시간을 단축시키고 고품질의 소프트웨어를 생산할 수 있다.

- 검증된 구조로 개발하기 때문에 안정적인 개발 가능

- 이해 관계자들이 공통된 아키텍처를 공유할 수 있어서 의사소통이 간편

- 시스템의 구조를 이해하는 것이 쉬어 개발에 참여하지 않은 사람도 손쉽게 유지 보수를 수행할 수 있다.

- 시스템의 특성을 개발 전에 예측하는 것이 가능

 

* 레이어 패턴

- 시스템을 계층으로 구분하여 구성하는 방법

- 각각의 서브 시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고 하위 계층은 상위 계층의 클라이언트가 됨

- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이뤄지므로, 변경 사항 적용시에도 두 개 계층에만 영향

- 특정 계층만을 교체해 시스템을 개선하는 것이 가능

 

* 클라이언트 - 서버 패턴

- 하나의 서버와 다수의 클라이언트, 두 부분으로 구성

- 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공

- 서버는 계속 클라이언트로부터의 요청을 대기하는 상태를 유지

- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적

 

* 마스터 슬레이브 패턴

- 마스터 컴포넌트는 슬레이브 컴포넌트들로 작업을 분산시킨 후, 슬레이브가 처리한 결과값을 다시 반환 받는 방법으로 작업을 수행하는 패턴

 

* 파이프 - 필터 패턴

- 데이터 스트림을 생성하고 처리하는 각 과정은 필터 컴포넌트에서 캡슐화하여 이루어지며, 처리되는 데이터는 파이프를 통해 데이터를 전송

- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장에 용이

- 필터 컴포넌트들을 재배치하여 다양한 파이프라인 구축 가능

 

* 모델 - 뷰 - 컨트롤러 패턴

- 서브 시스템을 3개 부분으로 구조화하는 패턴

모델 : 데이터와 비즈니스 로직을 관리

뷰 : 레이아웃과 화면을 처리하여 사용자에게 정보를 표시

컨트롤러 : 뷰로부터 받은 명령을 처리

- 여러 개 뷰를 만들 수 있으므로 한 개 모델에 대해 여러 개 뷰를 필요로 하는 대화형 애플리케이션ㅇ네 적합

- 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행 가능

 

* 이벤트 - 버스 패턴

- 4가지 컴포넌트로 구성되는 패턴

- 이벤트 소스 : 이벤트를 생성

- 이벤트 리스너 : 이벤트 실행

- 채널 : 이벤트 통로

 

* 브로커 패턴 

- 사용자가 원하는 서비스와 특성을 브로커에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결

- 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합한 패턴

 

* 블랙보드 패턴

- 해결 전략이 명확하지 않은 문제 처리에 유용

- 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태로 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있다.

- 컴포넌트는 블랙보드에 추가되는 새로운 데이터 객체를 생성할 수 있다.

- 컴포넌트는 블랙보드에서 특정 종류의 데이터를 찾으며, 기존의 지식 소스와의 패턴 매칭으로 데이터를 찾음

 

* 인터프리터 패턴

- 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용

- 주로 특정 언어로 작성된 문장 혹은 표현식이라고 하는 프로그램의 각 라인을 수행하는 방법을 지정하고, 언어의 각 기호에 대해 클래스를 생성한다

 

* 피어 투 피어 패턴

- 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될수도 서비스를 제공하는 서버가 될수도 있는 패턴