.RU

1.2.2. Икономически аспекти на софтуерното инженерство - Предговор учебник



1.2.2. Икономически аспекти на софтуерното инженерство

За да се изследват възможностите и разходите за поддържане на софтуерния продукт, е необходимо да се оцени средното разпределение на разходите за разработване сред отделните стъпки на софтуерния жизнен цикъл. Това е трудна задача, тъй като данните могат да са различни за различните проекти. Независимо от това, средните разходи за отделните стъпки могат грубо да се отнесат към общите разходи за разработване (100%) по следния начин:

а) Анализ на изискванията и спецификация 15%

б) Предварително проектиране 10%

в) Детайлизирано проектиране 15%

г) Реализиране 20%

д) Интегриране и тестване 20%

е) Изпитание 20%

ж) Поддържане 70- 200%

Посочените данни показват учудващо високи разходи за поддържане. Възможните причини за скрити грешки в софтуерния продукт, появяващи се по време на експлоатация са:

- системата се разработва от голям колектив от програмисти и системни техници, ето защо е възможна несъгласуваност на отделни части, в това число следствие на трудно реализуеми ситуации при работа в реални условия;

- невъзможността за пълно тестване, поради големия обем и логическата сложност на системата, е причина за запазването на част от грешките, допуснати от програмистите;

- програмната обработка в случай на неизправности в апаратната част може да доведе до изкривяване на информацията и непредвидими ситуации;

- случайни грешки на персонала по поддръжка, грешки свързани с неправилни или лошо разработени експлоатационни инструкции, а също и грешки при внасяне на изменения могат да доведат до неправилно функциониране на системата.

Малка част от разходите, свързани с поддържането, са поради отстраняване на грешки, по-голямата част са следствие на изменения в потребителските изисквания. Това е особено вярно за вградените системи за работа в реално време, които имат относително дълъг живот и са обект на непрекъснати изменения, които са продиктувани от еволюцията в операционната среда.

Таблицата показва и неочаквано високи разходи на софтуерното тестване - стъпки (д) и (е) - които обхващат около 40-50% от общите разходи за разработване. Това включва не само усилията за изпълнение на тестовете, но и дейностите, свързани с отстраняване на грешките в изискванията, проекта или кода, които са открити по време на тестване. Това, което прави проблема действително труден е, че вграденият софтуер за работа в реално време е обикновено изключително труден за тестване. Причина за това е сложността на интерфейса между системата и нейната околна среда и невъзможността за тестване на софтуера в неговата операционна среда. Не е възможно например, за целите на тестването изкуствено да се въвеждат неизправности в една телекомуникационна система по време на нейната реална работа.

Детайлизираният анализ на разходите по отстраняване на грешки е показал, че болшинството от тях - около 80% - са следствие от грешки направени по време на анализа на изискванията и проектирането, докато само 20% са грешки от кодиране. Това поставя ударението върху началните стъпки на софтуерния жизнен цикъл, и обяснява защо те поглъщат повечето от усилията и разходите.

Тези разглеждания водят до заключението, че практическите подходи в софтуерното инженерство трябва да обръщат голямо внимание на намаляване на разходите за тестване и поддържане, чрез увеличаване на възможността за тестване и поддържане на изискванията и на проекта, както и на реализациите на софтуерните елементи и техните компоненти. Средствата за постигане на тези цели са следните:

 Щателна организация на управлението на софтуерните проекти, включваща периодичен преглед и проверка за валидност на резултатите. Това би намалило вероятността за изграждане на система която не отговаря на изискванията и очакванията.

 Пълна документация и запис на всички изисквания, важни избори и решения взети при анализа, проектирането и реализирането. Добре е документите да се поддържат не само в текстова форма, но и под формата на диаграми, чертежи и таблици.

 Внимателна декомпозиция и разделяне на модули на софтуера по време на проектиране и реализиране, водещи до лесни за разбиране и поддържане структури, които са далеч по-удобни за документиране, тестване и изменение.

 Многократно използване на различни елементи на проекта. Това не се отнася само за кодираните софтуерни единици, но също и за елементите на изискванията, проектирането и документацията.

Трябва да се обърне внимание на по-важните свойства на документацията на проекта, която служи като основен инструмент за обмен на идеи между потребителите и производителите. Качеството на документацията значително влияе върху разходите за разработване и поддържане на продукта. Документацията трябва да бъде разбираема, пълна, недвусмислена, съгласувана и проследима. Първите три термина са свързани с общите правила на добрия стил на писане и не изискват допълнителен коментар.

Съгласуваността може да се интерпретира по два начина. Вътрешната съгласуваност означава, че няма два израза в даден документ, които си противоречат един на друг. Даден термин, синоним или съкращение има едно и също значение в целия документ, и даден обект или понятие винаги се означават с едно и също име. Външната съгласуваност между документите има същото значение, но се прилага към отделни документи, които не са йерархично свързани.

Проследимостта има по-широко значение отколкото външната съгласуваност и се прилага към документи, които са в йерархична връзка (предшестващ - следващ), като спецификация на изискванията и описание на проектните решения. Независимо от съгласуваността, това означава, че целият материал в следващия документ се базира на предшестващите го документи, т.е. не трябва да се въвежда не проследим документ. Връзката между документите трябва да бъде видима посредством изрични указатели.

Мотивацията за изучаване на икономическите аспекти на софтуерното инженерство е увеличаване на продуктивността и намаляване на разходите. За да се оцени евентуалната полза от прилагането на горните принципи, е интересно да се знаят общите разходи за производство на софтуер в световен мащаб. Статистиката на съвременния етап и бъдещите планове в тази област са посочени на фиг.1.6 [1].


Софтуерни разходи (*109 $ за година)

1000





500


200



100


50





20


1980

1985

1990

1995

2000

година

Фиг.1.6 Насока на развитие на софтуерните разходи


1.2.3. Класически методи за разработване на софтуер

Традиционният подход за разработване на софтуер съответства на модела на жизнения цикъл, описан в точка 1.2.1. Спецификацията на изискванията е документ, обикновено дълъг и изтощаващ, написан на естествен език и прецизно постановяващ какво трябва да прави системата, но без да посочва как трябва да се направи. Документът може да се чете от потребителя, от когото се изисква да го провери за валидност, т.е. преглеждане и приемане на съдържанието му. След проверката за валидност, документът служи като база за проектиране и реализиране на системата. За да играе тази роля, спецификацията на изискванията трябва да бъде: пълна, недвусмислена, съгласувана, проследима, проверима и модифицируема. Слаба точка в тази процедура е, че проверката за валидност на спецификацията на изискванията изцяло разчита на потребителското въображение. Двусмислието на естествения език води до двусмисленост на спецификацията. Нещо повече, потребителите рядко знаят какво точно искат. Вероятността за построяване на погрешна система, която се нуждае от незабавни изменения е голяма. Във втора глава е направено кратко описание на езика за спецификация и описание SDL, разработен от МСД1 като език, даващ един регламентиран, формален начин за обмен на информация между хора, работещи в областта на телекомуникациите.

На стъпките на проектиране и реализиране структурата и алгоритмите на системата, които трябва да се разработят, са определени и глобално оптимизирани според избрани критерии. И двете стъпки се изпълняват ръчно и изискват голяма квалификация на проектантите и програмистите. За да се провери съгласуваността между спецификацията на изискванията и реализацията, е необходимо сложно тестване. Слабо място в тази процедура е, че само реализираните програми могат да бъдат тествани, и че коригирането на грешки при проектирането, намерени в стъпката на тестване е обикновено много скъпо. Нещо повече, тестването може да не докаже отсъствието на грешки.

Изменения се правят най-много на етапа на реализиране. Оптимизираната структура се изменя и се извършва само локална оптимизация. Спецификацията на изискванията и описанието на проекта не винаги се изменят, тъй като това е досадна и отнемаща време задача. Това прави двете документации неадекватни и създава огромни проблеми по време на понататъшната поддръжка.

Главни недостатъци на класическия подход са обобщени накратко на фиг.1.7.

Трябва да се подчертае, че недостатъците не се отнасят до даден метод, а са присъщи характеристики на философията на разработване.

Няколко метода, които адресират проблемите, изброените по-горе са разработени и предложени на пазара. Повечето от методите, приложени в стъпката на анализ на изискванията изграждат повече или по-малко формален концептуален модел на системата, която трябва да се разработи. Моделът се декомпозира от гледна точка на потоците данни, управляващите потоци или структурите данни. Целта на декомпозицията, направена на етапа на анализ на изискванията, е структуриране на описанието на проблема, за да се направи то по-разбираемо. Използват се графични методи и средства, които помагат на анализиращия при разбирането на проблема, правят спецификацията по-малко двусмислена, и подпомагат комуникацията с потребителя.




Фиг.1.7. Недостатъците не се отнасят до даден метод, а са присъщи

характеристики на философията на разработване


Има три диаграми, по една за всеки аспект от поведението на системата, използвани по време на анализ и по време на проектиране:

 диаграми на потоците данни;

 диаграми на състоянията и преходите;

 диаграми на елементите и връзките.

Диаграмата на потоците данни показва функционалността на системата. Тя се състои от кръгове или трансформации на данните, които представят една системна функция; отворени правоъгълници, които представят хранилищата на данни (например таблици или свързани списъци) и насочени стрелки, които представят потоците от данни (непрекъснати линии). Диаграмата показва потока на данните, който влиза в системата и минава през различните функции. Чрез проверка на данните, влизащи в системата, на това, което системата прави с данните и евентуално на данните напускащи системата, системата се описва функционално.

Като пример ще разгледаме функциите на управляващия компютър по обслужване на повикванията в автоматична телефонна централа (фиг. 1.8). Ще дадем кратко най-общо описание на изграждането на вътрешна връзка от момента на вдигане на слушалката от викащия абонат до приключването на разговора.

Трансформацията обработка на заявка започва от момента на подаване на сигнал за обслужване от абоната (заявка) и завършва с отговор на централата за готовността й да предостави обслужване. Обработката на заявка има за цел да анализира викащия абонат и да му предостави регистър (устройство), който ще приема адресната информация. За да се изпълни тази системна функция, се използват данни за викащия абонат и справочни данни. Когато управляващият компютър стане готов да приема тази информация, той информира викащия абонат за това чрез изпращане на тонален сигнал, наричан сигнал “централа" или избирай.





^ Фиг. 1.8. Диаграма на потоците данни за

обслужване на повикванията


Трансформацията анализ на цифри започва, когато се приеме избрания номер и завършва с изпращане на сигнал повикване към викания абонат. Щом управляващият компютър открие край на номеронабирането, той трябва да разпознае приетите цифри и да ги анализира, за да опреди вида на връзката (например, вътрешна, изходяща и .т.н.), направлението, към което ще се насочи връзката и информация за таксуването. Проверява се състоянието на викания абонат, и ако е свободен, се променя неговия статус в зает. Търси се път, който да свърже двата абоната, избрания път се маркира, но не се задейства. За да се изпълни тази системна функция, се използват данни за състоянието на комутационното оборудване, данни за викания абонат и справочни данни. Към викания абонат се изпраща сигнал повикване, като едновременно с това се информира викащия абонат, че търсеният е свободен (сигнал звънене).

Трансформацията изграждане на връзка започва с отговор на викания абонат. Изгражда се избраният път, като се изпращат команди към съответното оборудване. Започва таксуване с включване на таймер за измерване на продължителността на разговора. Използваните данни за тази системна функция са данни за състоянието на комутационното оборудване и справочни данни.

Трансформацията разпадане започва с поставяне обратно на слушалката от един от двата абоната (например от викащ абонат). Веднага след приемането на сигнала разпадане се променя статуса на абонатите и се спира таксуването. Дават се команди за разграждане на пътя и освобождаване на заетите ресурси. Архивира се информацията за разговора, като се прибавя таксата от завършилата съобщителна услуга.

Диаграмата на състоянията и преходите показва динамиката или управлението на системата. Тя дефинира реда, в който трябва да се изпълняват системните функции, и се състои от правоъгълници, които представят състоянията на системата и стрелки, които указват преходите. Състоянието се използва за означаване периода от време, през който системата прави нещо (обикновено следи за постъпването на събитие). Преходите се използват за означаване на последователността, в която системата преминава от едно състояние в друго. Преходът от едно състояние в следващото се инициализира с условие, което дефинира причината за напускане на състоянието. Действията дефинират какво прави системата в прехода до влизане в следващото състояние. Връщайки се на горния пример, управлението на процеса на обслужване на повикванията може да се опише със съвкупност от състояния и преходи. В случая състоянието се дефинира като период, през който системата управлява повикването. Могат да се дефинират следните състояния: предизбиране, избиране, слушане на повиквателен сигнал и разговор (фиг.1.9).



Фиг.1.9 Диаграма на състоянията и преходите за обслужване на повикванията


В състояние предизбиране се следи за постъпване на заявка за обслужване. При откриване на заявка се инициализира преход. Действията в прехода обхващат описаните по-горе действия в трансформацията обработка на заявка. Преходът завършва с влизане в състояние избиране.

В състояние избиране се приема адресната информация, постъпваща с избраните цифри и се следи за край на избирането. След приемане на пълния брой цифри се инициализира преход. Действията в прехода обхващат описаните по-горе действия в трансформацията анализ на цифри. Преходът завършва с влизане в състояние на изпращане на повиквателен сигнал.

В състояние на слушане на повиквателен сигнал на викания абонат се изпраща сигнал повикване, а на викащия абонат - тонален сигнал за потвърждение на повикването (звънене). Следи се за отговор от викания абонат.

Когато виканият абонат отговори, се инициализира преход. Действията в прехода обхващат описаните по-горе действия в трансформацията изграждане на връзка. Преходът завършва с влизане в състояние на разговор.

В състояние на разговор се следи за разпадане от страна на викащия или викания абонат. При приемане на сигнал за разпадане се инициализира преход. Действията в прехода обхващат описаните по-горе действия в трансформацията разпадане. Преходът завършва с влизане в свободно състояние.

