소프트웨어 분석 및 설계 4주차 정리

 

 

 

구조모델과 개념모델

 

• 구조적 모델(structural model)은 비즈니스 시스템에서 생성 및 사용되는 객체를 표현하는 formal한 방법이다. 구조적 모 델은 문제를 구성하는 사람, 장소 또는 사물과 이들이 서로 어떻게 관련되어 있는지를 보여준다. 
• 구조적 모델은 반복적인 프로세스를 통해 모델링되며, 모델 은 시간이 지남에 따라 더 상세하게 구성된다. 분석가는 객 체의 논리적 구성을 보여주는 개념적 모델을 그리지만, 객체 가 어떻게 저장, 생성 또는 조작되는지는 나타내지 않는다. 
• 이 모델은 구현이나 기술적 세부사항이 없으므로(주로 설계나 구현에 필요한 정보), 분석가는 모델을 시스템의 실제 비즈니스 요구사항에 맞추는 데 더 집 중할 수 있다.
• 설계에서 분석가는 개념적 구조적 모델을 객체가 데이터베 이스와 소프트웨어에서 어떻게 구성될지를 반영하는 설계 모델로 발전시킨다.

 

구조모델 – core elements

 

 

 

구조모델 – core relationship

 

 

 

연관 (association)

• 클래스 모형의 주된 목적은 서로 관련된 클래스들 간의 관계를 보 여주는 것이다. (A primary purpose of a class diagram is to show the relationships, or associations, that classes have with one another)
• 연관은 클래스들의 관계를 적절히 표현하는 연관명과 다중성 정보를 표현하는 선으로 나타낸다.

 

 

 

 

 

 

연관과 다중성

 

연관관계에서는 객체의 대응 관계를 표현하는 다중성(multiplicity) 의 표현을 할 수 있다

 

 

 

 

Design Pattern <- singleton pattern 

 

 

 

연관을 표현하는 클래스

 

연관은 경우에 따라 이를 담당하는 클래스에 의해 표현되며 이를 연관클래스 (Association class)라 부른다.

 

 

중간에 관계를 각자 관계 테이블로 표시해주었다. 

 

 

 

구조 모델 예 – pattern sample

 

 

 

다음은 앞의 패턴들을 결합한 예이다

 

 

 

 

상품과 서비스를 있을 때 개별적으로 놨두게 된다면 아무런 관계가 없게 된다 따라서 아이템으로 연결한 것 

아이템 -> 상품 혹은 서비스 

상품 혹은 서비스는 아이템으로 일반화 된다 

 

 

일반화 관계 (Generalization Relationships)

 

• 일반화 추상화(generalization abstraction)를 통해 분석가는 다른 클래스의 속성과 연산을 상속하는 클래스를 만들 수 있다.
• 분석가는 여러 하위 클래스에서 사용될 기본 속성과 연산을 포함하는 슈퍼클래스를 만든다. 하위 클래스는 슈퍼클래스의 속성과 연산을 상속하며, 또한 고유한 속성과 연산을 포함할 수 있다.
• 예를 들어, 고객 클래스와 직원 클래스는 공통된 속성과 연산을 추출하여 새 슈퍼클래스인 Person에 배치하여 사람 클래스로 일반화 할 수 있다.
• 이런 식으로 분석가는 클래스 정의의 중복을 줄여서 공통 요소를 한 번 정의한 다음, 하위 클래스에서 재사용할 수 있다.
• 일반화는 a-kind-of 관계로 표현되므로, "직원은 a-kind-of Person"이라고 한다. 
• 분석가는 또한 일반화의 반대편인 특수화(specialization)를 사용하여 기존 클래스에서 새 하위 클래스를 만들 수 있도록 하여 추가 클래스를 발견할 수 있다

 

 

일반화 (Generalization)

• "is-a" / "a-kind-of" 관계
  예: 직원은 사람의 일종이다 → Employee is a kind of Person
• 공통 속성과 연산을 슈퍼클래스로 추출
  중복 제거 및 재사용성 증가
• UML에서 일반화는 삼각형 화살표로 표현됨 (하위 → 상위)

 

특수화 (Specialization)

• 기존 슈퍼클래스를 기반으로 하위 클래스를 만들어 구체화
• 특정한 속성이나 연산을 가진 서브클래스를 정의
  예: Person → Customer, Employee, Student 등

 

 

 

 

 

