3. Object-Oriented Analysis(OOA)

이 단계를 잘해놓으면 implementation은 직관적으로 잘 된다.

우선 OOA에 대해서 자세히 다루기 전에 OOAD와 UML에 대해서 간단히 알아본다.

Object-oriented analysis and design (OOAD)

• software development life cycle에서 가장 중요하다.
• 프로그래밍 언어나 데이터베이스와 같은 것과는 독립적이다.

Analysis

• 목적: 필요한 클래스나 객체를 찾고 설명한다.
• 무엇(what)을 풀어야하고 필요한지 분석한다.
• 중요한 점은 올바른 문제를 풀어야 한다는 것이다. (고객의 요구사항을 잘 이해해야 한다.)

Design

• 해결책(how)의 디자인을 만든다.(UML 활용)
• 클래스나 변수, 함수와 같은 것들이 어떻게 연관되고 호출하는지 그린다.

UML

• UML은 OOAD 프로세스를 시각화하는 표준적인 도구이다.
• UML은 Structure diagram과 behavior diagram이 있다. 그리고 여기서도 엄청나게 많은 종류가 나뉜다.
• 이 수업에서는 Use case, Class, State chart, Sequence, Activity 다이어그램을 배운다고 한다.
  • structure diagram은 class diagram만 배운다.
• Structure diagram은 프로그램이 구조적으로 어떻게 구성되어있는지에 관한 것이고, Behavior diagram은 동작과 관련이 깊다.
  • Behavior diagram는 시스템이 필요로 하는 요구 사항 중 기능을 어떻게 수행하는지 보이기 위해서 필요하다.

Object-oriented analysis

• 시스템의 기능적인 요구사항을 만든다. 목업이나 프로토타입을 만들기도 한다.
• Use-case Modeling, Class modeling, Dynamic modeling의 세 단계가 있다고 한다.
  • 이는 반복적으로 이루어지고, 서로 영향을 끼친다.

OOA Step 1: Use-case modeling

목표: 사용자의 관점에서 functional requirements를 설명한다.

• use case
  • 소프트웨어와 소프트웨어 사용자 간의 상호 작용을 설명
• scenario
  • use case의 인스턴스로, use case가 발생할 때의 상황을 설명한다.
• 몇 가지 질문
  • 사용자는 누구인가?
  • 시스템에 어떤 기능이 있습니까(시스템은 무엇을 합니까)?
  • 시스템은 언제 어디서 사용됩니까?
  • 사용자는 기능과 어떻게 상호 작용합니까?
  • 정상적이고 예외적인 상황에서 어떤 일이 발생합니까?

functional requirements 와 non-functional requirements의 차이를 아는가?

use case diagram

• 사용자가 시스템을 사용하여 수행할 수 있는 작업과 시스템의 응답을 정의한다.
• 다음 용도로 사용
  • 시스템의 functional requirements 모델링
  • functional requirements와 사용자 간의 상호 작용 표시
  • 시스템의 외부(사용자) 보기 가져오기
  • 시스템에 영향을 미치는 내부 및 외부 요인 식별
• 각 use-case에는 고유한 다이어그램이 있으며, 최상위 다이어그램은 보다 구체적인 다이어그램으로 세분화할 수 있습니다.
  • Ex) 병원 정보 시스템에는 진료, 수술 등에 대한 사용 사례 다이어그램이 있습니다.
• 왜 중요한가?
  • 누가 주역인지 확인하다
  • 최상위 요구사항을 식별한다.

syntax

• Actor
  • 대상으로부터 이익을 얻고 외부로부터 이익을 얻는 개인 또는 시스템
• Use Case
  • 시스템 functionality의 주요 부분을 나타냅니다.
  • “Make appointment”와 같이 "동사 + 명사"로 작성
• Association Relationship
  • 행위자 및 사용 사례 연결
• Include Relationship
  • 다른 사용 사례의 필수 포함
• Extend Relationship
  • 다른 사용 사례의 조건부/선택적 포함
• Generalization Relationship
  • 상속

시나리오

• 사용 사례에 기초한 상황 설명
• 시나리오는 종종 실제 사용자를 관찰하고 인터뷰함으로써 도출된다.
• 하나의 Use Case에는 여러 가지 시나리오가 있을 수 있습니다.
• Success scenario: 모든 것이 예상대로 그리고 요구 사항에 따라 작동하는 경우(사용자는 사용 사례에 따라 행동함)
• Exception scenario: 예외적인 일이 발생할 경우(예: 사용자가 실수하거나 네트워크가 다운된 경우 등)
• 시나리오 작성 방법(예: 사용자가 상황에서 수행하는 단계 목록)이 다릅니다.
• 엘레베이터의 예시가 나온다.
  • 행위는 엘레베이터 버튼 누르기, 층 버튼 누르기뿐인데, 무수한 시나리오가 나온다.

OOA Step 2: Class modeling

필요한 클래스 및 클래스 간의 관계를 식별한다.

• 사용 사례 다이어그램과 시나리오를 기초로 사용한다.
• 단계
  1. 객체를 식별하고 클래스로 그룹화합니다.
  2. 클래스의 인스턴스 변수 정의
  3. 학급 간의 관계 파악
• 객체 지향 설계 시 정의될 수 있으므로 method는 아직 정의되지 않습니다.
• class diagram으로 객체 모델링 결과를 제시할 수 있습니다.

Class Diagram

• 클래스의 관점에서 소프트웨어 아키텍처를 보여주는 다이어그램
  • 인스턴스 변수(attributes) 및 메서드(operations)
  • 클래스 간 관계
• 클래스 다이어그램에서 코드를 생성할 수 있으며, 그 반대의 경우도 가능하다.
• 다음은 클래스/객체 간의 관계를 설명하는 데 사용되는 가장 중요한 용어이다.
  • Association, Composition, Aggregation, Dependency, Inheritance, Generalization, Specialization, Realization

Association(HAS-A)

• 모든 오브젝트가 각자의 라이프사이클을 가지고 있고, 어떤 오브젝트가 다른 오브젝트를 소유하지는 않은 경우다.
• 클래스 A는 변수를 사용하여 클래스 B의 메서드를 호출할 수 있다.
• 보통 두 클래스 사이에 있지만, 3개(삼차 연관성)일 수도 있다.
• 선생님과 학생과 같은 예가 있다.

Aggregation(HAS-A)

• Association의 특별한 경우인데, 모든 오브젝트가 각자의 라이프사이클을 가지고 있으며, 한 오브젝트가 다른 오브젝트를 소유하고 있는 경우다.
• 다른 클래스를 구성하는 클래스입니다. 그것은 그것들을 사용한다.
  • 호수와 오리같은 느낌. 오리랑 호수는 사실 독립적이다! 둘 중 하나가 없어져도 나머지 하나는 잘 살 수 있다. 하지만, 하나의 오리가 여러 개의 호수에 있을 수는 없다.
  • 선생님이 어떤 부서에 Aggregation되어 있다고 합시다. 소속된 관계이기 때문에, 한 선생님이 여러 부서에 Aggregation 될 수는 없습니다. 그렇다고 해서 부서가 소멸될 때 선생님도 소멸되는 것은 아니다.
• Composition처럼 "내부" 클래스는 해당 클래스가 속한 클래스 외부에서 사용할 수 있다.

Composition(HAS-A)

• Aggregation의 특별한 경우입니다. 강력하게 연관된 Aggregation이며, 자식 오브젝트는 자신의 라이프사이클을 가지지 않고, 부모 오브젝트가 소멸될 경우 자식 오브젝트도 함께 소멸된다.
• 클래스는 다른 클래스로 구성된다. 소유권이 있다.
  • 즉 최소한 하나 이상 있어야 한다. 인간 몸의 장기같은 느낌이랄까? 둘 중 하나라도 지우면 나머지 하나도 없어져야 한다.
  • 집과 그 안의 방 사이의 관계와 같은 것!
• "내부" 클래스는 해당 클래스가 속한 클래스 이외의 논리적 기능이 없다.

Association vs Composition vs Aggregation

화살표 모양을 잘 보자

Dependency

• 한 클래스(클라이언트)가 특정 시점에 사용하기 때문에 다른 클래스(공급자)에 종속됨을 나타내는 약한 관계이다.
• 즉, 한 클래스가 올바르게 작동하려면 다른 클래스가 필요하다.
• 다른 클래스는 메소드의 매개 변수 또는 로컬 변수다.

Inheritance(IS-A)

왼쪽 대신 오른쪽을 써라. 즉, 멤버 변수를 추가하는걸 추천한다는 것 같다.

• 클래스는 다른 클래스의 데이터(필드)와 기능(메모리)을 상속한다.
• 슈퍼클래스는 추상적이거나 구체적일 수 있습니다.
• 적게 사용해야 한다.
• generalization 또는 specialization라는 용어는 종종 상속을 설명하는 데 사용됩니다.

Generalization

• 클래스 집합에서 공통 인스턴스 변수 및 메서드를 찾고 해당 클래스에 대한 슈퍼 클래스를 만드는 프로세스이다.
• 슈퍼클래스는 하위클래스의 더 일반적인 버전이다.

Specialization

• 전문화는 일반화의 반대이다. 우리는 슈퍼클래스의 전문화된 버전인 하위 클래스를 만듭니다.
• 새 인스턴스 변수 추가 및/또는 메서드 재정의한다.
• 특화된 클래스(즉, 하위 클래스)는 슈퍼 클래스보다 더 좁다.

Realization

• 클래스가 인터페이스를 구현(실현)하고 인터페이스 메서드를 재정의할 때 사용한다.

Visibility and multiplicity

• 인스턴스 변수 및 방법의 visibility를 나타내는 기호이다.
  • + public
  • - private
  • # protected
  • ~ package
• 많은 관계(예: 연관성, 구성, 집계)가 multiplicity을 정의할 수 있으며, 이는 각 측면에 있는 개체 수를 의미한다.

OOA Step 3: Dynamic modeling

이 단계의 목적은 각 클래스에 대한 state chart diagram을 만드는 것이다.

• 개별 객체가 이벤트에 어떻게 반응하는지, 그 결과 객체의 상태가 어떻게 변화하는지 다이어그램으로 보여준다.
  • 내부 이벤트: 소프트웨어의 다른 개체에서 생성된 이벤트다.
  • 외부 이벤트 : 외부 세계에 의해 생성된 이벤트(예: 네트워크 상태)다.
• 우리는 다음을 해야 한다.
  • 중요한 objects 식별(2단계)
  • 상태 식별
  • 상태를 변경하는 이벤트 식별

State chart

• State chart는 개체의 수명 동안의 상태 변경을 설명한다.
  • 한 상태에서 다른 상태로의 제어 흐름.
  • 객체 생성에서 종료까지의 흐름.

state chart syntax

The Results of Object-Oriented Analysis

• OOA 프로세스가 완료되면 시스템의 전반적인 요구 사항을 잘 이해하게 됩니다.
• 좀 더 구체적으로, 우리는 다음을 가지고 있다.
  • 소프트웨어가 사용될 다양한 사용 사례 및 시나리오 설명
  • 중요 클래스, 인스턴스 변수 및 관계 정의
  • 내부 및 외부 이벤트에 따라 개체 상태가 어떻게 변하는지 보여주는 각 중요 개체에 대한 상태 차트 다이어그램