Концептуальное проектирование порой называют техническим. Его основными этапами являются:
1) предварительное проектирование,
2) эскизное (рабочее или техно-рабочее) проектирование,
3) изготовление, испытания и доводка опытного образца системы.
(ИС - информационная система!)
При проектировании, в т.ч. при решении проблем автоматизации процессов, обычно изначально принимается один из двух вариантов: создание системы решающей сиюминутные задачи или включающей и перспективные задачи (“на вырост”), учитывающие будущие потребности.
В первом случае можно выбрать недорогое решение и быстро его реализовать. Однако высока вероятность, что достаточно скоро такую систему потребуется в значительной степени модернизировать или заменить.
Во втором случае потребуется более серьёзная проработка требований и технических решений, влекущая за собой увеличение сроков выполнения и стоимости проекта.
Не следует упускать из виду, что быстрое развитие науки, техники и технологий приводит к быстрому старению используемых методов и систем, что отрицательно влияет на эффективность их использования. При этом поэтапно вносить изменения в отдельные компоненты системы значительно проще, чем заменять её полностью. Кроме того, обычно требуется обеспечить быстрый возврат инвестиций, что достаточно сложно организовать при внедрении комплексных решений.
Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.
При реализации крупных проектов обычно прибегают к помощи хорошо зарекомендовавших себя крупных компаний-интеграторов, в том числе консалтинговых и внедренческих организаций.
Для реализации средних проектов стараются обойтись своими силами и (или) используют готовые решения, которые стремятся адаптировать под конкретные требования организации-заказчика.
Малые проекты характеризуются использованием готовых решений и, в ряде случаев, адаптацией их под конкретные условия использования.
Проектирование ИС начинается с составления в текстовой и (или) графической форме плана работ. На первом этапе проектирования необходимо выяснить требования пользователей к системе и, на основании этих требований, сформировать макет системы. Предпочтительно осуществлять проектирование модульным методом. Проектирование информационных систем непосредственно связано с их программированием, поэтому значительная часть проектных работ связана с программированием ИС.
9. Особенности натурного анализа
Натурным моделированием называют проведение исследования на реальном объекте с последующей обработкой результатов эксперимента на основе теории подобия. Натурное моделирование подразделяется на научный эксперимент, комплексные испытания и производственный эксперимент. Научный эксперимент характеризуется широким использованием средств автоматизации, применением весьма разнообразных средств обработки информации, возможностью вмешательства человека в процесс проведения эксперимента. Одна из разновидностей эксперимента - комплексные испытания, в процессе которых вследствие повторения испытаний объектов в целом (или больших частей системы) выявляются общие закономерности о характеристиках качества, надежности этих объектов. В этом случае моделирование осуществляется путем обработки и обобщения сведений о группе однородных явлений. Наряду со специально организованными испытаниями возможна реализация натурного моделирования путем обобщения опыта, накопленного в ходе производственного процесса, т.е. можно говорить о производственном эксперименте. Здесь на базе теории подобия обрабатывают статистический материал по производственному процессу и получают его обобщенные характеристики. Необходимо помнить про отличие эксперимента от реального протекания процесса. Оно заключается в том, что в эксперименте могут появиться отдельные критические ситуации и определиться границы устойчивости процесса. В ходе эксперимента вводятся новые факторы возмущающие воздействия в процесс функционирования объекта.
10. Изучение аналогов и образцов
Динамика перемен в современном мире обеспечивается преимущественного за счет интенсивной проектной деятельности, к которой способны только субъекты культурно-технологического развития, а не просто исполнители. Главным фактором развития становится производство новых знаний - детерминирование интеллектуальных технологий, что предполагает уход человека из сферы непосредственного преобразования вещества и энергии на уровень управления и творческой деятельности. Постоянно ускоряющийся темп научно-технического прогресса предъявляет особые требования к современному человеку. Знания быстро устаревают, и возникает постоянная потребность в обновлении и приобретении все новых знаний. В таких условиях имеющихся у человека знаний недостаточно и он вынужден их добывать и производить все более ускоренными темпами.
Успешность и качество жизни зависит от способности человека проектировать - самостоятельно выявлять проблемы, противоречия и задачи окружающей действительности (предпроектные исследования), создавать что-либо новое (не бывшее ранее) более эффективное, позволяющее преодолевать возникающую проблему, то есть за счет «выхода» за пределы познанной реальности и создания новой, пока еще не ставшей.
Проектирование в реальной действительности осуществляется по некоторым устоявшимся правилам и закономерностям. Проектирование всегда предполагает некоторое приращение к исходному состоянию объекта проектирования. Результат проектирования может быть представлен как некоторая исходная система (ИС) и добавка (приращение) А.
Процесс выявления проблемы и поиск ее решения происходит по определенной схеме. Часто эта схема не осознается (остается в подсознании). Весь процесс проектирования может быть условно разделен на три больших этапа :
Этот этап связан с выявлением проблемы. Основой возникновения проблемы в форме, пригодной для выполнения логических или эвристических процедур по ее разрешению, является некоторый дискомфорт, явное или скрытое неудобство, которое испытывает человек в определенной ситуации жизнедеятельности, обозначаемой в качестве проблемной. Осознание интуитивно ощущаемого дискомфорта (физического, психического, интеллектуального, духовного) и неудобства приводят к пониманию человеком сущности проблемы и ее формулированию, что является одним из условий разрешения проблемы. При этом проблема преобразуется в задачу, где известны объект изучения и /или преобразования, исходные условия и состояние, а так же (при необходимости) ограничения на будущие возможные решения. Предпроектные исследования позволяют предотвратить повторение уже созданных проектов и направить творческую мысль на выявление действительно реальных проблем и формулирование задач, решение которых позволит устранить проблему на более высоком уровне качества.
Второй этап имеет целью создание собственно проекта в виде описаний, схем, чертежей, алгоритмов, программ, расчетов и т.п. Процесс создания проекта заключается в построении мыслительных образов будущей реальности (идей) эвристическими, ассоциативно-интуитивными, рациональными, алгоритмическими и другими способами, активизирующими креативную функцию сознания, и в последующем переводе сформировавшихся мыслительных образов в доступную для зрительного восприятия и понимания форму (визуализация или конструирование). Создание доступного для восприятия образа (облика) идеи решения проблемы обеспечивается взаимно обусловленными видами мыслительной деятельности человека - исследовательской и проектной. При их определенном сходстве они отличаются, прежде всего, объектом познания, а также методами и последовательностью выполнения процедур. Исследование и проектирование можно разделить по типу моделей. Исследование - познавательная модель, ориентированная на процесс получения знания о реально существующем мире и его элементах. Эту модель можно построить для процесса обучения и для процесса научного исследования - это процесс производства знаний о явлениях, свойствах, состояниях существующего, имеющегося в наличии реального объекта или их совокупности. Исследовать можно только то, что есть в реальном мире. Проектирование - это прагматическая модель, строится в ситуациях, когда необходимо осуществить какое-либо преобразование реального мира с целью получения другого иного результата - это процесс производства знания о несуществующей (виртуальной) реальности, которая может состояться при определенных условиях.
Проектирование и исследование, познавательные и прагматические модели не могут существовать друг без друга. Они могут рассматриваться, как взаимно обусловленные процедуры процесса удовлетворения потребности человека.
11. Изучение нормативов
Нормативы - это методические указания в строительстве, это совокупность принятых органами исполнительной власти нормативных актов технического, экономического и правового характера, регламентирующих осуществление градостроительной деятельности, а также инженерных изысканий, архитектурно-строительного проектирования и строительства.
Изучение нормативов играет основную, важную роль, так как нормы в строительстве охватывают громаднейшую область проектирования. Например:
раздел Безопасность включает (Противопожарные нормы, нагрузки и воздействия, основания зданий и сооружений) и многое другое,
Раздел Конструкции охватывает всевозможные бетонные и железобетонные, алюминиевые, асбестоцементные и прочие конструкции
Раздел Инженерные сети и системы охватывает канализацию зданий, наружные сети и сооружения, отопление, вентиляция и кондиционирование, а так же газоснобжение, расчет стальных трубопроводов и многое другое.
Раздел Транспорт охватывает магистральные трубопроводы, Промышленный транспорт, Трамвайные и троллейбусные линии и многое другое.
Так же есть и другие разделы напримергидротехнические сооружения, Градостроительство, организация, производство и приёмка работ, сметные нормы и другие
Качество владения этими знаниями формирует пользу, прочность, красоту, и экономичность сооружаемого объекта.
Концептуальное (инфологическое) проектирование (КП) системы – это конструирование информационных моделей предметной области(ОУ), котрые не зависят от условий программной и аппаратной реализации.
Здесь выполняется три функции:
1. определение типов сущностей предметной области
2. определение типов связей между сущностями
3. определение атрибутов и связывание их с типами сущностей и связей.
4. создание локальных концептуальных моделей данных в виде диаграмм “сущность - связь”.
5. обсуждение ЛКИМД с пользователями.
Рис. 3.1.3.1 Соответствие этапов проектирования и элементов архитектуры ANSI/SPARC.
Этап логического проектирования.
Логическое проектирование – это конструирование информационных моделей на базе существующих концептуальных модулей. Т.е. на этом этапе концептуальная модель данных преобразовывается в локальную логическую модель данных и далее в глобальную логическую модель данных(ГЛМД) с учетом типа используемой СУБД. Этот этап содержит 2 подэтапа:
На первом подэтапе выполняется:
1. преобразование локальной концептуальной модели данных (ЛКМД) в локальную логическую модель данных(ЛЛМД);
2. определение набора отношений(таблиц) исходя из структуры ЛЛМД;
3. проверка ЛЛМД с помощью правил нормализации;
4. проверка ЛЛМД в отношении транзакции пользователей;
5. создание окончательной диаграммы «сущность-связь» для каждой ЛЛМД;
6. определение требований к ЛЛМД с точки зрения обеспечения целостности данных;
7. обсуждение ЛЛМД с конечными пользователями.
На втором подэтапе выполняется:
1. слияние ЛЛМД в ГЛМД;
2. проверка и корректировка ГЛМД;
3. создание окончательного варианта диаграммы «сущность-связь», отображающей ГЛМД;
4. обсуждение ГЛМД с конечными пользователями.
Т.о. концептуальное и логическое проектирование позволяет решить следующие задачи:
1 - разбить весь проекта на группу относительно небольших простых задач исходя из структуры предметной области, т.е. создать ЛКМД
2 преобразовать ЛКМД в ЛЛМД
3 объединить ЛЛМД в ГЛМД
Этап физического проектирования
Этот этап состоит из 3-х подэтапов:
1. внедрение ГЛМД в среду конкретной СУБД:
Проектируются основные таблицы в среде СУБД
Реализация функций связанных с управлением ПО или т.н. бизнес-правил для ПО
2. создание проекта физического представления БД:
Выбор конкретной структуры хранения данных
Определение требований к внешней памяти
3. разработка средств защиты БД:
Разработка и учет пользовательских представлений о защите данных
Определение правил доступа для разных типов пользователей
На этом же этапе необходимо рассмотреть вопросы мониторинга и настройки всей системы.
Выбор СУБД.
Выбор СУБД необходим для обеспечения оптимального способа поддержки данной БД и всех приложений ИС. Целесообразно этот выбор осуществить между этапами концептуального и логического проектирования, т.к. это даёт возможность определиться в типе СУБД. Выбор СУБД является довольно трудоемкой задачей, т.к. различные СУБД существенно отличаются друг от друга по целой группе параметров.
Общий список параметров включает:
1. физические параметры:
предусмотрены ли файловые структуры в данной СУБД;
наличие средств индексирования;
наличие средств сжатия данных;
возможность шифрования данных;
требуемые объемы ОЗУ и ПЗУ для данной СУБД и т.д.
2. параметры определения данных:
тип базовой модели организации данных;
наличие поддержки в расширении первичных ключей;
наличие средств поддержки целостности данных;
предусмотренные типы данных;
3. общие параметры:
стоимость СУБД;
наличие поддержки работы СУБД в Internet;
производительность данной СУБД;
4. параметры, определяющие доступность в плане создания приложений:
возможности языка запросов;
наличие многопользовательского доступа;
возможность использования языков современного уровня;
5. группа параметров, описывающих средства технологии разработки ИС:
наличие инструментов для работы с оконным интерфейсом;
наличие case-инструментов;
Эти параметры обычно снабжаются теми или иными весовыми коэффициентами, которые определяют степень важности этого параметра для данного заказчика (предприятия). Это позволяет используя числовые данные по каждому параметру рассчитать для каждой СУБД общий(интегральный) показатель и, следовательно, более объективно оценить её. Заказчик и проектировщик ИС выбирают ту СУБД, для которой интересующий показатель – наибольший(наилучший).
Разработка приложений.
Цель разработки приложений заключается:
1. создание проекта транзакций
2. создание проекта интерфейса пользователя.
Проектирование транзакций.
Транзакций – одно действие или последовательность действий, выполняемых одним и тем же пользователем и/или одной прикладной программой(ПП), в результате чего появляется возможность обеспечить доступ к БД и/или изменить её содержимое (пример транзакций – регистрация клиента в БД какого-либо банка).
Обычно транзакция выполняется частично персоналом АИС, а частично ПП или самой СУБД.
Основные типы транзакций:
1. транзакции извлечения – действия, обозначающие выборку данных из базы
2. транзакции обновления – действия, в результате которых обеспечивается либо удаление определенных данных, либо их изменение, либо добавление некоторых данных.
3. смешанные транзакции
При проектировании транзакций необходимо определить и задокументировать характер(свойства) всех транзакций, которые будут реализовываться в АИС. В их числе:
1. исходные данные, которые использует транзакция;
2. выходные данные, формируемые транзакцией;
3. функциональные характеристики транзакций;
4. степень важности транзакции для пользователя;
5. предполагается интенсивность использования данной транзакции.
7.2. Концептуальное проектирование с использованием методологии IDEF1X
Цель концептуального проектирования – создание концептуальной схемы данных на основе представлений о предметной области каждого отдельного типа пользователей. Концептуальная схема представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД. Часто на такой схеме отображаются только имена сущностей (таблиц) без указания их атрибутов. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания.
Ниже рассматривается последовательность шагов при концептуальном проектировании [ , ].
1. Выделение сущностей.
Первый шаг в построении концептуальной схемы данных состоит в определении основных объектов (сущностей), которые могут интересовать пользователя и, следовательно, должны храниться в БД. При наличии функциональной модели прообразами таких объектов являются входы, управления и выходы. Еще лучше для этих целей использовать . Прообразами объектов в этом случае будут накопители данных. Как было отмечено выше, накопитель данных является совокупностью таблиц (набором объектов) или непосредственно таблицей (объектом). Для более детального определения набора основных объектов необходимо также проанализировать потоки данных и весь методический материал, требуемый для решения задачи. Например, для задачи определения допускаемых скоростей основными объектами (наборами объектов) являются: нормативно-справочная информация, информация об участках дороги, задания на расчет, ведомости допускаемых скоростей и т.д. В ходе анализа и проектирования информационной модели наборы объектов должны быть детализированы. Например, составной объект «информация об участках дороги» с учетом специфики решаемой задачи требует разбиения на отдельные составляющие: участки, пути, раздельные пункты, километраж, план, верхнее строение пути и т.д.
Возможные трудности в определении объектов связаны с использованием постановщиками задачи:
Примеров и аналогий при описании объектов (например, вместо обобщающего понятия «работник» они могут упоминать его функции или занимаемую должность: «руководитель», «ответственный», «контролер», «заместитель»);
Синонимов (например, «допускаемая скорость» и «установленная скорость», «разработка» и «проект», «барьерное место» и «ограничение скорости»);
Омонимов (например, «программа» может обозначать компьютерную программу, план предстоящей работы или программу телепередач).
Далеко не всегда очевидно то, чем является определенный объект – сущностью, связью или атрибутом. Например, как следует классифицировать «семейный брак»? На практике это понятие можно вполне обоснованно отнести к любой из упомянутых категорий. Анализ является субъективным процессом, поэтому различные разработчики могут создавать разные, но вполне допустимые интерпретации одного и того же факта. Выбор варианта в значительной степени зависит от здравого смысла и опыта проектировщика.
Каждая сущность должна обладать некоторыми свойствами:
Должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;
Обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
Обладать одним или несколькими атрибутами (первичным ключом), которые однозначно идентифицируют каждый экземпляр сущности, т. е. делают уникальной каждую строку таблицы;
Может обладать любым количеством связей с другими сущностями.
В графической нотации IDEF1X для отображения сущности используются обозначения, изображенные на следующем рисунке.
 |
||
| а) независимая | б) зависимая |
Рис. 7.1. Сущности
Сущность в методологии IDEF1X является независимой (сильной, родительской, доминантной, владельцем) , если сущность не зависит от существования другой сущности (другими словами, каждый экземпляр сущности может быть однозначно идентифицирован без определения его связей с другими сущностями, или уникальность экземпляра определяется только собственными атрибутами). Сущность называется зависимой (слабой, дочерней, подчиненной) , если ее существование зависит от существования других сущностей. Терминология «родительская» – «дочерняя» и «владелец» – «подчиненный» также может использоваться в отношении двух зависимых сущностей, если экземпляры одной из них (дочерней, подчиненной) могут быть однозначно определены с использованием экземпляров другой (родительской, владельца), несмотря на то, что вторая сущность в свою очередь зависит от третьей сущности.
2. Определение атрибутов.
Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов – после идентификации сущности или связи, задать себе вопрос «Какую информацию требуется хранить о …?». Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную информацию (например, «Ведомость возвышений наружного рельса в кривых»), так и результаты обработки данных (например, «Форма № 1»).
Выявленные атрибуты могут быть следующих видов:
Простой (атомарный, неделимый) – состоит из одного компонента с независимым существованием (например, «должность работника», «зарплата», «норма непогашенного ускорения», «радиус кривой» и т.д.);
Составной (псевдоатомарный) – состоит из нескольких компонентов (например, «ФИО», «адрес», и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;
Однозначный – содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т.д.);
Многозначный – содержит несколько значений (например, у одного отделения компании может быть несколько контактных телефонов);
Производный (вычисляемый) – значение атрибута может быть определено по значениям других атрибутов (например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере);
Ключевой – служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа), быстрого поиска экземпляров сущности или задания связи между экземплярами родительской и дочерней сущностей;
Неключевой (описательный);
Обязательный – при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т.е. после указанных действий оно не может быть неопределенным (NOT NULL). Атрибуты, входящие в первичный ключ сущности, являются обязательными.
После определения атрибутов задаются их домены (области допустимых значений) , например:
Наименование участка – набор из букв русского алфавита длиной не более 60 символов;
Поворот кривой – допустимые значения «Л» (влево) и «П» (вправо);
Радиус кривой – положительное число не более 4 цифр.
Задание доменов определяет набор допустимых значений для атрибута (нескольких атрибутов), а также тип, размер и формат атрибута (атрибутов).
На основании выделенного множества атрибутов для сущности определяется набор ключей. Ключ – один или несколько атрибутов сущности, служащих для однозначной идентификации ее экземпляров, их быстрого поиска или задания связи между экземплярами родительской и дочерней сущностей. Ключи, используемые для однозначной идентификации экземпляров, подразделяются на следующие типы:
- суперключ (superkey) – атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать «лишние» атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов;
- потенциальный ключ (potential key) – суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями;
- первичный ключ (primary key) – потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности;
- альтернативные ключи (alternative key) – потенциальные ключи, которые не выбраны в качестве первичного ключа.
Рассмотрим пример. Пусть имеется таблица, содержащая сведения о студенте, со следующими столбцами:
Фамилия;
Отчество;
Дата рождения;
Место рождения;
Номер группы;
Номер пенсионного страхового свидетельства (НПСС);
Номер паспорта;
Дата выдачи паспорта;
Организация, выдавшая паспорт.
Для каждого экземпляра (записи) в качестве суперключа может быть выбран весь набор атрибутов. Потенциальными ключами (уникальными идентификаторами) могут быть:
Номер пенсионного страхового свидетельства;
Номер паспорта.
В качестве уникального идентификатора можно было бы выбрать совокупность атрибутов «Фамилия»+«Имя»+«Отчество», если вероятность учебы в вузе двух полных тезок была бы равна нулю.
Если в сущности нет ни одной комбинации атрибутов, подходящей на роль потенциального ключа, то в сущность добавляют отдельный атрибут – суррогатный ключ (искусственный ключ, surrogate key) . Как правило, тип такого атрибута выбирают символьный или числовой. В некоторых СУБД имеются встроенные средства генерации и поддержания значений суррогатных ключей (например, MS Access). Также стоит отметить, что некоторые разработчики вместо поиска потенциальных ключей и выбора из них первичного в каждую сущность добавляют искусственный атрибут, который в дальнейшем и используют в качестве первичного ключа.
Если потенциальных ключей несколько, то для выбора первичного ключа рекомендуется придерживаться следующих правил:
Количество атрибутов, входящих в ключ, должно быть минимальным (желательно, чтобы ключ был атомарным, т.е. состоял из одного атрибута);
Размер ключа в байтах должен быть как можно короче;
Тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений (путают регистр букв; добавляют лишние пробелы; используют буквы, пишущиеся на разных языках одинаково). В числовых атрибутах вероятность ошибки при вводе значения меньше;
Вероятность изменения значений ключа была наименьшей (например, «Номер пенсионного страхового свидетельства» более постоянный параметр, чем «ИНН» или «Номер паспорта»);
С ключом проще всего работать пользователям (например, «Номер пенсионного страхового свидетельства» – это набор из 11 цифр, а «Номер паспорта» зависит от его вида: гражданина СССР, гражданина РФ или зарубежный).
Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая – в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Этот набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key) .
В нотации IDEF1X атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой. Предварительная идентификация атрибутов на примере двух сущностей показана на следующем рисунке.
Рис. 7.2. Примеры сущностей
У независимой сущности «Участки» в качестве первичного ключа назначен суррогатный ключ, у зависимой сущности «План» – первичный ключ составной, состоящий из пяти атрибутов.
3. Определение связей.
Наиболее характерными типами связей между сущностями являются:
Связи типа «часть–целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;
Классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);
Производственные связи (например, «начальник–подчиненный»);
Функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.
Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.
Связь характеризуется следующим набором параметров:
Именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;
Кратностью (кардинальность, мощность): один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (N:M, N = M или N <> M). Кратность показывает, какое количество экземпляров одной сущности определяется экземпляром другой. Например, на одном участке (описывается строкой таблицы «Участки») может быть один, два и более путей (каждый путь описывается отдельной строкой в таблице «Пути»). В данном случае связь 1:N. Другой пример: один путь проходит через несколько раздельных пунктов и через один раздельный пункт может проходить несколько путей – cвязь N:M;
Типом: идентифицирующая (атрибуты одной сущности, называемые внешним ключом, входят в состав дочерней и служат для идентификации ее экземпляров, т.е. входят в ее первичный ключ) и неидентифицирующая (внешний ключ имеется в дочерней сущности, но не входит в состав первичного ключа);
Обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и введенные значения должны совпадать со значениями атрибутов первичного ключа какого-либо экземпляра родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенные значения не совпадают со значениями атрибутов первичного ключа ни одного экземпляра родительской сущности);
Степенью участия – количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т.е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Участок» состоит из «Путей». В то же время по степени участия возможны следующие типы связей:
o унарная (рекурсивная) – сущность может быть связана сама с собой. Например, в таблице «Работники» могут быть записи и по подчиненным, и по их начальникам. Тогда возможна связь «начальник» – «подчиненный», определенная на одной таблице;
o тернарная – связывает три сущности. Например, «Студент» на «Сессии» получил «Оценку по дисциплине»;
o кватернарная и т.д.
В методологии IDEF1X степень участия может быть только унарной или бинарной. Связи большей степени приводятся к бинарному виду.
Внешний вид связи на диаграммах IDEF1X указывает на ее мощность, тип и обязательность.
Таблица 7.1. Типы связей
| Внешний вид | Тип и обязательность связи | Мощность связи справа |
| 1 | ||
| Обязательная, идентифицирующая | 0 .. ∞ | |
Z |
Обязательная, идентифицирующая | 0 или 1 |
P |
Обязательная, идентифицирующая | 1 .. ∞ |
<число> |
Обязательная, идентифицирующая | <число> |
| Обязательная, неидентифицирующая | 0 .. ∞ | |
| Необязательная, неидентифицирующая | 0 .. ∞ |
Примечания.
1. Идентифицирующая связь отображается сплошной линией, неидентифицирующая – пунктирной.
2. Необязательность обозначается ромбиком.
На следующем рисунке приведены примеры отображения связей.
а) идентифицирующая
б) неидентифицирующая
в) рекурсивная
Рис.7.3. Примеры связей
На рис. 7.3б связь необязательная, так как некоторые сотрудники не обязательно должны входить в какой-либо отдел (например, директор предприятия), и неидентифицирующая, так как табельный номер уникален для каждого сотрудника.
4. Определение суперклассов и подклассов.
В тех случаях, когда две и более сущностей по набору атрибутов незначительно отличаются друг от друга, можно применять в модели конструкцию – иерархию наследования (категорий), включающую в себя суперклассы и подклассы.
Суперкласс – сущность, включающая в себя подклассы.
Иерархия наследования представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (постоянные служащие) и совместители. Из их общих свойств можно сформировать обобщенную сущность (родового предка) «Сотрудник» (рис. 7.4), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в дополнительных сущностях (потомках) «Постоянный сотрудник» и «Совместитель» .
Рис. 7.4. Иерархия наследования (неполная категория)
Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы «Постоянный сотрудник» и «Совместитель» имели бы сходную по смыслу связь «работает в» с сущностью «Организация»).
Для каждой категории требуется указать дискриминатор – атрибут родового предка, который показывает, как отличить одну сущность от другой. В приведенном примере дискриминатор – атрибут «Тип».
В полной категории одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере сотрудник обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.
При построении модели возможны различные комбинации полных и неполных категорий. Например, первый уровень категории неполный, отдельные сущности которого дополняются вторым уровнем – полной категорией.
7.3. Пример построения концептуальной схемы
На следующем рисунке показан фрагмент концептуальной схемы информационной модели для задачи определения допускаемых скоростей, построенная с использованием ERwin v9.2.
Рис. 7.6. Фрагмент концептуальной схемы информационной модели
В концептуальной схеме выделены следующие логические блоки данных:
Нормативно-справочная информация;
Информация об участках дороги;
Задание на расчет;
Ведомости допускаемых скоростей;
Проект Приказа «Н» (на рис. 7.6 не показан);
Формы № 1, 1а и 2 (на рис. 7.6 не показан).
Все сущности, входящие в блоки (кроме блока «Нормативно-справочная информация»), представлены во фрагменте только наименованиями. Сущности, входящие в блок «Нормативно-справочная информация», показаны развернуто, т.е. включая все атрибуты и первичные ключи. В этом блоке присутствуют две сущности («Нормативы для сопрягаемых кривых» и «Допускаемые скорости по уклону отвода возвышения в кривых»), которые не связаны ни с одной другой сущностью. Это не является ошибкой, так как существует мнение, что схема БД должна представлять собой связный граф (все сущности должны быть связаны между собой). Для большинства задач, где в БД накапливается различная оперативная информация, а затем на основе ее формируются различные отчеты и сводки, такое утверждение действительно имеет место. Но для инженерных, оптимизационных и некоторых других задач возможно наличие несвязанных таблиц. В рассматриваемом примере две несвязанные сущности участвуют в каждом расчете допускаемых скоростей, т. е. они влияют на результаты, отображаемые в ведомостях допускаемых скоростей. Но учитывая специфику задачи, изменение содержимого этих таблиц не должно приводить к изменению уже полученных результатов. Поэтому таблицы не связаны ни с заданиями на расчет, ни с результатами расчета.
Концептуальное проектирование порой называют техническим . Его основными этапами являются:
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 с. и др.
Главным направлением деятельности Компании «Метод» с момента ее основания и по настоящее время является разработка изобретающих компьютерных программ на основе методов концептуального проектирования технических систем.
Концептуальное проектирование - это отдельный вид проектной деятельности. Её результат - варианты концепций проектируемой технической системы (ТС) как в целом, так и ее отдельных частей.
Концепция ТС имеет различные формы представления, отличающиеся уровнем проработки (конкретности). Это:
Функциональная схема, в которой указан набор элементов ТС, выполняющих ту или иную техническую функцию, и способ их взаимодействия.
Принцип действия , определяющий взаимосвязь между физическими (химическими и т.п.) явлениями, протекающими в ТС на различных этапах ее жизненного цикла.
Принцип изменения , указывающий, как надо изменить материалы, конструкцию, режимы работы и взаимодействие устройства с окружающей средой, чтобы улучшить его характеристики.
Конструктивная схема , которая определяет состав ТС, взаимное расположение и взаимосвязь между ее элементами, особенности их конструктивного исполнения, используемые материалы, оптимальное соотношение параметров элементов и другие существенные признаки. Обычно, для краткости изложения, конструктивная схема ТС представляется в виде отличительной формулы . В ней перечисляются только те конструктивные признаки, которые отличают проектируемую ТС от ее прототипа.
Основной объем задач концептуального проектирования приходится решать на ранних стадиях разработки ТС: при разработке концепт - проекта и эскизном проектировании. Иными словами, тогда, когда определяется облик будущего изделия. Однако, и в дальнейшем, на этапах рабочего проектирования, испытаний, постановки на производство разработчики сталкиваются со сложными техническими проблемами. Их устранение так же требует методов концептуального проектирования.
Место и объем концептуального проектирования как отдельной поисковой процедуры поясняет следующая схема.
Концептуальное проектирование - это важнейшая составляющая процесса создания нового изделия. В конечном итоге, именно число проработанных концепций будущего изделия определяет его новизну и качество , а, следовательно, его конкурентоспособность и объем продаж .
Практическое применение методов концептуального проектирования показало, что они незаменимы при решении таких задач, как:
Изобретательство и концептуальное проектирование являются родственными видами деятельности, отличающимися, в основном, своим целями.
Изобретательство - это индивидуальная инициативная деятельность. Цель изобретателя состоит в создании изобретения, т.е. технического решения, обладающего мировой новизной . Изобретательство, как вид человеческой деятельности, сродни искусству. Поэтому очень часто создание изобретения несет в себе элемент случайности . Многие замечательные изобретения появляются «ни тогда» и «ни там», как того требует реальное производство. Это одна из главных причин трудностей внедрения изобретения в практику.
Случайный характер изобретательства может задержать развитие техники не на годы, а на тысячелетия! Например, древним грекам были известны все элементарные технические устройства, которые использовал Эдисон в своем фонографе для записи и воспроизведении звука. Они знали о свойствах струн колебаться при дуновении ветра, о колебании мембран барабанов, применяли рычаг для увеличения силы и использовали дощечки, покрытые воском, для записи слов. Однако соединить все эти знания вместе в одном устройстве они не смогли. Кстати, изобретению фонографа Эдисон также обязан счастливому случаю.
В отличие от изобретательства, концептуальное проектирование - это плановая производственная деятельность . Её цель - решить техническую проблему, которая поставлена перед разработчиками, в заданный срок. При этом, обычно, не ставится задача найти принципиально новое техническое решение, т.е. изобретение.
Если техническое решение находится после установленного срока, то, как правило, реализовать его практически не удается. Использование такого решения в текущем проекте невозможно, т.к. упущено время. В следующем проекте аналогичного изделия этому решению также обычно не находится места, т.к. появляются новые требования и новые решения.
Цель концептуального проектирования - обеспечение планомерности решения технической проблемы - достигается за счет применения современных информационных технологий. В отличие от изобретательства, в котором преобладает творческое начало человека, концептуальное проектирование - это, в первую очередь, технология. Именно она позволяет гарантировать нужный результат в установленные сроки.
ТРИЗ - теория решения изобретательских задач - была разработана Альтшулером Г.С. и его учениками в СССР в период 50 - 80-х годов прошлого века. Эта методология успешно развивается и в настоящее время. Методы ТРИЗ используют как отдельные изобретатели, так и консультационные фирмы во многих странах мира.
ТРИЗ и концептуальное проектирование являются родственными методологиями. У них одна и та же цель - плановое, целенаправленное решение технических проблем, но различные методы.
Основной арсенал ТРИЗ - это эвристические методы , состоящие из специальных алгоритмов, инструкций, методических рекомендаций и т.п., которые ориентированы на использование их человеком. Методы ТРИЗ помогают изобретателю проанализировать техническую проблему, придумать решение и расширить область его применения.
Более широкое использование методов ТРИЗ в инженерной практике ограничено необходимостью предварительного обучения . Овладеть этими методами на должном уровне можно только после длительного обучения на специальных курсах у опытного преподавателя.
Соответствующей реакцией на проблему обучения стало создание компьютерных программ, реализующих методы ТРИЗ. Однако, это не позволяет полностью избежать предварительного обучения. В этих программах компьютер используется как вспомогательное средство. С его помощью изобретатель, в основном, регистрирует результаты решения технической проблемы, а также находит подходящие эвристические приемы и технические примеры. При работе с такими компьютерными программами весь объем творческих операций изобретатель должен выполнить сам.
В концептуальном проектировании для решения технических проблем используются формальные методы и большие базы знаний , которые могут быть реализованы только в виде компьютерных программ. Пользователю совсем необязательно знать, какие методы (алгоритмы) применяются в этих программах. Ему достаточно указать техническую проблему, нажать кнопку «Решить» и выбрать лучшее из найденных решений. Таким образом, методы концептуального проектирования позволяют любому инженеру целенаправленно решать технические проблемы без предварительной методической подготовки.
Несмотря на указанные различия, подходы ТРИЗ и концептуальное проектирование не исключают, а дополняют друг друга. Методы ТРИЗ незаменимы при поиске направлений решения технической проблемы. Они помогают инженеру перейти от сложной технической проблемы к типовым изобретательским задачам. После этого можно применить методы концептуального проектирования. Уже сейчас изобретающие программы на основе методов концептуального проектирования могут решать некоторые изобретательские задачи средней степени сложности. Это обеспечивают обширные базы конкретных инженерных знаний и сложные формальные алгоритмы, которые используются в этих программах.
Кроме того, как показывает наш опыт, наилучших результатов при работе с современными изобретающими программами добиваются инженеры, владеющие ТРИЗ.
К этому надо добавить, что полностью формализовать весь процесс решения технических проблем не удастся никогда. Очевидно, что со временем область применения изобретающих компьютерных программ будет расширяться, но они никогда полностью не заменят в этом деле человека. И вызвано это не тем, что еще не решены какие-то математические проблемы или не хватает быстродействия и памяти у существующих компьютеров. Проблема только в одном: компьютер не изобретает, потому что он этого не хочет!
