ПроектнийПрактикум / ПрофесійнаПрактика / Разное / lavrishcheva-6

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

Кожний член сімейства повинен мати відображення своєї специфіки на мові високого рівня – DSL (Domain Specific Language), яка зараз широко використовується розробниками ПрО. На загальному рівні ця мова складається з трьох частин:

–метамодель, що відображає абстрактно синтаксис при визначенні специфіки ПрО і правила опису специфіки ПрО, необхідної для розробки моделі генерації GMD (Generative Model Development);

–конкретного синтаксису МП для опису нотацій моделі GMD та інших моделей ПрО;

–семантичного опису змісту всіх моделей.

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

8.2.1. Прикладна інженерія

Інженерія застосувань (applications), або прикладна інженерія, входить до інженерії ПрО, як складова її частина. Сутність цієї інженерії полягає у виробництві окремих членів сімейства або нових КПВ, багаторазово використовуваних проектних рішень при генерації окремих членів сімейства систем.

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

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

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

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

2.Розроблення вимог (Requirements) до ПС, тобто – це формування й опис функціональних, нефункціональних і інших властивостей ПС.

3.Аналіз поведінки (Behavioral Analysis) ПС – визначення функцій системи, деталей проектування і методів реалізації функції, кожний з яких має відповідну поведінку.

4.Специфікація інтерфейсів і взаємодій компонентів (Interface and Interaction Specification) відбиває розподіл ролей компонентів, інтерфейсів, їхню ідентифікацію і взаємодію через робочі потоки (workflow).

5.Збирання застосувань і повторне використання компонентів (Application Assembly and Component Reuse) ґрунтується на підборі й адаптації КПВ, визначенні сукупності правил, умов інтеграції і побудові конфігурації каркаса системи.

6.Тестування компонентів і середовища (Component Testing) ґрунтується на методах верифікації і тестування для перевірки правильності як окремих компонентів і КПВ, так і інтегрованої з компонентів ПС.

7.Розгортка (System Deployment) містить у собі оптимізацію плану компонентної конфігурації з урахуванням середовища, розгортання окремих компонентів і створення цільової компонентної конфігурації для функціонування ПС.

8.Супровід ПС (System Support and Maintenance) складається з аналізу помилок і відмов при функціонуванні ПС, пошуку і виправленні помилок, повторного його тестування й адаптації нових компонентів до вимог і умов інтегрованого середовища.

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

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

8.2.2. Інженерія сімейства систем домена

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

Інженерія ПрО базується на різних видах мови опису специфіки предметної області в мові DSL [4, 6, 13].

Мова DSL має виразну особливість, спрямовану на відображення специфіки предметної області. Тоді як мови загального призначення (Java, C++ і ін.) створювалися для задоволення будь-якого типу програм. Мова DSL не є новим винаходом, оскільки в неї були вбудовані загальні абстракції програмування. І хоча мова DSL створюється багато років для кожних нових ПрО, систематичне її

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

Будь-яка мова має свою визначену область застосування, мова DSL є більш

спеціалізованих мов, таких, як HTML, XML.

Характеристика мови DSL для опису специфіки ПрО. Прівнянно з мовами загального призначення ця мова має [6]:

– абстракції, які забезпечують визначення концепцій і абстрактних понять із предметної області;

– синтаксис, призначений для природного представлення понять домену і запобігання синтаксичній неузгодженості понять ПрО;

–опис в DSL вимагає наявності спеціалізованих статичних аналізаторів для перевірки синтаксису, щоб знайти помилки в описі специфікації моделі, і подати з них відомості уією мовою;

–оптимізація коду за описом в DSL базується на знаннях про цю область і це не доступно компіляторам МП загального призначення;

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

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

Специфікована в DSL модель ПрО є загальною моделлю генерації домену GDM, що відбиває:

– поняття, характеристики ПрО і членів сімейства в просторі проблем;

– набір членів сімейства і їхніх специфікацій у мовах типу DSL, RSL, CSP і

ін.;

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

–знання про конфігурацію (Configuration knowledge) відбивають характеристики членів сімейства і їхнє об’єднання в конфігурації;

–модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства, а також правила конструювання систем сімейства з урахуванням їхніх взаємозв’язків і залежності від КПВ;

–архітектуру (каркас) сімейства систем;

–реалізацію компонентів архітектури у мовах програмування.

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

Головною частиною моделі ПрО є моделі характеристик, що призначені для подання вимог до сімейств ПС, різних характеристик систем, що входять до складу ПрО та застосування КПВ. Ці моделі поділені на дві категорії [6]:

– моделі характеристик FODA (Feature-oriented Development Architecture), FORM (Feature-oriented Reuse Method), RSEB (Reuse-Driven Software Engineering Business), FeatureRSEB (з інтеграцією у RSEB–діаграм характеристик з FODAcom) тощо [13],

