3 Выбор лингвистическогообеспечения, разработка

программного обеспечения АИС.

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

4 Тестирование и отладка аис

На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.

5 Эксплуатация и контроль версий

Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%.

Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

7. Каноническое и типовое проектирование ЭИС.

Каноническое проектирование ЭИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование применяется для небольших локальных ЭИС.

В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектирования в жизненном цикле ЭИС в соответствии с применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные системы стадий создания» делится на следующие семь стадий:

• исследование и обоснование создания системы;

• разработка технического задания;

• создание эскизного проекта;

• техническое проектирование;

• рабочее проектирование;

• ввод в действие;

• функционирование, сопровождение, модернизация.

Основные понятия и классификация методов типового проектирования

Методы типового проектирования ЭИС предполагают созда­ние системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (под­систем, комплексов задач, программных модулей и т.д.), для ко­торых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области.

Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая про­граммные модули, проектное решение, пригодное к многократ­ному использованию. В качестве проектного решения может вы­ступать реализация как отдельных компонентов ЭИС (программ­ных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислитель­ных сетей), так и взаимосвязанных комплексов компонентов (фун­кциональных и обеспечивающих подсистем, ЭИС в целом). Ти­повые проектные решения также называют тиражируемыми про­дуктами.

В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового про­ектирования

При элементном методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному) .

Достоинство элементного метода типо­вого проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС.

К недостаткам применения метода относятся большие затра­ты времени на сопряжение разнородных элементов вследствие ин­формационной, программной и технической несовместимости TПP, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия.

В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислитель­ных и служебных функций. В силу ограниченного характера при­менения в дальнейшем метод элементного типового проектиро­вания ЭИС не рассматривается.

При использовании подсистемного метода типового проек­тирования ЭИС в качестве элементов типизации выступают от­дельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, па­раметрическую настраиваемость, альтернативность схем в пре­делах значений входных параметров. При этом достигается бо­лее высокая степень интеграции типовых элементов ЭИС

В качестве примеров широко распространенных функциональных ППП можно назвать: 1C «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета и др.

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

• открытостью архитектуры, позволяющей устанавливать про­екты на разных программно-технических платформах;

• масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест;

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

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

7. Параметрически- и модельно-ориентированное проектирование ЭИС.

Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.

Критерии оценки ППП делятся на следующие группы:

– назначение и возможности пакета;

– отличительные признаки и свойства пакета;

– требования к техническим и программным средствам;

– документация пакета;

– факторы финансового порядка;

– особенности установки пакета;

– особенности эксплуатации пакета;

– помощь поставщика по внедрению и поддержанию пакета;

– оценка качества пакета и опыт его использования;

– перспективы развития пакета.

Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП.

Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.

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

Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС. Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, либо путем автоматизированной адаптации этих моделей в результате экспертного опроса.Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.

Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

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

7. Автоматизированное проектирование: технология быстрой разработки приложений RAD и метод экстремального программирования.

RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

Одним из возможных подходов к разработке ИС в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application

Development). Под этим термином обычно понимается процесс разработки ИС, содержащий 3 элемента:

• небольшую команду программистов (от 2 до 10 человек);

• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

• повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Основные принципы методологии RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждом из этапов жизненного цикла;

• обязательное вовлечение пользователей в процесс разработки ИС;

• необходимое применение CASE-средств, обеспечивающих целостность проекта;

• необходимое использование генераторов кода;

• использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

• тестирование и развитие проекта, осуществляемые одновременно с разработкой;

• ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

Жизненный цикл ИС по технологии RAD состоит из четырех фаз:

• фаза анализа и планирования требований;

• фаза проектирования;

• фаза построения;

• фаза внедрения.

Границы применимости методологии RAD.

Методы УРП и СРП можно использовать далеко не всегда, а лишь в том случае, если:

• объем проекта и требования бизнеса четко определены, не изменяются, а сам проект невелик;

• проект не зависит от других средств автоматизации бизнеса, количество внешних интерфейсов ограниченно;

• система ориентирована на экранные формы, обработка данных и системные функции составляют незначительную часть, удобство экранных форм является важнейшим фактором успеха проекта;

• пользователи имеют высокую квалификацию и изначально положительно оценивают идею создания новой системы.

Метод экстремального программирования

В настоящее время предпринята попытка представить еще один способ быстрого написания проекта — метод экстремального программирования.

Этап планирования (planning game). На основании оценок, сделанных программистами, заказчик определяет функциональные возможности и срок реализации версий системы. Программисты реализуют только те функции, которые необходимы для возможностей, выбранных на данной итерации.

Частая смена версий (small releases). Систему запускают в эксплуатацию уже через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Выпуск новых версий может происходить с периодичностью от ежедневного до ежемесячного.

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

Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Чтобы принять правильное решение, необходимо понять, во сколько обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на исправление дефекта.

Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов.

Программирование в паре (pair programming). Весь код проекта пишут два человека, которые используют одну настольную систему.

Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее, чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты.

Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются.

Коллективное владение (collective ownership). Каждый программист имеет возможность в любое время усовершенствовать любую часть кода в системе, если сочтет это необходимым.

Заказчик с постоянным участием (on-site customer). Заказчик, кото рый в период работы над системой находится в команде разработчиков.

Открытое рабочее пространство (open workspace). Команда разработчиков располагается в большом помещении, окруженном комнатами меньшей площади. В центре рабочего пространства устанавливаются компьютеры, на которых работают пары программистов.

Не более чем правила (just rules). Члены коллектива, работающего по технологии экстремального программирования, обязуются выполнять изложенные правила. Однако это не более чем правила и команда может в любой момент поменять их, если ее члены достигли принципиального соглашения по поводу внесенных изменений.

В итоге мы получаем метод, потенциально обладающий высокой адаптируемостью к сильно изменяющимся требованиям к проекту, но в то же время не свободный от ряда серьезных недостатков. Последнее обстоятельство не позволяет рекомендовать данный метод к применению для проектов, требующих высокой или как минимум достаточной надежности работы.

7. Инфологическое проектирование ИС. Проектирование документальных БД.

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

Инфологический уровень может выступать как самостоятельный или быть составной частью внешнего уровня. В результате инфологического проектирования ИС должна быть создана инфологическая модель будущей БД. На этапе построения инфологической модели должны быть выполнены следующие шаги:

• Определение объектов, в которых накапливается и обрабатывается информация.

• Определение основных характеристик объектов и их взаимосвязей.

Существует различные подходы в инфологическом проектировании:

• Функциональный подход реализует принцип ―от задач.

• Объектный подход не фиксирует количество решаемых задач, а включает в инфологическую модель только объекты и связи между ними.

• Смешанный подход объединяет предметный и функциональный.

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

Логический (концептуальный) уровень строится с учетом специфики и особенностей конкретной СУБД.

Инфологическая и даталогическая модели, которые отображают модель одной предметной области, зависимы между собой. Инфологическая модель может легко трансформироваться в даталогическую модель. Внутренний уровень связан с физическим размещением данных в памяти ЭВМ.

Задача инфологического этапа - получение семантических (смысловых) моделей, отражающих информационное содержание системы. Определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы. Знания о предметной области представляются в какой-либо языковой системе, например, с использованием естественного языка, математических формул, диаграммы связей и т.д. Выполняется структуризация знаний о предметной области: выделяются и классифицируются множества составляющих функций, стандартизуется терминология. Затем описываются запросы пользователей к БД. Формируются описания внешних инфологических моделей, их взаимная увязка с концептуальной инфологической моделью без привязки к конкретной СУБД. Для описания инфологической модели в объектном подходе используются диаграммы ―объекты - связи‖ или, по-другому, ER - диаграммы.

Проектирование документальных БД

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

Документированные ИС предназначены для обеспечения санкционированного доступа к документам. Под документом понимается определенная совокупность сведений, используемая при решении экономических задач, расположенная на материальном носителе в соответствии с установленной формой.

Характерные функции таких ИС:

• ввод документов

• индексирование документов;

• хранение документов;

• поиск нужных данных;

• поддержка групповой работы над документами;

• разграничение прав доступа к документам;

• контроль и управление версиями документов, регламентирующие внесение в них изменений;

• сбор и анализ статистических данных по параметрам документов и функционированию системы;

• подготовка отчетов.

В процессе решения задач удобство диалогового режима в полной мере проявляется в процессе общения с базой данных. Среди них можно отметить такие как:

• возможность перебора различных комбинаций поисковых признаков в запросе;

• обеспечение более быстрого поиска данных;

• улучшение характеристик выходных данных за счет оперативной коррекции запроса с терминала;

• возможность расширения, сужения или изменения направлений поиска сразу после получения результатов;

• множественность точек доступа;

• быстрый доступ к относительно редко используемой информации;

• оперативный анализ получаемых сведений.

Основные принципы функционирования документальной системы:

• каждый потребитель вступает в контакт с системой на определенный период времени, в процессе которого осуществляется обмен сообщениями, именуемый диалоговой сессией или сеансом связи пользователя с системой;

• потребители могут одновременно проводить поиск в нескольких различных БД (поисковых массивах разной тематики, обладающих различными структурами документов). БД, поддерживаемые в системе, могут создаваться как собственными силами организации-пользователя, так и путем загрузки внешних БД, подготавливаемых службами-генераторами на машиночитаемых носителях. Согласование внешних и внутренних форматов документов осуществляется с помощью конверторов;

• на период диалоговой сессии за каждым потребителем закрепляются временные наборы данных (ВНД), куда заносятся результаты поиска, запросы и учетная информация, и часть содержимого которых может быть сохранена по директивам пользователя в постоянных наборах данных (ПНД) после окончания диалоговой сессии;

• работа системы проходит под наблюдением администратора, который имеет возможность путем вмешательства с главного терминала устранять помехи для нормального процесса работы.

• форматные поля и список двухбайтовых кодов слов, находящихся в тексте данного документа и прошедших входную обработку.

Основным средством администратора при проектировании логической структуры документальной БД является совокупность таблиц, описывающих внутренний формат документа и его связь с внешним (входным) форматом. Такие таблицы получили обобщенное название DBD (database definition - определение базы данных).

7. Проектирование фактографических БД: иерархическая МД, сетевая модель данных (модель CODASYL).

Проектирование фактографических БД

В фактографических БД содержат краткие сведения об описываемых объектах, представленные в строго определенном формате. Например, в БД библиотеке о каждой книге хранятся библиографические сведения: год издания, автор, название и пр.; в записной книжке школьника могут храниться фамилия, имена, даты рождения, телефоны, адреса друзей и знакомых. Основные признаки - простая структура данных и сложная система взаимосвязей между агрегатами данных.

В исторической последовательности развития данных систем сначала появились АИС, базирующиеся на иерархических, затем на сетевых и, наконец, на реляционных и постреляционных представлениях о структуре предметной области. В настоящее время наиболее распространенным подходом является реляционный (табличные БД), что не исключает, конечно, включения элементов иерархических и сетевых представлений при проектировании АИС.

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

Иерархическая МД (ИМД)

Впервые реализована в СУБД IBM - IMS (Information Management System), разработанной для поддержки банка данных по программе Apollo. При данном подходе предметная область представляется в виде совокупности структур иерархического типа (граф - "дерево").

Основные понятия ИМД:

• поле - минимальная единица данных;

• сегмент (узел) - совокупность полей, являющаяся единицей обмена между БД и прикладной программой. Сегмент (узел иерархического графа) более высокого уровня называется исходным (родительским) по отношению к ниже расположенному порожденному (отпрыску). Может использоваться также терминология "узел, принадлежащий вышестоящему узлу".

Конкретные данные, входящие в сегмент называются экземпляром сегмента.

В ИМД существуют также следующие понятия:

• брат - узел, имеющий того же родителя, что и другой узел;

• ветвь - узел дерева вместе со всеми его отпрысками, отдаленными потомками и родительскими источниками;

• лист - узел, у которого нет отпрысков;

• обход дерева - процесс обследования по очереди каждого узла дерева в иерархической модели данных, и пр.

Принцип построения IMS легок для понимания. Иерархия базы данных напоминает структуру компании или генеалогическое дерево.

Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".

В СУБД IMS отношения предок/потомок были реализованы в виде физических указателей от одной записи к другой, вследствие чего перемещение по базе данных происходило быстро. Поскольку структура данных в этой СУБД отличалась простотой, IMS могла размещать записи предков и потомков на диске рядом друг с другом, что позволяло свести к минимуму количество операций записи-чтения.

Существенно то, что физическая организация БД в этом случае такова, что выбрать конкретные сведения об объектах можно, лишь пройдя всю цепочку групп (сегментов) сверху вниз (путь на иерархическом дереве). Данная схема наиболее проста, но не лишена очевидных недостатков.

В частности, в связи с иерархичностью связей объектов в реальном мире в подобных БД необходимо создавать и поддерживать несколько иерархических отношений, что нарушает основную идею модели данных. Далее, рассматриваемая модель обладает рядом "парадоксов", наиболее очевидным из которых является "парадокс исключения". Удаление из БД некоторого вышестоящего сегмента приводит к автоматическому удалению и всех зависимых (порожденных сегментов).

Иерархическая МД в настоящее время представляет лишь исторический интерес, хотя ряд ее элементов и поддерживается некоторыми из рассматриваемых далее конкретными СУБД.

Сетевая модель данных (модель CODASYL)

В предложенной CODASYL модификации иерархической модели одна запись могла участвовать в нескольких отношениях предок/потомок. В сетевой модели такие отношения называются множествами. В 70-е гг. независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как 1DMS компании Cullinet, Total компании Cincom, которые приобрели большую популярность. Сетевые БД обладали рядом преимуществ:

• Гибкостью. Множественные отношения предок/потомок позволяют сетевой БД хранить данные, структура которых сложнее обычной иерархии.

• Стандартизованностью. Появление стандарта CODASYL.

• Быстродействием. Вопреки своей сложности, сетевые БД достигали быстродействия, сравнимого с быстродействием иерархических БД. Множества были представлены указателями на физические записи данных, и в некоторых системах администратор мог задать кластеризацию данных на основе множества отношений.

• Недостаток - жесткость БД, наборы отношений и структуру записей приходилось задавать заранее. Изменение структуры данных означало перестройку всей БД.

7. Проектирование фактографических БД: реляционная модель данных, модель "сущность-связь" (Entity-Relationship, ER).

Реляционная модель данных (РМД)

Данные в реляционной модели хранятся в виде таблиц. Таблица состоит из заголовка (столбцов или атрибутов) и строк или записей (кортежей). Поле таблицы - это значение, лежащее на пересечении строки и столбца. Множество значений, которые может принимать атрибут, называется домен атрибута. Реляционные таблицы называются отношениями. (Relation – отношение). Число столбцов или атрибутов таблицы называется степенью отношения. Число строк или записей таблицы называется мощностью отношения. Данные в реляционной модели должны удовлетворять следующим требованиям, которые называются внутренними ограничениями модели:

• В таблице каждая запись должна быть .

• Конкретные данные должны храниться только в одной таблице.

• Число отношений в модели должно быть оптимальным.

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

Важным отличием РМД от ИМД является возможность применения формального аппарата, описывающего преобразование и обработку данных в РМД - реляционной алгебры.Операндами реляционной алгебры являются отношения, как постоянные, так и переменные. Операции реляционной алгебры включают ледующие преобразования отношений.

А.Теоретико-множественные операции над несколькими подобными (имеющими одинаковую структуру - число атрибутов, их имен, домен и т.д.), отношениями, в том числе объединение, пересечение, разность.

Б. Операции над одним отношением: селекция или построение отношения-результата из отношения-источника путем отбора экземпляров, удовлетворяющих некоторому критерию отбора и проекция или построение результирующего отношения путем отбора части атрибутов всех экземпляров исходного отношения.

В. Операции над несколькими различными отношениями.

Реляционная модель данных достаточна для моделирования многих предметных областей. Но она имеет и свои недостатки:

• В РМД нет достаточных средств для представления смысла (семантики) предметной области.

• В РМД нет средств для представления зависимостей между данными (отношениями)

• Для многих приложений не достаточно представления данных в виде плоских таблиц

• РМД не предлагает никакого аппарата для разделения сущностей и связей.

Указанные недостатки привели к созданию семантических моделей данных (СМД). На практике СМД используются на первой стадии проектирования БД. Одной из наиболее популярных СМД является модель «сущность-связь» (entity-relationship) или ER-модель.

Модель "сущность-связь" представляет собой обобщение РМД путем разделения отношений, описывающих предметную область на две группы - сущностей и связей.

Сущность(Entity)является первичным,устойчивым объектом, описываемым некоторой совокупностью атрибутов.

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

При проектировании БД на основе ER-моделей исп-т ER-диаграммы. Модель ER является удобным средством описания предметной области перед тем, как перейти к ее представлению в реляционной модели данных.

Атрибут сущности – это свойство сущности, служит для уточнения, классификации, идентификации, числовой характеристики или выражения состояния сущности. Имена атрибутов пишутся под именем сущности строчными буквами.

Существует три типа свойств: Ключевые свойства позволяют различать экземпляры сущности. Дифференциальные свойства содержат смысл сущности, то, что отличает сущность от другой сущности. Валентные свойства используются для связи с другими сущностями.

Различают три основных типа абстрагирования и соответственно три вида операций над сущностями: агрегация, обобщение, ассоциация. Соответственно обратные логические операции над сущностями - это декомпозиция, специализация и индивидуализация.

ER-модели широко применяются как при ручном, так и при автоматизированном проектировании баз данных. При этом в некоторых системах, например, в системе IDEF, отсутствуют сложные понятия (агрегаты, ассоциации, обобщенные понятия), они заменяются связями. В разных системах применяются различные обозначения мощности связей и классов членства (обязательности связи) и т.д.

На основе созданной ER-схемы строится реляционная модель базы данных. Порядок построения реляционной модели из ER-схемы следующий:

• Каждая простая сущность отображается в таблицу, при этом имя сущности становится именем таблицы.

• Каждый атрибут сущности становится столбцом таблицы с тем же именем, при этом выбирается более точный формат значения атрибута. Ключевые свойства преобразуются в первичные ключи таблицы.

• Столбцы, соответствующие необязательным атрибутам могут содержать неопределенные значения, обязательные столбцы не могут.

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

• Связи один-ко-одному, один-ко-многим преобразуются во внешние ключи. Делается копия уникального идентификатора с конца связи «один», которая мигрирует в таблицу на конце связи «много», где и становится внешним ключом.

7. Сущность структурного подхода. Структурная модель предметной области. Процессный подход в описании предметной области

Модель – это наиболее полное и точное описание системы, которое позволяет получить ответы на вопросы относительно системы. Необходимость изучения реальных систем и создания моделей систем потребовала разработки соответствующей методологии.

Структурный анализ (Structured analysis) – это основанная на моделировании, ориентированная на процессы техника, используемая для анализа существующей системы, определения требований новой системы или того и другого. Для описания работы организации необходимо построить модель бизнес-процессов, адекватную предметной области. Эта модель в дальнейшем послужит основой проектирования ИС данной организации.

К моделям предметных областей предъявляются следующие требования:

• формализация, обеспечивающая однозначное описание структуры предметной области;

• понятность для заказчиков и разработчиков, основанная на применении графических средств отображения модели;

• реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

• обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

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

Структурный аспект предполагает построение:

• объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

• функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

• структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

• организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;

• технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.

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

• на внешнем уровне (определении требований);

• на концептуальном уровне (спецификации требований);

• на внутреннем уровне (реализации требований).

Процессный подход в описании предметной области

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

Процессный подход предполагает смещение акцентов от управления отдельными структурными элементами на управление сквозными бизнес-процессами, связывающими деятельность всех структурных элементов. Каждый деловой процесс проходит через ряд подразделений, т. е. в его выполнении участвуют специалисты различных отделов компании. Чаще всего приходится сталкиваться с ситуацией, когда собственно процессами никто не управляет, а управляют лишь подразделениями. Более того, структура компаний строится без учета возможностей оптимизации деловых процессов, обеспечивающих необходимые функции. Процессный подход позволяет устранить фрагментарность в работе, организационные и информационные разрывы, дублирование, нерациональное использование финансовых, материальных и кадровых ресурсов. Процессный подход к организации деятельности предприятия предполагает:

• широкое делегирование полномочий и ответственности исполнителям;

• сокращение уровней принятия решений;

• сочетание принципа целевого управления с групповой организацией труда;

• повышенное внимание к вопросам обеспечения качества;

• автоматизацию технологий выполнения бизнес-процессов.

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

Процессная модель экономического объекта должна строиться с учетом следующих положений:

1. Верхний уровень модели должен отражать только контекст деятельности (т.е., контекстная диаграмма должна отражать взаимодействие моделируемого предприятия с внешним миром).

2.На втором уровне должны быть отражены тематически сгруппированные бизнес-процессы предприятия и их взаимосвязи в виде основных направлений деятельности.

3.Каждое из направлений деятельностей должно быть детализировано на бизнес-процессы.

4. Детализация бизнес-процессов осуществляется посредством бизнес– функций.

5. Бизнес-функции описываются последовательностью элементарных технологических операций.

6.Описание элементарной операции осуществляется с помощью миниспецификации.

7. Метод функционального моделирования SADT. Методология IDEF0.

Метод функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этой методологии основываются на следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.

Методология функционального моделирования IDEF0 Основные элементы и понятия IDEF0

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги”, а не "производство услуг”).

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление” (Control);

Левая сторона имеет значение "Вход” (Input);

Правая сторона имеет значение "Выход” (Output);

Нижняя сторона имеет значение "Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1. Функциональный блок.Вторым "китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название "входящей”, "исходящей” или "управляющей”. Кроме того, "источником” (началом) и "приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом "источником” может быть только выходная сторона блока, а "приемником” любая из трех оставшихся.

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

При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображен функциональный блок "Обработать заготовку”.

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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