정보처리기사 필기 소프트웨어설계 정리

1-9

 

01 플랫폼 성능 특성 측정 항목

 

경사응가

경과시간 / 사용률 / 응답시간 / 가용성

 

02 DBMS 현행 시스템 분석 시 고려사항

가성호기구

가용성 / 성능 / 상호 호환성 / 기술지원 / 구축비용

 

03 현행 시스템 분석에서 고려하지 않아도 되는 항목

현행 시스템 분석시에는

운영체제 현행 시스템 분석,
네트워크 현행 시스템 분석,
DBMS 현행 시스템 분석을 고려 한다

02 현행 시스템 분석을 위한 플랫폼 성능 특성 분석의 기법으로 옳지 않은 것

옳은것

사용자 인터뷰, 성능 테스트, 산출물 점검

 

기능테스트는 플랫폼 성능 특성분석이 아닌 테스트 단계에 활용

 

03 비즈니스 융합의 유형으로 옳지 않은 것

옳은것

고객가치(why), 공급 역량 (who), 시장 유통 (whom)

전통 유지형은 비즈니스 융합의 유형에 해당하지 않는다.

 

04 운영체제 분석 시 고려사항이 아닌 것

맞는것

품질측면 = 신뢰도/ 성능

지원측면 = 기술 지원 / 주변 기기 / 구축 비용

 

1-27

 

02 자료 사전에서 자료의 생략을 의미하는 기호

{} = 자료의 반복

** = 자료의 설명

= 자료의 정의. ~으로 구성되어있다.

() = 자료 생략 가능함

 

04 데이터 흐름도

프플스터

Process / Data Flow / Data Store / Terminator

 

05 DFD 요소별 표기 형태

Process 처리기 : 입력된 데이터를 원하는 형태로 변환하여 출력 = 원

데이터 흐름 : DFD의 구성요소들 간의 주고받는 데이터 흐름을 나타내는 요소 = 화살표

데이터 저장소 : 데이터가 저장된 장소를 나타내는 요소, 평행성 안에는 데이터 저장소의 이름을 넣음 = 평행선

단말 (Terminator) : 프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타내는 요소, 사각형 안에는 외부 엔티티의 이름을 넣음 = 사각형

 

06 UML 확장 모델에서 스테레오 타입 객체를 표현할 때 사용하는 기호로 맞은 것은?

<<>> 기호를 사용

 

07 구조적 다이어 그램

클객 컴배 복패

 

클래스 / 객체 / 컴포넌트 / 배치(Deployment) / 복합체 구조 (Composite Structure) / 패키지

 

08 의존관계, 일반화 관계

의존

 

일반화

 

집합

포함

실체화

 

https://velog.io/@neulring/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-UML

velog

참고했습니다.

 

09 UML에서 활용되는 다이어그램 중, 시스템의 동작을 표현하는 행위 다이어그램

유시커 상활타

유스케이스 / 시퀀스 / 커뮤니케이션 / 상태 / 활동 / 타이밍

 

10 시퀀스 다이어그램 구성요소

객체, 생명선, 실행, 메시지

메생객실

 

11 유스케이스 수행 시 특별한 조건을 만족할 때 수행하는 유스케이스는 확장관계이다.

<<include>> 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함관계

<<extend>> 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수도 있는 관계

기본 유스케이스 수행 시 특별한 조건을 만족 할 때 수행

 

12 다이어그램

활동 다이어그램 - 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현

상태 다이어그램 - 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현, 모든 가능한 상태와 전이를 표현, 진입 조건, 탈출 조건, 상태 전이 등

클래스 다이어그램 - 시스템 내 클래스의 정적 구조를 표현, 속성과 동작으로 구성, 시스템의 구조를 파악하고 구조상의 문제점 도출 가능, 클래스와 클래스, 클래스의 속성 사이의 관계를 표현

 

 

13 

유스케이스 : 시스템이 제공해야 하는 서비스, 액터가 시스템을 통해 수행하는 일련의 행위

액터 : 사용자가 시스템에 대해 수행하는 역할, 시스템과 상호작용하는 사람 또는 사물

시스템 : 전체 시스템의 영역을 표현

 

14 UML

구조적 다이어그램

클객 컴배 복패

종류                         설명

클래스 다이어그램	클래스의 속성과 클래스 사이의 관계를 표현하며, 시스템 구조 파악 및 구조상 문제점을 도출한다.
객체 다이어그램	클래스에 속한 객체(인스턴스)를 특정 시점의 객체와 객체 사이 관계로 표현
컴포넌트 다이어그램	컴포넌트 사이 관계나 인터페이스를 표현하며, 구현 단계에서 사용
배치 다이어그램	결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하며, 노드와 통신 경로를 표현한다. 구현 단계에서 사용
복합체 다이어그램	클래스나 컴포넌트가 복합구조를 가질 시 그 내부 구조를 표현
패키지 다이어그램	유즈케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

 

행위 다이어그램

유시커 상활타

종류                           설명

유스케이스 다이어그램	유저의 요구를 분석하며 기능 모델링 작업에 사용. 유저와 유스케이스로 구성되어 유스케이스 간에는 여러 형태의 관계로 이루어짐
시퀀스 다이어그램	상호작용하는 시스템이나 객체들이 주고받는 메시지 표현
커뮤니케이션 다이어그램	동작에 참여한 객체들이 주고받는 메시지와 객체 간 연관까지 표현(시퀀스의 상위호환)
상태 다이어그램	객체가 자신이 속한 클래스의 상태 변화 및 다른 객체 간 상호작용에 따라 상태 변화 표현
활동 다이어그램	시스템이 어떤 기능을 수행하는지에 따라 객체 처리 로직이나 조건에 따른 처리 흐름을 순서에 따라 표현
상호작용 다이어그램	상호작용 다이어그램 간 제어 흐름 표현
타이밍 다이어그램	객체 상태 변화와 시간 제약 명시적 표현

 

17 클래스 다이어그램 구성요소

클래스 이름

속성(Attribute)

연산(Operation)

접근 제어자(Access Modifier)

 

20 XP의 5가지 가치

용단의 피존

용기 / 단순성 / 의사소통 / 피드백 / 존중

 

22 애자일 방법론에 해당

기능 중심 개발, 스크럼, 익스트림 프로그래밍

 

23 UML기본 구성요소

사관다

사물/관계/다이어그램

 

24 자료사전에서 선택의 의미

[]

 

25 XP 12가지 기본원리

1. 계획 절차(The Planning Process)
  고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수
  있는지를 알려준다.

2. 소규모 릴리즈(Small Release)
  작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다.

3. 상징(Metaphor)
  공통적인 이름의 체계를 갖고 공통적인 시스템 서술서를 갖게 되면, 개발과 의사소통을 돕는다.

4. 단순 설계(Simple Design)
  현재의 요구사항에 들어맞는 가장 단순한 시스템을 설계한다. "미래를 위해서"라는 것은 필요 없다.
  리택토링을 통해서도 좋은 설계를 할 수 있다.

5. 테스팅(Testing)
  XP는 항상 소프트웨어의 적합성에 초점을 두고 있다. 개발자는 테스트를 먼저한 후에 소프트웨어를 작성
  한다. 그렇게 되면 이미 테스트에서 요구사항을 충족하게 된다.

6. 리팩토링(Refactrong)
  개발하는 동안 내내 시스템의 설계를 향상시킨다.

7. 짝 프로그래밍(Pair Programming)
  개발자 둘이서 짝으로 코딩한다. 짝 프로그래밍은 혼자 코딩하는 것보다 비슷하거나 혹은 더 적은 비용을
  들인다고 한다.

8. 공동 소유(Collective Ownership)
  모든 코드는 모든 개발자에게 속해있다. 이는 팀을 최상의 속도로 움직이게 하며, 변경이 필요할 때에도
  지연을 줄인다.

9. 지속적인 통합(Continous Integration)
  매일 여러 번씩 소프트웨어를 통합하고 빌드한다.

10. 주당 40시간 업무(40 hour Week)
  피곤한 개발자가 실수를 더 많이 한다.

11. 현장고객 지원(On site Customer)
  의사소통을 향상시키고 문서의 양을 줄일 수 있다.

12. 코딩 표준(Coding Standard)
  효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의한다.

출처: https://hanlab.tistory.com/2 [Hansei University HAT Lab.:티스토리]

 

xp 5가지 가치

