- •Раздел 1. Проектирование асоиу.
- •1.1. Понятие асоиу.
- •1.2. Классификация асоиу.
- •1.2.1 Классификация асоиу:
- •1.2.2. Уровни управления. Классы аис для их поддержки. Характеристика классов
- •1.2.3. Структура асоиу на уровне подсистем. Характеристика подсистем
- •1.3. Основные принципы создания ас.
- •1.4. Стадии и этапы создания автоматизированной системы
- •1.4.1.Содержание программы обследования объекта автоматизации
- •1.4.2.Состав и содержание технического задания на создание автоматизированной системы
- •1) Общие сведения:
- •2) Назначение и цели создания (развития) системы;
- •3) Характеристика объектов автоматизации;
- •4) Требования к системе;
- •5) Состав и содержание работ по созданию системы;
- •6) Порядок контроля и приемки системы;
- •7) Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- •8) Требования к документированию;
- •9) Источники разработки.
- •1.5. Средства структурного анализа.
- •1.5.1. Методология функционального моделирования idef0
- •1.5.2. Функциональная методика потоков данных (dfd)
- •1.5.3. Методология idef3
- •1.6. Разработка концепции асоиу.
- •1. 6.1. Проектирование архитектуры
- •1.6.2. Проектирование пользовательского интерфейса
- •1.7. Информационное обеспечение асоиу.
- •1.8. Программное обеспечение асоиу.
- •1. 9. Назначение, характеристика и использование case-средств разработки асоиу
- •1.10. Основные методы проектирования асоиу
- •1. 10.1. Методы структурного проектирования
- •1. 10. 2. Метод объектно-ориентированного проектирования
- •Раздел 2. Системы обработки информации и управления в науке.
- •2.1. Системный подход в задачах анализа, моделирования и структурирования ис и асу образования и науки
- •2.2. Информационные системы в науке
- •2.2.1. Искусственные нейронные сети
- •2.2.2. Системы искусственного интеллекта
- •2.2.3. Экспертные системы
- •Раздел 4. Информационные системы в образовании.
- •4.1. Информационные системы как инструмент управления информационной средой образования
- •4.2. Корпоративные информационные системы образования в сети internet.
- •4.3. Распределенные и параллельные информационные системы. Процессы, коммутация и координация в распределенных и параллельных ис.
- •4.4. Предметная область информационных систем в образовательных технологиях.
- •4.5. Основные требования, предъявляемые к проектируемым информационно-вычислительным (информационным) системам в образовании.
- •4.6. Общая характеристика функций и содержания проектирования ис в образовании. Реализация проектных решений средствами новых информационных технологий.
- •4.6.1. Общие принципы и рекомендации по созданию баз библиографической, реферативной и полнотекстовой информации
- •4.7. Автоматизированные информационно-библиотечные системы
- •4.8. Информационные системы обучения и контроля знаний.
- •4.9. Информационные системы дистанционного образования
- •Раздел 5. Асоиу в образовании.
- •3Т:ХроноГраф Журнал
- •Коммерческие продукты с широким функционалом для различных нужд образовательного учреждения. Один из самых ярких примеров такой системы — «Сетевая Школа» и NetSchool.
- •Системы, созданные в рамках конкретного субъекта федерации или муниципалитета только для своих нужд, без возможности распространения данного опыта на соседние регионы.
- •1. Асуо-Контингент.
- •2. Асу на базе системы Oracle, созданная ргупс
- •Основные цели создания асу уз
- •Архитектура
- •Логическая модель
1.5.2. Функциональная методика потоков данных (dfd)
Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.
Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
внешние сущности;
системы/подсистемы;
процессы;
накопители данных;
потоки данных.
Внешняя сущность представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами, с которыми взаимодействует ИС.
После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами). Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации должны выполняться следующие правила:
правило балансировки - означает, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/ приемников данных может иметь только те компоненты, с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;
правило нумерации - означает, что при детализации процессов должна поддерживаться их иерархическая нумерация.
Мини спецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока)
• возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).
После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны.