라이브러리(컴퓨팅)

Library (computing)
"소프트웨어 라이브러리"는 여기로 리디렉션됩니다. 도서관 소프트웨어와 혼동되지 않도록 합니다.
이 기사는 소프트웨어 개발 개념에 관한 것입니다. 디지털 자산 저장소에 대해서는 디지털 라이브러리를 참조하십시오.
libvorbis 파일을 사용하여 Ogg Vorbis 파일을 재생하는 응용 프로그램의 예시

컴퓨터 과학에서 라이브러리는 컴퓨터 프로그램을 구현하기 위해 소프트웨어 개발 중에 활용되는 리소스 모음입니다.

리소스에는 구성 데이터, 문서, 도움말 데이터, 메시지 템플릿, 소스 코드 또는 미리 컴파일된 기능 및 클래스, 값 또는 유형 사양이 포함될 수 있습니다.

IBM의 OS/360 및 그 후속 제품에서는 이를 파티션 데이터 세트라고 합니다.

함수 라이브러리에는 함수가 호출되는 잘 정의된 인터페이스가 있습니다. 예를 들어, 프로그램은 프로그램에서 시스템 호출을 직접 수행하는 대신 라이브러리를 사용하여 간접적으로 시스템 호출을 수행할 수 있습니다. 또한 라이브러리에 의해 기능이 노출되어 여러 개의 독립적인 프로그램에 의해 재사용됩니다.

프로그램은 잘 정의된 메커니즘을 통해 라이브러리 기능을 호출합니다. 예를 들어, C에서 라이브러리 함수는 C의 정상 함수 호출을 사용하여 호출됩니다. 링커는 함수를 프로그램 자체 대신 라이브러리에서 사용할 수 있는 경우 라이브러리 메커니즘을 통해 함수를 호출하는 코드를 생성합니다.[1]

라이브러리 함수는 관련이 없는 여러 프로그램에서 사용할 수 있지만 프로그램에 정의된 함수는 해당 프로그램에서만 사용할 수 있습니다. 이러한 구분은 프로그램이 커질 때 계층적 개념을 얻을 수 있습니다. 그 경우 대형 프로그램의 독립적인 하위 부분에서 재사용되는 내부 라이브러리가 있을 수 있습니다.

라이브러리의 특징은 여러 개의 독립적인 프로그램에서 사용할 수 있으며 프로그래머는 라이브러리의 내부 세부 정보가 아닌 인터페이스만 알면 된다는 것입니다.

라이브러리의 가치는 표준화된 프로그램 요소의 재사용에 있습니다. 프로그램이 라이브러리를 호출하면 해당 동작 자체를 구현할 필요 없이 라이브러리 내부에서 구현된 동작을 얻습니다. 라이브러리는 모듈식으로 코드 공유를 장려하고 코드 배포를 용이하게 합니다.

라이브러리의 기능은 다양한 프로그램 라이프사이클 단계에서 호출 프로그램에 연결할 수 있습니다. 호출 프로그램을 빌드하는 동안 라이브러리의 코드에 액세스하면 라이브러리를 정적 라이브러리라고 합니다.[2] 대안은 라이브러리 파일과 분리되도록 프로그램 실행 파일을 구축하는 것입니다. 라이브러리 기능은 실행 파일이 시작된 후 로드 시간 또는 런타임에 연결됩니다. 이 경우 도서관을 동적 도서관이라고 합니다.

대부분의 컴파일 언어에는 표준 라이브러리가 있지만 프로그래머는 자신만의 사용자 정의 라이브러리를 만들 수도 있습니다. 대부분의 최신 소프트웨어 시스템은 대부분의 시스템 서비스를 구현하는 라이브러리를 제공합니다. 이러한 도서관은 현대 애플리케이션이 필요로 하는 서비스를 구성했습니다. 따라서 현대 애플리케이션에서 사용하는 대부분의 코드는 이러한 시스템 라이브러리에서 제공됩니다.

역사

컴퓨터 라이브러리의 아이디어는 찰스 배비지(Charles Babbage)에 의해 만들어진 최초의 컴퓨터로 거슬러 올라갑니다. 그의 해석 엔진에 관한 1888년 논문은 컴퓨터 연산이 수치 입력과 별개의 카드에서 펀칭될 수 있다고 제안했습니다. 이러한 작동 펀치 카드가 재사용을 위해 저장된 경우 "차원적으로 엔진에 자체 라이브러리가 있을 것"입니다.[3]

EDSAC 컴퓨터용 천공 테이프의 릴에 있는 서브루틴 라이브러리가 들어 있는 파일 캐비닛 옆에서 일하고 있는 한 여성.

1947년 골드스틴과 폰 노이만은 당시에는 아직 작동하지 않았던 초기 컴퓨터인 IAS 기계에 대한 작업을 위해 서브루틴의 "라이브러리"를 만드는 것이 유용할 것이라고 추측했습니다.[4] 그들은 각 와이어가 재사용 가능한 컴퓨터 코드를 저장하는 자기 와이어 기록의 물리적 라이브러리를 구상했습니다.[5]

폰 노이만에게서 영감을 받아 윌크스와 그의 팀은 EDSAC을 만들었습니다. 구멍 뚫린 테이프로 된 파일 캐비닛이 이 컴퓨터의 서브루틴 라이브러리를 고정하고 있었습니다.[6] EDSAC용 프로그램은 메인 프로그램과 서브루틴 라이브러리에서 복사한 일련의 서브루틴으로 구성되었습니다.[7] 1951년에 그 팀은 프로그래밍에 관한 최초의 교과서인 The Preparation of Programs for Electronic Digital Computer를 출판했는데, 그것은 도서관의 창작과 목적을 자세히 설명했습니다.[8]

COBOL은 1959년에 "도서관 시스템을 위한 기본 기능"을 포함했지만,[9] Jean Sammet은 돌이켜보면 "부적절한 도서관 시설"이라고 설명했습니다.[10]

JOBIL은 대략 헤더 파일 라이브러리인 COMPOL(Communication Pool)을 가지고 있었습니다.

현대 도서관 개념의 또 다른 주요 공헌은 FORTRAN의 하위 프로그램 혁신의 형태로 나타났습니다. FORTRAN 하위 프로그램은 서로 독립적으로 컴파일할 수 있지만 컴파일러에는 링커가 없었습니다. 따라서 Fortran-90에 모듈을 도입하기 전에는 FORTRAN[NB 1] 하위 프로그램 간의 형식 확인이 불가능했습니다.[11]

1960년대 중반까지 어셈블러를 위한 복사 및 매크로 라이브러리가 일반화되었습니다. IBM System/360의 인기를 시작으로 시스템 매개 변수와 같은 다른 유형의 텍스트 요소를 포함하는 라이브러리도 일반화되었습니다.

Simula는 최초의 객체 지향 프로그래밍 언어였으며 자바, C++, C#에서 사용되는 현대 개념과 클래스가 거의 동일했습니다. Simula의 클래스 개념은 Ada에서 패키지의 원형이자 Modula-2의 모듈이기도 했습니다.[12] 원래 1965년에 개발되었을 때에도 Simula 클래스는 라이브러리 파일에 포함되어 컴파일 시 추가될 수 있었습니다.[13]

링킹

주요 기사: 링크 시간 및 링커(컴퓨팅)

라이브러리는 라이브러리 모듈에 대한 링크 또는 기호로 알려진 참조를 해결하는 프로그램 연결 또는 바인딩 프로세스에서 중요합니다. 연결 프로세스는 일반적으로 특정 순서로 라이브러리 및 기타 모듈 집합을 검색하는 연결기 또는 바인더 프로그램에 의해 자동으로 수행됩니다. 일반적으로 주어진 라이브러리 집합에서 링크 대상을 여러 번 찾을 수 있는 경우 오류로 간주되지 않습니다. 연결은 실행 파일이 생성될 때(정적 연결) 또는 런타임에 프로그램이 사용될 때(동적 연결) 수행될 수 있습니다.

해결 중인 참조는 점프 및 기타 일상적인 호출에 대한 주소일 수 있습니다. 기본 프로그램에 있을 수도 있고, 다른 모듈에 따라 하나의 모듈에 있을 수도 있습니다. 참조되는 각 모듈의 메모리 세그먼트에 대해 런타임 메모리를 할당하여 (공통 베이스에서) 고정 또는 재배치 가능한 주소로 해결합니다.

일부 프로그래밍 언어는 링커가 컴파일러를 인식하거나 컴파일러와 통합할 수 있는 스마트 링킹이라는 기능을 사용하여 링커가 외부 참조가 어떻게 사용되는지 알 수 있으며, 내부 참조가 이루어졌음에도 불구하고 실제로 사용된 적이 없는 라이브러리의 코드는 컴파일된 응용 프로그램에서 폐기할 수 있습니다. 예를 들어 산술에 정수만 사용하거나 산술 연산을 전혀 하지 않는 프로그램은 부동 소수점 라이브러리 루틴을 제외할 수 있습니다. 이 스마트 링크 기능은 애플리케이션 파일 크기를 줄이고 메모리 사용량을 줄일 수 있습니다.

이전

주요 기사: 재배치(컴퓨터과학)

프로그램 또는 라이브러리 모듈의 일부 참조는 모든 코드 및 라이브러리에 최종 정적 주소가 할당될 때까지 해결할 수 없는 상대적 또는 기호 형식으로 저장됩니다. 재배치는 이러한 참조를 조정하는 과정이며, 링커 또는 로더에 의해 수행됩니다. 일반적으로 개별 도서관에 대한 재배치는 개별 도서관을 사용하는 프로그램과 이들이 결합된 다른 도서관에 따라 메모리 내 주소가 달라질 수 있기 때문에 자체적으로 수행할 수 없습니다. 위치 독립 코드는 절대 주소에 대한 참조를 피하므로 재배치가 필요하지 않습니다.

정적 라이브러리

주요 기사: 정적 라이브러리

실행 파일 또는 다른 개체 파일을 만드는 동안 연결을 수행할 때 정적 연결 또는 초기 바인딩이라고 합니다. 이 경우 링크는 일반적으로 링커에 의해 수행되지만 컴파일러에 의해 수행될 수도 있습니다.[14] 아카이브라고도 하는 정적 라이브러리는 정적으로 연결되도록 설계된 라이브러리입니다. 원래는 정적 라이브러리만 존재했습니다. 정적 연결은 모듈을 다시 컴파일할 때 수행해야 합니다.

프로그램에 필요한 모든 모듈은 정적으로 연결되어 실행 파일에 복사되기도 합니다. 이 프로세스와 그 결과 독립 실행형 파일은 프로그램의 정적 빌드로 알려져 있습니다. 가상 메모리가 사용되고 주소 공간 레이아웃 랜덤화가 필요 없는 경우 정적 빌드는 더 이상 재배치할 필요가 없을 수 있습니다.[15]

공유 라이브러리

주요 기사: 공유 라이브러리

공유 라이브러리 또는 공유 개체는 실행 파일 및 추가 공유 개체 파일에 의해 공유되도록 의도된 파일입니다. 프로그램에서 사용하는 모듈은 프로그램에 대한 단일 실행 파일을 만들 때 링커에 의해 복사되지 않고 로드 시간이나 런타임에 개별 공유 개체에서 메모리로 로드됩니다.

공유 라이브러리는 컴파일 시간 동안 정적으로 연결될 수 있습니다. 즉, 라이브러리 모듈에 대한 참조가 해결되고 실행 파일이 생성될 때 모듈에 메모리가 할당됩니다.[citation needed] 그러나 공유 라이브러리의 연결은 종종 로드될 때까지 연기됩니다.[dubious – discuss]

개체 라이브러리

원래 1960년대에 개척되었지만 동적 연결은 1980년대 후반까지 소비자가 사용하는 운영 체제에 도달하지 못했습니다. 1990년대 초반까지 대부분의 운영 체제에서 일반적으로 어떤 형태로든 사용할 수 있었습니다. 같은 기간 동안 객체 지향 프로그래밍(OOP)은 프로그래밍 환경에서 중요한 부분이 되었습니다. 런타임 바인딩이 있는 OOP에는 기존 라이브러리가 제공하지 않는 추가 정보가 필요합니다. 내부에 위치한 코드의 이름과 진입 지점 외에도 의존하는 개체의 목록이 필요합니다. 이는 OOP의 핵심 개념 중 하나인 상속의 부작용이며, 이는 모든 방법에 대한 완전한 정의의 일부가 서로 다른 위치에 있을 수 있음을 의미합니다. 이것은 단순히 하나의 라이브러리가 다른 라이브러리의 서비스를 필요로 한다는 것을 나열하는 것 이상입니다. 진정한 OOP 시스템에서는 라이브러리 자체가 컴파일 시 알 수 없을 수 있으며 시스템마다 다를 수 있습니다.

동시에 많은 개발자들은 데스크톱 컴퓨터에서 실행되는 디스플레이가 데이터 저장 또는 처리를 위해 메인프레임 또는 미니컴퓨터의 서비스를 사용하는 멀티티어 프로그램 아이디어를 개발했습니다. 예를 들어, GUI 기반 컴퓨터의 프로그램은 디스플레이를 위해 거대한 데이터 세트의 작은 샘플을 반환하기 위해 미니 컴퓨터에 메시지를 보냅니다. 원격 절차 호출(RPC)은 이미 이러한 작업을 처리했지만 표준 RPC 시스템은 없었습니다.

곧 대부분의 미니 컴퓨터 및 메인프레임 공급업체는 이 둘을 결합하는 프로젝트를 시작했고, 어디에서나 사용할 수 있는 OOP 라이브러리 형식을 만들었습니다. 이러한 시스템은 원격 액세스를 지원하는 경우 객체 라이브러리 또는 분산 객체로 알려졌습니다(모두는 아닙니다). 마이크로소프트의 COM은 현지에서 사용할 수 있는 시스템의 한 예입니다. COM의 변형 버전인 DCOM은 원격 접근을 지원합니다.

한동안 객체 라이브러리는 프로그래밍 세계에서 "차세대 큰 것"의 지위를 유지했습니다. 플랫폼 전반에 걸쳐 실행되는 시스템을 만들기 위한 여러 노력이 있었고, 기업들은 개발자들을 자신의 시스템에 가두기 위해 경쟁했습니다. IBM의 시스템 객체 모델(SOM/DSOM), Sun Microsystems의 DOE(Distributed Objects Everywhere), NeXT의 PDO(Portable Distributed Objects), Digital의 ObjectBroker, Microsoft의 Component Object Model(COM/DCOM) 및 CORBA 기반 시스템 등이 그 예입니다.

클래스 라이브러리

클래스 라이브러리는 이전 유형의 코드 라이브러리에 해당하는 대략적인 OOP입니다. 클래스에는 특성을 설명하고 개체와 관련된 작업(방법)을 정의하는 클래스가 포함됩니다. 클래스 라이브러리는 특성이 특정 값으로 설정된 인스턴스 또는 개체를 만드는 데 사용됩니다. 자바와 같은 일부 OOP 언어에서는 클래스가 라이브러리 파일(자바의 JAR 파일 형식)에 포함된 경우가 많고 인스턴스화된 개체는 메모리에만 존재합니다(잠재적으로 별도의 파일에 지속 가능). Smalltalk와 같이 클래스 라이브러리는 환경, 클래스 및 인스턴스화된 모든 개체의 전체 상태를 포함하는 시스템 이미지의 시작점에 불과합니다.

오늘날 대부분의 클래스 라이브러리는 패키지 저장소(예: 자바용 메이븐 센트럴)에 저장됩니다. 클라이언트 코드는 빌드 구성 파일의 외부 라이브러리에 대한 종속성을 명시적으로 선언합니다(예: Java의 Maven Pom).

원격 라이브러리

또 다른 라이브러리 기술은 완전히 분리된 실행 파일(흔히 가벼운 형태)을 사용하고 네트워크를 통해 다른 컴퓨터로 원격 프로시저 호출(RPC)을 사용하여 호출합니다. 이를 통해 운영 체제 재사용을 극대화할 수 있습니다. 라이브러리를 지원하는 데 필요한 코드는 다른 모든 프로그램에 대한 응용 프로그램 지원 및 보안을 제공하는 데 사용되는 코드와 같습니다. 또한 이러한 시스템은 라이브러리가 동일한 시스템에 존재할 필요가 없지만 네트워크를 통해 요청을 전달할 수 있습니다.

그러나 이러한 접근 방식은 모든 라이브러리 호출에 상당한 양의 오버헤드가 필요하다는 것을 의미합니다. RPC 호출은 이미 동일한 시스템에 로드된 공유 라이브러리를 호출하는 것보다 훨씬 더 비쌉니다. 이 접근 방식은 일반적으로 이러한 원격 호출, 특히 클라이언트-서버 시스템 및 Enterprise Java Beans와 같은 애플리케이션 서버를 많이 사용하는 분산 아키텍처에서 사용됩니다.

코드 생성 라이브러리

코드 생성 라이브러리는 Java용 바이트 코드를 생성하거나 변환할 수 있는 상위 API입니다. 이들은 측면 지향 프로그래밍, 일부 데이터 액세스 프레임워크 및 동적 프록시 개체를 생성하기 위한 테스트에 사용됩니다. 또한 필드 액세스를 차단하는 데 사용됩니다.[16]

파일 이름 지정

대부분의 최신 유닉스 계열 시스템

참고 항목: 유닉스 계열의

시스템이 저장합니다. libfoo.a 그리고. libfoo.so 다음과 같은 디렉터리의 파일 /lib, /usr/lib 또는 /usr/local/lib. 파일 이름은 항상 다음으로 시작합니다. lib, 그리고 접미사로 끝을 맺습니다. .a (archive, 정적 라이브러리) 또는 .so (공유 개체, 동적으로 연결된 라이브러리). 일부 시스템에는 동적으로 연결된 라이브러리의 이름이 여러 개 있을 수 있습니다. 이러한 이름은 일반적으로 동일한 접두사를 공유하며 버전 번호를 나타내는 접미사가 다릅니다. 대부분의 이름은 최신 버전에 대한 상징적인 링크의 이름입니다. 예를 들어, 일부 시스템에서는 libfoo.so.2 동적으로 연결된 라이브러리의 두 번째 주요 인터페이스 리비전의 파일명이 될 것입니다. libfoo.그 .la 라이브러리 디렉토리에서 가끔 발견되는 파일은 libtool 아카이브이며 시스템에서 사용할 수 없습니다.

macOS

참고 항목: macOS

시스템은 정적 라이브러리 규칙을 BSD에서 상속하며, 라이브러리는 a에 저장됩니다. .a 파일, 사용할 수 있습니다. .so-스타일 동적 링크 라이브러리( 와 함께) .dylib 접미사 대신). 그러나 macOS의 대부분의 라이브러리는 "프레임워크"로 구성되며, 라이브러리의 필수 파일과 메타데이터를 묶는 "번들"이라고 불리는 특별한 디렉토리 안에 배치됩니다. 예를 들어, 라고 하는 프레임워크가 있습니다. MyFramework 다음과 같은 번들로 구현됩니다. MyFramework.framework,와 함께 MyFramework.framework/MyFramework 동적으로 연결된 라이브러리 파일 또는 동적으로 연결된 라이브러리 파일에 대한 symlink입니다. MyFramework.framework/Versions/Current/MyFramework.

마이크로소프트 윈도우

참고 항목: 마이크로소프트 윈도우

동적 링크 라이브러리에는 일반적으로 접미사가 있습니다. *.DLL,[17]다른 파일 이름 확장자가 특정 목적의 동적으로 연결된 라이브러리를 식별할 수 있습니다[17]. *.OCX OLE 라이브러리용. 인터페이스 리비전은 파일 이름으로 인코딩되거나 COM-오브젝트 인터페이스를 사용하여 추상화됩니다. 그것들이 어떻게 편찬되느냐에 따라서, *.LIB 파일은 정적 라이브러리이거나 컴파일 중에만 필요한 동적 링크 가능 라이브러리의 표현일 수 있으며, "가져오기 라이브러리"로 알려져 있습니다. 서로 다른 파일 확장자를 사용하는 유닉스 세계와 달리 링크를 연결할 때 .LIB Windows의 파일이 일반 정적 라이브러리인지 가져오기 라이브러리인지 먼저 알아야 합니다. 후자의 경우, a .DLL 파일은 런타임에 있어야 합니다.

CAD 라이브러리

참고 항목: CAx 회사 목록 및 카테고리:3D 그래픽 파일 형식

컴퓨터 지원 설계 라이브러리 또는 CAD 라이브러리는 컴퓨터 지원 설계(CAD), 컴퓨터 지원 엔지니어링(CAE), 컴퓨터 지원 제조(CAM) 또는 빌딩 정보 모델링(BIM)을 위한 3D 모델 또는 부품의 클라우드 기반 저장소입니다. CAD 라이브러리의 예로는 GrabCAD, Sketchup 3D Warehouse, McMaster-Carr, TurboSquid 및 Thingiverse가 있습니다.[18] 이 모델은 무료 오픈 소스 또는 독점 제품이 될 수 있으며 CAD 라이브러리 3D 모델에 액세스하려면 구독료를 지불해야 합니다. 도식과 도표의 연계 오픈 데이터를 활용하여 인공 지능 CAD 라이브러리를 개발하고 있습니다.[19]

참고 항목

메모들

  1. ^ 예를 들어, 에이다 하위 프로그램 사이에서 더 일찍 가능했습니다.

참고문헌

  1. ^ Deshpande, Prasad (2013). Metamorphic Detection Using Function Call Graph Analysis (Thesis). San Jose State University Library. doi:10.31979/etd.t9xm-ahsc.
  2. ^ "Static Libraries". TLDP. Archived from the original on 2013-07-03. Retrieved 2013-10-03.
  3. ^ Babbage, H. P. (1888-09-12). "The Analytical Engine". Proceedings of the British Association. Bath.
  4. ^ Goldstine, Herman H. (2008-12-31). The Computer from Pascal to von Neumann. Princeton: Princeton University Press. doi:10.1515/9781400820139. ISBN 978-1-4008-2013-9.
  5. ^ Goldstine, Herman; von Neumann, John (1947). Planning and coding of problems for an electronic computing instrument (Report). Institute for Advanced Study. pp. 3, 21–22. OCLC 26239859. it will probably be very important to develop an extensive "library" of subroutines
  6. ^ Wilkes, M. V. (1951). "The EDSAC Computer". 1951 International Workshop on Managing Requirements Knowledge. 1951 International Workshop on Managing Requirements Knowledge. IEEE. p. 79. doi:10.1109/afips.1951.13.
  7. ^ Campbell-Kelly, Martin (September 2011). "In Praise of 'Wilkes, Wheeler, and Gill'". Communications of the ACM. 54 (9): 25–27. doi:10.1145/1995376.1995386. S2CID 20261972.
  8. ^ Wilkes, Maurice; Wheeler, David; Gill, Stanley (1951). The Preparation of Programs for an Electronic Digital Computer. Addison-Wesley. pp. 45, 80–91, 100. OCLC 641145988.
  9. ^ Wexelblat, Richard (1981). History of Programming Languages. ACM Monograph Series. New York, NY: Academic Press (A subsidiary of Harcourt Brace). p. 274. ISBN 0-12-745040-8.
  10. ^ Wexelblat, op. cit., p. 258
  11. ^ Wilson, Leslie B.; Clark, Robert G. (1988). Comparative Programming Languages. Wokingham, England: Addison-Wesley. p. 126. ISBN 0-201-18483-4.
  12. ^ 윌슨과 클라크, op. cit., p. 52
  13. ^ Wexelblat, op. cit., p. 716
  14. ^ Kaminsky, Dan (2008). "Chapter 3 - Portable Executable and Executable and Linking Formats". Reverse Engineering Code with IDA Pro. Elsevier. pp. 37–66. doi:10.1016/b978-1-59749-237-9.00003-x. ISBN 978-1-59749-237-9. Retrieved 2021-05-27.
  15. ^ Collberg, Christian; Hartman, John H.; Babu, Sridivya; Udupa, Sharath K. (2003). SLINKY: Static Linking Reloaded. USENIX '05. Department of Computer Science, University of Arizona. Archived from the original on 2016-03-23. Retrieved 2016-03-17.
  16. ^ "Code Generation Library". Source Forge. Archived from the original on 2010-01-12. Retrieved 2010-03-03. Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.
  17. ^ Bresnahan, Christine; Blum, Richard (2015-04-27). LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400. John Wiley & Sons (published 2015). p. 82. ISBN 9781119021186. Archived from the original on 2015-09-24. Retrieved 2015-09-03. Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions.
  18. ^ https://all3dp.com/2/best-sites-for-free-3d-cad-models-cad-libraries/
  19. ^ "Slash CAD model build times with new AI-driven part creation methodology GlobalSpec".

추가읽기