Формалізація процесу проектування (стр. 2 из 2)

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

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

Рис.4.2 Модель процесу виробництва

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

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

Рис.4.3 Модель середовища проектування

Любий процес проектування може встановлювати зв'язок з будь-яким процесом середовища проектування і запитувати створення нового підлеглого процесу (рис.4.3).

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

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

6. Загальна схема процесу проектування

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

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

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

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

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

Таким чином, розглянута вище організація процесу проектування дозволяє виділити його істотні компоненти, їхнє створення, взаємозв'язок, визначити підходи до реалізації.

САПР, побудована по зазначеній схемі, повинна мати:

засоби аналізу;

способи чи рекомендації проведення проектних перетворень;

пакети програм по реалізації методики рішення різних ЧЗП;

сценарій загальної технологічної (операторно-інформаційної) схеми проектування;

банк даних для роботи з базами підпроектов, вихідних і нормативно-довідкових даних, сценаріїв окремих ПЗП;

діалогову систему організації загального сценарію і сценаріїв ПЗП;

монітор організації паралельних процесів проектування;

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

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

1) побудувати граф проробки, вершини якого відображають формування й аналіз рішень по компонентах системи, а дуги - вершини за інформацією і послідовності розвитку загальносистемного проектування (ОСП) за часом;

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

3) вирішити поставлені вище задачі пророблення компонент системи (прохід "знизу нагору").

7. Схема проектування апаратно-програмного комплексу інформаційно-обчислювальної системи

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

Методологічна схема має три рівні деталізації.

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

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

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

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