2015-06-26
267
Уровень - это вид услуг, которые должны выполнятся на этом уровне, и средства, которыми эти услуги выполняются.
К средствам относится совокупность правил взаимодействия на определенном уровне, алгоритмы и программы, реализующие эти правила, все это определяется как протокол взаимодействия на определенном уровне.
ЭМВОС предполагает 7 уровней взаимодействия. Услуги предоставляются снизу вверх.
Физический уровень:
Обеспечивает физический контакт между системами и представляет верхнему уровню средства для передачи сигналов и информации (радиоканал, кабельный).
Канальный уровень:
Служит для побитовой передачи сигналов, кодовых комбинаций, обеспечивающих обнаружение и исправление ошибок, реализует средства повышения достоверности передачи (параллельная передача, обратная связь, кодирование). Возможна реализация средств тестирования канала, канальный уровень использует одно или несколько физических соединений.
Сетевой уровень:
Обеспечивает доставку блока информации в соответствии с адресом, указанным в заголовке блока.
Настроен в основном на передачу пакетов. Функции уровня:
- маршрутизация
- ретрансляция
- сетевые соединения
- мультиплексирование сетевых соединений - сегментация укрупнение
- обнаружение и исправление ошибок - упорядочение данных
- управление потоками
- передача срочных данных
- выбор и повторная установка службы
Транспортный уровень:
Обеспечивает прозрачную передачу данных между сеансовыми объектами и освобождает их от выполнения функций по организации надежной и эффективной передачи данных. В 3-х фазах транспортного уровня могут выполнятся следующие функции:
1. фаза установления соединения
- выбор сетевого соединения, наиболее удовлетворяющего требованиям сеансового объекта с учетом стоимости качества обслуживания;
- решение о целесообразности мультиплексирования или расщепления транспортного соединения с целью оптимизации использования сетевых соединений;
- выбор оптимального размера транспортного пакета:
- выбор функций, которые будут задействованы в фазе передачи данных;
- отображение транспортных адресов в сетевые;
- обеспечение идентификации различных транспортных соединений между одной и той же парой транспортных точек доступа;
- передача служебных данных.
2. фаза передачи данных
- доведение транспортных служебных данных до сеансовых объектов получателей; - упорядочение данных; - укрупнение данных; - сцепление данных; - сегментация данных;
- мультиплексирование или расщепление данных; - управление потоком;
- обнаружение и исправление ошибок; - передача срочных данных;
- разграничение транспортных и служебных данных; - идентификация транспортного соединения. 3. фаза разъединения соединения - оповещение о причине разъединения;
- идентификация разъединяемого транспортного соединения; - передача служебных данных.
Сеансовый уровень (уровень сессий):
Устанавливает сеансовые соединения (диалог) между двумя взаимодействующими представительными объектами и поддерживает информационный обмен между ними. - установление сеансового соединения; - разъединение сеансового соединения;
- обмен обычными данными; - обмен срочными данными; - управление взаимодействием; - синхронизация сеансового уровня; - оповещение об особых состояниях.
Представительный уровень:
Обеспечивает независимость прикладных объектов от используемого синтаксиса (от правил кодирования передаваемой информации). - запрос установления сеанса;
- согласование и повторное согласование синтаксиса; - преобразование синтаксиса; - запрос завершения сеанса.
Прикладной уровень:
Обеспечивает доступ в среду ВОС для прикладных процессов, которые обмениваются информацией посредством прикладных объектов, прикладных протоколов и служб представлений. Кроме передачи данных, прикладная служба (совокупность объектов прикладного уровня) может выполнять следующие услуги:
- идентификация партнеров, предполагающих взаимодействие;
- определение текущей готовности партнеров, предполагающих взаимодействовать;
- установление полномочий для передачи; - согласование механизма секретности;
- аутентификация (узнавание) партнера;
- определение методологии назначения цен, достаточности ресурсов, приемлемого качества
обслуживания; - синхронизация взаимодействующих приложений;
- выбор дисциплины диалога, включающей процедуры инициализации и завершения;
- согласование ответственности за обнаружение ошибок и процедур управления целостностью данных; - идентификация ограничений по синтаксису данных
9 Основы концептуального проектирования БД
Этап концептуального проектирования связан с описанием и синтезом разнообразных информационных требований пользователей в первоначальный проект баз данных. Результатом этого этапа является высокоуровневое представление информационных требований, например, такое как диаграмма «сущность-связь». Основу этой диаграммы составляет набор сущностей, который представляет или моделирует определенную совокупность сведений, специфицированную в требованиях. Сущности могут быть описаны атрибутами, позволяющими детализировать свойства сущности. Один или несколько атрибутов могут служить идентификатором для обозначения отдельных экземпляров сущности. Связи между сущностями отображают функциональные аспекты информации, представленной сущностями.
Существует несколько подходов к построению диаграмм типа «сущность-связь». Общим для всех подходов является набор из четырех основных проектных решений или шагов:
1. Определение сущностей.
2. Определение атрибутов сущностей.
3. Идентификация ключевых атрибутов сущностей.
4. Определение связей между сущностями.
Хотя существует некоторая общность мнений о необходимости этих шагов для построения информационной структуры, тем не менее нет общего соглашения относительно порядка их выполнения. Главное, что здесь необходимо, это чтобы первоначальная информационная структура была хотя бы частично независимой от процесса обработки, что позволит обеспечить гибкость процесса проектирования.
Подход к концептуальному проектированию обычно предполагает, что рассматривается представление одного-единственного пользователя. При этом возможно предположить, что таким единственным пользователем является администратор или проектировщик базы данных, который понимает требования всех пользователей и объединяет эти требования в полный набор согласованных спецификаций. Альтернативным является подход, в котором «интеграция представлений» выполняется как часть процесса концептуального проектирования.
Основы концептуального проектирования.
Концептуальное проектирование оперирует информацией, независимой от любой фактической реализации (т. е. от любой конкретной системы технического или программного обеспечения). Цель концептуального проектирования именно в том и состоит, чтобы представить информацию в доступной пользователю форме, не зависящей от спецификаций системы, но реализуемой несколькими системами.
Существует два подхода к концептуальному проектированию:
► Объектное представление;
► Моделирование сущностей.
Экспертные оценки концептуальной модели данных.
Метод экспертных оценок ставит следующие основные вопросы:
• Обладает ли концептуальная модель достаточной полнотой?
• Достаточно ли хорошо она отражает предметную область?
• Корректна ли она?
Подобные или более детализированные вопросы относительно всех аспектов системы (требований пользователя, программирования, операций и т. д.) не должны остаться без ответа. В процессе экспертизы выявляется все, что в проекте упущено, и это несомненно идет на пользу его полноте.
Корректность модели тщательно проверяется при анализе архитектуры системы. При этом требования пользователя к данным и процессам, а также к типизации процессов и данных рассматриваются с различных позиций.
В ходе экспертизы проекта исследуются особенности преобразования данных, т. е. процесс трансформации информационной модели в СУБД-зависимое представление. Первый шаг - определение правильности и полноты самой информационной модели. На следующем шаге исследуется СУБД-зависимое представление.
10 Нисходящая и восходящая технологии программирования.
Методы регламентирующие высокий профессиональный уровень написания программ независимо зли почти независимо от языка, операционной системы ЭВМ и решаемой задачи:
* система методов, способов и приемов разработки и отладки программ;
* совокупность организационно-административных и инженерно-технических средств поддерживающих создание, документирования, распространения и сопровождения программного продукта.
Для описания этих средств применяются графы, диаграммы и т.п. Унифицируется и стандартизируются административно-управленческие приемы и средства, коммуникатируются документация. Регламентируется этапность жизненного цикла программного продукта и применительно к этим этапам, разрабатывается нормативы производительного труда, надежность и качества изделий.
Основой технологии программирования служит модульность программы главной чертой которой является:
» стандартизация;
» паспортизация модулей;
» межмодульный интерфейс;
» унификация.
Технология программирования базируется на поэтапном построение программ, т. е. нисходящее и восходящее проектирование. Необходимость перехода к нисходящему проектированию при создании больших систем программного обеспечения стала очевидной в результате неудачных попыток по созданию программ из методов исходящего проектирования. Метод восходящего проектирования заключается в том, что вначале разрабатывается отдельные модули на языке низкого уровня, а затем они объединяются в систему. Поэтому недостатки проекта часто обнаруживаются только при отладке программного комплекса, т. е. оказывается, что множество модулей было написано и проверено только для того, чтобы быть затем забракованными. В противоположность этому при нисходящем проектировании сначала пишут и проверяются управляющие программы, а функциональные модули добавляют в процессе разработки системы. Таким образом, создание системы происходит путем её расширения уровень за уровнем с проверкой и объединением модулей в процессе программирования, а не после её окончания. На каждом уровне процесса проектирования отрабатываются программы обслуживания и определяются данные.
Нисходящее проектирование систем программного обеспечения обычно начинается с логического проектирования, обеспечивающего согласованную работу нескольких модулей, которым необходим доступ к совместно используемым данным.
Легко заметить, что преимущество нисходящего проектирования по сравнению с восходящим есть преимущество процесса при наличии обратной связи по сравнению с процессом без обратной связи. При восходящем проектировании программы не проверяются как составная часть системы до окончания разработки. При нисходящем же проектирование их проверяют сразу, в контуре системы. Если допущены ошибки в проектирование или в программирование, нисходящее проектирование позволяет обнаружить их на ранних этапах, когда программа еще находиться у разработчика. Восходящее же проектирование приводит к ошибкам, которые могут быть обнаружены только при комплексной отладки, когда разработчик модуля уже переключился на другую работу.
Разрабатывать программы с использованием метода нисходящего проектирования сложнее, чем применяя методвосходящего проектирования, но затраченные усилия окупаются на этапе объединения и отладки. Реализация метода нисходящего проектирования дает возможность предвидеть, что будет представлять собой система не только по окончанию разработки, но и на каждой промежуточной стадии. Продемонстрируем это на примере строительства поста. При проектирование моста на бумаге сначала изображают ферму, затем другие детали моста, в том числе опоры. Но для строительства моста нужен конструкторский план размещения каждой фермы и их соединений с помощью опор.
Разработка системы программного обеспечения методом восходящего проектирования напоминает проектирование моста на бумаге. Нужен только окончательный проект, и тогда можно надеяться, что и без «инструкторского плана все пойдёт гладко. К сожалению, людям, в том числе и конструкторам, свойственно ошибаться, поэтому реализация этого подхода сопровождается рядом трудностей.
11 Функции администратора ПО СУ ТП.
Администратор базы данных (АБД) - под этим понятием подразумевается лицо (или группа лиц, возможно, целое штатное подразделение), на которое возложено управление средствами базы данных организации.
АБД должен быть энергичной и способной личностью, организатором по призванию, желательно с техническим уклоном.
В его функции входит:
» координировать все действия по проектированию, реализации и ведению БД; учитывать перспективные и текущие требования пользователей; следить, чтобы БД удовлетворяла актуальным информационным потребностям;
» решать вопросы, связанные с расширением БД в связи с изменением границ ПО;
» разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секретности определенной части данных и разграничению доступа к данным;» выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность;
» следить за тем, чтобы БнД отвечал заданным требованиям по производительности, т. е. чтобы обработка запросов выполнялась за приемлемое время; -выполнять при необходимости изменения методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определять степень влияния изменений в данных на всю БД; -координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию;
» координировать работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы.
«координировать работы прикладных программистов, разрабатывающих новые ПП и выполнять проверку и включение прикладных программ в состав программного обеспечения системы И Т. П
12 Жизненный цикл ПО
Жизненный цикл - это развитие системы базы данных во времени.
Поэтому жизненный цикл базы данных можно разбить на следующие основные стадии:
» Проектирование;
» Эксплуатация;
» Вывод из эксплуатации.
Проектирование.
Та стадии проектирования разрабатываются технический и рабочий проекты. Техническое проектирование.
Во время технического проектирования базы данных проектировщик должен проделать следующую заботу:
1. Обследовать предметную область автоматизации.
2. Определить объекты и перечень их атрибутов, для каждого объекта выделить первичные ключи и провести нормализацию.
3. Установить все структурные, иерархические связи между объектами и все запросные связи, обеспечивающие обработку всех запросов пользователей и баз данных. Начертить схему проекта со всеми объектами и связями.
4. Выработать технологию обслуживания базы данных
5. Выбрать компьютер и инструментальные средства (конкретную СУБД) для реализации.
6. Проверить корректность проекта.
7. Определить сроки реализации банка данных.
Рабочее проектирование.
На стадии рабочего проектирования базы данных необходимо проделать следующие работы:
1. Описать средствами СУБД и ввести в ЭВМ схемы всех отношений.
2.. Разработать интерфейсы пользователей с базой данных.
3. Разработать программное обеспечение базы данных для всех приложений.
4. Заполнить базу данных контрольными данными и отладить ее.
5. Разработать контрольные примеры, провести тестирование системы и скорректировать технологию ее обслуживания.
6. Составить необходимые инструкции по системе и обучить пользователей.
Эксплуатация.
Ввод в эксплуатацию банков данных довольно длительный и сложный процесс, который предусматривает:
· Организацию сбора информации
· Заполнение БД
· Сдачу БД в эксплуатацию
· Реорганизация и реструктуризация при эксплуатации
Вывод из эксплуатации.
Существует правило, что сведенья из Базы Данных не должны уничтожаться, а передаются в Государственный архив. Срок хранения в архиве определяется ценностью информации. Так данные о заработной плате хранятся 75 лет. В архиве все хранится на магнитных лентах, поэтому вся База Данных переносится на твердый носитель. Выгрузка Базы Данных организовывается не по записям, а по полям. При этом может возникнуть сбой, если сдвинулся один из реквизитов. Поэтому при выгрузке Базы Данных происходит подсчет контрольных сумм в двоичном виде по строкам и по столбцам для нахождения сбоя в Базе Данных. Но при восстановлении утерянных символов существует опасность (10 процентов) получения неверного результата. Поэтому лучше заново загрузить блок. В этом случае надежность гарантируется.
13 Статические и динамические структуры данных, их особенности
Существуют динамические и статические объекты. У обычные переменные сразу после её описания резервируется область памяти, и эта область закрепляется за переменной на все время работы программы. Такого рода переменные называют статическими переменными. Часто бывает так, что какая-то переменная нужна не на всё время выполнение программы, а только на какую-то часть этого времени. Такие временные программные объекты могут занимать значительный объем памяти и одновременное существование всех таких объектов может потребовать столь большого объема машинной памяти, что соответствующая программа просто не сможет разместиться в ограниченной оперативной памяти машины. Переменные которые могут резервировать область памяти, а затем снова освобождать во время выполнения программы стали называть динамическими. Динамические объекты будут возникать в процессе выполнения программы, а действия над ними необходимо задавать уже до выполнения.
В Паскале для работы с динамическими объектами предусматривается специальный тип переменных, так называемый ссылочный тип. Каждому динамическому объекту в программе сопоставляется статическая переменная ссылочного типа. В терминах этих ссылочных переменных обосновываются действия над соответствующими динамическими объектами.
Динамические объекты и ссылки:
<имя ссылочного типа> = Л <имя типа>,
Где л - называемая «крышка», признак ссылочного типа,
<имя типа> - это имя либо статического, либо ранее описанного типа значения.
Рассмотрим листинг программы написанный на языке Паскаль:
Значение переменной p может быть ссылкой на динамический объект целого типа. Значение переменной q - ссылка на динамический объект литерного типа. Значение переменной RabMas - ссылка на динамический объект значение, которого является массив из 10 целых чисел. Значения статических ссылочных переменных указывают место в памяти соответствующего динамического объекта, поэтому переменные ссылочного типа часто называют указателями.
Динамическому объекту в отличие от статических не дается имен в обычном понимание этого слова. Для ссылки на динамический объект в Паскале имеется такое понятие как переменная с указателем: <имя переменной с указателем> = <ссылочная переменная> л, где <ссылочная переменная> - это имя той статической переменой ссылочного типа, которая в программе поставлена в соответствие данному динамическому типу.
«Крышка» после ссылочной переменной свидетельствует о том, что здесь речь идет не о значении ссылочной переменной, а о значении того программного объекта на которой указывает эта ссылочная переменная.
Отличия использования динамических переменных от статических переменных:
• вместо описания самих динамических переменных в программе даются описания указателей(статических переменных ссылочного типа) поставленных в соответствие динамическим переменным;
• в подходящем месте программы должно быть представлено порождение каждой из динамической
переменной (в Паскале процедура New);
• для ссылки на динамическую переменную используется переменная с указателем.
Если в процессе выполнения программы некоторая динамический объект созданный ранее становиться не нужным, то его можно уничтожить, что позволит освободить оперативную память, которую он занимал.
