1. Информационные системы в образовании
1.1. Определение информации и её виды.
Информация (от лат. informatio — осведомление, разъяснение, изложение) — в широком смысле абстрактное понятие, имеющее множество значений, в зависимости от контекста. В узком смысле этого слова — сведения (сообщения, данные) независимо от формы их представления. В настоящее время не существует единого определения термина информация. С точки зрения различных областей знания, данное понятие описывается своим специфическим набором признаков. Информация — совокупность данных, зафиксированных на материальном носителе, сохранённых и распространённых во времени и пространстве.
В то же время никак нельзя называть произведения искусства информацией. Эстетическое, культурологическое понимание термина информация в корне отличается от понимания информации в кибернетике, физике, биологии и т. д.
Органами чувств (приемниками информации) мы принимаем информацию об окружающем мире, в том числе и информацию о произведениях искусства. Но произведения искусства в связи с этим не становятся чистой информацией. Это мы при помощи органов чувств видя произведения искусства воспринимаем информацию о произведениях искусства.
Основные виды информации по ее форме представления, способам ее кодирования и хранения, что имеет наибольшее значение для информатики, это:
графическая или изобразительная — первый вид, для которого был реализован способ хранения информации об окружающем мире в виде наскальных рисунков, а позднее в виде картин, фотографий, схем, чертежей на бумаге, холсте, мраморе и др. материалах, изображающих картины реального мира;
звуковая — мир вокруг нас полон звуков и задача их хранения и тиражирования была решена с изобретением звукозаписывающих устройств в 1877 г. ее разновидностью является музыкальная информация — для этого вида был изобретен способ кодирования с использованием специальных символов, что делает возможным хранение ее аналогично графической информации;
текстовая — способ кодирования речи человека специальными символами — буквами, причем разные народы имеют разные языки и используют различные наборы букв для отображения речи; особенно большое значение этот способ приобрел после изобретения бумаги и книгопечатания;
числовая — количественная мера объектов и их свойств в окружающем мире; особенно большое значение приобрела с развитием торговли, экономики и денежного обмена; аналогично текстовой информации для ее отображения используется метод кодирования специальными символами — цифрами, причем системы кодирования (счисления) могут быть разными;
видеоинформация — способ сохранения «живых» картин окружающего мира, появившийся с изобретением кино.
1.2. Критерии качества и уровни информации.
Показатели качества информации
Возможность и эффективность использования информации для управления обусловливается такими ее потребительскими показателями качества, как
Репрезентативность — правильность, качественная адекватность отражения заданных свойств объекта.
Достоверность информации — соответствие информации объективной реальности окружающего мира.
Содержательность информации — это ее удельная семантическая емкость, равная отношению количества семантической информации в сообщении к объему Данных, его отображающих.
Достаточность (полнота) экономической информации означает, что она содержит минимальный, но достаточный для принятия правильного управленческого решения набор экономических показателей.
Объективность и субъективность информации является понятием относительным, так как методы субъективны. Более объективной принято считать информацию, в которую методы вносят меньший субъективный элемент (фотоснимок и рисунок).
Доступность информации для восприятия при принятии управленческого решения обеспечивается выполнением соответствующих процедур ее получения и преобразования.
Актуальность информации — это свойство информации сохранять свою полезность (ценность) для управления во времени.
Своевременность — это свойство информации, обеспечивающее возможность ее использования в заданный момент времени.
1.3. Определение ИС, БД, СУБД.
Термин информационная система (ИС) используется как в широком, так и в узком смысле.
В широком смысле информационная система есть совокупность технического, программного и организационного обеспечения, а также персонала, предназначенная для того, чтобы своевременно обеспечивать надлежащих людей надлежащей информацией.
Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).
Систе́ма управле́ния ба́зами да́нных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных
1.4. История развития ИС.
Развитие информационных систем
Развитие можно рассматривать:
1. С позиций развития самой техники, появления новой технической базы, порождающей новые информационные потребности.
2. С точки зрения совершенствования самих автоматизированных информационных систем (АИС).
Первый аспект предполагает два этапа: один — до появления ЭВМ, связанный с именами изобретателей первых вычислительных устройств, таких как Б. Паскаль, П.Л. Чебышев, Ч. Беббидж и др.; второй — с развитием ЭВМ.
Развитие ЭВМ
• Первое поколение ЭВМ (1950-е гг.) было построено на базе электронных ламп и представлено моделями: ЭНИАК, "МЭСМ”, "БЭСМ-1”, "М-20”, "Урал-1”, "Минск-1”. Все эти машины имели большие размеры, потребляли большое количество электроэнергии, имели малое быстродействие, малый объем памяти и невысокую надежность. В экономических расчетах они не использовались.
• Второе поколение ЭВМ (1960-е гг.) было на основе полупроводников и транзисторов: "БЭСМ-6”, "Урал-14”, "Минск-32”. Использование транзисторных элементов в качестве элементной базы позволило сократить потребление электроэнергии, уменьшить размеры отдельных элементов ЭВМ и всей машины, вырос объем памяти, появились первые дисплеи и др. Эти ЭВМ уже использовались для решения экономических задач.
• Третье поколение ЭВМ (1970-е гг.) было на малых интегральных схемах. Его представители — IBM 360 (США), ряд ЭВМ единой системы (ЕС ЭВМ), машины семейства малых с СМ I по СМ IV. С помощью интегральных схем удалось уменьшить размеры ЭВМ, повысить их надежность и быстродействие.
• Четвертое поколение ЭВМ (1980-е гг.) было на больших интегральных схемах (БИС) и было представлено IBM 370 (США), ЕС-1045, ЕС-1065 и пр. Они представляли собой ряд программно-совместимых машин на единой элементной базе, единой конструкторско-технической основе, с единой структурой, единой системой программного обеспечения, единым унифицированным набором универсальных устройств. Широкое распространение получили персональные (ПЭВМ), которые начали появляться с 1976 г. в США (An Apple). Они не требовали специальных помещений, установки систем программирования, использовали языки высокого уровня и общались с пользователем в диалоговом режиме.
Поколения информационных систем
• Первое поколение АИС (1960-1970 гг.) строилось на базе вычислительных центров по принципу "одно предприятие — один центр обработки”.
• Второе поколение АИС (1970-1980 гг.) характеризуется переходом к децентрализации ИС. Информационные технологии проникают в отделы, службы предприятия. Появились пакеты и децентрализованные базы данных, стали внедряться двух, трехуровневые модели организации систем обработки данных.
• Третье поколение АИС (1980-нач.1990 гг.): характерен массовый переход к распределенной сетевой обработке на базе персональных компьютеров с объединением разрозненных рабочих мест в единую ИС.
• Четвертое поколение АИС характеризуется сочетанием централизованной обработки на верхнем уровне с распределенной обработкой на нижнем. Наблюдается тенденция к возврату на крупных и средних предприятиях к использованию в ИС мощных ЭВМ в качестве центрального узла системы и дешевых сетевых терминалов (рабочих станций).
1.5. Классификация ИС.
Общепринятой классификации ИС до сих пор не существует, поэтому их можно классифицировать по разным признаками, что вызвало существование нескольких различных классификаций ИС
Согласно общепринятой классификации ИС - информационные системы - подразделяются:
• по масштабам применения - настольные и офисные
• по признаку структурированности задач - структурированные (формализуемые), не структурируемые (не формализуемые), частично структурируемые. Частично-структурированные делятся на: ИС репортинга и ИС разработки альтернативных решений (модельные, экспертные). Экспертные в свою очередь делятся на:
o централизованные, децентрализованные и коллективного использования
o с интеграцией по уровням управления, по уровням планирования и т.д.
• по функциональному признаку – производственные, маркетинговые (анализа рынка, рекламные, снабженческие и т.п.), финансовые (бухгалтерские, статистические, и т.п.), кадровые;
• по квалификации персонала и уровням управления – стратегические (топ-менеджеров), функциональные (менеджеров среднего звена) и оперативные (специалистов)
• по характеру обработки информации: системы обработки данных, системы управления, система поддержки принятия решений
• по оперативности обработки данных – пакетной обработки и оперативные
• по степени автоматизации - ручные, автоматические, автоматизированные
• по характеру использования информации - на информационно-поисковые, информационно-справочные, информационно-решающие, управляющие, советующие и т.п.;
• по степени централизации обработки информации — на централизованные, децентрализованные, информационные системы коллективного использования
• по характеру использования вычислительных ресурсов – на локальные и распределенные;
• по сфере деятельности - на государственные, территориальные (региональные), отраслевые, объединений, предприятий или учреждений, технологических процессов
• по классу реализуемых технологических операций - на системы с текстовыми редакторами, системы с табличными редакторами, СУБД, СУБЗ, системы с графикой, мультимедиа, гипертекстом
• по месту в процессе управления предприятия – на АРМ специалиста, ИС руководителя, ИС внешнего контролера, интегрированные системы, объединяющие в себе часть или все из этих функций
• по концепции построения – файловые, автоматизированные банки данных, банки знаний, ХД
• по режиму работы - на пакетные, диалоговые и смешанные
1.6. Компоненты ИС.
Компоненты информационной системы логически взаимосвязаны и зависят от ее назначения. Можно выделить несколько основных этапов движения информации:
• Получение данных, ввод в информационную систему.
• Обработка информации и дальнейшее распределение между пользователями.
• Накопление информации в базе данных, их резервное копирование.
• Анализ данных и их дальнейшая обработка.
• Принятие решений и формирование выходных документов.
Оптимальным считается тот вариант, при котором все компоненты информационной системы не только автоматизированы, но и дают реальный положительный результат в финансовой и хозяйственной деятельности организации.
1.7. Классификация БД.
Классификация баз данных
По типу хранимой информации БД делятся на
документальные,
фактографические и
лексикографические.
Среди документальных баз различают библиографические, реферативные и полнотекстовые.
К лексикографическим базам данных относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т. п.).
В системах фактографического типа в БД хранится информация об интересующих пользователя объектах предметной области в виде «фактов» (например, биографические данные о сотрудниках, данные о выпуске продукции производителями и т.п.); в ответ на запрос пользователя выдается требуемая информация об интересующем его объекте (объектах) или сообщение о том, что искомая информация отсутствует в БД.
По характеру организации хранения данных и обращения к ним различают
• локальные (персональные),
• общие (интегрированные, централизованные) и
• распределенные базы данных
По характеру организации данных БД могут быть разделены на
• неструктурированные,
• частично структурированные и
• структурированные.
Этот классификационный признак относится к информации, представленной в символьном виде. К неструктурированным БД могут быть отнесены базы, организованные в виде семантических сетей. Частично структурированными можно считать базы данных в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры БД. Только после этого базы данных такого типа могут быть заполнены данными.
Структурированные БД, в свою очередь, по типу используемой модели делятся на
• иерархические,
• сетевые,
• реляционные,
• смешанные и
• мультимодельные.
1.8. Архитектура БД.
Поскольку есть разные производители, и разные СУБД, существует разнообразные архитектуры.
1. Однобазовая архитектура – применяется в больших СУБД (Oracle и т.д.). преимущество такой БД – управление и контролирование БД происходит с одного сервера. Недостаток в том, что с течением времени, БД становится все больше и больше. Усложняются проблемы с резервным копированием и т.д.
2. Многобазовая архитектура – основное преимущество такой архитектуры в том, что упрощается проектирование. Для каждого приложения можно фактически создать свою базу данных. СУБД как программное обеспечение может управлять большим набором баз данных – InterBase, SQL-server – десятки тысяч СУБД могут поддерживаться одним сервером, а баз как файлов м.б. много – главное, чтобы сервер их видел. Недостатком таких СУБД является то, что при записи данных организаций в разные БД, считать данные из них представляет проблему.
3. Каталоговая архитектура – Desktop’овские СУБД. Базой данных является отдельный каталог: таблицы – отдельный файл, индекс – отдельный файл. Все расположено в отдельном каталоге, которых может быть много. Есть интересные решения в MS Access в одном файле таблицы, индексы, запросы находятся в одном файле. Есть свои плюсы и минусы. Трудно настраивать ПО постороннему – он должен сидеть в этой БД. Не каждая организация даст копию своей базы данных.
Такие однобазовые архитектуры, как в Oracle, позволяют создавать БД, хранящихся в нескольких физических файлах. Для того, чтобы назвать базой данных нечто, состоящее из нескольких файлов, вводят понятие табличного пространства, которое может покрывать несколько файлов. Сейчас, средние СУБД (SQL-сервер, например) начинают поддерживать такого рода табличные пространства!
1.9. Модель данных и ее виды.
Ядром любой базы данных является модель данных. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных - это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое по структуре дерево (граф).
К основным понятиям иерархической структуры относятся уровень, узел и связь. Узел - это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину, не подчиненную никакой другой вершине и находящуюся на самом верхнем - первом уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один иерархический путь от корневой записи.
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Реляционная модель данных объекты и связи между ними представляет в виде таблиц, при этом связи тоже рассматриваются как объекты. Все строки, составляющие таблицу в реляционной базе данных, должны иметь первичный ключ. Все современные средства СУБД поддерживают реляционную модель данных.
Эта модель характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
1. Каждый элемент таблицы соответствует одному элементу данных.
2. Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип и длину.
3. Каждый столбец имеет уникальное имя.
4. Одинаковые строки в таблице отсутствуют;
5. Порядок следования строк и столбцов может быть произвольным.
1.10. Иерархическая модель данных.
Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами (в программировании применительно к структуре данных дерево устоялось название братья).
Первые системы управления базами данных использовали иерархическую модель данных.
Пример: Например, если иерархическая база данных содержала информацию о покупателях и их заказах, то будет существовать объект «покупатель» (родитель) и объект «заказ» (дочерний). Объект «покупатель» будет иметь указатели от каждого заказчика к физическому расположению заказов покупателя в объект «заказ».
В этой модели запрос, направленный вниз по иерархии, прост (например, какие заказы принадлежат этому покупателю); однако запрос, направленный вверх по иерархии, более сложен (например, какой покупатель поместил этот заказ). Также, трудно представить не-иерархические данные при использовании этой модели.
Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.
1.11. Сетевая модель данных.
Сетевая модель данных — логическая модель данных, являющаяся расширением иерархического подхода, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в сетевых базах данных.
Разница между иерархической моделью данных и сетевой состоит в том, что в иерархических структурах запись-потомок должна иметь в точности одного предка, а в сетевой структуре данных у потомка может иметься любое число предков.
Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:
каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;
каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.
1.12. Реляционная модель данных.
Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.
На реляционной модели данных строятся реляционные базы данных.
Реляционная модель данных включает следующие компоненты:
Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.
Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).
Кроме того, в состав реляционной модели данных включают теорию нормализации.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».
Для лучшего понимания РМД следует отметить три важных обстоятельства:
модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
1.13. Свойства реляционной таблицы.
Главное достоинство таблицы реляционной базы данных – ее понятность. Мы имеем дело с информацией, представленной в табличной форме практически каждый день, и уже настолько привыкли к таблицам, что нет необходимости никому объяснять, как ими пользоваться.
Таблица реляционной базы данных обычно представляет собой двумерный массив и имеет ряд свойств:
в реляционной таблице нет одинаковых строк;
каждый из элементов таблицы реляционной базы данных – это один элемент данных;
каждый столбец несет уникальное имя;
все элементы столбца имеют одинаковый тип, то есть все ячейки столбца реляционной таблицы являются однородными;
столбцы реляционной таблицы размещаются строго в определенном порядке, который задают при создании таблицы;
в таблице реляционной базы данных может не быть строк, но в ней обязательно должен быть хотя бы один столбец;
на пересечении строки и столбца может находится только одно значение, которое не состоит из группы значений.
Поля реляционной базы данных
Каждое поле реляционной базы данных представляет собой наименьший поименованный элемент информации. Все поля в таблице реляционной базы данных являются однородными, каждое поле имеет уникальное имя. Они именуются пользователями с ограничениями, которые определяются произвольно.
Поля реляционной базы данных имеют следующие свойства:
название поля (имя);
тип поля, который определяет тип данных, хранящийся в поле;
размер поля – это длина в символах;
формат поля, т.е. способ форматирования данных;
маска ввода – она определяет форму, в которой вводятся данные в поле;
подпись, или другими словами заголовок столбца таблицы;
значение по умолчанию – это значение, которое вводится автоматически;
условие на значение (ограничение, предназначенное для проверки правильности ввода данных);
сообщение об ошибке – это сообщение, которое выдается при попытке ввода ошибочных данных;
обязательное поле (свойство, которое определяет обязательность заполнения поля);
пустые строки – это свойство, которое разрешает ввод пустых строковых данных;
индексированное поле – поле для ускорения операций поиска данных.
1.14. Типы связей.
Для графического отображения инфологической (концептуальной) модели разработан специальный язык ER-диаграмм (Entity-Relationship, т. е. сущность-связь). Между двумя сущностями можно установить следующие типы связей. Приняты следующие обозначения:
-ассотассоциация (связь, содержащая атрибуты) отображается ромбом;
- связи отображаются ребрами (линиями) с указанием (или без) типа связи;
- атрибуты отображаются овалами.
а) связь «один-к-одному»
В произвольный момент времени каждому экземпляру одной сущности будет соответствовать один экземпляр второй сущности (или отсутствовать экземпляр второй сущности). Например, каждый гражданин (сущность А), достигший возраста 16 лет, имеет один паспорт (сущность Б) (рисунок 1);
Рисунок 1- Связь «один-к-одному»
б) связь «один-ко-многим»
В произвольный момент времени каждому экземпляру одной сущности будет соответствовать один или несколько экземпляров второй сущности (или отсутствовать экземпляр второй сущности). Например, каждый поставщик (сущность А) поставляет в магазин несколько наименований (сущность Б) товаров, или одно наименование товара, или не поставляет товаров;
в) связь «многие-к-одному»
Этот тип связи имеет больше теоретическое значение, нежели практическое, и является зеркальным отображением связи «один- ко-многим»;
г) связь «многие-ко-многим»
В произвольный момент времени нескольким экземплярам одной сущности будет соответствовать несколько экземпляров второй сущности (или отсутствовать экземпляр второй сущности). Например, продавцы-тезки (сущность А) обслуживают покупателей-тезок (сущность Б)
Тип связи «многие-ко-многим» носит избыточный характер, т. е. и первая, и вторая сущности имеют множественные повторяющиеся атрибуты. Для ликвидации повторений (не уникальности) используется процедура нормализации, которая будет рассмотрена ниже.
В теории баз данных рассматриваются также и редко встречающиеся типы связей;
д) циклические связи
Циклические связи отличаются от связи «многие-ко- многим» тем, что имеют несколько ассоциаций, в то время как связь «многие-ко-многим» имеет одну ассоциацию;
е) тренарные связи
Тренарные связи характеризуются тем, что одна сущность имеет ассоциации с двумя другими сущностями (рисунок 2).
Рисноук 2- Тренарные связи
1.15. СУБД в архитектуре клиент-сервер.
Одна из моделей взаимодействия компьютеров в сети получила название «клиент-сервер» (Рис. 1.). Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и распоряжается информационными ресурсами системы, клиент имеет возможность воспользоваться ими.
Сервер базы данных представляет собой мультипользовательскую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - поддержки протоколов блокирования ресурсов, обеспечение, предотвращение и/или устранения тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front - end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом. Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т. е. часть функций приложений будет реализована в программе-клиенте, другая - в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:
• функции ввода и отображения данных;
• прикладные функции, характерные для предметной области;
• фундаментальные функции хранения и управления ресурсами (базами данных);
• служебные функции.
Исходя из этого деления любое приложение может состоять из следующих компонентов:
• компонент представления (функции 1-й группы);
• прикладной компонент (функции 2-й группы);
• компонент доступа к информационным ресурсам (функции 3-ей группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
• какие виды программного обеспечения в логических компонентах;
• какие механизмы программного обеспечения используются для реализации функций трех групп;
• как логические компоненты распределяются компьютерами в сети;
• какие механизмы используются для связи компонент между собой.
Исходя из этого, рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
1.16. Перспективы развития СУБД.
Анализ современных СУБД и реализованных на их основе приложений позволяет предположить следующие направления их развития:
поиск более современных моделей представления и типов данных в базах. Представляют интерес СУБД, поддерживающие несколько моделей или одну интегрированную модель и позволяющие удобно программировать вычисления, обрабатывать символьную и графическую информацию, работать со знаниями, аудио- и видеоинформацией, осуществлять доступ к распределенной информации и др. На пути к решению этой проблемы находится попытка поддержки во многих современных СУБД различных типов двоичных данных и типа гиперссылки.
разработка новых архитектур СУБД. Современные ИС требуют от СУБД возможности хранить и обрабатывать данные объемов петабайтов (1015байтов). В связи с этим говорят о необходимости организации нового уровня иерархии носителей – третичной памяти. Устройствами третичной памяти могут быть устройства в виде стоек магнитных дисков или лент с автоматически сменяемыми носителями. Примером может быть буферная система VSM (Virtual Storage Manager) корпорации Storage Tek. Эта система накапливает и сохраняет данные на жестких дисках в буфере данных, где они складируются в виде виртуальных томов на магнитных лентах (до 100 000 томов на каждом дисковом буфере). Максимальная скорость передачи данных пользователя – до 45 Мбайтов/с.
расширение областей применения БД. К новым областям применения можно отнести следующие два класса задач:
обработки сверхбольших объемов информации. Примером является проектируемая ИС наблюдения Земли EOS (Earth Observing System), основным элементом которой является база данных EOS DIS (EOS Data and Information System) – система данных и информации.
распределенной обработки информации в сети. Примерами задач данного типа являются задачи поиска и отбора информации в сети Internet, организации коллективного проектирования в территориально разнесенных организациях, обмена материальными, информационными, денежными и другими ресурсами с электронным оформлением.
улучшение сервиса конечных пользователей, администраторов и разработчиков.
Перспективные СУБД позволяют решать стоящие прикладные задачи с лучшим качеством. Для этого необходимо опираться на более совершенную элементную базу (увеличение производительности обработки запросов, повышение объема хранимых данных), иметь более совершенную программную организацию (распределенная обработка, безопасность хранимой информации), обладать гибкими и удобными интерфейсами для программистов, пользователей и администратора БД. Одним из новых требований в области ИТ является обеспечение безостановочной работы. Некоторые ИС работают непрерывно.
В современных условиях появляется потребность в обеспечении информационного обслуживания мобильного пользователя. Теперь нужно иметь возможности ведения БД как на центральной (стационарной) ВС, так и на портативном (переносном) компьютере. При этом необходимо иметь средства загрузки/выгрузки выбранных данных с центральной в портативную ЭВМ, а также средства обеспечения согласованности информации в обеих базах. Эти средства, например, СУБД Oracle Lite.
1.17. Этапы создания ИС.
Основные этапы создания информационной системы
Создание информационной системы начинается с момента первых переговоров Заказчика и потенциального Исполнителя и может никогда не закончиться, поскольку хорошие и полезные системы постоянно совершенствуются и развиваются.
Предварительный этап
На данном этапе необходимо осознать основные цели и задачи будущего проекта. Для этого ключевые представители Заказчика и Исполнителя организуют встречи, на которых обсуждают концепцию информационной системы, ключевые технические моменты, сроки и объемы выполняемых работ, а также стоимость и источники финансирования. Итогом предварительного этапа, помимо согласованных условий будущего договора, должен стать первый и самый фундаментальный проектный документ – устав проекта.
Сбор требований
К этому моменту все ключевые фигуры – участники проекта определены, и ничто не мешает начать собирать и утверждать требования к будущей информационной системе. Представители исполнителя общаются с будущими пользователями и администраторами системы, а также с их руководством. В ходе обследования не только систематизируются требования и пожелания к внедряемому решению, но и анализируется документация, которая должна стать источником исходных данных системы, или формирование которой должно быть в результате автоматизировано.
Проектирование
На этом этапе усилиями Исполнителя детально проектируются все сценарии, связанные с разработкой и внедрением информационной системы на территории Заказчика. Делается это в соответствии с условиями информационной среды (системного ландшафта) Заказчика и требованиями к интеграции создаваемой системы с уже имеющимися и эксплуатируемыми Заказчиком прочими программными продуктами.
Реализация
Этап реализации всех требований к информационной системе, изложенных в Техническом задании и Техническом проекте. В этот период Исполнитель разрабатывает все необходимые программные компоненты, создает структуры базы данных, производит установку, настройку и тестирование всех компонентов информационной системы на своей территории, имитирует сценарии интеграции и т.д. и т.п. Завершение этапа реализации подтверждается появлением таких проектных документов, как руководство по установке и настройке системы, программа и методика испытаний системы, а также шаблон базы данных и реестр всех выполненных программных разработок.
Подготовка информационной системы к эксплуатации
Все работы данного этапа уже проводятся на территории Заказчика и включают в себя установку и настройку всех компонентов системы в информационной среде Заказчика, проведение предварительного тестирования, разработку пользовательской документации, обучение пользователей, загрузку исходных данных, проведение испытаний системы в соответствии с программой и методикой испытаний и прочие подготовительные работы.
Опытно-промышленная эксплуатация
Последний этап в рамках разработки и первоначального внедрения информационной системы, задачей которого является успешное проведение опытной эксплуатации системы в течение определенного времени, а целью – подтвердить, что созданная информационная система – это ровно тот результат, который и ожидал Заказчик.
Сопровождение и развитие системы
Промышленная эксплуатация может выявить то, что некоторые требования к созданной информационной системе содержали неточности и требуют иной формулировки или дополнений, а сама система требует доработки. Не каждый Заказчик имеет в своем штате персонал, который способен самостоятельно внести в работу системы все, диктуемые реальной обстановкой изменения, поэтому заключает с Исполнителем отдельный договор на сопровождение информационной системы.
1.18. Начальный этап процесса создания ИС.
Предварительный этап
На данном этапе необходимо осознать основные цели и задачи будущего проекта. Для этого ключевые представители Заказчика и Исполнителя организуют встречи, на которых обсуждают концепцию информационной системы, ключевые технические моменты, сроки и объемы выполняемых работ, а также стоимость и источники финансирования. Итогом предварительного этапа, помимо согласованных условий будущего договора, должен стать первый и самый фундаментальный проектный документ – устав проекта.
Устав проекта определяет следующие принципиальные моменты, связанные с процессом разработки и внедрения информационной системы:
• Краткое описание проекта, цели и задачи создания информационной системы.
• Общее описание состава работ.
• Границы проекта: сроки, бюджет, перечень объектов автоматизации.
• Описание продукта: перечень поставляемого аппаратного и программного обеспечения, тип и количество лицензий и т.д.
• Организационная структура проекта: список и роли участников проектной группы со стороны Исполнителя и Заказчика, их ответственность и обязанности, система документооборота проекта.
• Основные этапы разработки и внедрения информационной системы, укрупненный план-график их реализации.
• Наиболее значимые риски невыполнения обязательств по проекту, а также способы минимизации рисков.
Другими словами, устав проекта – это именно устав, который разрабатывается руководителем проекта совместно с основными участниками проектной группы, утверждается руководством Исполнителя и Заказчика и не должен корректироваться в течение всего времени создания информационной системы.
Завершением предварительного этапа можно считать момент, когда подписан договор на услуги по разработке и внедрению информационной системы и утвержден устав проекта.
1.19. Формирование требований к ИС.
Сбор требований
К этому моменту все ключевые фигуры – участники проекта определены, и ничто не мешает начать собирать и утверждать требования к будущей информационной системе. Представители исполнителя общаются с будущими пользователями и администраторами системы, а также с их руководством. В ходе обследования не только систематизируются требования и пожелания к внедряемому решению, но и анализируется документация, которая должна стать источником исходных данных системы, или формирование которой должно быть в результате автоматизировано.
Результатом данного этапа должно стать появление технического задания на разработку и внедрение информационной системы. Техническое задание должно базироваться на условиях договора и требованиях, изложенных в уставе проекта и содержать следующие разделы (для России структура технического задания регламентируется ГОСТ 34.602 89):
• Назначение и цели создания системы.
• Описание объекта автоматизации и основных автоматизируемых бизнес-процессов.
• Требования к системе: требования к структуре; функциям (задачам), решаемым системой; требования к техническому и организационному обеспечению; требования к надежности, безопасности и т.д. и т.п.
• Состав и содержание работ по созданию информационной системы.
• Порядок контроля и приемки результатов работ.
• Требования к составу работ по подготовке объекта автоматизации для запуска информационной системы в эксплуатацию.
• Требования к составу проектной и пользовательской документации.
Завершение этапа сбора требований – это утверждение Заказчиком Технического задания. В некоторых случаях у Заказчика до начала работ по проекту уже существует техническое задание (входит в состав конкурсной документации). В этом случае результаты обследования и сбора требований фиксируются в частных технических заданиях, детализирующих и конкретизирующих общие требования к информационной системе, представленные в исходном техническом задании.
1.20. Проектирование ИС.
Проектирование
На этом этапе усилиями Исполнителя детально проектируются все сценарии, связанные с разработкой и внедрением информационной системы на территории Заказчика. Делается это в соответствии с условиями информационной среды (системного ландшафта) Заказчика и требованиями к интеграции создаваемой системы с уже имеющимися и эксплуатируемыми Заказчиком прочими программными продуктами. Результатом этапа проектирования должно стать оформление следующих разделов технического (концептуального) проекта:
• Архитектура информационной системы.
• Описание структур информационного хранилища (базы данных).
• Проектные решения, представленные детальным описанием сценариев автоматизации всех, затрагиваемых внедрением системы бизнес процессов.
• Сценарии интеграции разрабатываемой информационной системы с внешними программными продуктами.
• Источники исходных данных и варианты первоначального информационного наполнения системы.
• Концепция разграничения прав доступа к данным на основе ролей пользователей, определяющих, в том числе, их полномочия.
• Концепция обучения пользователей информационной системы.
1.21. Модели жизненного цикла ПО ИС.
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.
Каскадная, поэтапная, спиральная
1.22. Каскадная модель жизненного цикла ПО ИС.
Каскадная модель, в которой переход на следующий этап означает полное завершение работ на предыдущем этапе.
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ (или “водопад”). Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (рис. 1).
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. При этом этапы работ выполняются в логичной последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты. Этот подход хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно достаточно точно и полно сформулировать все требования и предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Его недостатки связаны с тем, что реальный процесс создания ПО ИС обычно не укладывается в такую жёсткую схему. Практически постоянно возникает потребность возвращаться к предыдущим этапам, уточнять или пересматривать принятые решения. В результате затягиваются сроки выполнения работы, пользователи могут вносить замечания лишь по завершению всех работ с системой. При этом модели автоматизируемого объекта могут устареть к моменту их утверждения.
1.23. Поэтапная модель жизненного цикла ПО ИС с промежуточным контролем.
В поэтапной модели с промежуточным контролем разработка ПО ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.
1.24. Спиральная модель жизненного цикла ПО ИС.
Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.
В этой модели особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.
1.25. Процессы жизненного цикла ПО ИС.
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО) [1,10,13]. ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [13]. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
• основные процессы ЖЦ ПО - процессы, в результате которых непосредственно вносится вклад в добавление стоимости создаваемого программного продукта.
• вспомогательные процессы, обеспечивающие поддержку выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО.
• организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.
1.26. Содержание основных процессов жизненного цикла ПО ИС.
Таблица 1.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)
Процесс
(исполнитель
процесса) Действия Вход Результат
Приобретение (заказчик)
• Инициирование
• Подготовка заявочных предложений
• Подготовка договора
• Контроль деятельности поставщика
• Приемка ИС • Решение о начале работ по внедрению ИС
• Результаты обследования деятельности заказчика
• Результаты анализа рынка ИС/ тендера
• План поставки/ разработки
• Комплексный тест ИС • Технико-экономическое обоснование внедрения ИС
• Техническое задание на ИС
• Договор на поставку/ разработку
• Акты приемки этапов работы
• Акт приемно-сдаточных испытаний
Поставка (разработчик ИС)
• Инициирование
• Ответ на заявочные предложения
• Подготовка договора
• Планирование исполнения
• Поставка ИС • Техническое задание на ИС
• Решение руководства об участии в разработке
• Результаты тендера
• Техническое задание на ИС
• План управления проектом
• Разработанная ИС и документация • Решение об участии в разработке
• Коммерческие предложения/ конкурсная заявка
• Договор на поставку/ разработку
• План управления проектом
• Реализация/ корректировка
• Акт приемно-сдаточных испытаний
Разработка (разработчик ИС)
• Подготовка
• Анализ требований к ИС
• Проектирование архитектуры ИС
• Разработка требований к ПО
• Проектирование архитектуры ПО
• Детальное проектирование ПО
• Кодирование и тестирование ПО
• Интеграция ПО и квалификационное тестирование ПО
• Интеграция ИС и квалификационное тестирование ИС • Техническое задание на ИС
• Техническое задание на ИС, модель ЖЦ
• Подсистемы ИС
• Спецификации требования к компонентам ПО
• Архитектура ПО
• Материалы детального проектирования ПО
• План интеграции ПО, тесты
• Архитектура ИС, ПО, документация на ИС, тесты • Используемая модель ЖЦ, стандарты разработки
• План работ
• Состав подсистем, компоненты оборудования
• Спецификации требования к компонентам ПО
• Состав компонентов ПО, интерфейсы с БД, план интеграции ПО
• Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам
• Тексты модулей ПО, акты автономного тестирования
• Оценка соответствия комплекса ПО требованиям ТЗ
• Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ
1.27. Стадии жизненного цикла ПО ИС.
В жизненном цикле АИС выделяют пять стадий [2].
1. Предпроектное обследование (планирование и анализ требований). На данной стадии проводится системный анализ существующей ИС, определяются требования к создаваемой ИС, оформляются технико-экономическое обоснование и техническое задание на разработку.
2. Проектирование. Осуществляется разработка состава автоматизируемых функций (функциональной архитектуры) и состава обеспечивающих подсистем (системной архитектуры) и оформление технического проекта ИС.
3. Разработка информационной системы подразумевает рабочее и физическое проектирование, программирование, разработку и настройку программ, наполнение базы данных, создание рабочей инструкции для персонала, оформление рабочего проекта.
4. Ввод информационной системы в эксплуатацию. На данном этапе проводится комплексная отладка подсистем ИС, тестирование, опытная эксплуатация, обучение персонала, поэтапное внедрение ИС в эксплуатацию по подразделениям экономического объекта и оформление акта о приемо-сдаточных испытаниях информационной системы.
5. Эксплуатация информационной системы: повседневная эксплуатация, сопровождение, модернизация, сбор рекламаций и статистики о функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации системы и ее выполнение.
Стадии 2 и 3 нередко объединятся в одну — так называемую стадию системного синтеза.
1.28. Этапы создания ИС на примере канонического проектирования.
Каноническое проектирование ИС. Стадии и этапы проектирования ИС.
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС, которая подразумевает полное завершение некоторого типа работ перед переходом к следующему этапу на котором выполняется другой тип работ. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
Каноническое проектирование ИС характеризуется следующими особенностями:
1. Отражает особенности ручной технологии проектирование;
2. Предполагает выполнение индивидуального (оригинального) проектирования;
3. Не предполагает использования средств интеграции;
4. Соответствует каскадной модели ЖЦ ИС.
На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС.
1.29. Содержание этапов создания ИС на примере канонического проектирования.
При каноническом подходе выделяются следующие этапы:
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
• обследование объекта и обоснование необходимости создания ИС;
• формирование требований пользователей к ИС;
• оформление отчета о выполненной работе и технического задания на разработку.
Стадия 2. Разработка концепции ИС.
• изучение объекта автоматизации;
• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
• оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
• разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
• разработка проектных решений по системе и ее частям;
• разработка документации на ИС и ее части;
• разработка и оформление документации на поставку комплектующих изделий;
• разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
• разработка рабочей документации на ИС и ее части;
• разработка и адаптация программ.
Стадия 7. Ввод в действие.
• подготовка объекта автоматизации;
• подготовка персонала;
• комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами);
• проведение опытной эксплуатации;
• проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
• выполнение работ в соответствии с гарантийными обязательствами;
• послегарантийное обслуживание.
1.30. Этапы проектирования БД.
При разработке БД можно выделить следующие этапы работы.
I этап. Постановка задачи.
На этом этапе формируется задание по созданию БД. В нем подробно описывается состав базы, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе данных (отбор, дополнение, изменение данных, печать или вывод отчета и т. д).
II этап. Анализ объекта.
На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.
III этап. Синтез модели.
На этом этапе по проведенному выше анализу необходимо выбрать определенную модель БД. Далее рассматриваются достоинства и недостатки каждой модели и сопоставляются с требованиями и задачами создаваемой БД. После такого анализа выбирают ту модель, которая сможет максимально обеспечить реализацию поставленной задачи. После выбора модели необходимо нарисовать ее схему с указанием связей между таблицами или узлами.
IV этап. Выбор способов представления информации и программного инструментария.
После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления информации.
В большинстве СУБД данные можно хранить в двух видах:
с использованием форм;
без использования форм.
Форма – это созданный пользователем графический интерфейс для ввода данных в базу.
V этап. Синтез компьютерной модели объекта.
В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.
Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.
Стадия 2. Создание исходной таблицы или таблиц.
Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.
При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами:
1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.
Стадия 3. Создание экранных форм.
Первоначально необходимо указать таблицу, на базе которой будет создаваться форма. Ее можно создавать при помощи мастера форм, указав, какой вид она должна иметь, или самостоятельно. При создании формы можно указывать не все поля, которые содержит таблица, а только некоторые из них. Имя формы может совпадать с именем таблицы, на базе которой она создана. На основе одной таблицы можно создать несколько форм, которые могут отличаться видом или количеством используемых из данной таблицы полей. После создания форму необходимо сохранить. Созданную форму можно редактировать, изменяя местоположение, размеры и формат полей.
Стадия 4. Заполнение БД.
Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.
VI этап. Работа с созданной базой данных.
Работа с БД включает в себя следующие действия:
поиск необходимых сведений;
сортировка данных;
отбор данных;
вывод на печать;
изменение и дополнение данных.
1.31. Этапы инфологического проектирования БД.
Приступая к следующему этапу проектирования, необходимо помнить, что решаемая задача составляет только часть предметной области. Если мы хотим построить гибкую легко наращиваемую систему, то в первую очередь следует выделить наименьший неделимый, в пределах нашей задачи, объект описания (минимальный объект описания). Невозможно управлять городским пассажирским потоком, не отслеживая передвижение каждого отдельного человека. Сложно, или скорее невозможно, составить школьный журнал, если вся информация об ученике будет собрана в единственный объект.
Однако, как жизнь невозможна без законов, так и моделирование не существует без правил. На данном этапе проектирования предметная область представляется моделью, выполненной без ориентации на используемые в дальнейшем программные и технические средства - инфологической моделью.
Какими же средствами воспользоваться для составления инфологического описания предметной области? На этот вопрос нет однозначного ответа. Существует несколько методик, и соответственно применяются разные инструментальные средства. Составляемая модель должна быть проста, наглядна, содержать все сведения для дальнейших этапов проектирования, легко преобразовываться в модели баз данных для распространенных СУБД. Исходя из этих требований, в описываемой методике проектирования используется модель, названная «сущность-связь» (или «объекты-связи»).
Модель «сущность-связь» позволяет представлять объекты предметной области и отношения между ними, т.е. позволяет описывать структуру предметной области. Она определяется в терминах: сущность, атрибут, связь.
Сущность - представление (абстракция) реально существующего объекта, процесса или явления. Наименование сущности должно быть уникально во всей модели.
Тип сущности - определяет набор однородных объектов.
Экземпляр сущности - конкретный объект из этого набора.
Например: сущность «Ученик» определяет всю информацию об учениках вообще. Конкретный ученик Ваня Иванов является экземпляром сущности «Ученик», а совокупность всех учеников составляет тип сущности.
Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.
Экземпляр атрибута - конкретное значение свойства.
Например: сущность «Ученик» определяется атрибутами: «Фамилия ученика», «Класс» и т.п. То есть для каждого конкретного ученика (экземпляра сущности) мы должны определить экземпляры атрибутов (их конкретные значения). Продолжим с нашим примером: экземпляр сущности «Ученик» Ваня Иванов имеет экземпляр атрибута «Фамилия ученика» - «Иванов» и экземпляр атрибута «Класс» - «8А».
Идентифицирующий атрибут (идентифицирующая совокупность атрибутов, ИСА) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.
Связь позволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.
Теперь попытаемся составить полную инфологическую модель задачи «Школьный журнал». Для этого перечислим те правила, которым должна удовлетворять модель «сущность-связь»:
1. Модель должна давать полное представление о предметной области.
2. Должны быть перечислены все необходимые для реализации задачи сущности и их атрибуты соответственно.
3. Имена сущностей должны быть уникальны.
4. Имена атрибутов в пределах одной сущности должны быть уникальны.
5. Мы должны гарантировать однозначную трактовку модели.
6. В каждой сущности должна быть выделена идентифицирующая совокупность атрибутов.
7. Модель должна быть гибкой, т.е. при возникновении новых задач расширяться без существенных изменений существующей модели.
Представленная на рисунке ниже модель позволяет решить основные задачи школьного журнала. Она является одним из многих возможных вариантов решения. Ее составление шло для вымышленной школы. Более того, представленная модель не в полной мере отвечает требованию гибкости. Мы не можем ученику по одному предмету выставить сразу несколько оценок. Обойти такое ограничение можно введением абстрактного атрибута «№ оценки». Этот атрибут не несет смысловой нагрузки, кроме количественной, однако, определив его как идентифицирующий, мы избежим трудностей при выставлении оценок.
• Сущность «Ученик» содержит все личные данные учащегося.
• Сущность «Кабинет» содержит информацию о техническом уровне, состоянии, количестве мест.
• Сущность «Преподаватель» содержит информацию об уровне подготовки, заслугах, разряде и личных данных учителя.
• Сущность «Оценка» содержит информацию об оценке, полученной учеником по определенному предмету, выставленную преподавателем в конкретный день.
1.32. Три нормальные формы, предложенные Коддом.
первая нормальная форма.
Для обсуждения первой нормальной формы необходимо дать два определения:
Простой атрибут - атрибут, значения которого атомарны (неделимы).
Сложный атрибут - получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах. (его также называют вектор или агрегат данных).
Теперь можно дать
Определение первой нормальной формы:
отношение находится в 1NF если значения всех его атрибутов атомарны.
Рассмотрим пример, заимствованный из уже упоминавшейся статьи Е.Ф.Кодда:
В базе данных отдела кадров предприятия необходимо хранить сведения о служащих, которые можно попытаться представить в отношении
СЛУЖАЩИЙ(НОМЕР_СЛУЖАЩЕГО, ИМЯ, ДАТА_РОЖДЕНИЯ, ИСТОРИЯ_РАБОТЫ, ДЕТИ).
Из внимательного рассмотрения этого отношения следует, что атрибуты "история_работы" и "дети" являются сложными, более того, атрибут "история_работы" включает еще один сложный атрибут "история_зарплаты".
Данные агрегаты выглядят следующим образом:
•ИСТОРИЯ_РАБОТЫ (ДАТА_ПРИЕМА, НАЗВАНИЕ, ИСТОРИЯ_ЗАРПЛАТЫ),
•ИСТОРИЯ_ЗАРПЛАТЫ (ДАТА_НАЗНАЧЕНИЯ, ЗАРПЛАТА),
•ДЕТИ (ИМЯ_РЕБЕНКА, ГОД_РОЖДЕНИЯ).
Их связь представлена на рис. 4.3.
вторая нормальная форма.
Очень часто первичный ключ отношения включает несколько атрибутов (в таком случае его называют составным) - см., например, отношение ДЕТИ, показанное на рис. 4.4. При этом вводится понятие полной функциональной зависимости.
Определение:
неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.
Пример:
Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР, ЦЕНА).
Поставщик может поставлять различные товары, а один и тот же товар может поставляться разными поставщиками. Тогда ключ отношения - "N_поставщика + товар". Пусть все поставщики поставляют товар по одной и той же цене. Тогда имеем следующие функциональные зависимости:
• N_поставщика, товар ->цена
• товар ->цена
Неполная функциональная зависимость атрибута "цена" от ключа приводит к следующей аномалии: при изменении цены товара необходим полный просмотр отношения для того, чтобы изменить все записи о его поставщиках. Данная аномалия является следствием того факта, что в одной структуре данных объединены два семантических факта. Следующее разложение дает отношения во 2НФ:
• ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР)
• ЦЕНА_ТОВАРА (ТОВАР, ЦЕНА)
Таким образом, можно дать
Определение второй нормальной формы:
Отношение находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.
нормальная форма Бойса-Кодда.
Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.
Определение нормальной формы Бойса-Кодда:
Отношение находится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.
Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.
1.33. Нормальная форма Бойсса-Кодда, 4 и 5 нормальные формы.
нормальная форма Бойса-Кодда.
Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.
Определение нормальной формы Бойса-Кодда:
Отношение находится в BCNF, если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.
Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.
Многозначные зависимости и четвертая нормальная форма (4NF).
Четвертая нормальная форма касается отношений, в которых имеются повторяющиеся наборы данных. Декомпозиция, основанная на функциональных зависимостях, не приводит к исключению такой избыточности. В этом случае используют декомпозицию, основанную на многозначных зависимостях.
Многозначная зависимость является обобщением функциональной зависимости и рассматривает соответствия между множествами значений атрибутов.
В качестве примера рассмотрим отношение ПРЕПОДАВАТЕЛЬ (ИМЯ, КУРС, УЧЕБНОЕ_ПОСОБИЕ), хранящее сведения о курсах, читаемых преодавателем, и написанных им учебниках. Пусть профессор N читает курсы "Теория упругости" и "Теория колебаний" и имеет соответствующие учебные пособия, а профессор K читает курс "Теория удара" и является автором учебников "Теория удара" и "Теоретическая механика". Тогда наше отношение будет иметь вид:
----------------------------------------------------
| ИМЯ | КУРС | УЧЕБНОЕ_ПОСОБИЕ |
----------------------------------------------------
| N | Теория упругости | Теория упругости |
| N | Теория колебаний | Теория упругости |
| N | Теория упругости | Теория колебаний |
| N | Теория колебаний | Теория колебаний |
| K | Теория удара | Теория удара |
| K | Теория удара | Теоретическая механика |
----------------------------------------------------
добавляем:
----------------------------------------------------
| K | Теория упругости | Теория удара |
| K | Теория упругости | Теоретическая механика |
----------------------------------------------------
Это отношение имеет значительную избыточность и его использование приводит к возникновению аномалии обновления. Например, добавление информации о том, что профессор K будет также читать лекции по курсу "Теория упругости" приводит к необходимости добавить два кортежа (по одному для каждого написанного им учебника) вместо одного. Тем не менее, отношение ПРЕПОДАВАТЕЛЬ находится в NFBC (ключевой атрибут - ИМЯ).
Заметим, что указанные аномалии исчезают при замене отношения ПРЕПОДАВАТЕЛЬ его проекциями:
--------------------------- -------------------------------
| ИМЯ | КУРС | | ИМЯ | УЧЕБНОЕ_ПОСОБИЕ |
--------------------------- -------------------------------
| N | Теория упругости | | N |Теория упругости |
| N | Теория колебаний | | N |Теория колебаний |
| K | Теория удара | | K |Теоретическая механика |
| K | Теория упругости | | K |Теория удара |
--------------------------- -------------------------------
Аномалия обновления возникает в данном случае потому, что в отношении ПРЕПОДАВАТЕЛЬ имеются:
1. зависимость множества значений атрибута КУРС от множества значений атрибута ИМЯ
2. зависимость множества значений атрибута УЧЕБНОЕ_ПОСОБИЕ от множества значений атрибута ИМЯ.
Такие зависимости и называются многозначными и обозначаются как
ИМЯ ->> КУРС ИМЯ ->> УЧЕБНОЕ_ПОСОБИЕ
Нетрудно показать, что многозначные зависимости всегда образуют связанные пары, поэтому их часто обозначают
ИМЯ ->> КУРС | УЧЕБНОЕ_ПОСОБИЕ
Очевидно, что каждая функциональная зависимость является многозначной, но не каждая многозначная зависимость является функциональной.
Определение четвертой нормальной формы:
Отношение находится в 4NF если оно находится в BCNF и в нем отстутсвуют многозначные зависимости, не являющиеся функциональными зависимостями.
Зависимости по соединению и пятая нормальная форма (5NF).
До сих пор мы предполагали, что единственной операцией, необходимой для устранения избыточности в отношении, была декомпозиция его на две проекции. Однако, существуют отношения, для которых нельзя выполнить декомпозицию без потерь на две проекции, но которые можно подвергнуть декомпозиции без потерь на три (или более) проекций. Этот факт получил название зависимости по соединению, а такие отношения называют 3-декомпозируемые отношения (ясно, что любое отношение можно назвать "n-декомпозируемым", где n >= 2).
Детально этот вопрос здесь мы не обсуждаем (полное изложение см. в книге К.Дейта), заметим лишь, что зависимость по соединению является обощением многозначной зависимости. Отношения, в которых имеются зависимости по соединению, не являющиеся одновременно ни многозначными, ни функциональными, также характеризуются аномалиями обновления. Поэтому, вводится понятие пятой нормальной формы.
Определение пятой нормальной формы:
Отношение находится в 5НФ тогда и только тогда, когда любая зависимость по соединению в нем определяется только его возможными ключами.
Другими словами, каждая проекция такого отношения содержит не менее одного возможного ключа и не менее одного неключевого атрибута.
1.34. Минимизация числа сущностей.
Правила минимизации сущностей:
1. Если все атрибуты рассматриваемой сущности полностью присутствуют в какой-либо другой, то рассматриваемая сущность является избыточной и должна быть ликвидирована.
2. Если имеется несколько сущностей с одинаковыми первичными ключами, то возможно объединение этих сущностей в одно в том случае, если в новой сущности может быть введен общий атрибут, ограничивающий смысл всех исходных сущностей. Можно ли пример? Ключ оставляем, а остальное сливаем в одну таблицу, добавляем атрибут, чтобы не было противоречий
3. Если некоторая сущность является проекцией одной сущности-связи, то она может быть объединена с другими проекциями. Т.е. несколько проекций одной сущности-связи можно объединить в одно (что такое проекция сущности – дубликат, и сущность связь – связывает две сущности?)
4. Если в модели есть сущности, имеющие одинаковый первичный ключ, и они имеют взаимно однозначное соответствие (это как? если они одинаковые), то их можно объединить в одну, в том случае, если периодичность (что за периодичность?) изменения первичных ключей во всех сущностях одинакова.
1.35. Датологическое проектирование БД.
Датологическое проектирование – организация данных, выделенных на предыдущем этапе проектирования в форму, принятую в выбранной СУБД.
Следующим шагом является выбор конкретной СУБД и отображение в ее среду спецификаций инфологической модели предметной области. Эту стадию называют логическим (даталогическим) проектированием БД. Ее результатом является концептуальная схема БД, включающая определение всех информационных единиц и связей, в том числе задание типов, характеристик и имен.
Проектирование логической структуры РБД предполагает:
• разбиение всей информации по отношениям (таблицам);
• определение состава полей (атрибутов) каждого отношения;
• определение ключа каждого отношения;
• определение связей и обеспечение целостности по связям.
Часто при описании логической структуры РБД указывают, по каким полям надо индексировать отношение, а для ключевых полей индексация предусматривается автоматически. Индексация занимает промежуточное положение между логической и физической структурой данных. Она определяет способ логического упорядочения данных и доступ к ним, но при этом создаются вспомогательные индексные файлы, что меняет общую структуру БД.
Возможно несколько альтернативных вариантов отображения инфологической модели в даталогическую. Следует учитывать влияние следующих факторов:
1) связи предметной области могут отображаться как декларативным путем – в логической схеме, так и процедурным – через программные модули, обрабатывающие (связывающие) соответствующие данные.
2) существенное влияние оказывает характер обработки. Частые обращения к совместно обрабатываемым данным предполагают их совместное хранение, а данные, к которым обращаются редко, целесообразно хранить отдельно.
Рассмотрим по шагам общий подход к построению РБД на основе инфологической модели, представленной ER-диаграммой.
1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы. Каждый простой атрибут становится столбцом таблицы с тем же именем: R1(И1 , А1 , А2 , А3 ).
2. Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Учитываются также следующие факторы:
• длина ключа – в качестве первичного ключа выбирается, как правило, самый короткий из вероятных ключей;
• стабильность– желательно выбирать в качестве первичного ключа атрибуты, которые не изменяются;
• мнемоничность– при прочих равных условиях следует отдавать предпочтение тем из вероятных ключей, которые легче запомнить.
Некоторые СУБД (Access, Paradox и др.) позволяют автоматически генерировать в качестве ключа таблицы поле типа «счетчик». Этот искусственный код можно использовать для простых объектов, если в предметной области не предполагается применение другой системы кодирования (ОКПО, ОКОНХ, ИНН).
Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (процесс может продолжаться рекурсивно).
3. Каждому из многозначных атрибутов ставится в соответствие отношение, полями которого будут идентификатор, выбранный в качестве первичного ключа, и многозначный атрибут. Ключ этого отношения будет составным, включающим оба эти атрибута. Для многозначных атрибутов МА4 и МА5 будут созданы отношения: R2(И1 , МА4 ) и R3(И1 ,МА5 ).
4. Если сущность имеет необязательный атрибут, возможны два варианта:
• если таким свойством обладают многие экземпляры объекта, его можно хранить как обычный атрибут в той же таблице (столбец может содержать неопределенные значения);
5. Если сущность имеет составной атрибут, то возможны два варианта:
• составному свойству ставится в соответствие отдельное поле;
• каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле.
6. Бинарные связи один-к-одному и один-ко-многим становятся внешними ключами. Создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.
Связь один-к-одному между сущностями встречается редко. Если класс принадлежности обеих сущностей является обязательным, то для отображения обеих связанных сущностей можно использовать одну таблицу:
R3(И1 , И2 , А1 , А2 ).
7. Преобразование бинарной связи один-ко-многим (1:N) зависит только от класса принадлежности N-связной сущности. Если он является обязательным, то можно использовать два отношения (по одному для каждой сущности). В отношение для N-связной сущности добавляется идентификатор 1-связной сущности:
R1(И1 , А1 )
R2(И2 , А2 , И1 ).
8. Для бинарной связи многие-ко-многим (М:N) потребуются три отношения: по одному для каждой сущности и одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов. Ключ этого отношения будет составным:
R1(И1 , А1 )
R2(И2 , А2 )
R3(И1 , И2 ).
9. В случае N-арной связи необходимо использовать (n+1) отношение – по одному для каждой сущности, и одно для связи. Идентификатор каждой сущности станет первичным ключом соответствующего отношения. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами отношения связи. Например:
R1(И1 , А1 )
R2(И2 , А2 )
R3(И3 , А3 )
R4(И1 , И2 , И3 , АС4 ).
10. Обобщающей сущности соответствует одно отношение, причем ключ сущности становится ключом отношения. Этому отношению приписываются общие для всех ролевых сущностей атрибуты.
1.36. Физическое проектирование БД.
Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.
Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.
Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных.
В случае реляционной модели данных под этим подразумевается следующее:
• создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;
• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;
• разработка средств защиты создаваемой системы.
Этапы концептуального и логического проектирования больших систем следует отделять от этапов физического проектирования. На это есть несколько причин.
• Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.
• Они выполняются в разное время, поскольку понять, что надо сделать, следует прежде, чем решить, как это сделать.
• Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.
Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений. Его следует рассматривать прежде всего как процесс познания. Как только проектировщик приходит к пониманию работы предприятия и смысла обрабатываемых данных, а также выражает это понимание средствами выбранной модели данных, приобретенные знания могут показать, что требуется уточнение и в других частях проекта. Особо важную роль в общем процессе успешного создания системы играет концептуальное и логическое проектирование базы данных. Если на этих этапах не удастся получить полное представление о деятельности предприятия, то задача определения всех необходимых пользовательских представлений или обеспечения защиты базы данных становится чрезмерно сложной или даже неосуществимой. К тому же может оказаться затруднительным определение способов физической реализации или достижения приемлемой производительности системы. С другой стороны, способность адаптироваться к изменениям является одним из признаков удачного проекта базы данных. Поэтому вполне имеет смысл затратить время и энергию, необходимые для подготовки наилучшего возможного проекта.
Этапы физического проектирования баз данных:
1. Перенос глобальной логической модели данных в среду целевой СУБД.
2. Проектирование основных отношений.
3. Разработка способов получения производных данных.
4. Реализация ограничений предметной области.
5. Проектирование физического представления базы данных.
6. Анализ транзакций.
7. Выбор файловой структуры.
8. Определение индексов.
9. Определение требований к дисковой памяти.
10. Проектирование пользовательских представлений.
11. Разработка механизмов защиты.
12. Обоснование необходимости введения контролируемой избыточности.
13. Текущий контроль и настройка операционной системы.
1.37. Объекты и режимы СУБД MSAccess.
• Таблицы - основные объекты базы данных. С ними мы уже знакомы. В них хранятся данные. Реляционная база данных может иметь много взаимосвязанных таблиц.
• Запросы - это специальные структуры, предназначенные для обработки данных базы. С помощью запросов данные упорядочивают, фильтруют, отбирают, изменяют, объединяют, то есть обрабатывают.
• Формы - это объекты, с помощью которых в базу вводят новые данные или просматривают имеющиеся. • Отчеты - это формы "наоборот". С их помощью данные выдают на принтер в удобном и наглядном виде.
• Макросы - это макрокоманды. Если какие-то операции с базой производятся особенно часто, имеет смысл сгруппировать несколько команд в один макрос и назначить его выделенной комбинации клавиш.
•Модули - это программные процедуры, написанные на языке Visual Basic. Если стандартных средств Access не хватает для удовлетворения требований заказчика, программист может расширить возможности системы, написав для этого необходимые модули или использовав готовые.
С организационной точки зрения в работе с любой базой данных есть два разных режима: проектировочный и эксплуатационный (пользовательский). Создатель базы имеет право создавать в ней новые объекты (например таблицы), задавать их структуру, менять свойства полей, устанавливать необходимые связи. Он работает со структурой базы и имеет полный доступ к базе. У одной базы может быть один, два или несколько разработчиков.
Пользователь базы - это лицо, которое наполняет ее информацией с помощью форм, обрабатывает данные с помощью запросов и получает результат в виде результирующих таблиц или отчетов. У одной базы могут быть миллионы пользователей, и, конечно, доступ к структуре базы для них закрыт.
1. Взгляните на стартовое окно базы данных. Кроме шести вкладок для основных объектов оно содержит три командные кнопки:
Открыть, Конструктор, Создать. С их помощью и выбирается режим работы с базой.
2. Кнопка Открыть открывает избранный объект. Если это таблица, то ее можно просмотреть, внести новые записи или изменить те, что были внесены ранее.
3. Кнопка Конструктор тоже открывает избранный объект, но по другому. Она открывает его структуру и позволяет править не содержимое, а устройство. Если это таблица, в нее можно вводить новые поля или изменять свойства существующих полей. Если это форма, в ней можно изменять или создавать элементы управления. Очевидно, что этот режим служит не для пользователей базы, а для ее разработчиков.
4. Действие командной кнопки Создать соответствует ее названию. Она служит для создания новых объектов. Этот элемент управления тоже предназначен для проектировщиков базы. Таблицы, запросы, формы и отчеты можно создавать несколькими разными способами: автоматически, вручную или с помощью Мастера. О достоинствах и недостатках этих методов мы поговорим при более подробном рассмотрении объектов Access.
1.38. Общая характеристика структурного подхода.
Структурный подход к анализу и проектированию ИС заключается в рассмотрении ее с общих позиций с последующей детализацией и представлением в виде иерархической структуры. На верхнем уровне иерархии обычно представляется функциональное описание системы. При проведении структурного анализа и проектирования для повышения наглядности используется графическое представление функций ИС и отношений между данными. Наиболее распространенными моделями и диаграммами графического представления являются следующие:
- диаграммы сущность – связь или ER-диаграммы служат для наглядного представления схем баз данных,
- диаграммы потоков данных служат для иерархического описания модели системы,
- метод структурного анализа и проектирования, служащий для проектирования функциональной модели объекта,
- схемы описания иерархии вход – обработка - выход служат для описания реализуемых программой функций и циркулирующих внутри нее потоков данных,
- диаграммы Варнье – Орра служат для описания иерархической структуры системы с выделением элементарных составных частей, процессов и указанием потоков данных для каждого процесса.
1.39. Классификация Case-средств.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
• средства анализа (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-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
Вспомогательные типы включают:
• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• средства конфигурационного управления (PVCS (Intersolv));
• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
• Vantage Team Builder (Westmount I-CASE);
• Designer/2000;
• Silverrun;
• ERwin+BPwin;
• S-Designor;
• CASE.Аналитик.
1.40. Обзор Case-средств.
На сегодняшний день российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
• Vantage Team Builder (Westmount I–CASE);• Designer/2000;• Silverrun;• ERwin+BPwin;• S-Designor;• CASE.Аналитик;• Rational Rose.
CASE-средство Silverrun американской фирмы "Computer Systems Advisers, Inc." (CSA) используется для анализа и проектирования АС бизнес-класса и ориентировано в большей степени на спиральную модель жизненного цикла. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
antage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели жизненного цикла (ЖЦ) ПО и поддержку полного жизненного цикла ПО.
Система обеспечивает выполнение следующих функций:
— проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
— проектирование диаграмм архитектуры системы SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);
— генерацию кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;
— программирование на языке С со встроенным сервером SQL;
— управление версиями и конфигурацией проекта;
— генерацию проектной документации по стандартным и индивидуальным шаблонам.
ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжениринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитарий данных средств.
BPwin — средство функционального моделирования, реализующее методологию IDEF0.
S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжениринг БД.
S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитарии данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.
CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования. Его основные функции:
• анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
• получение разнообразных отчетов по проекту;
• генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.
Среда функционирования: процессор-386 и выше, основная память 4 Мб, дисковая память 5 Мб, MS Windows 3.x или Windows 95.
С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитик, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.
Rational Rose — CASE-средство фирмы "Rational Software Corporation" (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует объединенную методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQL Windows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжениринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).
1.41. Основные принципы структурного подхода.
Основными из этих принципов являются следующие:
• принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
• принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
• принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
• принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);
• DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).
1.42. Виды диаграмм.
Рис.2. Структура SADT-модели. Декомпозиция диаграмм
Использование и особенности DFD диаграмм
Созданные модели потоков Данных организации могут быть использованы при решении таких задач, как:
1. определение существующих хранилищ данных (текстовые документы, файлы, Система управления базой данных — СУБД);
2. определение и анализ данных, необходимых для выполнения каждой функции процесса;
3. подготовка к созданию модели структуры данных организации, так называемая ERD-модель (IDEF1X);
4. выделение основных и вспомогательных бизнес-процессов организации.
Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD представляет моделируемую систему как сеть связанных работ.
При построении DFD-схемы бизнес-процесса нужно помнить, что данная схема показывает потоки материальных и информационных потоков и ни в коем случае не говорит о временной последовательности работ, хотя в большинстве случаев временная последовательность работ и совпадает с направлением движения потоков в бизнес-процессе.
Графический язык моделирования DFD диаграмм
Существуют две нотации DFD:
Как известно основным компонентом реляционных БД является таблица. Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы.
ERD-диаграмма графически представляет структуру данных проектируемой информационной системы. Сущности отображаются при помощи прямоугольников, содержащих имя. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи линий, соединяющих отдельные сущности. Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Рис. 6.1.Пример ERD-диаграммы,
Рис 5.2. ER-диаграмма
1.43. Основные понятия функциональной методики IDEF0.
IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
Основное понятие IDEF0-методологии – это понятие «модель». IDEF0-модель – это ис--кусственный объект, представляющий собой виртуальный образ системы и ее компонентов, в виде функциональной структуры объекта (совокупность диаграмм), отображающих производимые им действия и связи между этими действиями. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой ИС. IDEFO-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга.
Система– с точки зрения системологии, это совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей (люди, информация, про-граммное обеспечение, оборудование, изделия, сырье или энергия (энергоносители)). Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
1.44. Этапы процесса разработки модели в IDEF0.
Формирование IDEF0-модели начинается с создания ‘диаграммы верхнего уровня’, которая разрабатывается в несколько этапов.
На первом этапе ‘автор’ (‘разработчик’) диаграммы собирает информацию об архитектуре организационной системы. Нередко после предварительного сбора сведений создаются IDEF0-диаграммы, предназначенные для определения того, какую информацию еще предстоит получить.
На следующем этапе ‘разработчиком’ составляются список объектов и список функций, которые, по мнению ‘автора’, являются частью архитектуры организационной системы. Достаточность объектов и функций в каждом из списков определяется ‘разработчиком’ самостоятельно. Списки формируются следующим образом. Вначале, фиксируются любые объекты и функции, которые предположительно являются частью архитектуры организационной системы. Затем указывается, какие объекты необходимы для каждой конкретной функции, а после этого функции объединяются так, чтобы на ‘диаграмме верхнего уровня’ получилось 3-6 блоков, имеющих, по мнению ‘автора’, одинаковую сложность. Дуги тоже объединяются, при этом SADT/IDEF0 требует, чтобы с каждым блоком непосредственно соприкасалось не больше пяти дуг.
На третьем этапе создания ‘диаграммы верхнего уровня’ ‘разработчиком’ формулируются вопросы, для которых модель генерирует ответы. Эти вопросы необходимы, во-первых, для лучшего понимания ‘автором’ содержания модели, во-вторых, для формулировки цели создания модели, в-третьих, в качестве критерия окончания моделирования.
На очередном этапе формулируется ‘точка зрения’ модели, представляющая собой позицию, с которой возможно ответить на большинство поставленных вопросов. В дальнейшем на основании ‘точки зрения’ ‘разработчик’ принимает решение о прекращении декомпозиции. В SADT/IDEF0 действует правило, в соответствии с которым изменение ‘точки зрения’ при декомпозиции является показателем выхода за очерченные границы архитектуры организационной системы.
На следующем этапе вопросы, для которых моделью генерируются ответы, обобщаются, и оформляются ‘автором’ в виде ‘цели’. После этого ‘разработчик’ создает ‘диаграмму верхнего уровня’, которая представляет собой схему, изображающую архитектуру организационной системы в виде 3-6 общих функций. Концепцией SADT/IDEF0 рекомендована последовательность изображения графических компонент визуализации, позволяющая свести к минимуму ошибки при разработке IDEF0-схемы [3].
1.45. Состав функциональной модели.
Состав функциональной модели
Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (Рис. 1).
Рисунок 1. Функциональный блок и интерфейсные дуги
1.46. Этапы создания функциональной модели.
Процесс построения функциональной модели состоит из следующих этапов: построение контекстной диаграммы; проводится функциональная декомпозиция.
Согласно методологии функционального моделирования IDEF0 построение модели начинается с определения цели и точки зрения. Для этого необходим список вопросов, позволяющих определить границы модели.
Для подсистемы комплектования были сформулированы следующие вопросы:
Какие функции осуществляет данная подсистема?
Что является входными данными?
Что является выходными данными?
Что является управляющим компонентом?
Что (кто) является механизмом?
Входными данными, подлежащими вводу средствами подсистемы «Комплектование», являются: данные книготорговых и издающих организаций; данные об информационных потребностях пользователей; информация о продукции книгоиздательских и книготорговых организаций. Выходными данными подсистемы являются: заказные документы; отправленный заказ.
В качестве управляющих элементов определены нормативные документы и анализ статистических показателей. Механизмами являются сотрудник библиотеки и АРМ «Комплектатор».
Выявив, что должна делать подсистема, ее входные и выходные данные, определяется цель модели. Далее строят алгоритм традиционного процесса комплектования, используемый в конкретной библиотеке. На его основе выясняются основные компоненты процесса и их взаимосвязи, а также возможность автоматизации этого процесса. В результате создается алгоритм автоматизированного процесса комплектования (модель TO-BE)..
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
1.47. Иерархия SADT-диаграмм.
Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 2.7 показано типичное дерево диаграмм.
1.48. Типы связей между функциями в методологии SADT.
Значимость Тип связности Для функций Для данных
0 Случайная Случайная Случайная
1 Логическая Функции одного и того же множества или типа (например, "редактировать все входы") Данные одного и того же множества или типа
2 Временная Функции одного и того же периода времени (например,
"операции инициализации") Данные, используемые в каком-либо временном интервале
3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") Данные, используемые во время одной и той же фазы или итерации
4 Коммуникационнная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность
5 Последовательная Функции, выполняющие последовательные преобразования одних и тех же данных Данные, преобразуемые последовательными функциями
6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией
(0) Тип случайной связности: наименее желательный.
Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке 2.8.
Рис. 2.8. Случайная связность
(1) Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 2.9.
Рис. 2.9. Процедурная связность
(4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок 2.10).
(5) Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости (рисунок 2.11).
(6) Тип функциональной связности. Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рисунке 2.12.
Рис. 2.10. Коммуникационная связность
Рис. 2.11. Последовательная связность
1.49. Значимость типов связей между функциями в методологии SADT.
Ответ в 2,48
1.50. Моделирование потоков данных.
Моделирование потоков данных.
В основе методологии моделирования потоков данных лежит построение модели, анализируемой информационной системой. Модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхнего уровня иерархии определяют основные процессы внешними входами и выходами. Они детализируются при помощи диаграмм более низкого уровня. Детализация продолжается до тех пор пока не будет достигнут такой уровень декомпозиции, на котором процесс становится элементарным. Результатом детализации является многоуровневая иерархия диаграмм. Основными элементами диаграмм потоков данных являются внешние сущности, процессы или подсистемы, хранилища или накопители информации, потоки данных. При изображении диаграмм потоков данных используется две нотации:
- нотация Йодана;
- нотация Гейна-Сарсона.
1. Поток данных. Используется для моделирования передачи информации от источника к получателю, ориентация стрелки указывает направление движения информации.
2. Процесс. Выполняет преобразование входных потоков данных в выходные в соответствии с действием, которое определяется именем процесса. Имя процесса должно содержать глагол в неопределенной форме или отглагольное существительное и, возможно, дополнение.
3. Хранилище (накопитель данных). Обеспечивает хранение данных, которые сохраняются между процессами. Накопитель данных представляет собой абстрактное устройство для хранения информации.
4. Внешняя сущность - объект предметной области не входящий в контекст информационной системы и являющийся источником или получателем данных. Определение объектов предметной области в качестве внешней сущности указывает на то, что этот объект находится за пределами границ информационной системе и в обработке данных не участвует. Имя внешней сущности должно быть существительным.
1.51. Основные компоненты DFD.
Основными компонентами диаграмм потоков данных являются:
• внешние сущности;
• системы и подсистемы;
• процессы;
• накопители данных;
• потоки данных.
Внешняя сущность представляет собой материальный объект или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.
1.52. Построение иерархии диаграмм потоков данных.
Построение иерархии диаграмм потоков данных.
Главная цель в построении иерархии диаграмм потоков данных состоит в том, чтобы сделать ясными и понятными требования к проектируемой системе на каждом уровне ее детализации. В процессе построения иерархии диаграмм потоков данных следует придерживаться следующих правил:
1. Правило балансировки – означает, что при детализации процесса детализирующая диаграмма будет содержать только те компоненты информационных потоков которые определены на детализируемой диаграмме.
2. На каждой диаграмме может быть размещено от 2 до 9 процессов.
3. Несущественные на данном уровне детали использоваться не должны.
4. Декомпозиция потоков данных производится одновременно с декомпозицией процессов.
5. Имена процессов и потоков данных должны отражать их суть.
6. Функционально идентичные процессы следует определять один раз на самом верхнем уровне где процесс необходим, а затем на более низких уровнях на этот процесс ссылаться.
7. Следует разделять управляющие и входные потоки.
8. Правило нумерации состоит в том, что при детализации процессов должна поддерживаться их иерархическая нумерация.
1.53. Типы объектов для обеспечения декомпозиции данных в DFD.
Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки ЯБЛОКИ, АПЕЛЬСИНЫ и ГРУШИ. Эти потоки могут быть сгруппированы с помощью введения нового потока ФРУКТЫ. Для этого необходимо определить формально поток ФРУКТЫ как состоящий из нескольких элементов-потомков. Такое определение задается с помощью формы Бэкуса-Наура (БНФ) в словаре данных (см. главу 3). В свою очередь поток ФРУКТЫ сам может содержаться в потоке-предке ЕДА вместе с потоками ОВОЩИ, МЯСО и др. Такие потоки, объдиняющие несколько потоков, получили название групповых.
Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла (рис. 2.2), позволяющего расщепить поток на любое число подпотоков. При расщеплении также необходимо формально определить подпотоки в словаре данных (с помощью БНФ).
Рис 2.2. Расширения диаграммы потоков данных
Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток ФРУКТЫ, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока ФРУКТЫ может не быть вовсе, но вместо него могут быть потоки ЯБЛОКИ и АПЕЛЬСИНЫ (как будто бы они переданы из детализируемого процесса). В этом случае должно существовать БНФ-определение потока ФРУКТЫ, состоящего из подпотоков ЯБЛОКИ и АПЕЛЬСИНЫ, для целей балансирования.
Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм.
Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов:
1. ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме).
2. УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD.
3. НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока.
4. УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным.
5. Текст в свободном формате в любом месте диаграммы.
1.54. Рекомендации к построению модели в методологии DFD.
Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
1. Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
2. Не загромождать диаграммы несущественными на данном уровне деталями.
3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой.
4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.
5. Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться к нему на нижних уровнях.
6. Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты.
7. Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.
В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы:
1. Расчленение множества требований и организация их в основные функциональные группы.
2. Идентификация внешних объектов, с которыми система должна быть связана.
3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
4. Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты - внешними сущностями, основные виды информации - потоками данных между процессами и внешними сущностями.
5. Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
7. Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
8. Проверка основных требований по DFD первого уровня.
9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
10. Проверка основных требований по DFD соответствующего уровня.
11. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
12. Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
13. После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.
14. Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.
1.55. Базовые понятия ERD.
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
• иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
• иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь ;
• иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности . Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
1.56. Дополнительные понятия ERD.
1.57. Метод IDEF1.
Метод IDEFI
Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI.
Метод Баркера основан на нотации, предложенной автором, и используется в case-средстве Oracle Designer.
Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
В методе IDEFIX сущность является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 10.1, 10.2).
Рис. 10.1. Независимые от идентификации сущности
Рис. 10.2. Зависимые от идентификации сущности
Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). В IDEFIX могут быть выражены следующие мощности связей:
• каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рис. 10.3). Мощность связей может принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р — один или более. По умолчанию мощность связей принимается равной N.
Рис. 10.3. Графическое изображение мощности связи
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями ).
Пунктирная линия изображает неидентифицирующую связь (рис. 10.4). Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 10.4 ).
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рис. 10.4).
1.58. Мощности связей в методе IDEF1.
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:
• каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 2.31 (мощность по умолчанию - N).
1.59. Основные понятия объектно-ориентированного подхода.
Объектно-ориентированный подход основан на систематическом использовании моделей для языково-независимой разработки программной системы, на основе из ее прагматики.
Последний термин нуждается в пояснении. Прагматика определяется целью разработки программной системы: для обслуживания клиентов банка, для управления работой аэропорта, для обслуживания чемпионата мира по футболу и т.п. В формулировке цели участвуют предметы и понятия реального мира, имеющие отношение к разрабатываемой программной системе (см. рисунок 1.1). При объектно-ориентированном подходе эти предметы и понятия заменяются их моделями, т.е. определенными формальными конструкциями, представляющими их в программной системе.
Рис. 1.1. Семантика (смысл программы с точки зрения выполняющего ее компьютера) и прагматика (смысл программы с точки зрения ее пользователей)
Модель содержит не все признаки и свойства представляемого ею предмета (понятия), а только те, которые существенны для разрабатываемой программной системы. Тем самым модель "беднее", а, следовательно, проще представляемого ею предмета (понятия). Но главное даже не в этом, а в том, что модель есть формальная конструкция: формальный характер моделей позволяет определить формальные зависимости между ними и формальные операции над ними. Это упрощает как разработку и изучение (анализ) моделей, так и их реализацию на компьютере. В частности, формальный характер моделей позволяет получить формальную модель разрабатываемой программной системы как композицию формальных моделей ее компонентов.
Таким образом, объектно-ориентированный подход помогает справиться с такими сложными проблемами, как
• уменьшение сложности программного обеспечения;
• повышение надежности программного обеспечения;
• обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;
• обеспечение возможности повторного использования отдельных компонентов программного обеспечения.
Систематическое применение объектно-ориентированного подхода позволяет разрабатывать хорошо структурированные, надежные в эксплуатации, достаточно просто модифицируемые программные системы. Этим объясняется интерес программистов к объектно-ориентированному подходу и объектно-ориентированным языкам программирования. Объектно-ориентированный подход является одним из наиболее интенсивно развивающихся направлений теоретического и прикладного программирования.
Цель данного курса лекций - введение в объектно-ориентированный подход к разработке и реализации прикладных программных систем. Я попытаюсь убедить вас в целесообразности и плодотворности систематического применения объектно-ориентированного подхода на всех этапах жизненного цикла прикладной программной системы (см. рисунок 1.2), начиная с анализа требований к программной системе и ее предварительного проектирования, и кончая ее реализацией, тестированием и последующим сопровождением.
Рис. 1.2. Жизненный цикл программной системы
1.60. Группа понятий объектно-ориентированного подхода.
Объектно-ориентированный подход использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов.
Что же понимается под объектом и каковы другие основополагающие понятия данного подхода?
Прежде всего, введем понятие класса. Класс - это абстракция множества сущностей реального мира, объединенных общностью структуры и поведения.
Объект - это элемент класса, то есть абстракция определенной сущности.
Подчеркнем, что объекты активны, у них есть не только внутренняя структура, но и поведение, которое описывается так называемыми методами объекта. Например, может быть определен класс "пользователь", характеризующий "пользователя вообще", то есть ассоциированные с пользователями данные и их поведение ( методы ). После этого может быть создан объект "пользователь Иванов" с соответствующей конкретизацией данных и, возможно, методов.
К активности объектов мы еще вернемся.
Следующую группу важнейших понятий объектного подхода составляют инкапсуляция, наследование и полиморфизм.
Основным инструментом борьбы со сложностью в объектно-ориентированном подходе является инкапсуляция - сокрытие реализации объектов (их внутренней структуры и деталей реализации методов ) с предоставлением во вне только строго определенных интерфейсов.
Понятие " полиморфизм " может трактоваться как способность объекта принадлежать более чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под разными углами зрения, выделять при построении абстракций разные аспекты сущностей моделируемой предметной области, не нарушая при этом целостности объекта. (Строго говоря, существуют и другие виды полиморфизма, такие как перегрузка и параметрический полиморфизм, но нас они сейчас не интересуют.)
Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Наследование является важным инструментом борьбы с размножением сущностей без необходимости. Общая информация не дублируется, указывается только то, что меняется. При этом класс -потомок помнит о своих "корнях".
Очень важно и то, что наследование и полиморфизм в совокупности наделяют объектно-ориентированную систему способностью к относительно безболезненной эволюции. Средства информационной безопасности приходится постоянно модифицировать и обновлять, и если нельзя сделать так, чтобы это было экономически выгодно, ИБ из инструмента защиты превращается в обузу.
Мы еще вернемся к механизму наследования при рассмотрении ролевого управления доступом. Пополним рассмотренный выше классический набор понятий объектно-ориентированного подхода еще двумя понятиями: грани объекта и уровня детализации.
Объекты реального мира обладают, как правило, несколькими относительно независимыми характеристиками. Применительно к объектной модели будем называть такие характеристики гранями . Мы уже сталкивались с тремя основными гранями ИБ - доступностью, целостностью и конфиденциальностью. Понятие грани позволяет более естественно, чем полиморфизм, смотреть на объекты с разных точек зрения и строить разноплановые абстракции.
Понятие уровня детализации важно не только для визуализации объектов, но и для систематического рассмотрения сложных систем, представленных в иерархическом виде. Само по себе оно очень простое: если очередной уровень иерархии рассматривается с уровнем детализации n > 0, то следующий - с уровнем (n - 1). Объект с уровнем детализации 0 считается атомарным.
Понятие уровня детализации показа позволяет рассматривать иерархии с потенциально бесконечной высотой, варьировать детализацию как объектов в целом, так и их граней.
Весьма распространенной конкретизацией объектно-ориентированного подхода являются компонентные объектные среды, к числу которых принадлежит, например, JavaBeans. Здесь появляется два новых важных понятия: компонент и контейнер.
Неформально компонент можно определить как многократно используемый объект, допускающий обработку в графическом инструментальном окружении и сохранение в долговременной памяти.
Контейнеры могут включать в себя множество компонентов, образуя общий контекст взаимодействия с другими компонентами и с окружением. Контейнеры могут выступать в роли компонентов других контейнеров .
Компонентные объектные среды обладают всеми достоинствами, присущими объектно-ориентированному подходу:
• инкапсуляция объектных компонентов скрывает сложность реализации, делая видимым только предоставляемый вовне интерфейс;
• наследование позволяет развивать созданные ранее компоненты, не нарушая целостность объектной оболочки;
• полиморфизм по сути дает возможность группировать объекты, характеристики которых с некоторой точки зрения можно считать сходными.
Понятия же компонента и контейнера необходимы нам потому, что с их помощью мы можем естественным образом представить защищаемую ИС и сами защитные средства. В частности, контейнер может определять границы контролируемой зоны (задавать так называемый "периметр безопасности").
1.61. Основные элементы объектной модели.
При создании любого программного проекта в качестве первого (и самого главного) этапа есть всегда проектирование. В любой инженерной дисциплине под проектированием обычно понимается какой-то унифицирован подход, с помощью которого мы ищем пути решения определенной проблемы, обеспечивая выполнение поставленной задачи. За предположением Страуструпа: "Цель проектирования - выявление ясной и относительно простой внутренней структуры, которая иногда называется архитектурой... Проект является окончательным продуктом процесса проектирования". Продуктами проектирования являются модели, которые позволяют нам понять структуру будущей системы, сбалансировать требования и наметить схему реализации.
Моделирование широко распространено во всех инженерных дисциплинах, в значительной мере из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии. Каждая модель описывает определенную часть рассмотренной системы, а мы в свою очередь строим новые модели на базе старых, в которых более-менее уверенные. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.
Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами является: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм, и сохраняемость. Каждый из этих принципов собственно не новый, но в объектной модели они впервые применены в совокупности. Первые четыре понятия является обязательными в том понимании, что без каждого из них модель не будет объектно-ориентированной. Другие являются дополнительными, имея в виду, что они полезны в объектной модели, но не обязательные.
1.62. Дополнительные элементы объектной модели.
Интерфейс – специальный элемент информационной модели, предназначенный для связи логического представления и структуры информационного хранилища. Интерфейс является поименованным набором характеристик - свойств интерфейса и связан с определенной таблицей. Каждое свойство интерфейса связано с полем таблицы и своим типом определяет логику и семантику работы с данными этого поля: простое значение, перечисление, ссылка на объект, автоматически заполняемое значение и т.д. Каждому компоненту объекта соответствует один интерфейс, свойства которого автоматически являются атрибутами компонента. Каждой таблице могут соответствовать более одного интерфейса, что позволяет по-разному интерпретировать данные одной и той же таблицы для разных компонентов.
Представление – дополнительный элемент информационной модели, описывающий форму табличного представления данных и являющийся поименованным набором пар интерфейс-свойство – колонок представления. Каждая колонка представления может быть дополнена критериями фильтрации и/или объединения данных.
1.63. Состав методов объектно-ориентированного подхода.
В конце 80-х и начале 90-х годов ХХ века возникли различные объектно-ориентированные (О-О) методы, предлагающие подходы объектно-ориентированного анализа и разработки. Ранние О-О методы возникли в тех компаниях, для которых было очень важно обеспечить небольшое время выхода продукта на рынок и высокую устойчивость продукта к изменениям. В числе таких компаний были телекоммуникационные и финансовые, а позднее аэрокосмические, медицинские, банковские, страховые, транспортные и др. В то время и возникли объектно-ориентированный анализ (ООА = object-oriented analysis), техника объектного моделирования (OMT = object-oriented technique), метод Буча (Booch) и Обжектори (Objectory). Примерно в 1998 году появился метод Шлера (Shlaer) и Меллора (Mellor), который хотя и не являлся полностью объектно-ориентированным, но сыграл в то время важную роль в продвижении объектно-ориентированной парадигмы в проектировании.
ООА.
ООА был разработан Кодом (Coad) и Иордоном (Yourdon).
Метод разделяет разработку на три слоя. В первом слое осуществляется определение объектов, поэтому слой и называется объектным. Тут пользователи могут продемонстрировать свое понимание проблемной области, определяя соответствующие объекты из предметной области.
Второй слой называется слоем атрибутов. На этом этапе определяются атрибуты (элементы данных), связанные с объектами из предметной области.
Третий слой - сервисный слой, определяющий сервисы (или операции), предоставляемые каждым объектом.
В сущности, ООА помогает системным инженерам определить требования к системе, вместо того чтобы определять структуру программного обеспечения или его реализацию. В то же время, этот метод может помочь и в описании уже существующей системы (в том числе и ПО), ее операций и того, как другие системы должны взаимодействовать с ней.
ОМТ.
Метод ОМТ был разработан Румбахом (Rumbaugh).
Основная задача метода это создание таких наборов объектных моделей, детально описывающих архитектуру системы, пока финальный вариант модели не станет пригодным для реализации.
Подход предполагает наличие трех фаз. На фазе анализа создаются модели предметной области. В течение этой фазы создаются модели трех типов - объектные модели, динамические модели и функциональные модели. В первую очередь разрабатываются объектные модели. Для объектных моделей применяется нотация аналогичная ООА, основанная на концепции моделировании сущностей и связей (ER = Entity-Relationship modeling). Объектные модели описывают объекты, классы объектов и связи между объектами. Динамические модели описывают поведение системы с помощью расширения диаграмм состояний Харела (Harel). Функциональные модели описывают функции системы с помощью диаграмм потоков данных (DFD).
Каждая из моделей многократно уточняется и дорабатывается. На фазе проектирования (design) особое внимание уделяется структуре моделей, а на фазе разработки больше внимания уделяется языку, на котором планируется разработка. Таким образом, ОМТ покрывает не только процесс получение требований к системе, но также и процесс проектирования архитектуры решения.
Booch.
Метод Буча (Booch, 1994) был одним из первых предложенных объектно-ориентированных методов. Несмотря на то, что метод рассматривает фазу анализа, его основная сила появляется при проектировании объектно-ориентированных систем. Метод предусматривает постепенное и многократное уточнение архитектуры системы (incremental and iterative approach). Метод также вводит понятия логического и физического представлений системы.
Метод предусматривает фазу анализа проблемной области для выявления классов и объектов, а также связей между ними. Метод использует графическую нотацию для проектирования. Нотация имеет расширения для реализации классов и объектов, а также сервисов предоставляемых ими. Другой важной особенностью применяемой нотации является наличие диаграмм переходов состояний (state transition diagrams) и временных диаграмм (timing diagrams).
Objectory.
Метод Обжектори был предложен Якобсеном (Jacobsen).
Большинством своих идей метод похож на другие объектно-ориентированные методы. Фундаментальным отличием метода, как уже упоминалось выше, является использование сценариев или прецедентов (scenarios или use cases). Таким образом, функциональность системы описывается с помощью набора прецедентов для системы - моделью прецедентов.
В дальнейшем, модель прецедентов используется для получения модели объектов предметной области. Анализ полученной модели объектов предметной области позволяет классифицировать объекты предметной области трех типов: интерфейсные объекты, объекты сущностей и управляющие объекты. Далее объектная модель преобразуется в архитектурную модель, содержащую модули разрабатываемой системы.
1.64. Основные понятия UML.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — языкграфического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной моделисистемы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
К основным понятиям UML относятся:
• Сущности – абстракции, являющиеся основными элементами модели;
• Отношения – связывают различные сущности;
• Диаграммы – группируют представляющие интерес совокупности сущностей.
Сущности
• структурные – статические части модели, соответствующие концептуальным или физическим элементам модели;
• поведенческие – динамические составляющие, описывающие поведение модели во времени и в пространстве;
• группирующие;
• аннотационные.
Структурные сущности
Класс (Class) – описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Реализует несколько интерфейсов.
Интерфейс (Interface) – совокупность операций, которые определяют набор услуг, предоставляемых классом или компонентом. Описывает видимое извне поведение элементов.
Кооперация (Collaboration)– совокупность операций, которые производят некоторый общий эффект, не сводящийся к простой сумме слагаемых.
Вариант использования (Use сase) – описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-либо определенного действующего лица (Actor).
Активный класс (Active class) – класс, объекты которого вовлечены в один или несколько процессов и могут инициировать управляющее воздействие.
Компонент (Component) – физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию.
Узел (Node) – элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс.
Поведенческие сущности
Взаимодействие (Interaction) – поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенных целей.
Автомат (State machine) – поведение, определяющее последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакция на эти события.
1.65. Синтаксис и семантика основных объектов UML.
Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний.
Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста.
Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.
1.66. Стандартный набор диаграмм и нотаций самых различных видов, содержащийся в UML.
Нотация представляет собой графическую интерпретацию семантики для ее визуального представления.
В UML определено три типа сущностей:
- структурная – абстракция, являющаяся отражением концептуального или физического объекта;
- группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
- поясняющая (аннотационная) – комментарий к элементу диаграммы.
Тип Наименование Обозначение Определение (семантика)
Структурная Класс
(class) Множество объектов, имеющих общую структуру и поведение
Объект
(object) абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности)
интерфейс
(interface)
iРасчет совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
актер
(actor)
Инженер
службы пути внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
вариант использования
(use case) описание последовательности выполняемых системой действий, которая приводит к значимому для актера результату
состояние
(state) описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
кооперация
(collaboration) описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
компонент
(component) физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
узел
(node) физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Группирующая Пакет
(packages) Общий механизм группировки элементов.
В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
Поясняющая Примечание
(comment) Комментарий к элементу
Таблица 11.2. Отношения
Наименование Обозначение Определение (семантика)
Ассоциация (association) Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения
Агрегация (aggregation) Подвид ассоциации, описывающей связь "часть"–"целое", в котором "часть" может существовать отдельно от "целого". Ромб указывается со стороны "целого". Отношение указывается только между сущностями одного типа
Композиция (composition) Подвид агрегации, в которой "части" не могут существовать отдельно от "целого". Как правило, "части" создаются и уничтожаются одновременно с "целым"
Зависимость (dependency) Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность
Обобщение (generalization) Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа
Реализация (realization) Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)
Информационные системы в образовании
Экзаменационные билеты по предмету «Информатика»