Asp упрощение разработки с помощью изолирования процессов


Содержание

Методы упрощения моделей

Читайте также:

  1. I. Методы формирования сознания, методы убеждения
  2. I. Стили руководства. Методы принятия управленческих решений. Управленческая решетка Блейка — Моутона.
  3. I. Структурные методы
  4. II ПОСМЕРТНЫЕ МЕТОДЫ
  5. III) Методы управления 1 страница
  6. III) Методы управления 2 страница
  7. III) Методы управления 3 страница
  8. IV. Методы изображения действительности.
  9. IV. Методы изображения действительности.
  10. IV. Современные методы усиления фундаментов.
  11. O Понятия, методы и области применения
  12. V1. Предмет психологии. Методы психологии. История развития научной психологии

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

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

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

1) расчленение сложной системы на ряд более простых подсистем (декомпозиция);

2) выделение существенных свойств и воздействий и учет остальных в параметрической форме (метод макромоделирования);

3) линеаризация нелинейных процессов в некоторой области изменения переменных;

4) приведение систем с распределенными параметрами к системам c сосредоточенными параметрами (введение более жестких предположений и ограничений);

5) пренебрежение динамическими свойствами процессов.

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

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

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

Если дифференциальное уравнение объекта нелинейно из-за нелинейности его статической характеристики, то для линеаризации уравнения необходимо заменить нелинейную статическую характеристику y = F(x) линейной функцией y = a0 + a1x.

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

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

Дата добавления: 2015-04-24 ; Просмотров: 511 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Улучшение через упрощение

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

Исключение бюрократии

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

Типичный пример бюрократии — необязательное бумаготворчество. Менеджеры часто тратят 40–50% своего времени на чтение или написание документов. Исследования показали, что примерно 60% работы офиса идет на проверку других работ, а также на архивирование и поиск информации, иногда нужной, но чаще всего — бесполезной. Негативных результатов у такой работы много, их часто невозможно измерить. Поэтому важно провести критический анализ существующего стиля работы для минимизации всех задержек, исключения ненужных бумаг и операций, которые не добавляют ценность и не поддерживают другие процессы.

Избавиться от бюрократии можно следующим образом.

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

проводится ли инспекция этого действия и кто утвердил эту работу?

не нужны ли еще подписи?

сделано ли несколько экземпляров этого документа?

есть ли копии оформленных документов в архиве на всякий случай?

всем ли направлены копии документа?

вовлечены ли люди или отделы, которые мешают повышению эффективности и качества работы?

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

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

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

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

Действия, которые нельзя оправдать, исключаются.

Устранение излишков

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

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

Анализ добавленной ценности

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

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

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

Проблема заключается в том, что ценность продукта, выраженная в цене, по которой рынок готов ее приобрести, должна быть выше, чем производственные затраты. Таким образом, добавленная ценность — теоретическая концепция, выражающая и рыночную стоимость, и фактические материальные затраты. Величину добавленной ценности AV (added value) можно получить из формулы:

Как уже отмечалось, ценность, в этом смысле, есть результат действия большого числа субъективных факторов, таких как функциональность, престижность, совместимость с другими продуктами и т. д. Более того, ценность для потребителя не зависит от того, каковы были затраты на производство. Если бы можно было затратить на производство автомобиля марки «Мерседес» половину того, что тратится сейчас, ценность для потребителя от этого не изменилась бы.

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

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

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

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

Анализ добавленной ценности включает анализ каждого отдельного действия бизнес-процесса для определения его ценности для конечного потребителя. Задача заключается в классификации всех действий по трем указанным выше категориям, чтобы затем оптимизировать действия из категории 2 и исключать действия из категории 3. Анализ проводится методом Д. Харрингтона. Суть метода — нахождение ответов на вопросы, приведенные на схеме.

Анализ добавленной ценности

После того как все действия классифицированы, т. е. отнесены к одной из трех категорий, нужно на блок-схеме процесса раскрасить соответствующие прямоугольники разноцветными маркерами. Действия категории 1 — в зеленый цвет, категории 2 — желтый, а категории 3 — в красный. Такая раскраска дает наглядное представление о том, какая часть действий фактически связана с добавлением ценности. Как правило, полученная картина шокирует руководство организаций. Обычно только 30% материальных затрат связаны с действиями категории 1. На выполнение действий этой категории уходит менее 5% всего рабочего времени. Другой способ графического представления этой информации — диаграмма Д. Харрингтона, построенная в координатах «затраты — время цикла». Пример ее построения представлен на рис. 1. Он позволяет оценить эффект, который достигается оптимизацией действий категории 2 и исключением действий категории 3. Цель — сделать действия категории 1 основной частью бизнес-процесса с точки зрения затрат и времени.

Рис. 1. Зависимость затрат от времени цикла

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


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

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

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

большинство действий категории 3 можно исключить только с разрешения менеджмента;

инспекцию и контроль можно исключить, меняя политику и процедуры.

Результатом должно быть увеличение доли категории 1, сокращение доли категории 2 и минимизация доли категории 3. Если работа выполнена успешно, то диаграмма Д. Харрингтона в осях «затраты — время цикла» выглядит так, как показано на рис 2.

Рис. 2. Соответствующие соотношения после
завершения анализа добавленной ценности

Сокращение времени цикла

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

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

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

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

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

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

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

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

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

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

Более того, было известно, что некоторые звенья системы учета заказов работали в течение многих лет. Многие звенья дублировали друг друга. Логичным шагом было бы исключение избыточных звеньев. Для этой цели была разработана детальная блок-схема процесса и проведен анализ ее выходов. Результаты исследования оказались весьма интересными. Было обнаружено 16 практически одинаковых звеньев. В основном это были операции, где оформлялись различные версии документов по выполняемому заказу. А вот если можно было бы ввести в рассмотрение только одну версию документа, доступную сразу всем, то 13 звеньев процесса сразу можно было бы исключить. Через четыре месяца система оформления заказов была радикально перестроена таким образом, что однажды введенная информация становилась доступной всей организации. Это позволило решить две задачи: время выполнения заказа сократилось на девять дней, резко повысились точность процесса и качество его выхода.

В заключение был проведен анализ добавленной ценности. Рассматриваемый процесс уже был усовершенствован в части ускорения утверждения документации и доступности информации о заказах. Оказалось, что такой процесс имеет очень малое число действий категории 3. Доля категории 2 была немного выше, но все-таки неоправданно высокой. Эту долю можно уменьшить дальше, сокращая время, уходящее на индивидуальные действия по регистрации внутренних документов. На рис. 3 и 4 показаны диаграммы Д. Харрингтона для исходного и улучшенного процессов. Время цикла сократилось на 19 дней или на 64%, а затраты уменьшились почти на 1000 долл. на стандартный заказ.

Рис. 3. Зависимость затрат от времени цикла
для исходного процесса

Рис. 4. Зависимость затрат от времени цикла
для усовершенствованного процесса

Asp упрощение разработки с помощью изолирования процессов

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

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

Далее будут рассмотрены различные типы Подпроцессов.

Встроенный Подпроцесс (Embedded Sub-Process (Sub-Process))

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

  • Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой линией.
    • Текст, цвет, размер, а также линии, используемые для изображения Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
      • Одинарная жирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Действия Вызов (Подпроцесс).
      • Пунктирная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Событийного Подпроцесса.
      • Двойная линия в изображении границ Подпроцесса ДОЛЖНА означать использование данного графического элемента в качестве Подпроцесса Транзакции.

Подпроцесс может быть свернутым (Collapsed Sub-Process), при этом его детали скрыты (см. фигуру 10.25). Подпроцесс также может быть развернутым (Expanded Sub-Process), при этом его детали отображаются внутри Процесса, в котором данный Подпроцесс содержится (см. фигуру 10.26). В случае, если Подпроцесс является свернутым, то используется маркер, позволяющий отличить Подпроцесс от Задачи.

  • Маркер Подпроцесса ДОЛЖЕН изображаться в виде небольшого квадрата, расположенного в центре нижней части графического элемента и заключающего в себе знак «+».

