b354b study room

* UML 클래스 다이어그램 클래스 내부 구성요소 및 클래스 간의 관계를 도식화하여 시스템의 특정 모듈 or 일부 및 전체를 구조화한 구조 다이어그램 개발하기 전에 클래스 다이어그램을 그리면 시스템 내 클래스 간의 의존성 파악과 팀원들 간의 의사소통이 편리하다 Unified Modeling Language  * UML 클래스 다이어그램 단계  1. 개념  2. 명세  3. 구현  개념 단계 클래스만 도출하고 관계를 단순화하는 것이 목적  명세와 구현 단계 개발 직전 설계나 구현 이후 설명 목적으로 사용되고 이 다이어그램을 기반으로 코드로 구현하거나 코드를 기반으로 다어이그램을 그리기 때문에 코드와 연관이 깊다  * UML 클래스 다이어그램 요소  1. 클래스   2. 스트레오 타입  3. 추상 클래스  ..

* 디자인 패턴 1995년 Gof(Ganf of Four)라고 불리는 에릭 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스가 처음으로 구체화 및 체계화 수많은 디자인 패턴들 중 가장 일반적인 사례에 적용될 수 있는 패턴들을 분류하여 정리함으로써 지금까지도 소프트웨어 공학이나 현업에서 가장 많이 사용되는 디자인 패턴 디자인 패턴은 총 23개로 생성, 구조, 행위의 3가지로 분류한다  * 빌더 패턴 빌더 패턴은  구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴으로 기능과 구현을 두 개의 별도 클래스로 구현한다  * 싱글톤 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 수 없는 패턴 불필요한 메모리 낭비를 최소화 ㄱㄴ  * 방문자  ..

* 추상 팩토리  Abstract Factory 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공 추상 팩토리를 통해 생성된 클레스는 사용자에게 인터페이스를 제공하고 구체적인 구현은 concrete product 클래스에서 이루어짐 동일한 주제의 다른 팩토리를 묶음  * 빌더  Builder 복잡한 인스턴스를 조립해서 만드는 구조 복합 객체를 생성할 때 객체를 생성한 방법과 객체를 구현하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있음 생성과 표기를 분리해서 복잡한 객체를 생성  * 팩토리 메소드  Factory Method 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고 하위 클래스에서 인스턴스를 생성하는 방식 상위 ..

* 블랙박스 테스트 기능 테스트를 말하는 것 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법 테스트 케이스는 프로그램이나 모듈의 요구나 명세를 기초로 결정 제품에 대한 요구사항과 결과물이 일치하는지 확인 프로그램 내부 구조를 고려하지 x 코드를 몰라도 됨 입력과 출력을 알아야 함 가능한 모든 기능을 전부 테스트하는 것이 좋다 사용자의 요구사항 명세를 보면서 테스트하는 것 구현된 기능을 테스트 소프트웨어 인터페이스에서 실시된다  블랙박스 테스트의 종류  1. 동치 분할 검사  2. 경계값 분석  3. 원인-효과 그래프 검사  4. 오류 예측 검사  5. 비교 검사  동치 분할 검사  1. 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사  2. 동등 분할 기법이라..

* 소프트웨어 명세를 위해 필요한 4가지 모델 1. 구조 모델 2. 행위 모델 3. 아키텍처 모델 4. 데이터 모델 구조 모델 소프트웨어 시스템의 전체 구조를 설명 #26 소프트웨어 디자인은 소프트웨어의 구조, 동작, 아키텍처에 대한 설계이다 소프트웨어를 개발하기 위한 계획이나 규칙으로 프로그램이나 코드의 직접적인 실행물은 아니다 따라서 소프트웨어 디자인은 개발 과정에서 소프트웨어 제품을 설계하고 이해하기 위한 중요한 단계이다

#21 * 카디널리티 데이터 모델링에서 관계의 참여도를 나타내는 개념 1. 일대일 2. 일대다 3. 다대다 #22 * 시퀀스 다이어그램 Sequence Diagram 객체들 사이에서 시간에 따라 발생하는 상호작용을 보여주는 다이어그램 문제 해결에 필요한 객체를 정의하고 객체간의 송/수신 메시지의 순서를 시간의 흐름에 따라 표시하는 다이어그램 일반적으로 화면 요구사항과 클래스 다이어그램 기반으로 작성하고 시퀀스 다이어그램과 클래스 다이어그램을 크로스 체크 Guard 단일 메시지에 대해 조건을 명시할 수 있는 방법 메시지 앞 쪽에 대괄호 []로 감싼 후 조건을 명시 ex) [price > 10000] 배송비 무료로 처리 alt alternative 다중 조건문 다수의 조건 중 조건에 만족하는 단 하나만 실행..

* 디스패처 아키텍처 스타일 Dispatcher Architecture Style 분산 컴퓨팅에서 사용되는 미들웨어 아키텍처 서버 팜을 클라이언트에게 단일 서버처럼 보이도록 만든다 클라이언트 - 디스패처 - 서버 로 연결되어 있음 디스패처 노드 클라이언트의 초기 호출 시 고품질의 서버를 찾아서 선택된 서보의 정보를 클라이언트에게 제공 이후 클라이언트는 중간 에이전트 없이 직접 서버를 호출 브로커 아키텍처 스타일보다 성능이 b 고가용성, 안정성, 성능, 확장성을 위해 다수의 이중화 서버가 활용됨 디스패처 아키텍처의 필요성 1. 모든 요청을 처리하는 단일 서버는 높은 트래픽 양을 처리하기에 용량이 부족할 수 있다 2. 스케일업은 단기적인 해결책에 불과하다 저렴한 하드웨어와 운영체제를 기반으로 한 서버팜의 여..

* SOLID 함수와 데이터 구조를 클래스로 배치하는 방법 클래스들의 결합 방법을 설명 1. SRP 2. OCP 3. LSP 4. ISP 5. DIP SRP 단일 책임 원칙 Single Responsibility Principle 단일 모듈은 한 동작에 대해서만 책임져야 한다 OCP 개방 폐쇄 원칙 Open Closed Principle 개체의 확장 가능성은 열어두고 변경 가능성은 닫아두어야 한다 LSP 리스코프 치환 법칙 Liskov Substitution Principle 상속을 사용하기 위한 가이드 올바른 상속 관계의 특징을 정의하기 위한 가이드 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다 부모 클래스 타입의 자리에 자식 클래스를 넣어도 문제 없이 작동해야 한다 DIP 의존성 역전 원칙..

* 유스 케이스 다이어그램 Use Case Diagram 시스템과 사용자의 상호작용을 다이어그램으로 표현 사용자 관점에서 시스템의 서비스, 기능, 외부 요소를 보여줌 1. 시스템 2. 액터 3. 유스케이스 4. 관계 시스템 System 만들고자 하는 프로그램 액터 Actor 시스템 외부에서 시스템과 상호작용하는 시스템 or 사람 반드시 하나 이상의 유스케이스와 상호작용해야 한다 1. 사용자 역할 2. 외부 시스템 유스케이스 Usecase 사용자 입장에서 본 시스템의 기능 or 시스템의 요구사항 (액터에게 제공해야 하는 기능) 시스템 내에서의 일련의 작업을 수행하기 위한 행위들 관계 Relationship 액터와 유스케이스 사이의 의미 있는 관계 1. 연관 (1) 포함 (2) 확장 2. 의존 3. 일반화 ..

* 제품 백로그 product back log item 로드맵 및 그 요구 사항에서 파생된 개발 팀에서 수행할 우선 순위가 지정된 작업 목록 제품이 요구하는 기능과 우선순위 1. 누가 2. 어떤 문제를 겪고 있는가 3. 문제를 어떻게 해결할 수 있는가 4. 얻게 되거나 기대하는 결과 제품 소유자의 속도에 맞춰 백로그 작업을 하지 않으며 제품 사유자도 개발 팀에게 작업을 푸쉬하지 않는다 작업 수용량이 있으므로 개발 팀은 지속적으로 or 반복적으로 제품 백로그에서 작업을 가져온다 팀의 로드맵과 요구 사항으로 제품 백로그의 토대를 마련한다 백로그 그루밍 백로그에 대한 정기적인 검토 백로그가 커지면 제품 소유자는 백로그를 단기 및 장기적 항목으로 그룹화해야 한다 단 대략적으로, 막연하게 해야 한다 1. 장기 마..