Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы.pdf

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

- Конструкторы, деструкторы, финализаторы.

- Свойства(аксессоры).

- Индексаторы.

- Интерфейсы – как альтернатива множественному наследованию.

- Переопределение операторов для классов.

Часть языков (иногда называемых «чисто объектными») целиком построена вокруг объектных средств - в них любые данные (возможно, за небольшим числом исключений в виде встроенных скалярных типов данных) являются объектами, любой код – методом какого-либо класса и невозможно написать программу, в которой не использовались бы объекты. Примеры подобных языков – Java или Ruby. Другие языки (иногда используется термин «гибридные») включают ООП-подсистему в исходно процедурный язык. В них существует возможность программировать, не обращаясь к объектным средствам. Классические примеры - C++ и Delphi [В.В. Мухортов, В.Ю. Рылов ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, АНАЛИЗ И ДИЗАЙН Методическое пособие Новосибирск 2002 с. 211].

Большинство существующих методов объектно-ориентированного анализа и проектирования (ОО-АП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов [Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов/ Д. Розенберг., К. Скотт Издательский дом «Вильямс», 2012. с. 326]. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.

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

Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 1980-х и начале 1990-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метола OOSE (Object-Oriented Software) Ивар Якобсон [Крэг Ларман Применение UML 2.0 и шаблонов проектирования. 3-е издание. Издательство: Вильямс]. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

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

- обеспечить независимость от конкретных языков программирования и процессов разработки [Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя Издательский дом «Вильямс», 2010. с. 125].

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

- стимулировать рост рынка объектно-ориентированных инструментальных средств;

- интегрировать лучший практический опыт.

Язык UML находится в процессе стандартизации, проводимом ОМG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, и в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО [Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя Издательский дом «Вильямс», 2010. с. 122.]. Кроме того, практически все мировые производители САSЕ-средств, помимо Rational Software (Rational Rose) поддерживают UML в своих продуктах (Paradigm Plus, System Architec, Microsoft Visual Modeler, Delphi, PowerBuilder и др.).

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый ОМG в 1997 г., предлагает следующий набор диаграмм для моделирования [Крэг Ларман Применение UML 2.0 и шаблонов проектирования. 3-е издание]:

- диаграммы вариантов использования – для моделирования бизнес-процессов организации (требований к системе);

диаграммы классов – для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения системы;

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

- диаграммы состояний – для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы деятельностей – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей;

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

У большинства людей понятие проектирование ассоциируется со структурным проектированием по методу сверху вниз на основе функциональной декомпозиции, согласно которой вся система в целом представляется как одна большая функция и разбивается на подфункции, которые, в свою очередь, разбиваются на подфункции и т.д. Эти функции подобны вариантам использования в объектно-ориентированной системе, которые соответствуют действиям, выполняемым системой в целом [Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов/ Д. Розенберг., К. Скотт Издательский дом «Вильямс», 2012. – с 333].

В объектно-ориентированном подходе основная категория объектной модели – класс – объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы). Именно с этой точки зрения изменения, связанные с переходом от структурного к объектно-ориентированному подходу, являются наиболее заметными. Разделение процессов и данных преодолено, однако остается проблема преодоления сложности системы, которая решается путем использования механизма компонентов [Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UMLМ./ Л.А Мацяшек: Издательский дом «Вильямс», 2002. - с 128].

3.3 Объектно-ориентированное проектирование и его связь с другими методами проектирования

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований [Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя Издательский дом «Вильямс», 2010. с. 147]. Буч отмечает также ряд следующих преимуществ объектно-ориентированного подхода:

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

Объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие [Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов/ Д. Розенберг., К. Скотт Издательский дом «Вильямс», 2012.].

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

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

К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты [Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UMLМ./ Л.А Мацяшек: Издательский дом «Вильямс», 2002. с. 169]. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка объектно-ориентированного моделирования UML, и количество САSЕ-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход.

Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения САSЕ-технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком для передачи понимания, обеспечивается на сегодняшний день только структурными методами [Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов/ Д. Розенберг., К. Скотт Издательский дом «Вильямс», 2012. с. 53].

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

Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области [Крэг Ларман Применение UML 2.0 и шаблонов проектирования. 3-е издание]. Переход организации на объектно-ориентированную технологию – это смена мировоззрения, а не просто изучение новых САSE-средств и языков программирования.

Основой взаимосвязи между структурным и объектно-ориентированным подходами является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и др.). Эта взаимосвязь может проявляться в различных формах. Так, одним из возможных подходов является использование структурного анализа как основы для объектно-ориентированного проектирования [В.В. Мухортов, В.Ю. Рылов ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, АНАЛИЗ И ДИЗАЙН Методическое пособие Новосибирск 2002 с. 211]. Такой подход целесообразен ввиду широкого распространения САSЕ-средств, поддерживающих структурный анализ. Его можно считать слишком прагматическим, но в некоторых ситуациях иной подход невозможен. При этом структурный анализ следует прекращать, как только диаграммы потоков данных начнут отражать не только деятельность организации (предметную область), а и систему ПО.

После выполнения структурного анализа и построения диаграмм потоков данных вместе со структурами данных и другими продуктами анализа можно различными способами приступить к определению классов и объектов. Так, если взять какую-либо отдельную диаграмму, то кандидатами в объекты могут быть внешние сущности и накопители данных, а кандидатами в классы – потоки данных [Крэг Ларман Применение UML 2.0 и шаблонов проектирования. 3-е издание. с. 231].

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