Основные понятия проектирования программного обеспечения с помощью CASE-средств

Лекция 1. Основные понятия проектирования программного обеспечения с помощью CASE-средств Проектирование информационных систем (ИС) – логически сложная, трудоемкая и длительная работа, требующая высокой квалификации участвующих в ней специалистов. Кроме того, в процессе создания и функционирования ЭИС информационные потребности пользователей постоянно изменяются или уточняются, что еще более усложняет разработку и сопровождение таких систем. Основная доля трудозатрат при создании ИС приходится на прикладное программное обеспечение (ПО) и базы данных (БД). Производство ПО сегодня – крупнейшая отрасль мировой экономики. Информационные системы можно классифицировать по целому ряду различных признаков. В основу рассматриваемой классификации положены наиболее существенные признаки, определяющие функциональные возможности и особенности построения современных систем. В зависимости от объема решаемых задач, используемых технических средств, организации функционирования, информационные системы делятся на ряд групп (классов) (рис. 1.1). По типу хранимых данных ИС делятся на фактографические и документальные. Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции. В документальных системах информация представлена в виде документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится. Основываясь на степени автоматизации информационных процессов в системе управления фирмой, информационные системы делятся на ручные, автоматические и автоматизированные. Рис. 1.1. Классификация информационных систем Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком. В автоматических ИС все операции по переработке информации выполняются без участия человека. Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятия "информационная система". В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие. Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. (Например, ИС библиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр.) Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие. Результирующая информация управляющих ИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИС планирования производства или заказов, бухгалтерского учета.) Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных. (Например, экспертные системы.) В зависимости от сферы применения различают следующие классы ИС. Информационные системы организационного управления - предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр.). Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи. ИС управления технологическими процессами (ТП) - служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (температуры, давления, химического состава и т.п.), процедур контроля допустимости значений параметров и регулирования технологических процессов. ИС автоматизированного проектирования (САПР) - предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов. Интегрированные (корпоративные) ИС - используются для автоматизации всех функций фирмы и охватывают весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности. Для успешной реализации проекта объект проектирования (ПО ИС) должен быть, прежде всего, адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПО, обусловливающей совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы. Под моделью понимается полное описание системы ПО с определенной точки зрения. Модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. По мнению одного из авторитетнейших специалистов в области объектно-ориентированного подхода Гради Буча, моделирование является центральным звеном всей деятельности по созданию качественного ПО. Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения. Язык моделирования должен включать: элементы модели – фундаментальные концепции моделирования и их семантику; нотацию – визуальное представление элементов моделирования; руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей ПО. CASE-технология представляет собой совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Лекция 2. Жизненный цикл разработки программного обеспечения. Понятие жизненного цикла программного обеспечения (ЖЦ ПО) является одним из базовых в программной инженерии. Жизненный цикл программного обеспечения определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 "Information Technology – Software Life Cycle Processes" (ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (или программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ними документации данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения (естественно, при сохранении связей по входным данным). В соответствии со стандартом ISO/IEC12207 все процессы ЖЦ ПО разделены на три группы (рис. 2.1): • пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение); • восемь вспомогательных процессов, обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем); • четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение). Рис. 2.1. Процессы жизненного цикла программного обеспечения Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии: 1) анализ и планирование требований; 2) проектирование; 3) реализация; 4) внедрение. На стадии анализа и планирования требований пользователи осуществляют следующие действия: • определяют функции, которые должна выполнять система; • выделяют наиболее приоритетные функции, требующие проработки в первую очередь; • описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов - разработчиков. Кроме того, на данной стадии решаются следующие задачи: • ограничивается масштаб проекта; • устанавливаются временные рамки для каждой из последующих стадий; • определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.п. Результатом стадии должны быть: • список расставленных по приоритету функций будущего ПО ЭИС; • предварительные модели ПО. На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия: • более детально рассматриваются процессы системы; • при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности или неоднозначности; • устанавливаются требования разграничения доступа к данным; • определяется состав необходимой документации. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию. На стадии реализации выполняется непосредственно сама быстрая разработка приложения: • разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.); • пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки. Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям. На стадии внедрения производятся обучение пользователей, организационные изменения и параллельно с внедрением новой системы продолжается эксплуатация существующей системы (до полного внедрения новой). Методы и инструментальные средства проектирования (CASE-средства) составляют центральную часть формализованной дисциплины выполнения проекта любого ПО ИС. Метод проектирования ПО представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации. Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО. Технология проектирования ПО определяется как совокупность технологических операций проектирования (рис. 2.2) в их последовательности и взаимосвязи, приводящая к разработке проекта ПО. Рис. 2.2. Контекст технологической операции проектирования Современные технологии поставляются, как правило, в электронном виде вместе с CASE-средствами и включают библиотеки процессов, шаблонов, методов, моделей и других компонентов, предназначенных для построения ПО того класса систем, на который ориентирована технология. Электронные технологии включают также средства, которые должны обеспечивать их адаптацию для конкретных пользователей и развитие по результатам выполнения конкретных проектов. Лекция 3. Организация разработки программного обеспечения с помощью case-средств. Каноническое проектирование ИС. Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90. В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей. Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ: Стадия 1. Формирование требований к ИС. На начальной стадии проектирования выделяют следующие этапы работ: • обследование объекта и обоснование необходимости создания ИС; • формирование требований пользователей к ИС; • оформление отчета о выполненной работе и тактико-технического задания на разработку. Стадия 2. Разработка концепции ИС. • изучение объекта автоматизации; • проведение необходимых научно-исследовательских работ; • разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей; • оформление отчета и утверждение концепции. Стадия 3. Техническое задание. • разработка и утверждение технического задания на создание ИС. Стадия 4. Эскизный проект. • разработка предварительных проектных решений по системе и ее частям; • разработка эскизной документации на ИС и ее части. Стадия 5. Технический проект. • разработка проектных решений по системе и ее частям; • разработка документации на ИС и ее части; • разработка и оформление документации на поставку комплектующих изделий; • разработка заданий на проектирование в смежных частях проекта. Стадия 6. Рабочая документация. • разработка рабочей документации на ИС и ее части; • разработка и адаптация программ. Стадия 7. Ввод в действие. • подготовка объекта автоматизации; • подготовка персонала; • комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); • строительно-монтажные работы; • пусконаладочные работы; • проведение предварительных испытаний ; • проведение опытной эксплуатации ; • проведение приемочных испытаний. Стадия 8. Сопровождение ИС. • выполнение работ в соответствии с гарантийными обязательствами; • послегарантийное обслуживание. Обследование - это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для: • обоснования разработки и поэтапного внедрения систем; • составления технического задания на разработку систем; • разработки технического и рабочего проектов систем. На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации. Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями. По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения). Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить). Ориентировочное содержание этого документа: • ограничения, риски, критические факторы, которые могут повлиять на успешность проекта; • совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы; • сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации; • описание выполняемых системой функций; • возможности развития системы; • информационные объекты системы; • интерфейсы и распределение функций между человеком и системой; • требования к программным и информационным компонентам ПО, требования к СУБД; • что не будет реализовано в рамках проекта. На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены: • инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач; • возможности применения новых методов решения задач. Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах: • функции - информация о событиях и процессах, которые происходят в бизнесе; • сущности - информация о вещах, имеющих значение для организации и о которых что-то известно. При изучении каждой функциональной задачи управления определяются: • наименование задачи; сроки и периодичность ее решения; • степень формализуемости задачи; • источники информации, необходимые для решения задачи; • показатели и их количественные характеристики; • порядок корректировки информации; • действующие алгоритмы расчета показателей и возможные методы контроля; • действующие средства сбора, передачи и обработки информации; • действующие средства связи; • принятая точность решения задачи; • трудоемкость решения задачи; • действующие формы представления исходных данных и результатов их обработки в виде документов; • потребители результатной информации по задаче. Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить: • количество документов; • место формирования показателей документа; • взаимосвязь документов при их формировании; • маршрут и длительность движения документа; • место использования и хранения данного документа; • внутренние и внешние информационные связи; • объем документа в знаках. По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки. На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW. Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции. Функции первой категории обеспечивают критичные для успешной работы системы возможности. Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий. Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе. Модели деятельности организации создаются в двух видах: • модель "как есть" ("as-is")- отражает существующие в организации бизнес-процессы; • модель "как должно быть" ("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС. На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач: • получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения; • разработки плана работ по обеспечению надежности информационной системы и ее тестирования. Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования. Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking. Результаты обследования представляют объективную основу для формирования технического задания на информационную систему. Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. При разработке технического задания необходимо решить следующие задачи: • установить общую цель создания ИС, определить состав подсистем и функциональных задач; • разработать и обосновать требования, предъявляемые к подсистемам; • разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных); • установить общие требования к проектируемой системе; • определить перечень задач создания системы и исполнителей; • определить этапы создания системы и сроки их выполнения; • провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения. Таблица 3.1. Состав и содержание технического задания (ГОСТ 34.602- 89) № п\п Раздел Содержание 1 Общие сведения • полное наименование системы и ее условное обозначение • шифр темы или шифр (номер) договора; • наименование предприятий разработчика и заказчика системы, их реквизиты • перечень документов, на основании которых создается ИС • плановые сроки начала и окончания работ • сведения об источниках и порядке финансирования работ • порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств 2 Назначение и цели создания (развития) системы • вид автоматизируемой деятельности • перечень объектов, на которых предполагается использование системы • наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС 3 Характеристика объектов автоматизации • краткие сведения об объекте автоматизации • сведения об условиях эксплуатации и характеристиках окружающей среды 4 Требования к системе Требования к системе в целом: • требования к структуре и функционированию системы (перечень подсистем, уровни иерархии, степень централизации, способы информационного обмена, режимы функционирования, взаимодействие со смежными системами, перспективы развития системы) • требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки) • показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров) • требования к надежности, безопасности, эргономике, транспортабельности, эксплуатации, техническому обслуживанию и ремонту, защите и сохранности информации, защите от внешних воздействий, к патентной чистоте, по стандартизации и унификации Требования к функциям (по подсистемам): • перечень подлежащих автоматизации задач • временной регламент реализации каждой функции • требования к качеству реализации каждой функции, к форме представления выходной информации, характеристики точности, достоверности выдачи результатов • перечень и критерии отказов Требования к видам обеспечения: • математическому (состав и область применения мат. моделей и методов, типовых и разрабатываемых алгоритмов) • информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам) • лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода- вывода) • программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ) • техническому • метрологическому • организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала) • методическому (состав нормативно-технической документации) 5 Состав и содержание работ по созданию системы • перечень стадий и этапов работ • сроки исполнения • состав организаций — исполнителей работ • вид и порядок экспертизы технической документации • программа обеспечения надежности • программа метрологического обеспечения 6 Порядок контроля и приемки системы • виды, состав, объем и методы испытаний системы • общие требования к приемке работ по стадиям • статус приемной комиссии 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие • преобразование входной информации к машиночитаемому виду • изменения в объекте автоматизации • сроки и порядок комплектования и обучения персонала 8 Требования к документированию • перечень подлежащих разработке документов • перечень документов на машинных носителях 9 Источники разработки документы и информационные материалы, на основании которых разрабатывается ТЗ и система Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ. Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются: • функции ИС; • функции подсистем, их цели и ожидаемый эффект от внедрения; • состав комплексов задач и отдельных задач; • концепция информационной базы и ее укрупненная структура; • функции системы управления базой данных; • состав вычислительной системы и других технических средств; • функции и параметры основных программных средств. По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы. На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект системы - это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению. На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы. Таблица 3.2. Содержание технического проекта № п\п Раздел Содержание 1 Пояснительная записка • основания для разработки системы • перечень организаций разработчиков • краткая характеристика объекта с указанием основных технико-экономических показателей его функционирования и связей с другими объектами • краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы 2 Функциональная и организационная структура системы • обоснование выделяемых подсистем, их перечень и назначение • перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания • схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы 3 Постановка задач и алгоритмы решения • организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими задачами, характер использования результатов решения, в которых они используются) • экономико-математическая модель задачи (структурная и развернутая форма представления) • входная оперативная информация ( характеристика показателей, диапазон изменения, формы представления) • нормативно-справочная информация ( НСИ) (содержание и формы представления) • информация, хранимая для связи с другими задачами • информация, накапливаемая для последующих решений данной задачи • информация по внесению изменений ( система внесения изменений и перечень информации, подвергающейся изменениям) • алгоритм решения задачи ( последовательность этапов расчета, схема, расчетные формулы) • контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета) 4 Организация информационной базы • источники поступления информации и способы ее передачи • совокупность показателей, используемых в системе • состав документов, сроки и периодичность их поступления • основные проектные решения по организации фонда НСИ • состав НСИ, включая перечень реквизитов, их определение, диапазон изменения и перечень документов НСИ • перечень массивов НСИ, их объем, порядок и частота корректировки информации • структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда • методы хранения, поиска, внесения изменений и контроля • определение объемов и потоков информации НСИ • контрольный пример по внесению изменений в НСИ • предложения по унификации документации 5 Альбом форм документов • 6 Система математического обеспечения • обоснование структуры математического обеспечения • обоснование выбора системы программирования • перечень стандартных программ 7 Принцип построения комплекса технических средств • описание и обоснование схемы технологического процесса обработки данных • обоснование и выбор структуры комплекса технических средств и его функциональных групп • обоснование требований к разработке нестандартного оборудования • комплекс мероприятий по обеспечению надежности функционирования технических средств 8 Расчет экономической эффективности системы • сводная смета затрат, связанных с эксплуатацией систем • расчет годовой экономической эффективности, источниками которой являются оптимизация производственной структуры хозяйства (объединения), снижение себестоимости продукции за счет рационального использования производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений 9 Мероприятия по подготовке объекта к внедрению системы • перечень организационных мероприятий по совершенствованию бизнес-процессов • перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц 10 Ведомость документов Анализ и моделирование функциональной области внедрения программных систем Практика выработала ряд подходов к проведению организационного анализа, но наибольшее распространение получил инжиниринговый подход. Организационный анализ компании при таком подходе проводится по определенной схеме с помощью полной бизнес-модели компании. Компания рассматривается как целевая, открытая, социально-экономическая система, принадлежащая иерархической совокупности открытых внешних надсистем (рынок, государственные учреждения и пр.) и внутренних подсистем (отделы, цеха, бригады и пр.). Возможности компании определяются характеристиками ее структурных подразделений и организацией их взаимодействия. На рис. 3.1 представлена обобщенная схема организационного бизнес-моделирования. Построение бизнес-модели компании начинается с описания модели взаимодействия с внешней средой по закону единства и борьбы противоположностей, то есть с определения миссии компании. Рис. 3.1. Обобщенная схема организационного бизнес-моделирования Определение миссии, на наш взгляд, наиболее полно представлено в нормативном акте, определенном ISO [ISO-15704]. Под миссией понимается как деятельность организации, так и механизмы, использование которых позволяет достичь поставленных целей. Миссия является своеобразной мерой устремлений компании и, в частности, определяет рыночные претензии компании (предмет конкурентной борьбы). Определение миссии позволяет сформировать дерево целей компании - иерархические списки уточнения и детализации миссии. Дерево целей формирует дерево стратегий - иерархические списки уточнения и детализации достижения целей. При этом на корпоративном уровне разрабатываются стратегии роста, интеграции и инвестиции бизнесов. Блок бизнес-стратегий определяет продуктовые и конкурентные стратегии, а также стратегии сегментации и продвижения. Бизнес-потенциал, в свою очередь, определяет функционал компании - перечень бизнес-функций, функций менеджмента и функций обеспечения, требуемых для поддержания на регулярной основе указанных видов коммерческой деятельности. Кроме того, уточняются необходимые для этого ресурсы (материальные, человеческие, информационные) и структура компании. Построение бизнес-потенциала и функционала компании позволяет с помощью матрицы проекций определить зоны ответственности менеджмента. Матрица проекций - модель, представленная в виде матрицы, задающей систему отношений между классификаторами в любой их комбинации. Описание бизнес-потенциала, функционала и соответствующих матриц ответственности представляет собой статическое описание компании. При этом процессы, протекающие в компании пока в свернутом виде (как функции), идентифицируются, классифицируются и, что особенно важно, закрепляются за исполнителями (будущими хозяевами этих процессов). На этом этапе бизнес-моделирования формируется общепризнанный набор основополагающих внутрифирменных регламентов: • базовое Положение об организационно-функциональной структуре компании; • пакет Положений об отдельных видах деятельности (финансовой, маркетинговой и т.д.); • пакет Положений о структурных подразделениях (цехах, отделах, секторах, группах и т.п.); • должностные инструкции. Это вносит прозрачность в деятельность компании за счет четкого разграничения и документального закрепления зон ответственности менеджеров взаимодействия участников процесса, а затем (на нижнем уровне) - технология работы отдельных специалистов на своих рабочих местах. Такой подход позволяет описать деятельность компании с помощью универсального множества управленческих регистров (цели, стратегии, продукты, функции, организационные звенья и др.). Управленческие регистры по своей структуре представляют собой иерархические классификаторы. Объединяя классификаторы в функциональные группы и закрепляя между собой элементы различных классификаторов с помощью матричных проекций, можно получить полную бизнес-модель компании. При этом происходит процессно-целевое описание компании, позволяющее получить взаимосвязанные ответы на следующие вопросы: зачем-что-где-кто-как-когда-кому-сколько. Рис. 3.2. Основные этапы процессно-целевого описания компании Следовательно, полная бизнес-модель компании - это совокупность функционально ориентированных информационных моделей, обеспечивающая взаимосвязанные ответы на следующие вопросы: "зачем" - "что" - "где" - "кто" - "сколько" - "как" - "когда" - "кому". Рис. 3.3. Полная бизнес-модель компании Таким образом, организационный анализ предполагает построение комплекса взаимосвязанных информационных моделей компании, который включает: • Стратегическую модель целеполагания (отвечает на вопросы: зачем компания занимается именно этим бизнесом, почему предполагает быть конкурентоспособной, какие цели и стратегии для этого необходимо реализовать); • Организационно-функциональную модель (отвечает на вопрос кто-что делает в компании и кто за что отвечает); • Функционально-технологическую модель (отвечает на вопрос что-как реализуется в компании); • Процессно-ролевую модель (отвечает на вопрос кто-что-как-кому); • Количественную модель (отвечает на вопрос сколько необходимо ресурсов); • Модель структуры данных (отвечает на вопрос в каком виде описываются регламенты компании и объекты внешнего окружения). Представленная совокупность моделей обеспечивает необходимую полноту и точность описания компании и позволяет вырабатывать понятные требования к проектируемой информационной системе. Любая компания с ее микро- и макроокружением представляет собой иерархию вложенных друг в друга открытых, субъектно-ориентированных систем. Компания, с одной стороны, является частью рынка, а с другой отстаивает в конкурентной борьбе собственные интересы. Миссия представляет собой результат позиционирования компании среди других участников рынка. Поэтому миссию компании нельзя описывать путем анализа ее внутреннего устройства. Для построения модели взаимодействия компании с внешней средой (определение миссии компании на рынке) необходимо: • идентифицировать рынок (надсистему), частью которого является компания; • определить свойства (потребности) рынка; • определить предназначение (миссию) компании, исходя из ее роли на рынке. Кроме этого, миссия, как было сказано выше, это компромисс между потребностями рынка, с одной стороны, и возможностями и желанием компании удовлетворить эти интересы, с другой. Поиск компромисса может быть выполнен по шаблону, представленному на рис. 3.4. Рис. 3.4. Шаблон разработки миссии (матрица проекций) При разработке модели миссии компании рекомендуется: 1. Описать базис конкурентоспособности компании - совокупность характеристик компании как социально-экономической системы. Например: ◦ для объекта - уникальность освоенных технологий и исключительность имеющихся в компании ресурсов (финансовых, материальных, информационных и др.) ◦ для субъекта - знания и умения персонала и опыт менеджеров. Это определяет уникальность ресурсов и навыков компании и формирует позицию "могу". 2. Выяснить конъюнктуру рынка, т.е. определить наличие платежеспособного спроса на предлагаемые товары или услуги и степень удовлетворения рынка конкурентами. Это позволяет понять потребности рынка и сформировать позицию "надо". 3. Выявить наличие способствующих и противодействующих факторов для выбранного вида деятельности со стороны государственных институтов в области политики и экономики. 4. Оценить перспективу развития технологии в выбранной сфере деятельности. 5. Оценить возможную поддержку или противодействие общественных организаций. 6. Сопоставить результаты вышеперечисленных действий с учетом правовых, моральных, этических и др. ограничений со стороны персонала и сформировать позицию "хочу". 7. Оценить уровень возможных затрат и доходов. 8. Оценить возможность достижения приемлемого для всех сторон компромисса и сформулировать Миссию компании в соответствии с шаблоном, приведенным на рис. 3.5. Рис. 3.5. Шаблон разработки миссии Миссия в широком понимании представляет собой основную деловую концепцию компании, изложенную в виде восьми положений, определяющих взаимоотношения компании с другими субъектами: • что получит Заказчик в части удовлетворения своих потребностей; • кто, для чего и как может выступать в качестве партнера компании; • на какой основе предполагается строить отношения с конкурентами (какова, в частности, готовность пойти на временные компромиссы); • что получит собственник и акционеры от бизнеса; • что получат от бизнеса компании менеджеры; • что получит от компании персонал; • в чем может заключаться сотрудничество с общественными организациями; • как будут строиться отношения компании с государством (в частности, возможное участие в поддержке государственных программ). В соответствии с разработанной Миссией компании определяются социально значимые потребности, на удовлетворение которых направлен бизнес компании. Разработка бизнес-потенциала компании может быть выполнена по Шаблону формирования бизнесов, представленному на рис. 3.6. Рис. 3.6.  Шаблон формирования бизнесов В результате формируются базовый рынок и базовый продукт, детализация которых определяет предложения компании глазами покупателей (товарные группы) и однородные по отношению к продуктам компании группы покупателей (сегменты рынка). С помощью матричной проекции (рис. 3.7) устанавливается соответствие между сформированными товарными группами и сегментами рынка и определяется список бизнесов компании (на пересечении строк и столбцов находятся бизнесы компании). Рис. 3.7.  Шаблон формирования бизнесов (матрица проекций) На основании списка бизнесов, с помощью матричной проекции (рис. 3.8) формируется классификатор бизнес-функций компании. Рис. 3.8.  Шаблон формирования основных бизнес-функций Для формирования основных функций менеджмента компании сначала разрабатываются и утверждаются два базовых классификатора - "Компоненты менеджмента" (перечень используемых на предприятии инструментов/контуров управления) и "Этапы управленческого цикла" (технологическая цепочка операций, последовательно реализуемых менеджерами при организации работ в любом контуре управления). Далее аналогично, с помощью матрицы проекций, формируется список основных функций менеджмента. На рис. 3.9 приведены примеры классификаторов, на основании которых построена матрица - генератор основных функций менеджмента. Рис. 3.9.  Шаблон формирования основных функций менеджмента Представленные матричные проекции (рис. 3.8, рис. 3.9)) позволяют формировать функции любой степени детализации путем более подробного описания как строк, так и столбцов матрицы. Формирование зон ответственности за функционал компании выполняется с помощью матрицы организационных проекций (рис. 3.10). Рис. 3.10.  Шаблон распределения функций по организационным звеньям Матрица организационных проекций представляет собой таблицу, в строках которой расположен список исполнительных звеньев, в столбцах - список функций, выполняемых в компании. Для каждой функции определяется исполнительное звено, отвечающее за эту функцию. Заполнение такой таблицы позволяет по каждой функции найти исполняющие ее подразделения или сотрудника. Анализ заполненной таблицы позволяет увидеть "пробелы" как в исполнении функций, так и в загруженности сотрудников, а также рационально перераспределить все задачи между исполнителями и закрепить как систему в документе "Положение об организационной структуре". Положение об организационной структуре - это внутрифирменный документ, фиксирующий: продукты и услуги компании, функции, выполняемые в компании, исполнительные звенья, реализующие функции, распределение функций по звеньям. Таблица проекций функций на исполнительные звенья может иметь весьма большую размерность. В средних компаниях это, например, 500 единиц - 20 звеньев на 25 функций. В больших компаниях это может быть 5 000 единиц - 50 звеньев на 100 функций. Аналогично строится матрица коммерческой ответственности. Шаблон потокового процессного описания Шаблон потокового процессного описания приведен на рис. 3.11. Такое описание дает представление о процессе последовательного преобразования ресурсов в продукты усилиями различных исполнителей на основании соответствующих регламентов. Рис. 3.11.  Потоковая процессная модель Организационно-функциональная модель компании строится на основе функциональной схемы деятельности компании рис. 3.12. Рис. 3.12.  Функциональная схема компании На основании миссии формируются цели и стратегии компании. С их помощью определяется необходимый набор продуктов и, как следствие - требуемые ресурсы. Воспроизводство продукции происходит за счет переработки ресурсов в основном производственном цикле. Его компоненты формируют необходимые бизнес-функции для поставки ресурсов, производства продуктов и их распределения в места реализации. Для управления указанным процессом воспроизводства формируется совокупность компонентов менеджмента, которая порождает набор функций управления. Для поддержания процессов воспроизводства и управления формируются наборы соответствующих функций обеспечения (охраны, технического оснащения, профилактики и ремонта и пр.). Такой подход позволяет описать предприятие с помощью универсального множества управленческих регистров (цели, стратегии, продукты, функции, организационные звенья и пр.). Управленческие регистры представляют собой иерархические классификаторы. Объединяя классификаторы в функциональные группы и закрепляя между собой элементы различных классификаторов с помощью матричных проекций, можно получить модель организационной структуры компании. Для построения организационно-функциональной модели используется всего два типа элементарных моделей. Древовидные модели (классификаторы) - точные иерархические списки выделенных объектов управления (организационных звеньев, функций, ресурсов, в том числе исполнительных механизмов для бизнес-процессов, документов и их структуры, и т.п.). Каждый элемент классификатора может быть дополнительно охарактеризован рядом атрибутов: тип, шкала, комментарий и т.п. Фактически, классификаторы представляют собой набор управленческих регистров, содержащих, в основном, неколичественную информацию, совокупность которых задает систему координат для описания деятельности компании. Количество таких списков-классификаторов определяется целью построения модели. Матричные модели - это проекции, задающие систему отношений между классификаторами в любой их комбинации. Связи могут иметь дополнительные атрибуты (направление, название, индекс, шкала и вес). В начальной модели применяется всего несколько классификаторов предметной области: • основные группы продуктов и услуг компании; • ресурсы, потребляемые компанией в ходе своей деятельности; • функции (процессы), поддерживаемые в компании; • организационные звенья компании. В классификаторе функций обычно выделяют три базовых раздела: • основные функции - непосредственно связанные с процессом преобразования внешних ресурсов в продукцию и услуги предприятия; • функции менеджмента - или функции управления предприятием; • функции обеспечения - поддерживающие производственную, коммерческую и управленческую деятельность. Главной функцией компании является предоставление продуктов и услуг, поэтому сначала производится формальное описание, согласование и утверждение руководством предприятия перечня его бизнесов (направлений коммерческой деятельности), продукции и услуг. Из этого классификатора внешним контрагентам должно быть понятно, чем предприятие интересно рынку, а для внутренних целей - для чего нужен тот или иной функционал компании. В результате этих операций производится идентификация функционала и создается единая терминология описания функций предприятия, которая должна быть согласована всеми ведущими менеджерами. При составлении классификатора оргзвеньев важно, чтобы уровень детализации функций соответствовал уровню детализации звеньев. После формирования всех базовых классификаторов с помощью матричных проекций производится их закрепление за оргзвеньями предприятия: Процесс формирования матрицы проекций функций на оргзвенья на практике напоминает игру в крестики-нолики (рис. 3.10). По строчкам таблицы указываются подразделения, по столбцам - функции, составляющие содержание процесса управления или бизнес-процесса в данной компании. На пересечениях функций и подразделений, которые ответственны за выполнение функции, ставится крестик. Для проекций большой размерности используется механизм расстановки связей между двумя классификаторами, представленных списками. Стандартная практика построения моделей организационно-функциональной структуры компаний поддерживает два уровня детализации: 1. агрегированную модель; 2. детализированную модель. Агрегированная модель - модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3 уровней. Целью построения данной модели является предоставление информации об организационной структуре высшим руководителям компании для проведения стратегического анализа, анализа соответствия данной структуры стратегии и внешнему окружению компании. Модель может также предоставляться внешним пользователям (например, потенциальным инвесторам как иллюстрация к бизнес-плану, крупным клиентам и др.). Детализированная модель - модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем в агрегированной модели. Степень детализации в модели обусловлена конкретными потребностями компании (создание определенных организационных регламентов). Целью построения данной модели является предоставление информации о распределении функциональных обязанностей между подразделениями компании, а также об организации бизнес-процессов в компании. Построение детализированной модели позволяет создавать различные внутрифирменные регламенты: Положения об организационной структуре рис. 3.13. Ниже приведен пример описания фрагментов организационно-функциональной модели производственного предприятия рис. 3.14 и торгового предприятия рис. 3.15. Приведенные матрицы проекций являются основой для выделения бизнес-процессов предприятия и их владельцев на последующих этапах создания ИС. Рис. 3.13.  Схема создания Положения об организационно- функциональной структуре компании Рис. 4.14.  Распределение функций по подразделениям производственного предприятия Рис. 3.15.  Распределение функций по подразделениям торгового предприятия Функции подразделений производственного предприятия рассматриваются в рамках следующих функциональных областей: • корпоративное управление; • финансы; • персонал; • материальные ресурсы; • заказы; • производство; • разработка продуктов; • планирование; • снабжение/закупки; • качество; • сбыт/продажи. Распределение функций по структурным подразделениям в разрезе отдельных функциональных областей деятельности по управлению производственным предприятием представлено на рис. 3.14. Функции подразделений торгового предприятия рассматриваются в рамках иных функциональных областей (см. рис. 3.15). Лекция 4. Спецификация функциональных требований к программным системам. Разработка требований к проектируемой ИС строится на основе статического и динамичного описания компании. Статическое описание компании, рассмотренное в лекции 4, проводится на уровне функциональных моделей и включает описание бизнес-потенциала, функционала и соответствующих матриц ответственности. Дальнейшее развитие (детализация) бизнес-модели происходит на этапе динамичного описания компании на уровне процессных потоковых моделей. Процессные потоковые модели — это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. На верхнем уровне описывается логика взаимодействия участников процесса, на нижнем — технология работы отдельных специалистов на своих рабочих местах. Процессные потоковые модели отвечают на вопросы кто—что—как—кому. Современное состояние экономики характеризуется переходом от традиционной функциональной модели деятельности компании, построенной на принципах разделения труда, узкой специализации и жестких иерархических структурах, к модели процессной, основанной на интеграции работ вокруг бизнес-процессов. Главными недостатками функционального подхода являются: • разбиение технологий выполнения работы на отдельные фрагменты, иногда между собой несвязанные, которые выполняются различными структурными подразделениями; • отсутствие целостного описания технологий выполнения работы; • сложность увязывания простейших задач в технологию, производящую реальный товар или услугу; • отсутствие ответственности за конечный результат; • высокие затраты на согласование, налаживание взаимодействия, контроль и т. д.; • отсутствие ориентации на клиента. Процессный подход предполагает смещение акцентов от управления отдельными структурными элементами на управление сквозными бизнес-процессами, связывающими деятельность всех структурных элементов. Каждый деловой процесс проходит через ряд подразделений, т. е. в его выполнении участвуют специалисты различных отделов компании. Чаще всего приходится сталкиваться с ситуацией, когда собственно процессами никто не управляет, а управляют лишь подразделениями. Более того, структура компаний строится без учета возможностей оптимизации деловых процессов, обеспечивающих необходимые функции. Процессный подход позволяет устранить фрагментарность в работе, организационные и информационные разрывы, дублирование, нерациональное использование финансовых, материальных и кадровых ресурсов. Процессный подход к организации деятельности предприятия предполагает: • широкое делегирование полномочий и ответственности исполнителям; • сокращение уровней принятия решений; • сочетание принципа целевого управления с групповой организацией труда; • повышенное внимание к вопросам обеспечения качества; • автоматизация технологий выполнения бизнес-процессов. Согласно стандарту "Основные Положения и Словарь — ИСО/ОПМС 9000:2000" (п. 2.4) понятие " Процессный подход " определяется как: "Любая деятельность, или комплекс деятельности, в которой используются ресурсы для преобразования входов в выходы, может рассматриваться как процесс. Чтобы результативно функционировать, организации должны определять и управлять многочисленными взаимосвязанными и взаимодействующими процессами. Часто выход одного процесса образует непосредственно вход следующего. Систематическая идентификация и менеджмент применяемых организацией процессов, и особенно взаимодействия таких процессов, могут считаться " процессным подходом ". Основной принцип процессного подхода определяет структурирование бизнес–системы в соответствии с деятельностью и бизнес-процессами предприятия, а не в соответствии с его организационно-штатной структурой. Именно бизнес-процессы, обеспечивающие значимый для потребителя результат, представляют ценность и для специалистов, проектирующих ИС. Процессная модель компании должна строиться с учетом следующих положений: 1. Верхний уровень модели должен отражать только контекст диаграммы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром. 2. На втором уровне должны быть отражены тематически сгруппированные бизнес-процессы предприятия и их взаимосвязи. 3. Каждая из деятельностей должна быть детализирована на бизнес-процессы. 4. Детализация бизнес-процессов осуществляется посредством бизнес –функций. 5. Описание элементарной бизнес–операции осуществляется с помощью миниспецификации. Процессный подход требует комплексного изучения различных сторон жизни организации — правовых основ и правил деятельности, организационной структуры, функций и показателей результатов их исполнения, интерфейсов, ресурсного обеспечения, организационной культуры. В результате анализа создается модель деятельности "как есть". Обработка этой модели с помощью различных аналитических методов позволяет проверить, насколько деловые процессы рациональны, а также определить, является ли та или иная операция ориентированной на общественно значимый конечный результат или излишней бюрократической процедурой. В ходе анализа деловых процессов детально исследуются сферы ответственности подразделений ведомства, его руководителей и сотрудников. Это позволяет установить адреса владельцев деловых процессов, в результате чего процессы перестают быть бесхозными, создаются условия для разработки и внедрения систем стимулирования и ответственности за конечные результаты, определяются моменты и процедуры передачи ответственности. Анализ и оценка деловых процессов позволяют подойти к обоснованию стандартов их выполнения, допустимых рисков и диапазонов свободы принятия решений исполнителями, предельных нормативов затрат ресурсов на единицу эффекта. Однако чисто "процессная компания" является скорее иллюстрацией правильной организации работ. В действительности все бизнес-процессы компании протекают в рамках организационной структуры предприятия, описывающей функциональные компетентности и отношения. Управление всей текущей деятельностью компании ведется по двум направлениям — управление функциональными областями, которые поддерживают множество унифицированных бизнес-процессов, разделенных на операции, и управление интегрированными бизнес-процессами, задачей которого является маршрутизация и координация унифицированных процессов для выполнения как оперативных заказов потребителей, так и глобальных проектов самой организации (рис. 4.1). Рис. 4.1.  Схема управления деятельностью компании Фактически основной задачей организационного проектирования является выбор оптимального соотношения между эффективностью использования ресурсов и эффективностью процессов. Жесткая специализация подразделений экономит ресурсы организации, но снижает качество реализации процессов. Создание "процессных" команд, включающих собственных специалистов по всем ключевым операциям, обходится достаточно дорого, но при этом значительно сокращается время и повышается точность выполнения процесса. Иногда организации могут позволить себе выбрать этот путь, особенно в тех случаях, когда создается высокая ценность процесса, за которую потребитель согласен платить. Но, как правило, ищется какой-то компромисс на основе процессно-матричных структур. Когда компания начинает ориентироваться на процессы, исключительно важной становится роль владельцев интегрированных межфункциональных процессов, касающихся многих функциональных областей. Кроме того, новая парадигма деятельности предприятия вызывает появление большого числа процессов управления, распределенных по всему предприятию, а не сосредоточенных в специализированных организационных единицах: это системы качества, бюджетирования, маркетинга и т.п. Поэтому постановка бюджетирования как организационной, а не только финансовой задачи предполагает делегирование полномочий, т.е. власти (с которой нелегко расстаются). На более низкие уровни делегируется ответственность за принятие финансовых решений: о заключении сделки-договора, об оплате, о закупке, о скидках и отпуске в кредит и т.п. Это позволяет упростить связи между подразделениями и снизить количество уровней вертикального прохождения документов, т.е. является необходимым условием реализации классической схемы реинжиниринга. Таким образом, процессная ориентация ведет к перестройке организационной структуры, делает организационную структуру компании более "плоской", что иллюстрирует тесную связь между "вертикальным" описанием организации (как структуры распределения ответственности, полномочий и взаимоотношений) и ее "горизонтальным" описанием, как системы процессов. Основные элементы процессного подхода В рамках процессного подхода любое предприятие рассматривается как бизнес-система – система, которая представляет собой связанное множество бизнес-процессов, конечными целями которых является выпуск продукции или услуг. Под бизнес-процессом понимают совокупность различных видов деятельности, которые создают результат, имеющий ценность для потребителя. Бизнес-процесс – это цепочка работ (функций), результатом которой является какой-либо продукт или услуга. Каждый бизнес-процесс имеет свои границы и роли. В процессном подходе используются следующие ключевые роли: Владелец процесса – человек, отвечающий за ход и результаты процесса в целом. Он должен знать бизнес-процесс, следить за его выполнением и совершенствовать его эффективность. Владельцу бизнес-процесса необходимо обладать коммуникативностью, энтузиазмом, способностью влиять на людей и производить изменения. Лидер команды — работник, обладающий знаниями о бизнес-процессе и имеющий позитивные личные качества. Коммуникатор – работник, обучающий команду различным методам работы, подготавливающий совместно с лидером совещания и анализирующий их результат. Координатор процесса – работник, отвечающий за согласованную работу всех частей бизнеса и обеспечивающий связь с другими бизнес-процессами. Координатор должен обладать административными способностями и пониманием стратегических целей предприятия. Участники команды – специалисты различных уровней иерархии. Участники команды получают поддержку и методическое обеспечение от консультанта и коммуникатора, вместе с лидером проводят моделирование, анализ и оценку бизнес-процесса. Одним из основных элементов процессного подхода является команда. Существует несколько типов процессных команд: Ситуационная команда – обычно работает на постоянной основе и выполняет периодически повторяющуюся работу. Виртуальная команда – создается для разработки нового продукта или услуги. Ситуационный менеджер – высококвалифицированный специалист, способный самостоятельно выполнить до 90% объема работ. Важной задачей процессного подхода является формирование процессных команд. Подготовка и формирование команды включает: • учебные курсы; • практический тренинг по освоению методов, методик и др.; • психологическое тестирование; • тестирование рабочих навыков. Достижение определенной совокупности целей за счет выполнения бизнес-процессов называется деревом целей. Дерево целей имеет, как правило, иерархический вид. Каждая цель имеет свой вес и критерий (количественный или качественный) достижимости. Бизнес-процессы реализуют бизнес-функции предприятия. Под бизнес-функцией понимают вид деятельности предприятия. Множество бизнес-функций представляет иерархическую декомпозицию функциональной деятельности и называется деревом функций . Бизнес-функции связаны с показателями деятельности предприятия, образующими дерево показателей . На основании показателей строится система показателей оценки эффективности выполнения процессов. Владельцы процессов контролируют свои бизнес-процессы с помощью данной системы показателей. Наиболее общими показателями оценки эффективности бизнес-процессов являются: • количество производимой продукции заданного качества за определенный интервал времени; • количество потребляемой продукции; • длительность выполнения типовых операций и др. Выделение и классификация процессов При процессном описании должны решаться, как минимум, две задачи: 1. Идентификация всей системы "функциональных областей" и процессов компании и их взаимосвязей. 2. Выделение "ключевых" интегрированных процессов и их описание на потоковом уровне. Каждая деятельность компании реализуется как процесс, который имеет своего потребителя: внешнего — клиента или внутреннего — сотрудников или подразделения компании, реализующих другие процессы. На стадии системного описания процессов и выявляется значимость каждого процесса — в том числе происходит очищение от малопонятной деятельности. На этом этапе выбираются ключевые процессы для потокового описания, которое необходимо, например, для создания информационной системы предприятия. Наиболее распространены следующие четыре вида бизнес-процессов: 1. Процессы, создающие наибольшую добавленную стоимость (экономическую стоимость, которая определяется издержками компании, относимыми на продукцию). 2. Процессы, создающие наибольшую ценность для клиентов (маркетинговую стоимость за счет дифференциации продукции). 3. Процессы с наиболее интенсивным межзвенным взаимодействием, создающие транзакционные издержки. 4. Процессы, определенные стандартами ИСО 9000, как обязательные к описанию при постановке системы менеджмента качества. Важнейшим шагом при структуризации любой компании является выделение и классификация бизнес-процессов. Целесообразно основываться на следующих классах процессов: • основные; • процессы управления ; • процессы обеспечения ; • сопутствующие; • вспомогательные; • процессы развития. Рассмотрим модель деятельности компании (рис. 4.2), при описании которой используют процессы управления, основные бизнес-процессы и процессы обеспечения. Основные бизнес-процессы — это процессы, ориентированные на производство товаров и услуг, представляющие ценность для клиента и обеспечивающие получение дохода. Рис. 4.2.  Упрощенная модель деятельности компании Основные процессы образуют "жизненный цикл" продукции компании. Критериями эффективности таких процессов являются обычно качество, точность и своевременность выполнения каждого заказа. Многие потребители рассматривают увеличение качества как нечто более важное, чем уменьшение цены. Искусный продавец может получить заказ на выполнение работ в условиях конкуренции с другими фирмами, однако только качество товара или услуги определяет в большей степени, повторит ли потребитель свой заказ у этого продавца еще раз. Таких процессов, при развитой деятельности компании, может быть много. Все они описываются по производственно-коммерческим цепочкам: "первичное взаимодействие с клиентом и определение его потребностей реализация запроса (заявки, заказа, контракта и т.п.) послепродажное сопровождение и мониторинг удовлетворения потребностей". Процесс "реализации (запроса клиента)" может быть декомпозирован на следующие подпроцессы — процессы более низкого уровня: • разработка (проектирование) продукции; • закупка (товаров, материалов, комплектующих изделий); • транспортировка (закупленного); • разгрузка, приемка на склад и хранение (закупленного); • производство (со своим технологическим циклом и внутренней логистикой); • приемка на склад и хранение (готовой продукции); • отгрузка (консервация и упаковка, погрузка, доставка); • пуско-наладка; • оказание услуг (предусмотренных контрактом на поставку или имеющих самостоятельное значение) и т.п. Эти этапы цепочки также достаточно стандартны (например, в стандарте ИСО редакции 1994 г. приведены многие из этих процессов в качестве обязательных и подлежащих сертификации). Проверить, какие бизнес-цепочки существуют на предприятии, можно с помощью проекции каждого из выделенных "бизнесов, продукции и услуг" на вышеуказанный (стандартный) библиотечный классификатор жизненного или уже производственного цикла. Для оценки этапов работы с любым документом можно использовать также анализ "жизненного цикла документа", который может выглядеть следующим образом: • предоставляет исходные данные; • подготавливает, разрабатывает; • заполняет; • корректирует; • оформляет; • подписывает; • контролирует соответствие установленным требованиям; • визирует; • согласует; • утверждает; • акцентирует (принимает к сведению, использует); • хранит; • снимает копию. Здесь тоже может быть применена своя матрица-генератор, как средство проверки полноты, — идентификация цикла. Можно также воспользоваться референтными моделями деятельности аналогичных компаний — они могут сопоставляться с процессами конкурентов, лидеров отрасли, а также совершенствоваться. Процессы управления – это процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и бизнес-системы в целом. Процессы управления имеют своей целью выработку и принятие управленческого решения. Данные управленческие решения могут приниматься относительно всей организации в целом, отдельной функциональной области или отдельных процессов, например: • стратегическое управление; • организационное проектирование (структуризация); • маркетинг; • финансово-экономическое управление; • логистика и организация процессов; • менеджмент качества; • персонал. Другая возможная систематизация функций управления связана с понятием управленческого цикла и базируется на пяти исходных функциях управления: планирование, организация, распорядительство, координация, контроль. Самая распространенная ошибка — это смешение этих принципов. Для реализации процессного описания исключительно важным является то, что любая управленческая деятельность развертывается по так называемому "управленческому циклу", который включает: • сбор информации; • выработку решения; • реализацию; • учет; • контроль; • анализ; • регулирование. Например, наиболее часто встречающиеся варианты детализации: • сбор информации; • определение состава собираемой информации; • определение форм отчетности. • выработка решения; • анализ альтернатив; • подготовка вариантов решения; • принятие решения; • выработка критериев оценки; • реализация; • планирование; • организация; • мотивация; • координация; • контроль исполнения • учет результатов; • сравнение по принятым критериям; • анализ • анализ дополнительной информации; • диагностика возможных причин отклонений; • регулирование • регулирование на уровне реализации (возврат к п.3); • регулирование на уровне выработки решения (возврат к п.1,2) Каждый из этих этапов имеет своих характерных для него исполнителей — управленцев, которых можно отнести к трем основным категориям: • руководитель (ответственный за принятие и организацию выполнения решений); • специалист-аналитик (ответственный за подготовку решения и анализ отклонений); • технические исполнители (сбор информации, учет, коммуникации). Согласно некоторым подходам, в процессах управления выделяются два типа процессов, относящихся, соответственно, к двум типам менеджмента, условно обозначаемым как "менеджмент ресурсов" и "менеджмент организации", которые отличаются по объекту управления, базовым моделям и, что важно для описания процессов, — своими управленческими циклами. Тогда модель деятельности предприятия становится двухуровневой (рис. 4.3) Рис. 4.3.  Двухуровневая модель деятельности предприятия Из этой модели следует, что сами циклы ресурсного планирования нуждаются в регламентации — то есть ресурсное управление может осуществляться только по специально разработанным организационным регламентам. В основе цикла управления ресурсами лежит расчет или имитационное моделирование и контроль результатов: • выбор (или получение от системы верхнего уровня) целевого критерия оценки качества решения; • сбор информации о ресурсах предприятия или возможностях внешней среды; • просчет вариантов (с различными предположениями о возможных значениях параметров); • выбор оптимального варианта — принятие решения (= ресурсного плана); • учет результатов (и отчетность); • сравнение с принятым критерием оценки (= контроль результатов); • анализ причин отклонений и регулирование (возврат к 1, 2 или 3). В основе цикла организационного менеджмента лежит структурное или процессное моделирование и процедурный контроль: • определение состава задач (обособленных функций, операций); • выбор исполнителей (- распределение зон и степени ответственности); • проектирование процедур (последовательности и порядка исполнения); • согласование и утверждение регламента исполнения (- процесса, плана мероприятий); • отчетность об исполнении; • контроль исполнения (- процедурный контроль); • анализ причин отклонений и регулирование (возврат к 1, 2 или 3). Таким образом, на определенных шагах декомпозиции предприятию надо определить, какие стадии управленческого цикла реализуются по каждой из ранее выделенных задач управления. Это можно проверить с помощью матрицы-генератора, которая раскладывает компоненты менеджмента по этапам управленческого цикла. Процессы обеспечения – это процессы, предназначенные для жизнеобеспечения основных и сопутствующих процессов и ориентированные на поддержку их универсальных средств. Например, процесс финансового обеспечения, процесс обеспечения кадрами, процесс юридического обеспечения — это вторичные процессы. Они создают и поддерживают необходимые условия для выполнения основных функций и функций менеджмента. Клиенты обеспечивающих процессов находятся внутри компании. На верхнем уровне детализации можно выделить примерно следующие стандартные процессы обеспечения: • обеспечение производства; • техобслуживание и ремонт оборудования; • обеспечение теплоэнергоресурсами; • обслуживание и ремонт зданий и сооружений; • технологическое обеспечение; • метрологическое; • техника безопасности; • экологический контроль и т.п. • обеспечение управления; • информационное обеспечение; • обеспечение документооборота; • коммуникационное обеспечение; • юридическое обеспечение; • обеспечение безопасности; • материально-техническое обеспечение управления; • хозяйственное обеспечение; • обеспечение коммунальными услугами; • транспортное обслуживание и т.п. Для каждого из выделенных выше подпроцессов также следует определить, какой основной или управленческий процесс является потребителем этих "внутренних" услуг. Для этого существуют свои матрицы-генераторы. Их можно построить отдельно для основных процессов (рис. 4.4) и процессов управления (рис. 4.5). Рис. 4.4.  Упрощенная матрица-генератор обеспечивающих бизнес-функций Рис. 4.5.  Матрица-генератор обеспечивающих бизнес-функций Разбиение данных процессов производится по индивидуальным технологическим цепочкам. Многие из обеспечивающих процессов стандартны для всех компаний или определенных видов деятельности: промышленность, торговля, предоставление услуг и т.п. Однако, как правило, данный класс функций в меньшей степени "подвергается" потоковому процессному описанию. Большинство из них достаточно хорошо регламентируются должностными и специальными инструкциями. Референтная модель бизнес-процесса В качестве основного каркаса, объединяющего и систематизирующего все знания по бизнес-модели, можно использовать референтную модель. Референтная модель — это модель эффективного бизнес-процесса, созданная для предприятия конкретной отрасли, внедренная на практике и предназначенная для использования при разработке/реорганизации бизнес-процессов на других предприятиях. По сути, референтные модели представляют собой эталонные схемы организации бизнеса, разработанные для конкретных бизнес-процессов на основе реального опыта внедрения в различных компаниях по всему миру. Они включают в себя проверенные на практике процедуры и методы организации управления. Референтные модели позволяют предприятиям начать разработку собственных моделей на базе уже готового набора функций и процессов. Референтная модель бизнес-процесса представляет собой совокупность логически взаимосвязанных функций. Для каждой функции указывается исполнитель, входные и выходные документы или информационные объекты. Элементы (функции и документы) референтной модели бизнес-процесса содержат ссылки на соответствующие объекты ИС, а также документы и другую информацию (пользовательские инструкции, ответственных разработчиков), расположенную в репозитарии проекта. Отсюда и название — референтная модель (в переводе с английского ссылочная модель). Проведение предпроектного обследования предприятий Обследование предприятия является важным и определяющим этапом проектирования ИС. Длительность обследования обычно составляет 1-2 недели. В течение этого времени системный аналитик должен обследовать не более 2-3 видов деятельности (учет кадров, бухгалтерия, перевозки, маркетинг и др.). Сбор информации для построения полной бизнес-модели организации часто сводится к изучению документированных информационных потоков и функций подразделений, а также производится путем интервьюирования и анкетирования. К началу работ по обследованию организация обычно предоставляет комплект документов, в состав которого обычно входят: 1. Сводная информация о деятельности предприятия. 1) Информация об управленческой, финансово-экономической, производственной деятельности предприятия. 2) Сведения об учетной политике и отчетности. 2. Регулярный документооборот предприятия. 1) Реестр входящей информации. 2) Реестр внутренней информации. 3) Реестр исходящей информации. 3. Сведения об информационно–вычислительной инфраструктуре предприятия. 4. Сведения об ответственных лицах. Таблица 4.1. Реестр входящей информации (Наименование предприятия) (Наименование подразделения) Характеристики обработки документов № Наименование и назначение документа Кто обрабатывает Откуда поступает Трудоемкость Периодичность, регламент Способ получения Таблица 4.2. Реестр внутренней информации (Наименование предприятия) (Наименование подразделения) Характеристики обработки документов № Наименование и назначение документа Кто обрабатывает Кому передает Трудоемкость Периодичность, регламент Способ получения Таблица 4.3. Реестр исходящей информации (Наименование предприятия) (Наименование подразделения) Характеристики обработки документов № Наименование и назначение документа Кто обрабатывает Куда поступает Трудоемкость Периодичность, регламент Способ получения Списки вопросов для интервьюирования и анкетирования составляются по каждому обследуемому подразделению и утверждаются руководителем компании. Это делается с целью: • предотвращения доступа к конфиденциальной информации; • усиления целевой направленности обследования; • минимизации отвлечения сотрудников предприятий от выполнения должностных обязанностей. Общий перечень вопросов (с их последующей детализацией) включает следующие пункты: • основные задачи подразделений; • собираемая и регистрируемая информация; • отчетность; • взаимодействие с другими подразделениями. Анкеты для руководителей и специалистов могут содержать следующие вопросы: • Каковы (с позиций вашего подразделения) должны быть цели создания интегрированной системы управления предприятием? • Организационная структура подразделения. • Задачи подразделения. • Последовательность действий при выполнении задач. • С какими типами внешних организаций (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается? • Каким справочным материалом вы пользуетесь? • Сколько времени (в минутах) вы тратите на исполнение основных операций? На какие даты приходятся "пиковые нагрузки"? (периодичность в месяц, квартал, год и т.д.) Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.). Используемые программные продукты для автоматизации бизнес-процессов. • Какие отчеты и как часто вы готовите для руководства? Ключевые специалисты подразделения, способные ответить на любые вопросы по бизнес-процессам, применяемым в подразделении. • Характеристики удаленных объектов управления. • Документооборот на рабочем месте. Собранные таким образом данные, как правило, не охватывают всех существенных сторон организационной деятельности и обладают высокой степенью субъективности. И самое главное, что такого рода обследования не выявляют устойчивых факторов, связанных со специфическими особенностями организации, воздействовать на которые можно исключительно методами функциональной настройки организационной системы. Анализ опросов руководителей обследуемых организаций и предприятий показывает, что их представления о структуре организации, общих и локальных целях функционирования, задачах и функциях подразделений, а также подчиненности работников иногда имеют противоречивый характер. Кроме того, эти представления подчас расходятся с официально декларируемыми целями и правилами или противоречат фактической деятельности. Если структуру информационных потоков можно выявить по образцам документов и конфигурациям компьютерных сетей и баз данных, то структура реальных микропроцессов, осуществляемых персоналом в информационных контактах (в значительной мере недокументированных) остается неизвестной. Ответы на эти вопросы может дать структурно-функциональная диагностика, основанная на методах сплошной (или выборочной) фотографии рабочего времени персонала. Цель диагностики — получение достоверного знания об организации и организационных отношениях ее функциональных элементов. В связи с этим к важнейшим задачам функциональной диагностики организационных структур относятся: • классификация субъектов функционирования (категорий и групп работников); • классификация элементов процесса функционирования (действий, процедур); • классификация направлений (решаемых проблем), целей функционирования; • классификация элементов информационных потоков; • проведение обследования деятельности персонала организации; • исследование распределения (по времени и частоте) организационных характеристик: процедур, контактов персонала, направлений деятельности, элементов информационных потоков — по отдельности и в комбинациях друг с другом по категориям работников, видам процедур и их направлениям (согласно результатам и логике исследований); • выявление реальной структуры функциональных, информационных, иерархических, временных, проблемных отношений между руководителями, сотрудниками и подразделениями; • установление структуры распределения рабочего времени руководителей и персонала относительно функций, проблем и целей организации; • выявление основных технологий функционирования организации (информационных процессов, включая и недокументированные), их целеполагания в сравнении с декларируемыми целями организации; • выявление однородных по специфике деятельности, целевой ориентации и реальной подчиненности групп работников, формирование реальной модели организационной структуры и сравнение ее с декларируемой; • определение причин рассогласования декларируемой и реальной структуры организационных отношений. Сплошной "фотографией" рабочего времени называется непрерывное наблюдение и регистрация характеристик работников в процессе функционирования в течение всего рабочего дня. При этом индицируемые параметры последовательно вносятся в заранее заготовленную рабочую таблицу. Ниже представлена форма рабочей таблицы системного аналитика; Сразу по окончании процедуры обследования таблица пополняется дополнительными характеристиками: технологическая ветвь, системная функция, предмет, аспект, эмоциональный фон и др. Часть показателей, те, что помечены звездочкой, заполняются в процессе обследования, остальные — после. Содержание записей следующее: • номер (по порядку); • агент (должность обследуемого работника); • время, в течение которого выполнялась процедура; • процедура (наименование содержания совокупности элементарных действий, объединенных общностью решаемой частной задачи); • содержание (суть процедуры, которая должна быть классифицирована); • информация (направление движения информации между агентом и контрагентом); • инициатива (инициатор начала выполнения данной процедуры); • контрагент (должность работника, который находится с обследуемым в контакте); • отношение (отражающая субординацию агента и контрагента форма взаимодействия в данной процедуре); • проблема (словесная характеристика решаемой проблемы). Результаты предпроектного обследования Результатом предпроектного обследования является "Отчет об экспресс-обследовании предприятия", структура которого приведена ниже. 1. Краткое схематичное описание бизнес-процессов: ◦ управление закупками и запасами; ◦ управление производством; ◦ управление продажами; ◦ управление финансовыми ресурсами. 2. Основные требования и приоритеты автоматизации. 3. Оценка необходимых для обеспечения проекта ресурсов заказчика. 4. Оценка возможности автоматизации, предложения по созданию автоматизированной системы с оценкой примерных сроков и стоимости. Документы, входящие в отчет об обследовании, могут быть представлены в виде текстового описания или таблиц, примерная форма которых приведена ниже. № Б-П Наименование бизнес-процесса 1. Продажи: сеть, опт 2. План закупок 3. Размещение заказа на производство 4. Производство собственное 5. Закупка сырья 6. Платежи 7. Другие Операции бизнес-процесса Операция Исполнитель Как часто Входящие документы (документы-основания) Исходящий документ (составляемый документ) Описание документов бизнес-процесса Составляемый документ (исходящий документ) Операция Кто составляет (исполнитель) Как часто Документы-основания (входящие документы) Проведение предпроектного обследования позволяет решить следующие задачи: • предварительное выявление требований к будущей системе; • определение структуры организации; • определение перечня целевых функций организации; • анализ распределения функций по подразделениям и сотрудникам; • выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних информационных воздействий; • анализ существующих средств автоматизации организации. Информация, полученная в результате предпроектного обследования, анализируется с помощью методов структурного и/или объектного анализа, о которых будет сказано ниже, и используется для построения моделей деятельности организации. Модель организации предполагает построение двух видов моделей: • модели "как есть", отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению; • модели "как должно быть", отражающей представление о новых технологиях работы организации. Каждая из моделей включает в себя полную функциональную и информационную модель деятельности организации, а также модель, описывающую динамику поведения организации (в случае необходимости). Лекция 5. Методологии моделирования предметной области Структурная модель предметной области В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области. Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области. К моделям предметных областей предъявляются следующие требования: • формализация, обеспечивающая однозначное описание структуры предметной области; • понятность для заказчиков и разработчиков на основе применения графических средств отображения модели; • реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС; • обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей. Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области. Структурный аспект предполагает построение: • объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области; • функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах; • структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов; • организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах; • технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств. Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции. С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования .Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения. Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС. Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся: • время решения задач; • стоимостные затраты на обработку данных; • надежность процессов; • косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д. Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования. В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне ( спецификации требований ) и внутреннем уровне ( реализации требований ). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации. Объектная структура Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов. На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.). На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом, строится обобщенное представление структуры предметной области. Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах. Функциональная структура Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа "Заказ", который, в свою очередь, порождает документ "Накладная", сопровождающий партию отгруженного товара. Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы, и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий. На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20. На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций. На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции. Структура управления В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый бизнес-процесс. Тогда последовательность событий составляет конкретную реализацию бизнес-процесса. Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций бизнес-процессов. На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.). На концептуальном уровне устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов. На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей. Организационная структура Организационная структура представляет собой совокупность организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов. В функционально-ориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций, входящих в один тип процесса и относящихся к разным функциям управления. На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений. На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала). На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы. Техническая структура Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений. На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям. На концептуальном уровне определяются способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д. На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети. Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: "объекты-функции", "функции-события", "организационные единицы — функции ", "организационные единицы — объекты", "организационные единицы — технические средства" и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий. Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач. Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – "разделяй и властвуй" и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых "черных ящиков") и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа. Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте. Функция – совокупность операций, сгруппированных по определенному признаку. Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя. Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя. Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия. Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии. Функционально-ориентированные и объектно-ориентированные методологии описания предметной области Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные). Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе. Функциональная методика IDEF0 Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 5.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом: • верхняя сторона имеет значение "Управление" (Control); • левая сторона имеет значение "Вход" (Input); • правая сторона имеет значение "Выход" (Output); • нижняя сторона имеет значение "Механизм" (Mechanism). Рис. 5.1.  Функциональный блок Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей". Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля". Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности. Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех. Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов: • Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы: Что поступает в подразделение "на входе"? ◦ Какие функции и в какой последовательности выполняются в рамках подразделения? ◦ Кто является ответственным за выполнение каждой из функций? ◦ Чем руководствуется исполнитель при выполнении каждой из функций? ◦ Что является результатом работы подразделения (на выходе)? На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели. • Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. • Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели. Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели. Функциональная методика потоков данных Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища). Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по отгрузке продукции"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Кроме основных элементов, в состав DFD входят словари данных и миниспецификации. Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы. Процесс построения DFD начинается с создания так называемой основной диаграммы типа "звезда", на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. В случае сложного основного процесса он сразу представляется в виде декомпозиции на ряд взаимодействующих процессов. Критериями сложности в данном случае являются: наличие большого числа внешних сущностей, многофункциональность системы, ее распределенный характер. Внешние сущности выделяются по отношению к основному процессу. Для их определения необходимо выделить поставщиков и потребителей основного процесса, т.е. все объекты, которые взаимодействуют с основным процессом. На этом этапе описание взаимодействия заключается в выборе глагола, дающего представление о том, как внешняя сущность использует основной процесс или используется им. Например, основной процесс – "учет обращений граждан", внешняя сущность – "граждане", описание взаимодействия – "подает заявления и получает ответы". Этот этап является принципиально важным, поскольку именно он определяет границы моделируемой системы. Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы. На следующем шаге происходит декомпозиция основного процесса на набор взаимосвязанных процессов, обменивающихся потоками данных. Сами потоки не конкретизируются, определяется лишь характер взаимодействия. Декомпозиция завершается, когда процесс становится простым, т.е.: процесс имеет два-три входных и выходных потока; процесс может быть описан в виде преобразования входных данных в выходные; процесс может быть описан в виде последовательного алгоритма. Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные. Миниспецификация удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные; спецификация ссылается на имеющиеся элементы, не вводя новые; спецификация по возможности использует стандартные подходы и операции. После декомпозиции основного процесса для каждого подпроцесса строится аналогичная таблица внутренних событий. Следующим шагом после определения полной таблицы событий выделяются потоки данных, которыми обмениваются процессы и внешние сущности. Простейший способ их выделения заключается в анализе таблиц событий. События преобразуются в потоки данных от инициатора события к запрашиваемому процессу, а реакции – в обратный поток событий. После построения входных и выходных потоков аналогичным образом строятся внутренние потоки. Для их выделения для каждого из внутренних процессов выделяются поставщики и потребители информации. Если поставщик или потребитель информации представляет процесс сохранения или запроса информации, то вводится хранилище данных, для которого данный процесс является интерфейсом. После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены. К преимуществам методики DFD относятся: • возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы; • возможность проектирования сверху вниз, что облегчает построение модели "как должно быть"; • наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы. К недостаткам модели отнесем: необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных; отсутствие понятия времени, т.е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов). Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций. Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов: • абстрагирование; • инкапсуляция; • модульность; • иерархия; • типизация; • параллелизм; • устойчивость. Основными понятиями объектно-ориентированного подхода являются объект и класс. Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы. Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования. Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы. Объектно-ориентированный подход обладает следующими преимуществами: • Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей. • Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем. • Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира. К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны. В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции( операции, действия, работы), которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления. При функциональном подходе объектные модели данных в виде ER-диаграмм "объект — свойство — связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи. Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться. Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса. Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов). В случае наследования функций можно абстрагироваться от конкретной реализации процедур ( абстрактные типы данных ), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам ( полиморфизм ) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше. При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы. Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям. При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области. Синтетическая методика Как можно видеть из представленного обзора, каждая из рассмотренных методик позволяет решить задачу построения формального описания рабочих процедур исследуемой системы. Все методики позволяют построить модель "как есть" и "как должно быть". С другой стороны, каждая из этих методик обладает существенными недостатками. Их можно суммировать следующим образом: недостатки применения отдельной методики лежат не в области описания реальных процессов, а в неполноте методического подхода. Функциональные методики в целом лучше дают представление о существующих функциях в организации, о методах их реализации, причем чем выше степень детализации исследуемого процесса, тем лучше они позволяют описать систему. Под лучшим описанием в данном случае понимается наименьшая ошибка при попытке по полученной модели предсказать поведение реальной системы. На уровне отдельных рабочих процедур их описание практически однозначно совпадает с фактической реализацией в потоке работ. На уровне общего описания системы функциональные методики допускают значительную степень произвола в выборе общих интерфейсов системы, ее механизмов и т.д., то есть в определении границ системы. Хорошо описать систему на этом уровне позволяет объектный подход, основанный на понятии сценария использования. Ключевым является понятие о сценарии использования как о сеансе взаимодействия действующего лица с системой, в результате которого действующее лицо получает нечто, имеющее для него ценность. Использование критерия ценности для пользователя дает возможность отбросить не имеющие значения детали потоков работ и сосредоточиться на тех функциях системы, которые оправдывают ее существование. Однако и в этом случае задача определения границ системы, выделения внешних пользователей является сложной. Технология потоков данных, исторически возникшая первой, легко решает проблему границ системы, поскольку позволяет за счет анализа информационных потоков выделить внешние сущности и определить основной внутренний процесс. Однако отсутствие выделенных управляющих процессов, потоков и событийной ориентированности не позволяет предложить эту методику в качестве единственной. Наилучшим способом преодоления недостатков рассмотренных методик является формирование синтетической методики, объединяющей различные этапы отдельных методик. При этом из каждой методики необходимо взять часть методологии, наиболее полно и формально изложенную, и обеспечить возможность обмена результатами на различных этапах применения синергетической методики. В бизнес-моделировании неявным образом идет формирование подобной синергетической методики. Идея синтетической методики заключается в последовательном применении функционального и объектного подхода с учетом возможности реинжиниринга существующей ситуации. Рассмотрим применение синтетической методики на примере разработки административного регламента. При построении административных регламентов выделяются следующие стадии: 1. Определение границ системы. На этой стадии при помощи анализа потоков данных выделяют внешние сущности и собственно моделируемую систему. 2. Выделение сценариев использования системы. На этой стадии при помощи критерия полезности строят для каждой внешней сущности набор сценариев использования системы. 3. Добавление системных сценариев использования. На этой стадии определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей. 4. Построение диаграммы активностей по сценариям использования. На этой стадии строят набор действий системы, приводящих к реализации сценариев использования; 5. Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0. Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций ). Лекция 6. Унифицированный процесс разработки. Рациональный унифицированный процесс разработки программного обеспечения (RUP – Rational Unified Process) является частным случае унифицированного процесса (UP – Unified Process). В основу рационального унифицированного процесса положена итеративная разработка программного обеспечения. RUP является примером так называемого "тяжелого" процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр. Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять. Многочисленные вспомогательные действия дают надежду сделать возможным успешное решение задач по конструированию и поддержке сложных систем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами. Для достижения этого выполняется иерархическое пошаговое детальное описание предпринимаемых в той или иной ситуации действий, чтобы можно было научить обычного работника действовать аналогичным образом. В ходе проекта создается много промежуточных документов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачи на более простые. Эти же документы служат для проверки правильности решений, принимаемых на каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов, необходимых для получения желаемых результатов. RUP основан на трех ключевых идеях: • Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантов использования (use cases) — сценариев взаимодействия результирующей программной системы с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации. • Основным решением, принимаемым в ходе проекта, является архитектура результирующей программной системы. Архитектура устанавливает набор компонентов, из которых будет построено ПО, ответственность каждого из компонентов (т.е. решаемые им подзадачи в рамках общих задач системы), четко определяет интерфейсы, через которые они могут взаимодействовать, а также способы взаимодействия компонентов друг с другом. Архитектура является одновременно основой для получения качественного ПО и базой для планирования работ и оценок проекта в терминах времени и ресурсов, необходимых для достижения определенных результатов. Она оформляется в виде набора графических моделей на языке UML. • Основой процесса разработки являются планируемые и управляемые итерации, объем которых (реализуемая в рамках итерации функциональность и набор компонентов) определяется на основе архитектуры. RUP выделяет в жизненном цикле 4 основные фазы, в рамках каждой из которых возможно проведение нескольких итераций. Кроме того, разработка системы может пройти через несколько циклов, включающих все 4 фазы. 1. Фаза начала проекта (Inception) Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла. Рис. 6.1. Пример хода работ на фазе начала проекта 2. Фаза проектирования (Elaboration) Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла. Рис. 6.2. Пример хода работ на фазе проектирования 3. Фаза построения (Construction) Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла. Рис. 6.3. Пример хода работ на фазе построения 4. Фаза внедрения (Transition) Цель этой фазы — сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла. Рис. 6.4. Пример хода работ на фазе внедрения Артефакты, вырабатываемые в ходе проекта, могут быть представлены в виде баз данных и таблиц с информацией различного типа, разных видов документов, исходного кода и объектных модулей, а также моделей, состоящих из отдельных элементов. Основные артефакты и потоки данных между ними согласно RUP изображены на рис. 6.5. Рис. 6.5. Основные артефакты проекта по RUP и потоки данных между ними Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающие различные аспекты будущей системы. Большинство моделей представляют собой наборы диаграмм UML. Основные используемые виды моделей следующие: 1. Модель вариантов использования (Use-Case Model). Эта модель определяет требования к ПО – то, что система должна делать – в виде набора вариантов использования. Каждый вариант использования задает сценарий взаимодействия системы с действующими лицами (actors) или ролями, дающий в итоге значимый для них результат. Действующими лицами могут быть не только люди, но и другие системы, взаимодействующие с рассматриваемой. Вариант использования определяет основной ход событий, развивающийся в нормальной ситуации, а также может включать несколько альтернативных сценариев, которые начинают работать только при специфических условиях. Модель вариантов использования служит основой для проектирования и оценки готовности системы к внедрению. 2. Модель анализа (Analysis Model). Она включает основные классы, необходимые для реализации выделенных вариантов использования, а также возможные связи между классами. Выделяемые классы разбиваются на три разновидности – интерфейсные, управляющие и классы данных. Эти классы представляют собой набор сущностей, в терминах которых работа системы должна представляться пользователям. Они являются понятиями, с помощью которых достаточно удобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь в детали. Интерфейсные классы (boundary classes) соответствуют устройствам или способам обмена данными между системой и ее окружением, в том числе пользователями. Классы данных (entity classes) соответствуют наборам данных, описывающих некоторые однотипные сущности внутри системы. Эти сущности являются абстракциями представлений пользователей о данных, с которыми работает система. Управляющие классы (control classes) соответствуют алгоритмам, реализующим какие-то значимые преобразования данных в системе и управляющим обменом данными с ее окружением в рамках вариантов использования. 3. Модель проектирования (Design Model) Модель проектирования является детализацией и специализацией модели анализа. Она также состоит из классов, но более четко определенных, с более точным и детальным распределением обязанностей, чем классы модели анализа. Классы модели проектирования должны быть специализированы для конкретной используемой платформы. Каждая такая платформа может включать: операционные системы всех вовлеченных машин; используемые языки программирования; интерфейсы и классы конкретных компонентных сред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использования систем управления базами данных, СУБД, например, Oracle или MS SQL Server; используемые библиотеки разработки пользовательского интерфейса, такие как swing или swt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр. 4. Модель реализации (Implementation Model). Под моделью реализации в рамках RUP и UML понимают набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки – минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть поставлен отдельно от него. Часто компоненты представляют собой отдельные файлы с исходным кодом. 5. Модель развертывания (Deployment Model) Модель развертывания представляет собой набор узлов системы, являющихся физически отдельными устройствами, которые способны обрабатывать информацию – серверами, рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними, образованными различного рода сетевыми соединениями. Каждый узел может быть нагружен некоторым множеством компонентов, определенных в модели реализации. Цель построения модели развертывания – определить физическое положение компонентов распределенной системы, обеспечивающее выполнение ею нужных функций в тех местах, где эти функции будут доступны и удобны для пользователей. 6. Модель тестирования (Test Model или Test Suite) В рамках этой модели определяются тестовые варианты или тестовые примеры (test cases) и тестовые процедуры (test scripts). Первые являются определенными сценариями работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования. Тестовый вариант включает, помимо входных данных на каждом шаге, где они могут быть введены, условия выполнения отдельных шагов и корректные ответы системы для всякого шага, на котором ответ системы можно наблюдать. В отличие от вариантов использования, в тестовых вариантах четко определены входные данные, и, соответственно, тестовый вариант либо вообще не имеет альтернативных сценариев, либо предусматривает альтернативный порядок действий в том случае, если система может вести себя недетерминированно и выдавать разные результаты в ответ на одни и те же действия. Все другие альтернативы обычно заканчиваются вынесением вердикта о некорректной работе системы. Тестовая процедура представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок). Это может быть инструкция по ручному выполнению входящих в тестовый вариант действий или программный компонент, автоматизирующий запуск тестов. RUP также определяет дисциплины, включающие различные наборы деятельностей, которые в разных комбинациях и с разной интенсивностью выполняются на разных фазах. В документации по процессу каждая дисциплина сопровождается довольно большой диаграммой, поясняющей действия, которые нужно выполнить в ходе работ в рамках данной дисциплины, артефакты, с которыми надо иметь дело, и роли вовлеченных в эти действия лиц. 7. Моделирование предметной области (бизнес-моделирование, Business Modeling) Задачи этой деятельности — понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. 8. Определение требований (Requirements) Задачи – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. 9. Анализ и проектирование (Analysis and Design) Задачи – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания. 10. Реализация (Implementation) Задачи – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. 11. Тестирование (Test) Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям. 12. Развертывание (Deployment) Задачи – установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. 13. Управление конфигурациями и изменениями (Configuration and Change Management) Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. 14. Управление проектом (Project Management) Задачи – планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. 15. Управление средой проекта (Environment) Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. Первые пять дисциплин считаются рабочими, остальные – поддерживающими. Распределение объемов работ по дисциплинам в ходе проекта выглядит, согласно руководству по RUP, примерно так, как показано на рис. 6.6. Рис. 6.6. Распределение работ между различными дисциплинами в проекте по RUP Техники, используемые в RUP: • Выработка концепции проекта (project vision) в его начале для четкой постановки задач. • Управление по плану. • Снижение рисков и отслеживание их последствий, как можно более раннее начало работ по преодолению рисков. • Тщательное экономическое обоснование всех действий — делается только то, что нужно заказчику и не приводит к невыгодности проекта. • Как можно более раннее формирование базовой архитектуры. • Использование компонентной архитектуры. • Прототипирование, инкрементная разработка и тестирование. • Регулярные оценки текущего состояния. • Управление изменениями, постоянная отработка изменений извне проекта. • Нацеленность на создание продукта, работоспособного в реальном окружении. • Нацеленность на качество. • Адаптация процесса под нужды проекта. Лекция 7. Архитектура программного обеспечения. Под архитектурой ПО понимают набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов. Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает. Обычно при разработке ПО термин "компонент" имеет несколько другой, более узкий смысл — это единица развертывания, самая маленькая часть системы, которую можно включить или не включить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет некоторому набору правил, называемому компонентной моделью. Там, где возможны недоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции до обсуждения UML мы будем использовать преимущественно широкое понимание этого термина, а дальше – наоборот, узкое. В определении архитектуры упоминается набор структур, а не одна структура. Это означает, что в качестве различных аспектов архитектуры, различных взглядов на нее выделяются различные структуры, соответствующие разным аспектам взаимодействия компонентов. Примеры таких аспектов — описание типов компонентов и типов статических связей между ними при помощи диаграмм классов, описание композиции компонентов при помощи структур ссылающихся друг на друга объектов, описание поведения компонентов при помощи моделирования их как набора взаимодействующих, передающих друг другу некоторые события, конечных автоматов. Архитектура программной системы похожа на набор карт некоторой территории. Карты имеют разные масштабы, на них показаны разные элементы (административно-политическое деление, рельеф и тип местности – лес, степь, пустыня, болота и пр., экономическая деятельность и связи), но они объединяются тем, что все представленные на них сведения соотносятся с географическим положением. Точно так же архитектура ПО представляет собой набор структур или представлений, имеющих различные уровни абстракции и показывающих разные аспекты (структуру классов ПО, структуру развертывания, т.е. привязки компонентов ПО к физическим машинам, возможные сценарии взаимодействий компонентов и пр.), объединяемых сопоставлением всех представленных данных со структурными элементами ПО. При этом уровень абстракции данного представления является аналогом масштаба географической карты. Архитектура определяет большинство характеристик качества ПО в целом. Архитектура служит также основным средством общения между разработчиками, а также между разработчиками и всеми остальными лицами, заинтересованными в данном ПО. Выбор архитектуры задает способ реализации требований на высоком уровне абстракции. Именно архитектура почти полностью определяет такие характеристики ПО как надежность, переносимость и удобство сопровождения. Она также значительно влияет на удобство использования и эффективность ПО, которые, однако, сильно зависят и от реализации отдельных компонентов. Значительно меньше влияние архитектуры на функциональность – обычно заданную функциональность можно реализовать, использовав совершенно различные архитектуры. Поэтому выбор между той или иной архитектурой определяется в большей степени именно нефункциональными требованиями и необходимыми свойствами ПО с точки зрения удобства сопровождения и переносимости. При этом для построения хорошей архитектуры надо учитывать возможные противоречия между требованиями к различным характеристикам и уметь выбирать компромиссные решения, дающие приемлемые значения по всем показателям. Так, для повышения эффективности в общем случае выгоднее использовать монолитные архитектуры, в которых выделено небольшое число компонентов (в пределе – единственный компонент). Этим обеспечивается экономия как памяти, поскольку каждый компонент обычно имеет свои данные, а здесь число компонентов минимально, так и времени работы, поскольку возможность оптимизировать работу алгоритмов обработки данных имеется также только в рамках одного компонента. С другой стороны, для повышения удобства сопровождения, наоборот, лучше разбить систему на большое число отдельных маленьких компонентов, с тем чтобы каждый из них решал свою небольшую, но четко определенную часть общей задачи. При этом, если возникают изменения в требованиях или проекте, их обычно можно свести к изменению в постановке одной, реже двух или трех таких подзадач и, соответственно, изменять только отвечающие за решение этих подзадач компоненты. С третьей стороны, для повышения надежности лучше использовать либо небольшой набор простых компонентов, либо дублирование функций, т.е. сделать несколько компонентов ответственными за решение одной подзадачи. Заметим, однако, что ошибки в ПО чаще всего носят неслучайный характер. Они повторяемы, в отличие от аппаратного обеспечения, где ошибки связаны часто со случайными изменениями характеристик среды и могут быть преодолены простым дублированием компонентов без изменения их внутренней реализации. Поэтому при таком обеспечении надежности надо использовать достаточно сильно отличающиеся способы решения одной и той же задачи в разных компонентах. Другим примером противоречивых требований служат характеристики удобства использования и защищенности. Чем сильнее защищена система, тем больше проверок, процедур идентификации и пр. нужно проходить пользователям. Соответственно, тем менее удобна для них работа с такой системой. При разработке реальных систем приходится искать некоторый разумный компромисс, чтобы сделать систему достаточно защищенной и способной поставить ощутимую преграду для несанкционированного доступа к ее данным и, в то же время, не отпугнуть пользователей сложностью работы с ней. Разработка и оценка архитектуры на основе сценариев При проектировании архитектуры системы на основе требований, зафиксированных в виде вариантов использования, первые возможные шаги состоят в следующем. 1. Выделение компонентов ◦ Выбирается набор "основных" сценариев использования — наиболее существенных и выполняемых чаще других. ◦ Исходя из опыта проектировщиков, выбранного архитектурного стиля и требований к переносимости и удобству сопровождения системы определяются компоненты, отвечающие за определенные действия в рамках этих сценариев, т.е. за решение определенных подзадач. ◦ Каждый сценарий использования системы представляется в виде последовательности обмена сообщениями между полученными компонентами. ◦ При возникновении дополнительных хорошо выделенных подзадач добавляются новые компоненты, и сценарии уточняются. 2. Определение интерфейсов компонентов ◦ Для каждого компонента в результате выделяется его интерфейс – набор сообщений, которые он принимает от других компонентов и посылает им. ◦ Рассматриваются "неосновные" сценарии, которые так же разбиваются на последовательности обмена сообщениями с использованием, по возможности, уже определенных интерфейсов. ◦ Если интерфейсы недостаточны, они расширяются. ◦ Если интерфейс компонента слишком велик, или компонент отвечает за слишком многое, он разбивается на более мелкие. 3. Уточнение набора компонентов ◦ Там, где это необходимо в силу требований эффективности или удобства сопровождения, несколько компонентов могут быть объединены в один. ◦ Там, где это необходимо для удобства сопровождения или надежности, один компонент может быть разделен на несколько. 4. Достижение нужных свойств. Все это делается до тех пор, пока не выполнятся следующие условия: ◦ Все сценарии использования реализуются в виде последовательностей обмена сообщениями между компонентами в рамках их интерфейсов. ◦ Набор компонентов достаточен для обеспечения всей нужной функциональности, удобен для сопровождения или портирования на другие платформы и не вызывает заметных проблем производительности. ◦ Каждый компонент имеет небольшой и четко очерченный круг решаемых задач и строго определенный, сбалансированный по размеру интерфейс. На основе возможных сценариев использования или модификации системы возможен также анализ характеристик архитектуры и оценка ее пригодности для поставленных задач или сравнительный анализ нескольких архитектур. Это так называемый метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM). Основные его шаги следующие. 1. Определить набор сценариев действий пользователей или внешних систем, использующих некоторые возможности, которые могут уже планироваться для реализации в системе или быть новыми. Сценарии должны быть значимы для конкретных заинтересованных лиц, будь то пользователь, разработчик, ответственный за сопровождение, представитель контролирующей организации и пр. Чем полнее набор сценариев, тем выше будет качество анализа. Можно также оценить частоту появления и важность сценариев, возможный ущерб от невозможности их выполнить. 2. Определить архитектуру (или несколько сравниваемых архитектур). Это должно быть сделано в форме, понятной всем участникам оценки. 3. Классифицировать сценарии. Для каждого сценария из набора должно быть определено, поддерживается ли он уже данной архитектурой или для его поддержки нужно вносить в нее изменения. Сценарий может поддерживаться, т.е. его выполнение не потребует внесения изменений ни в один из компонентов, или же не поддерживаться, если его выполнение требует изменений в описании поведения одного или нескольких компонентов или изменений в их интерфейсах. Поддержка сценария означает, что лицо, заинтересованное в его выполнении, оценивает степень поддержки как достаточную, а необходимые при этом действия – как достаточно удобные. 4. Оценить сценарии. Определить, какие из сценариев полностью поддерживаются рассматриваемыми архитектурами. Для каждого неподдерживаемого сценария надо определить необходимые изменения в архитектуре – внесение новых компонентов, изменения в существующих, изменения связей и способов взаимодействия. Если есть возможность, стоит оценить трудоемкость внесения таких изменений. 5. Выявить взаимодействие сценариев. Определить какие компоненты требуется изменять для неподдерживаемых сценариев; если требуется изменять один компонент для поддержки нескольких сценариев – такие сценарии называют взаимодействующими. Нужно оценить смысловые связи между взаимодействующими сценариями. Малая связанность по смыслу между взаимодействующими сценариями означает, что компоненты, в которых они взаимодействуют, выполняют слабо связанные между собой задачи и их стоит декомпозировать. Компоненты, в которых взаимодействуют много (более двух) сценариев, также являются возможными проблемными местами. 6. Оценить архитектуру в целом (или сравнить несколько заданных архитектур). Для этого надо использовать оценки важности сценариев и степень их поддержки архитектурой. Унифицированный язык моделирования UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Бучи Джеймс Рамбоначали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Язык UML принят на вооружение практически всеми крупнейшими компаниями-производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый 0MG в 1997г., предлагает следующий набор диаграмм для моделирования: • диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации (требований к системе); • диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними; • диаграммы поведения системы (behavior diagrams); • диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: • диаграммы последовательности (sequence diagrams); • кооперативные диаграммы (collaboration diagrams); • диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое; • диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей; • диаграммы реализации (implementation diagrams): • диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; • диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. Лекция 8. Общая характеристика CASE-средства IBM Rational Rose Rational Rose – семейство объектно-ориентированных CASE-средств фирмы Rational Software Corporation – предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на языке моделирования UML. В настоящее время Rational Rose доминирует на рынке продуктов для объектно-ориентированного анализа, моделирования и проектирования. Rational Rose реализует генерацию кодов программ для C++, Smalltalk, Java, PowerBuilder, CORBA Interface Definition Language (IDL) и др., а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства реверсного инжиниринга программ, обеспечивающие повторное использование программных компонентов в новых проектах. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для C++, обеспечивающий реверсный инжиниринг. Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра обеспечивают "навигацию" по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т.д. Средства контроля и сбора статист и кидают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозиторий информации. Средства автоматической генерации кодов программ на языке C++, используя информацию, содержащуюся в диаграммах классов и компонентов, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке C++. Анализатор кодов C++ реализован в виде отдельного программного модуля. Его назначение – создавать модули проектов Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на C++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose / C++ обеспечивает возможность повторного использования программных компонентов. В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: • диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы; • спецификации классов, объектов, атрибутов и операций; • заготовки текстов программ. Тексты программ являются заготовками для последующей работы программистов. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы. В CASE-средстве IBM Rational Rose 2003 реализованы общепринятые стандарты на рабочий интерфейс программы, аналогично известным средам визуального программирования. Рис. 8.1. Общий вид рабочего интерфейса CASE-средства IBM Rational Rose 2003 Рабочий интерфейс программы IBM Rational Rose 2003 состоит из различных элементов, основными из которых являются: • главное меню; • стандартная панель инструментов; • специальная панель инструментов; • окно браузера проекта; • рабочая область изображения диаграммы или окно диаграммы; • окно документации; • окно журнала. Главное меню программы IBM Rational Rose 2003 выполнено в общепринятом стандарте и имеет следующий вид: Рис. 8.2. Внешний вид главного меню программы Отдельные пункты меню объединяют сходные операции, относящиеся ко всему проекту в целом. Некоторые из пунктов меню содержат хорошо знакомые операции, такие как открытие проекта, вывод на печать диаграмм, копирование в буфер и вставка из буфера различных элементов диаграмм. Другие операции настолько специфичны, что могут потребоваться дополнительные усилия для их изучения (свойства операций генерации программного кода или проверки согласованности моделей). Назначение отдельных операций главного меню приводится далее в данной лекции. Стандартная панель инструментов располагается ниже строки главного меню и имеет следующий вид (рис. 8.3). Некоторые из инструментов недоступны для нового проекта, который не имеет никаких элементов. Стандартная панель инструментов обеспечивает быстрый доступ к тем командам меню, которые выполняются разработчиками наиболее часто. Рис. 8.3. Внешний вид стандартной панели инструментов Пользователь может настроить внешний вид этой панели по своему усмотрению. Для этого необходимо выполнить операцию главного меню: Tools>Options (Инструменты>Параметры), открыть вкладку Toolbars (Панели инструментов) появившегося диалогового окна и нажать кнопку Standard (Стандартная). В дополнительно открытом окне можно переносить требуемые кнопки из левого списка в правый список, а ненужные кнопки - из правого списка в левый. Данным способом можно показать или скрыть различные кнопки инструментов, а также изменить их размер. Назначение отдельных кнопок стандартной панели инструментов приводится далее при рассмотрении операций главного меню. Лекция 9. Особенности разработки диаграмм вариантов использования. В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально – они почти всегда использовались и крайне редко документировались. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора – "сделать некоторый текст полужирным" и "создать индекс". Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Когда Ивар Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования. Человеческие фигурки здесь обозначают действующих лиц, овалы – варианты использования, а линии и стрелки – различные связи между действующими лицами и вариантами использования. Рис. 9.1. Диаграмма вариантов использования Работа над моделью в среде IBM Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования. Для вновь создаваемого проекта можно воспользоваться мастером типовых проектов, если он установлен в данной конфигурации. Мастер типовых проектов доступен из меню File>New (Файл>Новый) или при первоначальной загрузке программы IBM Rational Rose 2003. В случае разработки проекта, для которого не известна или не выбрана технология его реализации, следует отказаться от мастера, в результате чего появится рабочий интерфейс программ  IBM Rational Rose 2003 с чистым окном активной диаграммы классов и именем проекта untitled по умолчанию. Как и другие программы, IBM Rational Rose позволяет настраивать глобальные параметры среды, такие как выбор шрифтов и цвета для представления различных элементов модели. Настройка шрифтов, цвета линий и графических элементов производится через операцию главного меню: Tools>Options (Инструменты>Параметры). Характерной особенностью среды является возможность работы с символами кириллицы. Однако следует заметить, что при спецификации элементов модели с последующей генерацией текста программного кода следует записывать имена и свойства классов, ассоциаций, атрибутов, операций и компонентов символами того языка, который поддерживается соответствующим языком программирования. Для разработки диаграммы вариантов использования модели в среде IBM Rational Rose 2003 необходимо активизировать соответствующую диаграмму в окне диаграммы. Это можно сделать следующими способами: • раскрыть представление вариантов использования Use Case View в браузере проекта и дважды щелкнуть на пиктограммеMain (Главная); • с помощью операции главного меню Browse>Use Case Diagram (Браузер>Диаграмма вариантов использования). При этом появляется новое окно с чистым рабочим листом диаграммы вариантов использования и специальная панель инструментов, содержащая кнопки с изображением графических элементов, необходимых для разработки диаграммы вариантов использования. Назначение отдельных кнопок данной панели можно узнать также из всплывающих подсказок, которые появляются, если подвести и задержать на некоторое время указатель мыши над той или иной кнопкой (табл. 9.1). Таблица 9.1. Назначение кнопок специальной панели инструментов для диаграммы вариантов использования Графическое изображение Всплывающая подсказка Назначение кнопки Selection Tool Превращает изображение курсора в форму стрелки для последующего выделения элементов на диаграмме Text Box Добавляет на диаграмму текстовую область Note Добавляет на диаграмму примечание Anchor Note to Item Добавляет на диаграмму связь примечания с соответствующим графическим элементом диаграммы Package Добавляет на диаграмму пакет Use Case Добавляет на диаграмму вариант использования Actor Добавляет на диаграмму актера Unidirectional Association Добавляет на диаграмму направленную ассоциацию Dependency or Instantiates Добавляет на диаграмму отношение зависимости Generalization Добавляет на диаграмму отношение обобщения На специальной панели инструментов по умолчанию присутствует только часть кнопок с пиктограммами элементов, которые могут быть использованы для построения диаграммы. Добавить кнопки с пиктограммами других графических элементов, например, таких как бизнес-вариант использования (business use case), бизнес-актер (business actor), сотрудник (business worker), или удалить ненужные кнопки можно с помощью настройки специальной панели инструментов. Открыть диалоговое окно настройки специальных панелей инструментов для диаграмм в среде IBM Rational Rose 2003 можно с помощью операции главного меню: Tools>Options (Инструменты>Параметры), раскрыв вкладку Toolbars (Панели инструментов) и нажав соответствующую кнопку (например, Use Case diagram) в группе опций Customize Toolbars (Настройка панелей инструментов). Это окно настройки также можно открыть с помощью операции контекстного меню Customize (Настройка) при позиционировании курсора на специальной панели инструментов (рис. 9.2). Рис. 9.2. Диалоговое окно настройки специальной панели инструментов для диаграммы вариантов использования Для добавления необходимых кнопок на панель следует выделить их в левом окне со списком пиктограмм графических элементов, после чего нажать кнопку Добавить в центре диалогового окна. Для удаления ненужных кнопок с панели инструментов следует выделить их в правом окне со списком пиктограмм графических элементов, после чего нажать кнопку Удалить в центре диалогового окна. Для восстановления набора пиктограмм по умолчанию можно нажать кнопку Сброс. После настройки специальной панели инструментов соответствующее окно следует закрыть нажатием на кнопку Закрыть. Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис. В то же время два варианта использования, определенные в рамках одной моделируемой системы, также могут взаимодействовать друг с другом, однако характер этого взаимодействия будет отличаться от взаимодействия с актерами. Однако в обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию функционального поведения моделируемой системы. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: • ассоциации (association relationship) • включения (include relationship) • расширения (extend relationship) • обобщения (generalization relationship) При этом общие свойства вариантов использования могут быть представлены тремя различными способами, а именно – с помощью отношений включения, расширения и обобщения. Отношение ассоциации – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность (рис. 9.3). Рис. 9.3. Пример графического представления отношения ассоциации между актером и вариантом использования В контексте диаграммы вариантов использования отношение ассоциации между актером и вариантом использования может указывать на то, что актер инициирует соответствующий вариант использования. Такого актера называют главным. В других случаях подобная ассоциация может указывать на актера, которому предоставляется справочная информация о результатах функционирования моделируемой системы. Таких актеров часто называют второстепенными. Более детальное описание семантических особенностей отношения ассоциации будет дано при рассмотрении других диаграмм в последующих лекциях. Включение (include) в языке UML — это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого). Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в отношении включения. Так, например, отношение включения, направленное от варианта использования "Предоставление кредита в банке" к варианту использования "Проверка платежеспособности клиента", указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом <>, как показано на рис. 9.4. Рис. 9.4. Пример графического изображения отношения включения между вариантами использования Семантика этого отношения определяется следующим образом. Процесс выполнения базового варианта использования включает в себя как собственное подмножество последовательность действий, которая определена для включаемого варианта использования. При этом выполнение включаемой последовательности действий происходит всегда при инициировании базового варианта использования. Один вариант использования может входить в несколько других вариантов, а также содержать в себе другие варианты. Включаемый вариант использования является независимым от базового варианта в том смысле, что он предоставляет последнему инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант зависит только от результатов выполнения включаемого в него варианта использования, но не от структуры включаемых в него вариантов. Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <>, как показано на рис. 9.5. Рис. 9.5. Пример графического изображения отношения расширения между вариантами использования В изображенном фрагменте имеет место отношение расширения между базовым вариантом использования "Предоставление кредита в банке" и вариантом использования "Предоставление налоговых льгот". Это означает, что свойства поведения первого варианта использования в некоторых случаях могут быть дополнены функциональностью второго варианта использования. Для того чтобы это расширение имело место, должно быть выполнено определенное логическое условие данного отношения расширения. Отношение расширения позволяет моделировать таким образом, что один из вариантов использования должен присоединять к своему поведению дополнительное поведение, определенное для другого варианта использования. В то же время, данное отношение всегда предполагает проверку условия и ссылку на точку расширения в базовом варианте использования. Точка расширения определяет место в базовом варианте использования, в которое должно быть помещено расширение при выполнении соответствующего логического условия. При этом один из вариантов использования может быть расширением для нескольких базовых вариантов, а также иметь в качестве собственных расширений другие варианты. Базовый вариант использования не зависит от своих расширений. Семантика отношения расширения определяется следующим образом. Если базовый вариант использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, которая является первой из всех точек расширения у базового варианта, то проверяется логическое условие данного отношения. Если это условие выполняется, исходная последовательность действий расширяется посредством включения действий другого варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз — при первой ссылке на точку расширения, и если оно выполняется, то все расширяющие варианты использования вставляются в базовый вариант. Два и более актера могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей. Графически отношение обобщения обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 9.6). Эта линия со стрелкой имеет специальное название — стрелка-обобщение. Рис. 9.6. Пример графического изображения отношения обобщения между вариантами использования В данном примере отношение обобщения указывает на то, что вариант использования "Предоставление кредита корпоративным клиентам" - специальный случай варианта использования "Предоставление кредита клиентам банка". Другими словами, первый вариант использования является специализацией второго варианта использования. При этом вариант использования "Предоставление кредита клиентам банка" еще называют предком или родителем по отношению к варианту использования "Предоставление кредита корпоративным клиентам", а последний вариант называют потомком по отношению к первому варианту использования. Следует подчеркнуть, что потомок наследует все свойства поведения своего родителя, а также может обладать дополнительными особенностями поведения. Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми особенностями поведения родительских вариантов. При этом дочерние варианты использования участвуют во всех отношениях родительских вариантов. В свою очередь, дочерние варианты могут наделяться новыми свойствами поведения, которые отсутствуют у родительских вариантов использования, а также уточнять или модифицировать наследуемые от них свойства поведения. Язык UML включает в себя специальные механизмы расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Примеры подобных обозначений, которые используются для моделирования бизнес-систем и могут быть изображены на диаграммах вариантов использования: бизнес-актер, сотрудник и бизнес -вариант использования. Бизнес-актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью моделируемой системы. Графическое изображение бизнес-актера приводится на рис. 7, а. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы. Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы. Графическое изображение сотрудника приводится на рис. 7, б. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы. Бизнес-вариант использования (business use case) – вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса. Графическое изображение бизнес-варианта использования приводится на рис. 9.7, в. Общее свойство бизнес-вариантов использования состоит в том, что они являются концептуальной моделью отдельных бизнес-процессов моделируемой системы. Рис. 9.7. Графические изображения бизнес-актера (а), бизнес-сотрудника (б) и бизнес-варианта использования (в) Применение этих элементов графической нотации иллюстрирует пример представления диаграмм вариантов использования для системы продажи товаров в супермаркете. Эта модель может быть использована при создании и автоматизации соответствующих информационных систем. В качестве бизнес-актера данной системы можно рассматривать покупателя супермаркета, а в качестве сотрудника – продавца. При этом покупатель является клиентом сервиса "Оформление заказа на покупку товара", а продавец участвует в реализации соответствующего бизнес-процесса. Как следует из существа выдвигаемых к системе требований, этот сервис выступает в качестве базового бизнес-варианта использования данной системы. С одной стороны, продажа товаров предполагает согласование условий оплаты с покупателем и заказ товара со склада. Поскольку эта функциональность выполняется всегда, она может быть выделена в самостоятельные бизнес-варианты использования, которые будут связаны с базовым отношением включения. С другой стороны, продажа товаров может предполагать наличие отдельного информационного объекта — каталога товаров, который в некотором смысле не зависит от реализации сервиса по обслуживанию покупателей. В данном случае, каталог товаров может запрашиваться покупателем у продавца при необходимости выбора товара и уточнения его свойств. Вполне резонно представить сервис "Предоставление каталога товаров" в качестве самостоятельного бизнес-варианта использования. Дальнейшая детализация данной модели может быть выполнена на основе установления дополнительных отношений, в частности отношения "обобщение-специализация" для уже имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров — телевизоры. В этом случае диаграмма дополняется вариантом использования "Оформление заказа на покупку телевизора", который связан с сервисом "Оформление заказа на покупку товара" отношением обобщения. Полученная в результате диаграмма вариантов использования будет содержать 5 бизнес-вариантов использования, одного бизнес-актера и одного сотрудника, между которыми установлены соответствующие отношения включения, расширения и обобщения. Эта диаграмма, изображенная в общих обозначениях нотации языка UML, представлена на рис. 9.8 Рис. 9.8. Диаграмма вариантов использования для системы продажи товаров по каталогу в общих обозначениях языка UML Анализируя рассматриваемую систему продажи товаров по каталогу, можно заметить, что она представляет собой концептуальную модель типичной бизнес-системы, особенности которой связаны с получением определенной прибыли от реализации соответствующих бизнес-процессов. При этом роли покупателя и продавца в рассматриваемой системе существенно отличаются. Действительно, покупатель является внешним по отношению к системе субъектом, в то время как продавец является частью бизнес-системы. Реализация рассмотренных вариантов использования не изображается на диаграммах вариантов использования.