1.	АИС как объект разработки.	3
1.	АИС (АС) как изделие.	3
2.	Требования к изделиям:	3
3.	Реализация АС-изделия на этапах ЖЦ.	3
4.	АС как промышленно - техническое изделие	4
5.	ИВС как объект разработки:	4
6.	Интегрированная база данных - констатация идеи.	4
7.	За идеей - классическая методология проектирования.	4
8.	За методологией - мастерская инструментов проектирования БД.	5
9.	Причины появления новых требований	5
10.	Что нужно от баз данных для ответа на новые требования	6
11.	Вошедшие в практику новые инструменты мастерской проектировщика	6
12.	К новым подходам в методах проектирования БД	7
2.	Тема 1. Типы информационных систем - системы обработки операций, информационные системы управления, системы поддержки решений, экспертные системы. Их назначение и решаемые задачи.	8
3.	Тема 2. Классификация архитектур информационных систем. Их достоинства и недостатки. Области применения.	8
4.	Тема 3. Понятие данных и информации. Атрибуты информации. Информация в организации. Категории пользователей информационных систем.	10
5.	Тема 4. Определение информационной системы. Жизненный цикл разработки ИС.	11
6.	Жизненный цикл и характеристики. Критерии оценки качества. Проблемы разработки.	14
6.1	Составные части ПС	14
6.2	Классификационные признаки ПС	14
6.3	Жизненный цикл и характеристики ПО	15
6.4	Стадии создания АС по ГОСТ 34.601-90	15
6.5	Характеристики ПС	15
6.6	Проблемы разработки ПС.	15
7.	Методологии и методы разработки ИПО.	16
7.1	Методологии разработки ПС.	16
8.	Этапы разработки ИПО. Инструментальные средства реализации ИПО.	18
8.1	Инструментальные средства реализации ИПО.	21
8.2	НОВОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ	22
8.2.1	Интегрированная база данных	22
8.2.2	Классическая методология проектирования	22
8.2.3	КАСКАДНАЯ СХЕМА	23
8.2.4	Мастерская инструментов проектирования БД	24
8.2.5	Причины появления новых требований	25
8.2.6	Об использовании классических методов проектирования ИС в настоящее время	25
8.2.7	КАЧЕСТВЕННЫЕ ИЗМЕНЕНИЯ В ИТ	25
8.2.8	BPR (Business Process Reengineering) - Реконструкция Бизнес - Процессов	26
9.	Тема 5. Методология структурного анализа и проектирования.	28
10.	Тема 6. Диаграмма потока данных (ДПД). Назначение. Символы ДПД. Правила построения и принципы создания ДПД. Контекстная диаграмма, диаграммы уровня 1 и 2. Понятие функциональных примитивов. Документирование и проверка модели.	28
11.	Методы процессно-ориентированного анализа.	32
11.1	ПРОВЕДЕНИЕ АНАЛИЗА МЕТОДОМ HIPO	36
11.2	ПРОВЕДЕНИЕ АНАЛИЗА НА ОСНОВЕ МЕТОДОЛОГИИ SADT	39
11.2.1	Реализация методологии SADT в программном пакете Design/IDEF	39
11.2.2	Анализ программных систем на основе программного пакета Design/IDEF	42
12.	Тема 7. Методология IDEF0 - назначение и правила формирования.	53
13.	Тема 8. Методология IDEF1X - назначение. Правила формирования сущности, сущности зависимые и независимые от идентификатора.	53
14.	Тема 9. Семантика отношений связи. Мощность отношений связи. Идентифицирующее и не идентифицирующее отношение. Отношения категоризации. Правила отношений категоризации.	54
15.	Тема 10. Семантика атрибутов. Правила атрибутов. Первичные и альтернативные ключи. Правила первичных и альтернативных ключей. Правила внешних ключей	55
15.1	Последовательное использование моделей	57
15.2	Адаптивные подходы к организации проектирования ИС	60
15.2.1	ДЕСЯТЬ ЗАПОВЕДЕЙ	62
16.	МЕТОДЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ	63
16.1	ПРЕИМУЩЕСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА	65
16.2	НЕДОСТАТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА	65
16.3	ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА	65
17.	ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ	66
18.	ФУНКЦИИ И ТИПОВАЯ ОРГАНИЗАЦИЯ СУБД	67
19.	КОМПЛЕКС ПОДДЕРЖКИ БД	68
20.	ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ С АРХИТЕКТУРОЙ “КЛИЕНТ - СЕРВЕР”	74
20.1.1	АКТИВНЫЙ СЕРВЕР	74

ТЕМАТИЧЕСКИЙ ПЛАН
1. АСОИУ как объект разработки.
2. Жизненный цикл и характеристики ИПО АСОИУ. Проблемы разработки ИПО.
3. Методологии и методы разработки ИПО.
4. Этапы разработки и инструментальные средства реализации ИПО.
5. Представление знаний о предметной области. Инфологическое проектирование баз данных.
6. Создание многоуровневых моделей данных. 
7. Методы процессно-ориентированного анализа.
8. Структурный функциональный анализ.
9. Проектирование реляционных баз данных. 
10. Функции и типовая организация СУБД. Методы выбора СУБД.
12. Методы процессно-ориентированного проектирования.
13. Основы объектно-ориентированного анализа.
14. Основы объектно-ориентированного проектирования.
14. Особенности проектирования баз данных с архитектурой "клиент-сервер". Серверы баз данных. 
15. Особенности проектирования распределенных баз данных.
16. CASE -технологии разработки ИПО. Средства быстрой разработки ИПО.
17. Современные системы управления базами данных. Объектно-ориентированные базы данных.

1.	
1.	АИС как объект разработки.
1.	АИС (АС) как изделие.
Продукция является изделием (по ЕСКД), если она:
•	социально значима,
•	определены конкретные потребители,
•	определены потребительские свойства продукции (показатели качества),
•	определены критерии суммарной эффективности для потребителя и производителя.
2.	Требования к изделиям:
•	Социальная значимость - общественная полезность для пользователей.
•	Осознание потребителями полезности изделия в их деятельности.
•	Реализуемость изделия в нужные сроки при имеющихся в наличии ресурсах.
•	Обеспечение потребителю возможности практической доступности к изделию и его освоения.
•	Предоставление потребителю изделия гарантий его надежности и качества (эффективности).
•	Обеспечение возможности модификации изделия, развития и адаптации к различным условиям использования.
3.	
Система поддержки

Система внедрения

Объектная
система

Система
обслуживания

Система освоения

Система испытания

Система разработки

Система производства

Внутренние обеспечения

Внешние обеспечения

Реализация АС-изделия на этапах ЖЦ.

Система сопровождения

Внешние обеспечения		Объектная система		Внутренние обеспечения	
		Система обслуживания			
	Система освоения	Система поддержки		
	Система сопровождения	Система внедрения		
Система разработки	Система испытания	Система производства	

4.	АС как промышленно - техническое изделие

              АИС                    ИВС                   ИАК                   ПМК                КТС

                ЧМС								        ПТК
АИС		ИВС		ИАК		ПМК		КТС	
									
ЧМС								ПТК	

5.	ИВС как объект разработки:
•	Компоненты (элементы),
•	Набор однородных компонент (Обеспечения),
•	Набор разнородных компонент,
•	Комплексы,
•	Подсистемы,
•	АС как система,
•	Компоненты - внутренние обеспечения АС:
•	ИО - информационное,
•	АО - аналитическое,
•	ПО - программное,
•	МО - методическое,
•	КО - кадровое,
•	ОО - организационное,
•	ПрО - правовое,
•	ЛО - лингвистическое,
•	ТС - техническое,
6.	Интегрированная база данных - констатация идеи.
Сформировалось понимание интегрированной БД как общего информационного ресурса организации.
Хранимые данные стали аналогичны большому компьютеру, который одновременно используется многими пользователями с различными целями и должен быть все время работоспособен.
7.	За идеей - классическая методология проектирования.
Проектные этапы: 
•	сбор сведений о ПО (анализ потребностей и описание ПО с использованием так называемых "процессного" подхода и "непроцессного", подхода);
•	выбор языка представления т.н. "семантической" модели для фиксации сведений о ПО, их последующего анализа и синтеза модели БД;
•	анализ собранных сведений о ПО: классификация, формализация и интеграция структурных элементов описания ПО, формализация как структурных, так и процедурных ограничений целостности элементов в будущей модели ПО, определение динамики экземпляров объектов ПО;
•	синтез концептуальной модели БД: проектирование целостной концептуальной схемы БД на выбранном языке семантического моделирования;
•	выбор конкретной модели данных и СУБД для реализации БД;
•	проектирование логической схемы БД для выбранной СУБД (называющееся также "проектирование реализации");
•	разработка физической структуры БД включая размещение БД по узлам;
•	разработка технологии и процедур начального создания и заполнения БД;
•	разработка технологии и процедур сопровождения БД;
•	разработка универсальных программ доступа к БД и соответствующих интерфейсов пользователей;
•	информационное обеспечение разработки конкретных программ обработки данных:
•	обеспечение метаинформацией, данными контрольных примеров и др.;
•	получение обратной связи от разработчиков прикладных программ и пользователей ИС о полноте и эффективности организации БД;
•	тестирование БД, ее развитие и улучшение (настройка) ее структуры.
Использовалась дисциплина т.н. структурного анализа при проектном подходе "сверху вниз". Структурность связывается с применением иерархических структур для детализации данных и функций и соответствующих, достаточно "жестких" проектных процедур.
Проектная схема получила название "каскадной". Она хорошо согласована с аналогичной схемой проектирования программного обеспечения.
8.	За методологией - мастерская инструментов проектирования БД.
Наличие целостной методологии проектирования позволило позаботиться о систем автоматизации проектирования БД. Этому способствовало использование активных интегрированных словарей-справочников данных (DD/D, Data Dictionary/Directory).
Возникли системы CASE  - системы для структурного проектирования БД и связанных с ними ИС, ориентированные на модели данных, реализованные в различных СУБД.
Наибольшую популярность получили CASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D переименовался в CASE-репозиторий проектируемой ИС.
  Два основных направления развития CASE-систем и технологий проектирования:
 CASE-системы для проектирования собственно БД  и интегрированные инструменты, позволяющие и проектировать БД, и разрабатывать использующие их прикладные программы. 
Часто интегрированность функций приводит к сращиванию CASE-системы с одной из СУБД, на которую ориентированы CASE - средства разработки прикладных программ.
Итак, Классическая Мастерская проектировщика БД включает совокупность классических структурных методов проектирования, набор соответствующих инструментов моделирования, реализации, загрузки и сопровождения БД, а также "каскадную" организационную схему выполнения этих работ по принципу "сверху вниз".
9.	Причины появления новых требований
Появились новые возможности БД и способы их проектирования. Список типов хранимых и обрабатываемых данных расширился до возможных пределов, определяемых самым общим нормативным значением понятия "данное".
В корпоративные БД включаются не только неформатированные элементы и полнотекстовые фрагменты, но также БД с геоинформацией, мультимедийные БД, и это не исчерпывающий перечень.
Если ИТ были одним из толчков к такому развитию ситуации, то они оказались призваны и для того, чтобы обеспечить успех и саму возможность планируемых реконструкций.
 Возникли новые требования к архитектуре корпоративных ИС, как следствие - новые требования к корпоративным БД 
Как саму ИС нельзя рассматривать в отрыве от ее пользователей, так и новое проектирование должно рассматриваться как интеграция трех составных частей: требований бизнес-реинжиниринга, человеческого фактора и методов новых ИТ. Реальное объединение этих трех составных частей, каждая из которых приобрела в 90-е годы качественно новое наполнение, создало начала того, что можно назвать Н.С.П.
10.	Что нужно от баз данных для ответа на новые требования
Обеспечение максимальных возможностей для каждого работника, то есть поддержка выполнения всех бизнес-функций тем самым работником, который и получает конечный результат.
Со стороны ИС, БД и СУБД для этого требуется:
•	обеспечение средств доступа ко всем необходимым данным с использованием распределенных БД,
•	средств репликаций данных,
•	управления событиями в данных и процессах обработки транзакций;
•	использование архитектуры и программных средств хранилища данных,
•	средств Оперативной Аналитической Обработки Данных (OLAP),
•	применение средств быстрой разработки приложений (RAD) для создания "ИС руководителя" (EIS), средств поддержки принятия решений (DSS) на основе хранилища данных, OLAP и RAD/EIS;
•	применение средств DSS на основе анализа БД прецедентов, а также методов логического вывода, нейронных сетей и нейрокомпьютерных технологий и др.;
•	предложение единого интерфейса пользователя для работы с разными компонентами данных и приложений, использование в этом интерфейсе средств, повышающих простоту поиска информации и обращения к конкретным прикладным функциям, например функции геоинформсистем, гипертекстовые, естественного языка, речевого ввода.
•	разработка концепции и структуры корпоративной базы данных для новой ИС, реализация структуры БД, предполагающая снятие (существенное уменьшение) ограничений на ее развитие, в том числе при смене функций или функциональных компонентов обработки информации:
•	применение методов компонентного проектирования предметных БД как для операционных БД, так и для исторических БД хранилищ данных, архивов документов, геоинформационных и иных данных;
•	разработка процедур компонентного изменения корпоративной БД при изменении бизнес-процедур, видов деятельности, применяемых приложений и географического размещения предприятия;
•	постоянная актуализация понятийной модели деятельности предприятия для учета новых понятий, возникающих при изменении прикладных компонентов на функционально сходные и при изменении видов деятельности предприятия, и построение на этой основе новых интерфейсов между компонентами ИС;
•	динамическое администрирование фрагментами распределенной корпоративной БД при изменении частоты их использования, при модификации их структуры и при изменении их размещения.
11.	Вошедшие в практику новые инструменты мастерской проектировщика
Язык SQL, бывший в 80-м году всего лишь одним из языков, представляющих реляционную модель, стал реальным стандартом не только реляционной модели данных, но и промышленных СУБД.
В реальных разработках наиболее распространенных организационно-производственных ИС в большинстве случаев или в большей части объемов работ произошла замена средств разработки с SQL во включающем 3GL-языке или языка 4GL процедурного типа на языки и инструменты 4GL с оконным интерфейсом на основе управления через меню и с использованием элементов концепции объектно-ориентированного программирования (и сохранением возможностей выхода на SQL и процедурный язык).
Возникли практически работающие стандарты de facto интероперабельной работы с данными, в первую очередь - стандарт ODBC.
Мультиплатформенность стала нормой, многопротокольность коммуникаций для распределенных БД реализуется на основе стандартов и интероперабельных мониторов транзакций, поддерживается "интернационализация" хотя бы в части настроек на таблицы национальных кодировок данных.
Вошли в практику новые структуры и типы данных, новые операции над данными: неформатированные элементы, полнотекстовые БД и их обработка, ГИС-данные, мультимедийные БД, гипертекстовые распределенные БД, распределенная обработка и обработка, доставляемая вместе с объектом на вход ИС.
На практике наблюдаются шаги реальной интеграции упомянутых структур и операций.
Меняется подход к выбору СУБД, в первую очередь - для проектирования корпоративных БД, эксплуатация и развитие которых планируются как минимум на несколько лет.
Все более используются экономические основания и критерии для выбора СУБД.
12.	К новым подходам в методах проектирования БД
Как ответ на новые требования можно рассмотреть рекомендации к новым методам и инструментам проектирования БД. (Конечно, в предположении, что все новое есть ранее кем-то уже обнаруженное старое.)
•	Об исключении избыточности в данных
•	Проблема консервации проблем
•	Компонентная открытость и смысловая интероперабельность
•	Разработка понятийных моделей и ССК
•	Понятийные модели и последующие проектные работы:
•	разработка совокупности разных предметных ИМ с выделением общих информационных сущностей
•	разработка функциональных моделей разных типов
•	разработка семантически богатых средств поддержки пользователя и др.
•	Технологическая открытость
•	Проблемы объемов, временных характеристик и физического проектирования
•	Проблема границ применимости основных методов проектирования
•	В ходе исследований и практического проектирования должны быть определены границы применимости двух концепций: 
•	проектирование БД как объекта, осознанно отделенного от прикладных программ;
•	и объектно-ориентированное проектирование, в котором объект инкапсулирует и данные, и методы их обработки.

2.	Тема 1. Типы информационных систем - системы обработки операций, информационные системы управления, системы поддержки решений, экспертные системы. Их назначение и решаемые задачи.
Системы обработки операций (Transaction Processing System - TPS) – это автоматизированные версии ручных процессов, выполняемых в организациях. Эти системы автоматизируют обработку операций, которые являются рабочими событиями в деятельности организации.
В такой системе каждая операция может быть позже отменена или откорректирована. Что самое важное для организации – расчет количества и объема операций для любого периода времени. Система также обеспечивает официальные документы, которые обрабатываются другими подсистемами.
Информационные системы управления (Management Information System - MNS) предназначены для обработки данных, доступных через TPS,и преобразования их в форму для менеджеров обычно в формате отчета. Итоговые отчеты представляют всю деятельность по данному периоду времени, по географическому региону или другой классификации в агрегированном виде. Отчеты об исключительных ситуациях представляют информацию в случае, если она находится за пределами нормальных значений. Отчеты по требованию предоставляются только, когда менеджер хочет или должен проверить состояние деятельности. Точное содержание отчетов по требованию может изменяться в зависимости от потребности менеджера. Регламентные отчеты обеспечивают определенную информацию, если необходимо, содержание которой может изменяться в зависимости от потребности менеджера.
Системы поддержки решений (Decision Support Systems - DSS) предназначены для помощи организации в подготовке принятия решения. Обычно такая система имеет три основных составляющих: базу данных, базу моделей и модуль взаимодействия. База данных содержит данные, предназначенные для принятия решения. База моделей содержит некоторое количество моделей, которые могут использоваться для анализа ситуации принятия решения. Модуль диалога обеспечивает взаимодействие в процессе принятия решения конечного пользователя.
Применяя данные и варианты решений с использование моделей, ЛПР может оперативно сравнивать возможные решения проблемы. DSS позволяет менеджеру проверять или предлагать различные решения, а также изучать результаты принятия решений с использованием различных моделей
Экспертные системы (Expert Systems - ES) пытаются представлять и манипулировать знаниями. Знание – это приобретенное через опыт глубокое и всестороннее обучение. Экспертные системы основаны на принципах исследования искусственного интеллекта. Обычно пользователи общаются с ES посредством диалога, в течении которого ES задает вопросы, а пользователь дает ответы, которые используются для выбора применяемого правила. Данная процедура заканчивается рекомендацией, основанной на использовании правил.
3.	Тема 2. Классификация архитектур информационных систем. Их достоинства и недостатки. Области применения.
Персональная ИС. Предназначена для удовлетворения персональных информационных потребностей. Такие системы разрабатываются как приложения рабочего стола с использованием системы управления базами данных типа Access, Paradox, FoxPro и возможностей этих систем, ориентированных на помощь в создании приложений для конечного пользователя. Эти системы отличает простота информационной модели и практическое отсутствие бизнес – логики – последовательности процедур, ориентированных на обработку информации в базах данных с целью получения информации для дальнейшего анализа и принятия решений или выполнения производственной деятельности.
ИС для малого бизнеса. Обычно такие приложения реализуют как приложения рабочего стола, но используют более сложную модель и развитую бизнес – логику. К таким системам относятся «Системы бухгалтерского учета», «Системы учета товаров на складе» и т.п.
ИС для автоматизации обработки информации больших подразделений (10 – 15 рабочих мест). В таких подразделениях, называемых рабочими группами, обеспечивается обмен данными в локальной сети путем предоставления различных прав доступа на распределенные информационные ресурсы, размещенные на рабочих станциях.
Корпоративные информационные системы. В ИС такого рода информации хранится в локальной сети на выделенном файл – сервере, к которому осуществляется доступ с рабочих станций. В процессе обработки все необходимые данные передаются с файл – сервера на рабочие станции по локальной сети и, тем самым создают большой трафик. Эффективность использования таких систем зависит от существующей нагрузки на сеть и характера решаемых задач.
ИС по технологии клиент / сервер. В ИС такого типа данные по запросу от клиентского программного обеспечения обрабатываются непосредственно на сервере, и лишь результат возвращается на рабочую станцию, создавая незначительную нагрузку на сеть. Полученные от сервера данные клиентское ПО представляет пользователю в виде, удобном для дальнейшего применения. Высокая эффективность такой архитектуры ИС определяется использованием мощных многопроцессорных вычислительных комплексов серверов и многопоточная реализация сервера баз данных. Основные преимущества таких ИС:
- рабочая нагрузка естественным образом распределена на множестве компьютеров;
- пользователи могут легко совместно пользоваться данными;
- чувствительные к повреждениям и разрушениям данные могут быть надежно защищены в централизованном порядке.
Минусами архитектуры клиент / сервер можно назвать:
- необходимо принимать решение о распределении задач между клиентом и сервером;
- для каждого типа задач необходимо выбрать подходящее аппаратное обеспечение;
- необходимо строго контролировать переход на новые версии программного обеспечения;
- изменения концептуальной модели базы данных могут повлиять на всех клиентов;
- настройка и администрирование могут оказаться значительно сложнее чем в централизованной архитектуре.
Интернет – приложение. Использование технологий WWW для обеспечения доступа к каким-либо информационным ресурсам подразумевает существование следующих компонентов:
1. IP - сети с поддержкой базового набора услуг по передаче данных с единой политикой нумерации и маршрутизации, работающим сервисом имен DNS.
2. Выделенного информационного сервера - WWW-сервера, обеспечивающего предоставление гипертекстовых документов через IP - сеть в ответ на запросы WWW - клиентов.
Передаваемые гипертекстовые документы оформляются в стандарте HTML - языке описания гипертекстовых документов. Эти документы могут храниться либо в статическом виде, либо динамически компоноваться в зависимости от параметров запроса специальным программным обеспечением. Для динамической компоновки HTML-документов WWW-сервер использует специальным образом оформленные программы - CGI-программы (Common Gateway Interface), запускаемые WWW-сервером в ответ на запрос WWW - клиента. Эти программы, обрабатывая запрос, просматривают содержимое БД и создают выходной HTML-документ, возвращаемый клиенту (рис.1).

Рис.1. Технология обработки активных страниц
Это решение эффективно для больших баз данных со сложной структурой с поддержкой операций поиска. Показаниями также являются частое обновление и невозможность синхронизации преобразования БД в статические документы с обновлением содержимого. Возможно выполнение изменения БД с помощью WWW- интерфейсов. Выбор программных средств достаточно широк - языки программирования, интегрированные средства типа генераторов отчетов. Для СУБД с внутренними языками программирования существуют варианты использования этого языка для генерации документов (Oracle). В настоящее время для реализации CGI широко используются средства COM+, CORBA, Cold Fusion, PERL, PHP и другие.
4.	Тема 3. Понятие данных и информации. Атрибуты информации. Информация в организации. Категории пользователей информационных систем.
Данные – это факты или наблюдения о событии или сущности (конкретной или абстрактной, внешней или внутренней).
Информация – обработанные данные, которые организованы и приготовлены в форме, подходящей для принятия решения.
Информация предполагает взаимодействие и получение сведений или знаний. Она информирует и уведомляет, удивляет и стимулирует, уменьшает неуверенность, показывает дополнительные альтернативы, помогает устранить несоответствие или недостаточность знаний, а также влияет на персонал и стимулирует их к действию. Особенно в бизнесе информация должна выдавать сигналы раннего предупреждения и предвосхищать будущее.
Информация представляет собой данные, изображения, текст, документы и звук, часто неразрывно переплетающиеся, но всегда организованные в существенном контексте. Термин "данные" будет использоваться повсюду в тексте, чтобы охватить все компоненты информации, но важно помнить, что информация - нечто большее, чем простые числа.
Чтобы быть полезной, информация должна обладать характеристиками, описанными ниже. Это ключевые атрибуты информации.
1. Точность означает, что информация свободна от ошибок и пристрастности. В некоторых организациях, например, мы обнаруживаем, что менеджеры среднего звена обладают большим влиянием на решения высшего руководства, поскольку они выступают в качестве "привратников" при прохождении информации между средним, нижним и верхним уровнем управления. Такая власть над информацией позволяет менеджерам среднего звена манипулировать информацией или искажать ее, сообразуясь с собственными интересами.
2. Проверяемость означает, что два квалифицированных специалиста могут создать одну и ту же информацию независимо друг от друга. Часто организации применяют независимые источники информации, чтобы производить и распространять ее непосредственно на каждом уровне управления, уменьшая тем самым тенденцию пристрастности.
3.Своевременность. Доставка информации получателям в рамках необходимых временных границ является другим ключевым атрибутом качества информации. "Вчерашняя газета" сегодня может служить примером отклонения от стандарта доставки информации "в рамках необходимых временных границ". Своевременность просто означает, что получатели могут получить информацию, когда им это нужно.
4.Актуальность. Определяется полнотой ответа на вопросы получателя «что, почему, где, когда, кто, и как?» Информация увеличивает осведомленность или ценна для ЛПР (лицо, принимающее решение) за счет уменьшения неопределенности, повышения возможности в предсказании, или подтверждая или корректируя более ранние ожидания. Более того, информация, актуальная для одного получателя, не обязательно актуальна для другого.
5. Понятность. Информация должна быть предоставлена в ясном и понятном формате. То есть информация точно отражает значение данных, на которых она основана, и дает точную картину ее получателю, который может затребовать представление в графической, а не в табличной форме. Потребитель информации, ЛПР, должен делать свою часть работы, используя свою квалификацию, и как можно меньше времени тратить на выяснения и уточнения.
6. Полнота. Информация должна содержать все важные сведения, которые ожидают от нее пользователи.
Отсутствие любого из этих атрибутов приводит к тому, что ИС (информационные системы) отторгается организацией. Для обеспечения этих свойств необходимо принимать специальные меры при разработке и эксплуатации ИС, соответственно, затрачивая определенные средства на поддержание полезности информации.
5.	Тема 4. Определение информационной системы. Жизненный цикл разработки ИС.
Информационная система – это объединение людей, данных, процессов, интерфейсов, сетей и информационных технологий, которые взаимодействуют для целей поддержки и улучшения ежедневных операций, а также для обеспечения потребностей поддержки подготовки и принятия решения руководства и пользователей.
Жизненный цикл - это непрерывный процесс, который начинается с момента принятия решения о необходимости ее создания и заканчивается в момент ее полного изъятия из эксплуатации.
Структура ЖЦ ПО базируется на трех группах процессов:
1)  основные процессы ЖЦ ИС (приобретение, поставка, разработка, эксплуатация, сопровождение);
2)  вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
3) организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Основные этапы жизненного цикла разработки ИС:
1. Анализ системы.
- первоначальное исследование;
- изучение системы;
- осуществление исследований;
- определение информационных нужд и требований к системе;
- результат - требования к системе.
Суть этапа анализа системы - сбор информации, необходимой для приобретения или разработки новой системы. Разработка системы начинается с предварительного определения основных проблем и задач ИС, а также функций, с помощью которых разрешаются выявленные проблемы. Описание функций выполняется на языке производственных (описание процессов предметной области), функциональных (описание формы обрабатываемых документов) и технических (аппаратное, программное, лингвистическое обеспечение) требований. Во многих организациях в результате предварительного изучения ситуации готовится формальный запрос на проектирование и разработку ИС. Чтобы максимизировать использование ограниченных ресурсов, требования к разработке системы ранжируются по степени важности. После начального этапа производится исследование используемой в данный момент ИС, чтобы определить ее природу, нацеленность и понять сильные и слабые стороны, определяются и документируются информационные потребности пользователей системы и менеджеров. Все это используется для разработки и документирования требований к системе. Далее требования к системе используются для выбора между разработкой и приобретением ИС. Руководству предоставляется отчет об анализе системы.
2. Концептуальная разработка.
- оценка альтернатив;
- разработка спецификаций;
- результат - требования концептуальной разработки.
На этапе концептуальной разработки компания решает, как удовлетворить свои потребности. Первая задача - определить и оценить возможные альтернативы. Если одна из альтернатив принята руководством для разработки, то формируется план разработки ИС, содержащий следующие ключевые элементы:
- определение масштаба проекта, в рамках которого анализируются основные функции и взаимодействие с внешними системами;
- более полное изучение формулировки проблем;
- уточняются необходимые процессы обработки информации и ограничения;
- рассматривается ресурсное обеспечение разработки: люди, время, финансовые средства для разработки и функционирования ИС. Ресурсное обеспечение исчисляется по аналогии с известными разработками;
- готовится график выполнения различных этапов проекта.
В заключение этапа анализа готовятся детальные спецификации, описывающие логическую модель ИС: схемы и структуры данных всех уровней, модульность ИС, документацию логической структуры, скрипты для создания объектов БД.
3. Физическая разработка.
- разработка выходов;
- разработка базы данных;
- разработка входов;
- разработка программ;
- разработка процедур;
- разработка методов контроля;
- результат - разработанная система.
Физическая разработка - это перевод общих, ориентированных на пользователя требований, сформулированных на этапе концептуальной разработки, в детальные спецификации, которые могут быть использованы при кодировании и тестировании компьютерных программ. Разрабатываются входные и выходные документы, пишутся компьютерные программы, создаются файлы, разрабатываются процедуры, в новую систему встраиваются способы ее контроля. Разработанные компоненты тестируются и отлаживаются.
4. Внедрение.
- разработка плана внедрения и перехода на новую ИС;
- установка оборудования и программ;
- обучение персонала;
- тестирование системы;
- полное документирование;
- переход от старой к новой системе;
- подстройка системы и обзор внедрения;
- результат - работающая система.
Внедрение - это этап, на котором соединяются воедино все элементы системы и начинается ее функционирование. Это очень ответственный и сложный этап, поэтому подготавливается и строго выполняется план внедрения. Как часть внедрения, устанавливается и тестируется все новое оборудование и программы, нанимается или обучается персонал, тестируются (и возможно корректируются) новые процедуры обработки данных, отрабатываются стандарты и способы контроля новой ИС, делается подробное документирование. В конце этого этапа происходит демонтаж старой системы и переход на новую.
5. Эксплуатация и обслуживание.
- работа системы;
- изменения в системе;
- текущая эксплуатация;
- результат - улучшенная система.
После того как система заработала, она изучается на предмет обнаружения и исправления недостатков разработки. В течение своей жизни система периодически пересматривается. Изменения в нее вносятся по мере возникновения проблем или появления новых потребностей. Если требуются существенные изменения системы, по сути означающие ее замену, то цикл разработки начинается сначала.
В дополнение к этим пяти этапам на протяжении всего цикла разработки ИС производится планирование, управление поведенческими реакциями пользователей на изменения и оценка текущих возможностей всего проекта.

2.	
6.	Жизненный цикл и характеристики. Критерии оценки качества. Проблемы разработки.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (ПО) - совокупность программ на носителях данных и программных документов, предназначенная для отладки и решения задач определенного функционального назначения.
ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ - совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании.
По типу функционального назначения различают:
- системное ПО;
- инструментальное ПО;
- прикладное ПО.
Прикладное ПО может рассматриваться как
1) Приложение - набор программ, автоматизирующий решение некоторых прикладных задач пользователей.
2) Программная система (ПС)- набор прикладных программ, рассматриваемый как единый объект разработки.
6.1	Составные части ПС
1. Данные - входные,
		- выходные,
		- хранимые.
2. Процессы - последовательности инструкций или конъюнкции (соединения) событий, оперирующие с данными. Протекание процессов определяется условиями и ограничениями.
3. Интерфейс - пользовательский,
		- документальный, 
		- машинный.
6.2	Классификационные признаки ПС
1. По организации взаимодействия с пользователем:
- пакетные;
- интерактивные;
- реального времени.

2. По архитектурным особенностям реализации.
- однопроцессорные;
- параллельные;
- распределенные.
3. По особенностям строения:
А. - неинтеллектуальные (описание процесса):
		- обработки данных,
		- вычислительные,
		- информационно-поисковые,
    - интеллектуальные (моделирование механизма создания процесса).
Б. - обработки транзакций,
     - анализа данных,
     - поддержки принятия решений,
     - экспертные системы.
6.3	Жизненный цикл и характеристики ПО
ЖЦ - модель взаимосвязанных процессов создания и последовательного изменения состояний системы от возникновения необходимости в ней до полного выхода из употребления.

Проблема взаимосвязи жизненных циклов программно-технической среды и информационно-программного обеспечения.
6.4	Стадии создания АС по ГОСТ 34.601-90
1. Формирование требований к АС.
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.
6.5	Характеристики ПС
	функции	совместимость   легкость использования
			скорость      легкость освоения
			ресурсы        надежность

время   люди          документация   
инструменты         модифицируемость
деньги                   надежность 
6.6	Проблемы разработки ПС.
1. Неопределенность и несогласованность представлений пользователей о том, для чего нужна и что должна делать ПС.
2. Отсутствие профессиональных знаний разработчиков о предметной области автоматизируемой деятельности пользователей.
3. Сложность как создаваемой ПС, так и самого процесса разработки.
4. Высокая динамичность совершенствования ПТС и изменения деловых процессов в организации, соизмеримая с временем создания ПС. 
2.	
7.	Методологии и методы разработки ИПО.
7.1	Методологии разработки ПС.
Методология - совокупность механизмов (процедур, технологий и процессов), определяющих деятельность на каждой фазе разработки программных систем и объединенных единым философским подходом.
Методологии различаются по выбранному базису аспектной декомпозиции предметной области деятельности пользователей (совокупности моделей) и базисной составной части ПС, являющейся ведущей в процессе проектирования.
Основные классы методологий
1. Процессно-ориентированные основаны на структурном подходе к представлению процессов и потоков данных, с которыми они связаны. Разработанные раньше других, наиболее широко они используются при создании ПС обработки данных и вычислительного характера.
2. Дата-ориентированные предусматривают первоочередное моделирование данных в виде сущностей и связей между ними. После этого определяются связи между выходными и входными данными для того, чтобы выработать требования к процессам. Методологии этого класса широко используются при создании информационно-поисковых систем на основе баз данных.
3. Объектно-ориентированные основаны на объектной декомпозиции предметной области. В качестве объектов рассматриваются конкретные предметы, а также реальные или абстрактные сущности. Каждый объект содержит некоторую структуру данных, дополненную набором процедур, описывающих способы манипулирования этими данными. Таким образом, объект можно рассматривать как абстрактный тип данных, в котором соединены (инкапсулированы) и данные и подпроцессы. Процессы в системе описываются через последовательность происходящих в ней событий. В результате событий объекты могут становиться активными или пассивными, а также обмениваться между собой сообщениями, инициирующими возникновение новых событий. По сравнению с предыдущими объектно-ориентированная методология рассматривается как более гибкая из-за возможности создавать разнообразные виды абстракции типов данных. За счет этого улучшается модернизируемость ПС. В тоже время выигрыш в сроках разработки достигается лишь при неоднократном применении этого подхода и использовании в новом проекте объектов, разработанных для других систем.
4. Семантические предназначены для разработки интеллектуальных ПС.
Метод - концептуальное описание правил построения моделей, представляющих разные взгляды на проект, с использованием специальной нотации.
Методика - достаточно детальное описание последовательности шагов, выполняемых при разработке проекта системы на основе определенного метода.
Метод конкретизирует методологию, учитывая в явном или неявном виде:
- модель жизненного цикла, которая определяет порядок выполнения основных этапов разработки.
- перечень и порядок использования документов (моделей), которые должны быть получены после завершения каждого из этапов разработки.

ПЕРЕЧЕНЬ ЭТАПОВ РАЗРАБОТКИ (см. ниже)
МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПО (на фазе разработки) (см. ниже)

Представление методологии проектирования  в виде схемы Захмана
Объект
Субъект	Данные
	Функции
	Коммуникации	ПТС	
Заказчик
	Объекты
деятельности	Деловые
Процессы	Размещение
Линии связи	Места
деятельности	
Пользователь	Объекты деятельности и их связи	Задачи (фрагменты деловых процессов)	Рабочее место
Субъекты и способы взаимодействия	Рабочая станция
(ПЭВМ или терминал)	
Системный
Аналитик	Диаграммы "сущность - связь"	Диаграммы
потоков данных	Перечень и размещение
пользователей	Облик ПТС	
Системный
программист	Логическая модель данных	Структура программ
(приложений)	Архитектура
информационной системы	Архитектура ПТС	
Системотех-ник	Облик базы данных	Параметры решаемых задач	Интенсивность
и маршруты решения задач	Компоненты ПТС	
Программист	Физическая модель данных	Описание программы	Адреса и протоколы	Тип ЭВМ
и ОПО	
Эксплуата-ционный персонал	Файлы и базы данных	Программные
Файлы	Размещение и коммуникации	КТС и ОПО	
2.	
8.	Этапы разработки ИПО. Инструментальные средства реализации ИПО.
Перечень и последовательность этапов разработки ПС определяются выбранными методами ее создания, однако всегда можно выделить следующие этапы (фазы):
- анализ требований к программной системе, (что она должна делать, Ф - представление);
- проектирование системы (как она должна это делать, П - представление);
- реализация (чтобы она действительно это делала).
Модели жизненного цикла ПС (на фазе разработки):
1.	Каскадная модель - переход на следующий этап после полного окончания работ по предыдущему этапу.
2.	Поэтапная модель с промежуточным контролем - итерационная модель разработки ПС с циклами обратной связи между этапами.
3.	Спиральная модель - последовательное создание развиваемых версий (прототипов), для каждого из которых последовательно выполняются все этапы разработки.
4.	Быстрое создание приложений (RAD) - создание на основе объектно-ориентированной методологии и соответствующих инструментальных средств работающего прототипа системы, основным назначением которого является совместное с заказчиком и пользователями осуществление анализа и проектирования программной системы.

Рисунок 1. Каскадная модель разработки ПО

Рисунок 2. Спиральная модель разработки ПО

Рисунок 3. Модель разработки ПО с использованием RAD

СТАДИИ СОЗДАНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ (АС) ПО ГОСТ 34.601-90
1. Формирование требований к АС.
2. Разработка концепции АС. 
3. Техническое задание.
4. Эскизный проект.
- функции системы и подсистем, 
- состав комплексов задач и отдельных задач,
- концепция и укрупненная структура информационной базы,
- функции основных программных средств.
5. Технический проект. 
- функционально-алгоритмическая структура системы,
- алгоритмы решения задач и применяемые языки программирования,
- основные решения по организации и ведению информационной базы (в т.ч. классификаторы).
6. Рабочая документация.
Разработка или адаптация программ (в т.ч. разработка документации).
7. Ввод в действие. 
- автономная и комплексная наладка программных средств,
- предварительные испытания на работоспособность и соответствие ТЗ,
- опытная эксплуатация (при необходимости доработка ПО),
- испытания с целью приемки в постоянную эксплуатацию,
- обучение персонала. 
8. Сопровождение АС. 
8.1	Инструментальные средства реализации ИПО.
1. Системы программирования.
2. Системы управления базами данных.
3. Электронные таблицы.
4. Интегрированная среда реализации:
•	нераспределенной обработки (Microsoft Office);
•	распределенной обработки без поддержки коммуникаций (клиентское ПО на Ассess,
•	серверное на MS SQL Server);
•	распределенной обработки с поддержкой коммуникаций (средства создания и поддержки технологий:
1) groupware 	(Lotus Notes, Microsoft Exchange, GroupWise)
2) workflow (Staffware, Action Workflow)
Технологии groupware 
1) ориентированы на небольшие рабочие группы,
2) характеризуются поддержкой выполнения одной коллективной задачи и отсутствием структуризации в организации работ. 
Поддержка ограничивается обеспечением коллективного доступа к информации с помощью различных методов доступа:
- сетевой доступ к файлам и базе данных;
- локальная и глобальная электронная почта;
- терминальный доступ, пересылка файлов и электронная доска объявлений;
- просмотр и интерпретация гипертекста.
Технологии workflow
- служат для автоматизации документооборота в средних и крупных офисах;
- поддерживают многопользовательскую работу с несколькими задачами одновременно;
- предусматривает четкую структуризацию выполнения работ по ролям и документам с контролем исполнения.

ТРЕХУРОВНЕВАЯ МОДЕЛЬ
	---------------------------------------------------------------------------------------                 		ПРЕДМЕТ 					 									
	----------------------------------------------------------------------------------------
							  МЕТОД						
				последовательности операций				
				над объектами предметной области	Work
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
	Group		группы действий над элементами			flow  
ware		интерфейса для реализации операций		
--------------------------------------------------------------------------------------------------
							ИНСТРУМЕНТ		     
				элементарные действия пользователя	
				над элементами интерфейса
--------------------------------------------------------------------------------------------------

8.2	НОВОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
8.2.1	Интегрированная база данных 
Сформировалось понимание интегрированной БД как общего информационного ресурса организации. 
Хранимые данные стали аналогичны большому компьютеру, который одновременно используется многими пользователями с различными целями и должен быть все время работоспособен.
8.2.2	Классическая методология проектирования
Проектные этапы: 
•	сбор сведений о ПО (анализ потребностей и описание ПО с использованием так называемых "процессного" подхода и "непроцессного", подхода);
•	выбор языка представления т.н. "семантической" модели для фиксации сведений о ПО, их последующего анализа и синтеза модели БД;
•	анализ собранных сведений о ПО: классификация, формализация и интеграция структурных элементов описания ПО, формализация как структурных, так и процедурных ограничений целостности элементов в будущей модели ПО, определение динамики экземпляров объектов ПО;
•	синтез концептуальной модели БД: проектирование целостной концептуальной схемы БД на выбранном языке семантического моделирования;
•	выбор конкретной модели данных и СУБД для реализации БД;
•	проектирование логической схемы БД для выбранной СУБД (называющееся также "проектирование реализации");
•	разработка физической структуры БД включая размещение БД по узлам;
•	разработка технологии и процедур начального создания и заполнения БД;
•	разработка технологии и процедур сопровождения БД;
•	разработка универсальных программ доступа к БД и соответствующих интерфейсов пользователей;
•	информационное обеспечение разработки конкретных программ обработки данных:
•	обеспечение метаинформацией, данными контрольных примеров и др.;
•	получение обратной связи от разработчиков прикладных программ и пользователей ИС о полноте и эффективности организации БД;
•	тестирование БД, ее развитие и улучшение (настройка) ее структуры.
Это - дисциплина т.н. структурного анализа при проектном подходе "сверху вниз".  Проектная схема получила название "каскадной".

8.2.3	КАСКАДНАЯ СХЕМА

Рисунок 4. Каскадная схема

ПОЛОЖИТЕЛЬНЫЕ СТОРОНЫ "КАСКАДНОЙ" СХЕМЫ 
Положительные факторы применения этой схемы наблюдались в следующем: 
•	на каждой стадии формировался законченный, отвечающий критериям полноты и согласованности набор проектной, а затем и пользовательской документации, охватывающий все предусмотренные стандартами виды обеспечения ИС: организационное, методическое, информационное, программное, аппаратное и др.
•	выполняемые в логичной  последовательности этапы работ достаточно очевидным образом позволяли планировать сроки завершения всех работ и соответствующие затраты. 

Структура ИС 
СТАДИИ ПРОЕКТА	Организа- ционное	Методи-ческое	Информа-ционное	Програм-мное	Аппарат-ное	
Запуск	+-					
Обследование	+-	+-	+-			
Концепция ТЗ	+-	+-	+-			
Эскизный проект	+-	+-	+-	+-		
ТП	+	++	+	+-	+-	
РП	++	++	++	++	++	
Ввод в действие	++	++	++	++	++	

”Обследование”, общий анализ ситуации в организации и разработка общего обоснования целесообразности создания ИС: общий системный и ситуационный анализ текущего состояния и целей организации, ее масштабов, возможности, стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия.
"Концепция, ТЗ":
•	исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам,
•	 анализ критических факторов успеха и риска с использованием системного и ситуационного анализа,
•	 обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др., определение соответствия существующей оргструктуры, функций, документов и др. целям предприятия, проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций ("задач"), видов документов и правил документооборота, вычленение предметных БД, определение взаимосвязей между ними,
•	 разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.,
•	 построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана, модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEF0, по методике HIPO или др.), 
•	сбор и описание детальных требований к составу данных и алгоритмам реализации функций.
"Эскизный проект":
•	 разработка архитектуры будущей ИС в рамках эскизного проекта, 
•	 построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса-Кодда, четвертых и пятых нормальных форм),
•	 определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, переход от командного интерфейса к диалоговым режимам "вопрос-ответ", "управление через меню"), 
•	 определение модульной иерархии (верхние уровни) программного обеспечения ИС (модульное программирование, метод HIPO),
•	 определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, ),
•	 определение основных оргмероприятий по созданию и вводу в действие ИС,
•	 определение совокупности требований к приемке будущей ИС,
•	 определение сроков, состава работ и их стоимости для последующих работ по ИС. 
НЕДОСТАТКИ КАСКАДНОЙ СХЕМЫ 
1:"ОПОЗДАНИЕ" 
2: "БЕСПОЛЕЗНОСТЬ" 
Альтернатива такому подходу требовалось получение с помощью ИС качественно новых результатов, позволяющих осуществлять оптимальное управление производством в целом, динамически менять управление производственными процессами на предприятии, принимать лучшие управленческие решения, встраивать контроль качества и рациональное управление внутрь производственных процессов, использовать их самими производственными коллективами. 
8.2.4	Мастерская инструментов проектирования БД
Наличие целостной методологии проектирования позволило позаботиться о систем автоматизации проектирования БД. Этому способствовало использование активных интегрированных словарей-справочников данных (DD/D, Data Dictionary/Directory).
Возникли системы CASE  - системы для структурного проектирования БД и связанных с ними ИС, ориентированные на модели данных, реализованные в различных СУБД.
Наибольшую популярность получили CASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D переименовался в CASE-репозиторий проектируемой ИС.
 Два основных направления развития CASE-систем и технологий проектирования:
CASE-системы для проектирования собственно БД,
интегрированные инструменты, позволяющие и проектировать БД, и разрабатывать использующие их прикладные программы. 
Часто интегрированность функций приводит к сращиванию CASE-системы с одной из СУБД, на которую ориентированы CASE - средства разработки прикладных программ.
Итак, Классическая Мастерская проектировщика БД включает совокупность классических структурных методов проектирования, набор соответствующих инструментов моделирования, реализации, загрузки и сопровождения БД, а также "каскадную" организационную схему выполнения этих работ по принципу "сверху вниз".
8.2.5	Причины появления новых требований
Появились новые возможности БД и способы их проектирования. Список типов хранимых и обрабатываемых данных расширился до возможных пределов, определяемых самым общим нормативным значением понятия "данное". 
В корпоративные БД включаются не только неформатированные элементы и полнотекстовые фрагменты, но также БД с геоинформацией, мультимедийные БД, и это не исчерпывающий перечень.
Если ИТ были одним из толчков к такому развитию ситуации, то они оказались призваны и для того, чтобы обеспечить успех и саму возможность планируемых реконструкций.
 Возникли новые требования к архитектуре корпоративных ИС, как следствие - новые требования к корпоративным БД.
8.2.6	Об использовании классических методов проектирования ИС в настоящее время
Все эти методы остались в арсенале разработчиков и в настоящее время.
Однако они и соответствующие инструменты начинают совсем по иному применяться в условиях BPR и открытой архитектуры ИС. Кроме того, теперь они сочетаются с новыми методами, позволяющими достичь большей гибкости и процесса разработки, и самой ИС, причем за меньшее время.
 В отношении собственно классических методов изменения, в первую очередь, касаются качества их компьютерной поддержки, т.е. применения новых ИТ для поддержки классических методов:
•	•широкое применение графических диалоговых интерфейсов (диаграммы структур данных, иерархий функций, потоков данных и др.), •использование компьютерных сетей и работа с распределенными базами данных для поддержки кооперативной групповой разработки (использование общих словарей-справочников данных, теперь - "репозитариев"),
•	постепенное расширение использования понятийных моделей и методов объектного моделирования.
Новые ИТ заставили включать в классические методики и соответствующие новые функции. Как пример, это относится к средствам динамического моделирования архитектур клиент-сервер и систем с распределенными базами данных. Однако включение отдельных новых функций не меняло подхода в целом и не устраняло описанных выше недостатков.
8.2.7	КАЧЕСТВЕННЫЕ ИЗМЕНЕНИЯ В ИТ
ПОНЯТИЕ ОТКРЫТОЙ АРХИТЕКТУРЫ: 
Предполагало строгое соответствие формата передаваемых по сети сообщений стандарту протокола обмена, наличие нескольких стандартных уровней обмена сообщениями со стандартами протоколов для каждого уровня.
Одновременно стал решаться вопрос переносимости баз данных. 
В понятие открытой архитектуры стал вкладываться более широкий смысл.
Укажем лишь на интероперабельность: открытость системы, позволяющая встраивать ее как компонент в сложную разнородную распределенную информационную среду.
ТРИ КАЧЕСТВЕННЫХ СКАЧКА В ИТ:
1.Феномен персональных вычислений, основанный на постоянной доступности работнику возможностей ЭВМ, в первую очередь - на использовании персональных компьютеров.
2. Феномен кооперативных технологий, состоящий в компьютерной поддержке совместной согласованной работы группы работников над одним проектом.
3.Феномен компьютерных коммуникаций, состоящий в резком увеличении возможностей обмена любой информацией. Он возник, в частности, на основе стандартизованных протоколов обмена данными прикладного уровня в локальных и глобальных сетях. 
ПОНЯТИЙНАЯ МОДЕЛЬ КАК МИНИМАЛЬНАЯ ИНТЕГРИРУЮЩАЯ МОДЕЛЬ 
Необходимость строить ИС на основе набора "покупных" приложений разных поставщиков, причем набора, состав которого надо уметь изменить в нужное время, привела к практической невозможности использовать классические структурные технологии проектирования интегрированных систем.
Даже если "по большому счету" в новом приложении будут выполняться те же функции, но, например, быстрее и в более удачной компоновке, а информация хранится "всего лишь" в виде более детальных сведений и т.п., то информационные и функциональные модели могут отличаться друг от друга практически во всех деталях! 
Постепенно становилось ясно, что обе крайности неприменимы: ни вульгарный позадачный подход, ни попытки разработки полностью законченных больших ИС с заранее полностью спроектированной интегрированной базой данных. 
Единственным достаточно стабильным интегрирующим элементом современной ИС может являться только понятийная модель предметной области.
Активные понятийные модели разрабатывались не только для хранения описаний используемых понятий и связей между ними. Ставились цели динамически формировать новые суждения, определять тождество или сходство понятий, производить их интерпретацию вычислительного характера. К таким моделям относятся разные представления семантических сетей, некоторые специальные понятийные модели. 
В настоящее время слияние средств представления знаний с технологией обобщенных объектов и стандартизацией в области объектно-ориентированных представлений реально ведет на следующий, качественно новый уровень в технологии системного проектирования. 
Как саму ИС нельзя рассматривать в отрыве от ее пользователей, так и новое проектирование должно рассматриваться как интеграция трех составных частей: требований бизнес-реинжиниринга, человеческого фактора и методов новых ИТ. Реальное объединение этих трех составных частей, каждая из которых приобрела в 90-е годы качественно новое наполнение, создало начала того, что можно назвать Н.С.П.
8.2.8	BPR (Business Process Reengineering) - Реконструкция Бизнес - Процессов
“Бизнес - процессы это логические серии взаимозависимых действий, которые используют ресурсы предприятия (организации) для создания или получения в обозримом будущем полезного для Заказчика (Объекта заботы) выхода, такого как Продукт или Услуга”
Главное в BPR - резкое ускорение реакции предприятия на изменение в требованиях потребителя путем:
•	постоянное повышение качества продуктов и услуг;
•	трансформация и динамическое совершенствование организации работ;
•	критерии качества исходят от потребителя;
•	в центре внимания качество выполнения производственных функций
•	исследуются и устраняются недостатки производственной системы, а не отдельных работников;
•	повышение роли решений и инициативы каждого работника;
•	снимаются барьеры, установленные производственными подразделениями; организуется групповая “артельная работа”
•	один из определяющих факторов - обеспечение работникам возможности гордиться результатами своего труда.
Цели и методы BPR:
•	резкое снижение затрат времени на выполнение функций;
•	резкое снижение числа работников и других затрат на выполнение функций;
•	глобализация бизнеса:
•	 работа  с клиентами и партнерами в любой точке мира;
•	работа с клиентом в режиме 24*365 часа;
•	работа на будущие потребности клиента;
•	ускоренное продвижение новых технологий;
•	движение в информационное общество.
Связь BPR c ИТ:

Основная бизнес - платформа

Основная информационная платформа

Бизнес- архитектура
•	Товары и услуги
•	Организация
•	Управление и обработка 
•	Распределение ресурсов
•	Культура, ценности, награды 

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

A
Новые ИТ

B
Бизнес-
  реинжени-
    ринг

                      С
Социопсихология,
     другие науки
            о человеке

ABC
Новое
Системное
Проектирование

AC

AB

BC

Новое системное проектирование

9.	
Тема 5. Методология структурного анализа и проектирования.
Структурный анализ (Structured analysis) – это основанная на моделировании ориентированная на процессы техника, используемая для анализа существующей системы, определения требований новой системы или того и другого.
Модели представляются диаграммами, которые иллюстрируют компоненты системы: процессы и связанные с ними входы, выходы и файлы. Сложные объекты анализируются и декомпозируются на более простые и более документированные.
Структурное проектирование – это ориентированная на процессы техника для разбиения больших программ на иерархию модулей, в результате чего программа легче реализуется и изменяется.
Структурное проектирование отыскивает факторы программы в нисходящей иерархии модулей, которые имеют следующие свойства:
- Модули должны иметь сильную внутреннюю связность. Каждый модуль должен выполнять одну и только одну функцию. Это позволяет многократно использовать модули в будущих программах.
- Модули должны быть слабо связаны между собой; иными словами, модули должны быть минимально зависимы между собой. Это минимизирует эффект влияния будущих изменений одного модуля на другой.
- Группировать все модули (или процессы) вызванные одной операций для формирования операционного центра. Например, все задачи, выполняемые при получении заказа от поставщика, связаны. Часто, центр управления служит как модуль управления.
10.	Тема 6. Диаграмма потока данных (ДПД). Назначение. Символы ДПД. Правила построения и принципы создания ДПД. Контекстная диаграмма, диаграммы уровня 1 и 2. Понятие функциональных примитивов. Документирование и проверка модели.
Диаграмма потока данных - логическая модель потока данных в системе, которая показывает границы системы, процессы и каким образом объекты диаграммы логически связаны.
Диаграмма потока данных - превосходный инструмент для получения детальной информации о компонентах системы, процессах и объектах данных, обеспечивает аналитика логической схемой системы. Изображение компонентов системы с помощью контекстной диаграммы помогает аналитику, пользователю и менеджеру представлять альтернативные логические проекты системы высокого уровня. Элементы диаграммы потока данных ведут непосредственно к физическому проекту, к процессам, предполагающим программы и процедуры, потокам данных, предполагающим связи и хранилищам данных, предполагающим сущности данных, файлы и базы данных.
Создание диаграммы потока данных ориентировано на процессы. Следовательно, относительно легко пропустить ключевые элементы данных и производные. Сбалансированная диаграмма потока данных подтверждает внутреннюю логику модели, но не обязательно показывает отсутствующие элементы. Попытка сбалансировать сложную логическую модель без соответствующего программного обеспечения (типа CASE-средств) может оказаться трудной задачей.
Символы ДПД
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Внешние сущности. Внешняя сущность представляет собой материальный предмет или физическое лицо, являющееся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом, расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений (рис.1).

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

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

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

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

Рис. 5. Поток данных
Все потоки данных должны начинаться или заканчиваться процессом. Данные не могут проходить непосредственно от источника до потребителя или между источником/потребителем и хранилищем данных, если они не проходят через промежуточный процесс.
Правила построения:
1. Все потоки данных должны начинаться или заканчиваться процессом. Данные не могут протекать непосредственно от источника до потребителя или между источником / потребителем и хранилищем данных, если они не проходят через промежуточный процесс.
2. Многочисленные потоки данных между двумя компонентами можно показывать двумя линиями потока данных или двунаправленной стрелкой.
3. Название процесса состоит из глагола, следующего за существительным. В соответствии с соглашением, названия источников, получателей и хранилищ данных использует заглавные буквы, в то время как названиям процесса и потоки данных показываются произвольно.
4. Процессы в уровне 1 диаграмма потока данных перечисляется 1, 2, 3, и так далее. Подпроцессам в декомпозированной диаграмме потока данных назначают номера, начинающиеся с номера родительского процесса.
5. Символы могут быть повторены для облегчения чтения диаграммы.
Основные принципы:
- принцип сохранения данных
Любые данные, которые входят в процесс, должны использоваться или воспроизводиться этим процессом. Любые выходные данные процесса должны быть введены или созданы алгоритмом в пределах процесса. Любые данные, используемые алгоритмом в пределах процесса должны быть сначала введены в процесс. Любые данные, созданные алгоритмом должны или использоваться другим алгоритмом в пределах того же самого процесса или выведены процессом.
- принцип итераций
Процессы высокого уровня декомпозируются в процессы низшего уровня. На самом низком уровне - примитивные процессы, которые исполняют единственную функцию (или алгоритм).
Контекстная диаграмма (уровень 0) определяет границы системы, выдвигая на первый план источники и получатели. Выделение границы системы при изображении контекстной диаграммы помогает аналитику, пользователю и ответственным менеджерам рассматривать альтернативные логические проекты системы высокого уровня.
Уровень 1 диаграммы потока данных показывает важнейшие процессы системы, хранилища данных, источники и получатели, связанные потоками данных. Процесс уровня 1 является сложным и может включать программы, руководства, ручные процедуры, аппаратные средства ЭВМ, процедуры и другие действия.
Каждый процесс уровень 1 состоит из нескольких подпроцессов, которые внесены в список описаний процессов. Чтобы разбить диаграмму потока данных, аналитик создает независимый уровень 2 диаграммы потока данных для каждого процесса уровня 1.
Функциональный примитив - процесс (или преобразовывать), который не требует никакого дальнейшего разложения. Отдельные физические компоненты системы находятся на один шаг ниже функциональных примитивов.
Документирование. Элементы данных документируются в словаре данных. В процессе разработки элементы данных, которые занимают то же самое место, хранят или разделяют поток данных, формируют сложные вычисления или структуры данных также документируются в словаре данных.
Каждый процесс определен в описании процесса, которое обращает внимания на вход и элементы данных выхода и кратко описывает задачи или действия, которые он выполняет. Описания процессов иногда документируются в словаре данных.
Проверка модели включает следующие этапы:
1.	Проверка синтаксиса
2.	Проверка элементов данных
3.	Взаимные ссылки
4.	Проверка целей 

11.	Методы процессно-ориентированного анализа.
Представление  методологии проектирования в виде схемы Захмана
Объект
Субъект	Данные	Функции	Коммуникации	ПТС	
Заказчик	Объекты деятельности	Деловые процессы	Размещение. Линии связи	Места деятельности	
Пользователь	Объекты деятельности и их связи	Задачи (фрагменты деловых процессов)	Рабочее мест. Субъекты и способы взаимодействия	Рабочая станция (ПЭВМ или терминал)	
Системный аналитик	Диаграммы "сущность - связь"	Диаграммы потоков данных	Перечень и размещение
пользователей	Облик ПТС	
Системный программист	Логическая модель данных	Структура программ (приложений)	Архитектура
информационной системы	Архитектура ПТС	

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

