7. 소프트웨어 분석 및 설계
7.1 소프트웨어 분석 및 설계의 개념
7.2 소프트웨어 설계의 기술적인 관점
7.3 소프트웨어 설계의 가이드라인
7.4 소프트웨어 설계의 품질 요소
7.5 소프트웨어 아키텍처의 필요성
7.6 소프트웨어 아키텍처의 정의 및 개념
7.7 소프트웨어 아키텍처의 문서화
7.8 소프트웨어 아키텍처의 설계과정
7.9 소프트웨어 아키텍처의 작성을 위한 관점
7.10 소프트웨어 아키텍처의 적용 대상
7.11 정리
7.12 연습문제
7.1 소프트웨어 분석 및 설계의 개념
소프트웨어 분석
(Software Analysis) 은 소프트웨어 설계의 반대 개념이다
- 소프트웨어가 수행해야 하는 목적에 맞추어
- 컴포넌트(Component) 단위로 소프트웨어를 분해하는 문제해결 기법
- 이때, 각 컴포넌트는 잘 작동하고, 컴포넌트간의 상호 연결성도 잘 작동해야 한다
- 기술적인면 보다는 비즈니스와 고객의 요구에 중점을 두고 진행한다
컴포넌트
: 개발을 수행함에 있어서 구성하는 재사용 단위를 말한다
(예) RDB 조회 수행 컴포넌트, 버튼/리스트박스, 검색 컴포넌트
Information System 개발단계 상세의 내용 중에서
- 사전탐색, 문제분석, 요구사항 분석, 제안요청 및 업체결정의 4 단계가 여기에 포함된다.
- 상세한 내용은 4장과 5장의 내용을 참고한다
소프트웨어 설계
(System Design)은
- 소프트웨어의 컴포넌트를 재조립하여
- 보다 나은 시스템을 구성하는 문제 해결 기법
- 이때, 기존 시스템과 비교해서 추가/삭제/변화된 부분이 있다
[ 소프트웨어 설계(System Design)란 ? ] Information System의 시스템 설계자가 하는 일
소프트웨어 설계는
- 소프트웨어 구현의 첫번째 단계로서
- 소프트웨어의 전체 구조를 결정하는 단계이다
- 구체적인 설계에 들어가지 전에 수행되는 과정이다
소프트웨어 설계에서 하는 일은
- 구현하고자 하는 시스템을 여러 서브 시스템으로 분할하고
- 분할된 서브 시스템 단위로 하드웨어와 소프트웨어에 대한 구현 계획을 수립하는 것이다
소프트웨어 설계는
2단계로 이루어 진다
- 기본단계(Preliminary Design) : 상위설계(High Level Design)라고 한다
: 아키텍쳐설계 + 데이터설계 + 인터페이스 설계(내부, 외부시스템간) + 사용자 화면 설계
- 상세설계(Detail Design) : 하위 설계(Low Level Design)라고 한다
: 모듈설계 + 자료구조설계 + 알고리즘 설계 + 공용 모듈 설계
7.1 소프트웨어 분석및 설계의 개념
7.2 소프트웨어 설계의 기술적인 관점
소프트웨어 설계는
-
비즈니스와 고객의 요구사항에 초점을 맞추는 소프트웨어 분석과는 달리
,
-
구현을 염두에 두고 기술적인 부분에 집중하므로 아래의
4가지 설계를 수행해야 한다
[ 소프트웨어 설계를 구성하는 4가지 설계 ] Information System 구성과 연관하여 생각할 것
데이터 설계
(Data Design) DataBase Schema 부분
: 요구사항 분석과 정보 공학 방법론의 E-R Modeling 그리고 정규화(Normalization) 자료에
기반해서 자료구조와 데이터베이스를 설계하는 것이다
구조설계
(Architectural Design) Applicaton Schema 부분
: 기능 모델링이나 동적 모델링(예: 시퀀스 다이어그램)에 표시된 결과를 기반으로
프로그램 각 모듈이나 모듈 사이의 관계를 기술하는 것이다
/
프로시져 설계
(Procedural Design) Applicaton Logic부분
: Top-Down으로 구성된 각 단위 모듈의 내부의 구현을 수행하는 단계이다
사용자 인터페이스 설계
(User Interface Design) Interface Specification & Netowrk 부분
: 시스템이 사용자에게 제공하는 화면과 화면 사이의 연계 부분을 구체화 하는 단계이다
컴포넌트
: 개발자의 관점에서 재사용 가능한 단위를 말한다
명확한 역할이 있고 독립적으로 존재가능하다
(예) Visual Basic의 Button, 은행의 이자율 계산 컴포넌트
모듈
: 프로그램 언어로 정의된 컴포넌트이다
7.2 소프트웨어 설계의 기술적인 관점
[ 소프트웨어 설계의 개념 정리 ]
기본 설계
상세 설계
데이터 설계
구조 설계
프로시저 설계
인터페이스 설계
관리적 시각
기술적 시각
Database Schema
Interface & Network
Application Logic
Application Schema
개발할
소프트웨어
7.3 소프트웨어 설계의 가이드라인
실제 구현을 목표로 관리적 요소와 기술적 요소를 동시에 고려한다
설계는
Top-Down으로 구성되며, 기능별 단위 구성 요소(=모듈)은 독자적인 기능을 수행하도록 구성해야 한다.
모듈 내부의 응집도가 높도록하고
, 모듈들 사이의 결합는 최소가 되도록 하여야 한다
모듈 사이의 계층화와 연관성를 명확히 한다
분석과 모델링 결과물에 기반하여 소프트웨어 설계가 수행되어야 한다
.
즉
, 설계는 요구사항 분석 과정의 연장선상에서 수행되어야 하며, 예측과 추정에 기반하면 안된다
기본 설계단계에서
- 전체 데이터 구조를 정의하고
- 사용자 인터페이스와 인터페이스간의 연계성를 명확히하며
- 모듈의 구분과 모듈간의 관계를 정확히 하고
- 구현에 사용할 사용자 정의 자료형의 정의(=Class)와 관련성을 규정(=상속, 인터페이스)하여야 한다
핵심 프로세스를 중심으로 상세 로직을 정의함으로써
, 나머지 부분에 대한 상세 구현의 가이드를 설정합니다
7.4 소프트웨어 설계의 품질요소
소프트웨어 설계의 평가를 위한 척도는 다음과 같다
.
기능적 독립성
(independent function) : 구현하는 각 모듈이 기능적으로 분리되어 있는지를 보는 것
결합도
(coupling) : 모듈 사이의 상호 연관성의 복잡도를 보는 것으로, 한 모듈의 수정이 다른 모듈의 수정을
요구하면 결합도가 높은 것이다
. 결합도는 적을 수록 좋다
이해도
(understandability) : 프로그램 요소의 기능을 이해하기 쉽게 한 정도. 높을 수록 좋다
소프트웨어만으로 얼만큼 이해할 수 있는지가 중요하다
(주석, 기능의 분류 및 함수/변수의 이름…)
적응도
(adaptability): 소프트웨어의 변경이 용이한 정도를 보는 것이다. 적응도가 높으려면 결합도가
낮아야 하며
, 이해도가 높아야 한다. 적응도가 높으면, 이식성(Portability)이 좋아서,
다른 곳에서 활용하기 쉽다
응집도
(cohesion) : 모듈을 구성하는 기능이 여러가지 작업을 수행하는 것이 아니고, 하나의 작업을 수행하도록
구성되어 있다면 응집도가 높은 것이다
. 즉, 하나의 모듈은 하나의 역할을 수행하도록 한다
7.4 소프트웨어 설계의 품질요소
월간
레포트 모듈
DBMS
연동 모듈
레포트
Header/
Footer
출력모듈
분기
레포트 모듈
주간
레포트 모듈
응집도
: 레포트외 다른 기능이 없다
독립성
: 다른 모듈과의 기능적 분리
결합도
: 업무 처리를 위해 연계해야 하는
다른 모듈과의 연결성이 적다
이해도
: 모듈내 소스의 가독성
적응도
: 모듈을 다른 곳에서 사용하기 쉬운 정도
(예) 월간 레포트 모듈을 인사시스템외에
생산시스템에서도 사용하고자 하는 경우
레포트모듈
결합도
7.5 소프트웨어 아키텍쳐의 필요성
고객의 요구사항
개발자의 구현과정
비즈니스 중심
구현 및 기술 중심
소프트웨어 아키텍쳐는
- 고객과 관련자
- 개발자, 디자이너
간의 의사소통을 위한
효율적인 도구이다
소프트웨어 아키텍쳐
소프트웨어 설계의 대표적인 결과물이 소프트웨어 아키텍쳐이다
.
소프트웨어 분석 과정
소프트웨어 설계 과정
7.5 소프트웨어 아키텍쳐의 필요성
요구사항 분석
시스템 요구사항 정리
개념 설계
상세
/내부 설계
구현
테스트
/인수
소프트웨어
아키텍쳐의
역할
소프트웨어 아키텍쳐는 분석기능을 하는
요구사항 분석 이후에 제작된다
시스템 개발의 각 단계별로 만들어진
내용들이 소프트웨어 아키텍쳐에 추가된다
시스템 개발에 관여하는 사람들은
소프트웨어 아키텍쳐를 통해서
개발하는 시스템의 범위
, 내용, 방향,
진행상태
, 구성 등 모든 내용을
공유하고 확인할 수 있다
프로젝트가 진행되면 소프트웨어 아키텍쳐는
관련자
(사용자, 개발자, 아키텍터…)에 의해
지속적으로 추가
/보완/생성의 과정을 거친다
프로젝트 종료시에 산출물로 고객에게
제출한다
7.6 소프트웨어 아키텍쳐의 정의 및 개념
[
정의]
프로그램이나 컴퓨팅 시스템의 소프트웨어 아키텍처는
-
소프트웨어 구성요소와
-
그들이 지니고 있는 특성 중에 외부에 드러나는 특성,
-
그리고 구성 요소들의 관계를 표현하는 시스템의 구조나 구조체를 표현한 것을 말한다
-
그리고, 아키텍쳐 설계는 아키텍쳐를 정하는 의사결정의 과정이다.
보충
아키텍처는 소프트웨어 요소를 정의한다
시스템은 하나 이상의 구조로 구성될 수 있다
소프트웨어 아키텍처는 상위 수준의 설계이며, 시스템의 전체적인 구조를 표현한다
아키텍처는 프로그램이나 시스템을 구성하는 컨포넌트 들의 구조, 그들 간의 상관 관계,
시스템 설계를 통제하고 향후 진화에 영향을 주는 원칙이며 가이드라인이다
아키텍처는 컴포넌트와 커넥터로 구성된다
[
소프트웨어 아키텍처가 중요한 이유]
• 이해 관계자의 대화 수단
• 초기 설계 결정 사항
• 타 시스템개발자와 업무 협의를 가능하게 하는 시스템의 추상화
[
아키텍처 비즈니스 사이클]
소프트웨어 아키텍처는 기술과 비즈니스, 사회적인 영향 요소의 결과물이며,
아키텍처는 기술과 비즈니스, 사회환경에 영향을 준다. 또한 이런 환경 요소들은 다시
미래의 아키텍처에 영향을 미친다. 이것을 아키텍처 비즈니스 사이클이라고 한다
: ABC (Architecture Business Cycle)
[아키텍처에 영향을 주는 요인] 정보시스템의 구조와 연결시켜 생각할 것
• 이해 관계자 : 비용, 성능, 신뢰성, 변경용의성, 운영성, …
• 개발조직 : 개발 팀의 능력, 경험
• 배경과 경험 : 아키텍처의 배경(=기술, 표준, 제품)
• 기술적 환경 : 현시스템의 환경(데이터, 프로세스, 인터페이스, 네트웍)
• 잠재적 요구사항
[소프트웨어 아키텍처 수립과 관련된 활동]
• 비즈니스 기회 창출 : 미래의 요구사항 확인
• 요구사항 이해
• 아키텍처 선택 혹은 수립
• 아키텍처 문서화와 의사 소통
• 아키텍처 분석과 평가
• 아키텍처 기반 시스템 개발 및 준수
7.6 소프트웨어 아키텍쳐의 정의 및 개념
[
좋은 아키텍처의 요건]
아키텍처는 아키텍처 팀에 의해 수립되어야 한다
아키텍처는 요구사항에 기반하여 제작되고 이해 관계자에게 배포 공유되어야 한다
아키텍처는 기능 모듈 단위로 제작되어, 상세 내용은 보이지 않아야 한다
아키텍처는 점진적으로 만들어 가는 것이며, 어느 순간 완성되어야 하는 것은 아니다
:
다양한 이해 관계자가 회의에 참석하여 발전시켜야 한다
품질 속성에 대하여 필요한 수준이 구체적으로 명시되어야 한다
- 성능 : 처리량, 반응시간, 필요하드웨어 사양
- 확장성 : 동시접속자수, 데이터의 크기
- 변경용이성
- 보안성
- 가용성 : 가동률
- 통합성 : 다른 시스템과의 통합 가능
데이터를 생성 하는 모듈과 사용하는 모듈은 분리한다
[
참고 : 아키텍쳐 품질 속성에 대한 기준의 종류 ]
-
McCall,
-
Boehm
-
HP’s FURPS(functionality, usability, reliability, performance, supportability)
-
IBM’s CUPRIMDSO(capability, usability, performance, reliability, installability, maintainability, documentation, serviceability and overall)
-
SEI(software engineering institute)’s SAiP(software architecture in practice)
등이 있다
7.6 소프트웨어 아키텍쳐의 정의 및 개념
[
아키텍쳐 제작의 기본 원리 ]
분할 및 계층화 : Top-Down으로 분할하여 단위 작업(=모듈, 컴포넌트) 수준까지 내려간다
추상화 : 관점에 맞추어 필요한 부분만을 다룬다
단순화 : 복잡함을 제거하고, 기본 기능 중심으로 다룬다( 의사 소통을 위하여)
모듈화 : 기능별로 모듈화하여 구성한다
효율화 : 필요한 자원의 효과적 이용이 가능하도록 한다
7.6 소프트웨어 아키텍쳐의 정의 및 개념
7.7 소프트웨어 아키텍쳐의 문서화
개요
시스템의 범위
시스템 기능 요구사항
논리적 모듈 구성
기술적 모듈 구성
사용되는 도구 정리
시스템의 분할
전체 시스템
1차 View(통합 View)
전체 시스템
2차 View(기능별 분할 View)
전체 시스템
3차 View(각 기능 단위별 처리 과정 View)
개발 모듈 분할
2차 View에 기반하는 PL 레벨 분할
3차 View에 기반하는 개발 인력별 분할
코딩 규칙
기본 규칙
들여쓰기 규칙
변수
, 함수명 명명 규칙
변수의 적용 범위에 따른 명명 규칙
주석 처리 규칙
개발 매뉴얼 작성 규칙
로그 시스템 사양
로그의 출력 형식
로그의 저장 형태
/위치
로그의 수준 정의
3차 view에 기반하는 로그 수준 정의
사용자 정의 자료형
자료형 리스트
& 설명
상속구성도
인터페이스 기능도
기능별 연관 클래스
Map
DB 정보
Table 연관도
DB Access 모듈 인터페이스
어플리케이션에서 사용하는 방법 정의
에러 처리 규정
인터페이스 규격
외부 인터페이스 정의 규칙
내부 인터페이스 정의 규칙
에러 처리 규정
에러처리
커버
버전 이력
목차
목차별 페이지
(페이지 형식은 현버전/페이지번호/현재목차
포함해야함
)
… 이후에 상세한 내용은 지속적으로 보완
소프트웨어 아키텍쳐가 가지는 일반적인 목차를 정리하였다
.
프로젝트 시작 후
, 요구사항 수렴이 완료되면, 관련된 문서철을 만들고, 개발을 진행하면서 지속적으로 추가/보완한다
[ 목차외 내용 ]
7.8 소프트웨어 아키텍쳐의 설계과정
설계에 따른
구체적인 목표 설정
시스템의
특성 설정
아키텍쳐 적용
아키텍쳐 표현
아키텍쳐
검토 및
개선
[ 목표설정시고려 할 요소 ]
-
실시간 처리 시스템
-
확장의 가능성
-
유지
/보수의 중요성
-
필요한 보안 수준
-
개발환경
(프레임웍, 컴포넌트)
-
요구되는 성능
-
시스템의 신뢰성
-
복구의 시간
/편리성
-
개발언어
-
데이터베이스 종류
[ 시스템 특성의 종류 ]
-
온라인 처리 시스템
-
이벤트기반 처리 방식
-
배치 처리 방식
-
변환하는 프로그램
-
데이터베이스 중심
-
트렌젝션 중심
-
프로세스 중심
[ 적용 방법 ]
-
기존의 아키텍쳐 스타일
적용
-
프로젝트에 맞는
아키텍쳐의 개발 적용
[ 표현 방법 ]
-
표준 목차에 따른 문서 형태
로 표현한다
-
데이터
,
프로세스
,
인터페이스
,
네트웍
,
모듈 구성 및 연관성
,
컴포넌트 및 배치 등
필요한 내용을 서술한다
정보시스템
(Information System)을 구축하는데 필요한 내용을 종합적으로 정리하는 과정이다
그러므로
, 정보시스템에서 제공한 관점을 기준으로 필요한 내용을 정리한다
7.8 소프트웨어 아키텍쳐의 설계과정
[(참고) 아키텍쳐를 구성하는 관점 = UML 4+1 관점]
논리적 관점
분석가
/설계자
클래스나 컴포넌트의
종류와 관계
구현 관점
프로그래머
서브시스템의
모듈구조와 관계
프로세스 관점
시스템 통합자
시스템의 성능
,
확장성
, 효율
배치 관점
시스템엔지니어
시스템의 구성
유스케이스관점
사용자
원하는 기능
7.9 소프트웨어 아키텍쳐의 작성을 위한 관점
소프트웨어 아키텍쳐는 개발하고자 하는 소프트웨어가 어떤 기능을 어떻게 수행하는지를 종합적으로 정리한 문서이다
그러므로 개발에 관련된 모든 사람들이 항상 참고하는 것이며
, 필요한 경우 추가/삭제/변경을 할 수 있다.
소프트웨어 아키텍쳐를 표현하는 관점을 정리해 보면 다음과 같다
. 주의할 점은 어느 관점만을 사용하는 것이 아니고
필요에 따라 여러 개의 관점을 고려할 수도 있다
관점
중요 역할
사례
데이터베이스
전체 시스템이 사용하는 데이터베이스에 대한
내용을 중심으로 구성하는 것이다
E-R Model 자료
테이블 상세 구성 자료
클래스 중심
객체지향의 프로그램에서 사용하는 데이터 단위인
클래스의 정의와 클래스간의 연관관계를
중심으로 서술하는 것
클래스 다이어그램‘
시퀀스 다이어 그램 외
필요한
UML 다이어 그램
GUI 중심
사용자가 사용하는 화면을 중심으로 전체 시스템을
표현하는 것
GUI 중심의 핵심 프로세스 흐름 표현
모듈구성도
프로그램을 구성하는 단위 모듈을 정의하고
,
이들간의 관계를 표현하는 것
단위 업무별
, 모듈 구성도
전체 시스템 모듈구성도
공용 컴포넌트 및
커넥터
프로그램이 사용하는 공용 또는 외부의 컴포넌트
구성과 모듈간 또는 외부와의 연결성에 대한 것을
표현하는 것
컴포넌트 정의서
모듈간
, 외부와의 커넥터 명세서
(예) DB Access 공용 컴포넌트
설치 및 운영
완성된 프로그램이 운용되는 장비
/네트웍에 대한
상세 사항을 정리하는 문서
UML 의 Deployment Diagram
7.10 소프트웨어 아키텍쳐의 적용 대상
7.10.1 소프트웨어 아키텍쳐의 종류
아키텍쳐는 구성 요소를 중심으로 바라볼수 있다
(12.9). 하지만, 사용되는 환경을 중심으로 아키텍쳐를 구분하는 것도 중요하다.
주의할 점은 하나의 시스템이 한가지 관점만을 가지는 것은 아니며
, 상황에 따라 여러 관점을 가질 수 있다
적용 대상
특징
사례
일반적인 업무용
프로그램
기능이 다양하고
, 여러 모듈로 구성되는 다양한 인터페이스가
존재하는 특징을 가진다
아키텍쳐의 구성을 위해서는
Top-Down 분할을 수행한
다음 계층별로 아키텍쳐를 구성한다
인사관리 시스템
재무관리 시스템
통신 시스템
클라이언트
/서버
프로그램
사용자 단말기와 서버간의 역할이 클라이언트
/서버의 구조를
가지는 경우이다
영업관리 시스템
인사
/재무관리 시스템
트렌잭션 프로그램
업무의 수행에 있어 여러 작업이 하나의 단위로 수행되어야
하는 경우이다
항공기예약
, 은행계좌관리
MVC(Model/View/
Control) 프로그램
웹상에서 수행되는 대용량 프로그램을 대상으로 소스코드를
Model과 View, Control에 대한 것으로 분리하여 개발,
운영하는 경우이다
회사의
ERP 시스템
이벤트 중심 프로그램
GUI를 사용하는 프로그램이 가지는 특징으로 사용자가
이벤트를 발생했을 때 작동하는 경우이다
윈도우 기반 환경의 프로그램
미들웨어 사용 프로그램
데이터의 처리를 위하여 미들웨어를 도입하여 사용하는
프로그램이다
다음 페이지에 자세히…
7.10.2 미들웨어의 종류
미들웨어는 클라이언트와 서버 사이에 존재하는 부분으로 대용량 시스템에서 주로 사용한다
미들웨어를 어떻게 사용하느냐에 따라서
2 tier, 3 tier 등으로 분류할 수 있다
( 예 : 클라이언트 – 서버 2 tier, 클라이언트 – 미들웨어 – 서버 3 tier )
미들웨어는 아키텍쳐를 정리할 때
, 전체 시스템의 구성에 중요한 영향을 미치는 요소이므로, 별도로 정리한다
통신중심 미들웨어
기술
: RPC(Remote Procedure Call), SOAP(Simple Object Access Protocol),
CORBA(Common Object Request Broker Architecture, MoM(Message oriented Mid-
dleware)
어플리케이션과 웹 중심 미들웨어
제품
: .NET, JVM(Java Virtual Machine), EJB(Enterprise Java Bean), WAS(Web Applica-
tion Server)
트렌젝션 중심 미들웨어
제품
: TP Monitor, CruzTP
비즈니스 중심 미들웨어
제품
: BizTalk, TIBCO, ActiveBPEL
통신중심 미들웨어는 제품이 아닌 기술 중심으로 서술하였다
.
7.10 소프트웨어 아키텍쳐의 적용 대상
7.11 정리
소프트웨어 아키텍쳐의 이해를 위해 현 상황을 분석해 본다
아키텍쳐를 정하기 위하여 컨설팅 회사를 선정한 것 자체가 문제이다
.
컨설팅 회사는 아키텍쳐를 구체적으로 정할 만한 전문성이 없다
. 오히려, 미래의 비전이나 새로 개발할
시스템이 갖추어야 하는 특성에 대한 컨설팅을 하였다면 적당할 것으로 생각된다
.
아키텍쳐의 작성자와 구현 담당자가 다른 회사이고 상호 이해 없이 진행한다는 것이 문제이다
.
이런 경우는
100% 구현 담당자가 이전에 작성한 아키텍쳐를 새로 작업하게 된다.
이유는 서로 사용하는 용어가 다르고
, 이 경우에는 구현 담당자가 주어진 아키텍쳐에 대하여 제대로 이해할 수 없다
요구사항의 수렴 시에 개발자의 입장에서 수렴해야 하는데
, 컨설팅 회사의 사람들이 고객과 만나서
요구사항을 수렴하게 되면
, 구체적인 사항이 정리되지 않고, 큰 방향만 정리되는 경우가 대부분이다.
방향만 정리된 요구사항을 기반으로 아키텍쳐를 작성하면
, 실제 고객의 상세한 요구가 반영되지 않고.
일반적인 형태로 제작되기 때문에
, 개발자의 관점에서 아무 의미도 없는 일이다.
아키텍쳐는 그 프로젝트의 개발자와 고객를 위하여 준비하는 것임을 명심해야 한다
.
The End of Document
