Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Трудности временного характера и способы их преодоления
Некоторые из проблем, с которыми приходится сталкиваться разработчикам программного обеспечения, можно с полными основаниями охарактеризовать как "временные трудности". С появлением более совершенных инструментальных средств разработки острота этих проблем может снизиться. Хорошим примером временных трудностей могут служить проблемы отладки. За многие годы был достигнут огромный прогресс в предоставлении разработчикам средств отладки приложений в процессе их выполнения. Это привело к кардинальным изменениям самого процесса отладки, благодаря чему эта ранее трудоемкая задача, которая решалась при помощи столь разнородного инструментария, как карандаш и бумага, низкоуровневые средства наподобие дизассемблеров или отладочная печать, и требовала немалой доли интуиции, в настоящее время превратилась в весьма естественную интерактивную составную часть любого набора современных средств разработки. Среди разработчиков, пользующихся современным инструментарием, сегодня вряд ли найдутся такие, кто считает отладку отдельным видом деятельности, отличным от проектирования и написания кода. Сейчас все это объединено в рамках одного естественного процесса разработки программного обеспечения, и разработчики плавно переключаются с одного вида деятельности на другой. Еще не так давно наблюдалась явно иная картина, и, по крайней мере, в отношении программного обеспечения, выполняющегося на устройствах, об этом можно говорить со всей определенностью. Представляя собой когда-то сложнейшую проблему, отладка кода в наши дни значительно упростилась. То были временные трудности,
Трудности постоянного характера и методологии, привлекаемые для их разрешения
Ко второй категории проблем разработки программного обеспечения относятся те, которые лучше всего описываются выражением "неотъемлемые трудности". Проблемы этого рода уходят корнями в саму сердцевину процесса разработки программ.
Никакими усовершенствованиями инструментальных средства разработки решить эти проблемы невозможно. Скорее, эти проблемы диктуют необходимость применения подходящих методологий, которые могли бы направлять техническую мысль в нужное русло и гарантировать успешное завершение программных проектов, невзирая на трудности.
Неплохим примером ситуаций, которым свойственны неизбежные сложности, является проектирование алгоритмов. Современные объектно-ориентированные языки разработки значительно облегчили инкапсуляцию и организацию кода, но они не в состоянии упростить или автоматизировать собственно проектирование алгоритмов. Несомненно, наличие богатого набора базовых классов, предлагаемых современными программными средами, способствует написанию эффективных алгоритмов, однако проектирование принципиально новых алгоритмов по-прежнему является нелегкой задачей, которая, по всей вероятности, будет оставаться таковой и в ближайшем обозримом будущем. Это имеет место по той простой причине, что алгоритмам, в силу самой их природы, свойственна специфичность, обусловленная конкретикой задачи, и не существует никаких известных общих способов, позволяющих преобразовать ваши намерения в алгоритм, который наилучшим образом соответствовал бы намеченным целям; в подобных случаях автоматизация возможна лишь при условии значительного сужения масштаба задачи и создания специального инструментария для ее решения. То же самое можно сказать и о написании многопоточного кода. Применение усовершенствованных инструментальных средств, языков программирования и библиотек, несомненно, облегчает эту работу и позволяет решать задачи во многих случаях, допускающих строгое описание; вместе с тем, создать универсальную машину, способную разрезáть общие задачи на параллельные ломтики, нам никак не удается. Подобные проблемы являются неизбежными, и их решение требует тщательного проектирования и применения подходящей методологии.
Современные языки программирования и средства графического проектирования позволяют разработчикам полнее реализовывать свои намерения, но не устраняют необходимости в приобретении устойчивых навыков конструирования алгоритмов. Без таких навыков невозможно обойтись при построении критических систем, определяющих поведение и эффективность программного обеспечения. Лучшее, что смогла предложить современная технология программирования, — это упаковка сложных алгоритмов в повторно используемые компоненты и каркасы, и предоставление возможности моделирования взаимодействия компонентов между собой. При таком подходе проектирование критических систем, представляющих общий интерес, могут осуществлять высококлассные специалисты, а остальные разработчики получают возможность повторно использовать эти системы. Проектирование компонентов может быть упрощено, а взаимодействие между авторами компонентов и клиентами сделано более прозрачным за счет применения таких технологий моделирования, как UML (Unified Modeling Language — унифицированный язык моделирования) и панели графического проектирования, но эти технологии не в состоянии снять проблемы внутренней сложности, свойственные процессу проектирования эффективных алгоритмов. Постоянное совершенствование инструментальных средств будет способствовать преодолению временных трудностей, однако трудности постоянного характера, обусловленные самой природой алгоритмов, будут всегда оставаться.
Компоненты находят чрезвычайно широкую применимость, так как позволяют повторно воспользоваться результатами однажды проделанной нелегкой работы, но проектирование алгоритмов от этого нисколько не упрощается. Компонентно-ориентированное проектирование является методологией, возникшей из необходимости помочь программистам справиться с одной из самых неприятных проблем, с которыми приходится сталкиваться при разработке программного обеспечения. В соответствии с этой методологией разработчикам и специалистам в области архитектуры программных систем рекомендуется разбивать свои задачи на раздельные многоуровневые компоненты.
Сначала выделяются критические компоненты и алгоритмы, требующие проектирования, кодирования и тестирования на самом высоком профессиональном уровне. Вся основная функциональность предоставляется разрабатываемым приложениям высокоуровневым и, как правило, менее строго тестируемым кодом, который использует эти компоненты. Причина успеха компонентов как методологии заключается в том, что она дает возможность разложить приложение на отдельные части. Это позволяет инженерам-программистам, специалистам в области архитектуры систем и руководителям идентифицировать наиболее трудные моменты алгоритмизации и сосредоточить на них внимание. Как и в случае любой другой методологии, при разбиении приложения на компоненты необходимо действовать осмотрительно, стараясь не переусердствовать в этом. Если выделять в отдельные компоненты все, что только возможно, исходя из того ложного допущения, что увеличение количества компонент, на которые разбивается проект, приводит к лучшему техническому решению, то в результате этого чрезмерно усложнятся интерфейсы между многочисленными компонентами различно] о рода. Средства моделирования могут оказать вам помощь в визуализации этих взаимодействий, но от сложной картины вам все равно не избавиться. Чрезмерное обилие необязательных компонентов размывает тот острый фокус, который, в соответствии с самим ее назначением, должна обеспечивать разбивка на компоненты для достижения высоких эксплуатационных характеристик критических элементов. Любая методология должна применяться осмотрительно и с отчетливым пониманием тех целей, которые при этом преследуются. Методология полезна лишь тогда, когда можно измерить ее эффективность при решении данной задачи, ибо только в этом случае вы будете уверены в том, что реализуются все ее преимущества.
Двумя областями, в которых использование компонентов предлагает эффективные способы решения сложных задач и значительно упрощает работу с этими технологиями, являются XML и криптография.
Синтаксический анализ XML-выражений является примером непростой технической задачи, для решения которой очень хорошо подходит методология повторного использования компонентов. Число разработчиков, самостоятельно создающих собственные XML-анализаторы для своих приложений, весьма невелико лишь по той простой причине, что спроектировать и реализовать высокопроизводительный XML-анализатор, отличающийся высокой степенью надежности и универсальностью, очень нелегко. Если бы все те, кому необходимо использовать в своих приложениях XML, должны были создавать собственные XML-анализаторы, то последние страдали бы всевозможными мелкими огрехами и неувязками. Это нанесло бы непоправимый ущерб самой возможности организации взаимодействия между различными платформами, лежащей в основе XML. Исключая случаи чисто академических упражнений в проектировании алгоритмов (а XML предоставляет для этого действительно благодатную почву), написание собственного XML-анализатора было бы глупой затеей; вам никогда не удастся выполнить эту работу так же хорошо, как ее могут сделать те люди, перед которыми поставлена единственная задача: написать и протестировать такой анализатор. Вместо того чтобы заставлять каждого разработчика программного обеспечения тратить время на написание собственных специальных программ синтаксического разбора XML-выражений, методология проектирования,
Другим замечательным примером применения методологии повторного использования компонентов, где она оказывается более эффективной по сравнению с пользовательскими вариантами реализации, может служить криптография. Проектирование криптографических алгоритмов является своего рода сложным искусством. Вступая в определенное противоречие с ярко выраженным аспектом своей специфичности, криптографические функциональные средства с каждым днем приобретают все большее значение для разработчиков, создающих самые рядовые приложения. Давно доказано — лучшим способом создания незащищенного приложения является написание собственных криптографических алгоритмов. Если только вашей целью не является проведение исследований в области криптографии, то вы должны знать, что устоявшаяся инженерная практика программирования категорически рекомендует не заниматься созданием собственных криптографических систем. Проектирование, реализация и сопровождение криптографической системы, отвечающей требованиям надежности, живучести и быстродействия, — работа не из легких. Было бы крайне неразумно и чревато многими отрицательными последствиями, если бы все, кто нуждается в функциональных средствах криптографии, самостоятельно создавали криптографические системы для своих приложений. Итак, здесь мы также сталкиваемся с неизбежными проблемами проектирования алгоритма, решение которых более совершенные инструменты облегчить для нас не в состоянии. Но вместо того, чтобы поднимать руки вверх, признавая свое поражение: "Да, это действительно трудная задача, и с этим ничего не поделаешь", следует обратиться к методологии программных разработок, основанной на разбиении сложных алгоритмических задач общего характера на отдельные компоненты, а также к методологии, в соответствии с которой все участники рабочей группы должны следовать согласованному подходу, основанному на использовании компонентов.
Дополнительным преимуществом методологии, предполагающей использование готовых, берущихся "прямо с полки" компонент для решения проблем подобного рода, является снижение затрат на сопровождение программных продуктов. При обнаружении каких-либо изъянов в компонентах (а таковые всегда найдутся) они корректируются централизованным образом, а не по отдельности для каждого из многочисленных разрозненных вариантов реализации.
Любой достаточно сложный проект по разработке мобильного программного обеспечения нуждается в хорошем наборе методологий, способных справляться со свойственными данному виду разработки трудностями постоянного характера. Должен существовать процесс, позволяющий определять трудные проблемы и убеждаться в том, что они решаются наиболее подходящим для этого способом. Технология компонентов позволяет справиться с одним специфическим типом проблем разработки программного обеспечения. Однако для решения других проблем, например, тех, которые связаны с обеспечением необходимой производительности приложений, проектированием эффективных пользовательских интерфейсов или созданием надежных каналов связи для мобильных устройств, потребуются дополнительные методологии. Умение распознавать проблемы постоянного характера и знание способов их преодоления является отличительным признаком хорошего руководителя группы разработчиков.
Итак, существуют проблемы, в разрешении которых нам могут помочь инструментальные средства, и по мере совершенствования доступного инструментария эти проблемы будут год от года терять свою остроту. Наряду с этими проблемами временного характера существуют проблемы постоянного характера, которые могут решаться лишь на основе применения правильных технических подходов. Это возможно лишь при наличии методологии, гарантирующей, что наиболее важные проблемы будут решаться не от случая к случаю, а на основе их всестороннего и глубокого рассмотрения, как они того заслуживают.
Каждый успешный этап развития вычислительных средств характеризовался своими специфическими проблемами и соответствующими методологиями, позволяющими добиваться успеха. Эти методологии базировались и продолжают базироваться как на самых современных из имеющихся инструментальных средствах разработки, так и на специфических видах разрабатываемых решений.
На первых порах вычислительные ресурсы, например, память, регистры или тактовая частота процессоров были весьма ограниченными, и поэтому требование написания как можно более компактных и эффективных алгоритмов носило императивный характер. Эти цели являются актуальными и на сегодняшний день, но теперь они уравновешиваются долговременными преимуществами, которые сулит написание легких в обслуживании кодов, допускающих возможность их повторного использования. На данном этапе основной целью является не просто написание как можно более эффективного кода, а написание наиболее эффективного кода, отличающегося ясностью, надежностью и легкостью сопровождения.
Пакетная обработка
В эпоху пакетных вычислений (то есть во времена, предшествовавшие появлению диалогового программного обеспечения) безраздельно царствовали алгоритмы. Тогда было возможно, и это имело действительно существенное значение, указать как входные, так и ожидаемые выходные данные системы еще до написания кода. В силу того, что модель применения программных продуктов описывалась схемой ввод→обработка→вывод, много времени тратилось на разработку центрального алгоритма, а главной задача проектирования заключалась в максимальной экономии дискового пространства и памяти. У этой модели есть свои достоинства, и сегодня она по-прежнему является идеалом, к которому следует стремиться при разработке отдельных процедур, предназначенных для обработки информации в пакетном режиме (например, при проектировании алгоритмов сортировки). Такой подход целесообразно применять при проектировании отдельных функций, но не сложных систем, обеспечивающих интерактивное взаимодействие с пользователем. Этот период можно назвать эрой "блок-схем".
Серверная обработка без сохранения состояний
При построении надежных серверных приложений, отвечающих на запросы, роль Святого Грааля играет "отсутствие состояния". Ваш код получает запрос, обрабатывает его, а затем возвращает результат, не нуждаясь в сохранении состояния на протяжении периода времени между двумя последовательными запросами. Все это очень напоминает пакетную обработку, поскольку в данном случае также используется модель, описываемая схемой ввод→обработка→вывод. Разумеется, современные сложные Web- приложения (например, система покупательских тележек на Web-сайте Amazon) должны сохранять свое состояние в течение промежутков времени между двумя последовательными запросами, а этого легче всего достигнуть осуществляя управление состояниями на основе существенно централизованного механизма инкапсуляции, обеспечивающего выполнение как можно большего объема кода без сохранения состояния
Интерактивные вычисления, управляемые событиями
Управляемые событиями вычисления (event-driven computing) представляют вычислительную модель, в которой приложение находится в состоянии долговременного обмена информацией с конечным пользователем. Выполнение кода осуществляется в ответ на действия и запросы конечного пользователя; задача приложения заключается в обеспечении соответствующей реакции на то, что делает пользователь. В отличие от пакетных приложений интерактивные (диалоговые) приложения не имеют определенного фиксированного периода завершения и продолжают обрабатывать новые события, запускаемые пользователем, до тех пор, пока пользователь не решит прервать рабочий сеанс. Эту модель программирования обычно называют "управляемой событиями", поскольку в результате действий пользователя вырабатываются дискретные события (например, события щелчка мыши, выбора элемента списка или закрытия окна), на которые должно реагировать разрабатываемое приложение. При построении удачного интерактивного приложения, управляемого событиями, очень многое зависит от того, насколько тщательно продумана модель управления состояниями.