что такое инженерная модель

Инженерное 3D-моделирование: в чем его суть?

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

3D моделирование: основные области применения

Технология используется в следующих сферах:

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

Инженерное 3D моделирование: в чем отличия от трехмерной графики?

Основная разница касается финального результата. Если говорить о трехмерной графике, то результат – двухмерная картинка, анимация или рендеринг объемного объекта. Инженерное моделирование же направлено на получение технического документа, файла, содержащего информацию, необходимую при создании реального воплощения проекта.

Что можно получить с помощью 3D моделирования?

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

3D моделирование в ювелирном деле

Все тонкости процесса можно наглядно продемонстрировать на примере ювелирного производства. Моделирование представлено следующими видами:

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

Источник

Вопрос 1. Инженерная, патерналистская, коллегиальная и контрактная модели врачевания

Модель взаимоотношений работников здравоохранения и пациентов— наиболее общая схема конкретного общественного отношения, в кото­рой отражаются основные исходные положения субъектов отношения, определяющие форму и содержание взаимодействия между ними. Американский философ Р. Витч выделил 4 основные модели: инже­нерную, пасторскую (патерналистскую), коллегиальную и контрактную (договорную). По своему моральному значению эти модели представ­ляют собой иерархию возрастания этических ценностей от наименее морально обоснованной — инженерной к наиболее обоснованной — контрактной.

Инженерная модель, ее еще называют технологической моделью и моделью автомеханика, характеризуется отношением врача к пациен­ту как безличностному организму, в котором возник очаг патологии. В медицине, в рамках этой модели, используется такое понятие, как «отклонение физиологического механизма от положения равновесия», и врач стремится восстановить это равновесие. Показателями служат объективные параметры биохимии, физиологии, клинических исследо­ваний. Все это прикладное научное знание, которым не владеет паци­ент. Именно поэтому его личное мнение о собственном благе в смысле здоровья с точки зрения медика-профессионала не только бесполезно, но и может быть вредно. Выбор же врача, основанный на объективных данных, признается естественным и благотворным для пациента. Такие убеждения среди медиков традиционно воспринимаются каждым новым поколением врачей, но современная философия науки опровергает это устаревшее представление о природе научного знания. Наука отнюдь не нейтральна. Так называемое объективное знание как бы нагружено субъективными предпосылками, т.е. отражает личные и групповые интересы, искажается ошибками субъективного характера. Это подтверждается историей науки нового времени. Абсолютизация объективного знания ведет к технократизму (абсолютизации технологии) в медицине, который морально ущербен, поскольку входит в резкое противоречие с известным принципом уважения автономии пациента.При инженерной модели врач не проявляет должной заботы о своем пациенте после медицинского вмешательства, поскольку весь акцент смещен только в технологическую сторону самого медицинского вмешательства. Однако такая аморальность отношения врача не всегда может быть признана единственной причиной ущемления личности пациента. В целом ряде ситуаций современной медицины пациент объективно не может в полной мере выступить в качестве личности. Значительное число специалистов занято выполнением сугубо специализированных процедур и исследований, строго привязанных к частям тела человека. Практически здесь исключается личное общение с пациентом. Приме­ром может послужить работа рентгенолога с изображением частей тела на экране, а затем со снимком этого изображения (описанием его и ана­лизом). Такую и подобные ситуации (работа врача-лаборанта с материа­лом, взятым для анализа) обозначают термином «деперсонализация» (от лат. «личность»). Деперсонализация — это дистанцирование врача от личности пациента. Можно ли себя успокаивать тем, что это вынужденная мера? Нет, нельзя. Необходимо персонализировать рабо­ту с пациентом так, чтобы он вновь почувствовал себя личностью.

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

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

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

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

