_NOTE

★ ★ ★ 1. UML ( Unified Modeling Language )의 구성요소 - 사물, 관계, 다이어그램 2. 사물 ( Things ) - 구조, 행동, 그룹, 주해 { 사물 } 3. 관계 ( Relationships ) ★ ★ - 연관 ( - ) , 집합( ◇ ), 포함 ( ◆ ) , 일반화 ( ㅡ▷ ), 의존 ( --> ), 실체화 ( -- ▷ ) { 관계 } 4. 구조적, 정적 다이어그램 - 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지 - 컴포넌트, 배치 다이어그램은 구현 단계에서 사용되는 다이어그램임. ★ 5. 행위, 동적 다이어그램 - 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍 ★ 1) UI 구분 ★ - C..

★ 1) 운영체제( OS : Operation System ) - 하드웨어가 아닌 소프트웨어 # Windows, UNIX, Linux, Mac OS, iOS, Android 등등 - 가용성, 성능 | 기술지원, 구축 비용, 주변기기 ( 고려사항 ) 2) 미들웨어 ( Middleware ) - 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어 3) 데이터베이스 관리 시스템 ( DBMS ) - 사용자와 데이터베이스 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어 - 데이터베이스의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐 - JDBC , ODBC - Oracle, MySQL, SQLite, MongoDB, Redis 등등 - 가용성, 성능 | 기술지..

1. 폭포수 모형 - 가장 오래되고 가장 폭넓게 사용된 고전적 생명 주기 모형 - 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형 - 단계별 정의 및 산출물이 명확 - 개발 중간에 요구사항의 변경이 용이하지 않음 - 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 테스트 -> 유지보수 2. 프로토 타입 모형 ( 원형모형 ) - 견본품을 만들어 최종 결과물을 예측하는 모형 - 인터페이스 중점을 두어 개발 - 개발 중간에 요구사항의 변경이 용이 3. 나선형 모형( 점진적 모형 )★ - 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형 - 점진적 개발 과정 반복으로 요구사항 추가 가능 - 정밀하고 유지보수 과정 필요 없음 - 계획 및 정의 -> 위험분석 -> 공학..

다음 내용이 설명하는 디자인 패턴은 ? - 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될것인지는 서브클래스가 결정하도록 하는 것 - Virtual-Constructor패턴이라고도 함 --> Factory Method 패턴 - Visitor 패턴 : 행위패턴 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성함. 분리왼 처리 기능은 각 클래스를 방문하여 수행 - Observer패턴 : 행위패턴 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달. 분산된 시스템 간에 이벤트 생성, 발행, 이를 수신해야할때 이용함 - Bridge패턴 : 구조패턴 구현부에서 추상층을 분리, 서로가 독립적으로 확장함 기능과 구현을 두 개의 별도 클래스..

검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토 회의를 통해 오류를 조기에 검출하는데 목적을 두는 오규사항 검토 방법 : 워크스루 - 동료검토 : 2~3명이 진행하는 리뷰형태로 작성자가 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태 - 워크스루 : 검토자료를 회의전에 배포하여 사전 검토한 후, 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 조기에 검출하는데 목적을 둔 검증기법 - 인스펙션 : 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함을 발견하는 형태 UML 모델에서 한 사물의 명세가 바뀌면 다른 사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계 : Depen..

미들웨어에 대한 설명으로 틀린것은 : 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있어야 한다. - 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어이다. - 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, PC 환경, 운영체제 환경 등에서 시스템 간의 표준화된 연결을 도와주는 소프트웨어이다. - 표준화된 인터페이스를 통하여 시스템 간의 데이터 교환에 있어 일관성을 제공한다. - 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어이다. --> 미들웨어 솔루션은 미들웨어의 서비스 이용을 위해 사용자가 정보 교환 방법 등의 내부 동작을 확인할 필요가 없다. 사용자가 미들웨어의 정보 교환 방법 등의 내부 동작을 쉽게 확인할 수 있다면..

클래스 설계 원칙에 대한 바른 설명 개방-폐쇄의 원칙 : 클래스는 확장에 대해 열려있어야 하며 변경에 대해 닫혀 있어야한다. - 단일 책임원칙 : 하나의 객체는 하나의 동작만의 책임을 가짐 하나의 클래스는 하나의 목적을 위해서 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중 - 개방-폐쇄의 원칙 : 클래스는 확장에 대해 열려 있어야 하며 변경에 대해 닫혀 있어야 한다 소프트웨어 구성요소 (컴포넌트, 클래스, 모듈, 함수)는 확장에 열려있고, 변경에는 닫혀 있다 - 리스코프 교체의 원칙 : 특정 메소드가 상위 타입을 인자로 사용할 때, 그 타입의 하위 타입도 문제 없이 작동해야 함 서브타입 ( 상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다..

소프트웨어 설계에서 사용되는 대표적인 추상화 기법이 아닌것은: 강도 추상화 - 소프트웨어 설계에 사용되는 대표적인 3가지 추상화 기법 - 제어 추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법 - 기능 추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법 - 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법 추상화 ( Abstraction ) - 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것. - 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법 - 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터..

유스케이스에 대한 설명중 옳은 것은 액터는 대상 시스템과 상호작용하는 사람이나 다른 시스템에 의한 역할이다 - 유스케이스는 시스템이 액터에게 제공해야 하는 기능 시스템의 요구사항이자 기능을 의미 유스케이스 다이어그램은 사용자의 요구를 추출하고 분석하기 위해 주요 사용 액터는 시스템 외부에서 시스템과 상호작용하는 사람 혹은 시스템 사용자 액터 : 기능을 오규하는 대상이나 시스템의 수행결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상으로 시스템이 제공해야하는 기능인 유스케이스의 권한을 가지는 대상, 역할 시스템액터 : 사용자 액터가 사용한 유스케이스를 처리해주는 외부 시스템, 시스템의 기능 수행으 ㄹ위해서 연동이 되는 또 다른 시스템 액터를 의미 DFD에 대한 설명으로 틀린것은 : 시간흐름을 명확하게 표..

소프트웨어 설계에 사용되는 대표적인 3가지 추상화 기법 - 제어 추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법 - 기능 추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법 - 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법 추상화(Abstraction) : 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는것 - 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법 - 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구ㅜ조를 대표할 수 있는 표현으로 대체하는 방법 GOF 디자인패턴에서 생성패턴에 해당하..