한이아지와 함께하는 정보처리기사 1과목 3번째) 애플리케이션 설계

이번에는 1과목 3번째 부분은

애플리케이션 설계에 대해서 정리해보겠습니다!

(☆ 중요도 0.5 / ★ 중요도 1)

---

PART1. 소프트웨어 설계

• Chap01) 요구사항 설계
  • 현행 시스템 분석
  • 요구사항 확인 
  • 분석 모델 확인
• Chap02) 화면설계 
  • UI 요구사항 확인
  • UI 설계
• Chap03) 애플리케이션 설계
  • 공통 모듈 설계
  • 객체지향 설계
• Chap04) 인터페이스 설계
  • 인터페이스 요구사항 확인
  • 인터페이스 대상 식별
  • 인터페이스 상세 설계

---

Chap03) 애플리케이션 설계

---

1. 공통 모듈 설계

1.1. 공통 모듈 (★★★)

[1] 모듈 이란?

독립된 하나의 소프트웨어 or 하드웨어

 

[2] 공통 모듈이란?

전체 프로그램 중 특정 기능을 처리할 수 있는 실행 코드 (공통적으로 사용하는 모듈) → 자체적으로 컴파일 가능

 

공통 모듈 원칙 : 정명완일추

정확성, 명확성, 완전성, 일관성, 추적성

 

[3] 모듈화란?

프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화하여 제품의 성능을 향상시키고 유지보수를 쉽게 하는 기법

 

모듈화 기법

 - 루틴 : 소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임

    ▸ 메인 루틴 : 프로그램의 주요한 부분, 전체의 개략적인 동작 절차를 표시하는 루틴

    ▸ 서브 루틴 : 메인 루틴에 의해 필요할 때 마다 호출되는 루틴

 

모듈 설계 방안

모듈의 독립성과 재사용성을 높이기 위해 결합도는 낮추고 응집도는 높임

모듈의 복잡도와 중복성을 줄이고 일관성을 유지

모듈의 기능은 예측 가능해야 하며 지나치게 제한적이어서는 안됨

 

[4] 결합도 : 모듈간의 상호의존하는 정도

결합도가 약할수록 품질이 높음! (WHY? 결합도가 강하면 구현 및 유지보수가 어려움)

 

출처 : https://shlee1990.tistory.com/822

 

[5] 응집도 : 정보은닉 개념을 확장, 내부요소들의 관련되어 있는 정도

출처 : https://m.blog.naver.com/kji9653/222025565533

 

[6] Fan-In / Fan-Out : 시스템 복잡도를 최소화 하기 위해서 Fan-In은 높게 Fan-Out는 낮게 설정

구분	팬인 Fan-In	팬아웃 Fan-Out
개념	어떤 모듈을 제어하는 모듈의 수	어떤 모듈에 의해 제어되는 모듈의 수
모듈 숫자 계산	모듈 자신을 기준으로 모듈에 들어오면 팬인	모듈 자신을 기준으로 모듈에서 나가면 팬아웃
고려 사항	팬인이 높으면 설계가 잘 됬지만 장애점 발생 팬인이 높으면 관리 비용 및 테스트 비용 증가	팬아웃이 높으면 불필요한 모듈 호출 여보 검토 필요 팬아웃이 높으면 단순화 여보 검토 필요

팬인 / 팬아웃 계산

출처 : https://post.naver.com/viewer/postView.nhn?volumeNo=27424202&memberNo=26040503

 

1.2. 설계 모델링 (★★★)

[1] 설계 모델링이란?

요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 기법

 

설계 모델링 유형

✔ 구조 모델링 : 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스 등 상호 연결 구조를 모델링

                         구조 모델링 구성요소 - 프로시저, 데이터 구조, 모듈, 파일 구조

✔ 행위 모델링 : 소프트웨어의 구성요소들의 기능들이 언제, 어디서 어떻게 수행되고 상호 작용하는 지를 모델링

                    행위 모델링 구성요소 - 입력 데이터 출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등

 

[2] 소프트웨어 설계 유형

 - 자료 구조 설계 : 요구 분석 단계에서 생성된 정보를 바탕으로 SW를 구현하는데 필요한 자료 구조로 변환하는 과정

 - 아키텍처 설계 : 예비 설계 또는 상위 수준 설계, SW 전체 구조를 기술, SW를 구성하는 컴포넌트 간의 관계 정의

 - 인터페이스 설계 :  SW와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는 지 기술

 - 프로시저 설계 : 프로그램 아키텍처의 컴포넌트를 SW 컴포넌트의 프로시저 서술로 변환하는 과정

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

 

[3] 코드 설계란?

데이터의 분류나 조합을 쉽게 하기 위하여 사물을 표현하는 코드를 설계하는 기법

 

코드 기능 : 표분식배간연암오

표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출

 

코드 설계 종류

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

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

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

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

 - 십진 코드 : 10진수 형태로 표현한 코드

 - 그룹 분류식 코드 : 대상을 기준에 따라 구분하여 번호를 부여한 코드

 

코드 설계 절차

코드화 항목 선정 → 목적 설정 → 대상 확인 → 범위 결정 → 코드 사용 기간 설정 → 특성 분석 → 방식 결정 → 문서화

 

[4] HIPO

HIPO는 시스템의 분석 및 설계, 문서화할 때 사용하며, 하향식 소프트웨어 개발을 위한 문서화 도구

 

HIPO 특징

체계적인 문서관리 가능, 보기가 쉬어 이해 용이, 의존 관계를 동시에 표현 가능, 변경 및 유지보수 용이

 

HIPO 차트 종류 : 가총세

가시적 도표, 총체적 도표, 세부적 도표

 

1.3. 소프트웨어 아키텍처 (★★)

[1] 소프트웨어 아키텍처란?

소프트웨어 구성요소와 구성요소 특성 중 외부에 드러나는 특성 그리고 구성요소 간의 관계를 표현한 시스템 구조

즉, 소프트웨어를 설계하고 전개하기 위한 지침과 원칙

 

[2] 소프트웨어 아키텍처 설계

 ♣ 기능적 요구사항 - 구현

 ♣ 비기능적 요구사항 - 반영

 

[3] 소프트웨어 아키텍처 기본원리

모듈화 : 시스템의 수정, 재사용, 유지보수 등이 용이하도록 기능을 모듈 단위로 나눔 

           모듈이 크기가 크다 〓 모듈 개수 적고 모듈 간 통합 비용 적고 모듈 하나의 개발 비용이 큼

 

추상화 : 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화

           추상화 유형에는 과정 추상화, 데이터 추상화, 제어 추상화가 있음

 

단계적 분해 : 문제로 상위 중요 개념으로부터 하위의 개념으로 구체화 (하향식 설계 전략, 반복에 의해 세분화, 절차적)

 

정보은닉 : 서로 다른 모듈이 내부 절차에 자료에 접근하여 변경하지 못하게 만듬 (독립적 모듈 수행 가능)

 

[4] 소프트웨어 아키텍처 4+1 뷰

고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

출처 : https://slidesplayer.org/slide/14653385/

 

[5] 소프트웨어 아키텍처 비용 평가 모델

아키텍쳐 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델

 

소프트웨어 아키텍쳐 비용 평가 모델 종류 : SACAA (붐 샤카라카 붐 샤카라카)

 

출처 : https://howtofish.tistory.com/entry/SE-소프트웨어-아키텍처-평가

 

[6] 소프트웨어 아키텍처 설계 과정

 ① 설계 목표 설정 

 ② 시스템 타입 결정 : 대화형 / 이벤트 중심형 / 변환형 / 객체 영속형

 ③ 아키텍처 패턴 적용

 ④ 서브시스템 구체화

 ⑤ 검토

 

[7] 아키텍처 패턴

아키텍처 설계 시 참조할 수 있는 전형적인 해결방식, 예제

 

아키텍처 패턴 장점 : 시행착오 줄임, 예측 가능, 안정적 개발 가능

 

아키텍처 패턴 종류

구분	설명	개념도
레이어 패턴	시스템을 계층으로 구분하여 구성하는 패턴  ▶ 각각의 서브 시스템이 계층 구조를 이룸  ▶ 각 하위 모듈들은 특정한 수준의 계층화를 제공  ▶ 각 계층은 다음 상위 계층에 서비스 제공  ▶ 레이어 패턴은 서로 마주 보는 두 개의 계층 사이에서만      상호작용이 이루어짐
클라이언트-서버 패턴	하나의 서버와 다수의 클라이언트로 구성된 패턴  ▶ 사용자가 클라이언트를 통해 서버에 서비스 요청 →       서버는 클라이언트에 서비스 요청  ▶ 서버는 클라이언트로부터 요청을 대비해 항상 대기  ▶ 클라이언트와 서버는 요청과 응답의 경우를 제외하고 항상 독립적
파이프-필터 패턴	데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴  ▶ 서브 시스템이 입력 데이터를 받아 처리하고 결과를      다음 서브 시스템으로 전달  ▶ 재사용성이 좋고 추가가 쉬워 확장이 용이함  ▶ 필터 컴포넌트를 재배치하여 다양한 파이프라인 구축 가능  ▶ 데이터 변환, 버퍼링, 동기화에 사용
MVC 패턴	대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화  ▶ 모델 : 핵심 기능과 데이터 보관  ▶ 뷰 : 사용자에게 정보 표시  ▶ 컨트롤러 : 사용자로부터 받은 입력 처리  ▶ 각 부분은 독립적으로 분리되어 독자적인 개발 진행  ▶ 여러 개의 뷰를 만들 수 있어 한 개의 모델에      여러 개의 뷰를 활용한 대화형 구현 가능
브로커 패턴	사용자가 원하는 서비스와 특성을 블로커 컴포넌트에 요청하면 요청에 맞는 컴포넌트 연결  ▶ 브로커 컴포넌트가 컴포넌트 간의 통신을 조정하는 역할 수행