용단의 피존

 

애자일 선언문

개변동고

개인과 상호 작용 / 변화에 대응 / 동작하는 소프트웨어 / 고객과 협력

 

30 DFD

화살표 원 사각형 직선으로 표시

33 기능적, 비기능적 요구사항

기능적 요구 : 수행될 기능과 관련되어 소프트웨어가 가져야하는 기능적 속성

비기능적 요구 : 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 요구사항은 비기능적 요구사항에 해당

 

정산하기나 모임 관리처럼 시스템이 갖고 있는 기능은 기능적 요구사항이라하고 정산하는 속도, 시스템의 메모리 사용량처럼 기능은 아니나 측정해서 제한을 두고 시스템이 만족하도록 해야 하는 것은 비기능적 요구사항이라 한다.

 

36 스크럼에서 스프린트

2~4주의 짧은 개발 기간으로 반복적 수행으로 개발 품질을 향상

 

37 유스케이스 구성요소

연관, 포함, 확장, 일반화

유연포확일

 

38 유스케이스 관련 내용이 아닌것

시스템과 상호작용하는 외부 시스템은 액터로 파악해서는 안 된다.

유스케이스 사용자 측면에서의 요구사항으로 사용자가 원하는 목표 달성하기 위해 수행할 내용을 기술한다.

시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템.

액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다.

 

41. 소프트웨어를 보다 쉽게 이해할 수 있고 적은 비용으로 수정 할 수 있도록 겉으로 보이는 동작의 변화 없이 내부구조를 변경하는 것

 

Refactoring

 

42. 익스트림 프로그래밍

-소규모 개발조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법

-익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것

-구체적인  실천 방법을 정의, 개발문서 보다는 소스코드에 중점

기존의 방법론에 비해 실용성을 강조

45. 스크림어세 해당 스프린트가 계획대로 나아가고 있는지 정해진 목표를 수행하기 위해 팀 차원의 조정이 필요한지 알 수 있게 하고, 수행할 작업의 진행 상황을 확인 할 수 있는 것

Burn Down Chart

 

46. 상태 다이어그램

상태, 객체가 존재할 수 있는 조건

시작 상태, 객체의 시작상태

종료상태, 객체의 종료상태

전이, 다른 상태로 변경되는 상태

이벤트, 상태의 변화를 주는 현상

전이 조건, 특정 조건 만족 시 전이가 발생하도록 하기 위해 사용되는 속성값의 불린 식

 

1-42

 

1. CASE

요구분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 자동화 하는 것

 

상위 CASE

계획 수립, 요구분석, 기본설계 단계를 다이어그램으로 표현

모델들 사이 모순 검사 및 오류검증, 일관성 검증

자료흐름도 프로토 타이핑 작성 지원 및 UI설계 지원

 

하위 CASE

구문 중심 편집 및 정적, 동적 테스트 지원

시스템 명세서 생성 및 소스코드 생성 지원

 

CASE가 언어번역을 지원하진 않는다.

 

그래픽, 생명주기 전 단계 연결, 다양한 소프트웨어 개발모형 지원, 표준화된 개발 환경 구축 및 문서 자동화 기능, 작업 과정 및 데이터 공유를 통해 작업자 간 커뮤니케이션 증대

 

07 CASE 원천기술

구조적기법

프로토타이핑

자동프로그래밍

정보 저장소

분산 처리 기술

 

10 요구사항 관리 도구의 필요성

비용 편익 = 요구사항 변경으로 인한 비용 편익 분석

변경 추적 = 요구사항 변경의 추적

영향 평가 = 요구사항 변경에 따른 영향 평가

 

1-54

04. 

CLI = 명령어를 텍스트로 입력하여 조작하는 사용자 인터페이스

GUI = 그래픽 환경 기반으로 마우스나 전자펜

NUI = 사용자가 가진 경험을 기반으로 키보드나 마우스 없이 신체부위를 이용하는 사용자 인터페이스

OUI = 입력장치가 곧 출력, 현실에 존재하는 모든 사물이 입출력 장치로 변화할 수 있는 사용자 인터페이스

 

 

07. UI 요소

토글 버튼 = 두 가지 상태 중에 하나로 토글되도록 만든 요소

텍스트 박스 = 텍스트입력

라디오 박스 = 여러개 중 1개 (라디오에 카세트는 하나)

체크박스 = 여러개 옵션 중 1개 이상의 옵션

 

12. UI

시스템의 상태와 사용자의 지시에 대한 효과를 보여주어 사용자가 명령에 대한 진행 상황과표시된 내용을 해석할 수 있도록 도와주는 시스템

피드백

 

모듈 : 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어

해시 : 일방향 암호 방식으로 임의 길이의 정보를 입력받아, 고정된 길이의 암호문(해시값)을 출력하는 방식

 

제스처 : 탭, 더블 탭, 프레스, 플릭, 스와이프, 팬, 드레그 ,핀치, 로테이트

 

1-60

 

01. 처리속도, 보안성 등 시스템 성능은 비기능적 요구사항이다.

 

03.

1류 접근 = 인간의 감성

2류 : 개인의 성별

3류 : 감성적 어휘 대신 공학적인 방법

 

1-77

01. HIPO

체계적인 문서 관리가 가능

기호 도표등을 사용해서 보기가 쉽고 이해가 쉬움

기능 자료의 의존관계를 동시의 표현

변경 유지보수 용이

시스템의 기능을 고유 모듈들로 분할하여 이들간의 인터페이스 계층 구조로 표현한 것을 HIPO차트라고 함

변경 유지보수가 용이

 

03. 코드 설계

연상코드 = 코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호 형태로 넣어 연상할 수 있도록 구성

블록코드 = 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 코드

순차코드 = 일정한 기준에 따라 순서대로 일련번호를 부여

표의 숫자 코드 = 대상 자료의 물리적인 수치인 길이, 넓이, 용량 등을 표시한 코드

 

04. 팬인 팬아웃

팬인 : 모듈 자신을 기준으로 모듈에 들어오면 팬인

팬아웃 : 모듈 자신을 기준으로 모듈에서 나가면 팬 아웃

 

08. 협약에 의한 설계

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

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

 

선행조건 = 컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 조건

결과조건 = 사용 후 만족하여야 할 조건

불변조건 = 오퍼레이션이 실행되는 동안 항상 만족하여야 할 조건

 

10. 파이프 필터 형태의 소프트웨어 아키텍처에 대한 설명으로 옳은것은?

소프트웨어 아키텍처 패턴 중 파이프-필터 패턴은 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브시스템어르 놈겨주는 과정을 반복

필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이하다.

 

 

11. 상위 하위 설계

상위

자료구조설계, 아키텍처설계, 인터페이스설계, 프로시저설계

 

하위ㅇ

모둘설계

 

 ▷ 상위설계(High-Level Design)

   아키텍처 설계, 하위 설계를 위한 도면, 전체적인 구조로, System 수준 단계의 소프트웨어 구성 Component 관계이다.

 

 ▷ 하위설계(Low-Level Design)

   모듈 설계, 상위 설계에 대한 내용을 보다 상세하게 도출하여 만든 설계, 동적 행위 등에 대한 결정을 말한다. System의 각 구성요소들에 대한 설계, 내부 구조 설계로, 해당 설계과정이 완료되면, 구현(개발) 작업 진행의 부분으로, 구현(개발) 과정 중 직접적인 함수 처리나, 알고리즘 등에 대한 부분은 주로 개발자의 능력이다.

 

12. 오류

Transcription Error = 한자리를 잘 못 표기한 경우

Transposition Error = 연속된 두 글자가 서로 바뀌어 표기

Omission Error = 한 글자 빼고 기술

Addition Error = 한 글자를 추가되어 기술한 경우

Double Transpostion = 전위 오류가 중복 발생한 경우

 

14. 소프트웨어 아키텍처 설계에서 시스템 품질 속성이 아닌 것

가변성 보사시

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

 

15. 파이프-필터-패턴

서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복하는 패턴

필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이

 

16. 마스터 슬레이브 아키텍처

연산, 통신, 조정을 책임지는 마스터와 제어하고 동기화되는 대상인 슬레이브로 구성되는 패턴

슬레이브 프로세스는 데이터 수집 기능을 수행할 수 있다.

 

