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

Содержание:

ВВЕДЕНИЕ

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

В основе решения любых экономических задач лежит обработка информации. Для облегчения обработки информации создаются информационные системы.

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

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

Таким образом, при разработке информационной системы приходится решать две задачи:

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

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

- определение функций, которые должны быть решены с целью обеспечения служб предприятия надежной и качественной информацией для принятия решений;

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

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

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

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

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

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

В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И наконец, в процессе конструирования или объектно-ориентированного программирования обеспечивается реализация разработанных компонентов на языке C++, C#, Java, Smalltalk или Visual Basic.

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

1. Структура объектно-ориентированного программирования

1.1. Технологии программирования

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

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

В 1958 году были разработаны первые языки программирования, Фортран и Алгол-58. Программа на Фортране состояла из главной программы и некоторого количества процедур - подпрограмм и функций. Программа на Алголе-58 и его последующей версии Алголе-60 представляла собой единое целое, но имела блочную структуру, включающую главный блок и вложенные блоки подпрограмм и функций. Компиляторы для Фортрана обеспечивали раздельную трансляцию процедур и последующее их объединение в рабочую программу, первые компиляторы для Алгола предполагали, что транслируется сразу вся программа, раздельная трансляция процедур не обеспечивалась. 

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

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

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

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

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

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

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

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

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

- Построением языка программирования, содержащего как можно больше типов данных, и выбором для каждого класса задач некоторого подмножества этого языка. Такой язык иногда называют языком-оболочкой. На роль языка-оболочки претендовал язык ПЛ/1, оказавшийся настолько сложным, что так и не удалось построить его формализованное описание. Отсутствие формализованного описания, однако, не помешало широкому применению ПЛ/1 как в Западной Европе, так и в СССР.

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

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

1.2. Сущность объектно-ориентированного подхода

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

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

• абстрагирование (abstraction);

• инкапсуляция (encapsulation);

• модульность (modularity);

• иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

• типизация (typing)',

• параллелизм (concurrency)',

• устойчивость (persistence).

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

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

1.2.1. Объектно-ориентированный подход

Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями.

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

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

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

Устойчивость — свойство объекта существовать но времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

1.2.2. Основные понятия объектно-ориентированного подхода

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

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

Семантика - смысл программы с точки зрения выполняющего ее компьютера.

Прагматика - смысл программы с точки зрения ее пользователей.

Рисунок 1. Семантика и прагматика

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

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

• уменьшение сложности программного обеспечения;

• повышение надежности программного обеспечения;

• обеспечение возможности модификации отдельных компонентов

• программного обеспечения без изменения остальных его компонентов;

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

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

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

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

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

Объект определяется как осязаемая реальность (tangible entity) — предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями.

Индивидуальность — это свойства объекта, отличающие его от всех других объектов.

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

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

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

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

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

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

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

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

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

• обеспечить независимость от конкретных языков программирования и процессов разработки;

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

1.4 Варианты использования

В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально - они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые ввел понятие "вариант использования" (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта.

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

Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования. На рис.2 показаны некоторые варианты использования для системы торговой организации; человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки — различные связи между действующими лицами и вариантами использования.

Рисунок 2. Диаграмма вариантов использования

Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. На рис.2 четыре действующих лица: Менеджер по продажам, Оптовый торговец, Продавец и Система учета. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, Система учета). Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.

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

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

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

В дополнение к связям между действующими лицами и вариантами использования существуют два других типа связей (см. рис.2): "использование" (uses) и "расширение" (extends) между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку

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

Выбор применяемой связи определяется следующими правилами:

• связь "расширение" следует применять при описании изменений в нормальном поведении системы;

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

Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей "использование" и "расширение"). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта.

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

• ассоциации (например, клиент может сделать заказ);

• подтипы (частный клиент является разновидностью клиента).

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

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

Построение диаграмм классов можно рассматривать в различных аспектах:

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

