Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

В начале 70-х гг. 20 века был отмечен кризис программирования (software crisis). Выражалось тем, что масштабные проекты стали выполнятся с существенными задержками или с перерасходом средств на разработку. При этом достаточно большое количество программ не обладали требуемыми функциональными возможностями, в следствие чего их качество не устраивало потребителей.

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

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

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

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

1.1. Подходы к анализу и проектированию информационных систем

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

• структурная (процессно-ориентированная), основанная на каскадной (водопадной) модели жизненного цикла ИС (рисунок 1);

Рисунок 1. Каскадная модель жизненного цикла ИС

• объектно-ориентированная, основанная на итеративной модели ЖЦ ИС (рисунок 2).

Рисунок 2. Итеративная модель жизненного цикла ИС

Структурный анализ (Structured Analysis, SA) и структурное проектирование (Structured Design, SD) – результат появившегося в 1970-х структурного программирования, развивался из классического системного анализа. Методологии структурного анализа используют каскадную (водопадную) модель ЖЦ ИС; самые известные и используемые методологии структурно анализа – SADDT, SSADM. Методы структурного анализа дорабатывались и используются уже на протяжении многих лет.

Сравнительно позже появились и стали невероятно популярны объектно- ориентированные языки. По мере нарастания их популярности была разработана методология помощи программисту в разработке приложений с использованием объектно-ориентированных языков. Эта методология стала известна как объектно-ориентированный анализ и проектирование (оbject-oriented analysis and design, OOAD).

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

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

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

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

• понятное и относительно простое визуальное представление системы, легко понимаемое как пользователями, так и разработчиками;

• акцент на командной работе;

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

• допускают использование средств проверки требований;

• SSAD и IDEF0 – классические, широко известные методологии в области проектирования ИС, существующие на протяжении длительного времени и достаточно «зрелые»;

Недостатки структурных методологий:

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

• поскольку SSAD и SSADM неитеративны, то изменение требований может привести к перезапуску всего процесса разработки;

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

Преимущества объектно-ориентированных методологий:

• упрощение и ускорение программной реализации системы по сравнению со структурными методологиями;

• повторное использование кода в других проектах, благодаря независимости объектов и инкапсуляции, что сокращает стоимость проектирования, программирования и проверки; повторное использование кода может способствовать улучшению качества последующих проектов («Если 90% нового приложения содержит проверенные компоненты, то только 10% кода должна быть проверена с нуля» (Vivek Shah);

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

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

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

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

Недостатки объектно-ориентированных методологий:

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

• чрезмерная фокусировка на коде;

• не так много внимания уделяется командной работе, как в структурных методологиях;

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

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

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

• требует новый вид управления проектами, который включает различные типы анализа, отличные от традиционного функционального подхода декомпозиции. Следовательно, для команд разработчиков проекта, которые имеют долгую историю использования методологий SSAD и SSADM, переход к методологии OOAD является чрезвычайно сложным, длительным и трудоемким (Hantos, 2005);

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

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

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

В одной из опубликованных в 2001 году работ (Sircar, Nerur, and Mahapatra) было сделано интересное замечание: «недавний опрос ИТ менеджеров показал, что 39% организаций приняли OO технологии в той или иной форме. Тем не менее, ОО методологии проектирования используются только в 5% ИТ проектов»

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

1.2. Сущность объектно-ориентированного подхода

Термин «объект» или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки:

  • архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);
  • объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);
  • объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);
  • теории баз данных (модели «сущность-связь»);
  • систем искусственного интеллекта (фреймы).

В процесс создания программ термин «объект» впервые был введен в языке Simula 67 при определении сущностей предметной области.

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

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

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

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

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

Класс – это совокупность объектов, имеющих общую структуру и поведение. Фактически, класс – это шаблон, на основе которого генерируются однотипные объекты. В качестве синонима понятия «объект» часто употребляют понятие «экземпляр класса».

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

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

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

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

