11. Опишите процесс проектирования фактографических бд: методы проектирования; концептуальное, логическое и физическое проектирование.

Фактографические модели имеет структуру "объект-свойства-значения". Множество однотипных объектов в таких моделях представляется сущностью, а свойства объектов – атрибутами сущности. Например, продукция некоторого предприятия может быть сущностью "изделие", а атрибутами сущности – цена, геометрические размеры, дата изготовления и т.п.

Примерами фактографических моделей могут служить справочные таблицы значений физических величин, спецификации деталей и сборок, используемых в промышленных изделяих, и т.п. Одной из наиболее популярных фактографических моделей является модель "сущность-связь" (ER-модель). Эта модель предложена Ченом (Chen) в 1976 г. В ней представлено множество сущностей и отношений между ними.

Физическая модель – то, что реально получилось

Логическая модель – то, что проектировалось (схемы)

Концептуальная модель – определяется таблицами БД без объектов и элементов

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь".

Инфологическая модель должна быть отображена в компьютерно-ориентированную даталогическую модель, "понятную" СУБД

Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД.

10. Опишите процесс разработки состава и структуры БД, проектирование логико-семантического комплекса. Проектирование баз данных — это итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны прикладных программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств. Этапы проектирования баз данных связаны с многоуровневой организацией данных. Рассматривая вопрос проектирования баз данных, будем придерживаться такого многоуровневого представления данных: внешнего, инфологического, логического (даталогического) и внутреннего. Внешний уровень в этом случае выступает как отдельный этап проектирования, на котором изучается все внемашинное информационное обеспечение, то есть формы документирования и представления данных, а также внешняя среда, в которой будет функционировать банк данных с точки зрения методов фиксации, сбора и передачи информации в базу данных. Инфологический уровень представляет собой информационно-логическую модель (ИЛМ) предметной области, из которой исключена избыточность данных и отображены информационные особенности объекта управление без учета особенностей и специфики конкретной СУБД. То есть инфологическое представление данных ориентированно преимущественно на человека, который проектирует или использует базу данных. Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД. Модель логического уровня, поддерживаемую средствами конкретной СУБД, называют еще даталогической. Инфологическая и даталогическая модели, которые отображают модель одной предметной области, зависимы между собой. Инфологическая модель может легко трансформироваться в даталогическую модель. Внутренний уровень связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным. Целью проектирования на внешнем уровне является разработка внемашинного информационного обеспечения, которое включает систему входной (первичной) документации, характеризующую определенную предметную область, систему классификации и кодирования технико-экономической информации, а также перечень соответствующих выходных сообщений, которые нужно формировать с помощью БнД. Существуют два подхода к проектированию баз данных на внешнем уровне: «от предметной области» и «от запроса».  Подход «от предметной области» состоит в том, что формируется внешнее информационное обеспечение всей предметной области без учета потребностей пользователей и прикладных программ. Иногда этот подход называют еще объектным или непроцессным. Предметную область можно определить как сферу человеческой деятельности, выделенную и описанную согласно установленным критериям. В описываемое понятие должны входить сведения об ее элементах, явлениях, отношениях и процессах, отражающих различные аспекты этой деятельности. В описании предметной области должны присутствовать характеристики возможных воздействий окружающей среды на элементы и явления предметной области, а также обратные воздействия этих элементов и явлений на среду. Цель семантического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому семантическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компью

12. Опишите автоматизированное проектирование ИС с использованием CASE-технологий. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. CASE-технология - это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. Основа CASE-технологии - использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. CASE-технология поддерживает групповую работу над проектом, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, т. е. Функции, необходимые в процессе разработки и сопровождения проектов. Макетирование. Генерация документации. Верификация проекта. Автоматическая генерация объектного кода. Сопровождение и реинжиниринг.

Классификация современных CASE-средств Современные CASE-системы классифицируются по следующим признакам: 1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования); 2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями; 3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием); 4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ,  ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа; 5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;  6) по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.)

13. Опишите функционально-ориентированный и объектно-ориентированный подходы. Опишите содержание RAD-технологии прототипного создания приложений.. Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения.

В качестве итога перечислим основные принципы методологии RAD: разработка приложений итерациями;необязательность полного завершения работ на каждом из этапов жизненного цикла;обязательное вовлечение пользователей в процесс разработки ИС; необходимое применение CASE-средств, обеспечивающих целостность проекта; применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;необходимое использование генераторов кода; использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; тестирование и развитие проекта, осуществляемые одновременно с разработкой; ведение разработки немногочисленной хорошо управляемой командой профессионалов;

грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.