[정보처리기사 필기] 1. 소프트웨어 설계

정보처리기사

수제비2024 기출문제집으로 공부하면서 틀린 부분 위주로 기록

1-2 요구사항 확인

2. 요구사항 확인

클래스 다이어그램이란?

• 클래스 다이어그램은 구조 다이어그램으로 클래스 내부 구성요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 및 전체를 구조화한다. 개발 하기 전, 클래스 다이어그램을 그리게 되면 시스템 내 클래스 간의 의존성 파악과 팀원들 간 의사소통이 편리해진다

클래스 다이어그램의 요소

구성 요소	설명
클래스 이름 (Class Name)	클래스의 이름을 명시
속성 (Attribute)	클래스의 특징에 이름을 부여
연산 (Operatoin)	- 클래스에 속하는 객체에 적용될 메서드를 정의 - 클래스의 동작을 의미하며, UML에서는 동작에 대한 인터페이스를 지칭
접근 제어자 (Access Modifier)	- 클래스에 접근할 수 있는 정도를 표현 - private, public, protected, default

 

UML(Unified Modeling Language)

• 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어
• 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 해준다

UML의 구성요소

• 사물, 관계, 다이어그램

사물 종류	설명	예
구조 사물	- UML 모델의 정적인 부분들을 정의 - 시스템의 물리적, 개념적 요소를 표현	클래스, 유스케이스, 컴포넌트, 노드 등
행동 사물	- UML 모델의 동적인 부분을 표현 - 시간과 공간에 따른 요소들의 행위를 표현	상호작용, 상태 머신 등
그룹 사물	UML 모델의 요소들을 그룹으로 묶어서 표현	패키지 등
주해 사물	- UML 모델을 설명 - 부가적인 설명이나 제약조건 등을 표현	노트 등

 

애자일 방법론

• Agile: 기민한, 민첩한 이라는 뜻으로 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더 하고 수정해나가는 탄력적인 방법론
• 프로젝트의 요구사항을 모듈 중심으로 정의하지 않고, 기능 중심으로 정의한다

애자일 개발 방법론

• 스크럼
• 익스트림 프로그래밍
• 기능 주도 개발

XP(eXtreme Programming)란?

• 대표적인 애자일 방법론
• 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법
• 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것
• 구체적인 실천 방법을 정의하고 있으며, 개발 문서 보다는 소스 코드에 중점
• 수시로 발생하는 고객의 요구 사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론으로 기존의 방법론에 비해 실용성을 강조한 방법론

XP(eXtreme Programming)의 5가지 가치

가치	설명
용기	용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링할 수 있는 용기)
단순성	필요한 것만 하고 그 이상의 것들은 하지 않음
의사소통	개발자, 관리자, 고객 간의 원활한 소통
피드백	의사소통에 대한 빠른 피드백
존중	팀원 간의 상호 존중

 

스크럼

• 스크럼 마스터는 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다
• 제품 백로그는 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함될 수 있다
• 속도는 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다
• 스프린트는 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발 품질을 향상한다

DFD(Data Flow Diagram)

• 구조적 방법론을 대표하는 다이아그램
• 데이터가 소프트웨어 내의 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림
• 소프트웨어 및 정보시스템의 분석과 설계에서 매우 유용하게 사용되는 다이아그램
• 데이터 흐름도 또는 자료 흐름도라고도 칭한다
• 시스템의 모형화 도구로서 가장 보편적으로 사용되는 것 중의 하나
• 데이터에 비해 기능이 매우 복잡하고 중요할 경우에 매우 유용하게 사용

유스케이스 다이어그램(Usecase Diagram)

• 사용자 관점에서 시스템의 활동을 표현
• 유스케이스는 시스템의 기능적 요구 정의에 활용

유스케이스 다이어그램의 구성요소

• 시스템
  • 만들고자 하는 프로그램
• 액터
  • 시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람)
  • 시스템(시스템에 정보를 제공하는 또 다른 시스템)
• 유스케이스
  • 사용자 입장에서 바라본 시스템의 기능
  • 사용자 측면에서의 요구사항
  • 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술
