3.3 Розробка функціональної схеми
На функціональній схемі, зображеній на рисунку 3.2, є можливість прослідкувати за шляхами проходження функціональних сигналів від одного функціонального блоку до іншого та побачити рівні надходження данних з мережі та міри їхньої обробки.
Користувач використовуючи Інтернет браузер FireFox одержує доступ до глобальної мережі Інтернет та через розроблене програмне забезпечення A_system взаємодіє з Інтернетом (Web-контент), розмовляє за допомогою Інтернет пейджерів ( IRC, ICQ, AIM), користується електронною поштою.
Firefox є релізом наступного покоління веб-браузерів, який має безліч нагород, він містить у собі безліч спеціальних можливостей, що дозволяють зробити веб-браузер і веб-контент доступним для всіх користувачів.
Рисунок 3.2 – Функціональна схема системи
Програмне забезпечення A_system є системою розширення (extentions) можливостей FireFox надаючі користувачеві захист від фішингових атак.
Розглянувши усі блоки функціональної схеми перейдемо до розгляду діаграми взаємодії процесів, які відбуваються у системі.
3.4 Розробка діаграми процесів
Діаграма процесів розробленої системи зображена на рисунку 3.3. При детальному її розгляді можна побачити як саме проходе взаємодія у розробленій системі. Використовується модель проектування, графічне представлення «потоків» даних в інформаційній системі.
Діаграма взаємодії процесів використовується для візуалізації процесів обробки даних (структурне проектування). Для розробника вважається звичним спочатку креслити діаграму взаємодії процесів даних рівня контексту, завдяки чому буде показано взаємодію системи. Ця діаграма в подальшому підлягає уточненню шляхом деталізації процесів та потоків даних з метою показати систему що розробляється.
Діаграми потоків даних містять чотири типи елементів:
– Процеси які являють собою трансформацію даних в рамках описуваної системи.
– Сховища даних (репозиторії).
– Зовнішні по відношенню до системи сутності.
– Потоки даних між елементами трьох попередніх типів.
Рисунок 3.3 – Діаграма взаємодії процесів
4 Реалізація проекту. Розрахунки і експериментальні дані, що підтверджують правильність проектних рішень
4.1 Блок-схеми та опис алгоритмів функціонування системи
Було використано підходи з використанням UML, це уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, називаної UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.
UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм. Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.
Діаграми дають можливість представити систему (як ділову, так і програмну) у такому вигляді, щоб її можна було легко перевести в програмний код. Основною причиною використання мови UML є спілкування розробників між собою.
Крім того, UML спеціально створювалася для оптимізації процесу розробки програмних систем, що дозволяє збільшити ефективність їх реалізації у кілька разів і помітно поліпшити якість кінцевого продукту.
UML прекрасно зарекомендувала себе в багатьох успішних програмних проектах. Засоби автоматичної генерації кодів дозволяють перетворювати моделі мовою UML у вихідний код об’єктно-орієнтованих мов програмування, що ще більш прискорює процес розробки. Практично усі CASE-засоби (програми автоматизації процесу аналізу і проектування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.
Діаграми підвищують супроводжуваність проекту і полегшують розробку документації.
UML необхідний:
– Керівникам проектів, які керують розподілом завдань і контролем за проектом.
– Проектувальникам інформаційних систем які розробляють технічні завдання для програмістів.
– Бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії.
– Програмістам які реалізовують модулі інформаційної системи.
При модифікації системи об'єктний підхід дозволяє легко включати в систему нові об'єкти і виключати застарілі без істотної зміни її життєздатності. Використання побудованої моделі при модифікаціях системи дає можливість усунути небажані наслідки змін, оскільки вони не ламають структури системи, а тільки змінюють поведінку об'єктів.
Також при розробці дипломного проекту було використано наступні підходи UML: діаграма діяльності (діаграми поведінки типу); діаграма прецедентів (діаграми поведінки типу); Діаграма класів; Діаграма компонент; Діаграма об'єктів; Діаграма розгортання.
Діаграма діяльності. Це візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій. Дія є фундаментальною одиницею визначення поведінки в специфікації. Дія отримує множину вхідних сигналів, та перетворює їх на множину вихідних сигналів.
Одна із цих множин, або обидві водночас, можуть бути порожніми. Виконання дії відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності. Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та тестувати, деякі дії можуть вимагати певної послідовності.
Специфікація діяльності (на вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та існування механізмів синхронізації для гарантування виконання дій у правильному порядку.
Діаграма прецедентів це діаграма, на якій зображено відношення між акторами та прецедентами в системі. Також, перекладається як діаграма варіантів використання.
Діаграма прецедентів є графом, що складається з множини акторів, прецедентів (варіантів використання) обмежених границею системи (прямокутник), асоціацій між акторами та прецедентами, відношень серед прецедентів, та відношень узагальнення між акторами. Діаграми прецедентів відображають елементи моделі варіантів використання.
Суть даної діаграми полягає в наступному: проектована система представляється у вигляді безлічі сутностей чи акторів, що взаємодіють із системою за допомогою так званих варіантів використання. Варіант використання (use case) використовують для описання послуг, які система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, який виконує система при діалозі з актором.
При цьому нічого не говориться про те, яким чином буде реалізована взаємодія акторів із системою.
У мові UML є кілька стандартних видів відношень між акторами і варіантами використання:
– асоціації (association relationship);
– включення (include relationship);
– розширення (extend relationship);
– узагальнення (generalization relationship).
При цьому загальні властивості варіантів використання можуть бути представлені трьома різними способами, а саме — за допомогою відношень включення, розширення і узагальнення.
Відношення асоціації – одне з фундаментальних понять у мові UML і в тій чи іншій мірі використовується при побудові всіх графічних моделей систем у формі канонічних діаграм.
Включення (include) у мові UML - це різновид відношення залежності між базовим варіантом використання і його спеціальним випадком. При цьому відношенням залежності (dependency) є таке відношення між двома елементами моделі, при якому зміна одного елемента (незалежного) приводить до зміни іншого елемента (залежного).
Відношення розширення (extend) визначає взаємозв'язок базового варіанта використання з іншим варіантом використання, функціональна поведінка якого задіюється базовим не завжди, а тільки при виконанні додаткових умов.
Діаграма класів це статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення.
Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.
Діаграма класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини.
В UML існують наступні типи зв'язків які використовуються у діаграмі класів: Асоціації; Агрегація; Композиція.
Асоціації це якщо між двома класами визначена асоціація, то можна переміщатися від об'єктів одного класу до об'єктів іншого. Цілком припустимі випадки, коли обидва кінці асоціації відносяться до одного і того ж класу. Це означає, що з об'єктом деякого класу дозволено зв'язати інші об'єкти з того ж класу. Асоціація, що зв'язує два класи, називається бінарної. Можна, хоча це рідко буває необхідним, створювати асоціації, що зв'язують відразу кілька класів. Графічно асоціація зображується у вигляді лінії, що з'єднує клас сам з собою або з іншими класами.
Асоціації може бути присвоєно ім'я, яке описує природу відносини. Зазвичай ім'я асоціації не вказується, якщо тільки ви не хочете явно задати для неї рольові імена або у вашій моделі настільки багато асоціацій, що виникає необхідність посилатися на них і відрізняти один від одного. Ім'я буде особливо корисним, якщо між одними і тими ж класами існує кілька різних асоціацій.
Клас, що бере участь в асоціації, грає в ній деяку роль. По суті, це "обличчя", яким клас, що знаходиться на одній стороні асоціації, звернений до класу з іншого її боку. Можна явно позначити роль, яку клас грає в асоціації.
Часто при моделюванні буває важливо вказати, скільки об'єктів може бути пов'язано допомогою одного примірника асоціації. Це число називається кратністю (Multiplicity) ролі асоціації та записується або як вираз, значенням якого є діапазон значень, або в явному вигляді.
Вказуючи кратність на одному кінці асоціації, ви тим самим говорите, що на цьому кінці саме стільки об'єктів повинно відповідати кожному об'єкту на протилежному кінці. Кратність можна задати рівною одиниці (1), можна вказати діапазон: "нуль або одиниця" (0..1), "багато" (0 .. *), "одиниця або більше" (1 .. *). Дозволяється також вказувати певне число (наприклад, 3). За допомогою списку можна задати і більш складні кратності, наприклад 0. . 1, 3..4, 6 .. *, що означає "будь-яке число об'єктів, крім 2 і 5".
Агрегація це проста асоціація між двома класами відображає структурний відношення між рівноправними сутностями, коли обидва класу знаходяться на одному концептуальному рівні і ні один не є більш важливим, ніж інший. Але іноді доводиться моделювати відношення типу «частина/ціле», в якому один з класів має більш високий ранг (ціле) і складається з декількох менших за рангом (частин).
Ставлення такого типу називають агрегацією; воно зараховане до відносин типу «має» (з урахуванням того, що об'єкт-ціле має кілька об'єктів-частин). Агрегація є окремим випадком асоціації і зображується у вигляді простої асоціації з незафарбованим ромбом з боку «цілого». Графічно агрегація представляється порожнім ромбом на блоці класу, і лінією, яка від цього ромба до міститься класу.
Композиція це більш суворий варіант агрегації. Відома також як агрегація за значенням.
Композиція має жорстку залежність часу існування екземплярів класу контейнера та примірників містяться класів. Якщо контейнер буде знищений, то весь його вміст буде також знищено. Графічно представляється як і агрегація, але з зафарбовані ромбиком.
Діаграма компонент в UML це діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.
Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись.
Модуль програмного забезпечення може бути представлено в якості компоненти. Деякі компоненти існують під час компіляції, деякі – під час компонування, а деякі під час роботи програми.
Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.
Компоненти об'єднуються разом використовуючи структурні зв'язки (assembly connector) щоб об'єднати інтерфейси двох компонент. Це ілюструє зв'язок типу «клієнт-сервер».
Структурна взаємодія – «зв'язок двох компонент, який передбачає, що один з них надає послуги, потрібні іншому компоненту».
При використанні діаграми компонент щоб показати внутрішню структуру компонента, клієнтські та серверні інтерфейси можуть утворювати пряме з'єднання з внутрішніми. Таке з'єднання називається з'єднанням делегації.
Діаграма об'єктів в UML це діаграма, що відображає об'єкти та їх зв'язки в певний момент часу. Діаграма об'єктів може розглядатись як окремий випадок діаграми класів, на якій можуть бути представлені як класи, так і екземпляри (об'єкти) класів. Схожою за змістом є діаграма взаємодії (collaboration diagram).
Діаграми об'єктів не мають власної нотації. Оскільки діаграми класів можуть відображати об'єкти, то діаграма класів, на якій відображено лише об'єкти, та не відображено класи, може вважатись діаграмою об'єктів.
Діаграма об'єктів відображає об'єкти та зв'язки в певний момент роботи програми. Об'єкти можуть містити інформацію про власні значення а не про описання. Для відображення загальних шаблонів об'єктів та зв'язків, що можуть багаторазово створюватись під час роботи програми, слід використовувати діаграму взаємодії, яка може відображати характеристики об'єктів та зв'язків. Екземпляр діаграми взаємодії створює діаграму об'єктів.
Діаграма об'єктів не відображає еволюцію системи під час роботи. Натомість, слід використовувати діаграми взаємодії з повідомленнями, або діаграми послідовності.
Діаграма розгортання (deployment diagram) це діаграма в UML, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах. Компоненти відповідають представленню робочих екземплярів одиниць коду. Компоненти, що не мають представлення під час роботи програми на таких діаграмах не відображаються; натомість, їх можна відобразити на діаграмах компонент. Діаграма розгортання відображає робочі екземпляри компонент, а діаграма компонент, натомість, відображає зв'язки між типами компонент.
Під час роботи над дипломним проектом було створено блок-схеми. Перед їх розглядом необхідно провести роз’яснення який саме тип блок-схем використовується.
Блок-схема це представлення задачі для її аналізу або розв'язування за допомогою спеціальних символів (геометричних образів), які позначають такі елементи, як операції, потік, дані тощо. Блок вхідних та вихідних даних прийнято позначати паралелограмом, блок обчислень (обробки) даних - прямокутником, блок прийняття рішень - ромбом, еліпсом - початок та кінець алгоритму.
У інформаційних технологіях функціональна схема складається з функціональних блоків, які являють собою конструктивно відособлені частини (елементи або пристрої) автоматичних систем, які виконують певні функції. Функціональні блоки на схемі позначають прямокутниками, всередині яких надписують їх найменування відповідно до функцій, що виконуються. Зв'язки між функціональними блоками (внутрішні впливи) позначаються лініями зі стрілками, які вказують напрям впливів.
Функціональні схеми можуть виконуватися в укрупненому і розгорненому вигляді. У першому випадку на схемі зображають найважливіші блоки системи і зв'язки між ними.
У другому варіанті схема відображається більш детально, що полегшує її читання та ілюструє принцип роботи.
Основні елементи схем алгоритму це термінатор, процес, рішення, зумовлений процес (підпрограма), дані та з'єднувач.
Термінатор це елемент відображає вхід із зовнішнього середовища або вихід з неї (найчастіше застосування - початок і кінець програми). Всередині фігури записується відповідна дія.
Процес це виконання однієї або кількох операцій, обробка даних будь-якого виду (зміна значення даних, форми подання, розташування). Всередині фігури записують безпосередньо самі операції.
Рішення це показує рішення або функцію перемикального типу з одним входом і двома або більше альтернативними виходами, з яких тільки один може бути обраний після обчислення умов, визначених всередині цього елементу. Вхід в елемент позначається лінією, що входить зазвичай у верхню вершину елементу. Якщо виходів два чи три то зазвичай кожен вихід позначається лінією, що виходить з решти вершин (бічних і нижній). Якщо виходів більше трьох, то їх слід показувати однією лінією, що виходить з вершини (частіше нижній) елемента, яка потім розгалужується. Відповідні результати обчислень можуть записуватися поруч з лініями, що відображають ці шляхи.
Зумовлений процес (підпрограма) це символ відображає виконання процесу, що складається з однієї або кількох операцій, що визначені в іншому місці програми (у підпрограмі, модулі). Всередині символу записується назва процесу і передані в нього дані.
Дані це перетворення у форму, придатну для обробки (введення) або відображення результатів обробки (виведення). Цей символ не визначає носія даних (для вказівки типу носія даних використовуються специфічні символи).
З'єднувач це символ відображає вихід в частину схеми і вхід з іншої частини цієї схеми. Використовується для обриву лінії та продовження її в іншому місці (приклад: поділ блок-схеми, що не поміщається на листі). Відповідні сполучні символи повинні мати одне (при тому унікальне) позначення.
На рисунку 4.1 зображена основна блок-схема програми, на рисунку 4.2 зображено роботу підпрограми.
Рисунок 4.1 – Блок-схема основної програми
З яких видно що робота основної програми складається з початкових етапів ініціалізації ПЗ, перевірки наявності ресурсів системи, блоку початку основного циклу з чеканням запиту від користувача в якому відбувається виклик підпрограми та останньої стадії – перевірка поточного стану з завершенням роботи розробленого ПЗ. При роботі підпрограми виконується основний функціонал системи з циклічними послідовностями, перевіркою поточного стану та поверненням в основну програму прапорів стану виконання.
Рисунок 4.2 – Блок-схема роботи підпрограми
Блок-схеми є першоджерелами стратегії розвитку ПЗ. Тому від точності і детальної блок-схеми залежить результат всієї програми.
При виборі початкової точки відліку при побудові схем було враховано, що виходячи з вибору мови програмування і інших технічних засобів, програма буде об’єктно-орієнтована що вимагає оптимізації програми високого рівня, також те, що при розробці програми слід надати особливу увагу модулю системи протидії технологіям соціальної інженерії у мережі Інтернет.
При складанні блок-схем програмного забезпечення і напрацювання алгоритмів я зіткнувся з масою проблем, які вимагали напрацювання процедур і функцій над основною проблематикою. Для чого були створені додаткові класи, типи даних і константи, що забезпечило вирішення проблем.
Розглянемо проведені першочергові дії по створенню дипломного програмного забезпечення.
Одним з найбільш корисних властивостей популярного браузера FireFox є система розширень (extentions). Завдяки розширенням, можливо одержати додаткову функціональність, відсутню в самому браузері в моєму випадку антифішингова зашита.
Часто користувачі не знаходять потрібних розширень серед уже існуючих доступних у мережі Інтернет, незважаючи на готовність заплатити гроші за потрібне розширення, що породжує попит у різних розширеннях, саме через дані економічні міркування був обраний за основу браузер FireFox.
Розширення FireFox мають власну структуру файлів і щоб розширення правильно працювало, потрібно створити кореневий каталог, де будуть розміщатися всі файли розширення антифішингового захисту.
У будь-якому розширенні FireFox повинне бути як мінімум два файли - install.rdf і contents.rdf. У першому описано, як розширення буде встановлюватися в браузер, другий файл визначає структуру розширення.
Це прості текстові файли в XML-форматі, так що їх можна створювати в будь-якому текстовому редакторі. Але для зручності, я користувався спеціальним редакторам для xml-файлів (XMLSpy). Розширення rdf - це скорочення для "Resource Description Framework".
Вміст файлу install.rdf - цей файл повинен розташовуватися на самому верхньому рівні нашої антифішингової файлової ієрархії.
+- A_system / +- install.rdf +- chrome/ +- content/
У цьому файлі було описане наше розширення для менеджера розширень браузера FireFox, повідомивши його різну корисну інформацію - з якими версіями браузера сумісний додаток A_system.
<?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:em="http://www.mozilla.org/2004/em-rdf#"> <Description about="urn:mozilla:install-manifest"> <em:description>A_system extention</em:description> <em:homepageURL> </em:homepageURL>
<em:id>{65b3130e-8513-41b6-8ea8-43dbd9cc0b12}</em:id> <em:name>A_system</em:name> <em:version>1.0</em:version> <em:targetApplication> <Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:minVersion>1.0</em:minVersion> <em:maxVersion>1.0</em:maxVersion> </Description> </em:targetApplication> <em:file> <Description about="urn:mozilla:extension:file: A_system.jar"> <em:package>content/</em:package> </Description> </em:file> </Description> </RDF>
У перших рядках написано, що цей файл - ніщо інше, як стандартний XML-Файл. Для менеджера розширень надаються наступні дані.
<em:description>A_system extention</em:description> <em:homepageURL></em:homepageURL> <em:id>{65b3130e-8513-41b6-8ea8-43dbd9cc0b12}</em:id> <em:name>A_system</em:name> <em:version>1.0</em:version>>
Перший рядок указує на авторські права коду, для чого використовується тег <em:creator>. Наступний рядок - короткий опис того, а для чого, властиво, це розширення призначене. Ця інформація буде видна користувачам у менеджері розширень. Третій рядок указує на домашню сторінку розширення.
Четвертий рядок у цій секції, у тезі <em:id>, це найбільш важлива інформація у всьому файлі. Тут вказується унікальний ідентифікатор антифішингового розширення. Існує багато способів генерації унікальних ідентифікаторів.
Я використовував програму GUID Generator від Andy Hoskinson http://www.hoskinson.net/webservices/guidgeneratorclient.aspx.
Після створення унікального ідентифікатора я помістив його в тег <em:id>. У наступних рядках файлу описується, для якого додатка призначене це розширення:
<em:targetApplication> <Description> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> <em:minVersion>1.0</em:minVersion> <em:maxVersion>1.0</em:maxVersion> </Description> </em:targetApplication>
У моєму випадку в тезі <em:name> зазначений унікальний код браузера FireFox і його значення не повинне змінюватися. Тут же я встановив два тега для вказівки мінімальної й максимальної версії додатка, з якими дане розширення сумісне.
У моєму випадку ці два значення збігаються. Поточна версія FireFox дотримується наступної угоди по версіях:
major.minor.release.build[+]
Поля, що випливають за major – необов'язкові. У кінцевій частині опису файлу я вказав розташування JAR-Файлу (розглянутий нижче):
<em:file> <Description about="urn:mozilla:extension:file: A_system.jar"> <em:package>content/</em:package> </Description> </em:file>
В атрибуті about тегу <Description> вказується ім'я. У моєму випадку це посилання на файл "A_system.jar".
Для зручності, я назвав ім'я файлу співпадаюче з ім'ям розширення. В елементі <em:package> вказується розташування JAR-Файлу. Тому що в нас у директорії chrome є тільки один фолдер content, те його він і вказується.
Уміст contents.rdf - У цьому файлі описується, як моє розширення Антифішинг зберігається.
Це текстовий файл в XML-Форматі й він повинен розташовуватися в директорії content. Таким чином, після створення цього файлу, я одержав наступну структуру:
+- A_system/ +- install.rdf +- chrome/ +- content/ +- contents.rdf
Зміст цього файлу наступний:
<?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <RDF:Seq about="urn:mozilla:package:root"> <RDF:li resource="urn:mozilla:package:A_system"/> </RDF:Seq> <RDF:Description about="urn:mozilla:package:A_system" chrome:extension="true" chrome:name="A_system"/> <RDF:Seq about="urn:mozilla:overlays"> <RDF:li resource="chrome://browser/content/browser.xul"/> </RDF:Seq> <RDF:Seq about="chrome://browser/content/browser.xul"> <RDF:li>chrome://A_system/content/A_system-Overlay.xul</RDF:li> </RDF:Seq> </RDF:RDF>
Перші строки:
<RDF:Seq about="urn:mozilla:package:root"> <RDF:li resource="urn:mozilla:package:A_system"/> </RDF:Seq>
Указую назву пакета в першому атрибуті. У другому атрибуті повідомляємо, що так, цей додаток є розширенням Антифішинг.
І, нарешті, указування ім'я нашого пакета. Необхідно щоб значення атрибута chrome:name повинне бути зазначене в нижньому регістрі.
Всі видимі елементи в браузері FireFox створені за допомогою framework XUL (визначення розглянуте в раныше) і всі разом вони називаються chrome.
У наступному фрагменті коду дипломного проекту вказується, який файл chrome наше розширення буде "розширювати". У більшості випадків розширюється тільки файл brouser.xul, хоча є й інші. У випадку розробленого антифішингового додатку все просто:
<RDF:Seq about="urn:mozilla:overlays">
<RDF:li resource="chrome://browser/content/browser.xul"/> </RDF:Seq>
Для розробки користувальницького інтерфейсу розширень FireFox використовується мова розмітки XUL, що я вже згадував ледве вище. Краса XUL виражається в тім, що називається "динамічні оверлеї" (dynamic overlays). Вони дозволяють змінювати поводження інтерфейсу без необхідності зміни оригінального коду.
Для початку, я створив створив у меню Tools пункт "A_system". Для цього створив overlay-файл із назвою, зазначеною в тезі <RDF:li>. Він розташовується в тій же директорії що й contents.rdf.
У файлі A_system-Overlay.xul я вказав наступні дані:
<?xml version="1.0"?> <overlay id="A_systemOverlay" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <menupopup id="menu_ToolsPopup"> <menuitem label="A_system" position="1" />
<menuitem label=" About" position="2" />
. . . . . </menupopup> </overlay>
І далі продовжував створювати інтерфейс...
Після формування антифішинговогу інтерфейсу я одержав наступну структуру файлів:
+- A_system / +- install.rdf +- chrome/ +- content/ +- contents.rdf +- A_system-Overlay.xul
Зібрав в один пакет з розширенням XPI і встановив у браузер FireFox.