Лекция
Привет, Вы узнаете о том , что такое isv, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое isv, independent software vendor, динамические библиотеки , статические библиотеки , библиотека , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
библиотека (от англ. Library ) - сборник объектов или подпрограмм для решения близких по тематике задач. В зависимости от языка программирования библиотеки содержат объектные модули или исходный код и данные , вспомогательные для задействования и интеграции новых возможностей в программные решения.
Библиотека может означать то же, что модуль или несколько модулей.
С точки зрения компьютерных наук библиотеки делятся на статические и динамические .
В некоторых языках программирования (например, в Python) то же, что и модуль, в некоторых — несколько модулей. С точки зрения операционной системы (ОС) и прикладного ПО, библиотеки разделяются на динамические и статические.
Термин «библиотека подпрограмм», по всей видимости, одними из первых упомянули Уилкс М., Уиллер Д., Гилл С. в качестве одной из форм организации вычислений на компьютере . Исходя из изложенного в их книге, под библиотекой понимался набор «коротких, заранее заготовленных программ для отдельных, часто встречающихся (стандартных) вычислительных операций»
Самые ранние концепции программирования, аналогичные библиотекам, предназначались для отделения определений данных от реализации программы . Компания JOVIAL привлекла внимание общественности к концепции COMPOOL (коммуникационный пул) в 1959 году, хотя она заимствовала идею из программного обеспечения SAGE для больших систем . Следуя принципам информатики разделения задач и сокрытия информации , «цель Comm Pool состояла в том, чтобы разрешить совместное использование системных данных между многими программами путем предоставления централизованного описания данных».
COBOL также включал «примитивные возможности для библиотечной системы» в 1959 году , но Жан Саммет в ретроспективе охарактеризовал их как «неадекватные библиотечные возможности».
Другой важный вклад в концепцию современной библиотеки внесла инновационная подпрограмма FORTRAN . Подпрограммы FORTRAN можно компилировать независимо друг от друга, но в компиляторе отсутствовал компоновщик . Таким образом, до введения модулей в Fortran-90 проверка типов между подпрограммами FORTRAN [NB 1] была невозможна.
Наконец, историки концепции должны вспомнить влиятельную Simula 67 . Simula был первым объектно-ориентированным языком программирования , и его классы были почти идентичны современной концепции, используемой в Java , C ++ и C # . Класс концепция Симула был также родоначальником пакета в Ada и модуль из Modula-2 . Даже при первоначальной разработке в 1965 году классы Simula могли быть включены в файлы библиотеки и добавлены во время компиляции
Могут быть в виде исходного текста, что подключается программистом в свою программу на этапе написания (например, для языка Fortran существует огромное количество библиотек для решения различных задач именно в исходных текстах), либо в виде объектных файлов, присоединяемых (линкуються) до выполняемой программы на этапе компиляции (в Microsoft Windows такие файлы имеют расширение .lib, в UNIX -подобных ОС - обычно .a). В результате программа включает все необходимые функции, что делает ее автономной, но увеличивает размер.
Статическая библиотека — объектный файл в виде файла (нередко может быт поставлен вместе с исходным кодом), код из которого выборочно или полностью вставляется в программу на этапе компоновки.
Библиотеки, распространяемые в виде исходного кода, преобразуются транслятором в объектные файлы. Затем компоновщик соединяет объектный из объектных файлов библиотек и объектные файлы вашей программы в один исполняемый файл.
Например, в исходных текстах распространяются:
Библиотеки, распространяемые в виде объектных файлов, уже готовы к компоновке. Компоновщик выполняет соединение объектных файлов библиотек и объектных файлов вашей программы во время создания исполняемого файла.
Расширения объектных файлов статических библиотек в разных ОС.
| Расширение | ОС |
|---|---|
| «a» | UNIX |
| «lib» | Microsoft Windows |
Стандартные библиотеки многих компилируемых языков программирования (Fortran, Pascal, C, C++ и других) распространяются в виде объектных файлов.
Достоинства:
Недостатки:
Также называются распределяемыми библиотеками ( англ. Shared library ), или библиотеками, динамически подключаемых ( англ. Dynamic Link Library , DLL). Это отдельные файлы, предоставляющих программе набор используемых функций для скачивания на этапе выполнения при обращении программы к ОС с заявкой на выполнение функции из библиотеки. Если необходима библиотека уже загружена в оперативную память , программа будет использовать загруженную копию библиотеки. Такой подход позволяет сэкономить время и память, поскольку несколько программ используют одну копию библиотеки, уже загруженную в память.
Динамические библиотеки хранятся обычно в определенном месте и имеют стандартное расширение. Например, файлы .library в логическом томе Libs: в AmigaOS; в Microsoft Windows и OS / 2 файлы библиотек общего пользования имеют расширение .dll; в UNIX -подобных ОС - обычно .so; в MacOS - .dylib.
При написании программы программисту достаточно указать транслятора языка программирования ( компилятору или интерпретатору ), что следует подключить такую-то библиотеку и использовать такую вот функцию с указанной библиотеки. Ни исходный текст, ни исполняемый код функции в состав программы не входит.
Динамическая библиотека — файл, содержащий машинный код. Загружается в память процесса загрузчиком программ операционной системы либо при создании процесса, либо по запросу уже работающего процесса, то есть динамически.
| Расширение | ОС | Расшифровка | Примечание |
|---|---|---|---|
| so | UNIX | англ. Об этом говорит сайт https://intellect.icu . shared object | |
| dylib | Mac OS | англ. dynamic library | |
| library | AmigaOS | Хранятся в логическом томе Libs: | |
| dll | Microsoft Windows, OS/2 | англ. dynamic link library |
В зависимости от назначения различают:
При написании программы программисту достаточно указать транслятору (компилятору или интерпретатору) путь к библиотеке и имя функции. Ни исходный текст функции, ни ее исполняемый код в состав программы не войдут.
Достоинства:
Недостатки:
Библиотека — файл, содержащий либо код на интерпретируемом языке, либо байт-код для виртуальной машины.
Например, библиотеки для языка Python могут распространяться либо в виде файлов с исходным кодом (расширение «py»), либо в виде файлов с байт-кодом (расширение «pyc», буква «c» от англ. compiled).
Хотя изначально динамическое связывание было впервые применено в 1960-х, оно не распространялось на операционные системы, используемые потребителями до конца 1980-х годов. К началу 1990-х годов он был доступен в той или иной форме в большинстве операционных систем. В этот же период объектно-ориентированное программирование(ООП) становилось важной частью программирования. ООП с привязкой во время выполнения требует дополнительной информации, которую традиционные библиотеки не предоставляют. Помимо имен и точек входа кода, расположенных внутри, им также требуется список объектов, от которых они зависят. Это побочный эффект одного из основных преимуществ ООП - наследования, что означает, что части полного определения любого метода могут находиться в разных местах. Это больше, чем просто перечисление того, что одна библиотека требует услуг другой: в настоящей системе ООП сами библиотеки могут быть неизвестны во время компиляции и варьироваться от системы к системе.
В то же время многие разработчики работали над идеей многоуровневых программ, в которых «дисплей», работающий на настольном компьютере, использовал бы услуги мэйнфрейма или миникомпьютера для хранения или обработки данных. Например, программа на компьютере с графическим интерфейсом будет отправлять сообщения на миникомпьютер, чтобы вернуть небольшие образцы огромного набора данных для отображения. Вызов удаленных процедур (RPC) уже выполнял эти задачи, но стандартной системы RPC не было.
Вскоре большинство производителей миникомпьютеров и мэйнфреймов инициировали проекты по их объединению, создавая формат библиотеки ООП, который можно было использовать где угодно. Такие системы назывались библиотеками объектов или распределенными объектами , если они поддерживали удаленный доступ (не все поддерживали). COM от Microsoft является примером такой системы для локального использования. DCOM, модифицированная версия COM, поддерживает удаленный доступ.
Некоторое время объектные библиотеки имели статус «следующей большой вещи» в мире программирования. Был предпринят ряд попыток создать системы, которые могли бы работать на разных платформах, и компании соревновались, пытаясь запереть разработчиков в их собственных системах. Примеры включают в себя IBM 's System Object Model (SOM / DSOM), Sun Microsystems ' Распределенные объекты Везде (МЭ), NeXT 's Portable Distributed Objects (PDO), Digital ' s ObjectBroker , от Microsoft Component Object Model (COM / DCOM) и любое количество систем на базе CORBA .
После того как маркетинговая ажиотаж поутих, объектные библиотеки продолжали использоваться как в объектно-ориентированном программировании, так и в распределенных информационных системах. Библиотеки классов являются грубым эквивалентом ООП старых типов библиотек кода. Они содержат классы , которые описывают характеристики и определяют действия ( методы ) с объектами. Библиотеки классов используются для создания экземпляров или объектов с определенными значениями характеристик. В некоторых языках ООП, таких как Java , различие очевидно: классы часто содержатся в файлах библиотеки (например, в формате файла JAR Java ), а созданные экземпляры объектов находятся только в памяти (хотя потенциально могут быть сделаны постоянными).в отдельных файлах). В других, таких как Smalltalk , библиотеки классов являются просто отправной точкой для образа системы, который включает в себя все состояние среды, классов и всех созданных объектов.
Другое решение проблемы библиотеки заключается в использовании полностью отдельных исполняемых файлов (часто в некоторой облегченной форме) и их вызове с помощью удаленного вызова процедур (RPC) по сети на другой компьютер. Такой подход максимизирует повторное использование операционной системы: код, необходимый для поддержки библиотеки, - это тот же код, который используется для обеспечения поддержки приложений и безопасности для любой другой программы. Кроме того, такие системы не требуют наличия библиотеки на том же компьютере, но могут пересылать запросы по сети.
Однако такой подход означает, что каждый вызов библиотеки требует значительных накладных расходов. Вызовы RPC намного дороже, чем вызов разделяемой библиотеки, которая уже была загружена на тот же компьютер. Этот подход обычно используется в распределенной архитектуре, которая интенсивно использует такие удаленные вызовы, особенно в системах клиент-сервер и серверах приложений, таких как Enterprise JavaBeans .
Библиотеки генерации кода - это API высокого уровня, которые могут генерировать или преобразовывать байтовый код для Java . Они используются аспектно-ориентированным программированием , некоторыми платформами доступа к данным и для тестирования для создания динамических прокси-объектов. Они также используются для перехвата доступа к полю.
Независимый поставщик программного обеспечения (англ. ISV, Independent Software Vendor) - компания, специализирующаяся на создании или продаже программного обеспечения, разработанного для продажи на массовом рынке или на специализированных (нишевых) рынках. Такие рынки могут быть разнообразными, например, программное обеспечение для риелторов (брокеров недвижимого имущества), работы с расписаниями для персонала больниц, считывания штрихкода, обслуживания склада и даже программного обеспечения для ухода за детьми, и т. п.
Специализированные продукты обычно дают организациям более высокую производительность в работе, чем «коробочное» программное обеспечение, такое, например, как электронные таблицы или базы данных в составе офисных пакетов. У самых больших компаний — разработчиков программного обеспечения, таких как Microsoft и IBM, есть специальные программы для ISV. Однако ISV создает и продает программные продукты, которые работают на одной или более компьютерной аппаратуре или платформах операционной системы. Компании, которые делают платформы, такие как Software AG, salesforce.com, BEA Systems, Microsoft, Novell, IBM, Sun Microsystems, Hewlett Packard, и Apple, поощряют и оказывают поддержку ISV-вендорам, часто со специальными программами «делового партнерства» .
В целом, чем больше приложений, которые работают на платформе, тем более ценным это является для клиентов. Конечно, изготовители платформ, такие как Microsoft и IBM, тоже создают приложения, но не имеют ресурсов и, во многих случаях, специальных знаний, которые требуются, чтобы создавать приложения всех видов.
Некоторые ISV сосредотачиваются на специфической операционной системе, такой как AS/400, для малого бизнеса компании IBM, для которой есть тысячи приложений, созданных ISV. Другие ISV специализируются в какой-либо частной прикладной области, такой как поддержка инженерных работников, или разрабатывают программное обеспечение, в основном для высокопроизводительных Unix-платформ автоматизированного рабочего места.
ISV создают и продают программное обеспечение, которое добавляется в программные платформы. Производители OEM-оборудования используют компоненты платформы аппаратных средств, чтобы на их основе построить продукты. Торговые посредники, добавляющие стоимость, включают программное обеспечение платформ в собственные пакеты программных продуктов.
Ранее мы рассматривали различие между инфраструктурным кодом и не инфраструктурным, который обычно называется основным кодом. Разницу между этими двумя понятиями можно резюмировать так: «все в vendor-каталоге - это код инфраструктуры».Но я не согласен с этим, и вот почему.
Вы можете не согласиться с таким утверждением, потому что у каждого свое собственное определение «инфраструктуры», которое превратит это утверждение в неправильное. Ознакомимся с текущей версией этого определения, которая состоит из двух правил, определяющих основной код. Любой код, который одновременно не отвечает двум этим правилам, должен рассматриваться как код инфраструктуры.
Следуя этому определению мы понимаем, что как только часть кода достигает чего-то за пределами работающего приложения (например, оно подключается к сети, касается файловой системы, запрашивает текущее время или случайные данные), его следует рассматривать как код инфраструктуры. Как только фрагмент кода может работать только в определенной среде (веб-приложение, приложение CLI и т. д.), он также должен рассматриваться как код инфраструктуры.
Эти правила ничего не говорят о том, расположен ли основной код в директории src/ или vendor/, и это справедливо. Представьте, что у Вас есть кусок кода, который Вы можете вызывать как основной код, потому что он соответствует его определению. Если Вы сейчас перенесете этот код в отдельный репозиторий на GitHub, опубликуете его как пакет и установите его в каталоге vendor/ вашего проекта с помощью Composer, станет ли этот кусок кода внезапно кодом инфраструктуры? Конечно, нет. Расположение кода не определяет, что это за код.
То что, если что-то является кодом вендора, не определяет, то что это код инфраструктуры. Разница заключается в том, можете ли Вы запускать этот код в полной изоляции, без предоставления внешних зависимостей и без какой-либо подготовки среды.
Это может напомнить Вам об определении модульного теста Майкла Фезера. Тест не является модульным тестом, если:
Он не может работать одновременно с другими Вашими модульными тестами Вы должны сделать специальные вещи для Вашей среды (например, редактирование файлов конфигурации), чтобы тест заработал. Тесты, которые делают эти вещи, не повредят. Зачастую их стоит писать, в модульном виде. Однако важно иметь возможность отделить их от настоящих модульных тестов, чтобы можно было сохранить набор тестов, которые мы можем быстро выполнять всякий раз, когда мы вносим свои изменения. Фактически, следуя указанному определению основного кода, мы можем заключить, что основной код - это единственный код, который можно тестировать модулем. Это не означает, что Вы не можете протестировать код инфраструктуры, это лишь означает, что такой тест нельзя считать модульным тестом. Такие тесты часто называют интегральными или интеграционными тестами.
Таким образом, нет строгой связи между кодом инфраструктуры и каталогом внутри вендора. Однако существует некоторая обратная связь: большая часть кода инфраструктуры Вашего приложения находится в каталоге вендора. Можно также сказать, что Вы пишете большую часть основного кода самостоятельно.
Давайте посмотрим на некоторые примеры кода, который расположен в вендоре, но не будет (согласно моим правилам) называться кодом инфраструктуры:
Библиотеки, которые занимаются только преобразованием данных (например, преобразователь или сериализатор данных), также могут рассматриваться как не инфраструктурный код. На практике Вы можете использовать следующий контрольный список, чтобы узнать, является ли код (где бы он ни находился, в src или в vendor) не инфраструктурным кодом:
Первое правило гарантирует, что код не имеет внешних зависимостей (сеть, файловая система и т. д.), которые должны быть доступны при вызове кода. Второе правило гарантирует, что Вам не нужно готовить какой-либо специальный контекст для запуска этого кода. Когда все это верно, это означает, что если Вы запускаете код и сталкиваетесь с проблемой (в тесте или во время регулярного использования), Вы будете знать, что это проблема с кодом. Это не будет связано с какими-либо инфраструктурными проблемами, поэтому Вы должны быть в состоянии решить ее, исправив код, который запускается.
Исследование, описанное в статье про isv, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое isv, independent software vendor, динамические библиотеки , статические библиотеки , библиотека и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем