S1. 어플리케이션 설계
1. 소프트웨어 아키텍처
1) SW 아키텍처 : 기본구조(동일한 아키텍처: 기본 구조가 같은 여러형태의 결과물), 개발기반, 품질유지, 원칙, 지침
2) 모듈화 원리 : 유지관리에 좋음(많으면 통합비용증가, 적으면 개발비용증가)
추상화 : 과정(흐름), 구조(데이터), 제어(이벤트) / 포괄적 개념, 반복할수록 구체화, 가성비, 구조파악 용이
- 단계적 분해 : 하향식, 추상화의 반복으로 더 많은 단계 분해가능
- 정보은닉 : 접근금지, 별도의 인터페이스 사용, 유지보수에 용이
3) 품질속성 : 시스템(성능, 보안), 비즈니스(비용, 자원), 아키텍처(결함)
4) 설계과정 : 목표 - 시스템타입(대화형, 이벤트형, 변호나형, 객체영속형) - 아키텍처패턴(미리 만들어둔 공식) - 시스템구체화 - 검토
2. 아키텍처 패턴(=아키텍처 스타일, 표준 아키텍처) : 문제 해결의 윤곽제시, 원칙과 지침역할
장점 : 시간단축, 품질향상, 검증편리, 소통원활, 이해용이, 예측 가능 등
- 레이어(계층)패턴 : 각각의 상하위 계층과만 소통
- 클라이언트 서버 패턴 : 클라이언트(다수, 자원요청), 서버(항시대기, 자원제공)은 각각 독립적 동작
- 파이프 필터 패턴 : 필터 - 데이터 처리, 캡슐화(정보은닉) : 재사용성, 확장성으로 다양한 파이프라인 생성가능, 데이터변환, 버퍼링, 동기화 작업에 유리
- 모델 뷰 컨트롤러 패턴 : 어플리케이션에 적합
- 마스터 슬레이브 패턴 : 마스터(명령), 슬레이브(병렬처리, 취합, 몇몇이 고장나도 문제x)
- 브로커 패턴 : 클라이언트의 요청을 브로커가 적절한 서버로 연결, 여러개의 서버, 분산환경 시스템
- 피어투피어 패턴(p2p) : 서버와 클라이언트가 역할을 바꿀수 있는 형태(자원요청<->자원제공), 토렌트, 웹하드, 두가지 일을 병렬로 수행하는 멀티스레딩
- 이벤트 버스패턴 : 이벤트 발생시 여러 리스너가 이벤트 처리
- 블랙보드 패턴 : 공유데이터를 관리하는 블랙보드에 접근하여 원하는 데이터를 가짐, 음성인식, 차량식별, 신호해석 등
3. 객체지향 : (객체 : 결과물 통칭), 각 객체들이 서로 메시지를 보내며 기능 및 데이터사용 요청, 결과를 돌려주면서 프로그램 진행
| 절차(구조적)지향 프로그램을 하나의 큰 절차(순서)로 구성 |
데이터 | 상수 | 90 |
| 변수 | score=90 | ||
| 배열 | score={90,80,70} | ||
| 구조체 | student={name="a", score="90"} | ||
| 기능 | 실행문 | 밥을 먹는다 | |
| 분기문(조건제어) | if(true) 밥을 먹는다 else 밥을 안먹는다 | ||
| 반복문(루프문) | |||
| 함수 | 원할때만 |
1) 클래스 : 데이터와 기능을 묶어서 캡슐화한 것, 재사용, 확장(유지보수) 용이
- 인스턴스 : 클래스 재사용을 위한 복제결과물 (과정: 인스턴스화)
- 상속 : 확장(유지보수), 하위클래스는 상위클래스+자신의 요소까지 모두 사용 가능
2) 다형성 : 객체지향의 최종 목표, 클래스의 상속을 통해 확장되어 생성된 인스턴스에 기능제한으로 특정기능만 수행가능한 것
4. 모듈 : 모듈화된 기능(=서브루틴, 서브시스템), 재사용 가능
1) 독립성의 정도 판단 : 약한결합도, 강한응집도
- 결합도 : 상호의존의 정도
자료(data, 데이터로 구성) < 스탬프(stamp, 자료구조로 구성, 다른 모듈이 영향을 받음) < 제어(control, 다른 모듈에서 흐름 제어) < 외부(external, 다른 모듈이 내부 데이터 접근) < 공유(common, 여러 모듈들이 공통으로 데이터 사용) < 내용(content, 내부기능과 데이터 직접 참조)
- 응집도 : 정보은닉의 확장, 내부요소들끼리도 관련성을 판단하여 서로 기능간섭이 없도록, ∝ 품질
기능(functional, 단일문제-단일기능) > 순차(sequential, 이전 모듈출력 -> 다음 모듈 입력) > 통신(communication, 동일입출력으로 서로 다른 기능 수행) > 절차(procedural, 다수의 기능이 순차적으로 진행) > 시간(temporal, 특정 시간대에 처리되는 기능 모음) > 논리(logical, 유사한 기능 모음) > 우연(coincodental, 관련 없는 요소로 구성)
2) 팬-인, 팬-아웃 : 해당모듈을 제어하는, 해당모듈이 제어하는
3) 공통모듈
| 기법 | 설명 |
| 정확성(correctness) | 필요성 |
| 명확성(clarity) | 비중의적(한가지 의미로 해석되도록) |
| 완전성(completeness) | 필요한 모든것 |
| 일관성(consistency) | 충돌방지 |
| 추적성(traceability) | 출처, 관계파악 |
효과적인 모듈 설계방안
결합도↓ + 응집도↑ = 독립성 = 재사용
복잡도↓ + 중복성↓ + 입출력↓ = 품질
5. 코드/디자인 패턴
1) 코드 : 식별, 배열, 분류의 일정한 규칙에 따라 만들어진 기호
순차, 블록(블록구분후 순차), 10진, 그룹분류, 연상, 표의숫자
2) 디자인패턴 = 생성5 + 구조7 + 행위11
- 생성패턴 : 캡슐화, 유연성
추상팩토리(abstract factory) : 객체 생성코드가 상위 클래스에 존재, 하위(구체화)클래스가 상속, 하위클래스에 의존x
메소드팩토리(factory method) : 객체 생성코드를 하위 클래스에서 구체화, 상위클래스는 인터페이스만 제공, 각각의 클래스가 다른 작업수행 가능
빌더(builder) : 분리된 인스턴스를 조합하여 객체 생성
프로토타입(prototype) : 원본복제, 비용저렴
싱글톤(singleton) : 클래스내 인스턴스 하나뿐임을 보장, 동시참조 불가능
- 구조패턴 : 복잡한 구조의 시스템개발에 필요
어댑터(adapter) : 일치하지않는 인터페이스 변환
브릿지(bridge) : 추상층(기능)과 구현층(구체화)을 분리하여 독립적 확장
컴포지트(composite) : 트리구조구성, 단일과 복합개체 구분없이 다룸
데코레이터(decorator) : 기능추가를 위해 다른 객체를 덧붙임
퍼싸드(facade) : 서브클래스들의 통합 인터페이스를 제공(wrapper객체)하는 상위 클래스 구성
플라이웨이트(flyweight) : 다수의 유사 객체 생성이 필요할 때 최대한 공유해서 사용(메모리 절약)
프록시(proxy) : 접근이 어려운 객체에 접근할 수 있도록 인터페이스 역할 수행
- 행위패턴 : 상호작용, 책임분배
책임연쇄(chain of responsibility) : 둘이상의 객체가 연결(chain)되어 책임이 차례로 넘어감
커맨드(command) : 명령어 캡슐화(추상과 구체), 로그에 기록
인터프리터(interpreter) : 문법 표현 정의, 맞춤법 검사
반복자(iterator) : 접근이 잦은 객체는 동일한 인터페이스를 사용하도록, 순차접근
중재자(mediator) : 복잡한 상호작용 캡슐화
메멘토(memento) : 특정시점의 상태 객체화, 되돌리기
목적어(observer) : 이벤트 발행과 구독, 상태변화전달
상태(state) : 상태에 따라 동작을 다르게
전략(strategy) : 동일계열 알고리즘 상호교환, 독립적 사용
템플릿 메소드(template method) : 상위에서 인터페이스 정의, 하위에서 구체화(유지보수)
방문자(visitor) : 처리기능을 별도의 클래스로 구성
