Что такое система конструктор
Обновлено: 28.04.2024
Использование решений-конструкторов не является чем-то новым – многие разработчики не раз говорили о том, что тот или иной продукт имеет функцию конструктора и позволяет на его основе создавать готовое ПО. Тем не менее, их возможности ограничены, и на деле продуктом такой работы становятся лишь весьма ограниченные по функционалу решения. Новый инструмент со старым называнием анонсировала компания "ДоксВижн", заявив, что в реальностиэто совершенно иной продукт, существенно отличающийся от своих предшественников. В чем же заключаются эти отличия и насколько новый "Конструктор решений" облегчит жизнь и интеграторам, и заказчикам?
Отдельно хотелось бы обратить внимание на то, что "Конструктор решений" позволяет осуществлять новый подход к описанию состояний и ролей, предоставляет возможность переиспользования решений и их частей, имеет удобный механизм распространения решений за счет легкости создания инсталляционных пакетов, а также использует новый способ рассылки уведомлений – с помощью сервиса уведомлений.
Истина – в сравнении
На самом деле существует 4 способа разработки карточек. Первый, активно применяемый до настоящего времени - на универсальной карточке. Он примечателен тем, что не порождает новых типов карточек. Второй способ – на "Конструкторе решений". Среди его отличительных черт – визуальное проектирование интерфейса и карточки, а также минимум кодирования (с использованием скриптов). Третий способ - на основе базовой карточки того же "Конструктора решений". За счет него есть возможность создавать более сложные собственные разработческие решения, тем не менее, использующие в своей основе базовую карточку конструктора и многие его возможности. Последний способ разработки карточек – это создание полностью собственных решений с нуля. Попробуем определить, какие возможности и ограничения имеет тот или иной способ. Для начала рассмотрим метод "Универсальной карточки", поскольку изначально его возможностей практически хватало для создания полноценного решения а-ля Канцелярия.
Сравнение способов разработки на базе универсальной карточки и с помощью "Конструктора решений"
Источник: "ДоксВижн", 2011
Теперь рассмотрим случай, когда функциональных возможностей универсальной карточки недостаточно для создания решения, и приходится разрабатывать полностью новую карточку с помощью либо DeveloperStudio, либо конструктора решений. При этом при разработке в DeveloperStudio карточка может быть создана двумя путями: с нуля и на основе базовой карточки конструктора.
Сравнение способов разработки карточек с нуля и на конструкторе решений
Источник: "ДоксВижн", 2011
Приведенный выше анализ показывает, что метод с использованием "Конструктор решений" является более удобным, быстрым и функциональным способом разработки. Кроме того, в случаях, когда возможностей встроенного вконструктор способа работы с данными недостаточно и требуется программирование под конкретную сложную задачу, "Конструктор решений"может предоставить для разработки в качестве основы базовую карточку с богатым встроенным функционалом и всеми основными возможностями по настройке.
Теперь поговорим подробнее об использовании особенностей конструктора и применении разных способов разработки.
Олег Баранов окончил в 1989 году Санкт-Петербургский Государственный Технический Университет, начинал свой путь в ИТ-сфере разработчиком отечественной системы автоматизированного проектирования печатных плат ПРАМ 5.3. С 1995 года трудился в компании Typhoon Software, занимался системами искусственного интеллекта и IP-телефонии. В 2000 году пришел на работу в компанию Digital Design, где стал заниматься задачами электронного документооборота, руководил проектами по внедрению и отделом по разработке информационных систем. С 2008 года работает в компании "ДоксВижн" и занимает должность директора по продуктам и решениям. Олег является идеологом создания "Конструктора решений".
Одним из самых серьезных преимуществ нового инструмента является возможность быстрого прототипирования будущей системы для заказчика. Описав задачу формально и выделив необходимые объекты, можно сразу переходить к их визуальному созданию. При этом за достаточно короткий период времени можно создать работающий прототип.Для этого необходимо нарисовать интерфейс объектов и установить связи между ними, настроить права доступа, после чего разработчик получает уже работающее приложение, умеющее редактировать и сохранять самые разные данные и может продемонстрировать его заказчику, обсудить с ним детали. Хотелось бы отметить, что при создании решения нет резона удалять прототип. В дальнейшем для созданных карточек потребуется лишь описать привычную XML-схему, привязать интерфейсные элементы к полям вместо свойств, и добавить логику с помощью скриптов.
С технологической (архитектурной) точки зрения система-конструктор – это программный продукт, который: включает ядро, в котором определена принципиальная модель предметной области, а также базовый набор классов (максимально абстрактных) и основных методов работы с ними; включает конфигурацию, которая представляет собой реализацию информационной системы, построенной из классов и методов ядра; включает инструментарий, позволяющий пользователю строить свой собственный вариант конфигурации
Задачи управления в каждой организации, несомненно, являются уникальными, но, как правило, для всякого конкретного вида деятельности можно выделить типовые задачи. Подробный перечень типовых испецифических задач и их взаимосвязей может стать прототипом технического задания на систему.
При анализе функциональности системы-конструктора целесообразно все требуемые функции подразделить на ряд категорий: а) функции, уже реализованные в типовых конфигурациях системы-конструктора; б) функции, не реализованные в типовых конфигурациях, но которые можно реализовать при помощи средств конфигурирования; в) функции, которые нельзя реализовать (собственными силами) без коренной переделки системы.
ИС – трансформер, реализует базовую функциональность по управлению данными, по реализации бизнес логики и предоставлению графического пользовательского интерфейса, но не имеет реализованной бизнес модели для начала эксплуатации в рамках какой-либо предметной области.
Какие существуют способы приобретения ИС?
Способ приобретения ИС — последовательность действий от определения и формализации потребностей в информационной системе до момента, пока ИС не будет внедрена на предприятии.
Классификация способов приобретения ИС:
покупка готовой ИС;
разработка ИС (самостоятельная или заказная);
покупка и доработка ИС;
Преимуществами закупки готовых ИС являются: время разработки равное нулю; система тиражирована (наличие документации)
Недостатками закупки готовых ИС являются: система тиражирована (Вопросы защиты информации); необходима адаптация к предъявляемым требованиям.
Недостатками разработки ИС специализированной фирмой являются: длительное время разработки
Недостатками самостоятельной разработки ИС являются: длительное время разработки; отсутствия должной квалификации разработчиков; необходимость создания отдела ИТ.
Преимуществами самостоятельной разработки ИС являются: система уникальна; хорошая адаптация к предъявляемым требованиям
Преимуществами разработки ИС специализированной фирмой являются: система уникальна; хорошая адаптация к предъявляемым требованиям; наличие должной квалификации разработчиков.
Аутсорсинг ИС – это: заказ информационной системы фирмой-потребителем у фирмы-производителя ИС; сдача ИС фирмой-производителем в аренду фирме-потребителю ИС; выполнение сторонней фирмой обработки информации для фирмы-потребителя.
Преимуществами аутсорсинга ИС являются: возможность сфокусировать внимание компании на ее основном бизнесе; возможность гибко реагировать на изменения на рынке и внутри компании; отсутствие необходимости в расширении штата компании; сокращение затрат на операции.
Недостатками аутсорсинга ИС являются: возможность потери поставщика (надежность)
Каковы преимущества и недостатки разработки ИС фирмой-разработчиком ИС?
• проект выполняет высококлассная команда профессионалов;
• полноценное документирование проекта;
• разрабатываются с учетом специфики конкретного предприятия, требований и пожеланий специалистов предприятия, которые будут эту ИС использовать;
• могут быть реализованы нестандартные, экзотические функции, которые никогда не появятся в коробочных системах;
• бывает, что на предприятии работает другая ИС, которую заказчик не хочет менять (или даже несколько). В таком случае могут быть заказаны средства интеграции этих систем в одну с целью сохранения бизнес-процессов и накопленных данных;
• отсутствует лишняя функциональность. Интерфейс не перегружен и работать с такой системой обычно проще;
• заказные системы производительнее универсальных и предъявляют меньшие требования к аппаратуре;
• заказная система может развиваться разработчиком в требующемся заказчику направлении;
• разработка, настройка и сопровождение находится в одних руках профессионалов, что повышает устойчивость системы;
• часто самая большая стоимость;
• часто занимает самое длительное время;
• наличие самого периода разработка;
• отсутствует возможность заранее познакомиться с системой, "пощупать ее руками";
© 2014-2022 — Студопедия.Нет — Информационный студенческий ресурс. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав (0.01)
Навскидку, выставка «Меркур и другие конструкторы» в культурном центре ЗИЛ не производит впечатления — вот конструктор металлический, вот пластмассовый, вот инженерный и т.д.
Но один стенд привлекает внимание — он демонстрирует с десяток цифровых конструкторов, среди которых:
— конструктор фантастических существ для школьников, который объясняет всю культуру Древней Греции за 5 минут,
— онлайн-конструктор роботов из подручных материалов, объясняющий, куда девать старый пионерский значок с Лениным,
Раз конструкторы все чаще попадаются нам в цифровой форме — полезно знать общую концепцию их устройства. Об этом и поговорим с экспертом.
Оказывается, автор цифровых конструкторов со стенда сидит в том же здании, где проходит выставка.
 | Николай Селиванов — художник, преподаватель, автор электронных обучающих систем. Руководит проектом «Мастерская художественного проектирования» (творчество для детей) и организует выставки в ДК ЗИЛ. Ведущий специалист проекта Education, Art and ICT: integration for development of one's personality в Институте ЮНЕСКО по информационным технологиям в образовании, член президиума НП АДИТ (Автоматизация деятельности музеев и информационные технологии). |
Мы проговорили с Николаем два часа и выяснили — для чего бы ни создавался цифровой конструктор: для школы, для игр или для бизнеса, — он будет работать по одним и тем же законам.
1. Показываем принцип, а не учим паттерну
Николай: «Когда я вижу родителей, которые покупают детям только «Лего», я говорю им: «А кем вы хотите видеть его, когда человек закончит вуз — исполнителем в большой компании или творцом и, возможно, владельцем этой компании?»
Дело в том, что с точки зрения рассказывания историй «Лего» прекрасен — например, мы собираем с внуком батискаф, а параллельно я знакомлю его с темой подводных исследований. Но с точки зрения развития творческого мышления — этот конструктор слабоват, т.к. в нем часто учат собирать определенную вещь строго определенным образом.
Занятие при «Мастерской художественного проектирования», которой руководит Николай
Задача же конструктора: дать получить опыт создания тех или иных вещей — то есть, понять базовый принцип, а не научиться делать «конкретно так». В этом плане даже простые кубики — отличный пример правильного конструктора. С ним можно многое — да хоть модель мироздания объяснить.
Еще один хороший пример, который я встречал — брошюры и книги для «самоделкиных», которые массово издавали в 1930-х. Например, там говорится примерно следующее: «Вот вам принцип работы пропеллера; понимая его, вы можете сделать с ним хоть самолет, хоть квадрокоптер». То есть, показывается база, с которой можно добиться многого и разного. А не пошаговая инструкция на каждый случай, которая засядет в голове».
uKit: Когда мы только начали писать о конструкторах на Гиктаймсе, в комментариях появился пересказ истории про «конструктор это только для того, чтобы сделать вот так» — оказалась, проблема понимания, зачем нужен конструктор, иногда реально существует:
Хотя конструктор — что обычный, что цифровой, — решает задачу познания и прощупывания нового направления. Прохождения первых шагов через личный опыт, основанный на опыте других.
Например, Scratch – это и визуальная среда для обучения школьников программированию, и первые шаги в анимации, которые продумали за вас специалисты из MIT.
Те же простенькие онлайн-конструкторы баннеров и обложек от «Лего» — это первые шаги в графическом дизайне для маленьких, учитывающие и маркетинговую задачу, и демонстрацию того, как делать плакат/баннер/коллаж.
И так — вплоть до взрослого цифрового конструктора.
Сестра нашего бразильского коллеги собирает сайт на конструкторе где-то в Сан-Паулу
Любой сайт может быть собран по-разному, и ваша задача как разработчика конструктора — указать общий путь и дать простор для разумного творчества, выделив основные моменты. А не вбить в голову концепцию, что «любой сайт должен содержать в-о-о-от такую кнопку зеленого или красного цвета, точно говорю, у меня брат так поднялся».
А потому элементы и логика подбираются под каждый конструктор по ситуации.
2. Ситуативность и решение конкретных задач
Николай: «Каждому конструктору свое время и место. Каждый мой конструктор — это попытка решить проблему. Например, возьмем группу школьников, отведем их в зал античного искусства. На месте будем долго рассказывать им, как делались знаменитые греческие вазы. Но! Принцип, по которому они создавались, останется «закрытым» для них, поверьте — новые поколения часто не воспринимают культурный опыт прошлого.
А этот принцип есть. Любой инженер сказал бы — это принцип агрегата: когда сочетание различных элементов образует систему для решения какой-либо одной задачи.
Дети изучают конструктор фантастических существ на продвинутых уроках ИЗО
Так я придумал конструктор фантастических персонажей — он дает наглядно прочувствовать методу, по которой создавались изображения для разных типов античной керамики. Когда дети 2-8 классов, попробовав такой конструктор, приходят в музей, они понимают, как, зачем и из чего был создан объект.
А этот конструктор можно бесплатно скачать в App Store и Google Play (версию для планшета проектировал уже не Николай)
Мы хотели дать представление о том, как работали художники того времени. И конструктор основан на методической схеме написания классического пейзажа — это конкретная цветовая схема, конкретное понятие перспективы и принципов расположения объектов на планах.
uKit: Цифровые конструкторы всегда основывались на решаемой задаче. Взять, например, uCoz – первый проект нашей компании. В 2005-м он решал проблему основателей и их «тусовки» — сделать фан-сайт, форум, блог или портал, не углубляясь во FreeBSD. Это был продукт для гиков.
Когда на сломе 2000-х соцсети стали заменять фан-сайты и порталы, а малый бизнес стал выходить в интернет, появилась идея нашего uKit — «конструктора попроще».
В нем также реализована система мягких «сдержек и ограничений», подталкивающая человека к понимаю, какие данные важны на сайте. Например, на первом шаге мы просим создателя сайта заполнить поля адреса и дать телефон своего предприятия — потому что для клиента автосалона или мастерской по ремонту техники эта важная информация.
Цифровой конструктор в 2016-м году. Типовой блок стартового экрана главной страницы, например, подталкивает к мысли — посетитель с первого взгляда должен понять, что это за сайт.
Такие мягкие подсказки не ограничивают творческий порыв — любой блок можно удалить или переделать. Но в каждом цифровом конструкторе есть и границы, которые невозможно преступить.
3. Встроенные ограничения
Николай: «Важная задача для автора конструктора — найти грань между оригинальностью своей разработки и ее простотой. Потому что придумывать конструктор и пользоваться им — это разное. Создавая свои конструкторы, я пришел к такой схеме: есть сетка, четкая палитра и четкий набор элементов, из которых можно выбирать, — плюс несколько вариантов их соединения. Своего рода система ограничений.
Например, взять тот же конструктор фантастических животных, который с учебниками покупают образовательные учреждения. Я даю в нем очень ограниченную палитру.
Но в том же конструкторе классических пейзажей, вы видели, палитра богаче. Водораздел возможностей проходит иначе — мы ввели ограничения по перемещению между основными планами картины. Эти рамки сложились исторически, их определили сами художники того времени — начиная от того, где и что может располагаться (например, на классическом пейзаже архитектура всегда на среднем плане, а на переднем — событие), и заканчивая тем, на что должен быть обращен фокус внимания.
Такое ограничение дисциплинирует».
uKit: Понятно, что любой цифровой конструктор имеет рамки «что можно, а что нет» еще и банально потому, что изменения в систему может внести только разработчик. А у разработчика план расписан на полгода-год вперед: и иногда бывает важнее выпустить версию для слабовидящих, а не пилить «штуку, которая. ».
Конечно, в итоге часть пользовательских хотелок реализуется. Но бывают ограничения, которые намеренно «прибиты гвоздями». Например, у себя мы тоже ввели ограничение на палитру цветов — пользователю дается три набора, зависящих от тематики шаблона (бизнеса).
Речь, конечно, не о том, что «машина может быть любого цвета, если она черная». Это и учет психологии цветов (простой пример: сайту турфирмы подойдут бирюзовый и синий, так как они ассоциируются с морем и небом). И внимание к деталям: чтобы палитра и набор шрифтов совпадали на любой странице.
Наконец, если вы создаете сайт для пекарни, едва ли светло-розовый текст на кислотно-желтом фоне будет идеальным решением. А есть те, кто пытается так сделать…
Есть и другие полезные ограничения — например, нельзя встроить виджет комментариев никуда, кроме блога. Во-первых, зачем малому бизнесу виджеты комментариев по своему сайту, когда есть онлайн-чат, обратный звонок и форма обратной связи? Во-вторых, как Николай и многие другие, мы пришли к сетке, поддерживающей конструктор: она выполняет прикладную функцию — помогает сайту адаптироваться под разные экраны на лету.
4. У созданных в конструкторе объектов должны быть имена
Николай: «Каким бы конструированием мы ни занимались c детьми, я всегда подталкиваю ребят к тому, чтобы они давали имена своим творениям. А в цифровой среде имя — это одно из тех самых полезных ограничений. Например, как-то мы сделали конструктор роботов из домашнего хлама: вы берете, например, пионерский значок с Лениным, консервную банку, лампочки, гайки — собираете из них двухмерного робота, а затем пишете инструкцию к нему.
Одно из условий в нашем конструкторе — придумать роботу имя и дать серийный номер. Чтобы все было по-взрослому».
uKit: Для человека это естественно — давать имя своему «детищу». Ну а для любой информационной системы нужен идентификатор, по которому, в идеале, не только робот, но и человек сможет найти конкретное творение.
Когда вы делаете анимацию в Scratch — надо дать ей название. Когда вы приручили лошадь или другой «моб» в Minecraft — хочется дать название, причем за эту привилегию еще и бывает нужно заплатить — купить в игре «бирку».
Когда человек сделал сайт — в идеале, ему нужен не технический домен третьего уровня, который автоматически выдается любым конструктором, а полноценное имя для сайта. Это не только мягкая попытка заработать лишних 600-900 рублей в год, но мягкая подводка к тому, чтобы сделать творение завершенным.
5. Обычно он стоит денег
Николай: «Большая часть работ монетизируется по заказу: например, конструктор для Третьяковки спонсировала «Северсталь» (мы также делали для компании еще один, корпоративный конструктор).
Конструктор фантастических животных продает издательство как дополнение к учебнику ИЗО.
Почти все свои конструкторы я создал в 2000-х — и их носителем стал CD. Диски с конструкторами, доступными к розничной продаже, я даже одно время выставлял на сайте. Конечно, сейчас мы думаем, как перестроиться — почти все конструкторы имеют веб-версии, которые мы поднимаем под заказ, но они созданы на Flash. А все уже перешли на HTML5».
uKit: У онлайновых конструкторов есть одно преимущество — модель SaaS давно заменила для большинства не только диски, но и флешки. И вроде не собирается умирать.
В остальном, если за вами не стоят ресурсы MIT (как со Scratch), пиар-задача (как было с Lego Digital Designer — но проект закрыли) или у вас не опенсорсный проект, поддерживаемый большим сообществом, рано или поздно ваш конструктор придется монетизировать.
Банально потому, что, возвращаясь к пункту 3 нашего обзора, — есть команда, которая поддерживает проект и хочет кушать. Будь то Minecraft – вот хорошая хабрастатья об их монетизации, которая началась почти сразу же, еще до «всеобщей монетизации» три года назад. Будь то конструктор сайтов — сегодня на рынке нет бесплатных решений, если это не студенческие поделки.
6. Ни в один конструктор не играют вечно
Николай: «Не встречал людей, которые играли бы с любым конструктором все время, не переключаясь на новые. Конструктор, особенно цифровой — это демонстрация методики. Ты изучил ее, осмыслил — и пошел дальше».
uKit: В мире ИТ-проектов на этот счет есть понятие срока жизни клиента. Например, средний срок жизни сайта малого бизнеса, собранного на конструкторе, — 2 года. Либо он пощупал для себя интернет, понял, чего хочет — и пойдет осознанно щупать более сложные платформы, либо — как это ни печально, за такой срок предприятие часто просто закрывается.
7. В нем можно смешивать технологии
Николай: «Фишка цифровых конструкторов, будь то детские учебные программы, игры или специализированные решения — это возможность совместить их с новейшими технологиями. И самое перспективное тут — применение VR в цифровых конструкторах.
Мне кажется, такая интеграция откроет массу новых применений цифровым конструкторам — в обучении, бизнесе (например, туризме), сохранении культурного наследия и других сферах».
uKit: Да, тот же Minecraft показывали в сочетании с очками виртуальной реальности:
В мире конструкторов сайтов VR пока едва ли применим. А вот ИИ — в самую точку. Сегодня сразу несколько конструкторов веб-сайтов пробуют встроить нейросети в свои продукты, чтобы облегчить самый нудный этап — прототипирование сайта под задачу бизнеса.
Хей йо, Хабр! Меня зовут Королёв Николай. Я инженер-конструктор компании BIMeister и при этом успеваю доучиваться в Московском Политехническом Университете на факультете машиностроения. Наш отдел разрабатывает высокодетализированные 3D модели для крупнейших компаний на рынке, к примеру, Газпром, а также внедряет BIM технологии в объектные модели.
Технология САПР
Создание механизмов и машин в условиях прогрессивного роста современных технологий требуют от инженера владения современными методами расчёта и конструирования. При проектировании механизмов машин инженеры-конструкторы обращаются к цифровой модели. Но как её получить? Для разработки таких машин всё больше внедряется технология САПР.
САПР – это автоматизированная система, которая выполняет функции проектирования с упрощёнными способами по внедрению ряда информационных данных и технологий. Отсюда мы получаем главную функцию данной технологии — автоматизация.
Уже многие годы и всё чаще старые методы уходят на задний план. Лишь редкий представитель инженера, но опытный человек в своём деле, предпочитает бумажные чертежи электронным. Именно оптимизация процесса — великий “перестройщик” нашего времени.
Для выполнения разного вида оптимизации САПР делится на несколько типов системы:
CAD (Computer-aided design) - системные комплексы для проектирования,
CAE (Computer-aided engineering) - современные системы инженерного анализа,
CAM (Computer-aided manufacturing) – прописывания алгоритма действий станков с ЧПУ.
Рассмотрим простейшие примеры из жизни.
CAD – это процесс создания объекта с использованием методов его воспроизведения. Например, стул. Ножки, спинка, гвозди, сиденье — это его комплектующие. Молоток, отвёртка, шуруповёрт — способ сборки. Его материал: дерево, сталь — то, из чего делают комплектующие. Рабочий рубит дерево, а на заводе его обрабатывают, чтобы в магазине вы купили необходимые части для своего стула.
Казалось бы, что сложного может быть в создании стула?
Именно процесс создания и подготовки для дальнейшего воссоздания объекта в жизни заменяет нам технология CAD. В свою очередь, такие же жизненные процессы воплощают в себе CAE и CAM системы. Например, CAE сейчас может заменить привычный для любого инженера расчёт на сопротивление материала, а CAM – прописать последовательность выполнения процессов для создания стула. Именно технология САПР позволяет современным инженерам тратить меньше усилий и выдавать наилучший результат.
Пример использования САПР
Теперь, когда мы разобрались, что такое САПР и какие основные направления входят в него, внедрим немного конкретики, и подробно разберём все нюансы на примере.
В рамках проектной деятельности моего университета я разработал выскодетализированную модель «Коробка перемены передачи» по предложенному техническому заданию заказчика на основе патента. Начнём поэтапно.
Проектная деятельность – это отдельное направление, которое присутствует на каждом факультете вуза. Можно выбрать как тематику своего направления, так и вовсе изменить направление. Здесь важно понимать, что в 45% случаев при ведении успешной проектной работы эта тематика используется на защите диплома. Признаюсь, я не стал искать в себе что-то новое, а, наоборот, решил подкрепить уже полученные знания и выбрал своё направление.
На проектной деятельности я контролирую выполнение проектирования объектной модели «отдела моделирования», а также сам попутно принимаю участие в создании 3D визуализации изобретений.
Итак, вернёмся к модели.
По описанию патента и прилежащим эскизом (Рис. 1) была разработана модель (Рис. 2). Работа осуществлялась в программе Autodesk Inventor. При помощи CAD программы получилось не только воссоздать реалистичную модель изобретения, но также внедрить ряд полезных функций, а именно — модель полностью параметризированная. Это значит, что если изобретение пойдёт на эксплуатацию, то будет весьма просто автоматически подобрать просчитанные размеры.
Рисунок 1 - Эскиз изобретения Рисунок 2 - 3D модель "Коробка перемены передач"
Также в рамках данного изобретения была внедрена BIM технология. Давайте разберём, что это такое.
Технология BIM
BIM (Building Informational Modeling) — информационное моделирование зданий (термин 1992 года). Но причём здесь здания, когда мы говорим о механизмах и возможности визуализации их с применением САПР-систем?
Джон Месснер, профессор PennState говорил: «Через десять лет термин BIM исчезнет из употребления, поскольку информационное моделирование станет обычной работой со зданиями».
Важно выделить из цитаты профессора, что ключевое понятие в BIM — это информационное моделирование.
Моё видение такое: BIM — это информационная модель объекта с использованием цифровых данных. Какую ценную информацию мы можем внести в 3D модель. К примеру: вес, материал, стоимость изделия, расчёты, чертежи, визуализация работы механизма и многое другое.
Внедрение BIM
Отдельным вопросом стоит рассмотреть, как внедрить данную технологию в проект.
Внедрение в моём проекте происходило следующим образом: поскольку это должна быть атрибутивная информация, я задал параметры каждому элементу механизма, основные из которых: вес, материал, вычисления прочности, и вычисление стоимости конкретной детали по усреднённым значениям на рынке. Добавил чертежи и визуализацию принципа работы оборудования.
Итогом проекта стал полный пакет информационной модели. Теперь это не только твёрдое тело, но это и носитель информации — он позволяет изобретателю увидеть все параметры, чтобы воссоздать механизм вживую.
Проект получился весьма неплохим, поэтому мне предложили презентовать его на ежегодной студенческой научной конференции. Рассказывать сильно не о чем, примерная выдержка содержится выше, но а итогом стало почётное второе место с разрывом в 0.01 балла.
И конечно, я не мог оставить вас без интерактивной части. Давайте посмотрим на принцип работы механизма по предложенному описанию из патента.
Итоги
Я постарался наглядно показать и рассказать простым языком, что такое САПР, и BIM технологии, и для чего они нужны. Также на примере разработанной модели КПП мы посмотрели, какую актуальность играет CAD и BIM в сегодняшнее время.
Так нужно ли внедрять САПР и BIM технологии при проектировании механизмов? Однозначно, да. Это не просто технология визуализации параметров — это процесс контроля качества изобретения с использованием информационной цифровой модели, который позволяет устранить все ошибки на этапе разработке до начала эксплуатации изделия.
В заключении хотелось бы сказать, что время течёт словно река, а мы лишь следуем его течению.
С вами был Николай и компания BIMeister, оставляйте свои мысли по поводу статьи в комментариях. Пишите, на какие темы вам бы хотелось поговорить в уютном уголке Habr.
P.S. В следующем блоге, мы поговорим на тему актуальности IT образования и внедрения программирования при проектировании.
Продолжая публикацию по результатам “треугольного стола”, посвященного системам-конструкторам (трансформерам), во второй части мы углубляемся в технологические особенности продуктов этой категории, которые, по сути дела, являются их основным козырем. Свой взгляд на архитектурные и технологические характеристики конструкторов с точки зрения их потребительских качеств высказывает “экспертно-аналитический угол” нашего стола в лице представителей корпорации “МетаСинтез”.
В целом же позиционирование систем-конструкторов мы планируем рассмотреть в трех традиционных разрезах: технологическом, функциональном (прикладном) и ценовом.
Елена Монахова
На “треугольном столе” разгорелись бурные дебаты по поводу того, какие программные продукты считать конструкторами, а какие нет. Приводились самые разнообразные критерии отбора, было высказано много дельных замечаний, но к единому мнению присутствующие так и не пришли. Спор пришлось прекратить командно-административными мерами, так как продолжительность встречи была все же ограничена.
Как заметил один из участников семинара: “Если мы дадим точное определение, что такое конструктор, чем он отличается от неконструкторов, какие у него технологические особенности, позиционирование и пр., то на этом мы исчерпаем повестку дня”.
Чтобы не сваливать все в одну кучу, попробуем временно исключить из рассмотрения такие элементы определения, данного в предыдущей публикации, как “системы, предназначенные для создания финансово-экономических приложений” или “системы, рассчитанные на средний бизнес”, и ограничимся собственно “конструкторской” составляющей.
С технологической (архитектурной) точки зрения конструктор - это программный продукт, включающий:
2 ядро, в котором определена принципиальная модель предметной области, а также базовый набор классов (максимально абстрактных) и основных методов работы с ними;
2 конфигурацию (для общности назовем это так), которая представляет собой реализацию информационной системы, построенной из классов и методов ядра;
2 инструментарий, позволяющий пользователю строить свой собственный вариант конфигурации.
По сути дела, первыми конструкторами можно назвать такие системы программирования, как FoxBase или MS Access, однако их ядро не содержит модели предметной области. Данные системы являются универсальными и пригодны для создания практически любых программных продуктов, но они требуют высокого уровня подготовки разработчиков и значительных затрат времени. Нас же интересуют такие конструкторы, в которых часть работы уже выполнена: модель задана, основные понятия определены, схема построения известна. Все это плюс наличие базовой конфигурации и необходимых инструментов для внесения изменений позволяет существенно сократить расходы на внедрение автоматизированной системы (как финансовые, так и временные).
Сделаю сам, но отвечать будем вместе!
Обращаясь к потребительским свойствам конструкторов, попробуем вкратце обрисовать область их применения.
Требования рынка сегодня звучат примерно так. Клиенты желают сокращать сроки создания, внедрения и, что особенно важно, внесения изменений в сложные ИС, предназначенные для управления деятельностью предприятий. Это диктуется необходимостью адаптации систем управления к непрерывно меняющемуся объекту управления и его системному окружению.
С другой стороны, клиентов волнует качество получаемых систем, под которым понимается адекватность управляемым процессам, надежность, внутренняя непротиворечивость, интегрированность данных, соответствие современному техническому уровню, быстродействие и другие параметры.
Понятно, что создавать системы, соответствующие всем перечисленным требованиям, очень сложно, а на уровне пользователей - практически невозможно. Эта сложность проявляется в увеличении размеров программ и расширении функциональности систем, в множественности участвующих субъектов управления, усложнении связности, в проблемах поддержания понятийной целостности и т. д.
Поиск подхода, который позволил бы совместить достаточно высокую скорость создания ИС и внесения изменений в нее с разумными экономическими затратами, собственно, и привел программистское сообщество к разработке систем-конструкторов, занявших (или стремящихся занять) особое место среди систем других категорий. Отсюда и вытекают их специфические потребительские свойства.
Лев Тришанков, исполнительный директор “Алеф Консалтинг & Софт”: +Мне кажется, что мы сейчас живем в мире, где крупносерийные производства во всех областях постепенно исчезают.
Поэтому сегодня, во-первых, любой продукт должен быстро создаваться и выводиться на рынок, и, во-вторых, необходимы какие-то уникальные конфигурации этого продукта, лучше отвечающие потребностям небольших групп или отдельных покупателей.
Мы здесь говорим как раз о существовании подобной возможности в сфере информационных технологий: нужно создавать программные продукты, быстро выводимые на рынок и кастомизируемые с разумными экономическими затратами для конкретных покупателей или каких-то отдельных небольших групп, отраслей и т. д.
При этом надо принять во внимание, что жизненный цикл такого продукта не год, а десять и более лет. Это не ботинки, которые снашиваются за сезон, и не автомобиль, который меняют каждые 3-5 лет. Эти системы живут десятки лет, и их смена очень болезненна.
Что дает пользователю такая модифицируемость (несвойственная ни заказным, ни коробочным, жестко заданным программным продуктам)? Она позволяет создавать уникальные системы, наиболее эффективные для решения задач конкретного пользователя. А такие задачи найдутся у каждой организации, какой бы типовой она ни была.
Потребительское свойство № 1. Возможность решения специфических для пользователя задач управления, возможность выразить средствами системы-конструктора узкоспециализированность и уникальность.
Елена Дворникова, руководитель отдела продвижения ИС фирмы “Цефей”: +У нас были случаи, когда клиент при помощи нашей системы, точнее её инструментария решал задачу, абсолютно не относящуюся к экономике. Например, с нуля и практически не из наших базовых классов была создана система для учета ядерного топлива+
Алексей Харитонов, руководитель отдела продвижения экономических программ “1С”: Ранее много обсуждалось, какие системы автоматизации больше нужны пользователю - готовые решения или инструментальные пакеты. Сейчас очевидно, что нашему пользователю нужно то и другое “в одном флаконе”: современные программы продолжают развиваться и как комплекс решений для автоматизации бизнеса с глубоко проработанной методологией, и одновременно как гибкий инструмент, позволяющий перестроить эти решения в соответствии с нуждами конкретного предприятия - новыми идеями его генерального директора или старыми привычками его главного бухгалтера.
Понятно, что уникальность ИС достигается и просто разработкой системы на заказ. При чем же здесь конструкторы?
Важной особенностью решений, построенных на основе систем-конструкторов, является тот факт, что желаемую уникальность в них можно поддерживать непрерывно в соответствии с динамикой развития предприятия или организации. “Жесткие” коробочные программные продукты не могут плавно справляться с этой задачей, а вынуждены решать проблему изменчивости скачками - при выпуске новых версий, в том ритме, который задает сам разработчик. Причем эти версии опять же имеют вид типовых, а не уникальных.
Так как инструменты для модификации ИС в системах-конструкторах в большинстве случаев поставляются совместно с прикладным решением (а иногда и продаются отдельно), то непрерывное модифицирование (усовершенствование, развитие системы) становится доступно конечному пользователю. Эта характеристика систем-конструкторов составляет второе их потребительское свойство.
Потребительское свойство № 2. Адаптируемость во времени, возможность непрерывного внесения изменений в систему (доработки, настройки на специфические и уникальные задачи управления).
Непрерывное внесение изменений в систему дорогого стоит для конечных потребителей в прямом смысле этого слова, если эти изменения осуществляет фирма - разработчик программного продукта или даже их партнеры (хотя, возможно, они это могут сделать более профессионально и системно, чем пользователь). Даже незначительные модификации системы (например, добавление одной новой независимой задачи управления) обходятся конечному пользователю в тысячи долларов, а внесение изменений со сложной взаимосвязью с другими задачами управления исчисляется десятками тысяч долларов. Конечно, таких средств нет у малых, а часто и у средних фирм.
Разработчики систем-конструкторов решают эту проблему “отчуждением” программного продукта от себя. Таким образом, с одной стороны, за адаптацию системы теперь отвечает сам потребитель. С другой - он получает “во всевластие” полный набор инструментария для модификации системы и при наличии у фирмы-заказчика квалифицированных кадров может самостоятельно дорабатывать ее под свои специфические нужды (что существенно дешевле).
Эта особенность (если она действительно реализована) - отчуждаемость и переносимость конфигурации конструкторов - одно из самых главных отличий подобных систем.
Потребительское свойство № 3. Возможность внесения изменений в систему собственными силами потребителя для ее адаптации к специфическим и уникальным задачам управления.
Из дискуссии: “Даже если ему [пользователю] выполняет внедрение системы кто-то со стороны, то он уверен, что у него остается инструмент. . Естественно, какой-то партнер может уйти, но придут другие. И система может быть передана”.
Рассмотрим технологический аспект реализации этого свойства.
Вопрос: какие изменения в системе разработчик может разрешить пользователю и стоит ли разрешать вносить изменения в ядро? Тут мнения разработчиков сильно различаются. Одни - однозначно против, другие более лояльны, но ответственность за внесенные изменения четко разделяют с клиентом.
У первых ядро - это святая святых. Это исполняемый модуль, исходные тексты которого недоступны для конечного пользователя (“1С”, “Алеф”).
В Navision Axapta в ядро тоже залезать нельзя, все изменения конфигурации системы и индивидуальные настройки хранятся в отдельном пользовательском слое.
Другие разработчики предоставляют пользователям полную свободу действий, передавая им (если нужно) все исходные тексты (“ИнтелГрупп”). Третьи подходят гибко: что разрешается, а что запрещается изменять, определяется условиями договора (“Цефей”).
Фирма “Цефей” в большинстве случаев не позволяет конечным пользователям изменять структуру таблиц базы данных, мотивируя это тем, что неквалифицированное вмешательство пользователя может в отдельных случаях разрушить базу. (На наш взгляд, более предпочтительным выглядит вариант неизменного ядра, позволяющий серьезно снизить риск фатальных сбоев при работе системы).
Хочется снова вернуться к вопросу о том, какая же система является конструктором (в нашем смысле этого слова), а какая нет.
Несколько слов о системе Navision Axapta: можно ли ее отнести к конструкторам? (Напомним, что на “треугольном столе” эта система присутствовала условно.) В ней реализованы достаточно богатые возможности по перенастройке и разнообразный встроенный инструментарий, конфигурация состоит из 16 слоев бизнес- и системной логики, имеется возможность переноса конфигурации с компьютера на компьютер как целиком, так и послойно. Так что по архитектурно-технологическим свойствам система Navision Axapta действительно очень близка к конструкторам. Ее отличия от прочих рассматриваемых в этом обзоре систем, разработанных отечественными программистами, лежат в другой плоскости - у нее более развитая функциональность и соответственно более высокая цена решения. Но об этом пойдет речь в других частях нашего обзора.
Не секрет, что современные западные крупные (для простоты назовем их так) информационные системы (например, Oracle Applications или SAP R/3) обладают значительными возможностями по перенастройке и созданию дополнительной функциональности, а также развитым инструментарием по разработке и внесению этих изменений. Может быть, они тоже являются конструкторами?
Для того чтобы внести существенные изменения в функциональность крупных ИС, от пользователя требуется весьма высокий уровень подготовки, в то время как для модификации конфигурации конструкторов достаточно минимума знаний и навыков.
Изменение функциональности крупных систем и создание новых типовых решений - в основном прерогатива самих разработчиков или их представительств. Изменением же конфигурации конструкторов занимается огромный круг людей. Даже если не брать в рассмотрение конечных пользователей, которые просто перенастраивают систему под свои нужды, то впечатляет количество партнеров фирмы “1С” (типовых решений, ими созданных, - более 200!).
Чтобы добиться простоты внесения изменений собственными силами, создатели программных продуктов должны разработать и реализовать очень гибкий, но одновременно высокотехнологичный индустриальный подход к проектированию, построению и обновлению ИС.
Этот вопрос является основополагающим в дальнейшем развитии всех ИС, в том числе систем-конструкторов. И упирается он в разработку простой, но обладающей мощными выразительными способностями технологии проектирования, создания и обновления информационных систем.
В настоящий момент в мире подобная технология в полной мере не разработана, и над этой проблемой несколько десятилетий бьются лучшие аналитики, системщики, концептуалисты.
Участники “треугольного стола”
Угол № 1 (от имени “предложения”):
Угол № 2 (от имени “спроса”):
Лумпов Николай Алексеевич, аналитик московской торговой компании “Консул”.
Угол № 3 (от имени “независимого и немного критичного взгляда”), СМИ и эксперты:
- Елена Монахова, зам. гл. редактора PC Week/RE;
- представители научно-консалтинговой корпорации “МетаСинтез”:
Наталья Никитина, генеральный директор, канд. тех. наук;
Юрий Юдкин, руководитель Центра развития ИТ;
Юлия Гараева, консультант-аналитик в области ИТ;
- Сергей Брускин, руководитель Департамента управленческого консалтинга компании Robertson & Blums.
Читайте также: