Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Концептуальная модель предметной области информационной системы сети торговых точек
Концептуальная модель – это первая и очень важная ступень в процессе разработки программного обеспечения, которая непосредственно связана с объектно-ориентированным подходом в разработке. Концептуальная модель показывает понятия (сущности, объекты, классы) предметной области и взаимосвязь между ними. При принятии решения о включении или невключении понятия на концептуальную модель полезно руководствоваться следующими правилами: 1. В концептуальную модель должны попасть только те понятия, которые имеют существенное значение в контексте создаваемой системы. 2. На концептуальную модель должны попасть только понятия, а не их атрибуты. 3. На концептуальную модель не должны попадать списки понятий, за исключением тех случаев, когда этот список имеет собственное название. 4. Вполне допустимым является наличие на концептуальной модели понятий, которые не обладают никакими отличительными свойствами. С учетом приведенных правил включения или невключения понятий на концептуальную модель и приведенного выше варианта глоссария рассматриваемой предметной области можно построить следующую концептуальную модель, представленную на рис. П1.2.
Рис. П1.2. Пример концептуальной модели предметной области информационной системы сети торговых точек. Требования к информационной системе сети торговых точек Требование – это условие или возможность, которой должна удовлетворять система. Требования необходимо формулировать в виде простых законченных предложений, описывающих эти условия или возможности. Существует множество способов классификации требований. В данном случае применен упрощенный способ деления требований на функциональные и технические. В функциональных требованиях описывается, какие функциональные возможности хотелось бы видеть у проектируемой системы. Причем эти возможности описываются без уточнения подробностей. В технических требованиях описывается условия и возможности системы по хранению данных, по взаимодействию с другими системами (протоколы и т.д.), а также другие требования. Хорошо сформулированное требование должно обладать следующими свойствами: · Законченность. Каждое требование должно быть полностью законченным, т.е. в его описании должна содержаться вся информация необходимая для его понимания в контексте проектируемой системы и других требований.
· Слабая связанность. Следует стремиться к тому, чтобы требования были несильно связанны между собой. Требование необходимо писать так, чтобы его реализацию можно было бы легко отложить, и так, чтобы при изменении текста одного из требований остальные менялись минимально. · Последовательность. Требования должны описываться последовательно. Сначала должны идти требования, имеющие отношение к одному понятию или возможности системы, затем к другому и так далее. Последовательность нужна для облегчения понимания требований и удобства их чтения. Для формирования требований к системе можно использовать описание предметной области, а также список основных функций системы из документа «Видение». Процедура выделения требований к системе следующая. Попытайтесь мысленно представить вашу систему, и попытайтесь простыми предложениями описать, что она должна делать. Запишите эти предложения. Примерами таких предложений могут быть: «должна отображать список …», «должна постоянно хранить информацию о …», «должна получать информацию о … из внешней системы» и так далее. После того, как первый набросок требований сделан, попытайтесь расширить его за счет спецификации тех требований, которые необходимы для выполнения или поддержания уже написанных. Например, вы написали требование «Система должна предоставлять отчет о выручке и прибыли для определенного продавца». Из этого требования следует, что существует требование «Система должна хранить информацию о продавцах», а также «Система должна позволять вводить информацию о новых продавцах», «Система должна позволять редактировать информацию о существующих продавцах» и «Система должна позволять удалять информацию о продавцах». Можно выделить следующие рекомендации по оформлению требований: · Нумеруйте требования. Нумерацию удобно использовать для ссылки на требования. Ссылки на них могут встречаться в тексте других требований или в спецификации вариантов использования работы системы.
· Нумеруйте требований через десяток. Это необходимо для того, что соблюсти свойство последовательности изложения требований. Ведь, если вам нужно вставить новое требование между требованиями 7 и 8, а всего требований у вас 99, то вам придется перенумеровать все требования начиная с восьмого. Если же вам необходимо вставить требование между требованиями 70 и 80, то необходимость в такой перенумерации отпадает. Выполнение этой рекомендации еще удобно и потому, что в тексте требований могут встречаться ссылки на другие требования и в случае изменения номера требования, на которое имеется ссылка, необходимо будет изменить и ее. В случае же нумерации требований через десяток вероятность того, что номер требования когда-либо изменится очень мала. · Используйте только термины из глоссария. При описании запрещается использовать специальные термины, которых нет в глоссарии. Если вам необходимо употребить какой-либо термин, а его нет в глоссарии, то его необходимо туда внести, описать, и только потом употреблять (это вполне допустимо, ведь используется итеративный подход). · Не углубляйтесь слишком глубоко при спецификации требований. Определить, достаточно ли требований написано очень легко: если описаны все основные возможности системы, значит написание требований можно закончить. Качество написания требований можно лишь оценивать их пригодностью к использованию на более поздних этапах создания программного обеспечения. · Требования – это, прежде всего, требования заказчика. На первоначальном этапе заказчиком собственного программного обеспечения будете являться вы сами, но со временем у вас могут появиться уже реальные заказчики. Требования необходимо специфицировать именно с их точки зрения, а не с точки зрения каких-либо умозрительных заключений. Если заказчику требуется функция поиска, значит это требование, если нет, значит, такого требования не существует, несмотря на то, что его хочется включить в спецификацию требований. · Никакой реализации – только требования. Требование должно быть полностью абстрагированным от реализации. Недопустимым является употребление фраз типа «Система должны содержать таблицу Товары». На основании анализа предметной области и построенной концептуальной модели можно предъявить следующие требования к информационной системы сети торговых точек: Пример. Функциональные требования
Пример. Технические требования
Теперь рассмотрим фрагменты шагов Концептуальная модель иТребования к системе для информационной системы склада.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2021-04-04; просмотров: 341; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.138.114.38 (0.011 с.) |