Какие существуют платформы программирования

Framework vs Platform: в чём разница?

Привет, Хабр! Представляю вашему вниманию перевод статьи «Framework Vs. Platform What’s The Difference?» автора G. Harris.

Исповедуюсь: я педант. Несмотря на личные неудачи на этом поприще, я глубоко верю, что использование правильного языка добавляет множество преимуществ. Процитирую афоризм Марка Твена:

Разница между почти правильным словом и правильным словом действительно много значит. Это разница между светлячком (lightning bug) и молнией (lightning).

Ввиду этой разницы я вижу смысл в том, что время от времени меня раздражает недостаток ясности вокруг двух концепций фреймворк и платформа. Какая-нибудь платформа есть у любой компании в мире, которая имеет отношение к разработке. В мире опенсорса полно фреймворков. Но мало кто может определить эти концепции, будучи спрошен. Если я не способен дать чёткие определения базовой терминологии, могу ли я претендовать на полное понимание предмета обсуждения?

Я хотел бы предложить одно из возможных определений по аналогии.

Платформа — это нечто, что можно сравнить с коробкой-конструктором, которая была в комнате у моих детей, когда они были маленькими. Отдельные кубики являются компонентами. На идеальной платформе доступно множество разных комбинаций для сборки компонент, и может быть создан широкий спектр конечных продуктов. Платформы предлагают святой грааль повторного использования ПО: вот почему они так популярны.

Но каковы пререквизиты для построения платформы? Чтобы быть успешной, платформа должна отвечать некоторым обязательным техническим требованиям, и удовлетворить их — задача фреймворка.

• Сначала спросим, откуда взялось определение компонентной структуры? Возвращаясь к сравнению со строительными блоками, выбор доступных к использованию форм ограничен. Какие формы имеют смысл, будет зависеть от руководящих принципов, которые были выбраны с самого начала. Лежащая в основе фреймворка философия будет диктовать выбор возможных компонентных структур. Кстати, «компонент» — это еще одна из тех концепций, которая часто используется, редко продумана и обычно плохо определена. Тем не менее, привлечение простой аналогии сразу проясняет важность хорошо определённой (well-defined) концепции компонента.
• Следующий вопрос, который нужно задать, — это как собирать компоненты. Используется ли технология коннекторов, и как она работает? Конечно, наши компоненты могут быть похожи на деревянные кубики без реальных соединителей между блоками. Но для платформы этого недостаточно. Две возможные альтернативы можно увидеть у Lego ™ и Fischer-Price ™. Обе они позволяют присоединять другие блоки, добавив точки подключения (или порты) к каждому строительному блоку. В идеале именно так должны работать компоненты нашей платформы.
• Последнее ключевое замечание заключается в том, что отдельный строительный блок не знает о внутренней имплементации или свойствах всех остальных строительных блоков. У него есть только точки подключения (порты) и гарантия того, что он может работать вместе с любым другим компонентом, если соединитель (интерфейс) совпадёт. Компоненты являются анонимными, в очень точном смысле этого выражения. Обратите внимание, что это очень похоже на принцип взаимного забвения, выдвинутый Ральфом Вестфалом.

Фреймворк теперь можно определить как набор концепций, библиотек, инструментов и практик, которые обеспечивают:

1. Стандартизированную концепцию компонента для использования внутри платформы
2. Стандартизированную технологию коннекторов, которая обеспечивает коммуникацию между компонентами в платформе и сохраняет анонимность отдельных компонентов.

Платформа — это набор повторно используемых компонентов, которые были сконструированы в соответствии с принципами и философией платформы.

Возможны и другие определения, но я считаю именно эти определения чрезвычайно полезными.

Прошу заметить, насколько фундаментальной является концепция стандартизации в этом контексте. Задумайтесь на минуту о мире, в котором каждая электрическая вилка была уникальным продуктом ручной работы. Массовое производство электрических устройств никогда не станет индустрией в таком мире. То же самое относится и к платформе. Чтобы они могли играть в команде, все компоненты платформы должны иметь стандартизированную структуру и должны использовать стандартизированные концепции для взаимной коммуникации.

Я объяснил свою точку зрения: платформе требуется фреймворк в качестве основы. Фреймворк обеспечивает парадигмы компонентности и коммуникации. Он обеспечивает стандартизацию, необходимую для создания взаимозаменяемых компонентов. По мере того, как компоненты проектируются, создаются и тестируются, они становятся строительными блоками и вносят свой вклад в платформу. Фреймворк ограничивает степени свободы, которые доступны разработчикам. Он направляет и руководит их усилиями, чтобы достичь той критической степени стандартизации, которая требуется для успеха платформы.

Фреймворк может иметь дополнительные обязанности. В идеале он будет поддерживать концепцию причинно-следственных связей (по-немецки Wirkketten), позволяющую идентифицировать зависимости времени выполнения, потоки данных и потоки управления. Кроме того, он должен содержать (и скрывать) необходимый механизм для работы с параллелизмом. Но это послужит материалом для другой статьи.

Источник

Платформы разработки программного обеспечения (РПО)

Платформы разработки программного обеспечения (ПРПО, англ. Software Development Platforms, SDP) представляют собой любые программы, системы и сервисы, посредством которых потребности пользователей преобразуются в программное обеспечение

Сравнение Платформы разработки программного обеспечения (РПО)

Выбрать по критериям:

Платформы разработки программного обеспечения (РПО)

Руководство по покупке Платформы разработки программного обеспечения

1. Что такое Платформы разработки программного обеспечения

Платформы разработки программного обеспечения (ПРПО, англ. Software Development Platforms, SDP) представляют собой любые программы, системы и сервисы, посредством которых потребности пользователей преобразуются в программное обеспечение

2. Зачем бизнесу Платформы разработки программного обеспечения

Разработка программного обеспечения в компании — это процесс создания новых программных продуктов или улучшения уже существующих. Этот процесс может включать в себя разработку программного кода, тестирование, внедрение, обновление и поддержку программного обеспечения.

Целью разработки программного обеспечения является создание качественных и эффективных продуктов, которые решают задачи компании и улучшают ее бизнес-процессы. Разработка ПО может быть выполнена внутри компании или заказана у сторонних разработчиков.

В настоящее время для обеспечения деятельности по разработке программного обеспечения используется широкий спектр различных программных инструментов и платформ, поддерживающих различные процессы разработки от управления требованиями и проектирования до программной разработкий и управления качеством продуктов.

3. Назначение и цели использования Платформы разработки программного обеспечения

Платформы разработки программного обеспечения предназначены для создания и интеграции программных продуктов, которые могут быть использованы в различных отраслях и областях деятельности. Эти платформы обеспечивают разработчикам инструментарий для создания программного обеспечения, включая языки программирования, библиотеки и инструменты для тестирования и отладки.

Платформы разработки программного обеспечения включают в том числе средства разработки приложений, фреймворки, компоненты и утилиты, которые могут быть использованы для создания программного обеспечения на различных платформах и для различных операционных систем. Платформы разработки программного обеспечения также способствуют ускорению процесса разработки и снижению затрат на разработку программных продуктов.

4. Обзор основных функций и возможностей Платформы разработки программного обеспечения

Администрирование Возможность администрирования позволяет осуществлять настройку и управление функциональностью системы, а также управление учётными записями и правами доступа к системе. Импорт/экспорт данных Возможность импорта и/или экспорта данных в продукте позволяет загрузить данные из наиболее популярных файловых форматов или выгрузить рабочие данные в файл для дальнейшего использования в другом ПО. Многопользовательский доступ Возможность многопользовательской доступа в программную систему обеспечивает одновременную работу нескольких пользователей на одной базе данных под собственными учётными записями. Пользователи в этом случае могут иметь отличающиеся права доступа к данным и функциям программного обеспечения. Наличие API Часто при использовании современного делового программного обеспечения возникает потребность автоматической передачи данных из одного ПО в другое. Например, может быть полезно автоматически передавать данные из Системы управления взаимоотношениями с клиентами (CRM) в Систему бухгалтерского учёта (БУ). Для обеспечения такого и подобных сопряжений программные системы оснащаются специальными Прикладными программными интерфейсами (англ. API, Application Programming Interface). С помощью таких API любые компетентные программисты смогут связать два программных продукта между собой для автоматического обмена информацией. Отчётность и аналитика Наличие у продукта функций подготовки отчётности и/или аналитики позволяют получать систематизированные и визуализированные данные из системы для последующего анализа и принятия решений на основе данных.

5. Виды Платформы разработки программного обеспечения

Платформы разработки программных приложений Платформы разработки программных приложений (ПРПП, англ. Application Development Platforms, ADP) предоставляют разработчикам инструменты для создания программных приложений для различных областей применения: для интернет-сайтов, мобильных приложений, настольных приложений и серверных систем. Программные продукты в данной категории варьируются от минималистичных инструментов быстрой разработки до более сложных интегрированных сред разработки ПО. Системы тестирования программного обеспечения Программное обеспечение и системы тестирования программного обеспечения (СТПО, англ. Software Testing Systems, ST) предоставляют командам разработчиков инструменты и методы для управления качеством разрабатываемых программ в процессе разработки программного обеспечения Системы управления разработкой программного обеспечения Системы управления разработкой программного обеспечения (СУРПО, англ. Software Development Management Systems, SDM) предназначены для планирования и контроля за процессом разработки программного обеспечения, а также для поддержки общих задач работы команды Системы документирования программного обеспечения Системы документирования программного обеспечения (СДПО, англ.Software Documentation Systems, DOC) предназначены для решения задач создания проектной и эксплуатационной документации по программным продуктам, от импорта и создания контента до многоканальной публикации, перевода и использования документации Платформы разработки и эксплуатации программных систем Платформы разработки и эксплуатации программных систем (ПРЭ, англ. Software Systems Development and Operations Platforms, DevOps) предоставляют командам инструменты и возможности автоматизации разработки и эксплуатации ПО, необходимые для выполнения непрерывной поставки и управления. Системы анализа и проектирования программного обеспечения Системы анализа и проектирования программного обеспечения (САППО, англ. Software Analysis and Design Systems, SAD) предназначены для спецификации артефактов разработки ПО, в том числе требований, моделей, схем, диаграмм, алгоритмов для преобразования исходных требований аналитиками, проектировщиками и архитекторами пользователей в целостное решение

Источник