[소프트웨어분석및설계🛠️] 7장 객체지향방법론

전공과목 정리/소프트웨어분석및설계

[소프트웨어분석및설계🛠️] 7장 객체지향방법론 - (1) 기능 모델링

최연재 2024. 9. 8. 14:14

출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)

1. 객체지향 기술 개요

1.1 객체지향 기술 개요

1) 1970년대

- 프로그램을 여러 개 작은 부분으로 쪼개 개발하는 구조적 개발 방법론 이용

- 프로그램의 논리와 데이터를 분리해서 소프트웨어를 설계 ➡️ 개발단계별로 자연스럽게 연결되지 않고, 유지보수 비용이 이 많이 발생

⭐ 객체지향 개발방법론 등장

: 인간이 사고하는 방식대로 프로그램을 개발하려는 노력으로 탄생

2) 1990년대

: 여러 SW 기술 중 가장 중요한 기술로 인식

SW 위기 현상이 객체지향 기술로 인해 해결될 수 있다는 공감대 형성
소프트웨어 생산 기술의 초점이 프로그래밍에서 분석, 설계로 옮겨지며 더욱 주목받음
개발생산성을 높이는 방법을 제공
일관된 소프트웨어 개발 모델 제공

3) 객체지향 기술

- 구조적 개발 방법 : 조그만 변화에도 영향이 크다.

- 함수와 자료를 함께 객체로 추상화 ➡️ 변화에 영향을 덜 받음

- 장점

추상화, 정보 은닉 등 설계 원리에 충실
복잡함을 잘 다룰 수 있음.

- 특징

뚜렷하게 구별되는 단위인 객체(object)로 분할
코드 재사용에 의하여 생산성을 높임
빠른 속도로 적용, 산업계 표준화

2. 객체지향의 개념

2.1 객체지향 방법론의 핵심 개념

1) 객체지향 방법론

- 현실세계의 개체(entity)를 속성과 메소드로 결합시킨 객체 형태로 표현하는 개념

- 객체 간의 메시지 통신을 통해 시스템을 구현하는 개발 방법

2) 객체지향의 기본 원리

- 캡슐화, 정보 은닉

- 상속 (Inheritance)

- 다형성 (Polymorphism)

- 추상화

3) 객체 (Object)

- 현실세계에 존재하거나 생각할 수 있는 개념을 표현

- 객체가 되기 위해서는

상태를 가져야 한다.
- 객체가 가지는 자료 값이 상태를 표현함
- 시간이 흐르면서 변할 수 있다.
잘 정의된 오퍼레이션이 있어야 한다.
- 객체의 오퍼레이션은 동작을 결정
- 객체 외부에서 요구할 때 오퍼레이션을 호출
고유한 Identity가 있어야 한다.
- 객체를 구별할 수 있는 수단

4) 클래스 (class)

- 공통의 속성과 행위를 가진 객체를 묶어 추상화한 개념

- 인스턴스 (instance) : 클래스에서 파생된 하나의 실제 객체

- object = instances of classes

5) 클래스와 객체

- 클래스는 개념적인 의미, 객체는 구체적인 의미

- 한 클래스에서 생성된 객체들은 같은 속성과 같은 연산에 대한 정의를 가짐.

2.2 객체지향의 원리

1) 상속 (Inheritance)

- 객체지향 패러다임만이 갖는 고유 특성

- 클래스 간의 계층 구조를 통해 상위 클래스의 모든 특징을 물려받는 것

- 이미 정의한 클래스를 재사용하고, 확장할 수 있도록 지원

2) 캡슐화 (encapsulation)

- 객체에 대한 외부로부터의 접근을 제한

- 관련된 항목을 모아서 하나의 단위로 취급하는 것

- 객체 내부의 변경이 시스템 전체에 주는 영항을 최소한으로 억제

3) 데이터 은닉 (information hiding)

- 캡슐화와 비슷한 개념으로 객체의 상세한 내용을 객체 외부로부터 숨김

- 메시지를 통한 객체들 간의 상호작용

외부에서 알아야 할 내용만 공개, 나머지는 숨김
대상을 단순화시킬 수 있음
독립성, 유지보수성, 이식성

- 객체지향 언어의 접근제어 방식으로 구현 : public/private/protected

4) 다형성 (polymorphism)

- 프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메소드 등)이 다양한 data type에 속하는 것이 허용되는 성질

- 서로 다른 객체가 동일한 메시지에 대해 서로 다른 방법으로 응답할 수 있는 기능

overriding : 같은 이름의 메소드가 여러 클래스에서 다른 기능을 하는 것
overloading : 같은 이름의 메소드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것

🎁 추상화 (abstraction)

- 대상의 특정한 목적에 관련된 정보에 집중하기 위해, 중요하고 관련 있는 부분만을 추출해 간결하게 기술하는 것

- 보는 관점(view)에 따라 사물이나 정보의 중요성이 달라지므로 여러가지 관점(perspective)에 따라 설명

3. 객체지향 개발의 특징

3.1 반복적인 프로세스

: 소프트웨어 생명 주기를 반복하여 적용하도록 제안

3.2 솔기 없는 프로세스

: 프로세스를 구성하는 간 단계 간의 경계선이 불분명

3.3 상향식 접근 고려

cf) 구조적 방법론 : 하향식 (Top down) 프로세스 사용

3.4 재사용을 고려

cf) 구조적 방법론 : 성공적인 소프트웨어 산출물을 만들고자 하는 개발 공정에 치중

4. 기능 모델링

4.1 기능 모델링

1) 기능 모델링

- 기능을 정리하고 표현하는 기법

- 소프트웨어 개발자가 최종 프로덕트에 대한 비전을 사용자와 함께 공유

- 현재 시스템을 기능의 관점에서 파악하여 새로운 시스템의 전반적인 밑그림을 그리는 작업

- 프로토타입, 유스케이스(표현의 명확성과 간편함 확보 가능), 자연어 등을 이용

2) 유스케이스 기반의 분석 작업

- 유스케이스 다이어그램의 내용을 유스케이스에서 자세하게 작성

- 유스케이스 시나리오는 테스트 시나리오를 정의하는 효과적인 방법

- 비즈니스 프로세스를 파악하여 소작업을 액티비티

- 작성한 기능적 모델은 사용자 요구에 맞는지 검토 필요

3) 유스케이스 작성 목적

- 외부 액터에 의해 인식되는 시스템의 기능과 요구사항을 보여주기 위함

- 시스템의 범위를 정하는 데 도움이 됨

- 개발 과정을 계획한느 데 사용

- 요구사항을 개발하고 정의하는 기초

- 사용자 매뉴얼을 구성하는 데 사용될 수 있음

4.2 유스케이스

1) 유스케이스 (Use Case, 사용사례, 쓰임새)

- 외부에서 본 시스템의 뷰

- 시스템에 무슨 서비스가 있는지 사용자의 관점으로 본 것

- 시스템과 외부 액터(actor) 사이의 목표 지향적(goal-oriented) 인터랙션의 집합

- 유스케이스 : 일반적인 이벤트의 흐름을 모아 놓은 것

- 유스케이스 다이어그램 : 유스케이스의 인스턴스

2) 유스케이스 시나리오 작성 이유

- 유스케이스 파악 : 유스케이스는 개별 시나리오의 모임 ➡️ 유스케이스를 쉽게 파악 가능

- 테스트에 도움 : 시나리오 순서에 따라 값을 입력하고 시스템의 반응 확인

4.3 유스케이스 다이어그램

; 구성요소 = 액터 + 유스케이스 + 관계

1) 액터

- 시스템으로부터 서비스를 받을 필요가 있는 외부 요소

- 사람이 할 수 있는 역할, 시스템, 기관, 조직 등

- 시스템에 입력을 주고 출력을 받는 외부 요소

시스템의 주된 사용자
시스템과 상호작용하는 다른 시스템
시스템의 출력에 관심을 갖는 요소

2) 유스케이스

- 액터에게 서비스를 제공하기 위해 시스템이 수행하는 중요 프로세스

- 유스케이스 이름은 작업을 의미함.

- 단일 유스케이스가 여러 액터에 의해 구동될 때

작업의 흐름이 동일 ➡️ 같은 유스케이스
이벤트 흐름이 다름 ➡️ 다른 유스케이스

3) 유스케이스 다이어그램의 관계

- 연관관계 (association)

커뮤니케이션 관계로 유스케이스와 액터 사이의 관계
액터와 유스케이스 사이에 상호작용이 있음을 표현
유스케이스들 사이에서는 연관관계가 나타나면 안 된다.

- 의존관계 (dependency) : 유스케이스들 사이의 관계

포함관계
- 공통의 유스케이스를 별도로 정의
- base 유스케이스를 실행하기 위해 반드시 included 유스케이스가 실행되어야 한다.
확장관계
- 존재하는 유스케이스의 동작을 조건적으로 확장
- 이벤트의 추가나 예외적인 케이스
일반화관계 (generalization)
- 유스케이스 - 유스케이스
- 액터 - 액터

- 일반화관계 (generalization)

유스케이스 - 유스케이스
액터 - 액터

4..4 유스케이스 작성

; 유스케이스 안의 동작을 글로 서술 (상호작용을 더욱 자세히 작성)

1) 유스케이스 사건 흐름

- 기본 흐름

유스케이스의 여러 시나리오 중 가장 일반적이고 정상적인 상황을 나타내는 하나의 이벤트 흐름

- 대안 흐름 (Alternative Flow)

한 유스케이스에서 기본 흐름이 표현하는 상황을 제외한 모든 다른 상황
수행이 끝나면 기본 흐름으로 돌아오는 경우도 있고, 대안 흐름에서 종료되는 경우도 있음
선택 흐름과 예외 흐름

5. 시스템의 동작을 이해하기

5.1 시스템의 동작 이해하기

- 분석 단계에 워크플로우를 표현하는 방법

액티비티(activity)는 비즈니스 작업(프로세스)을 나타낸다.
액티비티 사이의 제어흐름을 보여주는 흐름도로 워크플로우 표현

- 객체지향 모델링에서는 액티비티 다이어그램

- 액티비티 다이어그램의 사용

시스템 수준 : 시스템과 상호작용하는 각 액터의 관점에서 모델링
메소드 수준 : 복잡한 오퍼레이션의 수행흐름을 표현

5.2 액티비티 다이어그램

액션/액티비티	액션 : 분할할 수 없는 동작 액티비티 : 액션의 집합
시작/종료	액션이나 액티비의 시작과 모든 액티비티 종료
흐름종료	특정 제어흐름이나 객체 흐름이 종료
선택/병합	선택 : 제어흐름이 흘러가기 위한 테스트 조건 병합 : 여러 경로가 하나로 합해지는 것
포크/조인	포크 : 액티비티의 흐름이 병렬적으로 수행됨 조인 : 액티비티의 병렬흐름이 다시 합해지는 시점
객체 노드	객체 흐름에 연결된 객체
제어 흐름	실행의 순서를 나타냄
객체 흐름	한 액티비티에서 다른 액티비티로 객체의 흐름
스윔레인	액티비티의 수행을 담당하는 역할에 따른 분할 선