Архитектура информационных систем

Лекции по дисциплине Архитектура информационных систем Лекция 1. Основы информационных систем Информационная система – это любая система, реализующая или поддерживающая информационный процесс. К информационным можно относить любые системы, включающие в себя работу с информацией. В настоящее время основным помощником человека при работе с информацией является компьютер, поэтому именно его мы и будем рассматривать в качестве источника, способа изменения и хранения информационных систем. А в качестве информационных систем будем рассматривать программное обеспечение компьютера. В зависимости от предметной области информационные системы могут весьма значительно различаться по своим функциям, архитектуре, реализации. Однако можно выделить ряд свойств, которые являются общими. • Информационные системы предназначены для организации и поддержки информационного процесса, поэтому в основе любой из них лежит среда хранения и доступа к информации. • Информационные системы ориентированы на конечного пользователя, не обладающего высокой квалификацией в области вычислительной техники. Поэтому клиентские приложения информационной системы должны обладать простым, удобным, легко осваиваемым интерфейсом. Таким образом, при разработке информационной системы приходится решать две основные задачи: • разработка базы данных, предназначенной для хранения информации; • разработка графического интерфейса пользователя клиентских приложений. В любой информационной системе можно выделить необходимые функциональные компоненты (табл. 1), которые помогают понять ограничения различных архитектур информационных систем. Рассмотрим более подробно особенности вариантов построения информационных приложений. • Таблица 1.1. Типовые функциональные компоненты информационной системы Обозначение Наименование Характеристика PS Presentation Обслуживает пользовательский ввод и Services отображает то, что сообщает ему (средства компонент логики представления (PL), с представления) использованием соответствующей программной поддержки PL Presentation Управляет взаимодействием между Logic (логика пользователем и ЭВМ. Обрабатывает представления) действия пользователя при выборе BL DL DS FS Business Logic (прикладная логика) Data Logic (логика управления данными) Data Services (операции c базой данных) File Services (файловые операции) команды в меню, щелчке на кнопке или выборе пункта в списке Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение Операции с базой данных (реализуемые SQL-операторами), которые нужно выполнить для реализации прикладной логики управления данными Действия СУБД, реализующие логику управления данными, такие как манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQLпредложения Дисковые операции чтения и записи данных для СУБД и других компонентов. Обычно являются функциями операционной системы (ОС) Классификация информационных систем Информационные системы классифицируются по разным признакам. Классификация по масштабу По масштабу информационные системы подразделяются на следующие группы: • одиночные; • групповые; • корпоративные. Одиночные информационные системы Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных, или локальных, систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access. Групповые информационные системы Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL (Structured Query Language – структурированный язык запросов)-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix. Корпоративные информационные системы Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server. Классификация по сфере применения По сфере применения информационные системы обычно подразделяются на четыре группы : • системы обработки транзакций (протоколов); • системы поддержки принятия решений; • информационно-справочные системы; • офисные информационные системы. Системы обработки транзакций, в свою очередь, по оперативности обработки данных разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций (OnLine Transaction Processing, OLTP) для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т.п. Важными требованиями для них являются: • высокая производительность обработки транзакций; • гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям. Системы поддержки принятия решений (Decision Support System, DSS) представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических, по другим показателям. Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в Интернете. Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом. Классификация по способу организации По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы: • системы на основе архитектуры файл-сервер; • системы на основе архитектуры клиент-сервер; • системы на основе многоуровневой архитектуры; • системы на основе Интернет/интранет-технологий. Лекция 3. Жизненный цикл АИС и его этапы Жизненный цикл (ЖЦ) - одно из базовых понятий методологии проектирования ИС. Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC International Electrotechnical Commission - Международная комиссия по электротехнике). В настоящее время базовым стандартом в области ЖЦ ПС и систем явля-ется международный стандарт ISO/IEC 12207:2008 – Системная и программная инженерия – Процессы жизненного цикла программных средств . Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС. Структура ЖЦ по стандарту ISO/IEC базируется на трех группах процессов: • основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение); • вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, решение проблем); • организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение). Основные процессы жизненного цикла – это процессы, которые реализуются под управлением основных сторон, участвующих в жизненном цикле программных средств. Основными сторонами являются заказчик, поставщик, разработчик, оператор и персонал сопровождения программных продуктов. К основным процессам относится пять процессов: • • заказ; поставка; • • разработка; эксплуатация; • • сопровождение. Вспомогательные процессы жизненного цикла – это процессы, яв- ляющиеся целенаправленными составными частями других процессов и предназначенные для обеспечения успешной реализации и качества выполнения программного проекта. К вспомогательным процессам относится восемь процессов: i. ii. iii. iv. v. документирование; управление конфигурацией; обеспечение качества; верификация; аттестация; vi. совместный анализ; vii. аудит; viii. решение проблем. Организационные процессы жизненного цикла – это процессы, предназначенные для создания в некоторой организации и совершенствования орга-низационных структур, охватывающих процессы жизненного цикла и соответ-ствующий персонал. К организационным процессам относится четыре процесса: 2. управление; 3. создание инфраструктуры; 4. усовершенствование; 5. обучение. Модель ЖЦ - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Наибольшее распространение получили две основные модели ЖЦ: • каскадная модель (70-85 гг.); • спиральная модель (86-90 гг.). Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.1.2.1). Положительные стороны применения каскадного подхода: • на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; • выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Рисунок 1.2.1. Схема каскадного подхода Однако реально в процессе создания ИС постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания ИС принимает следующий вид (рис. 1.2.2): Рисунок 1.2.2. Реальный процесс создания ИС на базе каскадной модели Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model). Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Другой недостаток - такое проектирование ИС ведет к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников. В спиральной модели ЖЦ (рис. 1.2.3), делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов. Рисунок 1.2.3. Спиральная модель ЖЦ Каждый виток спирали соответствует созданию нового фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track". Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов ИС. Основная проблема спирального цикла - определение момента перехода на следующий этап. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Модели быстрой разработки приложений Модель быстрой разработки приложений (Rapid Application Development, RAD) появилась в 80-е гг. XX в. в связи с бурным развитием мощных технологий и инструментальных средств разработки программных продуктов. Данная модель, исходя из особенностей ее реализации и целей ее использования, может поддерживать как инкрементную, так и эволюционную стратегию разработки систем или ПС. Как правило, RAD-модели используются в составе другой модели для ускорения цикла разработки прототипа (версии) системы или программного средства (см. пп. 2.5.3, 2.5.4). При невысокой сложности проектов RAD-модели могут применяться как независимые модели. Основу RAD-модели составляет использование мощных инструментальных средств разработки. Такими средствами являются языки четвертого поко-ления 4GL (Fourth Generation Language – язык программирования четвертого поколения) и CASE-средства (Computer Aided Software Engineering – компьютерная поддержка проектирования ПО), благодаря наличию в них сред визуальной разработки и кодогенераторов. Поэтому в процессе быстрой разработки приложений основное внимание уделяется не программи-рованию и тестированию, а анализу требований и проектированию. Использование инструментальных средств позволяет задействовать пользователя, а следовательно, дать оценку продукту на всех этапах его разработки. Характерной чертой RAD-модели является короткое время перехода от анализа требований до создания полной системы или программного средства. Разработка прототипа, как правило, ограничивается четко определенным периодом времени (временным блоком; обычно 60 дней) [30, 33]. При полностью определенных требованиях и не очень сложной проектной области использование RAD-модели позволяет за временной блок создать полную функциональ-ную систему. При использовании RAD-модели в соответствующем проявляются следующие ее основные достоинства: ей проекте 1) сокращение продолжительности цикла разработки и всего проекта в целом, сокращение количества разработчиков, а следовательно, и стоимости проекта за счет использования мощных инструментальных средств; 2) сокращение риска несоблюдения графика за счет использования принципа временного блока и связанное с этим упрощение планирования; 3) сокращение риска, связанного с неудовлетворенностью заказчика (пользователя) разработанным программным продуктом, за счет его привлечения на постоянной основе к циклу разработки; возрастание уверенности, что продукт будет соответствовать требованиям; 4) возможность повторного использования существующих компонентов; это достоинство проявляется при использовании RAD-модели в составе инкрементной или эволюционной модели; в этом случае наращивание функциональных возможностей осуществляется на базе разработанных ранее компонентов. Основными недостатками RAD-модели неподходящем для нее проекте являются: при использовании в 1) необходимость в постоянном участии пользователя в процессе разработки, что часто невыполнимо и в итоге сказывается на качестве конечного продукта; 2) необходимость в высококвалифицированных разработчиках, умеющих работать с инструментальными средствами разработки; 3) возможность применения только для систем или ПС, для которых отсутст-вует требование высокой производительности; 4) жесткость временных ограничений на разработку прототипа; 5) сложность ограничения затрат и определения сроков завершения работы над проектом в случаях, когда не удается разработать продукт за временной интервал; 6) неприменимость в условиях высоких технических рисков, при использовании новых технологий. Области применения RAD-модели определяются ее достоинствами и ограни-чены ее недостатками. RAD-модель может эффективно применяться в следующих случаях: 1) при разработке систем и продуктов, для которых характерно хотя бы одно из следующих свойств: поддаются моделированию; предназначены для концептуальной проверки; являются некритическими; имеют небольшой размер; имеют низкую производительность; относятся известной разработчикам предметной области; к являются информационными системами; требования для них хорошо известны; имеются пригодные к повторному использованию в них компоненты; 2) если пользователь может принимать постоянное участие в процессе разработки; 3) если в проекте заняты разработчики, обладающие достаточными навыками в использовании инструментальных средств разработки; 4) при выполнении проектов в сокращенные сроки (как правило, не более чем за 60 дней); 5) при разработке ПС, для которых требуется быстрое наращивание функциональных возможностей на последовательной основе; 6) при невысокой степени технических рисков; 7) в составе других моделей жизненного цикла. Структура информационной системы Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами. Подсистема — это часть системы, выделенная по какому-либо признаку. Общую структуру информационной системы можно рассматривать как совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации, а подсистемы называют обеспечивающими. Таким образом, структура любой информационной системы может быть представлена совокупностью обеспечивающих подсистем (рис. 2). Рис. 2. Структура информационной системы как совокупность обеспечивающих подсистем Среди обеспечивающих подсистем обычно выделяют информационное, техническое, математическое, программное, организационное и правовое обеспечение. Информационное обеспечение (ИО) - совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем информационных потоков, циркулирующих в организации, а также методология построения баз данных. Назначение подсистемы информационного обеспечения состоит в своевременном формировании и выдаче достоверной информации для принятия управленческих решений. Унифицированные системы документации создаются на государственном, республиканском, отраслевом и региональном уровнях. Главная цель - это обеспечение сопоставимости показателей различных сфер общественного производства. Разработаны стандарты, где устанавливаются требования: к унифицированным системам документации; • к унифицированным формам документов различных уровней управления; • к составу и структуре реквизитов и показателей; • к порядку внедрения, ведения и регистрации унифицированных форм документов. Однако, несмотря на существование унифицированной системы документации, при обследовании большинства организаций постоянно выявляется целый комплекс типичных недостатков: • чрезвычайно большой объем документов для ручной обработки; • одни и те же показатели часто дублируются в разных документах; • работа с большим количеством документов отвлекает специалистов от решения непосредственных задач; • имеются показатели, которые создаются, но не используются, и др. • Поэтому устранение указанных недостатков является одной из задач, стоящих при создании информационного обеспечения. Схемы информационных потоков отражают маршруты движения информации и ее объемы, места возникновения первичной информации и использования результатной информации. За счет анализа структуры подобных схем можно выработать меры по совершенствованию всей системы управления. Пример: В качестве примера простейшей схемы потоков данных можно привести схему, где отражены все этапы прохождения служебной записки или записи в базе данных о приеме на работу сотрудника - от момента ее создания до выхода приказа о его зачислении на работу. Построение схем информационных потоков, позволяющих выявить объемы информации и провести ее детальный анализ, обеспечивает: • исключение дублирующей и неиспользуемой информации; • классификацию и рациональное представление информации. При этом подробно должны рассматриваться вопросы взаимосвязи движения информации по уровням управления (см. рис. 3.2). Следует выявить, какие показатели необходимы для принятия управленческих решений, а какие нет. К каждому исполнителю должна поступать только та информация, которая используется. Методология построения баз данных базируется на теоретических основах их проектирования. Для понимания концепции методологии приведем основные ее идеи в виде двух последовательно реализуемых на практике этапов: 1-й этап - обследование всех функциональных подразделений фирмы с целью: • понять специфику и структуру ее деятельности; • построить схему информационных потоков; • проанализировать существующую систему документооборота; • определить информационные объекты и соответствующий состав реквизитов (параметров, характеристик), описывающих их свойства и назначение. 2-й этап - построение концептуальной информационно-логической модели данных для обследованной на 1-м этапе сферы деятельности. В этой модели должны быть установлены и оптимизированы все связи между объектами и их реквизитами. Информационно-логическая модель является фундаментом, на котором будет создана база данных. Для создания информационного обеспечения необходимо: • ясное понимание целей, задач, функций всей системы управления организацией; • выявление движения информации от момента возникновения и до ее использования на различных уровнях управления, представленной для анализа в виде схем информационных потоков; • совершенствование системы документооборота; • наличие и использование системы классификации и кодирования; владение методологией создания концептуальных информационнологических моделей, отражающих взаимосвязь информации; • создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения. Техническое обеспечение (ТО) - комплекс технических средств, предназначенных для работы информационной системы, а также соответствующая документация на эти средства и технологические процессы. Комплекс технических средств составляют: • компьютеры любых моделей; • устройства сбора, накопления, обработки, передачи и вывода информации; • устройства передачи данных и линий связи; • оргтехника и устройства автоматического съема информации; • эксплуатационные материалы и др. Документацией оформляются предварительный выбор технических средств, организация их эксплуатации, технологический процесс обработки данных, технологическое оснащение. Документацию можно условно разделить на три группы: • общесистемную, включающую государственные и отраслевые стандарты по техническому обеспечению; • специализированную, содержащую комплекс методик по всем этапам разработки технического обеспечения; • нормативно-справочную, используемую при выполнении расчетов по техническому обеспечению. К настоящему времени сложились две основные формы организации технического обеспечения (формы использования технических средств): централизованная и частично или полностью децентрализованная. Централизованное техническое обеспечение базируется на использовании в информационной системе больших ЭВМ и вычислительных центров. Децентрализация технических средств предполагает реализацию функциональных подсистем на персональных компьютерах непосредственно на рабочих местах. Перспективным подходом следует считать, по-видимому, частично децентрализованный подход - организацию технического обеспечения на базе распределенных сетей, состоящих из персональных компьютеров и большой ЭВМ для хранения баз данных, общих для любых функциональных подсистем. Математическое и программное обеспечение (МО, ПО) - совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач информационной системы, а также нормального функционирования комплекса технических средств. К средствам математического обеспечения относятся: • средства моделирования процессов управления; • типовые задачи управления; • методы математического программирования, математической статистики, теории массового обслуживания и др. В состав программного обеспечения входят общесистемные и специальные программные продукты, а также техническая документация. К общесистемному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных для решения типовых задач обработки информации. Они служат для расширения функциональных возможностей компьютеров, контроля и управления процессом обработки данных. Специальное программное обеспечение представляет собой совокупность программ, разработанных при создании конкретной информационной системы. В его состав входят пакеты прикладных программ (ППП), реализующие разработанные модели разной степени адекватности, отражающие функционирование реального объекта. Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономикоматематическую модель задачи, контрольные примеры. Организационное обеспечение (ОО) - совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации информационной системы. Организационное обеспечение реализует следующие функции: • анализ существующей системы управления организацией, где будет использоваться ИС, и выявление задач, подлежащих автоматизации; • подготовку задач к решению на компьютере, включая техническое задание на проектирование ИС и технико-экономическое обоснование ее эффективности; • разработку управленческих решений по составу и структуре организации, методологии решения задач, направленных на повышение эффективности системы управления. Организационное обеспечение создается по результатам предпроектного обследования на 1-м этапе построения баз данных, с целями которого вы познакомились при рассмотрении информационного обеспечения. Правовое обеспечение (Пр.О) - совокупность правовых норм, определяющих создание, юридический статус и функционирование информационных систем, регламентирующих порядок получения, преобразования и использования информации. Главной целью правового обеспечения является укрепление законности. В состав правового обеспечения входят законы, указы, постановления государственных органов власти, приказы, инструкции и другие нормативные документы министерств, ведомств, организаций, местных органов власти. В правовом обеспечении можно выделить общую часть, регулирующую функционирование любой информационной системы, и локальную часть, регулирующую функционирование конкретной системы. • Правовое обеспечение этапов разработки информационной системы включает нормативные акты, связанные с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора. Правовое обеспечение этапов функционирования информационной системы включает: • статус информационной системы; • права, обязанности и ответственность персонала; • правовые положения отдельных видов процесса управления; • порядок создания и использования информации и др. Лекция 4, 5. Классификация архитектур информационных систем Многозвенные информационные системы В этой части курса приводится классификация возможных архитектур информационных систем. Мы начинаем с традиционных архитектурных решений, основанных на использовании выделенных файл-серверов или серверов баз данных. Затем рассматриваются варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "склада данных" (DataWarehouse) интегрированной информационной среды, включающей разнородные информационные ресурсы. Наконец, последняя выделяемая нами архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода. Следует заметить, что как и любая классификация, наша классификация архитектур информационных систем не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений. Тем не менее, при архитектурном проектировании системы кажется полезным иметь хотя бы частично ортогонализированный архитектурный базис. В следующих частях курса мы подробно рассмотрим особенности каждой архитектуры и остановимся на методологиях и инструментально-технологических средствах, поддерживающих проектирование и разработку информационных систем в соответствующей архитектуре. 4.1. Файл-серверные приложения По всей видимости, организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети. Чем привлекает такая организация не очень опытных в области системного программирования разработчиков информационных систем? Скорее всего, тем, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения, работающего на каждой PC сети. Фактически, компоненты информационной системы, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждой PC дублируются не только прикладные программы, но и средчства управления базами данных. Файл-сервер представляет собой разделяемое всеми PC комплекса расширение дисковой памяти (рисунок 4.1) Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. Рис. 4.1. Классическое представление информационной системы в архитектуре "файл-сервер" Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Почему-то часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. База данных есть база данных. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Естественно, сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области. Но, собственно, из чего должно следовать, что файл-серверные приложения пригодны только в простых предметных областях? Во-вторых, необходимыми требованиями к базе данных информационной системы являются поддержание ее целостного состояния и гарантированная надежность хранения информации. Минимальными условиями, при соблюдении которых можно удовлетворить эти требования, являются: • наличие транзакционного управления, • хранение избыточных данных (например, с применением методов журнализации), • возможность формулировать ограничения целостности и проверять их соблюдение. В принципе, файл-серверная организация, как она показана на рисунке 2.1, не противоречит соблюдению отмеченных условий. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файлсерверной архитектуре, можно привести популярный в прошлом "сервер баз данных" Informix SE. Длинное замечание: Для сохранения четкости дальнейшего изложения нам необходимо несколько уточнить терминологию. Мы недаром написали "сервер баз данных" в кавычках применительно к СУБД Informix SE. При использовании этой системы копия программного обеспечения СУБД поддерживалась для каждого инициированного пользователем сеанса работы с СУБД. Грубо говоря, для каждого пользовательского процесса, взаимодействующего с базой данных создавался служебный процесс СУБД, который выполнялся на том же процессоре, что и пользовательский процесс (т.е. на стороне клиента). Каждый из этих служебных процессов вел себя фактически так, как если бы был единственным представителем СУБД. Вся синхронизация возможной параллельной работы с базой данных производилась на уровне файлов внешней памяти, содержащих базу данных. Условимся впредь называть такие СУБД не серверами баз данных, а системами управления базами данных, основанными на файл-серверной архитектуре (СУБД-ФС). Под истинным сервером баз данных мы будем понимать программное образование, привязанное к соответствующей базе (базам) данных, существующее, вообще говоря, независимо от существования пользовательских (клиентских) процессов и выполняемое, вообще говоря (хотя и не обязательно) на выделенной аппаратуре (мы намеренно используем не очень конкретные термины "программное образование" и "выделенная аппаратура", потому что их конкретное воплощение различается в разных серверах баз данных). Истинные серверы баз данных существенно сложнее по организации, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное управление базами данных. Везде далее в этом курсе при употреблении термина "сервер баз данных" мы будем иметь в виду истинные серверы баз данных. Но с другой стороны, в большинстве персональных СУБД эти условия не выполняются даже с помощью грубых приемов. В лучшем случае удается частично восполнить недостатки на уровне прикладных программ. В третьих, интерфейс развитых серверов баз данных основан на использовании высокоуровневого языка SQL, что позволяет использовать сетевой трафик между клиентом и сервером баз данных только в полезных целях (от клиента к серверу в основном пересылаются операторы языка SQL, от сервера к клиенту результаты выполнения операторов). В файл-серверной организации клиент работает с удаленными файлами, что вызывает существенную перегрузку трафика (поскольку СУБД-ФС работает на стороне клиента, то для выборки полезных данных в общем случае необходимо просмотреть на стороне клиента весь соответствующий файл целиком). В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 4.2). Рис. 4.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре Краткие выводы. Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Конечно, и в этом случае требуется большая аккуратность конечных пользователей (или администраторов, наличие которых в этом случае сомнительно) для надежного хранения и поддержания целостного состояния данных. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными. 4.2. Клиент-серверные приложения Под клиент-серверным приложением понимается информационную систему, основанную на использовании серверов баз данных . Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 4.3. На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции (пока нас не будет занимать, как строится код приложения). Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения. (Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.) Рис. 4.3. Общее представление информационной системы в архитектуре "клиентсервер" Заметим, что интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения. Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL. Здесь необходимо сделать еще два замечания. Обычно компании, производящие развитые серверы баз данных, стремятся к использованию своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных. Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL. Сервер производит компиляцию полученного оператора. Не будем здесь останавливаться на том, какой целевой язык используется конкретным компилятором; в разных реализациях применяются различные подходы Главное, что в любом случае на основе информации, содержащейся в таблицах-каталогах базы данных производится преобразование непроцедурного представления оператора в некоторую процедуру его выполнения. Далее (если компиляция завершилась успешно) происходит выполнение оператора. Мы снова не будем обсуждать технические детали, поскольку они различаются в реализациях. Рассмотрим возможные действия операторов SQL. Оператор может относиться к классу операторов определения (или создания) объектов базы данных (точнее и правильнее было бы говорить про элементы схемы базы данных или про объекты метабазы данных). В частности, могут определяться домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры. В любом случае, при выполнении оператора создания элемента схемы базы данных соответствующая информация помещается в таблицы-каталоги базы данных (в таблицы метабазы данных). Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения. При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных (мы намеренно не используем здесь термин "результирующая таблица", поскольку в зависимости от конкретного вида оператора результат может быть упорядоченным, а таблицы, т.е. отношения неупорядочены по определению). Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения. При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т.д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения. При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т.д.) также могут срабатывать триггеры, т.е., другими словами, может выполняться серверная часть приложения. Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т.д.). Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента. При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения. Как видно, в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов (рисунок 4.4). Рис. 4.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре С другой стороны, разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают не удовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента. Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных (или, как иногда их называют в русскоязычной литературе, тиражированных) баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных - упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей базы данных. Здесь возможны различные решения - от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень. В любом случае, клиенты становятся более толстыми при том, что сервер тоньше не делается (рисунок 4.5). Рис. 4.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов Сформулируем некоторые предварительные выводы. Архитектура "клиентсервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файлсервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию. При проектировании информационной системы, основанной на этой архитектуре, большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. В идеале, которого, конечно же не бывает, информационная система продолжает нормально функционировать после смены аппаратуры. 4.3. Intranet-приложения Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система - это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа. Возможности и проблемы безопасных информационных Intranet-систем мы рассмотрим в пятой части курса. Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web - Всемирная Паутина). Видимо, для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров, или "обходчиков" избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы (рисунок 4.6) оказывается достаточной для удовлетворения потребностей компании. Рис. 4.6. Простая организация Intranet-системы с использованием средств WWW Однако, при всех своих преимуществах (простота организации, удобство использования, стандартность интерфейсов и т.д.) эта схема обладает сильными ограничениями. Прежде всего, как видно из рисунка 2.6, в информационной системе отсутствует прикладная обработка данных. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу системы, внести изменения в HTML-описания и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы. На самом деле, все перечисленные трудности могут быть разрешены с использованием более развитых механизмов Web-технологии. Эти механизмы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появляются новые возможности. Плохо, потому что отсутствует стандартизация. Что касается логики приложения, то при применении Web-технологии существует возможность ее реализации на стороне Web-сервера. Для этого могут использоваться два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP (рисунок 4.7). Рис. 4.7. Вызов внешней процедуры Web-сервера Аналогичная техника широко используется для обеспечения унифицированного доступа к базам данных в Intranet-системах. Язык HTML позволяет вставлять в гипертекстовые документы формы. Когда браузер натыкается на форму, он предлагает пользователю заполнить ее, а затем посылает серверу сообщение, содержащее введенные параметры. Как правило, к форме приписывается некоторая внешняя процедура сервера. При получении сообщения от клиента сервер вызывает эту внешнюю процедуру с передачей параметров пользователя. Понятно, что такая внешняя процедура может, в частности, играть роль шлюза между Web-сервером и сервером баз данных. В этом случае параметры должны специфицировать запрос пользователя к базе данных. В результате получается конфигурация информационной системы, схематически изображенная на рисунке 4.8. Рис. 4.8. Доступ к базе данных в Intranet-системе На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, а также создание временных "виртуальных" HTML-страниц. Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности языка Java. Java - это интерпретируемый объектноориентированный язык программирования, созданный на основе языка Си++ с удалением из него таких "опасных" средств как адресная арифметика. Мобильные коды (апплеты), полученные в результате компиляции Javaпрограммы, могут быть привязаны в HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой как на рисунке 4.9. Рис.4.9. Доступ к базе данных на стороне клиента Intranet-системы На наш взгляд, Intranet является удобным и мощным средством разработки и использования информационных систем. Как мы уже отмечали, единственным относительным недостатком подхода можно считать постоянное изменение механизмов и естественное отсутствие стандартов. С другой стороны, если информационная система будет создана с использованием текущего уровня технологии и окажется удовлетворяющей потребностям корпорации, то никто не будет обязан что-либо менять в системе по причине появления более совершенных механизмов. 4.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных До сих пор мы рассматривали способы и возможные архитектуры информационных систем, предназначенных для оперативной обработки данных, т.е. для получения текущей информации, позволяющей решать повседневные проблемы корпорации. Однако у аналитических отделов корпорации и у высшего звена управляющего состава имеются и другие задачи: проанализировав поведение корпорации на рынке с учетом сопутствующих внешних факторов и спрогнозировав хотя бы ближайшее будущее, выработать тактику, а возможно, и стратегию корпорации. Понятно, что для решения таких задач требуются данные и прикладные программы, отличные от тех, которые используются в оперативных информационных системах. В последние несколько лет все более популярным становится подход, основанный на концепциях склада данных и системы оперативной аналитической обработки данных. Возможно, в российских условиях трудно производить долговременные прогнозы бизнесдеятельности (слишком изменчивы внешние факторы), но анализ прошлого и краткосрочные прогнозы будущего могут оказаться очень полезными. Прежде чем перейти к обсуждению технических аспектов, коротко обсудим проблемы терминологии. Поскольку термины, связанные со складами данных не так давно появились и на английском языке, и смысл их постоянно уточняется, трудно найти правильные русскоязычные эквиваленты. На сегодняшний день "datawarehouse" разными авторами переводится на русский язык как "хранилище данных", "информационное хранилище", "склад данных". Поскольку термин "хранилище" явно перегружен (он соответствует и английским терминам "storage" и "repository"), в этом курсе мы будем использовать термин "склад данных". Еще хуже дела обстоят с термином "data mart". В четвертом номере журнала "СУБД" за 1996 г. в напечатанных подряд двух статьях авторы переводят этот термин как "витрина данных" и "секция данных" соответственно. Однако в Оксфордском толковом словаре единственным подходящем по смыслу толкованием смысла слова "mart" является "market place". Чтобы не умножать число требуемых сущностей мы будем использовать термин "рынок данных" (обсуждение этого понятия отложим до пятой части курса). Конечно, постепенно терминология будет согласована, но это произойдет только тогда, когда склады данных будут активно использоваться в России. В этом разделе мы не будем рассматривать возможные технологические приемы реализации складов данных, а обсудим соответствующие вопросы на концептуальном уровне. Начнем с того, что главным образом различает оперативные и аналитические информационные приложения с точки зрения обеспечения требуемых данных. Замечание: речь идет о так называемых OLAPсистемах (от On-Line Analitical Processing), т.е. аналитических системах, помогающих принимать бизнес-решения за счет динамически производимых анализа, моделирования и/или прогнозирования данных. Основным источником информации, поступающей в оперативную базу данных является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Тем самым, склад данных должен включать как внутренние корпоративные данные, так и внешние данные, характеризующие рынок в целом. Если для оперативной обработки, как правило, требуются свежие данные (обычно в оперативных базах данных информация сохраняется не более нескольких месяцев), то в складе данных нужно поддерживать хранение информации о деятельности корпорации и состоянии рынка на протяжении нескольких лет (для проведения достоверных анализа и прогнозирования). Как следствие, аналитические базы данных имеют объем как минимум на порядок больший, чем оперативные. Во многих достаточно крупных корпорациях одновременно существуют несколько оперативных информационных систем с собственными базами данных (как мы уже отмечали в этом курсе, это не очень хорошо, но часто неизбежно по историческим причинам). Оперативные базы данных могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую (например, из-за ошибок ввода данных). Склад данных корпорации должен содержать единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оперативных баз данных и быть согласованной. Отсюда следует необходимость наличия компонента склада данных, извлекающего информацию из оперативных баз данных и "очищающего" эту информацию. Оперативные информационные системы проектируются и разрабатываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выбирается часто и небольшими порциями. Поэтому при проектировании оперативной базы данных можно и нужно учитывать этот заранее известный набор запросов (с известными оговорками в связи с возможными переделками информационной системы). Набор запросов к аналитической базе данных предсказать невозможно. Склады данных для того и существуют, чтобы отвечать на неожиданные (ad hoc) запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической базы данных стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.). Оперативные базы данных по своей природе являются сильно изменчивыми. Это учитывается в используемых СУБД. В частности, распространенным механизмом индексации являются B-деревья, модификация которых выполняется достаточно быстро, а строки в таблицах хранятся неупорядоченно. Аналитические базы данных меняются только тогда, когда в них загружается оперативная или внешняя информация. В результате оказывается разумным использовать другие, более быстрые при выполнении операций массовой выборки методы индексации, поддерживать упорядоченность информационных массивов, сохранять заранее вычисленные значения агрегатных функций и т.д. Если для оперативных информационных систем обычно хватает защиты информации на уровне таблиц (по правилам SQL-ориентированных баз данных), то информация аналитических баз данных настолько критична для корпорации, что для ее защиты требуются более тонкие приемы (например, при использовании реляционных баз данных установка индивидуальных привилегий доступа для индивидуальных строк и/или столбцов таблицы). С учетом приведенных замечаний общая архитектура склада данных и системы аналитической обработки данных может выглядеть так, как показано на рисунке 4.10. Рис. 4.10. Схематическое представление архитектуры аналитической информационной системы В 1993 г. основоположник реляционного подхода к организации баз данных Эдвар Кодд, исходя из потребностей систем динамической аналитической обработки данных, сформулировал 12 основных требований к системам, поддерживающим аналитические базы данных. Мы приведем изложение этих требований, чтобы представить точку зрения проектировщика и разработчика системы аналитической обработки данных. Многомерное концептуальное представление данных. Это требование возникает по той причине, что бизнес-пользователь естественно представляет историю и деятельность своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д.). OLAP-модели должны поддерживать это представление и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных. Прозрачность. Для бизнес-пользователя не должно быть существенно, где конкретно расположены средства динамического анализа данных. При разработке OLAP-систем следует придерживаться подхода открытых систем, что позволит размещать средства анализа в любом узле корпоративной сети. Доступность. Логическая схема, с которой работает OLAP-система, должна отображаться в схемы разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление. Согласованная эффективность производства отчетов. Эта эффективность не должна деградировать при увеличении числа измерений. Архитектура "клиент-сервер". Серверный компонент OLAP-системы должен быть достаточно развитым, чтобы разнообразные клиенты могли подключаться к нему с минимальными усилиями и затратами на дополнительное "интегрирующее" программирование. Родовая многомерность. Структурные и операционные возможности работы с каждым измерением данных должны быть эквивалентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному измерению, должна быть применима к любому другому измерению. Управление динамическими разреженными матрицами. Сервер OLAPсистемы должен уметь эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов. Поддержка многопользовательского режима. OLAP-система должна поддерживать многопользовательский доступ к данным (по выборке и изменению), обеспечивая целостность и безопасность данных. Неограниченные операции между измерениями. При выполнении многомерного анализа данных все измерения создаются и обрабатываются единообразно. OLAP-система должна быть в состоянии выполнять соответствующие вычисления между измерениями. Интуитивное манипулирование данными. Манипуляции, подобные смене пути анализа или уровня детализации, должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства. Гибкая система отчетов. Бизнес-пользователь должен иметь возможность манипулировать данными, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется. Неограниченное число измерений и уровней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для каждой аналитической модели. Для каждого измерения должно допускаться неограниченное число определяемых пользователями агрегатов. Основным выводом из материала этого раздела является то, что подход складов данных еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов. Тем не менее, он кажется настолько важным и перспективным, что многие компании (в том числе и ведущие производители СУБД) ведут активную работу, чтобы быть в авангарде этого направления. 4.5. Интегрированные распределенные приложения Нет никаких проблем, если с самого начала информационное приложение проектируется и разрабатывается в духе подхода открытых систем: все компоненты являются мобильными и интероперабельными, общее функционирование системы не зависит от конкретного местоположения компонентов, система обладает хорошими возможностями сопровождаемости и развития. К сожалению, на практике этот идеал является трудно достижимым. По разным причинам (мы перечислим некоторые из них ниже) возникают потребности в интеграции независимо и по-разному организованных информационно-вычислительных ресурсов. Видимо, ни в одной действительно серьезной распределенной информационной системе не удастся обойтись без применения некоторой технологии интеграции. К счастью, теперь существует путь решения этой проблемы, который сам лежит в русле открытых систем, подход, предложенный крупнейшим международным консорциумом OMG (Object Management Group). Остановимся на некоторых факторах, стимулирующих использование методов интеграции разнородных информационных ресурсов (здесь используются материалы статьи Л.А.Калиниченко и др. из журнала "СУБД" N 4, 1995 г.). Неоднородность, распределенность и автономность информационных ресурсов системы. Неоднородность ресурсов может быть синтаксической (при их представлении используются, например, разные модели данных) и/или семантической (используются разные виды семантических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна и чисто реализационная неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д. Потребности в интеграционном комплексировании компонентов информационной системы. Очевидно, что наиболее естественным способом организации сложной информационной системы является ее иерархическивложенное построение. Более сложные функционально-ориентированные компоненты строятся на основе более простых компонентов, которые могли проектироваться и разрабатываться независимо (что порождает неоднородность; ниже мы приведем примеры). Реинжинерия системы. После создания начального варианта информационной системы неизбежно последует процесс ее непрерывных переделок (реинжинерии), обусловленный развитием и изменением соответствующих бизнес-процессов корпорации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность. Решение проблемы унаследованных (legacy) систем. Любая компьютерная система (надеюсь, что это не относится к открытым системам в теперешнем понимании; только надеюсь, поскольку неизвестно, как отнесутся к нашим взглядам будущие поколения) со временем становится бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится решать задачу встраивания устаревших информационных компонентов в систему, основанную на новой технологии. Нужно, чтобы эта задача была разрешимой, т.е. чтобы компоненты унаследованных систем сохраняли интероперабельность. Повторно используемые (reusable) ресурсы. Технология разработки информационных систем должна способствовать использованию уже существующих компонентов, что в конечном итоге должно перевести нас от экстенсивного ручного программистского труда к интенсивным методам сборки ориентированной на конкретную область применения информационной системы. Продление жизненного цикла информационной системы. Чем дольше живет и приносит пользу информационная система, тем это выгоднее для корпорации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроектированных и разработанных, вообще говоря, в другой технологии. Решение проблемы интеграции неоднородных информационных ресурсов началось с попыток интеграции неоднородных баз данных. Направление интегрированных или федеративных систем неоднородных БД и мульти-БД появилось в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД. Основной задачей интеграции неоднородных БД является предоставление пользователям интегрированной системы глобальной схемы БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня операторы, понятные соответствующим локальным СУБД. В теоретическом плане проблемы преобразования решены, имеются реализации. При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая тем не менее иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, развивается направление мульти-БД. В системах мульти-БД не поддерживается глобальная схема интегрированной БД и применяются специальные способы именования для доступа к объектам локальных БД. Как правило, в таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД. Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно к собственным проблемам интеграции приходится решать все проблемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно добиться эффективности. Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель данных. В последнее время все чаще предлагается использовать объектно-ориентированные модели, но на практике пока основой является реляционная модель. Поэтому, в частности, включение в интегрированную систему локальной реляционной СУБД существенно проще и эффективнее, чем включение СУБД, основанной на другой модели данных. Основным недостатком систем интеграции неоднородных баз данных является то, что при этом не учитываются "поведенческие" аспекты компонентов прикладной системы. Легко заметить, что даже при наличии развитой интеграционной системы, большинство из указанных выше проблем не решается. Естественным развитием взглядов на информационные ресурсы является их представление в виде набора типизированных объектов, сочетающих возможности сохранения информации (своего состояния) и обработки этой информации (за счет наличия хорошо определенного множества методов, применимых к объекту). Наиболее существенный вклад в создание соответствующей технологии внес международный консорциум OMG, выпустивший ряд документов, в которых специфицируются архитектура и инструментальные средства поддержки распределенных информационных систем, интегрированных на основе общего объектно-ориентированного подхода. В базовом документе специфицируется эталонная модель архитектуры (OMA - Object Management Architecture) распределенной информационной системы (рисунок 4.11). Рис. 4.11. Эталонная модель OMA Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB - Object Request Broker). ORB, общие средства (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории "общие средства" (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.). В основе OMA лежит базовая объектная модель COM (Core Object Model), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах. Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (Interface Definition Language), который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMG API брокера объектных заявок. Правила построения и использования ORB определены в документе OMG CORBA (Common Object Request Broker Architecture).. Основным выводом из материала данного раздела является то, что проблемы интеграции неоднородных информационных ресурсов являются актуальными для корпораций и существуют технологии, позволяющие решать эти проблемы. В заключение второй части курса повторим, что приведенная классификация методов и технологий не является ортогональной. В реальной жизни требуется использовать разумные сочетания технологических и архитектурных решений. Цель курса не состоит в том, чтобы выдать готовые рецепты построения информационной системы. Мы стремимся погрузить слушателей в мир информационных технологий с тем, чтобы впоследствии было проще ориентироваться в этом мире и понимать значение его сущностей. Лекция 6 Специализированные подсистемы (СУБД, SAN и т. д.). Систе́ма управле́ния ба́зами да́нных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных. Основные функции СУБД • управление данными во внешней памяти (на дисках); • управление данными в оперативной памяти с использованием дискового кэша; • журнализация изменений, резервное копирование и восстановление базы данных после сбоев; • поддержка языков БД (язык определения данных, язык манипулирования данными). Обычно современная СУБД содержит следующие компоненты: • ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию, • процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машиннонезависимого исполняемого внутреннего кода, • подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД • а также сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы. Классификации СУБД По модели данных Примеры: • Иерархические • Сетевые • Реляционные • Объектно-ориентированные • Объектно-реляционные По степени распределённости • Локальные СУБД (все части локальной СУБД размещаются на одном компьютере) • Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах). По способу доступа к БД • Файл-серверные В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД. На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком. Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro. • Клиент-серверные Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР. • Встраиваемые Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы. Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР. SAN Сеть хранения данных SAN (Storage Area Network) - это высокоскоростная выделенная сеть передачи данных, связывающая один или несколько серверов с одной или несколькими системами хранения, работающими по протоколу Fibre Channel. Доступ к данным в SAN осуществляется на уровне блоков (в отличие от NAS, где доступ реализован на уровне файлов). Основная идея SAN состоит в отделении устройств хранения данных от сервера и сетевой ОС. Фактически, SAN - это комбинация аппаратных средств и ПО, позволяющая очень большому числу пользователей хранить и совместно использовать информацию. При этом, так как данные не хранятся на сервере корпоративной сети, то на нём могут исполняться другие важные приложения пользователей. Средой передачи в Fibre Channel могут быть как медный кабель (длиной до 25 м), так и оптоволоконный кабель (длиной до 10 км), позволяющий обеспечивать надёжную защиту от помех. C использованием специальных технологий в настоящее время можно создавать SAN с расстоянием между объектами более 100 км (для этого используются так называемые удлинители extenders). В SAN Fibre Channel могут применяться следующие 4 типа подключения устройств (топологии): - "Точка-точка" (point-to-point) - прямое подключение сервера к устройству или системе хранения. - "Петля с арбитражным доступом" (Fibre Channel Arbitrated Loop - FC-AL) передача данных осуществляется последовательно, от узла к узлу (по петле). Перед началом передачи передающее устройство инициализирует арбитраж за право использования среды передачи данных (откуда и происходит название топологии FC-AL). При использовании топологии FC-AL возможно подключение до 126 устройств хранения данных и серверов. Для этого используются концентраторы Fibre Channel. С их помощью возможно подключать и отключать устройства, находящиеся в петле FC-AL, без остановки всей системы, так как при отключении какого-либо устройства в петле концентратор автоматически замыкает, а в случае подключения нового устройства - автоматически размыкает её. При использовании топологии FC-AL полоса пропускания делится между всеми подключенными устройствами. Единовременно могут взаимодействовать только два устройства. - "Коммутируемое подключение" (switched, FC-SW). Устройства хранения и серверы (всего до 16 млн. единиц) подключаются к коммутатору Fibre Channel. Полоса пропускания доступна для каждого подключенного устройства. При обращении к внешней памяти допускается одновременное взаимодействие нескольких устройств. - "Cмешанное подключение". Для подключения используются как коммутаторы, так и концентраторы. Лекция 7 Распределенные информационные системы. Обычно, распределенной считают такую систему, в которой функционирует более одного сервера БД. Это применяется для уменьшения нагрузки на сервер и обеспечения работы территориально удаленных подразделений. Различная сложность создания, модификации, сопровождения, интеграции с другими системами позволяют разделить ИС на классы малых, средних и крупных распределенных систем. Малые ИС имеют небольшой жизненный цикл (ЖЦ), ориентацию на массовое использование, невысокую цену, невозможность модификации без участия разработчиков, использующие в основном настольные системы управления базами данных (СУБД) , однородное аппаратно-программное обеспечение, не имеющие средств обеспечения безопасности. Крупные корпоративные ИС, системы федерального уровня и другие имеют длительный жизненный цикл, миграцию унаследованных систем, разнообразие аппаратно-программного обеспечения, масштабность и сложность решаемых задач, пересечение множества предметных областей, аналитическую обработку данных, территориальную распределенность компонент. Распределённые базы данных (РБД) — совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети. РБД состоит из набора узлов, связанных коммуникационной сетью, в которой: каждый узел — это полноценная СУБД сама по себе; узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле. Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах. Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система. Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать: Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами. Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД. Типы распределённых баз данных Распределённые базы данных Мультибазы данных с глобальной схемой. Система мультибаз данных — это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД. Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования. Мультибазы с общим языком доступа — распределённые среды управления с технологией «клиент-сервер» Лекция 8 Архитектуры web-приложений. Web-приложения (web applications, часто их называют Интернетприложениями, internet applications) представляют собой набор страниц, объединенных общей функциональностью. Все Web-приложения являются клиент-серверными, что, очевидно, определяется технологией построения Интернета. В приложениях обычно задействуются все вышеперечисленные технологии, от DHTML, исполняемом в клиентском браузере, до расширений Web-сервера. В настоящий момент Web-приложения используются как внутри предприятий в локальных сетях, так и в Интернете - это широко известные Интернет-магазины. Архитектура Web-приложений Все Web-приложения можно условно разбить на три составные части: серверная часть, клиентское приложение и интерфейс. Серверную часть образует Web-сервер, возвращающий страницы приложения по запросам пользователя. Чаще всего эти страницы создаются динамически на основе информации, обрабатываемой приложением. Именно на создание страниц "на лету" направлены различные расширения Web-серверов, одно из которых - CGI - уже было ранее упомянуто.Клиентское приложение (браузер) последовательно запрашивает страницы с сервера, используя Dynamic HTML для управления интерфейсом и частичной обработки информации на компьютере клиента. Пользовательский интерфейс специально выделен отдельным пунктом, так как именно формированием клиентского интерфейса и работой с ним Web-приложения отличаются от привычных клиент-серверных приложений. В последнем случае клиентское приложение обменивается с сервером только данными, используя для формирования интерфейса ресурсы приложения. В Web-приложениях интерфейс практически полностью формируется на сервере, оставляя для исполнения клиентом только управление созданной страницей. Более того, существующие стандарты на браузеры накладывают дополнительную специфику на модель поведения приложения. В частности, два свойства, которые необходимо принимать во внимание при разработке приложения -наличие истории просмотра страниц и произвольный доступ к любой странице приложения по известному адресу. Последнее свойство обязательно должно учитываться в приложениях, использующих авторизацию пользователя. Другая серьезная проблема в разработке Web-приложения отслеживание сессии конкретного пользователя. Дело в том, что по определению HTTP-протокол не имеет понятия текущего состояния (stateless), т.е. очередной запрос страницы абсолютно не зависит от предыдущих запросов и потому не требует уникального идентификатора. Для отслеживания последовательных запросов и идентификации пользователя используются так называемые cookies. Лекция 9 Сервис–ориентированная архитектура (SOA). Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Программные комплексы, разработанные в соответствии с сервисориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST). Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем. Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными. Главное, что отличает SOA, это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу. Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall. SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса. Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов. SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов. Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнессервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов. Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований. Облачные системы. Облачные (рассеяные) вычисления (англ. cloud computing, также используется термин Облачная (рассеянная) обработка данных) — технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять и не должен заботиться об инфраструктуре, операционной системе и собственно программном обеспечении, с которым он работает. Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали. Согласно документу IEEE, опубликованному в 2008 году, «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.». Облачная обработка данных как концепция включает в себя понятия: − инфраструктура как услуга, − платформа как услуга, − программное обеспечение как услуга, − данные как услуга, − рабочее место как услуга. и другие технологические тенденции, общим в которых является уверенность, что сеть Интернет в состоянии удовлетворить потребности пользователей в обработке данных. Например, Google Apps обеспечивает приложения для бизнеса в режиме онлайн, доступ к которым происходит с помощью Интернетбраузера, в то время как ПО и данные хранятся на серверах Google. Терминология Хотя термин «облачные вычисления» является устоявшимся, в русском языке он имеет другое значение, нежели оригинал. «Cloud» помимо облака имеет и иное значение, а именно рассеяный; собственно значение «рассеянный» и подразумевается в англоязычной терминологии. Платформы Для обеспечения согласованной работы ЭВМ, которые предоставляют услугу облачных вычислений используется специализированное ПО, обобщённо называющееся "middleware control". Это ПО обеспечивает мониторинг состояния оборудования, балансировку нагрузки, обеспечение ресурсов для решения задачи. Облачные вычисления и виртуализация Для облачных вычислений основным предположением является неравномерность запроса ресурсов со стороны клиента(ов). Для сглаживания этой неравномерности для предоставления сервиса между реальным железом и middleware помещается ещё один слой - виртуализация серверов. Серверы, выполняющие приложения виртуализируются и балансировка нагрузки осуществляется как средствами ПО, так и средствами распределения виртуальных серверов по реальным. Лекция 10 Функциональные уровни информационной системы. 1. Суть и назначение декомпозиции Сложность — объективна и представляет собой интегральное свойство, присущее системе, состоящей из многих элементов, имеющих различные свойства, либо ведущих себя не типичным для остальных элементов образом. В случае, когда элементы, составляющие систему, обладают элементарными (не сложными) свойствами, сложность системы тем не менее может быть высокой, т.к. имеет синергетическую природу. Чтобы справиться с колоссальной сложностью, присущей большим программным системам, необходимо сформировать определенный подход к разбиению системы на части и к созданию общей архитектуры системы на основе критериев декомпозиции. После выполнения декомпозиции информационной системы и определения интерфейсов между программными подсистемами, каждую подсистему допустимо разрабатывать независимо. Таким образом, сутью декомпозиции является уменьшение сложности информационной системы, а назначением — обеспечение возможности ее наилучшего осмысления с целью воплощения в заданной техническими требованиями форме. 2. Основные критерии декомпозиции Известно множество специальных критериев декомпозиции целого на части. Критерии декомпозиции бывают составными, т.е. состоящими из других критериев и предельными, — не состоящими из других критериев. Таким образом, предельные критерии допустимо назвать строительными блоками критериальной базы, или просто критериальной базой, используемой в теории проектирования ПО. По этому, зная критериальную базу и правила построения составных критериев, можно строить специальные критерии для декомпозиции систем с неизвестной ранее топологией. Рассмотрим перечень наиболее употребимых составных критериев: − Критерий разбиения на функции системы (функциональный критерий или критерий декомпозиции прецедентов) − Критерий разбиения на подсистемы (модульный критерий) − Критерий разбиения на классы (критерий классификации) − Критерий разбиения на объекты (критерий объектной декомпозиции) − Критерий разбиения на состояния (критерий анализа автоматной модели) − Критерий разбиения на задачи (критерий синтеза асинхронной архитектуры) − Критерий определения интерфейсов (критерий композиции интерфейса). Проанализируем вышеприведенные критерии на предмет их состава при помощи критерия обобщения/специализации. В результате получим следующий перечень предельных критериев: − Критерий пространственной декомпозиции (критерий распределенности или географичкеский критерий) − Критерий временной декомпозиции (темпоральный критерий) − Критерий логической декомпозиции (критерий обобщения/специализации) Правила построения составных критериев: Есть три базовые координаты: место в пространстве, место во времени и логическая связь со смежными сущностями (объектами предметной области) В зависимости от того, какая проекция предметной области (системы) рассматривается, в составном критерии фигурирует тот или иной предельный критерий или критерии К базовому критерию или критериям, образующим в проекцию, добавляется заданная специализация, отличающая один составной критерий от других Связь проекций предметной области (системы) и составных критериев: Функциональный критерий декомпозиции является логической проекцией рассматриваемой системы; состоит из критерия логической декомпозиции и специализирован рассмотрением функций системы Модульный критерий является струкрурной проекцией системы; состоит из критериев логической, пространственной и временной декомпозиции, специализирован рассмотрением состава системы из замкнутых функциональных блоков Критерий классификации является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением состава структуры системы из программных объектов Критерий объектной декомпозиции является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением состава структуры системы из объектов, являющихся аналогами объектам предметной области Критерий разбиения на состоания является темпоральной проекцией рассматриваемой системы (чаще объекта); состоит из критериев логической и временной декомпозиции, специализирован рассмотрением реакции системы на внешние события Критерий разбиения на задачи является темпоральной проекцией рассматриваемой системы; состоит из критериев логической и временной декомпозиции, специализирован рассмотрением взаимодействия системы с другими системами Критерий определения интерфейса является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением способов межобъектного взаимодействия в системе. 3. Общие рекомендации по декомпозиции Создание диаграммы того или иного типа ведет к рассмотрению системы под той или иной проекцией, или, как обычно говорят, под определенным углом зрения. Рассматривая различные диаграммы разработчик тем самым полнее осознает структуру и поведение системы, что ведет к более обдуманным проектным решениям. Таким образом, первая рекомендация по декомпозиции — по возможности, создать и проанализировать как можно больше проекций рассматриваемой системы. Необходимо помнить, что не существует формальных процедур, ограничивающих проведение декомпозиции в общем виде. Но отсутствие решения в общем виде не значит его отсутствие в частном случае. Таким образом, вторая рекомендация по декомпозиции — перед началом декомпозиции или уже в процессе ее проведения, наметить рамки (границы) декомпозиции, по достижению которых декомпозиция будет считаться проведенной. Например, проводим декомпозицию до тех пор пока: Не пройдет отведенный промежуток времени Более менее станут понятны структура и поведение системы Будут достигнуты какие-то заданные количественные характеристики Как бы мы не старались локализовать (инкапсулировать) функциональность в объектах или модулях, суть функционирования системы — взаимодействие ее компонентов. Синергетические качества системы, такие как надежность и производительнсть — будут присущи системе только в том случае, когда ее компоненты взаимодействуют оптимальным образом (и сами при этом отвечают заданным критериям производительности и надежности). По этому, полная независимость в разработке подсистем — наиболее прямолинейный и не самый эффективный подход, таящий в себе ряд негативных качеств, влияющих на итоговые потребительские характеристики системы в целом. Таким образом, третья рекомендация по декомпозиции — нахождение и локализация в одном или нескольких классах или модулях абстрактной функциональности с целью использования ее в других, более специфичных классах/модулях. Абстрактная функциональность, как правило, мало связана с прикладной задачей и выполняет вспомогательные (служебные) функции. Например, отличный кандидат на вынос в отдельный модуль следующая функциональность: − Ввод/вывод в файловую систему − Взаимодействие с базой данных − Протоколирование работы системы − Взаимодействие с удаленной системой посредством сети Требования, предъявляемые к информационным системам Информационная система должна соответствовать требованиям гибкости, надежности, эффективности и безопасности. Гибкость Гибкость, способность к адаптации и дальнейшему развитию подразумевает возможность приспособления информационной системы к новым условиям, новым потребностям предприятия. Выполнение этих условий возможно, если на этапе разработки информационной системы использовались общепринятые средства и методы документирования, так что по прошествии определенного времени сохранится возможность разобраться в структуре системы и внести в нее соответствующие изменения, даже если все разработчики или их часть по каким-либо причинам не смогут продолжить работу. Любая информационная система рано или поздно морально устареет, и станет вопрос о ее модернизации или полной замене. Разработчики информационных систем, как правило, не являются специалистами в прикладной области, для которой разрабатывается система. Участие в модернизации или создании новой системы той же группы проектировщиков существенно сократит сроки модернизации. Вместе с тем возникает риск применения устаревших решений при модернизации системы. Рекомендация в таком случае одна — внимательнее относиться к подбору разработчиков информационных систем. Надежность Надежность информационной системы подразумевает ее функционирование без искажения информации, потери данных по «техническим причинам». Требование надежности обеспечивается созданием резервных копий хранимой информации, выполнения операций протоколирования, поддержанием качества каналов связи и физических носителей информации, использованием современных программных и аппаратных средств. Сюда же следует отнести защиту от случайных потерь информации в силу недостаточной квалификации персонала. Эффективность Система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на нее задачи в минимальные сроки. В любом случае оценка эффективности будет производиться заказчиком, исходя из вложенных в разработку средств и соответствия представленной информационной системы его ожиданиям. Негативной оценки эффективности информационной системы со стороны заказчика можно избежать, если представители заказчика будут привлекаться к проектированию системы на всех его стадиях. Такой подход позволяет многим конечным пользователям уже на этапе проектирования адаптироваться к изменениям условий работы, которые иначе были бы приняты враждебно. Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика, тем с меньшими затратами и в более короткие сроки система будет создана. Кроме того, заказчик, не являясь специалистом в области разработки информационных систем, может не знать о новых информационных технологиях. Контакты с заказчиком во время разработки для него информационной системы могут подтолкнуть заказчика к модернизации его аппаратных средств, применению новых методов ведения бизнеса, что отвечает потребностям, как заказчика, так и проектировщика. Заказчик получает рост эффективности своего предприятия, проектировщик — расширение возможностей, применяемых при проектировании информационной системы. Эффективность системы обеспечивается оптимизацией данных и методов их обработки, применением оригинальных разработок, идей, методов проектирования. Не следует забывать и о том, что работать с системой придется обычным людям, являющимся специалистами в своей предметной области, но зачастую обладающим весьма средними навыками в работе с компьютерами. Интерфейс информационных систем должен быть им интуитивно понятен. В свою очередь, разработчик-программист должен понимать характер выполняемых конечным пользователем операций. Рекомендациями в этом случае могут служить повышение эффективности управления разработкой информационных систем, улучшение информированности разработчиков о предметной области. Безопасность Под безопасностью, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют доступа к информационным ресурсам организации, кроме тех, которые для них предназначены. Защита информации от постороннего доступа обеспечивается управлением доступа к ресурсам системы, использованием современных программных средств защиты информации. В крупных организациях целесообразно создавать подразделения, основным направлением деятельности которых было бы обеспечение информационной безопасности, в менее крупных организациях назначать сотрудника, ответственного за данный участок работы. Помимо злого умысла, при обеспечении безопасности информационных систем приходится сталкиваться еще с несколькими факторами. В частности, современные информационные системы являются достаточно сложными программными продуктами. При их проектировании с высокой вероятностью возможны ошибки, вызванные большим объемом программного кода, несовершенством компиляторов, человеческим фактором, несовместимостью с используемыми программами сторонних разработчиков в случае модификации этих программ и т.п. Поэтому за фазой разработки информационной системы неизбежно следует фаза ее сопровождения в процессе эксплуатации, в которой происходит выявление скрытых ошибок и их исправление. Требование безопасности обеспечивается современными средствами разработки информационных систем, современной аппаратурой, методами защиты информации, применением паролей и протоколированием, постоянным мониторингом состояния безопасности операционных систем и средств их защиты. Жизненный цикл информационных систем Любую организацию можно рассматривать как совокупность взаимодействующих элементов (подразделений), каждый из которых может иметь свою, достаточно сложную, структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В общем случае можно выделить три вида связей между подразделениями предприятия: • функциональные связи — каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса; • информационные связи — подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.); • внешние связи — некоторые подразделения взаимодействуют с внешними системами, причем их взаимодействие также может быть как информационным, так и функциональным. В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения: • по содержанию действий разработчиков (групп разработчиков) — в данном случае рассматривается статический аспект процесса разработки, описываемый в терминах основных потоков работ (исполнители, действия, последовательность действий и т. п.); • по времени или по стадиям жизненного цикла разрабатываемой системы — в данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов. ИС. Методы проектирования ИС Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности. Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации. Проектирование информационных систем представляет сложный многоступенчатый вид деятельности, без научной организации которого немыслимо создание и использование современных сложных ИС, в том числе, в образовании, предпринимательстве, менеджменте и других областях жизнедеятельности общества. Понятие ИС Информационная система – комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, информационные ресурсы, а также системный персонал, обеспечивающий поддержку динамической информационной модели. ИС стала неотъемлемой частью функционирования практически любой организации, поэтому нет необходимости обсуждать вопрос актуальности разработки и внедрения ИС. Однако вопрос системности подходов к их проектированию и качества разработки до сих пор является злободневным. Общие методы и технологии проектирования ИС В информационных системах методы реализуются через конкретные информационные технологии и поддерживающие их стандарты, инструкции и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла ИС. Методы проектирования ИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям. Так, по степени автоматизации методы проектирования разделяются на: • ручное, при котором проектирование компонентов ИС осуществляется без использования специальных инструментальных программных средств, а программирование – на алгоритмических языках; • компьютерное, при котором производится генерация или конфигурирование (настройка) проектных решений на основе использования специальных инструментальных программных средств. По степени использования типовых проектных решений различают следующие методы проектирования: • оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к автоматизированным информационным системам (АИС). Характоризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которыые в максимальной степени отражают все его особенности; • типовое, предполагающее конфигурирование ИС из готовых типовых проектных решений (программных модулей). Выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты, как обобщение опыта для некоторых групп организационно-экономических систем или видов работ, в каждом конкретном случае связаны со множеством специфических особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной документации. По степени адаптивности проектных решений выделяют методы: • реконструкции, когда адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей); • параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми параметрами; • реструктуризации модели, когда изменяется модель проблемной области, на основе которой автоматически заново генерируются проектные решения. Сочетание различных признаков классификации методов обусловливает характор используемых технологий проектирования ИС, среди которых выделяют два основных класса: каноническую и индустриальную технологии. Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий не исключает использования в отдельных случаях канонических. Методы проектирования ИС подразумевают использование определенных программных и аппаратных средств, составляющих инструментальные средства программирования ИС. Метод проектирования включает совокупность трех составляющих: пошаговой процедуры, определяющей последовательность технологических операций проектирования; • критериев и правил, используемых для оценки результатов выполнения технологических операций; • нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Практически любой технологический процесс может быть частью сложного процесса. Он может включать в себя набор простых (менее сложных) технологических процессов и операций. Он может начинаться с любого уровня и не включать, например, этапы или операции, а состоять только из действий. Для реализации этапов технологического процесса могут использоваться разные программные среды, технологические операции и инструкции. Технологическую операцию считают элементарным (простым) технологическим процессом. При этом информационная операция – это отдельная законченная часть процесса (изменение содержания областей смыслового пространства субъекта) или инструкция. Технологические инструкции, составляющие основное содержание технологии, состоят из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. При проектировании ИС должны быть сформированы общие требования к ней (один из ключевых факторов успеха), поскольку изменения одних блоков, элементов и задач может повлечь за собой изменение к другим, связанным с ними элементам и процессам. При этом возникает риск, что система не сможет полностью или частично реализовать поставленные перед ней задачи, а неконтролируемые изменения и затраты на них могут привести к бесконечному переделыванию и доделыванию системы [16]. • Чем больше число задач, требующих изменения, чем больше они критичны для проектируемой системы, тем должен быть выше уровень компетенции ее разработчиков и ИТ-специалистов организации, в которой предполагается внедрить такую систему. Поскольку требования к системе могут часто и значительно меняться, необходимо организовать доступ всем участникам проекта к информации о проекте, оперативный обмен информацией между ними, а также сбор и систематизацию требований и решений. В этом случае должна существовать инфраструктура сопровождения и развития системы, включающая средства управления требованиями и изменениями, контроль версий и др. Реальное применение любой технологии проектирования, разработки и сопровождения ИС невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К ним относят стандарты: проектирования; • оформления проектной документации; • пользовательского интерфейса. Проектирование вообще и ИС в частности обычно осуществляется поэтапно (рис. 12). В общем случае основные этапы проектирования, заключаются в проведении некоторой последовательности исследований. • Рисунок 12 – Этапы (последовательность) исследований Исследования заканчиваются формированием требований и разработкой на их основе технического задания (ТЗ), в разделе конкретных видов деятельности которого формулируются цели и задачи, области применения и пользователи АИС, устанавливаются источники исходных данных, определяются информационные потребности пользователей и др. Наиболее часто при проектировании ИС используют технологии и методы системного проектирования. Системное (предварительное, концептуальное) проектирование включает в себя следующие стадии: • определение общих целей проектирования с формированием локальных (отдельных) целей разработки; • формирование концепции системы (объекта исследования) и подготовки данных для создания модели объекта; • разработки описания системы в виде структур объекта проектирования и построения функциональных подсистем объекта; • формализация задач проектирования, в том числе, формирование области поиска решений, систем предпочтений и ограничений, требований к объекту и т. п. Результатом системного (концептуального) проектирования является разработка технического задания (ТЗ) и, при необходимости, технико-экономического обоснования. Концептуальное проектирование порой называют техническим. Его основными этапами являются: • предварительное проектирование; эскизное (рабочее или техно-рабочее) проектирование; • изготовление, испытания и доводка опытного образца. Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы. При этом оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования. После построения проекта уточняется исходный бизнес-план. Выходными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточненный бизнес-план [17]. В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность внесения изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны «Заказчика», так и «Разработчика». Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа. • На стадиях разработки, интеграции и тестирования должна быть создана тестовая база данных (БД) и тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация БД и приложений. Приложения интегрируются в систему, проводится их тестирование в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему. В результате такого проектирования должна быть получена логическая структура системы (подсистемы, модуля и др.), схемы вводы, вывода, представления, преобразования данных и т. п. В соответствии с уставными правилами и документацией проекта заключительный этап создания системы предполагает комплексное тестирование всех ее компонентов, обучение пользователей, постоянное администрирование и др. Стадия внедрения включает в себя действия по установке и внедрению баз данных и приложений. Основной результат стадии – готовая к эксплуатации и перенесенная на программно-аппаратную платформу Заказчика версия системы, документация сопровождения и акт приемочных испытаний по результатам опытной эксплуатации. На стадии эксплуатации осуществляется постоянный (лучше – автоматический) контроль работоспособности системы (мониторинг) с целью отслеживания состояния объектов, своевременного выявления ошибок и нештатных ситуаций, ее развития. Стадии сопровождения и развития включают процессы и операции, связанные с регистрацией, диагностикой и локализацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространением новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием системы. Стадия развития фактически является повторной итерацией стадии разработки. Концептуальное проектирование системы характоризуется сжатыми сроками. По этой причине выполнение работ, связанных с ним и предпроектным обследованием объекта могут осуществляться параллельно или перекрываться по времени их выполнения. При проектировании, в т. ч. при решении проблем автоматизации процессов, обычно изначально принимается один из двух вариантов: создание системы, решающей сиюминутные задачи, или включающей и перспективные задачи («на вырост»), учитывающие будущие потребности. В первом случае можно выбрать недорогое решение и быстро его реализовать. Однако высока вероятность, что достаточно скоро такую систему потребуется в значительной степени модернизировать или заменить. Во втором случае потребуется более серьезная проработка требований и технических решений, влекущая за собой увеличение сроков выполнения и стоимости проекта. Но в этом случае возможно на гораздо больший период времени продлить эффективное функционирование созданной таким образом системы. Однако большие инвестиции сопряжены с бóльшими рисками. Поэтому рекомендуется разбивать предстоящие работы на небольшие этапы, реализация которых способна принести конкретный и ощутимый результат, обеспечивающий решение поставленной задачи. В этом случае при минимальных инвестициях можно обеспечить быструю отдачу и создать фундамент дальнейшего развития системы, способствующий, в том числе, изучению полученных результатов, корректировки дальнейших действий и т. п. Таким образом, разработка системы приобретает цикличный характор. И хотя подобный подход несколько более затратный, чем комплексное решение масштабной задачи, он позволяет уменьшить высокие риски, связанные с изменениями требований к разрабатываемой системе. Не следует упускать из виду, что быстрое развитие науки, техники и технологий приводит к быстрому старению используемых методов и систем, что отрицательно влияет на эффективность их использования. При этом поэтапно вносить изменения в отдельные компоненты системы значительно проще, чем заменять ее полностью. Кроме того, обычно требуется обеспечить быстрый возврат инвестиций, что достаточно сложно организовать при внедрении комплексных решений. Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объему и ряду других показателей: крупные, средние и малые (мелкие) проекты. При реализации крупных проектов обычно прибегают к помощи хорошо зарекомендовавших себя крупных компаний-интеграторов, в том числе консалтинговых и внедренческих организаций. Для реализации средних проектов стараются обойтись своими силами и (или) используют готовые решения, которые стремятся адаптировать под конкретные требования организации-заказчика. Малые проекты характоризуются использованием готовых решений и, в ряде случаев, адаптацией их под конкретные условия использования. Проектирование ИС начинается с составления в текстовой и (или) графической форме плана работ. На первом этапе проектирования необходимо выяснить требования пользователей к системе и на основании этих требований сформировать макет системы. Предпочтительно осуществлять проектирование модульным методом. Проектирование информационных систем непосредственно связано с их программированием, поэтому значительная часть проектных работ связана с программированием ИС. Модульное программирование – метод разработки программ, предполагающий разбиение программы на независимые модули. Считается, что модуль должен обладать оптимальными размерами (как правило, целиком помещаться на экране дисплея) и что разделение большой программы на модули облегчает ее разработку, отладку и сопровождение. Программный модуль, объединяющий в себе данные (свойства) и операции над ними (методы), называют объектом. Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики. На выбор средств проектирования могут существенно повлиять следующие особенности методов проектирования: • ориентация на создание уникального или типового проекта; • итерационный характор процесса проектирования; • возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей; • жесткая дисциплина проектирования и разработки при их коллективном характоре; • необходимость отчуждения проекта от разработчиков и его последующего централизованного сопровождения. Проектирование информационной системы – это один из важнейших этапов ее существования то, с чего, собственно, должна начинаться ее жизнь. Таким образом, прежде чем проектировать сеть, нужно понять, какие задачи будет решать сеть, какими будут основные потоки трафика, как физически будут расположены пользователи и ресурсы, нужно ли задание приоритетов видов трафика, как будут решаться вопросы защиты информации внутри сети, как сеть будет подключена к интернету, как решить задачи управления правами доступа пользователей. Кроме того, в задачу предпроектного исследования входит изучение состояния зданий и сооружений в месте развертывания сети, анализ существующей инфраструктуры. Эта информация жизненно необходима как для постановки задачи проектирования, так и для самого проектирования. Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем [1]. Классы ИС Информационная система. Информация. В широком смысле ИС есть совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать надлежащих людей надлежащей информацией. ИС в узком смысле рассматривают как программно-аппаратную систему, предназначенную для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствии с заложенной в нее логикой обработки, возможность получения, модификации и хранения информации. Основная задача информационных систем Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. Современные ИС немыслимы без использования баз данных и СУБД, поэтому термин «информационная система» на практике сливается по смыслу с термином «система баз данных» [24]. По степени распределенности отличают: настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере; распределенные (distributed) ИС, в которых компоненты распределены по нескольким компьютерам. Распределенные ИС, в свою очередь, разделяют на: файл-серверные ИС (ИС с архитектурой «файл-сервер»); клиент-серверные ИС (ИС с архитектурой «клиент-сервер»). В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях. В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся только клиентские приложения. В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные [23]. Классификация по архитектуре В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер базы данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую. В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения трехзвенной архитектуры – современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено – веб-сервер с соответствующим серверным программным обеспечением. Классификация по степени автоматизации По степени автоматизации ИС делятся на: • автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала); • автоматические: информационные системы, в которых автоматизация является полной, то есть вмешательство персонала не требуется или требуется только эпизодически. «Ручные ИС» («без компьютера») существовать не могут, поскольку существующие определения предписывают обязательное наличие в составе ИС аппаратно-программных средств. Вследствие этого понятия «автоматизированная информационная система», «компьютерная информационная система» и просто «информационная система» являются синонимами. Классификация по характору обработки данных По характору обработки данных ИС делятся на: информационно-справочные, или информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде; ИС обработки данных, или решающие ИС, в которых данные подвергаются обработке по сложным алгоритмам. К таким системам в первую очередь относят автоматизированные системы управления и системы поддержки принятия решений. Классификация по сфере применения Поскольку ИС создаются для удовлетворения информационных потребностей в рамках конкретной предметной области, то каждой предметной области (сфере применения) соответствует свой тип ИС. Перечислять все эти типы не имеет смысла, так как количество предметных областей велико, но можно указать в качестве примера следующие типы ИС: Экономическая информационная система – информационная система, предназначенная для выполнения функций управления на предприятии. Медицинская информационная система – информационная система, предназначенная для использования в лечебном или лечебнопрофилактическом учреждении. Географическая информационная система – информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных (пространственных данных). Классификация по охвату задач (масштабности) Персональная ИС предназначена для решения некоторого круга задач одного человека. Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения. Корпоративная ИС автоматизирует все бизнес-процессы целого предприятия (организации) или их значительную часть, достигая их полной информационной согласованности, безызбыточности и прозрачности. Такие системы иногда называют информационными системами предприятия и системами комплексной автоматизации предприятия. Методы программной инженерии в проектировании ИС Информационная система (ИС) – это система, предназначенная для ведения информационной модели, чаще всего – какой-либо области человеческой деятельности. Эта система должна обеспечивать средства для протекания информационных процессов: хранение, передача, преобразование информации. Информационной системой называют совокупность взаимосвязанных средств, которые осуществляют хранение и обработку информации, также называют информационновычислительными системами. В информационную систему данные поступают от источника информации. Эти данные отправляются на хранение либо претерпевают в системе некоторую обработку и затем передаются потребителю. Программная инженерия – это область компьютерной науки и технологии, которая занимается построением программных систем. Это инженерная дисциплина, которая связана со всеми аспектами производства программного обеспечения (ПО) от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств. Одним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса. Жизненный цикл ПО – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл – процесс построения и развития ПО. Жизненный цикл разбивается на отдельные процессы. Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: • Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать); • Разработка проекта программы (результат – описание того, как программа будет работать); • Кодирование (результат – исходный код и файлы конфигурации); • Тестирование программы (результат – контроль соответствия программы требованиям); • Документирование (результат – документация к программе); • Сопровождение (внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям). Модель жизненного цикла ПО – структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. Модель задается в виде практических этапов, необходимых для создания ПО. В модели мы говорим, что и как мы будем делать, т. е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять. Выбор модели процесса является первым шагом в создании ПО. Правильный выбор модели очень важен, т. к. во многом определяет успех проекта. Основные концепции программной инженерии сконцентрировались и формализовались в целостном комплексе систематизированных международных стандартов, охватывающих и регламентирующих практически все процессы жизненного цикла сложных программных средств. Несколько десятков стандартов этого комплекса допускают целеустремленный отбор необходимых процессов, в зависимости от характеристик и особенностей конкретного проекта, а также формирование на их базе проблемноориентированных профилей стандартов для определенных типов проектов и/или предприятий. Процесс стандартизации и сертификации давно вошел и в программную инженерию, где он составляет основу промышленного производства программных продуктов. Наиболее известными стандартами программной инженерии являются: • ISO/IEC 12207 – Information Technology – Software Life Cycle Processes – Процессы жизненного цикла программных средств. Стандарт содержит определения основных понятий программной инженерии (в частности программного продукта и жизненного цикла программного продукта). • SEI CMM – Capability Maturity Model (for Software) – модель зрелости процессов разработки программного обеспечения. Стандарт отвечает на вопрос: «Какими признаками должна обладать профессиональная организация по разработке ПО?». • PMBOK – Project Management Body of Knowledge – Свод знаний по управлению проектами. • SWBOK – Software Engineering Body of Knowledge – Свод знаний по программной инженерии – содержит описания состава знаний по разделам (областям знаний) программной инженерии. ACM/IEEE CC2001 – Computing Curricula 2001 – Академический образовательный стандарт в области компьютерных наук. Выделены 4 основных раздела компьютерных наук: Computer science, Computer engineering, Software engineering и Information systems, по каждому из которых описаны области знаний соответствующего раздела, состав и планы рекомендуемых курсов [6]. В настоящее время сообществом SWBOK разрабатывается расширенная версия знаний по программной инженерии, которая включает 15 областей: • • Software Requirements – требования к ПО. • Software Design – проектирование ПО. • Software Construction – конструирование ПО. • oftware Testing – тестирование ПО. • Software Maintenance – сопровождение ПО. • Software Configuration конфигурацией. • Software Engineering Management – управление IT проектом. • Software Engineering Process – процесс программной инженерии. • Software Engineering Models and Methods – модели и методы разработки. • • Software Engineering Professional Practice – описание критериев профессионализма и компетентности. Software Quality – качество ПО. • Software Engineering Economics – экономические аспекты • разработки ПО. Computing Foundations – основы вычислительных технологий, применимых в разработке ПО. • Management – управление Mathematical Foundations – базовые математические концепции и понятия, применимые в разработке ПО. • Engineering Foundations – основы инженерной деятельности. Метод программной инженерии – это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. В этом определении есть две основные составляющие: (а) создание высококачественного продукта и (б) экономически эффективным способом. Иными словами, метод – это то, что обеспечивает решение основной задачи программной инженерии: создание качественного продукта при заданных ресурсах времени, бюджета, оборудования, людей. Обычно выделяют три группы методов: эвристические методы (heuristic methods), касающиеся неформализованных подходов; формальные методы (formal methods), обоснованные математически; методы прототипирования (prototyping methods), базирующиеся на различных формах прототипирования. Методология программной инженерии и стандарты регламентируют современные процессы управления проектами сложных систем и программных средств. Они обеспечивают организацию, освоение и применение апробированных, высококачественных процессов проектирования, программирования, верификации, тестирования и сопровождения программных средств и их компонентов. Тем самым эти проекты и процессы позволяют получать стабильные, предсказуемые результаты и программные продукты требуемого качества. Программные инструменты предназначены для обеспечения поддержки процессов жизненного цикла программного обеспечения. Инструменты позволяют автоматизировать определенные повторяющиеся действия, уменьшая загрузку инженеров рутинными операциями и помогая им сконцентрироваться на творческих, нестандартных аспектах реализации выполняемых процессов. Инструменты часто проектируются с целью поддержки конкретных (частных) методов программной инженерии, сокращая административную нагрузку, ассоциированную с «ручным» применением соответствующих методов. CASE (Computer-Aided Software Engineering) – набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Инструменты (CASE) программной инженерии (Software Engineering Tools): • Инструменты работы с требованиями (Software Requirements Tools). • Инструменты проектирования (Software Design Tools) – инструменты для создания и проверки программного дизайна. (SADT/IDEF, UML, BPMN/BPEL, Microsoft DSL и т. п.) • Инструменты конструирования (Software Construction Tools) в соответствии с пониманием «конструирования», заданным соответствующей областью знаний SWEBOK. Эти инструменты используются для производства и трансляции программного представления (например, исходного кода), достаточно детального и явного для машинного выполнения. • Редакторы (program editors). Эти инструменты используются для создания и модификации программ и, возможно, ассоциированной с ними документации. • Компиляторы и генераторы кода (compilers and code generators). Неинтерактивные (командные) трансляторы исходного кода. Компиляторы и редакторы в интегрированных средах программирования. К этому • классу также относятся препроцессоры, линковщики/загрузчики, а также генераторы кода. • Интерпретаторы (interpreters). Можно объединить интерпретаторы с компиляторами и генераторами кода, как средства непосредственной подготовки (трансляции) исходного кода к исполнению. • Отладчики (debuggers). Эти инструменты поддерживают процесс конструирования программного обеспечения, но в то же время отличаются от редакторов и компиляторов. Инструменты тестирования (Software Testing Tools) • Генераторы тестов (test generators). Эти инструменты помогают в разработке сценариев тестирования. • Средства выполнения тестов (test execution frameworks). Эти средства обеспечивают среду исполнения тестовых сценариев в контролируемом окружении, позволяющем отслеживать поведение объекта, подвергаемого тестированию. • Инструменты оценки тестов (test evaluation tools). Эти инструменты поддерживают оценку результатов выполнения тестов, помогая определить, в какой степени и где именно обнаруженное поведение соответствует ожидаемому поведению. • Средства управления тестами (test management tools). Инструменты анализа производительности (performance analysis tools). Инструменты сопровождения (Software Maintenance Tools) Эта тема охватывает инструменты, особенно важные для обеспечения сопровождения существующего программного обеспечения, подверженного модификациям: • • Инструменты облегчения понимания (comprehension tools). Эти инструменты помогают человеку в понимании программ. Примерами могут служить различные средства визуализации. • Инструменты реинжиниринга (reengineering tools). Эти инструменты поддерживают деятельность по реинжинирингу, описанную в области знаний SWEBOK «Software Maintenance». Инструменты конфигурационного управления (Software Configuration Management Tools). Инструменты конфигурационного управления делятся на три категории: • Инструменты отслеживания (tracking) дефектов, расширений и проблем. • Инструменты управления версиями. • • Инструменты сборки и выпуска. Эти инструменты предназначены для управления задачами сборки и выпуска продуктов, а также включают средства инсталляции. Инструменты управления инженерной деятельностью (Software Engineering Management Tools). Средства управления деятельностью по программной инженерии делятся на три категории: • Инструменты планирования и отслеживания проектов. • Инструменты управления рисками. • • Инструменты количественной оценки. Инструменты поддержки процессов (Software Process Tools): • Инструменты моделирования. • • • Инструменты управления проектами. Engineering Инструменты конфигурационного управления, поддерживающие работу с актуальными версиями всего комплекса артефактов проекта. • Ролевые платформы разработки программного обеспечения, охватывающие все стадии жизненного цикла и, на сегодняшний день, являющиеся развитием интегрированных средств разработки и CASEинструментов в направлении поддержки «смежной» функциональности – управления требованиями, работ по конфигурационному управлению с поддержкой управления изменениями, тестирования и оценки качества. Инструменты обеспечения качества (Software Quality Tools). Средства обеспечения качества делятся на две категории: • Инструменты инспектирования. Эти средства • • • • • используются для поддержки обзора (review) и аудита. Инструменты (статического) анализа. Эти средства используются для анализа программных артефактов, данных, потоков работ и зависимостей. Из представленного видно, что специалист в области программной инженерии является в первую очередь не только разработчиком прикладного ПО, но и системного ПО, организатором и руководителем (менеджером проектов) промышленной разработки надежных качественных программных систем. Хотя прошло уже много лет с момента определения термина «Программная инженерия», однако и сейчас эта область знаний все еще относительно молода по сравнению с другими областями инженерии, есть все еще большая работа и дебаты вокруг того, что представляет собой «инженерия программного обеспечения», и удовлетворяет ли оно понятию инженерии. Несмотря на «юность» профессии программиста, будущее области программной инженерии радужно. Важнейшей проблемой развития и применения современных систем является обучение и воспитание специалистов в области программной инженерии, использование международных стандартов, способствующих высокому качеству ПО и достоверному его оцениванию. Необходимо обучение специалистов умению формализовать требования и достигать конкретные значения характеристик качества функционирования и применения сложных комплексов программ, с учетом тех ресурсов, которые нужны и доступны для обеспечения и совершенствования этого качества. Гибкие методологии разработки Гибкая методология разработки (англ. Agile software development, agile-методы) – серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Большинство гибких методологий нацелены на минимизацию рисков путем сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи миниприроста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки [9]. К гибким методологиям относятся следующие методологии: 1. Scrum 2. Kanban XP Общий цикл разработки по гибким методологиям выглядит следующим образом: 3. Рисунок 16 – Модели с учетом специфики задачи Регламентация процессов проектирования в отечественных и международных стандартах Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning – методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике. Среди наиболее известных стандартов можно выделить следующие: ГОСТ 34.601-90 – распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла. ISO/IEC 12207:1995 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов. Custom Development Method (методика Oracle) по разработке прикладных информационных систем – технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (FastTrack) или «облегченного подхода», рекомендуемых в случае малых проектов. Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP –это создание и сопровождение моделей на базе UML. Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений. Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы: 1. 2. 3. Основные процессы: • приобретение; • поставка; • разработка; • эксплуатация; • сопровождение. Вспомогательные процессы: • документирование; • управление конфигурацией; • обеспечение качества; • разрешение проблем; • аудит; • аттестация; • совместная оценка; • верификация. Организационные процессы: • создание инфраструктуры; управление; • обучение; • усовершенствование. • В таблице 1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами. Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Informationtechnology – Guidefor ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC 12207 to project management) [10]. Таблица 1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207) Процесс (исполнитель процесса) Приобретение (заказчик) Действия Вход Результат Инициирование Решение о начале работ по внедрению ИС Техникоэкономическое обоснование внедрения ИС Подготовка заявочных предложений Результаты обследования деятельности заказчика Подготовка договора Результаты анализа рынка ИС/ тендера Контроль деятельности поставщика План поставки/ разработки Комплексный тест ИС Техническое задание на ИС Договор на поставку/ разработку Акты приемки этапов работы Приемка ИС Акт приемносдаточных испытаний Окончание таблицы 1 Поставка (разработч ик ИС) Инициирование Техническое задание на ИС Ответ на заявочные предложения Решение руководства об участии в разработке Решение об участии в разработке Коммерческие предложения/ конкурсная заявка Результаты тендера Подготовка договора Планирование исполнения Поставка ИС Техническое задание на ИС Договор на поставку/ разработку План управления проектом План управления проектом Разработанная ИС и документация Реализация/ корректировка Акт приемно-сдаточных испытаний Разработка (разработч ик ИС) Подготовка Техническое задание на ИС Анализ требований к ИС Техническое задание на ИС, модель ЖЦ Проектирование архитектуры ИС Техническое задание на ИС Используемая модель ЖЦ, стандарты разработки План работ Состав подсистем, компоненты оборудования Подсистемы ИС Разработка требований к ПО Проектирование архитектуры ПО Детальное проектирование ПО Кодирование и тестирование ПО Интеграция ПО и квалификационно е тестирование ПО Интеграция ИС и квалификационно е тестирование ИС Спецификации требования к компонентам ПО Архитектура ПО Материалы детального проектирования ПО Спецификации требования к компонентам ПО Состав компонентов ПО, интерфейсы с БД, план интеграции ПО План интеграции ПО, тесты Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам Архитектура ИС, ПО, документация на ИС, тесты Тексты модулей ПО, акты автономного тестирования Оценка соответствия комплекса ПО требованиям ТЗ Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение – поддержка создания компьютеризированных систем. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов: 1. 2. 3. Договорные процессы: • приобретение (внутренние внешнего поставщика); решения или • поставка (внутренние решения или решения внешнего поставщика). Процессы предприятия: • управление окружающей средой предприятия; • инвестиционное управление; • управление ЖЦ ИС; • управление ресурсами; • управление качеством. Проектные процессы: • планирование проекта; • оценка проекта; • контроль проекта; • управление рисками; управление конфигурацией; • решения • управление информационными потоками; • принятие решений. Технические процессы: 4. • определение требований; • анализ требований; • разработка архитектуры; • внедрение; • интеграция; • верификация; • переход; • аттестация; • эксплуатация; • сопровождение; • утилизация. Специальные процессы: 5. • определение и установка взаимосвязей исходя из задач и целей. Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 2. Таблица 2. Стадии создания систем (ISO/IEC 15288) 1 2 3 4 Стадия Формирование концепции Разработка Стадия Реализация Эксплуатация Описание Анализ потребностей, выбор концепции и проектных решений Проектирование системы Описание Изготовление системы Ввод в эксплуатацию и использование системы 5 6 Поддержка Обеспечение функционирования системы Снятие с эксплуатации Прекращение использования, демонтаж, архивирование системы Лекция 6. Установление требований к ИС Определение требований к системе и анализ Определение требований к системе и анализ являются первым этапом создания ИС, на котором требования заказчика уточняются, согласуются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Для чего предназначена и что должна делать информационная система?» Именно здесь лежит ключ к успеху всего проекта. Целью системного анализа является преобразование общих, расплывчатых знаний об исходной предметной области (требований заказчика) в точные определения и спецификации для разработчиков, а также генерация функционального описания системы. На этом этапе определяются и специфицируются: ● внешние и внутренние условия работы системы; ● функциональная структура системы; ● распределение функций между человеком и системой, интерфейсы; ● требования к техническим, информационным и программным компонентам системы; ● требования к качеству и безопасности; состав технической и пользовательской документации; ● условия внедрения и эксплуатации. Разработка перечисленных выше спецификаций при создании ● ИС, предназначенной для автоматизации управленческих процессов, в общем случае проходит четыре стадии. Первая стадия анализа – структурный анализ предприятия – начинается с исследования того, как организована система управления предприятием, с обследования функциональной и информационной структур системы управления, определения существующих и возможных потребителей информации. По результатам обследования аналитик на первой стадии анализа выстраивает обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется (рис. 17). На этом материале аналитик строит функциональную модель «Как есть» (As Is). Вторая стадия работы, к которой обязательно привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели «Как есть», выявлении ее недостатков и узких мест, определении путей совершенствования системы управления на основе выделенных критериев качества. Третья стадия анализа, содержащая элементы проектирования, – создание усовершенствованной обобщенной логической модели, отображающей реорганизованную предметную область или ее часть, которая подлежит автоматизации – модель «Как должно быть» (As To Be). Заканчивается процесс (четвертая стадия) разработкой «Карты автоматизации», представляющей собой модель реорганизованной предметной области, на которой обязательно обозначены «границы автоматизации». Рисунок 17 – Схема обследования предприятия В большинстве случаев модель «Как есть» улучшается системным аналитиком за счет устранения очевидных несоответствий и узких мест, а полученный таким образом вариант модели рассматривается в дальнейшем в качестве предварительной модели «Как должно быть», которая впоследствии дополняется в соответствии со стратегией развития предприятия (рис. 18). Рисунок 18 – Стадии построения модели информационной системы На стадии анализа требований к проектируемой системе вводятся: ● классы пользователей и соответствующие диаграммы бизнес- транзакций; модели (диаграммы) процессов прикладной деятельности и соответствующие перечни функциональных задач ИС; ● классы объектов предметной области и соответствующие диаграммы «сущность-связь», отражающие информационную модель этой предметной области; ● топология расположения подразделений и пользователей, обслуживаемых данной ИС; ● параметры защиты данных, информации и самой системы. Основным документом, отражающим результаты работ первого этапа создания ИС, является техническое задание на проект (разработку), содержащее, кроме вышеперечисленных определений и спецификаций, также сведения об очередности создания системы, сведения о выделяемых ресурсах, директивных сроках проведения ● отдельных этапов работы, организационных процедурах и мероприятиях по приемке этапов, защите проектной информации и т. д. Следующий этап – проектирование. В реальных условиях проектирование – это поиск, моделирование способа разработки, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных начальных условий и ограничений. Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить: ● требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования; ● требуемую пропускную способность системы и минимальное время реакции системы на запрос; ● безотказную работу системы в требуемом режиме, готовность и доступность системы для обработки запросов пользователей; ● простоту эксплуатации и сопровождения системы; ● необходимую безопасность данных и права доступа пользователей. Производительность и надежность являются главными факторами, определяющими эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы. Жизненный цикл ИС формируется в соответствии с принципом нисходящего проектирования и, как правило, носит спиральноитерационный характор. Реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т. п. На каждом этапе жизненного цикла порождается определенный набор технических решений и документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе. Жизненный цикл ИС заканчивается, когда прекращается ее программное и техническое сопровождение. Спецификация требований. Модели состояния Требования необходимо специфицировать (т. е. задать) графически или каким-либо иным формальным способом. Всесторонняя спецификация системы может потребовать использования многих типов моделей. Язык UML изобилует интегрированными методами моделирования, способными помочь бизнес-аналитику справиться с этой задачей. Спецификация – подобно процессу разработки ПО в целом – итеративный процесс с пошаговым наращиванием уровня детализации моделей. Немаловажную роль в успешном моделировании играет использование CASE-средств. В результате спецификации требований вырабатываются три категории моделей: • модели состояний • модели поведения • модели изменения состояния. Для каждой изкатегорий существует несколько методов работы с ними. Спецификация состояния Состояние объекта определяется значениями его атрибутов и ассоциаций. Например, объект BankAccount (Банковский счет) может находиться в состоянии «превышение кредитного лимита», если значение атрибута balance (баланс) отрицательно. Поскольку состояния объекта определяются структурам данных, модели структур данных называются спецификациями состояний. Спецификация состояний дает статический взгляд на систему (поэтому моделирование состояний часто называют статическим моделированием). Здесь основной задачей является определение классов проблемной области, их атрибутов и отношений с другими классами. Вначале операции классов обычно не рассматриваются. Они выводятся из моделей спецификации поведения. В типичной ситуации сначала определяются классы-сущности, т. е. классы, которые определяют проблемную область и характоризуются постоянным присутствием в базе данных системы. Подобные классы иногда называются «бизнес-классами». Классы, которые обслуживают системные события (управляющие классы), и классы, которые представляют GUI-интерфейс (классы представления или пограничные классы), не устанавливаются до тех пор, пока не станут известны поведенческие характеристики системы. Моделирование классов Модель классов – это краеугольный камень разработки объектно-ориентированной системы. Классы лежат в основании наблюдаемости свойств и поведения системы. К сожалению, классы всегда трудно поддаются определению, а свойства классов не всегда очевидны. Весьма маловероятно, чтобы два аналитика пришли к одному и тому же множеству классов и их свойств для одной и той же нетривиальной проблемной области. Хотя модели классов могут отличаться, конечный результат и степень удовлетворенности пользователя могут быть в равной мере достаточными (или в равной мере недостаточными). Моделирование классов – это не детерминированный процесс. Не существует общего рецепта отыскания и определения наилучших классов. Этот процесс в значительной мере носит итеративный и пошаговый наращиваемый характор. К факторам, определяющим успешное проектирование классов, относится уровень квалификации и опыта аналитика, в частности, перечисленные ниже возможности. 1. Знания в области моделирования классов. 2. 3. 4. Понимание проблемной области. Опыт в области аналогичных и успешных проектов. Способность смотреть вперед и предвидеть последствия решений. Готовность к пересмотру модели с целью устранения недостатков и т. д. Последний момент связан с использованием CASE-средств. Широкомасштабное применение CASE-технологии может стать препятствием на пути разработки системы в технологически незрелых организациях. Однако использование CASE-средств для повышения личной продуктивности всегда оправдано. Два разных аналитика, как правило, не могут прийти к идентичным моделям классов для одной и той же проблемной области, и точно так же два разных аналитика не пользуются одним и тем же мыслительным процессом при выделении классов. Литература изобилует подходами, предлагаемыми для выявления классов. Аналитики могут поначалу даже следовать одному из этих подходов, однако последующие итерации, как правило, обязательно приводят к использованию нешаблонных и в чем-то даже случайных механизмов. Существуют четыре основных подхода к выявлению классов (class discovery). Ниже перечислены эти подходы. 1. Подход на основе использования именных групп. 5. 2. Подход на основе использования общих шаблонов для классов. Подход на основе использования прецедентов. 4. Подход CRC (class–responsibility–collaborators – класс– обязанности–сотрудники). После того как перечень потенциальных классов сформирован, необходима их дальнейшая спецификация: классы требуется включить в диаграмму классов и определить их свойства. Некоторые свойства можно ввести и отобразить внутри графических пиктограмм, представляющих классы на диаграмме классов. Многие другие свойства, включенные в спецификацию класса, имеют только текстовое представление. CASE-средства, как правило, обладают возможностями редактирования, позволяющими легко вводить или модифицировать подобную информацию посредством диалоговых окон, снабженных вкладками, или с помощью аналогичных способов. 3. Моделирование ассоциаций Ассоциации служат объединению объектов в системе. Они способствуют взаимодействию между объектами. Без ассоциаций объекты могут устанавливать связь только во время прогона программы, если они совместно используют одни и те же атрибуты или они имеют доступ (с помощью других средств, таких как глобальные переменные) к идентифицирующим объекты значениям других объектов. Ассоциации представляют собой наиболее существенный вид отношений моделей, в частности, моделей постоянных «бизнесобъектов». Ассоциации поддерживают выполнение прецедентов и, таким образом, обеспечивают совмещение спецификации состояний и поведения. Нахождение основных ассоциаций представляет собой побочный эффект процесса выявления классов. При определении классов аналитик принимает решение об атрибутах классов, и некоторые из этих атрибутов являются ассоциациями с другими классами. Атрибуты могут относиться к элементарным типам данных либо могут вводиться в качестве других классов, устанавливая, таким образом, отношения с другими классами. По существу, любой атрибут, относящийся к неэлементарным типам данных, должен моделироваться как ассоциация (или агрегация) по классу, представляющему этот тип данных. Выполнение пробного прогона прецедентов позволяет выявить остающиеся ассоциации. Устанавливаются пути взаимодействия между классами, необходимые для прогона прецедентов. Обычно ассоциации должны поддерживать эти пути взаимодействия. Каждая тернарная ассоциация должна быть заменена циклом или бинарной ассоциацией. Тернарные ассоциации привносят риск неверного семантического истолкования. Иногда для того, чтобы полностью выразить базовую семантику, циклы, образуемые ассоциациями, не должны коммутировать (быть замкнутыми). Это значит, что поменьшей мере одна из ассоциаций в цикле может быть производной (derived). Подобная ассоциация является избыточной в семантическом смысле и должна быть исключена (хорошая семантическая модель должна быть лишена избыточности). Вполне допустимо, что многие производные ассоциации, тем не менее, все же войдут в проектную модель (например, из соображений эффективности). Моделирование отношений агрегации и композиции Агрегация и ее более строгая форма композиция служит проводником семантики «часть-целое» между составным (супермножество) классом и компонентным (подмножество) классом. В языке UML агрегация трактуется как ограниченная форма ассоциации. Это колоссальное умаление роли агрегации в моделировании. Достаточно сказать, что агрегация, наряду с обобщением, является наиболее важным методом многократного использования функциональных возможностей в объектноориентированных системах. Моделирующая способность языка UML значительно усилилась, если бы язык поддерживал четыре возможных семантики для агрегации. 1. Агрегация типа «Безраздельно обладает». 2. Агрегация типа «Обладает». 3. Агрегация типа «Включает». 4. Агрегация типа «Участник». Агрегация типа «Безраздельно обладает» устанавливает следующее: • между компонентными классами и их составными классами установлено отношение зависимости по существованию (следовательно, удаление составного объекта распространяется вниз по иерархии отношения, так что связанные компонентные объекты также удаляются); • агрегация транзитивна (если объект C1 является частью объекта B1, а B1 является частью A1, тогда C1 является частью A1); • агрегация асимметрична (нерефлексивна) (если объект является частью объекта A1, то объект A1 не является частью B1); • агрегация стационарна (если объект B1 является частью объекта A1, то он не может быть частью объекта Ai (i≠1)). Агрегация типа «Обладает» поддерживает первые три свойства агрегации типа «Безраздельно обладает», к которым относятся: • зависимость существований; транзитивность; • асимметричность. Агрегация типа «Включает» слабее, чем агрегация типа «Обладает». Агрегация типа «Включает» поддерживает следующие свойства: • транзитивность; • асимметричность. Агрегация типа «Участник» обладает свойством целенаправленного группирования независимых объектов – группирования, при котором не делается предположений относительно свойства зависимости по существованию, транзитивности, асимметричности или стационарности. Это абстракция, посредством которой совокупность членов-компонентов рассматривается как составной объект более высокого уровня. Компонентный объект в агрегации типа «Участник» может одновременно принадлежать более чем одному составному объекту (поэтому, кратность агрегации типа «Участник» может иметь значение «многие ко многим»). Хотя агрегация получила признание как фундаментальная концепция моделирования, по меньшей мере, одновременно с обобщением, в объектно-ориентированном анализе и проектировании ей уделяется лишь незначительное внимание [18]. • Моделирование отношений обобщения Общие характеристики (атрибуты и операции) одного или более классов можно погрузить в более общий класс. Это явление известно как обобщение. Отношение обобщения соединяет родовой класс (суперкласс) с более специализированными классами (подклассы). Обобщение делает возможным наследование (многократное использование) характеристик суперкласса подклассом. В традиционных объектно-ориентированных системах наследование применяется к классам, а не к объектам (наследуются типы, а не значения). Помимо наследования обобщение преследует еще две цели. 1. Подставимость. 2. Полиморфизм. В соответствии с принципом подставимости (substitutability) объект подкласса является законным значением переменной суперкласса. Например, если переменная объявлена с целью хранения объекта Fruit (Фрукт), то объект Apple (Яблоко) является допустимым значением. В соответствии с принципом полиморфизма (polymorphism) одна и та же операция может иметь разные реализации в разных классах. Вызывающий объект может вызвать операцию, не зная и не заботясь о том, какая из реализаций операции выполнится. Вызываемый объект знает, какому классу он принадлежит и выполняет свою собственную реализацию. Полиморфизм работает лучше в тех ситуациях, когда он идет «рука об руку» с наследованием. Зачастую полиморфная операция в суперклассе объявляется, а реализация для нее в этом классе отсутствует. Это значит, что операция получила сигнатуру (имя и список формальных аргументов), а реализация должна быть обеспечена в каждом из подклассов. Подобная операция называется абстрактной. Абстрактную операцию не следует путать с абстрактным классом. Последний является классом, у которого отсутствуют непосредственные объекты-экземпляры (однако его подклассы могут обладать объектами-экземплярами). Экземпляров класса Vegetable (Овощи) может не существовать. Непосредственными экземплярами являются только объекты классов Potato (Картофель), Carrot (Морковь) и т. д. Фактически, класс, обладающий абстрактной операцией, является абстрактным. Конкретный класс, наподобие Apple, не может иметь абстрактных операций. Хотя абстрактные операции вводятся на уровне спецификаций поведения, абстрактные классы – это сфера спецификаций состояния. Многие суперклассы/подклассы аналитик отмечает еще в процессе формирования первоначального перечня классов. Многие другие обобщения можно обнаружить при определении ассоциаций. Может возникнуть необходимость связать различные ассоциации (даже принадлежащие одному и тому же классу) с классом на различных уровнях обобщения/специализации. Например, класс Course может быть связан с классом Student (Student takes Course – студент берет курс), кроме того, этот класс может быть связан с классом TeachingAssistant (TeachingAssistant teaches Course – ассистент ведет курс). Дальнейший анализ может показать, что класс TeachingAssistant является подклассом Student. При поиске отношения обобщения лакмусовой бумажкой выступают фразы «может быть» («can-be») и «это нечто вроде» («is-akind-of»). При истолковании отношения сверху-вниз по иерархии классов используется фраза «может быть» (например, Student «canbe» a TeachingAssistant – «студент «может быть» ассистентом»). При интерпретации отношения снизу-вверх используется фраза «это нечто вроде» (например, TeachingAssistant «is-a-kind-of» Student – «ассистент «это нечто вроде студента»). Обратите внимание, что если также справедливо утверждение о том, что «ассистент – это «TeachingAssistant «is-a-kind-of» Teacher», то мы установили множественное наследование. Моделирование касается проблем определения систем. Модель – это не действующая система, и поэтому она не отражает объектовэкземпляров. В любом случае количество объектов в работающей системе может быть огромным, и представить их графически невозможно. Тем не менее, при моделировании классов мы часто представляем себе объекты и рассматриваем трудные сценарии с использованием примеров объектов. Язык UML позволяет представить объекты графически. Мы можем изобразить диаграмму объектов, чтобы проиллюстрировать сложные отношения между классами или продемонстрировать изменения объектов со временем. Объектные модели можно использовать для иллюстрации и исследования способа взаимодействия объектов во время прогона программной системы [5]. Спецификация ассоциаций Определение ассоциации Ассоциация – это любой атрибут, относящийся к неэлементарным типам данных. Выявление ассоциаций Нахождение основных ассоциаций представляет собой побочный эффект процесса выявления классов. При определении классов аналитик принимает решение об атрибутах классов, и некоторые из этих атрибутов являются ассоциациями с другими классами. Атрибуты могут относиться к элементарным типам данных либо могут вводиться в качестве других классов, устанавливая, таким образом, отношения с другими классами. Выполнение пробного прогона прецедентов позволяет выявить остающиеся ассоциации. Устанавливаются пути взаимодействия между классами, необходимые для прогона прецедентов. Обычно ассоциации должны поддерживать эти пути взаимодействия. Каждая тернарная ассоциация должна быть заменена циклом или бинарной ассоциацией. Тернарные ассоциации привносят риск неверного семантического истолкования. Иногда для того, чтобы полностью выразить базовую семантику, циклы, образуемые ассоциациями, не должны коммутировать (быть замкнутыми). Это значит, что по меньшей мере одна из ассоциаций в 32-м цикле может быть производной (derived). Подобная ассоциация является избыточной в семантическом смысле и должна быть исключена (хорошая семантическая модель должна быть лишена избыточности). Вполне допустимо, что многие производные ассоциации все же войдут в проектную модель (например, из соображений эффективности). Спецификация ассоциаций ассоциаций подразумевает Спецификация выполнение следующих действий. 1. Присваивание имен ассоциациям. 2. Присваивание имен ассоциативным ролям. 3. Установление кратности ассоциации. Правила именования ассоциаций должны соответствовать соглашениям по именованию атрибутов – имена ассоциаций состоят из строчных букв, отдельные слова в имени ассоциации разделяются подчеркиванием. Если два класса связаны только одним ассоциативным отношением, задавать имя ассоциации и ассоциативные ролевые имена между этими классами необязательно. CASE-средства могут внутренне различать каждую ассоциацию через системные идентификационные имена. Ролевые имена можно использовать для раскрытия более сложных ассоциаций, в частности самоассоциативных отношений (self associations) (рекурсивных ассоциаций, которые связывают объекты одного и того же класса). При задании ролевых имен их следует выбирать с учетом того, что в проектной модели они станут атрибутами классов, расположенных на противоположных концах ассоциативной связи. Поиск агрегаций ведется параллельно с поиском ассоциаций. Если ассоциация проявляет одно или более из четырех семантических свойств, рассмотренных выше, то ее можно моделировать как агрегацию. Язык UML обеспечивает только ограниченную поддержку агрегации. Сильная форма агрегации называется в UML композицией. Спецификация состояний агрегации и композиции Агрегация и композиция Агрегация (aggregation) – это отношение вида часть целое между классом, который представляет собрание компонент (класс супермножество (superset class)), и классами, представляющими компоненты (классы подмножества (subset class)). Класс супермножество содержит один или более классов подмножеств. Композиция обладает дополнительным свойством «зависимость по существованию» (existence dependency). Объект класса подмножества не может существовать в отсутствие связи с объектом класса супермножества. Агрегация – особый случай ассоциации Она обладает рядом свойств: • Транзитивность Асимметрия Транзитивность означает, что если класс А содержит класс В, а • класс В содержит класс С, то класс А содержит класс С. Асимметрия означает, что если А содержит В, то В не может содержать А. С точки зрения модели отдельные части системы могут выступать в виде как элементов, так и подсистем, которые, в свою очередь, тоже могут состоять из подсистем или элементов. Таким образом, данное отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые составные части, которые также могут быть подвергнуты декомпозиции, если в этом возникнет необходимость. Очевидно, что рассматриваемое в таком аспекте деление системы на составные части представляет собой иерархию, но принципиально отличную от той, которая порождается отношением обобщения. Отличие заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями. Более того, части целого обладают собственными атрибутами и операциями, которые существенно отличаются от атрибутов и операций целого. Рисунок 19 – Графическое отношение агрегации Графически отношение агрегации (рис. 19) изображается сплошной линией, один из концов которой представляет собой не закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой «целое», или класс-контейнер. Остальные классы являются его «частями», в качестве примера отношения агрегации можно рассмотреть взаимосвязь типа «часть-целое», которая имеет место между классом Системный блок персонального компьютера и его составными частями: Процессор, Материнская плата, Оперативная память, Жесткий диск и Дисковод гибких дисков. Используя обозначения языка UML, компонентный состав системного блока можно представить в виде соответствующей диаграммы классов (рис. 20), которая в данном случае иллюстрирует отношение агрегации. Рисунок 20 – Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК Отношение композиции Композиция (composition) – разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого. Отношение композиции – частный случай отношения агрегации. Это отношение служит для спецификации более сильной формы отношения «часть-целое», при которой составляющие части тесно взаимосвязаны с целым. Особенность этой взаимосвязи заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части. Композит (composite) – класс, который связан отношением композиции с одним или большим числом классов. Графически отношение композиции (рис. 21) изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит. Остальные классы являются его «частями» Рисунок 21 – Графическое отношение композиции Наглядным примером этого отношения является окно графического интерфейса программы, которое может состоять из строки заголовка, полос прокрутки, главного меню, рабочей области и строки состояния. Нетрудно заключить, что подобное окно представляет собой класс, а его составные элементы также являются отдельными классами. Последнее обстоятельство характорно для отношения композиции, поскольку отражает различные способы представления данного отношения. Для отношений композиции и агрегации (рис. 23) могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, могут указываться кратности отдельных классов, которые в общем случае не обязательны. Применительно к описанному выше примеру класс Окно программы является классом-композитом, а взаимосвязи составляющих его частей могут быть изображены следующей диаграммой классов (рис. 22). Рисунок 22 – Диаграмма классов для иллюстрации отношения композиции на примере класса-композита Окно программы Рисунок 23 – Пример спецификации агрегации и композиции Моделирование отношения агрегации и композиции Моделирующая способность языка UML значительно усилилась, если бы язык поддерживал четыре возможных семантики для агрегации: 1. Агрегация типа «Безраздельно обладает». 2. Агрегация типа «Обладает». 3. Агрегация типа «Включает». 4. Агрегация типа «Участник». Агрегация типа «Безраздельно обладает» устанавливает следующее: между компонентными классами и их составными классами установлено отношение зависимости по существованию (следовательно, удаление составного объекта распространяется вниз по иерархии отношения, так что связанные компонентные объекты также удаляются); агрегация транзитивна; агрегация асимметрична (нерефлексивна); агрегация стационарна. Агрегация типа «Обладает» поддерживает свойства: зависимость существований; транзитивность; асимметричность. Моделирование объектов. Моделирование касается проблем определения систем. Модель – это недействующая система, и поэтому она не отражает объектов экземпляров. Тем не менее, при моделировании классов часто представляются объекты (рис. 25) и рассматриваются трудные сценарии с использованием примеров объектов. Объект – это экземпляр (instance) некоей «сущности». Он может быть одним из множества экземпляров одной и той же «сущности» (рис. 24). Рисунок 24 – Кооперирование объектов Рисунок 25 – Пример спецификации объектов Спецификация обобщения После появления первого выпуска платформы .NET программисты часто использовали пространство имен System.Collections для получения более гибкого способа управления данными в приложениях. Однако, начиная с версии .NET 2.0, язык программирования C# был расширен поддержкой средства, которое называется обобщением (generic). Вместе с ним библиотеки базовых классов пополнились совершенно новым пространством имен, связанным с коллекциями – System.Collections.Generic. Термин обобщения: – по существу, означает параметризированный тип. Особая роль параметризированных типов состоит в том, что они позволяют создавать классы, структуры, интерфейсы, методы и делегаты, в которых обрабатываемые данные указываются в виде параметра. С помощью обобщений можно, например, создать единый класс, который автоматически становится пригодным для обработки разнотипных данных. Класс, структура, интерфейс, метод или делегат, оперирующий параметризированным типом данных, называется обобщенным, как, например, обобщенный класс или обобщенный метод. Ссылка типа object Следует особо подчеркнуть, что в C# всегда имелась возможность создавать обобщенный код, оперируя ссылками типа object. А поскольку класс object является базовым для всех остальных классов, то по ссылке типа object можно обращаться к объекту любого типа. Таким образом, до появления обобщений для оперирования разнотипными объектами в программах служил обобщенный код, в котором для этой цели использовались ссылки типа object. Обобщения – это не совсем новая конструкция; подобные концепции присутствуют и в других языках. Например, схожие с обобщениями черты имеют шаблоны С++. Однако между шаблонами С++ и обобщениями .NET есть большая разница. В С++ при создании экземпляра шаблона с конкретным типом необходим исходный код шаблонов. В отличие от шаблонов С++, обобщения являются не только конструкцией языка C#, но также определены для CLR. Это позволяет создавать экземпляры шаблонов с определенным типомпараметром на языке Visual Basic, даже если обобщенный класс определен на C#. Преимущества использования обобщений: Производительность Безопасность Повторное использование двоичного кода Одним из основных преимуществ обобщений является производительность. Использование типов значений с необобщенными классами коллекций вызывает упаковку (boxing) и распаковку (unboxing) при преобразовании в ссылочный тип и обратно. Типы значений сохраняются в стеке, а типы ссылок – в куче. Классы C# являются ссылочными типами, а структуры – типами значений. .NET позволяет легко преобразовывать типы значений в ссылочные, поэтому их можно использовать там, где ожидаются объекты (т. е. ссылочные типы). Например, объекту можно присвоить значение типа int. Преобразование типа значений в ссылочный тип называется упаковкой (boxing). Упаковка происходит автоматически, когда метод ожидает параметр ссылочного типа, а ему передается тип значений. С другой стороны, упакованный тип значений может быть обратно преобразован к простому типу значений с помощью распаковки (unboxing). При распаковке требуется операция приведения. Безопасность Другим свойством обобщений является безопасность типов. Обобщения автоматически обеспечивают типовую безопасность всех операций. В ходе выполнения этих операций обобщения исключают необходимость обращаться к приведению типов и проверять соответствие типов в коде вручную. Повторное использование двоичного кода Обобщения повышают степень повторного использования двоичного кода. Обобщенный класс может быть определен однажды, и на его основе могут быть созданы экземпляры многих типов. При этом не нужно иметь доступ к исходным текстам, как это необходимо в случае шаблонов С++. Спецификация требований Что такое спецификация требований? • Спецификация требований – законченное описание поведения программы, которую требуется разработать. Требования необходимо специфицировать (т. е. задать) графически или какимлибо иным формальным способом. • В результате спецификации требований вырабатываются три категории моделей: • модели состояний • модели поведения • модели изменения состояния Для каждой из категорий существует несколько методов работы с ними. Спецификация поведения • Поведение системы – так как оно выглядит для внешнего пользователя – изображается в вид прецедентов. • Взаимодействие объектов можно задать с помощью диаграмм последовательностей или диаграмм кооперации. • Модели прецедентов (рис. 26) должны нарабатываться итеративно и параллельно с моделями классов. Классы, введенные в спецификации состояний, подлежат дальнейшей детальной проработке, при этом обозначаются наиболее важные операции. Следует, однако, напомнить, что спецификация состояний определяет только классы сущностей («бизнес объектов»). Выявление прецедентов Прецеденты представляют следующие компоненты общей модели системы: • Завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его любые вариации (подпотоки) и исключительные условия (альтернативные потоки)). • Фрагмент внешне наблюдаемых функций (отличных от внутренних фунций). • Ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов). • Фрагмент функциональных возможностей, инициируемый субъектом (будучи инициирован, прецедент может взаимодействовать с другими субъектами). При этом возможно, что субъект окажется только на принимающем конце прецедента (может быть, опосредовано), инициированного другим субъектом. Фрагмент функциональных возможностей, который предоставляет субъекту ощутимый полезный результат (и этот полезный результат достигается в пределах одного прецедента). Рисунок 26 – Пример модели поведения Спецификация требования. Модели изменения состояний Моделирование касается проблем определения систем. Модель – это недействующая система, и поэтому она не отражает объектовэкземпляров. В любом случае количество объектов в работающей системе может быть огромным, и представить их графически невозможно. Тем не менее, при моделировании классов мы часто представляем себе объекты и рассматриваем трудные сценарии с использованием примеров объектов. Язык UML позволяет представить объекты графически. Мы можем изобразить диаграмму объектов, чтобы проиллюстрировать сложные отношения между классами или продемонстрировать изменения объектов со временем. Объектные модели можно использовать для иллюстрации и исследования способа взаимодействия объектов во время прогона программной системы. Развитие методов и моделей проектирования ИС привело к необходимости создания взаимосвязанной совокупности методик концептуального проектирования, которая обеспечивала бы возможность эффективного обмена информацией между всеми специалистами – участниками процесса. Такая совокупность методик, разработанная в США по программе компьютеризации промышленности ICAM (Integrated Computer-Aided Manufacturing), получила название IDEF (аббревиатура от Icam DEFinition или Integrated Definition). Некоторые из этих методик получили статус государственного стандарта США. В IDEF входят методики функционального, информационного и поведенческого моделирования и проектирования, отмеченные в следующей таблице. Таблица 3 Методики функционального, информационного и поведенческого моделирования и проектирования Название методологии IDEF0 IDEF1 и IDEF1X IDEF2 IDEF3 IDEF4 IDEF5 Назначение Функциональное моделирование (Function Modeling Method) Информационное моделирование (Information and Data Modeling Methods) Поведенческое моделирование (Simulation Modeling Method) Моделирование процессов (Process Flow and Object State Description Capture Method) Объектно-ориентированное проектирование (Object-Oriented Design Method). Систематизации объектов приложения Название методологии IDEF6 IDEF8 IDEF9 IDEF14 Назначение (Ontology Description Capture method) Использование рационального опыта проектирования (Design Rationale Capture Method) Взаимодействие человека и системы (Human-System Interaction Design) Учет условий и ограничений (Business Constraint Discovery) Моделирование вычислительных сетей (Network Design) IDEF-технологии находят успешное применение в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Основными являются методология функционального моделирования бизнес-процессов IDEF0, методология информационного моделирования IDEF1X и методология документирования технологических процессов предприятия IDEF 3, дополненная технологией анализа потоков данных DFD. Методологию IDEF0 можно считать следующим этапом развития графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique), описанного выше. Последняя редакция стандарта IDEF0 была выпущена в 1993 г. Национальным институтом по стандартам и технологиям США (NIST). IDEF0 предназначена для функционального моделирования, т. е. моделирования выполнения функций объекта путем создания описательной графической модели, показывающей, что, как и кем делается в рамках функционирования предприятия. Метод IDEF0 основан на методологии SADT. Госстандартом России приняты рекомендации по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Они описывают язык моделирования IDEF0, правила и методику структурированного графического представления описания процессов (бизнес-процессов) предприятия или организации. В основе IDEF0 методологии лежит понятие блока, который отображает некоторую бизнес-функцию. Так же как в SADT, четыре стороны блока имеют разную роль: левая сторона имеет значение «входа», правая – «выхода», верхняя – «управления», нижняя – «механизма». Взаимодействие между функциями в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно «входным», «выходным», «управляющим» [22]. В IDEF0 реализованы три базовых принципа моделирования процессов: принцип функциональной декомпозиции; принцип ограничения сложности; принцип контекста. Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу [7]. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок – главная бизнес-функция моделируемой системы. Главная бизнес-функция системы – это «миссия» системы, ее значение в окружающем мире. При определении главной бизнес-функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Контекстная диаграмма играет еще одну роль в функциональной модели. Она «фиксирует» границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию. IDEF0 применяется для построения двух видов моделей. При обследовании предприятия строится функциональная модель КАК ЕСТЬ, которая позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и «узких» мест и разработки проекта совершенствования деловых процессов. Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес-правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям. IDEF3 является методикой описания бизнес-процессов как упорядоченной последовательности событий с одновременным описанием объектов, имеющих отношение к процессу. Эта методика является средством документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием называется описание последовательности изменений свойств объекта в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цехе и изменение ее свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т. д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т. д.). Для эффективного управления любым процессом необходимо иметь детальное представление об его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи: • Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса. • Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. • Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. • Содействовать принятию оптимальных решений при реорганизации технологических процессов. • Разрабатывать имитационные модели технологических процессов по принципу «КАК БУДЕТ, ЕСЛИ...» Как и в других методиках IDEF, главной единицей представления модели IDEF3 является диаграмма. Диаграммы оперируют такими элементами, как действия, связи (отношения между действиями), соединения (разворачивающее соединение, когда завершение одного действия вызывает начало выполнения нескольких других действий, и сворачивающее соединение в противоположной ситуации) и указатели (ссылки на другие разделы описания процесса). Действия в случае необходимости могут подвергаться последовательной декомпозиции для более детального анализа. Построение модели IDEF3, дополненное диаграммами потоков данных, как правило, является следующим шагом в проектировании после IDEF0 – анализа, который в этом случае используется для сбора данных и моделирования процесса «как есть». Методика IDEF1 была разработана как инструмент для анализа и изучения взаимосвязей между информационными потоками внутри системы, позволяющий отображать и анализировать их структуру и взаимосвязи. Целью подобного исследования является дополнение и структуризация существующей информации и обеспечение качественного управления информационными потоками. Необходимость в реорганизации информационной области, как правило, возникает на начальном этапе построения корпоративной информационной системы, и методология IDEF1 позволяет достаточно наглядно выявить слабые места в существующей структуре информационных потоков. Применение методологии IDEF1, как инструмента построения наглядной модели информационной структуры предприятия по принципу «Как должно быть», позволяет решить следующие задачи: • выяснить структуру и содержание существующих потоков информации на предприятии и взаимосвязей между этими потоками; • определить существующие правила, по которым осуществляется движение информационных потоков, а также принципы управления ими; • определить, какие проблемы, выявленные в результате функционального анализа и анализа потребностей, вызваны недостаточным использованием управления соответствующей информацией; • выявить информационные потоки, требующие дополнительного управления для эффективной реализации модели. Основой для разработки IDEF1 послужили методики информационного моделирования в виде диаграмм сущность-связь. Это определило их терминологическую и семантическую близость. Методология IDEF1 разделяет элементы структуры информационной области, их свойства и взаимосвязи на классы. Центральным понятием методологии IDEF1 является понятие сущности. Класс сущностей представляет собой совокупность информации, накопленной и хранящейся в рамках предприятия и соответствующей определенному объекту или группе объектов реального мира. Основными концептуальными свойствами сущностей в IDEF1 являются: • устойчивость – информация, имеющая отношение к той или иной сущности постоянно накапливается; • уникальность – любая сущность может быть однозначно идентифицирована. IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой здесь называется универсальное представление структуры данных в рамках предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Использование методики IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем, с помощью метода IDEF1), и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем, объектно-ориентированной, то лучше избрать другие методы моделирования. Методика онтологического исследования IDEF5 ориентирована на эффективное исследование строения и свойств любой системы. Понятие онтологии первоначально появилось в разделе философии, называемой метафизикой, которая изучает устройство реального мира. Основной характорной чертой онтологического анализа является, в частности, разделение реального мира на составляющие и классы объектов и определение их онтологий, или же совокупности фундаментальных свойств, которые определяют их изменения и поведение. IDEF5 предоставляет структурированную методологию, с помощью которой можно наглядно и эффективно разрабатывать, поддерживать, документировать и изучать онтологию системы. Средствами для этого являются: словарь терминов, используемых при описании характеристики объектов и процессов, имеющих отношение к рассматриваемой системе, точные и однозначные определения всех терминов этого словаря и классификации логических взаимосвязей между этими терминами. Онтологический анализ обычно начинается с составления словаря терминов, который используется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений этих терминов. Кроме того, документируются основные логические взаимосвязи между соответствующими введенным терминам понятиями. Таким образом, онтология включает в себя совокупность терминов и правила, согласно которым эти термины могут быть скомбинированы для построения достоверных утверждений о состоянии рассматриваемой системы в некоторый момент времени. Кроме того, на основе этих утверждений могут быть сделаны соответствующие выводы, позволяющие вносить изменения в систему, для повышения эффективности ее функционирования Процесс построения онтологии, согласно методологии IDEF5, состоит из пяти основных действий: • изучение и систематизирование начальных условий (устанавливает основные цели и контексты проекта разработки онтологии, а также распределяет роли между членами проекта); • сбор и накопление данных; • анализ данных (анализ и группировка собранных данных для облегчения построения терминологии); • начальное развитие онтологии (формирование предварительной онтологии на основе отобранных данных); • уточнение и утверждение онтологии – заключительная стадия процесса. IDEF представляет собой взаимосвязанную совокупность методик концептуального проектирования. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами – участниками разработки. Особенностью рассматриваемого семейства методологий является уникальная способность «задавать вопросы» в процессе моделирования, неразрывная связь графических средств (нотации) с методологией и технологией. С этой точки зрения семейство IDEF является, пожалуй, единственной системой, которая предоставляет не только средства отображения бизнес-процессов, но и методологию взаимодействия «аналитик-специалист», и, кроме того, технологию создания проектов, охватывающую все стадии «жизненного цикла» – от первичного анализа до формы представления окончательного проекта, через поэтапный процесс создания диаграмм и хранения версий. Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству. Функциональная методика потоков данных Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram – DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища). Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить документы по отгрузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Кроме основных элементов, в состав DFD входят словари данных и миниспецификации. Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. Миниспецификации обработки – описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы. Процесс построения DFD начинается с создания так называемой основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. В случае сложного основного процесса он сразу представляется в виде декомпозиции на ряд взаимодействующих процессов. Критериями сложности в данном случае являются: наличие большого числа внешних сущностей, многофункциональность системы, ее распределенный характор. Внешние сущности выделяются по отношению к основному процессу. Для их определения необходимо выделить поставщиков и потребителей основного процесса, т. е. все объекты, которые взаимодействуют с основным процессом. На этом этапе описание взаимодействия заключается в выборе глагола, дающего представление о том, как внешняя сущность использует основной процесс или используется им. Например, основной процесс – «учет обращений граждан», внешняя сущность – «граждане», описание взаимодействия – «подает заявления и получает ответы». Этот этап является принципиально важным, поскольку именно он определяет границы моделируемой системы. Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы. На следующем шаге происходит декомпозиция основного процесса на набор взаимосвязанных процессов, обменивающихся потоками данных. Сами потоки не конкретизируются, определяется лишь характор взаимодействия. Декомпозиция завершается, когда процесс становится простым, т. е.: 1) процесс имеет два-три входных и выходных потока; процесс может быть описан в виде преобразования входных данных в выходные; 3) процесс может быть описан в виде последовательного алгоритма. Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные. Миниспецификация удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные; спецификация ссылается на имеющиеся элементы, не вводя новые; спецификация по возможности использует стандартные подходы и операции. После декомпозиции основного процесса для каждого подпроцесса строится аналогичная таблица внутренних событий. Следующим шагом после определения полной таблицы событий выделяются потоки данных, которыми обмениваются процессы и внешние сущности. Простейший способ их выделения заключается в анализе таблиц событий. События преобразуются в потоки данных от инициатора события к запрашиваемому процессу, а реакции – в 2) обратный поток событий. После построения входных и выходных потоков аналогичным образом строятся внутренние потоки. Для их выделения для каждого из внутренних процессов выделяются поставщики и потребители информации. Если поставщик или потребитель информации представляет процесс сохранения или запроса информации, то вводится хранилище данных, для которого данный процесс является интерфейсом. После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет «повисших» процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены. К преимуществам методики DFD относятся: • возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы; • возможность проектирования сверху вниз, что облегчает построение модели «как должно быть»; • наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы. К недостаткам модели отнесем: необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных; отсутствие понятия времени, т. е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов). Создание логической модели данных Уровни логической модели Различают три уровня логической модели, отличающихся по глубине представления информации о данных: диаграмма сущность-связь (Entity Relationship Diagram, ERD); модель данных, основанная на ключах (Key Based model, KB); полная атрибутивная модель (Fully Attributed model, FA). Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области. Модель данных, основанная на ключах, – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области. Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи. Сущности и атрибуты Основные компоненты диаграммы ERwin – это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы [2]. Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Cущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить «технических» наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP). Использование (UDP) аналогично их использованию в BPwin [15]. Как было указано выше, каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т. е. не содержать множественных значений. Согласно синтаксису IDEFIX имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его. Каждый атрибут должен быть определен, при этом следует избегать циклических определений, например, когда термин 1 определяется через термин 2, термин 2 – через термин 3, а термин 3 в свою очередь – через термин 1. Часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых можно вычислить из других атрибутов. Примером производного атрибута может служить Возраст сотрудника, который может быть вычислен из атрибута Дата рождения сотрудника. Такой атрибут может привести к конфликтам; действительно, если вовремя не обновить значение атрибута Возраст сотрудника, он может противоречить значению атрибута Дата рождения сотрудника. Производные атрибуты – ошибка нормализации, однако их вводят для повышения производительности системы, чтобы не проводить вычисления, которые на практике могут быть сложными. Связи Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На логическом уровне можно установить идентифицирующую связь «один-ко-многим», связь «многие-комногим» и неидентифицирующую связь «один-ко-многим». В IDEFIX различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – FK. При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной. Мощность связей (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа сущности: • общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности; не помечается каким-либо символом; символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение); • символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); • цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. Имя связи (Verb Phrase) – фраза, характоризующая отношение между родительской и дочерней сущностями. Для связи «один-комногим», идентифицирующей или неидентифицирующей, достаточно указать имя, характоризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи «многие-ко-многим» следует указывать имена как Parent-to-Child, так и Child-to-Parent [8]. • Типы сущностей и иерархия наследования Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей. Характористическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности (рис. 27). Рисунок 27 – Пример характористической сущности «Хобби» Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Категориальная – дочерняя сущность в иерархии наследования. Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (постоянные служащие), и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) Сотрудник (рис.24), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть расположена в категориальных сущностях (потомках) Постоянный сотрудник и Совместитель. Обычно иерархию наследования создают, когда несколько сущностей имеют общие по смыслу атрибуты, либо когда сущности имеют общие по смыслу связи (например, если бы Постоянный сотрудник и Совместитель имели сходную по смыслу связь «работает в» с сущностью Организация), либо когда это диктуется бизнесправилами. Для каждой категории можно указать дискриминатор – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой (атрибут Тип на рис. 28). Рисунок 28 – Иерархия наследования. Неполная категория Иерархии категорий делятся на два типа – полные и неполные. В полной категории одному экземпляру родового предка (сущность Cотрудник, рис. 29) обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере сотрудник обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником. Рисунок 29 – Иерархия наследования. Полная категория Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. На рис. 28 показана неполная категория – сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность Консультант еще не внесена в иерархию наследования. Ключи Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен отличаться от других атрибутов. Первичный ключ (primary key) – это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения – это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рис. 29). В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key). Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения – это список атрибутов, расположенных выше горизонтальной линии. На рисунке 30 показаны кандидаты на роль первичного ключа сущности «Сотрудник» Рисунок 30 – Определение первичного ключа для сущности «Сотрудник» Здесь можно выделить следующие потенциальные ключи: 1. Табельный номер; 2. Номер паспорта; 3. Фамилия + Имя + Отчество. Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований: Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ №3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки. Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа №3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнесправила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В приведенном примере ключи №1 и 2 предпочтительней ключа №3. Атрибуты ключа не должны содержать нулевых значений. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа. Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами. Альтернативный ключ (Alternate Key) – это потенциальный ключ, не ставший первичным. Нормализация данных Нормализация данных – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, а также значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известны шесть нормальных форм. На практике обычно ограничиваются приведением данных к третьей нормальной форме. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила «один факт – в одном месте». Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели. Домены Домен можно определить как совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить домен «Возраст» как положительное целое число и определить атрибут Возраст сотрудника как принадлежащий этому домену. В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели. Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфические свойства, которые можно изменить вручную. Так, домен «Возраст» может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER. Каждый домен может быть описан, снабжен комментарием или свойством, определенным пользователем (UDP). Создание физической модели Создание физической модели данных Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели: 1) трансформационную модель; 2) модель СУБД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общей ИС и описывать подмножество предметной области. Данная модель позволяет проектировщикам и администраторам БД лучше представить, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель удовлетворяет требованиям к ИС. Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает более 20 реляционных и нереляционных БД. По умолчанию ERwin генерирует имена таблиц и индексов по шаблону на основе имен соответствующих сущностей и ключей логической модели, которые в дальнейшем могут быть откорректированы вручную. Имена таблиц и колонок будут сгенерированы по умолчанию на основе имен сущностей и атрибутов логической модели. Правила валидации и значения по умолчанию ERwin поддерживает правила валидации для колонок, а также значение, присваиваемое колонкам по умолчанию. Правило валидации задает список допустимых значений для конкретной колонки и/или правила проверки допустимых значений. В список допустимых значений можно вносить новые значения. ERwin позволяет сгенерировать правила валидации соответственно синтаксису выбранной СУБД с учетом границ диапазона или списка значений. Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных. С каждой колонкой или доменом можно связать значение по умолчанию. Список значений можно редактировать. После создания правила валидации и значения по умолчанию их можно присвоить одной или нескольким колонкам или доменами. Индексы В БД данные обычно хранятся в том порядке, в котором их ввели в таблицу. Многие реляционные СУБД имеют страничную организацию, при которой таблица может храниться фрагментарно в разных областях диска, причем строки таблицы располагаются на страницах неупорядоченно. Такой способ позволяет быстро вводить новые данные, но затрудняет поиск данных. Чтобы решить проблему поиска, СУБД используют объекты, называемые индексами. Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. Поскольку значения в индексе хранятся в определенном порядке, при поиске просматривать нужно значительно меньший объем данных, что существенно уменьшает время выполнения запроса. Индекс рекомендуется создавать для тех колонок, по которым часто производится поиск. При генерации схемы физической БД ERwin автоматически создает индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей и внешних ключей, поскольку эти колонки наиболее часто используются для поиска данных. Можно отказаться от генерации индексов по умолчанию и создать собственные индексы. Для увеличения эффективности поиска администратор БД должен анализировать часто выполняемые запросы и на основе анализа создавать собственные индексы. Триггеры и хранимые процедуры Триггеры и хранимые процедуры – это именованные блоки кода SQL, которые заранее откомпилированы и хранятся на сервере для того, чтобы быстро производить обработку запросов, валидацию данных и другие часто выполняемые функции. Хранение и выполнение кода на сервере позволяет создавать код только один раз, а не в каждом приложении, работающем с БД. Это экономит время при написании и сопровождении программ. При этом гарантируется, что целостность данных и бизнес-правила поддерживаются независимо от того, какое именно клиентское приложение обращается к данным. Триггеры и хранимые процедуры не требуется пересылать по сети из клиентского приложения, что значительно снижает сетевой трафик. Хранимой процедурой называется именованный набор предварительно откомпилированных команд SQL, который может вызываться из клиентского приложения или из другой хранимой процедуры. Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием может быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере. Триггер ссылочной целостности – это особый вид триггера, используемый для поддержания целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то триггер ссылочной целостности сообщает СУБД, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной строки (измененной или удаленной строки). Для генерации триггеров ERwin использует механизм шаблонов – специальных скриптов, использующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые ERwin по умолчанию, можно изменять. Для создания и редактирования хранимых процедур ERwin располагает специальными редакторами, аналогичными редакторам, используемым для создания триггеров. В отличие от триггера хранимая процедура не выполняется в ответ на какое-то событие, а вызывается из другой программы, которая передает на сервер имя процедуры. Хранимая процедура более гибкая, чем триггер, поскольку может вызывать другие хранимые процедуры. Ей можно передавать параметры, и она может возвращать параметры, значения и сообщения. Проектирование хранилищ данных В хранилища данных помещают данные, которые редко меняются. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руководителей и менеджеров. При проектировании хранилищ данных необходимо выполнять следующие требования: 1) хранилище должно иметь понятную для пользователей структуру данных; 2) должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально); должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений SQL в традиционных реляционных СУБД; 4) должна обеспечиваться поддержка сложных запросов SQL, требующих обработки миллионов записей. Как видно из этих требований, по своей структуре реляционные СУБД существенно отличаются от хранилищ данных. Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. Выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что значительно увеличивает время отклика. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса. Для эффективного проектирования хранилищ данных ERwin использует размерную модель – методологию проектирования, предназначенную специально для разработки хранилищ данных. Размерное моделирование сходно с моделированием связей и сущностей для реляционной модели, но имеет другую цель. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная модель ориентирована в первую очередь на выполнение сложных запросов В размерном моделировании принят стандарт модели, называемый схемой «звезда», которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных. Невозможно создать универсальную структуру данных, обеспечивающую высокую скорость обработки любого запроса, поэтому схема «звезда» строится для обеспечения наивысшей 3) производительности при выполнении самого важного запроса (или группы запросов). Схема «звезда» обычно содержит одну большую таблицу, называемую таблицей факта, помещенную в центре. Ее окружают меньшие таблицы, называемые таблицами размерности, которые связаны с таблицей факта радиальными связями. Для создания БД со схемой «звезда» необходимо проанализировать бизнес-правила предметной области для выяснения центрального запроса. Данные, обеспечивающие выполнение этого запроса, должны быть помещены в центральную таблицу. При проектировании хранилища важно определить источник данных, метод, которым данные извлекаются, преобразуются и фильтруются, прежде чем они импортируются в хранилище. Знания об источнике данных позволяют поддерживать регулярное обновление и проверку качества данных. Вычисление размера БД ERwin позволяет рассчитать приблизительный размер БД в целом, а также таблиц, индексов и других объектов через определенный период времени после начала эксплуатации ИС. Расчет строится на основе следующих параметров: начальное количество строк; максимальное количество строк; прирост количества строк в месяц. Результаты расчетов сводятся в отчет. Прямое и обратное проектирование Прямым проектированием называется процесс генерации физической схемы БД из логической модели. При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Обратным проектированием называется процесс генерации логической модели из физической БД. Обратное проектирование позволяет конвертировать БД из одной СУБД в другую. После создания логической модели БД путем обратного проектирования можно переключиться на другой сервер и произвести прямое проектирование. Кроме режима прямого и обратного проектирования программа обеспечивает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС. Диаграммы языка UML. Диаграмма вариантов использования UML (англ.Unified Modeling Language – унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки объектного моделирования, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. UML является языком широкого профиля, это – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода. На диаграммах вариантов использования (ВИ) изображаются акторы и варианты использования, между которыми существуют отношения. Здесь можно показывать и другие элементы UML (например, классы могут показывать, какие сущности порождаются или используются в конкретных ВИ – рис. 31). Рисунок 31 – Диаграмма вариантов использования Акторы Актором будем называть внешнюю по отношению к ПС сущность, которая может взаимодействовать с системой. Акторами могут быть как люди, так и внешние системы или устройства. Следует всегда помнить, что актор – это не конкретный человек или устройство, а роль (должностная обязанность), в которой он выступает по отношению к программной системе. Например, в качестве актора «Бухгалтер» может выступать весь наличный штат бухгалтерии. В то же время один конкретный человек может играть несколько ролей по отношению к системе. Главный бухгалтер может выступать как актор с таким же именем, но может использовать систему так же, как актор «бухгалтер» (то есть, выполнять работу обычного бухгалтера). В то же время акторы – не обязательно люди. Если ПС должна выполнять какие-либо действия в определенные моменты времени, то в качестве актора, инициирующего выполнение этих действий, может быть указан системный таймер. Нахождение акторов – один из первых шагов в определении использования любой системы (как реальной, так и программной). Каждый источник внешних событий, с которыми должна взаимодействовать система, представляется как актор. Актор должен иметь имя, которое должно отражать его роль. На диаграммах ВИ актор изображается в виде стилизованной человеческой фигурки, при этом можно использовать другие стереотипы для переопределения изображения. Варианты использования При взаимодействии актора с системой последняя выполняет ряд работ, которые образуют вариант использования системы (use case). Каждый актор может использовать систему по-разному, то есть инициировать выполнение разных ВИ. Таким образом, каждый ВИ, по существу, есть некоторое функциональное требование к системе (которое может быть разбито на несколько более мелких). ВИ не представляет собой конструкцию, напрямую реализуемую в программном коде. Все его поведение реализуется в виде классов и компонент. ВИ описывает, что делает ПС, но не как она это делает. Каждый ВИ обычно предполагает наличие нескольких вариантов поведения системы (потоков событий), один из которых является основным, остальные – альтернативными. Основной поток событий определяет последовательность действий системы, направленную на выполнение главной целевой функции данного ВИ. Альтернативные потоки описывают поведение системы в исключительных ситуациях, например, при ошибках. Описание потоков событий может быть выполнено как в текстовой форме, так и с помощью диаграмм UML, которые будут рассматриваться в дальнейшем. Лучший путь к нахождению ВИ – рассмотреть, что требует каждый актор от системы. Следует помнить, что система существует только для пользователей и должна строиться, исходя из их потребностей. Каждый ВИ должен иметь название, отвечающее его назначению. Название должно отражать, что достигается при взаимодействии с акторами. На диаграммах ВИ изображается в виде овала. Отношения Ассоциация – единственно возможная связь между актором и ВИ. Она показывает, что актор и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. На рис. 32а оператор инициирует начало выполнения ВИ открытия нового счета. Отношения между ВИ служат для извлечения из ВИ характорных фрагментов, которые могут рассматриваться как отдельные абстрактные ВИ. Примерами таких частей могут быть общие фрагменты, необязательные фрагменты и исключения. Если два или более ВИ имеют сходство в структуре и поведении, то целесообразно выделить общий фрагмент и построить новый, родительский ВИ. Исходные ВИ будут являться дочерними по отношению к родительскому. Дочерний ВИ наследует все поведение, описанное в родительском варианте. Отношение обобщения между двумя ВИ означает, что когда осуществляется дочерний ВИ, необходимо исполнение и родительского. В общем случае для того, чтобы создание родительского ВИ имело смысл, необходимо, чтобы у него было бы хотя бы два дочерних. Единственное исключение – когда имеются два ВИ и один из них является детализацией другого, но оба могут осуществляться независимо. На диаграммах показывается в виде отношения обобщения (см. рис. 32б). Отношение включения, помечаемое стереотипом <>, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения «знает» только базовый вариант использования, но не включаемый. Включение показывается пунктирной стрелкой, направленной от базового ВИ к включаемому (см. рис. 32б). Если ВИ имеет фрагменты, которые по характеру являются необязательными или представляют собой исключения и при этом не способствуют лучшему пониманию основного назначения ВИ, можно вынести за скобки такие фрагменты, создав новый, расширяющий ВИ. Начальный вариант становится базовым, который связывается с новым вариантом отношением расширения. Расширение показывается пунктирной стрелкой, направленной к расширяемому ВИ (см. рис. 32а, 32б). а) б) Рисунок 32 – Пример диаграммы ВИ: а – активация выполнения ВИ «Оператором» б – изображение двух режимов работы актора «Оператор» Актор «Оператор» активизирует выполнение ВИ «Открыть счет». В соответствии с заданным оператором типом счета выполняется либо ВИ «Открыть счет физического лица», либо «Открыть счет юридического лица», являющиеся расширениями первого. Открытие счета включает его контроль и при обнаружении ошибки – выдачу сообщения Оператору. Аналог рис. 32а. У актора «Оператор» есть два режима работы. Он активизирует «Открыть счет физического лица» либо «Открыть счет юридического лица». Открытие каждого счета включает выполнение работ, предусматриваемых в ВИ «Открыть счет», содержащим общее поведение для двух исходных ВИ. Назначение диаграмм вариантов использования Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием. При этом иерархическая организация требований представляется с помощью пакетов use cases. Диаграмма деятельности (действий). Диаграмма компонентов Диаграмма деятельности (действий) Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности. Диаграмма деятельности – это своеобразная блок-схема, которая описывает последовательность выполнения операций во времени. Их можно использовать для моделирования динамических аспектов поведения системы. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. В диаграммах деятельности (рис. 33) используются пиктограммы «действие», «переход», «выбор» и «линии синхронизации». В языке UML действие изображается в виде прямоугольника с закругленными углами, переходы – в виде направленных стрелок, элементы выбора – в виде ромбов, линии синхронизации – в виде горизонтальных и вертикальных линий. Рисунок 33 – Диаграмма деятельности Состояние действия является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока используются переходы, показывающие путь из одного состояния действия или деятельности в другое. Простые последовательные переходы встречаются наиболее часто, но их одних недостаточно для моделирования любого потока управления. Как и в блок-схеме, вы можете включить в модель выбор, который описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. Простые и ветвящиеся последовательные переходы в диаграммах деятельности используются чаще всего. Однако можно встретить и параллельные потоки, и это особенно характорно для моделирования бизнес-процессов. В UML для обозначения разделения и слияния таких параллельных потоков выполнения используются линии синхронизации, которые рисуется в видежирной вертикальной или горизонтальной линии. При моделировании течения бизнес-процессов иногда бывает полезно разбить состояния деятельности на диаграммах деятельности на группы (рис. 34), каждая из которых представляет отдел компании, отвечающий за ту или иную работу. В UML такие группы называются дорожками, поскольку визуально каждая группа отделяется от соседних вертикальной чертой, как плавательные дорожки в бассейне. Каждой присутствующей на диаграмме дорожке присваивается уникальное имя. Каждая дорожка представляет сферу ответственности за часть всей работы, изображенной на диаграмме, и может быть реализована одним или несколькими классами. Рисунок 34 – Диаграмма деятельности, разбитая на группы Диаграммы языка UML. Диаграмма последовательности Диаграмма последовательности (англ. sequence diagram) – диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл какого-либо определенного объекта (созданиедеятельность-уничтожение некой сущности) и взаимодействие акторов (действующих лиц) ИС в рамках какого-либоопределенного прецедента (отправка запросов и получение ответов). Используется в языке UML. Основными элементами диаграммы последовательности (рис. 35) являются обозначения объектов (прямоугольники с названиями объектов), вертикальные «линии жизни» (англ. lifeline), отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни»), и стрелки, показывающие обмен сигналами или сообщениями между объектами. Рисунок 35 – Диаграмма последовательности На данной диаграмме объекты располагаются слева направо. Диаграмма последовательности, пример взаимодействия при обработке электронной почты Виды стрелок Как было сказано выше, взаимодействие между акторами отображается при помощи специальных стрелок, передающих управление от отправителя (от кого идет стрелка) к получателю (тот, к кому направлена стрелка). Стрелки демонстрируют ход сценария и те события, которые происходят во время анализируемого прецедента. Всего существуют 5 видов стрелок: ● Синхронное сообщение – актор-отправитель передает ход управления актору-получателю, которому необходимо провести в прецеденте некоторое действие. Пока проводимое акторомполучателем действие не будет завершено (соответственно, не будет получено ответное сообщение), актор-отправитель теряет возможность производить какие-либо действия. Графически изображается как стрелка с закрашенным треугольником, после которой идет прямоугольник, отражающий деятельность объекта, в конце которого находится ответное сообщение. ● Ответное cообщение – данное сообщение является ответом на синхронное сообщение. Обычно содержит какое-либо возвращаемое изначальному актору-отправителю значение, также возвращающее ему управление (возможность действовать). ● Асинхронное сообщение – актор-отправитель передает ход управления актору-получателю, которому необходимо провести в прецеденте некоторое действие. Основное отличие от синхронного сообщения состоит в том, что актор-отправитель не теряет возможности совершать другие действия. ● Потерянное сообщение – сообщение без адресата (есть отправитель, нет получателя). Найденное сообщение – сообщение без отправителя. Последние два вида стрелок (взаимодействий) используются крайне редко. В основном они используются для демонстрации взаимодействия имеющихся объектов в данном прецеденте с внешними системами. Для сообщений также доступен ряд предопределенных стереотипов. Наиболее часто используемые стереотипы – это create и destroy. Сообщение со стереотипом create вызывает в классе метод, которые создает экземпляр класса. На диаграмме последовательности не обязательно показывать с самого начала все объекты, участвующие во взаимодействии. При использовании сообщения со стереотипом create создаваемый объект отображается на уровне конца сообщения. Для уничтожения экземпляра класса используется сообщение со стереотипом destroy, при этом в конце линии жизни объекта отображаются две перекрещенные линии. При отображении работы с сообщениями иногда возникает необходимость указать некоторые временные ограничения. Например, длительность передачи сообщения или ожидание ответа от объекта не должно превышать определенный временной интервал. Можно указать следующие временные параметры: ● ограничение продолжительности (Duration Constraint) – ● минимальное и максимальное значение продолжительности передачи сообщения; ● ограничение продолжительности ожидания между передачей и получением сообщения (Duration Constraint Between Messages); ● перехват продолжительности сообщения (Duration Observation); временное ограничение (Timing Constraint) – временной интервал, в течение которого сообщение должно прийти к цели (устанавливается на стороне получателя); ● перехват времени, когда сообщение было отправлено (Timing Observation). ● Диаграммы языка UML. Диаграмма классов Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования, показывая ее структуру. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними. Представление классов Класс – это основной строительный блок ПС. Это понятие присутствует и в ОО языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет название, атрибуты и операции. Класс на диаграмме показывается в виде прямоугольника (рис. 36), разделенного на 3 области. В верхней содержится название класса, в средней – описание атрибутов (свойств), в нижней – названия операций – услуг, предоставляемых объектами этого класса. Рисунок 36 – Изображение класса в нотации UML Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет. При реализации объекта в программном коде для атрибутов будет выделена память, необходимая для хранения всех атрибутов, и каждый атрибут будет иметь конкретное значение в любой момент времени работы программы. Объектов одного класса в программе может быть сколь угодно много, все они имеют одинаковый набор атрибутов, описанный в классе, но значения атрибутов у каждого объекта свои и могут изменяться в ходе выполнения программы. Для каждого атрибута класса можно задать видимость (visibility). Эта характеристика показывает, доступен ли атрибут для других классов. В UML определены следующие уровни видимости атрибутов: открытый (public) – атрибут виден для любого другого класса (объекта); защищенный (protected) – атрибут виден для потомков данного класса; закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим. Последнее значение позволяет реализовать свойство инкапсуляции данных. Например, объявив все атрибуты класса закрытыми, можно полностью скрыть от внешнего мира его данные, гарантируя отсутствие несанкционированного доступа к ним. Это позволяет сократить число ошибок в программе. При этом любые изменения в составе атрибутов класса никак не скажутся на остальной части ПС. Класс содержит объявления операций, представляющих собой определения запросов, которые должны выполнять объекты данного класса. Каждая операция имеет сигнатуру, содержащую имя операции, тип возвращаемого значения и список параметров, который может быть пустым. Реализация операции в виде процедуры – это метод, принадлежащий классу. Для операций, как и для атрибутов класса, определено понятие «видимость». Закрытые операции являются внутренними для объектов класса и недоступны из других объектов. Остальные образуют интерфейсную часть класса и являются средством интеграции класса в ПС. Отношения На диаграммах классов обычно показываются ассоциации и обобщения. Каждая ассоциация несет информацию о связях между объектами внутри ПС. Наиболее часто используются бинарные ассоциации, связывающие два класса. Ассоциация может иметь название, которое должно выражать суть отображаемой связи (рис. 37). Помимо названия ассоциация может иметь такую характеристику, как множественность. Она показывает, сколько объектов каждого класса может участвовать в ассоциации. Множественность указывается у каждого конца ассоциации (полюса) и задается конкретным числом или диапазоном чисел. Множественность, указанная в виде звездочки, предполагает любое количество (в том числе, и ноль). Например, на рисунке 37 ассоциация связывает один объект класса «Набор товаров» с одним или более объектами класса «товар». Связаны между собой могут быть и объекты одного класса, поэтому ассоциация может связывать класс с самим собой. Например, для класса «Житель города» можно ввести ассоциацию «Соседство», которая позволит находить всех соседей конкретного жителя. Рисунок 37 – Применение ассоциаций Ассоциация «включает» показывает, что набор может включать несколько различных товаров. В данном случае направленная ассоциация позволяет найти все виды товаров, входящие в набор, но не дает ответа на вопрос, входит ли товар данного вида в какой-либо набор. Ассоциация сама может обладать свойствами класса, то есть иметь атрибуты и операции. В этом случае она называется классассоциацией и может рассматриваться как класс, у которого помимо явно указанных атрибутов и операций есть ссылки на оба связываемых ею класса. В примере на рисунке 37 ассоциация «включает» по существу есть класс-ассоциация, у которой есть атрибут «Количество», показывающий, сколько единиц каждого товара входит в набор (рис. 38). Обобщение на диаграммах классов используется, чтобы показать связь между классом-родителем и классом-потомком. Оно вводится на диаграмму, когда возникает разновидность какого-либо класса (например, при развитии ПС – рис. 39), а также в тех случаях, когда в системе обнаруживаются несколько классов, обладающих сходным поведением (в этом случае общие элементы поведения выносятся на более высокий уровень, образуя класс-родитель – рис. 38). Рисунок 38 – Наследуются атрибуты и операции Как уже говорилось ранее, UML позволяет строить модели с различным уровнем детализации. На рис. 39 показана детализация модели, представленной на рис. 37. Рисунок 39 – Детализация модели набора товаров Обобщение показывает, что набор товаров – это тоже товар, который может быть предметом заказа, продажи, поставки и т. д. Набор включает опись, в которой указывается, какие товары входят в набор, а класс-ассоциация «включает» определяет количество каждого вида товаров в наборе. Стереотипы классов При создании диаграмм классов часто пользуются понятием «стереотип». В дальнейшем речь пойдет о стереотипах классов. Стереотип класса – это элемент расширения словаря UML, который обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках. Есть четыре стандартных стереотипа классов, для которых предусмотрены специальные графические изображения (рис. 40). Стереотип используется для обозначения классов – сущностей (классов данных), стреотип описывает пограничные классы, которые являются посредниками между ПС и внешними по отношению к ней сущностями – акторами, обозначаемыми стереотипом <>. Наконец, стереотип описывает классы и объекты, которые управляют взаимодействиями. Применение стереотипов позволяет, в частности, изменить вид диаграмм классов. Рисунок 40 – Стереотипы для классов Применение диаграмм классов Диаграммы классов создаются при логическом моделировании ПС и служат для следующих целей: Для моделирования данных. Анализ предметной области позволяет выявить основные характорные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных. Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС. • Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения. • Для моделирования логики программных компонент. • Для моделирования логики обработки данных. Диаграммы языка UML. Диаграмма взаимодействия объектов Диаграммы UML: зачем они нужны? UML – является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose и Enterprise Architect. На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а также обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему). Диаграммы UML и есть та основная накладываемая на модель структура, которая облегчает создание и использование модели. Диаграмма (diagram) – это графическое представление некоторой части графа модели. В диаграмму можно было бы включить любые (допустимые) комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы понимание моделей. Поэтому авторы UML определили набор рекомендуемых к использованию типов диаграмм, которые получили название канонических. Обратите внимание, что диаграммы не являются частью UML, как и абзацы или параграфы не являются частью естественного языка. Канонические диаграммы UML – это сложившаяся практика группирования сущностей и отношений. Мы уже познакомились с диаграммами UML нескольких видов. Одни из них описывают систему со статической точки зрения, например, диаграмма классов. Другие – с точки зрения описания поведения системы, ее динамики, например, диаграмма активностей. Еще одним типом диаграмм, описывающих поведенческие аспекты системы, являются диаграмма состояний и диаграммы взаимодействия, к которым относятся диаграммы последовательностей (Sequence Diagram) и кооперации (Cooperation Diagram). Вот о них-то мы сейчас и поговорим. В этой лекции мы рассмотрим такие вопросы: диаграммы взаимодействия и их место среди других диаграмм UML; диаграммы последовательностей и их нотация, диаграммы кооперации и их нотация. Элементы диаграммы взаимодействий Большинство Case-средств позволяет после построения одной из диаграмм автоматически получить другую, а также выполнять синхронизацию этих диаграмм между собой. Общими элементами диаграмм являются: – экземпляры акторов и объекты, участвующие во взаимодействии; – сообщения, передаваемые между экземплярами акторов и объектами. Экземпляры сущностей отображаются стандартно (экземпляр актора – человечком, экземпляр класса (объект) – прямоугольником или графическим стереотипом класса анализа). В то же время следует помнить, что экземпляр – это конкретная реализация соответствующей сущности (актора, класса, узла и т. д.). Чтобы учесть этот нюанс на диаграммах, имя экземпляра подчеркивается и может отображаться в следующих вариантах: – Имя объекта: Имя класса (например, Вася: Программист); – Имя класса (например, :Программист) – анонимный объект; – Имя объекта (например, Вася) – предполагается, что имя класса известно; – Имя объекта: (например, Вася :) – объект-сирота. Считается, что имя класса неизвестно. Для объектов, кроме имени, могут указываться также некоторые важные для взаимодействия атрибуты и их значения. Взаимодействие между экземплярами акторов и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (острие стрелки указывает на принимающую сторону) и спецификации. Зачастую на этапе спецификации требований необходимо показать не только алгоритм действий или изменение состояния объекта, но и обмен сообщениями между отдельными объектами Системы. Данную задачу решает диаграмма взаимодействия. Диаграмма взаимодействия предназначена для моделирования отношений между объектами (ролями, классами, компонентами) Системы в рамках одного прецедента. Данный вид диаграмм отражает следующие аспекты проектируемой Системы: • обмен сообщениями между объектами (в том числе, в рамках обмена сообщениями со сторонними Системами), • ограничения, накладываемые на взаимодействие объектов, • события, инициирующие взаимодействия объектов. В отличие от диаграммы деятельности, которая показывает только последовательность (алгоритм) работы Системы, диаграммы взаимодействия акцентируют внимание разработчиков на сообщениях, инициирующих вызов определенных операций объекта (класса) или являющихся результатом выполнения операции. Расширение нотации диаграмм взаимодействия в UML 2.0 позволяет аналитикам на более детальном уровне проработки требований по возможности заменять диаграммы деятельности диаграммами взаимодействия. Таким образом, основной целевой аудиторией для диаграммы взаимодействия будет команда разработчиков. Для Заказчика данный вид диаграмм будет интересен только в рамках моделирования взаимодействия проектируемой ИС и сторонних Систем, работающих на стороне Заказчика. Для описания взаимодействия объектов в UML предусмотрены следующие виды диаграмм: ⚫ Диаграмма последовательности – моделирует последовательность обмена сообщениями между объектами, ⚫ Диаграмма коммуникаций – модулирует структуру взаимодействующих компонентов (для данного вида диаграммы в UML 1 используется наименование «диаграмма коопераций»), ⚫ Временные диаграммы – моделирует изменение состояния нескольких объектов в момент взаимодействия, ⚫ Диаграмма обзора взаимодействия – сочетание диаграммы деятельности и диаграммы последовательности. Взаимодействие между отдельными компонентами Системы лучше отражает диаграмма коммуникаций. Данный вид диаграмм предназначен в основном для моделирования отношений между объектами. Диаграммы взаимодействия и их место среди других диаграмм UML Диаграмма взаимодействия – это диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними, включая и сообщения, которыми они обмениваются. Этот термин применяется к видам диаграмм с акцентом на взаимодействии объектов (диаграммах кооперации, последовательности и деятельности). Несмотря на то величайшее уважение, которое мы питаем к Г. Бучу, это определение не кажется нам уж очень удачным. Хотя суть понятия оно передает. Наиболее важное слово в этом определении – это слово «сообщения». Действительно, как люди программирующие, мы понимаем, что взаимодействие как раз и состоит в обмене сообщениями между объектами. И к вопросу о сообщениях мы в этой лекции еще не раз вернемся. А пока же посмотрим, что Буч говорит дальше. А дальше он объясняет, что такое диаграммы кооперации и последовательностей. Диаграмма последовательностей – диаграмма взаимодействия, в которой основной акцент сделан на упорядочении сообщений во времени. Диаграмма кооперации – диаграмма взаимодействий, в которой основной акцент сделан на структурной организации объектов, посылающих и получающих сообщения. То есть диаграмма последовательности описывает (и именно поэтому так и называется) последовательность, в которой объекты отправляют и получают сообщения, а диаграмма кооперации – это аналог диаграммы последовательностей, который тоже показывает обмен сообщениями между объектами, но акцентирует внимание на ролях, которые объекты играют во взаимодействии. Эти два типа диаграмм вообще-то взаимозаменяемы, и решение, какую именно из них использовать в каждом конкретном случае, каждый проектировщик принимает исходя из личных предпочтений. А какое же место диаграммы взаимодействия занимают среди других диаграмм UML? На этот вопрос можно ответить двояко. Можно просто говорить о построении диаграмм взаимодействия как об определенном этапе в процессе моделирования. А можно вспомнить о фазах жизненного цикла разработки ПО и посмотреть, где же диаграммы взаимодействия окажутся в таком случае. Да, кстати, кто помнит, какая диаграмма UML наилучшим образом подходит для описания процессов? Диаграмма активностей. Что ж, попробуем нарисовать диаграмму активностей (рис. 41), описывающую процесс построения модели системы: Рисунок 41 – Диаграмма активностей Диаграмма показывает, что диаграммы взаимодействия строятся после того, как описана структура системы (диаграмма классов, диаграмма компонентов), способы ее взаимодействия с внешним миром (диаграмма прецедентов) и алгоритмы действий, выполняющихся в системе (диаграмме активностей). Это как бы последний штрих, уточнение того, как именно ведет себя система путем изображения взаимодействия объектов внутри ее. Для того же чтобы показать место диаграмм взаимодействия в жизненном цикле разработки ПО, нарисуем еще одну «псевдодиаграмму». Правильнее было бы сказать, что та диаграмма, которую вы сейчас увидите (рис. 42), показывает, какие артефакты разработки документируются какими диаграммами. Рисунок 42 – Документирование этапов разработки с помощью UML Из рисунка 42 очень хорошо видно, что диаграмма последовательностей и диаграмма кооперации взаимозаменяемы и являются альтернативными друг другу шагами процесса. Диаграммы языка UML. Диаграмма развертывания Диаграмма развертывания – один из доступных видов диаграмм, поддерживаемых Flexberry Designer. Корпоративные приложения часто требуют для своей работы некоторой ИТ-инфраструктуры, хранят информацию в базах данных, расположенных где-то на серверах компании, вызывают веб-сервисы, используют общие ресурсы и т. д. В таких случаях полезно иметь графическое представление инфраструктуры, на которую будет развернуто приложение. Для этого и нужны диаграммы развертывания (рис. 43), которые иногда называют диаграммами размещения. Рисунок 43 – Диаграмма развертывания Такие диаграммы есть смысл строить только для аппаратнопрограммных систем, тогда как UML позволяет строить модели любых систем, не обязательно компьютерных. Польза диаграмм развертывания: Графическое представление ИТ-инфраструктуры может помочь более рационально распределить компоненты системы по узлам сети, от чего зависит, в том числе, и производительность системы. 2. Такая диаграмма может помочь решить множество вспомогательных задач, связанных, например, с обеспечением безопасности. Диаграмма развертывания показывает топологию системы и распределение компонентов системы по ее узлам, а также соединения – маршруты передачи информации между аппаратными узлами. Это – единственная диаграмма, на которой применяются «трехмерные» обозначения: узлы системы обозначаются кубиками. Все остальные обозначения в UML – плоские фигуры. 1. Основные элементы диаграммы развертывания На диаграмме развертывания можно отобразить следующие элементы нотации UML, доступные в панели элементов: Элемент/Нотация Предназначение Компонент (Component) Экземпляр компонента (Component instance) Интерфейс (Interface) Узел (Node) Экземпляр узла (Node instance) Объект (Object) Активный объект (Active object) Элемент/Нотация Предназначение Зависимость (Dependency) Точка изгиба связей (Point) Комментарий (Note) Коннектор комментария (Note connector) Проектирование интерфейсов. Модель ролей Эта модель представляет собой список ролей пользователей системы. Каждая роль – это группа связанных задач и потребностей некоторого множества пользователей. Модель ролей может определять связи между ролями (роли могут уточнять друг друга, включать друг друга или просто быть похожими) и набор из одной-трех центральных ролей, на которые, в основном, и будет нацелено проектирование. Кроме того, каждая роль может быть снабжена профилями, указывающими различные ее характеристики по отношению к контексту использования системы. Профили могут включать следующую информацию. • Обязанности – требования к знаниям (о предметной области, о самой системе и пр.), которым пользователь в данной роли, скорее всего, удовлетворяет. • Умения – уровень мастерства в работе с системой. • Взаимодействия – типичные варианты взаимодействия пользователя в этой роли с системой, включая их частоту, регулярность, непрерывность, концентрацию, интенсивность, сложность, предсказуемость, а также управление взаимодействием (направляется ли оно пользователем, или он только реагирует на действия системы). • Информация – источники, объем, направление передачи и сложность информации при взаимодействии с системой. • Критерии удобства – специфические критерии удобства работы для данной роли (быстрота реакции, точность указаний, удобство навигации и пр.). • Функции – специфические функции, возможности и свойства системы, необходимые или полезные для данной роли. • Возможные убытки от ошибок, которые может совершить человек в данной роли, риски использования различных функций. Пример модели ролей для пользователей банкомата приведен на рисунке 44. Рисунок 44 – Модель ролей пользователей банкомата Проектирование интерфейсов. Модель задач Модель задач при проектировании пользовательского интерфейса строится на основе сущностных вариантов использования (essential use cases). Описание сущностного варианта использования отличается от обычного тем, что в рамках его сценариев выделяются только цели и задачи пользователя, а не конкретные его действия. Таблица 4. Описание обычного (слева) и сущностного (справа) вариантов использования Действия Вставить карту Реакции Задачи Регистрация в системе Считать данные Запросить PIN Обязательства Проверка личности Ввести PIN Проверить PIN Вывести меню Нажать клавишу выдачи денег Предложение набора операций Выбор операции выдачи денег Запросить сумму Ввести сумму Вывести сумму Запросить подтверждение Нажать клавишу подтверждения Вернуть карту Выдать деньги Напечатать чек Выдать чек Выдача денег Выдача чека Целью такого выделения является освобождение от неявных предположений о наличии определенных элементов интерфейсов, что помогает разрабатывать их именно для решаемых задач. Удобно описывать такие сценарии в виде двух последовательностей – устремлений пользователя (не действий, а задач, которые он хочет решить) и обязательств системы в ответ на эти устремления. Пример описания обычного и сущностного варианта использования при работе приведен в табл. 4. В результате модель задач представляет собой набор переработанных вариантов использования со связями между ними по обобщению, расширению и использованию. Некоторые из вариантов использования объявляются основными – без них программа потеряет значительное количество пользователей. Всякая пользовательская роль при этом должна быть связана с одним или несколькими вариантами использования. Проектирование интерфейсов. Модель содержимого Модель содержимого пользовательского интерфейса описывает набор взаимосвязанных контекстов взаимодействия или рабочих пространств (представляемых экранами, формами, окнами, диалогами, страницами и пр.) с содержащимися в них данными и возможными в их рамках действиями. При построении этой модели нужно определить, что войдет в состав интерфейса (какие данные и функции), и не решать вопрос о том, как именно оно будет выглядеть. На начальном этапе один контекст взаимодействия ставится в соответствие одному (не вспомогательному!) варианту использования или группе очень похожих вариантов, для выполнения которых понадобится один и тот же набор инструментов. Средства для поддержки вспомогательных расширяющих вариантов использования обычно удобно помещать в контексты расширяемых ими основных вариантов. Сначала устанавливается, какая информация должна находиться в заданном контексте для успешного решения задач соответствующего варианта использования, затем определяется список необходимых операций для работы с этой информацией. Часто при обсуждении содержимого контекста взаимодействия для его представления используют лист бумаги с наклеенными на него подписанными стикерами разных цветов (для различения информационных элементов и элементов управления). Такое представление удобно для быстрого внесения изменений по ходу обсуждения. Оно также наглядно показывает, что рассматривается лишь прототип окна или странички, а его элементы абстрактны, для них пока не предлагается конкретная форма. Его трудно принять за «почти готовый» проект окна, формы или странички, описывающий итоговые форму, расположение и цвета элементов интерфейса. На рис. 45 приведен пример модели содержимого окна поиска номеров телефонов программы, реализующей корпоративный телефонный справочник. Рисунок 45 – Пример модели содержимого контекста взаимодействия После определения набора контекстов и их информационного и функционального содержимого рисуется между контекстами, показывающая карта навигации возможные переходы между ними (рис. 46). Карта навигации объединяет различные контексты взаимодействия в рамках модели содержимого интерфейса. Рисунок 46 – Часть карты навигации редактора Microsoft Word После разработки модели содержимого всякий основной вариант использования должен быть поддержан при помощи одного или нескольких контекстов взаимодействия. Чем меньше контекстов нужно использовать для выполнения одного варианта использования, тем лучше. Перечисленные три вида моделей – ролей, задач и содержимого – являются основными. Оставшиеся два вида моделей используются только при необходимости. Основные виды деятельности в рамках проектирования: Совместное с пользователями определение требований к ПО, с учетом пожеланий и требований к его интерфейсу. • Разработка модели предметной области с помощью пользователей. • Разработка моделей ролей и задач с помощью пользователей. • Разработка модели содержимого. • Разработка визуального проекта интерфейса (модели реализации). • Контроль удобства использования проекта интерфейса с участием пользователей. • Проектирование объектной структуры ПО. • Определение стандартов и стиля интерфейса с привлечением пользователей. • Проектирование и разработка справочной системы и документации. • Привязка интерфейса к контексту использования. • Итеративная разработка архитектуры ПО. • Итеративное конструирование ПО с постепенным введением запланированных функций. Контроль удобства использования готового ПО. • Проектирование интерфейсов Операционная модель Перечисленные три вида моделей – ролей, задач и содержимого – являются основными. Оставшиеся два вида моделей используются только при необходимости. Операционная модель описывает контекст использования системы и состоит из профилей пользовательских ролей. Модель реализации представляет собой визуальный проект интерфейса и описание его работы. Основные виды деятельности в рамках проектирования, ориентированного на использование, следующие: Совместное с пользователями определение требований к ПО, с учетом пожеланий и требований к его интерфейсу. Разработка модели предметной области с помощью пользователей. Разработка моделей ролей и задач с помощью пользователей. Разработка модели содержимого. Разработка визуального проекта интерфейса (модели реализации). Контроль удобства использования проекта интерфейса участием пользователей. Проектирование объектной структуры ПО. с Определение стандартов и стиля интерфейса с привлечением пользователей. Проектирование и разработка справочной системы и документации. Привязка интерфейса к контексту использования. Итеративная разработка архитектуры ПО. Итеративное конструирование ПО с постепенным введением запланированных функций. Контроль удобства использования готового ПО. Рисунок 47 – Взаимосвязи и распределение деятельностей во времени Деятельности, в которые вовлечены пользователи, помечены звездочкой (рис. 47). Эти деятельности не выполняются строго друг за другом в виде отдельных шагов. Для описания их распределения во времени используется диаграмма, изображенная на рис. 47 [12]. Модель реализации Следующими этапами является формализация полученной постановки задачи путем отсеивания ненужных элементов, организация классов выделенных элементов, задание области и типов их допустимых значений, действий над ними с целью создания полноценной модели предметной области. В качестве преимуществ подобного способа извлечения задачи можно указать на снижение степени непонимания между разработчиком и пользователем, вовлечение пользователя в проект с самого начала его реализации и построение им каркаса модели задачи и модели предметной области. Однако вызывает сомнение возможность использования данного подхода для решения задач со сложной моделью предметной области, имеющей большой объем и сложную структуру системы понятий, необходимую для решения задачи, обеспечения пользователя интеллектуальной поддержкой, поскольку каркас и элементы модели (термины и понятия) выделяются на основе неформального описания задачи пользователем.