Полиморфизм – принцип построения определяет возможность принимать различные внешние формы или функциональность (поведение) в зависимости от контекста. Например, методы Paint() (отрисовать) или DefineS() (определить площадь), определенные в родительском классе «фигура», для классов «эллипс» и «прямоугольник» должны быть реализованы по-разному."

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

1.3 Базовые составляющие объектно-ориентированного подхода

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

унифицированный процесс;

унифицированный язык моделирования;

шаблоны проектирования.

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

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

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

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

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

  1. Описание системы в виде объектов больше соответствует содержательному смыслу предметной области.
  2. Сущности предметной области, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга.
  3. Объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней связности и меньшей связности между компонентами системы.
  4. Объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться автономности обработки атрибутов различных экземпляров класса.
  5. Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации генерации кода. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая генерация кода (например, экранов или функций обработки данных) возможна лишь в определенных случаях.

2. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ ИНФОРМАЦИННЫХ СИСТЕМ.

2.1 Суть анализа и проектирования в ООП

Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в "… рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И, наконец, в процессе конструирования (construction) или объектно-ориентированного программирования (object-oriented programming) обеспечивается реализация разработанных компонентов и классов.

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

Далее следует объектно-ориентированный анализ предметной области (object-oriented domain analysis). Задачей этого этапа является определение видов деятельности участников процесса и составлении концептуальной модели (conceptual model), которая отражает различные категории элементов предметной области. Причем не только виды деятельности участников, но и все относящиеся к делу понятия."[1]

Следующий этап - это объектно-ориентированное проектирование (object-oriented design), при котором основное внимание сосредоточено на распределении обязанностей. Распределение обязанностей (responsibility assignment) означает выделение задач и обязанностей различных программных объектов в приложении.

Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы. Дело в том, что единственный вид деятельности, без которого невозможно обойтись. К тому же он оказывает определяющее влияние на робастность, масштабируемость, расширяемость и возможность повторного использования компонентов. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов (design class diagram) и диаграмм взаимодействий (collaboration diagram).

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

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

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

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

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

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

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

https://www.intuit.ru/EDI/23_04_17_1/1492899714-28128/tutorial/356/objects/3/files/03_01.gif

Рисунок 3. Изображение класса на диаграмме

2.3 Язык проектирования UML

На сегодняшний день существует более тридцати объектно- ориентированных методов проектирования (например, IDEF4 – Object-Oriented Design – методология ООП, позволяющая отображать структуру объектов и принципы их взаимодействия) с множеством различных нотаций представления объектных моделей.

Два самых популярных стандартных языка объектно-ориентированного моделирования – UML (The Unified Modeling Language) и SysML.

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

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

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

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

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей следующие набор диаграмм: структурные диа- граммы (Structure Diagrams); диаграммы поведения (Behavior Diagrams);диаграммы взаимодействия (Interaction Diagrams)

UML фокусируется не трех архитектурных видениях системы:

• функциональном (описывает внешнее поведение системы с точки зрения пользователя с помощью use-case диаграмм);

• статическом (в терминах атрибутов, методов, связей, классов, сообщений с помощью CRC cards, class diagrams, object diagrams);

• динамическом (sequence diagrams, collaboration diagrams, statecharts) и имеет практическое значение в описании сервисно-ориентированных архитектур (SOAs).

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка уточнялась и была расширена для поддержки методологии Model Driven Development, MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

3. СРЕДСТВА ДЛЯ РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ
С ИСПОЛЬЗОВАНИЕМ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

3.1 C++

Си++ (англ. C++) — компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования.

Началом разработки данного языка является 1979 год. При появлении язык назывался “C с классами”, однако позже он получил имя C++. Дав такое название, разработчики подчеркнули, с одной стороны, что язык основывается на языке C, и, с другой стороны, что он превосходит существенно по возможностям своего родителя. Основное дополнение C++ заключалось в языковом обеспечении работы с классами. Вместе с тем создатели C++ стремились сохранить совместимость с C: синтаксис первого основан на синтаксисе последнего, и большинство программ на C будут работать и как C++.

Первый выпуск C++ для коммерческого использования состоялся в 1985 году, вместе с публикацией книги “The C++ Programming Language”, которая на долгое время стала его неофициальным стандартом. В 1989 году вышла вторая версия языка в сопровождении книги “The Annotated C++ Reference Manual”.

В 1990-х годах язык стал одним из наиболее широко используемых языков программирования общего назначения. Первым официальным стандартом языка стал ISO/IEC 14882:1998, более известный как C++98. В 2003 году была принята его дополненная версия, C++03, а в 2005 году был опубликован “Library Technical Report 1” (сокращенно TR1) — документ, описывающий расширения стандартной библиотеки. TR1 не является стандартом, но большинство актуальных компиляторов C++ поддерживает его. Наконец, в 2011 году был принят текущий стандарт, C++11.

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

После описание класса необходимо описать переменную типа class. Это описание имеет следующий формат:

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

  • открытые, также называемые публичными, (public). Их вызов осуществляется с помощью оператора . («точка»);
  • закрытые, или приватные, (private), доступ к которым возможен только с помощью открытых методов;
  • защищенные (protected) методы, являются промежуточными между private и public. Их мы рассмотрим в уроке про наследование.

Класс — это фактически новый тип данных. Для создания переменной типа класс служит оператор:

name_class name;

Здесь name_class — имя класса, name — имя переменной. В дальнейшим переменную типа classбудем называть объект или экземпляр класса. Объявление переменной типа class (в нашем примере переменная name типа name_class) называется созданием объекта.

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

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

В качестве примера, рассмотрим класс complex для работы с комплексными числами. В классе complex будут члены класса:

  • double x — действительная часть комплексного числа;
  • double y — мнимая часть комплексного числа.

Также в нем будут методы:

  • double modul() — функция вычисления модуля комплексного числа;
  • double argument() — функция вычисления аргумента комплексного числа;
  • void show_complex() — функция выводит комплексное число на экран.

Ниже приведен текст класса:

Чаще всего разработку программ с использованием данного языка выполняют в среде MS Visual Studio, последняя версия данной оболочки вышла в 2017 году (см сайт – Microsoft.com). Использование данной среды позволяет эффективно разрабатывать программы и программные комплексы любой сложности, функционирующих под управлением операционной с системы Windows.

3.2 Java

Java — объектно-ориентированный язык программирования, разрабатываемый компанией Sun Microsystems с 1991 года и официально выпущенный 23 мая 1995 года. Изначально новый язык программирования назывался Oak (James Gosling) и разрабатывался для бытовой электроники, но впоследствии был переименован в Java и стал использоваться для написания апплетов, приложений и серверного программного обеспечения.

Программы на Java могут быть транслированы в байт-код, выполняемый на виртуальной java-машине (JVM) — программе, обрабатывающей байт-код и передающей инструкции оборудованию, как интерпретатор, но с тем отличием, что байт-код, в отличие от текста, обрабатывается значительно быстрее.

Язык Java зародился как часть проекта создания передового программного обеспечения для различных бытовых приборов. Реализация проекта была начата на языке C++, но вскоре возник ряд проблем, наилучшим средством борьбы с которыми было изменение самого инструмента — языка программирования. Стало очевидным, что необходим платформо-независимый язык программирования, позволяющий создавать программы, которые не приходилось бы компилировать отдельно для каждой архитектуры и можно было бы использовать на различных процессорах под различными операционными системами.

Язык Java потребовался для создания программного обеспечения, которое предполагает выполнения в бразерах. На практике языковые конструкции языка, определенные для языка Java, похожи на синтаксис языка C++. В Java используются практически точно такие же соглашения для объявления переменных, передачи параметров, операторов, а также и для управления потоком выполнением кода. В Java добавлены все хорошие черты C++.

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

class имя_класса extends имя_суперкласса { type переменная1_объекта:

type переменная2_объекта:

type переменнаяN_объекта:

type имяметода1(список_параметров) { тело метода;

}

type имяметода2(список_параметров) { тело метода;

type имя методаМ(список_параметров) { тело метода;

}

}

Ключевое слово extends указывает на то, что «имя_класса» — это подкласс класса «имя_суперкласса». Во главе классовой иерархии Java стоит единственный ее встроенный класс — Object. Если вы хотите создать подкласс непосредственно этого класса, ключевое слово extends и следующее за ним имя суперкласса можно опустить — транслятор включит их в ваше определение автома­тически.

Пример реализации класса на Java на рис. 3.2.

Рисунок 3.2 – Пример реализации класса в JAVA

Отличием IDE-оболочек для разработки JAVA-программ является их кросс-платформенность, т.е. возможность формирования кода, который может работать под управлением любой операционной системы – Windows, Linux, MacOS. Широкое применение находят инструментальные оболочки для создания приложений для мобильных телефонов. Наиболее используемой оболочкой является Eclipse, которая в настоящее время сопровождается фирмой ORACLE.

3.3 Ruby

Ruby — интерпретируемый объектно-ориентированный язык программирования, созданный в 1995 году Юкихиро Мацумото по прозвищу Мац. Автор ставил себе целью создать истинно объектно-ориентированный язык, что у него и получилось. Ruby имеет строгую динамическую типизацию. Особенностью языка является то, что в нем можно изменить любой класс в любое время. Как и во многих современных языках, в Ruby все данные является объектом (даже классы являются объектом класса Class), а все функции — методами.

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

Пример реализации класса на Ruby на рис.3.3.

Рисунок 3.3 – Пример реализации класса в Ruby

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

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

  • В Ruby есть конструкции для обработки исключений, как в Java или Python, которые позволяют проще работать с ошибками.
  • В Ruby представлен настоящий mark-and-sweep (пометь и отчисти) сборщик мусора для всех Ruby объектов. Не нужно вручную отслеживать количество ссылок в сторонних библиотеках. Как говорит Matz, “Это полезней для вашего здоровья.”
  • Писать расширения на C в Ruby проще чем в Perl или Python при помощи очень элегантного API для вызова Ruby из C. Он включает в себя вызовы для встраивания Ruby в программное обеспечение, чтобы использовать его как скриптовый язык. Также доступен интерфейс SWIG.
  • Ruby может подгружать сторонние библиотеки динамически, если позволяет операционная система.
  • В Ruby реализованы независимые от операционной системы потоки. Таким образом, на любых платформах, где вы запускаете Ruby, вы также имеете возможность использовать многопоточность, не зависимо от того, поддерживает ли данная система потоки или нет. Вы можете использовать возможности многопоточности даже в MS-DOS!
  • Ruby отличается высокой переносимостью: он был разработан большей частью на GNU/Linux, но работает на многих типах UNIX, Mac OS X, Windows, DOS, BeOS, OS/2, и так далее.

ЗАКЛЮЧЕНИЕ

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

СПИСОК ЛИТЕРАТУРЫ

  1. Иванов А.Г., Карпова А.В., Семик В.П., Филинов Ю.Е. Объектно-ориентированная среда программирования. Системы и средства информатики. Вып.2. - М.: Наука, 2011.
  2. Козырев А.А. Информационные технологии в экономике и управлении – СПб.: Изд-во Михайлова В.А., 2003
  3. Уткин В.Б., Балдин К.В. Информационные системы и технологии в экономике. – М.: ЮНИТИ, 2007.
  4. Stroustrup D. The C++ Programming Language. Addison-Wesley, 1986.
  5. Хотинская Г.И. Информационные технологии управления. – М.: Дело и Сервис (ДИС), 2003.