Концептуальное проектирование
Концептуальное проектирование технических систем - начальная стадия проектирования , на которой принимаются определяющие последующий облик решения, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. Термин «концепция» применяется для описания принципа действия не только в технических системах, но и в научных , художественных и прочих видов деятельности. «Концепт» (лат.) - содержание понятия, смысл. Таким образом, проектирование на концептуальном уровне - на уровне смысла или содержания понятия систем.
Основной объем задач концептуального проектирования относится к ранним стадиям разработки технических систем (ТС): при постановке задачи на проектирование , выработке массива вариантов технических и оформительских решений и в эскизном проектировании, при создании технического задания.
Автоматизированные системы поддержки этапа концептуального проектирования
Образ объекта или его составных частей может создаваться в воображении человека в результате творческого процесса или генерироваться в соответствии с некоторыми алгоритмами в процессе взаимодействия человека и ЭВМ с помощью автоматизированных систем поддержки этапа концептуального проектирования . Работы по этой тематике велись такими учеными как А. И. Половинкин , М. Ф. Зарипов , В. А. Камаев , Р. Коллер , А. М. Дворянкин, В. А. Глазунов , С. А. Фоменков , В. М. Цуриков и т. д..
Известны несколько подходов, которые легли в основу подобных автоматизированных систем [автоматизированная система]:
- Формализованное описание естественнонаучных и научно-технических эффектов на основе онтологии научно-технических характеристик.
- Теория решения изобретательских задач (ТРИЗ).
- Энерго-информационная модель цепей и метод структурных параметрических схем (ЭИМЦ).
- Система структурирования физических знаний и поискового конструирования.
Литература
- «Project on Creation of Knowledge Base on Physical and Technologocal Effects », Материалы международной конференции TC-1. Education in Measurements and Instrumentation - Challenges of New Technologies: Proceedings, Вроцлав - 2002, P. 171-176 ISBN 83-7085-647-0 . Зарипова В. М., Зарипов М. Ф., Петрова И. Ю.
- Применение объектных технологий для анализа и проектирования систем поиска новых технических решений (на примере систем Интеллект и Сапфит). Информационные технологии в образовании и медицине: Материалы международной конференции - 2004 г. - Волгоград: Издательство ВолгГТУ, 2004 г. Зарипова В. М., Камаев В. А.
Wikimedia Foundation . 2010 .
Смотреть что такое "Концептуальное проектирование" в других словарях:
концептуальное проектирование - 3.6.5. концептуальное проектирование: Стадия конструкторской ПП, выполняемая при помощи САЕ|САВ системы (САЕ Computer Aided Engineering, CAD Computer Aided Design), в ходе которой разрабатывается облик изделия (в форме геометрической 3D мoдeли)… …
Процесс создания схемы базы данных и определения необходимых ограничений целостности. Содержание 1 Основные задачи проектирования баз данных … Википедия
Андрей Георгиевич Теслинов [[Файл … Википедия
50.1.031-2001: Информационные технологии поддержки жизненного цикла продукции. Терминологический словарь. Часть 1. Стадии жизненного цикла продукции - Терминология 50.1.031 2001: Информационные технологии поддержки жизненного цикла продукции. Терминологический словарь. Часть 1. Стадии жизненного цикла продукции: 3.7.12. (всеобщее) управление качеством: Совокупность программных средств и данных … Словарь-справочник терминов нормативно-технической документации
Р 50.1.031-2001: Информационные технологии поддержки жизненного цикла продукции. Терминологический словарь. Часть 1. Стадии жизненного цикла продукции - Терминология Р 50.1.031 2001: Информационные технологии поддержки жизненного цикла продукции. Терминологический словарь. Часть 1. Стадии жизненного цикла продукции: 3.7.12. (всеобщее) управление качеством: Совокупность программных средств и… … Словарь-справочник терминов нормативно-технической документации
В Википедии есть статьи о других людях с такой фамилией, см. Камаев. Камаев Валерий Анатольевич Дата рождения: 30 мая 1940(1940 05 30) (72 года) Место рождения: г. Омск Страна … Википедия
DEMO (DEMOnstration Power Plant) проект электростанции, использующей термоядерный синтез. Планируется постройка после успешного ввода в строй ИТЭР. Временные рамки проекта В 2004 году были предложены следующие временные рамки проекта:… … Википедия
Эту статью следует викифицировать. Пожалуйста, оформите её согласно правилам оформления статей … Википедия
Спартак Петрович Никаноров Дата рождения: 30 августа 1923 Место рождения: Москва, СССР Спартак Петрович Ник … Википедия
S1000 малая неатомная подводная лодка. Совместная разработка Италии и России. Разработка проекта началась в 2004 году по техническому заданию и при финансировании Военно морских сил Италии. Первый этап работ был завершен в феврале 2005… … Википедия
Книги
- Концептуальное проектирование. Теория изобретательства , Глазунов В.Н.. В книге впервые изложены теоретические основы концептуального проектирования как самостоятельного вида проектной деятельности. Выявлены все виды задач концептуального проектирования и…
Аннотация
ПРОБЛЕМАТИКА КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКИХ ОБЪЕКТОВ
Бутенко Л.Н.
Статья посвящена проблемам концептуального проектирования технических систем. Показана актуальность междисциплинарной интеграции методов, применяемых для получения новых технических решений.
Problems of Conceptual design
The aim of this article is demonstration of problems and methods of conceptual design theory. Discussing intellectual problems in development theory achievements aspect. Shows the intersubject research for successful solving of this problems. This production can to change a scientific paradigm.
In this article we present this studies, procedures, metarules, which can management of relationship designing and some semantic describes of this aspect.
ПРОБЛЕМАТИКА КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКИХ ОБЪЕКТОВ
Бутенко Л.Н.
Волгоградский государственный технический университет
400131, г. Волгоград, проспект им. В.И. Ленина, 28, [email protected]
«Того, кто не задумывается о далёких трудностях,
непременно поджидают близкие неприятности»
Конфуций
«-Голова – она может всё». Граф Калиостро
Григорий Горин «Формула Любви»
В настоящее время высокую актуальность приобрели исследования в области концептуального проектирования ввиду того, что применение традиционных детерминированных методов описания, контроля и управления выявило их большую ограниченность, а порой и невозможность построения моделей проектируемых систем.
Современное состояние исследований в методологических дисциплинах (исследование операций, системотехника, системный анализ) а также теории принятия решений, многоуровневых иерархических систем, автоматического управления, катастроф таково, что не позволяет исследовать сложные, плохо структуризованные, динамичные предметные области.
Математическое моделирование в настоящее время ориентировано на параметрический синтез.
Лучшие из методов автоматизации программирования (логическое, структурное и объектно-ориентированное программирование CASE-технологии) не имеют в своем составе развитых познавательных средств. Мощные средства автоматизации проектно-конструкторских работ (например, AutoCAD) не имеют средств для представления сложных развивающихся объектов.
Методы и средства искусственного интеллекта (ситуационное управление, экспертные системы, инженерия знаний, базы знаний) не имеют средств для углубления понимания предметных областей, они лишь мобилизуют имеющиеся знания.
Методы проектирования организаций (проблемно-ориентированный подход, функциональный подход, системное проектирование и другие) не имеют средств для восстановления целостности интересов организаций и областей их деятельности.
Мощные познавательные методы, развитые в рамках философской диалектики, теории познания, в логике и методологии науки, в теории мышления, структурализма пока еще не стали средствами прикладной, инженерной работы.
Теория систем в своем развитии находится в методологическом тупике и не выработала методов постулирования сложных классов систем.
Синергетика имеет предметом физические или физикалистские процессы.
Математический аппарат (теория множеств, теория категорий и функторов, теория структур, теория топосов) широко применяется в теории систем и в ряде прикладных задач (проектирование баз данных), но до сих пор не был способен обеспечить исследование сложных предметных областей и проектирование сложных объектов.
Концептуальное проектирование системы – это стадия, на которой принимаются определяющие ее последующий облик решения на различных системных уровнях, проводится исследование созданных решений и их предварительное согласование.
Приведем ряд базовых определений:
Концепт (лат. conceptus - понятие) – понятие;
Термин «концептуальный» обозначает характер процесса (описания, представления и т.д.) или объекта (модели, структуры, результата и т.д.), отличающийся тем, что качественная определенность объектов представляется в форме понятий ; Концептуально мыслить - это базовая способность человеческого мышления с большими скоростями «свертывать» и обобщать информацию любого рода. Свертка информации может находить отображение в понятиях, числе, временной или пространственной структуре.
Рассмотрим массив интеллектуальных задач и способы их решения с точки зрения системного подхода к концептуальному проектированию систем любого класса.
Наиболее современное определение системы приведено в
Система = (элементы, отношения, внешняя среда, наблюдатель, язык)
Рассмотрим проблемы концептуального проектирования с точки зрений современного представления того, что называется системой. Первое, что бросается в глаза, то, что это определение статично, в нем отсутствуют правила построения систем. Только в последнее время в определении появляться новые объекты, которые влияют на эффективность процесса концептуального проектирования систем, например, Наблюдатель (проектировщик), Язык (язык проектирования). Формулировка первой проблемы заключается в том, что для обеспечения свойств системы должны быть созданы массивы правил их обеспечения. Приведем перечень инвариантных свойств системы, которые образуют кортеж :
S = (a,b,c,d,f, … , ),
где:a–первичность целого (системы); b–неаддитивность системы;c–размерность системы;d–сложность структуры системы;e–жесткость системы;f–вертикальная целостность системы;g – горизонтальная обособленность системы;h – иерархичность системы;i–множественность (разная глубина) описания системы;j–взаимозависимость системы и внешней среды;k–степень самостоятельности системы;l–открытость системы;m–совместимость системы;n–целенаправленность системы;o–наследственность системы;p–приоритет качества;q–приоритет интересов системы более высокого уровня;r–надёжность системы;s–оптимальность системы;t–неопределенность информационного обеспечения системы;u–эмерджентность системы;v–мультипликативность системы;w–непрерывность функционирования и развития системы;x–альтернативность путей функционирования и развития системы; y–синергичность системы;z–инерционность системы;–адаптивность системы;–организованность системы;–уровень стандартизации системы;–инновационный характер развития системы.
Для того, чтобы система была целостным объектом необходимо определить характер и последовательность интеллектуальных процедур, обеспечивающих проявление всех вышеназванных свойств.
Отметим, что свойства любой системы только в частном случае могут быть определены функцией структуры этой системы, более приемлемым, по нашему мнению, является зависимость «свойства–организация» системы. Под организацией будем понимать множество элементов и отношений, а также взаимодействие между элементами. В этом случае, концептуальное проектирование систем должно подчиняться закономерностям организации систем, как с точки зрения строения, так и функционирования. Здесь обнаруживается необходимость существования и, соответственно, проектирования такой надсистемы, которая осуществляет целепорождение и координацию всех проявлений свойств системы. Такая надсистема принципиально отлична от внешней среды.
Интеллектуальной проблемой является также создание «границ» системы с внешней средой, где главным является сохранение целостности и обеспечение устойчивости.
Влияние наблюдателя на процесс концептуального проектирования может быть определено через взаимодействие субъекта и объекта. В данном случае необходимо решить задачу о возникновении, формировании, развитии и воплощении идеи проектируемой системы. Приведем самые распространенные определения идеи:
Идея – форма постижения в мысли явлений объективной реальности ;
Идея – это терм, окруженный релевантным знанием ;
Идея – это зафиксированное в каком-либо коде представление об устройствах объекта, о сути процесса, о причинах и следствиях явлений .
Полная цепь развертывания идеи об объекте как о системе обозначена в : Наблюдатель порождает интенции, т.е. исходные намерения в границах аспекта. Следующий шаг проявления идеи – результат развития намерения в конкретной среде. Здесь знание становиться можно уже «рассматривать», это выражение сущности явления. Далее – этап проявления сущности. Это этап системообразования, здесь сущность как нечто целое обнаруживает различие своих частей. и, «наконец», этап восхождения к классам систем при помощи новых аксиом. Как следует из описания, вопрос о том, как появляется идея, является очень сложным, а процедуры ее усложнения, происходящие в Наблюдателе описаны в психологии недостаточно четко. В психолингвистике было уточнено понятие концепта и оказалось, что концепт не равнозначен термину понятия . Концепт существует в ментальном мире человека не в виде четких понятий, а как «пучок» представлений, понятий, знаний, ассоциаций, переживаний, который сопровождает слово. Концепты не только мыслятся, они «переживаются», они предмет эмоций, симпатий и антипатий,а иногда и столкновений. Концепт трактуют как некоторую базовую когнитивную сущность, позволяющую связывать смысл с употребляемым словом, как содержательную единицу процесса концептуализации, посредством которого действительность преломляется в голове человека.
Таким образом, мы выходим на проблему получения выводного знания. Человек может проявлять новое знание «методом открытия» и «методом постулирования». Отметим, что в данном контексте возникают проблемы учета изменения информации в процессе выводного знания (т.е. вывод является немонотонным), а также проблемы горизонтального и вертикального синтеза, средоточием которых является проблема совместимости между элементами и между системными уровнями проектирования.
Для концептуального проектирования особое значение имеет получение именно новых решений. Укажем на взаимосвязь этой проблемы с проблемой системогенеза, а также с проблемой получения выводного знания.
Отметим также, что особой актуальностью обладает концептуальное проектирование систем в аспекте обеспечения их инновационного развития. Это непосредственно связано с качественными переходами между системами, требующими изменения организации этих систем. Эту новую область исследований, по нашему мнению следует назвать гетеродинамикой. На рис.1 показаны возможные направления дальнейших междисциплинарных исследований. Подчеркивая прагматическую направленность, мы хотели бы указать на тесную взаимосвязь с задачами стратегического планирования, стратегического менеджмента, стратегического маркетинга для самых разных предметных областей.
Библиографический список:
1. Никаноров С. П. Метод концептуального проектирования систем организационного управления и его применение. Электронный научно-информационный журнал «СИСТЕМНОЕ УПРАВЛЕНИЕ. ПРОБЛЕМЫ и РЕШЕНИЯ» http://www.situation.ru/app/j_art_960.htm
2. Теслинов А.Г. Развитие систем управления: методология и концептуальные структуры. М.: «Глобус», 1998. 229с.
3. Волкова В.Н., Денисов А.А.Основы теории систем и системного анализа
4. Стратегический маркетинг: Р.А.Фатхутдинов. – СПб.: Питер, 2003.
5. Философский энциклопедический словарь. М: Советская Энциклопедия. 1983
6. Финн В.К.Философские проблемы логики интеллектуальных систем. Журнал Российской Ассоциации искусственного интеллекта. «Новости искусственного интеллекта» № 1. Москва 1999. с. 36.
7. Птушенко А. «Техника Молодёжи» № 3, 2003, стр 24.
8. Залевская А.А. Введение в психолингвистику. Российск.гос.гуманит.ун-т. М., 2000, 382 с.
9. Александров Е.А.Основы теории эвристических решений. М. Советское радио, 1975, 254 с.
10. Бутенко Дм.В. Взаимосвязь стратегического планирования и концептуального проектирования. // XXX Юбилейная Международная конференция и дискуссионный научный клуб IT+SE`2003 Новые информационные технологии в науке, образовании, телекоммуникации и бизнесе. Украина, Крым, Ялта-Гурзуф, 2003г., с. 107
Концептуальное (инфологическое) проектирование (КП) системы – это конструирование информационных моделей предметной области(ОУ), котрые не зависят от условий программной и аппаратной реализации.
Здесь выполняется три функции:
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. разработка средств защиты БД:
Разработка и учет пользовательских представлений о защите данных
Определение правил доступа для разных типов пользователей
На этом же этапе необходимо рассмотреть вопросы мониторинга и настройки всей системы.
Выбор СУБД.
Выбор СУБД необходим для обеспечения оптимального способа поддержки данной БД и всех приложений ИС. Целесообразно этот выбор осуществить между этапами концептуального и логического проектирования, т.к. это даёт возможность определиться в типе СУБД. Выбор СУБД является довольно трудоемкой задачей, т.к. различные СУБД существенно отличаются друг от друга по целой группе параметров.
Общий список параметров включает:
предусмотрены ли файловые структуры в данной СУБД;
наличие средств индексирования;
наличие средств сжатия данных;
возможность шифрования данных;
требуемые объемы ОЗУ и ПЗУ для данной СУБД и т.д.
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 – 3 разработки АС по ГОСТ 34 или этапам от определения требований до проектирования в моделях жизненного цикла.
Определению требований к ИС предшествует определение целей, для которых эта система будет разрабатываться. Цели ИС определяют границы предметной области, объекты которой, их свойства и взаимосвязи существенны с точки зрения поставленных целей и которые будут представлены в ИС (это информация о предметной области – ПО-информация). Цели ИС также определяют, каких пользователей и какие именно информационные потребности система будет обслуживать (это информация о потребностях пользователей – ПП-информация). Две эти составляющие: ПО-информация (являющаяся объективным отражением предметной области) и ПП-информация (отражающая отчасти субъективные представления пользователей) одинаково необходимы и важны для построения концептуальной модели, что и показано на рис. 14 7 . Иногда превалирует второе слагаемое в концептуальной модели, основанной на учёте текущих и предвидимых приложений, т.к. это позволяет быстрее и легче создать систему. Однако такие системы оказываются плохо приспособленными для обработки неформализованных, изменяющихся и непредвиденных заранее задач и запросов. Адекватное отражение в системе ПО-информации придает ей необходимую гибкость и адаптивность к изменяющимся условиям.
О
бщая
схема концептуального проектирования:
Схема на рис. 16 представляет два этапа проектирования: сбор и содержательный анализ информации о предметной области и прикладных задачах пользователей; концептуальный анализ данных и синтез концептуальной модели.
Первый этап - сбор данных о предметной области, которые могут быть получены в результате измерений или наблюдений, изучения отчётов и документов, опроса специалистов, и выявление перечня задач, которые должны решаться с помощью разрабатываемой системы. Получаемая при этом информация может быть отчасти субъективной. Для повышения её объективности используют методы экспертных оценок, проводят содержательный анализ для устранения дублирования информации, выявления противоречий и неоднозначности и так далее.
Модели ис и методики проектирования
Главная особенность разработки современных информационных систем состоит в концентрации сложности на начальных этапах анализа требований и проектирования спецификаций системы. Нечёткость и неполнота системных требований, нерешённые вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всей работы в целом.
К проектированию ИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование ИС конкретных организаций на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов ИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем. 8
Для обозначения первого направления используется термин "системная интеграция". В этом случае разработчик ИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-cредствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области.
Второе направление в большей мере относится к области разработки математического и программного обеспечения для реализации функций ИС - моделей, методов, алгоритмов, программ на базе знания методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т.п.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определённой дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций. Формализация нужна для однозначного понимания исполнителями и заказчиком требований, ограничений и принимаемых решений.
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе изучения предметной области, в том числе обследования организации, являются моделями её функционирования, В процессе разработки ИС модели, как правило, претерпевают существенные изменения и в окончательном виде они рассматриваются уже, как модели проектируемой ИС.
Различают функциональные, информационные, поведенческие и структурные модели 9 . Функциональная модель системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры данных – их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурные модели характеризуют морфологию системы (её построение) – состав подсистем, их взаимосвязи.
Таким образом, функции (отвечающие на вопрос "Что сделать?") в совокупности с исходными данным ("Над чем произвести действия?"), ограничениями (время, финансовые и материальные средства, нормативные документы или бизнес-правила и т.п.), средствами реализации ("Чем сделать?") и результатом ("Что сделано?") описывают проектируемую ИС.
Существует ряд способов построения и представления моделей, различных для моделей разного типа. Основой является структурный анализ – метод исследования системы, который начинается с её общего обзора и затем происходит детализация, формирующая иерархическую структуру с всё большим числом уровней. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, лёгких для понимания и решения;
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В настоящее время известно порядка 90 разновидностей структурного системного анализа, которые могут быть классифицированы по отношению к школам (для моделирования программных систем или систем вообще), по порядку построения модели (декларирующие первичность функционального или информационного моделирования), по типу целевых систем (информационные системы или системы реального времени) 10 . Несмотря на такое обилие методов, практически во всех из них используются три группы средств:
DFD (Data Flow Diagrams) - диаграммы потоков данных или SADT (Structured Analysis and Design Technique) диаграммы, иллюстрирующие функции, которые система должна выполнять;
ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь", моделирующие отношения между данными;
STD (State Transition Diagrams) - диаграммы переходов состояний, моделирующие зависящее от времени поведение системы (аспекты реального времени).
Кроме этих моделей на этапе структурного проектирования используются техники структурных карт, предназначенные для описания отношений между модулями (структурные карты Константайна) и внутренней структуры модулей (структурные карты Джексона).
Наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования, поскольку для информационного и поведенческого моделирования в настоящее время практически нет альтернативы ERD и STD соответственно. Далее рассмотрим основные понятия, связанные с вышеназванными методиками проектирования.
