소프트웨어 설계
요구사항 분석
- 소프트웨어 생명주기 (Software development life cycle)
- 시스템의 요구분석 부터 유지보수까지 모든 부분을 체계화한 절차.
- 단계별로 정리.
1. 요구사항 분석(명세화)
요구사항을 결정하는 단계, 실제 사용자와 함께 정의하는 단계
4. 테스트(시험)
화이트 박스
- 모듈의 코드를 오픈시킨 상태에서 원스코드의 논리적인 모든경로를 테스트 하는 방법
- 모든 문장을 한 번 이상 실행함.
- 기초경로검사(Base Path Testing), 제어 구조검사(Control Structure Testing)
- 문장검증기준, 분기검증기준, 조건검증기준, 분기/조건기준
블랙박스
- 블랙박스 테스트는 각 기능이 완전히 작동하는 것을 입증하는 테스트
- 인터페이스에 서 실시되는 테스트
애플리케이션 테스트 종류
- 단위테스트
- 사용자 요구사항을 테스트하는 단계
- 자료구조테스트, 실행결로테스트, 오류처리테스트
- 통합테스트
- 단위테스트를 통과한 모듈 사이의 인터페이스
- 상향식테스트, 하향식테스트
- 시스템테스트
- 통합된 단위 시스템이 정상적으로 작동하는지 테스트
- 기능-비기능 요구사항테스트
- 인수테스트
- 계약상의 요구사항이 만족되었는지 확인
- 알파-베타테스트
단.통.시.인 으로 외우자.
생명주기 모델 종류
- 폭포수 모델 ( Waterfall Model )
- 각 단계를 확실히 마무리 하고 넘어감.
- 고전적 생명주기 모형이라고 함.
- 요구사항 변경이 어렵다.
- 고전적 생명주기 모형이라고 함.
- 프로토타입 모델 ( Prototyping Model )
- 고객이 요구한 주요 기능을
프로토타입으로 구현.- 고객의 피드백을 반영하여 소프트웨어를 만들어감.
- 나선형 모델( Spiral Model)
- 위험을 최소화 할 때까지 점진적으로 완벽하게 진행하는 시스템
- 계획 및 정의 -> 위험분석 -> 개발 -> 고객평가.
- 반복적 모델
- 대상을 나누어 병렬적으로 개발 후 통합.
애자일 모형
고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행.
- 도구보단 개인과 상호작용
- 문서보단 실행되는 SW
- 계약협상보단 고객과의 협업
- 계획을 따르기 보다는 변화에 반응
스크럼
- XP(eXtreme Programming)
- 고객의 요구사항을 유연하게 대처하기 위해 고객의 참여와 개발과정을 반복적으로 수행.
- 의사소통, 용기, 존중, 피드백, 단순성
- 의용조피단
DBMS
- 사용자와 데이터베이스 사이에 존재하며 데이터베이스를 관리해주는 소프트웨어.
- 가용성, 성능, 기술지원, 상호호환성, 구축비용.
WAS (Web Application Server)
- 웹 어플리케이션 서버로 동적인 컨탠츠를 처리하는 미들웨어
- Tomcat, GlassFish, JBoss, Jetty, JEUS, webSphere
요구사항 유형
- 기능 요구사항
- 시스템이 제공하는 기능
- 기능성, 완전성, 일관성
- 비기능 요구사항
- 시스템장비 구성 요구사항 : 하드웨어, 소프트웨어 등 장비구성에 대한 요구사항.
- 성능 요구사항 : 처리속도 및 시간, 처리량 요구사항.
- 시스템이 수행하는 기능 이외의 사항, 제약사항에 관한 요구사항
- 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성
- 성능 요구사항 : 처리속도 및 시간, 처리량 요구사항.
기능-비기능은 시험에 자주 나오는거 같음
요구사항 개발 프로세스
- 요구사항 도출
- 요구사항을 식별하고 이해하는 과정
- 소프트웨어 생명주기를 반복
- 요구사항 분석
- 요구사항의 타당성을 조사. (비용, 일정)
- UML, 자료흐름도(DFD), 자료사전(DD) 등
- 자료사전
![자료사전]()
CASE (자동화 도구)
요구사항 분석을 위한 자동화 도구.
- SADT(Structured Analysis and Design Technique)
- SREM
- RSL
- REVS
- 요구사항 명세
| 정형 명세 기법 | 비정형 명세 기법 |
|---|---|
| 수학 | 상태/기능/객체 |
수학적 기호, 정형적 | 자연어 기반 서술 |
| 요구사항을 간결하게 표현 | 자연어때문에 요구사항결과가 작성자에따라 다를수 있음. |
- 요구사항 확인
HIPO
- 시스템 실행 과정인
입력처리와출력의 기능을 표현 - 하향식 소프트웨어 개발을 위한 문서.
- 가시적 도포 -> 총제적 도포 -> 세부적 도포.
UML(Unified Modeling Language)
- 시스템 개발자와 고객, 개발자와 개발자 간의 의사소통이 원할하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
관계
- 연관 관계
- 집합 관계
- 포함 관계
- 일반화 관계
- 의존 관계
- 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은시간에만 유지.
- 실제화 관계
다이어그램
- 구조적 다이어그램
- 정적모델링
- 클래스 다이어그램
- 객체 다이어그램
- 럼바우 객체지향 분석.
- 컴포넌트 다이어그램
- 배치 다이어그램
- 복합체 구조 다이어 그램
- 패키지 다이어그램.
- 럼바우 분석기법
- 객체 -> 동적 -> 기능
- 행위 다이어그램
- 동적모델링
- 유스케이스 다이어그램.
- 순차 다이어그램.
- 커뮤니케이션 다이어그램.
- 상태 다이어그램.
- 활동 다이어그램.
- 상호작용 다이어그램.
타이밍 다이어그램.
유스케이스 다이어그램 유스케이스란
사용자관점으로 시스템이 액터에게 제공하는 서비스로 사용자 요구를 분석하는 것으로기능 모델링작업에 사용.클래스 다이어그램 시스템 구성하는 클래스와 다른 클래스 사이의 관계를 표현.
- 순차(시퀀스) 다이어그램. 시스템이나 객체들이 메세지를 주고받으며
시간의 흐름에 따라 상호작용하는것을 그림으로 표현한 것.
UI
- CLI(command line interface)
- 명령과 출력이 텍스트 형태
- GUI(Graphical User Interface)
- 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행
- NUI(Natural user interface)
- 자연스럽게 사용자의 말이나 행동으로 기기를 조작.
- VUI(Voice user interface)
- 사람의 음성으로 기기를 조작
- OUI(Organic user interface)
- 모든 사물과 사용자간의 상호작용을 위한 인터페이스
직관성, 유효성(목적이 정확), 학습성, 유연성
객체지향 설계 원칙
- 단일 책임 원칙(SRP)
- 객체는 단 하나의 책임만 가져야함.
- 개방 폐쇄 원칙(OCP)
- 기존의 코드를 변경하지 않고, 기능을 추가.
- 리스코프 치환(LSP)
- 자식클래스는 최소한 자신의 부모 클래스에서 기능한 행위는 수행할 수있어야함.
- 인터페이스 분리(ISP)
- 자신이 사용하지 않는 인터페이스와 의존관계를 맺거나 영향을 받지 않아야한다.
- 의존 역전 원칙(DIP)
- 각 객체들 간의 의존관계가 성립될 때, 추상성이 낮은 클래스보다 높은 클래스에 의존관계를 맺어야함.
결합도
모듈간에 상호 의존하는 정도.
디자인패턴
생성패턴
- 추상팩토리
- 빌더
- 팩토리메소드
- 프로토타입
- 싱글톤
구조 패턴
- 어댑터
- 브리지
- 컴포지트
- 데코레이터
- 퍼싸드
- 플라이웨이트
- 프록시
행위 패턴
- 책임연쇄
- 커맨드
- 인터프리터
- 반복자
- 중재자
- 머멘토
- 옵서버
- 상태
- 전략
- 템플릿 메소드
- 방문자
요구사항 검증 방법
- 동료검토
- 요구사항 명세서 작성자가 명세서 내용을 직접설명하여 동료들이 이를 들으면서 결함을 발견.
- 워크스루
- 요구사항 명세서를 미리 배포하여 검토후, 짧은 검토 회의를 통해 결함을 발견
- 인스펙션
- 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함
- 프로토타이핑
- 프로토타입을 만들어 최종 결과물 예측
- 테스트 설계
- 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토
- CASE 도구
- 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석 관리.