• 관계
  • 액터와 유스케이스 사이의 의미있는 관계
  • 연관, 의존(포함, 확장), 일반화
    • 연관 관계: 유스케이스와 액터간의 상호작용이 있음을 표현
      • 사용자(액터)가 글을 등록한다(유스케이스)
    • 포함 관계: 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계. 포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용
      • '글을 등록한다' 기능을 동작하기 위해서는 '로그인 한다'는 기능이 반드시 동작
    • 확장 관계: 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계
      • '글을 등록한다' 기능을 수행할 때 '파일을 첨부한다' 기능을 선택적으로 수행
    • 일반화 관계: 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계
      • '글을 검색한다'를 '글쓴이로 검색한다'와 '날짜로 검색한다'로 좀 더 구체화

번 다운 차트(Burn Down Chart)

• 잔여 작업량과 잔여 시간을 세부적으로 비교해 팀이 기한까지 어떻게 작업하고 있는지를 시각적으로 나타낸다
• 스크럼에서 해당 스프린트가 계획된 대로 나아가고 있는지, 정해진 목표를 달성하기 위해 팀 차원의 조정이 필요한지 알 수 있게 하고, 수행할 작업의 진행 상황을 확인할 수 있는 차트

칸반 보드(Kanban Board)

• 전체 워크플로우를 카드 형태로 나타내고 수행된 활동, 진행중인 작업 및 보류 중인 활동을 구별할 수 있는 도구

1-3 애플리케이션 설계

1. 공통 모듈 설계

소프트웨어 설계 시 고려사항

• 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하고 구체화시켜 나간다
• 요구사항을 모두 구현해야 하고 유지 보수가 용이해야 한다
• 모듈은 독립적인 기능을 갖도록 설계해야 한다
• 모듈 간의 상관성은 낮추고 변경이 쉬워야 한다
• 효과적인 모듈 설계를 위해서는 결합도를 약하게 해야 모듈 간의 독립성을 확보한다. 또한 모듈 간의 상관성을 낮춰야 한다

모듈이란?

• 프로그램을 구성하는 구성 요소로, 관련된 데이터와 함수를 하나로 묶은 단위를 의미한다. 보통 하나의 소스 파일에 모든 함수를 작성하지 않고, 함수의 기능별로 따로 모듈을 구성한다. 이러한 모듈을 합쳐 하나의 파일로 작성하는 방식으로 프로그램을 만들게 된다. 프로그램 코드를 기능별로 나눠서 독립된 파일에 저장하여 관리하는 방식을 모듈화 프로그래밍이라고 한다

협약에 의한 설계

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

조건	설명
선행조건	컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 조건
결과 조건	사용 후 만족하여야 할 조건
불변조건	오퍼레이션이 실행되는 동안 항상 만족하여야 할 조건

 

표의 숫자 코드

• 표를 이용하여 데이터를 변환하는 방법
• 예를 들어 ASCII(아스키 코드), EBCDIC(에비시딕) 코드 등이 있다
• 표준화되어 있고 호환성이 좋다는 장점이 있지만, 표를 참조해야 하고 확장성이 낮다는 단점이 있다
• 코드화 대상 항목의 중량, 면적, 용량 등의 물리적 수치를 이용하여 만든 코드

순차 코드

• 코드 설계에서 일정한 일련번호를 부여하는 방식

블록 코드

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

10진 코드

• 10진수 형태로 표현한 코드

Transcription Error(사본 오류)

• 한 자리를 잘못 표기한 경우
• 필사 오류, 오자 오류라고도 불린다

Omission Error(생략 오류)

• 한 글자를 빼먹고 기술한 경우

Addition Error(첨가 오류)

• 한 글자를 추가되어 기술한 경우

소프트웨어 아키텍처 품질 속성 중 시스템 품질 속성의 정의 [가변성보사시]

• 시스템이 이해당사자의 요구를 얼마나 잘 만족시키는지를 나타내는 측정 가능하고 테스트가 가능한 특성
• 시스템 측면: 가용성, 변경용이성, 성능, 보안, 사용성, 시험 용이성,  확장성
• 비즈니스 측면: 시장적시정, 비용/혜택, 예상 시스템 수명, 목표시장, 공개일정
• 아키텍처 측면: 개념적 무결성, 정확성, 완결성, 구축가능성, 변경성, 시험성

모듈의 독립성을 높이기 위한 결합도

