2. Системнепрограмування
14. Машинно-орієнтовані мови програмування. Асемблери. Структура асемблера, перегляди тексту програми та відповідні бази даних.
Асемблер: машинно-орієнтована мова. Основною одиницею в асемблер-програмі є машинна команда (директива асемблера). На її основі будується машинний код.
Директиви асемблера– це команди, що управляють процесом компіляції. На основі директиви асемблера об’єктний код не будується. Кожна машинна команда чи директива записується в один рядок (або в декілька шляхом продовження).
Між кодами операцій і операціями повинен бути щонайменше один " ". Операнди записуються через кому, без проміжків.
ОП1,ОП2 коментар (коментар може починатись або з "*" або з ";")
Помітка– іменує як команди, так дані (символьне ім’я). В асемблері значення символьного імені є адреса. Repeat– символьне ім’я.
К
ожне
символьне ім’я кодується парою: (база,
зміщення), де база - ім’я сегменту
програми, в якому це символьне ім’я
визначено.
Оскільки
ми не можемо знати наперед абсолютну
адресу пам’яті ЕОМ, куди завантажується
програма, то асемблер виконує початкове
присвоєння абсолютної адреси кожного
сегменту значення
.
Реальна адреса формується під час
виконання програми шляхом сумування
значення регістру та зміщення, а початкові
значення регістрів сегментів приписується
операційною системою під час завантаження
програми.
А
семблер
під час обробки програми з кожним
сегментом пов’язує лічильник сегменту.
Обчислюється як попереднє значення
плюс довжина команди. Початкове значення
кожного лічильника або встановлюється
директивою асемблера.
Оскільки відсутня дисципліна вживання символьних імен, компілятор асемблеру щонайменше двопрохідний:
Попередній перегляд тексту: визначення значень символьних імен, їх адреси (сегмент + зміщення).
Другий перегляд тексту: Дає можливість перевірити код команди, та вказує адреси операндів.
Але в асемблері існують такі імена та значення, які не можна визначити під час компіляції (абсолютна адреса, ім’я зовнішньої функції). Тому в об’єктному коді резервується місце для операнда, а в результуючий файл, в таблиці модуля вказується зміщення в об’єктному коді, котре треба модифікувати.
2. Інформаційні технології
1. Уніфікована мова моделювання UML. Діаграми прецедентів
2. Використання діаграм послідовностей та діаграм класів при проектуванні програмних систем.
3. Патерни проектування
4. Платформа .NET Framework.
5. Сервісно-орієнтована архітектура
6. Огляд технологій J2EE. Технологія Java RMI.
7. Web-технології Java Servlet та JSP
8. Патерн Model-View-Controller у Web-проектах.
9. Патерн (принцип) IOC&DI та його підтримка у фреймворку Spring
10. Проблема валідації даних у Web-проектах. Підтримка AJAX.
1. Уніфікована мова моделювання uml. Діаграми прецедентів
UML (англ. Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки додатків. Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем. Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код. Практично усі CASE-засоби (програми автоматизації процесу аналізу і проектування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.
Діаграма прецедентів — в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі. Діаграма прецедентів є графом, що складається з множини акторів, прецедентів (варіантів використання) обмежених границею системи, асоціацій між акторами та прецедентами, відношень серед прецедентів, та відношень узагальнення між акторами.[1] Діаграми прецедентів відображають елементи моделі варіантів використання. Суть даної діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей чи акторів, взаємодіючих із системою за допомогою так званих варіантів використання. Варіант використання (use case) служить для опису сервісів, що система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, чинений системою при діалозі з актором. При цьому нічого не говориться про те, яким чином буде реалізована взаємодія акторів із системою.
У мові UML є кілька стандартних видів відношень між акторами і варіантами використання:
• асоціації (association relationship)
• включення (include relationship)
• розширення (extend relationship)
• узагальнення (generalization relationship)
--ТАКОЖ МОЖЕШ НАМАЛЮВАТИ ПРИКЛАД—