Объектно ориентированное проектирование реферат

Обновлено: 04.07.2024

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

Содержание

ВВЕДЕНИЕ………………………………………. ………………. …….3
Глава 1. История объектно-ориентированного программирования……4
Глава 2. Объекты в объектно-ориентированном программировании….9
Глава 3. Инкапсуляция в объектно-ориентированном программировании………………………………………………………………11
Глава 4. Наследование и виртуальные методы………………………. 12
Глава 5. Динамическое создание объектов и полиморфизм………………………………………………………….…………16
ЗАКЛЮЧЕНИЕ ………………………………………………………..…18
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ ………………….……. 20

Прикрепленные файлы: 1 файл

РЕФЕРАТ объектно-ориентированное программирование.doc

Министерство образования Российской Федерации

Министерство сельского хозяйства Российской Федерации

Иркутская государственная сельскохозяйственная академия

Кафедра информатики и математического моделирования

по дисциплине: Парадигмы программирования

на тему: Объектно-ориентированное программирование

Глава 1. История объектно-ориентированного программирования……4

Глава 2. Объекты в объектно-ориентированном программировании….9

Глава 3. Инкапсуляция в объектно-ориентированном программировании…………………………………… …………………………11

Глава 4. Наследование и виртуальные методы………………………. 12

Глава 5. Динамическое создание объектов и полиморфизм………………………………………………… ……….…………16

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ ………………….……. 20

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

1. абстракции – формальное о качествах или свойствах предмета путем мысленного удаления некоторых частностей или материальных объектов;

2. инкапсуляции – механизма, связывающего вмести код и данные, которыми он манипулирует, и защищающего их от внешних помех и некорректного использования;

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

4. полиморфизма – свойства, позволяющего использовать один и тот же интерфейс для общего класса действий.

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

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

- определение закрытых данных (данных состояния) для выбранных объектов;

- определение второстепенных объектов и их закрытых данных;

- определение иерархической системы классов, представляющих выбранные объекты;

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

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

- кодирование, отладка, компоновка и тестирование.

Глава 1. История объектно-ориентированного программирования

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

Начало развитию объектно-ориентированного подхода положил язык Simula 67, который был разработан в конце 60-х гг. в Норвегии. Несмотря на то, что язык намного опередил свое время, современники (программисты 60-х гг.) оказались не готовы воспринять ценности языка Simula 67, и он не выдержал конкуренции с другими языками программирования (прежде всего, с языком Fortran).

Но достоинства языка Simula 67 были замечены некоторыми программистами, и в 70-е гг. было разработано большое число экспериментальных объектно-ориентированных языков программирования. В результате исследования этих языков были разработаны современные объектно-ориентированные языки программирования: C++, Ada, Smalltalk и др.

Наиболее распространенным объектно-ориентированным языком программирования является язык C++. Он возник на базе соединения языков С и Simula. С++ был разработан в начале 80-х Бьерном Страуструпом, сотрудником компании AT&T. Все эти годы язык интенсивно развивался, и, наконец, в августе 1998 г. был принят международный стандарт языка С++.

Разработка новых объектно-ориентированных языков программирования продолжается и в настоящее время. Например, с 1995 г. стал широко распространяться объектно-ориентированный язык программирования Java, ориентированный на сети компьютеров и, прежде всего, на Internet.

Вместе с развитием объектно-ориентированного программирования стали развиваться и объектно-ориентированные методы разработки программного обеспечения, охватывающие стадии анализа и проектирования. Среди общепризнанных объектно-ориентированных подходов к анализу и проектированию следует выделить методы Г. Буча, Д. Рамбо, А. Джекобсона, Шлеера-Меллора и Коуда-Йордона. В результате объединения усилий первых трех авторов появился на свет унифицированный язык моделирования UML, который в 1997 г. был принят в качестве стандарта консорциумом Object Management Group и получил широкое распространение в сфере производства программного обеспечения.

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

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

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

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

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

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

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

– уменьшение сложности программного обеспечения;

– повышение его надежности;

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

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

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

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

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

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

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

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

- все объекты подчинены и согласовываются с одним и тем же набором правил и линий поведения;

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

Каждый класс должен иметь уникальное и значимое имя.

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

Операция (метод) – это процедура (или функция), задающая последовательность действий любого представителя класса в некоторой ситуации.

2. Унифицированный язык моделирования

История развития унифицированного языка моделирования – UnifiedModelingLanguage (UML), – берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из RationalSoftwareCorporation начали работу по унификации методов Booch и ObjectModelingTechnique (ОМТ). Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы.

Компания RationalSoftware вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как DigitalEquipmentCorp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, RationalSoftware, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0.

Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный выше документ защищен законом об авторском праве. В то же время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев, о чем следует упомянуть в данном контексте.

Следует отметить внимание гиганта компьютерной индустрии компании Microsoft к технологии UML. Еще в октябре 1996 г. Microsoft и RationalSoftwareCorporation объявили о своем стратегическом партнерстве, которое, по их общему мнению, способно оказать решающее влияние на рынок средств объектно-ориентированной разработки программ. При этом Microsoft лицензировала у RationalSoftware некоторые технологии визуального моделирования, в результате чего был разработан MicrosoftVisualModelerforVisualBasic. В свою очередь RationalSoftware лицензировала у MicrosoftVisualBasic и MicrosoftRepository, разрабатываемые вместе с TexasInstruments. При создании языка UML Microsoft внесла свой вклад в интеграцию UML со своими стандартами типа ActiveX и СОМ и в использование языка UML со своей технологией MicrosoftRepository.

В настоящее время RationalSoftwareCorporation объединила свои усилия по совершенствованию технологии UML с компанией IBM.

3. Представление класса

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


Рисунок 3 – Графическое изображение класса на диаграмме классов

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

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


Рисунок 4 – Примеры графического изображения классов на диаграмме

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

Атрибуты

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


Рисунок 5 – Структура задания атрибута

Квантор видимости может принимать одно из трех возможных значений и отображается при помощи специальных символов:

Квантор видимости может быть опущен. Отсутствие квантора видимости обычно трактуется как private. Вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.

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

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

[нижняя_граница1. верхняя_граница1, нижняя_граница2. верхняя_грашца2,…, нuжняя_гpaнuцa k. верхняя_граница k],

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

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

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

Операция

В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, структура которой приведена на рисунке 6:


Рисунок 6 – Структура задания операции

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


Рисунок 7 – Структура задания параметра

Здесь вид параметра – есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается.

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

параллельная (concurrent) – данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели.

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

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


Рисунок 8 – Пример задания класса

4. Представление отношения между классами

Если класс оказывает влияние на другой класс, то на диаграмме эта взаимосвязь (отношение) между классами изображается соединительной линией. Анализ разновидностей взаимосвязей (в дальнейшем отношений) позволяет выделить следующие:

- отношение зависимости (dependency relationship);

- отношениеассоциации (association relationship);

- отношениеобобщения (generalization relationship);

- отношение реализации (realization relationship).

Каждое из этих отношений имеет собственное графическое представление на диаграмме.

Отношение зависимости

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


Рисунок 9 – Графическое изображение отношения зависимости


Рисунок 10 – Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_A и Класс_Б)

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

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

Отношение ассоциации

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


Рисунок 11 – Графическое изображение отношения бинарной ассоциации

Как уже упоминалось, отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации является частью ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемешаться вместе с ними. Одним из таких дополнительных обозначений является имя роли отдельного класса, входящего в ассоциацию. Имя роли представляет собой строку текста рядом с концом ассоциации для соответствующего класса. Она указывает специфическую роль, которую играет класс, являющийся концом рассматриваемой ассоциации. Имя роли не является обязательным элементом обозначений и может отсутствовать на диаграмме.

Отношение агрегации


Рисунок 12 – Графическое изображение отношения агрегации

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


Рисунок 13 – Диаграмма классов для иллюстрации отношения агрегации

Отношение композиции

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


Рисунок 14 – Графическое изображение отношения композиции


Рисунок 15 – Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Отношение обобщения

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

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


Рисунок 16 – Графическое изображение отношения обобщения


Рисунок 17 – Фрагмент диаграммы классов с отношением обобщения

Рядом со стрелкой обобщения может размещаться строка текста, указывающая на некоторые дополнительные свойства этого отношения. В версии MSUML строка задает стереотип отношения с помощью слов: extends , inherits , private , protected , subclass , subtype , uses .


Рисунок 18 – Пример диаграммы классов

1 . Уоссермен Ф., Нейрокомпьютерная техника, – М., Мир, 1992.

2 . Горбань А.Н. Обучение нейронных сетей. – М.: ПараГраф, 1990

3 . Горбань А.Н., Россиев Д.А. Нейронные сети на персональном компьютере. – Новосибирск: Наука, 1996

4 . Gilev S.E., Gorban A.N., Mirkes E.M. Several methods for accelerating the training process of neural networks in pattern recognition // Adv. Modelling & Analysis, A. AMSE Press. – 1992. – Vol.12, N4. – P.29–53

5 . С. Короткий. Нейронные сети: алгоритм обратного распространения.

6 . С. Короткий, Нейронные сети: обучение без учителя. Artificial Neural Networks: Concepts and Theory, IEEE Computer Society Press, 1992.

8 . Лорьер Ж.Л. Системы искусственного интеллекта. – М.: Мир, 1991. – 568 с.

9 . Искусственный интеллект. – В 3-х кн. Кн. 2. Модели и методы: Справочник/ Под ред. Поспелова Д.А. – М.: Радио и связь, 1990. – 304 с.

10 . Бек Л. Введение в системное программирование. – М.: Мир, 1988.

11. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. – К.: Диалектика, 1993. – 240 с.

Основы объектно-ориентированного проектирования ( реферат , курсовая , диплом , контрольная )

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

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

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

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

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

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

все объекты подчинены и согласовываются с одним и тем же набором правил и линий поведения;

между объектами одного класса нет связей.

Каждый класс должен иметь уникальное и значимое имя.

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

Операция (метод) — это процедура (или функция), задающая последовательность действий любого представителя класса в некоторой ситуации.

2. Унифицированный язык моделирования

История развития унифицированного языка моделирования — Unified Modeling Language (UML), — берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и Object Modeling Technique (ОМТ). Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы.

Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0.

Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный выше документ защищен законом об авторском праве. В то же время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев, о чем следует упомянуть в данном контексте.

Следует отметить внимание гиганта компьютерной индустрии компании Microsoft к технологии UML. Еще в октябре 1996 г. Microsoft и Rational Software Corporation объявили о своем стратегическом партнерстве, которое, по их общему мнению, способно оказать решающее влияние на рынок средств объектно-ориентированной разработки программ. При этом Microsoft лицензировала у Rational Software некоторые технологии визуального моделирования, в результате чего был разработан Microsoft Visual Modeler for Visual Basic. В свою очередь Rational Software лицензировала у Microsoft Visual Basic и Microsoft Repository, разрабатываемые вместе с Texas Instruments. При создании языка UML Microsoft внесла свой вклад в интеграцию UML со своими стандартами типа ActiveX и СОМ и в использование языка UML со своей технологией Microsoft Repository.

В настоящее время Rational Software Corporation объединила свои усилия по совершенствованию технологии UML с компанией IBM.

3. Представление класса

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

Рисунок 3 — Графическое изображение класса на диаграмме классов Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса (рисунок 3, а). По мере проработки отдельных компонентов диаграммы, описания классов дополняются атрибутами (рисунок 3, б) и операциями (рисунок 3, в).

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

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

Атрибуты

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

Рисунок 5 — Структура задания атрибута Квантор видимости может принимать одно из трех возможных значений и отображается при помощи специальных символов:

Квантор видимости может быть опущен. Отсутствие квантора видимости обычно трактуется как private. Вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.

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

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

[нижняя_граница1. верхняя_граница1, нижняя_граница2. верхняя_грашца2,…, нuжняя_гpaнuцa k. верхняя_граница k],

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

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

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

Операция

В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, структура которой приведена на рисунке 6:

Рисунок 6 — Структура задания операции

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

Рисунок 7 — Структура задания параметра Здесь вид параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается.

последовательная (sequential) — для данной операции необходимо обеспечить ее единственное выполнение в системе, одновременное выполнение других операций может привести к ошибкам или нарушениям целостности объектов класса.

параллельная (concurrent) — данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели ("https://referat.bookap.info", 17).

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

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

Рисунок 8 — Пример задания класса

4. Представление отношения между классами

Если класс оказывает влияние на другой класс, то на диаграмме эта взаимосвязь (отношение) между классами изображается соединительной линией. Анализ разновидностей взаимосвязей (в дальнейшем отношений) позволяет выделить следующие:

отношение зависимости (dependency relationship);

отношение ассоциации (association relationship);

отношение обобщения (generalization relationship);

отношение реализации (realization relationship).

Каждое из этих отношений имеет собственное графическое представление на диаграмме.

Отношение зависимости

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

Рисунок 9 — Графическое изображение отношения зависимости Рисунок 10 — Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_A и Класс_Б) Стрелка может помечаться необязательным, но стандартным ключевым словом в кавычках и необязательным индивидуальным именем. Для отношения зависимости предопределены ключевые слова, которые обозначают некоторые специальные виды зависимостей. Эти ключевые слова (стереотипы) записываются в кавычках рядом со стрелкой, которая соответствует данной зависимости. Примеры стереотипов для отношения зависимости представлены ниже:

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

Отношение ассоциации

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

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

Отношение агрегации

Рисунок 12 — Графическое изображение отношения агрегации Еще одним примером отношения агрегации может служить деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя обозначения языка UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (см. рисунок 13), которая в данном случае иллюстрирует отношение агрегации.

Рисунок 13 — Диаграмма классов для иллюстрации отношения агрегации

Отношение композиции

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

Рисунок 14 — Графическое изображение отношения композиции Рисунок 15 — Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Отношение обобщения

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

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

Рисунок 16 — Графическое изображение отношения обобщения Рисунок 17 — Фрагмент диаграммы классов с отношением обобщения Рядом со стрелкой обобщения может размещаться строка текста, указывающая на некоторые дополнительные свойства этого отношения. В версии MS UML строка задает стереотип отношения с помощью слов: extends, inherits, private, protected, subclass, subtype, uses.

Диаграмма, на которой отображаются классы и отношения между ними называется статической диаграммой классов (или диаграммой классов). В литературе используются также и другие наименования — «информационная модель"[7]. На рисунке 18 приведен фрагмент диаграммы классов, содержащей отношение обобщения и бинарной ассоциации.

Рисунок 18 — Пример диаграммы классов

1. Уоссермен Ф., Нейрокомпьютерная техника, — М., Мир, 1992.

2. Горбань А. Н. Обучение нейронных сетей. — М.: ПараГраф, 1990

3. Горбань А. Н. , Россиев Д. А. Нейронные сети на персональном компьютере. — Новосибирск: Наука, 1996

4. Gilev S.E., Gorban A.N., Mirkes E.M. Several methods for accelerating the training process of neural networks in pattern recognition // Adv. Modelling & Analysis, A. AMSE Press. — 1992. — Vol.12, N4. — P.29−53

5. С. Короткий. Нейронные сети: алгоритм обратного распространения.

6. С. Короткий, Нейронные сети: обучение без учителя. Artificial Neural Networks: Concepts and Theory, IEEE Computer Society Press, 1992.

8. Лорьер Ж. Л. Системы искусственного интеллекта. — М.: Мир, 1991. — 568 с.

9. Искусственный интеллект. — В 3-х кн. Кн. 2. Модели и методы: Справочник/ Под ред. Поспелова Д. А. — М.: Радио и связь, 1990. — 304 с.

Введение

в системное программирование. — М.: Мир, 1988.

11. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. — К.: Диалектика, 1993. — 240 с.

  • Для учеников 1-11 классов и дошкольников
  • Бесплатные сертификаты учителям и участникам

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

Факультет физико – математический

Кафедра информатики и вычислительной техники

Особенности объектно-ориентированных языков

Автор работы________________________________________ А. А. Кирсанова

Направления подготовки 44.03.05 Педагогическое образование

Профиль Математика. Информатика

Руководитель работы: канд. физико – матем. наук, доцент___________________________________________ Т. В. Кормилицына

Введение

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

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

1 Объектно-ориентированное программирование

1.1 Технологии программирования

Технология программирования – это совокупность методов и средств разработки (написания) программ и порядок применения этих методов и средств.

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

В 1958 году были разработаны первые языки программирования, Фортран и Алгол-58. Программа на Фортране состояла из главной программы и некоторого количества процедур - подпрограмм и функций. Программа на Алголе-58 и его последующей версии Алголе-60 представляла собой единое целое, но имела блочную структуру, включающую главный блок и вложенные блоки подпрограмм и функций.

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

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

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

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

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

– построением языка программирования, содержащего как можно больше типов данных, и выбором для каждого класса задач некоторого подмножества этого языка. Такой язык иногда называют языком-оболочкой. На роль языка-оболочки претендовал язык ПЛ/1, оказавшийся настолько сложным, что так и не удалось построить его формализованное описание. Отсутствие формализованного описания, однако, не помешало широкому применению ПЛ/1 как в Западной Европе, так и в СССР;

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

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

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

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

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

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

