1-11강. 애플리케이션 설계-공통 모듈 설계(1)

과목1. 소프트웨어 설계, 11강. 애플리케이션 설계-공통 모듈 설계(1)

 

[ 목차 ]

1. 애플리케이션 설계

2. 공통 모듈의 개념

3. 공통 모듈 명세 작성 원칙

4. 모듈화 개념

5. 모듈화의 목적

6. 모듈의 성질

7. 소프트웨어 설계와 모델링의 개념

8. 소프트웨어 설계 프로세스

9. 설계 모델의 구성

10. 구조 모델의 정적, 동적 요소

11 행위 모델의 정적, 동적 요소

 

1. 애플리케이션 설계 

1) 요구사항 확인을 통한 상세 분석 결과, 소프트웨어 아키텍처 가이드라인/산출물에 의거하여 이에 따른 애플리케이션

    구현을 수행하기 위해 공통모듈 설계, 타 시스템 연동에 대하여 상세 설계하는 능력

2) 모듈 : 전체 프로그램 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미하며 자체적으로 컴파일이 가능하고 다른

             프로그램에서 재사용 가능 (=컴포넌트 : 독립적인 서비스를 제공하는 소프트웨어 모듈)

 

2. 공통 모듈의 개념

1) 날짜 처리를 위한 유틸리티 모듈 등과 같이 전체 프로그램의 기능 중 공통적으로 사용할 수 있는 모듈을 의미

2) 업무 기능 분해도를 통해 식별 가능

 

3. 공통 모듈 명세 작성 원칙

1) 정확성 : 실제 시스템 구현 시 필요한지 여부를 알 수 있도록 정확하게 작성

2) 명확성 : 해당 기능에 대한 일관된 이해와 하나로 해석될 수 있도록 작성

3) 완전성 : 시스템의 구현 시 요구사항과 필요한 모든 것을 기술

4) 일관성 : 공통 기능 사이에 충돌이 발생하지 않도록 작성

5) 추적성 : 해당 기능에 대한 유의사항의 출처와 관련 시스템 등 유기적 관계에 대한 식별이 가능하도록 작성

 

4. 모듈화 개념

1) 소프트웨어 설계의 기본 원리로, 소프트웨어를 모듈 단위로 나누는 것

2) 소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리를 용이하게 하여 프로그램을 효율적으로 관리할 수 있

    도록 시스템을 분해하고 추상화하는 기법

3) 모듈의 크기가 과도하게 작은 경우 모듈의 개수가 많아져 모듈 간 통합 비용이 과다 발생

4) 모듈의 크기가 과도하게 크면 모듈 간 통합 비용은 감소하나 하나의 모듈 개발 소모 비용이 증가

구조화 : 문제를 나누고 의미 있는 것 끼리 연결

추상화 : 전체적이고 포괄적인 개념을 설계한 후 세분화, 구체화 시켜나가는 방법

 

5. 모듈화의 목적

1) 소프트웨어 복잡도가 감소하고 변경이 쉬우며 프로그램 구현이 용이

2) OSI 7계층 역시 각각 독립적이며 상호 의존도는 낮기에 모듈이라 볼 수 있음

 

6. 모듈의 성질

1) 응집도

  1] 모듈 내부의 구성 요소간 관계의 밀접 정도 평가, 즉 모듈 안의 요소들이 서로 관련되어 있는 정도

  2] 응집도가 높을수록 필요한 요소들의 구성되고 낮을수록 요소들 간의 관련성이 적은 요소들로 구성

  3] 모듈이 독립적인 기능으로 잘 정의되어 있는 정도

  4] 독립적인 모듈이 되기 위해서는 응집도가 강해야 함

  5] 품질측면에서 가장 높은 품질은 기능적 응집이며 가장 낮은 품질은 우연적 응집도

  6] 우연적 < 논리적 < 시간적 < 절차적 < 교환적 < 순차적 < 기능적

기능적 응집도 Functional
1) 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우
2) 응집도가 가장 높은 경우이며 단일 기능의 요소로 하나의 모듈을 구성
 
순차적 응집도 Sequential
1) 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
2) 두 요소가 하나의 모듈을 구성한 경우

교환적(통신적) 응집도 Communication
1) 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있는 경우

절차적 응집도 Procedural
1) 모듈의 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우
2) 순차적 응집도와 다르게 어떤 구성 요소의 출력이 다음 구성 요소의 입력으로 사용되지 않음

시간적 응집도 Temporal
1) 연관된 기능이라기 보다 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우

논리적 응집도 Logical
1) 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우

우연적 응집도 Coincidental
1) 모듈 내부의 각 구성 요소들이 연관이 없을 경우

2) 결합도

  1] 모듈과 모듈 사이의 관련성이 어느 정도인지 즉, 상호의존도를 나타냄

  2] 관련성이 적을수록 모듈의 독립성이 높아 모듈간 영향이 작아짐

  3] 독립적인 모듈이 되기 위해서는 결합도가 약해야 함

  4] 품질 측면에서 가장 높은 품질은 자료 결합이며, 내용 결합이 가장 낮음

  5] 데이터 > 스탬프 > 제어 > 외부 > 공통 > 내용

자료 결합도 Data
1) 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어나는 경우
2) 모듈들이 데이터 요소(매개변수, 파라미터)를 통해 데이터만 주고받으면 서로 간섭을 최소화
3) 모듈 간의 독립성이 보장, 관계가 단순해 하나의 모듈 변경 시 다른 모듈에 미치는 영향 작음
4) 유지보수 높음