Процессно-ориентированные методы анализа относятся к  классу методов структурного анализа (подход Баркера), основанных на следующих принципах: 
1) декомпозиции,
2) иерархического упорядочивания,
3) абстрагирования - выделение на каждом уровне иерархии своих, существенных с некоторых позиций, аспектов системы и отвлечение от несущественных с целью представления системы в наиболее простом и общем для данного уровня иерархии виде,
4) формализации - строгое следование применяемым методам,
5) непротиворечивости - обоснованность и согласованность элементов моделей,
6) независимости данных - модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения по узлам обработки информации.

Структурный анализ начинается с общего представления о ПС, которое затем детализируется, приобретая иерархическую структуру, включающее все большее число уровней. Использование принципа декомпозиции облегчает понимание функций, которые должна выполнять ПС, за счет их подразделения на множества более мелких.
Для обеспечения проектирования трех базисных составных частей ПС, каждая из которых также является объектом разработки: 1) данных, 2) процессов и 3) интерфейса, на этапе анализа используются три группы моделей, иллюстрирующих: 
•	функции, которые эта система должна выполнять;
•	состав и характеристики данных, а также отношения между ними;
•	поведение системы, зависящее от времени и внешних событий, в частности, от действий пользователей.
Соответствующие модели получили название функциональных, информационных и событийных. Примерами наиболее часто и эффективно применяемых моделей каждой из групп являются следующие:
DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов;
ERD (Entity-Relationhip Diagrams) – диаграммы «сущность – связь»;
STD (State-Transition Diagrams) – диаграммы переходов состояний.

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

Рисунок 5. Пример диаграммы потоков данных

Каждый процесс может быть детализирован с помощью DFD нижнего уровня. Когда дальнейшая детализация с использованием DFD перестает быть полезной, переходят к другим средствам описания процессов. Содержимое каждого хранилища также сохраняют в словаре данных. Модель данного хранилища представляется в виде ERD. При необходимости DFD может быть также дополнена STD, описывающей поведение системы. На следующем рисунке представлена схема, иллюстрирующая иерархическую структуру получаемых на основе процессно-ориентированных декомпозиции описаний.

Рисунок 6. Иерархическая структура описаний с  использованием диаграмм потоков данных

Перечисленные средства могут быть использованы для полного описания как существующей организационной системы, деятельность которой автоматизируется, так и разрабатываемой системы.
Отметим, что представленная совокупность моделей является универсальной с точки зрения полноты представления всех трех базисных составных частей ПС. Оборотной стороной этой универсальности является избыточность как всего набора моделей, так и основания моделей – DFD, которая возможна при превалировании процессной составляющей ПС над остальными, особенно информационной. Строго говоря, ERD является неотъемлемой частью набора моделей, характерных для методологий проектирования, ориентированных на данные. В связи с этим для анализа функциональных требований могут использоваться и другие методы, предусматривающие получение моделей, отличающихся от диаграмм потоков данных. Одним из недостатков DFD является использование в качестве структурного представления ориентированного графа, в вершины которого отображаются и данные и процессы, что затрудняет восприятие и снижает эффективность проводимой декомпозиции. Рассматриваемые далее методы лишены этого недостатка, хотя это и сужает область их использования.

Метод HIPO (Hierarchic Input-Process-Output) – диаграмм, разработанный фирмой IBM, характеризуется следующими основными чертами:
1)	использование трех элементов: вход, обработка, выход;
2)	способностью переставлять связь между входными и выходными данными и процессом обработки;
3)	возможность декомпозировать систему иерархически, не вовлекая излишне мелкие детали.
Процесс специфицируется как центральный блок диаграммы и соединен с элементами, составляющий вход и выход (см. рис.)

Рисунок 7.  HIPO-диаграмма

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

Метод функционального моделирования, входящий в методологию SADT (Structured Analisis and Design Technics), предусматривает, как и другие методы, построения совокупности диаграмм, организованные в иерархические структуры. В состав диаграмм входят блоки, соответствующие функциям (процессам), и дуги, связывающие блоки и отображающие взаимосвязи между ними (см. рисунок). В отличие от DFD и HIPO-диаграмм, содержащих лишь информационные связи (вход-выход) в этом методе анализируется связи по управлению и исполнению (механизму). Таким образом, диаграмма каждого уровня представляет собой, как и DFD, структурные описания, однако в ней не предусмотрены элементы (вершины), соответствующие хранилищам данных. Заметим также, что наличие входов Управление позволяет частично отразить информацию, содержащуюся в диаграммах переходов состояний (STD).

Рисунок 8. Представление блоков и дуг при анализе на основе методологии SADT

В заключение отметим, что функциональные модели с использованием рассмотренных методов могут разрабатываться не только на этапе анализа требований, предъявляемых к ПС, но и на этапе ее проектирования при определении функций, реализуемых программными модулями.
11.1	ПРОВЕДЕНИЕ АНАЛИЗА МЕТОДОМ HIPO
Последовательность проведения анализа функциональных требований к ПС с использование метода HIPO рассмотрим на примере программы решения квадратного уравнения вида:
ax2+bx+c=0.
Напомним, что решение уравнения называется такое значение x, при котором уравнение превращается в тождество. В силу своей простоты пример не является, конечно, характерным для класса программных систем, именно сложность которых и обуславливает необходимость проведения анализа. Тем не менее только на простом примере можно показать суть используемых методов. Вместе с тем даже этот простой пример иллюстрирует ряд сложностей, с которыми приходится сталкиваться при проведении анализа.
Процедура анализа начинается с построения HIPO-диаграммы на наивысшем уровне абстракции, содержащим единственный процесс. Процесс P0 можно идентифицировать как «Найти решение уравнения». На первый взгляд, не вызывает трудностей описание входных данных, это действительные переменные a, b и c. Однако вопрос о диапазоне их изменения помогает уточнить функциональные требования к программе. Действительно, можно считать, что квадратное уравнение не вырождено. Тогда диапазон изменения коэффициента a надо ограничить, потребовав a0. Но возможен и вариант использования программы, предусматривающей произвольные значения коэффициентов уравнения, т.е. неограниченность диапазона их изменения. Предположим, что имеет место последний вариант. Тогда описание выходных переменных потребует дополнительного анализа. В зависимости от сочетания значений коэффициентов могут быть следующие  варианты решения уравнения, приведенные в таблице. Таблицы такого вида называются таблицами решений. В полном виде они используются на этапе проектирования. На этапе анализа достаточно иметь столбцы, в которых помещаются значения указателя варианта n и информация о виде решения. Предположим, что в качестве выходных данных нам необходимо выдавать либо два числовых корня x1 и x2, либо один числовой корень x, либо символьное сообщение s, содержащее информацию о «патологических» случаях. Заметим, что это не самый удачный вариант выходной информации, однако мы остановимся на нем в целях упрощения анализа.

Таблица решений

Указатель варианта n	a	B	C	D	Вид решения	
1	0	0	0		s	
2	0	0	0		s	
3	0	0			x	
4	0			0	x1, x2	
5	0			<0	s	

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

Рисунок 9. Диаграмма нулевого уровня

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

Рисунок 10. Декомпозиция исходного процесса Р0

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

Рисунок 11. Декомпозиция процесса Р3

Декомпозиция процесса Р2 (рисунок ниже) основана, кроме того, на введении промежуточных переменных n и D. Использование n в качестве промежуточной переменной естественно и необходимо, так как именно она и определяет вариативность результатов в соответствии с таблицей. Что касается дискриминанта D, то он, наряду с коэффициентами уравнения a, б и c, определяет значение, принимаемое указателем n. Поэтому процесс «Найти D» может быть определен как на втором уровне иерархии, так и ниже.

Рисунок 12. Декомпозиция процесса Р2

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

Рисунок 13. Декомпозиция процесса Р23
11.2	ПРОВЕДЕНИЕ АНАЛИЗА НА ОСНОВЕ МЕТОДОЛОГИИ SADT
11.2.1	Реализация методологии SADT в программном пакете Design/IDEF
На рубеже 70-х годов при проработки программы интегрированной компьютеризации производства (ICAM) Министерства оборон США была использована методология SADT (Structure Analysis and Design Technique), что привело к стандартизации и публикации ее основных частей, получивших в последствии название методологии IDEF (ICAM DEFinition).
IDEF включает три метод построения IDEF-моделей, основанных на графическом представлении проектируемых систем:
•	IDEF0 – используется для создания функциональной модели, которая является структурированным изображением функции проектируемой системы, а также информации и объектов, связывающие эти функции;
•	IDEF1 – применяется при построении информационной модели, которая включает в себя структурное представление информации, необходимой при поддержки функций системы;
•	IDEF2 – позволяет построить динамическую модель, отображающую функционирование систем во времени с использованием сетей Петри.
Ниже будут рассмотрены основные понятия метода IDEF0-моделей на примере решения квадратного уравнения.
При этом важно уяснить, что IDEF0-модель используемая для более глубокого понимания и анализа не только системы в целом или ее окружения, но и того, как взаимодействуют ее компоненты. При разработке новых систем методология IDEF0 вначале может применяться для определения требований и функций, а затем – собственно для управления процессом проектирования системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем IDEF0 может быть использована с целью проведения анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Как уже отмечалось, результатом применения методологии IDEF0 является модель. Модель состоит из диаграмм, фрагментов текста и глоссария, которые имеют ссылки друг на друга.
Диаграммы – главные компоненты модели. На диаграммах все функции системы и интерфейсы между ними представлены как блоки (функции) и дуги (интерфейсы).
Место соединения дуги с блоком определяет тип интерфейса (см. рисунок). Данные, предназначенные для управлением выполнением функции или задающие ограничения на ее выполнение входят в блок сверху, в то время материалы иди информация, которые будут подвергнуты обработке входят в блок с левой стороны. Механизмы (специалисты, технические устройства, программы и т.п.), посредством которых осуществляется выполнение функций, представляются дугами, входящими в блок снизу. И, наконец, результаты выполнения функции показываются с правой стороны блока.

Рисунок 14. Представление блоков и дуг при анализе на основе методологии SADT

В совокупности своей блоки и дуги диаграммы i+1-го уровня IDEF0-модели используются для представления подфункций и связей между ними, описывающих более общую функцию диаграммы смежного i-го уровня, называемую «родителем».
Постепенное введение все больших уровней детализации по мере создания диаграмм обеспечивает полноту представления информации о проектируемой системе.
Построение IDEF-модели начинается с представления всей системы в виде одного блока и дуг, отображающих интерфейсы с функциями вне системы. Поскольку этот блок отображает систему в целом, то имя, указанное в блоке, является общим для всей модели и присутствует на всех ее диаграммах.
Затем блок, представляющий систему в качестве единичного модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами (см. рисунок). Каждая из дуг имеет метку, подсоединенную к ней выраженную в виде оборота существительного.

Рис. Структура IDEF-модели.

В IDEF0 есть свои правила постепенного добавления деталей в процессе декомпозиции. Модуль всегда делится не менее, чем на три, но не более, чем на шесть подмодулей. Верхний предел – шесть – позволяет использовать иерархию для описания более сложных объектов. Нижний предел – три – гарантирует введение достаточного количества деталей, чтобы полученная декомпозиция представляла интерес.
Во всех случаях каждый подмодуль может содержать только те элементы, которые входят в исходный модуль. Кроме того, модуль не может опустить какие-либо элементы, т.е. «родительский» блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него ничего не может быть удалено.
Ни последовательность, ни время не указываются на IDEF0-диаграммах в явном виде. Обратные связи, продолжающиеся процессы и перекрещивающиеся (во времени) функции могут быть легко изображены при помощи дуг.
11.2.2	Анализ программных систем на основе программного пакета Design/IDEF
Изложенный материал иллюстрирует содержание практического занятия по курсу «Анализ и проектирование систем».
В качестве примера, на основе которого будут показаны особенности работы с программным пакетом Design/IDEF, возьмем задачу решения квадратного уравнения. Основные параметры квадратного уравнения и алгоритм его решения представлены выше.
Создание листа верхнего уровня. После запуска программы новый проект создается с помощью пункта New меню File. Первая модель, которая создается в проекте, должна быть функциональная модель (IDEF0), поэтому в появившемся окне "Select New Page Type" следует выбрать методологию IDEF0 (см. рисунок). После нажатия на кнопку "OK" создается страница верхнего уровня модели. На данной странице находится только один блок, который должен представлять систему в виде единого модуля. Все остальные блоки будут располагаться на страницах более низкого уровня. Название блока должно отражать цель всего проекта.

После запуска Design/IDEF и перед началом построения IDEF0-модели необходимо создать мастер-страницу, включающую в себя некоторую рабочую информацию (имя автора, название проекта, дата исполнения и т.д.). Информация с этой страницы будет воспроизводиться на всех диаграммах модели. Кроме того, такие переменные как «дата», «узел», «название» и «контекст» будут автоматически изменяться для каждой диаграммы. Для этого в окне Startup Master Page Selection необходимо выбрать файл «startup\startup.msp».
Появившаяся страница диаграммы верхнего уровня называется контекстной диаграммой и содержит единственный выделенный IDEF-блок.
Настройка среды проектирования. Прежде, чем создавать остальные блоки, желательно сразу настроить среду проектирования, так как в противном случае в дальнейшем придется устанавливать настройки для каждого созданного блока в отдельности. Для этого в меню Edit, пункте Set Attributes… необходимо настроить все шрифты, которые будут действовать по умолчанию. Из предлагаемого списка шрифтов следует выбирать кириллические.

Далее в меню Edit, пункте Set Options… устанавливается максимальное количество блоков на странице (Activities, Maximum Boxes), тип нумерации (Activities, Numbering), кривизну стрелок (Arrows, Automating Routing), валюту и точность вычислений (Cost) и др. (см. рисунок).

В настройках атрибутов проекта (Edit, Set Page Attributes…) устанавливаются соответствующие атрибуты. Также желательно проверить и другие настройки из пунктов Set Colors…, Set User Options…, Set Settings… из меню Edit.
Создание и редактирование блоков. Для создания нового блока используется пункт "IDEF Box" меню Create либо соответствующая кнопка на панели инструментов. После выбора пункта или нажатия кнопки следует указать место, где будет расположен новый блок. Панель инструментов изображена на рисунке.

