애플리케이션 설계 - 모듈, 객체지향 설계, 디자인 패턴

정보처리기사 필기 준비하며 정리한 내용입니다.

공통 모듈 설계

공통 모듈

• 모듈의 개념
  • 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드.
    • 자체적으로 컴파일 가능.
    • 다른 프로그램에서 재사용이 가능하다.
    • 유지보수하기도 쉽다
  • 프로그램은 모듈의 결합이다.
  • 모듈 중 자주 사용하는 것들이 공통 모듈이다

재사용

• 재사용 범위에 따른 분류 ⭐
  1. 함수와 객체
  2. 컴포넌트
  3. 애플리케이션
  단위 크기 : 함수와 객체 < 컴포넌트 < 애플리케이션
• 재사용 유형
  1. 편의적 재사용
     • 전에 만든 것 중에 재사용할 거 있나?
  2. 계획적 재사용
     • 지금 만드는 걸 나중에도 재사용할 거야!
• 재사용의 대표적인 사례
  1. 라이브러리 : 언어에 종속적!
     • 내부 라이브러리
       • 언어 자체에서 기본적으로 제공하는 라이브러리
     • 외부 라이브러리
       • 기본적으로 제공하지 않는데 외부에서 다른 누군가가 만들어 공유해준 것
  2. 디자인 패턴
     • 선인들이 이런 식으로 했더니~ 효율적으로 잘 돌아가더라~ 하는 것들(방식들)을 만들어둔 것
       • 문서라고 보면 된다 (가이드, 설명서- 이런 개념)
         • 완벽하게 가져다 쓸 순 없다!
  3. 프레임워크
     • 공통적으로 뼈대를 제공하는 툴
     • 전체적인 구성을 제공한다!
     • ex. 전자정부 프레임워크 : spring보다 좀 더 큰 틀을 만든 것

공통 모듈 작성 원칙

• 정확성 : 해당 기능이 실제 시스템 구현 시 필요한지 여부를 알 수 있도록 정확하게
• 명확성 : 한가지로 해석될 수 있게
• 완전성 : 모든 걸 기술해야
• 일관성 : 기능 간 상호충돌 없게
• 추적성 : 누가 어떻게 썼는지~ 등의 출처 추적 가능

📌모듈화

• 재사용할 수 있도록 시스템을 분해하고 추상화하는 기법
• 필요성
  • 관리의 용이
  • 복잡도 감소
  • 개발 및 유지보수 용이
• 응집도는 높이고 결합도는 낮추는 모듈 설계로, 모듈의 독립성이 올라간다 → 재사용을 할 수 있게 된다.

1) 응집도 Cohesion ⭐⭐⭐

• 모듈 하나가 내부에서 똘똘 뭉쳐서 하나의 역할만 수행해야 한다.
• 응집도가 높을수록 필요한 요소들로 구성되어 있다.
• 높을수록 잘 설계된 모듈이다.

🔻 응집도의 유형 ⭐

• 기능적 응집도 Functional Cohesion
  • 가장 좋다! 모듈 내부 모든 기능이 단일한 목적을 위해 수행되는 경우
• 순차적 응집도 Sequential Cohesion
  • 모듈 내부에서 나온 출력값이 그 다음의 일에 입력값으로 사용된다.
• 통신적 응집도 Communication Cohesion
  • 동일 입력 출력 사용
• 절차적 응집도 Precedural Cohesion
  • 순차적으로 처리될 때
  • (모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우)
• 시간적 응집도 Temporal Cohesion
  • 특정 시간에 처리되어야 하는 활동을 한 모듈 안에 넣은 것 (연관기능과는 관계없다)
• 논리적 응집도 Logical Cohesion
  • 유사한 것들 모아놓음
• 우연적 응집도 Coincidental Cohesion
  • 아무 연관관계 없는(별 상관없는) 것들이 그냥 모여있는 경우

2) 결합도 Coupling ⭐⭐⭐

• 모듈과 모듈관의 관련성 / 의존성 정도
• 낮을수록 잘 설계된 모듈
  • 각 모듈의 독립성이 높아진다

🔻 결합도의 유형 ⭐

• 자료 결합도 Data Coupling
  • 두 모듈 사이에 매개변수(인터페이스)로 값만 전달될 때
  • 결합도 가장 낮다 (제일 좋음)
• 스탬프 결합도 Stamp Coupling
  • 두 모듈 사이에 인터페이스로 배열, 오브젝트, 스트럭처 등이 전달되는 경우
• 제어 결합도 Control Coupling
  • 제어 요소가 전달이 될 때
• 외부 결합도 External Coupling
  • 외부에 있는 변수를 참조할 때
• 공통 결합도 Common Coupling
  • 전역 변수를 쓸 때
• 내용 결합도 Content Coupling
  • 내부에 있는 변수나 기능을 다른 모듈에서 사용 (스파게티 코드!)
  • 결합도 가장 높다 (제일 안좋음)

3) 팬인Fan-in, 팬아웃Fan-out ⭐

팬인, 팬아웃의 개념은 보통 개수!

• 시스템 복잡도를 최적화하기 위해서는
  • 팬인을 높게 (내가 호출되는 것)
  • 팬아웃은 낮게 (내가 호출하는 것)

---

설계에 관하여

협약에 의한 설계 ⭐

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

(멋대로 하지 말고 협약에 따라 설계한다~ 는 의미)

• 선행 조건 : 설계 전에 어떤 일이 있어야 되느냐
• 결과 조건 : 이 설계를 통과했을 때 어떤 결과가 나와야 하느냐
• 불변 조건 : 항상 만족되어야 하는 조건

설계의 종류

• 상위 설계(케이스도구)
• — 분석과 설계에 관련된 것
• 하위 설계(케이스도구)
  • 모듈 설계, 자료구조 설계, 알고리즘 설계
    • 자료구조 : 컴퓨터 안에 들어가는 데이터를 어떻게 효율적으로 저장할 것인지에 대한 학문. 이 자료구조를 구현하기 위해서는 알고리즘이 들어가야 한다. 뗄레야 뗄 수 없는 관계!
• — 개발 단계 (구현, 테스트)

설계의 원리 ⭐

• 분할과 정복 (Divide & Conquer)
  • 작게 나눠서 차근차근
• 추상화 (Abstraction)
  • 공통의 성질을 뽑아내는 것 (공통 모듈을 뽑아내는 것)
  • 기법 ⭐
    • 과정 추상화
    • 데이터 추상화
    • 제어 추상화 (명령)
• 단계적 분해
  • 기능을 작은 단위로 나누어 점차적으로 구체화하는 방법
• 모듈화
  • 실제로 개발할 수 있는 작은 단위로 나눈다
• 정보 은닉
  • 중요한 정보는 감추자
  • 같이 사용되는 것이 캡슐화
  • 외부에선 접근이 불가능하고 해당 클래스에서만 사용 가능
    • ex. -weight / +getWeight
      • 누가 언제 사용했는지 log가 남는다

설계 유형 2가지

1. 구조 모델링
   • UML 정적 다이어그램에 해당된다
2. 행위 모델링
   • 구조가 어떤 상태값으로 바뀔 것인지
   • UML 행위 (동적) 다이어그램

---

📌코드 설계

• 유형
  1. 순차 코드 Sequence Code⭐
     • 일정한 순서에 의해 일련번호를 부여하는 코드
  2. 블록 코드 Block
     • 코드화 할 대상이 갖는 공통 특징 중심
     • ex. 시 군 구
  3. 10진 코드 Decimal
     • 10진수 형태로 표현
  4. 그룹 분류 코드
     • 대분류-중분류-소분류
     • 각 분류별로 번호 순서 부여
  5. 연상 코드 Mnemonic ⭐
     • 뭔가 연상될 수 있는 것 (쉽게 파악할 수 있도록)
     • ex. TV_2021_04
  6. 표의 숫자 코드 Significant Digit ⭐
     • 중량, 면적, 용량 등의 물리적 수치 이용
     • ex. 30-50-120 (길이, 너비, 용량)
  7. 합성코드
     • 두 개 이상의 코드 조합
• 오류 발생 형태
  1. 생략 오류 Omission error
     • 입력 시 한 자리 빼놓고 기록
     • 1234 → 123
  2. 필사 오류 Transcription
     • 임의의 한 자리 잘못 기록
     • 1234 → 1235
  3. 전위 오류 Transposition
     • 좌우 자리 바꾸어 기록
     • 1234 → 1243
  4. 이중 오류 Double Transposition
     • 전위 오류 두가지 이상 발생
     • 1234 → 2143
  5. 추가 오류 Addition ⭐
     • 입력 시 한자리 추가로 기록
     • 1234 → 12345
  6. 임의 오류 Random
     • 위의 오류가 두 가지 이상 결합
     • 1234 → 12367

---

📌객체지향 설계 (OOP, Object Oriented Programming)

요즘에 나오는 프로그래밍 언어 대부분. (JS는 예외로 상속 같은 개념은 없다)

C, 코볼 등이 절차지향 언어

객체지향의 개념

1. 객체object로 나누고
2. 구조를 만들어
3. 객체의 행동method와
4. 고유한 값attribute(속성)을 정의하여 설계(이 객체 안에 메서드도 있고 속성도 있고)
5. 이는 현실 세계의 유형일 수도 있고 무형일 수도 (회원, 주문, 상품 등)

객체지향 구성요소 ⭐

1. 클래스 Class ⭐유사한 유/무형의 존재를 **속성(멤버 변수)**과 **연산(method:속성의 값을 바꿀 수 있다)**을 정의해서 만든 틀.
   • 다른 클래스와 독립적으로 디자인한다.
   • 데이터를 추상화 하는 단위 (공통의 성질로 묶을 수 있는 단위)
     • 추상화한 걸 상속받아서 자기만의 고유한 틀을 만들 수 있다.
2. = 구조

2. 객체 Object

• 클래스의 인스턴스
  • 자바로 예시를 들면
    • User a = new User()
    • User라는 구조(Class)로 a라는 인스턴스를 만들게 된다.
    • User가 갖고 있는 구조 그대로 (속성, 연산 등) 갖고 메모리에 올라간다. (틀은 올라가지 않는다)
    • 실제로 메모리에 올라간 상태가 객체 인스턴스.
• 객체는 자신 고유의 속성을 가진다
  • a도 User 클래스 안에 있는 항목들을 가지고
  • b도 가진다.
    • 즉 같은 걸 공유하는 게 아니라는 뜻

1. 속성 Attribute = 멤버변수
   • 객체들이 가지고 있는 고유한 값을 단위별로 정의
   • 성질, 분류, 수량, 현재 상태 등
     • ex. ID, PW, 전화번호 등
2. 메서드 Method
   • 속성에 있는 값을 변경시킬 수 있는 연산.
   • 어떤 특정한 작업을 수행하기 위한 명령문의 집합.
3. 메세지 Message
   • 객체 간 상호작용
     • 객체의 메서드를 호출하여
   • 객체에게 어떤 행위를 하도록 지시

객체지향의 특징 ⭐

1. 캡슐화 Encapsulation
   • 데이터attribute와 데이터를 처리하는 행동method을 하나로 묶은 것
   • 캡슐화된 객체의 세부내용은 외부에 은폐된다
     • 오류의 파급 효과가 적다
   • 객체들 간 메시지를 주고받을 때 해당 객체의 세부 내용을 알 필요가 없으므로,
     • 인터페이스가 단순해지고, 결합도가 낮아진다.
       • 독립성 높아짐
         • 재사용용이
2. 정보은닉 Information Hiding
   • 캡슐화의 핵심 개념
   • 다른 객체에게 자신의 데이터를 숨기고, 자신이 정의한 행동만을 통하여 접근을 허용.
3. 상속 Inheritance
   • extends로 상위클래스의 모든 데이터 (프라이빗 제외) 행동을 하위 클래스가 물려받는 것
   • 상위클래스의 데이터와 행동을 자신의 클래스에 다시 정의하지 않아도 됨
     • +a 로 추가도 가능
   • 상위 클래스 요소들을 사용할 수 있기 떄문에
     • 소프트웨어 재사용을 증대시키는 중요한 개념.
4. 다형성 Polymorphism각 객체가 가지고 있는 여러 가지 방법으로 응답할 수 있는 개념
   1. 오버로딩
      • 똑같은 이름의 메서드를 여러개 만드는 것
      • 메서드명은 똑같고 인자가 다른 경우
        • a(), a(), a(x,y)
   2. 오버라이딩
      • 상속관계에서만 존재
      • 부모로부터 물려받은 걸 재정의
5. (형태가 다양한 성질)
6. 추상화 Abstraction
   • 중요하다! 디자인 패턴의 거의 대부분의 클래스구조가 추상화 구조를 띠고 있다.
   • 공통적인 부분들만 모아놓은 것
   • 공통적인 특성을 상위클래스에서 정의하고, 하위클래스가 해당 메소드를 재정의하는 것

객체지향의 설계원칙 SOLID ⭐⭐⭐

이런 식으로 설계의 방향을 잡으라는 지침이다.

1. 단일 책임 원칙 SRP Single responsibility principle
   • 하나의 클래스는 하나의 책임만을 가져야 한다.
2. 개방 폐쇄 원칙 OCP Open-closed principle
   • 잘 설계해서 수정하지 말자 = 기존 코드 변경X Closed
     • 수정할 일이 있으면 확장으로 (상속받아서~) = 기능을 추가할 수 있도록 Open 설계하자
3. 확장에는 열려있고 수정에는 닫혀있자
4. 리스코프 치환 원칙 LSP Liskov substitution principle
   • 하위클래스는 언제나 상위클래스를 대체할 수 있어야 한다.
   • 상위클래스가 들어갈 자리에 하위클래스를 넣어도 계획대로 작동해야 한다.
5. 인터페이스 분리 원칙 ISP Interface Segregation Principle
   • 쓸데없는 인터페이스 만들지 마라 (내가 진짜 사용할 것만 만들어라)
6. 의존성 역전 원칙 CIP Dependency Inversion Principle
   • 의존 관계 맺을 때 변화 거의 없는 것에 의존해야
     • 자주 변화하는 건 X
   • 구체적 클래스 X. 인터페이스나 추상 클래스와 의존 관계를 맺어야 한다.
     • 추상화!

---

📌디자인 패턴 Design Pattern

• 개념
  • 선인들이 이렇게하면 더 효율적인 설계가 가능하다고 만들어 준 가이드
  • 재사용할 수 있도록 만들어놓은 패턴들의 모음
  • 효율적인 코드를 만들기 위한 방법론

디자인 패턴의 구성요소 ⭐

1. 이름과 유형
2. 문제 및 배경
3. 솔루션 : 패턴 이루는 요소 관계, 협동과정
4. 사례
5. 결과 : 적용했을 때의 이점과 영향
6. 샘플 코드 ⭐

GoF(Gang of Four) 디자인 패턴 ⭐

• 각각 디자인 패턴을 생성, 구조, 행위 3가지로 분류

1. 생성패턴 Creational
   • 객체 생성할 때 이렇게 생성하면 더 효율적으로 생성할 수 있더라
   • 추상화 방법 (디자인 패턴은 죄다 추성화!)
   • 종류
     • 추상 팩토리
     • 빌더
     • 팩토리 메소드 : 찍어내는 패턴 - 위임하여 캡슐화
     • 프로토타입 : 원본-시제품 복사
     • 싱글톤 : 인스턴스가 하나임을 보장함 (참조는 하나만!)
2. 구조패턴 Structural
   • 구조를 접목시킬 때 이렇게 하면~
   • 클래스나 인터페이스 합성
   • 클래스 객체 조합해 더 큰 구조로 만든다
   • 종류
     • 어댑터 : 변환
     • 브리지 : 분리해서 확장할 수 있도록
     • 컴포지트 : 객체들의 관계를 트리 구조로 구성
     • 데코레이 터 : 덧붙인다
     • 퍼사드 ⭐ : 서브시스템에 있는 인터페잉스 집합에 대해 하나의 통합된 인터페이스 Wrapper 제공
     • 플라이웨이트 : 공유로 메모리 절약
     • 프록시 : 객체의 대리surrogate나 대체글placeholder을 제공
3. 행위패턴 Behavioral
   • 뭔가 그 객체들이 동작하면서 나타나는 패턴들
   • 클래스나 객체들이 상호작용하는 방법 정의
   • 결합도 최소화를 도운다
   • 종류
     • 책임 연쇄 : 연쇄적으로 묶어 요청 처리하는 객체 만날때까지
     • 커맨드
     • 인터프리터 : 특정 언어의 문법 표현 정의
     • 반복자
       • 자바의 iterator라는 클래스는 배열 형태다
     • 중재자
     • 메멘토 : 특정 상태로 다시 되돌아올 수 있도록 내부 상태 실체화
     • 옵저버 : 변화를 감지
     • 상태 : 상태에 따라~
     • 전략 : 알고리즘군 정의
     • 템플릿 메소드 : 상위클래스는 골격만 작성 구체적 처리는 서브클래스에 위임
     • 방문자