Design Engineering - Hanyang · 2018-05-13 · - GoF(Gang of Four) : Gamma E., Helm R., Johnson R.,...

CSE4006: Software Engineering - Scott Lee

Scott Uk-Jin Lee

Division of Computer Science, College of Computing Hanyang University ERICA Campus

1st Semester 2018

Design Engineering

CSE4006 Software Engineering


Software Design

!2

• 다음을 포함 : • 디자인 원칙 (principles)

- 작업 수행 중 디자이너를 가이드하는 철학 수립 및 재정의

• 디자인 개념 (concepts): - 디자인 실무의 메커니즘이 적용되기 전에 이해 하는 것이 필수

• 디자인 실무 (practices): - 새로운 방법, 더 나은 분석, 더 넓은 지식으로 진화 함에 따라 지속적으로 변함

• 훌륭한 소프트웨어 설계는 다음을 제시 : • 견고성 (firmness) : 기능을 저해하는 버그는 없어야 함 • 상품성 (commodity) : 의도된 목적에 적합해야 함 • 기쁨(delight) : 사용 겸험이 즐거워야 함


Software Engineering - Design • data/class design

• 분석 클래스를 구현 클래스(implementation class)와 자료 구조로 변환

• architectural design • 주요 소프트웨어 구조 요소 간의 관계를 정의

• interface design • 소프트웨어 요소, 하드웨어 요소, 사용자가 통신하는 방법 정의

• component-level design • 구조 요소를 소프트웨어 구성 요소의 절차적 설명으로 변환

!3


Analysis Model→Design Model

!4


Design & Quality

설계 (Design)는 : • 분석 모델에 포함된 모든 명시적 요구사항 (explicit requirements)을 반드시 구현해야 함 • 고객이 원하는 암시적 요구사항 (implicit requirements)도 수용해야함

• 일기 쉽고 이해할수 있는 (understandable) 가이드가 되어야 함 • 코드를 생성, 테스트 유지보수 하는 사람들을 위해

• 소프트웨어의 전체적 그림 (청사진)을 제공해야 함 • 구현 관점에서 데이터 (data), 기능적 (functional), 행동적

(behavioral) 도메인을 기술

!5


Quality Guidelines

설계 (Design)는 :

1. 아키텍처 (architecture)를 보여줘야 함

i) 알아볼 수 있는 아키텍처 스타일이나 패턴을 사용하여 생성

ii) 좋은 설계 특징들을 가지고 있는 컴포넌트들로 구성

iii) 진화적인 (evolutionary) 방법으로 구현 가능해야 함

2. 모듈화(논리적으로 분할) 되어야 함

3. 데이터 (data), 아키텍처 (architecture), 인터페이스 (interfaces), 컴포넌트 (components)에 대한 고유 한 표현법을 포함해야 함

!6


Quality Guidelines

설계 (Design)는 : 4. 다음과 같은 자료 구조 (data structure)를 유도

• 구현될 클래스에 적합한 • 알아볼 수 있는 데이터 패턴으로 부터 추출된

5. 독립된 기능적 특징을 보이는 컴포넌트들을 유도 6. 컴포넌트들 사이 그리고 외부 환경 과의 연결 복잡성을 낮추는 인터페이스를 유도

7. 소프트웨어 요구사항 분석 중 얻은 정보에 의해 구동되는 반복가능한 (repeatable) 방법을 사용하여 도출

8. 그 의미를 잘 전달할 수 있도록 효과적으로 표현

!7


Quality Attributes - FURPS [Gra87] developed by HP

• Functionality (기능성) • 기능 집합, 프로그램의 능력, 기능의 일반성으로 평가

• Usability (사용성) • 인간적 요인 (human factor), 전체적 미학을 고려하여 평가

• Reliability (신뢰성) • 고장율 (failure rate), 출력 정확도, 고장 복구 능력을 측정하여 평가

• Performance (성능) • 처리 속도, 응답 시간, 처리량, 효율성, 자원 소비 등으로 측정

• Supportability (지원성) • 유지보수성 (maintainability) : 확장성, 적용성, 서비스 가능성 • 호환성, 구성 (configuration) 및 설치 (installation) 용이성

!8


fundamental Software Design Concepts

• abstraction (추상화) • 데이터, 절차

• architecture • 전반적인 소프트웨어 구조

• patterns (패턴) • 입증 된 설계 (design) 솔루션의 “본질을 전달”

• separation of concerns (관심사 분리) • 복잡한 문제는 조각으로 세분화하면 더 쉽게 처리 가능

• modularity (모듈화) • 데이터 및 기능의 분류

!9


fundamental Software Design Concepts

• hiding (은닉)

• 제어(controlled) 인터페이스

• functional independence (기능적 독립성)

• 단일 지향성 기능 (응집력 ohesion)과 낮은 결합도 (coupling) • refinement (단계별 구체화)

• 모든 추상화에 대한 세부 사항 정교화 (elaboration) • aspects

• 글로벌 요구사항이 설계에 미치는 영향을 이해하게 하는 메커니즘 • refactoring

• 디자인을 단순화하는 재구성 기술

!10


Data Abstraction

• 데이터 객체들을 설명하는 명명된 데이터 컬렉션

!11


Procedural Abstraction

• 특정적이며 제한된 기능을 갖는 명령 (instrcution) 시퀀스

!12


Software Architecture Design“The overall structure of the software and the way the structure provides

conceptual integrity for a system” - Shaw et. al.

• 구조적 특성 (structural properties) • 시스템의 컴포넌트와 컴포넌트가 패키징되고 서로 상호 작용하는 방식

• 추가 기능성 특성 (extra-functional properties) • 설계 아키텍처가 성능, 수용성, 신뢰성, 보안, 적용성 등의 요구사항을 달성하는 방법

• 관련 시스템 계열 (families of related system) • 유사 시스템 계열의 설계에서 일반적으로 방생하는 반복 가능한 패턴 • 아키텍처 빙딜 블록 재사용 능력

• 표현 (representation) • 구조적 모델, 프레임워크 모델, 동적 모델, 프로세스 모델, 기능 모델 • architectural Description Language (ADL)

!13


Design Pattern“설계 패턴은 특정 환경에서 일반적인 설계 문제를 해결하도록 맞추어진, 상호 협력하는

객체들과 클래스들에 대한 기술” - GoF(Gang of Four) : Gamma E., Helm R., Johnson R., Vlissides J., 1995

• 모든 분야의 최고 디자이너는 다음을 볼 수 있는 능력이 있다 • 문제를 특징 짓는 패턴 • 결합하여 솔루션을 만들 수 있는 패턴

• 디자인 패턴은 설계력 (design forces)의 집합을 고려할 수 있음 • 설계력은 소프트웨어와 관련된 비 기능적 요구 사항 (예 : 유지 관리 용이성, 이식성 등)을 설명

• 패턴 특성 (클래스, 책임 - responsibilities, 공동 작업 - collaborations)은 패턴이 다양한 문제를 수용 할 수 있도록 조정될 수 있는 디자인 속성을 나타냄

• 추상화 수준 • 아키텍처 패턴 / 디자인 패턴 / 숙어 (코딩 패턴)

!14


Design Pattern Template

• pattern name : 패턴의 본질을 설명하는 짧고 표현력이 강한 이름 • intent : 패턴과 패턴이 하는 일을 설명 • motivation : 문제의 예를 제시 • applicability : 패턴을 적용할 수 있는 구체적인 설계 상황 기록 • structure : 패턴을 구현하는 데 필요한 틀래스들을 설명 • participants : 패턴을 구현하는 데 필요한 틀래스들의 책임을 설명 • collaborations : 참여자들이 협력하여 책임을 수행하는 방법을 설명 • related patterns : 관련 디자인 패턴의 상호 참조

!15


Separation of Concerns

• 복잡한 문제는 개별적으로 해결 / 최적화 할 수 있는 조각으로 세분화되면 보다 쉽게 처리 가능

• concern은 소프트웨어 요구사항 모델의 일부로 명세되는 기능 또는 동작

• concern을 더 작고 관리하기 쉬운 조각으로 분리함으로써 문제를 해결하는데 소요되는 시간과 노력이 감소

!21


Modular Design“modularity is the single attribute of software allows a program to be

intellectually manageable” - Myers, G.

• monolithic 소프트웨어는 쉽게 파악할 수 없음 • 제어 경로 및 변수의 수, 참조 범위, 전반적 복잡성은 이해를 불가능에 가깝게 함

→모든 경우, 설계를 여러 모듈로 나누고 이해를 용이하게 하며 소프트웨어 구축 비용을 절감

쉽게 빌드, 변경, 수정, …

!22


Modularity : Trade-offs

!23


Information Hiding

!24


Information Hiding - Why?

• 부작용 (side effects)의 가능성 감소 • 지역 (local) 디자인 결정의 전체적 영향 (global impact) 제한 • (controlled) 인터페이스를 통한 커뮤니테이션 / 상호 작용 강조 • 글로벌 데이터 사용 자제 • 캡슐화 (encapsulation)의 촉진 : 고품질 디자인의 속성 • 고품질 소프트웨어를 만들기 위해서

