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

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

Данные преимущества достигаются при разработке системы в соответствии с основными принципами объектно-ориентированной парадигмы:

• Инкапсуляция — свойство объекта, предусматривающее ограничения на внесение изменений в объект за счет сокрытия информации о его внутренней структуре. Взаимодействие с объектом возможно лишь посредством его методов и атрибутов. Методы и атрибуты объединяются под определением интерфейса объекта.
• Наследование — механизм, реализующий новые объекты на основе уже имеющихся. Данный механизм позволяет использовать атрибуты и методы одного объекта внутри другого объекта; при этом допускается их частичная или полная модификация. Объект, созданные по данному механизму носит определение потомка.
• Полиморфизм — свойство объектов, позволяющее реализовывать различные действия в ответ на одни и те же вызовы, в зависимости от разных внешних условий, сопровождающих данный вызов. Как правило под этим подразумевается способность подбирать операции в зависимости от типа данных, сопровождающих вызов из вне. [3]

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

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

Любой объект характеризуется следующими свойствами: индивидуальность, состояние, поведение.

• Состояние — одна из кондиций, возможных для данного объекта, способная изменяться с течением времени; зависит от атрибутов данного объекта и взаимных вызовов объектов.
• Поведение — регламентирует реакцию объекта на вызовы из вне и его возможные действия. Данное свойство обеспечивается с помощью списка методов данного объекта.
• Индивидуальность определяет уникальность данного объекта, вне зависимости от совпадения его состояния с другим объектом. [2]

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

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

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

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

1.5.Объектно-ориентированный анализ.

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

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

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

Объектно-ориентированный анализ и проектирование (ООАП) — методика разработки информационных систем, в основе которой находится принцип объектно-ориентированного представления предметной области в форме объектов, являющихся экземплярами конкретных классов. [15]

Технология ООАП в значительной степени связана с системами автоматизированной разработки программного обеспечения (Computer Aided Software Engeniring — CASE). Изначально к CASE-инструментам было настороженное отношение. Впоследствии возникли как восхищенные отклики, так и критические замечания в их адрес. Для подобных противоречивых оценок был ряд оснований. Одно из них состоит в том, что первые CASE-средства являлись примитивной «надстройкой» над системами управления баз данных. Применение визуализации в процессе развертывания базы данных значительно ускоряет данный процесс, однако это не является решением при разработки программного обеспечения иных классов.

В основе другой причины лежит графическая нотация, реализованная в CASE-инструментарии. Предложения по созданию единого синтаксиса для визуального представления концепции структуры базы данных, по типу строгого синтаксиса в языках программирования, получили неоднозначную реакцию. Это обеспечило «радушный прием» сообществом разработчиков стандартизованного языка моделирования UML. [14]

В пределах объектно-ориентированного анализа и проектирования были определены три графические нотации:

• диаграммы «сущность-связь»
• диаграммы функционального моделирования
• диаграммы потоков данных

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

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

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

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

ГЛАВА.2 СРЕДСТВА РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ С ИСПОЛЬЗОВАНИЕМ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

2.1.Язык проектирования UML.

Появление отдельных языков объектно-ориентированного проектирования было отмечено в середине 70-х годов. В то время отдельные авторы предлагали множество методик проектирования. К началу девяностых годов существовало около пятидесяти языков ООАП, что вызывало у пользователей определенные сложности с выбором конкретной методики, поскольку каждая из них, наравне с преимуществами, обладала и своими недостаткам. Появление к этому времени таких стандартов как IDEF0 и IDEF1X не решало проблему унификации методик в полной мере.

Однако ряд методов к этому времени приобрел несколько большую популярность, в сравнении с остальными. Такими методами стали:

• Booch (автор — Гриди Буч)
• Object Modeling Technique (автор — Джеймс Румбах)
• Object-Oriented Software Engineering (автор — Айвар Джекобсон)

Особенностью данных методов являлась специализация на конкретном уровне анализа и проектирования. В частности, методика Айвара Джекобсона имела инструменты визуализации вариативности применения, что важно на этапе анализа требований при развертывании информационных систем.

Подход Джеймса Румбаха проявлял максимальную эффективность на этапе анализа процессов обработки информации в приложениях.

В октябре 1994 года Буч и Румбах начали работу по интеграции и унификации собственных подходов. При этом проводились исследования всех доступных на тот момент средств объектно-ориентированного проектирования и анализа с целью выявления их преимуществ. Впервые унифицированный метод был представлен в 1995 году и имел к тому моменту версию 0.8. Позже в состав рабочей группы вошел Джекобсон, его методика Object-Oriented Software Engineering так же была интегрирована в Unified Method.

К этому моменту Unified Method Language получил поддержку консорциума Object Managment Group, который был создан раннее с целью разработки стандартов в области объектных и компонентных технологий CORBA. В составе данного консорциума была создана группа разработчиков, куда вошли вышеуказанные авторы методик, и которая взяла на себя задачу по дальнейшему развитию UML.

Позже был создан так называемый консорциум партнеров UML, куда вошли такие компании как DEC, IBM, HP, Oracle, Unisys, Rational Software. С их участием версия UML 1.0 была создана к январю 1997 года. Данная версия имела хорошую определенность, предоставляла средства, обеспечивающие высокую выразительность, обладала гибкостью, позволяющей решать задачи широкого спектра. [1]

История разработки и последующего развития языка UML графически представлена на рисунке 1.

Рисунок 1. История развития UML

На сегодняшний день разработка и стандартизация языка UML сосредоточена в пределах консорциума OMG. При этом отмечается, что данный язык открыт для всех предложений по его дальнейшему развитию. Новейшая версия UML — 2.5; представлена в июне 2015 года.

UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

На сегодняшний день на рынке программного обеспечения существует множество CASE-средств, поддерживающих UML и предоставляющих генерацию программ на популярных языках программирования, таких как Java, C++, Delphi и т. д.

Заинтересованность разработчиков в UML возрастает с течением времени. Он является базисом в CASE-средствах визуального моделирования. Кроме того, он применяется не только для объектно-ориентированного анализа и проектирования, но и для документирования бизнес-процессов. [8]

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

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