[정보처리기사 필기] 1과목 소프트웨어 설계 - 2

UML(Unified Modeling Language)

 - 시스템 분석, 설계 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

 - UML은 Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

 - UML의 구성 요소에는 사물, 관계, 다이어그램 등이 있음

---

Rumbaugh

 - 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 객체지향 분석 기법

 - 순서는 객체, 동적, 기능 순으로 이루어짐

 

Booch

 - 미시적 거시적 개발 프로세스를 모두 사용하는 분석 방법

 - 클래스와 객체들을 분석 및 식별하고 클래스의 속성 연산 정의

 

Jacobson

 - USE CASE를 사용하는 분석 방법

---

사물(Things)

 - 모델을 구성하는 가장 기본 요소

 - 다이어그램 안에서 관계가 형성될 수 있는 대상

 - 사물에는 구조 사물, 행동 사물, 그룹 사물, 주해 사물이 있음

 

구조 사물(Structural Things)

 - 시스템 개념적, 물리적 요소를 표현

 

행동 사물(Behavioral Things)

 - 시간과 공간에 따른 요소들의 행위를 표현

 

그룹 사물(Grouping Things)

 - 요소들을 그룹으로 묶어서 표현

 

주해 사물(Annotation Things)

 - 부가적인 설명이나 제약조건 등을 표현

---

관계(Relationships)

 - 사물과 사물 사이의 연관성을 표현하는 것으로, 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있음

 

연관(Association) 관계

 - 연관 관계는 2개 이상의 사물이 서로 관련되어 있음을 표현

 

집합(Aggregation) 관계

 - 집합 관계는 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현

 

포함(Composition) 관계

 - 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현

 

일반화(Generalization) 관계

 - 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

 

의존(Dependency) 관계

 - 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현

 

실체화(Realization) 관계

 - 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계를 표현

---

다이어그램(Diagram)

 - 사물과 관계를 도형으로 표현한 것

 - 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용.

 

구조적(Structural) 다이어그램

 - 클래스 다이어그램(Class Diagram)
 - 객체 다이어그램(Object Diagram)
 - 컴포넌트 다이어그램(Componert Diagram)
 - 배치 다이어그램(Deployment Diagram)
 - 복합체 구조 다이어그램(Composite Structure Diagram)
 - 패키지 다이어그램(Package Diagram)

 

행위(Behavioral) 다이어그램

 - 유스케이스 다이어그램(Use Case Diagram)
 - 시퀀스 다이어그램(Sequence Diagram)
 - 커뮤니케이션 다이어그램(Communication Diagram)
 - 상태 다이어그램(State Diagram)
 - 활동 다이어그램(Activity Diagram)
 - 상호작용 개요 다이어그램(Interaction Overview Diagram)
 - 타이밍 다이어그램(Timing Diagram)

 

---

사용자 인터페이스

 - 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미

---

사용자 인터페이스의 구분

 - CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

 - GUI(Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

 - NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

 

사용자 인터페이스의 기본 원칙

 - 직관성

 - 유효성

 - 학습성

 - 유연성

 

사용자 인터페이스의 설계 지침

 - 사용자 중심

 - 일관성

 - 단순성

 - 결과 예측 가능

 - 가시성

 - 표준화

 - 접근성

 - 명확성

 - 오류 발생 해결

---

소프트웨어 아키텍처

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

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

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

 - 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보은닉이 있음

---

모듈화(Modularity)

 - 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미

 - 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을 향상

 - 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 듬

 

추상화(Abstraction)

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

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

 - 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있음

※추상화의 유형

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

 

단계적 분해(Stepwise Refinement)

 - Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법

 - 추상화의 반복에 의해 세분화

 - 소프트웨어의 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행

 

정보 은닉(Information Hiding)

 - 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

 - 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이

---

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

 

시스템 측면

 - 성능

 - 보안

 - 가용성

 - 기능성

 - 사용성

 - 변경 용이성

 - 확장성

 - 기타 속성

 

비즈니스 측면

 - 시장 적시성

 - 비용과 혜택

 - 예상 시스템 수명

 - 기타 속성

 

아키텍처 측면

 - 개념적 무결성

 - 정확성, 완결성

 - 구축 가능성

 - 기타 속성

---

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

 1. 설계 목표 설정

 2. 시스템 타입 결정

 3. 아키텍처 패턴 적용

 4. 서브시스템 구체화

 5. 검토

---

아키텍처 패턴

 

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

 - 서브시스템들과 그 역할이 정의되어 있으며, 서브시스템 사이의 관계와 여러 규칙, 지침 등이 포함

 - 아키텍처 패턴의 종류에는 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 등이 있음

---

레이어 패턴(Layers Pattern)

 - 시스템을 계층으로 구분하여 구성하는 고전적인 방법 중 하나

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

 - 서로 마주보는 두 개의 계층 사이에서만 상호작용

 - 대표적으로 OSI 참조 모델이 있음

 

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

 - 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성

 - 사용자는 클라이언트랑만 의사소통을 함. 즉 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공되는 방식

 - 서버는 클라이언트의 요청에 대비해 항상 대기 상태를 유지

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

 

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

 - 데이터스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴

 - 재사용성이 좋고, 추가가 쉬워 확장이 용이

 - 데이터 변환, 버퍼링, 동기화 등에 주로 사용

 - 대표적으로 UNIX의 쉘이 있음

 

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

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

 - 모델 : 서브시스템의 핵심 기능과 데이터를 보관

 - 뷰 : 사용자에게 정보를 표시

 - 컨트롤러 : 사용자로부터 받은 입력을 처리

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

 - 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합

 

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

 - 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식

 - 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 사용

 

브로커 패턴(Broker Pattern)

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

 - 분산 환경 시스템에서 주로 활용

 

피어-투-피어 패턴(Peer-To-Peer Pattern)

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

 - 멀티스레딩방식을 사용

 

이벤트-버스 패턴(Event-Bus Pattern)

 - 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식

 - 4가지 주요 컴포넌트

   - 이벤트를 생성하는 소스

   - 이벤트를 수행하는 리스너

   - 이벤트의 통로인 채널

   - 채널들을 관리하는 버스

 

블랙보드 패턴(Blackboard Pattern)

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

 - 음성 인식, 차량 식별, 신호 해석 등에 주로 사용

 

인터프리터 패턴(Interpreter Pattern)

 - 프로그램 코드의 각 라인을 수행하는 방법을 지정, 기호마다 클래스를 갖도록 구성