Диаграмата на елементите и връзките представя информационния модел на системата. Тя е пасивна диаграма, което означава, че няма поток нито на данни, нито управляващ поток, но показва всички неща, които участват в системата и как всички тези различни неща са свързани заедно в реалния свят. В нашия пример тази диаграма може да показва програмната структурата на комутационните програми, управляващи комутационния процес (фиг. 1.10).



Фиг.1.10 Диаграма на елементите и връзките за програмите,

свързани с обслужване на повикванията


Откриването на събития свързани с дадено повикване става от програмите за приемане на сигнали. Логическата обработка и вземането на решени се изпълнява от програми за анализ. Работата с паметта, където се управляват комутационните операции е функция на програмата за изпълнение на задачи. Изпълнението на решенията, т.е. физическата промяна в състоянието на повикването се реализира от програмите за издаване на команди.

За да се даде на проектанта пълна спецификация на изискванията, изискванията се описват йерархично, с увеличаващо се ниво на детайлизация. Така например, всяка една трансформация на фиг. 1.8 или състояние на фиг. 1.9 могат да се декомпозират, за да се отрази в детайли дадена системна функция или състояние. Няма ограничение за броя на нивата в йерархията на диаграмите.

Методите, приложени на стъпката на проектиране, преобразуват структурата на концептуалния модел, изграден на стъпката на анализ на изискванията и прибавят технологично-oриентирани детайли, свързани с техническите характеристики на софтуера. Резултатът е модел за реализиране, представен в описанието на проекта, който показва точно как системата изпълнява нейните функции. Основните понятия, съществени за използваните методи в стъпките на проектиране и реализиране са декомпозиция отгоре на долу и различни методи за структурно програмиране. В повечето случай декомпозицията се извършва от гледна точка на функциите, потоците данни и структурите данни. Управляващият поток между софтуерните модули винаги се дефинира изрично. Методите са ориентирани към структуриране на програмния код по такъв начин, че да се посрещнат техническите изисквания и системата да се направи надеждна и удобна за поддържане.

Независимо от графичните означения, са необходими текстови документи. Методите и средствата за документиране осигуряват компютъризирано създаване и съхранение на документацията. За да се направи документацията по-малко двусмислена, обикновено естествения език се ограничава до структурна форма, придружена от диаграми на данни и управляващи потоци, речници с данни, указатели и т.н. Проследимостта на спецификацията на изискванията и описанието на проекта е от изключителна важност с оглед на бъдещи изменения. Проблемът за съгласуваността между документацията и реализирания програмен код остава нерешен, тъй като изменението на документите се счита за второстепенно, от гледна точка на текущите изменения, тъй като може да не е валидно при следващите изменения.


1.2.4. Моделиране

Спецификацията на изискванията по-горе бе посочена като критична за успеха на процеса на разработване. Грешки в спецификацията, открити след стъпката на реализиране, са обикновено изключително скъпи за коригиране. Доброто разпознаване на потребителските нужди е от жизнена важност за крайния успех. Независимо от усилията за подобряване на качеството на анализа на изискванията и спецификация-та, обаче, проблемите с непълнотата, несъгласуваността и неяснотата в спецификацията остават нерешени.




^ Фиг. 1.11. Подходът на моделиране намалява разходите и усилията

при разработване и поддържане

Подходът на моделиране включва построяване на работен модел (прототип) на системата, която трябва да се разработи. Прототипът се представя на потребителя, който може да усети и види рано резултатите. Преди завършването на спецификацията, прототипът може да се измени с цел проверка на различни възможности. Има две главни разлики между прототипа и крайния продукт: първо прототипът не трябва да посреща изискванията за техническите характеристики и борави само с функционалността на системата; второ - може да бъде непълен и може да отразява само една гледна точка за системата, която трябва да се разработи, например, споразумения за комуникацията човек-машина.

Моделирането подхожда добре на модела на жизнения цикъл на системата, описан по-горе. Прототипите се построяват и проверяват по време на етапа на анализ на изискванията. След проверката за валидност, прототипите могат да бъдат оставени на страна и процесът на проектиране и реализиране може да започне. Главното предимство на прототипите е по-доброто разпознаване на потребителските нужди и по-надеждната ранна проверка на валидността на поведението на системата и нейния интерфейс с външния свят. Това води до намаляване на разходите и усилията за поддържане по време на експлоатация.

От друга гледна точка, разработването на прототип е само по себе си проект, т.е. той трябва да бъде описан неформално, проектиран и след това реализиран. За да бъде оправдано от гледна точка на организацията на проекта, разработването на прототип трябва да бъде направено в кратки срокове и неговите разходи не трябва да превишават обикнове-ните разходи на етапа на анализ на изискванията. Възможно е използва-нето на съответни софтуерни средства: езици за моделиране, приложни пакети. В много малко приложения за обработка на данни, които са слабо свързани с ефективността на компютъра, прототипът може да посрещне всички системни изисквания и така да стане годен за реализиране.

Моделирането на системи за работа в реално време е много сложно, тъй като функционалността и техническите характеристики не могат да бъдат отделени. Това води до концепцията за изпълнима спецификация (т.1.2.6), която описва изискванията и в същото време дава възможност прототипа на системата да бъде проверен чрез симулация.


1.2.5. Обектно-ориентирано проектиране

Проектирането е втората критична част от жизнения цикъл на софтуера. Традиционният модел на жизнения цикъл се осланя на функционална декомпозиция отгоре надолу. На всяка следваща стъпка се уточняват и изчистват функциите, определени на предишните стъпки, като се прави пълно описание на системата на все по-високо ниво на детайлизиране. Мотивацията на такъв подход е да се намали сложността: голямата система се разделя на множество малки модули, които са по-лесни за разработване. На самия край по време на пакетиране на програмите логическите модули се поставят във физически модули, като по този начин дефинира физическата структура на кода за реализиране. Пакетирането се извършва, като се има предвид оптимизацията на техническите характеристики.

Слабо място в тази процедура е, че повечето критични решения, засягащи цялостната системна структура, трябва да бъдат направени много рано, когато проблемът е все още до голяма степен непознат. Нещо повече, тъй като декомпозицията е изпълнена главно във функционалната област, най-важните данни са глобални за цялата система. Това води до значителни проблеми по време на поддържане, когато представянето на данните трябва да бъде изменено в отговор на измененията в околната средата или в потребителските изисквания.

Обектно-ориентираният подход се базира по естествен начин на физическия или по-точно на математическия модел на процеса (явлението), което се моделира. Той вгражда в себе си концепциите за абстрактни типове данни, информационно скриване и наследяване. Ключово положение е, че програмната структура трябва да моделира структурата на реалния свят, в който е дефиниран проблемът.

Реалният свят се състои от различни единици, които взаимодействат една с друга. Следвайки тази структура, софтуерът който трябва да се разработи, се разглежда като множество от обекти. Всеки обект се състои от данни и множество от операции, изпълнявани от и върху него. Операциите върху обектите са само действия, които изменят данните, съдържащи се вътре в обекта. Детайлите на представянето на данните са скрити, т.е. не са видими, не са достъпни за други обекти. Всеки софтуерен модул обозначава обект или клас от обекти, извлечени от пространството на проблемите.

В неговата сегашна форма обектно-ориентираното програмиране е метод приложим за стъпките на проектиране и реализиране в традиционния модел на жизнения цикъл. Главните стъпки на метода са:

1. Идентифициране на обектите.

2. Идентифициране на операциите позволени за и изисквани от всеки обект.

3. Определяне на интерфейсите между обектите.

4. Проектиране и реализиране на операциите.

Важно различие между традиционното проектиране и обектно-ориентирания метод е инверсията на пакетирането на програми, което определя физическата структура на софтуерния елемент (стъпки 1, 2) и функционалното изчистване (стъпки 3, 4).

Ако се върнем на горния пример за обслужване на повикванията в автоматична телефонна централа, могат да се дефинират следните обекти: абонатна линия, път за свързване и съединителна линия. Като пример, да разгледаме ресурса абонатна линия. Той се дефинира като обект, който се заема чрез заявка и се използва според неговото вътрешно състояние (свободна или заета) и приетите команди, например, "заемане", "приемане на цифри", "разпадане". По аналогичен начин могат да се дефинират и останалите обекти в системата, например разговорен път, съединителна линия (за връзка с други централи). Всеки ресурс, дефиниран като обект има следните характеристики:

 има свое собствено състояние, функция, която изпълнява и външен логически интерфейс;

 заема се и се освобождава със заявки;

 има много екземпляри на един и същ ресурс.

На всеки обект (логически ресурс) се съпоставя програмна единица, която:

 има структура на данните, която представя вътрешното състояние на ресурса;

 има програми, които се изпълняват щом дойде команда за използване на ресурса;

 обръщението към програмната единица става чрез формиране на заявка.

Ако софтуерът трябва да бъде изпълнен в многозадачна среда, обектите могат да бъдат реализирани, като съвместно действащи паралелни процеси. В среда с последователно изпълнение на задачи трябва да бъде разработена трансформираща функция, която изрично дефинира управляващия поток.

Предимствата на обектно-ориентирания подход са очевидни на стъпката на поддържане. Всички важни характеристики на реалните обекти са капсулирани в техните изчислителни модели, и всички изменения в средата водят само до локални изменения вътре в дадени обекти. Нещо повече, всички важни данни са скрити и защитени в модулите обекти и изменения в представянето на данните не се разпространяват извън границите на обектите.


1.2.6. Реализиране с трансформиране

Най-съзидателната част в процеса на софтуерното инженерство е анализът на изискванията и спецификацията. Веднъж, след като е конструирана пълна и недвусмислена спецификация, тя описва детайлно поведението на системата, която трябва да бъде разработена. Семантиката на това описание не трябва да се изменя в процеса на проектиране и реализация. Това води до концепцията за автоматична трансформация на спецификацията на изискванията в изпълнима реализация.

В подхода на реализирането с трансформиране изпълнимата спецификация съдържа първия прототип на системата, която трябва да се разработи. След проверката за валидност на спецификацията, тя може да бъде обект на серия трансформации. Трансформациите изчистват функциите и дефинициите на данните, изменят структурата и техническите характеристики, като съхраняват функционалността на системата. Трансформациите могат да бъдат избрани ръчно, но се изпълняват автоматично. Резултатът от трансформацията е изпълним и формира следващия прототип на системата, която трябва да се разработи. Успешните прототипи се проверяват, оценяват и се изследва компромисът между функционалността, техническите характеристики и разходите. Когато изискванията са посрещнати, процесът на проектиране завършва с формално и изпълнимо описание на проекта, което автоматично се транслира в реализация.




^ Фиг.1.12 Модел на трансформиране с реализиране


Предимствата на този нов подход са очевидни. Трудоемките стъпки на проектиране, реализиране и тестване изчезват, и процесът на разработване се разглежда, като състоящ се от анализ на изискванията и спецификация, и оценяване, трансформиране и генериране на кода на реализация

(фиг.1.12). Единственият трудоемък етап е спецификация на изискванията. Продуктивността на процеса на разработване може да се увеличи значително. Основната документация на системата съдържа изпълнимата спецификация на изискванията. Поддържането не се изпълнява вече върху кода. Спецификацията е тази, която се изменя, след това трансформира и повторно реализира, точно както по време на оригиналния проект на разработване.

Спецификацията, базирана на SDL, е изпълнима и нейната функционалност може да се демонстрира и оцени чрез симулация на системата, при условие че дадени функции са били програмирани, (моделирани) на език от високо ниво. На стъпката на трансформиране дефиницията на функциите и данните могат да бъдат изчистени и структурата на системата може да бъде модифицирана, за да се посрещнат изискванията на средата за изпълнение.

За да бъде успешно въведен в инженерната практика, подходът на реализиране с трансформиране трябва да бъде осигурен с методология, и мощно множество от софтуерни средства.


1.2.7. Оценка на методите за разработване

Съвременният инженерен опит показва, че досега класическият подход към разработване на софтуера е най-разпространен и най-успешно прилаган. Той предлага не само доказани в областта методи за разработване и компютъризирани средства, но и дисциплиниран и управляем процес на разработване. Недостатък на подхода е, че голям брой софтуерни проекти, разработени по този начин не могат да се включат в границите на крайните срокове и бюджетните средства, предварително дефинирани за тях.

Моделирането се разглежда като полезен метод за част от жизнения цикъл, осигуряващ стъпката на анализ на изискванията и спецификацията. Обаче, той е труден за използване в големи проекти. Това води до заключението, че наличните е момента средства не са достатъчно развити.

Обектно-ориентираният подход бързо изплува, като главен реквизит за ефективно софтуерно разработване. В днешно време обаче, подходът не предлага строг, добре дефиниран метод с индустриални стандарти. В момента се правят интензивни усилия в тази област.

Реализирането с трансформиране е най-обещаващия метод за в бъдеще, тъй като предлага радикално решение на софтуерната криза. Този подход пряко съответства на формалните методи за програмно конструиране и настройка, тъй като трансформацията трябва да бъде коректно доказана. Досега обаче, изследванията в двете насоки, се правят независимо. Вероятно това е защото, нито един от съществу-ващите методи и средства не е в състояние да предложи пълния потенциал на този метод за проектиране.

Най-прагматичният подход за разработване на софтуер е комбинацията от класическите методи и възможностите за моделиране. Множество компютърно-ориентирани софтуерни инженерни средства (CASE системи), които осигуряват този подход са налични на пазара.

Сравнението на методите за разработване показва, че нивото на автоматизация нараства от традиционния подход към подхода на трансформационното реализиране. Това не означава обаче, че най-накрая автоматични средства ще решат проблемите на разработване на софтуера. Проблемите винаги ще се решават от хора. Но средствата ще изпълняват дейности, които не изискват съзидателни усилия, следователно ще предоставят на проектанта повече време за оценка на най-критичните решения.