오버헤드란 프로그램의 실행흐름에서 나타나는 현상중 하나로 예를 들어 , 프로그램의 실행흐름 도중에 동떨어진 위치의 코드를 실행시켜야 할 때 , 추가적으로 시간,메모리,자원이 사용되는 현상입니다.

한마디로 정의하자면,  오버 헤드는 특정 기능을 수행하는데 드는 간접적인 시간, 메모리 등 자원을 말한다. 

 

예를들어,  10초 걸리는 기능이 간접적인 원인으로 20초걸린다면 오버헤드는 10초가 되는것이다. 

 

모듈

모듈이란 소프트웨어 설계에서 기능단위로 분해하고 추상화 되어 재사용 및 공유 가능한 수준으로 만들어진 단위로 그 자체로서 컴파일 가능한 단위이며, 재사용 가능하고 동시에 여러 다른 모듈의 개발에 사용될 수 있습니다.

모듈화란 이러한 분해를 강조하여 유지 보수와 타 프로그램에서의 코드 재사용을 손쉽게 하는 소프트웨어 설계 기법을 말합니다.

---

이렇게 모듈화를 통해 설계하면 프로그램의 효율적인 관리 및 성능 향상, 전체적인 소프트웨어 이해 용이성 증대 및 복잡성 감소하는 장점이 있습니다.
모듈화의 목표는 모듈간 결합도 최소화, 응집도 최대화를 목표로 합니다.

 

25. 재사용의 유형

함수객체, 컴포넌트, 애플리케이션

 

29. 결합도

내>공>외>제>스>자

 

1-84

32. 결합도

데이터 결합도 - 인터페이스로 전달되는 파라미터를 통해서만 모듈간의 상호작용이 일어나는 경우

내용 결합도 - 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우, 하나의 모듈이 직접적으로 다른 모듈의 내용을 참조 할 때

공통 결합도 - 파라미터가 아닌 모듈 밖에 선언되어있는 전역변수를 참조하고 갱신하는식으로 상호작용을 하는 경우

 

결합도 낮아지는 순

내 공 외 제 스 자

 

35. 응집도의 유형

기능적 응집도 : 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

우연적 응집도 : 모듈 내부의 구성요소들이 연관이 없을 때

논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우

절차적 응집도 ; 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우

 

36. 응집도의 유형

우논시절통순기

우연전 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적

coincidental         temporal    Procedural           sequential 

 

42. 소프트웨어 아키텍처 4+1 뷰

유논프구배

유스케이스 뷰 - 논리 뷰  - 프로세스 뷰 - 구현 뷰 - 배포 뷰

 

1-96

2. 

클래스 - 객체 지향 프로그램에서 데이터를 추상화하는 단위

인스턴스 - 프로그램엣 클래스를 통해 만든 실제의 실행객체, 프로그램의 실행단계에서 나타남

객체 - 자신 고유의 데이터를 가지며 클래스에서 정의한 행위를 수행

메시지 - 객체에서 어떤 행위를 하도록 지시하기 위한 방법

메서드 - 클래스로부터 생성된 객체를 사용하는 방법

클래스 - 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현

 

객체간의 메시지를 주고받을 때 각 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고 데이터와 데이터를 처리하는 함수를 하나로 묶은것 --> 캡슐화 --> 세부내용이 외부에 은폐되어 변경으로 인한 오류의 파급효과가 적음

 

09. 정보은닉의 가장 근본적인 목적

특정 모듈의 정보를 필요로 하지 않는 모듈이 접근하지 못하도록 세부 내용을 은폐하고 설계하는 기법

다른 모듈의 접근을 막고, 세부 내용을 은폐함으로써 고려되지 않은 영향을 최소화 하게 된다.

 

10. 다형성

하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

 

필드 - 클래스에 포함된 변수

 

캡슐화 - Encapsulation

 

16. 추상화 기법

과자제

과정 추상화 / 자료 추상화 / 제어 추상화

 

21. 객체지향 방법론

Jacobson 야콥슨 = 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 사용

Rumbaugh 럼바우 = 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론

분석 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링

Booch 부치 = 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론

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

Coad와 Yourdon = E-R다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별 , 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법

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

 

22.

interface Segregation Princople

인터페이스 분리 원칙 = 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

 

Dependency Inversion Principle

의존성 역전의 원칙 = 실제 사용관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

 

Liskov Substitution Principle

리스코프 치환의 원칙 = 서브타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙

 

Single Responsibility Principle

하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙

 

단일 책임의 원칙 = 하나의 클래스는 하나의 목적을 위해서 생성되며 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중 되어 있어야 한다.

 

개방 폐쇄 원칙 = 소프트웨어 구성요소는 확장에는 열려있고 변경에는 닫혀있어야 한다는 원칙

 

인터페이스 분리의 원칙 = 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

 

29. 럼바우 

객체 모델링 = 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하는 모델링

동적 모델링 = 시간의 흐름에 따라 객체들 사이으이 제어 흐름, 동작 순서등의 동적인 행위를 표현하는 모델링

기능 모델링 = 프로세스들의 자료 흐름을 중심, DFD

 

33. 객체지향 분석 방식은 상향식

 

34. 부분 전체 또는 부분의 관계는 집단화

일반화와 달리 상위 클래스의 성질들이 하위로 상속되지 않음

 

36. 디자인 패턴 구성요소

패문솔 사결샘

패턴이름/문제/솔루션/사례/결과/샘플 코드

 

37. 

생성

생빌 프로 팩앱싱

구조

구 브데 퍼플 프록 컴 어

 

41. 목적에 따른 디자인 패턴 유형

생구행

생성 / 구조 / 행위

 

49. 오버라이딩 오버로딩

오버라이딩 = 상위클래스에서 정의한 일반 메소드의 구현을 하위클래스에서 무시하고 재정의 할 수 있다.

오버로딩 = 매개변수의 유형과 개수를 다르게 하여 같은 이름이 메서드를 여러 개 가지는 기법

 

1-144

 

1. 

동료 검토

2~3명이 진행하는 리뷰의 형태, 요구사항 명세서 작성자가 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행

 

워크 스루

오류를 조기에 검출하는 데 목적

검토자료를 회의전에 배포해서 사전검토 후 짧은시간 회의, 문서화, 비공식적

 

인스펙션

스프트웨어 요구, 설계, 원시코드등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 검토방법

계획 -> 사전 교육 - 준비 - 회의 -수정 -후속조치

 

3. 정형기술검토 FTR

논쟁이나 반박을 제한해야 한다.

 

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

도분명확

도출/분석/명세/확인

 

08. 인스펙션 절차

계획 - 교육 - 준비 - 인스펙션 - 회의 - 수정 - 후속 조치

 

1-120

01. 

시스템 인터페이스를 구성하는 시스템으로 연계할 데이터를 데이터베이스와 애플리케이션으로부터 연계 테이블 또는 파일 형태로 생성하여 송신하는 시스템

송신 시스템

 

수신 시스템

수신한 테이블을 변환하여 저장또는 제공

 

중계 서버

송신 시스템 수신시스템 사이에서 데이터를 중계

 

02. 시스템 구성요소

입력 출력 처리 제어 피드백

 

02. 시스템 아키텍처 설계원칙

대확 고운보

대규모 트랜잭션 처리 및 온라인 성능 보장

시스템 아키텍처 확장성 보장

서비스 고가용성 보장

운영관리 효율성

시스템 보안 강화

 

 

트래픽(traffic)이란 서버와 스위치 등 네트워크 장치에서 일정 시간 내에 흐르는 데이터의 양을 말한다. 웹사이트에 트래픽이 많다는 것은 사용자 접속이 많아서 전송하는 데이터의 양이 많다는 것을 뜻한다. 트래픽이 너무 많으면 서버에 과부하가 걸려서 기능에 문제가 생길 수 있다.

 

1-127

 

01 트랜잭션 처리

원격 프로시저 호출

 

객체 기반 미들웨어

 

트랜잭션 처리

 

02 미들웨어 솔루션

디원메트 레객와

DB미들웨어 / 원격 프로시저 호출 / 메시지 지향 미들웨어 / 트랜잭션 처리 모니터 / 레거시웨어 / 객체 기반 미들웨어

 

06 

DB링크 = 데이터베이스에서 제공하는 DB링크 객체를 이용하는 기술

소켓 = 서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트 통신 요청시 클라이언트와 연결하고 통신

 

메시지 지향 미들웨어

=> 다소 느리고 안정적인 응답을 필요로 할 때