Программная инженерия (software engineering) - совокупность инженерных методов и средств создания ПО.

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

Этапы становления и развития программной инженерии:

· 70-е и 80-е годы - систематизация и стандартизация процессов создания ПО (на основе структурного подхода)

· 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода)

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

§ Системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения

§ Разработка ПО должна быть осуществлена в рамках выделенного бюджета

§ Системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющимся ПО

§ Системы должны быть легко сопровождаемыми и масштабируемыми

Мировая статистика разработки проектов ПО (по данным отчета Standish Group – CHAOS Report)

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

• Разработка ПО изначально является проектированием и не имеет признаков строительства или производства

• Разработчики не строят ПО – они его проектируют

• Конечный результат проектирования – код на языке высокого уровня – является чертежом ПО

Другие причины возможных неудач (по данным Standish Group и Rational Software)

· нечеткая и неполная формулировка требований к ПО, недостаточное управление требованиями

· частое изменение требований и спецификаций

· недостаточное вовлечение пользователей в работу над проектом

· отсутствие грамотного управления проектом

· недостаточная поддержка со стороны высшего руководства

· новизна используемой технологии для организации

· высокий риск, связанный с «каскадным» подходом

Одна из причин - экстремальные условия выполнения проектов:

§ план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом

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

§ бюджет и связанные с ним ресурсы урезаны наполовину

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

Причины, порождающие экстремальные проекты

§ Высокая конкуренция, порожденная глобализацией рынков

§ Высокая конкуренция, вызванная появлением новых технологий

§ Наивный оптимизм и менталитет первопроходцев

§ Сильное воздействие неожиданных правительственных решений

Причины участия в экстремальных проектах

2. Жизненный цикл ПО ЭИС. +в3 и в4

3. Процессы жизненного цикла в различных стандартах. +в2 и в4

4. Жизненный цикл. ГОСТ ИСО МЭК 12207. +в2 и в3

Жизненный цикл ПО (software lifecycle): период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации

Основной нормативный документ - стандарт ISO/IEC 12207: 1995 "Information Technology - Software Life Cycle Processes"

§ ГОСТ ЕСПД (ГОСТ 19.ХХХ) - ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. Стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно

§ ГОСТ 34.601-90, ГОСТ 34.602-89, ГОСТ 34.603-92 - малопригодны для современных распределенных систем, функционирующих в неоднородной среде, отдельные положения устарели

§ ГОСТ Р ИСО/МЭК 12207-99 (перевод ISO 12207) - введен в действие в июле 2000 г.

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

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

§ Каждый процесс разделен на набор действий, каждое действие - на набор задач

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

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

• анализ проблем и запросов на модификацию ПО

• проверка и приемка в процессе сопровождения

Процесс управления конфигурацией (configuration management process) – процесс применения административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО

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

Процесс управления конфигурацией включает:
- идентификацию конфигурации;
- контроль конфигурации;
- учет состояния конфигурации;
- оценку конфигурации;
- управление выпуском и поставку

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

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

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

Процесс совместной оценки (joint review process) - предназначен для оценки состояния работ по проекту и ПО, создаваемого при выполнении данных работ (действий), сосредоточен на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта

Процесс инфраструктуры (infrastructure process) - выбор и поддержка технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации и сопровождения ПО

Процесс усовершенствования (improvement process) - оценка, измерение, контроль и усовершенствование процессов ЖЦ ПО

5. Жизненный цикл. ГОСТ 34, Oracle, RUP

ГОСТ 34

Oracle

Rational

§ Формирование требований к АСАС

§ Разработка концепции АС

§ Техническое задание

§ Эскизный проект

§ Технический проект

§ Рабочая документация

§ Ввод в действие

§ Сопровождение АС

§ Стратегия (определение требований)

§ Анализ (формулирование детальныхтребований)

§ Проектирование (детальные спецификации)

§ Реализация (написание и тестирование приложений)

§ Внедрение

§ Эксплуатация

§ Начальная стадия (Inception)

§ Разработка (Elaboration)

§ Конструирование (Construction)

§ Ввод в действие (Transition)

6. Каскадная модель ЖЦ ПО (waterfall)

• Фиксация требований к системе до ее сдачи заказчику

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

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

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

• Выход из календарного графика, запаздывание с получением результатов

• Невозможность разбить систему на части (весь продукт разрабатывается за один раз)

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

7.Спиральная модель ЖЦ ПО

Идентификация и анализ риска на каждой итерации

¨ Назначение приоритетов пользовательским требованиям

¨ Разработка последовательности прототипов, начиная с требований наивысшего приоритета

¨ Использование каскадной модели для реализации окончательного прототипа

¨ Оценка результатов по завершении каждой итерации и планирование следующей итерации

¨ Завершение проекта при нецелесообразности его продолжения

ускорение разработки (раннее получение результата за счет прототипирования)

· постоянное участие заказчика в процессе разработки

· разбиение большого объема работы на небольшие части

· снижение риска (повышение вероятности предсказуемого поведения системы)

· сложность планирования (определения количества и длительности итераций, оценки затрат и рисков)

· сложность применения модели с точки зрения менеджеров и заказчиков

· напряженный режим работы для разработчиков

8. Подход RAD

В рамках спиральной модели ЖЦ широкое распространение получил один из подходов к разработке ПО, известный как методология быстрой разработки приложений RAD (Rapid Application Development). Эта методология включает в себя три составляющие: небольшая команда программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл ПО в соответствии с методологией RAD состоит из четырех фаз: анализа и планирования требований; проектирования; построения; внедрения.

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

На этапе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении АС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (60 - 90 дней). С использованием CASE-средств проект АС распределяется между различными командами (делится функциональная модель). Результатом данного этапа должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап нередко происходит неконтролируемое искажение данных. Применение единой среды хранения данных о проекте позволяет этого избежать. В отличие от обычных подходов, при которых используются специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасываются после устранения неясностей в проекте АС, в подходе RAD каждый прототип передается будущей системе. Таким образом, на следующую фазу передается более полная и полезная информация.

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

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

9. Модель и архитектура ЭИС.

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

Моделирование - процесс создания точного описания системы в виде совокупности моделей

М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А

Модели - средства для визуализации, описания, проектирования и документирования архитектуры системы

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

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

· совокупность структурных элементов системы и связей между ними;

· поведение элементов системы в процессе их взаимодействия;

· иерархия подсистем, объединяющих структурные элементы;

10. Языки моделирования.

Сегодня наиболее известными языками (нотациями) графического моделирования бизнес-процессов являются UML, ARIS, IDEF (IDEF0, IDEF3 в программной интерпретации BPwin).

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения подобных задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными;

IDEF0 — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна́я последовательность (WorkFlow).

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

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

IDEF3 широко применяется при разработке информационных систем. При этом используется AllFusion Process Modeler (ранее BPwin) - инструмент визуального моделирования бизнес-процессов

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

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

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре

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

· Анализ — определение того, что система будет делать,

· Проектирование — определение подсистем и их взаимодействие,

· Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое,

ARIS (сокр. от англ. Architecture of Integrated Information Systems) — методология и программный продукт компании IDS Scheer для моделирования бизнес-процессов компании.

Методология ARIS является достаточно рафинированной. Организация в ARIS рассматривается с четырёх точек зрения:

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

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

1. EPC (event-driven process chain) — метод описания процессов, нашедший применение в системе SAP R/3;

2. ERM (Entity Relationship Model) — модель сущность-связь для описания структуры данных;

3. UML (Unified Modeling Language) — объектно-ориентированный язык моделирования.

11. Диаграммы UML.

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

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

· Sequence diagram (диаграммы последовательностей действий);

1.1 Use case diagram (диаграммы прецедентов)

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

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

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

1.2 Deployment diagram (диаграммы топологии)

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

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

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

1.3 State Maсhine diagram (диаграммы состояний)

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

Statechart diagram (диаграмма состояний)

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

1.4 Activity diagram (диаграммы активности)

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

Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

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

1.5 Interaction diagram (диаграммы взаимодействия)

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

1.6 Sequence diagram (диаграммы последовательностей действий)

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

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

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

1.7 Collaboration diagram (диаграммы сотрудничества)

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

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

1.8 Class diagram (диаграммы классов)

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

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

Пример UML диаграммы классов в нотации Booch

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

Пример UML диаграммы классов в унифицированной нотации

которому в дальнейшем будет создан конкретный объект.

И конечно же, Rational Roseпозволяет создавать диаграмму классов в унифицированной нотации

1.9 Component diagram (диаграммы компонентов)

Этот тип диаграмм

http://www.caseclub.ru/articles/rose2.10.gif

предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

12. Диаграммы UML. Диаграммы вариантов использования.

На диаграммах вариантов использования (ВИ) изображаются актеры и варианты использования, между которыми существуют отношения. Здесь можно показывать и другие элементы UML (например, классы могут показывать, какие сущности порождаются или используются в конкретных ВИ - см. рис.1).

Актером будем называть внешнюю по отношению к ПС сущность, которая может взаимодействовать с системой. Актерами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актер - это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Например, в качестве актера <Бухгалтер> может выступать весь наличный штат бухгалтерии. В то же время один конкретный человек может играть несколько ролей по отношению к системе. Главный бухгалтер может выступать как актер с таким же именем, но может использовать систему так же, как актер <бухгалтер> (то есть, выполнять работу обычного бухгалтера). В то же время актеры - не обязательно люди. Если ПС должна выполнять какие-либо действия в определенные моменты времени, то в качестве актера, инициирующего выполнение этих действий, может быть указан системный таймер.

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

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

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

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

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

Ассоциация - единственно возможная связь между актером и ВИ. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. На рис.2а оператор инициирует начало выполнения ВИ открытия нового счета.

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

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

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

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

