- 객체지향 방법론
- 현실세계의 개체(Entity)를 속성과 메소드를 결합시킨 객체 형태로 표현하는 개념
- 객체 간의 메시지 통신을 통해 시스템을 구현하는 개발 방법
- 객체지향의 핵심개념은 객체와 "클래스"이다.
- 객체지향의 기본원리
- 캡슐화(Encapsulation)
- 정보은닉(Information hiding)
- 상속(Inheritance)
- 다형성(Polymorphism)
- 객체(Object)는 현실세계에 존재하거나 생각할 수 있는 개념을 표현한 것이다.
- 객체가 되려면 상태를 가져야 한다.
- 객체가 가지는 자료 값이 상태를 표현한다.
- 시간이 흐르면서 변화할 수 있어야 한다.
- Ex. 강좌의 상태 : open & close
- 객체는 잘 정의된 오퍼레이션이 있어야 한다.
- 객체의 오퍼레이션은 동작을 결정한다.
- 객체가 무얼하는지 결정한다.
- 객체 외부에서 요구할 때 오퍼레이션을 호출한다.
- Ex. 강좌 시간 결정, 수강생 추가, 수강생 삭제
- 객체는 고유한 identity가 있어야 한다
- 객체를 구별할 수 있는 수단이다.
- 객체에 고유한 이름을 부여하여 객체명으로 구분하는 것이 일반적이다.
- 클래스 (class)
- 공통의 속성과 행위를 가진 객체를 묶어 추상화한 개념
- 객체를 구현하는 방법
- 객체의 틀이라고도 한다.
- 인스턴스 (instacne) : 클래스에서 파생된 하나의 실제 객체 (objects = instances of classes), 값을 가지는 것
- Ex. 클래스는 설계 도면으로 이걸 토대로 상체가 만들어지면 객체라고 한다.
- 클래스 & 객체
- 클래스는 개념적인 의미, 객체는 구체적인 의미라고 볼 수 있다.
- 한 클래스에서 생성된 객체들은 같은 속성과 같은 연산에 대한 정의를 가진다.
- 상속(Inheritance)
- 객체지향 패러다임만이 갖는 고유 특성
- 클래스 간의 계층구조를 통해 상위클래스의 모든 특성을 물려받는 것
- 상위 클래스가 가지고 있는 것은 하위 클래스도 자동으로 가진다.
- 이미 정의한 클래스를 재사용하고, 확장 할 수 있도록 지원하는 개념
- 캡슐화(encapsulation)
- 객체에 대한 외부로부터 접근을 제한
- 데이터를 밖에서 함부로 접근할 수 없도록 막은 것
- 공개된 부분인 인터페이스를 통해서면 접근할 수 있도록 한다.
- 접근제어자(private, public)을 통해 손쉽게 제어 가능
- 관련된 항목을 모아서 하나의 단위로 취급하는 것
- 객체내부의 변경이 시스템 전체(외부)에 주는 영향을 최소한으로 억제하낟.
- 데이터 은닉 (information hiding)
- 캡슐화와 데이터 은닉이라는 개념을 거의 같게 본다.
- 캡슐화와 비슷한 개념으로 객체의 상세한 내용을 객체 외부에 철저히 숨긴다.
- 단순히 메시지만으로 객체와의 상호작용을 하게 만든다.
- 외부에서 알아야 하는 부분만 공개하고, 나머지는 숨김으로써(추상화의 원리) 대상을 단순화시키는 효과가 있음 (독립성 → 유지보수성 → 이식성 모두 보장)
- 단위를 꼭 잘 만들어 놔야 한다.
- 객체지향언어의 접근 제어방식으로 구현 : public/private/protected
- 다형성(polymorphism)
- 객체지향 패러다임만이 갖는 고유 특성
- 여러 가지 형태를 가질 수 있다는 것을 뜻한다.
- 프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메소드 등)이 다양한 data type에 속하는 것이 허가되는 성질
- Ex. 같은 이름으로 함수를 만들 수 있음 (이때 매개변수의 구성은 다르게 해야 한다.)
- 즉, 서로 다른 객체가 동일한 메시지에 대하여 서로 다른 방법으로 응답할 수 있는 기능이다.
- Overriding : 같은 이름의 메소드가 여러 클래스에서 다른 기능을 하는 것
- Overloading : 같은 이름의 메소드가 인자의 개수나 자료형에 따라서 다른 기능을 하는 것
- UML(Unified Modeling Language)
- 초기엔 대표적인 모델링 언어
- 객체 지향의 처음과 끝이라고 할 수 있다.
- 객체 지향 방법론 = UML, 거의 대신하는 대상이 되었다.
- 1990년 초기 객체지향 방법론 등장하면서, 표기법의 차이가 문제로 대두 → OMT + OOSE + OOAD 합쳐버림
- 1997년 OMG에 의해 표준 채택이 되었다.
- Object Management Group (OMG) : 컴퓨터 산업 표준화 컨소시움
- 가장 최근 버전 : 2017년 발표된 UML 2.5.1
- 특징 (UML이 제공하는 것)
- 가시화
- SW 개념 모델을 시각적인 그래픽 형태로 표기
- 표기법에 사용하는 기호에 명확한 정의를 부여하는 것
- 의미를 직관적으로 이해할 수 있게 하는 것
- 사용자 요구를 전달 받거나 개발자들 사이의 의사소통에서도 중요하게 사용된다.
- 명세화
- 정확하고 명백하며 완전한 모델을 만드는 것
- 시스템 아키텍처와 모든 상세 내역에 대한 문서화가 가능해지도록 한다.
- 요구사항이 다 들어가 있어야 한다.
- 구축
- UML로 명세화 된 설계 ↔ 소스코드
- 바로 자동 전환/변환 가능
- 가능한 이유 : 객체지향 방법론은 분석과 설계가 구분되어 있지 않기 때문이다.
- UML 확장 메커니즘
- 추가로 필요한 것을 만들어 쓸 수 있게
- 스테레오타입(stereotype)
- 기본적인 요소 외에 새로운 요소를 만들기 위함
- << >> 기호를 사용
- Ex. <<subsystem>>
- 꼬리표값(tagged values)
- 구성 요소가 갖는 속성을 확장하여 구성요소의 명세서에 새로운 정보를 추가
- 값을 지정
- tag = value 기호를 사용
- 제약(constraints)
- 구성 요소에 있는 이전의 규칙을 수정하거나 새롭게 값을 생성하기 위함
- 제약 사항 표시
- 꼬리표값과 함께 사용되기도 함
- { } 기호를 사용
- 1970년대
- 프로그램을 여러 개 작은 부분으로 쪼개어 개발하는 "구조적 개발방법론" 사용
- 프로그램의 논리와 데이터를 분리해서 소프트웨어를 설계 → 개발단계 별로 자연스럽게 연결되지 않고 유지보수 비용이 많이 발생
- 유지보수가 쉬우려면 모듈이 잘 설계되어 있어야 함 → 이걸 위해 객체지향 개발방법론이 탄생
- 객체지향 개발방법론 등장 : 인간이 사고하는 방식대로 프로그램을 개발하려는 노력으로 탄생
- 구조적 개발방법론과 객체지향 개발방법론은 접근 방법 자체가 다름
- 1990년대 들어서면서 여러 SW 기술 중에 객체지향방법론이 가장 중요한 기술로 인식됨
- SW 위기 현상이 객체 지향 기술로 인하여 해결될 수 있다는 공감대가 형성됨
- 소프트웨어 생산기술의 초점이 프로그래밍에서 분석, 설계로 옮겨지면서 더욱 주목을 받음 ★★★
- 잘 쓰려면 분석/설계가 잘 되어야 한다
- 그 관점에 한 몫을 한 것이 객체지향
- 객체지향은 분석/설계/구현이 하나의 흐름이므로 수월
- 개발생산성을 높이는 방법을 제공 (재사용 지향)
- 일관된 소프트웨어 개발 모델 제공
- 구조적 개발방법론
- 특징 : 함수, 처리, 프로세스가 중요
- 단점 : 분석/설계/구현 단계마다 용어/개념이 다름, 작은 변화에도 영향이 큼
- 객체지향 개발방법론
- 클래스인 객체 사이의 호출/응답이 중요, 클래스를 어떻게 잘 설계할지가 관건
- 함수와 자료를 함께 객체로 추상화함 → 변화에 영향을 덜 받음
- 장점 : 분석/설계/구현이 하나의 개념으로 연결됨, 추상화/정보은닉 등 설계 원리에 충실(class가 이것을 잘 반영), 복잡함을 잘 다룰 수 있음(class를 묶어 package도 만드는 중)
- 특징 : 뚜렷하게 구별되는 단위인 객체(object)로 분할, 코드 재사용에 의해 생산성을 높임, 빠른 속도로 적용하여 산업계 표준화가 됨
- 객체지향 개발의 특징
- 반복적인 프로세스
- 솔기 없는 프로세스
- 상향식 접근 방식
- 재사용을 고려
- 반복적인 프로세스
- 분석&설계가 구분 없이 계속 반복됨 (만들어 둔 것을 계속 refine)
- 소프트웨어 생명주기를 반복하여 적용하도록 제안
- 솔기 없는 프로세스
- seamless 프로세스
- 프로세스를 구성하는 각 단계 간의 경계선이 불분명
- 상향식 접근 방식
- 구조적 방법론 : 하향식 (Top Down) 프로세스를 사용
- 객체지향 방법론 : 상향식 프로세스를 사용
- 가장 작은 단위를 찾아내어 넓혀감 (컴포넌트→시스템)
- 재사용을 고려
- 구조적 방법론 : 성공적인 SW 산출물을 만들고자 하는 개발 공정에 치중
- 객체지향 방법론 : 재사용이 고려되어 프로세스가 진행
- 객체지향 방법론은 크게 3가지가 있다.
- 기능 모델링
- 구조 모델링
- 행위 모델링
- 소프트웨어 분석을 위한 객체지향 방법론의 첫번째 활동
- 사용자로부터 도출한 요구사항으로부터 소프트웨어 시스템이 해야 할 기능이 무엇인지를 식별해가는 과정
- 유스케이스 다이어그램
- 시스템과 관련된 외부 요소들을 표현
- 얘로 기능 모델링 표현
- 배경도와 비슷한 의미
- 가장 많이 쓰이는 것
- 나와 소통하는 다른 것들 표현
- 유스케이스 작성
- 시스템이 사용자에게 눈에 보이는 결과를 생성하기 위해 수행하는 작업을 순서대로 정리 해 놓은 것
- 유스케이스 다이어그램 작성 후 해야 할 일
- 각 유스케이스마다 작성해야 함
- 유스케이스 작성의 목적
- 외부 액터에 의해 인식되는 시스템의 기능과 요구사항을 보여주기 위함
- 시스템의 범위를 정하는데 도움이 됨
- 개발 과정을 계획하는데 사용
- 요구를 개발하고 검증하는데 사용
- 테스트케이스를 정의하는데 기초가 됨 → 사용자가 원하는 것이 잘 만들어졌는지 확인하기 위해
- 사용자 매뉴얼 구성하는데 사용될 수 있음
- 시스템 최상위 수준에 해당하는 기능을 사용자 관점으로 나타내는 것
- 사용자가 시스템을 통해 제공받는 주요 기능과 시스템과 사용자 간의 상호작용을 표현
- 유스케이스 (UseCase, 사용사례, 쓰임새)
- 외부에서 본 시스템의 뷰
- 사용자의 관점에서 시스템이 제공하는 서비스를 나타낸 것
- 시스템과 외부 사용자(액터, actor) 사이의 목표지향적인 인터랙션의 집합
- 유스케이스 다이어그램 구성요소
- 작성 절차
- 요구사항 정의 내용을 검토한다.
- 요구사항을 토대로 시스템의 경계를 결정한다.
- 경계가 설정된 시스템에 대한 명칭(시스템 명)을 정의한다.
- 시스템 외부에 존재하는 액터를 식별하고, 각 액터의 역할을 정의한다.
- 각 액터가 시스템에서 사용하는 기능을 식별한다.
- 식별된 기능(유스케이스)과 액터 간의 관계를 정의한다.
- 유스케이스 명세서(Use Case Description)를 작성한다. = Use Case를 작성한다.
- TIP
- 간단한 것이 좋다.
- 기능은 다 표현되어야 한다.
- 복잡할 필요가 없다.
- 관계를 잘 설정해야 코드를 잘 작성할 수 있다.
- 시스템으로부터 서비스를 받는 외부 요소
- 사람(역할), 시스템, 조직을 표현한다.
- 외부에 존재하는 상호작용 대상이다.
- 역할을 중심으로 식별한다.
- Ex. James라는 사람이 시스템 사용자이면서 시스템 관리자 역할을 할 때, 액터는 사용자와 관리자의 두 가지로 식별해야 한다.
- 표현 모습
[5.1.2] 유스케이스 다이어그램 - 유스케이스
- 액터에게 서비스를 제공하기 위해 시스템이 수행하는 중요 프로세스
- 유스케이스 이름은 작업을 의미하는 동사구 형태
- 유스케이스는 액터에 의해 시작되어야 한다.
- 단일 유스케이스가 여러 액터에 의하여 구동 될 때 분리할지 말지 고민해야 하는데, 다른 액터가 구동될 때 작업이 동일하면 같은 유스케이스이고, 이벤트 흐름이 다르면 다른 유스케이스이다.
- 하나의 유스케이스는 동작 수행에 대한 종료를 포함하도록 정의해야 한다.
- 유스케이스가 시작되기 위한 사전 조건이 필요하고, 끝났을 때 결과로 나올 사후 조건 존재한다.
- 유스케이스 사이에는 흐름이 없다
- 유스케이스 1개는 외부 액터와 어떻게 interaction 할지만 구성하면 된다.
- 유스케이스는 level이 아닌 1개의 Diagram이다.
- 유스케이스는 사이즈를 다들 비슷하게 설정해야 한다.
- 연관관계 (association)
- 커뮤니케이션 관계로 유스케이스와 액터 사이의 관계
- = interaction을 나타내는 것
- 의존관계 (dependency) : 유스케이스들 사이의 관계, 업무의 흐름과 상관 없다, 의존성 여부를 나타내는 것
- 포함 (include) 관계
- 공통의 유스케이스를 별도로 정의
- base 유스케이스를 실행하기 위해 반드시 included 유스케이스가 실행되어야 한다.
- 예시 : 주문 변경을 하려면 주문을 찾는 것을 먼저 해야 한다.
- 공통되는 유스케이스를 뽑아 따로 만든다.
- 화살표 방향이 included 쪽으로 향하도록 표현한다.
- 의존 관계 (dependency)
- 확장관계
- 유스케이스의 동작을 조건적으로 확장
- 이벤트의 추가나 예외적인 케이스
- 화살표가 base 쪽으로 향하도록 표현한다.
- 일반화 관계 (generalization)
- 유스케이스와 유스케이스, 또는 액터와 액터 사이의 관계
- 상속을 나타낸다.
- 모든 usecase에 대해 usecase 명세서를 작성해야 한다
- 유스케이스에 대한 간단한 식별 정보와 유스케이스 내부에서 처리해야 하는 기능의 상세한 흐름을 나타낸다.
- 기본 흐름
- 유스케이스의 여러 시나리오 중에서 가장 일반적이고 정상적인 상황을 나타내는 하나의 이벤트 흐름
- 대안 흐름(Alternative Flow)
- 한 유스케이스에서 기본 흐름이 표현하는 상황을 제외한 모든 다른 상황
- 수행이 끝나면 기본 흐름으로 돌아오는 경우도 있고 대안 흐름에서 종료되는 경우도 있다.
- 선택 흐름과 예외흐름이 있다.
![[CS][소프트웨어공학] 객체지향방법론, UML, 유스케이스 다이어그램](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbfHOMF%2FbtsDIyEFYih%2FKcuyt60rbDyIonWmjf4mYk%2Fimg.png)