UML에서 일반화는 삼각형 화살표로 표현됨 (하위 → 상위) 

 

 

 

• 농구 선수에 있어 가드, 포워드, 센터의 구분은 그들의 역할에 따라 구분됨
• 이 경우 공통 속성과 오퍼레이션은 부모 클래스에서 정의함
• 해당 오퍼레이션은 해당 클래스에서 정의 및 구현을 원칙으로 함
• 추상 클래스 -> 만약에 상속받은 모든 것이 내 책임이면 부모클래스는 구현을 할 수 없기 때문에 부모 클래스는 추상 클래스로 존재하게 된다 
• 일반 클래스 -> 추상 클래스와 반대로 부모클래스가 자기의 객체를 가질 수 있을 때 

 

추상 클래스란?

• 인스턴스를 만들 수 없는 클래스
• 주로 공통된 속성과 연산을 정의하지만, 일부 기능은 하위 클래스에서 구현하도록 강제함
• 일반화 과정에서 공통 구조를 정의하면서도, 구체적인 동작은 자식 클래스에 위임하고 싶을 때 사용됨

 

 

상속(inheritance)   => 일반화라고 봐도 무방

 

• 상속은 부모클래스의 속성과 오퍼레이션을 동시에 전달하며 따라서 선택적 상속이 안 됨
• 상속은 부모가 단수인지 혹은 복수인지에 따라 단일 상속과 다중 상속으로 구분됨
• 상속의 장점: 상속은새로운 클래스를 정의할 때 기존 클래 스를 기반으로 재사용 함으로써 점증적으로 (incremental) 개발이 가능하도록 한다 
• 상속의 단점: 슈퍼클래스의 오퍼레이션과 속성을 재정의 (redefinition)하는 과정에서 충돌(conflict)이 발생한다.
  • 예로서, 만일 Employee가 새로운 메서드를 추가할 경우, 예를 들어 updateSchedule()가 추가된다면 이는 하위 클래스 , 예를 들어 Doctor가 가진  updateSchedule() 메서드와 충돌한다.
• 다른예로, 다중 상속의 충돌도 발생가능하다 
  • Employee와 Robot 둘다 name, runningTime 이 겹친다 

 

 

 

 

 

 

 

 

 

다형성(polymorphisom)

 

 

• 다형성을 통해 객체는 동일한 메시지를 여러 객체에 보낼 수 있다. 이 때 동일 메시지는 각기 다른 객체 혹은 클래스에 따라 다르게 해석된다.
• 다형성의 장점: 캡슐화와 정보은닉에 기반하여 객체는 다른 객체 사용시 어떻게 처리되는지에 관해 몰라도 된다. 
• 동적 바인딩(dynamic binding)은 실행시간에 객체의 데이터 타이핑을 결정짓는 메카니즘이다. 
  • 예: Employ 상속에서 computePay()를 독립적으로 구동시키는 다형성의 경우
• 다형성의 단점: 동적 바인딩이 적용될 경우 어떤 객체가 메시지를 처리할 지 결정되는 않는 경우가 발생할 수 있다. 결과적으로 코드가 없는 객체로 메시지가 전달될 수 도 있으며 이는 시스템 에러의 원인이 된다.
  • 예를 들어, 아래의 경우 Employee, Customer 모두 computePay() 메소드를 갖지만 Customer의 메소드가Employee와는 전혀 다른 계산방식을 가질 경우 의미적인 일관성(semantically consistent) 문제를 발생시킨다

 

 

의미적 일관성 문제 (Semantically Consistent)

• 모든 하위 클래스가 같은 메서드를 가지더라도 의미가 달라질 수 있음

 

 

 

 

 

 

 

 

A a = new A(); 

B b= new A(); 

 

a.computepay()

b.couputepay()   

--> 바인딩 문제 

 

 

일반화 <- is kind of 관계 

          

 

복합관계(Aggregation Relationships)

is part of 관계 aggregation 

 

 

• 데이터 모델링, 지식 표현(knowledge representation), 언어학 등의 분야 에서는 집합이나 복합(aggregation or composition) 유형이 빈번히 사용 되어 왔다.
• 예를 들어, 논리적 또는 물리적으로 a-part-of, 집합 멤버십에서와 같이 a-member-of, 포함됨, 관련됨 및 연관됨의 개념이 있다. 
• 일반적으로 모든 복합 관계는 부분을 전체에 연결하거나, 부분을 부분 (assemblies)에 연결한다. 이를 위해 a-part-of 또는 has-parts 의미 관 계를 사용하여 집합 추상화를 표현한다. 
• 예를 들어, 문은 자동차의 a-part-of이고, 직원은 부서의 a-part-of이며, 부서는 조직의 a-part-of이다. 
• 일반화 관계와 마찬가지로, 복합 관계도 복합 계층으로 결합될 수 있다. 예를 들어, 피스톤은 엔진의 a-part-of이고, 엔진은 자동차의 a-part-of 이다.
• 복합 관계는 양방향이며, 집합의 반대는 분해(decomposition)이다. 예를 들어, 문과 엔진이 자동차의 일부라면, 자동차에는 문과 엔진이라는 부품이 존재하게 된다.
• 분석가는 다양한 부품 사이를 옮겨 다니며 새로운 부품을 발견할 수 있다.

 

 

 

 

 

일반화(Generalization)와의 차이

 

 

 

Aggregation vs Composition

 

 

 

 

복합연관 (Aggregation) 강한 관계 

 

 

• 하부 클래스는 상위 클래스에 대해 종속적임
• 따라서 상위 객체 제거 시 하부 객체 역시 자동 제거됨
• 객체와 객체 간의 관계를 part-of 관계를 표현함
• 상위 객체의 분해 (decomposition)관계로도 이해할 수 있음

 

 

 

 

집합연관(Association) 느슨한 관계 

• 하나 이상의 클래스가 모여 새로운 클래스를 형성할 경우에 표 현함
• 복합연관과 유사한 part-of 관계이나 느슨한 (loosely coupled) 관계인 점에서 차이를 보임

 

 

 

 

추상클래스 (abstract class)

 

 

• 일반 클래스와는 달리 추상클래스는 객체를 생성하지 못함
• 따라서 생성자 (constructor)와 소멸자 (destructor) 등의 오퍼레이션을 정의하지 않음
• 오퍼레이션의 선언은 포함하지만 오퍼레이션의 구현을 제공하지 않음
• 다른 클래스를 정의할 때 규칙을 제시하는 용도로 사용됨

 

 

 

추상 클래스의 코드예

 

 

 

 

 

클래스 vs 객체 다이어그램

 

• 객체 다이어그램은 클래스 다이어그램에 기반하여 작성되지 만 객체간 특정 상황을 묘사함
• 예로서 체스게임의 객체 다이어그램은 아래의 특정 상황을 묘사하 는데 사용될 수 있음

 

 

객체를 밑줄로 그어서 표시한다 

Association (연관 )  -> link의 객체화

 

 

객체 다이어그램은 클래스 다이어그램의 인스턴스(객체) 상태를 나타낸다 

 

인터페이스 클래스

• 일련의 서비스를 제공하기 위해 여러 개의 클래스가 상호 작용할 경우 사용함
• 이 경우 컴포넌트 단위로 포장되는 것이 일반적임
• 컴포넌트의 서비스를 전담하는 클래스를 인터페이스 클래스라 함
• 컴포넌트 서비스는 실체화(realization)가 필요함

 

 

세탁기의 예에서 세탁기와 세탁기 제어부는 논리적으로 분리된 두 클래스임

세탁기 제어부는 Control Knob이라 불리는 인터페이스 클래스로 표현가능함 

아래의 두 표현은 동일한 인터페이스를 표현한 것임

 

 

 

 

api는 함수들의 집단 인터페이스 클래스 도 함수들의 집단 

 

 

인터페이스의 표현

 

 

• 인터페이스 클래스는 구현부 (realization)과 사용부 (use)부 분으로 구분되어 표현함 
• WashinMachine은 ControlKnob 인터페이스 클래스의 구현을, Person은 ControlKnob 인터페이스의 사용을 표현함

 

 

 

인터페이스와 실체화

 

• 컴포넌트 스펙 부분과 구현 부분을 분리하면 구현부의 변경이 발생 해도 인터페이스를 사용하는 외부 클래스의 변경은 발생하지 않음 
• 이는 클래스의 유지보수에 도움을 줄 수 있는 구조임

 

 

 

 

• 인터페이스 클래스에는 종종 Ibilling, ICustomerMgt와 같은 인터페이스 명칭이 부여됨

 

 

 

인터페이스 클래스

• 인터페이스 클래스는 다른 클래스 생성의 규약으로 사용됨
• 이를 통해 다형성을 지원하고 코드의 유연성을 높임