Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите” Договор: BG051PO001-4.3.05 – 0022 Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на...

О ПЕРАТИВНА ПРОГРАМА

„РАЗВИТИЕ НА ЧОВЕШКИТЕ РЕСУРСИ” 2007-2013

МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО И НАУКАТА

Схема BG051PO001-4.3.05 „Развитие на професионалното образование и обучение в сътрудничество с работодателите”

Инвестира във вашето бъдеще!

Договор: BG051PO001-4.3.05 – 0022

Име на проект: „Образователни паркове за развитие на професионално знание и компетенции в областта на компютърните технологии и системи в колаборация с IT сектора“

Бенефициент: Професионална гимназия по компютърни технологии и системи –
гр. Правец

ДЕЙНОСТ 6. Разработване на електронно съдържание за специализираните
професионални курсове, заложени за професионално обучение в 4
образователни парка
Отчетен период: 01.04.2014 г. – 30.04.2014 г.

ДИСЦИПЛИНА: ТЕХНОЛОГИЯ НА ПРОГРАМИРАНЕТО

Тема 4. Планиране, проектиране и реализация на софтуерна система. Етап на проектиране - методи и техники.

Технологии за разработване на софтуер. Конвенционални (структурни) технологии.

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

Диаграма на Kuhn – научно знание > криза > радикална смяна > научно знание. Хронологически модел на ЖЦ:

Определяне на софтуерната система:

- Определяне на изискванията:

а) формулиране на изискванията - всички възможни изисквания въз основа на определените вече предназначение и обхват на предлаганата софтуерна система(FAST - потребителите и разработчиците подготвя предварително множество от изисквания; анализ на различните гледни точки – brainstorming на потребителите, определят се изискванията евентуално use cases).

б) анализ на изискванията – класифициране(функционални, не-, задължителни, препоръчителни), формиране на непротиворечива система за всяко изискване, осъществимо?, рискови фактори, ресурси, проследимост, Спецификация на изискванията(СИ).

в) утвърждаване на изискванията - СИ се проверява и утвърждава от потребители и разработчици и стават основен док. за софтуерната разработка.

г) проследяване на изискванията - планиране на дейностите по проследяване на изискванията, като в контролните точки се включат и проверки за постигнатата степен на удовлетворяване на избраните изисквания.

- Аналитичен Модел – формален, резултат от проведения структурен анализ и предназначението му е да улесни следващите дейности по проектиране. Съставен е от:

а) модел на данните представя основните обекти, атрибутите, които ги описват и връзките на обектите помежду им. Обект – всяко нещо, което създава/използва информация в софт. система. Характеристики на отношенията – кардиналност(1:1, 1:N, N:N), модалност(задължително 0, незадължително 1). Xxxxxxxx, представяща обектите и отношенията между тях, се нарича диаграма елемент-връзка.

б) функционален модел представя основните функции на софтуерната система чрез проследяване на преобразуването на информацията в нея. Data Flow Diagram представя трансформациите на данните така че от входните данни в системата да се получат изходните. Правоъгълник за външни обекти, кръг за ф-ция и стрелки за входните и изходните данни. Широко използвано. Нарича се спецификация на процеса.

в) поведенчески модел - системата се описва чрез различимите си състояния и начина на преминаване от едно в друго. Диаграмата на преобразуване на състоянията представя наблюдаваните състояния (правоъгълници) и събитията (стрелки). Основно преимущество на структурния анализ е простотата и нагледност.

Речни на данните - име на обекта, синоними, къде и как се ползва, същност, допълнително инфо.

Проектиране:

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

- Методи и средства за проектиране -два начина: ad hoc или стандартизиран процес. Ад хок - въз основа на утвърдените изисквания се изготвя неформализирано описание на естествен език , служи за ръководство при съставяне на програмите. По-систематичен е подходът с прилагане на структурни методи, които предлагат начини за описване и процедури за създаване на софтуерни проекти.

