용어 정리
소프트웨어 아키텍쳐
특징 |
1. 소프트웨어의 사전 작업을 통해 소프트웨어 개발을 쉽게 하도록 기본 틀을 만드는 것 |
2. 소프트웨어 개발의 중심축 |
3. 다양한 수준에서 구성 요소의 역할과 구성 요소 간의 관계에 집중 |
4. 모든 단계에 영향을 줄만한 초기 의사 결정의 핵심 |
5. 일반적인 모양과 조화를 위한 스타일을 정하는 작업 |
아키텍쳐 패턴
정의 |
1. 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션 |
2. 아키텍쳐 패턴은 소프트웨어 디자인 패턴과 비슷하지만 더 넒은 범위에 속함 |
3. 컴퓨터 하드웨어 성능 제한, 비즈니스 위험의 최소화, 고가용성 등 소프트웨어 공학의 다양한 문제를 해결 |
UI (User Interface)
사용자가 시스템을 원활히 사용하도록 돕는 장치 / 소프트웨어
ex) CLI(Command Line Interface), GUI(Graphic User Interface), NUI(Natural User Interface)
8가지 일반적인 소프트웨어 아키텍쳐 패턴
1. 계층화 패턴 (Layered pattern)
항목 | 내용 |
개념 및 예시 | 하위 모듈들의 그룹으로 나눌 수 있는 구조화된 프로그램 |
ex) 일반적인 데스크톱 애플리케이션, 전자상거래 웹 애플리케이션 | |
장점 | 1. 추상화 |
2. 캡슐화 | |
3. 응집도 높음 | |
4. 재사용 가능 | |
단점 | 이웃층과의 커뮤니케이션이 제한적 |
2. 클라이언트-서버 패턴 (Client-Server pattern)
항목 | 내용 |
개념 및 예시 | 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공 |
ex) 이메일, 문서 공유 및 은행 등의 온라인 애플리케이션 | |
장점 | 1. 데이터 집중화 |
2. 보안 | |
단점 | 1. 병목 |
2. 비용 |
3. 마스터-슬레이브 패턴 (Master-Slave Pattern)
항목 | 내용 |
개념 및 예시 | 1. 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산 |
2. 슬레이브가 반환한 결과값으로부터 최종 결과값을 계산 | |
3. 마스터는 일을 분배하는 역할을 가지고 있음 | |
4. 슬레이브는 전달된 기능을 수행 | |
ex) 컴퓨터 시스템에서 버스와 연결된 주변장치, 다중 스레드 응용 프로그램 | |
장점 | 1. 정확성(서비스의 실행은 슬레이브들에게 전파되어 설계된 로직대로만 동작) |
단점 | 2. 마스터에 장애가 발생시, 데이터 손실 |
4. 파이프-필터 패턴 (Pipe-Filter Pattern)
항목 | 내용 |
개념 및 예시 | 1. 각 처리 과정은 필터(filter) 컴포넌트에서 이루어짐 |
2. 처리되는 데이터는 파이프(pipes)를 통해 흐름 | |
3. 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있음 | |
ex) 컴파일러 | |
장점 | 1. 필터추가 쉬움(단순성) |
2. 재사용 | |
3. 병렬성 | |
단점 | 1. 다른 패턴보다 복잡함 |
2. 오류발생 시 필터 간 데이터 손실 발생 가능 | |
3. 가장 느린 필터에 의해 효율성 결정 |
5. 브로커 패턴 (Broker Pattern)
개념 | |
1. 서버는 자신의 기능들(서비스 및 특성)을 브로커에게 넘겨줌(publish) | |
2. 클라이언트가 브로커에 서비스를 요청 | |
3. 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션 |
6. 피어 투 피어 패턴 (Peer-To-Peer Pattern)
항목 | 내용 |
개념 및 예시 | 1. 각 컴포넌트는 피어(peers)라고 불림 |
2. 피어는 클라이언트로서 피어에게 서비스 요청 가능 | |
3. 피어는 서버로서 각 피어에게 서비스 제공 가능 | |
ex) 파일 공유 네트워크, 암호화폐 |
7. 이벤트-버스 패턴 (Event-Bus Pattern)
항목 | 내용 |
개념 및 예시 | 1. 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행(publish) |
2. 리스너는 특정 채널에서 메시지를 구독 | |
3. 이벤트 스트림을 생성하는 이벤트 생성자, 이벤트를 수신 대기하는 이벤트 소비자로 구성 | |
ex) 알림 서비스 |
8. 모델-뷰-컨트롤러 패턴 (Model-View-Controller Pattern)
개념 | 내용 |
모델(Model) | 1. 데이터와 비즈니스 로직을 담당 |
2. 시스템의 상태 및 동작을 나타내는 데이터를 관리하고 업데이트 | |
3. 데이터 변경에 대한 통지를 뷰 / 컨트롤러에 전달하여 업데이트가 필요한 부분 갱신 | |
4. UI와 독립적으로 존재, 데이터의 구조와 유효성 검사를 다룸 | |
뷰(View) | 1. 사용자에게 정보를 표시하고 사용자 입력을 받는 부분을 담당 |
2. 모델의 데이터를 시각적으로 나타내고, 사용자가 상호작용할 수 있도록 인터페이스 제공 | |
3. 사용자 입력을 컨트롤러에 전달하여 처리 | |
컨트롤러(Controller) | 1. 사용자 입력을 처리하고 모델을 업데이트 |
2. 사용자가 뷰를 통해 어떠한 동작을 요청하면 모델 상태 변경 메서드 수행 | |
3. 뷰와 모델 간 상호작용 조정, 애플리케이션의 흐름 제어 |
소프트웨어 아키텍처 품질 요구사항
UI 설계 원칙
속성 | 내용 |
직관성 | 누구나 쉽게 이해하고 사용할 수 있도록 |
유효성 | 사용자의 목적을 정확하게 달성할 수 있도록 |
학습성 | 누구나 쉽게 배우고 익힐 수 있도록 |
유연성 | 사용자의 요구사항을 최대한 수용, 오류를 최소화 하도록 |
UI 설계 지침
지침 | 내용 |
사용자 중심 | 사용자가 이해하기 편하고 쉽게 사용할 수 있는 환경을 제공하고 실사용자에 대한 이해가 바탕이 되어야 함 |
일관성 | 버튼이나 조작방법을 사용자가 기억하기 쉽고 빠른 습득이 가능하게 설계해야 함 |
단순성 | 조작 방법은 가장 간단하게 작동되도록 하여 인지적 부담을 감소시켜야 함 |
결과 예측 가능 | 작동시킬 기능만 보고도 결과 예측이 가능해야 함 |
가시성 | 주요 기능을 메인 화면에 노출하여 조작이 쉽도록 함 |
표준화 | 디자인을 표준화하여 기능 구조의 선행 학습 이후 쉽게 사용할 수 있어야 함 |
접근성 | 사용자의 직무, 연령, 성별 등 다양한 계층을 수용해야 함 |
명확성 | 사용자가 개념적으로 쉽게 인지해야 함 |
오류 발생 해결 | 사용자가 오류에 대한 상황을 정확히 인지할 수 있어야 함 |
UI 프로토타입의 장 / 단점
특징 | 내용 |
장점 | 사용자 설득과 이해가 쉽다 |
개발 시간이 감소한다. | |
오류를 사전에 발견할 수 있다. | |
단점 | 많은 수정을 거치면 오히려 작업 시간이 늘어날 수 있다. |
자원 효율성 관점에서 필요 이상으로 자원을 많이 소모한다. | |
정확한 문서 작성이 생략될 수 있다. |
'Archive > 정보처리기사' 카테고리의 다른 글
[정보처리기사] 1.소프트웨어 설계 - 화면 설계 (UI 설계) (0) | 2023.12.10 |
---|---|
[정보처리기사] 1.소프트웨어 설계 - 요구사항 확인(분석모델 확인) (0) | 2023.12.03 |
[정보처리기사] 1.소프트웨어 설계 - 요구사항 확인(요구사항 확인) (2) | 2023.12.03 |
[정보처리기사] 1.소프트웨어 설계 - 요구사항 확인(현행 시스템 분석) (0) | 2023.12.02 |