지금까지 requirement description 을 기반으로 커뮤니케이션 다이어그램 또는 시퀀스 다이어그램을 그린 뒤, 이 결과를 클래스 다이어그램으로 변환하는 모든 과정을 살펴보았다.이번 글에서는 사용자 UI 를 설계하는 과정을 더 자세히 정리한다. 우리는 시스템 아키텍처를 설계할 때 boundary class, control class, entity class 3가지 종류로 구분하여 설계하였다.이를 가리켜 3-tier architecture 라고도 부른다. boundary class 는 presentation layer 라고도 부르며,사용자 또는 다른 외부 시스템에서 사용하는 인터페이스를 다루고,사용자가 데이터를 입력할 수 있는 매커니즘을 제공하며,인터페이스에 가지고 있는 데이터를 적절하게 포맷팅..

지난 글에서는 커뮤니케이션 다이어그램 대신 그릴 수 있는 시퀀스 다이어그램에 대해 정리하였다.이번 글에서는 커뮤니케이션 다이어그램 / 시퀀스 다이어그램을 통해 그렸던 analysis class diagram 에 detailed design 을 추가하는 방법을 정리해본다. 클래스 다이어그램에 detailed design 을 추가하는 것은 다음 작업들을 하는 것이다. 1. 어트리뷰트 타입 추가클래스 다이어그램에 어트리뷰트를 기술할 때는 다음과 같이 기술한다. 이름 : 타입 = 초기값 {특성 값} 특성 값에는 constant, fixed, not null 과 같은 특성을 기술한다.이름 앞에 / 를 붙이면 상속받은 (derived) 특성을 나타내고, 밑줄을 그으면 class-scope(static) 변수를 나타..

지난 글에서는 use case description 으로부터 시스템을 설계하는 class diagram 을 만드는 과정을 정리하였다.이때 중간에 오브젝트 간 상호작용을 표현하는 방법으로서 communication diagram 으로 상호작용을 표현했다.이번 글에서는 sequence diagram 이라는 또 다른 오브젝트 간 상호작용 표현 방법을 정리해본다. Sequence Diagram시퀀스 다이어그램은 오브젝트간 상호작용을 시간순으로 나타낸 다이어그램이다.그리고 이 상호작용의 디테일 정도는 계층을 나눠서 필요한 만큼만 표현한다.한번에 모든 상호작용의 전체 디테일을 다 표현하면 너무 복잡하기 때문이다. 시퀀스 다이어그램은 클래스 다이어그램을 그리기 전 커뮤니케이션 다이어그램 대신에 그릴 수 있는 다이어그..

세상에서 제일 바빴던 5월이 지나갔다.팀플, 학교 내외에서 진행하는 프로젝트, 스터디 활동 등만족스러운 경험, 만족스럽지 못한 경험들이 많았다. 진로 관련1. 전공소프트웨어 공학은 랜덤으로 구성된 팀원들과 팀플을 진행했다.모두 각자의 역할을 열심히 수행해서 팀원에 대한 스트레스는 하나도 없었지만, qna를 보면서 교수님의 답변을 따라 과제를 수시로 수정하는 점은 힘들었다. 그래도 과제 결과가 만족스럽게 나와서 다행이었고, 이때는 5월 초에 진행해서 소공에만 집중할 수 있었다보니 괜찮았다. 다음 소공 과제는 개인과제로 1차, 2차로 나뉘어 진행했다.1차는 클래스 다이어그램을 그려 설계만 하는 과제, 2차 과제는 코드로 구현하고 실행을 확인한 뒤 수정된 설계도를 그리는 과제였다.지금까지는 머릿속으로 설계하고..

소프트웨어 개발의 주요 단계를 다시 정리해보면 다음의 5단계를 거쳐서 소프트웨어를 개발한다. 1. specification2. design3. implementation4. test5. maintenance specification 단계에서는 사용자의 요구사항을 파악하고, use case diagram 을 통해 시스템의 기능을 시각화하였다.그리고 사용자의 액션에 따라서 시스템이 어떻게 응답해야 하는지 use case description 을 작성하여 시스템에서 개발해야 하는 부분이 어디인지 명확하게 정의하였다. 이번 글부터는 design 단계를 진행한다.design 단계에서는 앞서 파악한 요구사항을 분석하여, 실제로 프로그램을 개발할 때 어떤 클래스와 메서드를 사용할 지 설계한다.이 과정을 마치고나면 커..

지난 글에서 정리했듯 BST 는 on-disk 자료구조로는 적합하지 않았다.그래서 BST 를 기반으로 fanout 이 크고 트리의 높이도 더 작은 B-Tree 라는 자료구조가 등장했다.이번 글에서는 제일 기본적인 B-Tree 에 대해 정리해본다. B-Tree 를 그림으로 표현하면 아래와 같이 표현할 수 있다. 또는 책에 따라서 아래와 같이 표현하기도 한다. B-Tree 내부 각 노드가 보유한 key 값들은 일정한 순서로 정렬되어 있다.(위 그림의 경우라면 key1 따라서 하나의 노드 안에서 특정 키를 찾을 때는 이분 탐색을 사용하여 원하는 키를 찾을 수 있다. 꼭 노드 내부가 아니더라도, B-Tree 의 데이터 탐색 시간복잡도는 로그 시간복잡도를 갖는다.예를 들어 40억개 데이터 중에서 원하는 데이터..

이번 글부터는 가장 유명한 저장 구조인 B-Tree 를 이해하는데 있어 필요한 기본적인 개념들을 정리한다.지난 글에서도 언급했듯 B-Tree 는 mutability 를 갖는 저장 구조이다.그리고 대부분의 mutability 구조는 in-plcae update 메커니즘을 사용한다.이 말은 데이터를 삽입, 수정, 삭제하는 연산을 수행할 때, 그 데이터가 저장된 그 파일 안에서 연산이 일어난다는 것을 말한다. 어떤 스토리지 엔진은 같은 데이터 레코드의 여러 버전을 동시에 저장하기도 한다.다중 버전 동시성 제어, Slotted Page 가 그 예시이다.하지만 이해를 간단히 하기 위해, B-Tree 를 정리할 때는 하나의 데이터 레코드가 저장된 위치는 유일하다고 가정하자. Binary Search TreeB-Tr..

데이터베이스 스터디를 하며 인덱스를 내용을 공부하고 발표한 뒤, covering index 에 대한 질문을 받았다.스터디 책에서는 data file 을 구현하는 방법 중에 모든 데이터 레코드가 인덱스 파일에 들어있는 index-organized tables (IOT) 방식을 소개하고 있었는데, IOT 와 covering index 가 같은 개념인지 묻는 질문이었다.covering index 개념을 처음 들어봐서 다른 분의 답변을 듣고 공부할 수 있었는데, 새로 알게된 개념인만큼 이번 기회에 정리해보려고 한다. Covering Indexcovering 은 포괄한다는 의미를 갖고 있다.인덱스는 테이블 데이터를 찾을 때 사용할 일부 컬럼에 대한 데이터를 갖고 있는데, 이 데이터만으로 쿼리를 커버할 수 있는 인..

스토리지 엔진은 특정 자료구조를 기반으로 만들어진다.하지만 캐싱, 복구, 트랜잭션과 같은 기능은 이런 자료구조가 설명해주지 않는다. 스토리지 구조에는 크게 3가지 공통 변수가 있다. 1. buffering 사용 여부2. immutable file 또는 mutable file 사용3. 데이터 저장시 정렬 여부 스토리지 구조가 갖는 최적화 방법과 구별 기준 대부분은 이 3가지 개념 중 하나와 관련되어 있다. Buffering스토리지 구조가 디스크에 데이터를 저장하기 전에 특정 양의 데이터를 모았다가 저장하는지 아닌지를 나타낸다.물론 모든 디스크 기반 구조는 어느정도 버퍼링 기법을 사용할 수 밖에 없다.디스크가 최소한 block 단위로 데이터를 전달하므로, 블록 데이터를 모았다가 쓰는 것이 좋기 때문이다.따라..

개요이제 스토리지 엔진이 어떻게 데이터를 저장되는지 정리하기에 앞서, data file 과 index file 에 대해 정리해보려고한다.우리는 왜 데이터를 단순히 파일 시스템이 아니라 DBMS 를 사용해서 저장할까? DBMS도 데이터를 저장할 때 파일로 저장하지만, DBMS 는 파일 시스템이 제공하는 디렉토리 / 파일의 계층 구조를 사용하지 않는다.또한 파일을 만들 때도 DBMS에서 직접 결정한 포맷에 맞춰 파일을 구성한다.이렇게 하는 이유는 크게 3가지 이유가 있다. 1. Storage EfficiencyDBMS는 데이터 레코드를 저장할 때 storage overhead 를 최소화하는 방식으로 파일을 구성한다. 2. Access Efficiency원하는 레코드를 찾을 때 최소한의 단계를 거쳐서 찾을 수..