5.Базовые функции и операции информационныхтехнологий.

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

Управление жизненным циклом - определяет применение стандартных технологических процедур или операций.К таким базовым функциям относятся:

-документирование

-экспертиза

-гармонизация

-проведение изменений и дополнений (версионность)

-регистрация объектов

-отладка ошибок

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

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

Стандартизация Обеспечивается не для каждой информационной системы.

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

6.Эталонные модели информационных технологий.Особенности реализаци и эталонных моделей.Особенности реализации эталонных моделей. Цель любой эталонной модели - описание основных правил реализации систем в соответствии с требованиями стандартизации и верификации. Все стандартные зталонные модели определяются международными организациями по стандартизации.Эталонная модель взаимосвязи отдельных систем OSI RM(Open SystemInterconnection Reference Model)

Стандартизация взаимосвязи системы охватывает три уровня описания средств информационного обмена.Информационный обмен необходим для обеспечения построения распределенных информационных систем. Первый уровень(«Концептуальный») определены основные понятия и общая структура взаимосвязи.Описываются принципы построения системы базовых стандартов, определяется язык и методологические основы построения и описания стандартов.Представитель первого уровня - модель ВОС для построения сетевых стандартов.

Второй уровень.Определяется спецификация сервиса или услуг.

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

Эталонная модель окружений открытых систем РOSIX OSE RM (Portable Operating System Interfaсе for Computer Environments Open System Environment Reference Model)Модель разработана комитетом IEEE.

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

Механизмы:

Применение POSIX OSE обеспечивает следующие механизмы:

Переносимость приложений на уровне исходных текстов. Системная интероперабильность - возможность взаимодействия модулей различныхпроизводителей.Переносимость пользователей - обеспечение возможности для пользователей работать на различных платформах без переобучения.Адаптируемость к новым стандартам.

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

Масштабируемость прикладных систем.

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

Прозрачность реализации, т.е. выделение реализации интерфейса.

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

-Интеграцию информационной системы из компонент различных производителей.

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

Открытая система - это система информационных технологий, реализующая окружение открытых систем или OSЕ-стандарт.

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

7.Процесс проектирования систем. Удачный проект. Основные принципы проектирования. Рациональный процесс проектирования. Удачный проект Удачным проектом мы назовем тот, который удовлетворил ожидания заказчика, уложился во временные и финансовые рамки, легко поддается изменению и адаптации.Ясное представление об архитектуре создаваемой системы;

Хорошо организованный итеративно развивающийся процесс работы над проектом.

Архитектура

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

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

Существуют стратегические и тактические решения.

Стратегическое решение имеет важное архитектурное значение и связано с высоким уровнем системы - механизмы обнаружения и обработки ошибок

-парадигмы интерфейса пользователя

-политика управления памятью

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

-протокол класса

-сигнатура метода

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

Пять уровней зрелости рациональных процессов (по Хэмфри):

Начальный - Процесс разработки хаотичен.

Воспроизводимый - Opганизация в разумной степени управляет своими планами и обязательствами. Определенный - Процесс разработки в разумной степени определен, понятен и применяется на практике; он позволяет выбирать команду и предсказывать ход разработки (следующая цель - оформить выработанную практику разработки как инструментальную среду).

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

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

8.Микропроцесс проектирования. Выявление классов и объектов. Выяснение семантики классов и объектов. Выявление связей между классами и объектами. Реализация классов и объектов.Микропроцесс проектирования

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

выявление классов и объектов на данном уровне абстракции;

выяснение семантики этих классов и объектов;выявление связей между этими классами и объектами;спецификация интерфейса и реализация этих классов и обьектов.

Выявление классов и объектов

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

Таким образом, словарь данных - центральное хранилище относящихся к системе абстракций.

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

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

Порядок действий:

Применение классического подхода к классификации, чтобы получить множество кандидатов в классы и объекты.

Исследование последовательности событий (появятся абстракции первого и второго порядка.)

Применение техники анализа поведения и выявление абстракции, которые непосредственно связаны с функциональными точками системы. Функциональные точки системы берутся из макропроцесса и представляют отдельные проверяемые и внешне наблюдаемые поведения системы.

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

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

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

Результаты.

-Уточнение словаря данных

-Выражение интерфейсов на языке реализации (Получение общего каркаса схемы данных)

-Составление диаграммы объектов и диаграммы взаимодействий

С этим шагом связано три вида деятельности:

-раскадровка

-проектирование изолированных классов

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

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

Проектирование изолированных классов

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

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

-Создание диаграмм классов, на которых указываются ассоциации между абстракциями.

-Добавление к ним деталей,полученных на предыдущем шаге (операции и атрибуты некоторых абстракций).

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

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

Порядок действий:

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

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

Реализация классов и объектов

Цель - создание осязаемого представления наших абстракций путем выпуска последовательных исполнимых версий системы (макропроцесс).

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

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

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

Рассмотреть объекты, которым можно делегировать обязанности.

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

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