동호다찌

1. 프로그램 실행 여부에 따른 테스트 정적 테스트 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트 워크 스루, 인스펙션, 코드 검사 동적 테스트 프로그램을 실행하여 오류를 찾는 테스트 화이트박스 테스트, 블랙박스 테스트 2. 테스트 기반에 따른 테스트 명세 기반 테스트 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 동등 분할, 경계값 분석(블랙박스 테스트) 구조 기반 테스트 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트 구문 기반, 결정 기반, 조건 기반(화이트박스 테스트) 경험 기반 테스트 테스터의 경험을 기반으로 수행하는 테스트 에러 추정, 체크 리스트, 탐색적 테스팅 3. 시각에 따른 테스트 검..

1. 애플리케이션 테스트의 개념 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차이다. 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인하고 소프트웨어가 기능을 정확히 수행하는지 검증한다. 테스트 실행 전 개발한 소프트웨어의 유형을 분류하고 특성을 정리해서 중점적으로 테스틑할 사항을 정리해야 한다. 2. 애플리케이션 테스트의 필요성 테스트를 통해 프로그램 실행 전에 오류를 발견하여 예방 반본적인 테스트로 신뢰도 향상 단순한 오류 발견뿐만 아닌 새로운 오류의 유입도 예방 최소한의 시간과 노력으로 많은 결함을 찾음 3. 애플리케이션 테스트의 기본 원리 잠재적인 결함을 줄일 수 있지만 결함이 없다고 증명할 수는 없다. 즉 완벽한 소프트웨어 테스팅은 불가능하다. 결함은 대부분 개발자의 특..

1.통합 개발 환경(IDE) 개발에 필요한 환경, 즉 편집기, 컴파일러, 디버거 등의 다양한 툴을 하나의 인터페이스로 통합하여 제공하는 것 통합 개발 환경 도구란 통합 개발 환경을 제공하는 소프트웨어이다. 코드의 자동 생성 및 컴파일 가능, 추가 기능 위한 도구를 다운로드 가능 코드를 실행 or 테스트 시 오류가 발생한 부분을 시각화 > 수정 용이 외부의 다양한 서비스와 연동하여 개발에 편의를 제공, 필요한 정보를 공유 가능 대표 도구 이클립스 비주얼 스튜디오 엑스 코드 안드로이드 스튜디오 IDEA 2. 빌드 도구 빌드는 소스 코드 파일들을 컴퓨터에서 실행할 수 있는 제품 SW로 변환하는 과정 or 결과물 빌드 도구란 빌드하는 데 필요한 전처리, 컴파일 등의 작업들을 수행하는 SW 대표 도구 Ant 아파..

1. 디자인 패턴 디자인 패턴(Design Pattern)은 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다. 디자인 패턴 유형 구분 유형 설명 목적 생성 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴 구조 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴 행위 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴 범위 클래스 클래스 간 관련성(상속 관계를 다루는 패턴) 객체 디자인 패턴 요약 ✅ 생성 Builder : 생산 단계를 캡슐화 하여 구축 공정을 동일하게 이용하도록 하는 패턴 Prototype : 복사하여 새 개체를 생성할 수 있도록 하는 패턴 Factory Meth..

1. 객체지향 분석의 개념 객체지향 분석은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 이와 연관된 속성과 연산, 그들 간의 관계등을 정의하여 모델링하는 작업이다. 소프트웨어를 개발하기 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어 분석한다. 클래스, 객체, 속성, 연산들을 표현해서 모형화할 수 있게 해준다. 클래스로부터 인스턴스화하고, 클래스를 식별하는 것이 객체지향 분석의 주요한 목적 2. 객체지향 분석의 방법론 ✅ Rumbaugh 방법 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법 ✅ Booch 방법 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의하는 방법 ✅ Jacobson 방법 Use Case를 강조하여 사용하는..

1. 객체지향의 개요 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 사용 구조적 기법의 문제점 유지보수 고려하지 않고 개발 공정에만 집중 개발이 시작된 이후 추가적인 요구사항에 대응하기 어려움 재사용이 어려워 이전에 개발한 소프트웨어와 유사한 소프트웨어를 다시 개발할 때도 시간과 인력이 동일하게 소모 소프트웨어의 재사용 및 확장 용이, 고품질의 소프트웨어를 빠르게 개발, 유지보수 쉬움 복잡한 구조를 단계적 ㆍ계층적으로 표현, 멀티미디어 데이터 및 병렬 처리 지원 2. 객체(Object) 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한)..

1. 아키텍처 패턴의 개요 아키텍처를 설계할 때 참조할 수 있는 전형적 해결 방식 or 예제를 의미 SW 시스템의 구조를 구성하기 위한 기본적 윤곽을 제시 서브시스템들과 그 역할이 정의되어 있음, 서브시스템 사이의 관계와 여러 규칙/지침 등이 포함되어 있음 =아키텍처 스타일 = 표준 아키텍처 장점 개발 시간 단축, 고품질 SW 생산 가능 검증된 구조로 개발 > 안정적 개발 가능 이해관계자들이 공통 아키텍처를 공유 > 의사소통 간편 시스템 구조 이해 쉬움 > 손쉽게 유지보수 가능 시스템 특성 개발 전 예측 가능해짐 2. 레이어 패턴 (Layers Pattern) 시스템을 계층으로 구분하여 구성하는 고전적 방법 중 하나 각각의 서브시스템들이 계층 구조를 이룸, 상위 계층 - 서비스 제공자 / 하위 계층 - ..

1. 소프트웨어 아키텍처의 설계 소프트웨어 아키텍처는 소프트웨어의 골격이 되는 기본 구조이자 소프트웨어 구성 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체 ex) 건축 설계와 비슷하다. 의뢰자의 요구사항에 맞추어 건물의 용도와 형태를 정하고, 땅을 어떻게 다질지, 골조는 어떻게 세울 것인지와 같이 대략적인 것을 정하는 과정 소프트웨어 개발 시 적용되는 원칙과 지침 이해관계자들의 의사소통 도구로 활용됨 좋은 품질을 유지하며 사용자의 비기능적 요구사항으로 나타난 제약을 반역하고,기능적 요구사항을 구현하는 방법을 찾는 해결 과정 기능적 요구사항 : 시스템이 갖춰야 할 필수적인 기능에 대한 요구 항목들 비기능적 요구사항 : 그 외의 품질이나 제약사항에 관한 것 애플리케이션의 분할 방법과 분할된 모듈에 ..

1. Use Case Diagram(유스케이스 다이어그램) 유스케이스 다이어그램은 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템이 개발된 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것이다. 외부 요소와 시스템 간의 상호작용 사용자의 요구사항을 분석하기 위한 도구 시스템의 범위를 파악 2.Class Diagram(클래스 다이어그램) 클래스 다이어그램은 구조 다이어그램으로 클래스 내부 구성요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈이나 일부 및 전체를 구조화 합니다. 개발 하기 전, 클래스 다이어그램을 그리게 되면 시스템 내 클래스 간의 의존성 파악과 팀원들 간 의사소통이 편리합니다. 3. Sequence Diagram(순서 다이어그램) 여러 대상 간..

1. UML(Unified Modeling Language) 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다. UML을 사용 시 6개의 구조 다이어그램, 7개의 행위 다이어그램 작성 가능 UML의 구성 요소 : 사물, 관계, 다이어그램 2. 사물 (Things) 사물은 모델을 구성하는 가장 중요한 기본요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상을 말한다. 사물에는 구조사물, 행동사물, 그룹사물, 주해사물이 있다. 3. 관계 (Relationships) 사물과 사물 사이의 연관성을 표현하는 것으로 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화관계 등이 있다. ..