Мови конструювання (Construction Languages)

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

Найпростіший тип мов конструювання - конфігураційний мова (configuration language), що дозволяє задавати параметри виконання програмної системи.

Інструментальний мова (toolkit language) - мова конструювання з повторно-використовуваних елементів; зазвичай будується як сценарний мова (script), що здійснюється у відповідному середовищі.

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

• лінгвістична

• формальна

• візуальна

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

Використання візуальних конструкцій обмежено складністю візуального представлення складних висловів та тверджень тільки за рахунок переміщення візуальних сутностей на діаграмі (візуальному представленні). Однак, візуальна нотація може грати роль досить потужного інструменту, коли застосовується в тих завданнях програмування, де необхідна побудова інтерфейсу для програм, чия логіка. Деталізоване поведінка визначено раніше.
Сьогоднішні роботи (і їх стан) в області архітектур і додатків, керованих моделями, в першу чергу - OMG MDA (Model-Driven Architecture www.omg.org / mda) / UML (Unified Modeling Language www.omg.org / uml), Microsoft DSL (Domain-Specific Language), спрямовані на те, щоб використовувати ту чи іншу візуальну нотацію, що базується на мета-моделях, як інструмент, що застосовується і для визначення функціональної логіки системи. Чи можна в чистому вигляді вважати ці нотації саме візуальними - питання спірне. Але в термінах, пропонованих SWEBOK, вони відносяться саме до візуальних нотаціям, так як припускають однозначну інтерпретацію візуального представлення у вигляді тексту і навпаки. Крім того, історично ці нотації визначалися спочатку як нотації візуального представлення функціональності і вже надалі ці візуальні уявлення були відображені на цровне відповідних мета-моделей (хоча це більшою мірою вірно для UML, ніж DSL, але DSL можна розглядати і як аналог UML, передбачає більшу свободу застосувань та інтегрованість з конкретною платформою - Microsoft). Інша область стандартів, спрямованих на застосування візуальних нотацій для опису функціональності - Business Process Management Notation (BPMN - www.omg.org / bpmn) і пов'язаний з нею мову Business Process Execution Language, побудований на базі XML. Таким чином, район обгрунтованого застосування візуальних нотацій для конструювання програмних систем якісно розширитися і, не виключено, ми станемо свідками de facto-формування нової категорії нотацій, угод і змішаних типів мовних засобів, призначених для конструювання програмного забезпечення як природного продовження проектування.

 

Кодування (Coding)

Практика конструювання програмного забезпечення показує активне застосування таких міркувань і технік:

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

• використання класів, що перераховуються типів, змінних, іменованих констант та інших виразних сутностей;

• організація вихідного тексту (у вирази, шаблони, класи, пакети / модулі та інші структури)

• використання структур управління;

• обробка помилкових умов і виняткових ситуацій

• запобігання можливих проломів в безпеці (наприклад, переповнення буфера або вихід за межі індексу в масиві)

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

• документування коду

• тонка "настройка" коду

• рефакторинг (не згадується SWEBOK)

 

3.4 Тестування в конструюванні (Construction Testing)

При конструюванні використовуються дві форми тестування, проведеного інженерами, безпосередньо створюють вихідний код:

• модульне тестування (unit testing)

• інтеграційне тестування (integration testing)

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

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

IEEE опублікував два стандарти, присвячених даній темі:

• IEEE Std 829-1998: "IEEE Standard for Software Test Documentation"

• IEEE Std 1008-1987: "IEEE Standard for Software Unit Testing"

Напряму з цією темою пов'язані під-теми SWEBOK 2.1.1 "Unit Testing" та 2.1.2 "Integration Testing".