소프트웨어 생명 주기 SDLC (Software Development Life Cycle)
소프트웨어가 만들어져서 사용되고, 유지·보수되다가 종료되기까지의 전체 과정
순서
1. 요구사항 분석
2. 설계
3. 구현
4. 테스트
1. 폭포수 모형(Watarfall Model)
고전적 생명 주기 모형
선형 순차적 모형 (한 단계가 끝나야만 다음 단계로 넘어감)
장점: 단계별 정의 및 산출물이 명확
단점: 개발 중간에 요구사항의 변경이 용이하지 않음
타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 테스트(검사) -> 유지보수
2. 프로토타입 모형(Prototype Model, 원형 모형)
견본품을 만들어 최종 결과물을 예측하는 모형
인터페이스에 중점을 두어 개발
장점: 개발 중간에 요구사항의 변경이 용이
3. 나선형 모형(Spiral Model, 점진적 모형)
폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
장점: 점진적 개발 과정 반복으로 요구사항 추가 가능 이때 추가적인 위험분석도 가능
정밀하고 유지보수 과정이 필요 없음
계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가
4. 애자일 모형(Agile Model, 민첩함 모형?)
일정한 주기(Iteration, Sprint)를 반복하면서 개발과정 진행
절차와 도구보다 고객과의 소통에 초점을 맞춤
기능중심 개발
장점: 변화에 유연하게 대응 가능
XP(eXtreme Programming), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal), 린(LEAN)
-> 방법론
* XP 기법
XP(eXtreme Programming)의 핵심 가치
용기(Courage)
단순성(Simplicity)
의사소통(Communication)
피드백(Feedback)
존중(Respect)
XP의 기본원리
- Whole Team (전체 팀)
- Small Release(소규모 릴리즈)
- Test-Driven Development (테스트 주도 개발)
- Contingous Intergration (계속적인 통합)
- Collective Ownership (공동 소유권)
- Pair Programming (짝 프로그래밍)
- Design Improvement (디자인 개선) 또는 Refactoring(리팩토링)
* 리팩토링(Refactoring): 소프트웨어의 겉보기 동작(기능)은 그대로 유지하면서 내부 코드 구조를 개선하는 작업
* Scrum 기법
짧고 자주 진행하는 팀 단위 협업 방식
스크럼의 원래 뜻은 럭비 용어로 여러 선수가 머리를 맞대고 공을 밀고 나가는 것이다
팀원들이 긴밀하게 협력하며 목표를 향해 나아가는 것
팀원 스스로가 스크럼 팀 구성
개발 작업에 관한 모든 것을 스스로 해결해야 함
스프린트는 2 ~ 4주 정도의 기간으로 진행
제품 책임자(PO; Product Owner)
- 요구사항이 담긴 백로그(BackLog)를 작성하는 주체
- 백로그에 대한 우선순위를 지정, 이해관계자들의 의견을 종합
스크럼 마스터(SM; Scrum Master)
- 일일 스크럼 회의 주관
- 팀원들을 통제하는 것이 목표가 아님
개발팀(DT; Development Team)
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
- 최대 인원 7 ~ 8명
스크럼 개발 프로세스
스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 -> 스크럼 검토 회의 -> 스프린트 회고
*sprint: 짧은 기간
소멸 차트(Burn-down Chart):
- 개발을 완료하기까지 남은 작업량을 보여줌
- 각 주기 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타냄
개발 기술 환경 파악
- 운영체제 (OS, Operation System)
iOS, Android도 운영체제
고려사항: 가용성, 성능, 기술 지원, 구축 비용, 주변 기기
- 미들웨어 (Middleware)
- 운영체제와 응용 프로그램 사이에서 통신과 기능 등을 제공하는 소프트웨어
- 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어 << 이게 줜나 함정인게 클라이언트와 서버 라고 하니까 운영체제와 응용 프로그램과 뭔가 대응이 되서 이상한 말로 느껴지는데
(클라이언트와 서버) << 보통 응용프로그램에서 하는 일
간의 통신을 담당하는 시스템 소프트웨어이다
- 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, pc 환경, 운영체제 환경 등에서 시스템 간의 표준화된 연결을 도와주는 소프트웨어
- 표준화된 인터페이스를 통하여 시스템 간의 데이터 교환에 있어 일관성을 제공
- 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어
- 미들웨어 솔루션은 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 확인할 필요가 없다
- 사용자가 미들웨어의 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있다면 보안의 위협이 될 수 있으므로 확인할 수 없도록 해야 함
- 사용자가 미들웨어의 내부 동작을 확인하기 위해서는 별도의 응용 소프트웨어가 사용되어야 함
- 데이터베이스 관리 시스템 (DBMS: Data Management System)
사용자와 데이터베이스 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어
데이터베이스(DB)의 구성, 접근 방법, 유지 관리에 대한 모든 책임을 짐
JDBC(Java Database Connectivity, 자바)
ODBC(Open Database Connectivity, 응용 프로그램)
Oracle, MySQL, SQLite, MongoDB, Redis 등
고려사항: 가용성, 성능, 기술 지원, 구축 비용, 상호 호환성
- 웹 어플리케이션 서버 (WAS, Web Application Server)
정적인 콘텐츠를 처리하는 웹 서버(Web Server)와 반대됨
동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어(= 소프트웨어), 웹 환경을 구현하기 위한
데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공
Tomcat, JEUS, WebLogic, JBoss, Jetty, Resin, WebSpare
고려 사항: 가용성, 성능, 기술 지원, 구축 비용
- 미션-크리티컬한 기업 업무도 JAVA, EJB 컴포넌트 기반으로 구현이 가능
오픈 소스(Open Source)
누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 무료로 사용할 수 있게 공개한 것
고려사항: 라이선스의 종류, 사용자 수, 기술의 지속 가능성
요구사항 정의
기능 요구사항
기능, 입력, 출력, 저장, 수행 등등
기능적 요구사항: 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항
비기능 요구사항
성능, 품질, 제약사항, 호환성, 보안 등등
비기능적 요구사항: 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 실제 수행에 보조적인 요구사항
요구사항 개발 프로세스
도출(Ellcitation)/추출 -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)/검증(Valification)
요구사항 분석 기법
- 요구사항 분류
- 개념 모델링(UML)
- 요구사항 할당
- 요구사항 협상
- 정형 분석
요구사항 확인 기법
- 요구사항 검토
- 프로토타이핑
- 모델 검증
- 인수 테스트 (알파 테스트, 베타 테스트)
*UML 다이어그램: 객체지향 시스템의 그림 표준 설계도
다이어그램: 구조를 도형으로 나타낸것?
UML(Unified Modeling Langauge)의 구성요소
- 4 사물 (구조, 행동, 그룹, 주해)
- 6 관계 (연관/의존, 집합/포함, 일반화/실체화)
- 13 다이어그램 (6개 구조 다이어그램, 7개 행위 다이어그램)
6 구조(정적) UML 다이어그램 (클래스, 객체, 컴포넌트, 배치, 복합구조, 패키지) (클객컴배복패)
시스템이 무엇으로 이루어져 있는가?
7 행위(동적) UML 다이어그램(유스케이스, 시퀀스, 커뮤니케이션, 스테이트, 액티비티 상호작용 개요, 타이밍)
(유시커스액타)
시스템이 어떻게 동작하는가?
클래스, 유스케이스, 시퀀스에 대해 자세히 알아야 함
유스케이스 다이어그램: 사용자 측면에서 본 시스템 기능
유스케이스 다이어그램의 구성요소: 시스템 범위, 액터, 유스케이스, 관계
유스케이스 다이어그램 관계 종류: 연관, 포함, 확장, 일반화
사물(Things)
- 구조
- 행동
- 그룹
- 주해(주석?)
관계(Relationships)
- 연관: 지속적인 관계
- 집합: 전체-부분 관계자만 독립
- 포함: 전체 사라지면 부분도 사라짐
- 일반화: 상속 관계
- 의존: 파라미터로 쓰는거?
- 실체화: 인터페이스 구현
구조적, 정적 다이어그램(Diagram): 시스템 내부에서의 구조
- 클래스(class): 시스템을 구성하는 클래스들의 구조와 관계를 표현
- 객체(object): 독립된 객체 정보를 표현
- 컴포넌트(component): 컴포넌트 끼리의 구조 관계 표현
- 배치(deployment): 결과물, 프로세스, 컴포넌트 등 시스템의 물리적 요소들의 구조를 표현
- 복합체 구조(composite structure): 파트, 인터페이스, 협업 등 클래스의 내부 구조를 표현
- 패키지(package): 패키지간의 그룹화를 표현
(클컴객 복배패)
행위, 동적 다이어그램(Diagram): 시스템 내부에서의 동작
- 유스케이스(Use Case, 사용 사례): 사용자의 관점에서 표현
- 시퀀스 (Sequence, 순차): 객체 간에 주고받는 메시지를 시간 순서에 따라 회귀 메시지, 제어 블록 등으로 표현
- 커뮤니케이션 (Communication, 협업): 객체 간에 주고받는 메시지와 더불어 객체들 사이의 연관 관계를 함께 표현
- 상태 (State): 객체는 특정 상태를 지니며 이 상태는 이벤트(event)와 같은 액션에 의하여 변경되는데 이런 변화를 표현, 하나의 객체만 표현
객체 전이의 요소가 되는 요인: event
- 활동 (Activity): 전체 흐름을 객체의 처리 로직이나 조건에 따라 처리의 흐름을 순서에 따라 표현, 수행을 표현
- 상호작용 개요 (Interaction Overview): 활동 + 시퀀스
- 타이밍 (Timing): 객체 상태의 변화와 시간 제약을 명시적으로 표현
(유시커활 상상타)
유스케이스(Use Case)의 구성 요소 간의 관계
유스케이스(Use Case): 사용자가 시스템으로 무엇을 할 수 있나? 액터가 시스템과 상호작용하여 얻는 의미있는 기능 단위
- 연관 관계(Association): 유스케이스와 액터 간의 상호작용이 있음을 표현
- 포함 관계(Include): 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
- 확장 관계(Extend): 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계
- 일반화 관계(Generalization): 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계
유스케이스 다이어그램에서 엑터(Actor): 시스템과 상호작용하는 외부 존재
실제 사람이 아니라 역할 개념
사용자 인터페이스 (UI, User Interface)
1. UI의 구분
- CLI(Command Line Interface): 텍스트 형태로 이뤄진 인터페이스
- GUI(Graphical User Interface): 마우스로 선택해 작업을 하는 그래픽 환경의 인터페이스
- NUI(Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
- VUI(Voice User Interface): 사람의 음성으로 기기를 조작하는 인터페이스
- OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용을 위한 인터페이스
2. UI의 기본 원칙
직관성: 누구나 쉽게 이해하고 사용할 수 있어야 함
유효성: 사용자의 목적을 정확하고 완벽하게 달성해야 함
학습성: 누구나 쉽게 배우고 익힐 수 있어야 함
유연성: 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 함
// 사용자 중심: 사용자가 이해하기 쉽고 편하게 사용할 수 있는 환경을 제공해 실 사용자에 대한 이해가 바탕이 되어야 함
일관성: 버튼이나 조작 방법을 사용자가 기억하기 빠르고 쉽게 습득할 수 있도록 설계해야 함
단순성: 조작 방법은 가장 간단하게 작동되도록 하여 인지적 부담을 최소화 해야 함
결과 예측 가능: 작동시킬 기능만 보고도 결과 예측이 가능해야 함
가시성: 주요 기능을 메인 화면에 노츌하여 쉬운 조작이 가능해야 함
표준화: 디자인을 표준화하여 기능 구조의 선행 학습 이후 쉽게 사용 가능해야 함
접근성: 사용자의 직무, 연령, 성별 등이 고려된 다양한 계층을 수용해야 함
명확성: 사용자가 개념적으로 쉽게 인지해야 함
오류 발생 해결: 사용자가 오류에 대한 상황을 정확하게 인지할 수 있어야 함
3. 웹의 3요소
- 웹 표준(Web Standards)
- 웹 접근성(Web Accessibility)
- 웹 호환성(Cross Browsing)
4. UI 설계 도구
와이어프레임(Wireframe): 레이아웃을 협의하거나 공유하기 위해 사용
스토리보드(Story Board): 최종적으로 참고하는 작업 지침서, 작업 산출물(디스크립션)
프로토타입(Prototype): 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 모형
목업(Mockup): 실제 화면과 유사한 정적인 모형
유스케이스(Use Case): 사용자 측면 요구사항을 다이어그램 형식으로 묘사 (유스케이스 명세서)
5. UI 프로토타입
장점: 사용자를 설득하고 이해시키기 쉬움, 개발 시간을 줄일 수 있음, 사전 오류 발견 가능
단점: 반복적인 개선 및 보완 작업으로 인한 작업 시간 증가 및 자원 소모, 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성
6. UI 시나리오 문서 요건
- 이해성(Understandable): 누구나 쉽게 이해할 수 있도록 설명
- 완전성(Complete): 최대한 상세하게 기술
- 일관성(Consistent): 일관성 유지
- 가독성(Readable): 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함
- 수정 용이성(Modifiable): 수정 및 개선이 쉬워야 함
- 추적 용이성(Traceable): 변경사항에 대해서 쉽게 추적할 수 있어야 함
7. 기타
HCI(Human Computer Interaction or Interface): 사람과 컴퓨터의 상호작용을 연구해서 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문
UX(User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험
주관성(Subjectivity), 정황성(Contextuality), 총체성(Holistic)
감성공학: 1류: 인간의 감성, 2류: 심리적 기능, 3류: 공학적 및 수학적 모델, 객관적
품질 요구사항
1. 국재 제품 품질 표준
- ISO/IEC 9126
- ISO/IEC 12119: 패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준
- ISO/IEC 14598
- ISO/IEC 25000: SW 품질 평가 통합 모델, SQuaRE로도 불리며 위 3개를 통합
품질 관리: 2500n, 품질 모델: 2501n, 품질 측정: 2502n, 품질 요구: 2503n, 품질 평가: 2504n
(관모측요평)
2. ISO/IEC 9126
기능성(Functionality): 요구사항을 정확하게 만족하는 기능을 제공하는가?
#적절성, 정확성, 상호 운용성, 보안성, 호환성
신뢰성(Reliability): 요구된 기능을 정확하고 일관되게 오류 없이 수행하는가?
#성숙성, 결함 허용성, 회복성
사용성(Usability): 사용자가 정확하게 이해하고 사용하는가?
#이해성, 학습성, 운용성, 친밀성
효율성(Efficiency): 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리하는가?
#시간 효율성, 자원 효율성
유지 보수성(Maintainability): 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는가?
#분석성, 변경성, 안정성, 시험성
- 이식성(Protability): 소프트웨어를 다른 환경에서도 쉽게 적용할 수 있는가?
#적용성, 설치성, 대체성, 공존성
(기신사 효유이)
3. ISO/IEC 14598
- 반복성(Repeatability)
- 재현성(Reprodibility)
- 공정성(Impartiality)
- 객관성(Objectivity)
4. 국제 프로세스 품질 표준
- ISO/IEC 9001
- ISO/IEC 12207: 기본 프로세스, 조직 프로세스, 지원 프로세스 (기조지)
- ISO/IEC 15504(SPICE): 불완전 -> 수행 -> 관리 -> 확립 -> 예측 -> 최적화
- CMMI(Capability Maturity Model Integration): 조직 차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를평가하는 연속적 표현이 있음
소프트웨어 아키텍쳐
- 사용자의 비기능적 요구사항으로 나타난 제약 반영
- 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
설계과정
1. 설계 목표 설정
2. 시스템 타입 결정
3. 아키텍처 패턴 적용(스타일 적용 및 커스터마이즈)
4. 서브시스템 구체화(서브시스템의 기능, 인터페이스 동작 작성)
5. 검토(아키텍쳐 설계 검토)
(설타커서검)
1. 모듈화
- 시스템 기능들을 모듈 단위로 나눠 소프트웨어의 성능 및 재사용성을 향상시키는 것
- 모듈의 크기 커지면: 모듈 개수 적음, 모듈 간 통합 비용 적음, 모듈 하나의 개발 비용이 큼
- 모듈의 크기 작아지면: 모듈 개수 많음, 모듈 간 통합 비용 큼
2. 추상화
- 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시키는 것
- 과정 추상화: 자세한 수행 과정을 정의하지 않고 전반적인 흐름만 파악
- 데이터 추상화: 데이터의 세부적인 속성이나 용도를 정의하지 않고 데이터 구조를 대표하는 표현으로 대체
- 제어 추상화: 이벤트 발생의 정확한 절차나 방법을 정의하지 않고 대표하는 표현으로 대체
3. 단계적 분해
Niklaus Wirth에 의해 제안된 하향식 설계 전략
추상화의 반복에 의해 세분화
소프트웨어 기능에서부터 시작해 절차적으로 구체화
상세한 내역은 가능한 뒤로 미루어 진행
4. 정보 은닉
한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
정보 은닉을 통한 독립적 모듈 수행 가능
모듈 변경 시 영향을 받지 않아 수정, 시험, 유지보수 용이
객체 지향(Object-Oriented)
1. 객체(Object)
독립적으로 식별 가능한 이름을 갖고 있음
객체가 가질 수 있는 조건인 상태(State)는 일반적으로 시간에 따라 변함
객체와 객체는 상호 연관성에 의한 관계가 형성됨
객체가 반응할 수 있는 메시지의 집합을 행위(연산,method)라고 하며, 객체는 행위의 특징을 나타냄
객체는 일정한 기억장소를 갖고 있음
2. 클래스(Class)
하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
공통된 속성과 연산(행위)를 갖는 객체의 집합
객체지향 프로그램에서 데이터를 추상화하는 단위
각각의 객체들이 갖는 속성과 연산(Method)을 정의하고 있는 틀
슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스
서브 클래스(Sub Class)는 특정 클래스의 하위(자식) 클래스
3. 인스턴스(Instance)
- 클래스에 속한 각각의 객체
- 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)라고 함
4. 메서드(Method)
클래스로부터 생성된 객체를 사용하는 방법
전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산
5. 메시지(Message)
객체에게 어떤 행위를 하도록 지시하기 위한 방법
6. 캡슐화(encapsulation)
데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것
인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부 접근이 제한됨
정보 은닉 측면과 가장 밀접한 관계가 있음
외부 모듈의 변경으로 인한 파급 효과가 적음
재사용 용이, 인터페이스 단순해짐
결합도 Down / 응집도 Up
7. 상속(Inheritance)
이미 정의된 상위(부모) 클래스의 모든 속성과 연산을 하위(자식) 클래스가 물려받는 것
소프트웨어의 재사용(Reuse)을 높이는 중요한 개념
8. 다중 상속(Multiple Inheritance)
한 개의 클래스가 두 개 이상의 상위(부모) 클래스로부터 속성과 연산을 상속 받는 것
9. 다형성(Polymorphism)
하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력
하나의 객체나 메서드가 여러 가지 형태를 가질 수 있는 성질
ex) + 연산자의 경우 숫자 클래스에서는 덧셈, 문자 클래스에서는 문자열의 연결 가능
하나의 인터페이스나 이름으로 다양한 타입의 객체를 다루거나 동일한 함수/메서드가 객체에 따라 다르게 동작하는 특징
* 오버로딩(over loading): 같은 이름의 메소드를 중복하여 정의하는 것
* 오버라이딩(overriding): 슈퍼 클래스의 메소드를 서브 클래스에서도 동일한 메소드를 재정의하는 것
결합도(Coupling)
모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
1. 내용 결합도(Content Coupling)
한 모듈이 다른 모듈의 내부 기능 및 내부 자료를 직접 참조하거나 수정할 때의 결합도
2. 공통 결합도(Common Coupling)
공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도 (전역 변수)
3. 외부 결합도(External Coupling)
어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도 (전역 변수)
4. 제어 결합도(Control Coupling)
어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도 / 권리 전도 현상
5. 스탬프 결합도(Stamp Coupling)
모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달 될 때의 결합도
6. 자료 결합도(Data Coupling)
어떤 모듈이 다른 모듈을 호출하면서 매개 변수(피라미터)나 인수로 데이터를 넘겨주고 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 결합도
(내 공 외 제 스 자)
응집도(Cohesion)
모듈의 내부 요소들의 서로 관련 되어 있는 정도
1. 우연적 응집도(Coincidental Cohesion)
모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
2. 논리적 응집도(Logical Cohesion)
유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
3. 시간적 응집도(Temoral Cohesion)
특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
4. 절차적 응집도(Procedural Cohesion)
모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
5. 통신적 응집도(Communication Cohesion)
동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
6. 순차적 응집도(Sequential Cohesion)
모듈 내 하나의 활동으로부터 나온 출력 데이터(출력값)를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
7. 기능적 응집도(Functional Cohesion)
모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
(우 논 시 절 통 순 기)
코드
식별, 분류, 배열, 간소화, 표준화, 연상, 암호화, 오류 검출 기능
1. 순차 코드(일련번호 코드)
- 일정 기준에 따라서 최초의 자료부터 차례로 일련 번호를 부여
2. 블록 코드(구분 코드)
- 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호 부여
3. 10진 코드(도서 분류식 코드)
- 0~9까지 10진 분할하고 다시 각각에 대새허 10진 분할하는 방법을 필요한만큼
4. 그룹 분류 코드
- 대분류, 중분류, 소분류 등으로 구분하여 각 그룹 안에서 일련번호를 부여
5. 연상 코드(기호 코드)
- 관계있는 숫자나 문자, 기호를 이용하여 코드 부여
6. 표의 숫자 코드(유효 숫자 코드)
- 물리적 수치 그대로 코드에 적용
7. 합성 코드
- 2개 이상의 코드를 조합
8. 코드 부여 체계
- 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
- 유일한 코드를 부여하여 식별 및 추출을 용이하게 함
디자인 패턴 (GoF)
서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델
- 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴
- 재사용 가능, 설계아이디어 틀
아키텍쳐 패턴은 전체 시스템의 구조를 설계하기 위한 참조 모델
- 아키텍쳐 패턴이 다지인 패턴보다 상위 수준의 설계에 사용됨
1. 생성 패턴(Creational Pattern)
객체를 생성하는 것에 대한 패턴
- 추상 팩토리(Abstract Factory): 관련된 객체들의 집합을 생성하는 인터페이스를 제공하며 구체적인 팩토리 클래스를 통해 객체 생성을 추상화하는 패턴
- 빌더(Builder): 복잡한 객체의 생성 과정을 단순화하고 객체를 단계적으로 생성하며 구성하는 패턴
- 팩토리 메소드(Factory Method): 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정하도록 하는 것(Virtual-Constructor 패턴)
- 프로토타입(Prototype): 원본 객체를 복제하는 방법
- 싱글톤(Singleton): 하나의 클래스 인스턴스를 전역에서 접근 가능하게 하면서 해당 인스턴스가 한 번만 생성되도록 보장하는 패턴
(빌패추 싱프)
2. 구조 패턴(Structural Pattern) : 구조를 통해 확장성을 꾀하는 패턴
- 어댑터(Adapter): 호환성이 없는 클래스 인터페이스를 이용할 수 있도록 변환해주는 패턴
- 브리지(Bridge): 구현부에서 추상층을 분리하여 독립적으로 확장 및 다양성을 가지는 패턴
- 컴포지트(Composite): 여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 떄 사용하는 패턴
- 데코레이터(Decorator): 상속을 사용하지 않고도 객체의 기능을 동적으로 확장해주는 패턴
- 퍼싸드(Facade): 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 플라이웨이트(Flyweight): 공유해서 사용함으로써 메모리를 절약하는 패턴
- 프록시(Proxy): 다른 객체에 대한 대리자(Proxy)를 제공하여 접근 제어, 지연 로딩 등을 구현하는 패턴
(어브컴데 퍼플프)
3. 행위 패턴(Behavioral Pattern) : 행위의 변경, 수정 등을 위한 패턴
- 책임 연쇄(Chain of Responsibility): 한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴
- 커맨드(Command): 요청에 사용되는 각종 명령어들을 추상, 구체 클래스로 분리하는 패턴
- 인터프리터(Interpreter): 언어나 문법에 대한 해석기를 제공하여 주어진 언어로 표현된 문제를 해결하는 패턴
- 반복자(Iterator): 동일한 인터페이스를 사용하도록 하는 패턴
- 중재자(Mediator): 서로의 존재를 모르는 상태에서도 협력할 수 있게 하는 패턴
- 메멘토(Memento): 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
- 옵저버(Observer): 객체 간의 일 대 다 종속 관계를 정의하여 한 객체의 상태 변경이 다른 객체들에게 알려지도록 하는 패턴
- 상태(State): 객체의 상태를 캡슐화하고 상태 전환을 관리하는 패턴
- 전략(Strategy): 클라이언트에 영향을 받지 않는 독립적인 알고리즘을 실행 중에 선택하는 패턴
- 탬플릿 메소드(Templete Method): 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에 정의하는 패턴
- 방문자(Visitor): 객체 구조를 순회하면서 다양한 연산을 수행하는 패턴
(책커인 반중메옵 탬방상전)
인터페이스 요구사항 검증
1. 요구사항 검증(Requirements Verification)
- 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지 검토하는 것
- 인터페이스 요구사항 검토 계획 수립 -> 검토 및 오류 수정 -> 베이스라인 설정
2. 요구사항 검증 방법
- 동료 검토(Peer Review)
요구사항 명세서 작성자가 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 검토 방법
- 워크 스루(Walk Through)
검토회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토 회의를 통해 결함을 발견하는 검토 방법
- 인스펙션(Inspection)
요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함을 발견하는 검토 방법
3. 인터페이스 요구사항 검증 주요 항목
- 기능성(Functionality)
- 완전성(Completenesss)
- 일관성(Consistency)
- 명확성(Unambiguity)
- 검증 가능성(Verifability)
- 추적 가능성(Traceability)
- 변경 용이성(Easily Changeable)
인터페이스 방법 명세화
1. 시스템 연계 기술
직접 연계 방식
DB링크(DB link): 수신 시스템에서 DB Link를 생성하고 송신 시스템에서 해당 DB 링크를 직접 참조하는 방식
DB 연결(DB conection): 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀(DB Connection Pool)을 생성하고 연계 프로그램에서해당 DB 커넥션 풀명을 이용
ex) 송신 시스템의 Data Source = DB
API/Open API: 송신 시스템의 DB에서 데이터를 읽어와 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램
#open API는 이런 기능을 누구나 무료로 사용할 수 있도록 공개된 API
JDBC: 수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 DB와 연결
하이퍼 링크(Hyper Link): 웹 애플리케이션에서 하이퍼링크 이용
연계 솔루션: EAI 서버와 송/수신 시스템에 설치되는 클라이언트를 이용하는 방식
간접 연계 방식
소켓(Socket): 서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트의 통신 요청 시 클라이언트와 연결하는 네트워크 기술
웹 서비스(Web Service): 웹 서비스에서 WSDL, UDDI, SOAP 프로토콜을 이용해 연계하는 서비스
WSDL(Web Services Description Langauge)
웹 서비스와 관련된 서식이나 프로토콜 등을 표준적인 방법을 기술하고 게시하기 위한 언어
UDDI(Universal Description Discovery and Integration)
인터넷에서 전 세계의 비즈니스 업체 목록에 자신의 목록을 등록하기 위한 확장성 생성 언어(XML)기반의 규격
SOAP(Simple Object Access Protocol)
웹 서비스를 실제로 이용하기 위한 객체 간의 통신 규약
ESB(Enterprise Service Bus)
개방형 표준인 웹 서비스를 이용하며 메시징과 웹 서비스, 데이터 변형, 인텔리전트 라우팅을 결합하여 다양한 애플리케이션 간의 연결과 상호작용을 지원하는 표준기반의 미들웨어 플랫폼
2. 인터페이스 통신 유형
단방향: 시스템에서 거래 요청만 하고 응답은 없는 방식
동기(Sync): 시스템에서 거래 요청 후 응답이 올 때까지 대기(Request-Reply)하는 방식
ex) 은행 업무: 송금 버튼을 누르면 그 즉시 버튼에 대한 응답으로 돈이 송금됨
비동기(Async): 시스템에서 거래 요청 후 다른 작업을 수행하다 응답이 오면 처리하는 방식
ex) 채점하는 교수님: 시험지를 받고 채점하는 건 다음 날 해도 문제 없음
#동기, 비동기는 양방향
3. 인터페이스 처리 유형
실시간 방식: 사용자가 요청한 내용을 바로 처리해야 할 때 사용하는 방식
지연 처리 방식: 매 건 단위 처리로 비용이 많이 발생할 때 사용하는 방식
배치 방식:대량의 데이터를 처리할 때 사용하는 방식
4. 인터페이스 발생 주기
매일, 수시, 주 1회 등
미들웨어 솔루션 명세
운영체제 - 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
1. DB(Database)
2. RPC(Remote Procedure Call, 원격 프로시저 호출)
3. MOM (Message Oriented Middleware, 메시지 지향 미들웨어)
4. TP-Monitor(Transaction Processing Monitor, 트랜잭션 처리 모니터)
5. Legacyware(레거시웨어)
6. ORB(Object Request Broker, 객체 요청 브로커)
7. WAS(Web Application Server, 앱 애플리케이션 서버)
정보공학 방법론에서 데이터베이스 설계의 표현으로 사용하지 않는 모델: Entity-Relationship Diagram
1과목 추가 정리
1. 자료 흐름도(DFD: Data Flow Diagram)
#PTSD: Process, Terminator, Data Store, Data Flow
- 자료 흐름은 처리를 거쳐 변환될 때마다 새로운 이름을 부여한다
- 어떤 처리가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 한다
- 상위 단계의 처리(Process)와 하위 자료흐름도의 자료 흐름은 서로 일치되어야 한다
- 자료 저장소가 마지막 도착지 일 수 있다
2. UML 확장 모델의 스테레오 타입 객체 표현 기호
#<< >>
3. 자료 사전 기호
= : 자료의 정의: ~로 구성되어 있다(is composed of)
+: 자료의 연결: 그리고 (and)
(): 자료의 생략: 생략 가능한 자료 (Optional)
[|]: 자료의 선택: 자료 선택 (oru)
{}: 자료의 반복: 자료 반복 (Iteration of)
**: 자료의 설명: 주석 (Comment)
4. 부분-전체(part-whole) 관계 또는 부분(is-a-part-of)의 관계로 설명되는 연관성을 나타내는 용어는? = 집단화
일반화(Generalization)
객체들에 있어 공통적인 성질들을 상위 객체로 정의하고, 특수화(Specialization)된 객체들을 하위의 부분형(subtype) 객체로 정의하는 추상화 방법
추상화(Abstraction)
객체의 가장 중요한 것에만 중점을 두어 간략화 시킨 것
캡슐화(Encapsulation)
자료와 행위를 하나로 묶고 실제 구현 내용을 외부에 감추는 것 캡슐화된 객체의 행위는 외부에서 볼 때는 실제가 아닌 추상적인 것이 되므로 정보 은닉(information hiding) 개념이 지켜짐
정보 은닉: 객체가 캡슐화를 통하여 내부의 데이터나 오퍼레이션의 구현 내용을 감추는 것, 외부에서 무분별한 접근을 허용하지 않는 것
집단화(Aggregation)
서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만드는 것
여러 개의 속성을 묶어 사용자 정의형의 엔티티를 만드는 수단
복합 객체의 종속 성분을 모델링하기 위해 사용되며 복합 성분 클래스 과계를 통해 복합 속성 계층(Composite attribute hierachy)을 형성
*객체지향 기법에서 동일한 형의 특성을 갖는 객체들을 모아 구성한 것으로 클래스들 사이의 'is instance of' 관계로 설명되는 연관성을 나타내는 것은? = 분류화
5. HIPO(Hiearchy Input Process Output)
- 하향식 소프트웨어 개발을 위한 문서화 도구
- HIPO 차트 종류: 가시적 도표, 총체적 도표, 세부적 도표
- 기능과자료의 의존 관계를 동시에 표현할 수 있음
- 보기 쉽고 이해하기 쉬움
6. 객체지향 분석 방법론
현실세계의 문제를 '객체' 중심으로 분석해서 소프트웨어 요구사항을 정리하는 방법
Coad와 Yourdon 방법
- ER다이어그램을 사용하여 객체의 행위를 모델링하며 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성
Booch 방법
- 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법
Jacobson 방법
- 유스케이스(Use Case, 사용 사례)를 강조하여 사용하는 분석 방법
Wirfs-Brocks 방법
- 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 방법
Rumbaugh(럼바우) 방법 / 객체 모델링 기법(Object Modeling Technique)
- 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법
- 객체 모델링(Object) -> 동적 모델링(Dynamic) -> 기능 모델링(Function) 순으로
7. UML의 시퀀스 다이어그램의 구성 항목
- 생명선(Life Line)
- 실행(Activation, 활성 박스)
- 메시지(Message)
8. 객체지향 설계 원칙
SPR, 단일 책임원칙(Single Responsibility Principle): 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 함
OCP, 개방-폐쇄 원칙(Open-Closed Principle): 기존의 코드를 변경하지 않고(Closed), 기능을 수정하거나 추가할 수 있도록(Open) 설계 해야 함
LSP, 리스코프 치환 원칙(Liskov Substitution on Principle): 서브타입(하위 클래스, 자식 클래스)은 어디에서나 자신의 기반타입(상위 클래스, 부모 클래스)으로 교체할 수 있어야 함
ISP, 인터페이스 분리 원칙 (Interface Segregation Principle): 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 함 -> 자신이 사용하지 않는 기능(인터페이스)에는 영향을 받지 않아야 함
DIP, 의존역전 원칙(Dependency Inversion Principle): 의존 관계를 맺을 때 변화하기 쉬운 것보단 변화하기 어려운 것에 의존해야 한다는 원칙
9. 디자인 패턴 구성요소
패턴의 이름과 구분: 패턴을 부를 때 사용하는 이름과 패턴의 유형
문제 및 배경: 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미
솔루션: 패턴을 이루는 요소들, 관계, 협동(Collaboration) 과정
사례: 간단한 적용 사례
결과: 패턴을 사용하면 얻게 되는 이점이나 영향
샘플코드: 패턴이 적용된 원시 코드 (Source Code)
10. DBC(Designed by Contract, 계약에 의한 설계)
- 프로그램의 모듈들의 책임을 문서화하는데 초점을 맞춤
- 각각의 모듈이 가져야하는 기능만큼만 동작하도록 함
- 위의 개념들을 문서화하고 검증하는 것이 핵심
11. CASE(Computer-Aided Software Engineering) 도구
- 소프트웨어 개발 과정의 일부 또는 전체를 자동화하기 위한 도구
- 표준화된 개발 환경 구축 및 문서 자동화 기능 제공
- 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션 증대
주요기능: S/W 라이프 사이클 전 단계의 연결, 그래픽 지원, 다양한 소프트웨어 개발 모형 지원
CASE의 원천 기술
- 구조적 기법
- 프로토타이핑 기술
- 자동 프로그래밍 기술
- 정보 저장소 기술
- 분산처리 기술
* EAI(Enterprise Application Integration): 기업 응용 프로그램 통합으로 기업용 응용 프로그램의 구조적 통합 방안을 가리킴
* FEP(Front-End Processor): 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 차지하는 시간을 줄여주는 프로그램이나 하드웨어
* GPL(General Public License): 자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이렌스
* Duplexing: 이중화(데이터베이스의 회복 기법 중 가장 간단한 것)
이중 통신(duplex) 또는 쌍방향 통신은 두 지점 사이에서 정보를 주고 받는 전자 통신 시스템을 말함 이중 통신을 할 때 전송 방향마다 두 개의 통신 선호를 사용하면 단순하지만 전송로를 아끼기 위해 여러 종류의 전송 방식이 쓰임
요구 분석 과정
* 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다
* 자료 흐름도, 자료 사전 등이 효과적으로 사용될 수 있음
* 구체적인 명세를 위해 소단위 명세서가 활용될 수 있음
요구 공학(Requirements Engineering)
사용자와 이해관계자의 요구사항을 체계적으로 수집, 분석, 명세, 검증, 관리하는 공학적 활동
품질 개선과 프로젝트 실패의 최소화를 목적으로 함
바람직한 소프트웨어 설계 지침
- 하나의 입구와 하나의 출구를 갖도록 해야 함
(제어 흐름이 명확해지고 이해, 검증, 유지보수가 쉬워짐)
- 병행성 수준을 높이기 위해서는 모듈을 독립성을 높여야 함
클래스
- 클래스들는 각각의 객체들이 갖는 속성과 오퍼레이션을 표현함
- 속성: 클래스의 상태나 정보를 표현함
- 오퍼레이션: 클래스가 수행할 수 있는 동작으로 함수라고도 함
mvc(model-view-controller): MVC 모델은 사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다
제어는 뷰와 모델 사이에서 전달자 역할을 수행하며 뷰는 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다
제어는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다
요구사항 명세 기법