2. 객체 지향 설계

2.1. 객체 지향 (★★★)

[1] 객체지향이란?

실세계의 개체를 속성과 메소드가 결합한 형태의 객체로 표현하는 기법

 

[2] 객체지향 구성요소 : 클객메메인속 (앞으로 클 자객을 매매한 인간의 속내)

 - 클래스 : 객체지향 프로그램에서 데이터를 추상화하는 단위, 유사한 객체들을 묶어 공통된 속성과 연산을 표현

               최상위 클래스 : 상위 클래스를 갖지 않는 클래스 / 슈퍼 클래스 : 부모 클래스 / 서브 클래스 : 자식 클래스 

 

 - 객체 : 데이타 + 함수, 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유, 객체마다 다른 상태와 식별성 보유

            객체는 독립적인 이름 보유, 객체는 시간에 따라 상태가 변함, 객체 간의 상호 연관성에 의해 관계 형성

 

 - 메소드 : 객체를 사용하는 방법, 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산

 

 - 메시지 : 객체 간 상호작용을 하기 위한 수단, 상호작용은 메시지를 통해 이루어짐, 객체에서 객체로 전달

 

 - 인스턴스 : 객체지향 기법에서 클래스에 속한 객체를 정의

 

 - 속성 : 객체들이 가지고 있는 데이터 값들을 단위별로 정의

 

[3] 객체지향 기법 : 캡상다추정관

 - 캡슐화 : 관련성이 많은 데이터와 관련된 함수들을 한 묶음으로 처리하는 기법, 결합도가 낮아지고 재사용이 용이

              인터페이스가 단순화, 정보은닉과 밀접한 관계, 세부 내용이 은폐되어 외부에서 변경이 어려움

 

 - 상속성 : 상위 클래스의 속성과 메소드를 하위 클래스에서 재정의 없이 물려받음

               하위 클래스는 새로운 속성과 메소드를 첨가하여 사용 가능 

 

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

              객체지향의 오버로딩 개념, 동일한 메소드명 사용

 

 - 추상화 : 공통 성질을 추출하여 추상 클래스를 설정하는 기법

 

 - 정보은닉 : 코드 내부 데이터와 메소드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 기술

 

 - 관계성 : 두 개 이상의 엔터티 형에서 데이터를 참조하는 관계를 나타내는 기법, 종류로는 연집분일특

              연관화, 집단화, 분류화, 일반화, 특수화

 

[4] 객체 지향 설계 원칙 : SOLID

 - 단일 책임의 원칙(S) : 하나의 클래스는 하나의 목적을 위해서만 생성됨, 객체지향 프로그래밍의 가장 기초 원칙 

 - 개방 폐쇄 원칙 (O) : 소프트웨어 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고 변경에는 닫혀야 함

 - 리소코프 치환의 원칙 : 서브 타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 함

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

 - 의존성 역전의 원칙 : 실제 사용 관계는 바뀌지 않고 추상을 매개로 메시지를 주고받으며 관계를 느슨하게 만듬 

 

[5] 객체 지향 모델링 기법 : 객동기  (광복 후 급격한 객동기)

 - OOSE (객체 모델링) : 유스케이스에 의한 접근 방법, 유스케이스를 모든 모델의 근간으로 활용

                               분석 → 설계 → 구현 단계로 구성, 기능적 요구사항 중심의 시스템

 

 - OMT (동적 모델링) : 객체지향 분석, 시스템 설계, 오브젝트 설계 및 구현의 4단계로 구성, 대형 프로젝트에 유용

                              럼바우의 객체 지향 분석 절차는 객체 모델링 → 동적 모델링 → 기능 모델링 순, 의사소통 편리

 

 - OOD (기능 모델링) : 설계 부분만 존재, 설계 문서화를 강조하여 다이어그램 중심으로 개발

                               미시적 분석 방법과 거시적 분석 방법으로 모두 사용, 분석과 설계 분리 불가능

 

2.2. 디자인 패턴 (★★★)

[1] 디자인 패턴이란?

소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

 

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

 - 패턴의 이름 : 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형

 - 문제 및 배경 : 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미

 - 솔루션 : 디자인 패턴을 이루는 요소들, 관계, 협동 과정

 - 사례 : 디자인 패턴 적용 사례

 - 결과 : 디자인 패턴을 사용하면서 얻게 되는 이점

 - 샘플 및 코드 : 디자인 패턴이 적용된 코드

 

