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

–технологію розробки системи;

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

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

–облік процесу тестування, складання звітів про аномальні події, відмови і дефекти в підсумковому документі системи.

Висновки. Були розглянуті формальні специфікації програм, методи доведення програм за ними, а також сучасні методи і процеси верифікації та тестування ПС, засновані на понятті програм – «біла скринька» і «чорна скринька». Визначено критерії тестування, типи помилок, що виявляються в програмах, а також відмови і помилки на процесах ЖЦ. Сформульовано методи забезпечення процесів отримання правильних програм за допомогою спеціальних груп фахівців, зокрема тестувальників.

Контрольні питання і завдання

1.Назвіть формальні методи перевірки правильності програм.

2.Визначте формальну специфікацію.

3.Визначте основні поняття формальної специфікації VDM і RAISE.

4.Визначте мету і структуру концепторної мови.

5.Визначте поняття передумов і постумов, аксіом і тверджень.

6.Опишіть, як проходить процес доведення специфікованої програми і назвіть проблеми проведення доведення.

7.Які процеси перевірки зафіксовані в стандарті?

8.Назвіть задачі процесів верифікації і валідації програм.

9.Опишіть міжнародний проект з верифікації.

10.Визначте процес тестування та методи тестування.

11.Поясніть значення термінів «чорна скринька» та «біла скринька».

12.Назвіть об'єкти тестування і підходи до їхнього тестування.

13.Яка існує класифікація типів помилок і тестів перевірки програм.

14.Назвіть сутність інфраструктури організації робіт з тестування?

Список літератури до розділу 6

1.Марков А.А. Теория алгоритмов // Москва, АН СССР. – 1954. – 231 с.

2.Ляпунов А.А. О логических схемах программ// Проблемы кибернетики.–

вып.1. – М.: 1958.

3.Янов Ю.И. О логических схемах алгоритмов// Проблемы кибернетики.–

вып.1. – М.: 1958.

4.Hoare C.A.R. Рrof of correctness of data representation // Acta Informatica, 1(4).– 271– 287. – 1972. – P. 214–224.

5.Андерсон Р. Доказательство правильности программ. – М.: Мир, 1982. – 165 с.

6.Abrial I.R., Meyer B. Spesification Language Z. – Boston: Massachusetts Computer Associates Inc., 1979. – 378 p.

7.Biorner D., Jones C.B. The Vienna Development Methods (VDM): The Meta – Language. – Vol. 61 of Lecture Notes in Computer Science. – Springer Verlag, Heiderberg, Germany, 1978. – 215 p.

8.Петренко А.К. Венский метод разработки программ // Программирование.– 2001. – № 1. – С. 3–23.

9.The RAISE Language Group. The RAISE Spesification Language. BCS Practitioner Series. – Prentice Hall, 1982. – 397 p.

10.The RAISE Methods Group. The RAISE Development Methods. BCS Practitioner Series. – Prentice Hall, 1985. – 493p.

11.Агафонов В.Н. Спецификации программ: понятийные средства и их организация.– Новосибирск: Наука, 1987. – 240 с.

12.Непомнящий В.А., Сулимов А.А. Об одном подходе к спецификации и верификации трансляторов. М.: Программирование.– 1983.– № 4. – С. 51– 58.

13.Непомнящий В.А., Шилов Н.В., Бодин Е.В. Спецификация и верификация распределенных систем средствами языка Elementary–real// М.: Программирование.– 1999. – № 4. – С. 54–67.

14.Вудкок Д. Первые шаги к решению проблемы верификации программ// Открытые системы.– 2006.–№8.– С. 36-43.

15.Hoare T., Misra J. Verified software: Theories, Tools, Experiments. Vision of Grant Challenge project.–Microsoft Research Ltd and the University of Texas at Austin, 2005.– 1–43c.

16.Коваль В.Н. Концепторные языки. Доказательное проектирование.– Киев.– Наук. думка, 2001.– 182с.

