Софтуерни технологии
Определяне на софтуерната система
Изтегляне 204.11 Kb.
|
| 3.2. Определяне на софтуерната система
Целта на тази фаза е да се определят предназначението и обхватът на соф- туерната система; да се разберат потребностите и желанията на потребителя; да се оцени осъществимостта на избираните решения; да се обсъди и избере при- емлива съвкупност от изисквания, които да се специфицират, валидират и ут- върдят, като се регламентира и проследяването им така, че да се осигури вграж- дането им в целевата система. 3.2.1. Определяне на изискванията Основен проблем при определяне на изискванията е разминаването на спе- циалистите в съответната приложна област (наричани най-общо потребители) и софтуерните специалисти, които отговарят за първоначалното определяне на системата (т. нар. системни аналитици или проектанти). Обикновено потреби- телите не могат ясно и точно да формулират потребностите и очакванията си; пропускат очевидните за тях подробности и нямат реална представа за възмож- ностите на компютърните системи. Аналитиците пък не познават особеностите на дейностите, които ще автоматизират, и не могат да преценяват доколко са съществени обсъжданите проблеми. Затова определянето на изискванията трябва да се разглежда като итеративен процес с активното участие на подходящо изб- рани представители и от двете страни. Ще опишем целите, съдържанието и прилаганите техники за всяка от пос- ледователните стъпки. а) Формулиране на изискванията Основна цел на този етап е съставяне на съвкупност от всички възможни
37
(Brainstorming), всички възможни потребители на системата, които след това се групират по сходство на гледните точки, които те представят. В резултат на интервюта, провеждани от системните аналитици с членове на групата, разго- вори и целенасочени обсъждания се определят изискванията на групата. Ако е необходимо, се разработват сценарии (use-cases) за реализацията на някаква основна функция и дори прототипи за нея, за да могат да се дефинират по- точно съответните изисквания. Всяко изискване се описва (същност на изиск- ването, кой и защо го предлага). Тази документация е необходима за по-ната- тъшното разглеждане и оценяване. б) Анализ на изискванията Съставената съвкупност от изисквания се изследва за пълнота и непроти- воречивост. Всички изисквания се класифицират по няколко критерия — нап- ример на функционални и нефункционални, на задължителни и препоръчител- ни, като може да им се присвоява и коефициент на значимост. Изследват се връзките помежду им и противоречията се разрешават на основа на присвое- ния им приоритет. След формиране на непротиворечива система за всяко изис- кване се определя доколко ясно и точно е формулирано, осъществимо ли е в определената среда за разработване, с какви рискови фактори е свързано, с какви ресурси би се реализирало, проследимо ли е в процеса на реализация на ПП и как може да се провери удовлетворяването му в целевата система. Полу- ченото описание на изискванията е документ, който се нарича „Спецификация на изискванията" (според други автори — „Съглашение за изискванията"). в) Утвърждаване на изискванията Създадената спецификация на изискванията се проверява от представите- ли на заинтересованите страни — потребители и разработчици, като се изс- ледват и изискванията като цяло, и всяко изискване поотделно. Обичайната тех- ника е използване на стандартни въпросници, чрез които се постига система- тичност и изчерпателност на проверката. След приключването й спецификаци- ите на изискванията се утвърждават и стават основен документ за цялата софту- ерна разработка. г) Проследяване на изискванията Препоръчва се планиране на дейностите по проследяване на изискванията, като в определените за проекта контролни точки се включат и проверки за пос- тигнатата степен на удовлетворяване на избрана подсъвкупност от изисквания. 3.2.2. Аналитичен модел Създадените спецификации на изискванията към софтуера са основа за изграждане на първия формален модел на целевата система — т. нар. аналити- чен модел. Той е резултат от проведения структурен анализ и предназначение- то му е да улесни следващите дейности по проектиране. Основните съставящи на аналитичния модел са: а) Модел на данните Моделът на данните представя основните обекти, атрибутите, които ги описват, и връзките на обектите помежду им. Обект може да бъде всяко нещо, което създава или използва информация в софтуерната система. Описанието на 38 обекта включва описание на същността и на атрибутите му, които представят основните характеристики и свойства на този обект. Например в една библио- течна система обектът книга има атрибути регистрационен номер, индекс (за принадлежност към област в съответствие с общоприета класификация), загла- вие, автор(и), издателство, година на издаване, цена, език, на който е написана, и др. Друг обект е читател, който може да се опише с атрибути име, ЕГН, адрес, образование, месторабота. Обектите са свързани помежду си по различен начин. Например обектите читател и книга са свързани с отношения заемам, връщам, загубвам, поръчвам. Разглежданите отношения са ориентирани, т. е. имат посока, която трябва да се отчита при анализирането и изобразяването им. За всяко отношение могат да се определят стойностите на две основни характеристики: кардиналност и модалност. Кардиналността е характе- ристика, която определя колко екземпляра от единия обект могат да са в отно- шение с екземпляри от другия обект. Кардиналността се описва с „един" и ,мно- гo" и може да бъде един-към-един (1:1 читател — ЕГН), един-към-много (l:N читател — книги) и много-към-много (M:N читатели — групи по интереси). Модалността определя дали отношението между два обекта е задължи- телно (модалност 1) или незадължително (модалност 0). Например отношение- то заема между читател — книга в двете посоки има модалност 0, защото във всеки момент има читатели, които не са заели книги, и книги, които не са взети от читатели. Използвайки приетите означения, отношенията между разглежданите обек- ти могат да се представят графично по следния начин: Диаграма, представяща обектите и отношенията между тях, се нарича ди- аграма елемент-връзка (entity-relationship diagram ERD). Тя е предложена за пръв път от Чен [4] за проектиране на релационни СУБД и после многократно е разширявана и по съдържание, и по форма. ERD е графично представяне, в което обектите се представят с надписани правоъгълници, а отношенията — чрез свързващите ги надписани линии. Въведени са специални означения за кардиналността и модалността на всяко отношение. Описанието на обектите и атрибутите им заедно с диаграмата, представя- ща отношенията между тях, определят модела на данните. б) Функционален модел Предназначението на този модел е да представи основните функции на соф- туерната система чрез проследяване на преобразуването на информацията в нея. Диаграмата на потока на данните (Data Flow Diagram) e графично представяне, 39 Като задължителна част на аналитичния модел се разглежда и речникът на данните, който представлява систематично и точно описание на всеки елемент на данните, споменат в някой от моделите на софтуерната система. Описанието на елемент от речника обикновено съдържа: име на обекта; синоними — други имена, използвани за същия обект; списък на срещанията на този обект — къде и как се използва; описание на същността на обекта; допълнителна информация. Основно преимущество на структурния анализ е простотата и нагледност- та. Освен с това широкото му практическо използване се обяснява и с наличи- ето на множество инструментални средства, подпомагащи систематичното му прилагане за конструиране, описване и автоматично проверяване на пълнотата и непротиворечивостта на съответните модели. Изтегляне 204.11 Kb. Сподели с приятели:
|