4장(서버 프로그램 구현)
소프트웨어 아키텍처
→ sw 를 구성하는 요소들 간의 관계를 표현하는 구조 또는 구조체
- 모듈화 (Modularity) - 성능향상, 수정 및 재사용을 위해 시스템의 기능들을 모듈 단위로 나누는 것.
- 추상화 (Abstraction) - 먼저 추상적이고 포괄적인 개념을 설계 후 구체화 시켜 나가는 것.
과정 추상화 자세한 수행 과정을 정의 하지 않고, 전반적인 흐름만 파악.
| 데이터 추상화 | 데이터의 세부적 속성은 파악하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체 |
| 제어 추상화 | 이벤트의 발생도 대표 표현으로 대체. |
- 단계적 분해 (Stepwird Refinement) - 상위의 중요 개념 에서 하위로 구체화 시켜 나가는 것.
- 정보 은닉 (Information Hiding) - 절차와 자료를 감추어 다른 모듈이 접근, 변경하지 못하게 함.
상위설계 하위 설계
| 별칭 | 아키텍처 설계, 예비설계 | 모듈 설계, 상세 설계 |
| 설계대상 | 시스템 전체 구조 | 시스템의 내부 구조 및 행위 |
| 세부 목록 | 구조, DB, 인터페이스 | 컴포넌트 ,자료구조, 알고리즘 |
객체지향 분석 → 사용자의 요구사항 모두를 정의하여 모델링 하는 작업.
객체 → 데이터와 이를 처리하기 위한 함수를 묶어놓은 소프트웨어 모듈.
객체지향 구성요소
- 객체
- 클래스
- 메시지
객체지향의 특성
- 캡슐화
- 상속
- 다형성 - 하나의 메세지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력
- 연관성
방법론
- 럼바우(객동기) 객객 동상기자
객체 모델링 정보 모델링이라고도 하며, 객체들간의 관계를 규정하여 객체 다이어그램으로 표현
| 동적 모델링 | 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들간의 제어흐름, 상호작용, 동작순서등 동적인 행위를 표현 하는 모델링. |
| 기능 모델링 | 자료흐름도(DFD)를 이용하여 프로세스들 간의 자료흐름 처리과정을 표현한 모델링. |
- 부치(Booch) - 미시적 개발 프로세스와 거시적 개발 프로세스 모두 사용
- Coad와 Yourdon - E-R 다이어그램을 사용하여 객체의 행위를 모델링함.
모듈 (Module) → 독립성을 높이기위해
결합도는 낮고 응집도는 높아야 한다.
← 나쁨 좋음 →
| 내용 결합도 | 공통 결합도 | 외부 결합도 | 제어 결합도 | 스탬프 결합도 | 자료 결합도 | |
| 우연적 응집도 | 논리적 응집도 | 시간적 응집도 | 절차적 응집도 | 통신적 응집도 | 순차적 응집도 | 기능적 응집도 |
결합도 (모듈 외부의 결합도)
내용 결합도 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우의 결합도(얽혀잇음) (안좋은것)
| 공통 결합도 | 전역변수를 갱신하는 식으로 상호 작용하는 경우 |
| 외부 | 외부 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도 |
| 제어 | 어떤 모듈이 다른 모듈의 내부에 제어 신호를 이용하여 통신하는 경우 (if, for) |
| 스탬프 | 모듈간의 인터페이스로 배열이나 객체, 구조등이 전달되는 결합도 (배열, 포인터 등) |
| 자료 | 모듈간의 자료(값)만 통해서만 모듈을 호출하는 것 (좋음) |
응집도 (모듈 내부의 결합도)
우연적 응집도 아무 연관관계없는 것을 모아놓은 것 (안좋음)
| 논리적 응집도 | 논리적으로 비슷한 것 끼리 모아서 수행하는 것 |
| 시간적 응집도 | 같은시간대에 처리되는 것을 모아서 처리하는 것 |
| 절차적 응집도 | 모듈안의 구성요소들이 순차적으로 수행되는경우 |
| 통신적 응집도 | 동일한 입력과 동일한 출력 |
| 순차적 응집도 | 한 활동으로 나온 출력값이 다른활동의 입력값이 되는 것 |
| 기능적 응집도 | 모듈 내부의 기능들이 단일목적을 위해 똘똘뭉쳐있는 상태 (좋음) |
디자인 패턴 (Design Pattern)
→ 모듈간의 관계 및 인터페이스를 설계할때 참조할 수 있는 전형적인 해결방식
생성패턴
→ 클래스나 객체의 생성과 참조 과정을 정의
| 추상 팩토리 (Abstract Factory) |
인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현함. |
| 빌더 (Builder) |
인스턴스를 건축하듯이 조합하여 객체를 생성 |
| 팩토리 메소드 (Factory Method) |
객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당 |
| 프로토타입 (Prototype) |
원본 객체를 복제하는 방법으로 객체를 생성하는 패턴 비용이 클 경우 주로 이용 |
| 싱글톤 (Singleton) |
하나의 객체를 생성하면 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조 할 수는없음. |
구조패턴
→ 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴
| 브리지 (Brdige) |
구현부에서 추상층을 분리하여 서로가 독립적으로 확장 할 수 있도록 한 패턴 |
| 데코레이터 (Decorator) |
객체간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴 |
| 퍼싸드 (Facade) |
복잡한 서브클래스들을 피해 더 상위에 인터페이스를 구성함으로 서브 클래스의 기능을 간편하게 사용할 수 있도록 하는 패턴 |
| 플라이 웨이트 (Flywegiht) |
메모리를 절약하는 패턴 (인터페이스를 공유해 사용) |
| 프록시 (Proxy) |
접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴 |
| 컴포지트 (Composite) |
여러 객체를 가진 복합개체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴 |
| 어댑터 (Adapter) |
호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용 할 수 있도록 변환해주는 패 |
행위패턴
→ 클래스나 객체들이 상호작용하는 방법이나 책임분배 방법을 정의하는 패턴
| 책임연쇄 (Chain of Responsibility) |
요청을 처리할 수 있는 각 객체들이 고리로 묶여있어 요청이 해결될 때 까지 고리를 따라 책임이 넘어감 |
| 커맨드 | 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴 |
| 인터프리터 | 언어에 문법 표현을 정의하는 패턴. (SQL 이나 통신 프로토콜 개발시 사용) |
| 반복자 | 접근이 잦은 객체에 대한 동일한 인터페이스를 사용하도록 하는 패턴 |
| 중재자 | 객체들간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴 |
| 메멘토 | Ctrl+z와 같은 되돌리기 기능을 개발할때 주로 이용 |
| 옵서버 (Observer) |
한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴 |
| 상태 | 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴 |
| 전략 (Strategy) |
클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있음. 클라이언트의 영향 없이 알고리즘의 변경이 가능. |
'정보처리기사 > 단원별 개념정리' 카테고리의 다른 글
| 정보처리기사-6장(화면설계,UI, 품질요구사항, ISO/IEC) (0) | 2023.01.25 |
|---|---|
| 정보처리기사-5장(인터페이스, 미들웨어, 모듈연계) (0) | 2023.01.25 |
| 정보처리기사-3장(통합구현, XML, IPC..) (0) | 2023.01.25 |
| 정보처리기사-2장 (DBMS, 정규화, 트랜잭션, DB보안(임의,강제,역할기반)).. (0) | 2023.01.25 |
| 정보처리기사-1장 요구사항 확인(SDLC, XP, 자료흐름도DFD, UML...) (0) | 2023.01.25 |