17.Хоар Ч., Лауер П.Е. Непротиворечивые взаимодополняющие теории семантики языков программирования// М.: Мир, 1980.–C.186–221.

18.Dolores R. Wallase M. Ippolito, Cuthill B. Reference Information for the Software Verification and Validation Process // NIST Special Publication. – 1996 . – 80p.

19.Herhart S.L. Program Verification in the 90’s.// Proc. Conf. on Computing in the 1980’s, 1978.– P.80–89.

20.Fei Xie and James C. Browne. Verified Systems by Composition from Verified Components {feixie, browne}@cs.utexas.edu.

21.Майерс Г. Искусство тестирования программ. – Пер.с англ. M.: Финансы и статистика. – 1982. – 176 с.

22.Иванников В.П., Дышлевый К.В., Мажелей С.Г., Садовская Д.Б., Шебуняев А.Б. Распределенные объектно-ориентированные среды // М.: Труды ИСП РАН, 2000.–с.84–100

23.Липаев В.В. Тестирование программ. – М.: Радио и связь, 1986. – 295 с.

24.Канер С., Фолк Д., Нгуен Е.К. Тестирование программного обеспечения: Пер с англ. – Киев: DiaSoft. – 2000. – 544 с.

25.Weyuker E.J., Ostrand T.J. Theories of program testing and the application of revealing subdomains // IEEE Trans.Soft.Eng. – 1980. – 6. – №. 3, – P. 236– 246.

26.Андон Ф.И., Коваль Г.И., Лаврищева Е.М., Коротун Т.M., Суслов В.Ю,

Основы инженерии качества программных систем. – Киев: Академпериодика.–Второе изд.– 2007. – 680с.

27.http://research.microsoft.com/specsharp/

28.ISO/IEC 12207: 2002. Information technology – Software life cycle processes). Информационные технологи. – Процессы жизненного цикла программного обеспечения.

29.Соммервил И. Инженерия программного обеспечения.–6 издание.– Москва–Санкт–Петербург–Киев, 2002.–623 с.

30.CASE–93. Proceeding Sixth Intern. // Workshop on Computer Aided Software Engineering. – Singapure. – 1993. – July 19–23. – 418 p.

31.Лаврищева Е.М., Коротун Т.М. Построение процесса тестирования программных систем // Проблемы программирования.–2002.–№1–2.– С.272–281.

32.Бабенко Л.П., Лавріщева К.М. Основи программноі інженерії. – Киев: Знання, 2001. – 269 с.

33.Коротун Т.М. Модели и методы инженерии тестирования программных

систем в условиях ограниченных ресурсов. – Автореф. дис. … канд.-физ.- мат. наук. – Киев: Ин-т кибернетики им. В.М. Глушкова НАН Украины, 2005. – 21 с.

184

Розділ 7. ІНТЕРФЕЙСИ, ВЗАЄМОДІЯ, ЕВОЛЮЦІЯ ПРОГРАМ І ДАНИХ

У цьому розділі розглядаються базові поняття з програмної інженерії, які необхідні для виробництва ПС. До них відносять: інтерфейси, засоби їхнього подання; взаємодія різномовних програм за інтерфейсом; перетворення і змінювання програм і даних. Описано різні види інтерфейсів, методи перетворення нееквівалентних типів даних взаємодіючих різномовних програм. Визначено задачі неоднорідності МП, платформ і середовищ, що впливають на зв'язки різномовних програм, сформульовано шляхи їхнього розв’язання. Розглянуто стандарт ISO/IEC 11404 –1996 про незалежні від сучасних МП типів даних і забезпечення універсальним апаратом їхнього перетворення і форматів даних, а також еволюційне змінювання програм.

7.1. Визначення інтерфейсу у програмуванні

Інтерфейс – це зв'язок двох окремих сутностей. Види інтерфейсів: мовні, програмні, апаратні, призначені для користувача, цифрові і т.п. Програмний (API) і/або апаратний інтерфейс (port) – це способи перетворення вхідних/вихідних даних під час об'єднання комп'ютера з периферійним обладнанням. У МП – це програма або частина програми, в якій визначаються константи, змінні, параметри і структури даних для передачі іншим.

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

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

