Object Oriented Design

※ tutorialspoint의 OOAD 요약 (https://www.tutorialspoints.com/object_oriented_analysis_design/)

 

분석 단계 후에는, object oriented design을 사용한 object oriented model을 개발. OOD에서는, 분석 모델의 비기술적 concept을 구현 클래스로 매핑하고, 제약 사항을 구분하고, 인터페이스를 설계. 간단히 말해서, concrete technology 기바능로 어떻게 시스템을 구축하는지에 관한 설명.

• Definition of the context of the system
• Designing system architecture
• Identification of the objects in the system
• Construction of design models
• Specification of object interfaces

1. System Design

시스템의 conext를 정의하여, 시스템 아키텍처를 디자인

• Context: static part는, subsystem의 hierarchy로 확장된 전체 시스템의 block diagram으로 설계. subsystem 모델은 UML로 표현. dynamic part는, 시스템과 그 주변 환경이 어떻게 interaction 하는지 설명하며, use case diagram으로 모델링.

• System Architecture: 도메인 지식 뿐만 아니라 아키텍처 설계 원리에 따라 시스템 context를 기반으로 설계. 시스템은 layer로 분할되며, 각 layer는 subsystem으로 분할.

2. Object-Oriented Decomposition

decomposition이란, divide and conquer 원칙에 따라, 크고 복잡한 시스템을 덜 복잡한 작은 component로 나누는 것을 의미. 시스템의 major component는 subsystem으로 불림. object-oriented decomposition은 individual autonomous object와 object간의 communication으로 정의.

decomposition의 장점은,

• 개별 component는 덜 복잡하여, 이해하기 쉽고, 관리하기 쉬움

• 전문 기술을 가진 노동력의 분업을 가능하게 함
• 다른 subsystem에 영향을 주지 않고, subsystem을 교체, 수정을 가능하게 함

3. Identifying Concurrency

concurrency는 1개 이상의 object가 동시에 이벤트를 수신하고, 1개 이상의 activity를 동시에 실행하도록 한다. concurrency는 dynamic model에서 정의하고, 표현.

concurrency를 위해, 각각의 element는 별도의 control thread에 할당. concurrency가 object 레벨이라면, concurrent object는 별도의 control thread에 할당. single object의 2개 operation이 concurrent인 경우, object는 다른 thread로 분할.

data integrity, deadlock, starvation 문제와 연관. 즉, 명확한 strategy 필요. design 단계에서 정의되어야 하며, 구현 단계로 넘기면 안됨.

4. Identifying Patterns

어플리케이션 디자인에 관한 일반적인 것으로 받아들일 수 있는 솔루션을 디자인 패턴이라고 한다.

• Façade pattern
• Model view separation pattern
• Observer pattern
• Model view controller pattern
• Publish subscribe pattern
• Proxy pattern

5. Controlling Events

시스템 설계 중, 시스템의 object에서 발생하는 이벤트를 정의하고 적절히 처리 필요.

4가지 종류의 이벤트가 모델링 될 수 있다,

• Signal Event − 1개 object가 전디고, 다른 object가 처리

• Call Event − operation dispatch를 나타내는 동기 이벤트

• Time Event − 시간의 흐름 표현

• Change Event − state 변화 표현 이벤트

6. Handling Boundary Conditions

시스템 설계는, 각각의 subsystem 뿐만 아니라, 전체 시스템의 initialization, termination 처리 필요. 

• The start–up of the system: non-initialized state에서 steady state로의 전환

• The termination of the system: 모든 동작중인 thread 종료, 리소스 및 모든 메시지 정리

• 시스템 initial configuration과 (필요시) 시스템 reconfiguration

• 시스템 오류 또는 undesired termination

boundary condition은 boundary use case를 이용하여 모델링

7. Object Design

subsystem hierarchy 개발 후, 시스템의 object 정의하고, 세부 사항 설계. 설계자는, 시스템 설계 strategy를 자세하게 설명. 어플리케이션 domain에서 computer 영역으로 전환. analysis 단계에서 정의된 object는 execution time, memory consumption, 전반적인 cost 최소화 목적으로 재정의.

object design은 다음 과정을 포함,

• Object identification
• Object representation, i.e., construction of design models
• Classification of operations
• Algorithm design
• Design of relationships
• Implementation of control for external interactions
• Package classes and associations into modules

Object Identification

첫번째 과정은, object identification. object oriented analysis 단계에서 정의한 object는 class로 그룹화하여 implementation에 적합하도록 세분화.

• 각 subsystem, package의 class identification

• class간의 link, association 정의

• class간의 hierarchical association 정의 (generalization/specialization 및 inheritance)

• aggregation 설계

Object Representation

class 정의 후, object modeling으로 표현 필요. UML diagram으로 구성.

2가지 종류의 design model,

• Static Models: class diagram, object diagram 이용

• Dynamic Models: interaction diagram, state-char diagram 이용

Classification of Operations

이 단계는, object에 대해 처리할 operation과 OOA 단계에서 작성한 object model, dynamic model, functional model 3가지를 결합. operation은 무엇을 해야 하는지를 명시하는 것이 아닌 어떻게 하는 것인지를 명시.

operation 관련 처리되어야 하는 작업들,

• 각 object의 state transition diagram

• object에 의해 수신된 event 정의

• 하나의 event가 동일하거나 다른 object의 다른 event를 trigger하는지 정의

• action 내의 sub-operation 정의

• main action은 data flow diagram으로 확대

Algorithm Design

algorithm을 이용하여 object 내의 operation 정의. algorithm은 문제를 해결하기 위한 단계적 절차. 어떻게 수행되는지에 관심.

주어진 operation에 따라 복수개의 algorithm 가능. algorithm 선택 metric은,

• Computational Complexity: complexity는 compuation / memory consumption 관점에서 효율성 결정

• Flexibility: 선택한 algorithm을 다양한 환경에서 적합도를 잃지 않고 적절하게 구현할 수 있는지에 관한 지표

• Understandability: 이해하기 쉽고, 구현하기 쉬운지에 대한 관점

Design of Relationships

relationship 구현 전략은 object design 단계에서 설명될 필요가 있다. main relationship은 association, aggregation, inheritance로 구성.

설계자는 association 관련 다음을 따른다,

• association이 단방향인지, 양방향인지 정의

• assocation path 분석 및 필요하다면 업데이트

• many-to-many relationship 또는 one-to-one / one-to-many relationship은 별도의 object로 구현

inheritance 관련, 다음을 따른다,

• class와 association 조정

• abstract class 정의

• provision을 생성하여 필요시 behavior 공유

Implementation of Control

object 설계자는 state-chart model의 개선을 포함할 수 있다. 시스템 설계에서, dynamic model에 대한 기본 방향이 구성. object 설계 중 이 방향이 구현을 통해 적절히 구체화 된다.

dynamic model의 구현은,

• Represent State as a Location within a Program: location of control에 의해 프로그램의 상태를 정의하는 전통적인 방법. FSM은 프로그램으로 구현 가능. transition은 input statement을 형성하고 main control path는 instruction sequence를 구성하며, branch는 condition을 구성, backward path는 loop (iteration)을 구성.

• State Machine Engine: state machine engine class를 통해 state machine을 표현. 이 class는 어플리케이션에서 제공하는 transition set와 action을 통해 state machine 실행
• Control as Concurrent Tasks: object를 task로 구현. event는 task간의 호출로 구현. 실제 object의 inherent concurrent 보존.

8. Packaging Classes

대규모 프로젝트에서는, 모듈 / 패키지로의 분할이 중요. object 설계 때는 class, object를 package로 그룹화하여 여러 그룹이 협력할 수 있도록 한다.

패키징의 여러 관점으로는,

• Hiding Internal Information from Outside View: class를 black box로 만들어서, class 내의 변경이 외부 client에게 영향을 주지 않도록 한다.

• Coherence of Elements: class, option, module과 같은 element는 일관된 계획에 따라 구성됨으로써, 일관성을 갖게 된다.

• Construction of Physical Modules

  • 모듈 내의 class는 동일하거나 비슷한 object를 표현해야 한다.

  • 밀접한 class들은 하나의 모듈 내에 존재해야 한다.

  • 관계가 없거나 약한 class들은 별도의 모듈에 존재해야 한다.
  • 모듈은 cohesion을 가져야 한다. (모듈 내 component들의 높은 협력)
  • 모듈은 다른 모듈과 약하게 coupling 되어야 한다. (상호 의존성의 최소화)

9. Design Optimization

analysis model은 시스템의 logical information을 확보하고, design model은 효율적인 access를 위한 세부 사항을 추가한다. design을 구현하기 전에, 최적화를 해야 한다. 최적화는, space와 다른 metric 관점에서의 비용의 최소화이다. 

하지만, 이 최적화는 구현의 용이성, 유지 보수, 확장성과 같은 중요 요소를 배척하지 않아야 한다. 완벽하게 최적화된 설계 모델은 효율적이지만, readbility / reusability가 부족할 수 있다. 즉, 적절한 밸런스를 찾아야 한다.

design optimization에 대한 여러 관점은,

• Add redundant associations
• Omit non-usable associations
• Optimization of algorithms
• Save derived attributes to avoid re-computation of complex expressions

Addition of Redundant Associations

새로운 association으로 access cost를 줄일 수 있는지 확인. association의 추가가 새로운 information을 제공하는 것은 아니지만, 전체적인 모델의 효율화를 만들어낸다.

Omission of Non-Usable Associations

너무 많은 association은 시스템 이해를 어렵게 만들고, 전박적인 효율화를 방행한다. non-usable association을 제거해야 한다.

Optimization of Algorithms

자료 구조, 알고리즘의 최적화는 collaborative manner를 통해 구성된다. class design 완료 후, operation / algrorithm의 최적화가 필요하다.

알고리즘의 최적화는,

• computation task의 재구성
• functional modeld에서 구성된 loop 실행 순서 변경
• dead path 제거

Saving and Storing of Derived Attributes

Derived attribute는 다른 attribution의 function에서 계산되어 나온 attribute를 의미한다. derived attribute의 value를 필요할 때마다 re-computation하는 것은 time-comsuming procedure이다. 이를 피하기 위해, 계산 된 결과를 저장할 수 있다.

하지만, 이것은 base attribute value의 변경에 따른 derived attribute value의 변경에 대한 고려가 필요하다. 이를 위해,

• base attribute value 변경 시마다, derived attribute의 re-computation

• 모든 derieved attribute를 주기적으로 업데이트

10. Design Documentation

Documentation은 SW 개발 과정을 기록하는 필수적인 부분이다. documentation을 통해 design decision 등의 정보를 다른 사람들에게 제공 가능하다.

Usage Areas

proudct의 secondary part이지만, 다음 영역에서 필수적이다,

• 다수 개발들이 참여하는 SW 개발
• 반복적인 SW 개발
• SW 프로젝트의 후속 버전 개발
• SW 평가
• 테스트 정보 확인
• SW 유지 보수

Contents

포함해야 할 contents로는,

• High–level system architecture: process diagram, module diagram

• Key abstractions and mechanisms: class diagram, object diagram

• Scenarios that illustrate the behavior of the main aspects: behavioural diagrams

Features

좋은 documentation의 특징은,

• 간결하고, 더불어 명확하며, 일관적이고, 완전함

• SRS에 따라 tracing 가능

• well-structured

• 설명 보다는 diagram