stringtranslate.com

Программная структура

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

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

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

Обоснование

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

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

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

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

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

Примеры

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

Архитектура

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

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

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

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

Смотрите также

Ссылки

  1. ^ Риле, Дирк (2000), Framework Design: A Role Modeling Approach (PDF) , Швейцарский федеральный технологический институт
  2. ^ "Framework". DocForge . Архивировано из оригинала 7 октября 2018 . Получено 15 декабря 2008 .
  3. ^ Влиссидес, Дж. М.; Линтон, М. А. (1990), «Unidraw: фреймворк для создания графических редакторов, ориентированных на определенную область», ACM Transactions on Information Systems , 8 (3): 237–268, doi : 10.1145/98188.98197 , S2CID  11248368
  4. ^ Джонсон, Р. Э. (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. ^ Хилл, C; ДеЛука, C; Баладжи, V; Суарес, M; да Силва, A (2004), «Архитектура структуры моделирования земной системы (ESMF)» , Вычислительная техника в науке и технике , 6 : 18–28, doi :10.1109/MCISE.2004.1255817, S2CID  9311752
  7. ^ Гаше, А. (2003), «Программные платформы для разработки систем поддержки принятия решений – новый компонент в классификации инструментов разработки DSS», Журнал систем принятия решений , 12 (3): 271–281, doi :10.3166/jds.12.271-280, S2CID  29690836
  8. ^ Pree, W (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: Система шаблонов. Чичестер , Wiley , 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.

Внешние ссылки