[Software Engineering] Object Oriented Analysis&Design

OOA (Object Oriented Anlysis) 

OO design Process

OO analysis: 문제의 이해 / Key 컨셉, relationship 식별/ Vocabulary생성 /도메인 모델 생성에 관함.
Communication용 / UML class diagram을 informal notation으로 사용한다.
Starting point of finding class later ( low representational gap) 
Use case or requirement를 input으로 사용한다.
System Behavior 정의 :System sequence diagram, System behavior contract
문제를 Model/ diagram으로, concept 정의:  Domain model Glossary(용어사전)


OO Design: 문제 정의/ class diagram으로 SW class와 relationship 식별 
Responsibility 책정 ( attribute or method) / interaction diagram으로 behavior 탐구
디자인 대안 탐구 / Object model, interaction 모델 생성.
Object의 responsibility 책정, 상호작용(interaction) 정의 : Object interaction diagram
가능성 있는 솔루션을 Model, diagram으로: Object Model 

Implementation: map 디자인 to code, implement class && method.

 

High level SW 디자인 process 

• Project injection(주입)
• Gather requirement
• Define actor, use case
• 문제사항 Model / diagram. Object 정의
• Define system behavior
• Assign object responsibility ( attribute or method)
• Define object interaction
• 잠재적인 솔루션 Model / diagram
• 솔루션 적용 & 테스트
• 유지보수, 발전 ….

도메인의 key abstraction 식별가능한가?, 그들을 도메인 모델로 모델링 가능한가?

- Modeling problem domain
-  domain 의 key 컨셉 식별
- noun(명사), verb, relationship 사이의 컨셉 식별
- non-specific 한 vocabulary는 피한다 ( system 같은)
- operation과 컨셉 식별
- Glossary (용어사전)
- key 컨셉을 정의, 식별
- 애매한거만 정의하면 된다.
- attribute (text or number: 책이름, 저자 ) vs concept( 추상적: 책) 
Concept 구분하기: 
-‘명사’ 찾기,
- 실제하는 것,역할( 어머니,선생님), event(구매,요청), interaction,구조, device,조직
- 도메인 모델링 장점
- 도메인(범위) 이해가능 ( 범위 책정하고 간다)
- Ensure completeness
- agree on common set of term
- prepare to design: 도메인 concept은 Class의 좋은 후보(low representational gap)
- OOA hint
-도메인은 vocabulary 제공
- concept 에 집중 ( SW class, data 에 집중 x) >concept이 class 될 수도, 안될 수도
- model 은 절대 완벽할 수 없다.( partial model> 나중에 추가적으로 확장)

도메인 model VS 데이터 Model : 도메인 모델은 데이터가 저장될 필요가 없다
도메인 model VS object model, java class: 오직 실제 도메인 concept(real word obj, real world abstraction) 만 포함. UI-frame, database 포함 x 
시스템안의 key interaction들 식별가능? 그들을 system sequence diagram으로 표현 가능?

System sequential Diagram

시스템의 범위 내에서 일어나는 event의 순서 나타낸다.
-목표: 시스템의 인터페이스 정의, 식별
- user, overall system 같은 시스템-level의 요소들만 사용.

Behavior Contract:  (formalize System at boundary)

-Sequence diagram안의 어떤 operation의  pre condition, post condition 설명.
Ex) operation: 대여 
Pre-condition: 이미 사용자가 로그인함, 책 재고 남아있음
Post-condition: 새롭게 대여된 아이템을 받는다.

Domain VS Implementation

- domain: level concept: real-world의 거의 모든 것 
-Implement & level concept: “method name”, programming type, visible modifier
Helper 메소드 & 클래스, 디자인 패턴의 artifact

요약

Domain-level representation tool

- domain model
-system sequence diagram
-system behavior contracts
빠르고, 허술하게 ( 반복으로 보완!)
이를 피드백 받는다!

 

 

 

 

OO Design

 

OO analysis

• “문제 인식”domain model, 용어  
• system behavior (system 시퀸스 다이어그램, behavior 다이어그램) 

 

OO Design

• “solution 정의” 
• object의 책임 할당 (Object interaction diagram)
• 잠재적인 솔루션을 model, diagram ( object model)

Object diagram

 컨셉 to class 에 대한 다이어그램이다.

