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

Содержание:

Введение

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

В момент появления первых ЭВМ предметом внимания была прежде всего аппаратура, особенности архитектуры ЭВМ. И программы разрабатывались в двоичных кодах. Со временем вычислительные машины становились мощнее и надежнее. Одновременно с этим возрастала сложность решаемых с их помощью задач, что в свою очередь вызвало совершенствование технологий разработки программ. Важнейший прорыв произошел в конце 50-х годов, когда появились языки программирования высокого уровня: Фортран, Ангол и др. Их появление в свою очередь позволило решать более сложные задачи. Требования возросли, что опять потребовало совершенствования технологий и т.д.

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

Языки первого поколения ориентировались на научно-инженерные применения (1954-1958). Во втором поколение языков высокого уровня основной тенденцией стало развитие алгоритмических абстракций (1959-1961). Языки третьего поколения стали поддерживать абстракцию данных, что позволило программистам описывать свои собственные типы данных (1962-1970).

Четвертое поколение (1970-1980) знаменовалось всплеском активности создания новых языков. Было создано около 2-х тысяч языков и их диалектов. Именно в этом поколении появились языки, называемые объектными или объектно-ориентированными.

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

I. История развития объектно-ориентированного программирования

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

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

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

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

Рис. 1 Архитектура программы, использующей глобальную область данных

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

Необходимость исключения таких ошибок привела к идее использования в подпрограммах локальных данных (рис 2).

Рис. 2 Архитектура программы, использующей подпрограммы с локальными данными

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

Усилиями многих авторов такая технология была создана и получила название «структурное программирование».

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

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

Рис. 3 Основные структуры процедурной декомпозиции

Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Как правило, они включали основные «структурные» операторы управления, поддерживали вложение подпрограмм, локализацию и ограничение области «видимости» данных.

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

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

Рис. 4 Архитектура программы, состоящей из модулей

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

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

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

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

Как следует из определения основными понятиями объектно-ориентированного программирования являются объекты и классы.

II. Понятие объекта и класса

1. Объекты

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

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

Как пример возьмем операцию снятия денег через банкомат. В данной операции задействованы три объекта «клиент Иванов», «банкомат на Тверской» и «счет 66579801», который открыт в данном банке. Подойдя к банкомату и засунув свою карточку, объект «клиент Иванов» посылает банкомату сообщение «Начать работать». Получив такое сообщение банкомат запрашивает код доступа. «Банкомат на Тверской» посылает сообщение «клиенту Иванову»: «Сообщите идентификационный номер». Если идентификация прошла успешно, «клиент Иванов» просит выдать ему 1000 рублей. Он посылает сообщение банкомату, а тот в свою очередь посылает сообщение объекту «счет № 66579801». Приняв это сообщение, объект «счет № 66579801» проверяет, если ли у него 100 рублей, и, если есть, пересылает разрешение на снятие денег, одновременно уменьшая свой баланс на соответствующую сумму. Банкомат передает деньги, и на этом процедура заканчивается (рис. 5).

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

Рис. 5 Схема взаимодействия объектов

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

Но что же такое «объект»? Дать четкое и приемлемое для всех определение этому понятию невозможно. Объект — это слишком общее понятие. Так, например, Гради Буч дает следующее определение: «Что -то с чем-то можно оперировать. У объекта есть состояние, поведение и возможность отличить его от других объектов.

1. Состояние объекта.

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

2. Идентификация объекта.

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

3. Интерфейс объекта.

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

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

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

2. Классы

В системе обычно функционирует множество объектов. Некоторые из них «похожи» или однотипны. Однотипные объекты объединяют в классы.

Понятие класса позволяет существенно упростить разработку и реализацию системы.

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

Индивидуальные объекты называются экземплярами класса, а класс — это шаблон, по которому строятся объекты (рис. 6). Термины «объект» и «экземпляр» эквивалентны.

Рис. 6 Классы, используемые в банковской системе

В чем же отличие понятия класса от таких понятий, как «интерфейс» и «тип»?

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

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

Важнейшими свойствами классов и их принципиальным отличием от абстрактных типов данных является наследование и полиморфизм.

1. Наследование классов.

Наследование — это отношение между классами, при котором один класс разделяет структуру или поведение одного, или нескольких других классов.

Прежде всего механизм наследования позволяет выделить общие части разных классов.

2. Полиморфизм.

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

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

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

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

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

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

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

Кроме главных, существуют дополнительный элементы; контроль типов, параллелизм, персистентность.

1. Абстрагирование

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

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

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

Наиболее часто применяется абстракция сущности.

2. Инкапсуляция

Абстракция и инкапсуляция дополняют друг друга. В центре внимания абстракции находится наблюдаемое поведение объекта, а инкапсуляция отвечает за внутреннюю реализацию, которая и определяет внешнее поведение. Инкапсуляция реализуется за счет сокрытия информации о деталях функционирования объекта. Объект представляется своего рода «черным ящиком», предоставляя во внешнюю среду инструменты для ввода информации и определенным образом реагируя на изменения внешней среды. Очевидно, что в языках высокого уровня подобное поведение обеспечивается за счет открытых методов объекта.

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

Инкапсуляцию можно определить следующим образом:

Инкапсуляция — это процесс разделения элементов абстракции, определяющих структуру и поведение, инкапсуляция предназначена для изоляции контрактных обязательств абстракции от реализации.

3. Модульность

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

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

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

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

При практической реализации модульной декомпозиции можно руководствоваться правилами:

• 1. Конечной целью декомпозиции программы на модули является снижение затрат на программирование. Разделение на модули не носит механический характер: каждому классу — отдельный модуль.
  2. Структура каждого модуля должна быть простой для понимания, допускать независимую реализацию других модулей и не влиять на их поведение. Изменение проекта, состоящего из множества модулей, должно существенно упроститься по сравнению с аналогичной реализацией проекта в одномодульном варианте.
  3. Решение проблемы повторной компиляции модулей. Модули могут компилироваться независимо, но если при компиляции будут выявлены зависимости, то процесс компиляции может занять существенное время. Поэтому при программировании модулей необходимо ориентироваться на использование интерфейсов.
  4. Необходимо как можно больше скрывать детали реализации модуля. Данное определение связано с предыдущим, так как позволяет реализовать интерфейс, а затем постепенно наполнять модуль конкретной реализацией.

Модульность – это свойство системы, представленной отдельными,

цельными и слабосвязанными фрагментами (модулями).

Разделение системы на модули имеет важные последствия.

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

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

4. Иерархия

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

Иерархия – это механизм для упорядочивания классов абстракций. При реализации и проектировании программных систем следует учитывать следующие виды иерархий: отношение между классами (иерархия «общее/частное») и отношение объектов (иерархия «целое/часть»).

Одиночное наследование. Данный вид наследования представляет собой вид иерархии, которая наиболее распространена. Данное отношение между классами основано на принципе «является» («is a»).

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

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

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

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

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

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

5. Контроль типов

Контроль типов – это механизм, контролирующий правила замены объектов различных типов.

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

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

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

1. Часто при отсутствии контроля типов программа может завершиться непредсказуемо, сто связано с отсутствием механизма выявления ошибок на этапе разработки.

2. Чаще всего, цикл разработки, включающий этапы редактирования, компиляции и отладки, является очень трудоемким. Автоматическое выявление ошибок на раннем этапе крайне желательно.

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

4. Контроль типов позволяет оптимизировать работу компилятора.

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

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

6. Параллелизм

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

Каждая программа должна иметь один поток управления, но в параллельной системе существует возможность создавать множество потоков управления с разным приоритетом.

Выделяют следующие виды параллелизма:

1. «тяжеловесный» (heavyweight);
2. «легковесный» (lightweight).

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

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

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

Объект – это понятие, объединяющее две точки зрения: каждый объект (построенный на основе абстракции реального мира) может представлять собой отдельный поток управления (абстракцию процесса). Такой объект называется активным (active). Действительно, каждый объект – не просто реализация абстракции, как описания реального процесса (явления) предметной области. Объект имеет свой жизненный цикл, свой период существования.

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

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

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

