Задачи и особенности объектно-ориентированного проектирования программных средств

Лекция 8. Объектно-ориентированное проектирование программных средств

Построение государственных геодезических сетей методом поли-гонометрии и трилатерации

На узких участках местности триангуляция 1-го класса может заме-

няться полигонометрическими ходами 1-го класса. Звено полигонометрии

1-го класса, его длина состовляет приблизительно 200 км.

класса, его длина составляет приблизительно 200 км, состоит из 8-10

сторон длиной от 20 до 25 км, на концах звена определяют пункты Лапла-

са. Звено полигонометрии 2-го класса опирается на звено 1-го класса и

имеет не более двух точек поворота хода. Длины сторон составляют не менее 2 км.

Звено полигонометрии 3-го класса опирается на звено 2-го класса

и имеет не более двух точек поворота хода. Звено полигонометрии 4-го класса опирается на звено 3-го класса и имеет не более двух точек поворота хода. Длины сторон состовляет не менее 2 км.

Полигонометрические сети по точности равнозначны триангуляционными

сетям, но имеют недостатки:

а) слабый контроль результатов измерений длин линий и углов;

б) полигонометрическим ходом обеспечена узкая полоса местности;

в) сложнее развитие съёмочного обоснования.

Измерение длин линий полигонометрических ходов выполняется светодальномером.

Построение государственной геодезической сети методом трилатерации -

так же, и как и построение триангуляции.

Отличие: при триангуляции в построенных треугольниках измеряются

теодолитом углы, а при трилатерации измеряются длины сторон треугольников светодальномером. Метод трилатерации используют в малообжитых и труднодоступных районах.

Контрольные вопросы:

1. Назначение и классификация геодезических сетей.

2.Схема построения плановых геодезических сетей сгущения.

3.Построение государственных геодезических сетей методом триангуляции.

Литература:

1. Дьяков Б. Н. Геодезия. Общий курс: учеб. пособие дл я

2. вузов. − Новосибирск: Изд. НГ У, 1993. − 169 с.

3. 4Дьяков Б. Н. Геодезия. Общий курс. Новосибирск:

4. СГ Г А, 1997. 173 с.

5. Инженерная геодезия. Учеб. для вузов / К л ю ш ин Е. Б.,

6. Киселев М. И., Мих е л е в Д. Ш., Ф е л ь д м а н Е. Д.: П од

ред. Мих е л е в а Д. Ш. − 2-е изд. испр. − М.: Высш. ш к.,

2001. − 464 с.: ил.

7. Инструкция по топосъемкам масштабов 1: 5000 – 1: 500

− М.: Недра, 1973. с.

8. Кузнецов П. Н. Г еодезия. Ч. 1. М.:, 2002. с.

9. Маслов А. В. и др. Г еодезия / Ма с л ов А. В., Л а р ч е н к о Е.

10. Г., Гор д е е в А. В., Ал е к с а н д р ов Н. Н. Ч. 1. – М.:

Издател ьство геодезич еской л итерату ры, 1958. 512 с.

11. Маслов А. В. Г еодезия. Ч. 1. М.: Недра, 1980.

Маслов А. В., Юнусов А. Г.Ю Горохов Г. И

Международные стандарты программной инженерии (Приложение 1), регламентируют жизненный цикл программных средств широкого класса в различных областях их применения. Они ориентированы в основном на структурное проектирование и разработку процессов, функций и данных в различных комплексах программ, в которых доминируют сложные алгоритмы обработки, относительно небольшой совокупности данных. Объектно-ориентированное проектирование (ООП) предназначено организовывать программные системы с большими базами данных на основе описаний объектов реального мира, важных для пользователей. Этот подход существенно отличается от структурного проектирования, которое акцентировано на сложные функции и процессы обработки данных. Объекты реального мира, существующие внутри области действия ООП программных проектов, определяются в терминах целей, характеристик и ответственностей поведения соответствующих данных (атрибутов) и отношений с другими многочисленными объектами. Все функции при этом скрыты внутри деталей описаний объекта.

Объектно-ориентированное проектирование представляет собой стратегию, в рамках которой программная система состоит из взаимодействующих объектов, имеющих собственное локальное состояние и способных выполнять определенный набор операций, определяемый состоянием объекта. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Под процессом ООП подразумевается проектирование классов объектов и взаимоотношений между этими классами. Объектно-ориентированные системы можно рассматривать как совокупность автономных и в определенной степени независимых объектов. Изменение реализации какого-нибудь объекта или добавление новых функций не влияет на другие объекты системы.

