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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

1.1. Характеристика объектно–ориентированного подхода

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

объектно–ориентированные методологии (технологии) разработки программных систем;
инструментальные средства, поддерживающие эти технологии [12].

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

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

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

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

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

UML – язык, применяемый для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно–ориентированного подхода. [9].

Нa cтaдиях aнaлизa и проектирования часто используются так называемые шаблоны (пaттeрны) прoeктирoвaния. Шaблoн – это именованная пара «проблема/решение», содержащая готовое oбoбщeннoe рeшeниe типичнoй проблемы [7]. Как правило, шаблон помимо текстового oпиcaния coдeржит тaкжe одну или несколько диаграмм UML (например, диаграммы клaccoв, пocлeдoвaтeльнocти и/или коммуникации), графически иллюстрирующих состав и структуру классов, a тaкжe ocoбeннocти их взаимодействия при решении поставленной проблемы. Шаблоны рaзрaбaтывaютcя oпытными прoфeccиoнaлaми и являются проверенными, эффективными (порой оптимальными) решениями [7].

1.2. Понятия объектно–ориентированного подхода

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

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

При разработке программного обеспечения термин «объект» впервые был введен Оле–Джоаном Далем, Бьорном Мюрхогом и Кристеном Ныгардом из Норвежского вычислительного центра (г. Осло). Они разработали язык Simula 67, созданный на основе языка Algol–60 и предназначенный для моделирования и описания сложных систем. Однако по–настоящему широкое внедрение этой идеи произошло при разработке языка SmallTalk в 1990 г. Аланом Кейем из Исследовательского центра фирмы Xerox (г. Пало–Альто). В SmallTalk использовались только объектно–ориентированные конструкции.

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

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

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

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

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

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все (разрешенные) атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы [6].

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

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по–разному [6].

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

2. Применение объектно–ориентированного подхода при проектировании

2.1. Анализ достоинств и недостатков объектно–ориентированного подхода

Оценим объектно–ориентированный подход в соотношении с не менее известным структурным подходом.

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

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

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно–ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно–ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований [1].

Исследователи отмечают также ряд следующих преимуществ объектно–ориентированного подхода:

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно–ориентированных языков программирования [2].

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

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

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

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

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

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

Case–средства, поддерживающие объектно–ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case–средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая кодогенерация (например, экранов или функций обработки данных) возможна лишь в редких случаях [7].

2.2. Методологии, применяемые в процессе реализации объектно–ориентированного подхода

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

Методология OMT (Object Modeling Technique) поддерживает две первые стадии жизненного цикла программных систем. Это не единственная объектно–ориентированная методология разработки программных систем. Она является одной из наиболее продвинутых и популярных объектно–ориентированных методологий. Более того, графический язык (система обозначений для диаграмм) методологии OMT получил достаточно широкое распространение и используется в некоторых других объектно–ориентированных методологиях, а также в большинстве публикаций по объектно–ориентированным методологиям [12].

В этом разделе рассмотрим объектно–ориентированные методологии разработки программных систем. Они будут сравниваться с методологией OMT. В последнее время интерес к объектно–ориентированным методологиям разработки программных систем продолжает возрастать: много публикаций в журналах, докладов на конференциях и т.д. Программное обеспечение объектно–ориентированных методологий стало настолько популярным, что все интересные инструментальные и CASE–системы давно исчезли из public domain и распространяются только как коммерческие системы. Наиболее известной такой системой является система Paradigm+, которая поддерживает восемь объектно–ориентированных методологий, и в том числе, методологию OMT [12].

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

OMT (Object Modeling Technique);
SA/SD (Structured Analysis/Structured Design);
JSD (Jackson Structured Development);
OSA (Object–Oriented System Analysis).

Методология OMT опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+ [12].

Методология SA/SD содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов [9].

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

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

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы. Таким образом, мы видим, что у методологий SA/SD и OMT много общего: обе методологии используют похожие конструкции для моделирования и поддерживают три взаимно–ортогональных представления проектируемой системы. Методологии SA/SD и OMT можно рассматривать как два способа использования инструментального средства – OMTTool.

Методология JSD предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80–х годов, особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. На этом этапе решается вопрос «что должно быть сделано»; вопрос «как это должно быть сделано» решается на следующем этапе – этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени [5].

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT. Разработка модели JSD начинается с изучения объектов реального мира. Целью системы является обеспечение требуемой функциональности, но Джексон понимает, что сначала следует убедиться, что эта функциональность согласуется с реальным миром. Модель JSD описывает реальный мир в терминах сущностей (объектов), действий и порядка выполнения действий. Разработка системы по методологии JSD включает следующие шесть фаз:

разработка действий и объектов;
разработка структуры объектов;
разработка исходной модели;
разработка функций;
разработка временных ограничений;
реализация системы [5].

Методология JSD может быть названа объектно–ориентированной с большой натяжкой: в ней почти не рассматривается структура объектов, мало внимания уделяется их атрибутам. Некоторые действия в смысле методологии JSD являются, по существу, зависимостями между объектами в смысле методологии OMT [5].

Методология OSA обеспечивает объектно–ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

Методологии объектно–ориентированного анализа нередко критикуются за то, что они являются больше реализационно–ориентированными, чем проблемно–ориентированными, обеспечивая больше предварительную разработку, чем анализ требований к системе. Действительно, все рассмотренные методологии (такие, как OMT, SA/SD, JSD) поддерживают прежде всего предварительную разработку программных систем, а не анализ требований к ним. Это следует из таблиц 1 и 2, в которых рассмотрены возможности различных методологий, поддерживающие процесс анализа (таблица 1) и процесс разработки (таблица 2) [12].

Таблица 1

Аналитические возможности сравниваемых методологий объектно–ориентированного анализа

Возможность	OSA	OMT	SA/SD	JSD
Объекты: должны иметь индивидуальное и независимое состояние и поведение	+	+	+	+
Классы объектов: должны определять свойства своих членов и должны иметь место в памяти	+	+	+	+
Множества связей: множества соединений объектов	+	+	+	+
Реляционные классы объектов: рассматривают связи как объекты	+	+	–	+
Полностью интегрированные подмодели: допускают произвольную интеграцию подмоделей анализа; знак «–» в таблице означает, что подмодели, представленные, например, блок–схемами, не могут комбинироваться с другими видами подмоделей (например, моделями поведения)	+	–	–	+
Агрегация: часто используемый механизм абстракции, который представляет взаимосвязи между системами и их частями	+	+	+	+
Обобщение/наследование: механизм абстракции: если A есть специализация B, то свойства A подразумевают свойства B	+	+	–	+
Полномасштабные ограничения мощности связей: допускают мощности связей, являющихся произвольными множествами неотрицательных целых чисел (не только 1–1, 1–M, M–1, M–M)	+	–	–	–
Синонимы и омонимы: допускают несколько имен для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей	+	–	–	–
Полная система триггеров: допускаются только условия, только события, или комбинации условий и событий	+	+	–	–
Действия: описывают поведение, которое завершается	+	+	+	+
Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться	+	+	–	–
Межобъектный параллелизм: более одного объекта могут быть активными одновременно	+	+	+	+
Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов	+	+	–	–
Исключения: допускается обнаружение и обработка условий ошибок	+	–	–	–
Временные ограничения: обеспечивают средства ограничения времени на какое–либо действие	+	–	+	+
Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем	+	–	–	–
Метамодель: определяет правильный экземпляр модели	+	–	–	–
Родовой класс: параметризация классов – механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка	–	–	–	–
Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события	+	+	+	–
Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям	+	–	–	–
Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами	+	–	–	–
Непрерывные взаимодействия: допускает непрерывный поток информации	+	–	–	–
Взаимодействия по бродкастингу: разрешает иметь много приемников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий	+	–	–	–
Общее число аналитических возможностей	29	13	8	9

Таблица 2

Возможности сравниваемых методов объектно–ориентированного анализа, используемые на этапе разработки системы

Возможность	OSA	OMT	SA/SD	JSD
Значения: имеют состояние, но не имеют поведения и индивидуальности; хотя значения можно считать постоянными объектами, во многих подходах существует различие между пространствами значений и объектов	–	+	+	+
Атрибуты и/или методы: определяют классы объектов в терминах атрибутов и/или методов, аналогично тому, как классы объектов определяются в объектно–ориентированных языках	–	+	+	+
Шаблоны классов объектов: шаблоны, по которым создаются экземпляры классов объектов, что подразумевает, что свойства экземпляра объекта определяет класс, а не свойства объекта определяют его класс	–	+	–	+
Абстрактные классы: шаблоны, которые определяют свойства, но не разрешают создавать экземпляры	–	+	+	+
Псевдонаследование: разрешает, чтобы атрибуты и сигнатуры методов подкласса совпадали с атрибутами и сигнатурами методов суперкласса	–	+	+	+
Тождественность по значениям: множества атрибутов (их обычно называют возможными ключами), используемые для определения тождественности объектов	–	+	+	–
Изменение семантики: разрешает переопределять в подклассе семантику методов суперкласса	–	+	+	–
Императивный вызов операций: позволяет вызов метода в отношении клиент–сервер	–	–	–	+
Общее число возможностей по разработке	0	7	6	6

Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно–ориентированным анализом систем и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы: OSA реализована в системе программирования C++ на рабочей станции Hewlett–Packard 700 под управлением ОС HP–UX 9.01.

Методология OSA, как и другие методологии, поддерживает три взаимно–ортогональных представления (модели) проектируемой системы:

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

Модель зависимостей между объектами аналогична объектной модели методологии OMT. В ней рассматриваются объекты, множества отношений между объектами и различные ограничения [15].

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

ЗАКЛЮЧЕНИЕ

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

Для достижения цели были выполнены следующие задачи:

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

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

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

СПИСОК ИСТОЧНИКОВ

Васильев, А. Н. C#. Объектно–ориентированное программирование / А. Н. Васильев. – М.: Питер, 2015. – 320 c.
Васильев, А. Н. Java. Объектно–ориентированное программирование / А. Н. Васильев. – М.: Питер, 2016. – 400 c.
Иванова, Г. С. Объектно–ориентированное программирование / Г. С. Иванова. – М.: Московский Государственный Технический Университет (МГТУ) имени Н.Э. Баумана, 2014. – 149 c.
Колесов, Ю. Б. Моделирование систем. Объектно–ориентированный подход / Ю. Б. Колесов, Ю. Б. Сениченков. – М.: БХВ–Петербург, 2016. – 192 c.
Комлев Н. Ю. Объектно Ориентированное Программирование. Хорошая книга для Хороших Людей / Н. Ю. Комлев. – М.: Солон–Пресс, 2018. – 892 c.
Кьоу, Дж. Объектно–ориентированное программирование / Дж. Кьоу, М. Джеанини. – М.: Питер, 2015. – 240 c.
Лафоре, Р. Объектно–ориентированное программирование в C / Р. Лафоре. – М.: СПб: Питер; Издание 4–е, 2018. – 928 c.
Лесневский, А. С. Объектно–ориентированное программирование для начинающих / А. С. Лесневский. – М.: Бином. Лаборатория знаний, 2015. – 232 c.
Мартынов, Н. Н. Алгоритмизация и основы объектно–ориентированного программирования на JavaScript. Информатика и ИКТ. Профильный уровень. 10 класс / Н. Н. Мартынов. – Москва: Наука, 2017. – 272 c.
Могилев, А. Методы программирования. Компьютерные вычисления / А. Могилев, Л. Листрова. – М.: БХВ–Петербург, 2018. – 320 c.
Павловская, Т. C/C++. Процедурное и объектно–ориентированное программирование. Учебник / Т. Павловская. – М.: Питер, 2015. – 496 c.
Санников, Е. В. Курс практического программирования в Delphi. Объектно–ориентированное программирование / Е. В. Санников. – М.: Солон–Пресс, 2016. – 188 c.
Хорев, П. Б. Объектно–ориентированное программирование / П. Б. Хорев. – М.: Академия, 2015. – 448 c.
Хохлов, Д. Г. Методы программирования на языке С. Практикум. В 2 частях (комплект) / Д. Г. Хохлов. – М.: Бином. Лаборатория знаний, 2019. – 712 c.
Хювенен, Э. Мир Лиспа. Методы и системы программирования / Э. Хювенен, Й. Сеппянен. – М.: Мир, 1990. – 320 c.