1. 소프트웨어 설계의 기본 원칙

1.1 소프트웨어 설계

1.1.1 소프트웨어 설계의 개념

• 요구사항 명세서를 참조하여 소프트웨어의 구체적인 설계서를 작성 하는 단계
• 물리적으로 구현이 가능하도록 시스템을 구체적으로 정의하는 단계

1.1.2 소프트웨어 설계의 종류

• 상위설계 : 분석, 설계
  • 아키텍처 설계 : 시스템의 전체적인 구조 설계
  • 데이터 설계
    • 시스템에 필요한 정보를 설계
    • 데이터 베이스 설계
  • 인터페이스 정의 : 시스템의 구조와 서브 시스템들 사이의 인터페이스를 명확히 정의
  • 사용자 인터페이스 설계 : 사용자가 익숙하고 편리하게 사용하도록 인터페이스 설계
• 하위설계 : 구현, TEST
  • 모듈 설계 : 각 모듈의 실제적인 내부를 알고리즘 형태로 표현
  • 자료구조 설계 : 자료구조, 변수 등에 대한 상세한 정보를 설계
  • 알고리즘 설계 : 업무의 처리 절차 등을 설계

1.1.3 소프트웨어 설계의 원리⭐

• 분할과 정복(Divide & Conquer)

  • 규모가 큰 소프트웨어를 여러 개의 작은 서브 시스템으로 나누어 하나씩 완성시킨다.

• 추상화(Abstraction)

  • 특정한 목적과 관련된 필수 정보만 추출하여 강조하고, 관련이 없는 세부 사항을 생략함으로써, 본질적인문제에 집중할 수 있도록 한다.
  • 자세한 구현 전에, 상위 레벨에서 제품의 구현을 먼저 생각해보는 것
  • 추상화 기법 : 과제데⭐
    • 과정 추상화: 자세한 단계를 고려하지 않고 상위 수준에서 수행 흐름만 먼저 설계
    • 제어 추상화: 여러 명령들을 간단한 표현으로 대체하는 것이다.
    • 데이터 추상화: 데이터 구조를 대표할 수 있는 표현으로 대체하는 것이다.

• 단계적 분해(Gradual Decomposition): 기능을 점점 작은 단위로 나누어 점차적으로 구체화 하는 방법

• 모듈화(Modulization): 실제로 개발할 수 있는 작은 단위로 나눈다.

• 정보은닉(Information Hiding)

  • 다른 객체에게 자신의 정보를 숨기고, 자신의 연산만을 통해 접근이 가능하도록 한다.
  • 클래스 외부에서 특정 정보에 대한 접근을 막는다는 의미
  • 캡슐화와 밀접한 관계가 있다

1.2 설계 모델링

1.2.1 설계 모델링 개념

• 소프트웨어를 구성하는 모듈들을 식별하고, 이것들의 연결을 그림으로 표현한 것
• 소프트웨어를 만들기 위한 계획 또는 만들어야 할 물건을 의미있게 표현한 것
• 소프트웨어에 대하여 여러 엔지니어들이 공통된 개념을 공유하는데 도움을 준다.

1.2.2 설계 모델링 원칙

• 소프트웨어 설계는 변경이 용이하도록 구조화되어야 한다.
• 한 함수 안에 특정 기능을 수행하는 데 필요한 자료만을 사용하도록 한다.
• 요구사항 분석에서 얻은 정보를 이용하여 반복적 방법을 통해 이루어져야 한다.
• 독립적이고 기능적인 특성들을 지닌 모듈 단위로 설계되어야 한다.

1.2.3 설계 모델링 유형

• 구조 모델링
  • 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 연결 구조를 모델링
  • 시스템의 구성 요소들과 이들 사이의 구조적인 관계와 특성들의 모델링
  • UML 정적 다이어그램
• 행위 모델링
  • 소프트웨어의 구성요소들의 기능들이 언제, 어떠한 순서로 기능을 수행해야 작용하는지를 모델링
  • 시스템의 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들의 모델링
  • UML 동적 다이어그램

1.2.4 소프트웨어 설계 절차 및 유형⭐

• 아키텍처 설계 : 시스템을 구성하는 서브시스템들과 그들 간의 관계를 파악하고 명세한다.
• 데이터베이스 설계 : 시스템 구현에 사용되는 데이터의 구조를 자세하게 설계하고 명세한다.
• 서브시스템 설계 : 각 서브시스템이 담당하는 서비스와 제약사항들에 대해 명세한다.
• 컴포넌트 설계 : 서브시스템이 수행하는 기능을 여러 컴포넌트에 할당하고, 컴포넌트들의 인터페이스를설계하고 명세한다.
• 자료구조와 알고리즘 설계 : 컴퓨터에 자료를 효율적으로 저장하는 방식과, 자료구조 내에서 기본적인 연산방법을 설계하고 명세
• 협약에 의한 설계⭐
  • 클래스에 대한 여러 가정을 공유하도록 명세
  • 선행 조건 : 컴포넌트 오퍼레이션 사용 전에 참이 되어야할 조건
  • 결과 조건 : 사용 후 만족되어야 할 결과조건
  • 불변 조건 : 오퍼레이션이 실행되는 동안 항상 만족되어야할 조건

2. 소프트웨어 아키텍처

2.1 소프트웨어 아키텍처

2.1.1 소프트웨어 아키텍처(SoftWare Architecture) 개념

• 소프트웨어의 골격이 되는 기본구조
• 시스템의 컴포넌트 사이의 관계를 정의한 구조

2.1.2 소프트웨어 아키텍처의 특징

• 간략성: 이해하고 추론할 수 있을 정도의 간결성 유지
• 추상화: 시스템의 추상적인 표현을 사용
• 가시성: 시스템이 포함해야 하는 것들을 가시화
• 관점 모형: 이해당사자의 관심사에 따른 모형 제시
• 의사소통 수단: 이해당사자 간 원활한 의사소통 수단으로 이용

2.1.3 소프트웨어 아키텍처 프레임워크 구성요소

• 아키텍처 명세서(Architecture Description): 아키텍처를 기록하기 위한 산출물
• 이해관계자(Stakeholder) :소프트웨어 시스템 개발에 관련된 모든 사람과 조직 - 고객, 개발자, 프로젝트 관리자 등 포함
• 관심사(Concerns)
  • 동일한 시스템에 대해 서로 다른 이해관계자 의견
  • e.g.) 사용자 : 기본적인 기능, 신뢰성, 보안등의 요구
• 관점(Viewpoint) : 서로 다른 역할이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점
• 뷰(View) : 이해 관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현

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

(1) 4+1 뷰 개념

• 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
• 복잡한 소프트웨어 아키텍처를 다양한 이해관계자들이 바라보는 관점
• View는 시스템의 여러 가지 측면을 고려하기 위한 다양한 관점을 바탕으로 정의

(2) 4+1 View Model 과 구성요소 : 유논프구배⭐

• 유스케이스 뷰 (use case view)
  • 아키텍처를 도출하고 설계하는 작업을 주도하는 뷰
  • 다른 뷰를 검증하는데 사용
  • Use Case Diagram이 사용
  • +1 에 해당하며 유스케이스가 나머지 4개 뷰에 모두 참여하면서 영향을 준다.
• 논리 뷰 (logical view)
  • 시스템의 기능적인 요구사항
  • 시스템이 최종 사용자를 위해 해야 하는 것을 나타낸다.
• 프로세스 뷰 (process view)
  • 프로그램 실행시의 시스템 표현
  • Thread와 Process에 의한 동작을 중점적으로 표현
  • 동시성, 분산처리, 시스템 통합, 오류 허용 등을 표현
• 구현 뷰 (implementation view)
  • 개발 환경 안에서 정적인 소프트웨어 모듈의 구성
  • 개발자 관점에서 소프트웨어 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현
• 배치 뷰 (deployment view)
  • 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑 되는가를 표현
  • 가용성, 신뢰성, 성능, 확장성 등의 시스템의 비기능적인 요구사항 고려
  • 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현

2.1.5 소프트웨어 아키텍처 품질속성⭐

2.1.6 소프트웨어 아키텍처 평가

• 소프트웨어 아키텍처 평가 개념
  • 아키텍처의 접근법이 품질속성(보안, 성능, UI 등)에 미치는 영향을 판단하여 아키텍처 적합성을 판단하고평가하는 표준 기법
• 소프트웨어 아키텍처 평가기법 유형 : 비가시적 평가(SACCA, 사카)

2.2 소프트웨어 아키텍처 패턴

2.2.1 소프트웨어 아키텍처 패턴의 개념⭐

• 주어진 문맥 안에서 소프트웨어 아키텍처의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책
• 소프트웨어 공학의 다양한 문제를 해결
  • 컴퓨터 하드웨어 성능
  • 비즈니스 위험의 최소화
  • 고가용성 : 한 서버가 정지했을 떄, 다른 서버를 이용해 시스템을 이용하게 하는 방법⭐
    • 가용성 : 언제든지 시스템을 이용할 수 있어야 한다
• 일부 아키텍처패턴은 소프트웨어 프레임워크 안에 구현되어 있다.

2.2.2 소프트웨어 아키텍처 패턴 종류⭐

• 계층화 패턴(Layered pattern)

  • n-티어 아키텍처 패턴으로 부른다.
  • 하위 모듈을 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용
  • 각 서브 시스템이 하나의 계층이 되고 하위층이 제공하는 서비스를 상위층의 서브 시스템이 이용할 수 있는구조
  • e.g.) OSI 7계층, TCP/IP 4계층

• 클라이언트-서버 패턴(Client-Server Pattern)

  • 다수의 클라이언트와 하나의 서버로 구성
  • 서버는 클라이언트에게 서비스를 제공하며 데이터를 관리하는 역할
  • e.g.) 일반적인 웹 프로그램

• 마스터-슬레이브 패턴(Master-Slave Pattern)

  • 마스터 컴포넌트가 동등한 구조의 슬레이브 컴포넌트로 작업을 분산 하고, 슬레이브가 결과값을 반환하면 최종결과값을 계산하는 구조

    = 마스터는 연산, 슬레이브는 인용만 한다

  • e.g.) 컴퓨터와 주변장치

• 파이프-필터 패턴(Pipe-Filter Pattern)⭐

  • 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴 * 스트림 : 한 방향으로 보낸다 (동영상 스트리밍)
  • 필터 컴포넌트에서 각 처리과정을 실행하며, 처리된 데이터는 파이프를 통해 전송
  • 서브시스템이 입력데이터를 받아 처리하고 결과를 다음 서브시스템으로 넘겨주는 과정을 반복
  • e.g.) Unix 쉘처리

• 브로커 패턴(Broker Pattern)

  • 분리된 컴포넌트로 구성된 분산 시스템에서 사용되는 패턴
  • 각 컴포넌트들은 원격 서비스를 통해 서로 상호작용을 할 수 있으며 브로커 컴포넌트가 컴포넌트 간의 통신을 조절

• 피어 투 피어 패턴(Peer to Peer Pattern)
  • 피어라 부르는 각 컴포넌트 간에 서비스를 주고 받는 패턴
  • 피어 객체 하나가 클라이언트, 서버의 역할을 모두 수행하는 구조
  • e.g.) 파일 공유(P2P), 토렌트
• 이벤트-버스 패턴(Event-Bus Pattern)
  • 이벤트 버스를 통해 특정 채널로 메시지를 발행
  • 리스너가 구독한 채널에 소스가 서비스를 제공하면 채널이 리스너에게 서비스를 제공
  • e.g.) 알림 서비스
• 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)⭐
  • MVC Pattern - 3개의 각 컴포넌트는 각자의 역할을 갖고 사용자에게 서비스를 제공
  • 자료의 저장, 제어, 표현 기능을 분리하여 재사용을 증진
  • 모델(Model) : 도메인의 기능과 자료를 저장하고 보관
  • 뷰(View) : 사용자에게 결과를 표시
  • 컨트롤러(Controller) : 사용자로부터 입력을 받아 연산을 처리
  • e.g.) 일반적인 웹 어플리케이션 설계 아키텍처

• 블랙보드 패턴(Blackboard Pattern) : 명확히 정의된 해결 전략이 알려지지 않은 문제에 대해서 유용한 패턴
• 인터프리터 패턴(Interpreter Pattern) : 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용되는 패턴

3. UML

3.1 UML(Unified Modeling Language)⭐

3.1.1 UML 개념⭐

• 프로그램 설계를 표현하기 위해 사용하는 표기법
• 시스템 개발 과정에서 이해관계자 사이에 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어
• 소프트웨어 시스템, 업무 모델링, 시스템의 산출물을 규정하고 시각화, 문서화하는 언어
• 프로그램언어가 아닌 기호와 도식을 이용하여 표현하는 방법을 정의한다.

3.1.2 UML 특징 : 가구명문

• 가시화 언어 : 소프트웨어의 개념 모델을 시각적인 그래픽 형태로 작성한다.
• 구축 언어 : 명세화된 설계모델은 다양한 언어의 소스코드로 변환하여 구축할 수 있다.
• 명세화 언어 : 분석, 설계, 구현 단계의 각 과정에서 필요한 모델을 명세화 할 수 있는 언어
• 문서화 언어 : 일련의 과정을 문서로 남겨 계속 유지 보수한다.

3.2 UML 구성요소 : 사관다⭐

3.2.1 사물(Things)

• 구조 사물 : 시스템의 개념적, 물리적 요소
  • e.g.) 클래스, 유즈케이스, 컴포넌트 등
• 행동 사물 : 시간과 공간에 따른 요소들의 행위
  • e.g.) 상호작용, 상태머신
• 그룹 사물 : 요소들을 그룹으로 묶은 것
  • e.g.) 패키지
• 주해 사물 : 부가적 설명이나 제약조건
  • e.g.) 주석, 노트

3.2.2 관계(Relationships) : 연의 일실 포집⭐

• 연관관계(Association)
  • 2개 이상 사물이 서로 관련된 관계
  • 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 표시

• 의존관계(Dependency)
  • 연관 관계와 같이 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 표시
  • 연관 관계와 차이점은 두 클래스의 관계가 한 메서드를 실행하는 동안과 같이 매우 짧은 시간만 유지
  • 한 클래스의 명세가 바뀌면 다른 클래스에 영향을 줌
  • 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우

• 일반화 관계(Generalization)
  • 한 클래스가 다른 클래스를 포함하는 상위 개념일 때의 관계
  • 객체지향 개념에서는 일반화 관계를 상속관계(Inheritance)라고 함

• 실체화 관계 (Realization)
  • 인터페이스를 구현받아 추상 메서드를 오버라이딩(재정의) 하는 것을 의미
  • 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정

• 포함 관계 (Composition)

  • 부분 객체가 전체 객체에 속하는 관계로 긴밀한 필수적 관계

  • 전체 객체의 라이프타임과 부분 객체의 라이프 타임은 의존적

  • 전체 객체가 없어지면 부분 객체도 없어짐

• 집합 관계 (Aggregation)
  • 한 객체가 다른 객체를 소유하는 ‘has a’ 관계
  • 전체 객체의 라이프타임과 부분 객체의 라이프타임은 독립적
  • 전체 객체가 사라진다 해도 부분 객체는 사라지지 않음

3.2.3 다이어그램(Diagram)⭐

(1) 구조 다이어그램 : 클객컴 배복패

(2) 행위 다이어그램 : 유시커 상활타

3.3 주요 다이어그램⭐

3.3.1 클래스 다이어그램

(1) 클래스 다이어그램 개념

• 자기만의 속성(attribute)과 일정한 행동(behavior)으로 구성
• 여러 개의 클래스들은 서로 연관이나 상속, 의존 관계 등으로 서로 간의 상호작용을 표현

(2) 클래스 다이어그램 표현

(3) 접근 제한자 표기법

3.3.2 유스케이스 다이어그램

(1) 유스케이스 다이어그램 개념

• 시스템과 사용자의 상호작용을 다이어그램으로 표현
• 사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여준다.
• 프로젝트에 대한 요구사항을 정의하고 세부기능을 분석하며 개발 범위를 정할 때 작성한다.

(2) 유스케이스 다이어그램 구성요소 : 유액시

(3) 유스케이스 다이어그램

3.3.3 시퀀스 다이어그램

(1) 시퀀스 다이어그램 개념

• 객체간의 상호작용 메시지 시퀀스를 시간의 흐름에 따라 나타내는 다이어그램

(2) 시퀀스 다이어그램 구성요소 : 객생메실

• 객체(Object) : 객체(활동 주체)는 직사각형으로 표현

• 생명선(Lifeline)

  • 라이프라인은 객체에서 이어지는 점선으로 표현
  • 점선은 위에서 아래로 갈수록 시간의 경과를 의미

• 실행 박스(Activation Box)

  • 생명선상에서 길다란 직사각형으로 표현
  • 현재 객체가 어떤 활동을 하고 있음을 의미

• 메시지(Message) : 인스턴스 간 주고 받은 데이터

  • 메시지의 유형
    • 동기 메시지 (Sync message): 요청을 보낸 후에 반환이 올 때까지 대기
      • e.g., TCP
    • 비동기 메시지 (Async message): 요청을 보낸 다음 반환을 기다리지 않고 다른 작업을 수행
      • e.g. UDP
    • 자체 메시지 (Self message): 자기 자신에게 요청을 보냄
    • 반환 메시지 (Reply/Return message): 요청에 대해 메시지를 반환

3.3.4 상태 다이어그램

(1) 상태 다이어그램 개념

• 한 객체의 상태 변화를 나타내는 다이어그램

(2) 상태 다이어그램 예시