Платформа J2Me
Шрифт:
Сбор требований — указание новых требований и детализирование существующих требований.
Построение архитектуры — описание разработки системы.
Разработка — например, объектно-ориентированный анализ и проектирование.
Реализация — создание работающей системы с некоторым увеличивающимся набором функциональных возможностей.
Тестирование — тестирование функциональной возможности, встроенной на данном этапе.
Отладка — выявление, локализация
SunTone AM объединяет эти этапы в повторяемые циклы, каждый раз улучшая свою реализацию до тех пор, пока все требования не будут соблюдены. Например, при разработке IMAP-почтового клиента для платформы MIDP разработчик может понять, что определенную архитектуру нелегко реализовать из-за ограничений доступных библиотек. Разработчик понимает это после прохождения через'первый цикл вышеуказанных этапов разработки. После завершения первоначального прототипа становится ясно, что некоторую часть логической схемы сложно реализовать.
Второй этап начинается с повторной попытки сбора требований. Разработчик вновь исследует требования для того, чтобы лучше их понять или чтобы определить, нужны ли на самом деле определенные свойства или могут ли быть переопределены сценарии, определяющие модель использования определенных свойств. Дальше следует второй цикл создания архитектуры, разработки, создания прототипа и так далее через все этапы процесса.
Основная проблема процесса разработки заключается в том, чтобы определять в конце каждого цикла, отвечает ли система всем указанным требованиям в достаточной мере. Если нет, необходим еще один цикл. Сила итеративной разработки заключается в возможности для разработчиков создавать системы, которые отвечают всем требованиям эффективнейшим образом.
Ключевым моментом этой эффективности является понятие создания прототипов отдельных функциональных возможностей системы в каждом цикле. Эта философия отличается от традиционного «водопадного» подхода к разработке программного обеспечения. Например, при разработке нашего почтового клиента MIDP первый этап должен быть связан с созданием базовых свойств, присутствие которых обязательно для всех остальных свойств, таких, как вход пользователя в систему и выборка почтовых заголовков и сообщений. Если тестирование выявило, что эта базовая инфраструктура не работает, разработчики узнают об этом в самом начале разработки и смогут исправить это до того, как решатся углубиться дальше и создадут дополнительные свойства на треснувшем фундаменте. Более того, этот подход позволяет избежать комплексной интеграции массы свойств в конце одного цикла разработки, когда становится намного сложнее локализовать и исправить причину проблемы.
Определение того, отвечает ли прототип указанному набору требований, является центральным для любой архитектурной методологии или разработки. Поэтому указание полного набора требований является важной частью любого процесса разработки. В следующем списке содержится две категории требований:
— функциональные требования охватывают функциональные возможности приложения и его логическое действие;
— нефункциональные требования описывают системные характеристики или качества системы.
Вторая категория в данном списке представляет собой требования, которые определяют уровень производительности, расширяемости, безопасности, восстановимости, доступности системы и так далее.
Одним из краеугольных камней SunTone AM, который отличает ее от других методологий, является ее сконцентрированность на системных качествах. Важным критерием при оценке отличия хорошей архитектуры от сомнительной является определение того, насколько хорошо она поддерживает системные качества, определяемые требованиями. Конечно, чтобы создать всеобъемлющую архитектуру, разработчик должен взглянуть на систему со всех ракурсов.
SunTone AM определяет три измерения — ярус, уровень и системное качество — каждое из которых представляет собой уникальный взгляд на систему. Эти измерения поддерживают разбиение системы на ортогональные срезы, которые отражают соблюдение системой различных категорий требований.
В этой главе не описываются понятия ярусов и уровней, такое описание уведет слишком далеко в рассмотрение того, что такое архитектура и как ее осуществлять, и подходит больше для обучения тому, как разрабатывать многоярусные системы. Большая часть этой главы посвящена освещению архитектурных принципов для того, чтобы помочь перенести понятия на реальные системы и понять их характеристики.
Эта глава сконцентрирована на понятиях, связанных с системными качествами, поскольку это то, что наиболее часто упускается, и поскольку системные качества очень важны для достижения производительности, безопасности и массового распространения в средах беспроводного Интернета.
В контексте системной архитектуры системные качества включают следующие категории:
— качества пользовательского уровня — практичность, доступность;
— качества уровня служб — производительность, надежность, доступность;
— качества стратегического уровня — расширяемость, гибкость;
— качества системного уровня — безопасность, управляемость, восстанавливаемость.
Проектирование с учетом системных качеств жизненно важно для успешной работы любой системы. Ваш почтовый клиент MIDP может вести себя прекрасно с логической и функциональной точек зрения, но если его производительность недопустима, он станет непригодным.
Центральным принципом SunTone AM является необходимость обращения к системным качествам с начального этапа проектирования архитектуры и разработки. Нереально ожидать, что вы будете способны изменить или перепроектировать ваши приложения в конце их цикла разработки для приспособления к системным качествам. Статистика индустрии поддерживает мысль о том, что большинство усилий, которые прилагаются для реализации соответствия системным качествам в самом конце процесса разработки, оказываются уже напрасными.
Качества пользовательского уровня. Качества пользовательского уровня включают практичность и доступность. Практичность — это измерение того, насколько интуитивно и просто использование приложения. Разработка пользовательского интерфейса должна быть приспособлена к пожеланиям пользователя. Разработка, поддерживающая пользовательский интерфейс, должна стоять на втором месте. Эта задача скорее всего возникнет в приложениях MIDP, поскольку пользовательский интерфейс MIDP ставит перед разработчиками задачу создания коммерчески рентабельных пользовательских интерфейсов. Разработчикам, возможно, придется пойти на компромисс в свойствах после экспериментирования с тем, насколько легко поддерживать интуитивный, практичный интерфейс.