Welcome to gwimong's Blog!

안녕하세요. 귀몽이의 개인 블로그입니다.

Mapstruct로 DTO 변환 시 주의 사항

2023-07-25

Programming

Spring Mapstruct

Mapstruct

MapStruct is a code generator that greatly simplifies the implementation of mappings between Java bean types based on a convention over configuration approach. The generated mapping code uses plain method invocations and thus is fast, type-safe and easy to understand.

MapStruct는 Java bean 유형 간의 매핑 구현을 단순화하는 코드 생성기입니다.

Spring에서는 interface를 정의하고 @Mapper 이노테이션을 달아주면, 간단하게 코드를 자동 생성시키고 이를 bean으로 등록시킵니다.

@Mapper
public interface TestMapper  {
    TestMapper MAPPER = Mappers.getMapper(TestMapper.class);
}

위의 TestMapper 코드에 변환하고자 하는 Java bean 유형을 정의하여 사용하면 됩니다.

주의 사항

Mapstruct는 매핑 구현 코드를 자동으로 생성 할 때, 변환하고자 하는 Java bean 유형의 생성자 또는 builder 를 사용하여 구현됩니다.

id와 name 필드를 가지는 Entity입니다.

@Data
@NoArgsConstructor(access = AccessLevel.PROTECTED, force = true)
public class TestEntity {
    int id;
    String name;
    
    @Builder
    public TestEntity(String name) {
        this.name = name;
    }
}

DTO를 Entity로 변환하는 맵퍼입니다.

@Mapper
public interface TestMapper {
    TestMapper MAPPER = Mappers.getMapper(TestMapper.class);
    TestEntity toEntity(TestDto dto);
}

생성자 이용 시

생성자에 지정된 필드를 기준으로 매핑 구현 코드가 생성 됩니다.

public class TestDto {
    
    private String name;
    
    public TestDto(String name) {
        this.name = name;
    }
}

public class TestMapperImpl implements TestMapper {
    public TestEntity toEntity(TestDto dto) {
        if (dto == null) {
            return null;
        }

        String name = null;
        name = dto.getName();

        TestEntity testEntity = new TestEntity(name);

        return testEntity;
    }
}

위 코드를 빌드하면 아래와 같은 경고 가 발생합니다.

Task :compileJava
mapper\EntityMapper.java:4: warning: Unmapped target property: “id”.
TestEntity toEntity(TestDto dto);

1 warning

TestEntity의 id 필드와 팹핑되는 필드가 없어서 발생하는 경고입니다.
이를 해결하기 위해 Mapping 시 id를 매핑하지 않도록 설정합니다.

@Mapper
public interface TestMapper {
    TestMapper MAPPER = Mappers.getMapper(TestMapper.class);

    @Mapping(ignore = true, target = "id")
    TestEntity toEntity(TestDto dto);
}

Builder 이용 시

정의된 Builder 메소드를 통해 매핑 구현 코드가 생성 됩니다.

public class TestDto {

    private String name;

    @Builder
    public TestDto(String name) {
        this.name = name;
    }
}

public class TestMapperImpl implements TestMapper {
    public TestEntity toEntity(TestDto dto) {
        if (dto == null) {
            return null;
        }

        TestEntityBuilder testEntity = TestEntity.builder();

        testEntity.name(dto.getName());

        return testEntity.build();
    }
}

빌드 패턴을 사용하면, 위의 “warning: Unmapped target property”가 발생하지 않습니다.
(Mapstruct는 builder가 모든 필드를 맵핑한 것으로 판단하는 것 같습니다.)

Lombok의 @builder로 빌드 패턴을 사용 시,
annotationProcessor의 순서는 mapstruct-processo가 lombock보다 앞에 정의 되어야 합니다.

annotationProcessor "org.mapstruct:mapstruct-processor:1.4.2.Final"
annotationProcessor "org.projectlombok:lombok:1.18.20"
annotationProcessor "org.projectlombok:lombok-mapstruct-binding:0.2.0"

Read All

