[소프트웨어 설계] Unified Modeling Language (UML) - (1) usecase diagram (2) activity diagram (3) sequence diagram

Unified Modeling Language (UML)

• 소프트웨어 프로그램을 시각화하기 위해 다이어그램으로 구성된 표준화된 모델링 언어
• UML diagrams describe the boundary, struture, and the behavior of the system and the objects within it
• 객체지향기반으로 객체지향설계, 객체지향 모델링, 객체지향소프트웨어엔지니어링에 활용됨
• 특징
  • A read-to-use, expressive visual modeling lanuage : 사용자가 모델을 개발, 교환할 수 있는 즉시 사용가능한 시각적 모델링 언어 제공
  • Extensibility : 코어 컨셉을 확장할 수 있는 전문 매커니즘 제공
  • PL-agnostic : 프로그래밍 언어 및 개발에 종속되지 않음
  • A basis for the modeling language : 모델링 언어를 이해하기 위한 기반
  • Support object- oriented tool market : 객체지향툴 성장에 기여
  • Support higher-level development concepts : 협력, 프레임워크, 패턴, 구성요소에 기여
• 장점
  • 소프트웨어 구조를 전달 및 이해하는데 완벽한 시각적 언어 : 성능, 보안 등 평가하는데 도움이 됨
  • 총 14 종류의 다이어그램으로 표현이 되는데 다 ㅇ라 필요는 없음
  • 상용화된 많은 툴들이 있음
• 단점
  • 꼭 표준화된 시각적 언어가 필요한가? : 파워포인트, 비지오, 화이트보드로 그려진 비공식적 시각화도 충분하진 않은가?
  • Ascending Degree of Complexity : 소프트웨어가 커지고 복잡해짐에 따라 extra complexity를 가져옴
  • Architecture-indifferent design : 단순하고 기본적이며 복잡하지 않은 소프트웨어 구조
• 종류
  • Structural Diagram → 시스템의 정적 구조
  • Behavior Diagram → 시스템의 동적 동작

Use Case Diagram

• 목적
  • system context 구체화
  • 시스템 요구사항 캡처
  • 시스템 구조 검증
  • 구현 및 테스트케이스 생성

Unified Modeling Language (UML)

• 소프트웨어 프로그램을 시각화하기 위해 다이어그램으로 구성된 표준화된 모델링 언어
• UML diagrams describe the boundary, struture, and the behavior of the system and the objects within it
• 객체지향기반으로 객체지향설계, 객체지향 모델링, 객체지향소프트웨어엔지니어링에 활용됨
• 특징
  • A read-to-use, expressive visual modeling lanuage : 사용자가 모델을 개발, 교환할 수 있는 즉시 사용가능한 시각적 모델링 언어 제공
  • Extensibility : 코어 컨셉을 확장할 수 있는 전문 매커니즘 제공
  • PL-agnostic : 프로그래밍 언어 및 개발에 종속되지 않음
  • A basis for the modeling language : 모델링 언어를 이해하기 위한 기반
  • Support object- oriented tool market : 객체지향툴 성장에 기여
  • Support higher-level development concepts : 협력, 프레임워크, 패턴, 구성요소에 기여
• 장점
  • 소프트웨어 구조를 전달 및 이해하는데 완벽한 시각적 언어 : 성능, 보안 등 평가하는데 도움이 됨
  • 총 14 종류의 다이어그램으로 표현이 되는데 다 ㅇ라 필요는 없음
  • 상용화된 많은 툴들이 있음
• 단점
  • 꼭 표준화된 시각적 언어가 필요한가? : 파워포인트, 비지오, 화이트보드로 그려진 비공식적 시각화도 충분하진 않은가?
  • Ascending Degree of Complexity : 소프트웨어가 커지고 복잡해짐에 따라 extra complexity를 가져옴
  • Architecture-indifferent design : 단순하고 기본적이며 복잡하지 않은 소프트웨어 구조
• 종류
  • Structural Diagram → 시스템의 정적 구조
  • Behavior Diagram → 시스템의 동적 동작

Use Case Diagram

• 목적
  • system context 구체화
  • 시스템 요구사항 캡처
  • 시스템 구조 검증
  • 구현 및 테스트케이스 생성

1. Actor
   1. actor triggers use case
   2. has a responsibility toward the system (inputs), has expectations from the system (outputs)
   3. how to identify it
      1. 누가 이 시스템을 사용, 시작, 설치, 종료, 유지하는지?
      2. 이 시스템을 사용하는 다른 시스템이 있는지?
      3. 누가 이 시스템에서 정보를 받고 혹은 정보를 주는지?
      4. 이 시스템이 자동으로 콜 되는지?
2. Use Case
   1. system function
   2. each actor must be linked to a use case, while some use cases may not be linked to actors
   3. how to identify use cases
      1. 액터가 시스템에서 원하는 기능이 무엇인지?
      2. 액터가 시스템에 저장하는 정보를 생성, 읽기, 업데이트, 삭제하는지?
      3. 시스템 내부 상태 변경에 대해 액터에게 알려야 하는지?
      4. 시스템이 통보 받아야 할 외부 이벤트가 있는지? 있다면 어떤 액터로부터 전달받아야 하는지?
3. Use Case Relationship - ‘extends’ ; 특정조건에서만 동작; 유즈케이스가 특정 유즈케이스에 정의된 행위로 선택적으로 추가 확장될 수 있음
   1. Indicates that an “Invalid Password” use case may include (subject to specified in the extension) the behavior specified by base use case “ Login Account”
   2. depict with a directed arrow having a dotted line
   3. the stereotype “<<extends>>” identifies as an extend relationship
4. Use Case Relationship - ‘include’ ; 기능을 위한 기능; 기본 유즈케이스가 실행되기 위해서는 반드시 다른 특정 유즈케이스의 행위를 포함해야 한다는 것을 의미
   1. a uses relationship from base use case to child use case indicates that an instance of the base use case will include the behavior as specified in the child use case.
   2. an include relationship is depicted with a directed arrow having a dotted line.
   3. the stereotype “<<include>>” identifies the relationship as an include relationship
5. Use Case Relationship - ‘generalization’ ; 개념의 확대(일반화)
   1. a generalization relationship is a parent-child relationship be tween use cases
   2. the child use case is an enhancement of the parent use case
   3. generalization is shown as a directed arrow with a triangle arrowhead
6. Communication Link
   1. the participation of an actor in a use case is shown by connecting an actor to a use case by a solid link
   2. association : The actor and the use case communicate with one another using messages.
7. Boundary of system
   1. the entire system as defined in the requirements document
   2. for large and complex systems, each module may be the system boundary.
   3. form a system boundary for use cases specific to each of these business functions

---

Use Case Diagram VS. Activity Diagram

use case diagram : 컴퓨터 시스템과 사용자의 상호작용을 표현한 것으로 사용자 입장에서 이해할 수 있게 기술해야 함

activity diagram : 유즈케이스 다이터그램 작성 후 하나의 유즈케이스 내에서의 흐름을 표현하는 액티비티 다이어그램을 작성할 수 있음. 일련의 activity들을 가지고 프로세스를 표현, 프로그램의 작업 흐름에 초점, 병렬행동 지원

What is Activity Diagram?

• 시스템의 동적 측면을 보여주는 다이어그램
• 한 활동에서 다른 활동으로의 흐름을 모델링 할 수 있음
• 순서도와 크게 다르지 않음
• 시스템 내부의 행위들, 행위들의 분기점, 분기되는 조건 등을 표현

When to use Activity Diagram?

• 비지니스 워크플로우를 조사하여 Use case 후보들을 찾는데 유용
• Use case 에 대한 사전, 사후 조건을 식별하는 데 유용
• Use case 안에서 혹은 서로 다른 Use case 끼리의 워크플로우를 정의하는 데 도움
• 복잡한 워크플로우 모델링에 도움
• 복잡한 activity(행위)들을 자세히 도식화하는데 도움

How to draw?

1. Activity의 Scope을 정함
2. Activity식별 후 flow로 이어본다 (화살표)
3. 필요한 Decision들을 정의 (분기점)
4. 평행적으로 수행될 수 있는 Activity들을 찾는다
5. Activity diagram을 작성

Notiations

특징1 : 분기와 병렬(fork)

• 분기 : 선택의 기로, 둘 중 하나를 선택해야 할 경우
• 병렬 : 동시에 두가지 업무가 진행

특징2: 파티션/Swimlame

• 각 활동을 진행하는 담당자가 다를 경우

특징3: 흐름 (Flow)

 

Activity diagram 작성 시 유용한 팁

→ PseudoCode(의사코드)의 활용

• 프로그래밍언어와 비슷한 구문으로 이루어져있지만 실제 실행할 수는 없음
• 알고리즘 작성 전 생각을 정리하고 스케치하는 데 유용

---

[비밀번호 재설정 프로그램]

💡 사용자는 비밀번호를 재설정 하려고 한다.

#1. 비밀번호 재설정 프로그램이 시작되면 사용자는 아이디를 입력한다.

#2. 아이디가 존재하지 않는 경우 프로그램은 종료되고 존재하는 경우 기존 패스워드를 입력받는다.

#3. 기존 패스워드가 맞는 경우 비밀번호 재설정을 하고 프로그램은 종료된다.

#4. 기존 패스워드가 틀릴경우 5번까지 시도할수 있으며 맞으면 비밀번호를 재설정하고 틀릴경우는 프로그램이 종료된다.

 

pseudoCode

##반복문
for i in range(5):
	type password

##조건문
if (ID exists):
	type password
else :
	terminate

if (correct password):
	reset password
else:
	type password

if(try 5 times):
	terminate
else:
	type password

Activity Diagram with [Visual Paradigm]

 

Sequence diagram

• 작업이 수행되는 방법을 자세히 보여주는 상호작용 다이어그램
• “협업”의 맥락에서 객체 간 상호작용을 보여줌
• 다이어그램의 세로축을 활용하여 메시지가 전송되는 시간과 메시지 내용을 표시하여 상호작용의 순서를 시각적으로 보여줌
• 목적
  • Use Case 혹은 작업을 실현하기 위한 협업에서 발생하는 상호작용
  • 시스템-사용자, 시스템-시스템, 하위시스템-하위시스템 까리의 상호작용

Activity diagram vs. sequence diagram

activity diagram(Functional modeling) sequence diagram (Dynamic modelling)

메시지의 제어흐름(control flow)를 나타냄	→ 동일(공토점
시스템 작업의 흐름을 모델링	특정 기능을 수행하는데 사용되는 시스템 안에서의 호출 시퀀스를 시각화
한 활동(activity)에서 다른 활동으로의 메시지 흐름을 보여줌	한 객체에서 다른 객체로의 메시지 흐름을 보여줌
프로세스의 실행을 나타냄	프로세스의 시간순서를 나타내
단일 혹은 여러 사용 사례(use case)혹은 여러 객체들에 대한 작업 (action)들의 일반적인 순서를 설명	단일 사용사례 (use case)에서 여러 객체의 동작을 설명

💡 sequence diagram은 결국 객체들 간의 상호작용을 보여주는 것에 초점을 둔 것