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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

1. Рассмотреть основные понятия объектно-ориентированного подхода (далее ООП).
2. Сущность ООП.
3. Отдельным разделом расписать унифицированный язык моделирования UML.
4. Описать преимущества и недостатки ООП.
5. Привести примеры программных продуктов на основе ООП.

1. Теоретическое введение в объектно-ориентированный подход

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

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

Есть три отличия между этими двумя подходами.

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

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

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

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

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

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

• унифицированный процесс (Unified Process, UP);
• экстремальное программирование (eXtreme Programming, XP);
• гибкое моделирование (Agile Modeling, AM).

Унифицированный язык моделирования (Unified Modeling Language, UML) – это базовое средство фиксации (документирования) результатов проектирования систем посредством этих методологий является.

Основные понятия, используемые в данном подходе

Первый термин — это объект и эквивалентные ему понятия. Появились независимо в различных областях, связанных с компьютерами, в процессе разработки:

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

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

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

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

Индивидуальность – это некоторое свойство сущности, которое позволяет отличить ее от других. Если говорить об объекте поезд, имея в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а рассматривать конкретный грузовой поезд с номером 1024, весом 4500 т., состоящий из полувагонов с некоторыми номерами и так далее.

Для группировки однотипных объектов в ООП используется понятие «класс». Класс – это множество объектов, которые имеют общую структуру и поведение или это шаблон, по которому генерируются (создаются) однотипные объекты. Чаще всего употребляют синоним понятия класса, а именно экземпляр класса.Р

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

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

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

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

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

Существуют еще и другие принципы ООП:

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

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

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

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

К базовым составляющим ООП относят:

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

Распишем более подробно каждую из составляющих ООП.

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

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

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

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

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

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

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

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

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

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

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

Кроме всего остального, язык UML не считается языком зрительного программирования, но модели, разработанные с его поддержкой, имеют все шансы быть переведены на всевозможные языки программирования. Модель, построенную на базе языка UML, возможно переместить на надлежащие языки программирования: Java, C++, Visual Basic, и в том числе и предположить в облике таблиц реляционной базы данных или же устойчивые объекты объектно-ориентированной базы данных.

Словарь языка UML состоит из трех блоков:

• сущности;
• отношения;
• диаграммы.

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

Отношения бывают следующих типов:

1. Обобщение.
2. Ассоциации
3. Агрегации
4. Композиции
5. Зависимости
6. Реализации

В UML выделяют девять типов диаграмм:

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

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

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

Данная система представляется в виде множеств актеров, которые взаимодействуют с системой при помощи вариантов использования.

Диаграмма строится на основе следующих компонентов:

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

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

Relationships (связи или отношения) – используются для обозначения отношений между компонентами модели.

Связи бывают следующих видов:

• Ассоциация – единственно возможная связь между актером и ВИ. Ассоциативная связь специфицирует особенности взаимодействия актера и варианта использования. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. Изображается в виде сплошной линии.
• Отношение обобщения между двумя вариантами использования означает, что когда осуществляется дочерний вариант использования, необходимо исполнение и родительского. В общем случае для того, чтобы создание родительского ВИ имело смысл, необходимо, чтобы у него было бы хотя бы два дочерних. Единственное исключение – это, когда имеются два ВИ и один из них является детализацией другого, но оба могут осуществляться независимо.
• Отношение включения, помечаемое стандартом <>, обозначает, то что с целью абсолютного реализации главного (базисного) ВИ следует осуществление также вводимого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но никак, однако не применяется.

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

Notes (примечания) - произвольные текстовые комментарии разработчика, имеющие отношение к компонентам Use case – диаграммы. Структурные элементы данной диаграммы представлены в приложении А.

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

Структурные сущности – это имена существительные в языке UML, которые представляют собой либо концептуальные, либо физические элементы. Основной вид структурной сущности — это класс.

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

Рисунок 1 – Вид сообщения в поведенческой сущности

Аннотирующие сущности – это части, которые поясняют UML-модели, иными словами, комментарии, используемые для пояснения и выделения некоторого элемента модели. Главной такой сущностью является примечание. В нем отображаются ограничения и комментарии, относящиеся к элементу или набору элементов. Графически представляется прямоугольником с загнутым углом, внутри которого помещается соответствующий комментарий. На рисунке 2 представлено его изображение.

Рисунок 2 – Вид комментария

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

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

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

Рисунок 3 – Вид класса

