Тема 5. Техника информационного моделирования Цель: - рассмотреть средства языка информационных моделей - объяснить технику информационного моделирования - научить читать информационные модели - научить составлять информационные модели Побочные цели: - показать, что основное преимущество формального описания системы состоит в концентрации внимания разработчиков на деталях (которые иначе были бы рассмотрены значительно позднее и привели к существенным переделкам проекта системы), и, как следствие этого - стимулировании постановки вопросов перед экспертами и перед самими собой. Содержание: 1. Назначение 2. История 3. Основные понятия 3.1. Объект 3.2. Атрибут 3.3. Связь 4. Понятие предметной области (домена) 5. Представление информационных моделей 6. Процедура моделирования 7. Пример "Мастерская" 1. Назначение На начальных этапах моделирования системы основные трудности связаны с определением целей системы и, в особенности, границ системы. Причиной этих затруднений является неполнота и нечеткость начального определения системы. "Мостиком" к более четкому определению целей системы и ее границ является анализ понятий, используемых при описании предметной области системы. Предметная область системы - это та часть мира, которая должна измениться после введения в эксплуатацию системы. Информационная модель является "инвентаризацией" понятий, которые требуются для описания этой части мира. Информационная модель предметной области является лингвистической моделью, т.е. толковым словарем специализированного языка, который будет использоваться на дальнейших этапах разработки. Информационная модель не является формальной, однако существенно снижает неопределенность и двусмысленность всех последующих моделей. Преимущества информационной модели: - первичная договоренность о терминологии описания системы между всеми участниками производственного процесса (заказчики, будущие пользователи, эксперты предметной области, аналитики, проектировщики, кодировщики и персонал сопровождения); - достижение лучшего понимания требований к системе, ее целей и границ; - информационная модель МОЖЕТ составить основу структуры системы (методы Coad-Yourdon, Booch, Shlaer-Mellor, Object Modelling Technique); Информационная модель позволяет аналитикам (совместно с заказчикам и экспертами) уточнить, какую именно часть предметной области будет составлять проектируемая система. На основе информационной модели предметной области составляется словарь основных объектов системы и ее окружения (существительные), операций системы (глаголы), словать событий и атрибутов объектов. 2. История Впервые идея информационных моделей и соответствующая нотация была предложена Peter Chen в 1976. Название модели, использованное в оригинальной работе - Entity-Relationship Model ("модель сущность-связь"). Эта техника предназначались в качестве средства описания структуры баз данных. Основная проблема, которую решала техника моделей "сущность-связь" заключалась в создании абстрактного механизма описания данных, с возможностью последующей реализации как в реляционных, так и в сетевых базах данных. Техника "сущность-связь" имела большой успех и продолжает использоваться и поныне. Одновременно начались попытки увеличения мощности оригинальной техники для использования ее в процессе производства программного обеспечения для описания требований к системам, для описания структуры систеты и т.д. Новое развитие техника информационного моделирования получила с распространением объектно-ориентированного подхода к анализу, проектированию и программированию. Наиболее распространенные современные версии техники "сущность-связь" называются "техника объектного моделирования" (OMT) и "информационное моделирование" в методе Shlaer-Mellor. В курсе представлен упрощенный вариант техники объектного моделирования. Большинство определений приводится по Shlaer-Mellor. Использование блочных диаграмм в качестве нотации для информационного моделей близко к Shaler-Mellor. Официальных стандартов на представление информационных моделей не существует. 3. Основные понятия 3.1. Объект 3.1.1. Определение Определение. Объект - это такая абстракция множества предметов реального мира, что: - все предметы в этом множестве (экземпляры) имеют одни и те же характеристики; - все экземпляры подчинены и согласовываются с одним и тем же набором правил поведения; Объект представляет собой один типичный, но неопределенный экземпляр чего-то в реальном мире. Заметим, что в языках объектно-ориентированного программирования это соответствует понятию класс. Каждый объект в модели должен быть обеспечен уникальным и значимым именем. 3.1.2. Нахождение объектов Обычно объекты относятся к одной из следующих категорий: - реальные объекты; - роли; - события; - взаимодействия; - спецификации; Реальные объекты - это абстракции фактического существования некоторых предметов реального мира. Роли - абстракции цели или назначения человека, части оборудования или организации. Событие - абстракция чего-то произошедшего или случившегося. Взаимодействие - абстракции отношений между другими объектами. Спецификации - абстракции правил, стандартов или критериев каческва (в отличие от реального объекта или роли, которые удовлетворяют этим стандартам). 3.1.3. Представление объекта 3.2. Атрибут 3.2.1. Определение Определение. Атрибут - это абстракция одной характеристики, которой обладают все абстрагированные как объект сущности. Каждый атрибут обеспечивается именем, уникальным в пределах объекта. Каждый атрибут имеет множество допустимых значений (домен). Определение. Идентификатор объекта - это множество из одного или более атрибутов, значения которых однозначно определяют каждый экземпляр объекта. Каждый объект должен иметь идентификатор. Объект может иметь несколько идентификаторов, каждый из которых составлен из одного или нескольких атрибутов. В этом случае, один из идентификаторов выбирается как привилегированный. Правило 1. Один экземпляр объекта имеет ровно одно значение для каждого атрибута в любой момент времени. Правило 2. Атрибут не должен содержать никакой внутренней структуры. Правило 3. Когда объект имеет составной идентификатор, т.е. состоящий из двух или более атрибутов, каждый атрибут, не являющийся частью идентификатора, представляет характеристику всего объекта, а не его части, а тем более не характеристику чего-либо другого. Правило 4. Каждый атрибут, не являющийся частью идентификатора, представляет характеристику экземпляра, указанного идентификатором, а не характеристику некоторого другого атрибута - неидентификатора. 3.2.2. Нахождение атрибутов Обычно атрибуты относятся к одной из следующих категорий: - описательные; - указывающие; - вспомогательные; 3.2.3. Представление атрибутов 3.3. Связь 3.3.1. Определение Определение. Связь - это абстракция набора отношений, которые систематически возникают между абстрагированными как объекты предметами в реальном мире. Симметричные/антисимметричные Физическая связь либо концептуальная связь Множественные ассоциации Атрибуты связи; моделирование связи как объекта Связь "Состоит-из" (агрегатная связь) "Наведенные" связи Объект А связан с объектом Б по связи С1, если существует другая связь С2 А с Б, причем экземпляр А связан с экземпляром Б по связи С1, если данный экземпляр А связан с экземпляром Б по связи С2. Обозначение С1=С2 Объект А связан с объектом Б по связи С1, если существует объект В, и объект В связан с объектом А по связи С2, а также объект В связан с объектом Б по связи С3, причем экземпляр А связан с экземпляром Б по связи С1, если существует экземпляр В, такой что экземпляр В связан с экземпляром А по связи С2, а также экземпляр В связан с экземпляром Б по связи С3. Обозначение С1=С2+С3 3.3.2. Формы связей Множественность бинарных связей Существует три фундаментальных вида связи: один-к-одному, один-ко-многим, многие-ко-многим. Связь один-к-одному существует, когда один экземпляр одного объекта связан с единственным экземпляром другого объекта. Связь один-ко-многим существует, когда один экземпляр некоторого объекта связан с одним или более экземплярами другого и каждый экземпляр второго объекта связан только с одним экземпляром первого. Связь многие-ко-многим существует, когда один экземпляр некоторого объекта связан с одним или более экземпляров другого, и каждый экземпляр второго объекта связан с одним или более экземпляров первого. Дополнительно, можно выделить безусловные и условные связи. Связь называется безусловной, когда для участия в связи требуется каждый экземпляр обоих объектов. В условной связи могут существовать экземпляры объектов, которые не принимают участия в связи. Связь называется биусловной, когда связь условная с двух сторон, т.е. могут существовать экземпляры обоих объектов, которые не участвуют в связи. 3.3.3. Представление связей 3.4. Подтип и супертип Множественное наследование 4. Понятие домена Прикладные домены Сервисные домены 5. Представление концептуальных моделей 6. Процедура моделирования 1) Идентифицировать реальные объекты (по ролевой модели) 2) Идентифицировать связи между объектами; для каждой связи дать имя связи идентифицировать роль связи с каждой стороны множественность связи с каждой стороны 3) Выявить множественные ассоциации для каждой множественной связи ввести "нереальный" объект (роль, событие, взаимодействие, спецификация) 4) при необходимости вернуться к 2) 5) Идентифицировать домены; составить диаграмму доменов 6) Разбить модель в соответствии с доменами; идентифицировать связи между доменами 7) По каждому домену проверить, нет ли излишних деталей; не являются ли некоторые из введенных объектов атрибутами других объектов; при необходимости удалить лишние объекты и/или связи; заменить объект атрибутом другого объекта; 8) Уточнить атрибуты связей 9) Идентифицировать наведенные связи 10) Верификация модели 11) Составить текстовое описание доменов 12) Составить словарь объектов и действий 13) Составить текстовое описание связей 7. Пример "Мастерская" 7.1. Текстовое описание доменов Домен Клиент Домен Отчет Домен Заказ Домен Цех 7.2. Словарь объектов Домен "Клиент" Клиент Квитанция Приемный пункт Прибор Обращение за починкой прибора Обращение за получением прибора Принять прибор Починить прибор Проверить квитанцию Оценить время починки прибора Домен "Отчет" МГУ Отчет Цех Запрос отчета Подготовить отчет Домен "Заказ" Заказ Домен "Цех" Мастер Курьер Починка прибора Доставка прибора Доставить прибор мастеру Возвратить прибор на приемный пункт Починить прибор 7.3. Текстовое описание связей Домен "Клиент" rq1 Клиент "сдает в починку" Приборы. Прибор "сдается в починку" Клиентом (Клиенты могут передавать Прибор друг другу, поэтому один и тот же Прибор может последовательно сдаваться в починку различными Клиентами). По-определению, Клиент "сдает в починку" хотя бы один Прибор. rq2 Клиент "использует" Приемные Пункты. Приемный Пункт "обслуживает" Клиентов. Может существовать Пункт, который не "обслуживает" ни одного Клиента, если не существуют Клиенты, которые "используют" данный Приемный Пункт. По-определению, Клиент "использует" хотя бы один Приемный Пункт. rq3 Клиент "выполняет" Обращения за починкой прибора. Каждое Обращение за починкой прибора "выполняется" ровно одним Клиентом. Обращение осуществляется за починкой определенного Прибора, т.е. связь наведенная. По-определению, Клиент осуществляет хотя бы одно Обращение. rq4 Клиент "получает" Квитанции. Каждая Квитанция "получена" ровно одним Клиентом. Клиент получает Квитанцию на определенный Прибор, который "сдан им в починку", т.е. связь наведенная. Могут существовать Клиенты, не получившие ни одной Квитанции. rq5 Обращение за починкой прибора "приводит к выписыванию" Квитанции. Каждая Квитанция "выписывается по" Обращению за починкой прибора. Существуют Обращения, по которым Квитанция не выписывается. rq6 Каждое Обращение за починкой прибора "связано с" определенным Прибором. Прибор может быть последовательно "связан с" несколькими Обращениями. rq7 Квитанция "выписывается на" Прибор. На один и тот же Прибор может быть последовательно "выписано" несколько Квитанций. Квитанция "выписывается на" тот Прибор, который сдают в починку, поэтому связь наведенная. rq8 Приемный Пункт "выписывает" Квитанции. Каждая Квитанция "выписана" в определенном Приемном Пункте. Может существовать Приемный Пункт, не выписавший ни одной квитанции (если в данный Пункт не производилось Обращений). Приемный Пункт "выписывает" квитанции по тем Обращениям, которые производятся в данный Пункт, поэтому связь наведенная. rq9 Приемный Пункт "обрабатывает" Обращения за починкой приборов. Каждое Обращение обрабатывается тем Пунктом, который "использовал" для этого Клиент, т.е. связь наведенная. rq10 Приемный Пункт "принимает" Приборы. Может существовать Пункт, который не "принял" ни одного Прибора (если данный Пункт не был использован ни одним Клиентом, либо если Пункт не выписал Квитанции ни на один Прибор). Пункт "принимает" только те Приборы, на которые "выписал" Квитанцию, т.е. связь наведенная. "Принятый" Прибор остается на Приемном Пункте. cl1 cl2 cl3 cl4 cl5 cl6 cl7 cl8 cl9 Домен "Отчет" rp1 rp2 rp3 rp4 rp5 rp6 Домен "Заказ" or1 or2 or3 or4 Домен "Цех" sh1 sh2 sh3 sh4 sh5 sh6 sh7 sh8 /*---------------------------------*/ BLOCK domains; SUBSTRUCTURE; BLOCK client_domain REFERENCED; BLOCK report_domain REFERENCED; BLOCK order_domain REFERENCED; BLOCK shop_domain REFERENCED; ENDSUBSTRUCTURE; ENDBLOCK domains; /*------- problem domains ------------*/ BLOCK client_domain; SUBSTRUCTURE; BLOCK client; ENDBLOCK; BLOCK unit; ENDBLOCK; BLOCK office; ENDBLOCK; BLOCK receipt; ENDBLOCK; BLOCK fix_request; ENDBLOCK; BLOCK unit_claim; ENDBLOCK; /* --- request --- */ CHANNEL rq2 FROM client TO office WITH uses; FROM office TO client WITH is_used_by; ENDCHANNEL; CHANNEL rq1 FROM client TO unit WITH fixes; FROM unit TO client WITH is_fixed_by{ordered}; ENDCHANNEL; CHANNEL rq3 FROM client TO fix_request WITH makes; FROM fix_request TO client WITH is_made_by<1>; ENDCHANNEL COMMENT rq3=rq1+rq6; CHANNEL rq4 FROM client TO receipt WITH receives; FROM receipt TO client WITH is_received_by<1>; ENDCHANNEL COMMENT rq4=rq1+rq7; CHANNEL rq5 FROM fix_request TO receipt WITH leads_to_issuing<1->; FROM receipt TO fix_request WITH is_issued_upon<1>; ENDCHANNEL; CHANNEL rq6 FROM fix_request TO unit WITH is_associated_with<1>; FROM unit TO fix_request WITH is_associated_with{ordered}; ENDCHANNEL; CHANNEL rq7 FROM receipt TO unit WITH replaces<1>; FROM unit TO receipt WITH is_replaced_by{ordered>; ENDCHANNEL rq7=rq5+rq6; CHANNEL rq8 FROM office TO receipt WITH issues; FROM receipt TO office WITH is_issued_by<1>; ENDCHANNEL COMMENT rq8=rq5+rq9; CHANNEL rq9 FROM office TO fix_request WITH processes; FROM fix_request TO office WITH is_processed_by<1>; ENDCHANNEL COMMENT rq9=rq2+rq3; CHANNEL rq10 FROM office TO unit WITH takes; FROM unit TO office WITH is_taken_by{ordered}; ENDCHANNEL COMMENT rq10=rq7+rq8; /*---- claim -----*/ CHANNEL cl1 FROM client TO receipt WITH uses; FROM receipt TO client WITH is_used_by<1>; ENDCHANNEL cl1=cl4; CHANNEL cl2 FROM client TO unit_claim WITH makes; FROM unit_claim TO client WITH is_made_by<1>; ENDCHANNEL; CHANNEL cl3 FROM unit_claim TO receipt WITH is_associated_with<1>; FROM receipt TO unit_claim WITH is_associated_with<1>; ENDCHANNEL; CHANNEL cl4 FROM office TO unit_claim WITH processes; FROM unit_claim TO office WITH is_processed_by<1>; ENDCHANNEL COMMENT cl4=cl2+rl2; CHANNEL cl5 FROM receipt TO office WITH is_checked_by<1>; FROM office TO receipt WITH checks; ENDCHANNEL COMMENT cl5=cl3+cl4; CHANNEL cl6 FROM unit_claim TO fix_request WITH corresponds_to<1>; FROM fix_request TO unit_claim WITH corresponds_to{ordered}; ENDCHANNEL COMMENT cl6=rq5+cl3; CHANNEL cl7 FROM client TO4 unit WITH receives; FROM unit TO client WITH is_received_by{ordered>; ENDCHANNEL COMMENT cl7=rq1; CHANNEL cl8 FROM unit_claim TO unit WITH lead_to_return<1->; FROM unit TO unit_claim WITH is_claimed{ordered>; ENDCHANNEL COMMENT cl8=rq7+cl3; CHANNEL cl9 FROM office TO unit WITH return; FROM unit TO office WITH is_returned_by{ordered}; ENDCHANNEL COMMENT cl9=rq7+rq8; ENDSUBSTRUCTURE; ENDBLOCK client_domain; /*--------------------------------*/ BLOCK report_domain; SUBSTRUCTURE; BLOCK mgu; ENDBLOCK; BLOCK report_request; ENDBLOCK; BLOCK report; ENDBLOCK; BLOCK vmk; ENDBLOCK; CHANNEL rp1 FROM mgu TO report_request WITH makes{ordered}; FROM report_requset TO mgu WITH is_made_by<1>; ENDCHANNEL; CHANNEL rp2 FROM report_request TO vmk WITH is_processed_by<1>; FROM vmk TO report WITH processes{ordered}; ENDCHANNEL; CHANNEL rp3 FROM mgu TO vmk WITH controls<1>; FROM vmk TO mgu WITH is_controlled_by<1>; ENDCHANNEL COMMENT rp3=rp1+rp2; CHANNEL rp4 FROM report_request TO report WITH leads_to_issuing<1>; FROM report TO report_request WITH is_issued_upon<1>; ENDCHANNEL; CHANNEL rp5 FROM vmk TO report WITH prepares{ordered}; FROM report TO vmk WITH is_prepared_by<1>; ENDCHANNEL COMMENT rp5=rp4+rp2; CHANNEL rp6 FROM mgu TO report WITH receives{ordered}; FROM report TO mgu WITH is_received_by<1>; ENDCHANNEL COMMENT rp6=rp1+rp4; ENDSUBSTRUCTURE; ENDBLOCK report_domain; /*--------- service domains ------------*/ BLOCK order_domain; SUBSTRUCTURE; BLOCK order; ENDBLOCK; BLOCK fix_request; ENDBLOCK COMMENT from client_domain; BLOCK office; ENDBLOCK COMMENT from client_domain; BLOCK unit; ENDBLOCK COMMENT from client_domain; CHANNEL or1 FROM order TO fix_request WITH corresponds_to<1>; FROM fix_request TO order WITH leads_to_creation_of<1>; ENDCHANNEL; CHANNEL or2 FROM order TO office WITH is_managed_by<1>; FROM office TO order WITH manages; ENDCHANNEL; CHANNEL or3 FROM order TO unit WITH manages_to<1>; FROM unit TO order WITH is_managed_by<1>; ENDCHANNEL; ENDSUBSTRUCTURE; ENDBLOCK order_domain; /*---------------------------------*/ BLOCK shop_domain; SUBSTRUCTURE; BLOCK master; ENDBLOCK; BLOCK repair; ENDBLOCK; BLOCK courier; ENDBLOCK; BLOCK delivery; ENDBLOCK; BLOCK unit; ENDBLOCK COMMENT from client_domain; BLOCK order; ENDBLOCK COMMENT from order_domain; CHANNEL sh1 FROM master TO unit WITH fixes; FROM unit TO master WITH is fixed_by{ordered}; ENDCHANNEL COMMENT sh1=sh5+sh2; CHANNEL sh2 FROM repair TO unit WITH is_associated_with<1>; FROM unit TO repair WITH is_associated_with{ordered}; ENDCHANNEL COMMENT sh2=sh4+sh3; CHANNEL sh3 FROM delivery TO unit WITH is_associated_with<1>; FROM unit TO delivery WITH is_associated_with{ordered}; ENDCHANNEL; CHANNEL sh4 FROM delivery TO repair WITH is_associated_with<1>; FROM repair TO delivery WITH is_associated_with<2>{ordered}; ENDCHANNEL; CHANNEL sh5 FROM master TO repair WITH makes; FROM repair TO master WITH is_made_by<1>; ENDCHANNEL; CHANNEL sh6 FROM delivery TO order WITH is_associated_with<1>; FROM order TO delivery WITH is_associated_with<2>{ordered}; ENDCHANNEL COMMENT sh6=sh7+sh8; CHANNEL sh7 FROM courier TO delivery WITH makes; FROM delivery TO courier WITH is_made_by<1>; ENDCHANNEL; CHANNEL sh8 FROM courier TO order WITH serves; FROM order TO courier WITH is_served_by<2>; ENDCHANNEL; ENDSUBSTRUCTURE; ENDBLOCK shop_domain;