OOAD-08
use cases
FR - usec ase
NFR - Quality(FURPS) + standard Quality Model
QA(품질속성)
Use-case Model : writing requirements in context
유스케이스
특히 "기능적인 요구사항"을 발견하고 기록함
OOAD를 포함한 프로젝트의 여러 측변에 영향을 미침
유스케이스 작성하기
시스템을 사용하는 것의 이야기
요구사항을 이해하고 묘사하는 훌륭한 기술이다.
유스케이스 모델
모든 유스케이스의 집합
시스템의 기능적인 부분과 환경을 알 수 있는 모델이다.
Use Case
목표를 달성하기 위해 시스템을 사용하는 일부 actor의 텍스트 이야기
액터(사용주체)가 대상 시스템을 어떻게 이용할 지에 대한 스토리 텔링을 하는 것
Use Cases and the Use-Case Model
UP는 Requirement discipline 내에서 유스케이스 모델을 정의한다!!
유스케이스는 텍스트 문서다. 다이어그램이 아니다.
유스케이스 모델링은 주로 다이어그램 텍스트를 쓰는 것이다. 다이어그램을 그리는 것이 아니다.
-> 항상 다이어그램은 아니나 보통 다이어그램 사용. 꼭 텍스트를 써야 함!
Use Cases
유스케이스는 주로 기능적인 요구사항이나 행동 요구사항이다.
- 시스템이 수행할 작업을 나타내고
- 발견하고 정의한다
유스케이스는 시스템이 작동하는 방식에 대한 contract(계약)을 정의한다.
유스케이스 - 시스템의 사용 사례
- 요구사항을 이해하고 설명하는 훌륭한 기술
Actor
액터는 사람(역할로 식별됨), 컴퓨터 시스템, 조직(예를 들어 계산원)과 같이 행동이 있는 대상이다.
액터는 행동이 있는 모든 것이다.
- 역할로 식별되는 사람
- 컴퓨터 시스템
- 조직
- 소프트웨어
Scenario with Actor
시나리오
- 액터와 시스템 간의 행동과 상호작용의 특정 시퀀스
- 예) 현금으로 물건을 성공적으로 구매한 시나리오, 신용 결제 거부로 아이템을 구매하지 못한 시나리오
시나리오는 행동의 특정 시퀀스이고 액터와 시스템 간의 상호작용이다. 유스케이스 인스턴스라고도 함
유스케이스는 목표를 지원하기 위해 시스템을 사용하는 액터를 설명하는 관련 성공, 실패 시나리오의 모음이다.
유스케이스 모델
- UP의 Requirement 산출물(artifact)
- 추가 사항
- 용어 사전
- 비전
- 비즈니스 규칙
- 모든 요구사항 분석에 유용하다
Kinds of Actors
Primary actor
- 토론 중인 시스템(SuD)의 서비스를 사용해서 사용자 목표를 달성함
Supporting actor
- SuD에 서비스를 제공
- 오른쪽에 그림
Offstage actor
- 유스케이스의 행동에 관심이 있음
Template
이 일을 하기 전에 미리 세팅되어야 하는 점들
유스케이스 사용한 예시 나옴. 피피티 참고
Use Case : a two-column variation
액터와 시스템이 하는 것을 나눠서 작성
Applying UML: 유스케이스 다이어그램
UML은 유스케이스와 액터, 액터들의 관계를 이름으로 설명하기 위해 유스케이스 다이어그램 표기법을 제공한다.
OOAD-09
UML Use Case
UML : Unified Modeling Language
이용 영역
- 요구사항 분석 단계에서 유스케이스 다이어그램이 주로 사용됨
- domain concept model이나 소프트웨어 설계를 기술함
- 클래스 다이어그램이 널리 사용됨
UML의 역사
걍 피피티 봐. 별로 안 중요
UML Diagrams
-
Activity : 절차적이고 병렬적인 행위를 기술
-
Ingeraction overview : Sequence와 Activity diagram의 결합
-
Use case : 사용자가 상호작용하는 시스템의 모습을 기술
-
Communication : 객체들간의 상호작용을 연결에 초점을 맞춰 기술
-
Sequence : 객체들간의 상호작용을 순서에 초점을 맞춰 기술
-
Class : 클래스와 클래스 간의 관계를 기술
-
Deployment : 시스템의 물리적인 배치를 기술
-
Package : 시스템의 컴파일시의 계층적 구조를 기술
UML 구성요소
다이어그램
정적뷰
- 클래스 다이어그램
- 객체 다이어그램
- 컴포넌트 다이어그램
- 배치 다이어그램
동적뷰
- 유스케이스 다이어그램
- 시퀀스 다이어그램
- 콜래보레이션 다이어그램
- 스테이트차트 다이어그램
- 액티비티 다이어그램
객체지향 모델 및 자원들간 관계
Use Case Diagram
Use Case
UML은 Use Case Diagram 표기법 정의
Use Case 용도
- 시스템의 더 놓은 레벨의 뷰를 제공함
- 유스케이스는 시스템의 외부 뷰 표현
다이어그램보다는 텍스트 서술에 집중
Use Case와 요구사항 관리
- 시스템의 기능적 요구사항 획득
- 사용자와 시스템간의 상호작용 서술
- 시스템이 어떻게 사용되는 가를 이야기체로 서술
유스케이스
- 핵심은 시스템을 사용하는 사용자의 입장
- 공통적인 사용자 목표에 의해 묶인 시나리오들의 집합
- 내용이 잘 전달되어야 함
유스케이스 레벨
- 시스템 유스케이스 : 소프트웨어 시스템과의 상호작용 표현
- 비즈니스 유스케이스 : 비즈니스와 고객 또는 이벤트와의 상호작용 표현
이벤트들의 흐름
- 사용자와 시스템 간의 상호작용을 서술하는 일련의 스텝들
- 발생 가능한 시퀀스
- 유스케이스를 시작시킨 행위자는 왼쪽, 결과를 받는 행위자는 오른쪽에 표현
Actor
액터
- 사용자가 시스템에 대해서 수행하는 역할
- 액터는 사람일수도 있고 시스템일 수도 있음
- 여러 사람이 하나의 액터로, 하나의 사람이 여러 액터로 맵핑 가능
- 유스케이스를 시작시키고, 유스케이스가 끝나면 결과를 받음
액터의 종류
- 주 액터
- 주 목적을 가지고 있는 액터
- 주도적으로 접근함
- 이차 액터
- 유스케이스를 실행시키기 위해 시스템이 필요로 하는 지원하는 액터
일어나는 이벤트의 표현
- 시스템과 액터 간의 상호작용 요소
유스케이스 다이어그램
이해관계자들을 위한 좋은 소통 도구
유스케이스들의 목차의 그래픽적인 테이블 표현
액터, 유스케이스, 액터와 유스케이스 간의 관계로 구성
시스템
- 유스케이스를 둘러싸는 사각형으로 표현
- 행위자는 대개 시스템 외부에 있는 반면, 유스케이스는 시스템의 내부에 있다.
extend
include
OOAD-11
: UML - Class Diagram
Class Diagram
설계 시 가장 많이 사용되며 그 모델링 개념의 폭이 넓음
- 객체 타입인 클래스를 표현하는 다이어그램
- 클래스의 속성(attribute), 오퍼레이션(operation), 연관관계(association), generalization(일반화), package 등이 다른 클래스와 사이의 다양한 정적인 관계를 표현
클래스 다이어그램은 클래스, 인터페이스, 관계를 보여준다.
- +(public), #(protected), -(private)
- 변수 기술 방법
예. mycar:Car - 함수 기술 방법
예. getNameByID(id:int):Sting - 클래스 명이 기울어져 있으면 추상 클래스라는 의미
바운더리 클래스
시스템 및 주변 환경과 상호작용을 한다.
초기에는 액터/유스케이스 한 쌍 당 하나의 바운더리 클래스를 설정해도 좋다.
- 이후 여러 개의 바운더리 클래스 또는 컨트롤 클래스로 분할될 수 있다.
바운더리 클래스는 사용자, 외부 시스템, 장비 등과 상호 작용하는 클래스이다.
엔터티 클래스
시스템에서 정보를 저장하고 관리한다.
시스템 관점에서의 주요 추상개념이다.
- 유스케이스 기술서의 사건 흐름으로부터 파악한다
- 주요 추상개념을 참조한다
- 관련 자료들로부터 명사를 선별하고, 이로부터 엔터티 클래스를 찾아낸다.
! 운영 모델과 비즈니스 개념 모델 모두를 알아야한다.
컨트롤 클래스
유스케이스 행위를 중재한다.
유스케이스 행위를 조정하는 클래스
하나의 유스케이스에 하나의 컨트롤 클래스
! 가장 어려운 부분으로, 특히 규모에 따라 전략이 매우 다양화될 수 있다.
상위 클래스(패키지) 다이어그램
- 관련 클래스들의 적절한 분류 (Classification)
- 업무 분류는 클래스 다이어그램에 패키지를 통해서 표현
설체 단계에서 클래스 다이어그램
가시성
- Private : 클래스 안에서
- Package : 같은 패키지 안에서
- Protected : 상속관계 안에서
- Public : 모든 시스템
접근제어자 (Access Modifier)
protected
접근제어자가 protected로 설정되었다면, protected가 붙은 변수, 메소드는 동일 패키지 내의 클래스 또는 해당 클래스를 상속받은 외부 패키지의 클래스에서 접근이 가능하다.
속성 (attribute)
클래스의 속성은 객체의 상태를 나타내는 정보이다.
속성(attribute) 또는 연관관계(association)로 표현
[visibility] / name [: type][multiplicity] [=default][{property-string}]
예) +/name : String[1] = "Untitled" {readonly}
연관관계 (association)
- 연관관계는 소스 클래스와 타겟 클래스를 연결
- 속성(property)의 이름은 역할이름으로 표현
- 연관관계의 양끝에 개수를 표현 (참여하는 속성의 개수 표현)
class-level attribute
static attribute
- 속성이 한 클래스의 여러 객체에 의해 공유된다.
표기법: 밑줄을 친다.
오퍼레이션 / 메소드
수행할 행위
오퍼레이션 문법
- [visibility] name ([parameter-list]) ':' [return-result][{properties}]
-visibility marker는 public(+) 또는 private(-) - name은 문자열
- parameter-list(매개변수 목록)은 연산을 위한 parameter list
- return-type은 만약 하나가 있으면 반환되는 값의 type
- property-string : 문자열 갖는 특성이 연산에 적용
정적 오퍼레이션
정적 오퍼레이션과 속성
- 인스턴스가 아니라 클래스에 적용되는 오퍼레이션 또는 속성
관계 (relationship)
의존, 연관, 집합, 복합, 상속
가장 약한 순부터 쓰면,
- dependency : 의존
- association : 연관
- aggregation : 집합
- composition : 복합
- inheritance : 상속
의존성 관계
두 클래스 간의 의존성은 클래스가 해당 클래스의 개체를 사용하기 위해 다른 클래스에 대해 알아야 함을 선언함
- 한 요소의 변화가 다른 요소에 영향을 미칠 경우 의존성이 존재한다.
- 시스템의 대형화로 의존성 제어가 더욱 중요하다
- 의존성을 통제하지 못할 경우, 특정 요소의 변화에 대한 파급효과는 커진다.
- UML에서 모든 요소들의 의존성을 표현할 수 있다.
두 개체를 연결하는 개체 참조를 포함함
연관 관계
상대 객체와의 관계를 표현함
집합 관계
part-of 관계
집합을 나타낸다는 표시로 연결 끝에 속이 빈
다이아몬드 표시
속이 빈 다이아몬드는 다른 클래스의 인스턴스를 포함하는 클래스의 연관 끝 점에 나타낸다.
구성 관계
얘는 전체-부분 관계이다.
ex) 키보드는 컴퓨터의 한 부분이다.
집합된 인스턴스는 한번에 하나의 구성에 속할 수 있다.
일부 오퍼레이션은 구성에서 그것이 집합 인스턴스로 전파되어야 한다.
구성은 물리적인 결합이 되어 있어 분리되어 생각되어 질 수 없다.
구성이 부품을 갖고 부품이 다른 부품을 갖는 것처럼 계층 구조를 가질 수 있다.
상속 관계
superclass와 subclass 간 논리적 추상화를 제공한다.
subclass는 일반화된 superclass의 모든 특성(속성, 오퍼레이션, 연관)을 상속받는다.
하위 클래스 -> 상위 클래스
유사한 종류의 선이 클래스가 인터페이스를 구현함을 나타내는 데 사용됨
인터페이스를 구현한 클래스 -> 인터페이스 클래스
추상 클래스
직접 인스턴스를 생성할 수 없는 클래스
- 구현이 없어 순수한 정의만을 가진 오퍼레이션
- 추상 클래스는 하나 이상의 추상 오퍼레이션 보유
추상 클래스와 추상 오퍼레이션은 이탤릭 체로 표현
+)
오버로딩 :
같은 클래스 내에서 동일한 이름의 메서드를 파라미터 시그니처(파라미터 개수, 순서, 타입)를 다르게 하면서 재정의하는 것
오버라이딩 :
수퍼 클래스에 있는 메서드를 같은 파라미터 시그니처로 서브 클래스에서 그 메서드를 재정의하는 것
인터페이스
어떤 구현도 가지지 않는 클래스
- 모든 특성이 추상
- 키워드 <>를 사용하여 표현
인터페이스의 장점
- 구현의 변경이 용이
- 구현이 아닌 인터페이스에 대해 프로그래밍
- 변경에 의해 영향 받는 부분을 최소화
인터페이스는 클래스 내에 구현 로직이 없으며, 선언만 가능함
추상 클래스는 클래스 내 추상 메소드가 하나 이상 포함됨
인터페이스는 모든 메소드가 추상 메소드
추상 클래스는 그 추상 클래스를 상속받아서 기능을 이용하고 확장시키는 데 있음
반면에 인터페이스는 함수의 껍데기만 있는데, 그 이유는 그 함수의 구현을 강제하기 위해서다. 구현을 강제해서 구현 객체의 같은 동작을 보장할 수 있다.
제약 조건
OCL을 사용한 3가지 제약조건
- invariants
항상 true인 상수, 클래스 속성에서 정의함 - 전제 조건
메소드가 수행되기 전에 만족하여야 하는 제약조건
메소드 입력값의 유효성을 검증하는데 사용 - 사후 조건
메소드가 수행된 후에 만족하여야 하는 제약조건
출력값이 메소드에 의해 어떻게 바뀌었는지를 검증하는데 사용
OOAD-12
: 액티비티 다이어그램, interaction 다이어그램
액티비티 다이어그램
시스템의 workflow를 모델링하는 도구
- 시스템의 목적을 달성하는 방법을 나타냄
- 시스템에서 발생하는 프로세스의 흐름을 보여줌
상위수준 액티비티 다이어그램
구분선이 있음
Activity
- 활동은 엣지로 연결된 노드의 그래프로 지정되는 일종의 행동이다.
- 활동은 다른 활동을 호출하는 활동의 계층 구조를 형성하거나 객체 지향 모델에서 절차적 계산을 설명할 수 있다.
- 비즈니스 프로세스 엔지니어링 및 작업 흐름을 위한 조직 모델링에 활동을 적용할 수 있음
Actions
- 액션은 UML에서 동작 사양의 기본 단위이다.
- 액션은 입력 세트로 사용하여 출력 세트를 생성할 수 있고, 이러한 세트들은 비어 있을 수 있음
- 일부 액션은 액션이 실행되는 시스템의 상태를 수정할 수 있음
Action & Activity
- 액션은 프로세스 완료의 활성 단계입니다.
- 액션은 모델링되는 프로세스입니다
Pins
- 핀은 액션에 대한 입력이나 출력을 나타냄
- 액션의 인풋을 줄 수 있고 아웃풋을 받을 수 있음
Call Behavior Actions
액션 기호 안에 배치된 호출된 동작의 이름을 가진 액션으로 표기됩니다.
Decision & Merge
결정은 조건에 따라 다른 일련의 액션을 실행하려는 경우에 사용된다.
분기된 흐름은 결정 노드에서 시작된 조건 동작의 끝에 표시하는 머지 노드에서 함께 결합됨
=> 조건에 따라 분리가 되는 경우에 디시션을 쓰고, 여러개로 분리된 업무들(흐름들)을 하나로 다시 묶는 것이 머지
Fork & Join
조인 : 흐름이 조인을 지나기 전에 들어오는 모든 작업이 완료되어야 함을 의미함
포크 : 나가는 흐름이 여러개 있는 반면, 조인에는 들어오는 흐름이 여러 개 있음
Time Events
모래시계로 그림
들어오는 흐름이 없는 time event는 반복적인 time event이다.
- 모래시계 옆 텍스트의 빈도로 활성화됨
Calling other Activities
Objects in activity diagram
개체 노드는 액티비티에서 특정 포인트에서 사용할 수 있는 개체를 나타냄
- 개체가 주변 액션에 의해 사용, 생성 또는 수정되었음을 표시하는 데 사용됨
인풋 핀은 지정된 객체가 액션에 입력된다는 것
아웃풋 핀은 지정된 객체가 액션에서 출력된다는 것
- showing objects passed between actions
- showing how objects change state during an activity
- showing action inputs and outputs
입력 및 출력 핀을 사용하여 데이터 흐름 설명
- 출력 핀 및 입력핀을 사용하여 한 작업에서 나가는 출력 및 다른 작업으로 들어오는 입력을 개별적으로 설명
- 동작 호출 작업으로 하위 동작 설명
Partitions (or Swimlanes)
어떤 참가자가 어떤 액션을 해야하는지 보여줌 (수영장 레인 같은 느낌)
Activity Diagrams 분할
Connectors
- 커넥터는 다이어그램을 풀어주는 데 도움이 됨
- 명확한 선 대신 기호로 엣지를 연결함
- 내부에 이름이 쓰여진 원으로 그려짐
Expansion Regions
- 확장 영역은 영역의 액션이 입력 컬렉션의 각 항목에 대해 수행됨을 보여줌
Interaction Diagram
액티비티 다이어그램은 하는 업무를 분담했음
시퀀스 다이어그램
-> 동적인 업무를 표현하는 다이어그램. 객체가 어떤일을 하는지 표현. 액티비티는 흐름이었음!
- 시퀀스 다이어그램은 동적 표현하는 다이어그램이다.
- 시스템 실행 시 생성되고 소멸되는 객체를 표기함
- 객체들 간에 주고받는 메시지를 보여줌
- 한 사건이 발생하였을 때 여러 객체 간 관계를 시간 순서에 따라 정의
- 시간을 중심으로 표현
- 다이어그램은 유스케이스 내의 객체와 객체에 내포되어 있는 메시지를 표현함
시퀀스 다이어그램은 시간의 흐름을 위에서 아래로 흐르게 표시.
각자 [객체:클래스]가 위에 있고 생명선이 있으며 실행과 메시지를 표시
유스케이스 기술서의 흐름대로 시간에 따른 시나리오를 표현
파라미터들이 VO (Value Object) 형태로 추상화되어 있음
Events, Signals, and Messages
이벤트는 신호(시그널)과 메시지의 빌딩 블록임
- 신호와 메시지는 같은 개념에 대해 정말 다른 이름임
- 신호는 시스템 설계자가 자주 사용하는 용어
- 메시지는 소프트웨어 설계자가 선호함
메시지 서명
- 속성 = 신호 or 메시지 이름 (arguments) : return_type
왼쪽 object에서 오른쪽을 인보크 함?
Nested Messages : 중첩된 메시지
한 참가자의 메시지로 인해 수신 참가자가 하나 이상의 메시지를 보내는 경우, 이러한 결과 메시지는 트리거링 메시지 내에 중첩되었다고 한다.
Message Arrows
Ovelapping Execution Specifications
동일한 라이프라인의 겹치는 execution Specifications는 겹치는 사각형으로 표시됩니다.
-> 하나의 execution 안에 또 다른 실행 있음
-> 왔던 거 기억했다가 끝나면 다시 부르고 싶을 때. ex) callback()
--
오브젝 별로 시간의 흐름에 따라 다른 옵젝과 하는 일 구분해서 볼 수 있음
아까 액티비티는 목적별로 그냥 흐름?
Loop Example
UseCase와 Sequence Diagram
유스케이스의 단계대로 시퀀스 다이어그램 object이 이루어짐
Communication Diagram
콜라보레이션 == 커뮤니케이션
- 객체와 객체들의 관계로 구성된 커뮤니케이션을 보여주며, 상호 간에 전달되는 메시지도 보여줌
- 객체, 객체를 연결하는 링크 및 각 링크 사이에서 발생하는 상호 작용을 보여줌
시퀀스 다이어그램과 커뮤니케이션 다이어그램 비교
참여자를 효과적으로 보여줌
- 시퀀스 : 참여자가 페이지의 가장 위에 있는 경우가 많다. 참여자 보기 쉽다.
- 커뮤니케이션 : 참여자에 초점을 맞춰 연결되어 있어서 보기 쉽다.
=> 커뮤니케이션 다이어그램이 더 잘 보여줌~
참가자들간의 링크. 연결점 유무
- 시퀀스 : 연결점 있다.
- 커뮤니케이션 : 연결점 있다.
=> 커뮤니케이션 다이어그램이 더 명확하게 보여줌~
메시지 신호를 보여줌
=> 둘 다 보여줌
병행적인 메시지 처리
- 시퀀스 : 순차적으로 볼 수 있다.
- 커뮤니케이션 : 숫자 표시로 메시지 순서를 알 수 있다.
=> 둘 다 잘 보여줌~ 근데 시퀀스가 조금 더 잘 보여주나벼(교수님 피셜)
비동기적 메시지 처리
- 시퀀스 : 비동기적 화살표 사용함
- 커뮤니케이션 : 메시지 순서 지정에 초점이 없기 때문에 비동기 메시지에 대한 개념이 없음..!
=> 시퀀스가 비동기적을 가시적으로 더 잘 보여줌~
메시지의 순서를 보는 정도
- 시퀀스 : 수직적인 순서에 따라서 순차적으로 볼 수 있음
- 커뮤니케이션 : 숫자에 따라 볼 수 있음
=> 시퀀스 다이어그램이 더 명확하게 보여줌~
다이어그램 생성과 관리가 더 쉬운 것
- 시퀀스 : 간단함. 그치만 UML 툴 없으면 힘들어짐
- 커뮤니케이션 : 간단함. 중간에 순서 바꿔야 하면 툴 없이는 힘듦
=> 개인 선호도라 우위를 판별하기 어려움. 근데 유지관리 용이는 커뮤니케이션이 더 위~
