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

Содержание:

Введение

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

1.Основные моменты проектирования

1.1 Сложность программного обеспечения

Учитывая огромное количество и многообразие информационных систем, далеко не все они сложны на столько, как это может показаться с первого взгляда. Даже всего один человек может придумать, спроектировать и воплотить в жизнь, а в дальнейшем успешно сопровождать и использовать программное обеспечение. Причем это может быть как и человек, только начинающий свою карьеру, так и уже состоявшийся профессионал-программист. Это не означает, что эта система не соответствует требованиям заказчика, или же сделана специалистом низкого уровня, вероятнее всего она просто-напросто имеет довольно узкую специализацию^[1]. А ещё жизненный цикл данного ПО как правильно довольно мал, из-за чего целесообразнее разработать новое ПО чем реконструировать имеющееся. Из этого следует, что при создании подобных систем нужно запастись скорее терпением, чем быть гениальным разработчиком, и поэтому имеет смысл обратить внимание на другие процессы.

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

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

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

- сложность предметной области, для которой производится ПО

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

- ПО должно иметь определенную вариативность использования

- описание поведения больших дискретных систем порой не совсем удовлетворительно^[2]

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

Если попытаться анализировать систему крупного океанского лайнера, то можно увидеть всё то многообразие и сложность различных подсистем, которые в свою очередь тоже делятся на подсистемы, которые в свою очередь, как не сложно догадаться, тоже отнюдь не состоят из одной строчки кода. Взять, к примеру, систему освещения, которая в свою очередь делится на системы освещения жилых помещений, подсобных помещений, технических помещений, систему внешнего освещения, добавить к этому ещё и систему аварийной световой сигнализации, которая в свою очередь интегрирована в каждую из вышеупомянутых подсистем. А ведь это только часть общей системы управления лайнером. При этом компания-заказчик будет вносить постоянно какие-либо изменения, так сказать «под себя», требовать, чтобы все системы были удобны, производительны, имели продолжительный срок службы, и были при этом максимально дешевы. Исходя из сложности задач мы и получаем сложность, свойственную ПО^[3].

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

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

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

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

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

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

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

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

1.2. Структура сложных систем

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

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

Первым признаком можно назвать наличие определенной иерархии во взаимодействии различных зависимых друг от друга компонентов системы, которые так же могут быть разделены на другие подсистемы, и так до самых простейших компонентов^[7]. По сути, любую сложную систему можно разобрать по составляющим как конструктор, и собрать ее обратно. Это еще и является показателем работоспособности системы.

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

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

Третьим признаком является то, что связь внутри отдельных модулей сложной системы, как правило, сильнее, чем связь между самими этими модулями. Анализируя взаимодействие, как между модулями, так и внутри самих модулей, разработчики получают более ясную картину функционирования системы в целом. Именно это свойство и позволяет выделить определённое взаимодействие между отдельными компонентами, отделить наиболее взаимозависимые в отдельные модули, тем самым разделив систему на подсистемы, и работать над каждой подсистемой отдельно.

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

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

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

Этот пример наводит на мысль, что мы обращались с термином иерархия в весьма приблизительном смысле. Наиболее интересные сложные системы содержат много разных иерархий. На корабле, например, можно выделить несколько систем: освещения, управления курсом, и многие другие. Такая градация дает структурную иерархию типа «быть частью»^[9].

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

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

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

Рисунок 1-1. Каноническая форма сложной системы.

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

Большинство из нас формально обучено структурному проектированию «сверху вниз», и мы воспринимаем декомпозицию как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. Представим, что у этой задачи существует некий другой способ декомпозиции. Мы разделили систему, выбрав в качестве критерия декомпозиции принадлежность ее элементов к различным абстракциям данной проблемной области. Хотя обе схемы решают одну и ту же задачу, но они делают это каждая по-своему. Во второй декомпозиции мир представлен совокупностью автономных действующих лиц, которые взаимодействуют друг с другом, чтобы обеспечить поведение системы, соответствующее более высокому уровню. «Получить изменения в отформатированном виде» больше не присутствует в качестве независимого алгоритма. Это действие существует теперь как операция над объектом «Файл изменений». Эта операция создает другой объект - «Изменения в карте». Тем самым, каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Каждый объект совершает определенные действия, и мы можем, отправив им какое-то сообщение, попросить их совершить какие-либо действия. Так как наша декомпозиция основана на объектах, а не на алгоритмах, мы называем ее объектно-ориентированной декомпозицией. Какая декомпозиция сложной системы позволит справится с задачей лучше - по алгоритмам или по объектам? Тут есть один небольшой нюанс, а именно то, что правильный ответ на этот вопрос заключается в том, что важны оба аспекта^[12]. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Все же мы не можем сконструировать сложную систему одновременно двумя способами, тем более, что эти способы по сути ортогональны.  Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения. Практика, однако, показывает, что полезнее начинать с объектной декомпозиции^[13]. Такое начало поможет нам лучше справиться с приданием организованности сложности программных систем. Выше этот объектный подход помог нам при описании таких непохожих систем, как компьютер и крупная компания. Объектная декомпозиция имеет несколько чрезвычайно важных преимуществ перед алгоритмической. Объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств. Объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируется на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены. Более того, объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.

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

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

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

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

- процесс - правила проектирования модели;

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

Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.

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

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

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

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

Рисунок 1-2. Объектно-ориентированные модели.

1.3 Объектная модель

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

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

Что же представляет собой объектно-ориентированное программирование?

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

В данном определении можно выделить три части:

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

- каждый объект является экземпляром какого-либо определенного класса. 

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

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

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

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

- Объекты относятся к соответствующим классам.

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

Поддержка наследования в таких языках означает возможность установления отношения «is-a», например, красная роза - это цветок, а цветок - это растение^[19]. Языки, не имеющие таких механизмов, нельзя отнести к объектно-ориентированным. В принципе, такие языки можно назвать объектными, но не объектно-ориентированными. Согласно этому определению объектно-ориентированными языками являются Smalltalk, Object Pascal, C++ и CLOS, a Ada - объектный язык. Но, поскольку объекты и классы являются элементами обеих групп языков, желательно использовать и в тех, и в других методы объектно-ориентированного проектирования.

2. Объектно-ориентированное проектирование

2.1 Классы и объекты

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

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

Из этого следует, что можно расширить неформальное определение объекта какой-то новой идеей: существование в пространстве и времени определяется тем, что объект моделирует некоторую часть окружающей действительности. В языке программирования Simulа был впервые введен термин «объект» в программном обеспечении, так что он применялся для моделирования реальности^[20].

Типы объектов, которые вызывают интерес при проектировании программных систем, не исчерпываются объектами реального мира. На этапе проектирования можно ввести другие безусловно важные типы объектов, взаимодействие их друг с другом должно служить механизмом отображения поведения более высокого уровня. Исходя из этого, мы можем дать более конкретное определение. Объект - это конкретный опознаваемый предмет, сущность или единица (абстрактная или реальная), который должен иметь четко определенное функциональное назначение в конкретной предметной области. Если брать в расчет более общий план, то объект может быть определен как нечто, что имеет четко очерченные границы^[21].

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

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

Рассмотрим систему пространственного проектирования CAD/CAM. Два тела, например, сфера и куб, имеют как правило нерегулярное пересечение. Хотя эта линия пересечения не существует отдельно от сферы и куба, она все же является самостоятельным объектом с четко определенными концептуальными границами^[22].

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

Важно не забывать, что объект - это нечто, имеющее четко определенные границы, но этого недостаточно, чтобы отделить один объект от другого или дать оценку качества абстракции. На основе имеющегося опыта можно сказать, что объекты имеют определенные свойства. Объект обладает состоянием, поведением и идентичностью, структура и поведение схожих объектов определяет общий для них класс, термины «экземпляр класса» и «объект» взаимозаменяемы^[23]. Состояние объекта характеризуется перечнем статистических всех свойств данного объекта и текущими динамическими значениями каждого из этих свойств.

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

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

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

В объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и входят в определение класса объекта. В C++ они называются функциями-членами. Можно использовать эти термины как синонимы^[24].

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

Наиболее интересны те объекты, состояние которых не статично, их состояние изменяется и запрашивается операциями.

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

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

Класс - это некое множество объектов, имеющих общую структуру и общее поведение.

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

Важно отметить, что классы, как их понимают в большинстве существующих языков программирования, необходимы, но не достаточны для декомпозиции сложных систем. Некоторые абстракции так сложны, что не могут быть выражены в терминах простого описания класса. Например, на достаточно высоком уровне абстракции графический интерфейс пользователя, база данных или система учета как целое, это явные объекты, но не классы. Можно попытаться выразить такие абстракции одним классом, но повторной используемости и возможности наследования не получится. Иметь громоздкий интерфейс - плохая практика, так как большинство клиентов использует только малую его часть. Более того, изменение одной части этого гигантского интерфейса требует обновления каждого из клиентов, независимо от того, затронуло ли его это изменение, по сути. Вложенность классов не устраняет этих проблем, а только откладывает их. Лучше считать их некими совокупностями, по-другому кластерами, сотрудничающих классов^[26]. Такие кластеры можно назвать как компонентами, так и, по сути, категориями классов. Состояние объекта задается в его классе через определения констант или переменных, помещаемые в его защищенной или закрытой части. Тем самым они инкапсулированы, и их изменения не влияют на клиентов. В поведении простых классов можно разобраться, изучая операции их открытой части. Однако поведение более интересных классов, такое как перемещение объекта класса DisplayItem или составление расписания для экземпляра класса TemperatureController, включает взаимодействие разных операций, входящих в класс. Как уже говорилось выше, объекты таких классов действуют как маленькие машины, части которых взаимодействуют друг с другом, и так как все такие объекты имеют одно и то же поведение, можно использовать класс для описания их общей семантики, упорядоченной по времени и событиям. В целом мы можем описывать динамику поведения объектов, используя модель конечного автомата.

2.2 Основные принципы объектно-ориентированной модели

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

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

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

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

Существует несколько типов абстракций, начиная с объектов, которые почти точно соответствуют реалиям предметной области, и кончая объектами, не имеющими право на существование. Имеет смысл подробнее остановиться на каждом основном типе абстракции^[28].

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

Абстракция поведения. В данной абстракции объект состоит из обобщенного множества операций.

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

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

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

Однако стоит заметить, что понятия операция, метод и функция-член происходят от различных традиций программирования, реализованных в таких языках как Ada, Smalltalk и C++ соответственно. Фактически они обозначают одно и то же и в дальнейшем будут взаимозаменяемы.

Все абстракции обладают как статическими, так и динамическими свойствами. Например, файл как объект требует определенного объема памяти на конкретном устройстве, имеет имя и содержание. Эти атрибуты являются статическими свойствами. Конкретные же значения каждого из перечисленных свойств динамичны и изменяются в процессе использования объекта, а именно, файл можно увеличить или уменьшить, изменить его имя и содержимое. В процедурном стиле программирования действия, изменяющие динамические характеристики объектов, составляют суть программы. Любые события связаны с вызовом подпрограмм и с выполнением операторов. Стиль программирования, ориентированный на правила, характеризуется тем, что под влиянием определенных условий активизируются определенные правила, которые в свою очередь вызывают другие правила, и так далее. Объектно-ориентированный стиль программирования связан с воздействием на объекты, например в терминах Smalltalk с передачей объектам сообщений. Так, операция над объектом порождает некоторую реакцию этого объекта. Операции, которые можно выполнить по отношению к данному объекту, и реакция объекта на внешние воздействия определяют поведение этого объекта^[30].

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

Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры. Иерархия - это упорядочение абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов, а именно иерархия «is-a», и структура объектов - иерархия «part of».

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

Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. Не всегда очевидно, как в полной мере использовать преимущества такого языка, как C++. Существенно повысить эффективность и качество кода можно просто за счет использования C++ в качестве «улучшенного С» с элементами абстракции данных. Однако гораздо более значительным достижением является введение иерархии классов в процессе проектирования. Именно это называется ООП, и именно здесь преимущества C++ демонстрируются наилучшим образом. Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, C++, CLOS и Ada вне объектной модели, их наиболее сильные стороны либо игнорируются, либо применяются неправильно.

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

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

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

Наконец, объектная модель ориентирована на человеческое восприятие мира, или, многие люди, не имеющие понятия о том, как работает компьютер, находят вполне естественным объектно-ориентированный подход к системам^[32].

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

Заключение

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

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

1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. Пер. с англ. М.: Бином, СПб. Невский диалект, 1998.
2. https://studfiles.net
3. Давыдов В.И. Кунгурцев А.Б. Объектно-ориентированное программирование. Одесса. Автограф, 2003.
4. Кунгурцев О.Б. Основы программирования на языке Java.Середовище Net Beans. Одесса. ВМВ, 2006.
5. Уткин В. Б. Информационные системы в экономике. Учебник для студентов высших учебных заведений. М.: Издательский центр «Академия», 2004.
6. https://studopedia.ru
7. Васильев А.Н. Java. Объектно-ориентированное программирование. М.- СПБ, 2014.
8. Дж. Кьоу Объектно-ориентированное программирование. Дж. Кьоу, М. Джеанини. М.- СПБ, 2015.
9. https://javarush.ru
10. https://devcolibri.com
11. Иванова Г.С. Объектно-ориентированное программирование / Г.С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев. М.: МГТУ им. Н. Э. Баумана, 2014.
12. Хорев П.Б. Объектно-ориентированное программирование / П.Б. Хорев. - М.: Academia, 2017
13. Татьяна Павловская C/C++. Процедурное и объектно-ориентированное программирование. Учебник / Татьяна Павловская. - М.: СПБ, 2015.
14. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000.

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

2. https://studfiles.net ↑

3. Дж. Кьоу Объектно-ориентированное программирование. Дж. Кьоу, М. Джеанини. М.- СПБ, 2015. ↑

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

5. https://javarush.ru ↑

6. Васильев А.Н. Java. Объектно-ориентированное программирование. М.- СПБ, 2014 ↑

7. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000 ↑

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

9. Уткин В. Б. Информационные системы в экономике. Учебник для студентов высших учебных заведений. М.: Издательский центр «Академия», 2004 ↑

10. https://studfiles.net ↑

11. https://studopedia.ru ↑

12. Дж. Кьоу Объектно-ориентированное программирование. Дж. Кьоу, М. Джеанини. М.- СПБ, 2015. ↑

13. Уткин В. Б. Информационные системы в экономике. Учебник для студентов высших учебных заведений. М.: Издательский центр «Академия», 2004. ↑

14. Давыдов В.И. Кунгурцев А.Б. Объектно-ориентированное программирование. Одесса. Автограф, 2003. ↑

15. Васильев А.Н. Java. Объектно-ориентированное программирование. М.- СПБ, 2014. ↑

16. https://devcolibri.com ↑

17. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. ↑

18. Татьяна Павловская C/C++. Процедурное и объектно-ориентированное программирование. Учебник / Татьяна Павловская. - М.: СПБ, 2015 ↑

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

20. https://studopedia.ru ↑

21. Кунгурцев О.Б. Основы программирования на языке Java.Середовище Net Beans. Одесса. ВМВ, 2006. ↑

22. Хорев П.Б. Объектно-ориентированное программирование / П.Б. Хорев. - М.: Academia, 2017 ↑

23. https://studfiles.net ↑

24. Иванова Г.С. Объектно-ориентированное программирование / Г.С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев. М.: МГТУ им. Н. Э. Баумана, 2014. ↑

25. Дж. Кьоу Объектно-ориентированное программирование. Дж. Кьоу, М. Джеанини. М.- СПБ, 2015. ↑

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

27. https://studopedia.ru ↑

28. Хорев П.Б. Объектно-ориентированное программирование / П.Б. Хорев. - М.: Academia, 2017 ↑

29. Уткин В. Б. Информационные системы в экономике. Учебник для студентов высших учебных заведений. М.: Издательский центр «Академия», 2004. ↑

30. Иванова Г.С. Объектно-ориентированное программирование / Г.С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев. М.: МГТУ им. Н. Э. Баумана, 2014. ↑

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

32. https://javarush.ru ↑