7.2.6 Описание функциональных блоков

А1. Определить цели управленческого учета.

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

АН. На первом этапе декомпозиции руководством определяется стратегия управленческого учета на основе потребностей в управлен­ческой информации. Его задача — формализовать потребности и увязать их со стратегией предприятия.

Рис. 7.6. Декомпозиция первого уровня

Рис. 7.7. Одна из декомпозиций второго уровня

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

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

А2. Собрать и обработать данные.

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

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

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

А23. Данные в информационной системе распределяются по объ­ектам учета и центрам ответственности. При наличии достаточной аналитики это осуществляется автоматически.

A3. Подготовить управленческую отчетность

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

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

А32. Сводная отчетность формируется на основе консолидации отчетности центров ответственности и других обработанных данных. В части подтвержденных данных контрольные функции выполняет финансовая отчетность.

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

Применение функционального 7.3 моделирования в аудиторской деятельности

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

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

SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования — широко используется вомногих областях, начиная с 1973 г. SADT обычно применяется на ранних стадиях создания системы для минимизации возмож­ных ошибок, исправление которых на стадии проектировании обхо­дится гораздо дешевле, чем во время функционирования системы. SADT-методология нашла свое применение в создании программно­го обеспечения, долгосрочном стратегическом планировании, обу­чении персонала, автоматизированном производстве, управлении финансами и т.д.

С помощью методологии SADT на основе технологий аудитор­ской компании "BDO Руфаудит" была создана обобщенная схема про­цесса проведения аудиторской проверки, начиная с преддоговорной организационной работы и заканчивая представлением аудиторско­го заключения. Целью данной работы является последовательное

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

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

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

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

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

Возможны также обратные связи: при промежуточной оценке ре­зультатов принимается решение о корректировке направлений про­верки, что приводит к изменению стратегии аудита и новому планиро­ванию (диаграммы АО и A3) — рис. 7.10.

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

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

ПРИЛОЖЕНИЯ П1 Семейство стандартов IDEF

Применяемые в CASE-средствах разные методики и модели опи­сывают различные свойства систем, важные, например, с точки зре­ния их автоматизации, а также позволяющие количественно оценить параметры проектов. Следует отметить, что спектр свойств систем различного назначения очень широк, и не все они к настоящему вре­мени отражены в адекватных моделях. В то же время для класса информационных систем организационного типа (Management Information Systems — MIS) адекватные модели разработаны и под­держиваются соответствующими средствами автоматизации.

Взаимная совокупность методик и моделей концептуального про­ектирования IDEF (Integrated DEFinition) разработана в США по про­грамме Integrated Computer-Aided Manufacturing. В настоящее время имеются методики функционального, информационного и поведенче­ского моделирования и проектирования, в которые входят IDEF-моде-ли, приведенные ниже.

Название	Назначение
IDEF0	Функциональное моделирование
	Function Modeling Method
IDEFIhIDEFIX	Информационное моделирование
	Information and Data Modeling Method
IDEF2	Поведенческое моделирование
	Simulation Modeling Method
IDEF3	Моделирование деятельности
	Process Flow and Object Stale Description Capture Method
IDEF4	Объектно-ориентированное проектирование
	Object-oriented Design Method
IDEF5	Систематизация объектов приложения
	Ontology Description Capture Method
IDEF6	Использование рационального опыта проектирования
	Design Rational Capture Method
IDEF8	Взаимодействие человека и системы
	Human-System Interaction Design

IDEF9	Учет условий и ограничений
	Business Constraint Discovery
IDEF14	Моделирование вычислительных сетей
	Network Design

IDEFO реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique), предло­женная в 1973 г. Д. Россом и впоследствии ставшая основой стандарта IDEF0. Эта методика рекомендуется для начальных стадий проекти­рования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспече­ние.

IDEF1X hIDEFI реализуют методики инфологического проекти­рования баз данных. В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь" (ERD — Entity-Relations Diagrams) Разра­ботка информационной модели по IDEF1X выполняется в несколько этапов:

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

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

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

• детализируются нестандартные отношения, определяются ключе­ вые атрибуты сущностей. Детализация отношений заключается в замене связей "многие ко многим" на связи "многие к одному" и "один ко многим";

• определяются атрибуты сущностей.

IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает система?", то в этих методиках дета­лизируется ответ: "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирова­ния систем массового обслуживания, сети Петри, возможно примене­ние модели конечного автомата, описывающей поведение системы как последовательности смен состояний.

Перечисленные методики относятся к так называемым структур­ным методам.

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

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

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

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

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

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

П2 Нотации моделирования

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

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

Функциональная модель системы описывает совокупность вы­полняемых системой функций, характеризует морфологию системы (ее построение) — состав подсистем, их взаимосвязи.

Информационная модель отображает отношения между элемен­тами системы в виде структур данных (состав и взаимосвязи).

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

Сочетания типов моделей образуют стандартные CASE-модели. На рынке программных продуктов имеется много CASE-систем для концептуального проектирования систем, поддерживающих пе­речисленные модели. Чаще всего речь идет о поддержке мето­дологии IDEF. В России достаточно широко известны продукты BPwin, ERwin, OOwin фирмы Platinum, Design/IDEF фирмы Meta Software, CASE-аналитик фирмы "Эйтэкс", Silverun фирм CSA, Paradigm Plus и др. Приведем основные характеристики программных продуктов фирмы Platinum.

Система BPwin предназначена для разработки функциональных моделей по методике IDEF0.

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

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

_пз Программное средство

моделирования Design/IDEF

Одной из альтернатив описанному выше пакету Platinum BPwin является программа Design/IDEF, выпущенная в 1995 г. компанией Meta Software (США). Design/IDEF поддерживает создание моделей в следующих методологиях (рис. Ш): . IDEF0; . IDEF1X.

Основными преимуществами Design/IDEF перед BPwin являются:

Рис, Ш. Выбор методологии моделирования в Design/IDEF

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

• доступность — Design/IDEF распространяется бесплатно и ее можно без проблем получить из Internet;

• поддержка проектирования схем данных по методологии IDEF1X (однако необходимо отметить, что компания Platinum предлагает

для аналогичных целей программное средство ERwin, которое об­ладает большими возможностями по сравнению с Design/IDEF и довольно распространено среди разработчиков баз данных) По своим возможностям в части поддержки методологии IDbtU Design/IDEF во многом идентичен программе Platinum BPwin. Ре­зультат моделирования по методологии IDEF0 с использованием Design/IDEF приведен на рис. П2. Программу Design/IDEF можно скопировать из Интернет, обратившись, например, по адресу: www.idefine.com.

Структурный

П4 и объектно-ориентированный подход. Что лучше

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

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

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

Традиционный подход к разработке моделей

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

1. Структурный анализ и структурное проектирование (Structured Analysis and Structured Design — SA/SD) является одной из самых из­ вестных методик разработки информационных систем. В методике SA/SD подчеркивается, что система предоставляет своим пользова­ телям одну или несколько функций — так называемый подход функ­ циональной декомпозиции. SA/SD предлагает набор средств, таких как диаграммы потоков данных, диаграммы состояний-переходов. ER-диаграммы (на фазе анализа) и структурные схемы (на фазе проек­ тирования).

2. Методика IDEF (Integrated computer aided manufacturing DEFinition) была разработана ВВС США в середине 70-х гг. На основе этой методики министерство обороны США создало федеральный стандарт обработки информации IDEF1X, который обеспечивает поддержку на нескольких уровнях посредством "модели бизнеса", "модели информационной системы" и "модели технологии". Модели­ рование бизнеса поддерживается ER-диаграммами для данных и диа­ граммами потоков данных специального вида, что позволяет иерархи­ чески описывать функции системы.

3. Методика SADT (Structured Analisis and Design Technige) ис­ пользует систему обозначений, похожую на диаграммы потоков дан­ ных IDEF, для описания функций и структур данных информацион­ ной системы на основе декомпозиции.

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

_Г

/Щ:и замены). Другими словами, информационная система описыва-ся как некая абстракция компьютера.

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

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

• линейность выполнения этапов жизненного цикла разработки;

• четкое разделение данных и процессов их обработки;

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

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

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

• трудоемкость внесения изменений;

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

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

• сложность переноса на другие платформы.

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

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

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

Особенности сложных информационных систем

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

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

Применяемые инструментальные средства (ИС) должны поддер­живать групповую разработку. Для этого современные ИС реализуют­ся в комплексах с архитектурой "клиент-сервер". В них должна быть предусмотрена возможность интеграции результатов работы отдель-

ных участников проекта и защиты их от несанкционированного доступа.

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

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

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

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

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

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

Каждый объект является представителем некоторого класса одно­типных объектов. Класс определяет общие свойства для всех его объ­ектов. К таким свойствам относятся:

• состав и структура данных, описывающих атрибуты класса и соот­ ветствующих объектов;

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

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

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

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

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

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

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

При таком подходе сложная система описывается наиболее есте­ственным образом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• осознавать выгоды такого подхода;

• знать, какие части задачи могут быть решены с применением су­ ществующих программных средств;

• заниматься поиском подходящих для повторного использования программ;

• стремиться найти такие программы;

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

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

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

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

Недостатки объектно-ориентированного подхода

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

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

Динамическое связывание, предполагающее поиск метода в клас­се, которому принадлежит получающий сообщение объект, приводит к тому, что обращение к методу занимает в 1,75-2,5 раза больше вре­мени, чем к обычной подпрограмме. Это, конечно, замедляет работу приложения. Однако, как указывает Г. Буч, динамическое связыва­ние при использовании строго типизированных языков применяется примерно в 20% случаев вызовов методов. В результате снижаются непроизводительные потери времени. В приложениях, где такие по­тери критичны, приходится прибегать к специальным программист­ским приемам.

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

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

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

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

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

Реинжиниринг: П5 не автоматизируйте — уничтожайте

В данном приложении приводится перевод статьи одного из ос­новоположников реинжиниринга бизнеса М. Хаммера (Reengineering Work: Don't Automate, Obliterate by Michael Hammer / Harvard Business Review, 1990), одним из первых затронувших эту про­блему. (Майкл Хаммер — президент Hammer and Company (www.hammerandco.com), консалтинговой фирмы, работающей в области информационных технологий, расположенной в г. Кем­бридж:, штат Массачусетс).

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

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

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

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

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

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

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