Git

1. Git

• Git 이란 소스코드를 효과적으로 관리하기 위해 개발된 분산형 버전 관리 시스템이다.

2. Git 설치

• Git 공식 홈페이지에서(https://git-scm.com) 운영체제에 맞는 Git을 다운로드 후 설치한다.
• Git 설치 후 명령 프롬프트에서 아래의 명령어로 설치된 Git의 버전을 확인한다.

  git --version

• Sourcetree 공식 홈페이지에서(https://www.sourcetreeapp.com) 운영체제에 맞는 Sourcetree를 다운로드 후 설치한다.

3. Git의 주요 용어

3.1. 저장소(Repository)

• 저장소는 파일 / 폴더의 저장 공간으로 파일이 변경 이력 별로 구분되어 저장된다.
• 원격 서버에서 관리되며 여러 사람이 공유하기 위한 저장소를 원격 저장소(Remote Repository)라고 한다.
• 개인 PC에서 관리하는 저장소를 로컬 저장소(Local Repository)라고 한다.

3.2. Commit

• 로컬 저장소에 파일이나 폴더의 변경 사항을 기록하는 작업을 Commit이라고 한다.
• Git은 Commit을 시간 순으로 저장하며 이전 Commit 상태부터 현재 Commit 상태까지 만들어 보관한다.
• Commit 내용을 통해 변경 이력과 변경 내용을 확인할 수 있다.

3.3. Index(Stage Area)

• Commit 하기 위해 추가하는 파일들이 저장되는 공간을 Index라고 한다.
• 사용자 입장에서는 Commit 대기 상태란 뜻으로 Staging Area라고 부르기도 하다.

3.4. Branch

• 저장소 내에서 다른 작업에 영향을 받지 않는 독립된 단위의 저장소를 Branch라고 한다.
• 즉, Branch는 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이다.

3.5. Checkout

• 현재 Branch를 다른 Branch로 전환하는 것을 Checkout이라고 한다.

3.6. Merge

• 특정 브랜치의 작업 내용을 다른 브랜치에 병합하는 것을 Merge라고 한다.

3.7. Clone

• 원격 저장소의 내용을 로컬 저장소에 복제하는 것을 Clone이라고 한다.

3.8. Push

• 로컬 저장소에서 변경된 이력을 원격 저장소에 업로드하는 것을 Push라고 한다.

3.8. Pull

• 원격 저장소에서 최신 변경 이력을 다운로드하여 로컬 저장소에 적용하는 것을 Pull이라고 한다.

4. .gitignore 파일

• Git에서 관리하지 않는 파일들의 목록을 작성하는 파일을 .gitignore 파일이라고 한다.
• .gitignore 파일은 저장소 최상위에 저장되어야 정상적으로 동작한다.

  ### Java ###
  # Compiled class file
  *.class
  
  # Package Files #
  *.jar
  *.war
  *.nar
  *.ear
  *.zip
  *.tar.gz
  *.rar
  
  ### Windows ###
  # Windows thumbnail cache files
  Thumbs.db
  
  # Windows Installer files
  *.cab
  *.msi
  *.msix
  *.msm
  *.msp
  

소프트웨어 공학 개요

1. 소프트웨어란?

• 소프트웨어에서 소프트는 '부드럽다'라는 뜻으로 딱딱하고 변경하기 어렵다는 '하드'와 반대되는 개념이다.
• 소프트웨어란 입력된 자료를 처리하여 결과를 출력하는 프로그램과 프로그램의 개발, 운용, 보수에 필요한 자료 일체를 말한다.

2. 소프트웨어 공학

• 공학적 원리를 소프트웨어 개발에 적용하는 것이 소프트웨어 공학이다.
• 공학이란 과학과 수학을 기초로 하여 구조나 기계, 시스템 등을 생산하는 데 체계적인 방법을 적용하는 것을 말한다.

3. 소프트웨어 개발 작업

3.1. 요구 분석

• 무엇을 개발할지 결정하는 작업이다.

3.2. 설계

• 사용할 수 있는 기술을 이용하여 요구 사항을 어떻게 구현할 것인지 결정하는 작업이다.

3.3. 구현

• 설계한 내용을 구현하는 작업이다.

3.4. 테스트

• 프로그램을 구현한 후 기능이 원하는 대로 작동하는지 테스트하는 작업을 말한다.

3.5. 유지보수

• 개발된 소프트웨어를 완벽해질 때까지 계속 발전시켜나가는 작업을 말한다.

요구 분석

1. 개요

• 요구 분석은 무엇을 하는 시스템을 개발할지 결정하는 것이다.
• • e.g 운영체제, 언어, 성능, 조건 등을 포함

2. 도메인 분석

• 도메인 분석은 소프트웨어 엔지니어가 개발하려는 분야의 배경지식을 알아가는 과정이다.
• 도메인이란 말은 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술을 의미한다.
• 도메인 분석으로 얻을 수 있는 장점으로는 빠른 개발, 좋은 시스템, 확장 예견이 있다.

3. 요구 추출

• 문제를 이해하기 위해 정보를 수집하고 사용자에게 무엇이 필요한지 찾아내는 것을 요구 추출이라 한다.

3.1. 기능적 요구

• 기능적 요구는 시스템이 무엇을 하는지, 즉 사용자나 다른 시스템을 위해 제공하는 서비스가 무엇인지 기술한 것이다.
• • e.g. 입력, 출력, 시스템에서 데이터를 어떻게 저장 할 것인지, 어떤 알고리즘을 사용할 것인지

3.2. 비기능적 요구

• 비기능적 요구는 소프트웨어를 개발하는 동안 고수해야 할 제약 조건으로, 사용하는 하드웨어의 제약, 소프트웨어 품질의 특성에 대한 수준의 범위를 정해놓은 것이다.
• • e.g. 반응시간, 처리속도, 고장 없이 얼마만큼, 가용성, 유지보수 ..

4. 요구 문서화

• 문제와 현재의 상태를 파악하고 요구를 도출한 후 해결책을 제시하고 소프트웨어가 어떤 기능을 가져야 하는지 정확히 기술하는 단계를 요구 문서화 또는 명세화라 한다.

5. 요구 검토

• 도출한 요구 사항이 적절한지 검토하고, 수정이 필요하면 다시 요구 추출 단계로 돌아간다.
• 요구 사항을 검토할 때는 관련자들이 모두 참석한 가운데 리뷰 회의를 진행한다.

설계

1. 개요

• 소프트웨어의 구조 설계는 품질 좋은 소프트웨어 시스템을 개발하기 위한 중요한 단계이다.
• 만약 소프트웨어 구조가 잘 설계되지 않으면 구현, 테스트, 유지보수에 큰 어려움이 뒤따를 것이다.

2. 설계의 접근법

2.1. 하향식 설계

• 가장 높은 수준의 구조부터 시작하여 점차 낮은 수준의 구조로 내려오면서 각종 설계 이슈에 관한 의사 결정을 하는 방법이다.
• 소프트웨어 구조와 사용될 데이터베이스의 종류를 먼저 결정한 후 특정 데이터 아이템의 형태와 사용될 개별 알고리즘을 결정하는 것을 예로 들 수 있다.

2.2. 상향식 설계

• 재사용이 가능한 낮은 수준의 기능을 먼저 정한 다음, 높은 수준의 구조를 만들기 위해 이것들을 어떻게 배치할지 결정한다.

3. 설계의 종류

• 아키텍처 설계
• 클래스 설계
• 사용자 인터페이스 설계
• 데이터베이스 설계
• 알고리즘 설계
• 프로토콜 설계

4. 설계안 결정

4.1. 목표와 우선순위 결정

• 본격적인 설계를 시작하기 전에 여러 가지 품질 측면에 대해 목표와 우선순위를 수립해야 한다.
• 목표와 우선순위를 정할 때 고려할 품질은 메모리 효율성, CPU 효율성, 유지보수성, 이식성, 사용성이다.

4.2. 비용 효과 분석

• 설계할 때 고려해야 할 중요한 점은 비용을 줄이고 효과를 높이는 방법을 찾는 것이다.
• 새로운 기능이나 설계안에 대한 비용을 추정하기 위해 다음과 같은 요소를 고려한다.
  • 소프트웨어 엔지니어링 작업에 드는 추가 비용
  • 특정 개발 기술에 드는 추가 비용
  • 사용자 및 제품 지원 인력에 드는 추가 비용
  • 소프트웨어 엔지니어링 작업 시 절약 시간
  • 매출 향상이나 사용자의 금전적 이익

UML(Unified Modeling Language)

1. UML(Unified Modeling Language)

• UML은 소프트웨어를 시각적으로 모델링 하기 위해 사용한다.
• UML은 소프트웨어를 모델링 하는 표준 그래픽 언어로 심벌과 그림을 사용하여 나타낼 수 있다.

2 UML의 목적

• UML의 목적은 소프트웨어 개발에 도움을 주는 것이다.
• 개발 과정에 여러 가지 다이어그램으로 설계하면 구조가 좋아지고 개발자들 간의 의사 교환이 쉬어진다.

3. UML 다이어그램의 종류

3.1. 사용 사례 다이어그램

• 액터와 사용 사례를 통해 시스템의 기능을 모델링 하는 데 사용한다.
• 개발하려는 시스템의 기능적 요구 또는 업무 프로세스의 개관을 나타낸다.

3.2. 시퀀스 다이어그램

• 객체 사이의 메시지 교환을 시간의 흐름에 따라 나타낸 것이다.
• 즉, 사용 사례로 표시된 업무 프로세스에 대해 시스템 안의 존재하는 객체가 어떤 식으로 개입하여 상호작용하는지를 나타낸다.

3.3. 클래스 다이어그램

• 객체지향 시스템의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타낸다.
• 또한 도메인(문제 영역)의 개념과 그것들 사이의 관계를 표시한다.

3.4. 패키지 다이어그램

• 관련된 클래스를 패키지로 그루핑하여 복잡한 시스템을 조직화하는 데 사용한다.

3.5. 상태 다이어그램

• 외부 자극에 대한 시스템의 동적 상태 변화를 나타낸다.
• 외부 이벤트에 대해 민감하게 상태를 변화시키는 객체를 모델링 한다.

3.6. 액티비티 다이어그램

• 시스템의 내부 프로세스를 단계별 작업 흐름 형태로 모델링 한다.
• 시스템의 동적 특징을 나타낸다.

3.7. 배치 다이어그램

• 노드, 컴포넌트, 커넥터 등 시스템의 물리적 자원 배치를 나타낸다.

디자인 패턴

1. 개요

• 자주 반복되는 설계 유형을 디자인 패턴이라 한다.
• 디자인 패턴은 체계적으로 문서화하여 범용적으로 사용할 수 있도록 정리한 것이다.

2. 기본 패턴

2.1. 개념 실체 패턴(Abstraction Occurrence Pattern)

• 각 객체의 공통 정보를 공유할 때 사용한다.
• 실체는 공통된 정보를 가진 멤버들의 모임이고, 개념은 공유하는 정보를 담는 클래스이다.

2.2. 플레이어 역할 패턴 (Player Role Pattern)

• 하나의 클래스에 다양한 역할을 표현하고 싶을 때 사용한다.

2.3. 위임 패턴(Delegation Pattern)

• 다른 클래스가 가진 특정 오퍼레이션을 활용하여 책임을 위임하고 싶을 때 사용한다.

2.4. 계층 구조 패턴

• 계층 관계를 가진 객체들을 묶어 동일한 처리를 하고 싶을 때 사용한다.

3. 생성 패턴

3.1. 팩토리 패턴(Facto