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