스탬프 결합도 Stamp
1) 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우
2) 두 모듈 사이에서 정보를 교환할 때 필요한 데이터만 전달할 수 없고 필요없는 데이터까지 전달
3) 하나의 데이터 정보만 필요해도 자료 구조에 대한 정보를 알아야 함
4) c언어의 구조체는 몇 개의 데이터 요소의 모임으로 이루어져 있는데, 어떤 모듈을 호출할 때 구조체를 매개변
     수로 넘기면 받은 모듈에서 원하지 않는 다른 요소까지 받아야 함

제어 결합 Control
1) 처리할 대상인 값만 전달되는 것이 아닌 어떻게 처리해야 하는지 제어 요소(제어 플래그)가 전달되는 경우
2) 제어 결합은 정보은닉을 크게 위배하며, 다른 모듈의 내부에 관여하기에 관계가 복잡함
3) 유지보수 매우 어려움

외부 결합 External
1) 어떤 모듈에서 외부로 선언한 데이터를 다른 모듈에서 참조할 때의 결합도
2) 두 개의 모듈이 외부에서 도립된 데이터 포멧, 통신 프로토콜, 디바이스 인터페이스를 공유할 때 발생
3) 모듈 간 결합이 심각, 한 모듈이 다른 모듈 내의 요소들을 참조하고 동시에 이런 요소들이 다른 모듈에 개방

공통 결합 Common
1) 공통 데이터 영역을 사용하는 경우
2) 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용
3) 지역 변수 : 모듈 안 선언
4) 전역 변수 : 모듈 밖 선언
5) 애인끼리 공동 관리 토장을 공통으로 사용
6) 전역 변수 값이 변하면 모든 모듈이 함께 영향을 받음
7) 공통 영역에서 문제가 발생하거나 데이터가 변경되면 관련된 모듈을 모두 검토해야 하므로 유지보수 어려움
8) 따라서 꼭 필요한 경우만 데이터를 공유하여 공통 기억장소를 최소화해 독립성을 보장해야 함
      즉, 데이터들을 개별 모듈 내부에서 선언

내용 결합 Content
1) 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우

7. 소프트웨어 설계와 모델링의 개념

1) 소프트웨어 설계

  1] 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 단계

  2] 장치, 프로세스, 시스템을 명확하고 상세하게 정의하며 실현가능 하도록 관련 기술과 원칙을 적용하는 과정

  3] 요구사항 분석(무엇을)으로부터 설계(어떻게)로 관점이 바뀌며 구현할 소프트웨어의 청사진을 만드는 것

2) 설계 모델링

  1] 소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능외에 구조 및 동적 행위들을 모델링

      하여 표현, 분석, 검증하는 과정

  2] 구조(정적) 모델링 : 클래스, 오브젝트(객체), 컴포넌트, 디플로이먼트

  3] 행위(동적) 모델링 : State, Sequence, Collaboration, Activity

 

8. 소프트웨어 설계 프로세스

1) 요구명세 

  1] 기능적 요구 : 시스템이 반드시 수행해야 되는 기능들

  2] 품질적 요구 : 성능, 보안

  3] 형태적 요구 : 일정한 구성 체계를 가진 형식이나 요소에 관련된 것

2) 모델링

3) 분석

4) 명세화 : 세세한 내용을 낱낱히 밝힘

5) 검증

6) 2~5 반복

7) 상세 설계 명세

  1] 행위/구조 모델

  2] 시험결과

  3] 시험계획/명세

구조 모델링
1) 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 연결 구조를 모델링
2) 시스템의 구성 요소들과 이들 사이의 구조적인 관계와 특성들의 모델링
3) 구성요소 : 프로시저, 데이터구조, 모듈, 파일구조
4) 시스템 구조 : 구성 요소들의 연결 구조, 포함관계
5) UML 정적 다이어그램
6) 컴퓨터 구성 요소 : CPU, 메모리, 사운드 카드
7) 컴퓨터 시스템 구조는 각 구성요소의 연결 구조와 관계

행위 모델링
1) 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행해야 작용하는지를 모델링
2) 시스템의 각 구성 요소들의 기능적 특성들에 대한 모델링
3) 시스템의 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들의 모델링
4) 입/출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등
5) 상태전이, 데이터 흐름경로, 사건발생 순서, 실행 경로 등
6) 예시 기능 : 계산기 프로그램 데이터 
7) 예시 순서 : 계산기 프로그램 실행 순서
8) UML 동적 다이어그램

9. 설계 모델의 구성

10. 구조 모델의 정적, 동적 요소

1) 정적 요소

  1] 구성 요소의 유형 및 유형계통

  2] 구성 요소들의 배열, 결합 관계

  3] 구성 요소들의 인터페이스

  4] 구성 요소들의 상호 작용 채널

2) 동적 요소

  1] 동적 생성 및 소멸

  2] 동적 결합/연결

  3] 위치 이동, 복제

 

11 행위 모델의 정적, 동적 요소

1) 정적 요소

  1] 입력/출력 데이터

  2] 입출력 맵핑

  3] 데이터 흐름 채널

2)동적 요소

  1] 제어

  2] 상호작용 프로토콜

  3] 상호 작용 실행 경로

  4] 상태전이

  5] 처리순서, 입/출력 순서, 알고리즘