Если требуется разместить несколько блоков на диаграмме, то для этого может быть использован пункт "Place Boxes…" меню Create или соответствующая ему кнопка. После выбора пункта или нажатия на кнопку в появившемся окне необходимо будет ввести количество размещаемых блоков. Новые блоки размещаются равномерно по диагонали из левого верхнего в правый нижний угол. 
Размеры новых блоков устанавливаются по умолчанию. Размеры каждого блока изменяются путем перетаскивания маркеров (черных квадратиков на границе объекта), которые появляются после щелчка мыши на блоке.
Для добавления текста в блок (надписывания блока) следует выбрать пункт "Turn On Text" меню Modify, нажать на клавишу F2 на клавиатуре или на соответствующую кнопку на панели инструментов. Режим ввода текста выключается клавишей Esc.
Замечание: Перенос текста на следующую строку в блоках происходит автоматически в зависимости от ширины блока. Текст же в метке должен быть перенесен вручную.
Напечатайте в блоке A0 следующий текст: «Решение квадратного уравнения».
На этой странице верхнего уровня блоку A0 необходимо для выполнения, указанной в нем функции четыре дуги: одна входная дуга, одна управляющая дуга, одна дуга механизма и одна выходная дуга. Дуги в Design/IDEF могут быть созданы только между блоком другим блоком или между блоком и меткой. При движении или изменении размеров объектов (блоков, меток) соответствующие дуги остаются присоединенными к ним.
Поэтому, прежде чем рисовать дуги необходимо создать и разместить на диаграмме четыре метки:
•	для входной дуги: «A, B, C»;
•	для управляющей дуги: «Диалоговый режим»;
•	для дуги механизма: «ПЭВМ»;
•	для выходной дуги: «S, x, (x1, x2)».
Создание и редактирование ярлыков. Для создания меток (ярлыков) используется пункт Label меню Create, клавиша F3 клавиатуры или соответствующая кнопка на панели инструментов. После нажатия следует указать место, где будет введена надпись. Отмена режима ввода надписей происходит при нажатии на клавишу Esc или на любую кнопку на панели инструментов.
Редактирование ярлыков происходит путем включения режима редактирования текста (Modify, Turn On Text или клавиша F2 или соответствующая кнопка на панели инструментов). Выключение режима происходит при нажатии клавиши Esc.
Создание и редактирование стрелок. Прежде чем рисовать дуги следует задать режимы, влияющие на их создание. С этой целью откройте меню EditSet OptionsIDEF0Arrows. В появившимся перечне команд выберете Lock Arrows, которая следит за тем, чтобы нарисованные углы дуг были прямыми и Route Arrows, разбивающая дугу на ломаные сегменты с прямыми углами так, чтобы дуга не пересекала, а как бы обходила по пути другие блоки и метки.
Для создания новой дуги необходимо выбрать пункт Arrow меню Create или нажать на соответствующую кнопку на панели инструментов. Затем курсором мыши следует нажать на точку диаграммы, откуда будет выходить дуга, и, не отпуская кнопки мыши, протащить дугу до того места какого-либо объекта, куда должна дуга войти.
Изменение имеющейся на диаграмме стрелки производится с помощью маркеров, появляющихся при ее выделении.
Ветвление (объединение) стрелок происходит с помощью пунктов Branch (Join)  меню Create или соответствующей кнопки на панели инструментов. Дуга, подвергающаяся ветвлению (объединению) должна быть предварительно выделена. После вызова процедуры требуется указать место на любом из объектов диаграммы (объект начинает мигать при приближении курсора мыши), куда (откуда) будет направлена ветвь.

Рисунок 15. Контекстная диаграмма верхнего уровня.

Замечание: Дуги в Design/IDEF рисуются от точки на стороне исходного блока или метки, где вы нажмете кнопку мыши. Если отпустить кнопку мыши до завершения дуги, то дуга будет сегментирована. Для создания корректного соединения дугой двух объектов необходимо указателем мыши осуществлять небольшой заступ на объект, который при выполнении команды Arrow примет форму дуги «», где наконечник стрелы является «горячей» точкой указателя дуги. Указатель дуги остается активным до тех пор, пока вы не отмените его нажатием клавиши Esc или выбором другой команды. Двойное нажатие на левую кнопку мыши вне блока или метки во время создания дуги удаляет эту дугу.
Декомпозиция блоков. В Design/IDEF каждая диаграмма в модели может быть названа и иерархически связана. Существующая команда Decompose позволяет создавать подстраницы контекстной диаграммы, на которых изображается следующий уровень модели.
Декомпозиция производится с помощью пункта Decompose меню Create или соответствующей кнопки на панели инструментов. В результате декомпозиции создается новый лист диаграммы более низкого уровня, перейти на который можно двойным щелчком по декомпозированному блоку.
Перемещение между страницами. Для перехода на родительскую или дочернюю страницу используются пункты "Parent" и "Child" меню Select или соответствующие кнопки на панели инструментов. Для перехода на произвольную страницу может быть использовано иерархическое дерево страниц проекта, которое вызывается пунктом "Page…" меню Select.
Подстраница получает имя, в точности совпадающее с текстом внутри декомпозированного блока и номер «P.2». Автоматически заполняются переменные мастерской страницы: дата, контекст, узел и название.
Блок A0 на родительской диаграмме имеет четыре дуги, соединяющие его с метками. Текст этих меток будет автоматически перенесен на страницу-наследник и помещен в невидимые прямоугольники, называемые «портовыми узлами» и расположенные по краям страницы-наследника.
Замечание: Если IDEF-страница не помещается целиком на экране выберете команду Reduce в меню View, чтобы увидеть все портовые узлы. Выберете команду Enlarge меню View, чтобы вернуться к 100-процентному масштабу.
Диаграмма второго уровня будет содержать три функции: ввод данных, найти решение и вывод данных.
Для создания и размещения блоков, отображающих указанные выше функции выберите команду Place Boxes в меню Create.
Появится диалоговое окно, в котором будет выделено число «3», указывающее на количество создаваемых блоков. Вы можете напечатать любое необходимое вам число, но не больше максимально допустимого числа блоков, помеченного в этом диалоговом окне. Максимальное число блоков может быть изменено в диалоговом окне Set Attributes… меню Edit.
Кликните мышкой по полю OK для создания и размещения трех IDEF-блоков вдоль диагонали страницы. Блоки нумеруются автоматически в соответствии с режимом нумерации блоков, установленных в окне Set Attributes….
Используя команду Turn On Text в меню Modify, впечатайте указанный выше текст в соответствующие функциональные блоки.
Затем нарисуйте дуги, соединяющие между собой функциональные блоки и портовые узлы (контекстные метки). При этом следует имеет ввиду, что контекстная метка «ПЭВМ» соединяется с тремя блоками (A1, A2, A3), а метка «Диалоговый режим» - с двумя (A1, A3).
Чтобы создать разветвляющуюся дугу между контекстной меткой «ПЭВМ» и функциональными блоками A1, A2 и A3, нарисуйте дугу между указанной меткой и блоком A1. Нажмите клавишу Esc для завершения создания дуги.
Замечание: Если вертикальный участок дуги расположился слишком близко к другому блоку, вы можете передвинуть его. Поместите графический указатель на один из выделяющих квадратиков, расположенный в вершине прямого угла и передвиньте его в новое положение. Дуга будет нарисована заново.
Сохраняя выделение этой дуги, выберете команду Branch в меню Create. Появится сообщение в поле состояния: «Select the IDEF Box or label for branch» (Укажите IDEF-блок или метку для разветвления). Поместите указатель мыши на нижнюю сторону блока A2. Как только контуры указанного блока замерцают, щелкните левой кнопкой мыши. Ветвь дуги будет автоматически будет проведена от метки «ПЭВМ» вдоль исходной дуги до точки разветвления, от которой ломаная дуга с прямым углом присоединится к блоку A3.
Как отмечалось ранее, каждая дуга может иметь свою метку. Воспользовавшись командой Label в меню Create, создайте возле дуги, соединяющий блоки A1 и A2 метку «a, b, c». Для присоединения метки к дуге нажмите клавишу Esc, чтобы закончить создание меток, и выберете команду Attach Label в меню Create. В поле состояния появится сообщение: «Select the Arrow for attach» (Укажите дугу для присоединения). Поместите указатель мыши на вертикальный сегмент дуги напротив метки. Когда дуга замерцает, щелкните кнопкой мыши.
В результате выполнения команды появится линия, соединяющая метку и дугу, а в точку присоединения на дуге будет помещен маленький кружочек.
Замечание: Design/IDEF позволяет произвести только одно присоединение для каждой дуги.
Создайте и присоедините метки для каждой из дуг на диаграмме второго уровня, как показано на рисунке.

Рисунок 16. Диаграмма второго уровня.

На этом построение диаграммы второго уровня заканчивается. Для построения диаграммы третьего уровня необходимо осуществить декомпозицию блока A3 «Найти решение», используя команду Decompose меню Create.
На диаграмме третьего уровня следует разместить четыре функционального блока: найти D, найти числовое решение, найти символьное решение (см. рисунок).

Рисунок 17. Диаграмма третьего уровня.

Обратите внимание, что на полученной диаграмме третьего уровня не удалось избежать пересечения стрелок, отображающих связи между функциями. Для таких случаев в Design/IDEF предусмотрена возможность построения мостов, позволяющих визуально отличать точки пересечения и разветвления двух и более стрелок.
Выберете команду Create Bridges в меню EditSet AttributesIDEF0Arrows. После ее выполнения в каждой точке пересечения автоматически появится мост, как показано на предыдущем рисунке.
Design/IDEF также предоставляет большой выбор средств для изменения внешнего вида объектов, что позволяет выделять их особые значения, например, декомпозированный блок на родительской диаграмме.
Заполнение декомпозированного блока IDEF-блока одним из имеющихся орнаментов – это эффективный способ выделить его среди других блоков страницы. В нашем случае декомпозированным блоком является блок A2.
Чтобы перейти к блоку A2, декомпозиция которого представлена на текущей странице, воспользуйтесь командой Parent в меню Select. Если к этому времени вы по каким то причинам переместились с диаграммы третьего уровня в другое место, используйте команду Page… в том же меню. В результате выполения этой команды на экране будет отражена иерархия уровней вышей модели (см. рисунок).

Рисунок 18. Структура модели.

Щелкните кнопкой мыши на уровне P2. На появившееся диаграмме выделите блок A2 «Найти решение». Выберите в поле Fill в меню EditSet AttributesDecomposed понравившиеся вам орнамент и щелкните кнопкой мыши на поле OK. Чтобы текст в заполненном блоке выделялся на фоне орнамента, поменяйте шрифт с простого на жирный, воспользовавшись командой Box Text там же.
Прежде чем закончить работу с диаграммой третьего уровня, рассмотри ситуацию, связанной с пропуском одной из функций. Допустим, что при декомпозиции функции «Найти решение» вы забыли о вычислении значения параметра n и разместили на диаграмме третьего уровня три функциональных блока, вместо четырех.
В данном случае можно удалить три имеющихся блока и создать четыре новых. Но если вы уже внесли в эти блоки информацию, которую вам не хочется печатать заново, то возможен другой способ – вставка дополнительного блока.
Вставка производится с помощью команды IDEF Box в меню Create. Выполнение этой команды приведет к изменению указателя мыши на указатель блока. Необходимо поместить указатель блока в то место диаграммы, где должен быть левый верхний угол дополнительного блока щелкнуть кнопкой мыши. В результате будет создан IDEF-блок, размеры которого определены по умолчанию.
Новый блок получит ближайший свободный IDEF-номер, в нашем случае A24. Поскольку этому блоку соответствует вторая на диаграмме функция, его номер следует изменить, воспользовавшись командой Renumber Box… в меню Edit. Появится диалоговое окно Renumber Box. В этом окне нужно пометить поле Renumber All Boxes и щелкнуть кнопкой мыши на поле OK. Блоки диаграммы изменят нумерацию на последовательную, начиная с выделенного вами дополнительного блока, номер которого сменится на A22.
Вставка дополнительного блока может привести к некорректному расположению блоков, не оставляющему места для размещения соответствующих дуг. На этот случай Design/IDEF предлагает несколько способов выравнивания блоков относительно друг друга.
I способ: изменение положения блока относительно двух смежных с ним блоков.
Для того, чтобы вставленный дополнительный блок (в нашем случае это A22) расположился посредине между смежными с ним блоками необходимо выделить его и выбрать команду Between из меню ModifyAlign. В поле состояния появится сообщение: «Select Node [box], Region or Page border as a Reference for Alignment» (Укажите узел [блок], область или контур страницы в качестве ориентира для выравнивания). Необходимо выделить первый из двух смежных блоков (в нашем случае – A21). Сообщение в поле состояния изменится на предложение выделить второй ориентир для выравнивания. В нашем случае им является второй из смежных блоков – A23. После его выделения блок A22 будет помещен между блоками A21 и A23 на равных расстояниях.
II способ: равномерное расположение всех блоков на странице.
Перед началом выравнивания блоков на странице, их необходимо сгруппировать. Чтобы сформировать группу, включающую все блоки текущей диаграммы следует нажать кнопку мыши, предварительно поместив указатель чуть левее и выше первого из блоков и не отпуская ее перемещать указатель, обводя все блоки выделяющим прямоугольником. После отпуска кнопки мыши, каждый блок группы будет заключен в широкую черную рамку, а указатель мыши превратиться в указатель группы.
Замечание: Группу можно создать и по другому: выделить первый блок, а потом щелкнуть кнопкой мыши при нажатой клавише Shift на остальных блоках. Случайный щелчок кнопкой мыши вне членов группы может ее отменить.
Последующее выравнивание блоков, входящих в состав групп осуществляется по команде Spread из меню Modify. На экране появится диалоговое окно, в котором необходимо выбрать, например, «Horizontal»,  «Vertical» или «Diagonal», т.е. выравнивание по горизонтали, вертикали или по диагонали.
После проведения выравнивания нужно отменить группу щелчком кнопкой мыши вне членов группы.
Иногда помимо равномерного размещения блоков на странице возникает необходимость в изменении их размера по определенному образцу. В Design/IDEF предусмотрена возможность выравнивания размеров блоков по одному из них. Для этого необходимо создать группу из блоков, размеры которых будут изменяться, и выбрать команду Same Size в меню Modify. В поле состояния появится сообщение: «Select Node [box] or Region as Model for Share Change» (Укажите узел [блок] или область в качестве модели для изменения формы).
После появления сообщения нужно поместить указатель внутрь блока, форма которого будет служить эталоном, и, как только его контур начнет мерцать, щелкнуть кнопкой мыши. После чего все блоки, входящие в состав группы будут совпадать по размерам.
Для завершения модели вам осталось провести декомпозицию функционального блока A23 «Найти численное решение», разместив на диаграмме четвертого уровня два функциональных блока: найти x, найти (x1б x2) (см. рисунок).

Рисунок 19. Диаграмма четвертого уровня.

На этом IDEF-модель рассмотренного примера завершена. Но прежде чем отправит ее на печать, рекомендуется просмотреть диаграммы для проверки IDEF0 синтаксиса. В программном пакете Design/IDEF такая проверка автоматизирована. Для этого выберите команду Validate… в меню File. В появившемся диалоговом окне пометьте все поля, начинающиеся со слова Check. В разделе Report Options пометьте поле Display on Screen. Этот параметр направит отчет на экран. После того как вы щелкните кнопкой мыши на поле OK на экран будет выдан отчет проверки IDEF0 синтаксиса диаграмм вашей модели (см. рисунок).

Рисунок 20. Отчет о проверки синтаксиса модели.

Рисунок 21. Блок-схема решения квадратного уравнения.

12.	Тема 7. Методология IDEF0 - назначение и правила формирования.
Методология IDEF0 (Integrated DEFinition) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Данная методология применяется при создании новых систем для определения требований и функций и затем для разработки системы, удовлетворяющей требованиям и реализующей функции. Для действующих систем эта методология может использоваться для анализа функций, выполняемых системой, а также для наглядного представления «механизмов», посредством которых эти функции осуществляются. Основной сферой применения методологии IDEF0 является предпроектное обследование и анализ системы.
Методология IDEF0 основана на методе SADT Росса. В рамках проекта ICAM, организованного военными ведомствами США с целью разработки подходов, обеспечивающих повышение эффективности проектирования благодаря систематическому внедрению компьютерных технологий, метод SADT и некоторые аспекты его применения были стандартизированы, после чего получили название методологии IDEF0. В соответствии с проектом ICAM было разработано семейство методологий IDEF, в которое кроме методологии создания функциональной модели сложной системы IDEF0 вошли еще две самостоятельных методологии моделирования:
- IDEF1 – методология создания информационной модели производственной среды или системы (основана на реляционной теории Кодда и использование ER – диаграмм Чена);
- IDEF2 – методология создания динамической модели производственной среды или системы.
Модель IDEF0 представляет собой набор диаграмм с поддерживающей их документацией, включающей сопровождающие тексты и словарь. Диаграммы модели декомпозируют сложный объект на составные части. Первоначальная (исходная, корневая) диаграмма является наиболее общим и наиболее абстрактным описанием всей системы в целом. Она показывает основную функциональную составляющую системы в виде блока. Детали (компоненты) каждого из основных блоков показаны на других диаграммах в виде блоков. Далее они могут быть превращены в более подробные диаграммы, до тех пор, пока не будет достигнута требуемая степень детализации.
Правила включают:
• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
• связность диаграмм (номера блоков);
• уникальность меток и наименований (отсутствие повторяющихся имен);
• синтаксические правила для графики (блоков и дуг);
• разделение входов и управлений (правило определения роли данных).
• отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
13.	Тема 8. Методология IDEF1X - назначение. Правила формирования сущности, сущности зависимые и независимые от идентификатора.
Методология IDEF1 – это методология семантического моделирования данных, с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
IDEF1X использует подход сущностей-отношений к семанитческому моделированию. Основными конструкциями IDEF1X-модели являются: предметы, к которым относятся данные, т.е. люди, места, идеи, события и т.д.
Они изображаются блоками. Отношения между этими предметами, изображаемые соединяющими блоки линиями. Характеристики этих предметов, изображаемые именами атрибутов внутри блоков.
Сущность представляет множество реальных или абстрактных предметов (людей, объектов, мест, событий, состояний и т.д.), обладающих общими атрибутами и характеристиками. Отдельны элемент этого множества называется экземпляром сущности. Реально существующий объект может быть представлен в нескольких сущностях модели данных.
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.

Правила
1.	Каждая сущность должна иметь уникальное имя и к одному и тому же имени должна применяться одна и та же интерпретация.
2.	 Сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через отношение.
3.	Сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности.
4.	Каждая сущность может обладать любым количеством отношений с другими сущностями модели.
5.	Если внешний ключ целиком используется в качестве первичного ключа сущности или его части, то сущность является зависимой от идентификатора. И наоборот, если если используется только часть внешний ключа или вообще не используются внешние ключи, то сущность является независимой от идентификатора
6.	Отношение связи- это связь между сущностями, при которой каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным количеством экземпляром второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя.
14.	Тема 9. Семантика отношений связи. Мощность отношений связи. Идентифицирующее и не идентифицирующее отношение. Отношения категоризации. Правила отношений категоризации.
Отношение связи - это связь между сущностями, при которой каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя.
Отношение связи может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).
В IDEF1X могут быть выражены следующие мощности связей:
• каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;
• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка. Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями). Пунктирная линия изображает неидентифицирующую связь. Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
Некоторые реально существующие сущности являются категориями других сущностей. В IDEF1X-модели они связаны друг с другом через категориальное отношение. Сущности-категории являются взаимоисключающими. Существует также отношение неполной категоризации, когда имеется экземпляр общей сущности, не связанный ни с каким экземпляром из сущностей-категорий.
Правила отношений категоризации
- Сущность-категория может иметь только одну общую сущность.
- Сущность-категория не может быть сущностью- потомком в идентифицирующем отношении.
- Атрибуты первичного ключа сущности-категории должны совпадать с атрибутами первичного ключа общей сущности.
- Атрибуты представляют тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов. Экземпляр атрибута определяется типом характеристики и ее значением. Атрибуты изображаются в виде списка имен внутри блока сущности.
15.	Тема 10. Семантика атрибутов. Правила атрибутов. Первичные и альтернативные ключи. Правила первичных и альтернативных ключей. Правила внешних ключей
Атрибут – это описательное свойство или характеристика сущности.
Правила атрибутов
- Каждый атрибут должен иметь уникальное имя.
- Сущность может обладать любым количеством атрибутов.
- Сущность может обладать любым количеством наследуемых атрибутов.
- Каждый экземпляр сущности должен иметь значение для каждого атрибута (правило необращения в ноль).
- Ни один из экземпляров сущности не может обладать более чем одним значением для связанного с сущностью атрибута (правило неповторяемости).
- Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Первичный ключ - потенциальный ключ, который будет в большинстве случаев использован для однозначной идентификации единственного экземпляра сущности. Альтернативный ключ – это любой непотенциальный ключ, который не установлен в качестве первичного.
Правила первичных и альтернативных ключей 
- Каждая сущность должна обладать первичным ключом.
- Каждая сущность может обладать любым числом альтернативных ключей.
- Первичный или альтернативный ключ могут состоять из одного атрибута или комбинации атрибутов.
- Один атрибут может быть частью более чем одного ключа, первичного или альтернативного.
- Атрибуты, входящие в первичные ключи сущности, могут быть собственными для сущности или наследоваться через отношения.
- Первичные и альтернативные ключи должны содержать только необходимые для однозначной идентификации атрибуты, т.е. при исключении из ключа любого атрибута не все экземпляры сущности могут быть однозначно определены.
- Если первичный ключ состоит более чем из одного атрибута, то значение любого неключевого атрибута должно функционально зависеть от всего первичного ключа (правило полной функциональной зависимости).
- Каждый неключевой атрибут должен функционально зависеть только от первичного и альтернативных ключей, т.е. значение неключевого атрибута не может определяться значением другого неключевого атрибута (правило отсутствия транзитивной зависимости).
- Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.
Правила внешних ключей
- Каждая сущность должна содержать отдельный внешний ключ для каждого отношения связи или категоризации, в котором эта сущность является сущностью-потомком или сущностью-категорией.
- Первичный ключ общей сущности должен наследоваться в качестве первичного ключа для каждой сущности-категории.
- Каждый наследуемый атрибут сущности-потомка или сущности-категории должен представлять атрибут из первичного ключа связанной родительской или общей сущности.
- Каждый атрибут первичного ключа родительской или общей сущности должен быть наследуемым атрибутом в связанной сущности-потомке или сущности – категории.

Возможные методики проектирования отличаются по последовательности использования результатов анализа (функциональных и информационных моделей):
1. Последовательное использование моделей разных уровней иерархии.
2. Использование моделей нижнего уровня иерархии.

15.1	Последовательное использование моделей

Рисунок 22. Нулевой уровень

Рисунок 23. Первый уровень

Рисунок 24. Второй уровень - представление процесса Р2

Рисунок 25. Второй уровень - представление процесса Р3

Рисунок 26. Представление процесса Р2

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

ЧЕТЫРЕ ШАГА ПРОЕКТА  РЕИНЖЕНИРИНГА
•	
МОБИЛИЗАЦИЯ

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

ДИАГНОСТИКА

•	Выбор и определение масштабов процесса
•	Понимание потребностей клиентов
•	Понимание текущего процесса
•	Определение недостатков в существующем проекте
•	Определение целей для нового проектирования

РЕИНЖЕНИРИНГ

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

РЕАЛИЗАЦИЯ

ПОЛУЧЕНИЕ РЕАЛЬНОГО РЕЗУЛЬТАТА

•	Формулирование стратегии воплощения
•	Изготовление прототипа реальной системы
•	Конструирование и “монтаж” измененной компании
•	Разработка подведомственной инфраструктуры
•	Развертывания и официальные регламентации

•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	
•	

Параллельное компонентное проектирование ИС.
На практике при отсутствии идеальных схем, полезно развивать циклическую схему с применением методов компонентного и параллельного проектирования с использованием интеграции компонентов на основе понятийных моделей. 
В этом случае организация разработки может быть графически представлена как совокупность нескольких спиральных процессов параллельной разработки или адаптации нескольких компонентов ИС с их последующей комплексной стыковкой.
Такая организация называется “Параллельное компонентное проектирование"
Адаптивные схемы организации Н.С.П.
Н.С.П. не навязывает заказчику и разработчику общую для всех, типовую схему обязательного выполнения полного цикла работ по BPR, или тотальному реинжинирингу, или чему-нибудь подобному. С учетом реального положения с ИС, реальных нужд предприятия и реальной его готовностью к BPR выполняются те работы, которые может освоить это предприятие.
Тем не менее, в общем случае в Н.С.П. исследуется необходимость и возможность выполнения всех видов работ, потенциально необходимых предприятию. В силу этого, предлагается построение гибких организационных схем проектирования, заключающееся в построении и динамическом уточнении адаптивной организационной схемы, ориентированной на специфику конкретного предприятия, его внутреннее состояние и внешнее положение. Адаптивность проявляется также и в том, что строится схема, в соответствии с которой в процессе выполнения работ выбирается тот вариант проектирования и будущей ИС, для которого готово предприятие или может быть подготовлено за приемлемое время.
Начальными являются аналитические экспертные процедуры, определяющие состояние предприятия (организации) и его потребность в BPR  и готовность к нему.
ЗАКЛЮЧЕНИЕ
"Реконструкции самих по себе бизнес-процессов недостаточно. Организациям следует крепко усвоить, что в постоянно меняющейся, неопределенной среде абсолютно необходимо конструирование предприятия" (Мартин Дж.).
 Им перечисляются основные методы ИТ, которые будут служить технологической базой будущей киберкорпорации. Выделим из них два:
•	объектно-ориентированное моделирование, которое заменит структурные методы CASE-систем и позволит создавать приложения, напрямую моделируя процессы с выделением в них многократно используемых элементов работ; 
•	компонентное программное обеспечение, состоящее из генерируемых на основе шаблонов покупных компонентов и среды, позволяющей соединять компоненты и создаваемые объекты. 
Эти методы ИТ являются прямыми методами Нового Системного Проектирования, необходимость в которых предсказывалась давно В середине 90-х годов  необходимость в них стала предельно острой, в том числе для реализации смысловой интероперабельности компонентов на уровнях персональных и кооперативных метатехнологий.
Необходимость в активных понятийных моделях в качестве минимальных интегрирующих моделей подтверждается. В качестве стратегического плана и для корпораций, и для профессионалов в ИТ Мартин Дж. предлагает лучше проектировать стратегию развития: постоянны ситуации, в которых и специалисты, и корпорации не имеют стратегического плана своего развития, или выдают за него нечто другое, не зная того, в какую сторону и как следует развиваться. Это подтверждает, что третьим проблемным аспектом проектирования ИС является целенаправленная работа с людьми (самым сложным компонентом ИС) для ясного и рационального решения стратегических задач.
15.2.1	ДЕСЯТЬ ЗАПОВЕДЕЙ
1).Целесообразно сочетание двух правил:
 не поддаваться безоглядно на "горячие" лозунги модных течений и, одновременно,
 не пропускать настоящие изменения, которые должны включаться в практику проектирования.
2) Целесообразно исходить из того, что корпоративная ИС проектируется как информационно-управляющая система, включающая бизнес-архитектуру предприятия, его персонал, используемую ИТ-архитектуру, и является действующей частью т.н. "киберкорпорации", это значит, что в виде ИС проектируется часть предприятия, которая непосредственно осуществляет его "бизнес". 
3) Проектировать ИС как реализацию последовательности состояний системы в развитии ее функциональных возможностей, причем таких состояний, в каждом из которых ИС приносит те реальные (часто - частичные) полезные результаты, которые нужны "для сегодня", и содержит возможность развития для получения результатов, которые будут нужны "для завтра".4) Учитывать необратимость требований, фиксируемых в подходе BPR, таких как глобализация деятельности, снабжение работников всеми информационными и функциональными средствами для возможности самостоятельного принятия решений, предельное сокращение времени реакции на возникающие потребности и др.
5) Как ключевой элемент проектирования ИС осуществлять поиск, конструкторскую реализацию и информационно-функциональное обеспечение такого решения бизнес-архитектуры, которое обеспечивает "прорыв", т.е. такую организацию процессов, которая в реальности может обеспечить радикальное повышение итоговой эффективности деятельности предприятия.
6) Развивать применение понятийных моделей предприятий как базисного интегрирующего слоя, позволяющего управлять (хотя бы и в ручном режиме, через применение развитых тезаурусов) смысловой интеграцией отдельных предметных БД, потоков документов в workflow, отдельных прикладных компонентов.
7) Продолжать локально использовать структурные модели, но в улучшенной каскадной схеме работ, с применением прототипирования и других ускоряющих методов. Переходить на сочетание иерархических структурных моделей и открытых объектно-ориентированных подходов.
8) Организовывать проектирование как "Параллельное компонентное проектирование" - совокупность параллельных спиральных процессов разработки или адаптации нескольких компонентов ИС с их последующей комплексной стыковкой. Применять схему распределения ресурсов, ориентированную на такое проектирование 
9) Использовать принцип построения адаптивных схем организации проектного цикла, приспосабливаемых к реальным потребностям и возможностям предприятий в области проведения либо жесткого бизнес-реинжиниринга, либо менее радикального развития. Использовать в адаптивных организационных схемах процедуры и экспертизы, учитывающие специфику положения предприятия на местном рынке и реальную готовность руководства и остального персонала к реинжинирингу. Учитывать, что из трех составных частей Н.П.С. работа с "человеческим фактором" чаще всего является определяющей и наиболее критичной.
10) Закладывать возможности перехода к постоянному конструированию предприятия в будущем, учитывая в планах то, что оно будет вынужденно базироваться на закладываемом сегодня фундаменте Информационных Технологий, включая архитектурные решения, прикладные программы, а также методы совершенствования деятельности предприятий.
16.	МЕТОДЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ
Основы Объектно-Ориентированного Подхода
Объект - абстрактная или реальная сущность, обладающая индивидуальностью и поведением, и имеющая атрибуты, значение которых определяют его состояние.
Объект - является представителем некоторого класса однотипных объектов.
Класс - множество объектов, связанных общностью структуры и поведения.
Два вида декомпозиции предметной области:
1. По принципу "целое - часть" 
- на объекты.
      A состоит из B.
2. По принципу "общее - частное"
 - на классы.
      A является обобщением B. 
Поведение характеризует то, как объект воздействует или подвергается воздействию других объектов с точки зрения изменения состояния этих объектов и передачи сообщений.
Сообщение - воздействие одного объекта на другой с целью вызвать соответствующую реакцию (выполнить процесс).
Объекты и их взаимодействие

Процессы - изменяют значения атрибутов;
	    - формируют сообщения.
Атрибуты - определяют состояние объекта;
	    - определяют содержание сообщения.
ПРИНЦИПЫ ОБЪЕКТНОГО ПОДХОДА
1. Инкапсуляция 
2. Наследование
3. Полиморфизм
Инкапсуляция (скрытие информации):
- интеграция данных и допустимых процессов их обработки, запрещающая любой доступ к атрибутам объекта кроме как через его процессы;
- отделение внутренней структуры объекта (его реализации) от интерфейса с ним.

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

Отношения между объектами
Использование - возможность передачи сообщения от одного объекта к другому.
Включение - отражает отношение "целое - часть".
Отношения между классами
Наследование.
Использование.
Наполнение - отражает отношение между сборным классом, объекты которого составлены из других объектов,  и классом "других" объектов.
Метакласс - класс классов, позволяющий трактовать классы как объекты.
16.1	ПРЕИМУЩЕСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
- распараллеливание работ
- простота внесения изменений
- гибкая архитектура и модернизируемость
- повторное использование программных компонент
- естественность описания
16.2	НЕДОСТАТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
- психологические трудности
- начальные финансовые затраты
- замедление работы приложений из-за обращения к методу классов
- многочисленность операций и их вызовов
- интенсивный обмен сообщениями (при распределенной структуре)
16.3	ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА 
В результате ООА формируются:
1. Общее описание проблемы - краткое изложение всех основных функций, которые должны быть выполнены ПС.
2. Перечни 
	- объектов,	- атрибутов объектов,
	- процессов,	- атрибутов процессов.
3. Диаграммы
	- ORD - диаграмма отношений объектов;
	- CHD - диаграмма иерархии классов;
	- GCSD - диаграмма структуры "общее - частное";
	- W/PSD - диаграмма структуры "целое - часть";
	- STD - диаграмма переходов состояний.
Общее описание проблемы - для сложных приложений может выполняться итеративно и иерархически. 
Рекомендации по описанию:
1) Использовать только декларативные предложения вида:
- Существительное - глагол;
- Существительное - глагол - дополнение (объект);
- Глагол - дополнение (объект);
2) Обеспечить представление:
- всех нужных функций;
- основной информации и процессов;
- всех предложений на одном уровне абстракции, детализации и важности.
2.1. Перечень объектов, 
	1) Выделить все существительные
	2) Переписать в отдельный список все глаголы, относящиеся к этим существительным.
	3) Оценить каждое существительное из списка, является оно объектом или же только атрибутом объекта.
	4) Отделить объекты, принадлежащие области решений, от объектов, принадлежащих области проблем.
	5) Присвоить имя объектам, принадлежащим области решений.
2.2. Перечень процессов, 
	1) Выделить все глаголы и переписать их в отдельный список.
	2) Оценить каждый глагол из списка, является ли он процессом.
	3) Отделить процессы, принадлежащие области решений, от процессов, принадлежащих области проблем.
	4) Присвоить имя процессам, принадлежащим области решений.
	5) Приписать процессам объекты, если объект преобразуется процессом или данные объекта считываются процессом.
	6) Оценить (по имеющейся процедуре) приписывание процессов объектам.
17.	ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ 
Основные шаги ООП. 
1) Размещение объектов по поддоменам: пользователь, технические средства, программное обеспечение  или данные.
2) Разработка событийно-временных диаграмм для каждого множества взаимодействующих процессов и их объектов.
3) Определение обслуживающих объектов, которые необходимо использовать.
4) Разработка диаграмм Буча.
5) Определение передачи сообщений.
6) Разработка диаграмм процессов.
7) Разработка спецификаций модулей
Диаграммы Буча

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

18.	ФУНКЦИИ И ТИПОВАЯ ОРГАНИЗАЦИЯ СУБД 
ОСНОВНЫЕ ТРЕБОВАНИЯ К СУБД:
1.адекватность отображения ПО
2.выполнение правил, по которым функционирует ПО
3.контроль за состоянием БД
4.анализ и оценка ситуаций в БД
5.контроль используемых типов данных
ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
1.многопользовательский режим
2.многоплатформенность
3.развитие БД
4.многофункциональность
5.поддержка общепринятых стандартов сетевого обмена
6.поддержка стандартов межпрограммных интерфейсов
7.управление распределенными БД
СОСТАВ И ОРГАНИЗАЦИЯ СУБД: 
1.комплекс поддержки БД 
2.комплекс инструментальных средств
3.комлекс сопровождения приложений
4.комплекс обеспечения услуг

19.	КОМПЛЕКС ПОДДЕРЖКИ БД  
Ядро СУБД.
Программные системы, поддерживающие работу с распределенными БД. 
Работу в разнородной машинной среде. 
Сетевые конфигурации.
Программное обеспечение параллельной работы.
Реализация функций языка запросов.
Комплекс инструментальных средств:
•	программные системы для системных пользователей (системные аналитики, системные программисты, аналитики-постановщики задач и др.)
•	средства развития систем автоматизации
•	(объектно-ориентированное проектирование и программирование) 
•	комплекс сопровождения приложений:
•	пакеты прикладных программ в области
финансовой деятельности,
производства,
кадрового обеспечения,
подготовки и принятия решений.
Комплекс услуг:
•	предпродажные консультации,
•	консультации по вопросам системной интеграции,
•	техническое сопровождение систем,
•	обучение специалистов.
Основные функции  ядра СУБД:
1.управление данными во внешней памяти
2.управление буферами  оперативной памяти
3.управление процедурами
4.управление правилами
5.управление событиями
6.управление транзакциями
7.журнализация  и  восстановление БД
8.защита данных
9.поддержка единого интегрированного языка запросов: процедуры, правила, события.
Цели и задачи:
1) централизованный контроль доступа к данным
2)одновременное использование процедур
3)снижение трафика сети
4)поддержка целостности БД
Правила (триггеры):
1)обработка ситуаций при изменении состояний БД
2)обеспечение целостности по ссылкам (внешние ключи)
События:
синхронизация процессов обработки
обработка транзакций
Свойства acid-транзакций
1)атомарность
2)согласованность
3)изолированность
4)долговечность
Структура транзакций 
Обработка и фиксация транзакций
Журнализация транзакций

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

В экономической литературе : "предел допустимых издержек" иногда назывался "границей терпения. Рекомендовалось рассматривать интервал терпения, как тот интервал времени, в течение которого конфликты в отрасли или на предприятии случаются все чаще и носят все более обременительный характер
Поведение руководителей, не осуществивших своевременные инвестиции, во многих случаях может быть легко понято.  Инвестиции надо осуществлять заранее, часто - задолго до наступления "границы терпения" или, что  то же, достижения "предела допустимых издержек". В то же время, покупаемый предмет "невидим", а прежний часто еще не износился! (Т.е. работает так же, как и пять или даже десять лет назад.) 
Инвестиционные альтернативы 
А) Альтернатива сохранения (  на рис. кривой "А"). За пределом Х издержки продолжают расти с еще большей скоростью. Последствий такого развития событий  --  упадок предприятия.  Этот вариант означает отсутствие инвестиций в новые технологии. 
Б) Пропорциональное развитие (на рис. кривой "Б").  ИС после окончания периода Т1-Т5 развивалась точно пропорционально росту ее использования за этот период. В случае "Б" для больших многопользовательских ИС рекомендуется считать, что При покупке готовой системы автоматизации зона принятия решения заканчивается не позднее 0.5 года до момента Х. При выполнении разработки собственной системы автоматизации зона принятия решения заканчивается не позднее, чем за год до момента Х. Этот режим инвестирования имеет  недостаток: сразу после ввода в действие новой ИС процесс повторяется: начинается рост объема издержек выше желательного или нормативного уровня. 
В) Улучшающее развитие показано кривой "В": после периода роста издержек производятся инвестиции, опускающие объем издержек ниже начального уровня двухлетней давности. (Точка начала выполнения работ по инвестиционной программе обозначена "В-н".) Это обеспечивает более длительную перспективу, в которой можно: 
•	вести себя по типу альтернативы "А" (т.е. не производить новых вложений) и все еще не входить в новую зону принятия решения, 
•	иметь тот резерв прочности, который позволит успешно реагировать на действия конкурентов или указания высшего руководства. 
Такое улучшение положения достигается не только за счет количественных параметров ИС (более мощный компьютер, чем в варианте "Б"), но и за счет перехода на более передовую технологию в методах обработки данных и интерфейсах пользователей.
 Рекомендуется считать: При покупке готовой ИС при улучшающем развитии зона принятия решения заканчивается не позднее 8-ми месяцев до момента Х. Сдвиг правой границы зоны "влево", как и в случае "Б", зависит от объема собственных работ по постановке задач и программированию своей ИС.
. В Таблице приведены оценки границ принятия решения в условиях хорошей организации работ. 
Правые границы зон принятия решений (в месяцах до момента X ) 
для двух вариантов инвестиционной политики 	

	Покупка готовой ИС без доработки (привязки) 

	Малый объем своей разработки или привязки (доработки) готовой ИС 

	Своя разработка или большой объем работ по привязке ИС 

Пропорциональное развитие 

	        5-6

	        6-8

	                 10-16 

Улучшающее развитие 

	       7-8

	        8-10

	                 12-18 

Рекомендации по выбору варианта инвестиционной политики и моментов принятия решения.
Рекомендуемая инвестиционная политика лежит между вариантами "Б" и "В". Однако, предпочтение отдается улучшающему развитию, обеспечивающему лаг роста издержек (отсрочку выхода на старый начальный уровень) минимум на один год. Коридор рекомендуемых решений показан на рис.3, где поведение по схеме "С" дает как минимум один год устойчивой конкурентоспособной работы вашего предприятия. 
В настоящее время опыт многих разработчиков, аналитиков и пользователей говорит о том, что в рассматриваемой области информационных технологий альтернативе улучшающего развития обеспечивает более дорогая, но функционально мощная, открытая и стабильно развиваемая СУБД. 
В соответствии со сформулированным предпочтением в случае покупаемых для ИС готовых решений зона принятия решения кончается за 7-9 месяцев до момента Х. 
Для ИС, предусматривающих собственные разработки, зона принятия решения кончается раньше на срок, необходимый для выполнения собственных разработок. В случае реализации среднего проекта, реализуемого за срок до 1-го года, зона принятия решения кончается за 18 месяцев до момента Х. 
На рис. серым отмечены соответствующие границы зон. 
Безусловно, предусмотрительный руководитель, имеющий возможности для инвестирования, должен начинать инвестиционную программу не доводя предприятие до правой границы принятия решения, и его предприятие не столкнется с предельным объемом издержек. 
R5 Варианты развития предприятия после инвестирования и выбор базовой программной системы.
После завершения работ, предусмотренных инвестиционной программой, процесс роста издержек может полностью повториться (с лагом роста в варианте "С") или пойти по более пологой кривой. 
Чем более эффективную по стоимости эксплуатации программную систему Вы приобретете, чем меньше будут расти издержки при росте числа пользователей, объема базы данных и из-за других факторов роста предприятия, тем более пологой будет кривая объема издержек. 
Стоимость эксплуатации - это экономическая категория, равная сумме всех издержек по пользованию товаром, возникающих после его покупки. Как известно, в общей стоимости потребления товара длительного пользования именно стоимость эксплуатации составляет большую часть - до 80% и более. 

Чем более мощное по функциям и уровню инструментов программное средство, тем меньше будут затраты на новые разработки или доработки готовой. АИС, купленной "под ключ". А такие доработки обязательно возникнут: потребуется формировать новые отчеты , появятся изменения в нормативных документах, придется изменять формы входных документов, и т.д., и т.п.. 
На рис.6 и 7показан коридор возможностей развития при выборе варианта инвестиций "С", но покупки либо менее эффективной системы SYS1, либо более эффективной в указанных отношениях системы SYS2, хотя и более дорогой в момент покупки. 
 Система SYS2 позволит делать либо меньшими следующие затраты после окончания такого же инвестиционного периода, либо увеличить период инвестиций, либо получить и то, и другое. Одновременно такая система позволит предприятию почти все время оставаться на более выгодных конкурентных позициях по сравнению с тем, которое выбрало систему SYS1. 
Неявно в различиях между SYS1 и SYS2 учитывается такой показатель качества системы, как стабильность ее развития в будущем, даже при смене типа компьютеров. Эта стабильность является основной защитой ваших инвестиций. Предпочтительней выбор той СУБД, которая позволит достаточно долго развивать вашу ИС в любых направлениях без отказа от имеющихся разработок, а лишь переходом к новым моделям аппаратуры и версиям базовых программных средств. 
Этот фактор является одним из ключевых. Руководителю надо учитывать два воплощения этого фактора: 
•	во-первых, собственно стабильность развития СУБД, и, 
•	во-вторых, соблюдение стандартов открытых систем, обеспечивающих переносимость приложений и данных, возможности подключения программ других фирм и др.. 
В области компьютерных технологий в настоящее время планируемое таким образом будущее лежит в интервале максимум трех - четырех инвестиционных циклов, т.е. от шести до девяти (редко - двенадцати) лет. 
Основное значение данного примера в том, что должен производиться выбор такой СУБД, при котором обеспечена пологовая кривая роста объема издержек в планируемом будущем. 
Резюме метода обоснованного инвестирования в программную технологию 

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

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

20.	ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ С АРХИТЕКТУРОЙ “КЛИЕНТ - СЕРВЕР”
технологии и модели “клиент-сервер”
взаимодействие компьютеров в сети и программ в сети
типы серверов (в зависимости от ресурсов)
системы с централизованной архитектурой
распределенный характер обработки
разделение функций  стандартного интерактивного приложения :
компонент представления (функции ввода и отображения данных)
прикладной  компонент (функции “приложения” – решаемой задачи)
компонент доступа к  информационным ресурсам (функции хранения и управления информационными ресурсами – файлы, базы данных и т.п.)
типы моделей распределенной обработки
модель файлового сервера (fs)
модель доступа к удаленным данным (rda)
модель сервера базы данных (dbs)
модель сервера приложений (as)

20.1.1	АКТИВНЫЙ СЕРВЕР
требования к реализации активного сервера
взаимная непротиворечивость отражение бизнес-правил по
контроль  за состоянием БД 
оповещение о возникновении всех происходящих в БД  изменениях
контроль типов данных
процедуры.  правила.  события в БД.

Журнализация транзакций
Надежность хранения данных.
Мягкие  и жесткие сбои.
Журнал изменений БД.
Стратегия “упреждающей записи”.
Протокол WAL. Откат транзакции.
Восстановление после жесткого сбоя.
Журнал и архивная копия.