Компонентно-орієнтоване програмування:Іспит

Матеріал з USIC Wiki

Перейти до: навігація, пошук
Для ФІН

Ця стаття відноситься до групи довідкових статей для студентів ФІН.


Зміст

Модуль як категорія функціональності та задача модуляризації програмних систем. Різниця в декомпозиції систем для основних методологій: структурної та об’єктно-орієнтованої.

СКАЗАНО НА ПАРІ

Перша задача модульного принципу – застосувати невеличкий інформаційний ресурс для запуску і виконання складних програм. Друга задача – допомога організації та збереження досвіду програмістів у виглядів початкового коду, або бінарного коду, або певних скомпільованих частин.

Визначається один головний мейн-модуль, що з’єднує решту модулів програми.

Структурна декомпозиція виходить з функціональності продукту.

Обєктно-орієнтований спосіб – чорна скринька об’єкта, з атрибутами та методами, що визначають спосіб імпорту і експорту даних.

Модуль — выделенная по мотивам функциональности часть первичного материала программного фонда. Помимо исходных текстов программ к первичным материалам относятся:

  • тексты исходных данных,
  • тексты указаний об атрибутах выделенных частей программных материалов (автор, решаемая задача, дата написания программы и т. д.),
  • тексты процедур, применяемых к программным материалам (например, указание «транслировать и результат поместить в указанную библиотеку», «запустить модуль с такими-то данными»);
  • сопроводительная документация, для которой не менее актуальны разбиение на отдельные модули и формирование из них тех или иных конфигураций выходных документов.

Вторичные объекты программного фонда:

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

Версия или точнее конкретная конфигурация программы — совокупность первичных материалов, участвующих в порождении загрузочного модуля. Задача конфигурирования важна, однако почти всегда выполняется вручную.

Два способа создания поддержки программного фонда :

  1. на соответствующем этапе ЖЦ (життєвий цикл) программный продукт отчуждается от разработчика и передается заказчику, который имеет дело с одним конечным кодом, т.е. версией системы;
  2. заказчику нужен не программный продукт, а только отчеты о решении наукоемких задач. Тогда разработчики строят инструмент конфигурирования программ, не заботясь о красоте и стройности кода, с помощью которого решаются задачи.

Модуляризация как расчленение программного материала на модули – непремен¬ный атрибут любого программистского проекта, поскольку с ростом размеров программы качество выполнения модуляризации играет важную роль в конечном успехе проекта. Модуляризация затрагивает все этапы ЖЦ создаваемого программного продукта: от первичной спецификации будущей программы (системы) – до удобств реинжиниринга и сопровождения программного продукта.

Різниця в декомпозиції систем для основних методологій: структурної та об’єктно-орієнтованої.

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

  1. "разделяй и властвуй" для разбиения сложных проблем на множество меньших независимых задач, легких для понимания и решения;
  2. иерархического упорядочивания для организации составных частей проблемы в иерархические структуры с добавлением новых деталей на каждом уровне.

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

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

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

Метод інженерії вимог І. Джекобсона.

СКАЗАНО НА ПАРІ

Опис програмного продукту через зазначання вимог до нього: функціональні і системні. Функціональні - що має робити продукт. Системні - щодо розмірів пам"яті, швидкодії тощо. З розмірів пам"яті випливали можливості декомпозиції на модулі. Цей метод виник тоді, коли інформаційний ресурс комп"ютерів був обмеженим, проте комп"ютери вже мали ОС. З цим методом стався революційний прорив. До цього програмний продукт специфікували набором мовних конструкцій. Наявність ОС дозволила перенести ряд функцій планування на неї.

Метод інженерії вимог І. Джекобсона (єдиний з усіх методів) вказує послідовний підхід до виявлення об'єктів, суттєвих для домену, і ґрунтується на варіантах (прикладах чи сценаріях) використання системи, яку треба побудувати

Декомпозиція складності проблеми:

  1. складна проблема трансформується на сукупність складових мети;
  2. кожна із складових мети трансформується у сукупність можливих прикладів використання системи;
  3. сценарії трансформуються в процесі аналізу їх у сукупність взаємодіючих об'єктів.

Актор - абстракція особи користувача як певної ролі ініціатора запуску роботи, поданої сценарієм, та обміну інформацією із системою.

Актор вважається зовнішнім фактором системи, дії якого мають недетермінований характер. Різниця між користувачем як конкретною особою й актором – роллю, яку будь-яка особа може грати в системі.

Актор в моделі заданий класом, а користувач — екземпляром класу. Для актора визначено такі правила:

  1. кожен сценарій може запускати тільки один актор;
  2. кожен актор може запускати кілька сценаріїв;
  3. взаємодія акторів в інтересах системи (тобто, як складова її функціональності) дозволяється тільки через передбачені для цього сценарії;
  4. актор не визначає сценарію, а лише ініціює ланцюжок подій, який визначить сценарій;
  5. для кожного актора визначаються його інтерфейси з тими сценаріями, які він запускає.

Сценарій – це повне протікання подій у системі і має стан та поведінку. Актори визначають зовнішнє оточення системи, а сценарії – її внутрішню суть.Для моделі сценаріїв є спеціальна графічна нотація. Між сценаріями можна два типи відношень:

  1. відношення "розширює" означає, що функції одного сценарію є доповненням до функцій іншого. Застосовується, коли маємо кілька варіантів того самого сценарію, тоді інва-ріантна його частина зображається як основний сценарій, а окремі варіанти змінної частини – як розширення. Основний сценарій стійкий щодо можливих випадків розширення його функцій;
  2. відношення "використовує" означає, що певний сценарій може використовуватися для розширення кількома іншими сценаріями (аналог процедури в мовах програмування).

Неформальний опис кожного сценарію: назва, анотація, актори, визначення всіх аспектів взаємодії системи з акторами, передумови, які визначають початковий стан, функції час виконання сценарію, виняткові ситуації, дії-реакції на передбачувані ситуації, умови завершення сценарію, постумови.

На подальших стадіях сценарій використання трансформується в сценарій поведінки системи.

Опис інтерфейсів подається неформально. інтерфейси визначають, якими бачать систему її користувачі.

Декомпозиція сценарію - провести такий вибір об'єктів, який дасть змогу забезпечити спроможність системи до адаптації в разі зміни умов або потреб використання системи. Тож стратегія вибору враховує принципи:

  1. зміна вимог неминуча;
  2. об'єкт має модифікуватися тільки внаслідок зміни відповідних вимог до системи;
  3. об'єкт має бути стійким до модифікації і сприяти розумінню системи;
  4. стійкість до модифікацій (стабільність) системи розуміється як їхня локальність, коли зміна кожної з вимог має вести до відповідних змін якнайменшої кількості об'єктів (в ідеалі одного).

Типи об'єктів розрізнюють залежно від їхньої схильності до змін. Для її оцінки простір, в якому функціонує система, структурований трьома вимірами:

  1. інформація, яку обробляє система (її внутрішній стан);
  2. поведінка системи;
  3. презентація системи (її інтерфейси з користувачами та іншими системами).

Впродовж ЖЦ найбільших змін зазнають вимоги до презентації системи.

Розглядаємо три типи об'єктів:

  1. об'єкти-сутності;
  2. об'єкти інтерфейсу;
  3. керівні об'єкти.

Об'єкти-сутності моделюють у системі довгоживучу інформацію, яка зберігається після виконання сценарію.

Об'єкти інтерфейсу містять функціональності, залежні безпосередньо від оточення системи й визначені в сценарії.

Керівні об'єкти перетворюють інформацію, введену об'єктами інтерфейсу і подану об'єктами-сутностями, на інформацію, що виводиться інтерфейсними об'єктами (тобто керівні об'єкти відповідають функціям переробки інформації).

Продуктами стадії аналізу вимог за методом Джекобсона є:

  1. онтологія домену (зазвичай як модель сутність-зв'язок П.Чена);
  2. модель сценаріїв;
  3. неформальний опис сценаріїв та акторів;
  4. опис інтерфейсів сценаріїв та акторів;
  5. діаграми взаємодії об'єктів сценаріїв.

Подальша деталізація проблеми за цим методом відбувається на наступних етапах життєвого циклу, при цьому зберігається трасування вимог, тобто відстеження відповідності об'єктів впродовж усіх етапів розробки.

Підхід Джексона як структурний метод аналізу і проектування. Діаграми взаємодії (послідовності і кооперації). Діаграми реалізації (компонентів і розгортання). Мова UML як стандарт моделювання.

Методология функционального моделирования SADT

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

  • графическое представление блочного моделирования.
  • строгость и точность.

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

Методологии Gane/Sarson

В основе данной методологии (методологии Gane/Sarson [11]) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.

Case-метод Баркера

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

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD).

Діаграми взаємодії (послідовності і кооперації)

Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень. Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии, отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.

Диаграмма коммуникации, Communication diagram (в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Діаграми реалізації (компонентів і розгортання)

Діаграма компонент — в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними. Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись. Модуль програмного забезпечення може бути представлено в якості компоненти. Деякі компоненти існують під час компіляції, деякі — під час компоновки, а деякі під час роботи програми. Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.

Діаграма розгортування (англ. deployment diagram) — в UML, діаграма, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах.[1] Компоненти відповідають представленню робочих екземплярів одиниць коду. Компоненти, що не мають представлення під час роботи програми на таких діаграмах не відображаються; натомість, їх можна відобразити на діаграмах компонент. Діаграма розгортування відображає робочі екземпляри компонент, а діаграма компонент, натомість, відображає зв'язки між типами компонент.

Метод UML як стандарт моделювання (Unified Modeling Language) визначають як мову для специфікації, візуалізації, конструювання й документування артефактів програмних систем, а також для моделювання бізнесу. В метод закладено парадигму об'єкт¬ного підходу, за якою концептуальне моделювання проблеми відбувається в термінах взаємодії об'єктів:

  1. онтологія домену визначає склад класів об'єктів домену, їхніх атрибутів та взаємовідношень, а також послуг (операцій), які можуть виконувати об'єкти класів;
  2. модель поведінки визначає можливі стани об'єктів, інциденти, що ініціюють переходи з одного стану в інший, повідомлення, які об'єкти надсилають один одному;
  3. модель процесів визначає дії, які виконують об'єкти.

В комплексі сукупність включених до методу діаграм відображає найважливіші випадки функціонування системи:

  1. діаграми класів (Class diagram);
  2. діаграми сценаріїв (Use-case diagram);
  3. діаграми поведінки об'єктів, а саме:
    • діаграми послідовності (Sequence diagram);
    • діаграми співробітництва чи кооперації (Collaboration diagram);
    • діаграми активності (Activity diagram);
    • діаграми станів (Statecards diagram);
  4. діаграми реалізації, а саме:
    • діаграми компонентів;
    • діаграми розміщення чи розгортання (Deployment diagram).

Кожний вид діаграм відображає різні перспективи бачення й розуміння моделі. У моделі може бути по кілька діаграм кожного з описаних видів.

Діаграма класів відображає онтологію домену і еквівалентна інформаційній моделі за методом С. Шлеєр та С. Мелора.

Атрибути можуть бути напередвизначеними в UML та мати такі значення:

  1. спільна (public);
  2. захищена (protected);
  3. приватна (private).

Операція – це сервіс, який може надавати екземпляр класу, якщо його викличуть. Операція має назву і список аргументів.

Асоціація – взаємна залежність між об'єктами різних класів, кожен з яких є рівноправним членом залежності.

Агрегація або відношення частина-до-цілого має таку особливість, що час існування об'єкта-частини збігається з часом існування об'єкта-цілого.

Спадкування підкласом властивостей суперкласу може мати позначку "один до багатьох". Різновидами спадкування можуть бути відношення узагальнення й спеціалізації

Альтернативна асоціація, коли деякий клас одночасно може перебудувати у зв'язку тільки з одним елементом певної множини класів.

Залежність між класами має різновиди: клас-клієнт може використовувати певний сервіс (операцію) іншого класу; класи можуть пов'язуватися відношенням трасування, коли один трансформується в другий унаслідок певного процесу ЖЦ; один клас може уточнювати другий.

Екземпляризація – залежність між параметризованим абстрактним класом-шаблоном (template) і реальним класом, який ініційовано шляхом визначення параметрів шаблону.

Зміст і нотація діаграми сценаріїв повністю збігаються з методом І. Джекобсона. Поведінка системи розглядається як обмін повідомленнями між об’єктами для досягнення певної мети. Різні сторони взаємодії об’єктів відображаються у різних діаграмах:

  1. діаграми послідовності демонструють впорядкованість взаємодії ото, обмін повідомленнями) в часі (уподовж лінії життя об'єктів);
  2. діаграми співробітництва (кооперації) демонструють ролі, які відіграють об’єкти під час взаємодії для досягнення певних цілей;
  3. діаграми активності демонструють потоки керування при взаємодії об'єктів;
  4. діаграми станів демонструють динаміку зміни станів об'єкті, під впливом перебігу подій (аналогічно до діаграм переходів у стани за методом Шлеєр-Мелора).

Призначенням діаграми компонентів є відображення структури системи як композиції компонентів і зв'язків між ними, як їх уявляє собі програміст..

Призначенням діаграми розміщення (розгортання) є визначення складу фізичних ресурсів системи та відношень між ними.

Пакет в UML –загальний механізм організації деяких елементів (об'єктів, класів, підсистем тощо) в групи. Групування можливе, починаючи від системи загалом і до підсистем різних рівнів деталізації, аж до класів. Пакет визначає назву простору, який займають елементи, що входять до його складу, і є засобом посилання на цей простір; це особливо важливо для великих систем з сотнями, а інколи тисячами елементів, що вимагають ієрархічного структурування. Підсистема в UML розглядається як різновид пакета, який має самостійну функцію. Групування в пакети може бути вкладеним, тобто складовими пакетів можуть бути класи, інші пакети та підсистеми.

Призначення пакета – бути елементом конфігурації, тобто елементом, який можна включати як визначену складову композиції в побудові певної системи.

Підхід Шлеєр-Мелора щодо аналізу доменів.

СКАЗАНО НА ПАРІ

Для конкретних предметних областей, моделює через певну категоріальну базу і інформаційну модель. Визначає, які є класи і зв’язки між ними. Звідси випливає єдине подання даних для показу причинно-наслідкових зв’язків між сутностями. Оптимальне подання даних. Відсутність зайвих перетворень для даних. Використовується в поєднанні з Джексоном.

Вимоги + структура і методи + онтологія.

Метод інженерії вимог С.Шлеєр та С.Мелора.

Продукти інженерії вимог за методом С. Шлеєр та С. Мелора:

  1. інформаційна модель системи (онтологія) у формі:
    • діаграми сутність-зв'язок;
    • опису об'єктів та їхніх атрибутів (подається неформально);
    • опису зв'язків між об'єктами (подається неформально);
  2. модель поведінки об'єктів системи у формі:
    • діаграми переходів у стани (ДПС) або таблиці переходів у стани (ТПС);
    • опису дій ДПС (подається неформально);
    • опису подій ДПС (подається неформально);
  3. модель процесів для станів об'єктів у формі:
    • діаграми потоків даних дій (ДПДД);
    • таблиці процесів станів;
    • опису процесів (подається неформально).

Програмна система розглядається як сукупність визначеного ряду доменів ПрО, кожний з яких аналізується незалежно від інших . Продукт аналізу домену – три складові, що будуються за три етапи:

  1. онтологія домену, яку звуть інформаційною моделлю системи або домену;
  2. модель станів об'єктів, визначених у складі інформаційної моделі (онтології);
  3. модель процесів, які супроводжують переходи з одного стану в інший.

(1) Коли будується онтологія домену, то шукаються суттєві об'єкти і встановлюються зв'язки (відношення) між ними. Знаходять об'єкти, дають їм унікальні та значущі назви. Категорій, серед яких шукати:- реальні предмети світу;

  • абстракції фізичних предметів світу ( тварина, літак);
  • ролі предметів, тобто абстракції їхнього призначення або мети використання. (платник податків)
  • інциденти, тобто абстрактні події, які впливають на зміну стану об'єкта(залік);
  • взаємодії, тобто об'єкти, які характеризують відношення об'єктів(перехрестя доріг);
  • специфікації або подання правил, стандартів, критеріїв якості, обмежень користування.

Подання інформаційної моделі в цьому методі ґрунтується реляційній моделі даних.

За моделлю П.Чена розрізняються три фундаментальних види зв'язку: 1:1, 1:n, m : n.

Інформаційна модель на наступних фазах ЖЦ програмної системи відображається на структури БД.

(2) Модель станів відображає динаміку змін, що відбуваються в стані кожного з визначених класів об'єктів, Базові поняття моделі динаміки поведінки об'єктів:

  • стан об'єкта визначається поточними значеннями окремих його атрибутів, а стан домену – сукупністю станів його об'єктів;
  • стан об'єкта змінюється внаслідок певних подій або з'ясування певних стимулів;
  • зміна стану супроводжується певними процесами, визначеними для кожного стану як такі, що мають відбутися після досягнення цього стану.

У методі Шлеєр-Мелора запропоновано дві альтернативні нотації для фіксації динамічних аспектів вимог як поведінки визначених об'єктів. Перша графічна зветься діаграмою переходів у стани (ДПС), а друга таблична - таблицею переходів у стани (ТПС).

Побудова моделі станів:

  1. визначити множину станів, в яких об'єкт може перебувати;
  2. визначити множину інцидентів чи подій, які спонукають об’єкти класу змінювати свій стан;
  3. визначити для кожного із зафіксованих станів правила переходу;
  4. визначити для кожного з станів дії або процеси, які треба виконати при набутті стану.

Дії виконуються екземпляром, який змінює стан. Подія, яка викликає зміни стану, є сигналом керування, що зазвичай передає якісь дані. Різновиди дій такі:

  1. обробка інформації, яку несе подія;
  2. зміна певного атрибута об'єкта;
  3. обчислення;
  4. генерація події для деякого екземпляра якогось класу (можливо, для самого себе);
  5. генерація події, що має передаватися зовнішнім щодо даного домену об'єктам, як-от людина-оператор, інша система, фізичний при-лад тощо;
  6. прийом повідомлення про події від зовнішніх об'єктів;
  7. взаємодія з двома спеціальними об'єктами -таймером та системним годинником.

Таймер – це механізм вимірювання інтервалу часу, який вважається вбудованим у даний метод системним об'єктом, що не потребує визначення. Атрибутами цього об'єкта є:

  1. унікальний ідентифікатор екземпляра таймера;
  2. залишок часу (інтервал часу, через який буде подано сигнал про настання певної події);
  3. мітка події, яка настане, коли залишок часу буде дорівнювати нулю;
  4. ідентифікатор екземпляра об'єкта, для якого встановлюється таймер.

Системний годинник – це також вбудований у метод об'єкт, атрибути якого – показники системного часу (години, хвилини, день, місяць, рік) – можна читати.

(3) Модель процесів описує дії, що супроводжують зміни станів об'єктів. Дії як алгоритми виконуються системою як реакції на події і визначають її функціональність. Проводиться декомпозиція дій на окремі складові, які отримали назву процесів. Послідовність виконуваних процесів утворює потік керування; воднораз процеси під час виконання обмінюються даними, що утворюють потоки даних; два зазначені типи потоків пропонується використовувати як моделі алгоритмів дій системи, для подання яких у цьому методі передбачена діаграма потоків даних дій (ДПДД). Джерела даних допускаються:

  1. атрибути об'єктів;
  2. системний годинник;
  3. таймери;
  4. дані подій;
  5. повідомлення зовнішніх об'єктів.

Процеси розрізняються за такими типами:

  • так званий аксесор, що здійснює доступ до архівів;
  • генератор подій;
  • перетворювач даних (обчислення);
  • перевірка умов.

Процеси і стадії життєвого циклу програмного забезпечення за ДСТУ 3918-99 (ISO/IEC 12207:1995)

СКАЗАНО НА ПАРІ

Каскадна модель встановлювала послідовність стадій життєвого циклу від специфікації вимог до процесу супроводу і багфіксу. Ця модель передбачала, що при виявленні помилки відкотитися можна лише на 1 етап назад. Проте більшість помилок виявляється на стадії тестування (передостанній крок), і тому їх здолати неможливо.

Системний підхід: отримання інструменту - користування інструментом, виявлення недоліків - далі назад - далі вдосконалення, повторення попереднього кроку враховуючи недоліки, які були виявлення під час експлуатації системи. Після кожного етапу - зворотній хід. Системний підхід слід уявляти як певну спіраль, по якій піднімаємося. Відстань між витками - релаксація - коли програмісти усвідомлюють накопичений досвід і якісно вдосконалюють продукт.

На кожному етапі життєвого циклу можна застосовувати однакові процеси покращення

ОСНОВНІ ПРОЦЕСИ ЖИТТЄВОГО ЦИКЛУ

  • процес замовлення (Acquisition process) - замовник висловлює побажання до розроблюваного продукту;
  • процес поставки (Supply process) - розробник оцінює замовлення, уточнює незрозумілі речі і погоджується;
  • процес розроблення (Development process) - жосткий кодінг;
  • процес експлуатації (Operation process) - впарювання замовнику для використання;
  • процес супроводу (Maintanance process) - тут зрозуміло.

Процес розроблення

Цей процес складається із таких дій:

  1. впровадження процесу;
  2. аналіз системних вимог;
  3. проектування архітектури системи;
  4. аналіз вимог до програмного забезпечення;
  5. проектування архітектури програмного забезпечення;
  6. розробка детального проекту програмного забезпечення;
  7. кодування та тестування програмного забезпечення;
  8. інтеграція програмного забезпечення;
  9. кваліфікаційне тестування програмного забезпечення;
  10. системна інтеграція;
  11. кваліфікаційне тестування системи;
  12. інсталяція (установка) програмного забезпечення;
  13. забезпечення приймання програмного забезпечення

Моделі життєвого циклу. До таких моделей належать моделі водоспаду, еволюційна. компонентна, запланованого удосконалення продукту, спіральна.

каскадна модель ЖЦ. Особливості цієї моделі:

  • послідовний порядок виконання усіх фаз ЖЦ; надання користувачу (замовнику) працюючого програмного виробу тільки на заключній фазі реалізації; низький рівень автоматизації робіт (особливо на початкових фазах) і погана інтегрованість інструментарію на окремих фазах ЖЦ; слабка взаємодія розробника з користувачем-замовником при створенні ПВ;
  • нерівномірність розподілу ресурсів на розробку, оскільки на кінцевих фазах ЖЦ потреба в ресурсах різко зростає.

На практиці спростована слушність одержання якісного продукту у разі послідовного вико-нання усіх фаз ЖЦ для широкого класу ПВ. Складність і розмаїття вимог до ПВ призводять до того, що на початкових фазах припускається левова частка помилок. Відомі приклади проектів, що потерпіли невдачу, оскільки з вичерпанням ресурсів наприкінці розробки був створений програмний продукт, що не задовольнив користувача (замовника).

Циклическая модель с возвратами (если что-то не устраивает, возвращаемся к предыдущим этапам).

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

Модель прототипов: создаётся начальный прототип, потом от него строится продукт. Но: прототип создаётся быстро, продукт долго. Данная модель позволяет уточнить постановку задачи.

Організація колективу розробників програмного продукту та забезпечення його якості. Управління проектом та підтримка розробки.

СКАЗАНО НА ПАРІ

Є людина, яка займається організаційними питаннями - Project manager.

Системний аналітик - бачить програмний продукт в цілому, моделює. Модель можна розбити функціонально за окремими модулями; або за етапами життєвого циклу. Аналітик визначає незалежні модулі і роздає програмістам, які працюють незалежно. Крім цього є група тестерів - незалежна від програмістів. Вони створюють тестові приклади, які тестують усі гілки програмного продукту, створюють тестувальний стенд. Цей стенд має бути підтвердженням роботоздатності системи. Розпаралелювання іде як за моделюванням, так і за стадіями життєвого циклу.

Project manager має спеціальні засоби для організації групової роботи. Системний перегляд: системний аналітик встановлює контрольні точки. При досягненні таких точок збираються всі бригади, і переглядається, хто з бригад відстає. Встановлюється інтерфейс між продуктами, розробленими різними бригадами, потім він оцінюється.

Организация коллектива разработчиков

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

Ядро: один пишет прототип, потом из него возникает продукт. Проблема: сложен переход.

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

"Хирургическая" бригада: главный "хирург", зам. гл. "хирурга", подмастерья. Работает для небольших комплексов, для больших проектов – плохо. Где найти главного "хирурга"? (Он должен быть и программистом, и руководителем).

Перекрёстные чтения модулей (заставляют писать лучше).

Microsoft Solutions Framework. Разработка больших и сложных программных продуктов довольно рискована; статистика показывает, что многие заканчиваются неудачей. Среди причин отметим:

  1. постоянное изменение требований;
  2. нечёткие или неполные спецификации;
  3. низкое качество кода;
  4. слишком широко поставленная задача;
  5. ошибки в подборе кадров;
  6. плохая организация работы;
  7. нечётко сформулированные цели.

Для решения проблем создания ПС служба Microsoft Consulting Services разработала набор моделей MSF (Microsoft Solutions Framework), в котором учтён опыт, накопленный группами разработки программных продуктов. Набор моделей MSF – это правила и спецификации, применяемые при создании и распространении программных продуктов, а также обеспечивающих более эффективное использование технологий для решения проблем бизнеса.

Team model – описывает, как должны быть организованы коллективы и какими принципами им надо руководствоваться для достижения успеха в разработке программ. Формирование коллектива – сложная задача (должна решаться психологами).

Не должно быть команды из одних лидеров; не должно быть команды из одних исполнителей;в случае неудачи – заново;финансовые штрафы (если проект провалился, наказывают всех)

Development (разработка) – тестирование, построение продукта (по исходным текстам получается текущая версия).

Program management (управление программой) – организация (ведение графика проекта, утренние совещания ~15 минут), соответствие спецификациям, стандартам, фиксация нарушений, написание технической документации.

Product management (управление продуктом) – написание спецификаций (возможно, заказчиком).

User education (обучение пользователей) – написание технической документации, обучающих курсов, повышение эффективности труда пользователей.

Logistics management (управление материально-техническим снабжением) – корректная установка и сопровождение, техническая поддержка продукта.

Testing (тестирование) – выявление и устранение недоработок, исправление ошибок.

Всё вышеперечисленное – это роли. За ними может скрываться >=0 человек. Поскольку реализация каждой из целей крайне важна для успешного выполнения проекта, соответствующие им роли равноправны в принятии всех решений. Единоначалия здесь нет; есть лишь коллектив, знающий, что делать, и располагающий всем, что для этого нужно.

Project tradeoff matrix. Заказчик должен буквально подписаться под этой матрицей и должен расставить приоритеты. Далее см. примеры матрицы.

Матрица для Microsoft: ресурсы – строго ограничены, расписание – можно позже, features – не обязательно (мультиверсионность).

Тестування програм та захисне програмування. Управління ризиком. Супроводження програмного продукту і задачі реінжинірингу.

СКАЗАНО НА ПАРІ

З появою крупномасштабних систем, що працюють в реальному часі (керування аеропортом) постало питання про те, що треба застосовувати спеціальні методи захисного програмування. Такі методи почали з"являтися в системах підтримки програмістських проектів, всередині мов програмування тощо. На підтримку захисного програмування з"явилися ТИПИ ДАНИХ. За допомогою типів даних можна встановити діапазон значень, що виключить ймовірність виникнення багатьох помилок. Кейс-системи при виконанні а+б перевірє, чи значення а є з простору значень а, а значення б є з простору значення б. Якщо використовувати захисне програмування - контроль ризиків.

Користувачі шлють повідомлення про помилки. Використовуючи ці повідомлення, розробники моделюють на своєму тестовому стенді ці помилки і виправляють помилки.

Управление рисками. Риск – неприятное событие, происходящее с некоторой вероятностью. Пишем список Top 10 risks: описание риска, вероятность риска (высокая, средняя, низкая), ущерб, вероятность ущерба.

Как бороться с рисками (risk mitigation strategies):

  • reduce the risk;
  • transfer the risk;
  • avoid the risk.

Причины возникновения риска:

  • организационные решения;
  • вопрос доступности (не можем до кого-то достучаться);
  • окружение (обстановка, люди, программное обеспечение);
  • новые технологии.

Process model – определяет, когда и какие работы должны быть выполнены. Принципы и практические приёмы, лежащие в основе модели:

  • итеративный подход (последовательный выпуск версий);
  • подготовка чёткой документации;
  • учёт неопределённости будущего;
  • учёт компромиссов;
  • управление рисками;
  • поддержание ответственности отношения коллектива к срокам выпуска продукта;
  • разбиение крупных проектов на более мелкие управляемые части;
  • ежедневная сборка проекта;
  • постоянный анализ хода работ.

Process model имеет три основные особенности:

  • разбиение всего процесса на фазы;
  • введение опорных точек;
  • итеративность.

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

Envisioning – выработка единого понимания проекта всеми членами коллектива. Vision document включает:

  • problem statement (описание проблем) ~ 1 стр.
  • vision statement (от чего хотим уйти, к чему хотим прийти) ~ 2-3 стр.
  • solution concept (что хотим внедрить…) ~ as necessary
  • user profiles (кто будет этим пользоваться)
  • business goals (возврат инвестиций, …)
  • design goals (конкретные свойства продукта: цели и ограничения)

Planning

  • functional specification
  • project plan + schedule
  • master risk assessment doc

Developing (building)

  • переиспользование,
  • защищённость (defensive),
  • programming by contract.

Stabilizing – появление стабильного продукта, готового к использованию.

Важную роль играют опорные точки (milestones), в которых анализируется состояние работ и производится их синхронизация.

Каждая фаза процесса разработки завершается главной опорной точкой (major milestone). Главные опорные точки – это критерий перехода с одной фазы проекта на другую.

Промежуточные опорные точки (interim milestones) служат для анализа и синхронизации достигнутого.

Postmortem. Checklists: что хорошо, что плохо, какие проблемы встретились. На их основе строится knowledge base.

Реинжиниринг

Есть работающая программа, но как она работает, никто не знает. Реинжиниринг – это есть:

  • преобразование программного продукта;
  • существенно более общее понятие, чем программирование.

Реинжиниринг похож на трансляцию. Но в отличие от трансляции занимается инфраструктурными преобразованиями:

  • ввод-вывод (раньше перфокарты, магнитные ленты);
  • диалог с человеком;
  • работа с базами данных.

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

Тестирование

Программирование – конструктивный процесс, требует высокой квалификации. Тестирование – деструктивный процесс, не требующий высокой квалификации (больше нужны дотошность и пессимизм), но повышающий качество продукта ( зростає його вартість).

Тестирование – процесс исполнения с целью нахождения ошибок. Хороший тест – с большой вероятностью находит ошибку. Как тестировать:

  • тестують не автори коду;
  • має бути конкуренція між прогерами і тестерами(писать с минимальным числом ошибок, тестировать с начала работ);
  • перевіряти помлкову поведінку (сообщения об ошибках должны быть осмысленными);
  • ймовірність помилки пропорційна числу знайдених помилок;
  • повинен бути чітко домовлений кінцевий результат.

Обычно малые фрагменты программы содержат большое количество ошибок.

Виды тестирования:

  • чёрный ящик (без просмотра исходного текста)
  • белый ящик
  • test-coverage – покрытие тестами возможных вариантов.
  • модульное тестирование
  • комплексное тестирование
  • получасовое тестирование
  • inspection peer review – нахождение ошибок просто при чтении текста.

Классы эквивалентности входных данных (не проверять все данные, а только классы). Граничные значения входных данных. Предположения об ошибках ("я бы сделал ошибку здесь").

Bug-tracking databases – таблица с атрибутами: описание ошибки, модуль (содержавший ошибку), статус ошибки, дата обнаружения, версия продукта.

Статусы:

  • open: найдена
  • fixed: исправлена
  • can't reproduce: невозможно воспроизвести
  • by design: проектировщики
  • won't fix: это не ошибка (тестеру показалось…)
  • postponed: исправим в следующей версии
  • regression testing – исправленная ошибка появилась вновь.

Severity (важность, сложность ошибки):

  • crash: всё падает, total data lost
  • major problem: падает частично, partial data lost
  • minor problem: no data lost
  • trivial: don’t worth fixing

Priority (сумеем ли исправить в этой версии):

  • highest: невозможно поставить продукт с такой ошибкой, не можем перейти к следующей версии
  • high: поставить не можем, к следующей версии перейти можем
  • medium: всё можем
  • low: какие-то улучшения – на следующую версию

Планка качества (Quality bar): продукт нельзя выпустить, если есть хотя бы одна ошибка с Severity "crash" или с Priority "highest"/"high". Действия:

  • подавление ошибок: удаление функциональности, содержащей ошибку;
  • небольшие исправления могут повлечь новые ошибки;
  • исправляют то, что чаще встречается (ориентация на большинство пользователей).

Защитное программирование - стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом.

Защитное программирование предполагает соблюдение трех основных принципов:

  1. входные данные каждого модуля должны тщательно анализироваться в предположении, что они ошибочны;
  2. каждая программная ошибка должна быть выявлена как можно раньше, что упрощает установление ее причины;
  3. ошибки в одном модуле должны быть изолированы так, чтобы не допустить их влияние на другие модули.

Абстракція модульності щодо модульного програмування. Принцип приховування інформації. Аксіома модульності. Принцип збіркового програмування.

СКАЗАНО НА ПАРІ

Принцип приховування інформації від тих, хто використовує модуль, є очевидним. Розмір не стандартизується. Якщо є набір модулів, то з них можна зібрати програмний продукт. Це треба робити за моделями збіркового програмування. Граф, що показує всі можливі зв’язки між модулями, модулює клас задач предметної області.

Процедурное программирование. Первоначальной (и, возможно, наиболее исполь¬зуемой) парадигмой программирования было "Определите, какие процедуры вам нужны; используйте лучшие из известных вам алгоритмов!"

Модульное программирование. Со временем в проектировании программ акцент сместился с организации процедур на организацию структур данных. Помимо всего прочего, это вызвано ростом размеров программ. Модулем обычно называют совокупность связанных процедур и тех данных, которыми они управляют. Парадигма программирования приобрела вид: "Определите, какие модули нужны; поделите программу так, чтобы данные были скрыты в этих модулях". Эта парадигма известна также как "принцип сокрытия данных". Если в языке нет возможности сгруппировать связанные процедуры вместе с данными, то он плохо поддерживает модульный стиль программирования. Типичный пример модуля - определение стека.

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

Абстракция данных. Модульное программирование предполагает группировку всех данных одного типа вокруг одного модуля, управляющего этим типом.Каждый управляющий типом модуль должен определять собственный алгоритм создания "переменных" этого типа.

Тип, реализуемый управляющим им модулем по многим важным аспектам, существенно отличается от встроенных типов. Такие типы не получают поддержки со стороны транслятора (разного вида контроль), которая обеспечивается для встроенных типов. Концепция модульности, поддерживающая парадигму упрятывания данных, не запрещает такой стиль программирования, но и не способствует ему. В языках Ада и С++ эта трудность преодолевается благодаря тому, что пользователю разрешается определять свои типы, которые трактуются в языке практически так же, как встроенные. Теперь парадигму программирования можно выразить "Определите, какие типы вам нужны; предоставьте полный набор операций для каждого типа". Если нет необходимости в разных объектах одного типа, то стиль программирования, суть которого сводится к упрятыванию данных и следование которому обеспечивается с помощью концепции модульности, вполне адекватен этой парадигме.

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

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

Конструктивизм модульности. Майерс предлагает для оценки приемлемости модуля использовать его конструктивные характеристики:

  1. размер модуля,
  2. прочность модуля,
  3. сцепление с другими модулями,
  4. рутинность модуля (независимость от предыстории обращений к нему).

Числом содержащихся в нем операторов или строк измеряется размер модуля

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

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

Рутинность модуля – это его независимость от предыстории обращений к нему. Модуль называют рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему

Принцип сборочного программирования. Программное обеспечение конструируется из существующих компонентов, а как их объединить – дело вкуса. Главное – есть механизм повторного использования компонентов, предполагающий наличие репозитария компонентов и подключения компонентов согласно неких модели, каркаса, объявления или спецификации и т.п.

Повторне використання ґрунтується на будь-яких порцiях формалізованих знань, отриманих з реалiзацiї завершених розробок і зафiксованих у рiзноманiтних формах: вiд конкретних параметризованих програмних модулiв до каркасів, архітектури та середовища. Знання про минулий досвiд розробки систем у вигляді повторно-використовуваних компонентів (ПВК) можна застосовувати не тiльки самим розробникам, а й іншим фахівцям після адаптації до умов нового середовища. Базисом повторного використання є сховища з інформаційним каталогом компонентів та ПВК із типовими функціями, які настроюються на нові умови з меншими зусиллями, ніж нова розробка.

Модулі у мовах програмування. Процедурна абстракція. Гіпотеза про глобальні дані.

Процедурний принцип: модуляризація на базі процедур. Зв"язування між модулями і процедурами встановлювалися на основі глобальних даних - це і є гіпотеза про глобальні дані (за Перевозчиковою).

Раннє зв"язування - компілятор і лінкувальник, певною мірою інсталяційна процедура. Це зв"язування допоміжного матеріалу модулів через глобальні дані. Таке зв"язування статичне. Пізнє зв"язування - динамічне. DLL.

Модуль - виділена за мотивами функціональності частина ПЕРВИННОГО МАТЕРІАЛУ програмного фонду. Первинний матеріал: вихідний текст програм, текст вихідних даних, документація, тексти процедур, що застосовуються до матеріалів тощо. Вторинний матеріал: скомпільована програма, модуль з бібліотеки, завантажувальний модуль тощо.

Спочатку великою популярністю користувалася парадигма процедурного програмування. Для підтримки цієї парадигми мови програмування надавали механізм передачі параметрів і отримання результатів функції. Алгоритми представлялися у вигляді процедур, які можна використовувати незалежно.

Згодом акцент змістився з організації процедур на організацію структур даних. Набула популярності концепція модульного програмування. МОДУЛЬ - сукупність зв"язаних процедур і тих даних, якими вони керують. Ця парадигма відома також як "принцип приховування даних". Типовий приклад модуля - визначення стеку. Тут необхідно вирішити такі задачі: 1). Надати інтерфейс для стеку (push(), pop()); 2). Гарантувати, що представлення стеку буде доступне через такий інтерфейс; 3). Забезпечити ініціалізацію стеку при першому його використанні.

Характеристики модуля (Меєрс):

  1. Розмір - кількість операторів або рядків (має бути ні великим, ні малим);
  2. Зв"язність - міра внутрішніх зв"язків модуля. Чим вища зв"язність, тим більше зв"язків модуль може приховати від зовнішньої програми. Найменша зв"язність у модуля, міцного за збігом (коли повторювані фрагменти коду виділяються в окремий модуль - не рекомендовано використовувати). Рекомендовано використовувати два класи модулів (за зв"язністю):
    • Функціонально зв"язний модуль - реалізує певну визначену функцію. При реалізації функції, модуль може використовувати й інші модулі.
    • Інформаційно зв"язний модуль - виконує декілька операцій чи функцій над однією і тією ж структурою даних, яка невідома поза цим модулем. Такий клас слід розглядати як клас програмних модулів з вищим ступенем зв"язності. Інформаційно зв"язний модуль може реалізовувати абстрактний тип даних (в мові Ада - пакет).
  3. Зчеплення модуля - міра незалежності за даними від інших модулів. Чим менше зчеплення модуля, тим більша його незалежність.
    • Зчеплення за змістом - найгірший вид зчеплення. Один з модулів має прямі посилання на вміст іншого модуля.
    • Зчеплення за загальною областю - теж не рекомендоване. Декілька модулів використовують одну і ту ж область пам"яті.
    • Параметричне зчеплення (зчеплення за даними) - єдиний рекомендований спосіб. Дані передаються модулю як значення його параметрів або як результат звернення до іншого модулю для обрахування певної функції (в мовах програмування - звертання до функцій).
  4. Рутинність - незалежність модуля від передісторії звернень до нього. Модуль рутинний, коли результат звернення до нього залежить лише від передаваних параметрів і не залежить від передісторії звернення до нього. Інакше модуль називається залежним від передісторії. Використання залежних від передісторії модулів досить небезпечне, однак часто необхідне.

Процедурна абстракція - ідея, яка полягає у тому, що у процедурах спосіб їх використання відокремлюється від деталей реалізації в термінах більш примітивних функцій (дані обробляються процедурою більш високого рівня, використовуючи процедури низького рівня). Готову процедуру можна використовувати, не вникаючи в деталі реалізації алгоритму, оскільки для використання достатньо знати її призначення і опис аргументів.

Гіпотеза про глобальні дані - використання глобальних даних небезпечне. Локальність даних дає можливість легко читати та розуміти модулі, підвищує незалежність модулів, дає можливість легко їх видаляти з програми.

Розмір модуля. Зчеплення модулів. Раннє і пізнє зв’язування.

Розмір модуля - кількість операторів або рядків. Модуль не повинен бути ні занадто великим, ні занадто малим. Маленькі модулі призводять до громіздкої структури програми. Великі ж модулі не зручні для вивчення та зміни. Рекомендовано використовувати модулі розміром від декількох десятків до декількох сотень операторів.

Зчеплення модуля - міра незалежності за даними від інших модулів. Чим менше зчеплення модуля, тим більша його незалежність.

  • Зчеплення за змістом - найгірший вид зчеплення. Один з модулів має прямі посилання на вміст іншого модуля.
  • Зчеплення за загальною областю - теж не рекомендоване. Декілька модулів використовують одну і ту ж область пам"яті.
  • Параметричне зчеплення (зчеплення за даними) - єдиний рекомендований спосіб. Дані передаються модулю як значення його параметрів або як результат звернення до іншого модулю для обрахування певної функції (в мовах програмування - звертання до функцій).

Зв"язування модулів у комплекси проходить через глобальні дані. Є два різновиди зв"язування:

  1. Раннє зв"язування - лінкування скомпільованих програмних модулів.
  2. Пізнє зв"язування - до виконуваного коду по мірі необхідності підключаються модулі з бібліотек.

Складність та режими підключень залежать від видів бібліотек: стандартних процедур, динамічних бібліотек (DLL), бібліотек класів тощо.

Раннє зв"язування - компілятор і лінкувальник, певною мірою інсталяційна процедура. Це зв"язування допоміжного матеріалу модулів через глобальні дані. Таке зв"язування статичне. Пізнє зв"язування - динамічне. DLL.

В об"єктно-орієнтованому програмуванні: зв"язування імен - асоціація значень з ідентифікаторами. Зв"язування імен, яке відбувається на етапі компіляції, перед тим, як програма запуститься, називається раннім (статичним). А зв"язування, що відбувається в процесі виконання програми - пізнє (динамічне).

Варіантність модулів. Планування обчислень і управління конфігурацією програм. Родовий generic-модуль у Аді. Режими макрообчислень мовного процесора

Іноді необхідна версійність модулів для різних задач. При оформленні версійності програмісти стикаються з рядом проблем. Насамперед це проблема безболісності внесення змін та проблема дублювання інформації. Ці проблеми виникають при застосуванні оператора вибору case - для додавання варіантів модулів необхідно змінювати текст основної програми. Проте це далеко не єдиний спосіб.

Важливим елементом оформлення рішення для різних задач є модуляризація. Рішення для варіантів задач проектуються у вигляді окремих модулів зі спільним інтерфейсом. В головній частині програми формується варіантне гніздо, тобто місце, призначене для підстановки одного із наявних варіантних фрагментів. Ця підстановка кокнретних модулів відбувається під час зборки програми в залежності від вказаної конфігурації.

Механізм конфігурації застосовується тоді, коли точка варіантності позначає можливий вибір із сукупності передбачених наперед взаємозамінних компонентів (у тому числі на рівні сценаріїв).

Найкраще версійність модулів організована в generic-модулі Ada. Він кожного разу налаштовується, використовуючи різні властивості. Властивості виписуються на рівні родового модуля. В певній точці застосування модуля ми встановлюємо конкретні його властивості.

Родовий модуль має родові прараметри, які замінюються на фактичні під час загальної конкретизації. Родовий модуль - параметризований шаблон, на основі якого створюються конкретні модулі. Параметри шаблона є родовими (узагальненими) за природою і їх не слід плутати з формальними параметрами модулів, що отримані внаслідок загальної конкретизації. Характерним для такого модуля є використання родових операцій, тобто операцій, які перевантажуються і не призначені для якоїсь однієї визначеної операції, а забезпечують формальні параметри для фактичних параметрів спеціальних типів даних (наприклад, "+" може означати додавання для цілих, дійсних чисел, об"єднання, конкатенації тощо).

Під конфігуруванням родового модуля слід розуміти створення на його базі конкретного модуля шляхом конкретизації його параметрів.

Частини модулів можна вилучити з обчислень безпосередньо перед компіляцією, використовуючи спеціальні директиви. Натрапляючи на ці директиви, мовний процесор буде просто ігнорувати виділені модулі.

Template і суперкласи. Характеристика бібліотек фундаментальних класів С++ за ISO/IEC 14882:1998.

Темплейти і суперкласи найкраще реалізовані в С++. Спочатку було поняття абстрактного класу. Його треба було уточнювати на етапі виконання. Проте згодом стало зрозуміло, що є багато задач, які можна описати за допомогою шаблонів.

Суперклас - клас, на основі якого створюються інші класи; абстрагування класів-нащадків. Абстракція, яка уточнюється на момент застосування. Суперклас дозволяє створювати узагальнений інтерфейс, що має в собі настроювану функціональність за рахунок використання віртуальних функцій. Механізм суперкласів широко використовується в ООП завдяки можливості повторного використання, яка досягається завдяки загальним можливостям, що інкапсульовані в модульні об"єкти.

Шаблони класів (class templates) - іноді називаються generic class або class generator. Шаблон не є класом, він лише дає можливість компілятору згенерувати визначення конкретного класу за зразком заданої схеми. Шаблони можна застосовувати лише на основі раннього зв"язування.

Наприклад: 

template <class T> class Vector {..} - шаблон класу

Vector <int> x(5) - оголошення об"єкту класу Vector <int>, створеного з шаблону.

Стандартна бібліотека С++ складається з 10 невеликих бібліотек

  1. Бібліотека мовної підтримки - містить типи і функції, що безпосередньо пов"язані з роботою компілятора мови програмування С++. Наприклад, в цю бібліотеку входять константи, що визначають діапазони і рівень точності обчислень функцій, що використовують значення з рухомою крапкою.
  2. Бібліотека діагностики - містить класи винятків та інші засоби діагностики кодів повернення повідомлень про помилки.
  3. Бібліотека загального використання - містить великий набір засобів, які важко віднести до будь-якої спеціалізованої бібліотеки.
  4. Бібліотека рядків - містить засоби маніпуляції текстовими рядками.
  5. Бібліотека розміщення - підтримує набори міжнародних та національних символів і форматів, що необхідні для орбробки і повернення даних про дату, час та національну валюту.
  6. Бібліотека контейнерів - містить родові контейнери для створення колекцій об"єктів.
  7. Бібліотека ітераторів - підтримує функції навігації по колекції об"єктів.
  8. Бібліотека алгоритмів - містить багато стандартних алгоритмів обробки даних.
  9. Бібліотека чисел - надає користувачам комплексні числа, спеціальні типи числових масивів та алгоритми обчислень.
  10. Бібліотека вводу-виводу - надає засоби форматування та керування операціями вводу та виводу даних в файли та інші пристрої.

Шість моделей реалізації життєвого циклу програми: каскадна, дослідницька, прототипування, спіральна, формального перетворення, збіркового програмування

  1. Каскадна. Колектив послідовно розробляє проект - від вихідної концепції до комплексного тестування. Ця модель вимагає визначення опорних точок, в яких буде оцінюватися зроблене і вирішуватиметься питання про те, чи можна рухатися далі. Такий підхід застосовується для проектів, у яких вимоги легко формулюються на самому початку, але не придатний для складних, коли вимоги можуть неодноразово змінюватися. Крім того, каскадна модель вимагає готування величезної кількість документації, а також наявності однорідної процедури оцінки результатів на кожному етапі. Ця модель передбачала, що при виявленні помилки відкотитися можна лише на 1 етап назад. Проте більшість помилок виявляється на стадії тестування (передостанній крок), і тому їх здолати неможливо.
    • Постановка -> Планування (люди, ресурси) -> Проект (структура, зв"язки) -> Реалізація -> Відлагодження -> Документування -> Здача програмного продукту -> Супровід.
  2. Дослідницька. Модель, що застосовується в інноваційних проектах, коли відомий лише напрямок досліджень, а не кінцевий результат. В дослідницькому програмуванні не можливо наперед сказати, який об"єм ресурсів потрібен для досягнення цілі. Не існує також детального планування розробки. Велике значення має людський фактор, оскільки в основі методу лежить творчий підхід. Процеси тестування і відлагодження розпаралелені. Розробка складається з 3-х етапів: прототипування, тестування і налагодження, які проходять по колу. Розробка ведеться по висхідній. Спочатку створюються ключові компоненти, які розширюються і вдосконалюються методом проб та помилок. Величезне значення має процес тестування.
  3. Прототипування. Точна спіраль з релаксацією. Відстань між витками - релаксація - коли програмісти усвідомлюють накопичений досвід і якісно вдосконалюють продукт. Вислуховуємо замовника - створюємо прототип - оцінка замовником - і по колу. На кожному витку відбувається вдосконалення прототипу і поступове підвищення його функціональності. Часто прототипування використовується для того, аби встановити точні вимоги до програмного продукту і перейти на каскадний рівень.
  4. Спіральна. Розробка застосування виглядає як серія послідовних ітерацій. На перших етапах уточнюються специфікації продукту, на подальших додаються нові можливості та функції. Ціль цієї моделі - якнайраніше виявляти ризики і уже в перших версіях продукту усувати пов"язані з цим проблеми. В силу своєї ітеративності ця модель дозволяє коректування в ході роботи, що сприяє поліпшенню продукту. Модель: Планування - Аналіз ризиків - Конструювання - Оцінка замовником - і по колу. Різні витки = різні версії.
  5. Формальне перетворення. Розробляються формальні специфікації програмного забезпечення, які перетворюються на програми шляхом коректних перетворень.
  6. Збіркове програмування. Принцип збіркового програмування - збираємо з існуючих модулів програмний продукт. Всі з"єднання модулів можна подати у вигляді графа. Така графова структура може стати моделлю певних задач предметних областей.

Задача повторного використання накопичених компонентів. Репозитарії, організація доступу до компонентів повторного використання і побудова компонентних імен

Компонентна розробка — це метод побудови ПЗ з конструкцій за каталогом як композиції готових компонентів. Йдеться не лише про порції програмного коду або програмні модулі. Повторне використання (ревикористання) — це використання для нових розробок будь-яких порцій формалізованих знань, під час реалізації завершених розробок програмних систем.

Повторно використовуваними компонентами (ПВК) звуться елементи знань про минулий досвід розробки систем, якщо:

  1. їх можуть використовувати не лише їхні розробники;
  2. їх можна адаптувати для створення нових систем.

Зауважимо, що при цьому потрібен каталог, з якого можна зрозуміти, які деталі є і як їх можна поєднувати в конструкцію.

Є шаблон на те, який вигляд мають модулі загального використання. Постає питання про організацію репозитаріїв. Приклад - DLL.

Організація доступу до компонентів відбувається через механізм іменування компонентів. Таке іменування можна побудувати за різними принципами (способи побудови пошукових образів):

  • спосіб вільного індексування - список ключових слів, які найчастіше згадуються в тексті ПВК;
  • ієрархічний спосіб - створений на базі заздалегідь побудованої онтології домену проблемної галузі;
  • фасетний спосіб - за іменами, що побудовані через формулювання окремих властивостей. Пошуковий образ ПВК може складатися з наперед визначених порцій (фасет), кожна з яких належить до окремого аспекту розгляду ПВК. Усередині фасети інформацію можна структурувати на окремі поля, значення яких можуть належати до певної онтології або вільного (наперед не визначеного) списку дескрипторів (термінів) або до одного з наперед визначених альтернативних значень. Тобто фасетний спосіб поєднує в собі можливості двох наведених вище способів.

Репозитарії - інформаційні сховища, де сидять такі re-use компоненти. В С++ можна створити власні бібліотеки.

Стандартні бібліотеки функцій, динамічні бібліотеки (DLL) і бібліотеки фундаментальних класів

Бібліотеки функцій. По суті використання підпрограм. Підпрограма - абстракція програми, яка виконує певну дію. Виклик - через ім"я. Використовуються через раннє зв"язування. В необхідне місце підставляється код підпрограми, після чого відбувається компіляція. Раннє зв"язування - лінкування скомпільованих програмних модулів. Виконується компілятором, лінкувальником і певною мірою інсталяційною процедурою. Це зв"язування допоміжного матеріалу модулів через глобальні дані. Таке зв"язування статичне.

Динамічні бібліотеки. До виконуваного коду по мірі необхідності підключаються модулі з таких бібліотек. В DLL - пізнє зв"язування. Пізнє зв"язування - до виконуваного коду по мірі необхідності підключаються модулі з бібліотек. Воно динамічне.

Бібліотеки фундаментальних класів. Бібліотеки шаблонів. Шаблони класів (class templates) - іноді називаються generic class або class generator. Шаблон не є класом, він лише дає можливість компілятору згенерувати визначення конкретного класу за зразком заданої схеми. Шаблони можна застосовувати лише на основі раннього зв"язування.

Наприклад: 

template <class T> class Vector {..} - шаблон класу

Vector <int> x(5) - оголошення об"єкту класу Vector <int>, створеного з шаблону.

Каталогізація абстрактних архітектур програмних систем та прикладних доменів. Приклади абстрактних архітектур.

DLL - готове рішення, яке можна застосовувати. Готовими рішеннями є усталені служби ОС.

Абстрактні домени: ОМГ описав 6 абстрактних доменів: хелскер, мануфактури тощо. Можна взяти такий домен, провести його налаштування. Наприклад, з хелскера з усіх видів госпіталів зроблю собі стоматологічний кабінет. Архітектура абстрактного домену - найвищий прояв готового рішення. Перше - етап налаштування, потім - застосування. Якщо щось не так - переналаштування.

Спектр задач проблемної галузі, що допускають схожі способи розв'язання їх, називають доменом предметної галузі. Абстрактна архітектура — це декомпозиція спільного вирішення для виділеного спектра завдань домену на підсистеми або ієрархію підсистем, на кореневому рівні якої фіксуються можливі варіанти виділених параметрів та обмежень, котрим відповідають варіації складу виділених компонентів.

Отже, абстрактні архітектури визначають глобальну структуру проектованої системи і функціональність її стабільних головних складових, що може розглядатись як фіксована частина абстракції підходу до вирішення виділеного спектра завдань. Спеціалізація абстрактної архітектури здійснюється шляхом довизначення варіацій компонентів.

Прикладами повторно використовуваних компонентів абстрактних архітектур є:

  • системи управління базами даних;
  • архітектура компілятора, в яку можна вбудовувати різноманітні лексичні й синтаксичні аналізатори, генератори кодів;
  • архітектура експертної системи, основаної на правилах тощо.

Розвитком ідеї абстрактної архітектури є каталогізація доменів масового вжитку й узагальнення їхніх властивостей як поняття абстрактний домен. Виконуючи аналіз подібності та розбіжностей сукупності доменів, експерти можуть помітити аналогії для таких, на перший погляд, відмінних речей, як продаж театральних квитків, резервування місць на рейси літаків або розподіл деталей на обробку для верстатів заводського конвеєра. Помітивши аналогії в структурі знань різних із синтаксичного погляду доменів, експерти можуть ввести абстракції об'єктів, які можна конкретизувати у відповідні об'єкти аналогічних доменів. Вимоги до систем, що належать до цих доменів, можна подати у термінах відповідного абстрактного домену.

Автори пропонують набір абстракцій проблем, які слугують базисом для генерації специфічних для конкретного домену сценаріїв збирання та перевірки вимог, використання їх під час експлуатації, складання вимог у формі юридичного контракту природною мовою. Було сформовано перелік з 13 абстрактних доменів (забезпечення ресурсів, використання ресурсів, логістика і т.д.). Для згаданих вище доменів можна навести чимало прикладів завдань, несхожих зовні, але вирішення яких вимагає маніпулювання об'єктами з аналогічною поведінкою.

Патерни кооперативної діяльності компонентів. Види патернів

Патерни є абстракцією спілкування (взаємодії) певної сукупності об'єктів у кооперативній діяльності, для якої визначено абстрактних учасників, їхні ролі, взаємовідносини та розподіл відповідальності. Патерн фіксує певне узагальнене рішення, яке дозволяє спілкуватися розробникам та замовникам і розмірковувати щодо проблеми та її розв'язання. Патерни описують окрему повторювану проблему проекту як визначену наперед схему її розв'язання шляхом специфікації абстракції її складових, їхніх ролей та взаємовідносин і відповідальності.

Креативні патерни (від англ. create - створювати) відображають процеси створення екземплярів об'єктів. Нижче наведено приклади таких патернів:

  • ініціатор - це відповідь на проблему, яка полягає в тому, що конкретний тип об'єкта часто змінюється; контекст визначається як багаторазова потреба породжувати екземпляри об'єкта; рішення - інтерфейс створення об'єктів відокремлюється від власне створення, яке вирішується через визначення підкласу, який конкретизує, що саме створюється;
  • трансформер - це відповідь на проблему організації перегляду файлів та трансформування їх у різні формати; рішення - відокремити механізм перегляду від алгоритмів створення нових форматів;
  • прототип - це відповідь на проблему породжувати екземпляр об'єкта за заданим зразком; рішення - визначити тип за екземпляром прототипу і створити новий об'єкт як копію прототипу.

Структурні або архітектурні патерни визначають композиції класів об'єктів, їхніми типовими прикладами є:

  • адаптор - це відповідь на проблему пристосовування інтерфейсу до смаку персонального клієнта. Контекст - смаки часто змінюються. Рішення - визначити абстракцію інтерфейсу як суперклас, а настройку на персональні вимоги клієнта - як підклас;
  • фасад - це відповідь на проблему локалізації в підсистемах властивостей, що мають високу вірогідність змін. Контекст - найбільшу вірогідність змін мають об'єкти інтерфейсу. Рішення - передбачити можливі зміни в підсистемі та зосередити їх в одному класі;
  • пошарова структура - це відповідь на проблему дотримування певного рівня абстракції в осмисленні проблеми на кожній стадії життєвого циклу розробки програмної системи Контекст - наявність розробників з різними рівнями кваліфікації, що зумовлює здатність виконувати роботу на відповідних рівнях абстракції. Рішення полягає в декомпозиції системи на ієрархію шарів, для кожного з яких встановлюється стандартизований інтерфейс між компонентами попереднього та наступного шарів.

Поведінкові патерни визначають взаємодію класів та їхніх екземплярів (як розподіл абстрактних ролей ) і їхню поведінку. Приклади:

  • ланцюг повноважень - це відповідь на проблему роз'єднання відправників повідомлень від тих, хто їх обробляє. Контекст - потреба в роздільному функціонуванні перших і других. Рішення - повідомлення передається від об'єкта до об'єкта, доки не дійде до того, хто виконає його обробку;
  • клієнт/сервер/сервіс - це відповідь на проблему інкапсулювання подробиць реалізації програмних послуг, щоб вивільнити клієнтів від необхідності знати їх. Контекст - сервіс може бути запрошено паралельно й одночасно багатьма клієнтами. Рішення - побудова двох класів. Перший з них - сервіс - інкапсулює послідовність виконання послуги, підтримує стани виконання послуги і передає події, котрі виникають у процесі виконання послуги. Другий - сервер - інкапсулює ресурси та послуги сервісів і визначає абстрактний інтерфейс з клієнтом, конкретизація якого ініціює конкретне виконання конкретного сервісу.

Каркаси прикладних застосувань. Приклади каркасів.

Каркас проблеми визначає готову структуру головних складових частин, на які має поділятися система, побудована для розв'язання проблеми. Каркас об'єднує множину класів об'єктів, які взаємодіють між собою для досягнення множини цілей, котрі розв'язують проблему.

За способом спеціалізації каркаси поділяють на два різновиди.

  1. Каркас типу "біла скринька" має у своєму складі абстрактні класи, які неповно визначають мету та інтерфейси компонентів. Щоб трансформувати такий каркас у конкретну прикладну систему, достатньо породити шляхом наслідування конкретні класи й доповнити при цьому визначення відповідних методів. Але цей процес потребує знання про внутрішню побудову каркаса, що суттєво утруднює його використання.
  2. Каркас типу "чорна скринька" - це структура, окремі вузли якої означено як такі, визначення котрих відкладено (так звані "гарячі плями"). На відміну від попереднього типу каркаса, для заповнення "гарячих плям" пропонується спектр можливих альтернативних класів - претендентів зайняти місце у "гарячій плямі". Кожна пляма відповідає одному з аспектів змінюваності системи. Вибираючи один з альтернативних класів, ми отримуємо реалізацію відповідного йому варіанта системи. Створення системи виглядає як визначення конкретної конфігурації компонентів, відповідних "гарячим плямам". Визначення конкретного варіанта системи проводиться як вибір "з полиці" потрібних компонентів.

Прикладом каркаса є система банківських розрахунків, для якої визначено дві "гарячі плями": компонент ідентифікації рахунка клієнта (зазвичай у кожній країні діють відповідні стандарти) та компонент реакції на прохання клієнта зняти певну суму з його рахунка, якщо така сума перевищує наявну суму рахунка (окремі банки можуть у такому разі кредитувати клієнтів певних категорій або на певних умовах).

Приклади каркасів (за RST):

  • "чорна скринька" :.NET Framework; Java RE(JRE), Boost
  • "біла скринька": STL,?

Процедурне програмування з роздільним збереженням даних і функцій. Об'єктно-орієнтоване програмування. Інкапсуляція, спадкування реалізації, поліморфізм. Недоліки повторного використання об'єкта. Перекомпіляція початкового коду (біла скринька)

Процедурне програмування з роздільним збереженням даних і функцій.

Ще починаючи від com-програм, не було розділення на код і дані, все було в перемішку. Саме на цих принципах і досі базується C/C++, якщо його використовувати як процедурну мову. (Саме тому ще досі є взломи програм через "переповнення буфера" -- це можливість зміну коду програми через надмірне введення даних (дані виходять за межі відведеного їм місця і перетирають код що йде після цього)).

Фактично, навіть Pascal чи щось схоже на це вже уникає або, принаймні, наближається до того щоб розділяти дані і код.

Об'єктно-орієнтоване програмування.

об'єктно-орієнтований - Властивий технології або мові програмування, що підтримують об'єкти, класи і спадкування.

Примітка - Деякі автори сформулювали наступні вимоги до об'єктно-орієнтованого програмування: приховування інформації або інкапсуляція, абстракція даних, передача повідомлень, поліморфізм, динамічне зв'язування і спадкування (комп-конспект 1-4)

Об'єктно-орієнтоване програмування (ООП) - одна з парадигм програмування, яка розглядає програму як множину "об'єктів", що взаємодіють між собою. В ній використано декілька технологій від попередніх парадигм, зокрема успадкування, модульність, поліморфізм та інкапсуляцію. Не зважаючи на те, що ця парадигма з'явилась в 1960-тих роках, вона не мала широкого застосування до 1990-тих (wikipedia)

Інкапсуляція

інкапсулювати - Застосовувати приховування інформації до мовних конструктів

інкапсуляція - Процес або результат виконання таких дій, коли необхідно інкапсулювати *мовний конструкт

приховування інформації - Принцип відмови у доступі до чи у відомостях про мовний конструкт або певні деталі цього, крім тих подробиць, що вважаються суттєвими для користувачів

спадкування реалізації

спадкування - Копіювання всієї чи частини внутрішньої структури і набору операцій з одного класу у похідний клас

Успадкування - конкретизація в підкласі окремих властивостей та поведінки, визначених у суперкласі

Поліморфізм

Поліморфізм - Здатність різних об'єктів по-різному відповідати на однакові повідомлення

повідомлення - Запит до об'єкту на виконання однієї з його операцій

(простими словами, це коли робота з екземплярами різних класів через їхнього спільного предка (використовуючи методи предка). При цьому насправді виконується код що описаний в класі-нащадку, а не предку. (реалізовується через віртуальні функції))

Недоліки повторного використання об'єкта

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

Перекомпіляція початкового коду (біла скринька)

"Біла скринька" найкраще демонструється в процедурному програмуванні. Це означає що користувачу системи (модуля, набору модулів) відкрито всі процеси які відбуваються всередині і він може на них впливати. (Бо "чорна" -- це коли користувач тільки може дати щось на вхід і отримати результат). Тому, якщо раптом щось в "білій скринці" щось змінилося, -- виникає потреба перекомпілювати все що базується на цій білій скринці, оскільки невідомо як ці зміни можуть вплинути на те що від нього породжено.

Якщо перейти до об'єктно-орієнтованого підходу, то, як описано в попередньому розділі, "біла скринька" -- це набір абстрактних класів, які неповно визначають мету та інтерфейси компонентів. Щоб трансформувати це у конкретну прикладну систему, достатньо породити шляхом наслідування конкретні класи й доповнити при цьому визначення відповідних методів.

Компонентне програмування. Інкапсуляція, спадкування інтерфейсів, поліморфізм, чорна скринька бінарного подання; інфраструктура розподілених застосувань (пошук інтерфейсів, транзакції, безпека тощо).

Компонентна розробка - конструювання програмного забезпечення з конструкцій за каталогом як композиції готових компонентів.(конспект)

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

"Object Oriented Programming = Polymorphism + (Some) Late Binding + (Some) Encapsulation + Inheritance

Component Oriented Programming = Polymorphism + (Really) Late Binding + (Real, Enforced) Encapsulation + Interface Inheritance + Binary Reuse"

(Чарлі Кіндел, Майкрософт)

Інкапсуляція

інкапсулювати - Застосовувати приховування інформації до мовних конструктів

інкапсуляція -Процес або результат виконання таких дій, коли необхідно інкапсулювати *мовний конструкт

приховування інформації - Принцип відмови у доступі до чи у відомостях про мовний конструкт або певні деталі цього, крім тих подробиць, що вважаються суттєвими для користувачів

спадкування інтерфейсів

(швидше всього, малася на увазі "реалізація інтерфейсів")

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

Идеальный интерфейс должен

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

Поліморфізм

Поліморфізм - Здатність різних об'єктів по-різному відповідати на однакові повідомлення

повідомлення - Запит до об'єкту на виконання однієї з його операцій

(простими словами, це коли робота з екземплярами різних класів через їхнього спільного предка (використовуючи методи предка). При цьому насправді виконується код що описаний в класі-нащадку, а не предку. (реалізовується через віртуальні функції))

чорна скринька бінарного подання

Чорна скринька - це термін для визначення системи, механізм роботи якої або невідомий або неважливий і межах даної задачі. Для роботи чи дослідження таких систем восновному є певний "вхід", через який можна вказати певний набір параметрів для роботи і "вихід", через який можна отримати результат роботи "чорної скриньки".

Саме так і виглядає робота з динамічними бібліотеками (dll) або системними викликами - програміст який їх використовує може вказати тільки вхідні параметри і отримати результат.

інфраструктура розподілених застосувань (пошук інтерфейсів, транзакції, безпека тощо)

Еволюція архітектури застосування: однорівнева система, локальна обчислювальна мережа персональних комп'ютерів, дволанкова архітектура клієнт-сервер, триланкова об'єктна архітектура клієнт-сервер, Web-сервіси.

Однорівнева система

Певно що це програма (або комплекс програм) яка працює в межах одного комп'ютера і не потребує або просто і не має можливості комунікувати з іншими комп'ютерами. Особливостями цього підходу є спільний адресний простір, спільні ресурси файлового сховища і дуже висока надійність і швидкість комунікації програм між собою.

Локальна обчислювальна мережа персональних комп'ютерів

Коли з'явилася можливість з'єднати два і більше комп'ютерів хоча б якимось кабелем, одразу ж почався розвиток програмного забезпечення який би цим користувався. Специфіка цього рівня є в тому, що в цьому спілкуванні "всі рівні" і, якщо конкретна програма не знає куди їй треба звертатися, вона мусить спитати у всіх (multicast, broadcast), що є не кльово.

На відміну від попереднього рівня, оперативна пам'ять і дисковий простір у процесів вже різний, а тому виникають пов'язані з цим проблеми пов'язані з передачею коду чи даних між комп'ютерами. Зв'язок між програмами є менш надійним, оскільки додаються проблеми які можуть виникнути на етапі передачі даних між програмами. Але, з іншого боку, тепер програми не "чекають" поки одна з них використовує процесор чи якісь інші ресурси конкретного комп'ютера, а мають можливість повноцінно працювати паралельно.

Дволанкова архітектура клієнт-сервер

Це розподілена обчислювальна архітектура, в якій виділяється один або кілька (часто - потужніших) комп'ютерів що надають певні послуги ("сервери"), якими користуються "клієнти". Якщо клієнт потребує якусь інформацію про чи від інших клієнтів, він, в основному, звертається до сервера щоб він надав йому цю інформацію, таким чином оптимізуючи навантаження мережі і мінімізуючи час затрачений іншими клієнтами на обробку мережених викликів (немає бродкастів).

Загальноприйнята архітектура сервера - це певна програма або комплекс програм що очікують з'єднань від клієнтів на певних виділених мережевих портах.

Мінусами цієї технології є можливе обмеження швидкодії системи швидкодією сервера або мережного підключення до сервера і зупинка роботи мережі якщо сервер перестає працювати.

Триланкова об'єктна архітектура клієнт-сервер

(також називають "багатоланкова" архітектура)

Це розподілена клієнт-серверна архітектура, в якій графічний інтерфейс, функціональна логіка (бізнес-логіка) і сховище даних (база даних) розробляються і впроваджуються як незалежні модулі, найчастіше - на різних платформах.

Триланкова модель взаємодії програми є стандартною архітектурою і визнається як паттерн проектування системи.

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

Три ланкова архітектура складається з

  • Користувацький інтерфейс (Presentation tier) - представляє інформацію кінцевому користувачу, спілкується з Сервером застосування.
  • Сервер застосування (Application tier, Business Logic) - надає користувацькому інтерфейсу дані від сервера бази даних і передає зміни в базу даних які прийшли від користувацького інтерфейсу, контролює права доступу користувача і визначає реакцію системи на запити користувача.
  • Сервер Бази даних (Data tier) - надає доступ до інформації що зберігається у сховищі даних, обробляє запити і змінює дані. Виділення окремого сервера бази даних покращує масштабованість і швикість роботи системи.

Web-сервіси

Веб-сервіс - це програмна система розроблена щоб забезпечувати інтероперабельне спілкування між комп'ютерами в мережі. Ця програмна система має інтерфейс, описаний в форматі зрозумілому для машини (Web Services Description Language, WSDL). Інші системи спілкуються з цією використовуючи SOAP (Simple Object Access Protocol) повідомлення, в основному серіалізовані в XML і передані з використанням HTTP. (офіційне визначення W3C)

Фактично ж, зараз є 2 типи веб-сервісів:

  • "Big Web Services", які підтримуються великими компаніями і працюють на SOAP/XML over HTTP і підтримуються багатьма мовами програмування.
  • RESTful сервіси, які базуються на чистому HTTP і можуть працювати в будь-якому браузері. Вони компактніші, простіші і швидше обробляються. На відміну від веб-сервісів базованих на SOAP, в REST веб-сервісах немає чіткого протоколу роботи, тому різні застосування і сервери які постулюють REST-приналежність можуть не комунікувати між собою.

Способи використання веб-сервісів:

  • Remote Procedure Call: структура і функціонал веб-сервісів дуже схожий і спочатку він і задумувався як вдосконалення RPC, коли веб-сервіси просто прив'язували до функцій написаних конкретною мовою програмування. Цей підхід часто критикується, оскільки унеможливлює "слабке зв'язування" (як віртуальні функції)
  • Service-oriented architecture (message-oriented): основна відміннісіть від RPC в тому, що наголос робиться не на функції до якої йде виклик, а на повідомленні що передається - саме воно містить інформацію про те що треба виконати на іншій стороні. Також йде розробка і реалізація Event-Driven SOA, (SOA 2.0), в якому, на відміну від SOA 1.0, клієнт не має регулярно запитувати сервер про зміни, а отримає повідомлення про зміни від сервера.
  • Representational state transfer(REST): спрощення ідеї Web-сервісів в якому є спроба обмежитися набором загальновідомих HTTP (чи інших) операцій, таких як (SET,GET,POST…) для того щоб можна було брати або віддавати дані не тільки визначеним веб-сервісам, а будь-кому хто реалізовує протокол (HTTP).(наприклад, працювати з сайтами чи браузерами як з web-сервісами/клієнтами)

Технологія CORBA як стандарт компонентних моделей об'єктного проектування розподілених застосувань: патерн на верхньому рівні і каркас (фреймворк) на нижньому. CORBA-компоненти: від системних об'єктів до бізнес-об'єктів.

Корба - механізм стандартизації виклику методів між об'єктами в програмі і між різними програмами. Корба визначає IDL(interface definition language) для визначення того як об'єкти будуть представлені ззовні. Для можливості роботи з Корбою з різних мов, вона надає механізм "співставлення" "mapping" конструктів IDL і специфічних їх реалізацій на різних мовах, таких як C++/Java/Ada/Lisp/Smalltalk/Python/Ruby….

В основі специфікації корби лежить концепція ORB, саме через який програма і взаємодіє з іншими, зовнішніми, об'єктами.

Фактично, програма яка хоче працювати на основі корби:

  • На серверній стороні: ініціалізує ORB і працює через Object Adapter, який і займається реєстрацією об'єктів, посилань на них, правами доступу.
  • На клієнтській стороні: знати Object Reference (щось типу corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root), по якому ORB з клієнтської сторони згенерує заглушку з якою вже можна буде працювати як з локальним клієнтом.

Паттерном, певно що, називають те що для роботи з корбою треба реалізувати певний інтерфейс і зареєструвати об'єкти які і працюватимуть.

А тоді "каркасом" -- те як це все працює внизу (через stub/skeleton, (наступне запитання), CORBA- компоненти) і як з ним працює клієнт.

CORBA-компоненти

  • Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов
  • Объектные Службы предоставляют набор услуг (интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации других объектов. Операции, предоставляемые Объектными Службами, выступают в качестве базовых "строительных" блоков для Общих Средств и прикладных объектов. (Уведомления Объектов о Событии, Жизненного Цикла Объектов Именования Объектов (детальніше - питання 25, "сервіси КОРБА"))
  • Функции СУБД в информационной архитектуре. Следуя принципам модульности и ортогональности компонентов информационной архитектуры, OMG представляет функции управления базами данных рядом таких служб, как долговременное хранение объектов, управление конкурентным доступом к объектам, служба транзакций, службы объектных связей, объектных запросов, изменений объектов и т.п.
  • Общие Средства заполняют концептуальное пространство между ORB и объектными службами с одной стороны, и прикладными объектами с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы -- фундаментальные объектные интерфейсы, а задача Общих Средств -- поддержка интерфейсов сервисов высокого уровня. (Средства поддержки пользовательского интерфейса, Средства управления информацией, Средства управления системой, Средства управления задачами)

З ПОПЕРЕДНІХ КУРСІВ

З поширенням ОО-підходу для аналізу і проектування застосувань, виникли нові способи забезпечення взаємодії компонентів РЗ у вигляді об’єктів, які можуть окремо існувати і розподілятися мережею локально чи віддалено та у разі обробки утворювати об’єкти-процеси. Для сумісного використання об’єктів і їх взаємодії способом надсилання запитів консорціум ОМG розробив стандарт СОRВА загальної архітектури брокера об’єктних запитів (Соmmоn Object Request Вrоkеr Architecture), визначивши структуру і основні засоби для подання РЗ: об’єктна модель взаємодії, IDL-мова опису інтерфейсів об’єктів, відокремлених від їхньої мови реалізації, специфікація ОRВ (Object Request Вrоkеr). Об’єкт викликає метод через інтерфейсний посередник (stub), який у свою чергу використовує ОRВ, щоб надіслати метод для виконання на реальний сервер. Об’єкт клієнта використовує також ОRВ, щоб знайти сервер у мережі, динамічно виконати об’єкт і отримати інформацію від серверу про результати обробки, передані у інтерфейсний об’єкт-stub.

CORBA-об'єкти та інтерфейси як методи цих об'єктів. Stub і skeleton. ORB-сервіси. BOA-інтерфейс і чотири стилі активізації CORBA-об'єктів. Приклади реалізації ORB.

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

Stub і skeleton

Конечный код, продуцируемый IDL-компилятором, - это пара отображений: для клиентской и серверной сторон. Код клиентского отображения называется корешком (stub), а код серверного - скелетом (skeleton). Эти отображения могут статически привязываться к соответствующему клиентскому или серверному коду во время компиляции.

ORB-сервіси.

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

BOA-інтерфейс і чотири стилі активізації CORBA-об'єктів.

BOA-интефейс (BOA - Basic Object Adapter).-Объектный адаптер поддерживает, "понимает" разные способы и стили реализаций объектов. Хотя интерфейс ответственен за тип реализации, объектный адаптер отвечает за "стиль" реализации объекта, например, за активизацию объекта, если запрос послан, а объект еще не готов (не был активизирован). Применительно к BOA уместны четыре стиля активизации объектов:

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

Приклади реалізації ORB.

Здесь клиент делает вызов демона, прослушивающего известный порт и работающего на другом компьютере, через TCP-сокет. Демон выполняет системный вызов fork() и exec(), запуская процесс реализации на сервере.

Когда процесс запускается, он вызывает метод BOA - impl_is_ready(). В случае с разделенным сервером (правилом активизации) он вызывает метод BOA - obj_is_ready().

Затем BOA передает вызов метода, собственно, объекту, которому этот вызов предназначается. Сервисы объекта возвращают результат клиенту.

Різниця між викликом ORB та RPC (з наведенням трас подій). Модель ORB-інтероперабельності та її зіставлення з OSI-моделлю взаємодії і моделлю комунікацією за системою протоколів TCP/IP .

Вызовы проходят через ORB по следующей цепочке (ORB.PNG):

  • клиент вызывает метод через корешок;
  • ORB передает запрос BOA, который активизирует реализацию объекта;
  • реализация отвечает BOA, что она существует и готова к работе;
  • BOA передает запрос метода в реализацию через скелет;
  • реализация возвращает результат (выбрасывает исключение) обратно в ORB.

Зображення:ORB.png

В цепочке, вызовы клиента от ORB опускаются по стеку протоколов, а на серверной стороне -- вызовы поднимаются по нему (следовательно, это обратный вызов).

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

  • сервер (посредством portmapper'а) регистрирует номер порта;
  • сервер читает из порта, который он блокирует, пока сообщение не прочитано целиком;
  • клиент запрашивает у portmapper'а номер порта сервера;
  • portmapper ему отвечает;
  • клиент контактирует с сервером на хосте через заданный порт;
  • блокировку порта снимает сервер;
  • сервер возвращает результат или выбрасывает исключение.

Зображення:RPC.png

Модель ORB-інтероперабельності та її зіставлення з OSI-моделлю взаємодії і моделлю комунікацією за системою протоколів TCP/IP

Табличка: OSI i TCP/IP: OSI (Application, Presentation, Session, Transport, Network, Data Link, Physical);

TCP/IP: (Application, -, -, Transport, Internet, Network Access, -). Позначення Application, -, - означає, що Application рівень TCP/IP покриває Application, Presentation i Session рівні OSI.

Табличка: ORB і OSI:

Stub/Skeleton - Application

1.1) GIOP, 2.1) ESIOP, 3.1) GIOP - Presentation

1.2) IIOP, 2.2) DCE-CIOP, 3.2) 77 - Session

1.3) TCP, 2.3) TCP 3.3) IPX - Transport

1.1 - інтерфейс, 1.2 - відображення 1.1 на 1.3. Так само з 2 та 3.

Поскольку реализация CORBA доступна всем, требуется сетевой протокол, чтобы разные системы могли взаимодействовать друг с другом. Протокол GIOP (General Inter-ORB Protocol) специфицирован как общий интерфейс, включая типы сообщений и их формат, которые необходимы для взаимодействия.

Семантический слой IIOP (Internet Inter-Orb Protocol) специфицирован, чтобы отобразить GIOP на TCP/IP. Комбинация GIOP и IIOP необходима для взаимодействия за пределами одного компьютера.

77 i IPX - приклад що GIOP можна відобразити і на інші протоколи (не TCP/IP)

ESIOP і DCE-CIOP -- Environment Specific Inter-ORB Protocols, приклад що замість GIOP може бути ще й якийсь конкретний специфічний протокол. (в даному випадку - DCE-CIOP (DCE Common Inter-ORB Protocol).

ORB працює на Application layer.

Сервіси CORBA: життєвого циклу, довготермінового збереження, іменування, подій, контролю сумісного доступу, транзакцій, відношень, зовнішнього подання, запитів, ліцензування, якостей (properties), часу, безпеки, комерції, контейнерів. .

CORBAservices - доступные объектные сервисы, являющиеся обычными CORBA-объектами. Такие сервисы изначально специфицированы в Common Object Services Specification (COSS; название еще часто используется).

В настоящее время в официальном списке CORBAservices находятся:

  • событийная система уведомлений (Event Notification), (подій)
  • устойчивость (Persistence), (довготермінового збереження)
  • жизненный цикл (Lifecycle), (життєвого циклу)
  • сервис имен (Naming), (іменування)
  • контроль тупиковых ситуаций(Concurrency Control) (контроль сумісного доступу)
  • взаимосвязи (Relationships), (відношень)
  • транзакции (Transactions), (транзакцій)
  • сервисы сбора информации (Collections), (контейнерів)
  • расширение (Externalization),
  • время (Time), (часу)
  • безопасность (Security), (безпеки)
  • сервис запросов (Query service), (запитів)
  • лицензирование (Licensing), (ліцензування)
  • trading, (комерції) НЕМА
  • управление изменениями (Change Management), (зовнішнього подання)
  • управление свойствами (Properties). (якостей)

Жизненный цикл (Lifecycle).

Данный объект позволяет делать следующее:

  • копировать (глубоко и поверхностно),
  • перемещать,
  • удалять,
  • производить поиск,
  • создавать,
  • генерировать новые объекты из шаблонов (factoring).

Устойчивость (Persistence) Довготермінового збереження.

Объектный менеджер устойчивости (POM) - присваивает постоянным объектам PID. POM-тождественность определяет отображение назад в низлежащие хранилища (PDS). Ярлык протокола именует низлежащее хранилище (PDS). Сейчас специфицированы три формы протокола:

  • прямой доступ PSM (DA),
  • подобие языка IDL - DDL,
  • Sun and HP (JOSS) ODMG-93,
  • прямой доступ из C++ в OODBMS-отображение,
  • Sun, ODI, O2, Versant, Poet.

Динамические объекты данных (DDO) - нейтральное хранилище и структуры, вмещающие состояние объекта.

Сервис имен (Naming) управляет иерархией имен.

Объекты контекстного именования могут:

  • связывать,
  • разъединять,
  • повторно связывать,
  • уничтожать,
  • соединять контексты и новые контексты,
  • создавать списки.

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

Событийная система уведомлений (Event Notification).(подій)

Поддерживаются объекты, выполняющие такие функции:

  • поддержка потребителей и поставщиков сообщений
  • поддержка "типизованных событий"
  • нетипизованные события, использующие тип "any"
  • типизованные события описываются в IDL

Контроль тупиковых ситуаций (Concurrency Control).

Множественный считыватель/одиночный записыватель:

  • читает и пишет;
  • обновляет (из чтения в запись без отключения блокировки);
  • активно читает;
  • активно записывает в модели блокировочного иерархического механизма.

Транзакции как сервисы поддерживают:

  • набор слабых и гнездовых транзакций,
  • одно- или двухфазное завершение транзакции,
  • восстанавливаемые и невосстанавливаемые объекты транзакций.

Клиент транзакции - начинающий транзакцию

Транзакционный сервер - обслуживающий транзакции

Сервер отката - завершающий транзакцию

Контекст транзакции - идентифицирует транзакцию (может быть задействована более чем одна нить транзакции)

Ресурсы - сервис транзакции вызывает протокол на зарегистрированном ресурсе (подготовка, откат, завершение транзакции, завершение транзакции в одной фазе, забывание транзакции)

Взаимосвязи (Relationships) (Відношень) поддерживают:

  • типы,
  • роли,
  • приоритеты (в связанных системах),
  • главенствование (при максимуме связей),
  • семантика (операции и атрибуты),
  • навигация.

Управление изменениями (Change Management), (зовнішнього подання) Поддерживает идентификацию и согласованную эволюцию объектов. Сюда входит управление версиями существующих объектов, связанными наборами или конфигурациями объектов, и преобразованиями между соответствующими представлениями объектов.

Cервис запросов (Query Service)

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

Служба Лицензирования (Licensing Service).

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

Управление свойствами (Properties).

Свойство состоит из имени и значения (типа `any`) и может иметь режимы доступа:

  • нормальный - нет ограничений (изменяемый и удаляемый)
  • только чтение - удаляемый, но не изменяемый
  • нормальный фиксированный - изменяемый и не удаляемый
  • фиксированный, только чтение - неизменяемый и неудаляемый

Свойства имеют законченную систему управления:

  • вычислениями
  • факторингом (генерации новых объектов по шаблонам)
  • определениями (PropertyDefs)
  • факторингом определений и т.д.

Время (Time)

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

Служба Безопасности Объектов (Object Security Service).

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

Cбор информации (Collections) как сервис состоит из:

  • очередей
  • списков (или массивов)
  • деревьев (графов)
  • стеков
  • настроек

Расширение (Externalization)

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

Базова ієрархія COM-технології: сервер/клас/інтерфейс/метод. COM-інтерфейси: інтерфейс IUnknown, отримання посилання на інтерфейс, підрахунок посилань.

Рівнозначними є КОМ та КОРБА. КОМ – це технологія, КОРБА - це модель.

Модель СОМ относится к широко используемым средствам модульного программного обеспечения. Программы, созданные на ее основе, предоставляет большой набор интегрированных служб, легкодоступных инструментов и полезных приложений. Говорят, что средства СОМ имеют бинарно-совместимую (binary-compatible) архитектуру компонентов.

Компонент – это дискретная часть ПО, предназначенная для выполнения отдельной, заранее определенной работы. Компонент может использоваться любой программой. Поскольку компонент автономен, его легко заменить.

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

Объекты СОМ могут существовать в том же процессе, что и их контроллер (controller). Также их можно переместить в другой процесс.

  • Объекты внутрипроцессного сервера (in-of-process server) реализуются в виде модулей DLL и исполняются внутри пространства процесса контроллера.
  • Объекты внепроцессного сервера (out-of-process server) реализуются в виде исполняемых файлов и исполняются в отдельном пространстве процесса.

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

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

Интерфейс СОМ позволяет приложениям и разным компонентам обращаться к функциям компонента СОМ с помощью таблицы виртуальных функции (virtual function table), которая также называется viable (виртуальная таблица) или VTBL. Эта таблица содержит не реально существующие функции, а набор указателей на функции компонента. Клиенты не могут обращаться к VTBL напрямую. Для этого используется указатель интерфейса (interface pointer), который добавляет промежуточный уровень доступа и делает возможной реализацию этого интерфейса. Значит, клиент видит только указатель на указатель в VTBL.

Единственное требование к таблице VTBL интерфейса СОМ состоит в том, что первое поле в таблице есть указатель на интерфейс IUnknown как единственный интерфейс, который должен быть реализован в любом компоненте, чтобы последний мог стать компонентом СОМ. Все другие интерфейсы наследуются из интерфейса IUnknown. Компоненты СОМ содержат реализации любого числа интерфейсов. Если интерфейсы слишком долго отсутствуют или изменены, то взаимодействие прерывается. После того, как интерфейс определен и опубликован (сделан общедоступным для использования без ограничений), его нельзя изменить. Одно из правил СОМ – ПО поддерживается неизменным интерфейсом после его опубликования. Свойства интерфейсов: Интерфейс не является классом. Интерфейс не является объектом. Интерфейсы строго подразделены по типам. Интерфейсы неизменны.

Интерфейс IUnknown должен реализовывать каждый компонент СОМ. Все объекты СОМ реализуют интерфейс IUnknown, так как он управляет всеми интерфейсами объекта. Интерфейс IUnknown содержит три метода: QueryInterface, AddrRef и Release. Метод QueryInterface используется для выявления почти всех доступных интерфейсов объекта. Если нужно использовать один из этих интерфейсов, вызывается метод AddRef. По завершении работы с отдельным интерфейсом вызывается метод Release.

Интерфейс IDispatch порождается интерфейсом IUnknown и первоначально был создан для удобства использования языков сценариев. Его использование не рекомендуется при разработке приложений (по причине роста накладных расходов), к которым не требуется доступ из языков сценариев. Интерфейс IDispatch содержит функции, которые позволяют обращаться к методам и свойствам объектов COM, позволяя VB и другим языкам сценариев управлять свойствами и методами объекта.

Сигнатура интерфейса предоставляет пользователям информацию о: число и порядок методов в интерфейсе;число, порядок и тип всех параметров каждого метода; тип возвращаемого значения каждого метода. Тип параметра указывает, является ли параметр входным (in), выходным (out) или входным/выходным (in/out).

Подсчет ссылок (reference counting) определяет, как приложение отслеживает экземпляры объектов СОМ. Правила подсчета ссылок таковы.

  • Для корректного подсчета ссылок в VC++ для каждой новой копии указателя интерфейса вызывается метод AddRef, а при каждом разрушении указателя интерфейса – метод Release.

Средства СОМ попытаются связаться с SCM (Service Control Manager – диспетчер управления службами). Диспетчер SCM является службой СОМ, которая управляет активацией СОМ, используя следующие процедуры:

  • когда клиенты впервые запрашивают объект сервера СОМ, они предают диспетчеру SCM код ID объекта;
  • диспетчер SCM находит и загружает сервер, получая эту информацию из системного реестра;
  • диспетчер SCM просит компонент сервера создать запрашиваемый объект;
  • диспетчер SCM получает ссылку на интерфейс объекта и возвращает его клиенту;
  • после возврата диспетчером SCM ссылки на клиента, его работа завершается. Теперь клиент и сервер готовы к взаимодействию.

Типи COM. Клієнти і COM-сервери.

Сервери мають стандартну структуру. Клієнти ні.

Компонент СОМ создается как модуль ActiveX DLL, содержащий классы, к которым программа может получить доступ через компонент СОМ. Затем компонент регистрируется в системном реестре Windows клиента. Таким образом, можно создавать простые ссылки на проект клиентской программы. Программа "знает" все о компоненте из записей в системном реестре, в том числе о расположении DLL на компьютере; поэтому его можно загружать и исполнять.

Вы можете упаковать объекты СОМ тремя способами: в виде клиентов, в виде серверов и в виде элементов ActiveX.

Клиенты СОМ являются приложениями или инструментами программирования, которые управляют одним или несколькими объектами СОМ. Эти объекты могут существовать в этом же приложении или в каком-то другом. Клиенты используют существующие объекты, создают новые экземпляры объектов, получают и устанавливают свойства, а также вызывают методы, поддерживаемые объектом. Инструментальные средства VB представляют собой клиента СОМ.

Можно создать клиентов, выполнив следующие действия:

  • написав программный код в приложении, которое с помощью средств автоматизации обращается к объектам, предоставляемым другим приложением;
  • изменив существующий инструмент программирования, например встроенный макроязык, для добавления поддержки автоматизации;
  • разработав новое приложение, например компилятор или броузер информации о типе (type information), который поддерживает автоматизацию.

Объекты СОМ могут существовать в том же процессе, что и их контроллер (controller). Также их можно переместить в другой процесс.

  • Объекты внутрипроцессного сервера (in-of-process sewer) реализуются в виде модулей DLL и исполняются внутри пространства процесса контроллера.
  • Объекты внепроцессного сервера (out-of-process server) реализуются в виде исполняемых файлов и исполняются в отдельном пространстве процесса.

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

Объекты внутрипроцессного сервера фактически могут исполняться как автономные объекты, если они исполняются под управлением псевдопроцесса (surrogate process). Клиенты без всяких затруднений могут создавать внепроцессные объекты, базирующиеся на модулях DLL.

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

Роль елементів ActiveX щодо побудови бізнес-об’єктів розподілених застосувань.

В качестве основы элементов ActiveX использована спецификация OLE Control 96 (ОС96). Она предназначалась для построения небольших элементов с высокой скоростью исполнения. Кроме того, впервые в истории пользовательских элементов управления стали использоваться элементы без дескрипторов окна (window handle), так называемые "безоконные" элементы.

OLE (англ. Object Linking and Embedding) — технология связывания и внедрения объектов в другие документы и объекты, разработанные корпорацией Майкрософт. OLE позволяет передавать часть работы от одной программы редактирования к другой и возвращать результаты назад. Например, установленная на персональном компьютере издательская система может послать некий текст на обработку в текстовый редактор, либо некоторое изображение в редактор изображений с помощью OLE-технологии.

ActiveX - компоненти, що працюють за певними правилами, мають можливість звернутись до сервера через VTBL, набором функцій що визначає можливості цього застосування.

Элементы ActiveX реализуются в виде внутрипроцессного сервера, который можно использовать в любом контейнере OLE, например VB. Различие между элементом ActiveX и внутрипроцессным сервером СОМ в том, что элементы ActiveX, как правило, имеют пользовательский интерфейс. Полный набор функциональных возможностей элемента ActiveX доступен только при использовании внутри контейнера, сконструированного специально под элементы ActiveX.

В элементах ActiveX используется несколько программных компонентов, эффективно взаимодействующих с контейнером элемента ActiveX и его пользователем. Элементы ActiveX должны работать согласованно со своим контейнером и должны предоставлять свойства и методы, определяемые их функциональным предназначением. Кроме того, эти элементы должны связываться со своим контейнером, а контейнер – связываться с ними. Наконец, элементы ActiveX должны сохранять свои свойства: если их закрыть, а потом снова открыть, они должны "вспомнить" свои свойства, если это необходимо.

ActiveX – це каркас (framework) для визначення реюзе компонентів(які називають контролами), що виконують певний набір функцій в середовищі Віндовс таким чином, що результат не залежить від того якою конкретно мовою було написано контрол. Програмний продукт може об’єднувати декілька таких котлів для виконання своїх задач.

Багато застосувань від Microsoft(Internet Explorer, Microsoft Office, Microsoft Visual Studio, and Windows Media Player) використовують цю технологію для побудови власної функціональності та представлення цієї функціональності для інших застосувань. Так, наприклад, ІЕ може відображати елементи ActiveX з веб-сторінок.

Модель DCOM. Внутрішньо- і зовнішньопроцесні компоненти. Віддалений виклик процедур і впорядкування передач параметрів і результатів (маршалінг/анмаршалінг).

Средства DCOM – это просто средства СОМ на расстоянии. DCOM позволяет исполнять ваши компоненты не на том компьютере, который используется вашим компонентом DCOM. Компонент DCOM обычно (но не обязательно) исполняется на другой машине в собственном пространстве процессов. Независимо от исполнения на локальной или удаленной машине, функциональные средства компонента доступны вашей программе и другим компонентам.

DCOM служит "пропуском" на доступ к распределенной части приложения.

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

Можно написать компонент всего один раз и позволить использовать его многим программистам.

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

При замене компонентов можно заменить их всего один раз на сервере, вместо изменения на каждой клиентской машине.

Средства DCОМ хороши, но каждый раз вам придется решать, перевешивают ли преимущества средств DCOM их недостатки, перечисленные ниже.

Как программисту, вам придется переместить свое внимание со свойств на службы. Для этого надо научиться думать немного иначе, что требует некоторого навыка.

Установка компонентов DCOM сложнее установки обычных приложений. Вам следует убедиться, что клиент знает о серверных компонентах и их местоположении.

Компоненты, находящиеся в сети, работают медленнее компонентов, помещенных на сервере, из-за времени, потраченного на обработку сетевого трафика.

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

Объекты внутрипроцессного сервера (in-of-process server) реализуются в виде модулей DLL и исполняются внутри пространства процесса контроллера.

Объекты внепроцессного сервера (out-of-process server) реализуются в виде исполняемых файлов и исполняются в отдельном пространстве процесса.

Именно RPC превращают модель СОМ в DCOM. Для обслуживания DCOM фирма Microsoft расширила средства RPC с помощью механизма ORPC (Object RPC – вызов объектной удаленной процедуры), расширяющего возможности RPC по части вызова и создания удаленного объекта, а также передачи ссылок. Когда процедура вызывается удаленно, она выполняет функцию на удаленном компьютере и возвращает результат исполнения этой функции. В распределенных приложениях данные для передачи между процедурами собираются в пакет и передаются по сети с помощью вызова.

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

Для передачи параметров нужен механизм, позволяющий передавать данные за пределы процесса (process boundary). Это и есть маршализация. Маршализация работает с помощью механизма, который использует объекты, называемые заместителями (proxies) и суррогатами (stubs). Они обеспечивают функцию представительства (proxy function), встроенную в клиент, и суррогатную функцию (stub function), встроенную в компонент. Заместитель (proxy) маршализует данные и готовит их для отправки за пределы процесса в компонент. Напротив, суррогатная функция (stub function) демаршализует данные для использования компонентом.

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

Базова ієрархія COM+-технології: застосування/клас/інтерфейс/метод. Декларативне програмування з використанням атрибутів за архітектурою Windows DNA розподілених застосувань. Три яруси застосувань у Windows DNA.

COM+ відрізняється від COM наявністю монітора транзакцій за допомогою якого можна побудувати будь-який інтерфейс.

Архитектура Windows DNA – оболочка, позволяющая разработчикам строить распределенные приложения с помощью технологий и служб, являющихся частью Windows. Архитектура Windows DNA предоставляет набор конструкторских правил, помогающих разработчикам делать корректный выбор вариантов технических решений при создании ПО для новых приложений. Архитектура Windows DNA позволяет разработчикам уделить основное внимание решению бизнес-проблем, а не заниматься управлением технологической инфраструктуры.

Модель Windows DNA взаимодействует с тремя ярусами (tier) приложения:

  • ярус пользовательского интерфейса (UI – User Interface);
  • средний ярус, управляемый с помощью технологии СОМ+;
  • ярус базы данных.

Технология СОМ+ составляет средний ярус приложений. Сервер MTS (Microsoft Transaction Server – сервер транзакций Microsoft) стал первым инструментом, предоставляющим помощь разработчикам программных средств среднего яруса. Главным назначением сервера MTS было предоставление средств управления транзакциями, что позволяло уделять внимание деловым проблемам и уменьшать инфраструктуру для поддержки транзакций. Сервер MTS также помогал разработчикам управлять ресурсами сервера. Вторым инструментом была MSMQ (Microsoft Message Queue – очередь сообщений Microsoft), которая поддерживала отсоединенных пользователей и приложения, основанные на сообщениях. Средства СОМ+ – это объединение средств MTS и всех других служб, сконструированных для поддержки построения распределенных приложений.

С помощью административного инструмента Component Services Snap-in (Сменные служебные компоненты), диалоговое окно которого показано на рис. 11.1, вы можете конфигурировать и администрировать компоненты СОМ и приложения. Инструмент Component Services Snap-in, также называемый СОМ+ Explorer (Проводник СОМ+), должен стать вашим лучшим другом. Он позволяет выполнить большинство операций конфигурирования всех своих компонентов.

Про COM+

афтар: Евгений Марков, Генеральная Сервисная Компания (Санкт-Петербург)

Технология COM+ базируется на возможностях COM и обеспечивает поддержку распределенных приложений на компонентной основе. Объекты транзакций COM+ обладают основными свойствами объектов COM. Кроме этого, объекты транзакций реализуют специфические возможности, присущие только объектам MTS:

  • управление транзакциями;
  • безопасность;
  • пулинг ресурсов;
  • пулинг объектов.

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

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

Транзакції СОМ+ та організація черг компонентів (QC). COM+-сервіси: активація за потреби, пул об’єктів, синхронізація, безпека, автоматичні транзакції, черги, вільно зв’язані події, балансування завантаження.

Компоненты СОМ+ со средствами выполнения транзакций предоставляют оболочку, создаваемую вокруг транзакций MS DTC (Координатор распределенных транзакций (Distributed Transaction Coordinator)) для формирования транзакции СОМ+. Когда из компонента транзакции (transactional component) создается объект, средства СОМ+ автоматически создают транзакцию СОМ+. Когда объект активирован (метод вызван), средства СОМ+ создают физическую транзакцию (транзакцию MS DTC). При деактивировании объекта средства СОМ+ вызывают метод Commit (Подтвердить) или Abort (Отменить) для физической транзакции.

Вы можете управлять созданием транзакции, устанавливая свойства транзакции (transaction property).

Средства QC (Queued Components) являются ключевыми в технологии СОМ+ Средства QC предоставляют простой способ асинхронного вызова и исполнения компонентов. Они основываются на очереди MSMQ. Использование средств MSMQ требует знания способов маршализации очереди, а также отправки и приема сообщений.

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

Для вызова организованных в очередь компонентов используется моникер (moniker), который создает экземпляр объекта непосредственно либо предавая идентификатор CLSID моникеру queue.

В очередь QC также входят компоненты, перечисленные ниже:

  • Recorder (Рекордер) – для клиентской или отправляющей стороны;
  • Listener (Слушатель) – для серверной или принимающей стороны;
  • Player (Проигрыватель) – для серверной или принимающей стороны;
  • Инструмент администрирования Message Mover (Переносчик сообщений), который перемещает сообщения из одной очереди в другую.

Главное назначение средств QC – обеспечение механизма удаленных вызовов (remoting mechanism) для интерфейсов СОМ. Это позволяет удаленным серверным объектам исполняться после их вызова клиентом. Механизм удаленных вызовов QC выполняет запись всех вызовов методов объекта и не проигрывает их, пока клиентский компонент не завершит использование серверного объекта, а транзакция (которая записывала вызовы методов) не достигнет нормального завершения (будет подтверждена).

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

Средства QC обрабатывают сбой транзакции с помощью серии "повторных" очередей, связанных с конкретным приложением. Для каждого приложения имеется пять очередей:

  • Обычная входная очередь,
  • Первая повторная очередь,
  • Вторая повторная очередь,
  • Третья повторная очередь,
  • Конечная отстойная (resting) очередь.

При отмене каждой транзакции компонент Player генерирует событие LCE (Loosely Coupled Event – слабосвязанное событие). Оно генерирует одно событие, когда сообщение перемещается из одной очереди в следующую, и еще одно событие, когда сообщение помещается в конечную отстойную очередь. Слабосвязанные события (LCE) являются частью основанных на компонентах событийных систем, которые используют модели публикования (publish) и подписки (subscribe). Серверы публикаций (publisher) публикуют события подписчикам. Подписчики могут подписаться на любое публикованное событие.

Объекты QC поддерживают основанную на ролях семантику системы защиты подобно другим объектам СОМ+.

Динамическое выравнивание нагрузки – это механизм распределения клиентских вызовов по множеству серверов для их дальнейшей обработки (совершенно незаметный для самого клиента). При динамическом выравнивании нагрузки для специального приложения устанавливается целевая группа устройств (обычно группа серверов). Указанное приложение автоматически реплицируется на устройствах целевой группы. Данные совместно используются в централизованном порядке или реплицируются на серверах (с правами доступа только на чтение). Клиенты или клиентские приложения конфигурируются для использования маршрутизатора с выравниванием нагрузки. Анализатор выравнивания нагрузки отслеживает характеристики управляемых ресурсов. Механизм выравнивания нагрузки использует результаты анализа для динамического принятия решения о выборе используемого устройства. Различные анализаторы взаимодействуют друг с другом при принятии решений по маршрутизации.

Система Windows поддерживает следующие средства выравнивания нагрузки.

СОМ+ позволяют строить приложения, использующие компоненты СОМ с дозированным распределением по серверам.

Windows (WLB – Windows Load Balancing) обеспечивает основанное на протоколе IP выравнивание нагрузки и мультисерверную расширяемость для служб системного уровня.

Организация пула объектов была сконструирована для компенсации расходов на создание дорогостоящих объектов. Производительность работы можно улучшить при внесении объекта в пул. Тогда при запросе нового объекта метод CoCreateInstance извлекает его из пула, а метод Release возвращает его в пул. Однородность пула по отношению к идентификаторам CLSID обеспечивает высокую производительность этого механизма.

Об’єктна DOM-модель документа та розширювана мова розмітки XML, мова XSD визначення схеми XML, розширювана мова стилів XSL.

Від Перевозчикової:

XML – має XSD схему. Маємо зараз одну таку схему. Вона всіх поєднала. Стандарт під егідою ООН - ebXML. Electronic data exchange – перше використання XML. Стандарт EDIFACT. Всі комерційні організації, банки працюють з стандартними документами XML, що є локалізованими і створеними на базі EDIFACT. Обєктна DOM – модель.

Переход на стек спецификаций XML позволяет:

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

Все эти возможности логичнее всего реализовывать в специализированных продуктах разработки Web-контента и его сопровождения. Флагманы индустрии Web, такие как IBM, Microsoft, Sun Microsystems, Software AG, Oracle, Netscape и др., активно разрабатывают эту ниву. Результатом усилий, сосредоточенных на этом направлении, будет переход индустрии разработки Web-контента и средств доступа к нему на эти продукты.

Стек спецификаций XML.

Раніше: SGML(рівень опису структури даних), HTML(рівень метаданих), PICS 1.0 (рівень представлення), нові підходи: XML(рівень опису структури даних), XHTML, RDF(рівень метаданих), Pics 2.0(рівень представлення). Цель нового подхода W3C состоит в том, чтобы разработать набор спецификаций форматов данных, который бы позволил улучшить модульность и расширяемость номенклатуры форматов для любых видов приложений. При этом новый набор спецификаций должен обеспечить и преемственность. Идея состоит в том, что все данные описываются в определенном порядке и, если следовать этому порядку, то спецификации будут представлять собой стек. Первый уровень такого стека - описание структуры данных. Второй уровень стека - описание семантики (смысла, содержания). Третий уровень стека - описание способа применения (отображения, преобразования и т.п.) данных.

Современные взгляды на документ как на структуру типа дерево (Document Object Model), то это преобразование одного графа в другой.

Функциональное назначение новых спецификаций. Рассмотрим коротко основное назначение компонентов нового стека.

В основе всех спецификаций лежит XML(eXtensible Markup Language). Это значит, что и PICS 2.0, и XHTML - суть XML документы. XML - это расширяемый язык разметки. XML является одним из клонов SGML. XML не заменяет собой HTML. У этих двух языков совершенно разное назначение. У XML две главных задачи: во-первых, обеспечить описание структуры данных, во-вторых, обеспечить общий синтаксис для всех других спецификаций. Таким образом, XML не указывает, как надо отображать документ, он только описывает его структуру и содержание.

С точки зрения W3C следующей по значимости спецификацией является RDF (Resource Description Framework). Основное назначение RDF - описание XML-ресурсов с самых разных точек зрения. Другими словами - это форма метаданных.

На том же уровне стека спецификаций, что и RDF находится XSL (eXtasible Style Language). Основное назначение XSL - описание формы представления данных на носителе. Пока речь идет главным образом о двух формах представления - отображение документа в рабочей области браузера и на листе бумаги. Но, как не трудно догадаться, номенклатура носителей может быть расширена. Если это произойдет, то XSL имеет все шансы пересечься с RDF по области применения.XSL состоит из двух частей: спецификации преобразований (transformation) и спецификации форматируемых объектов (formating objects). Назначение первой - определить возможные способы преобразования XML-конструкций в форму, пригодную для отображения, а второй - обобщить свойства отображаемых объектов и отклассифицировать эти объекты. XSLT(eXtansible Style Language for Transformation) частично содержит инструкции преобразования, т.е. является чем-то средним между декларативным языком и процедурным. В нем есть даже конструкция function.

Жесткость и строгость правил разметки вытекает из двух свойств XML: документы должны быть синтаксически правильными(well-formed) и должны обеспечивать "достоверность"(validating). Первое требование вытекает из необходимости построения дерева объектов в соответствии с DOM, а второе - из возможности реализации подстановок, в том числе, и рекурсивных, как на стороне сервера, так и на стороне клиента.

Platform for Internet Content Selection (PICS) - это спецификация меток, которые можно ассоциировать с содержанием документов. Первоначально она разрабатывалась как "помощь родителям и учителям в контроле за содержанием Internet-ресурсов, которые просматривают дети". Если рассматривать PICS в более широком контексте, то - это механизм, предназначенный для обеспечения ограничений, введенных законодательством страны или владельцем ресурса на распространение информации определенного содержания.

XML Schema — один из языков описания структуры XML документа. Как большинство языков описания XML, XML Schema была задумана для определения правил, которым должен подчиняться документ. Но, в отличие от других языков, XML Schema была разработана так, чтобы её можно было использовать в создании программного обеспечения для обработки документов XML. После проверки документа на соответствие XML Schema, читающая программа может создать модель данных документа, которая включает: словарь (названия элементов и атрибутов), модель содержания (отношения между элементами и атрибутами и их структура), типы данных. Каждый элемент в этой модели ассоциируется с определённым типом данных, позволяя строить в памяти объект, соответствующий структуре XML-документа. Языкам Объектно-ориентированного программирования гораздо легче иметь дело с таким объектом, чем с текстовым файлом. Другим удобством XML Schema является то, что один словарь может ссылаться на другой, и таким образом разработчик может использовать уже существующие словари, и легче устанавливать и распространять стандарты XML структуры для определённых задач (например, словарь протокола SOAP).

Приклади компонентних технологій: .NET Framework, Enterprise JavaBeans.

.NET Framework — программная технология от компании Microsoft, предназначенная для создания обычных программ и веб-приложений.

Одной из основных идей Microsoft .NET является совместимость различных служб, написанных на разных языках. Например, служба, написанная на C++ для Microsoft .NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на C# можно написать класс, наследованный от класса, написанного на Visual Basic .NET, а исключение, созданное методом, написанным на C#, может быть перехвачено и обработано в Delphi.

Подобно технологии Java, среда разработки .NET создаёт байт-код, предназначенный для исполнения виртуальной машиной. Входной язык этой машины в .NET называется CLI (Common Language Infrastructure). Применение байт-кода позволяет получить кроссплатформенность на уровне скомпилированного проекта (в терминах .NET: сборка), а не только на уровне исходного текста, как, например, в С. Перед запуском сборки в среде исполнения CLR байт-код преобразуется встроенным в среду JIT-компилятором (just in time, компиляция на лету) в машинные коды целевого процессора. Также существует возможность скомпилировать сборку в родной (native) код для выбранной платформы с помощью поставляемой вместе с .NET Framework утилиты NGen.exe.

Компілятор С# переводить програми у байт-код проміжної мови (Intermediate Language — IL), що потім транслюється середовищем часу виконання платформи .NЕТ (IL Common Language Runtime). Мова ІL платформно-незалежна, тобто один раз відкомпільована програма може завантажуватися на кожній .NET-платформі, від Windows 2000 до Windows СЕ.

Автоматичне "прибирання сміття". У свій час архітектори Java багато попрацювали над створенням механізму автоматичного керування пам'яттю, що отримав назву автоматичного прибирання сміття.

Творці С# також узяли на озброєння зазначений підхід. Розробники програмного забезпечення будуть цілком врятовані від головного болю, пов'язаного з керуванням пам'яттю, при роботі з новою мовою. При цьому сам механізм прибирання сміття в С# виглядає більш проробленим, ніж реалізований у Java.

С# містить у собі повноцінну підтримку технології СОМ+ і Windows АРІ, а також можливість взаємодії з іншими бібліотеками для платформи Win32. Досягається це за допомогою механізмів делегування (делегати в чомусь схожі на функціональні покажчики С++).

При цьому сам С# не має навіть власної бібліотеки класів. Проте він повною мірою використовує багаж інших систем програмування Microsoft (Visual С++, Visual Ваsіс, середовища виконання сценаріїв і ін.).

EJB (Enterprise Java Beans)

Перед тем как приступить к подробному обсуждению, давайте посмотрим, что же в действительности представляет собой EJB. По сути, это система распределенных, транзакционных и безопасных программных компонентов. На более абстрактном уровне отдельный Enterprise Java-Bean есть не что иное, как компонент ПО, составленный в строгом соответствии со спецификацией EJB. Эта спецификация описывает взаимосвязь между компонентом ПО (собственно bean) и средой его выполнения (контейнером). Но это еще не все. В дополнение к описанию структуры компонентов спецификация EJB определяет и условия, необходимые для получения законченных решений при совместной работе различных поставщиков.

Конечная цель спецификации EJB – создание платформно-независимой среды разработки компонентного ПО, которая позволит разработчикам выбирать компоненты из пакета компонентов и подключать их в более крупные приложения. Для достижения этой цели в спецификации EJB определена система ролей в жизненном цикле разработки ПО: Разработчик компонентов (EJB provider); Сборщик приложений (Application assembler); Установщик (Deployer); Разработчик серверных компонентов (EJB server provider); Разработчик контейнеров (EJB container provider)

Элементы архитектуры

Распределенность

Создать распределенный компонент сравнительно просто. Для описания удаленных интерфейсов разработчикам не придется изучать специальные языки, типа IDL (Interface Definition Language). Чтобы определить удаленные методы, используются стандартные элементы языка Java – интерфейсы и классы. Поддержка доступа удаленного клиента осуществляется при помощи двух стандартных Java API: Java Remote Method Invocation (RMI) и Java Naming Hid Directory Interface (JNDI).

Транзакции

Одним из основных свойств компонента EJB является его способность взаимодействовать с другими компонентами, будь то Enterprise JavaBeans или компоненты DCOM/CORBA. Но необходимо, чтобы ваши компоненты можно было сгруппировать в логическую транзакцию. Для реализации этого требования используется API-интерфейс Java Transaction Service (JTS).

JTS представляет собой реализацию на Java спецификации Object Transaction Service (OTS), разработанную OMG. Теоретически это позволяет компонентам EJB работать с другими объектами, поддерживающими данный стандарт, например, компонентами CORBA.

Возможность долговременного хранения (персистентностъ)

Для долговременного хранения экземпляров объектов в EJB используется специальный тип компонентов – компоненты-сущности (entity bean). Такие объекты продолжают сохранять свое состояние даже после завершения работы контейнера EJB. Спецификация определяет два типа персистентности: управляемую контейнером и управляемую компонентом.

Защита

Разрабатываемые системы должны поддерживать комплексные требования защиты, предъявляемые сообществом пользователей, не снижая показателей производительности. Политику защиты определяет установщик во время развертывания приложения.

Отримано з http://wiki.usic.org.ua/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D1%96%D1%94%D0%BD%D1%82%D0%BE%D0%B2%D0%B0%D0%BD%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F:%D0%86%D1%81%D0%BF%D0%B8%D1%82
Особисті інструменти