Процес трансформації проекту в програму має кілька поширених назв: кодування (coding), програмування (programming), реалізація (implementation). Наявність синонімів є наслідком не лише неузгодженості в термінології, а, мабуть, і тієїобставини, що кожний з термінів значною мірою відбиває певний аспект того процесу, про який ми ведемо мову в цьому розділі. Справді, потрібно виконати конструювання, визначивши складові системи як програмні модулі; потрібно запрограмувати ці модулі обраною мовою програмування, для чого слід не лише перевести нотації проекту в коди обраного засобу програмування, а й провести тестування та верифікацію отриманих кодів. А в цілому потрібно перетворити проект на працюючу програмну систему, документовану таким чином, щоб було зрозуміло, як її використовувати, інакше кажучи реалізувати програмну систему. Для певності далі будемо вживати термін реалізація.
Реалізація є першою із стадій життєвого циклу, внаслідок якої артефакти, створені людиною на попередніх стадіях, трансформуються в артефакти, які буде передано комп’ютеру, і тому мають бути для нього однозначно зрозумілими. Така трансформація потребує активного діалогу між особою, котра розуміє проект, і комп’ютером, який має трактувати відповідну до проекту реалізацію. Одна із сторін діалогу є людиною з непередбачуваною поведінкою, прихильністю до замовчування того, що вона має за "загальновідоме", до забудькуватості та нечіткого формулювання, інша є абсолютно педантичним комп’ютером-виконавцем.
Під час перетворення проекту на працюючу систему робиться цілий ряд уточнень та формалізацій, у процесі яких програміст трансформує свої знання в зрозумілі комп’ютеру артефакти і деталізує ті можливі варіанти, які передбачено проектом. При цьому програміст має подивитись з точки зору комп’ютера, щоб зрозуміти, що він уміє і знає з того, що не обумовлено в проекті. Вміння та знання комп’ютера визначаються сукупністю інструментальних засобів, які доступні програмістові. Нині це досить широкий спектр мов програмування, генераторів програм, бібліотек об’єктних модулів, класів, функцій тощо. Тож програміст має знати все або більшість з того, що знає комп’ютер (принаймні готові напрацювання, придатні для його проблемної галузі), щоб зробити правильний вибір потрібних інструментальних засобів та готових компонент, створити ті компоненти, яких не вистачає, а також інтегрувати все в працюючу систему. Прийняття рішення про використання тих чи інших готових компонент може привести до суттєвих змін в архітектурі проекту.
З іншого боку, обрання певного інструментального засобу визначає стилістичний напрям процесу реалізації. Можна назвати три поширені стилістичні напрями:
-лінгвістичний стиль, коли програма має вигляд текстів, наближених до натуральної мови і тому звичних для більшості користувачів;
- математичний стиль, коли шляхом математичного чи логічного розмірковування можна досить точно висловити свої потреби, оскільки семантику математичних та логічних виразів точно встановлено. На жаль, цей стиль може бути застосовано лише для вузького кола добре сформульованих завдань із чітким і зрозумілим механізмом абстракції. Крім того, володіння таким стилем доступне лише відносно вузькому колу фахівців зі спеціальною освітою;
- візуальний стиль, коли для наочного уявлення взаємодії об’єктів системи активно використовуються зорові образи.
Слід зазначити, що тенденції розвитку інструментальних засобів розроблення програм є такими, щоб інтегрувати всі три стилі в одній розробці. Зокрема це стосується візуальних мов програмування (JAVA і под.).
Вибір і використання готових інструментів та компонент має свою специфіку в програмній інженерії, висвітленню якої присвячено розділ 7.
Контрольні запитання і завдання
1. У чому суть трансформації програмного проекту в програму.
2. Чи визначає сукупність наявних інструментальних засобів можливі напрями реалізації?