Уразі, коли один з елементів (програма, процедура або функція) записаний на різних МП і, крім того, якщо всі ці елементи розташовуються на різних комп'ютерах, то виникають проблеми неоднорідності типів даних в цих МП, структурах пам'яті платформ комп'ютерів і операційних середовищ, де вони виконуються. Поняття інтерфейсу як самостійного об'єкта сформувалося у зв'язку із складанням або об'єднанням різномовних програм і модулів в монолітну систему на великих ЕОМ (mainframes) [1, 2].

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

структури пам'яті комп'ютерів. На рис. 7.1 наведено схему програми С, в якій містяться два виклики – Call A ( ) і Call B ( ) з параметрами, що через інтерфейсні модулі-посередники A’ і B’ здійснюють перетворення даних і їх передачу модулям А і В.

Рис. 7.1. Схема зв’язків модулів А і В із С через інтерфейси А’ і B’

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

7.1.1. Інтерфейси в сучасних середовищах

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

–захищені, доступні класу і підкласу;

–приватні, доступні класу

Рис. 7.2. Структура представлення класу

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

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

Нове тлумачення інтерфейсу об'єктів наведено в праці П. Вегнера [3], який сформулював парадигму переходу від алгоритмів обчислень до взаємодії об'єктів. Суть цієї парадигми полягала в тому, що обчислення і взаємодія об'єктів розглядалися як дві ортогональні концепції. Взаємодія – це деяка дія (action), але не обчислення, а повідомлення – не алгоритм, а дія, відповідь на яку залежить від послідовності операцій (Op), що впливають на стан розподіленої (shared state) пам'яті локальної програми (рис. 7.3). Операції інтерфейсу (Op1 і Op2) належать до класу неалгоритмічних і забезпечують взаємодію об'єктів через повідомлення.

Рис.7.3. Інтерфейс взаємодії через операції інтерфейсу (за Вегнером)

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

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

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

Мережі будуються на основі стандартної семирівневої моделі відкритих систем OSI (Open Systems Interconnection) [5]. Об'єкти рівнів у цій моделі зв'язуються між собою по горизонталі і вертикалі. Запити від застосувань надходять на рівень представлення даних для їхнього кодування (перекодування) до виду платформи, що використовується в застосуванні. Відкриті системи надають будь-яким застосуванням різного роду послуги: керування віддаленими об'єктами, обслуговування черг і запитів, обробка інтерфейсів і т.п.

Доступ до послуг здійснюється за допомогою різних механізмів:

–виклику віддалених процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [5, 6];

–скріплення розподілених об'єктів і документів в системі DCOM [7];

–мови опису інтерфейсу IDL (Interface Definition Language) з підтримкою його брокером – ORB (Object Request Broker) в системі CОRBA [8];

–виклику RMI (Remote Methods Invocation) в системі JAVA [9, 10] і ін.

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

Взаємозв'язок процесу з віддалено розташованим від нього іншим процесом (наприклад, сервером) на іншому комп'ютері виконує протокол UDP або TCP/IP, який передає параметри в stub–інтерфейсі клієнта stub-серверу для виконання віддаленої процедури.

Механізм посилання запиту в системі CORBA базується на описі запиту в мові IDL для доступу до віддаленого методу/функції через протокол IIOP або GIOP. Брокер ORB передає запит генератору, потім посилає stub/skeleton серверу, що реалізує інтерфейс засобами об'єктного сервісу (Common Object Services) або загальними засобами (Common Facilities). Оскільки брокер реалізовано в різних розподілених системах: CORBA, COM, SOM, Nextstep і ін.[11], то він забезпечує взаємодію об'єктів в різних мережних середовищах.

