-
가
-
가상 시스템(virtual machine)
- 기타 컴퓨터 프로그램을 실행하는 소프트웨어 프로그램. 이는 실제 시스템인 컴퓨터가 다른 실제 시스템처럼 작동할 수있게 합니다.
-
가시성(visibility)
-
값(public, protected 또는 private)을 참조하는 모델 요소를 내장된 이름 공간 외부에 표시하는 방법을 보여주는 값이 나와 있는 일람표.
-
가져오기(import)
-
패키지 컨텍스트에서 해당 패키지(패키지 내에 순환적으로 임베드되어 있는 패키지 포함) 내에서 클래스를 참조할 수 있는 패키지를 표시하는 종속성. 내보내기와 대조됩니다.
-
가져오기 종속성(import-dependency)
- 소스는 설계 패키지이고 대상은 다른 설계 패키지인 스테레오타입 종속성. 가져오기 종속성은 소스 패키지에서 대상 패키지의 공용 컨텐츠를 참조할 수 있게 합니다.
-
값(value)
-
유형 도메인의 요소.
-
개발자(developer)
- 프로젝트 채택 표준 및 프로시저에 따라 필수 기능을 개발할 책임이 있는 사람. 이는 요구사항, 분석 & 설계, 구현 및 테스트 규칙 중 하나를 사용하여 활동을 수행하는 것을 포함합니다.
-
개발 주기(development cycle)
-
라이프사이클, 주기와 동의어입니다. 테스트 주기 역시 참조하십시오.
-
개발 케이스(development case)
- 조직을 수행하는 데 사용되는 소프트웨어 엔지니어링 프로세스. 이는 통합 프로세스 제품의 구성 또는 사용자 정의로서 개발되며 프로젝트 요구사항에 맞게 조정됩니다.
-
개발 프로세스(development process)
-
소프트웨어 개발(예: 모델 구축 또는 모델 구현) 중에 해당 목적을 위해 수행하는 부분적으로 순서화된 단계 세트.
-
개선 요청(Enhancement Request)
- 새 기능 또는 시스템의 기능을 지정하는 스테이크홀더 요청 유형. 변경 요청 역시 참조하십시오.
-
객체(object)
-
상태 및 작동을 캡슐화하는 잘 정의된 경계 및 ID를 갖고 있는 엔티티. 상태는 속성 및 관계로 표시되며 작동은 조작, 메소드 및 상태 시스템으로 표시됩니다. 객체는 클래스 인스턴스입니다. 클래스, 인스턴스를 참조하십시오.
-
객체 다이어그램(object diagram)
-
특정 시점에 객체 및 해당 관계를 포함하는 다이어그램. 객체 다이어그램은 클래스 다이어그램 또는 의사소통 다이어그램의 특수한 경우라고 볼 수 있습니다. 클래스 다이어그램, 의사소통 다이어그램을 참조하십시오.
-
객체 라이프라인(object lifeline)
-
일정 기간 동안 객체의 존재를 표시하는 순서 다이어그램의 라인. 순서 다이어그램을 참조하십시오.
-
객체 모델(object model)
- 시스템 구현의 추상적 개념.
-
객체 클래스(object class)
- 객체의 속성 및 메소드를 정의하기 위한 템플리트. 객체 클래스는 다른 객체 클래스를 포함할 수 있습니다. 객체 클래스를 개별적으로 표현한 것을 객체라고 합니다.
-
객체 플로우 상태(object flow state)
-
한 상태에서의 조치의 출력을 다른 상태에서의 조치의 입력으로 전달하는 것을 나타내는 활동 그래프의 상태.
-
검사(inspection)
- 결함, 개발 표준의 위반 및 기타 문제점을 발견하기 위해 제안자가 아닌 사람 또는 그룹이 일부 결과물(모델, 문서, 소프트웨어)을 검사하는 공식 평가 기술.
-
검토(review)
- 검토는 잠재적 결함을 발견하고 결과물 세트의 품질을 평가하기 위해 수행되는 그룹 활동입니다.
-
게이트웨이(gateway)
- 다른 언어로 통신하는 네트워크를 연결하는 호스트 컴퓨터. 예를 들어, 게이트웨이는 회사의 LAN을 인터넷에 연결합니다.
-
결과(result)
- 결과물의 동의어입니다. 전달물을 참조하십시오.
-
결과물(artifact)
- (1) 다음과 같은 정보가 있습니다. 1) 프로세스에 의해 생성, 수정 또는 사용됩니다. 2) 책임 영역을 정의합니다. 3) 버전 제어를 준수합니다. 결과물은 모델, 모델 요소 또는 문서일 수 있습니다. 문서에 다른 문서를 포함할 수 있습니다.
-
소프트웨어 개발 프로세스에서 사용하거나 생성하는 실제 정보(예: 모델, 소스 파일, 스크립트 및 2진 실행 파일). 결과물은 전개 가능 컴포넌트의 구현을 구성할 수 있습니다. 제품과 동의어입니다. 컴포넌트와 대조됩니다.
-
결과물(output)
- (1) 프로세스 단계의 결과인 모든 결과물. 전달물을 참조하십시오.
- (2) 실시 중인 테스트에서 발생한 가공하지 않은 결과 또는 제품. 예상 결과물은 테스트 케이스에 정의되어 있습니다.
-
결과물 가이드라인(artifact guidelines)
- 결과물의 작성 및 변경 방법뿐만 아니라, 특정 결과물을 사용하여 작업하는 방법에 대한 설명.
-
결과물 세트(artifact set)
- 시스템의 한 측면을 표현해 주는 관련 결과물 세트. 여러 결과물이 수 많은 규칙에 사용되기 때문에 결과물 세트는 규칙과 일치하지 않습니다(예: 위험 목록, 소프트웨어 구조 문서 및 반복 계획).
-
결함(defect)
- 전달된 작업 제품의 예외 또는 결점(예: 초기 라이프사이클 단계 중에 발견된 누락 또는 불완전한 점, 테스트 또는 조작을 위해 충분히 완성된 소프트웨어에 포함된 오류 증상). 결함은 추적하여 해결하려고 하는 모든 유형의 문제점일 수 있습니다. 변경 요청 역시 참조하십시오.
-
결합(cohesion)
- 다른 컴포넌트에 의존하는 동일한 유형을 가진 같은 성격의 컴포넌트 조합. 서로 연결된 조치 또는 상태(유착). 커플링과 대조됩니다.
-
경계 클래스(boundary class)
- 시스템의 환경 및 내부 활동 간의 통신을 모델화하는 데 사용되는 클래스.
-
경쟁 조건(race condition)
- 둘 이상의 독립적 타스크가 동시에 동일한 상태 정보에 액세스하여 수정을 시도할 때 발생하는 조건. 이 조건으로 시스템의 불일치 작동이 발생하며 동시 시스템 설계에 있어 근원적인 문제점을 제공합니다.
-
계층(layer)
-
패키지를 동일한 추상 레벨에 있는 모델로 그룹화하는 특정 방법.
-
동일한 추상 레벨에 있는 분류자 또는 패키지 조직. 계층은 구조의 수평적 단편을 나타내는 반면 파티션은 수직적 단편을 나타냅니다. 파티션과 대조됩니다.
-
고객(customer)
- 시스템에 대한 재정적 책임을 지는 생산 조직 내부 또는 외부의 사람 또는 조직. 대형 시스템에서 일반 사용자가 고객이 아닐 수 있습니다. 고객은 개발된 제품 및 해당 결과물의 최종 수신인입니다. 스테이크홀더를 참조하십시오.
-
공격(attack)
- 실행 중인 컴퓨터 소프트웨어 프로그램의 정상 조작을 중단하거나 피하기 위한 계획적이며 방법론적인 시도. 구성원이 여러 가지 기술을 사용하여 소프트웨어 시스템을 공격하는 소프트웨어 해커(A.K.A 크래커) 커뮤니티로부터 생성된 악의적인 컴퓨터소프트웨어 공격의 개념. 일반적으로 보안 소프트웨어를 교묘히 피하고 호스트 시스템에 불법으로 침입합니다(예: 버퍼오버 플로우, 서비스 거부, 자원 제한조건 및 트로이의 목마 등). 이 용어는 차후에 소프트웨어 시스템에서 잠재적 버그를 노출할 수 있는 방법을 논의하면서 컴퓨터 소프트웨어 테스트 전문가에 의해 채택되었습니다.
-
공통 게이트웨이 인터페이스(CGI: common gateway interface)
- 웹 서버가 서버 시스템에서 실행되는 프로그램을 실행할 수 있게 하는 표준 프로토콜. CGI 프로그램은 웹 클라이언트 브라우저로부터의 요청에 대한 응답으로 실행됩니다.
-
관계(relationship)
-
모델 요소 간의 의미론적 연결. 관계의 예는 다음과 같습니다(연관 및 일반화).
-
관리(management)
- 개발 프로젝트의 계획 및 관리를 목적으로 하는 소프트웨어 엔지니어링 프로세스의 규칙.
-
교착 상태(deadlock)
- 두 개의 독립된 스레드 제어가 블록되어 있는 상태로 각각 상대편이 어떤 조치를 취하기를 기다리고 있습니다. 교착 상태는 종종 경쟁 조건을 피하기 위해 동기화 메커니즘을 추가한 경우에 발생합니다.
-
구조, 실행 가능(architecture, executable)
-
실행 가능한 구조.
-
구조(architecture)
-
IEEE에 따라 환경에서 최상위 레벨의 시스템 개념. 소프트웨어 시스템(해당 시점)의 구조는 인터페이스를 통해 상호작용하는 중요한 컴포넌트의 조직 또는 구조입니다. 이러한 컴포넌트는 좀 더 작은 단위의 컴포넌트 및 인터페이스로 구성되어 있습니다.
-
시스템의 조직적 구조. 구조는 인터페이스, 파트를 연결하는 관계 및 파트를 어셈블하는 데 필요한 제한조건을 통해 상호작용하는 여러 파트로 반복해서 분해될 것입니다. 클래스, 컴포넌트 및 서브시스템을 포함하는 인터페이스를 통해 상호작용하는 파트.
-
구조적 기능(structural feature)
-
모델 요소의 정적 기능(예: 속성).
-
구조적 기준선(architectural baseline)
- 기본 구조 및 시스템의 작동이 안정화되는 구현 단계의 맨 끝에 있는 기준선.
-
구조적 메커니즘(architectural mechanism)
- 구조적 메커니즘은 빈번히 발생하는 문제점에 대해 공통적이면서 구체적인 솔루션을 나타냅니다. 이는 구조 패턴, 작동 패턴 또는 둘 다일 수 있습니다. Rational Unified Process에서 구조적 메커니즘은 분석 메커니즘, 설계 메커니즘 및 구현 메커니즘에 대한 포괄적인 용어로 사용되는 구조적 메커니즘입니다.
-
구조적 모델 측면(structural model aspect)
-
유형, 클래스, 관계, 속성 및 조작을 포함하여 시스템 내의 객체의 구조를 강조하는 모델 측면.
-
구조적 보기(architectural view)
- 해당 Perspective에서 시스템 구조 보기. 기본적으로 구조, 모듈화, 필수 컴포넌트 및 기본 제어 플로우에 중점을 둡니다.
-
구조적 패턴(architectural pattern)
- [BUS96]은 구조적 패턴을 다음과 같이 정의합니다.
"구조적 패턴은 소프트웨어 시스템에 대한 기본적인 구조적 조직 스키마를 표현합니다. 이는 사전 정의된 서브시스템 세트를 제공하고, 책임을 지정하며, 이들 세트 간의 관계를 조직하는 데 필요한 규칙 및 가이드라인을 포함합니다."
이는 RUP에서 사용하는 설명입니다. 좀더 상세히 설명하면, 구조적 패턴은 특정 규모에서의 패턴(솔루션 템플리트)이며 구체적 소프트웨어 구조에 대한 템플리트입니다. 이는 시스템 전체 특성 및 일반적으로 서브시스템 규모(클래스 레벨이 아님)의 관계를 다룹니다. 이 방법에서 구조적 패턴이 전문화되지 못하는 기본적인 이유는 없지만, 기본적으로 구조적 패턴은 어플리케이션 도메인에 종속되거나 특정 도메인의 어휘가 패턴의 설명에 사용되지 않는 것 같지는 않습니다. 분석 패턴과 비교하십시오. 소프트웨어 구조 문서는 시스템에 사용되는 구조적 패턴을 표시합니다.
-
구조화된 클래스(structured class)
-
내부 구조를 가진 분류자(예: 클래스 또는 컴포넌트)입니다. 커넥터로 연결된 파트의 세트가 포함되어 있습니다. 외부 환경 및 해당 내부 파트 간의 상호작용이 강제로 포트를 통해 전달될 수 있습니다.
-
구체적(concrete)
- 실제, 특정 사물 또는 인스턴스와 연관 또는 관련된 것. 감각적으로 인식될 수 있으나 추상적이거나 상상적이지는 않습니다. 추상과 대조됩니다. 구체적 클래스를 참조하십시오.
-
구체적 클래스(concrete class)
-
직접 초기화할 수 있는 클래스. 추상 클래스와 대조됩니다.
-
구축(construction)
- 통합 프로세스의 세 번째 단계. 이 단계에서 실행 가능한 구조적 기준선으로부터 사용자 커뮤니티로 전이 준비가 된 지점으로 소프트웨어를 가져옵니다.
-
구축자(constructor)
- 클래스와 동일한 이름을 가지며 클래스 유형을 가진 객체를 구축하고 초기화하는 데 사용되는 특수 클래스 메소드.
-
구현(implementation)
- 적절한 품질 표준을 충족시키는 소프트웨어 구성요소를 구현하는 것이 목적인 소프트웨어 엔지니어링 프로세스의 규칙.
-
무엇인가를 구축하거나 계산하는 방법에 대한 설명. 예를 들어, 클래스는 유형의 구현이고 메소드는 조작의 구현입니다.
-
구현 메커니즘(implementation mechanism)
- 구현 프로세스 중에 사용되는 구조 메커니즘. 이는 설계 메커니즘을 정제한 것으로, 메커니즘의 정확한 구현을 지정하고 구축시 여러 구현 패턴(이디엄)을 적용합니다. 또한 규모면에서 설계 메커니즘과 구현 메커니즘 사이에 차이가 있지 않습니다. 예를 들어, 내부 프로세스 통신 분석 메커니즘의 특정 구현은 특정 운영 체제의 공유된 메시지 함수 호출을 활용하는 공유된 메모리 설계 메커니즘입니다. 세마포어를 사용하거나 기타 구현 메커니즘에 기반한 래칭 메커니즘을 사용하여 동시성 충돌(공유된 메모리에 부적당한 동시 액세스)을 방지할 수 있습니다.
-
구현 모델(implementation model)
- 구현 모델은 컴포넌트의 콜렉션 및 이를 포함하는 구현 서브시스템의 콜렉션입니다.
-
구현 보기(implementation view)
-
패키징, 레이어링 및 형상 관리(소유권, 릴리즈 전략 등) 모두와 관련하여 개발 환경에서 정적 소프트웨어 요소(코드, 데이터 및 기타 수반 결과물)의 조직에 대해 설명하는 구조적 보기. 통합 프로세스에서 이는 구현 모델에 대한 보기입니다.
-
구현 상속(implementation inheritance)
-
보다 특정한 요소의 구현 상속. 인터페이스의 상속을 포함합니다. 인터페이스 상속과 대조됩니다.
-
구현 서브시스템(implementation subsystem)
- 좀더 작은 파트로 나눠서 구현 모델을 구성하는 데 사용되는 컴포넌트 및 기타 구현 서브시스템의 콜렉션. RUP에서 구현 모델 및 구현 서브시스템은 구현 보기의 대상이므로 개발시 가장 중요하다는 점을 주의하십시오. 이는 설계 패키지와 동일합니다. "구현 서브시스템"이라는 이름은 "서브시스템"이라는 용어의 일반적인 사용을 반영하여 컴포넌트 보다 규모가 큰 것을 나타냅니다. 그러나 UML 용어에서 이는 서브시스템이 아닌 패키지 스테레오타입입니다.
-
구현 패턴(implementation pattern)
-
이디엄을 참조하십시오.
-
구현화(elaboration)
- 제품 비전 및 해당 구조를 정의하는 프로세스의 두 번째 단계.
-
규정자(qualifier)
-
값이 연관을 통해 객체와 관련된 객체 세트를 파티션하는 연관 속성 또는 속성 튜플.
-
규칙(discipline)
- 규칙은 주요 '관심 영역'에 관련된 관련 활동의 콜렉션입니다. RUP의 규칙에는 다음이 포함됩니다(비즈니스 모델링, 요구사항, 분석 & 설계, 구현, 테스트, 전개, 구성 & 변경 관리, 프로젝트 관리, 환경).
-
그린 필드 개발(green-field development)
- "기존 시스템으로부터의 전개" 또는 "레거시 단편의 리엔지니어링"과는 다르게 "스크래치에서 시작"하는 개발. 어원: 풀만 있는 비개발 지역에 새 공장을 지을 때 발생하는 용도 변경.
-
근거리 통신망(LAN: local area network)
- 제한된 지역 내에 사용자가 거주하는 건물에 위치한 컴퓨터 네트워크. LAN은 일반적으로 여러 클라이언트 워크스테이션에 서비스를 제공하는 하나 이상의 서버 시스템으로 구성됩니다.
-
기능(feature)
- 직접 스테이크홀더 요구사항을 이행하는 시스템이 제공하는 외부적으로 관측 가능한 서비스.
-
인터페이스, 클래스 또는 데이터 유형과 같은 분류자 내에 캡슐화되어 있는 특성(예: 조작 또는 속성).
-
기본 클래스(base class)
- 기타 클래스 또는 Bean으로 부터 도출된 클래스. 기본 클래스는 다른 기본 클래스로부터 도출될 수 있습니다. 추상 클래스를 참조하십시오.
-
기술 권한(technical authority)
- 프로젝트의 기술 권한은 변경 요청을 구현할지 여부 및 구현 방법을 중재할 권한과 전문 기술을 갖고 있습니다. 기술 권한은 변경 타스크를 정의하며 변경 요청에 해당하는 작업 타스크 엔지니어링의 결과를 평가합니다.
-
기준선(baseline)
- 향후 전개 또는 개발을 위해 합의된 기초를 구성하고 공식 프로시저(예: 변경 관리 및구성 제어)를 통해서만 변경될 수 있는결과물의 검토 및 승인된 릴리즈.
-
꼬리표 값(tagged value)
-
특성을 이름-값 쌍으로 명시적으로 정의합니다. 꼬리표 값에서 이름을 태그라고 합니다. 특정 태그는 UML에 사전 정의되어 있으며 나머지는 사용자 정의할 수 있습니다. 꼬리표 값은 UML에 있는 세 개의 확장 가능성 메커니즘 중 하나입니다. 제한조건, 스테레오타입을 참조하십시오.
-
나
-
내보내기(export)
-
패키지 컨텍스트에서 내장된 메시지 외부에서 요소를 볼 수 있게 합니다. 가시성을 참조하십시오. 내보내기[OMA], 가져오기와 대조됩니다.
-
내부 전이(internal transition)
-
객체의 상태를 변경하지 않고 이벤트에 대한 응답을 알려주는 전이.
-
내장된 문서(enclosed document)
- 문서 세트를 전체로 수집하기 위해 다른 문서에 내장될 수 있는 문서. 각 포함물뿐만 아니라 포함하는 문서는 별도의 결과물로 간주됩니다.
-
노드(node)
-
노드는 일반적으로 최소 메모리를 가지고 있으며 종종 처리 능력도 있는 런타임 컴퓨팅 자원을 나타내는 분류자입니다. 노드에 런타임 객체 및 컴포넌트가 상주할 수 있습니다.
-
논리적 보기(logical view)
- 시스템 설계의 기본 클래스에 대해 설명하는 구조적 보기. 주요 비즈니스 관련 클래스 및 핵심 작동 및 구조 메커니즘(지속성, 의사소통, 오류 허용, 사용자 인터페이스)을 정의하는 클래스. 통합 프로세스에서 논리적 보기는 설계 모델의 보기입니다.
-
다
-
다양성(multiplicity)
-
세트가 가정할 수 있는 허용 가능한 카디낼러티 범위의 스펙. 연관에서 역할, 합성의 일부분, 반복 및 기타 목적을 위해 다양성 스펙을 제공할 수 있습니다. 본질적으로 다양성은 양의 정수의 서브세트(무한)입니다. 카디낼러티와 대조됩니다.
-
다이어그램(diagram)
-
모델의 전체 또는 일부분을 그래픽으로 표시하는 것.
-
모델 요소 콜렉션의 그래픽 프리젠테이션으로서, 대부분 호(관계) 및 정점(기타 모델 요소)의 연결된 그래프로 표현됩니다. UML은 다음 다이어그램을 지원합니다(클래스 다이어그램, 객체 다이어그램, 유스 케이스 다이어그램, 순서 다이어그램, 의사소통 다이어그램, 상태 차트 다이어그램, 활동 다이어그램, 컴포넌트 다이어그램 및 전개 다이어그램).
-
다중 값(multi-valued)
-
다양성 유형:: 상위 속성이 1보다 큰 숫자로 설정된 다양성을 가진 모델 요소. 다중 값이라는 용어는 속성, 매개변수 등이 임의의 시점에 갖는 값의 갯수와는 무관합니다. 단일 값과 대조됩니다.
-
다중 분류(multiple classification)
-
객체가 둘 이상의 클래스에 직접 속할 수 있는 일반화의 의미론적 변형. 동적 분류를 참조하십시오.
-
다중 상속(multiple inheritance)
-
둘 이상의 수퍼유형을 가질 수 있는 유형은 일반화의 의미론적 변형입니다. 단일 상속과 대조됩니다.
-
단계(phase)
- 두 개의 주요 프로젝트 이정표 간의 시간. 이 기간 중에 잘 정의된 목표 세트를 충족시키고 결과물을 완료하며, 다음 단계로 이동할지 또는 이동하지 않을지를 결정합니다.
-
단언(assertion)
- 반드시 존재해야 하는 프로그램 상태 또는 프로그램 실행 중 특정 시점에서 프로그램 변수가 충족시켜야만 하는 조건 세트를 지정하는 논리식.
-
단일 값(single value)
-
다양성 유형:: 상위 속성이 1로 설정되었을 때 정의된 다양성이 단일 값인 모델 요소. 단일 값 속성(예: 하한이 0인 다양성)이 값을 갖지 않을 수 있기 때문에, 단일 값이라는 용어는 속성, 매개변수 등이 임의의 시점에 갖는 값의 갯수와는 무관합니다. 다중 값과 대조됩니다.
-
대상 테스트 항목(target test item)
- 테스트 노력의 대상으로 식별된 개발 제품의 측면(일반적으로 소프트웨어 또는 하드웨어). 대상 테스트 항목은 조작, 인터페이스, 기능, 컴포넌트, 구현 서브시스템 또는 시스템 레벨에서 범위가 지정되거나 아니면 시스템의 외부 측면(예: 운영 체제 또는 주변 장치)일 수 있습니다. 테스트 대상, 테스트 항목과 동의어입니다.
-
대화 가능(conversational)
- 대화 방식으로 두 개의 분산 어플리케이션이 정보를 교환하는 통신 모델. 일반적으로, 어플리케이션은 대화를 시작(또는 할당)하고 일부 데이터를 보낸 다음 다른 어플리케이션이 일부 데이터를 보낼 수 있습니다. 두 개의 어플리케이션은 한 어플리케이션이 완료(또는 할당해제)될 때까지 번갈아 데이터를 보냅니다. 대화 가능한 모델은 동기 양식의 통신입니다.
-
데이터베이스(database)
- (1) 하나 이상의 어플리케이션을 충족시키는 스키마에 따라 중복이 제어되어 함께 저장되는 관련 데이터의 콜렉션.
- (2) 시스템에 저장되는 모든 데이터 파일.
- (3) 함께 저장되어 데이터베이스 관리 시스템에 의해 관리되는 데이터 세트.
-
데이터베이스 관리 시스템(DBMS: database management system)
- 효율적인 액세스, 무결성, 복구, 동시 제어, 기밀 및 보안을 위해 중앙 제어, 데이터 독립성 및 복합 실제 구조 서비스를 제공함으로써 데이터를 관리하는 컴퓨터 프로그램.
-
데이터 유형(datatype)
-
ID가 결여되어 있고 조작에 역효과가 없는 값 세트에 대한 설명. 데이터 유형은 기본적으로 사전 정의되어 있는 유형 및 사용자 정의 가능 유형을 포함합니다. 사전 정의된 유형에는 숫자, 문자열 및 시간이 포함됩니다. 사용자 정의 가능 유형에는 일람표가 포함됩니다.
-
도메인(domain)
- 관련된 값을 가진 제품군으로 규정되는 지식 또는 활동 영역.
-
해당 영역의 참가자가 이해하는 개념 및 기술 세트로 규정되는 지식 또는 활동 영역.
-
도메인(데이터베이스)(domain(database))
- 데이터베이스의 테이블 열에 대해 올바른 값의 범위를 정의하는 사용자 정의된 데이터 유형.
-
도메인 모델(domain model)
-
도메인 컨텍스트에서 가장 중요한 객체 유형을 캡처하는 도메인 모델. 도메인 객체는 시스템이 작업하는 환경에 존재하는 엔티티 또는 환경에서 발생하는 이벤트를 표시합니다. 도메인 모델은 비즈니스 분석 모델의 서브세트입니다.
-
도메인 이름 서버(DNS: domain name server)
- www.software.ibm.com과 같은 도메인 이름을 123.45.67.8과 같이 숫자로 된 인터넷 프로토콜 주소로 변환하기 위한 시스템.
-
도출된 요소(derived element)
-
다른 요소로부터 계산될 수 있으나 명확도를 위해 표시되거나 의미론 정보를 추가하지 않더라도 설계 목적으로 포함되는 모델 요소.
-
동기 상태(synch state)
-
상태 시스템의 동시 영역을 동기화하는 데 사용되는 상태 시스템의 정점.
-
동기 조치(synchronous action)
-
전송 객체가 결과를 기다리기 위해 일시정지하는 요청. 비동기 조치와 대조됩니다.
-
동등 클래스(equivalence class)
- 객체가 유사하게 작동할 것으로 예상되는 동등한 값의 분류. 이 기술은 가상 테스트가 너무 많아 가용 시간에 실시할 수 없을 경우, 실행할 가장 중요한 테스트를 분석할 수 있도록 적용될 수 있습니다. 동등 파티션, 도메인과 동의어입니다.
-
동시 서브상태(concurrent substate)
-
동일한 합성 상태에 포함되어 있는 다른 서브상태와 동시에 보유할 수 있는 서브상태. 합성 서브상태를 참조하십시오. 해체 서브상태와 대조됩니다.
-
동시성(concurrency)
-
동일한 시간 간격에서 둘 이상의 활동이 발생하는 것. 동시성은 두 개 이상의 스레드를 조금씩 차이를 두면서 실행하거나 동시에 실행하여 도달할 수 있습니다. 스레드를 참조하십시오.
-
동적 분류(dynamic classification)
-
객체가 유형 또는 역할을 변경할 수 있는 일반화의 의미론적 변형. 정적 분류와 대조됩니다.
-
동적 정보(dynamic information)
- 사용자가 요청할 때 작성되는 정보. 동적 정보는 각 사용자가 이를 볼 때마다 다른 컨텐츠를 볼 수 있도록 시간이 지남에 따라 변경됩니다.
-
라
-
라이프사이클(lifecycle)
- 라이프사이클은 4단계(초기, 구현, 구축 및 이행)를 거치면 완료됩니다. 초기 단계의 시작 부분과 이행 단계의 마지막 부분까지 걸리는 시간. 개발 주기, 주기와 동의어입니다.테스트 주기 역시 참조하십시오.
-
런타임(run time)
-
컴퓨터 프로그램이 실행되는 기간. 모델링 시간과 대조됩니다.
-
리스너(listener)
- JDK 1.1에서 이벤트를 수신하고 처리하는 클래스.
-
릴리즈(release)
- 주요 이정표에서 평가 객체인 최종 제품의 서브세트. 릴리즈는 안정적이며 실행 가능한 제품 버전으로서, 다른 결과물과 함께 이 릴리즈(예; 릴리즈 정보 또는 설치 지시사항)를 사용하는 데 필요합니다. 릴리즈는 내부 또는 외부일 수 있습니다. 내부 릴리즈는 이정표의 일부로서 또는 사용자 또는 고객에게 대한 시연용으로 개발 조직에 의해서만 사용됩니다. 외부 릴리즈(또는 전달)는 일반 사용자에게 전달됩니다. 릴리즈는 완벽한 제품일 필요는 없으나, 엔지니어링 Perspective에서만 유용성을 측정할 경우 방법에 따라 한 단계일 수 있습니다. 릴리즈는 개발 팀이 "90% 완료, 90% 남음"과 같은 증후군을 방지하기 위해 일정한 간격으로 마감할 수 있게 하는 강제 실행 기능 역할을 합니다. 프로토타입, 기준선 역시 참조하십시오.
-
릴리즈 관리자(release manager)
- 릴리즈 관리자는 모든 소프트웨어 자원이 제어되고 필요에 따라 내부 및 외부 릴리즈로 구성 가능한지를 확인할 책임이 있습니다.
-
링크(link)
-
두 객체 간의 의미론적 연결. 연관인스턴스. 연관을 참조하십시오.
-
링크 종료(link end)
-
연관 종료 인스턴스. 연관 종료를 참조하십시오.
-
마
-
매개변수(parameter)
-
변경, 전달 또는 리턴될 수 있는 변수의 스펙(예: 이름, 유형 및 방향). 매개변수는 조작, 메시지 및 이벤트에 사용됩니다. 정규 매개변수와 동의어입니다. 인수와 대조됩니다.
-
매개변수 연결(parameter connection)
- 특성 값 또는 조치, 메소드 또는 스크립트의 리턴 값을 제공함으로써 조치 또는 메소드의 매개변수를 지정하는 연결. 매개변수는 항상 연결의 소스입니다. 연결을 참조하십시오.
-
매개변수화된 요소(parameterized element)
-
하나 이상의 바인드되지 않은 매개변수를 가진 클래스에 대한 설명. 템플리트와 동의어입니다.
-
메소드(method)
- (1) 무엇인가를 완료하기 위한 일반적이고 체계적인 방법. 타스크를 완료하거나 목표를 이룰 수 있도록 논리적으로 순서화된 계획 또는 프로시저가 따릅니다.
- (2) UML 1.1: 조작. 조작의 결과에 영향을 미치는 알고리즘 또는 프로시저의 구현.
-
조작의 구현. 이는 조작에 연관된 알고리즘 또는 프로시저를지정합니다.
-
메소드 호출(method call)
-
메시지와 동의어입니다.
-
메시지(message)
-
활동이 발생한다고 예상하고 한 인스턴스에서 다른 인스턴스로 정보를 전달하는 스펙. 메시지는 신호 발생 또는 조작 호출을 지정할 수 있습니다.
-
메시징(messaging)
- 서로 메시지를 보냄으로써 분산 어플리케이션이 의사소통할 수 있는 통신 모델. 메시지는 일반적으로 반드시 응답이 필요하지 않은 짧은 정보 패킷입니다. 메시징은 비동기 통신 메소드를 구현합니다. 호출하여 특정 타스크를 수행하도록 매개변수 세트를 전달할 수 있는 클래스 내의 Java 코드 단편.
-
메커니즘(mechanism)
- 메커니즘은 패턴 인스턴스입니다. 특정 모델과 협업하기 위해서는 약간의 추가 정제가 필요할 수 있습니다. 따라서 메커니즘은 단일 컨텍스트로 된 특정 솔루션(순환 문제점에 대한)입니다. 메커니즘은 패턴에 적합하거나 패턴을 준수한다고 말할 수 있습니다. 협업은 메커니즘이라고 할 수 있으나 용어는 일반적으로 소프트웨어 어플리케이션(예: 지속성을 처리하거나 패턴이 적용 가능할 경우)에서 공통적으로 반복되는 문제점에 대한 솔루션을 제공하는 협업용으로 예약되어 있습니다. 분석 및 설계에서 메커니즘 개념은 '플레이스홀더'(지속성이 필요한 것으로 식별됨)로서 사용될 수 있습니다. 예를 들어, 분석가 및 설계자는 문제점을 체계적이고 일관성있게 해결할 수 있도록 하는 지속성 메커니즘이 사용된다고 말할 수 있습니다.
-
메타 객체(meta-object)
-
메타모델링 언어의 모든 메타 엔티티에 대한 일반 용어(예: 메타 유형, 메타 클래스, 메타 속성 및 메타 연관).
-
메타 메타모델(meta-metamodel)
-
메타모델을 표현할 언어를 정의하는 모델. 메타 메타모델과 메타모델의 관계는 메타모델과 모델 간의 관계와 동일합니다.
-
메타모델(metamodel)
-
모델을 표현할 언어를 정의하는 모델.
-
메타 클래스(metaclass)
-
인스턴스가 클래스인 클래스. 메타 클래스는 일반적으로 메타모델을 구성하는 데 사용됩니다.
-
모델(model)
- 의미론적으로 근접한 추상적 개념의 시스템. 통합 프로세스에서 특정 Perspective에서 본 시스템의 완전한 설명('완전'이란 말은 해당 Perspective에서 시스템을 이해하는 데 추가 설명이 필요하지 않음을 의미함). 모델 요소 세트. 두 모델이 중복될 수 없습니다.
-
의미론적으로 근접한 추상적 주제 시스템. 시스템을 참조하십시오.
- 사용법 참고: MOF 스펙 컨텍스트에서 메타 메타모델에 대해 설명합니다. 간략하게 말해서 메타 메타모델은 간단히 모델이라고 합니다.
-
모델 구현화(model elaboration)
-
출력된 모델에서 저장소 유형을 생성하는 프로세스. 구현된 모델을 기반으로 하고 이에 따라 저장소를 초기화하고 데이터를 입력할 수 있는 인터페이스 및 구현의 생성을 포함합니다.
-
모델링 규칙(modeling convention)
- 개념을 표현하는 방법, 프로젝트 팀 관리에서 결정한 모델링 언어에 대한 제한사항("서브시스템 간에는 상속을 사용하지 마십시오", "유스 케이스 모델에서는 확장 또는 포함 연관을 사용하지 마십시오", "C++에서 friend 구축을 사용하지 마십시오."). 소프트웨어 구조 문서에 나와 있습니다.
-
모델링 시간(modeling time)
-
소프트웨어 개발 프로세스의 모델링 단계 중에 발생하는 것을 간주합니다. 여기에는 분석 시간 및 설계 시간이 포함됩니다. 사용법 참고: 객체 시스템을 논의할 때 모델링 시간 및 런타임 문제를 구분하는 데 중요합니다. 분석 시간, 설계 시간을 참조하십시오. 런타임과 대조됩니다.
-
모델 요소(model element)
-
모델화화고 있는 시스템에서 가져온 요약의 요소. 보기 요소와 대조됩니다.
- MOF 스펙에서 모델 요소는 메타 객체라고 간주됩니다.
-
모델 정의(defining model)
-
저장소가 기본으로 하는 모델. 여러 개의 저장소가 동일한 정의 모델을 가질 수 있습니다.
-
모델 측면(model aspect)
-
메타모델의 특정 품질을 강조하는 모델링 차원. 예를 들어, 구조적 모델 측면은 메타모델의 구조적 품질을 강조합니다.
-
모듈(module)
-
기억장치 및 조작의 소프트웨어 단위. 모듈에는 소스 코드 모듈, 2진 코드 모듈 및 실행 가능 코드모듈을 포함합니다. 컴포넌트를 참조하십시오.
-
문서(document)
- 문서는 종이 또는 종이 메타포를 사용하는 매체에 표현될 정보 콜렉션입니다. 종이 메타포에는 페이지 개념이 포함되며, 내재적 또는 명시적인 일련의 컨텐츠가 들어 있습니다. 이 정보는 텍스트 또는 2차원의 그림으로 되어 있습니다. 예를 들어, 종이 메타포에는 워드 프로세서 문서, 스프레드시트, 스케줄, Gantt 도표, 웹 페이지 또는 오버헤드 슬라이드 프리젠테이션이 있습니다.
-
문서 설명(document description)
- 의도했던 특정 문서의 컨텐츠에 대해 설명합니다.
-
문서 템플리트(document template)
- Adobe(R) FrameMaker(R) 또는 Microsoft(R) Word(R)와 같은 툴에 사용 가능한 구체적인 툴 템플리트.
-
문자열(string)
-
텍스트 문자의 순서. 문자열 표시 세부사항은 구현에 의존하며 국제적 문자 세트 또는그래프를 지원하는 문자 세트를 포함합니다.
-
뮤테이터 메소드(mutator method)
- 해당 인스턴스 변수에 대한 인터페이스를 제공하기 위해 객체가 제공하는 메소드. 인스턴스 값을 리턴하는 액세서 메소드는 get 메소드 또는 getter 메소드라고 하고, 인스턴스 변수에 값을 지정하는 뮤테이터 메소드는 set 메소드 또는 setter 메소드라고 합니다.
-
바
-
바인딩(binding)
-
템플리트의 매개변수에 인수를 제공하여 템플리트로부터 모델 요소를 작성.
-
반복(iteration)
-
릴리즈(내부 또는 외부)를 생성하는 기준선 계획 및 평가 기준을 포함한 별개의 활동 순서.
-
받기[메시지](receive [a message])
-
보내는 사람 인스턴스로부터 전달된 정보 처리. 보내는 사람, 받는 사람을 참조하십시오.
-
받는 사람(receiver)
-
보내는 사람 객체로부터 전달된 정보를 처리하는 객체. 보내는 사람과 대조됩니다.
-
방화벽(firewall)
- 정의된 규칙에 따라 전달되는 트래픽을 제한하는 데 사용될 수 있는 연관된 소프트웨어가 있는 컴퓨터 또는 프로그램 가능 장치. 일반적으로 발신지 또는 대상 주소와 TCP/IP 포트 번호를 기본으로 제어가 적용됩니다.
-
버전(version)
- 일부 결과물의 변형. 일반적으로 이전 버전을 확장한 결과물의 나중 버전.
-
범위 관리(scope management)
- 사용 가능한 자원 및 시간을 토대로 특정 릴리즈 주기에서 구현될 수 있는 요구사항 세트의 우선순위를 결정하고 판별하는 프로세스. 이 프로세스는 변경사항이 발생하면 프로젝트 라이프사이클을 통해 계속해서 진행됩니다. 변경 관리 역시 참조하십시오.
-
베타 테스팅(beta testing)
- 실 사용자의 일부가 제품을 미리 사용해 보는 사전 릴리즈 테스트.
-
변경 관리(change management)
-
결과물에 대한 변경을 제어하고 추적하는 활동. 범위 관리 역시 참조하십시오.
-
변경 요청(CR: change request)
-
결과물 또는 프로세스를 변경하기 위해 스테이크홀더에서 모든 요청에 대한 일반적인 용어. 변경 요청에 문서화되어 있는 것은 근원, 현재 문제점의 영향, 제안된 솔루션 및 해당 비용에 대한 정보입니다. 개선 요청, 결함 역시 참조하십시오.
-
변경 제어 보드(CCB: change control board)
- CCB의 역할은 모든 변경 요청을 올바르게 고려하여 권한을 부여하고 조정할 수 있도록 중앙 제어 메커니즘을 제공하는 것입니다.
-
변수(variable)
- (1) 데이터 기능에 필요한 객체 내의 기억장치 위치. 데이터 기능은 숫자 또는 날짜와 같은 객체로서 포함하는 객체의 속성으로서 저장됩니다.
- (2) 런타임시 ID를 받는 Bean. 변수 자체는 데이터 또는 프로그램 논리를 포함하지 않습니다. 어플리케이션이 아닌 Bean에서 런타임 ID를 받으려면 연결되어있어야 합니다.
-
변환(transform)
- Rational Software Architect 사용법에서 기본적으로 메타모델, 모델 및 추상 레벨에 걸쳐 일괄처리에 맞게 최적화된 변환.
- 변환은 변환 수행 조치를 나타내는 명령으로도 사용됩니다(예: "사용자가 모델 A를 모델 B로 변환").
-
변환(transformation)(또는 모델 변환(model transformation))
- 일반적으로, 매개변수 및 기타 데이터 세트로부터 파생된 일부 규칙 세트를 따라 소스 모델에서 대상 모델을 생성하는 프로세스.
- 또한 '변환'은 소스 언어로 된 모델을 대상 언어로 된 모델로 변환하는 방법을 판별하는 결과물(정의, 스펙, 규칙 세트, 기타 데이터 등)을 설명하는 데 사용될 수 있습니다. 변환은 Rational Software Architect 사용법에서는 추상 개념으로 간주되어 변환 및 패턴으로 좀더 전문화됩니다.
-
변환 정의(transformation definition)
- [KLE03]에서는 이를 다음과 같이 정의합니다.
"소스 언어로 된 모델을 대상 언어로 된 모델로 변환할 수 있는 방법에 대해 함께 설명하는 변환 규칙 세트. "
-
보고서(report)
- 하나 또는 여러 개의 결과물에 대해 설명하는 자동으로 생성된 설명. 보고서 자체는 결과물이 아닙니다. 대부분의 경우, 보고서는 개발 프로세스의 임시 제품이며 관련 시스템의 특정 측면과의 의사소통 수단입니다. 이는 자체를 문서화하지 않는 결과물의 스냅샷 설명입니다.
-
보기(view)
- 해당 Perspective 또는 시점에서 보고 이 Perspective와 관련되지 않은 엔티티는 생략하는 모델의 간단한 설명(요약). 구조적 보기 역시 참조하십시오.
-
해당 Perspective 또는 유리한 관점에서 표시하고 이 Perspective와 관련되지 않은 엔티티는 생략하는 모델 투영.
-
보기(데이터베이스)(view(database))
- 데이터베이스에 있는 하나 이상의 실제 테이블에 들어 있는 열정보로 구성된 가상 테이블.
-
보기 요소(view element)
-
보기 요소는 모델 요소 콜렉션을 텍스트 및/또는 그래픽으로 투영한 것입니다.
-
보기 투영(view projection)
-
모델 요소를 보기 요소로 투영. 보기 프로젝션은 각 보기 요소에 대한 위치 및 양식을 제공합니다.
-
보내기(send)
-
보내는 사람 인스턴스에서 받는 사람 인스턴스로 정보를 전달하는 것. 보내는 사람, 받는 사람을 참조하십시오.
-
보내는 사람(sender)
-
정보를 받는 사람 객체로 전달하는 객체. 받는 사람과 대조됩니다.
-
보호 조건(guard condition)
- 연관된 전이를 시작하기 위해 지정해야 하는 조건.
-
부울(boolean)
-
값이 참 또는 거짓인지 표시하는 일람표.
-
부울 표현식(boolean expression)
-
부울 값에 대해 평가하는 표현식.
-
분류자(classifier)
-
작동 및 구조적 기능을 설명하는 메커니즘. 분류자는 인터페이스, 클래스, 데이터 유형 및 컴포넌트를 포함합니다.
-
분산 처리(distributed processing)
- 분산 처리는 기능 및 데이터가 LAN 또는 WAN에 연결된 복수의 컴퓨팅 자원을 통해 분산될 수 있는 어플리케이션 또는 시스템 모델입니다. 클라이언트/서버 컴퓨팅을 참조하십시오.
-
분석(analysis)
- 소프트웨어 개발 프로세스의 일부. 기본 목적은 문제점 도메인의 모델을 공식화하는 것입니다. 분석은 무엇을 수행할 것인지에 중점을 두며, 설계는 이를 수행하는 방법에 중점을 둡니다. 설계를 참조하십시오.
-
분석 & 설계
- (일반) 시스템의 필수 기능 및 품질 요구사항을 충족시킬 수 있는 전략적 결정을 수행하는 활동. 설계 모델을 참조하십시오.
-
통합 프로세스에서 규칙의 목적은 구현시 시스템의 유스 케이스 구현 방법을 보여주는 것입니다.
-
분석가(analyst)
- 스테이크홀더의 요구를 도출하고 해석한 다음, 이 요구를 전체 팀에게 전달할 책임이 있는 프로젝트 팀의 구성원.
-
분석 메커니즘(analysis mechanism)
- 핵심 클래스 및 서브시스템을 식별하는 발견 기간 중에 설계 프로세스의 초기에 사용되는 구조적 메커니즘. 일반적으로 분석 메커니즘은 자유롭게 구현하는 방식으로 솔루션의 핵심 측면을 캡처합니다. 분석 메커니즘은 일반적으로 문제점 도메인과 관련되어 있지 않지만 대신에 "전산학" 개념입니다. 이는 도메인 관련 클래스 또는 컴포넌트에 특정 작동을 제공하거나, 클래스 및/또는 컴포넌트 간의 협업 구현에 해당합니다. 이는 프레임워크로 구현됩니다(예: 지속성, 상호 처리 의사소통, 오류 또는 결함 핸들링, 통지, 메시지 처리하는 메커니즘).
-
분석 모델(analysis model)
-
설계 모델의 추상적 개념을 제공하는 객체 모델. 이는 유스 케이스의 초기 구현 정의를 제공합니다.
-
분석 시간(analysis time)
-
소프트웨어 개발 프로세스의 분석 단계 중에 발생한 사항을 참조하십시오. 설계 시간, 모델링 시간을 참조하십시오.
-
분석 클래스(analysis class)
- 시스템의 설계 요소에서 수행하는 역할의 추상적 개념. 일반적으로 유스 케이스 구현 컨텍스트 내에 있습니다. 분석 클래스는 여러 역할에 대해 추상적 개념을 제공하며, 이러한 역할의 일반 작동을 나타냅니다. 분석 클래스는 일반적으로 하나 이상의 설계 요소(예: 클래스 및/또는 캡슐 설계, 서브시스템 설계)로 전개됩니다.
-
분석 패턴(analysis pattern)
- [FOW97a] 분석 패턴은 다음과 같습니다.
"[...] 비즈니스 모델링에서 공통 구축을 나타내는 개념 그룹. 이는 하나의 도메인에만 관련될 수도 있고, 여러 도메인에 걸쳐 있을 수 있습니다."
이 참조서에서 도메인에 대한 어휘는 패턴을 설명하는 데 사용됩니다. [FOW97a]의 정의를 비즈니스 모델링 이외의 도메인으로 확장해야만 하기 때문입니다. 분석 패턴의 다른 측면은 분석 모델에서 초기화 설정에 필요한 추상적이고 개념적인 템플리트이며, 의도된 것(모든 패턴에서와 같이 바인딩을 통해)이라는 것입니다. 이는 설계를 통해 더 정제되어야 합니다. 분석 패턴의 규모는 광범위하게 변할 수 있지만 [FOW97a]에 표시된 규모는 중간 크기이며, 전체 어플리케이션의 분석 모델을 형성하도록 구성됩니다.
-
비동기 조치(asynchronous action)
-
전송 객체의 결과를 기다리기 위해 일시정지하지 않는 요청. 동기 조치와 대조됩니다.
-
비전(vision)
- 핵심 스테이크홀더 요구사항 및 시스템의 기능 레벨에서 개발 및 지정될 제품에 대한 사용자 또는 고객의 보기.
-
비주얼 프로그래밍 툴(visual programming tool)
- 프로그램을 그래픽으로 지정하는 데 필요한 수단을 제공하는 툴. 어플리케이션 프로그래머는 컴포넌트의 그래픽 표현을 조작하여 어플리케이션을 작성합니다.
-
비즈니스 개선(business improvement)
-
비즈니스 리엔지니어링 수행. 여기서, 변경 작업은 로컬이며 전체 비즈니스로 확장하지 않습니다(정리 비용, 리드 시간, 모니터링 서비스 및 품질).
-
비즈니스 구조(business architecture)
- 비즈니스 구조는 다른 요소에 대해 명확한 관계를 가진 조직화된 요소 세트로서, 각 기능에 의해 정의된 전체 구조를 하께 형성합니다. 요소는 조직적이며 작동 가능한 비즈니스 구조를 나타내며 비즈니스의 핵심 프로세스 및 구조에 대한 추상적 개념을 보여줍니다.
-
비즈니스 규칙(business rule)
- 비즈니스 내에서 충족시켜야 하는 정책 또는 조건 선언. 비즈니스 규칙은 모델, 문서 또는 둘 다에서 캡처될 수 있습니다.
-
비즈니스 리엔지니어링(business reengineering)
-
비즈니스 엔지니어링 수행. 여기서, 변경 작업에는 전체 기존 비즈니스의 포괄적 관찰이 포함되고 작업 수행 이유 및 작업 수행 과정에 대해 고찰하게 됩니다. 모든 기존의 비즈니스 프로세스를 조사한 후 근본적인 개선을 위해 이를 재구성하는 완전히 새로운 방법을 찾습니다. 이에 대한 다른 이름은 BPR(Business Process Reengineering) 및 프로세스 혁신입니다.
-
비즈니스 모델링(business modeling)
- 비즈니스를 시각적으로 모델링하는 데 사용할 수 있는 모든 모델링 기술을 포함합니다. 이는 비즈니스 엔지니어링을 수행하는 데 사용할 수 있는 기술의 서브세트입니다.
-
비즈니스 목표(business goal)
- 비즈니스 목표는 비즈니스에서 충족시켜야 하는 요구사항입니다. 비즈니스 목표는 미래의 어느 시점까지 도달할 수 있는 특정 표준 값을 설명하여 비즈니스의 활동을 계획 및 관리하는 데 사용됩니다. 비즈니스 목표 역시 참조하십시오.
-
비즈니스 목표(business objective)
- 상위 레벨 비즈니스 목표에 대해 공통적으로 사용되는 용어. 비즈니스 목표는 일반적으로 추상적이기 때문에 측정하기가 어려워, 보다 측정이 쉬운 하위 레벨 비즈니스 목표로 변환됩니다.
-
비즈니스 분석 모델(business analysis model)
-
비즈니스 유스 케이스의 구현에 대해 설명하는 객체 모델. 비즈니스 객체 모델과 동의어입니다.
-
비즈니스 시스템(business system)
- 비즈니스 시스템은 특정 목적을 이행하는 역할 및 자원 세트를 캡슐화하고 해당 목적을 달성할 수 있는 책임 세트를 정의합니다.
-
비즈니스 액터(인스턴스)(business actor(instance))
- 비즈니스와 상호작용하는 비즈니스 외부의 사람 또는 사물.
-
비즈니스 액터(클래스)(business actor(class))
- 비즈니스 액터 인스턴스 세트를 정의합니다. 여기서, 각 비즈니스 액터 인스턴스는 비즈니스와 관련하여 동일한 역할을 수행합니다.
-
비즈니스 엔지니어링(business engineering)
- 회사에서 특정 목표에 따라 해당 비즈니스를 설계하는 데 사용하는 기술 세트. 비즈니스 엔지니어링 기술은 비즈니스 리엔지니어링, 비즈니스 개선 및 비즈니스 작성 모두에 사용됩니다.
-
비즈니스 엔티티(business entity)
- 비즈니스 엔티티는 비즈니스 액터 및 비즈니스 작업자가 처리하는 중요하고 지속적인 정보를 나타냅니다.
-
비즈니스 유스 케이스(인스턴스)(business use-case(instance))
- 특정 비즈니스 액터에 대해 주목할 만한 가치가 있는 결과를 생성하는 비즈니스가 수행하는 일련의 조치.
-
비즈니스 유스 케이스(클래스)(business use-case(class))
- 비즈니스 유스 케이스는 비즈니스 유스 케이스 인스턴스 세트를 정의합니다. 여기서, 각 인스턴스는 비즈니스가 수행하는 일련의 조치로서 특정 비즈니스 액터에 대해 주목할 만한 가치가 있는 결과를 생성합니다. 비즈니스 유스 케이스 클래스에는 "주목할 만한 가치가 있는 결과"를 생성하는 것과 관련된 모든 기본 및 대체 워크플로우가 포함됩니다.
-
비즈니스 유스 케이스 구현(business use-case realization)
- 비즈니스 유스 케이스 구현은 비즈니스 객체 협업의 관점에서 특정 비즈니스 유스 케이스의 워크플로우가 비즈니스 분석 모델 내에서 구현되는 방법에 대해 설명합니다.
-
비즈니스 유스 케이스 모델(business use-case model)
- 비즈니스가 의도한 기능의 모델. 비즈니스 유스 케이스 모델은 조직에서의 역할 및 전달물을 식별하는 데 꼭 필요한 정보로 사용됩니다.
-
비즈니스 유스 케이스 패키지(business use-case package)
- 비즈니스 유스 케이스 패키지는 비즈니스 유스 케이스, 비즈니스 액터, 관계, 다이어그램 및 기타 패키지의 콜렉션입니다. 이는 콜렉션을 작은 파트로 나눠서 비즈니스 유스 케이스를 구조화하는 데 사용됩니다.
-
비즈니스 이벤트(business event)
- 비즈니스 이벤트는 비즈니스의 중요한 공간 및 시간에서 발생한 중요한 어커런스를 설명합니다. 비즈니스 이벤트는 비즈니스 프로세스 간에 신호를 보내는 데 사용되며, 일반적으로 비즈니스 엔티티와 연관되어 있습니다.
-
비즈니스 작성(business creation)
- 새 비즈니스 프로세스, 새 비즈니스 라인 또는 새 조직 작성을 목표로 하는 비즈니스 엔지니어링을 수행하는 것입니다.
-
비즈니스 작업자(business worker)
- 비즈니스 작업자는 비즈니스에서의 역할 또는 역할 세트를 나타냅니다. 비즈니스 작업자는 비즈니스 유스 케이스 구현에 참여하는 동안 다른 비즈니스 작업자와 상호작용을 하고 비즈니스 엔티티를 조작합니다.
-
비즈니스 전략(business strategy)
- 비즈니스 전략은 비즈니스 개념을 구현하는 데 필요한 프린시펄 및 목표를 정의합니다. 이는 궁극적으로 비즈니스 비전을 달성할 수 있는 장기적인 비즈니스 목표의 콜렉션을 구성합니다.
-
비즈니스 프로세스(business process)
- 조직 목표의 지원으로 정의된 결과를 제공하기 위해 조직의 자원을 사용하는 논리적으로 관련된 활동 그룹. RUP에서는 비즈니스의 예상 작동을 보여주는 비즈니스 유스 케이스와 비즈니스 작업자 및 비즈니스 엔티티가 해당 작동이 구현되는 방법을 보여주는 비즈니스 유스 케이스 구현을 사용하여 비즈니스 프로세스를 정의합니다. 프로세스 역시 참조하십시오.
-
비즈니스 프로세스 엔지니어링(business process engineering)
-
비즈니스 엔지니어링을 참조하십시오.
-
빌드(build)
- 시스템의 조작 가능한 버전 또는 최종 제품에서 제공된 성능 서브세트를 보여주는 시스템의 일부.
-
사
-
사용법(usage)
-
한 요소(클라이언트)가 올바르게 작동하거나 구현하기 위해 다른 요소(제공자)가 있어야 하는 종속성.
-
사용자 인터페이스(user interface)
- (1) 사용자가 컴퓨터와 상호작용할 수 있게 하는 하드웨어, 소프트웨어 또는 둘 다.
- (2) 사용자 인터페이스라는 용어는 시각적 프리젠테이션 및 사용자가 상호작용하는 할 때 사용하는 기본 소프트웨어를 지칭합니다.
-
사후 조건(postcondition)
- 유스 케이스를 종료할 때 시스템에 대한 제한조건을 정의하는 텍스트로 된 설명.
-
조작 완료시 반드시 참이어야 하는 제한조건.
-
상속(inheritance)
- 일반화를 가능하게 만드는 메커니즘. 개별 클래스 세그먼트 외부에 전체 클래스 설명을 작성하는 메커니즘.
-
좀더 특정한 요소가 작동에 관련된 보다 일반적인 요소의 작동 및 구조를 통합하는 메커니즘. 일반화를 참조하십시오.
-
상위(parent)
-
일반화 관계에서 다른 요소(하위)를 일반화한 것. 서브클래스, 서브유형을 참조하십시오. 하위와 대조됩니다.
-
상위 클래스(parent class)
- 다른 Bean 또는 클래스가 데이터, 메소드 또는 둘 다를 상속하는 클래스.
-
상태(state)
-
일부 조건을 충족시키는 객체의 수명 중에 일부 활동을 수행하거나 일부 이벤트를 기다리는 조건 또는 상황.
-
상태 시스템(state machine)
- 상태 시스템은 모델 요소의 작동을 지정하여 이벤트에 대한 응답 및 객체의 라이프사이클을 정의합니다.
-
응답 및 조치와 함께 이벤트에 대한 응답으로 일생동안 객체 또는 상호작용이 거치는 상태의 순서를 지정하는 작동.
-
상태 차트 다이어그램(statechart diagram)
-
상태 시스템을 보여주는 다이어그램. 상태 시스템을 참조하십시오.
-
상호작용(interaction)
-
특정 타스크를 수행하기 위해 인스턴스 간에 정보를 전달하는 방법에 대한 스펙. 상호작용은 협업 컨텍스트 내에 정의되어 있습니다. 협업을 참조하십시오.
-
상호작용 다이어그램(interaction diagram)
-
객체 상호작용을 강조하는 특정 유형의 다이어그램에 적용되는 일반 용어. 여기에는 의사소통 다이어그램 및 순서 다이어그램이 포함됩니다.
-
색상표(palette)
- Bean 색상표를 참조하십시오.
-
색인(index)
- 데이터베이스 테이블에서 행 검색 효율을 향상시키기 위해 사용하는 메커니즘.
-
샌드박스(sandbox)
- Java 애플릿이 실행되는 제한된 환경으로서 웹 브라우저에서 제공합니다. 샌드박스는 서비스를 제공하고 적합하지 않은 조치(예: 파일 I/O를 수행하거나 애플릿이 로드되어 있는 서버가 아닌 다른 서버와 상호작용하는 것)를 수행하지 못하게 합니다. 하위와 유사한 애플릿으로 샌드박스를 실행하는 환경을 호출합니다.
-
서명(signature)
-
작동 기능의 이름 및 매개변수. 서명은 선택적 리턴 매개변수를 포함할 수 있습니다.
-
서버(server)
- 네트워크의 여러 사용자 또는 워크스테이션에게 서비스를 제공하는 컴퓨터(예: 파일 서버, 프린터 서버 및 메일 서버).
-
서브상태(substate)
-
합성 상태의 일부분인 상태. 동시 서브상태, 해체 서브상태를 참조하십시오.
-
서브시스템(subsystem)
-
패키지라는 의미론을 갖고 있는 모델 요소는 다른 모델 요소 및 클래스를 포함할 수 있으며 작동할 수 있습니다. 서브시스템의 작동은 클래스 및 서브시스템이 포함하는 다른 서브시스템에 의해 제공됩니다. 서브시스템은 수행할 수 있는 작동을 정의하는 하나 이상의 인터페이스를 구현합니다.
-
서브시스템은 모델 요소를 그룹화한 것으로, 이들 중 일부는 다른 포함된 모델 요소에서 제공하는 작동의 스펙을 구성합니다. 패키지, 시스템 역시 참조하십시오.
-
서브시스템 상태(submachine state)
-
합성 상태와 동일하나 해당 컨텐츠는 다른 상태 시스템에 의해 설명되는 상태 시스템의 상태.
-
서브유형(subtype)
-
일반화 관계에서 전문화된 다른 유형(수퍼유형). 일반화를 참조하십시오. 수퍼유형을 참조하십시오.
-
서브클래스(subclass)
-
일반화 관계에서 전문화된 다른 클래스. 일반화를 참조하십시오. 수퍼클래스와 대조됩니다.
-
서브활동 상태(subactivity state)
-
잠시 지속 기간을 갖는 최소 단위가 아난 일련의 단계 실행을 나타내는 활동 그래프에서 상태.
-
설계(design)
-
시스템을 구현하는 방법을 결정하는 것이 기본 목적인 소프트웨어 개발 프로세서의 한 부분. 설계 중에 시스템의 필수 기능 및 품질 요구사항을 충족시킬 수 있는 전략 및 전술적 결정. 분석을 참조하십시오.
-
설계 메커니즘(design mechanism)
- 설계 프로세스 중이나 설계 세부사항을 완성하는 중에 사용되는 구조적 메커니즘. 이는 추가 정제이고 하나 이상의 구조적 및 설계 패턴을 바인드할 수 있는 관련 분석 메커니즘에 연관되어 있습니다. 규모면에서 분석 메커니즘과 설계 메커니즘 간에 차이가 있어야 할 필요는 없습니다. 분석 레벨 및 설계 레벨에서 지속성 메커니즘을 설명할 수 있으며 동일한 것을 의미하지만, 다른 정제 레벨에서는 동일하지 않습니다. 설계 메커니즘은 구현 환경에 대한 몇 가지 세부사항을 가정하나 특정 구현(예: 구현 메커니즘)으로 제한되지는 않습니다.예를 들어, 내부 프로세스 통신의 분석 메커니즘은 IPC(Interprocess Communication)의 여러 설계 메커니즘(공유된 메모리, IPC와 유사한 기능 호출, 세마포어 기본 IPC 등)에 의해 정제될 수 있습니다. 각 설계 메커니즘마다 특정한 장점과 단점이 있습니다. 특정 설계 메커니즘의 선택 여부는 메커니즘을 사용한 객체의 특성에 의해 결정됩니다.
-
설계 모델(design model)
-
유스 케이스의 구현을 설명하는 객체 모델. 구현 모델 및 해당 소스 코드의 추상화 역할을 합니다.
-
설계 서브시스템(design subsystem)
- 시스템의 일부를 나타내는 모델 요소. 설계 서브시스템은 해당 작동을 제공하는 다른 모델 요소(클래스 또는 기타 설계 서브시스템)를 패키지하여 작동을 캡슐화합니다. 또한 설계 서브시스템이 수행할 수 있는 작동을 정의하는 인터페이스 세트도 표시합니다.
-
설계 시간(design time)
-
소프트웨어 개발 프로세스의 설계 단계 중에 발생하는 것을 지칭합니다. 모델링 시간을 참조하십시오. 분석 시간과 대조됩니다.
-
설계 패키지(design package)
-
클래스, 관계, 유스 케이스 구현, 다이어그램 및 기타 패키지의 콜렉션으로, 이를 좀 더 작게 나누어 설계 모델로 구조화하는 데 사용됩니다. 이는 구현 서브시스템과 논리적으로 동일합니다.
-
설계 패턴(design pattern)
- [GAM94]에서는 설계 패턴을 다음과 같이 정의합니다.
"설계 패턴은 서브시스템 또는 소프트웨어 시스템의 컴포넌트를 정제하기 위한 스키마 또는 이들 간의 관계를 제공합니다." 여기서는 특정 컨텍스트 내의 일반 설계 문제점을 해결하는 통신 컴포넌트에서 공통적으로 발생하는 구조에 대해 설명합니다.
설계 패턴은 중소 규모의 패턴 즉, 규모면에서는 구조적 패턴보다 작으나 일반적으로 프로그래밍 언어에 독립적입니다. 설계 패턴이 바인드되면, 구체적 설계 모델의 일부분(설계 메커니즘의 일부)을 구성합니다. 레벨로 인해 설계 패턴은 도메인 간에 적용할 수 있습니다.
-
세대(generation)
-
주기가 종료되었을 때의 최종 릴리즈.
-
소프트웨어 구조(software architecture)
- 소프트웨어 구조에는 소프트웨어 시스템의 조직에 대한 중요한 결정이 포함됩니다. 시스템이 요소 간의 협업에 지정된 대로 작동과 함께 작성하는 구조적 요소 및 해당 인터페이스의 선택. 구조적 및 작동 요소를 점진적으로 커지는 서브시스템으로 작성. 이 조직, 이 요소 및 해당 인터페이스, 해당 협업 및 작성을 안내하는 구조적 스타일.
- 소프트웨어 구조는 구조 및 작동은 물론 사용법, 기능, 성능, 탄력, 재사용, 포용성, 경제성 및 기술 제한조건과도 연관되어 있습니다.
-
소프트웨어 스펙 검토(SSR: software specification review)
- 워터폴 방화벽 라이프사이클에서 소프트웨어 요구사항 스펙이 완료될 때 보유하는 기본 검토.
-
소프트웨어 요구사항(software requirement)
- 외부적으로 식별 가능한 시스템 작동의 스펙(예: 시스템에 대한 입력, 시스템으로부터의 출력, 시스템의 기능, 시스템의 속성 또는 시스템 환경의 속성).
-
속성(attribute)
-
클래스에 의해 정의되는 속성은 클래스의 이름 지정된 등록 정보 또는 해당 객체를 나타냅니다. 속성은 해당 인스턴스의 유형을 정의하는 유형을 갖고 있습니다.
-
분류자 인스턴스가 보유할 수 있는 값의 범위를 설명하는 분류자 내의 기능.
-
수령(reception)
-
분류자가 수신한 신호에 반응할 준비가 되었다는 선언.
-
수퍼유형(supertype)
-
일반화 관계에서 전문화된 다른 유형(수퍼유형). 일반화를 참조하십시오. 서브유형과 대조됩니다.
-
수퍼클래스(superclass)
-
일반화 관계에서 전문화된 다른 클래스(수퍼클래스). 일반화를 참조하십시오. 서브클래스와 대조됩니다.
-
순서 다이어그램(sequence diagram)
-
시간순으로 정렬된 객체 상호작용을 표시하는 다이어그램. 특히, 상호작용에 참여한 객체와 교환된 메시지의 순서를 표시합니다. 의사소통 다이어그램과는 달리 순서 다이어그램은 시간 순서를 포함하나 객체 관계는 포함하지 않습니다. 순서 다이어그램은 일반 양식(일반 시나리오에 대해 설명) 및 인스턴스 양식(시나리오 인스턴스에 대해 설명)에 존재합니다. 순서 다이어그램 및 의사소통 다이어그램은 유사한 정보를 표시하기는 하지만 표시 방법은 다릅니다. 의사소통 다이어그램을 참조하십시오.
-
순위(rank)
-
구조에 미치는 영향 또는 릴리즈에 대한 중요성에 대해 설명하는 유스 케이스 또는 시나리오의 속성.
-
스레드(thread)
- 실행 환경 내에서 실행 중인 독립적인 계산 및 내장된 운영 체제 프로세스에서 정의한 주소 공간("간단한 프로세스").
-
제어 흐름의 프로그램, 동적 모델 또는 일반 기타 표현을 통한 단일 실행 경로. 또한 간단한 프로세스인 활성 객체의 구현을 위한 스테레오타입. 프로세스를 참조하십시오.
-
스모크 테스트(smoke test)
- 이전 빌드 이후로 소프트웨어가 양식 또는 기능으로 회귀되는지를 판별하기 위해 각 소프트웨어 빌드에 대해 실행할 수 있는 테스트의 서브세트를 설명하는 데 사용되는 단계(일반적으로 숫자로 제한). 빌드 유효성 검증 테스트, 빌드 검증 테스트, 빌드 승인 테스트, 빌드 회귀 테스트 및 정상 여부 점검과 동의어입니다.
-
스윔레인(swimlane)
-
조치에 대한 책임을 조직하는 활동 다이어그램에 대한 파티션. 스윔레인은 일반적으로 비즈니스 모델의 조직 단위에 해당합니다. 파티션을 참조하십시오.
-
스키마[MOF](schema[MOF])
-
MOF 컨텍스트에서 스키마는 모델 요소의 컨테이너인 패키지와 동일합니다. 스키마는 MOF 패키지에 해당합니다. 메타모델과 대조되며 패키지는 MOF 패키지에 해당합니다.
-
스텁(stub)
- 테스트 목적의 기능을 포함하는 컴포넌트. 스텁은 일부 사전 정의된 값만을 리턴하는 순수 "더미"이거나, 더 복잡한 작동을 "시뮬레이팅"할 수 있습니다.
-
스테레오타입(stereotype)
- 요소의 메타 분류. 스트레오타입은 모든 특정 스테레오타입 값에 대해 지정될 수 있는 의미론적 구현을 갖고 있습니다. RUP에 사용하도록 권장되는 사전 정의된 스테레오타입을 보려면 RUP 내의 결과물에 대한 "UML 표현" 속성을 참조하십시오.
-
메타모델의 의미론을 확장하는 모델링 요소의 새로운 유형. 스테레오타입은 메타모델에서 기존의 특정 유형 또는 클래스에 기반해야 합니다. 스테레오타입은 의미론을 확장할 수 있으나 기존의 스테레오타입 및 클래스의 구조는 확장할 수 없습니다. 특정 스테레오타입은 UML에 정의되어 있고 나머지는 사용자 정의될 수 있습니다.
-
스테이크홀더(Stakeholder)
- 시스템의 결과에 실질적으로 영향을 받는 개인.
-
스테이크홀더 요구사항(stakeholder need)
- 구매 또는 사용을 정당화하기 위해 이행해야 하는 비즈니스 또는 운영상의 문제점(기회).
-
스테이크홀더 요청(stakeholder request)
-
스테이크홀더로부터의 여러 가지 전문화된 유형의 요청(예: 변경 요청, 개선 요청, 요구사항 변경 요청, 결함).
-
스토어드 프로시저(stored procedure)
- 데이터베이스에 연관된 코드 또는 스크립트의 기능적 단위.
-
스펙(specification)
-
무엇이 존재하는지 또는 무엇을 수행하는지에 대한 서술적 설명. 구현과 대조됩니다.
-
승격(promotion)
- JavaBean에서 포함된 Bean의 기능을 연결 작성에 사용할 수 있게 만드는 것(예: 패널에 있는 세 개의 누름 단추를 구성하는 Bean). 이 Bean이 프레임에 있을 경우, 프레임에서 사용하려면 누름 단추의 기능을 승격시켜야 합니다.
-
승인(acceptance)
- 고객이 소프트웨어 제품의 소유권을 부분적인 성능을 가진 계약 또는 완벽한 성능을 가진 계약으로 승인하는 조치.
-
시간(time)
-
절대적 또는 상대적 순간을 나타내는 값.
-
시간 이벤트(time event)
-
현재 상태를 입력한 다음에 경과된 시간을 나타내는 이벤트. 이벤트를 참조하십시오.
-
시간 표시(timing mark)
-
이벤트 또는 메시지가 발생한 시간에 대한 표시. 타이밍 표시는 제한조건에 사용될 수 있습니다.
-
시간 표현식(time expression)
-
절대적 또는 상대적 시간 값으로 분석하는 표현식.
-
시나리오(scenario)
-
작동을 보여주는 특정 조치의 순서. 시나리오는 하나 이상의 유스 케이스 인스턴스의 상호작용 또는 실행을 보여주는 데 사용될 수 있습니다. 상호작용, 테스트 시나리오를 참조하십시오.
-
시스템(system)
-
(1) 특정 목적을 달성하기 위해 조직된 연결된 단위의 콜렉션. 시스템은 여러 관점에서 하나 이상의 모델에 의해 설명될 수 있습니다. 실제 시스템과 동의어입니다.
- (2) 최상위 레벨 서브시스템.
-
시스템 요구사항 검토(System Requirements Review)
- 워터폴 라이프사이클에서 시스템 스펙이 완료될 때 보유하는 주요 검토의 이름.
-
시작(fire)
-
상태 전이를 실행하는 것. 전이를 참조하십시오.
-
시작 페이지(start page)
- 웹 사이트를 찾아볼 때 사용자가 보는 첫 번째 페이지. 기본 페이지, 홈 페이지와 동의어입니다.
-
신호(signal)
-
인스턴스 사이에 전달되는 비동기 자극의 스펙. 신호가 매개변수일 수 있습니다.
-
신호 상속(single inheritance)
-
한 개의 수퍼유형만을 가질 수 있는 유형에서 일반화의 의미론적 변형.다중 상속과 대조됩니다.
-
실제 매개변수(actual parameter)
-
인수와 동의어입니다.
-
실패(failure)
- 시스템 또는 컴포넌트가 지정된 성능 요구사항 내에서 해당 필수 기능을 수행할 능력이 없음[IE610.12]. 실패는 하나 이상의 오류에 근본 원인을 갖고 있는 하나 이상의 결함에 대한 식별 가능한 증상으로 규정됩니다.
-
실행 가능 구조(executable architecture)
- 실행 가능 구조는 시스템의 부분적 구현으로서, 특히 비기능적 요구사항을 충족하는 선택된 시스템 기능 및 특성을 보여주기 위해 빌드됩니다. 이는 구현 단계에서 성능, 처리량, 용량, 신뢰성 및 기타 'ilities'와 관련된 위험을 낮추기 위해 빌드되었기 때문에 완벽하게 작동하는 시스템 기능을 중단하지 않고 견고한 기반의 구축 단계에 추가할 수 있습니다. RUP는 실행 가능 구조를 의도대로 실행하여(요구사항 충족), 전달물 시스템의 일부분이 되도록 전개적 프로토타입으로 빌드하는 것이 목적입니다.
-
씬 클라이언트(thin client)
- 씬 클라이언트는 일반적으로 자원이 제한된 시스템에서 실행되거나 작은 운영 체제에서 실행되는 시스템을 지칭합니다. 씬 클라이언트는 로컬 시스템 관리가 필요하지 않으며 네트워크를 통해 전달된 Java 어플리케이션을 실행합니다.
-
아
-
애플릿(applet)
- 웹 브라우저 내에서 실행하도록 설계된 Java 프로그램. 어플리케이션과 대조됩니다.
-
액세서 메소드(accessor method)
- 인스턴스 변수에 대한 인터페이스를 정의하기 위해 객체가 제공하는 메소드. 인스턴스 값을 리턴하는 액세스 메소드는 get 메소드 또는 getter 메소드라고 하고, 인스턴스 변수에 값을 지정하는 뮤테이터 메소드는 set 메소드 또는 setter 메소드라고 합니다.
-
액세스 수정자(access modifier)
- 클래스, 메소드 또는 속성에 대한 액세스를 제어하는 키워드. Java의 액세스 수정자는 public, private, protected 및 패키지(기본값)입니다.
-
액터(인스턴스)(actor(instance))
- 시스템과 대화하는 시스템 외부의 사람 또는 사물.
-
액터(클래스)(actor(class))
- 시스템과 관련하여 각 액터 인스턴스가 동일한 역할을 수행하는 액터 인스턴스의 세트를 정의합니다.
-
이 유스 케이스와 상호작용할 경우, 유스 케이스의 사용자가 수행하는 연관된 역할 세트. 액터는 통신하는 각 유스 케이스에 대해 하나의 역할을 가지고 있습니다.
-
액터 일반화(actor generalization)
- 액터 클래스(하위)에서 다른 액터 클래스(상위)로의 액터 일반화는 유스 케이스의 상위에서 수행할 수 있는 역할을 하위에 상속함을 나타냅니다.
-
어플리케이션(application)
- 사용하기 위해 제출된 조치(새 기술). 기술을 적용한 조치.
- 특정 비즈니스(예: 은행업, 항공 산업, 주식 중개업, 보험, 회계, 재고 조사)에서 결정한 기능 및 산업 관련 소프트웨어.
- Java 프로그래밍에서 main() 메소드를 포함하는 자체 내장된 독립형 Java 프로그램입니다. 애플릿과 대조됩니다.
-
엔터프라이즈 Javabean(EJB: enterprise javabean)
- EJB는 서버에서 실행되고 클라이언트에서 호출되도록 설계된 시각적이지 않은 원격 객체입니다. EJB는 여러 번 빌드될 수 있는 시각적이지 않은 JavaBeans입니다. EJB는 한 시스템에 상주하며 다른 시스템으로부터 원격으로 호출될 수 있습니다. 이는 플랫폼에 독립적입니다. Bean이 쓰여지면 Java를 지원하는 모든 클라이언트 또는 서버 플랫폼에서 사용될 수 있습니다.
-
엔티티 클래스(entity class)
- 시스템이 저장한 정보 및 연관 작동을 모델화하는 데 사용되는 클래스. 여러 유스 케이스에서 재사용되는 일반 클래스로, 종종 지속적 특성을 가질 수 있습니다. 엔티티 클래스는 여러 유스 케이스에 포함되며, 일반적으로 이러한 유스 케이스에 존속하는 엔티티 객체 세트를 정의합니다.
-
역할(role)
- 개인의 작동 또는 책임을 정의 또는 소프트웨어 엔지니어링 조직 컨텍스트에서 팀으로서 함께 작업하는 개인의 집합.
-
특정 컨텍스트에 참여하는 엔티티의 이름이 지정된 특정 작동. 역할은 정적(예: 연관 종료) 또는 동적(예: 협업 역할)일 수있습니다.
-
연관(association)
- 인스턴스 사이에서 양방향의 의미론적 연결을 모델화하는 관계.
-
인스턴스 사이에서 연결을 지정하는 둘 이상의 분류자 간의 의미론적 관계.
-
연관 종료(association end)
-
분류자에게 연관을 연결하는 연관의 엔드포인트.
-
연관 클래스(association class)
-
연관 및 클래스 특성이 있는 모델 요소. 연관 클래스는 클래스 특성도 갖고 있는 연관 또는 연관 특성도 갖고 있는 클래스로 보일 수 있습니다.
-
열(column)
- 데이터베이스 내의 테이블의 속성.
-
외관(facade)
- 서브시스템의 클라이언트가 필요로 하는 모든 정보를 구성하고 내보내는 서브시스템 내의 특수 패키지인 스테레오타입의 <<facade>>. 이 패키지에는 인터페이스(인터페이스가 서브시스템에 고유한 경우), 서브시스템 외부의 인터페이스에 대한 구현 관계 및 서브시스템을 사용할 서브시스템의 클라이언트가 요구하는 모든 문서가 포함됩니다.
-
외부 링크(external link)
- 웹 사이트에서 현재 웹 사이트 외부에 위치한 URL에 대한 링크. 외부 링크와 동의어입니다.
-
외부 링크(outside link)
-
외부 링크와 동의어입니다.
-
외부 키(foreign key)
- 다른 테이블의 1차 키를 참조하는 데이터베이스 테이블의 열 또는 열 세트.
-
오류(fault)
- 구현 모델에 있는 컴포넌트가 실패하면 필수 작동을 수행하는 부수적인 조건. 오류는 실패를 관찰하여 식별된 다양한 결함의 근본 원인입니다.
-
오류 기반 테스트(fault-based testing)
- 사전 정의된 오류가 있는지 여부를 보여주기 위해 테스트 메소드 또는 테스트 데이터를 사용하여 컴퓨터 소프트웨어를 테스트하는 기술. 예를 들어, 소프트웨어가 0으로 나누는 오류를 올바르게 처리하여 테스트 데이터가 0을 포함한다는 것을 보여줍니다.
-
오류 모델(fault model)
- 기초로 유사한 오류 개념을 사용하고, 오류를 발견하기 위해 테스트 메소드를 제공하는 컴퓨터 소프트웨어 테스트 모델. 올바른 오류 모델은 오류 또는 근본 원인의 정의, 오류를 생성할 수 있는 관측 가능한 실패, 오류를 발견할 수 있도록 테스트 기술 및 적절한 테스트 데이터의 프로파일을 제공합니다.
-
요구사항(requirement)
- 요구사항은 시스템이 확인해야 하는 조건 또는 성능에 대해 설명합니다. 조건이나 성능은 사용자 요구사항에서 직접 도출되거나 계약서, 표준, 스펙 또는 기타 공식적으로 제공된 문서에 설명되어 있을 수 있습니다. 소프트웨어 요구사항을 참조하십시오.
-
시스템에 필요한 기능, 특성 또는 작동.
-
규칙 소프트웨어 엔지니어링 프로세스에서 규칙의 목적은 시스템이 수행해야 할 작업을 정의하는 것입니다. 가장 중요한 활동은 비전, 유스 케이스 모델 및 추가 스펙 결과물을 개발하는 것입니다.
-
요구사항 관리(requirements management)
- 시스템의 소프트웨어 요구사항을 이끌어내고 조직하며 문서화하고, 이러한 요구사항의 변경에 대해 고객과 프로젝트 팀간의 계약을 맺고 이를 유지보수하기 위한 체계적인 접근 방법.
-
요구사항 속성(requirement attribute)
- 요구사항 및 기타 프로젝트 요소 간에 링크를 제공하는 특정 요구사항에 연관된 정보(예: 우선순위, 스케줄, 상태, 설계 요소, 자원, 비용, 위험).
-
요구사항 유형(requirement type)
- 공통 특성 및 속성을 기본으로 요구사항을 범주화하는 것. 종종 요구사항 유형은 요구사항 소스 또는 영향이 미치는 영역(예: 스테이크홀더 요구사항, 기능, 유스 케이스, 추가 요구사항, 문서 요구사항, 하드웨어 요구사항, 소프트웨어 요구사항 등)을 기초로 합니다. 요구사항은 이들이 나타내는 소프트웨어 품질의 차원(FURPS+)을 기초로 범주화됩니다.
-
요구사항 추적(requirements tracing)
-
요구사항을 기타 요구사항 및 기타 결과물과 이에 연관된 프로젝트 요소에 링크하는 것.
-
요소(element)
-
모델의 최소 구성 단위.
-
요약(abstraction)
- 관심있는 특정 세부사항 세트에만 초점을 둘 수 있도록 불필요한 세부사항은 표시하지 않는 보기 또는 모델을 작성하는 것.
-
다른 유형의 엔티티와 구별되는 엔티티의 가장 중요한 특성. 요약은 보는 사람의 시각과 관련된 경계를 정의합니다.
-
운영 체제 프로세스(operating system process)
- 클래스 및 서브시스템 인스턴스가 상주하고 실행하는 고유한 주소 공간 및 실행 환경. 실행 환경을 하나 이상의 제어스레드로 나눌 수 있습니다. 프로세스 및 스레드를 참조하십시오.
-
워크스테이션(workstation)
- 조작원이 작업하는 입력/출력 장비의 구성. 사용자가 어플리케이션을 수행할 수 있는 단말기 또는 마이크로 컴퓨터로, 일반적으로 메인프레임 또는 네트워크에 연결되어 있습니다.
-
워크플로우(workflow)
- 비즈니스의 개별 액터에게 관측 가능한 결과 값을 생성하는 비즈니스에서 수행되는 활동 순서.
-
워크플로우 세부사항(workflow detail)
- 일부 결과를 수행하기 위해 긴밀히 협업하여 수행되는 활동을 그룹화한 것. 활동은 일반적으로 다른 활동에 대한 입력으로 사용되는 한 활동의 출력을 사용하여 병렬로 또는 반복적으로 수행됩니다. 워크플로우 세부사항은 보다 높은 레벨의 추상적 개념을 제공하고 워크플로우의 이해력을 높일 수 있도록 활동을 그룹화하는 데 사용됩니다.
-
워터폴 모델(waterfall model)
- [IE610.12]에서는 워터폴 모델을 다음과 같이 정의합니다.
"구성 활동(일반적으로 개념 단계, 요구사항 단계, 설계 단계, 구현 단계, 테스트 단계, 설치 및 체크아웃 단계)가 해당 순서대로 수행되는 소프트웨어 개발 프로세스 모델로서, 순서가 중복될 수는 있지만 반복은 거의 없거나 전혀 없습니다.
이 정의는 RUP에 적용되며 "단계"라는 용어는 "규칙"이라는 용어로 바뀌었습니다. RUP에서 규칙은 이름이 지정된 비즈니스 모델링, 요구사항, 분석 & 설계, 구현, 테스트 및 개발입니다. 워터폴 개발 모델에서 규칙은 한 번만 순서대로 발생하며 중복은 거의 발생하지 않거나 전혀 발생하지 않습니다.
-
원격 메소드 호출(RMI: remote mothod invocation)
- JDK 1.1에서 다른 Java 가상 시스템에서 원격 Java 객체에 액세스하는 메소드를 허용하는 분배 Java 프로그램을 작성할 수 있게 하는 API.
-
웹 브라우저(web browser)
- 사용자가 HTML 페이지를 요청하여 표시할 수 있게 하는 클라이언트에서 실행되는 소프트웨어의 일부.
-
웹 사이트(web site)
- 모두 하나의 서버에 있는 웹 시스템. 사용자는 브라우저를 사용하여 웹 사이트를 탐색합니다.
-
웹 서버(web server)
- WWW의 서버 컴포넌트. 이는 웹 브라우저에서의 정보 요청을 처리할 책임이 있습니다. 정보는 서버의 로컬 디스크에서 검색되거나 특정 어플리케이션 기능을수행하기 위해 서버가 호출한 프로그램에 의해 생성되는 파일일 수있습니다.
-
웹 시스템(web system)
- 계층적 또는 선형이 아니라 그래프 양식으로 서로 연결되어 있는 정보 페이지를 포함하는 하이퍼 매체 시스템. 웹 시스템은 브라우저를 통해 액세스할 수 있는 웹 서버로서 자신을 명시할 수 있습니다.
-
웹 어플리케이션(web application)
- 시스템 사용자와 시스템 간의 기본 통신 수단으로서 인터넷을 사용하는 시스템. 웹 시스템 역시 참조하십시오.
-
위임(delegation)
-
메시지에 대한 응답으로 다른 객체에 메시지를 전달하는 객체의 능력. 상속과 대조됩니다.
-
위지트(widget)
- 이 컨텍스트에서는 단추, 화면이동 막대, 레이블, 목록 상자, 메뉴 또는 선택란과 같이 윈도우에 배치할 수 있는 것을 총칭하는 용어.
-
위험(risk)
- 주요 이정표의 성패에 악영향을 미칠 가능성이 높은 현재 진행 중이거나 앞으로 발생할 문제점.
-
유니코드(unicode)
- 현대의 여러 가지 언어에 대한 문자로 된 텍스트를 교환, 처리 및 표시하는 것을 지원하도록 설계된 문자 코딩 시스템. 유니코드 문자는 일반적으로 16비트의 부호없는 정수를 사용하여 인코드됩니다.
-
유스 케이스(use case)
- 조치 순서와 관련하여 시스템 작동에 대한 설명. 유스 케이스는 액터에게 관측 가능한 결과 값을 산출해야 합니다. 유스 케이스는 대체 및 예외 플로우를 비롯하여 "관측 가능한 결과 값"의 생성과 관련된 모든 이벤트 흐름을 포함합니다. 보다 공식적으로 유스 케이스는 유스 케이스 인스턴스 또는시나리오 세트를 정의합니다.
-
변형을 포함하여 시스템(또는 기타 엔티티)이 시스템의 액터와 상호작용하면서 수행할 수 있는 일련의 조치에 대한 스펙. 유스 케이스 인스턴스, 시나리오를 참조하십시오.
-
유스 케이스 구현(use-case realization)
- 유스 케이스 구현은 협업 객체와 관련하여 설계 모델에서 특정 유스 케이스를 구현하는 방법에 대해 설명합니다.
-
유스 케이스 다이어그램(use-case diagram)
-
시스템 내의 액터와 유스 케이스 간의 관계를 보여주는 다이어그램.
-
유스 케이스 모델(use-case model)
-
유스 케이스와 관련하여 시스템의 기능적 요구사항에 대해 설명하는 모델.
-
유스 케이스 보기(use-case view)
- 대부분 구조적으로 중요한 컴포넌트(객체, 타스크, 노드)에 중점을 두면서 시스템에서 중요한 유스 케이스를 수행하는 방법에 대해 설명하는 구조적 보기. RUP에서는 유스 케이스 모델의 보기입니다.
-
유스 케이스 섹션(use-case section)
- 유스 케이스 섹션은 사전 조건, 사후 조건, 서브플로우, 단계 및 텍스트를 포함한 모든 유스 케이스 섹션입니다. 유스 케이스 섹션은 추적성 항목으로 사용될 수 있습니다.
-
유스 케이스 인스턴스(use-case instance)
-
유스 케이스에 지정된 일련의 조치의 성능. 유스 케이스 인스턴스. 유스 케이스 인스턴스는 유스 케이스를 통한 특정 "엔드-투-엔드" 구체적 경로입니다. 유스 케이스의 하나 이상의 가능한 플로우 중에 액터는 특정 사람(액터 인스턴스)으로 바뀌고 특정 값과 응답을 제공하며 단일 경로만을 취합니다. 시나리오, 테스트 시나리오를 참조하십시오.
-
유스 케이스 패키지(use-case package)
- 유스 케이스 패키지는 유스 케이스, 액터, 관계, 다이어그램 및 기타 패키지의 콜렉션입니다. 이 콜렉션을 작게 나누어 유스 케이스 모델을 구성하는 데 사용됩니다.
-
유틸리티(utility)
-
글로벌 변수 및 프로시저를 클래스 선언 양식으로 그룹화하는 스테레오타입. 유틸리티 속성 및 조작은 각각 글로벌 변수 및 글로벌 프로시저가 됩니다. 유틸리티는 기본 모델링 구문이 아니라 프래그래밍 도구입니다.
-
유형(type)
- 공통 특성, 관계, 속성 및 의미론을 공유하는 엔티티 세트에 대한 설명.
-
객체에 적용 가능한 조작과 함께 도메인 인스턴스(객체)를 지정하는 데 사용되는 클래스의 스테레오타입. 유형은 메소드를 포함하지 않을 수도 있습니다. 클래스, 인스턴스를 참조하십시오. 인터페이스와 대조됩니다.
-
유형 표현식(type expression)
-
하나의 유형에 대한 참조로 평가하는 표현식.
-
의미론 변동 지점(semantic variation point)
-
메타모델의 의미론이 변하는 지점. 이는 메타모델 의미론을 자유롭게 해석할 수 있게 합니다.
-
의사소통 다이어그램(communication diagram)
- (1) 공식적으로 이름이 지정된 협업 다이어그램인 의사소통 다이어그램은 객체 간의 상호작용 패턴에 대해 설명합니다. 이는 서로 간의 링크 및 서로 간에 전송된 메시지를 사용하여 상호작용에 참여하는 객체를 표시합니다.
- (2) 이는 분류자 및 연관이 아닌 분류자 역할 및 연관 역할을 포함하는 클래스 다이어그램입니다.
- (3) 의사소통 다이어그램 및 순서 다이어그램은 둘 다 상호작용을 표시하지만 다른 측면을 강조합니다. 순서 다이어그램은 시간 순서를 명확히 표시하나 객체 관계는 명시적으로 표시하지 않습니다. 의사소통 다이어그램은 객체 관계를 명확히 표시하나 시간 순서는 순번으로 가져와야 합니다.
-
분류자 및 연관 또는 인스턴스 및 링크를 사용하여 모델 구조 주위에 구성되어 있는 상호작용을 표시하는 다이어그램. 순서 다이어그램과는 달리 상호작용 다이어그램은 인스턴스 간의 관계를 표시합니다. 순서 다이어그램 및 의사소통 다이어그램은 유사한 정보를 표시하기는 하지만 다른 방법으로 표시합니다. 순서 다이어그램을 참조하십시오.
-
의사소통-연관(communicates-association)
-
액터 클래스 및 유스 케이스 클래스 사이의 연관으로 해당 인스턴스가 상호작용함을 나타냅니다. 연관의 방향은 의사소통(통합 프로세스 규약)의 개시자를 나타냅니다.
-
의사소통 연관(communication association)
-
전개 다이어그램에서 통신을 의미하는 노드 사이의 연관. 전개 다이어그램을 참조하십시오.
-
이디엄(idiom)
- [BUS96]에서는 이디엄을 다음과 같이 정의합니다.
"이디엄은 프로그래밍 언어에 지정된 하위 레벨 패턴입니다. 이디엄은 제공된 언어의 기능을 사용하여 컴포넌트의 특정 측면 또는 이들 간의 관계를 구현하는 방법에 대해 설명합니다. "
또한 구현 패턴이라고도 합니다. 예를 들어, UML로 표현된 구체적 설계를 가져와 이를 Java로 구현할 때, 해당 언어에 대한 반복 구현 패턴이 사용될 수 있습니다. 관용구는 설계 및 구현에 적용됩니다.
-
이름(name)
-
모델 요소를 식별하는 데 사용되는 문자열.
-
이름 공간(namespace)
-
이름을 정의하여 사용할 수 있는 모델의 일부분. 이름 공간 내에서 각 이름은 고유한 의미를 갖습니다. 이름을 참조하십시오.
-
이벤트(event)
-
시간 및 공간에서 위치를 갖고 있는 중요한 발생에 대한 스펙. 상태 다이어그램 컨텍스트에서 이벤트는 전이시킬 수 있는 어커런스입니다.
-
이벤트-메소드 연결(event-to-method connection)
- Bean에 의해 생성된 이벤트에서 Bean 메소드로의 연결. 연결된 이벤트가 발생하면 메소드가 실행됩니다.
-
이정표(milestone)
- 반복이 공식적으로 종료하는 지점. 릴리즈 지점에 해당합니다.
-
인수(argument)
-
런타임 인스턴스에 대해 분석하는 매개변수의 바인딩. 실제 매개변수와 동의어입니다. 매개변수와 대조됩니다.
- 메소드 호출시 매개변수로서 포함되는 데이터 요소 또는 값. 인수는 호출된 메소드가 요청된 조작을 수행하는 데 사용할 수 있는 추가 정보를 제공합니다.
-
인스턴스(instance)
-
클래스 또는 유형의 설명을 충족시키는 개별 엔티티.
-
조작 세트를 적용할 수 있고 조작의 효과를 저장하는 상태를 갖고 있는 엔티티. 객체를 참조하십시오.
-
인터넷(Internet)
- 모두 TCP/IP 프로토콜을 사용하며 1960년대 후반 및 1970년대 초반의 ARPANET으로부터 발전된 거대한 상호 연결된 네트워크 콜렉션.
-
인터넷 프로토콜 주소(internet protocol address)
- 네트워크에 연결된 모든 컴퓨터를 식별하는 숫자로 된 주소(예: 123.45.67.8).
-
인터페이스(interface)
-
클래스 또는 컴포넌트의 서비스를 지정하는 데 사용되는 조작의 콜렉션.
-
요소의 작동을 설명하는 이름이 지정된 조작 세트.
-
인터페이스 상속(interface inheritance)
-
보다 특정한 요소의 인터페이스를 상속하는 것. 구현 상속은 포함하지 않습니다. 구현 상속과 대조됩니다.
-
인트라넷(intranet)
- 공용 인터넷에서 찾은 동일한 유형의 소프트웨어를 사용하나 내부 전용인 회사 또는 조직 내부의 사설 네트워크. 인터넷이 좀더 보편화되면서 인터넷에서 사용되는 대부분의 툴이 사설 네트워크에서도 사용됩니다. 예를 들어, 많은 회사들이 직원들만 사용할 수 있는 웹 서버를 갖고 있습니다.
-
일람표(enumeration)
-
특정 속성 유형의 범위로서 사용되는 이름이 지정된 값의 목록(예: RGBColor = {red, green, blue}). 부울은 {false, true} 세트에 있는 값을 가진 사전 정의된 일람표입니다.
-
일반화(flatten)
-
해체와 동의어입니다.
-
일반화(generalization)
-
보다 일반적인 요소 및 보다 특정한 요소 간의 분류학적 관계. 좀더 특정한 요소는 좀더 일반적인 요소와 완전히 일치하며 자세한 정보가 포함되어 있습니다. 좀더 특정한 요소 인스턴스는 좀더 일반적인 요소가 허용될 경우에 사용될 수 있습니다. 상속을 참조하십시오.
-
일반화 가능 요소(generalizable element)
-
일반화 관계에 참여할 수 있는 모델 요소. 일반화를 참조하십시오.
-
임시 객체(transient object)
-
작성한 프로세스 또는 스레드를 실행하는 동안에만 존재하는 객체.
-
입력(input)
- (1) 프로세스에 의해 사용되는 결과물. 정적 결과물을 참조하십시오.
- (2) 실행 조건이 발생하게 만드는 해당 테스트에 사용되는 값. 입력 값은 테스트 케이스에 정의되어 있습니다.
-
입력 조치(entry action)
-
해당 상태에 도달하기 위해 취해진 전이와 상관없이 상태 시스템의 상태를 입력할 때 실행되는 조치.
-
자
-
자원 파일(resource file)
- Java 프로그램에서 참조하는 파일. 그래프 및 오디오 파일을 예로 들 수 있습니다.
-
작동(behavior)
-
결과뿐만 아니라, 조작 또는 이벤트의 관찰 가능한 효과.
-
작동 기능(behavioral feature)
-
모델 요소의 동적 기능(예: 조작 또는 메소드).
-
작동 모델 측면(behavioral model aspect)
-
시스템에서 인스턴스의 작동을 강조하는 모델 측면(메소드, 협업 및 상태 이력 포함).
-
작업공간(workspace)
- 현재 작업 중인 모든 코드를 포함하는 작업 영역(현재 개정판). 작업 영역에는 표준 Java 클래스 라이브러리 및 기타 클래스 라이브러리도 포함됩니다.
-
장치(device)
-
프로세서에 지원 기능을 제공하는 노드 유형. 임베드된 프로그램(장치 드라이버)을 실행할 수는 있지만 일반용 어플리케이션은 실행할 수 없습니다. 대신 일반용 어플리케이션을 실행하는 프로세서를 제공하기 위해서만 존재합니다.
-
재사용(reuse)
-
결과물을 더 사용하거나 반복해서 사용하는 것.
-
-
기존의 결과물을 사용하는 것.
-
재생(resurrect)
-
직렬화 해제를 참조하십시오.
-
저장소(repository)
-
조항(예: 요구사항, 결과(메트릭), 객체 모델, 인터페이스 및 구현)을 처리하는 중에작동하는 제품(결과물) 출력을 저장하는 장소.
-
전개(deployment)
-
규칙 소프트웨어 엔지니어링 프로세스에서 규칙의 목적은 개발된 시스템을 사용자에게 전이시키는 것입니다. 규칙에는 교육 자료 및 설치 프로시저와 같은 결과물이 포함됩니다.
-
전개(evolution)
- 초기 개발 주기 이후의 소프트웨어의 활동 기간. 제품이 관련된 모든 후속 주기.
-
전개(evolutionary)
- 사용자 요구사항이 완전히 이해되지 않아 각 후속 반복(구현 단계)에서 요구사항을 정제해야 한다는 사실을 인정하는 반복 개발 전략.
-
전개 다이어그램(deployment diagram)
-
런타임 처리 노드 및 해당 노드에 활성화되어 있는 컴포넌트, 프로세스 및 객체의 구성을 표시하는 다이어그램. 컴포넌트는 코드 단위의 런타임 명시를 나타냅니다. 컴포넌트 다이어그램 역시 참조하십시오.
-
전개 단위(deployment unit)
-
그룹으로서 프로세스 또는 프로세서에 할당된객체 또는컴포넌트 세트. 런타임합성 또는집합으로 표시되는 분배 단위.
-
전개 보기(deployment view)
- 하나 이상의 시스템 구성에 대해 설명하는구조적 보기. 이러한 형상에서 컴퓨팅 노드에 대한 소프트웨어컴포넌트(타스크, 모듈)의 맵핑.
-
전개 환경(deployment environment)
- 의도한 용도에 맞게 개발된 소프트웨어를 설치 및 실행용으로 설정된 하드웨어 및 소프트웨어 구성의 특정 인스턴스. 테스트 환경, 환경을 참조하십시오.
-
전달물(deliverable)
-
고객 또는 다른 스테이크홀더에 대한 값, 자료 또는 기타 등을 갖고 있는 프로세스로부터의 출력.
-
전이(transition)
- 소프트웨어를 사용자 커뮤니티로 인도하는 프로세스의 네 번째 단계.
-
첫 번째 상태의 객체가 지정된 특정 조치를 수행하며 지정된 이벤트가 발생하고 지정된 조건이 충족될 때 두 번째 상태로 들어감을 나타내는 두 상태 간의 관계. 이렇게 상태가 변하는 것을 전이가 시작된다고 말합니다.
-
전제 조건(precondition)
- 유스 케이스를 시작할 때 시스템에 대한 제한조건을 정의하는 텍스트로 된 설명.
-
조작을 호출할 때 참이어야 하는 제한조건.
-
정규 매개변수(formal parameter)
-
매개변수와 동의어입니다.
-
정렬(marshal)
-
직렬화 해제와 동의어입니다.
-
정보(stimulus)
-
한 인스턴스에서 다른 인스턴스로 정보를 전달하는것(예: 신호 발생 또는 조작 호출). 신호 수령을 일반적으로 이벤트라고 합니다. 메시지를 참조하십시오.
-
정적 결과물(static artifact)
- 프로세스에서 사용하나 변경되지 않는 결과물.
-
정적 분류(static classification)
-
객체가 유형을 변경할 수 없거나 역할을 변경할 수 없는 일반화의 의미론적 변경. 동적 분류와 대조됩니다.
-
정적 정보(static information)
- 액세스할 때 마다 변경되지 않는 웹 파일.
-
정점(vertex)
-
상태 시스템의 변환에 필요한 소스 또는 대상. 정점은 상태 또는 pseudo 상태일 수 있습니다. 상태, pseudo 상태를 참조하십시오.
-
정제(refinement)
-
이미 특정 세부사항 레벨로 지정된 것의 더 자세한 스펙을 나타내는 관계(예: 설계 클래스는 분석 클래스의 정제).
-
제공업체(supplier)
-
다른 업체에서 호출할 수 있는 서비스를 제공하는 분류자. 클라이언트와 대조됩니다.
-
제안자(originator)
- 제안자는 변경 요청(CR)을 제안하는 사람입니다. 표준 변경 요청 메커니즘에서는 제안자가 현재 문제점에 대한 정보와 변경 요청 양식에 따른 제안 솔루션을 제공해야 합니다.
-
제어 및 관측 지점(point of control and observation)
-
테스트 환경에서 관측을 기록하거나 테스트의 제어 흐름과 관련된 결정을 내리는 테스트의 절차 플로우 중 특정 시점. 밀접하게 관련된 개념인 제어 지점은 필수 제어 결정을 내리기 위해서는 하나 이상의 관측 지점에 대한 세부사항이 필요합니다.
-
제어의 중심(focus of control)
-
직접적으로 또는 하위 프로시저를 통해 객체가 조치를 수행하는 기간을 보여주는 순서 다이어그램에 대한 기호.
-
제어 클래스(control class)
-
클래스는 하나 또는 여러 유스 케이스에 지정된 작동을 모델화하는 데 사용됩니다.
-
제품(product)
- 개발 결과인 소프트웨어 및 이에 연관된 몇 가지 결과물(문서, 릴리즈 매체, 교육).
-
제품 라인 구조(product-line architecture)
- 요소 유형, 이들이 상호작용하는 방법 및 유형에 제품 기능을 맵핑하는 방법을 정의합니다. 일부 구조 요소 인스턴스를 정의하여 진행할 수도 있습니다. 이 용어는 일반적으로 조직 또는 회사 내의 제품 세트에 적용됩니다. [HOF99]를 참조하십시오.
-
제품 지지자(product champion)
- 제품의 비전에 대한 스폰서이며 개발 팀과 고객 사이의 지지자 역할을 수행하는 고위 간부.
-
제한조건(constraint)
-
의미론적 조건 또는 제한사항. 특정 제한조건은 UML에 사전 정의되어 있으며 일부는 사용자가 정의할 수 있습니다. 제한조건은 UML에서 세 개의 확장 가능성 메커니즘 중 하나입니다. 꼬리표 값, 스테레오타입을 참조하십시오.
-
조작(operation)
-
작동에 영향을 미치도록 객체가 요청할 수 있는 서비스. 조작에는 가능한 실제 매개변수를 제한할 수 있는 서명이 있습니다.
-
조직 단위(organization unit)
- 관리에 필요한 컨텍스트를 제공하는 조직의 기본 컴포넌트. 조직 구조는 상위 단위를 계층 구조의 하위에 연관시키고 각 단위는 다른 비즈니스 컴포넌트의 콜렉션에 대한 책임이 있습니다[MARS00]. 비즈니스 시스템을 참조하십시오.
-
조치(action)
-
추상적인 계산 가능 프로시저를 구성하는 실행문의 스펙. 일반적으로 조치를 통해 시스템 상태를 변경시키며 메시지를 객체로 보내거나 속성값 또는 링크를 수정하여 구현될 수 있습니다.
-
조치 상태(action state)
-
최소한의 조치 실행을 나타내는 상태(일반적으로 조작 호출).
-
조치 순서(action sequence)
-
조치 순서로 분석하는 표현식.
-
종료 조치(exit action)
-
해당 상태를 종료하기 위해 취해진 전이와 상관없이 상태 시스템에서 상태를 종료할 때 실행된 조치.
-
종속성(dependency)
-
두 모델링 요소 간의 관계로서, 한 모델링 요소(독립 요소)에 변경사항이 생기면 다른 모델링 요소(종속 요소)에도 영향을 미칩니다.
-
주기(cycle)
-
라이프사이클, 개발 주기와 동의어입니다. 테스트 주기 역시 참조하십시오.
-
주석(comment)
-
요소 또는 요소 콜렉션에 첨부된 주석. 참고에는 의미가 없습니다. 제한조건과 대조됩니다.
-
중단점(break point)
- 실행이 정지되는 컴퓨터 프로그램의 지점.
-
중요 설계 검토(CDR: critical design review)
- 워터폴 라이프사이클에서 세부사항 설계가 완료될 때 보유하는 주요 검토.
-
증가(increment)
- 후속 반복 종료시 두 릴리즈 간의 차이(델타).
-
증분(incremental)
-
반복할 때마다 조금씩 기능을 추가함으로써 시스템을 빌드하는 반복 개발 전략을 규정합니다.
-
지속적 객체(persistent object)
-
객체를 작성한 프로세스 또는 스레드가 없어진 다음에 존재하는 객체.
-
직렬화(serialize)
-
해체와 동의어입니다.
-
직렬화 해제(deserialize)
- 정렬되지 않은 상태로부터 객체를 구축하는 것. 정렬, 재생을 참조하십시오.
-
진척 상황(earned value)
- [MSP97]은 다음과 같이 정의합니다.
"지금까지 수행한 작업의 값 측정. 획득 가치는 발생한 실제 비용이 예산에 맞는지와 타스크가 기준선 계획보다 앞서 있는지 아니면 뒤처져 있는지를 표시하기 위해 원래 측정치와 현재(progress-to-date) 측정치를 사용합니다.
-
집합(aggregation)
- 집합(전체 파트)과 해당 파트 사이에서 전체 파트 관계를 모델화하는 연관.
-
집합(전체 파트)과 컴포넌트 파트 사이에서 전체 파트 관계를 지정하는 특수한 연관 양식. 합성을 참조하십시오.
-
집합(클래스)(aggregate(class))
-
집합(전체 파트) 관계에서 "전체"를 나타내는 클래스. 집합을 참조하십시오.
-
차
-
참가(participate)
-
관계 또는 구체화된 관계에 대한 모델 요소의 연결(예: 클래스는 연관에 참가하고 액터는 유스 케이스에 참가).
-
참조(reference)
-
(1) 모델 요소의 명시적 의미.
- (2) 다른 분류자로의 이동을 용이하게 하는 분류자 내에 지정된 슬롯. 포인터와 동의어입니다.
-
책임(responsibility)
-
분류자의 계약 또는 의무.
-
체크포인트(checkpoint)
- 특정 유형의 형식화된 결과물이 제시하는 조건 세트. 일반적인 형식으로 응답하는 질문 형식으로 설명할 수도 있습니다.
-
초기 유형(primitive type)
-
하위 구조가 없는 사전 정의된 데이터 유형(예: 정수 또는 문자열).
-
초기화(inception)
- 통합 프로세스의 첫 번째 단계. 이 단계에서 구현 단계로 진입하기 위해 수행되고 있는 지점(최소 내부적으로)으로 이전 생성에 대한 제안 요청을 가져옵니다.
-
최종 상태(final state)
-
합성 상태 또는 전체 상태 시스템을 내장시키는 것이 완료되었음을 알려주는 특수한 유형의 상태.
-
추상(abstract)
- 구체적인 목적이나 의도가 없는 추상적인 주제 또는 이와 관련된 것. 적용되거나 구체적이 아니며 이론적입니다. 구체적인 존재와는 다릅니다. 구체적과 대조됩니다. 추상 클래스를 참조하십시오.
- 특정 인스턴스와 연관되지 않은 개념 또는 관념입니다. 추상과 동의어입니다.
- 인수 또는 이론의 요점을 요약한 것. 개요, 개관과 대조됩니다.
-
추상 클래스(abstract class)
-
클래스는 서브클래스 세트에 공통적인 작동을 제공하나 자신은 인스턴스를 갖지 않도록 설계되었습니다. 추상적 클래스는 개념을 나타냅니다. 여기서 파생된 클래스는 개념의 구현을 나타냅니다. 기본 클래스를 참조하십시오. 구체적 클래스와 대조됩니다.
-
추적(trace)
-
다른 요소로부터 한 요소를 도출하기 위한 특정 규칙이 없는 동일한 개념을 나타내는두 요소 간의 이력 또는 프로세스 관계를 나타내는 종속성.
-
추적성(traceability)
- 기타 관련 프로젝트 요소, 특히 요구사항에 관련된 프로젝트 요소에 대해 프로젝트 요소를 추적할 수 있는 기능. 추적성에 포함된 프로젝트 요소를 추적성 항목이라고 합니다.
-
추적성 항목(traceability item)
- 요소 간의 종속성 추적을 보존하기 위해 다른 프로젝트 요소가 명시적으로 추적해야 하는 모든 프로젝트 요소. Rational RequisitePro와 관련하여 이 정의는 다음과 같이 다시 표현될 수있습니다. RequisitePro 요구사항 유형 인스턴스를 사용하여 RequisitePro에 표현되는 프로젝트 요소.
-
출력된 모델(published model)
-
고정되었으며 저장소 초기화 및 다른 모델 정의시 지원하는 데 사용하는 모델. 고정된 모델의 모델 요소는 변경할 수 없습니다.
-
카
-
카디낼러티(cardinality)
-
세트 내의 요소 수. 다양성과 대조됩니다.
-
캡슐(capsule)
- 시스템 제어의 캡슐화된 스레드를 나타내는 특정 설계 패턴. 캡슐은 필수적이며 제한된연관 및 특성의 특정 세트를 가진 스테레오타입 클래스입니다.
-
캡슐 역할(capsule role)
- 캡슐의 협업 또는 구조에서 특정 위치를 차지할 수 있는 캡슐의 스펙 유형을 나타냅니다. 캡슐 역할은 컨테이너 캡슐이 완전히 소유하며 독립적으로 존재할 수는 없습니다. 캡슐의 구조적 분해에는 일반적으로 커넥터에 의해 결합된 협업 캡슐 역할의 네트워크가 포함됩니다.
-
캡슐화(encapsulation)
- 소프트웨어 객체의 내부 표현을 숨기는 것. 객체는 기본 구조를 노출하지 않고 데이터를 조회 및 조작하는 인터페이스를 제공합니다.
-
커플링(coupling)
-
컴포넌트가 서로 종속된 정도. 두 가지 유형의 커플링("느슨함" 및 "밀접함")이 있습니다. 느슨한 커플링은 확장 가능 소프트웨어 구조를 지원하는 데 바람직하나 밀접한 커플링은 최대 성능을 얻는 데 필요합니다. 컴포넌트 간에 교환되는 데이터가 많아지거나 좀더 복잡해지면 커플링이 증가됩니다. 결합(cohension)과 대조됩니다.
-
컨테이너(container)
-
(1) 다른 인스턴스를 포함하기 위해 존재하며 해당 컨텐츠에 액세스하거나 이를 반복하는 조건을 제공하는 인스턴스(예: 배열, 목록 및 세트).
- (2) 다른 컴포넌트를 포함하기 위해 존재하는 컴포넌트.
-
컨테인먼트 계층 구조(containment hierarchy)
-
모델 요소 및 이들 사이에 존재하는 컨테인먼트 관계를 구성하는 이름 공간 계층 구조. 컨테인먼트 계층 구조는 acyclic 그래프를 형성합니다.
-
컨텍스트(context)
-
특정 목적(예: 조작 지정)으로 연관된 모델링 요소 세트의 보기.
-
컴파일 시간(compile time)
-
소프트웨어 모델을 컴파일하는 중에 발생한 것을 참조합니다. 모델링 시간, 런타임을 참조하십시오.
-
컴포넌트(component)
- 정의된 구조 컨텍스트에서 명확한 기능을 이행하는 중요하고, 거의 독립적이며, 대체 가능한 시스템 파트입니다. 인터페이스 세트의 구현을 확인하고 제공하는 컴포넌트.
-
구현을 캡슐화하여 인터페이스 세트를 표시하는 모듈 방식, 전개 가능, 대체 가능 파트입니다. 컴포넌트는 일반적으로 컴포넌트가 상주하는 하나 이상의 분류자(예: 구현 클래스)에 의해 지정되며, 하나 이상의 결과물(예: 2진, 실행 파일 또는 스크립트)에 의해 구현될 수 있습니다. 결과물과 대조됩니다.
-
컴포넌트 다이어그램(component diagram)
-
컴포넌트 간의 조직 및 종속성을 표시하는 다이어그램.
-
컴포넌트 모델(component model)
- 개발자가 프로그램 작성시 결합될 수 있는 재사용 가능한 코드 세그먼트를 정의할 수 있게 하는 구조 및 API. VisualAge for Java는 JavaBeans 컴포넌트 모델을 사용합니다.
-
쿠키(cookies)
- 방문한 웹 사이트 요청시 웹 브라우저가 작성하는 작은 파일. 브라우저는 다음 번 방문시 파일의 컨텐츠를 사이트로 보냅니다.
-
클라이언트/서버(client/server)
- 한 위치에 있는 프로그램이 다른 위치에 있는 프로그램으로 요청을 보낸 다음 응답을 기다리는 분배 데이터 처리에서의 상호작용 모델. 요청하는 프로그램을 클라이언트라고 하고 응답하는 프로그램을 서버라고 합니다.
-
클라이언트(client)
-
다른 분류자에게 서비스를 요청하는 분류자. 제공업체와 대조됩니다.
-
클래스(class)
-
동일한 속성, 조작, 메소드, 관계 및 의미론을 공유하는 객체 세트에 대한 설명. 클래스는 인터페이스 세트를 사용하여 클래스가 환경에 제공하는 조작 콜렉션을 지정합니다. 인터페이스를 참조하십시오.
-
클래스 계층 구조(class hierarchy)
- 단일 상속을 공유하는 클래스 간의 관계. 모든 Java 클래스는 객체 클래스로부터 상속합니다.
-
클래스 다이어그램(class diagram)
-
선언(정적) 모델 요소 콜렉션(예: 클래스, 유형 및 해당 컨텐츠 관계를 표시하는 다이어그램.
-
클래스 라이브러리(class library)
- 클래스 콜렉션.
-
클래스 메소드(class method)
-
메소드를 참조하십시오.
-
키워드(keyword)
- ID로서 사용될 수 없으며 Java용으로 예약된 사전 정의된 단어(예: return).
-
타
-
타스크(task)
-
운영 체제 프로세스, 프로세스 및 스레드를 참조하십시오.
-
타임박스(timeboxing)
- RUP에서 권장하는 반복 스케줄 관리에 대한 접근 방법. 처음에 반복 범위 및 스케줄을 설정하며 개발 타스크가 계획보다 길어질 경우, 원래 계획된 범위를 조정하기 위해 종료일을 못맞추기 보다는 계획된 반복 종료일을 맞출 수 있도록 해당 범위(및 반복하도록 확약된 자원)를 적극적으로 관리하도록 프로젝트 관리자를 격려합니다. RUP에서 늦춰지는 스케줄을 관리하기 위해 자원을 추가하는 것보다는 범위를 줄이는 것이 좋습니다. 이 접근 방식의 모티베이션은 스테이크홀더가 반복 결과를 가시적으로 표시하고 반복을 평가하여 얻은 경험을 후속 반복에 반영할 수 있게 하는 것입니다.
-
탐색 테스트(exploratory testing)
- 테스트 실행에 앞서 테스트 대상에 대한 최소한의 계획이 필요하며 제한된 문서화를 허용하는 컴퓨터 소프트웨어 테스트 기술로, 테스터의 기술 및 지식과 테스트 결과로부터의 피드백에 의존하여 진행 중인 테스트 노력에 대한 조언을 합니다. 탐색 테스트는 종종 한 세션에서 얻은 피드백을 동적으로 후속 세션을 계획하는 데 사용하는 단기 세션에서 실시되기도 합니다. 자세한 정보는 [BAC01a]를 참조하십시오.
-
테스트(test)
- (1) 시스템을 통합하고 테스트하는 것이 목적인 소프트웨어 엔지니어링 프로세스의 규칙.
- (2) 해당테스트 케이스의 인스턴스.
- (3) 테스트 실행.
-
테스트 대상(target-of-test)
-
대상 테스트 항목과 동의어입니다.
-
테스트 도구(test suite)
- 테스트 실행을 순서화하고 테스트 결과를 판별할 수 있는 유용하고 관련된 테스트 로그 정보 세트를 제공할 수 있도록 테스트 스크립트 콜렉션을 그룹화하는 데 사용되는 패키지와 유사한 결과물. 테스트 드라이버, 쉘 스크립트와 동의어입니다.
-
테스트 드라이버(test driver)
- 테스트를 호출하며, 종종 테스트 데이터를 제공하고, 실행을 제어 및 모니터하며, 테스트 결과를 보고하는 데 사용되는 소프트웨어 모듈 또는 어플리케이션. 테스트 드라이버는 자동화된 하나 이상의 테스트 실행 순서를 지정하고 제어합니다. 테스트 도구와 동의어입니다.
-
테스트 모티베이터(test motivator)
- 테스트를 수행할 동기를 제공하는 그 무엇으로, 테스터를 조치로 이동하며 테스트를 추진하게 합니다. 테스트 모티베이터는 제공된 실행 가능 소프트웨어 릴리즈의 해당 측면을 평가하도록 테스터를 자극시킬 내용을 식별하여 가시적으로 만들 수 있게 합니다. 일반적으로, RUP의 테스트 모티베이터는 특정 품질 위험을 나타내며 평가 임무 컨텍스트 범위에 속합니다.
-
테스트 범위(test coverage)
- 일반적으로 테스트 범위는 어디까지인지 또는 어떻게 측정되었는지를 참조하는 데 사용되는 용어. 일반적인 측정 방법이며, 테스트 범위에는 해당 테스트 세트가 해당 시스템 또는 컴포넌트의 테스트 케이스에 지정된 공식 스펙을 해결하는 정도를 고려하는 사항이 포함됩니다.
-
테스트 스크립트(test script)
- 테스트를 구현하는 단계별 콜렉션으로, 실행이 가능합니다. 테스트 스크립트는 수동으로 실행되는 문서 텍스트 지시사항 또는 자동화된 테스트 실행을 가능하게 하는 컴퓨터가 읽을 수 있는 지시사항 양식을 가질 수 있습니다. 테스트 시나리오, 테스트 프로시저를 참조하십시오.
-
테스트 시나리오(test scenario)
- 테스트 실행 컨텍스트에서 관심이 있는 작동을 식별하는 조치의 순서(실행 조건). 테스트 시나리오는 동등한 조치 순서 클래스를 일반화하는 방법을 제공합니다. 이 경우, 클래스는 특정 데이터 값이 아닌 범위와 같은 특징을 기본으로 동등하다고 간주됩니다. 테스트 시나리오는 단일 범위 레벨에서 작동을 기술하며 해당 레벨에서 하나 이상의 작동을 관련시킵니다. 예를 들어, 테스트 시나리오는 하나 이상의 유스 케이스 인스턴스에 관련되거나 여러 유스 케이스에 걸친 작동 인스턴스에 관련될 수 있습니다. 시나리오, 유스 케이스 인스턴스, 테스트 프로시저를 참조하십시오.
-
테스트 아이디어(test idea)
- 실시하는 데 잠재적으로 유용한 테스트를 식별하는 간략한 명령문. 테스트 아이디어는 일반적으로 제공된 테스트의 일면(입력, 실행 조건, 예상 결과)을 나타내나 종종 테스트의 단일 측면만을 해결합니다. 테스트 아이디어는 테스트 이면의 가장 본질적인 아이디어를 제외하고 테스트 작업에 대한 스펙을 포함하지 않은 불완전한 정의라는 점에서 테스트 케이스와는 다릅니다. 테스트 요구사항과 동의어입니다. 테스트 케이스를 참조하십시오.
-
테스트 오라클(test oracle)
- 테스트를 통과할지 또는 실패할지 여부를 알기 위한 전략. 테스트 오라클에는 테스트의 출력을 관찰할 수 있는 매체와 매체가 표시하는 내용을 해석하는 데 필요한 기술 모두가 포함됩니다. 이는 예상 결과에 대해 관찰된 결과를 평가할 수 있는 수단을 제공합니다.
-
테스트 요구사항(test requirement)
- 하나 이상의 테스트의 구현 및 실행을 이행해야 하는 테스트 노력에 제출된 요구사항. 이 용어는 테스트 아이디어라는 용어로 대체되었습니다.
-
테스트 용이성(testability)
- 올바르게 테스트할 대상 테스트 항목의 기능. 대상 항목이 자신에 대한 필수 테스트를 구현할 수 없는 경우, 테스트 용이성이 결여되었을 가능성이 있습니다. 테스트 용이성과 관련하여 논의된 두 가지 기본 측면은 다음과 같습니다. 1) 테스트 대상 항목이 테스트되는 항목에 대해 적절한 지원을 제공할 수 있는 기능. 2) 테스트 팀이 사용하는 프로세스 및 툴의 적합성 - 여기에 적용하기 위해 사용한 특정 전략. 테스트 인터페이스, 테스트 접근 방법을 참조하십시오.
-
테스트 이스케이프(test escape)
- 다운스트림 제품 사용 중에 계속해서 발견되는 결함을 발견하기 위해 테스트 팀이 실시하는 활동 조항 중에 발견되지 않는 오류 또는 결함.
-
테스트 임무(test mission)
-
평가 임무..
-
테스트 주기(test cycle)
- 여러 가지 중에서 테스트 실행 및 평가를 포함하는 테스트 활동 기간. 독립 테스트에 빌드를 사용할 수 있게 된 경우와 해당 빌드에서의 현재 테스트 활동기간이 종료된 경우, 소프트웨어 빌드를 테스트 환경으로 통합하는 시간 간격. 대부분의 반복은 최소 하나의 테스트 주기를 포함하나 반복은 0개 또는 다수의 테스트 주기를 포함할 수 있습니다.
-
테스트 케이스(test case)
-
대상 테스트 항목의 일부 특정 측면을 평가하기 위해 식별된 테스트 입력, 실행 조건, 예상 결과 세트에 대한 스펙(일반적으로 공식적임). 테스트 케이스를 수행하는 데 필요한 양식을 생성하는 테스트에 대해 설명하면서 완전히 형성된 테스트 스펙이라는 점에서 테스트 케이스는 테스트 아이디어와 다릅니다.
-
테스트 프로시저(test procedure)
- 제공된 테스트의 절차적인 측면. 일반적으로 하나 이상의 제공된 테스트 케이스의 설정 및 단계별 실행에 대한 자세한 지시사항 세트입니다. 테스트 프로시저는 테스트 시나리오 및 테스트 스크립트에서 캡처됩니다. 테스트 시나리오, 테스트 스크립트를 참조하십시오.
-
테스트 환경(test environment)
- 알려져 있고 제어된 조건에서 테스트를 실시할 목적으로 설정된 하드웨어 및 소프트웨어 구성의 특정 인스턴스. 개발 환경, 환경 역시 참조하십시오.
-
테이블(table)
- 특정 엔티티 또는 주제에 대한 정보 콜렉션을 표시하는 데이터베이스 요소.
-
테이블 공간(tablespace)
- 데이터베이스 내의 기억장치의 논리적 단위.
-
텔넷(telnet)
- 미국 국방부 가상 단말기 프로토콜.
-
템플리트(template)
-
결과물에 대해 사전 정의된 구조.
-
매개변수화된 소프트웨어 요소와 동의어입니다.
-
통합(integration)
- 별도의 소프트웨어 컴포넌트를 실행 가능한 통합체로 결합하는 소프트웨어 개발 활동.
-
통합 빌드 계획(integration build plan)
- 컴포넌트를 구현하여 특정 반복으로 통합하는 순서를 정의합니다. 일반적으로 반복 계획 내에 포함되어 있습니다.
-
툴 강좌(tool mentor)
- 특정 소프트웨어 툴을 사용하여 특정 프로세스 활동 또는 단계를 수행하는 방법에 대한 실제 안내를 제공하는 설명.
-
트랜잭션(transaction)
- 단일 요청에 의해 시작된 하나 이상의 어플리케이션 프로그램으로 구성된 처리 단위. 트랜잭션을 실행하려면 하나 이상의 타스크를 시작해야 할 수 있습니다.
-
트랜잭션 처리(transaction processing)
- 사용자가 제출한 요청을 수신하는 즉시 처리하는 대화식 어플리케이션을 지원하는 컴퓨팅 양식. 결과는 비교적 짧은 시간에 요청자에게 리턴됩니다. 트랜잭션 처리 시스템은 동시에 복수의 트랜잭션을 처리하는 데 필요한 자원을 공유하도록 관리합니다.
-
트리거(trigger)
- 초기
전이를 제외하고
상태 시스템의 모든 작동은 객체 인터페이스 중 하나에 이벤트가 도착하면 트리거됩니다. 따라서 트리거는 인터페이스에서 전이가 발생하게 하는 이벤트를 정의합니다. 트리거는 트리거링 이벤트가 도착할 것으로 예상되는 인터페이스에 연관됩니다. 더욱이 전이는 복수의 트리거를 가질 수 있으므로 트리거 중 하나를 충족시키는 이벤트에서 전이가 발생하게 됩니다.
-
트리거(데이터베이스)(trigger(database))
- 데이터베이스가 특정 조치 또는 조치 세트를 수행하게 하는 데이터베이스와 연관된 코드.
-
특성(property)
-
요소의 특성을 나타내는 이름이 지정된 값. 특성은 의미론적 영향을 미칩니다. 특정 특성은 UML에 사전 정의되어 있습니다. 다른 특성은 사용자 정의할 수 있습니다. 꼬리표 값을 참조하십시오.
-
특성 - 특성 연결(property-to-property connection)
- 한 객체의 특성에서 다른 객체의 특성으로의 연결. 연결을 참조하십시오.
-
팀 리더(team leader)
- 팀 리더는 프로젝트 관리 및 개발자 간의 인터페이스입니다. 팀 리더는 타스크를 할당하고 모니터하여 완료해야 하는 책임을 갖고 있습니다. 팀 리더는 개발 담당자가 프로젝트 표준을 준수하고 프로젝트 스케줄을 지키도록 해야 할 책임을 갖고 있습니다.
-
파
-
파티션(partition)
-
(1) 활동 그래프: 조치의 책임을 구성하는 활동 그래프의 일부. 스윔레인 역시 참조하십시오.
- (2) 구조:동일한 추상 레벨에 있는 분류자 또는 패키지의 서브세트. 파티션은 구조의 수직적 단편을 나타내는 반면 계층은 수평적 단편을 나타냅니다. 계층과 대조됩니다.
-
패키지(package)
-
요소를 그룹으로 조직화하기 위한 일반적인 목적의 메커니즘. 패키지는 다른 패키지 내에 포함될 수 있습니다.
-
패턴(pattern)
- 해당 컨텍스트에서 유용성이 입증된 반복 문제점에 대한 솔루션 템플리트. 좋은 패턴은 문제점을 정의하는 충돌하는 포스를 성공적으로 해결하며, 한 패턴은 이 포스를 해결하는 방법에 기반하여 다른 패턴을 선택합니다. 패턴을 호출한 효과가 있으려면, 최소한 패턴의 세 가지 실제 어플리케이션이 분명히 있어야 합니다. 소프트웨어의 경우, UML은 다른 측면의 패턴(예: 사용 결과 목록, 사용 예)을 직접 모델화하지는 않지만 매개변수화된 협업을 사용하여 패턴의 표현은 지원할 수 있으므로 텍스트를 사용할 수 있습니다. 소프트웨어 패턴은 값을 해당 매개변수에 바인드하여 초기화됩니다. 패턴은 다음과 같이 다양한 규모 및 추상 레벨(예: 구조적 패턴, 분석 패턴, 설계 패턴, 테스트 패턴 및 이디엄 또는 구현 패턴)로 존재할 수 있습니다.
- Rational Software Architect 사용법에서 주로 단일 메타모델 내에서와 동일한 추상 레벨 내에서 그리고 종종 동일한 모델 내에서 대화식, 부분적 구현화에 맞게 최적화된 변환.
-
팩토리(factory)
- (1) 객체의 작성 또는 초기화 설정을 처리하는 설계 패턴의 특정 그룹을 참조하는 데 공통적으로 사용되는 용어(예: 추상 팩토리 및 팩토리 메소드[GAM94]).
- (2) Java - 지정된 Bean의 새로운 인스턴스를 동적으로 작성할 수 있는 비시각적 Bean.
-
평가 임무(evalution mission)
- 해당 작업 스케줄에 맞게 테스트 팀에 대한 작업 목표의 핵심을 정의하는 간략하고 기억하기 쉬운 명령문. 일반적으로 반복 단위로 재고하며, 평가 임무는 테스트 스테이크홀더가 수익을 달성할 수 있도록 팀의 작업을 생산적으로 유지하도록 하는 데 중점을 둡니다. 임무 명령문의 몇 가지 예로는 중요한 문제점 빨리 찾기, 인식된 품질에 대한 조언 및 스펙 검증이 있습니다.
-
포트(port)
- 포트는 캡슐 인스턴스에 대한 경계 객체로서 메시지를 전달하는 인터페이스 역할을 합니다. 포트는 캡슐과 함께 작성되어 캡슐이 파기될 때 파기된다는 점에서 캡슐이 포트를 "소유"한다고 봅니다. 각 포트는 자체 소유하는 캡슐 인스턴스(모든 파트가 해당 컨테이너와 다른 동일한 정도까지)의 ID 및 상태와 구분되는 ID와 상태를 갖습니다.
- TCP/IP 전문 용어에서 파트는 어플리케이션이 연결할 수 있는 별도로 주소 지정이 가능한 지점입니다. 예를 들어, 기본 HTTP는 포트 80을 사용하고 보안 HTTP(HTTPS)는 포트 443을 사용합니다.
- 다른 시스템 또는 플랫폼에서 사용할 수 있도록(소프트웨어) 수정합니다.
-
포함(include)
-
기본 유스 케이스에서 포함 유스 케이스로의 관계. 포함 유스 케이스에 대해 정의된 작동을 기본 유스 케이스에 대해 정의된 작동에 삽입할 수 있는 방법을 지정합니다.
-
포함 관계(include-relationship)
- 포함 관계는 기본 유스 케이스에서 포함 유스 케이스로의 관계. 포함 유스 케이스에 대해 정의된 작동을 명시적으로 기본 유스 케이스에 대해 정의된 작동으로 삽입하는 방법을 지정합니다.
-
표현식(expression)
-
특정 유형의 값으로 평가하는 문자열. 예를 들어, 표현식 "(7 + 5 * 3)"은 숫자 유형의 값으로 평가합니다.
-
품질(quality)
- 설명되었거나 암시된 요구사항을 충족시킬 수 있는 능력이 있는 제품 또는 서비스의 총체적 기능 또는 특성.
-
품질 보증(quality assurance)
- 제품 또는 서비스가 품질에 대한 해당 요구사항을 충족시킨다는 확신을 제공하는 데 필요한 모든 계획적이고 체계적인 조치.
-
품질 위험(quality risk)
- 소프트웨어 제품의 품질에 악영향을 미칠 가능성이 큰 현재 진행 중이거나 차후에 진행할 문제점. 품질 위험을 평가할 수 많은 품질 차원이 있지만 RUP는 품질의 차원을 논의하기 위한 기초로 FURPS+ 요구사항 모델을 사용합니다.
-
프레임워크(framework)
-
특정 도메인 내의 어플리케이션에게 확장 가능한 템플리트를 제공하는 마이크로 구조.
-
프로세서(processor)
- 하나 이상의 프로세스를 실행할 성능을 갖고 있는 노드의 유형. 일반적으로 여기에는 계산 능력, 메모리, 입/출력 장치가 필요합니다. 노드, 프로세스 및 장치 역시 참조하십시오.
-
프로세스(process)
- (1) 다른 프로세스, 특히 운영 체제 프로세스와 동시에 논리적으로 실행할 수 있는 제어 스레드. 스레드 역시 참조하십시오.
- (2) 목표에 도달할 수 있도록 부분적으로 순서화된 단계 세트. 소프트웨어 엔지니어링에서 목표는 소프트웨어 제품을 빌드하거나 기존의 제품을 강화하는 것입니다. 프로세스 엔지니어링에서 목표는 프로세스 모델을 개발하거나 강화하는 것입니다. 비즈니스 엔지니어링에서는 비즈니스 유스 케이스에 해당합니다.
-
(1) 운영 체제에서 동시성 및 실행의 중량 단위. 스레드와 대조되며 일반 및 간단한 프로세스를 포함합니다. 필요한 경우, 스테레오타입을 사용하여 구현을 구분합니다.
- (2) 소프트웨어 개발 프로세스. 시스템을 개발할 단계 및 가이드라인.
- (3) 알고리즘을 실행하거나 동적으로 무엇인가를 처리하는 것.
-
프로세스 보기(process view)
- 시스템 동시성 측면(타스크(프로세스) 및 해당 상호작용)에 대해 설명하는 구조적 보기.
-
프로젝션(projection)
-
세트에서 서브세트로의 맵핑.
-
프로젝트(project)
- 프로젝트는 사람에 의해 수행되고, 한정된 자원에 의해 제한되며, 계획, 실행 및 제어됩니다. 프로젝트는 고유한 제품 또는 서비스를 작성하기 위해 취하는 일시적 노력입니다. 일시적이란 모든 프로젝트에 확정된 시작과 확정된 끝이 있음을 의미합니다. 고유하다는 것은 제품 서비스가 몇 가지 차별화되는 면에서 모든 유사한 제품 및 서비스와 다르다는 것을 의미합니다. 프로젝트는 종종 조직의 비즈니스 전략을 수행하는 중요한 컴포넌트입니다.
-
프로젝트 관리자(project manager)
- 프로젝트에 대해 전반적인 책임이 있는 역할. 프로젝트 관리자는 타스크가 프로젝트 스케줄, 예산 및 품질 요구사항에 따라 스케줄, 할당 및 완료되었는지를 확인해야 합니다.
-
프로토콜(protocol)
-
캡슐 간의 통신에 사용되는 호환 가능한 메시지 세트의 스펙. 프로토콜은 들어오고 나가는 메시지 유형 세트(예: 조작, 신호), 선택적으로 프로토콜에 참여하는 참가자가 제공해야 하는 추상적 작동을 지정하는 메시지 및 상태 시스템의 필수 순서를 정의하는 순서 다이어그램 세트를 정의합니다.
-
프로토콜(TCP/IP)(protocol(TCP/IP))
- 인터넷을 통해 세계 전역에 컴퓨터 메시지를 전달하는 기본 프로그래밍 기초. 인터넷을 정의하는 프로토콜 모음. 원래는 UNIX 운영 체제용으로 설계되었으며 TCP/IP 소프트웨어는 이제 모든 유형의 컴퓨터 운영 체제에 사용 가능하게 되었습니다. 인터넷을 사용하기 위해서는 컴퓨터에 TCP/IP 소프트웨어가 설치되어 있어야 합니다.
-
프로토타입(prototype)
-
변경 요청 및 구성 제어를 따르지 않아도 되는 릴리즈.
-
프록시(proxy)
- FTP의 Telnet과 같이 특정 네트워크 어플리케이션에 대해 한 네트워크에서 다른 네트워크로의 어플리케이션 게이트웨이. 예를 들어, 방화벽의 프록시 Telnet 서버는 사용자의 인증을 수행한 다음 마치 거기에 없었던 것처럼 프록시를 통해 트래픽을 흘러가게 합니다. 방화벽에 더 많은 로드가 발생되기 때문에 기능은 클라이언트 워크스테이션이 아닌 방화벽에서 수행됩니다. Socks와 비교하십시오.
-
플랫폼(platform)
- [OMG03]에서는 이를 다음과 같이 정의합니다.
"플랫폼에 종속된 서브시스템은 플랫폼에서 제공하는 기능을 구현하는 방법에 대한 세부사항과 관계없이 사용할 수 있는 지정된 사용 패턴 및 인터페이스를 통해 관련된 기능 세트를 제공하는 서브시스템/기술 세트. "
-
필드(field)
-
속성을 참조하십시오.
-
하
-
하위(child)
-
일반화 관계에서 다른 요소(상위)를 특수화한 것. 서브클래스, 서브유형 역시 참조하십시오. 상위와 대조됩니다.
-
하이퍼링크(hyperlink)
- 누르면 페이지의 다른 영역 또는 다른 웹 페이지에 연결되는 웹 페이지의 영역.
-
하이퍼텍스트(hypertext)
- 다른 텍스트에 대한 숨겨진 링크를 포함하는 문서의 텍스트. 하이퍼텍스트 단어에서 문서를 누르면 링크에 지정된 텍스트로 이동합니다. 하이퍼텍스트는 동일한 문서의 다른 곳에 있는 관련 참조로 이동하기 위해 Windows 도움말 프로그램 및 CD 백과사전에 사용됩니다. 무엇보다도 하이퍼텍스트에 대한 놀라운 사실은 전세계의 모든 웹 문서(웹을 통해 HTTP 사용)에 링크할 수 있으며, 마우스를 한 번만 누르면 전세계를 이동할 수 있다는 점입니다.
-
하이퍼텍스트 마크업 언어(hypertext markup language)
- WWW(World Wide Web)에 하이퍼텍스트 문서를 빌드하는 데 사용되는 기본 언어. 이는 기본적이고 일반적인 ASCII 텍스트 문서에 사용되나 이러한 문서를 NetScape와 같은 웹 브라우저로 해석(렌더링)할 경우 문서에 형식화된 텍스트, 색상, 다양한 글꼴, 그래픽 이미지, 특수 효과, 다른 인터넷 위치로의 하이퍼텍스트 점프 및 정보 양식을 표시할 수 있습니다.
-
합성(composition)
-
전체의 일부로서 강력한 소유권 및 동시에 발생하는 라이프사이클을 가진 집합 연관 양식. 고정되지 않은 다양성을 가진 파트는 합성 자체 이후에 작성될 수 있으나, 일단 작성되면 함께 생성되었다가 함께 소멸합니다. 즉, 수명을 공유합니다. 이러한 파트는 합성이 소멸되기 전에 명시적으로 제거될 수 있습니다. 작성을 반복할 수 있습니다. 합성 집합을 참조하십시오.
-
합성[클래스](composite [class])
-
합성 관계를 사용하여 하나 이상의 클래스에 관련된 클래스. 합성을 참조하십시오.
-
합성 Bean(composite bean)
- 여러 Bean으로 구성된 Bean. 합성 Bean은 비주얼 bean, 비주얼하지 않은 bean 또는 둘 다를 포함할 수 있습니다. bean 역시 참조하십시오.
-
합성 상태(composite state)
-
동시(결합) 서브상태 또는 순차적(해체) 서브상태로 이루어진 상태. 서브상태를 참조하십시오.
-
합성 서브상태(composite substate)
-
동일한 합성 상태에 포함되어 있는 다른 서브상태와 동시에 보유할 수 있는 서브상태. 합성 상태를 참조하십시오. 영역과 동의어입니다.
-
합성 집합(composite aggregation)
-
합성과 동의어입니다.
-
해석할 수 없음(uninterpreted)
-
UML에 의해 구현이 지정되지 않은 유형에 대한 위치 표시기. 모든 해석되지 않은 값에는 해당하는 문자열 표현이 있습니다. CORBA를 참조하십시오.
-
해체(de-marshal)
- 바이트 스트림으로 기록할 수 있도록 객체를 해체하는 것. 일반화, 직렬화를 참조하십시오.
-
해체 서브상태(disjoint substate)
-
동일한 합성 상태에 포함되어 있는 다른 서브상태와 동시에 보유할 수 없는 서브상태. 합성 상태를 참조하십시오. 동시 서브상태와 대조됩니다.
-
핵심 메커니즘(key mechanism)
- 시스템 요소 간의 상호작용 패턴과 관련하여 구조적 패턴을 구현하는 방법에 대한 설명. 일반적으로 소프트웨어 구조 문서에 표시됩니다.
-
협업(collaboration)
- (1) 컨텍스트 내에서 일부 작동을 구현하기 위해 상호작용하는 객체 콜렉션에 대한 설명입니다. 일부 목적을 수행하기 위해 어셈블된 협업 객체 집단에 대해 설명합니다.
- (2) 객체 네트워크 내에서 메시지 교환시, 보다 전체적인 작동 보기를 캡처합니다.
- (3) 협업은 세 가지 주요 구조 기반 계산(데이터 구조, 제어 플로우 및 데이터 플로우)의 일관성을 보여줍니다.
- (4) 협업에는 정적 및 동적인 파트가 있습니다. 정적 파트는 협업 초기화시 객체 및 링크가 수행하는 역할을 설명합니다. 동적 파트는 계산을 수행하기 위해 협업에서 시간 경과에 따른 메시지 플로우를 표시하는 하나 이상의 동적 상호작용으로 구성됩니다. 협업은 동적 작동을 설명하는 메시지 세트를 갖고 있습니다.
- (5) 메시지와의 협업이 상호작용입니다.
-
특정 방법으로 특정 역할을 수행하는 분류자 및 연관 세트를 사용하여 조작 또는 분류자(예: 유스 케이스)를 구현하는 방법에 대한 스펙. 협업은 상호작용을 정의합니다. 상호작용을 참조하십시오.
-
협업 다이어그램(collaboration diagram)
- 이 용어는 UML 2.0에서 의사소통 다이어그램으로 변경되었습니다.
-
형상(configuration)
- (1) 일반: 기능 단위의 성격, 숫자 및 주요 특성에 정의된 대로 시스템 또는 네트워크 정렬. 하드웨어 또는 소프트웨어 형상에 적용됩니다.
- (2) 시스템 또는 시스템 컴포넌트의 특정 버전을 정의하는 요구사항, 설계 및 구현. 형상 관리를 참조하십시오.
-
형상 관리(configuration management)
- [ISO95] 항목 식별, 정의 및 기준선 지정, 이러한 항목의 수정 및 릴리즈 제어, 항목 및 수정 요청 상태 보고 및 기록, 항목의 완성도, 일관성 및 정확성 확인 및 기억장치 제어, 항목 처리와 전달을 할 목적으로 사용되는 지원 프로세스.
-
형상 항목(configuration item)
- [ISO95] 일반 사용 기능을 충족시키고 제공된 참조 시점에서 고유하게 식별될 수 있는 형상 내의 항목.
-
호출(call)
-
분류자에서 조작을 호출하는 조치 상태.
-
홈 페이지(home page)
-
시작 페이지를 참조하십시오.
-
확약(commit)
- 자원(트랜잭션 또는 데이터)에 적용된 변경사항을 영구적으로 만들기 위해 작업 단위를 종료하는 조작.
-
확장(extend)
-
확장 유스 케이스에서 기본 유스 케이스로의 관계. 확장 유스 케이스에 대해 정의된 작동을 기본 유스 케이스에 대해 정의된 작동으로 삽입할 수 있는 방법을 지정합니다.
-
확장 관계(extend-relationship)
- 유스 케이스 클래스 A에서 유스 케이스 클래스 B로의 확장 관계는 B의 인스턴스가 A가 지정된 작동(확장에 지정된 특정 조건에 한함)을 포함할 수 있음을 의미합니다. 단일 대상 유스 케이스의 여러 확장자가 지정한 작동이 단일 유스 케이스 인스턴스 내에서 발생할 수 있습니다.
-
환경(environment)
- (1) 시스템을 개발하는 환경을 정의하고 관리하는 것이 목적인 소프트웨어 엔지니어링 프로세스의 규칙. 여기에는 프로세스 설명, 형상 관리 및 개발 툴이 포함됩니다.
- (2) 최종 제품이 전개된 소프트웨어 개발, 소프트웨어 테스트를 목적으로 설정된 하드웨어 및 소프트웨어 형상의 특정 인스턴스. 테스트 환경, 개발 환경 역시 참조하십시오.
-
활동(activity)
-
역할에게 수행하도록 요청할 수 있는 작업 단위.
-
활동 그래프(activity graph)
-
하나 이상의 분류자를 포함하는 프로세스를 모델화하는 데 사용되는 상태 시스템의 특수한 케이스. 상태 차트 다이어그램과 대조됩니다. 활동 다이어그램과 동의어입니다.
-
활동 기반 관리(ABM: activity-based management)
- 활동 관리 대신 고객 가치 및 회사 이익을 달성하는 데 중점을 두는 광범위한 규칙. 이는 중요한 정보로 활동 기반 비용을 참조합니다.
-
활동 기반 비용(ABC: activity-based costing)
- 활동, 자원 및 비용 객체의 비용 및 성능을 측정하는 방법. 자원은 활동에 지정되고, 활동은 용도를 기반으로 비용 객체에 지정됩니다. 비용을 기반으로 하는 활동은 활동에 대한 비용 드라이버의 일시적인 관계를 인지합니다.
-
활동 서버 페이지(ASP: active server page)
- 활동 서버 페이지(Microsoft(R)). 웹 어플리케이션에 동적 작동을 제공하는 기술 메커니즘입니다.
-
활성 객체(active object)
-
스레드를 소유하며 제어 활동을 초기화할 수 있는 객체. 활성 클래스의 인스턴스.
-
활성 클래스(active class)
-
시스템에서 스레드 제어를 표시하는 클래스.
-
인스턴스가 활성 객체인 클래스. 활성 객체를 참조하십시오.
-
활성화(activation)
-
조치 실행.
-
A
-
ABC
-
활동 기반 비용을 참조하십시오.
-
ABM
-
활동 기반 관리를 참조하십시오.
-
ACL
- 액세스 제어 목록.
-
API
-
API를 참조하십시오.
-
API(Application Programming Interface)
- 어플리케이션이 서로 통신 있게 하는 소프트웨어 인터페이스. API는 기초 운영 체제 또는 서비스 프로그램이 제공하는 특정 기능 및 서비스를 확보할 수 있도록 어플리케이션에서 코드화될 수 있는 프로그래밍 언어 구문 또는 명령문 세트입니다.
-
APPC
-
APPC(Advanced Program-to-Program Communication)를 참조하십시오.
-
APPC(Advanced Program-to-Program Communication)
- IBM 환경에서 기본적으로 사용되는 통신 프로토콜.
-
ASCII
-
ASCII를 참조하십시오.
-
ASCII(American Standard Code for Information Interchange)
- 정보 교환을 위한 미국 표준 코드. 대부분의 PC 및 UNIX 시스템에서 사용되는 8비트 문자 인코딩 스키마. 이는 7비트의 ASCII 표준을 대신합니다.
-
ASP
-
활성 서버 페이지를 참조하십시오.
-
B
-
BASIC
- 초보자가 사용할 수 있도록 다목적의 기호로 된 명령어 코드, 프로그래밍 언어. VB를 참조하십시오.
-
Bean
- 어플리케이션을 빌드하는 데 사용되는 작은 컴포넌트. JavaBean을 참조하십시오.
-
beaninfo
- Bean의 특성, 이벤트 및 메소드에 대한 정보를 검색하기 위해 액세스할 수 있는 메소드 세트를 정의하는 Bean과 한 벌인 클래스.
-
C
-
CBD
-
CBD(Component-Based Development)를 참조하십시오.
-
CBD(Component-Based Development)
-
컴포넌트로부터 어셈블된 소프트웨어 집중 시스템의 작성 및 전개뿐만 아니라 이러한 컴포넌트의 개발 및 결과.
-
CCB
-
변경 제어 보드를 참조하십시오.
-
CDR
-
중요 설계 검토를 참조하십시오.
-
CGI
-
공통 게이트웨이 인터페이스를 참조하십시오.
-
CIM(Computation Independent Model
- [OMG03]에서는 다음과 같이 정의합니다.
"계산 독립 모델은 계산 독립 관점에서 본 시스템에 대한 보기입니다. CIM은 시스템 구조에 대한 세부사항을 표시하지 않습니다. CIM은 스펙에 사용되는 질문에서 도메인 경험자에게 익숙한 도메인 모델 및 어휘라고 합니다. "
-
CLI
-
CLI(Call-Level Interface)를 참조하십시오.
-
CLI(Call-Level Interface)
- 데이터베이스 액세스용으로 호출 가능한 API. 이는 임베드된 SQL API의 대안입니다. 임베드된 SQL과 달리, CLI는 사용자가 프리컴파일 또는 바인딩할 필요가 없지만 런타임시 SQL문 및 관련 서비스를 처리하는 표준 기능 세트를 제공해야 합니다.
-
CM
-
형상 관리를 참조하십시오.
-
COBOL
- Common Business Oriented Language입니다.
-
COBRA(Common Object Request Broker Architecture)
- 인프라스트럭처를 제공하는 소프트웨어 버스(ORB)를 정의하는 미들웨어 스펙.
-
COM
- 컴포넌트 객체 모델(Microsoft). DEC 및 Microsoft사의 소프트웨어 구조로서 ObjectBroker 및 OLE의 통합을 가능하게 합니다. Microsoft에서 나중에 COM을 DCOM으로 발전시켰습니다.
-
CORBA
-
COBRA(Common Object Request Broker Architecture)를 참조하십시오.
-
CR
-
변경 요청을 참조하십시오.
-
CRC(Class-responsibility collaborators)
- 클래스-책임 협업자. 이는 원래 Ward Cunningham 및 Kent Beck이 객체가 시스템에서 수행해야 하는 작업(책임)을 정의하고 이러한 책임을 이행하는 데 관련된 기타 객체(협업자)를 식별하기 위해 제안한 것으로, 객체 지향 개발에 사용되는 기술입니다. 기술은 [WIR90]에 설명되어 있습니다. CRC 카드는 보통 인덱스 카드를 사용하여 이러한 결과를 캡처하는 방법입니다.
-
CRUPIC STMPL
- 이 머리글자어는 제품 요구사항 정의 및 제품 품질 평가 모두에 사용할 수 있는 범주를 나타냅니다. 두 개의 범주로 나뉩니다. 첫 번째 범주는 조작 범주(기능, 신뢰성, 사용성, 성능, 설치 가능성, 호환성)를 나타내고 두 번째 범주는 개발 범주(지원 가능성, 테스트 용이성, 유지보수성, 이식성, 로컬화 가능성)를 나타냅니다. FURPS+ 역시 참조하십시오.
-
D
-
DASD
-
DASD(Direct Access Storage Device)를 참조하십시오.
-
DASD(Direct Access Storage Device)
- 디스크 드라이브와 같이 기억장치에서 직접 액세스할 수 있는 장치(순차적으로 액세스되는 테이프 드라이브와는 다름).
-
DBA
- 데이터베이스 관리자.
-
DBCS
-
2바이트 문자 세트를 참조하십시오.
-
DBMS
-
데이터베이스 관리 시스템을 참조하십시오.
-
DCE
-
DCE(Distributed Computing Environment)를 참조하십시오.
-
DCE(Distributed Computing Environment)
- 분산 컴퓨팅 환경. 컴퓨터 업계에서 분산 컴퓨팅에 대한 사실 표준으로 채택되었습니다. DCE는 다양한 벤더가 제공한 컴퓨터가 투명하게 통신하고 컴퓨팅 전원, 파일, 프린터 및 네트워크의 기타 객체와 같은 자원을 공유할 수 있게 해줍니다.
-
DCOM
- 분산 컴포넌트 객체 모델(Microsoft). 네트워크를 통해 분배된 객체를 지원하도록 Microsoft에서 COM을 확장한 것.
-
DLL
-
DLL(dynamically linked library)을 참조하십시오.
-
DLL(Dynamically Linked Library)
- 링크시(컴파일의 최종 단계)보다는 런타임시 프로그램에 바인드되는 실행 가능한 코드 및 데이터를 포함하는 파일. 이는 사용하는 루틴의 사본을 포함하는 각 태스크가 아닌 여러 태스크 간에 동일한 라이브러리 코드 블록을 공유할 수 있음을 나타냅니다. C++ Access Builder는 Java 프로그램이 C++ DLL에 액세스할 수 있게 하는 bean 및 C++ 랩퍼를 생성합니다.
-
DMZ
-
DMZ(demilitarized zone)를 참조하십시오.
-
DMZ(demilitarized zone)
- 이 용어는 이제 서브네트워크를 설명하기 위해 업계에서 공통적으로 사용되고, 외부 인터넷 및 회사 내부 인터넷 모두에서 방화벽에 의해 보호되는 웹 서버에 일반적으로 사용됩니다.
-
DNS
-
도메인 이름 서버를 참조하십시오.
-
E
-
e-business
- (1) 인터넷과 같은 전자 매체를 통한 비즈니스 트랜잭션.
- (2) 내부 비즈니스 프로세스(인트라넷 경유), 해당 비즈니스 관계(익스트라넷 경유) 및 상품, 서비스 및 정보의 구매 및 판매(전자 상거래 경유)에 인터넷 기술 및 네트워크 컴퓨팅을 사용하는 비즈니스.
-
EJB
-
엔터프라이즈 Javabean을 참조하십시오.
-
ERP(Enterprise Resource Planning)
- 엔터프라이즈 자원 계획.
-
F
-
FTP
-
FTP(File Transfer Protocol)를 참조하십시오.
-
FTP(File Transfer Protocol)
- 컴퓨터 간에 파일을 전송할 수 있게 하는 기본적인 인터넷 기능. 이를 사용하여 사용자의 컴퓨터에서 원격, 호스트 컴퓨터로 파일을 업로드할뿐 아니라 원격, 호스트 컴퓨터로부터 파일을 다운로드할 수도 있습니다.
-
FURPS(Functionality, usability, reliability, performance, supportability + others)
- 기능성, 사용성, 신뢰성, 성능, 지원성 및 기타. [GRA92]에 설명되어 있으며, 이 머리글자어는 제품 품질 평가 및 제품 요구사항 정의 모두에 사용할 수 있는 범주를 나타냅니다. 대체 범주 메소드도 사용될 수 있습니다. CRUPIC STMPL을 참조하십시오.
-
G
-
GUI
-
GUI(Graphical User Interface)를 참조하십시오.
-
GUI(Graphical User Interface)
- 사용자가 명령을 입력하기 보다는 그래픽 기능을 조작하여 프로그램과 통신할 수 있게 하는 인터페이스 유형. 일반적으로 GUI는 그래픽, 지정 장치, 메뉴 표시줄 및 기타 메뉴, 중복되는 윈도우 및 아이콘의 조합을 포함합니다.
-
H
-
hotjava
- Sun Microsystems, Inc.에서 개발한 Java가 가능한 웹 및 인터넷 브라우저. HotJava는 Java로 작성됩니다.
-
HTML
-
하이퍼텍스트 마크업 언어를 참조하십시오.
-
HTML 브라우저(HTML browser)
-
웹 브라우저를 참조하십시오.
-
HTTP(Hypertext transport protocol)
- 하이퍼텍스트 전송 프로토콜.
-
HTTP 요청(HTTP request)
- 웹 브라우저에 의해 시작되어 HTTP를 준수하는 트랜잭션. 서버는 일반적으로 HTML 데이터를 사용하여 응답하나 다른 유형의 객체도 보낼 수 있습니다.
-
I
-
I/T(Information Technology)
- 정보 기술.
-
IDE
-
IDE(Integrated Development Environment)을 참조하십시오.
-
IDE(Integrated Development Environment)
- 편집기, 컴파일러 및 디버거를 비교하는 소프트웨어 프로그램.
-
IE
- Internet Explorer(Microsoft).
-
IEEE
- Institute of Electrical and Electronics Engineers, Inc.
-
IIOP
-
IIOP(Internet Inter-ORB Protocol)를 참조하십시오.
-
IIOP(Internet Inter-ORB Protocol)
- TCP/IP 네트워크를 통해 GIOP(General Inter-ORB Protocol) 메시지를 교환하는 방법을 정의하는 업계 표준 프로토콜. IIOP는 인터넷 자체를 다른 ORB가 브릿지할 때 사용할 수 있는 백본 ORB로서 사용할 수 있게 합니다.
-
IMAP4
- Internet Message Access Protocol - 버전 4.
-
IP
-
인터넷 프로토콜을 참조하십시오.
-
IP(Internet Protocol)
- 기본 인터넷 기능을 제공하는 프로토콜.
-
IPSec
-
IP 보안 프로토콜을 참조하십시오.
-
IPSec(IP security protocol)
- 네트워크 계층에 암호 작성 보안 서비스를 제공합니다.
-
IP 번호(IP number)
- 점으로 분리된 네 자리 수로 구성된 고유한 번호인 인터넷 주소는 점으로 분리된 네 자리 수 표시라고도 합니다(예: 123.45.67.8). 모든 인터넷 컴퓨터는 IP 번호를 갖고 있으며 대부분의 컴퓨터는 점으로 분리된 네 자리 수 표시에 대한 맵핑 또는 별명인 하나 이상의 도메인 이름도 갖고 있습니다.
-
ISAPI(Internet Server API)
- 인터넷 서버 API.
-
ISO
- 표준화를 위한 국제 조직.
-
ISP(Internet Service Provider)
- 인터넷 서비스 제공업체. 다른 회사 또는 개인에게 인터넷에 대한 액세스 또는 실제 위치를 제공하는 회사. 대부분의 ISP는 IAP(Internet Access Provider)이기도 합니다.
-
J
-
JAR
-
JAR(java archive)를 참조하십시오.
-
JAR(Java archive)
- 여러 파일을 하나로 묶는 플랫폼 독립 파일. 압축, 다운로드 시간 절감 및 보안 용도로 JAR 파일을 사용합니다. JAR 형식은 Java로 작성되기 때문에 JAR 파일은 완전히 확장 가능합니다.
-
Java
- Java는 인터넷을 통해 컴퓨터에 안전하게 다운로드하여 컴퓨터 또는 파일에 바이러스 또는 기타 손상을 주지 않고 즉시 실행할 수 있는 프로그램을 작성하도록 특별히 설계된 Sun Microsystems사에서 창안한 프로그래밍 언어입니다. 애플릿이라고 하는 작은 Java 프로그램을 사용하여 웹 페이지에 애니메이션, 계산기, 기타 가상 트릭과 같은 기능을 포함할 수 있습니다. 일반 컴퓨터 프로그램이 수행할 수 있는 거의 모든 것을 수행하는 Java 프로그램을 작성하여 웹 페이지에 Java 프로그램을 포함시킬 수있기 때문에 웹에 아주 다양한 기능을 추가할 수 있을 것으로 기대합니다.
-
javabean
- javabean은 별도로 개발된 다른 Bean과 함께 하나의 어플리케이션에 통합될 수 있는 컴포넌트입니다. 이 단일 어플리케이션은 브라우저 내에 또는 ActiveX 컴포넌트로서 독립형으로 사용될 수 있습니다. Javabeans는 단일 프로세스에 대해 로컬로 사용하게 되어 있으므로 런타임시 종종 볼 수 있습니다. 이 비주얼 컴포넌트는 단추, 목록 상자, 그래픽 또는 도표일 수 있습니다.
-
JDBC
-
JDBC(Java Database Connectivity)를 참조하십시오.
-
JDBC(Java Database Connectivity)
- JDK 1.1에서 프로그램이 이 표준을 준수하는 데이터베이스에 액세스할 수 있게 API를 정의하는 스펙.
-
JDK
-
JDK(Java Development Kit)를 참조하십시오.
-
JDK(Java Development Kit)
- JDK는 Sun Microsystems에서 사용 허가를 받은 개발자에게만 사용 가능합니다. 각 JDK 릴리즈에는 Java 컴파일러, JVM(Java Virtual Machine), Java 클래스 라이브러리, Java 애플릿 표시기, Java 디버거 및 기타 툴이 포함됩니다.
-
JFC
-
JFC(Java Foundation Class)를 참조하십시오.
-
JFC(Java Foundation Class)
- Netscape, Sun 및 IBM에서 개발했으며 JFC는 Java 어플리케이션에 대한 인터페이스를 개발하는 데 도움이 되는 기초 단위입니다. 이는 Java 어플리케이션이 기존의 운영 체제 시스템과 보다 완벽히 상호작용할 수 있게 합니다.
-
JIT(Just in time)
- 적시 생산.
-
JVM(Java Virtual Machine)
- Java 가상 시스템. 바이트 코드로 컴파일되어 일반적으로 ".class" 파일에 저장되는 Java 프로그램을 해석하는 소프트웨어의 스펙. JVM 자체는 C로 작성되며 대부분의 플랫폼에서 실행되도록 이식할 수 있습니다. JVM 명령어 세트는 스택 지향적이며 명령어 길이는 가변적입니다. 일부 다른 명령어 세트와 달리 JVM은 객체 메소드 호출(다른 명령어 세트의 서브루틴 호출과 유사함)에 필요한 명령어 세트를 포함함으로써 직접적으로 객체 지향 프로그래밍을 지원합니다.
-
K
-
L
-
LAN(local area network)
-
근거리 통신망.
-
LDAP(Lightweight Directory Access Protocol)
- 온라인 디렉토리 서비스에 액세스하기 위한 프로토콜. LDAP은 TCP/IP를 통해 실행 중인 디렉토리를 갱신하고 검색하는 비교적 간단한 프로토콜을 정의합니다.
-
M
-
MDA(Model Driven Architecture)
- [OMG03]에서는 이를 다음과 같이 정의합니다.
"특정 기술 플랫폼의 해당 기능 구현 스펙에서 기능 스펙을 분리하는 IT 시스템 스펙에 대한 접근 방법."
-
MDD(Model Driven Development)
- 모델을 단순히 중간 개발 결과물로 보지 않고 작동 시스템을 생성할 수 있는 정확한 설명으로 보는 시스템 개발에 대한 접근 방법(모델 설명에 엄격한 규칙이 필요하기는 하지만 향상된 추상 레벨의 모델에서 작업함).
-
MIB(Management Information Base)
- 관리 정보 베이스.
-
MIME
-
MIME(Multipurpose Internet Mail Extension)을 참조하십시오.
-
MIME(Multipurpose Internet Mail Extension)
- 텍스트, 이미지, 오디오 및 비디오를 지원하는 인터넷 표준.
-
MOF
-
OMG 정의 기술. MOF(Meta-Object Facility) 스펙은 상호 작동 가능 메타모델 및 해당 모델 세트를 정의 및 조작하는 데 사용될 수 있는 CORBA IDL 인터페이스 세트를 정의합니다. 이 상호 조작 가능 메타모델에는 UML 메타모델, MOF 메타-메타모델은 물론 메타모델을 사용하여 지정할 향후 OMG 채택 기술도 포함됩니다. MOF는 CORBA 기본 설계 및 재사용 저장소 구현에 필요한 인프라스트럭처를 제공합니다. 이 정의는 MOF 스펙 버전 1.3에서 가져옵니다.
-
MOM(Message-Oriented Middleware)
- 메시지 기반 미들웨어.
-
MVC(Model Viewcontroller)
- 어플리케이션의 컴포넌트를 분리하는 어플리케이션 구조. 모델은 비즈니스 논리 또는 데이터를 나타냅니다. 보기는 사용자 인터페이스를 나타내고 제어기는 사용자 입력을 관리하거나 간혹 어플리케이션 플로우를 관리하기도 합니다.
-
MVC(model view controller)
-
모델 보기 제어기.
-
MVS(Multiple Virtual Storage)
- 다중 가상 기억장치.
-
N
-
n-ary 연관(n-ary association)
-
네 개 이상의 클래스 간의 연관. 연관의 각 인스턴스는 각 클래스에 있는 n-tuple 값입니다. 2진 연관과 대조됩니다.
-
NC
- Network Computer 또는 Network Computing
-
NCF(Network Computing Framework)
- 네트워크 컴퓨팅 프레임워크.
-
NO TERM ENTRY
-
NSAPI(Netscape Server API)
- Netscape 서버의 API입니다.
-
NT
- Windows NT(New Technology).
-
O
-
ODBC
-
ODBC(Open Database Connectivity)를 참조하십시오.
-
ODBC(Open Database Connectivity)
- 호출 가능한 SQL을 호출하는 데이터베이스 관리 시스템에 대한 액세스를 허용하는 Microsoft에서 개발한 C 데이터베이스 API로서, SQL 프리프로세서를 사용할 필요가 없습니다. 또한 ODBC는 사용자가 런타임시 선택한 데이터베이스 관리 시스템에 어플리케이션을 링크하는 데이터베이스 드라이버 호출 모듈을 추가할 수 있도록 하는 구조를 제공합니다. 이는 어플리케이션이 더 이상 지원되는 모든 데이터베이스 관리 시스템의 모듈에 직접 링크되어 있지 않아도 됨을 의미합니다.
-
ODBC 드라이버(ODBC driver)
- ODBC 드라이버는 ODBC 함수 호출을 구현하고 데이터 소스와 상호작용하는 DLL(Dynamically Linked Library)입니다.
-
ODBC 드라이버 관리자(ODBC driver manager)
- Microsoft에서 제공하는 ODBC 드라이버 관리자는 가져오기 라이브러리가 있는 DLL입니다. 드라이버 관리자의 기본 목적은 ODBC 드라이버를 로드하는 것입니다. 드라이버 관리자는 또한 각 드라이버의 ODBC 함수에 대한 시작점과 ODBC 호출에 대한 매개변수 유효성 확인 및 순서 유효성 확인을 제공합니다.
-
OLTP
-
OLPT(Online Transaction Processing)를 참조하십시오.
-
OLTP(Online Transaction Processing)
- 단말기 사용자가 제출한 요청을 받는 즉시 처리하는 대화식 어플리케이션을 지원하는 컴퓨팅 양식. 결과는 비교적 짧은 시간에 요청자에게 리턴됩니다. 온라인 트랜잭션 처리 시스템은 동시에 여러 트랜잭션을 효율적으로 사용할 수 있도록 하기 위해 자원을 공유하도록 지시합니다.
-
OMG(Object Management Group)
- 객체 관리 그룹.
-
OO((Object Oriented))
- 객체 지향.
-
OOP
-
OOP(Object-Oriented Programming)를 참조하십시오.
-
OOP(Object-Oriented Programming)
- 데이터 분리 및 상속 개념을 기본으로 하는 프로그래밍 접근 방법. 절차식 프로그래밍 기술과 달리, 객체 지향 프로그래밍은 완료 방법이 아니라 문제점을 형성하는 데이터 객체와 이를 조작하는 방법에 중점을 둡니다.
-
ORB(Object Request Broker)
- 객체가 투명하게 요청을 작성하고 객체로부터 응답을 받는 방법과 객체가 로컬인지 또는 원격인지를 지정하는 CORBA 용어.
-
객체 요청 브로커.
-
P
-
PCO(Point of Control and Observation)
-
제어 및 관측 지점.
-
PDR
-
PDR(Preliminary Design Review)을 참조하십시오.
-
PDR(Preliminary Design Review)
- 방화벽 라이프사이클에서 구조적 설계가 완료될 때 보유하는 주요 검토.
-
PERL(Practical Extraction & Reporting Language)
- 실제 추출 및 보고서 작성 언어.
-
Perspective
- 일반적으로 의미에는 큰 변화없이 관점에 대한 대안으로 사용될 수 있습니다.
- Rational Software Architecture 사용법(Eclipse 기반)에서 UI 패러다임의 일부분. 특정 시각이 열려 있으면 데스크탑은 다른 역할 또는 관계의 지원으로 연관된 보기, 편집기 및 조치를 표시하도록 변경됩니다.
-
PGP
- Pretty Good Privacy입니다.
-
PIM(Platform Independent Model)
- [OMG03]에서는 이를 다음과 같이 정의합니다.
"플랫폼에 특정 정보를 포함하지 않는 서브시스템 모델 또는 이를 구현하는 데 사용되는 기술. "
-
PKI
- Public Key Infrastructure입니다.
-
PM(Platform Model)
- 플랫폼은 개념(파트 또는 서비스를 나타냄), 스펙, 인터페이스 정의, 제한조건 정의 및 어플리케이션이 특정 플랫폼을 사용하는 데 필요한 기타 요구사항의 세트입니다.MDA에서 플랫폼 모델은 UML로 상세히 설명되어 있고 공식화되어 있으며 MOF 호환 저장소에서 사용 가능합니다. 예를 들어, 플랫폼 모델은 J2EE, .NET 또는 다른 용도로 빌드할 수 있습니다.
-
POP3
- Post Office Protocol 3입니다.
-
PRA
-
PRA(Project Review Authority)를 참조하십시오.
-
PRA(Project Review Authority)
- 프로젝트 관리자가 보고하는 조직 엔티티. PRA는 소프트웨어 프로젝트가 정책, 방법 및 표준을 준수하는지를 확인할 책임이 있습니다.
-
PRD
-
PRD(Product Requirements Document)를 참조하십시오.
-
PRD(Product Requirements Document)
- 제품(시스템), 의도한 사용법 및 제품이 제공하는 기능 세트에 대한 상위 레벨의 설명.
-
private
- 클래스 구성원과 연관된 액세스 수정자. 이는 클래스 자체만이 구성원에 액세스할 수 있게 합니다.
-
protected
- 클래스 구성원과 연관된 액세스 수정자. 이는 클래스 자체, 서브클래스 및 동일한 패키지 내의 모든 클래스가 구성원에 액세스할 수 있게 합니다.
-
pseudo 상태(pseudo-state)
-
상태 양식을 가지나 상태로서 작동하지 않는 상태 시스템의 정점. pseudo 상태에는 초기 및 이력 정점이 포함됩니다.
-
PSM(Platform Specific Model)
- [OMG03]에서는 이를 다음과 같이 정의합니다.
" 특정 플랫폼에서 이를 구현하는 데 사용된 특정 기술에 대한 정보를 포함하는 서브시스템 모델로서 플랫폼에 특정한 요소를 포함할 수 있습니다. "
-
Q
-
QA(quality assurance)
-
품질 보증.
-
QE(Quality Engineering)
- 품질 엔지니어링. 품질 보증 역시 참조하십시오.
-
R
-
RDBMS
- Relational Database Management System입니다.
-
RFC
- (1) 변경 요청. 변경을 위해 엔지니어링 변경 제안서에 계약금을 사용하도록하는 구매자 또는 판매자의 요청. 요청에는 해결 중인 기술적 또는 계약상의 문제점, 프로젝트에 대한 영향 또는 수익, 비용 및 스케줄 영향에 대한 평가 내용이 설명되어 있습니다.
- (2) 설명 요청. RFC라고 알려진 문서에 인터넷 표준이 정의되어 있습니다.
-
RFI(Request for information)
- 정보 요청. 시장에서의 공식적인 정보 조회. 일반적으로 '관심의 표현식'으로 요청에 설명된 작업에 착수하여 명령할 계약자의 능력 및 사용 가능성과 관련되어 있습니다.
-
RFP(Request For Proposal)
- 제안 요청. 계약의 기초를 형성할 방법론과 보상 모두를 설명하는 공식적인 응답(제안)을 찾는 작업 범위를 포함하는 공식적 제안서.
-
RFQ(Request For Quotation)
- 견적 요청. 지정된 대로 상품/또는 서비스의 가격을 제출하는 공식적인 제안서.
-
RMI
-
원격 메소드 호출을 참조하십시오.
-
RMI 레지스트리(RMI registry)
- 원격 클라이언트가 서버 Bean에 대한 참조를 가져올수 있게 하는 서버 프로그램.
-
RMI 컴파일러(RMI compiler)
- RMI 통신을 용이하게 하는 스텁 또는 스켈레톤 파일을 생성하는 컴파일러. 툴 메뉴 항목에서 이 컴파일러를 자동으로 호출할 수 있습니다.
-
RPC
-
원격 프로시저 호출.
-
RPC(Remote Procedure Call)
- 다른 장소에 있는 분배 프로시저에 대한 함수 호출을 사용하여 요청을 할 수 있는 의사소통 모델. 프로시저의 위치는 호출 어플리케이션에 대해 투명합니다.
-
RPW
-
RPW(Rational Process Workbench)를 참조하십시오.
-
RPW(Rational Process Workbench)
- 프로세스 엔지니어가 사용자 정의된 소프트웨어 개발 프로세스의 전달을 가속화하고, 통합 모델링 언어를 사용하여 프로세스를 시각적으로 모델링하며, RUP에 캡처된 베스트 프랙티스를 레버리지할 수 있게 하는 프로세스 사용자 정의 및 출력 툴.
-
RSA(Rivest-Shamir-Adleman algorithm)
- Rivest-Shamir-Adleman 알고리즘.
-
RUP
- Rational Unified Process입니다.
-
S
-
S/MIME(Secure MIME)
- 보안 MIME
-
SAP
-
SAP(systems,applications, and products)을 참조하십시오.
-
SAP(Systems, Applications, and Products)
- 원래 이름은 "Systemanalyse und Programmentwicklung"이었으나 현재 데이터 처리에서는 SAP이라고 지정되었습니다. SAP은 광범위하게 사용되는 소프트웨어에 통합 비즈니스 솔루션을 제공합니다.
-
SEPA
-
SEPA(Software Engineering Process Authority)를 참조하십시오.
-
SEPA(Software Engineering Process Authority)
- 프로세스 정의, 평가 및 개선 책임을 가진 조직의 엔티티.
-
servlet
- servlet은 브라우저 요청에 대한 응답으로 서버에서 실행되는 Java 객체입니다. 이는 HTML 또는 XML 디렉토리를 생성하거나 JSP를 호출하여 결과물을 생성합니다.
-
SET
- Secure Electronic Transaction입니다.
-
SHTTP
- Secure Hypertext Transfer Protocol입니다.
-
SMTP
- Simple Mail Transport Protocol입니다.
-
SNMP
- Simple Network Management Protocol입니다.
-
SOA(Service-Oriented Architecture)
- 서비스 지향 구조(SOA)는 그들이 제공하는 컴포넌트 및 서비스와 관련하여 소프트웨어 시스템 구조의 개념적 설명이며, 이 컴포넌트, 서비스 및 컴포넌트 간의 연결의 기본 구현과는 관계 없습니다.
-
soap-opera 테스트(soap-opera testing)
- 극적이고 과장된 시나리오에 대한 추론을 사용하여 테스트 시나리오를 정의하는 기술. TV의 멜로 드라마처럼 이 시나리오는 "현실"을 반영하지만 시스템 사용에 대한 극적 인스턴스를 설명하기 위해 압축 및 과장되었습니다. 경험이 풍부한 사용자와 협업하여 정의할 경우, 멜로 드라마는 시스템의 여러 기능적 측면을 신속하게 테스트할 수 있으며 시스템 공식 스펙 또는 시스템 기능에 직접 관련되어 있지 않기 때문에 중요하지만 아직 예상하지 못한 문제점을 밝히는 데 성공률이 높습니다. 이 용어 및 연관된 기술의 정의는 고객과의 테스트 상담 중에 Hans Buwalda에 의해 개발되었습니다.
-
SOCKS
-
SOCKS(Socket Secure)를 참조하십시오.
-
SOCKS(socket secure)
- 호환되는 클라이언트 코드(클라이언트 코드가 소켓 보안 작성)가 원격 호스트와의 세션을 설정할 수 있게 하는 게이트웨이.
-
SQL
- Structured Query Language입니다.
-
SRR
-
시스템 요구사항 검토를 참조하십시오.
-
SRS
-
SRS(Software Requirements Specification)을 참조하십시오.
-
SRS(Software Requirements Specification)
- 빌드할 시스템의 내부 및 외부 작동을 완전히 정의하는 요구사항 세트. 종종 기능적 스펙이라고 합니다.
-
SSL
- Secure Sockets Layer입니다.
-
SSR
-
소프트웨어 스펙 검토를 참조하십시오.
-
T
-
TCP
-
Transmission Control Protocol입니다.
-
TCP/IP
-
Transmission Control Protocol/Internet Protocol입니다.
-
U
-
UI
-
사용자 인터페이스를 참조하십시오.
-
UML
-
UML(Unified Modeling Language)을 참조하십시오.
-
UML(Unified Modeling Language)
- 소프트웨어 위주 시스템의 결과물을 가시화, 지정, 구축 및 문서화하는 언어[BOO98]. UML[UML01]을 참조하십시오. RUP 용어집에서 UML에 있는 정의는
기호로 표시됩니다.
-
UML 프로파일(UML Profile)
-
UML 메타모델에 대한 확장 세트. 스테레오타입, 제한조건, 태그 정의 및 꼬리표 값을 사용하여 새 의미론과 함께 특정 UML 모델 요소를 사용자 정의 및 확장하는 방법을 지정합니다. 특정 목적으로 정의된 이러한 관련 확장 세트가 UML 프로파일을 구성합니다.
-
URL
-
URL(Uniform Resource Locator)을 참조하십시오.
-
URL(Uniform Resource Locator)
- 웹 브라우저가 연결을 시작하는 데 사용하는 WWW의 자원에 대한 표준 ID. URL은 사용할 통신 프로토콜, 서버의 이름 및 서버에서 검색할 객체를 식별하는 경로 정보를 포함합니다.
-
V
-
VB
- Microsoft에서 작성한 Visual Basic(전문화된 BASIC 버전) 프로그래밍 언어 및 연관 IDE.
-
VM
-
가상 시스템을 참조하십시오.
-
VPN(Virtual private network)
- 가상 사설 네트워크.
-
W
-
WBS(Work Breakdown Structure)
- 계획된 프레임워크. 비용, 결과물 및 활동을 할당 및 추적할 수 있는 작업 단위로 프로젝트를 분해하는 것.
-
Windows 레지스트리(Windows registry)
- Microsoft(R) Windows(R) 등록 데이터베이스로서 제공된 PC에 설치된 소프트웨어 프로그램의 구성 설정 및 사용자 옵션을 저장하는 데 사용됩니다.
-
WWW(WWW 또는 웹: world wide web)
- 그래픽 하이퍼텍스트 멀티미디어 인터넷 서비스.
-
WYSIWYG
- 화면에 보이는 이미지 그대로 프린터 출력으로 되는 기능.
-
X
-
XML
- Extensible markup language입니다.
-
XP
- Extreme Programming입니다.
-
Y
-
Z
-
1바이트 문자 세트(SBCS: single-byte character set)
- 각 문자를 1 바이트로 표현하는 문자 세트.
-
1차 키(primary key)
- 테이블의 행을 식별하는 데 사용되는 데이터베이스 테이블의 열 또는 열 세트.
-
2바이트 문자 세트(DBCS: double-byte character set)
- 각 문자를 2바이트로 나타내는 문자 세트. 256개 이상의 코드 포인트를 포함하여 2바이트 문자 세트가 필요한 일본어, 중국어 및 한국어와 같은 언어. 1바이트 문자 세트와 대조됩니다.
-
2진 연관(binary association)
-
두 클래스 간의 연관. n-ary 연관의 특수한 케이스.