Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

Интерактивные вычисления, управляемые событиями

Управляемые событиями вычисления (event-driven computing) представляют вычислительную модель, в которой приложение находится в состоянии долговременного обмена информацией с конечным пользователем. Выполнение кода осуществляется в ответ на действия и запросы конечного пользователя; задача приложения заключается в обеспечении соответствующей реакции на то, что делает пользователь. В отличие от пакетных приложений интерактивные (диалоговые) приложения не имеют определенного фиксированного периода завершения и продолжают обрабатывать новые события, запускаемые пользователем, до тех пор, пока пользователь не решит прервать рабочий сеанс. Эту модель программирования обычно называют "управляемой событиями", поскольку в результате действий пользователя вырабатываются дискретные события (например, события щелчка мыши, выбора элемента списка или закрытия окна), на которые должно реагировать разрабатываемое приложение. При построении удачного интерактивного приложения, управляемого событиями, очень многое зависит от того, насколько тщательно продумана модель управления состояниями.

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

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

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