Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Объектно-ориентированное программирование

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 14.12.2012
Размер файла 2,2 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

1

Размещено на http://www.allbest.ru/

Содержание

  • Глава I. Структура объектно-ориентированного программирования
  • 1.1 Сущность объектно-ориентированного подхода
  • 1.2 Унифицированный язык моделирования UML
  • 1.3 Варианты использования
  • Глава II. Диаграммы
  • 2.1 Диаграммы классов
  • 2.2 Диаграммы взаимодействия
  • Глава III. Пример использования объектно-ориентированного подхода
  • Заключение
  • Список использованной литературы
  • Приложение

Введение

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

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

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

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

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

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

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

объектный ориентированный программирование подход

Глава I. Структура объектно-ориентированного программирования

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

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

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

абстрагирование (abstraction);

инкапсуляция (encapsulation);

модульность (modularity);

иерархия (hierarchy).

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

типизация (typing) ',

параллелизм (concurrency) ',

устойчивость (persistence).

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

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

Объектно-ориентированный подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

связь "расширение" следует применять при описании изменений в нормальном поведении системы;

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

Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей "использование" и "расширение"). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.

Глава II. Диаграммы

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

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

ассоциации (например, клиент может сделать заказ);

подтипы (частный клиент является разновидностью клиента).

Рис. 2 Диаграмма классов

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

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

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

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

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

аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

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

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

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

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

Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

Роль может быть явно поименованная с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется "позиция заказа". Если такая метка отсутствует, роли присваивается имя класс - цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

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

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

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

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

Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

Каждая Строка заказа проверяет состояние определенного Запаса товара:

Если данная проверка удовлетворяется (результат - true), то Строка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.3).

Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

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

Рис.3 Диаграмма последовательности

(self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер - это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).

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

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

...

Страница:


Подобные документы

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

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

    реферат [273,2 K], добавлен 09.06.2009

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

    Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).

    курсовая работа [1,1 M], добавлен 13.05.2014

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

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

    контрольная работа [51,7 K], добавлен 22.01.2013

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

    Использование объектно-ориентированного программирования - хорошее решение при разработке крупных программных проектов. Объект и класс как основа объектно-ориентированного языка. Понятие объектно-ориентированных языков. Языки и программное окружение.

    контрольная работа [60,1 K], добавлен 17.01.2011

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

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

    презентация [74,8 K], добавлен 14.10.2013

  • Объектно-ориентированное программирование. Сравнительный анализ языков объектно-ориентированного программирования

    Характеристики и свойства языков программирования. Исследование эволюции объектно-ориентированных языков программирования. Построение эволюционной карты механизмов ООП. Разработка концептуальной модели функционирования пользовательского интерфейса.

    курсовая работа [2,6 M], добавлен 17.11.2014

  • Основы программирования в C++

    История развития языков программирования; создание и распространение языка С++; новый подход к разработке объектно-ориентированного программного обеспечения. Применение моделирования предметных областей для структуризации их информационных отражений.

    реферат [29,1 K], добавлен 06.12.2010

  • Объектно-ориентированное программирование с помощью Microsoft Visual Basic

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

    курсовая работа [428,9 K], добавлен 19.09.2012

  • Объектно–ориентированная модель информационной подсистемы "Трудоустройство"

    Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

    курсовая работа [2,7 M], добавлен 23.06.2011

  • Объектно-ориентированное программирование на языке С++

    Приемы и правила объектно-ориентированного программирования с использованием языка С++. Общие принципы разработки объектно-ориентированных программ. Основные конструкции языка С++. Разработка различных программ для Windows с использованием WIN32 API.

    учебное пособие [1,6 M], добавлен 28.12.2013

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

    Использование скриптового языка программирования для разработки web-приложений (сценариев). Изучение основ объектно-ориентированного программирования в языке PHP. Ознакомление со специальными методами для работы с классами. Назначение интерфейсов.

    контрольная работа [25,1 K], добавлен 14.03.2015

  • Имитационное моделирование динамических систем и процессов с использованием объектно-ориентированного подхода. "Производственная линия с пунктами технического контроля"

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

    курсовая работа [1,2 M], добавлен 09.01.2014

  • Средства объектно-ориентированного программирования в задачах защиты информации

    Понятие объектно-ориентированного программирования, характеристика используемых языков. Практическая разработка средств объектно-ориентированного программирования в задачах защиты информации: программная реализация на языке С++, а также Turbo Pascal.

    курсовая работа [275,9 K], добавлен 22.12.2011

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

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

    курсовая работа [688,3 K], добавлен 23.12.2013

  • Место объектно-ориентированного программирования в современном программировании

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

    курсовая работа [698,3 K], добавлен 09.12.2013

  • Объектно-ориентированная технология разработки программного обеспечения будильника

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

    курсовая работа [355,8 K], добавлен 26.09.2014

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

    Методология объектно-ориентированного программирования в Java. Понятия класса, объекта и объектной переменной. Динамическая и статическая объектные модели. Логическое структурирование приложения. Наследование в Java. Отличия интерфейсов от классов.

    курс лекций [547,2 K], добавлен 01.05.2014

  • Разработка объектно-ориентированной программы

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

    лабораторная работа [212,0 K], добавлен 10.03.2013

  • Объектно-ориентированное программирование на Borland C++

    Технологии программирования. Сущность объектно-ориентированного подхода к программированию. Назначение Си, исторические сведения. Алфавит, базовые типы и описание данных. Структуры и объединения. Операторы Си++. Функции. Библиотека времени выполнения.

    курс лекций [51,9 K], добавлен 03.10.2008

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

    Разработка программы с использованием принципов объектно-ориентированного программирования на языке высокого уровня С средствами Microsoft Visual Studio 2010. Построение алгоритма реализации. Класс программы, инструкция по использованию программы.

    курсовая работа [1,0 M], добавлен 26.12.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены