[정보처리 산업기사 필기] 애플리케이션 설계 02

요구사항 정의 (2022-02-19)

• 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공함

• 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 줌

• 요구사항의 유형
  • 기능 요구사항(Functional requirements)
  • 비기능 요구사항(Non-functional requirements)
  • 사용자 요구사항(User requirements)
  • 시스템 요구사항(System requirements)

요구사항의 유형

• 기능 요구사항(Functional requirements)

  • 기능 요구사항은 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
  • 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
  • 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
  • 시스템이 반드시 수행해야 하는 기능
  • 사용자가 시스템을 통해 제공받기를 원하는 기능
• 비기능 요구사항(Non-functional requirements)
  • 비기능 요구사항은 품질이나 제약사항과 관련된 요구사항
  • 시스템 장비 구성 요구사항
  • 성능 요구사항
  • 인터페이스 요구사항
  • 데이터를 구축하기 위해 필요한 요구사항
  • 테스트 요구사항
  • 보안 요구사항
  • 품질 요구사항 : 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안 성 등
  • 제약사항
  • 프로젝트 관리 요구사항
  • 프로젝트 자원 요구사항
• 사용자 요구사항(User requirements)
  • 사용자 요구사항은 사용자 관점에서 본 시스템이 제공해야 할 요구사항
  • 사용자를 위한 것으로, 친숙한 표현으로 이해하기 쉽게 작성됨
• 시스템 요구사항(System requirements)
  • 시스템 요구사항은 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
  • 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현됨
  • 소프트웨어 요구사항이라고도 함

요구사항 개발 프로세스

• 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
• 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 함
• 요구사항 개발은 요구공학(Requirement Engineering)의 한 요소임
• 도출(Elicitation) > 분석(Analysis) > 명세(Specification) > 확인(Validation)

요구사항 도출(Requirement Elicitation, 요구사항 수집)

• 요구사항 도출은 시스템, 사용자, 개발자 등 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지 식별하고 이해하는 과정
• 개발자와 고객사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별 됨
• 소프트웨어 개발 생명 주기(SDLC) 동안 지속적으로 반복됨
• 요구 사항을 도출하는 주요기볍
  • 청취와 인터뷰
  • 설문
  • 브레인 스토밍
  • 워크샵
  • 프로토타이핑
  • 유스케이스

요구사항 분석(Requirement Analysis)

• 요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정함
• 서로 상충되는 요구사항이 잇으면 이를 중재하는 과정임
• 요구사항 분석에 사용되는 대표적인 도구
  • 자료 흐름도(DFD)
  • 자료 사전(DD)

요구사항 명세(Requirement Specification)

• 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미함
• 기능 요구사항을 빠짐없이 기술함
• 비기능 요구사항은 필요한 것만 기술함
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있음 ㅉ

요구사항 확인(Requirement Validation, 요구사항 검증)

• 요구사항 확인은 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동
• 이해관계자들이 검토해야함
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리 (SCM)를 수행함

요구 공학(Requirements Engineering)

• 요구공학은 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
• 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 함

요구사항 분석(Requirement Analysis)

• 요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미함
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정함
• 사용자의 요구를 정확하게 추출하여 목표를 정함

구조적 분석 기법

• 구조적 분석 기법은 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화함
• 하향식 방법을 사용하여 시스템을 세분화할 수 있음
• 분석의 중복을 배제할 수 있음
• 주요 구조적 분석 기법 도구
  • 자료흐름도(DFD)
  • 자료 사전(DD)
  • 소단위 명세서(Mini-Spec)
  • 개체 관계도(ERD)
  • 상태 전이도(STD)
  • 제어 명세서

구조적 분석 기법 도구

• 자료흐름도(DFD; Data Flow Diagram)
  • 자료 흐름도는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형중심으로 기술하는 방법
  • 자료흐름 그래프, 버블 차트라고도함
  • 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용됨
• 자료 사전(DD : Data Dictionary)
  • 자료 사전은 자료 흐름도에 잇는 자료를 더 자세히 정의하고 기록한 것
  • 데이터를 설명하는 데이터로, 데이터의 데이터 또는 메타 데이터(Meta Data)라고도 함
  • 자료 사전에서 사용되는 표기 기호
    • = : 자료의 정의 : ~로 구성되어 있다(is composed of)
    • +: 자료의 연결 : 그리고(and)
    • () : 자료의 생략 : 생략 가능한 자료(Optional)
    • [] : 자료의 선택 : 또는 (or)
    • {} : 자료의 반복 : iteration of
    • ** : 자료의 설명 : 주석(Comment)

요구사항 분석 CASE와 HIPO (2022-02-20)

• 요구사항 분석용 CASE(자동화 도구)
  • 요구사항 분석용 CASE는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미함

대표적인 요구사항 분석용 CASE

• SADT
  • 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
  • SoftTech 사에서 개발
  • 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
• SREM = RSL/REVS
  • TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구
  • RSL과 REVS를 상용하는 자동화 도구
• PSL/PSA
  • PSL과 PSA를 사용하는 자동화 도구
  • 미시간 대학에서 개발
• TAGS
  • 시스템 공학 방법 응용에 대한 자동 접근 방법
  • 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

HIPO(Hierarchy Input Process Output)

• HIPO는 시스템의 분석 및 설계, 또는 문서화에 상용되는 기법으로, 시스템 실행 과정인 입력,처리,출력의 기능을 표현한 것
• 하향식 소프트웨어 개발을 위한 문서화 도구임
• 기능과 자료의 의존 관계를 동시에 표현할 수 있음
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉬움

• 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함

• HIPO Chart의 종류
  • 가시적 도표(Visual Table of Contents, 도식 목차)
  • 총체적 도표(Overview Diagram, 총괄 도표, 개요도표)
  • 세부적 도표(Detail Diagram, 상세 도표)

UML(Unified Modeling Language)의 개요

• UML은 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자의 상호간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• Rumbaugh(OMT), Booch, Jacobason 등의 객체지향 방법론의 장점을 통합하였음
• OMG(Object Management Group)에서 표준으로 지정하였음
• UML의 구성요소
  • 사물(Things)
  • 관계(Relationships)
  • 다이어그램(Diagram)

UML의 구성요소

1. 사물(Things)

• 사물은 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말함
• 모델을 구성하는 가장 중요한 기본 요소임
• 사물의 종류
  • 구조 사물(Structural Things)
    • 시스템의 개념적, 물리적 요소를 표현
    • 클래스(Class), 유스케이스(Use Case), 컴포넌트(Component), 노드(Node) 등
  • 행동 사물(Behavioral Things)
    • 시간과 공간에 따른 요소들의 행위를 표현
    • 상호작용(Interaction) , 상태 머신(State Machine) 등
  • 그룹 사물(Group Things)
    • 요소들을 그룹으로 묶어서 표현
    • 패키지(Package)
  • 주해 사물(Annotation Things)
    • 부가적인 설명이나 제약조건 등을 표현
    • 노트(Note)

1. 관계(Relationship)

• 관계는 사물과 사물사이의 연관성을 표현하는 것
• 관계의 종류는 연관관계, 집합관계, 포함관계, 일반화 관계, 의존관계, 실체화 관계 등이있다.
  • 연관관계(Association) 관계
  • 연관 관계는 2개이상의 사물이 서로 관련되어 있는 관계
  • 사물 사이를 실선으로 연결하여 표현함
  • 방향성은 화살표로 표현함
  • 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결함
  • 다중도를 선 위에 표기함

1. 집합(Aggregation) 관계

• 집합관계는 하나의 사물이 다른 사물에 포함되어 있는 관계
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)는 서로 독립적임
• 포함되는쪽(부분, Part)에서 포함하는 쪽(전체, whole)으로 속이 빈 마름모를 연결하여 표현

1. 포함(Composition) 관계

• 포함 관계는 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)는 서로 독립될 수 없고 생명주기를 함께 함
• 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현함

1. 일반화(Generaliztion) 관계

• 일반화 관계는 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부름
• 구체적(하위)인 사물에서 일반적(상위)인 사물쪽으로 속이 빈 화살표를 연결하여 표현 함

1. 의존(Dependency) 관계

