Аннотация
ПРОБЛЕМАТИКА КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ ТЕХНИЧЕСКИХ ОБЪЕКТОВ
Бутенко Л.Н.
Статья посвящена проблемам концептуального проектирования технических систем. Показана актуальность междисциплинарной интеграции методов, применяемых для получения новых технических решений.
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
Задачей концептуального проектирования является определение информационных потребностей "предприятия", тех процессов и данных, которые необходимы для обеспечения этих потребностей. Процесс концептуального проектирования начинается с изучения деятельности "предприятия", т.е. с анализа предметной области . Вначале определяются цели и задачи предприятия, анализируются процессы (планирование, управление, контроль), обеспечивающие достижение этих целей и выполнение поставленных задач. Затем осуществляется разбиение процессов на процессы более низкого уровня до тех пор, пока в результате декомпозиции не будет достигнут уровень приложений, выполнение которых возможно без дальнейшего разбиения. Далее определяются информационные потребности каждого приложения, определяются требования к данным, которые, в сущности, определяют локальные представления, о которых речь шла выше. Дальнейший процесс объединения этих локальных представлений, устранение возникающих противоречий, имеет своей целью создание единого цельного представления БД, называемого как уже упоминалось выше концептуальным представлением. К сожалению, следует констатировать, что проектирование БД все еще является весьма субъективным занятием, поскольку не существует действительно строгих методов решения этой задачи.
Концептуальная схема описывает общее представление в терминах некоторой абстрактной модели данных .
Любая модель данных содержит три компоненты:
Описание структуры данных , т.е. описание объектов, на которых строится БД.
Ограничения целостности , т.е. набор правил, которые ограничивают множество экземпляров этих объектов, допустимых в БД.
Набор допустимых операций , т.е. набор операторов, которые применяются для обработки экземпляров объектов.
Модель данных предполагает, как минимум, наличие языка определения данных (ЯОД) для описания структуры и языка манипулирования данными (ЯМД), включающего операции извлечения и модификации данных, а также наличие механизма поддержания соответствия данных предметной области на основе формально описанных правил.
Популярный подход к моделированию данных был предложен Питером Ченом в работе «Модель сущность-связь – к унифицированному виду данных». Этот подход основан на модели «сущность-связь» или ER-модели, обсуждению которой посвящена настоящая лекция.
ER-модель основывается на некой важной семантической информации о реальном мире и предназначена длялогического представления данных.
Укажем семантические концепции (конструктивные элементы), используемые в этой модели.
Сущности (мы будем пользоваться более привычным термином – Объекты ) подразделяются на правильные(сильные) и слабые . Слабым называется объект, который находится в зависимости от некоторого другого объекта, т.е. он не может существовать, если не существует этот другой объект .Правильным объектом называется объект, который не является слабым. Например, в базе данных фирмы, в которой хранятся данные о предпочтениях клиентов, объект «Предпочтения» является слабым, т.к. экземпляра этого объекта, соответствующего конкретному клиенту, не может быть в базе данных, если не существует соответствующий экземпляр объекта «Клиент». В частности, если данный экземпляр объекта «Клиент» будет удален, то так же должны быть удалены все зависящие от него экземпляры объекта «Предпочтения».
Возможны случаи, когда некоторый объект А является специальным видом другого объекта В . Тогда говорят, что А является подтипом В (или " А есть В ") или В является обобщением А . Например, в базе данных "Авиалинии" имеется объект "Служащие". Для указания того, кто из служащих является пилотом, можно в БД определить объект "Пилот" как подтип объекта "Служащий". Пилоты автоматически обладают всеми свойствами сотрудников, однако обратное утверждение неверно (например, для пилотов может быть дополнительно определено свойство "Тип самолета, которым пилот владеет в наибольшей мере" неприменимое ковсем сотрудникам). Аналогично, пилоты автоматически участвуют во всех связях (см. ниже), в которых участвуют сотрудники. О таких свойствах и связях говорят, что онинаследуются подтипом от супертипа.
Подтип в свою очередь может являться супертипом для объектов-подтипов следующего уровня, те в свою очередь для следующего и т.д., образуя, таким образом, иерархию типов для данного объекта. Пример такой иерархии представлен на рис. 1.
Рис. 1. Пример иерархии объектов
Иерархию типов не следует путать с иерархией данных. На рис.1 вовсе не подразумевается, что один сотрудник может иметь в подчинении нескольких программистов, наоборот, для одного экземпляра объекта "Служащий" существует максимум один экземпляр объекта "Программист", представляющий того же самого сотрудника в роли программиста.
Атрибуты и их классификация.
Напомним, что атрибут – это свойство объекта или связи, которое характеризуется именем и множеством допустимых значений.
Атрибуты подразделяются на простые и составные. Простой атрибут не может быть разделен на более мелкие независимые элементы (в рамках используемой модели данных). Составной атрибут состоит из нескольких независимо существующих элементов (например, составное свойство «имя сотрудника» может складываться из простых свойств «имя», «отчество» и «фамилия»).
Атрибуты также подразделяются на – однозначные и многозначные . Однозначный атрибут содержит только одно значение для каждого экземпляра объекта определенного типа. Многозначный атрибут может содержать несколько значений для каждого экземпляра объекта определенного типа . Например, название отделения или филиала компании -однозначныйатрибут, а номер телефона отделения – вообще говоря, многозначный (оно может иметь несколько номеров).
Еще одно разделение атрибутов – на базовые и производные. Базовый атрибут – это такой, значение которого не зависит от значений других атрибутов данного объекта или других. Производный атрибут - это такой, значение которого зависит от значений некоторого множества других атрибутов
Атрибут является ключевым , уникальным, если он однозначно идентифицирует каждый экземпляр объекта из данного набора .
Связи и их характеристики
Связи устанавливаются между объектами, называемыми участниками , а количество участников данной связи называется степенью этой связи. Связь может быть полной или частичной . Пусть R является связью, которая содержит объект Е в качестве участника. Тогда, если каждый экземпляр объекта Е находится, по крайней мере, в одном экземпляре связи R , то участие Е в связи R называется полным, в противном случае – частичным. Например, если каждый товар должен поставляться, по крайней мере, одним поставщиком, то участие товаров в связи между товарами и поставщиками является полным. Но если допустима такая ситуация, когда некоторый товар не поставляется ни одним поставщиком, то участие товаров в связи является частичным.
Обсудим несколько важных общих характеристик связей:
Связь может быть определена на более чем двух объектах. Например, связь объектов "Отделение"-"Специализация"-"Предмет"-"Вид испытания" определяет перечень испытаний (экзаменов, зачетов, курсовых и пр.), которые необходимо выдержать студенту, обучающемуся по некоторой специализации на конкретном (например, "дневном") отделении. Эта связь определяется, в частности, на четырех сущностях.
Может существовать несколько связей, определенных на одних и тех же множествах объектов . Например, связи "Работает над" и "Руководит" определяются на совпадающих множествах объектов {"Проект", "Служащий"}.
Связь может устанавливаться между разными экземплярами одного объекта. Такая связь называется рекурсивной.
Связь может определять зависимость существования (existence dependency) одного объекта от другого . Например, связь "Подчиняется" показывает, что существование экземпляра объекта в наборе "Подчиненный" зависит от присутствия экземпляра некоторого объекта в наборе объектов "Служащий".
Не много стоит построить небоскреб: знаний и умений - достаточно. Много стоит идея такого здания, которую можно реализовать в любых климатических условиях при возможных тектонических движениях земной коры: знаний и умений - будет явно недостаточно при этих (всего двух!), но кардинально существенных, условиях.
Сомнительно, что человек решится на концептуальное проектирование такой идеи. Есть уникальные технические решения, которые в разных странах мира разные специалисты реализовали в зданиях, мостах, телекоммуникационных сооружениях и других сложных конструкциях. Все это востребовано в конкретном месте для конкретной цели и рассчитано на конкретные условия применения.
Современное концептуальное проектирование - это статика. Условия применения результатов интеллектуальной деятельности человека - это всегда динамика. Сама человека - это непрерывное развитие (динамика).
Сегодня уровень науки, технологий и знаний слишком мал, чтобы создавать динамичные системы. Если человек проектирует самолет: это, как минимум, мотор и два крыла. Если создает престижный автомобиль, то у авто будет кожаный салон и четыре колеса. О подводных лодках, истребителях и космических кораблях вовсе можно не говорить: инерция и жесткая конструкция делают их уязвимыми для любого динамичного, не обязательно «интеллектуального», снаряда.
Каждая новая техническая система - лучше предыдущей. Она впитывает опыт создания предшественниц, нивелирует допущенные ранее ошибки и просчеты. Со статикой результатов интеллектуальной деятельности человека привыкли мириться: другого выхода нет. Допускать допущенные просчеты в концептуальном проектировании новых технических, социальных и иных систем уже не принято.
Любое проектирование - это спиралевидный динамический процесс, который адаптивно учитывает достигнутые ранее знания и умения, определяет изменения в области применения и ориентируется на обоснованные требования потребителя.
Не только человек, но и любое живое существо наблюдает и собирает информацию. Сознательно или подсознательно - не суть важно. Только в результате анализа воспринятых данных и «понимания» их сквозь призму накопленного опыта (знаний и умений) происходит анализ ситуации и принятие решения.
Человек разработал множество методов и инструментальных средств для сбора и анализа информации, но выделять этот процесс как стадию, например, подготовка данных или предварительное проектирование, бессмысленно. Человек сознательно воспринимает информацию и принимает решения, обдумывая текущие цели и задачи. Человек подсознательно выполняет гораздо больше действий и, в конечном итоге, именно подсознание подталкивает сознание к формированию правильного поведения и исполнению конкретного действия.
Сбор и анализ информации - это начало социальной или технической системы. Это сама по себе концепция начала работ. Всегда первичная информация собирается и изучается в контексте поставленной цели и решаемых задач. Всегда вторичная информация отражает все те же поставленные цели и задачи. Каждый новый этап - это концептуальное проектирование на новом витке развития знаний о достигнутом и достигаемом: о цели и решаемых задачах.
Человек не всегда придает объективное значение своей деятельности. Дело вовсе не в том, что он к этому не стремится, просто часто он ставит перед собой одни цели, но достигает другие. Концептуальное проектирование существовало всегда, но «сознательно» человек к этому отнесся только с появлением компьютерной техники и программирования.
Между тем, ассоциации: «концепция = информационная система» не существует. Во всяком случае: об этом свидетельствует современное положение вещей.
Простой пример. Система электронного документооборота организации. Сколько лет создавались такие системы? Сколько таких систем разработано? Сколько научных конференций - состоялось, копий - сломано, бумаги - исписано? По сей день ни один из результатов «концептуального проектирования» систем документооборота не состоялся как концептуально исполненный.
Жесткие конструкции синтаксиса и семантики языков программирования. Четкое понимание, что формализовать динамику области применения и решаемой задачи человек не в силах: знаний и умений явно недостаточно. Результат: всякая модель формализации области применения и требуемой задачи обращается в статическую конструкцию.
Современный мир виртуальных технологий мало чем отличается от пирамиды Хеопса. Изменить что-либо в созданной информационной системе крайне сложно. Любое изменение чревато существенными затратами стороннего труда (разработчика, программиста, автора): сама информационная система ничего «для себя сделать не может».
Естественное концептуальное проектирование, как пример создания идеальной системы, существовало всегда. Есть разница между тем, что человек делает, и что он понимает. Пирамида Хеопса не одинока в своем исполнении. Почти километр «изящных» железобетонных конструкций: небоскреб Бурдж-Халифа в Дубай (ОАЭ) - не единственное высотное сооружение. Аналогичных примеров можно привести множество: естественное концептуальное проектирование свойственно человеку, и человек это демонстрирует параллельно в различных регионах планеты в различных сферах социальной, производственной и духовной практики.
Любая роспись иконы в храме, выполненная на сферической поверхности, но воспринимаемая объемно и, естественно, с любого места в этом храме, создана многократно различными специалистами в различные времена.
Теория решения изобретательских задач (ТРИЗ), одно из заметных достижений прошлого века, была выполнена одним человеком, но привлекла внимание многочисленных специалистов, которые развили и использовали ее в реальной практике.
ТРИЗ - идеальный пример современного концептуального проектирования, начатый одним человеком и развитый множеством людей, но не достигший, объективно возможного, концептуального уровня развития.
ТРИЗ - заметное, но не монументальное достижение. Альтшуллер, Шапиро и тысячи их последователей внесли вклад в теорию, практику и изобретательское дело, но результат «ничтожен»: последователи и правообладатели, фантастические рассказы и статьи о сильном мышлении... в сравнении: Леонардо Да Винчи своими исследованиями полетов птиц и кардинально новой идеей: «не крыло должно махать, но аэроплан должен лететь» - прославился больше и украсил свои многочисленные концептуальные изобретения загадочной Джакондой.
ТРИЗ не строилась на фундаменте технического задания, а ее родоначальник Альтшуллер не руководствовался какими-либо методами выполнения работ. «Мастера» теории решения изобретательских задач и тысячи их учеников довольствовались малым:
С точки зрения общественного сознания, актуальности и полезности целевая установка ТРИЗ социально значима и имеет реальное практическое применение.
Автоматизировать процесс решения изобретательских задач, исключив из него «элементы случайности: внезапное и непредсказуемое озарение, слепой перебор и отбрасывание вариантов, зависимость от настроения и т. п» (цитата из "Википедии").
ТРИЗ существенно повлияла на общественное сознание и позволила многим тысячам специалистов решить реальные практические задачи. Было создано множество лабораторий изобретающих машин и спроектировано несколько десятков интеллектуальных систем.
Однако теория решения изобретательских задач по сей день ничем не отличается от курса средней или высшей школы, но гораздо слабее организована в методическом плане. Все три базовых постулата концепции ТРИЗ не имеют ровным счетом никакого значения. Ни об одной «изобретающей машине» общественное сознание до сих пор не имеет никакого представления, а идею искусственного интеллекта и возможность создания интеллектуальной системы уже давно не воспринимает всерьез.
Постулат «1»: нет разницы между естественной и искусственной системой, потому. как и то, и другое развивается не по определенным, а по объективным законам. То, что человек не познал или не понимает объективности законов Природы, ровным счетом для этих законов ничего не значит.
Постулат «2»: все системы развиваются, но причем здесь противоречия. Есть задача, есть необходимость ее концептуального проектирования, и есть проблема образования (квалификации) специалистов, задействованных в ее решении.
Постулат «3»: даже на пустом месте, которое обнаружили два квалифицированных специалиста в поисках одного противоречия, они сформулируют два десятка кардинально различных варианта решения.
Так было, есть и будет, пока уровень знаний и умений будет основываться на субъективном мнении, а не на объективных законах Природы.
Цели и задачи проектирования - это всегда важно, но гораздо важнее их концепция. Во всякой области применения развивающаяся естественная система или создаваемая человеком искусственная система есть нечто, обозначаемое целью, и спектр составляющих этого нечто, обозначаемый задачами. Есть требования, которые формулирует потребитель (заказчик), автор идеи.
Концептуальное проектирование (КП) - это динамика развития цели и составляющих ее задач, как способ движения к пониманию сути вещей, явлений и процессов. Человек сначала понимает, что нужно сделать, затем что-то делает и, переосмысливая созданное, пересматривает цель и составляющие ее задачи.
Интересная особенность поисковой выдачи по запросу: «методы и средства концептуального проектирования»: 97 % результатов связаны с информационными системами, программированием, базами данных и другими направлениями в области компьютерного дела и информационных технологий; остальные 3 % придутся на «более практичные» сферы социальных и производственных потребностей: авиационные двигатели, производственные процессы, социальные или природоохранные проекты и другое.
Странная особенность человеческого менталитета, когда он приобретает знания и приближается к пониманию объективных законов Природы: ставить свои достижения на первое место, пренебрегать достижениями других людей и считать только свой собственный опыт определяющим критерием познания окружающей среды и влияния на нее.
Концептуальное проектирование: примеры из области разработки программного обеспечения.
1) В настоящее время принято выделять следующие методологии разработки ПО:
2) Основными этапами КП являются:
3) Есть два подхода к КП:
Другие определения методов, инструментальных средств, трактовки целей и задач в современном общественном сознании отражены в аналогичном стиле.
Трудно согласиться с авторами разнообразных концептуальных теорий, методик и средств выполнения концептуального проектирования. Во-первых, компьютерное дело - не самое главное в социальной и производственной сфере, хотя имеет огромное значение. Во-вторых, идея формализации - это гарантия статики и жестких конструкций при решении абсолютно любой задачи. В-третьих, при всем надлежащем и уважительном отношении к знаниям и умением признанных авторитетов и специалистов приоритет имеют не их знания и умения, а объективные законы природы.
Наука и практика обязаны теории решения изобретательских задач. Это было на самом деле великое дело: систематизировать физические, химические, социальные и другие достижения, практические решения, изобретения, технологические процессы. Задача сформулировать системы физических эффектов или определить объективные закономерности - воистину актуальна, была всегда, и в современном мире ее актуальность стремительно растет.
Объективный подход в проектировании: ничего жесткого и формального, все процессы и понятия развиваются, непрерывно пересматриваются анализируются и совершенствуются. Говорить о концептуальном проектировании в формальном ключе нельзя. Фиксировать смысл в терминах реляционных или иерархических отношений между предметами или явлениями, значит фиксировать конечный результат.
Суть не в том, что такое цель, задача, средство или метод. В концептуальном контексте важен смысл, а не его формальное обозначение.
Менталитет венца Природы - человека по сей день не позволяет ему наделить иное живое существо интеллектом. Человек до сих пор не понимает, что его ровным счетом ничего не значит для объективных законов Природы.
Человек может считать, что действует сознательно и не понимать, что его мозг непрерывно делает что-то бессознательно, чтобы уже через три года ребенок после рождения начал, к примеру, выражать свои потребности словами, а к пяти годам строить пирамиды из кубиков, а к десяти годам мечтать о полетах на Луну или статусе известного композитора.
Концептуальное проектирование своего поведения пчела делает на автомате. Результат - есть польза пчелиной семье, окружающей среде и человеку. Пусть человек считает, что интеллектом пчела не обладает. Это ровным счетом ничего не значит.
Концептуальное проектирование своего поведения делает каждый человек лучше, чем пчела: у него гораздо больше функциональных и интеллектуальных возможностей. Не обязательно быть великим архитектором, конструктором истребителей пятого поколения. Достаточно быть простым преподавателем средней школы и без знания ТРИЗ, на одном дыхании создать концепцию подготовки детей к сложной и интересной жизни в обществе. На благо себе и людям.
Концептуальное проектирование порой называют техническим . Его основными этапами являются:
1) предварительное проектирование,
2) эскизное (рабочее или техно-рабочее) проектирование,
3) изготовление, испытания и доводка опытного образца системы (рис. 4.3).
Рис. 4.3. Этапы концептуального проектирования.
Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы . При этом оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования. После построения проекта уточняется исходный бизнес-план. Выходными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточнённый бизнес-план.
В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность, внесение изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны “Заказчика”, так и “Разработчика”. Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения и чем позже эта потребность возникает. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа.
На стадии разработки , интеграции и тестирования должна быть создана тестовая БД и тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация БД и приложений. Приложения интегрируются в систему, проводится их тестирование в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему.
В результате такого проектирования должна быть получена логическая структура системы (подсистемы, модуля и др.), схемы вводы, вывода, представления, преобразования данных и т.п.
В соответствии с уставными правилами и документацией проекта заключительный этап создания системы предполагает комплексное тестирование всех её компонентов, обучение пользователей, постоянное администрирование и др.
Стадия внедрения включает в себя действия по установке и внедрению баз данных и приложений. Основной результат стадии – готовая к эксплуатации и перенесенная на программно-аппаратную платформу Заказчика версия системы, документация сопровождения и акт приёмочных испытаний по результатам опытной эксплуатации.
На стадии эксплуатации осуществляется постоянный (лучше – автоматический) контроль работоспособности системы (мониторинг) с целью отслеживания состояния объектов, своевременного выявления ошибок и нештатных ситуаций, её развития.
Стадии сопровождения и развития включают процессы и операции, связанные с регистрацией, диагностикой и локализацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространением новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием системы. Стадия развития фактически является повторной итерацией стадии разработки.
Результатом концептуальной стадии проектирования АИС является итоговый документ – “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.
Концептуальное проектирование системы характеризуется сжатыми сроками. По этой причине выполнение работ, связанных с ним и предпроектным обследованием объекта могут осуществляться параллельно или перекрываться по времени их выполнения.
При проектировании, в т.ч. при решении проблем автоматизации процессов, обычно изначально принимается один из двух вариантов: создание системы решающей сиюминутные задачи или включающей и перспективные задачи (“на вырост”), учитывающие будущие потребности.
В первом случае можно выбрать недорогое решение и быстро его реализовать. Однако высока вероятность, что достаточно скоро такую систему потребуется в значительной степени модернизировать или заменить.
Во втором случае потребуется более серьёзная проработка требований и технических решений, влекущая за собой увеличение сроков выполнения и стоимости проекта. Но в этом случае возможно на гораздо больший период времени продлить эффективное функционирование созданной таким образом системы. Однако большие инвестиции сопряжены с бóльшими рисками. Поэтому рекомендуется разбивать предстоящие работы на небольшие этапы, реализация которых способна принести конкретный и ощутимый результат, обеспечивающий решение поставленной задачи. В этом случае при минимальных инвестициях можно обеспечить быструю отдачу и создать фундамент дальнейшего развития системы, способствующий, в том числе, изучению полученных результатов, корректировки дальнейших действий и т.п. Таким образом, разработка системы приобретает цикличный характер. И хотя подобный подход несколько более затратный, чем комплексное решение масштабной задачи, он позволяет уменьшить высокие риски, связанные с изменениями требований к разрабатываемой системе.
Не следует упускать из виду, что быстрое развитие науки, техники и технологий приводит к быстрому старению используемых методов и систем, что отрицательно влияет на эффективность их использования. При этом поэтапно вносить изменения в отдельные компоненты системы значительно проще, чем заменять её полностью. Кроме того, обычно требуется обеспечить быстрый возврат инвестиций, что достаточно сложно организовать при внедрении комплексных решений.
Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.
При реализации крупных проектов обычно прибегают к помощи хорошо зарекомендовавших себя крупных компаний-интеграторов, в том числе консалтинговых и внедренческих организаций.
Для реализации средних проектов стараются обойтись своими силами и (или) используют готовые решения, которые стремятся адаптировать под конкретные требования организации-заказчика.
Малые проекты характеризуются использованием готовых решений и, в ряде случаев, адаптацией их под конкретные условия использования.
Проектирование ИС начинается с составления в текстовой и (или) графической форме плана работ. На первом этапе проектирования необходимо выяснить требования пользователей к системе и, на основании этих требований, сформировать макет системы. Предпочтительно осуществлять проектирование модульным методом. Проектирование информационных систем непосредственно связано с их программированием, поэтому значительная часть проектных работ связана с программированием ИС.
Модульное программирование – метод разработки программ, предполагающий разбиение программы на независимые модули. Считается, что модуль должен обладать оптимальными размерами (как правило, целиком помещаться на экране дисплея) и что разделение большой программы на модули облегчает её разработку, отладку и сопровождение.
Программный модуль, объединяющий в себе данные (свойства) и операции над ними (методы), называют объектом.
Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики.
На выбор средств проектирования могут существенно повлиять следующие особенности методов проектирования:
· ориентация на создание уникального или типового проекта;
· итерационный характер процесса проектирования;
· возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей;
· жёсткая дисциплина проектирования и разработки при их коллективном характере;
· необходимость отчуждения проекта от разработчиков и его последующего централизованного сопровождения.
ER-модели
Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В 1976 году Чен (Chen) предложил для проектирования ИС (баз данных) использовать ER-модели
(Entity Relationship model – модель «сущность-связь»), представляющие концептуальные модели данных. Они получили широкое распространение в современных CASE-системах, поддерживающих автоматизированное проектирование ИС и обычно используются на этапе информационно-логического моделирования.
ER-модель наглядно изображает структурные блоки информации и логические взаимосвязи между ними. Основными понятиями являются сущность, связь и атрибут (см. Таблицу).
Таблица понятий: сущность, связь и атрибут.
Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать много сотрудников. На рисунке приведен пример ER-диаграммы.
На основе ER-моделей последовательно формируют реляционные БД.
Важным параметром ИС является простота её использования, включающая обеспечение качества проектной документации. При проектировании следует ориентироваться на следующие документы:
ГОСТ 24.602-86 . Автоматизированные системы управления. Состав и содержание работ по стадиям создания. (Введён с 01.01.89.–М.: Изд-во стандартов, 1986.–12 с.).
ГОСТ 34.601-90 . Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания (Введён с 29.12.90, 24.601-86. 24.602-86. 1997 г.).
ГОСТ 34.602-89 . Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Введ. 01.01.90.
ГОСТ 34.603-92 . Информационная технология. Виды испытаний автоматизированных систем.
РД 50-640-87 . Системы автоматизированного проектирования. Порядок выполнения работ при создании систем: Инструкция.–М.: Изд-во стандартов, 1987.–28 с. и др.
Чтобы у пользователя были более четкие понятия о функционировании той или иной системы, проектировщик создает концептуальную модель того или иного приложения. В этих целях используется различная документация, графики, спецификация, диаграммы и так далее. Чтобы вы могли точно понять, что такое концептуальная модель, какие она преследует, в данной статье мы решили более подробно остановиться на этом понятии.
Концептуальная модель - это определенная схема. Она в целях формирования смысловой структуры некоего объекта использует различные понятия и связи между ними. Однако стоит учитывать тот момент, что концептуальная модель системы абстрактна. Но это не единственное значение термина. Кроме того, существует понятие "концептуальная модель Смысл данного термина состоит в том, что для описания какой-либо сферы используется перечень связанных между собой понятий. В этих целях используются классификация определений, их характеристики и свойства, а также законы происходящих в них процессов.
Стоит отметить, что концептуальная модель создается в первую очередь для облегчения восприятия информации обычным пользователем. Другими словами, разрабатывается узконаправленное и подробное описание действия структуры. Чтобы добиться данного результата, необходимо в первую очередь сделать эту модель наиболее простой (с этой целью используют минимальное количество значений). А во-вторых, постараться максимально ориентировать ее на выполнение определенных задач (то есть максимально ограничить работу пользователя с нефигурирующими значениями в данной области).
Концептуальная модель преследует следующие цели:
Создать простую, последовательную и удобную в использовании и изучении структуру. С этой целью области задач разделяются на понятия, которые можно использовать для работы с разными объектами.
Сохранить устойчивость терминологии. Это достигается тем, что концептуальная модель данных, состоящая на начальном этапе из словаря терминов, используется для распознавания каждого действия и объекта, расписанного в программе.
Как доказано, неиспользование данной терминологии приводит к тому, что для определения одной схемы используются несколько понятий, или один и тот же термин применяется для описания различных схем.
Этот процесс заключается в создании первоначальной схемы. В дальнейшем разработчик сможет применять ее для реализации программного обеспечения. Чтобы дать описание сложной системе, используется некий алгоритм поведения компонентов данной системы, отражая, таким образом, их взаимодействие между собой. Бывают случаи, когда информации, содержащейся в описании, оказывается недостаточно, чтобы понять и изучить объект моделирования. Чтобы исправить данное упущение, следует возвратиться к этапу составления оглавления и добавить те данные, отсутствие которых было установлено при формализации объекта. Причем, как показывает практика, подобных возвратов может быть несколько. Кстати, создание рассматриваемых в статье схем для простых структур не оправдано.
В нашли применение разные концептуальные модели, имеющие различную структуризацию. Чаще всего их схемы ориентируются на математические теории. Это приводит к проблемам выбора подходящей системы описания необходимого объекта моделирования. Так, к примеру, для дискретных схем принято использовать процессно-ориентировочные структуры. Чтобы составить непрерывную конструкцию, используют потоковые диаграммы системной динамики. Концептуальная разрабатывается с использованием специального языка, который закреплен в самой конструкционной структуре. Дабы упростить построение и программирование той или иной схемы, используются специально разработанные приемы технологии программирования.
Следует знать, что концептуальная модель включает в себя ряд важных элементов. В первую очередь к ним относятся исследование объектов и изучение их действий. То есть пользователь должен изучить список всех видимых для него приложений и манипуляций, которые он может совершать над каждым объектом в отдельности. Естественно, что в разработке системы могут (и, скорее всего, будут) присутствовать и другие объекты, однако они будут скрыты от пользователя.
В ряде случаев при создании объектов концептуальной модели используют принцип структурной организации многоуровневых систем. Таким образом, разработчик достигает более легкого проектирования понятного для пользователя объекта. Подобное построение способствует управлению реализацией системы, а также облегчает создание структур команд приложения. То есть разработчик может определить, какие действия применимы к различным объектам, какие из них могут быть обобщены. Это дает возможность сделать структуру команд наиболее доступной для восприятия пользователем. То есть вместо того, чтобы изучать огромное количество объектно-ориентировочных команд, необходимо всего лишь освоить обобщенные. Анализируя все вышесказанное, можно сказать, что концептуальная модель - это всего лишь схема, которая определяет свойства элементов планируемой структуры и ее причинно-следственные связи, необходимые для достижения поставленной цели конструирования.
