정보시스템감리사 시험공부 정리노트 with Gemini
UML(Unified Modeling Language)에서 스테레오 타입(Stereotype)은 기존의 UML 요소(클래스, 연관 관계 등)의 의미를 구체화하거나 확장할 때 사용하는 메커니즘으로, 주로 길러멧기호(« ») 안에 표기합니다. 클래스 다이어그램의 관계(Relationship), 특히 의존(Dependency)이나 추상화(Abstraction) 관계에서 자주 사용되는 표준 스테레오 타입들을 기능별로 분류하여 빠짐없이 정리해보도록 하겠습니다. 1. 인스턴스 생성 및 소멸 (Creation & Destruction)한 클래스가 다른 클래스의 인스턴스를 생성하거나 없앨 때 사용합니다.스테레오 타입적용 관계설명«create»의존 (Dependency)클라이언트 클래스가 공급자(Target) 클래스의 ..
1. 클래스 형태 표기 (Stereo)가장 표준적인 방식으로, 일반 클래스 상자에 스테레오타입인 «interface»를 표기합니다. 구성 : 상단에 «interface» 키워드와 인터페이스 이름을 작성하고, 아래 칸에 추상 메서드(오퍼레이션) 목록을 나열합니다.구현 연결 : 클래스가 이 인터페이스를 구현할 때는 점선 화살표(빈 삼각형 머리)인 '인터페이스 실현(Realization)' 선으로 연결합니다. 2. 롤리팝 표기법 (Lollipop/Socket)인터페이스를 간결하게 표현할 때 사용하는 아이콘 방식입니다.제공 인터페이스(Provided Interface) : 클래스 끝에 붙은 작은 원(공) 모양으로 표현하며, 해당 클래스가 인터페이스를 구현하고 서비스를 제공함을 의미합니다. (공을 줄께..)요구 ..
ISO/IEC 25023은 소프트웨어 품질 평가 표준인 SQuaRE(System and Software Quality Requirements and Evaluation) 시리즈 중 하나로, 소프트웨어 제품의 품질 측정(Measurement)을 위한 구체적인 지표를 정의한 표준입니다.구분표준 번호부문명 (Division)주요 내용 및 역할2500nISO 2500x품질 관리 (Quality Management)SQuaRE 시리즈 전반에 대한 지침, 용어 정의 및 관리 모델을 제시합니다.2501nISO 2501x품질 모델 (Quality Model)소프트웨어의 8대 품질 특성과 사용성 품질 모델 등 평가의 기준이 되는 모델을 정의합니다. (예: ISO 25010)2502nISO 2502x품질 측정 (Quali..
필립 크루첸(Philippe Kruchten)이 1995년에 제안한 이 모델은, 복잡한 소프트웨어 아키텍처를 단 하나의 관점이 아닌 '서로 다른 4개의 관점'과 이들을 검증하고 연결하는'1개의 핵심 관점(유스케이스)'으로 설명하는 프레임워크입니다.1. 4+1 뷰 모델의 상세 구조아키텍처 문서는 이해관계자(Stakeholder)마다 보고 싶어 하는 정보가 다르므로 이를 만족시키기 위해 뷰를 분리한 것 논리 뷰 (Logical View)핵심 : 시스템이 사용자에게 어떤 기능(Functional Requirements)을 제공하는가?관점 : 최종 사용자(End-User)의 관점내용 : 시스템의 기능적 요구사항을 클래스, 객체, 관계 등으로 추상화하여 표현설계 : 클래스 다이어그램, 시퀀스 다이어그램 등을 주..
관점지향 프로그래밍(Aspect-Oriented Programming, AOP)은 객체지향 프로그래밍(OOP)을 보완하여 소프트웨어의 복잡도를 낮추기 위해 등장한 패러다임.1. 등장 배경: OOP의 한계객체지향 프로그래밍(OOP)은 모듈화를 통해 재사용성을 높였지만, 특정 기능들이 여러 클래스에 걸쳐 중복되는 문제를 완전히 해결하지 못함.코드 중복 (Code Duplication) : 로깅(Logging), 보안(Security), 트랜잭션(Transaction) 처리와 같은 기능은 거의 모든 비즈니스 로직에 공통적으로 필요합니다. 이를 각 객체마다 작성하면 코드가 중복됩니다.흩어진 관심사 (Scattered Concerns) : 공통 기능이 여러 모듈에 흩어져 있어, 코드를 수정할 때 해당 기능이 포함..
1. 인터페이스와 클래스 간의 상속 규칙자바에서 키워드를 구분하는 기준은 '구현(Implementation)의 의무가 있는가'입니다.구분키워드설명클래스 → 클래스extends부모의 기능을 물려받아 확장함.인터페이스 → 인터페이스extends규격과 규격을 합쳐 더 큰 규격을 만듦.클래스 → 인터페이스implements인터페이스에 정의된 추상 메서드를 직접 구현함.인터페이스 → 클래스불가능인터페이스는 클래스를 상속(extends)할 수 없음왜 인터페이스가 인터페이스를 상속할 땐 extends인가요?인터페이스 간의 상속은 부모 인터페이스의 기능을 자식 인터페이스가 그대로 '확장'하는 개념이기 때문입니다. 자식 인터페이스 역시 추상적인 상태이므로, 메서드 몸통(Body)을 구현할 의무가 없습니다. 그래서 ext..
ISO/IEC/IEEE 29119-4 테스트 설계 기법 요약 정리1. 명세 기반 기법 (Clause 5.2) - 입력 및 출력의 명세 기반조항기법명특징계산 및 설계 방법5.2.1동등 분할데이터를 동일 결과가 예상되는 영역으로 분할유효/무효 영역당 최소 1개 값 선정5.2.2분류 트리 기법테스트 요소를 트리 구조로 시각화하여 조합트리의 잎(Leaf) 노드 조합으로 케이스 생성5.2.3경계값 분석영역의 경계에서 발생하는 오류 집중 공략2-point(경계, 외부) 또는 3-point($n-1, n, n+1$)5.2.4구문 규칙 테스팅입력 값의 형식(문법) 규칙을 검증올바른 문법과 잘못된 문법 케이스 설계5.2.5.3모든 조합 기법모든 변수의 가능한 모든 값을 결합모든 값의 개수를 곱함 ($\prod V_i$)..
Lehman의 소프트웨어 진화의 법칙(Lehman's Laws of Software Evolution)은 소프트웨어 공학의 선구자인 메이어 리만(Meir M. Lehman)과 라즐로 벨라디(Laszlo Belady)가 1974년부터 제안한 이론입니다. 이 법칙의 핵심은 "소프트웨어는 완성된 후에도 계속해서 변화하고 진화해야 하며, 그렇지 않으면 도태된다"는 것입니다. 8가지 주요 법칙 (The 8 Laws)에 대해 정리하여 드립니다.1. 계속적인 변경의 법칙 (Law of Continuing Change)핵심: 시스템은 현실 세계의 변화에 맞춰 끊임없이 변경되어야 합니다.이유: 사용자의 요구사항과 운영 환경은 멈춰있지 않고 계속 변하기 때문입니다.결과: 변경되지 않는 시스템은 유용성이 점차 떨어져 결국 ..
1. 오버로딩 (Overloading): 과적하기"같은 이름의 함수를 여러 개 만드는 것"입니다. 트럭에 짐을 많이 싣는(Overload) 것처럼, 하나의 이름에 여러 기능을 껴 넣는다고 생각하세요.핵심 : 이름은 같지만, 매개변수(개수나 타입)가 달라야 함.비유 : 식당의 '주문하기' 기능. 주문하기라는 함수(메서드)는 같지만 매개변수인 메뉴명, 수량, 옵션이 다름.주문하기(메뉴명) -> "김치찌개 하나요!"주문하기(메뉴명, 수량) -> "김치찌개 세 개요!"주문하기(메뉴명, 옵션) -> "김치찌개 맵게 하나요!"목적 : 같은 성격의 기능을 이름 하나로 편하게 쓰기 위해 사용합니다.2. 오버라이딩 (Overriding): 덮어쓰기"부모에게 물려받은 기능을 내 식으로 재정의하는 것"입니다. 기존의 것을 ..
추상 클래스나 객체라는 개념, 처음 접하면 "붕어빵 틀이 있는데 왜 붕어빵을 못 만든다는 거지?" 싶어서 충분히 헷갈릴 수 있어요. 아주 핵심만 짚어서 쉽게 설명해 드릴게요!1. '객체(Object)'란 무엇인가?컴퓨터 프로그래밍에서 객체는 "실제로 메모리에 존재하며 일을 하는 실체"를 말해요.클래스: 설계도 (예: 자동차 설계도)객체: 설계도를 보고 실제로 만든 물건 (예: 내 주차장에 있는 아반떼, 옆집 테슬라)설계도만 가지고는 도로를 달릴 수 없죠? 실제로 공장에서 찍어낸 '실물(객체)'이 있어야 운전을 할 수 있는 것과 같은 이치입니다.2. 왜 추상 클래스는 객체를 못 만들까?가장 큰 이유는 "미완성 설계도"이기 때문이에요.예를 들어, 제가 당신에게 "동물(Animal) 한 마리만 그려보세요"라고..
