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

 Концептуальная модель – это первая и очень важная ступень в процессе разработки программного обеспечения, которая непосредственно связана с объектно-ориентированным подходом в разработке.

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

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

2. На концептуальную модель должны попасть только понятия, а не их атрибуты.

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

4. Вполне допустимым является наличие на концептуальной модели понятий, которые не обладают никакими отличительными свойствами.

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

 

Рис. П1.2. Пример концептуальной модели предметной области информационной системы сети торговых точек.

Требования к информационной системе сети торговых точек

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

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

Хорошо сформулированное требование должно обладать следующими свойствами:

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

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

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

Для формирования требований к системе можно использовать описание предметной области, а также список основных функций системы из документа «Видение».

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

Можно выделить следующие рекомендации по оформлению требований:

· Нумеруйте требования. Нумерацию удобно использовать для ссылки на требования. Ссылки на них могут встречаться в тексте других требований или в спецификации вариантов использования работы системы.

· Нумеруйте требований через десяток. Это необходимо для того, что соблюсти свойство последовательности изложения требований. Ведь, если вам нужно вставить новое требование между требованиями 7 и 8, а всего требований у вас 99, то вам придется перенумеровать все требования начиная с восьмого. Если же вам необходимо вставить требование между требованиями 70 и 80, то необходимость в такой перенумерации отпадает. Выполнение этой рекомендации еще удобно и потому, что в тексте требований могут встречаться ссылки на другие требования и в случае изменения номера требования, на которое имеется ссылка, необходимо будет изменить и ее. В случае же нумерации требований через десяток вероятность того, что номер требования когда-либо изменится очень мала.

· Используйте только термины из глоссария. При описании запрещается использовать специальные термины, которых нет в глоссарии. Если вам необходимо употребить какой-либо термин, а его нет в глоссарии, то его необходимо туда внести, описать, и только потом употреблять (это вполне допустимо, ведь используется итеративный подход).

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

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

· Никакой реализации – только требования. Требование должно быть полностью абстрагированным от реализации. Недопустимым является употребление фраз типа «Система должны содержать таблицу Товары».

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

Пример. Функциональные требования

Номер	Текст
FR010	Система должна позволять просматривать информацию о продавцах, зарегистрированных в системе.
FR013	Система должна позволять вводить информацию о новых продавцах.
FR016	Система должна позволять удалять уволенных продавцов из системы.
FR017	Система должна иметь функцию отображения состояния склада. Т.е. списка товаров торговой точки с указанием текущего его количества на складе, цены и другой информации
FR019	При просмотре состояния склада необходимо предусмотреть поиск товара по названию
FR020	Система должна предоставлять возможность вводить информацию о поступлении товаров на торговую точку
FR030	Необходимо предусмотреть различие между вводом информации о поступлении абсолютно нового товара и товара, который продавался когда-либо на торговой точке
FR040	Система должна позволять вводить информацию о продажах товара за день (журнал продаж), а также информацию о фактической выручке, которую сдает конкретный продавец
FR042	Система должна предоставить функцию просмотра старых журналов продаж, позволяя искать их по дате создания и отчитывающемуся продавцу.
FR045	Система должна сохранять информацию обо всех поступлениях товаров и обо всех их продажах (расходах)
FR050	Система должна генерировать следующие отчеты: приход, расход и выручка. При этом общей для всех отчетов должна быть функция составления отчета за какой-то конкретный период.
FR060	Отчет приход должен содержать следующую информацию: · дата · код товара · наименование товара · количество поступившего товара · закупочная цена за единицу (для данного факта прихода товара) · всего затрат Кроме этого для всего отчета указывается сумма всех затрат на закупку товара.
FR065	Система должна позволять фильтровать отчет по строке, имеющейся в наименовании товара. Например: за период с 1 января 2000 года по 28 февраля 2000 года просмотреть отчет о поступлении товаров, у которых в наименовании имеется слово «Балтика». В такой отчет попадут все товары, у которых в названии встретилось слово «Балтика», и информация о приходе которых зафиксирована в системе в указанный период времени.
FR070	Отчет расход должен содержать следующую информацию: · № журнала продаж · дата · продавец · наименование · количество, которое имелось в наличии · проданное количество · количество, которое осталось в наличии · цена, по которой продан товар · сумма продажи · закупочная цена на момент продажи · полученная прибыль Кроме этого для всего отчета должна быть указана суммарная прибыль, полученная от продажи товаров, попавших в отчет.
FR075	Система должна позволять фильтровать отчет по строке в названии товара и продавцу, продавшему товар.
FR080	Отчет выручка и прибыль должен содержать следующую информацию: · № журнала продаж · дата · продавец · расчетная выручка · фактическая выручка · сумма недостачи · фактическая прибыль Кроме этого для всего отчета должна указываться суммарная фактическая прибыль.
FR085	Необходимо предусмотреть возможность фильтрации отчета по продавцу, сдававшему журнал продаж, на основе которого строится отчет.

Пример. Технические требования

Номер	Текст
TR010	Система должна обеспечить постоянное хранение информации о следующих объектах: · товар · продавец · журнал продаж а также информации о поступлении товара на торговую точку и о его расходе (продаже).
TR020	Система должна прозрачным для пользователя методом обращаться к базе данных с целью выборки необходимых ей данных, также изменения, сохранения и удаления данных.
TR030	Система должна быть реализована на языке Visual C++ в среде разработки Microsoft Visual Studio.

 

Теперь рассмотрим фрагменты шагов Концептуальная модель иТребования к системе для информационной системы склада.