!25


Stepwise Refinement

!26


Functional Independence

• 단일성 기능을 갖춘 모듈을 개발하고 다른 모듈과의 과도한 상호 작용에 대한 혐오를 가지고 모듈을 작성하여 달성

• 응집력 (cohesion) : 모듈의 상대적 기능 강도를 나타내는 지표 • 응집력있는 모듈은 프로그램의 다른 부분에있는 다른 구성 요소와의 상호 작용이 거의 필요없는 단일 작업을 수행 (이상적으로는 단 한가지만 수행)

• 결합도(coupling) : 모듈 간 상대적 상호 의존성을 나타내는 지표 • 결합도는 모듈 간의 인터페이스 복잡성, 모듈에 대한 접근 혹은 참조가 일어나는 지점, 어떤 데이터가 인터페이스를 통해 전달되는 가에 의존

!27


Functional Independence

!28


Refactoring

• 1999, Martin Fowler : • “Refactoring is the process of changing a software system in such a

way that it does not alter the external behavior of the code [design] yet improves its internal structure."

• 소프트웨어가 리펙터링되면, 기존 설계의 다음을 검사 • 중복성 (redundancy) • 사용 되지 않은 설계 요소 • 비효율적이거나 불필요한 알고리즘 • 잘못 작성되거나 부적절한 자료 구조 • 더 나은 설계를 산출하기 위해 수정할 수 있는 다른 설계 상 오류

!29


The Design Model

!30


Design Model Elements• 데이터 요소 (data elements)

• 데이터 모델 → 자료 구조 • 데이터 모델 → 데이터베이스 아키텍처

• 아키텍처 요소 (architectural elements) • 응용 분야 (application domain) • 분석 클래스와 클래스들의 관계, 협업 (collaborations) 및 행동이 설계 실현으로 변형 됨 • 패턴 및 스타일 (@ later lectures)

• 인터페이스 요소 (interface elements) • 사용자 인터페이스 (UI) • 타 시스템, 장치, 네트워크 또는 다른 정보 생산/소비자에 대한 외부 인터페이스 • 다양한 설계 컴포넌트 사이의 내부 인터페이스

• 컴포넌트 요소 (component elements) • 배포 요소 (deployment elements)

!31


Data Elements

• 데이터 혹은 정보에 대한 사용자의 시각을 묘사한 고급 모델 • 자료 구조 및 연산자의 설계는 고품질 응용 프로그램을 작성하는 데 필수적

• 데이터 모델을 데이터베이스로 변환하는 것이 시스템 비지니스 목표 달성에 필수적

• 데이터베이스를 데이터 웨어하우스로 재구성하면 비지니스 자체의 성공에 영향을 미칠 수 있는 데이터 마이닝 및 지식 발견 (knowledge discovery)를 가능하게 함

!32


Architectural Elements

• 소프트웨어 제품의 전반적인 견해를 제공 • 다음으로부터 파생 :

• 소프트웨어와 관련된 응용 분야에 대한 정보 • 특정 분석 모델 요소 간의 관계 및 협력 • 아키텍처 패턴 및 스타일의 가용성 (@ later lectures)

• 일반적으로 요구 사항 모델 내의 분석 패키지에서 종종 파생되는 일련의 상호 연결된 시스템 집합으로 표시 됨

!33


Interface Elements

• 인터페이스 : 클래스 외부에서 관찰 가능한 동작을 나타내고 public 연산에 대한 엑세스를 제공하는 연산의 집합

• 중요 요소들 : • 사용자 인터페이스 (UI) • 타 시스템, 장치, 네트워크 또는 다른 정보 생산/소비자에 대한 외부 인터페이스

• 다양한 설계 컴포넌트 사이의 내부 인터페이스 • UML의 communication diagram을 사용하여 모델화

!34


Interface Elements

!35


Component Elements

• 각 소프트웨어 컴포넌트의 내부 사항을 설명 • 다음을 정의 :

• 모든 지역 (local) 데이터 객체에 대한 자료 구조 • 모든 컴포넌트 처리 기능에 대한 알고리즘 세부 정보 • 모든 컴포넌트 연산에 접근할 수 있는 인터페이스

• UML component / activity diagram, pseudocode (PDL) 을 사용하여 모델화

!36


Component Elements

!37


Deployment Elements

