Читать онлайн «Основы проектирования корпоративных систем». Страница 26

Если планируется, что разрабатываемый продукт будет развиваться, можно будет применить инкрементальную модель, хотя и не совсем подходящую, или спиральную модель. Ее преимущества в том, что она подходит для реализации постоянно развивающегося программного средства. А в нашем случае заказчик, вероятно, потом захочет добавить дополнительную функциональность: например, подключение систем электронных платежей (WebMoney, Яндекс. Деньги и т. д.), кредитных карт (нужен будет сервер приложений, осуществляющий верификацию данных пользователей, проверку наличия достаточных средств на карте и т. д.), отслеживание пути движения заказа, sms-информирование клиента и т. д. Однако спиральная модель может не очень хорошо подходить, если этап анализа рисков очень дорог. Но для нашего проекта можем обойтись упрощенным анализом рисков – спиральная модель будет приемлемым решением.

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

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

Рис. 4.1. Интерфейс интернет-магазина

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

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

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

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

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

Наименование продукта должно описываться текстовым полем ограниченной длины (например, 50 символов). Описание должно быть текстовым полем большей длины, по которому пользователь может понять, подходит ему товар или нет. Также должно быть изображение – обычное, цветное, статическое, объема порядка сотен килобайт. Возможно, одной фотографии будет недостаточно (это тоже можно обсудить с заказчиком). Поскольку в требованиях также говорится о доставке заказа, нужно определить такое понятие, как вес, потому что он выступает определяющим условием для типа и стоимости доставки. И, конечно, у продукта должна присутствовать цена. Это атрибут не конкретного экземпляра, а всего типа продуктов. Еще нужен некий внутренний код (артикул) для идентификации продукта (это тоже наводит на мысль об использовании СУБД).