Оргнізація доступу до інформації в гіпертекстових системах може бути забезпечена одним з таких трьох способів:

у початкових вузлах гіпертексту розміщується коротка таблиця змісту;

для перегляду інформації приймається спеціальна програма;

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

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

1987 року розробники з Університету Північної Кароліни (США) представили систему WЕ (А Wгіtіпg Епvігопmепt fог Ргоfеssіопаls).

В основу моделі системи WЕ покладено таку ідею: читання і пись­мо розглядаються як симетричні в цілому процеси, які у своїх стадіях змінюють їх за взаємопротилежною черговістю.

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

візуалізація мережі (сітки) для підтримки ранньої стадії створен­ня тексту ("мозкового штурму");

вікна ієрархій для подальшої концептуальної організації.

У третьому вікні користувач може редагувати текстові начерки у вузлах сітки.

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

НЕ нашли? Не то? Что вы ищете?

Система WЕ орієнтована на створення науково-технічних текстів.

Лабораторією «Сіменс» (Відень) розроблена система Нуреr Аuthог. В основу системи покладено підтримку трьох фаз авторського процесу:

ІДЕЇ,

ПЛАН,

ТЕКСТ.

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

Далі система дозволяє надати одержаній сітці ієрархічну органі­зацію. Для цього структура проблемної сфери упорядковується від «за­гального до окремого» (таксономією). Таксономія зберігається у ма­шині і розглядається як засіб навігації створеної сітки.

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

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

Система Нурег Аuthог побудована як додаток до комерційної гіпер-текстової системи Нурег Shell.

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

зберігання текстових і географічних документів;

можливість додавання s виключення документів;

автоматичне виділення ключових слів у тексті;

пошук документів за ключовими словами і за змістом документа;

перехід від текстового або графічного документа до зв'язаних з ним інших документів;

зв'язок документів з цифровими даними, побудова діаграм графіч­них документів.

ГІпертекстова система забезпечує легкість переходу від одного до­кумента до іншого. Але залишається ряд невирішених питань:

вручну роблять посилання у документах (відсутнє автоматичне індексування);

засоби пошуку дозволяють знаходити тільки такі слова і словоспо­лучення, які точно збігаються;

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

Для реалізації зазначених вимог s усунення недоліків в існуючих системах роботи з документами за рубежем стали створювати системи нового класу — системи «text management systems» ("системи уп­равління документацією"), в яких поєдналися різноманітні методи зберігання та обробки інформації.

У загальному випадку системи управління документацією забез­печують таке:

звичайний логічний пошук інформації за ключовими словами;

деякі системи дозволяють проводити пошук за зразком, який містить, крім букв, спеціальні символи (wilcards), наприклад «?» або «*»;

найбільш розвинені системи забезпечують пошук не лише задано­го слова, але і його синонімів або зв'язаних з ним за змістом слів;

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

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

користувач може вказувати, які слова не слід включати в індекс.

Системи управління документацією знаходять все ширше застосу­вання. Про це свідчить, наприклад, той факт, що 1992 року в США на персональних комп'ютерах працювало від 80 до 100 тисяч таких систем.

Контрольні запитання

1.  Рівні управління проектуванням інформаційних систем

2.  Склад тимчасового колективу по розробці інформаційних систем

3.  Контур управління

4.  Види документів та їхнє призначення.

5.  Охарактеризуйте операції традиційної (ручної) розробки проек­тної документації.

6.  Які Існують способи автоматизованого зберігання і обробки тек­стових документів?

7.  Основні функції АСТД.

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

12.1. Загальна характеристика елементного підходу
до створення інформаційної системи

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

Більш ефективним є шлях, коли при розробці систем чи їх частин враховується можливість їх використання для певних груп об’єктів: підрозділів, підприємств, галузей тощо. Такі проектні рішення можуть бути прийняті єдиними чи використовуватися як типові. Склад, галузь застосування чи інші характеристики можуть бути прийняті у вигляді відповідних стандартів підприємства, галузі, державних стандартів чи керівних методичних матеріалів. Такими стандартизованими типовими елементами є ЄСКК ТЕІ, ЄСКД, ЄСТД, створені уніфіковані системи планової, облікової, звітної, фінансової та іншої документації.

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

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

2) побудова єдиних схем обміну даними між системою і користувачами;

3) використання єдиних форм документів і повідомлень, які пристосовані для людей і ЕОМ;

4) забезпечення універсальності засобів відображення виробничо-господарської діяльності.

Перші проектні рішення з’явилися в 1971–1975 рр. на основі тих можливостей і досягнень, які були на той час в області постановок і типізації задач і їх програмних модулів в умовах застосування ЕОМ другого покоління. При розробці ТПР створювалась проектна документація з усіх видів забезпечення, яка уможливлювала виконувати створення ІС методом агрегування її з оригінальною проектною документацією, що відбивала специфіку об’єкта. Потім були розроблені друге й третє покоління ТПР.

Усе це викладено в галузевих керівних методичних матеріалах по створенню АСУВ і її частин і в ряді монографій і підручників.

До ТПР висуваються такі вимоги:

вони мають забезпечувати можливість об’єднування в єдину систему при незначних витратах на прив’язування до конкретного об’єкта;

допускати приріст системи за рахунок нових рішень, які стають типовими.

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

Усі ТПР поділяються на 5 класів.

1. Спеціальне програмне забезпечення «Задача».

2. Загальне програмне забезпечення.

3. Техніка (за складом, розміщенням і порядком використання КТЗ).

4. Інформаційна база ( по інформаційній базі).

5. Посадові й технологічні інструкції «Персонал» (які регламен-тують дії посадових осіб органів управління при функціонуванні ІС).

ТПР класу «Задача» розроблюють для конкретних процесів управління об’єктом. Документація містить опис постановки задачі, алгоритм розв’язання, програмні модулі з їх описами та інструкціями по застосуванню. Кожне ТПР може будуватися за модульним принципом, де модулі можуть мати декілька варіантів рішення. Це забезпечує гнучкість ТПР, що дозволяє прив’язувати документацію до різних об’єктів після простого налагодження. ТПР можуть бути галузевими і міжгалузевими. ТПР прогресивно впливали і впливають на розвиток методів створення ІС. Ця технологія скорочує трудові затрати на створення проекту в середньому приблизно на 30 % (, Машинный синтез АСУП. – М.: Статистика, 1980. – 222 с.). Проте досвід показує, що з усіх компонентів системи, можливо, потрібно буде доробляти до 40 % документації.

Загальні недоліки типового (елементного) проектування такі:

1) відсутність єдиної інформаційної бази і, як наслідок, інформа-ційної ув’язки по всій системі;

2) відсутність альтернативних рішень по окремих елементах і задачах, що практично зумовлює необхідність розробки оригінальних рішень по цих функціях;

3) відсутність єдиної ідеології побудови програм по всіх функціональних задачах;

4) ускладнене компонування окремих елементів у систему;

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

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

7) відсутність засобів машинного ведення проектно-технологічної документації і координації розробників ІС;

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41