Программная среда

Из Википедии, бесплатной энциклопедии
«Framework (информатика)» перенаправляется сюда. Чтобы узнать о других значениях, см. Фреймворк (значения) .

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

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

У фреймворков есть ключевые отличительные особенности, которые отличают их от обычных библиотек :

Обоснование [ править ]

Разработчики программных инфраструктур стремятся облегчить разработку программного обеспечения, позволяя дизайнерам и программистам посвящать свое время удовлетворению требований к программному обеспечению, а не работе с более стандартными низкоуровневыми деталями создания рабочей системы, тем самым сокращая общее время разработки. [2] Например, команда, использующая веб-фреймворк для разработки банковского веб-сайта, может сосредоточиться на написании кода, специфичного для банковского дела, а не на механике обработки запросов и управления состоянием .

Фреймворки часто увеличивают размер программ — явление, называемое « раздуванием кода ». Из-за потребностей приложений, ориентированных на потребности клиентов, в одном продукте иногда оказываются как конкурирующие, так и дополняющие друг друга платформы. Кроме того, из-за сложности их API запланированное сокращение общего времени разработки может быть не достигнуто из-за необходимости тратить дополнительное время на обучение использованию платформы; эта критика явно справедлива, когда сотрудники разработчиков впервые сталкиваются со специальной или новой структурой. [ нужна цитата ] Если такая структура не будет использоваться при последующих рабочих задачах, время, затраченное на ее изучение, может стоить дороже, чем специально написанный код, знакомый персоналу проекта; многие программисты хранят копии полезного шаблонного кода для общих нужд.

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

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

Эта тенденция в полемике поднимает важный вопрос о фреймворках. Создание элегантной структуры, а не структуры, которая просто решает проблему, по-прежнему является скорее ремеслом, чем наукой. « Элегантность программного обеспечения » подразумевает ясность, краткость и минимум отходов (дополнительные или посторонние функции, большая часть которых определяется пользователем). Например, для тех фреймворков, которые генерируют код, «элегантность» будет означать создание кода, который является чистым и понятным для достаточно знающего программиста (и который, следовательно, легко модифицируется), а не кода, который просто генерирует правильный код. Проблема элегантности заключается в том, почему относительно немногие программные платформы выдержали испытание временем: лучшие платформы смогли изящно развиваться по мере развития базовой технологии, на которой они были построены. Даже там, после развития, многие такие пакеты сохранят устаревшие возможности, раздувая окончательную версию программного обеспечения, поскольку замененные в противном случае методы сохраняются параллельно с более новыми методами.

Примеры [ править ]

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

Архитектура [ править ]

По словам Преи, [8] Программные платформы состоят из «замороженных» и «горячих» точек . Замороженные точки определяют общую архитектуру программной системы, то есть ее основные компоненты и отношения между ними. Они остаются неизменными (замороженными) в любой реализации среды приложения. Горячие точки представляют собой те части, где программисты, использующие инфраструктуру, добавляют свой собственный код для добавления функциональности, специфичной для их собственного проекта.

В объектно-ориентированной среде структура состоит из абстрактных и конкретных классов . Создание экземпляра такой структуры состоит из создания и создания подклассов существующих классов. [9]

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

При разработке конкретной программной системы с программной средой разработчики используют «горячие точки» в соответствии с конкретными потребностями и требованиями системы. В основе программных платформ лежит голливудский принцип : «Не звоните нам, мы позвоним вам». [10] [11] Это означает, что определяемые пользователем классы (например, новые подклассы) получают сообщения от предопределенных классов платформы. Разработчики обычно справляются с этим, реализуя суперкласса абстрактные методы .

См. также [ править ]

Ссылки [ править ]

  1. ^ Риле, Дирк (2000), Каркасное проектирование: подход к ролевому моделированию (PDF) , Швейцарский федеральный технологический институт.
  2. ^ "Рамки" . ДокФордж . Архивировано из оригинала 7 октября 2018 года . Проверено 15 декабря 2008 г.
  3. ^ Влиссидес, Дж. М.; Линтон, Массачусетс (1990), «Unidraw: основа для создания предметно-ориентированных графических редакторов», ACM Transactions on Information Systems , 8 (3): 237–268, doi : 10.1145/98188.98197 , S2CID   11248368
  4. ^ Джонсон, RE (1992), «Документирование фреймворков с использованием шаблонов», Материалы конференции по системам, языкам и приложениям объектно-ориентированного программирования - OOPSLA '92 , ACM Press, стр. 63–76, doi : 10.1145/141936.141943 , ISBN  0201533723 , S2CID   604969 {{citation}}: CS1 maint: дата и год ( ссылка )
  5. ^ Биррер, А; Эггеншвилер, Т. (1993), «Материалы Европейской конференции по объектно-ориентированному программированию», Структуры в области финансового инжиниринга: отчет об опыте , Springer-Verlag , стр. 21–35.
  6. ^ Хилл, К; ДеЛюка, К; Баладжи, В; Суарес, М; да Силва, А. (2004), «Архитектура системы моделирования системы Земли (ESMF)» , Вычисления в науке и технике , 6 : 18–28, doi : 10.1109/MCISE.2004.1255817 , S2CID   9311752
  7. ^ Гаше, А. (2003), «Программные платформы для разработки систем поддержки принятия решений – новый компонент в классификации инструментов разработки DSS», Journal of Decision Systems , 12 (3): 271–281, doi : 10.3166/jds.12.271- 280 , S2CID   29690836
  8. ^ Пре, В. (1994), «Меташаблоны: средство для отражения основ многоразового объектно-ориентированного проектирования», Труды 8-й Европейской конференции по объектно-ориентированному программированию , Конспекты лекций по информатике, 821 , Springer-Verlag : 150 –162, CiteSeerX   10.1.1.74.7935 , doi : 10.1007/BFb0052181 , ISBN  978-3-540-58202-1
  9. ^ Бушманн, Ф. (1996), Архитектура программного обеспечения, ориентированная на шаблоны, Том 1: Система шаблонов. Чичестер , Уайли , ISBN  978-0-471-95869-7
  10. ^ Ларман, К. (2001), Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и унифицированный процесс (2-е изд.), Prentice Hall , ISBN  978-0-13-092569-5
  11. ^ Гамма, Эрих ; Хельм, Ричард ; Джонсон, Ральф ; Влиссидес, Джон (1994). Шаблоны проектирования . Аддисон-Уэсли. ISBN  0-201-63361-2 .

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_framework&oldid=1189133939"