java 입문반 1주차

(화요일)

- github 이슈 생성해서 jira랑 연동 실습하기(?)

- README.md 파일에서 md란...? markdown 파일이라는 뜻 (웹 페이지 글올릴 때 쓰임) 

Github Project에서 Board는 애자일 하게 만들 수 있도록 한다!! 요즘 제일 많이 사용

 

Todo : 이슈 진행 전 상태

In Progress : 담당자가 이슈를 확인하고 진행중인 상태

In Review : 검토를 요청/진행 중인 상태(중간에 검토 단계를 넣는게 요즘 근황)  

Done : 완료 및 종료된 상태

 

기본 세팅 완료!!

 

issue랑 project 연결

 

 

 

프로젝트 목표 : 정해진 비용과 기간내에서 어떻게 하면 품질을 높이면서 마무리할 수 있을건지...

 

- R&R : Role & Responsibility (pm이라면 프로젝트 관리를 위한 책임)

 

학생 / 학생 등록 / 학생 등록 수정 이처럼... 세분화하는 구조화하는 활동 WBS / Level 3~4 정도로 쪼개는것이 좋다 (2-3주 단위로 할 수 있는 분량)

 

- wbs 실습은 내일!!

 

- 위험과 이슈의 차이 : 위험(potential problem)은 아직 잠재적 문제로 아직 일어나지 않은 것이고 이슈는 일어난 문제로 실제로 일어날 이슈를 방지하기 위해 위험을 방지해야한다!

- 위험과 관련된용어 : 발생 가능성과 발생했을때의 심각도(위험도)를 곱한것이 위험도.. 높은것이 우선순위로 정해지고 이를 대비하기 위해 철저하게 계획을 세워야한다

 

 

 

(수요일)

- wbs 만들기 

 

학생 관리 시스템 WBS 만들기

 

 

 

베이스 라인 : 특정 시점에서 필요한 파일들을정확히 사용할 수 있게 해주는 작업..

 - 어떤 요구사항 명세서를 반영하는 소스코드인건지를 알기 애매하므로 어떤 산출물을 기준으로 개발한건지를 알기 위해 적어 놓은것이 baseline..

- 어떤 요구사항 명세서와 설계서를 기준으로 개발할건지를 확인하고 개발해야한다!

- 소프트웨어 형상 통제 : 형상통제위원회에서 변경 요청을 수용할 것인지 평가하고 협의하는 과정(CCB한테 통과 받아야 업데이트 가능)

 

 

요구사항 명세서(SW Requirement Specification) : 무엇을 개발할건지에 초점을 맞춘다! (어떤 기능을 제공할것인지, 어떤 품질로 / 어떻게는 설계서에 들어갑니다..)

- 시스템(SYSRS)

- 소프트웨어(SWRS)

- 하드웨어(HWRS)

 

기능 vs 비기능 

- 기능 :  찐 기능

- 비기능 : 품질, 성능, 제약사항

 

비기능 요구사항 예시

 

기능 요구사항 어떻게 분석하고 작성하는지... (도출, 분석, 명세, 확인...)

- 좋은 요구사항 명세서라면 요구사항 명세서를 가지고 테스트를 만들어서 다 잘 돌아가는지...(테스트가 가능하다면 요구사항이 굉장히 디테일 하다는것!! / 아니라면 요구사항 명세서 더 자세하게 해달라고 부탁하기!!)

- 추적성 : 우리의 소스코드가 어떤 설계서, 아키텍처 설계서, 요구사항 명세서를 만족시키기 위해 나왔는지 추적이 가능한지... / 우리의 요구사항은 언제든지 변경될 수 있기 때문에 어떤걸 수정해야할지 찾는데 시간이 오래걸림, 누락 가능하다

 

- 변경 용이성 : 다른것과 최대한 독립성을 띄우는것이 좋다(의존적이면 변경하기 힘듦) 

-  uml 그리기 실습은 내일..

 

 

<목요일)

- UML : 시스템 설계를 표현하는데 사용하는 통합된 모델링언어

 

MBD : MODEL BASED DEVELOPMENT / 모델링만 하면 자동으로 개발해줌... / 개발자는 없어져도... 설계자는 안 없어진다

 

USECASE DIAGRAM 구성요소

- user actor :  시스템의 외부에 있으면서 시스템과 상호작용하는 것들... 일반적으로 사용자 혹은 외부 시스템

- system actor : 해당 프로젝트의 개발 범위에는 속하지 않지만 데이터를주고받는 등 서로 연동되는 다른 시스템 
                          ex) 우리 시스템에 데이터를 주는 기상청 시스템   

- usecase : 시스템이 액터에게 제공해야 하는 기능의 집합 / 동사+명사 형식으로 작성(성적등록, 성적조회)

- relationship : 액터와 유스케이스 / 유스케이스와 유스케이스 사이의 연관 관계!!! (관계 종류.....)

 

 

# USECASE DIAGRAM 그리기

https://app.diagrams.net/

 

 

# 설계

- 관점 : HOW(어떻게)

- 특징 : 사용 환경을 반영해 구체적

- 상위 설계서, 상세 설계서 두가지로 나뉨

 

 

(금요일)

https://velog.io/@hongjunland/Clean-Architecture

클린 아키텍처 필독서...

 

# 설계!!!

 

## 추상화 : 상위 레벨에서 제품의 구현을 생각해봄!!

 

https://wealthymindset.tistory.com/entry/%EC%82%AC%EC%97%85%EC%B6%94%EC%A7%84-%ED%98%95%ED%83%9C%EC%9D%98-%EB%91%90%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95-%ED%83%91%EB%8B%A4%EC%9A%B4Top-down%ED%95%98%ED%96%A5%EC%8B%9D-%EB%B0%94%ED%85%80%EC%97%85Bottom-up%EC%83%81%ED%96%A5%EC%8B%9D-%EB%B0%A9%EC%8B%9D

Top-down(하향식)과 Bottom-up(상향식)의 차이..

 

comfile 과정 : .java 파일을 컴퓨터가 해석할 수 있도록 컴파일러를 거쳐서 .class 파일로 바꿔주는 과정

 

 

## 분할과 정복(Divide Conquer)

 

- Component : 소프트웨어를 구성하는 요소들의 집합 / 클 수도 작을 수도 어떻게 쪼개지는지는 때마다 다르다  

- Unit : 더이상 나눌 수 없는 atomic한 요소

 

분할과 정복의 의미...

- 하나로 하지 말고 여러 개로 쪼개고 하나하나 작은 단위부터 개발하고 합쳐서 상향식으로 개발해 나가라는 의미

- 모듈화랑 같은 의미(= unit과도 같음)

- 한 화면에 보기 좋은 50-80줄 사이로 함수를 작성하는 것이 좋음

 

 

## 모듈화(Modularity)

 

- 의미 : 소프트웨어 구조를 이루는 기본 단위

- 특징

• 독립적인 기능을 수행하는 단위
• 유일한 이름을 가짐
• 모듈에서 또 다른 모듈을 호출(call)할 수 있음 -> interaction의 한 종류 / interface : interaction을 하는데 손쉽게 하는 수단(화면) / 호출을 하는경우... 데이터를 요청하고 응답 받을  
• 다른 프로그램에서도 모듈을 호출할 수 있음

- 모듈의 크기 : 시스템의 규모, 유형, 특성에 따라 작음 / 작은 시스템이라면 모듈의 크기는 함수 / 큰 시스템이라면...

 

- 응집도는 강하게(모듈 구성 요소간에는 강하게) / 결합도는 약하게(의존성이 약해야한다)

- 결합도를 느슨하게 하라는 말이... 모든 관계가 안좋다는 말이 아니라 A,B가 서로 호출하여 에러의 무한루프를 돌지 말라는 소리  

- 결합도가 높을수록 복잡해짐 / 낮을수록 단순해지도 유지보수, 재사용성이 좋다

 

 

C언어 절차지향형 언어...

- 다른 언어들도 다 순서대로 코드가 실행되는데 왜 절차지향이라고 하는지 ???? 특히나 순서에 집중해서?? 함수를 어디서나 쓰려고 하면 전역변수로 선언해야 한다 / 유지보수 어려움

 

JAVA 객체지향 언어...

- 사람이 이해한것처럼 코드를 짜보자 해서 나온 언어

- interaction이 이루어지기 때문에 loose coupling, strong cohension을 꼭 하자

 

 

# 객체지향방법론의 특징

 

- 캡슐화 : 정보은닉의 개념이 포함된 개념 / 나의 정보를 감싸서 다른 사람들에게 정보를 숨기는 효과 

- 상속 : 다른클래스의 속성을 물러받아 내 것처럼 쓰는 것 

- 다형성 : 하나 이상의 형태를 갖는 것

• 오버로딩 : 같은 함수 이름이어도 매개변수의 개수나 타입이 다르면 중복 정의하여 사용 가능
• 오버라이딩 : 상속 관계에서 부모의 가져온 메소드를 자식 클래스가 재정의 하여 사용 가능
  • 오버라이딩은 부모 클래스의 메소드를 자식 클래스에서 동일한 이름과 매개변수로 재정의하여, 자식 클래스에서 메소드를 호출할 때 부모 클래스의 메소드가 아닌 자식 클래스의 메소드가 실행되도록 하는 것입니다. 오버라이딩은 메소드에서만 이루어집니다.
  • 쉐도잉은 자식 클래스에서 부모 클래스와 동일한 이름의 변수를 선언하여 부모 클래스의 변수를 덮어쓰는 것입니다. 이 경우 자식 클래스의 인스턴스는 부모 클래스의 변수 대신 자식 클래스의 변수를 참조하게 됩니다. 하지만 부모 클래스의 변수 자체가 변경되는 것은 아닙니다