Текст книги "Основы проектирования корпоративных систем"

Рис. 3.10. Жизненный цикл ПО, гибкие методологии, Agile

В заключение стоит еще раз отметить, что был рассмотрен ряд моделей – Build-and-fix, водопадная, быстрого прототипирования, инкрементальная, синхростабилизации, объектно-ориентированная, упоминалась эволюционная модель. Build-and-fix пригодна не для корпоративных проектов, а для небольших проектов с предсказуемым циклом развития и объемом порядка 1000 строк. Водопадная модель применима для корпоративных систем, обеспечивает четкую дисциплину проекта и хорошую управляемость, так как основана на большом количестве документов, которые производятся в ходе жизненного цикла, но в итоге из-за только одного прохода получившееся ПО может не соответствовать потребностям заказчика. Быстрое прототипирование несамостоятельно, в ряде случаев вызывает у разработчиков соблазн повторного использования быстро разработанного ненадежного, недокументированного кода. Способствует сопровождаемости и обеспечивает максимально ранний возврат инвестиций, так как приводит к консенсусу по поводу требований заказчика. Инкрементальная модель требует открытой архитектуры и может выродиться в Build-and-fix, но в целом удовлетворяет потребностям клиента из-за эволюционного процесса разработки продукта. Модель синхростабилизации обладает рядом преимуществ, но не получила широкого применения вне Microsoft. Спиральная модель пригодна в первую очередь для внутренних проектов, так как требует специфических знаний по оценке рисков. Объектно-ориентированная модель обеспечивает итерации и паралеллизм, но опять же при слабой дисциплине проекта может выродиться в модель Build-and-fix.

Рис. 3.11. Жизненный цикл ПО, гибкие методологии, Scrum

Рис. 3.12. Жизненный цикл ПО, гибкие методологии, eXtreme Programming (XP)

Глава 4
Выбор модели жизненного цикла корпоративных систем

В предыдущей главе были рассмотрены преимущества и недостатки основных моделей ЖЦ – Build-and-fix, водопадной (каскадной) модели, где проектирование корпоративных информационных систем происходит в один проход, модели быстрого прототипирования (несамостоятельной, так же как и Build-and-fix), инкрементальной, модели синхронизации и стабилизации Microsoft, которая в настоящее время смещается в сторону MSF, спиральной и объектно-ориентированной модели. Также были рассмотрены основные характеристики и особенности моделей, их основные достоинства и недостатки.

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

Итак, пусть требуется создать ПО, которое реализует программный проект построения многокомпонентной информационной системы, которая программно поддерживает интернет-магазин, осуществляющий торговлю этническими редкостями из Африки. Требуется оценить с точки зрения usability (удобства использования) сайт для торговли через Интернет этническими редкостями и сделать его более удобным в использовании. Обсудим этапы жизненного цикла проекта в связи с требованиями, которые возникли предварительно в ходе обсуждений с заказчиком. Этот выбор нужно сделать как можно раньше, потому что неверный выбор подхода к реализации системы может привести к неверному проектному решению, программной архитерктуре, в результате – к достаточно серьезным накладным расходам при проектировании, реализации и, что очень важно, сопровождении продукта.

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

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

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

Исходя из этих предпосылок перечислим модели. Build-and-fix – модель неполного жизненного цикла, которая содержит краткое описание стадий ЖЦ: первичное проектирование и анализ упрощены, документация присутствует не в полном объеме. Водопадная (каскадная) модель – один проход по всем стадиям жизненного цикла, жесткое документальное согласование каждого этапа с возможностью продолжения или прекращения работы. Модель быстрого прототипирования – несамостоятельная, может применяться как вспомогательная для уточнения технических характеристик. Инкрементальная модель, модель Microsoft (синхростабилизации); объектно-ориентированная модель, где есть взаимодействие и даже перекрытие этапов.

Какие модели можно исключить и почему? Модель Build-and-fix имеет смысл исключить сразу, если решение будет расширяться, а проект необходимо сопровождать. Конечно, этот проект может выйти за рамки 1000 строк, что является пределом для этой модели. Кроме того, программный продукт – законченное решение, включающее помимо кода множество документации: техническое задание (или другой документ со спецификацией требований), большое количество сценариев использования (десятки, сотни страниц), диаграмм, описывающих динамику поведения системы (переходов состояния, потоков данных, последовательности, взаимодействия, классов). Таким образом, модель Build-and-fix существенно ограничена и для данного проекта неприменима.

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

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

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

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

Какие модели могут быть использованы вполне, но с некоторыми замечаниями? Модель быстрого прототипирования будет в это случае вполне уместна. Естественно, не как самостоятельная, а как сопровождающая некоторую более серьезную модель. Она применима, потому что у заказчика нет в полной мере четкого представления о функционале и недостает технических знаний, чтобы очертить требования и оговорить функциональность, которая должна быть реализована. Поэтому очень сложно организовать диалог разработчика с заказчиком: они фактически говорят на разных языках. В этом случае на помощь приходит прототип, который как раз и проявит ту функциональность, о которой, возможно, мечтал заказчик, но не формулировал ее явно в силу ограниченности своих технических знаний. С другой стороны, она даст основания разработчику для того, чтобы корректно проектировать и реализовывать программный продукт, избавит разработчика и заказчика от непроизводительных потерь времени, людских ресурсов и средств. Для создания быстрых прототипов подходят технологии Microsoft (Visual Studio). Там существуют хорошие конструкторы визуальных форм и отчетов. Возможно достаточно быстро представить заказчику вариант интерфейса, включая командные кнопки, меню в стиле Windows, привычном заказчику, и обсудить с ним детали будущей реализации, на основе которых можно четче сформулировать технические требования и, что очень важно, определить окончательный выбор модели, поскольку все еще есть различные варианты.

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

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

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

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

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

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

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

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

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

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

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

Еще одним важным требованием будет работа с корзиной. У корзины тоже должны присутствовать атрибуты. Это количество товаров в корзине (общее и каждого вида), способ доставки, возможно, еще некоторые связанные атрибуты – способ оплаты и т. д. Также важны функции – способы, которыми пользователь будет оперировать с объектами в корзине. Здесь существует ряд функций, связанных с добавлением и удалением товаров (по одному, группой). Имеет смысл предусмотреть полную очистку корзины и удаление товаров по одному. И, наконец, оформление заказа. История заказов – вероятнее всего, таблица базы данных с полями: реквизиты заказчика (ФИО, логин), адрес доставки, дата заказа, номер заказа (первое, что спрашивает оператор в интернет-магазине).

Существуют вычисляемые поля: стоимость заказа, общее количество товаров, вес. Их не следует делать хранимыми, а имеет смысл вычислять.

Также необходимо определить технологии, которые будут присутствовать в списке требований. При этом мы должны детализировать несколько глобальных параметров. Это прежде всего вид интерфейса. Скорее всего он будет графическим. Интерфейс содержит окна, выпадающие списки, меню, командные кнопки (вход в систему, оформление заказа, дополнительные возможности). Таким образом, интерфейс должен делиться на графическую и логическую части. То есть это определенные классы элементов управления (будут ли это предопределенные классы. NET или разработанные вручную) и логическая часть (сценарии работы пользователя). При этом понятно, что работа осуществляется реализацией некоторых сценариев (например, вход – заказ – выход) и ряд сценариев вариативен.

В общей архитектуре системы имеется клиентская часть, которая уже была описана, и логика, а также есть некая часть, связанная с СУБД, где хранится каталог товаров и история заказов, плюс есть механизм, определяющий серверную часть реализации. Он работает с базой данных, извлекая из нее необходимую информацию, он передает эту информацию в интерфейс пользователя и содержит логику работы. Таким образом, это трехзвенная архитектура вида клиент – сервер. Далее нужно детализировать такие параметры, как тип СУБД (Oracle, Microsoft SQL Server и т. д. исходя из сроков реализации, объемов данных, используемой модели, интенсивности транзакций), язык и среда реализации (платформы Java или. NET, язык Java или C# исходя из опыта разработчиков и пожеланий заказчика; Java-решение может быть менее затратным), CASE-средства для создания, развития и поддержки продукта.

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

Порядок объема базы данных – сотни мегабайт. Если предусмотреть дополнительные или более высококачественные фотографии размером порядка мегабайта и если товаров порядка сотни, то размер БД будет порядка гигабайта. Сейчас это предварительные соображения, но в документ с требованиями необходимо внести данные о том, какого рода ограничение должно быть на объем данных сверху. Для определения интенсивности транзакций нужно сделать предположение, насколько сложные запросы к базе данных возможны, какова интенсивность транзакций, каков их механизм, какова пропускная способность интернет-канала, который будет узким местом в системе. Поэтому имеет смысл предусмотреть различные механизмы представления информации. Ряд пользователей будет заинтересован в более качественных фотоизображениях, поэтому необходимо оговорить тот порог, который предусматривается для пропускной способности, просто чтобы обезопасить себя от изменения факторов, за которые мы не можем отвечать. Если пропускная способность сети падает ниже возможностей модема, можно говорить о том, что система не сможет работать стабильно. Можно обсуждать с заказчиками скорость порядка десятков мегабит. В любом случае нужно четко описать и это количественное ограничение.

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

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

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

Особенности механизма авторизации. Система должна иметь возможность авторизации пользователей. Для простоты: пока есть один тип пользователей – покупатели. Каждый пользователь характеризуется именем пользователя и паролем. Пользователь может задать свое имя и свой пароль (возможно, полезна будет автогенерация паролей), сменить пароль в любое время сеанса работы с системой. Формулируются понятия авторизованного и неавторизованного пользователя: если пользователь не пытался войти в систему или ввел при входе некорректные имя и пароль, пользователь получает статус неавторизованного. В противном случае пользователь становится авторизованным. Это важные понятия, потому что в зависимости от состояния пользователя система предоставляет ему различные сервисы. Можно оговорить еще и количество попыток ввода имени и пароля. Также система должна выдавать адекватное сообщение об ошибке. Авторизованный пользователь должен иметь возможность выйти из авторизованного режима. Сохранять ли состояние корзины, нужно обсуждать с заказчиком.

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

Каталог продукции содержит список наименований, детальное описание продукта, изображение и цену. Нужно указать, всю ли линейку товаров поддерживает система и чем ее ассортимент ограничивается. Например, весь ассортимент продукции заказчика с ограничением на длину и вес.

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

Работа с корзиной. Корзина – промежуточное хранилище товаров в системе. При выборе продукции пользователь должен указать количество экземпляров данного наименования продукции (должно быть ограничение на него), способ доставки (явно перечисляем типы доставки, определенные в системе). Как только выбирается способ доставки, в корзине появляются данные о стоимости доставки (оговаривается алгоритм ее расчета). При этом авторизованный пользователь, в отличие от неавторизованного, должен иметь возможность работы с корзиной: добавление товаров, просмотр корзины, удаление товаров. В данном случае он имеет возможность как полностью очистить корзину, так и удалить товары поэлементно. Это тоже важно указать, чтобы при реализации системы у заказчика не возникло разночтений. При работе с корзиной авторизованный пользователь должен иметь возможность просмотра следующей информации: общая стоимость всей продукции (это вычисляемое поле, а не хранимое), общая стоимость доставки (также вычисляем ее как сумму стоимости доставки всех товаров), общий вес продукции (конечно, с учетом выбранного количества продукции), общая стоимость заказа. Здесь можно оговорить различные скидки (например, в зависимости от стоимости заказа или возраста пользователя). Естественно, пользователь не может изменить стоимость заказа.

Важным является понятие сессии: продукция в корзине пользователя хранится только в ходе одной сессии. Началом сессии можно считать вход в систему, концом – закрытие браузера или нажатие кнопки «Выход». Между этими двумя событиями происходит сессия. После окончания сессии пользователь становится неавторизованным и из корзины все удаляется.

Другое важное функциональное требование – способ оформления заказа. Естественно, оформление заказа возможно только после того, как пользователь выбрал необходимое количество товаров в корзине и нажал на кнопку «Оформить заказ». Таким образом, оформление заказа также доступно только для авторизованных пользователей – это явно указывается в документе. Заказ включает в себя всю продукцию из корзины и свойства доставки – эти атрибуты автоматически переносятся из корзины в заказ. Если нажата кнопка «Оформить заказ», он автоматически попадает в БД и не может быть отменен. Также важно, что после оформления заказа сессия продолжается, но вся продукция из корзины удаляется автоматически. Это тоже нужно явно отметить.

Список требований к системе по программным технологиям может выглядеть так:

Требования к системе: Технологии

• Интерфейс пользователя

Пользовательский интерфейс состоит из графического интерфейса пользователя и логической части

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

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

Пользовательский интерфейс реализован как Java-приложение (версия j2sdk 1.4.2). Графический интерфейс реализован с использованием Swing

Среда разработки – Idea 7.0.1

• База данных

Система хранит в базе данных всю статическую информацию: данные о каждой продукции (наименование, цена, вес, описание, указатель URL к графическому файлу), данные о цене доставки по земле и по воздуху, данные о заказах

В качестве СУБД используется PostgreSQL версии 8.2.4

• Обеспечение связи с базой данных

Для обеспечения связи с базой данных разработан модуль связи с БД. Модуль реализован на языке Java (версия j2sdk 1.4.2). Доступ к БД обеспечен с помощью JDBC (используется драйвер JDBC для PostgreSQL, postgresql-8.2-506.jdbc4.jar)

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