Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (ПОНЯТИЕ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ И ЕЕ ОСОБЕННОСТЕЙ).pdf
Добавлен: 27.06.2023
Просмотров: 79
Скачиваний: 2
В основе объектно-ориентированного проектирования лежит объектный подход. OOП принципиально отличается от традиционных подходов структурного проектирования, так как подразумевает иной подход к процессу декомпозиции. А программный продукт по архитектуре в значительной степени выходит за рамки традиционных представлений.
ООП основное внимание направляет на правильное и эффективное структурирование сложных систем. Это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления как логической и физической так статистической и динамической модели проектируемой системы [8].
Базовыми составляющими объектно-ориентированного подхода являются:
- унифицированный процесс;
- унифицированный язык моделирования;
- шаблоны проектирования.
Унифицированный процесс– это процесс разработки программного обеспечения (ПО), при котором обеспечивается упорядоченный подход к распределению задач и обязанностей в организации-разработчике. Унифицированный процесс затрагивает все этапы жизненного цикла ПО, начиная с определения требований и заканчивая сопровождением. Данный процесс являет собой некий суммированный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.
Неотъемлемой частью унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. Следует отметить, что Унифицированный процесс иUMLразрабатывались совместно.
На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования.
Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML(например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.
Наиболее популярными методологиями, поддерживающими данный подход, в настоящий момент являются:
-унифицированный процесс(Unified Process, UP);
-экстремальное программирование(eXtreme Programming, XP);
-гибкое моделирование(Agile Modeling, AM).
ООП имеет ряд преимуществ:
- отображение системы в виде объектов, что в большей степени соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода база данных должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту могут храниться в нескольких таблицах;
- сущности реального мира, как правило, обладают определеным поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;
- объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Данное преимущество позволяет решить проблемы адаптации системы к постоянно меняющимся требованиям, сопровождения на разных жизненных циклах ИС, а так же повторного использования компонентов.
- объектно-ориентированный подход дает возможность облегчить организацию параллельные вычисления, так как каждый объект в системе наделен собственными значениями характеристик (атрибутов) и поведением, что может быть использовано для его автономной работы;
- достижение большой степени автоматизации кодогенерации за счет Case-средств. Такие средства, работающие при структурным подходе, удачно справляются с генерацией структур баз данных. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации, что делает возможной автоматическую кодогенерацию (например, экранов или функций обработки данных) лишь в редких случаях[9].
Типичный процесс объектно-ориентированной разработки выглядит следующим образом (рис.2.1):
Рисунок 2.1.Процесс объектно-ориентированного проектирования
Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты:
-
- технологию конструирования концептуальной объектно-ориентированной модели предметной области;
- инструментальные средства спецификации проектных решений;
- библиотеки типовых компонент модели предметной области;
- типовые проектные решения для ряда функциональных областей.
В основу объектно-ориентированной технологии проектирования ИС положены разработка, анализ и спецификация концептуальной объектно-ориентированной модели предметной области. Концептуальная объектно-ориентированная модель предметной области является основой проекта и реализации системы и обеспечивает:
-
- необходимый уровень формализации описания проектных решений;
- высокий уровень абстрагирования, типизации и параметризации проектных решений;
- компактность описания;
- удобство сопровождения готовой системы.
Отличительными чертами предлагаемой методологии являются следующие:
-
- наличие единого методологически обоснованного ядра, обеспечивающего открытость технологии для модификации, расширения и создания новых моделей представления проектных решений;
- наличие единого формального аппарата анализа проектных решений для используемых моделей представления. Отличительными чертами предлагаемой технологии являются:
- совместное рассмотрение информационных, материальных и финансовых потоков;
- первичная и вторичная классификация объектов предметной области с обязательным указанием оснований классификации;
- наличие конструктивных методик декомпозиции и агрегирования компонентов проекта, использующих результаты классификации;
- наличие формальных методов оценки связности и сцепления компонентов проекта;
- использование функциональной модели данных с атрибутами – функциями доступа и атрибутами – категориями в качестве основы концептуальной модели данных.
2.3 Анализ и оценка средств реализации ООП
Существует два типа объектно-ориентированных моделей системной архитектуры:
- статические модели, описывающие структуру системы как классы объектов и взаимоотношений между ними, которые документируются на данном этапе, являются отношениями обобщения, отношениями "используют - используются" и структурными отношениями;
- динамические модели, описывающие структуру системы и показывающие динамические взаимодействия между объектами системы (но не классами объектов), документируемые взаимодействия содержат последовательность составленных объектами запросов к сервисам и описывают реакцию системы на взаимодействия между объектами.
В языке моделирования UML поддерживается ряд возможных статических и динамических моделей:
- модели подсистем, которые показывают логически сгруппированные объекты, они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет, и является статическим;
- модели последовательностей, которые показывают взаимодействия между объектами, они представляются в UML с помощью диаграмм последовательности или кооперативных диаграмм - динамические модели;
- модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события, в UML они представлены в виде диаграмм состояния - динамические модели.
Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. В UMLпакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Существует несколько способов создания, применения и введения новых определений для моделей ООП с использованием диаграмм вариантов использования сценариев, диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества, взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые вводятся сверху-вниз, другие - снизу-вверх, и все они итеративно определяются заново с помощью сотрудничества.
Статическое представление объектно-ориентированного анализа - представляет собой диаграмму класса, а также диаграмму объекта для представления определенного экземпляра класса, куда входят компоненты атрибутов, служб и отношений наряду с понятиями, взятыми из иерархии, абстракции, инкапсуляции и наследования. Идентифицируются ответственности классов, затем обработка идет наверх, а для достоверности применяются сценарии вариантов использования. В этом случае реализуется подход снизу-вверх. Подобный способ достаточно хорош, но существует еще путь сверху-вниз, когда при идентификации классов начинают с практических примеров, а затем продолжается обработка вниз, доходя до сценариев. Если начать с классов можно сначала идентифицировать их через абстракции. Затем для каждого класса перечисляются ответственности, идентифицируются атрибуты и операции (поведение - снова через абстракцию) и, наконец, обращаются к сценариям вариантов использования для подтверждения диаграммы класса. Однако сначала рассматривается описание диаграмм классов.
Статическое представление объектно-ориентированной разработки проекта - диаграммы взаимодействия и сотрудничества - отображают взаимодействия, которые пространственно ориентированы на окружение модели и характеризуют классы и ассоциации (экземпляры и связи). Целью сотрудничества является определение способов реализации вариантов использования. Диаграмма сотрудничества отображает отношения между экземплярами объектов. Поведение реализуется с помощью набора объектов, обменивающихся входными сигналами в рамках общего взаимодействия, что позволяет достичь поставленной цели. Для представления механизмов, применяемых при разработке, важно обращать внимание только на определенные объекты и изучать взаимодействие между ним. Рассматриваемые объекты всегда выделяются из большей системы, в которой данные объекты являются лишь компонентами.
Сотрудничество уточняет контекст, который позволяет выразить поведение реализуемого элемента в терминах, единых для всех участников сотрудничества. Таким образом, в то время как модель представляет систему в целом, сотрудничество является лишь частичным отображением данной модели. Именно сотрудничество определяет эффективность применения подмножества содержимого модели. Сотрудничество можно охарактеризовать на двух различных уровнях: на уровне спецификации или на уровне экземпляра. Диаграмма, представляющая сотрудничество на уровне спецификации, характеризует роль классов и ассоциаций. В то же время диаграмма на уровне экземпляра отображает экземпляры и связи, которые согласуются с ролями в сотрудничестве. При отображении сотрудничества указывается, какие экземпляры свойств должны принимать участие в сотрудничестве, т.е. каждый участник указывает необходимые свойства, которыми должен обладать согласуемый экземпляр.
Динамическое представление объектно-ориентированного проектирования - диаграммы взаимодействия и последовательные диаграммы-демонстрируют взаимодействие, отображенное в динамике. В ней отображаются экземпляры, участвующие во взаимодействии с помощью соответствующих линий жизни, а также входные сигналы, которыми они обмениваются. Эти сигналы собраны во временную последовательность. В отличие от диаграммы сотрудничества, последовательная диаграмма включает временные последовательности, но не содержит объектных отношений. Последовательная диаграмма может существовать в общей форме (описывать все возможные сценарии) и в форме экземпляра (описывать один действительный сценарий). Последовательные диаграммы и диаграммы сотрудничества выражают подобную информацию, однако, используют различные способы. Последовательная диаграмма имеет две размерности: размерность по вертикали представляет время; размерность по горизонтали представляет различные объекты.
Динамическое представление объектно-ориентированной разработки проекта -диаграммы переходов между состояниями - представляют, основанное на состоянии, поведение класса экземпляров объектов для всех сценариев. Обычно моделируются лишь классы с объектами, которые, как ожидается, проходят через наборы состояний. Состояниепредставляет условие или ситуацию во время жизни объекта, при которой удовлетворяется определенное условие, реализуется некоторая деятельность или же ожидается какое-либо событие. Диаграмма состояния отображает механизм состояния - поведение, определяющее последовательности состояния, которые проходит объект или взаимодействие во время своей жизни при отклике на события, вместе с соответствующими откликами и действиями.