Рисунок 3. Диаграмма классов

• аспект спецификации — модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

• аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

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

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

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

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

С концептуальной точки зрения ассоциации представляют собой концептуальные связи между классами. На диаграмме показано, что Заказ должен поступить от единственного Клиента, а Клиент в течение некоторого времени может сделать несколько Заказов. Каждый из этих Заказов содержит несколько Строк заказа, каждая из которых соответствует единственному Продукту. Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

Роль может быть явно поименованная с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется «позиция заказа». Если такая метка отсутствует, роли присваивается имя класс - цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины «начало» (source) и «цель» (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

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

1.5.1. Преимущества ООП

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

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

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

Расширение типа (type extension) и вытекающий из него полиморфизм переменных оказываются полезными преимущественно в следующих ситуациях.

• Обработка разнородных структур данных. Программы могут работать, не утруждая себя изучением вида объектов. Новые виды могут быть добавлены в любой момент.
• Изменение поведения во время выполнения. На этапе выполнения один объект может быть заменен другим. Это может привести к изменению алгоритма, в котором используется данный объект.
• Реализация родовых компонент. Алгоритмы можно обобщать до такой степени, что они уже смогут работать более, чем с одним видом объектов.
• Доведение полуфабрикатов. Компоненты нет надобности подстраивать под определенное приложение. Их можно сохранять в библиотеке в виде полуфабрикатов (semifinished products) и расширять по мере необходимости до различных законченных продуктов.
• Расширение каркаса. Независимые от приложения части предметной области могут быть реализованы в виде каркаса и в дальнейшем расширены за счет добавления частей, специфичных для конкретного приложения.

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

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

1.5.2. Недостатки ООП

Объектно-ориентированное программирование требует знания четырех вещей:

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

2. Многоразовое использование требует от программиста познакомиться с большими библиотеками классов. А это может оказаться сложнее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций. В языке Smalltalk, к примеру, до того, как перейти к практическому программированию, нужно изучить значительную часть его библиотеки классов. А это тоже требует времени.

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

4. Очень трудно изучать классы, не имея возможности их «пощупать». Только с приобретением мало-мальского опыта можно уверенно себя почувствовать при работе с использованием ООП.

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

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

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

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

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

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

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

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

1. Неэффективность на этапе выполнения. В языках типа Smalltalk сообщения интерпретируются во время выполнения программы путем осуществления поиска их в одной или нескольких таблицах и за счет выбора подходящего метода. Конечно, это медленный процесс. И даже при использовании наилучших методов оптимизации Smalltalk-программы в десять раз медленнее оптимизированных C-программ [Cha92].

В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит лишь к вызову через указатель процедурной переменной. На некоторых машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И поскольку сообщения встречаются в программе гораздо реже других операций, их воздействие на время выполнения влияния практически не оказывает.

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

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

3. Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.

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

Другой подход — дать возможность компоновщику удалять лишние методы.

Такие интеллектуальные компоновщики уже доступны для различных языков и операционных систем.

Oberon избрал третий путь избавления от излишней универсальности.

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

Таким образом, нельзя утверждать, что ООП вообще неэффективно.

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

• 1. Программные продукты, применяемые для реализации объектно- ориентированного подхода

Существует великое множество продуктов, применяемых для реализации объектно-ориентированного подхода при проектировании информационных систем. Вот некоторые из них: AllFusion Process Modeler, AllFusion Data Modeler, IDS Sheer ARIS Express, IBM Rational Rose, IBM Rational Enterprise Architect, IBM Rational Team Concert, Microsoft Visual Studio, Microsoft Team Foundation Server, Embarcaderor RAD Studio, Component Builder, CVS, SVN, Microfocus StarTeam, Apache ANT, Apache Maven, MSBuild, JetBrains dotTrace, JetBrains Reflector, JetBrains ReSharper, Atlassian Jira, Atlassian Confluence, Microsoft Project, Gantt Project, IBM Rational Robot, IBM Rational Functional Tester, IBM Rational Performance Tester, IBM Rational Purify, IBM Rational Quantity, IBMRational PureCoverage. Рассмотрим некоторые из них.

• 1. Программа компьютерного моделирования BPwin (AllFusion Process Modeler)

BPwin - мощный инструмент моделирования, разработанный фирмой Computer Associates Technologies который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности - действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Таким образом, формируется целостная картина деятельности предприятия - от моделей организации работы в маленьких отделах до сложных иерархических структур. При разработке или закупке программного обеспечения модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же системных аналитиков и разработчиков BPwin - еще и мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).

