제8 강시스템분석 소프트웨어공학 - eduever.comB0%AD%20%BD%C3%BD... · 소단위명세서 {자료흐름도의최하위프로세스가어떤기능을하는 가를기술한것

제제 8 8 강강 시스템분석시스템분석 소프트웨어공학소프트웨어공학제제 8 8 강강 시스템분석시스템분석, , 소프트웨어공학소프트웨어공학

컴퓨터일반컴퓨터일반

http://www.eduever.com1

7 17 1 시스템의시스템의 개요개요7.17.1 시스템의시스템의 개요개요



시스템의 개요

정의

서로 관련 있는 구성요소가 정해진 목적을 달성하기 위서로 관련 있는 구성요소가 정해진 목적을 달성하기 위해 유기적으로 결합된 조직체

특성특성

목적성

제어성제어

제어성

자동성 출력처리입력

종합성

피드백피드백

구성요소


소프트웨어 개념

소프트웨어

프로그램의 개발이나 운영 또는 유지 보수에 관련

되는 모든 정보 포함

소프트웨어 특성

비가시성(invisibility)

복잡성(complexity)복잡성(complexity)

변경 가능성(changeability)

복제성(duplicability)


소프트웨어의 분류

소프트웨어 분류

기능에 따른 분류기능에 따른 분류

—응용 소프트웨어(application software)—시스템 소프트웨어(system software)( y )

개발과정에 따른 분류

—프로토타입(prototype)(p yp )프로그램이 완성되기 전에 사용자의 요구사항을 면밀히 파악하기 위해 표본으로 만들어 사용자들에게 제시하는 예비적 결과물과물

—패키지(package)다수의 사용자들에게 보급할 목적으로 개발하여 상품화한 소프트웨어

—주문형 소프트웨어(custom software)사용자가 특정용도로 사용하기 위해 주문하여 개발된 소프트


사용자가 특정용도로 사용하기 위해 주문하여 개발된 소프트웨어

소프트웨어 공학 개념

IEEE의 정의소프트웨어 공학이란 소프트웨어의 개발, 운용, 소프트웨어 공학이란 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한 체계적인 접근 방법이다

소프트웨어 공학의 목표에 맞춘 정의품질이 좋은 소프트웨어를 최소한의 비용으로 계획된 일정에 맞추어 개발하는 것

하드웨어와 소프트웨어의 비용 구성률


7 27 2 시스템시스템 생명주기생명주기 모델모델7.27.2 시스템시스템 생명주기생명주기 모델모델



시스템 생명주기 모델

일반적인 소프트웨어 생명주기(3단계)

정의 단계정의 단계

—사용자의 유구사항을 정의단계

—타당성 조사, 명세서 작성을 포함하는 시스템 분석 활동

포함

개발 단계

—요구사항과 명세서에 따라 소프트웨어를 만드는 단계

—시스템 설계, 코딩, 테스트 등의 활동 포함

유지 보수 단계유지 보수 단계

—운용도중 생기는 결점(error)을 수정, 개선하는 활동

수정형 적응형 완전형 예방형 유지보수를 포함


—수정형, 적응형, 완전형, 예방형 유지보수를 포함

폭포수 모형(Water fall)

1950년대 항공 방위 소프트웨어 시스템 개발 경험을 토대로

처음 소개됨처음 소개됨

1970년대부터 소프트웨어 공학 교과서나 산업계에서의 표준

문제점

반복과정발생

불확실성

단계별 지연이 발생단계별 지연이 발생


폭포수 모형(Water fall)(계속)

계획

소프트웨어 개발의 실현 가능성을 가늠하는 활동소프트웨어 개발의 실현 가능성을 가늠하는 활동

—타당성 조사를 해서 문제를 명확하게 분석하고 최적의

해결방안을 제시할 수 있어야 함해결방안을 제시할 수 있어야 함

요구분석

개발되는 소프트웨어 시스템의 기능, 제약 조건, 목표 등이 시스템 사용자와 더불어 명확하게 정의되어

야 하는 단계

요구분석의 결과물로 사용자의 요구와 시스템 개발

자들이 요구에 부응하는 것을 확인하는 명세서

(system specification)를 얻게 됨


폭포수 모형(Water fall)(계속)설계

요구분석 단계에서 얻어진 결과물을 가지고 어떻게구분석 단계에서 얻어진 결과물을 가지 어떻게시스템을 구성할 것인가 하는 것이 문제

시스템 구조 설계, 프로그램 설계, 사용자 인터페이설계가 핵심스 설계가 핵심

결과물소프트웨어 시스템의 구조를 나타내는 설계서—소프트웨어 시스템의 구조를 나타내는 설계서

구현앞 단계에서 설계된 모듈들이 실질적인 프로그램으앞 단계에서 설계된 모듈들이 실질적인 프로그램으로 작성됨

원시 코드로 작성된 각 모듈은 단위 테스트를 거쳐서원시 코드로 작성된 각 모듈은 단위 테스트를 거쳐서검정되어야 함


폭포수 모형(Water fall)(계속)테스트

독립적으로 작성된 모듈이나 프로그램들이 설계된 대로 사용자의 요구사항에 적합하게 구현되었는지 확인

통합 테스트각 모듈이나 프로그램들이 하나의 시스템으로 통합되면서 받는— 각 모듈이나 프로그램들이 하나의 시스템으로 통합되면서 받는테스트

시스템 테스트— 통합된 시스템으로 완성된 후에 받는 테스트

알파 테스트시스템 개발팀 또는 개발 회사가 완성된 시스템을 자체적으로 실— 시스템 개발팀 또는 개발 회사가 완성된 시스템을 자체적으로 실제 상황에서처럼 사용해보면서 고객의 승인을 얻기 위해 테스트하는 것

베타 테스트베타 테스트— 개발한 소프트웨어 시스템을 상품으로 출시하기 전에 특정 고객

들을 선정하여 사용해보도록 함으로써 피드백 효과를 노리는 테


스트 방법

폭포수 모형(Water fall)(계속)유지보수

웨어 시 템이 완성되어 인수된 실제 사소프트웨어 시스템이 완성되어 인수된 후 실제로 사

용하는 모든 기간에 걸쳐 이루어지기 때문에 가장

기간이 길고 비용도 많이 드는 단계

오류와 결함 수정 뿐만 아니라 시스템을 운영하면서오류와 결함 수정 뿐만 아니라 시스템을 운영하면서

새롭게 나타나는 개선 사항이나 서비스 요구 등에

부응하기 위한 노력까지 포함


프로토타입 모형

개발자는 추후에 개발될 소프트웨어의 시범 케이스 내지는 본보기로 프로토타입(prototype)을 만들스 내지는 본보기로 프로토타입(prototype)을 만들어 제시

사용자와 개발자가 처음부터 원활하게 의견을 교사용자와 개발자가 처음부터 원활하게 의견을 교환할 수 있다는 장점을 지님

문제점문제점

비효율적 내용포함

시스템개발관리의 어려움


나선형 프로세스 모형


나선형 프로세스 모형(계속)

나선형 프로세스 모형

보엠(Boehm)이 1988년에 제안함보엠(Boehm)이 1988년에 제안함

소프트웨어 개발 과정을 나선형으로 진행시킴

나선형 안에 표시된 원은 소프트웨어의 각 단계를 나타냄

— 목표 수립

— 위험 분석

— 개발

— 평가

위험 분석을 하면서 시스템을 개발함

위험을 사전에 막거나 감소시킬 수 있으므로 대규모 시스

템의 소프트웨어를 개발하는 데 적합한 방법


7 37 3 시스템시스템 개발주기개발주기7.37.3 시스템시스템 개발주기개발주기



시스템 개발주기

계획

요구분석요구분석

설계

구현

테스트테스트

문서화

유지보수유지보수


요구사항 분석

개발할 소프트웨어가 무엇을 수행할 것인지를 명확

하게 정의하게 정의

시스템 설계자들에게 데이터, 인터페이스, 아키텍

쳐를 설계하는 데 필요한 정보 제공

요구사항의 분석 5 단계요구사항의 분석 5 단계

문제 인식(identification)

전개(elaboration)전개(elaboration)

종합(synthesis)

검토(review)

문서화(documentation)


( )

요구사항 분석(계속)

요구사항의 구성

사용자 요구사항

—자연언어나 간단한 도식으로 시스템이 제공할 서비스와 시

스템 운영상의 제약사항을 추상적으로 기술한 것

시스템 요구사항

—시스템이 제공할 서비스와 시스템 운영상의 제약사항들을

보다 구체적으로 기술한 것

—기능적 명세서(functional specification)

소프트웨어 디자인 명세서소프트웨어 디자인 명세서

—시스템 요구사항을 좀더 구체적으로 기술한 것


요구사항 분석(계속)요구사항 명세서 1. 개요

1.1 목적1.2 범위

목표

—개발될 시스템에 대한

1.3 정의1.4 약어1.5 참고문헌

2. 일반적인 사항2 1 제품 기능개발될 시스템에 대한

기술적인 요구사항을 세

밀하게 작성하는 것

2.1 제품 기능2.2 사용자 특성2.3 일반적 제약사항2.4 가정

3 세부 요구사항밀하게 작성하는 것

설계 업무의 기초 문서

3. 세부 요구사항3.1 기능 요구사항3.2 성능 요구사항3.3 인터페이스 요구사항3.4 운영 요구사항

정확할수록 개발된 소프

3.4 운영 요구사항3.5 자원 요구사항3.6 검증 요구사항3.7 인수 테스트 요구사항3.8 문서화 요구사항

트웨어의 품질 향상3.9 보안 요구사항3.10 이식성 요구사항3.11 품질 요구사항3.12 신뢰성 요구사항3 13 유지 보수성 요구사항


3.13 유지 보수성 요구사항3.14 안전 요구사항

요구사항 분석(계속)요구사항 분석 단계

많은 정보를 수집해서 정리해야 함많은 정보를 수집해서 정리해야 함

사용자와 개발자 간의 의사소통 원활해야 함

구조적 분석 기법

—데마르코(DeMarco)가 고안

—시스템을 구성하는 프로세스들 사이의 데이터 흐름에

맞추어 개발될 시스템의 모형을 만드는 것

—도구

자료 흐름도(data flow diagram)( g )

자료 사전(data dictionary)

소단위 명세서(mini


요구사항 분석(계속)자료 흐름도

정보 흐름과 자료가 입력에서 출력으로 이동함에 따라적용되는 변형을 묘사하는 그래픽 모델링 기법

가장 널리 사용되는 시스템 모델링 도구

자료 흐름 모델

자료 흐름도 표기법


요구사항 분석(계속)자료 사전

요구사항 분석 동안에 발견된 데이터 요소에 대한 항목을요구사항 분석 동안에 발견된 데이터 요소에 대한 항목을

정의하기 위한 모델링 도구

개발될 시스템에서 필욯로 하는 모든 데이터 요소들을 정개발될 시스템에서 필욯로 하는 모든 데이터 요소들을 정

리한 목록

시스템에서 사용하는 데이터 구성 요소를 정의하기 위한시스템에서 사용하는 데이터 구성 요소를 정의하기 위한

과정

—자료 흐름도에 나타난 자료 흐름과 자료 저장소의 의미를 명시

—자료 흐름에 따라 이동하는 데이터들의 집합을 명시

—자료 저장소에 있는 데이터들의 집합을 명시

—자료 흐름과 자료 저장소에 있는 정보와 관련된 값들을 명시


—개체 관계도에 있는 관계들에 대한 세부사항을 명시

요구사항 분석 – 자료 사전(계속)

자료 사전 표기법

표기 의미 표기 의미

= 정의 [] 다수 중 하나

+ 순차 ** 주석+ 순차 ** 주석

() 선택적 @ 식별자

{} 반복 | 분리자{} 반복 | 분리자


요구사항 분석(계속)소단위 명세서

자료 흐름도의 최하위 프로세스가 어떤 기능을 하는자료 흐름도의 최하위 프로세스가 어떤 기능을 하는

가를 기술한 것

프로세스 명세서프로세스 명세서

소작업 명세서

소단위 명세서를 작성하는 데 사용되는 방법

—의사결정표(decision table)

—구조적 영어(structured English)

—흐름도(flowchart)

—나씨-슈나이더만(Nassi-Shneiderman) 도표

—전후 조건(pre/post condition)


설계소프트웨어 개발 프로세스 중에서 기술적인 핵심 부분

아키텍처 설계아키텍처 설계

분석단계의 산출물인 자료 흐름도를 기반으로 하여 자료흐름도에 표현된 내용을 프로그램 구조도(structure 흐름도에 표현된 내용을 프로그램 구조도(structure chart)로 변환하는 작업

—변환 흐름을 기반으로 하는 경우

—트랜잭션 흐름을 기반으로 하는 경우

모듈 설계듈 설계

아키텍처 설계를 통해 얻어진 프로그램 구조도의 모듈들에 대해 모듈들 사이의 기능적인 독립성을 확보하기 위해세부적으로 구체화하는 설계 과정

—모듈에 대한 응집도(cohesion)


—모듈들 사이의 결합도(coupling)

설계(계속)데이터 설계

사항 석 단계에서 얻어진 개체요구사항 분석 단계에서 얻어진 개체(entity)들을 프로

그램으로 구현할 데이터 구조로 변환하는 업무

인터페이스 설계

소프트웨어 모듈들 상호간의 인터페이스에 대한 설계소프트웨어 모듈들 상호간의 인터페이스에 대한 설계

소프트웨어와 다른 소프트웨어 또는 장치들과의 인터페

이스에 대한 설계

컴퓨터와 사용자와의 의사교환을 위한 인터페이스 설계컴퓨터와 사용자와의 의사교환을 위한 인터페이스 설계


구현

프로그래밍 언어의 선택

고려해야 할 프로젝트의 특성고려해야 할 프로젝트의 특성

—사용자 요구, 프로그래머 능력, 현재 사용 중인 언어, 컴파일러

의 가용성과 품질, 지원 가능한 개발 도구, 언어의 호환성, 개의 가용성과 품질, 지원 가능한 개발 도구, 언어의 호환성, 개발 경험 등

프로그래밍 언어의 특성래밍 언어의 특성

—표현력, 적합성, 단순성, 명확성, 직교성

구조적 코딩 기법구조적 코딩 기법

제어 흐름을 모두 세 가지 제어 구조(순차, 선택, 반복 구

조)로 표현하는 것조)로 표현하는 것

if then, while, for, case 등의 구문을 사용하면 쉽게 하향


식 프로그래밍을 할 수 있음

구현(계속)코딩 스타일

권장하는 원칙권장하는 원칙—명확하게 작성되어야 한다

—수식이 의미하는 바는 명료해야 한다

—임시 변수의 사용을 피하도록 한다

—혼돈스럽지 않은 변수명을 정해야 한다

일관성 있는 변수명을 사용해야 한다—일관성 있는 변수명을 사용해야 한다

—가독성을 높이기 위해 들여쓰기를 한다

—같은 문장의 반복을 최소화한다같은 문장의 반복을 최소화한다

—코드와 일치하는 주석문을 두어야 한다

—모듈화를 위해 서브프로그램을 이용한다

원시 코드의 문서화소프트웨어의 유지 보수 단계에서 프로그램을 구체적으


로 이해하는 데 필수적

테스트

개발된 소프트웨어 시스템이 사용자들의 요구에

맞는지 실행 결과가 예상한 결과와 정확하게 맞맞는지, 실행 결과가 예상한 결과와 정확하게 맞

는지 또는 어떤 차이를 보이는지를 테스트하고 평

가하는 일련의 과정

오류를 발견하기 위한 과정오류를 발견하기 위한 과정

검증(validation), 검토(verification) 및 품질 보증

(quality assurance)의 의미를 포함

크게 단위 테스트, 통합 테스트, 인수 테스트로 나크게 단위 테스트, 통합 테스트, 인수 테스트로 나

누어 시행


테스트(계속)

단위 테스트(unit test)소프트웨어 시스템의 최소 구성 요소가 되는 모듈들을소프트웨어 시스템의 최소 구성 요소가 되는 모듈들을개별적으로 테스트하는 것

모듈 테스트모듈 테스트

블랙박스 테스트

기능 테스트(f ti l t t)—기능 테스트(functional test)—모듈 프로그램의 입출력과 기능을 시험


테스트 – 단위 테스트(계속)

화이트박스 테스트

—소프트웨어의 구조와 구현내용을 잘 알아야하는 방법—소프트웨어의 구조와 구현내용을 잘 알아야하는 방법

—구조적 테스트(structural test)—유리상자 테스트(glass-box test) 유리상자 테스트(glass box test)


테스트(계속)통합 테스트

개별적인 단위 테스트를 통과한 모듈들을 모아서 전개별적인 단위 테스트를 통과한 모듈들을 모아서 전

체 시스템으로 완성하기 위해 통합적으로 테스트하

는 것는 것

시스템이 예정한 대로 기능을 수행하는지 테스트하

고 모듈들 사이의 인터페이스가 제대로 작동하는지고 모듈들 사이의 인터페이스가 제대로 작동하는지

테스트 하는 것

하향식 테스하향식 테스트(top-down test)

상향식 테스트(bottom-up test)

인터페이스 테스트

스트레스 테스트


스트레스 테스트

테스트(계속)인수 테스트

실질적으로 사용되기 위해 마지막으로 이루어지는실질적으로 사용되기 위해 마지막으로 이루어지는

테스트

개발된 소프트웨어 시스템을 하나의 완성된 제품으

로 보고 사용자들이 제공하는 실제 데이터를 가지고

시스템을 테스트

시스템이 사용자 요구사항에 맞게 제 기능을 하는지시스템이 사용자 요구사항에 맞게 제 기능을 하는지

테스트

알파 테스트알파 테스트

베타 테스트


유지 보수소프트웨어 시스템이 사용자들이 원하는 곳에 인수되고 설치

된 후 일어나는 모든 변경 과정

수정형 유지보수

소프트웨어의 오류를 수정하는 작업

적응형 유지보수

오류가 없더라고 소프트웨어와 관련된 환경적 변화에 적응하도록 소

프트웨어를 재조정하는 일

완전형 유지보수

소프트웨어의 성능을 향상시키기 위해 소프트웨어를 개선하는 작업

예방형 유지보수

앞으로 발생할 수 있는 변경가능성을 수용하거나 개발과정에서 생각

못했던 기능을 추가하기 위해 소프트웨어의 여러 조건들을 수용할 수

있도록 소프트웨어의 구조를 개선하는 등 미리 대비하는 작업


있도록 소프트웨어의 구조를 개선하는 등 미리 대비하는 작업

7.47.4 구조적구조적 분석분석7.5 7.5 구조적구조적 설계설계



IPT 기법(improved programming technique)

프로그램 기술을 향상시키기 위한 테크닉

관리와 기술 양면에서 해결책을 찾기 위한 수단관리와 기술 양면에서 해결책을 찾기 위한 수단

기술측면 : 구조적 코딩

하향식 프로그래밍

설계 보조

HIPOHIPO프로그램 기술 언어

Nassi-Schneiderman chart Nassi-Schneiderman chart


HIPO 시스템 실행 과정인 입력, 처리, 출력을 계층적으로 기술하는 방법

시스템을 설계하거나 문서화하기 위한 도구임

체계화된 문서 작성이 가능하며, 보기 쉽고 알기 쉬움

하향식(Top-Down) 방식을 사용하여 나타냄

개발 과정에서 문서화를 부산물로 얻을 수 있음

도표상에 기능 위주로 입력 내용, 처리 방법, 출력 내용이 제시되므로 시스템의 이해가 쉬움

기능과 자료의 의존 관계를 동시에 표현할 수 있음

유지보수 및 변경이 용이함

도식 목차 ․HIPO에서 지정된 기능을 계층적으로 나타낸 도표

(Visual Table of Contents)

․시스템의 구조와 각 기능의 관계를 도식화한 것으로, 특정 기능을 쉽게찾을 수 있음

총괄 도표 ․시스템 또는 프로그램의 기능을 입력, 처리, 출력 관계로 도표화한 것

(Overview

Diagram)

․사용자의 관점에서 본 시스템 또는 프로그램의 기능과 처리 내용을 나타내는 것

상세 도표 총괄 도표에 나타난 기능을 구성하는 기본 요소들을 상세히 기술한 도표


(Detail Diagram)

프로그램 기술 언어

하향식

HIPO로 정의된 기능을 실행할 때의 순서를 명확화HIPO로 정의된 기능을 실행할 때의 순서를 명확화

의사언어

정해진 문법이 없다

특징 및 효과

특정한 문법과 언어의 제약이 없다특정한 문법과 언어의 제약이 없다

프로그래밍 언어를 모르는 사람도 작성가능

일반인의 적극적 참여가 가능일반인의 적극적 참여가 가능

프로그래밍을 위한 사고의 도구로 사용할 수 있다


문서화의 목적, 시스템 재검토 목적으로 사용

N-S chart

구조적 코딩이 용이

순차구조순차구조

선택구조

반복구조


결합도

두 모듈간의 상호 의존도를 측정하는 것으로, 좋은설계는 모듈간의 결합도를 최소화하여 모듈의 독립설계는 모듈간의 결합도를 최소화하여 모듈의 독립성을 높인 것을 의미

결합도의 순서(약함 강함) 자료 결합도 스탬결합도의 순서(약함 → 강함) : 자료 결합도 → 스탬프 결합도 → 제어 결합도 → 외부 결합도 → 공통 결합도 내용 결합도합도 → 내용 결합도


응집도(Cohesion)

한 모듈 내에 있는 구성 요소의 기능적 관련성을 평가하는 기준으로서 응집도가 높을수록 모듈의 독립가하는 기준으로서, 응집도가 높을수록 모듈의 독립성은 높아짐

응집도의 순서(약함 강함) 기능적 응집도 순응집도의 순서(약함 → 강함) : 기능적 응집도 → 순차적 응집도 → 통신적 응집도 → 절차적 응집도 →시간적 응집도 논리적 응집도 우연적 응집도시간적 응집도 → 논리적 응집도 → 우연적 응집도


구조적 분석과 설계

요구 분석 명세서를 작성하기 위하여 널리 사용되어 오는 IPT 기법 중의하나임

구조적 분석은 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자구조적 분석은 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구 사항을 파악하고 문서화하는 체계적인 분석 기법임

구조적 분석용 도구 :자료 흐름도(DFD) 자료 사전(DD) 소단위 명세서(Mini-Spec.) ( p )개체 관계도(ERD)상태 전이도(STD)

도형 중심의 문서화 도구를 사용함->분석자와 사용자간 대화가 용이도형 중심의 문서화 도구를 사용함 >분석자와 사용자간 대화가 용이

시스템을 하향식으로 세분화함

하향식 분할 원리를 적용하여 분석의 중복성을 배제함

사용자의 요구 사항을 논리적으로 표현하여 전체 시스템을 일관성 있게이해할 수 있음


구조적 분석 도구

자료 흐름도(DFD)시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술하는 분석용 도구로, 버블 차트라고도 함

하향식 분할의 원리를 적용하여 그림 중심으로 표현하향식 분할의 원리를 적용하여 그림 중심으로 표현

처리입력된 자료를 출력으로 변환하는 것

① 자료 흐름:발생지, 종착지, 처리 및 저장소 사이에서 자료의 흐름을 나타냄료의 흐름을 나타냄

② 자료 저장소:시스템 상의 자료를 저장하기 위한 장소

③ 단말 시 템에 필 한 자 가 입력되 발생지와 시③ 단말:시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지를 나타냄

④ 자료처리 자료의 변환


④ 자료처리 : 자료의 변환

자료 사전(DD) 자료 흐름도의 대상의 되는 모든 자료에 대한 기본적인 사항들을 더 자세히 정의하기 위해 사용되는 도구메타 데이터(Meta Data) 또는 데이터의 데이터라고도 함메타 데이터(Meta Data) 또는 데이터의 데이터라고도 함이름을 이용해 정의를 쉽게 찾을 수 있어야 하며, 이름이 중복되어서는 안 됨갱신하기 쉬워야 하며, 정의하는 방식이 명확해야 함중복된 정의가 없어야 함자료 사전의 정의 대상

자료 흐름(Data Flow)을 구성하는 자료 항목, 자료 저장소(Data Store)를 구성하는 자료 항목, 자료에 대한 의미, 자료 요소(Data Element)의 단위 및 값

자료 사전의 기호자료 사전의 기호=자료의 정의{ }자료의 반복+자료의 연결|대체 항목의 나열( )자료의 생략* ... *자료의 설명[ ]자료의 선택[ ]


소단위 명세서(Mini-Spec.)

자료 흐름도상의 최하위 처리 절차를 상세하게 기술하는 데 사용하는 도구로 프로세스 명세서라고도 함하는 데 사용하는 도구로, 프로세스 명세서라고도 함

구조적 언어, 의사 결정표, 의사 결정도를 이용하여기술함기술함


7 67 6 객체지향분석과객체지향분석과 설계설계7.67.6 객체지향분석과객체지향분석과 설계설계



객체지향 기법 관련 용어

속성(Attribute)한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의하는 것으로서 성질, 분류, 식별, 수량 또는 현재 상태 등을 표현함

메소드(Method)객체에 정의된 연산을 의미하며, 객체의 상태를 참조하거나 변경하는 수단이 됨객체에 정의된 연산을 의미하며, 객체의 상태를 참 하거나 변경하는 수단이 됨

클래스(Class)2개 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현하는 요소 즉, 공통된 특성과 행위를 갖는 객체의 집합이라고 할 수 있음 한 클래스를 기준으로 하여된 특성과 행위를 갖는 객체의 집합이라고 할 수 있음. 한 클래스를 기준으로 하여그 기준 클래스의 상위 클래스를 수퍼 클래스, 하위 클래스를 서브 클래스라고 함

인스턴스(Instance)하나의 클래스에 속하는 각각의 객체를 의미하나의 클래스에 속하는 각각의 객체를 의미

인스턴스화(Instantiation)클래스로부터 새로운 객체를 생성하는 행위

메시지(Message) 외부로부터 하나의 객체에 전달되는 메소드(행위)의 요구


객체의 특징

다형성하나의 메시지에 대해 각 클래스가 가지고 있는 고유한 방법으로 응답할 수 있는능력을 의미 즉, 같은 연산자라도 각 클래스에 따라 다른 기능을 수행할 수 있음

상속성(Inheritance)이미 정의된 상위 클래스의 메소드를 비롯한 모든 속성을 하위 클래스가 물려받을이미 정의된 상위 클래 의 메 를 비롯한 든 속성을 하위 클래 가 물려받을수 있는 것을 의미

추상화(Abstraction)불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화시키는 것을 의미

캡슐화(Encapsulation)데이터 구조와 데이터를 조작하는 연산을 하나로 묶어 하나의 모듈 내에서 결합되데이터 구조와 데이터를 조작하는 연산을 하나로 묶어 하나의 모듈 내에서 결합되도록 하는 것을 의미

정보 은닉(Information Hidden)캡슐화된 정보를 외부에 감추는 것을 의미


객체지향 소프트웨어 개발 방법론

객체지향 기술

램 성 의 재사 가능하게 해프로그램 구성 요소의 재사용을 가능하게 해줌

소프트웨어 개발과 고품질 프로그램을 신속하게 만들

수 있게 해줌

객체지향 정신으로 프로그램 분석 설계 구현 단계객체지향 정신으로 프로그램 분석, 설계, 구현 단계

에 이르기까지 객체지향 패러다임에 따라야만 각 단

계가 일관성을 갖게 됨


객체지향 분석

객체지향 소프트웨어 공학의 부분으로 수행되는

첫 번째 기술적인 활동첫 번째 기술적인 활동

객체지향 분석의 기본 원칙

정보 도메인 구체화

모듈 기능 기술모듈 기능 기술

모형 행위 표현

모형들을 세부 사항으로 나타내기 위해 분할

초기 모형들은 문제의 본질을 나타내고 차후의 모기 형 제의 나타내 차후의

형들은 구현의 세부사항들을 나타냄


객체지향 분석(계속)객체지향 분석을 완성하기 위해 필요한 작업

사용자 요구사항은 사용자가 될 고객과 소프트웨어사용자 요구사항은 사용자가 될 고객과 소프트웨어

엔지니어 사이의 의견 교환에 의해 작성되어야 함

클래스들은 식별되어야 함(속성과 방법들이 정의됨)

클래스 계층이 명시되어야 함

객체들 사이의 관계(객체-대-객체)가 표현되어야 함

객체 행위가 모델화 되어야 함객체 행위가 모델화 되어야 함

모형이 완성될 때까지 위의 첫 단계부터 이전 단계

까지 반복적으로 재사용되어야 함


객체지향 설계(object oriented design)시스템 설계

분석 모형을 시스템 설계 모형으로 변환

구성—목표의 정의

—서브시스템 파악

—프로세서와 구성 요소 배정

자료 저장소 정의—자료 저장소 정의

객체 설계시스템을 이루는 객체의 내용을 설계시스템을 이루는 객체의 내용을 설계

구성서비스 정의—서비스 정의

—구성 요소 선택

—재구조화


재구 화

—최적화

객체지향 설계(object oriented design)(계속)객체지향 설계

서브시스템 설계(subsystem design)서브시스템 설계(subsystem design)클래스와 객체 설계(class and object design)메시지 설계(message design)메시지 설계(message design)책임 설계(responsibilities design)


객체지향 테스팅

객체지향 시스템의 테스트 단계

객체와 관련된 연산의 개별적인 테객체와 관련된 연산의 개별적인 테스트

개별적인 객체 클래스 테스트

객체들의 클러스터 테스트

객체지향 시스템 테스트객체지향 시스템 테스트

통합 테스트를 위한 접근 방법

사용 사례 또는 시나리오 기반 테스트

스레드 테스트스레드 테스트

객체 반응 테스트


7 77 7 UMLUML7.77.7 UMLUML



UML(Unified Modeling Language)

UML의 정의

복잡한 소프트웨어 시스템 개발 모델링에 필요한 구성복잡한 소프트웨어 시스템 개발 모델링에 필요한 구성요소를 제시하고 이를 이용한 추상화 방법과 산출물들을 프로젝트 참여자들이 쉽게 이해할 수 있도록 소프트을 프로젝트 참여자들이 쉽게 이해할 수 있도록 소프트웨어 개발방법론(표현 및 기법)들이 통합된 객체지향개발 표준통합 모델링 언어

표준화된 다이어그램을 통하여 소프트웨어 생명 주기전체 단계에서 시스템의 산출물을 가시화하고 명세화하는 모델링 언어

비즈니스 모델링이나 대규모의 복잡한 분산시스템 모델링, 정보시스템 모델링 등을 시각적으로 구체화하고 구축하는 객체지향 모델링 언어


UML(Unified Modeling Language)

UML의 특징각 개발공정에 다양하고 일관성 있는 표현방법을 제공각 개발공정에 다양하고 일관성 있는 표현방법을 제공하고 확장성이 뛰어남

소규모에서 대규모 프로젝트까지 모두 잘 적용할 수 있규 에서 대규 젝 까지 두 잘 적용할 수 있음

UML은 CASE 도구 및 개발프로세스(Unified Process) 지원원

특정 개발 방법론에 얽매이지 않는 개방적이고 독립적표기체계표기체계

별도의 비용이 없는 공개된 표준 모델링 제공

개발자간 의사소통 원활 반복적 점진적 과정개발자간 의사소통 원활, 반복적 점진적 과정

사용자에게 사용하기 쉽고 표현이 풍부한 시각적 모형화 언어 제공


화 언어 제공

4+1 View

Use-Case ViewUse Case View외부 사용자의 관점에서의 기능을 나타냄시스템 행동을 설명최종사용자 분석가 설계자 테스트 담당자에게 제공 되는 뷰최종사용자, 분석가, 설계자, 테스트 담당자에게 제공 되는 뷰시스템 아키텍쳐를 구체화하는 요인들을 명세화Diagramg

— Static : Use-Case Diagram— Dynamic : Communication Diagram, State Chart Diagram, Activity Di

agram


4+1 ViewLogical View

시스템 내부의 structure와 behavior로 functionality가 어떻게 설계되었는지를 표현지를 표현Logical View는 Service관점에서 시스템이 사용자에게 제공해야 하는 기능적 요구사항 표현DiagramDiagram

— Static : Class Diagram, Object Diagram— Dynamic : Sequence Diagram, Communication Diagram, State Chart Diagram

, Activity DiagramImplementation View

개발 환경 내에서 실제 소프트웨어 모듈의 구성과 관련개발의 용이성, 소프트웨어 관리, 재사용, 프로그램언어와 개발 도구에 따, , ,른 제약과 관련되어 파생된 요구사항을 고려시스템 배포의 형상관리 표현물리적인 시스템을 조립하고 배포하는데 사용되는 Component와 File 들로 구성로 구성Diagram

— Static : Component DiagramDynamic : Communication Diagram State Chart Diagram Activity Diagram


— Dynamic : Communication Diagram, State Chart Diagram, Activity Diagram

4+1 ViewProcess View

절차적인 관점Performance, Reliability, Scalability, Integrity, System Management, Synchronization등의 요구사항을 고려Diagram Diagram

— Static : Class Diagram, Object Diagram— Dynamic : Communication Diagram, State Chart Diagram, Activit

y Diagramy DiagramDeployment View

시스템을 컴퓨터와 device의 node로 전개 시켜 표현Deployment Diagram은 시스템에서 서로 다른 node들과 이 node들 간의 연결을 나타내기 위해 생성됨Diagram Diagram

— Static : Deployment Diagram— Dynamic : Communication Diagram, State Chart Diagram, Activit

y Diagram


y Diagram

UML Diagram의 종류

Use-Case Diagram



Use-Case Diagram시스템이 해야 할 행동 명세화를 하고 순서 있는 액션의 집합시스템이 해야 할 행동 명세화를 하고 순서 있는 액션의 집합을 기술한 것으로 Actor에게 해택이 있는 결과를 제공해야 함

사용자의 시각에서 SW 시스템의 범위와 기능을 쉽게 설명하사용자의 시각에서 SW 시스템의 범위와 기능을 쉽게 설명하고 정의한 모델

시스템의 모든 기능에 대한 Use Case와 이와 관련된 Actor들및 이들간의 관계를 표현

고객과 개발자간에 시스템이 무엇을 수행하는지에 대한 명확하고 일관성 있는 정의를 제공하고 일관성 있는 정의를 제공

개발자에게 시스템에 대한 이해를 제공하여 개발을 도와줌

시스템 행동을 조직화하고 모델링시스템 행동을 조직화하고 모델링

시스템의 정적 쓰임새 뷰



Sequence Diagram시스템의 동작을 정형화 하고 객체간의 메시지 교환을시스템의 동작을 정형화 하고 객체간의 메시지 교환을쉽게 표현하고 시간에 따른 메시지 발생순서를 강조한다다.어떤 일을 하기 위해 참여하는 객체들 사이에 일어나는상호작용을 시간 순으로 파악하기 위해 사용됨상호작용을 시간 순으로 파악하기 위해 사용됨

객체들의 집합이 제시간에 상호 작용하는 방법을 표현

메시지의 시간적 순서를 강조메시지의 시간적 순서를 강조



Class Diagram시스템을 구성하는 클래스 구조를 나타내며 객체들의시스템을 구성하는 클래스 구조를 나타내며 객체들의공통구조와 동작을 추상화 하며, Dependency, Association Aggregation Realization 관계를 표현한다Association, Aggregation, Realization 관계를 표현한다.

—시스템에 포함된 객체들의 유형들과 그 클래스들 사이의 정적 관계성을 표현

—한 클래스의 속성과 연산을 표현

—객체들을 연결하는 방법에 적용하는 제약사항을 표현

—클래스, 인터페이스, 협력간의 관계를 나타내며 객체 지향시스템 모형화에서 가장 공통적으로 많이 쓰임

객체들 사이의 행위를 나타내는 것은 S Di 과—객체들 사이의 행위를 나타내는 것은 Sequence Diagram과동일



Communication Diagram특정 메시지 집합 안에 참여하는 객체들의 조직에 초점특정 메시지 집합 안에 참여하는 객체들의 조직에 초점을 두고 있으며 Sequence Diagram과 마찬가지로 설계작업흐름에 적용작업흐름에 적용

객체들 사이의 행위를 나타내는 것은 Sequence Diagram과 동일과 동일

객체들 사이의 정적인 구조에 더 초점



State Diagram시스템의 동적 측면을 모델링 하는 것으로 Object행동시스템의 동적 측면을 모델링 하는 것으로 Object행동모델을 작성한다.

한 객체가 가지는 상태와 사건에 따라 순차적으로 발생하는—한 객체가 가지는 상태와 사건에 따라 순차적으로 발생하는행동에 중점을 두고 작성

—하나의 상태전이 다이어그램에서 객체의 초기 상태를 나타내는 시작 상태는 오직 하나만 존재하며, 객체의 마지막 상태인 종료 상태는 여러 개 존재할 수 있음



Activity Diagram순서도의 일종으로 발생하는 활동을 강조순서도의 일종으로 발생하는 활동을 강조

데이터의 활동이나 흐름, 또는 활동들 사이의 의사 결정을 표현을 표현

하나의 사용사례 내에서 일어나는 활동들을 분할하기위해 사용 가능위해 사용 가능

시스템의 기능을 모형화하고 객체간의 제어 흐름 표현에 유용에 유용

순서나 병렬적인 처리를 요하는 행위를 표현


Object Diagram

Object Diagram 객체들 사이의 관계표현 클래스의 Instance에 대한 정객체들 사이의 관계표현, 클래스의 Instance에 대한 정적 스냅샷

객체들의 상호작용을 정의하기 위해 작성—객체들의 상호작용을 정의하기 위해 작성

—특정 객체들이 전체 클래스 모델의 내용 안에서 사용되는 방법을 나타내기 위해 클래스 다이어그램에 추가 객체들 사이의 관계를 표현


Component Diagram인터페이스를 가지고 자체 실행 가능한 컴포넌트 모임인터페이스를 가지고 자체 실행 가능한 컴포넌트 모임을 표현, 실행 Node에서 실행 가능한 컴포넌트를 명세화

물리적 구성단위 컴포넌트와 그들간의 구성 및 의존 관계를—물리적 구성단위 컴포넌트와 그들간의 구성 및 의존 관계를표현

—시스템의 논리적 모델을 개발자 관점에서 바라본 물리적 모델로 재배치하는 데 사용

—어떤 클래스를 어떤 파일에 넣으면 어떤 파일을 모아 어떤모듈을 만들 것인지 등을 정의하는 것모듈을 만들 것인지 등을 정의하는 것


7 87 8 CASECASE7.87.8 CASECASE



소프트웨어 공학의 발전 동향 - CASE

CASE(Computer Aided Software Engineering)소프트웨어 공학에서 여러 작업들을 자동화하는 것소프트웨어 공학에서 여러 작업들을 자동화하는 것CASE 도구

—소프트웨어 공확과 관련된 여러 작업 중에서 하나의 작업을웨어 공확과 관련된 여러 작업 중에서 하나의 작업을자동화한 소프트웨어 패키지

구분상위 CASE 하위 CASE 통합 CASE—상위 CASE, 하위 CASE, 통합 CASE

원천기술—구조적 기법, 프로토타입 기술, 응용 프로그래밍, 정보 저장, , ,

소, 분산처리기술 등

장점표준화를 쉽게 달성할 수 있다—표준화를 쉽게 달성할 수 있다

—소프트웨어의 품질 향상(일관성과 완벽성 자동 검증)—개발 비용 절약


—생산성 향상

재사용

다른 시스템에서 테스트해보고 검증해본 구성 요소를 바탕으로 새로운 설계를 한다는 의미소를 바탕으로 새로운 설계를 한다는 의미

소프트웨어 개발과 유지 보수 비용을 줄임

시스템을 신속히 개발하여 양도할 수 있음시스템을 신속히 개발하여 양도할 수 있음

소프트웨어의 질적 향상 꾀함

요구분석과 설계 단계에서부터 재사용을 염두에요구분석과 설계 단계에서부터 재사용을 염두에두어야 함

재사용이 가능한 소 웨어의 단위재사용이 가능한 소프트웨어의 단위

응용 시스템 재사용

구성 요소 재사용

함수 재사용


재사용(계속)소프트웨어 설계와 개발 과정에서의 요구사항

재사 이 적절한 성 가 쉽게 발견되어야 함재사용이 적절한 구성 요소가 쉽게 발견되어야 함

구성 요소를 재사용하는 쪽에서는 구성 요소들을 신구성 를 재사용하는 쪽에서는 구성 들을 신

뢰할 수 있어야 함

구성 요소에 대한 내용이 문서화되어 있으면 새로운

용도로 적용시키기가 쉬움


Documents

제8 강시스템분석 소프트웨어공학 - eduever.comB0%AD%20%BD%C3%BD... · 소단위명세서 {자료흐름도의최하위프로세스가어떤기능을하는 가를기술한것