[소프트웨어 공학] 7. Software Design

※ Software Design

- A process through which requirements are translated into a representation of software.

- Software design methodology lacks the depth, flexibility and quantitative nature in comparison to classical engineering fields. 

요구사항을 소프트웨어로 개발하기 위하여 개발자의 관점에서 작성한다.

※ Characteristics of Good Design 

- A design should exhibit a hierarchical structure. - 계층구조로 보기 쉽게

- A design should be modular. - 모듈화

- A design should contain distinct and separable representation of data and procedure. 

  - 데이터로 나타낼 부분과 Procesure로 나타내야할 부분을 분리한다. 

- A design should lead to modules that exhibit independent functional characteristics. - 독립적인 기능을 모듈화한다.

- A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment. - 외부환경과 결합되기 쉽게 복잡하지 않은 인터페이스로 설계한다.

Modularity in details 

※ Coupling  

Degree of interdependence between two modules. 

두 모듈 사이의 관계가 형성될때 그 결합강도.

Low coupled system 

- Prevent ripple effect - 파급효과 억제

- Enhance understandability - 이해력 향상

Objective: Minimize coupling 

- Make modules as independent as possible. - 가능한 독립적인 모듈로 만든다.

- Indicates a well-partitioned system. 

How to achieve low coupling 

- Eliminating unnecessary relationships - 불필요한 관계를 제거한다.

- Reducing the number of necessary relationships - 필요한 관계도 최소화한다.

※ Scale of Coupling

▲ Best (Low Coupling)  ▼ Worst	Data Coupling	Two modules are data coupled if they communicate by parameters, each parameter being an elementary piece of data.    모듈간 데이터를 전달할 때 모든 데이터(매개변수)가 다 사용되어질 때.  Avoid wide inter face -> Define and use composite data  Avoid Tramp data - > Restructure the module structure
	Stamp Coupling	Two modules are stamp coupled if one passes to the other a composite piece of data   모듈간 데이터를 전달할때 일부 데이터만 사용되어질 때.  Never pass records containing many fields to modules that need part of those fields - > Narrow the interface of the module.   Bundling means collecting unrelated data items into an artificial data structure - > Never collect unrelated data items into an artificial data structure
	Control Coupling	Two modules are control coupled if one passes to the other a piece of information intended to control the internal logic of the other   모듈이 다른 모듈의 다른 로직을 통제할 가능성이 있을 때.  Split the called module by defining new module for each exclusively executed logic. 모듈 자체를 분리하여야 한다.
	Common Coupling	Two modules are common coupled if they refer to the same global data area   두개의 모듈이 같은 전역변수를 사용할때.  Bad reasons for common coupling   Ripple effect - 파급효과  Less flexibility of globally coupled module - 수정이 어렵다.  Remoteness in time is introduced   Abuse of the same global area for multiple purpose   Difficulty in understanding and tracking the use of global area - 이해어려움
	Content Coupling	Two modules are content coupled if one refers to the inside of the other in any way  다른 모듈의 내부를 그냥 접근할 수 있는 경우  ex) 'goto' statement , assembly program

※ Cohesion

The measure of the strength of functional relatedness of elements within a module

하나의 모듈안에서 각 요소가 공통의 목적을 달성하기 위한 응집도.

Objective: Maximize Cohesion 

- Make modules whose elements are strongly and genuinely related to one another 

Relationship between Coupling and Cohesion 

- 2 ways to evaluate the partitioning of a system 

- The cohesion of a module often determines how tightly it will be coupled to other modules in a system, and vice versa. 

▲ Best (High Cohesion) (유지보수 쉬움)  ▼ Worst	Functional	A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task   모듈이 한 가지의 일만 할 때.
	Sequential	A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next   모듈 안에 있는 하나의 작업에 대한 결과가 다른 작업의 입력이 된 경우.  (다른 모듈로 분리하는 것이 좋다)
	Communicational	A communicationally cohesive module is one whose elements contribute to activities that use the same input or output data   동일한 입력과 출력인 소작업들이 모인 모듈.  When the caller has interested in the part of the return value -> Define functionally cohesive module for each elementary return value
	Procedural	A procedurally cohesive module is one whose elements are involved in different and possible unrelated activities in which control flows from each activity to the next  모듈 안의 작업들이 큰 테두리 안에서 같은 작업에 속하고 입출력을 공유하지도 않지만, 순서에 따라 수행될 필요가 있는 경우.  (연관없는 활동을 제거한 후 sequential/functional cohesion으로 바꾸어라)
	Temporal	A temporally cohesive module is one whose elements are involved in activities that are related in time   프로그램의 초기화 모듈 같이 한번만 수행되는 요소들이 포함된 형태.
	Logical	A logically cohesive module is one whose elements contribute to activities of the same general category in which activities to be executed are selected from outside the module   유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성될 경우.
	Coincidental	A coincidentally cohesive module is one whose elements contribute to activities with no meaningful relationship to one another   아무 관련없는 처리 요소로 모듈이 형성되는 경우.

좋은 소프트웨어 설계란?

모듈화 원칙을 지키고 유지보수가 쉽게 할 수 있도록 설계하는 것이다.

모듈화 원칙은 Low Coupling + High Cohesion 이다.

※ Design in Technical aspects 

Data design

- transformation of the information domain model created during analysis into the data structures. 

 (데이터베이스 설계)

Architectural design

- definition of the relationship among major structural components of the software. 

 (전체 시스템을 이루는 서브시스템, 모듈 관계파악)

Procedural design 

- transformation of structural components into a  procedural description of the software.  

(User) Interface design 

- establishment of the layout and interaction mechanisms for human-machine interaction.  

 (메뉴나 입력양식 설계)

Structured Design : Architectural Design 

A process through which requirements are translated into a representation of software. 

※ Architectural Design : Task Model

Task Model  

- represents how tasks collaborate with each other to realize the Flow Diagrams 

To design task model is the most important work of embedded system development 

- Because it has significant impact system’s performance, reliability, required resource, and so on 

We develop task models through the following steps 

- Integrating data flow diagrams into a whole DFD.  

- Identifying candidate tasks  

   Each control process can form a ‘Control Task’  

   Process can form a task when it is either Periodic or Asynchronous 

- Allocating remaining processes 

- Merging tasks  

※ Tips for Allocating Remaining Processes 

Allocating and merging heuristics (응집력과의 관계를 생각한다)

- Control Cohesion 

  Control process may be grouped with the processes it uses into a task 

  For example, triggered synchronous function 

- Sequential Cohesion  

  Certain processes perform operations that must be carried out in a sequential order 

- Temporal Cohesion 

  Certain processes may perform operations that are activated by the same event 

- Functional Cohesion 

  Functional cohesion occurs when there are one or more functions that are closely related 

When a set of tasks are working in a mutually exclusive manner(independent), they can be grouped into a single task 

Structured Design : Detailed Design 

※Overview of Structured Design 

Goal of Structured Design is to build a model to describe how the system work (시스템이 어떻게 동작하는지)

Can convert Flow Diagrams into a structure chart at task level. (

After architectural design, we perform Structured Design for each task 

 - For Flow Diagrams in each task, we convert it into structure chart using modular design strategies  

 - Then, we refine the result to describe the enough details of tasks

Structure Chart	Modules, Invocations, Couples, Control Abstraction 등의 정해진 Symbols을 이용하여 어떻게  컨트롤하는지를 그린 그림.
Module Specification	모듈의 세부적인 내용을 슈도코드로 작성한 것.

※ Refining Structure Chart

Make each module cohesively  - High Cohesion 

Keep the coupling between modules loosely - Low Coupling

Factoring - 공통된 속성을 뽑아서 하나의 클래스로 만든다.

Reduce Fan-Out - 두 개의 모듈을 최대한 합쳐라 ( 다른 모듈을 호출하지 않게)

Delete Dummy Module 

Localization for Periodic Process - 데이터를 필요로할때 계속 요청하지 않고 local화하여 값이 변경되었을 때만 알린다. 

Contents of  SDD  

1. Introduction 

 - Purpose of this document 

 - Project overview 

 -Related documents, terms, abbreviations 

2. Architectural Design 

 - Architecture model 

 - Model description  

3. Module Design  

 - For each module  

    Design model 

    Module specification 

4. Interface Design 

 - Software interface 

 - Communication interface  

5. Data Design 

 - Data structure design 

6. Implementation Design 

 - Required SW technologies  

 - HW technologies  

7. Others  

 - Considerable issues 

8. Traceability Analysis  

 - Traceability matrix  

9. References and Appendix  

What is the difference betwwen DFD and Structure chart?

 DFD - 데이터의 흐름만 구성 ( 처리관점 )

 Structure chart - 실행 개념 ( 컨트롤 관점 )