Актер <Оператор> активизирует выполнение ВИ <Открыть счет>. В соответствии с заданным оператором типом счета выполняется либо ВИ <Открыть счет физического лица> либо <Открыть счет юридического лица>, являющиеся расширениями первого. Открытие счета включает его контроль и при обнаружении ошибки - выдачу сообщения Оператору.

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

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

13. Диаграммы UML. Диаграммы взаимодействия.

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

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

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

Диаграммы последовательностей действий (Sequence diagram)

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

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

14. Технологии создания ПО.

Технология Rational Unified Process (IBM Rational Software)

Одна из наиболее совершенных технологий, претендующих на роль мирового корпоративного стандарта - Rational Unified Process (RUP)

1.Итерационный и инкрементный (наращиваемый) подход к созданию ПО.

2.Планирование и управление проектом на основе функциональных требований к системе - вариантов использования.

3.Построение системы на базе архитектуры ПО.

Технология Oracle

Методическую основу ТС ПО корпорации Oracle (www.oracle.com) составляет метод Oracle (Oracle Method) - комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

· CDM (Custom Development Method) - разработка прикладного ПО;

· AIM (Application Implementation Method) - внедрение прикладного ПО;

· BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;

· OCM (Organizational Change Management) - управление изменениями, и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage - библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method, известного по использованию CASE-средств фирмы Oracle и книгам Р. Баркера. По существу, CDM является методическим руководством по разработке прикладного ПО с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM ЖЦ ПО формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов (Рис. 2):

· анализ (формулирование детальных требований к системе);

· проектирование (преобразование требований в детальные спецификации системы);

· реализация (написание и тестирование приложений);

· внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

Технология Borland

Компания Borland (www.borland.com) в результате развития собственных разработок и приобретения целого ряда компаний представила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle Management, ALM). В соответствии с технологией Borland процесс создания ПО включает в себя пять основных этапов:

Выполнение всех этапов координируется процессом управления конфигурацией и изменениями.

Технология Computer Associates

Компания Computer Associates (www.ca.com) предлагает комплексы инструментальных средств поддержки различных процессов ЖЦ ПО:

· AllFusion Modeling Suite - интегрированный комплекс CASE-средств [16], включающий следующие продукты:

o AllFusion Process Modeler (BPwin) - функциональное моделирование;

o AllFusion ERwin Data Modeler (ERwin) - моделирование данных;

o AllFusion Component Modeler (Paradigm Plus) - объектно-ориентированный анализ и проектирование с использованием UML и возможностью генерации кода;

o AllFusion Model Manager (Model Mart) - организация совместной работы команды разработчиков;

o AllFusion Data Model Validator (ERwin Examiner) - проверка структуры и качества моделей данных.

AllFusion Change Management Suite - комплекс средств управления конфигурацией и изменениями.

· AllFusion Process Management Suite - средства управления процессами и проектами для различных типов приложений.

CASE-средства ERwin и BPwin были разработаны фирмой Logic Works, которая в 1998 году вошла в состав PLATINUM Technology, а затем Computer Associates.

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

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. ERwin выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений.

15. Технология RUP.

RUP – Rational Unified Process (Уникальный процесс разработки ПО).

2. 2. База знаний по программной инженерии в различных отраслях производства.

3. 3. Обеспечение структурного подхода к назначению задач и обязанностей в организации, занимающейся разработкой ПО.

Цикл разработки – период времени от начала продукта до выпуска продукта или отказа от выпуска (цикл первоначальной разработки), до выпуска новой версии (цикл развития), до исправления ошибки (цикл поддержки).

Жизненный цикл продукта – время от начала проекта до завершения проекта.

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

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

Итерация – четкая последовательность задач с планом и критерием оценки, приводящая к выпуску релиза.

Дисциплина – логическая группа из ролей, задач артефактов и других средств управления процессом.

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

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

Задача – единица работы в RUP, которая может быть предложена роли для выполнения.

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

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

Цикл – полное прохождение всех 4-х фаз, приводящее к выпуску продукта.

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

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

2. Четко определенная и структурированная технология программной инженерии.

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

В RUP используется итеративный архитектурно-центричный и основанный на прецедентах использования подход к разработки ПО.

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

6 – Среда управления конфигурациями и изменениями.

1. Разработка приспособлена к меняющимся требованиям.

4. Облегчается повторное использование кода.

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

Архитектура – набор существенных решений касающихся организации программных решений таких как:

2. Поведение (функциональный элемент), определяемое взаимодействием этих элементов.

3. Объединение элементов в более крупные подсистемы.

Архитектурный стиль конкретной организации.

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

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

16. Стадии ЖЦ по технологии RUP.

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие основные принципы:

· Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

· Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).

· Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

· Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

· Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

· Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

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

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

Графическое представление процесса разработки по RUP

· Создается экономическое обоснование (business case).

· Определяются основные требования, ограничения и ключевая функциональность продукта.

· Создается базовая версия модели прецедентов.

При завершении начальной стадии оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

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

· Документирование требований (включая детальное описание для большинства прецедентов).

· Спроектированную, реализованную и оттестированную исполняемую архитектуру.

· Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).

Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

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

17. Средства моделирование бизнес процессов.

Business Studio — система бизнес-моделирования, позволяющая компаниям ускорить и упростить развитие своей системы управления, внедрение системы менеджмента качества.

· Формализация стратегии и контроль ее достижения

· Проектирование и оптимизация бизнес-процессов

· Проектирование организационной структуры и штатного расписания

· Формирование и распространение среди сотрудников регламентирующей документации

· Формирование Технических заданий и поддержка внедрения информационных систем

Процесс проектирования и совершенствования системы управления можно представить в виде следующей последовательности этапов:

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

· Простота, удобство и высокая скорость освоения специалистами.

· Использование самых популярных нотаций моделирования бизнес-процессов, понятных исполнителям без дополнительной подготовки: IDEF0, Процесс (Basic Flowchart), Процедура (Cross Functional Flowchart), EPC.

· Интегрированность : в одном инструменте собраны все востребованные бизнесом методики и технологии: BSC/KPI, моделирование бизнес-процессов, имитационное моделирование, функционально-стоимостной анализ, поддержка СМК.

· Формирование на выходе конкретизированных регламентирующих документов, не требующих дополнительной доработки. Поддержка двух форматов: документы Microsoft Word или HTML-навигатор.

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

· Обеспечение совместной работы над одной бизнес-моделью команды специалистов в рамках одной сети или в режиме off-line.

· Использование в качестве графического редактора диаграмм Microsoft Visio, ставшего стандартом в области деловой графики.

Fox Manager, предназначенной для оптимизации управления и внедрения процессного подхода на предприятии.
Программы серии Fox Manager позволяют:

· описать и управлять бизнес-процессами предприятия;

· построить и оптимизировать организационную структуру;

· генерировать должностные инструкции и регламентирующую документацию;

· контролировать производственный процесс в любой точке;

· управлять любыми видами рисков на предприятии;

· осуществлять внутренний контроль результативности бизнес-процессов;

· поддерживать систему документации в актуализированном состоянии;

· поддерживать системы менеджмента качества и безопасности ISO и HACCP;

Менее чем за год с момента завершения разработки программы Fox Manager, нашими клиентами стало более 50 предприятий различного профиля и вида деятельности на территории Украины, России и стран Балтии и СНГ.

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

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

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

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

Программные продукты серии Fox Manager успешно прошли тест на совместимость в операционной системой Windows 7 при помощи программы Windows 7 Client Software Logo Toolkit в нашей лаборатории.
Fox Manager ФМ официально поддерживает новую операционную систему начиная с версии 1.2.

Microsoft Visio — редактор диаграмм и блок-схем для Windows. Использует векторную графику для создания диаграмм.

Выпускается в двух редакциях: Standard и Professional.

Первоначально Visio разрабатывался и выпускался компанией Visio Corporation. Microsoft приобрела компанию в 2000 году, когда продукт назывался Visio 2000, был выполнен ребрендинг и продукт был включен в состав Microsoft Office.

18. Методология SADT

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

· графическое представление блочного моделирования. строгость и точность. Правила SADT включают:

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

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

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

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

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

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

19. Методология IDEF0

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна́я последовательность (WorkFlow).Так же отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель является одной из самых прогрессивных моделей и используется при организации бизнес проектов и проектов, основанных на моделировании всех процессов как административных, так и организационных.

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвященная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик-специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST).

Программные продукты, реализующие эту методологию

20. Методология IDEF3

IDEF3 широко применяется при разработке информационных систем. При этом используется AllFusion Process Modeller (ранее BPwin) - инструмент визуального моделирования бизнес-процессов

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

IDEF3 состоит из двух методов. Process Flow Description (PFD) - Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса. Object State Transition Description (OSTD) - Описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов. Модель в нотации IDEF3 может содержать два типа диаграмм:

· диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD)

· диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN)

Диаграмма IDEF3 Process Flow Description может состоять из 5 основных описательных блоков:

21. Методология ARIS

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

§ EPC (event-driven process chain) - метод описания процессов, нашедший применение для описания процессов системы SAP R/3;

§ ERM (Entity Relationship Model) – модель сущностей-связей для описания структуры данных;

§ UML (Unified Modeling Language) – объектно-ориентированный язык моделирования.

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

В инструментальной среде ARIS существует возможность настройки методологии в зависимости от целей проекта и профессиональных знаний пользователей.

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

Семейство продуктов ARIS состоит из двух основных продуктов, ARIS Easy Design и ARIS Toolset, и множества дополнительных функциональных модулей.

ARIS Toolset (ARIS Easy Design) – единая среда моделирования, которая представляет собой совокупность четырех основных компонентов – Explorer (Проводник), Designer (средство для графического описания моделей), Таблиц (для ввода различных параметров и атрибутов) и Мастеров (Wizards). Различия двух продуктов заключается не в методологической части (ARIS Easy Design входит в ARIS Toolset), а лишь в функционале. ARIS Easy Design ориентирован на сбор информации и документирование, когда ARIS Toolset позволяет еще и проводить комплексный анализ, семантические проверки информации. Кроме того, только ARIS Toolset позволяет создавать скрипты (шаблоны) для отчетов, анализа и семантических проверок. ARIS Toolset – это средство для полноправного управления проектом ARIS. Функции управления заключаются в возможностях разграничения доступа для различных групп пользователей, а также ограничения методологи. Это необходимо, что бы избавится от избыточности методологии при реализации конкретного проекта. Помимо этого, некоторые модули, в частности ARIS ABC и ARIS Simulation, функционируют только при наличии ARIS Toolset.

Дополнительные функциональные модули включают в себя средства:

§ ARIS for R/3, ARIS Web Connectivity for R/3, ARIS Connectivity for SAP R/3 HR для интеграции с SAP R/3 и, в частности, с модулем HR;

§ ARIS ABC для операционного стоимостного анализа (activity based costing)

§ ARIS Simulation для динамического (имитационного) моделирования на базе известного пакета Simple++ (лицензия Simple++ Runtime включена в пакет);

§ ARIS Web Publisher для публикации созданных моделей в Internet/Intranet и обмена ими через Web с использованием технологий ActiveX и Java;

§ ARIS Repository API для разработки интерфейсов с внешними независимыми приложениями.

§ ARIS Server для возможности работы в многопользовательском режиме.

§ ARIS Server устанавливается как отдельное приложение.

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

Дополнительные функциональные модули, кроме ARIS Server, могут работать только при условии наличия ARIS Toolset.

Преимуществом ARIS перед другими средствами описания бизнес-процессов является отсутствие необходимости взаимодействия функциональных модулей (ABC, динамическое моделирование, настройка и генерация отчетов) через какие-либо программные интерфейсы. Таким образом, все данные, используемые основными продуктами и дополнительными функциональными модулями, хранятся в едином репозитории и не требуют проведения операций по экспорту/импорту. С точки зрения пользователя, работа с ARIS Easy Design и работа с ARIS Toolset и дополнительными функциональными модулями в плане использования методологии ничем не отличается, но различается функционалом по обработке данных. С точки зрения пользовательского интерфейса, различия проявляются только в дополнительных опциях меню и таблицах, позволяющих упростить навигацию по данным.

Работа в многопользовательской среде проходит при наличии установленного приложения ARIS Server.

Таким образом, методология ARIS едина для любого функционального модуля и может быть ограничена (при помощи ARIS Toolset) с учетом целей проекта и нужд пользователей. Функционал системы ограничивается с помощью аппаратного лицензионного ключа для LPT-порта, в котором прописывается набор функциональных возможностей конкретного пользователя. Добавление функциональных возможностей производится путем замены существующего ключа или добавления дополнительного. Аппаратный ключ входит в поставку.

В настоящее время имеются интерфейсы для ARIS к CASE-средствам, системам WorkFlow, системам GroupWare, разработанные сторонними компаниями. Эти интерфейсы представляют собой приложения, которые через промежуточный файл трансформируют данные в формате ARIS в данные в формате конечного средства и наоборот. Ниже приведен список программных продуктов, к которым разработан интерфейс с ARIS, а также компании-разработчики интерфейсов.

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

· Формирование общего видения компании (глобальный уровень)

· Формирование детального описание процессов компании (вплоть до процессов рабочих мест)

· Формирование организационной и функциональной структуры, структур данных

· Описание требований к информационным системам поддержки деятельности

· Проектирование интегрированных информационных систем

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

· Проведение анализа разработанных моделей (количественный и сравнительный, анализ, анализ семантики, анализ стоимостных и временных характеристик)

· Разработка информационных систем (формирование баз данных, генерация программных кодов)

· Интеграция моделей с функционирующими информационными системами (актуализация организационной структуры, номенклатуры, показателей)

· Пункты 1 – 7 представленного перечня обеспечиваются системой на уровне методологии, которая едина для любого модуля ARIS.

Пункт 8 поддержан встроенными в ARIS Toolset генератором отчетов. При этом можно как проводить документирование по предсозданным разработчиком структурам, так и создавать собственные структуры отчетов, в том числе и в соответствии со стандартами ISO 9000.

Пункт 9 обеспечен встроенными в ARIS Toolset средствами анализа моделей (Analysis), проверки семантики моделей (Semantic Checks), а также дополнительными модулями ARIS ABC и ARIS Simulation.

Пункт 10 осуществляется за счет существующих интерфейсов в средства разработки информационных систем (CASE-средства, системы класса Workflow, ERP-системы).

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

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

22. DFD, основные элементы

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

Основными элементами диаграмм потоков данных являются:

Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации. В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие. К сожалению, DFD методология не оформлена как стандарт. По этой причине в диаграммах потоков данных используются различные условные обозначения. На рисунке 1 показаны символы внешних сущностей, используемые в нотациях «Yourdon and Coad Process Notation» и «Gane and Sarson Process Notation».

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

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

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

Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить) и поясняющими существительными, например: «Напечатать адрес получателя», «Акцептовать счет».

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

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

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

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

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

23. Моделирование ERD

Одной из основных частей информационного обеспечения является информационная база. Информационная база (ИБ) представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Разработка БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

· иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;

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

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

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

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

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

24. Моделирование сущность-связь, основные элементы

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

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

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

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

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

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом [37]. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

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

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

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

Каждая сущность в модели изображается в виде прямоугольника с наименованием:

Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".

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

Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

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

Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

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

Сущность может иметь несколько различных ключей.

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

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

Связи позволяют по одной сущности находить другие сущности, связанные с нею.

Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

Графически связь изображается линией, соединяющей две сущности:

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

Каждая связь может иметь один из следующих типов связи:

Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на Рис. 4.

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

Каждая связь может иметь одну из двух модальностей связи:

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

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

Связь может иметь разную модальность с разных концов (как на Рис. 4).

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на Рис. 4 читается так:

Слева направо: "каждый сотрудник может иметь несколько детей".

Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

25. Связи, обобщения, включения, расширения RUP

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

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

Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"), как показано на рис. 4.7.

Рис. 4.7. Пример графического изображения отношения расширения между вариантами использования

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

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

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

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

Рис. 4.8. Графическое изображение отношения расширения с примечаниями условий выполнения вариантов использования

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

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

Рис. 4.9. Пример графического изображения отношения обобщения между вариантами использования

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

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

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

Рис. 4.10. Пример графического изображения отношения обобщения между актерами

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

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

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

Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на рис. 4.11.

Рис. 4.11. Пример графического изображения отношения включения между вариантами использования

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

26. Объектно-ориентированный подход в проектировании ЭИС.

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

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

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

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

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

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

СУЩНОСТЬ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. Основные принципы ООП

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

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

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

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

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

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

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

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

28. Основные понятия ООП

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

Класс - это абстрактное понятие, сравнимое с понятием категория в его обычном смысле.

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

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

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

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

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

Существует 2 способа включения метода в класс:

2.Объявление метода при описании, а его описание - при вызове.

Методы, определенные внутри класса, являются неявно встроенными.

class A
    {
    int x, y;
    int sum ( ) { return (x + y) ; }
    } ;

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

Class B
    {
    int x, y;
   int sum ( )
    } ;
int B::sum ( ) { return (x + y) ; }

Также как и структуры, классы можно задавать либо статически, либо динамически.
Например,
    статически - Toplist    foo;
    динамически - Toplist *bar ; bar=new Toplist;

Для статических и динамических классов применимы те же правила и принципы, что и для статических и динамических переменных.

Классы содержат данные и методы. В ООП методы и данные одного класса могут передаваться другим классам, т.е. объекты могут наследовать свойства друг друга. Класс наследует свойства другого класса, обладает теми же возможностями, что и класс, от которого он порожден. Этот принцип называется наследованием (inheritance). Порожденный класс называется потомком (descendant), а тот, от кого он порожден - предком (ancestor). Благодаря новым свойствам, которыми дополняется потомок, порожденный класс может обладать большими возможностями, чем его предок.Механизм наследования обеспечивает возможность многократного применения программного кода. Таким образом, классы могут быть представлены в виде иерархии. Библиотека VLC (Visual Component Library) в Delphi как раз и является такой иерархической системой классов.

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

Инкапсуляция (encapsulation) - объединение данных с функциями, предназначенными для манипулирования этими данными (т.е. поведением) в новом типе - КЛАССЕ .

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

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

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

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

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

Например, метод класса Музыкальных инструментов - PlayMusicForAnOrchestra - может быть определен как общим метод, который может использоваться с любой категорией инструментов. Этот метод написан таким образом, что не важно, какой именно инструмент получает задание играть, однако для классов, описывающих конкретные инструменты, данный метод должен быть переопределен (override), что даст возможность определить конкретные действия, учитывая особенности конкретного инструмента.

БАЗЫ ДАННЫХ (БД)

1.Информация и данные. Понятие банка данных, базы данных.

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

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

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

1. Объективность. Более эффективной принято считать ту информацию, в которую методы вносят наименьший субъективный элемент.

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

3. Достоверность. Степень соответствия информации реальному положению дел.

4. Адекватность. Определяется степенью содержания в ней полезной составляющей.

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

6. Актуальность. Степень соответствия информации текущему моменту времени.

1. Сбор – накопление информации с целью обеспечения достаточной полноты для принятия решений.

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

3. Фильтрация – процесс отсеивания лишних данных, в которых нет необходимости для принятия решения.

4. Сортировка данных – упорядочивание данных по заданному признаку с целью удобства их использования (в данном случае повышается доступность информации).

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

6. Защита данных – комплекс мероприятий, направленных на предотвращение утраты, несанкционированного воспроизведения или модификации.

7. Транспортировка – процесс приема, передачи данных между удаленными участками информационного процесса.

8. Преобразование – перевод данных из одной исходной формы в другую или из одной структуры в другую.

9. Обработка данных – упорядоченный процесс их преобразования в соответствии с алгоритмом задачи.

Информационная система – ресурсы, которые позволяют выполнять сбор, корректировку и распространение информации.

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

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

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

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

1. Аппаратное обеспечение. Для работы СУБД и приложений необходимо некоторое аппаратное обеспечение. Оно может варьироваться в очень широких пределах – от единственного ПК до сети из многих компьютеров.

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

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

5. Пользователи. Это специалисты, которые обеспечивают создание, работу и развитие базы данных.

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

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

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

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

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

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

2. OLAP и OLTP-системы.

В наше время без систем управления базами данных не обходится практически ни одна организация, особенно среди тех, которые традиционно ориентированы на взаимодействие с клиентами. Такие базы данных называют операционными или транзакционными, поскольку они характеризуются огромным количеством небольших транзакций, или операций записи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступ к базам транзакций, принято называть системами оперативной обработки транзакций (OLTP - On-Line Transactional Processing) или учетными системами.

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

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

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP- приложений (On-Line Transaction Processing - оперативная обработка транзакций). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег, и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, «снять сумму денег со счета А, добавить эту сумму на счет В». Время ожидания типичных запросов в таких системах не должна превышать нескольких секунд. Проблемы OLTP-систем заключается в том, что: 1) транзакций очень много; 2) выполняются они одновременно (к системе может быть подключено несколько тысяч одновременно работающих пользователей); 3) при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В). Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Пример запроса: «есть ли свободные места в купе поезда Москва-Сочи, отправляющегося 20 августа в 23:15». Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP- приложении, тем оно, как правило, быстрее и надежнее. OLTP-системы требуют защиты от несанкционированного доступа, от нарушения целостности, аппаратных и программных сбоев.

Другим типом приложений являются OLAP-приложения (On-Line Analitical Processing - оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (СППР) (Decision Support System - DSS), хранилищ данных (Data Warehouse), систем интеллектуального анализа данных (Data Mining). Такие системы предназначены для нахождения зависимостей между различными данными. Приведем примеры запросов: «как связан объем продаж товаров с характеристиками потенциальных покупателей»; «каким будет объем продаж железнодорожных билетов в следующие 3 месяца с учетом сезонных колебаний»), для проведения анализа "что если…". OLAP- приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми из электронных таблиц или из других источников данных. Такие системы характеризуются следующими признаками: · Добавление в систему новых данных происходит относительно редко крупными блоками (например, раз в квартал загружаются данные по итогам квартальных продаж из OLTP- приложения). · Данные, добавленные в систему, обычно никогда не удаляются. 82

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

Основываясь на этих данных, можно отвечать на вопросы вроде "у какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?" Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP) или построен средствами реляционной модели данных (ROLAP - Relational OLAP). Оперативность обработки больших обьемов данных в системах OLAP достигается за счет применения мощной многопроцессорной ВТ, сложных методов анализа и специальных хранилищ данных, накапливающих информацию из разных источников за большой период времени и обеспечивающих быстрый доступ к ней (Data Warehouse ). В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому приходится применять специализированные языки, ориентированные на аналитическую обработку данных. К их числу можно отнести, например, язык Express 4GL (язык четвертого поколения - 4 Generation Language ) фирмы.Oracle.

Необходимость использования OLAP в учетных системах

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

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

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

Этим объясняется интерес к объединению и анализу данных учетной системы с помощью технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка). Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации. Исходные данные преобразуются таким образом, чтобы наглядно отразить структуру деятельности предприятия.

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

· расчеты и вычисления по нескольким измерениям, иерархиям и/или членам;

· выборка подмножеств данных для просмотра на экране;

· углубление в данные (drill down), для просмотра информации на более детализированном уровне;

· переход к детальным данным, лежащим в основе анализа.

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

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

Системная характеристика	Учетная система (OLTP)	OLAP
Взаимодействие с пользователем	На уровне транзакции	На уровне всей базы данных
Данные, используемые при обращении пользователя к системе	Отдельные записи	Группы записей
Время отклика	Секунды	От нескольких секунд до нескольких минут
Использование аппаратных ресурсов	Стабильное	Динамическое
Характер данных	Главным образом первичные (самый низкий уровень детализации)	В основном производные (сводные значения)
Характер доступа к базе данных	Предопределенные или статические пути доступа и отношения данных	Неопределенные или динамические пути доступа и отношения данных
Изменчивость данных	Высокая (данные обновляются с каждой транзакцией)	Низкая (во время запроса данные обновляются редко)
Приоритеты	Высокая производительность Высокая доступность	Гибкость Автономность пользователя

Совместное использование OLAP и учетной системы, в частности прямая настройка аналитических функций на OLTP-базу, осложняется несколькими факторами:

· OLAP запросы к базам данных чаще всего бывают сложными и требуют много времени. Прямой доступ к OLTP-базе существенно снижает общую производительность оперативной системы.

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

· Данные в учетных системах часто "зашумленные", неполные и несогласованные.

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

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

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

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

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

Процесс интегрирования OLAP-технологии с учетными системами может осуществляться по-разному. Все подходы имеют свои преимущества и недостатки. Как уже было сказано выше, прямая настройка аналитических средств (Direct BI) затруднена. Возможно также создание дублированных баз данных, витрин и Хранилищ данных. Практически всегда возникает необходимость в преобразовании операционных данных в аналитические. Для создания многомерного представления, нужно настроить данные так, чтобы они соответствовали логической многомерной структуре, далекой от структуры учетной системы. Например, многие измерения, используемые для анализа, могут вообще не иметь соответствий в учетных системах и извлекаться из других источников.

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

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

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

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

3.Роль баз данных в структуре ИС.

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

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

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

Исторически первыми появились распределенные ИС с применением файл-сервера. В таких ИС компьютер по запросам пользователей файлы базы данных передаются на персональные компьютеры (ПК), где и производится их обработка. Недостатком такого варианта архитектуры является высокая интенсивность передачи обрабатываемых данных. Причем зачастую передаются избыточные данные: вне зависимости от того сколько файлов из базы данных требуется пользователю, файлы базы данных передаются целиком. (комп-сервер: кбд и файл-сервер -> сетевое по -> ПК клиента: пбд и СУБД; передача файлов из БД для обработки)

Также существует структура распределенной ИС, построенной по архитектуре клиент-сервер с использованием сервера баз данных. При такой архитектуре сервер базы данных обеспечивает выполнение основного объема обработки данных. Формируемые пользователем или приложением запросы поступают к серверу БД в виде инструкций языка SQL. Сервер базы данных выполняет поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении с предыдущим является заметно меньший объем передаваемых данных. (комп-сервер: кбд и сервер БД -> сетевое по -> ПК клиента: пбд и СУБД; передача данных из БД).

Наиболее популярные СУБД, использующиеся для создания и управления персональными БД и приложениями: Access и Visual FoxPro фирмы Microsoft, Paradox фирмы Borland.

Корпоративная БД создается, поддерживается и функционирует под управлением сервера БД, например Microsoft SQL Server или Oracle Server.

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

· несколько компьютеров-серверов и персональных компьютеров с ПБД.

Использование архитектуры клиент-сервер дает возможность постепенного наращивания ИС предприятия, во-первых, по мере развития предприятия; во-вторых, по мере развития самой ИС.

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

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

4.Классификация СУБД и их основные функции.

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

Полнофункциональные СУБД представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям (Clarion, Access, Paradox, etc). Обычно они имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т.п. Для создания запросов и отчетов используется язык QBE (Query By Example), многие ПФСУБД включают средства программирования для профессиональных разработчиков.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Эта группа БД в настоящее время менее многочисленна, но их количество постепенно растет. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами (MS SQL Server, InterBase, Net Ware SQL).

В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т.д. При этом элементы пары «клиент-сервер» могут принадлежать одному или разным производителям ПО.

Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:

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

К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (Delphi, Power Builder, Visual Basic).

По характеру использования СУБД делят на персональные и многопользовательские.

Персональные СУБД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД могут выступать в роли клиентской части многопользовательских СУБД (Paradox, Access).

Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и ОС). Oracle, Informix.

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

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

· обеспечение целостности и безопасности БД.

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

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

Механизм транзакций используется в СУБД для поддержания целостности данных в базе. Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения.

· атомарность ( выполняются все входящие в транзакцию операции или ни одна);

· сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);

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

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

Ведение журнала изменений в БД выполняется в СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных сбоев и отказов, а также ошибок в ПО.

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

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

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

База данных — это поименованная совокупность взаимосвязанных данных, находящихся под управлением СУБД.

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

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

полнофункциональные СУБД;

серверы БД;

клиенты БД;

средства разработки программ работы с БД.
Полнофункциональные СУБД (ПФСУБД) представляют собой традиционные СУБД, которые сначала появились для больших машин, затем для мини-машин и для ПЭВМ. Из числа всех СУБД современные ПФСУБД являются наиболее многочисленными и мощными по своим возможностям. К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R: BASE.
Обычно ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example - формулировки запросов по образцу, см. подраздел 3.8). Многие ПФСУБД включают средства программирования для профессиональных разработчиков.
Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.
Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Эта группа БД в настоящее время менее многочисленна, но их количество постепенно растет. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL.
Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).
В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары "клиент - сервер" могут принадлежать одному или разным производителям программного обеспечения.
В случае, когда клиентская и серверная части выполнены одной фирмой, естественно ожидать, что распределение функций между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным "любой ценой". Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) - роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Biyth Software, Paradox, DataEase, Focus, 1-2-3, MDBS III, Revelation и другие.
Средства разработки программ работы с БД могут использоваться для создания разновидностей следующих программ:

клиентских программ;

серверов БД и их отдельных компонентов;

пользовательских приложений.
Программы первого и второго вида довольно малочисленны, так как предназначены, главным образом, для системных программистов. Пакетов третьего вида гораздо больше, но меньше, чем полнофункциональных СУБД.
К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки программ для различных языков программирования, а также пакеты автоматизации разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi и Power Builder (Borland), Visual Basic (Microsoft), SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft) и ERwin (LogicWorks).
Кроме перечисленных средств, для управления данными и организации обслуживания БД используются различные дополнительные средства, к примеру, мониторы транзакций (см. подраздел 4.2).
По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУ БД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др.
Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.
По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
С точки зрения пользователя, СУБД реализует функции хранения, изменения (пополнения, редактирования и удаления) и обработки информации, а также разработки и получения различных выходных документов.

5.Критерии выбора СУБД при создании информационных систем

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

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

· Особенности архитектуры и функциональные возможности

Рассмотрим каждую из этих групп в отдельности.

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

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

· Средства поиска. Некоторые современные системы имеют встроенные дополнительные средства контекстного поиска.

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

· Реализация языка запросов. Все современные системы совместимы со стандартным языком доступа к данным SQL-92, однако многие из них реализуют те или иные расширения данного стандарта.

Особенности архитектуры и функциональные возможности.

· Мобильность. Мобильность – это независимость системы от среды, в которой она работает. Средой в данном случае является как аппаратура, так и программное обеспечение (операционная система).

· Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли данная система соответствовать росту информационной системы, причем рост может проявляться в увеличении числа пользователей, объема хранимых данных и объеме обрабатываемой информации.

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

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

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

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

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

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

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

· Возможности разработки Web-приложений. При разработке различных приложений зачастую возникает необходимость использовать возможности среды Internet. Средства разработки некоторых производителей имеют большой набор инструментов для построения приложений под Web.

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

· Рейтинг TPC (Transactions per Cent). Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является TPC-анализ производительности систем. Фактически TPC анализ рассматривает композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель TPC – это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы.

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

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

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

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

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

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

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

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

· Операционные системы, под управлением которых способна работать СУБД.

· Качество и полнота документации. К сожалению, не все системы имеют полную и подробную документацию.

· Локализованность. Возможность использования национальных языков не во всех системах реализована полностью.

· Модель формирования стоимости. Как правило, производители СУБД используют определенные модели формирования стоимости. Например, стоимость одного и того же продукта может существенно изменяться в зависимости от того, сколько пользователей будет с ним работать.

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

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

ручное кодирование программ (Clipper, FoxPro, Paradox);

создание текстов приложений с помощью генераторов (FoxApp в FoxPro, Personal Programmer в Paradox);

автоматическая генерация готового приложения методами визуального программирования (Delphi, Access, Paradox tor Windows).
При ручном кодировании программисты вручную набирают текст программ приложений, после чего выполняют их отладку.
Использование генераторов упрощает разработку приложений, поскольку при этом можно получать программный код без ручного набора. Генераторы приложений облегчают разработку основных элементов приложений (меню, экранных форм, запросов и т. д.), но зачастую не могут полностью исключить ручное кодирование.
Средства визуального программирования приложений являются дальнейшим развитием идеи использования генераторов приложений. Приложение при этом строится из готовых "строительных блоков" с помощью удобной интегрированной среды. При необходимости разработчик легко может вставить в приложение свой код. Интегрированная среда, как правило, предоставляет мощные средства создания, отладки и модификации приложений. Использование средств визуального программирования позволяет в кратчайшие сроки создавать более надежные, привлекательные и эффективные приложения по сравнению с приложениями, полученными первыми двумя способами.
Разработанное приложение обычно состоит из одного или нескольких файлов операционной системы.
Если основным файлом приложения является исполняемый файл (например, ехе-файл), то это приложение, скорее всего, является независимым приложением, которое выполняется автономно от среды СУБД. Получение независимого приложения на практике осуществляется путем компиляции исходных текстов программ, полученных различными способами: путем набора текста вручную, а также полученных с помощью генератора приложения или среды визуального программирования.
Независимые приложения позволяют получать, например, СУБД FoxPro и система визуального программирования Delphi. Отметим, что с помощью средств Delphi обычно независимые приложения не разрабатывают, так как это достаточно трудоемкий процесс, а привлекают процессор баз данных BDE (Borland DataBase Engine), играющий роль ядра СУБД. Одним из первых средств разработки приложений для персональных ЭВМ является система Clipper, представляющая собой "чистый компилятор".
Во многих случаях приложение не может исполняться без среды СУБД. Выполнение приложения состоит в том, что СУБД анализирует содержимое файлов приложения (в частном случае - это текст исходной программы) и автоматически строит необходимые исполняемые машинные команды. Другими словами, приложение выполняется методом интерпретации.
Режим интерпретации реализован во многих современных СУБД, например, Access, Visual FoxPro и Paradox, а также в СУБД недавнего прошлого, к примеру, FoxBase и FoxPro.
Кроме этого, существуют системы, использующие промежуточный вариант между компиляцией и интерпретацией - так называемую псевдокомпиляцию. В таких системах исходная программа путем компиляции преобразуется в промежуточный код (псевдокод) и записывается на диск. В этом виде ее в некоторых системах разрешается даже редактировать, но главная цель псевдокомпиляции - преобразовать программу к виду, ускоряющему процесс ее интерпретации. Такой прием широко применялся в СУБД, работающих под управлением DOS, например, Foxbase+ и Paradox 4.0/4.5 for DOS.
В СУБД, работающих под управлением Windows, псевдокод чаще используют для того, чтобы запретить модифицировать приложение. Это полезно для защиты от случайной или преднамеренной порчи работающей программы. Например, такой прием применен в СУБД Paradox for Windows, где допускается разработанные экранные формы и отчеты преобразовывать в соответствующие объекты, не поддающиеся редактированию.
Некоторые СУБД предоставляют пользователю возможность выбора варианта разработки приложения: как интерпретируемого СУБД программного кода или как независимой программы.
Достоинством применения независимых приложений является то, что время выполнения машинной программы обычно меньше, чем при интерпретации. Такие приложения целесообразно использовать на слабых машинах и в случае установки систем "под ключ", когда необходимо закрыть приложение от доработок со стороны пользователей.
Важным достоинством применения интерпретируемых приложений является легкость их модификации. Если готовая программа подвергается частым изменениям, то для их внесения нужна инструментальная система, т. е. СУБД или аналогичная среда. Для интерпретируемых приложений такой инструмент всегда под рукой, что очень удобно.
Другим серьезным достоинством систем с интерпретацией является то, что хорошие СУБД обычно имеют мощные средства контроля целостности данных и защиты от несанкционированного доступа, чего не скажешь о системах компилирующего типа. В последних упомянутые функции приходится программировать вручную, либо оставлять на совести администраторов.
При выборе средств для разработки приложения следует учитывать три основных фактора: ресурсы компьютера, особенности приложения (потребность в модификации функций программы, время на разработку, необходимость контроля доступа и поддержание целостности информации) и цель разработки (отчуждаемый программный продукт или система автоматизации своей повседневной деятельности).
Для пользователя, имеющего современный компьютер и планирующего создать несложное приложение, по всей видимости, больше подойдет СУБД интерпретирующего типа. Напомним, что такие системы достаточно мощны, имеют высокоуровневые средства, удобны для разработки и отладки, позволяют быстро выполнить разработку и обеспечивают удобное сопровождение и модификацию приложения.
При использовании компьютера со слабыми характеристиками лучше остановить свой выбор на системе со средствами разработки независимых приложений. При этом следует иметь ввиду, что малейшее изменение в приложении влечет за собой циклическое повторение этапов программирования, компиляции и отладки программы. Разница в выполнении независимого приложения и выполнения приложения в режиме интерпретации колеблется в пределах миллисекунд в пользу независимого приложения. В то же время разница во времени подготовки приложения к его использованию обычно составляет величины порядка минуты - часы в пользу систем с интерпретацией.

6.Виды моделей данных

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

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

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

Узел–это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящемся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчинённую никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчинённые) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи БД существует только один путь от корневой записи.

В иерархии у каждого потомка может быть только один предок.

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

Сетевая модель данных соответствует трёхуровневой архитектуре следующим образом:

1. Концептуальный уровень (логический вид всех данных и отношений в базе данных) называемой схемой.

2. Внешний уровень (пользовательские представления данных, нужные для разных приложения) называется подсхемой.

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

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

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

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

Понятие реляционный связано с разработками известного американского специалиста в области систем баз данных Е.Кодда.

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

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

Реляция–двумерная таблица, содержащая строки и столбцы данных.

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

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

Рекурсивное отношение–отношение, связующее объектное множество с ними самими.

Название столба–это имя атрибута. Количество атрибутов реляции называется степенью реляции (если столбцов 5, то степень реляции равна 5).

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

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

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

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

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

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

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

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

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

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

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

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

Описание хранимой и обрабатываемой информации в ЭИС делается с разной степенью детализации. Различают 3 уровня детализации:

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

2. Концептуальный уровень - описание информационных потребностей на уровне ЭИС.

3. Внутренний уровень - описание способов хранения информации в памяти ЭВМ и методов доступа к ней.

