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

Содержание:

Введение

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

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

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

В данной курсовой работе рассмотрен объектно-ориентированный подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 Унифицированный процесс

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

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

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

- видов деятельности (как) - работ, осуществляемых исполнителями;

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

- артефактов (что) - информации, создаваемой, изменяемой или используемой исполнителями в проекте. Другими словами, артефакт это не только то, что создается в результате деятельности (технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.), но и то, что направляет эту деятельность (артефакты управления - календарный план, техническое задание, инструкции и т. д.);

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

Унифицированный процесс придерживается спиральной модели (стратегии) жизненного цикла ПО, предложенной Барри Боэмом.

Рисунок 1. Спиральная стратегия

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

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

Рисунок 2. Интенсивность процессов при создании версии информационной системы

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

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

Конструирование (англ. construction). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.

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

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

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

Вспомогательные технологические процессы обеспечивают выполнение основных.

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

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

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

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

Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:

- UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2"

- UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Общая структура UML показана на рисунке 3

Рисунок 3

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

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

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

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».

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

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

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent). 

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

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

стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;

помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента;

ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

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

диаграмма вариантов использования или прецедентов (use case diagram)

диаграмма классов (class diagram)

диаграммы поведения (behavior diagrams)

диаграмма состояний (statechart diagram)

диаграмма деятельности (activity diagram)

диаграммы взаимодействия (interaction diagrams) 

диаграмма последовательности (sequence diagram) 

диаграмма кооперации (collaboration diagram) 

диаграммы реализации (implementation diagrams)

диаграмма компонентов (component diagram) 

диаграмма развертывания (deployment diagram) 

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

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

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

связи, которые представляются различными линиями на плоскости;

текст, содержащийся внутри границ отдельных геометрических фигур;

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

2.3 Шаблоны проектирования

Шаблоны это эффективные решения, разработанные опытными профессионалами. Идея применения шаблонов принадлежит Кристоферу Александеру (1977 г.). Наиболее популярные шаблоны сводят в единые каталоги. Наиболее известными из них являются каталоги GoF "банды Четырех" (Гамма Е., Хелм Р., Джонсон Р. и Влиссидес Дж.) и GRASP (General Responsibility Assignment Software Patterns – общие шаблоны распределения обязанностей в программных системах).

Шаблон представляет собой именованную пару "проблема / решение", содержащую готовое обобщенное решение типичной проблемы. Таким образом, шаблон:

- имеет имя;

- содержит описание проблемы;

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

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

Глава 3. Преимущества и недостатки объектно-ориентированного подхода

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

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

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

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

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

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

• осознавать выгоды такого подхода;

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

• заниматься поиском подходящих для повторного использования программ;

• стремиться найти такие программы;

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

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

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

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

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

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

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

Динамическое связывание, предполагающее поиск метода в классе, которому принадлежит получающий сообщение объект, приводит к тому, что обращение к методу занимает в 1,75-2,5 раза больше времени, чем к обычной подпрограмме. Это, конечно, замедляет работу приложения. Однако, как указывает Г. Буч, динамическое связывание при использовании строго типизированных языков применяется примерно в 20% случаев вызовов методов. В результате снижаются непроизводительные потери времени. В приложениях, где такие потери критичны, приходится прибегать к специальным программистским приемам.

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

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

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

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

Глава 4. Инструментальные средства объектно-ориентированного проектирования информационных систем

Объектно-ориентированное программирование возникло раньше объектно-ориентированного анализа и проектирования, поэтому на сегодняшний день существует достаточно большое количество языков, поддерживающих данную технологию. Первым из них, по дате возникновения, считается язык Smalltalk, хотя многие элементы объектно-ориентированного подхода были использованы еще в языке Simula в 1967г. Наиболее мощным инструментом создания объектно-ориентированных программ на сегодня является язык C++, созданный на базе языка структурного программирования C. Успешно развивается язык Java, который изначально разрабатывался как объектно-ориентированный.

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

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

Smalltalk-72, -74. -76, -78, -80. Реализации 1972 и 1974 годов заложили основу языка, в частности идею передачи сообщений и полиморфизм, хотя механизм наследования еще не появился. В последующих версиях полноправное гражданство получили классы; этим достигла завершения точка зрения, что все состоит из объектов. Smalltalk-80 был перенесен на многие компьютерные платформы.

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

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

- объекты взаимодействуют, обмениваясь сообщениями.

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

Таблица 1

Абстракции	Переменные экземпляра	Имеются
	Методы экземпляра	Имеются
	Переменные класса	Имеются
	Методы класса	Имеются
Инкапсуляция	Переменных	Закрытые
	Методов	Открытые
Модульность	Разновидности модулей	Отсутствуют
Иерархии	Наследование	Одиночное
	Шаблоны	Отсутствуют
	Метаклассы	Имеются
Типизация	Сильная типизация	Отсутствует
	Полиморфизм	Имеется (одиночный)
Параллельность	Многозадачность	Непрямая (посредством классов)
Устойчивость	Долгоживущие объекты	Отсутствуют

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

Язык программирования C++ был разработан Бьерном Страустрапом, сотрудником AT&T Bell Laboratories. Непосредственным предшественником C++ является С with Classes, созданный тем же автором в 1980 году. Язык С with Classes, в свою очередь, был создан под сильным влиянием С и Simula. C++ - это в значительной степени надстройка над С. В определенном смысле можно назвать C++ улучшенным С, тем С, который обеспечивает контроль типов, перегрузку функций и ряд других удобств. Но главное в том, что C++ добавляет к С объектную ориентированность.

Известны несколько версий C++. В версии 1.0 реализованы основные механизмы объектно-ориентированного программирования, такие как одиночное наследование и полиморфизм, проверка типов и перегрузка функций. В созданной в 1989 году версии 2.0 нашли отражение многие дополнительные свойства, возникшие на базе широкого опыта применения языка многочисленным сообществом пользователей. В версии 3.0 (1990) появились шаблоны и обработка исключений. C++ продолжает совершенствоваться, в 1998 году вышла новая версия стандарта, содержащая в себе некоторые довольно существенные изменения. Язык стал основой для разработки современных больших и сложных проектов.

Характеристики C++ приведены в таблице 2.

Таблица 2

Абстракции	Переменные экземпляра	Имеются
	Методы экземпляра	Имеются
	Переменные класса	Имеются
	Методы класса	Имеются
Инкапсуляция	Переменных	Открытые, защищенные, закрытые
	Методов	Открытые, защищенные, закрытые
Модульность	Разновидности модулей	Файл
Иерархии	Наследование	Множественное
	Шаблоны	Имеются
	Метаклассы	Отсутствуют
Типизация	Сильная типизация	Имеется
	Полиморфизм	Имеется (одиночный)
Параллельность	Многозадачность	Непрямая (посредством классов)
Устойчивость	Долгоживущие объекты	Отсутствуют

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

Заключение

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

Библиография

Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2001. -560 с.

Крачтен Ф. Введение в Rational Unified Process, 2002. -240 с.

Леоненков А.В. Самоучитель UML 2, 2007. -576 с.

Буч Г. Язык UML. Руководство пользователя, 2004. -432 с.

Ларман К. Применение UML и шаблонов проектирования: учебное пособие, 2001. -496 с.

Гранд М. Шаблоны проектирования в Java, 2004. -559 с.

Черемных С.В.. Структурный анализ систем IDEF-технологий, 2003 г. -208 с.

Сайт Частного Боровского исследовательского учреждения по внедрению новых технологий. http://bourabai.ru/