(사)정보화사회실천연합

소프트웨어 디자인

0 1,432

요구사항 분석(Requirement Analysis)

– 전통적 소프트웨어 개발 방법은 과거의 경험을 토대로 여러 방법들을 집대성 하여 정형화 한 것.

– 전통적(고전적) 소프트웨어 개발 방법을 구조적 소프트웨어 개발방법 이라고도 한다.

– 요구사항 분석은 사용자의 요구 사항을 이해하고 문서화하는 활동을 의미

– 문제 인식–>평가와 종합–>모델제작(프로토타입)–>문서화와 검토

– 요구사항 분석은 사용자와 개발자의 지식 차이 등으로 의사소통이 곤란하여 어렵다.

이를 해결하기 위해 다이어그램 또는 프로토 타입을 이용 할 수 있다.

– 시스템이 복잡해 지는 것은 요구 사항 분석을 어렵게 만든다. 객체 지향분석 등으로 해결 가능하다.

– 요구사항이 문서화하기 까다로운 것도 요구사항 분석이 어려운 이유다. 제도적인 기술이 필요하다.

– 요구사항 분석가는 많은 경험과 해박한 지식, 계획 파악능력과 고객관점에서의 마인드가 필요하다

구조적 분석 기법 : 도형중심의 분석용 도구와 분석 절차를 이용하여 요구사항을 파악한다.

도형 중심의 도구를 이용하기 때문에 사용자 간의 대화가 용이하다.

구조적 분석도구

– DFD(Data Flow Diagram) 자료 흐름도

– 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화 된다.

– 자료는 처리(Process)를 거쳐 변환될 때마다 새로운 이름이 부여된다.

– 자료흐름도의 세분화는 요구분석이 진행됨에 따라 보다 자세한 흐름도를 작성하는 것이다.

– 레벨 별로 분류가 되며 Level 0의 자료흐름도를 배경도 라고 한다.

– DFD의 세분화는 각각의 프로세스에 대하여 개별적인 상세화를 가능케 한다.

– 세분화 단계가 많아질수록 소프트웨어 설계와 구현작업이 용이해진다.

Data Dictionary (DD) 자료사전

– 자료사전은 자료흐름도(DFD)에 있는 자료를 더 자세히 정의하고 기록한 것으로 데이터의 데이터 또는 메타 데이터(Meta data) 라고 한다.

– 정의 부분과 설명부분으로 나뉘며 정의의 이름이 중복되어서는 안 된다.

= : 자료의 정의 ~로 구성되어 있다.

+ : 자료의 연결. 그리고의 의미

( ) : 자료의 생략. 생략가능한 자료

[ | ] : 자료의 선택. 또는(or)의 의미

{ } : 자료의 반복.

* * : 주석 (Comment)

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

– 자료흐름도에서 최하위 단계 버블(플세스)의 처리 절차를 기술한 것으로 프로세스 명세서.

– 소단위 명세서는 분석가의 문서이며, DFD를 지원하기 위해 작성된다.

– 구조적 언어와 의사결정표(판단표)등을 이용하여 기술된다.

Entity Relationship Digram (ERD) 개체관계도

– 개체 관계도는 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체관의 관계를 표현.

– 개체 관계도는 개체, 속성, 관계 등으로 구성된다.

State Transition Diagram (STD) 상태전이도

– 상태전이도는 시스템에 어떠한 사건이 발생할 경우 그 상태에 초점을 맞추어 모델링 한것.

– 사각형은 시스템의 상태를, 화살표는 상태전이를 나타낸다.

소프트웨어 디자인(Software Design)

구조적 설계기법

– Module : 하나의 배포 단위가 될만한 S/W단위.

– 구조적 설계 기법은 모듈, 프로그램 구조를 설계하기 위한 전략, 문서화 도구 등을 제공하는 체계화된 기법으로 자료흐름 중심 설계 기법이라고도 한다.

– DFD, DD, ERD, Mini Spec. 등이 준비된 이후에 설계 한다.

– 설계 : 설계는 요구사항 분석명세서의 기능이 구현되도록 처리될 자료구조를 문서화하는 것이다

– 설계는 소프트웨어의 품질평가를 위한 지침이 된다.

– 소프트설계 모형은 데이터 설계, 구조 설계, 인터페이스 설계, 프로시저 설계로 구성된다.

– 데이터 설계 : ERD를 이용하여 정의된 개체와 관계, 자료사전에 정의된 자료의 설명 등이 기초가 됨.

