4.1.3. Методология ооап
Разработка масштабных проектов обусловила анализ предметной области до начала написания программы. При проектировании базы данных, в отличие от решения вычислительных задач, нужна предварительная разработка концептуальной схемы для отражения взаимосвязей предметной области и особенностей организации информации. При этом предметная предметная область включает объекты и взаимосвязи, нужные для описания требований и условий решения задачи.
Сложность выделения исходных или базовых компонент предметной области проявляется в неформальности процедур или правил, применяемых для этой цели. Эта работа выполняется совместно с экспертами в предметной области. Для концептуализации предметной области (выделения или идентификации ее компонент) предметной области применяют несколько правил и способов.. На начальном этапе концептуализации популярны т.н. CRC-карточки (Component, Responsibility, Collaborator- компонента, обязанность, сотрудники). Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рисунок. 4.1.4), где компонента - абстрактная единица с функциональностью, связанной с решением поставленных задач.
Рисунок 4.1.4. CRC-карточка для описания компонент предметной области.
Жизненный цикл (ЖЦ) программы - совокупность взаимосвязанных этапов от разработки требований к ней до полного отказа от ее использования. Обычно считают ЖЦ программы состоящим из следующих этапов:
Анализ предметной области и формулировка требований к программе.
Проектирование структуры программы.
Реализация программы в кодах (собственно программирование).
Внедрение программы.
Сопровождение программы.
Отказ от использования программы.
При анализе предметной области и .формулировке требований определяются функци разрабатываемой программы, и концептуализируется предметная область. Это работа аналитиков и специалистов предметной области, а в результате появляется концептуальная схема с описанием основных компонент и выполняемых ими функций.
При проектировании структуры программы создается детальная схема программы; на ней указывают классы с их свойствами и методами и взаимосвязи между ними. На этом этапе в работе участвуют аналитики, архитекторы и некоторые программисты. Результат - детализированная схема программы с указанием классов и их функциональных взаимосвязей. Такая схема дает исходные данные для написания программного кода.
Инструменты быстрой разработки приложений (Rapid Application Development, RAD) значительно сокращают затраты и время на выполнение этого традиционного этапа, а его результатом является программное приложение с требуемой функциональностью, способное решать задачи предметной области.
Внедрение и сопровождение программы требуют настройки и конфигурирования среды программы, а также устранения выявленных при ее использовании ошибок. Иногда отдельным этапом считают тестирование программы, т.е. проверку работоспособности программы на ряде совокупностей исходных данных и при особых режимах эксплуатации. В результате растет надежность программного приложения, исключаются критические ситуации и ущерба пользователям приложения.
Развитие методологии ООАП автоматизировало второй, а потом и первый этапыы ЖЦ программы, что перестало сдерживать разработку приложений. ООАП тесно связаны с методами автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД), и визуализация разработки концептуальной схемы БД не могла решить проблем разработки приложений иных типов. Кроме того, у языков программирования строгий синтаксис, а создание однозначной графической нотации CASE-средств было затруднено. Вот почему создание унифицированного языка моделирования (Unified Modeling Language, UML) оказалось весьма востребованным.