• 오류가 발생했을 때 전파되어 다른 오류의 원인이 되는 파문 효과를 최소화해야 한다
• 인터페이스가 정확히 설정되어 있지 않을 경우 불필요한 인터페이스가 나타나 모듈 사이의 의존도는 높아지고 결합도가 증가한다
• 다른 모듈과 데이터 교류가 필요한 경우 전역변수 보다는 매개변수를 사용하는 것이 결합도를 낮추는 데 도움이 된다

결합도의 유형 [내공외제스자]

내용 결합도 < 공통 결합도 < 외부 결합도 < 제어 결합도 < 스탬프 결합도 < 자료 결합도

순으로 결합도가 낮아진다

응집도의 유형 [우논시절통순기]

우연적 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적 응집도

순서로 응집도가 높아진다

 

소프트웨어 아키텍처 4+1뷰 [유논프구배]

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

 

소프트웨어 설계 시 고려사항

• 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하고 구체화시켜 나간다
• 요구사항을 모두 구현해야 하고 유지 보수가 용이해야 한다
• 모듈은 독립적인 기능을 갖도록 설계해야 한다
• 모듈 간의 상관성은 낮추고 변경이 쉬워야 한다
• 효과적인 모듈 설계를 위해서는 결합도를 약하게 해야 모듈 간의 독립성을 확보한다. 또한 모듈 간의 상관성을 낮춰야 한다

모듈이란?

• 프로그램을 구성하는 구성 요소로, 관련된 데이터와 함수를 하나로 묶은 단위를 의미한다. 보통 하나의 소스 파일에 모든 함수를 작성하지 않고, 함수의 기능별로 따로 모듈을 구성한다. 이러한 모듈을 합쳐 하나의 파일로 작성하는 방식으로 프로그램을 만들게 된다. 프로그램 코드를 기능별로 나눠서 독립된 파일에 저장하여 관리하는 방식을 모듈화 프로그래밍이라고 한다

협약에 의한 설계

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

조건	설명
선행조건	컴포넌트의 오퍼레이션 사용 전에 참이 되어야 할 조건
결과 조건	사용 후 만족하여야 할 조건
불변조건	오퍼레이션이 실행되는 동안 항상 만족하여야 할 조건

 

표의 숫자 코드

• 표를 이용하여 데이터를 변환하는 방법
• 예를 들어 ASCII(아스키 코드), EBCDIC(에비시딕) 코드 등이 있다
• 표준화되어 있고 호환성이 좋다는 장점이 있지만, 표를 참조해야 하고 확장성이 낮다는 단점이 있다
• 코드화 대상 항목의 중량, 면적, 용량 등의 물리적 수치를 이용하여 만든 코드

순차 코드

• 코드 설계에서 일정한 일련번호를 부여하는 방식

블록 코드

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

10진 코드

• 10진수 형태로 표현한 코드

Transcription Error(사본 오류)

• 한 자리를 잘못 표기한 경우
• 필사 오류, 오자 오류라고도 불린다

Omission Error(생략 오류)

• 한 글자를 빼먹고 기술한 경우

Addition Error(첨가 오류)

• 한 글자를 추가되어 기술한 경우

소프트웨어 아키텍처 품질 속성 중 시스템 품질 속성의 정의 [가변성보사시]

• 시스템이 이해당사자의 요구를 얼마나 잘 만족시키는지를 나타내는 측정 가능하고 테스트가 가능한 특성
• 시스템 측면: 가용성, 변경용이성, 성능, 보안, 사용성, 시험 용이성,  확장성
• 비즈니스 측면: 시장적시정, 비용/혜택, 예상 시스템 수명, 목표시장, 공개일정
• 아키텍처 측면: 개념적 무결성, 정확성, 완결성, 구축가능성, 변경성, 시험성

모듈의 독립성을 높이기 위한 결합도

• 오류가 발생했을 때 전파되어 다른 오류의 원인이 되는 파문 효과를 최소화해야 한다
• 인터페이스가 정확히 설정되어 있지 않을 경우 불필요한 인터페이스가 나타나 모듈 사이의 의존도는 높아지고 결합도가 증가한다
• 다른 모듈과 데이터 교류가 필요한 경우 전역변수 보다는 매개변수를 사용하는 것이 결합도를 낮추는 데 도움이 된다

결합도의 유형 [내공외제스자]

내용 결합도 < 공통 결합도 < 외부 결합도 < 제어 결합도 < 스탬프 결합도 < 자료 결합도

순으로 결합도가 낮아진다

응집도의 유형 [우논시절통순기]

우연적 < 논리적 < 시간적 < 절차적 < 통신적 < 순차적 < 기능적 응집도

순서로 응집도가 높아진다

 

소프트웨어 아키텍처 4+1뷰 [유논프구배]

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

2. 객체 지향 설계

객체 지향 기법

• 캡슐화
  • 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법
  • 객체 간에 메시지를 주고받을 때 각 객체의 세부내용은 알 필요가 없으므로 인터페이스가 단순해지고 객체 간의 결합도가 낮아진다
  • 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
  • 캡슐화된 객체의 세부 내용이 외부에 은폐되어 변경으로 인한 오류의 파급 효과가 적다
• 정보은닉
  • 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술
  • 다른 모듈의 접근을 막고, 세부 내용을 은폐함으로써 고려되지 않은 영향을 최소화하게 된다
  • 모듈들 사이의 독립성을 유지시키는 데 도움이 된다
  • 설계에서 은닉되어야 할 기본 정보로는 IP 주소와 같은 물리적 코드, 상세 데이터 구조 등이 있다

객체 지향 방법론

• Coad와 Yourdon
  • E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법
• 럼바우 [객동기]
  • 가장 일반적으로 사용되는 방법
  • 그래픽 표기법을 이용하여 소프트웨어 구성 요소를 모델링하는 방법론
  • 분석 절차는 객체 모델링(객체 다이어그램) -> 동적 모델링(상태 다이어그램) -> 기능 모델링(자료 흐름도 DFD) 순서로 진행

객체 지향 설계 원칙(SOLID)

• Single Responsibility Principle (단일 책임의 원칙)
  • 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙
• Open Close Principle(개방 폐쇄 원칙)
  • 소프트웨어의 구성 요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙
• Liskov Substitution Principle(리스코프 치환의 원칙)
  • 서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙
• Interface Segregation Principle(인터페이스 분리의 원칙)
  • 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
• Dependency Inversion Principle(의존성 역전의 원칙)
  • 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

디자인 패턴 구성 요소 [패문솔사결샘]

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

GOF(Gang of four)의 디자인 패턴의 유형

• 생성 패턴 [생 빌 프로 팩앱싱]
  • 생성 (빌더 / 프로토타입 / 팩토리 메서드 / 앱스트랙 팩토리 / 싱글톤)
• 구조 패턴 [구 브데 퍼플 프록 컴 어]
  • 구조 (브릿지 / 데코레이터 / 퍼사이드 / 플라이 웨이트 / 프록시 / 컴포지트 / 어댑터)
• 행위 패턴 [행 미인이 템옵 스테 비커스트 메체]
  • 행위 (미디에이터 / 인터프리터 / 이터레이터 / 템플릿 메서드 / 옵저버 / 스테이트 / 비지터 / 커맨드 / 스트레티지 / 메멘토 / 체인 오브리스판서빌리티

디자인 패턴 유형은 3가지인데 왜 four일까 검색했더니, <디자인 패턴>은 소프트웨어 설계에 있어 공통된 문제들에 대한 표준적인 해법과 작명법을 제안한 책이다. 이 분야의 4인방(Gang of Four, 줄여 GoF)들이 작성했다

1-4 인터페이스 설계

2. 인터페이스 대상 식별

시스템의 구성 요소 [입출처제피]

• 입력(Input)
• 출력(Output)
• 처리(Process)
• 제어(Control)
• 피드백(Feedback)

3. 인터페이스 상세 설계

메시지 지향 미들웨어(MOM; Message-Oriented Middleware)

• 독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할을 한다
• 송신 측과 수신 측의 연결 시 메시지 큐를 활용하는 방법이 있다
• 상이한 애플리케이션 간 통신을 비동기 방식으로 지원한다

1-5 기타

1. 기타

FEP(Front-End Processor)

• 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어

소프트웨어 개발 영역을 결정하는 요소

• 기능, 성능, 신뢰도, 인터페이스, 제약 조건
• 인터페이스
  • 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어
  • 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어
  • 순서적 연산에 의해 소프트웨어를 실행하는 절차

기능 모델링 순서

• 입출력 자료 정의 -> 자료 흐름도 작성 -> 기능 명세서 작성 -> 제약 조건 파악