정보처리기사 1과목

제가 정리한 자료입니다. 저는 이 정리된 자료로 합격했습니다.!

 

1.시스템의 구성요소

- 입력, 처리, 출력, 제어, 피드백

 

2. 유스케이스

- 정의 : 시스템이 액터에게 제공해야 하는 기능으로, 시스템의 요구사항이자 기능을 의미

- 유스케이스 다이어그램 : 사용자의 요구를 추출하고 분석하기 위해 주로 사용

- 액터 : 대상 시스템과 상호작용하는 사람 혹은 시스템

- 사용자 액터 : 기능을 요구하는 대상이나 시스템의 수행결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상으로 제공해야하는 기능인 유스케이스의 권한을 가지는 대상, 역할

- 시스템 액터 : 사용자 액터가 사용한 유스케이스를 처리해주는 외부 시스템, 시스템의 기능 수행을 위해서 연동이 되는 또 다른 시스템 액터를 의미

 

- Usecase 구성요소와의 관계

1) 연관 : use case와 actor의 관계

2) 확장 : 기본 use case 수행 시 특별한 조건을 만족할 때 수행할 usecase

3) 포함 : 시스템의 기능이 별도의 기능을 포함

4) 일반화 : 하위 use case/action이 상위 use case/actor에게 기능/역할을 상속받음

5) 그룹화 : 여러개의 usecase를 단순화하는 방법

 

3. 요구사항 개발 프로세스

- 도출 -> 분석 -> 명세 -> 확인

 

4. 객체지향 기법

instnace : 같은 클래스에 속한 각각의 객체

message : 객체에게 어떤 행위를 하도록 지시하는 명령(객채의 행위를 표현)

method : 객체에 소속된 함수를 의미

class : 데이터를 추상화

module : 실행코드와 객체들(함수, 클래스, 변수)의 묶음

Polymorphism(다형성) : 파생된 클래스와 관련되면서 또 다른 행위를 요구하는 것

Inheritance(상속) : 하나의 클래스가 다른 클래스로부터 애트리뷰트나 메소드를 물려받는 것

캡슐화(Encapsulation)

- 서로 관련성이 많은 데이터와 이와 관련도니 함수들을 한 묶음으로 처리하는 기법

- 결합도가 낮아지고 재사용이 용이

- 인터페이슥 단순화 됨

- 정보은닉과 관계가 깊음

- 변경 발생 시 오류의 파급효과가 적음

집단화 : is part of

- 클래스 간의 구조적인 집약 관계

- “클래스 A는 클래스 B와 클래스 C로 구성된다.”

 

추상화

- 공통 성질을 추출하여 수퍼클래스로 구성한다. 또한 객체 중심의 안정된 모델 구축 가능하고 현실 세계를 자연스럽게 표현한다. 장점으로 분석의 초점이 명확해진다.

 

5. GoF (Gangs of Four) 디자인 패턴

정의 : 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

- 장,단점

: 객체지향 설계/구현 위주 : 디자인 패턴은 객체지향 설계/구현에 많이 사용

: C언어를 주로 사용하는 구조적 설계/구현에서도 사용할 수 있지만 너무 복잡해서 큰 도움이 되지 않는다.(즉 절차형 언어와 함께 이용될 때 효율이 극대화 X)

 

1) 생성패턴 : 객체를 생성하는 것에 대한 패턴

- Abstract Factory pattern (추상팩토리) : 동일한 주제의 다른 팩토리를 묶어 준다.

- Builder pattern(빌더패턴) : 생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성

- factory method pattern

- 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 하는 방식

-> 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정하도록 하는 것

=> Virtual-Constructor 패턴

 

- prototype pattern : prototype을 먼저 생성하고 인스턴스를 복제하여 사용하는 구조

- Singleton patten : 한 클래스에 한 객체만 존재하도록 제한한다.

 

★ 추상 패턴은 없고, 생성 패턴으로 추상팩토리가 있따.

 

2) 구조 패턴 : 구조를 통해 확장성을 꾀하는 패턴

- Adapter pattern(어댑터 패턴) : 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 한다.

- bridge patten(브릿지 패턴) : 구현분에서 추상층 분리하여 각자 독립적으로 확장이 가능하게 하는 패턴

- Composite pattern(컴포지트 패턴) :

- decorator pattern(데코레이션 패턴) : 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있다.

- 퍼사드 패턴ㄹ

- 플라이웨잇 패턴

- 프록시 패턴

 

3) 행위 패턴 : 행위의 변경, 수정 등을 위한 패턴

- 역할 사슬 패턴

- 커맨더 패턴

- 인터프리터 패턴

- 이터레이터 패턴

- ~~~~ 개많음

- mediator pattern : 객체간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해준다.

- state pattern(상태)：동일한 동작을 객체의 상태에 따라 다르게 처리해야 할 때 사용하는 디자인 패턴

 

6. 요구사항 분석이 어려운 이유?

- 개발자와 사용자 간의 지식이나 표현의 차이의 커서 상호 이해가 쉽지 ㅇ낳다.

- 사용자 요구는 예외가 많아 열거와 구조화가 어렵다

- 사용자의 요구사항이 모호하고 불명확하다

- 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.

 

7. 시스템 품질 속성

- 가용성, 변경용이성, 성능, 보안성, 사용편의성, 시험용의성

8. 연계시스템 구성

- 송신 시스템 : 연계할 데이터를 DB와 어플리케이션으로부터 연계테이블 또는 파일 형태로 생성하여 송신

- 수신 시스템 : 수신한 연계테이블, 파일데이터를 수신시스템에서 관리하는 데이터 형식에 맞게 변환하여 DB에 저장하거나 애플리케이션에서 활용할 수 있도록 제공

- 중계 서버 : 송/수신 시스템 사시에서 데이터를 송수신하고, 연계데이터의 송수신 현황을 모니터링함, 연계데이터의 보안강화 및 다중플랫폼 지원 등이 가능

 

9. CASE(=컴퓨터 지원 시스템공학)

- 구조적 기법, 프로토타이핑 기술, 자동프로그래밍 기술, 정보 저장소 기술, 분산 처리 기술

- 정의 : 시스템 개발과정의 일부 또는 전체를 자동화시킨 것(개발자의 반복적인 업무를 줄이기위해서)

- 1980년대 소개 1990년대부터 자주 사용

설명

1) 소프트웨어 모듈의 재사용성이 향상

2) 자동화된 기법을 통해 소프트웨어 품질이 향상

3) 소프트웨어 유지보수를 간편하게 수행할 수 있다.

4) 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리, 표준 준수여부 확인

 

틀린 보기: 소프트웨어 사용자들에게 사용 방법을 신속히 숙지! -> 시키는 것은 아님

 

특징

- 소프트웨어 생명주기를 전체 단계를 연결해 주고 자동화해주는 통합된 도구를 제공

- 소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 제공

1) 소프트웨어(S/W) 라이플 사이클 전 단계의 연결

2) 그래픽 지원

3) 다양한 소프트웨어 개발 모형 지원

 

상위 CASE

- 요구 분석과 설계 단계를 지원

- 모델들 사이의 모순검사 기능

- 모델의 오류 검증 기능

- 자료흐름도 작성 기능

 

- 하위 CASE : 코드를 작성하고 테스트하며 문서화하는 과정 지원 – 원시코드 생성 기능

 

- 통합 CASE : 소프트웨어 개발 주기 전체과정을 지원

 

10. 아키텍처 스타일

- 클라이언트 서버 구조 : 컴포넌트가 다른 컴포넌트에게 서비스를 요청, 데이터가 여러 컴포넌트를 거치며 처리(하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴)

- 계층 구조 : 모듈들로 응집된 계층 단위로 SW를 구성. 계층간에 사용 가능의 관게를 표현

- MVC 구조 : 모델-뷰-컨트롤러, 기능을 분리한 아키텍쳐

- 파이프 필터 : 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송(서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업)

- 레이어 패턴 : 시스템을 계층으로 구분하여 구성

- 모델-뷰-컨트롤러 패턴 : 서브시스템을 3개의 부분으로 구조화하는 패턴

 

10. UML 다이어그램 - 액시디콜콤클

- 기능적 모델은 사용자 측면에서 본 시스템 기능이며, UML에서는 Use case Diagram을 사용

- 동적 모델은 시스템의 내부 동작을 말하며, UML에서는 Sequence, State, activity

- Activity 다이어그램 : 업무의 흐름을 모델링하거나 객체의 생명 주기를 표현(시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 ᄄᆞ른 처리의 흐름을 순서에 따라 표현)

- Behavioral Diagram에 속한다

 

- Sequence 다이어그램 : 객체 간의 메시지 전달을 시간적 흐름을 분석(객체들 사이의 메시지교환)

 

- Collaboration 다이어그램 : 객체와 객체가 주고받는 메시지 중심의 작성, 동적 다이어그램

 

- 모름-

- Component 다이어그램 : 소프트웨어 구조를 그림

 

- 정적 모델은 객체, 속성, 연관관계, 오퍼레이션의 시스템의 구조를 나타내며 UML - Class

- Class 다이어그램 : 시스템의 구조적인 모습을 그림(클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다. 시스템의 구졸르 파악하고 구조상의 문제점을 도출할 수 있다.

- State Diagram : 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서(하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현

- Deployment 다이어그램 : 기업 환경의 구성과 컴포넌트들 간의 관계

 

11. UML 모델

- Dependency(의존) : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것을 말한다

- Realization(실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정

- Generaliztion(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말한다(‘is-a’관계)

- Association(연관) : 두 사물간의 구조적 관계로, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함(‘has-a’관계)

 

12. 애자일 개발 방법론

* 핵심가치 4가지

1) 프로세스와 도구보다는 개인과의 상호작용에 더 가치

2) 방대한 문서보다는 실행되는 SW에 더 가치를 둠

3) 계약 협상보다는 고객과의 협업에 더 가치를 둠

4) 계획을 따르기 보다는 변화에 반응하는 것에 더 가치르 둠

 

- 익스트림 프로그래밍(XP) 단소피용준

- 5원칙 : 단순성, 소통, 피드백, 용기, 존중

- 스크럼크리스털 패밀리

- 기능 주도 개발(FDD, Feature-Driven Developement)

- 익스트림 모델링

 

13. 리눅스 명령어

- ls : List, 디렉토리 목록 출력

- cat : 파일출력, 두 개 이상의 파일 연결

- pwd : Print Working Directory, 현재 디렉토리 출력

- uname : 시스템 정보를 출력(버전 확인)

 

14. 시스템 연계 기술

1) DB링크

- 데이터베이스에서 제공하는 DB 링크 객체를 이용한다

- 수신측에서 DB 링크를 생성하고 송신측에서 해당 DB링크를 직접 참조하는 방식

2) DB 커넥션

- 수신측의 WAS에서 송신측 데이터 베이스로 연결하는 DB Connection Pool을 생성

3) API/OpenAPI : 송신측의 데이터베이스에서 데이터를 가져와 제공하는 응용 프로그래밍 인터페이스 프로그램

4) JDBC

- 수신측의 프로그램에서 JDBC 드라이버를 이용해 송신 시스템 데이터베이스와 연결

- DBMS 유형, DBMS 서버 IP와 Port, DB Instance 정보가 필요하다

5) 하이퍼링크 : 웹 응용에서 하이퍼링크를 이용한다

6) 소켓

- 서버는 통신을 위한 Sockect을 생성하여 포트를 할당한다

- 클라이언트의 통신 요청 시 클라이언트와 연결하고 통신하는 네트워크 기술

 

 

15. 미들웨어

- WAS : 어플리케이션 수행 미들 웨어

- MOM : 메시지 지향 미들웨어

- RPC : 원격 프로시저 호출

- ORB : 네트워크 호출 미들웨어

- TP monitor : 트랜잭션이 올바르게 처리되고 있는지 데이터를 감시/제어

- 미들웨어 솔루션 : 컴퓨터와 컴퓨터간의 연결을 쉽고 안전하게 할 수 있도록 해주고 이에 대한 관리를 도와주는 소프트웨어

 

16. 객체지향 분석 방법론

1) Booch(부.치)

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

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

- 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링

- 개체모델링 동적 모델링 기능 모델링

2) Jacobson(제이콥슨)

- Use Case를 사용하여 분석(사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용하는 방법을 기술)

3) Coad-Yourdon

- E-R 다이어그램을 사용해 객체의 행위를 모델링

- 객체 식별, 구조 식별

4) Wirfs-Brock

- 분석과 설계간 구분이 없으며, 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행

 

17. 현행 시스템 분석

- 플랫폼 기능 분석, 플랫폼 성능 특성 분석, 운영체제 분석, 네트워크 분석, DBMS 분석, 비즈니스 융합 분석

 

18. 객체지향 분석 – 업무(비즈니스)를 객체, 속성 등의 개별요소로 추상화 하는 기법

 

19. 럼바우(Rumbaugh) 객체지향 분석 기법

1) 객체

– 가장 중요시 선행(세 가지 모델 중 가장 중요)

- 시스템에서 요구되는 객체를 찾아내 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시

 

2) 동적

– state

- 상태 다이어그램(상태도)를 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동적 순서 등의 동적인 행위를 표현

 

3) 기능

– 자료의 흐름(DFD)을 이용해 다수의 프로세스간의 자료 흐름을 중심으로 처리 과정을 표현

 

20. 객체지향 설계 원칙(SOLID)

1) 단일 책임 원칙(SRP) : 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야함

2) 개방 폐쇄의 원칙(OCP) : 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

3) 리스코프 교체(치환)의 원칙(LSP) : 컴퓨터 프로그램에서 자료형

- S가 자료형 T의 하위형이라면 필요한 프로그램의 속성의 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환)할 수 있어야 한다는 원칙

4) 인터페이스 분리 원칙(ISP) : 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙

5) 의존성 역전 원칙(DIP) : 의존 관계를 맺을 때 변화하기 쉬운 것보다 변화하기 어려운 것에 의존하라는 원칙

 

21. 코드 정의

- 데이터를 사용 목적에 따라 식별, 분류, 배열하기 위하여 사용되는 숫자, 문자 또는 기호로 컴퓨터 처리에 효율적인 것을 선정

종류

1) 순차 코드 : 자료의 발생순, 크기순, 가나다순 등 일정 순서대로 코드

2) 블록 코드(구분코드) - 코드화 대상을 미리 파악하여 블록으로 구분한 후 그 안에서 순서대로 코드를 부여

3) 그룹 분류 코드 – 구분 코드를 세분화한 형태로 대분류, 중분류, 소분류 등 각 분류별로 자릿수를 구성

4) 표의 숫자 코드 – 표현하려는 대상의 의미는 제외하고 수치만을 모아 만든 것으로 대상이 되는 물체의 중량, 면적, 크기 등을 직접 코드에 적용

5) 십진 분류 코드 – 코드화 대상물을 일정한 소속으로 구분하여 십진수 한 자리씩 구분하여 대분류하고, 같은 방법으로 중분류, 소분류한 코드

6) 연상 코드 – 숫자나 문자를 조합해서 나타내는 것으로 어떤 내용을 기억할 수 있도록 표시한 기호 코드

7) 약자 코드 – 일반적으로 사용해온 단위의 약자를 코드로 사용

8) 끝자리 분류 코드 – 다른 종류의 코드와 조합해서 사용하며, 코드의 끝에 붙여서 그 의미를 표현

 

 

22. DFD(data flow diagram)

1) 자료 흐름 그래프 또는 버블 차트라고 한다.

2) 구조적 분석 기법에 이용된다.

3) 시간 흐름을 명확하게 표현할 수 없다.

4) DFD의 요소는 화살표, 원, 사각형, 직선(단선/이중선)으로 표시)

* 구성요소

Process, Data flow, data store, terminator

23. UML의 기본 구성요소

1) Things – 사물

2) Relationship – 관계

3) Diagram – 다이어그램

띵다리~

 

24. 소프트웨어의 하위설계

1) 모듈 설계

2) 인터페이스 작성 (정의 X)

 

25. 자료사전(Data Dictionary)

1) ‘=’ - 정의

2) ‘+’ - 구성

3) ‘[]’ - 택일

4) ‘{}’ - 반복

5) ‘()’ - 생략가능

6) ‘**’ - 설명

 

26. 소프트웨어의 사용자 인터페이스개발시스템(User Interface Development System)

1) 사용자 입력의 검증

2) 에러 처리와 에러 메시지 관리

3) 도움과 프롬프트(prompt) 제공

- 소스코드분석 및 오류복구는 back-end에서 컴파일러가 하는 역할!

 

27. 요구사항 명세기법

1) 정형 명세법

- 수학적 기반/모델링 기반

- Z, VDM, Petri-Net(모형기반)

- CSP, CCS, LOTOS(대수적방법)

- 시스템 요구특성이 정확하고 명세가 간결하다. 명세와 구현이 일치

- 그러나 이해도가 낮으며 이해관계자의 작성 부담 가중

 

2) 비정형명세

- 상태, 기능, 객체 중심 명세법

- FSM(Finite state machine)

- Decision Table, ER모델링

- State chart(SADT)

- UseCase: 사용자기반모델링

- 명세 작성이 간편하고 의사전달 방법이 다양

- 불충분한 명세가능성, 모호성

 

28. 소프트웨어 개발 단계에서 요구 분석 과정

1) 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다.

2) 자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.

3) 보다 구체적인 명세를 위해 소단위 명세서(MIini-Spec)가 활용될 수 있다.

- 개발 비용이 가장 많이 소요되는 단계는 유지보수

 

29. 모듈 간의 결합도가 약할수록 좋다(반대로 응집도는 강할수록좋다)

 

30. 요구사항 분석 시에 필요한 기술

 

* 요구사항 개발 프로세스 : 도출 → 분석→ 명세(설계명세서작성) → 확인

- 도출 단계 : 인터뷰, 설문, 브레인스토밍 등이 있어 청취와 인터뷰 질문 기술 필요

- 분석

: 관찰 및 모델 작성 기술(개념모델링이 있어서), 요구사항 분류, 할당, 협상

: 비용과 일정에 대한 제약설정

: 타당성 조사

: 요구사항 정의 문서화

 

31. UML에서 시퀀스(Sequence) Diagram의 구성 항목

1) 액터

2) 활성 객체(Object)

3) 라이프라인(생명선)

4) 메시지

5) 제어 삼각형

 

32. 협약의 의한 설계(Desgin by Contract)

- 클래스에 대한 여러 가정을 공유하도록 명세한 것

- 소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행,결과,불변조건을 나타내는 설계 방버

 

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

2) 결과조건(postcondition) : 오퍼레이션이 수행된 후 만족하여야 하는 조건

3) 불변조건(invariant) : 클래스 내부가 시랭되는 동안 항상 만족하여 하는 조건( 예: 리스트에 있는 노드가 항상 오름차순으로 되어야 함)

 

33

- 일반화 관계

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

- 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)이라고 함

- 하위 사물에서 상위 사물인 쪽으로 속이 빈 화살표를 연결

 

34. 인터페이스 요구 사항 검토(검증) 방법

1) 동료 검토(Peer Review) : 2-3명이 진행하는 리뷰형태, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견

2) 워크스루(Walk Through) : 검토 회의 전, 명세서를 미리 배포하여 사전검토 후에 짧은 검토 회의를 통해 결함 발견

3) 인스펙션(Inscpection) : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하면서 결함을 발견

 

35. 코드

1) 연상 코드 - 항목의 명칭이나 약호와 관계 있는 숫자, 문자, 기호를 이용해 코드를 부여

2) 블록 코드 - 대상 항목에서 공통적인 것을 블록으로 구분하고 블록 내에 일련 번호를 부여

3) 순차 코드 - 일정 기준에 따라 최초의 자료부터 일련번호를 부여

4) 표의 숫자 코드 - 길이, 넓이, 부피 등 항목의 성질의 물리적인 수치를 그대로 코드에 적용

 

* 연상 코드는 숫자 뿐만 아니라 문자 기호를 입력, 일련번호만은 only 순차코드

 

36. UML 확장 모델에서 스테레오 타입 객체를 표현할 때 사용하는 기호 - << >>

 

37. DBMS 분석 시 고려사항

1) 무결성(가용성)

2) 일관성(상호호환성)

3) 회복

4) 보안

5) 효율성(성능)

6) 데이터베이스 확장

 

* 틀린답 : 네트워크 구성도

 

38. HIPO(Hierarchy Input Process Output)

1) 하향식 소프트웨어 개발을 위한 문서화 도구

2) 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표가 있다.

3) 기능적 자료의 의존 관계를 동시에 표현할 수 있다.

4) 보기 쉽고 이해하기 쉽다.