Информационные системы в экономике

(?)Количество товара в накладной - это явный атрибут, но атрибут чего? Это атрибут не просто "товара", а "товара в накладной".

(?)Цена товара в накладной - опять же это должен быть не просто атрибут товара, а атрибут товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

Сумма накладной - явный атрибут накладной. Этот атрибут не является независимым. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

Наименование склада - явный атрибут склада.

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

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

Точно также поступим со связью типа M:N, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму (рис 8.17).



Рис 8.11. Конечная ER-диаграмма

8.5 Концептуальные и физические ER-модели

Разработанная выше ER-диаграмма является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенностей конкретной СУБД и не содержит особенностей реализации. По концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п. Физический вариант диаграммы, приведенной на Рис. 8.17 может выглядеть, например, следующим образом (рис 8.18).

Рис 8.12. Физическая ER-диаграмма



На физической диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST" и "CUST_DETAIL ", соответствующих сущностям "Накладная" и "Строка накладной ", появились новые атрибуты, которых не было в концептуальной модели(CUST_ID, SKLAD_ID). Это ключевые атрибуты родительских таблиц, мигрировавшие в дочерние таблицы для того, чтобы обеспечить связь между таблицами.

8.6 Резюме по ER-моделированию

Реальным средством проектирования данных является семантическое моделирование.

В качестве инструмента семантического моделирования используются ER диаграммы.

ER-диаграммы используют стандартные графические обозначения для моделирования сущностей и их связей.

Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме, становятся таблицами, атрибуты становятся столбцами таблиц, связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.

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



8.7 Применение ER-моделирования к построению информационной системы коммерческой фирмы

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

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

Техническое задание может содержать следующие пункты. Названия и примеры заполнения пунктов приведены далее.

Назначение проекта

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

Наименование разработки

Система управления базой данных (СУБД) по обслуживанию сельскохозяйственных предприятий компании. Пестициды и агрохимикаты.

Цель разработки

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

Задачи разработки

С целью эффективного обслуживания клиентов разработанная СУБД должна решать следующие задачи.

Ввод, хранение и анализ сведений о клиентах компании, их должностных лицах, местоположении.

Планирование, расчет и мониторинг заявок клиентов, их выполнения и оплаты.

Ведение справочника препаратов и агрохимикатов и условий их применения на культурных растениях против перечня вредящих объектов.

Мониторинг цен производителей препаратов и цен конкурентов - поставщиков.

Составление, расчет и выдача прайс-листов о предлагаемых товарах.

Планирование, расчет и мониторинг наших заявок поставщикам, их выполнения и оплаты.

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

Сбор и анализ информации по клиентам.

Эффект от внедрения

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

Средства выполнения работы

Персональная вычислительная техника типа IBM PC, теория и программы системы управления базами данных, опыт компании. В качестве основного программного инструментального средства разработки выбирается среда Visual FoxPro версии 5 и выше.

Содержание проекта

Разработка проекта ИС основана на методе сущностей и связей. СУБД относится к реляционному типу, то есть информация представляется в виде двумерных таблиц. Каждой информационной сущности соответствует отдельная таблица.

Информационные сущности

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

Информационные сущности, наборы данных.

Вредящие объекты

Против чего или для чего применяются препараты.

Действующие вещества препаратов

Показывает состав действующих веществ в каждом препарате.

Действующие вещества

Список химических составляющих, на основе которых изготавливаются препараты.

Должностные лица

Содержатся сведения о должностных лицах клиентов и поставщиков.

Заявки клиентов

Это заголовочная часть заявок клиентов нам. Табличная часть находится в Пунктах заявок клиентов.

Заявки компании

Для обслуживания клиентов мы берем (покупаем) товары у крупных поставщиков, которым хлопотно заниматься каждым отдельным потребителем.

Классы культур

Зерновые, овощи и прочее.

Классы препаратов

Инсектициды, фунгициды, регуляторы роста и прочее.

Клиенты

Сельскохозяйственные предприятия, которым мы продаем товары или оказываем услуги.

Культуры

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

Курс условной единицы

Курсы доллара и евро по отношению к рублю.

Менеджеры

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

Начисления по ФПК

Фонд поощрения клиентов (ФПК) организуется в компании с целью продвижения своих товаров на рынок.