plantuml로 Software Architecture 작성하기

2023-07-10

Tools

Plantuml C4 model
Software architecture를 표현하기 위한 다양한 방법들이 있지만, 저는 시스템을 분석 및 설계할 때 주로 아래의 문서를 작성합니다.
- Software Requirements Specification(Functional Specification)
- Usecase Diagram
- System Architecture Diagram
- Infra Architecture Diagram
- UI Wireframe
- Entity Relationship Diagram
- Sequence Diagram
- Data Flow Diagram
- Status Flow Diagram
초기에는 Microsoft PowerPoint로 모든 아키텍처를 표현했었습니다.
단순한 시스템 구성도에서부터 다양한 다이어그램까지(시퀀스 다이어그램, 액티브 다이어그램, ERD 등), 거의 모든 문서를 MS PowerPoint 하나로 해결 할 수 있었습니다.
(물론 지금도 가장 많이 사용하고 있는 도구 중 하나입니다.)

MS PowerPoint는 분명 만능의 도구이지만, 그 만큼 자유도가 높아 매번 다른 스타일의 문서가 생성되었고, 지속적으로 관리가 되지 않았습니다.
이러한 설계 문서는 작성하는 것도 중요하지만, 관리도 매우 중요합니다.

보통 시스템 분석 및 설계 시 열심히 작성해 놓고, 그 이후에는 잘 보지 않는 경우가 많았습니다.
왜냐하면 초기 설계 이후로 변경된 내용들을 지속적으로 갱신 하지 않았기 때문입니다.

좀 더 체계적으로 사용할 수 있는 방법을 찾아보며 다양한 도구들을 사용해보았습니다.

그러다 최근 정착하게 된 도구가 plantuml입니다.

PlantUML

PlantUML은 사용자가 일반 텍스트 언어로 다이어그램을 작성할 수 있는 오픈 소스 도구입니다.
일반 텍스트 언어로 작성하기때문에 기존에 사용 중인 소스 형상 관리 도구에 그대로 적용 할 수 있습니다.

예를 들어, Git과 같은 형상 관리 서버의 해당 프로젝트 내에서 설계 문서를 함께 관리 할 수 있습니다.

또한, 다양한 다이어그램을 작성 할 수 있어 설계 문서의 양식을 통일 할 수 있습니다.
- 시퀀스 다이어그램
- 유스케이스 다이어그램
- 클래스 다이어그램
- 객체 다이어그램
- 액티비티 다이어그램 (예전 문법은 여기에)
- 컴포넌트 다이어그램
- 배치 다이어그램
- 상태 다이어그램
- 타이밍 다이어그램
C4 Model

C4 Model은 소프트웨어 시스템의 아키텍처를 모델링하기 위한 그래픽 표기법 중 하나로,

UML과 4+1 아키텍처 뷰 모델을 기반으로

시스템을 계층 수준에 따라 시각적으로 표현하고 이를 문서화합니다.
- Level 1 : 범위 내 시스템과 사용자 및 다른 시스템과의 관계(=System Diagram)
- Level 2 : 시스템을 상호 관련된 컨테이너로 분해(=Container Diagram)
- Level 3 : 컨테이너를 상호 관련된 구성 요소로 분해(=Component Diagram)
- Level 4 : 코드에 맵핑 할 수 있는 수준으로 분해(=Code Diagram)
C4-PlantUML

C4-PlantUML은 PlantUML로 다이어그램을 생성하기 위한 매크로로 스트레오타입 등이 정의되어 있습니다.
(PlantUML이 제공되는 다이어그램에 C4 Model 스타일을 적용)

지원되는 다이어그램 목록 :
- 시스템 컨텍스트 및 시스템 환경 다이어그램
- 컨테이너 다이어그램
- 구성 요소 다이어그램
- 동적 다이어그램
- 배포 다이어그램
- 시퀀스 다이어그램
Read All
QGroundControl 개발 환경 구축하기

2023-06-19

Aerospace

Term Acronyms
QGroundControl 소스 코드를 가져와 기본적으로 빌드하는 방법을 설명합니다.

Source Code
```
$ git clone --recursive -j8 https://github.com/mavlink/qgroundcontrol.git
```
Build QGC

QGC(2023.06.19, qgc v4.2.6)는 QT 5.15.2를 대상으로 테스트되었으며, 그외 버전은 정식으로 지원하지 않습니다.

Do not use any other version of Qt! QGC has been thoroughly tested with the specified version of Qt (5.15.2). There is a significant risk that other Qt versions will inject bugs that affect stability and safety (even if QGC compiles).

Using Containers

Linux Conntainer 이미지로

제공되는 Docker 파일을 이용하여 별도의 설치 없이 빌드 및 배포를 수행 할 수 있습니다.
(해당 Docker 파일은 Ubuntu 20.04로 구성되어 있습니다.)

To install :
1. Docker 다운로드 및 설치
2. Docker 이미지 생성
  > cd qgroundcontrol > docker build --file ./deploy/docker/Dockerfile-build-linux -t qgc-linux-docker .
3. Build 1) 다운로드한 레포지토리 폴더로 이동 shell $ cd qgroundcontrol
  2) 빌드를 수행할 디렉토리를 생성하고 이미지 실행 shell > docker run --rm -v ${PWD}:/project/source -v ${PWD}/build:/project/build qgc-linux-docker
Native Build

macOS, Linux, Windows, iOS 및 Android의 빌드를 지원합니다.
- macOS: v10.11 or higher
- Ubuntu: 64 bit, gcc compiler
- Windows: Vista or higher, Visual Studio 2019 compiler (64 bit)
- iOS: 10.0 and higher
- Android: Jelly Bean (4.1) and higher.
MSVC 설치(Windows Only)

윈도우 환경에서는 Visual Studio 2019 Compiler(64bit)로 컴파일을 수행합니다.
Desktop development whth C++를 선택하여 설치를 진행합니다.

QT 설치
1. Qt Installer를 다운로드 받습니다.
The Qt Company offering changes, open source offline installers are not available any more since Qt 5.15. Read more about offering changes in the https://www.qt.io/blog/qt-offering-changes-2020 blog. If you need offline installers, please consider our new Qt for Small Business offering: https://www.qt.io/blog/available-now-qt-for-small-businesses
1. QT를 설치합니다.
  $ ./qt-unified-linux-x64-4.6.0-online.run
  기본적으로 최신 버전만 선택할 수 있습니다.
  Archive를 체크 후 Filter 버튼을 클릭하여 이전 버전을 불러옵니다.
build

CLI에서 qmake를 사용하여 빌드

1) 다운로드한 레포짘토리 폴더로 이동
```
   $ cd qgroundcontrol
```
2) 빌드를 수행한 디렉토리를 생성하고 이동
```
   $ mkdir build
   $ cd build
```
3) qmake 스크립트를 사용하여 빌드 구성
```
   $ qmake ../
```
4) make를 실행하여 컴파일(-j{number of threads} )
```
   make -j12
```
Run
```
$ ./staging/QGroundControl
```
TroubleShooting

[Ubuntu 환경]
- QT 버전 변경
  $ vi /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf
  /opt/QT/5.15.2/gcc_64/bin
  /usr/lib/x86_64-linux-gnu
- Not found airmap
  ompiling /home/ubuntu/Documents/qgroundcontrol/src/QGCToolbox.cc In file included from /home/ubuntu/Documents/qgroundcontrol/src/Airmap/AirMapSharedState.h:17, from /home/ubuntu/Documents/qgroundcontrol/src/Airmap/AirMapManager.h:12, from /home/ubuntu/Documents/qgroundcontrol/src/QGCToolbox.cc:38: /home/ubuntu/Documents/qgroundcontrol/src/Airmap/services/client.h:4:10: fatal error: airmap/client.h: No such file or directory 4 | #include <airmap/client.h> | ^~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:260800: QGCToolbox.o] Error 1 07:52:49: The process "/usr/bin/make" exited with code 2. Error while building/deploying project qgroundcontrol (kit: Desktop Qt 5.15.2 GCC 64bit) When executing step "Make"
  This currently applies to Airmap on Linux, which is optional but enabled by default.
  
  airmap을 비활성화 합니다.
  $ echo -e "DEFINES += DISABLE_AIRMAP\r\n" | tee user_config.pri
Read All

UAM 용어 정리

2023-06-15

Aerospace

Term Acronyms

ATM / UAM / UTM 서비스를 위해 사용되는 용어를 정리하고 있습니다.
아직 미정립되거나 개념을 수립 중인 용어도 포함 되어 있습니다.

용어

Acronym	Definition	정의
AAM	Advanced Air Mobility	첨단 항공 모빌리티
AFR	Automated Flight Rule	자동 비행 규칙
ASM	Air Space Management	항공역 관리
ATC	Air Traffic Control	항공 교통 관제
ATS	Air Traffic Service	항공 교통 서비스
CA	Cooperative Ares	협동 구역
CEP	Corridor Entry/Exit Point	회랑 입출점
CFM	Cooperative Flow Management	협력 흐름 관리
CNS	Communication, Navigation, and Surveillance	통신, 안내, 감시
COP	Cooperative Operating Practice	협력 운영 관행
ConOps	Concept of Operations	운영의 개념
DCB	Demand-Capacity Balancing	수요-용량 균형
DEP	Distributed Electric Propulsion	분산 전기 추진
DOT	Department of Transportation	교통(부)과
EDCT	Expect Departure Clearance Time	예상 출발 허가 시간
ETM	Upper Class E Traffic Management	상부 등급E 교통관리
eVTOL	Electric Vertical Takeoff and Landing	전기추진 수직 이착륙기
FAA	Federal Aviation Administration	미연방항공청
FIS	Flight Information Service	항공 정보 서비스
IFR	Instrument Flight Rules	계기비행 규칙
IMC	Instrument Meteorological Conditions	계기비행 기상 조건
LOA	Letter of Agreement	합의서
NAS	National Airspace System	국가 공역 체계
NASA	National Aeronautics and Space Administration	미항공우주국
NOTAM	Notice to Air Missions	항공 임무 공지
PIC	Pilot in Command	조종사
PSU	Provider of Services for UAM	UAM 서비스 제공자
RPIC	Remote Pilot in Command	원격 조종사
SAA	Special Activity Airspace	특수 활동 공역
SDSP	Supplemental Data Service Provider	부가 데이터 서비스 제공자
TFM	Traffic Flow Management	교통 흐름 관리
TFR	Temporary Flight Restriction	임시 비행 제한
UAM	Urban Air Mobility	도심 항공 모빌리티
UAO	UAM Air Operator	UAM 이해 관계자
UATM	UAM Air Traffic Management	UAM 교통 관리
UAS	Unmanned Aircraft Systems	무인 항공기 시스템
USS	UAS Service Supplier	UAS 서비스 공급자
UTM	UAS Traffic Management	UAS 교통 관리
V2V	Vehicle-to-Vehicle	차량 to 차량
VFR	Visual Flight Rules	시계비행 규칙
VMC	Visual Meterological Conditions	시계비행 기상 조건
VPO	VertiPort Operator	버티포트 이해관계자
VTOL	Vertical Takeoff and Landing	수직이착률
xTM	Extensible Traffic Management	확장가능한 교통 관리

Read All

소프트웨어 공학 기본 #2

2023-05-25

SoftwareEngineering

Study Software
소프트웨어 개발방법론

(SDM; Software Development Methodology) :
소프트웨어를 개발하는 방법에 대한 이론으로서, 소프트웨어 개발 과정, 절차, 방법, 산출물, 기법, 도구들을 체계적으로 정리하고 표준화시킨 것입니다.

구조적 방법론

(Structured Development) :
전체 시스템을 정형화된 분석 절차에 따라 요구사항을 파악하여 문서화 하고, 이를 기반으로 소트프웨어를 개발하는 방법론 입니다.
- 요구 사항 분석 : 고객이 원하는 요구사항을 끌어내어 명세화합니다.
- 구조적 분석 : 고객이 원하는 기능과 시스템 환경, 데이터를 종합하여 DFD(Data Flow Diagram)을 작성하고, 이를 통해 기능을 분해하여 기능별 소단위 명세( mini-Specification)를 작성합니다.
- 구조적 설계 : 모듈 중심으로 소프트웨어를 설계합니다.
- 구조적 프로그래밍 : 설계를 기반으로 소프트웨어를 개발합니다.
“거시적 관점”이 부족하다는 한계가 있음

정보공학 개발 방법론

(Information Engineering Development) :
비즈니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론으로
기업 전체, 또는 기업의 주요 부분을 계획, 분석, 설계 및 구축에 정형화 된 기법들을 상호 연관성 있게 통합, 적용하는 데이터 중심 방법론 입니다.
- 정보 전략 계획(ISP) : 업무프로세스와 시스템을 분석하고 미래 아키텍처와 전략계획을 수립합니다.
- 업무 영역 분석(BAA) : 업무 현황을 분석하여 개념 수준의 데이터와 프로세스를 설계합니다.
- 업무 시스템 설계(BSD) : 실질적으로 시스템을 설계하는 단계로 다양한 다이어그램을 사용하여 프로세스를 설계합니다.
- 시스템 구축(SC) : 설계 명세서로부터 데이터베이스를 상세 설계하고 실행 가능한 프로그램 코드를 생성합니다.
“경직된 구조”로 이전 단계의 변화에 대응하기 어려움

객체 지향 개발 방법론

(Object-Oriented Development) : 현실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object) 로 표현하며,
이 객체들이 메시지 교환을 통해 상호 작용함으로써 전체 시스템이 운영되도록 개발하는 방법론입니다.
- 개념화 : 요구 사항을 분석하여 정의합니다.
- 상세화 : 문제 영역(Problem Domaion)을 분석하고 견고한 아키텍처 토대를 마련합니다.
- 구축 : 사용자들에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발합니다.
- 전이 : 소트프웨어를 사용자에게 전달합니다.
개발 수준이 저 수준의 추상화 개념이므로 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어려움

컴포넌트 기반 개발 방법론

(Component Based Development) :
컴포넌트를 조립하여 시스템을 개발 하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론입니다.
- 분석 : 사용자의 요구 사항을 수집하고 이를 정의합니다.
- 설계 : 소프트웨어의 아키텍처를 정의하고 이를 구성하는 콤포넌트와 데이터베이스 등을 설계합니다.
- 구현 : 개발 표준을 정의하고 이에 맞춰 코드를 구현합니다.
- 테스트 : 요구 사항이 모두 반영되었는지 테스트하고 이에 대한 결과를 보고합니다.
애자일 개발 방법론

(Agile Software Development) :
기존 개발 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 단점을 개선하기 나왔습니다.

미래를 예측하기 보다는 주기적으로 제작 프로토타입을 시험해보는 철저한 관리를 통한 개발 방법론이라 할 수 있으며
끊임없이 개발하고 수정하는 일을 반복하면서 고객이 가장 만족할 수 있는 방향으로 소프트웨어를 개발합니다.
1. 먼저 개발 범위 안에 있는 요구 사항을 분석해 우선 순위가 높은 요구 사항을 먼저 개발합니다.
2. 개발 된 부분에 대해 실행하는 모습을 고객에게 보여주고 이에 대한 피드백을 받습니다.
3. 고객의 요구 사항과 개선 사항을 반영하여 다음 요구 사항을 개발합니다.
4. 1-3을 반복합니다.
테스트 기반 개발 방법론

(Test Driven Development) :
전통적인 개발 방법론에서의 구현 후 테스트를 수행하는 단계와는 반대로 테스트를 먼저 수행하고, 소프트웨어를 구현하는 개발 방법론입니다.
1. 테스트 케이스 작성 : 요구 사항을 만족하기 위한 테스트 케이스를 작성합니다.
2. 실제 코드 구현 : 테스트 케이스를 통과하기 위한 최소한의 코드를 구현합니다.
3. 리팩토링 : 작성한 코드를 표준에 맞도록 리팩토링 합니다.
4. 모든 요구 사항을 만족하는 테스트 케이스를 통과 할 때까지 1-3을 반복합니다.
행위 기반 개발 방법론

(Behaviour Driven Development) :
TDD에서 파생된 개발 방법론으로, 사용자의 행위를 정의하고 이에 대한 테스트 코드를 작성하면서 소프트웨어를 개발하는 방법입니다.
Read All
소프트웨어 공학 기본 #1

2023-05-25

SoftwareEngineering

Study Software
소프트웨어 개발 수명 주기

(Software Development Life Cycle, SDLC)
시스템 엔지니어링, 정보 시스템, 또는 소프트웨어 공학에서 정보 시스템을 계획, 개발, 시험, 채용하는 과정을 뜻하는 용어입니다.
대게 요구사항 분석→설계→개발→테스트→운영 단계로 구성되어 있습니다.

요구 사항 분석
- 요구 사항을 수집하고 제품의 요구와 조건을 결정
- 소프트웨어의 기능과 제약 조건 등을 명확히 정의
설계
- 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정
- 시스템 구조 설계/ 프로그램 설계 / 사용자 인터페이스 설계 / 데이터베이스 설계 등
구현
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 구현
- 인터페이스 / 자료 구조 / 오류 및 예외 처리 등
테스트
- 시스템이 요구을 모두 만족하는지 검사하고 평가하는 단계
- 단위 테스트 / 통합 테스트 / 시스템 테스트 / 인수 테스트 등
유지 보수
- 시스템이 인수된 이 후 일어나는 모든 활동
소프트웨어 생명 주기 모델

폭포수 모델 (Waterfall Model)
- 가장 오래 된 모델
- 순차적으로 각 단계를 완료 후, 다음 단계로 넘어가는 모델
- 단계별 정의와 산출물이 명확하나, 요구 사항 변경이 어려움
프로토타이핑 모델 (Prototyping Model)
- 주요 기능을 프로토타입으로 구현하고, 이에 대한 고객의 피드백을 반영하여 소프트웨어를 개발
- 요구분석이 쉽고 타당성 검증이 가능하나 프로토타입 개발에 따른 비용 증가
나선형 모델(Spiral Model)
- 점진적으로 완벽한 시스템을 개발해 나가는 모델
- 위험성 감소와 변경에 유연한 대처가 가능하나, 단계 반복에 따른 추가 비용과 관리가 어려움
반복적 모델(Iteration Model)
- 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델
- 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델
- 병행 개발로 인한 일정 단축이 가능하나, 관리 비용이 증가
Read All

2/17

Welcome to gwimong's Blog!

Mapstruct로 DTO 변환 시 주의 사항

Mapstruct

주의 사항

생성자 이용 시

Builder 이용 시

plantuml로 Software Architecture 작성하기

PlantUML

C4 Model

C4-PlantUML

QGroundControl 개발 환경 구축하기

Source Code

Build QGC

Using Containers

Native Build

MSVC 설치(Windows Only)

QT 설치

build

Run

TroubleShooting

[Ubuntu 환경]

UAM 용어 정리

용어

소프트웨어 공학 기본 #2

소프트웨어 개발방법론

구조적 방법론

정보공학 개발 방법론

객체 지향 개발 방법론

컴포넌트 기반 개발 방법론

애자일 개발 방법론

테스트 기반 개발 방법론

행위 기반 개발 방법론

소프트웨어 공학 기본 #1

소프트웨어 개발 수명 주기

요구 사항 분석

설계

구현

테스트

유지 보수

소프트웨어 생명 주기 모델

폭포수 모델 (Waterfall Model)

프로토타이핑 모델 (Prototyping Model)

나선형 모델(Spiral Model)

반복적 모델(Iteration Model)