КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Подход к проектированию программ в целомСтр 1 из 14Следующая ⇒ Практическая работа №12. Диаграмма классов
Цель: Изучение объектно-ориентированного подхода к проектированию приложений. Задача: Следуя принципам объектно-ориентированного подхода, спроектировать иерархию DOM и построить диаграмму классов. Теоретическая часть. Основные сведения о базовых элементах диаграммы классов и связях между ними см. лекцию «Диаграмма классов». Этапы объектно-ориентированного подхода к разработке ПО: Объектно-ориентированный анализ (analysis) - способ анализа, изучающий требования к системе с точки зрения будущих классов и объектов, основываясь на словаре предметной области. Объектно-ориентированное проектирование (design) - способ проектирования, включающий в себя описание процесса объектно-ориентированной декомпозиции и объектно-ориентированную нотацию для описания различных моделей системы (логической и физической, статической и динамической). Объектно-ориентированное программирование - это метод реализации, в основе которого лежит идея представления программной системы в виде набора взаимодействующих объектов, каждый из которых является экземпляром некоторого класса, а классы объединены в иерархию наследования. Порядок их применения таков: сначала проводится объектно-ориентированный анализ, затем проектирование, а после этого - реализация (то есть программирование). Цели проведения анализа · A1 Понять проблему или проблемы, которые программная (или иная) система должна решить. · A2 Задать значимые вопросы о проблеме и о системе. · A3 Обеспечить основу для ответов на вопросы о специфических свойствах проблемы и системы. · A4 Определить, что система должна делать. · A5 Определить, что система не должна делать. · A6 Убедиться, что система удовлетворит потребности ее пользователей и определить критерии ее приемки. Это особенно важно, когда система разработана по контракту для внешнего клиента. · A7 Обеспечить основу для разработки системы Подход к проектированию программ в целом ООП ориентировано на разработку крупных программных комплексов, разрабатываемых командой программистов (возможно, достаточно большой). Проектирование системы в целом, создание отдельных компонент и их объединение в конечный продукт при этом часто выполняется разными людьми, и нет ни одного специалиста, который знал бы о проекте всё. Объектно-ориентированное проектирование основывается на описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса: · Из каких частей состоит система. · В чём состоит ответственность каждой из частей. Выделение частей производится таким образом, чтобы каждая имела минимальный по объёму и точно определённый набор выполняемых функций (обязанностей), и при этом взаимодействовала с другими частями как можно меньше. Дальнейшее уточнение приводит к выделению более мелких фрагментов описания. По мере детализации описания и определения ответственности выявляются данные, которые необходимо хранить, наличие близких по поведению агентов, которые становятся кандидатами на реализацию в виде классов с общими предками. После выделения компонентов и определения интерфейсов между ними реализация каждого компонента может проводиться практически независимо от остальных (разумеется, при соблюдении соответствующей технологической дисциплины). Большое значение имеет правильное построение иерархии классов. Одна из известных проблем больших систем, построенных по ООП-технологии — так называемая проблема хрупкости базового класса. Она состоит в том, что на поздних этапах разработки, когда иерархия классов построена и на её основе разработано большое количество кода, оказывается трудно или даже невозможно внести какие-либо изменения в код базовых классов иерархии (от которых порождены все или многие работающие в системе классы). Даже если вносимые изменения не затронут интерфейс базового класса, изменение его поведения может непредсказуемым образом отразиться на классах-потомках. В случае крупной системы разработчик базового класса не просто не в состоянии предугадать последствия изменений, он даже не знает о том, как именно базовый класс используется и от каких особенностей его поведения зависит корректность работы классов-потомков. Рекомендации:
|