집밖은 위험해

UML Unified Modeling Language 

- 업무, 어플리케이션, 아키텍처 모델링에 사용하는 모델링 언어로 다양한 언어 코드 생성에 사용

UML 구성

- 사물, 관계, 다이어그램으로 구성

1. 사물 things

1.1 구조사물 structual 

 - UML 모델의 정적인 부분, 개념적/물리적 요소 표현. 클래스 class, 유스캐이스 use case, 컴포넌트 component, 노드

1.2 행동 사물

 - 시스템 행위. 상호작용 interaction, 상태 state

1.3 그룹 사물

 - 개념을 그룹화하는 사물. 패키지 package

1.4 어노테이션 사물

 - 부가적 개념 설명. 노트 note

2. 관계 

2.1 연관 관계 association : 다른 사물과 연관 있음

2.2 집합 관계 aggregation : 전체와 부분간 관계

2.3 포함 관계 coposition : 큰 부분이 소멸시 포함 부분도 함께 소멸됨

2.4 일반화 관계 generalization : 부모/자식 관계로 상속을 나타냄

2.5 실체화 관계 realization : 인터페이스 구현 관계

2.6 의존 관계 dependency : 한사물 변화가 타사물에 영향주는 관계

3. 다이어그램

3.1 구조적 다이어그램

- 클래스 다이어그램 : 비슷한 객체들의 그룹

- 객체 다이어그램 : 객체의 인스턴스 사이 관계

- 컴포넌트 다이어그램 : 소프트웨어 물리적 단위(exe, dll 등)의 구성과 연결상태 표현

- 배치 다이어그램 deployment diagram : 결과물, 프로세서, 하드웨어 등 물리적연결 표현

- 패키지 다이어그램 package diagram : 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

3.2 행동 다이어그램

- 유스케이스 다이어그램 usecase : 사용자 입장에서 본 시스템

- 시퀀스 다이어그램 sequence : 객체간 메시지 시간 흐름에 따른 표현

- 상태 다이어그램 state : 객체의 상태 변화를 나타냄

- 활동 다이어그램 activity : 유스캐이스 내부나 객체 동작 중 발생활동 표현

- 커뮤니케이션 다이어그램 communication : 객체간 메시지 표현

유스케이스 

- 타원으로 표시하고 안에 유스케이스명 작성

클래스 

- 클래스 : 공통의 속성, 오퍼레이션 및 관계를 갖는 객체들의 집합

1. 클래스 정의

- 클래스 이름은 대문자로 시작, 속성과 오퍼레이션은 소문자로 시작

- 패키지와 함께 표현시 패키지명::클래스이름 -> Dog::Bulldog

2; 속성 정의

- 속성이름:속성타입[=초기값]

- 가시성 visibility : +(public), #(protected), -(private)

- 밑줄 : 해당 클래스에 유일한속성

3. 기능 정의

- 오퍼레이션이름(파라미터 리스트):리턴타입

- visibility name(parameter-list):return-type-expression

4. 가시성 visibility

- +(public) : 외부 클래스에서도 사용 가능

- #(protected) : 하위 클래스와 해당 클래스 내에서만 가능

- -(private) : 해당 클래스에서만 가능

- ~(package, default) : 패키지 내에서만 사용 가능

5. 추상 클래스 abstract class

- 추상메소드가 1개 이상 존재하는 클래스

*이탤릭체로 표기하여 추상 메소드임을 알림

객체 

- 클래스의 인스턴스

- 특정한 속성 값 가짐

- 객체 이름은 밑줄로 표현 ex) 클래스이름:객체이름

협력 collaboration

- 목적 달성하기 위한 일련의 행위

- 타원을 점선 표기, 안에 역활 내용 기입

상태

- 객체 상태를 순서로 명시

- 이벤트에 대한 객체의 반응

액티브 클래스

- 하나 이상의 프로세스나 스레드 같는 객체를 파생하는 클래스 기술

- 클래스 표기와 비슷하지만, 양옆에 세로라인 추가

컴포넌트

- 시스템을 구성하는 물리적인 단위로 독립적인 실행단위 혹은 배포단위

- 배치 컴포넌트 deployment compoenent : dll, exe 같이 실행가능한 구성요소

- 작업 결과물 컴포넌트 word product compoenent : 실행에 쓰이지않으나 개발 작업에 만들어지며, 실행 시스템 생성

  -> ex) 분석/설계 문서, 소스코드 파일, 데이터 파일

- 실행 컴포넌트 executable component : 실행 결과로 생성되는 컴포넌트로 객체, DB레코드, 파일

노드

- 물리적인 요소로 시스템 실행때 존제

- 메모리와 처리능력을 가진 자원

- 육면체로 표현하여 필요시 컴포넌트 표기

데이터 모델 Data model

- 정보들을 나타내기 위해 단순화, 추상화한 모델

- 데이터 모델 요소 : 구조, 연산, 제약조건

- 구조 : 데이터 정적 성질로 엔티티 타입과 이들 간의 관계를 명세

- 연산 : 데이터 동적 성질로 엔티티 인스턴스에 적용가능한 연산에 대한 명세

- 제약 조건 : 데이터 베이스에 저장하는 데이터가 이상이 발생하지않도록(무결) 하기 위해  사용

데이터 모델 구조

- 개체 entity : 구분, 표현하려는 정보 단위

- 속성 attribute : 데이터의 최소 단위로 열에 해당  

- 관계 relation: 개체 간 관계나 속성 간 논리적 연결

데이터 모델 제약조건

- 개체 무결성 제약조건 : 개체의 기본키에 null이 들어가선 안되며 유일해야함 

- 참조 무결성 제약조건 : 외래키는 null이나 타 개체 타입의 기본키를 참조해야함

- 도메인 무결성 제약조건 : 도메인은 범위 내 원자값을 사용해야함

데이터 모델 종류

- 개념적 데이터 모델 : 현실 세계를 반영하여 개념적으로 나타낸 모델로 대표적으로 개체-관계 모델이 있음.

- 논리적 데이터 모델 : 개념적 모델을 DBMS에서 사용하기 위한 논리적 데이터 모델로 변경한 것(파악)

- 물리적 데이터 모델 : DBMS의 특성을 고려하여 구체화한 모델로 물리적인 구조(스키마)와 제약조건 작성(세분화)

개념적 데이터 모델 요소

- 개체 : 구분, 표현하려는 정보 단위

- 개체 타입 : 정보의 형태

- 개체 인스턴스 : 하나의 정보

- 속성 : 데이터의 최소 단위로 열

- 관계 : 개체 타입이나 속성 간 관계

- 카디널리티 cardinality : 개체의 최소, 최대 범위로 대수(옵션)

- 차수 degree : 하나의 관계에 연결된 개체타입 개수

논리적 데이터 모델 요소

- 튜플 : 릴레이션의 행

- 속성 : 릴레이션의 열

- 카디널리티 : 튜플 개수

- 차수 : 속성의 개수

- 릴레이션 인스턴스 : 릴레이션이 가지는 튜플들의 집합

- 릴레이션 스키마 : 릴레이션이 가지는 속성들의 집합

- 릴레이션 = 릴레이션 인스턴스 + 릴레이션 스키마

테이블과 릴레이션의 차이

- 릴레이션 : 개체들을 나타내기위한 추상적인 개념(논리적 데이터 모델)

- 테이블 : 구체적인 표현 방법(물리적 데이터 모델)

키

- 후보키 candidate key : 유일성과 최소성을 가지는 속성 또는 속성 집합

- 슈퍼키 candidate key : 유일성을 가지는 속성 또는 속성 집합

- 기본키 primary key : 후보 키중 릴레이션을 대표하는 속성 또는 속성 집합

- 대체키 : 기본키가 아닌 후보키

- 외래키 foreign key : 타 테이블의 기본키를 참조하는 속성

요구 공학 requirement engineering

- 요구사항을 분석, 명세화, 유지, 보수까지 모든 공정. 접근

요구공학 공정

1. 요구사항 추출 : 개발하고자하는 시스템에 대한 요구 추출

2. 분석 : 무엇을 구현할것인지 분석

3. 기술 : 분석된 요구사항을 명세화

4. 검증 : 요구사항 명세서 검증 

5. 유지 보수 : 새 요구사항 체계적 관리

요구 사항 requirement

- 시스템 기능. 사용자가 원하는 조건, 능력

요구 분석 명세서 

- 개발 초기에 사용자 요구사항 정리한 문서

요구 분석 과정

1. 사용자 요구 파악 : 면담, 문서 검토

2. 소프트웨어 목표 수립 : 요구사항 평가와 목표 수립

3. 모델링 : 자료와 제어 흐름, 기능 처리, 동작 행위 등 모델 작성

4. 요구 분석 명세서 : SRS Software Requirement Specification.  소프트웨어 기능, 성능, 제약조건 등 명세서 작성

요구사항 분석 방법

1. 구조적 분성 방법

 - 시스셈 기능 중심 구조적 분석. 프로세스 도출, 프로세스간 데이터 흐름 정의

2. 객체 지향 분석

 - 사용자 중심 시나리오 분석. 유스 케이스 모델로 구축

 - 유스케이스 실체화 과정을 통해 추출된 요구사항 분석

요구사항

1. 비기능적 요구사항

- 소프트웨어 성능, 용이성, 신뢰성, 보안 성 등 기능과 관련되지 않은 요구사항으로 개발 과정의 제약사항에 해당

 ex) 데이터 처리용량, 외부시스템과 연결, 보안 관련 준수사항

2. 기능적 요구사항

 - 소프트웨어 기능에 대한 요구사항 

 ex) 비즈니스 요구사항, 사용자 요구사항, 비즈니스 규칙

애자일 개념

- Agile(기민한, 빠르고 낭비없이 만드는 것) 개발을 가능하게 해주는 다양한 방법론 전체 말함

-> 개발 과정에서 변경사항 유연하고 빠르게 대응하는 방법론

- 큰하나를 단계별로 작은 여러개로 나누고, 작은 프로젝트를 하나씩 수행하고 테스트

- 문서 중심 산출물보다 소프트웨어 중심

애자일 특징

- 반복 점진적 개발

- 자기조직화와 교차 기능 팀 활용

- 빠르게 요구사항 반영, 프로토 타입 제작, 피드백 통한 의견 반영

- 다른 SDLC 모델과 다르게 분석과 설계를 크게 강조 안함. 구현단계를 초반에 수행

주요 에자일 방법론 종류

- SCRUM : 30일마다 동작 가능한 제품 제공하는 스프린트 중심

- XP(eXtream Programming) : 고객과 함께 2주 정도 반복 개발. 테스트와 우선개발

- Lean Software Development : 구체적 개발 프로세스 정의 없이 철학적 접근 방식 정의

- FFD(Feature Driven Developement) : 기능 중심 개발. 티처마다 2주 정도 반복 개발실시. UML

개발 방법론

