CASE-технологии проектирования информационных систем
За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) - в дословном переводе - разработка программного обеспечения информационных систем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, термин CASE используется в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обес-печения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных автоматизированных информационных систем в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (ПО) (приложений) и баз данных, генерацию кода, тести-рование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
CASE-средства позволяют не только создавать "правильные" продукты, но и обеспечить "правильный" процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ИС от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования ИС. При использовании CASE-технологий изменяются все этапы жизненного цикла программного обеспечения (подробнее об этом будет сказано ниже) информационной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих специ-фикации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Такие методологии обеспечивают строгое и наглядное описание про-ектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. CASE-технологии успешно применяются для построения практически всех типов ИС, однако устойчивое положение они занимают в следующих областях:
обеспечение разработки деловых и коммерческих ИС, широкое применение CASE-технологий обусловлены массовостью этой прикладной области, в которой CASE применяется не только для разработки ИС, но и для создания моделей систем, помогающих решать задачи стратегического планирования, управления финансами, определения политики фирм, обучения персонала и др. (это направление получило свое собственное на-звание - бизнес-анализ);
разработка системного и управляющих ИС. Активное применение CASE-технологий связано с большой сложностью данной проблематики и со стремлением повысить эффективность работ.
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE-средства обладают следующими основными достоинствами:
улучшают качество создаваемых ИС за счет средств автоматического контроля (прежде всего контроля проекта);
позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат;
ускоряют процесс проектирования и разработки;
освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки;
поддерживают развитие и сопровождение разработки;
поддерживают технологии повторного использования компонента разработки.
Необходимо понимать, что успешное применение CASE-средств невозможно без понимания базовой технологии, на которой эти средства основаны. Сами по себе программные CASE-средства являются средствами автоматизации процес-сов проектирования и сопровождения информационных систем. Без понимания методологии проектирования ИС невозможно применение CASE-средств.
^
Характеристика современных CASE-средств
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл (ЖЦ) ИС.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых техни-ческих решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирова-ния предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых, так или иначе, используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ИС и обладающее следующими основными характерными особенностями:
мощными графическими средствами для описания и документирования ИС, обеспечивающими удобный интерфейс с разработчиком и развивающими его твор-ческие возможности;
интеграцией отдельных компонент CASE-средств, обеспечивающей управляемость процессом разработки ИС;
использованием специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ИС) содержит следующие компоненты:
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархичес-ки связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений, включая языки 4GL и генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPWin (Logic Works));
средства анализа и проектирований (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналитик (Макро-Проджект)). Выходом таких средств являются специ-фикации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных , обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее рас-пространенных СУБД. К ним относятся ERwin (Logic Works). S-Designor (SDP) и DataBase Designer (Oracle). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений . К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга , обеспечивающие анализ про-граммных кодов и схем баз данных и формирование на их основе различных моделей и проектных специфи-каций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS (Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA (Rational Software)).
Silverrun;
Designer/2000;
Vantage Team Builder (Westmount I-CASE);
ERwin+BPwin;
S-Designor;
CASE-Аналитик.
Охарактеризуем основные возможности CASE-средств на примере имеющей широкое распространение системы Silverrun.
CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и про-ектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживае-мая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.
Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без связи с остальными модулями.
Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автома-тическая перенумерация, работа с деревом процессов (вклю-чая визуальное перетаскивание ветвей), отсоединение и при-соединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.
Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.
Модуль реляционного моделирования (RDM- Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в ре-ляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных . На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представле-ния. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.
^ Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.
Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ИС.
Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет доку-ментировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех воз-можностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.
Для обмена данными с другими средствами автоматиза-ции проектирования, создания специализированных проце-дур анализа и проверки проектных спецификаций, составле-ния специализированных отчетов в соответствии с различными стандартами в системе Silverrun имеются три способа выдачи проектной информации во внешние файлы:
система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редак-тор или включить в другой отчет;
система экспорта/импорта. Для более полного контро-ля над структурой файлов в системе экспорта/импор-та имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не толь-ко формировать, но и загружать в репозитории. Это дает возможность обмениваться данными с различны-ми системами: другими CASE-средствами, СУБД, тек-стовыми редакторами и электронными таблицами;
хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к данным репозитория из наиболее распространенных систем управления базами данных обеспечена возможность хранить всю проектную информацию непосредственно в формате этих СУБД.
в стандартной однопользовательской версии имеется механизм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спецификации;
сетевая версия Silverrun позволяет осуществлять одно-временную групповую работу с моделями, хранящи-мися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчи-ков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.
Помимо системы Silverrun, укажем назначение и дру-гих популярных CASE-средств и их групп.
Vantage Team Builder представляет собой интегрирован-ный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ИС и поддержку полного ЖЦ ИС.
Uniface 6.1 – продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных прило-жений в архитектуре "клиент-сервер".
CASE-средство Designer/2000 2.0 фирмы Oracle является интегрированным CASE-средством, обеспечивающим в со-вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ИС для систем, использующих СУБД Oracle.
Пакет CASE/4/0 (microTOOL GmbH), включающий структурные средства системного анализа, проектирования и программирования, обеспечивает поддержку всего жизненного цикла разработки (вплоть до сопровождения), на основе сете-вого репозитория, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналитиков, проектировщиков, программистов).
^
Локальные средства
Пакет ERWin (Logic Works) используется при моделировании и создании баз данных произвольной сложности на ос-нове диаграмм "сущность-связь". В настоящее время ERWin является наиболее популярным пакетом моделирований дан-ных благодаря поддержке широкого спектра СУБД самых различных классов - SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdb и др.) и "настольных" СУБД типа xBase (Clipper, dBase, FoxPro, MS Access, Paradox и др.).
BPWin - средство функционального моделирования, реализующее методологию IDEFO. Модель в BPWin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс, разбивая его на шаги и подпроцессы.
S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERWin, отличаясь внешне ис-пользуемой на диаграммах нотацией. S-Designer реализует стандартную методологию моделирования данных и генери-рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server и др.
CASE-Аналитик 1.1 (Эйтекс) является практически един-ственным в настоящее время конкурентоспособным отече-ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответ-ствии с описанной ранее методологией.
^
Объектно-ориентированные CASE-средства
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ИС, а также для генерации кодов на различных языках и выпуска проектной документа-ции. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (язык UML - Unified Modeling Language) является в настоящее время и, очевид-но, останется в будущем общепринятым стандартом в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
^
Средства конфигурационного управления
Цель конфигурационного управления (КУ) - обеспечить управляемость и контролируемость процессов разработки и сопровождения ИС. Для этого необходима точная и достоверная информация о состоянии ИС и его компонент в каждый момент времени, а также о всех предполагаемых и выполненных изменениях.
Для решения задач КУ применяются методы и средства, обеспечивающие идентификацию состояния компонент, учет номенклатуры всех компонент и модификаций системы в це-лом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координирован-ное управление развитием функций и улучшением характеристик системы.
Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.
^
Средства документирования
Для создания документации в процессе разработки АИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).
Продукт SoDA предназначен для автоматизации разработки проектной документации на всех фазах ЖЦ ИС. Он позволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и включать ее в выходные документы. При этом контролируется соответствие документации проекту, взаимосвязь документов, обеспечивается их своевременное обновление. Результи-рующая документация автоматически формируется из множества источников, число которых не ограничено.
Пакет включает в себя графический редактор для подготовки шаблонов документов. Он позволяет задавать необходимый стиль, фон, шрифт, определять расположение заголовков, резервировать места, где будет размещаться извлекаемая из разнообразных источников информация. Изменения автоматически вносятся только в те части документации, на которые они повлияли в программе. Это сокращает время подготовки документации за счет отказа от перегенерации всей документации.
SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по редактированию и верстке выпускаемой документации.
Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого до-кумента (или его части) возможен из системы SoDA.
Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.
^
Средства тестирования
Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок. Регрессионное тести-рование - это тестирование, проводимое после усовершен-ствования функций программы или внесения в нее изменений.
Одно из наиболее развитых средств тестирования QA (новое название – Quality Works) представляет собой интег-рированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
В заключение приведем пример комплекса CASE-средств, обеспечивающего поддержку полного ЖЦ ИС. Нецелесообразно сравнивать отдельно взятые CASE-средства, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ИС. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ИС. Сравниваться могут комплексы методоло-гически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ИС и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков (отметим, что рациональное комплексирование инструментальных средств разработки ИС является важнейшим условием обеспечения качества этой ИС, причем это замечание справедливо для всех предметных областей).
Лекция №8
Многоуровневая архитектура 9
Интернет/интранет-технологии 10
Требования, предъявляемые к информационным системам 10
Гибкость 11
Надежность 11
Эффективность 11
Безопасность 12
Жизненный цикл информационных систем 16
Общие сведения об управлении проектами 17
^ Классификация проектов 18
Основные фазы проектирования информационной системы 18
Концептуальная фаза 19
Подготовка технического предложения 19
Проектирование 19
Разработка 20
Ввод системы в эксплуатацию 20
Процессы, протекающие на протяжении жизненного цикла информационной системы 21
^ Основные процессы жизненного цикла 21
Разработка 21
Эксплуатация 21
Сопровождение 22
Вспомогательные процессы жизненного цикла 23
Организационные процессы 23
Структура жизненного цикла информационной системы 23
Начальная стадия 24
Стадия уточнения 24
^ Стадия конструирования 24
Стадия передачи в эксплуатацию 24
Жизненный цикл информационных систем 28
Модели жизненного цикла информационной системы 28
^ Каскадная модель жизненного цикла информационной системы 29
Основные этапы разработки по каскадной модели 29
Основные достоинства каскадной модели 29
Недостатки каскадной модели 30
^ Спиральная модель жизненного цикла 31
Итерации 31
Преимущества спиральной модели 32
Недостатки спиральной модели 33
Методология и технология разработки информационных систем 37
Методология RAD 40
Основные особенности методологии RAD 40
^ Объектно-ориентированный подход 41
Визуальное программирование 42
Событийное программирование 43
Фазы жизненного цикла в рамках методологии RAD 44
Фаза анализа и планирования требований 44
Фаза проектирования 44
Фаза построения 45
Фаза внедрения 46
^ Ограничения методологии RAD 46
Методология и технология разработки информационных систем 51
Профили открытых информационных систем 51
Понятие профиля информационной системы 52
Принципы формирования профиля информационной системы 53
^ Структура профилей информационных систем 55
Профиль прикладного программного обеспечения 57
Профиль среды информационной системы 57
Профиль защиты информации 58
Профиль инструментальных средств 58
^ Методология и технология разработки информационных систем 63
Стандарты и методики 63
Виды стандартов 64
Методика CDM фирмы Oracle 65
Общая структура 66
Особенности методики СDМ 68
^ Международный стандарт ISO/IEC 12207: 1995-08-01 69
Общая структура 69
Основные и вспомогательные процессы ЖЦ 69
Особенности стандарта ISO 12207 71
CASE-технологии проектирования информационных систем 77
Характеристика современных CASE-средств 80
^ Локальные средства 86
Объектно-ориентированные CASE-средства 87
Средства конфигурационного управления 87
Средства документирования 87
Средства тестирования 88
Принципы построения и этапы проектирования баз данных 93
Основные понятия и определения 93
Описательная модель предметной области 99
^ Принципы построения и этапы проектирования баз данных 111
Концептуальные модели данных 111
Типы структур данных 112
Операции над данными 113
^ Ограничения целостности 114
Иерархическая модель данных 115
Сетевая модель данных 117
Реляционная модель данных 118
Бинарная модель данных 119
Семантическая сеть 119
Технология моделирования информационных систем 124
Методы моделирования систем 124
^ Математическая модель системы 126
Классификация математических моделей 128
Имитационные модели информационных систем 136
Методологические основы применения метода имитационного моделирования 136
^ Имитационные модели информационных систем 146
Классификация имитационных моделей 146
Структура типовой имитационной модели с календарем событий 153
^ Имитационные модели информационных систем 161
Технология моделирования случайных факторов 161
Генерация псевдослучайных чисел (ПСЧ) 161
Мультипликативный метод 163
Аддитивный метод 164
Смешанный метод 164
^ Моделирование случайных событий 165
Последовательное моделирование 167
Моделирование после предварительных расчетов 167
Имитационные модели информационных систем 172
Технология моделирования случайных факторов 172
^ Моделирование случайных величин 172
Моделирование непрерывных случайных величин 173
Метод обратной функции 173
Метод исключения (Неймана) 174
Метод композиции 176
Моделирование дискретных случайных величин 177
Метод последовательных сравнений 177
Метод интерпретации 178
^ Моделирование случайных векторов 178
Метод условных распределений 179
Метод исключения (Неймана) 180
Метод линейных преобразований 181
Имитационные модели информационных систем 187
Основы организации имитационного моделирования 187
^ Этапы имитационного моделирования 187
Испытание имитационной модели 188
Задание исходной информации 189
Верификация имитационной модели 189
Проверка адекватности модели 189
Калибровка имитационной модели 190
Исследование свойств имитационной модели 190
Оценка погрешности имитации, связанной с использованием в модели генераторов псевдослучайных чисел (ПСЧ) 190
Определение длительности переходного режима 191
Оценка устойчивости результатов имитации 192
Исследование чувствительности модели 192
^
Языки моделирования 193
Характеристики современных операционных систем
Год за годом происходит эволюция структуры и возможностей операционных систем. В последнее время в состав новых операционных систем и новых версий уже существующих операционных систем вошли некоторые структурные элементы, которые внесли большие изменения в природу этих систем. Современные операционные системы отвечают требованиям постоянно развивающегося аппаратного и программного обеспечения. Они способны управлять работой многопроцессорных систем, работающих быстрее обычных машин, высокоскоростных сетевых приспособлений и разнообразных запоминающих устройств, число которых постоянно увеличивается. Из приложений, оказавших влияние на устройство операционных систем, следует отметить мультимедийные приложения, средства доступа к Internet, а также модель клиент/сервер.
Неуклонный рост требований к операционным системам приводит не только к улучшению их архитектуры, но и к возникновению новых способов их организации. В экспериментальных и коммерческих операционных системах были опробованы самые разнообразные подходы и структурные элементы, большинство из которых можно объединить в следующие категории.
· Архитектура микроядра.
· Многопоточность.
· Симметричная многопроцессорность.
· Распределенные операционные системы.
· Объектно-ориентированный дизайн.
Отличительной особенностью большинства операционных систем на сегодняшний день является большое монолитное ядро. Ядро операционной системы обеспечивает большинство ее возможностей, включая планирование, работу с файловой системой, сетевые функции, работу драйверов различных устройств, управление памятью и многие другие. Обычно монолитное ядро реализуется как единый процесс, все элементы которого используют одно и то же адресное пространство. В архитектуре микроядра ядру отводится лишь несколько самых важных функций, в число которых входят работа с адресными пространствами, обеспечение взаимодействия между процессами (interprocess communication - IPC) и основное планирование. Работу других сервисов операционной системы обеспечивают процессы, которые иногда называют серверами. Эти процессы запускаются в пользовательском режиме и микроядро работает с ними так же, как и с другими приложениями. Такой подход позволяет разделить задачу разработки операционной системы на разработку ядра и разработку сервера. Серверы можно настраивать для требований конкретных приложений или среды. Выделение в структуре системы микроядра упрощает реализацию системы, обеспечивает ее гибкость, а также хорошо вписывается в распределенную среду. Фактически микроядро взаимодействует с локальным и удаленным сервером по одной и той же схеме, что упрощает построение распределенных систем.
Многопоточность (multithreading) - это технология, при которой процесс, выполняющий приложение, разделяется на несколько одновременно выполняемых потоков. Ниже приведены основные различия между потоком и процессом.
· Поток. Диспетчеризуемая единица работы, включающая контекст процессора (куда входит содержимое программного счетчика и указателя вершины стека), а также свою собственную область стека (для организации вызова подпрограмм и хранения локальных данных). Команды потока выполняют ся последовательно; поток может быть прерван при переключении процессора на обработку другого потока 4 .Процесс. Набор из одного или нескольких потоков, а также связанных с этими потоками системных ресурсов (таких, как область памяти, в которую входят код и данные, открытые файлы, различные устройства). Эта концепция очень близка концепции выполняющейся программы. Разбивая приложение на несколько потоков, программист получает все преимущества модульности приложения и возможность управления связанными с приложением временными событиями.
Многопоточность оказывается весьма полезной для приложений, выполняющих несколько независимых заданий, которые не требуют последовательного исполнения. В качестве примера такого приложения можно привести сервер базы данных, который одновременно принимает и обрабатывает несколько запросов клиентов. Если в пределах одного и того же процесса обрабатываются несколько потоков, то при переключении между различными потоками непроизводительный расход ресурсов процессора меньше, чем при переключении между разными процессами. Кроме того, потоки полезны при описанном в последующих главах структурировании процессов, которые являются частью ядра операционной системы.
До недавнего времени все персональные компьютеры, рассчитанные на одного пользователя, и рабочие станции содержали один виртуальный микропроцессор общего назначения. В результате постоянного повышения требований к производительности и понижения стоимости микропроцессоров производители перешли к выпуску компьютеров с несколькими процессорами. Для повышения эффективности и надежности используется технология симметричной многопроцессорности (symmetric multiprocessing - SMP). Этот термин относится к архитектуре аппаратного обеспечения компьютера, а также к образу действий операционной системы, соответствующему этой архитектурной особенности. Симметричную многопроцессорность можно определить как автономную компьютерную систему со следующими характеристиками.
1. В системе имеется несколько процессоров.
2. Эти процессоры, соединенные между собой коммуникационной шиной или какой-нибудь другой схемой, совместно используют одну и ту же основную память и одни и те же устройства ввода-вывода.
3. Все процессоры могут выполнять одни и те же функции (отсюда название симметричная обработка).
Операционная система, работающая в системе с симметричной многопроцессорностью, распределяет процессы или потоки между всеми процессорами. У многопроцессорных систем есть несколько потенциальных преимуществ по сравнению с однопроцессорными, в число которых входят следующие.
· Производительность . Если задание, которое должен выполнить компьютер, можно организовать так, что какие-то части этого задания будут выполняться параллельно, это приведет к повышению производительности по сравнению с однопроцессорной системой с процессором того же типа. Сформулированное выше положение проиллюстрировано на рис. 2.12. В много задачном режиме в один и тот же момент времени может выполняться только один процесс, тогда как остальные процессы вынуждены ожидать своей очереди. В многопроцессорной системе могут выполняться одновременно несколько процессов, причем каждый из них будет работать на от дельном процессоре.
· Надежность. При симметричной мультипроцессорной обработке отказ одного из процессоров не приведет к остановке машины, потому что все процессоры могут выполнять одни и те же функции. После такого сбоя система продолжит свою работу, хотя производительность ее несколько снизится.
· Наращивание . Добавляя в систему дополнительные процессоры, пользователь может повысить ее производительность.
· Масштабируемость. Производители могут предлагать свои продукты в различных, различающихся ценой и производительностью, конфигурациях, предназначенных для работы с разным количеством процессоров.
Важно отметить, что перечисленные выше преимущества являются скорее потенциальными, чем гарантированными. Чтобы надлежащим образом реализовать потенциал, заключенный в многопроцессорных вычислительных системах, операционная система должна предоставлять адекватный набор инструментов и возможностей
Рис. 2.12. Многозадачность и многопроцессорность
Часто можно встретить совместное обсуждение многопоточности и многопроцессорности, однако эти два понятия являются независимыми. Многопоточность - полезная концепция для структурирования процессов приложений и ядра даже на машине с одним процессором. С другой стороны, многопроцессорная система может обладать преимуществами по сравнению с однопроцессорной, даже если процессы не разделены на несколько потоков, потому что в такой системе можно запустить несколько процессов одновременно. Однако обе эти возможности хорошо согласуются между собой, а их совместное использование может дать заметный эффект.
Заманчивой особенностью многопроцессорных систем является то, что наличие нескольких процессоров прозрачно для пользователя -за распределение потоков между процессорами и за синхронизацию разных процессов отвечает операционная система. В этой книге рассматриваются механизмы планирования и синхронизации, которые используются, чтобы все процессы и процессоры были видны пользователю в виде единой системы. Другая задача более высокого уровня - представление в виде единой системы кластера из нескольких отдельных компьютеров. В этом случае мы имеем дело с набором компьютеров, каждый из которых обладает своей собственной основной и вторичной памятью и своими модулями ввода-вывода. Распределенная операционная система создает видимость единого пространства основной и вторичной памяти, а также единой файловой системы. Хотя популярность кластеров неуклонно возрастает и на рынке появляется все больше кластерных продуктов, современные распределенные операционные системы все еще отстают в развитии от одно- и многопроцессорных систем. С подобными системами вы познакомитесь в шестой части книги.
Одним из последних новшеств в устройстве операционных систем стало использование объектно-ориентированных технологий. Объектно-ориентированный дизайн помогает навести порядок в процессе добавления к основному небольшому ядру дополнительных модулей. На уровне операционной системы объектно-ориентированная структура позволяет программистам настраивать операционную систему, не нарушая ее целостности. Кроме того, этот подход облегчает разработку распределенных инструментов и полноценных распределенных операционных систем.
2.2 Разработка концептуальной модели информационной системы.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов их физического хранения. Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели должна происходить структуризация данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности
обработки. Проектирование концептуальной модели основано на анализе задач, стоящих перед рекламным агентством. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Чтобы построить необходимую нам модель, мы привели все имеющиеся данные к третьей нормальной форме, в результате чего получили следующие сущности:
· Виды блюд.
· Персонал.
· Должности.
· Заказы.
Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:
Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;
Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;
Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;
Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;
Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».
Рис. 2. Концептуальная модель данных
2.3 Разработка логической модели информационной системы
Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.
Схема 1 - Многоуровневое представление данных БД под
управлением СУБД
Различают концептуальный, внутренний и внешний уровни представления этих баз данных, которым соответствуют модели аналогичного назначения.
Концептуальный уровень соответствует логическому аспекту представления данных предметной области в интегрированном виде. Концептуальная модель состоит из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД к логической структуре базы данных.
Внутренний уровень отображает требуемую организацию данных в среде хранения и соответствует физическому аспекту представления данных. Внутренняя модель состоит из отдельных экземпляров записей, физически хранимых во внешних носителях.
Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД, доступных в приложении, а так же заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск).
Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.
Схема 2 - Этапы процесса проектирования базы данных
Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности.
Информационно-логическая (инфологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:
Фамилия Оклад
В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.
При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию.
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определённый набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма. Отношение называется нормализованным или приведённым к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.
Рисунок 1 - Графическое изображение функциональной зависимости реквизитов
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести “расщепление” исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
Целью работы является создание базы данных, обеспечивающей:
быстрый ввод новых данных;
хранения и поиск уже введённых данных;
печать необходимого количества персональных отчётов.
Данными являются:
Фамилия, имя, отчество;
Дата рождения;
Занимаемая должность;
Должностной оклад;
Количество фактических дней отработанных за месяц.
Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.
Для этого будем пользоваться средствами Database Desktop
В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:
Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.
CASE-средства проектирования информационных систем
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.
