Софтуерни технологии
4.2. Обектно ориентиран анализ и проектиране
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 4.3. Обектно ориентирано програмиране и тестване
- 4.4. Управление на обектно ориентираното разработване
- 4.5. Въвеждане на обектно ориентирания подход
- 5. ДЕИНОСТИ,ОСИГУРЯВАЩИ РАЗРАБОТВАНЕТО НА ПРОГРАМНИ ПРОДУКТИ
- 5.1. Откриване на дефекти
48 4.2. Обектно ориентиран анализ и проектиране Целта на обектно ориентирания анализ (OOA) е създаването на модел, представящ статичните и динамични характеристики на класовете и взаимоот- ношенията между тях. Създадени са различни методи за OOA, използващи раз- лични съвкупности от диаграми и означения, но преминаващи през едни и същи стъпки, обобщени в [1], както следва:
Проектирането на ОО-система изисква определянето на многопластова софтуерна архитектура, специфициране на подсистеми, които изпълняват ис- каните функции, описание на обектите (класовете), които са изграждащите бло- кове на системата, и описание на механизмите на комуникация, реализиращи потока на данните между слоевете, подсистемите и обектите. 49
 ОО-проектиране се извършва на две нива, съответстващи на външното и
детайлното проектиране при конвенционалния подход — проектиране на сис- темата и проектиране на обектите. При проектирането на системата се определя архитектурата на OO- приложение. Създаденият аналитичен модел се декомпозира на подсистеми, ка- то се описва предназначението на всяка подсистема и връзките между тях. Про- ектират се още потребителският интерфейс и логическата организация на дан- ните (т. нар. компонента за управление на данните). При проектирането на обектите за всеки обект (екземпляр на клас или подклас) се съставя интерфейсно описание и описание на реализацията [2]. Интерфейсното (протоколно) описание определя всички съобщения, получавани от обекта, и съответните операции, които обектът извършва при получаване на съобщенията. Описанието на реализацията (implementation description) специ- фицира свързаните с обекта структури данни и алгоритмите за всяка операция. За стандартизирано описание на моделите в обектно ориентираното раз- работване на софтуер е създаден т. нар. Unified Modeling Language (UML) [3]. Основните части на UML са: а) Представяния. Моделирането на сложните реални системи изисква описването на различни техни аспекти — функционални, нефункционални, ор- ганизационни и др. Така системата има няколко представяния от различна глед- на точка, като всяко представяне е проекция на цялостното описание на систе- мата в съответствие с избран аспект (ракурс). Поддържаните от езика UML представяния са:
б) Диаграми. Диаграмите са графи, описващи съдържанието на различни- те представяния. Езикът UML има девет различни типа диаграми (use-case dia- gram, class diagram, object diagram, state diagram, sequence diagram, collabo- ration diagram, activity diagram, component diagram and deployment diagram), чрез съчетаването на които се описват всички представяния на системата. в) Елементи на модела. Използваните в диаграмите концептуални обекти се наричат елементи на модела. Те представят основните обектно ориентирани елементи като клас, обект, съобщение и връзките между тях. Всеки елемент на модела може да се използва в различни диаграми, но смисълът и означението му не се променят. г) Общи механизми. Те осигуряват допълнителна информация за семанти- ката на елементите на модела или как да се разшири моделът за специфични процеси, системи или организации. Езикът UML може да се използва за моделиране във всички фази на разра- ботването и за всякакви софтуерни системи. Използването му се подпомага от 50 инструментални средства (индивидуални или интегрирани), които изчертават ди- аграмите, съхраняват информацията за всички модели и представянията им, оси- гуряват многопотребителска работа и дори могат да генерират автоматично код. 4.3. Обектно ориентирано програмиране и тестване Програмирането представлява превръщане на ОО-проект в програмен код. Класовете, дефинирани при проектирането, трябва да се опишат като класове в съответния ОО-език за програмиране като С++, Java или Smalltalk. Резултатът е програма, която може да се изпълнява. Особеностите на процеса на съставяне на програми могат да се намерят в ръководствата за съответните ОО-езици. Целта на ОО-тестване е същата, както и при стандартния подход — да се открият колкото се може повече грешки в рамките на определените за тестване- то бюджет и време. Поради специфичните черти на ОО-подход обаче съдържа- нието на основните дейности, свързани с тестването, е различно. Преди всичко е необходимо да се разшири обхватът на тестването така, че то да започва от най-ранните фази и първите обекти за тестване да бъдат моде- лите на системата, създадени след ОО-анализ и ОО-проектиране. Причината за това е, че всяка неоткрита грешка в тези модели би довела до грешки в програ- мите, които трудно биха се открили. Например основните семантични конст- рукции (класове, атрибути, операции и съобщения) се определят в модела, съз- даден след ОО-анализ, и неподходящият избор на всеки от тези елементи би довел до допълнителни и може би излишни усилия при проектирането и прог- рамирането. Затова ОО-тестване включва формалните проверки за правилност, пълнота и непротиворечивост в контекста на синтаксиса, семантиката и из- ползването на моделите, създадени след ОО-анализ и проектиране. Техники, определящи какво и как да се проверява, са описани в [4]. Друга съществена разлика е в стратегията за тестване, осигуряваща последователно разрастване на обектите, които ще се тестват. Така традицион- ното модулно тестване тук е тестване на клас, защото в ОО-контекст класът е най-малката тестируема единица, капсулирала данните (атрибутите) и операци- ите над тях. Вместо проверка на алгоритъма, както е в модулното тестване, при тестването на клас се проверяват операциите и промените в състоянията на класа. Вместо традиционното интеграционно тестване на съставена по някакви правила съвкупност от модули в ОО-системи се тества съвкупност от класо- ве. В зависимост от начина на съставяне на съвкупността от класове съгласно [5] интеграционното ОО-тестване може да бъде:
Системното ОО-тестване съвпада с традиционното, защото целта му е да изследва поведението на системата като цяло, без да се разглежда реализацията. 51
Генерирането на тестови данни зависи от метода на тестване (стресово, случайно, сценарийно) и от обекта на тестване — отделен клас или група от класове. Подробности могат да бъдат намерени в [5, 6]. 4.4. Управление на обектно ориентираното разработване Както ще видим в глава 9., стихийността в софтуерното производство се преодолява с прилагане на основните управленски техники. За разработването на ПП те са за управление на: процеса на създаване на софтуер, създавания продукт, софтуерния проект и човешкия фактор. 4.4.1. Управление на процеса на разработване Както беше описано в глава 2., препоръчва се всяка софтуерна организа- ция да избере модел на жизнения цикъл на ПП, който идентифицира подхода за разработване и определя последователността и съдържанието на основните фа- зи и/или функции. За ОО-разработване Г. Буч [7] предлага т. нар. рекурсивно- паралелен модел, схематично представен на фиг. 4.1. Той е много близък до спираловидния и до еволюционния модел, споменати в глава 2., и същността му е в разработването на последователно разрастващи и усложняващи се прототи- пи до окончателното изграждане на целевата система. За всеки прототип се извършват едни и същи дейности: планиране, анализ, проектиране, извличане на компоненти от библиотеката за повторно използване, конструиране на про- тотипа с налични и новоразработени компоненти, тестване и оценка от потре- бителя, определящ изискванията към следващия прототип. Моделът се различава от останалите подобни модели по рекурсивното повтаряне на дейностите (включително и на анализа и проектирането!) за всеки прототип и по възможността за паралелното им извършване за независимите компоненти на системата. За ефективно управление на рекурсивно-паралелното разработване ръко- водителят на проекта трябва да осъзнае, че планирането (определянето на стан- дартните задачи и графици) и измерването на развитието на проекта се извърш- ва за всяка независима компонента поотделно. 4.4.2. Управление на проекта и продукта Стандартните техники за управление на софтуерни проекти (вж. глава 9.) са приложими и при ОО-разработване, но съдържанието на някои от извършва- ните дейности е различно. Ще споменем някои съществени разлики: а) допълване на стандартните методи за оценяване на цената на разра- ботване, трудоемкостта и продължителността на софтуерен проект с разрабо- тените ОО-метрики, измерващи специфични за подхода елементи — сценарии на използване, основни и поддържащи класове и връзките между тях [8]; б) за проследяване на развитието на проекта се препоръчва стандартната техника с използване на контролни точки, но достигането им се определя по 52 53  специфичен начин. В [1] са описани критерии за определяне, кога е завършил
ОО-анализ (контролна точка 1), ОО-проектиране (контролна точка 2), програ- мирането (контролна точка 3) и тестването (контролна точка 4). Например кри- териите за завършване на ОО-анализ са:
— Класовете за многократно използване са идентифицирани. Аналогични критерии са зададени и за останалите контролни точки. в) управлението на проекта и управлението на продукта се преплитат по- ради специфичното покомпонентно разработване при ОО-подход. Една от особеностите на ОО-разработване е, че всяко приложение може да се изгражда чрез компоненти. Под компонента се разбира клас, който е създа- ден и съхранен, с определено ниво на качество и степен на общност, която позволява да се използва многократно. 
На фиг. 4.2. е показана схема, илюстрираща управлението на проекта и про- дукта при ОО-разработване с използване на библиотека от компоненти. Организи- зацията на проекта е подчинена на краткосрочни цели като завършване на проекта в определения срок и в рамките на бюджета. Организацията на продукта преследва по-дългосрочни цели — създаване на компоненти за многократно използване. По- ради специалните изисквания към тези компоненти (да са с проверено и високо качество, да решават клас от сродни проблеми, да са подробно документирани) цената на разработването им е по-висока. Това се компенсира с намаляването на| цената за изграждане на приложения и намаляване на усилията за съпровождане. 54
Както е показано на фиг. 4.2., разграничени са три групи изпълнители на
Програмистите на приложения трябва да имат знания за приложната об- ласт и способност за абстрактно мислене. Те трябва да определят кои обекти трябва да се групират, за да се изгради приложението. Затова те се интересуват не от детайлите и реализацията на компонентите, а от същността им и за какво могат да се използват. Програмистите на компоненти трябва да проектират и реализират всяка компонента така, че тя да е настроеваема и да се използва лесно. Независимо че отговарят за изграждане и поддържане на библиотеката от компоненти, те учас- тват активно в началото на всеки проект, за да дадат информация, какви налич- ни компоненти има и как могат да се използват. Основните функции на стратезите са координиране и съветване. Те трябва да имат необходимата квалификация и опит в повторното използване (вж. гла- ва 13) като основен подход в софтуерната организация. Разполагайки със зна- ния за достъпните компоненти и начина им на вграждане в приложения, страте- зите са посредници между двете групи, като решават и по-глобални въпроси: какво да бъде съдържанието на библиотеката от компоненти, как да се оптими- зира описанието и търсенето на нужните компоненти в нея, какви автоматизи- рани средства да се използват и т. н. Различни са изискванията към квалификацията, опита, знанията и умения- та на трите категории софтуерен персонал и разпределянето на задълженията трябва да е съобразено с тях. 4.5. Въвеждане на обектно ориентирания подход Преминаването към ОО-разработване изисква планирани и систематични действия, успехът на които зависи от много фактори. Обобщавайки идеи от [9], ще изброим някои препоръки, следването на които би улеснило процеса на преход: — Обучение на персонала на софтуерната фирма на всички нива. Ръко- водството на фирмата трябва да осъзнае предимствата на подхода и да осигури !ясни цели, подкрепа и финансиране за периода от време, необходим за пости- гане на технологично ниво. Ръководителите на проекти трябва да бъдат специ- ално обучени, за да разберат и да могат да прилагат ОО-технология. Най-сери- озна трябва да бъде преквалификацията на разработчиците чрез осигуряване на подходяща литература, организиране на специални курсове и семинари за обмяна на опит с колеги от други софтуерни фирми. — Стартиране на пилотен проект за проверка, как разучените ОО-техники ще се прилагат в рамките на организацията. Размерът и сложността на пилотния проект трябва да бъдат такива, че той да се реализира от не повече от петима разработчици и за сравнително кратък период от време (от 3 до 5 месеца). За планиране и оперативно управление на проекта може да се привлече опитен специалист, който да ръководи проекта и да осигури документирането на въз- 55
информация. За следващите проекти се препоръчва прилагането на съвкупност от метрики за измерване на подобренията в процеса на разработване и произ- водителността.
Въвеждането на ОО-подход изисква предварителна подготовка и оценка на разходите и ползите за организацията, като единственият начин за проверка- та им е практическата реализация. Литература 1. Pressman, R. Software Engineering—A Practitioner's Approach. R.S. Pressman & Associates, Inc. 2000. 2. Goldberg, A., D.Robson, Smaltalk-80: The Language and its Implementation, Addison-Wesley, 1983. 3. Eriksson, H., UML Toolkit, Wiley Computer Publishing, 1998.
56 5. ДЕИНОСТИ,ОСИГУРЯВАЩИ РАЗРАБОТВАНЕТО НА ПРОГРАМНИ ПРОДУКТИ Процесът на създаване на софтуер може да се разглежда като съвкупност от основни дейности (напр. дефиниране на изискванията, проектиране, програ- миране) и допълнителни дейности. Характерно за допълнителните дейности е, че те са „фонови" и се осъществяват в продължение на няколко или дори всич- ки фази на жизнения цикъл. Типични допълнителни дейности ca:
Ще разгледаме някои допълнителни дейности, които са съществени за съз- даването на софтуера и на които не са посветени отделни части на учебника. 5.1. Откриване на дефекти Откриването на дефекти е част от цялостното осигуряване на качеството на софтуера (вж. глава 8.). Поради изключителната му важност ще го разгледа- ме като отделна дейност. 5.1.1. Основни понятия Качеството на програмните продукти е абстрактно понятие. Твърди се, че то трудно се дефинира, но е лесно да се разпознае при реалното използване на съответния програмен продукт. Една от трудностите при дефинирането е отно- сителният характер на качеството. Могат да се избират различни дефиниции в зависимост от интересуващия ни аспект на качеството, от това кой го оценява и кои са обектите, чието качество се изследва. В по-нататъшното изложение ще се придържаме към следната дефиниция: 57
Качествен е този програмен продукт, който удовлетворява формулирани- те към него изисквания. Всяко отклонение от изискванията ще наричаме дефект. Дефектите обикновено се дължат на една или няколко грешки. Под грешка ще разбираме неправилност, отклонение или неволно преина- чаване на обект или процес. В зависимост от това, в какъв софтуерен продукт се откриват, грешките могат да бъдат грешки в проекта, в програмата, в документацията, в тестовите данни и т. н. По-нататък ще разгледаме само грешките в програмите, дейностите за отк- риването и отстраняването им и средствата, подпомагащи тези дейности. Според Майерс в програмата има грешки, ако тя не изпълнява това, което потребителят разумно очаква от нея. Грешките могат да бъдат:
Съгласно друга класификация грешките могат да бъдат: а) технологични грешки — при въвеждане на програмите или при подго- товка на входните данни върху технически носители; б) алгоритмични грешки; в) програмни грешки — неправилно използване на конструкциите от съот-
г) системни — свързани с функциониране в определена операционна сис- тема. В зависимост от вида на грешките се прилагат различни техники за търсенето им. 5.1.2. Основни дейности за откриване и отстраняване на грешни Двете основни дейности, свързани с откриването и отстраняването на грешки в програмите, са настройване и тестване. Настройване (debugging) ще наричаме локализиране и отстраняване на установени грешки. Тестване (testing) ще наричаме изследване на програмите за установява- не на съответствието им с различни по степен на формализираност характерис- тики, правила и изисквания. Дейностите настройване и тестване се различават по основното си пред- назначение, по използваните методи и по нивото на сложност на откриваните грешки. Когато настройването завърши, е ясно, че програмата решава някакъв проб- лем. Предназначението на тестването е да докаже, че точно това е проблемът, който се иска да бъде решен. Връзката между тестването, настройването и поправянето на грешки може да се илюстрира чрез схемата на фиг. 5.1. Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|
