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

В основу объектно-ориентированной технологии проектирования ИС положены разработка, анализ и спецификация концептуальной объектно-ориентированной модели предметной области [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] Важно не начинать проектирование до завершения анализа. Равным образом важно избегать затягивания проектирования, пытаясь получить идеальную, а следовательно, недостижимую аналитическую модель.
• Итеративное выполнение реализации (эволюция). Цель эволюции — наращивать и изменять реализацию, последовательно совершенствуя ее, чтобы в конечном счете создать готовую систему.
• Управление эволюцией продукта в ходе эксплуатации. Сопровождение — это деятельность по управлению эволюцией продукта в ходе его эксплуатации. Она в значительной степени продолжает предыдущие фазы, за исключением того, что вносит меньше архитектурных новшеств. Вместо этого делаются более локализованные изменения, возникающие по мере учета новых требований и исправления старых ошибок.

---