Розробка проекту мобільного робочого місця «Нарядчик поїзних бригад»

ЗМІСТ

• ВСТУП
• РОЗДІЛ 1. ПРОБЛЕМИ АВТОМАТИЗАЦІЇ РОБОТИ НАРЯДЧИКА ПАСАЖИРСЬКОЇ ВАГОННОЇ ДІЛЬНИЦІ
• 1.1. Загальна характеристика задачі автоматизації роботи нарядчика
• 1.2. Огляд існуючих рішень проблеми автоматизації роботи нарядчика
• РОЗДІЛ 2. КОНЦЕПТУАЛЬНЕ ПРОЕКТУВАННЯ СТРУКТУРИ МОБІЛЬНОГО РОБОЧОГО МІСЦЯ НАРЯДЧИКА ТА ХАРАКТЕРИСТИКА ВИКОРИСТАНИХ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ
• 2.1 Концептуальна модель мобільного робочого місця «Нарядчик поїзних бригад»
• 2.2 Характеристика використаних інструментальних засобів
• РОЗДІЛ 3. ЕКСПЕРИМЕНТАЛЬНА РОЗРОБКА МОБІЛЬНОГО РОБОЧОГО МІСЦЯ «НАРЯДЧИК ПОЇЗНИХ БРИГАД»
• 3.1 Загальна характеристика мобільного робочого місця
• 3.2 Програмна реалізація структурних елементів
• 3.3 Практичні рекомендації до використання
• ВИСНОВКИ
• ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ
• ДОДАТКИ

ВСТУП

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

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

Наприкінці 50-х років для вирішення завдань експлуатації залізничного транспорту почали використовувати ЕОМ. Поступово концепція використання електронних машин і математичних методів, а також накопичений досвід і технічний потенціал, призвели до створення комплексної автоматизованої системи управління залізничним транспортом.

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

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

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

Тому метою роботи є розробка проекту мобільного робочого місця «Нарядчик поїзних бригад».

Об'єкт дослідження — планування та облік робіт поїзних бригад нарядчиком пасажирської вагонної дільниці.

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

Завдання роботи полягають у наступному:

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

2. проаналізувати існуючі рішення проблеми автоматизації робочого місця нарядчика;

3. здійснити концептуальне проектування структури мобільного робочого місця «Нарядчик поїзних бригад»;

4. описати функціональні характеристики інструментальних засобів, обраних для розробки мобільного робочого місця «Нарядчик поїзних бригад»;

5. реалізувати окремі функції мобільного робочого місця «Нарядчик поїзних бригад».

РОЗДІЛ 1. ПРОБЛЕМИ АВТОМАТИЗАЦІЇ РОБОТИ НАРЯДЧИКА ПАСАЖИРСЬКОЇ ВАГОННОЇ ДІЛЬНИЦІ

1.1 Загальна характеристика задачі автоматизації роботи нарядчика

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

Обов’язки нарядчика поїзних бригад (витяг із посадової інструкції):

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

2. Формувати поїзну бригаду спільно з начальником поїзда з дотриманням норм режиму праці і відпочинку, виробляти розстановку у відповідності зі схемою формування поїзда і урахуванням виконання наказів з обов’язковим підписом нарядчика та начальника поїзда у книзі формування бригад. У тій же книзі провідники вагонів розписуються за отримання маршрутного листа;

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

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

5. Контролювати своєчасний вихід на роботу провідників вагонів;

6. Записувати в книги формування поїзних бригад всі відправлені поїзні бригади, окремі причіпні вагони із зазначенням номера поїзда, номера вагона, дати відправлення, ПІБ, табельні номери всіх провідників вагонів і начальників поїздів. Особистий розпис провідника за отримання маршрутного листа в даній книзі обов’язковий;

7. Записувати в книги формування поїзних бригад всі бригади, що прибули, окремі причіпні вагони із зазначенням номера поїзда, номера вагона, дати прибуття, ПІБ всіх провідників, дати виходу на роботу та особистої розпису за вихід;

8. Складати акт спільно зі старшим нарядчиком і інструктором поїзних бригад про ухід провідника з роботи, де обов’язково вказати дату, час, суть справи (якщо провідник вагону не розписані в книзі за наступний вихід на роботу). Акт повинен підписуватися з повним зазначенням прізвищ і посад і передаватися начальнику резерву провідників. По виходу провідника вагону на роботу, пред’явити йому акт про ухід додому за власним бажанням, зажадати пояснення і з усіма документами відвести до начальника резерву провідників для розбору;

9. Оформляти листки непрацездатності поїзних працівників;

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

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

Певний час автоматизація роботи нарядчика Криворізької пасажирської вагонної дільниці «ЛВЧ-2» здійснюється за допомогою інструментарію автоматизованих систем управління експлуатацією, ремонтом пасажирських вагонів та обслуговуванням пасажирів у поїздах (АСУ ЕРПВ) та «Резерв провідників» (див. пункт 1.2).

1.2 Огляд існуючих рішень проблеми автоматизації роботи нарядчика

У пусковому комплексі АСУ ЕРПВ автоматизовано понад 300 функцій управління, основними серед яких є такі:

— облік наявності і конструктивного устрою пасажирських вагонів;

— облік знаходження і використання вагонів;

— облік пробігу пасажирських вагонів;

— облік ремонту і технічного обслуговування вагонів;

— планування ремонту вагонів;

— контроль парку пасажирських вагонів. Формування і передача інформації про парк пасажирських вагонів на рівень інтеграції даних;

— контроль технічного стану пасажирських вагонів в експлуатації;

— контроль і планування надходження коштів від надання послуг у пасажирських поїздах;

— облік наявності, ремонту і пробігу колісних пар;

— контроль парку пасажирських вагонів. Рівень інтеграції даних;

— контроль парку пасажирських вагонів. Графічний інтерфейс;

— контроль і планування надходження коштів від надання послуг у пасажирських поїздах Рівень інтеграції даних;

— контроль та планування роботи поїзних бригад;

— облік і планування ремонту устаткування та об'єктів підвищеної небезпеки;

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

— контроль забезпечення матеріалами, паливом та запасними частинами;

— облік і планування потреби пасажирських вагонів у вугіллі в залежності від прогнозу погоди.

Основним недоліком АСУ ЕРПВ є не оснащеність графічним інтерфейсом та локальний доступ.

Проблема відсутності графічного інтерфейсу була вирішена при розробці АСУ «Резерв провідників» (див. рис. 1.1).

Рис. 1.1. Вікно перегляду електронних маршрутних листів (АСУ «Резерв провідників»)

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

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

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

У першому розділі було вивчено зміст проблеми автоматизації робочого місця нарядчика та проаналізовані існуючі рішення проблеми автоматизації робочого місця нарядчика.

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

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

З самого початку розвитку Internet, а особливо з появою Web-технологій, мережа орієнтована на інформаційне забезпечення своїх користувачів.

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

Саме тому було обрано використання Web-технологій для створення мобільного робочого місця «Нарядчик поїзних бригад»

РОЗДІЛ 2. КОНЦЕПТУАЛЬНЕ ПРОЕКТУВАННЯ СТРУКТУРИ МОБІЛЬНОГО РОБОЧОГО МІСЦЯ НАРЯДЧИКА ТА ХАРАКТЕРИСТИКА ВИКОРИСТАНИХ ІНСТРУМЕНТАЛЬНИХ ЗАСОБІВ

2.1 Концептуальна модель мобільного робочого місця «Нарядчик поїзних бригад»

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

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

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

Діаграми потоків даних є основним засобом моделювання функціональних вимог системи при проектуванні. З їхньою допомогою ці вимоги розбиваються на функціональні компоненти (процеси) і представляються у виді мережі, зв’язаної потоками даних. Головна мета таких засобів — продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також, виявити відносини між цими процесами. Далі при побудові діаграми потоків даних буде використовуватися нотація Гейна-Сарсона (Gane-Sarson). Джерела інформації (зовнішні сутності) породжують інформаційні потоки (потоки даних), що переносять інформацію до підсистем чи до процесів. Ті у свою чергу перетворюють інформацію і породжують нові потоки, що переносять інформацію до інших процесів чи підсистемам, накопичувачів даних чи зовнішніх сутностей — споживачів інформації. Таким чином, основними компонентами діаграм потоків даних є:

— зовнішні сутності;

— процеси;

— накопичувачі даних;

— потоки даних.

Процес являє собою перетворення вхідних потоків даних у вихідні відповідно до певного алгоритму. Фізично процес може бути реалізований різними способами.

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

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

Накопичувачем даних у даній системі є база даних системи (зберігає всю інформацію про користувачів, графіки, напрями руху та іншу інформацію).

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

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

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

Рис. 2.1. Контекстна діаграма потоків мобільного робочого місця «Нарядчик поїзних бригад»

Проведемо декомпозицію потоків даних, показаних на рисунку 2.1

Таблиця 2.1 Декомпозиція потоків даних для контекстної діаграми потоків даних

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

Діаграма потоків даних першого рівня будується як декомпозиція процесів, що присутні на контекстній діаграмі. Опишемо декомпозицію деяких процесів.

Процес «Вести облік за індивідуальними маршрутними листами»:

— Вивести на екран індивідуальні маршрутні листи провідників.

— Додати запис про провідника у базу даних.

— Змінити запис про провідника у базі даних.

— Вилучити запис про провідника з бази даних.

Процес «Вести облік бригадних маршрутних листів»:

— Вивести на екран бригадні маршрутні листи.

— Додати запис про бригаду у базу даних.

— Змінити запис про бригаду у базі даних.

— Вилучити запис про бригаду з бази даних.

Процес «Вести облік бригад»:

— Вивести на екран бригади.

— Додати запис про номер та склад бригади в базу даних.

— Змінити запис про номер та склад бригади в базі даних.

— Вилучити запис про номер та склад бригади з бази даних.

Процес «Вести облік добового розрахунку»:

— Вивести на екран добовий розрахунок поїздним бригадам.

— Додати запис у добовий розрахунок до бази даних.

— Змінити запис в добовому розрахунку в базі даних.

— Вилучити запис в добовому розрахунку з бази даних.

Процес «Вести облік табелів провідників»:

— Вивести на екран табелі провідників.

— Додати запис у табель провідника в базу даних.

— Змінити запис у табелі провідника в базі даних.

— Вилучити запис у табелі провідника з бази даних.

Таким чином, функціональність системи цілком визначена. Подальша декомпозиція процесів приведе до опису алгоритмів роботи окремих програмних модулів, що входять до складу програмного забезпечення системи.

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

Структура мобільного робочого місця:

— реляційна база даних;

— web-доступ до бази даних.

Функціонал МРМ «Нарядчик поїзних бригад»:

— облік користувачів;

— облік індивідуальних маршрутних листів;

— облік бригадних маршрутних листів;

— облік бригад;

— облік добового розрахунку робочого часу поїздним бригадам;

— облік табелів провідників;

— перегляд провідниками індивідуальних маршрутних листів та табелів;

— побудова прогнозу щодо виконання норми годин на квартал;

— функції, які виконує адміністратор сайту: управління структурою БД та налаштування авторизації користувачів.

Отже, користувачами системи є адміністратор, нарядчики пасажирської вагонної дільниці та провідники.

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

Доступ до будь-яких даних у системі МРМ «Нарядчик поїзних бригад» відбувається вибіркою даних із джерел даних з використанням логіна, табельного номеру та паролю. Табельний номер адміністратор сайту заздалегідь заносить до бази даних та вказує права користувача. Таким чином, при відсутності табельного номера неможливо отримати необхідні дані.

З аналізу функціональної моделі системи можна побудувати концептуальну модель даних системи.

Найбільш розповсюдженим засобом представлення концептуальної моделі даних є діаграми «сутність-зв'язок» (ERD). З їхньою допомогою визначаються важливі для предметної області об'єкти (сутності), їхні властивості (атрибути) і відносини один з одним (зв'язки). ERD безпосередньо використовуються для проектування реляційних баз даних.

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

Перший крок побудови концептуальної моделі даних — виділення сутностей.

Можна виділити наступні сутності:

— Користувачі.

— Індивідуальні маршрутні листи.

— Бригадні маршрутні листи.

— Бригади.

— Члени бригади.

— Добовий розрахунок часу поїздним бригадам.

— Напрямок.

— Норма.

— Табель провідника.

Наступний крок побудови моделі - ідентифікація атрибутів.

Атрибутами сутностей є:

Сутність «Користувачі».

— Код користувача.

— Логін.

— Хеш-код паролю.

— ФІО.

— Табельний номер.

— Посада (права).

Сутність «Індивідуальні маршрутні листи».

— Код індивідуального маршрутного листа.

— ПІБ.

— Явка.

— Потяг.

— Напрям.

— Уход.

— Номер вагону.

— Норма.

— Хвостовий.

Сутність «Бригадні маршрутні листи».

— Код бригади.

— Номер бригади.

— Начальник потягу.

— Потяг.

— Напрям.

— Явка.

— Уход.

Сутність «Бригади».

— Код бригади.

— Номер бригади.

— Табельний номер.

— Начальник потягу.

Сутність «Члени бригади».

— Код бригади.

— Код члена бригади.

— Табельний номер.

— ПІБ члена бригади.

Сутність «Добовий розрахунок часу поїздним бригадам».

— Код календаря.

— ПІБ.

— Номер потягу.

— Напрямок.

— Явка.

— Уход.

— Норма.

— Стартова поїздка.

— Всього.

— Перша доба.

— Друга доба.

— Третя доба.

— Четверта доба.

— П'ята доба.

— Шоста доба.

— Сьома доба.

Сутність «Напрямок».

— Код напрямку.

— Напрямок.

Сутність «Норма».

— Код норми.

— Норма.

Сутність «Табель провідника».

— Код провідника.

— ПІБ.

— Напрям.

— Норма.

— 1-й день першого місяця.

— 31-й день першого місяця.

— 1-й день другого місяця.

— 30-й день другого місяця.

— 1-й день третього місяця.

— 31-й день третього місяця.

— Стартова поїздка.

— Код добового розрахунку.

З урахуванням наявної інформації побудуємо ER-діаграму (рис. 2.2) у нотації IE (Information Engineering).

Зв’язок «Користувачі є членами бригад».

Опис: користувач може входити до складу членів бригад. Але може і не входити.

Сутність 1: «Користувач».

Сутність 2: «Члени бригад».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: може входити до; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: складається з; мін., макс.: 1, n.

Зв’язок «Члени бригад входять до бригад».

Опис: кожен член бригади входить до складу бригади.

Сутність 1: «Члени бригади».

Сутність 2: «Бригади».

Відношення: багато до багатьох.

Сутність 1 > Сутність 2; роль: може входити до; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: складається з; мін., макс.: 1, n.

Рис. 2.2. Концептуальна модель даних Зв’язок «Бригади мають бригадні маршрутні листи».

Опис:кожна бригада має бригадний маршрутний лист.

Сутність 1: «Бригади».

Сутність 2: «Бригадні маршрутні листи».

Відношення: Один до одного.

Сутність 1 > Сутність 2; роль: мають; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: належать; мін., макс.: 1, n.

Зв’язок «Бригадні маршрутні листи мають напрям».

Опис: кожен бригадний маршрутний лист має напрям.

Сутність 1: «Бригадні маршрутні листи».

Сутність 2: «Напрям».

Відношення:один до одного.

Сутність 1 > Сутність 2; роль: мають; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: належить; мін., макс.: 1, n.

Зв’язок «Члени бригад мають індивідуальні маршрутні листи».

Опис: кожен член бригади має свої індивідуальні маршрутні листи.

Сутність 1: «Члени бригад».

Сутність 2: «Індивідуальний маршрутний лист».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: належить до; мін., макс.: 1, n.

Зв’язок «Індивідуальні маршрутні листи мають норму».

Опис: кожен індивідуальний маршрутний лист може мати норму.

Сутність 1: «Індивідуальні маршрутні листи».

Сутність 2: «Норма».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: належить до; мін., макс.: 1, n.

Зв’язок «Індивідуальні маршрутні листи мають напрям».

Опис: кожен індивідуальний маршрутний лист може мати напрям.

Сутність 1: «Індивідуальні маршрутні листи».

Сутність 2: «Напрям».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 0, n.

Сутність 2 > Сутність 1; роль: належить до; мін., макс.: 1, n.

Зв’язок «Члени бригади мають добовий розрахунок часу».

Опис: Деякі члени бригади (провідники) мають добовий розрахунок робочого часу.

Сутність 1: «Члени бригади».

Сутність 2: «Добовий розрахунок робочого часу».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: належить; мін., макс.: 1, 1.

Зв’язок «Добовий розрахунок часу має норму».

Опис: У добовому розрахунку робочого часу поїздним бригадам вказується норма.

Сутність 1: «Добовий розрахунок часу».

Сутність 2: «Норма».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: вказується у; мін., макс.: 1, 1.

Зв’язок «Добовий розрахунок часу має напрям».

Опис: У добовому розрахунку робочого часу поїздним бригадам вказується напрям, за яким працюють провідники.

Сутність 1: «Добовий розрахунок часу».

Сутність 2: «Напрям».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: вказується у; мін., макс.: 1, 1.

Зв’язок «Добовий розрахунок часу має табель провідника».

Опис: На основі добового розрахунку робочого часу поїздним бригадам будуються табелі провідникам.

Сутність 1: «Добовий розрахунок часу».

Сутність 2: «Табель провідника».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: будує; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: відноситься; мін., макс.: 1, 1.

Зв’язок «Табель провідника має норму».

Опис: У добовому розрахунку робочого часу вказується норма.

Сутність 1: «Табель провідника».

Сутність 2: «Норма».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: відноситься; мін., макс.: 1, 1.

Зв’язок «Табель провідника має напрям».

Опис: У табелі провідника вказується напрям.

Сутність 1: «Табель провідника».

Сутність 2: «Напрям».

Відношення: один до одного.

Сутність 1 > Сутність 2; роль: має; мін., макс.: 1, 1.

Сутність 2 > Сутність 1; роль: відноситься; мін., макс.: 1, 1.

Виходячи з аналізу концептуальної моделі даних системи, розробимо логічну структуру бази даних. Логічна структура бази даних системи представлена на рисунку 2.3.

Рис. 2.3. Логічна структура бази даних системи Розробимо фізичну структуру кожної таблиці, що входить у базу даних. Типи даних будемо вказувати для СУБД My SQL Server.

При описі фізичних таблиць бази даних використані стандартні позначення ключів:

— PK (первинний ключ).

— ALT (альтернативний ключ).

— FK (зовнішній ключ).

Усі таблиці бази даних знаходяться в 1 нормальній формі (НФ), якщо вони є двовимірними, не містять полів, що включають кілька значень, і порожніх ключових полів (PK).

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

Структура фізичної таблиці «Користувачі» представлена в таблиці 2.2. Таблиця «Користувач» знаходиться в 3 НФ, оскільки дані полів, що не входять у первинний ключ, не залежать один від одного. Структура фізичної таблиці «Індивідуальні маршрутні листи» представлена в таблиці 2.3. Таблиця «Індивідуальні маршрутні листи» знаходиться в 3 НФ, оскільки дані полів, що не входять у первинний ключ, не залежать один від одного.

Структура фізичної таблиці «Бригадні маршрутні листи» представлена в таблиці 2.4. Таблиця «Бригадні маршрутні листи» знаходиться в 3 НФ, оскільки дані полів, що не входять у первинний ключ, не залежать один від одного.

Структура фізичної таблиці «Бригади» представлена в таблиці 2.5. Таблиця «Бригади» знаходиться в 3 НФ, оскільки дані полів, що не входять у первинний ключ, не залежать один від одного.

Структура фізичної таблиці «Члени бригади» представлена в таблиці 2.6. Таблиця «Члени бригади» знаходиться в 3 НФ, оскільки дані полів, що не входять у первинний ключ, не залежать один від одного.

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

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

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

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

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

Таблиця 2.2. Структура таблиці «Користувачі» / «Polzovateli»

Таблиця 2.3. Структура таблиці «Індивідуальні маршрутні листи» / «Individ_marsh_listy»

Таблиця 2.4. Структура таблиці «Бригади» / «brigady»

Таблиця 2.5. Структура таблиці «Члени бригади» / «chleny_brigady»

Таблиця 2.6. Структура таблиці «Добовий розрахунок часу поїздним бригадам» / «Kalendar»

Таблиця 2.7. Структура таблиці «Напрямок» / «Napryamok»

Таблиця 2.8. Структура таблиці «Норма» / «Norma»

Для реалізації проекту обрана наступна конфігурація: HTML + CSS + JavaScript + PHP + MYSQL.

Мова розмітки сторінок HTML є простим і зручним інструментом для створення сторінок, за допомогою JavaScript зручно писати скрипти, без PHP сьогодні важко представити сучасні сайти, оскільки ця мова надає практично необмежені можливості програмування Web-сторінок.

У даній клієнтській частині системи керування Web-контентом планується розробити:

1) швидкодіючий алгоритм;

2) ефективний підхід до розробки;

3) простий, але зрозумілий інтерфейс;

4) різноманітні модулі;

5) надійну функціональність.

Інтерфейс повинен бути мінімізованим і зрозумілим. Суть полягає в заповненні необхідних форм і подальшої передачі запитів з подальшим виведенням сторінки.

Основним кроком при написані є створення бази даних для системи. База створюється вбудованими функціями панелі управління хостингом, інтерфейс представлений на рис. 2.4.

Рис. 2.4. Інтерфейс phpMyAdmin

Планується досягти високої швидкодії за рахунок мінімізації і простоти.

Оптимальним було б рішення використовувати кодування «UTF 8», що забезпечує підтримку майже всіх існуючих мов і кодує ASCII символи одним байтом, а національні алфавіти — кількома.

Для зручності користування сайтом, будуть відведені ролі. Керування доступом на основі ролей можна використовувати, щоб призначати користувачам права. Усі права визначаються ролями керування. Роль керування визначає, до чого користувач має доступ і які завдання може виконувати. Кожний користувач може використовувати лише ті вкладки та параметри, які дозволяє призначена йому роль:

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

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

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

Починати наповнення будь-якого веб-сайту слід з планування його інформаційної структури і створення інформаційної моделі. У даній системі існують три рівні організації інформації: «Розділи» — це великі — об'єднання, що складаються з категорій; «Категорії» — невеликіоб'єднання, що вміщають об'єкти; «Об'єкти контенту» — це — будь-який текст, файл, посилання які користувач хоче розмістити на веб-сторінці.

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

Категорії будуть створюватися адміністратором сайту. Так для розділу «Маршрутні листи» можна створити категорії «Індивідуальні маршрутні листи» і «Бригадні маршрутні листи»; для розділу «Графіки» -«Добовий розрахунок дня».

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

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

Щоб досягти всіх цих результатів, потрібно детальніше ознайомитися з системами управління, веб-орієнтованими мовами програмування та реляційними базами даних.

2.2 Характеристика використаних інструментальних засобів

Веб-орієнтовані мови програмування

Термін HTML (Hyper Text Markup Language) означає «мова маркування гіпертекстів «. Це поняття дуже широке, включає в себе Інтернет і локальні мережі, редактори, браузери, різноманітні програмні продукти, компакт-диски, навчальні курси, дизайн та багато іншого. HTML — своєрідна протилежність мовам програмування, відомим тільки фахівцям.

HTML давно перестав бути просто мовою програмування. Людина, яка вивчала цю мову, знаходить можливість робити складні речі простими способами і, головне, швидко, що в комп’ютерному світі не так вже й мало. Гіпертекст підходить для включення елементів мультимедіа в традиційні документи. Практично саме завдяки розвитку гіпертексту, більшість користувачів отримало можливість створювати власні мультимедійні продукти і поширювати їх на компакт-дисках. Такі інформаційні системи, виконані у вигляді набору HTML-сторінок, не вимагають розробки спеціальних програмних засобів, так як всі необхідні інструменти для роботи з даними (WEB-браузери) стали частиною стандартного програмного забезпечення більшості персональних комп’ютерів. Від користувача потрібно виконати тільки ту роботу, яка відноситься до тематики розроблюваного продукту: підготувати тексти, намалювати малюнки, створити HTML-сторінки і продумати зв’язок між ними.

HTML, як основа створення WEB-сторінок, має пряме відношення і до нового напряму образотворчого мистецтва — WEB-дизайн. Художнику в Інтернеті недостатньо просто намалювати красиві картинки, оригінальний логотип, створити новий фірмовий стиль. Він повинен ще помістити все це в Мережі, продумати зв’язок між WEB-сторінками, щоб все рухалося, відгукувалася на дію користувача, вражало уяву, викликало бажання створити що-небудь своє, оригінальне в цій області.

Перша версія HTML була розроблена в 1989 році Тімом Бенерс-Лі для популярного в минулому браузера Mosaic. Але в той час ні для мови, ні для браузера не знайшлося гідного застосування. У 1993 році з’явився HTML +, і ця версія також залишилася практично непоміченою. Початок широкого використання гіпертексту дала версія 2.0 яка, з’явилася в червні 1994 року. Це був рік зростання популярності WWW по всьому світу. Елементи, включені у версію 2, в більшості своїй використовуються донині. У версії 3.0 HTML, яка з’явилася через рік, була реалізована можливість промальовування математичних символів (знаків інтервалу, нескінченності, дробу, дужок і т.д.) за допомогою елементів мови. Під цю версію був розроблений браузер Arena. Але цей проект не отримав подальшого поширення.

У 1996 році з’явився HTML 3.2. Це було новаторське рішення, в специфікацію мови були введені фрейми, які стали тепер дуже популярні у розробників WEB-сторінок. Навіть зараз на основі цієї специфікації можна реалізувати цікаві дизайнерські рішення. Практично всі сучасні браузери підтримують версію 3.2, тому автори WEB-сторінок впевнені в працездатності всіх елементів.

Поряд з офіційними специфікаціями мови, які розроблялися організацією W3C (W3 Консорціум), компанії-виробники браузерів створювали власні елементи (розширення). Згодом, деякі з цих елементів, після отримання загального визнання включилися в специфікацію наступних версій мови. Новаторське рішення — фрейми, що не були включені в специфікацію 3.2. Але браузери підтримували фрейми і багато книг, присвячені HTML, містили опис фреймів без згадки про те, що це нестандартні елементи. У наслідку, фрейми стали стандартом де-факто. У версії 4 вони вже були включені на повній підставі. Еелементи APPLET і SCRIPT, необхідні для розширення HTML іншими програмними кодами версії 3.2, не зіграли тієї ролі, яку мали зіграти. Це пояснюється тим, що браузери різних версій по-різному інтерпретували програми на різних мовах JAVA, JAVASCKRIPT, Visual Basic (VBScript). В результаті не вдалося отримати достатньо надійний працюючий код, і дані мови використовувалися прихильниками HTML в основному для експериментів.

Офіційна специфікація HTML 4 (Dynamic HTML) з’явилася в 1997 році. У цей час вже було очевидно, що подальший розвиток гіпертексту буде здійснюватися за рахунок скрипт — програмування. Це виявилося ефективніше, ніж вводити в мову всі нові елементи. Що з’явилися в той час браузери (Netscape Navigator 4, Microsoft Internet Explorer 4 і ін) вже досить надійно інтерпретували програмний код (був встановлений певний рівень стандартизації). Однак проблеми у розробників ще залишилися. Як приклад можна відзначити, що багато скриптів починаються з визначення версії браузера, щоб потім використовувати той або інший фрагмент коду. На програміста лягає обов’язок тестування сторінок на всіх популярних браузерах.

В результаті, використання всіх можливостей Dynamic HTML стало спадком програмістів досить великих організацій, де є умови для розробки складних програм і всебічного їх тестування. Творцям особистих WEB-сторінок часом доводиться шукати компроміс між надійністю і новаторством, щоб отримати достатньо грамотний HTML-код.

CSS (англ. Cascading Style Sheets — каскадні таблиці стилів) — формальна мова опису зовнішнього вигляду документа, написаного з використанням мови розмітки.

Переважно використовується як засіб опису, оформлення зовнішнього вигляду веб-сторінок, написаних за допомогою мов розмітки HTML і XHTML, але може також застосовуватися до будь-яких XML-документами, наприклад, до SVG або XUL.

CSS використовується творцями веб-сторінок для завдання кольорів, шрифтів, розташування окремих блоків та інших аспектів представлення зовнішнього вигляду цих веб-сторінок. Основною метою розробки CSS було розділення опису логічної структури веб-сторінки (яка проводиться за допомогою HTML або інших мов розмітки) від опису зовнішнього вигляду цієї веб-сторінки (яке тепер проводиться за допомогою формальної мови CSS). Такий поділ може збільшити доступність документа, надати велику гнучкість і можливість управління його поданням, а також зменшити складність і повторюваність в структурному вмісті. Крім того, CSS дозволяє представляти один і той же документ в різних стилях або методах виведення, таких як екранне уявлення, друковане подання, читання голосом (спеціальним голосовим браузером або програмою читання з екрану), або при виведенні пристроями, що використовують шрифт Брайля.

Найбільш повно підтримуючими стандарт CSS є браузери, що працюють на двигунах Gecko, WebKit (Safari, Arora) і Presto (Opera).

Колишній колись найпоширеніший браузер Internet Explorer 6 підтримує CSS далеко не повністю. Internet Explorer 7 хоча і значно поліпшив рівень підтримки CSS, але все ще містить значну кількість помилок.

В Internet Explorer 8 використовується новий движок, який повністю підтримує CSS 2.1 і частково — CSS 3.

Для перевірки підтримки браузером веб-стандартів (у тому числі і різних частин стандарту CSS) був розроблений тест Acid. Його друга версія називається Acid2, а третя, відповідно, Acid3.

Основні переваги CSS перед HTML:

— управління дизайном будь-якої кількості документів за допомогою однієї таблиці стилів;

— більш точний дизайн сторінок, підтримуваний всіма браузерами;

— поділ документа на дві складові: структура та дизайн, завдяки чому вихідний код стає чистим і легко читається;

— нові розширені можливості порівняно із звичайним html.

PHP (англ. PHP: Hypertext Preprocessor — «PHP: препроцесор гіпертексту»; спочатку Personal Home Page Tools — «Інструменти для створення персональних веб-сторінок»; вимовляється пі-ейч-пі) — скриптова мова програмування загального призначення, інтенсивно застосовується для розробки веб-додатків. В даний час підтримується переважною більшістю хостинг-провайдерів і є одним з лідерів серед мов програмування, що застосовуються для створення динамічних веб-сайтів.

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

У 1994 році датський програміст Расмус Лердорф створив набір скриптів на Perl/CGI для висновку і обліку відвідувачів його онлайн-резюме, які оброблювали шаблони HTML-документів. Лердорф назвав набір Personal Home Page (Особиста Домашня Сторінка). Незабаром функціональності і швидкості Perl-інтерпретатора скриптів — перестало вистачати, і Лердорф розробив з використанням мови C новий інтерпретатор шаблонів PHP/FI (англ. Personal Home Page / Forms Interpreter — «Особиста Домашня Сторінка / Інтерпретатор форм»).

У 1997 році після тривалого бета-тестування вийшла друга версія обробника, написаного на C — PHP/FI 2.0. Її використовували близько 1% (приблизно 50 тисяч) всіх інтернет-доменів світу.

Версія PHP 3.0 піддалася значній переробці, що визначила сучасний вигляд і стиль мови програмування. У 1997 році два ізраїльські програмісти, Енді Гутманс і Зеєв Сураські, повністю переписали код інтерпретатора. PHP 3.0 був офіційно випущений в червні 1998 року.

Однією з найсильніших сторін PHP 3.0 була можливість розширення ядра додатковими модулями. Згодом, інтерфейс написання розширень привернув до PHP безліч сторонніх розробників, що працюють над своїми модулями. Це дало можливість PHP працювати з величезною кількістю баз даних, протоколів, підтримувати велике число API. Велика кількість розробників призвела до швидкого розвитку мови і стрімкого зростання її популярності. З цієї версії акронім php розшифровується як «PHP: hypertext Preprocessor», замість застарілого «Personal Home Page». До зими 1998 року, практично відразу після офіційного виходу PHP 3.0, Енді Гутманс і Зеєв Сураські почали переробку ядра PHP. У завдання входило збільшення продуктивності складних додатків і поліпшення модульності базису коду PHP. Новий движок, названий Zend Engine, успішно справлявся з поставленими завданнями і вперше був представлений в середині 1999 року. PHP 4.0, заснований на цьому движку і приніс з собою набір додаткових функцій. Офіційно вийшов в травні 2000 року. На додаток до поліпшення продуктивності, PHP 4.0 мав ще декілька ключових нововведень, таких як підтримка сесій, буферизація виводу, більш безпечні способи обробки вводиться користувачем, і декілька нових мовних конструкцій.

П’ята версія PHP була випущена розробниками 13 липня 2004. Зміни включають оновлення ядра Zend (Zend Engine 2), що істотно збільшило ефективність інтерпретатора. Введена підтримка мови розмітки XML. Повністю перероблені функції ООП, які стали багато в чому схожі з моделлю, яка використовується в Java. Зокрема, введено деструктор, відкриті, закриті і захищені члени і методи, остаточні члени і методи, інтерфейси і клонування об'єктів. У наступних версіях також були введені простори імен, замикання і цілий ряд досить серйозних змін, кількісно і якісно порівнянних з тими, які з’явилися при переході на PHP 5.0.

Шоста версія PHP розроблялася з жовтня 2006 року. Було безліч нововведень, як, наприклад, виключення з ядра регулярних виразів POSIX і «довгих» суперглобальних масивів, видалення директив safe_mode, magic_quotes_gpc і register_globals з конфігураційного файлу php.ini. Одним з основних нововведень повинна була стати підтримка Юнікоду. .Однак у березні 2010 року розробку PHP 6 було визнано безперспективною через складнощі з підтримкою Юнікоду. Вихідний код PHP 6 переміщений на гілку, а основною лінією розробки стала версія 5.4.

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

Популярність у галузі побудови веб-сайтів визначається наявністю великого набору вбудованих засобів для розробки веб-додатків. Основні з них:

— автоматичний витяг POST і GET-параметрів, а також змінних оточення веб-сервера в зумовлені масиви;

— взаємодія з великою кількістю різних систем управління базами даних (MySQL, MySQLi, SQLite, PostgreSQL, Oracle (OCI8), Oracle, Microsoft SQL Server, Sybase, ODBC, mSQL, IBM DB2, Cloudscape і Apache Derby, Informix, Ovrimos SQL, Lotus Notes, DB + +, DBM, dBase, DBX, FrontBase, FilePro, Ingres II, SESAM, Firebird / InterBase, Paradox File Access, MaxDB, Інтерфейс PDO);

— автоматизована відправка HTTP-заголовків;

— робота з HTTP-авторизацією;

— робота з cookies і сесіями;

— робота з локальними і віддаленими файлами, сокетами;

— обробка файлів, що завантажуються на сервер;

— робота з XForms.

В даний час PHP використовується сотнями тисяч розробників. Згідно з рейтингом корпорації TIOBE, що базується на даних пошукових системах, у грудні 2012 року PHP знаходився на 6 місці серед мов програмування. До найбільших сайтів, які використовують PHP, відносяться Facebook, Wikipedia і ін.

Входить в LAMP — поширений набір програмного забезпечення для створення та хостингу веб-сайтів (Linux, Apache, MySQL, PHP).

JavaScript. JavaScript — прототипна-орієнтована сценарна мова програмування. Є діалектом мови ECMAScript. JavaScript зазвичай використовується як вбудована мова для програмного доступу до об'єктів додатків. Найбільш широке застосування знаходить в браузерах як мова сценаріїв для додання інтерактивності веб-сторінок.

Основні архітектурні риси: динамічна типізація, слабка типізація, автоматичне керування пам’яттю, прототипне програмування, функції як об'єкти першого класу.

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

Назва «JavaScript» зареєстрована товарним знаком компанії Oracle Corporation.

У 1992 році компанія Nombas (згодом придбана Openwave) почала розробку вбудованої скриптової мови Cmm (Сі-мінус-мінус), яка, за задумом розробників, повинна була стати досить потужною, щоб замінити макроси, зберігаючи при цьому схожість з Сі, щоб розробникам не становило жодних труднощів вивчити нову мову. Головною відмінністю від Сі була робота з пам’яттю. У новій мові все управління пам’яттю здійснювалося автоматично: не було необхідності створювати буфери, оголошувати змінні, здійснювати перетворення типів. В усьому іншому мови були сильно схожі одна на однуо: зокрема, Cmm підтримувала стандартні функції і оператори Сі. Cmm була перейменована в ScriptEase, оскільки вихідна назва звучала надто негативно, а згадка в ній Сі «відлякувала» людей.

На основі цієї мови був створений пропрієтарний продукт CEnvi. Наприкінці листопада 1995 Nombas розробила версію CEnvi, впроваджувану у веб-сторінки. Сторінки, які можна було змінювати за допомогою скриптової мови, отримали назву Espresso Pages — вони демонстрували використання скриптової мови для створення гри, перевірки даних, що ввів користувач і створення анімації. Espresso Pages позиціонувалися як демоверсія, покликана допомогти уявити, що трапиться, якщо в браузер буде впроваджено мову Cmm. Працювали вони тільки в 16-бітовому Netscape Navigator під управлінням Windows Перед Бренданом Айком, найнятим в компанію Netscape 4 квітня 1995, було поставлено завдання впровадити мову програмування Scheme або щось схоже в браузер Netscape. Оскільки вимоги були розмиті, Айка перевели в групу, відповідальну за серверні продукти, де він пропрацював місяць, займаючись поліпшенням протоколу HTTP. У травні розробник був перекинутий назад, в команду, що займається клієнтською частиною (браузером), де він негайно почав розробляти концепцію нової мови програмування. Менеджмент розробки браузера, включаючи Тома Пакін (Tom Paquin), Міхаеля Тоя, Ріка Шелла (Rick Schell), був переконаний, що Netscape повинен підтримувати мову програмування, що вбудовується в HTML-код сторінки.