Скачать презентацию ТЕХНОЛОГІЇ ПРОГРАМНИХ ТА РОЗПОДІЛЕНИХ ПРИКЛАДНИХ СИСТЕМ З
7268cbf04ffd9133ef06a56303f29016.ppt
- Количество слайдов: 102
ТЕХНОЛОГІЇ ПРОГРАМНИХ ТА РОЗПОДІЛЕНИХ ПРИКЛАДНИХ СИСТЕМ З ЗАСТОСУВАННЯМ ГОТОВИХ РЕСУРСІВ (1992 -2012) доктор фіз. - мат. наук, проф. Лавріщева К. М. Доповідь на науковому семінарі ІПС НАНУ присвячується реалізації ідей академіка В. М. Глушкова
Технологія програмування програмних систем (ПС) з готових програмних компонентів. Історічний анонс 1. Об’єктне програмування. Метод Фреге І Буча. 2. Компонентне програмування. ОКМ – метод. 3. Генераційне програмування. Взаємодія і варіабельність. 4. Сервісне програмування. Семантик-Веб.
Технологія зборочного програмування програмних систем з готових програмних ресурсів. Історічний анонс
Предметна область (Пр. О) – це область знань, що визначається відповідним набором понять і термінологій для замовників і користувачів. Модель Пр. О - це сукупність об’єктів, пов'язаних між собою деякою множиною відношень та поведінкою. об’єктна орієнтація = об’єкти + успадкування. Модель Пр. О – це сукупність понять, концептів простору проблем з властивостями і характеристиками на множині синонімів і класифікаційних логічних зв’язків між ними. Об'єкт це абстрактний образ або конкретний фізичний предмет або групи предметів з зазначеної множини їх характеристик та функцій. Компонент - самостійний продукт, що підтримує об'єктну парадигму, реалізує частину або усю окрему Пр. О і уміє взаємодіяти з іншими компонентами через інтерфейси. Модель компонента КПВ = (T, I, F, R, S), де T – тип компонента; I – множина інтерфейсів; F – функціональність компонента; R – реалізація чи програмний код; S – сервіс, що забезпечує взаємодію компонента з середовищем щодо оброблення або розгортки. Програмна система (ПС) – сукупність окремих об’єктів чи компонентів з реалізації взаємопов’язаних функцій Пр. О у заданому середовищі. Сімейство програмних систем (СПС) – це сукупність ПС, які визначаються спільною множиною понять та множиною спеціальних понять, що притаманні кожному окремому члену СПС.
Сімейство продуктів (ISO/IEC FDIS 24765: 2009 E) «група продуктів або послуг, які мають спільну керовану множину властивостей, що задовольняють потреби певного сегменту ринку або виду діяльності» Розподілена прикладна система (РПС) - це система, що складається з готових ресурсів (компонентів, сервісів, даних), ПС, які розташовані на об'єднаних у мережі хостах, і можуть взаємодіяти між собою через зовнішні загальні механізми - модель OSI, протоколи RPC, RMI, WCF, SOA, SCA, Інтернет тощо. Сервіс-орієнтована архітектура (SOA) РПС - набір принципів і засобів розробки програм РПС із сумісних і уніфікованих сервісів та послуг. Уніфікація – це типізація функціональноcті, семантики сервісів за їхніми характеристиками та мовами опису сервісів для динамічного (runtime) виконання на вебі.
В. М. Глушков ініціював розвиток (1960) – технології побудови ЕОМ, обчислювальних комп’ютерів зі схемною інтерпретацією мов (Миры, Украина), макроконвеєров, Маяк; – технології програмування (операцийні системи, транслятори, відладчики, редактори, системи автоматизації програм, ППП…); – технології побудови АСУ, АСУ ТП, систем автоматизації підприємств та напрямів діяльності (математичного, економічного, транспортного, будівельного і др. ). По цим напрямам технології розвивалися і Computer Science (1960) з головним терміном Software Engineering (1968) - інженерія (конструювання) ЕОМ і їхнього програмного забезпечення.
Зборочний конвеєр Глушкова (1975) “Через 20 -30 років з’являться фабрики програм, що працюватимуть за принципом зборочного конвеєра, як в автомобільній промисловості Форда. . . Індустрія компютерних програм буде ґрунтуватися на технологічних лініях (ТЛ) конвеєрного виготовленні різних продуктів: комп’ютерів, АСУ, АСУ ТП, програмних і інформаційних систем”. З часом ці передбачення повністю виправдалися. Зараз дія багата різних фабрик програм з готових програмних ресурсів. В Україні побудовано (2011) експериментальну студентську фабрику програм і артефактів з 4 ТЛ по принципу Глушкова в КНУ імені Тараса Шевченко під керівництвом викладача КНУ проф. К. М. Лавріщевої.
призначена для промислового виготовлення програмного продукту (ПП) з готових ресурсів (модулів, програм в різних PL, даних) для масового застосування на підприємствах і організаціях СРСР. Базис ТП – експериментальні технологічні лінії для зборки ПС, АСУ з готових програм, подібно фабрикам програм. Технологія продукту ПС – це метод програмування, процеси ТЛ з побудови елементів продукту, організація і управління ними за підтримкою технологічних модулів (ТМ), інструментальних засобів (трансляторів, редакторів, трансформаторів, збиральників, компонувальників, тестіровщиків)
Шляхи розвитку технології програмування Идея В. М. Глушкова – производство программ по принципу сборочного конвейера (1975). Постанова ДКНТ СМ СРСР – «Создание Гос. ФАП и РФАП» (1966 -1996) та «Программные средства как продукция производственно-технического назначения» (1970). Програмна інженерія – якість, продуктивність, індустрія (1968 -НАТО). Системи автоматизації виробництва програм 1980 -1990 (ПРИЗ, РТК, ПРОЕКТ, АПРОП, ДИСУППП, ДЕЛЬТАСТАТ, БЕТА…). Композиционное программирование (Редько В. Н. , более 20 диссертаций). Сборочное программирование В, М. Глушков, А. П. Ершов, Е. М. Лаврищева (1988 –защита диссертации). В пам’ять 85 летия А. П. Ершова, 90 -летия В. М. Глушкова От ручного труда к конвейрной сборки программ”Чернецки К, Айзенекер У. “Порождающее программирование(2005). Потоковая сборка программ. Гринфильд Дж. “Фабрики разработки программ” (2007), Г Ленц схеми фабрики програм в UML для . Net Фабрики програм у інформаційному світі (більш 1000) Андон П. І. , Лавріщева К. М. - 2010. Сборочный конвейер Фаулера М. ”Continuous integration”(2009) , EPAM інтеграційна фабрика програм (Белоросія). Фабрика програм Авдошіна за схемою зборки в UML (2010, Росія). App. Fabric – IBM, MS. Net, Oberon, Sun, . .
Технологія = інженерії CS Комп'ютерна технологія Системна технологія
Технологія = інженерії CS Software Engineering (технологія) – це система методів, способів і дисципліни з планування, розробки, експлуатації і супроводження програмного забезпечення (ПЗ), призначених для його промислового виробництва (www. swebok. com). Вона охоплює усі аспекти створення ПЗ від початку формулювання вимог, розроблення продукту, використання, супроводження та остаточного його списання. Базис цієї технології – теорія алгоритмів, теорія програмування, теорія обчислень і розподіленої комунікації, а також теорія планування, регулювання процесів та ресурсів, тестування, вимірювання, оцінювання ризику та якості ПП. Інформаційні системи – це комп’ютерні системи обробки різноманітної інформації в підприємській та бізнес діяльності, включаючи бухгалтерський облік, розрахунки заробітної плати, документообіг на усіх рівнях управління тощо. Це засоби керування та обробки інформації, забезпечення продуктивності та ефективності роботи різних організацій. Інформаційні пошукові системи - головні інструменти накопичення, пошуку і відбору різних ресурсів Інтернет масового застосування.
Технологія = інженерії CS Інформаційні технології – базис комп’ютерної інфраструктури сучасних корпорацій, підприємств та державних органів управління, на яких вирішуються різні задачі обробки різноманітної інформації, зокрема глобального типу. На розробку інформаційних технологій і підготовку високо кваліфікованих ІТ–спеціалістів виділяються неймовірні ресурси для підтримки і зростання різних видів інформаційних ресурсів Інтернет і доступу до них усіх бажаючих у світовому інформаційному простору. Головні цілі і завдання інформатики з побудови інформаційних систем і технологій сформулював академік В. М. Глушков у своєї останній в житті монографії «Беспаперова інформатика» (1982).
Становлення технологии программирования і індустрії в СРСР 1969 -1992
Перспективные направления 1985– 1995 гг. 1. Сборочное программирование 2. Языки спецификаций. 3. Промышленное изготовление программных продуктов. 4. Язык разработки – формализованный язык высокого уровня со средствами модуляризации. 5. Язык программирования и язык разработки объединить, допуская комплексирование с готовыми модулями…. » . 6. Выработать и унифицировать нормативы по технологии второго поколения, которые обеспечили бы: - общую этапность разработки программного продукта; - нормативы производительности и надежности продукта; - организационно-документационную структуру; - вычислительную инструментальную среду; - межмодульный интерфейс, поддерживающий принцип сборочного программирования.
Модульное программирование Система алгоритмических алгебр (Цейтлин Г. Е. , Глушков В. М. ) Синтезирующее программирование (Тыугу Э. Х. ) Алгебраическое программирование (Летичевский А. А. ) Сборочное программирование (Лаврищева Е. М. ) Визуальное Р-программирование (Вельбицкий И. В. ) Композиционное программирование (Редько В. Н. ) Структурное программирование (Иордан Е. ) Венский метод проектирования -VDM, Raise (Д. Бьернер, С. Джонис и др. ) Процедурное программирование. Функциональное программирование…
Объектно-ориентированное программирование (Г. Буч) UML (Г. Буч, Дж. Рамбо, А. Джекобсон) Императивный концепторный язык (Коваль В. Н. ) Компонентное программирование. Генерирующее программирование (К. Чернецки, У. Айзенакер). Конструирование (Инженерия) распределенных объектов и ORB (В. Эммерих) Программирование в объектных ЯП (C++, C#, Java, VBasic, Ada, Ruby, Python, …) для современных сред. Сервисно-ориентированное программирование. Программирование семантик Веб Интернет
Інститут програмних систем, 1992 -2013.
Андона Ф. И. , Лаврищевої Е. М. Основные перспективные направления развития ТП: 1. Объектное проектирование прикладных систем(ПС); 2. Компьютерные CASE-системы проектирования ПС; 3. Приобретение и представление знаний об объектах и функциях приложений с помощью компонентов повторного использования - КПИ; 4. Стандартизация методов интеграции и сборки ПС из КПИ; 5. Подходы к реализации интерфейса компонентов RPC, ORB в системе Corba, Com, DCom; 6. Инженерия качества – подходы к достижению надежности и качества ПС.
Работы по качеству в рамках СЭВ (с 1987 -1992). Проекты по качеству при ДКНТ (с 1992 -1996) Кулаков А. Ф. , Лаврищева Е. М. , Липаева В. В. и др. «Проект стандарта качества ПС СЭВ» . Методики инженерии качества для АСУ в МО Украины (1998 -2002). Монография (1996) “Методы инженерии распределенных компьютерных приложений” (Андон Ф. И. , Лаврищева Е. М. ) Методы тестирования и оценки качества ПП (Коротун Т. М. и др. ) Диссертации (Коваль Г. И. , Коротун Т. М. , Задорожная Н. Т. , Слабоспицкая О. А. ). Монография «Основы инженерии качества программных систем. Ф. И. Андон … (2002, 2007). Учебник «Менеджмент документообігу в ІС освіти» 2007, Задорожна Н. Т. , Лавріщева К. М.
На рубежі 80 -х ХХ сторіччя Г. Буч запропонував об’єктний підхід, який змінив традіційний процес розробки програмних систем (ПС) мовами програмування і став механізмом зняття кризи складності програмного забезпечення. Фактично поява запропонованої їм теорії об'єктного програмування є технологічним рішенням у програмуванні і засобом виходу з кризи складності розробки реальних ПС. В деякому сенсі об’єктний підхід став узагальненням попереднього традиційного підходу к розробки програмного забезпечення. Програми, створені з об’єктів спрощують процес програмування, значно знижають складність ПС і забезпечують додавання і віддаління об’єктів з ПС без деяких труднощів, ніж це було раніше.
Принцип всеобщности объектного определения. Все сущности – суть объекты. Принцип объектных различий. Каждый объект – уникальный элемент. Принцип объектной упорядоченности. Все объекты упорядочены соответственно их отношениям. Принцип целостности объектной модели. Объекты и отношения между ними однозначно определяет ОМ на определенном уровне абстракции и описания. Принцип взаимодействия объектов через операции вызова объектов на множестве входных и выходных интерфейсов.
є ізу По ол мв зн Си ач ає Namei Deni Відношення Coni
Об’єкт за Фреге Ei = Ei(Namei, Deni, Coni) і на множини об’єктів E=(E 1, E 2, … En) на певному рівні об’єктного аналізу визначає Namei – знак (ім’я); Deni – денотат; Coni – концепт. Концепти об’єктів визначаються на множині предикатів P=(P 1, P 2, … Pr): Coni = (Pi 1, Pi 2, …, Pis).
Поняття об'єкту визначається на рівнях об'єктного аналізу із залученням математичних формалізмів при побудові об’єктної моделі (ОМ) з описом та уточненням функцій об’єктів та відповідних властивостей і характеристик ОМ відображає поняття і сутності Пр. О, їх зв’язки і поведінку. ОМ: «объектная ориентация = объекты + наследование, поліморфізм, інкапсуляція» , класи об ’ єктів і відношення (агрегації, асоціації. спеціалізації, єкземплярізації др. ). Аксіома 1. Предметна область (Пр. О), що моделюється з об’єктів, сама є об’єктом. Аксіома 2. Предметна область, що моделюється, може бути окремим об’єктом у складі іншої предметної області. При моделюванні об’єкт Пр. О принаймі отримує хоча б одну властивість або характеристику та унікальну ідентифікацію в множині об’єктів Пр. О та предикатів з властивостей і відношень між об’єктами. Якщо О=(О 0, О 1, …, Оn) – множина об’єктів Пр. О і О 0 відповідає самій Пр. О, то для елементів множини О виконується відношення: i[(i>0) & (Оi О 0)] (1) Кожен з об’єктів подається як множина або елемент певної множини. У цьому випадку вираз (1) трансформується у такий вигляд i j[(i>0)&( j≥ 0)& (i ¹ j)& (Оi Оj)] (2).
Мета об’єктного аналізу Предметна область подається, як множина об’єктів з властивостями та характеристиками, які необхідні й достатні для визначення та ідентифікації окремих об’єктів, а також опису їх поведінки у рамках вибраної системи понять та абстракцій. Формальні рівні абстракції подання об’єктів: Узагальнюючий рiвень Структурно-впорядковуючий рівень Характеристичний рівень Поведінковий рівень
Узагальнюючий рiвень * E 0 E 2 E 5 E 4 E 1 E 3
Структурно-впорядковуючий рiвень * E 2 E 5 E 4 E 1 E 3
Характеристичний рівень * My. Exemplar is IEnumerable My. Exemplar is IComparable My. Exemplar is ICloneable My. Exemplar is ICollection My. Exemplar is IAsync. Result My. Exemplar is IDisposable
Поведінковий рівень Визначається послідовність станів об’єктів на основі сукупності концептів об’єктів та їх значень, що відображається у діаграмах переходів станів. Взаємозв’язки між об’єктами формуються на основі бінарних предикатів, які пов’язані із властивостями об’єктів Пр. О і деталізуються до рівня вза ємовідношень між станами об’єктів. Залежність від параметра часу досягається внесенням у об’єктну модель спеціального об’єкта Timer, основне призначення якого полягає у розсилці спеціальних повідомлень поточного часу з певним рівнем дискретності. Кожен об’єкт має відповідний метод, який аналізує отримане значення і виконує перехід до іншого стану або залишає його без змін.
Декомпозиційна зміна денотату *
Композиційна зміна денотатів *
Розширення та звуження концепту *
= (O', , I, P), де O'=(O 1, O 2, On) – множина об'єктів, = {decds, decdn, comds, comdn, conexp, connar} – операції зміни денотатів, розширення та звуження їхніх концептів; I= (I 1, I 2, …, Ik) – множина зв’язків, відношень; P=(P 1, P 2, …, Pr) – множина предикатів для визначення властивостей концептів об'єктів (наприклад, Coni = (Pi 1) = true/false). Теорема. Множина операцій алгебри є повною системою операцій щодо функцій деталізації, екземпляризації, агрегації.
Результатом зв’язку двох об’єктів (наприклад. O 25. O 47) є інтерфейсний об’єкт, у якого множина вхідних інтерфейсів співпадає з множиною вхідних інтерфейсів об’єкта-приймальника, а множина вихідних інтерфейсів з множиною вихідних інтерфейсів об’єкта-передавача. Аксіома. Композиція об’єктів є коректною, якщо об’єкт-передавач повністю забезпечує інтерфейсний сервіс, який необхідний об’єктуприймальнику для виконання функції об’єкту. Об’єкти можуть мати декілька інтерфейсів, які можуть успадковувати інтерфейси інших об’єктів, тоді останні надають сервіс всієї множини вихідних інтерфейсів.
- конкретизація об'єкту: клас, екземпляр класу, об'єднаний клас-перехрещення, агрегований клас; - аналіз сутностей: 0 -арні, унарні, бінарні. Взаємовідношення: узагальнення, спеціалізація, агрегація, деталізація, класифікація, екземплярізація; - операції функції алгебри аналізу. - операції відправлення і отримання повідомлень. - операції поведінки об'єктів з урахуванням зв’язків між характеристиками та часу їх існування в ОМ.
Клас - загальна властивість, яка притаманна сукупності об’єктів. Метод (або функція) - операція над об'єктними екземплярами деякого класу. Спадкоємність - властивість довільного об'єкту зберігати поведінку (атрибути і операції) базового (батьківського) об'єкту класу на застосовність методу базового класу або похідного від нього. Інкапсуляція - доступність властивостей і методів об’єкту виконувати сумісне зберігання даних і функцій та захованість внутрішньої інформації з ізоляцією особливостей реалізації. Поліморфізм - можливість оперувати з об'єктами без однозначної ідентифікації їх типів.
Объектная технология была рождена исходя из опыта разработки реальных систем и стала самым большим обобщением опыта разработчиков за последние 20 лет. Если программу представлять в виде объектов, то она легче создается, более надежна и легко исправляется путем добавления или удаления объектов. Технология включает процессы ЖЦ: 1. Анализ Пр. О. 2. Формулировка требований. 3. Создание модели Пр. О из объектов. 4. Проектирование объектов модели для опису объектном языке программирования. 5. Реализация алгоритмов объектно-ориентированными языками (Basic, C#, Java та ін. ). 6. Опис интерфейса языком IDL. 7. Обработка программ в среде системы программирования. 8. Отладка ы тестирование. 3. Новые объектные инструменты: Java, Java Beans, Java. Script…
. Компонентні моделі: Модель компоненту: Comp = (CName, CInt, CFact, CImp, CServ), де CName – ім'я компоненту; CInt = {CInti} – множина інтерфейсів компоненту; CFact – інтерфейс керування екземплярами; CImp = {CImpj} – реалізації компоненту; CServ = {CServr} – системні сервіси. Відношення: наслідування, екземпляризації, контракту, зв'язування та взаємодії. Модель інтерфейсу: CInti = ( Int. Namei , Int. Funci , Int. Speci ), де Int. Namei - ім'я інтерфейсу; Int. Funci – функціональність (сукупність методів); Int. Speci – специфікація інтерфейсу; Модель середовища: CE = (Name. Space, Int. Rep, Imp. Rep, CServ. Imp), де Int. Rep, Imp. Rep – репозитарій інтерфейсів і реалізацій сервісів
вихідні Модель вхідного інтерфейсу Модель вихідного інтерфейсу Умова цілісності існування компонента Аксіома 4.
Компонентна алгебра: = { } = {CSet, CESet, 1} {CSet, CESet, 2}, де – зовнішня алгебра, – внутрішня алгебра, Зовнішня алгебра: = { CSet, CESet, 1}, де CSet – множина компонентів Comp, CESet – середовище Е компонентів і інтерфейсів, 1= {CE 1, CE 2 , CE 3 , CE 4} – операції алгебри: CE 1 – операції оброблення компонентів, CE 2 = Comp CE 1 операції інсталяції, CE 3 = CE 1 CE 2 операції об'єднання середовищ, CE 4 = CE 1 Comp операції видалення середовища, Comp 2 – CE 2 = Comp 2 (CE 1 Comp 1) заміщення. Внутрішня алгебра: = { CSet, CESet, 2}, де 2 = {Оrefac, OReing , ORever } – сукупність операцій еволюції: Оrefac = {Add. OImp, Add. NImp, Repl. Imp, Add. Int} – рефакторінгу, Oreing= {rewrite, restruc, adop, supp, conver } – реінженерії, ORever= {visual, metric, restruc, design, rewrite} – реверсної інженерії.
Алгебраїчні системи перетворень: 1 = {G b, G c, G i, G r}, 2 = {G a, G z, G u, G e}, де G t =
Модель КПВ = (T, I, F, R, S), T – тип компонента, I – интерфейс компонента; F – функціональність; R – реалізація; S – сервіс взаємозв’язків з компонентами і середовищем; Компонентна модель КМ: КМ = {СLm{Lm 1, …, Lmn}, Р {Рi, …, Рm}, СLn {In 1 , …, Ink}, де СLm - компоненти з множини реалізації, Р - предикати з множини предикатів відповідають збиранню чи конфігурації КПВ в складні структури ПС чи СПС з використанням реалізацій компонентів СLm і інтерфейсів In, СLn – множина інтерфейсів компонентів. Члени множини компонентів С подаються у репозиторії різними мовами, іменами і інтерфейсами. Вони можуть змінюватися в моделі КМ новими компонентами з метою отримання різних варіантів продуктів ПС за аксіомами. Аксіома 5. Два компоненти C 1 та C 2 є тотожними (рівними), якщо тотожними є їх відповідні складові. Як наслідок, заміна C 1 на C 2 не впливає на компонентну модель, до якої належить компонент C 1. мова специфікації інтерфейсів КПВ (IDL, АРІ, OSWL, XML…); зборка компонентів і КПВ: інженерія застосувань, доменів, сімейств програм і систем; модель репозиторія для подання КПВ з різних предметних областей.
1. Модель сборки КПВ в ПС, СПС (описание интерфейсных типов данных в IDL, вызовов RPC, RMI). * Функции изменения ФТД к форматам КПВ другой среды, тестирование экспорта и импорта интерфейсных данных и др. * Алгебра преобразования типов данных (библиотека функций изоморфного отображения нерелевантных типов данных ЯП и отличий в форматах frameworks). * Межъязыковый и межмодульный интерфейс взаимосвязи ЯП и программ в классе ЯП (средства описания типов данных в ЯП, операций вызовов и др. ). * Система генерации модулей–посредников. 2. Модель сборки Common Language Runtime в. NET (описание компонентов, манифеста сборки и имен), разворачивание приложений, содержащих манифест. * Описание метаданных в манифесте (типов, свойств, методов, аргументов, атрибутов, базовых классов и т. п. ) и необходимых ресурсов. * Описание компонентов в VBasic, C++, C# для сборки (версия, варианты, типы и т. д. ). * Идентификация типов объектов ЯП в пространстве имен подобно типов данных. * Microsoft Intermediate Language (MSIL, IL) – компиляция семейства языков в IL или управляемый код для сборки…
interconect PS (A, B, C, Int. A, Int. B, Int. C) - взаємодія програм A, B, C за їх інтерфейсами Int. A, Int. B, Int. C; redevelop PS (Int. A, Int. B) – перебудова типів даних А, В; linkconfig SPS (Al 1, Bl 1, Cl 1 (Intidl. A, Intidl. B, Intidl. C) – зборка шляхом конфігурування програм A, B, C в одної МП L 1 і їх параметри в інтерфейсі подані мовою IDL; makeaway PS (A) – віддалити з системи PS програму А; add PS (A, C) – додати компоненти А, С до системи PS; insert F PS – вставити модуль F в систему PS; rename A B – змінити ім’я ; redoing x, y BD –передати дані x, y в БД за відповідним форматом.
Принцип перехода от ОМ к КМ (объекты преобразуются в компоненты и их интерфейсы) Принцип декомпозиции Пр. О на функции и программирование их компонентами. Принцип независимости и повторного использования. Принцип объединения (сборки) разнородных компонентов через их интерфейсы в программные структуры (СПС И СПС). Принцип наследования входных и выходных интерфейсов. Принцип распределенности
- Проектування КПВ і ПС - об’єктно-компонентний метод проектування (ОКМ), - Трансформаційний, конфігураційний генерувальний метод, - сервісно-орієнтований підхід. Технологія розробки ПС із КПВ: - ЖЦ, продуктовими лініями, ТЛ. - Графічними мовами DSL, Work. Flow, Use case, UML 2. - конструювання СПС із КПВ, assets. - Технологія взаємодії, варіабельності ПС і СПС. - Технологія навчання прийомам виробництва ПС.
Компоненты повторного использования (КПИ); Репозиторий КПИ і онтологии доменів ЖЦ і Обчислювальної геометрії; Компонентная алгебра сборки КПИ; Системи перетворення GDT↔ FDT; Моделі программної системи, сімейства систем; Модель варіантної ПС і СПС; Модель якісної ПС і СПС; Модель взаємодії і варіабельності ПС, СПС; Методи індустрії ПС і СПС із КПВ; Монография 2 издание «Сборочное программирование’; Инструментально-технологический комплекс (ИТК) изготовления ПС і СПС из КПИ.
Технологія ОКМ – це метод проектування об’єктної моделі (ОМ) із об’єктів і реалізації їх функцій програмними компонентами в КП. ОКМ включаєт: - об’єктна і компонентна алгебри метода ОКМ з операціями проектування різнорідних КПВ (reuses, assets, servises), - операції збирання і перетворювання даних до різних форматів сучасних середовищ (VS. Net, IBM, Corba, Eclipse тощо) за допомогою нових згенерованих примітивних функції GDT стандарту ISO/IEC 11404– 2007 до FDT МП (і зворотно), - зменшення обсягу робіт з виробництва систем сімейства СПС за рахунок готових КПВ, операцій компонентної алгебри та системи трансформації GDT FDT.
готовые программные компоненты (артефакты, программы, системы, reuses, assets, КПИ и т. п. ); интерфейс, как спецификатор паспортных данных готовых разнородных ресурсов, независимо от языка программирования, в языке спецификации интерфейса (IDL, API, SIDL, WSDL, RAS и т. п. ); операционная среда, содержащая системные программные средства и инструменты для поддержки сборки (интеграции) разнородных ресурсов; ТЛ, продуктовые линии (Product Lines) производства ПП; метод разработки (сборка, композиция КПИ, UML, DSL и др. ); сборочный конвейер (конфигурация, комплекс, семейство, пакет).
1. Sun Microsytems (Remote Procedure Call – RPC, RMI Java, описание удаленных ТД в RPC, операции для клиента (clnt) и сервера (replay), RPC-библиотека) 2. Component Object Model (COM) – стандарт Microsoft для компонентов включает протокол конкретизации и использования компонентов внутри процесса, между процессами или между компьютерами. Active. X, OLE обеспечивают взаемосвязь в языках Visual Basic, C++, C#, . NET и др. 3. Java Beans – стандарт Sun Microsystems для компонентов (зависимый от языка). 4. CORBA (IDL-интерфейс для связи КПВ в языках программирования (ЯП), сложность отображения одного ЯП реализации в другой, проблемы преобразования типов данных ). 5. Microsoft Visual Studio. NET - среда разработки, среда выполнения Common Language Runtime (CLR), cреда выполнения как CLR реализация ТД, межъязыкового взаимодействия и разворачивания (deployment) компонентов. 6. IBM, VSphere IBM – сервисная компонентная архитектура (SCA) с интерфейсом в WSDL для импорта и экспорта данных (EJBs), интеграция и упаковка компонентов в сервисный модуль типа файлу J 2 EE. 7. OBERON компонетная обработка на многих ЯП, подобно Corba на коммерческой основе.
Моделі КП (моделі компонента, інтерфейсу, компонентного середовища, зміни, еволюції). Моделі зборки, конфигурування, трансформації, генерації і др. Моделі взаємодії програм і ПС в гетерогенних середовищах. Моделі варіантності компонентів, програм, ПС і СПС. Моделі якості компонентів, програм, ПС і СПС. Модели разработки (MDD, MDA, SOA, PIM, PSM, GDM тощо). Модели стандарта 12207 ЖЦ (спиральная, водоспадная, ТЛ, Product Line) для производства ПП; Фундаментальні типи даних (ФДТ) PL, якими обмінюються різнорідні КПВ (reuses, assets, servises, artifacts…) між собою; Алгебраїчні системи перетворення даних до різних форматів сучасних середовищ (VS. Net, IBM, Corba, Eclipse, Grid…); Генерація ФДТ GDT ISO/IEC 11404– 2007. Об’єктна і компонентна алгебри збирання різнорідних КПВ.
Технологія зборки компонентів в MS. Net
3. Генераційна технологія (трансформація, конфігурація, генерація – К. Чернецки)
1. Парадигмы программирования (ООП, КП, Сервисное, Аспектное, Композиционное, Функциональное, Ментальное, Генерирующее и др. ). 2. Мультиязыки (C/C++, C#, LAVA, Pascal, Ada, Basic, Script, Clear, Ruby, . . . ), XML, UML, RDF. . . , GDT. 3. Сложные системы – СПС, Applications, Domains, Family Systems. . 4. Готовые КПИ, ГОР. 5. Средства взаимодействия – интерфейс (IDL, APL, SDL, …, протоколы, вызовы, сообщения. . . 6. Модели разработки ПС (MDA, MDD, PIM, PSM, GDM, DSML, FМ. . . ). 7. Методы генерации, трансформации, конфигурации, интеграции.
Базові завдання 1. Методологія та технологія складального конвеєра об'єктів, компонентів, КПВ; 2. Об'єктно-компонентний метод – ОКМ: Теорія зборки та перебудови не релевантних типів даних, компонентна алгебра); 3. Розробка теорії інтероперабельності (інтерфейсу взаємодії програм, ПС, СПС), варіабельності (змінності варіантів ПС), життєдіяльності (безвідмовності та живучості ПС); 4. Забезпечення якості компонентів на процесах створення СПС 5. Обслуговування компонентів і КПВ у репозиторію; 6. Використання конфігураційного методу реалізації моделі GDM; 7. Розроблення інтегрованого середовища для виконання ТЛ і Рroduct Lines Додаткові завдання 1. Генерація типів даних GDT FDT для гетерогенних середовищ; 2. Розробка онтології домену ЖЦ стандарту ISO/IEC 12207, обчисл. геометрії. 3. Технологія навчання мовам програмування C #, Java та засадам SE; 4. Створення методології побудови ТЛ для індустріального виробництва ПП. 5. Створення фабрики програм в КНУ студентами.
включає формальний апарат інтерфейсу систем та механізмів обробки гетерогенних даних мережі для забезпечення інтероперабельності, міграції систем із одного середовища в інше, розширюючи межі виконання завдань з обчислення даних. Модель взаємодії є моделлю верхнього рівня моделі OSI має вигляд: Мвз = {Мпр, Мсис, Мсеред}, де Мпр = {Com, Int, Pro} – модель програми, Мсис = {FPC, Int, Pro} – модель системи, Мсеред = {Envir, Int, Pro} – модель середовища, Реалізовані такі моделі у середовищі ІТК: Visual Studio Eclipse CORBA Visual Studio ІВМ Eclipse
Модель варіабельності Mvar = SV; AV , де SV – підмодель варіантної структури СПС; AV – підмодель варіабельності продуктів процесу розроблення СПС. Модель Mvar процесу розроблення СПС забезпечує: * постійне підвищення рівня відповідності кінцевих продуктів СПС; * забезпечення рівня змінності продуктів СПС, адекватного умовам; * зниження витрат та скорочення термінів розроблення продуктів СПС. Підмодель варіантності структури СПС: SV = G 1; Gt, TRt ; Con; Dep , де Gt = Ft, LFt ) – граф, вершини якого є унікальні ідентифікатори артефактів типу t потреб, t=1; вимог, t=2; компонентів архітектури, t=3; ПС, компонентів, тестів, t=4; таблиць БД, t=5 , поєднані зв’язками обов’язкового та варіантного підпорядкування; TRt – двосторонні зв’язки артефактів типу t поданих вершинами Ft артефактами типу t-1, для реалізації яких призначені артефакти типу Con і Dep – предикати на декартовому добутку множин артефактів, які подають обмеження й залежності між функціями та показниками якості СПС. Підготовлено до захисту дисертація аспіранта Колесник А. Л.
Управління варіантами в структурі СПС Формування набору ПС для Пр. О; виділення загальних і варіантних характеристик ПС. Побудова моделі характеристик FM і GDM; * розробка КПИ і накопичення у базі конфігурації; планування багатократного використання КПИ для членів СПС в точках варіантів; реалізація моделі варіабельної з артефактів і КПИ; конфігурація КПИ в СПС та їх адаптація до нових умов середовища функціонування; керування варіантами і замінами функцій в СПС.
- обґрунтування задач розроблення якісних членів сімейств ПС на процесі визначення вимог; - інженерія якісних ПС із КПВ за базовим ЖЦ; - генерація СПС із ПС і КПВ за показниками якості, щодо конструювання структури СПС; - оцінювання показників якості КПВ, ПС на процесах ЖЦ. Модель якості компонентів і ПС Мяк = {Q, A, M, W}, де Q = {q 1, q 2, …, qi }i = 1, , 6 – множина характеристик якості (Quality – Q); A ={a 1, a 2, …, aj}j=1 J – множина атрибутів (Attributes – A) для qi; M = {m 1, m 2, …, mk}k=1, , K – множина метрик (Metrics – M)для кожного aj ; W = {w 1, w 2, …, wn}n=1, N – множина коефіцієнтів ваги (Weights – W) для mi. Оцінювання показників якості ПС за моделлю 6 q 1 = a 1 j m 1 j w 1 j j=1
. http: //sestudy. edu-ua. net (укр. , рос. , анг. ). http: //programsfactory. univ. kiev. ua www. intuit. ru * http: //ceur-ws. org/Vol-848/ICTERI-2012, http: //ceur-ws. org/Vol-1000/ICTERI-2013 .
1. Программные средства поддержки ІТК линий разработки КПИ и СПС, взаимодействия ПС и сред, конфигурации вариантов СПС из КПИ, генерации данных; Eclipse и Protégé, как інтрументи связи КПИ и построения онтологий; сборки и интеграции КПИ; оценки качества ПП, электронного обучения программированию в языках C#, Java, SE. 2. Инструментальные средства общего назначения загальносистемні засоби (Corba, JAVA, VS. Net, IBM, Protege, Eclipse, MCF й Tools DSL MS. Net тощо); засоби спеціального призначення (Eclipse, Protégé) для моделювання моделей предметних областей та додавання КПВ до репозиторію; системи програмування з МП Visual Basic, C++, Java та мови в межах VS. Net (C#, F#, C++ , Visual Basic), системи CORBA (C++, C, Lisp, Smalltalk, Java, Pascal, PL/1, Python) та Java/RMI; засоби з підтримки мови DSL (Tools DSL VS. Net, Eclipse-DSL, Work Flow); засоби тестування й оцінювання програм і КПВ; СУБД MS. Net для підтримки репозиторию КПВ і інтерфейсів.
ТЕХНОЛОГИИ ИТК: Технология обслуживания репозиторию КПИ, Технология разработки КПИ, Технология сборки КПИ, Технология конфигурирования КПИ, Технология генерации описания КПИ в языке DSL, Технология оценка затрат и качества, Технология онтологии вычислит. геометрии, ЖЦ ISO/IEC 12207 Технология веб–сервисов, Технология генерация типов данных ISO/IEC 11404. ВЗАИМОДЕЙСТВИЕ программ, систем и сред: Модель Corba–Eclipse–Java, Модель VS. Net C#–Eclipse, Модель Basic–C++. ІНСТРУМЕНТЫ ИТК: Система Eclipse, Система Protégé ПРЕЗЕНТАЦИИ В ИТК: Система ведения зарубежных командировок для НАНУ, Слайды про ИТК, фабрики программ Методологии построения ТЛ ОБУЧЕНИЕ: технологии разработки программ в С# VS. Net, языка Java, электронного учебника с предмета «Программная инженерия» веб-сайту КНУ http: //programsfactory. univ. kiev. ua.
Компонентна розробка ПС на веб-сайті
* Програмна інженерія * Технології і навчання * Мова: укр. • рус. • eng. * Ви зараз знаходитесь у: Технології » Онтології 3. Онтологія доменів * Термін онтологія, як метафізичний, виник ще в 1613 р. В Computer Science під онтологією розуміється специфікація концептуальних знань про деяку предметну область, тобто опис множини об’єктів і зв’язків між ними. Формально онтологія містить поняття, організовані в таксономію їх описів і правил виводу. Концептуальна модель онтології O =
Схема онтології обчислювальної геометрії має такий вигляд: Класи задач * Статичні задачі. * Динамічні задачі. * Задачі геометричного пошуку. * Варіації задач. Домен «Обчислювальна геометрія» подається в графічному вигляді засобами системи Protégé 4. 2 Protégé підтримує два основних способи моделювання онтологій за допомогою редакторів Protégé-Frames і Protégé-OWL. Онтології, побудовані в Protégé, можуть бути експортовані в безліч форматів, включаючи RDF (RDF Schema), OWL і XML Schema. Protégé має відкриту, легко розширювану архітектуру за рахунок підтримки модулів розширення функціональності.
Структура головних процесів Структура головних
Структура процесів керування ЖЦ в DSL
* Ви зараз знаходитесь у: Технології » Генерація DSL ЖЦ » Приклад * Назва файлу: __init__. rar * Розмір: 259. 69 Кб * Дата модифікації: Tue Jan 17 13: 38: 14 2012 * Опис: Тестування програми шляхом порівняння з еталоном. Для запуску необхідно розпакувати зміст архіву у будь-яку директорію та запустити на виконання файл __init__. py (на комп'ютері має бути встановлене середовище Python). * Завантажити
Результат тестування програм * Програма тестування КПВ у мові Ruby на веб-сайті
* 5. Генерація загальних типів даних GDT-FDT
* * * * * * * // create the zero vector of length N public Vector(int N) { this. N = N; this. data = new double[N]; } // create a vector from an array public Vector(double[] data) { N = data. length; // defensive copy so that client can't alter our copy of data[] this. data = new double[N]; for (int i = 0; i < N; i++) this. data[i] = data[i]; } public int length() { return N; } // return the inner product of this Vector a and b public double dot(Vector that) { if (this. N != that. N) throw new Runtime. Exception("Dimensions don't agree"); double sum = 0. 0; for (int i = 0; i < N; i++) sum = sum + (this. data[i] * that. data[i]); return sum; }
* * * Testing complex numbers a = 5. 0 + 6. 0 i b = -2. 000000004 + 2. 999999996 i c = -27. 99999996 + 2. 9999999876 i Testing composites Some doc 2 Testing maps You asked about O'Reilly. They are located in: Sebastopol, CA * * * * * Key Adobe; Value Mountain View, CA Key IBM; Value White Plains, NY Key Learning Tree; Value Los Angeles, CA Key Microsoft; Value Redmond, WA Key Netscape; Value Mountain View, CA Key O'Reilly; Value Sebastopol, CA Key Sun; Value Mountain View, CA entry. Set() returns 7 Map. Entry's Testing queues * Звернення до Веб-сайту для генерування комплексних чисел
Веб-сервиси Веб-сервіс — програмна система, що ідентифікується рядком URI, властивості та методи котрої описані за допомогою спеціальної мови WSDL. Доступ до ресурсів такої системи здійснюється через протокол SOAP, який представляється XML-запитами, що передаються за допомогою Інтернет-протоколу (HTTP). Веб-сервіси близькі класам об’єктно-орієнтованих МП (Java EE). Ключове поняття веб-сервісу є повідомлення з однієї чи кількох змінних. Методи класів задаються операціями з вхідним і вихідним значеннями повідомлень. Після виклику операції змінні вхідного повідомлення протоколу SOAP, інтерпретуються як параметри відповідного методу класу, який лежить в основі сервісу. Після завершення роботи методу формується вихідне повідомлення, що містить повернуте методом значення, яке відправляється клієнту протоколом SOAP. Така архітектура сервісу дозволяє викликати методи асинхронно. Зміст розділу сайту Опис принципів роботи веб-сервісів Приклад роботи з веб-сервісами Інструкція по роботі з прикладом Сторінка доступу до локального веб-сервісу
* Ви зараз знаходитесь у: Технології » Веб- сервіси » Приклад * Назва файлу: webservices. zip. Розмір: 2243. 88 Кб. Дата модифікації: Fri Nov 11 20: 14: 08 2011 Опис: * Програма з графічним інтерфейсом, яка використовує простий веб-сервіс з додавання і віднімання цілих чисел. Для запуску розпакуйте зміст архіву у будь-яку директорію і запустіть на виконання файл WSLoader. jar. На машині має бути встановлено сервер програм Glass. Fish (його можна безкоштовно завантажити на сайті Oracle). Для більш детального опису програми див. інструкцію з використання. * Завантажити
* Виконання прикладу на сайті
* Перспективи: Using ISO/IEC 11404 for Semantics
ФАБРИКА ПРОГРАМ КНУ http: //programsfactory. univ. kiev. ua Фабрику розроблено за відчизняною методологією ТЛ с участием студентов кафедри ІС факультету кібернетики КНУ Аронова А. і Дзубенко А. Фабрика забеспечує розробку і збереження різних артефактов фундаментальних аспектів навчальних теорій з математики, информатики, Computer Sciences, Software Engineering, Information Systems, Information Technologies та представлення їх у вигляді програм, КПВ і сімейств програм. Фабрику подано наступними ТЛ: * Общая линия проектирования программ в MS. NET * Примеры студенческих программ и артефактов * Сертификация КПВ для репозитория * Конвейерная сборка.
Результати теоретичних та прикладних робіт є значним і вагомим вкладом в технологію програмування і програмну інженерію у напряму: нові та обґрунтовані моделі взаємодії, варіабельності та життєздатності для використання в Grid і Cloud Computing; класифікація дисциплін програмної інженерії, відсутній раніше і признаної спеціалістами за кордоном; розвиток ідей академіка Глушкова щодо методів виготовлення ПП за інтерфейсом по ТЛ, як базісу зборочного програмування, подані двома веб-сайтами для застосування в Україні і за кордоном. http: //sestudy. edu-ua. net, http: //programsfactory. univ. kiev. ua Впровадження. Новітні наробки ІПС НАНУ проходять апробацію на курсах лекцій студентам Тараса Шевченко КНУ та МФТІ по Технології програмування та Програмної інженерії. Студенти активно їх вивчають, розвивають і виконують дипломні та магістерські роботи (за 5 років біля 20). 3 доповіді на міжнародних конференціях ICTERI-2012, 2013 (анг. ), Опубліковано базові ідеї ПІ за кордоном в 4 статтях Лавріщевої К. М. ж. Springer (2008 -2011) та у відчизнянних статтях співробітників – біля 50 (2007 -2012).
Публікації - електронна монографія «Нові теоретичні і прикладні засади технології виробництва сімейств програмних систем у контексті ГП”. ДНТІ України і ВІНІТІ Росії, 2012. -Реф. Журнали. - 3 монографії (Наукова думка – “Методы программирования. Теория, инженерия, практика -2007, Академперіодика – “Основы инженерии качества программных систем» -2007, Наукова думка“Сборочное программирование. Основы индустрии программных продуктов» -2009); - 2 підручника з програмної інженерії (видав. Мін. освіти і науки РАН “Методы и средства программной инженерии” – 2007 та Академперіодика – Програмна інженерія - 2008); - 55 наукових статей співробітників відділу “Програмна інженерія”; - 10 статей в закордонних журналах http: //Springerlink. com/ - 26 доповідей (4 на семінарах кафедр КНУ ім. Тараса Шевченко, 7 на міжвузівських науково-практичних конференціях МНТУ (20092011), 6 на міжнародних конференціях КНУ Theoretical and Applied Aspects of Cybernetics, 2 - на міжнародному науковому конгресі при Каб. Мін. України 17 -18 листопада 2011, 5 доповідях на Укр. Пр. O (20062010), 2 на ICTERI-2012 і ICTERI-2013.
Напрями роботи по теме Семантик –Web: (2012 -2016) “Розробка теоретичних основ та прикладних питань побудови сервісноорієнтованих прикладних програмних систем у семантичному середовищі» Сервісне-орієнтоване програмування
Напрями робот по проекту веб-семантик Уточнення понять Пр. О, ПС, СПС для розподілених по мережі ресурсів і прикладних систем РПС і в семантичному вебі; Розроблення моделей Пр. О, ПС, СПС і РПС із готових ресурсів (об'єктів, компонентів, артефактів, сервісів) з орієнтацією на веб; Аналіз сучасних засобів підтримки готових ресурсів щодо вебу; Обґрунтування моделей взаємодії і варіабельності для РПС; Розроблення методології побудови ТЛ РПС з готових ресурсів і анотування процесів ТЛ мовою BPMN; Розроблення онтології стандарту ISO/IEC 12207 ЖЦ і семантики його процесів, як шлях автоматизованої генерації ЖЦ варіантів РПС; Вивчення засобів нотацій мови BPMN з метою опису процесу тестування ЖЦ і генерування варіантів ПС в структури РПС.
Типизація сервісів: • системні сервіси, що є у кожному загальносистемному середовищі проектування, реалізації та керування ПС і РПС (MS. Net, IBM, Intel…); • об’єктні сервіси, що підтримують об’єкти, класи, операції ЖЦ ООП для розробки РПС у об’єктному середовищі (Corba, RRoses…); • веб-сервіси чи інформаційні ресурси Інтернет для пошуку, композиції, інтеграції КПВ і сервісів для функціонування у всемірної павутині. Властивості сервісів: 1. Іменування (Naming)для їх накопичення і пошуку у просторів імен в розподіленому середовищі Інтернет. 2. Зв'язування (Binding) для встановлення відповідності “ім'яоб'єкт” і зв’язків між знайденими сервісами. 3. Транзакції (Transaction) для організації та управління сукупністю компонентів сервісу. 4. Повідомлення (Messaging) для організації спілкування між компонентами у моделі асинхронних транзакцій.
Принципи розробки РПС: - функціональність ГОР (компонентів, сервісів, інтерфейсів, даних, артефактів тощо); – компонентність - властивість побудови РПС з готових типізованих, класифікованих і каталогізованих «деталей» за композиційним принципом; - композиційність компонентів, сервісів та інтерфейсів у РПС за їх властивостями, характеристиками та правилами об’єднання для виконання в гетерогенних середовищах; – інтероперабельність – здатність ГОР і інших елементів РПС взаємодіяти між собою через інтерфейси в умовах адаптації у різні гетерогенні середовища; – варіантність - здатність ГОР і компонентних ПС до змін шляхом завдання схем варіантів (конфігурацій) з додаванням нових функціональних ГОР в структуру РПС.
Transparency: The replacement of a service implementation has to be transparent for the depending services and applications. No extra code should be included into the implementation of a service to handle the replacement of its dependencies. But it is justifiable that a component implements special methods to consider the replacement of itself. • Atomicity: Changing a service implementation must be uninterrupted and therefore an atomic operation. Other services or application are not allowed to see any intermediate states. Accessing an intermediate state may also result in unpredictable side effects. Solely changing the entry in the service registry can result in race conditions. Depending services may hold references to different implementation sat the same point in time, which may cause indeterministic behaviour. • State preservation: Attributes of the service may have a specific value at the moment of change. This state of the service has to be transferred to the new implementation. Therefore the state of the old version of the underlying component has to be saved and injected into the new version. • Lifecycle management: The whole adaptation process has to be coordinated by the environment. A Lifecycle management has to control the process: Saving the state of the old version, replacing the old version by the new one and restoring the state. The Life cycle management must also ensure the atomic execution of the whole process.
Модель сервісів РПС - набір уніфікованих і сумісних сервісів з принципами функціональності, взаємодії і варіантності. Вона створюється на основі об'єктно-компонентної моделі і інтерфейсів. Для подання - функціональності сервісів використовуються сучасні мови, онтології (моделі і словники), - взаємодії механізми SOAP, SCA та експорту і імпорту даних, - варіантності конфігураційні, уніфіковані комунікаційні протоколи, компонентні моделі. Модель сервісу забезпечує: – розширення функціональності шляхом пошуку і залучення нових сервісів; – поліпшення комунікацій через їхні інтерфейси; - підвищення мовного рівня комунікації системи РПС з кінцевими користувачами.
Конструктивний аналіз існуючих підходів, моделей і методів подання знань Пр. О з метою розгляду їх рівня і змісту. 1. Запропоновані формальні моделі ПС і їх сімейств СПС для їх використання у розподіленому середовищі. - згідно ОКМ будується об'єктна модель ОМ = {O, I }, яка трансформуються у модель КМ = {K, I, Ke, Ie, Md}. - Мпс = {L, Mf, Ms, Mi, Md}, де L = {L 1, L 2, …, Lk) – мова опису функцій ОМ; Mf = {O 1, O 2, …, Or} – множина функцій (методів); Mi = {Min, Mout, Minout} – множина інтерфейсів з описом in, out та inout параметрів для кожної пари зв’язних компонентів ПС; Ms = {Msin, Msout, …, Msinout} – множина сервісів (Common Facility Services) з передачі вхідних, вихідних та серверних даних; Md – множина даних та метаданих (типів FDT, GDT) ПС, що подаються в модулях посередниках типу stub, skeleton мовою IDL. Мпс поповнено моделями інтероперабельності Mint і варіабельності Mvar для розподіленого функціонування РПС і змінювання її елементів в конфігураційній структурі ПС, як нових варіантів продукту. Деякі моделі і операції їх реалізацій подані на сайті ІТК ІПС НАНУ (http: //sestudy. edu-ua/com).
*Результати етапу з побудови моделі розподіленої ПС
Модель СПС - це сукупність моделей ПС: Мспс = {{Мпс1, Мпс2, …, Мпсk }, {Mgf, Msf ={Msf 1, Msf 2, …, Msfk}, Mi, Мd}, де Мпс1, Мпс2 , …, Мпсk – множина членів сімейства ПС; Mgf – множина зовнішніх характеристик Пр. О чи властивостей загального типу, що визначають загальну термінологію та властивості усіх ПС сімейства; Msf ={Msf 1, Msf 2, …, Msfr} – множина внутрішніх характеристик кожного окремого члена cімейства, поданого моделлю ПС (Мпсi ) - Msf 1 для Мпс1 , …, Msfr для Мпсk; Mi – множина загальних інтерфейсів СПС, що подаються мовою IDL; Minc – модель взаємозв’язку ПС через елементи множини Mi; Мd = {Мd 1, Мd 2, …, Мdk} – множина даних, що відображають дані кожного члена ПС. Протоколи типа RPC, RMI, Icontract передають моделі Minc у IDL чи API через інтерфейсний посередник від одного компонента ПС чи СПС до іншого. Ці моделі трансформуються до реалізаційної моделі ПС, СПС. *
2. Для РПС з використанням сервісних ресурсів (РПС_СР), запропоновано об’єктно-сервісно-компонентну конструктивізацію традиційної моделі властивостей СПП і методу ОКМ у вигляді моделі РПС_СР як спеціального сімейства продуктів. Ця модель зв’язує об’єктне подання РПС_СС та її сервіснокомпонентну архітектуру засобами діаграм потоків робіт (workflow) і бізнес-процесу використання РПС_СС (мовою BPMN). 3. Об’єктна та сервісно-компонентна підмоделі запропонованої моделі за допомогою базових операцій об’єднання, перетину та доповнення множин їх елементів визначаються бульовими решітками з одиницею – повним об’єднанням всіх елементів та нулем – порожнім елементом. Доведено, що відображення між ними є ізоморфізмом решіток з унарним відношенням припустимості підмножини складних властивостей (відповідно, сервісів для них) в окремих варіантах РПС_СР.
4. Запропоновано об’єктно-компонентну модель завдання артефактів Сімейства СПП – від вимог до коду продукту – як підграфів моделі ОРС_СР, пов’язаних її підмоделями. Надано композиції базових операцій над моделями для створення СПП із заданими властивостями та рефакторингу компонентів, як механізмів зміні вимог чи умов використання. 5. Напрями подальших досліджень: - аналіз завдання інтеграції запропонованої моделі з використанням мов BPEL і BPEL 4 WS; - відображення у моделі СПС показників до якості РПС_СР; - створення технології композиції локальних та Веб-сервісів; - поглиблений аналіз можливостей сучасних продуктів IBM Mashup Center та Web. Sphere Business Services Fabric, для автоматизованого розроблення РПС_СР. Mashup Center призначений для побудови mashup – веб застосунків шляхом інтеграції інформації з різних розподілених джерел. Web. Sphere Business Services Fabric як засоби реалізації РПС з модульних, динамічно компонованих та поширюваних бізнес-процесів. *
Д ЯКУЮ ЗА УВАГУ !