• 의존관계는 연관 관계와 같이 사물사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계임
• 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현

1. 실체화(Realiztion) 관계

• 실체화 관계는 사물이 할 수 잇거나 해야하는 기능으로, 서로를 그룹화 할 수 있는 관계
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현

다이어그램(Diagram)

• 다이어그램은 사물과 관계를 도형으로 표현한 것
• 여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 줌
• 정적 모델링에서는 주로 구조적 다이어그램을 사용함
• 동적 모델링에서는 주로 행위 다이어그램을 사용함

구조적 다이어그램(Structual) 다이어그램의 종류

• 클래스 다이어그램(Class Diagram)
  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함
• 객체 다이어그램(Object Diagram)
  • 클래스에 속한 사물(객체)들 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현함
  • 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용
• 컴포넌트 다이어그램(Component Diagram)
  • 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현함
  • 구현 단계에서 사용됨
• 배치 다이어그램(Deployment Diagram)
  • 결과물,프로세스,컴포넌트 등 물리적 요소들의 위치를 표현함
  • 구현 단계에서 사용됨
• 복합체 구조 다이어그램(Composite Structure Diagram)
  • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현함
• 패키지 다이어그램(Package Diagram)
  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함

행위(Behavioral) 다이어그램의 종류

• 유스케이스 다이어그램(Use Case Diagram)
  • 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함
  • 사용자(Actor)와 사용 사례(Use Case)로 구성됨
• 시퀀스 다이어그램(Sequence Diagram)
  • 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현함
• 커뮤니케이션 다이어그램(Communication Diagram)
  • 동작에 참여하는 객체들이 주고받는 메시지와 객체들간의 연관 관계를 표현함
• 상태 다이어그램(State Diagram)
  • 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현함
  • 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용됨
• 활동 다이어그램(Activity Diagram)
  • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현함
• 상호작용 개요 다이어그램(Interaction Overview Diagram)
  • 상호작용 다이어그램 간의 제어흐름을 표현함
• 타이밍 다이어그램(Timing Diagram)
  • 객체 상태 변화와 시간 제약을 명시적으로 표현함

스테레오 타입(Stereotype)

• 스테레오 타입은 UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는것이다.
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(«»)사이에 쵸현할 형태를 기술한다
• 주로 표현되는 형태
  • « include » : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
  • « extend » : 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
  • « interface » : 인터페이스를 정의하는 경우
  • « exception » : 예외를 정의하는 경우
  • « constructor » : 생성자 역할을 수행하는 경우

유스케이스(Use Case)다이어그램

• 기능 모델링

  • 기능 모델링은 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것
  • 개발될 시스템의 전반적인 형태를 기능에 초점을 맞춰 표현함
  • 기능 모델링의 종류
    • 유스케이스(Use Case) 다이어그램
    • 액티비티(Activity) 다이어그램

유스케이스(Use Case) 다이어그램

• 유스케이스 다이어그램은 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
• 외부 요소와 시스템 간의 상호 작용을 확인할 수 있음
• 사용자의 요구사항을 분석하기 위한 도구로 사용됨
• 시스템의 범위를 파악할 수 있음

유스케이스(UseCase) 다이어그램 구성요소

• 시스템(System) / 시스템 범위(System Scope)
  • 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템 범위를 표현한 것
• 액터(Actor)
  • 시스템과 상호작용을 하는 모든 외부 요소
  • 주로 사람이나 외부 시스템을 의미함
  • 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당됨
  • 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음.
• 유스케이스(Use Case)
  • 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
• 관계(Relationship)
  • 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음
  • 유스케이스에서 나타날 수 있는 관계 : 포함(include) 관계, 확장(Extends) 관계, 일반화 (Generaliztaion) 관계

클래스(Class) 다이어그램

• 정적 모델링
  • 정적 모델링은 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적은 구조를 표현한 것
  • 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점(View)에서 표현함
  • 정적 모델링은 객체(Object)들을 클래스(Class)로 추상화하여 표현함
  • UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램임

클래스(Class) 다이어그램

• 클래스 다이어그램은 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것
• 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램임
• 시스템 구성 요소를 문서화하는 데 사용됨

클래스(Class) 다이어그램의 구성요소

• 클래스(Class)
  • 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한 것
  • 일반적으로 3개의 구획(Compartment)으로 나눠 클래스의 이름,속성, 오퍼레이션을 표기함
  • 속성(Attribute) : 클래스의 상태나 정보를 표현함
  • 오퍼레이션(Operation) : 클래스가 수행할 수 있는 동작으로, 함수(메소드, Method) 라고 함
• 제약조건
  • 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
  • 클래스 안에 제약조건을 기술할 때는 중괄호 {}를 이용함
• 관계(Relationship)
  • 관계는 클래스와 클래스 사이의 연관성을 표현함
  • 클래스 다이어그램에 표현하는 관계에는 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계가 있음
• 연관 클래스
  • 연관 클래스는 연관 관계에 있는 두 클래스에 추가적으로 표현해야할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스
  • 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시함
  • 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정함

시퀀스(Sequence) 다이어그램

• 동적 모델링
  • 동적 모델링은 시스템의 내부 구성요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것
  • 시스템 내부 구성 요소들 간에 이루어지는 동작이라는 관점(View)에서 표현함
  • 시스템이 실행될 때 구성요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둠
• 동적 모델링의 종류
  • 시퀀스 다이어그램
  • 커뮤니케이션 다이어그램
  • 상태 다이어그램

시퀀스(Sequence) 다이어그램

• 시퀀스 다이어그램은 시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것
• 시스템이나 객체들의 상호 작용 과정에서 주고받는 메시지를 표현함
• 각 동작에 참여하는 시스템이나 객체들의 수행 기간을 확인할 수 있음
• 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현함

시퀀스(Sequence) 다이어그램의 구성요소

• 액터(Actor)
  • 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미함
• 객체(Object)
  • 메시지를 주고 받는 주체
• 생명선(Lifeline)
  • 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현함
• 실행 상자(Active Box, 활성 상자)
  • 객체가 메시지를 주고받으며 구동되고 있음을 표현함
• 메시지(Message)
  • 객체가 상호 작용을 위해 주고받는 메시지
• 객체 소멸
  • 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
• 프레임(Frame)
  • 다이어그램의 전체 또는 일부를 묶어 표현한 것

소프트웨어 아키텍쳐

• 소프트웨어 아키텍처는 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체임
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정함
• 소프트웨어 아키텍처 설계의 기본 원리에는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있음

모듈화(Modularity)

• 모듈화는 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미함
• 모듈의 크기를너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 듬
• 모듈의 크기를 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발비용이 많이 듬

추상화(Abstraction)

• 추상화는 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것

• 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러가지 요인들을 테스트 할 수 있음

• 추상화의 유형
  • 과정 추상화
    • 자세한 수행 과정을 정의 하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
  • 데이터 추상화
    • 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
  • 제어 추상화
    • 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

단계적 분해(Stepwise Refinement)

• 단계적 분해는 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
• Niklaus Wirth에 의해 제안된 하향식 설계 전략 임
• 소프트웨어의 포괄적인 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행함

정보 은닉(Information Hiding)

• 정보 은닉은 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있음
• 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정,시험,유지보수가 용이

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

• 소프트웨어 아키텍처가 이해관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인하기 위해 품질 평가 요소들을 구체화 시켜놓은 것

• 품질 평가 요소의 종류

  • 시스템 측면
    • 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 등
  • 비즈니스 측면
    • 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등
  • 아키텍처 측면
    • 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성 등

소프트웨어 아키텍처의 설계 과정

1. 설계 목표 설정 : 요구사항을 분석하여 전체 시스템의 설계 목표 설정
2. 시스템 타입 설정 : 시스템과 서브시스템의 타입을 결정하고, 아키텍처 패턴 선택
3. 아키텍처 패턴 적용 : 시스템의 표준 아키텍처 설계
4. 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스 정의
5. 검토 : 설계목표, 요구사항, 설계의 기본원리 등을 만족하는지 아키텍처 검토

협약(Contract)에 의한 설계

