<< Пред.           стр. 3 (из 6)           След. >>

Список литературы по разделу

  Далее, осуществляется Выбор логической организации файлов на основе универсума способов логической организации с получением таблицы описаний. Затем осуществляется "Выбор носителей" для каждого файла из универсума машинных носителей.
  Далее выполняется операция "Выбор физической организации файлов", используя данные списка выбранных носителей и универсума способов физической организации файлов ИБ, в результате получаем таблицу описания физической организации файлов.
  Проектирование БД имеет свои особенности на всех стадиях и этапах проектирования, рассмотренные в курсе "Базы данных и знаний".
 Вопросы для самоконтроля
 1. Каков состав внутримашинного обеспечения?
 2. Что такое электронный документ?
 3. Что такое макет экранной формы и каковы типы макетов?
 4. Какие виды файлов существуют в ЭИС?
 5. Что такое информационная база и каковы требования, которым она должна удовлетворять?
 6. Принципы и способы организации ИБ как совокупности локальных файлов.
 7. Принципы и способы организации интегрированной БД.
 ЛЕКЦИЯ 7
 ИНДУСТРИАЛЬНОЕ ПРОЕКТИРОВАНИЕ
 КОРПОРАТИВНЫХ ЭИС
 РЕИНЖЕНИРИНГ БИЗНЕС-ПРОЦЕССОВ
 НА ОСНОВЕ КОРПОРАТИВНОЙ ЭИС
  Под бизнес-процессом (БП) понимают совокупность взаимосвязанных операций (работ) по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов. Современные предприятия имеют сложную структуру, обусловленную многопрофильностью, большим числом связей с партнерами. В этих условиях происходит смещение с акцентов управления отдельными подразделениями и ресурсами на управление сквозными процессами, связывающими воедино деятельность взаимосвязанных подразделений предприятия. При этом в ходе управления бизнес-процессами все материальные, финансовые, информационные потоки рассматриваются во взаимодействии.
  Реинжиниринг бизнес-процессов (РБП) определяется как фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения коренных улучшений в основных показателях деятельности предприятия. Целью РБП является системная реорганизация материальных, финансовых, информационных потоков, направленная на упрощение организационной структуры, перераспределение и минимизацию использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания. РБП обеспечивает решение следующих задач:
  * определение оптимальной последовательности выполняемых функций, которое приводит к сокращению цикла изготовления и продажи товаров и услуг, обслуживания клиентов;
  * оптимизация использования ресурсов, в результате чего минимизируются издержки и обеспечивается оптимальное сочетание различных видов деятельности;
  * построение адаптивных БП, нацеленных на быструю адаптацию к изменениям потребностей конечных потребителей продукции;
  * определение рациональных схем взаимодействия с партнерами и клиентами.
  ИБП включает в себя реинжиниринг БП, проводимый с периодичностью в 5-7 лет, выполняется на основе применения инженерных методов и современных программных инструментальных средств моделирования БП.
  РБП возможен только на основе интегрированных корпоративных ИС, которые обеспечивают поддержку управлению деловыми процессами на всех уровнях. В отличие от канонического подхода к автоматизации отдельных функций управления в виде отдельных АРМов, не изменяющих существующую технологию управления, использование КЭИС предполагает изменение системы управления на основе концепции автоматизации управления сквозными БП. Причем адаптация структуры КЭИС к изменениям потребностей системы управления должна быть непрерывной.
  Общими требованиями к созданию КЭИС, обеспечивающих эффективный РБП предприятий являются:
  * модульность, предполагающая разработку и внедрение ЭИС по отдельным программным комплексам, которые автоматизируют определенные виды деятельности предприятия и взаимодействуют между собой;
  * интегрируемость, позволяющая осуществлять информационный обмен между программными комплексами через общую БД на основе стандартов представления форматов данных и интерфейсов;
  * адаптивность, обеспечивающая настраиваемость программных комплексов на различные схемы организации БП;
  * масштабируемость, позволяющая наращивать число АРМ ЭИС по мере внедрения программных комплексов и расширения предприятия без потери эффективности эксплуатации ЭИС;
  * открытость (переносимость), реализующая сопряжение программных комплексов со стандартными программными приложениями;
  * конфиденциальность, предполагающая настройку прав доступа пользователей к системе в зависимости от уровня компетенции.
  РБП предполагает изменение архитектуры ЭИС, которая должна:
  * на оперативном уровне обеспечить ускорение информационных потоков, связывающих участников деловых процессов, и улучшить синхронизацию одновременно выполняемых процессов;
  * на тактическом уровне способствовать повышению качества принимаемых управленческих решений, позволяющих адаптировать деловые процессы к изменению внешней среды;
  * на стратегическом уровне обеспечивать процесс принятия решений относительно проектирования новых и перепроектирования существующих БП.
  На оперативном уровне упрощение организации осуществляется на основе принципов горизонтального и вертикального сжатия процессов.
  Горизонтальное сжатие процесса подразумевает объединение нескольких рабочих процедур в рамках создания многофункционального АРМ, подключаемой к комплексной системе автоматизации управления. Например, при приеме заказа от клиента выполняется не только его регистрация, но и планирование выполнения. В ходе планирования проверяется достаточность всех ресурсов, осуществляется их выделение, назначаются сроки выполнения, корректируется общий план-график работ. Кроме того, с помощью ЭС в случае дорогостоящих заказов может быть выполнена проверка финансового состояния клиента.
  Вертикальное сжатие процесса это - организация и контроль выполнения делового процесса со стороны менеджеров на основе использования ЛВС с архитектурой "клиент - сервер", систем управления потоками работ и распределенных БД. Таким образом, сокращаются затраты времени на межоперационные переходы, достигается более гибкое планирования и использование имеющихся ресурсов.
  На тактическом уровне управления для оптимизации выполнения БП требуется применение автоматизированных систем планирования и управления, которые позволяют своевременно выявлять потребность в ресурсах и обеспечить ее реализацию. К таким системам относятся системы управления ресурсами следующих классов:
  * планирование потребности в материалах под производственную программу или заказ;
  * планирование производства, включая определение потребности в материалах, производственных мощностях, трудовых ресурсах;
  * комплексное планирование работы предприятия, включая обеспечение финансовыми ресурсами в соответствии с производственной программой.
  На стратегическом уровне обоснование принятия решений по выпуску новой и модернизации существующей продукции, расширению или сокращению финансово-хозяйственной деятельности предполагает широкое использование СППР на базе применения ЭММ моделирования, ЭС, статистических методов прогнозирования, интеллектуального анализа данных.
  Для реализации перечисленных требований многие методы канонического проектирования ЭИС, предназначенные для локальной автоматизации управленческих процессов, становятся непригодными, и только методы и средства индустриального проектирования ЭИС на основе применения CASE, RAD и компонентной технологий позволяют осуществлять быструю разработку и адаптацию проектных решений в соответствии с динамически изменяющимися потребностями.
 ЭТАПЫ РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ
  В моделях жизненного цикла ЭИС предполагалось, что требования организационно-экономической системы к ЭИС, как правило, четко определяются к моменту начала проектирования ЭИС, т.е. система функционирует к моменту разработки ЭИС.
  РПБ предполагает, что реорганизация системы не может быть успешно проведена без создания адекватной ЭИС. Поэтому ЭИС не просто автоматизирует существующие деловые процессы "как есть", а обеспечивает поддержку изменений организационно-экономической системы на принципах "как должно быть". Вследствие этого реорганизация системы и проектирования ЭИС идут параллельно.
  Параллельность жизненного цикла разработки ЭИС означает также, что большинство основных реорганизуемых БП проектируется одновременно, что вызывает необходимость параллельной координации проводимых работ в части разработки общих обеспечивающих подсистем. Таким образом, общесистемные требования формируются в процессе реализации требований по отдельным БП. Имеет место следующая последовательность этапов проведения бизнес-реинжиниринга.
  На стадии идентификации выделяются ключевые БП, реорганизация которых обеспечивает кардинальное повышение эффективности функционирования организационно - экономической системы (предприятия). На стадии обратного инжиниринга осуществляется моделирование существующих деловых процессов с целью формулирования предложений по их реорганизации. Стадия прямого инжиниринга включает построение моделей новой организации деловых процессов и их реализацию в виде рабочего проекта. Модели новой организации деловых процессов доказывают возможность достижения сформулированных на этапе идентификации критериев эффективности. В дальнейшем модели деловых процессов воплощаются в виде положений и инструкций по организации работ персонала и техно - рабочего проекта ИС. Внедрение предполагает комплексное тестирование разработанных компонентов проекта, обучение персонала и поэтапный ввод в действие перепроектированных БП.
 ИДЕНТИФИКАЦИЯ БП
  Работы по идентификации БП инициируют менеджеры верхнего звена управления предприятием - лица, принимающие решения. На этом этапе осуществляется постановка задач РБП, которая определяется ключевыми проблемами предприятия (например, снижение объема продаж, высокая текучесть кадров, межоперационные простои). Постановка задач включает:
  1. Формулирование (уточнении) миссии предприятия.
  2. Определение критических факторов успеха (7 - 8 факторов) или критериев эффективности организации БП.
  3. Выявление основных видов БП, как существующих, так и перспективных (10 - 15 процессов).
  4. Описание отличительных особенностей выявленных БП.
  5. Оценка важности БП по степени влияния на реализацию критических факторов успеха.
  6. Определение ограничений, связанных с уровнем квалификации персонала фирмы, технической оснащенности производства, наличием ИТ, финансовых ресурсов.
  7. Описание возможных сценариев развития предприятия: появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов.
  8. Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров, конъюнктуры рынка.
  9. Ранжирование БП для проведения РБП в соответствии с полученной оценкой важности, ограничениями, рисками и перспективами.
  Для подготовки принятия решений по проведению РБП или уточнения сформулированных задач РБП может быть проведена работа по обобщенному анализу финансово-хозяйственной деятельности предприятия с использованием современных ИТ.
  Так, формулирование миссии предполагает решение задач качественного анализа деловых процессов, связанных с определение стратегии поведения предприятия на рынке в части расширения границ рынка или глубокого проникновения на рынок, повышения качества товаров, услуг. В качестве основных методов формирования стратегии предприятия используются методы анализа иерархий Саати, нечеткой логики Заде, а инструментальных средств - статистические ЭС с возможностью обработки качественных (нечетких) оценок, такие, как Expert Choice, Guru, Level5, Nexpert Objects.
  Выбор БП выполняется на основе анализа сегментов рынка, с помощью которого конкретизируются стратегические цели предприятия для определения регионов, потребителей, каналов распределения продуктов и услуг. Основными методами исследования на этом этапе выступают методы статистического анализа и прогнозирования, методы интеллектуального анализа данных. Наиболее мощными инструментальными средствами анализа и прогнозирования для выявления основных сегментов рынка являются ППП SAS, Oracle Express, Business Objects, SPSS.
  Оценка ограничений и рисков, связанных с проведением РБП, выполняется в ходе решения задач бизнес-планирования. В частности, для выделенных БП осуществляется оценка возможностей предприятия в плане эффективности распределения капиталовложений по различным проектам. Для решения этой задачи обычно используются ЭММ и методы оптимизации. К наиболее известным относятся ППП Project Expert, PROSPIN.
  После принятия решения о проведении РБП выполняется планирование работ на всех стадиях жизненного цикла проекта, выделяются материальные, людские, финансовые ресурсы.
  Планирование РБП осуществляется с помощью методов и средств управления проектами. С помощью простейших программных средств управления проектами типа TimeLine, Microsoft Project строятся сетевые календарные графики выполнения работ.
  ОБРАТНЫЙ ИНЖИНИРИНГ
  Обратный инжиниринг предполагает исследование функционирующих на предприятии БП. Цель этого этапа заключается в проведении диагностики "узких мест" в организации существующих БП и формировании направлений их реорганизации. Задача упрощается, если на предприятии имеется документация о функционирующих процессах после предыдущей реорганизации. На этом этапе уточняется постановка задач, выполненная на этапе идентификации, проводится корректировка целей. Используются методы и средства структурного анализа деловых и информационных процессов, которые реализованы в ППП: Design/IDEF, ErWin, ARIS Toolset.
  РАЗРАБОТКА МОДЕЛЕЙ НОВОЙ ОРГАНИЗАЦИИ БП.
  Прямой инжиниринг предполагает разработку моделей новой организации БП. При этом модели могут строиться в нескольких вариантах, из которых выбираются наиболее эффективные с точки зрения реализации критических факторов успеха. В конечном счете, составляют два варианта моделей новой организации БП:
  * идеальную модель, которая может быть достигнута в перспективе и к которой следует стремиться;
  * реальную модель, которая может быть достигнута в обозримом будущем с учетом имеющихся ресурсов и ограничений.
  Причем реальная модель БП должна быть такой, чтобы можно было в перспективе перейти к идеальной модели, т.е. обе модели должны быть концептуально близки друг к другу.
  Моделирование проблемной области БП выполняется в два подэтапа:
  1) определяется объективная структура новой организации БП: состав объектов, функций и событий;
  2) объекты и функции БП распределяются по структурным подразделениям предприятия, и определяют требования к ИС.
  Для обоснования варианта организации БП используются методы динамического имитационного моделирования. Динамический анализ предполагает рассмотрение во времени множества одновременно выполняющихся БП. Имитационное моделирование БП позволяет формировать такие характеристики, как производительность (объемы производства, сбыта), временные и стоимостные характеристики отдельных функций, степень и стоимость использования ресурсов. Целями имитационного моделирования БП могут быть:
  * сравнение средних значений и дисперсий динамических характеристик различных альтернатив процессов при одинаковых исходных данных (один сценарий моделирования - несколько моделей);
  * отыскание оптимальных значений переменных на множестве возможных значений (несколько сценариев моделирования - одна модель);
  * определение зависимостей между различными факторами процессов в результате специального анализа полученной статистики.
  РЕАЛИЗАЦИЯ ПРОЕКТА РЕИНЖИНИРИНГА БП
  После определения моделей новой организации БП осуществляется разработка обеспечивающих подсистем, поддерживающих функционирование предприятий в новых условиях. Для изменения структуры ОЭС осуществляется:
  * разработка организационно-штатной структуры предприятия;
  * разработка должностных инструкций;
  * разработка системы стимулирования работников;
  * обучение персонала;
  * подготовка рабочей документации.
  Для создания новой ИС осуществляются:
  * генерация, настройка, программирование и отладка программных модулей;
  * разработка и наполнение БД;
  * установка оборудования.
  Для быстрой разработки ИС используются CASE - средства автоматизации проектирования или средства конфигурации комплексных систем управления ресурсами предприятия. В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средства быстрой разработки приложений (RAD - технология) и языки программирования.
  ВНЕДРЕНИЕ ПРОЕКТА РЕИНЖИНИРИНГА БП
  Внедрение проекта РБП, как правило, осуществляется поэтапно в соответствии с приоритетами, установленными на этапе идентификации БП. Большое значение на этапе внедрения отводится комплексному тестированию компонентов проекта, для чего используются специальные программные средства. Внедрение проекта РБП предполагает его сдачу приемочной комиссии, в которую входят представители лиц, принимающих решения и будущие менеджеры процессов.
  После внедрения спроектированных БП в реальную практику очень важно организовать анализ достижения заданных в начале реинжиниринга критериев эффективности функционирования предприятия, на основе которых можно своевременно принимать решения о необходимости адаптации БП к изменяющейся внешней среде.
 Вопросы для самоконтроля
  1. Что такое бизнес-процесс и чем процесс управления бизнес-процессом отличается от управления ресурсами
  2. Что понимают под реинжинирингом бизнес-процессов. Какие задачи решает реинжиниринг?
  3. Перечислите основные этапы реинжиниринга бизнес-процессов.
  4. Что понимают под моделью проблемной области.
  5. Какие требования предъявляют к модели проблемной области.
  6. Какие существуют критерии для оценки модели проблемной области?
 ЛЕКЦИЯ 8
 АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС
 (CASE - ТЕХНОЛОГИИ)
 ОСНОВНЫЕ ПОНЯТИЯ И КЛАССИФИКАЦИЯ
 CASE - ТЕХНОЛОГИЙ
  CASE-технологии с самого начала развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации) за счет ее автоматизации и интеграции поддерживающих средств. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано в основном на методологиях структурного или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
  Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС. Так как цена ошибок, допущенных на этих этапах, превышает цену ошибок, допущенных на последующих стадиях разработки. Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования:
  * улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;
  * возможность повторного использования компонентов разработки;
  * поддержание адаптивности и сопровождения ЭИС;
  * снижение времени создания системы, возможность получения на ранних стадиях прототипа системы и его оценки;
  * освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор.
 CASE - средства имеют следующую архитектуру.
  Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов:
  * проектировщиков и их прав доступа к различным компонентам системы;
  * организационных структур;
  * диаграмм;
  * компонентов диаграмм;
  * связей между диаграммами;
  * структур данных;
  * программных модулей;
  * процедур;
  * библиотеки модулей.
  Графические средства моделирования предметной области позволяют разработчикам АИС в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в диалоговом режиме, вводятся в словарь данных, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений. В любой момент времени диаграммы могут быть распечатаны для включения в техническую документацию проекта.
  Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции:
  * создавать элементы диаграмм и взаимосвязи между ними;
  * задавать описания элементов диаграмм;
  * задавать описания связей между элементами диаграмм;
  * редактировать элементы диаграмм, их взаимосвязи и описания.
  Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции:
  * мониторинг правильности построения диаграмм;
  * диагностику и выдачу сообщений об ошибках;
  * выделение на диаграмме ошибочных элементов.
  Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам: по времени, автору, элементам диаграмм, по проекту в целом.
  Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:
  * инициализации проекта;
  * задания начальных параметров проекта;
  * назначения и изменения прав доступа к элементам проекта;
  * мониторинга выполнения проекта.
  Сервис представляет набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации, восстановления данных, создания нового репозитория.
  Современные CASE-системы классифицируются по следующим признакам:
  * по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные, комплексно-ориентированные (набор методологий проектирования);
  * по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями, с наиболее распространенными нотациями;
  * по степени интегрированности:
  o tools (отдельные локальные средства);
  o toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС);
  o workbench (полностью интегрированные средства, связанные с репозиторием);
  * по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на ЛВС, Ориентированные на ГВС, смешанного типа;
  * по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
  * по типу ОС.
  Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию БД и пользовательских интерфейсов.
 ФУНКЦИОНАЛЬНО - ОРИЕНТИРОВАННОЕ
 ПРОЕКТИРОВАНИЕ ЭИС
  Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования ИС. Они заключаются в следующем:
  1. декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
  2. представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.
  В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
  * BFD - диаграмма бизнес-функций (функциональные спецификации):
  позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами этих диаграмм являются:
  o Функция - некоторое действие ИС, необходимое для решения экономической задачи;
  o Декомпозиция функций - разбиение функций на множество подфункций;
  * SAG нотация:
  * DFD - диаграмма потоков данных (ДПД);
  ДПД, как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отображаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками указываются имена передаваемых/используемых единиц информации - документов, экранных форм, файлов).
  * STD - диаграмма переходов состояний (ДПС - матрицы перекрестных ссылок);
  ДПС моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы, исходя из предыдущих и текущего состояния.
  * SSD - диаграмма структуры программного приложения задает взаимосвязь функций и программных модулей, которые их реализуют. Представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. Служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах, к реализации информационной системы. Фрагмент SSD-диаграммы в нотации SAG для задачи аналитического учета на складах имеет вид:
  * ERD - ER-модель данных предметной области (информационно-логические модели "сущность - связь"):
  ориентирована на разработку БД, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей.
 
 ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС
  Структурная декомпозиция ЭИС на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.
  Конечным результатом процесса ООП должно стать множество классов объектов с присоединенными методами обработки атрибутов. Если в функциональном подходе модели данных и операции разрабатываются относительно независимо друг от друга и только координируются между собой, то ОО подход предполагает совместное моделирование данных и процессов. При этом модели проблемной области в репозитории постепенно уточняются.
  В связи с этим система ОО моделей постепенно разворачивается по направлению от модели общего представления функциональности ЭИС к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов конкретной программно-технической среде.
  Для ОО моделирования используется унифицированный язык моделирования (UML). Система ОО моделей в соответствии с нотациями UML включает в себя следующие диаграммы:
  1. Диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательных транзакций;
  2. Диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
  3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ним событий;
  4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействия объектов в рамках одного прецедента использования;
  5. Диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);
  6. Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);
  7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;
  8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.
 Диаграмма прецедентов использования (ДПИ)
  ДПИ выявляет основные БП как последовательности транзакций, которые должны выполняться целиком, когда выполнение обособленного подмножества действий не имеет значения без выполнения всей последовательности. Прецеденты использования инициируются из вешней среды пользователями ЭИС, называемыми актерами. На этом уровне моделирования не раскрывается механизм реализации процессов. Представленные сущности имеют следующие графические обозначения:
 
  Актер - внешний пользователь процесса
 
 
 Прецедент использования (БП)
  Актер инициирует выполнение прецедента использования и получает от него результаты. Взаимодействие (ассоциация) актеров с прецедентом использования осуществляется в результате события, которое обозначается поименованной стрелкой. Один актер может участвовать в нескольких прецедентах использования, а в одном ПИ может быть занято несколько актеров
  Информирование об отложенном заказе Информирование о заказе на закупку
 
  формирование
  заказа
  удаление подтверждение
 Менеджер заказа заказа Менеджер
 по продажам ввод по закупкам
  данных
  оформление
  договора
 
  Рис. 6. Пример ДПИ
  В реализации прецедентов использования (ПИ) возможно выделение нескольких потоков событий:
  * основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек;
  * альтернативные потоки событий, например временное откладывание или полный отказ от выполнения заказов.
  Основной и альтернативный потоки событий в модели прецедентов использования описываются в виде текстовых комментариев.
  Несколько ПИ могут иметь общую часть, выделяемую в самостоятельный ПИ, с которым устанавливаются отношения использования (uses). С другой стороны, некоторые прецеденты использования могут быть расширены деталями. В таком случае создается дополнительный прецедент использования, с которым устанавливаются отношения расширения (extends).
 
  ввод uses
  данных
 Менеджер
  оформление uses
  договора
  extends extends
 
 
 
  Рис. 7 Пример применения отношений использования и расширения
 Диаграммы классов объектов (ДКО)
  ДКО отображают статическую структуру классов объектов. Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов. Классы объектов могут иметь различные стереотипы поведения: объекты-сущности, управляющие объекты, интерфейсные объекты:
 
 
 Интерфейсный объект - Управляющий объект - Сущность - активный объект форма взаимодействия ИС с пользователем (экранная форма, меню, кнопка) активный объект, координирующий выполнение функций пассивный объект над которым выполняются операции обработки Объекты, отражаемые в диаграмме классов объектов, связываются статическими отношениями, которые отражают постоянные связи между объектами независимо от выполнения конкретного БП. К статическим отношениям относятся обобщение, агрегация, ассоциация объектов.
 Диаграммы состояний (ДС)
  ДС отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и определяет:
  * типичные состояния проходит объект;
  * события, ведущие к изменению состояния объекта;
  * действия выполняемые, когда он получает сообщение об изменении состояния;
  * объекты создаются и уничтожаются (входные и выходные точки диаграммы).
  Используются следующие обозначения:
 
  Входная точка Состояние Переход состояний Выходная точка
  Входная точка определяет событие, которое образует начальное состояние объекта. В точку входа нельзя перейти из состояния объекта.
  Выходная точка определяет завершение существования объекта. Из нее нет перехода состояния.
  Состояние представляет ситуацию, в течение которой выполняется непрерывная деятельность или объект находится в стационарном положении. Состояние определяется как набор значений атрибутов и отношений, связанных с объектом. Имя состояния должно быть уникальным только внутри класса объекта, для которого оно определяется. С каждым состоянием связано одно событие или более, которые могут его изменить. Для состояния задаются имена всех связанных с ним переходов в другие состояния. Переход состояний определяет изменение в состоянии объекта, которое происходит в результате события, возникающего в то время, когда объект находился в данном состоянии. Каждый переход состояний должен иметь уникальное имя. Переход состояний описывается следующими атрибутами:
  * назначение - состояние объекта, в которое перейдет объект после перехода состояния.
  * вызов - имя события, которое вызывает переход состояний. Имена событий должны быть идентичными в определении класса и состояния. Вызываемые события могут быть либо внешними, осуществляемыми актерами, либо внутренними, связанными с поведением других объектов, либо временными, связанными с истечением заданного интервала времени.
  * условие перехода - это логическое выражение, связанное с атрибутами объекта, которое должно быть проверено для выбора перехода состояния. Условие перехода задается в том случае, если происходит событие, в результате которого может произойти неоднозначный переход состояний. Условия переходов для одного исходного состояния должны быть взаимоисключающими.
  * действие - атрибут, информационно описывающий сущность действия, которое должно выполняться при переходе состояний. Этому действию будет соответствовать некоторая процедура, реализующая метод класса объектов.
  Переход состояний графически помечается меткой линии, на которой задается, по крайней мере, один из следующих атрибутов: Вызов, Условие перехода, Действие.
 Диаграмма взаимодействия объектов
  Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:
  * в форме диаграммы последовательностей, показывающей последовательность взаимодействий на графе;
  * в форме кооперативной диаграммы, показывающей взаимодействие объектов в табличной форме.
  В диаграмме последовательностей взаимодействие объектов отображается в виде стрелки между объектами, которая соответствует событию или сообщению от одного объекта к другому, вызывающего выполнение метода, реагирующего на событие (сообщение) объекта. Номер стрелки соответствует номеру события в последовательности.
  Диаграмма кооперативного поведения представлена в табличном виде по следующим правилам.
  1. В столбцах таблицы указываются объекты всех типов, участвующие в реализации прецедента использования. Порядок расположения активных и пассивных объектов произволен и должен быть удобен для понимания модели. Актеры прецедента использования отображаются на правой и левой границах таблицы.
  2. По горизонтали проводятся поименованные стрелки, отображающие взаимодействие (коммуникацию) объектов в рамках данной операции. Эта стрелка означает, что первый объект в рамках выполняемой операции посылает сообщение второму объекту о необходимости выполнения действия. При получении сообщения второй объект выполняет действие.
  3. На пересечении строк и столбца вертикально отображается условный отрезок времени, в течение которого выполняется то или иное действие над объектом.
 Диаграмма деятельностей
  Диаграммы взаимодействия не отражают детально порядок выполнения операций в части разветвлений, циклических повторений, параллельности/произвольности действий. Диаграмма деятельностей исправляет эти недостатки. Под деятельностью понимают некоторую работу, которая может быть декомпозирована на совокупность действий.
  Диаграмма деятельностей может отражать взаимодействие объектов из нескольких прецедентов использования, в частности реализующих отдельные стандартные и альтернативные пути обработки объектов.
  Блок, соответствующий одной деятельности, может отражать несколько событий и быть декомпозирован аналогично блоку функционально-ориентированного подхода.
  Имеют место следующие обозначения:
 Деятельность
 Выход
 Поток от деятельности к деятельности
 Итерация
 Синхронизация
 
 Решение
 Разделение потока на деятельности,
 выполняемые параллельно или произвольно
 
 Диаграммы пакетов
  В объектно-ориентированном подходе пакет содержит множество взаимосвязанных классов объектов и соответствует понятию "подсистема функционально-ориентированного подхода". Один прецедент использования может требовать классы объектов из разных пакетов. Класс объектов обычно назначается одному пакету, но с позиции достижения разных подцелей может входить в состав разных пакетов.
  Пакетная технология группирования классов объектов позволяет:
  * упростить разработку и эксплуатацию ЭИС;
  * применить гибкую адаптацию типовых компонентов с позиции их повторного использования;
  * оптимизацию клиент-серверной архитектуры ЭИС.
  Обычно ЭИС разбивается на функциональные и обеспечивающие пакеты. Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет "Проблемная область". Каждый пакет, в свою очередь, может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов. Обычно пакеты проблемной области содержат иерархии обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемам выделяются в самостоятельные пакеты. В одном пакете, как правило, выделяется не более 20 компонентов.
  С обеспечивающей точки зрения ЭИС разбивают на пять основных пакетов:
  * Интерфейс, объекты которого реализуют функции взаимодействия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между системами;
  * БД, объекты выполняющие доступ к данным внешней памяти;
  * Управление задачами, объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например, в системе управления рабочими потоками;
  * Утилиты, объекты которого осуществляют вспомогательные функции, например преобразование форматов данных;
  * Обеспечивающие пакеты, т.е. работающие по принципу клиент-серверной архитектуры, выполняющие серверные функции для функциональных объектов-клиентов. Таким образом, обеспечивающие пакеты освобождают пользователя от знания деталей программно-технической реализации ЭИС.
 Диаграммы компонентов и размещения
  Диаграмма компонентов отображает зависимости программных компонентов, которые представляются в виде исходных, откомпилированных и исполняемых программных кодов объектов. Один компонент, как правило, соответствует программному коду одного пакета класса объектов.
  Компонент в своем составе имеет интерфейсный класс объектов, через которые осуществляется доступ к остальным классам объектов компонента. С помощью интерфейса объекты других компонентов обращаются не к конкретным объектам рассматриваемого компонента, а к его интерфейсному объекту. Таким образом, упрощается взаимодействие компонентов между собой, когда при доступе к компоненту из других компонентов не требуется знать внутреннюю структуру этого компонента. Компонент, к которому осуществляется обращение, может быть не объектно-ориентированным. Достаточно, чтобы у такого компонента был только один интерфейсный класс объектов, который транслирует запросы к компоненту в вызовы обычных процедур. У компонентов может быть несколько интерфейсов.
  В модели размещения отображается топология расположения компонентов по узлам вычислительной сети. Технологическая сеть объектно-ориентированного проектирования ЭИС включает следующие операции: анализ системных требований, логическое проектирование, физическое проектирование, реализация.
  Рассмотрим подробнее эти операции.
 Анализ системных требования к ЭИС
  На входе этапа анализа системных требований используется описание организационно-экономической системы, полученное в ходе работ по анализу и проектированию БП. Эти материалы содержат описание организационной структуры, структуры материальных, финансовых, информационных потоков, которое может быть выполнено либо с помощью традиционных средств графического отображения, либо с помощью определенных методологий бизнес-реинжиниринга (например, с помощью объектно-ориентированной методологии).
  ТС анализа системных требований к ЭИС имеет следующий вид.
 
 
 
 
 
 
 
  Рис. 8. ТСП анализа системных требований к ЭИС
  Так, в объектно-ориентированной (ОО) методологии анализа и проектирования предусматриваются:
  * описание БП как прецедентов использования, актерами которых служат внешние участники БП (клиенты, поставщики).
  * задание порядка разработки и автоматизации БП в соответствии с определенными критериями, например, наибольшим эффектом для заказчика, простотой и быстротой разработки.
  * неформальное словесное описание БП.

<< Пред.           стр. 3 (из 6)           След. >>

Список литературы по разделу