Применение объектно-ориентированного подхода при проектировании информационной системы (Методы и средства проектирования)

Содержание:

ВВЕДЕНИЕ

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

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

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

Аналитические исследования ведущих зарубежных аналитиков показывали не очень приятные результаты. Так в 1995 году, компания Standish Group провела анализ работы 364 американских корпораций и итоги выполнения 23 000 проектов в области разработки ПО, и пришла к следующим выводам: 16,2 % проектов выполнены в заданный срок, 52,7 % проектов были выполнены с опозданием, 31,1 % проектов были аннулированы до завершения. Все это конечно оказало большое влияние на бюджет.

В качестве причин данных неудач выступали:

• неточная и неполная формулировка требований к ПО;
• отсутствие ресурсов;
• неполно вовлечение пользователей в работу над проектом;
• ненадлежащее планирование;
• постоянное изменение требования к ПО;
• отсутствие грамотной координации проектом;
• отсутствие поддержки со стороны высшего руководства.

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

В соответствии с данной темой, в данной работе были поставлены следующие цели и задачи:

Целью исследования является подробный анализ всех аспектов объектно-ориентированного подхода. В соответствии с данной целью поставлены следующие задачи:

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

Предмет исследования – показатели, характеризующие объектно-ориентированный подход.

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

1. СТРУКТУРА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

Существует два главных подхода к проектированию информационных систем (ИС), такие как: структурный и объектно-ориентированный.

Структурный подход предполагает декомпозицию системы, т.е. разбиение системы на автоматизированные функции. Вся система разбивается на функциональные подсистемы, а те в свою очередь разбиваются на подфункции и т.д. вплоть до определенных процедур. В итоге можно сделать ввод, что проектирование системы происходит «сверху вниз». Нужно заметить, что, сама автоматизированная система сохраняет целостное представление, где все компоненты, входящие в эту систему остаются взаимосвязаны^[1][1]. Как правило, в дальнейшем, при проектировании системы «снизу вверх» начиная от отдельных задач и заканчивая всей системой, целостность утрачивается, и появляются проблемы при информационной стыковке отдельных компонентов данной системы. Данная проблема очень сильно усложняет процесс модификации системы. Какие либо преобразования, внесённые на каком либо уровне системы, с огромной вероятностью приведут к потоку каскадных негативных изменений на вышестоящих уровнях.

Объектно-ориентированный подход принципиально отличается от структурного, прежде всего, тем, что при объектно-ориентированном подходе логическая структура системы отражается абстракциями в виде классов и объектов, а при структурном подходе – алгоритмами и определенными выделенными множествами^[2][2].

Понятия объект и класс являются главными в объектно-ориентированном подходе^[3][3].

Объект – это нечто целостное, чем можно оперировать без учета наличия других подобных предметов рассмотрения, объект обладает поведением, состоянием и идентичностью^[4][4].

Класс – это множество рассматриваемых объектов с общей структурой и поведением^[5][5].

История

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

В 1967 г сотрудниками Норвежского Вычислительно Центра Оле-Йохансоном и Кристеном Нюгордом был, разработал первый мире объектно-ориентированный язык программирования (ЯП) Simula 67^[6][6]. Во время своего рождения данный язык предлагал революционные идеи: объекты, классы, виртуальные методы и т.д., но все это не было воспринято современниками как что то новое. Но, тем не менее, в дальнейшем большинство данных концепций были развиты Аланом Кэйем и Дэном Ингаллосом.

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

Главные понятия и разновидности

Структура данных «класс», которая представляет собой объектный тип данных, внешне похожа на типы данных процедурно-ориентированных языков, такие как структура в языки C или запись в Pascal или QuickBasic. При всем этом элементы данной структуры могут быть не только данными, но и методами. Данное объединение называется «инкапсуляцией»^[7][7].

Наличие инкапсуляции вполне достаточно для «объектности» ЯП, но это еще не значит что он объектно-ориентированный - для этого требуется наличие «наследования»^[8][8].

Но даже этих двух механизмов не достаточно, для того,что бы сделать ЯП объектным. Самые главные преимущества ООП проявляются, когда в ЯП реализован «полиморфизм».

Основные понятия

Абстракция (Abstraction) – это придание объекту характеристик, четко определяющих его концептуальные границы, отличая от других объектов. Главная суть состоит в том, чтобы отделить способ использования составных объектов данный от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функций и деталей ее реализации в терминах более примитивных функций, в итоге, данные обрабатываются функцией высокого уровня при помощи вызова функции низкого уровня. Абстракция является основой ООП и допускает работу с объектами, не вдаваясь в особенности их реализации^[9][9].

Инкапсуляция (Encapsulation) – это свойство ЯП, которое позволяет объединить данные и код в объект и скрыть реализацию объект от пользователя. Пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только с помощью данного интерфейса^[10][10].

Сокрытие данных – это важная часть ООП, которая управляет областями видимости. Является логическим продолжением инкапсуляции. Задачей сокрытия является неспособность пользователя узнать и повредить внутренне состояние объекта^[11][11].

Наследование (Inheritance) – это способность описать новый класс от другого, при этом сохраняются все свойства и методы класса-предка и при необходимости добавляются новые. Набор классов, которые связанны наследованием и отношением, называют иерархией.

Полиморфизм (Polymorphism) – это явление, при котором функции с одним и тем же именем соответствует разный программный код в зависимости от того, объект какого класса применяется при вызове этого метода.

Определение ООП

По мнению Алана Кея, создателя ЯП Smalltalk, которого считают одним из отцов-основателей ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов^[12][12]:

• все является объектом;
• вычисления производятся через взаимодействия между объектами, при котором один объект требует, чтобы другой выполнил определенное действие. Объекты взаимодействуют путем отправления и получения сообщений. Сообщение – это запрос на выполнение действия, дополненный набором аргументов, которые могут быть необходим при выполнении действия^[13][13].
• каждый объект обладает независимой памятью состоящей из других объектов;
• каждый объект является представителем класса, выражающий общие свойства объектов;
• в классе задается поведение объекта. Таким образом, все объекты являющиеся экземплярами одного класса способны выполнять одни и те же действия;
• классы организованны в единую древовидную структуру с общим корнем, называемую иерархией наследования. Поведение и память, которые связанны с экземплярами конкретного класса, автоматически доступны любому классу, расположенному ниже в древовидной иерархии^[14][14].

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

Управляемость и устойчивость системы обеспечивается благодаря разделению ответственности объектов, т.е. за каждое действие отвечает конкретный объект, однозначного определения интерфейсов межобъектного взаимодействия и полной внутренней структуры объекта от внешней среды^[16][16].

ООП основывается на описании поведения и структуры разрабатываемой системы, т.е. отвечает на два главных вопроса:

• из каких частей состоит система;
• в чем состоит ответственность каждой из этих частей.

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

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

2. ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ UML

2.1 Унифицированный язык объектно-ориентированного моделирования

На данный момент существует огромное число разнообразных инструментальных средств, использующихся для реализации заданного проекта ИС начиная от этапа анализа и заканчивая этапом создания программного кода. Различают отдельно так называемые upper CASE tools (CASE-средства верхнего уровня) и lower CASE tools (CASE-средства нижнего уровня)^[17][17].

Среди главных проблем использования upper CASE tools выделают проблемы их адаптации под определенные проекты, по причине того, что они очень серьезно регламентируют процесс разработки и не позволяют организовать работу на уровне отдельных элементов проекта^[18][18]. Другим вариантом возможно использование lower CASE tools, но их использование влечет за собой определенные проблемы, такие как: трудности при организации взаимодействия между командами, работающими над определенными элементами проекта^[19][19].

Тем средством, который позволил объединить данный подходы, стал Unified Modeling Language (Унифицированный язык объектно-ориентированного моделирования). United Modeling Language или просто UML – это преемник поколения методов ООАП, которые появились в конце 80-х и начале 90-х годов. Разработка UML началась в конце 1994 г, когда Джейм Рамбо и Гради Буч нчаласи работу по определению методов Booch и OMT под эгидой компании Rational Software. А уже к концу 1995 г они создали первую спецификацию объединенного метода, которого они назвали Unified Method, версии 0.8. В том же году к ним присоединился Ивар Якобсон, создать метода Object-oriented Software Engineering. В итоге UML стал прямым объединением и унификацией методов Буча, Рамбо и Якобсона^[20][20]. Основными целями при разработке UML были:

• дать пользователям уже готовый для применения выразительный язык визуального моделирования, который позволял не только проектировать осмысленные модели, но и обмениваться ими;
• обеспечить формальную среду для понимания данного языка моделирования;
• обеспечить независимость от определенных ЯП. и процессов разработки;
• заранее предусмотреть механизмы специализации и расширяемости для увеличения фундаментальных концепций^[21][21].

На сегодняшний день UML как нотация моделирования ИС поддерживается рядом объектно-ориентированных CASE-продуктов^[22][22].

Основными характеристиками объектно-ориентированного языка моделирования UML являются:

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

Базовый набор диаграмм UML содержится в большом количестве средств моделирования. Однако в связи с тем, что каждая прикладная задача имеет свои особенности и требует всех концепций в каждом предложении, язык предоставляет пользователям такие возможности как:

• Моделирование с применение только средств «ядра» для типовых приложений;
• Моделирование с применением дополнительных условных обозначений, если они отсутствуют в «ядре», или специализация нотации и ограничений для данной предметной области^[23][23].

Для поддержки моделирования различных этапов жизненного цикла ИС язык UML предоставляет целую совокупность различных диаграмм.

При проектировании концептуальной модели используют диаграммы вариантов использования и диаграмм деятельности, модели бизнес-объектов, диаграммы последовательностей^[24][23].

На этапе работы над логической моделью ИС описать требования к системе позволяют диаграммы вариантов использования, а при предварительном проектировании применяют диаграммы классов, диаграммы последовательностей, диаграммы состояний.

Детальное проектирование при разработке физической модели выполняют с использованием диаграмм развертывания, диаграмм компонентов и диаграмм классов^[25]24.

2.2 Варианты использования

В течение довольно таки продолжительного периода времени в процессе как традиционного структурного, так и объектно-ориентированного проектирования разработчики применяли типичные сценарии, которые помогали точнее понять требования к системе. Трактовались данные сценарии весьма неформально, они часто использовались и очень редко документировались. Понятие use case (вариант использования) ввел впервые Ивар Якобсон и придал ему такую значимость, что оно трансформировалось в главный элемент проектирования и планирования проекта.

Вариант использования представляет собой такую последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом, т.е. действующим лицом^[26][25]. Вариант использования описывает примитивное взаимодействие между системой и пользователем. В качестве простого примера, два обычных варианта использования типичного текстового процессора – сделать данный текст полужирным и создать индекс. На этом простом примере легко можно выделить пару свойств варианта использования: он решать для пользователя некоторую дискретную задачу, охватывает очевидную для пользователя функцию, а так же может быть как большим, так и довольно маленьким. Вариант использования в простых случаях определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать^[27][26].

В 1994 г. Ивар Якобсон предложил не только использовать варианты использования в качестве основных элементов процесса проектирования ПО, но и применять диаграммы вариантов для их наглядного представления^[28][27].

При создании модели прецедентов, основными элементами на диаграмме будут являться:

• актер (actor) – это элемент, обозначающий пользовательские роли и взаимодействующий с определенной сущностью;
• прецедент – это элемент, который отражает действия, выполняемые самой системой (с указанием всевозможных вариантов), приводящие в результата, наблюдаемые актерами.

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

• include (включение) – указывает на взаимосвязь некоторых вариантов использования, из которых основной использует всегда функциональное поведение связанных с ним прецедентов;
• extend (расширение) – указывает на взаимосвязь базового варианта использования и вариантов использования, которые в свою очередь являются специальными случаями;
• generalization (обобщение) – указывает на общность ролей^[29][28].

Все варианты использования, так или иначе, связаны с требованиями к функциональности системы извне. Варианты использования всегда нужно анализировать вместе с актерами системы, при этом определяя реальные цели пользователей и рассматривая альтернативные варианты решения этих задач^[30][29].

Актеры могут играть разные роли по отношению к варианту использования. Они могут сами принимать в нем участие или всего лишь пользоваться его результатами. Важность разных ролей актеров зависит от того, как используются его связи^[31][30].

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

В дополнение к связям между актерами и вариантами использования существуют так же еще два других типа связей, такие как: extends (расширение) и uses (использование) между вариантами использования. Связь типа extends (расширение) используется, когда один вариант использования похож на другой, но при этом не несет большую загрузку.

Выбор необходимого типа связи определяется следующими правилами:

• связь типа extends (расширение) нужно использовать при описании в нормальном поведении системы;
• связь типа uses (использование) требуется применять во избежание повторов в двух или более вариантах использования.

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

ДИАГРАММЫ

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

Диаграмма UML – это специальный язык графического описания и предусмотренный для объектного моделирования в области разработки различного ПО^[32][31]. Данный язык представляет собой открытый стандарт, в котором применяются разные графические обозначения, для того чтобы создать абстрактную модель системы. UML разрабатывался для обеспечения визуализации, определения, документирования, а так же для проектирования различных систем^[33][32]. Следует сказать, что сама по себе UML-диаграмма не является ЯП, но при этом предусматривается возможность генерации отдельного кода на ее основе.

Использования UML не прекращается на моделировании различного ПО. На сегодняшний момент данный язык все так же используется для моделирования различных бизнес-процессов и ведения системного проектирования^[34][33].

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

Далее мы рассмотрим, какие бывают виды диаграмм, и скажем об их назначении.

Итак, диаграммы бывают следующих видов:

• диаграмма вариантов использования;
• диаграмма классов;
• диаграмма состояний;
• диаграмма взаимодействий;
• диаграмма деятельности;
• диаграмма пакетов;
• диаграмма компонентов;
• диаграмма размещения.

Диаграмма вариантов использования показывает на себе все отношения, возникающие между актерами и разными вариантами использования^[35][34]. Основная ее цель – это осуществлять собой полное средство, при помощи которого конечный пользователь, заказчик или разработчик могут совместно обсуждать функциональность и поведение конкретной системы^[36][35].

Диаграмма классов представляет собой статическую структурную диаграмму, которая предназначена для описания структуры системы, а также для демонстрации методов, атрибутов и зависимостей между несколькими различными классами^[37][36].

Существует несколько течек зрения на построение данных диаграмм в зависимости от того, как они буду использоваться:

• концептуальная. В этом случае диаграмма классов UML осуществляет описание модели конкурентной сферы, и в ней предусматриваются только классы прикладных объектов;
• реализационная. В данном случае диаграмма классов включает в себя всевозможные классы, которые применяются в программном коде;
• специфическая. Здесь, диаграмма применятся в процессе проектирования различных ИС^[38][37].

Диаграмма состояния определяет все возможные состояния, в которых может находиться определенный объект, а также процесс смены состояния объекта вследствие наступления каких либо событий. Имеется множество форм диаграмм состояний, незначительно отличающихся друг от друга семантикой^[39][38].

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

Диаграмма деятельности показывает разложение деятельности на некоторое количество частей. Под понятие деятельности понимается спецификация определенного исполняемого поведения как в виде параллельного, так и в виде координированного последовательного выполнения разных подконтрольных элементов – вложенных типов деятельности и различных действий, которые объединены потоками, идущими от выходов конкретного узла к выходам другого^[40][39].

Диаграмма пакетов носит структурный характер, и главных ее содержанием являются различные пакеты, а также отношения между ним. В этом случае, нет никакого жесткого разделения между несколькими структурами диаграммами, в итоге их использование все чаще встречается только для удобства, и не несет в себе никакого семантического значения. Различные элементы способны предоставлять другие UML диаграммы (пакеты и сами диаграммы пакетов)^[41][40]. Их использование осуществляется для обеспечения организации нескольких элементов в группы, по какому либо признаку, для упрощения структуры и организации работы с моделью данной системы.

Диаграмма компонентов представляет собой статическую структурную диаграмму, предназначенную для демонстрации разбиения определенной программной системы на различные структурные компоненты и для связи между ними. В качестве таковых диаграмма компонентов способна использовать различные исполняемые файлы, пакеты, библиотеки, модели^[42][41].

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

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

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

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

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

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

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

Объектно-ориентированный подход имеет ряд существенных удобств, которые не предусмотрены иными подходами. Важно то, что данный подход позволяет создавать системы удовлетворяющие законам хорошо структурированных сложных систем. Кроме этого, существует еще ряд преимуществ, которые предоставляет ООП^[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 диаграммы, для чего они нужны, и каких видов они бывают, а так же перечислены как положительные, так и отрицательные стороны данного подхода и перечислены мнения критиков объектно-ориентированного подхода.

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

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

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

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

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

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

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

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

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

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

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

БИБЛИОГРАФИЯ

1. Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – 624 с.
2. Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – 304 с.
3. Брукс Ф., Чапел Х. Мифический человеко-месяц, или как создаются программные системы / Ф Брукс., Х Чапел. – М.: Символ-Плюс, 1975. – 304 с.
4. Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – 560 с.
5. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – 496 с.
6. Вендеров А.М. CASE-технологии. Современные методы и средства проектирования информационные систем / А.М. Вендеров. – М.: Финансы и статистика, 1998. - 98 с.
7. Дал У.И. Симула 67 / У.И. Дал. – М.: Мир, 1969. – 98 с.
8. Дейкстра Э. Дисциплина программирования / Э Дейкстра. - .: Мир, 1978. – 276.
9. Киллелиа П. Тюнинг веб-сервера / П Киллелиа. – СПб.: Питер, 2003. – 528 с.
10. Кирютенко Ю.А., Савельев В.А. Объектно-ориентированное программирование. Язык Smalltalk / Ю.А. Кирютенко., В.А. Савельев. – М.: Вузовская книга, 2006. – 328 с.
11. Майер Б. Объектно-ориентированное конструктирование программных систем / Б. Майер. – М.: Издательство «Русская Редакция», 2005. – 1232 с.
12. Медведев В.И. Особенности объектно-ориентированного программирования / В.И. Медведев. – М.: РИЦ «Школа», 2010. – 444 с ил.
13. Мухортов В.В., Рылов В.Ю. Объектно-ориентированное программирование, анализ и дизайн. Методическое пособие / В.В. Мухортов., В.Ю. Рылов. – М.: Новосибирск, 2002. – 108 с.
14. Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. – 420 с.
15. Фаулер М. UML. Основы, 3-е издание / М. Фаулер. – М.: Символ-Плюс, 2004. – 184 с.

ПРИЛОЖЕНИЯ

Приложение 1.

Диаграмма вариантов использования

Источник: http://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

Приложение 2.

Диаграмма классов

Источник: http://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

Приложение 3.

Диаграмма состояний

Источник: https://habrahabr.ru/post/74330/

Приложение 4.

Диаграмма взаимодействий

Источник: http://studopedia.su/

Приложение 5.

Диаграмма деятельности

Источник: http://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

Приложение 6.

Диаграмма пакетов

Источник: http://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

Приложение 7.

Диаграмма компонентов

Источник: http://www.syl.ru/article/206012/new_uml-diagramma-vidyi-diagramm-uml

Приложение 8.

Диаграмма размещения

Источник: http://studopedia.su/12_26455_diagrammi-komponentov.html

1. [1] Вендеров А.М. CASE-технологии. Современные методы и средства проектирования информационные системы / А.М. Вендеров. – М.: Финансы и статистика, 1998. – С. 7. ↑

2. [2] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 12. ↑

3. [3] Мухортов В.В., Рылов В.Ю. Объектно-ориентированное программирование, анализ и дизайн. Методическое пособие / В.В. Мухортов., В.Ю. Рылов. – М.: Новосибирск, 2002. – 5 с. ↑

4. [4] Медведев В.И. Особенности объектно-ориентированного программирования / В.И. Медведев. – М.: РИЦ «Школа», 2010. – 32 с ил. ↑

5. [5] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 13. ↑

6. [6] Дал У.И. Симула 67 / У.И. Дал. – М.: Мир, 1969. – C. 6. ↑

7. [7] Майер Б. Объектно-ориентированное конструктирование программных систем / Б. Майер. – М.: Издательство «Русская Редакция», 2005. – С. 255. ↑

8. [8] Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – C. 162. ↑

9. [9] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 42. ↑

10. [10] Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – C. 164. ↑

11. [11] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 47. ↑

12. [12] Кирютенко Ю.А., Савельев В.А. Объектно-ориентированное программирование. Язык Smalltalk / Ю.А. Кирютенко., В.А. Савельев. – М.: Вузовская книга, 2006. – C. 142. ↑

13. [13] Кирютенко Ю.А., Савельев В.А. Объектно-ориентированное программирование. Язык Smalltalk / Ю.А. Кирютенко., В.А. Савельев. – М.: Вузовская книга, 2006. – C. 144. ↑

14. [14] Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – C. 167. ↑

15. [15] Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – C. 168. ↑

16. [16] Бадд Т. Объектно-ориентированное программирование в действии / Т. Бадд. – М.: Питер, 2-е издание, 1997. – C. 169. ↑

17. [17] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 52 с. ↑

18. [18] Фаулер М. UML. Основы, 3-е издание / М. Фаулер. – М.: Символ-Плюс, 2004. – C. 55 с. ↑

19. [19] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 124 с. ↑

20. [20] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 126 с. ↑

21. [21] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 56 с. ↑

22. [22] Фаулер М. UML. Основы, 3-е издание / М. Фаулер. – М.: Символ-Плюс, 2004. – C. 58 с. ↑

23. [23] Фаулер М. UML. Основы, 3-е издание / М. Фаулер. – М.: Символ-Плюс, 2004. – C. 60 с. ↑

24. [23] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 58 с. ↑

25. 24 Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 130 с. ↑

26. [25] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 156 с. ↑

27. [26] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 60 с. ↑

28. [27] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 134 с. ↑

29. [28] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 158 с. ↑

30. [29] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 64 с. ↑

31. [30] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 138 с. ↑

32. [31] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 164 с. ↑

33. [32] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 68 с. ↑

34. [33] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 144 с. ↑

35. [34] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 145 с. ↑

36. [35] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 167 с. ↑

37. [36] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 70 с. ↑

38. [37] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 72 с. ↑

39. [38] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 170 с. ↑

40. [39] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 148 с. ↑

41. [40] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 150 с. ↑

42. [41] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 75 с. ↑

43. [42] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 173 с. ↑

44. [43] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 174 с. ↑

45. [44] Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя, 2-е издание / Г. Буч., Д. Рамбо., И. Якобсон. – М.: ДМК Пресс, 2007. – C. 77 с. ↑

46. [45] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 153 с. ↑

47. [46] Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е издание, 2007. – C 155 с. ↑

48. [47] Мюллер Роберт Дж. Базы данных и UML. Проектирование / Роберт Дж. Мюллер. – М.: Лори, 2002. –C 178 с. ↑

49. [48] Вендеров А.М. CASE-технологии. Современные методы и средства проектирования информационные системы / А.М. Вендеров. – М.: Финансы и статистика, 1998. – С. 42. ↑

50. [49] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 122. ↑

51. [50] Майер Б. Объектно-ориентированное конструктирование программных систем / Б. Майер. – М.: Издательство «Русская Редакция», 2005. – С. 544. ↑

52. [51] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 125. ↑

53. [52] Буч Г. Объектно-ориентированный анализа и проектирование с примерами приложений на C++ / Г. Буч. – СПб.: Невский диалект, 2-е издание., 1998. – С. 125-126. ↑

54. [53] Брукс Ф., Чапел Х. Мифический человеко-месяц, или как создаются программные системы / Ф Брукс., Х Чапел. – М.: Символ-Плюс, 1975. – C. 304 с. ↑

55. [54] Дейкстра Э. Дисциплина программирования / Э Дейкстра. - .: Мир, 1978. – C. 275. ↑

56. [55] Киллелиа П. Тюнинг веб-сервера / П Киллелиа. – СПб.: Питер, 2003. – C. 244 с. ↑