[gitHub+ERD+소프트웨어 관리] 20230907

gitHub

gitHub 삭제할 gitHub를 클릭하여 Settings에 들어간다.

맨 아래로 내려가면 Danger Zone이 존재하며 Deletethis repository를 클릭한다.

중간에 나오는 코드를 복사하고 아래 버튼을 클릭한다.

삭제하려면 위에서 복사한 코드를 붙여 Delete 버튼을 클릭한다.

삭제 완료

내 pc에서도 git 폴더를 삭제한다.

gitHub 생성 gitHub 사이트에서 Create repository를 클릭한다.

저장소의 이름을 지정하고 설명을 덧붙인 다음 create repository를 클릭한다.

만들어진 gitHub의 주소를 복사한다.

다시 이클립스로 돌아와 프로젝트를 우클릭하고 team-share Project를 클릭하여 프로젝트를 공유할 준비를 한다.

프로젝트를 공유할 준비를 하고 나면 다시 Team-commit을 클릭한다.

기존의 모든 소스를 +버튼을 클릭하여 아래로 이동하고 message를 작성한 후 commit 한다.

이클립스로 git를 열다

romote에서 Create Remote를 수행한다.change를 클릭하고 URI에 hub에서 복사한 url 주소를 붙인다.gitHub에서 가입한 user와 token을 입력하고 완료를 클릭한다.Advanced 클릭 후 All Branches 클릭정상적으로 finish 되는 것을 확인할 수 있다.그런 다음 Save and Push를 클릭한다.push를 하려면 아이디와 비밀번호를 입력해야 하는데 비밀번호는 토큰을 입력했다(이전 토큰이 만료되어서 새로 발급받았으면 좋았을걸!)※ Token 발행방법 gitHun에서 패스워드는 Token을 사용한다고 한다.gitHub에서 가져오기깃허브 협업[master만]팀원의 gitHub ID(즉 이메일 주소)를 받아 입력한다.[팀원만 해당]이메일 주소로 온 팀장 협업 승인 메일을 클릭하여 협업 승인을 완료한다.팀장의 파일을 임포트 한다.이때 URI는 팀장 깃허브 URI를 붙인다.팀장의 소스 파일을 저장할 폴더 이름을 지정한다.성공리에 성공ERD (Entity Relationship Diagram) : 객체-관계도eXERDEXERD에서 테이블을 생성하고 컬럼명 지정 마스터 테이블: 회사에서 기준 테이블 트랜잭션 테이블: 매일 신규 입력 또는 삭제되는 테이블[논리 모드][물리 모드]RDB 비식별관계(sabun) 부모 테이블의 기본키 또는 유니크키를 자신의 기본키로 사용하지 않고 외래키로 사용하는 관계자식 데이터는 부모 데이터 없이도 독립적으로 생성할 수 있다.부모와의 의존성을 줄일 수 있어 보다 자유로운 데이터 생성 및 수정 가능식별관계(custcode, order_date) 부모 테이블의 기본키 또는 유니크키를 자신의 기본키로 사용하는 관계 부모 테이블의 키가 자신의 기본키에 포함되므로 반드시 부모 테이블에 데이터가 존재해야 자녀 테이블에 데이터를 입력할 수 있다.부모의 데이터가 없으면 아이의 데이터는 태어나지 않는다.포워드 엔지니어링이름 앞 스키마 표시는 해제하고 확인자바빈은 예전에 접속해놔서 자동으로 세팅되어있어! 연결테스트만 진행하고 완료버튼 클릭오라클에 테이블이 생성되었음을 확인할 수 있다.리버스 엔지니어링 기존에 만들어진 오라클 테이블→ERD로 가져온다.오라클에 있던 테이블이 ERD에 들어온 것을 확인할 수 있다.소프트웨어 관리프로젝트관리컴포넌트통합일정원가범위->BaseLine품질->ISO9126 (기능,신뢰,이식성,사용성,효율성)인적->내부/외주커뮤니케이션->내부커뮤니케이션,개발->현업커뮤니케이션 이해관계조달위험->수용,회피,전가,완료소스코드커버리지종류 의미 특징구문 커버리지(Statement)프로그램 내의 모든 명령문이 최소한 한번은 실행하는 테스트 케이스 가장 약한 형태의 보상 결정 커버리지(Decision)프로그램 내의 모든 결정문이 적어도 한번은 참과 거짓의 결과를 실행하는 테스트 케이스 Branch보상 같은 이미 구문 커버리지 만족 조건 커버리지(Condition)결정 명령 내의 각 조건이 적어도 한번은 참과 거짓이 되게 하는 테스트 케이스 결정 보상보다 강한 조건/결정 커버리지(Condition/Decision)전체 조건식뿐 아니라 개별 조건식도 진정으로 한번거짓 한번 결과가 되게 하는 테스트 케이스 결정 및 조건 커버리지 향상 변경 조건/결정 커버리지(Modified/Dicition)각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에서 독립적으로 영향을 주도록 하는 테스트 케이스 조건/결정 커버리지 문제점 해결 논리식의 문제점 발생 시 해결종류 의미 특징 구문 커버리지(Statement) 프로그램 내의 모든 명령문이 적어도 한 번은 실행하는 테스트 케이스 결정 커버리지보다 강한 형태의 커버리지 결정 커버리지(Decision) 프로그램 내의 모든 결정문이 적어도 한 번은 참과 거짓 결과를 실행하는 테스트 케이스 Branch 커버리지와 같은 이미 구문 커버리지 만족 조건 커버리지(Condition) 결정 명령어 내의 각 조건이 적어도 한 번은 참과 거짓이 되도록 수행하는 테스트 케이스 결정 커버리지보다 강한 조건/결정 커패시턴스(Condition/Decision) 전체 조건식뿐만 아니라 개별 조건식도 진정으로 한 번, 거짓된 한번 결과가 되도록 수행하는 테스트 케이스 결정 및 조건 커버리지 향상 변경 조건/결정 커버리지(Modified/Dicition) 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식으로부터 독립적으로 영향을 주도록 하는 테스트 케이스 조건/결정 커버리지의 문제점 해결 논리식 문제점 발생시 해결소스 커버리지 설명구분 상세 SC(Statement Coverage)4개의 테스트 케이스 중 모두 가능 CC(Condition Coverage)Condition A의 결과인 1,0그리고 Condition B의 결과인 1,0이 적어도 1번은 테스트 케이스이며, 선택 예제에서 다른 테스트 사례가 더 존재한다.DC(Decision Coverage)Decision의 결과인 1과 0이 각각 최소한 1번은 테스트 케이스로 선택 예에서 다른 테스트 사례가 더 존재하는 C/DC(Condition/Decision Coverage)각각의 개별 Condition의 결과 값이 0,1으로도 최소 1번은 테스트 케이스로 선택 MC/DC(Modifed Coverage/Decision Coverage)각각의 개별 조건식 A, B가 전체 조건 식의 결과로부터 독립하기 때문에 A, B가(1,0),(0,(0,1,0,1,0,0,1), 개수는 2^n(이때 n은 Condition개수)개의 테스트 케이스글로만 읽었을 때는 이해가 잘 안 돼.<CC> 개별 조건식인 A, B가 적어도 한 번은 1과 0의 결과가 나와야 한다.<DC> 전체 조건식인 AorB의 결과가 적어도 한 번은 0, 1이 나와야 한다.<C/DC> 개별 조건식인 A, B가 적어도 한 번씩 0, 1이 나와야 하며, 전체 조건식도 적어도 한 번은 0, 1이 나와야 한다.<MC/DC> C/DC 커버리지를 만족하고 전체 조건식 결과가 독립적이어야 한다.개별 조건식인 A, B의 결과가 변화했을 때 전체 조건식에 영향을 준다고 테스트를 실시<CC> 개별 조건식인 A, B가 적어도 한 번은 1과 0의 결과가 나와야 한다.<DC> 전체 조건식인 AorB의 결과가 적어도 한 번은 0, 1이 나와야 한다.<C/DC> 개별 조건식인 A, B가 적어도 한 번씩 0, 1이 나와야 하며, 전체 조건식도 적어도 한 번은 0, 1이 나와야 한다.<MC/DC> C/DC 커버리지를 만족하고 전체 조건식 결과가 독립적이어야 한다.개별 조건식인 A, B의 결과가 변화했을 때 전체 조건식에 영향을 준다고 테스트를 실시<MCC> 모든 테스트 케이스 선택