• 물리적 컴퓨팅 환경에서 소프트웨어 기능 및 하위 시스템을 할당하는 방법을 나타냄

• UML deployment diagram을 사용하여 모델화 • deployment diagram의 설명자는 컴퓨팅 환경은 나타내지만 구성 세부 정보는 나타내지 않음

• 특정 이름의 하드웨어 구성을 식별하는 deployment diagram의 인스턴스는 설계의 후기 단계에서 개발

!38


Deployment Elements

!39


Design Principles

• 설계 프로세스 ‘tunnel vision’을 겪지 않아야 함 • 설계는 분석 모델로부터 추적 가능 (traceable) 해야 함 • 설계는 일관성 (uniformity)과 통합성을 보여야 함 • 설계는 변경을 수용할 수 있도록 구조화 • 설계는 비정상적 데이터 및 이벤트가 발생하는 경우에도 부드럽게 저하되도록 구조화

• 설계는 코딩이 아니며, 코딩은 설계가 아님 • 설계는 실현 이후가 아니라 만들어지는 순간부터 품질에 대해 평가

• 설계는 개념적 (의미적) 오류를 최소화하기 위해 검토

!40


Object-Oriented Design Concepts

• 설계 클래스 • entity 클래스 • 경계 (boundary) 클래스 • 제어 (controller) 클래스

• 상속 (inheritance) • 수퍼 클래스의 모든 책임은 모든 서브 클래스에 즉시 상속 됨

• messages • 수신 객체에서 발생하는 어떤 동작을 실행

• 다형성 (polymorphism) • 설계를 확장하는데 필요한 노력을 크게 줄이는 특성

!41


Object-Oriented Design Concepts

• 설계 옵션 : • 클래스는 처음부터 설계되고 만들어질 수 있음 (상속 없이) • 클래스 계층 구조를 검색하여 상위 계층의 클래스 (슈퍼클래스)가 필요 속성 및 연산을 대부분 가지는지 판단할 수 있음 - 새로운 클래스는 슈퍼클래스에서 상속되며 필요에 따라 추가적인 부분이 더해질 수 있음

• 클래스 계층 구조는 새로운 클래스가 속성과 연산을 상속받을 수 있도록 재구성 가능

• 기존 클래스의 특징은 새로운 클래스에서 재정의 (override) 될 수 있으며, 다른 버전의 속성과 연산으로 구현

!42


Messages

!43


Polymorphism• 기존 접근 방식 …

• 모든 그래프는 ’graph’라고 불리는 일반 (general) 클래스의 하위 클래스로 정의 • overloading이라는 개념을 사용하여 각 하위 클래스는 ‘draw’라는 연산을 정의 • 객체는 하위 클래스들 중 하나에서 인스턴스화 된 객체들 중 하나에 ‘draw’ 메세지를 보낼 수 있음 - 메세지를 받은 객체는 자체’draw’ 연산을 호출하여 적절한 그래프를 생성

!44


Design Classes• 분석 클래스는 설계를 거쳐 entity 클래스로 구체화 됨 • 경계 (boundary) 클래스는 사용자가 소프트웨어 사용 시 보고 상호 작용하는 인터페이스 (예, interactive screen or printed reports)를 생성하기 위해 설계 중 개발 됨 • entity 객체가 사용자에게 표현되는 방법을 관리하는 책임

• 제어 (controller) 클래스는 다음을 관리하기 위해 설계 됨 • entity 객체의 생성과 업데이트 • entity 객체로 부터 정보를 얻을 때 경계 객체 인스턴스화 • 객체들 사이의 복잡한 커뮤니케이션 • 객체들 간 또는 사용자와 애플리케이션 사이에 전달되는 데이터의 유효성 검사

!45


Design Classes Characteristics

• 완전 (complete) & 충분 (sufficient)

• 필요한 모든 속성과 메쏘드 포함 • 클래스의 의도 달성에 필요한 메쏘드 만 포함

• 윈시적 (primitiveness) • 각 클래스의 메쏘드는 하나의 서비스 제공에 집중

• 높은 응집력 (cohesion)

• 작고, 집중적이며, 단일성을 가진 클래스

• 낮은 결합도 (coupling) • 클래스 사이 협력은 최소한으로 유지

!46


Analysis Class & Design Class

!47

Design Engineering - Hanyang · 2018-05-13 · - GoF(Gang of Four) : Gamma E., Helm R., Johnson R.,...

Documents

Transcript of Design Engineering - Hanyang · 2018-05-13 · - GoF(Gang of Four) : Gamma E., Helm R., Johnson R.,...