Ferdinand Wagner
Ruedi Schmuki
Thomas Wagner
Peter Wolstenholme
Modeling Software with Finite State Machines A Practical Approach. 2006
Перевод
Возможность тестирования строк кода создаёт иллюзию лёгкости программирования.
Создание синтаксически правильных строк кода не означает, что мы пишем что-то разумное.
Конечный автомат математически подходит для реализации самой важной, но хрупкой части ПО - поведения.
Поведение - самая сложная часть программного обеспечения и источник большинства непонятных ошибок.
Понимание проблем системы управления есть источник вдохновения.
Устоявшаяся практика использования спецификации в качестве основы
для кодирования неверна.
Эффект языка C можно описать замечанием:
“услышав о крупной программной катастрофе, я могу быть уверен, что она была написана на C.”
В юности обучились многим глупостям, но, части удалось переобучиться.
Языки, определенные на прочной теоретической основе, не получали широкого признания.
Большинство языков программирования не очень хорошо “масштабируются”. Их легко использовать для написания небольших автономных программ, но для реальных проектов сделать конечный код понятным во всей полноте практически невозможно.
Нет общего понимания или соглашения относительно программных методов. Если бы они существовали, человеку без каких-либо знаний о программных
методах было бы запрещено кодировать.
Нанять специалиста в прикладной области и позволить специалисту
учиться программированию на практике или взять настоящего программиста и попытаться научить программиста решению прикладной проблемы во время программирования?
Очевидный ответ — создать команду, состоящую как из прикладных
специалистов, так и из настоящих программистов, — во многих случаях трудно достичь.
Трудности в определении навыков, требуемых от программиста, приводят к
чрезвычайно широкому диапазону эффективности работы программиста, а также качества создаваемого кода.
Много людей, которые программируют, никогда не посещая курсов информатики, действительно ли образование помогает индустрии программного обеспечения?
Сравним разработку компьютерного оборудования и программного обеспечения.
Это два совершенно разных мира, хотя они относятся к одному и тому же продукту; это две грани одного и того же продукта.
Производство электронного оборудования - это хорошо организованный
и спланированный процесс. Аппаратное обеспечение создается на бумаге (фактически в CAD—программах): электрические схемы, макеты, моделирование, проверка - несколько шагов, на которых создается весь проект аппаратного обеспечения.
Только когда оборудование полностью спроектировано (другими словами, полностью определено), можно приступать к производству.
В отличие от этого, разработка программного обеспечения не требует какого—либо этапа проектирования или спецификации - мы можем
начать производство (кодирование), имея очень смутное представление о
приложении.
Причина отношения заказчиков к их требованиям, как и у программистов:
заказчики знают, что их не заставляют предоставлять точную
спецификацию, поэтому они "экономят".
Закон разработчиков программного обеспечения и заказчиков:
Выбирай путь кажущегося удобства.
Инструменты CASE
(автоматизированной разработки программного обеспечения) ровесники индустрии программного обеспечения.
В рамках этой очень широкой темы были разработаны тысячи методов и инструментов для любой мыслимой программной деятельности.
Причинами негативного отношения к CASE tools является то, что ожидаемые преимущества (формальной) спецификации, такие как проверка на логические ошибки и согласованность всей спецификации,
не могут быть реализованы.
Генерация кода оказалась недоразумением.
UML
вместо синтеза многолетнего опыта, объединили несколько не совсем совместимых концепции и обозначения, создав монстра, якобы, где-то, полезного.
Основная проблема любого CASE-инструмента заключается в том, что они не являются полноценным языком программирования.
Следовательно, они позволяют реализовать только часть работы по разработке (спецификация, моделирование).