7. Персистентность

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

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

1. Промежуточные результаты вычисления выражений.
2. Локальные переменные в вызове процедур.
3. Собственные переменные, глобальные переменные и динамические данные.
4. Данные, сохраняющиеся между разными сеансами выполнения программы.
5. Данные, сохраняющиеся при переходе от одной версии программы к другой.
6. Данные, существующие после исчезновения программы.

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

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

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

Персистентность – это способность объекта преодолевать временные рамки (т. е. продолжать свое существование после исчезновения своего создателя) или пространственные пределы (т. е. выходить за пределы своего первоначального адресного пространства).

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

Как и у любого метода программирования, у ООП есть ряд преимуществ и недостатков.

IV. Достоинства и недостатки объектно-ориентированного подхода.

1. Достоинства ООП

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

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

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

Расширение типа и вытекающий из него полиморфизм переменных оказываются полезными преимущественно в следующих ситуациях.

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

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

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

2. Недостатки ООП

Объектно-ориентированное программирование требует знания четырех вещей.

• • Необходимо понимать базовые концепции, такие как классы, наследование и динамическое связывание. Для программистов, уже знакомых с понятием модуля и с абстрактными типами данных, это потребует минимальных усилий. Для тех же, кто никогда не использовал инкапсуляцию данных, это может означать изменения мировоззрения и может отнять на изучение значительное количество времени.
  • Многоразовое использование требует от программиста познакомиться с большими библиотеками классов. А это может оказаться сложнее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций.
  • Проектирование классов — задача куда более сложная, чем их использование. Проектирование класса, как и проектирование языка, требует большого опыта. Это итеративный процесс, где приходится учиться на своих же ошибках.
  • Очень трудно изучать классы, не имея возможности их «пощупать». Только с приобретением опыта можно уверенно себя почувствовать при работе с использованием ООП.

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

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

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

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

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

Другой подход — дать возможность компоновщику удалять лишние методы.

Таким образом, нельзя утверждать, что ООП вообще неэффективно.

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

V. Программные продукты ООП

1. Business studio

Business studio – система визуального бизнес-моделирования, позволяющая компаниям ускорить и упростить развитие своей системы управления, внедрение системы менеджмента качества.

Первая версия Business Studio вышла 5 октября 2004г. как продукт, предназначенный для создания моделей бизнес-процессов  и их документирования. В качестве графической среды моделирования был использован широко распространенный пакет Microsoft Office Visio. В дальнейшем функциональность продукта быстро расширялась: в 2007 году появляется модуль для проектирования системы целей и показателей с поддержкой методики   BSC/KPI и модуль имитационного моделирования и  функционально-стоимостного анализа, в 2008 году расширены возможности по проектированию и поддержанию СМК и работе с показателями, в 2011 году реализована интеграция с BPM-системами путём передачи схем процессов в формате XPDL, а также появился модуль контроллинга бизнес-процессов на основе данных ИТ-систем.

Основная задача, которую решает Business Studio, – это создание комплексной модели бизнеса, содержащей следующие элементы:

• Стратегия (Система целей и показателей их достижения);
• Модель бизнес-процессов и их KPI;
• Организационная структура;
• Ресурсы и документы;
• Информационные системы.

В части создания моделей бизнес-процессов Business Studio базируется на методологии SADT (Structured Analysis & Design Technique), в том числе поддерживает нотацию моделирования бизнес-процессов IDEF0. Среди остальных поддерживаемых нотаций: блок-схемы (Process Flowchart, Cross Functional Flowchart), EPC (Event Driven Process Chain). В качестве методической основы для построения моделей бизнес-процессов реальных компаний в продукт интегрированы типовые структуры бизнес-процессов (Process Frameworks) – референтные модели для типичных процессов организаций различных сфер деятельности.

В части создания системы целей и показателей поддерживается методология создания Сбалансированной системы показателей Нортона и Каплана.

