Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
патологични ЖЦ. При тях някоя от фазите не е застъпена или пък непрекъсна-
тостта особено на връзката между разработването и съпровождането е разкъ- сана. Това се случва при някои разработки, когато тези две фази се възлагат на различни колективи. Ясно е, че такова равнище на подробност не би довело до адекватен модел, приложим за практически нужди, поради което Фокс въвежда още едно ниво за всяка от фазите, което съдържа разбивка на характерните за съответната фаза дейности („усилия", както ги нарича той). За разработването това са: Дефиниране на изискванията Проектиране •— Написване на програмите Сглобяване на програмите Тестване Документиране За съпровождането дейностите са следните: — Добавяне на нови функции 23 Усъвършенстване на съществуващи функции Добавяне на функции, свързани с промени в хардуера Отстраняване на установени грешки 2.3.4. Тримерен модел на Питърс—Tpun Този модел (1.2.2. по класификацията) представлява само теоретически ин- терес. Той е опит да се обхванат заедно различни страни на процеса на разра- ботване на софтуер, но като че ли третото въведено измерение, свързано с из- ползваните формални апарати, няма практическо значение (поне равностойно на останалите две измерения). Съгласно авторите, следва да се разглеждат три измерения (аспекта) на раз- работването на ПП — време, логика и формализъм. Фигуративно те могат да се представят като паралелепипед. Ние ще се задоволим с кратко описание на тези три измерения. Време. Това е вече срещаната хронологическа компонента и тя отразя- ва развитието във времето на ПП. Вероятно поради това, че чрез останалите две компоненти се допринася за по-пълното описание на ЖЦ на 1111, тук се отлича- ват само 4 фази — анализ на системата (ПП), проектиране, реализация и експ- лоатация. Логика. В това измерение се категоризират дейностите, които се извър- шват през отделните фази, дефинирани вече в първото измерение. Те са: опре- деляне на проблема и оценъчно проектиране, синтез на системата (ПП), анализ на системата, оптимизация, вземане на решение, планиране на действията. В тази съвкупност от дейности, която не е подредена случайно по този начин, смисълът на синтеза е да се създадат няколко алтернативни идейни проекта, на анализа — да се идентифицират и систематизират изводите и оценките на всяка от алтернативите, а на оптимизацията — да се подредят алтернативите по един или повече критерии. След тази дейност остава само да се вземе решение за избор на алтернатива. — Формализъм. В това измерение авторите включват необходимите спо- ред тях за разработването формални модели на ПП. Отличават се следните мо- дели по реда на тяхното възникване и реализация. Започва се чисто мислен модел, очевидно отразяващ първоначалните идеи на разработчика за ПП. Този модел се преобразува в структурен. Препоръчително е той да се базира на ня- какъв математически формализъм от рода на графи (евентуално някакъв фикси- ран тип графи — дървета, мрежи и np.). Последният модел е лингвистичен и той придобива формата на последователност от текстови оператори с определен синтаксис или семантика. С други думи казано, това е вече било проект на 1111 на определено ниво, описан формално, било ПП, реализиран във вид на опре- делен програмен език. 2.3.5. Частични модели Терминът „частични" вероятно търпи известна критика. Той е използван, за да се покаже, че в този тип модели по правило липсват съществени части от 24 естествения ЖЦ на ПП. Причината за това е, че тези модели се опитват да отразят т. нар. reuse техника, чийто смисъл е малко или повече използване на вече създадени компоненти от други ПП — програмни модули, проектантски решения, документация. Подходът на повторното използване се смята в мо- мента за изключително перспективен. Полагат се усилия за оценяването на резултатите от прилагането му, както и за разработването на подходящи инс- трументални средства — например библиотеки от модули за повторно изпол- зване с подходящи механизми за търсене на нужните на конкретния нов ПП компоненти. Като пример за такъв модел ще разгледаме предложения в [4]. Основното понятие в него е asset, чийто най-точен превод на български е като че ли не особено хубавата дума заготовка. Съгласно модела има няколко възможни рав- нища на ползване на заготовки. Съответната схема е дадена на фиг. 2.4. Във всички случаи прилагането на модела започва с оценка на изисквани- ята. Оттам нататък в зависимост от резултата първоначално става насочване или към ниво 3, или към ниво 2. Насочването към ниво 3 означава, че разработването на новия ПП е въз- можно практически изцяло на основата на заготовки. След подбора им следва сглобяването им и ПП е готов за разпространение. Следващ по сложност е вариантът с насочване към ниво 2. Прави се наст- ройка на избраните заготовки. На практика оттук са възможни два изхода: В първия случай настроените модули са готови за използване и се пов- таря процедурата от ниво 3 — пристъпва се към сглобяване. Във втория случай има настроени модули, които въпреки настройката не удовлетворяват изискванията. Тогава се отива на ниво 0. Възможно е оценката на изискванията да покаже, че не е възможно насоч- ване нито към ниво 3, нито към ниво 2. В този случай насочването е към ниво 1. 25 Там разработването на необходимите модули се прави на основата на идеи от достъпните заготовки. Оттук са възможни два изхода — точно както от наст- ройката на ниво 2. Последната възможност е ниво 0. Към процедурата на ниво 0 — проекти- ране и създаване на заготовки — не се отива непосредствено от оценката на изискванията. Насочването към нея е от ниво 1 или ниво 2, когато се е оказало, че получените програмни модули не отговарят на изискванията. Ясно е, че в този модел не са отразени някои от дейностите, характерни за разработването на ПП. Идеята е да се подчертаят най-важните и специфични дейности по използването на готови елементи. Изтегляне 2.27 Mb. Сподели с приятели:
|