Общий процесс объектно-ориентированного проектирования состоит из нескольких крупных этапов:

- определение рабочего окружения системы и разработка моделей её использования;

- проектирование архитектуры программной системы;

- определение и идентификация основных объектов системы;

- разработка модели архитектуры комплекса программ;

- определение и документирование интерфейсов объектов.

Процесс ООП нельзя представить в виде простой схемы (как при структурном проектировании), в которой предполагается четкая последовательность этапов. Фактически все перечисленные этапы в значительной мере можно выполнять параллельно, с учетом взаимного влияния друг на друга. Как только разработана архитектура системы, определяются объекты и интерфейсы. После создания моделей объектов отдельные объекты можно переопределить, а это может привести к изменениям в архитектуре системы.

Главное преимущество ООП программных средств состоит в том, что оно упрощает задачу внесения изменений в системную архитектуру, поскольку представление состояния объекта не оказывает на нее влияния. Изменение внутренних данных объекта не должно влиять на другие объекты системы. Более того, так как объекты слабо связаны между собой, обычно новые объекты просто вставляются без значительных воздействий на остальные компоненты системы.

Основные понятия ООП включают:

- при объектно-ориентированном проектировании основные компоненты программной системы представляются как объекты со своими состояниями и операциями;

- объекты предоставляют сервисы (методы) другим объектам и создаются в реальном времени на основе определения класса объектов;

- объекты могут быть реализованы последовательно и параллельно, параллельный объект может быть пассивным, у которого состояние изменяется только через его интерфейс, или активным, который может изменять свое состояние без вмешательства извне;

- в процессе объектно-ориентированного проектирования возможно создание ряда различных моделей, которые можно разделить на статические (модели классов, модели обобщения, модели агрегирования) и динамические (модели последовательностей, модели конечного автомата);
- важным преимуществом объектно-ориентированного проектирования является то, что он упрощает процесс модификации системы.

Одна часть общей системы занимается сбором данных, другая обобщает данные, полученные из различных источников, третья выполняет архивирование данных и наконец четвертая создает результаты. Система представляет собой многоуровневую архитектуру, в которой отражены все этапы обработки данных в системе, сбор и обобщение данных, архивирование данных и создание результатов. Такая многоуровневая архитектура вполне годится для проектирования, так как каждый этап основывается только на обработке данных, выполненной на предыдущем этапе.

Использование методов ООП строго регламентировано, поэтому:

- возрастает производительность труда разработчиков благодаря переходу к высокоэффективному методу - на базе предварительного анализа проекта;

- запросы и объекты реального мира проще моделируются путем концентрации внимания на классах, а не на алгоритмах их функционирования;

- компоненты системы легко изменяются и применяются повторно;

- требования проще отслеживаются;

- поддерживается эффективное прототипирование;

- разработка проекта отличается непрерывностью в представлении объектов - одни и те же типы диаграмм применяются как при анализе, так и на этапе разработки;

- работа по проектированию может осуществляться с помощью универсальных технологических инструментов.

ООП - только часть объектно-ориентированного процесса разработки системы, где на протяжении всего процесса создания ПС используется объектно-ориентированный метод. Этот подход подразумевает выполнение трех этапов:

- объектно-ориентированный анализ - создание модели предметной области приложения ПС, где объекты отражают реальные объекты-сущности, а также определяются операции, выполняемые объектами;

- объектно-ориентированное проектирование - разработка модели системы ПС и системной архитектуры с учетом системных требований, в которой определение всех объектов подчинено решению конкретной задачи;

- объектно-ориентированное программирование - реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (например, Java), непосредственно выполняющего отражение определенных объектов и предоставляющего средства для определения классов объектов.

Этапы могут "перетекать" друг в друга, т.е. могут не иметь четких рамок, причем на каждом этапе обычно применяется одна и та же система нотации. Переход на следующий этап приводит к усовершенствованию и конкретизации результатов предыдущего этапа путем более детального описания определенных ранее классов объектов и определения новых классов. Так как данные скрыты внутри объектов, детальные решения о содержании данных можно отложить до этапа реализации системы. В некоторых случаях можно также не спешить с принятием решений о расположении объектов и о том, будут ли эти объекты последовательными или параллельными. Если необходимы функциональные изменения, они производятся внутри объекта, что приводит к незначительным изменениям в оставшейся внешней части его процессов. Для обновления или добавления функций, оставшиеся объекты, поддерживаются с помощью интерфейсов. Объектно-ориентированное проектирование отображает предметную область задачи и ответственности системы, но задерживает определение подробностей реализации объектов, переносит их на более поздний этап разработки и минимизирует влияние изменений в функциональных требованиях.

При ООП основное внимание уделяется тому, что следует делать, каким образом добиться цели, а процесс её достижения целиком зависит от этапа разработки. Объектная декомпозиция дает возможность создавать программные комплексы визуально меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода повышает уровень унификации разработки и пригодность для повторного использования не только программных компонентов, но и больших комплексов программ, что ведет к созданию унифицированной среды разработки и переходу к сборочному созданию программных продуктов. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования компонентов из предыдущих разработок. Однако, структурный подход сохраняет свою высокую значимость и широко используется на практике. Взаимосвязью между структурным и объектно-ориентированным подходами является общность ряда категорий и понятий жизненного цикла ПС.

Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и с дополнительными финансовыми затратами. Кроме того, диаграммы, отражающие специфику объектного подхода, гораздо менее наглядны и хуже понимаемы непрофессионалами, объектно-ориентированный подход обычно не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки нескольких проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области.

В программных средствах при ООП рекомендуется выделять три уро-вня:

- уровень интерфейсов, который занимается всеми взаимодействиями с другими частями системы и предоставлением внешних интерфейсов системы;

- уровень сбора данных, управляющий сбором информации из внешней среды и обобщающий данные перед отправкой их в систему построения обобщенных результатов;

- уровень объектов, в котором представлены и описаны все объекты, используемые в процессе сбора исходных данных.

В общем случае рекомендуется структурировать систему на части так, чтобы архитектура была как можно проще. Согласно хорошему практическому правилу, модель архитектуры должна состоять не более чем из семи-восьми основных объектов. Перед выполнением проектирования должны быть сформированы представления относительно основных объектов проектируемой системы. Вместе с тем требуется определить и документировать все другие внешние объекты системы. Определения объектов на данном этапе проектирования отражает классы объектов и структура системы описывается в терминах этих классов. Классы объектов, определенные ранее, получают более детальное описание, поэтому иногда приходится возвращаться на данный этап проектирования для переопределения классов. Первый этап в любом процессе проектирования состоит в выявлении взаимоотношений между проектируемым ПС и его окружением. Выявление этих взаимоотношений помогает решать, как обеспечить необходимую функциональность системы и как структурировать систему, чтобы она могла эффективно взаимодействовать со своим окружением.

Язык UML представляет набор разработанных инженерных задач практического профиля, которые успешно испытаны при моделировании крупных и сложных систем. Поддерживается метамодель для диаграмм классов и набор семантических и синтаксических правил, определяющих суть элементов и их отношений. Модель поддерживается большим количеством автоматизированных инструментов. Основные цели использования языка UML на этапе разработки проекта ПС:

- поддержка на уровне пользователей готового к применению, выразительного визуального языка моделирования, применяемого для разработки и обмена моделями;

- поддержка спецификаций, независимых от определенных языков программирования и процессов разработки;

- поддержка формального базиса для представления языка моделирования;

- поддержка высокоуровневых понятий, таких как компоненты, элементы сотрудничества, каркасы и шаблоны;

- интеграция наилучшего опыта.

Разработчики UML установили, что даже при использовании современных передовых технологий, при сборе требований, анализе и разработке продолжается борьба с не адекватными и постоянно изменяющимися требованиями заказчиков (см. лекцию 6). Варианты использования предназначены для уточнения динамически требований и выработки более четкого представления возможных изменений в поведении системы. Они позволяют реализовать функциональные усовершенствования, которые отражаются и адресуются в организованной форме. Классы и объекты языка UML демонстрируют гибкость и управляемость при использовании статично и динамично несовершенных описаний. Для оживления общения в команде специалистов ООП позволяет реализовать в группе программистов интегрированный подход с помощью общего словаря и языка; инкапсуляция данных и алгоритмов позволяет членам команды работать над компонентами в параллельном режиме. Также в этом случае можно ограничить влияние изменчивости требований; наследственные свойства функций и атрибутов являются эффективным дополнением к функциональным возможностям.

Дата добавления: 2014-01-13