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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

Проблемы этой темы изучались такими выдающимися авторами как Черников Б.В., Рыбальченко М. В., Попов А.В., Григорьева А. Л., Лошманов А. Ю., Назаров С.В., Перлова О.Н., Григорьев М. В., Григорьева И. И., Кравченко А. В., Анисимов В.В., Астапчук В. А., Терещенко П. В., а также другие исследователи, специалисты в области информационных технологий. Они углубились в проблему, высказали свое мнение и тщательно изучили все аспекты данной темы.

Объект работы: информационные системы

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

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

Задачи работы:

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

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

1.1 Основные понятия, используемые в объектно-ориентированном подходе

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

архитектуры компьютеров (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 использовались только объектно-ориентированные конструкции [3, с.29].

Объектная модель, которая является концептуальной базой объектно-ориентированной методологии, имеет четыре главных элемента [10, с.63] :

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

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

типизация
параллелизм

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

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

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других [18, с.16].

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

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

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории) [1, с.65]. При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

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

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

Иерархия - ранжированная (упорядоченная) система абстракций. Основными видами иерархических структур, применительно к сложным системам, является структура классов (иерархия "is -a") и структура объектов (иерархия "part of"). Принцип наследования позволяет упростить выражения абстракции, делая проект менее громоздким и более выразительным [3, с.79].

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

Дополнительные элементы: типизация - ограничение предъявляемых классу объектов, препятствующих взаимозамене различных классов и в большинстве случаев сильно сужающих возможность такой замены. Концепция типизации строится на понятии абстрактных типов данных. Тип - точное определение свойств строения или поведения, которое присуще некоторой совокупности объекта [9, с.41] . Часто термины «тип» и «класс» считают эквивалентными. Более точно сказать, что класс реализует тип. Типизация позволяет выполнять описание абстракций т. о., что реализуется поддержка проектных решений на уровне языка программирования.

В тоже время объектно-ориентированные языки программирования могут быть: строго типизированными, нестрого типизированными и совсем не типизированными, что позволяет говорить о типизации, как о второстепенном элементе. Сильно типизированные языки - это такие языки, в которых все выражения проводят проверку на соответствие типов. С++ поддерживает сильную типизацию. Различают статическую типизацию (раннее связывание) и динамическую типизацию (позднее связывание). Разделение имеет отношение ко времени, когда имена связывают с типами: статическая - во время компиляции; динамическая - во время исполнения программы [15, с.92].

Полиморфизм возникает на стыке принципов наследования и динамических связей [9, с.42] . Это свойство является самым существенным в объектно-ориентированном программировании. Полиморфизм отличает объектно-ориентированное проектирование от более традиционных методов с использованием абстрактных типов данных [12, с.123] .

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

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

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

Объектно-ориентированная технология проектирования ИС предоставляет мощную, гибкую, универсальную концептуальную основу для конструирования информационно-управляющих систем в различных областях хозяйственной деятельности и управления, сочетающую использование моделей современной логистики, объектного подхода к компонентам предметной области, современных инструментальных средств визуального программирования и СУБД с SQL-интерфейсом [15, с.96] .

Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты [19, с.154] :

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

В основу объектно-ориентированной технологии проектирования ИС положены разработка, анализ и спецификация концептуальной объектно-ориентированной модели предметной области [4, с.219].

Концептуальная объектно-ориентированная модель предметной области является основой проекта и реализации системы и обеспечивает:

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

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

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

Отличительными чертами предлагаемой технологии являются [4, с.220]:

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

При всем разнообразии моделей предметных областей концептуального уровня (Power Designer «Моделирование бизнеса» (Sybase), Oracle Method, Rational Rose – Гради Буч, Object – Oriented Design LanguagE (OODLE) – Салли Шлеер и Стефан Меллор) отсутствуют такие модели, которые бы позволяли в полной мере использовать знания по классификации элементов предметной области для описания свойств ее элементов и в то же время сохраняли преимущества традиционных функционального и информационного подходов, основанных на модели данных [15, с.110]. «Чистый» объектный подход (Гради Буч) уже на ранних стадиях требует представлять данные о классификации в виде диаграмм классов. Это слишком жесткое требование [19, с.156]. Выделение иерархии классов требует проведения объемного и тонкого анализа различных аспектов взаимосвязей объектов предметной области. В рамках самого объектного подхода подобных методик нет. С другой стороны, попытки совместить чистый объектный подход с традиционными подходами (Салли Шлеер) оказываются неудачными, так как последние рассматриваются не как обоснование решений объектного подхода, а как средство моделирования последнего [2, с.46].

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

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

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

Базовыми составляющими объектно-ориентированного подхода являются [19, с.147] :

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

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

Неотъемлемой частью унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода [6, с.82] . Следует отметить, что унифицированный процесс и UML разрабатывались совместно.

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

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

2.1 Особенности объектно-ориентированной системы

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

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

Составными частями объектно-ориентированной методологии (ООМ) являются [16, с.109]:

объектно-ориентированный анализ;
объектно-ориентированное проектирование;
объектно-ориентированное программирование.

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

В данном определении можно выделить три части:

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

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

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

В данном определении содержатся две важные части [2, с.53] :

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

Главными достоинствами объектно-ориентированного подхода являются [7, с.112]:

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

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

описание системы в виде объектов больше соответствует содержательному смыслу предметной области [7, с.74]. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;
сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга [14, с.187];
объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы[2, с.62] . Это облегчает решение проблем:
адаптации системы к изменению существующих или появлению новых требований;
сопровождения системы на разных стадиях жизненного цикла;
повторного использования компонентов;
объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться его автономной работы [8, с.26] ;
Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации кодогенерации. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД [17, с.114]. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая кодогенерация (например, экранов или функций обработки данных) возможна лишь в редких случаях.

2.2 Использование объектно-ориентированной технологии в проектировании информационной системы

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

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

Выявление сущности требований к программному продукту (концептуализация). Концептуализация должна установить основные требования к системе. Для каждой принципиально новой части программы или даже для новою применение существующей сжпемы найдется такой момент, когда в голову разработчика, архитектора, аналитика или конечного пользователя западет идея о новом приложении [8, с.96]
Разработка модели требуемого поведения системы (анализ). Цель анализа — дать описание задачи. Описание должно быть полным, непротиворечивым, пригодным для чтения и обозрения всеми заинтересованными сторонами, реально проверяемым [11, с.163]. Говоря нашим языком, цель анализа — представить модель поведения системы.
Создание архитектуры для реализации (проектирование). Цель проектирования — создать архитектуру развивающейся реализации и выработать единые тактические приемы, которыми должны пользоваться различные элементы системы. Процесс проектирования начинается сразу после появления некоторой приемлемой модели поведения системы [13, с.318] Важно не начинать проектирование до завершения анализа. Равным образом важно избегать затягивания проектирования, пытаясь получить идеальную, а следовательно, недостижимую аналитическую модель.
Итеративное выполнение реализации (эволюция). Цель эволюции — наращивать и изменять реализацию, последовательно совершенствуя ее, чтобы в конечном счете создать готовую систему.
Управление эволюцией продукта в ходе эксплуатации. Сопровождение — это деятельность по управлению эволюцией продукта в ходе его эксплуатации. Она в значительной степени продолжает предыдущие фазы, за исключением того, что вносит меньше архитектурных новшеств. Вместо этого делаются более локализованные изменения, возникающие по мере учета новых требований и исправления старых ошибок.

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

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

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

выявление классов и объектов на данном уровне абстракции. Цель выявления классов и объектов состоит в том, чтобы найти границы предметной области. Кроме того, эта деятельность является первым шагом в продумывании объектно-ориентирован ной декомпозиции разрабатываемой системы [6, с.71] .
выяснение семантики этих классов и объектов Цель выяснения семантики классов и объектов — определить поведение и атрибуты каждой абстракции, выявленной на предыдущем шаге. При этом уточняются намеченные абстракции, продуманно и измеримо распределяя между ними обязанности.
выявление связей между этими классами и объектами. Цель выявления связей между классами и объектами — уточнить границы каждой обнаруженной ранее в микропроцессе абстракции и опознать все сущности, с которыми она взаимодействует. Это действие формализует концептуальное и физическое размежевание между абстракциями, начатое на предыдущем шаге [4, с.56] .
спецификация интерфейса и реализация этих классов и объектов. На этапе анализа реализация классов и объектов нужна, чтобы довести существующие абстракции до уровня, достаточного для обнаружения новых классов и объектов на следующем уровне абстракции; они сами будут в дальнейшем поданы на новую итерацию микропроцесса. При проектировании целью реализации становится создание осязаемого представления наших абстракций путем выпуска последовательных исполнимых версий системы (макропроцесс).

Основные преимущества использования объектно-ориентированной технологии [17, с.52]:

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

К недостаткам объектно-ориентированного подхода можно отнести [5, с.198]:

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

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

Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты [18, с.23]:

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

Концептуальная объектно-ориентированная модель предметной области является основой проекта и реализации системы и обеспечивает [9, с.41] :

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

Отличительными чертами предлагаемой методологии являются следующие [16, с.169]:

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

Отличительными чертами предлагаемой технологии являются [8, с.110]:

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

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

В объектно-ориентированном подходе основное внимание уделяется захвату структуры и поведения информационных систем в небольшие модули, объединяющие как данные, так и процессы. Основная цель объектно-ориентированного проектирования (OOD) — повысить качество и производительность системного анализа и проектирования, сделав его более удобным для использования [10, с.86].

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

Унифицированный язык моделирования (UML). UML — это визуальный язык, который позволяет моделировать процессы, программное обеспечение и системы, чтобы выразить дизайн архитектуры системы[12, с.141]. Это стандартный язык для проектирования и документирования системы объектно-ориентированным способом, который позволяет техническим архитекторам общаться с разработчиком.

Он определяется как набор спецификаций, созданных и распространяемых Группой управления объектами. UML расширяемый и масштабируемый [17, с.303].

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

UML состоит из [18, с.29] :

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

Пример нотации UML для класса:

Запись класса
Диаграмма экземпляра — нотация UML
UML нотация
Операции над объектами

Следующие операции выполняются на объектах[17, с.306] :

Конструктор / Деструктор — создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.

Запрос — Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного сотрудника.

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

UML весьма полезен для следующих целей [12, с.146] :

Моделирование бизнес-процесса
Описание архитектуры системы
Отображение структуры приложения
Захват поведения системы
Моделирование структуры данных
Построение подробных спецификаций системы
Зарисовка идей
Генерация программного кода
Статические Модели

Статические модели показывают структурные характеристики системы, описывают ее системную структуру и делают акцент на тех частях, которые составляют систему. Они используются для определения имен классов, атрибутов, методов, подписи и пакетов [10, с.19].

Диаграммы UML, которые представляют статическую модель, включают диаграмму классов, диаграмму объектов и диаграмму прецедентов. Они используются для определения имен классов, атрибутов, методов, подписи и пакетов [12, с.149] .

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

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

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

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

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

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

Модель объектно-ориентированная выгодна следующими способами [17, с.310]:

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

Есть три типа объектных отношений [10, с.38] :

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

Жизненный цикл разработки объектно-ориентированной системы

Он состоит из макропроцессов [5, с.195] :

Объектно-ориентированный анализ (ООА)
Объектно-ориентированный дизайн (OOD)
Объектно-ориентированная реализация (OOI)

Разработка объектно-ориентированных систем включает в себя следующие этапы [4, с.177]:

Объектно-ориентированный анализ
Объектно-ориентированный дизайн
макетирования
Реализация
Инкрементальное тестирование

Объектно-ориентированный анализ. Этот этап касается определения системных требований и понимания системных требований для построения модели сценария использования. Вариант использования — это сценарий, описывающий взаимодействие пользователя и компьютерной системы. Эта модель представляет пользовательские потребности или пользовательское представление системы [4, с.181].

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

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

Макетирования. Прототипирование позволяет полностью понять, насколько легко или сложно будет реализовать некоторые функции системы [10, с.40].

Это также может дать пользователям возможность прокомментировать удобство использования и полезность дизайна. Это может дополнительно определить сценарий использования и значительно упростить моделирование сценария использования.

Реализация. Он использует либо компонентную разработку (CBD), либо быструю разработку приложений (RAD).

Компонентно-ориентированная разработка (CBD). CODD — это промышленный подход к процессу разработки программного обеспечения с использованием различных технологий, таких как инструменты CASE [1, с.18]. Разработка приложений переходит от индивидуальной разработки к сборке предварительно созданных, предварительно протестированных, повторно используемых программных компонентов, которые работают друг с другом. Разработчик CBD может собрать компоненты для создания полной программной системы.

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

Его задача состоит в том, чтобы быстро и постепенно реализовать приложение, чтобы реализовать дизайн требований пользователя с помощью таких инструментов, как Visual Basic, Power Builder и т. Д.

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

Заключение

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Анисимов В.В. Проектирование информационных систем: курс лекций. В 2 ч. Ч.1. Структурный подход / В.В. Трофимов. - Хабаровск: Изд-во ДВГУПС, 2006. - 112 с.
Астапчук В. А., Терещенко П. В.- Корпоративные информационные системы: требования при проектировании 2-е изд., испр. и доп. Учебное пособие для вузов-М.:Издательство Юрайт,2019-113 с.
Белов В.В. Проектирование информационных систем: Учебник / В.В. Белов. - М.: Академия, 2018. - 144 c.
Вичугова А. А. Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурного и объектно-ориентированного подходов / А.А. Вичугова. - М.: Университет, 2014. - 458 c.
Водяхо А.И. Архитектурные решения информационных систем. Учебник / А.И. Водяхо. - М.: Лань, 2017. - 862 c.
Гвоздева Т.В. Проектирование информационных систем: технология автоматизированного проектирования. Лабораторный практикум. Учебно-справочное пособие / Т.В. Гвоздева, Б.А. Баллод. - СПб.: Лань, 2018. - 156 c.
Григорьев М. В., Григорьева И. И.- Проектирование информационных систем. Учебное пособие для вузов-М.:Издательство Юрайт, 2019-318 с.
Губин А.Ю. Объектно-ориентированный подход к проектированию информационного портала организации 2015. - 205 с.
Гуськов М. Ю. Принципы объектного подхода в разработке систем промышленной автоматизации / М. Ю. Гуськов, Л. В. Гурьянов // Новые информационные технологии и системы: материалы XIII Международной научно-технической конференции - Пенза: Издательство Пензенского государственного университета, 2016. – 118 с.
Информационные системы предприятия: Учебное пособие / Варфоломеева А. О., Коряковский А. В., Романов В. П. - М.: НИЦ ИНФРА-М, 2016. - 283 с.
Карминский А.М. Методология создания информационных систем / А.М. Карминский. - М.: ИНФРА-М, 2018. - 264 c.
Кравченко А. В. Методика оценки эффективности информационных систем / А.В. Кравченко. - М.: Университет, 2015. - 380 c.
Назаров С.В. Архитектура и проектирование программных систем / С.В. Назаров. - М.: ИНФРА-М, 2018. - 968 c.
Перлова О.Н. Проектирование и разработка информационных систем: Учебник / О.Н. Перлова, О.П. Ляпина, А.В. Гусева. - М.: Academia, 2017. - 416 c.
Попов А.В., Григорьева А. Л., Лошманов А. Ю. Объектно-ориентированный анализ, проектирование и программирование информационной системы университета // Современные проблемы науки и образования. – 2012. – 311 с.
Проектирование информационных систем : учеб. пособие / В.В. Коваленко. — М. : ФОРУМ : ИНФРА-М, 2018. — 320 с.
Раскин Д. Интерфейс: Новые направления в проектировании компьютерных систем / Д. Раскин. - М.: Символ-плюс, 2013. - 798 c.
Рыбальченко М. В.- Архитектура информационных систем. Учебное пособие для СПО-М.:Издательство Юрайт,2019. – 91 с.
Черников Б.В. Лексикологический синтез документов в комплексах информационных систем / Б.В. Черников. - М.: Форум, 2018. - 239 c.