– 구조설계 : 모듈간의 관계와 프로그램 구조를 정의하는 것으로 DFD, DD, STD등과 모듈의 상호 작용을 토대로 만든다.

– 인터페이스 설계 : 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신 하는지를 기술하는 것으로 DFD등이 인터페이스의 설계에 기초가 된다.

– 프로시저 설계 : 모듈이 수행할 기능을 절차적 기술로 바꾸는 구체적인 단계로서 소단위 명세서, 상태 전이도 정보가 Procedure 설계의 기초가 된다.

설계의 기본원리

Modularity (모듈화)

– 모듈화는 소프트웨어를 모듈 단위로 나누는 것을 의미 한다.

– 모듈화를 이용하여 설계 하면 확장성, 융통성, 경제성등이 향상 된다.

Abstraction (추상화)

– 포괄적인 개념부터 설계한후 차츰 구체화 시켜 나가는 설계 방법이다.

– 추상화의 유형으로 함수를 통하여 입력과 출력의 개념을 정리 하는 기능 추상화와 제어의 개념을 추상화한 제어 추상화와 자료를 클래스화 시키는 자료추상화가 있다.

– Sepwise Refinement(단계적 정제) : 하향식 설계 전략으로, 상위부터 추상화를 반복하여 구현.

Information Hiding (정보은닉)

– 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근, 변경 못하게 하는 것.

– 다른 모듈이 필요에 의해 접근할 때는 허용된 정보만 전달.

– 모듈이 독립적으로 수행되고, 변경되어도 다른 모듈에 영향을 안주므로 수정, 시험 및 유지보수가 용이 하다.

Program Stucture (프로그램 구조)

-소프트웨어의 구성 요소인 모듈의 계층적 구성을 나타내는 것으로 제어 계층 구조(Control hierarchy structure) 라고도 한다.

– 반복, 순서, 선택과 같은 소프트웨어의 절차적인 처리 과정을 나타내지 않는다.

– 프로그램 구조는 일반적으로 트리구조의 다이어그램으로 표현한다.

– Fan – in(공유도) : 어떤 모듈을 제어하는 모듈의 수를 나타낸다.

– Fan -out(제어도) : 어떤 모듈에 의해 제어되는 모듈의 수를 나타낸다.

– Depth(깊이) : 제어의 계층(hierarchy) 수를 나타낸다.

– Width(넓이) : 제어의 분기된 수를 나타낸다.

– Subordinate(종속적 모듈) : 어떤 모듈에 의해 제어되는 모듈을 나타낸다.

Data Structure(자료구조)

– 자료구조는 자료 사이의 논리적인 관계를 표현한 것으로 자료의 구성, 결합 정도 등을 나타낸다.

– 자료구조의 종류에는 스칼라 항목, 벡터, 연결리스트, 계층적 자료 구조 등이 있다.

바람직한 설계의 특징

– 설계를 소프트웨어 구조를 나타내야 하며 독립적인 모듈들로 구성되어야 한다.

– 설계는 논리적 요소로 분리되는 구조를 가져야 한다.

– 설계에서 계층적 자료조직이 제시되어야 하며 프로시저에 대해 분명하고 분리된 표현을 써야 한다.

– 복잡성을 줄이는 인터페이스를 가져야 하며, 요구분석에서 얻어진 정보를 이용해야 한다.

– 요구사항을 모두 구현해야 하고, 유지보수가 용이해야 한다.

– 결합도는 낮추고 응집도는 높아야 한다.

– 전체적인 개념을 설계한 후 차례대로 세분화 하여 구체화 시켜 나간다.

Module and Modularity

– 모듈화는 소프트웨어를 각 기능별로 분할 하는 것을 의미하며, 분할 된 것을 모듈이라 한다.

– 모듈화를 수행하면 소프트웨어의 복잡도가 감소하고, 프로그램 구현이 용이하다.

– 모듈의 속성 : 입출력요소, 기능요소, 기관요소, 내부자료 요소

– 모듈의 구성 : 호출 모듈, 피 호출 모듈

– 모듈이 기능적 독립성을 가지는 것은 모듈화, 추상화, 정보 은닉의 결과 이다.

– 모듈의 독립성은 결합도(Coupling)과 응집도(Cohension)에 의해 측정되며, 독립성을 높이려면 모듈의 결합도를 약하게 하고 응집도를 강하게 하며 모듈의 크기를 작게 만들어야 한다.

Coupling (결합도)

– 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미 한다.

– 결합도가 높으면 시스템 구현 및 유지 보수가 어렵다.

– 다음 숫자의 순서대로 결합도가 약한 순으로 정리한다.

(자료결합도 < 스탬프 결합도 < 제어결합도 < 외부 결합도 < 공통결합도 < 내용결합도)

1. Data coupling : 파라미터의 전달방식. 다른 모듈에 영향 끼치지 않는 바람직한 결합도

2. Stamp coupling : 두 모듈이 동일한 자료 구조를 조회 할때의 결합도로 실제로 자료구조를 조회 하지 않는 모듈에도 영향을 미친다.

3. Control coupling : 제어가 엉킨 형태로, 하위 모듈이 상위 모듈에게 처리 명령을 부탁함.

4. External coupling : 외부 결합도는 외부로 선언한 데이터를 다른 모듈에서 참조할 때의 결합도.

5. Common coupling : 전역변수처럼 공통 데이터 영역을 여러 모듈이 사용하는 결합도.

6. Contect coupling : 다른 모듈의 기능 및 자료를 직접 참조하거나 수정하는 결합도로서 가장 결합도가 높다.

Cohension (응집도)

– 응집도는 정보 은닉 개념을 확장한 것으로 모듈이 독립적인 기능으로 정의 되어있는 정도를 의미

– 독립적인 모듈이 되기 위해서는 응집도가 강해야 한다.

– 다음의 숫자 순서대로 응집도가 강한 순서이다.

기능적응집>순차적응집>교환적응집>절차적응집>시간적응집>논리적응집>우연적응집

1. Functional cohension : 모듈의 모든 기능이 독립적으로 수행됨.

2. Sequential cohension : 모듈의 데이터 교환이 파라미터를 통해 이루어짐.

3. Communication cohension : 동일한 입출력을 사용하여 다른 기능을 수행하는 서로 다른 모듈.

4. Procedural cohension : 절차적으로 다른 모듈들과 연관되어 수행 되는 정도.

5. Temporal cohension : 특정시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성함.

6. Logical cohension : 유사한 성격을 갖거나 특정형태로 분류되는 것들이 하나의 모듈로 뭉침

7. Coincidental cohension : 모듈의 내부가 관련 없는 것들 로만 이루어짐 (전체메인문)

효과적인 모듈화 설계 방안

– 결합도는 줄이고 응집도는 높여서 모듈의 독립성을 높인다.

– 중복성을 줄이고 일관성을 유지 시킨다.

– 모듈의 기능이 예측 가능해야 하고, 이해하기 쉬운 크기로 분해해야 한다.

– 하나의 입력통로와 하나의 출력 통로가 존재 하게 해야 한다.

– 모듈 인터페이스를 설계해야 한다.

SoftwareDesign

– 자료설계 : 첫번째 작업으로 정보은닉과 자료 추상화의 개념이 도움을 준다.

– 구조설계 : DFD를 작성하여 전반적 계층 구조를 설계한다. DFD를 기반으로 구조 도표(Structure chart)를 만든다. 구조 도표는 모듈의 호출 관계를 나타낸 것.

– 인터페이스 설계 : 사용자와 통신 하는 UI 또는 사용자 입장의 인터페이스를 만든다.

– 절차(Procedure) 설계 : 데이터, 아키텍쳐, 인터페이스 설계가 끝난 뒤에 이루어 지는 설계로 코드수준에 가까울 정도로 구체적인 모듈 명세서를 작성한다. 프로그램 설계 언어 등이 이용된다.

흐름도와 n-s 차트와 같은 그래픽 설계 표기법이 있다.

Flow chart

– 순차, 선택, 반복과 같은 논리적 흐름 절차를 따르며, 절차 설계이므로 자세한 내용을 다룬다.

Nassi-Schneiderman Chart(N-S Chart)

– 논리의 기술에 중점을 둔 모형을 통하여 연속, 선택 및 반복 등 제어 논리 구조를 표현한다.

– Goto나 화살표를 사용하지 않으며, 시각적이지만 작성하기 어렵다.

– 단일입구와 단일 출구로 표현한다.

Program Design Language(PDL)

– 의사코드라고도 부르며 영어를 이용하여 구조적 프로그래밍의 제어 구조를 기술 함.

– 사용자와의 의사소통을 용이하게 만들며, 문법의 제한 없이 자유롭게 표현 가능하다.

글을 남겨주세요.