- Етапи на проектиране - два основни етапа на функционалното проектиране:предварително (външно) проектиране и детайлно (вътрешно) проектиране.Външното създава архитектурен проект. Обхваща:- логическата организация на данните; - структурата на системата; - интерфейс на системата; Вътрешното (component-level) софтуерната система се представя като йерархия от програмни части(модули – основна,

самостоятелно разработвана, тествана и док. единица; 4 атрибута – вход/ изход, функция, механизъм за реализация, вътрешни данни; ). - Методи за описване на проекти - предпочитат се неформалните методи поради съпротивата и на потребителите, и на проектантите(нямат теоретична подготовка, твърде сложни класове – паралелно изпълнение и т.н.). Използваните техники за описания са:а) графично описание; б) таблично представяне; в) текстови описания: този вид описания са с различна степен на формализираност и най-общо се делят на две: псевдокодове и езици за проектиране на програми (PDL - Program Design Language). Псевдокодът е неформален език - речникът на езика включва глаголи, имена от речника на данните и запазени думи за описване на логиката(цикъл, условие). Критерии за сравняване на методите за описване на проекти - модулност; простота; леснота на редактиране; възможност за автоматично създаване и обработка; съпровождаемост; удобство на представяне на данните; възможност за верификация; сложност на прехода „проект-програма". Организационни аспекти на проектирането: проектирането трябва да се осъществява целенасочено и систематично,с регламентиране на основните процедури. Най-сложният проблем е определянето на подходящо ниво на декомпозиране и на подробност на проекта. Оценяване на качеството на проекти, характеристики: Пълнота - утвърдените изисквания да са отразени в проекта на софтуерната система. Проектът да бъде разбираем, ясен, точно и недвусмислено описан, и да не зависи от платформата, на която ще се реализира. Лесно проверяем и документиран. Спецификация на проекта:

I. Цел и обхват на дейностите по проектиране;

II. Описание на проектите а) външен проект;б) детайлен проект;

III.Съответствие на проектите с утвърдените изисквания;

IV. План за модулно и системно тестване;

V.Допълнителни условия и ограничения за проектирането;

VI. Приложения (описание на алгоритми, алтернативни процедури,таблични данни, извлечения от други документи, и т.н.).

Програмиране: Основната идея на структурното програмиране (без GOTO") е използването на три класически конструкции: линейна последователност,конструкция за разклоняване IF-THEN-ELSE и за цикъл. Техниката за написване на структурни програми съчетава низходящото проектиране и постъпковото уточняване. Започва се с най-обща схема на програмата, като всеки цикъл или проверка на условие се представят чрез съответните оператори, а всяка вложена част постепенно се разширява, докато се получи окончателната програма. Основно преимущество на структурното проектиране е повишаване на разбираемостта и тестируемостта на програмите и намаляване на усилията за тяхното разучавано и съпровождане. Недостатък: необходимостта от усвояване на тази специална програмистка техника и прилагането й при създаване на всички програми; изискват по-големи изчислителни ресурси. Интегриране и Тестване: стратегиите за тестване определят кои части на с-мата да се тестват, в какъв ред, с какви методи и средства, в каква среда и от кого. Обикновено се започва с модулно тестване, след което се преминава към тестване на компонентите от по-високо ниво.

- Модулно (поелементно) тестване: проверява коректността на най-малките програмни компоненти - модулите. Препоръчва се тестването да започне с проверка на интерфейса (на входните и изходните данни) на модула и да продължи с проверка на логиката,обработката на данните и реализираните функции. Модулното тестване изисква специална среда. Необходимо е да се създадат допълнителни програми драйвери (drivers) за извикване на тествания модул и опори (stubs) за представяне на модулите, извиквани от тествания модул.

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

Реализират се възходящо или низходящо. Възходящ подход се започва от най-долното ниво на йерархията (модула), образуват се подсистеми и накрая се достига до най-високото ниво - системата. Низходящ подход(драйвери) започва се с тестване на системата като цяло и се продължава с тестване на елементите от по-ниските нива. „Сандвичово тестване"(стъбове) - до определено ниво в йерархията се прилага единият, а оттам нататък - другият подход.

Особено важни са т.н. приемни тестове. Те са последна проверка на завършената софтуерна система преди разпространяването й. Алфа-тестването се провежда с участието и на потребители, но в средата

на разработване. Бета-тестването е изцяло в реална потребителска среда.

Обектно-ориентиран подход за разработване на софтуер.

Основни понятия: обект -познаваем предмет, елемент или същност, имащ важно функционално предназначение в разглежданата приложна област. Всеки обект има състояние, поведение и индивидуалност. Сходни обекти определят общ за тях клас. Състоянието на обекта се характеризира с изброяване на всичките му възможни свойства(атрибути). Всеки атрибут има област на ДС. С всеки обект могат да се свържат операции. Понятието клас е основен за ОО-подхода. Той обхваща данните и алгоритмите ,описващи съдържанието и поведението на „нещо" от реал свят. Суперклас е съвкупност от класове, а подклас - екземпляр на клас. Същ йерархия на класовете, като подкласовете наследяват атрибутите и операторите на cyпepкласа, но могат да имат и специфични за тях. Взаимодействието чрез съобщения, изпълнява се посочената в съобщението операция и връща управлението на обекта подател. Така се описва поведението на обектите и на ОО-система като цяло.Три основни характеристики на ОО-подхода: Капсулиране => преимущества: вътрешната реализация остава скрита; данните и операциите са обединени в едно цяло - класа, (повторното му използване); връзките са опростени(не зависи от вътрешната структура от данни). Наследяване => Всички подкласове ОО анализ и проектиране: Целта на OOA е създаването на модел, представящ статични и динамични характеристики на класовете и взаимоотношенията м/у тях. Различни методи за OOA преминават през едни и същи стъпки:

1)Изясняване на потребителските изисквания за системата

2)Идентифициране на потребителски сценарии (use-cases)

3)Избор на класовете и обектите въз основни на изисквания

4) Идентифициране на атрибутите и операциите за всеки обект

5)Дефиниране на структурите и йерархиите на класовете

6)Построяване на модел, описващ обектите и връзките м/у тях (object-relationship model)

7) Построяване на поведенчески модел

8)Проверка на ОО аналитични модели за съответствие с потребителските сценарии.

Проектирането на 2 нива, съответстващи на външното и детайлното проектиране при конвенционалния подход - проектиране на системата(1) и проектиране на обектите(2). (1) - определяне се архитектурата на OO-приложение. Аналитичния модел се декомпозира на подсистеми, като се описва предназначението на всяка подсистема и връзките м/у тях. Проектират се UI и логическата организация на данните. (2) - за всеки обект се съставя интерфейсно описание и описание на реализацията. Интерфейсното определя всички съобщения, получавани от обекта, и операциите. О на Реализацията - свързаните с обекта структурни данни и алгоритъма за всяка операция. За стандартизирано описание на моделите в ОО - разработване на софтуер е създаден Unified Modeling Language. Основни части на UML са:

а) Представяния (аспекти — функционални, нефункционални, организационни и др.) - потребителско (use-case view); логическо; компонентно; конкурентно; обвързващо (deployment view)

б) Диаграми - (use-case |class|object | state| sequence| collaboration| activity| component| deployment diagram)

в)Елементи на модела -използваните в диаграмата концептуални обекти - клас, обект, съобщение и връзките м/у тях.

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

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

Интеграционното ОО-тестване може да бъде: проследяващо (thread-based) -тестват се всички класове, свързани с едни и същи събития в системата; пластово - разглеждане на йерархията от класове и разделяне на класовете на независими и последователни слоеве от зависими класове; клъстерно - съставяне на групи от взаимодействащи класове и тестването им. Системното ОО-тестване съвпада с традиционното. Генерирането на тестови данни зависи от метода на тестване (стресово, случайно, сценарийно) и от обекта на тестване — отделен клас или група от класове.

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

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

- Управление на персонала - Разграничени са 3 групи изпълнители на ОО софтуерен проект: програмисти на приложения1), програмисти на компоненти2) и стратези3). 1) определят кои обекти да се групират, за да се изгради приложението. 2) участват активно в началото на всеки проект, за да дадат информация, какви налични компоненти има и как могат да се използват. Основна функции на 3) са координиране и съветване - опит в повторното използване като основен подход в софтуерна организация, решават и какво да бъде съдържанието на библиотека от компоненти. Въвеждане на ОО подход: Препоръки, следването на които би улеснило процеса на преход:

1) Обучение на персонала на софтуерна фирма на всички нива! ясни цели, подкрепа и финансиране за периода от време, необходимо за постигане на технологично ниво. Ръководителите на проекти трябва да бъдат спец обучени.

2)Стартиране на пилотен проект за проверка. < петима разработчици (3- 5 месеца). За планиране и оперативно управление - - опитен специалист, който да ръководи проекта и да осигури документирането на възникващите проблеми и успешни решения, така че да се натрупва know-how информация. За следващите проекти прилагането на метрики за измерване на подобренията в процеса на разработване и производителността.

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

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

Изготвил:….......

Боян Петров

8