[3] 디자인 패턴 유형 

- 목적 

 ▶ 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 생성 방식을 구조화, 캡슐화를 수행하는 패턴

 ▶ 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴

 ▶ 행위 : 클래스나 객체들이 상호작용ㅎ는 방법과 역할 분담을 다루는 패턴

 

- 범위

 ▶ 클래스 : 클래스 간 관련성, 컴파일 타임에 정적으로 결정

 ▶ 객체 : 객체 간 관련성, 런타임에 동적으로 결정

 

[4] 디자인 패턴 종류

- 생성 패턴 : 생빌프로팩앱싱 (생더블 날빌을 프로브 안 뽑고 하길래 팩토리 앱온해서 싱나게 부심)

   객체의 생성과 참조 과정을 샘플화하여 객체가 생성되거나 변경되어도 프로그램에 영향을 크게 주지 않음

 

 ★ 빌더 패턴 (Builder) : 생성 단계를 캡슐화하여 구축 공정을 동일하게 이용, 인스턴스를 조합하듯이 객체 생성

 ★ 프로토타입 패턴 (Prototype) : 원본 객체를 복제하여 새 객체를 생성하는 패턴 

 ★ 팩토리 메소드 (Factory Method) : 객체 생성을 서브 클래스에서 처리할 수 있도록 분리하여 캡슐화한 패턴

 ★ 추상 팩토리 (Abstract Factory) : 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹을 생성하여 추상화

 ★ 싱글톤 (Singleton) : 유일한 하나의 인스턴스를 보장하도록 하는 패턴, 하나의 객체를여러 프로세스가 동시에 참조 X

 

- 구조 패턴 : 구브데퍼플프록컴어 (구 부대 퍼플 프로토스 컴퓨터 병력 어디갔냐?

   클래스나 객체들을 조합하여 더 큰 구조를 만들 수 있게 해주는 패턴

 

 ★ 브릿지 (Bridge) : 추상화 구현을 분리하여 결합도를 낮춘 패턴, 서로가 독립적으로 확장 가능

 ★ 데코레이터 (Decorator) : 소스를 변경하지 않고 기능을 확장하도록 하는 패턴, 객체 간의 결합을 통해 확장

 ★ 퍼싸드 (Facade) : 하나의 인터페이스를 통해 느슨한 결합을 제공하는 패턴, 서브 클래스의 기능을 간편하게 사용

 ★ 플라이웨이트 (FlyWeight) : 대량의 작은 객체들을 공유하는 패턴, 공유해서 사용하기 때문에 메모리 절약 가능

 ★ 프록시 (Proxy) : 대리인이 일을 처리하는 패턴, 접근이 어려운 객체와 연결하려는 객체 사이에 인터페이스 역할을 수

 ★ 컴포짓 (Composite) : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고 싶을 때 사용하는 패턴

 ★ 어댑터 (Adapter) : 호환성이 없는 인터페이스로 인해 함께 사용하지 못하는 클래스를 사용하도록 변환해주는 패턴

 

- 행위 패턴 (생성과 구조에 없는 패턴은 모두 행위패턴)

   클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의한 패턴

 

 ★ 인터프리터 (Interpreter) : 언어 규칙 클래스를 이용하는 패턴

 ★ 템플릿 메소드(TM) : 알고리즘 골격의 구조를 정의, 상위 클래스에서 골격을 정의하고 하위 클래스에서 구체화

 ★ 책임 연쇄 (CoR) : 객체들끼리 연결 고리를 만들어 내부적으로 전달, 한 객체가 처리하지 못하면 다음 객체로

 ★ 커맨드 (Command) : 요청 자체를 캡슐화하여 파라미터로 전달, 요청에 필요한 정보를 저장하거나 로그에 남김

 ★ 이터레이터 (Iterator) : 내부 표현은 보여주지 않고 순회, 접근이 잦은 객체에 대해 동일한 인터페이스를 적용

 ★ 중재자 (Mediator) : 수 많은 객체들 간의 상호작용을 캡슐화하여 객체로 정의하는 패턴

 ★ 메멘토 (Memento) : 상태 값을 미리 저장해 두었다가 복구하는 패턴, 요청에 따라 해당 시점의 상태를 되돌림

 ★ 옵저버 (Observer) : 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달

 ★ 상태 (State) : 객체 내부 상태에 따라 행위를 변경, 동일한 동작을 다르게 처리할 때 사용

 ★ 전략 (Strategy) : 다양한 알고리즘을 캡슐화하여 알고리즘 대체가 가능하도록 한 패턴, 상호 교환할 수 있음

 ★ 방문자 (Visitor) : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 클래스로 구성