전산직 소프트웨어공학 정리(ing)

전체적인 과목 흐름을 파악하는게 중요 하나의 소프트웨어를 계획부터 해서 개발 그리고 이후 유지보수와 평가까지 한다고 생각하고 봐야한다.

 

- 소공

 

UP(United Process) 

: 통합 프로세스로 점진적임(iterative), 유스케이스 기반, 아키텍처 중심의 개발을 지향 , 위험관리를 중시 

1. Inception(도입)
2. elaboration(상세)
3. construction(구축)
4. transition(이행) 

반복적,점진적, 유스케이스기반, 아키텍처 중심

 

V 모델 

1. 사용자 환경 (설치시험)

2. 시스템 정의 (인수시험)

3. 요구분석(시스템시험,요구사항) : 타당성 조사 -> 요구사항 추출 및 분석 -> 요구사항 명세화 -> 요구사항 검증

4. 구조설계(통합시험,인터페이스)

5. 상세설계(단위시험,모듈 내부 오류)

6. 코딩(디버깅)

답은 2번이다. 

 

나선형 모델 

 

애자일 방법론 종류 : 스크럼, 동적시스템 개발 방법, 적응형 소프트웨어 개발(ASD),XP,FDD,Crystal

XP : 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법, XP는 프로그래머들이 코딩을 할때에 테스트 코드를 작성하도록함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 한다(+ 프로토타입), 자동화된 테스트 도구 사용

 

 

소프트웨어 개발 계획 단계 : 비용과 일정 도출

 

COCOMO : 프로젝트 관리와 계획에서 비용 예측 함수 인자 

1. 한해 동안 코드 한줄에 가해지는 변경 횟수

2.개발할 떄 사용한 노력

3.유지보수 작업을 위한 보정한 값 

 

이때 FP(기능점수)도 사용된다. - 외부조회,외부입력,외부출력 내부논리파일,외부연계파일 

(잘보면 내부조회,입력,출력은 없다 인지하자) 

 

일정계획은 CPM네트워크나 간트 차트 이용함

 

이후 요구 분석함 ( 구조적 분석(dfd+자료사전),객체지향 분석(use case))

-> 요구분석 명세서 만듬 , 그럴려면 추출 해야하고 ( 면담, 시나리오, 유스케이스, 브레인 스토밍 등 존재) 

이는 비정형 명세와 정형 명세로 나뉨 

정형명세는 수학적이므로 MTBF(뒤에 두개 더한거), MTTF(고장까지),MTTR(수리시까지)가 있다 

비기능적 요구사항에서 개발에 대한 제약사항(개발 방법과 개발 플랫폼)을 정한다.

예) 모델링 언어는 UML 2.x를 사용해하며, 개발 언어는 java언어, 운영체제는 Linux에서 동작해야 한다.

 

위험 관리 활동 = 식별 -> 분석 -> 계획 -> 관찰 

 

이후 모델링(객체지향)을 진행한다.

객체지향 분석 대표적인것이 럼바우(OMT)이다.

이건 구성요소를 그래픽 표기로 모델링하는 기법이며 객체 - 동적 - 기능 모델링 순서로 진행된다.

모델링엔 UML을 사용한다.

UML은 유스케이스, 클래스, 시퀀스, 협동, 상태, activity 다이어그램등이 있다.

이때 정적 모델은 클래스,패키지,배치이고 동적은 시퀀스,상태,액티비티이다.

1번이요

구성요소 : message, lifeline, activation

alt : 조건으로 나뉘어질때 

opt : 조건인데 else를 따로 정의하지 않고 발생할때만 정의해 둠, 아니면 아무것도 아닌걸로

par : 병렬로 수행할수 있다는 뜻

 

UML에서 가장 표현하기 어려운 것 - fork 와 join

include는 반드시 실행해야 하는거고 extend는 필요하지만 실행할수도 있고 안할수도 있는 선택적인 것

a -->(include) b 이면 a하려면 b가 필요하다 

a <--(extend) b이면 a라는 행동에 b가 추가적으로 가능 , 이게 좀 헷갈릴수 있다.

 

- 클래스 설계에서의 원칙 

1. 단일 책임원칙 : 한 클래스는 하나의 책임만 가진다.

2. 개방 폐쇠 원칙 : 확장에는 열려 있고 변경에는 닫혀 있다

3. 리스코프 치환 원칙 : 객체는 하위 타입의 인스턴스로 바뀔수 있어야 한다.

4. 인터페이스 분리 원칙 : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

5. 의존관계 역전 원칙 : 추상화에 의존, 구체화에 의존하면 안된다. 

 

memento 패턴  :  원하는 시점의 데이터를 복원할 수 있는 패턴

Command 패턴 :  요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴이다.

Strategy 패턴 :  객체가 할 수 있는 행위들 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴입니다.

facade패턴 : 어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공한다. 그니까 여러 인터페이스 호출 순서같은거 한번에 실행되도록

adapter 패턴 : 한 클래스의 인터페이스를 클라이언트에서 사용하고자하는 다른 인터페이스로 변환한다. 호환성없는 둘을 연결시켜 준다.
composite 패턴 :  단일 객체와 그 객체들을 가지는 집합 객체를 같은 타입으로 취급하며, 트리 구조로 객체들을 엮는 패턴이다

 

 

모델링 된것을 보고 구조를 설계한다. 

상위- 하위 설계를 함. 이때 디자인 패턴을 통해 설계가 된다. 

 

상위 보단 하위 설계에서 응집도와 결합도를 따진다.

응집도 = coincidental -> logical -> temporal ->procedure -> communication -> sequential->functional

결합도 =  data -> stamp -> control -> common -> content

 

그리고 클래스 설계 원칙(SOLID)

단일 책임 : 클래스는 단 한 개의 책임을 가져야 한다

개방 패쇠 : 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다

리스코프 교체 : 특정 메소드가 상위 타입을 인자로 사용한다고 할 때, 그 타입의 하위 타입도 문제 없이 정상적으로 작동을 해야 한다는 것입니다.

의존관계 역전 : 자동차 -> 스노우 타이어 , 자동차 -> 타이어(interface)- 스노우 타이어, 일반 타이어, 광폭 타이어 이런식으로 바꿈

인터페이스 분리의 원칙 : 자신이 사용하는 메소드만 상속 받도록

 

CRC 카드(Class-responsibility-collaboration card)는 객체지향 소프트웨어 설계에서 사용되는 브레인스토밍 툴이다. 일반적으로 디자인을 시작할 때 어떤 객체가 필요하고 그들이 어떻게 상호 연계할지 여부를 결정하는 데 사용한다. 객체,패키지 명등 열거한다.

(세부 연산설계는 아니다) , 클래스의 연산,속성 파악 및 협력 클래스 파악에 이용

 

구현에서는 리팩토링(결과변경없이 구조= 메소드 추출) , 코드품질 향상기법( 코드 인스펙션, 정적 분석, 증명) 

 

테스트는 정적과 동적 테스트로 구분됨 

정적 테스트는 개별 검토, 동료검토, 검토회의(동료끼리)

동적 테스트는 블랙테스트(동등 분할, 경계값 분석,원인 결과,), 화이트 박스(문장 검증, 분기검증,조건검증,분기/조건 검증,다중 조건 검증,경로 검증)

조합 테스트 (페어와이즈 테스트, 모델 기반 테스트, 직교 배열 테스트)

순환 복잡도 = 간선수 -노드수 +2 or 분기수(for,if,while) +1

: 독립적인 경로 수 선형적으로 측정, 원시코드의 구조적인 복잡성을 알아 냄

 

제약(Constraints) - 원인 결과 그래프 

• E exclusive ; 원인1과 원인2 중 많아야 하나가(at most one) 참이 될 수 있음을 의미한다. 즉, 두 원인이 동시에 참일 수 없다.
• I Inclusive ; 원인1, 원인2, 또는 원인3 중 적어도 하나는 (at least one) 참이어야 함을 나타낸다. 즉, 모두가 동시에 거짓일 수는 없다.
• O one and only one ; 원인1과 원인2 중 오로지 하나만 참이어야 함을 나타낸다.
• R Requires ; 원인1일 참이려면 원인2도 반드시 참이어야 함을 나타낸다. 즉, 원인1이 참이면서 원인2가 거짓인 경우는 불가능하다.(a<-b이면 b하려면 a가 필요하다는 것) 

 

그리고 전반적인 개발단계에 맞는 테스트 

단위 -> 통합(하향=스텁,상향=드라이버) -> 시스템 -> 인수 테스트 , 회귀 테스트 등 존재함

 

회귀 버그를 찾는 모든 소프트웨어 테스트 방식은 회귀 테스트라 할 수 있다. 회귀 버그는 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 일반적으로 회귀 버그는 프로그램 변경 중 뜻하지 않게 발생한다.

회귀 테스트로는 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법이 많이 사용된다.

 

 

상향식 통합 테스트 과정

:낮은 수준의 모듈들을 클러스터로 결합 -> 드라이버라는 제어 프로그램의 작성 -> 클러스터의 검사 -> 드라이버를 제거하고 클러스터를 상위로 결합 

 

이후 유지보수

형상관리 (베이스라인 관리): 형상 요소는 새 프로젝트가 시작될 때 파악한다. (형상 식별= 변경관리 및 베이스라인 수립, 제어, 상태보고, 감사)

역공학(낮은 추상수준 구현->높은 수준으로 바꾸게 ) : 자동화 도구, 문서 복원도 가능, 성능 개선이 아님 있는 그대로 분석하는 것 

재공학(개선하기위해 재구조화),재사용이 있다

 

마지막으로 품질보증을 하는데 품질평가 모델이 있다.

1) 소프트웨어 제품 품질 특성을 평가 하거나

2) 프로세스 품질 특성 평가를 하거나 두 개인 것 같다 

 

프로세스 품질 특성 평가에 밑의 CMMI와 SPICE도 속한다.

 

CMMI : 성숙도를 평가하기 위한 모델이며 그 방법을 관례로써 나타내고 있다. 

초기 -> 관리 -> 정의 -> 정량적 관리단계 -> 최적화단계

 

(throw-away) 프로토타입은 최종 시스템의 사용방식과는 일치하지 않는다

 

 

인터페이스 분석 : 모듈 사이의 연계도, 메소드 및 매개변수 분석 

시스템 아키텍처 : 상세 설계도가 아닌 대략적인 것 의사소통 가능하며 요구 사항 고려하여 이해당사자들이 정의한 것 

 

SPICE 단계(=iso 12207(크게 기본,지원,조직 프로세스이다)를 기반으로 함, iso 12207은 소프트웨어 생명주기 표준이다.)

0 : 구현 x

1 : 수행 : 프로세스 수행 및 목적 달성 

2 : 관리 : 수행 계획 및 관리 

3 : 확립 : 표준 프로세스 사용

4 : 예측 : 척도 수집과 분석으로 프로세스가 토제

5 : 최적화 : 프로세스의 지속적 개선 

 

CASE도구 

상위 CASE : 요구분석과 설계를 지원

하위 CASE : 코드작성(구현), 검사(테스트)지원

통합 CASE : 개발 주기 전 과정을 지원

 

 

ATAM : 시나리오 기반하여 소프트웨어 아키텍처를 평가하는 기법

 

McCall의 품질 모델 

: 내부 품질과 외부 품질 요소들의 관계를 설명하는 모델 

ex> 제품 운영

정확성 : 요구,설계 사항 만족시키며 사용자가 원하는대로 수행되고 있는 정도

신뢰성 : 프로그램이 항시 정확하게 동작하고 있는 정도

효율성 : 프로그램의 기능을 수행할 때 요구되는 소요자원의 양

무결성 : 허가되지 않은 사람의 접근을 통제할 수 있는 정도

유용성 : 사용이 용이한 정도

이식성 : 하나의 운영환경에서 다른 환경으로 이동하는데 드는 노력

 

SMI(Software Maturity Index, 소프트웨어 성숙 색인) 

SMI = MT-(Fa+Fc+Fd)/MT

MT = 현재 릴리즈에서 모듈 수 

Fa : 추가된것

Fc : 변경된 것

Fd : 삭제된 것  들의 수

SMI가 1에 가까울수록 제품이 안정되는 것이다. 

 

CORBA(Common Object Request Broker Architecture)

= 분산 컴퓨팅과 객체지향기술을 합침, peer to peer이다. 

 

MVC(=Model view Controller)

MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다.

 

 

IEEE 1042 : 소프트웨어 형상관리, 변경관리하는 것 

슈발.. 1042