3일차 : 3. 애플리케이션 설계

Dev_HG·2020년 6월 29일
0

1. 공통 모듈 설계

1. 공통 묘듈의 개념

  1. 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드를 의미한다.
  2. 자체적으로 컴파일 가능하고, 다른 프로그램 재사용이 가능하다.
  3. 여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈을 의미하며 날짜 처리를 위한 유틸리티 모듈 등이 해당된다.

2. 공통 모듈 원칙

공통 모듈에 대한 명세를 작성할 때에는 다음의 원칙을 지킨다.
1. 정확성(Correctness) : 해당 기능이 실제 시스템 구현 시 필요한지 아닌지를 알 수 있도록 정확하게 작성
2. 명확성(Clarity) : 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성
3. 완전성(Completeness) : 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술
4. 일관성(Consistency) : 공통 기능 간에 상호 충돌이 없도록 작성
5. 추적성(Traceability) : 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 육기적 관계에 대한 식별이 가능하도록 작성
cf : 컴파일(Compile) : 프로그래밍 언어로 쓰여 있는 원시 코드(Source Code)를 다른 프로그래밍 언어의 목적 코드(Object Code)로 옮기는 기법이다.

3. 모듈화

1. 모듈화(Modulaty) 개념

프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법

2. 모듈화 필요성

  1. 모듈의 크기가 너무 작아 모듈 개수가 많이지면 모듈 간 통합 비용이 많이 발생한다.
  2. 모듈의 크기가 너무 크면 모듈 간의 통합 비용이 줄어드는 대신 모듈 당 개발 비용이 커진다.

4. 모듈화 유형

모듈화의 유형에는 크게 응집도와 결합도가 존재한다.
1. 응집도 : 모듈 내부에서 구성요소 간에 밀접한 관계를 맺고 있는 정도, 응집도가 높을수록 필요한 요소들로 구성되어 있고 낮을수록 관련이 적은 요소
2. 결합도 : 모듈과 모듈 간에 어느 정도 관련성이 있는지를 나태내는 정도, 관련이 적을수록 모듈의 독립성이 높아 모듈 간 영향이 적어짐

5. 응집도 유형

  1. 우연적 응집도(Concidental Cohesion) : 모듈 내부의 각 구성요소들이 연관이 없을 경우
  2. 논리적 응집도(Logical Cohesion) : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 둘에서 처리되는 경우
  3. 시간적 응집도(Temporal Cohesion) : 연관된기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
  4. 절차적 응집도(Procedual Cohesion) : 모듈이 다수의 관련 기능을 가질 대 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
  5. 통신적 응집도(Sequential Cohesion) : 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우
  6. 순차적 응집도(Sequential Cohesion) : 모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용할 경우
  7. 기능적 응집도(Functional Cohesion) : 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

6. 결합도 유형

  1. 내용 결합도(Content Coupling) : 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우
  2. 공통 결합도(Common Coupling) : 파라미터가 아닌 모듈 밖에 선언된 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우
  3. 외부 결합도(External Coupling) : 두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우
  4. 제어 결합도(Control Coupling) : 단순 처리할 대상인 값만 전될되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우
  5. 스탬프 결합도(Stamp Coupling) : 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우
  6. 자료 결합도(Data Coupling) : 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우

설계 모델링

1. 설계 모델링 개념

요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 하는 기법이다.
소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능, 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정이다.

2. 설계 모델링 원칙

소프트웨어 설계는 변경이 쉽도록 구조화 되어야한다.
하나의 함수 안에 특정 기능을 수행하는 데 필요한 자료만 사용하도록 규제 한다.
독립적이고 기능적인 특성을 지닌 모듈 단위로 분할 설계한다.
계층적 구조를 가져야 한다.

3. 설계 모델링 유형

[설계 모델링 유형]
1. 구조 모델링 : 소프트웨어를 구성하는 컴포넌틑들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링, 시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들을 모델링
=> 구성요소 : 프로시저, 데이터 구조, 모듈, 파일 구조
cf : 프로시저(Procedure) : 프로그램을 기능에 따라 여러 개의 단위로 분해하여 작성하는 것으로 크게 서브 프로시저와 함수 프로시저로 구분한다.
cd : 모듈(Module) : 프로그램을 구성하는 구성요소의 일부로 관련된 함수나 변수 또는 클래스를 모아 놓은 파일이다. 모듈은 다른 프로그램에서 불러와서 사용할 수 있다.

[설계 모델링 유형]
1. 구조 모델:
[정적인(static)요소]
구성요소의 유형 및 유형 계통, 구성요소들의 배열, 결합 관계, 구성요소들의 인터페이스, 구성요소들의 상호작용 채널
[동적인(Dynamic)요소]
다이내믹 생성 및 소멸, 동적 결합/연결 , 위치 이동/복제
2. 행위 모델 :
[정적인(Static)요소]
입력 데이터, 출력 데이터, 입출력 매핑, 데이터 흐름 채널
[동적인(Dynamic)요소]
제어, 상태 전이 , 상호작용 프로토콜, 처리 순서, 입출력 순서, 알고리즘

4. 소프트웨어 설계 유형

  1. 자료 구조 설계(Data Structure Design) : 요구 분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 과정
  2. 아키텍쳐 설계(Architecture Design) : 예비 설계 또는 상위 수준 설계, 소프트웨어 시스템의 전체 구조를 기술, 소프트웨어를 구성하는 컴포넌트 간의 관계를 정의
  3. 인터페이스 설계(Interface) : 소프트웨어와 상호 작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지 기술
  4. 프로시저 설계(Procedure Design) : 프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정