В чем польза от BPwin.

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

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

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

BPwin позволяет:

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

BPwin (теперь AllFusion Process Modeler) — программный продукт в области реализации средств CASE-технологий. Позволяет проводить описание, анализ и моделирование бизнес-процессов. Занимает одно из лидирующих мест в своём сегменте рынка. В настоящее время выпускается компанией Computer Associates. Распространяется на коммерческой основе.

Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти методологии по-своему уникальны. Каждая из них может быть выполнена отдельно с помощью BPwin, но их совокупность заключённая в модель даёт аналитику полную картину предметной области клиента.

Полное (новое) название BPwin: AllFusion Process Modeler.

Кому нужен BPwin: всем компаниям, желающим добиться оптимальности и эффективности собственного бизнеса или бизнеса заказчиков. Руководителям проектов, бизнес-аналитикам, системным аналитикам, руководителям, маркетологам, консультантам, менеджерам по качеству и др.

Аргументы и факты:

• поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область более комплексно;
• позволяет повысить эффективность бизнеса, оптимизировать любые процедуры в компании;
• полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC);
• не дорог, распространён, по нему много информации и компетентных специалистов;
• лёгок в освоении и применении, есть курсы на русском языке
• позволяет облегчить сертификацию на соответствие стандартам качества ISO9000
• является стандартом де-факто, интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др
• благодаря вышеупомянутой интеграции и поддержке совместной, командной работы над одними и теми же моделями (с помощью ModelMart), не имеет аналогов для крупных проектов.
• Пример модели, построенной в Bpwin интегрирован со средством имитационного моделирования Arena. Имитационное моделирование - создание компьютерной модели системы (физической, технологической, финансовой и т. п.) и проведение на ней экспериментов с целью наблюдения/предсказания. Реальный эксперимент проводить дороже, а зачастую опасно или невозможно;
• содержит собственный генератор отчётов;
• позволяет эффективно манипулировать моделями - сливать и расщеплять их;
• имеет широкий набор средств документирования моделей, проектов.

Некоторые достоинства BPwin.

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

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

BPwin позволяет адаптироваться к постоянно меняющимся реалиям современного рынка.

Конкуренция предполагает мгновенную реакцию на новые возможности, угрозы и потребности покупателей. Сегодня постоянные изменения стали нормой. Поскольку бизнес-процессы становятся все более сложными, требуются решения, представляющие интегрированный взгляд на функционирование компании. Таким решением является релиз BPwin 4.0 SP1.

Управление сложными бизнес-процессами

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

Анализ бизнеса с различных сторон: поддержка в BPwin сразу трех нотаций: IDEF0, IDEF3 и DFD.

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

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

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

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

От подробностей бизнеса к интересам предприятия.

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

Отличительные черты BPwin.

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

Автоматизация процесса проектирования.

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

Свойства, определяемые пользователем.

Вы можете настроить BPwin для сбора информации, существенной для вашего бизнеса. Эта информация становится сразу же доступной через генератор отчетов BPwin и может быть экспортирована в другие программы, например, Microsoft Word и Excel.

Диаграммы Swim Lane.

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

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

Развитые диаграммы.

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

Организационные диаграммы.

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

Рисунок 4. Пример организационной диаграммы.

Технологии моделирования.

BPwin обеспечивает совместное и повторное использование технологий моделирования бизнес-процессов (IDEF0), потоков работ (IDEF3) и потоков данных (DFD).

Функционально-стоимостной анализ (ABC).

BPwin полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (ABC) и оптимизирована для анализа процессов. Развитые средства подготовки отчетов и двунаправленный интерфейс со специализированным инструментарием ABC облегчают реализацию корпоративной стратегии на основе управления хозяйственной деятельностью.

Собственный генератор отчетов.

Report Template Builder (RTB) - это новый генератор отчетов, общий для ERwin и BPwin, создающий разнообразные отчеты и Web-страницы. Вы можете определять шаблоны отчетов, применяя их затем к любым своим моделям. Подход "определить однажды - применять повторно и повсюду" позволяет организации быстро создавать и продвигать стандарты отчетности. RTB поддерживает множество форматов, включая RTF, HTML, XLS (Excel) и обычный текст.

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

AllFusion Process Modeler 7.

AllFusion Process Modeler 7 или как он ранее назывался BPwin - мощный программный продукт с помощью которого, можно проводить моделирование, анализ, описание и последующую оптимизацию бизнес-процессов. С помощью BPwin можно создавать графические модели бизнес-процессов. Графическое изображение схемы выполнения работ, организации документооборота, обмена различными видами информации позволяет визуализировать существующую модель организации бизнеса. Это дает возможность использовать передовые инженерные технологии для решения задач управления организацией.

С помощью BPwin (AllFusion Process Modeler 7) можно организовать подробное документирование всех важных аспекты бизнес-процессов т.е. необходимых действий, способов их осуществления и контроля за ними, необходимыми для этого ресурсами и впоследствии визуализировать полученную информацию. BPwin позволяет повысить эффективность ИТ-решений в бизнесе, проектировщики и аналитики бизнес-моделей получают возможность найти оптимальное соотношение между бизнес-требованиями, корпоративными инициативами, процессами информационной архитектуры и проектированием приложений. С помощью BPwin можно увидеть полную картину организации деятельности предприятия: от количества работы в небольших подразделениях предприятия до сложных функций организации предприятия.

Использование BPwin (AllFusion Process Modeler 7) эффективно использовать в проектах, в которых нужно сделать описание существующих баз предприятия, внедрить на предприятии корпоративные информационные систем и для проведения реорганизации существующих бизнес-проектов. С помощью BPwin можно провести оптимизацию деятельности предприятия и осуществить проверку на соответствие ее стандартам ISO 9000, создать проект организационной структуры, исключить ненужные операции, уменьшить размер издержек и увеличить эффективность. В основе программного продукта BPwin (AllFusion Process Modeler 7) заложены общепринятые технологии моделирования, такие как idef0. Моделирование с помощью методологии idef0 рекомендовано к использованию Госстандартом Российской Федерации и является общепринятым стандартом в США. Наглядность и простота моделей Process Modeler делает значительно более простым взаимодействие между различными участниками бизнес-процессов. Популярность BPwin (AllFusion Process Modeler 7) дает возможность согласовывать функциональные модели в электронном виде. BPwin (AllFusion Process Modeler 7) - это продукт компании Computer Associates, он вместе с ERwin Data Modeler (ERwin), Model Manager (ModelMart) и Data Model Validator (ERwin Examiner), входит в пакет программ AllFusion Modeling Suite. Использование этого программного комплекса позволяет эффективно обеспечить все аспекты моделирования информационных систем.

• 1. CASE-средства IBM Rational Rose

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции.

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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

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

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

Взаимодействие с другими средствами и организация групповой работы.

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

Для управляемой подмодели предусмотрены операции:

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

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

Среда функционирования.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Для работы системы необходимо выполнение следующих требований:

• Платформа Windows - процессор 80386SX или выше (рекомендуется 80486), память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.
• Платформа UNIX - память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

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

2.3. Microsoft Visual Studio 2010 - среда для быстрой разработки

Продукты Microsoft для разработчиков давно входят в список наиболее востребованного программного обеспечения для программистов разного уровня. За восемь лет существования на рынке среда разработки Microsoft Visual Studio стала де-факто стандартом создания .NET-приложений.

Для работы с Microsoft Visual Studio 2010 потребуется современный компьютер под управлением ОС Windows 2003/XP/Vista/2008/7, обновленных до самых последних версий. Полная установка пакета требует порядка 7,5 Гб свободного дискового пространства, наличия браузера Internet Explorer 8, библиотеки .NET Framework и офисного пакета MS Office 2007 или MS Office 2010. Интерфейс приложения отвечает существующей тенденции построения пользовательских оболочек приложений от Microsoft (мультитач-управление, графические эффекты оболочки Aero, ленточный интерфейс и так далее). Среда заметно упростились и улучшилась в плане пользовательского интерфейса (см. рис. 5) - это заметно по инструментам визуализации кода: программные архитекторы и программисты видят привычный для себя интерфейс, который выполнен с использованием технологий Windows Presentation Foundation и Silverlight, в котором для повышения удобства восприятия убраны некоторые линии и градиенты и оставлена возможность переключения между режимами. Также стоит отметить поддержку мультимониторных систем - это удобно для отладки кода.

Рисунок 5. Microsoft Visual Studio 2010 - стартовый экран.

Продукт создавался с включением элементов совместной работы и обмена данными между программистами, занятыми в проекте. Для этого нужна организация централизованного хранилища информации с гибким механизмом разграничения доступа к контенту, наглядными инструментами контроля состояния проекта и участия программистов в достижении ключевых показателей, системой отслеживания изменений, которые внесены в код и ждут одобрения. В MS Visual Studio 2010 это обеспечивается компонентом Team Foundation Server, который позволяет организовать доступ до единого хранилища требований для определенных участников проекта.

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

Рисунок 6. Microsoft Visual Studio 2010 - основной интерфейс.

Второй основной компонент Visual Studio Lab Management 2010 создан для построения диаграмм для реализации проекта. С его помощью можно построить сначала зависимости для текущего решения, чтобы увидеть, как оно будет работать, а потом визуализировать последовательности действий для новых функций, которые появятся в новом проекте. Примечательно, что все элементы могут быть легко выведены из частей диаграмм с сохранением общего дизайна проекта в исходном виде.

Для облегчения этого процесса в Microsoft Visual Studio 2010 применяется известная технология UML-моделирования с несколькими типами UML-диаграмм (диаграммы деятельностей, вариантов использования, последовательностей, классов, компонентов). Это позволяет команде разработчиков увидеть не только все связи объектов кода, но и ошибки связей и "узкие" места кода, которые необходимо исправить.

Рисунок 7. Microsoft Visual Studio 2010 - отладочный интерфейс.

Третий компонент среды разработки - MS Expression 3/Expression Blend. Это удобное средство для дизайнеров и разработчиков, которые могут создавать в нем расширенные медиарисунки не просто графического оформления частей и деталей проекта, но и концептуальную их составляющую (связи, навигацию, управление, формы и так далее). В результате подобные цифровые прототипы становятся своего рода интерактивными изображениями, которые имеют реальные элементы программного кода будущей реализации проекта, к которым разработчики могут оставлять свои пометки, замечания и предложения через вышеописанный Team Foundation Server, где эти файлы и размещаются. Руководители проекта могут организовать доступ к проекту и через веб-интерфейс, для чего потребуется только совместимый веб-браузер. Ресурсы можно просматривать напрямую из MS SharePoint 2010.

В основу Microsoft Visual Studio 2010 заложены два подхода к ведению проекта - линейный и с помощью гибких спринтов (в терминологии Microsoft ими называются этапы, которые состоят из установленных мероприятий по выполнению проекта, иными словами, это "дробление" хода проекта по частям). Для этого в Visual Studio 2010 появился новый набор типов рабочих элементов, типов связей, панели мониторинга, отчеты и документы, которые больше соответствуют стилю работы групп, использующих гибкий процесс. Таким образом, руководитель проекта получает набор инструментов для контроля и распределения нагрузки на исполнителей, видит всю иерархию зависимостей для выполнения задач. Это позволяет оперативно сориентироваться в случае возможной перегрузки отдельных сотрудников и перенести запланированные работы на другой период без особых простоев. Среда разработки позволяет сохранять эти схемы и применять их многократно, что экономит время на повторное распределение ролей.

Заметим, что Microsoft Visual Studio 2010 сохраняет обратную совместимость с предыдущими версиями среды - проекты с использованием предыдущих версий языков .NET будут сконвертированы в соответствии с обновленными компонентами и интегрированы с новыми компонентами. Тем не менее возможна и обратная операция, когда новую систему необходимо интегрировать со старым кодом. Для обеспечения отладки кода на предмет возникновения ошибок есть инструмент Test Impact View, который отображает все влияния изменений в коде на тестирование проекта. Программист с его помощью сможет увидеть, какие тесты ему нужно выполнить после того или иного внедрения или исключения фрагмента, переключаясь быстро между самим кодом и списком тестов.

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

В Microsoft оптимизировали IntelliTrace, уменьшив до 2-5 раз скорость синтаксического разбора кода любого размера. В Microsoft Visual Studio 2010 можно создавать несколько виртуальных сред с несколькими виртуальными ПК, на которых будут производиться тесты, анализы, сборки и развертывания приложений. Эта система построена на базе System Center Virtual Machine Manager, что существенно облегчает процессы виртуализации разработки. Кроме того, Microsoft Visual Studio 2010 совместима с развиваемой Microsoft платформой для "облачных" вычислений Azure.

ЗАКЛЮЧЕНИЕ

В работе были показаны современные методы и средства проектирования. Был рассмотрен объектно-ориентированный подход к проектированию информационных систем, суть подхода к проектированию, его достоинства и недостатки. Данная курсовая работа показала, что для облегчения процесса объектно-ориентированного анализа и проектирования существует ряд CASE-средств, некоторые из них были рассмотрены в работе (BPWin, IBM Rational Rose, Microsoft Visual Studio). Важным шагом в развитии объектно-ориентированного анализа стала разработка унифицированного языка моделирования (UML).

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

1. ООС позволяют справляться со сложностью.

2. ООС предназначены для изменений.

3. Объекты могут использоваться несколько раз.

4. ООС легко поддерживаются.

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

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

1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем - М.: ИУИТ, 2012 - 300 с.

2. Коваленко В.В. Проектирование информационных систем, учебник - М.: Форум - 2012, 320 с.

3. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. - 2-е изд., испр. и. дополн. – М.: Издательство Диалог-МИФИ, 2007 – 400 с.

4. Проектирование экономических информационных систем: Учебник/Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; Под. ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2003. – 512 с.

5. Г. Буч, А. Якобсон, Дж. Рамбо UML [пер. с англ. А. Вахитов, Д. Солнышков]. - 2-е изд. – М.: Питер, 2006 – 735 с.

6. Дубейковкий В.И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM – М.: ДИАЛОГ-МИФИ, 2007 – 384 с.

7. Дубейковкий В.И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как? – М.: ДИАЛОГ-МИФИ, 2007 – 464 с.

8. Маклаков С.В. Моделирование бизнес-процессов с AllFusion PM. – 2-е изд., испр. и. дополн. – М.: Издательство Диалог-МИФИ, 2007 – 224 с.

9. У. Боггс, М. Боггс UML и Rational Rose секреты эффективного проектирования объектно-ориентированных приложений – М.: ЛОРИ, 2004 – 509 с.

10. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с.