[Software Engineering] Component-Level Design & Fundamental Design Concepts

Component-Level Design

Component-level design은 Architecture design이 완료된 후에 수행되는데, 이것은 각 소프트웨어 Component에 할당된 자료 구조, 처리 로직, 인터페이스 특성 및 통신 메커니즘을 정의하는 것이다.

 

Component란 프로그램의 기능적 요소이다. 이는 "module"이라고도 불린다. UML에서는 component를 "a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces"으로 정의한다. 

 

Step 1: Identify All Design Components

1. 문제 도메인에서 Design component를 식별 (architectural component를 사용, 개선)

2. 인프라 도메인에서 Design component를 식별 (GUI 관련 component, OS 관련 component)

Step 2: Elaborate All Design Components

1. Design component간 전달되는 Message(Message 이름, 콘텐츠 및 속성)을 지정 -> UML communication diagram 

2. 각 Component에 대한 Interface를 식별(Interface 이름 및 속성) -> UML component diagram

3. 자료 구조 및 데이터 유형(변수 및 복합 자료 구조) 식별 -> UML component diagram

4. 각 프로세스 내의 프로세싱 흐름 설명(flow chart 또는 UML activity diagram), 각 프로세스에 대한 매개변수와 매개변수 타입을 지정

Step 3: Describe Persistent Data Sources and Identify Relavant Components

- 대부분의 경우 데이터 저장소는 처음에 Architecture design의 일부로 지정된다.

1. 영구적인 데이터 저장소의 구조 및 구성에 대한 추가 세부 정보 제공

2. 이를 관리하는 데 필요한 Design component 식별

Step 4: Develop and Elaborate Behavioral Representations

- 전체 시스템 및/또는 특정 Component의 동작을 나타내기 위해 flow chart, data-flow models, state machine model을 사용한다.

1. 전체 시스템에 대한 디자인 요소를 식별하고 그린다. (State machine model일 경우: states, events, transitions, actions)

2. 개별 Component에 대한 디자인 요소를 식별하고 그린다.

Step 5: Elaborate Deploymet

1. Design component를 수용할 컴퓨팅 환경 식별

2. 각 Component의 위치 지정

3. 특정 하드웨어 및/또는 소프트웨어 환경 설명 

 

Fundamental Design Concepts

1. Abstraction: 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것

- Data abstraction: 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법

- Procedural abstraction: 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법

 

2. Modularity: 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등을 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것

- 모듈을 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 든다.

 

- Information Hiding: 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법이다. 이를 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로, 수정, 시험, 유지보수가 용이하다.

- Encapsulation: 데이터와 데이터를 처리하는 함수를 하나로 묶는 것. 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐되어 외부에서의 접근이 제한적이기 때문에 외무 모듈의 변경으로 인한 파급 효과가 적다. 객체들 간의 메시지를 주고받을 때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다.

 

- Functional Independence: 모듈화와 추상화의 직접적인 결과이다. 이는 모듈이 독립적인 기능으로 정의되어 있는 정도인 Cohesion과, 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미하는 Coupling 이라는 두 가지 기준을 사용하여 평가된다. Cohesion이 강하고, Coupling이 약할수록 Functional Independency가 높다.

 

- Functional Cohesion(가장 강함): 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도

- Communiational Cohesion: 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 Component들이 모였을 경우의 응집도

- Temporal Cohesion(가장 약함): 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도

 

- Content Coupling(가장 강함): 한 모듈이 다른 모듈에 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도

- Common Coupling: 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도

- Control Coupling(가장 약함): 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위한 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도

 

3. Refinement: High-Level의 추상화에서부터 Low-Level의 추상화로 점진적으로 소프트웨어를 구현해 나가는 Top-Down 설계 전략으로 다음과 같이 수행될 수 있다.

- 어려운 문제를 두 단계로 세분화 하기

- High-level의 Activity를 일련의 sub-activities로 나누기

- 하나의 Task를 일련의 Tasks로 나누기

- 시스템 상태 및 속성을 캡처하기 위한 변수 도입

- 처리하는 데이터의 구조를 반영하기 위한 루프 구조화

 

Refinement는 다음을 필요로 할 수 있다.

- Seperation of concerns: 한 번에 한 가지 일에 집중하고 올바르게 처리

- The mañana principle: 처음에는 문제를 단순한 수준에서 정의하고 점진적으로 세부사항을 추가하는 방식으로, 이 과정에서 핵심적인 설계 과정이나 복잡한 부분은 나중의 해결하기로 미루는 것

 

Abstraction와 Refinement는 상호보완적이다.

- Abstraction을 통해 Procedure와 Data를 지정하면서 Low-level의 세부 사항은 억제

- Refinement를 통해 Low-level의 세부 사항을 공개