1.2.8 Технологичност на софтуера за работа в реално време

Днес главният проблем на програмното осигуряване на системи за работа в реално време е да се направи то технологично. Старите проблеми, като икономия на памет и машинно време например, или отпадат, или остават на заден план. Стремежът към технологичен софтуер е мотивиран от три причини. Едната е необходимостта да се увеличи производителността на големия щат от програмисти. Другата причина се отнася за условията на експлоатация на системите за работа в реално време. Обикновено периодът на експлоатация на тези системи се измерва с десетки години. През този период се очакват много промени. Например, в телекомуникационната индустрия, измененията в съобщителната мрежа, добавянето на нови видове съобщителни услуги и нови видове телефонни услуги, необходимостта от добавяне на нови функции или разширение на централите, налагат и съответни изменения в програмното осигуряване. Третата причина е необходимостта софтуера да бъде отворен за бъдещите и непрогнозируеми изменения в апаратната част от развитието на полупроводниковите технологии. Големите инвестиции, вложени в програмното осигуряване на една система за работа в реално време, задължават създателите й да се опитат да й осигурят дългогодишно производство.

Казаното обяснява защо усилията са насочени към непрекъснато развитие на информационните технологии (фиг.1.13).





Фиг.1.13. Главният проблем на телекомуникационния софтуер

е той да се направи технологичен


През последните няколко години прилаганите информационни технологии в телекомуникационната индустрия са показали отлични резултати в:

 използването на метода на виртуалните машини при проектира-нето на софтуерна структура и използваните езици за програмиране;

 използването на препоръките на МСД за езика за спецификация и описание SDL и по-специално неговата графична форма;

 използване на препоръките на МСД за езика за програмиране от високо ниво CHILL;

 използване на стандарт за дефиниране на интерфейса между операционната система и приложния софтуер, което осигурява преноси-мост на приложенията;

 използване на модерни приложения на системите за управление на бази данни;

 въвеждането на обектна-ориентация в процеса на разработване на софтуера, при дефиниране на архитектури, в езиците за програмиране, операционните системи и системи за управление на бази данни;

 разработване и използване на експертни системи в области, къде-то се налага управление на сложни проблеми и където конвенционалната компютърна технология не може да бъде от полза;

 прилагане на технологията на невронните мрежи, които моделират човешкото мислене в целия спектър на проектиране;

 постепенно въвеждане на новата комуникационна архитектура, наречена интелигентна мрежа, която ускорява и опростява въвеждането на нови услуги.

Тези технологии се развиват до голяма степен изолирано една от друга, независимо от факта, че всяка от тях притежава свойства, съответстващи на другите. На съвременния етап усилено се работи върху интегрирането на всички тези технологии.

За да се разбере къде е силата на всяка една от тези технологии, по-долу ще се изброят техните ключови характеристики.


Структура на софтуерните нива и езиците за програмиране

Съвременният подход към разработването на индустриални системи за контрол за работа в реално време използува принципа на разделяне на нива. Най-долното ниво (ядрото) е това на апаратната част. Софтуерът се реализира, като обвивка на апаратната част, като всяко следващо ниво представлява абстракция на по-долните нива.

Главното предимство на приложението на този метод, наречен още метод на виртуалните машини е, че програмистите на дадено ниво няма нужда да знаят подробности за реализирането на функциите на по-ниските нива. Друго не по-маловажно предимство е изолирането на влиянието на промените в апаратната част. Влиянието на някакво изменение (поради приложението на някаква нова полупроводникова технология, например) е ограничено до малки области във виртуалната машина. Така замяната на даден компютър изисква изменения само в опера-ционната система и по този начин не влияе върху приложните програми (фиг.1.14).

Друг тип виртуална машина се получава, когато се използват езици от високо ниво. В този случай програмистът работи с машина,




която разбира операторите на езика от високо ниво, а в действителност реалната машина (компютърът)

работи само с машинен код. Връзката между изходния (от високо ниво) код и обектния (машинен) код се дава чрез помощните програми (външното програмно осигуряване).

Архитектурата на приложния телекомуникационен софтуер не е предмет на курса и е разгледана в [7].



^ Фиг. 1.14. Разделена на нива софтуерна архитектура


Езици за проектиране

Съществува голямо разнообразие от езици за проектиране, но ефектът от тях се чувствува само, ако има средства за тяхното използване. Ако тези средства могат да се разберат и използват по лесен начин, ако са евтини и бързи за изпълнение, тогава може да се твърди, че езикът е добър.

В областта на телекомуникациите, за да въведе международен стандарт за проектиране МСД е разработил езика SDL (Specification and Description Language). SDL е език за обмен на информация между хора. Този обмен има две посоки:

 потребителят съобщава на производителя какви функции трябва да изпълнява системата, т.е. прави спецификация;

 производителят казва на потребителя какви функции може да изпълни предлаганата система, т.е. прави описание.

SDL e насочен главно към описание на логическите функции в централата, между централите и между централата и външната среда. Логическите функции се изпълняват от процеси, като се отчитат специфичните особености на процесорното управление в реално време, а именно:

- наличие на голям брой едновременно изпълнявани еднакви или различни процеси;

- процесите се изпълняват на стъпки, като всяка от стъпките се стартира от събития, външни за самия процес;

- стартиращите събития могат да носят и допълнителна информация, освен информацията, която се получава от факта на появата им.

С SDL се описват на различни нива на детайлизация на комутационната система функциите на системата или функциите на отделните нейни детайли.

Създадени са много SDL средства, които осигуряват среда за използването му. Не е трудно да се предскаже разширяване на приложението на SDL - освен за проектиране на комутационни системи за тестване и верификация директно нa ниво SDL. Докато сега има сравнително малко на брой и скъпо оборудвани работни места, които осигуряват възможности за графично редактиране на SDL, в близко бъдеще този брой значително ще се увеличи. Средата за професионално графично редактиране увеличава продуктивността на програмното осигуряване около 30% по време на разработката му.

Малко по-проблематично стои въпросът за интерфейса на SDL с езиците за програмиране, независимо от тяхното ниво. Преходът от много високо ниво на интерактивно редактиране и интерпретиране главно в графична форма надолу към интерактивно редактиране от високо ниво, интерпретиране, компилиране, свързване, тестване и по нататък към ниското ниво на представяне на машинен език (ако въобще е необходимо) ще бъде възможен по много бърз и традиционен начин. Вследствие на това програмистът ще може да определи до кое ниво на езика да стигне. Решението ще зависи главно от изискванията за ефективност на времето и паметта на съответната система. Средствата трябва да дават възможност да се интерпретира, симулира и изпълнява на различни нива, като по този начин голям обем програмни модули ще могат да бъдат автоматично генерирани и интегрирани.

Общи сведения за езика SDL са дадени в точка 2.2.1.


Езици за програмиране

Независимо от описания в предната точка сценарий за използване на езиците за проектиране, езиците за програмиране няма да загубят своята важност. Машинно-ориентираните езици ще се използват само за много специални и апаратно зависими цели. Езиците за програмиране от високо ниво все още ще играят най-важната роля при реализирането на функционалните детайли и характерните свойства и в бъдеще.

Проектантите на комутационен софтуер ще разчитат на CHILL (и всички други езици от високо ниво, които се използват сега). CHILL (CCITT High Level Language) е език от високо ниво за програмиране. Областта на използване на езика включва създаване на програми за: обработка на повикванията; контрол и диагностика; операционни системи; настройка и изпитание на програмното осигуряване. CHILL не се опитва да предостави специфични конструкции за всеки от изброените по-горе случаи на използване, а дава обща база с различни възможности, подходящи за конкретни приложения. Общи сведения за езика CHILL са дадени в точка 2.2.2.

Важна роля ще играе така нареченото интерактивно програмиране. Степента на взаимодействие между средствата и програмиста значително ще нарасне. Сега програмистите използват отпечатаните резултати само като документация, т.е. сами коригират допуснатите грешки. Утре така нареченият синтактично-ориентиран редактор, или редактиращ интерпретатор или итеративен компилатор ще стане партньор на програмиста, а не негов ням слуга. Той ще дава предложения за коригиране на грешки, ще предлага по-добри решения за някои конструкции, ще посочва оператори, чието изпълнение ще бъде критично по отношение на време и памет и др. Тъй като хардуерът ще осигури достатъчно памет и висока скорост на изпълнение, в обработващите езикови средства може да се вгради голямо количество "интелигентност", така че те да могат да правят коректни допускания за желанията и намеренията на техните потребители. Това драстично ще намали обема на ръчния труд на програмиста и по този начин ще бъде ключов фактор за увеличаване на продуктивността на програмното осигуряване.

Обратно на хардуерните технологии, за софтуерните езици е необходим дълъг период от време, за да се утвърдят. И когато те се наложат, е необходимо дори повече време да бъдат заместени с други по-добри.


Операционни системи

За да посрещнат специфичните изисквания на хардуерната архитектура за телекомуникационните системи, производителите са разработили специфични операционни системи, върху които те разработват специфични телекомуникационни приложения. Очевиден недостатък на тази стратегия е, че сериозно се намалява възможността за вграждане в системата на приложения, закупени на пазара. Друг важен недостатък е, че преносимостта на приложенията от система с общо предназначение към специфичната система изисква емулацията на операционната система. Сега тази преносимост е от особена важност, тъй като обикновено тестовете на отделните единици се изпълняват върху системата с общо предназначения, докато интегриращите тестове се изпълняват върху специфичната система.

Обещаващ начин за решаване на този проблем е използването на стандартен интерфейс между операционната система и приложението. В литературата се срещат описания на този подход, базирани на Unix.

Основните принципи на построение на операционните системи са разгледани в глава 3.


Модерни приложения на системите за управление на бази данни

Съвременните комутационни системи използват организация, ориентирана към бази данни, например за експлоатация на програмното осигуряване. За да осигури абонатите със съответните видове услуги, централата се нуждае от база абонатни данни. Отделни бази данни са необходими за бъдещи промени, за административно и техническо обслужване.

Класическата форма на системите за управление на бази данни е проектирана за управление на важни, но ограничен брой приложения. Общите характеристики на такива приложения са, че те поддържат голямо количество данни, но операциите, които могат да се изпълняват върху данните са прости.

Съществуват два общи подхода, които предлагат решение на проблема за комбиниране на възможностите за бърз достъп на езика за операции с данни и възможностите за операции върху данни, предлагани от езиците с общо предназначение. Обектно-ориентираният подход е да се използва език с възможности за дефиниране на абстрактни типове данни или класове. Тези системи разрешават на потребителя да вгражда структури от данни за бърз достъп в своите класове. Логическият подход използва език, който наподобява логически правила (if ... then). Системите за управление на бази знания осигуряват единствен декларативен език, който играе ролята и на език за операции с данни и на език с общо предназначение.

Базите данни формират критичната част на софтуера, който се изпълнява в телекомуникационните мрежи и който разрешава гъвкавост, което е целта на модерните интелигентни мрежи.

Глава 4 прави въведение в теорията на базите данни.




Обектно-ориентиран подход

Обектната-ориентация, идеята за която беше дадена в т.1.2.5 е нов подход както за проектиране, така и за реализиране. Счита се, че той предлага значителни предимства пред традиционния структурен подход. Благодарение на свойства, като капсулиране и наследственост, обектната ориентация може с успех да се прилага в области, критични за софтуерното инженерство. Например, обектната ориентация е полезна при разширяване на софтуерния продукт (типично поради изменения във функционалната спецификация) и при необходимост от многократно използване на софтуерните модули.

При модулното проектиране на програми основният проблем е как решението на задачата да се разложи на серия от подзадачи, които могат да се програмират. Ако подзадачата е сложна, тя отново се разделя на по-прости подзадачи. По този начин в центъра на вниманието на програмиста е създаването на текста на програмата, вместо то да бъде съсредоточено върху вътрешната структура на явленията и тяхното взаимодействие. В резултат се получава програма, чиято структура е обвързана много силно с поставената задача.

Нормално е в процеса на създаване на софтуер, а и след това при неговата експлоатация, потребителят да изисква промени в първоначално поставената задача. В резултат на това в структурата на програмите се налагат промени, които да отразяват потребителските изисквания. Когато програмата е малка и обозрима, това не е особен проблем. С нарастване на обема на програмите и техния брой се изискват все повече промени на различни места в програмния код.

Програмите се създават, за да извършват определена полезна дейност. В комутационната техника, те моделират реални процеси. Характерно за обектно-ориентирания подход в програмирането е, че програмата се конструира, като се изхожда от физическия или по-точно математическия модел на процеса (явлението), което се моделира. Ако по своята структура и по изпълнението си създадената програма е близка до явлението или обекта, за който се отнася, се счита, че тя е обектно-ориентирана.

Изборът на език е по-малко важен от гъвкавата обектна структура. Най-атрактивен от групата на обектно-ориентираните езици на съвременния етап е С++, който се използва от програмистите в най-големите софтуерни компании за реализирането на големи индустриални проекти. Други езици, които се използват са Smalltalk и Eiffel.

В света на софтуера обектната ориентация предлага техническа платформа, на която може да се стъпи, независимо от приложните интереси. Основните положения в обектно-ориентираната технология са разгледани в глава 5.


Експертни системи

Експертните системи представят най-развития клон на изкуствения интелект. Експертна система превзема знанието на експертите в дадена област и го транслира в език на експертната система; обикновено този език е декларативен - описва знанието под формата на правила if ... then ... else ... . Когато на потребителя е необходима експертиза, експертната система се изпълнява; механизмът за вземане на решение генерира правилата. В последните години се наблюдава интензивно използване на експертните системи в много области.