- 소프트웨어 공학 원리를 소프트웨어 개발 생명 주기에 적용 -> 소프트웨어 개발방법론 = 소프트웨어 공학 + 방법론

- 시스템 개발을 위한 작업 활동, 절차, 산출물, 기법 등 정리

- 품질 높이고 납기일 준수하여 만족도를 높이기 위한 개발 방법

개발 방법론 진화 과정

60 : 대용량 계산 수단. 요구사항도 단순. 군분야에서. 기계어 사용. 개발 방법론 x

70 : 고급언어 사용. 요구사항 발생. 민간 영역으로 확대. 폭포수 방법론 탄생

80 : 대중화. 요구사항 복잡화. SDLC 개발 방법론 대두. c언어 사용

90 : 대형 프로젝트 증가. 위험관리, 요구사항 적합성, 생산성 고려. 객체지향언어 활용

00 : 웹 어플리케이션 중심 변화. 자동화 툴 발전

현대 : 고객 요구사항 + 개발자 편의성 고려한 자동화 툴. 계획부터 테스트까지 개발자 혼자 할수있는 시기

개발 방법론 특징

- 개발 단계 정의. 활동, 제품, 검증절차 각 단계 종결 기준 등 상세히 서술

- 방법과 절차 등을 공학적 방법으로 정의

개발 방법론 구성

1. 작업 절차 : 작업 단계 체계. 단계 - 활동 - 작업

2. 작업 방법 : 수행에 대한 구체적인 설명. 절차/작업방법

3. 산출물 : 단계별 산출물 목록 및 양식(설계서), 메뉴얼/설정 방법 등

4. 기법과 도구 : 기법 - 소요 기술(객체지향 모델링 기법), 도구 - 지원 도구 혹은 표준 방법(CASE)

개발 방법론 종류

1. 구조적 방법론

2, 정보공학 방법론

3. 객체지향 방법론

4. 컴포넌트 기반 방법론

1. 구조적 방법론

- 전체 시스템을 기능에 따라 분할하여 개발. 이를 통합하는 분할 방식의 방법론

 ex) 폭포수 모델

- 순차, 선택, 반복으로 프로그램 로직

- 정형화된 분석 절차에 따라 요구사항 파악하고, 도형중심 다이어그램으로 문서화

- 컨트롤 가능한 모듈로 구조화

- 장점 : 일괄 처리 소프트웨어 개발에 적합. 전형적인 접근법

- 단점 : 데이터 정보 은닉 불가. 재사용 보수성 낮음

구조적 방법론 단계별 산출물

1. 계획 : 도메인 분석서, 프로젝트 계획서

2. 분석 : DFD(Data Flow Diagram) - 프로세스들간 데이터 흐름을 표현한 도표

3. 설계 : Structure Chart - 소프트웨어 기능을 계층적으로 표현한 차트, 프로그램 사양서

2. 정보공학 방법론

- 데이터 중심 80년대 자료구조 중심 방법론. 구조적 방법론 극복

 ex) 프로토타입, 정보공학 방법론

- 기업 중심 계획, 데이터 중심 설계, 도형 산출물

- 장점 : 전략적 기회식별 및 방안 제공, 장기적 발전 허용

- 단점 : 장기간 필요, 특정 사업 영역으로부터 독립된 시스템 개발에는 부적합

정보공학 방법론 단계별 산출물

1. 계획 :도메인 분석서, 프로젝트 계획서

2. 분석 : ERD, 기능 차트, 이벤트 모델

3. 설계 단계 : 어플리케이션 구조도, 프로그램 사양서, 테이블 정의서 목록

3. 객체지향 방법론

- 소프트웨어 생명주기에 객체지향 개념 접목해 일관된 모델로 개발

- 객체, 클레스 및 이들과 관계를 식별하여 설계 모델로 변환

객체지향 방법론 원리

1. 업무 요건 정의 : 요구사항 수집 -> 업무요건 정의

2. 객체 지향 분석 : 객체 모델링 -> 동적 모델링 -> 기능 모델링

3. 객체지향 설계 : 시스템 설계 -> 객체 설계 -> 구현

4.테스트/배포 : 테스트 ->패키지 -> 프로젝트 평가

객체지향 방법론 산출물

1. 계획 : 비즈니스 프로세스, 컨셉 모델, 프로젝트 계획서

2. 분석 : 유스케이스 다이어그램, 시퀀스 다이어그램, 클래스 다이어그램

3. 설계 : 시퀀스/클래스/컴포넌트 다이어그램

객체 지향 분석

- 객체 모델링 :시스템 정적 구조. 추상화, 분류화,일반화

- 동적 모델링 : 객체 사이 변화 조사. 상태, 동작

- 기능 모델링 : 입력에 대한 처리 결과 확인

객체지향 설계와 분석

- 시스템 설계 : 시스템 구조를 서브시스템으로 분해. 성능 최적화/자원 분배 방안

- 객체 설계 :상세 내역을 모형으로 개발 상세화. 구체적 자료구조와 알고리즘 구현

- 객체 지향 구현 

4. 컴포넌트 기반 방법론 CBD

- 재사용가능한 컴포넌트 개발, 조합하여 어플리케이션 개발

- 2000년대 컴포넌트 중심 개발 방법론. Agile 방법론

- 객체지향개발방법론 개선, 인터페이스 중시, 컴포넌트 기반 재사용성 중시, 개발시간 단축

컴포넌트 기반 방법론 원리

1. 요구 분석 : 요구사항 분석

2. 분석 : 아키텍처 정의, 유스케이스 모델링

3. 설계 : UI 설계, 컴포넌트 정의/설계, DB, 테스ㅡㅌ 설계

4. 개발 : 코딩, 테스트

5. 구현 : 릴리즈, 교육

컴포넌트 기반 방법론 단계별 산출물

1. 계획 : 비즈니스 프로세스 모델, 프로젝트 모델

2. 분석 : 유스 케이스 다이어그램, 컴포넌트 다이어그램, 재사용 계획서

3. 설계 : 시퀀스 다이어그램, 클래스 다이어그램, 컴포넌트 다이어그램

컴포넌트 기반 방법론 분류

- 요소 컴포넌트 : 최소단위 컴포턴트

- 기능 컴포넌트 : 요소 컴포넌트를 결합하여 하나의 기능 구현

- 서비스 컴포넌트 : 하나의 사용자 서비스 수행하는 컴포넌트

- 어플리케이션 컴포넌트 : 여러 서비스 수행하는 시스템 컴포넌트

소프트웨어 개발 라이프 사이클 SDLC software development life cycle

- 소프트웨어 개발을 주기로 보고 수행하기 위한 프로세스 모델 과정

- 타당성 검토부터 개발, 폐기 전과정을 생명주기로 보고 정의, 단계별 체계화

소프트웨어 위기

1. 원인

- 소프트웨어가 복잡해지니까 잘 관리해서 효율적으로 개발하자

- 소프트웨어 규모 대규모화, 복잡 -> 개발 비용 증가

- 하드웨어 비용에 대해 소프트웨어 가격 증가

- 유지보수 어려움과 개발 정체 현상 

2 증상

- 예산 초과, 일정 지연, 비효율적인 소프트웨어

-> 요구사항 불만족, 관리가 어려운 코드

3. 대응 방안

- 객체 지향 프로그래밍, 캡슈로하

- 구조적 프로그래밍

- 통합 개발환경, 컴포넌트화, 프로토타이핑

- 애자일 개발 프로세스, 버그/이슈 관리 시스템, 버전 관리 시스템

- 디자인 패턴, 가비지 콜렉션, 멀티스레딩

SDLC 특성

- 프로젝트 수행 절차를 이행하기 위한 효과적 도구

- 유형, 관점, 개발 방침, 표준 정책에 따라 다양한 방법 존재

SDLC 기능

- 비용 산정, 개발 계획 수립

- 표준화 지원, 프로젝트 관리 지원

SLDC 장접

- 소프트웨어 개발 과정 통제 가능

- 대규모 시스템 개발에 적합

- 문서화 용이

SDLC 단점

- 사용자 요구사항 변경힘듬

SDLC 프로세스

1. 요구사항 정의

- 요구사항 식별, 상세화

- 프로그램 개발을 위한 사양 작성(아키텍처, 프레임워크, 디자인 패턴)

-> 요구사항 명세화

2. 개발 단계

- 프로그래밍 및 실행 코드 생성

- 테스트 : 다양한 수준 테스트(단위/통합 등)로 검증

3. 지원 단계

- 구축 후 인수 테스트 및 교육

- 유지 보수

- 폐기

SDLC 프로세스 정리

- 정의 단계 : 타당성 검토, 요구사항 분석, 설계

- 개발 단계 : 개발, 테스트

- 지원 단계 : 설치/이행, 유지보수, 폐기

SDLC 모델 유형

1. 폭포수 모델

2. 원형 모델

3. 나선형 모델

4. 반복적 모델

5. RAD 기법 모델

6. 4세대 모델

7. 클린룸 모델

8. V모델

1. 폭포수 모델 waterfall

- 개념 정리서 구현까지 하향식 접근 방법으로 추상화 모델링

- 가장 많이 사용된 전통적 모델

- 소프트웨어 개발을 단계, 순차, 체계적 접근

- 각 단계를 철저히 매듭짓고 다음단계 진행

- 검토 validation 및 검증 vertification, 검사 test에 프로젝트 전반 품질 향상 추구

폭포수 모델 장단점

- 장점 : 복잡성이 낮고 세분화하여 관리 용이, 사례가 풍부하고 이해하기 쉬움

- 단점 : 소프트웨어가 거대화, 요구사항 구체화 힘듬. 단계마다 불필요한 문서 양산. 개발 완료 시점에서 완성 가능

2. 원형 모델 prototyping

- 고객과 원할한 의사소통을 통한 개발 모델

- 사용자 요구사항을 충분히 분석할 목적으로 시스템 핵심적인 기능 먼저 만들어 평가 후 구현하는 점진적 개발방법

=> 사용자 요구 잘 반영, 개발 중에도 유지보수 효과

- 기본적으로 폭포수 모델과 같으나 프로토 타입 과정이 추가. 요구사항 분석 잘못될시 다시 샘플 만듬

프르토타이핑 장단점

- 장점 : 사용자 요구사항 불명확시 사용 용이, 관리자 이해 용이, 제품 추적 시험 가능성 확보

- 단점 : 개발 완료로 착각하기 쉬움, 문서 작성 미흡, 과다한 요구사항 발생

프로토타이핑 프로세스

1. 요구사항 분석

2. 프로토타입 개발 - 핵심적 기능위주

3. 요구 사항 이행 확인

4. 수정 및 보완

5. 고객과 개발자가 함께 평가

3. 나선형 모델 spiral

- 소프트 웨어 기능을 나누어 점진적으로 개발하는 모델

- 개발 중 위험 최소화 하기 위해 나선을 돌면서 개발해나감

-> 리스크 최소화, 점진적 수행, 위험 부담이 큰 대형 시스템 구축에 적합

나선형 모델 장단점

- 장점 : 대규모 시스템에 적합, 위험 감소 유지보수 용이, 반복적 개발 및 테스트로 강인성 향상, 다음 사이클서 기능추가

- 단점 : 관리가 힘들고 개발 시간 장기화, 복잡한 프로세스

나선형 모델 프로세스

1. 목표 설정 planning : 목표/제약조건 설정

2. 위험 분석 risk analysis : 우성 순위 기능 선택

3. 구현 및 테스트 engineering : 선택된 기능 개발

4. 의사소통 및 다음단계 수립 evaluation : 개발 경과 평가, 요구사항 반영 수정

목표

- 소프트웨어 개발과 프로세스 적용 관련 지식을 활용하여 SW 안정성 보장, 품질 평가를 위해 case 도구 및 다양한 기법 학습

공학과 소프트웨어 정의

- 공학 : 과학적 원리 지식 도구 등으로 새로운 제품, 도구 만드는 것

- 소프트웨어 : 프로그램, 개발, 운용, 보수 전체

소프트웨어 공학

- SW 개발, 유지보수 등 생명주가 전방 체계적으로 다루는 학문

=> 좋은 SW 개발, 관리를 위함

소프트웨어 공학의 목적

1. 소프트 개발의 어려움

2. 효율적인 개발을 통한 생산성 향상

3. 고품질 소프트웨어 생산

소프트웨어 공학 구성 요소

1. 원리

2. 기법

3. 도구

4. 언어

소프트웨어 공학 영역

1. 요구공학 requirement engineering

- SW 개발에서 첫 작업

- 목표와 제약사항 확립하여 기능, 성능(user requirements 요구사항) 정의하는 과정

- 다른 시스템과의 인터페이스 등 정의하는 과정

- 비용 조건, 납기 지연, 품질 저하 방지

2. 아키텍처 architecture

- 아키텍처 구성요소와 요소 간의 관계, 시스템 기능, 속성 및 제약사항을 적절히 반영하는 구조를 조직화하여 시스템 전체적인 형태

-> 컴포넌트와 커넥터로 시스템을 분할하여 구조화하는것

3. 개발 방법론 development methodology

- 어떤 방법으로 개발할 것인가

- 구조적 방법론, 객체지양 방법론, 컴포넌트 방법론

- 개발 조직 특성 및 여건에 맞게 조정 및 재정의 될 수 있음

4. 테스팅 testing

- 오류 없는 SW 개발을 위해 수행하는 테스트 작업

- 구성 : 단위 테스팅, 통합 테스팅, 시스템 테스팅

5. 프로세스 process

- 소프트웨어 개발 및 진화에 사용되는 활동, 방법

- 요구되는 인력, 절차, 방법, 도구 들을 통합하는 수단

- 프로세스 정의방법, 관리조직, 관리 기반 구조등에 대해 연구됨

=> 소프트웨어 프로세스 특성을 설명하는 모형, 효과적인 프로세스 실현을 위한 단계적 접근 방법 명시 모델 연구

6. 형상 관리 configuration management

- 소프트웨어 구성요소에 대한 변경 관리 대상인 형상 항목을 식별해서 변경을 통제 기록함

- 형상 식별, 형상 통제, 형상 상태 확인, 형상 검사

7. 품질 quality

- 소프트 웨어 품질은 제품 품질 product quality와 프로세스 품질 process quality로 구분

- 제품 품질 : 제품 자체의 품질

- 프로세스 품질 : 소프트웨어 개발하는 프로세스가 정확하고 우수한지. 좋은 프로세스 품질은 좋은 소프트웨어 생산

- SQA, 제품 검사, 평가 모델, 국제 표준

8. 재사용 reuse

- 코드 재사용

- 응용 분야 지식

- 개발 경험

- 설계 결정

- 시스템 지식

- 요구사항 분석

- 설계, 문서

=> 코딩 단계 이전의 분석 및 설계 단계서 만들어진 산출물을 재사용하려는 노력이 계속됨

9. 프로젝트 관리 project management

- 프로젝트의 일정, 인력 및 예산 등 관리하여 프로젝트를 성공적으로 이끌기 위해 요구됨

- 프로젝트 관리 영역 : 프로젝트 통합, 범위, 일정, 비용, 품질, 인적자원, 의사소통, 위험, 조달관리

10. 정형 기법 formal method

- 수학과 논리학 기반으로 소프트웨어 시스템을 명세하거나 검증하는 기법

- 정형 논리 formal logic, 수리 논리 mathematical logic -> 정형 명세 기법, 수식 사용 -> 체계적으로 시스템 검증

11. 유지 보수 maintenance

- 고객에게 인도된 후에도 개선 목적으로 일부분 수정, 유지보수

- 수정 유지보수 : 오류 수정

- 적응 유지보수 : 새환경에서 적응할수있도록 수행

- 완전 유지보수 : 새 기능 추가, 구조 성능 개선

- 예방 유지 보수 : 잠재적인결함 예방

소프트웨어 분류

1. 관리 소프트웨어

 - 자료를 받아 가공 후 정보 제공

2. 제어 소프트웨어

 - 각종 센서를 이용하거나 기기 동작을 제어하는 소프트웨어

3. 임베디드 소프트웨어

 - 장비나 기기에 내장된 형태의 소프트웨어

소프트웨어 개발 프로세스

- 소프트웨어 제품 개발에 필요한 과정

1. 계획

2. 요구분석

3. 설계

4.. 구현

5. 테스트

6. 유지보수

1. 소프트웨어 개발 개획

- 무엇을 개발할지 결정

- 타당성 분석

- 요구사항 식별하여 시스템 정의서 문서화

- 개발 계획서 작성

2. 요구분석

- 시스템 목표 확립

- 요구사항 발견, 모델링, 명세화 과정

- 만족해야할 기능, 성능, 타 시스템과 인터페이스 규정

=> 요구 사항 분석 명세서 작성

3. 설계

- 제품의 공학적 표현

- 요구사항으로 추적

- 구현 이전에 소프트웨어 뼈대를 정의해 구현 기반 만듬

3.1 상위 설계 high level design

- 아키텍처 설계, 예비 설계, 시스템 수준 소프트웨어 구성, 컴포넌트 간 관계로 구성된 시스템 전체적인 구조

-> 구조 설계, DB 설계, 인터페이스 설계

=> 시스템 구조도, DB 설계도(ERD), 화면 및 출력물 레이아웃

3.2 하위 설계 low level design

- 모듈 설계, 상세 설계

- 각 구성요소들의 내부 구조와 행위 결정

- 구성요소의 제어와 데이터간 연결에 대한 구체적 정의

-> 컴포넌트 설계, 자료구조 설계, 알고리즘 설계

=> 절차 기반, 자료 위주,객체 지향

4. 구현

- 프로그래밍 수행

- 코딩과 디버깅

- 단위 시험 unit test 실시

- 규칙 : 높은 가독성, 간결하고 명확한 코딩

5. 테스트 test

- 소프트 내 오류 발견하여 수정하는 단계

- 테스트 절차

1. 테스트 계획

2. 테스트 케이스 설계

3. 테스트 실행 및 평가

4. 테스트 결과 분석

5. 오류 추적 및 수정

- 결과 분석 : 테스트로 얻은 값과 목표한 값 비교

-> 보고서 작성

6. 유지 보수

- 오류 수정, 환경 변화에 따른 적응, 기능 향상에 따른 요구사항 변경 고려

- 성능 개선, 하자 보수, 새 환경에 대한 이식 및 수정

소프트웨어 프로젝트

- 제품이나 서비스를 만드는데 수행해야하는 행동

- 구성요소 : 목표, 비용, 참여자, 기술, 고객, 기간 등

- 프로세스 : 소프트웨어 제품 구상 -> 제안 요청서 배포 -> 제안서 제출 -> 심사 -> 계약서 작성 -> 프로젝트 시작 및 수행 -> 프로젝트 종료 및 제품 인도

프로젝트 관리

- 프로젝트 요구사항을 만족하기 위해 지식, 기술, 툴을 프로젝트 활동에 적용

1.  프로젝트 통합 관리

 - 변경 관리를 통해 수정된 내용으로 개정된 프로젝트 정함

2. 범위 관리

 - 프로젝트 범위 정의. 검증. 통제

3. 일정 관리

 - 기간 내수행하기 위한 프로세스로. 작업 정의, 작업 순서, 작업 기간 산정, 일정 개발, 일정 통제

4. 비용 관리

 - 예산 안에서 완료하도록 요구되는 프로세스. 자원기획, 비용산정, 비용예산수립, 비용 통제

5. 프로젝트 품질 관리

 - 품질 기획, 품질 보증, 품질 통제

6. 인적 자원 관리

 - 조직 기획, 팀 확보, 팀 개발

7. 위험 관리

 - 위험 관리 기획, 위험 식별, 정성적 위험 분석, 정량적 위험 분석, 위험 대응 기획, 위험 감시 및 통제

8. 의사소통 관리

 - 의사소 소통 기획, 정보 배포, 성과 보고, 성과 정보

9. 프로젝트 조달 관리

 - 조달 기획, 권유 기획, 공급자 유치, 공급자 선정, 계약 관리, 계약 종료

갱신 이상 update anomaly

- 데이터 중복으로 발생하는 문제

- 삽입 이상 : 불필요한 데이터를 삽입하지 않으면 데이터 삽입이 안되는 이상

- 수정 이상 : 중복데이터 중 일부만 수정되어 데이터 불일치 발생

- 삭제 이상 : 유용한 데이터도 같이 삭제되는 문제

교수 릴레이션 - 기본키 : 학번, 교과목 번호

- 학번에 학년 정보가 중복되어 있음

- 삽입 이상 : 600번 학생. 2학년 삽입 시 교과목 번호가 없으면 삽입 x

- 수정 이상 : C312 수강한 400번 학생 학년을 4 -> 3학년으로 변경시 나머지 데이터 학년과 불일치

- 삭제 이상 : 200번 학생 삭제시 3학년 정보도 사라짐

->속성간 종속성 고려가 불충분해서 발생

=> 릴레이션 분해해서 하나의 종속관계를 하나의 릴레이션으로 표현해야함 => 릴레이션 정규화

함수적 종속 functional dependency : fd

- 정규화 핵심 개념으로 릴레이션의 갱신 이상을 발견하는 방법.

- 속성 간 관계에 대한 제약조건에 해당

- 속성 y는 속성 x에 함수적으로 종속 : x -> y

사원 릴레이션의 함수적 종속 관계 표현

1. 사원번호 -> 사원 이름, 주소, 전화번호 : 사원번호를 알면 이름, 주소, 전화번호알수있음

2. 부서번호 -> 부서이름 : 부서번호를 알면 부서이름 알수있음

3. 부서이름 -> 부서번호 :부서이름을 알면 부서번호알수있음

