05. 공통 모듈 설계
설계 모델링
개념
소프트웨어를 구성하는 모듈들을 식별하고, 이것들의 연결을 그림으로 표현한 것
소프트웨어를 만들기 위한 계획 또는 만들어야 할 물건을 의미있게 표현한 것
소프트웨어에 대하여 여러 엔지니어들이 공통된 개념을 공유하는데 도움을 줌
원칙
소프트웨어 설계는 변경이 용이하도록 구조화되어야 함
한 함수 안에 특정 기능을 수행하는 데 필요한 자료만을 사용하도록 함
요구사항 분석에서 얻은 정보를 이용하여 반복적 방법을 통해 이루어져야 함
독립적이고 기능적인 특성들을 지닌 모듈 단위로 설계되어야 함
절차 및 유형
요구사항 명세아키텍처 설계 & 시스템 아키텍처: 시스템을 구성하는 서브시스템들과 그들 간의 관계를 파악하고 명세데이터베이스 설계 & 명세: 시스템 구현에 사용되는 데이터의 구조를 자세하게 설계하고 명세서브시스템 설계 & 명세: 각 서브시스템이 담당하는 서비스와 제약사항들에 대해 명세컴포넌트 설계 & 명세: 서브시스템이 수행하는 기능을 여러 컴포넌트에 할당하고, 컴포넌트들의 인터페이스를 설계하고 명세자료구조/알고리즘 설계 & 명세: 클래스에 대한 여러 가정을 공유하도록 명세
선행 조건: 컴포넌트 오퍼레이션 사용 전에 참이 되어야 할 조건
결과 조건: 사용 후 만족되어야 할 결과 조건
불변 조건: 오퍼레이션이 실행되는 동안 항상 만족되어야할 조건
종류
상위 설계
예비 설계로 전체적인 구조를 설계
아키텍처 설계, 데이터 설계, 시스템 분할, 인터페이스 설계, 사용자 인터페이스 설계
하위 설계
소프트웨어 내부 구조를 상세히 설계
각 모듈의 실제적인 내부를 알고리즘 형태로 표현
모듈 설계, 자료구조 설계, 알고리즘 설계
원리
분할과 정복 | Divide & Conquer
규모가 큰 소프트웨어를 여러 개의 작은 서브 시스템으로 나눔
하나의 일을 수행할 때 작은 단위로 나누고, 작은 단위를 각각 하나씩 처리하여 전체 일을 끝냄
추상화 | Abstraction
특정한 목적과 관련된 필수 정보만 추출하여 강조하고, 관련이 없는 세부사항을 생략함으로써 본질적인 문제에 집중할 수 있도록 함
자세한 구현 전에 상위 레벨에서 제품의 구현을 먼저 생각해보는 것
과정 추상화: 자세한 단계를 고려하지 않고 상위 수준에서 수행 흐름만 먼저 설계하는 것
데이터 추상화: 데이터 구조를 대표할 수 있는 표현으로 대체하는 것
제어 추상화: 여러 명령들을 간단한 표현으로 대체하는 것
단계적 분해 | Gradual Decomposition
- 기능을 점점 작은 단위로 나누어 점차적으로 구체화 하는 방법
모듈화 | Modulization
- 실제로 개발할 수 있는 작은 단위로 나눔
정보 은닉 | Information Hiding
- 다른 객체에게 자신의 정보를 숨기고, 자신의 연산만을 통해 접근이 가능하도록 함
- 독립성 유지 -> 요구사항 등 변화에 대처하여 수정 가능
- 다른 모듈의 구현에 영향을 받지 않음
- 클래스 외부에서 특정 정보(IP, 상세 데이터 주소 등)에 대한 접근을 막는다는 의미
- 캡슐화와 밀접한 관계
유형
구조 모델링
소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 연결 구조를 모델링
시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들의 모델링
UML 정적 다이어그램
행위 모델링
소프트웨어의 구성요소들의 기능이 언제, 어떠한 순서로 기능을 수행해야 작동하는지를 모델링
시스템의 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들의 모델링
UML 동적 다이어그램
소프트웨어 아키텍처 | Software Architecture
개념
소프트웨어의 골격이 되는 기본 구조
소프트웨어 요소와 이들 요소의 외부 속성, 그리고 이들 사이의 관계를 구성하는 시스템의 전체적 구조
시스템의 컴포넌트와 이들 사이의 관계 그리고 이들의 설계 및 변경에 대한 원리와 가이드라인을 정의한 구조
한 가지 다이어그램으로 결정되지 않으며 여러 관점의 다이어그램으로 이루어짐
설계 과정
- 설계 목표 설정
- 시스템 타입 결정
- 스타일 적용 및 커스터마이즈
- 서브시스템의 기능, 인터페이스 동작 작성
- 아키텍처 설계 검토
품질속성
정확성 | Correctness : 소프트웨어가 사용자의 요구기능을 충족시키는가?
신뢰성 | Reliability : 기능이 오차나 오류 없이 동작하는가?
효율성 | Efficiency : 기능을 수행하는데 적절한 자원이 소요되는가?
무결성 | Integrity : 허용되지 않는 사용이나 자료 변경을 제어하는가?
사용 용이성 | Usability : 쉽게 배우고 사용할 수 있는가?
유지보수성 | Maintainability : 변경 및 오류 교정 시 쉽게 수정할 수 있는가?
시험 용이성 | Testability : 개선, 유지보수 등에 있어서 테스트를 하기 용이하게 되어 있는가?
유연성 | Flexibility : 새로운 요구사항에 대해서도 쉽게 개선 및 적용이 가능한가?
이식성 | Portability : 다양한 플랫폼 및 하드웨어에서 동작하는가?
재사용성 | Reusability : 개발된 기능을 다른 목적으로 사용하기 용이한가?
상호운용성 | Interoperability : 다른 소프트웨어와 상호 교류가 용이한가?
특징
간략성 : 이해하고 추론할 수 있을 정도의 간결성 유지
추상화 : 시스템의 추상적인 표현을 사용
가시성 : 시스템이 포함해야 하는 것들을 가시화
관점 모형 : 이해당사자의 관심사에 따른 모형 제시
의사소통수단 : 이해당사자 간 원활한 의사소통 수단으로 이용
프레임워크 구성요소
아키텍처 명세서 | Architecture Description
- 아키텍처를 기록하기 위한 산출물
이해관계자 | Stakeholder
소프트웨어 시스템 개발에 관련된 모든 사람과 조직
고객, 개발자, 프로젝트 관리자 등 포함
관심사 | Concerns
- 동일한 시스템에 대해 서로 다른 이해관계자 의견
- ex) 사용자 : 기본적인 기능, 신뢰성, 보안 등의 요구
관점 | Viewpoint
- 서로 다른 역할이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점
뷰 | View
- 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현
4+1 View
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
복잡한 소프트웨어 아키텍처를 다양한 이해관계자들이 바라보는 관점
View는 시스템의 여러 가지 측면을 고려하기 위한 다양한 관점을 바탕으로 정의
구성요소
논리적 관점 | Logical View: 분석사 & 설계자클래스나 컴포넌트의 종류와 관계
- 시스템의 기능적인 요구사항
- 시스템이 최종 사용자를 위해 해야하는 것을 나타냄
구현 관점 | Implementation View: 프로그래머서브시스템의 모듈 구조와 관계
- 개발 환경 안에서 정적인 소프트웨어 모듈의 구성
- 개발자 관점에서 소프트웨어 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현
- 물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈이 어떻게 구조화되어 있는가에 초점
프로세스 관점 | Process View: 시스템 통합자시스템의 성능, 확장성, 효율
- 시스템에서 사용하는 소프트웨어 서브시스템의 모듈이 어떻게 구조화 되어있는지에 초점
- Thread와 Process에 의한 동작을 중점적으로 표현
- 동시성, 분산처리, 시스템 통합, 오류 허용 등을 표현
배치 관점 | Deployment View: 시스템 엔지니어시스템의 구성
- 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑 되는가를 표현
- 시스템을 구성하는 처리장치 간의 물리적 배치에 초점
- 가용성, 신뢰성, 성능, 확장성 등의 시스템의 비기능적인 요구사항 고려
- 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현
유스케이스 관점 | Use Case View: 사용자기능
- 아키텍처를 도출하고 설계하는 작업을 주도하는 뷰
- 다른 뷰를 검증하는데 사용
- Use Case Diagram이 사용
- +1에 해당하며 유스케이스가 나머지 4개 뷰에 모두 참여하면서 영향을 줌
평가
아키텍처의 접근법이 품질속성(보안, 성능, UI 등)에 미치는 영향을 판단하여 아키텍처 적합성을 판단하고 평가하는 표준 기법
- 가시성
- 가시적 평가 : Inspection, Review, Validation & Verification
- 비가시적 평가 : SAAM, ATAM, CBAM, ARID, ADR
- 시점
- 이른 평가 : 아키텍처 구축과정 중 어느 때나 평가 가능
- 늦은 평가 : 기존 시스템의 요구사항에 대한 아키텍처의 적합성을 판단할 때 사용
Pattern
Layerd pattern
- n-티어 아키텍처 패턴
- 하위 모듈을 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용
- 각 서브 시스템이 하나의 계층이 되고 하위층이 제공하는 서비스를 상위층의 서브 시스템이 이용할 수 있는 구조
- 수직적 계층으로 구분, 각 계층은 서비스의 집합을 제공
- ex) OSI 7계층, TCP/IP 4계층
Client-Server Pattern
다수의 클라이언트와 하나의 서버로 구성
서버는 클라이언트에게 서비스를 제공하며 데이터를 관리하는 역할
ex) 일반적인 웹 프로그램
Master-Slave Pattern
마스터 컴포넌트가 동등한 구조의 슬레이브 컴포넌트로 작업을 분산하고, 슬레이브가 결과값을 반환하면 최종 결과값을 계산하는 구조
실시간 시스템에서 사용하며 슬레이브 프로세스는 수집기능을 수행하지 않음
ex) 컴퓨터와 주변장치
Pipe-Filter Pattern
데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
필터 컴포넌트에서 각 처리과정을 실행하며, 처리된 데이터는 파이프를 통해 전송
데이터는 파이프를 통해 한 쪽 방향으로 흐르며, 필터 이동 시 오버헤드가 발생
서브시스템이 입력데이터를 받아 처리하고, 결과를 다음 서브시스템으로 넘겨주는 과정을 반복
ex) Unix 쉘처리
Broker Pattern
분리된 컴포넌트로 구성된 분산 시스템에서 사용되는 패턴
각 컴포넌트들은 원격 서비스를 통해 서로 상호작용을 할 수 있으며 브로커 컴포넌트가 컴포넌트 간의 통신을 조절
Peer to Peer Pattern
피어라 부르는 각 컴포넌트 간에 서비스를 주고 받는 패턴
네트워크의 어떠한 노드라도 주어진 연산을 수행할 수 있는 비중앙집중적(Decentralized) 아키텍처
피어 객체 하나가 클라이언트, 서버의 역할을 모두 수행하는 구조 서버와 클라이언트의 구분이 없음
| ex) 파일공유 | P2P |
Event-Bus Pattern
이벤트 버스를 통해 특정 채널로 메시지를 발행
프로그램에서 감지되고 처리될 수 있는 사건(Event)중심의 시스템에 적합
리스너가 구독한 채널에 소스가 서비스를 제공하면 채널이 리스너에게 서비스를 제공
ex) 알림 서비스
Model-View-Controller Pattern | MVC Pattern
3개의 각 컴포넌트는 각자의 역할을 갖고 사용자에게 서비스를 제공
Model | 데이터 관리 컴포넌트: 도메인의 기능과 자료를 저장하고 보관View | 화면 관리 컴포넌트: 사용자에게 결과를 표시Controller | 인터랙션 제어 컴포넌트: 사용자로부터 입력을 받아 연산을 처리자료의 저장, 제어, 표현 기능을 독립적으로 분리하여 재사용을 증진
사용자 인터페이스를 담당하는 계층의 응집도를 높이고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있음
디자인 패턴 중 Observer 패턴에 해당하는 구조
ex) 일반적인 웹 어플리케이션 설계 아키텍처
User -> Controller : 사용자 입력 요청
Controller -> Model : 연산 질의 요청
Model -> Controller : 질의 결과
Controller -> View : 데이터 수정
View -> User : 응답
Blackboard Pattern
명확히 정의된 해결 전략이 알려지지 않은 문제에 대해서 유용한 패턴
ex) 음성인식, 차량 식별 및 추적, 단백질 구조 식별 등
Interpreter Pattern
- 특정 언어로 작성된 프로그램을 해석하는 컴포넌트를 설계할 때 사용되는 패턴
모듈
개념
전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드
자체적으로 컴파일 가능하고, 다른 프로그램에서 재사용이 가능
기능별로 함수나 메서드를 만들고, 이를 합쳐서 프로그램을 만듬
분리된 모듈들은 해당 프로그램에서 공용으로 사용하거나 다른 프로그램에서 재사용 가능
공통 모듈
개념
자주 사용하는 기능들을 다시 사용할 수 있도록 하나의 패키지로 제공하는 독립된 모듈
여러 프로그램에서 공통으로 사용할 수 있는 모듈
재사용 범위에 따른 분류
함수와 객체 : 클래스나 메소드 단위의 소스 코드를 재사용
Component : 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용
Application : 공통된 기능들을 제공하는 애플리케이션을 공유
재사용 유형
편의적 재사용 : 프로젝트를 시작할 때, 재사용 가능한 컴포넌트가 있는지를 찾아서 재사용(내부 재사용, 외부 재사용)
계획적 재사용 : 나중에 재사용 할 수 있도록 전략적으로 설계
재사용 대표적인 사례
Library
- 소프트웨어 개발, 사용, 유지보수를 돕도록 설계한 관련 문서와 소프트웨어의 집합
Design Pattern
프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 특정 상황에서의 문제를 해결하는 방식을 설명
Framework애플리케이션 개발에 바탕이 되는 클래스들과 인터페이스의 집합
공동 모듈 작성 원칙
정확성 | Correctness
- 해당 기능이 실제 시스템 구현 시 필요한지 여부를 알 수 있도록 정확하게 작성
명확성 | Clarity
- 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성
완전성 | Completeness
- 공통 기능들 간에 상호 충돌이 없도록 작성
추적성 | Traceability
- 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성
모듈 설계
모듈화 | Modulization
개념
프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화
소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 용이하게 하는 기법
모듈화 필요성
프로그램의 효율적인 관리 및 성능 향상
한 기능에 대한 복잡도 감소로 프로그램 개발의 용이
프로그램 재사용을 통한 개발 및 유지보수 용이
오류 파급효과 최소화
단위당 프로그램 개발 노력&비용 최소화
모듈 개수 및 비용 간 상관관계
- 모듈의 크기가 너무 작아서 개수가 많아지면 통합 비용이 많이 소요
- 모듈의 크기가 너무 크면 통합 비용이 줄어드는 대신 모듈을 개발하는 데 드는 비용이 커짐
응집도 | Cohesion
개념
모듈 내부에서 구성 요소 간에 밀접한 관계를 맺고 있는 정도
응집도가 높을수록 필요한 요소들로 구성되어 있고 낮을수록 관련이 적은 요소들로 구성
응집도가 높을수록 잘 설계된 모듈
유형
순서 : 높은 응집도 -> 낮은 응집도
기능적 응집도 | Functional Cohesion
- 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우
순차적 응집도 | Sequential Cohesion
- 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
통신적 응집도 | Communication Cohesion
- 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우
절차적 응집도 | Procedural Cohesion
- 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
시간적 응집도 | Temporal Cohesion
- 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
논리적 응집도 | Logical Cohesion
- 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
우연적 응집도 | Coincidental Cohesion
- 모듈 내부의 각 구성 요소들이 어떠한 연관관계도 없는 기능요소로 구성된 경우
- 서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행하는 경우
결합도 | Coupling
개념
모듈과 모듈 사이의 관련성/의존성 정도
관련이 적을수록 모듈의 독립성이 높아 모듈 간 영향이 적어짐
결합도가 낮을수록 잘 설계된 모듈
- 파문효과(Ripple Effect)를 최소화
- 전역변수(Global Variable)보다 매개변수(Parameter)를 사용
유형
순서 : 낮은 결합도 -> 높은 결합도
자료 결합도 | Data Coupling
- 모듈 간의 인터페이스로 값이 전달되는 경우
스탬프 결합도 | Stamp Coupling
- 두 모듈이 매개변수(Interface)로 자료(Array, Object, Structure)를 전달할 때, 자료구조 형태로 전달되어 이용될 경우
제어 결합도 | Control Coupling
- 단순 처리할 대상인 값만 전달되는게 아니라 어떻게 처리를 해야한다는 제어요소가 전달되는 경우
- 어떤 모듈이 다른 모듈의 내부 논리 조직을 제어하기 위한 목적으로 제어신호를 이용하여 통신
- 상위 모듈에게 처리 명령을 부여하는 권리 전도현상 발생
외부 결합도 | External Coupling
- 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조하는 경우
공통 결합도 | Common Coupling
- 파라미터가 아닌 모듈 밖에 선언되어 있는 전역변수를 참조하고 전역변수를 갱신하는 식으로 상호작용하는 경우
- 두 모듈이 동일한 전역데이터를 접근하는 경우
내용 결합도 | Content Coupling
- 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용(참조)하는 경우
Fan-in & Fan-out
소프트웨어의 구성요소인 모듈을 계층적으로 분석하기 위해 활용
팬인과 팬아웃 분석을 통해 시스템의 복잡도를 측정
시스템 복잡도를 최적화하기 위해서는 팬인은 높게, 팬아웃은 낮게 설계
Fan-in
얼마나 많은 모듈들이 현재 모듈을 호출하는지를 나타냄
해당 모듈로 들어오는 상위 모듈 수
Fan-out
어떤 모듈에 의해 호출되는 모듈의 수
해당 모듈에서 호출하는 하위 모듈 수
코드 설계
개념
- 데이터를 사용 목적에 따라 그룹으로 분류 및 나열하고 특정 자료의 선별 및 추출 작업을 용이하게 하기 위해 부여한 숫자, 문자 및 기호 체계
기능
식별 : 각 데이터 간의 성격에 따라 구분 가능 분류 : 특정 기준이나 동일한 유형에 대한 그룹화 배열 : 의미를 부여하여 나열 가능 기타 : 표준화, 간소화, 연상, 암호화, 오류 검출
순서
- 코드 대상 항목 결정
- 코드 목적 설정
- 코드 대상 확인
- 코드 사용 범위 결정
- 코드 사용 기간 결정
- 코드 항목의 특성 분석
- 코드 방식 결정
- 코드의 문서화
유형
순차 코드 | Sequence Code
자료의 발생순, 크기순 등 코드화 대상 항목을 일정한 순서에 의해 일련번호를 부여하는 코드
ex) 학번, 군번
블록 코드 | Block Code
코드화 할 대상이 갖는 공통 특징을 중심으로 항목들을 별도의 집단으로 분류하고, 한 집단 안에서 순서대로 코드를 부여
ex) 시/군/구
10진 코드 | Decimal Code
- 10진수 형태로 표현한 코드
그룹 분류 코드 | Group Classification Code
- 대상 항목에 대한 분류 기준에 따라 대분류, 중분류, 소분류 등 각 분류별로 번호를 순서적으로 부여하는 코드
연상 코드 | Mnemonic Code
코드 대상의 명칭과 관계있는 문자, 숫자, 약어를 코드의 일부로 사용하여 어떤 대상을 의미하는지 쉽게 파악할 수 있게 만든 코드
ex) DELL_Monitor_2023_AW3423
표의 숫자 코드 | Significant Digit Code
- 코드화 대상 항목의 중량, 면적, 용량 등의 물리적 수치를 이용하여 만든 코드
합성 코드 | Combined Code
- 두 개 이상의 코드를 조합하여 만든 코드 방식
코드의 오류 발생 형태
생략 오류 | Omission Error
입력 시 한 자리를 빼놓고 기록한 경우
ex) 1997 -> 197
필사 오류 | Transcription Error
입력 시 임의의 한 자리를 잘못 기록한 경우
ex) 1997 -> 1977
전위 오류 | Transposition Error
입력 시 좌우 자리를 바꾸어 기록한 경우
ex) 1997 -> 1979
이중오류 | Double Transposition Error
전위 오류가 두 가지 이상 발생한 경우
ex) 1997 -> 9179
추가 오류 | Addition Error
입력 시 한 자리 추가로 기록한 경우
ex) 1997 -> 19978
임의 오류 | Random Error
위의 오류가 두 가지 이상 결합하여 발생한 경우
ex) 1997 -> 19798