• Interaction diagram: system 영역의 행동.
• Domain model( 문제)  Object model( 해결책)
• Real-world 시스템 implement
• 요구사항, 컨셉 Class, object
• 컨셉 간의 관계 상속관계, object의 reference 
• 문제해결 결과 도출
• 용어 사전 build 해결책 찾기

Design 결정

• design 간의 tradeoff와 이유
• coupling과 cohesion 간의 tradeoff는?
• GRASP 패턴 : 디자인에 responsibility 부여

UML

• 소통의 용도
• 모든 도메인이 class되는 것은 아니다. 

메인 모델                            object 모델

 

class 다이어그램    vs   object 다이어그램

Class 다이어그램: 클래스 명세와 클래스 간의 관계를 표현 (real world)

Object 다이어그램: 인스턴스 간의 관계 표현

Object 모델: class(object) 와 field // interface와 method로 구성.” 타입 “ 명시
Association: 관계를 나타낸다.

Class/object 예시

  
Interface 예시

Association

 

주의점
- field와 메소드에는 각각 변수, 메소드만.
- type 명시!
Association: arrow는  is a( 포함) 제외하면  association 명과 cardinality(1,  n..) 등 만 명시하자!

 

Sequencial Diagram VS Interaction Diagram

• Interaction 다이어그램은, 대안 design을 찾는 것을 돕는다.
• 구성요소 API에 대응하는 상호작용을  적어나간다.
• 시스템 영역안의 상호작용에 대해 표현한다.
  
  

누가 user에게서 아이템을 빌렸는지 아는가? 그리고 누가 late fee(요금) 을 Compute하는가 ? 

Object의 Doing Responsibility : object 생성, 계산 ,다른 오브젝트 컨트롤 등을 포함
Object의 Knowing responsibility: private으로 가려진 data, 관련된 object, 그것이 derive,
계산 할 수 있는 것들을  Knowing 해야한다.

Object design은 domain 모델링처럼 정확하게 영역을 나눌 수 없다? 

• GRASP
• General 
• Responsibility
• Assignment
• Software
• Pattern/Principle

GRASP 패턴

아래와 같이, 총 9개가 존재한다.
1. Information expert

2. Creator

3. Controller

4. Indirection

5. Low coupling

6. High cohesion

7. Polymorphism

8. Protected variations

9. Pure fabrication

Low representational gap (LRG)

Class는 domain 컨셉을 거의 바꾸지 않고 직관적이게 바로 가져와서 쓸 수 있다.

LRG 디자인: domain class 옮겨와서 실제 SW class 로 사용 >> 이건 단지 시작점일 뿐!
Design goal: 초기 상태를 어느정도 잡고 변경하기 위함
어떤 곳에선 실제 설계가 들어가야할 수 있다.

Design Goal

- 변경, 이해, 재사용, 노동 분배를 위함.
Design Principle
- Low coupling, high cohesion
-Low representational gap

Design Heuristic

Information Expert: 역할을 수행할 수 있는 정보를 가지고 있는 객체에 역할을 부여하자.
Creator: 객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여하자.
Controller: 시스템 이벤트(사용자의 요청)를 처리할 객체를 만들자
 Law of demeter: 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙

• 디자인은 quality attribute ( evolvability,  reuse, performance, security,compliance,scalability…) 에 의해 driven 된다.
• Design principle(low coupling, high cohesion, high correspondence,…)은 위의 quality를 충족시키는 가이드라인이 된다.
• GRASP 디자인 휴리스틱(Creator, information Expert, Controller) 은 위의 principle을 촉진시킨다.
  
  

 

 

Low coupling, High Cohesion 

Cohesion(응집도) 

• 하나의 클래스가 담당하는 기능의 정도( 높을수록 필요한 기능만 포함)
• 이게 높을수록 구조가 simple해져서 좋다. (응집도가 높다 >> 주어진 기능만 수행한다)

Coupling( 결합도) 

• 관계가 얽혀 있는 정도 ( 다른 모듈에 의존하는 정도)
• 1개 클래스에 기능 많이, 관계는 적게( 유지보수성!)
• 결합도가 높을수록 구조가 복잡하고 알기 힘들다.

Low coupling

• design for 가독성 ,변경비용, reuse 가능성 향상, 노동 분배 ( 이런 quality를 위한 규칙) 
• Low coupling: 적은 의존성, object 수 감소 >> design for change
• 적은 의존성 > design for 가독성
• 적은 인터페이스: 나누기 쉽다 => design for 노동 분배
• 복잡한 의존성 x => design for reuse.   
• 상속으로 coupling 감소시키자.