Операции и атрибуты имеют один из трех типов видимости: private (частный), protected (защищенный), public (общий). Она указывается в виде левого символа в строке с именем элемента.

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

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

Для абстрактного класса имя пишется курсивом.

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

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

Существуют четыре типа отношений между классами:

Зависимость – связь между двумя элементами модели, в которой при изменении одного элемента может привести к изменению семантики другого элемента. Графически представляется в виде пунктирной линии со стрелкой. На рисунке 4 представлен ее вид.

Рисунок 4 – Отношение зависимости

Ассоциация – связь между элементами модели, которая описывает набор связей, между объектами в модели. К примеру, например, класс Человек и класс Среднее учебное заведение имеют ассоциацию, например, как человек имеет возможность обучаться в школе. Ассоциации возможно присвоить имя «учится в». В представлении однонаправленной ассоциации прибавляется стрелка, указывающая на назначение ассоциации. На рисунке 5 представлен пример этой ассоциации.

Рисунок 5 – Отношение ассоциации

Еще связь содержит кратность. Она указывается вблизи с обозначениями связанных компонент диаграммы, и характеризует сплошное численность экземпляров соответственного компонента, которые имеют все шансы играть в качестве составляющих предоставленной ассоциации. Записывается в облике выражения с наименьшим и предельным значением; для их деления применяются 2 точки. Ставя множественность далекого конца ассоциации, вы показываете, сколько объектов имеет возможность поприсутствуешь на далеком конце ассоциации для всякого объекта класса, оказавшегося на ближнем ее конце. Численность объектов надлежит пребывать в границах данного спектра. Множественность имеет возможность задаваться как кол 1, ноль или же раз 0..1, каждое смысл 0..* или же *, раз или же некоторое количество 1..*. Возможно еще задавать в облике интервала цельных значений, то есть это 2 количества разбитых точками. К примеру 2..5, или же ставить четкое количество, к примеру 3. На рисунке 6 представлен пример данного отношения, здесь используется диапазон целых значений.

Рисунок 6 – Множественная ассоциация

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

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

Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть». На рисунке 7 представлено данное отношение.

Рисунок 7 – Отношение агрегации

Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.

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

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

Рисунок 8 – Отношение композиции

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

Рисунок 9 – Отношение обобщения

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

Рисунок 10 – Отношение реализации

Структурные элементы данной диаграммы представлены в приложении А.

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

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

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

• entry – так называемое входное действие, действие, которое выполняется в момент входа в данное состояние;
• exit – выходное действие, то есть это действие, которое выполняется в момент выхода из данного состояния;
• do – выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии;
• defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.

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

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

Структурные элементы данной диаграммы представлены в приложении А.

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

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

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

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

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

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

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

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

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

Выделяют следующие достоинства:

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

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

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

• гибкость при модификации и расширении системы.

Рассмотрим каждое из них более подробно.

Концептуальная ясность в разработке системы.

При использовании программных объектов для моделирования объектов реального мира выделяют два наиболее важных эффекта:

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

• у разработчика есть возможность моделировать системы, считавшиеся ранее слишком трудными или сложными для работы.

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

а. датчики и сканеры в измерительных и управляющих системах;

б. дома в географической информационной системе;

в. кружки для диаграмм данных в CASE;

г. файлы и очереди в ОС;

д. сети в адаптивной инженерии знаний.

Надежность

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

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

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

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

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

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

Гибкость

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

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

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

Несмотря на то, что ООП имеет много достоинств, находятся и его недостатки:

Нехватка постоянной памяти

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

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

Смена парадигмы

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

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

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

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

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

Реализация объектно-ориентированного подхода при проектировании ИС

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

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

1. Формирование требований
2. Разработка концепции
3. Техническое задание
4. Эскизный проект
5. Технический проект
6. Рабочая документация
7. Ввод в действие
8. Сопровождение ИС

Рассмотрим эти стадии более подробно.

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

Чаще всего разработчики используют Microsoft SQL Server для создания баз данных, так как это самое распространенное и удобное в использовании приложение. Также можно использовать и MS Access, Oracle.

Но прежде, чем создавать базу данных в Microsoft SQL Server, необходимо построить ряд диаграмм, используя язык UML. Это диаграмму вариантов использования и диаграмму классов (ER-модель). На них отображаются пользователи системы и их функции. После того, как диаграммы будут построены, можно приступать к созданию базы данных. Исходя из построенной ER-модели и строится база данных. Далее необходимо созданную базу нормализовать, то есть привести к какой-либо нормальной форме. Существует их 5, но разработчик должен ее свести к 3 нормальной форме. Получили на выходе эскизный проект.

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

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

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

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

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

