인터페이스 요구사항 검증방법 ① 요구사항 검토 동료검토 PeerReview 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료(주변 이해관계자)가 결함을 발견하는 형태 워크스루 Walk Through 검토회의 전 요구사항 명세서를 미리 배포하여 사전검토 후 짧은 검토회의인 스펙Inspection 요구사항 명세서 작성자 이외의 검토 전문가가 확인
② 프로토타입-실제로 개발되는 소프트웨어 견본품을 작성하여 최종 결과 예측
③ 테스트 설계-테스트 케이스를 생성하여 향후 요구사항이 현실적으로 테스트 가능한지 검토
④ CASE 툴 활용 – 일관성 분석을 통해 요구사항 변경사항 추적, 분석, 관리
코드의 종류 순서차 코드 일정 기준에 따라 최초 자료부터 순서대로 일련변호 부여 1,2,3,4…블록코드 공통성이 있는 것끼리 블록으로 구분하여 각 블록 내에서 일련번호 부여 부서번호 연상코드 명칭, 약호와 관련된 숫자, 문자, 기호를 이용하여 코드 부여 TV-50표의 숫자코드 길이, 넓이, 부피, 지름, 높이와 같은 물리적 수치를 그대로 코드에 적용 12x10x8 합성코드 2개 이상의 코드를 조합하여 만드는 방법 연상+순차 그룹분류코드 대분류, 소분류 등으로 구분하고 그 중에서 일련번호 부여 10진코드 도서분류식
공통 모듈 – 여러 프로그램에서 공통적으로 사용할 수 있는 모듈 – 자주 사용되는 계산식, 사용자 인증 – 재사용성 확보, 중복 개발 회피
정확성 해당 기능이 필요함을 알 수 있도록 명확성 중의 과녁으로 해석되지 않도록 무결성 시스템의 실현을 위한 모든 것을 기술 일관성 상호 충돌이 발생하지 않도록 추적성 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록
미들웨어-오페레이팅 시스템, 애플리케이션 간에 운영체제에서 제공하는 서비스 이외의 추가 서비스 제공-일관성 보증
DB- 클라이언트에서 원격 데이터베이스와 접속하기 위한 미들웨어-2-Tier 아키텍처 RPC Remote Procedure Call – 원격 프로세서 호출 – 응용 프로그램 프로세서를 마치 로컬 프로세서처럼 호출하는 방식 ORBObject Request Broker – 객체 요청 브로커 – 객체 지향 미들웨어로 코바 CORBA 표준 스펙 구현 TP-Monitor Transaction Processing Monitor – 트랜잭션 업무로 트랜잭션을 처리, 감시(항공기, 철도 예약 업무) – 고속 응답 서비스에 적합하다. 앱 애플리케이션 서버 – 정적 콘텐츠 처리하는 웹 서버와 달리 사용자의 요구에 따라 변화하는 동적 콘텐츠를 처리하기 위해 사용 – 웹 환경을 구현하기 위한 미들웨어 MOMMessage Oriented Middleware – 메시지 지향 미들웨어 – 비동기형 메시지 전달 방식 – 온라인 업무보다는 이기종 분산 데이터 시스템 데이터 동기를 위해 사용
디자인 패턴 – 재사용할 수 있는 기본형 코드가 포함 – 개발 중 문제가 발생할 경우 해결책을 구상하는 것이 아니라 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 보다 효율적 – 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화 – 에릭 감마(GoF), 리처드 헬름, 랄프 존슨, 존 브리시디스가 구체화
① 생성 패턴 오브젝트 생성과 관련된 패턴빌더 Builder – 작게 분리된 인스턴스를 건축하도록 조합하여 오브젝트 생성 – 오브젝트 생성 과정과 표현 방법을 분리하였으며, 동일한 오브젝트 생성에도 서로 다른 결과를 만들어낼 수 있는 프로토타입 Prototype – 원본 오브젝트를 복제하는 방법으로 오브젝트 생성 – 비용이 클 경우 주로 이용 팩토리 메서드 Factory Method – 오브젝트 생성을 서브클래스로 처리하도록 분리하여 캡슐화한 패턴 – 상위클래스로 인터페이스만 정의하고 실제 생성은 서브클래스가 담당 추상 팩토리 Abstractory – 구체적인 클래스에 의존하지 않고 의존한다. 추상적으로 표현-관련된 서브 클래스를 만들어 한번에 교환 가능 싱글 톤 Singleton-생성된 객체는 어디서나 참조할 수 있지만 복수의 프로세스가 동시에 참조할 수 없는-클래스 내에서 인스턴스가 하나임을 보장하고 불필요한 메모리 낭비의 최소화 ② 구조 패턴 클래스와 객체를 조합하고 더 큰 구조로 하는 패턴 브리지 Bridge-구현부로부터 추상 계층을 분리하고 서로 독립적으로 확장할 수 있도록 구성-기능과 구현 복합 Composite-여러 객체를 가지는 복합 객체를 구분 없이 다룰 때-객체 속에 디렉터리 안에 구성된 것처럼 복합 객체 중 복합 객체가 포함 구조 구현 가능 파 서드 Facade- 복잡한 서브 클래스를 피하고 상위 인터페이스를 구성하고서브 클래스의 기능을 쉽게 사용할 수 있도록 하는 패턴-Wrapper개체가 필요(서브 클래스 간의 통합 인터페이스를 제공)프록시 Proxy-접근이 어려운 오브젝트와 이에 접속하려는 객체 사이에 인터페이스의 역할을 수행-네트워크 연결, 메모리의 대용량 객체 접근 등에 주로 이용 데커레이터 Decorator-객체 간의 결합을 통해서 능동적으로 기능을 확장-임의의 객체에 부가적인 기능을 추가하기 위해서 다른 반 어댑터 호환성 없는 호환성 없는 호환성 이용할 수 있도록 변환-기존 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 주로 이용 플라이 웨이트 Flyweight-인스턴스가 필요할 때마다 생성하는 것이 아니라 최대한 공유하고 사용했다함으로써 메모리를 적약-다수의 유사 객체를 생성하거나 조작할 때 유용하게 이용 ③ 행위 패턴 클래스나 객체가 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴 방문자 Visitor-각 클래스의 데이터 구조로 처리 기능을 분리하여 별도의 클래스로 구성 옵서버-한 객체의 상태가 변화하면 객체에 계승된 상태를 전달-이벤트를 생성해야 한다.terator-접속이 빈번한 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴메멘트 Memento-특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 되돌릴 수 있는 기능 제공-Ctrl+Z 명령어 Command-요청을 객체의 형태로 캡슐화하여 재사용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴-요청에 사용되는 각종 명령어를 추상 클래스와 구체 클래스로 분리하여 단순화 책임 연쇄 Chain of Responsibility-요청을 처리할 수 있는 객체가 2개 이상 존재하고,정의-SQL, 통신 프로토콜 중재자 Mediator-복잡한 상호작용을 캡슐화하여 객체 간의 의존성을 줄이고 결합도를 감소시킬 수 있는 상태 State-객체의 상태에 따라 동일한 동작을 다르게 처리할 때-객체 상태를 캡슐화하고 이를 참조하는 방식 전략 Strategy-동일 계열 알고리즘을 개별적으로 캡슐화하여 상호 교환할 수 있도록 정의-클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며 클라이언트에 영향 없이 상위 메소드 템플릿에서 골격을 정의하고 하위 등급으로 상세 처리를 구체화-유사한 서브클래스를 정리하여 공통적으로 정의한 내용을
연습 > 보기에서 다른 행위 패턴에 속하는 것을 찾아내는 템플릿 메서드 추상 팩토리 빌더 프로토타입 컴포지트 퍼서드 데코레이터 싱글톤 옵서버 메멘트 플라이웨이트 중재자 반복자 어댑터 브리지 프록시 팩토리 메서드 템플릿 메서드 방문자 반복자 컴포지트 데코레이터 프록시 싱글톤 빌더 책임 연쇄 추상 팩토리 상태 전략 인터레이터 빌더 커맨드 메멘트 퍼서드 중재자 Observer Comprite Factory
Q. 동일한 객체가 존재하는 경우 해당 객체를 공유하여 사용함으로써 메모리를 절약하고 존재하지 않는 경우에만 새롭게 객체를 생성하여 사용하도록 하는 디자인 패턴은?
Q. 자료 구조처럼 접근성이 많은 객체에 대해 동일한 인터페이스를 사용하도록 하는 디자인 패턴은?
Q. 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세서가 동시에 참조할 수 없는 디자인 패턴은?
Q.호환성이 없는 클래스의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 디자인 패턴은?
Q. 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후의 요청에 따라 객체를 그 시점의 상태로 되돌릴 수 있는 기능을 제공하는 디자인 패턴은?
Q. 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당하는 디자인 패턴은?