ИМД основана на понятии деревьев, состоящих из вершин и ребер. Вершине дерева ставится в соответствие совокупности атрибутов данных, характеризующих некоторый объект. Вершины и ребра дерева как бы образуют иерархическую древовидную структуру, состоящую из n уровней.

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

2. Каждая вершина соответствует одному или нескольким атрибутам.

3. Hа уровнях с большим номером находятся зависимые вершины. Вершин предшествующего уровня является начальной для новых зависимых вершин.

4. Каждая вершина, находящаяся на уровне i, соединена с одной и только одной вершиной уровня i-1, за исключением корневой вершины.

5. Корневая вершина может быть связана с одной или несколькими зависимыми вершинами.

6. Доступ к каждой вершине происходит через корневую по единственному пути

7. Существует произвольное количество вершин каждого уровня.

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

Основные достоинства ИМД: простота построения и использования, обеспечение определенного уровня независимости данных, простота оценки операционных характеристик.

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

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

· Добавление новой записи (при добавлении новой записи должен быть организован уникальный ключ, значение которого однозначно характеризует ее).

· Изменение значения предварительно извлеченной записи (значение ключа при этом не должно изменяться).

· Удаление некоторых записей, при этом удаляются все записи, находящиеся с ней в групповом отношении.

o Следующей записи (эта операция выполняется в порядке левостороннего обхода дерева)

В СМД элементарные данные и отношения между ними представляются в виде ориентированной сети (вершины - данные, дуги - отношения).

В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL.

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

· Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.

· Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базы данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.

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

Над данными сетевой модели можно выполнять следующие действия:

· внести запись в БД (в зависимости от типа включения запись может быть внесена в групповое отношение или нет);

· включить запись в групповое отношение (связать запись с каким-либо владельцем);

· переключить (связать подчиненную запись с записью владельца в том же групповом отношении);

· изменить значение элементов предварительно извлеченной записи;

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

· удалить – при удалении записи необходимо учитывать классы членства;

· исключить из группового отношения (разорвать связь между записью владельца и подчиненной записью).

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

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

Реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.

2. Столбцы реляц.таблицы поименованы, поэтому их порядок не важен.

4. Каждая запись уникальна и однозначно определяется значением ключа.

5. Каждый элемент таблицы называется полем, может быть однозначно определен.

6. В столбце записываются данные одного типа

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

Все операции, выполняемые над отношениями, можно разделить на две группы:

1. Операции над отношениями, к которым относятся проекция, соединение и выбор.

2. Операции над множеством, то есть над несколькими отношениями (объединение, пересечение, разность, деление, декартово произведение).

7.МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ»

ER-модель (Entity-Relationship model) представляет собой высокоуровневую концептуальную модель данных, которая была разработана в 1976 году с целью упрощения задачи проектирования БД. Основные концепции модели «сущность-связь» включают типы сущностей, связи и атрибуты.

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

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

Отдельные свойства сущности называются атрибутами. Атрибуты сущности содержат значения, описывающие ее. Значения атрибутов – основная часть сведений БД.

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

Простые атрибуты не могут быть разделены на более мелкие компоненты. Примеры: пол, зарплата.

Составные атрибуты могут быть разделены на более мелкие компоненты, которые характеризуются независимым существованием (адрес, ФИО).

Однозначный – атрибут, который содержит одно значение для сущности.

Многозначный – атрибут, который содержит несколько значений для сущности (телефоны).

Домен атрибута – набор значений, которые могут быть присвоены атрибуту.

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

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

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

Рекурсивная связь – связь, в которой одни и те же сущности участвуют несколько раз и в разных ролях.

Метод создания набора отношений с заданными свойствами на основе требований к данным. Процесс нормализации был впервые предложен Коддом. Сначала были предложены три вида нормальных форм: первая, вторая и третья. Затем было сформулировано строгое определение третьей нормальной формы, которое называется НФ Бойса-Кодда. Позже появились 4-я и 5-я НФ, на практике использующиеся крайне редко.

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

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

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

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

Данная таблица спроектирована неудачно, так как в 4 кортежах, соответствующих рабочему 1412, повторяется одно и то же имя и информация о типе специальности. Эта избыточность данных или повторение приводит к нарушению целостности данных (противоречивость_ в БД. Проблема возникает из-за того, что работник может работать более чем на одном здании.

Целостность данных–согласованность данных в БД.

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

Аномалия обновления–противоречивость данных, вызванная их избыточностью и частым обновлением.

Необходимо разделить таблицу WORKER на две реляционные таблицы, WORKER и ASSIGNMENT (назначение), тогда аномалий не возникает.

Разбиение–это процесс разделения таблиц на несколько таблиц в целях избавления от аномалий и поддержания целостности данных (нормализация данных).

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

Атомарное значение–значение, не являющееся множеством значений или повторяющейся группой.

Вторая и третья нормальные формы касаются отношений между ключевыми и неключевыми атрибутами. Реляционная таблица находиться во 2НФ, если никакие неключевые атрибуты не являются функционально зависимыми лишь от части ключа. Таким образом, 2НФ может быть нарушена, если ключ является составным, то есть ключом является набор из нескольких атрибутов.

В данной таблице ключ состоит из атрибутов WORKER-ID и BLDG-ID. NAME определяется атрибутом WORKER-ID и, и следовательно, функционально зависит от части ключа. Это означает, что для определения имени работника, достаточно знать WORKER-ID. Таблица не удовлетворяет 2НФ. Для того, чтобы решить эту проблему, необходимо разбить на 2 реляционные таблицы, каждая из которых удовлетворяет 2НФ.

Эти 2 меньшие таблицы называются проекциями исходной таблицы.

Процесс разбиения на две 2НФ-таблицы состоит из нескольких простых шагов:

Третья нормальная норма–любой детерминант является ключом.

В данной таблице имеются следующие функциональные зависимости:

Однако также имеется функциональная зависимость

SKILL-TYPE не является ключом, соответственно, критерий 3НФ не выполняется.

Создадим новую таблицу R1, удалив из WORKER все атрибуты, стоящие в правой части ФЗ. В нашем примере, это ПРЕМИАЛЬНЫЕ.

Создадим новую таблицу, состоящую из атрибутов как из левой, так и из правой частей ФЗ. В нашем примере это SKILL-TYPE и BONUS-RATE. Детерминант ФЗ SKILL-TYPE будет ключом (таблица R2).

Такая версия 3НФ часто называется нормальной формой Бойса–Кодда (НФБК). Этот критерий утверждает, что таблица удовлетворяет 3НФ, если в ней нет транзитивных зависимостей.

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

Одной из наиболее популярных семантических моделей данных является модель «сущность-связь" (часто называемая также ER-моделью — по первым буквам английских слов Entity (сущность) и Relation (связь)).

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

Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом 1DEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDEF, Power Designer). Основными понятиями ER-диаграммы являются сущность, связь и атрибут.

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

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

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

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

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

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

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

8. Сетевая модель данных

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

Над данными сетевой модели можно выполнять следующие действия:

· включить запись в групповое отношение (связать запись с каким-либо владельцем);

· переключить (связать подчиненную запись с записью владельца в том же групповом отношении);

· изменить значение элементов предварительно извлеченной записи;

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

· удалить – при удалении записи необходимо учитывать классы членства;

· исключить из группового отношения (разорвать связь между записью владельца и подчиненной записью).

9.Защита баз данных.

Защита баз данных – обеспечение защищенности базы данных против любых предумышленных или непредумышленных угроз с помощью различных компьютерных и некомпьютерных средств.

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

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

Опасность – любая ситуация или событие, намеренное или непреднамеренное, которое способно неблагоприятно повлиять на систему.

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

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

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

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

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

Аутентификация – механизм определения того, является ли пользователь тем, за кого себя выдает. За предоставление доступа к компьютерной системе обычно отвечает системный администратор, в обязанности которого входит создание учетных записей пользователей. Каждому пользователю присваивается уникальный идентификатор, который используется ОС для определения того, кто есть кто. С каждым идентификатором связывается определенный пароль, выбираемый пользователем и известный операционной системе. При регистрации пользователь должен предоставить системе свой пароль для выполнения проверки (аутентификации) того, является ли он тем, за кого себя выдает. Подобная процедура позволяет организовать контролируемый доступ к компьютерной системе, но необязательно предоставляет право доступа к СУБД или иной прикладной программе. Для получения доступа к СУБД может использоваться отдельная подобная процедура. Ответственность за предоставление прав доступа к СУБД обычно несет администратор БД, который создает идентификаторы пользователей в среде самой СУБД.

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

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

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

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

5. Шифрование. Кодирование данных с использованием специального алгоритма, в результате чего данные становятся недоступными для чтения любой программой, не имеющей ключа дешифрования. Некоторые СУБД включают средства шифрования, предназначенные для использования в подобных целях. Подпрограммы таких СУБД обеспечивают санкционированный доступ к данным (после их декодирования). Шифрование также может использоваться при передаче данных по линиям связи. Существует множество различных технологий кодирования данных с целью сокрытия передаваемой информации, одни из них называют необратимыми, другие – обратимыми. Необратимые методы не позволяют установить исходные данные. Обратимые технологии используются чаще. Для организации защищенной передачи данных по незащищенным сетям должны использоваться системы шифрования, включающие следующие компоненты:

· ключ шифрования, предназначенный для шифрования исходного текста;

· алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;

Некоторые системы шифрования, называемые симметричными, используют один и тот же ключ как для шифрования, так и для дешифрования.

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

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

В документах по мерам безопасности должно быть определено:

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

· ответственность и обязанности отдельных работников;

· дисциплинарные меры, принимаемые в случаях нарушений установленных ограничений;

· процедуры, которые должны обязательно выполняться.

Типичный план защиты от непредвиденных обстоятельств должен включать:

· сведения о том, кто является главным ответственным лицом и его контакты;

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

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

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

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

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

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

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

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

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

-специальные регистры для хранения реквизитов защиты: паролей, идентифицирующих кодов, грифов или уровней секретности,

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

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

-специальные биты секретности, значение которых определяет уровень секретности информации, хранимой в ЗУ, которой принадлежат данные биты,

-схемы прерывания передачи информации в линии связи с целью периодической проверки адреса выдачи данных.

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

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

-идентификация технических средств (терминалов, устройств группового управления вводом-выводом, ЭВМ, носителей информации), задач и пользователей,

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

-контроль работы технических средств и пользователей,

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

-уничтожения информации в ЗУ после использования,

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

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

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

4. криптографическое шифрование информации.

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

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

-обоснование путей реализации систем шифрования в автоматизированных системах,

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

-оценка эффективности криптографической защиты.

СЕТЕВАЯ ЭКОНОМИКА

1. Создание сетевых форм организаций

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

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

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

2. Внутрифирменное информационное пространство

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

3. Коллективное формирование информационных ресурсов

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

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

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

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

Модернизация торговой инфраструктуры с помощью Интернет-технологий получила название "телеторговля" или "электронная коммерция". На начало 1998 г. в Интернете действует около 3 млн. торговых сайтов. Объем продаж через Интернет в США составляет пока около 2% от общего показателя. В прогнозе на 2002 г. ожидается, что эта доля повысится до 10% и составит 327 млр. долларов.

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

· В банковской индустрии транзакционные издержки составляют порядка 1 доллара при совершении сделки в отделении банка, 50 центов при совершении сделки по телефону, 25 центов при использовании банкоматов и 13 центов при использовании Интернет

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

· Крупный американский банк Citibank (http://www.citibank.com/) начинает разворачивать операции в Великобритании. Банк не планирует создавать в Великобритании филиалов или отделений. Вместо этого банк планирует предложить своим клиентам бесплатный доступ к Интернет. Соответствующие услуги будут обеспечиваться британским провайдером Virgin Net (http://www.virgin.net/). Citibank полагает, что его накладные расходы окажутся настолько низкими, что он сможет платить своим клиентам 4,75% годовых по текущим счетам, тогда как для большинства традиционных банков этот процент составляет всего 0,3%.

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

3.система трудовых отношений - дистанционные трудовые отношения.

Этот процеес является частью децентрализция процесса производства в пространстве и времени.

-Использование коммуникаций и интернет технологий

Удешевление раб.силы.; работодатель заинтересован в увеличении нововведений для увеличения производства

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

«-»: отсутсвие контроля за менеджером; не существует коллективного креатифа, коммукационный барьер.

«-» психологическая нагрузка :«+» разгрузка инфраструктур, снижения

2. Дистанционные трудовые отношения (телеработа)

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

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

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

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

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

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

Социально-экономические выгоды общества от массового применения средств телеработы:

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

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

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

3.Особенности сетевой экономики

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

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

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

Эти новые особенности сетевой экономики требуют учета в практической деятельности следующих новых моментов:

1. Электронные чипы стремительно миниатюризируются, дешевеют, и проникают повсюду. Наращивание разнообразных и многоуровневых связей между этими внедряемыми всюду "желатиновыми бобами" (jelly beans), приводит к образованию среды тесно связанных друг с другом чипов, испускающих непрерывный поток мини-посланий ("Пора открывать", "Начинай работу", "Осталось мало воды", "Ступай сюда" и т.д. и т.п.), которые будут расходиться сверх-подвижными волнами. Сетевая экономика вовлекает все новых участников: программные агенты, роботы, приборы и машины, а также несколько миллиардов людей. Все будут связаны со всеми.

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

3. Ценность участия в сетевой экономике растет экспоненциально от роста числа участников. Этот рост "засасывает" в сетевую экономику все новых и новых участников. Примеры такого роста наблюдаются для корпораций Микрософт, Федерал Экспресс, для распространения факс-аппаратов и по отношению к самой сети Интернет.

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

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

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

7. Если услуги становятся тем ценнее, чем они многочисленнее (пункт №2), и если они стоят тем меньше, чем они становятся лучше и важнее (пункт №6), то, продолжая эту логику, можно сказать, что самые ценные вещи должны быть те, которые бесплатны. Электронные копии почти ничего не стоят, а ценность возрастает пропорционально при их умножении, порождая все большую потребность в них. Когда важность и незаменимость продукта установится, компания может продавать дополнительные услуги или делать апгрейд (улучшать), что позволяет следовать и далее курсом щедрости и поддерживать этот магический круг. Вдобавок, единственный фактор в мире, становящийся действительно редким ресурсом - это внимание. Выбрасывая на рынок бесплатный продукт, вы приковываете долю человеческого внимания, которая приведет к доле рынка. И то, что сегодня бесплатно, завтра приобретет ценность, включая новые навыки и знания (сетевые, в первую очередь).

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

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

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

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

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

4.Обзор основных Интернет-технологий.

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

Самым статичным представителем перового вида являются классические веб-страницы, которые несут информацию (возможно, достаточно часто обновляемую) от источника к потребителю, но не содержат удобных средств для двух- или многостороннего взаимодействия авторов и пользователей информации Более динамичным представителем первого типа технологий являются телеконференции, или как их еще называют "группы новостей" (newsgroups), и близкие к ним "списки рассылки" (mailing lists), которые позволяют в течение нескольких часов распространять сообщения отдельных людей среди гигантской аудитории и дают достаточно удобные возможности для проведения массовых обсуждений и обмена мнениями. На базе данных средств в Интернете работает более 20 тысяч тематических дискуссионных групп, члены которых получают сообщения друг от друга по электронной почте и могут просматривать и реагировать на них в любое удобное время. Размер таких групп практически не ограничены. Любой пользователь Интернета может в течение часа подписаться на получение сведений, распространяемых по определенным группам новостей, или отказаться от подписки. Известно, что в этих группах стихийно, но достаточно регулярно возникают дискуссии по определенным темам, которые продолжаются от одного дня до нескольких месяцев, в которых может принять участие 2-3 человека или несколько сотен, которых объединяет общность интересов, а не территориальная близость.

Рассмотрим подробнее три наиболее используемых способа реализации асинхронных коммуникаций:

- СПИСКИ РАССЫЛКИ Списки рассылки (mailing list) являются наиболее старым представителем интерактивный Интернет-технологий. Для участия в них достаточно иметь собственный адрес электронной почты и знать адрес нужного списка рассылки (см. в правой колонке где можно найти адрес списка рассылки). На этот адрес посылается письмо, текст которого состоит из некоторых команд или сообщения для пользователей данного списка рассылки. Для получения списка команд, как правило, достаточно послать на адрес списка рассылки письмо из одного слова help. Заголовок писем с командами для списка рассылки обычно должен быть пустым. Если вы послали письмо с командой подписаться на данный список рассылки (чаще всего эта команда - subscribe), то ваш адрес, который берется из служебных заголовков вашего письма, помещается в список адресов, по которым будут дублироваться все приходящие сообщения за исключением писем с командами.

- ГРУППЫ НОВОСТЕЙ Группы новостей (newsgroups), в России их чаще называют телеконференции, являются технически более развитым средством, чем списки рассылки и поэтому, часто, включают возможности последних. Главное отличие групп новостей от списков рассылки - пользователь может не получать их на свой компьютер по электронной почте, а может просматривать их прямо на так называемых серверах новостей (newsserver). Для этого требуется специальное программное обеспечение. Просмотр различных групп новостей становится более простым и оперативным по сравнению со списками рассылки.

С технической точки зрения, группы новостей существуют за счет того, что все мировые сервера новостей обмениваются между собой поступающими от их пользователей сообщениями по пересекающимся спискам групп новостей. Разные сервера могут хранить для своих пользователей разные наборы групп новостей и с разной продолжительностью. Например сервер новостей Инфотека хранит около 1500 групп новостей, а аналогичный сервер НГУ не несколько сот групп больше. По разным группам срок хранения сообщений может варьироваться от одного дня (группа "test" в НГУ) до нескольких месяцев. http://feedme.org/, включающая и российские группы новостей

- ВЕБ-ФОРУМЫ Веб-форумы (web forums) являются следующим этапом развития описанных выше технологий и представляют из себя интеграцию возможностей списков рассылки, групп новостей с веб-страницами. В результате, привычные веб-страцицы, которые по средствам выразительности превосходят другие технологии, получают дополнительно достаточно мощные интерактивные свойства. Примерами веб-форума являются интерактивные веб-страницы "Телеработа в России", "Виртуальный Академгородок", доска объявлений для одного из спецкурсов на ЭФ НГУ.

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

5. Эмпирические законы сетевой экономики.

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

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

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

На фоне вышесказанного главное ответить на вопрос меняется только технология, а экономические законы остаются без изменений или современное технологическое развитие устанавливает принципиальное новые закономерности в экономических процессах. В 1926 г Кондратьев Николай отметил в труде «Длинные волны»: «Помимо кратких и среднесрочных волн существуют циклы которые охватывают от 20 до 50 лет», а также отметил, что данные цикл основывается на инновациях. В дальнейшем Нефёдов Л. отметил, что данные инновации – Базисные инновации.

1. На технологическом уровне определяют тем и направление инновационного процесса.

2. На экономическом решающим образом обуславливает общеэкономическое развитие и оказывает самое главное влияние на экономический рост.

3. На общественном уровне приводит к широкой реорганизации.

На современном уровне базисные инновации – информационная техника. (исходя из точки зрения Кондратьева)

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

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

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

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

Появляется новая парадигма роста. Ели в течении первых четырех циклов делался упор на ресурсы и матерю то в текущем моменте делается упор на информацию.

b. Значение микроэлектроники для повышение производительности в области информационной техники (все эти законы «эмпирическим исследованиями» принципиально необходимо учитывать временное ограничение):

1. Закон Гроша гласит : «Производительность компьютерной техники возрастает как квадратная функция от инвестиций в эту отрасль»

2. Мур считается: «Мощность электронных чипов возрастает в 2 раза каждые 18 месяцев» это подтверждено в наноэлектронике в оптоволоконной техники.
Из этого закона можно сделать что плотность хранения информации увеличивается каждый раз в 2 раз -> цены на микропроцессоры в 2 раза.

Коммуникационная техника как технологическая база для создания сетей:

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

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

Утверждение Хантли: по размеру основной капитал телекоммуникационной компании в 10 раз превышает капитал традиционных предприятий. Можно выявить структурные различия между коммуникационными компаниями и обычными промышленными коммерческими.

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

2. Косвенный сетевой эффект – рыночно-обусловленный, возникает в случае, если комплектующая продукция (зап. части. сервисы, программы) становится дешевле и доступнее. Он проявляется в том случае, когда наряду с ростом спроса на товар как правило:

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

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

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

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

Из закона Хантли: инвестиции в оборудование в телекоммуникационном секторе значительно выше, чем в классическом производстве. Потребность инвестиций в научные исследования, конструирование и разработку технологий составляют самую крупную часть затрат, тогда как вложение в их последующее массовое производство снижаются. То же самое можно сказать про относительный ИП – услуги, пользующиеся спросом для устранения фактического или потенциального И. дефицита. Д. Шапиро утверждает, что И. дорого производить, но дешево воспроизводить. Это связано с высокими постоянными затратами, но низкими предельными издержками. Доминирование постоянных затрат для снижения предельных издержек означает определенный вызов для предприятия, поскольку расходы на опытные и конструкторские работы должны осуществляться непрерывно и быть значительными. что ведет к сложению альянсов п/п по вложениям в научную разработку.

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

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

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

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

f. Доминирование отрицательной обратной связи в классической экономике.

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

g. Доминирование положительной обратной связи в информационной экономике.

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

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

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

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

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

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

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

Изменение требований к квалификации специалистов в сетевой экономике.

1. увязка технической и экономической сторон ноу-хау;

2. создание психологически-социальной компетенции.

Рис. «Структурные изменения в системе управления»

6.Распределенные сети, локальные сети, сети предприятия.

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

3. сетевая операционная система (сетевые программы).

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

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

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

Все вышесказанное можно объединить одним термином -- совместный доступ к ресурсам.

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

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

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

Intranet - это внутренняя корпоративная сеть, построенная на интернет-технологиях.

Intranet - системы - промежуточное звено между локальной сетью и корпоративными системами высокого уровня - CRM и ERP решениями. С технической точки зрения интранет - это внутренний корпоративный web-портал, призванный решать задачи именно вашей компании; задачи, в первую очередь, по систематизации, хранению и обработке внутрикорпоративной информации. Интранет - сайт доступен только в рамках локальной сети Компании включая удаленные филиалы (intranet) или как портал в сети Интернет, невидимый в поисковых системах и требующий авторизации при входе (extranet). Доступ к страницам портала осуществляется через web-браузер, что позволяет пользоваться услугами интранет - систем людям с минимальной компьютерной подготовкой. Обновление информации осуществляется ответственными сотрудниками с помощью специальных интерфейсов, работа с которыми практически идентична работе с офисными приложениями.

Ключевым словом при описании intranet - систем является слово "единый":

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

· Низкий риск и быстрая отдача инвестиций.

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

· Низкая стоимость и простота технологий.

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

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

В общем случае сети, расположенные в одном (или нескольких близко расположенных) здании называется локальной (ЛВС). Сети, объединяющие компьютеры в разных зданиях, городах и странах, она называется распределенной (WAN -Wide Area Network). Распределенные сети очень большого масштаба (например, Internet, EUNET, Relcom, FIDO) часто называют глобальными. Распределенные сети состоят из трех основных компонент:

1. Локальные сети, как узлы распределенной сети

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

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

· Повторители (Repeater) - усиливают полученный из кабельного сегмента сигнал и передают его в другой сегмент.

· Мосты (Bridge) передают сообщения на основе записей в таблице пересылки.

o соединяет идентичные или разные сети (например, Ethernet и Token Ring).

· Маршрутизаторы (Router) обеспечивают выбор маршрута обмена данными между узлами сети.

o Дистанция обычно оценивается в интервалах (hop) - промежутках между двумя соседними маршрутизаторами на пути от отправителя к получателю.

a. Организация межсоединений в сети интернет

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

5. сеансовый (TCP) отвечает за установку, поддержание и свертывание соответствующих каналов;

6. представительский обслуживает работу прикладных программ (FTP);

7. прикладной уровень взаимодействует с пользователем, предоставляет сетевые инфо-услуги и использование пользователем ПП.

В начале сообщения IP дается адресная информация отправителя, в конце – получателя. IP не отвечает за сборку пакетов, за это отвечает протоколов транспортного уровня TCP. Он:

2. на стороне получателя собирает и расставляет по местам пакеты;

3. запрашивает пропущенные и потерянные пакеты,если они есть;

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

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

1. Dial-Up – соединение с провайдером через модем по телефонным сетям. Прокси-серверы;

3. ADSL – асимметричная цифровая абонентская линия.

7.Электронная коммерция.

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

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

«Мягкие» - товары, которые могут быть представлены в электронной форме ( информация, программное обеспечение)

«Жесткие» - вещественные товары и товарные предметы.

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

1 – участники: правительство, поставщики, торговцы, потребители, производители.

2 – процессы: исследование рынка, расчеты, выполнение заказов, продажи, поддержка.

8.Модели организации предприятий в сетевой экономике.

Концепции и модели бизнеса в среде интернет.

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

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

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

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

C2C ( потребитель для потребителя) – продажа товаров и услуг между потребителями.

C2B ( потребитель для бизнеса) – предоставляют возможность потребителю самостоятельно устанавливать цены на услуги и товары.

1. Посредническая модель. Посредники сводят продавца и покупателя вместе и помогают продвижению товара. Характерна для концепций B2B, B2C, C2C. Посренические издержки – гонорар, комиссия.

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

2. торговые посредники принимают заявки на определенные условия приобретения товара.

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

4. аукционный посредник поддерживает аукционных продавцов, посреднические издержки продавца – за право на размещение товара и % от транзакций.

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

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

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

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

1. портал – поисковая машина, к которой могут быть присоединены контент и сервисы. Большое количество посетителей делают их доходными.

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

2. нишевые порталы – более крупные, направлены на группу;

2. доски объявлений – перечень позиций либо для продажи либо для приобретения. Может быть платным возмещением или посещением.

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

4. контентно-таргетированная реклама (целевая)

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

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

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

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

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

4. Торговая модель. Оптовые и розничные продавцы и покупатели.

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

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

2. оплата за клики – партнер платит тому сайту, на котором размещен баннер за количество кликов.

7. Комьюнити модель: доход может быть основан на продаже дополнительных товаров и услуг или на добровольных взносах пользователей.

2. публичная трансляция – на основе вложений участников

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

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

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

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

3. Интернет-компании, реализующие товары и услуги через интернет. Цель – осуществление полного бизнес-цикла в интернет, ориентация на получение прибыли. Концепция – создание интерактивного сайта. который обеспечивает работу с клиентами. в т. ч. он-лайн заказы, имеет сервис поставок, платежей, п/п полностью окупаемым и приносящее прибыль.

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

9.Электронные платежные системы.

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

На данный момент электронная коммерция в рунете охватила все сегменты рынка, что привело в свою очередь к возникновению платежных систем (с 1998 г. - Pay Cash, 1999г – Web Money, 2002г. Pay Cash+Yandex = яндекс-деньги).

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

1. непосредственная оплата в магазин, где покупаешь;

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

Существующие на данный момент электронные платежные системы по типу доступа к электронному счету можно разделить на 2 большие группы:

 требующие установки на компьютер пользователя дополнительного программного обеспечения;

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

Этап проектирования	Реализация в Business Studio
Формализация стратегии	Стратегические карты, Сбалансированная система показателей
Проектирование бизнес-процессов	нотации моделирования: IDEF0, Процесс (Basic Flowchart), Процедура (Cross Functional Flowchart), EPC (Event Driven Process Chain).
Проектирование организационной структуры	Проектирование организационной структуры управления, отражающей распределение полномочий и ответственности за исполнение бизнес-процессов компании, назначение исполнителей отдельных действий в рамках бизнес-процессов, а также проведение расчета необходимого количества сотрудников.
Имитационное моделирование и ФСА	Моделирование деятельности компании в рамках спроектированных бизнес-процессов и организационной структуры.
Разработка ТЗ на внедрение информационных систем	Система позволяет создавать четкие и подробные задания для разработчиков ИС
Формирование регламентирующей документации	Автоматически генерируются Регламенты процессов и процедур, Должностные инструкции, Положения о подразделениях. Возможность разработки и использования фирменных стилей.
Доведение документации до сотрудников	Вывод документации в MS Word для печати – ознакомление под роспись. Вывод документации в HTML-навигатор.
Контроль показателей.	Возможность контролировать достижение запланированных значений показателей непосредственно в системе Business Studio; в отчетах, сформированных по значениям показателей в формате MS Word; с помощью специального модуля Cockpit
Анализ показателей	Анализ показателей в динамике. Анализ план-факт. Декомпозиция рассчитываемых показателей.
Анализ несоответствий и их последствий	Анализ несоответствий и причин их возникновения с применением диаграммы Исикавы
Замыкая круг	Планирование корректирующих и предупреждающих мероприятий