Организация корпоративных информационных систем в ООО "ПИК НСС"

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

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

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

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

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

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

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

1.1 Общие принципы построения и основные этапы проектирования КИС

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

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

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

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

Появление настольных персональных компьютеров в 80-90 годах и резкий скачок производительности оборудования и ПО способствовали дальнейшему развитию КИС. Предприятия и организации, используя ИС как стратегическое оружие - своевременное предоставление нужной информации, достигали успеха в своей деятельности: создание новых товаров, услуг, нахождение новых рынков сбыта, поиск партнеров, организация выпуск продукции по низкой цене. Появляются MRPII, представляющие методологию, направленную на более широкий охват ресурсов, нежели MRP (в отличие от MRP, в системе MRPII производится планирование не только в материальном, но и в денежном выражении) [003] и CRM систем - прикладного ПО для организаций, предназначенного для автоматизации стратегий взаимодействия с заказчиками, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов [004].

С возникновением интернета в 1990-2000 годах появилась возможность получать заказы от клиентов удаленно, что способствовало появлению электронной экономики. После объединений функций планирования материальных и финансовых ресурсов появились ERP системы - системы на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы) [005]. С возможностью обновления данных через интернет стало возможным развитие систем нормативно-справочной информации. Общей целью использования ИТ являлось обеспечение конкурентоспособности организации.

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

В настоящее время ведущие производители КИС для организации стали предлагать системы новейшего класса ERPII - новая ревизия концепции ERP, основная идея которой заключается в выходе за рамки задач по оптимизации внутренних процессов организации. Системы класса ERPII позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. [007].

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

Главными особенностями современного подхода к построению КИС являются:

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

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

детальная проработка и согласование с заказчиком всех этапов разработки проекта, контрольных точек, требуемых ресурсов [008].

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

Анализируя опыт развертывания КИС, эксперты аналитического агентства McKinsey в 1997 году сформулировали принципы, построения таких систем:

экономическая необходимость - основанием для внедрения должна быть экономическая необходимость, а не просто появление новых ИТ;

финансовая целесообразность - объем финансирования новой ИС должен определяться из соображений финансовой выгоды;

простота структуры - система должна иметь простую и гибкую структуру;

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

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

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

Также принципы построения КИС зависят еще и от заданных индивидуальных свойств. Данная проблема встала перед ЗАО "СПРУТ-Технология" в 1993 г., когда была поставлена задача создания ИС управления всей городской инфраструктурой, включая саму мэрию. Специалистами было проведено обследование муниципальной инфраструктуры, а затем разработан проект системы, призванной решить весь комплекс поставленных задач. Но после первых попыток реализации прототипа на основе вышеописанных принципов интеграции отдельных компонент дали отрицательный результат. Дальнейший поиск решения и различного рода эксперименты по организации управления делами внутри мэрии поставили массу новых проблем. Проблемы коснулись психологии и менталитета людей, уровня сложившихся производственных отношений, а также стиля и правил индивидуальной и коллективной работы. Собранная по результатам исследования информация слабо соответствовала принятым в мире правилами постановки менеджмента, что ставило под сомнение возможную эффективность ИС в среде людей, каждый из которых работает по своим правилам и зачастую непредсказуем.

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

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

Различают две модели проектирования КИС: каскадная, когда каждая последующая стадия вытекала из предыдущей (рис. 1); итерационная, когда каждая последующая стадия не только вытекает из предыдущей, но и может корректироваться по результатам последующих стадий (рис. 2).

Рис. 1 - Каскадная модель разработки КИС

Рис. 2 - Итерационная модель разработки КИС

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

Исследование предметной области:

Спецификацию деятельности в предметной области,

Анализ деятельности в предметной области: структурно-логический анализ деятельности (анализ путей, анализ связности (прочности и сцепления) компонентов предметной области), анализ производительности, экономический анализ;

Разработка архитектуры системы:

Спецификации требований к проектируемой системе,

Конструирование концептуальной модели предметной области,

Спецификации обработки данных в проектируемой системе,

Спецификации пользовательского интерфейса системы,

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

Реализация проекта.

Внедрение системы.

Сопровождение системы [10].

1.2 Классификация и основные характеристики КИС

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

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

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

DFD (Data Flow Diagrams) - диаграммы потоков данных;

SADT (Structured Analysis and Design Technique - метод структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы;

ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

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

Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).

Диаграммы, моделирующие данные и их отношения (ERD).

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

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

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

2.1.2 Метод функционального моделирования SADT

Метод функционального моделирования SADT (Structured Analysis and Design Technique) разработан Дугласом Россом. На его основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

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

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

Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

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

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

2.1.3 Моделирование потоков данных (процессов)

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

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

внешние сущности;

системы/подсистемы;

процессы;

накопители данных;

потоки данных.

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

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

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

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

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

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

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

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

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

2.2 Объектно-ориентированный подход к проектированию КИС

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

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

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

Объекты и классы организуются с использованием следующих принципов:

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

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

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

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

2.2.2 Архитектура CORBA

CORBA (Common Object Request Broker Architecture) - это стандарт, набор спецификаций для промежуточного программного обеспечения (ППО,middleware) объектного типа. [017]

Задача ППО и заключается в связывании программных приложений для обмена данными. Эволюция ППО - это путь от программ передачи информации между конкретными приложениями, через средства импорта, экспорта данных и организацию мостов между некоторыми приложениями, через SQL, RPC (Remote Procedure Call), TP мониторы (Transaction Proceesing) обработки транзакций, Groupware - управление различными неструктурированными данными (тексты, факсы, письма электронной почты, календари и т.д.) и, наконец, MOM - Message-Oriented Middleware (асинхронный обмен сообщениями между сервером и клиентом), к созданию распределенных компьютерных систем. Элементы этих систем могут взаимодействовать друг с другом как на одной локальной машине, так и по сети. Уникальная полифоничность CORBA позволяет организовать единую ИС, элементы которой могут общаться друг с другом, вне зависимости от их конкретной реализации, «прописки» в распределенной системе, платформы и языка их реализации.

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

При определении конкретной архитектуры Брокер Объектных Запросов вовсе необязательно должен быть реализован как один компонент, но каждая реализация должна реализовывать три категории операций:

Операции, которые одинаковы для всех реализаций ORB-а.

Операции, специфичные для конкретного объектного типа.

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

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

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

Система объектов обеспечивает клиента набором сервисов. Клиент способен запросить некоторый сервис. Объект - это нечто, что обеспечивает один или более сервисов, которые клиент может запросить.

2.2.3 Технология OLE

Технология OLE (Object Linking and Embedding) - технология управления и обмена информацией между программным интерфейсом других приложений. Связывание и внедрение объектов (Object Linking and Embedding).

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

При использовании OLE в обмене информацией участвуют два приложения: приложение-сервер и приложение-клиент.

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

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

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

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

2.2.4 Основные средства языка UML

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

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

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

Подпакет - пакет, который является составной частью другого пакета.

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

Для графического изображения пакетов на диаграммах применяется специальный графический символ (рис. 3.).

Рис. 3 - Графическое изображение пакета: а) без содержимого, б) с содержимым

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

В нотации языка UML определены следующие виды канонических диаграмм:

вариантов использования (use case diagram)

классов (class diagram)

кооперации (collaboration diagram)

последовательности (sequence diagram)

состояний (statechart diagram)

деятельности (activity diagram)

компонентов (component diagram)

развертывания (deployment diagram)

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

В целом интегрированная модель сложной системы в нотации UML может быть представлена в виде совокупности указанных выше диаграмм (рис. 4.)

Рис. 4 - Интегрированная модель сложной системы в нотации UML

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

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

Геометрические фигуры на плоскости, играющие роль вершин графов соответствующих диаграмм.

Графические взаимосвязи, которые представляются различными линиями на плоскости.

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

2.3 CASE-средства

2.3.1 Особенности CASE-технологии

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

Традиционные языки программирования в силу малой наглядности, избыточности и многословия для этой роли не подходили, и, в конце концов, стали предприниматься попытки создания четкого графического языка. Реализации графических языков и методологии их использования способствовали появлению программно-технологических средств специального класса - CASE-средств. Аббревиатура расшифровывается как Computer-Aided Software Engineering, т.е. разработка ПО с помощью компьютера. [022]

Главные составляющие CASE-продукта таковы:

методология (Method Diagrams), которая задает единый графический язык и правила работы с ним.

графические редакторы (Graphic Editors), которые помогают рисовать диаграммы;

генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ

репозиторий, своеобразная база данных для хранения результатов работы программистов (сложилась парадоксальная ситуация: к тому моменту базами данных пользовались все, кроме программистов), происходит переход от "плоских" файлов к системе хранения информации о разработке проекта. [023]

2.3.2 Компоненты полного комплекса CASE-средств

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

средства разработки приложений, включая языки 4GL и генераторы кодов;

средства конфигурационного управления;

средства документирования;

средства тестирования;

средства управления проектом;

средства реинжиниринга. [029]

Основные характерные особенности:

мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

использование специальным образом организованного хранилища проектных метаданных (репозитория). [030]

2.3.3 Классификация CASE-средств

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам: