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

Содержание:

ВВЕДЕНИЕ

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

Свою историю объектно-ориентированный подход берет в далеких 60-х гг. XX в. Именно в этот период термин «объект» был впервые использован применительно к разработке программных продуктов. О. Дж. Даль, Б. Мюрхог и К. Ньюгард (Норвежский вычислительный центр, Осло) разработали язык Simula 67. В основе языка лежал известный и популярный на тот момент язык Algol-60. Предполагалось, что новый язык будет успешно применяться для моделирования и реализации сложных информационных систем [6, c. 25].

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

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

Глава 1. Функционально-модульная и объектно-ориентированная технологии проектирования ИС

Существует два основных подхода к разработке информационных систем, отличающихся критериями декомпозиции. Первый подход – функционально-модульный, или структурный, определяется принципом алгоритмической декомпозиции. В соответствии с этим принципом осуществляется разделение функций ИС на модули по функциональной принадлежности, и каждый модуль реализует один из этапов общего процесса. Функционально-модульный подход к проектированию ИС, получивший название «модель водопада», предусматривает строго последовательный порядок действий. Главный недостаток такого подхода заключается в движении информации в одном направлении. Если при проектировании или эксплуатации возникает проблема, то она решается только на данной стадии проекта, не затрагивая предыдущих стадий. Недостаточная обратная связь приводит к ограниченным исправлениям, что в свою очередь, приводит к деформированным реализациям. Ориентация на функционально-модульный подход увеличивает вероятность потери контроля над решением возникающих проблем [13, c. 41].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1 Этапы проектирования ИС

Выделим следующие этапы проектирования ИС [13, c. 107]:

I. Исследование предметной области.

II. Разработка архитектуры системы.

III. Реализация проекта.

IV. Внедрение системы.

V. Сопровождение системы.

Рассмотрим каждый этап детально.

Этап I. Исследование предметной области предусматривает следующие шаги:

1. Спецификацию деятельности в предметной области.

2. Анализ деятельности в предметной области.

2.1. Структурно-логический анализ деятельности.

2.1.1. Анализ путей.

2.1.2. Анализ связности (прочности и сцепления) компонентов предметной области.

2.2. Анализ производительности.

2.3. Экономический анализ.

Этап II. Разработка архитектуры системы включает в себя разработку следующих компонентов:

1. Спецификации требований к проектируемой системе.

2. Конструирование концептуальной модели предметной области.

3. Спецификации обработки данных в проектируемой системе.

4. Спецификации пользовательского интерфейса системы.

5. Спецификации деятельности в предметной области с учетом внедрения системы.

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

Рисунок 1. Модели представления проектных решений

Модель классификации ориентирована на группирование объектов предметной области в соответствии с различными аспектами классификации и важность тех или иных свойств этих объектов [10, c. 73]. Модель декомпозиции ориентирована на описание систем, способных выполнять действия над данными. Различают виды декомпозиции действий на основе:

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

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

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

Модель пользовательского интерфейса ориентирована на описание взаимодействий пользователей с проектируемой системой, состава форм представления и команд управления заданиями.

Модели логики ориентированы на описание потока управления (последовательности выполнения) операторов программной системы и действий пользователей.

Для отображения результатов проектирования на различных этапах используются следующие виды схем представления проектных решений [10, c. 84]:

1. Схемы первичной классификации.

2. Схемы вторичной классификации.

3. Схемы детализации.

4. Схемы спецификации функциональных возможностей.

5. Схемы локальных моделей данных.

6. Схемы потоков.

7. Диаграммы переходов.

8. Схемы спецификации пользовательского интерфейса.

9. Схемы распределенной обработки данных.

10. Структурированные карты объектов.

Схема классификации описывает многомерную одноуровневую классификацию одного элемента. Каждый признак (основание)классификации имеет глобальный идентификатор и имя: саt. <ид. признака классификации>–<имя признака классификации>.

Дуги на схеме классификации помечаются соответствующими элементами типа cat.

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

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

Вторичные основания классификации элемента формируются в соответствии с основаниями классификации элементов, которые сильно связаны с данным элементом.

Схемы потоков являются средством более детальной спецификации функциональных или организационных элементов. В соответствии с типами потоков будем различать схемы [4, c. 251]:

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

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

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

Этап III. Реализация информационных систем на основе информационных технологий должна быть основана на инженерных подходах, предполагающих качественные, оптимальные по используемым ресурсам, эффективные и удобные в эксплуатации разработки. В достаточной степени разработана технология проектирования программного обеспечения (ПО). Однако в ИС кроме программной составляющей существенную роль играет информационная составляющая, определяющая структуру, атрибутику и типизацию данных, ограничения целостности для баз данных, логику управления последними, поэтому при проектирования ИС приоритет отдается информационной модели, на основе которой реализуются остальные компоненты, включая диалог [13, c. 114].

Рассмотрим кратко основные аспекты и сложившиеся подходы к реализации ИС.

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

Одиночные ИС реализуются на автономном компьютере (чаще всего ПК), могут содержать несколько простых приложений, рассчитаны на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых «настольных» СУБД или с помощью файловой системы и диалоговой оболочки для ввода, редактирования и обработки данных.

Групповые ИС ориентированы на коллективное использование информации членами обособленной рабочей группы, обычно строятся как локальная вычислительная сеть ПК или реже как много терминальная вычислительная система. Однотипные или специализированные рабочие места обеспечивают вызов одного или нескольких приложений. Общий информационный ресурс представляет собой базу данных или совокупность файловых структур. При разработке таких систем используются «настольные» СУБД, серверы БД для рабочих групп и соответствующие инструменты разработки [9, c. 47].

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

Групповые и корпоративные информационные системы могут строиться на основе следующих способов:

• многотерминальные централизованные вычислительные системы;
• системы на основе локальной сети ПК;
• системы с архитектурой «клиент – сервер»:
• системы с распределенными вычислениями;
• офисные системы;
• системы на основе Интернет / интранет-технологий.

Среди средств разработки информационных систем выделяют следующие основные группы [3, c. 79]:

• традиционные системы программирования;
• инструменты для создания файл-серверных приложений;
• средства разработки приложений «клиент – сервер»;
• средства автоматизации делопроизводства и документооборота;
• средства разработки Интернет / интранет-приложений;
• средства автоматизации проектирования (CASE-технологии).

Традиционные системы программирования представлены средствами создания приложений на алгоритмических языках программирования (Си, Паскаль, Бейсик и др.). Инструментальные средства программирования могут быть представлены набором утилит (редактор текстов, компилятор, компоновщик и отладчик) или интегрированной программной средой. Развитием традиционных систем программирования является объектно-ориентированное и визуальное программирование [9, c. 56].

Основой разработки файл-серверных приложений для локальных сетей ПК являются инструментальные средства «персональных» СУБД, реализованные в виде диалоговой интегрирующей среды, предоставляющей три уровня доступа:

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

Среди инструментальных средств реализации приложений с архитектурой «клиент – сервер» выделяют следующие:

• среды разработки приложений для серверов баз данных;
• независимые от СУБД инструменты для создания приложений «клиент – сервер»;
• средства поддержки распределенных информационных приложений.

Среди этой группы следует выделить инструментальные средства быстрой разработки приложений RAD (Rapid Application Development),обеспечивающие реализацию удаленного доступа к СУБД по двухзвеннойсхеме «клиент – сервер»; связь клиентских приложений с серверами БД с помощью непроцедурного языка структурированных запросов SQL; целостность БД, включая целостность транзакций; поддержку хранимых процедур на серверах БД; реализацию клиентских и серверных триггеров-процедур; генерацию элементов диалогового интерфейса и отчетов [7, c. 346].

Средства автоматизации делопроизводства и документооборота подразделяются на следующие подгруппы:

• средства автоматизации учрежденческой деятельности OfficeAutomation;
• системы управления электронным документооборотом EDMS
• EDI – электронный документооборот и UN/EDIFACT – европейский стандарт EDI в задачах логистики;
• средства обеспечения коллективной работы Groupware;
• средства автоматизации документооборота Workflow.

Данная группа средств включает в свой состав: текстовые редакторы для подготовки и корректировки документов; процессоры электронных таблиц для расчетов, анализа и графического представления данных; программы генерации запросов по образцу из различных БД; сетевые планировщики для назначения рабочих встреч и совещаний; средства разработки и демонстрации иллюстративных материалов для презентаций; словари и системы построчного перевода и др. Эти средства представляют собой отдельные пакеты (Win Word, Word Perfect, Excel, Lotus), интегрированный пакет программ (MS Works) или согласованный набор пакетов (Microsoft Office, Corel Perfect Office).

Средства программирования Интернет / интранет-приложений представлены различными системами программирования на интерпретируемых языках Java, Java Script, Tel и др. Построенные с использованием этих средств приложения могут загружаться с любого web-сервера сети и интерпретироваться на клиентском узле. Это обеспечивает платформенную независимость при расширении функциональных возможностей.

Средства автоматизации проектирования приложений (CASE-технологии) предназначены для анализа предметной области, проектирования и генерации программных реализаций. Новые тенденции в реализации приложений связаны с промышленным характером разработки программного обеспечения. Среди существующих инструментальных средств такого типа целесообразно выделить следующие [3, c. 92]:

• комплект специальных инструментальных средств быстрой разработки прикладных ИС – RAD (Rapid Application Development);
• технологический комплекс разработки программного обеспечения RUP (Rational Unified Process) фирмы Rational Software;
• технология разработки программного обеспечения ExtremeProgramming (XP).

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

Наиболее полным описанием процесса разработки программного обеспечения, включающим методики выполнения работ на каждой стадии жизненного цикла системы, является Rational Unified Process (RUP), уникальность которого заключается в том, что это стандартизованный процесс разработки программного обеспечения, используемый многими крупными компаниями по всему миру. RUP обладает следующими преимуществами по сравнению с другими процессами [7, c. 270]:

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

В качестве графической нотации в RUP используется Unified Modeling Language (UML), являющийся стандартом для представления объектных моделей. В UML артефакты разработки представляются диаграммами, описывающими структуру программы и ее поведение.

Другим подходом к разработке программного обеспечения является технология Extreme Programming или ХР. Основными элементами данного подхода являются [2, c. 43]:

• быстрая разработка программного продукта на основе стандартных шаблонов проектирования;
• постоянное взаимодействие разработчиков с заказчиками системы;
• минимизация затрат на документирование проекта;
• максимальное использование программных тестов («unittests») для проверки функциональности и корректности исходных кодов программ;
• использование рефакторингов для расширения функциональности системы и устранения ее недостатков.

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

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

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

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

Этап IV. Внедрение системы в действие.

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

Этап V. Сопровождение ИС [13, c. 116].

• выполнение работ в соответствии с гарантийными обязательствами;
• послегарантийное обслуживание.

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

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

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

Методы структурного проектирования помогают упростить процесс разработки сложных систем за счет использования алгоритмов как готовых строительных блоков. Аналогично, методы объектно-ориентированного проектирования созданы, чтобы помочь разработчикам применять мощные выразительные средства объектного и объектно-ориентированного программирования, использующего в качестве блоков классы и объекты [1, c. 44].

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

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

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

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

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

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

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

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

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

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

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

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

Подход полезен как с методической точки зрения (две разнородные характеристики предметной области – данные и программы – объединяются в объекты), так и с точки зрения техники проектирования и разработки программных систем (вместо двух технически не связанных, но логически переплетенных веток образуется один надёжный ствол) [14, c. 8].

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

В объектно-ориентированных системах декомпозиция системы на объекты осуществляется с учётом удобства последующего детального анализа, разработки и внедрения системы. Одним из наиболее важных критериев выделения компонентов системы является минимизация числа аппаратно-зависимых её компонент. Это позволяет снизить затраты на адаптацию системы при переносе на другую аппаратную платформу, а также уменьшить количество неиспользуемых компонент при работе на конкретной платформе. Решение этой проблемы осуществляется путём исследования существующих платформ, оценки направлений их развития, анализа возможностей использования принятых и (или) предложения новых стандартов взаимодействия системы с аппаратной платформой [5, c. 107].

На основе декомпозиции системы:

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

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

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

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

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

• объектно-ориентированная разработка программного обеспечения;
• объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. К объектно-ориентированной разработке относятся [10, c. 122]:

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

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

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

Можно выделить следующие объектно-ориентированные методологии разработки программного обеспечения [8, c. 9]:

• RUP (Rational Unified Process);
• OMT (Object Modeling Technique);
• SA/SD (Structured Analysis/Structured Design);
• JSD (Jackson Structured Development);
• OSA (Object-Oriented System Analysis).

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

Среди свойств объектов в объектно-ориентированном подходе можно отметить:

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

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

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

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

Основное преимущество объектно-ориентированного подхода состоит в упрощении проектирования информационных систем, при наличии типовых проектных решений по отдельным компонентам, а также легкости модификации, поскольку модификация касается лишь отдельных компонент [12, c. 96].

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Буч Г. Объектно-ориентированный анализ и проектирование / Г. Буч. – СПб.: — Невский диалект, 2015. – 560 с.

2. Буч Г., Рамбо Дж., Якобсон А. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. – СПб.: — Питер, 2014. – 432 с.

3. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М.: — Финансы и статистика, 2014. – 238 с.

4. Вендров Л.М. Обзор средств проектирования информационных систем / Л.М. Вендров. – М.: — Финансы и статистика, 2013. – 341 с.

5. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. – М.: — ДМК, 2015. – 354 с.

6. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: — БИНОМ, 2018. – 300 с.

7. Емельянова Н.З., Партыка Т.Л., Попов И.И. Проектирование информационных систем / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. – М.: — Форум, 2013. – 432 c.

8. Заботина Н.Н. Проектирование информационных систем / Н.Н. Заботина. – Братск: — ГОУВПО БрГТУ, 2017. – 119 с.

9. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования / Е.З. Зиндер. – М.: — Центр Информационных Технологий, 2016. – 174 с.

10. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К. Объектно-ориентированное программирование / Г.С. Иванова, Т.Н. Ничушкина, Е.К. Пугачев. – М.: — МГТУ им. Н.Э. Баумана, 2018. – 320 с.

11. Ипатова Э.Р. Методологии и технологии системного проектирования информационных систем / Э.Р. Ипатова. – М.: — ФЛИНТА, 2016. – 256 с.

12. Йордан Э., Аргила С. Объектно-ориентированный анализ и проектирование систем / Э. Йордан, С. Аргила. – М.: ЛОРИ, 2017. – 264 с.

13. Коцюба И.Ю., Чунаев А.В., Шиков А.Н. Основы проектирования информационных систем / И.Ю. Коцюба, А.В. Чунаев, А.Н. Шиков – СПб.: — ИТМО, 2015. – 206 с.

14. Рогачев А.М. Современные методы и средства проектирования информационных систем / А.М. Рогачев. – Архангельск: — САФУ, 2015. – 90 с.

15. Федоров Н.В. Проектирование информационных систем на основе современных CASE-технологий / Н.В. Федоров. – М.: — МГИУ, 2018. – 278 с.

ПРИЛОЖЕНИЯ

Приложение 1.

Модели представления проектных решений