[정보처리기사] 1과목 소프트웨어설계 헷갈리는 부분 정리

* 애자일 모형 (Agile Model)

- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행함

- 좋은 것을 빠르고 낭비없게 만들기 위해 고객과의 소통에 초점을 맞춤

- 기업 활동 전반에 걸쳐 사용

- 스프린트(Sprint) 또는 이터레이션(iteration)이라고 불리는 짧은 개발 주기를 반복하며 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용함

- 각 개발주기에서는 고객의 요구사항에 우선순위를 부여해서 개발 작업을 진행함

- 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합함

 

- 애자일 모형을 기본으로 하는 소프트웨어 개발 모형

 : 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery)

 

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

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

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

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

 4) 계획을 따르기보다는 변화에 대응하는 것에 더 가치를 둔다.

 

* 자료흐름도 (Data Flow Diagram)

- 프로세스(Process), 자료 흐름(Data Flow), 자료 저장소(Data Store), 단말(Terminator)

 

- 프로세스(Process) 

 . 자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며 처리, 기능, 변환, 버블이라고도 함

 . 원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입함

- 자료 흐름(Data Flow)

 . 자료의 이동(흐름)이나 연관관계를 나타냄

 . 화살표 위에 자료의 이름을 기입함

- 자료 저장소(Data Store)

 . 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄

 . 도형(평행선) 안에 자료 저장소 이름을 기입함

- 단말(Terminator)

 . 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음(정보의 생산자와 소비자)

 . 도형(사각형) 안에 이름을 기입함 

* UML (Unified Modeling Language)

- 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델

- Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였으며, 객체 기술에 관한 국제표준화기구인 OMG(Object Management Group)에서 표준으로 지정함

- UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있음

- 각각의 다이어그램은 사물과 사물간의 관계를 용도에 맞게 표현

- UML 구성 요소에는 사물, 관계, 다이어그램이 있음

 

- UML의 관계(Relationships)

 . 연관(Association) 관계 : 2개 이상의 사물이 서로 관련되어 있음

 . 집합(Aggregation) 관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계

 . 포함(Composition) 관계 : 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

 . 일반화(Generalization) 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현하는 관계

 . 의존(Dependency) 관계 : 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

 . 실체화(Realization) 관계 : 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계

 

- UML 다이어그램의 종류

 . 구조적(Structural) 다이어그램 = 정적 다이어그램

 .. 클래스 다이어그램(Class Diagram) : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현

 .. 객체 다이어그램(Object Diagram) : 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현

 .. 컴포넌트 다이어그램(Component Diagram) : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현

 .. 배치 다이어그램(Deployment Diagram) : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현

 .. 복합체 구조 다이어그램(Composite Structure Diagram) : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

 .. 패키지 다이어그램(Package Diagram) : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

 

 . 행위(Behavioral) 다이어그램 = 동적 다이어그램 

 .. 유스케이스 다이어그램(Use Case Diagram) : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용함

 .. 순차 다이어그램(Sequence Diagram) : 상호 작용하는 시스템이나 객체들이 주고 받는 메세지를 표현(액터, 객체, 라이프라인, 활성(실행) 상자, 메시지)

 .. 커뮤니케이션 다이어그램(Communication Diagram) : 순차 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지를 표현하는데, 메시지뿐만 아니라 객체들 간의 연관까지 표현

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

 .. 활동 다이어그램(Activity Diagram) : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

 

* 객체지향

- 객체지향 프로그래밍 언어의 구성 요소

 . 객체(Object)

 .. 데이터(속성)와 이를 처리하기 위한 연산(메서드)을 결합시킨 실체

 .. 데이터 구조와 그 위에서 수행되는 연산들을 가지고 있는 소프트웨어 모듈

 .. 속성(Attribute) : 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들의 단위별로 정의하는 것으로서 성질, 분류, 식별, 수량 또는 현재 상태 등을 표현함

 .. 메서드(Method) : 객체가 메세지를 받아 실행해야 할 때 구체적인 연산을 정의하는 것으로, 객체의 상태를 참조하거나 변경하는 수단이 됨

 . 클래스(Class)

 .. 두 개 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현하는 요소 (공통된 특성과 행위를 갖는 객체의 집합)

 .. 객체의 유형 또는 타입(Object Type)을 의미함

 . 메시지(Message)

 .. 객체들 간에 상호작용을 하는데 사용되는 수단으로 객체의 메서드(동작, 연산)를 일으키는 외부의 요구사항

 .. 메시지를 받은 객체는 대응하는 연산을 수행하여 예상된 결과를 반환하게 됨

 

- 객체지향 설계 원칙(SOLID 원칙)

 . 단일 책임 원칙(SRP; Single Responsibility Principle)

 .. 객체는 단 하나의 책임만 가져야 한다는 원칙

 .. 응집도는 높고, 결합도는 낮게 설계하는 것을 의미

 . 개방-폐쇄 원칙(OCP; Open-Closed Principle)

 .. 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙

 .. 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화하는 방법이 대표적

 . 리스코프 치환 원칙(LSP; Liskov Substitution Principle)

 .. 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙

 .. 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야함

 . 인터페이스 분리 원칙(ISP; Interface Segregation Principle)

 .. 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙

 .. 단일 책임 원칙이 객체가 갖는 하나의 책임이라면, 인터페이스 분리 원칙은 인터페이스가 갖는 하나의 책임

 . 의존 역전 원칙(DIP; Dependency Inversion Principle)

 .. 각 객체들 간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙

 .. 일반적으로 인터페이스를 활용하면 이 원칙은 준수됨 

 

* 나선형모델 (Spiral Model, 점진적 모형)

- 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

- 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 함 

- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함

- 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음

- 수행 과정(반복) : 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가