Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
57 Cards in this Set
- Front
- Back
|
Софтверски систем се састоји од Атрибута и Системских операција. Опиши. |
Атрибути описују структуру система, док системске операције описују понашање система. Атрибути представљају концепте реалног система који описују статичке карактеристике система (нпр. Рачун, Партнер,..). Системске операције представљају основне функције система, које се могу користити из окружења система (нпр. УнесиРачун, ПромениРачун, ИзрачунајРачун, ...). |
|
|
Допустиви улаз и излаз и софтверског система. Опиши. |
Допустиви улаз у софтверски систем је дефинисан потписом који садржи назив системске операције која се позива и скупом улазних аргумената (нпр. IzracunajRacun(Racun),...). Излаз из софтверског система је представљен преко скупа излазних аргумената (нпр. Racun, signal, ...). Излаз се добија као резултат извршења неке од системских операција над атрибутима система. |
|
|
Слика софтверски системи, страна 1 |
|
|
|
Опиши софтверски систем. |
Atributi = {AT1, AT2,…,ATn} Sistemske operacije ={SO1,SO2,..,SOm} - Основнефункције система SOi∈Sistemske operacije , i = (1,..,m) UA1,UA2,…,UAk– Улазниаргументи IA1,IA2,…,IAs– Излазниаргументи |
|
|
Да ли је корисничкиинтерфејс део софтверског система или је он изван система. Шта је кориснички интерфејс? |
Кориснички интерфејс представља реализацију улазаи/или излаза софтверског система. |
|
|
Развој (животни циклус) софтверског система, наведи фазе. |
Прикупљања захтева од корисника Анализа Пројектовање Имплементација Тестирање |
|
|
Фаза прикупљања захтева од корисника, опиши. |
Дефинишу се својства и услови које софтверски систем (или шире гледајући пројекат) треба да задовољи. Захтеви се могу поделитикао функционални и нефункционални. Функционални захтеви дефинишу захтеване функције система, док нефункционални захтеви дефинишу све остале захтеве. Нeфункционални захтеви као што су употребљивост,поузданост, перформансе и подрживостсистема представљају атрибуте квалитета софтверског система. Функционални захтеви се описују преко моделаслучаја коришћења. |
|
|
Фаза анализе, опиши. |
У фази анализе се описује логичка структура и понашање софтверског система, односно пословна логика софтверског система. Елементи структуре софтверскогсистема се описују помоћу именица и придева док се елементи понашања описују помоћу глагола. |
|
|
Слика Развој софтверског система, страна 3 |
|
|
|
Како се описује структура софтв ерског система? |
Структура софтверскогсистема се описује преко концептуалног и релационог модела док се понашање софтверског система описује помоћу секвенцних дијаграма и системскихо перација. |
|
|
Фаза Пројектовања, опиши? |
У фази пројектовања се описује архитектура софтверског система која је тронивовска и састојисе од: а) корисничког интерфејса б) апликационе логике и ц) складишта података. Апликациона логикасе састоји од: б1) контролера апликационелогике б2) пословне логике и б3) брокера базе података. Сваки однаведених нивоа тронивовске архитектуре је реализован преко скупа класа које представљају компоненте архитектуре софтверског система. Компоненте архитектуре су дефинисане преко интерфејса. |
|
|
Фаза Имплементације, опиши? |
У фази имплементације се праве имплементационе компоненте које се реализују у некој од постојећих технологија (Јава, .NET,...). |
|
|
Фаза Тестирања, опиши? |
У фази тестирања, свака од компоненти се тестира тако што се за сваку од њих праве тест случајеви, тест процедуре и тест компоненте. |
|
|
Развој софтверског система код Ларманове методе има јасан логички след. Слика, страна 4 |
|
|
|
Закључак првог дела. |
Кориснички интерфејс је дефинисан преко скупа екранских форми. Сценарија коришћења екранских форми једиректно повезан са сценаријима случајева коришћења. Пословна логика, која седобија у фази анализе, се преноси у фазу пројектовања и постаје саставни деоапликационе логике. Складиште података се пројектује на основу релационог модела. Имплементационе компоненте,из фазе имплементације, треба да реализују компоненте које су добијене у фази пројектовања. Свака од имплементационих компоненти се тестира у фази тестирања |
|
|
Однос информациони - пословни систем |
Информациони систем се прави како би се олакшао рад и управљање неким реалним пословним системом. Пословни систем у најопштијем смислу има своју структуру и понашање. Структура пословног система се односи на организациону структуру преко које се одређују везе и односи између елемената пословног система, док се понашање пословног система односи на пословнепроцесе који одређују токове извршења функција пословног система (нпр.функција продаје, набавке,...). |
|
|
Структура и понашање пословног система се моделирају преко? |
Структура и понашање пословног системасе моделирају преко модела података и модела процеса ИС-а. |
|
|
Модел процеса -> ССА ->речник података |
Модел процеса се описује помоћу Структурне Систем Анализе (ССА). Структурна систем анализа је представљена преко дијаграма токова података. Напомена: Структурна систем анализа се ради у фази анализе ИС-а. На основу дијаграма тока података могуће је направити речник података и дати прецизну спецификацију основних (примитивних) процеса система. |
|
|
Прва фаза у развојусофтверског система, прикупљање захтева, опиши. |
Прва фаза у развојусофтверског система, прикупљање захтева, се описује преко модела случаја коришћења (СК) који се добија на основу спецификације основних процеса. Напомена: Фаза прикупљања захтева и анализа софтверског система се из перспективе ИС-аназивају фаза логичког пројектовањаИС-а. |
|
|
Друга фаза у развоју софтверског система, анализа софтверског система, опиши. |
У фази анализе софтверског система, на основу модела СК се одређује модел података и модел понашања софтверског система. Модел података софтверског система се описује помоћу проширеног модела објекти везе (ПМОВ), релационог модела (РМ), објектног модела (ОМ),..., итд. Релациони модел је подржан SQL упитним језиком. Релациони модел се може добити на основу ПМОВ-а. Модел понашања софтверског система се описује помоћу системских операција. Модел података и модел понашања софтверскогсистема описују пословну логику софтверског система. |
|
|
Трећа фаза у развоју софтверског система, пројектовање софтверског система, опиши. |
У фази пројектовања софтверског система се дефинише тронивојска архитектура која се састоји од: корисничког интерфејса, апликационе логике и складишта података. Пројектовање сценарија коришћења екранских форми корисничког интерфејса се ради на основу СК-а. Напомена: Фаза пројектовања софтверског система се из перспективе ИС-а назива фаза физичког пројектовања ИС-а. Фаза имплементације софтверског система се изперспективе ИС-а назива фаза имплементације ИС-а |
|
|
Пета фаза у развоју софтверског система, складиштење податка, опиши. |
Складиште података може бити реализовано преко система за управљање базом података, системомдатотека,...,итд. Системи за управљање базом података (СУБП) могу бити:релациони (РСУБП), објектни (ОСУБП),...,итд. Релациони СУБП су: MS Access,MySQL, Oracle,.., итд. |
|
|
Слика, однос информаицоног и софтверског система |
|
|
|
Дефиниција пројектовања софтвера |
Пројектовање се у контексту софтверског инжењерства дефинише као: a) процесдефинисања архитектуре, компоненти, интерфејса и других особина система иликомпоненте и b) резултат тог процеса. (слика страна 8) |
|
|
Код објашњења процеса животног циклуса софтвера пројектовање софтвера се састоји од две активности: |
Пројектовањесофтверске архитектуре (понекад се назива пројектовање највишег нивоа), описује структуру и организацију софтвера на највишем нивоу.На овом нивоу се идентификује различите компоненте. Детаљно пројектовање софтвера које описује сваку компоненту до нивоа детаљности који је довољан да се она може конструисати |
|
|
Захтеви (Requirements) |
Захтеви представљају својства и услове које систем или шире гледајући пројекат мора да задовољи[Ларман]. Постоје различити типови захтева које систем мора да задовољи и они су категоризовани према FURPS+ (Functional - Функционалност, Usability- Употребљивост, Reliability - Поузданост,Performance - Перформансе, Supportability- Подрживост) моделу Захтеви се често категоризују као функционални и не функционални захтеви. Функционални захтеви дефинишу захтеване функције система, док нефункционални захтеви дефинишу све остале захтеве. Утом смислу не функционални захтеви (употребљивост, поузданост, перформансе иподрживост система) представљају атрибуте квалитета (quality attributes) софтверског система. |
|
|
Захтеви -> Функционалност |
Функционалност представља способност (capabilities)система да обезбеди захтеване функције (понашање система). Заштита (security)система представља једну од основних функција коју систем треба да обезбеди. |
|
|
Захтеви -> Употребљивост |
Употребљивост представља способност система да се може једноставно користити. То се постиже помоћу разних упутстава и документције који описују начин његовог коришћења. |
|
|
Захтеви -> Поузданост |
Поузданост представља способност система да може успешно обрадити проблем који се дешава у току извршења система. У том смислу систем мора да обезбеди начин опоравка података у случају насилног прекида рада система. Такође систем треба да омогући предвиђање могућих понашања система. |
|
|
Захтеви ->Перформансе |
Перформансесистема се односе на време одзива захтеваних функција, пропусну моћ мреже кроз коју пролазе подаци, тачност извршења функција, могућност коришћења односно расположивост функција система и начин коришћење расположивих ресурса система |
|
|
Захтеви -> Подрживост |
Подрживост системасе односи на лакоћу његовог прилагођавања и одржавања, интернационализацију у смислу његове прилагодљивости различитим знаковним системима који се користеу свету и начину конфигурисања система. |
|
|
У ФУРПС+ моделу знак ‘+’ указујена? |
У ФУРПС+ моделу знак ‘+’ указујена помоћне захтеве који се односе на: - Имплементацију система – до којих граница се могу користити расположиви ресурси. Који се програмски језици и алати могу користити. Поред тога имплемантациони захтеви се односе и на хардвер који ће се користити. - Интерфејс система – ограничења која постоје у комуникацији система са његовим окружењем. - Операције система – управљање системом и његовим операцијама. - Паковање система – начин физичког организовања система у пакете, који представљају управљиве јединице система. - Легалност – могућност употребе системау смислу његове легалности. |
|
|
Захтеви се код Лармана описују помоћу? |
Захтевисе код Лармана описују помоћу UML Модела Случаја Коришћења (Use-Case Model). |
|
|
Од чега се састоји Модел СК? |
Модел СК сесастоји од скупа случаја коришћења (СК), актора (АК) и веза између случаја коришћења и актора. 2 слике на 10-ој страници |
|
|
Опиши модел СК. |
Модел СК је везан за више а) СК, б) веза између СК и АК и ц) АК. Један СК може да има више веза са АК. Један АК може да има више веза са СК.Једна веза се односи на један пар СК-АК Случај коришћења описује скуп сценарија, односно скуп жељених коришћења система од стране актора. |
|
|
Шта је сценарио? слика на страни 10 |
Сценарио описује једно жељено коришћење система од стране актора. Случај коришћења има један главни и више алтернативних сценарија. Сценарио је описан преко: а) секценцеакција и б) интеракција између актора и система. СК се састоји из главног иалтернативних сценарија. У току интеракције између актора и софтверског система, актор позива системске операција софтверског система. То значи да се у току неког (једног) сценариа Ski случаја коришћења позива једна или више системских операција (SO1, SO2,...,SOn). |
|
|
Као резултат извршењасистемске операције над атрибутима софтверског система се добијају? слика на страни 11 |
Као резултат извршења системске операције над атрибутима софтверског система се добијају излазни резултати IZSO1, IZSO2,...,IZSOn. Системске операције ={SO1,SO2,..,SOn} - Основне функцијесистема (атомске функције) Случајеви коришћења ={SK1,SK2,..,SKp} - Жељене функцијесистема (молекулске функције) SKi∈ Slučajevi korišćenja, i =(1..p) |
|
|
Акције које изводе Актор и Систем? |
СК, односно сценарија СК дефинишу жељене функције система. Жељене функције система, када се извршавају, позивају по одређеном редоследу основне функције система. Једну акцију сценариа изводи или акторили систем. У том смислу: Актор изводи једну од три врсте акција: а) АкторПрипрема Улаз (Улазне Аргументе) за Системску Операцију (АПУСО). б) АкторПозива систем да изврши Системску Операцију (АПСО). ц) Акторизвршава НеСистемску Операцију (АНСО). Систем изводи две акције у континуитету: а) Систем извршава Системску Операцију(СО): б) Резултат системске операције (Излазни аргументи (IA)) се прослеђује до актора. |
|
|
Дефиниција: Актор? |
Актор представља спољног корисника система. Он поставља захтев систему да изврши једну или више системских операција, по унапред дефинисаном сценариу. Систем одговара на постављени захтев актора,шаљући му вредност излазних аргумената као резултат извршења операција. Актор се обично дефинише као неко или нешто што има понашање. Захтев за извршење једне или више системских операција се не одиграва континуално него дискретно.То значи да корисник интерактивно позива једну по једну системску операцију, у дискретним временским интервалима. Из наведеног може да се закључи да сценарио описује интерактивно коришћење софтверског система. |
|
|
Правила код прикупљања захтева: ЗА1, ЗА2, ЗА3, ЗА4 |
ПравилоЗА1 (Независност сценарија СК): Сценарија СК не треба да буду у међусобној интеракцији.Она се требају дефинисати као атомска, у смислу да се извршавају у потпуности самостално. На тај начин се олакшава њихов развој и одржавање. ПравилоЗА2 (Glass’ low): Недостаци код дефинисања захтева су основни разлог могућег неуспеха у развоју пројекта (програма). ПравилоЗА3 (Boehm’s first low): Уколико се не уоче грешке у току дефинисања захтева, исте севеома тешко могу уклонити у каснијим фазама развоја програма. ПравилоЗА4 (Boehm’s second low): Прављење прототипова значајно смањује могуће грешке код дефинисања захтева и његовог развоја, нарочито код дефинисања корисничкогинтерфејса. |
|
|
Начин представљања модела СК |
СК се у почетним фазама развојасофтвера представљају текстуално док се касније они представљају прекосеквенцних дијаграма, дијаграма сарадње, дијаграма прелаза стања или дијаграмаактивности. Тексуалниопис СК има следећу структуру: Назив СК. Акторе СК. Учеснике СК. Предуслови који морају бити задовољени да би СК почео да сеизвршава. Основни сценарио извршења СК. Постуслови који морају бити задовољенида би се потврдило да је СК успешно извршен. Алтернативна сценарија извршења СК. Специјални захтеви. Технолошки захтеви. Отворена питања. |
|
|
Анализa |
Фаза анализе описује логичку структуру и понашање софтв. система.Понашање софтверског система је описано помоћу системских дијаграма секвенци и преко системских операција. Структура софтерског система се описује помоћу концептуалног и релационог модела. |
|
|
Понашање система се може описати преко? |
Понашање система се можеописати преко УМЛ-ових секвенцних дијаграма [Larman], односно преко дијаграма сарадње. |
|
|
Деф. АН1: Системски дијаграм секвенци |
Деф.АН1: Системски дијаграм секвенци приказује, за издвојени сценарио СК, догађаје у одређеном редоследу, који успостављају интеракцију између актора и софтверског система. |
|
|
Деф. АН2: Догађај којинаправи актор |
Деф. АН2: Догађај који направи актор је побуда за позив системске операције. То значи да актор позива системску операцију преко посредника. Позив системске операције указује на интеракцију између актора и система. За догађај који представља побуду за позив СО се често каже да је то системскидогађај. |
|
|
смисли питање |
Догађаје праве актори у оквиру APSO акција, над примаоцем догађаја. Прималац догађаја прихвата догађај и позива системску операцију која се налази на страни система. Након извршења системске операције систем враћа неки резултат као одговор на догађај. За сваки СК, прецизније речено за сваки сценаријо СК, праве се системски дијаграми секвенци и то само за АПСО и ИА акције сценарија. |
|
|
Деф. АН3: Системска операција |
Деф.АН3: Системска операција описује понашање софтверског система. Системска операција има свој потпис, који садржи име методе и опционо улазнеи/или излазне аргументе. |
|
|
Деф. АН4: Уговори |
Деф.АН4: Уговори се праве за системске операције и они описују њено понашање. Уговори описују шта операција треба да ради, без објашњења како ће то да ради. Један уговор је везан за једну системску операцију. Уговори се састоје из следећих секција: • Операција– имеоперације и њени улазни и излазни аргументи • Веза са СК – имена СК у којима се позива системска операција • Предуслов–пре извршења системске операције морају бити задовољени одређени предуслови (систем мора бити у одговарајућем стању). • Постуслови – после извршења системске операције у систему морају бити задовољени одређени постуслови (систем мора бити у одговарајућем стању или се поништава резултат операције). |
|
|
Деф. АН5: Постуслови СО |
Деф.АН5: Постуслови СО указују на то шта треба да се деси (ефекти извршења СО), након извршења СО, а не како ће то да се деси. Постуслови се изражавају у прошлом времену, како би се нагласило да је објекат дошао у ново стање, а не да ће дође у ново стање |
|
|
Деф. АН6: Предуслови СО |
Деф. АН6: Предуслови СО указују на то шта је требало да се деси, како би СО могла да се изврши, а не како се то десило. |
|
|
Дефиниција АН7: Концептуални модел |
ДефиницијаАН7: Концептуални модел описује концептуалне класе домена проблема. Концептуални модел садржи концептуалне класе и асоцијације између концептуалних класа. Често се за концептуалне моделе каже да су то доменски модели или модели објектне анализе. |
|
|
Дефиниција АН8: Концепти (концептуалне класе) |
ДефиницијаАН8: Концепти (концептуалне класе) представљају атрибуте софтверског система. То значи да концепти описују структуру софтверског система. Концептуалне класе састоје се од атрибута, који описују особине класе. Концептуалне класе треба разликовати од софтверских класа. |
|
|
Дефиниција АН9: Атрибути |
ДефиницијаАН9: Атрибути представљају особине која се придружују до концептуалних класа. Сваки од атрибута је везан за одређени тип податка. Атрибут има конкретну вредност за конкретно појављивање концептуалне класе. |
|
|
Дефиниција АН10: Асоцијацијa |
ДефиницијаАН10: Асоцијација је веза између концептуланих класа. Сваки крај асоцијације представља улогу концепта који учествује у асоцијацији. Улога садржи име, пресликавање и навигацију. Име улоге је засновано на формату: ИмеКонцКласе1 – Глагол –ИмеКонцКласе2, где глагол описује однос између концептуалних класа у датом контексту. Пресликавање дефинише колико много појављивања концептуалне класе А може бити придружено једном појављивању концептуалне класе Б. Навигација указује на једносмерне везе између концептуалних класа. Између концептуалних класа може постојати више асоцијација. |
|
|
Објашњење дефиниција концептуалног модела и његовихелеменатa |
Софтверски систем сесастоји од атрибута и системских операција. Концепти представљају реализацију атрибута софтверског система. |
|
|
Шта је резултат анализе сценаријаСК и прављења концептуалног модела? |
Као резултат анализе сценарија СК и прављења концептуалног модела добија се логичка структура и понашање софтверског система. |
|
|
Шта правимо на основу концептуалног модела |
На основу концептуалног модела може се направити релациони модел, који ће да представља основу за пројектовање релационе базе података[Ullman]. |