• 협약에 의한 설계는 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유 할 수 있도록 명세한것
• 컴포넌트에 대한 정확한 인터페이스를 명세함
• 명세에 포함될 조건
  • 선행 조건(Precondition) : 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
  • 결과 조건(Postcondition) : 오퍼레이션이 수행된 후 만족되어야 할 조건
  • 불변 조건(Invariant) : 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건

아키텍처 패턴(Patterns)

• 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미함
• 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시함
• 아키텍처 패턴에는 서브시스템들과 그 역할이 정의되어 있음
• 서브시스템 사이의 관계와 여러 규칙, 지침 등이 포함되어있음
• 주요 아키텍처 패턴의 종류
  • 레이어 패턴
  • 클라이언트-서버 패턴
  • 파이프-필터 패턴
  • 모델-뷰-컨트롤러 패턴

레이어 패턴(Layers pattern)

• 시스템을 계층으로 구분하여 구성하는 고전적인 방법의 패턴
• 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 됨
• 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
• 댚적으로 OSI 참조 모델이 있음

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

• 클라이언트-서버 패턴은 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
• 사용자가 클라이언트를 통해 서버에 요청하면 클라이언트가 응답을 받아 사용자에게 제공하는 방식

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

• 파이프-필터 패턴은 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴
• 앞 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴을 반복함
• 데이터 변환, 버퍼링, 동기화 등에 주로 사용됨
• 대표적으로 UNIX의 쉘(Shell)이 있음

모델-뷰-컨트롤러 패턴(Model-View-Controller pattern)

• 서브시스템을 모델,뷰,컨트롤러로 구조화하는 패턴
• 컨트롤러가 사용자의 요청을 받으면 핵심 기능과 데이터를 보관하는 모델을 이용하여 뷰에 정보를 출력하는 구조임
• 여러 개의 뷰를 만들 수 잇음
• 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합함

객체지향(Object-Oriented)

• 객체지향은 소프트웨어 각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있음
• 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉬움
• 객체지향의 구성요소
  • 객체(Object)
  • 클래스(Class)
  • 메시지(Message)
• 객체지향의 특징
  • 캡슐화(Encapsulation)
  • 상속(Inheritance)
  • 다형성(Polymorphism)
  • 연관성(Relationship)

객체(Object)

• 객체는 데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈
  • 데이터 : 객체가 가지고 있는 정보, 속성이나 상태, 분류 등
  • 함수 : 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘, 객체의 상태를 참조하거나 변경하는 수단

클래스(Class)

• 클래스는 공통된 속성과 연산을 갖는 객체의 집합
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 함

메시지(Message)

• 메시지는 객체들 간의 상호작용에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구사항

캡슐화(Encapsulation)

• 외부에서 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
• 캡슐화된 객체는 외부 모듈의 변경으로 인한 파급 효과가 적다
• 객체들 간에 메시지를 주고받을 때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고 객체 간의 결합도가 낮아짐

상속(Inheritance)

• 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는것
• 하위 클래스는 물려받은 속성과 연산을 다시 정의하지 않아도 즉시 자신의 속성으로 사용할 수 있음
• 하위 클래스는 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있음

다형성(Polymorphism)

• 하나의 메세지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
• 객체들은 동일한 메소드명을 사용하여 같은 의미의 응답함

연관성(Relationship)

• 연관성은 두개 이상의 객체들이 상호 참조하는 관계를 의미
• 연관성의 종류
  • is member of (연관화,Association) : 2개 이상의 객체가 상호 관련되어 있음을 의미함
  • is instance of (분류화, Classfication) : 동일한 형의 특성을 갖는 객체들을 모아 구성하는 것
  • is part of (집단화, Aggregation) : 관련있는 객체들을 묶어 하나의 상위 객체를 구성하는것
  • is a
    • 일반화(Generalization) : 공통적인 성질들로 추상화한 상위 객체를 구성하는 것
    • 특수화/상세화(Specialization) : 상위 객체를 구체화하여 하위 객체를 구성하는 것

객체지향 분석 및 설계 (2022-02-21)

객체지향 분석의 방법론

• 객체지향 분석은 사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업
• 개발을 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석함
• 클래스를 식별하는 것이 객체지향 분석의 주요 목적임

객체지향 분석의 방법론의 종류

