НОРМАТИВНО И МЕТОДИЧЕСКО ОСИГУРЯВАНЕ НА СЪЗДАВАНЕТО НА АИС.
Основни понятия за проектиране на АИС
Най-общо AIS включва: потребител (потребител), информационни ресурси, информационни носители, средства за събиране, съхранение, обработка на информация, средства за предаване на информация.
Дизайнът на AIS се основава на два взаимосвързани компонента:
Стандарти за проектиране;
Методика на проектиране.
Основните концепции, подходи и дефиниции на дизайна на AIS се регулират от три вида проектна и софтуерна документация:
- единна система за проектна документация (ESKD);
- единна система за програмна документация (ЕСПД);
- набор от насоки за AIS.
Съставът на проектната документация е набор от стандарти и насоки за AIS GOST 24.104-85, GOST 34.003-90, GOST 34.201-90 включва насоки за информационни технологии и автоматизирани системи, както и изисквания за съдържанието на документите.
Целта на проектирането е да се идентифицира сравнително проста вътрешна структура, наречена архитектура на системата.
AIS се разработва като проект. Много характеристики на управлението на проекти и фазите на разработване на проекти (фази на жизнения цикъл) са общи, независими не само от предметната област, но и от естеството на проекта. Понятието проект е сложно понятие и е трудно да се намери еднозначна формулировка за него.
Проект- това е ограничена във времето целенасочена промяна на отделна система с първоначално ясно определени цели, чието постигане определя завършването на проекта, както и с установени изисквания за срокове, резултати, риск, изразходване на средства и ресурси и организационни структура.
За икономическисистеми по проекта EIS ще разбираме конструкторската и технологична документация, която описва проектните решения за създаване и работа на EIS в специфична софтуерна и хардуерна среда.
Под EIS проектсе отнася до процеса на преобразуване на входна информация за обекта на проектиране, методите на проектиране и опита в проектирането на обекти с подобна цел в съответствие с GOST в проект на EIS. От тази гледна точка проектирането на EIS се свежда до последователно формализиране на проектните решения на различни етапи от жизнения цикъл на EIS: планиране и анализ на изискванията, технически и детайлен проект, внедряване и експлоатация на EIS.
Дизайнерски обекти EIS са отделни елементи или техните комплекси от функционални и поддържащи части. По този начин функционалните елементи в съответствие с традиционната декомпозиция са задачи, комплекси от задачи и управленски функции. Като част от поддържащата част на EIS обектите на проектиране са елементите и техните комплекси от информационна, софтуерна и техническа поддръжка на системата.
като субектпроектиране на EIS са екипи от специалисти, които извършват дейности по проекта, като правило, като част от специализирана (проектантска) организация и клиентска организация, за която е необходимо да се разработи EIS. Мащабът на разработваните системи определя състава и броя на участниците в процеса на проектиране. При голям обем и кратки срокове за изпълнение на проектните работи, няколко дизайнерски екипа (разработващи организации) могат да участват в разработването на системата. В този случай се определя родителска организация, която координира дейностите на всички съизпълнители организации.
Формата на участие на съизпълнителите в разработването на системния проект може да бъде различна. Най-разпространената е формата, при която всеки сътрудник извършва проектантска работа от началото до края за част от разработваната система. Обикновено това е функционална подсистема или взаимосвързан набор от задачи за управление. По-рядко срещана е формата на участие на съизпълнители, при която отделни съизпълнители извършват работа на определени етапи от процеса на проектиране. Възможен е вариант, при който функциите на клиента и разработчика се комбинират, т.е. EIS се проектира самостоятелно.
Изпълнението на дизайна на EIS включва използването от дизайнерите на определена технология за проектиране, която съответства на мащаба и характеристиките на разработвания проект.
EIS технология за проектиране- това е набор от методология и инструменти за проектиране на EIS, както и методи и инструменти за организиране на дизайна (управление на процеса на създаване и модернизиране на EIS проект)
Методология (концепция + метод)
Организация на инструментите
проектиране инженерство
Технологията на проектиране се основава на технологичен процес, който определя действията, тяхната последователност, състава на изпълнителите, средствата и ресурсите, необходими за извършване на тези действия.
По този начин технологичният процес на проектиране на EIS като цяло е разделен на набор от последователно-паралелни, свързани и подчинени вериги от действия, всяка от които може да има свой предмет. Действията, които се извършват при проектирането на ДОВОС могат да бъдат определени като неделими технологични операции или като подпроцеси на технологични операции. Всички действия могат да бъдат всъщност проектни действия, които формират или модифицират резултатите от дизайна, и действия за оценка, които се разработват съгласно установените критерии за оценка на резултатите от дизайна.
По този начин технологията на проектиране се определя от регламентирана последователност от технологични операции, извършвани в процеса на създаване на проект въз основа на един или друг метод, в резултат на което ще стане ясно не само КАКВО трябва да се направи, за да се създаде проект, но също и КАК, НА КОГО и в КАКВА ПОСЛЕДОВАТЕЛНОСТ трябва да се направи.
Предметът на всяка избрана технология за проектиране трябва да бъде отразяването на взаимосвързани процеси на проектиране на всички етапи от жизнения цикъл на EIS.
Основните изисквания към избраната технология за проектиране включват следното:
Проектът, създаден с помощта на тази технология, трябва да отговаря на изискванията на клиента;
Избраната технология трябва максимално да отразява всички етапи от жизнения цикъл на проекта;
Избраната технология трябва да осигурява минимални разходи за труд и разходи за проектиране и поддръжка на проекта;
Технологията трябва да бъде в основата на комуникацията между дизайна и поддръжката на проекта;
Технологията трябва да допринася за повишаване на производителността на труда на дизайнера;
Технологията трябва да гарантира надеждността на дизайна и експлоатацията на проекта;
Технологията трябва да улесни лесното поддържане на проектната документация.
Основата на технологията за проектиране на EIS е методология, която определя същността, основните отличителни технологични характеристики.
Методология на проектиранепредполага наличието на някаква концепция, принципи на проектиране, реализирани чрез набор от методи за проектиране, които от своя страна трябва да бъдат подкрепени от някои инструменти за проектиране.
Организацията на проектиране включва дефинирането на методи за взаимодействие на дизайнерите помежду си и с клиента в процеса на създаване на EIS проект, който също може да бъде подкрепен от набор от специфични инструменти.
Методите за проектиране на EIS могат да бъдат класифицирани според степента на използване на средствата за автоматизация, стандартните дизайнерски решения и адаптивността към очакваните промени.
Да, според степента автоматизацияМетодите за проектиране са разделени на методи:
ръчен дизайн, при които проектирането на EIS компонентите се извършва без използването на специални софтуерни инструменти, а програмирането се извършва на алгоритмични езици;
компютърен дизайн, който произвежда генериране или конфигуриране (настройка) на дизайнерски решения въз основа на използването на специални софтуерни инструменти.
Според степента на използване на стандартните дизайнерски решения се разграничават следните методи за проектиране:
Оригинален (индивидуален) проект, когато проектните решения се разработват "от нулата" в съответствие с изискванията за ДОВОС;
Типово проектиране, което включва конфигурацията на EIS от готови типови проектни решения (софтуерни модули).
Оригиналният (индивидуален) дизайн на EIS се характеризира с това, че всички видове проектантска работа са насочени към създаването на индивидуални проекти за всеки обект, които отразяват в максимална степен всички негови характеристики.
Типовото проектиране се извършва въз основа на опита, натрупан при разработването на индивидуални проекти. Типичните проекти като обобщение на опита за определени групи организационни и икономически системи или видове работа във всеки случай са свързани с много специфични характеристики и се различават по степента на покритие на управленските функции, извършената работа и разработената проектна документация.
Според степента на адаптивност на проектните решения методите за проектиране се класифицират на методи:
Реконструкции, когато адаптирането на дизайнерските решения се извършва чрез обработка на съответните компоненти (препрограмиране на софтуерни модули);
Параметризация, когато проектните решения се коригират (регенерират) в съответствие с променящите се параметри;
Преструктуриране на модела, когато моделът на проблемната област се променя, въз основа на което автоматично се регенерират дизайнерски решения.
Комбинацията от различни характеристики на класификацията на методите за проектиране определя характера на използваната технология за проектиране на EIS, сред които се открояват две основни.
клас: канонични и индустриални технологии (Таблица 2.1). Технологията на индустриалния дизайн от своя страна се разделя на два подкласа: автоматизиран (използване на CASE технологии) и типичен (параметрично ориентиран или моделно ориентиран) дизайн. Използването на технологии за индустриален дизайн не изключва използването на канонична технология в някои случаи.
Таблица 2.1 Характеристики на класовете по технология на проектиране
За специфични видове технологии за проектиране е обичайно да се използват определени инструменти за разработка на EIS, които поддържат изпълнението както на индивидуална проектна работа, етапи, така и на техните комбинации. Следователно разработчиците на EIS като правило са изправени пред задачата да изберат инструменти за проектиране, които по отношение на техните характеристики най-добре отговарят на изискванията на конкретно предприятие.
Инструментите за проектиране трябва да бъдат:
В своя клас те са инвариантни спрямо обекта на проектиране;
Покрийте в съвкупност всички етапи от жизнения цикъл на EIS;
Технически, софтуерно и информационно съвместими;
Лесен за научаване и използване;
Икономически осъществимо.
Средствата за проектиране на EIS могат да бъдат разделени на два класа: без използването на компютър и с използването на компютър.
Инструментите за проектиране без използването на компютър се използват на всички етапи и етапи на проектиране на EIS. Като правило това са средства за организационна и методологична поддръжка на проектните операции и на първо място различни стандарти, които регулират процеса на проектиране на системата. Това включва и единна система за класифициране и кодиране на информацията, единна документационна система, модели за описание и анализ на информационните потоци и др.
Компютърно-подпомогнатите инструменти за проектиране могат да се използват както на отделни, така и на всички етапи и етапи от процеса на проектиране на EIS и съответно да подпомагат разработването на елементи на системния дизайн, раздели на системния дизайн и дизайна на системата като цяло. Целият набор от инструменти за проектиране, използващи компютри, е разделен на четири подкласа.
Първият подклас включва оперативни инструменти, които поддържат проектирането на операции за обработка на информация. Този подклас инструменти включва алгоритмични езици, библиотеки от стандартни подпрограми и обектни класове, макрогенератори, програмни генератори за типични операции по обработка на данни и др., както и инструменти за разширяване на функциите на операционните системи (помощни програми). Този клас включва и такива прости инструменти за проектиране като инструменти за тестване и отстраняване на грешки в програми, поддържане на процеса на проектна документация и т.н. Особеността на най-новите програми е, че те повишават производителността на дизайнерите, но не разработват цялостно дизайнерско решение.
По този начин инструментите от този подклас поддържат отделни операции по проектиране на EIS и могат да се използват независимо един от друг.
Вторият подклас включва инструменти, които поддържат дизайна на отделни компоненти на EIS проекта. Този подклас включва инструменти за цялата система:
Системи за управление на бази данни (СУБД);
Методоориентирани пакети от приложни програми (решаване на проблеми на дискретно програмиране, математическа статистика и др.)
Таблични процесори;
Статистически RFP;
Обвивки на експертни системи;
Графичен редактор;
Текстови редактори;
Интегриран PPP (интерактивна среда с вградени диалогови възможности, която ви позволява да интегрирате горния софтуер).
Изброените инструменти за проектиране се характеризират с използването им за разработване на технологични подсистеми на EIS: въвеждане на информация, организиране на съхранение и достъп до данни, изчисления, анализ и показване на данни, вземане на решения.
Третият подклас включва инструменти, които поддържат проектиране на секции на проекта за ДОВОС. В този подклас разпределете функционални инструменти за проектиране.
Функционалните инструменти са насочени към разработването на автоматизирани системи, които изпълняват функции, комплекси от задачи и задачи за управление. Разнообразието от предметни области генерира разнообразие от инструменти от този подклас, фокусирани върху вида на организационната система (промишлени, непромишлени зони), ниво на управление (например предприятие, цех, отдел, обект, работно място), функция на управление ( планиране, счетоводство и др.).
Функционалните средства за проектиране на системи за обработка на информация включват стандартни дизайнерски решения, функционални пакети от приложни програми, типови проекти.
Четвъртият подклас инструменти за проектиране на EIS включва инструменти, които поддържат развитието на проекта на етапите и етапите на процеса на проектиране. Този клас включва подклас инструменти за автоматизиране на дизайна на EIS (CASE-инструменти).
Съвременните CASE инструменти от своя страна се класифицират основно по два критерия:
1) по обхванатите етапи от процеса на разработване на ДОВОС;
2) според степента на интеграция: отделни локални инструменти (инструменти), набор от неинтегрирани инструменти, покриващи повечето от етапите на разработка на EIS (инструментариум) и напълно интегрирани инструменти, свързани с обща база данни за дизайн - хранилище (workbench) .
Дизайнът на AIS е творчески процес. Всеки проект преминава през определени състояния в своето развитие: от състояние, когато „все още няма проект“ до състояние, когато „проектът вече не съществува“. Наборът от етапи на развитие от възникването на идеята до завършването на проекта обикновено се разделя на етапи (фази, етапи). Има някои разлики в определянето на броя на етапите (фазите) и тяхното съдържание, но въпреки това същността на съдържанието на жизнения цикъл на разработка на AIS при различните подходи е една и съща.
Етапи на развитие на CASE-системите
През последното десетилетие се появи нова посока в проектирането на информационни системи - компютърно проектиране с помощта на CASE-инструменти. Терминът CASE (Computer Aided System/Software Engineering) първоначално се е отнасял само за автоматизация на разработката на софтуер; сега обхваща разработването на сложни AIS като цяло.
Първоначално CASE технологиите бяха разработени, за да се преодолеят недостатъците на методологията за структурно проектиране (сложност на разбиране, висока трудоемкост и цена на използване, трудности при извършване на промени в проектните спецификации и т.н.) чрез автоматизация и интегриране на поддържащи инструменти.
CASE-технологиите не съществуват сами по себе си, те не са независими. Те автоматизират и оптимизират използването на съответната методика и дават възможност за повишаване на ефективността на нейното прилагане.
С други думи, CASE технологииса набор от методологии за анализиране, проектиране, разработване и поддържане на сложни софтуерни системи, подкрепени от набор от взаимосвързани инструменти за автоматизация, които ви позволяват визуално да моделирате предметната област, да анализирате този модел на всички етапи на разработване и поддръжка на AIS и да разработвате приложения в съответствие с информационните нужди на потребителите.
Съвременните CASE инструменти покриват широка гама от поддръжка за множество технологии за проектиране на AIS - от прости инструменти за анализ и документиране до пълномащабни инструменти за автоматизация, покриващи целия жизнен цикъл на AIS. Най-голяма нужда от използването на CASE-системи има в началните етапи на разработката - на етапите на анализ и спецификация на изискванията за AIS. Допуснатите тук грешки са почти фатални, цената им далеч надхвърля цената на грешките в по-късните етапи на развитие.
Основните цели на CASE инструментите са да отделят началните етапи (анализ и проектиране) от следващите и да не натоварват разработчиците с подробности за средата за разработка и работата на системата.
Повечето съвременни CASE системи използват методологии структурени/или обектно-ориентиран анализИ дизайн,въз основа на използването на визуални диаграми, графики, таблици и диаграми.
При правилното използване на CASE-инструментите се постига значително увеличение на производителността на труда, което (според оценки на чуждестранни компании, използващи CASE технологии) е от 100 до 600%, в зависимост от обема, сложността на работата и опита с CASE. В същото време всички фази на жизнения цикъл на AIS се променят, но най-големите промени се отнасят до фазите на анализ и проектиране (Таблици 2.5, 2.6).
Таблица 2.5.Оценки на разходите за труд по фази от жизнения цикъл на АИС
Таблица 2.6.Сравнение на използването на CASE и традиционното развитие
Използването на CASE-инструменти не само автоматизира структурната методология и прави възможно използването на съвременни методи за системно и софтуерно инженерство, но също така предоставя други предимства (фиг. 2.22), по-специално:
1. подобрява качеството на разработвания софтуер чрез автоматично генериране и управление;
2. позволява да се намали времето за създаване на прототип на AIS, което дава възможност да се оцени качеството и ефективността на проекта на ранен етап;
3. ускорява процеса на проектиране и разработка;
4. ви позволява да използвате повторно разработените компоненти;
5. поддържа AIS проследяване;
6. освобождава от рутинната работа по документиране на проекта, тъй като използва вградения документатор;
7. Улеснява екипната работа по проект.
Ориз. 2.22.Предимства на разработването на AIS с помощта на CASE-технологии: А- коефициент на намаляване на разходите по проекта; б -коефициент на намаляване на времето за разработка
Повечето CASE инструменти се основават на четири основни концепции: методология, метод, нотация, инструмент [ 11,15, 16].
Методикаопределя насоки за оценка и избор на решения при проектиране и разработване на АИС, етапи на работа, тяхната последователност, правила за разпределение и възлагане на методите.
методи -процедури за генериране на компоненти и техните описания.
Нотацииса предназначени да опишат общата структура на системата, елементи от данни, стъпки на обработка, могат да включват графики, диаграми, таблици, блок-схеми, формални и естествени езици.
съоръжения- инструменти за поддръжка и подобряване на методите; поддържа работата на потребителите при създаване и редактиране на проект в интерактивен режим, помага за организиране на проекта под формата на йерархия от нива на абстракция, проверява съответствието на компонентите.
Класификация на CASE инструменти
Досега няма стабилна класификация на CASE-инструментите, дефинирани са само подходи за класификация в зависимост от различни класификационни характеристики. По-долу са някои от тях.
Ориентация към технологичните етапи и процеси от жизнения цикъл на АИС:
1. средства за анализ и дизайн. Използва се за създаване на системни спецификации и дизайн. Те поддържат добре познати методологии за проектиране;
2. инструменти за проектиране на бази данни. Осигурява логическо моделиране на данни, генериране на структури от бази данни;
3. инструменти за управление на изискванията;
4. инструменти за управление на конфигурацията на софтуера. Поддръжка на програмиране, тестване, автоматично генериране на софтуер от спецификации;
5. средства за документиране;
6. инструменти за тестване;
7. инструменти за управление на проекти. Подкрепа за планиране, контрол, взаимодействие;
8. инструменти за обратно инженерство, предназначени за прехвърляне на съществуваща система в нова среда.
Поддържани методологии за проектиране[ 11, 12, 15, 16]:
1. функционално ориентирани (структурно ориентирани);
2. обектно ориентирани;
3. комплексно ориентирани (набор от методологии за проектиране).
Поддържани означения за графични диаграми:
1. с фиксирана нотация;
2. с отделни означения;
3. с най-често срещаните означения.
Степен на интеграция:
1. помощни програми (Tools), самостоятелно решаващи автономна задача;
2. пакети за разработка (Toolkit), които са набор от инструменти, които осигуряват помощ за един от класовете софтуерни задачи;
3. набори от интегрирани инструменти, свързани с обща проектна база данни - хранилище, автоматизираща цялата или част от работата на различните етапи на създаване на AIS (Workbench).
Колективно развитие на проекта:
1. без подкрепата на колективното развитие;
2. фокусиран върху развитието на проекта в реално време;
3. фокусирани върху начина на комбиниране на подпроекти.
Видове CASE инструменти:
1. инструменти за анализ (Upper CASE); сред специалистите се наричат средства за компютърно планиране. С помощта на тези CASE-инструменти се изгражда модел, който отразява всички съществуващи специфики. Тя е насочена към разбиране на общите и частни механизми на функциониране, наличните възможности, ресурси, целите на проекта в съответствие с целта на компанията. Тези инструменти ви позволяват да анализирате различни сценарии, натрупвайки информация за вземане на оптимални решения;
2. инструменти за анализ и проектиране (Middle CASE); се считат за подкрепа на анализа на изискванията и фазите на проектиране на спецификациите и структурата на AIS. Основният резултат от използването на среден CASE инструмент е значително опростяване на системния дизайн, тъй като проектирането се превръща в итеративен процес на работа с изискванията на AIS. В допълнение средните CASE инструменти осигуряват бързо документиране на изискванията;
3. инструменти за разработка на софтуер (Долен); поддръжка на системи за разработка на софтуер AIS. Те съдържат системни речници и графични инструменти, които елиминират необходимостта от разработване на физически спецификации - има системни спецификации, които директно се превеждат в програмни кодове на разработваната система (до 80% от кодовете се генерират автоматично). Основните предимства на по-ниските CASE инструменти са значително намаляване на времето за разработка, улесняване на модификациите, поддръжка на възможността за работа с прототипи.
CASE инструментите също класифицират по вид и архитектура на компютърната технология,и по тип операционна система.
В момента пазарът на софтуерни продукти е представен от голямо разнообразие от софтуер, включително CASE-инструменти от почти всеки от изброените класове.
Характеристики на CASE инструментите
сребърен пробег.Инструментът Silverrun CASE на американската компания Computer Systems Advisers, Inc. (CSA) се използва за анализ и проектиране на AIS от бизнес клас и е фокусиран повече върху спиралния модел на жизнения цикъл. Приложим е за поддръжка на всяка методология, базирана на отделното изграждане на функционални и информационни модели (диаграми на потока от данни и диаграми на обекти-връзки).
Настройката към конкретна методология се осигурява чрез избор на необходимите графични обозначения на моделите и набор от правила за проверка на спецификациите на дизайна. Системата разполага с готови настройки за най-разпространените методологии: DATARUN (основната методология, поддържана от Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. За всяка концепция, въведена в проекта, е възможно да добавите свои собствени дескриптори. Архитектурата Silverrun ви позволява да разширите вашата среда за разработка според нуждите.
Silverrun има модулна структураи се състои от четири модула, всеки от които е самостоятелен продукт и може да се закупува и използва отделно.
1. Модул за изграждане на модели на бизнес процесипод формата на диаграми на потока от данни, Business Process Modeler (BPM) ви позволява да моделирате функционирането на автоматизирана организация или създавана AIS. Възможността за работа с модели с голяма сложност се осигурява от функциите за автоматично преномериране, работа с дървото на процеса (включително визуално плъзгане на клонове), отделяне и прикрепване на части от модела за колективно развитие. Диаграмите могат да се изготвят в няколко предварително дефинирани нотации, включително Yourdon/DeMarco и Gane/Sarson. Възможно е също така да създадете свои собствени обозначения, например да добавите дефинирани от потребителя полета към броя на дескрипторите, показани на диаграмата.
2. Модул за концептуално моделиране на данни Entity-Relationship eXpert (ERX) позволява изграждането на модели на данни за обекти-връзки, които не са специфични за изпълнението. Вградената експертна система ви позволява да създадете правилен нормализиран модел на данни, като отговаряте на смислени въпроси относно връзката на данните. Осигурено е автоматично изграждане на модел на данни от описания на структури от данни. Анализът на функционалните зависимости на атрибутите позволява да се провери съответствието на модела с изискванията на третата нормална форма и да се гарантира тяхното изпълнение. Валидираният модел се предава на модула Relational Data Modeler.
3. Модул за релационно моделиране Relational Data Modeler (RDM) ви позволява да създавате подробни модели обект-връзка, проектирани да бъдат внедрени в релационна база данни. Този модул документира всички структури, свързани с изграждането на база данни: индекси, тригери, съхранени процедури и т.н. Гъвкавата нотация и разширяемостта на хранилището ви позволяват да работите по всяка методология. Възможността за създаване на подсхеми е в съответствие с подхода на ANSI SPARC за представяне на схема на база данни. На езика на подсхемите се моделират както възли за разпределена обработка, така и потребителски изгледи. Този модул предоставя дизайн и пълна документация на релационни бази данни.
4. Мениджър на хранилище на работна група Workgroup Repository Manager (WRM) се използва като речник на данни за съхраняване на информация, обща за всички модели, и също така осигурява интегриране на модулите Silverrun в единна среда за проектиране.
Предимството на инструмента Silverrun CASE е неговата висока гъвкавост и разнообразие от визуални инструменти за изграждане на модели, а недостатъкът е липсата на строг взаимен контрол между компонентите на различните модели (например възможността за автоматично разпространение на промените между DFD на различни нива на разлагане). Трябва да се отбележи обаче, че този недостатък може да бъде значителен само ако се използва каскадният модел на жизнения цикъл.
Инструменти, включени в Silverrun:
1. автоматично генериране на схеми на бази данни за най-разпространените СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. трансфер на данни към инструменти за разработка на приложения: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
По този начин е възможно напълно да се дефинира машината на базата данни, като се използват всички характеристики на конкретна СУБД: тригери, съхранени процедури, ограничения за референтна цялост. При изграждането на приложение данните, мигрирани от хранилището на Silverrun, се използват или за автоматично генериране на интерфейсни обекти, или за бързото им създаване ръчно.
За обмен на данни с други инструменти за автоматизация на дизайна, създаване на специализирани процедури за анализиране и проверка на спецификациите на дизайна и съставяне на специализирани отчети в съответствие с различни стандарти, Silverrun предоставя три начина за издаване на информация за дизайна към външни файлове.
1. Система за отчитане. Отчетите се извеждат в текстови файлове.
2. Система за износ/импорт. Задава се не само съдържанието на файла за експортиране, но и разделителите на записите, полетата в записите, маркерите за началото и края на текстовите полета. Такива файлове за експортиране могат да бъдат генерирани и качени в хранилището. Това прави възможен обмен на данни с различни системи: други CASE инструменти, СУБД, текстови редактори и електронни таблици.
3. Съхраняване на хранилището във външни файлове с достъп чрез ODBC драйвери. За достъп до данни от хранилище от най-често срещаните СУБД е възможно цялата информация за проекта да се съхранява директно във формата на тези СУБД.
Silverrun поддържа два начина за групова работа:
1) в стандартната версия за един потребител има механизъм за контролирано разделяне и обединяване на модели. Моделът може да бъде разделен на части и разпределен между няколко разработчици. След подробно проучване, частите отново се сглобяват в един модел;
2) мрежовата версия на Silverrun позволява паралелна групова работа с модели, съхранявани в мрежово хранилище, базирано на Oracle, Sybase или Informix DBMS. В същото време няколко разработчици могат да работят с един и същ модел, тъй като блокирането на обекти се извършва на ниво отделни елементи на модела.
Сладко Инструментът за разработка на приложения JYACC's Application Manager (JAM) е продукт на JYACC.Основната характеристика е съответствието с RAD методологията, тъй като JAM ви позволява бързо да внедрите цикъла на разработка на приложения, който се състои в генериране на следващата версия на прототипа на приложението , като вземете предвид изискванията, посочени в предишната стъпка, и го представете на потребителя.
JAM има модулна структура и се състои от следните компоненти:
1. системно ядро;
2. JAM/DBi - специализирани интерфейсни модули за СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и др.);
3. JAM/RW - модул за генериране на отчети;
4. JAM/CASEi - специализирани интерфейсни модули за CASE инструменти (JAM/CASE-TeamWork, JAM/CASE-Inno-vator и др.);
5. JAM/TPi - специализирани интерфейсни модули за мениджъри на транзакции (например JAM/TPi-Server TUXEDO и др.);
6. Jterm - специализиран емулатор на X-терминал.
Ядрото на системата е завършен продукт и може да се използва самостоятелно за разработка на приложения. Всички останали модули не са задължителни и не могат да се използват самостоятелно.
Ядрото на системата включва следните основни компоненти:
1. екранен редактор. Редакторът на екрана включва среда за разработка на екрана, хранилище на визуални обекти, собствен JAM DBMS - JDB, мениджър на транзакции, дебъгер, стилов редактор;
2. редактор на менюта;
3. набор от спомагателни съоръжения;
4. средство за производство на индустриална версия на приложението.
При използване на JAM разработването на външния интерфейс на приложението е визуален дизайн и се свежда до създаване на екранни форми чрез поставяне на интерфейсни структури върху тях и дефиниране на екранни полета за въвеждане/извеждане на информация. Дизайнът на интерфейса в JAM се извършва с помощта на екранен редактор.Приложенията, разработени в JAM, имат многопрозоречен интерфейс. Разработването на екрана се състои в поставянето на интерфейсни елементи върху него, групирането им, задаването на стойностите на техните свойства.
Редактор на менютови позволява да разработвате и отстранявате грешки в системи от менюта. Реализирана възможност за изграждане на пиктографски менюта. Присвояването на елементи от менюто към обектите на приложението се извършва в екранния редактор.
JAM ядрото има вградена JDB релационна СУБД за един потребител. Основната цел на JDB е да създава прототипи на приложения в случаите, когато работата със стандартна СУБД е невъзможна или непрактична. JDB прилага необходимия минимум от възможности за релационна СУБД, който не включва индекси, съхранени процедури, тригери и изгледи. Използвайки JDB, можете да изградите база данни, която е идентична с целевата база данни (до функциите, които липсват в JDB) и да разработите значителна част от приложението.
Дебъгерът ви позволява да извършите комплексно отстраняване на грешки на разработеното приложение. Всички събития, които се случват по време на изпълнение на приложението, се проследяват.
Помощни програми JAM включва три групи:
1) Конвертори на JAM екранни файлове в текст. JAM записва екрани като двоични файлове в собствен формат;
2) конфигуриране на I/O устройства. JAM и създадените с него приложения не работят директно с I/O устройства. Вместо това JAM има достъп до логически I/O устройства (клавиатура, терминал, отчет);
3) поддръжка на екранни библиотеки.
Един от незадължителните JAM модули е генератор на отчети.Оформлението на отчета се извършва в JAM екранния редактор. Описанието на доклада се извършва на специален език. Генераторът на отчети ви позволява да дефинирате данните, които да бъдат изведени в отчета, групирането на изходната информация, форматирането на изхода и т.н.
Приложенията, разработени с помощта на JAM, могат да бъдат превърнати в изпълними модули. За да направят това, разработчиците трябва да имат C компилатор и линкер.
JAM съдържа вграден език за програмиране JPL (JAM Procedural Language), с който при необходимост могат да се пишат модули, реализиращи конкретни действия. Този език се превежда. Възможен е обмен на информация между визуално изградената среда на приложението и такива модули. Освен това JAM реализира възможността за свързване на външни модули, написани на езици, които са съвместими при извиквания на функции с езика C.
Jam е система, управлявана от събитиясъстоящ се от набор от събития - отваряне и затваряне на прозорци, натискане на клавиш на клавиатурата, задействане на системен таймер, получаване и прехвърляне на контрол върху всеки елемент от екрана. Разработчикът прилага логиката на приложението, като дефинира манипулатор за всяко събитие.
манипулатори на събития JAM може да има както вградени JAM функции, така и функции, написани от разработчика на C или JPL. Наборът от вградени функции включва повече от 200 функции за различни цели; те са достъпни за извиквания от функции, написани както на JPL, така и на C.
Индустриална версия на приложението,разработен с JAM, се състои от следните компоненти:
1. изпълним модул на интерпретатора на приложението;
2. екрани, съставляващи приложението (доставени като отделни файлове, като част от екранни библиотеки или вградени в тялото на интерпретатора);
3. външни JPL модули (доставени като текстови файлове или предварително компилирани; предварително компилирани
4. външни JPL-модули - като отделни файлове и като част от екранни библиотеки);
5. конфигурационни файлове на приложението - конфигурационни файлове на клавиатура и терминал, файл със системни съобщения, общ конфигурационен файл.
Директното взаимодействие със СУБД се осъществява от модулите JAM/DBi (Database interface). Начините за реализиране на взаимодействие в JAM са разделени на два класа: ръчни и автоматични.
При ръчен начинразработчикът самостоятелно пише SQL заявки, в които източниците и дестинациите за получаване на резултатите от изпълнението на заявката могат да бъдат както интерфейсни елементи на визуално проектирано външно ниво, така и вътрешни променливи, невидими за крайния потребител.
Автоматичен режимреализиран от JAM транзакционния мениджър. Това е осъществимо за типични общи типове операции с бази данни, така наречените QBE (Query By Example - заявки според модела), като се вземат предвид доста сложните връзки между таблиците на базата данни и автоматичният контрол на атрибутите на екранния I/O полета, в зависимост от типа транзакция (четене, запис и др.), в която участва генерираната заявка.
JAM ви позволява да създавате приложения за работа с повече от 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-съвместими СУБД и др.
Отличителна черта на JAM е високото ниво на преносимост на приложенията между различни платформи (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS и др.); може би изискване за "преначертаване" на статични текстови полета на екрани с руски текст при пренасяне между DOS-Windows-UNIX среди. Освен това преносимостта се улеснява от факта, че в JAM приложенията се разработват за виртуални I/O устройства, а не за физически. По този начин, когато се пренася приложение от платформа на платформа, обикновено е необходимо само да се определи съответствието между физически I/O устройства и техните логически представяния за приложението.
Използването на SQL като средство за взаимодействие с СУБД също помага да се осигури преносимост между СУБД. В случай на прехвърляне на структура на база данни, приложенията може да не изискват модификация, освен инициализация на сесия. Това е възможно, ако приложението не използва SQL разширения, специфични за СУБД.
С увеличаване на натоварването на системата и сложността на решаваните задачи (разпределение и разнородност на използваните ресурси, броя на едновременно свързаните потребители, сложността на логиката на приложението), тристепенен архитектурен модел"клиент - сървър" с помощта на мениджъри на транзакции. Компонентите JAM/TPi-Client и JAM/TPi-Server улесняват преминаването към трислоен модел. В същото време модулът JAM/TPi-Server играе ключова роля, тъй като основната трудност при внедряването на тристепенния модел се крие в внедряването на логиката на приложението в услугите за управление на транзакции.
Интерфейсът JAM/CASE позволява обмен на информация между хранилището на JAM обекти и хранилището на инструмента CASE. Обменът е подобен на начина, по който структурата на базата данни се импортира в JAM хранилището директно от базата данни. Разликата е, че обменът между хранилищата е двупосочен.
В допълнение към модулите JAM / CASEi има и модул JAM / CASEi Developer "s Kit. Използвайки този модул, можете самостоятелно да разработите интерфейс (т.е. специализиран JAM / CASEi модул) за конкретен CASE инструмент, ако има е готов JAM / CASEi модул, защото не съществува.
Има интерфейс, който реализира взаимодействието между инструмента Silverrun CASE и JAM. Той прехвърля схемата на базата данни и екранните форми на приложението между инструмента Silverrun-RDM CASE и JAM версия 7.0; има два режима на работа:
1) директният режим (Silverrun-RDM->JAM) е предназначен за създаване на CASE речникови обекти и елементи на JAM хранилище въз основа на представяне на схема в Silverrun-RDM. Въз основа на представянето на интерфейсни модели данни в Silverrun-RDM се генерират екрани и елементи от JAM хранилището. Мостът преобразува RDM таблиците на релационните схеми и релациите в последователност от JAM обекти от подходящ тип. Техниката за изграждане на интерфейсни модели на данни в Silverrun-RDM включва използването на механизъм на подсхема за прототипиране на екрани на приложения. Въз основа на описанието на всяка от RDM подсхемите, мостът генерира JAM екран;
2) обратният режим (JAM->Silverrun-RDM) е предназначен за прехвърляне на модификации на CASE-речникови обекти към релационния модел Silverrun-RDM.
Режимът на реинженеринг ви позволява да прехвърлите модификации на всички свойства на JAM екрани, импортирани преди това от RDM, към схемата Silvcrrun. За да се контролира целостта на базата данни, не се допускат промени в схемата под формата на добавяне или изтриване на таблици и полета на таблици.
JAM ядрото има вграден интерфейс към инструменти за управление на конфигурацията (PVCS на платформата Windows и SCCS на платформата UNIX). Екранните библиотеки и/или хранилища се прехвърлят под контрола на тези системи. При липсата на такива системи JAM самостоятелно изпълнява някои от функциите за подпомагане на развитието на екипа.
На платформата MS-Windows JAM има вграден интерфейс към PVCS и действията за извличане/връщане се извършват директно от средата на JAM.
Vantage Team Builder (Westmount I-CASE). Vantage Team Builder е интегриран софтуерен продукт, ориентиран към внедряване, с пълна поддръжка за модела на жизнения цикъл на водопада.
Vantage Team Builder предоставя следните функции:
1. проектиране на диаграми на потока от данни, диаграми на обекти-връзки, структури от данни, блокови диаграми на програми и последователности от екранни форми;
2. проектиране на диаграми на системната архитектура - SAD (проектиране на състава и връзката на изчислителните съоръжения, разпределяне на системните задачи между изчислителните съоръжения, моделиране на взаимоотношенията клиент-сървър, анализиране на използването на мениджъри на транзакции и функции за функциониране на системата в реално време);
3. генериране на програмен код на езика на целевата СУБД с пълна софтуерна среда и генериране на SQL код за създаване на таблици на база данни, индекси, ограничения за интегритет и съхранени процедури;
4. програмиране на C с вграден SQL;
5. управление на версии и конфигурация на проекта;
6. многопотребителски достъп до хранилището на проекта;
7. генериране на проектна документация по типови и индивидуални образци;
8. експорт и импорт на проектни данни в CDIF формат (CASE Data Interchange Format).
Vantage Team Builder се предлага в различни конфигурации в зависимост от използваната система за управление на базата данни (ORACLE, Informix, Sybase или Ingres) или инструментите за разработка на приложения (Uniface). Конфигурацията на Vantage Team Builder за Uniface се различава от останалите с частичното фокусиране върху спираловиден модел на жизнения цикъл поради възможностите за бързо създаване на прототипи. За описание на AIS проекта се използва голям набор от диаграми.
При конструирането на всички видове диаграми се осигурява контрол за съответствието на моделите със синтаксиса на използваните методи, както и контрол за съответствието на едноименни елементи и техните типове за различни видове диаграми.
При конструирането на диаграми на потоци от данни DFD се осигурява контрол върху съответствието на диаграмите на различни нива на разлагане. DFD от най-високо ниво се валидира с помощта на матрицата на списъка със събития на ELM. За контролиране на декомпозицията на съставни потоци от данни се използват няколко опции за тяхното описание: във формата диаграми на структурата на данните DSD или ин нотации BNF (форма на Backus - Naur).
За изграждане на SAD се използва разширена DFD нотация, която дава възможност за въвеждане на концепциите за процесори, задачи и периферни устройства, което осигурява яснота на дизайнерските решения.
При изграждането на модел на данни под формата на ERD, той се нормализира и се въвежда дефинирането на физическите имена на елементи от данни и таблици, които ще се използват в процеса на генериране на физическата схема на данни на конкретна СУБД. Предоставя възможност за определяне на алтернативни ключове на обекти и полета, които съставляват допълнителни входни точки към таблицата (полета на индекси), както и кардиналността на връзките между обекти.
Наличието на универсална система за генериране на код, базирана на определени средства за достъп до хранилището на проекта, позволява да се поддържа високо ниво на изпълнение на проектната дисциплина от разработчиците: строга процедура за генериране на модели; твърда структура и съдържание на документацията; автоматично генериране на сорс кодове на програми и др.; всичко това осигурява повишаване на качеството и надеждността на разработената ИС.
Системи за публикуване като FrameMaker, Interleaf или Word Perfect могат да се използват за подготовка на проектна документация. Структурата и съставът на проектната документация са конфигурирани в съответствие с посочените стандарти. Корекцията се извършва без промяна на проектните решения.
При разработване на големи AIS, цялата система като цяло отговаря на един проект като категория Vantage Team Builder. Проектът може да бъде разложен на множество системи, всяка от които съответства на някаква относително автономна AIS подсистема и се разработва независимо от другите. В бъдеще системите за проекти могат да бъдат интегрирани.
Процесът на проектиране на AIS с помощта на Vantage Team Builder се изпълнява в четири последователни фази (етапи) - анализ, архитектура, дизайнИ изпълнение,в същото време завършените резултати от всеки етап се прехвърлят изцяло или частично (импортират) към следващата фаза. Всички диаграми, с изключение на ERD, се преобразуват в друг тип или променят външния си вид в съответствие с характеристиките на текущата фаза. По този начин DFD се преобразуват във фазата на архитектурата в SAD, DSD в DTD. След като импортирането приключи, логическата връзка с предходната фаза се прекъсва, т.е. могат да се направят всички необходими промени в диаграмите.
Конфигурацията Vantage Team Builder за Uniface осигурява споделяне на две системи в рамките на една среда за технологично проектиране, докато схемите на базата данни (SQL модели) се прехвърлят в хранилището на Uniface и обратно, моделите на приложения, генерирани от инструментите на Uniface, могат да бъдат прехвърлени в Хранилище на Vantage Team Builder. Възможните несъответствия между хранилищата на двете системи се елиминират с помощта на специална помощна програма. Разработването на екранни форми в среда Uniface се извършва на базата на диаграми на последователност на FSD форми след импортиране на SQL модела. Технологията за разработване на AIS, базирана на тази конфигурация, е показана на фиг. 2.23.
Структурата на хранилището, съхранявано в целевата СУБД и интерфейсите на Vantage Team Builder са отворени, което по принцип позволява интеграция с всякакви други инструменти.
Uniface.Продуктът Compuware е среда за разработка на широкомащабни приложения в архитектурата "клиент-сървър" и има следната компонентна архитектура:
1. Хранилище на обекти на приложения (хранилище на обекти на приложения) съдържа метаданни, използвани автоматично от всички други компоненти през целия жизнен цикъл на AIS (модели на приложения, описания на данни, бизнес правила, екранни формуляри, глобални обекти и шаблони). Хранилището може да се съхранява във всяка от базите данни, поддържани от Uniface;
Ориз. 2.23.Взаимодействие между Vantage Team Builder и Uniface
2. Application Model Manager поддържа модели на приложения (E-R модели), всеки от които е подмножество на общата схема на база данни от гледна точка на това приложение, и включва подходящ графичен редактор;
3. Rapid Application Builder - инструмент за бързо създаване на екранни форми и отчети на базата на обекти от приложения модел. Включва графичен редактор на формуляри, инструменти за създаване на прототипи, отстраняване на грешки, тестване и документиране. Реализиран интерфейс с различни видове прозоречни контроли Open Widget Interface за съществуващи графични интерфейси - MS Windows (включително VBX), Motif, OS/2. Универсалният интерфейс за представяне ви позволява да използвате една и съща версия на приложението в среда на различни графични интерфейси, без да променяте програмния код;
4. Услугите за разработчици (услуги за разработчици) се използват за поддръжка на големи проекти и внедряване на контрол на версиите (Uniface Version Control System), права за достъп (разграничаване на правомощия), глобални модификации и т.н. Това предоставя на разработчиците средства за паралелен дизайн, въвеждане и контрол на изхода, търсене, преглед, поддържане и издаване на отчети за данните от системата за контрол на версиите;
5. Deployment Manager (управление на разпространението на приложения) - инструменти, които ви позволяват да подготвите създаденото приложение за разпространение, да го инсталирате и поддържате (платформата на потребителя може да се различава от платформата на разработчика). Те включват мрежови и СУБД драйвери, сървър за приложения (полисървър), инструменти за разпространение на приложения и управление на бази данни. Uniface поддържа интерфейс с почти всички известни хардуерни и софтуерни платформи, СУБД, CASE-инструменти, мрежови протоколи и мениджъри на транзакции;
6. Personal Series (персонални инструменти) се използват за създаване на сложни заявки и отчети в графична форма (Personal Query and Personal Access – PQ/PA), както и за прехвърляне на данни към системи като WinWord и Excel;
7. Distributed Computing Manager - инструмент за интеграция с Tuxedo, Encina, CICS, OSF DCE мениджъри на транзакции.
Версията Uniface 7 напълно поддържа модел на разпределени изчисления и тристепенна архитектура клиент-сървър (с възможност за промяна на схемата за декомпозиция на приложението по време на изпълнение). Приложенията, създадени с помощта на Uniface 7, могат да се изпълняват в разнородни операционни среди, използвайки различни мрежови протоколи, едновременно на няколко разнородни платформи (включително Интернет).
Компонентите на Uniface 7 включват:
1. Uniface Application Server - сървър за приложения за разпределени системи;
2. WebEnabler - сървърен софтуер за работа с приложения в Интернет и интранет;
3. Name Server - сървърен софтуер, който осигурява използването на разпределени ресурси на приложението;
4. PolyServer – средство за достъп до данни и интегриране на различни системи.
Поддържаните СУБД включват DB2, VSAM и IMS; PolyServer също така осигурява оперативна съвместимост с MVS OS.
Дизайнер/2000 + Разработчик/2000. Designer/2000 2.0 на ORACLE е интегриран CASE инструмент, който, във връзка с инструментите за разработка на приложения Developer/2000, осигурява пълна поддръжка на жизнения цикъл на софтуера за системи, използващи СУБД на ORACLE.
Designer/2000 е семейство от методологии и поддържащите ги софтуерни продукти. Основна методология Designer/2000 (CASE*Method) е методология за проектиране на структурна система, която напълно покрива всички етапи от жизнения цикъл на AIS. На етапа на планиране се определят целите за създаване на системата, приоритетите и ограниченията, разработват се архитектурата на системата и планът за развитие на AIS. В процеса на анализ се изграждат: модел на информационните потребности (диаграма на субект-връзка), диаграма на функционална йерархия (базирана на функционална декомпозиция на AIS), матрица за кръстосани препратки и диаграма на потока от данни.
На етапа на проектиране се разработва подробна архитектура на AIS, проектират се схема на релационна база данни и програмни модули, установяват се кръстосани препратки между компонентите на AIS за анализ на тяхното взаимно влияние и контрол на промените.
На етапа на внедряване се създава база данни, изграждат се приложни системи, те се тестват, проверява се качеството и се проверява съответствието с изискванията на потребителите. Създадена системна документация, учебни материали и ръководства за потребителя. На етапите на експлоатация и поддръжка се анализира производителността и целостта на системата, извършва се поддръжка и, ако е необходимо, модификация на AIS.
Designer/2000 предоставя графичен интерфейс за разработване на различни модели на домейни (диаграми). В процеса на изграждане на модели информацията за тях се въвежда в хранилището. Designer/2000 включва следните компоненти.
Спазването на горните принципи е необходимо при извършване на работа на всички етапи от създаването и експлоатацията на AIS и AIT, т.е. през целия им жизнен цикъл.
Жизнен цикъл(LC) - периодът на създаване и използване на AIS (AIT), започвайки от момента, в който възникне необходимостта от тази автоматизирана система и завършва с момента, в който тя вече не се използва.
Жизненият цикъл на AIS и AIT ни позволява да разграничим четири основни етапа, всеки етап на проектиране е разделен на няколко етапа и осигурява съответната работа:
I етап - предпроектна проверка:
1-ви етап - формиране на изискванията, проучване на обекта на проектиране, разработване и избор на вариант на концепцията на системата;
2-ри етап - анализ на материалите и оформяне на документация - създаване и одобряване на предпроектно проучване и задание за проектиране на системата въз основа на анализа на материалите от проучването, събрани на първия етап.
II етап - дизайн:
1-ви етап - технически дизайн,където се търсят най-рационалните дизайнерски решения за всички аспекти на развитието, създават се и се описват всички компоненти на системата, а резултатите от работата се отразяват в техническия проект;
2-ри етап - работен дизайн,по време на които се извършва разработването и фината настройка на програмите, настройката на структурите на базата данни, създаването на документация за доставка, инсталирането на технически средства и инструкции за тяхната работа, изготвянето на длъжностни характеристики за всеки потребител. Технически и работни проекти могат да бъдат обединени в един документ - технически работен проект.
III етап - системен вход в действие:
1-ви етап - подготовка за изпълнение- инсталиране и въвеждане в експлоатация на технически средства, зареждане на база данни и пробна експлоатация на програми, обучение на персонала;
2-ри етап - пилотно тестваневсички компоненти на системата преди въвеждане в търговска експлоатация, обучение на персонала;
3-ти етап (последният етап от създаването на AIS и AIT) - въвеждане в експлоатация;издадени от актове за приемане и предаване на работите.
IV етап - промишлена експлоатация - освен ежедневното функциониране включва поддръжка на софтуерни инструменти и целия проект, оперативна поддръжка и администриране на бази данни.
5. Методи за провеждане на проектантска работа
Създаването на автоматизирани информационни системи и технологии може да се осъществи по два начина. Първият вариант предполага, че в тази работа са ангажирани специализирани фирми с професионален опит в изготвянето на софтуерни продукти със специфична ориентация. Според втория вариант проектирането и създаването на разработки се извършват от дизайнери-програмисти, които са в персонала на предприятия, където се създават нови информационни технологии и системи.
В процеса на разработване на автоматизирани системи, работни места и технологии дизайнерите се сблъскват с редица взаимосвързани проблеми:
За дизайнера е трудно да получи изчерпателна информация, за да оцени изискванията, формулирани от клиента (потребителя) за нова система или технология.
Клиентът често няма достатъчно познания за проблемите на автоматизацията, за да прецени възможността за внедряване на определени иновации. В същото време дизайнерът е изправен пред прекомерно количество подробна информация за проблемната област, което създава трудности при моделирането и формализираното описание на информационните процеси и решаването на функционални проблеми.
Поради големия обем и техническа терминология, спецификацията на проектираната система често е неразбираема за клиента, а прекомерното й опростяване не може да задоволи специалистите, които създават системата.
С помощта на известни аналитични методи е възможно да се решат някои от тези проблеми, но само съвременните конструктивни методи дават радикално решение, сред които методологията на структурния анализ заема централно място.
структурен анализ наречен метод за изследване на системата, който започва с нейния общ преглед и след това детайли, придобивайки йерархична структура с нарастващ брой нива.
Структурният анализ включва разделянето на системата на нива на абстракция с ограничен брой елементи на всяко от нивата (обикновено от 3 до 6-7). На всяко ниво се подчертават само детайлите, които са от съществено значение за системата.
Методологията на структурния анализ се основава на принципите на декомпозицията и принципа на йерархичното подреждане.
Принцип на разлаганевключва решаване на трудни проблеми чрез разделянето им на задачи, които са лесни за разбиране и решаване.
Принцип на йерархично подрежданедекларира, че системата може да бъде разбрана и изградена на нива, всяко от които добавя нови детайли.
На предпроектен етапизвършва се проучване и анализ на всички характеристики на проектирания обект с цел изясняване изискванията на клиента. По-специално, идентифицира се набор от условия, при които се предполага, че бъдещата система ще работи (хардуерни и софтуерни ресурси; външни условия за нейното функциониране; съставът на хората и работите, свързани с нея и участващи в информационни и управленски процеси), описват се функциите, изпълнявани от системата и др. П.
На този етап се определят:
Архитектура на системата, нейните функции, външни условия, разпределение на функциите между хардуер и софтуер;
Интерфейси и разпределение на функциите между човек и система;
Изисквания към софтуерни и информационни компоненти на системата, необходими хардуерни ресурси, изисквания към бази данни, физически характеристики на компонентите на системата, техните интерфейси.
Качеството на по-нататъшното проектиране зависи в голяма степен от правилния избор на методи за анализ и формулираните изисквания към новосъздадената технология.
Методите, използвани на етапа на предпроектното проучване, се разделят на:
- Методи за изследване и анализ на действителното състояние на обект или технология. Тези методи позволяват да се идентифицират тесните места в изследваните процеси и включват: устно или писмено проучване; писмена анкета; наблюдение, измерване и оценка; групова дискусия; анализ на задачите; анализ на производствени и управленски процеси.
Като цяло методите за изследване и анализ на действителното състояние на управленските дейности и съществуващата технология за решаване на проблеми са предназначени да съберат необходимите материали и да формират основата за проектиране на AIS и AIT.
- Методи за формиране на дадено състояние. Те се основават на обосновката на всички компоненти на АИС въз основа на целите, изискванията и условията на клиента. Тези методи, които са работни инструменти на дизайнерите, включват методи: моделиране на процеса на управление; конструктивен дизайн; разграждане; анализ на информационния процес.
- Метод за моделиране на процеса на управление.В процеса на изследване на проектния обект се изграждат икономико-организационни и информационно-логически модели. Те отразяват икономическите и управленските отношения, както и свързаните с тях информационни потоци.
- Метод на конструктивно проектираневи позволява да разделите целия комплекс от задачи на видими и анализируеми подкомплекси (модули).
- Метод на разлаганемодули предвижда по-нататъшно разделяне на подгрупи от задачи на отделни задачи, индикатори.
- Анализ на информационните процесие предназначен да идентифицира и представи връзката между резултата, процеса на обработка и въвеждането на данни. Използва се и за анализиране и формиране на информационни връзки между работните места на управленски служители, специалисти, технически персонал и информационните технологии. За целта са описани входната и изходната информация, както и алгоритъмът за обработка на информацията по отношение на всяко работно място.
- Методи за графично представяне на действителните и зададените състоянияосигуряват използването на визуално представяне на процесите на обработка на информация. Най-известните от тях включват метода на блок-схемата, методите на стрелковите диаграми, мрежовите диаграми, таблиците на последователността на операциите на процесите.
Ако на етапа на предпроектиране изискванията за създаване на AIS и AIT трябва да бъдат формулирани в техническото задание, тогава проектът трябва да отговори на въпроса: „Как системата ще отговаря на изискванията към нея?“.
В резултат на етапите на проектиране трябва да се получи проект на системата в рамките на бюджета на разпределените ресурси.
Етапите на проектиране включват следните основни работи:
Разработване на целите и организационните принципи на АИС;
Формиране на вариант на АИС и АИТ;
Програми за отстраняване на грешки;
Пробна експлоатация;
Доставка на проекта AIS и AIT.
В процеса на организиране на дизайна се вземат различни решения, които влияят върху динамиката и качеството на работа. Следователно за всеки етап на проектиране се определят: очаквани резултати и документи; лични функции на главата; решения, взети от лидера; функции на клиента и разработчик на AIS и AIT.
Проектната и изпълнената документация включва: инструкции за работния процес, програми за работни места, инструкции за документация, препоръки за използване на информация, методи, таблици за решения и др.
В съвременните условия AIS, AIT и AWP по правило не се създават от нулата. Необходимостта от навременна, качествена, оперативна информация и нейната оценка като най-важен ресурс в процесите на управление, както и последните постижения на научно-техническия прогрес, налагат преструктурирането на функциониращата АИС и създаването на АИС и АИТ на нова техническа и технологична база.
AIS дизайн
Подробна разработка проектиране на систематасъдържаща пълен комплект от неговата организационна, проектна, технологична и експлоатационна документация. В съответствие с GOST 34.601-90. Проектирането на автоматизирани системи включва изпълнението на редица етапи, включително: формиране на изисквания за AU, разработване на концепцията за AU, разработване на технически спецификации, предварителен проект, технически проект и разработване на работна документация. Етапите на създаване на АС, освен проектиране, включват също: въвеждане в експлоатация и поддръжка на АС. Всеки етап е подразделен на етапи. Приложенията към този стандарт също така определят:
· Списък на видовете организации, участващи в работата.
В зависимост от естеството на проектния обект и неговите специфични условия GOST 34.601-90 позволява изключването на отделни етапи, както и тяхната комбинация. Като се има предвид дългогодишната практика, развита в Русия при създаването на автоматизирани информационни системи (" AIS“), обикновено се извършват следните етапи на проектиране: предпроектно проучване, идеен проект, идеен проект, технически проект и работен проект. Други държавни стандарти, регулиращи различни аспекти на проектирането на АЕЦ:
· GOST 34.602-89 Набор от стандарти за автоматизирани системи. Техническо задание за създаване на автоматизирана система. Вписан.01.01.90г.
· Стандарт 34.603-92 Информационни технологии. Видове AS тестове.
· Стандарти 34. (971, 972.973, 974, 981) - 91 Информационни технологии. Връзката на отворените системи.
· Стандарт 34.91. Информационни технологии. Локални мрежи и др.
Предпроектно проучване- Събиране и обработка на информация за организацията и функционирането на обекта за автоматизация, включително данни за взаимодействието му с външната среда и други обекти, както и изпълнението системен анализ, разработване на предпроектно проучване за възможността за автоматизация и разработване на общи изисквания за разработване на автоматизирана система. Съдържанието на работата по време на предпроектното проучване на обекта за автоматизация съответства на етапа „Формиране на изискванията към AU“ GOST 34.601-90, етапи: „Инспекция на обекта и обосновка на необходимостта от създаване на AU“, „ Формиране на потребителски изисквания към АС”, „Формиране на отчет за извършената работа и заявка за разработване на АС – тактико-техническо задание.
Концептуален дизайн- Съответства на етапите на проектиране в съответствие с GOST 34.601-90 - „Разработване на концепцията на AU“ (етапи: „Разработване на варианти на концепцията на AU и избор на вариант на концепцията на AU, който удовлетворява потребителя“, „Изготвяне отчет за извършената работа“) и „Разработване на задание“. Видовете окончателни документи за работа на този етап са предварителен проект(използвани също имена - “ Идеен проект ”, “Пилотен проект") или програмасъздаване на система, която включва:
Кратко описание на първоначалното състояние на обекта за автоматизация и средата, в която работи;
Посочване на основните цели и списък със задачи за автоматизация;
· Описание на разширената организационна и функционална структура на избрания вариант (или варианти) за изграждане на създаваната система;
· Предпроектно проучване;
· Разширено описание и основни изисквания към средствата за информационно и езиково осигуряване;
· Общи изисквания към софтуера и хардуера;
· Списък и разширено описание на етапите на създаване на системата, сроковете на тяхното внедряване, състава на изпълнителите и очакваните резултати от внедряването им;
· Първоначална оценка на разходните показатели за изпълнение на работата;
· Техническо задание за системата като цяло и/или нейните основни компоненти (подсистеми, софтуерни и хардуерни системи и инструменти, отделни задачи и др.), одобрено от клиента.
Идеен проект- Разработване на идейни проектни решения на системата и нейните части. Окончателният документ от работата на този етап на проектиране е идеен проект, който съдържа основните конструктивни и схемни решения на обекта на разработка, както и данни, които определят неговата цел и основни параметри (при проектиране софтуерсистема, черновият проект трябва да съдържа пълен спецификацияразвити програми).
Инжинерен дизайн -Етап на проектиране на АЕЦ, който включва:
· Разработване на проектни решения за системата и нейните части;
· Разработване на документация за АС и неговите части;
· Разработване и изпълнение на документация за доставка на продукти за придобиване на АЕЦ и/или технически изисквания (технически спецификации) за тяхното разработване;
· Разработване на задания за проектиране в съседни части на проекта на обекта за автоматизация.
Крайният документ от този етап на проектиране е технически проектсъдържащ, в допълнение към изброените материали, схеми на електрически вериги и проектна документация на обекта за разработка и неговите компоненти, списък на избрани готови инструменти софтуер и хардуер(включително компютри, операционна система, приложни програмии т.н.), както и алгоритмирешаване на проблеми за разработване на нови софтуерни средства и др.
Работен проект- Заключителен етап дизайн, който в допълнение към разработването на работна документация за системата и нейните части, изисквана от GOST 34.601-90, като цяло предвижда изясняване и детайлизиране на резултатите от предишни етапи, създаване и тестване на експериментален и / или пилотен прототип на обект на автоматизация, разработване и тестване на софтуерни продукти, технологична и оперативна документация. Резултатите са представени в работещили технически работен проект. В съвременната дизайнерска практика автоматизирани информационни системи(Например, АБИС, ASNTI, ACSи т.н.) това е началният етап от тяхното внедряване в работата на фирма, организация или услуга, която е клиент на проекта или ръководител на редица други автоматизирани фирми, организации, услуги и др.
Цикъл на разработка (дизайн) софтуер -Набор от етапи на развитие софтуерзапочвайки от системен анализи разработване на първоначални изисквания преди внедряването му.
Принципи на проектиране на AIS- Набор от правила или изисквания, фиксирани от дългогодишен и многостранен опит в създаването и експлоатацията на AIS. Най-често срещаните са:
· Идентичност- разработването на нова, усъвършенстването на съществуваща или въвеждането на външно получена АИС са сходни по съдържание научно-технически проблеми, различаващи се един от друг само по съдържанието на редица етапи и времеви параметри;
· Технологичност: автоматизирана технология означава разработване на нова технология или модернизация на съществуваща в условията на АИС и не позволява просто използване на разработения софтуер и хардуер в условията на стари традиционни технологии;
· Приемственост, етапност и приемственост на развитието и развитието: AIS - системи, постоянно развиващи се на тяхна база; всяка иновация служи като развитие на основните системни принципи и вече постигнатото качество;
· адаптивност: AIS компонентите трябва да имат свойства, които осигуряват бързо адаптиране на тези компоненти към промените във външната среда и новите инструменти;
· Модулен принцип на изграждане на софтуер и хардуер: приема, че съставът на тези инструменти се състои от блокове („модули“), които предоставят възможност за тяхната замяна или промяна с цел подобряване на функционирането на АИС или нейното адаптиране към нови условия;
· Технологичен (включително - мрежа) интеграция: предполага единство на цялата система от технологии за създаване, актуализиране, съхраняване и използване на информационни ресурси и по-специално единна обработка на документи и данни, както и тяхното многократно и многоцелево използване;
· Пълно нормализиране на процесите и тяхното наблюдение: многоцелевото използване на AIS информация изисква висока надеждност на данните в системата. За да направите това, на различни етапи от обработката и въвеждането на информационни документи е необходимо да се използват различни форми на контрол на информацията, изискванията за които могат да се формират от състава на задачите, които се решават, и данните, които се обработват. необходим е и постоянен мониторинг за получаване на качествени и количествени характеристики на функционирането на АИС въз основа на вградени и специално разработени инструменти за интелектуална статистика;
· Регламент: AIS са фокусирани върху функционирането в индустриален режим, осигурявайки масова поточна обработка на информационни документи; тази обработка се регламентира от стандарти, маршрутни и експлоатационни технологии, стандарти за ресурсни и времеви показатели и развита диспечерска служба.
· Икономическа целесъобразност: създаването на AIS трябва да включва избора на такива дизайнерски решения (включително софтуерни, технически, организационни и технологични), които при постигане на целите и задачите осигуряват минимизиране на разходите за финансови, материални и трудови ресурси.
· Типизация на проектни решения: разработването и развитието на AIS и техните мрежи се извършва с акцент върху междубиблиотечното сътрудничество и сътрудничество, както и в съответствие с правилата и протоколите за международен обмен на информация;
· Максимално използване на готови решения: за да се намалят разходите и времето за разработване и внедряване на AIS, както и да се намалят грешките при проектирането както на системата като цяло, така и на отделните й компоненти, се препоръчва да се използват колкото е възможно повече готови решения и инструменти. В този план при създаването на нова система значителен обем работа е свързан с анализ на алтернативни варианти за възможни решения, избор на най-подходящия за обекта на автоматизация и адаптирането му към нови условия на използване;
· корпоратизъм: при проектирането на автоматизирана система, която е част от система от по-високо ниво (градове, департаменти, републики и др.), Трябва да се осигури нейната хардуерна, софтуерна, езикова и информационна съвместимост с други участници в системата и / или AIS мрежата. Корпоративните изисквания могат да противоречат на изискванията или решенията, продиктувани от други принципи, например приемствеността на дизайнерските решения;
· Ориентация към първите лица на обекта за автоматизация: успешното изпълнение на работата по създаването на AIS, нейното развитие и експлоатация е възможно само ако те са безусловно подкрепени от първото лице на обекта за автоматизация (например директор на библиотека или информационен орган) и пряката отговорност за тяхното внедряване се възлага със заповед на организацията на ръководителя на ниво поне заместник-директор