3. 소프트웨어 아키텍처

1. 소프트웨어 아키텍쳐(Software Architecture) 개념

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.

2. 소프트웨어 아키텍처의 필요성

주요 이해관계자들 간의 관점 조율을 통한 시스템을 최적화 한다.
아키텍처는 시스템의 비기능적인 요소에 집중해서 만들어지고, 기능적인 요소도 고려한다.

3. 소프트웨어 아키텍처 프레임워크


소프트 웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준이다.

2. 소프트웨어 아키텍처 프레임워크 구성요소

  1. 아키텍쳐 명세서 : 아키텍처를 기록하기 위한 산출물들, 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현, 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등이 있음

  2. 이해관계자 : 시스템 개발에 관련된 모든 사람과 조직 || 고객, 최족사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등을 포함

  3. 관심사 : 시스템에 대해 이해관계자들의 서로 다른 의견과 목표
    사용자 입장 => 기본적인 기능, 신뢰성, 보안, 사용성 등의 품질
    유지보수자 입장 => 유지보수의 용이성
    개발자 입장 => 적은 비용과 인력으로 개발

  4. 관점 : 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식, 이해관계자들이 서로 다른 역할이나 책임으로 시스템이난 산출물들에 대해 보고 싶은 관점

  5. 뷰 : 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현, 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성

  6. 근거 : 아키텍처 결정 근거, 회의 결과, 보고 결과
    cf : 1. Mission : 목적 달성 위해 시스템이 수행하는 방향성
    cf : 2. Environment : 내부/외부 제약
    cf : 3. System : 특정 목적 달성을 위한 컴포넌트 집합
    cf : 4. Architecture : 시스템 구조
    cf : 5. Stakeholder : 사람 / 조직
    cf : 6. Architecture Description : 아키텍처를 기록하기 위한 산출물
    cf : 7. Concern : 관계자 관심사
    cf : 8. View Point : View를 구성하기 위한 규칙을 정의하는 패턴
    cf : 9. View : 모델 작성방법 정의
    cf : 10. Rational : 아키텍처 평가 판단 기준
    cf : 11. Library view point : 모델 작성 방법에 대한 사례
    cf : 12. Model : 모델

4. 아키텍쳐 4+1 뷰

  1. 소프트웨어 아키텍처 4+1 뷰 개념
    고객의 요구사항을 정리해 놓은 시나리오를 4개 관점에서 바라보는 소프트웨어적인 접근 방법이다.
    4개의 분리된 구조로 구성되는 아키텍쳐 개념을 제시하고, 이들 4개 구조가 서로 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기 위해 체크 방법으로 유스케이스르 사용한 것이다.
  2. 소프트웨어 아키텍처 4+1 뷰 구성요소
    4+1에서 1은 유스케이스 뷰이고 4는 논리 뷰. 구현 부, 프로세스 뷰, 배포 뷰다.

최종 사용자----------------------------------------------------프로그래머

프로그매러----------------------------------------------------시스템 엔지니어

[소프트웨어 아키텍쳐 4+1]
1. 유스케이스 뷰(Use-Case View) : 유스케이스는 아키텍쳐를 도출하고 설계하는 작업을 주고, 아키텍쳐 다른 뷰를 검증하는 데 사용
2. 논리 뷰(Logical View) : 시스템의 기능적인 요구사항 지원, 설계 모델의 추상화이며, 주요 설계 패키지와 서브 시스템, 클래스를 식별, 클래스와 이들 간 관계에 대한 집합을 보여주는 클래스 다이어그램으로 표현
3. 프로세스 뷰(Process View) : 런타임 시의 시스템의 태스크(Task), 스레드(Thread), 프로세스(Process)와 이들 사이의 상호작용 등의 관계를 표현, 성능이나 가용성과 같은 시스템의 비기능적인 요구사항을 고려
4. 구현 뷰(Implementation View) : 개발 환경 안에서 정적인 소프트웨어 모듈(소스 코드, 데이터 파일, 컴포넌트, 실행 파일 등)의 구성을 표현,개발자 관점에서 소프트웨어의 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현, 컴포넌트 뷰(Component View)라고도 함
5. 배포 뷰(Deployment View) : 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑되는가를 보여주며, 가용성, 신뢰성, 성능, 확정성 등의 시스템의 비기능적인 요구사항을 고려 || 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현

5. 소프트웨어 아키텍처 비용 평가 모델

  1. 소프트웨어 아키텍쳐 비용 평가 모델
    아키텍쳐 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델

  2. 소프트 아키텍쳐 비용 평가 모델종류

  1. SAAM : Software Architectuure Analysis Method, 변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능
  2. ATAM : Architecture Trade-off Analysis Method, 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가
    cf : 아키텍쳐 품질 속성 : 아키텍처 비용 평가를 위해서 필요한 사항으로 특정 품질에 대한 요구사항을 명세하나 내역, 최적의 아키텍처를 선택하기 위한 핵심요소(품질속성)
  3. CBAM : Cost Benefit Analysis Method, 경제적 의사결정에 대한 요구를 충족, ATAM 바탕의 시스템 아키텍처 분석 중심, 경제적 모델링 방법
  4. ADR : Active Design Review, 소프트웨어 아키텍처 구성요소 간 응집도 평가
  5. ARID : Active Reviews for Intermediate Designs, 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중
profile
꾸준함

0개의 댓글