Модели взаимоотношений можно классифицировать также по типу взаимоотношений между врачом и пациентом: монологичному или ди­алогичному взаимодействию. Монологичной считают такую модель, в которой общение между врачом и пациентом выстраивается как моно­лог специалиста с невежественным слушателем. Диалогичной считается такая модель, когда взаимодействие врача и пациента разворачивается как диалог равноправных партнеров, обсуждающих общую проблему. Коллегиальная модель приближается к диалогичной. Подлинный диалог возможен, если врач и пациент в равной степени причастны к ис­тине, хотя и при разном ее понимании. Если истинным считать только естественно-научное знание, то им обладает врач, а у пациента не будет никакой своей истины. Так ли это? Однако в чем заключается природа специфического знания пациента, есть ли у него основание иметь право на контроль в ситуациях врачевания, право на диалог с врачом? Это вы­ясняется при рассмотрении понятий о здоровье и заболеваниях челове­ка с точки зрения пациента.В некоторых случаях коллегиальную модель рассматривают сквозь призму солидарной ответственности за здоровье пациентов нескольких врачей.

Под контрактной модельювзаимоотношений между медиками и пациентами подразумевают, во-первых, отношения, построенные на взаимном уважении и доверии, и лишь во-вторых — формальную сто­рону таких отношений, а именно договор с пациентом, контракт, со­глашение. При этом моральная сторона отношений пациента и врача в тексте договора отражена не прямо, а косвенно. Очевидно, что при претворении в жизнь данной модели успехом у пациентов пользуются врачи, сочетающие высокий профессионализм и личностные качества, соответствующие ценностным ориентациям врача на основе принципов и норм биоэтики. Эта модель отношений пациента с врачом аналогич­на модели отношений граждан с выборной властью, которые в совре­менном обществе строятся на договорной основе, впрочем, так же как и моделям трудовых, семейных отношений — словом, любых отноше­ний между гражданами, которые требуют юридического оформления. По мнению Р. Витча, именно эта модель в наибольшей степени защищает моральные ценности автономной личности, ибо для реализации контрактных отношений существенно важны моральные принципы свободы, сохранения достоинства, правдивости, справедливости. Кон­трактная модель позволяет избежать ущемлений свободы, характерных для инженерной и патерналистской модели, с одной стороны, а с другой — она не позволяет пациенту строить иллюзии относительно своего соучастия в лечении в качестве коллеги врача. Пациент добровольно устанавливает отношения с врачом на тех условиях, которые считает для себя выгодными и приемлемыми. Если условия не соблюдаются, паци­ент вправе считать для себя договор недействительным, лишить врача тех полномочий, которыми он его наделил.

Источник

Модели общения врача и пациента

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

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

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

Инженерная модель

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

Плюсы: скорость приёма, и, по мнению некоторых медиков, при такой модели вероятность врачебной ошибки ниже.

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

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

Патерналистская модель

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

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

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

Минусы: Врачам может мешать инициатива пациентов, если они не умеют с ней работать и строить диалог так, чтобы не обесценить мнение пациента. Знание пациента мешает, тем более что чаще всего это знание не совпадает с их точкой зрения. Обычно, когда пациент рассказывает: «Я вот прочитал то-то», — врач думает: «Лечитесь сами, если читали».

Коллегиальная модель

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

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

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

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

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

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

Контрактная модель

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

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

Источник

Роль компьютерного инженерного моделирования в инновационной деятельности

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

Термин «инновация» в наше время употребляется все чаще и чаще. В апреле 2014 года сотрудниками издания «Harvard Business Review» (выпуск 92, № 4) при помощи инструмента «Google’s Ngram Viewer» была предпринята попытка проследить частоту употребления известных деловых терминов в книгах, опубликованных за прошлое столетие. Они исходили из следующей предпосылки: язык является отражением человеческой культуры, и соответственно, используемые фразы отражают меняющиеся приоритеты. В данном исследовании было показано, что частота употребления слова «инновации» увеличилась более чем в 5 раз за рассмотренный период – гораздо больше чем частота употребление слов «менеджмент» или «управление».

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

В 2012 году патентное бюро США получило более 575 000 патентных заявок, то есть в 6 раз больше, чем в 1962 году, и на 60% больше, чем в 2002 году. Таким образом, можно видеть, что инновационная деятельность не просто увеличивается – она стремительно набирает обороты.

Содействие инновационной деятельности

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

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

Экономия времени и средств – не единственное преимущество моделирования. Иногда инновационные события происходят по воле случая. Например, незначительные изменения в ходе тестирования продукта или изменение материала могут дать большие преимущества в использовании. Причины улучшения не всегда могут быть понятны; в ходе испытаний всегда можно ответить на вопрос: «Что случилось?», но не всегда – на вопрос: «Почему?». Для этого инженерам нужно проводить больше испытаний или выполнять моделирование.

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

Начните моделировать рано. Моделируйте часто.

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

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

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

Источник

Инженерный подход к разработке ПО

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

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

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

Часть 1. Инженерный подход к разработке

Что это такое? Покажу на примере возведения моста:

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

В разработке ПО этапы 1 и 2 часто отсутствуют либо очень слабо выражены. Если требования и зафиксированы, то расплывчато, неполно и неформально. Лишь единицы детализируют требования и разрабатывают чёткие спецификации.

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

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

Что такое требования?

Если кратко, требования — это формулирование свойств продукта в терминах предметной области. Например, так: «Все экземпляры программы должны одинаково обрабатывать входные запросы».

В требованиях не используются термины области реализации. Как только в требования просачиваются термины «синхронизация состояний», Raft, Paxos, «логарифмическая сложность по времени» — то начинают смешиваться требования и спецификация.

Важно понимать это и чётко отделять одно от другого.

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

Свойства ПО, которые видит потребитель, оцениваются по метрикам предметной области. Нужно разделять требования и спецификации, чтобы иметь возможность 1) выделить основные метрики продукта, по которым потребитель будет оценивать наше ПО, и 2) ясно понимать, какие свойства продукта важны для пользователя, а какие нет.

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

Классический пример такого несоответствия приведён в разнообразной литературе о разработке пользовательского интерфейса и в статьях (например: System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications, Computer latency: 1977–2017). Разработчики обычно стараются оптимизировать время выполнения операции, например поиска информации в базе данных, а для пользователя важно время отклика системы. И если поиск идёт медленно, но пользователь начинает видеть выдаваемые результаты как можно быстрее, то ему кажется, что такое ПО работает лучше, чем то, которое ищет быстро, но сначала аккумулирует результаты и в конце выдаёт их все.

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

И, наконец, самая важная причина:

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

Об этом хорошо написал Michael Jackson в книге Problem Frames: Analysing & Structuring Software Development Problems. На мой взгляд, это одна из самых полезных книг для разработчиков ПО. Она учит в первую очередь анализировать проблемы пользователей, которые и должно решать хорошее ПО. Супербыстрая программа, которая потребляет мало ресурсов системы, но не решает задач пользователей, — это плохая программа. Крутая, но плохая.

Что есть спецификация?

Спецификация — это формулирование свойств ПО в терминах области разработки ПО. Вот тут появляются понятия сложности, синхронизации и т. д.

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

Особенно стоить отметить пользу и важность спецификаций на протоколы и интерфейсы между компонентами системы, что позволит избежать вот таких ситуаций:

В чём отличие от обычного подхода к разработке?

При инженерном подходе мы заранее проектируем ПО с требуемыми характеристиками в соответствии со спецификациями. Спецификации проверяем на нужные свойства, которые идут из требований.

Я сделал сравнение в виде таблички (весьма субъективной):

А не за водопадную ли модель разработки тут идёт агитация?

Инженерия ПО, включая даже формальные спеки и моделирования, отлично сочетается с agile-подходом.

Есть мнение, что инженерный подход к разработке несовместим с быстрой итерационной разработкой ПО (так утверждается во многих статьях, вот пример).

Но это не так. Инженерный подход с успехом применяется во многих проектах, в том числе в проектах с короткими итерациями.

Раньше из-за слабо развитых средств и инструментов поддержки инженерный подход действительно был тесно связан с водопадной моделью.

Но сейчас всё кардинально поменялось.

Благодаря прорывным успехам в области моделирования, SAT/SMT-солверов и др. теперь можно быстро проверять огромные пространства состояний системы на наличие нужных нам свойств и отсутствие ненужных, верифицировать промышленные объёмы кода и т. д.

Появились первоклассные промышленные инструменты типа Alloy, TLA+/TLC, Atelier B, PRISM, которые перевели задачу формализации и проверки спецификаций из академической/математической, требующей высокой квалификации и огромных усилий, в задачу push-button, доступную большинству программистов.

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

Требования легко уточнять итеративно, особенно с современными подходами и инструментами.
И уточнение требований, спецификаций, рефакторинг моделей, написание кода и его рефакторинг легко могут идти параллельно — в рамках одной итерации.

В общем, инженерный подход сейчас совсем не равен водопадной модели, это уже две независимые вещи.

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

В блоге Hillel Wayne показано, как просто работать с формальными спецификациями и моделями. У него есть отличный пример, как за 10 минут формально специфицировать логику пользовательского интерфейса программы и проверить некоторые её свойства.

Не буду вдаваться в детали и переводить статью целиком, просто покажу саму спецификацию на языке Alloy:

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

Свойства для проверки тоже легко задаются:

Спецификация похожа на небольшую программу.

К её разработке, уточнению и рефакторингу можно применять те же подходы, что и к разработке программ на любых языках программирования.

С такими спецификациями можно легко работать в стиле agile.

Зачем нужны такие спецификации и что с ними делать — покажу далее.

Формализация спецификаций

Как вы уже догадались, вышеприведённая спецификация является формальной, так как выполнена в рамках формализма — языка Alloy, который позволяет описывать объекты и взаимосвязи между ними в рамках реляционной логики первого порядка.

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

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

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

Часть 2. Пример использования Alloy

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

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

Представленный подход к обработке данных на основе вычислительных графов применим для широкого класса задач.

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

Отношения

Традиционно в математике бинарным отношением называется множество пар , где и .

Описание отношений и их свойств поместим в отдельный модуль (который очень близок к стандартному util/relation):

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

Графы

Теперь на основе отношений определим основные свойства графов.

Модуль для описания графов близок к стандартному utils/graph, но, в отличие от модуля отношений, в данный модуль вошли только необходимые нам предикаты и функции:

Вычислительный граф

Вычислительный граф — это абстракция, описывающая вычисления в системе в виде графа.

На данном этапе мы рассматриваем в основном топологию.

Теперь опишем вычислительный граф, который удовлетворяет вышеприведённым свойствам, на Alloy:

Посмотрим на пару примеров вычислительных графов:

Примеры графов можно увидеть на следующем рисунке:

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

Подумав над свойствами вычислительных графов по отношению к обрабатываемым данным, мы придём к идее консистентности.

Консистентность вычислительного графа

Под консистентностью тут понимаются свойства графа по отношению к потоку данных, которые обрабатываются в графе.

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

Понятно, что потерять данные можно только после получения. Мы можем классифицировать узлы по возможности потери данных:

Граф консистентен, если в нём не теряются результаты вычислений и все вычислительные процессы конечны, т. е. мы получим результат за конечное время (все вычисления в графе останавливаются за конечное время, и мы можем считать результат из стока).

Консистентности можно достичь, добавив ещё несколько свойств к свойствам вычислительного графа:

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

То есть все узлы, которые являются корнями, кроме истока, это просто неактивные узлы.

И (правда, избыточное, оно следует из других) свойство:

Теперь уточним спецификацию вычислительного графа:

Для экономии времени и места картинки с уточнёнными вычислительными графами приводить не буду.

Операции над вычислительным графом

Для работы с вычислительными графами нам нужны операции.

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

В простейшем случае жизнь графа состоит из шести этапов:

Изменение работающего графа не подразумевается. Сценарий простой и для большинства задач подойдёт. Не надо заботиться о консистентности графа по отношению к данным во время работы: после создания граф валидируется и далее не меняется.

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

Это серьёзно усложняет задачу.

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

Предположим, у нас уже есть валидный и работающий граф.

Сначала подумаем, какие операции нам минимально необходимы:

Новый узел при добавлении очевидно считается неактивным.

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

Соединять узлы мы можем несколькими вариантами:

Первый и последний вариант тривиальны, а второй и третий уже интереснее.

Очевидно, что при подключении неактивного узла к активному ничего плохого не произойдёт: активные узлы безопасны относительно данных, циклов не получится. Ведь в противном случае должна быть дуга к какому-то неактивному узлу, а оттуда — путь к данному неактивному, а это противоречит определению активного/неактивного узла.

Такое подключение будет безопасным, только если:

Опишем операции в виде предикатов над графами, которые связывают граф до и после операции.

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

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

Давайте проверим, что connect сохраняет валидность графа:

Alloy не смог найти контрпример во всём пространстве конфигураций графов с количеством узлов до восьми включительно. Это большое пространство, » 168 primary vars » говорит о том, что оно размером возможных значений основных переменных. И это заняло на среднем ноутбуке меньше 30 секунд!

То есть мы можем быть вполне уверены, что операция connect сохраняет валидность любых вычислительных графов.

Теперь обратная операция, удаление дуги:

Ого! Найдены контрпримеры! Парочку из них можно увидеть на следующем рисунке:

Дуги, помеченные как r1, — это дуги графа до операции disconnect, r2 — после неё. Там, где есть r1, но нет параллельной ей r2, эта r2 и была удалена операцией.

Видно, что причина контрпримеров — это удаление единственной дуги from->to, в случае когда source (он же from) перестаёт быть связанной вершиной графа.

Поправляем операцию disconnect:

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

Полнота операций

У нас есть множество валидных графов, а достаточны ли наши операции для построения любого валидного графа из любого валидного?

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

И вот тут мы получаем:

Мы столкнулись с ограничением Alloy: квантификация может быть только первого порядка либо должна сводиться к первому порядку.

А здесь не получилось сделать сколемизацию квантора «some intermediate…», так как подкванторная переменная должна пробегать по структуре высшего порядка — последовательности графов.

И к первому порядку такую конструкцию не свести.

Иногда (но не так часто, как хотелось бы) можно переформулировать предикат так, чтобы он свёлся к первому порядку.

Хотя уже есть higher-order Alloy, но он пока экспериментальный, квантификация высших порядков у него имеет существенные ограничения по размеру моделей. Она катастрофически замедляет моделирование, так как идёт через CEGIS — counter-example guided inductive synthesis.

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

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

Эта проверка уже работает, и мы видим результат:

Красные дуги — это дуги графа до шага, чёрные пунктирные — после шага. На этом шаге добавляется дуга from->to.

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

Поправляем connect:

Теперь всё нормально.

Точно так же проверяем обратный шаг для операции disconnect. Там тоже будет контрпример, придётся внести правки:

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

Это означает, что, начав с минимального работающего валидного графа (например, source->drain), мы можем дойти до больших валидных графов с помощью операций connect/disconnect и всегда вернуться к начальному графу.

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

Что дальше?

Дальше можно развивать идею в направлении локальности операций, например.

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

То есть хорошо бы разработать операции со свойством локальности: им понадобится знание только об узлах, что участвуют в операции (признаки safe/active и пр.).

При небольших ограничениях на возможные топологии графа эта задача решаема.

Далее, хорошо бы проводить множество параллельных операций над графом одновременно.

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

Либо можно изначально проектировать систему таким образом, чтобы операции были локальные и параллельные.

Ещё хорошо бы ввести типы входных и выходных из узлов данных, чтобы конструировать графы с учётом специфики узлов обработки.

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

А сколько времени ушло на эту модель вычислительного графа?

На написание кода на Alloy и отладку спек ушло не более часа.

Намного больше времени заняли сопровождающий текст и подготовка иллюстраций.

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

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

Как поэкспериментировать с моделями графов?

Установите Alloy Analyzer, скопируйте файлы из репозитория на GitHub — и экспериментируйте.

А что нам даёт описание на Alloy?

Тут всё довольно очевидно:

Заключение

Сейчас разработка серьёзного ПО уже немыслима без грамотного инженерного подхода. Facebook, Google, Microsoft, Amazon уделяют много внимания и сил разработке надёжных систем и ПО.

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

Обычные agile-подходы во многих областях недостаточны для быстрой адаптации к рынку, нужна быстрая адаптация с минимумом ошибок.

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

И тут на помощь придёт инженерный подход.

Во многих областях разработку ПО можно и нужно вести в рамках гибких методологий с применением инженерных методов.

В следующих статьях я собираюсь подробнее рассказать о требованиях и спецификациях, их плюсах, минусах, возможностях и ограничениях, о других весьма полезных инструментах (TLA+/TLC, B-method/Atelier B, Promela/SPIN). Постараюсь сопроводить статьи примерами использования инструментов.

Библиография

Книги для погружения в область

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

Источник