환경

• MySQL

배경

• 데이터베이스를 사용하다가 실수를 하지 않으려면 어떤 방법이 있을까 하면서 생각하다가 정리

START TRANSACTION, COMMIT, and ROLLBACK 구문들

START TRANSACTION

• 새로운 트랜잭션을 시작
• 이어지는 쿼리들을 다 기억한다.

COMMIT

• 현재 트랜잭션을 커밋하여 해당 변경 사항을 영구적으로 반영한다.
• Implicit Commit을 발생시키는 경우는 링크를 참고

ROLLBACK

• 현재 트랜잭션을 롤백하여 해당 변경 사항들을 취소한다.
• Rollback을 할 수 없는 구문의 경우 링크를 참고

사용 예시

• example_table에서 실수로 id가 2인 행의 값을 잘못 변경해서 다시 id가 3인 행의 값을 변경하는 예시
• 이 외에도 데이터베이스에 많은 변경이 필요할 때 TRANSACTION을 사용하여 유용하게 처리할 수 있다.

START TRANSACTION;
UPDATE example_table SET status = 'family' WHERE id = 2;
ROLLBACK;
START TRANSACTION;
UPDATE example_table SET status = 'family' WHERE id = 3;
COMMIT;

참고자료

• https://dev.mysql.com/doc/refman/8.0/en/commit.html
• https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html
• https://dev.mysql.com/doc/refman/8.0/en/cannot-roll-back.html

Environment and Prerequisite

• MySQL

Background

• Thinking about ways to avoid making mistakes while using a database, I came up with the following ideas

START TRANSACTION, COMMIT, and ROLLBACK Statements

START TRANSACTION

• Start a new transaction.
• Remember the queries until COMMIT or ROLLBACK.

COMMIT

• Commits the current transaction, making its changes permanent.
• The cases that trigger implicit commits can be found in the link.

ROLLBACK

• Rolls back the current transaction, canceling its changes.
• Statements that cannot be rolled back can be referred to in the link.

Usage

• An example of mistakenly modifying the values of the row with id 2 in the example_table and then correcting it by updating the values of the row with id 3.
• In addition, TRANSACTION can be used effectively when many changes are needed in the database.

START TRANSACTION;
UPDATE example_table SET status = 'family' WHERE id = 2;
ROLLBACK;
START TRANSACTION;
UPDATE example_table SET status = 'family' WHERE id = 3;
COMMIT;

Reference

• https://dev.mysql.com/doc/refman/8.0/en/commit.html
• https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html
• https://dev.mysql.com/doc/refman/8.0/en/cannot-roll-back.html

시퀀스 다이어그램(Sequence Diagram)

환경

• UML

시퀀스 다이어그램(Sequence Diagram)

시퀀스 다이어그램(Sequence Diagram)

• 시퀀스 다이어그램(Sequence Diagram): 객체들의 상호작용을 시간에 따라 표현한 UML 다이어그램

시퀀스 다이어그램(Sequence Diagram) 기본 표기법

• 객체(Object): 시퀀스 다이어그램에서 상호작용하는 개체(객체 또는 클래스)로 각 객체는 다이어그램 상단에 배치되며 수평선으로 이어진 생명선이 있다.
• 생명선(Lifeline): 객체의 존재와 상호작용이 시간에 따라 어떻게 이어지는지를 나타내는 점선으로 객체의 생명주기를 표현하며 시간은 위에서 아래로 흐른다. 활성화 된 경우에는 직사각형으로 표시된다.
• 메시지(Message): 객체들의 상호작용에 사용하는 요청 또는 응답으로 화살표로 표시된다.

메시지 유형

• 동기 메시지: Sender가 요청 후 응답 메시지를 받을 때까지 기다린다. 아래 그림처럼 화살표로 표시된다.
• 비동기 메시지: Sender가 요청 후 응답 메시지를 기다리지 않고 계속 하던 작업을 진행한다. 아래 그림처럼 화살표가 표시된다.
• 반환 메시지: 아래처럼 표시되며 불분명할 때는 생략 가능하다.

Combined Fragments

Guards

객체 간 소통 흐름을 표시할 때 조건을 이용해 흐름 제어를 하는 부분을 Guards라고 한다. 아래 IBM 문서에서는 “[pastDueBalance = 0]”로 나와있다.

Combined Fragments

시퀀스 다이어그램에서 흐름을 제어할 때 사용하는 여러 조건들이 있는데 아래와 같이 여러가지가 있다.

• Branches and Loops
  • alt
  • opt
  • loop
  • break
• Concurrency and Order
  • seq
  • strict
  • par
  • critical
• Filters and Assertions
  • ignore
  • consider
  • assert
  • neg

alt, opt

• alt: switch문으로 생각하면 되며 여러 조건을 명시해 흐름을 제어할 수 있다.
• opt: if문으로 생각하면 되며 하나의 특정 조건에 따른 흐름을 제어할 수 있다.

loop

• loop: 조건에 따른 반복문을 사용해 흐름을 제어할 수 있다.
• 아래의 경우 “[size<0]”을 만족하면 5부터 10까지 반복하는 경우다.

break

• break: 코드에서 exception과 같은 부분으로 조건을 만족하면 해당 fragment를 수행하고 기존에 남은 부분들을 수행하지 않고 바깥 fragment를 빠져나간다.
• 만약 아래의 경우에서 break fragment 아래 다른 내용들이 더 있었다면 해당 내용을 수행하지 않고 loop를 빠져나간다.

seq, strict

• seq: 기본으로 탑재되는 fragment로 기본 순서라 보면 된다.
• strict: 점선으로 나눠진 부분이 차례로 실행되어야 하는 분명한 순서가 존재하는 fragment다.

관련한 좋은 그림이 있어서 다른 블로그에서 가져왔다. seq와 strict의 차이를 알 수 있다. 마지막 그림의 경우 search_google() → search_bing() → search_yahoo() 순서다.

par

• par: parallel의 앞 글자로 말 그대로 병렬로 수행할 수 있는 걸 표현할 때 쓸 수 있다.
• 점선으로 나누어진 fragment별로 상호 간섭 없이 독립적으로 실행될 수 있다.
• 어떤 문서에서는 실제 parallelism은 아니고 concurrency라고 표현한 걸 봤다.
• 아래의 그림에서 add()와 remove()를 parallel하게 요청한다고 볼 수 있다.

critical

• critical: Atomic Area로 상호작용을 독점적으로 실행하고, 다른 요소들의 간섭을 방지할 때 사용한다.
• 해당 critical fragment 안에서의 순서는 기본 값인 seq와 동일하다.
• critical fragment에 들어온 경우에는 다른 메시지 상호작용이나 인터럽트 없이 해당 구역을 다 우선 수행하고 진행한다고 보면 된다.
• 아래의 그림의 경우 add()와 remove()가 순서 관계 없이 add()→remove() 또는 remove()→add() 이렇게 진행될 수 있지만 critical fragment에서는 둘 중 하나만 실행하고 다음 요청을 처리한다.

ignore

• ignore: 특정 유형의 메시지들을 무시하기 위해 사용한다.
• {} 안에 무시할 메시지를 명시한다.
• 아래의 경우 명시된 get과 set이 무시된다.

consider

• consider: 특정 유형의 메시지들을 표시하고 강조하고 나머지는 무시하기 위해 사용한다.
• {} 안에 강조하거나 표시할 메시지를 명시한다.
• 아래의 경우 add와 remove만 고려하고 다른 메시지는 무시한다고 보면 된다.

assert

• assert: 항상 참이어야 하는 상호작용의 일부를 정의하는 데 사용된다고 한다.
• {}로 조건이 명시되기도 하는데 해당 조건을 반드시 만족해야 한다.

neg

• neg: 유효하지 않거나 오류가 난 경우를 표현하기 위해 사용한다.
• neg가 아닌 모든 부분들은 정상 작동된 경우로 가정한다.
• 아래의 경우 timeout이 난 경우에는 잘못된 경우라는 표현이다.

기타

Reference

• 하나의 시퀀스 다이어그램과 다른 시퀀스 다이어그램을 연결할 때 사용하는 방법이다. ref 안에 다른 시퀀스 다이어그램이 존재한다고 보면 된다.

참고자료

• https://en.wikipedia.org/wiki/Sequence_diagram
• https://developer.ibm.com/articles/the-sequence-diagram/
• https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
• https://jsdysw.tistory.com/334
• https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/
• https://www.omg.org/spec/UML/2.5.1

Sequence Diagram

Environment and Prerequisite

• UML

Sequence Diagram

Sequence Diagram

• Sequence Diagram: UML diagram which shows interactions between objects based on time sequence

Sequence Diagram Basic Notation

• Object: Interacting entities(objects or classes) in a sequence diagram which are placed at the top of the diagram, each having a lifeline represented by a vertical dashed line.
• Lifeline: A line shows object’s existence and interactions between objects through time. Time goes up to down. It is depicted as a rectangle when state is active.
• Message: It is an request and response in objects interactions which depicted as directed line.

Message Type

• Synchronous Message: Sender waits until receive response message. It is depicted as an arrow as shown in the diagram below.
• Asynchronous Message: Sender continues execution without waiting for a response message. It is depicted as an arrow as shown in the diagram below.
• Response Message: It is depicted as shown below and can be omitted when unclear.

Combined Fragments

Guards

When indicating the flow of communication between objects, the part that controls the flow using conditions is called Guards. In the IBM document below, it is shown as “[pastDueBalance = 0].”

Combined Fragments

There are many conditions using in sequence diagram like below.

• Branches and Loops
  • alt
  • opt
  • loop
  • break
• Concurrency and Order
  • seq
  • strict
  • par
  • critical
• Filters and Assertions
  • ignore
  • consider
  • assert
  • neg

alt, opt

• alt: It can be thought of as a switch statement, allowing multiple conditions to control the flow.
• opt: It can be thought of as an if statement, where a specific condition controls the flow.

loop

• loop: It can control flow using loops based on conditions.
• Below shows iterate from 5 to 10 if “[size<0]” is true.

break

• break: It is like an exception in code. If condition met, it exits fragment even though there are rest things to do.
• If there were any additional contents below break fragment such as case below, they would not be executed and the loop would be exited.

seq, strict

• seq: This is the default fragment, which can be considered as the basic sequence.
• strict: This fragment has a clear order where the parts divided by dotted lines must be executed sequentially.

I found a good illustration on another blog that shows the difference between seq and strict. In the last diagram, the order is search_google() → search_bing() → search_yahoo().

par

• par: To represent something that can be performed in parallel as the term suggests.
• Each fragment divided by dotted lines can be executed independently without interference.
• In some documents, I’ve seen this referred to as concurrency rather than actual parallelism.
• In the diagram below, you can see that add() and remove() are requested in parallel.

critical

• critical: It is an atomic area which interacts independently with prevent from interfering from others.
• The order within the critical fragment follows the default sequence.
• When entering the critical fragment, that flow runs firstly without other interrupt or other interactions.
• In the diagram below, add() and remove() can proceed in either order add()→remove() or remove()→add() but within the critical fragment, only one of them is executed before handling the next request.

ignore

• ignore: It is used to ignore specific types of messages.
• The messages to be ignored are specified within the {} brackets.
• In the example below, the specified get and set messages are ignored.

consider

• consider: It is used to highlight and emphasize specific types of messages while ignoring others.
• The messages to be highlighted or emphasized are specified within the {} brackets.
• In the example below, only add and remove are considered and the other messages are ignored.

assert

• assert: It is used to define parts of interactions that must always be true.
• Conditions are sometimes specified within {} brackets and these conditions must be satisfied.

neg

• neg: It is used to represent cases that are invalid or have encountered an error.
• All parts that are not neg are assumed to be working normally.
• In the example below, a timeout indicates a case of failure.

Others

Reference

• It is an method which connects sequence diagrams. There is another sequence diagram exists in ref.

Reference

• https://en.wikipedia.org/wiki/Sequence_diagram
• https://developer.ibm.com/articles/the-sequence-diagram/
• https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
• https://jsdysw.tistory.com/334
• https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/
• https://www.omg.org/spec/UML/2.5.1

유스 케이스 다이어그램(Use Case Diagram)

환경

• UML

Use Case Diagram

Use Case

• 유스 케이스(Use Case): 유저가 시스템을 통해서 얻고자 하는 하나의 행위나 이야기를 의미한다.

Use Case Diagram

• 유스 케이스 다이어그램(Use Case Diagram): 액터 그리고 시스템들의 관계를 표현한 다이어그램이다.

액터(Actor), 유스 케이스(Use Case), 시스템 경계(System Boundary)

액터(Actor)

• 액터(Actor): 시스템과 상호작용하는 외부 개체를 나타낸다.
• 다이어그램에서는 사람 모양으로 표시한다.
• Use Case에 있는 그림에서 “Registered User”가 액터다.

유스 케이스(Use Case)

• 정의는 위에 Use Case를 참고한다.
• 다이어그램에서는 타원으로 표시한다.
• Use Case에 있는 그림에서 “Edit an article.”이 유스 케이스다.

시스템 경계(System Boundary)

• 시스템 경계(System Boundary): 설계하고자 하는 시스템의 모델의 나타낸다.
• 다이어그램에서는 사각형으로 표시한다.
• Use Case Diagram에 있는 그림에서 “System Boundary”가 시스템 경계다.

관계(Relationship)

연관(Association)

• 연관(Association): 액터와 유스 케이스의 상호작용을 나타낸다.
• Ex) 유저가 보드를 수정한다.

포함(Include)

• 포함(Include): 다른 유스 케이스를 포함하는 관계를 의미한다.
• Ex) 글을 올리는건 사진 추가를 포함한다.

확장(Extend)

• 확장(Extend): 특정 조건을 만족하면 다른 유스 케이스로 확장될 수 있는 관계를 의미한다.
• Ex) 비행기 예약은 어떤 조건이 되면 좌석을 선택할 수 있다.

일반화(Generalization)

• 일반화(Generalization): 상속과 비슷한 개념으로 유스 케이스가 다른 유스 케이스들의 일반화된 상위 유스 케이스임을 나타낸다.

참고자료

• https://en.m.wikipedia.org/wiki/Use_case
• https://en.wikipedia.org/wiki/Use_case_diagram
• https://www.geeksforgeeks.org/use-case-diagram/
• https://www.ibm.com/docs/ko/rational-soft-arch/9.7.0?topic=diagrams-use-case