정보처리기사 1강(소프트웨어 설계) 핵심 요약

1. 소프트웨어 공학의 기본원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
• 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야한다.
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

 

2. 폭포수 모형

• 이전 단계로 돌아갈 수 없다는 전재하에 각 단계를 확실히 매듭짓고 다음 단계를 진행하는 개발 방법론이다.
• 보햄이 제시한 고전적 생명 주기 모형이다.
• 요구사항을 반영하기 어렵다.

 

3. 나선형 모형

• 나선을 따라 돌듯이 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 과정이 반복적으로 수행된다.

 

4. 애자일 모형의 주요 방법론

• 스크럼(Scrum)
• XP(eXtreme Programming)
• 기능 중심 개발(FDD : Freature Driven Development)
• 칸반(Kanban)
• Lean

 

4-1 애자일 개발 4가지 핵심

• 프로세스와 도구보다 개인과 상호작용에 더 가치를 둔다.
• 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
• 계약 협상보다는 고객과 협업에 더 가치를 둔다.
• 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

4-2 XP의 핵심 가치

• 의사소통(Communication)
• 단순성(Simplicity)
• 용기(Courage)
• 존중(Respect)
• 피드백(Feedback)

 

5. 주요 비기능 요구사항

• 성능 요구사항
• 보안 요구사항
• 품질 요구사항
• 제약사항
• 인터페이스 요구사항

 

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

 

 

7. 요구사항 분석

• 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미.
• 소프트웨어 개발의 실제적인 첫 단계
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정
• 사용자 요구를 정확하게 추출하여 목표를 정하고, 해결 방식을 결정

 

8. 자료 흐름도의 구성 요소

 

9. HIPO

• 하향식 소프트웨어 개발을 위한 문서화 도구이다.
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다

 

10. UML

• 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체 지향 모델링 언어이다.
• 구성 요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

 

10-1 UML의 주요 관계

• 일반화(Generalization) 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
• 의존 관계(Dependency) 관계 : 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
• 실체화(Realization) 관계 : 사물이 할 수 있거나, 해야 하는 기능으로 서로 그룹화 할 수 있는 관계를 표현

 

11. 구조적(정적) 다이어그램의 종류

• 클래스 다이어그램(Class Diagram)
• 객체 다이어그램(Object Diagram)
• 컴포넌트 다이어그램(Component Diagram)
• 배치 다이어그램(Deployment Diagram)
• 복합체 구조 다이어그램(Composite Structure Diagram)
• 패키지 다이어그램(Package Diagram)

 

12. 행위(동적) 다이어그램 종류

• 유스케이스 다이어그램(Use Case Diagram)
• 순차 다이어그램(Sequence Diagram)
• 커뮤니케이션 다이어그램(Communication Diagram)
• 상태 다이어그램(State Diagram)
• 활동 다이어그램(Activity Diagram)
• 상호작용 개요 다이어그램(Interaction Overview Diagram)
• 타이밍 다이어그램(Timing Diagram)

 

12-1 유스케이스 다이어그램 - 액터(Actor)

• 시스템과 상호작용을 하는 모든 외부 요소로 사람이나 외부 시스템을 의미한다.
• 주액터 : 시스템을 사용함으로써 이득을 얻는 대상, 주로 사람이 해당
• 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템, 조직이나 기관 등이 될 수 있다.

 

12-2 순차 다이어그램의 구성 요소

• 액터(Actor)
• 객체(Object)
• 생명선(Lifeline)
• 실행 상자(Active Box)
• 메세지(Messege)

순차 다이어그램 구성요소 예제

 

13. 사용자 인터페이스(UI)

• 사용자의 편의성과 가독성을 높여준다.
• 작업 시간을 단축시켜준다.
• 업무에 대한 이해도를 높혀준다.
• 사용자 중심으로 설계되어있다.

 

13-1. 사용자 인터페이스의 구분

• CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
• GUI(Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
• NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

 

13-2. 사용자 인터페이스의 기본 원칙

• 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.
• 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 한다.
• 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.

 

14. 목업(Mock up)

• 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형
• 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지는 않는다.

 

15. ISO/IEC 9126의 품질 특성

소프트웨어 품질특성과 척도에 관한 표준 지침

• 기능성(Functionality) : 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타냄
• 신뢰성(Reliability) : 요구된 기능을 오류 없이 수행할 수 있는 정도를 나타냄
• 사용성(Usability) : 사용자가 쉽게 배우고 사용할 수 있는 정도를 나타냄
• 이식성(Portability) : 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄

 

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

설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브 시스템 구체화 -> 검토

 

17. 모듈화

• 기능의 분리가 가능하여 인터페이스가 단순해진다.
• 프로그램의 효울적인 관리가 가능하다.
• 오류의 파급 효과를 최소화할 수 있다
• 모듈의 크기를 너무 작게 나누면 갯수가 많아져 모듈간의 통합 비용이 많이 들고, 너무 크게 나누면 갯수가 적어 통합 비용은 적게 들지만, 모듈 하나의 개발 비용이 많이 든다.

 

18. 추상화의 유형

• 과정 추상화
• 데이터(자료) 추상화
• 제어 추상화

 

19. 정보 은닉

• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법이다.
• 모듈을 독립적으로 수행할 수 있다.
• 수정, 시험, 유지보수가 용이하다.

 

20. 파이프-필터 패턴

• 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴
• 데이터 변환으로 인한 오버헤드가 발생한다.

 

21. MVC(Model-View-Controller) 패턴

• 모델(Model) : 서브시스템의 핵심 기능과 데이터를 보관함
• 뷰(View) : 사용자에게 정보를 표시함
• 컨트롤러(Controller) : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄

 

22. 메세지(Messege)

• 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항이다.
• 객체들 간에 상호 작용을하는데 사용되는 수단

 

23. 클래스(Class)

• 공통된 속성과 연산(행위)를 갖는 객체의 집합이다.
• 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 한다.
• 객체 지향 프로그램에서 데이터를 추상화하는 단위이다.

 

24. 캡슐화(Encapsulation)

• 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
• 외부 모듈의 변경으로 인한 파급 효과가 적다.
• 인터페이스가 단순화된다.
• 재사용이 용이하다

 

25. 상속(Inheritance)

• 상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것

 

26. 다형성(Polymorphism)

• 오버로딩(Overloading) : 메소드의 이름은 같지만 인수를 받는 자료형과 개수를 달리하여 여러 기능을 정의할 수 있음.
• 오버라이딩(Overriding) : 메소드의 이름은 같지만 메소드 안의 실행 코드를 달리하여 자식 클래스에서 재정의해서 사용할 수 있음.

 

27. 객체 지향 분석 방법론

27-1 Coad와 Yourdon 방법

• ER다이어그램을 사용해 객체의 행위를 모델링한다.
• 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메세지 연결 정의 등의 과정으로 구성하는 기법이다.

 

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

• 객체(Object) 모델링 : 정보 모델링이라고도 하며, 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것
• 동적(Dynamic) 모델링 : 상태 다이어그램을 이용하여 객체들 간의 동적인 행위를 표현하는 모델링
• 기능(Functional) 모델링 : 자료 흐름도를 이용하여 자료의 흐름을 표현한 모델링 

 

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

• 단일 책임 원칙(SRP : Single Responsibility Principle) : 객체는 단 하나의 책임만 가져야 한다는 원칙
• 개방-폐쇠 원칙(OCP : Open-Closed Principle) : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
• 리스코프 치환 원칙(LSP : Liskov Substitution Principle) : 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙
• 인터페이스 분리 원칙(ISP : Interface Segregation Principle) : 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
• 의존 역전 원칙(DIP : Dependency Inversion Principle) : 각 객체들 간의 의존관계가 성립될 때 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙

 

29. 모듈(Module)

• 모듈화를 통해 분리된 시스템의 각 기능들이다.
• 단독으로 컴파일이 가능하다.
• 재사용 할 수 있다.
• 다른 모듈에서의 접근이 가능하다.

 

30. 결합도

자료 -> 스탬프 -> 제어 -> 외부 -> 공통 -> 내용

(약함)                                                               (강함)

• 자료(Data) 결합도 : 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
• 스탬프(Stamp) 결합도 : 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
• 제어(Control) 결합도 : 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도
• 외부(Extermal) 결합도 : 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
• 공통(Common) 결합도 : 공유되는 공통 데이터 영역을 여러 모듈의 사용할 때의 결합도
• 내용(Content) 결합도 : 다른 모듈의 내부 자료를 직접 참조하거나 수정할 때의 결합도 

 

31. 응집도

우연적 -> 논리적 -> 시간적 -> 절차적 -> 교환적 -> 순차적 -> 기능적

(약함)                                                                                                    (강함)

31-1. 주요 응집도

• 절차적(Procedural) 응집도 : 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
• 시간적(Temporal) 응집도 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
• 우연적(Coincidental) 응집도 :  각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

 

32. 효과적은 모듈 설계 방안

• 결합도는 줄이고, 응집도는 높인다.
• 복잡도와 중복성을 줄인다.
• 일관성을 유지시킨다.
• 모듈의 기능은 지나치게 제한적이어서는 안 된다.
• 유지보수가 용이해야한다.

 

33. 팬인(Fan-In) / 팬아웃(Fan-Out)

• 팬인 : 어떤 모듈을 제어(호출)하는 모듈의 수
• 팬아웃 : 어떤 모듈에 의해 제어(호출)되는 모듈의 수

예시

A의 경우 Fan-In은 0(), Fan-Out은 3(B, C, D)

C의 경우 Fan-In은 1(A), Fan-Out은 1(F)

F의 경우 Fan-In은 2(C, D), Fan-Out은 1(I)

 

34. 디자인 패턴(Disign Pattern)

• 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미한다.
• 생성 패턴, 구조 패턴, 행위 패턴

34-1. 생성 패턴(Creational Pattern)

• 추상 팩토리(Abstract Factory) : 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
• 빌더(Builder) : 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
• 팩토리 메소드(Factory Method) : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화 한 패턴, 가상 생성자 패턴(Virtual Constructor)이라고도 함
• 프로토타입(Prototype) : 원본 객체를 복제하는 방법으로 객체를 생성함
• 싱글톤(Singleton) : 생성된 객체를 여러 프로세스가 동시에 참조할 수 없음.

34-2 구조 패턴(Structural Pattern)

• 어댑터(Adapter) : 인터페이스를 다른 클래스가 재사용할 수 있도록 변환
• 브리지(Bridge) : 서로가 독립적으로 확장할 수 있도록 구성
• 컴포지트(Composite) : 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용함
• 데코레이터(Decorator) : 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현함
• 퍼싸드(Fecade) : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성
• 플라이웨이트(Flyweight) : 가능한 한 인스턴스를 공유해서 사용함으로써 메모리를 절약하는 패턴
• 프록시(Proxy) : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

34-3 행위 패턴(Behavioral Pattern)

• 책임 연쇄(Chain of Responsibility) : 요청을 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태
• 커맨드(Command) : 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장함
• 인터프리터(Interpreter) : 언어에 문법 표현을 정의함
• 반복자(Iterator) : 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함 
• 중재자(Mediator) : 복잡한 상호 작용을 캡슐화하여 객체로 정의함
• 메멘토(Memento) : 객체를 해당 시점의 상태로 되돌릴 수 있는 기능을 제공, ctrl + z 와 같은 기능을 개발할 때 주로 이용
• 옵저버(Observer) : 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달
• 상태(State) : 객체에 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용함
• 전략(Strategy) : 동일한 계열의 알고리즘들을 상호 교환할 수 있게 정의함
• 템플릿 메소드(Template Method) : 하위 클래스에서 세부 처리를 구체화함
• 방문자(Visitor) : 처리 기능을 분리하여 별도의 클래스로 구성

 

35. 요구사항 검증 방법

• 동료 검토(Peer Review) : 작성자가 명세서 내용을 직접 설명하면서 결함을 발견
• 워크 쓰루(Walk Through) : 미리 배포한 명세서를 사전 검토한 후 결함을 발견
• 인스펙션(Inspection) : 작성자를 제외한 다른 검토 전문가들이 결함을 발견
• 동료 검토와 워크 쓰루는 비공식 검토 방법, 인스펙션은 공식적인 검토 방법

 

36. 미들 웨어(Middleware)

• 분산 컴퓨팅 환경에서 서로 다른 기종 간을 연결한다.
• 운영체제와 응용 프로그램 사이에서 다양한 서비스를 제공
• 위치 투명성을 제공
• 사용자가 미들웨어의 내부 동작을 확인하려면 별도의 응용 소프트웨어를 사용해야한다.

36-1. 미들웨어의 종류

미들웨어의 종류