Сильной стороной продукта является интегрированность - в одном инструменте собраны наиболее востребованные методики и технологии: BSC/KPI, моделирование бизнес-процессов, имитационное моделирование, функционально-стоимостной анализ, поддержка СМК.

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

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

Продукт позволяет:

• Формализовать стратегию и контролировать достижение стратегических целей;
• Проектировать и оптимизировать бизнес-процессы, а также проведение функционально-стоимостного анализа и имитационного моделирования);
• Проектировать организационную структуру и штатное расписание
• Автоматически формировать и распространять среди сотрудников регламентирующую документацию (документы Microsoft Word, Microsoft Excel, HTML-навигатор);
• Поддерживать внедрение системы менеджмента качества в соответствии со стандартами ISO;
• Формировать технические задания и поддерживать внедрение комплексных информационных систем;
• Продукт целесообразно использовать в проектах: реорганизации бизнеса, оптимизации и регламентации бизнес-процессов, внедрения и сертификации СМК, внедрения комплексных информационных систем .

2. MS Visio

Microsoft Visio предоставляет возможности для быстрого создания деловой графики различной степени сложности: схем бизнес процесса, технических, инженерных рисунков, презентаций, разнообразных вариантов организационных, маркетинговых и технических диаграммэлектрических и электронных схем, систем транспортных коммуникаций и т. д. Основная идея, заложенная в Microsoft Visio,- создать возможность эффективного использования в индивидуальных проектах готовых профессиональных наработок, представленных в виде богатой встроенной коллекции библиотек Visio, в которой весь арсенал элементов разбит по тематическим категориям и скомпонован в трафареты. Таким образом, задача создания необходимой графики сводится к выбору необходимого трафарета и перетаскивания нужной фигуры на страницу документа. На созданные объекты затем легко добавляются цветовые темы, фон и заголовки и получаются профессионально оформленные документы. Особенно привлекательным Visio делает возможность разрабатывать свои собственные библиотеки (Stensils) с графическими фигурами (Master). Интерфейс Visio - традиционный для приложений Windows; многие элементы являются составными частями любой прикладной программы Windows: строка заголовка, панель быстрого доступа, лента с инструментами, рабочее поле, полосы прокрутки, строка состояния и др.

Специфическими для Visio элементами являются: трафареты - панели Фигуры с готовыми профессиональными наработками для выбранной категории элементов, располагающиеся в левой части рабочей области Visio.

Работа с документами Visio - открытие, сохранение документов, импорт и экспорт изображений, а также способы управления многостраничными файлами выполняются стандартными приемами Windows и осуществляется с помощью вкладки Главная.

3. Язык графического описания UML

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

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

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

Преимуществами UML является:

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

Заключение

Итак, в ходе курсовой работы был изучен объектно-ориентированный подход.

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

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

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

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

А также рассмотрели примеры языков программирования, действующих на основе ООП.

Список используемой литературы

1. Николаев Е.И./ Объектно-ориентированное программирование: учебное пособие. – Ставрополь: Изд-во СКФУ/2015-225 с.
2. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К./ Объектно-ориентированное программирование: Учеб. Для вузов/Под ред. Ивановой Г.С. – М.: Изд-во МГТУ им Н.Э. Баумана/ 2001-320 с.
3. Фридман А.Л./ Основы объектно-ориентированной разработки программных систем. – М.: Финансы и статистика/ 2000-192 с.
4. Сорокин А.А./ Объектно-ориентированное программирование: учебное пособие (курс лекций). – Ставрополь: Изд-во СКФУ/ 2014-174 с.
5. Зыков С.В./ Введение в теорию программирования. Объектно-ориентированный подход- М.: Национальный Открытый Университет «ИНТУИТ» /2016-189
6. Радченко Г.И./ Объектно-ориентированное программирование. – Челябинск: Издательский центр ЮУрГУ/ 2013-167 с.
7. Бадд. Т./ Объектно-ориентированное программирование в действии/ 1997-296 c.
8. Ханспетер Мессенбок/ Объектно-ориентированное программирование в Оберон-2. – Springer-Verlag Berlin Heidelberg/ 1993,1994-290 c/