Нормы расхода

Показывают какие препараты и нормы их расхода действуют на каких культурах, против каких вредящих объектов, в каких условиях применения.

Объемы, площади культур клиентов

Массы, количества и площади культур у каждого из клиентов. Позволяют определить потенциальную емкость рынка по товарам (препаратам).

Оплаты по ФПК

Оплаты заявок клиентов

Оплата заявки может проходить в несколько этапов и не привязывается к отдельным пунктам заявки.

Оплаты поставщикам

Поставки для компании

Поставки по заявкам клиентов

Каждый пункт заявки клиента может удовлетворяться в несколько поставок. Поставка понимается как поставка одного товара одному клиенту.

Поставщики

У них мы покупаем товары.

Поставщики товаров

Здесь указываются цены сторонних поставщиков на поставляемые ими товары в одной из трех валют.

Прайс-листы

Здесь содержится информация по прайс-листу в целом. Строки табличной части листов содержатся в сущности Пункты прайс-листов.

Препаративные формы

Препараты могут изготавливаться в виде порошка, суспензии, раствора и т.п.

Препараты

Производители товаров

Если производитель и продает товары, то его надо включить в Поставщики.

Пункты заявок клиентов

Табличная часть заявок клиентов нам.

Пункты заявок компании

Табличная часть наших заявок поставщикам.

Пункты прайс-листов

Список наших товаров и цены на них.

Районы

События клиента

События должностного лица

Субъекты федерации

Товары

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

Упаковки, виды тары

Связи

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

Модель насчитывает 36 связей между информационными сущностями. Все связи относятся к типу "один ко многим" (1:М), т.е. каждому объекту из одного набора соответствует 0 и более объектов из второго набора и каждому объекту из второго набора соответствует 0 или 1 объект из первого набора. Например, каждому клиенту соответствует 0 и более заявок, и каждая заявка относится не более чем к одному клиенту. Связи показаны на рисунке 1 линиями, причем сторона "многие" оканчивается трезубцем, а сторона "один" - крестиком.

Структура информационной модели

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

Рис 8.13.

Заметим, что на рисунке показано 37 сущностей. Две сущности: Семена и Удобрения, - не предполагаются входящими в состав проектируемой ИС. Они показывают место изменения системы при появлении новых видов потребностей клиентов.

Схема имеет несколько колец связей: Товары - Пункты наших заявок - Наши заявки - Поставщики - Поставщики товаров - Товары, Товары - Пункты заявки - Клиенты - Должностные лица - Поставщики - Товары, Клиенты - Объемы - Нормы расхода - Препараты - Товары - Пункты заявки - Клиенты. Ни один из модулей системы не должен обрабатывать все сущности кольца вместе.

Главной сущностью, как видно, является Товары - у нее 9 связей (система торговая). Вторая по важности - Клиенты - 8 связей (система обслуживающая). Третья сущность по важности - Препараты - 5 связей (система сельскохозяйственная).

Декомпозиция

С целью составления плана работ по реализации СУБД выделим из системы более или менее независимые подсистемы. При выделении выполним требование, чтобы каждая подсистема после реализации и внедрения решала определенную задачу в компании и приносила пользу.

При анализе общей структуры (рис 8.19) выделяются следующие подсистемы.

Справочник препаратов (рис 8.20).

Рис 8.14.



Подсистема обрабатывает 9 сущностей и 8 связей.

Справочник клиентов (рис 8.21).

Рис 8.15.

Подсистема обрабатывает 11 сущностей и 10 связей, из которых сущность Культуры формируется в подсистеме Справочник препаратов.

Поставщики и товары (рис 8.22).

Рис 8.16.

Подсистема обрабатывает 7 сущностей и 6 связей, из которых сущность Препараты формируется в подсистеме Справочник препаратов, а сущность Должностные лица формируется так же как в подсистеме Клиенты. При реализации имеет смысл разделить ее на 2 подсистемы: подсистему Товары, обрабатывающую сущности Товары, Упаковка, Препараты и Производители, и подсистему Поставщики, обрабатывающую сущности Товары, Должностные лица, Поставщики товаров и Поставщики.

Заявки клиентов (рис 8.23).

Рис 8.17.

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

Прайс-листы (рис 8.24).

Рис 8.18.

Самая простая подсистема. Обрабатывает 3 сущности и 2 связи, из которых сущность Товары формируется в подсистеме Поставщики и товары.

Заявки компании поставщикам (рис 8.25).

Рис 8.19.



Обрабатывает 6 сущностей и 5 связей, из которых сущности Товары и Поставщики формируются в подсистеме Поставщики и товары.

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

План работ

Последовательность этапов диктуется максимумом и комплексностью внедренных функций.

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

В таблице 8.1 находится календарный план выполнения работ по реализации СУБД и примерная стоимость.

Таблица 8.1. Календарный план

№ этапа	Наименование этапа	Сроки, месяцев	Стоимость, тыс. руб.	% от общей стоимости
1	Справочник препаратов	4	18	17
2	Справочник клиентов	4	20	19
3	Товары	2	6	5
4	Стыковка Товары и Справочник препаратов	1	4	4
5	Стыковка Клиенты и Справочник препаратов	0.5	1	1
6	Поставщики товаров	1	4	4
7	Стыковка Поставщики товаров с Товары и должностными лицами	0.5	2	2
8	Заявки клиентов	2	8	7
9	Стыковка Заявки клиентов с Товары и Клиенты	1	4	4
10	Прайс - листы	1.5	4	4
11	Стыковка Прайс-листы с Товары	0.5	2	2
12	Заявки компании	2	8	7
13	Стыковка Заявки компании с Товары и Поставщики товаров	1	3	3
14	Курс у.е.	0.5	1	1
15	Отладка системы в целом, непредвиденные расходы	3.5	21	20

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

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

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

Сетевой график выполнения работ показан на рис 8.26. Цифрами указаны номера этапов в соответствии с таблицей 8.1.

Рис 8.20. Сетевой график проведения работ



Минимальный срок исполнения системы - 15 месяцев. Ориентировочная стоимость работы 106 000 рублей. Сетевой график показывает также, какие этапы можно выполнять параллельно.

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

Примерный интерфейс

Главное окно. Главное меню. Многооконность. Форма навигации с фильтром. Форма обновления. Предварительный просмотр отчетов. Буферизация и откат данных.

Форма обновления всегда модальная. Форма навигации может быть немодальной.

Форма навигации содержит список, из которого выбирается объект, кнопки обновления: Добавить, Изменить, Удалить - и, возможно, кнопку фильтра по родительскому объекту (рис 8.27). При активизации родительский объект равен последнему использовавшемуся.

Рис 8.21. Форма навигации



Кнопки обновления вызывают форму обновления (рис 8.28), в которой можно редактировать информацию об объекте. Кнопки ОК и Отмена закрывают форму обновления. ОК вносит изменения в набор данных, Отмена не вносит изменений.

Рис 8.22. Форма обновления

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

Рис 8.23. Дочерние объекты

При задании справочных объектов (объект со стороны "1" на связи), например, Культуры к Нормам расхода использовать значение по умолчанию, в качестве которого берется объект последнего применения.

Замечание: Если имеется реализованная ИС для какой-либо предметной области, при помощи анализа интерфейса ИС можно восстановить и построить информационную модель.

Авторы проекта

Забиралов С.В., системный администратор компании;

Киселев В.Г., доцент финансового факультета ННГУ;

Хаванов С.В., генеральный директор компании.

Август 2002 года.

Приложение. Спецификации проекта

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

Текст приложения не приводится.



9. Рациональный унифицированный процесс

Опыт создания систем, начиная с программных систем, сконцентрировался в теории Рационального унифицированного процесса (РУП).

9.1 Основные понятия

С 70-х годов прошлого века до сегодняшних дней продолжается так называемый "кризис систем". Выражается он в том, что большие проекты выполняются с превышением сметы расходов и/или сроков, отведенных на разработку. Разработанные системы не обладают требуемыми функциональными возможностями, имеют низкую производительность и качество. По результатам исследований американской индустрии разработки систем, выполненных в 1995 году, только 16% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. 53% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. 31% проектов были аннулированы до завершения. Для двух последних категорий проектов бюджет, в среднем, оказался превышенным на 89%, а срок выполнения - на 122%.

Причины неудач:

нечеткая и неполная формулировка требований;

недостаточное вовлечение пользователей в работу над проектом;

