Софтуерни технологии
ДЕЙНОСТИ,ОСИГУРЯВАЩИ РАЗРАБОТВАНЕТО НА ПРОГРАМНИ ПРОДУКТИ....57
Изтегляне 204.11 Kb.
|
- Навигация на страницата:
- ^ 6. КАЧЕСТВО НА СОФТУЕРА 70 Общи понятия 70 Модели на качеството на софтуера 71 7. СОФТУЕРНИ МЕТРИКИ
| 5. ДЕЙНОСТИ,ОСИГУРЯВАЩИ РАЗРАБОТВАНЕТО НА ПРОГРАМНИ ПРОДУКТИ....57
Откриване на дефекти 57 Съпровождане 64 Документиране 67 ^ 6. КАЧЕСТВО НА СОФТУЕРА 70 Общи понятия 70 Модели на качеството на софтуера 71 7. СОФТУЕРНИ МЕТРИКИ 83 Въведение 83 Измерването в софтуерното производство 83 Класификация на софтуерните метрики 84 Примери за софтуерни метрики 87 Методологични проблеми на използването на софтуерните метрики 91 5 3 .3.2. Методи и средства за проектиране Както всяка основна дейност в разработването на софтуер и проектиране- то може да се реализира по два начина: като ad hoc процес или като стандарти- зиран процес. В първия случай въз основа на утвърдените изисквания се изгот- вя неформализирано описание на естествен език, което служи за ръководство при съставяне на програмите. По-систематичен е подходът с прилагане на т. нар. структурни методи, които предлагат начини за описване и процедури за създа- ване на софтуерни проекти. 3.3.3. Emanu на проектиране Разграничават се два основни етапа на функционалното проектиране: пред- варително (понякога наричано външно) проектиране и детайлно (понякога на- ричано вътрешно) проектиране. Като резултат от предварителното проектиране се създава външният (архитектурен) проект. Той представя цялостната структура на софтуерната система и начините, чрез които тази структура осигурява кон- цептуалната цялост на системата. Създаденият външен проект обхваща: логическата организация на данните — трансформация на създадения при анализа модел на данните в структури от данни, необходими за реализация на системата; структурата на системата — основните компоненти, външнопроявими- те им свойства и отношенията между тях; интерфейс на системата — между отделните й части, между системата и други софтуерни системи и между системата и потребителя. При детайлното проектиране {component-level) софтуерната система се представя като йерархия от „черни" кутии, които трябва да се реализират като обособени програмни части, наречени модули. Модулът е функционално обо- собен и стандартно оформен елемент, който е основна, самостоятелно разра- ботвана, тествана и документирана единица. При първата стъпка се създава схема на структурата, описваща основните модули, потока на данните и потока на управление между тях. При втората стъпка се специфицират модулите. Все- ки модул има име и четири основни атрибута: вход и изход; основна функция; механизъм за реализация на функцията; вътрешни данни. 3.3.4. Memogu за описване на проекти Създадени са различни методи за описание на създаваните проекти, които се различават по степента си на формализираност и по нагледността и разбира- емостта на получените описания. Практиката показва, че все още се предпочи- тат неформалните методи поради съпротивата и на потребителите, и на проек- тантите. Възраженията на потребителите са, че формалните описания са твърде сложни и неразбираеми за тях и те не могат да участват ефективно в обсъжда- 42 нето и проследяването на създаваните проекти. Възраженията на проектантите срещу формализмите са следните: не всички софтуерни специалисти имат необходимата теоретична под- готовка (например в областта на дискретната математика и математическата ло- гика), за да овладеят съответния апарат и да го прилагат за сложните реални системи; някои класове софтуерни системи са сложни за формално специфицира- не поради необходимостта от паралелни обработки, работа в реално време и др.; в софтуерните организации няма достатъчна информация за съществу- ващите техники за специфициране на проекти и за съответните инструментал- ни средства, които ги подпомагат. Използваните техники за описания са: а) Графично описание Този вид описание е най-старият, доколкото блок-схемите са един от най- предпочитаните начини за описание на алгоритми. В последните години се по- вишава приложимостта му поради появата на графични редактори и на специа- лизирани софтуерни средства за графично проектиране. б) Таблично представяне Заимствано е от теорията на вземане на решения и се състои в съставяне на таблици, описващи анализираните условия и съответните реакции на систе- мата за всяка комбинация от осъществени или неосъществени събития. в) Текстови описания Този вид описания са с различна степен на формализираност и най-общо се делят на две: псевдокодове и езици за проектиране на програми (PDL — Program Design Language). Псевдокодът е ограничен и структуриран естествен език, обикновено анг- лийски. Речникът на езика включва глаголи, имена от речника на данните и запа- зени (ключови) думи за описване на логиката на извършваните действия. Син- таксисът на езика допуска комбинации от линейна конструкция, конструкция за описване на условия и конструкция за описване на цикли. По-долу следва схематичен псевдокод за специфициране на модули. Той е създаден на основа- та на описани в литературата псевдокодове и е успешно приложен в реални софтуерни проекти: С^ ПЕЦИФИКАЦИЯ НА МОДУЛ Module:<имe> Рurposе:<предназначение> Uses: <вход> Returns: <изход> Defines: <собствени данни> Functional details:<описани чрез псевдокод> Псевдокодът е неформален език — ограничен английски. Речник: = глаголи (прилагателните и обстоятелствените пояснения се пропускат по- ради нееднозначното им интерпретиране); = термини от речника на данните; = ключови думи за описване на логиката. 43 С интаксис: I. Последователни конструкции =. разказвателно описание на английски език; =. оператор за присвояване. II. Конструкции за условен преход: IF THEN ELSE < sequential_construct_S2> III. Конструкции за цикъл WHILE DO
END
FOR NEXT
DO .... UNTIL
Ра злични начини за описване на проекти са подходящи за различните про- екти или за части на един и същи проект. В [7] са описани следните критерии за сравняване на методите за описване на проекти: модулност; простота; леснота на редактиране; възможност за автоматично създаване и обработка (чрез съответни ре- дактори); съпровождаемост; удобство на представяне на данните; възможност за верификация; сложност на прехода „проект—програма" Изтегляне 204.11 Kb. Сподели с приятели:
|