Hewlett Packard и Tektronix - известные фирмы, которые специализируются не лишь только на компьютерной промышленности. Они числятся насыщенными приверженцами объектно-направленных стилей. В фирмы Hewlett Packard, к примеру, филиал Lake Stevens Instrument Division уже некоторое количество лет пользуется объектно-ориентированную методологию. В 1985 г. она стала применить Objective C. Данный язык применялся для разработки виртуального инструмента и измерительного интерфейса на базе рабочей станции для многоканального Динамического Анализатора Сигналов HP3565. Этот итог используется с целью рассмотрения издаваемых отделением устройств. Он выделяет свойства сигнала (принятие сигнала, измерение, тест, документация и автоматизация) и опробывает ответ. ПО произведено из 312 классов объектов, 6044 способов и 100474 строк слова. На разработку системы было затрачено время, эквивалентное 39 инженерным годам - коэффициент производительности равен 11 строчкам на всякого инженера каждый день. Фирма предполагает добиться более значимой производительности во грядущих намерениях, во каковых вполне вероятно повторно использовать текста планов со помощью приспособления наследования. Она придумала личную систему измерений, основанную на документации по классам и заголовкам и применяемую для прогнозирования актуального цикла процесса.

Другим активным пользователем в этой области является Bell Northern Research, занимающийся разработкой средств для новых коммуникационных служб. Данные ресурсы удерживают спецификацию равно как постоянных качеств, таким образом также динамического действия, прогнозирования также рассмотрения производительности. Компания функционирует в стиле Smalltalk, однако обговаривает трансформация в речь С++. US West увлекается стремительным прототипированием с целью презентации определений новейших телекоммуникационных вопросов, к примеру, сетного контролирования. Проекты включают пакеты пользовательского интерфейса, редакторы объектов, механизм вывода, систему ввода новых правил, различные мониторы для отладки и объектно-ориентированную базу данных. Фирма также ведет работы по написанию интерфейса машина/машина, особенно для старых систем, не являющихся объектно-ориентированными.

McDonnell Douglas's Computer Integrated Enterprise Business Unit (CIEBU) разработал семейство продуктов для поддержки сбора данных и распределенных цифровых управляющих систем для их применения в профсоюзах. Версия 1.0 была выпущена в 1988 г. и включает Членство, Отчеты о занятости и Набор данных, именуемые на рынке MATROL (Manufacturing Activity Control System) . Данные продукты питания существовали изобретены со поддержкой стиля Objective-C с целью поставки в концепции DEC Vax/VMS около DECnet со помощью MAP (Manufacturing Automation Protocol) также TOP (Technical Office Protocol). Скорость разработки и гибкость - ключевые черты в выборе языка. Фирма оценила, что использование объектно-ориентированной технологии снизило время разработки примерно на семь месяцев.

Applied Intelligent Systems, Inc (AISI) разрабатывает визуальные системы, применяемые в операциях сборки и проверки в электронике и автоматике. Прикладные задачи включают распознавание символов, верификацию сборки, выявление брака, идентификацию, управление роботами, размещение и ориентацию компонентов. Фирма стремилась снизить время разработок, предоставив библиотеку программ, а также сделать системы программируемыми пользователями. С целью формирования библиотеки классов применен речь Objective-C, содержащий общеупотребимые предметы вида видеокамер, дисплеев также действий обрабатывания отображений.

Крупные компании, специализирующиеся исследованиями во данной сфере, содержат General Motors, использующую объектно-направленные понятия во некоторых собственных планах, подобных равно как GM Research, таким образом также GM Advanced Engineering Systems; но кроме того GTE, организовавшую категорию согласно объектно- направленным банкам сведений также разглядывающую вероятность применения объектно-направленной технологические процессы во собственных множественных независимых подразделениях.

Компания Honeywell создала сферу Rapid (Rapid Prototyper for Interface Design), дозволяющую спецам сообразно человеческим условиям создавать прототипы внешнего на подобии интерфейсов оператора с маленькими управляющими панелями, к примеру термостатами для жилища и кабинета, системами обороны и контроллерами подключения электро систем. Rapid предопределена для моделирования управляющей панели на рабочей станции или же PC, довольно четкого для применения специалистами по человечным моментам. Она была сотворена с поддержкой Smalltalk-80 на Tektronix 4404: незатейливый работающий образец был сотворен в направление нескольких месяцов [Freburger 1987]. Сотрудники NASA/Goddard Space Flight Cenre (GSFC) сделали объектно- нацеленную теорию управления со пользовательским дизайном в пределах названием Transportable Applications Executive (TAE Plus). Заинтригованность к этому проекту был замечен во Семьдесят-х годах, в случае если было установлено, то, что 50% исходных текстов диалоговых практических вопросов, сформированных во Вселенском Фокусе, потребуется в пользовательские интерфейсы. 1-ая версия TAE была сотворена в начале 80-х гг. Впрочем, она не была предопределена для работы с интерфейсами все растущей трудности - многооконными, цветными, с внедрением графических объектов и пиктограмм.

Для данных целей GSFC приняла решение расширить TAE функциями и инструментальными способами для разработки и работы с оконными пользовательскими интерфейсами. Инструментальные средства прототипирования были реализованы на языке Smalltalk на рабочей станции Sun. Эти средства позволяют разработчику работать с предопределенными объектами типа кнопок, панелей и т.д. Законченная система затем сохраняется для прикладных программистов. Система TAE была написана на Си с поддержкой X Window System, но она не совместима с системой Smalltalk. Этим образом, создатели приняли решение переписать инструментальное средство на C++, дабы объединить выдающиеся качества объектно-ориентированного расклада в написании интерфейса с совместимостью со стереотипными способами на подобии X Window.

IBM Rational Rose – средство визуального моделирования, которое считается стандартом де-факто среди средств, используемые при визуальном проектировании приложений. Этот продукт входит в состав установочного пакета IBM Rational Suite и применяется для моделирования программных систем с использованием широкого круга инструментов, средств и платформ. Rational Rose позволяет создавать, изменять и проверять корректность созданные модели.

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

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

Для разработчиков на Visual Studio и WinDNA - Rational Rose плотно соприкасается с MS Visual Studio, также гарантирует помощь семантики также схемы WinDNA, визуализацию также повторную исследование программный код COM/ATL, MTS также ADO, настройку также раскрытую исследование стандартов с целью генерации многоуровневых дополнений WinDNA.

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

ЗАКЛЮЧЕНИЕ

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

Исходя из рассмотренного материала, можно сделать несколько выводов.

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

К недостатку ООП можно также отнести повышенные требования к аппаратуре. Практическая Деятельность применения ТМООП в IBM PC/AT продемонстрировала затормаживание быстроты исполнения проектов во 5-7 один раз согласно сопоставлению с подобными проектами на Си или Паскале. При этом время получения готовой программы сократилось в 2-3 раза, программы стали выглядеть яснее, лучше приспособлены для повторного использования.

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

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

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

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

1. Основы объектно-ориентированного подхода к анализу и проектированию информационных систем [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: https://sites.google.com/site/anisimovkhv/learning/pris/lecture/tema9, свободный. – Загл. с экрана – дата обращения 15.12.19.
2. Объектно-ориентированное программирование [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: https://ru.wikipedia.org/wiki/ Объектно-ориентированное программирование, свободный. – Загл. с экрана – дата обращения 15.12.19.
3. Основные понятия объектно-ориентированных систем [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: http://www.math.rsu.ru/smalltalk/obzornew-2.ru.html, свободный. – Загл. с экрана – дата обращения 15.12.19.
4. Основы применения объектно-ориентированного программирования [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: https://www.itweek.ru/themes/detail.php?ID=39282, свободный. – Загл. с экрана – дата обращения 15.12.19.
5. Теория и практика UML. Диаграмма состояний [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: http://it-gost.ru/articles/view_articles/97, свободный. – Загл. с экрана – дата обращения 15.12.19.
6. Унифицированный язык моделирования UML [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: http://www.maksakov-sa.ru/ModelUML/IziMod/index.html, свободный. – Загл. с экрана – дата обращения 15.12.19.
7. IBM Rational Rose [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: http://www.interface.ru/home.asp?artId=314, свободный. – Загл. с экрана – дата обращения 20.12.19.
8. UML-диаграммы классов [Электронный ресурс] – Электрон. текстовые дан. – Режим доступа: https://prog-cpp.ru/uml-classes/, свободный. – Загл. с экрана – дата обращения 15.12.19.

ПРИЛОЖЕНИЕ A

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

Рисунок 2 – Диаграмма классов

Рисунок 3 – Диаграмма состояний