'전체 글'에 해당되는 글 32건

0. 들어가기에 앞서

 클래스 다이어그램은 시스템 구조를 나타내고, 객체지향 모델링의 빌딩 블록으로 사용된다.

 여러 다이어그램들 중 객체지향 언어와 직접적인 연관을 가지는 유일한 다이어그램이고, 어플리케이션의 구조 디자인, 분석, 시스템의 역할 묘사, 그리고 Reverse Engineering(역공학)에 사용될 수 있다.

 개인적인 프로젝트 경험으로, 시스템이 어떤 요소들로 구성되는지 사람들에게 설명해주고, 시스템 유지 보수를 위해서 많이 사용했었다.

1. 클래스 다이어그램

 클래스 다이어그램은 클래스와 클래스들 사이의 관계를 나타내는 정적 모델이다.

 클래스 다이어그램은 클래스와 그들 사이의 Relationship(관계)로 구성된다.

1.1 클래스(Class)

- 시스템 내의 오브젝트들(사람, 장소, 물건 등등)

- 시스템 내의 정보를 저장/관리한다.

- Attribute(클래스의 특성), Operation(클래스의 동작)을 가진다.

예시

환자 클래스

 이는 진료 예약 시스템에서 환자(Patient)라는 클래스다.

 Patient 클래스는 amount(진료비), insurance carrier(보험회사 명)이라는 Attribute를 가지고, make appointment(진료 예약), calcuate last visit(최근 방문일 계산), change status(상태 변환), provides medical history(진료기록 제공)이라는 Operation을 가진다.

1.2 Relationship

- 클래스들 사이의 관계

- 클래스들 사이의 선으로 표현된다.

예시

 이것도 병원 진료 예약 시스템의 일부분이다.

 Patient는 Appoinment(예약)을 스케줄하는 관계를 가진다.

 Patient 1명이 여러번 진료 예약을 할 수 있으니, Patient는 n (0 <= n)개의 Appointment와 관계를 가진다.

클래스 다이어그램 예시 

 이 그림은 클래스 다이어그램의 한 예시다.

2. Relationship의 종류

 클래스들간의 관계를 나타내는 Relationship에는 다음과 같은 것들이 있다.

 Association은 클래스와 클래스 사이의 관계, 혹은 클래스 자신과의 관계를 나타낸다.

 단순한 줄로 표시하고, 연관된 클래스가 서로 어떤 관계를 나타내는지를 표시하고, Multiplicity Symbol이라는 것을 가진다. 이 예시의 경우 오른쪽 클래스 하나당 왼쪽 클래스가 0개이상 관계를 가지는 예시다.

 Generalization은 a kind of 관계를 나타낸다.

 객체지향 언어에서 부모 클래스 상속, 인터페이스 구현을 이것으로 표현한다.

 Aggregation은 Association의 한 종류로, 논리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Aggregation 관계를 가진다고 표현 할 수 있다.

 Composition은 Association의 한 종류로, 물리적인 a part of 관계를 나타낸다. A class is a part of B class라고 하면 A는 논리적으로 B와 Composition관계를 가진다고 표현 할 수 있다.

Aggregation VS Composition

 Aggregation과 Composition은 모두 포함 관계를 나타내는데, 논리적/물리적인 관계를 나타낸다는 차이만 있다.

 이게 잘 헷갈리는 부분인데, A is a part of B일 때 이 관계가 Aggregation 관계면 B가 소멸되도 A는 소멸되지 않고, Composition 관계면 B가 소멸 되면 A도 함께 소멸된다고 보면 된다.

(그리고 두 경우 모두 A가 소멸되도 B는 소멸되지 않는다.)

 예를 들어, "학생 is a part of 동아리" 관계는 Aggregation 관계이고, "바퀴 is a part of 자동차" 관계는 Composition 관계다. 동아리가 소멸되어도 학생들은 소멸되지 않기 때문에 이는 논리적인 관계고, 자동차가 소멸 될 때는 바퀴도 함께 소멸되므로 물리적인 관계라고 볼 수 있다. (바퀴를 따로 떼서 파는 경우는 생각하지 말도록 하자.)

3.클래스 다이어그램 간소화

 클래스에는 Concrete Class와 Abstract Class가 있다. 그 중 Concrete Class만 묘사하여 다이어그램을 간소화하는 방법인데, 이는 잘 고려해보고 써야한다.

 어떤 Concrete Class인 CClass가 Abstract Class인 AClass를 상속받고 있고, 다른 외부 클래스들이 주로 AClass와 관계를 가지는 경우, 이 방법을 쓰면 다이어그램을 이해하기 어려워지는 원인이 될 수 있기 때문이다.

 View 메커니즘은 원래 데이터베이스에 나오는 개념이다.

 데이터베이스에서 View는 필요한 데이터만을 원하는 형태로 골라서 본다는 개념인데, 이를 클래스 다이어그램에도 적용하여 상황에 따라 필요한 클래스들만 묘사하여 다이어그램을 간소화하는 방법이다.

 연관된 클래스들끼리 묶어 패키지로 만드는 방법이다. 패키지로 취급하면 다이어그램이 더 간단해질 수 있다.

4. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9E%98%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8 - 위키피디아 클래스 다이어그램

https://www.tutorialspoint.com/uml/uml_class_diagram.htm - Tutorial Point. Class Diagram

1. Activity Diagram이란?

 액티비티 다이어그램은 일련의 Activity들로 어떤 프로세스를 표현하는 다이어그램으로, 모든 종류의 프로세스를 표현하는데 사용 될 수 있다.

2. Acitvity Diagram의 구성

 Action/Activity - 어떤 Action이나 Action의 집합. 동사 + 명사로 이름이 붙여짐.

 Object Node - 한 Activity에서 다른 Activity로 이어지는 flow of information을 나타내는 것.

 Control Flow - 실행 순서를 나타내는 화살표.

 Object Flow - Flow of Object를 나타내는 것.

 Initial Node - Activity Diagram의 시작점(Action 들의 시작점)

 Final Node - Activity Diagram 종료지점(Activity의 Flow들이 모두 끝나는 시점)

 Decision Node - 분기점.

 Merge Node - Decision Path들을 하나로 모으는 노드.(Decision Node로 나눠진 Control flow를 다시 합침)

 Fork Node - 평행적으로 수행되는 Flow를 나누는 노드

 Join Node - Fork Node로 나눠진 Control Flow를 다시 하나로 합치는 노드

 구성 요소들을 정리해놓고 보니 너무 많고 애매한 정의가 많아서 정의를 달달달 외우는 것 보다는 예시를 보면서 이해하고, 나중에 필요할 때는 예시와 정의를 같이 찾아보는게 좋겠다.

 컨트롤 노드

 Initial node, Final node, Decision node, Merge node, Forke node, Join node를 컨트롤 노드(Control Node)라고 부른다.

 예제

 다음 액티비티 다이어그램은 병원의 진료 예약 관리 기능에 대한 것이다.

 진료 예약 관리에서는 예약, 예약 취소, 예약 변경 기능을 제공한다.

 처음 이 액티비티가 시작되면 환자의 정보를 받는다.(Get Patient Onformation)

 이 때 예약정보(Appt Request Info) 오브젝트가 생성되어 이후 예약 할 지, 예약을 취소 할 지, 예약을 변경 할 지 결정할 때 사용된다.(기존 환자)

 또, 이 오브젝트는 신규 환자가 예약을 잡을 때도 사용된다.

 환자의 정보를 받은 이후에는 기존에 등록된 환자인지, 신규환자인지에 따라 다른 프로세스가 진행된다.

3. Swimlanes

 Swimlane은 오브젝트들간의 역할 분리를 나타낸다. 분리된 역할들이 서로다른 오브젝트에서 평행적으로 수행된다.

 Swimlane은 가로로 그려도 되고 세로로 그려도 된다.

 예제

 이 예제는 학교 점심 도시락을 만드는 Activity에 대한 액티비티 다이어그램이다.

 이 액티비티가 시작되면 바로 firstParent와 secondParent로 flow가 분할되어 평행적으로 진행된다.

 firstParent를 보면 내부에서 다시 GetJelly, GetPeanutButter, GetBread로 flow가 분할되어 평행적으로 수행되는데, 처음에 firstParent, secondParent로 나뉜것과는 달리 모든 flow가 오브젝트 내부에서 수행된다는 차이가 있다.

4. Activity Diagram 작성 가이드라인

5. Activity Diagram과 Usecase의 관계

6. 레퍼런스

System Analysis & Design 5th - WILEY

1. 유즈케이스(Use case)

 사용자가 시스템을 어떻게 사용하는지를 나타내는 것.

 시스템의 기본적인 기능들(사용자가 시스템을 사용하여 어떤 일들을 할 수 있는지, 시스템이 어떤 방식으로 반응하는지)를 나타내는 것.

 하나의 유즈케이스는 사용자가 어떤 작업을 처리할 때 수행하는 일련의 과정들이다.

 유즈 케이스는 소프트웨어를 설계하는 과정에서, 건축용 블록과 같은 역할을 한다.

 각각의 유즈케이스들은 각각 하나의 역할만을 설명한다.

2. Usecase 다이어그램

2.1 Usecase 다이어그램의 기본 구성

 유즈케이스는 다음과 같은 요소들로 구성되는 다이어그램으로, UML(Unified Modeling Language)로 표현한다.

- 액터 : 시스템을 이용하려고 하는 서브젝트 외부의 사람, 혹은 시스템. 스틱맨으로 표현하기도 하고, 박스로 표현하기도 함

- 유즈케이스 : 시스템 기능의 주요한 조각.

- 서브젝트 : 주제의 범위를 나타내는 것.

예시

병원 진료 예약 시스템의 유즈케이스 다이어그램

 이 예시에서 시스템은 예약 조율, 스케줄 제공, 가능한 시간 입력이라는 기능을 제공한다.

 각각의 기능들은 유즈케이스로 표현, 진료예약 시스템이라는 Subject로 범위 제한, 액터는 환자, 관리자, 의사 이렇게 3명이다.

 각각의 유즈케이스들은 환자, 관리자, 의사라는 액터와 상호작용하므로 Association 관계로 표현한다.

2.2 Usecase 간의 관계

 유즈케이스들 간에 서로 Genalization, Inclusion, Extension 관계를 가질 수 있다.

- Genalization : 일반화(generalized)된 유즈케이스는 좀 더 자세하게 정의된 유즈케이스다.

- Inclusion : A가 B를 Include한다는 것은, A의 작업이 B를 포함한다는 것을 나타낸다.

- Extension : 예외적인 상황을 커버하기 위해 사용되는 관계.

예제

병원 진료 예약시스템 확장판

 몇 가지만 살펴보자.

 우선 환자가 예약을 하는 유즈케이스(Manage Appointments)는 환자가 신규 환자, 기존 환자 두 가지 타입으로 늘어났으니, 신규 환자 예약(Make New Patient Appt)과 기존 환자 예약(Make Old Patient Appt) 두 가지로 나누어야한다. 그래서 Genalization 관계를 적용해 두 가지 유즈케이스로 나누었다.

 새로운 환자가 예약을 잡는 유즈케이스는(Make New Patient Appt) 신규 환자 등록이라는 유즈케이스(Create New Patitent)를 포함하므로 includsion 관계로 표현한다.

 환자 정보를 업데이트하는 유즈케이스(Update Patient)는 기존 환자가 예약을 잡는 유즈케이스(Make Old Patient Appt)에서 특별한 경우(환자 데이터를 업데이트 해야하는 경우)에만 사용되므로 Make Old Appt 유즈케이스에서 확장되어 extension 관계로 표현된다. (화살표 방향을 쉽게 헷갈리므로, 헷갈리지 않게 주의)

3. UseCase Description

 유즈케이스를 문서에 포함할 땐 유즈케이스 다이어그램은 필수로 들어가야하고, 유즈케이스 Description은 선택적으로 넣는다. 유즈케이스 Description은 유즈케이스 다이어그램 작성에 필요한 모든 정보들을 담는 것으로, 하나의 UseCase Description이 하나의 UseCase를 설명한다. (유즈케이스 다이어그램 전체를 설명하는 것이 아니다.)

 개인적인 경험상 유즈케이스들마다 일일히 Description을 작성하려면 시간 소모가 커서 굳이 필요하지 않다면 생략하는게 나을 듯 싶다.

 UseCase Description은 다음의 세 부분으로 구성된다.

- Overview : 이름, ID, 종류, 가장 중요한 액터, 간략한 요약, 중요도 레벨, Stakeholders(관계자들), 트리거

- Relationships : 유즈케이스들 간의 Association, Extend, Include, Generalization.

- The flow of events : Normal flow(보통의 활동들), Sub flow(유즈케이스를 간단하게 하기 위해 Normal flow를 분해한 것), Alternate/Exceptional flow()

- 기타 사항들

예시

4. 유즈케이스 작성 요령

* Kiss 원칙 : Keep It Simple Stupid의 약자. 원칙이라기보다는 복잡한 것 보다는 간단한 게 좋다는 일종의 격언이다.

5. Use Case Description 작성 요령(순서)

6. 레퍼런스

System Analysis & Design 5th - WILEY

https://ko.wikipedia.org/wiki/KISS_%EC%9B%90%EC%B9%99 - KISS 원칙

1. 개요

 헐리우드 원칙은 프로그래밍 원칙 중 하나다.

 헐리우드 원칙을 적용하면, 저수준 구성요소에서고수준 구성요소를 집적 호출 할 수 없게 하고, 고수준 구성요소가 저수준 구성요소를 직접 호출 하는것은 허용하게 됩니다.

 이렇게 하면 의존성 부패(dependency rot) 현상을 방지할 수 있습니다.

2. 의존성 부패

의존성 부패현상이란, 고수준 구성요소가 저수준 구성요소에 의존하고, 또 그 저수준 구성요소는 고수준 구성요소에 의존하고, 고수준 구성요소가 또다른 구성요소에 의존하고... 이런식으로 의존성이 복잡하게 꼬이는 것을 말한다.

 시스템이 이런식으로 구현되면 시스템이 어떤식으로 디자인 된 것인지 알아보기가 어려워진다.

3. 레퍼런스

- Head First Design Pattern(O'REILLY media)

- https://zetawiki.com/wiki/Hollywood_%EC%9B%90%EC%B9%99 : 제타위키

1. MIT 라이센스란

 MIT 라이센스는 MIT 공대에서 나온 소프트웨어 라이센스다.

 MIT 라이센스 표기는 다음과 같은 형식으로 되어있다.

 MIT License
Copyright (c) 2017 gwiazdorrr
     
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
     
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
     
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

2. 제약 및 허가 사항

 오픈소스 라이브러리들의 경우 MIT 라이센스를 따르는게 자주 보이며, 다른사람이 만든 오픈소스를 사용할 때마다 이걸 수정해서 써도 되는가, 상용 소프트웨어에 활용해도 되는가 등이 헷갈리기 때문에, 확실히 알아두고 갈 필요가 있다.

 MIT 라이센스는 다음의 사항들을 제약하고, 허가한다.

 쉽게 말해, 개발하는 프로젝트에 라이센스 문구를 표시해주면 상용으로도 사용 가능하고, 수정해서 사용하는 것도 자유라는 것이다.

3. MIT 라이센스 표기 예시

 MIT 라이센스 표기 예시로, 게임 개발 엔진인 유니티 엔진 에셋 중, Better Streaming Assets 라는 에셋이 있다. 무료로 이용가능하고, MIT 라이센스 표시를 달고 나오는데, 이 에셋을 다운로드 받으면 README.txt 파일 내에 MIT 라이센스가 표기되어있다.

 MIT 라이센스는 이처럼 프로젝트 폴더 내에 표기를 해 두면 되고, LICENSE.txt, README.txt 등 파일에 표기하면 된다.

4. 라이센스 소프트웨어 사용 표기 예시

 이 예시들은 MIT 라이센스 뿐만 아니라 라이센스 표기를 요구하는 다른 라이센스들 모두에 해당되는 사항이다.

 문서 파일 뷰어인 Polaris office의 모바일 앱에서는 다음과 같이 라이센스들을 표기한다.

 폴라리스 오피스는 라이센스를 조금 약식으로 표기한 것으로 보인다.

 구글 플레이 스토어가 라이센스 표기를 정말 잘 해놓은 예시인데, 각 라이센스들에 대한 카피라이트 전문을 볼 수 있게 해 뒀다.

 오픈소스를 사용 할 때 라이센스 표기는 이 예시들과 비슷하게 해두도록 하자.

5. 레퍼런스

https://ko.wikipedia.org/wiki/MIT_%ED%97%88%EA%B0%80%EC%84%9C - 위키피디아:MIT 라이센스

https://www.olis.or.kr/license/qnaDetail.do?bbsNum=27161 - OLIS 오픈소스SW 라이센스 종합정보 시스템 관련 질문 글.

https://kyeonjung.tistory.com/15 - continue 블로그. 외부 라이브러리 라이센스 고지 방법

 유니티 엔진으로 모바일 게임을 개발하던 중, 한글 파일을 읽으면 한글이 깨지는 문제를 겪였다.

 문제 원인은 모바일 기기의 기본 인코딩 방식이 euc-kr가 아니었고, euc-kr 인코딩을 지원하지도 않는 것이었다.

1. 한글 인코딩으로 변환

 읽어온 데이터를 한글 인코딩으로 변환하면 문제는 해결된다.

 이는 다음 코드를 이용하여 구현할 수 있다.

System.Text.Encoding.GetEncoding("euc-kr");   : euc-kr 인코딩 클래스 변수를 얻어옴

예제 

//결과 텍스트(인코딩 전)
byte[] resultBytes = www.bytes;
            
System.Text.Encoding euc = System.Text.Encoding.GetEncoding("euc-kr");            //한글을 읽기 위한 euc-kr 인코딩

//읽은 파일 데이터를 euc-kr 인코딩으로 변환
string convertedString = euc.GetString(resultBytes);

 그런데 System.Text.Encoding.GetEncoding("euc-kr") 부분에서 에러가 발생했다.

 유니티 에디터에서는 아무런 문제도, 경고도 뜨지 않았는데, 안드로이드 기기에서 테스팅 할 때만 이 코드에서 오류가 발생해서 문제를 또 찾아봤는데, 인코딩과 관련된 dll 파일이 없는게 원인이었다.

 문제 해결을 위해서는 인코딩과 관련된 dll인 I18N.dll, I18N.CJK.dll 파일을 복사해서 유니티 프로젝트의 Assets/Plugins 디렉토리에 넣고 새로 빌드하면 된다.

 이 두 dll 파일들은 ...\Unity\Editor\Data\Mono\lib\mono\unity 디렉토리 내에 있으니 복사해서 사용하면 된다.

dll 파일들 위치

2. 레퍼런스

https://202psj.tistory.com/1297 - 유니티 모바일에서 한글 인코딩 사용하기

https://forum.unity.com/threads/solved-application-crash-with-notsupportedexception.415325/ - GetEncoding() 에러 해결 방법