1과목 -3 (필기 개념 정리)

 

1. 품질 요구사항

(1) ISO/IEC 9126 : 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용됨

 

(2) ISO/IEC 12119 : ISO/IEC 9126을 준수한 품질 표준으로, 테스트 절차를 포함하여 규정함

(5) 목록

- 기능성 (Functionality)

- 신뢰성 (Reliability)

- 사용성 (Usability)

- 효율성 (Efficiency)

- 유지 보수성 (Maintainability)

- 이식성 (Portability)

 

 

 

2.UI 요소

(1) 체크 박스(Check Box) : 여러 개의 선택 상황에서 1개 이 상의 값을 선택할 수 있는 버튼임
(2) 라디오 버튼(Radio Button) : 여러 항목 중 하나만 선택할 수 있는 버튼임
(3) 텍스트 박스(Text Box) : 사용자가 데이터를 입력하고 수 정할 수 있는 상자임
(4) 콤보 상자(Combo Box) : 이미 지정된 목록 상자에 내용 을 표시하여 선택하거나 새로 입력할 수 있는 상자임
(5) 목록 상자(List Box) : 콤보 상자와 같이 목록을 표시하지 만 새로운 내용을 입력할 수 없는 상자임

 

 

---

 

1. 소프트웨어 아키텍쳐 설계의 기본 원리

(1) 모듈화 (Modularity) 

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

(3) 단계적 분해 (Stepwise Refinement)

(4) 정보 은닉 (Information Hiding)

 

 

 

 

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

(1) 시스템 측면 
(2) 비즈니스 측면 
(3) 아키텍처 측면

 

 

 

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

(1) 설계 목표 설정

(2) 시스템 타입 결정

(3) 아키텍처 패턴 적용

(4) 서브시스템 구체화

(5) 검토

 

 

 

4. 협약(Contract)에 의한 설계

(1) 선행 조건 (Precondition) : 오퍼레이션이 호출되기 전에 참이 되어야 할 조 건 

(2) 결과 조건 (Postcondition) : 오퍼레이션이 수행된 후 만족되어야 할 조건

(3) 불변 조건 (Invariant) : 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건

 

---

 

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

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

(2) 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이하다.
(3) 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능하다.
(4) 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용된다.
(5) 대표적으로 UNIX의 쉘(Shell)이 있다.

 

 

 

 

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

(1) 모델(Model) : 서브시스템의 핵심 기능과 데이터를 보관 함

(2) 뷰(View) : 사용자에게 정보를 표시함

(3) 컨트롤러(Controller) : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄

 

 

 

 

3.  기타 패턴

(1) 마스터-슬레이 브 패턴 (Master-Slave Pattern) : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작 업을 분할한 후, 슬레이브 컴포넌트에서 처리 된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴

(2) 브로커 패턴 (Broker Pattern) : 사용자가 원하는 서비스와 특성을 브로커 컴 포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해줌

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

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

(5) 블랙보드 패턴 (Blackboard Pattern)

(6) 인터프리터 패턴 (Interpreter Pattern) 

 

 

 

 

4. 객체(Object)

(1) 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡 슐화한) 하나의 소프트웨어 모듈이다.  

(2) 객체는 독립적으로 식별 가능한 이름을 가지고 있다. 

 

---

 

1. 클래스(Class)

(1) 공통된 속성과 연산(행위)을 갖는 객체의 집합으 로, 객체의 일반적인 타입(Type)을 의미한다

(2) 클래스는 각각의 객체들이 갖는 속성과 연산을 정의하 고 있는 틀이다. 
(3) 클래스는 객체지향 프로그램에서 데이터를 추상화하는 단위이다.
(4) 클래스에 속한 각각의 객체를 인스턴스(Instance)라 하 며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴 스화(Instantiation)라고 한다.  

 

 

 

 

2. 캡슐화(Encapsulation)

(1) 데이터(속성)와 데이터를 처리하는 함수를 하나 로 묶는 것을 의미한다. 

(2) 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은 폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문 에 외부 모듈의 변경으로 인한 파급 효과가 적다. 
(3) 캡슐화된 객체들은 재사용이 용이하다. 
(4) 객체들 간의 메시지를 주고받을 때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다.

 

 

 

 

3. 상속(Inheritance)

(1) 이미 정의된 상위 클래스(부모 클래스)의 모든 속성 과 연산을 하위 클래스(자식 클래스)가 물려받는 것이다

(2) 상속을 이용하면 하위 클래스는 상위 클래스의 모든 속 성과 연산을 자신의 클래스 내에서 다시 정의하지 않고 서도 즉시 자신의 속성으로 사용할 수 있다. 
(3) 하위 클래스는 상위 클래스로부터 상속받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용할 수 있다.

 

 

 

 

4. 다형성(Polymorphism)

(1) 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체(클래스)가 가지 고 있는 고유한 방법(특성)으로 응답할 수 있는 능력을 의 미한다.

(2) 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의 미의 응답을 한다.
(3) 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이 상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것이다.

 

---

 

 

 

1. 객체지향 분석의 방법론

(1) Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방 법으로 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법

(2) Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거 시적(Macro) 개발 프로세스를 모두 사용하는 분석 방 법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함

(3) Jacobson 방법 : Use Case를 강조하여 사용하는 분석 방법

(4) Coad와 Yourdon 방법 : E-R 다이어그램을 사용하여 객 체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법

(5) Wirfs-Brock 방법 : 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하 는 기법

 

 

 

 

 

2. 럼바우(Rumbaugh)의 분석 기법

(1) 분석 활동은 ‘객체 모델링 → 동적 모델링 → 기능 모델 링’ 순으로 통해 이루어진다.

(2) 객체 모델링 (Object Modeling) : 정보 모델링이라고도 하며, 시스템에서 요구되는 객 체를 찾아내어 속성과 연산 식별 및 객체들 간의 관 계를 규정하여 객체 다이어그램으로 표시하는 것

(3)  동적 모델링 (Dynamic Modeling) : 상태 다이어그램(상태도)을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링

(4) 기능 모델링 (Functional Modeling) : 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모 델링

 

 

 

 

 

3. 객체지향 설계 원칙

(1) 단일 책임 원칙 (SRP, Single Responsibility Principle) : 객체는 단 하나의 책임만 가져야 한다는 원칙

 

(2) 개방-폐쇄 원칙 (OCP, Open- Closed Principle : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙

 

(3) 리스코프 치환 원칙 (LSP, Liskov Substitution Principle) :  자식 클래스는 최소한 자신의 부모 클래스에 서 가능한 행위는 수행할 수 있어야 한다는 설 계 원칙

 

(4) 인터페이스 분리 원칙 (ISP, Interface Segregation Principle) : 자신이 사용하지 않는 인터페이스와 의존 관 계를 맺거나 영향을 받지 않아야 한다는 원칙

 

(5) 의존 역전 원칙 (DIP, Dependency Inversion Principle) : 각 객체들 간의 의존 관계가 성립될 때, 추상 성이 낮은 클래스보다 추상성이 높은 클래스 와 의존 관계를 맺어야 한다는 원칙