Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 3.1. Модели на жизнения цикъл и подходи за разработване
- 3.2. Определяне на софтуерната система
32 а) административно-правни — свързани със съставянето на някои от доку- ментите:
Частта от групата, отговаряща за този тип дейности, включва и специалист с правно образование. б) технически — състоят се в осигуряването на:
в) изпитания от клас С — това са крайни изпитания, състоящи се в случаен избор сред готовите за разпращане комплекти от ПП и проверката им за качес- тво и комплектност. Документиране Съответната на тази функция група отговаря за създаването и поддържа- нето на потребителската документация. В нея се включват различните ръко- водства, инструкции, справочници, необходими на потребителя за правилното и ефективно експлоатиране на ПП. (Трябва да се прави разлика с вътрешната документация на разработчика, която се създава от други групи.) Групата включва специалисти с филологическо образование, евентуал- но специалисти, които изготвят потребителската документация на чужд език (ако ще се разпространява в чужбина). В по-големите фирми тук се включва и специалист по софтуерни технологии. Задачата му е да проектира струк- турата на потребителската документация, да определи подходящи примери за илюстрирането й, след завършването й да провери съответствието с дейс- твието на ПП. Изпитания Тази функция обхваща дейностите по установяване на наличието на де- фекти и на разлики между действителните свойства на ПП и спецификациите му. Разграничават се 3 вида изпитания: а) Клас А — вътрешни, извършвани от самите разработчици при програ- мирането и сглобяването на ПП. б) Клас В — независими, които се изпълняват от групата по изпитанията. в) Клас С — случайни, описани по-горе и извършвани от групата по обс-
Тъй като групата по изпитания се занимава с откриване на дефекти, тя се състои от висококвалифицирани специалисти информатици. Поддържане Тази функция обхваща всички дейности, свързани с преките контакти на фирмата производител с потребителите: 33
Съпровождане Обхваща всички дейности по внасяне на промени в готовия ПП:
Извършва се от разработчиците. Изисква най-високата възможна квалифи- кация, защото, както е известно, в повечето случаи внасянето на коректни изме- нения в съществуваща програма е по-трудно, отколкото създаването на нова програма. Съпровождането може да се извършва на различни равнища: а) гаранционно съпровождане — обикновено то включва задължения за
б) развитие на ПП и отстраняване на грешки; в) отстраняване на грешки; г) регистриране на съобщенията за грешки и на заявките за подобряване с оглед вземането им под внимание при евентуално разработване на нов подобен ПП. Режимът на съпровождане може да зависи от конкретно подписания дого- вор, ако има пряка връзка между разработчика и потребителя. На фиг. 2.7. са представени по хоризонталната ос фазите на ЖЦ на ПП, по вертикалната — функциите, а така също и интензивността на отделните функ- ции по време на отделните фази. Както обикновено се приема, колкото една функция се изпълнява по-интензивно, толкова по-наситен е цветът па предста- вянето. Литература
Фиг. 2.7. Модел на Гънтър 34 35 3. КОНВЕНЦИОНАЛЕН ПОДХОД ЗА РАЗРАБОТВАНЕ НА СОФТУЕР Когато текущото състояние на научното знание не е в състояние да удов- летвори очакванията ни, се оказваме в състояние на криза. Тази криза се следва от радикална смяна на научното знание, т. е. на начина, по който моделираме или правим нещо. Следователно сегашната ситуацията в софтуерното произ- водство не е нова — просто се преминава от един подход към друг с неизбеж- ните за такъв преход трудности, породени от необходимостта от усвояване и прилагане на нови идеи. В тази глава ще представим основните принципи на традиционния подход на разработване на софтуер, следвайки хронологичен модел на ЖЦ, последова- телните фази на който са определяне на софтуерната система, проектиране, програмиране, интегриране и тестване, използване.  3.1. Модели на жизнения цикъл и подходи за разработване
Проучването на специализираната литература показва, че продължава съз- даването на нови модели на ЖЦ. Поради стремежа да обхванат най-различни аспекти (технологични, организационни и икономически) новосъздаваните мо- дели са все по-сложни и оттам — все по-малко приложими в практиката. Затова в последно време усилията са насочени към разглеждане на noдxoдu за разра- ботване. Всеки подход за разработване определя основните правила, практики и процедури, които трябва да се следват в процеса на създаване на ПП. Подходите могат да бъдат с различна степен на общност. Някои от тях обединяват сродни методи. Например известни от литературата са подходът за разработване съгласно целите (чрез проследяване на изискванията или чрез про- тотипиране) или подходът с управление на риска. Най-общите фундаментални подходи се наричат парадигми. Ще разгранича- ваме два такива подхода: традиционен (конвенционален) и обектно ориентиран. Традиционният подход се е формирал с възникването на научното направление соф- туерни технологии като възможно решение на т. нар. софтуерна криза. За съжале- ние десетилетия след прилагането му някои тревожни симптоми на софтуерната криза — висока цена на разработване и незадоволително качество — продължават да се наблюдават. Затова бе създаден нов поход — обектно ориентираният. Такова развитие е в пълно съответствие с диаграмата на Kuhn [1], показана на фиг. 3.1 
3.2. Определяне на софтуерната система Целта на тази фаза е да се определят предназначението и обхватът на соф- туерната система; да се разберат потребностите и желанията на потребителя; да се оцени осъществимостта на избираните решения; да се обсъди и избере при- емлива съвкупност от изисквания, които да се специфицират, валидират и ут- върдят, като се регламентира и проследяването им така, че да се осигури вграж- дането им в целевата система. 3.2.1. Определяне на изискванията Основен проблем при определяне на изискванията е разминаването на спе- циалистите в съответната приложна област (наричани най-общо потребители) и софтуерните специалисти, които отговарят за първоначалното определяне на системата (т. нар. системни аналитици или проектанти). Обикновено потреби- телите не могат ясно и точно да формулират потребностите и очакванията си; пропускат очевидните за тях подробности и нямат реална представа за възмож- ностите на компютърните системи. Аналитиците пък не познават особеностите на дейностите, които ще автоматизират, и не могат да преценяват доколко са съществени обсъжданите проблеми. Затова определянето на изискванията трябва да се разглежда като итеративен процес с активното участие на подходящо изб- рани представители и от двете страни. Ще опишем целите, съдържанието и прилаганите техники за всяка от пос- ледователните стъпки. а) Формулиране на изискванията Основна цел на този етап е съставяне на съвкупност от всички възможни
37
 ки, описан в [3]. Първоначално се идентифицират, например чрез „мозъчна атака"
(Brainstorming), всички възможни потребители на системата, които след това се групират по сходство на гледните точки, които те представят. В резултат на интервюта, провеждани от системните аналитици с членове на групата, разго- вори и целенасочени обсъждания се определят изискванията на групата. Ако е необходимо, се разработват сценарии (use-cases) за реализацията на някаква основна функция и дори прототипи за нея, за да могат да се дефинират по- точно съответните изисквания. Всяко изискване се описва (същност на изиск- ването, кой и защо го предлага). Тази документация е необходима за по-ната- тъшното разглеждане и оценяване. б) Анализ на изискванията Съставената съвкупност от изисквания се изследва за пълнота и непроти-
в) Утвърждаване на изискванията Създадената спецификация на изискванията се проверява от представите-
г) Проследяване на изискванията Препоръчва се планиране на дейностите по проследяване на изискванията,
Създадените спецификации на изискванията към софтуера са основа за изграждане на първия формален модел на целевата система — т. нар. аналити- чен модел. Той е резултат от проведения структурен анализ и предназначение- то му е да улесни следващите дейности по проектиране. Основните съставящи на аналитичния модел са: а) Модел на данните Моделът на данните представя основните обекти, атрибутите, които ги
обекта включва описание на същността и на атрибутите му, които представят основните характеристики и свойства на този обект. Например в една библио- течна система обектът книга има атрибути регистрационен номер, индекс (за принадлежност към област в съответствие с общоприета класификация), загла- вие, автор(и), издателство, година на издаване, цена, език, на който е написана, и др. Друг обект е читател, който може да се опише с атрибути име, ЕГН, адрес, образование, месторабота. Обектите са свързани помежду си по различен начин. Например обектите читател и книга са свързани с отношения заемам, връщам, загубвам, поръчвам. Разглежданите отношения са ориентирани, т. е. имат посока, която трябва да се отчита при анализирането и изобразяването им. За всяко отношение могат да се определят стойностите на две основни характеристики: кардиналност и модалност. Кардиналността е характе- ристика, която определя колко екземпляра от единия обект могат да са в отно- шение с екземпляри от другия обект. Кардиналността се описва с „един" и ,мно- гo" и може да бъде един-към-един (1:1 читател — ЕГН), един-към-много (l:N читател — книги) и много-към-много (M:N читатели — групи по интереси). Модалността определя дали отношението между два обекта е задължи- телно (модалност 1) или незадължително (модалност 0). Например отношение- то заема между читател — книга в двете посоки има модалност 0, защото във всеки момент има читатели, които не са заели книги, и книги, които не са взети от читатели. Използвайки приетите означения, отношенията между разглежданите обек- ти могат да се представят графично по следния начин: 
Диаграма, представяща обектите и отношенията между тях, се нарича ди- аграма елемент-връзка (entity-relationship diagram ERD). Тя е предложена за пръв път от Чен [4] за проектиране на релационни СУБД и после многократно е разширявана и по съдържание, и по форма. ERD е графично представяне, в което обектите се представят с надписани правоъгълници, а отношенията — чрез свързващите ги надписани линии. Въведени са специални означения за кардиналността и модалността на всяко отношение. Описанието на обектите и атрибутите им заедно с диаграмата, представя- ща отношенията между тях, определят модела на данните. б) Функционален модел Предназначението на този модел е да представи основните функции на соф-
39
Като задължителна част на аналитичния модел се разглежда и речникът на данните, който представлява систематично и точно описание на всеки елемент на данните, споменат в някой от моделите на софтуерната система. Описанието на елемент от речника обикновено съдържа:
Основно преимущество на структурния анализ е простотата и нагледност- та. Освен с това широкото му практическо използване се обяснява и с наличи- ето на множество инструментални средства, подпомагащи систематичното му прилагане за конструиране, описване и автоматично проверяване на пълнотата и непротиворечивостта на съответните модели.  Фиг. 33
описващо трансформациите на данните така, че от входните данни в системата да се получат исканите изходи. Използваните графични елементи са: правоъгълник за означаване на външни обекти, предаващи или приемащи информация от сис- темата; кръг — за означаване на функция, променяща данните по някакъв начин и надписани стрелки, представящи съответните входни и изходни данни. Пример за диаграма на потока на данните (ДПД) е показан на фиг. 3.3 Широкото практическо използване на ДПД се обуславя от тяхната изклю- чителна простота и нагледност. Те могат да се съставят с различна степен на детайлизираност. Например така наречената фундаментална ДПД (диаграма на ниво 0) представя софтуерната система като една обобщена функция, преобра- зуваща входа на системата в изхода. По-нататъшното анализиране изяснява ос- новните функции, докато се достигне до описание, което може да бъде основа за проектирането. Графичното представяне на функциите може да се съпътства с допълнително описание на всеки елемент в ДПД. Това описание се нарича спецификация на процеса. Освен входа, изхода и същността на извършваната трансформация могат да се задават и допълнителни изисквания към всяка от описваните функции. Класическият структурен анализ е разширен с допълнителни техники за отразяване на особеностите на определени класове софтуерни системи. Нап- ример за моделиране на системи в реално време е предложено създаването на диаграми на потока на управление [5]. Диаграмите на потока на управление (ДПУ) и съответните им подробни описания, наречени спецификация на уп- равлението (control specification), могат да бъдат създавани с помощта на съ- ответни инструментални средства. в) Поведенчески модел За някои видове системи се предлага създаването и на модел на поведението
Каталог: 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. Сподели с приятели:
|
