Читайте также: |
|
Объектно-ориентированная разработка программной системы основана на стиле, называемом проектированием от данных. Проектирование системы сводится к поиску абстракций данных, подходящих для конкретной задачи. Каждая из таких абстракций реализуется в виде класса, которые и становятся модулями — архитектурными единицами построения системы.
В хорошо спроектированной системе каждый класс играет и роль модуля, и роль типа данных. Каждый модуль системы имеет вполне определенную смысловую нагрузку.
Типичная ошибка — рассматривать класс только как архитектурную единицу, объединяя под обложкой класса разнородные поля и функции, после чего становится неясным, какой же тип данных задает этот класс.
Процесс разработки программного обеспечения с использованием ООП включает четыре этапа.
1. Анализ. Его цель — максимально полное описание задачи. На этом этапе выполняется анализ предметной области задачи, производится объектная декомпозиция разрабатываемой системы и определяются важнейшие особенности поведения объектов (описание абстракций).
Решение задачи должно быть представлено в виде результата взаимодействия отдельных функциональных элементов некоторой системы, имитирующего процессы, происходящие в предметной области. Каждый функциональный элемент, получив входное воздействие (сообщение), должен выполнять заранее определенные действия. Процессом решения задачи управляет последовательность сообщений.
Функциональные элементы системы, обладающие самостоятельным поведением (т.е. «умеющие» выполнять некоторые действия, зависящие от полученных сообщений и текущего состояния), реализуются с помощью объектов. Процесс представления предметной области в виде совокупности объектов, обменивающихся сообщениями, называется объектной декомпозицией. Основные рекомендации по ее выполнению следующие:
1. Для сложных систем объектная декомпозиция должна выполняться поэтапно: на первом этапе декомпозируется вся система, на последующих этапах — ее объекты как подсистемы.
2. При декомпозиции системы в целом в качестве объектов могут выделяться элементы двух типов:
· элементы интерфейса пользователя;
· средства хранения, организации и преобразования данных.
При этом для каждого объекта должно определяться множество получаемых и передаваемых сообщений и его основные характеристики.
3. Процесс декомпозиции прекращается при получении объектов, которые могут быть достаточно просто реализованы, т. е. имеют четко определенную структуру и поведение.
При выполнении объектной декомпозиции между объектами устанавливаются отношения двух типов.
1. Отношение использования. В этом случае один объект передает сообщение другому, причем объект, инициирующий сообщение, называется активным, а объект, получающий сообщение — пассивным.
Отношение использования может принимать форму воздействия (активный объект воздействует на пассивный объект, передавая ему сообщение), исполнения (пассивный объект исполняет указание активного объекта) и посредничества (некоторый объект-посредник, получив сообщение от активного объекта, передает его пассивному объекту).
2. Отношение включения. Если объект является результатом декомпозиции более сложного объекта, то говорят, что между ними существует отношение включения: первый объект включает второй (иерархия «целое-часть»).
По результатам анализа разрабатывается структурная схема программного продукта, на которой показываются основные объекты и сообщения, передаваемые между ними, а также выполняется описание абстракций.
2. Проектирование. Оно делится на два этапа.
1. На этапе логического проектирования принимаемые решения практически не зависят от условий эксплуатации (операционной системы и используемого оборудования). Логическое проектирование заключается в разработке структуры классов (определяются поля для хранения состояния объектов и алгоритмы методов, реализующих аспекты поведения объектов). Результатом является иерархия или диаграмма классов, отражающая их взаимосвязь, и описание классов.
2. На этапе физического проектирования принимаются во внимание условия эксплуатации. Выполняются объединение описаний классов в модули, выбор схемы их подключения (статическая или динамическая компоновка), определение способов взаимодействия с оборудованием, с операционной системой и другим программным обеспечением (например, базами данных, сетевыми программами), обеспечение синхронизации процессов для систем параллельной обработки и т.д.
3. Эволюция системы. Это процесс поэтапной реализации и подключения классов к проекту. Он начинается с создания основной программы или проекта будущего программного продукта. После этого реализуются и подключаются классы так, чтобы создать грубый, но, по возможности, работающий прототип будущей системы, который тестируется и отлаживается.
4. Модификация. Это процесс добавления новых функциональных возможностей или изменение существующих свойств системы. Как правило, изменения должны затрагивать реализацию класса, оставляя без изменения его интерфейс (что при использовании ООП обычно обходится без особых неприятностей, так как изменяется внутренняя область классов). Изменение интерфейса также становится не очень сложной задачей, хотя ее решение может повлечь за собой необходимость согласования процессов взаимодействия объектов, что потребует изменений в других классах программы. Однако сокращение количества параметров в интерфейсной части по сравнению с модульным программированием существенно облегчает и этот процесс.
Простота модификации позволяет сравнительно легко адаптировать программные системы к изменяющимся условиям эксплуатации, что увеличивает время жизни систем, на разработку которых затрачиваются огромные временные и материальные ресурсы.
Особенностью ООП является то, что объект или группа объектов могут разрабатываться отдельно, и, следовательно, их проектирование может находиться на различных этапах (например, интерфейсные классы уже реализованы, а структура классов предметной области еще только уточняется). Обычно проектирование начинается, когда какой-либо фрагмент предметной области достаточно полно описан в процессе анализа.
Дата добавления: 2015-07-25; просмотров: 184 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Состав класса, его размер должен определяться не архитектурными соображениями, а той абстракцией данных, которую должен реализовать класс. | | | Обработка исключительных ситуаций |