Software Design

1. Software Design

2. Functional model Informational model Design Behavioral model Architectural design Procedural design Code Data design Other requirements Interface design Program modules Test Integrated and validated software 소프트웨어 설계(1) • 설계 단계

3. 소프트웨어 설계(2) • 설계 과정 • 요구분석명세서에 기술된 명세를 해결 방안으로 변환시키는 과정 • 명세 (Specification) • 소프트웨어 시스템을 problem domain 관점에서 기술 • 설계 (Design) • software domain 관점에서 기술 • 주어진 문제에 대하여 제안된 해결방안(solution) • 분석과 설계의 차이 --> 주택 건설의 예

4. 설계작업의 구분(1) • 프로젝트 관리 관점에서의 구분 • 예비 설계(preliminary design) • 요구사항들을 자료와 소프트웨어 구조로 변환 • 상세 설계(detail design) • 세부적인 자료구조와 알고리즘 도출 • 기술적 측면에서의 구분 • 소프트웨어 구조 설계(architectural design) • 자료 설계 • 절차 설계(procedural design) • 인터페이스 설계 • 인간-기계간의 상호작용 설계

5. 설계작업의 구분(2) • 설계대상이 무엇인가에 따른 구분 • 외적 설계 (External Design) • 소프트웨어 제품의 외적 특성을 고안/계획/기술 • 요구사항을 세분화하여 시스템에 대한 고수준의 구조적 관점 구축 • 내적 설계 (Internal Design) • 소프트웨어 제품의 내부 구조와 구성 모듈에 대하여 기술 • 외적 설계 (External Design) • user displays, report formats, external data sources/sinks • functional characteristics, high-level process structure • 성능 요구 사항

6. 설계작업의 구분(3) • 내적 설계 (Internal Design) • 구조 설계 (Architectural Design) • building blocks과 그들 사이의 관계를 파악 • Hierarchy of system views • 시스템의 기능, 자료 흐름, 자료 저장소 사이의 관계 정립 • 상세 설계 (Detailed Design) • 기능을 구현하기 위한 알고리즘 기술 • 자료 저장소를 구현하기 위한 자료 구조 확립 • 기능과 자료 구조 간의 사실상의 상호 연결 관계 구축

7. 설계 원리(Principles of Design) • 설계 원리 • 추상화(abstraction) 자세한 사항보다는 근본적인 본질에 집중 • 정보은닉(information hiding) 모듈의 상세한 처리 내용은 시스템의 다른 부분으로부터 감추어져야 함 • 단계적 분해(stepwise refinement) 문제를 상위 개념부터 하위의 구체적인 단계로 분할 및 세분화 • 모듈화(modularization) 소프트웨어를 구성하는 기본 단위는 모듈

8. 추상화(1) • 추상화란? • 자세한 사항은 접어두고, 근본적인 본질에 집중 • 전체적이고 포괄적인 개념 --> 구체적인 개념 • 기능 추상화, 자료 추상화, 제어 추상화 • 기능 추상화(Functional abstraction) • 입력 자료를 출력 자료로 변환하는 과정을 추상화 • Examples • Abstraction by Parameterization : subroutine • Abstraction by Specification : built-in functions

9. 추상화(2) • 자료 추상화(Data abstraction) • 자료의 표현 및 자료 구조의 구현에 독립적 • 자료의 자세한 부분에 대한 지식 없이도 사용 가능 • Examples • Built-in Types: Freedom of storage representations • User-defined Types: Allow mapping of concepts from the problem domain into the implementation language • Data Encapsulation: Packaging of a data structure and its access routines in a single module • Abstract Data Types: Declaration of a data type (template) from which numerous instances of encapsulated data objects can be created

10. 정보 은닉 • 정보 은닉이란? • 모듈 안에 포함된 정보는 이를 필요로 하지 않는 다른 모듈이 접근할 수 없도록 설계되어야 함 • 모듈화의 기준으로 사용되는 개념 • 장점 • 모듈 구현의 독립성 • 모듈 구현의 병렬성 • 모듈의 이해도 증진 • 변경의 국부화, 변경으로 인한 영향의 최소화

11. 단계적 세분화 • 단계적 세분화 기법(N. Wirth) • 상호 독립적인 설계 요소를 격리 • 점진적으로 세분화 • 세분화 요소의 표현(representation details)과 관련된 의사 결정은 가능한 한 연기 • 세분화 과정에서 각각의 연속적인 단계들은 이전 단계로부터 자연스럽게 확장시킴 • 기법의 적용 • 모듈에 대한 상세 설계시 사용 • 사례 : “Airline Reservations Program”

12. 모듈화(1) • module이란? • 수행 가능한 문장들의 집합으로 이름이 있는 서브루틴 • 잘 정의된 단일의 목적을 가짐 • 다른 모듈을 호출하거나 호출될 수 있음 • 컴파일하거나 라이브러리에 저장되는 단위 • 모듈 형태 • sequential module • incremental module • 수행 중에 인터럽트가 가능한 모듈 • Examples: coroutine, interrupt driven system • parallel module • 다중 프로세서 환경에서 다른 모듈과 동시에 실행될 수 있는 모듈 • Examples: Modula의 Module, Ada의 Package

13. 모듈화(2) • 좋은 모듈이 되기 위한 조건 • modular decomposability: top-down design • 조합 용이성: reusable • understandability: ease of maintenance • continuity: 변경으로 인한 소프트웨어 구조에의 영향을 최소화 • protection: error의 영향 및 side effect 최소화 • 모듈의 기능적 독립성에 대한 품질 평가 기준 • 응집도: 모듈 내부의 기능적 응집력의 정도 • 결합도: 모듈 상호간에 의존하는 정도

14. 모듈의 응집도 (Cohesion) (1) • Levels of Cohesion • coincidental • No meaningful relationships among elements (multiple, unrelated functions) • Closely related to their subordinate and superordinate modules (large interface) • e.g. Compute the cosign of an angle and the inverse of a matrix. • logical • Performs a set of related functions with a single interface. • Parameters have different interpretations depending on which function is invoked. Some parameters are ignored in some cases. • e.g. Add or delete an entry and list all the entries on the membership directory. • classical • Performs multiple sequential functions. Weak but nonzero relationship. • No parameter or logic to determine which elements to execute • e.g. INIT. declare i, j, x, y; declare table1(20), table2(20); read trans-file-1; read trans-file-2;

15. 모듈의 응집도 (Cohesion) (2) • procedural • Multiple functions where the sequential relationship among the functions is implied by the problem statement. • e.g. Extract the outline of an object and determine its shape. • communicational • Procedural and all the elements communicate with one another through a common data structure. • e.g. Compute the largest angle of a triangle and the sum of the length of each side. • functional • The outside (function) is easier to understand than its inside (logic). • e.g. Find customer loan balance. • informational => Information Hiding • Multiple functions dealing with a single data structure. • Physical packaging together of modules having functional strength • e.g. STACK, QUEUE

16. 모듈의 응집도 (Cohesion) (3) • Module Strength의 판별 IF 단일 기능 THEN functional ELSE IF Data에 의한 결합 informational or communicational ELSE IF Control에 의한 결합 procedural or classical ELSE logical or coincidental • Exercises • Print and punch the output file • Update, add, or delete a record on the master file. • Format screen for part display and read part record from database • Read the next transaction, edit it, and display it to the tape operator. • Read or write an inventory record (two entry points).

17. 모듈의 결합도 (Coupling) (1) • 결합도에 영향을 주는 요소 • 모듈 간의 연결 형태: transfer/return, multiple entry • 인터페이스의 복잡도: 공유되는 정보의 양 • 정보 흐름의 형태: 자료 흐름, 제어 흐름 • Levels of Coupling • Content coupling • One module makes a direct reference to the contents of the other module • Does not occur in high-level languages. (assembly lang.) • Common coupling • A modification impacts every module that is common coupled to this module. • difficult to use in other context. • difficult to control data access. • difficult to know what data are used by a particular module. • e.g. FORTRAN : common blocks

18. 모듈의 결합도 (Coupling) (2) • Control coupling • One module passes elements of control as parameters to the other module. • e.g. function code, flags, switches, error code, return code • One module knows something about the logic of the other module. • * inversion of control (hierarchy breakdown) • Stamp coupling • Modules reference the same nonglobal data structure. • The name or location of the data structure is passed through the program as a parameter. • Pass needed field as parameters • Data coupling • Is a necessary minimum form of the module interconnection..

19. 구조 설계(1) • Architectural Design? • Establishing the overall structure of a software system • identify major system components and their communications • produces a description of the software architecture • An early stage of the system design process • Represents the link between specification and design processes • Often carried out in parallel with some specification activities

20. 구조 설계(2) • Advantages of explicit architecture • Stakeholder communication • Architecture may be used as a focus of discussion by system stakeholders • System analysis • Means that analysis of whether the system can meet its non-functional requirements is possible • Large-scale reuse • The architecture may be reusable across a range of systems

21. 구조 설계(3) • Architectural design process • System structuring • identify several principal sub-systems • identify communications between these sub-systems • Control modelling • establish a model of the control relationships between the different parts of the system • Modular decomposition • decompose the identified sub-systems into modules

22. 구조 설계(4) • Sub-systems and modules • A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. • A module is a system component that provides services to other components but would not normally be considered as a separate system • System structuring • Concerned with decomposing the system into interacting sub-systems • The architectural design is normally expressed as a block diagram presenting an overview of the system structure • May develop more specific models showing how sub-systems share data, are distributed, and interface with each other

23. 구조 설계(5) • Control models • Are concerned with the control flow between sub-systems. Distinct from the system decomposition model • Centralized control • One sub-system has overall responsibility for control and starts and stops other sub-systems • Event-based control • Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

24. 구조 설계(6) • Modular decomposition • Another structural level where sub-systems are decomposed into modules • Two modular decomposition models covered • An object model where the system is decomposed into interacting objects • A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model • If possible, decisions about concurrency should be delayed until modules are implemented

25. 자료 설계(1) • 자료 설계란? • 요구 단계에서 식별된 자료 객체들의 논리적인 표현을 선택 • 논리적 자료 구조에 직접 작동해야 하는 프로그램 모듈을 식별 • 자료 설계를 위한 원칙 • 기능과 행위에 적용된 체계적인 분석 원칙을 자료에 적용 • 모든 자료 구조와 이에 대한 모든 연산을 식별 • 자료 사전을 자료와 프로그램을 정의하는데 이용 • 하위 수준의 자료 설계에 관한 결정은 가능한 한 연기 • 정보 은닉 개념 적용 • 유용한 자료 구조의 라이브러리와 이에 적용되는 연산을 개발

26. 자료 설계(2) • 자료 구조 설계 • 자료를 단순파일에 저장하는 경우에 수행 • 시스템의 외부 파일에 대한 설계 및 시스템구조도에 나타난 자료에 대한 자료 사전 작성 • 절차 1. DFD의 자료저장소 => 외부 파일 2. 요구 단계의 자료 사전 => 레코드의 항목 및 길이 결정 • 사례 : 인사관리 시스템의 인사 기본 파일 • 데이터베이스 설계 • 자료를 데이터베이스로 구축할 경우에 수행 • 자료의 논리적 설계 • 데이터 모델링에 의한 자료 분석 (E-R Diagram)

27. 절차 설계 • 절차 설계란? • 절차 설계/알고리즘 설계/상세설계 • 구조적 설계 기법은 소프트웨어의 구조 설계에 초점==>모듈 내부에 대한 설계가 필요 • 상세 설계(detailed design) • 구조 설계에서 식별한 모듈 또는 오퍼레이션에 대한 알고리즘 설계 • 특정 프로그래밍 언어의 사용은 절제 • 표기법 • 그래픽 표기 방법: flowchart, N-S 도표 • 가상 코드 표기 방법: 프로그램 설계 언어(PDL)

28. Flow Chart (1) • 기본개념 • 알고리즘의 제어 흐름을 표현하는 그래픽 도구 • 기본 요소: 직사각형, 다이아몬드, 화살표 • 직사각형 --> 처리를 표시 • 다이아몬드 --> 조건 분기를 표시 • 화살표--> 제어 흐름을 표시 • 장단점 • 간단하고 표현력이 높으며 배우기 쉽다 • 구조적으로 작성하면 읽기 쉽고 이해도가 높은 프로그램 구조 생성 가능 • 비구조적이고 복잡한 프로그램 구조 생성 가능 • goto 문의 무절제한 사용 • 간단한 모듈의 내부 구조를 나타내는데 적합하나,복잡한 시스템 구조 설명에는 부적합

29. Flow Chart (2)

30. NS Chart(1) • 기본 개념 • flowchart의 단점을 극복하고자 Nassi & Schneiderman이 제안, Chapin이 발전시킨 그래픽 표기법 • 순서적 구조, 조건 분기 구조, 순환 구조 등 기본적인 요소에 대한 표시 방법 제공 • 장단점 • 프로그램의 기본 제어 구조를 서로 다른 도표로 표시하여 쉽게 읽고 이해할 수 있음 • 임의로 goto 문을 작성할 수 없고, N-S 도표가 제공하는 요소들만 사용 --> 프로그램의 구조적 표현 가능 • 순환(recursion) 제어 구조를 쉽게 표시할 수 있음

31. NS Chart(2)

32. 프로그램 설계언어 • Program Design Language의 기본 개념 • 가상 코드(pseudocode)라고도 부름 • 고급 프로그램 언어의 제어 구조와 자연 언어를 통합 • PDL "프로그램"은 순서도 혹은 N-S 도표로 변환 가능 • Examples: PDL/Ada, PDL/C • 자체적인 PDL 설계 시 구비 요건 • 키워드 및 제어 구조는 미리 정의 • 처리에 대한 설명은 자연어 사용 • 데이터 타입에 대한 정의를 내릴 수 있는 기능 • 사용할 고급 언어로 정의할 수 있는 모든 타입을 설명 • 모듈 정의 기능을 제공하여야 하며, 모듈간에 서로 호출할 수 있어야 함

33. 사용자 인터페이스 설계(1) • 사용자 인터페이스 설계의 필요성 • 컴퓨터 보급의 확대에 따라 사용자 인터페이스에 대한 중요성이 증가 • 컴퓨터와의 대화가 직관적이고 쉬워야 함 • 많은 사람들이 컴퓨터를 사용하는데 어려움을 느끼고 있음 • 인터페이스가 배우기 어렵고, 쓰기 어렵고, 사용자의 실수를 허용하지 아니함 • 인터페이스가 쉽다면, 사용자는 시스템 내부의 기능을 보다 효과적으로 활용할 수 있음

34. 사용자 인터페이스 설계(2) • 요구단계에서의 사용자 인터페이스 설계 • 요구분석 과정에서 파악된 자료의 반영 • 사용자가 관심을 가지는 데이터 • 사용자 입력 정보 및 시스템 출력 정보 • 사용자가 보아야 할 데이터, 상태의 변화, 기능 수행 등 • 요구명세서의 일부인 Preliminary User Manual에 사용자 인터페이스를 기술 • 매뉴얼의 사용자를 명확히 규정 • 사람과 시스템 사이의 인터페이스에 대한 정보 기술 • 입출력 데이터를 중심으로 하여 예상되는 메뉴 구조, 스크린, 보고서 형식 등을 포함하여 기술

35. 사용자 인터페이스 설계(3) • 설계 단계에서의 사용자 인터페이스 설계 • 구체적인 사용자 인터페이스는 설계의 초기단계에서 정의 • 메뉴 구조, 스크린의 모양과 데이터, 필요한 버튼 등을 포함 • 사용자와 상호 작용이 많은 시스템의 경우에는 사용자 인터페이스가 소프트웨어 구조보다 먼저 고려되어야 할 중요한 문제 • User Guide에 사용자 인터페이스 설계 결과를 기록 • 사용자 안내서에는 시스템의 목적, 주요 기능, 구조, 다른 소프트웨어 및 하드웨어와의 인터페이스 등을 기술 • 스크린에 대한 설명으로는 메뉴, 스크린 종류, 스크린 형식, 데이터를 선택하거나 입력하는 방식 등을 포함

36. 사용자 인터페이스와 인적 요소(1) • 사용자 인터페이스의 인적 요소 • 사용자 인터페이스의 사용자 = 인간 • 고려해야 할 인적 요소 (human factor) • 심리학적인 요소 • 사용자의 인터페이스에 대한 요구 • 나이, 성, 직업, 교육, 문화, 피부 색깔 등에 따른 특성 • 인간의 사물에 대한 인식 방법 • 시각적인 지각 능력 • 연역 또는 귀납적인 추론 능력 • 인간 사회와 조직 등

37. 사용자 인터페이스와 인적 요소(2) • 인식 모델 (cognition model) • 인간이 정보를 처리하는 방법을 규명 • 인간은 인식 과정을 통하여 사물을 이해하고 지식을 얻으며, 기억, 추리, 기능의 파악, 새로운 아이디어의 창출 등을 수행 • HCI는 인간과 컴퓨터간의 지식 교환 방법을 제시하고, 이를 개선할 방안을 연구

38. 사용자 인터페이스와 인적 요소(3) • 확장 모델 • 인식 모델에 기억 장치와 관심부분을 추가 • perceptual processor가 어떤 방법으로 정보를 지각하는가? • 정보가 어떻게 관심의 대상이 되는가? • 정보가 어떻게 처리되고 저장되는가?

39. 사용자 인터페이스와 사회적 요소 • 정보에 대한 이해는 사회적 환경이 바탕 • 사회 환경에서 보고, 듣고, 배운 정보가 저장되며, 이를 바탕으로 인식을 수행 • 문화의 차이는 사용자 인터페이스에 대한 요구에 영향 • 문화에 따라 붉은 색깔에 대한 이해와 반응은 서로 다름 • 사용자 인터페이스 설계에 사회적 환경 및 습관에 대한 요소를 고려 • 같은 사회적 환경이라도, 조직에서 수행하는 임무에 따라 컴퓨터에 대한 이해는 상이 • 조직이 업무를 능률적으로 수행하도록 지원 • 사용자 인터페이스 설계시 사용자의 역할 및 기술 수준을 고려 • 사용자의 역할에 따라 정보를 다양하게 표시하고, 다양한 상호 대화 방식을 지원 • 사용자의 기술 수준에 따라 사용자 인터페이스를 구분

40. 사용자 인터페이스 방식 • 사용자 인터페이스의 평가 기준 • 사용법을 배우는데 소요되는 시간 • 특정 기능을 수행시키는데 필요한 시간 • 원하는 작업을 수행하기까지 범한 오류의 빈도 • 시스템에 대한 사용자의 만족도 • 시스템의 사용법을 기억하고 있는 기간 • 사용자 인터페이스 방식 • 명령어(Command) 방식 • 메뉴(Menu) 방식 • 양식 채움(Form fill-in) 방식 • 직접 조작(Direct manipulation) 방식

41. 명령어 방식 • Overview • 컴퓨터 시스템이 도입된 초기에 널리 이용 • 키보드로 명령어를 컴퓨터에 입력하여 컴퓨터와 대화 • 컴퓨터 시스템의 동작마다 특정한 명령어를 제공 • 같은 종류의 동작을 세분화하기 위하여 다양한 선택 사항을 제공 • Example: UNIX 시스템 명령어 • cd, chdir : 작업 디렉토리를 변경 • chmod : 파일 또는 디렉토리의 access permission를 변경 • options: r 읽기 접근, w 쓰기 접근, x 수행 접근, u 사용자(소유자), g 그룹, o 이외, a 전부

42. 메뉴 방식 (1) • Overview • 다양한 메뉴 항목을 구성하여 제시하고, 사용자는 항목을 선택하여 필요한 기능을 수행 • 현재 널리 사용되고 있는 인터페이스 방식 • 사용자는 메뉴의 각 항목을 기억할 필요가 없으며, 각 항목이 어떤 기능을 수행하는가를 판정할 수만 있으면 시스템 사용 가능 • 키보드 입력이 불필요하여, 입력 오류가 없음 • full screen menu • 메뉴가 스크린 전부를 차지하고 사용자는 메뉴 항목을 반드시 선택하여야만 다음 기능을 수행할 수 있는 방식 • 예: touch screen을 통한 기능 선택 화면

43. 메뉴 방식 (2) • Drop-down 메뉴

44. 메뉴 방식 (3) • Pop-up 메뉴

45. 메뉴 방식 (4) • Push-Button 메뉴

46. 메뉴 방식 (5) • 기타 메뉴 • Radio-Button 메뉴 • 기능과 연관된 선택 사항을 메뉴 형식으로 설계할 수 있음 • 선택 사항은 배타적(exclusive)인 경우도 있고, 배타적이 아닌 경우도 있음 • Check-Box 메뉴 • Check-box 메뉴를 이용하여 선택 사항에서 비배타적으로 선택할 수 있는 사항을 설계할 수 있음 • 비배타적 선택에서는 사용자가 동시에 여러 가지 사항을 선택할 수 있음

47. 양식기입 방식 (1) • Overview • 대량의 데이터를 입력하는 경우에 사용 • 입력 항목에 따라 다양한 field를 제공하며, 해당 정보를 필드에 직접 입력 가능 • 필드마다 이름을 갖고 있어 직관적이며, 일상 업무에서 사용하는 서식과 유사하여 편함 • 초보자도 쉽게 사용할 수 있음 • 데이터베이스 시스템 또는 MIS 시스템에서 많이 사용

48. 양식기입 방식 (2) • Example

49. 사용자 인터페이스 설계시 유의사항 • 인터페이스는 일관성 있게 설계 • 의미 있는 피드백을 제공 • 파괴적인 행동을 하고자 할 때 이를 확인 • 사용자가 취한 행동에 대하여 원 상태로 복귀할 수 있도록 허용 • 행동 사이에 기억해야 할 정보의 양을 극소화 • 대화, 움직임, 생각의 효율성을 추구 • 키 입력을 최소화 및 마우스 이동 거리 최소화 • 사용자의 실수에 관대 • 명령어와 활동들을 분류하여 화면에 배치하여 응집력을 강화 • 문맥-의존적(context sensitive) 도움말 기능을 제공 • 간단한 동사와 명령어를 사용하고, 불필요한 입력은 제외

50. 설계서 작성(1) • 도큐먼트의 역할 • 개발의 수단 • 개발 요원 간의 통신 수단 • 설계 작업의 상세화 수단 • 설계 품질의 확보 • 표준화의 추진 • 개발대상 소프트웨어의 구조를 표준화 • 소프트웨어 설계 제조 순서의 표준화 • 프로젝트 관리의 수단 • 각 공정의 진행 상황의 확인 • 소프트웨어 규모, 품질 등의 정량적 파악 • 공유 자산화와 기술의 전수 • 소프트웨어를 조직의 공유자산으로 한다. • 신인, 후배에 대한 교육과 기술의 전수