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

Содержание:

Введение

Проектирование информационных систем (ИС) – логически сложная, трудоемкая и длительная работа, требующая высокой квалификации специалистов. Однако до настоящего времени проектирование ИС нередко выполнялось на интуитивном уровне неформализованными методами, включающими в себя практический опыт, экспертные оценки и дорогостоящие экспериментальные проверки качества функционирования ИС. В последнее время ведущие аналитики отмечают, что большинство проектов выполнятся в режиме «death march», буквально – «смертельный марш» (Эдвард Йордан), т. е. это такой проект, параметры которого отклоняются от нормы на 50%. Освоение и правильное применение методов и средств создания ПО позволят повысить качество ИС, обеспечить управляемость процесса проектировании ИС и увеличить срок ее жизни.

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

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

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

Объектно-ориентированнный подход в проектировании, как и функционально-ориентированный, предполагает декомпозицию ИС.[6] Если в функционально-ориентированном подходе декомпозиции подлежали процессы обработки, то в объектно-ориентированном подходе декомпозиции подлежат объекты, которые характеризуются определенной структурой данных. Здесь декомпозиция идет от данных. В объектно-ориентиро-ванном подходе выделяют классы объектов. Каждый класс содержит однородные объекты.[1] Объектам одного класса присуще одинаковое множество методов реагирования на внешние сообщения. Иерархическая декомпозиция системы представляется в виде иерархии классов объектов, а функционирование системы – в виде взаимодействия объектов, обменивающихся сообщениями.

Среди свойств объектов в объектно-ориентированном подходе отметим следующие:

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

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

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

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

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

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

Модификация системы не требует полного пересмотра проекта, затрагивая лишь соответствующие классы и объекты.[5]

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

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

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

2.Методы проектирования программных систем

Разграничим понятия «метод» и «методология». Метод - это последовательный процесс создания моделей, которые описывают вполне определенными средствами различные стороны разрабатываемой программной системы.

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

Методы появились как ответ на растущую сложность программных систем. Для первых ЭВМ создавались простые программы. В 60-70-е годы эффективность применения компьютеров резко возросла, цены на них стали падать, а возможности ЭВМ увеличились. Сложность ПО возросла, поэтому в 60-70-е годы было разработано много методов, помогающих справиться с растущей сложностью программ.[4]

Методы разбивают на три группы:

• метод структурного проектирования сверху вниз (оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100000 строк);.
• метод потоков данных (DFD) (структура программной системы строится как преобразование входных потоков в выходные);
• объектно-ориентированное проектирование (OOD).[5]

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

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

3.Модели объектно-ориентированного проектирования

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

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

• условные обозначения - язык для описания каждой модели;
• процесс - правила проектирования модели;
• инструменты - средства, которые ускоряют процесс создания моделей, определяют законы их функционирования и помогают выявлять ошибки в процессе разработки.[6]

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

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

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

1. прогресс в области архитектуры ЭВМ (включая системную и аппаратную часть);
2. развитие языков программирования, таких как Simula, Smalltalk, CLU, Ada;
3. развитие методологии программирования, включая принципы модульности и защиты информации (сокрытия данных)".[4]

Три момента, оказавшие влияние на становление объектного подхода:

• развитие теории баз данных (ER-модели);
• исследования в области искусственного интеллекта (теория фреймов);

достижения философии и теории познания (греки – мир можно рассматривать как в терминах объектов, так и событий; Декарт _люди имеют объектный взгляд на мир; Клир – редукционизм и холизм).

Компоненты объектного подхода

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

С Т И Л Ь	ВИД АБСТРАКЦИИ
Процедурно-ориентированный	Алгоритмы
Объектно-ориентированный	Классы и объекты
Логико-ориентированный	Цели (наиболее часто выраженные в терминах исчисления предикатов)
Ориентированный на правила	Правила "если…- то…"
Ориентированный на ограничения	Инвариантные соотношения

5.Основные элементы объектно-ориентированного стиля

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

Ему соответствуют четыре главных элемента (без любого из них подход не будет ОО)	и три дополнительных элемента:
абстрагирование; ограничение доступа; модульность; иерархия	типизация; параллелизм; сохраняемость

• Абстрагирование – позволяет сосредоточить внимание на существенных характеристиках объекта с точки зрения наблюдателя (пример кошка для домохозяйки и ветеринара)[6]

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

Абстракция должна охватить лишь самую суть объекта, не больше, но и не меньше – «принцип наименьшей выразительности»[5]

Выделяют следующие обстракции:

• Абстракция сущности

объекта Объект представляет собой модель некой сущности (описание существенных сторон) предметной области

• Абстракция поведения Объект состоит из обобщенного множества операций, каждая из которых выполняет полезную функцию

•Абстракция в виде виртуальной машины Объект объединяет группы операции, которые либо используются для управления объектом (на более высоком уровне управления), либо сами используют некоторый набор операций более низкого уровня

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

Наиболее интересны абстракции сущностей объектов, так как они соответствуют словарю предметной области.