–моделі варіантів сценаріїв використання (Use Case Variants) [14].

У першу категорію потрапляють традиційні методології моделювання, використовувані при побудові ПС, у другу – методології, засновані на аналізі сценаріїв діяльності потенційних користувачів ПС у ПрО, що будуються за допомогою UML (Sequence diagrams та Activity diagrams).

Про трансформацію DSL опису моделей ПрО. Як було сказано раніше,

модель предметної області Мпро є загальною моделлю GDM домену, який складається з декількох моделей окремих прикладних систем Мпро1, Мпро2, ..., МпроN.

Кожна з цих моделей відображає поняття і специфіку відповідної системи із сімейства систем домену. На їхньому перетині існують загальні поняття, характеристики і обмеження, які відображаються у моделі характеристик ПрО. Опис кожної моделі Мпроi виконується відповідною проблемно-орієнтованою DSLi мовою. Цей опис трансформується безпосередньо у відповідну МПi, тобто мову реалізації (рис.8.3), або у іншу DSLj мову, яка потім трансформується у МП.

Рис. 8.3. Схема трансформація моделей прикладних систем

Після трансформації опис моделей Мпро1, Мпро2, ..., МпроN, що отриманий у

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

PIM (Platform Independent Model) і платформа залежного рівня за моделлю PSM (Platform Specific Models). Концепції дворівневого моделювання архітектури MDA (Model Driven Architecture) і відображення PIM→PSM безпосередньо відповідають наведеній ідеології побудови сімейства ПрО, які базуються на відображенні опису Мпроi моделей прикладних систем (Application model) у DSL-мовах у МП (рис.8.4).

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

Рис.8.4. Схема трансформації прикладної моделі до платформи

Вибору альтернативної платформи відповідає точка варіантності у сімействі систем. Ця точка невидима на рівні конкретної ПС і при керуванні варіантами платформ з ней почінається автоматично виконання шляхом трансформації PIM→PSM, розробник не бере участі в цьому.

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

Моделювання архітектури сімейства за характеристиками. Моделювання архітектури сімейства виконується за підходом, орієнтованим на характеристики (feature-oriented approach) її членів. Архітектура сімейства систем містить у собі окремі члени і «успадковує» еталонну архітектуру у просторі рішень (реалізації) генерувального програмування. Ця архітектура формується у просторі проблем таким чином, щоб різні комбінації характеристик цієї архітектури могли бути застосовані як компоненти реалізації простору рішень та і у кінцевому програмному продукту сімейства. Архітектура сімейства може бути подана у вигляді генерувальної предметно-орієнтованої мови зразка, яка визначає архітектурний стиль ПС сімейства за інваріантами систем, механізмами мінливості та еволюційного її розвитку через подання комбінацій відповідних шаблонів проектування цієї архітектури.

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

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

226 Розділ 8

Рис.8.5. Схема побудови моделі характеристик ПрО

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

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

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

Методологія розробки домену. На основі мови DSL створено методологію розробки домену MDD, що базується на генеративної моделі домену GDM (Generative Domain Model), яка специфікується [7]. Методологія містить у собі:

–модельно-керовану архітектуру MDA, що використовує мову моделювання UML для подання архітектури системи і її конкретні профілі для різних платформ;

–модельно-інтегровану обробку MIC (Model-Integrated Computing) для реалізації елементів системи і їхніх зв'язків за допомогою засобів предметно-

орієнтованої мови моделювання DSML (Domain-Specific Modeling Language) і

перетворення цього опису у платформозалежні артефакти. Архітектура MIC поєднує:

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

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

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

Технологія розробки сімейства програм вміщує три види базових процесів:

–розробка ПрО з унікальних, одиночних програм і інших компонентів;

–інженерія повторного використання програмних ресурсів;

–менеджмент домену.

Розробка ПрО належить до конвеєрної з повторним використанням компонентів. Для ПрО планується створення базових ресурсів, що можуть повторно використовуватися: компоненти, генератори, DSL-описи, моделі аналізу, КПВ, документація й ін. Розробка предметної області – це більш складний виробничий процес, що містить у собі такі загальні етапи: аналіз, проектування і впровадження в ПрО одиночних програм або КПВ.

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

Інженерія повторного використання – це пошук і аналіз КПВ для їхнього повторного використання під час розв’язання задач ПрО. Вони відображаються в загальній архітектурі сімейства і в архітектурі всіх членів (тобто прикладних

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

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

Таким чином, інженерія ПрО складається з таких процесів:

–аналіз ПрО, виявлення об'єктів і зв’язків між ними;

–визначення області дій об'єктів ПрО;

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

– створення базису для інженерії виробництва конкретних прикладних членів сімейства з механізмами змінювання незалежно від засобів їхньої реалізації;

–підбір і підготовка компонентів багаторазового застосування для різних задач ПрО;

–генерація окремих членів сімейства або домену в цілому.

Процеси в цій схемі забезпечують формування моделі ПрО і моделі характеристики, як елементів простору проблем. Вони трансформуються в архітектуру системи й опис її компонентів. При цьому проводиться підбір готових компонентів і їхня генерація для одержання програм, що розв’язують задачі ПрО у просторі задач. Таким чином, дана схема приводить до генерації доменної моделі GMD для сімейства ПС і породженню готових підсистем або окремих членів сімейства [4].

Для забезпечення гнучкості і змінюваності деяких членів сімейства технологічна схема інженерії ПрО може мати додаткові етапи:

–коректування процесів виробництва в зв'язку з включенням у систему нових проектних рішень або при зміні складу КПВ;

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

–розроблення інфраструктури КПВ – опис, збереження, пошук, оцінювання

йоб'єднання готових КПВ, що розміщаються в репозитарію системи;

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

–створення репозитарію КПВ і компонентів багаторазового використання в класі завдань ПрО;

–забезпечення безпеки, захисту даних, змін тощо;

–забезпечення синхронізації і взаємодії КПВ.

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

8.2.3. Стандартизація процесів інженерії домену

У стандарті ISO/IEC 12207: 2002 подано опис процесу доменної інженерії домену (Domain engineering process) як нового процесу в моделі процесів ЖЦ. Згідно з цим стандартом процес інженерії домену охоплює ряд видів діяльності: аналіз і проектування домену, а також технологію інженерії домену.

Аналіз домену полягає у:

–визначенні меж домену і зв'язків з іншими доменами;

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

–формуванні словників для опису основних понять у домені і взаємозв'язків між активами в домені;

–класифікації і документуванні моделей;

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

Проектування домену (Domain design) – це визначення архітектури домену за допомогою програмних компонентів, специфічних ресурсів, або активів (Assets).

Крім цього стандарту, відмітимо проект стандарту комітету OMG (http:\\www.omg.org) з повторних компонентів RAS (Reusing Assets Specifications).

Уньому пропонується формат опису інформації щодо повторно використовуваних ресурсів при розробці ПС, що є узагальненням поняття активу (asset) як програмного розв’язання деякої задачі в заданому контексті, яка належать до проблеми розробки ПС, а контекст визначає процес розроблення або виконання програмного продукту. Актив — це компонент або КПВ, тобто робочий продукт

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

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

Технологія інженерії домену, що базується на новому процесі в моделі ЖЦ (ISO/IEC 12207) і понятті ресурсу (asset), містить у собі наступні стандартизовані підпроцеси:

–формування ресурсів (asset provision), тобто розроблення або придбання ресурсів, які можуть використовуватися при компонуванні нових програмних систем або підсистем;

–розроблення бази ресурсів (asset-based development), основою якої є концепція повторного використання (software reuse) – КПВ, що забезпечує компоновку програмних продуктів домена;

–супровід ресурсів (Asset maintenance) – модифікація і еволюція моделі, архітектури і продуктів домену за рахунок готових ресурсів типу КПВ.

Ця технологія припускає розробку методик і інструментів для ефективного виконання процесів ЖЦ а також для генерації системи із КПВ і компонентів багаторазового застосування відповідно до специфікацій вимог до системи та опису специфіки ПрО засобами спеціалізованих мов DSL.

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

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

8.3. Інженерія індустріального виробництва програмних продуктів

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

процеси та технологічні лінії виготовлення продуктів. Фірми-виготовники проводять моніторинг для визначення запиту на деякий вид програмного продукту.

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

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

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

Відомими середовищами для виготовлення програмних продуктів є лінії виробництва (Product Line Practice), система Microsoft Visual Studio Teams Systems, Microsoft MSF, Eclips тощо. Розглянемо їх детальніше.

8.3.1. Структура лінії виробництва програмних продуктів

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

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

При цьому в межах домену досліджуються ринок і потреби покупців, будується виробничий план, процеси і визначається організація їхньої взаємодії. Відповідно до потреб ринку будується технологічна лінія продукту, в яку включаються процеси, необхідні методи розробки, тестування і оцінки продуктів та процесів цієї лінії. Основу лінії становить інфраструктура, в яку входять групи розробників, різні методи і засоби інженерії ПрО, необхідні для побудови і експлуатації лінії виробництва продуктів (рис. 8.6) [10–12], а також відповідні керівні матеріали і методики.

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

– обмеженнями, властивими майбутнім продуктам лінії;