отсутствие необходимых ресурсов;

неудовлетворительное планирование и отсутствие грамотного управления проектом;

частое изменение требований и спецификаций;

новизна и несовершенство используемой технологии;

недостаточная поддержка со стороны высшего руководства/

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

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

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

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

Начало - определение целей проекта.

Разработка- разработка плана и архитектуры проекта.

Построение - постепенное создание системы.

Внедрение - поставка системы конечным пользователям.

Рис 9.1. ЖЦ системы. Циклы, фазы, итерации



На рисунке 9.2 показано общее представление РУП в двух измерениях:

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

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

Высота графиков показывает трудоемкость процессов.

Рис 9.2.Общее представление РУП

9.2 Фазы

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

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

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

Построение. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению. На этой фазе описываются оставшиеся требования и критерии приемки, проект "обрастает плотью". Завершается разработка и тестирование системы.

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

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

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

Итак, главной задачей в начальной фазе является выработка требований, в фазе разработки - анализ и проектирование, в фазе построения - реализация, а в фазе внедрения - развертывание.

9.3 Рабочие процессы

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

моделирование процессов - описывается структура и динамика организации;

определение требований - описывается основанная на прецедентах постановка требований;

анализ и проектирование - описываются различные виды архитектуры системы;

реализация - собственно разработка компонент, автономное тестирование компонент и объединение системы;

тестирование - описываются проверочные сценарии, процедуры проверки и метрики для измерения числа ошибок;

развертывание - охватывает конфигурирование системы;

управление конфигурацией - управление изменениями и поддержание целостности проекта;

управление проектом - описывает разные стратегии работы с итеративным процессом проектирования;

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

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

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

9.4 Артефакты

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

Артефакты в Рациональном Унифицированном Процессе подразделяются на две области: административные и технические.

Технические артефакты, в свою очередь, делятся на четыре большие группы:

группа требований - описывает, что система должна делать;

группа проектирования - описывает, как система должна быть построена;

группа реализации - описывает сборку разработанных компонентов.

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

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

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

К группе реализации относится информация об элементах, из которых состоит система, а также информация о том, как собирать систему.

Группа развертывания сообщает о том, как система разбита на модули, в каком виде она поставляется, как устанавливается и запускается на площадке заказчика.

9.5 Модели

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

модель процессов - формализует структуру и деятельность организации;

модель предметной области - формализует место системы в окружающем мире;

модель прецедентов - формализует функциональные требования к системе;

аналитическая модель (необязательная) - формализует идею проекта;

проектная модель - формализует словарь предметной области и области решения;

модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;

модель развертывания - формализует способ связи аппаратных средств, на которых выполняется система;

модель реализации - описывает части, из которых собирается физическая система;

модель тестирования - формализует способы проверки и приемки системы.

Вид - это одна из проекций (точек зрения) модели. В Рациональном Унифицированном Процессе существует пять связанных друг с другом видов системной архитектуры. Т.е. архитектура системы и каждая модель рассматривается с точки зрения:

проектирования,

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

процессов,

Охватывает цепочки и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает производительность, масштабируемость и пропускную способность системы.

развертывания,

Охватывает способ связи аппаратных средств системы, на которой она выполняется. Этот вид связан с распределением, поставкой и установкой частей физической системы.

реализации,

Охватывает компоненты и документы, используемые для сборки и выпуска конечного продукта. Этот вид предназначен для управления версиями системы, которые могут по-разному объединяться между собой из независимых компонентов и документов;

прецедентов,

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

Рациональный Унифицированный Процесс особенно хорошо приспособлен к языку построения ИС UML.



10. Технология IDEF5 представления знаний

Стандарт IDEF5Метод сбора данных по описанию онтологий официально опубликован в США в 1994 году.

10.1 Основные принципы онтологического анализа

От древнегреческого: онтос - сущее, логос - учение, понятие.

Онтология-описание смысла терминов в какой-либо предметной области. Онтология может пониматься как структура представления знаний о мире.

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

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

На рис 10.1 приведена диаграмма IDEF5, на которой показано содержание термина "Домашнее животное" и его связи с термином "Человек".

Онтология - формализованное представление предметной области, которое включает словарь терминов и описания, как термины соотносятся друг с другом.

Понятие онтологии пересекается в информатике и лингвистике с понятием тезауруса.

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

Рис 10.1. Связь терминов в IDEF5

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

Построение онтологии, согласно технологии IDEF5 состоит из пяти действий.

Организация и обзор.

Это действие устанавливает основные цели онтологии, а также распределяет роли между участниками проекта.

Сбор данных.

На этом этапе происходит сбор и накопление начальных данных для построения онтологии.

Анализ данных.

Эта стадия заключается в анализе и группировке собранных данных и предназначена для построения терминологии.

Начальное развитие онтологии.

На этом этапе формируется предварительная онтология, а именно:

Создание словаря терминов.

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

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

Уточнение и утверждение онтологии.

Заключительная стадия процесса.

10.2 Язык описания онтологий в IDEF5

В IDEF5 существует два онтологических языка:

Схематический язык (Schematic Language-SL),

язык доработок и уточнений (Elaboration Language-EL).

Схематический язык SL - это графический язык. Он позволяет рисовать начальную стадию онтологии. Язык EL представляет собой структурированный текстовый язык, который позволяет детально характеризовать элементы онтологии.

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

Графические элементы языка SL представлены в таблице 10.1.

Всего существует четыре основных вида схем и диаграмм.

Диаграммы классификации предназначены для представления знаний о системе. Существует два типа таких диаграмм: Диаграмма строгой классификации DS и диаграмма естественной классификации NKC.



Таблица 10.1. Графические элементы IDEF5

Классы, элементы	Связи и изменения состояния	Процессы, соединения и перекрестки
Класс: Отдельный элемент:	Первичные связи: 1) Взаимосвязь многие со многими 2) Взаимосвязь двух классов Вторичные связи: Изменения состояния: 1) Слабое изменение 2) Сильное изменение 3) Мгновенное изменение	Процесс Соединения: Перекрестки:

10.3 Виды схем и диаграмм IDEF5

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



Рис 10.2. Диаграммы строгой классификации

Диаграммы естественной классификации NKC, наоборот, не предполагают того, что свойства класса являются необходимым и достаточным признаком для принадлежности к ним тех или иных объектов. Пример диаграммы NKC приведен на рис 10.3.

Рис 10.3. Диаграммы естественной классификации

Схема композиции.

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

Рис 10.4.Схема композиции

Схема связей.

Схемы связей первого порядка показывают связи между классами. На рис 10.5 показаны связи между классами (терминами) Планировщик, План трудовых ресурсов, Ресурс, Деятельность. Классы изображены кругами, связи изображены скругленными прямоугольниками на левом рисунке или стрелками на правом рисунке.

Рис 10.5. Схема связей первого порядка

Схемы связей второго порядка показывают связи между связями. На рис 10.6 показана иерархическая связь между связями типа "Часть чего-либо".

Рис 10.6. Схема связей второго порядка

информационный система автоматизация

Диаграмма состояния объекта.

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

Например, полученная в процессе нагревания теплая вода, уже относится не к классу ВОДА, а к его дочернему классу ТЕПЛАЯ ВОДА. Однако при описании процессаbцелесообразно разделять оба вида изменений. Для такого разделения используется обозначения следующего вида: "класс:состояние". Например теплая вода будет описываться как: "вода: теплая", холодная - "вода:холодная" и так далее. Пример диаграммы состояния приведен на рис 10.7.

Рис 10.7. Диаграмма состояния

Технология IDEF5 связана с технологией IDEF1X, которая оперирует с терминами в форме сущностей. Например, онтология рис 10.1 может быть представлена в IDEF1X следующей ER-диаграммой (рис 10.8).

Рис 10.8. Сравнительная ER-диаграмма

Также диаграммы состояния IDEF5, по сути, повторяют схемы объекта из IDEF3.

Язык EL позволяет представлять онтологии в текстовом описании. Он шире и строже чем схематический язык. В рамках нашей темы он не представлен.



10.4 Резюме по IDEF5

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

словаря терминов, используемых при описании объектов и процессов,

однозначных определений всех терминов словаря,

классификации логических связей между терминами.

Набор этих средств является онтологией системы, а стандарт IDEF5 предоставляет технологию для разработки и поддержки этой онтологии.

Размещено на Allbest.ru

...