В света на телекомуникациите експертните системи могат да се използват за различни цели. Най-голямо приложение намират при контрола и диагностиката, както при поддържане на комутационни системи, така и при поддържане на мрежи. Причините за това са следните: сложност на проблемите в областта; необходимост да се направи достъпно за широк кръг от оператори знанието на малък брой експерти; необходимост от взаимно решаване на проблемите между системата (или мрежата) и оператора.

Глава 6 прави въведение в теорията на изкуствения интелект.


Невронни мрежи

Накратко, невронните мрежи могат да боравят с неточни и непълни данни, да се тренират, да се и обучават, като се адаптират към изменящата се околна среда, да обобщават в ситуации, които не са им познати, и да се изпълняват много бързо веднъж, след като са тренирани.

Проектите, изградени на базата на невронна мрежа работят върху проблеми, свързани с обработка на естествения език - такива като разпознаване и синтезиране на реч, и преобразуване на текст в реч.

Невронните мрежи функционират много добре в ситуации, където за да се достигне дадена цел, трябва да се направят много стъпки, а изборът на всяка стъпка е сред много възможни. Проблемът е, че има твърде много възможности, които трябва да се опитат в допустимо време на компютърна система с дадена изчислителна мощност.

Невронните мрежи се използват за маршрутизиране на трафика в телефонната мрежа, при проектиране на електронни платки определят мястото на чипа с цел оптимално опроводяване и други подобни проблеми, свързани с назначаване на ресурси. Освен при маршрутизация за минимизиране на закъснения, понякога те трябва също да могат да отговорят бързо на радикално изменящата се околна среда на системата. Невронната мрежа може да не намери най-доброто решение (което би могло да отнеме значително време дори и на суперкомпютър), но намира достатъчно добър отговор.

Основните понятия, свързани с невронните мрежи, са представени в глава 6.


Интелигентни мрежи

За бъдещите телекомуникационни услуги се очаква да бъдат реализирани чрез все по-широко използване на различни функции по обработка на информация от компютри, свързани в мрежите. Разработването и внедряването на тези услуги ще се ускори и опрости чрез постепенното внедряване на архитектурата на Интелигентните мрежи.

Интелигентните мрежи се характеризират с: увеличено използване на елементите на мрежата, които се управляват чрез или взаимодействат със софтуера; използване на общи данни и разпределена обработка сред елементите на мрежата; необходимост от стандартни интерфейси между мрежовите елементи; и потребителски изисквания за по-интелигентни телекомуникационни услуги.

Основните идеи зад Интелигентната мрежа са:

 Отделяне на основния процес на комутация и контрол на повикванията от софтуера, който дефинира и управлява специфични услуги;

 Конструиране на софтуера на услугите от ограничен брой стандартни, многократно използваеми софтуерни модули, които дефинират елементарни услуги и функции на мрежата, и осигуряване на генерираща функционалност на мрежата, върху която те могат да се разработят и доставят;

 Осигуряване на контролен механизъм, който посредничи между софтуерните модули на услугите и сигнализацията на мрежата.

Резултатът е възможност за непосредствено и еднородно осигуряване на всички услуги, които могат да бъдат конструирани от тези модули. Дейностите на много фирми производителки в областта на Интелигентните мрежи в световен мащаб и необходимостта от стандартизация и еволюция в тази област са довели до разработването на глобална програма от МСД, адресирана към международни стандарти и рамка за стандартизация на еволюцията към Интелигентната мрежа. Главната цел на програмата е да се дефинира нова архитектурна концепция, която ще посрещне нуждите на доставчиците на телекомуникационни услуги от "бързо, ефективно и диференциално задоволяване на техните съществуващи и потенциални пазарни нужди за услуги" и "да подобри качеството и да намали разходите по административното и техническо обслужване на услугите в мрежата".

Интелигентните мрежи, като нова софтуерна технология в телекомуникациите са разгледани в [8] и не са предмет на курса. Интелигентните мрежи са разгледани в контекста на базите данни и обектно-ориентирания подход за проектиране съответно в точка 4.13 и точка 5.5.3.


Контролни въпроси и задачи

1. Кое е по-важно в системите за работа в реално време да се отговори бързо или да се отговори на време?

2. Какви са техническите характеристики на системите за работа в реално време?

3. Какво означава твърдението, че система за работа в реално време е надеждна?

4. Какво означава твърдението, че система за работа в реално време е предсказуема?

5. Каква е целта при анализа на строги системи за работа в реално време: да се минимизира средното време за чакане или да се определи максималното време за чакане?

6. Какви са последствията при неспазване на крайните срокове за отговор в строгите системи за работа в реално време?

7. Каква е функцията на приложните програми в софтуера на системите за работа в реално време?

8. Каква е функцията на помощните програми в софтуера на системите за работа в реално време?

9. На коя стъпка при създаването на софтуера се прави проверка за верност?

10. На коя стъпка при създаването на софтуера се прави проверка за валидност?

11. От коя стъпка при създаването на софтуера резултатите са изхо-ден код и тестови резултати за всяка софтуерна единица?

12. От коя стъпка при създаването на софтуера резултатите са описание на софтуерния продукт и ръководства за оператора и потре-бителя?

13. Какво се описва с диаграмата на състоянията и преходите?

14. Какво се описва с диаграмата на потоците данни?

15. Опишете функционалността на система за управление на потре-бителски достъп до информационна система, в която: потребителят формира заявка за достъп до системата, която на свой ред обработва заявката и пита за идентификационен код и парола, при коректна идентификация поребителят формира заявка за операции с данни, а системата изпълнява неговата заявка.

^ 16. Опишете динамиката (управлението) на системата за управление на потребителския достъп.

17. Опишете функционалността на система за приемане цифри от номеронабиране, в която абонатът вдига микротелефонната гарнитура и избира цифрите на номера, като отчетете възможността за отказ от повикването по време на номеронабиране.

^ 18. Опишете динамиката (управлението) на системата за приемане на избрани цифри.

19. Вярно ли е твърдението, че при обектно-ориентираното проектиране се започва от общото към частното, като се прави функционална декомпозиция?

20. Вярно ли е твърдението, че изпълнимата спецификация е описание на готовия софтуерен продукт

21. Вярно ли е твърдението, че при реализирането с трансформиране изменения се правят върху кода на реализацията?

22. Обяснете какво се разбира под технологичност на програмното осигуряване.

23. Кои информационни технологии се използват в телекомуника-циите?


Използвана литература

[1] Halang A.Walfgang, Krzyszfot M.Sacha, Real-Time Systems, Implementation of Industrial Computerized Process Automation, Singapore:World Sientific, 1992

[2] Goldsmith, S. Practical Guade to Real-Time Systems Development, New York, N.Y. :Prentice hall International, 1993

[3] Keller, M., Software Specification and Design: A disciplined Approach for Real-Time Systems, New York, N.Y. :Weley, 1992

[4] Cooling, J.E., Software design for Real-Time Systems, London, Chapman nd Hall, 1991

[5] Habaux J.P., Software Engeering for Telecommunications: Bringing Research Results into Industrial Practice, Ann Telecommun., 47, n0 1-2, 1992, pp.25-37

[6] Цанков Б., Цифрови комутационни системи, София, Техника, 1992.