1.3 Принципы объектно-ориентированного программирования

В основу ООП положены следующие принципы:

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

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

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

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

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

1) интерфейс – совокупность доступных извне элементов реализации абстракции (основные характеристики состояния и поведения);

2) реализация – совокупность недоступных извне элементов реализации абстракции (внутренняя организация абстракции и механизмы реализации ее поведения).

Ограничение доступа в ООП позволяет разработчику:

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

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

Сочетание объединения всех свойств предмета (составляющих его состояния и поведения) в единую абстракцию и ограничения доступа к реализации этих свойств получило название инкапсуляции.

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

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

В ООП используются два вида иерархии:

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

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

Использование принципа типизации обеспечивает:

– раннее обнаружение ошибок, связанных с недопустимыми операциями над программными объектами (ошибки обнаруживаются на этапе компиляции программы при проверке допустимости выполнения данной операции над программным объектом);

– возможность генерации более эффективного кода.

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

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

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

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

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

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

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

– глобальные объекты, существующие пока программа загружена в память;

– сохраняемые объекты, данные которых хранятся в файлах внешней памяти между сеансами работы программы.

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

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

2 Особенности объектно-ориентированных языков программирования

Объектно-ориентированный язык программирования (ОО-язык) – язык, построенный на принципах объектно-ориентированного программирования.

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

Первый объектно-ориентированный язык программирования Simula 67 был разработан в конце 60-х годов в Норвегии. Авторы этого языка очень точно угадали перспективы развития программирования: их язык намного опередил свое время.

Однако современники (программисты 60-х годов) оказались не готовы воспринять ценности языка Simula 67, и он не выдержал конкуренции с другими языками программирования (прежде всего, с языком Fortran).

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

Но достоинства языка Simula 67 были замечены некоторыми программистами, и в 70-е годы было разработано большое число экспериментальных объектно-ориентированных языков программирования: например, языки CLU, Alphard, Pascal и др. Эти языки так и остались экспериментальными, но в результате их исследования были разработаны современные объектно-ориентированные языки программирования: C++, Smalltalk, Eiffel и др.

Наиболее распространенным объектно-ориентированным языком программирования безусловно является C++. Свободно распространяемые коммерческие системы программирования C++ существуют практически на любой платформе. Широко известна свободно распространяемая система программирования G++, которая дает возможность всем желающим разобрать достаточно хорошо и подробно прокомментированный исходный текст одного из образцовых компиляторов языка C++. Завершается работа по стандартизации языка C++: последний Draft стандарта C++ выпущен в июне 1995 г. (он доступен по Internet).

Разработка новых объектно-ориентированных языков программирования продолжается. С 1995 года стал широко распространяться новый объектно-ориентированный язык программирования Java, ориентированный на сети компьютеров и, прежде всего, на Internet. Синтаксис этого языка напоминает синтаксис языка C++, однако эти языки имеют мало общего. Java интерпретируемый язык: для него определены внутреннее представление (bytecode) и интерпретатор этого представления, которые уже сейчас реализованы на большинстве платформ. Интерпретатор упрощает отладку программ, написанных на языке Java, обеспечивает их переносимость на новые платформы и адаптируемость к новым окружениям. Он позволяет исключить влияние программ, написанных на языке Java, на другие программы и файлы, имеющиеся на новой платформе, и тем самым обеспечить безопасность при выполнении этих программ. Эти свойства языка Java позволяют использовать его как основной язык программирования для программ, распространяемых по сетям (в частности, по сети Internet).

3 Обзор объектно-ориентированных языков программирования

Язык Smalltalk был разработан командой Xerox Palo Alto Research Center Learning Research Group как программная часть Dynabook – фантастического проекта Алана Кея. В основу были положены идеи Simula. Smalltalk является одновременно и языком программирования, и средой разработки программ. Это чисто объектно-ориентированный язык, в котором абсолютно все рассматривается как объекты; даже целые числа - это классы. Вслед за Simula, Smalltalk является важнейшим объектно-ориентированным языком, поскольку он не только оказал влияние на последующие поколения языков программирования, но и заложил основы современного графического интерфейса пользователя, на которых непосредственно базируются интерфейсы Macintosh, Windows и Motif.

В основу языка положены две простые идеи:

– все является объектами;

В таблице 1 приведены характеристики языка Smalltalk с точки зрения семи основных элементов объектного подхода.

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

Читайте также: