Структуры архитектуры
Структура архитектуры — это базовая теоретическая структура, которая поддерживает определение архитектурной модели. Реальные архитектурные методологии описывают свои собственные структуры, поддерживающие определение элементов методологии, а именно, тех, что описывают архитектурные процессы, определение видов системы и артефактов, которые представляют собой конкретное определение разработки системы.
SunTone AM предлагает структуру, чьи основные характеристики включают:
— сконцентрированная на случаях использования — подчеркивает, что начинать надо со сбора требований;
— итеративная — многократное развертывание системы с помощью повторного прохождения по циклу разработки, который включает все фазы разработки;
— управляемая системными качествами — обращение к системным качествам на всех этапах разработки;
— архитектурно-ориентированная — твердая приверженность архитектурным принципам;
— базирующаяся на примерах — применение при решении задач проектирования образцов, которые на практике доказали, что являются решениями общераспространенных проблем.
Далее последует краткое описание этих принципов с целью мотивировать вас на выполнение построения архитектуры в качестве первого этапа процесса разработки. Определяя описание системы посредством архитектуры, разработчики и создатели могут создавать высококачественные системы, которые более точно соответствуют изначально изложенным системным требованиям. Построение архитектуры помогает разработчикам создавать более надежные, безотказные, функциональные системы, которые являются более ценными для разработчиков и пользователей.
Полное описание или объяснение даже одного из этих принципов лежит за пределами возможностей данной книги. Краткое описание, предоставляемое здесь, тем не менее, предназначено для ознакомления вас с понятиями, связанными с этими архитектурными принципами, и дает вам, разработчику приложений J2ME, понятие о том, как получить преимущества от искусства и науки построения архитектуры. Для более тесного знакомства с архитектурой и архитектурной методологией SunTone AM смотрите книгу "Dot-Corn & Beyond".
Первый элемент структуры SunTone AM, случай использования, — это описание системного требования. Случаи использования собирают и документируют системные требования в читабельной для человека форме. Невозможно преувеличить значение того, что разработка будет отвечать требованиям системы. Процесс сбора требований является деятельностью, дополняющей построение архитектуры. Существует несколько хороших книг, которые объясняют случаи использования в полном объеме, такие, как книга Элистера Кокбарна (Alistair Cockburn) «Writing Effective Use Cases», которая указана в разделе «Справочная литература» в конце данной книги.
Как правило, невозможно собрать все системные требования в достаточном объеме с первого раза. По этой причине SunTone AM подчеркивает важность выполнения итеративного сбора требований. Так как понятие системы развивается вместе с приобретаемым в процессе ее создания опытом разработчиков, маркетингового персонала и других работников, требования расширяются или становятся более четко очерченными и их описания могут быть заданы более точно.
Принцип итеративной разработки применяется на каждом этапе процесса разработки, а не только при сборе требований. Итеративная разработка связана с идеей выполнения нескольких повторений всего цикла разработки. Причина включения всех этапов в процесс итеративной разработки заключается просто в том, что сложно реализовать что-либо правильно в первый раз. Цикл разработки включает следующие этапы:
Сбор требований — указание новых требований и детализирование существующих требований.
Построение архитектуры — описание разработки системы.
Разработка — например, объектно-ориентированный анализ и проектирование.
Реализация — создание работающей системы с некоторым увеличивающимся набором функциональных возможностей.
Тестирование — тестирование функциональной возможности, встроенной на данном этапе.
Отладка — выявление, локализация и исправление ошибок.
SunTone AM объединяет эти этапы в повторяемые циклы, каждый раз улучшая свою реализацию до тех пор, пока все требования не будут соблюдены. Например, при разработке IMAP-почтового клиента для платформы MIDP разработчик может понять, что определенную архитектуру нелегко реализовать из-за ограничений доступных библиотек. Разработчик понимает это после прохождения через'первый цикл вышеуказанных этапов разработки. После завершения первоначального прототипа становится ясно, что некоторую часть логической схемы сложно реализовать.
Читать дальше