• Rumbaugh(럼바우) 방법
  • 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행함
• Booch(부치) 방법
  • 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용함
  • 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
• Jacobson 방법
  • 유스케이스(Use Case)를 강조하여 사용함
• Coad와 Yourdon 방법
  • E-R 다이어그램을 사용하여 객체의 행위를 모델링함
  • 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성함
• Wirfs-Brock 방법
  • 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행함

럼바우(Rumbaugh)의 분석기법

• 럼바우의 분석 기법은 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
• 객체 모델링 기법(OMT, Object-Modeling Technique)이라고도 함

• 분석 활동은 ‘객체 모델링 -> 동적 모델링 -> 기능 모델링’ 순으로 이루어짐

• 객체 모델링(Object Modeling)
  • 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것
• 동적 모델링(Dynamic Modeling)
  • 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링
• 기능 모델링(Functional Modeling)
  • 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

객체지향 설계 원칙

• 객체지향 설계 원칙은 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜져야 할 원칙
• SRP, OCP, LSP, ISP, DIP의 다섯 가지 원칙의 앞 글자를 따 SOLID 원칙이라고 부름

디자인 패턴(Design Pattern)

• 디자인 패턴은 모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미함
• 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성되어 있음
• 바퀴를 다시 발명하지 마라(Don`t reinvent the wheel)라는 말과 같이, 개발 과정 중에 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적임
• GOF의 디자인 패턴은 생성 패턴, 구조 패턴, 행위 패턴으로 구분됨

생성 패턴(Creational Pattern)

생성패턴은 클래스나 객체의 생성과 참조 과정을 정의하는 패턴

• 추상 팩토리(Abstract Factory)
  • 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관, 의존 하는 객체들의 그룹으로 생성하여 추상적으로 표현함
  • 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능함
• 빌더(Builder)
  • 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체를 생성함
  • 객체의 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음
• 팩토리 메소드(Factory Method)
  • 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
  • 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당
  • 가상 생성자(Virtual Contstructor) 패턴 이라고도 함
• 프로토타입(Prototype)
  • 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
  • 일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용함
• 싱글톤(Singleton)
  • 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음
  • 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화 할 수 있음

구조 패턴(Structrual Pattern)

구조 패턴은 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

• 어댑터(Adapter)
  • 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용 할 수 있도록 변환해주는 패턴
  • 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용함
• 브리지(Bridge)
  • 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능과 구현을 두 개의 별도 클래스로 구현함
• 컴포지트(Composite)
  • 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
  • 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음
• 데코레이터(Decorator)
  • 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 있는 패턴
  • 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현함
• 퍼싸드(Facade)
  • 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
  • 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요함
• 플라이웨이트(Flyweight)
  • 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
  • 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용할 수 있음
• 프록시(Proxy)
  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
  • 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용함

행위 패턴(Behaviroal Pattern)

행위 패턴은 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴

• 책임 연쇄(Chain of Responsibility)
  • 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
  • 요청을 처리할 수 있는 각 객체들이 고리(Chain)로 묶여 있어 요청이 해결될때까지 고리를 따라 책임이 넘어감
• 커맨드(Command)
  • 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
  • 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화함
• 인터프리터(interpreter)
  • 언어에 문법 표현을 정의하는 패턴
  • SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용함
• 반복자(Iterator)
  • 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
  • 내부 표현 방법의 노출 없이 순차적인 접근이 가능함
• 중재자(Mediator)
  • 수많은 객체들 간의 복잡한 상호작용(Interface)를 캡슐화하여 객체로 정의하는 패턴
  • 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음
• 메멘토(Memento)
  • 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
  • [Ctrl] + [Z]와 같은 되돌리기 기능을 개발할 때 주로 이용함
• 옵서버(Observer)
  • 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
  • 일대다의 의존성을 정의함
  • 주로 분산된 시스템 간에 이벤트를 생성,발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용함
• 상태(State)
  • 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
  • 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리함
• 전략(Strategy)
  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
  • 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능함
• 템플릿 메소드(Template Method)
  • 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
  • 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이 하게 해줌
• 방문자(Visitor)
  • 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
  • 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행함