[7] Цанков Б., Е.Пенчева, Р.Голева, Програмно осигуряване на комутационни системи, Технически университет - София, 1993.

[8] Jan Thorner, Intelligent Networks, Artech House Inc., Boston, London, 1994



-36-pragmatika-i-ritorika-diskursa-v-periodicheskoj-pechati-sfera-subekta-i-virazhenie-ocenki.html
-37-globalizaciya-i-ee-posledstviya-uchebnik-dlya-11-klassa-obsheobrazovatelnih-uchrezhdenij.html
-37-rekreacionnoe-rajonirovanie-rossii-v-s-preobrazhenskij-protivopostavlyaet-dve-issledovatelskie-pozicii.html
-38-sborshik-inekcionnih-igl-edinij-tarifno-kvalifikacionnij-spravochnik-rabot-i-professij-rabochih-vipusk-16-razdel.html
-39-kontrolnie-ispitaniya-vodovodov-i-setej-spravochnik-izdanie-3-e-pererabotannoe-i-dopolnennoe.html
-4-afinskoe-gosudarstvo-v-v-v-do-n-e-istoriya-gosudarstva-i-prava-zarubezhnih-stran.html
  • doklad.bystrickaya.ru/uchet-truda-i-zarabotnoj-plati-13.html
  • lecture.bystrickaya.ru/arkadij-mihajlovich-golicin-svobodnaya.html
  • credit.bystrickaya.ru/otchyot-za-pervoe-polugodie-2010-2011-uchebnogo-goda-stranica-10.html
  • literatura.bystrickaya.ru/soderzhanie-i-trebovaniya-k-nauchnomu-referatu.html
  • portfolio.bystrickaya.ru/opit-protivokorrozionnoj-zashiti-vagonov-dlya-perevozki-mineralnih-udobrenij-lapshin-v-f.html
  • institut.bystrickaya.ru/tema-5-administrativnie-organi-kak-subekti-administrativnogo-prava-uchebno-metodicheskij-kompleks-po-napravleniyu.html
  • esse.bystrickaya.ru/rabochaya-uchebnaya-programma-po-discipline-diskretnaya-matematika-razrabotana-v-sootvetstvii-s-federalnim-gosudarstvennim-obrazovatelnim-standartom-visshego-professionalnogo-obrazovaniya-i-uchebnim-planom.html
  • znaniya.bystrickaya.ru/realizuyushie-programmi-nachalnogo-i-srednego-professionalnogo-obrazovaniya-stranica-6.html
  • upbringing.bystrickaya.ru/konkurs-na-poluchenie-denezhnogo-pooshreniya-luchshih-uchitelej-obsheobrazovatelnih-uchrezhdenij-utverzhdayu-stranica-2.html
  • zadachi.bystrickaya.ru/proektirovanie-avtomatizirovannoj-informacionnoj-sistemi.html
  • otsenki.bystrickaya.ru/sekciya-fizika--subbota-25022012-g-obshaya-programma-xvi-respublikanskogo-konkursa-issledovatelskih-rabot-konferencii.html
  • control.bystrickaya.ru/byudzhetnij-federalizm-6.html
  • kolledzh.bystrickaya.ru/6-funkcionalnie-ispitaniya-elektrooborudovanie-vzrivozashishennoe-chast-7-zashita-vida-e.html
  • education.bystrickaya.ru/238data-dokumenta-rekvizit-11-instrukciya-po-dokumentacionnomu-obespecheniyu-obshie-polozheniya.html
  • laboratornaya.bystrickaya.ru/programma-seminara-sovremennie-aspekti-proizvodstva-bezalkogolnih-napitkov-assortiment-tehnologiya-oborudovanie-sanitariya-proizvodstva-kontrol-kachestva.html
  • nauka.bystrickaya.ru/ukazatel-tom-6-stranica-5.html
  • urok.bystrickaya.ru/pravovoe-prosveshenie-informacionnij-otchyot-municipalnogo-uchrezhdeniya-kulturi-neklinovskogo-rajona.html
  • education.bystrickaya.ru/05-11062009-g-s29-tema-stroitelstvo-stroitelen-kontrol.html
  • literatura.bystrickaya.ru/sokolov-v-v-filosofiya-duha-i-materii-rene-dekarta-vistorii-filosofii-tvorchestvo-rene-dekarta-1596-1650-odna-iz-samih-bolshih-vershin-odno-iz-velichajshih-d-stranica-4.html
  • knowledge.bystrickaya.ru/obshie-polozheniya-obrazovatelnaya-programma-nachalnogo-obshego-obrazovaniya-gbou-sosh-411.html
  • knowledge.bystrickaya.ru/o-prisyage-l-n-tolstoj-moemu-malenkomu-sinu-petrushe-s-nadezhdoj-i-veroj-v-to-chto-on-stanet-nastoyashim-oficerom.html
  • college.bystrickaya.ru/261-lyubimie-dvizheniya-detej-i-effekt-kachelej-nauchnij-redaktor.html
  • zadachi.bystrickaya.ru/socialnoe-planirovanie-sushnost-soderzhanie-i-vidi.html
  • thescience.bystrickaya.ru/gost-12405-81.html
  • student.bystrickaya.ru/22-rinochnaya-kapitalizaciya-emitenta-ezhekvartalnij-otchet-otkritogo-akcionernogo-obshestva-dorogobuzh-kod-emitenta.html
  • turn.bystrickaya.ru/polozhenie-o-proekte-uchashegosya-obshie-polozheniya.html
  • knowledge.bystrickaya.ru/nomera-urokov-programma-uchebnoj-disciplini-didaktika-sevastopol.html
  • crib.bystrickaya.ru/izbrannie-trudi-stranica-34.html
  • lesson.bystrickaya.ru/politicheskij-portret-liderov-v-sovremennoj-rossii.html
  • institut.bystrickaya.ru/tematicheskij-plan-prakticheskih-zanyatij-uchebnoe-posobie-dlya-studentov-pedagogicheskih-vuzov-po-specialnosti-031300.html
  • universitet.bystrickaya.ru/tema-orfoepicheskie-i-akcentologicheskie-normi-uchebno-metodicheskij-kompleks-po-discipline-russkij-yazik-i-kultura.html
  • thescience.bystrickaya.ru/iii-evolyuciya-cheloveka-valeologicheskie-aspekti-rossijskoj-federacii-v-kachestve-uchebnika-dlya-studentov-visshih.html
  • college.bystrickaya.ru/1uslovnie-oboznacheniya-polozhenie-o-laboratorii-cifrovih-obrazovatelnih-resursov-i-pedagogicheskogo-proektirovaniya.html
  • teacher.bystrickaya.ru/glava-20-obratnij-otschet-vyacheslav-shaligin.html
  • institute.bystrickaya.ru/glava-i-zadachi-poetiki-15-melodika-stiha-po-povodu-knigi-b-m-ejhenbauma-melodika-stiha-pb-1922-56.html
  • © bystrickaya.ru
    Мобильный рефератник - для мобильных людей.