🔖 1장 요구사항 확인
소프트웨어 생명 주기
1. 폭포수 모형 (Waterfall Model)
✔️ 전통적, 고전적 생명 주기 모형
✔️ 이전 단계로 돌아갈 수 없음
✔️ 각 단계가 끝나야 다음 단계로 넘어갈 수 있는 선형 순차적 모형
✔️ 타당성 검토 ➡️ 계획 ➡️ 요구분석 ➡️ 설계 ➡️ 구현(코딩) ➡️ 시험(검사) ➡️ 유지보수
2. 프로토타입 모형 (Prototype Model)
✔️ 실제 개발될 SW에 대한 프로토타입을 만들어 최종 결과물을 예측하는 모형
✔️ SW의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점 보완
🔁 요구 수집 ➡️ 빠른 설계 ➡️ 프로토 타입 구축 ➡️ 고객 평가 ➡️ 프로토타입 조정 ➡️ 구현
3. 나선형 모형 (Spiral Model)
✔️ 보헴 제안
✔️ 폭포수 모형 ➕ 프로토타입 모형
✔️ 여러 번의 SW 개발 과정을 거쳐 점진적으로 완벽한 최종 SW 개발
✔️ 누락되거나 추가된 요구사항을 첨가할 수 있음
🔁 계획 수립 ➡️ 위험 분석 ➡️ 개발 및 검증 ➡️ 고객 평가
4. 애자일 모형 (Agile Model)
✔️ 고객 요구사항 변화에 유연하게 대응 가능
✔️ 일정한 주기 반복하는 모형
✔️ 짧은 개발 주기 반복, 반복되는 주기마다 만들어진 결과물에 대해 고객의 평가와 요구 적극 수용
✔️ 스크럼, XP, 기능 중심 개발
다이어그램
1. 구조적 다이어그램
📌 클래스 다이어그램
: 클래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현
📌 객체 다이어그램
: 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
- 럼바우 객체지향 분석 기법에서 객체 모델링에 활용
📌 컴포넌트, 배치, 복합체 구조, 패키지 다이어그램
2. 행위 다이어그램
📌 상태 다이어그램
: 럼바우 객체 지향 분석 기법에서 동적 모델링에 활용
📌 유스케이스, 시퀀스, 커뮤니케이션, 활동, 상호작용 개요, 타이밍 다이어그램
🔖 2장 화면 설계
품질 요구사항
1. ISO/IEC 9126
✔️ 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용됨
✔️ 소프트웨어의 품질에 대한 요구사항을 기술하거나 개발중인 또는 개발이 완료된 소프트웨어의 품질 평가 등에 사용됨
✔️ 2011년에 호환성과 보안성을 강화해 ISO/IEC 25010으로 개정됨
📌 기능성
: 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는가
✔️ 적절성/적합성 : 목적 달성을 위해 적절한 기능을 제공
✔️ 정밀성/정확성 : 사용자가 요구하는 결과를 정확하게 산출
✔️ 상호 운용성 : 다른 시스템과 서로 어울력 작업
✔️ 보안성 : 정보 접근을 권한에 따라 허용하거나 차단
✔️ 준수성 : 기능과 관련된 표준, 관례 및 규정을 준수
📌 신뢰성
: 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는가
✔️ 성숙성 : 결함으로 인한 고장을 피해갈 수 있는 능력
✔️ 고장 허용성 : 결함 또는 인터페이스 결여 시에도 규정된 성능 수준 유지
✔️ 회복성 : 고장시 규정된 성능 수준까지 회복하고 직접적으로 영향 받은 데이터를 복구
📌 사용성
: 사용자가 쉽게 배우고 사용할 수 있으며, 향후 다시 사용하고 싶은가
✔️ 이해성 : 소프트웨어를 사용자가 이해
✔️ 학습성 : 소프트웨어 애플리케이션 학습
✔️ 운용성 : 소프트웨어 운용 및 제어
✔️ 친밀성 : 소프트웨어 재사용
📌 효율성
: 사용자가 요구하는 기능을 할당된 시간동안 한정된 자원으로 얼마나 빨리 처리할 수 있는가
✔️ 시간 효율성 : 적절한 반응 시간 및 처리 시간, 처리율
✔️ 자원 효율성 : 적절한 자원의 양과 종류
📌 유지 보수성
: 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는가
✔️ 분석성 : 결함, 고장의 원인, 수정될 부분들을 식별
✔️ 변경성 : 결함 제거 또는 환경 변화로 인한 수정 등을 쉽게 구현
✔️ 안정성 : 변경으로 인한 예상치 못한 결과를 최소화
✔️ 시험성 : 소프트웨어의 변경 검증
📌 이식성
: 다른 환경에서도 얼마나 쉽게 적용할 수 있는가
✔️ 적용성 : 원래 목적으로 제공되는 것 외에 다른 환경으로 변경
✔️ 설치성 : 임의의 환경에 소프트웨어를 설치
✔️ 대체성 : 동일한 환경, 동일한 목적을 위해 다른 소프트웨어를 대신해서 사용
✔️ 공존성 : 자원을 공유하는 환경에서 다른 소프트웨어와 공존
2. ISO/IEC 25010
📌 기능 적합성
: 기능 완전성, 기능 정확성, 기능 적절성
📌 성능 효율성
: 시간 효율성, 자원 효율성, 사양
📌 호환성
: 공존성, 상호운영성
📌 사용성
: 적절 인지정도, 학습성, 조작성, 사용자 오류 방지, UI 미학, 접근성
📌 신뢰성
: 성숙성, 사용가능성, 결함 허용성, 복구성
📌 보안성
: 기밀성, 무결성, 부인방지, 책임추적성, 인증성
📌 유지 보수성
: 모듈성, 재사용성, 분석성, 변경성, 시험성
📌 이식성
: 적응성, 설치성, 대체성
3. 개발자 관점에서 본 소프트웨어 품질의 특성에 대한 표준
📌 ISO/IEC 12119
: ISO/IEC 9126을 준수한 품질 표준
- 테스트 절차를 포함해 규정함
📌 ISO/IEC 14598
: 소프트웨어 품질의 측정과 평가에 필요 절차를 규정한 표준
- 개발자/구매자/평가자 별로 수행해야 할 제품 평가 활동을 규정함
🔖 3장 애플리케이션 설계
아키텍처 패턴
1. 레이어 패턴
: 시스템을 계층(Layer)으로 구분해 구성하는 고전적 방법 중 하나
✔️ 각각의 서브시스템들이 계층 구조를 이룸
- 상위 계층 : 하위 계층에 대한 서비스 제공자가 됨
- 하위 계층 : 상위 계층의 클라이언트가 됨
✔️ 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
✔️ 변경 사항을 적용할 때도 서로 마주보는 두 개의 계층에만 영향을 미치므로 변경 작업이 용이함
✔️ 특정 계층만 교체해 시스템을 개선하는 것이 가능
ex) OSI 참조 모델 : 네트워크 프로토콜을 계층별로 구분한 모델
2. 클라이어트-서버 패턴
: 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
✔️ 사용자는 클라이언트와만 의사소통함
→ 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공함
✔️ 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지
✔️ 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적임
3. 파이프-필터 패턴
: 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화해 파이프를 통해 데이터를 전송하는 패턴
✔️ 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장에 용이함
✔️ 필터 컴포넌트들을 재배치해 다양한 파이프라인을 구축하는 것이 가능함
✔️ 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 자주 사용됨
✔️ 필터 간 데이터 이동시 데이터 변환으로 인한 오버헤드가 발생함
ex) UNIX의 쉘(Shell)
4. 모델-뷰-컨트롤러 패턴
: 서브시스템을 3개의 부분으로 구조화하는 패턴
✔️ 모델 : 서브시스템의 핵심 기능과 데이터 보관
✔️ 뷰 : 사용자에게 정보 표시
✔️ 컨트롤러: 사용자로부터 받은 입력 처리
✔️ 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업을 수행할 수 있음
✔️ 여러 개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합함
5. 기타 패턴
📌 마스터-슬레이브 패턴
: 마스터 컴포넌트는 동일한 구조의 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
✔️ 마스터 컴포넌트 : 모든 작업의 주체
✔️ 슬레이브 컴포넌트 : 마스터 컴포넌트의 지시에 따라 작업을 수행해 결과를 반환
✔️ 마스터와 슬레이브는 구조가 동일하므로 기능도 동일하게 수행함
✔️ 연산, 통신, 조정 기능은 슬레이브 제어를 위해 일반적으로 마스터가 수행함
✔️ 장애 허용 시스템과 병렬 스스템에서 주로 활용함
📌 브로커 패턴
: 사용자가 원하는 서비스와 특징을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해줌
✔️ 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합한 패턴
✔️ 분산 환경 시스템에서 주로 활용됨
📌 피어-투-피어 패턴
: 피어를 하나의 컴포넌트를 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될 수도 있는 패턴
✔️ 클라이어트와 서버는 전형적인 멀티스레딩 방식을 사용함
✔️ 멀티스레딩 방식: 프로세스를 두 개이상의 실행 단위로 구분해 자원을 공유하며 병렬로 수행하는 기능
📌 이벤트-버스 패턴
✔️ 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
✔️ 소스 (Source) : 이벤트 생성
✔️ 리스너 (Listener) : 이벤트 수행
✔️ 채널 (Channel) : 이벤트 통로
✔️ 버스 (Bus) : 채널 관리
📌 블랙보드 패턴
: 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태
✔️ 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음
✔️ 해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴
✔️ 음성 인식, 차량 식별, 신호 해석 등에 주로 활용됨
📌 인터프리터 패턴
✔️ 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 작도록 구성됨
✔️ 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용됨
모듈 결합도 & 응집도
1. 결합도
: 모듈 간에 상호 의존하는 정도
✔️ 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음
✔️ 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다.
✔️ 자료 < 스탬프 < 제어 < 외부 < 공통 < 내용
📌 자료 결합도 : 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
📌 스탬프(검인) 결합도 : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
2. 응집도
: 모듈이 독립적인 기능으로 정의도어 있는 정도
✔️ 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음
✔️ 기능적 > 순차적 > 교환적 > 절차적> 시간적 > 논리적 > 우연적
📌 기능적 : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우
📌 우연적 : 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우
디자인패턴
1. 생성 패턴
: 객체의 생성과 참조 과정을 캡슐화해 객체가 생성되거나 변경되어도 프로 그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더함
📌 추상 팩토리 : 서로 연관/의존하는 객체들의 그룹으로 생성해 추상적으로 표현
📌 빌더 : 작게 분리된 인스턴스 조합해 객체 생성
📌 팩토리 메소드 : 객체 생성을 서브 클래스에서 처리하도록 분리해 캡슐화
📌 프로토타입 : 원본 객체 복제
📌 싱글톤 : 하나의 객체 생성하면 참조는 할 수 있으나 동시에 참조 불가능
2. 구조 패턴
: 더 큰 구조로 만들 수 있게 해주는 패턴, 복잡한 시스템을 개발하기 쉽게 도와줌
📌 어댑터 : 다른 클래스가 이용할 수 있도록 변환
📌 브리지 : 서로 독립적으로 확장할 수 있도록 구성
📌 컴포지트 : 복합 객체와 단일 객체 구분 없이 다루고자 할 때 사용
📌 데코레이터 : 객체 간의 결합으로 기능 확장
📌 퍼싸드 : 간편하게 사용할 수 있도록 복잡한 서블 클래스 상위에 인터페이스를 구성
📌 플라이웨이트 : 가능한 한 공유해서 사용해 메모리 절약
📌 프록시 : 접근이 어려운 객체와 연결하려는 객체 사이에서 인터페이스 역할 수행
3. 행위 패턴
: 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배해 결합도를 최소화할 수 있도록 함
📌 책임 연쇄 : 요청을 처리할 수 있는 객체가 처리하지 못하면 다음 객체로 넘어감
📌 커맨드 : 요청에 필요한 정보를 저장하거나 로그 남김
📌 인터프리터 : 언어에 문법 표현을 정의
📌 반복자 : 접근이 잦은 객체에 대해 동일한 인터페이스 사용
📌 중재자 : 복잡한 상호작용을 캡슐화해 객체로 정의함
📌 메멘토 : 요청에 따라 객체를 해당 시점의 상태로 돌림
📌 옵서버 : 한 객체의 상태가 변화면 객체에 상속된 다른 객체들에게 변환된 상태를 전달
📌 상태 : 객체의 상태에 따라 동일한 동작을 다르게 처리
📌 전략 : 동일한 알고리즘을 개별적으로 캡슐화해 상호 교환할 수 있게 정의
📌 템플릿 메소드 : 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의
📌 방문자 : 처리 기능을 분리해 별도의 클래스로 구성
🔖 4장 인터페이스 설계
요구사항 검증 방법 - 요구사항 검토
: 결함 여부를 검토 담당자들이 수작업으로 분석
✔️ 동료 검토
: 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고
동료들이 이를 들으면서 결함을 발견하는 형태
✔️ 워크스루
: 컴토 회의 전 요구사항 메세서를 미리 배포해
사전 검토 후 짧은 검토 회의를 통해 결함을 반견하는 형태
✔️ 인스펙션 : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이
요구사항 명세서를 확인하면서 결함을 발견하는 형태
미들웨어
: 미들(Middle) + 소프트웨어 (Software)
✔️ 시스템 간의 데이터 교환에 일관성 보장
✔️ 위치 투명성 제공 : 시스템의 실제 위치를 알 필요 없이 시스템의 논리적 명칭만으로 액세스할 수 있음
📌 DB
: 원격의 데이터베이스와 연결하기 위한 미들웨어
📌 RPC (Remote Procedure Call)
: 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
📌 MOM (Message Oriented Middleware)
: 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
📌 TP-Monitor (Transaction Processing Monitor)
: 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어, 빠른 응답 속도 유지
📌 ORB (Object Request Broker)
: 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어
➡️ 코바(CORBA) : 분산 프로그램 객체를 생성, 배포, 관리하기 위한 규격을 의미
📌 WAS (Web Application Server)
: 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
