Методология и технология проектирования информационных систем. Учебное пособие для магистрантов направления подготовки 09.04.03 «Прикладная информатик

«сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней стадии разработки системы – стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализация данных) расходятся. Таким образом, единственно возможным средством преодоления данного пробела является определение соответствия между объектноориентированной и реляционной технологиями, которое в основном сводится к отображению диаграмм классов и диаграмм «сущность – связь» реляционной модели. Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между структурным CASE-средством Silverrun и объектно-ориентированным CASE-средством Rational Rose, разработанный российской компанией «Аргуссофт» .Это ПО создает диаграммы классов

Rational Rose на основе RDM-модели (Relational Data Model —

реляционная модель данных) Silverrun и наоборот. Аналогичные интерфейсы существуют также между CASE-

средствами ERwin (с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).

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

80

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

Вкачестве основных принципов используются:

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

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

–принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

–принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

–принцип непротиворечивости – заключается в обоснованности и согласованности использования элементов системы;

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

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными из них являются следующие [6]:

–SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

–DFD (Data Flow Diagrams) диаграммы потоков данных;

–ERD (Entity-Relationship Diagrams) диаграммы

«сущность-связь».

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

81

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

3.3. Методологии, стандарты инфологического моделирования и структурно-функционального проектирования ИС

Процесс проектирования включает в себя следующие этапы:

1.Инфологическое проектирование.

2.Определение требований к операционной обстановке,

вкоторой будет функционировать информационная система.

3.Логическое проектирование БД.

4.Выбор СУБД и других инструментальных программных средств.

5.Физическое проектирование БД.

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

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

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

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

Функциональный – реализует принцип «от задач» и применяется тогда, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания

82

информационных потребностей которых создаётся рассматриваемая БД.

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

Модель «сущность – связь» или ER–модель является комбинацией двух предыдущих подходов и обладает достоинствами обоих.

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

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают физически существующие (СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).

Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр

– конкретными значениями свойств.

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

83

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

Для каждой сущности выбираются свойства (атрибуты). При этом различают:

1.Идентифицирующие и описательные атрибуты.

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

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

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

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

Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности –

84

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

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

Каждая связь характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если вновь порождённый объект одного типа оказывается по необходимости связанным с объектом другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной.

По типу различают множественные связи «один к одному» (1:1), «один ко многим» (1: n) и «многие ко многим» (m: n). ER–диаграмма, содержащая различные типы связей, приведена на рис. 1. Обратите внимание, что обязательные связи на рис. 3.18 выделены двойной линией.

Рисунок 3.18 – ER–диаграмма с примерами типов множественных связей

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

85

сущностями ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ.

Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 3.19.

Рисунок 3.19 – Пример ER–диаграммы с однозначными и многозначными атрибутами

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

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

–объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

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

86

– образование классов и подклассов подобных объектов (например, класс «изделие» и подклассы типов изделий, производимых на предприятии).

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

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

Контрольные вопросы:

1.Что такое методология структурного анализа при исследовании ИС?

2.Каковы особенности модели стандартов IDEF?

3.Какими свойствами характеризуется проектирования SADT и семейства стандартов IDEF?

4.В чем заключается сущность структурного анализа и проектирования SADT?

5.Каковы особенности методологии и стандартов CASEсредства?

6.Уточните CASE-средства функционального и информационного анализа

7.Какие компоненты используются для структурнофункционального проектирования?

8.В чем преимущество методологии структурнофункционального проектирования ИС?

87

СПИСОК РЕКОМЕНДУЕМЫХ ИСТОЧНИКОВ

1. Круз, Р.Л. Структуры данных и проектирование программ : учебное пособие / Круз Р.Л., пер. с англ. 3-е издание — Москва : Лаборатория знаний, 2017. — 767 с. —

ISBN 978-5-00101-451-5. — URL: https://book.ru/book/922953

(дата обращения: 01.04.2021). — Режим доступа: по подписке БУКЭП. – Текст : электронный.

2.Ляндау, Ю.В. Бизнес-архитектор: проектирование систем управления. Часть 1. Проектирование систем управления : монография / Ляндау Ю.В. — Москва : Русайнс,

2017. — 111 с. — ISBN 978-5-4365-0976-1. — URL: https://book.ru/book/920746 (дата обращения: 01.04.2021). —

Режим доступа: по подписке БУКЭП. – Текст : электронный. 3.Грекул, В.И. Проектирование информационных

систем : курс лекций / Грекул В.И. — Москва : Интуит НОУ,

2016. — 570 с. — ISBN 978-5-9556-0033-8. — URL: https://book.ru/book/918134 (дата обращения: 01.04.2021). —

Режим доступа: по подписке БУКЭП. – Текст : электронный. 4.Методы и средства проектирования информационных

систем и технологий : учебное пособие. Бакалавриат : практикум / сост. Крахоткина Е.В. — Ставрополь : СевероКавказский федеральный университет, 2015. — 152 с. — URL: https://book.ru/book/928787 (дата обращения: 041.04.2021). —

Режим доступа: по подписке БУКЭП. – Текст : электронный. 5.Основы объектно-ориентированного проектирования :

курс лекций / Мейер Бертран — Москва : Интуит НОУ, 2016.

—765 с. — URL: https://book.ru/book/917854 (дата обращения:

01.04.2021). — Режим доступа: по подписке БУКЭП. – Текст : электронный.

5.Савельев, А.О. Проектирование и разработка вебприложений на основе технологий Microsoft : курс лекций / Савельев А.О., Алексеев А.А. — Москва : Интуит НОУ, 2016.

—437 с. — URL: https://book.ru/book/918133 (дата обращения:

01.04.2021). — Режим доступа: по подписке БУКЭП. – Текст : электронный.

88

Учебное издание

Шуваев Александр Васильевич

Методология и технология проектирования информационных систем

Учебное пособие

для магистрантов направления подготовки 09.04.03 «Прикладная информатика»

Оригинал-макет подготовлен на кафедре информационных систем Компьютерный дизайн Д. В. Ковалева

Подписано в печать 13.06.2021.

Отпечатано в типографии ООО «Ветеран» в полном соответствии с качеством предоставленного электронного оригинал-макета

89