Программирование в картинках. Rational Rose

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

1) предварительное проектирование,

2) эскизное (рабочее или техно-рабочее) проектирование,

3) изготовление, испытания и доводка опытного образца системы (рис. 4.3).

Рис. 4.3. Этапы концептуального проектирования.

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

В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность, внесение изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны “Заказчика”, так и “Разработчика”. Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения и чем позже эта потребность возникает. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа.

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

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

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

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

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

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

Результатом концептуальной стадии проектирования АИС является итоговый документ – “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.

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

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

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

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

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

Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.

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

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

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

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

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

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

Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики.

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

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

· итерационный характер процесса проектирования;

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

· жёсткая дисциплина проектирования и разработки при их коллективном характере;

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

ER-модели
Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В 1976 году Чен (Chen) предложил для проектирования ИС (баз данных) использовать ER-модели (Entity Relationship model – модель «сущность-связь»), представляющие концептуальные модели данных. Они получили широкое распространение в современных CASE-системах, поддерживающих автоматизированное проектирование ИС и обычно используются на этапе информационно-логического моделирования.

ER-модель наглядно изображает структурные блоки информации и логические взаимосвязи между ними. Основными понятиями являются сущность, связь и атрибут (см. Таблицу).

Таблица понятий: сущность, связь и атрибут.

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать много сотрудников. На рисунке приведен пример ER-диаграммы.

На основе ER-моделей последовательно формируют реляционные БД.

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

ГОСТ 24.602-86 . Автоматизированные системы управления. Состав и содержание работ по стадиям создания. (Введён с 01.01.89.–М.: Изд-во стандартов, 1986.–12 с.).

ГОСТ 34.601-90 . Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания (Введён с 29.12.90, 24.601-86. 24.602-86. 1997 г.).

ГОСТ 34.602-89 . Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Введ. 01.01.90.

ГОСТ 34.603-92 . Информационная технология. Виды испытаний автоматизированных систем.

РД 50-640-87 . Системы автоматизированного проектирования. Порядок выполнения работ при создании систем: Инструкция.–М.: Изд-во стандартов, 1987.–28 с. и др.

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

Апробированный результат научно-исследовательской работы (НИР) и научно-исследовательской опытно-конструк-торской работы (НИОКР) является предпочтительным для применения на предприятиях, так как дает возможности развития предприятия при определенных рисках. Первый вид испытанных научных результатов (идея НИР) является основой инновационного потенциала и отличается высокими рисками, которые практически оценить очень сложно. Поэтому такие результаты имеют развитие приоритетно на основе государственного управ-ления, которое выступает венчурным капиталистом.

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

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

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

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

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

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

Результирующими от созданной идеи могут быть: 1) проект; 2) программа; 3) направление научной и опытно-конструк-торской работы. Создание на основе полученного технико-технологического решения проекта определяет возможности бизнес-планирования, т.е. получение обоснованного организационно-экономического плана работы. Программа включает процесс исследований, результатом которых является комплекс взаимоувязанных инновационных проектов. Достижение организационно-экономической эффективности по программе осуществляется поэтапно на основе согласованного выполнения комплекса проектов. Отличительной особенностью инновационного направления является большая доля научных исследований, направленных на изыскание таких технико-технологиче-ских решений, которые могут обеспечить конкурентные преимущества предприятию в его развитии. Направление включает программы и проекты.

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

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

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

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

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

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

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

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

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

Рассматривая модели, используемые при решении задач проектирования, можно выделить:

Иерархическое описание и стратегии его формирования;

Теоретико-множественные модели;

Модели представления знаний: например: продукция как форма предоставления знаний; фреймы; сценарии; предикатные модели; модели представления данных.

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

В отношении событий, поддающихся контролю, намечаются действия, направленные на то, чтобы желательные события происходили, а нежелательные - нет;

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

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

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

Когнитивное моделирование технико-технологических объектов и систем определяет возможность комплексной увязки в информационную технологию трех компонентов: 1) концептуализации; 2) структурирования и 3) параметризации. Концептуализация должна быть целенаправленной, что предполагает применение категориального анализа и теории парадигмы.

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

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

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

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

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

Основные понятия, классификация

Одна из архитектур БД называется ANSI/SPARC.

Основной идеей является выделение трехуровневой абстракции в описании данных. Цель – отделение пользовательского представления БД от ее физического представления.

Причины, по которым желательно такое разделение:

Каждый пользователь должен иметь возможность обращаться к общим данным, используя собственное представление о них;

Пользователи не должны иметь дело с подробностями физического хранения данных;

Администратор БД должен иметь возможность изменять структуру БД, не оказывая влияние на представления пользователей;

Внутренняя структура БД не должна зависеть от изменений физических аспектов хранения информации, таких как переключение на новое устройство и т.д.;

Выделяются три уровня архитектуры БД – внешний, концептуальный и внутренний.

Внешний уровень – представление БД с точки зрения пользователей, состоит из нескольких внешних представлений, обычно соответствующих группам пользователей. Различные представления могут по-разному отображать одни и те же данные, также они могут включать вычисляемые данные, не хранящиеся в БД.

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

1. Все элементы данных.

2. Ограничения, накладываемые на элементы данных.

3. Семантическая информация о данных.

4. Информация о мерах обеспечения безопасностей и поддержки целостности данных.

Внутренний уровень – описывает реализацию БД и предназначен для обеспечения оптимальной производительности системы и экономного использования ее ресурсов с учетом конкретной СУБД.

Внутреннему уровню соответствует следующая информация:

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

2. Распределение дискового пространства для хранения данных и индексов.

3. Сведения о физической организации данных.

4. Сведения о сжатии данных и методах их шифрования.

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

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

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

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

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

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

Понятие сущности.

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

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

Характеристики сущности. Проблема уникальности сущности.

В общем случае, сущность – тип или класс различимых объектов. Основанием отнесения сущности к определенному классу является наличие у сущности характеристик (атрибутов), присущих классу. Отличие сущности от остальных сущностей класса производится на основании значений этих же характеристик.

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

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

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

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

В формате IDEFX сущность определяют следующим образом:

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

Связи. Понятие связи.

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

Пусть в предметной области существует факт – «студент обучается в группе». Это означает наличие взаимосвязи между сущностями студент и группа. При более детальном анализе выявляются дополнительные факты: студент одновременно может учиться только в одной группе, группа может состоять из многих студентов.

Такие взаимодействия отражаются как связи «один ко многим» и в стандарте IDEFX отражаются следующим образом:

В результате построения связи у сущности «студент» появился новый атрибут, помеченный FK (foreign key). Значение этого атрибута должно совпадать со значением первичного ключа сущности «группа».

В стандарте IDEFX связи «один ко многим» классифицируют по следующим признакам:

1) по возможности null-значения;

2) по степени зависимости связываемых сущностей;

3) по кардинальности;

1. Классификация связи по возможности null-значения . Продолжим пример со студентом. В какой-то момент времени студент может не принадлежать группе, например, когда студент находится в академическом отпуске или при переводе со специальности на специальность. Таким образом, атрибут «номер группы» в сущности «студент», кроме значения первичного ключа сущности «группа», может принимать null-значение.

Такая связь (с возможностью null-значения внешнего ключа) отмечается ромбом у сущности-предка.

Рассмотрим другой пример – «сотрудник работает в отделе». Проводим рассуждения, аналогичные предыдущему примеру. Если «каждый сотрудник должен работать в отделе», то между сущностями «сотрудник» и «отдел» имеется связь «один ко многим» без возможности неопределенного значения внешнего ключа. Она отображается также, только ромб у сущности-предка отсутствует.

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

071901 – первые 4 цифры – номер специальности, остальные – номер специализации. При этом номер специализации уникален в рамках специальности.

Сущности, подобные сущности «специализация», называются слабыми или зависимыми, и отображаются прямоугольниками со скругленными углами:

Связь называются идентифицирующей связью «один ко многим» и отображается не пунктирной линией и переносом первичного ключа сущности-предка в состав первичного ключа сущности-потомка. Разумеется, идентифицирующая связь не может допускать неопределенного значения внешнего ключа.

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

3. Классификация связи по кардинальности . Стандарт IDEFX поддерживает следующие кардинальности связи (рис 4):

Например, в группе должен быть хотя бы 1 студент.

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

Роль внешнего ключа.

Иногда для более точного описания предметной области вводится понятие роли атрибута для внешнего ключа. Роль – значение, которое атрибут несет, в сущности. Например, в примере о кураторе группы атрибут «табельный номер преподавателя» в сущности «группа» может играть роль «куратор». Если связь построена в обратном направлении, то внешний ключ играет роль «курируемая группа».

Бывают ситуации, когда введение роли внешнего ключа обязательно.

1) Например, когда между двумя сущностями присутствуют две или более связи → опишем бухгалтерскую проводку, которая характеризуется номером в пределах одной даты и суммой. Счет характеризуется номером, названием и разделом баланса. Между сущностями можно выделить две связи:

– «проводка кредитует счет» - один и тот же счет может кредитоваться различными проводками, а проводка кредитует только один счет → связь «один ко многим»; проводка не может не иметь счета кредитования, то есть связь не допускает неопределенного значения внешнего ключа; счет кредитования не участвует в идентификации проводки, поэтому связь не идентифицирующая;

- «проводка дебетует счет» - первичный ключ к сущности «счет» должен дважды войти в состав не ключевых атрибутов сущности «проводка», то есть обойтись без роли внешнего ключа нельзя:

2) в случае рекурсивной связи - когда родитель и потомок совпадают. Пример – иерархия подчинения в организации, когда для данного работника необходимо учитывать его непосредственного начальника:

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

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

2.Модель данных

Любая модель данных содержит три компоненты:

Описание структуры данных , т.е. описание объектов, на которых строится БД.

Ограничения целостности , т.е. набор правил, которые ограничивают множество экземпляров этих объектов, допустимых в БД.

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

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

Популярный подход к моделированию данных был предложен Питером Ченом в работе «Модель сущность-связь – к унифицированному виду данных». Этот подход основан на модели «сущность-связь» или ER-модели, обсуждению которой посвящена настоящая лекция.

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

3.Модель «сущность-связь». Семантические концепции

Укажем семантические концепции (конструктивные элементы), используемые в этой модели.

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

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

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

Рис. 1. Пример иерархии объектов

Иерархию типов не следует путать с иерархией данных. На рис.1 вовсе не подразумевается, что один сотрудник может иметь в подчинении нескольких программистов, наоборот, для одного экземпляра объекта "Служащий" существует максимум один экземпляр объекта "Программист", представляющий того же самого сотрудника в роли программиста.

Атрибуты и их классификация.

Напомним, что атрибут – это свойство объекта или связи, которое характеризуется именем и множеством допустимых значений.

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

Атрибуты также подразделяются на – однозначные и многозначные . Однозначный атрибут содержит только одно значение для каждого экземпляра объекта определенного типа. Многозначный атрибут может содержать несколько значений для каждого экземпляра объекта определенного типа . Например, название отделения или филиала компании -однозначныйатрибут, а номер телефона отделения – вообще говоря, многозначный (оно может иметь несколько номеров).

Еще одно разделение атрибутов – на базовые и производные. Базовый атрибут – это такой, значение которого не зависит от значений других атрибутов данного объекта или других. Производный атрибут - это такой, значение которого зависит от значений некоторого множества других атрибутов

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

Связи и их характеристики

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

Обсудим несколько важных общих характеристик связей:

Связь может быть определена на более чем двух объектах. Например, связь объектов "Отделение"-"Специализация"-"Предмет"-"Вид испытания" определяет перечень испытаний (экзаменов, зачетов, курсовых и пр.), которые необходимо выдержать студенту, обучающемуся по некоторой специализации на конкретном (например, "дневном") отделении. Эта связь определяется, в частности, на четырех сущностях.

Может существовать несколько связей, определенных на одних и тех же множествах объектов . Например, связи "Работает над" и "Руководит" определяются на совпадающих множествах объектов {"Проект", "Служащий"}.

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

Связь может определять зависимость существования (existence dependency) одного объекта от другого . Например, связь "Подчиняется" показывает, что существование экземпляра объекта в наборе "Подчиненный" зависит от присутствия экземпляра некоторого объекта в наборе объектов "Служащий".

Предпосылкой создания своей методологии явился такой диагноз С.П.Никанорова существующему положению в развитии организаций: происходит накопление несистемных решений, повсеместно распространяется сиюминутное, ситуационное мышление, которое приводит к, так называемому, феномену складывания - процессу произвольного возникновения чего-то под действием многих факторов, которые проявляются стихийно. Если что-то неэффективно работает, то часто говорят: «Так сложилось, никто не виноват». Следствием складывания являются неконтролируемые области жизни и возникающие проблемы, которые требуют действий для их решения.
У кого возникают проблемы? Они могут быть только у субъектов, то есть у тех, кто имеет возможности и имеет интересы. Проблема для субъекта и состоит в несоответствии интересов возможностям. Субъекты могут приблизительно одинаково воспринимать то, что происходит, но они относят его к своим интересам и возможностям, которые не поднимаются выше определенного уровня. Поэтому то, что происходит, не воспринимается ими как единая цельная проблема, что и приводит к несистемным решениям.
Какие есть подходы к решению этих проблем? Некоторые субъекты надеются управиться с ними с помощью проблемно-ориентированного подхода, при котором исследуются выявленные недостатки, сдерживающие достижение субъектом его целей. Рафинированная форма этого подхода - системный анализ, который использует идеологию целенаправленных систем. Но устранить феномен складывания с помощью проблемно- ориентированных методов невозможно, так как возникают не отдельные проблемы, а клубок проблем. И если стараться решить какую-нибудь одну проблему, то клубок проблем только увеличивается и спутывается, как и обычный клубок ниток при вытягивании одной нити. Надо разрубить клубок с помощью нормативного подхода, который основан на полагании желаемого класса систем. При создании систем этот подход должен координироваться с проблемно-ориентированным подходом. Нелепо устранять недостатки изжитой системы. Надо не проблемы решать, а строить все заново, подчиняя этой идее и свои интересы, и свои возможности. Рафинированной формой нормативного подхода являются системы с идеалом, к которому они должны стремиться.
Недостатком этих подходов, возникших в 60-х годах 20-го столетия и являющихся продуктами гонки вооружений, является отсутствие представления о развитии, в частности, о переходе из устаревшего качества в новое качество, которое задается последовательностью целей.
В начале 1970-х годов, задолго до осознания широкими кругами разработчиков бесперспективности создания автоматизированных систем на базе традиционных методологий, С.П. Никаноров сформировал новый методологический подход, в котором объектом автоматизированного проектирования являлись не АСУ, а системы организационного управления (СОУ) . К этим системам отнесены любые организации, в которых осуществлялось производство, управление, проектирование, обучение и другие виды деятельности с использованием компьютерных информационных систем. Идея о необходимости и проблемах проектирования организаций рассмотрена в предисловии к переведенной под его редакцией книге С.Янга ( в разделе 1).
На основе этого подхода к 1978-му году был выпущен технический проект автоматизированной системы проектирования (АСП) СОУ . Эта
АСП должна была разрешить проблему обеспечения управляемости процесса проектирования в условиях непрерывных изменений внутренней и окружающей среды, как проектируемой системы, так и проектирующей ее системы с помощью методов математического концептуального моделирования предметной области. Должен был быть обеспечен теоретический контроль проектных процессов, начиная от формирования первичного замысла и заканчивая рабочим проектированием и созданием организации.
Сущность методологии. Перед непосредственным проектированием системы организационного управления формируется ее общая математическая концептуальная модель. Процесс проектирования сводится к управляемой конкретизации общей модели и последующей ее интерпретации. Это обеспечивает целостность проекта системы, в отличие от традиционной технологии, когда проект является совокупностью автономно разрабатываемых частей. Полученный дедуктивным способом проект затем сопоставляется с исходными требованиями. При выявлении несоответствий концептуальная модель корректируется и затем осуществляется повторное проектирование.
Таким образом, в этой методологии процесс математической концептуализации является итерационным, и он не сводится к однозначной формализации объекта и процесса проектирования, как это имеет место, например, при проектировании теплоэнергетического комплекса, осуществляемого системой МАВР.
В разработанном техническом проекте АСП СОУ методы моделирования и проектирования были ориентированы на логически направленное и поэтому управляемое теоретическое и инструментально-технологическое проектирование. Прежде всего, обеспечивалась полнота понятийного пространства проектирования за счет логического формирования всевозможных комбинаций элементов понятийной конструкции с применением морфологического и иных методов. А математическая экспликация давала возможность оперировать понятийными конструкциями вне зависимости от прикладного содержания и знакового оформления.
Функции системы АСПСОУ показаны в табл.7.1. Теоретизация предметной области основывается на выявлении проблем, установлении их системной природы и возможных путей решения. При проектировании знаковой системы определяется состав баз данных, формы документов и т.п.
Таблица 7.1 Функции Выход Вход 1. Определение и реализация концепции теоретизации предметной области
Операционная трактовка теоретических схем. Определение процедур управления с их входами и выходами
Проектирование знаковой реализации СОУ и пространственно-временной привязки.
Документирование проекта СОУ 1. Модель (теория) предметной области
Проект системы организационного управления 1. Метамодели,
описывающие поня-тия организационных систем управления и их элементов
Метамодели формализованных теорий
Для реализации этой методологии был разработан набор теоретических схем, названных конструктами, используемых для формирования с помощью логических методов теории предметной области и модели объекта проектирования. Разработка конструктов и последующий синтез конкретных теорий с контролируемым формированием производных понятий осуществлялись с использованием математического аппарата теории структур Бурбаки . Были созданы различные технологии оперирования конструктами, позволяющие на их базе формировать сложные и при этом легко изменяемые понятийные схемы.
Из описания функциональной структуры видно, что, в отличие от системы концептуального программирования ПРИЗ (см.раздел 2), теории предметной области и модели объекта проектирования являются не входом, а выходом системы АСП СОУ. А уже затем формируются проекты СОУ, как производный результат логического вывода на построенных моделях предметной области и последующей интерпретации абстрактных математических конструкций. Входом в процесс проектирования являются сформированные с использованием заранее создаваемых абстрактных метаматематических схем (конструктов), метамодели, описывающие понятия СОУ и их элементов, и метамодели, описывающие имеющиеся формализованные теории, необходимые для моделирования СОУ. К ним относятся теории технических систем, теории производственных систем, теории целенаправленных систем и т.д. Новым здесь явилось также использование аксиоматического представления теорий.
Функциональная структура АСП СОУ
Универсальность этой методологии предопределяется сформированной общей метамоделью проектируемой системы с использованием
конструктов, которые имеются в памяти системы, и возможностями ее конкретизации при проектировании. Если при интерпретации конкретизированной метамодели с помощью понятий охватываемой предметной области, СОУ и ее элементов выявляется ее неадекватность, то выбираются, либо другие способы конкретизации, либо корректируется общая концептуальная модель.
Математические модели понятий формируются с использованием различных теорий таких, таких, как теория структур, теория множеств, категорная теория систем и т.д., в разных знаковых формах - текстах, таблицах, формулах, графиках и т.д., в разных языках, шрифтах и с разным размещением на различных носителях. Это может быть выражено с помощью, предложенной в 70-х годах С.П.Никаноровым, теоретической схемы, названной «логосинотопотех». В ней выделялась логическая сущность («лог»), представляющий ее знак («син») и место расположения знака («топ») на носителе («тех»). Главным в этой схеме было семантическое отношение: «лог» раскрывает смысл знакового представления «син».
В этом подходе объектом проектирования является и функциональная структура организации и процесс ее проектирования. Методология включает дедуктивный и индуктивный этапы проектирования. Дедуктивный этап осуществляется с помощью предварительно разработанных и сохраняемых в памяти метасистемы концептуальных аксиоматических описаний необходимых областей знаний в разных математических формах - теоретико- множественной, категорной, теоретико-системной конструктов в шкалах множеств Н. Бурбаки. Потом для сформированных метамоделей системы осуществляется выбор методов и, в конечном итоге, выбор технологий с использованием базы разных теорий, моделей, методов и средств.
Индуктивный этап наступает при контроле адекватности сформированных проектов и последующем итеративном корректировании начальных теоретических схем.
Применяемость рассматриваемой методологии для проектирования организаций ограничена ориентацией на специалистов высокой квалификации, владеющих инструментарием создания и использования математических конструктов, осуществляемого в течение последних трех десятков лет научным коллективом, возглавляемым С.П. Никаноровым.
В настоящее время имеется несколько сотен конструктов и набор методов оперирования ими. Силами сравнительно небольшого коллектива специалистов был разработан информационно-программный инструментарий для автоматизированной поддержки формирования математических метамоделей предметных областей с использованием накапливаемой базы конструктов. Были созданы автоматизированная система , обеспечившая запросный режим и выполнение операций синтеза, порождения, визуализации и т.д., синтаксический и семантический анализаторы, а также лингвистический интерпретатор родов структур. Дальнейшее развитие инструментария ориентировалось на поддержку процесса проектирования организационных процедур и форм документов.
К сожалению, для реализации этой методологии при ее появлении не были разработаны детальный технологический проект и полная инструментальная система. Для получения промышленного результата требовалось задействовать мощные организации, специализирующиеся на разработке информационно-программного обеспечения, на что была нужна серьезная государственная поддержка. Когда-то академик В.М.Глушков, директор Киевского института кибернетики, говорил, что создание общегосударственной автоматизированной системы (ОГАС) необходимо финансировать так же, как космические программы или атомную промышленность. Но, к сожалению, этого не произошло.
Рассматривая эту методологию с современных позиций, видно, что в ней недостаточно внимания уделялось непосредственному, конкретному моделированию и развитию действующих организаций в рамках теорий производственных и экономических систем. Она была ориентирована на разработку новых систем, что соответствовало существовавшей в тот период времени ориентации на создание автоматизированных систем производства, проектирования и управления.
Хотя формально тогда и требовалось проведение предварительного обследования и анализа действующих систем, согласно имеющейся регламентирующей документации, и даже были разработаны детальные методики диагностического обследования и моделирования организаций, но на практике это осуществлялось редко. При отсутствии соответствующего инструментария данный этап требовал огромных усилий и времени, а результат работы проектировщиков учитывался по сданному госкомиссии проекту новой системы и ее опытному внедрению.
При выбранном методе дедуктивного формирования проекта становится затруднительным переход к имеющемуся разнообразию содержания реальных процессов, при котором осуществляется модельная интерпретация, когда элементы модели отображают конкретные элементы систем организационного управления, обозначаемые терминами исходной области знаний. В метамодельной интерпретации термам теоретических конструкций приписываются так называемые лингвистические переменные. Но как перейти к конкретным элементам системы организационного управления, если предварительно не построена ее исходная модель? И как формировать для нее математическую модель с заданным набором определенных ограничений и целевой функцией, адекватной реальности?
Такие модели нужно было создавать при развитии действующих организаций и накапливать модели-прототипы для использования при проектировании новых систем. Но надо помнить, что использование этих моделей в наглядном виде стало возможным только после появления компьютеров с большим быстродействием и огромной памятью, а также инструментальных средств, обеспечивающих формирование таких моделей. Без таких моделей невозможно производить операционное сопоставление теоретических результатов с требованиями, заданными в исходной области знаний и определять адекватность использованных абстрактных схем.
С другой стороны, если имеется конкретная содержательная модель, построенная в понятиях исходной области знаний, а инструментальная система может логически обрабатывать и нематематические понятия, то необходимо обосновать целесообразность применения математических концептуальных моделей в условиях использовании сетей компьютеров с большой памятью и быстродействием.
При использовании рассматриваемой методологии следует учитывать, что, уменьшая разнообразие и удерживая разработку системы в определенных теоретических границах, применение конструктов одновременно огрубляет предметную область, ограничивая возможности понятийного моделирования профессионалов. Когда конструкт создается, то рассматривается и идеализируется некоторая сторона сущности. Будучи созданным, конструкт может иметь много материальных и знаковых воплощений, но при этом он отображает лишь математический аналог некоторой стороны сущности, а не саму содержательную сторону сущности, которую адекватно может воспринимать профессионал в этой области. При этом природа знаний в предметных областях зачастую такова, что фразы, с помощью которых общаются профессионалы, являются лишь намеком на образы реальной сущности, возникающие у них при обучении и в результате приобретения опыта. Эти образы активизируются при восприятии фразы в сознании специалиста, но для передачи смысла фраз специалистам из других областей знаний соответствующие образы требуют расшифровки намеков.
Проблемой является и обеспечение теоретического контроля процесса создания конструктов, в частности, обоснования выбора аспектов сущности, лежащих в основе разработки математических конструкций, и корректности ее выполнения. Используемые математические конструкты должны обеспечивать интеграцию методов и средств, имеющихся в разных предметных областях, выполняя функцию их теоретической надстройки. Учитывая огромную масштабность и сложность областей знаний, которые необходимо охватывать современному разработчику, эти конструкты могут выполнять и гносеологическую функцию.
В при анализе этого подхода отмечено, что он ориентирован на прямое обеспечение при проектировании систем желаемых их свойств. Но для его реализации необходимо накопить требуемые конструкты, обеспечивающие такие возможности, опробовать необходимые методы синтеза, конкретизации и интерпретации и их программное обеспечение, доведя его до промышленного уровня. Ограниченность применения этого подхода может быть связана с проблемами перехода от общих конструктов к имеющемуся понятийному разнообразию исходной области знаний, а также с тем, что его эффективно могут реализовать только специалисты, умеющие работать с конструктами.
Полная библиография публикаций по концептуальному анализу и проектированию за период с 1967 по 2003 год приведена в . В ней представлено 742 публикации, сгруппированные по алфавиту авторов, по годам публикации и по тематике. Авторский указатель охватывает 189 авторов, а тематический - 83 рубрики.