Heuristic

데메테르 법칙

• 다른 모듈에 대해 제한된 정보만 알아야. (stranger에게 정보 유출 막기)
• getA().getB().do()  이런거 x  (여러 다리 걸친 놈이 메소드 쓰는 것)

Controller( design heuristic)

시스템 operation과 event를 담당하는 object를 찾아야 한다. => object에 responsibility 부여

• Use case 다이어그램으로 어떤 system event가 발생하는지 체크
• LRG, high cohesion  Principle을 써서  sequence 다이어그램에서 derive해서 만들자.
• (sequence 다이어그램과 유사하지만, object 수 줄이기)
• Controller는 자체로는 하는 일 없고 시스템 이벤트와 중간다리 역할.
•  controller for system수는 적어야한다. >> 특수 task를 위한 controller만 형성
• façade design 패턴과 연관성이 있다!

Controller의 디자인 tradeoff

⦁ coupling 감소 Principle 도움
User 인터페이스와 domain logic은 decouple 되어있고, 둘다 controller에 couple되어있다.
Domain logic 변경>  controller에 영향 ( 바로 UI에 영향 x) UI는 도메인 logic 모른채로 변경가능.

⦁ Reuse를 돕는다. ( quality 도움)
Controller가 domain logic의 인터페이스처럼 동작.
더 작고, 명백한 인터페이스 >> evolvability

하지만,  controller에 다 떄려박으면 오히려 low cohesion, high coupling을 만든다. ( split 하면 될수도)

Cohesion

High cohesion:  자기가 해야 할 것만 (무작정 기능이 적은 게 아닌, 이유 없는 기능을 뭉치지 말기, 즉 무작정 한 class에 때려 넣으면 안된다는 것)

= > 코드 가독성, reuse 가능성 증가

 
그래프는 알고리즘 기능도 포함해야 한다. 
High cohesion: 기능별로 나눠 놓고, 필요한 기능들이 결합되어 사용되어야.
역할 => 가독성, 유지보수성, reuse 가능성 향상되고, low coupling(principle)을 돕는다.
보통 high cohesion 은 적은 기능으로 직결되기도 한다. 

• 1개 class /method에 모든 기능 =>  low coupling, low cohesion
• 모두 분할 => high coupling, high cohesion
• LRG등을 고려하자.

 

Information Expert ( Heuristic)

• 책임을 질 수 있을 정도의 정보가 있는 class에만 책임을 할당하자.
• 객체는 데이터와 처리로직이 함께 묶여 있는 것이고, 자신의 데이터를 감추고자 하면 오직 자기 자신의 처리 로직에서만 데이터를 처리하고, 외부에는 그 기능(역활)만을 제공해야 하기 때문이다.
• Domain class 참고해서 software class 추상적으로 설계하자.
• LRG, low coupling principle 고려해서   domain model에서 derive하자!

 

sale이 총 매출을 알고 있다.

Creator

생성할 객체에 대한 object를 종합하거나, 가지고 있거나, 데이터를 가지고 있거나,…
이런 생성할 객체의 흐름을 알고 있는 객체가 생성하도록 하자.
( 이런 객체가 생성된 객체를 자주 쓰고, reference 될 것이기에)

Process

Low coupling, LRG Principle 고려해서 domain model, interaction 다이어그램에서 추출

 

아래의 문제를 풀어보자.

 

Tree가 beetle 생성해야 한다. ( 책임 가지고 있기 떄문) 

 

• Creator =>  low coupling, high cohesion ( principle) 촉진.
• Evolvability( design for change= quality) 촉진 : object 생성이 숨겨져 있고, replace될 수 있다 

 

Object interaction diagram

   object에 메소드를 추가한다.
- 추가적인 데이터 책임을 보여줄 수 있다
- 추가적인 데이터 타입, architectural 패턴을 보여줄 수 있다.

Object model

중요한 디자인 결정을 집계할 수 있다.
- implementation 가이드라인의 역할을 한다. 

요약

• 디자인은 quality attribute ( evolvability,  reuse, performance, 등) 에 의해 driven 된다.
• Design principle(low coupling, high cohesion, high correspondence,…)은 위의 quality를 충족시키는 가이드라인이 된다.
• GRASP 디자인 휴리스틱(Creator, information Expert, Controller) 은 위의 principle을 촉진시킨다.