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

Содержание:

ВВЕДЕНИЕ

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

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

В данной работе будет рассмотрен объектно-ориентированный подход по отношению к проектированию ЭИС.

ГЛАВА 1. ПОНЯТИЕ И СВОЙСТВА ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

В случае рассмотрения экономического объекта реального мира информационную систему будут называть экономической информационной системой (ЭИС). Другими словами, ЭИС – это человеко-машинная система, обеспечивающая с использованием компьютерных технологий сбор, передачу, обработку и хранение информации для управления производством (Семенов М.И., Трубилин А.И.; Под ред. Лойко В.И. Информационные системы и технологии в экономике - М.: Финансы и статистика, 2005. - С. 51).

Информационная система создается для конкретного экономического объекта и должна в определенной мере копировать взаимосвязи элементов объекта.

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

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

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

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

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

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

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

Всех этих принципов можно добиться, проектируя систему при помощи средств объектно-ориентированного подхода.

ГЛАВА 2. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД

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

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

Проблемы, стимулировавшие развитие ООП:

• необходимость повышения производительности разработки за счет многократного (повторного) использования ПО;
• необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений);
• облегчение проектирования систем (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006 - С. 162).

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

• абстрагирование;
• инкапсуляция;
• модульность;
• иерархия.

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

• типизация;
• параллелизм;
• устойчивость.

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

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

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

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

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

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

Устойчивость – свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан), (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006 - С. 163 - 165).

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

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

Класс - это множество объектов, связанных общностью свойств, поведения, связей и семантики (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - С. 167). Любой объект является экземпляром класса. Определение классов и объектов - одна из самых сложных задач объектно-ориентированного проектирования.

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

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

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

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

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

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

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

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

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

Рассматривая диаграмму UML, необходимо помнить, что основной принцип UML заключается в том, что любая информация на конкретной диаграмме может быть подавлена. Это подавление может носить глобальный характер – скрыть все атрибуты – или локальный – не показывать какие-нибудь конкретные классы. Поэтому по диаграмме вы никогда не можете судить о чем-нибудь по его отсутствию (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 41).

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

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

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

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

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

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

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

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

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

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

Составим для данного примера диаграмму вариантов использования (рисунок 1).

Идея описания функциональных требований в виде вариантов использования была сформулирована в 1986 г. Иваром Якобсоном. (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - С. 179).

Достоинства диаграммы вариантов использования заключаются в том, что она:

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

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

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

Действующие лица можно идентифицировать, задавая следующие вопросы:

• Кто использует систему непосредственно?
• Кто отвечает за эксплуатацию системы?
• Какое внешнее оборудование используется системой?
• Какие другие системы взаимодействуют с данной системой?

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

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

Рисунок 1

По данной диаграмме составим описания вариантов использования (таблица 1, таблица 2), рассмотрев принцип действия актера “материально ответственное лицо” при приеме и выдаче товара.

Таблица 1. Описание варианта использования «Приём/поставка товара»

1. Главный раздел
Имя варианта использования	Приём/поставка товара
Актеры	Материально ответственное лицо, Поставщик
Цель	Принять товар на склад
Краткое описание	Материально ответственное лицо принимает товар на склад от поставщика согласно приходным ордерам
Тип	Базовый
2. Раздел «Типичный ход событий»
Действия актера	Отклик ПК
1. Материально ответственное лицо запрашивает просмотр карточки складского учета	2. ПК показывает окно карточки складского учета
3. Материально ответственное лицо запрашивает изменение записи в карточке складского учета	4. ПК показывает окно с записями карточки складского учета
5. Материально ответственное лицо изменяет записи в карточке складского учета	6. ПК подтверждает изменение записей в карточке складского учета
7. Материально ответственное лицо запрашивает оформление приходного ордера	8. ПК показывает окно оформленного приходного ордера

Таблица 2. Описание варианта использования «Выдача/получение товара»

1. Главный раздел
Имя варианта использования	Выдача/получение товара
Актеры	Материально ответственное лицо, Получатель
Цель	Выдать товар со склада
Краткое описание	Материально ответственное лицо выдаёт товар со склада получателю согласно расходным ордерам
Тип	Базовый
2. Раздел «Типичный ход событий»
Действия актера	Отклик ПК
1. Материально ответственное лицо запрашивает просмотр карточки складского учета	2. ПК показывает окно карточки складского учета
3. Материально ответственное лицо запрашивает изменение записи в карточке складского учета	4. ПК показывает окно с записями карточки складского учета
5. Материально ответственное лицо изменяет записи в карточке складского учета	6. ПК подтверждает изменение записей в карточке складского учета
7. Материально ответственное лицо запрашивает оформление расходного ордера	8. ПК показывает окно оформленного расходного ордера

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

Диаграммы деятельности - это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельное процессы (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 139).

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

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

Для моделирования работы склада создадим диаграмму деятельности материально ответственного лица. На рисунке 2 приведена диаграмма приема/поставки товара, а на рисунке 3 – выдачи/получения.

Рисунок 2

Рисунок 3

Из описаний выше составляем диаграмму классов для нашей модели, рисунок 4.

Классами называются базовые элементы любой объектно-ориентированной системы. Класс — это множество объектов, связанных общностью свойств, поведения, связей и семантики (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - С. 167).

В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов.

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

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

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

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

Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 62).

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

Мощность показывает, как много объектов участвует в связи. Мощность - это число объектов одного класса, связанных с одним объектом другого класса. Для каждой связи можно обозначить два показателя мощности - по одному на каждом конце связи. В языке UML приняты следующие нотации для обозначения мощности (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006 - С. 173 - 174).

Значения мощности:

• * - много;
• О - нуль;
• 1 - один;
• 0..* - нуль или больше;
• 1..* - один или больше;
• 0..1 – нуль или один;
• 1..1 – ровно один.

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

В рассматриваемом примере классами являются: поставщик, получатель материально-ответственное лицо, карточка складского учёта, приходный и расходный ордера, справочник товаров. В каждом классе есть свои атрибуты и операции. Например, у класса поставщик имеются атрибуты: наименование организации, юридический адрес, телефон/факс, расчётный счёт; операции: AddSuplier() – добавление поставщика, RemoveSuplier() – удаление поставщика, GetSuplier() – получение информации о поставщике, GetAllSuplier() – получении списка поставщиков.

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

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

Рисунок 4

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

ГЛАВА 4. ОБЗОР CASE-СРЕДСТВ

CASE-средства (Computer Aided Software Engineering) - это программные средства моделирования, позволяющие графически проектировать систему, рас­пространять дизайн проекта для широкой аудитории, публиковать модели и отчеты, а также генерировать рабочий код прило­жений и баз данных. Вместе с тем, большинство средств по­зволяет генерировать модели из готового кода, что дает возможность проводить рефакторинг приложений на более высоком уровне.

Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного проектирования, является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates. Входящий в этот пакет продукт, а именно AllFusion Component Modeler (Paradigm Plus) является средством для проектирования, визуализации и поддержки качественных информационных систем. Обеспечивая расширенную поддержку совместного проектирования и многократного использования компонентов модели, существенно увеличивает производительность команды разработчиков. Обеспечивает полную поддержку UML, языка объектного моделирования для документирования, специфицикации и проектирования приложений. Визуальное моделирование помогает управлять большими проектами и анализировать влияние изменений, а так же гарантирует, что получившийся в итоге продукт сможет удовлетворить потребности конечного пользователя. Продукт обеспечивает синхронизацию проектов приложений и их программных реализаций при любом числе изменений в коде и независимо от количества итераций проекта без применения маркеров кода или потери данных, включает функцию "Интеллектуальные связи", которая существенно упрощает создание крупномасштабных моделей за счет уменьшения числа действий, которые нужно совершать при рисовании связей.

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

• AllFusion Process Modeler - является инструментом визуального моделирования бизнес-процессов, поддерживающий три нотации моделирования: IDEF0, IDEF3 и DFD.
• 2.  AllFusion ERwin Data Modeler - инструмент проектирования, документирования и сопровождения базы данных, хранилища данных и витрины данных.
• 3.  AllFusion Data Model Validator – инструмент для проверки структуры баз данных и создоваемых моделей в Erwin, позволяющий выявлять недочеты проектирования.
• 4.  AllFusion Model Manager – средство для совместной работы группы проектировщиков.

Интегрированный целиком комплекс Case-средств, обеспечивает все потребности компаний-разработчиков.

Одним из наиболее применимых case-средств, помогающий преобразовать технические и бизнес-концепции в визуальную форму, является Microsoft Visio. К сожалению это не полноценное средство моделирования, а пакет, предназначенный исключительно для рисования UML-диаграмм. Но и этот пакет не лишен своих плюсов, например таких как: интеграция с другими приложениями MS Office; идет с семнадцатью языковыми пакетами, включая поддержку азиатских языков и двунаправленного текста; помогает повысить производительность, за счет вращения фигур без переключения в специальный режим вращения, выбор и вращение группы фигур, печать выбранной части диаграммы, функция поиска фигуры и других; возможность использовать для генерации и структурирования идей в виде диаграмм во время сессий мозгового штурма, которые можно экспортировать в Microsoft Word, Microsoft Excel или XML, положив таким образом начало созданию других бизнес-файлов; располагает встроенным средство рецензирования, которое можно использовать для отслеживания фигур и примечаний, оставленных другими соразработчиками и многое другое. Внешне Microsoft Visio похож на другие программы Microsoft Office, что дает ему фору перед другими программными средствами, так как не надо осваивать интерфейс с нуля, ведь он уже знаком большинству пользователей PC.

Теперь рассмотрим пакет с открытым программным кодом, написанный на Delphi. StarUML - это пакет для разработки быстрых, гибких, расширяемых, функциональных и распространяемых бесплатно платформ UML/MDA для систем Windows. Сам проект StartUML создан с целью разработки универсальной бесплатной платформы для моделирования. StarUML имеет мощную, но в тоже время простую архитектуру с поддержкой возможности подключения плагинов, поэтому любой разработчик имеет возможность принять участие в расширении функций утилиты, разработав и подключив собственный модуль, используя совместимые языки. Это дает платформе много большие перспективы развития пред коммерческими аналогами.

Интерфейс средства очень удобен и интуитивно понятен, так как напоминает Microsoft Visual. Базовый пакет StarUML способен создавать документацию в виде текстовых файлов, файлов MS Excel и MS PowerPoint, а так же доступен ряд модулей, добавляющих поддержку ER-диаграмм, некоторых профайлов UML, например SPEM, WAE и др.

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Семенов М.И., Трубилин А.И.; Под ред. Лойко В.И. Информационные системы и технологии в экономике - М.: Финансы и статистика, 2005. - 416 с.

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

3. Фаулер M. UML Основы, 3-е издание. - Пер. с англ. - СПб: Символ Плюс, 2004. - 192 с.