- 3 - 애플리케이션 설계
21. 디자인패턴
1) 디자인 패턴의 개요
각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할때 참조할 수 있는 전형적인 해결방식 또는 예제이다.
재사용할 수 있는 기본형 코드
개발과정 중 문제가 발생하면 문제에 해당하는 디자인 패턴을 참고
* 아키텍쳐 패턴과 디자인 패턴의 차이!
아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용됨
아키텍쳐 패턴이 전체 시스템의 구조를 설계하기 위한 참조 모델이라면, 디자인 패턴은 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델임
2) 생성 패턴
객채의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 받지 않도록 유연성을 더해주는 패턴이다.
종류
추상 팩토리 : 구체적인 클래스에 의존하지 않고 인터페이스를 통해 서로 연관, 의존하는 그룹으로 생성한다.
빌더 : 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성한다.
팩토리 메소드 : 객체의 생성을 서브 클래스에서 처리하도록 분리해 캡슐화한다.
프로토타입 : 원본 객체를 복제하는 방법으로 객체를 생성한다.
싱글톤 : 객체의 인스턴스를 전역화한다.
3) 구조 패턴
클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴이다.
종류
어댑터 : 호환성이 없는 클래스의 인터페이스를 다른 클래스가 이용할 수 있도록 한다.
브리지 : 구현 부에서 추상층을 분리해서 서로가 독립적으로 확장할 수 있도록 구성한다.
컴포지트 : 여러 객체를 가진 복합객체와 단일 객체를 구분 없이 다루고자 할 때 사용한다.
데코레이터 : 객체 간의 결합을 통해 능동적으로 기능을 확장하는 패턴이다.
퍼싸드 : 복잡한 서브 클래스들을 피해 상위에 인터페이스를 구성한다.
플라이웨이트 : 인스턴스를 가능한한 공유해서 사용해서 메모리를 절약한다
프록시 : 접근이 어려운 객체 사이에 인터페이스 역할을 한다.
4) 행위 패턴
클래스나 객체들이 서로 상호작용 하는 방법이나 책임 분배 방법을 정의하는 패턴이다.
종류
책임 연쇄 : 요청을 처리하는 객체가 둘 이상 존재해 한 객체가 처리하지 못하면 다음 객체로 넘어간다.
커맨드 : 요청을 객체의 형태로 캡슐화해서 이용, 취소할 수 있도록 정보를 저장한다
인터프리터 : 언어에 문법 표현을 정의한다
반복자 : 접근이 잦은 객체에 동일한 인터페이스를 사용한다
중재자 : 객체간의 복잡한 상호작용을 캡슐화하여 객체로 정의한다.
메멘토 : 특정 시점에서 객체 내부 상태를 개체화함으로 요청에 따라 특정 시점으로 객체의 상태를 되돌릴 수 있다.
옵저버 : 한 객체의 상태가 변화하면 객체에 상속된 다른 객체들에게 변화된 상태를 준다.
상태 : 객체의 상태에 따라 동작을 다르게 처리한다.
전략 : 동일 계열의 알고리즘을 개별적으로 캡슐화해서 상호 교환할 수 있게 한다.
템플릿 메소드 : 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부처리를 구체화한다.
방문자 : 데이터 구조에서 처리 기능을 분리해 별도의 클래스를 구성
* 패턴이 많죠..? 특성까지는 외우지 못하시더라도 행위, 구조, 생성 패턴에 어떤 패턴들이 있는지는 아셔야 합니다!
- 4 - 인터페이스 설계
22. 시스템 인터페이스 요구사항 분석
1) 시스템 인터페이스 요구사항 구성
시스템 인터페이스는 독립적으로 떨어져 있는 시스템들끼리 서로 연동하여 상호 작용하기 위한 접속 방법과 규칙이다.
- 시스템 인터페이스 요구사항 명세서에는 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려사항이 있다.
2) 시스템 인터페이스 요구사항 분석
요구사항 명세서에 요구사항을 기능적 요구사항과 비기능적 요구사항으로 분류하고 조직화하여 요구사항 명세를 구체화하고 이를 이해관계자에게 전달하는 과정이다.
기능적 요구사항 : 시스템이 무엇을 하는지? 어떤 기능을 하는지?
비기능적 요구사항 : 프로젝트 개발 과정에서 지켜야할 제약 사항
- 요구사항 분석은 소프트웨어 요구사항 분석 기법을 적절히 이용한다.
- 요구사항은 적절한 수준으로 세분화한다.
- 요구사항 분석 시 누락된 요구사항이나 제한조건을 추가한다.
- 요구사항에 대한 상대적 중요도를 평가하여 우선순위를 부여한다.
3) 시스템 인터페이스 요구사항 분석 절차
- 소프트웨어 요구사항 목록에서 시스템 인터페이스 관련 요구사항을 선별
- 별도로 시스템 인터페이스 요구사항 목록을 생성
- 시스템 인터페이스와 관련도니 요구사항 및 아키텍처 정의서, 현행 시스템의 연계 시스템 현황 자료 등 관련된 자료를 준비
- 요구사항 명세서를 확인해 기능적 요구사항과 비기능적 요구사항으로 분류
- 요구사항 명세서와 요구 사항 목록 및 관련 자료들을 비교해 요구사항을 분석하고 내용을 추가하거나 수정함.
- 명세서와 요구사항 목록을 이해관계자에게 전달
23. 인터페이스 요구사항 검증
1) 요구사항 검증
인터페이스의 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술 되었는지 검토하고, 개발 범위의 기준인 베이스라인을 설정하는 것이다.
순서
계획 수립 -> 검토 및 수정 -> 베이스 라인 설정 |
2) 인터페이스 요구사항 검토 계획 수립
프로젝트 이해관계자들이 프로젝트 품질 관리 계획을 참조해 수립한다.
검토계획이 수립되면 요구사항 검토 참여자들에게 자료와 일정을 전달한다.
3) 인터페이스 요구사항 검토 및 오류 수정
검토 체크리스트 항목에 따라 인터페이스 요구사항 명세서를 검토하는 것이다.
- 오류가 발견되면 오류 목록과 시정 조치서를 작성한다.
- 요구 수정과 승인 절차를 진행할 수 있도록 요구사항 검토 결과를 검토 관련자들에게 전달한다.
- 시정 조치서를 작성하고 시정 조치가 완료가되면 인터페이스 요구 사항 검토 작업을 완료한다.
4) 인터페이스 요구사항 베이스라인 설정
인터페이스 요구사항 검토 및 오류 수정이 끝나면 소프트웨어 설계 및 구현을 위해 요구사항 명세서의 베이스라인을 설정한다.
5) 요구사항 검증 방법
요구사항 검토 : 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 담당자들이 분석한다.
요구사항 검토의 상세 항목
- 동료검토 : 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 형태의 검토 방법이다.
- 워크스루 : 검토 회의 전에 사전 검토를 한 후에 짧은 검토 회의를 통해 결함을 발견하는 형태의 검토 방법이다.
- 인스펙션 : 작성자를 제외한 다른 검토 전문가들이 검토하는 방법이다.
프로토 타이핑 : 요구사항을 정확히 파악하기 위해 프로토타입을 제작한다
테스트 설계 : 요구사항은 테스트 할 수 있게 작성되어야 하며, 이를 위해 테스트 케이스를 생성한다.
케이스 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리, 표준 준수 여부를 확인한다.
* 요구사항 검토의 종류에 대해 확실하게 구별하셔야 합니다!
6) 인터페이스 요구 사항 검증의 주요 항목
- 완전성 : 요구사항이 누락되지 않고 완전히 반영 되었는지?
- 일관성 : 모순되거나 충돌하지 않고 일관되어있는지?
- 명확성 : 모든 참여자가 명확이 이해라 수 있는지?
- 기능성 : 요구사항에서 요구한 기능에 중점을 두고 있는지?
- 검증 가능성 : 요구사항을 모두 만족하고, 소프트웨어가 요구사항을 만족하는것을 검증할 수 있는지?
- 추적 가능성 : 명세서와 설계서를 추적할 수 있는지?
- 변경 용이성 : 요구사항 명세서의 변경이 쉬운지?
24. 인터페이스 방법 명세화
1) 인터페이스 방법 명세화의 개념
내외부 시스템이 연계하여 작동할 때 인터페이스 별 송수신 방법, 송수신 데이터, 오류식별 및 처리 방안에 대한 내용을 문서로 명확하게 정리하는 것이다.
명세화 하기 위해서는 시스템 연계 기술, 인터페이스 통신 유형, 처리 유형, 발생 주기에 대한 정보가 필요하다.
2) 시스템 연계 기술
DB Link : DB에서 제공하는 DB Link객체를 이용한다.
API/Open API : 송신 시스템의 데이터베이스에서 데이터를 읽어 제공하는 어플리케이션 프로그래밍 인터페이스다.
연계 솔루션 : EAI 서버와 송수신 시스템에 설치되는 클라이언트를 이용한다
Socket : 서버를 위한 소켓으로 통신하는 네트워크 기술이다.
Web Service : WSDL과, UDDI, SOAP 프로토콜을 이용한다.
3) 인터페이스 통신 유형
단방향 : 시스템에서 거래만 요청하고 응답이 없음
동기 : 시스템에서 거래를 요청하고 응답이 올 때까지 대기하는 방식
비동기 : 거래를 요청하고 다른작업을 수행하다 응답이 오면 처리하는 방식이다.
4) 인터페이스 처리 유형
실시간 방식 : 요청한 내용을 바로 처리해야할 때 사용하는 방식
지연 처리 방식 : 매건 단위로 처리할 경우 비용이 많이 발생할 때 사용하는 방식
배치 방식 : 대량의 데이터를 처리할 때 사용하는 방식
* "배치"라는 단어의 특징을 잘 알고 계셔야 합니다. 뒤로 갈수록 비슷한 의미가 많이 등장해요!
5) 인터페이스 발생 주기
업무의 성격과 송수신데이터 전송량을 고려하여 매일, 수시, 주 1회등으로 구분한다.
25. 미들웨어 솔루션 명세
1) 미들웨어의 개념 및 종류
운영체제와 해당 운영체제에서 실행되는 응용프로그램 사이에 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어다.
- 미들웨어는 표준화된 인터페이스를 제공함으로 시스템 간의 데이터 교환에 일관성을 보장한다.
2) DB
데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어다.
- DB를 사용하여 시스템을 구축할 경우 2-Tier 아키텍처라고 한다.
- 마이크로소프트의 ODBC, 볼랜드의 IDAPI, 오라클의 Glue가 있다.
3) RPC(Remote Procedure Call)
원격 프로시저 호출은 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어다.
- 이큐브시스템스의 Entera, OSF의 ONC/RPC가 있다.
* RPC는 프로시저만 기억!
4) MOM(Message-Oriented Middleware)
메시지 기반의 비동기형 메시지를 전달하는 방식이다.
- 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 윟 ㅐ많이 사용된다.
- IBM의 MQ, 오라클의 Message Q, JCP의 JMS가 있다.
* M으로 시작하니까 메시지죠!
5) TP-Monitor(Transaction Processing Monitor)
트랜잭션 모니터는 항공기나 철도 예약 업무와 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어다.
- 사용자 수가 증가해도 빠른 응답 속도를 유지하는 업무에 사용
- 오라클의 tuxedo, 티맥스소프트의 tmax가 있다.
* 항공기와 철도하면 TP모니터입니다!
6) ORB(Object Request Broker)
객체 요청 브로커는 객체 지향 미들웨어로 코바 표준 스펙(네트워크 분산 프로그램)을 구현한 미들웨어다.
- Micro Focus의 Orbix, OMG의 CORBA가 있다.
* 아키텍처 패턴에서도 브로커 패턴이 있었죠?
7) WAS
앱 애플리케이션 서버는 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하는 미들웨어다.
- HTTP 세션 처리를 위한 웹 서버 기능 뿐 아니라 미션-크리티컬한 기업 업무까지 JAVA, EJB 컴포넌트 기반으로 구현한다.
- 오라클의 WebLogic, IBM의 WebSphere가 있다.
8) 미들웨어 솔루션 식별
개발 및 운영환경에 사용될 미들웨어 솔루션을 확인하고 목록을 작성하는 것이다.
소프트웨어 아키텍처에서 정의한 아키텍처 구성 정보와 프로젝트에서 구매가 진행중이거나 구매 예정인 소프트웨어 내역을 확인해서 개발 및 운영환경에서 사용될 미들웨어 솔루션을 식별한다.
솔루션의 시스템, 구분, 솔루션명, 버전, 제조사의 정보를 정리한 미들웨어 솔루션 목록을 작성한다.
9) 미들웨어 솔루션 명세서 작성
미들웨어 솔루션 목록의 미들웨어 솔루션 별로 관련 정보를 상세하게 기술한다.
제품 명칭 및 버전, 사용 목적 등을 제품안내서 및 설명 자료등을 통해 검토한다.
제품에 대한 사용환경과 특징을 검토한다.
미들웨어 솔루션이 지원하는 시스템 범위와 정상적인 서비스 제공을 위한 환경 구성과 제공 기능에 대한 제약사항이 존재하는지 검토한다.
상세 정보, 제공 기능, 특징, 시스템 구성 환경에 대한 제약사항을 정리하여 명세서를 작성한다.
* 특징을 뽑아서 명세서 작성하라는 이야기입니다... 말 참 어렵게 하죠...
'2020 정보처리기사 필기 > 1과목 - 소프트웨어 설계' 카테고리의 다른 글
[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(애플리케이션 설계) (0) | 2020.05.26 |
---|---|
[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(화면설계_2) (0) | 2020.05.26 |
[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(화면설계) (0) | 2020.05.25 |
[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(요구사항확인_2) (0) | 2020.05.25 |
[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(요구사항 확인) (0) | 2020.03.10 |