102. SW 아키텍처 4+1 View : 고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법
- 사용사례관점 Use Case View : 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의
- 논리관점 Logical View : 상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의
- 구현관점 Implementation View : 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의
- 프로세스관점 Process View : 시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스를 정의
- 배치관점 Deployment view : 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의
103. SW 아키텍처 4+1 View : 고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법
- 사용사례관점 Use Case View : 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의
- 논리관점 Logical View : 상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의
- 구현관점 Implementation View : 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의
- 프로세스관점 Process View : 시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스를 정의
- 배치관점 Deployment view : 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의
104. 아키텍처 스타일 / 소프트웨어 설계 패턴 / 소프트웨어 아키텍처 프레임워크
- 아키텍처 스타일
- 아키텍처 스타일은 아키텍처의 유형
- 적절한 아키텍처 스타일의 선택은 대상시스템의 개발을 효율적이고 효과적으로 만들 수 있음
- 소프트웨어 설계 패턴
- 반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션
- 소프트웨어 아키텍처 프레임워크
- IEEE1471 : 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준 (ISO/IEC/IEEE 42010 표준)
- IEEE42010 : 시스템 및 SW 엔지니어링 아키텍처 기술과 관련된 용어와 개념을 정의한 국제표준
105. 객체지향의 구성
- 클래스 Class
- 같은 종류(또는 문제해결을 위한)의 집단에 속하는 속성과 행위를 정의한 것
- 객체지향 프로그램의 기본적인 사용자 정의 데이터형
- 객체 Object
- 클래스의 인스턴스
- 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행
- 속성 Attribute
- 객체의 데이터
- 메서드 Method
- 객체의 행위 : 함수, 메서드
- 클래스로부터 생성된 객체를 사용하는 방법
- 메시지 Message
- 객체 간의 통신
107. 객체지향의 기법
- 캡슐화 Encapsulation
- 속성(데이터)과 메서드(연산)를 하나로 묶어서 객체로 구성
- Readability 향상 : 유지보수가 용이
- 재사용성이 높은 S/W 개발이 가능
- 객체간 인터페이스를 이용, 종속성을 최소화
- 추상화 Abstraction
- 공통성질을 추출하여 슈퍼클래스로 구성
- 객체중심의 안정된 모델을 구축
- 현실 세계를 자연스럽게 표현
- 분석의 초점이 명확해짐
- 다형성 Polymorphism
- 동일한 이름의 여러 오퍼레이션(메서드)를 다른 사양으로 정의 가능
- 오버로딩 : 매개변수의 수 또는 타입을 달리하여 구분
- 오버라이딩 : 부모클래스의 메서드를 재정의
- 정보은닉 Information Hiding
- 캡슐화된 항목을 다른 객체로부터 숨김
- 메시지 전달에 의해 다른 클래스 내의 메서드가 호출됨
- 상속성 Inheritance
- 부모 클래스의 속성과 메서드를 상속받아 사용
- 부모와 자식 클래스 간의 관계가 슈퍼클래스와 서브클래스로 유지됨
- 부모 클래스는 추상적, 자식 클래스는 구체적 성질을 가짐
109. 다형성의 기법
구분 | 오버로딩 Overloading | 오버라이딩 Overriding |
개념 | 하나의 클래스 내에서 같은 이름으로 여러 개의 메서드를 정의 | 상속관계인 상위 클래스의 메서드를 하위클래스에서 재정의 |
메서드명 | 특정 클래스 내 동일 | 상속관계 내 동일 |
매개변수개수, 타입 | 개수 또는 타입이 다름 | 반드시 동일 |
리턴 타입 | 상관없음 | 기본적으로 동일 |
접근제한 | 상관없음 | 범위가 같거나 넓어야 함 |
Code | public class Employee{ public String name; public int age; //print() aptjem public void print() { System.out.println("이름:" + this.name + "나이는" + this.age); } } //Employee 상속 public class Manager extends Employee { String jobOfManage; //print() 메서드 오버라이딩 public void print(){ System.out.printIn("이름:" + this.name + "나이:" + this.age); System.out.printIn("관리자" + this.name + this.jobOfManage + "담당"); } } |
public class Overloadingtest { //test() 호출 void test(){ System.out.printIn("매개변수 없음"); } //test에 매개변수로 int형 2개 호출 void test(int a, int b) { System.out.printIn("매개변수" + a + "와" + b); } //test에 매개변수 double형 1개 호출 void test(double d){ System.out.printIn("매개변수" + d); } } |
Test Code | public class test { public static void main(String[] args) { //Manager 객체 생성 Manager lee = new Manager(); //변수 설정 lee.name = "홍길동"; lee.age = 30; lee.jobOfManage="프로젝트 매니저"; //Overring된 Manager객체 print() 호출 lee.print(); } } |
public class test { public static void main(String[] args) { //Overloadingtest 객체 생성 Overloadingtestob = new Overloadingtest(); //test() 호출 ob.test(); //test(int a, int b) 호출 ob.test(10, 20); //test(double d) 호출 ob.test(50); //test(double d) 호출 ob.test(123.4); } } |
111. 디자인패턴
목적 | 생성패턴 | 구조 패턴 | 행위 패턴 | |
의미 | 객체의 생성방식을 결정하는 패턴 | 객체를 조직화하는데 유용한 패턴 | 객체의 행위를 조직, 관리, 연합하는데 사용하는 패턴 | |
범위 | 클래스 | Factory method | Adapter | Template method Interpreter |
객체 | Singleton Abstract factory Builder Prototype |
Bridge Composite Decorator Façade Fly weight Proxy |
Iterator Command Chain of Responsibility State Strategy Mediator Memento Visitor Observer |
115. GoF의 디자인 패턴
목적 | 생성패턴 | 구조 패턴 | 행위 패턴 | |
의미 | 객체의 생성방식을 결정하는 패턴 | 객체를 조직화하는데 유용한 패턴 | 객체의 행위를 조직, 관리, 연합하는데 사용하는 패턴 | |
범위 | 클래스 | Factory method | Adapter | Template method Interpreter |
객체 | Singleton Abstract factory Builder Prototype |
Bridge Composite Decorator Façade Fly weight Proxy |
Iterator Command Chain of Responsibility State Strategy Mediator Memento Visitor Observer |
116. MVC 패턴의 구성
- 모델 Model
- 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보
- 통보를 통해서 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있음
- 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 함
- 뷰 View
- 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옴
- 컨트롤러 Controller
- 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있음
- 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시 방법을 바꿀 수 있음
117. 인터페이스
- 내외부 인터페이스
- 조직 내/외부에 존재하는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미
- 네트워크를 통해 조직 내/외부에 존재하는 시스템 간의 요구 기능을 수행하기 위해서 내외부 인터페이스 설계와 개발은 필수적
- 인터페이스 설계 능력
- 응용 소프트웨어 개발을 위해 정의된 시스템 인터페이스 요구사항을 확인
- 인터페이스 대상을 식별하여 인터페이스 설계서를 작성하는 능력
- 내외부 인터페이스
- 조직 내외부에 존재화는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미
- 내외부 인터페이스 요구 사항 분석
- 요구 사항 정의 단계에서 정의한 기능 및 비기능 내외부 인터페이스 요구 사항을 식별하고 분류, 조직화하여 명세를 구체화하는 작업
- 내외부 인터페이스 설계
- 네트워크를 통해 조직 내외부에 존재하는 시스템 간의 요구 기능을 구현하기 위한 설계를 의미
119. 요구공학
- 요구사항 분석
- 요구사항들 간 상충되는 것을 해결
- 소프트웨어 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지를 이해
- 요구사항을 정제하여 소프트웨어 요구사항을 정리하는 업무
- 요구사항 명세
- 요구사항을 체계적으로 검토, 평가, 승인될 수 있도록 문서를 작성하는 것을 의미
- 시스템의 정의 및 시스템 요구사항, 소프트웨어 요구사항을 작성하는 업무
- 요구사항 확인
- 분석가가 요구사항을 이해했는지 확인이 필요
- 요구사항 문서가 조직의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증하는 것이 중요, 이러한 활동을 수행하는 업무
120. 요구공학의 프로세스
- 요구사항 개발의 절차 : 도출 → 분석 → 명세 → 확인
- 도출 Elicitation
- 소프트웨어가 해결해야 할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련
- 활용기법 : 인터뷰, 시나리오, 작업분석, BPR, 프로토타이핑, RFP, 워크샵, 벤치마킹
- 분석 Analysis
- 요구사항들 간의 상충을 해결하고 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지 이해
- 활용기법
- 구조적 분석 : DFD, Data Dictionary, mini Spec, ERD
- Use Case 기반 분석 : UML, 모델링
- 명세 Specification
- 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 것
- 활용기법 : ER 모델링, FSM, SADT (구조적 분석과 디자인 기술)
- 확인 / 검증 Validation / Verification
- 분석가가 요구사항을 이해했는지에 대한 확인이 필요
- 요구사항 문서가 조직의 표준에 부합하고 이해 가능하며 일관성 있고 완전한지에 대한 검증이 중요
- 활용기법
- Verifiaction 검증 : 소프트웨어 개발 라이프사이클의 각 단계의 산출물이 이전 단계에서 설정된 개발규격과 요구들을 충족시키는지의 여부를 판단하기 위한 활동
- Validation 확인 : 소프트웨어 개발 라이프사이클의 각 단계의 산출물이 최초 사용자 요구 또는 소프트웨어 요구에 적합한지를 입증하기 위한 활동
- 도출 Elicitation
- 요구사항 관리
- 요구사항 협상 : 가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법
- 요구사항 기준선 : 공식적으로 검토되고 합의된 요구사항 명세서
- 요구사항 변경 관리 : 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
- 요구사항 확인 : 구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 방법
121. 비기능적 요구사항
- 시스템 장비 구성 요구사항 : 하드웨어, 소프트웨어, 네트워크 등의 도입 장비 내역 등
- 성능 요구사항 : 처리속도 및 시간, 처리량, 동적정적 용량, 가용성 등
- 인터페이스 요구사항 : 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항
- 데이터 요구사항 : 초기자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등
- 테스트 요구사항
- 보안 요구사항 : 정보 자산의 기밀성과 무결성을 확보하기 위해 필요한 사항
- 품질 요구사항 : 품질 항목, 품질 평가 대상 및 목표 (신뢰성, 사용성, 유지관리성 등)
- 제약사항 : 기술, 표준, 업무, 법제도 등 제약조건 등을 파악하여 기술
- 프로젝트 관리 요구사항 : 관리 방법 및 추진 단계별 수행방안에 대한 요구사항을 기술
- 프로젝트 지원 요구사항 : 지원사항 및 방안에 대한 요구사항을 기술
125. 시스템 아키텍처의 기본 요구사항
- 시스템 구성 및 동작 원리를 나타내고 있음
- 시스템 구성 요소에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술 : IEEE 1471, TOGAF 등
- 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사
- 요구 사양 및 시스템의 전체 수명주기를 고려
- 하드웨어와 소프트웨어를 포함하는 시스템 전체에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식, 시스템의 전체적인 최적화를 목표로 함
127. 소프트웨어 아키텍처
- 소프트웨어 시스템의 구조를 비롯한 시스템 개발에 중요한 영향을 미치는 결정들
- 소프트웨어 시스템 개발에서 특정 시스템에 대하여 요구되는 기능과 품질을 확보하고 또한 소프트웨어 시스템의 구축 및 지속적인 개선이 용이하도록 하는 역할
- 소프트웨어 시스템의 컴포넌트들을 식별하고 그 속성을 정의
- 컴포넌트들 사이의 커뮤니케이션 방법 및 물리적 배치 등을 포함하는 시스템의 구조
- 이해관계자들 간의 원활한 의사소통 수단
- 소프트웨어의 복잡성 증가에 따른 해결 대안
- 시스템의 추상적인 표현을 사용하여 복잡도를 관리
129. 모듈을 제어 관련 용어
- 공유도 Fan-in : 어떤 모듈을 제어(호출)하는 상위 모듈의 개수
- 제어도 Fan-out : 어떤 모듈에 의해 제어(호출)되는 하위 모듈의 개
131. 개체정의서
- 데이터베이스 개념 모델링 단계에서 도출한 개체의 타입과 관련 속성, 식별자 등의 정보를 개괄적으로 명세화한 정의서
- 개체 타입명 : 데이터베이스에 저장할 개체를 대표할 수 있는 이름
- 속성 : 개체의 특징 또는 설명 정보
- 식별자 : 해당 개체를 유일하게 식별할 수 있는 속성 (주식별자, 대체 식별자)
133. 데이터베이스 기술
- DB Link : 데이터베이스에서 제공하는 DB Link 객체를 활용한 연계 기술
- DB Connection : 송신 시스템 DB로 연결하는 DB Connection Pool을 생성하고 연계 프로그램에서 해당 DB Connection Pool을 이용하는 기술, API/OpenAPI, JDBC, Hyper Link 등
- Socket 소켓 : 통신을 위한 프로그램으로 포트를 할당하고 클라이언트의 통신 요청 시 클라이언트와 연결하는 연계 기술
- Web Service 웹 서비스 : WSDL, UDDI, SOAP 프로토콜을 이용하여 연계하는 연계 기술
135. 인터페이스 연계 서버의 기능과 관련된 장애, 오류
- 시스템 연계 과정에서 발생할 수 있는 장애나 오류의 유형
- 연계 시스템의 장애
- 송신 시스템의 연계 프로그램 오류 : 연계 데이터를 생성하거나 추출하는 과정, 코드 및 데이터를 변환하는 과정에서 발생할 수 있음
- 연계 데이터 자체 오류
- 수신 시스템의 연계 프로그램 오류 : 운영 DB에 데이터를 반영하거나 코드 및 데이터를 변환하는 과정에서 발생
136. 인터페이스 보안 코딩
- 인터페이스 보안 기능 : 아마호화 알고리즘은 DES보다는 AES 알고리즘을 적용
- 민감정보가상화 : 인터페이스 데이터 중 민간정보(주민번호, 전화번호 등)는 비식별화 조치
- 인증 보안 수행 : 인터페이스 수행에 필요한 인증 수행 (보안 토큰 소유 확인)
- 이상 거래 감지 : 외부 불법 접근 시도, 무작위 공격행위 탐지 기능
- 필드 암/복호화 : 정의된 보안 필드를 인터페이스하기 전 암/복호화
- 필드 필터링 : 필드 필터링을 통해 필수 정보만을 제공
- 암호화 키 전송 : UI에 Field 암호화, Hash를 위한 암호화 Key를 반환하는 기능
- 파일 암/복호화 : 파일서버에 저장된 파일을 암/복호화하는 기능
- 체크성 : 송/수신 시스템 간 체크성 검증하여 메시지 위변조를 확인
- 중요 인터페이스 데이터 암호화 저장
- 개인정보, 금융정보, 패스워드 등 중요 인터페이스 정보는 암호화하여 저장
- 중요 인터페이스 데이터 암호화 전송
- 민감한 정보를 통신 채널을 통하여 내보낼 때에는 반드시 암호화 과정을 거쳐야 하며, 필요할 경우 SSL 또는 HTTPS 등과 같은 보안 채널을 사용
137. 인터페이스 처리 유형
- 동기 거래 Sync : 요청서비스에서 응답메시지를 즉시 받아 처리하는 거래
- 비동기 거래 Async : 요청결과 수신서비스에서 응답 메시지를 대신 받아 처리
- 지연 거래 Deferred : 메시지를 수신 시스템에 일정시간을 간격을 두고 반영하는 거래
- 파일 거래 File : 송수 파일을 수신 시스템에서 Batch 처리로 반영하는 거래
138. 미들웨어 솔루션의 유형
- RPC : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
- MOM : 메시지 기반의 비동기형 메시지 전달 방식 미들웨어로 서로 다른 이기종 분산 데이터 시스템의 데이터 동기를 위하여 주로 사용
- ORB : 코바 CORBA 표준 스펙을 구현한 객체지향 미들웨어
- WAS : 웹환경을 구현하기 위한 미들웨어, 기능은 자바, EJB 컴포넌트 기반으로 구현 가능
- TP-모니터 : 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합
144. 자료 사전의 기호
- = : 자료의 정의, A는 ~로 구성
- + : 자료의 연결, A와 B를 연결
- ( ) : 자료의 생략, 없어도 되는 자료
- [ | ] : 자료의 선택, A이거나 B
- { } : 자료의 반복
- ** : 자료의 설명
145. 미들웨어 아키텍처
- DB 접속 미들웨어 : 데이터베이스 제품 제작업체에서 제공하는 어플리케이션과 데이터베이스를 연결해주는 미들웨어
- RPC : 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
- MOM : 메시지 기반의 비동기형 메시지 전달 방식 미들웨어로 서로 다른 이기종 분산 데이터 시스템의 데이터 동기를 위하여 주로 사용
- ORB : 코바 CORBA 표준 스펙을 구현한 객체지향 미들웨어
- WAS : 웹환경을 구현하기 위한 미들웨어, 기능은 자바, EJB 컴포넌트 기반으로 구현 가능
- TP-모니터 : 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합
148. 동료검토 / XP의 12가지 실천사항
- 동료 검토
- 동료 검토의 절차
- 계획 : 관련 자료 수집, 구성원 역할 배정
- 사전준비 : 검토 항목, 범위 설정, 검토 설명
- 개별 검토 : 개별적 산출물 검토 진행
- 검토 회의 : 산출물 오류, 결함, 조치 사항 회의
- 재작업 : 오류, 결함 사항 분석, 조치
- 후속조치 : 저자가 작성 내용 반영 여부 판별
- 동료 검토의 구성 요소
- 관찰 대상 범위 : SDLC 단계별 산출물 범위 확인
- 참여자 구성원 : 중재자, 검토자, 저자, 기록자 등
- 체크리스트 : 산출물의 추적도, 설계 구현 내용
- 동료 검토의 절차
- XP의 12가지 실천사항 Practice
- Planning game
- 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정
- 비즈니스 우선순위와 기술적 평가가 결합
- Small / Short releases
- 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈
- 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 약 2주 사이클로 볼 수 있도록 자주 새로운 버전 배포 유지
- Metaphor
- 공통의 name system 의사소통 및 공통 개념 공유
- 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것으로, 이해하기 쉬운 스토리로 이루어짐
- Simple design
- 당장 필요하지 않은 디자인 배제
- 항상 가능한 가장 간결한 디자인 상태 유지
- TDD
- 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야 하는지 스스로 깨우침
- 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인
- Refactioring
- 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성
- Pair programming
- 두사람이 함께 프로그램 Driver / Partner
- 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업
- Collective Code Ownership
- 팀의 모든 프로그래머가 소스코드에 대해서 공동 책임을 지는 것
- 시스템에 있는 코드는 누구든지 언제라도 수정 가능
- CI
- 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때마다 지속적으로 통합되고 동시에 테스트
- 40-hour week
- 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임하지 않도록 함
- Whole Team
- 개발 효율성을 위해 고객을 프로젝트에 상주시킴
- 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할
- Coding Standard
- 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함
- Planning game
'자격증 > 정보처리기사' 카테고리의 다른 글
[정보처리기사 필기] 기출문제 - 201 ~ 250. 오답노트 (1) | 2025.03.05 |
---|---|
[정보처리기사 필기] 기출문제 - 151 ~ 200. 오답노트 (2) | 2025.03.04 |
[정보처리기사 필기] 기출문제 - 051 ~ 100. 오답노트 (1) | 2025.02.28 |
[정보처리기사 필기] 기출문제 - 001 ~ 050. 오답노트 (0) | 2025.02.27 |
[정보처리기사 필기] 시스템 보안 구축 - 157. 보안 솔루션 (0) | 2025.02.26 |