Фигура 10.25 – Графический элемент Свернутый Подпроцесс

Фигура 10.26 – Графический элемент Развернутый Подпроцесс

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

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

Фигура 10.27 – Развернутый Подпроцесс, выступающий в роли «параллельного блока».

BPMN различает пять типов стандартных маркеров Свернутого Подпроцесса. Маркер Подпроцесса, изображенный на фигуре 10.25, может сочетаться с оставшимися четырьмя маркерами: Маркером Цикла (Loop Marker), Многоэкземплярным Маркером (Multiple-Instance Marker), Маркером Компенсации (Compensation Marker) и Маркером Ad Hoc (Ad-Hoc Marker). Свернутый Подпроцесс может содержать от одного до трех вышеуказанных Маркеров. Комбинации Маркеров могут быть любыми, кроме сочетания Маркеров Цикличности и Многоэкземплярного, — эти Маркеры не могут изображаться одновременно (см. фигуру 10.28).

  • Маркер Цикла ДОЛЖЕН БЫТЬ выполнен в виде небольшой стрелки, острие которой загнуто в направлении, противоположном направлению самой стрелки.
    • Маркер Цикла МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Многоэкземплярного
  • Многоэкземплярный Маркер ДОЛЖЕН БЫТЬ выполнен в виде трех параллельных вертикальных линий.
    • Многоэкземплярный Маркер МОЖЕТ сочетаться с любым другим Маркером Подпроцесса, кроме Маркера Цикла.
  • Маркер Ad Hoc ДОЛЖЕН БЫТЬ выполнен в виде тильды.
    • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.


  • Маркер Компенсации ДОЛЖЕН БЫТЬ выполнен в виде двух треугольников, повернутых влево (как кнопка перемотки назад на проигрывателе).
    • Маркер Компенсации МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.
  • Все вышеописанные Маркеры при совместном отображении ДОЛЖНЫ БЫТЬ сгруппированы и располагаться в центре нижней части графического элемента Подпроцесса.

Цикл Многоэкземплярность Компенсация Ad-Hoc Компенсация + AdHoc

Фигура 10.28 – Маркеры Свернутого Подпроцесса

Свернутый Подпроцесс в BPMN 2.0 относится к Встроенному Подпроцессу, описанному в BPMN 1.2. Повторно используемый Подпроцесс в BPMN 1.2 относится к Действию типа Вызов, описанному в BPMN2.0. Фигура 10.29 представляет собой диаграмму классов Подпроцесса.

Фигура 10.29 — Диаграмма классов элемента SubProcess

Элемент SubProcess наследует атрибуты и ассоциации элементов Activity (см. таблицу 10.3) и элемента FlowElementContainer (см. таблицу 8.45). Таблица 10.20 содержит информацию о дополнительных атрибутах элемента SubProcess.

Таблица 10.20 – Атрибуты элемента SubProcess

triggeredByEvent: boolean = false

Данный атрибут указывает на то, что данный Подпроцесс работает с Событиями.

· Значение «false» указывает на то, что Подпроцесс является стандартным.

· Значение «true» указывает на то, что Подпроцесс работает с Событиями и является причиной возникновения дополнительных ограничений.

triggeredByEvent: boolean = false

Данный атрибут обусловливает наличие списка Артефактов, хранящихся в Подпроцессе.

ReusableSubProcess (CallActivity) Повторно используемый Подпроцесс (Вызов)

Повторно используемый Подпроцесс, описанный в BPMN 1.2, относится к Действию типа Вызов, используемому для вызова предопределенного Подпроцесса.

Событийный Подпроцесс (Event Sub-Process)

Событийным Подпроцессом называется специфический Подпроцесс, используемый внутри Процесса (Подпроцесса). Такой Подпроцесс имеет атрибут triggeredByEvent с установленным значением «true».

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

  • Событийный Подпроцесс НЕ ДОЛЖЕН иметь входящих или исходящих Потоков операций.

Событийный Подпроцесс МОЖЕТ появляться (один раз или многократно) или НЕ появляться в ходе выполнения родительского Процесса. Отличие такого Подпроцесса от стандартного состоит в том, что стандартный Подпроцесс в качестве триггера использует Поток операций, а Событийный ПодпроцессСтартовое событие. Всякий раз, когда какое-то Стартовое событие запускается во время выполнения родительского Процесса, запускается и Событийный Подпроцесс.

  • Стартовое событие Событийного Подпроцесса ДОЛЖНО иметь определенный триггер.
    • Стартовое событие (EventDefinition) ДОЛЖНО БЫТЬ одного из следующих типов: Сообщение, Ошибка, Эскалация, Компенсация, Условие, Сигнал, Множественный.
  • Событийный Подпроцесс ДОЛЖЕН содержать одно или более Стартовое событие.

Такой Подпроцесс изображается в виде прямоугольника с закругленным углами (установленное в BPMN отображение графического элемента Подпроцесс).

  • Событийный Подпроцесс представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен одинарной тонкой пунктирной линией (см. фигуры 10.30 и 10.31).
    • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм». Однако следует учитывать следующее исключение:
      • Если Событийный Подпроцесс является свернутым, то Стартовое событие в таком Подпроцессе будет являться маркером и отображаться в левом верхнем углу фигуры Подпроцесса (см. фигуру 10.30).

Фигура 10.30 – Графический элемент Свернутый Событийный Подпроцесс

Фигура 10.31 – Графический элемент Развернутый Событийный Подпроцесс

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

  1. Родительский Процесс прерывается.
  2. Родительский Процесс продолжает выполняться (не прерывается).

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

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

Фигура 10.32 –Событийные Подпроцессы внутри родительского Подпроцесса

Транзакцией называется специфический тип Подпроцесса, который демонстрирует определенное поведение, контролируемое посредством протокола транзакции (например, WS-Transaction). Граница графического элемента Транзакция выполнена двойной линией (см. фигуру 10.33).

  • Транзакция представляет собой прямоугольник с закругленным углами, который ДОЛЖЕН БЫТЬ выполнен двойной тонкой линией.
    • Текст, цвет, размер, а также линии, используемые для изображения данного Подпроцесса, ДОЛЖНЫ соответствовать правилам, указанным в разделе «Использование Текста, Цвета и Линий в Моделировании Диаграмм».


Фигура 10.33 –Подпроцесс Транзакция

Фигура 10.34 – Свернутый Подпроцесс Транзакция

Элемент TransactionSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.21 содержит информацию о дополнительных атрибутах и ассоциациях элемента TransactionSub-Process.

Таблица 10.21 – Атрибуты и ассоциации элемента TransactionSub-Process

method: Transaction- Method

Данный атрибут определяет метод, используемый для совершения Транзакции или её отмены. Для выполняемых процессов данный атрибут ДОЛЖЕН содержать особый URL, например, http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, orhttp://docs.oasis-open.org/ws-tx/wsba/2006/ 06/AtomicOutcome для WS-BusinessActivity. Для сохранения совместимости с BPMN 1.1 данный атрибут также может иметь значения «##compensate», «##store» и «##image».

Использование Транзакции может привести к следующим результатам:

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

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

Илон Маск рекомендует:  text-align-last в CSS

Спонтанный Подпроцесс (Ad-Hoc Sub-Process)

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

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

  • Маркер Спонтанного Подпроцесса ДОЛЖЕН БЫТЬ выполнен в виде тильды.
    • Маркер Ad Hoc МОЖЕТ сочетаться с любым другим Маркером Подпроцесса.

Фигура 10.35 – Графический элемент Свернутый Спонтанный Подпроцесс

Фигура 10.36 – Графический элемент Развернутый Спонтанный Подпроцесс

Элемент Ad-HocSub-Process наследует атрибуты и ассоциации элемента Activity (см. таблицу 10.3) за счет взаимосвязи с Подпроцессом. Таблица 10.22 содержит информацию о дополнительных ассоциациях элемента Ad-HocSub-Process.

Таблица 10.22 – Ассоциации элемента Ad-HocSub-Process

Данный атрибут определяет условия, при которых завершается Процесс. Значение «true» указывает на то, что Процесс будет завершен.

ordering: AdHocOrdering = Parallel

Данный атрибут указывает на то, будут ли Действия, включенные в Процесс, выполняться параллельно или НЕОБХОДИМО последовательное их выполнение. Значением по умолчанию является «parallel». Значение «sequential» ограничивает одновременное выполнение нескольких Действий. В данном случае в определенный период времени может быть выполнено лишь одно Действие. Если выбрано значение «parallel», то одновременно может выполняться любое количество Действий, от нуля и более.

cancelRemaining- Instances: boolean = true

Данный атрибут используется только в том случае, если для вышеописанного атрибута ordering установлено значение «parallel». Указывает на то, будут ли отменены запущенные экземпляры Действий, если значение атрибута completionCondition становится «true».

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

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

Фигура 10.37 – Спонтанный Подпроцесс написания главы для книги

Хотя в Спонтанном Подпроцессе структура не определена, в его детали все же может быть добавлена информация о последовательности Действий или корреляции данных. К примеру, можно расширить вышеописанный Спонтанный Подпроцесс написания главы для книги путем добавления в него Объектов данных, Ассоциаций или Потоков операций (см. фигуру 10.38).

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

  • В список элементов BPMN, которые ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входит Действие.
  • В список элементов BPMN, которые МОГУТ использоваться в Спонтанном Подпроцессе, входят: Объект данных, Поток операций, Ассоциация, Ассоциация данных, Группа, Поток сообщений (может являться как целью, так и результатом), Шлюз, Промежуточное событие.
  • В список элементов BPMN, которые НЕ ДОЛЖНЫ использоваться в Спонтанном Подпроцессе, входят: Стартовое событие, Конечное событие, Переговоры (графически), Соединители переговоров (графически), Действия Хореографии.

Фигура 10.38 – Спонтанный Подпроцесс написания главы для книги с отображением последовательности Действий и зависимых данных

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

Проблемой для BPM стало отслеживание статуса Спонтанного Подпроцесса. Как правило, Процессы такого типа контролируются при помощи приложений для групповой работы (например, e-mail). BPMN позволяет моделировать Процессы, необязательные для выполнения, хотя определенные механизмы для выполнения процессов, способные отслеживать Спонтанные Подпроцессы, существуют. Исходя из этого, Спонтанный Подпроцесс будет завершен при определенных условиях, которые указываются посредством установки значения для атрибута completionCondition, определяющего, в свою очередь, атрибуты Процесса, корректируемые Действием данного Процесса.

Asp упрощение разработки с помощью изолирования процессов

Если процесс уточнения решения при переходе к все более точным моделям происходит достаточно плавно , без значительного изменения качественных особенностей решения и значений критериев, то оно должно удовлетворять ЛПР, так как ЛПР выбрало такое сочетание критериев на первом шаге, нашло решение на втором, а затем уточняло его на третьем шаге процедуры. Если же оказывается, что упрощенные модели давали неверное представление о возможностях системы (процесс упрощения был проведен недостаточно точно), то необходимо пересмотреть процедуру упрощения. [c.333]

Основной тенденцией развития баланса в нашей стране было его постоянное усложнение. В последние годы происходит обратный процесс — упрощение структуры баланса. Так, за последние три десятилетия число статей баланса уменьшилось примерно в два раза. [c.19]

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

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

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

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

В ППП подобных АБАК первое решение задачи является одновременно и процессом ее программирования. Этот единый процесс упрощенно состоит в выполнении пользователем следующих действий [c.104]

Тот, кто хорошо усвоил процесс упрощения трудовых операций, без особого труда уяснит, что лозунг обогащение труда означает поворот в развитии. Дело не в том, чтобы труд снова становился сложным, он должен стать богаче, ответственнее, интереснее, причем такие ступени менеджмента, как планирование распоряжение, организация, получение информации и ее обработка, а также контроль за этими функциями, должны быть по возможности подчинены одной инстанции. Для этого необходима новая концепция рабочих мест.-Необходимо, чтобы сотрудники справлялись с техникой, для работы с которой прежде нужны были узкие специалисты (например, работа с терминалами, диалог с банками данных и т. д.), а для этого в свою очередь необходимо, чтобы управляющие были на высоте новых задач. Следует укреплять их понимание своей новой роли. Задачи, которые им предстоит решать в новых условиях, более ответственны и требуют творчества выработка стратегических направлений развития, управление на уровне социально-политических требований. [c.175]

Основной тенденцией развития баланса в нашей стране было его постоянное усложнение. В последние годы происходит обратный процесс — упрощение структуры баланса. Так, за последние два десятилетия число статей баланса промышленного предприятия уменьшилось примерно в два раза. Кроме того, баланс унифицирован для всех отраслей. В определенном смысле продолжена прежняя практика жесткого регулирования состава и структуры отчетности (ранее унификация баланса находилась в компетенции Министерства финансов РФ и отраслевых министерств). [c.92]

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

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

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

Объясните каждый этап коммуникационного процесса по упрощенной модели, приведенной в данной главе. [c.190]

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

Привлекательно звучит основной принцип системы — производство деталей нужного типа, в нужное время и в нужном количестве. Задача системы — устранить из производства ненужные элементы, промежуточные и конечные запасы. Непрерывность производства, своевременная адаптация к изменениям спроса по количеству и ассортименту достигаются путем точных поставок и автономизации производственных операций. Точные поставки означают производство нужного вида изделий в нужном количестве и в нужное время. Автономизацию можно упрощенно раскрыть как самостоятельный контроль работника за браком. Это позволяет поддерживать точность поставок, не допускать движения дефектных изделий от предыдущего процесса к последующему, что предотвращает сбои на последнем. Эти общие черты системы, несомненно, заинтересуют опытного читателя. Каковы же ее основные элементы [c.21]

Инновационная политика. Условия, катализирующие инновационные процессы. Понятие нового товара. Виды новых товаров. Уровни разработки товара (по замыслу, в реальном исполнении, с подкреплением, упрощенный). Понятие, виды тестирования. Методы тестирования. Пробный маркетинг. [c.131]


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

Взаимоотношение между вводимыми факторами, производственным процессом и итоговым выходом продукции описывается производственной функцией. Производственная функция указывает максимальный выпуск продукции Q, который может произвести фирма при каждом отдельном сочетании факторов производства. Для упрощения предположим, что имеются два вводимых фактора труд L и капитал К. Тогда мы можем записать производствен- [c.158]

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

Нефтеперерабатывающая промышленность отличается широким ассортиментом продукции, большим числом процессов и установок, участвующих в ее выработке, и крайней сложностью их производственных взаимосвязей. В нефтепереработке многие товарные нефтепродукты получаются смешением компонентов (полуфабрикатов), прошедших целый ряд тесно взаимосвязанных процессов переработки. Себестоимость таких товарных нефтепродуктов слагается из себестоимости компонентов (полуфабрикатов), прошедших на смешение. В себестоимости готовых (товарных) нефтепродуктов, не участвующих в смешении, удельный вес полуфабрикатов своего производства также достигает 90—98%. В этих условиях для упрощения расчета можно подвергнуть разложению на калькуляционные статьи (без полуфабрикатов) всю себестоимость товарных нефтепродуктов, условно допустив, что она полностью состоит из полуфабрикатов. Погрешность такого допущения будет незначительна. Себестоимость товарных нефтепродуктов (табл. Х.З, итог гр. 8) определяют как сумму произведений натурального количества на производственную себестоимость тонны каждого нефтепродукта. [c.293]

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

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

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

Таким образом, целевая функция (2.9) вместе с ограничениями (2.11), (2.17) и (2.18) представляет собой экономико-математическую модель задачи необходимо найти такие значения темпов выполнения работ сетевой операционной модели (количества добавляемых на процессы технологических звеньев), которые обеспечивают строительство объекта в плановые сроки при минимуме затрат на передислокацию строительно-монтажных подразделений. Данная задача относится к классу нелинейных задач целочисленного программирования. Даже в упрощенном варианте организации строительства без учета сменности работ решение задачи представляет определенную трудность. [c.50]

Нарастание затрат при изготовлении деталей в механическом цехе показано на рис. 8.2. Ломаные линии обозначают нарастание затрат в процессе производства детали. Для упрощения расчета величины незавершенного производства допускается, что нарастание затрат происходит равномерно. На графике оно изображено штриховыми линиями. [c.154]

Требование а3.з.п а рац. Выполнение его связано с сокращением затрат времени на операцию. Обратимся к рис. 30. Из рисунка видно, что процесс остановки системы может протекать с линейным замедлением а3.з.ш т. е. по прямой линии абс. Однако, если в этом случае не удовлетворяется условие а3.3.п з а рац, необходимо искусственно увеличить интенсивность снижения скорости системы. Тогда при несколько упрощенном изображении тахограмма замедления примет форму ломаной линии ab . [c.65]

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

Упрощение работы — это практика анализа рабочей деятельности и систематический поиск путей улучшения работы. Успешная работа по упрощению требует не только минимальных корректив текущих процессов, но и внесения более масштабных изменений, определяющих новые пути и способы деятельности. Мы будем называть это творчеством способностью силой воображения вносить в реальность что-либо ранее не существовавшее. Цель данной главы — изучить процесс упрощения работ как инструмент менеджмента в более ширйком контексте творчества. [c.535]

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

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

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

МОДЕЛЬ ОРГАНИЗАЦИИ КАК ОТКРЫТОЙ СИСТЕМЫ. Рис. 2.3. представляет собой упрощенное изображение организации как открытой системы. На входе организация получает от окружающей среды информацию, капитал, человеческие ресурсы и материалы. Эти компоненты называются входами. В процессе преобразования организация обрабатывает эти входы, преобразуя их в продукцию или услуги. Эта [c.80]

Непрерывность потока продукции, адаптация к изменениям спроса по количеству и номенклатуре продукции достигаются с помощью двух основных принципов точно вовремя и автономизации. Эти два принципа являются столпами системы Тоёты . Точно вовремя в целом означает производство нужного вида изделий в нужном количестве и в нужное время. Автономизация может быть упрощенно обозначена как самостоятельный контроль работника за браком. Она поддерживает точную поставку продукции тем, что исключает возможность поступления дефектных деталей предшествующего производственного процесса на последующий и предотвращает сбои. [c.116]

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

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

Asp упрощение разработки с помощью изолирования процессов

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

Дата последнего изменения: 14 апреля 2011 г.

Применимо к: SharePoint Foundation 2010

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

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

В отличие от решения фермы, для песочницы позволяет администраторам семейства веб-сайтов устанавливать пользовательские решения в Microsoft SharePoint Foundation без привлечения администраторов более высокого уровня. Однако такая независимость ограничивает изолированные решения в плане развертывания, выполняемого кода и доступа к ресурсам.

Иногда вместо термина «изолированный» используется термин «пользовательский», особенно в объектной модели для системы изолированных решений. Например, пространством имен с основными API-интерфейсами для системы является Microsoft.SharePoint.UserCode , а служба, управляющая выполнением изолированных решений, называется Узел пользовательского кода SharePoint 2010 в диалоговом окне Windows Службы на интерфейсных веб-серверах. (В приложении центра администрирования она называется службой изолированного кода SharePoint Foundation). Это отражает прежнее название термина, который теперь называется «изолированным решением».

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

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

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

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

В изолированных решениях не могут развертываться определения сайтов. (Но могут развертываться функционально эквивалентные им веб-шаблоны. Дополнительные сведения см. в статье How to: Deploy a Web Template in a Sandboxed Solution .

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

Более полное описание элементов, которые могут развертываться в изолированном решении, см. в статье Что можно реализовать в изолированном решении .

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

SharePoint — это приложение ASP.NET и, как для любого приложения ASP.NET, при получении HTTP-запроса интерфейсным веб-сервером специальный драйвер, HTTP.SYS , обнаруживает запрос и перенаправляет его в пул приложений, который обрабатывает запросы для целевого веб-сайта IIS, и, следовательно, для целевого веб-приложения SharePoint. Каждый пул приложений имеет рабочий процесс IIS ( w3wp.exe ), в котором выполняется конвейер запросов для каждого запроса. (Дополнительные сведения о рабочих процессах IIS 7.0 и пулах приложений см. в статье, посвященной введению в архитектуру IIS 7 (Возможно, на английском языке)). На сервере SharePoint рабочий процесс IIS выполняется в учетной записи пула приложений. Обычно это учетная запись фермы и, следовательно, процесс имеет разрешения на чтение и запись для ресурсов SharePoint. В ферме с несколькими серверами учетная запись фермы обычно является пользователем домена. Это та же учетная запись, которая получает доступ к базам данных контента. Служба таймера SharePoint 2010 выполняется в контексте той же учетной записи.

Решения фермы выполняются в рабочем процессе IIS так же, как и любое приложение ASP.NET. Однако изолированные решения выполняются в специально ограниченной среде выполнения. Это необходимо для предотвращения замедления или сбоя работы пула приложений в случае выполнения незаконного или несовершенного кода. Таким образом, SharePoint накладывает ограничения на действия кода в изолированном решении. Критически важной частью реализации этой системы является то, что изолированные решения должны выполняться в специальном изолированном рабочем процессе ( SPUCWorkerProcess.exe ).

Когда запрос пытается обратиться к изолированному решению, диспетчер выполнения SharePoint, работающий в рабочем процессе IIS, находит изолированный рабочий процесс (или запускает его, если ни один не выполняется), в котором будет выполняться код изолированного решения. Как правило, этот изолированный рабочий процесс может быть запущен на любом сервере фермы, на котором выполняется служба изолированного кода SharePoint Foundation ( SPUCHostService.exe ). В диалоговом окне Windows Службы она называется службой узла пользовательского кода SharePoint 2010 .

Сервер, на котором выполняется служба изолированного кода SharePoint Foundation, может быть (но необязательно) интерфейсным веб-сервером, на котором выполняется рабочий процесс IIS. Используемый сервер можно задать в приложении центра администрирования: администраторы могут выбрать выполнение всех изолированных процессов в «локальном режиме», при котором все запросы изолированного решения обрабатываются на том же интерфейсном веб-сервере, на котором выполняется рабочий процесс IIS, или выбрать запуск каждого изолированного процесса диспетчером выполнения в «удаленном режиме», который иногда называют «режимом сходства». В этом режиме диспетчер выполнения осуществляет поиск сервера, на котором работает служба изолированного кода SharePoint Foundation и который уже создал в своем процессе SPUCWorkerProcess.exe домен приложения для такого же изолированного решения. (Это возможно в случае, когда это же изолированное решение уже запрашивалось ранее, например, другим пользователем в другом семействе веб-сайтов). Если соответствующий домен приложения существует, запрос будет отправлен на обработку в этот домен. Если ни на одном сервере со службой изолированного кода SharePoint Foundation нет домена приложения для изолированного решения, диспетчер выполнения назначит запрос наименее занятому из этих серверов. После этого сервер создаст необходимый домен приложения и обработает запрос изолированного решения. Независимо от используемого режима («локального» или «сходства») домен приложения в изолированном рабочем процессе остается активным после обработки запроса и используется повторно при получении другого запроса для того же изолированного решения.

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

К всему коду, выполняемому в изолированном рабочем процессе, применяются ограничения на выполнение и доступ. Существует две системы ограничений: одна применяется только к вызовам из кода изолированных решений основной сборки SharePoint Foundation, Microsoft.SharePoint.dll . Другая применяется ко всем остальным вызовам, включая вызовы других сборок SharePoint и сборок .NET Framework. В этой статье первая система называется ограничениями серверной объектной модели, а вторая — общими ограничениями. (Также существуют различные ограничения, обусловленные системой раздельной визуализации страниц, используемой в изолированных решениях. Дополнительные сведения см. в разделе Система раздельной визуализации страниц далее в этой статье).

Примечание

Эти две системы являются взаимоисключающими: общие ограничения не применяются к вызовам сборки Microsoft.SharePoint.dll .

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

Запрещающая политика разграничения доступа кода (CAS) накладывает ограничения на действия кода в изолированном рабочем процессе. Эта политика определяется в файле wss_usercode.config в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG и на нее ссылается файл web.config в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. (Изменение этого файла не поддерживается). Политика CAS накладывает следующие ограничения:

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

Код изолированного решения не может вызывать интерфейсы API Reflection Microsoft .NET Framework 3.5.

Код изолированного решения может вызывать только те сборки .NET Framework 3.5, которые имеют атрибут AllowPartiallyTrustedCallersAttribute . Это блокирует доступ примерно к 2/3 интерфейсов API .NET Framework 3.5, в том числе, например, к System.Printing . У некоторых сборок SharePoint также нет этого атрибута. Списки сборок .NET Framework, имеющих и не имеющих этот атрибут, см. в статье Сведения о доступности сборок .NET из изолированных решений . Списки сборок SharePoint, имеющих и не имеющих этот атрибут, см. в статье Доступные и недоступные сборки SharePoint из изолированных решений .

Примечание

Политика CAS делает исключение для сборок Microsoft Office со строгим именем. Таким сборкам предоставляются разрешения уровня «Полное доверие».

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

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

Маркер не дает процессу право на чтение или запись в файловую систему.


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

Маркер не дает процессу право на запись в реестр.

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

Следует помнить, что эти ограничения не применяются к вызовам интерфейсов API в сборке Microsoft.SharePoint.dll . Так, например, вызов GetLocalizedString может выполнять чтение из файлов ресурсов в файловой системе, а вызовы объектов SPList могут выполнять чтение и запись в базу данных контента, независимо от того, на каком сервере она находится. (Однако файл не может быть развернут на диск в изолированном решении, поэтому файл .resx должен быть установлен отдельно как решение фермы).

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

Ниже приведены некоторые ограничения объектной модели SharePoint, к которой можно получить доступ:

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

Недоступны почти все классы в пространстве имен Microsoft.SharePoint.WebControls , т. е. изолированное решение не может использовать большинство элементов управления ASP.NET.

Полный список классов Microsoft.SharePoint.dll , которые доступны для изолированных решений, см. в статье Программные интерфейсы Microsoft.SharePoint.dll, доступные из изолированных решений .

Реализация этого ограничения выполняется парой специально ограниченных версий сборки Microsoft.SharePoint.dll , называемых сборками оболочки, которые расположены в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies. Основное отличие этих версий от стандартной сборки Microsoft.SharePoint.dll заключается в том, что они содержат только подмножество классов и членов стандартной версии.

Одна из двух сборок оболочки загружается изолированным рабочим процессом. Другая загружается в специальный процесс прокси ( SPUCWorkerProcessProxy.exe ), который выполняется в режиме полного доверия и управляется службой изолированного кода SharePoint Foundation. Стандартная сборка Microsoft.SharePoint.dll также загружается в этот процесс прокси.

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

Когда изолированное решение вызывает допустимый интерфейс API, который содержится в сборках оболочки, первая сборка оболочки передает его второй сборке в процесс прокси с полным доверием, которая в свою очередь передает его стандартной сборке Microsoft.SharePoint.dll . Возвращаемые результаты передаются обратно в исходный вызывающий код. Это взаимодействие между процессами возможно благодаря удаленному взаимодействию .NET. Изолированный рабочий процесс и процесс прокси с полным доверием всегда запускаются вместе и действуют в паре. При сбое одного из них второй также останавливается.

В системе ограничений серверной объектной модели существует дополнительное ограничение, которое также обеспечивается сборками оболочки. Некоторые интерфейсы API SharePoint могут быть вызваны из изолированных решений, но только со специальными ограничениями на передаваемые им параметры. Эти входные ограничения обеспечивают сборки оболочки, которые гарантируют, что при их нарушении произойдет исключение. Единственным случаем такого ограничения в SharePoint Foundation 2010 являются конструкторы SPSite(String) и SPSite(Guid) . Эти конструкторы доступны для изолированных решений, но им могут передаваться только URL-адреса или идентификаторы GUID, которые ссылаются на семейство веб-сайтов, в котором установлено изолированное решение.

Примечание

Это происходит потому, что вторая сборка оболочки и стандартная сборка Microsoft.SharePoint.dll выполняются в процессе с полным доверием, к которому не применяются общие ограничения. Эти ограничения применяются в изолированном рабочем процессе.

Примечание

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

На рис. 1 показана обработка HTTP-запроса при обращении к изолированному решению.

Файлы SPUCHostService.exe , SPUCWorkerProcess.exe и SPUCWorkerProcessProxy.exe находятся в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

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

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

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

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

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

Когда клиентский компьютер запрашивает страницу SharePoint, которая содержит компонент из изолированного решения, например, развернутую в изолированном решении веб-часть, SharePoint визуализирует несколько объектов страницы. Один визуализируется в рабочем процессе Microsoft ASP.NET ( w3wp.exe ), а остальные — в изолированном рабочем процессе. Все неизолированные компоненты визуализируются на странице в рабочем процессе ASP.NET, а первый изолированный компонент — в объекте страницы в изолированном рабочем процессе. Когда страница в изолированном рабочем процессе полностью визуализируется, она объединяется с объектом страницы в процессе ASP.NET. Если на запрошенной пользователем странице имеется несколько изолированных компонентов, каждый из них визуализируется по отдельности в собственном объекте страницы в изолированном рабочем процессе. Все эти объекты страницы последовательно объединяются с объектом страницы в процессе ASP.NET.

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

Существует два основных способа обхода изолированными решениями обычных ограничений. Наиболее существенным является использование клиентского кода для доступа к ресурсам, которые недоступны из серверного кода в изолированном решении. Например, изолированное решение может содержать пользовательскую страницу сайта с кодом JavaScript, который вызывает клиентскую объектную модель JavaScript SharePoint. Кроме того, изолированное решение может содержать веб-часть, которая размещает приложение Microsoft Silverlight. Это приложение может вызывать клиентскую объектную модель Silverlight SharePoint. Ни одно из ограничений изолированных решений не применяется к клиентскому коду. Не существует ни ограничений выполнения кода, ни ограничений доступа к ресурсам, ни ограничений использования ресурсов. Дополнительные сведения см. в статье How to: Extend the Power of a Sandboxed Solution with the SharePoint Client Object Model .

Архитектура изолированных решений также позволяет использовать технологию, с помощью которой изолированное решение может вызывать пользовательские операции, выполняемые в режиме полного доверия. Для использования этой технологии необходимо разработать решение фермы, содержащее один или несколько классов, производных от SPProxyOperation . Каждый из этих классов определяет операцию, которая будет выполняться в режиме полного доверия и может вызываться из изолированных решений с помощью метода ExecuteRegisteredProxyOperation . Точнее, эти операции прокси с полным доверием выполняются в том же процессе прокси ( SPUCWorkerProcessProxy.exe ), в котором выполняется стандартная сборка Microsoft.SharePoint.dll . Операции прокси могут возвращать данные в изолированное решение.

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

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

Дополнительные сведения о разработке и вызове операций прокси с полным доверием см. в разделе Sandboxed Solutions in Partnership with Full-Trust Proxies in SharePoint 2010 и в других разделах того же узла.

SharePoint предоставляет инфраструктуру проверки решений, которую можно использовать для разработки пользовательских средств проверки решений, например, средства проверки подписи решения определенным сертификатом. Средства проверки в семействе веб-сайтов выполняются при активации изолированных решений. Активация недопустимого решения блокируется. После обновления или добавления нового средства проверки каждое активированное решение проверяется повторно при следующем выполнении. Недопустимые решения деактивируются. Дополнительные сведения о разработке пользовательских средств проверки см. в статье Solution Validation System .

Обзор процесса разработки программного обеспечения

Введение

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

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

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

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

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

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

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика».

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

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

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

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

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

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

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

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


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

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

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

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

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

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

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

Процесс разработки инвестиционного ПО

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

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

Процесс разработки встроенного ПО

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

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

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

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

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

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

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

Заключение

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

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

Упрощение деталей и сборок

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

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

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

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

Упрощенные детали

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

  • резьба;
  • массивы с большим числом элементов;
  • выдавленный текст;
  • накатка;
  • грани с очень малым радиусом (радиусы сгиба);
  • большое число скруглений.

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

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


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

  • Большое число ребер;
  • ребра, очень малые относительно остальной модели;
  • ребра со сложной кривизной.

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

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

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

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

Причины, по которым необходимо моделировать резьбу в 3D:

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

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

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

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

Упрощенные сборки

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

Есть два способа создать упрощенную сборку:

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

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

Для использования варианта с видимыми гранями не должно быть упрощенного тела, построенного с помощью инструментов моделирования. Если такое тело есть, его можно просто удалить из раздела Упрощенная сборка Навигатора.

После нажатия на кнопку Выполнить появится интерфейс Изменить результат:

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

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

Изоляция приложений IIS

Проблемы «песочницы»

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

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

Особенности изолирования

Желательно сразу предупредить руководителей предприятия о том, что идеальная изоляция приложений не достижима ни на одной из существующих платформ IIS. В частности, полная изоляция приложений в IIS 5.0 невозможна, потому что продукт не проектировался в расчете на использование «песочницы» (sandbox). Важнейшие компоненты и процессоры сценариев, такие как Cold Fusion компании Macromedia, работают в процессе inetinfo.exe, который должен выполняться в контексте учетной записи System. В таких условиях высокий уровень изоляции просто невозможен.

В IIS 6.0 Web-приложения по умолчанию запускаются в контексте безопасности встроенной учетной записи Network Service. Данный контекст — значительный шаг вперед по сравнению с учетной записью System. Благодаря одному этому улучшению IIS 6.0 — уже явно предпочтительный вариант для размещения Web-сервера. Уделив достаточное внимание деталям, можно обеспечить высокий уровень изоляции приложений на сервере IIS 6.0.

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

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

Для безопасности IIS всегда важно идентифицировать процесс, в котором выполняются приложения. Каждое приложение связано с конкретным экземпляром процесса. Например, если пользователь, зарегистрированный как Joe, запускает notepad.exe, то программа работает под управлением Joe и располагает пользовательскими правами и разрешениями Joe. Как правило, службы выполняются с правами учетной записи System, административные инструменты работают с расширенными правами учетной записи Administrator, а пользовательские программы, такие как Microsoft Office, выполняются с правами запустившего их пользователя. Во всех случаях программа связана со средой исполнения, именуемой также контекстом безопасности.

Как и другие приложения, IIS для запуска Web-приложений задействует хост-процесс (в зависимости от версии IIS). Хост-процесс оценивает системные ресурсы, используя идентификатор процесса. Например, IIS 6.0 задействует хост-процесс с именем w3wp.exe, который работает с идентификатором процесса Network Service. Однако если w3wp.exe всегда использует Network Service для доступа к файлам, то пользовательские разрешения NTFS теряют свое значение! Каждому файлу и программе требуется только разрешение Network Service для чтения, исполнения или записи (по необходимости), а любые другие разрешения излишни.

Очевидно, что такой сценарий неприемлем. Требуется более высокий уровень детализации при управлении разрешениями пользователей и групп. Для этой цели IIS не идентифицирует процессы, а представляет (impersonate) пользователя, сравнивая пользовательский маркер доступа, назначенный в ходе аутентификации, с разрешениями NTFS для файла. Таким образом, реализуются пользовательские разрешения.

Разработчики спроектировали как IIS 6.0, так и IIS 5.0 таким образом, чтобы IIS в большинстве случаев представлял пользователя, но некоторые Web-приложения обходят эту процедуру. Другими словами, программист может составить приложение, которое «обращается к себе» для доступа к системным ресурсам IIS. То есть IIS сверяет разрешения для доступа к системным ресурсам с разрешениями для экземпляра процесса, а не для учетной записи пользователя.

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

Microsoft ASP.NET — пример приложения, в котором не всегда используется представление. Для активизации представления (я рекомендую сделать это для приложений, не использующих аутентификацию на базе форм) следует выполнить действия, описанные в главе «ASP.NET Impersonation» руководства Microsoft .NET Framework Developer?s Gu >

Управлять представлением в ASP.NET можно с помощью параметра в файлах .config, однако не так легко убедиться в корректности представления в скомпилированных приложениях. Один из признаков неисправности — приложение работает, только если запущено в контексте учетной записи System. Если разработчики или поставщики настаивают на выполнении приложения в режиме Low application protection в IIS 5.0 или назначают идентификатор LocalSystem пулу приложений, в котором приложение размещено в IIS 6.0, то приложение должно потребовать привилегированного контекста. Это верный признак неполноты представления.

Другой способ определить, обращается ли приложение к файлам от имени экземпляра процесса или от имени учетной записи пользователя, — задействовать утилиту Filemon.exe компании Sysinternals. Эта бесплатная утилита показывает в реальном времени все обращения к файлам на сервере. Необходимо лишь отменить разрешения Full Control для нужного файла, запустить Filemon и обратиться к файлу, чтобы увидеть запись Access Denied в столбце результатов и имя пользователя, обратившегося к файлу. Процедура показана на экране 1.

Важно!
Экран 1. Выяснение тонкостей доступа к файлу с помощью Filemon

Идентификация процесса чрезвычайно важна для изоляции приложений. Рассмотрим два приложения — защищенное и общедоступное. Если оба приложения работают с одним экземпляром процесса, то разработчик общедоступного приложения может загрузить на сервер программу, которая переключает экземпляр процесса. В данном контексте безопасности программа, работающая в общедоступном приложении, может прочитать весь контент Web-узла из безопасного приложения и даже вызывать размещенные в нем приложения. Самая большая угроза при этом исходит от пользователей, имеющих право загружать на сервер и запускать программы, особенно двоичные исполняемые файлы. Поэтому главную опасность представляют программисты, имеющие доступ к приложениям. Взломщик извне может добиться таких же результатов, успешно проведя атаку с использованием идентификатора процесса общедоступного приложения. Типичный пример — атаки с переполнением буфера. Злоумышленник также может разместить «троянского коня» на рабочей станции программиста и получить привилегированный доступ к серверу или получить доступ методами «социальной инженерии». По этой причине приложения, которые должны работать в контексте учетной записи System или Administrator, нельзя надежно изолировать друг от друга.

В идеальном случае, решая задачу создания изолированного в «песочнице» приложения, можно применить к Web-контенту разрешения NTFS. В результате получаем экземпляры процессов, связанных с защищенным приложением, и его пользователи — единственные субъекты безопасности, имеющие доступ к контенту. Другими словами, следует убедиться, что разрешения NTFS не дают доступа к экземпляру процесса любому другому Web-приложению. Для этого необходимо знать все идентификаторы процессов, используемые IIS. В IIS 6.0 назначить защищенному приложению уникальный идентификатор достаточно просто (об этом будет рассказано в следующем разделе), а для IIS 5.0 можно руководствоваться таблицей. Таблица применима и к IIS 6.0 при работе в режиме изоляции исполняемого процесса IIS 5.0.

Изменение идентификаторов процессов

При выполнении типичного Web приложения в IIS 5.0 можно увидеть три имени процесса, каждое с собственным идентификатором. Inetinfo.exe — главный процесс, который работает в контексте процесса System. IIS использует dllhost.exe, когда приложение настроено на работу в режиме Medium или High Application Protection в IIS Manager и выполняется в контексте пользователя IWAM_servername user (создаваемого в процессе установки IIS). Приложения ASP.NET выполняются в процессе с именем aspnet_wp.exe, который использует в качестве идентификатора процесса учетную запись ASPNET.

При запуске Web-приложений в Inetinfo с идентификатором процесса System возникает проблема. В случае атаки с переполнением буфера (как было при нападениях Code Red и Nimbda), взломщик получает доступ к самым широким правам на сервере.

Microsoft не поддерживает работу inetinfo.exe в контексте учетных записей, кроме учетной записи System. Кроме того, несмотря на возможность изменить идентификатор процесса приложений ASP.NET, все приложения ASP.NET выполняются в одном экземпляре aspnet_wp.exe. Лучшее решение для IIS 5.0 — использовать Component Services для настройки идентификатора IWAM для dllhost.exe. Сделав это, необходимо изменить пароль в метабазе и для локальной учетной записи пользователя IWAM. Из-за необходимости специализированных настроек усложняются развертывание, диагностика и администрирование. В результате, а также в силу зависимости от inetinfo.exe (работающей от имени System) не рекомендуется применять IIS 5.0 для изоляции приложений в «песочницах».

Объединять идентификаторы процессов IIS 6.0 гораздо проще, чем в IIS 5.0. По умолчанию любая программа, запускаемая на сервере IIS 6.0, будет выполняться в контексте учетной записи Network Service, за исключением приложений Common Gateway Interface (CGI), которые работают в собственном контексте пользователя, вызвавшего их. Назначить уникальный идентификатор любому пулу приложений, в котором размещено Web-приложение, можно на вкладке Identity в диалоговом окне свойств пула (экран 2).

Экран 2. Диалоговое окно Properties пула приложений

Однако есть одна особенность: учетная запись Network Service — член группы, существующей только в Windows Server 2003 с установленным IIS 6.0, группы IIS_WPG. Как указывается в справочных файлах IIS 6.0, группа IIS_WPG располагает минимальным набором полномочий, необходимых для IIS, и обеспечивает удобный способ использования учетной записи определенного пользователя в качестве идентификатора, не назначая вручную разрешений этому идентификатору. Далее: «В тех случаях когда учетная запись не принадлежит к группе IIS_WPG и не имеет соответствующих разрешений, попытка запуска исполнительного процесса закончится неудачей». Эта цитата не точна и вводит в заблуждение. Идентификатор, присвоенный пулу приложений (экран 2), должен быть членом группы IIS_WPG. Это обязательное условие. Нельзя назначить учетной записи пользователя все необходимые полномочия, так как некоторые из них встроены в группу IIS_WPG и связаны с http.sys.

Это обстоятельство имеет важное значение для изоляции приложений в IIS 6.0. Следует помнить, что программист может управлять представлением. Все экземпляры процессов (пулы приложений) являются членами группы IIS_WPG, поэтому по умолчанию все Web-приложения могут обращаться к любому контенту на сервере, доступ к которому для IIS_WPG разрешен настройками NTFS.

Задача администратора здесь простая, но не очевидная: необходимо назначить уникальный экземпляр процесса каждому изолируемому приложению, сделать экземпляр членом группы IIS_WPG и предоставить уникальному экземпляру разрешения NTFS Read и Execute для контента сайта. Нельзя использовать такие группы, как Users, Everyone, Authenticated Users и IIS_WPG для назначения разрешений на Web-сайте, поскольку уникальные экземпляры процесса будут членами этих групп.

Управление разрешениями для IIS_WPG


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

Группа IIS_WPG имеет разрешения Full Control в папке IIS Temporary Compressed Files. IIS использует эту папку в тех случаях, когда в IIS Manager активизирован режим сжатия. В результате сжатия IIS записывает сжатые данные в папку IIS Temporary Compressed Files и в ответ на последующие запросы извлекает документы из кэша. Для всех Web-узлов существует только одна папка IIS Temporary Compressed Files, и в соответствии со статьей Microsoft «Using HTTP Compression for Faster Downloads» (http://www.microsoft.com/resources/ documentation/IIS/6/all/techref/en-us/iisRG_PER_26.mspx) группа IIS_WPG должна иметь разрешения Full Control для данной папки. Эта информация противоречит сведениям, приведенным в статье Microsoft «Default permissions and user rights for IIS 6.0» (http://support.microsoft.com/ kb/812614), в которой стандартными разрешениями названы List, Read и Write. В действительности группа IIS_WPG наделена разрешениями Full Control.

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

  • Не использовать сжатия. Чтобы сжатия не было, нужно удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files.
  • Использовать сжатие только для надежно защищенных сайтов. Требуется удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files и назначить разрешения Full Control уникальной учетной записи, созданной для пула приложений.
  • Использовать сжатие только для сайтов, отличных от защищенного сайта. Сделать это проще всего в папке IIS Temporary Compressed Files: запретить доступ с Full Control экземпляру процесса, назначенного пулу приложений, в котором находится защищенное приложение. В такой конфигурации сжатие могут использовать все приложения, за исключением защищенного.

Легко заметить, что группа IIS_WPG также имеет разрешения Full Control в папке \%windir%system32inetsrvASP compiled templates. В статье Microsoft «ASP Template Caching» указывается, что для этой папки группе IIS_WPG требуются только разрешения Read, Write и Delete, но в действительности группе предоставляется Full Control. Неверная информация приводится и в статье Microsoft «AspDiskTemplateCacheDirectory», в которой говорится: «Как правило, идентификаторы процессов, выполняющих Asp.dll, — учетные записи IWAM_USER и System». Данное утверждение явно относится к IIS 5.0, но не к IIS 6.0, так как IIS 6.0 по умолчанию использует запись Network Service.

К счастью, размещение компилируемых шаблонов настраивается по сайту, папке и виртуальному каталогу. В результате можно построить раздельные папки кэша шаблонов ASP, назначив им такие разрешения NTFS, что ни одно другое приложение, работающее на сайте (за исключением имеющих разрешения Administrator или System), не сможет производить чтение или запись в папке кэша шаблонов. Местоположение определяется параметром AspDiskTemplateCacheDirectory в метабазе. Можно создать этот параметр метабазы с помощью Metabase Explorer или Adsutil, а затем связать его с уникальной папкой для защищенного приложения. Разрешения Full Control следует предоставить администраторам и уникальному экземпляру процесса, назначенному защищенному пулу приложений.

При подготовке программ к изоляции в ASP.NET необходимо корректно настроить разрешения для временных файлов ASP.NET. Группе IIS_WPG предоставляются разрешения Full Control в папке \%systemroot%Microsoft.NET Frame workv1.1.4322Temporary ASP.NET Files. К счастью, указать местонахождение временных файлов ASP.NET можно для каждого приложения отдельно через элемент файла web.config, как описано в статье Microsoft «ASP.NET Settings Schema». Таким образом обеспечивается должный уровень изоляции и защиты папки.

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

С помощью утилиты cacls.exe можно вывести разрешения в текстовый файл для последующего анализа. Ниже приведен пример для стандартной установки IIS.

cacls C:inetpubwwwroot* /T > output.txt

Управление анонимным доступом

Наконец, необходимо создать уникальную учетную запись анонимного пользователя для защищенного Web-узла. Этому пользователю не нужны особые разрешения, так как все необходимые права имеются у стандартной учетной записи пользователя. Здесь важно выбрать очень надежный пароль и не следует использовать IUSR в качестве имени учетной записи — в противном случае IIS может перепутать стандартную учетную запись IUSR с учетной записью, созданной администратором.

При назначении разрешений NTFS следует помнить, что для защищенного контента нельзя использовать такие группы, как Users, Authenticated Users и Everyone, если только анонимным пользователям явно не запрещено обращаться к другим Web-узлам во всем каталоге с контентом.

Другие технологии и факторы

Задача изоляции приложений часто не ограничивается отдельным сервером IIS и распространяется на другие серверы предприятия. Детали способа доступа к сетевым ресурсам, контекст безопасности, используемые службы и механизмы аутентификации играют определенную роль в организации доступа приложения к базе данных, файл-серверу и другим сетевым устройствам. Эти вопросы выходят за рамки данной статьи, но читатели могут ознакомиться с разделами COM+ в статье «What Are COM+ Partitions» и ограниченным делегированием в статье «Kerberos Protocol Transition and Constrained Delegation» на сайте Microsoft. Кроме того, можно прочитать документ «Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0».

Методичный подход — залог успеха

Разместить приложение на IIS-сервере, максимально изолировав его от других приложений на том же сервере, — нелегкая задача. IIS 5.0 не подходит для этой цели из-за неупорядоченности экземпляров процессов и управляющих ими механизмов. IIS 6.0 — гораздо более удобная платформа. Изолировать приложения здесь проще благодаря контролю над экземпляром процесса пулов приложений и управлению разрешениями NTFS. Для изоляции и защиты любых каталогов, использующих группу IIS_WPG, требуется точность, и администратору необходимо аккуратно назначать разрешения NTFS. Однако, придерживаясь методичного подхода, можно достичь высокой степени изоляции.

Специалист по IIS 7.0 и Web-службам в Microsoft, редактор журнала Windows IT Pro. brett@iisanswers.com

Поделитесь материалом с коллегами и друзьями

Упрощение тестирования по соображениям проектирования при использовании инъекции зависимостей

Мы проводим несколько месяцев в проекте с зелеными полями, чтобы переделать логические и бизнес-уровни нашего продукта. Используя MEF (инъекция зависимостей), мы достигли высокого уровня охвата кода, и я считаю, что у нас есть довольно солидный продукт. Поскольку мы работаем над более сложной логикой, мне стало все труднее unit test.

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

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

Моя субъективная точка зрения:

  • MEF выглядит как действительно приятная плагиновая инфраструктура; он не предназначен для полноценной структуры DI. Если вам не нужны компоненты с возможностью замены, изучите полные каркасы контейнеров DI/IoC. Unity является альтернативой Microsoft.
  • Удостоверьтесь, что вы не выполняете анти-шаблон шаблона службы > . Используйте конструктор, вставляя интерфейсы, когда это возможно. Смотрите этототличный пост Марк Семанн и этот Джимми Богард. Ваше выражение о том, что вы «используете контейнер как можно больше» , вызывает озабоченность — несколько классов должны знать что-либо о контейнере.
  • Получите действительно хорошую фальшивую/изолирующую среду и научитесь ее использовать. Я люблю Moq. Попробуйте выполнить проверку состояния в тестируемой системе, а не проверку поведения на макет, когда это возможно.
  • Прочитайте Искусство тестирования устройств. Прочтите другие книги и статьи об модульном тестировании. Практика TDD. Продолжайте учиться.
  • Прочитайте Очистить код и убедитесь, что ваши классы следуют SOLID (особенно принцип единой ответственности). Длительная макетная настройка — запах кода; ваши классы, вероятно, делают слишком много. Высокий охват кода хорош, но лучшим показателем может быть циклическая сложность.
  • Не беспокойтесь о том, что ваши модульные тесты занимают больше времени, чем производственный код. Однако обрабатывайте свои тесты, например, производственный код, и удаляйте дублирование, когда вы можете сохранить читаемость и ремонтопригодность.

Вот несколько хороших ссылок о DI и хорошей практике проектирования (с точки зрения написания тестируемого кода), которые вы можете проверить (google tech conversations):

Я нашел их очень полезными с большим количеством хороших советов по тестируемому дизайну.

Как обеспечить изоляцию процессов и не сломать Windows

Содержание статьи

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

Введение, или как плохо жить без песочницы

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

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

Песочницы и особенности их реализации

Итак, антивирусы не спасают, а иногда ломают то, что уже есть. «Давайте подойдем к защите с другой стороны и будем изолировать процессы друг от друга», — сказал кто-то бесконечно умный. Действительно, здорово, когда подозрительные процессы выполняются в некоторой изолированной среде, называемой песочницей. Выполняемая в песочнице малварь не может покинуть ее пределов и навредить всей системе. Этот могло бы быть решением, однако в существующих реализациях песочниц есть нюансы.
Далее мы как раз и будем обсуждать все тонкости построения песочниц, знание которых тебе обязательно пригодится, когда понадобится выбрать средство изоляции процессов или HIPS (Host-based Intrusion Prevention System — система предотвращения вторжений для рабочих станций).

Нюанс №1, или одна песочница на всех

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

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

Как проверить, что изоляция устроена именно таким образом? Очень просто! Запусти два приложения в песочнице. Например, notepad.exe и wordpad.exe. Создай с помощью notepad.exe текстовый файл 1.txt.

Рис. 1. Создаем текстовый файл

Разумеется, данный файл будет сохранен не на рабочем столе, а в «виртуальной» директории. Попробуй открыть его Wordpad’ом (рис. 3).

Рис. 2. Похоже, для всех изолированных приложений создана одна изолированная среда Рис. 3. Файл открывается на чтение

Итак, созданный одним изолированным приложением файл можно открыть с помощью другого изолированного приложения. Скажем прямо, изоляция уже не очень. Но может, по крайней мере от записи будет какая-то защита? Меняем содержимое (рис. 4).

Рис. 4. Изменяем содержимое текстового файла

И сохраняем. А теперь попробуем открыть файл 1.txt с помощью notepad.exe. Конечно же, запустим notepad.exe в песочнице (рис. 5).

Рис. 5. Модифицированный текстовый файл

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

Нюанс №2, или недоизоляция

Да, изолируемые процессы не могут достучаться до доверенной части системы. но в большинстве реализаций только на запись. То есть они могут читать отовсюду практически без ограничений и часто имеют доступ к сети. Это сделано, видимо, для большей совместимости, но это нельзя назвать изоляцией.
Попробуй провести простенький опыт с песочницей на свой выбор. Создай директорию на жестком диске. Скажем, такую: E:\Photos . Помести в нее, например, фотографию (рис. 6).

Рис. 6. Приватная фоточка

Запусти Internet Explorer в песочнице и попробуй отправить данное изображение, скажем, на rghost.

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

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

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

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

Нюанс №3, или «а давайте сделаем еще один велосипед, это так интересно»

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Илон Маск рекомендует:  Адаптивная верстка
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL