Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Унифицированный язык объектно-ориентированного моделирования).pdf

Диаграмма размещения показывает физические связи между аппаратными и программными элементами системы. Она является отличным вариантом, чтобы показать размещение объектов в распределенной системе. Каждый узел на данной диаграмме представляет собой некий тип вычислительного устройства. Данная аппаратура может быть как простым устройством, так и мейнфреймом^[43][42].

Теперь перейдем к преимуществам использования данных диаграмм:

вследствие объектно-ориентированного языка, технологии описания результатов проведенного анализа и проектирования являются семантически близкими к методам программирования на различных типах современных объектно-ориентированных языках;
данный язык получил довольно широкое распространение и активно совершенствуется;
UML позволяет расширить, а также вводить свои тестовые и графические стереотипы, что способствует его применению не только в программной инженерии;
при помощи этого языка система может быть описана с любых точек зрения и точно так же описываются всевозможные аспекты ее поведения;
все диаграммы довольно легки для чтения даже после быстрого ознакомления с синтаксисом^[44][43].

Несмотря на то, что UML диаграммы имеют много плюсов, их часто критикуют за такие недостатки как:

Избыточность. В большинстве случаев критики считают, что UML является сложным и большим, и зачастую это неоправданно. В него входят довольно много избыточных и даже бесполезных диаграмм и конструкций, причем очень часто такая критика идет в сторону второй версии, а не первой, по причине того, что в более новых ревизиях имеется огромное число компромиссов «разработанных комитетом»^[45][44].
Всевозможные неточности в семантике. Из-за того, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, присущая для языков, конкретно определенных техникой формального описания. В некоторых моментах абстрактный синтаксис OCL, UML и английский язык начинают противоречить друг другу, в то время как в других случаях они являются неполными^[46][45].
Трудности в процессе изучения и внедрения. Проблемы указанные выше создают сложности при изучении и внедрении UML, в особенности, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а именно рабочие системы, то есть код и есть проект. В соответствии с этим есть потребность в разработке более эффективного способа написания ПО^[47][46]. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на деле этого может не хватать, т.к. в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в итоге будет ограничиваться тем, что может предположить или определить интерпретирующий UML инструмент^[48][47].
Рассогласование нагрузки. Этот термин происходит из теории системного анализа для определения неспособности входа определенной системы восполнять выход иной.
Пытается быть универсальным. UML это язык моделирования общего назначения, старающийся обеспечить совместимость с любым существующим на сегодняшний день языком обработки.

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

ПОЛОЖИТЕЛЬНЫЕ И ОТРИЦАТЕЛЬНЫЕ СТРОНЫ

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

данный подход допускает в полной мере применять выразительные возможности объектных и объектно-ориентированных ЯП.;
использование ООП серьезно повышает уровень унификации разработки и пригодность для повторного применения, как программ, так и проектов, что в итоге приводит к появлению расширяющейся и разветвлённой среды разработки;
объектно-ориентированные системы зачастую получаются более компактными;
при объектно-ориентированном подходе выполнение проекта состоит из ряда хорошо продуманных шагов, что повышает уверенность в правильности принимаемых решений и уменьшает степень риска получения отрицательного эффекта от проекта^[50][49].
использование данного подхода приводит к построению систем на основе стабильных промежуточных описаний, что значительно упрощает процесс внесения изменений в дальнейшем, это предоставляет системе возможность развиваться поэтапно и исключает потребность в ее полной переработке даже в случае серьезных изменений изначальных требований^[51][50];
ООП также уменьшает риск проставления проектирования сложных систем до достижения всех поставленных задач, прежде всего потому, что процесс интеграции отдельных частей системы растягивается на все время проектирования, а не превращается в единовременное событие;
объектный подход ориентирован на человеческое восприятие мира^[52][51].

Гради Буч один из основателей унифицированного языка моделирования UML указывает на следующие причины, которые приводят к снижению производительности программ из-за использования объектно-ориентированных средств:

динамическое связывание методов. Обеспечение полиморфного поведения объектов приводит к необходимости связывать методы, которые вызываются программой, только не на шаге компиляции, а в процессе исполнения программы, на что приходиться тратить дополнительное время. При всем этом динамическое связывание необходимо только для 20% вызовов, но некоторые ООП-языки применяют его всегда.
значительная глубина резкости. ООП-разработка часто приводит к созданию «многослойных» приложений, в которых выполнением объектом необходимого действия сводится к множеству обращений к объектам более низкого уровня. В таком приложении очень часто происходит много вызовов методов и возвратов из методов, все это оказывает, влияет на производительность.
наследование «размывает» код. Код, который относится к «оконечным» классам иерархии наследования – находится не только в самих классах, но и в их классах-предках. Методы, которые относятся к одному классу, описываются в разных классах. В итоге это приводит к двум неприятным последствиям: снижается скорость трансляции, по причине того, что компоновщику приходится подгружать описание всех классов иерархии и снижается производительность программы в системе со страничной памятью;
инкапсуляция снижает скорость доступа к данным. Запрет на прямой доступ к полям класса извне приводит к необходимости создания и использования методов доступа. Написание, компиляция и исполнение методов доступа сопряжено с дополнительными расходами;
динамическое создание и уничтожение объектов^[53][52]. Динамически создаваемые объекты, как правило, размещаются в куче, что менее эффективно, чем размещение их на стеке и, тем боле, статическое выделение памяти под них на этапе компиляции. Невзирая на данные минусы, Гради Буч утверждает, что выгоды от применения ООП более весомы. По его словам повышение производительности за счет лучшей организации кода в некоторых моментах компенсирует дополнительные расходы на организацию функционирования программы. Также можно отменить, что многие эффекты снижения производительности способны сглаживаться или полностью устраняться за счет хорошей оптимизации кода компилятором. В качестве примера, снижение скорости доступа к полям класса из-за использования методов доступа устраняется, если компилятор использует инлайн-подстановку вместо вызова метода доступа.

Критика ООП

Несмотря на отдельные замечания в сторону ООП, в настоящее время именно эта парадигма применяется в большинстве проектов. Но при этом не следует считать, что ООП является лучшей методикой программирования.

Критические высказывания в адрес ООП:

исследования Thomas E. Potok, Mladen Vouk и Andy Rindos показало отсутствие серьезной разницы в продуктивности проектирования ПО между ООП и процедурным подходом;
Кристофер Дэйт указывает на неспособность сравнения ООИ и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП;
Александр Степанов, в одном из своих интервью он указал, что ООП «методологически неправильно» и «ООП практически такая же мистификация, как и искусственный интеллект»;
Фредерик Брукс (Frederick P. Brooks, Jr.) в своей статье «No Silver Bullet». Essence and Accidents of Software Engineering (Computer Magazine; April 1987) указывает, что наиболее сложной частью создания ПО является «дизайн, спецификация и тестирование концептуальных конструкций, а не работа по выражению этих концептуальных конструкций»^[54][53]. ООП (наряду с такими технологиям как искусственный интеллект, экспертные системы, графическое программирование, автоматическое программирование, верификация программ и др.) по его мнению, не является «серебряной пулей», которая способна снизить сложность проектирования программных систем. По его мнению «ООП позволяет сократить только привнесенную сложность в выражение дизайна. Дизайн остается сложным по своей природе»;
Никлаус Вирт полагает, что ООП – не более чем тривиальная надстройка над структурным программирование, и преувеличение ее значимости, выражающееся, в том числе, во включении в языки программирования все новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого ПО;
Эдсгер Дейкстра указывал: «то о чем общество в большинстве случаев просит – это змеиное масло^[55][54]. Естественно, “змеиное масло” имеет очень впечатляющие имена, иначе будет очень трудно что-то продать: “Структурный анализ и Дизайн”, “Программная инженерия”, “Модели Зрелости”, “Управляющие информационные системы”, “Интегрированные среды поддержки проектов”, “Объектная ориентированность”, “Реинжиниринг бизнес-процессов”».
Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «ООП предоставляет вам множество способов замедлить работу ваших программ»^[56][55].

Если попытаться классифицировать критические высказывания в адрес ООП, то можно выделить несколько аспектов критики данного подхода к программированию.

Критика рекламы ООП.

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

Оспаривание эффективности разработки методами ООП.

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

Главные идеи объектно-ориентированного подхода опираются на данные положения:

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

В объектно-ориентированном программировании базовыми понятиями являются понятие объекта и класса. Объект обладает конкретными свойствами. Его состояние задается значениями его признаков. Объект обладает методами решений.

Объект – это осязаемая реальность, которая характеризуется четко определяемым поведением.

Объект – это особый опознаваемый предмет, блок или сущность, абстрактная или реальная, которое имеет необходимое функциональное назначение в определенной предметной области.

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

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