Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 4
Текст из файла (страница 4)
Оба подкласса наследуют черты класса Ылггогв (например, наличие видимой области на экране). 5сгойлйЫлЫогс добавляет полосу прокрутки и смещение. Возможность выделять общие черты нескольких классов в суперкласс значительно сокращает количество повторений в проектах и программах и является одним из основных достоинств объектно-ориентированной технологии. Полиморфизм (ро1ушогрЬ|зш) означает, что одна и та же операция может подразумевать разное поведение в разных классах.
Например, в шахматах операция ход для пешки и для ферзя характеризуется разньгм поведением. Операция (орегайоп) — это процедура или трансформация, которую объект выполняет сам или которая осуществляется с данным объектом. Примерами операций являются выравниваниеВлраво, отображение и хад. Реализация операции в конкретном классе называется методам (щегЬод). Поскольку объектно-ориентированная операция является полиморфной, в разных классах объектов она может быть реализована разными методами. В реальном мире операция является абстрагированием похожего поведения у объектов одного рода.
Каждый объект «сам знает», как выполнить свои собственные операции. В объектно-ориентированных языках программирования выбор подходящего метода для реализации операции осуществляется автоматически, исходя из имени операции и класса объекта, к которому она относится. Клиенту операции нет необходимости знать о том, сколько еще методов могут реализовывать данную полиморфическую операцию. Разработчики могут добавлять новьге классы, не меняя существующий код, при условии, что они предоставляют методы для каждой возможной операции.
Объекты-велосипеды дФг Класс Велосипед Атрибуты размер рамы размер колес количество передач материал Операции переключать двигаться чинить Объекты-многоугольники Класс Многоугольник Атрибуты вершины цвет границы ~ Ю прорисовать стереть переместить Рис.
1.2. Обьекты и классьс каждый класс описывает множество индивидуальных обьектов 20 Глава 1 ° Введение 1.2. Объектно-ориентированная разработка Эта книга посвящена объектно-ориентированной разработке программного обеспечения как способу мышления, основанному на абстракциях, существующих как в реальном мире, так и в программах. В этом контексте разработка (грече!оршепг) обозначает жизненный цикл программного обеспечения: анализ, проектирование и реализацию. Целью объектно-ориентированной разработки является идентификация и упорядочение концепций приложения, а не окончательная реализация на языке программирования.
Брукс заключает, что наиболее сложной частью разработки программного обеспечения является работа с его сущностью (еззепсе), а не акциденцией (асс1депгз) отображения этой сущности в конкретный язык программирования ) Вгоо)гз-951 Наша книга не содержит непосредственного описания проблем, связанных с интеграцией, обслуживанием н усовершенствованием программного обеспечения. Однако ясный проект в четкой системе обозначений упрошает все этапы жизненного цикла программного обеспечения.
Объектно-ориентированные концепции и система обозначений, используемые для выражения проекта, также оказываются полезными при написании документации. 1.2.1. Моделирование концепций, а не реализации В прошлом объектно-ориентированное сообшество занималось, главным образом, языками программирования. В литературе исследовались вопросы реализации, а не анализа и проектирования. Объектно-ориентированные языки программирования были полезны тем, что они обладали гибкостью, нехарактерной для традиционных языков программирования.
Однако для технологий разработки программного обеспечения это был шаг назад, поскольку все внимание уделялось механизмам реализации, а не лежащим в основе мыслительным процессам. Гораздо большего выигрыша можно достичь, если сосредоточиться на концептуальных вопросах переднего плана, а не на деталях реализации. Недостатки проекта, всплываюшие в процессе реализации, стоят дороже, чем те, которые обнаруживаются раньше. Слишком ранний переход к реализации ограничивает возможные варианты представления проекта, а потому часто приводит к снижению качества продукта. Объектно-ориентированный подхол к разработке поошряет разработчиков работать и мыслить в терминах приложения на протяжении всего жизненного никла программного продукта. Эффективное решение проблем, связанных со структурами данных и функциями, может быть осуществлено только после идентификации, упорядочения и постижения внутренних концепций приложения.
Объектно-ориентированная разработка — это концептуальный процесс, независимый от языка программирования, по крайней мере, до последних этапов. Фактически это образ мышления, а не методика программирования. Главное преимущество объектной ориентированности состоит в том, что она помогает тем, кто 1.2. Объектно-ориентированная разработка 21 пишет спецификации, разработчикам и заказчикам ясно выражать абстрактные концепции и обсуждать их друг с другом. Таким образом облегчается составление спецификаций, анализ, документирование и определение интерфейсов и, конечно же, программирование.
1.2.2. Объектно-ориентированная методология В этом разделе мы опишем процесс объектно-ориентированной разработки и системы графических обозначений для объектно-ориентированных концепций. Процесс состоит из построения модели приложения и последующей ее детализации. Одна и та же система обозначений используется на всем протяжении процесса разработки, начиная с анализа и заканчивая проектированием и реализацией.
Информация, добавленная на одном из этапов, не будет утеряна или даже преобразована при переходе к следующему этапу. Описываемая методология включает следующие этапы. 1. Концептуализация системы. Разработка программного обеспечения начинается с бизнес-аналитиков или пользователей, которые придумывают приложение и формулируют первичные требования к нему. 2. Анализ. Аналитик тьчательно исследует и безжалостно переформулирует требования, конструируя модели, исходя из концепций системы. Аналитик должен работать с заказчиком, чтобы добиться понимания задачи, потому что формулировки редко оказываются полными или корректными. Аналитическая модель — это сжатая и точная абстракция того, что именно должна делать система (а не то, каким образом это будет сделано).
Аналитическая модель не должна содержать никаких решений относительно реализации. Например, класс Ж(пдое в аналитической модели системы управления окнами для рабочей станции должен быть описан в терминах видимых атрибутов и операций. Аналитическая модель состоит из двух частей: модели предметной области (доша1п пюде1) — описания объектов реального мира, отражаемых системой, и модели приложения (арр!гсаВоп шоде1) — описания видимых пользователю частей самого приложения. Например, для приложения биржевого маклера объектами предметной области могут быть акции, облигации, торги и комиссия. Объекты модели приложения могут управлять выполнением торгов и отображать результаты.
Хорошая модель должна быть доступной для понимания и критики со стороны экспертов, не являющихся программистами. 3. Проектирование системы. Команда разработчиков продумывает стратегию решения задачи на высшем уровне, определяя архитектуру системы (зузсеш агсй(гесгцге). На этом этапе определяются политики, которые послужат основой для принятия решений на следующих этапах проектирования. Проектировщик системы должен выбрать параметры системы, по которым будет проводиться оптимизация, предложить стратегический 22 Глава 1 ° Введение подход к задаче, провести предварительное распределение ресурсов. Например, проектировщик может решить, что любые изменения изображения на экране рабочей станции должны быть быстрыми и плавными, даже при перемещении и закрытии окон.
На основании этого решения он может выбрать подходящий протокол обмена и стратегию буферизации памяти. 4. Проектирование классов. Проектировщик классов уточняет аналитическую модель в соответствии со стратегией проектирования системы. Он прорабатывает объекты предметной области и объекты модели приложения, используя одинаковые объектно-ориентированные концепции и обозначения, несмотря на то, что эти объекты лежат в разных концептуальных плоскостях.
Цель проектирования классов состоит в том, чтобы определить, какие структуры данных и алгоритмы требуются для реализации каждого класса. Например, проектировщик классов должен выбрать структуры данных и алгоритмы для всех операций класса ИЪЫо~е. 5. Реализация. Ответственные за реализацию занимаются переводом классов и отношений, образовавшихся на предыдущем этапе, на конкретный язык программирования, воплощением их в базе данных или в аппаратном обеспечении.
Никаких усложнений на этом этапе быть не должно, потому что все ответственные решения уже были приняты на предыдущих этапах. В процессе реализации необходимо использовать технологии разработки программного обеспечения, чтобы соответствие кода проекту было очевидным, а система оставалась гибкой и расширяемой. В нашем примере группа реализации должна написать код класса йгшйош на каком-либо языке программирования, используя вызовы функций или методов графической подсистемы рабочей станции.
Объектно-ориентированные концепции действуют на протяжении всего жизненного цикла программного обеспечения, на этапах анализа, проектирования и реализации. Одни и те же классы будут переходить от одного этапа к другому без всяких изменений в нотации, хотя на последних этапах они существенно обрастут деталями. В нашем примере модели класса аллою, созданные на этапе анализа и на этапе реализации, являются корректными, но они служат разным целям, а потом отражают разные уровни абстракции.
Концепции индивидуальности, классификации, полиморфизма и наследования действуют на протяжении всего процесса разработки. Обратите внимание, что мы не предполагаем обязательного использования водопадного процесса разработки (составление требований, анализ, проектирование, реализация). Для каждой конкретной части системы этапы проектирования должны выполняться в указанном выше порядке, но это не значит, что части системы обязательно должны создаваться последовательно.
Мы поддерживаем итерационный процесс разработки; составляющая часть системы разрабатывается в несколько этапов, после чего к ней добавляются новые возможности. 1.2. Объектно-ориентированная разработка 23 Некоторые классы не входят в аналитическую модель. Они появляются позднее, на этапах проектирования или реализации. Например, структуры данных, подобные деревьям, хэш-таблицам и связным спискам, редко появляются в реальном мире и обычно невидимы пользователям. Проектировщики добавляют их в систему для того, чтобы обеспечить поддержку выбранных алгоритмов. Объекты структур данных существуют внутри компьютера и не являются непосредственно наблюдаемыми.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
