Open Library - открытая библиотека учебной информации. Концептуальное проектирование систем

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

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

Статика и динамика систем

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

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

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

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

Сбор и анализ информации

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

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

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

Статика и жесткое конструирование

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

Между тем, ассоциации: «концепция = информационная система» не существует. Во всяком случае: об этом свидетельствует современное положение вещей.

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

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

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

Объективные законы физического мира

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

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

Теория решения изобретательских задач (ТРИЗ), одно из заметных достижений прошлого века, была выполнена одним человеком, но привлекла внимание многочисленных специалистов, которые развили и использовали ее в реальной практике.

ТРИЗ - идеальный пример современного концептуального проектирования, начатый одним человеком и развитый множеством людей, но не достигший, объективно возможного, концептуального уровня развития.

ТРИЗ - заметное, но не монументальное достижение. Альтшуллер, Шапиро и тысячи их последователей внесли вклад в теорию, практику и изобретательское дело, но результат «ничтожен»: последователи и правообладатели, фантастические рассказы и статьи о сильном мышлении... в сравнении: Леонардо Да Винчи своими исследованиями полетов птиц и кардинально новой идеей: «не крыло должно махать, но аэроплан должен лететь» - прославился больше и украсил свои многочисленные концептуальные изобретения загадочной Джакондой.

Субъективные положения социального мира

ТРИЗ не строилась на фундаменте технического задания, а ее родоначальник Альтшуллер не руководствовался какими-либо методами выполнения работ. «Мастера» теории решения изобретательских задач и тысячи их учеников довольствовались малым:

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

С точки зрения общественного сознания, актуальности и полезности целевая установка ТРИЗ социально значима и имеет реальное практическое применение.

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

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

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

Обозначить - не значит использовать: концептуально о базовых постулатах ТРИЗ

Постулат «1»: нет разницы между естественной и искусственной системой, потому. как и то, и другое развивается не по определенным, а по объективным законам. То, что человек не познал или не понимает объективности законов Природы, ровным счетом для этих законов ничего не значит.

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

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

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

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

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

Методы и средства проектирования

Интересная особенность поисковой выдачи по запросу: «методы и средства концептуального проектирования»: 97 % результатов связаны с информационными системами, программированием, базами данных и другими направлениями в области компьютерного дела и информационных технологий; остальные 3 % придутся на «более практичные» сферы социальных и производственных потребностей: авиационные двигатели, производственные процессы, социальные или природоохранные проекты и другое.

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

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

1) В настоящее время принято выделять следующие методологии разработки ПО:

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

2) Основными этапами КП являются:

• Предварительное проектирование.
• Эскизное (рабочее или техно-рабочее) проектирование.
• Изготовление, испытания и доводка опытного образца системы.

3) Есть два подхода к КП:

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

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

Объективный подход к проектированию

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

Наука и практика обязаны теории решения изобретательских задач. Это было на самом деле великое дело: систематизировать физические, химические, социальные и другие достижения, практические решения, изобретения, технологические процессы. Задача сформулировать системы физических эффектов или определить объективные закономерности - воистину актуальна, была всегда, и в современном мире ее актуальность стремительно растет.

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

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

Человек и пчела

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна из архитектур БД называется 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) в случае рекурсивной связи - когда родитель и потомок совпадают. Пример – иерархия подчинения в организации, когда для данного работника необходимо учитывать его непосредственного начальника:

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

Здесь выполняется три функции:

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. предполагается интенсивность использования данной транзакции.

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

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

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

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

(ИС - информационная система!)

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

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

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

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

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

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

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

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

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

9. Особенности натурного анализа

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

10. Изучение аналогов и образцов

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

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

Проектирование в реальной действительности осуществляется по некоторым устоявшимся правилам и закономерностям. Проектирование всегда предполагает некоторое приращение к исходному состоянию объекта проектирования. Результат проектирования может быть представлен как некоторая исходная система (ИС) и добавка (приращение) А.

Процесс выявления проблемы и поиск ее решения происходит по определенной схеме. Часто эта схема не осознается (остается в подсознании). Весь процесс проектирования может быть условно разделен на три больших этапа :

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

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

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

11. Изучение нормативов

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

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

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

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

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

Раздел Транспорт охватывает магистральные трубопроводы, Промышленный транспорт, Трамвайные и троллейбусные линии и многое другое.

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

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