3. Практичні міркування (Practical Considerations)

Конструювання - діяльність, в рамках якої програмне забезпечення наводиться до угоди з довільними (іноді - хаотичними) обмеженнями реального світу, які вимагають від програмного забезпечення точного дотримання їх. Наближаючись до обмежень реального світу, конструювання (більшою мірою, ніж будь-яка інша область знань) ведеться на основі практичних міркувань і технік. 3.1 Проектування в конструюванні (Construction Design)

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

3.2 Мови конструювання (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-формування нової категорії нотацій, угод і змішаних типів мовних засобів, призначених для конструювання програмного забезпечення як природного продовження проектування.