Сообщений 0 
Оценка 15
[+0/-1]
Оценить 
| Сообщений 0 Оценка 15
[+0/-1]
Оценить
|
Из словаря Merriam-Webster
Основной вход: meth·od·ol·o·gy (методология)
Функция: существительное
Форма(ы) с окончаниями: мн. -gies
Этимология: новолат. methodologia, от лат. methodus + -logia -logy
Дата: 1800
(www.m-w.com, 2004)
Исходные коды примеров к книге
Эта глава специально отведена для рассмотрения методологии разработки программного обеспечения, используемой в процессе проектирования и построения мобильных приложений.
Можно выделить два рода проблем, с которыми приходится сталкиваться разработчикам приложений, специалистам по архитектуре систем и руководителям в процессе разработки программного обеспечения. С одной стороны, это трудности, действительно присущие разработке программного обеспечения как таковой, с другой – трудности временного характера, отражающие несовершенство инструментальных средств разработки и технологий, доступных на данном этапе.
Что касается разработки приложений для десктопов и сервером, то за последние 10-15 лет в разрешении "временных" проблем в этой области был достигнут огромный прогресс. Современные средства разработки имеют несравненно более высокую производительнее по сравнению с теми, которые использовались какой-нибудь десяток лет тому назад. Это утверждение особенно справедливо по отношению к проектированию и отладке пользовательских интерфейсов. Аналогичные преобразования в настоящее время происходят и в области разработки программного обеспечения для мобильных устройств. Многие усовершенствования, касающиеся проектирования и отладки программ для десктопов и серверов, сейчас доступны и для мобильных устройств, что значительно упрощает выполнение этих видов работ и делает их доступными для более широкого круга разработчиков, чем несколько лет тому назад. Темпы разработки программ резко ускорились. В результате этого значительно возросло число проектов, которые могут быть реально осуществлены (за часть которых при других условиях не имело бы смысла даже и браться). Благодаря достижениям в области средств и технологий программирования сейчас вполне осуществимы такие проекты мобильного программного обеспечения, реализации которых еще несколько лет тому назад воспрепятствовала бы их высокая сложность и стоимость.
Однако, как и в случае разработки программ для десктопов и серверов, между "возможностями написания кодов" и "возможностями создания замечательных приложений" лежит огромная пропасть. Последний фактор отражает общие трудности, присущие разработке любого современного программного обеспечения. Одно дело – просто взяться за работу, написать и отладить код, и совершенно другое – связать весь код в корректно функционирующее, надежное и гибкое приложение.
Путь, позволяющий обойти трудности, свойственные разработке программного обеспечения, пролегает через использование подходящих методологий. В двух словах, методология – это набор руководящих принципов, соблюдение которых позволяет успешно завершить начатое дело. Многие из методологий, ориентированных на приложения для десктопов и серверов, в равной степени можно использовать и при разработке программного обеспечения для мобильных устройств, однако трудности, которые являются уникальными или проявляются с особой силой в последнем случае, заслуживают отдельного рассмотрения.
Данная глава разделена на две части. В первой из них обсуждаются общие методологии разработки программ с добавлением в необходимых случаях отдельных пояснений, касающихся частного случая мобильных устройств. Во второй части главы рассматриваются узкие методологические вопросы, непосредственно связанные с особенностями разработки мобильных приложений. Задачей начальных разделов данной является развитие в вас понимания всей важности выбора подходящей методологии разработки, тогда как в оставшихся частях настоящей главы раскрываются принципы конкретной методологии, которыми следует руководствоваться при разработке программного обеспечения для мобильных устройств.
| ПРИМЕЧАНИЕ Великолепная работа по исследованию и обсуждению данной темы проделана в книге The Mythical Man Month. Каждый, кто хочет получить солидную подготовку в области общей методологии разработки программного обеспечения, должен обязательно прочесть эту книгу. |
Некоторые из проблем, с которыми приходится сталкиваться разработчикам программного обеспечения, можно вполне обоснованно охарактеризовать как "временные трудности". С появлением более совершенных инструментальных средств разработки острота этих проблем может снижаться. Хорошим примером временных трудностей могут служить проблемы отладки. За многие годы был достигнут огромный прогресс в предоставлении разработчикам средств отладки приложений в процессе их выполнения. Благодаря этому кардинально изменился сам процесс отладки, которая из трудоемкой задачи, решавшейся ранее путем разрозненного применением столь различного инструментария, как карандаш и бумага, низкоуровневые средства наподобие дизассемблеров или отладочная печать, и требующей немалой доли интуиции, в настоящее время превратилась в весьма естественную интерактивную составную часть любого набора современных средств разработки. Среди разработчиков, пользующихся современным инструментарием, сегодня вряд ли найдутся такие, кто считает отладку отдельным видом деятельности, отличным от проектирования и написания кода. Сейчас все это объединено в рамках одного естественного процесса разработки программного обеспечения, и разработчики плавно переключаются с одного вида деятельности на другой. Еще не так давно наблюдалась явно иная картина, а уж, во всяком случае, в отношении программного обеспечения, выполняющегося на устройствах, об этом можно говорить со всей определенностью. Представляя собой когда-то сложнейшую проблему, в наши дни отладка кода значительно упростилась. Это были временные трудности, и улучшенные технологии позволяют с ними справляться.
Ко второй категории проблем разработки программного обеспечения относятся те, которые лучше всего описываются выражением "неотъемлемые трудности". Корни этих проблем уходят в сердцевину самого процесса разработки программ. Никакими усовершенствованиями инструментальных средства разработки решить эти проблемы невозможно. Скорее, эти проблемы диктуют необходимость применения подходящих методологий, которые могли бы направлять инженерную мысль в нужное русло и гарантировать успешное завершение программных проектов, невзирая на трудности.
Хороший пример сложных проблем постоянного характера предоставляет проектирование алгоритмов. Современные объектно-ориентированные языки разработки значительно облегчили решение задач инкапсуляции и организации кода, но они не в состоянии упростить или автоматизировать проектирование алгоритмов. Несомненно, наличие богатого набора базовых классов, предлагаемых современными программными средами, способствует написанию эффективных алгоритмов, однако проектирование принципиально новых алгоритмов по-прежнему является нелегкой задачей, которая, по всей вероятности, будет оставаться таковой и в ближайшем обозримом будущем. Это имеет место по той простой причине, что алгоритмам, в силу самой их природы, свойственна специфическая целенаправленность, и не существует известных общих способов, позволяющих преобразовать ваши намерения в алгоритм, который наилучшим образом соответствовал бы намеченным целям; подобные задачи поддаются автоматизации лишь при условии значительного сужения масштаба задачи и создания специального инструментария для ее решения. То же самое можно сказать и о написании многопоточного кода. Применение усовершенствованных инструментальных средств, языков программирования и библиотек несомненно облегчает работу и позволяет решать задачи во многих строго описываемых случаях; вместе с тем, создать универсальную машину, способную разрезать общие задачи на параллельные ломтики, нам никак не удается. Подобные проблемы являются неизбежными и требуют тщательного выполнения проектирования и применения подходящей методологии.
Современные языки программирования и средства графического проектирования позволяют разработчикам полнее выражать свои намерения, но не устраняют необходимости в приобретении устойчивых навыков конструирования алгоритмов. Без таких навыков невозможно обойтись при построении критических систем, определяющих поведение и эффективность программного обеспечения. Лучшее, что смогла предложить современная технология программирования, - это упаковка сложных алгоритмов в повторно используемые компоненты и каркасы приложений и предоставление возможности моделирования взаимодействия этих компонент между собой. При таком подходе проектирование критических систем, представляющих всеобщий интерес, могут осуществлять высококлассные специалисты, а остальные разработчики смогут повторно использовать эти системы. Проектирование компонент может быть упрощено, а взаимодействие между авторами компонент и клиентами сделано более прозрачным за счет применения таких технологий моделирования, как UML (Unified Modeling Language – универсальный язык моделирования) и панели графического проектирования (graphical design surfaces), но эти технологии не в состоянии снять проблемы внутренней сложности, свойственные процессу проектирования эффективных алгоритмов. Постоянное совершенствование инструментальных средств будет способствовать преодолению временных трудностей, но трудности постоянного характера, обусловленные самой природой алгоритмов, будут всегда оставаться.
Компоненты находят чрезвычайно широкую применимость, так как позволяют повторно использовать результаты однажды проделанной нелегкой работы, но проектирование алгоритмов от этого нисколько не упрощается. Компонентно-ориентированное проектирование является методологией, которая возникла из необходимости помочь программистам справиться с одной из самых неприятных проблем, с которыми приходится сталкиваться при разработке программного обеспечения. В соответствии с этой методологией разработчикам и специалистам в области архитектуры программных систем рекомендуется разделять свои задачи на отделенные друг от друга многоуровневые компоненты.
Сначала выделяются критические компоненты и алгоритмы, требующие проектирования, кодирования и тестирования на самом высоком профессиональном уровне. Разрабатываемым приложениям вся основная функциональность предоставляется высокоуровневым и, как правило, менее строго тестируемым кодом, который использует эти компоненты. Причиной успеха "компонентизации" как методологии является то, что она дает возможность разложить приложение на отдельные части. Она позволяет инженерам-программистам, специалистам в области архитектуры систем и руководителям идентифицировать наиболее трудные моменты алгоритмизации и сосредотачивать на них внимание. Как и в случае любой другой методологии, при разбиении приложения на компоненты необходимо действовать осмотрительно и не переусердствовать в этом. Если выделять в отдельные компоненты все, что только возможно, лишь на том ошибочном основании, что увеличение количества компонент, на которые разбивается проект, приводит к лучшему техническому решению, то в результате это породит чрезмерно сложные интерфейсы между различными бесчисленными компонентами. Средства моделирования могут оказать вам помощь в визуализации этих взаимодействий, но сплошная мешанина есть сплошная мешанина. Чрезмерное обилие необязательных компонент размывает тот острый фокус, который, в соответствии с самим ее назначением, разбивка на компоненты должна наводить лишь на критические элементы для достижения их высоких эксплуатационных характеристик. Любая методология должна применяться с осмотрительностью и с явным осознанием тех целей, которые при этом преследуются. Методология полезна лишь тогда, когда можно измерить ее эффективность при решении данной задачи для получения уверенности в том, что реализуются все ее преимущества.
Две ситуации, благоприятные с точки зрения использования методологии разбивки на компоненты Двумя областями, в которых использование компонент предлагает эффективные способы решения сложных задач и значительно снижает сложность работы с этими технологиями, являются XML и криптография. Синтаксический анализ XML-выражений является примером непростой технической задачи, для решения которой очень хорошо подходит методология повторного использования компонент. Число разработчиков, которые сами пишут собственные XML-анализаторы для своих приложений весьма невелико лишь по той простой причине, что спроектировать и реализовать высокопроизводительный, в высшей степени надежный и универсальный XMLанализатор очень нелегко. Если бы все желающие использовать в своих приложениях XML должны были заниматься написанием собственных XML-анализаторов, то можно не сомневаться, что в них присутствовали ли бы все виды "блох" и несогласованностей, какие только возможны. Это нанесло бы непоправимый урон самой возможности организации взаимодействия между различными платформами, лежащей в основании XML. Исключая случаи чисто академических упражнений в проектировании алгоритмов (а XML предоставляет для этого действительно благодатную почву), написание собственного XML-анализатора являлось бы глупой затеей; вам никогда не удастся выполнить эту работу так же хорошо, как это сделают те люди, перед которыми поставлена единственная задача: написать и тестировать такой анализатор. Вместо того чтобы заставлять каждого в процессе разработки программного обеспечения тратить время на написание собственных специфических программ синтаксического разбора XML-выражений, была предложена методология проектирования, рекомендует применение заранее созданных и прошедших тщательное тестирование универсальных компонент. В результате разработок, выполненных на очень строгом уровне проектирования алгоритмов и тестирования, были созданы несколько XML-анализаторов, основанных как на собственном, так и на управляемом коде. Эти несколько компонент повторно используются многими разработчиками приложений, желающими применять XML. Таков методологический подход к решению изначально трудной задачи создания надежного XML-анализатора. Другим замечательным примером применения методологии повторного использования компонент, где она оказывается более эффективной по сравнению с пользовательскими вариантами реализации, может служить криптография. Проектирование криптографических алгоритмов является своего рода сложной формой искусства. Вступая в определенное противоречие с этим аспектом специфичности, криптографические функциональные средства с каждым днем приобретают все большее значение для разработчиков, создающих самые обычные приложения. Уже давно доказано – лучшим способом создания незащищенного приложения является написание собственных криптографических алгоритмов. Если только вы не проводите исследования в области криптографии, знайте, что устоявшаяся инженерная практика программирования крайне категорически рекомендует не заниматься созданием собственных криптографических систем. Проектирование, реализация и сопровождение криптографической системы, отвечающей требованиям надежности, живучести и быстродействия, – работа не из легких. Было бы крайне неразумно и ошибочно, если бы каждый, нуждающийся в функциональных средствах криптографии, создавал собственные криптографические системы для своих приложений. Поэтому здесь мы имеем дело с еще одним случаем неотъемлемых проблем проектирования алгоритмов, которые более совершенные инструменты не в состоянии за нас решить. И вместо того, чтобы сдаваться и признавать свое поражение словами: "Да, это действительно трудная задача, и с этим ничего не поделаешь", следует обратиться к методологии программных разработок, основанной на разбиении сложных алгоритмических задач, представляющих всеобщий интерес, на отдельные компоненты, а также к методологии, в соответствии с которой все участники рабочей группы должны использовать компоненты согласованным образом. Дополнительным преимуществом методологии использования готовых, берущихся "прямо с полки" компонент при разрешении проблем подобного рода является снижение затрат на сопровождение программных продуктов. При обнаружении каких-либо изъянов в компонентах (а таковые всегда найдутся) они корректируются централизованным образом, а не требуют каждый раз отдельного рассмотрения, когда периодически всплывают в многочисленных разрозненных реализациях. |
Любой достаточно сложный проект по разработке мобильного программного обеспечения нуждается в хорошем наборе методологий, способных справляться с со свойственными данному виду разработок трудностями постоянного характера. Должен существовать процесс, позволяющий определять трудные проблемы и убеждаться в том, что они решаются наиболее подходящим для этого способом. Использование компонент позволяет справиться с одним специфическим типом проблем разработки программного обеспечения. Однако для решения других проблем, связанных, например, с обеспечением необходимой производительности приложений, проектированием эффективных пользовательских интерфейсов или созданием надежных каналов связи для мобильных устройств, потребуются дополняющие методологии. Умение распознавать проблемы постоянного характера и знание способов их преодоления является отличительным признаком хорошего руководителя группы разработчиков.
Итак, существуют проблемы, в разрешении которых нам могут помочь инструментальные средства, и по мере совершенствования доступного инструментария эти проблемы будут год от года терять свою остроту. Наряду с этими проблемами временного характера существуют проблемы постоянного характера, которые могут решаться лишь на основе применения правильных технических подходов. Это возможно лишь при наличии методологии, гарантирующей, что наиболее важные проблемы будут решаться не от случая к случаю, а на основе их всестороннего и глубокого рассмотрения, как они того заслуживают.
Эволюция подходов к разработке программного обеспечения на протяжении ряда лет Каждый успешный этап развития вычислительных средств знаменовался собственными характерными проблемами и соответствующими методологиями, позволяющими добиваться успеха. Эти методологии базировались и продолжают базироваться как на существующих в то время инструментальных средствах разработки, так и на специфических видах разрабатываемых решений. Первоначально компьютерные ресурсы, например, память, регистры или количество тактов процессора, были весьма скудными, и поэтому требования написания как можно более компактных и эффективных алгоритмов носили императивный характер. Эти задачи являются насущными и на сегодняшний день, но теперь они уравновешиваются долговременными преимуществами, которые сулит написание легких в обслуживании кодов, допускающих их повторное использование. На данном этапе основной целью является не просто написание наиболее эффективного кода, а написание наиболее эффективного кода, отличающегося понятностью, надежностью и легкостью сопровождения. Пакетная обработка В эпоху пакетных вычислений (т.е., во времена, предшествующие интерактивному программному обеспечению) царствовали алгоритмы. Тогда было возможно, и это имело действительно существенное значение, указать как входные, так и ожидаемые выходные данные системы еще до написания кода. Поскольку модель применения программных продуктов основывалась на схеме ввод –> обработка –> вывод, много времени тратилось на разработку центрального алгоритма, а главной целью проектирования было избежать необоснованного расходования дискового пространства или памяти. У этой модели есть свои достоинства, и сегодня она по-прежнему является идеалом, к которому следует стремиться при разработке обособленных процедур, предназначенных для обработки информации в пакетном режиме (например, при проектировании алгоритмов сортировки). Этот подход можно применять при проектировании отдельных функций, но не сложных систем, обеспечивающих интерактивное взаимодействие с пользователем. Этот период можно назвать эрой "диаграмм". Серверная обработка без сохранения состояний При построении надежных серверных приложений, отвечающих на запросы, роль Святого Грааля играет "отсутствие состояния". Ваш код получает запрос, обрабатывает его, а затем возвращает результат, не нуждаясь в сохранении состояния на протяжении периода времени между двумя последовательными запросами. Все это очень напоминает пакетную обработку, поскольку в данном случае также используется модель, описываемая схемой ввод –> обработка –> вывод. Разумеется, современные сложные Web-приложения (например, система потребительских карточек на Web-сайте Amazon) должны сохранять свое состояние в промежутке времени между двумя последовательными запросами, а этого легче всего достигнуть, осуществляя управление состояниями на основе в заметной мере централизованного механизма инкапсуляции, обеспечивающего выполнение как можно большего объема кода в режиме без сохранения состояния. Интерактивные вычисления, управляемые событиями Управляемые событиями вычисления (event-driven computing) представляют вычислительную модель, в которой приложение находится в состоянии долговременного общения с конечным пользователем. Выполнение кода осуществляется в ответ на действия и запросы конечного пользователя; приложение реагирует на то, что делает пользователь. В отличие от пакетных приложений интерактивные приложения не имеют какого-либо фиксированного периода завершения и продолжают обрабатывать новые события, запускаемые пользователем, до тех пор, пока пользователь не решит прервать рабочий сеанс. Эту модель программирования обычно называют "управляемой событиями", поскольку в результате действий пользователя вырабатываются дискретные события (например, события щелчка мыши, события выбора элемента списка или события закрытия окна), на которые должно реагировать разрабатываемое приложение. При построении удачного интерактивного приложения, управляемого событиями, очень многое зависит от наличия тщательно продуманной модели управления состояниями. |
В наши дни лишь немногие специалисты рекомендуют использовать диаграммы для представления функционального поведения приложений. Начнем с того, что в этом случае работать пришлось бы с диаграммами огромных размеров. Современная модель программирования приложений, управляемых событиями, богатые пользовательские интерфейсы и широкодоступные инструментальные средства, обеспечивающие быструю разработку приложений, привели к тому, что идея отображения при помощи диаграмм всех алгоритмов приложения и вариантов пользовательского взаимодействия в настоящее время кажется уже старомодной. Детализация на таком уровне может быть использована для отображения отдельных ключевых алгоритмов, если это окажется необходимым, но в целом требуется более высокоуровневый подход.
Существует и противоположный подход, ориентирующийся на конкретную специфику ситуаций, суть которого состоит в том, что необходимо "просто взяться за работу и начать составлять код, пока не будет получено завершенное приложение". При всей своей соблазнительности такой бездумный подход к программированию чреват возможными просчетами и обычно приводит к созданию беспорядочного клубка плохо функционирующего кода с массой "ляпов", который с трудом поддается сопровождению и, в конце концов, будет отброшен и заново переписан. Приложения этого типа часто выглядят так, будто их "склепали" или "слепили" лишь потому, что под рукой были их составные части. В этом случае в основе всех проектных решений лежат ответы на частные вопросы: "Каким образом может быть решена только что возникшая проблема?", и при этом мало внимания уделяется анализу того, каковое общее влияние окажет данное решение на систему в целом как в отношении поведения системы, так и в отношении сложности кода.
В отличие от описанного подхода, отличающегося узостью рассмотрения задачи, сторонники одного из других направлений утверждают: "Прежде чем написать хотя бы одну строку кода, составьте детальные спецификации для всего приложения в целом". Такой уровень детальной координации может потребоваться для проектов, в которых участвуют группы разработчиков, но работа над такими проектами требует также и дисциплины соблюдения текущих спецификаций, чтобы они имели смысл на протяжении всего процесса разработки. Кроме того, в таких проектах требуются детальные предварительные сведения относительно конечного поведения приложения, заблаговременное знание которого во многих случаях просто нереально. Как ни заманчиво звучит "специфицировать все до мельчайших деталей", такой подход обычно оказывается непригодным для современных процессов разработки, и в частности, если речь идет о разработке первой версии продукта, поскольку по мере продвижения работы многое будет проясняться, что повлечет за собой соответствующее изменение требований. Это особенно справедливо в случае разработки приложений для мобильных устройств, когда для понимания того, как люди будут использовать их в реальной жизни, могут потребоваться испытания в реальных условиях. Важно, чтобы проект предусматривал определенный уровень гибкости, позволяющий адаптироваться к обнаруженным в процессе разработки новым факторам и возникающим проблемам. Спецификация должна существовать, однако вначале она должна быть гибкой, но постепенно все более уточняться по мере приближения продукта к его окончательной форме.
Очень важно выбрать тот реалистический уровень организации процесса, которого вы и ваша группа сможете придерживаться. Даже если вы выполняете работу в индивидуальном порядке, желательно приучить себя к определенной самодисциплине. В сравнительно небольших проектах, каковыми обычно являются приложения для мобильных устройств, должен реализовываться подход, который будет привлекателен и выгоден для всех участников группы. Чрезмерное планирование лишает гибкости в тех случаях, когда первоначальные планы приходится изменять. Излишне строгие пункты плана или негибкие спецификации будут просто отбрасываться. С другой стороны, отсутствие плана или слабая организация процесса проектирования приведут к неустойчивости определения продукта, который либо скатится до посредственного уровня, либо должен будет переделываться. Существует "золотая середина", зависящая от размера, сферы применимости и степени завершенности разрабатываемого продукта. Важно правильно оценить масштабы проекта и исходя из этого наметить реалистическую организацию работы, позволяющую достигнуть конечной цели.
Существуют замечательные книги, посвященные вопросам организации процесса проектирования программного обеспечения, поэтому ниже приводятся лишь краткие замечания. От своего имени могу дать следующие рекомендации, соблюдение которых, по моему мнению, играет важную роль при разработке программного обеспечения:
В случае любого проекта разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный "актуальный документ", в котором определяются 1) требования проекта и целевое назначение завершенного продукта, 2) философия проекта, 3) архитектура приложения, 4) текущее состояние работ в этом направлении и 5) план, в соответствии с которым продукт будет доведен из его нынешнего состояния до успешного завершения. Для крупных продуктов могут предусматриваться дополнительные документы, но всегда должен существовать ключевой документ самого верхнего уровня, в котором определяются основные цели проекта, его нынешнее состояние и план работ. Этот документ должен быть реально действующим документом, который, по мнению всех участников группы, правильно определяет направления работы.
Единственный актуальный документ, который управляет всем процессом разработки, должен быть разбит на несколько разделов:
По мере продвижения работы над проектом вы будете открывать для себя много нового. Как бы вы ни старались все предугадать, всегда будут возникать непредвиденные трудности. Вы столкнетесь с проблемами производительности и вам, по всей видимости, не удастся сразу же получить наиболее подходящий пользовательский интерфейс. Приобретение опыта в разработке мобильных приложений означает, что в будущем вы будете совершать меньше ошибок, но можно почти с полной уверенностью утверждать, что каких-то ошибок вы не избежите. Планируйте проведение критического анализа полученных результатов во время выполнения отдельных контрольных этапов и особенно – завершающих контрольных этапов разработки, когда вы можете подвести некоторые промежуточные итоги и установить основные проблемы, которые к этому времени успели возникнуть. Итеративная природа процесса проектирования современного программного обеспечения повышает значимость своевременного обновления основного документа проекта, а также методологии, способной предоставить эффективные возможности итерирования проекта.
Несмотря на всю очевидность этого утверждения является очевидным, но в процессе написания кодов мобильных приложений о нем часто забывают. Разработчики теряются в коде и забывают о том, для чего предназначено само приложение. В случае приложений для настольных компьютеров и Web-приложений это чаще всего проявляется в неуклюжих и малопонятных пользовательских интерфейсах и отсутствии ключевых функций. Приложение хотя и работает, но не совсем так, как следовало бы, и при изучении порядка обращения с ним конечного пользователя ожидают тяжелые испытания. Пренебрегая необходимостью иметь в голове цельную картину всего, что связано с приложением, вы рискуете утратить ясность целей.
Ввиду того что приложения для мобильных устройств отличаются большей целенаправленностью модели применения и ограниченностью пользовательского интерфейса, результаты утери ясности целей разработчиком в этом случае оказываются еще более плачевными. Работая с неудачно спроектированным мобильным приложением, конечный пользователь в гораздо большей степени ощущает любые неудобства в работе и острее воспринимает любые недостатки приложения. Навигация в пределах приложения превращается в сплошной кошмар, очень быстро накапливаются проблемы производительности, в результате чего конечный пользователь испытывает только разочарование. Поскольку размеры мобильные устройств близки к размерам обычных устройств и приспособлений, которыми можно оперировать одной рукой (часы, телефоны, складные ножи, музыкальные плееры, отвертки и т.п.), пользователь проникается убеждением, что их поведение должно быть кристально прозрачным и интуитивно понятным. Мобильные приложения должны быть такими, чтобы пользователь мог применять их, не нуждаясь в особых инструкциях. Наверное, каждый из нас может припомнить из своей практики случаи, когда приходилось пользоваться электронными часами или пультом дистанционного управления с многочисленными или неудачно расположенными кнопками. Ясность намерений разработчика имеет огромное значение.
По этой причине очень важно, чтобы основной документ вашего проекта содержал отчетливые формулировки целей создания приложения. Со временем эти цели могут претерпевать изменения, но работа каждого должна быть направлена на решение одного и того же круга согласованных задач. В случае возникновения необходимости в изменении точки приложения основных усилий, каждый должен изменить акценты своей работы, и тогда на помощь приходит основной документ проекта с его разделом, содержащим развернутые формулировки целей. Если ваше приложение не в состоянии полностью обеспечить достижение установленных целей, то успеха вы не добились, независимо от того, какой объем кода вами написан.
Все является важным, но некоторые вещи более важны, чем другие. В математическом анализе функций существует понятие об эффектах первого, второго, … n-го порядка. Чем ниже порядок эффекта, тем более заметное влияние оказывает данный член ряда на поведение всей системы; эффектами высших порядков часто можно пренебречь. Аналогичная ситуация складывается и в процессе разработки мобильных приложений; вы не имеете возможности уделять равное внимание всем аспектам, поэтому научитесь концентрировать свои усилия на том, что имеет наибольшее значение.
Ниже перечисляются шаги, описания которых демонстрируют, как подступиться к наиболее значимым аспектам вашего проекта мобильного приложения. Шаги перечислены в порядке их следования. По мере внесения изменений в проект и при его переделках обязательно повторно просматривайте предыдущие шаги, ибо это позволит вам всегда быть уверенным в том, что изменения, которые вы вносите для решения тех или иных проблем, не заставят вас переделывать давно выполненную работу. Например, может сложиться такая ситуация, что решение проблем связи оказывает влияние на способ взаимодействия пользователей с данными, предоставляемыми пользовательским интерфейсом; иногда это допустимо, иногда – нет. Если вы изменяете коммуникационную модель своего мобильного приложения, обязательно исследуйте, как это скажется на фундаментальных аспектах, управляющих пользовательским восприятием вашего приложения.
Этот шаг назван нулевым, поскольку он действительно предшествует любой работе, связанной с проектированием и разработкой приложения. Прежде чем вы приступать к составлению планов и созданию программного обеспечения, вы должны хорошо представлять себе, каким должен быть результат.
Приложения для настольных компьютеров подобны широкоугольной линзе в том смысле, что в типичных случаях они отображают значительный объем информации, предоставляя пользователю материал для изучения на экране большого размера. В отличие от этого мобильные приложения напоминают увеличительное стекло или линзу. Они предоставляют пользователю возможность быстро просматривать требуемые детальные данные, быстро переходить к суженным наборам данных и получать к ним доступ, а также принимать решения в реальном масштабе времени. Как правило, мобильные приложения представляют более специализированный набор сценариев по сравнению с приложениями, ориентированными на десктопы. Очень важно точно определиться с тем, на каких сценариях должно специализироваться ваше приложение.
Прежде чем начать реально разрабатывать приложение, определите подмножество функциональных средств, к которым пользователь сможет получать быстрый доступ в духе, свойственном мобильным устройствам. В случае создания нового приложения, аналога которого для десктопов не существует, запишите ключевые сценарии, которые пользователи смогут выполнять при помощи вашего приложения, а также порядок действий пользователя, обеспечивающий использование этих сценариев посредством мобильного устройства. Во многих случаях вам будет легче придать этим сценариям реальные очертания, если вы подготовите соответствующие рисунки или создадите прототипы. Если подразумевается определенная группа конечных пользователей, пообщайтесь с ними и предоставьте им возможность поработать некоторое время с экспериментальными версиями своих приложений, чтобы они могли дать о них свои отзывы.
Если вы правильно выделите ключевые сценарии и средства вашего приложения, то это окажет определяющее влияние на всю оставшуюся часть процесса разработки. Наличие явно сформулированного описания того, как конечные пользователи будут использовать ваше приложение, и детальное понимание их потребностей окажут вам неоценимую помощь при настройке производительности приложения и проектировании пользовательского интерфейса, коммуникационной системы и модели памяти.
Если вы не определите важнейшие с вашей точки зрения сценарии и средства, то в результате вы получите бессистемную смесь средств, объединенных в одно приложение. Отсутствие явного списка основных функций приложения или разделения функций на группы в соответствии с их приоритетами приведет к тому, что пользовательский интерфейс не будет оптимизирован для эффективного решения ключевых задач. Например, если ожидается, что пользователь в основном будет заинтересован во вводе данных, то вы должны оптимизировать пользовательский интерфейс таким образом, чтобы обеспечить как можно более точное и надежное выполнение операций ввода. И наоборот, если ввод данных используется лишь изредка, то вариант пользовательского интерфейса ввода, оптимизированного не самым идеальным образом, может оказаться вполне допустимым, что позволит перебросить ресурсы проектирования и разработки на другие направления. Лишь только если группой разработчиков будут идентифицированы, перечислены и согласованы наиболее важные сценарии, эксплуатационные характеристики приложения могут быть настроены для их выполнения должным образом, а конечные пользователи не будут по недосмотру лишены важных для них средств.
Чтобы процесс разработки завершился успешно, составьте спи кок ключевых требований, которым должно удовлетворять приложение, и возможностей, которые оно должно обеспечивать, и пусть этот список будет первым разделом вашего основного документа проекта.
| Неудачное описание | Удачное описание |
|---|---|
| Приложение для обслуживания банковских операций" Обеспечить для пользователей мобильных устройств доступность Web-функциональности приложения MyBankFoos, предназначенного для мобильного банкинга, как в автономном, так и в сетевом режиме работы". В этом описании ни слова не сказано о том, какие функциональные возможности являются наиболее важными. Что именно должно быть отнесено к их числу? Возможность проверки состояния нужного счета? Оплата счетов? Список операций по переводам денежных средств? Смена обслуживающих банков? Денежные переводы? Операции в местах продажи? Заемные и залоговые условия при покупке автомобиля? Каковы те основные операции, в выполнении которых при помощи мобильного устройства больше всего будет нуждаться пользователь? | Приложение для обслуживания банковских операций "1. Пользователи должны иметь возможность получения доступа к своим банковским счетам посредством не более пяти нажатий кнопок клавиатуры мобильного телефона, выполняемых одной рукой. 2. Пользователи должны иметь возможность совершать покупки и получать соответствующие подтверждения от торговых автоматов, используя инфракрасный порт устройства, при помощи не более трех клавиатурных нажатий". Мы идентифицировали два ключевых сценария, которые хотели бы сделать доступными для пользователей. |
| Опросы общественного мнения "Обеспечить замену бумаге и дощечке с зажимом при проведении опросов общественного мнения и избавится от занесения данных опроса вручную". Какие вопросы будут задаваться? Когда будет выполняться синхронизация данных? | Опросы общественного мнения "Приложение должно предоставить пользователям возможность сбора информации в ходе опросов общественного мнения, при помощи устройства Pocket PC. Вопросы будут предусматривать либо выбор одного из готовых вариантов ответа, либо простой цифровой ввод, а ответы будут кэшироваться на устройстве и отправляться на сервер после помещения PC на подставку. Опрос может содержать до 20 вопросов, а результаты, содержащие вплоть до 1000 ответов, должны хранится на устройстве. Ввод текста вручную не требуется". Мы указали, какие виды вопросов должно обрабатывать приложение, а также каким образом будет осуществляться синхронизация устройства. (Здесь следует обратить внимание на то, что при составлении списка сценариев мы не заботились о том, какой именно способ сохранения результатов на устройстве будет использоваться или каков будет конкретный механизм синхронизации, коль скоро сценарий работает, - это важно только для нашей реализации, но не для конечного пользователя.) Мы указали также и то, что от приложения не требуется (например, ему не придется обрабатывать текст в свободной форме). |
| Учет товара "Версия системы учета товара, ориентированная на настольные компьютеры, будет сделана доступной для подключенных к сети и автономных мобильных устройств". Полный перенос функциональности Web-приложений, а также рассчитанных, на десктопы, почти никогда не приводит к удовлетворительным результатам. | Учет товара "Приложение предназначено для использования на складах в режиме периодического доступа к сети WI-Fi. Должна быть обеспечена возможность автономного режима работы с хранящимися на устройстве данные учета товаров, охватывающие вплоть до 5000 наименований. Идентификаторы товарных единиц должны сканироваться при помощи устройства для считывания штрих-кодов. Учетные записи о товарных единицах могут включаться в список описи и исключаться из нее. Устройства синхронизируются с использованием сети Wi-Fi, когда к этому их вынуждает пользователь. Для обновления информации может быть затребован активный доступ к серверной базе данных. Ключевой сценарий: Произвести сканирование при помощи устройства для считывания штрих-кодов и указать нажатием клавиши вид операции со списком описи – добавление или исключение учетной записи. Считать порядковый номер покупки для его связывания с учетной записью о товарной единице. Ключевое требование: В случае невозможности считывания штрих-кода пользователь должен иметь возможность быстро ввести необходимую цифровую информацию вручную при помощи сенсорного экрана и пера. Для повышения надежности ведения учета информация о неудачных попытках считывания штрих-кодов в процессе эксплуатации приложения должна заноситься в журнал." Мы указали, в чем состоит суть ключевых требований, а также выписали основной сценарий, в соответствии с которым будет эксплуатироваться приложение. |
| Игровые/обучающие приложения "Создать мобильное приложение для изучения слов иностранного языка". Какая емкость словаря потребуется? Как в общих чертах будет происходить процесс обучения? | Игровые/обучающие приложения "Приложение является игрой, предназначенной для проверки того, насколько хорошо пользователь знает слова иностранного языка. Пользователям предлагаются вопросы, предлагающие выбрать правильный перевод слова из набора предложенных вариантов путем касания экрана. В устройстве может храниться до 1000 различных иностранных слов. В устройстве также должны храниться примеры предложений с изучаемыми словами." Обучающая программа описана довольно полно. Потребуется дальнейшее исследование того, как должна работать игра, но мы уже определили высокоуровневую модель ввода/вывода и емкость словаря. |
| Приложение для заказа авиабилетов "Приложение должно обеспечить сохранение и обработку всей пользовательской информацией о рейсах в мобильном телефоне и сделать ее доступной при работе в автономном режиме". В этом описании мало говорится о том, что будет делать приложение и каким образом пользователь будет работать с ним. | Приложение для заказа авиабилетов "Пользователь должен иметь возможность получения доступа к сохраняемой в устройстве информации, касающейся электронного заказа билетов. Информация, которую сможет получать пользователь мобильного телефона, включает в себя номер заказа, номер полета, время полета и данные об аэропортах вылета и назначения, причем для получения доступа к этой информации должно требоваться не более трех клавиатурных нажатий. Должен быть обеспечен быстрый вызов и передача этой информации работнику, осуществляющему резервирование посадочных мест." |
После того как вы идентифицируете ключевые сценарии и возможности приложения, вы должны позаботиться о создании наилучших условий работы для тех, кто будет им пользоваться. Под этим подразумевается, что вы должны подумать об обеспечении наиболее оптимальной производительности и интерактивности вашего мобильного приложения.
Проверяйте свои допущения в реальных условиях эксплуатации сценариев. Даже если для некоторых частей приложения не хватает реальных данных или кода, для испытания эффекта задержек при выполнении пользователем обычных задач легко вставить состояния ожидания в скелет кода пользовательского интерфейса приложения. Очень важно иметь хорошее представление о том, какие периоды ожидания допустимы, а какие – нет. Следует стремиться к тому, чтобы приложение всегда давало возможность понять, что та или иная операция находится в состоянии выполнения, если она не может закончиться немедленно. Кроме того, если работа может выполняться в течение длительного или неопределенного времени, ее выполнение может быть поручено фоновому потоку.
Разрабатывая приложение, используйте реалистические размеры данных, отражающие либо превышающие предполагаемые размеры данных, с которыми придется работать пользователю. Одной из распространенных ошибок, допускаемых разработчиками в процессе создания приложений, является использование пробных данных небольшого объема, что иногда приводит к тому, что при работе с фактическими объемами реальных данных приложение работает просто ужасно. Чем раньше вы начнете тестировать приложение на реальных данных, тем раньше эти проблемы выйдут на поверхность и тем выше шансы того, что вам удастся справиться с проблемами производительности.
Блок-схема организации процесса разработки мобильного приложения представлена на рис. 4.1. Если вы столкнулись с проблемами производительности – остановитесь! Можно сказать это и по-другому: если в процессе проектирования и разработки приложения вы столкнулись с проблемами производительности – немедленно прекратите дальнейшее написание кода! Слишком уж часто разработчики продолжают тратить время на составление кода, чтобы иметь на руках "завершенный код", давая себе обещание, что впоследствии они обязательно вернутся к решению возникших проблем производительности. Такая стратегия в лучшем случае является рискованной! Она редко приводит к успеху в случае приложений для десктопов и серверов и обычно приводит к довольно плачевным результатам; в случае же мобильных устройств результаты ее применения будут еще худшими. Причина этого заключается в том, что проблемы производительности часто не являются следствием недостатков какого-то отдельного алгоритма, который можно просто доработать или оптимизировать, не влияя на остальные части системы. До тех пор пока вы детально не выясните природу проблемы и не убедитесь в том, что альтернативное решение способно ее устранить, вы, в действительности, не можете сказать ничего определенного о том объеме переделок проекта, которые для этого могут потребоваться. Вам может повезти, однако везение довольно быстро покидает тех программистов, которые слишком зависят от него.
Рис. 4.1. Методология, подчиняющаяся требованиям производительности
Во многих случаях проблемы производительности имеют систематический характер и касаются всего приложения в целом. Некоторые из систематических причин плохой производительности обусловлены способом обмена данными с памятью, количеством одновременно удерживаемых в памяти ресурсов или особенностями того способа, который используется пользовательским интерфейсом для перерисовки и обновления информации на экране. Подобные разновидности проблем производительности обычно являются следствием неудачного выбора проектного варианта, и их удовлетворительное разрешение должно обеспечиваться уже на самых ранних стадиях процесса проектирования и разработки приложения. Стоимость чрезмерно быстрого продвижения вперед для получения "завершенного кода" и последующего возврата к пересмотру стратегии доступа к данным, повторному проектированию модели использования памяти и организации выполнения какой-либо работы в фоновом режиме для улучшения интерактивности пользовательского интерфейса поистине огромна. Даже если в результате внесения запоздалых проектных изменений вы и получите работающий код приложения, он окажется плохо организованным. Реальные основы высокой производительности приложения должны закладываться еще в его фундаменте.
Не забывайте также о том, что по мере разработки приложения оно будет все время разрастаться и усложняться. Вы буде писать все больше кода, создавать все новые объекты, и у вас будет появляться все больше компонент, конкурирующих между собой за право обладания ограниченным пулом ресурсов. Если ваше приложение сталкивается с проблемами производительности и вы не обратите на это внимания сразу же после того, как они возникли, то по мере того, как объем кода будет расти, эти проблемы могут только усугубляться, а не ослабляться. К тому же, добавление нового кода будет порождать дополнительные зависимости в модели данных, модели использования памяти, модели пользовательского интерфейса, коммуникационной модели и других логических частях программы, которые вы написали. Вы сами себя загоните в угол.
Нередко можно встретиться примерно с такими рассуждениями, которые на первый взгляд кажутся вполне разумными, но на самом деле являются глубоко ошибочными: "Прежде чем я смогу понять, какие части приложения нуждаются в улучшении, я должен написать весь код". Такая позиция является весьма порочной, поскольку в ней содержится предположение о том, будто отдельные части вашего приложения каким-то странным образом не зависят друг от друга. Вместе с тем, когда вы напишете весь код, в него будет введено множество явных и неявных зависимостей между различными системами, и вы, вероятнее всего, будете в состоянии внести в код лишь некоторые изменения количественного, а не качественного характера. Вам не уйти от этого даже в том случае, если вы приложите максимум усилий к инкапсуляции кода приложения. Чем больше объем кода, тем больше в нем существует зависимостей между отдельными частями; пытайтесь бороться с этим, тщательно продумывая структуру приложения, но знайте, что это – неизбежное жизненное явление. Браться за решение проблем производительности следует тогда, когда базовый код еще обладает достаточной гибкостью и остается открытым для реструктуризации. Наилучшим временем для этого является период первоначального написания кода.
Как только у вас возникнут проблемы с производительностью – остановитесь, оцените ситуацию и выясните, что происходит. Имеет ли место неэффективное обновление пользовательского интерфейса? Не хранится ли в памяти слишком много данных, в результате чего "сборщику мусора" приходится непрестанно трудиться? Не характеризуется ли данный вид обработки изначально длительным временем выполнения, в результате чего ее целесообразно выполнять в фоновом режиме, асинхронно по отношению к пользовательскому интерфейсу? Не работаете ли вы с большими объемами данных, используя высокоуровневую модель объектов с сохранением состояний, тогда как лучше было бы использовать низкоуровневую модель программирования без сохранения состояний? Определите, в чем коренятся причины проблемы и соответствующим образом перестройте структуру кода для их устранения, прежде чем приниматься за дальнейшее составление кода, который будет зависеть от принятых вами допущений.
Придерживаясь в процессе разработки приложения определенной дисциплины и не упуская из виду вопросы производительности, вы сможете добиться того, что код, а также модели использования данных и памяти вашего приложения не будут содержать ничего лишнего, а дизайн пользовательского интерфейса будет отличаться ясностью и эффективностью.
Если вы создадите привлекательный и интуитивно понятный интерфейс, простую и надежную коммуникационную модель и объектно-ориентированную модель данных, но ваше приложение будет вести себя неудачным образом, конечные пользователи будут разочарованы. В силу самой природы мобильных устройств конечные пользователи рассчитывают на их высокую интерактивность. Люди носят эти устройства в карманах и надеются, что смогут воспользоваться ими сразу же, как только в этом возникнет необходимость.
Очень важно понимать, что восприятие любых эксплуатационных параметров приложения носит исключительно субъективный характер. Пользователя не интересует, сколько времени ушло на получение данных, ему важно лишь то, насколько длительным показался ему этот промежуток, и что в это время происходило. Этим можно воспользоваться с выгодой для себя при проектировании приложения. Длительно выполняющиеся операции не будут казаться большим злом, если поведение приложения таково, что у пользователей складывается впечатление, будто они сохраняют контроль над ситуацией и чувствуют ответную реакцию приложения. Главные доказательства высокой производительности приложения коренятся в ощущениях реального пользователя.
Поставьте перед собой формирование нужного пользовательского восприятия характеристик производительности приложения в качестве основной цели. Эту задачу вы должны начать решать еще до того, как приступите к проектированию пользовательского интерфейса, многие аспекты которого будут определяться требованиями производительности. Например, предположим, что в приложении предусмотрена запрашиваемая пользователем операция, для выполнение которой требуется 20 секунд. Поскольку оставить пользовательский интерфейс без возможности реагирования на действия пользователя на целых 20 секунд было бы недопустимо, эта работа должна выполняться в фоновом режиме, чтобы в процессе обработки запроса пользовательский интерфейс сохранял свою интерактивность. Если вы поступите именно так, то часть визуального пространства, занимаемого пользовательским интерфейсом, целесообразно выделить для вывода информации о состоянии выполнения данной операции, чтобы пользователь знал, что его запрос принят и обрабатывается.
Пример разработки пользовательского интерфейса с учетом требований обеспечения высокой производительности Как ActiveSync, так и Internet Explorer для Pocket PC и интеллектуальных телефонов предлагают элементы пользовательского интерфейса, назначение которых состоит в том, чтобы информировать пользователей о состоянии выполнении инициированных ими асинхронных запросах. Благодаря этому пользовательский интерфейс сохраняет свою интерактивность, а у пользователя не возникает чувства потери контакта с устройством. Для синхронизации календарной информации с сервером Exchange приложению ActiveSync может потребоваться инициация телефонного звонка или иной операции соединения, выполнение которой занимает длительное время. В процессе выполнения такой операции пользовательский интерфейс устройства отображает пояснительный текст, информирующий пользователя о текущем состоянии попытки создания соединения. Таким текстом может быть "Набор номера …", "Соединение с сервером", "Синхронизация расписания", "Загружено 12 из 20" и т.п. Подобные простые уведомляющие элементы пользовательского интерфейса не дают никакого выигрыша в производительности, но зато сохраняют в пользователе уверенность в том, что полезная для него работа продолжает выполняться, и удерживают его от попыток отмены запроса из-за того, что его выполнение затягивается. Pocket Internet Explorer также может нуждаться в подключениях к источникам данных, просмотре IP-адресов URL и выполнении других задач в процессе загрузки Web-страниц. При выполнении подобных затяжных задач заголовок окна браузера обновляется, все время отображая текст, информирующий о состоянии соединения. Кроме того, при загрузке Web-содержимого отображается анимационный флаг Windows. Оба указанных действия информируют пользователя о том, что выполнение операции продолжается. В обоих случаях пользовательский интерфейс сохраняет свою интерактивность, а пользователям предоставляется возможность отмены операции, если они того захотят. Наличие возможности в любой момент прекратить выполнение операции поддерживает в пользователе чувство уверенности, а непрерывное информирование их о степени выполнения операции уменьшает вероятность того, что они ее отменят. Конечно, было бы лучше всего, если бы такие операции выполнялись мгновенно, но в тех случаях, когда это невозможно, следующее наилучшее решение состоит в том, чтобы поддерживать интерактивность пользовательского интерфейса и непрерывно информировать пользователя о развитии ситуации. |
Как выше уже обсуждалось, еще до начала проектированию мобильного приложения важно выделить ключевые сценарии и возможности, которые будут определять его сферу применимости. Очередное важное замечание касается того, чтобы весь процесс разработки был ориентирован на обеспечение высокой производительности приложения, что позволит вам не загнать самих себя в угол при составлении кода. Если вы не в состоянии добиться того, чтобы выбранные вами ключевые сценарии и средства функционировали удовлетворительно, возвращайтесь обратно к чертежной доске.
Следующей в списке важных задач стоит разработка подходящего пользовательского интерфейса. Точно так же как проблемы производительности решаются с учетом особенностей человеческого восприятия, хороший пользовательский интерфейс должен проектироваться с учетом специфики целевых устройств. Пользовательский интерфейс, являющийся оптимальным для одного класса устройств, для устройств другого класса может оказаться далеко не лучшим вариантом. Учет специфики всегда является оправданным.
Будьте готовы к итеративному проектированию пользовательского интерфейса, особенно если для мобильных устройств вы это делаете впервые или только приступаете к работе с новым классом устройств, форм-фактор которых отличается от тех, с которыми вы раньше имели дело. По мере накопления опыта работы с устройствами данного класса процесс проектирования пользовательских интерфейсов для вас ускорится, но вам все равно придется возвращаться к более ранним этапам работы, чтобы все выглядело отлично и хорошо воспринималось.
Рис. 4.2. Проектирование пользовательского интерфейса, ориентированное на достижение высокой производительности
Будет неплохо, если вы возьмете за правило отделять логику выполнения приложения от логики представления информации, и тогда внесение изменений в пользовательский интерфейс не будет влечь за собой необходимости изменения логики приложения. Это вдвойне справедливо, когда речь идет об устройствах. Абстрагируя логику выполнения приложения от логики представления, усиливаете свои позиции как в отношении пересмотра и улучшения пользовательского интерфейса для устройства, которое в настоящее время является для вас целевым, так и в отношении быстрого переноса приложения на новые классы устройств. Сегодняшнее приложение для ручного устройства PDA завтра вполне может стать приложением для интеллектуальных телефонов, если только код его пользовательского интерфейса не сплетен накрепко с основной логикой приложения. Тщательное разделение логики приложения и логики интерфейса принесет вам неплохие дивиденды как в отношении сопровождения кода, так и в отношении его переносимости.
Ключевыми факторами проектирования пользовательского интерфейса являются обеспечение продуктивной работы конечного пользователя и сохранение способности интерфейса в любой момент реагировать на внешние воздействия. Очень важно, чтобы пользователи могли быстро выполнять основные сценарии приложения. Например, если конечным пользователям приходится часто вводить календарные даты, то используемые для этого способы должны быть как можно более быстрыми, простыми и предсказуемыми. Если в иных возможных ситуациях пользователям приходится часто выбирать из большого списка один элемент, то быстрее всего это можно сделать не тогда, когда все элементы содержатся в одном списке типа ListBox, а тогда, когда для этого разработан специальный графический пользовательский интерфейс, при помощи которого пользователи смогут быстро отыскать нужный элемент. Список автомобильных запчастей только выиграет, если его дополнить схематическим изображением автомобиля, касание отдельных частей которого на дисплее будет перемещать вас в нужную часть списка. Подобным же образом в медицинском приложении может быть использовано схематическое изображение человеческого тела. Корректный пользовательский интерфейс зависит от типа решаемых задач и специфики устройств, на которых выполняется приложение. Вот почему идею пользовательских интерфейсов, которые "пишутся однажды, выполняются везде", в случае мобильных устройств не всегда удается реализовать. Подходы этого типа просто не в состоянии обеспечить одинаково хорошие условия работы для пользователей на устройствах широкого спектра с различными размерами дисплеев и возможностями ввода.
С обеспечением высокой продуктивности работы пользователя тесно связано поддержание способности интерфейса реагировать на внешние воздействия. Пользовательский интерфейс приложений для мобильных устройств должен обладать быстрым откликом. Это вовсе не означает, что пользователя нельзя оставлять в состоянии ожидания на какое-то время; избежать этого иногда просто невозможно. Однако ни в коем случае нельзя заставлять пользователя гадать, выполняется ли запрошенная им операция или запрос необходимо повторить. Отсутствие каких-либо признаков активности устройства, получившего запрос на выполнение операции, вызывает сильное раздражение у пользователей, поскольку психологически они настроены на то, что после нажатия кнопки, касания экрана или иного воздействия на то, что находится у них в руке, что-то должно обязательно происходить.
Выбранные вами для мобильного приложения модели данных и памяти определяют, каким образом будет осуществляться управление объектами и ресурсами, удерживаемыми в памяти. И наоборот, эти модели памяти также определяют, каким образом ваше приложение будет избавляться от ненужных данных и ресурсов, чтобы освободить память для своих нужд. Мобильные устройства заметно отличаются от своих настольных собратьев повышенными запросами в отношении эффективности управления данными и памятью.
В мобильных устройствах крупными пулами памяти и файлами подкачки жертвуют ради уменьшения размеров и снижения энергопотребления. Приложение, выполняющееся на мобильном устройстве, обитает уже не в роскошном особняке, а в приличной городской квартире. Взамен спортивного автомобиля, используемого приложениями настольных компьютеров для быстрого объезда окрестностей, у него имеется только мотоцикл. Считать свое приложение обитающим в условиях намного более ограниченного пространства – неплохая аналогия, которую полезно постоянно держать в голове в процессе проектирования моделей данных и памяти для мобильного приложения.
Рис. 4.3. Проектирование моделей данных и памяти, ориентированное на достижение высокой производительности
Те, кто программирует приложения для десктопов, исключая приложения, потребляющие огромные ресурсы памяти (например, сложные программы рисования часто обрабатывают числовые матрицы огромной размерности), в своем большинстве обычно даже не задумываются о том, какую модель памяти лучше использовать. Поэтому в таких приложениях систематическое и заблаговременное освобождение памяти от хранящихся в ней ресурсов, необходимость в которых отпала, как правило, не производится. Любые необходимые данные сразу же загружаются в память без предварительной ее очистки от ненужных данных. Загрузка данных и ресурсов в память продолжается непрерывно либо из-за беспечности программиста, либо просто на тот случай, если они могут понадобиться пользователю. Если уж приложение утруждало себя загрузкой некоторых данных или изображений из сетевого ресурса, то почему бы не подержать их в памяти подольше, чтобы сразу же предоставить их пользователю, если ему захочется вновь обратиться к этому же ресурсу? В случае приложений, предназначенных для десктопов, такой подход является в большой мере оправданным; находящиеся в памяти неиспользуемые данные в конечном счете сбрасываются на жесткий диск, а вызов в случае необходимости нужной страницы данных в память осуществляется гораздо быстрее, чем повторное подключение к сети и посылка запроса. В распоряжении у приложения имеется целый дом, и неиспользуемые вещи можно просто-напросто разместить где-то на чердаке.
Как нами ранее уже обсуждалось, в случае мобильных устройств наблюдается совершенно иная ситуация. Учитывая ограниченность объема доступной памяти и отсутствие вторичных накопителей, которые можно было бы использовать для временного сохранения страниц памяти, разработчики обязаны использовать память и ресурсы весьма осмотрительно. Разработчик мобильного приложения обязательно должен целенаправленно выбрать модель данных, в соответствии с которой будет осуществляться управление хранением данных в памяти и "сборкой мусора". В случае устройств правильная стратегия часто заключается в освобождении памяти от данных или явном их перемещении на карту флэш-памяти и повторном вызове данных в память, когда они вновь потребуются.
Если существует искусство создания замечательных приложений, то умение выбирать наиболее подходящие модели данных является важнейшей его частью. Рациональное управление памятью и ресурсами подразумевает следующее: 1) приобретение навыков экономного расходования памяти и хранения в ней только тех объектов, в которых действительно существует острая необходимость и которые будут немедленно использованы, 2) отыскание способов кэширования важных данных на устройстве, но за пределами активной памяти и 3) перемещение остальных данных на накопитель, находящийся за пределами устройства. Научившись этим трем вещам, вы пройдете значительную часть дистанции, отделяющей вас от создания великолепно функционирующих приложений, работа с которыми будет доставлять удовольствие пользователям.
Выбор коммуникационной модели, а также модели ввода/вывода определяет, каким образом ваше приложение будет связываться с ресурсами вне своего процесса. В качестве таковых могут выступать либо локальные ресурсы устройства, например, хранящиеся на нем файлы и базы данных, либо ресурсы, являющиеся внешними по отношению к физическому устройству, например, такие, доступ к которым осуществляется посредством связи через сокеты, а также файлы на серверах, Web-службы и удаленные базы данных. Выбор способов, используемых приложением для связи как с локальными, так и с удаленными ресурсами оказывает большое влияние на то, как ваше приложение будет воспринято пользователями, и поэтому занимает одно из ведущих мест в списке всего того, что должно быть включено в вашу методологию разработки.
Почти все приложения, способные предоставлять пользователю информацию длительного хранения, обеспечивают эту возможность путем локального сохранения и извлечения такой информации на устройстве.
Рис. 4.4. Проектирование коммуникационной модели, ориентированное на достижение высокой производительности
Наиболее важными факторами, влияющими на работу с локальными данными устройства являются формат данных и уровень абстракции модели программирования, используемой для работы с этими данными.
Формат данных
Вообще говоря, формат, в котором сохраняются данные, выбирается на основе компромисса между требованиями эффективности и удобства использования. Любые конкретные данные могут сохраняться в виде двоичных файлов, простых текстовых файлов, текстовых XML-файлов или в виде структурированных таблиц локальных баз данных. Требования эффективности означают минимизацию размера данных и обеспечение максимально возможной производительности приложения. К числу требований удобства использования относятся максимально возможное повышение производительности труда разработчика, улучшение условий сопровождения кода, минимизация объема необходимого тестирования, обеспечение возможности обмена данными между приложениями и гибкость формата, обеспечивающая возможность его последующего расширения.
Двоичные форматы сохранения данных предлагают самые широкие возможности как в отношении снижения размера данных, так и в отношении повышения производительности приложения. По этой причине данные, характеризующиеся большой плотностью информации, например изображения, чаще всего сохраняются в двоичных форматах. Потребности в сохранения данных изображений настолько специфичны, что для этого имеется целый ряд популярных форматов, каждый из которых предлагает свой вариант достижения компромисса между размером данных, производительностью и точностью передачи изображения. Каждый из двоичных форматов изображений отвечает определенным запросам. Двоичный формат может использоваться для хранения не только изображений, но и любых данных. Однако работать с двоичными данными тяжелее; если вы создаете собственные двоичные форматы, то у вас появятся заботы, связанные с необходимостью учета различий в версиях данных и обеспечением возможности использования этих данных другими приложениями.
Хранение данных в текстовых форматах значительно облегчает их использование и расширяют возможности их переноса в другие приложения, так как декодировать их легче. Однако текстовые файлы имеют расширенные размеры по сравнению с их двоичными аналогами. Размеры XML-файлов оказываются еще большими, чем размеры обычных текстовых файлов, поскольку текстовые данные дополняются в них информацией о схеме данных. Эти дополнительные метаданные схемы значительно повышают гибкость данных в отношении учета их версий и переносимости в другие приложения, но это требует использования дополнительного пространства. Кроме того, при чтении и записи XML-файлов их требуется дополнительно пропускать через синтаксические анализаторы, что усложняет их обработку по сравнению с обычными текстовыми файлами, в которых для разделения данных используются запятые или символы табуляции. Отмеченная гибкость достается за счет дополнительных расходов. Эти дополнительные расходы можно снизить, используя разумные стратегии реализации, но полностью избавиться от них невозможно.
Базы данных предлагают наивысшую степень организации данных, однако привносят с собой дополнительные накладные расходы, связанные с выполнением процессора базы данных.
Уровни абстракции модели программирования
Модели программирования, предназначенные для работы с сохраненными данными, обычно имеют несколько уровней. Так, для работы с файлами в .NET Compact Framework предлагаются следующие уровни абстракции, приведенные в порядке их повышения:
Каждый из перечисленных уровней предлагает все более высокий уровень абстракции для облегчения работы с данными, что связано с соответствующим повышением накладных расходов. В некоторых случаях эти накладные расходы пренебрежимо малы и вполне оправдывают то повышение продуктивности труда разработчика и степени надежности, которое обеспечивают тестированные высокоуровневые API. В других случаях, особенно при работе с большими объемами данных, высокоуровневые абстракции выдвигают такие дополнительные требования к памяти и процедуре разработке, которые являются неприемлемыми. В подобных случаях разработчикам следует переходить на один уровень абстракции ниже в стеке API и попытаться решить возникшие проблемы с использованием более низкоуровневого API, характеризуемого меньшими накладными расходами. Важно уметь оценивать, какие накладные расходы связаны с использованием того или иного уровня абстракции.
Выбор формата хранения данных и модели программирования
Какой формат данных следует использовать для хранения данных – целиком зависит от целей вашего приложения; никакого универсального рецепта здесь не существует. Распространенной ошибкой тех, кто только приступает к разработке программного обеспечения для мобильных устройств, является допущение о том, что, поскольку в этом случае приходится иметь дело с ограниченными ресурсами, следует сразу же переходить на самый низкий уровень абстракции и использовать двоичные файлы вместе с потоковыми операциями файлового ввода/вывода. Иногда такая потребность действительно существует, но в большинстве случаев это просто означает выполнение ненужной работы, которая потребует дополнительного тестирования и, вероятно, приведет к худшему решению, не обеспечивающему достаточной гибкостью. Общее правило заключается в том, чтобы использовать наивысший уровень абстракции, допустимый с точки зрения размера данных и достигаемой при этом производительности. Было бы неразумно изобретать собственный двоичный формат для данных сравнительно небольшого объема, поскольку при средних запросах памяти лучшего варианта, чем XML, не найти. С XML легко работать, он обеспечивает надежную работу с различными версиями данных и для него существует высокоуровневый API, облегчающий программирование. Точно так же, в случае возникновения действительной необходимости в двоичном формате, например, для хранения больших объемов данных, описывающих изображения, гораздо предпочтительнее воспользоваться уже имеющимися и проверенными на практике форматами, если таковые имеются. Поскольку существует целый ряд хорошо зарекомендовавших себя форматов изображений, изобретение собственного формата будет, как правило, напрасной тратой времени. При любой удобной возможности старайтесь использовать уже существующие компоненты и форматы данных; изобретайте свои собственные форматы лишь в тех случаях, когда вы убеждены, что высокоуровневые подходы не сработают.
Кроме самых простых игр и элементарных производственных приложений наподобие калькуляторов, большинство представляющих интерес приложений для мобильных устройств так или иначе взаимодействуют с данными, хранящимися вне устройства. Эти данные могут находиться в базе данных, реплицируемой на устройстве. Они могут содержаться в хранящейся на устройстве адресной книге, синхронизируемой с электронным почтовым сервером. Ими также могут быть изображения или музыкальные файлы, загруженные с Web или настольного компьютера или "принятые" с другого устройства через инфракрасный порт. SMS-сообщения поступают на мобильные телефоны и отсылаются ими. XML- данные передаются Web-службам и принимаются от них. К данным может осуществляться доступ по сети Wi-Fi, передаваться посредством флэш-карты, вставленной в устройство, пересылаться через соединения мобильных телефонов с использованием протокола GRPS, передаваться через инфракрасный порт или просто отсылаться через Ethernet-кабель, подключенный к устройству. Короче говоря, существует множество самых различных типов данных, которыми устройства могут обмениваться, и средств, обеспечивающих передачу этих данных.
Остановив свой выбор на ряде сценариев, выполнение которых будет обеспечивать ваше приложение, проникнувшись решимостью не забывать в процессе разработки приложения о необходимости обеспечения высокой производительности, подготовив прототипы пользовательского интерфейса, который предоставит пользовать возможность взаимодействовать с приложением, вы должны уделить внимание выбору коммуникационной модели.
В процессе выработки коммуникационной модели вы должны обязательно обратиться к подготовленным ранее основным сценариям вашего приложения и определить, какие соединения потребуются для активизации этих сценариев. К числу вопросов, на которые должны быть даны ответы, относятся следующие:
Производительность и надежность
Вы должны исходить из того, что в мобильных сетях соединения часто разрываются, и как правило, это происходит в самый неподходящий момент. Даже если устройство подключено к сети непосредственно через кабель, все равно следует подумать о мерах предосторожности, заранее предполагая, что случиться может все что угодно: сервер может выйти из строя, кабель может порваться, прокси-серверы, трансляторы сетевых адресов, маршрутизаторы и брандмауэры могут внезапно организовать против вас заговор, а эти противные, маленькие злые гномы могут проникнуть в "железо" и атаковать ваши пакеты данных крохотными молоточками, чтобы сбить их с пути истинного к пункту назначения. Разумная доля скептицизма, граничащая с паранойей, сторицей себя окупит. Заблаговременно предполагайте любые мыслимые и немыслимые варианты, лишь бы ваше приложение было надежно защищено, и трезво подходите к реалиям работы в условиях сбойных соединений и возникновения непредсказуемых затруднений.
Большинству из нас приходилось наблюдать, как выполнение приложения на сервере или десктопе на некоторое время приостанавливалось из-за недоступности сетевого ресурса. Обычно такое приложение либо зависает, либо не подает признаков жизни в течение времени, которое кажется вечностью, пока, наконец, не возвратит управление пользователю. В случае мобильных устройств ситуация неизбежно оказывается еще худшей. Поезда заходят в туннели, а двери лифтов захлопываются, в результате чего сигналы, которые до этого были доступными, теперь блокируются, но никаких предупреждающих сообщений об этом выполняющееся мобильное приложение получить не может. Пропадает связь между отдельными ячейками сотовой связи, отключаются базовые станции сетей Wi-Fi, и вообще, иногда бывает так, что что-то просто идет наперекосяк по каким-то необъяснимым причинам.
Надеюсь, я был достаточно убедителен, чтобы вы прониклись уверенностью в необходимости написания соответствующих кодов, защищающих приложение от подобных неприятностей. Существуют способы, которые облегчают решение этой задачи:
Доступ к сетевым ресурсам в невероятной степени расширяет возможности мобильных приложений, но при этом неизбежно привносит в ваше приложение элементы, находящиеся вне вашего контроля. Очень важно, чтобы ваше мобильное приложение могло надежно вести себя в тех весьма реальных ситуациях, когда попытка получения доступа к внешним ресурсам оказывается неудачной или может быть завершена лишь в течение недопустимо длительного времени. Если вы предусмотрите корректную обработку ситуаций подобного рода, то ваше приложение от этого значительно выиграет и будет не только отлично работать, но и лучше восприниматься пользователями. Пользователи будут благодарны вам или, по крайней мере, не будут честить ваше имя при появлении сообщения "отключилась сеть".
Уровни абстракции в программной модели
Как и в случае локальных данных устройства, при работе с сетевыми ресурсами также используется несколько уровней абстракции. Так, в .NET Compact Framework предлагаются следующие уровни API для работы с сетевыми данными:
Каждый из этих уровней, перечисленных в порядке повышения степени абстракции, последовательно предлагает все более удобную и живучую тестированную инфраструктуру. Как и в случае локального обмена данными в устройствах, вы должны выбирать наивысший из приемлемых для вас уровней абстракции и переходить к более низким уровням лишь тогда, когда вы убеждены, что более высокие уровни не в состоянии удовлетворить ваши запросы. Использование более низкоуровневых моделей программирования означает более непосредственный контроль над тем, что происходит, и обеспечивает максимальную гибкость, но это достается за счет увеличения сложности, уменьшения возможностей переноса приложения на другие платформы и необходимости более тщательного тестирования. Вы должны также знать, что даже нижайшие уровни абстракции не предоставят вам возможности полного контроля; ваше приложение всегда должно будет каким-то образом справляться со сбоями в сети, а на низких уровнях абстракции это часто сделать сложнее. Существуют же веские причины того, почему во всех случаях, кроме наиболее специфических низкоуровневых задач, разработчики вместо языка ассемблера используют языки более высокого уровня, и точно те же рассуждения вы должны применять, выбирая коммуникационную модель для своего приложения. Чем выше уровень абстракции, тем лучше почти во всех случаях.
Современная разработка является итеративным процессом. Это особенно справедливо в отношении разработки приложений для мобильных устройств. Основываясь на своей квалификации и опыте, вы принимаете первоначальные решения, которые кажутся вам наилучшими, и при необходимости впоследствии пересматриваете их. Наличие опыта проектирования приложений для мобильных устройств поможет вам принять лучшие решения, но никогда не сделает их идеальными. Всегда вкрадется какая-нибудь непредвиденная проблема, которая вынудит вас заново оценить свой проект и внести в него небольшие уточнения или, как это часто случается, радикальные изменения. Значительное место в оставшейся части книги отводится тому, чтобы научить вас с самого начала принимать наилучшие решения и одновременно привить необходимые технические навыки, которые позволят вам оставить открытыми двери для пересмотра проекта, если это потребуется.
Хороший проект мобильного программного обеспечения обязательно должен предусматривать выявление неизбежно появляющихся проблем уже на самых ранних стадиях проекта и ориентировать на создание кода, обладающего достаточно модульной и гибкой структурой, чтобы при необходимости его можно было перепрограммировать, не рискуя безнадежно запутаться.
Приступив к проектированию и тестированию коммуникационной модели, вы можете обнаружить, что в проекте были допущены значительные просчеты. Может оказаться, что расходуемый объем памяти слишком велик, а это означает, что либо количество данных, одновременно хранящихся в памяти, слишком большое, либо их хранение организовано недостаточно эффективно. Вероятнее всего, изменение модели данных окажет влияние на коммуникационную модель, управляющую тем, как именно будет осуществляться обмен данными с долговременным хранилищем. В свою очередь, внесение изменений в модель данных и коммуникационную модель может повлечь за собой необходимость пересмотра пользовательского интерфейса. Возможно, при внесении этих изменений вам придется учесть тот факт, что количество данных, одновременно находящихся в памяти в любой момент времени, превышает то, которое допускалось ранее, или же что для обеспечения желаемой степени интерактивности пользовательского интерфейса способ извлечения данных должен быть изменен по сравнению с первоначально предполагаемым. Наконец, в процессе всех этих упражнений вы можете обнаружить, что некоторые из целей приложения, предусмотренные проектом, должны быть изменены. Возможен и другой вариант, когда в результате использования и тестирования приложения обнаруживается, что состав его проектных целей должен быть расширен. Современная разработка приложений носит итеративный характер. Поскольку мобильные устройства представляют собой новый и еще не до конца исследованный мир, они потребуют еще большего итерирования.
Рис. 4.5. Пересмотрите предыдущие шаги проекта, если это необходимо для устранения проблем производительности
Когда имеешь дело со всеми этими взаимосвязями между различными стадиями разработки, легко потеряться где-то посередине и начать писать код, значительная часть которого, связывающая отдельные части между собой, будет походить на запутанный клубок спагетти, а необходимые проектные изменения будут выглядеть как заплаты. Вы должны избегать подобного соблазна и использовать собственные контрольные этапы, которые помогут вам сохранить целостность процесса проектирования. Определите явные критерии завершения таких этапов, чтобы процесс проектирования был упорядоченным. Покидая контрольный этап разработки, вы должны дать ответы на следующие вопросы:
В основе всех ваших проектных решений должна лежать философия, которая в качестве главенствующей цели ставит обеспечение высокой производительности. Если какой-либо из пунктов проекта вашего приложения не в состоянии обеспечить выполнение этого требования, прекратите дальнейшее написание кода! Прекратите написание кода! Прекратите написание кода! И сразу же займитесь выяснением того, где находится узкое место производительности и разрешите связанные с этим проблемы, прежде чем двигаться дальше. Это важно на любой стадии проекта, но должно быть обязательным условием на завершающей стадии и на всех контрольных этапах проекта, которые вы для него определили. По мере приближения процесса разработки приложения к своему завершению внесение изменений должно требоваться реже, да и делать это уже будет труднее, поскольку между написанными к этому времени модулями кода установятся различного рода зависимости. Предусмотрите в своих планах, что на ранних стадиях проекта вы будете множество раз возвращаться к критическому пересмотру принятых ранее решений и вносить изменения, тогда как по мере прохождения вашим проектом контрольных этапов и приближения кода к его окончательному виду необходимость в таких изменениях будет постепенно уменьшаться.
В случае мобильных устройств процесс пакетирования и установки приложения часто называют инициализацией (provisioning). Этот шаг должен быть отнесен к категориям, числящимся под рубрикой "последние по порядку, но не менее важные", поскольку, как и все другие шаги, его правильное выполнение также требует применения итеративного подхода. Следует обязательно продумать, какие компоненты должны быть развернуты, чтобы ваше приложение могло выполняться на целевых устройствах, каким образом пользователи должны это выполнять и какие способы будут использоваться впоследствии для обновления приложения. Ниже приведен перечень вопросов, давая ответы на которые вам будет легче выработать стратегию инициализации вашего мобильного приложения:
Из-за того, что существует огромное разнообразие мобильных устройств и разработанных для них сетевых моделей, ни на один из поставленных выше вопросов невозможно дать единственный правильный ответ. Какое решение будет наилучшим, зависит от типа устройства, способа его подключения к сети, опытности его пользователя и политик, при помощи которых сетевые операторы могут контролировать доступ к устройствам.
План инициализации приложения должен записываться на бумаге и добавляться в список ваших сценариев. Также крайне желательно включать разработку и тестирование пакетирования и установки приложения в реальных условиях в состав контрольных этапов ранних стадий проекта приложения. Современные инструментальные среды разработки могут отлично установить ваше приложение на устройство в порядке тестирования, но конечные пользователи при установке приложения вашу среду разработки обычно использовать не будут. Как показывает практика, развертывание приложения конечным пользователем всегда представляет собой проблему.
Как гласит часто цитируемое и освященное веками изречение, "хорошо выполненный посредственный план гораздо лучше превосходного и подробного, который остался нереализованным". Эта истина применима и к разработке современного программного обеспечения. Что толку от того, что у вас имеется разработанный по всем правилам план и методология разработки, если они недостаточно гибки, чтобы их можно было приспособить к реалиям итеративного характера приближения к конечному результату. "Для различных проектов разработки требуются различные уровни строгости и опыта" – вот лучшее руководство к пониманию того, какая степень формализации допустима для процесса разработки, чтобы это принесло только пользу. Кроме того, всегда следует быть готовым к любым неожиданностям. По мере того как вы будете разрабатывать и тестировать свое приложение, обязательно будут выявляться факторы, которые вынудят вас заметно менять свои планы. Всегда учитывайте это и организуйте процесс разработки таким образом, чтобы он позволял справляться с подобными ситуациями. Итак, в хронологическом порядке:
| Сообщений 0 Оценка 15
[+0/-1]
Оценить
|