Объект, использующий ресурсы другого объекта называется клиентом.[1]

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

Понятия операция (Ada), метод (Smalltalk) и функция-элемент (C++ )- фактически обозначают одно и то же и используются как эквивалент.

Все абстракции обладают как статическими, так и динамическими свойствами.

Пример: Объект – файл. Статические свойства : объем требуемой памяти, имя, содержание. Динамические свойства: файл может изменять размеры, имя, содержание.[6]

Пример. В Object Pascal есть абстракции: переменные объектов, методы объектов; нет: переменных классов, методов классов. Отсутствуют также метаклассы и множественное наследование – эти механизмы исключены, чтобы сделать язык простым для изучения программистам начинающим изучать О.О. методологию. Поэтому Object Pascal иногда называют «обглоданным» О.О. языком[3]

Уже насчитывается около 2000 языков программирования, более 100 – объектных (имеющих механизмы реализации абстрактных данных и классов, например, Ada) и объектно-ориентированных языков (в которых реализован механизм наследования как средство отражения иерархии классов, например, Smalltalk, Object Pascal (в нем есть простое наследование), C++, Clos).

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

Практически это означает наличие двух частей в описании класса: интерфейса и реализации. Интерфейс – отображает внешнее проявление объекта, создавая абстракцию поведения всех объектов данного класса. Внутренняя реализация – описывает механизмы достижения желаемого поведения объекта.[2]

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

• Модульность – является элементом конструкции и позволяет осуществлять на её основе проектные решения. В таких языках ( например, Object Pascal, C++, Ada, CLOS, LISP) классы и объекты составляют логическую структуру системы, эти абстракции организуются в модули, образуя физическую структуру системы (особенно когда система состоит из сотен классов).[4]

Иначе говоря, «модульность – это разделение программы на раздельно компилируемые фрагменты (модули) , имеющие между собой средства сообщения».[1]

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

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

• Иерархия – это ранжированная или упорядоченная последовательность.

Пример иерархии: наследование - такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, простое или множественное наследование).

6.Дополнительные элементы объектно-ориентированного стиля.

• Типизация. Концепция типизации строится на понятии типов абстрактных данных.

«Тип – это точное определение свойств строения или поведения, которое присуще некоторой совокупности объектов». «Тип» и «Класс» - эквивалентные понятия

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

• Параллелизм. Реальная параллельность достигается только на многопроцессорных системах (системы с одним процессором имитируют параллельность за счет алгоритмов разделения времени). В то время, как объектно-ориентированное программирование основано на абстракции данных, ограничении доступа и наследовании, параллелизм связан с абстрагированием и синхронизацией процессов.[1]

Объект является основой, которая объединяет обе концепции: каждый объект (как абстракция реальности) может представлять собой отдельный канал управления (абстракцию процесса). Такой объект называется активным.

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

• Устойчивость – это свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и (или) в пространстве (перемещение объекта из адресного пространства, в котором он был создан {для многопроцессорных систем})[5]

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

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

• Инкапсуляция – объединение в данном элементе и данных, и способов их обработки. Можно определить данные, входящие в классы, и действия, которые могут выполняться над этими данными, как некоторую структуру–объект в системе, работающей согласно набору правил.[1]
• Наследование – сохранение, перенос атрибутов данных и выполняемых над ними операций от объекта к объекту. С помощью этого принципа строятся различные иерархии классов (простое наследование), а также смешанные классы (множественное наследование), когда некоторый новый класс одновременно наследует атрибуты и выполняемые над ними операции от нескольких базовых классов. При этом имеется возможность модифицировать «поведение» объектов.[3]
• Полиморфизм означает возможность единообразного обращения к объектам в тексте программы при сохранении уникальности их поведения. Этот принцип позволяет определять целый ряд объектов на основе одного базового класса и обращаться к ним единообразно при сохранении специфического поведения каждого из них. Так, операция сравнения различных объектов возможна только тогда, когда базовый класс определяет метод сравнения.[5]

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

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

• Объектный подход позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования (их преимущества не всегда очевидны)[4]
• Использование объектного подхода существенно повышает качество разработки в целом и её фрагментов.
• Использование объектного подхода приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений и позволяет избегать полной переработки системы в случае существенных изменений исходных требований.[2]
• Объектный подход ориентирован на человеческое восприятие мира (для многих людей является естественным ООП к системам).
• Объектный подход уменьшает риск разработки сложных систем потому что:

а) процесс интеграции растягивается во времени жизненного цикла системы;

б) объектный подход включает ряд хорошо продуманных этапов проектирования (что также уменьшает степень риска и повышает степень уверенности в правильности принимаемых решений).[1]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

В связи со своими особенностями объектно-ориентированное программирование имеет ряд преимуществ перед структурным (и др.) программированием. Выделим некоторые из них:

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

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

Особенность ООП

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

Список литературы

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. И доп. – М.: Финансы и Статистика, 2006 – 544с.,

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

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

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

5. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004

6. Гамма Э.Приемы объектно-ориентированного проектирования. Паттерны проектирования – М.: Питер, 2010