WikiDer > Доменная инженерия
Доменная инженерия, также называемый разработка продуктовой линейки, это весь процесс повторного использования базовые знания в производстве новых программного обеспечения системы. Это ключевая концепция систематического повторное использование программного обеспечения. Ключевой идеей систематического повторного использования программного обеспечения является домен. Большинство организаций работают только в нескольких областях. Они неоднократно строят похожие системы в пределах одной области с вариациями для удовлетворения различных потребностей клиентов. Вместо того, чтобы создавать каждый новый вариант системы с нуля, можно добиться значительной экономии за счет повторного использования частей предыдущих систем в домене для создания новых.
Процесс идентификации доменов, их ограничения и выявления общих черт и различий между системами в домене называется анализ предметной области. Эта информация фиксируется в моделях, которые используются на этапе реализации домена для создания артефактов, таких как повторно используемые компоненты, предметно-ориентированный язык, или генераторы приложений, которые можно использовать для создания новых систем в домене.
Цель
Разработка предметной области предназначена для повышения качества разрабатываемых программных продуктов за счет повторного использования программных артефактов.[1] Техника предметной области показывает, что большинство разработанных программных систем - это не новые системы, а, скорее, варианты других систем в той же области.[2] В результате, используя доменную инженерию, предприятия могут максимизировать прибыль и сократить время вывода продукта на рынок, используя концепции и реализации из предшествующих программных систем и применяя их к целевой системе.[1][3] Снижение стоимости очевидно даже на этапе внедрения. Одно исследование показало, что использование предметно-ориентированных языков позволяет использовать размер кода как в методы и количество символы, должно быть сокращено более чем на 50%, а общее количество строки кода будет уменьшено почти на 75%.[4]
Доменная инженерия фокусируется на сборе знаний, собранных во время программная инженерия процесс. Разрабатывая артефакты многократного использования, компоненты можно повторно использовать в новых программных системах по низкой цене и с высоким качеством.[5] Потому что это касается всех фазы цикла разработки программного обеспечения, доменная инженерия также фокусируется на трех основных фазах: анализ, проектирование и реализация, параллельная разработка приложений.[6] Это дает не только набор реализация программного обеспечения компоненты, относящиеся к предметной области, но также повторно используемые и настраиваемые требования и конструкции.[7]
Учитывая рост объемов данных в Интернете и рост числа Интернет вещей, подход доменной инженерии становится актуальным и для других дисциплин.[8] Появление глубоких цепочек веб-сервисов подчеркивает относительность концепции сервиса. Веб-сервисы, разработанные и управляемые одной организацией, могут использоваться как часть платформы другой организацией. Поскольку услуги могут использоваться в разных контекстах и, следовательно, требовать разных конфигураций, при проектировании семейств услуг может быть полезен подход к проектированию предметной области.
Фазы
Разработка предметной области, как и разработка приложений, состоит из трех основных фаз: анализ, проектирование и реализация. Однако там, где программная инженерия сосредоточена на Один системы, доменная инженерия фокусируется на семья систем.[6] Хорошая модель предметной области служит справочником для разрешения неоднозначности на более позднем этапе процесса, хранилищем знаний о характеристиках и определениях предметной области, а также спецификацией для разработчиков продуктов, которые являются частью предметной области.[9]
Анализ домена
Анализ домена используется для определения домена, сбора информации о домене и создания модель предметной области.[10] За счет использования особенности моделей (изначально задуманная как часть функционально-ориентированный анализ предметной области метод), анализ предметной области направлен на определение общих точек в домене и различных точек в домене.[11] За счет использования анализа предметной области разработка настраиваемый требования и архитектуры, а не статический возможны конфигурации, которые были бы созданы традиционным подходом к разработке приложений.[12]
Анализ предметной области существенно отличается от разработка требований, и поэтому традиционные подходы к получению требований неэффективны для разработки конфигурируемых требований, которые могут присутствовать в модели предметной области. Чтобы эффективно применять доменную инженерию, повторное использование необходимо учитывать на более ранних этапах жизненный цикл разработки программного обеспечения. За счет использования выбора функций из разработанных моделей функций рассмотрение возможности повторного использования технологии выполняется очень рано и может адекватно применяться на протяжении всего процесса разработки.[13]
Анализ предметной области основан в первую очередь на артефактах, полученных из прошлого опыта в данной предметной области.[10] Существующие системы, их артефакты (например, проектная документация, документы с требованиями и руководства пользователя), стандарты, а клиенты - все это потенциальные источники входных данных для анализа предметной области.[10][14] Однако, в отличие от разработки требований, анализ предметной области состоит не только из сбора и формализации информации; творческая составляющая тоже существует. В процессе анализа предметной области инженеры стремятся расширить знания о предметной области за пределы того, что уже известно, и разбить предметную область на сходства и различия, чтобы улучшить реконфигурируемость.[10]
Анализ предметной области в первую очередь дает модель предметной области, представляющий общие и различные свойства систем в домене.[10] Модель предметной области помогает создавать архитектуры и компоненты настраиваемым образом, выступая в качестве основы для проектирования этих компонентов.[15] Эффективная модель предметной области не только включает в себя изменяющиеся и согласованные функции предметной области, но также определяет словарь, используемый в предметной области, и определяет концепции, идеи и явления внутри системы.[10][16] В моделях функций концепции разбиваются на обязательные и дополнительные функции для создания полностью формализованного набора настраиваемых требований.[17]
Дизайн доменов
При проектировании предметной области используется модель предметной области, созданная на этапе анализа предметной области, и нацелена на создание общей архитектуры, которой могут соответствовать все системы внутри предметной области.[18] Точно так же, как в разработке приложений используется функциональный и нефункциональные требования Для разработки проекта на этапе проектирования предметной области используются настраиваемые требования, разработанные на этапе анализа предметной области, и создается настраиваемое стандартизованное решение для семейства систем. Дизайн домена направлен на создание архитектурных шаблонов, которые решают проблему, общую для систем в домене, несмотря на различные конфигурации требований.[19] Помимо разработки шаблонов во время проектирования предметной области, инженеры должны также позаботиться об определении области действия шаблона и уровня, на котором контекст имеет отношение к шаблону. Ограничение контекста имеет решающее значение: слишком много контекста приводит к тому, что шаблон неприменим ко многим системам, а слишком маленький контекст приводит к тому, что шаблон становится недостаточно мощным, чтобы быть полезным.[20] Полезный узор должен быть как часто повторяющимся, так и качественным.[21]
Целью проектирования предметной области является удовлетворение как можно большего числа требований предметной области при сохранении гибкости, предлагаемой разработанной моделью функций. Архитектура должна быть достаточно гибкой, чтобы удовлетворить все системы в домене, и в то же время достаточно жесткой, чтобы обеспечить прочную основу, на которой будет основано решение.[22]
Реализация домена
Реализация домена - это создание процесса и инструментов для эффективного создания настраиваемой программы в домене.
Критика
В последнее время доменная инженерия подвергается критике за то, что слишком много внимания уделяется «проектированию для повторного использования» или «разработке с повторным использованием» общих функций программного обеспечения, а не «разработке для использования», так что мировоззрение человека язык или контекст интегрированы в дизайн программного обеспечения.[23]
Смотрите также
Рекомендации
- ^ а б Фрейкс и Канг 2007, п. 2
- ^ Фрейкс и Канг 2007, п. 1
- ^ Чарнецкий и Эйзенекер 2000, п. 19
- ^ Баторий и др. 2002 г., п. 19
- ^ Чарнецкий и Эйзенекер 2000, п. 20
- ^ а б Чарнецкий и Эйзенекер 2000, п. 21 год
- ^ Харсу 2002, п. 8
- ^ Reinhartz-Berger et al. 2013, п. xii
- ^ Фалбо, Гуиззарди и Дуарте, 2002 г., п. 2
- ^ а б c d е ж Чарнецкий и Эйзенекер 2000, п. 23
- ^ Чарнецкий и Эйзенекер 2000, п. 38
- ^ Канг и др. 2004 г., п. 7
- ^ Канг и др. 2004 г., п. 3
- ^ Канг и др. 2004 г., п. 4
- ^ Фрейкс и Канг 2007, п. 3
- ^ Чарнецкий и Эйзенекер 2000, п. 84
- ^ Чарнецкий и Эйзенекер 2000, п. 86
- ^ Чарнецкий и Эйзенекер 2000, п. 24
- ^ Чарнецкий и Эйзенекер 2000, п. 25
- ^ Бушманн, Хенни и Шмидт 2007, п. 42
- ^ Бушманн, Хенни и Шмидт 2007, п. 31 год
- ^ Чарнецкий и Эйзенекер 2000, п. 28
- ^ Mettler 2017, п. 5
Источники
- Баторий, Дон; Джонсон, Клей; Макдональд, Боб; фон Хидер, Дейл (2002). «Достижение расширяемости с помощью продуктовых линеек и предметно-ориентированных языков: тематическое исследование». ACM Transactions по программной инженерии и методологии. ACM. 11 (2): 191–214. CiteSeerX 10.1.1.100.7224. Дои:10.1145/505145.505147. S2CID 7864469.CS1 maint: ref = harv (связь)
- Бушманн, Франк; Хенни, Кевлин; Шмидт, Дуглас К. (2007). Архитектура программного обеспечения, ориентированная на шаблоны: шаблоны и языки шаблонов. 5. Джон Уайли и сыновья. ISBN 978-0-471-48648-0.CS1 maint: ref = harv (связь)
- Чарнецкий, Кшиштоф; Эйзенекер, Ульрих В. (2000). Генеративное программирование: методы, инструменты и приложения. Бостон: Эддисон-Уэсли. ISBN 0-201-30977-7.CS1 maint: ref = harv (связь)
- Фалбо, Рикардо де Альмедиа; Гуиззарди, Джанкарло; Дуарте, Катя Кристина (2002). «Онтологический подход к доменной инженерии». Материалы 14-й Международной конференции по программной инженерии и инженерии знаний. ACM: 351–358. CiteSeerX 10.1.1.19.2577. Дои:10.1145/568760.568822. ISBN 1581135564. S2CID 16743035.CS1 maint: ref = harv (связь)
- Канг, Kyo C .; Ли, Джеджун; Ким, Киджу; Ким, Джерард Джонхён; Шин, Эйисеоб; Ха, Мунхан (октябрь 2004 г.). «ФОРМА: Функционально-ориентированный метод повторного использования с эталонными архитектурами, зависящими от предметной области». Анналы программной инженерии. Springer Нидерланды. 5: 143–168. CiteSeerX 10.1.1.95.7568. Дои:10.1023 / А: 1018980625587. S2CID 1830464.CS1 maint: ref = harv (связь)
- Фрейкс, Уильям Б.; Канг, Кё (июль 2007 г.). «Исследование повторного использования программного обеспечения: состояние и будущее». IEEE Transactions по разработке программного обеспечения. 31 (7): 529–536. CiteSeerX 10.1.1.75.635. Дои:10.1109 / це.2005.85. S2CID 14561810.CS1 maint: ref = harv (связь)
- Харсу, Маарит (декабрь 2002 г.). Обзор доменной инженерии (PDF) (Отчет). Институт программных систем, Технологический университет Тампере. п. 26. ISBN 9789521509322.CS1 maint: ref = harv (связь)
- Меттлер, Тобиас (2017). «Контекстуализация профессиональной социальной сети для здравоохранения: опыт исследования дизайна действий» (PDF). Журнал информационных систем. 28 (4): 684–707. Дои:10.1111 / isj.12154.CS1 maint: ref = harv (связь)
- Рейнхартц-Бергер, Ирис; Штурм, Арнон; Кларк, Тони; Коэн, Шолом; Беттин, Йорн (2013). Доменная инженерия: линейки продуктов, языки и концептуальные модели. Springer Science + Business Media. ISBN 978-3-642-36654-3.CS1 maint: ref = harv (связь)