Задания для самопроверки
Проведите самооценивание известной Вам организации-разработчика ПО по ключевым элементам стандарта ISO 9004.
Проанализируйте его результаты и предложите обоснованные рекомендации по улучшению процессов производства ПО в данной организации.
6.Формальные методы в разработке по
Формальные методы в разработке программного обеспечения призваны, с одной стороны, повысить степень его автоматизации, а с другой – гарантировать высокий уровень качества создаваемого программного продукта, который достигается, прежде всего, за счет уменьшения доли «человеческого фактора» в разработке. В идеале создание ПО должно сводиться к заданию его спецификации, из которых автоматизированным образом получается корректный программный код, реализующих данную спецификацию оптимальным образом.
Первым шагом к формализации является создание формальной модели будущего программного продукта, обладающей определенными свойствами, исходя из начальных требований к нему. Как правило, требуется создать не одну модель, а семейство согласованных между собой моделей, описывающих будущий продукт с разной степенью абстракции (levels of abstraction), по мере уточнения требований к продукту и разных точек зрения (points of view) на него. Существенными требованиями к этому семейству моделей является, с одной стороны, их внутренняя непротиворечивость и полнота, а с другой стороны, – представление в форме, доступной для содержательной обработки на ЭВМ и в то же время совершенно понятной разработчику и в достаточной степени заказчику.
Инструменты формализации и верификации
Существует ряд инструментальных средств для представления формализованных моделей программных продуктов, таких как языки моделирования MSC[27], SDL, UML[34], UCM[28], CPN, ASM, c помощью которых можно описать поведение достаточно сложных систем наглядным и, главное, формализованным способом. Некоторые из них позволяют не только исследовать различные свойства таких моделей с помощью других специализированных инструментальных средств, но сгенерировать код на языке программирования (например, С), реализующий данную модель.
Написание моделей является трудной задачей, однако модель, про которую можно доказать, что она непротиворечива и полна, несет огромную ценность, поскольку никакая проверка свойств модели тестированием не может гарантировать ее правильное поведение во всех возможных случаях. Рассмотрим для примера простую классическую задачу о безопасном железнодорожном переезде (Рис. 40).
Рис. 40. Задача о железнодорожном переезде
Имеется железнодорожный переезд, оборудованный датчиками движения поездов и автоматическими шлагбаумами для автотранспорта. Датчики регистрируют вход поезда в критический интервал и выход из него, а шлагбаумы закрывают или открывают движение через переезд для автотранспорта. Задача – обеспечить состояние обоих шлагбаумов «переезд закрыт» всякий раз, когда в критическом интервале находится хотя бы один поезд. Предполагается также, что в критическом интервале не могут находиться одновременно два поезда на одном и том же пути.
Написание соответствующей программы, получающей сигналы от датчиков и управляющей шлагбаумами, уже нетривиально, поскольку тривиальное решение – шлагбаумы всегда закрыты – явно не годится. В реальной ситуации приходится предусматривать ситуации, когда, например, поезд, войдя в критический интервал, затем начал двигаться в обратную сторону, или когда, например, перестали поступать сигналы от датчиков; таких «нестандартных» случаев может оказаться достаточно много и ни один из них не может быть пропущен в реализации программы управления реальным железнодорожным переездом.
Если в данной задаче всего 4-5 требований, то насколько сложнее становится задача формализации, когда исходных требований тысячи и десятки тысяч! На практике для доказательства свойств таких моделей применяются автоматизированные методы дедуктивного вывода (deductive reasoning), методы проверки на модели (model checking) и их различные комбинации с применением эвристических подходов. Общего решения не существует, ввиду очевидной алгоритмической неразрешимости задачи о поиске такого доказательства.
Известно достаточно много инструментальных систем для формализации и исследования подобных моделей, например:
ACL2 – Computational Logic, США
ASCE – Adelard, Соединенное королевство
Atelier B – STERIA Méditerranée, Франция
B-Toolkit – B-Core, Соединенное королевство
BLAST – University of Passau, Германия [21]
CADENCE – CADENCE, США
CADP – VASY, Франция
CBMC – Carnegie-Mellon University, США [24]
CPN Tools – University of Aarhus, Дания [38]
Coq Proof Assistant –INRIA, Франция [31]
Escher – Escher Technologies Ltd., Соединенное королевство
FDR – Formal Systems, Соединенное королевство
Isabelle – University of Cambridge, Соединенное королевство [32]
Kronos – Verimag, Франция
NuSMV – ITC-IRST, Italy [25]
PARAGON-VERSA (ACSR) – University of Pennsylvania, США
ProofPower – ICL, Соединенное королевство
Prover – Prover Technology, Швеция
PVS/DC – SRI International, США
RAISE tools – Terma, Дания
Simplify – HP Labs, США [37]
SPIN – Bells Labs, США [22]
SRDSV – Институт систем информатики им.А.П.Ершова СО РАН, Россия
StateClock – York University, США
SteP – Stanford University, США
Tempura PVS/IT – Newcastle, Соединенное королевство
TRIO – Uni.Namur, Бельгия
UPPAAL – Uppsala, Sweden; Alborg, Дания
Valiosys – Valiosys, Франция
Vampire – University of Manchester, Соединенное королевство [33]
VERISOFT – Bell Labs, США [26]
Zola – Imperial Software Technology, Соединенное королевство
Z3 – Microsoft Research, США [36]
Многие из них, будучи изначально разработаны в академической среде как результат НИР, стали затем программным продуктом, который поддерживается компанией, осуществляющей его дальнейшее развитие и сопровождение уже как коммерческого продукта. В то же время в различных компаниях, разрабатывающих промышленное программное обеспечение, имеются собственные инструментальные средства, как правило, являющиеся их торговыми секретами, в той или иной мере обеспечивающие выполнение задач верификации создаваемого ПО.
Формализация исходных требований проводится вручную, и ее главная проблема – обеспечить адекватность получаемой формальной модели исходным требованиям. Как только формальная модель получена, ее уже можно исследовать и анализировать, применяя различный инструментарий, но все выводы будут относиться не к исходным требованиям, а только к этой модели. Поэтому проблема адекватности – основная для принятия решения о том или ином методе формализации.
Формализация требований полезна даже при отсутствии инструмента для дальнейшей верификации полученной модели, поскольку при передаче требования средствами уже другого языка вскрываются неточности и прямые ошибки, которые иначе остались бы незамеченными до фазы кодирования и, возможно, еще дальше. Существует оценка, что только на этапе ручной формализации находят примерно 30% ошибок в исходных требованиях, что, в соответствии с кривой Боэма (Рис. 2) существенно снижает лишние затраты на создание данного программного продукта.
На сегодняшний день единственным разумным решением этой проблемы является разделение ответственности за адекватную формализацию между разработчиком ПО, эту формализацию осуществляющим, и заказчиком, предлагающим исходные требования для формализации. Язык представления формальной модели должен быть lingua franca (общим языком) этих двух категорий лиц – участников программного проекта. Разумеется, разработчик, осуществляющий формализацию, может не знать всех тонкостей и особенностей той предметной области, для которой разрабатывается ПО; поэтому его интерпретация исходных терминов на языке формализации может быть не той, какую имеет в виду заказчик. Отсюда следует, что язык формализации должен быть понятен заказчику, по крайней мере, в такой степени, что он может принять обоснованное мнение о правильном или неправильном отображении его требований в этом языке формализации.
Первыми языками формализации были различные варианты языка математической логики, единственный недостаток которых – малодоступность широкому кругу заказчиков ПО. Попробуйте, например, объяснить заказчику, что логическая формула:
req Activate40: Forall (a:name, rest) (
~((queuesize(waiting)+queuesize(ready)+1) <= MaxNotSuspended) &
(processor = (Activate a).rest) &
(a in_set suspended) &
(BaseTask(a) |/ ExtendedTask(a))
-> after (Activate a)
(processor = rest)
);
является точной формализацией его требования, что активизация очередной задачи не происходит, если очередь активных задач уже полна! Поэтому большое развитие получили графические языки формализации, некоторые из которых стали промышленными стандартами: MSC[27], SDL, UML, UCM[28].
Например, поведенческое требование при установлении соединения по телефону: «Если набран допустимый номер, то этому номеру посылается вызов, а если номер не допустим, то вызывающий абонент получает сигнал «занято», на языке MSC может быть выражено диаграммой, представленной на Рис. 41.
Рис. 41. Формализация установления соединения между телефонами m и n
Если телефон m находится в состоянии idle (свободен) и его трубку снимают (offhook), то в вызывающем телефоне m появляется гудок (dialtone), после чего он переходит в состояние dial, и с этого телефона происходит набор номера n. Далее возможны два варианта (альтернативы – ALT). Если номер n допустимый (valid), то ему посылается сигнал вызова (ring), после чего аналогичный сигнал посылается вызывающему телефону m, и оба телефона оказываются в отношении установления соединения (ringing). Если же номер n недопустим (~valid), то вызывающему телефону m посылается сигнал «занято» (busy), и он переходит в состоянии занято (busy).
Подобные диаграммы, отображающие другие требования, могут объединяться вместе, создавая точные описания различных сценариев поведения данной системы.