소프트웨어 설계

아키텍쳐 설계

소프트웨어 아키텍처 설계 개념

• 요구분석 이후 구현을 위한 설계의 단계에서 첫 번째 수행은 아키텍처를 설계하는 것

아키텍처 설계 (Architectural Design)

• 아키텍처는 각각의 서비스를 제공하는 서브시스템과 이 서브시스템들을 제어하고 통신을 위하여 어떠한 일들을 하여야 하는 것

아키텍처를 명세화(설계)해야 하는 이유

• 관련자와의 의사소통 도구

  • 시스템 관련자(System Stakeholders)와 의견을 교환하는데 사용함.

• 시스템을 분석하는 도구

  • 요건 등이 적용가능한지 시스템을 분석하는데 사용함.

• 대단위 시스템에서 재사용 활용

  • 대단위 시스템에서 중복 구현 없이 서브시스템이나 모듈 등을 재사용하기 위하여 판단하는데 유용함.

아키텍처 설계 시 고려하여야 할 사항 - 성능

1. 성능(Performance)

   • 중요한 오퍼레이션은 내부에서 처리하고, 통신은 최소화함.
   • 잘게 쪼개진 컴포넌트보다는 보다 큰 구성요소로 성능을 높임.

2. 보안성(Security)

   • 내부 계층 안에 주요자산들을 위치시키는 계층적 아키텍처를 사용함.

3. 안전성(Safety)

   • 안전이 필요한 중요기능은 내부에 위치시키며, 서브시스템은 작게 유지함.

4. 가용성(Availiability)

   • 장애 등에 대비하기 위하여 컴포넌트나 메커니즘의 중복적 구현이 되어 있어야 함

5. 유지보수성(Maintainability)

   • 세분화 되어 교체 가능한 컴포넌트를 사용하여야 함

아키텍처 설계 시 고려하여야 할 사항 - 사고

1. 참고 아키텍처

   • 설계중인 시스템을 위한 템플렛으로서 작동할 수 있는 일반 응용 시스템의 아키텍처가 존재하는가?

2. 분산 프로세스

   • 시스템이 다수의 프로세서로 어떻게 분산될 것인가?

3. 아키텍처 스타일

   • 시스템에 적절한 아키텍처 스타일은 무엇인가?

4. 시스템구성 접근법

   • 시스템을 구성하는데 이용되는 기본적인 접근법은 무엇이 될 것인가?

5. 모듈분해

   • 시스템에서 구성 단위가 모듈들로 어떻게 분해될 것인가?

6. 제어

   • 시스템에서 구성 단위들의 오퍼레이션을 제어하기 위해 어떤 전략이 사용될 것인가?

7. 설계평가

   • 아키텍처의 설계를 어떻게 평가할 것인가?

8. 문서화

   • 시스템의 아키텍처를 어떻게 문서화 할 것인가?

아키텍처 설계 시 고려하여야 할 사항을 참고하여 아키텍처를 설계하고
설계물을 결정 후 구현에 나서게 됨.

가장 중요한 일은 참고할 만한 아키텍처 모델을 조사한 후 전부 또는
일부분을 템플릿으로 활용하고 본인에 맞게 변형하여 아키텍처를 설계해야 함.

시스템 구성방법에 따른 아키텍처 모델

저장소 모델 (Repository Model)

• 중앙에 집중된 공유 데이터 베이스를 기반으로 하는 시스템 모델

• ex) Mainframe 체계의 시스템

• 장점

  • 다량의 데이터를 공유하는데 효과적임
  • 백업, 보안, 접근제어, 오류 등을 중앙집중적으로 통제가능 함.

• 단점

  • 데이터가 중앙 집중되어 있기 때문에 임시적으로 중요치 않은 데이터도 중앙에 모여 저장되어져야 함.
  • 시스템의 유연성을 떨어지기 때문에 한 단위 모듈을 수정 보안하는 작업도 전체 시스템의 영향을 줄 수 있음.

Client / Server 모델

• 서비스와 서버 그리고 클라이언트의 집합으로 구성되는 시스템 모델

• ex) 웹 시스템 등

• 장점

  • 분산아키텍처로 분산된 프로세스와 네트워크의 이점을 이용할 수 있음

• 단점

  • 데이터의 중복, 불일치를 처리해야 하는 복잡성이 있음

계층적 모델 (Layered Model)

• 시스템을 계층적으로 구성하는 시스템 모델

• ex) 형상관리 시스템 계층 - 객체관리 시스템 계층 - 데이터베이스 시스템계층 - 운영체계계층으로 시스템을 나누어 보는 체계

• 장점

  • 시스템을 점증적으로 개발할 수 있음.

• 단점

  • 시스템을 정확히 어떤 계층으로 확실히 분리할 수 있는지, 모든 계층들을 합하였을 때 전체가 되는지를 고려해야 함.

객체지향 분해 (Object-Oriented Decomposition)

• 시스템을 계층적으로 구성하는 시스템 모델

• 청구서의 처리 시스템을 나타낸 객체모델

  • Customer : 고객
  • Payment : 대금지급
  • Invoice : 청구서
  • Receipt : 영수증

• 위에 제시된 모델은 전체 시스템을 데이터와 기능(function)이 묶여 있는 객체로 나타내고 이를 연결하는 과정

• 청구서라는 객체는 일자(Date), 금액(Amount), 고객(Customer)의 데이터 뿐만 아니라 처리(Issue()),
  독촉장발행(SendReminder())등등 해야할 일의 함수도 포함하고 있음
  

기능지향 파이프라이닝 (Function-Oriented Pipelining)

• 시스템을 입력데이터를 받아 출력데이터가 나오는 형태로 표현하는 모델

• 청구서의 처리 시스템을 나타낸 기능지향 파이프라이닝 모델

  • 청구서 / 청구서 판독
  • 대급 지급 / 대급 지급 인식
  • 영수증 발급 / 영수증
  • 대금지급기한 인식 / 대금지급 독촉장 발행 / 독촉장

• 화살표를 따라가 보면 업무의 흐름을 할 수 있으며 각각의 단위는 하나의 기능임을 알 수 있음.

중앙집중제어 (Centralized Control)

• 한 서브 시스템이 제어의 전체적인 책임을 지고 다른 서브시스템을 시작하거나 종료시키는 체계

• 제어를 다른 서브시스템에 넘길 수 있지만, 이 제어의 책임은 자신이 가지고 있어야 함.

• 실시간 시스템을 위한 중앙 집중 제어 모델

  • 센서처리기
  • 반응처리기
  • 시스템제어기
  • 계산처리기
  • 사용자 인터페이스
  • 장애처리기

• 모든 처리프로세스들은 시스템 제어기의 중앙 집중제어를 통하여 움직이거나 반응하는 구조임.

이벤트기반 제어 (Event-Based Control)

• 제어정보가 서브시스템에 내장되기 보다는 각 서브 시스템이 외부적으로 생성되는 이벤트에 반응을 할 수 있도록 설계된 모델

• 이러한 이벤트들은 다른 서브시스템이나, 시스템의 환경 등에서도 발생할 수 있음.

• 어떤 이벤트(여기서는 제어이벤트 신호인 인터럽트)가 발생하면 해당 이벤트가 전달되어야 되는 주소 등이 인터럽트 벡터를 참고하고
  해당 이벤트들은 목적지 프로세스를 잠시 정지하여 컨트롤 할 수 있는 해당 프로세스의 핸들러에게 전달됨
  

• 이벤트를 받은 핸들러는 자기의 프로세스에게 해당 이벤트를 처리하도록 전달함.

응용 시스템 아키텍처

데이터 처리 시스템

• 응용 시스템의 관점에서 아키텍처 구분 시

  • 데이터처리, 트렌젝션의 처리, 이벤트 처리, 언어처리 시스템 분류함.

• 데이터처리 응용 시스템은 데이터의 처리 관리를 중점으로 다룸.

• 급여, 과금, 회계 같은 광범위한 분야에서 활용되는 시스템

트렌젝션 처리 시스템

• 정보에 대한 요청에 대하여 처리하고, 정보를 갱신 하는 등 실시간 트렌젝션 처리 중심 응용 시스템

  • 대화식 은행 시스템
  • 정보시스템
  • 전자상거래 시스템
  • 예약시스템

• Web Browser <=> Web Server <=> Application Server <=> Database Server

• 웹 브라우저는 웹 서버에 접속함

• 웹 서버는 어플리케이션 서버에게 어떠한 처리를 요청함.

• 어플리케이션 서버는 웹 서버로부터 받은 요청을 데이터 베이스를 호출하여 처리한 후 응답을 웹 서버에게 보냄.

• 웹 서버는 어플리케이션 서버에서 보내온 응답을 웹 페이지로 변경하여 웹 브라우저에게 전달함.

이벤트 처리 시스템

• 이벤트를 해석하고 처리하는 방식의 시스템

  • PC기반의 응용 시스템 (마우스 감지, 키보드 감지)
  • 실시간 시스템 (주식매매, 레이더 탐지)

• 항상 키보드의 입력이벤트를 받고 있음.

• 키보드나 마우스의 입력에 따라 이 입력이 글자를 쓰는 데이터(Editor Data)인지 명령인지,
  부수적인(Ancillary) 데이터인지 부수적인 명령인지를 판단하고 번역(Interpret)함.
  

• 해당 이벤트가 명령이면 명령에 맞는 작업들을 수행함.

• 해당 이벤트(키 입력)가 글자를 쓰는 작업이면 끊임없이 화면을 다시 보여주는 작업을 계속 수행함.

언어 처리 시스템

• 프로그램언어의 처리 등을 하는 시스템으로 단순히 프로그래밍 언어뿐만 아니라,
  HTML이나 XML같은 언어를 처리하는 브라우저 시스템도 이에 해당함.
  

• 컴파일러는 맨 처음 코딩된 코드의 어휘(낱개 단어)를 먼저 분석(Lexical Analysis)함.

  • 분석 시 심볼테이블(Symbol Table)을 참고함.

• 어휘가 분석되면 구문을(문법) 분석(Syntactic Analysis)함.

• 구문 분석 후 해당 구문을 묶어 최종적으로 어떤 일을 해야 되는지 의미를 분석(Semantic Analysis)함.

• 마지막으로 해석된 코드를 기계어 코드로 생성(Code Generation)함.

사용자 인터페이스 설계

• 사용자가 시스템의 접근하는 부분을 설계하는 부분을 말함.

  • 일반적으로 화면설계가 대부분을 차지함.

사용자 인터페이스 설계 시 고려사항

• 사용자 인터페이스는 해당시스템을 사용할 사용자가 익숙하고, 다른 시스템에서 경험한 것과 유사하고,
  인터페이스에서 이것을 누르면 어떤 것이 실행될 것이라고 본인이 기대된 기능이 당연히 실행되도록 설계되어야 함
  

• 시스템 사용자는 시스템의 기능보다는 사용자 인터페이스로 시스템을 판단함.

• 나쁜 인터페이스 설계는 시스템 마비상태 정도의 에러를 유발할 수도 있음.

• 나쁜 사용자 인터페이스 설계는 수많은 소프트웨어 시스템을 절대 사용하지 않아지는 원인이기도 함.

사용자 인터페이스 설계 원칙

사용자 인터페이스(UI: User Interface) 설계 프로세스

UI설계 프로세스의 주요 활동 구성

• 사용자 분석 (User Analysis) : 사용자가 시스템을 가지고 무엇을 하는지 이해해야 함.

• 시스템 프로토타이핑 (System Prototyping) : 사용자가 사용을 경험해 볼 수 있는 프로토 타입들을 계속해서 만드는 작업을 함.

• 인터페이스 평가 (Interface Evaluation) : 만들어진 프로토 타입을 경험해보고 적합한 인터페이스를 평가 함.

• 최종 UI확정

정보구조 (Information Architecture)

• 엔티티형이나 엔티티 집합으로 구성되는 정보 모델링으로 얻어지는 결과

• 각 엔티티 집합은 몇 개의 속성들로 표현되며, 각 속성은 현실 객체들이 가질 수 있는 값들의 이름

• 웹사이트 공간에서 상호작용을 설계하는 것

  • 사용자의 경험을 이용하여 사용자의 두뇌에 인식하도록 만드는 것임.

• 실질적으로 웹사이트의 경우 ‘전체 Site Map’을 먼저 작성해 보면, 전체 웹사이트의 분석 설계 및 성격을 이해하는데 용이함.

• 원하는 곳에 도착하면 알림을 주는 위치기반 App을 설계함.