4. {사원번호, 부서번호} -> 직책 : 사원번호, 부서번호를 알아야 직책을 알수있음

5. x : 사원이름이나 부서번호, 주소등을 알아도 나머지 속성을 알수없음. 함수적으로 결정 x

함수적 종속 다이어그램 function dependency diagram fdd

- 함수적 종속 관계를 그림으로 표현

사원 릴레이션 함수적 종속 다이어그램

완전 함수적 종속 full functional dependency

- 복합속성 x -> y가 성립시

- 복합속성 {a,b}가 c의 결정자로 a나 b만으로 c를 결정 불가

부분 함수적 종속

- 복합 속성 x->y 성립시

- 복합 속성 {a, b} 중 b만으로 c를 결정

사원 릴레이션 함수적 종속 정리

함수적 종속 1. {사원번호, 부서번호} -> (직책, 사원이름, 주소, 전화번호, 부서이름) 성립

부분 함수적 종속 1.  {부서번호} -> (사원이름, 주소, 전화번호)

부분 함수적 종속 2  {사원번호} -> (부서이름)

완전 함수적 종속 1. {사원번호, 부서번호} -> (직책)

이행적 함수적 종속 transitive functional dependency

- 한 릴레이션 속성 a, b, c가 있을때 다음 필요충분조건 만족하는경우. 속성 c가 속성 a에 이행적 함수적종속

학생 릴레이션 예시

- 학생(학번, 교과목번호, 성적, 학과 이름, 학과 전화번호)

함수족 종속 

- 완전 함수적 종속 : {학번, 교과목 번호} -> 성적

- 부분 함수적 종속 : 학번 ->(학과이름, 학과전화번호)

- 완전 함수적 종속 : 학과이름->학과전화번호

학생 릴레이션 함수적 종속 다이어그램

학번 -> 학과명, 학과명-> 학과 전화번호

=> 학과 전화번호는 학번에 이행적 함수적 종속관계

정규화 normalization

- 데이터 중복을 제거하여 갱신 이상 제거. 논리적 데이터 모델 단순화 

* 많은 조인이 발생하여 질의 응답시간이 느려질수있음

정규형 normal form

- 데이터 중속 감소와 응답시간 단축하기위한 제약 조건을 만족하는 형태 

- 제약조건에 따라 제1 정규형 ~ 제 5정규형.

- 정규화 정도가 낮을수록 하나의 릴레이션에 많은 정보 포함

정규형 단계

1. 제 1정규형 1NF : 모든 속성 도메인이 원자값 -> 중복 속성 분리

2. 제 2정규형 2NF : 모든 속성이 기본키에 완전 함수적 종속 -> 기본키에 부분 함수적 종속 속성 분리

3. 제 3정규형 3NF : 이행적 함수적 종속 없어야함 -> 이행적 함수적 종속 속성 분리

4. 보이스/코드 정규형 BCNF

* 보통 제3정규형이나 보이스/코드 정규형까지 정규화 수행

3NF, BCNF가 최적인 이유

- 1NF, 2NF : 불필요한 데이터 중복, 공간 낭비

- 4NF, 5NF : 너무많은 릴레이션. 복잡한 종속성

정규화 단계

0. 비정규 릴레이션

1. 1NF <- 원자 값이 아닌 도메인 분해

2. 2NF <- 부분 함수적 종속 제거

3. 3NF <- 이행적 함수적 종속 제거

4. BCNF <- 결정자가 후보키가 아닌 함수적 종속 제거

5. 4NF <- 다치 종속성 제거

6. 5NF <- 조인 종속성 제거

- 비정규 릴레이션 예시 : 동아리가 다중치 속성

(1) 제1 정규형

- 릴레이션 속성은 원자값만 가져야함. 학생 2 새 릴레이션 생성(기본키 : {학번, 동아리})

- 그러나 학번, 이름, 학과가 중복된 데이터 발생 -> 2개의 새 릴레이션(제 1 정규형 만듬)

- 학생 3 릴레이션(1NF) : 학번 -> (이름, 학과)

- 학생 4 릴레이션(1NF) : {학번, 동아리}

(2) 제 2정규형

- 제1 정규형은 기본키에 부분적 함수적 종속으로 갱신 이상 발생

-> 릴레이션을 분해하여 부분적 함수적 종속 제거하여 제 2정규형 만듬

수강지도 릴레이션 분해

- 수강지도(학번, 교과목번호, 지도교수, 학과, 성적)

- 기본키 : {학번, 교과목번호}

- 함수적 종속

 학번 -> (지도교수, 학과)

 {학번, 교과목번호} -> 성적

 지도교수 -> 학과

수강 릴레이션 2NF, 지도 릴레이션 2NF

- 학번 -> (지도교수, 학과)로 부분적 함수적 종속 발생

=> 수강 릴레이션과 지도 릴레이션으로 분해

지도(학번, 지도교수, 학과)

수강(학번, 교과목 번호, 성적)

(2) 제 3 정규형

- 제 2정규형은 이행적 함수적 종속관계가 존재시 갱신 이상 발생

-> 이행적함수적 종속 제거하여 제3정규형 만듬

지도 릴레이션 2NF

- 지도(학번, 지도교수, 학과)

- 기본키 : 학번

학번 ->(지도교수, 학과)

지도교수 -> 학과

=> 학과는 학번에 이행적 종속관계

지도 릴레이션 분해 3NF

- 지도릴레이션을 학생지도와 교수소속 3NF 릴레이션으로 분해

학생지도(학번, 지도교수)

교수소속(지도교수, 학과)

보이스 코드 정규형 BCNF

- 제3 정규형은 후보키가 아닌 결정자가 존재시 갱신 이상 발생

-> 모든 결정자가 후보키가되는 BCNF 만듬

수강과목 3NF 릴레이션

- 수강과목 : (학번, 교과목, 교수)

- 기본키 : {학번, 교과목}

- 후보키 : {학번, 교과목}, {학번, 교수}

{학번, 교과목} -> 교수

교수 -> 교과목

-> 교수 속성이 후보키가 아닌데도 결정자 역활 수행

수강과목 3NF 릴레이션 분해

- 교수과목(교수, 교과목) BCNF 릴레이션

- 수강교수(학번, 교수(FK)) BCNF 릴레이션

역정규화 denormalization

- 성능 개선을위해 데이터 중복과 갱신 이상이 생기더라도 낮은 정규형으로 되돌아감

테이블과 릴레이션 차이

- 테이블 : 릴레이션 표현하는 구채적인 방법

- 릴레이션 : 추상적인 개념 중복 허용 x

논리적 설계

- 개념적 데이터 모델을 DBMS가 지원하는 논리적 데이터 모델(릴레이션=릴레이션 인스턴스 + 릴레이션 스키마) 설계

- 논리적 모델링 : 개념적 스키마를 논리적 스키마(릴레이션 스키마)로 변환, 정규화 수행, 무결성 제약조건 정의

- 트랜젝션 인터페이스 설계 : 트랜젝션 모델링을 기초로 인터페이스 설계

릴레이션 스키마

- 관계 데이터 모델의 기본이 되는 릴레이션을 구성하는 속성들의 집합

- 릴레이션 이름과 속성들로 표현

1. erd 개체와 관계를 릴레이션 스키마로 변경 ->  릴레이션명(속성1, 속성2)

2. 기본키에 밑줄 표기

3. 스키마 단순화 - 1:1, 1:n 관계 유형 단순화

4. 정규화로 적합한 릴레이션 형태로 변환

튜플 tuple : 관계 데이터 모델의 한 행으로 개념 데이터 모델의 엔티티에 대응

속성 attribute : 관계 데이터 모델 의 열

도메인 domain : 속성이 가질수 있는 값의 영역

카디널리티 cardinality : 릴레이션이 가지는 튜플의 갯수

차수 degree : 릴레이션이 가지는 속성의 개수

릴레이션 인스턴스 relation instance : 튜플들의 집합

릴레이션 스키마 relation schema : 속성들의 집합

릴레이션 relation : 릴레이션 인스턴스 + 스키마

키 key : 유일하게 식별할수 있는 속성이나 속성 집합

후보키 : 유일성, 최소성 만족하는 속성 집합

슈퍼키 : 유일성만 만족하는 속성 집합

대체키 : 기본키가 아닌 후보키들

기본키 : 후보키중 가장 적합한 키, not null, unique

외래키 : 타 릴레이션의 기본 키를 참조하는 키

무결성 제약 조건 integrity constraints

- 정확성과 일관성 유지를 위해 db가 만족해야하는 조건

1. 개체 무결성 :기본키는 구분가능한 유일한 값으로, null값을 가져선 안됨

2. 참조 무결성 : 외래키는 null이나 기본키값을 가져야함

3. 도메인 무결성 : 미리 정해진 도메인 값을 가져야함

- 기본키와 외래키는 개체 무결성과 참조 무결성은 묵시적으로 정의됨

- not null, unique, check 는 논리적 모델링 단계에서 명시적으로 정의

개념적 설계 conceptual design

- 요구 분석 명세서를 토대로 DBMS와 무관한 추상적 형태로 요구사항 표현

- 개념적 모델링 : 데이터 중심 DB 설계. 데이터 요구분석 명세서로 ER 모델 도출 -> ERD로 표현

- 트랜잭션 모델링 : 처리 중심 DB 설계. 트랜젝션 요구분석 명세서를 기초로 업무 단위 유형별 트랜잭션 설계

데이터 요구 분석 명세서 -> 개념적 모델링 -> ER 모델

- 목표 : 주요 개체와 관계를 식별

1. 핵심 개체 타입 식별

2. 관계 타입 식별

3. 관계 타입 유형과 카디널리티(옵션, 최소 최대범위) 설정

4. 개체 타입 속성 식별

5. 개체 타입 식별자 결정

6. 관계 타입 속성 식별

7. ERD 표현

8. 검증

개체 entity

- db가 표현하려는 정보로 구별될수 있는 요소

개체 타입 entity type

- 테이블

관계 relation

- 개체간 의미있는 연결, 연관성

속성 attribute

- 개체의 특성. 정보의 가장 작은 단위

- 개체 설명하는 명사 -> 개체의 속성, 관계 설명하는 명사 -> 관계의 속성

차수 degree

- 관계에 연결된 개체 타입의 수

카디널리티 cardinality

- 관계에 대한 개체 최소, 최대 범위. 옵션

ERD entity relation diagram

- 개체 관계 모델을 표현하는 방법

1. 개체 타입 표시 - 사각형. 이름

2. 개체 타입 간 관계 표시 - 가능한 동사

3. 관계 타입 유형 표시 : 1:1, 1:N, N:M

4. 관계 타입 카디널리티 표시 : (최소, 최대) 옵션

5. 개체 타입 속성 표시 : 최소 한개의 식별자(기본키). 식별자는 밑줄, 동그라미. 최소 2개이상

6. 관계 타입 속성 표시 : 속성이 있는 경우