Виклик методу RMI в системі JAVA виконує віртуальна машина (virtual machine), яка інтерпретує byte-коди програми, що викликаються, створені різними системами програмування МП (JAVA, Pascal, С++) на різних комп'ютерах і середовищах. Функції RMI аналогічні брокеру ORB.

7.1.2. Інтерфейс між клієнтом і сервером

У розподіленому середовищі реалізується два способи зв’язування: на рівні МП через інтерфейси прикладного програмування і компілятори IDL, що генерують клієнтські і серверні Stab. Інтерфейси визначаються в мові IDL або APL, динамічний інтерфейс від об'єкта-клієнта до объекта-сервера і назад виконує брокер ORB. Інтерфейси мають окрему реалізацію на МП і доступні різномовним програмам. Компілятори з IDL як частина проміжного рівня самі реалізують зв’язування з МП через інтерфейс клієнта і сервера, заданого в тому ж МП [8, 11– 14].

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

До функції інтерфейсного посередника клієнта належать:

–підготовка зовнішніх параметрів клієнта для звернення до сервісу сервера,

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

Загальні функції інтерфейсного посередника сервера забезпечують:

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

–повернення результату клієнту через параметри повідомлення і знищення віддаленої процедури і ін.

Опис інтерфейсного посередника не залежить від МП взаємодіючих об'єктів і

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

Інтерфейсні посередники задають зв'язок між клієнтом і сервером (stub для клієнта і skeleton для сервера). Їхні описи відображаються в тих МП, в яких представлено відповідні їм об'єкти або компоненти. Ці інтерфейси використовуються в системах CORBA, DCOM, JAVA та ін. Вони надають різні сервіси розробки і виконання застосувань в розподіленому середовищі. Системні сервіси підключаються до застосування за допомогою брокера. Брокер забезпечує інтероперабельність компонентів і об'єктів при переході з одного середовища в інше.

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

До засобів забезпечення інтероперабельності і передачі даних між різними середовищами і платформами належить, наприклад, стандартний механізм зв'язку між JAVA і C/C++ компонентами, що ґрунтується на застосуванні концепції Java Native Interface (JNI), реалізованої як засіб звернення до функцій з JAVA–класів і бібліотек, розроблених на інших мовах.

Ці засоби вміщують аналіз JAVA-класів для пошуку прототипів звернень до функцій, реалізованих в мовах C/C++, і генерацію заголовних файлів для використання їх при компіляції C/C++ програм. Відомо, що у засобі JAVA–класу міститься звернення не до JAVA–методу (він називається native), а для завантаження необхідних C/C++ бібліотек за викликом, що реалізує необхідний зв'язок. Така схема діє в одному напрямі – від JAVA до C/C++ тільки для такої комбінації МП.

Варіант реалізації аналогічної задачі пропонує технологія Bridge2Java, яка забезпечує звернення з JAVA-класів до COM-компонентів. Для цього генерується оболонка для COM-компонента, яка містить у собі проксі-клас і забезпечує необхідне перетворення даних засобами стандартної бібліотеки перетворень типів. Ця схема не вимагає змін в початковому Java-класі, COM-компоненти можуть бути описані різними мовами.

Механізм інтероперабельності реалізовано також на платформі .Net за допомогою проміжної мови CLR (Common Language Runtime). У цю мову транслюються коди, написані в різних МП (C#, Visual Basic, C++, J#). CLR дозволяє не тільки інтегрувати компоненти, розроблені в різних МП, а й використовувати бібліотеку стандартних класів незалежно від мови реалізації.

Такий підхід дозволяє реалізувати доступ до компонентів, які були розроблені раніше без орієнтації на платформу .Net, наприклад, до COMкомпонентів. Для цього використовуються стандартні засоби генерації оболонки для COM-компонента, за допомогою якої він представляється як .Net–компонент.

При такій схемі реалізуються всі види зв'язків і для будь-яких МП даного середовища.

7.2. Інтерфейс мов програмування

7.2.1. Інтерфейс і взаємозв'язок мов програмування

Основні МП, що використовуються для опису компонентів в сучасних середовищах, це С++, Паскаль, JAVA та ін. [11–14].

Різномовні програми, написані в цих мовах, звертаються одна до одної через віддалений виклик, який припускає взаємно однозначну відповідність між фактичними параметрами V = {v1, v2,..., vк} програми, що викликає, і формальними параметрами F = {f1, f1,...,fк1} програми, що викликається. При неоднорідності одного з параметрів із множин формальних або фактичних параметрів різномовних програм необхідно здійснути відображення (mapping) нееквівалентного типу даних параметра в одній МП у відповідний тип даних в іншій МП.

Аналогічно розв'язується задача перетворення нееквівалентних типів даних в МП. Подамо це перетворення такими етапами.

Етап 1. Побудова операцій перетворення типів даних T = {Tt } для множини

мов програмування L = { l } =1, n.

Етап 2. Побудова відображення простих типів даних для кожної пари взаємодіючих компонентів в l 1 і l 2, а також застосування операцій селектора S і конструктора С для відображення складних структур даних в цих мовах.

Один із способів формалізованого перетворення типів даних – створення

алгебраічних систем для кожного типу даних Tt :

Gt = <X t, t >,

де t – тип даних, X t – множина значень, які можуть набути змінні цього типу даних, t – множина операцій над цими типами даних.

Як прості типи даних сучасних МП можуть бути t = b (bool), с (char), i (int), r

(real). Складні типи даних t = а (array), z (record), u (union), e (enum) – комбінація простих типів даних. Цим типам даних відповідають такі класи алгебраїчних

відображення двох алгебраїчних систем з сумісними типами даних двох різних мов. У класі систем (7.1) перетворення типів даних t, q для пари мов lt і l q має такі властивості відображень:

1)системи Gt і Gq для мов lt і l q – ізоморфни, якщо їхні типи даних q, t визначені на одній і тій же множині простих або складних типів даних;

2)між значеннями Xt і Xq типів даних t, q існує ізоморфізм, якщо множина

3) алгебраїчні системи Gt = Gq за потужністю повинні бути рівні, оскільки вони представлені на безлічі типів даних мов lt і l q .

Відображення 1, 2 зберігають лінійний порядок елементів, оскільки алгебраїчні системи є лінійно впорядкованими.

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

Системи програмування з МП мають такі особливості компіляції програм:

–різні двійкові представлення результатів компіляторів для однієї й тієї ж МП, реалізованих на різних комп'ютерах;

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

–параметри виклику об'єктів відображаються в операції методів;

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

–зв'язок МП здійснюється через інтерфейси кожної пари з множини мов (L1,

..., Ln) проміжного середовища.

Зв'язок між різними мовами L1, ..., Ln здійснюється через інтерфейс пари мов Li,…,Ln, що взаємодіють між собою в середовищі, яке генерує відповідні конструкції Li в операції опису інтерфейсу і навпаки.

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

Взаємодія МП в системі CORBA полягає у відображенні типів об'єктів в типи клієнтських і серверних stub шляхом:

–відображення опису запиту клієнта в МП в операції IDL;

–перетворення операцій IDL в конструкції МП і передачу їх серверу засобами брокера ORB, що реалізовує stub в типи даних клієнта.

Оскільки МП системи CORBA можна реалізовувати на різних платформах і в різних середовищах, то їхнє двійкове представлення залежить від конкретної апаратної платформи [7, 8, 11, 13, 14]. Для всіх МП системи CORBA (С++, JAVA, Smalltalk, Visual C++, COBOL Ada-95) передбачено загальний механізм зв'язку і розташування параметрів методів об'єктів в проміжному рівні. Зв'язок між об'єктними моделями кожної МП системи СОМ і JAVA виконує брокер ORB (рис. 7.4). Якщо в загальну об'єктну модель CORBA входить об'єктна модель СОМ, то в ній типи даних визначаються статично, а конструювання складних типів даних здійснюється тільки для масивів і записів.