KNOW INTUIT, Лекция, Качество на софтуера

Здравина

Устойчивостта е способността на софтуера да реагира правилно при извънредни ситуации.

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

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

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

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

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

Разширяемост

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

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

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

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

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

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

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

Повторна употреба

Определение: повторно използване

Повторната употреба е способността на софтуерните елементи да служат за изграждане на много различни приложения.

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

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

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

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

Съвместимост

Съвместимостта е лекотата на комбиниране на един софтуер с друг.

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

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

Стандартни файлови формати, като в системата Unix, където всеки текстов файл е просто последователност от знаци.
Стандартни структури от данни, като в системата Lisp, където всички данни, както и програмите, са представени от двоични дървета (наречени списъци).
Стандартни потребителски интерфейси, както в различни версии на Windows, OS/2 и MacOS, където всички инструменти разчитат на една единствена парадигма за комуникация с потребителя въз основа на стандартни компоненти като прозорци, икони, менюта и др.

По-голяма общност се постига чрез дефиниране на стандартни протоколи за достъп до всички важни елементи, контролирани от програми. Това е идеята зад абстрактните типове данни и OO подхода, както и така наречения binder.междинен софтуер като CORBA и OLE-COM (ActiveX) на Microsoft.