May 2013 Download this article as a PDFAbstract

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

Введение

Веб-приложения обычно собраны из ряда существующих компонентов, которые объединяются вместе для поддержки пользовательских бизнес-процесса. Они являются компонентами, такие, как Drupal и SugarCRM, которые предоставляют часто используемые функциональные возможности для управления содержимым и управление профилями пользователей. Код, который связывает компоненты называется «связующий код». Поскольку этот код является очень специфичным для собранных компонентов, это может быть трудно поддерживать и повторного использования.

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

В то же время приложения, созданные часто только отличаются в мелких деталях, и таким образом много времени впустую разработчиков, модификации и создания связующий код и узнать о новых компонентов API-интерфейсы. Более систематический подход к выбору компонентов и создание связующий код вызывается для – один, который уменьшает количество ненужных связующий код. Разработчики приложений могут учиться дисциплине программного обеспечения продуктовой линейки, которая касается систематического создания общих активов и методов для включения повторного использования продуктов в линейке. Этот подход пока широко не используется для разработки веб-приложений, но преимущества использования программного продукта line инженерный подход в три раза: i) в результате применения более легким в обслуживании, ii) время сохраняется при разработке приложения в результате повторного использования и iii) сведения об использовании конкретного компонента может быть скрыт от разработчика за общие интерфейсы.

Во вставке 1 приводятся примеры бизнес-процессов, которые разделяют многие их потребности и могли бы воспользоваться программного продукта line подход.

Вставка 1. Примеры с аналогичными требованиями бизнес-процессов

Тони, Фред и Боб являются владельцы бизнеса с очень схожими потребностями:

  • Тони хочет запустить акцию для своего ресторана. Когда обедающие оплатить счет, они также должны получить печатный билет, который вводит их в розыгрыше для приза. В конце периода акции выигрышные номера билета объявляются на доске в ресторане. Обедающие с выигрышный билет может выкупить его в ресторане.
  • Фред работает строительная компания и хочет генерировать потенциальных клиентов для своего бизнеса. Потенциальные клиенты могут ввести их электронной почты на веб-сайте компании, и они будут отправлены по электронной почте с билетом, который также вводит их в розыгрыше для приза. В конце акции победитель будет выбран и уведомление по электронной почте. Победитель может распечатать билет и выкупить его, посетив офис строительной компании.
  • Боб является владельцем независимого книжного магазина и хочет повысить лояльность своих клиентов. Клиенты могут получить скидку на будущие покупки, если они регистрируют свою электронную почту на сайте магазина. Когда клиенты делают покупки, они могут ввести число их квитанции на сайте, и они будут получать билет стоит 10% от денег, которые они провели, которые они могут выкупить на их следующей покупки.

Каждый из наших владельцев бизнеса трех подходов билеты R нас, чтобы разработать пользовательское приложение, которое реализует бизнес-процессы. Традиционно билеты R нас могли бы построил приложение для Тони, выбрали соответствующие компоненты – такие как платформы для поддержания базы данных билетов, печать штрих-код на билете и сканирования штрих-кода – и проводной их вместе с помощью клея код. При создании приложения Фред билеты R нас бы начали с кодом, разработанный для Тони, добавлена новая возможность отправить билет через электронную почту и сделал настроек существующего кода. Аналогично при создании приложения Боба, повторное использование будет ограничена клон и собственный подход.

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

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

Эта основная аудитория этой статьи являются компании, как Наша гипотетическая компания, билеты R нас, которые должны создать более простым в обслуживании приложений и достижения более высокой степени повторного использования.

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

Повышение уровня абстракции

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

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

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

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

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

Архитектура настраиваемого платформы

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

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

Рисунок 1

Рисунок 1. Архитектура настраиваемого платформы

Процесс

В этом разделе описывается процесс создания настраиваемых платформ и создания приложений, основанных на этой платформе. Преимущества этого подхода являются:

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

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

Требования записываются в виде формы целей и ожиданий (цель модели) и описания бизнес-процессов (сценарии). В исследованиях, которые мы проводили эти модели представлены в нотации требований пользователей (URN). Однако ради экспозиции, мы не будем вдаваться в подробности этой нотации, но относятся заинтересованного читателя к веб-сайт проекта. Для читателей, знакомых с вариантами использования и унифицированный язык моделирования (UML) мы могли бы добавить, что URN мосты между сценарии использования и объектных моделей в UML.

Процесс состоит из пяти шагов:

1. Моделирование домена требования

  • Соберите требования пользователей в форме целей и ожиданий (цель модели) и описания бизнес-процессов (сценарии) путем опроса владельцев бизнеса.
  • Цель модели создается для каждого владельца бизнеса или группы владельцев бизнеса, которые разделяют ту же функциональность. Конкретное определение ключа создается для таблицы конфигурации.
  • Отслеживаются связи между моделями цели и сценарии.

2. выявление общих черт и вариативности в модели требований

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

3. Моделирование требований приложения

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

4. определение существующих компонентов

  • Соответствующие компоненты сценария модели против компонентов программного обеспечения.
  • Определите параметры конфигурации для включения в таблицы конфигурации.

5. Привязка вариативности к компонентам

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

Вставка 2 Пример из первых двух этапов этого процесса. На рисунке 2 показано, как архитектура из рисунка 1 был создан для примера билеты R нас (шаги 3 – 5). Обратите внимание, что для целей иллюстрации, некоторые детали были удалены из схемы.

Вставка 2. Применение этого процесса к примеру билеты R нас (шаги 1 и 2)

В первом шаге (моделирование домена требования) мы захватить бизнес-владельца домена требования с точки зрения их целей и бизнес-процессов. Ниже приведены примеры требований на понятном языке:

  • Тони, владелец ресторана, хочет использовать акции, чтобы получить diners для возвращения. Его потребности включают способность генерировать билеты, распечатать их и позволить победителям выкупить билеты на приз.
  • Фред хочет использовать акции для создания потенциальных клиентов для его строительной компании. Помимо того, что способен генерировать билеты, он должен иметь возможность собирать адреса электронной почты от потенциальных клиентов.
  • Боб хочет повысить лояльность своих клиентов, давая им скидки на будущие покупки. Он также нуждается в своих клиентов, чтобы иметь возможность ввести свои продажи квитанции на сайте книжного магазина.

Обратите внимание, что «хочет» указать цели и «способности» указать шаги в бизнес-процессе.

На втором шаге (определение общности и вариативности в модели требований) мы смотрим за то, что распространено среди моделей и каким образом они отличаются. Например:

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

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

Примеры общих черт, которые требуют всех владельцев бизнеса включают:

  • запросы пользователей для ввода данных
  • Создание билетов
  • Выбор выигрышных билетов
  • выкуп Выигрышные билеты

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

  • Поддержка нескольких типов штрих-кодов на билеты
  • Отправка сообщений электронной почты победителей
  • регистрация и регистрация клиентов

Примеры компонентов кандидата:

  • Штрих-код PHP для создания и чтения штрих-кодов
  • PHP Mailer и SMTP в PHP для отправки писем
  • Рамки базы данных MyDB для PHP
  • Билеты R нас собственные компоненты для генерации билета случайных чисел
  • Билеты R нас собственные компоненты для проверки представленных билетов

Примеры параметров конфигурации включают:

  • текст, отображаемый на билетах
  • Тип штрих-кода
  • флаг, следует ли отправлять письма клиентам
  • срок действия акции

Рисунок 1

Рисунок 2. Создание архитектуры для примера

Заключение

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

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

Ключевые слова: веб-приложений, анализ требований, разработка линейки продуктов, быстрое прототипирование, настраиваемая платформа

Добавить новый комментарий

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.