
- •1 Автоматизированные системы
- •2 Автоматизированные системы управления
- •2 .1. Требования к асу в целом
- •2.2. Требования к функциям асу
- •2.3. Требования к подготовленности персонала асу
- •2.4. Требования к техническому обеспечению асу
- •2.5. Требования к программному обеспечению асу
- •2.6. Требования к информационному обеспечения асу
- •2.7. Требования к организационному обеспечению асу
- •2.8. Требования к лингвистическому обеспечению асу
- •2.9. Требования к правовому обеспечению асу
- •2.10. Требования к эксплуатационной документации на асу
- •2. 11 Требования безопасности
- •3 Жизненный цикл ас
- •3.1 Стадии и этапы создания ас
- •3.2 Модели жц ас
- •Информационные и коммуникационные технологии
- •4. 1 Технология разработки ас
- •4.2 Методология rad
- •4.3 Принципы системного подхода к созданию аис
- •Проектирование аис
- •5.1 Этапы проектирования данных
- •Информационная модель данных
- •Иерархическая структура данных
- •5.2.2 Сетевая модель данных
- •5.2.3 Реляционная модель данных
- •5.2.4 Объектно-ориентированная модель данных
- •Концептуальное проектирование
- •5.3.1 Модели описания предметной области и концептуальной модели данных:
- •5.3.2 Информационная модель данных
- •Типы связей.
- •5.3.3 Инструментальные средства проектирования автоматизированных систем. Понятие case- технологии.
- •1) По инструментального case- средства bPwin.
- •Понятие об информационно-вычислительной сети
- •6.1 Локальные и глобальные вычислительные сети
- •6.2 Технология Клиент-сервер
- •Основы защиты информации. Методы защиты информации
- •Список использованных источников
- •41 Иосу
5.2.4 Объектно-ориентированная модель данных
Объектно-ориентированную парадигму предложил доктор Кристен Нигард. Объектно-ориентированная модель данных – это развитие ОО программирования (ОО языки программирования С++, Java и др. являются результатом ранней работы Нигарда).
Традиционно информация и процедуры хранятся раздельно:
- Данные и связи между ними – в базе данных;
- Процедуры – в прикладной программе.
Объектная ориентированность позволяет хранить процедуры обработки сущностей вместе с данными.
ОО базы являются навигационными :доступ к данным производится с помощью связей, хранящихся внутри самих данных.
Сущности – замкнутые единицы, которые можно легко использовать повторно и перемещать в новое место (поведение сущности является частью самой сущности).
ОО модель поддерживает связи типа многие ко многим (n:n).
Применение ОО БД:
1.Для приложений, которые состоят из большого количества взаимодействующих частей, например, космические корабли, большие вычислительные сети. Каждая из этих частей обладает своим поведением, которое зависит от поведения других.
2. Для систем, которые обрабатывают большие объемы данных, например, БД, поддерживающая систему слежения за полетом космического аппарата и управления им, для моделирования интегрированных систем, необходимых при проектировании космических аппаратов и т.д.
3. Для приложений, осуществляющих предсказуемый доступ к данным, например, для проектирования и планирования больших сетей передачи данных. Сложность систем быстро возрастает, что ведет к трудностям отслеживания вида оборудования и его конфигурации.
Недостатки:
- Формулирование незапланированных запросов к ОО БД осуществляется не так просто как к реляционной, но такие запросы поддерживаются.
Замечание. Если ООБД рассматривать с точки зрения реляционных БД, то класс – это домен, т.е. выступает в роли типа данных в колонке.
Языки, используемые в ООБД:
ODL- язык определения объектов;
OQL – язык запроса объекта.
Синтаксис OQL очень похож на синтаксис SQL – 92 с расширениями для поддержки объектов.
ODL – используется для объявления структуры классов, включая свойства и сигнатуры операций. Однако реализация операций не входит в спецификацию ODL, поэтому нужен язык программирования – C++, Java или SmallTalk.
СУБД, реализующие ОО БД:
1. Oracle 8i – поддерживает гибридные объектно-реляционные БД. Использует язык манипулирования данными SQL. Объявленные классы используются как домены колонок.
2. ООСУБД Jasmin (продукт компании Computer Associates).
Концептуальное проектирование
5.3.1 Модели описания предметной области и концептуальной модели данных:
SADT модели
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.:
Модели IDEF – метод структурного анализа и проектирования – модели и соответствующие функциональные диаграммы;
DFD модели –диаграммы потоков данных;
ERD модели – диаграммы “сущность - связь”.
Методики описаний моделей:
IDEF0 Функциональное моделирование (Function Modeling Method)
IDEF1, IDEF1X Информационное моделирование (Information and Data Modeling Methods)
IDEF2 Поведенческое моделирование (Simulation Modeling Method)
IDEF3 Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4 Объектно-ориентированное проектирование (Object-Oriented Design Method).
IDEF5 Систематизация объектов приложения (Ontology Description Capture method)
IDEF6 Обоснование проектных действий (Design Rationale Capture Method)
IDEF8 Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9 Выявление и учет условий и ограничений проектирования (Business Constraint Discovery)
IDEF14 Моделирование вычислительных сетей для АС (Network Design)
Модели описания АС
Различают следующие модели систем: функциональные, информационные, поведенческие и структурные модели.
Структурные модели характеризуют морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Функциональная модель системы описывает совокупность выполняемых системой функций.
Информационные модели отражают структуры данных — их состав и взаимосвязи.
Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий, осуществляется привязка ко времени.
Функциональная модель. Нотация IDEFO.
IDEF0 - Функциональное моделирование (Function Modeling Method).
IDEF0 — это более четкое представление методики SADT. SADT — методика, рекомендуемая для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих пользователей, оборудование, ПО.
Разработку SADT-модели начинают с формулировки цели моделирования. Далее строят иерархическую совокупность диаграмм с описанием функций.
Недостатки SADT-моделей — их слабая формализованность для автоматического выполнения проектных. Достоинство - наличие графического языка диаграмм, удобного для восприятия человеком.
Методология IDEFO представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEFO отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями.
Методология IDEF0 используется на всех этапах жизненного цикла системы, но в основном применяется в предпроектном обследовании и анализе системы. Модель IDEF0 обеспечивает возможность обмена информацией о рассматриваемом объекте на языке, понятном не только аналитику и разработчику систем, но и специалисту эксперту в предметной области, пользователю, руководителю.
Методология IDEF0 включает в себя метод IDEFO, а также методы и процедуры его поддерживающие.
В методе IDEFО выделяют следующие составляющие:
- концепция метода;
- графический язык;
- процедура чтения диаграмм;
- метод построения модели;
- критерии оценки качества модели;
- процедуры контроля качества модели;
метод объединения модели.
В организационную поддержку метода IDEFO входят:
- метод групповой работы;
- формы документирования модели;
-процедуры согласования и утверждения модели;
способ ведения личных архивов моделей;
- процедура сбора данных.
Язык функциональной модели.
Модель IDEFO (SADT) представляет собой совокупность диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков на других диаграммах.
Разработку функциональной модели начинают с формулировки цели моделирования. Далее строят иерархическую совокупность диаграмм с лаконичным описанием функций.
Модели бывают 2 видов:
- AS-IS – модель, которая есть сейчас.
- TO-BE – модель, которая будет после внедрения АС.
Построение модели начинается с представления всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы.
О
писание
объектов и процессов в нотации IDEFO
выполняется в виде совокупности
взаимосвязанных блоков (рисунок ).
Рисунок – Вид изображения элементарного блока в IDEF0
Блоки отражают функции (работы. Названиями функций являются глаголы. Типичные примеры функций: планировать, разработать, классифицировать, измерить, изготовить, отредактировать, рассчитать, продать.
Число блоков на одном уровне иерархии — не более 8. Блоки в англоязычной литературе называют блоками ICOM (Input-Control-Output-Mechanism).
Блоки нумеруются (номер записывается в правом нижнем углу).
Алгоритм построения модели.
1) Построение блока исходной функции и интерфейсных дуг.
2) Блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме на несколько блоков, соединенных интерфейсными дугами. Декомпозиционные блоки определяют основные подфункции исходной функции, границы которых определены интерфейсными дугами. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма изображают одну и ту же часть системы.
3)Каждая из этих подфункций может быть декомпозирована подобным образом в целях большей детализации.
На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной (декомпозиционной) диаграммы.
Диаграммы должны строиться в удобном для чтения и анализа виде. Для этого не загромождать отдельные диаграммы большим количеством объектов и излишними пересечениями, изгибами линий. Количество диаграмм и степень детализации работ определяется исходя из глубины рассмотрения предметной области. При построении модели обязательно дать определение всем объектам в модели для того, чтобы сформировать словарь слов предметной области.
Иерархия модели приведена на рисунке.
Рисунок – Модель IDEF0
Стрелки и их взаимоотношение с блоками.
Дуги (стрелки) отображают множества объектов (данных), их имена — существительные.
Стрелки управления определяют условия выполнения функции. Примеры управления: требования, чертеж, стандарт, указания, план. Влияя на работу блока управление не трансформируется в результате выполнения функции. Может оказаться, что целью функционального блока является как раз изменение того или иного правила, инструкции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую информацию, должна рассматриваться не как управление, а как вход функционального блока.
Управление можно рассматривать как специфический вид входа. В случаях, когда неясно, относить ли стрелку к входу или к управлению, предпочтительно относить ее к управлению до момента, пока неясность не будет разрешена.
Стрелки входа. Вход представляет собой информацию (сырье), используемую или преобразуемую функциональным блоком для получения выходной информации.
Стрелки выхода. Выход — это информация (продукция), получаемая в результате работы функционального блока. Каждый блок должен иметь, как минимум, один выход. Действие, которое не производит никакого четко определяемого выхода, не должно моделироваться вообще.
Механизм отображает используемые средства, например: компьютер, оснастка, заказчик, фирма.
Комбинированные стрелки. В IDEFO существует пять основных видов комбинированных стрелок:
- выход — вход,
- выход — управление,
- выход — механизм исполнения,
- выход — обратная связь на управление,
- выход — обратная связь на вход.
Варианты выполнения функций и соединения дуг с блоками (Рисунок ).
Рисунок – Одновременное выполнение функций
Рисунок – Пример обратной связи
Различают семь типов связей между функциями
Значи-мость |
Тип связности |
Для функций |
Для данных |
0 |
Случайная |
Случайная |
Случайная |
1 |
Логическая |
Функции одного и того же множества или типа (например, "редактировать все входы") |
Данные одного и того же множества или типа |
2 |
Временная |
Функции одного и того же периода времени (например, "операции инициализации") |
Данные, используемые в каком-либо временном интервале |
3 |
Процедурная |
Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") |
Данные, используемые во время одной и той же фазы или итерации |
4 |
Коммуникационная |
Функции, использующие одни и те же данные |
Данные, на которые воздействует одна и та же деятельность |
5 |
Последовательная |
Функции, выполняющие последовательные преобразования одних и тех же данных |
Данные, преобразуемые последовательными функциями |
6 |
Функциональная |
Функции, объединяемые для выполнения одной функции |
Данные, связанные с одной функцией |
(0) Тип случайной связности: наименее желательный.
Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке .
Рисунок - Случайная связность
(1) Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке .
Рисунок - Процедурная связность
(4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок ).
Рисунок - Коммуникационная связность
(5) Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости (рисунок ).
Рисунок - Последовательная связность
(
6)
Тип функциональной связности.
Диаграмма отражает полную функциональную
связность, при наличии полной зависимости
одной функции от другой. Диаграмма,
которая является чисто функциональной,
не содержит чужеродных элементов,
относящихся к последовательному или
более слабому типу связности. Одним из
способов определения функционально-связанных
диаграмм является рассмотрение двух
блоков, связанных через управляющие
дуги, как показано на рисунке .
Рисунок -. Функциональная связность
В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 15, имеет следующий вид:
В = g(Б) = g(f(A))
Ниже в таблице представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.