SYSADMIN'S CELLAR

1. 단원 요약 개요 UML (Unified Markup Language) 1.0: OMG, 1997 UML 2.5: OMG, 2015 4+1 View Usecase View: 유스케이스 다이어그램 Logical View: 상호작용 다이어그램(시퀀스 다이어그램, 통신 다이어그램) Process View: 액티비티 다이어그램 Development View Physical View UML 2.5 다이어그램 유스케이스 다이어그램: 구조적, 행위적 측면을 모두 표현한다. 구조 다이어그램 클래스 다이어그램 객체 다이어그램 패키지 다이어그램 컴포넌트 다이어그램 배포 다이어그램 행위 다이어그램 액티비티 다이어그램 상태머신 다이어그램 상호작용 다이어그램 시퀀스 다이어그램 통신 다이어그램 액터: 막대인간, 아이콘, 스테..

1. 단원 요약 개요 "객체지향 분석과 설계"는 제6장 사용자 요구 분석(요구공학) 단원의 "요구사항 모델링"에 관한 설명 중 "객체지향 분석 모델"을 기초로 수행된다. 객체지향 분석: 문제 도메인을 분석하여 개념 모델을 작성하는 과정 객체지향 분석의 결과물은 시스템이 수행하는 기능을 설명하는 모델이다. 유스케이스, 클래스, 상호작용 다이어그램 객체지향 설계: 객체지향 분석 단계의 결과물을 비기능적 요구사항과 아키텍처를 고려하여 변환하는 과정 = 개념 클래스들을 구현 클래스들로 변환하는 과정 요구사항 추출 요구 공학: 요구사항 추출을 위한 활동 액터 찾기 시스템과 상호작용하는 사람, 외부 시스템을 찾는다. 유스케이스를 시작시키거나 그로부터 정보를 제공받는 액터를 "참여 액터"라고 부른다. 시나리오 찾기 ..

1. 단원 요약 코딩 코딩 스타일: 가독성과 유지보수성을 높이기 위한 소스코드 작성 지침이나 관행 내부 문서화: 소스코드 내에서 주석을 통해 코드에 대한 설명을 작성하는 행위 코드 스멜: 잠재적으로 문제가 발생할 소지가 있는 소스코드의 일부분 리팩토링: 기능 수정 없이, 구조를 개선하여 가독성과 유지보수성을 높이는 행위 소프트웨어 유지보수 제품 변경 전략 아키텍처 수정 없이 변경 아키텍처 수정 유지보수성 향상을 위한 재공학 유지보수 유형 수정 유지보수: 오류 수정 적응 유지보수: 외부 환경 변화에 대응하기 위한 수정 완전 유지보수: 기능, 성능 개선을 위한 수정 *가장 자주 일어난다. 예방 유지보수: 이해성, 유지보수성 개선을 위한 수정 소프트웨어 유지보수: 형상관리 형상: 시스템을 구성하는 요소들과 그..

1. 단원 요약 설계 프로세스 입력: 요구사항 명세서, 요구사항 분석모델, 환경적 제약 조건 출력: SW 아키텍처, 인터페이스, 알고리즘, 데이터 형식 정의 설계 프로세스는 반복적이다. 설계 행위 아키텍처 설계: 시스템의 논리적 구성도로써, 비기능적 요구사항에 큰 영향 데이터베이스 설계 서브시스템 설계 컴포넌트 설계 자료구조/알고리즘 설계 설계 원리 문제분할(분할정복) 수평 분할: 기능별로 모듈 그룹화(전체 제어가 복잡해지나 파급 효과가 작고 테스트, 유지보수, 확장이 용이하다.) 수직 분할: 상위 모델은 제어, 하위 모델은 실제 작업을 수행(제어는 단순하나 파급 효과가 크다.) 추상화 기능 추상화: 데이터 추상화: 하향식 설계/상향식 설계 하향식 설계: 상향식 설계: 아키텍처 설계 아키텍처 스타일: 유..

1. 단원 정리 요구사항(requirements): 목적 달성을 위해 시스템이 갖추어야 할 조건이나 능력 기능적 요구사항: 사용 시나리오, 데이터 형식 등 비기능적 요구사항: 성능, 보안 등 FURPS+: HP에서 개발한 요구사항 분류 모델 기능적: Functionality 비기능적: Usability, Reliability, Performance, Supportability ➡️ 품질 조건 Plus(+)는 비기능적 요구사항 중 제약 조건을 의미함 요구 공학 프로세스: 시스템 요구사항 명세서(SRS)를 만들기 위한 반복적 프로세스 고객이 작성한 문제 기술서를 바탕으로 SRS를 산출한다. 타당성 조사➡️요구사항 수집/분석(추출)➡️문서화➡️검토➡️관리 절차로 진행된다. 위 절차 중에서 요구사항 수집/분석(..

1. 단원 요약 소프트웨어 테스트: 결함을 찾기 위한 목적으로 프로그램을 실행하는 것으로, 품질보증 활동이다. 결함 테스트: 코드를 확인(verify)하여 결함을 찾는 것 검증 테스트: 시스템을 검증(validate)하는 것 SW 테스트 원칙 테스트 케이스 구성 요소: 입력, 예상결과, 실행조건, 절차, 목적 자가 테스트 금지 테스트 후반부에서도 소홀히 하지 말 것 모든 경우를 고려할 것 테스트 케이스를 재사용할 것 오류가 발견된 곳에서 추가 오류가 존재할 가능성이 높다. 테스트 작업 절차 Test Case 설계➡️Test Data 준비➡️Test 실행➡️결과 비교➡️보고서 작성 테스트 작업 우선순위 개별 모듈 테스트 < 전체 시스템 테스트 새 기능 테스트 < 오래된 기능 테스트 예외적 상황 테스트 < ..

1. 단원 요약 SW 품질 생산자 시각: 요구사항 만족, 개발 표준 준수 여부 고객 시각: 사용 목적과 기대에 부합하는지 여부 SW 품질의 분류 관점에 따른 분류: 사용자 관점, 개발자 관점, 프로젝트 관리자 관점 외부/내부 특성 외부 특성: 사용자 관점에서 신뢰성/사용성 등 실행되는 코드의 행위를 측정한다. 내부 특성: 개발자 관점에서 문서/코드에 대한 정적 평가를 수행한다. 제품/프로세스 특성 제품 특성: SW 제품 자체에 대한 품질을 평가한다. 프로세스 특성: SW 프로세스에 대한 품질을 평가한다. (일정, 비용, 위험관리 등) SW 제품 품질 표준: ISO/IEC 9126, 14598, 25000 ISO/IEC 9126: 6가지 품질 특성과 그 부특성들을 정의 기능성: 적합성, 정확성, 상호운영성..

1. 단원 요약 프로젝트 관리 개요 프로젝트 계획, 요구사항 준수 확인, 일정/예산 등의 감독 프로젝트 계획 비용과 일정을 결정 발생 가능한 위험을 분석하고 대안을 모색 브룩스의 법칙: 지체된 프로젝트에 인력을 추가하면 일정이 더욱 지체된다. 소프트웨어 프로젝트 관리의 문제점 실체가 없으므로 문서에 의존 개발 프로세스에 관한 표준이 없음 기술 발전으로 인해 과거 경험 활용이 어려움 SW 일정 계획 작업 분할: 전체 작업을 관리/측정이 용이한 소작업으로 분할, WBS로 표현 작업 명세화: 각 소작업의 산출물, 투입 자원(Person/Month)을 결정 작업 진행순서 정의: 소작업 간 선행 관계 분석, 개발순서 결정(PERT 그래프) 인력 배정: 각 소작업에 적합한 개발자 투입 작업비용 산정: 작업의 양, ..

1. 단원 요약 소프트웨어 프로세스란 소프트웨어 개발 절차를 말한다. 폭포수 모델(waterfall model): 고전적 SDLC, 선형 순차 모델 타당성 조사 단계 타당서 조사 보고서 사업 개요, 기술/경제적 타당성, 기대 효과, 비용, 인도일 등 요구 분석 및 명세 단계 무엇을 개발할 것인가? 정확·일관·완전한 요구사항명세서(SRS) 작성 설계 및 명세 단계 what ➡️ how 설계 단계의 구분 시스템 아키텍처 설계 인터페이스 설계 프로그램 설계 설계 방법의 구분 전통적인 구조적 분석/설계 객체지향 분석/설계 코딩 및 단위 테스트 단계 설계를 바탕으로 프로그램 작성 테스트 계획, 방법, 수준 결정 코드 인스펙션 수행 통합 및 시스템 테스트 단계 알파 테스트: SW 개발 현장에서 수행 베타 테스트: ..

1. 단원 요약 스트림은 순서가 있는 일련의 데이터가 이동하는 통로이다. 스트림을 이용하면 데이터나 목적지의 특성에 대해 독립적으로 프로그래밍이 가능하다. 스트림의 끝에는 파일, 주변기기, 소켓, 배열, 프로세스 등이 위치할 수 있다. 스트림을 통해 바이트, 문자, 객체가 이동할 수 있다. java.io에는 바이트 단위, 그리고 2바이트 단위로 처리가 가능한 스트림이 존재한다. Byte 단위 처리 최상위 추상클래스: InputStream, OutputStream 파일 입출력용 서브클래스: FileInputStream, FileOutputStream 2Bytes 단위 처리 최상위 추상클래스: Reader, Writer 파일 입출력용 서브클래스: FileReader, FileWriter 보조 스트림 클래스는..