Изпратете вашата добра работа в базата от знания е лесно. Използвайте формуляра по-долу

Студенти, специализанти, млади учени, които използват базата от знания в своето обучение и работа, ще ви бъдат много благодарни.

Публикувано на http://www.allbest.ru/

Омски държавен институт за обслужване

Моделиране на информационни системи с помощта на UML езика

Методически указания за изпълнение на курсова работа

И.В. Червенчук

• Въведение
• 2 . унифициран език за моделиранеUML
• 4. Разработване на модел на софтуерна система чрез средстваUML
• 5. Въпроси за внедряване на информационната система
• 6. Теми на курсовите работи
• Библиографски списък

Въведение

Работата се занимава с разработването на информационни системи с помощта на унифицирания език за моделиране UML, който е в основата на курсовата работа по дисциплината "Информационни системи и процеси. Моделиране и управление". Разработват се основните етапи на рационалния единен процес на разработване на информационни системи, дават се примери и илюстрации. Дадени са варианти за задачи за курсова работа.

Методическите указания са предназначени за студенти от специалност "Приложна информатика" и могат да се използват при изпълнение на курсова работа, подготовка за изпит, както и в процеса на самостоятелна работа.

1. Общи изисквания за изпълнение на курсова работа

Курсовата работа по дисциплината "Информационни системи и процеси. Моделиране и управление" е последният етап от изучаването на този курс и е предназначена да затвърди на практика основните теоретични знания за моделиране на информационни системи. Работата се състои в разработване на модел на определена информационна система с помощта на единния моделиращ език UML с последващата му реализация. Като типичен вариант на задачата се предлага разработването на информационно-справочна система на базата на база данни, но по желание на ученика, съгласувано с преподавателя, може да се изработи WEB приложение, тестова система или хардуерно устройство. да бъде предложено като задача. В същото време основната предпоставка е използването на обектно-ориентиран подход и изграждането на UML модел.

Типичното заглавие на курсовата работа изглежда като „Разработване на информационна и референтна система _ заглавие _ "

Въведение

1. Обширен преглед на предметната област. Основни системни изисквания

2. Подробен модел на информационната система

2.1 Поглед от гледна точка на случаите на използване

2.2 Изглед на дизайна

2.3 Изглед за изпълнение

2.4 Перспектива на процеса (ако е приложимо)

2.5 Изглед от гледна точка на разполагане (ако е необходимо)

3. Внедряване на информационната система

Заключение

Приложение Списък на програма или главен модул

Във въведението можете да посочите използването на информационните технологии в различни сфери на дейност, включително сектора на услугите, предимствата на електронното счетоводство, проблемите на изграждането на специализирани информационни системи и др.

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

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

Когато се подчертават проблемите на внедряването на системата в бележка, препоръчително е да се обоснове изборът на среда за програмиране, да се предостави ръководство за потребителя. Задължителен елемент е включването на екранни форми (screen-shorts) на внедрената програма в текста, насърчава се използването на инструменти за обратно инженерство.

В заключение основните резултати от работата са обобщени накратко: разработен е UML-модел на системата, системата е реализирана чрез такава и такава среда за програмиране, която разработената система позволява, предимствата на използваните подходи (на базата на относно моделирането) към проектирането на системи.

език за моделиране на информационната система

Курсовата работа трябва да съдържа 20-30 страници отпечатан текст с илюстрации. Непременно трябва да се предоставят диаграми на случаи на използване, класове, взаимодействия.

2. Единен език за моделиране UML

Рационалното развитие на информационна система предполага задълбочено предварително аналитично проучване. На първо място е необходимо да се очертае кръгът от задачи, изпълнявани от разработваната система, след това да се разработи модел на системата и накрая да се определят методите за изпълнение. Дълбокото проучване на архитектурата на информационната система, която се разработва в началните етапи на проектиране, като правило, се изплаща по-късно, особено при разработване на мащабни проекти с дългосрочна поддръжка.

Инструментите на езика за моделиране UML (Unified Model Language, - унифициран език за програмиране) позволяват експресивно и доста лесно да се извърши предварителна концептуална разработка на информационна система и в същото време методично съпътства целия процес на разработка, включително целия по-нататъшен жизнен цикъл на разработената информационна система като софтуерен продукт.

UML е обектно-ориентиран език за визуализиране, уточняване, конструиране и документиране на артефакти на софтуерни системи.

UML, както всеки друг език, се състои от речник и правила, които ви позволяват да комбинирате думите, включени в него, и да получите смислени конструкции. В моделиращ език речникът и правилата са фокусирани върху концептуалното и физическото представяне на информационните системи. Моделирането е от съществено значение за разбирането на системата. Като се има предвид това, един модел никога не е достатъчен. Напротив, за да се разбере всяка нетривиална система, трябва да се разработят голям брой взаимосвързани модели. Когато се прилага към софтуерни системи, това означава, че е необходим език, който може да се използва за описване на представяне на архитектурата на системата от различни гледни точки през целия цикъл на разработка.

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

UML е език за спецификации. В този контекст спецификацията означава изграждане на точни, недвусмислени и завършени модели. UML позволява спецификацията на всички важни решения за анализ, проектиране и внедряване, които трябва да бъдат взети по време на разработването и внедряването на софтуерна система.

UML е език за проектиране. Въпреки че UML не е визуален език за програмиране, моделите, създадени с него, могат да бъдат директно преведени на различни специфични езици за програмиране. С други думи, UML моделът може да бъде съпоставен с езици като Java, C ++, Visual Basic и дори релационни таблици на база данни или постоянни обектно-ориентирани обекти на база данни. Тези понятия, които за предпочитане се предават графично, са представени в UML; тези, които са по-добре описани в текстова форма, се изразяват с помощта на език за програмиране.

Това съпоставяне на модел с език за програмиране позволява директен дизайн: генериране на код от UML модел в конкретен език. Можете също да решите обратния проблем: възстановите модела от съществуващата реализация. Естествено, моделът и реализацията включват използването на редица специфични субекти. Следователно, обратното инженерство изисква както инструменти, така и човешка намеса. Комбинацията от генериране на код напред и обратно инженерство ви позволява да работите както в графични, така и в текстови представяния, стига инструментите да гарантират съгласуваност между двете представяния.

В допълнение към директното картографиране в езици за програмиране, UML, поради своята изразителност и уникалност, ви позволява директно да изпълнявате модели, да симулирате поведението на системите и да управлявате операционни системи.

UML е език за документация

Една софтуерна компания произвежда други документи в допълнение към изпълнимия код, включително:

Системни изисквания;

архитектура;

проект;

източник;

планове за проекти;

тестове;

прототипи;

версии и др.

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

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

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

3. Описание на предметната област

Концепцията за предметна област на база данни е едно от основните понятия на компютърните науки и няма точно определение. Използването му в контекста на IP предполага наличието на стабилна връзка във времето между имената, понятията и определени реалности на външния свят, независима от самото IP и неговия кръг потребители. По този начин, въвеждането под внимание на концепцията за предметна област на база данни ограничава и прави видимо пространството за извличане на информация в IS и прави възможно изпълнението на заявки за крайно време.

Под описанието на предметната област имаме предвид описанието на средата на разработваната система, видовете потребители на системата, като същевременно се посочват основните задачи, чието решение е възложено на системата.

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

При разработването на системен речник е необходимо да се дефинират имената на обектите („студент”, „учител”, „дисциплина”). В този случай терминът същност се разбира от нас като компонент от модела на домейна, тоест като обект, вече идентифициран на концептуално ниво. Обектите, разпределени в предметната област, се трансформират от анализатора в обекти.

Обектът е резултат от абстракция на реален обект. Има два проблема, свързани с обектите: идентификация и адекватно описание. За идентификация се използва име, което трябва да е уникално. В този случай се предполага, че има отхвърляне на неговото значение, което е присъщо на естествения език. Използва се само индикативната функция на името. Името е директен начин за идентифициране на обект. Косвените методи за идентификация на обект включват дефинирането на обект чрез неговите свойства (характеристики или атрибути).

Обектите взаимодействат един с друг чрез своите свойства, което поражда ситуации. Ситуациите са отношения, които изразяват връзки между обекти. Ситуациите в предметната област се описват чрез изявления за предметната област. На този етап можете да използвате методите на пропозиционалното смятане и смятането на предикатите, тоест формалната, математическа логика. Например твърдението „Програмистът и мениджърът са служители на компанията“ описва приобщаваща връзка. По този начин цялата информация за обекти и обекти от домейна се описва с помощта на изрази на естествен език.

Можете да посочите структурни връзки, да подчертаете статични и динамични ситуации (като по този начин въведете времеви параметър в модела), но за подробно изследване на модела е по-удобно да използвате разширени средства за описание на домейна, например средства за езика UML.

И така, задачата е да се разработи система "Работна станция на секретаря на катедрата", която да позволява автоматизирано отчитане на данни за служители и студенти на катедрата по ИКТ на OmSTU, предоставя гъвкави възможности за решаване на планирани и непланирани специфични задачи по обработка акредитивни писма.

Като част от решаването на проблема с разработването на AWP за секретаря на отдела, ще отделим следните субекти:

учители - преподаватели от катедрата;

студенти- студенти от университета по тази специалност;

студенти учат в групи, групае организираща (обединяваща) единица за студентите;

завършили студенти, имат особеността, че от една страна сами могат да водят учебни занятия, от друга, самите те са студенти и имат научен ръководител;

дисциплина- преподавана дисциплина (предмет, курс).

Вмъкнатите обекти имат редица атрибути, които ще дефинираме по-късно.

Ние провеждаме два типа потребители: частни потребител(по-нататък потребител, и администратор... Предполага се, че потребителима достъп до системата със заявка, показва отчети, администратордопълнително може да променя данните. Например помощник-секретарят на катедрата може да действа като потребител, самият секретар може да действа като администратор или отговорен учител.

Като се вземат предвид въведените условия, разработваната система трябва да осигурява:

организиране на пълно и достоверно счетоводство на всички служители и студенти от катедрата;

информационна поддръжка на взетите управленски решения, формиране на пълна и достоверна информация за образователните процеси и резултатите от дейността на отдела;

намаляване на разходите за труд за изготвяне на първични документи и отчети;

елиминиране на дублирането при въвеждане на информация и произтичащите от това механични грешки;

удобен за потребителя интерфейс;

разграничаване на правомощията на обикновените потребители и администратора.

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

4. Разработване на модел на софтуерна система посредством UML

UML е език за спецификация и визуализация, основните му единици са диаграми.

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

класови диаграми

диаграми на обекти;

диаграми на случаи на използване;

диаграми на последователност;

диаграми за сътрудничество;

диаграми на състоянието;

диаграми за действие (дейност);

диаграми на компонентите;

диаграми за разгръщане.

UML концептуален модел

Диаграмата на класовете показва класове, интерфейси, обекти и колаборации и техните връзки. При моделиране на обектно-ориентирани системи този тип диаграма се използва най-често. Диаграмите на класовете представляват статичен изглед на дизайн на системата. Диаграмите на класовете, които включват активни класове, съответстват на статичния изглед на системата от гледна точка на процеса.

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

Диаграмата на случаите на използване показва случаи на употреба и участници (специален случай на класове), както и връзките между тях. Диаграмите на случаи на използване се отнасят до статичен изглед на система от гледна точка на случаи на употреба. Те са особено важни при организиране и моделиране на поведението на дадена система.

Диаграмите на последователността и диаграмите на сътрудничество са специални случаи на диаграми на взаимодействие. Диаграмите на взаимодействието представят връзките между обектите; показва по-специално съобщенията, които обектите могат да обменят. Диаграмите на взаимодействие се отнасят до динамичния изглед на системата. В този случай диаграмите на последователност отразяват временното подреждане на съобщенията, а диаграмите на сътрудничество - структурната организация на обектите, обменящи съобщения. Тези диаграми са изоморфни, тоест могат да се трансформират една в друга.

Диаграмите на състоянията представляват автомат, който включва състояния, преходи, събития и типове действия. Диаграмите на състоянието се отнасят до динамичния изглед на системата; те са особено важни при моделиране на поведението на интерфейс, клас или сътрудничество. Те се фокусират върху поведението на даден обект в зависимост от последователността на събитията, което е много полезно за симулиране на реактивни системи.

Диаграмата на дейността е специален случай на диаграма на състоянието; той показва преходите на потока на контрол от една дейност към друга в рамките на системата. Диаграмите на дейността се отнасят до динамичен изглед на система; те са най-важни при моделирането на неговото функциониране и отразяват потока на контрол между обектите.

Диаграмата на компонентите показва организацията на набор от компоненти и зависимостите между тях. Компонентните диаграми се отнасят до статичен изглед на система от гледна точка на изпълнение. Те могат да бъдат свързани с диаграми на класове, тъй като компонент обикновено се съпоставя с един или повече класове, интерфейси или колаборации.

Диаграмата за внедряване показва конфигурацията на обработващите възли на системата и компонентите, поставени в тях. Диаграмите за внедряване се отнасят до статичен изглед на архитектурата на системата от гледна точка на внедряването. Те са свързани с диаграмите на компонентите, тъй като един подвъзел обикновено съдържа един или повече компоненти.

Ето частичен списък с диаграми, използвани в UML. Инструментите ви позволяват да генерирате и други диаграми, като диаграми на профили на база данни, диаграми на уеб приложения и т.н.

4.1 Проектиране на изглед от гледна точка на случай на използване

Моделирането започва с определяне на основните цели на разработваната система и действията, които тя трябва да извършва. За тези цели се използват диаграми на случаи на използване. Както бе споменато по-рано, диаграмите на случаи на използване показват случаи на употреба и участници и връзките между тях.

Прецедент (Случай на използване) е описание на последователност от действия, извършени от системата, която произвежда видим резултат, който е значим за определен действай д ra (актьор). Случаят на използване се използва за структуриране на поведенческите обекти на модела. Прецедентът само декларира описание на някакво действие на системата, отговаряйки на въпроса "какво да правя?", но не посочва с какви средства. Конкретното изпълнение на поведението, определено от случая на използване, се осигурява от клас, сътрудничество с клас или компонент.

Актьорът е съгласуван набор от роли, които потребителите играят, докато взаимодействат с тях. Обикновено актьорът представлява ролята, която човек, хардуерно устройство или дори друга система играе в дадена система. В разработената система „Работна станция на секретаря на отдела” действащите лица са администратор (админ) и потребител.

Графично прецедентът е изобразен като елипса, ограничена от непрекъсната линия, обикновено съдържаща само името си, актьорът има икона "малък човек".

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

Връщайки се към моделирането на автоматизираното работно място на секретаря на отдела, нека подчертаем прецедентите:

Редактиранеданни,

Търсенестудент,

Търсенеучител,

Издаванесписъкпреподавадисциплини,

Упълномощаване.

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

Най-често срещаната връзка между случаи на употреба, случаи на употреба и участници е асоциацията. В някои случаи могат да се използват обобщаващи отношения. Тези връзки имат същото значение като в диаграмата на класовете.

В допълнение, две специфични зависимости са дефинирани между случаите на използване в UML - връзка за включване и връзка за разширение.

Връзката на включване между случаите на употреба означава, че в даден момент в основния случай на употреба е включено (включено) поведението на друг случай на употреба. Включеният случай на употреба никога не съществува автономно, а се инстанцира само като част от обграждащия случай на употреба. Можете да мислите за базовия случай на използване като заемане на поведението на включения. Поради наличието на връзки на включване е възможно да се избегнат множество описания на един и същи поток от събития, тъй като общото поведение може да се опише като независим случай на използване, включен в базовите. Връзката на включване е пример за делегиране, при който редица отговорности на системата са описани на едно място (в включен случай на използване), а останалите случаи на използване, когато е необходимо, включват тези отговорности в техния набор.

Връзките на включване са изобразени като зависимости със стереотипа „включи“. За да посочите място в потока от събития, където основен случай на употреба включва поведението на друг, просто напишете думата include, последвана от името на случая на употреба, който да включите.

Връзката с разширение се използва за моделиране на части от случай на използване, който потребителят възприема като незадължително поведение на системата. Това ви позволява да разделите задължителните и незадължителните поведения. Връзките на разширението също се използват за моделиране на отделни подпотоци, които се изпълняват само при определени обстоятелства. И накрая, те се използват за симулиране на множество потоци, които могат да бъдат задействани в даден момент от сценария в резултат на изрично взаимодействие с актьора.

Връзката на разширението е изобразена като зависимост със стереотипа "разширяване". Точките за разширение на основния скрипт са изброени в допълнителен раздел. Те са просто етикети, които могат да се появят в потока на основния случай на употреба.

Пример за използване на тази връзка може да бъде достъпът до база данни с оперативна част и архив. В този случай, ако заявката е предоставена с данните от оперативната част, се извършва основният (основен) достъп до данните, ако данните от оперативната част не са достатъчни, се осъществява достъп до архивните данни, т.е. , достъпът се извършва по разширения сценарий.

В нашия случай прецедентът редактиранеданнивключва случаи на употреба: входданни, изтриванеданни, промянатаданни.

Диаграмата на прецедентите на AWP на секретаря на отдела е показана на фиг. 1.

Ориз. 1. Схема на прецедентите на АРМ на секретаря на отдела

Прецедент Търсенестудентвключва търсене по фамилно име и търсене по резултати от академични резултати.

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

Потоците от събития могат да бъдат описани с помощта на неструктуриран текст, структуриран текст (съдържащ служебни думи: АКО,ПРЕДИТЕЗИPORДОКАТОи др.), специализиран формален език (псевдокод).

Когато се описва случай на използване като поток от събития, важно е също така да се посочат основните и алтернативни потоци на поведението на системата.

Например, разгледайте описанието на потока от събития от случая на използване разрешение.

Основен поток събития. Случаят на използване започва, когато системата поиска от потребителя за неговото име и парола. Потребителят може да го въведе от клавиатурата. Завършва въвеждането с натискане на клавиша Въведете. След това системата проверява въведените Логин и парола и ако съвпадат с администратора, потвърждава пълномощията на администратора. Това завършва прецедента.

Изключително поток събития. Клиентът може да прекрати транзакцията по всяко време с натискане на клавиша Отмяна. Това действие поставя началото на прецедента отначало. Няма влизане в системата.

Изключително поток събития. Клиентът може да изтрие своите Логин и парола по всяко време, преди да натисне клавиша Enter.

Изключително поток събития. Ако клиентът е въвел вход и парола, които не отговарят на администратора, му се предлага да влезе отново или да влезе в системата като обикновен потребител.

Очевидно описанието на случай на използване чрез поток от събития предполага някакъв вид алгоритъм, който може да бъде представен в диаграма на дейност (фиг. 2).

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

Подобни диаграми могат да обяснят изпълнението на други случаи на употреба, като по този начин допълват изгледа на системата от гледна точка на случаите на употреба.

Ориз. 2. Упълномощаване на потребителя. Диаграма на дейността.

4.2 Разработване на изглед за дизайн

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

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

При моделирането трябва да се помни, че всеки клас трябва да съответства на някакъв реален обект или концептуална абстракция от областта, с която се занимава потребителят или разработчикът. Добре структуриран клас има следните свойства:

е добре дефинирана абстракция на някаква концепция от речника на проблемната област или областта на решението;

съдържа малък, добре дефиниран набор от отговорности и изпълнява всяка една от тях;

поддържа ясно разделение между спецификациите на абстракцията и нейното изпълнение;

ясно и просто, но в същото време дава възможност за разширяване и адаптиране към нови задачи.

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

Атрибут адресима собствена структура, за да я отрази, можете да въведете допълнителен клас, да го наречем T_ ADR(както е обичайно в много системи за програмиране, имената на класовете започват с буквата Т). Имайте предвид, че атрибутът адресклас човеке екземпляр на класа T_ ADR, тоест между тези класове се установява връзка на зависимост (обозначена с пунктирана стрелка с отворен връх, стрелката е насочена от зависимия към независимите). В нашия случай промяна на структурата на класа T_ ADRводи до смяна на класа човекчрез структурата на съответния атрибут ( адрес).

При моделиране на клас T_ ADRатрибут индексзададени с помощта на примитивен тип T_ POSTIDX, дефинирано като шестцифрено десетично число. Примитивните типове са стереотипни " Тип" , диапазонът от стойности се посочва чрез ограниченията, затворени в къдрави скоби.

В клас учителнека подчертаем специфичните атрибути, свързани само с учителя: позиция, уч. степен(академична степен), уч. ранг (академичен ранг), освобождаване от отговорност(категория от единна тарифна скала). Атрибути уч. степени уч. рангпо-добре е да се дефинират специализирани типове чрез изброяване. Изброяванията се моделират от клас със стереотип " enum" (изброяване - изброяване), разрешените стойности се записват като атрибути, етикетите, които определят видимостта на атрибутите, са потиснати. В този пример чрез изброяването въвеждаме специализирани класове T_Трябва да, T_UCHST, T_UchZv, съответно определяне на възможни длъжности, академични степени, академични звания чрез премествания. В този случай, както и другаде в подобни случаи, при създаване на класове, които определят атрибутите на основния клас, се установяват отношения на зависимост.

За класа студентсе въвежда специфичен атрибут стаярекордни книги... Определени са специфични атрибути за следдипломния клас форматаизучаване наи датапостъпления... Формата на обучение ще се определя от специален клас чрез изброяване T_FormObuch(на пълен работен ден, на непълно работно време).

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

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

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

Ориз. 3. Схема на класовете на AWP на секретаря на катедрата (вариант 1)

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

Върху въведения набор от класове е необходимо да се предефинират връзките. Връзките на обобщението и зависимостите вече са определени, остава да се дефинират асоциациите.

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

В този случай, както и в повечето други, посоката на асоциациите е двупосочна, така че е по-добре да потиснете навигацията (махнете отметката от полето Navigable на опцията Detail Role)

Нека дефинираме връзка между учителии преподава дисциплинимного към много: един учител може да преподава няколко дисциплини, някои дисциплини могат да се преподават от няколко учители. Между дисциплинии специалностисе създава и асоциацията „много към много”: учебната програма на специалностите съдържа много дисциплини, повечето от дисциплините се намират в работните планове на няколко специалности. Класът на асоциацията е прикрепен към тази асоциация. Дисциплини-специалностис атрибути, указващи дисциплината, броя на семестрите и броя на часовете по дадена дисциплина по дадена специалност.

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

За да се отрази присъствието на ръководител за дипломиран студент, е необходимо да се въведе асоциация между аспирант и преподавател от типа „много към един“, един ръководител може да има няколко дипломирани студенти. В тази асоциация, от страна на учителя, можете изрично да посочите ролята: ръководител.

Ориз. 4. Класна схема на AWP на секретаря на отдела (вариант 2)

Във всяка групидима лидер на група, този факт може да бъде показан чрез допълнителна асоциация (нека му дадем име глава) от група към ученици с тип кратност "едно към едно". В този случай можете изрично да посочите навигацията.

Следдипломни студентиможе също да преподава специфични дисциплини на конкретни групи: асоциации много към много следдипломни групи, следдипломни дисциплини. Някои завършили студенти може да не преподават, така че типът множественост в краищата на асоциацията ще бъде 0. n.

Окончателната класова диаграма е показана на фиг. 3.

Ориз. 5. Опростена диаграма на класовете

Като се има предвид, че както студенти, така и преподаватели преподават часове, може да се въведе допълнителен абстрактен час, напр. преподаванекойто е потомък на класа човеки суперклас за класове учители дипломиран студент, което леко ще намали броя на връзките. (фиг. 4.). В случая от класовете дисциплинаи групаасоциациите ще отидат в час преподаване, като се приеме връзка към класовете учители дипломиран студентчрез наследяване (отношение на обобщение). До клас преподаванеможете да извадите атрибутите предложение(0,5 ставка, пълна ставка) и освобождаване от отговорност.

Получената диаграма е доста сложна и натоварена с елементи, но моделирането на класовете далеч не е завършено: все още трябва да се дефинират някои полезни класове и интерфейси. За да разтоварим диаграмата на класовете, ще изградим нов изглед към нея (на отделна диаграма), като оставим изображението на основните класове и потиснем показването на спомагателни, определящи видовете атрибути (фиг. 5).

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

Нека да преминем към дефинирането на интерфейсите. Класовете взаимодействат с външния свят чрез интерфейси.

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

Нека поставим на диаграмата класа електроннимаса, който капсулира всички свойства и операции на електронната таблица, която ви позволява да редактирате данните. Няма да разкриваме структурата на този клас поради голямата му сложност. Така че в съвременните инструменти за разработка на приложения потребителят използва готови класове и шаблони, наследявайки техните възможности, например библиотеката VCL (Delphi) съдържа клас TTable, който капсулира възможностите на електронна таблица. Потомци на класа електроннимасаса специфични електронни таблици, съдържащи конкретни данни за преподаватели, аспиранти, студенти, групи, дисциплини и специалности. Като направи съответните класове потомци на класа електроннимаса, ние декларираме за тези класове всички свойства и операции, присъщи на електронните таблици (регистрация в системата, вмъкване, изтриване, редактиране на данни, сортиране и т.н.).

За класа електроннимаса, и съответно за всички негови потомци ние дефинираме интерфейса редактиране,което предполага всички възможни операции за редактиране на данни (вмъкване, изтриване, промяна на данни). В този случай се приема, че в клас електроннимасатези възможности са реализирани.

Използване на персонализиран клас електроннимасаи наследяването избягва дефинирането на специални свойства и интерфейси за редактиране на данни за всяка електронна таблица.

Нека дефинираме интерфейсите Търсенеучител, Търсенедисциплиникато ги прикачите към съответните им класове с връзка за изпълнение. Няма да разкриваме състава на операциите на тези интерфейси (той е доста тривиален), следователно ще показваме интерфейсите в съкратена форма (под формата на кръг). Припомнете си, че връзка на реализация, прикрепена към интерфейс в съкратена форма, се показва като проста плътна линия (като асоциация).

Интерфейс Търсенестудентще се показва с индикация на списъка с операции чрез стереотипен клас, докато релацията за изпълнение е показана с пунктирана стрелка със затворен връх.

Естествено се приема, че въведените интерфейси са имплементирани посредством класовете, към които са прикрепени чрез връзката имплементация, тоест съответните класове съдържат операции и методи, които реализират декларираните интерфейси. За по-лесно възприемане тези механизми не се визуализират.

За да управляваме правата за достъп и оторизацията на потребителя, ние въвеждаме класа мениджърдостъп... Мениджърът на достъп има атрибут за частен тип достъп масапароликойто е екземпляр на класа CodirTable(Кодирана таблица), съдържаща пароли ( парола) и входни имена ( Влизам) администраторски потребители. Предполага се, че възможностите на сервизния клас CodirTableне позволявайте на неоторизиран потребител да чете потребителски пароли. На този етап от проектирането ние просто декларираме такива възможности, без да се спираме на механизма за тяхното изпълнение, а предполагаме, че те са капсулирани в клас CodirTable.

клас мениджърдостъпсъдържа открити транзакции входпаролаи предоставяне на администраторски права, чрез които се осъществява оторизация и управление на правата за достъп.

Нека посочим зависимостта между интерфейса за редактиране на данни ( редактиране) и мениджър за достъп, като се приеме, че само потребители с администраторски права имат пълни възможности за редактиране на данни.

Ориз. 6. Окончателната схема на класовете на АРМ на секретаря на катедрата

Крайната диаграма е показана на фиг. 6.

Така че на този етап разработването на обектно-ориентиран модел на работната станция на секретаря на отдела с помощта на диаграмата на клас UML може да се счита за завършена. Естествено е възможно да се върнете към него и да преразгледате някои елементи по време на проектирането на системата, при коригиране на задачи, при изясняване на отделни детайли. Процесът на проектиране на информационни системи е итеративен. Трябва да се отбележи, че разработената диаграма на класовете съдържа елементи, които изрично или имплицитно реализират всички случаи на използване на диаграмата на случаите на използване. Всеки случай на употреба на диаграмата на случай на употреба трябва да съответства или на интерфейс, или на интерфейсна операция (приема се внедряването в класовете, съответстващи на интерфейса), или на публична операция на класа, или на набор от публични операции (в този случай, случаят на използване се реализира директно от съответния клас или набор от класове).

Нека да разгледаме процеса на създаване на нов запис на ученик с помощта на диаграма на последователност.

Създаването на нов запис предполага администраторски права, така че администраторът ще бъде протагонистът на това взаимодействие ( админ). Този елемент вече е въведен в диаграмата на случаите на използване, така че го плъзнете върху диаграмата на последователността от браузъра за преглед на случаи на употреба.

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

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

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

Мениджързаписи- обект, който има стандартен набор от възможности за управление на данни при работа с електронна таблица. Този набор от възможности се наследява от класа студентиот клас електроннимаса... За обект Мениджързаписикласът, на който е екземпляр, е изрично посочен - студенти.

Петров- специфичен запис за ученик Петров, нов елемент от таблицата за ученици. Тук изрично посочваме въведения клас записОстудент... Такива обекти обикновено съществуват временно, за да изпращат подходяща информация към базата данни по време на транзакции. След края на транзакцията този обект може да бъде унищожен. Обектът, съответстващ на записа, може да бъде създаден отново, ако е необходимо да се редактира информацията.

Мениджъртранзакции- обект, който осигурява изпълнението на завършена операция върху базата данни, в този случай създаването на нов запис за ученик Петров. Този обект е отговорен и за изпълнението на редица системни функции, които придружават транзакцията. Примери за мениджъри на транзакции са например BDE (използва се за достъп до бази данни Paradox, Dbase и др. от приложения Delphi), ADO (използва се за достъп до бази данни на MS Access от различни приложения).

Диаграмата на последователността за въвеждане на нов запис за ученик в AWS на секретаря на катедрата е показана на фиг. 7.

Ориз. 7. Въвеждане на студентски данни. Диаграма на последователността.

В диаграмата на последователността ние дефинираме предаването на съобщения между обекти: създавайновзапис(излъчва се от обект на обект до края на веригата като съобщение спасизапис); отворенформа(към формата за въвеждане); да въведеФ.И ЗА.,адрес. (въвеждане на студентски данни), тогава тези данни се излъчват чрез съобщения спасиФ.И ЗА.,адрес. От мениджъртранзакцииизпращане на съобщение събиране информацияОстудентпредоставяне на обратна връзка към базата данни и накрая рефлексивно съобщение мениджъртранзакциинаречена като спасизаписvDB, гарантира края на транзакцията.

При желание това взаимодействие може да бъде представено чрез диаграма на сътрудничество, илюстрираща преди всичко структурния аспект на взаимодействието (фиг. 8). Тази диаграма може да бъде изградена от предишната в автоматичен режим (в Rational Rose чрез натискане на клавиша F5).

Ориз. 8. Въвеждане на данни за ученика. Диаграма за сътрудничество.

Ако е необходимо, проектът може да бъде допълнен с други диаграми на взаимодействие, които разкриват работата на случаите на използване.

4.3 Разработване на профил на релационна база данни

В случай, че за внедряване на системата се използва обектно-ориентирана СУБД (OODBMS), изградената в предишния раздел обектна диаграма е окончателният модел и пряко ръководство за внедряването на информационната система. В същия случай, когато се предполага, че релационна база данни (RDB) се използва като информационно ядро ​​на информационна система, е необходимо да се разработи друга диаграма, профилна диаграма на релационна база данни.

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

маса (Таблица) - набор от записи в базата данни за конкретен обект, състои се от колони.

Колона ( Column) е компонент на таблицата, съдържащ един от атрибутите на таблицата (поле на таблицата).

Основен ключ (Първичен ключ) - възможен ключ, избран за идентифициране на редове в таблицата.

Външен ключ (Външен ключ) - една или повече колони на една таблица, които са първични ключове на друга таблица.

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

Съхранено процедура (Съхранена процедура) е независима процедурна функция, изпълнявана на сървъра.

домейни ( Domains) е валиден набор от стойности за атрибут или колона.

В допълнение към тези обекти могат да бъдат въведени някои допълнителни обекти, които отразяват специфични аспекти на модела на базата данни.

Подобни документи

Методологии за разработване на информационни системи в родна и чужда литература. Държавни и международни стандарти в областта на разработката на софтуер. Разработване на фрагмент от учебно-методичната ресурсна информационна система.

курсова работа, добавена на 28.05.2009


Определение на понятието "система". Историята на развитието и характеристиките на съвременните информационни системи. Основните етапи от развитието на автоматизирана информационна система. Използване на вътрешни и международни стандарти в областта на информационните системи.

презентация добавена на 14.10.2013 г


Основната идея на методологията и принципите на RAD-разработване на информационни системи, нейните основни предимства. Причини за популярността, особености на приложението на технологията. Формулиране на основните принципи на развитие. Среди за разработка, използващи принципи на RAD.

Презентацията е добавена на 04/02/2013


Ролята на управленската структура в информационната система. Примери за информационни системи. Структура и класификация на информационните системи. Информационни технологии. Етапи на развитие на информационните технологии. Видове информационни технологии.

курсова работа е добавена на 17.06.2003 г


Концепцията за CASE-инструменти като софтуерни инструменти, които поддържат създаването и поддържането на информационни системи (ИС). Характеристики на IDEF-технологията за развитие на ИС. Описание на нотацията IDEF0. Разработване на функционални модели на бизнес процес.

презентация добавена на 04/07/2013


Същността на единния език за моделиране, неговия концептуален модел и принцип на действие, общи правила и механизми. Моделиране на понятието "компетентност". Диаграма на класа, описваща образователния процес. Внедряване на дадена информационна система.

дисертация, добавена на 17.02.2015г


Развитие на информационни системи. Съвременният пазар на финансово-икономически приложен софтуер. Предимства и недостатъци на внедряването на автоматизирани информационни системи. Методи за проектиране на автоматизирани информационни системи.

дисертация, добавена на 22.11.2015г


Понятие за информационна система, видове информационни системи. Анализ на инструменти за разработване на автоматизирани информационни системи. Изисквания към програмата и софтуерния продукт. Разработване на форми на графичен интерфейс и бази данни.

дисертация, добавена на 23.06.2015г


Решение за информационна сигурност. Системи за центрове за данни. Какво е хардуер на центъра за данни. Основни понятия и принципи на моделирането. Изборът на метод за решаване на проблеми. Метод на Zoitendijk на допустимите посоки, алгоритъм на Франк – Улф.

курсова работа, добавена на 18.05.2017


Концепция за информационна система. Етапи на развитие на информационните системи. Процеси в информационната система. Информационна система за намиране на пазарни ниши, за намаляване на производствените разходи. Структурата на информационната система. Техническа поддръжка.

МИНИСТЕРСТВО НА ОБРАЗОВАНИЕТО НА РУСКАТА ФЕДЕРАЦИЯ УЛЯНОВСК ДЪРЖАВЕН ТЕХНИЧЕСКИ УНИВЕРСИТЕТ V.S.SHCHLEIN МОДЕЛИРАНЕ НА ИНФОРМАЦИОННИ СИСТЕМИ Бележки от лекции за студенти по направление 652100 "Авиостроене" Уляновск 2002 г. 2 УДК на ВДК.062 на университета V.S.H.62. Щ Моделиране на информационни системи: записки от лекции / V.S. SHCHEKLEIN. - Уляновск: UlSTU, 2002 .-- с. Бележките от лекциите са подбрани материали, използвани през учебната 1999/2000 г. при провеждане на учебните занятия по дисциплината "Моделиране на информационни системи". Предназначена е за студенти от специалности: 130107 "Софтуерна обработка на строителни материали" и 130111 "Управление на проекти на производство на самолети". Това ръководство не е пълно, планира се включването на нов разработен материал, чийто подбор и дизайн се извършва в съответствие с утвърдената програма за дисциплина. 3 СЪДЪРЖАНИЕ ВЪВЕДЕНИЕ ………………………………………………………… .. РЕАЛИЗАЦИЯТА МУ С КОМПЮТЪР ................. 7 3. СТАТИСТИЧЕСКИ обобщени симулации на алгоритъм . ................................................................ ............... 9 4. СИМУЛАЦИОННА случайна величина с даден закон РАЗПРЕДЕЛЕНИЕ. СИМУЛАЦИЯ НА СЛУЧАЙНИ СЪБИТИЯ …………………………………………………… .. 5. ПОДХОД КЪМ СИМУЛАЦИЯ НА СИСТЕМИ …………………… 15 6. ЗАДАВАНЕ НА СЛУЧАЙНИ СТОЙНОСТИ И СЛУЧАЙНИ СЪБИТИЯ В EXCEL ...................... 23 8. МОДЕЛИРАНЕ НА СИСТЕМИ ЗА МАСОВО ОБСЛУЖВАНЕ. 25 9. Структура на информационно-изчислителния систематичен ТЕМ ........................................ ......................................... 26 9.1. Концепцията на процеса ………………………………………………………………………… .. 28 9.2. Натовареност …………………………………………………… 29 10. ПОКАЗАТЕЛИ ЗА ДЕЙСТВИЕ НА ИНФОРМАЦИОННАТА СИСТЕМА ………………………………………………………… ……… .. 30 11. ОЦЕНКА НА ЕФЕКТИВНОСТТА НА КОМПОНЕНТИТЕ НА СИСТЕМАТА …………………………………………………………………………………….…. 31 12. ОЦЕНКА НА ЕФЕКТИВНОСТТА НА СИСТЕМАТА ОБЩО ……. 32 13. ВЛИЯНИЕ НА РЕЖИМА ЗА ОБРАБОТКА НА ДАННИ ……………………………… .. 35 14. ХАРАКТЕРИСТИКИ НА НАДЕЖДНОСТ ………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………… .. …………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………………………………………………………… ……………………………………………………………………………………………………………. 40 ЛИТЕРАТУРА ………………………………………………. 46 4 ВЪВЕДЕНИЕ Полезността на математическото моделиране за решаване на практически задачи изобщо не предизвиква съмнения. Може да възникне въпросът, защо е необходимо да се овладее моделирането на информационни системи (а сега тези системи не могат да си представят без компютри) за строители на самолети, фокусирани върху технологията на производство на самолети? Съвременните технологии стават все по-автоматизирани. Един съвременен производител на самолети, независимо дали е дизайнер или технолог, трябва да използва компютри в работата си. Съществува опасност от неадекватна оценка на възможностите на компютъра при решаване на инженерни задачи. Това може да доведе или до отказ от автоматизиране на един или друг фрагмент от технологичния процес, или до неоправдани разходи за изчислителна техника, чиито възможности са силно надценени в сравнение с необходимите. Така нареченият здрав разум обаче може да доведе до сериозни грешки в оценката. Целта на дисциплината е да се снабди млад специалист с апарат за оценка на информация и компютърни системи, така че да може правилно да вмести средствата за автоматизация в контурите на производството или управлението. Освен това, чрез моделиране на определени системи, студентите придобиват косвен опит в оптимизирането на системи и затвърждават уменията за използване на компютър за решаване на професионални проблеми. 1. ОСНОВНИ ПОНЯТИЯ НА ТЕОРИЯТА НА МОДЕЛИРАНЕТО Моделирането е замяната на един обект с друг с цел получаване на информация за най-важните свойства на обекта – оригинала с помощта на обекта – модела. Модел (фр. modele от лат. modulas - мярка, проба): 1) проба за масово производство на продукт; марка на продукта; 2) продуктът, от който е премахната формата (шаблони, шарки, площадки); 3) лицето или предмета, изобразен от художника; 4) устройство, което възпроизвежда структурата или действието на всяко друго устройство; 5) всяко изображение на обект, процес или явление, използвано като представител на оригинала (изображение, диаграма, чертеж, карта); 6) математическият апарат, описващ обект, процес или явление; 7) устройство за получаване на отпечатък в леярска форма. По-нататък, освен ако не е посочено друго, моделът ще се разбира като математически апарат. Всички модели имат определена структура (статична или динамична, материална или идеална), която е подобна на структурата на оригиналния обект. В процеса на работа моделът действа като относително независим квазиобект, което дава възможност да се получат известни знания за самия обект по време на изследване. Ако резултатите от такова изследване (моделиране) се потвърдят и могат да послужат като основа за прогнозиране в изследваните обекти, тогава се казва, че моделът е адекватен на обекта. В този случай адекватността на модела зависи от целта на моделирането и възприетите критерии. Процесът на моделиране предполага наличието на: - обекта на изследване; - изследовател с конкретна задача; - модел, създаден за получаване на информация за обект, необходима за решаване на проблем. По отношение на модела изследователят е експериментатор. Трябва да се има предвид, че всеки експеримент може да има значително значение в конкретна област на науката и техниката само при специална обработка на резултатите от него. Един от най-важните аспекти на системното моделиране е проблемът с целта. Всеки модел се изгражда в зависимост от целта, поставена от изследователя, следователно един от основните проблеми при моделирането е проблемът за целта. Приликата на протичащия в модела процес с реалния процес не е самоцел, а условие за правилното функциониране на модела. Целта трябва да бъде изследване на някои аспекти от функционирането на обекта. Ако целите на моделирането са ясни, тогава възниква следващият проблем, проблемът за изграждане на модел. Тази конструкция се оказва възможна, ако има информация или се изтъкват хипотези относно структурата, алгоритмите и параметрите на изследвания обект. Трябва да се подчертае ролята на изследователя в процеса на изграждане на модел, този процес е творчески, базиран на знания, опит, евристика. Формалните методи, които позволяват достатъчно точно описание на система или процес, са непълни или просто липсват. Следователно изборът на тази или онази аналогия се основава изцяло на опита на изследователя, а грешките на изследователя могат да доведат до погрешни резултати от моделирането. Когато моделът е изграден, тогава следващият проблем може да се счита за проблема с работата с него, изпълнението на модела. Тук основните задачи са да се сведе до минимум времето за получаване на крайни резултати и да се гарантира тяхната надеждност. За правилно построен модел е характерно, че той разкрива само онези закономерности, които са необходими на изследователя, а не отчита свойствата на системата – оригинала, които са незначителни в дадения момент. Класификацията на видовете системно моделиране е показана на фиг. 1.1. Математическото моделиране е изграждането и използването на математически модели за изследване на поведението на системи (обекти) в различни условия, за получаване (изчисляване) на определени характеристики на оригинала, без да се правят измервания или с малък брой от тях. В рамките на математическото моделиране са разработени два подхода: - аналитичен; - имитация. 6 Моделиране на системата Детерминистичен Стохастичен Статичен Динамичен Дискретен Дискретен Непрекъснат Непрекъснат Абстрактен Материал Визуален Символичен Математически Природен Физически Аналитичен Комбиниран. Симулация Фиг. 1.1. Аналитичният подход се основава на изграждането на формулни зависимости, свързващи параметрите и елементите на системата. Дълго време този подход всъщност беше математически подход. Въпреки това, когато се разглеждат сложни системи, строгите математически зависимости са много сложни; за получаване на необходимите стойности на параметрите са необходими голям брой измервания. Анализът на характеристиките на процесите на функциониране на сложни системи, използващи само аналитични методи на изследване, среща значителни трудности, което води до необходимостта от значително опростяване на моделите или на етапа на тяхното изграждане, или в процеса на работа с модел, което намалява надеждността на резултатите. Симулационният (статистически) подход към моделирането се основава на използването на пределната теорема на Чебишев за вероятностно представяне на параметрите на системата. Въз основа на предварително проучване на моделираната система е доста лесно да се определят видовете и стойностите на законите за разпределение на случайните променливи на параметрите. В рамките на симулационния подход се използват аналитични зависимости между параметрите на елементите на системата, но тези зависимости са от по-обобщен, опростен характер. Те са много по-прости от зависимостите в аналитичния подход. 7 Математическото моделиране на системи, включително информационни системи, е насочено към оптимизиране на структурата на системите, избор на най-оптималните режими на функциониране на системите, определяне на необходимите характеристики на хардуера и софтуера. Математическото моделиране на технологични процеси, включително информационни процеси, има за основна цел намиране на оптимални или приемливи характеристики на самия обект, намиране на оптимални режими на обработка, обучение на персонал и осигуряване на определени функции за управление. При всички случаи моделирането трябва да отговаря на следните изисквания: - моделите да са адекватни на съответните системи или технологични задачи; - трябва да се осигури необходимата точност; - трябва да се осигури удобството на потребителя - специалист по технология или обработка (управление) на информация: - разбираем интерфейс за управление на моделиране; - достатъчна скорост на работа; - видимост на резултатите; - приемливи разходи за разработване и използване на симулационни инструменти. 2. СЪЩНОСТ НА МЕТОДА НА СТАТИСТИЧЕСКИТЕ ТЕСТОВЕ И РЕАЛИЗИРАНЕТО му С ПОМОЩТА НА КОМПЮТЪР Методът на статистическото моделиране се състои в възпроизвеждане на изследвания процес с помощта на вероятностен математически модел и изчисляване на характеристиките на този процес. Методът се основава на многократно тестване на конструирания модел с последваща статистическа обработка на получените данни, за да се определят характеристиките на разглеждания процес под формата на статистически оценки на неговите параметри. Разгледайте уравнението: y = f (x, t, ξ), (2.1) където y е системен параметър, който трябва да се определи, x е фазова променлива, t е време, ξ е случаен параметър, чийто закон на разпределение е познато ни. Ако функцията f е по същество нелинейна, тогава няма универсални методи за решение за решаване на този проблем и достатъчно напълно разработени редовни методи за намиране на оптимални решения могат да се прилагат само чрез поставяне на видимостта на използването на математиката на преден план; опростяването ще доведе до сериозна загуба на точност. Математическият модел ще стане неадекватен 8 за изучаваната система, а моделирането ще бъде само форма на заблуда. Въпреки това, ако е възможно да се конструира функция y = ϕ (ξ) и генератор на случайни числа ξ 1, ξ 2, ..., ξ N с даден закон на разпределение, тогава стойността на y може да се изчисли като y = ∑ ϕ (ξ i) N, (2.2) където ϕ (ξ 1) е стойността на i-тата реализация. Ако f (x, t, ξ) е аналитичен модел на процеса на преобразуване на информация или технологичния процес на обработка на детайл, то ϕ (ξ) ще бъде статистически модел. Някои принципи и техники за конструиране на статистически модели ще бъдат обсъдени по-късно. Важно е, че при конструирането на функцията y = ϕ (ξ) и генератора на случайни числа ξ 1, ξ 2, ..., ξ N на хартия, в преобладаващото мнозинство от случаите е доста лесно да ги реализирате на компютър с помощта на подходящия софтуер. В този случай резултатите ще съдържат грешка, но тази грешка е по-малка от грешките поради допускания в аналитичния модел. Освен това грешката, дължаща се на прилагането на статистическия модел, може да се определи количествено. Тази техника се разширява до по-сложни случаи, когато уравнение (2.1) съдържа не само случайни параметри, но и случайни функции. След получаване на N реализации на компютър следва етапът на обработка на статистиката, който позволява да се изчислят, наред с математическото очакване (2.2), и други параметри ϕ (ξ), например дисперсията D = 1 N * ∑ xi - 1 N 2 * (∑ xi). При метода на статистическите тестове, за да се получат достатъчно надеждни резултати, е необходимо да се осигури голям брой реализации N, освен това при промяна на поне един начален параметър на задачата е необходимо да се извърши серия от N теста отново. В сложните модели неоправдано голяма стойност на N може да се превърне в фактор, забавящ получаването на резултата. Ето защо е важно правилно да оцените необходимия брой резултати. Доверителният интервал ε, доверителната вероятност α, дисперсията D и броя на реализациите N са свързани с отношението ε = D NФ −1 (α), където Ф −1 (α) е обратната функция на функцията на Лаплас . На практика можете да използвате съотношението N ≤ D ε 2 * 6,76 за α ≥ 0,99, като с цел надеждност вземете най-голямата стойност на N от съотношението (). Оценка на дисперсията D може да бъде получена предварително с помощта на същия статистически модел за броя на реализациите n, n<< N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

„Компютърно математическо моделиране” Цели на изучаване на раздела. Овладяване на моделирането като метод за опознаване на заобикалящата действителност (научно-изследователска природа на раздела) - показва се, че моделирането в различни области на знанието има сходни характеристики, често за различни процеси е възможно да се получат много сходни модели; - демонстрира предимствата и недостатъците на компютърния експеримент в сравнение с пълномащабния експеримент; - показва се, че както абстрактният модел, така и компютърът дават възможност за опознаване на околния свят, за управлението му в интерес на човека. Развитие на практически умения по компютърно моделиране. Дадена е общата методология на компютърното математическо моделиране. На примера на редица модели от различни области на науката и практиката се реализират практически всички етапи на моделиране, от формулирането на задачата до интерпретацията на резултатите, получени в хода на компютърен експеримент. Насърчаване на професионалното ориентиране за ученици. Разкриване на склонността на ученика към изследователска дейност, развитие на творческия потенциал, ориентация към избора на професия, свързана с научни изследвания. Преодоляване на предметната дисоциация, интегриране на знания. Курсът разглежда модели от различни области на науката с помощта на математика. Развитие и професионализиране на компютърните умения. Овладяване на софтуер за общо и специализирано предназначение, системи за програмиране.

Задачи и функции на информационната система.

IS може да реши две групи задачи. Първата група е свързана с чисто информационно осигуряване на основната дейност (избор на необходимите съобщения, тяхната обработка, съхранение, търсене и доставка до субекта на основната дейност с предварително определена пълнота, точност и ефективност в най-приемлива форма). Втората група задачи е свързана с обработка на получената информация/данни в съответствие с определени алгоритми с цел изготвяне на решения на задачите, стоящи пред предмета на основната дейност. За да разреши подобни проблеми, ИС трябва да разполага с необходимата информация за предметната област. За да разреши подобни проблеми, ИС трябва да има определен изкуствен или естествен интелект. Информационна система - система за подпомагане и автоматизиране на интелектуалната работа - търсене, администриране, експертиза и експертни оценки или преценки, вземане на решения, управление, признаване, натрупване на знания, обучение. Задачите на първата група са задачите за информатизация на обществото "в ширина".

Задачи от втора група - задачи по информатизация

дълбоко в обществото.

За решаване на поставените задачи ИС трябва да изпълнява следните функции:

 подбор на съобщения от вътрешната и външната среда, необходими за осъществяване на основната дейност;

 въвеждане на информация в ИС;

 съхраняване на информация в паметта на ИС, нейното актуализиране и поддържане на целостта;

 обработка, търсене и издаване на информация в съответствие с изискванията, определени от ODS. Обработката може също да включва подготовка на опции за решаване на проблеми, приложени от потребителя.

Информационна система (ИС) - взаимосвързан набор от инструменти, методи и персонал, използвани за съхраняване, обработка и издаване на информация с цел постигане на целта. Съвременното разбиране за информационната система включва използването на персонален компютър като основно техническо средство за обработка на информация. ИС е среда, съставните елементи на която са компютри, компютърни мрежи, софтуерни продукти, бази данни, хора, различни видове технически и софтуерни комуникации и др. Въпреки че самата идея за IP и някои принципи на тяхната организация се появиха много преди появата на компютрите, обаче, компютъризацията увеличи ефективността на IP с десетки и стотици пъти и разшири обхвата на тяхното приложение.

Функционалната структура на информационната система.

В IS е препоръчително да се разграничат три независими функционални подсистеми.

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

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

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

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

Изпълнението на тези функции изисква устройство за описание и анализ на информационните нужди и тяхното изразяване на езика на IS (включително LOD, IPL, език за индексиране и др.), както и апарат за самата информационна поддръжка (процедури за търсене и издаване на информация , езици за манипулиране на данни и др.). Много функции на подсистемите на ИС се дублират или припокриват, което е предмет на оптимизация при проектирането на ИС. В тази връзка автоматизацията на ИС е придружена от преразпределение на елементите на ИС.

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

От тази гледна точка „нивото на автоматизация“ на ИС е тясно свързано със „степента на структуриране“ на информацията. Има три нива на структурирана информация: Твърдо структурирана информация (данни) - информация, чието формализирано представяне чрез съвременни средства за нейното структуриране (по-специално езици за описание на данни) не води до загуба на адекватността на информационния модел за оригинала

информация. Слабо структурираната информация е информация, чието формализирано представяне води до значителни загуби в адекватността на информационния модел на самата първоначална информация.

Неструктурирана информация е информация, за която в момента няма средства за нейното формализирано представяне с приемливо ниво на адекватност на практика. Средствата за представяне на такава информация трябва да имат високи семантични и експресивни способности. Разработването на такива инструменти в момента върви по линията на създаване на езици за описване на знания и IPL с висока семантична сила.

Методологии за изграждане на информационни системи.

Индустрията за разработване на автоматизирани системи за управление на информация възниква през 50-те - 60-те години на миналия век и до края на века придобива напълно завършени форми.

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

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

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

Според статистиката, съставена от Standish Group (SSL), от 8380 проекта, изследвани от SSL през 1994 г., повече от 30% от проектите с обща стойност над 80 милиарда долара се провалиха. В същото време само 16% от общия брой проекти бяха завършени навреме, а превишаването на разходите възлизаше на 189% от планирания бюджет.

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

Според съвременната методология процесът на създаване на ИС е процес на изграждане и последователна трансформация на редица съгласувани модели на всички етапи от жизнения цикъл на ИС (ЖЦ). На всеки етап от жизнения цикъл се създават специфични модели – организации, изисквания за

IP. IP проект. изисквания за кандидатстване и др. Обикновено се разграничават следните етапи на създаване на ИС: формиране на изисквания към системата, проектиране, внедряване, тестване, въвеждане в експлоатация, експлоатация и поддръжка.

Началният етап от процеса на създаване на ИС е моделирането на бизнес процеси, протичащи в организацията и реализиращи целите на задачата. Моделът на организацията, описан от гледна точка на бизнес процесите на бизнес функциите, ви позволява да формулирате основните изисквания за IS.

Дизайнът на IS се основава на моделиране на домейни. За да се получи адекватен на предметната област проект на ИС под формата на система от правилно работещи програми, е необходимо да има цялостно, системно представяне на модела, което отразява всички аспекти на функционирането на бъдещата информационна система. В този случай под модел на домейн се разбира определена система, която имитира структурата или функционирането на изследвания домейн и отговаря на основното изискване – да бъде адекватна на този домейн.

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

Към моделите на домейни са наложени следните изисквания:

Формализиране, предоставящо недвусмислено описание на структурата на предметната област;

Разбираемост за клиенти и разработчици на базата на използването на графични средства за изобразяване на модела;

Реализуемост, предполагаща наличие на средства за физическа реализация на модела на домейна и ИС;

Предоставяне на оценка на ефективността от прилагането на модела на домейна въз основа на определени методи и изчислени показатели.

Функционално моделиране IDEF0: основни дефиниции и разпоредби.

Програмата за интегрирана компютъризация на производството ICAM (ICAM - Integrated Computer Aided Manufacturing) е насочена към повишаване на ефективността на промишлените предприятия чрез широкото въвеждане на компютърни (информационни) технологии. В Съединените щати това обстоятелство е осъзнато още в края на 70-те години, когато американските военновъздушни сили предлагат и прилагат

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

IDEF0 се използва за създаване на функционален модел, който показва структурата и функциите на системата, както и потоците от информация и материални обекти, свързващи тези функции.

IDEF1 се използва за изграждане на информационен модел, който показва структурата и съдържанието на информационните потоци, необходими за поддържане на функциите на системата;

IDEF2 ви позволява да изградите динамичен модел на променящото се във времето поведение на функциите, информацията и системните ресурси.

Досега най-разпространените и прилагани методологии са IDEF0 и IDEF1 (IDEF1X), които са получили статут на федерални стандарти в Съединените щати. Методологията IDEF0, чиито характеристики и приложение са описани в това ръководство (GD), се основава на подхода, разработен от Дъглас Т. Рос в началото на 70-те години и наречен SADT (Structured Analysis & Design Technique – метод за структурен анализ и дизайн). Основата на подхода и като следствие на методологията IDEF0 е графичен език за описание (моделиране) на системи, който има следните свойства.

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

Методологията на анализа на структурните системи значително помага при решаването на подобни проблеми.

Структурният анализ обикновено се нарича метод за изследване на система, който започва с общия й преглед и след това я детайлизира, придобивайки йерархична структура с нарастващ брой нива. Такива методи се характеризират с: разделяне на нива на абстракция с ограничен брой елементи (от 3 до 7); ограничен контекст, включващ само съществените детайли на всяко ниво; използване на строги официални правила за записване; последователно приближаване към резултата.

Нека дефинираме ключовите понятия на структурния анализ на предприятието (организацията).

Операцията е елементарно (неделимо) действие, извършвано на едно работно място.

Функция - набор от операции, групирани по определен критерий.

Бизнес процесът е свързан набор от функции, в хода на които се изразходват определени ресурси и продукт (обект, услуга, научен

откритие, идея), което е от стойност за потребителя.

Подпроцесът е бизнес процес, който е структурен елемент на някакъв бизнес процес и представлява стойност за потребителя.

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

Описването на система с помощта на IDEF0 се нарича функционален модел. Функционалният модел е предназначен да описва съществуващи бизнес процеси, който използва както естествени, така и графични езици. За да се предаде информация за конкретна система, източникът на графичния език е самата методология IDEF0.

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

Среда на инструментите BPwin.

Моделирането на бизнес процеси обикновено се извършва с помощта на инструменти за случаи. Тези инструменти включват BPwin (технология PLATINUM), Silverrun (технология Silverrun), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функционалността на инструментите за структурно моделиране на бизнес процеси ще бъде обсъдена с помощта на примера на BPwin казус инструмент.

BPwin поддържа три методологии за моделиране: функционално моделиране (IDEF0); описание на бизнес процеси (IDEF3); диаграми на потока от данни (DFD). BPwin има доста прост и интуитивен потребителски интерфейс. Когато стартирате BPwin, по подразбиране се появява основната лента с инструменти, палитрата с инструменти (чийто външен вид зависи от избраната нотация) и отляво навигаторът на модела - Model Explorer).

При създаване на нов модел се появява диалогов прозорец, в който трябва да посочите дали моделът ще бъде създаден наново или ще бъде отворен от файл или от хранилището на ModelMart, след което въведете името на модела и изберете методологията, в която моделът ще бъде построен.

Както беше посочено по-горе, BPwin поддържа три методологии - IDEF0, IDEF3 и DFD, всяка от които решава свои специфични проблеми. В BPwin е възможно да се изграждат смесени модели, тоест моделът може да съдържа едновременно IDEF0 и IDEF3 и DFD диаграми. Съставът на палитрата с инструменти се променя автоматично при превключване от една нотация към друга.

Моделът на BPwin се разглежда като колекция от дейности, всяка от които оперира с набор от данни. Работата е изобразена като правоъгълници, данните като стрелки. Ако щракнете върху който и да е обект от модела с левия бутон на мишката, се появява контекстно меню, всеки елемент от което съответства на редактора на свойство на обекта.

В началните етапи на създаване на IP е необходимо да се разбере как работи организацията, която ще бъде автоматизирана. Мениджърът познава работата като цяло добре, но не е в състояние да се задълбочи в детайлите на работата на всеки обикновен служител. Един обикновен служител знае добре какво се случва на работното му място, но може да не знае как работят колегите. Следователно, за да се опише работата на едно предприятие, е необходимо да се изгради модел, който да е адекватен на предметната област и да съдържа знанията на всички участници в бизнес процесите на организацията.

Най-удобният език за моделиране на бизнес процеси е IDEF0, където системата е представена като набор от взаимодействащи дейности или функции. Тази чисто функционална ориентация е фундаментална – функциите на системата се анализират независимо от обектите, с които оперират. Това ви позволява по-ясно да моделирате логиката и взаимодействието на процесите на организацията.

Процесът на моделиране на система в IDEF0 започва със създаването на контекстна диаграма, диаграма на най-абстрактното ниво на описанието на системата като цяло, съдържаща дефиницията на предмета на моделиране, целта и гледната точка на Моделът.

Дейностите се отнасят до наименувани процеси, функции или задачи, които възникват с течение на времето и имат разпознаваеми резултати.

Произведенията са изобразени като правоъгълници. Цялата работа трябва да бъде наименувана и дефинирана. Името на работата трябва да бъде изразено с глаголно съществително, обозначаващо действие (например "Дейност на компанията", "Приемане на поръчка" и т.н.). Работата „Дейности на компанията“ може да има например следното определение: „Това е модел на обучение, описващ дейностите на компанията“. При създаване на нов модел (меню Файл / Нов) автоматично се създава контекстна диаграма с едно произведение, изобразяващо системата като цяло.

Стрелките описват взаимодействието на работните места и представляват някакъв вид информация, изразена в съществителни (например „Обаждания от клиенти“, „Правила и процедури“, „Счетоводна система“.)

Учебник за университети

2-ро изд., Rev. и добавете.

2014 Г.

Тираж 1000 екземпляра.

Формат 60x90 / 16 (145x215 mm)

Изпълнение: меки корици

ISBN 978-5-9912-0193-3

BBK 32.882

УДК 621.395

Гриф УМО
Препоръчва се от UMO за обучение в областта на телекомуникациите като учебник за студенти от висши учебни заведения, обучаващи се в специалностите „Мрежи и комутационни системи“, „Многоканални телекомуникационни системи“

анотация

Разгледани са алгоритми за моделиране на дискретни и непрекъснати случайни величини и процеси. Изложени са принципите и алгоритмите за моделиране на информационни сигнали, описани от марковски процеси с дискретно и непрекъснато време.Разгледани са принципите на моделиране на системи за опашка. Описани са особеностите на описанието и използването на фрактални и мултифрактални процеси за моделиране на телекомуникационен трафик. Анализирани са методи и примери за моделиране на информационни системи с помощта на специализирани софтуерни пакети Matlab, Opnet, Network simulator.

За студенти, записани в специалностите „Мрежи и комутационни системи“, „Многоканални телекомуникационни системи“, „Информационни системи и технологии“.

Въведение

1 Общи принципи на системно моделиране
1.1. Общи понятия за модел и моделиране
1.2. Класификация на модела
1.3. Структура на модела
1.4. Методологически основи за формализиране на функционирането на сложна система
1.5. Компонентно моделиране
1.6. Етапи на формиране на математически модел
1.7. Симулационно моделиране
Контролни въпроси

2 Общи принципи на изграждане на комуникационни системи и мрежи
2.1. Концепцията за изграждане на комуникационни системи и мрежи
2.2. Многослойни мрежови модели
2.2.1. Тристепенен модел
2.2.2. Архитектура на TCP/IP протокола
2.2.3. Референтен модел на OSI
2.3. Структура на комуникационната мрежа
2.3.1. Глобални мрежи
2.3.2. Локални мрежи
2.3.3. Топологии на компютърни мрежи
2.3.4. Локални Ethernet мрежи
2.4. Frame Relay мрежи
2.5. IP телефония
Контролни въпроси

3 Симулация на произволни числа
3.1. Разбиране на произволни числа
3.2. Програмни методи за генериране на равномерно разпределени случайни числа
3.3. Формиране на случайни величини с даден закон на разпределение
3.3.1. Метод на обратна функция
3.3.2. Приблизителни методи за преобразуване на произволни числа
3.3.3. Метод на скрининг (метод за генериране на Нойман)
3.4. Методи, базирани на централната пределна теорема
3.5. Алгоритми за моделиране на често използвани произволни променливи
3.6. Алгоритми за моделиране на корелирани случайни променливи
3.7. Формиране на реализации на случайни вектори и функции
3.7.1. Моделиране на n-мерна произволна точка с независими координати
3.7.2. Формиране на случаен вектор (в рамките на теорията на корелацията)
3.7.3. Формиране на реализации на произволни функции

4 Моделиране на дискретни разпределения
4.1. Разпределение на Бернули
4.2. Биномиално разпределение
4.3. Поасоново разпределение
4.4. Симулация на опити в схемата на случайни събития
4.4.1. Симулация на случайни събития
4.4.2. Моделиране на противоположни събития
4.4.3. Моделиране на дискретна случайна променлива
4.4.4. Моделиране на пълна група от събития
4.5. Потоци от събития
4.6. Обработка на резултатите от симулацията
4.6.1. Прецизност и брой реализации
4.6.2. Първична обработка на статистически данни
Контролни въпроси

5 Алгоритми за моделиране на стохастични сигнали и смущения в комуникационни системи
5.1. Алгоритъм за моделиране на нестационарни случайни процеси
5.2. Алгоритми за моделиране на стационарни случайни процеси
5.3. Методи за моделиране на сигнали и шум под формата на стохастични диференциални уравнения
5.4. Примери за модели на стохастични процеси в комуникационните системи
5.4.1. Модели на информационни процеси
5.4.2. Модели на смущения
5.4.3. Характеристики на основните видове смущения
Контролни въпроси

6 Марков стохастични процеси и тяхното моделиране
6.1. Основни понятия за стохастичен процес на Марков
6.2. Основни свойства на дискретни марковски вериги
6.3. Непрекъснати вериги на Марков
6.3.1. Основни понятия
6.3.2. Полумарковски процеси
6.3.3. Смърт и репродуктивни процеси
6.4. Модели на произволни процеси на Марков с непрекъсната стойност, базирани на стохастични диференциални уравнения
6.5. Моделиране на марковски стохастични процеси
6.5.1. Моделиране на дискретни процеси
6.5.2. Моделиране на скаларни непрекъснати процеси
6.5.3. Моделиране на векторни процеси с непрекъсната стойност
6.5.4. Моделиране на гаусов процес с дробно-рационална спектрална плътност
6.5.5. Моделиране на многократно свързани последователности
6.5.6. Моделиране на процеси на Марков с помощта на оформящи филтри
6.5.7. Алгоритъм за статистическо моделиране на марковски вериги
Контролни въпроси

7 Примери за модели на Марков
7.1. Марковски модели на речевия диалог на абонатите
7.1.1. Речови състояния
7.1.2. Диалогови модели
7.2. Марковски модели на речеви монолог
7.3. Управляван от Марков процес на Поасон в речевите модели
7.4. Марковски модели на цифрови последователности на изхода на кодека G.728
7.5. Статистическо мултиплексиране на източника на речеви пакети с отчитане на модела на Марков за телефонен диалог
7.6. Марков модел на безжичен канал с ARQ/FEC механизъм
7.7. Грешки при пакетиране
7.8. Изчисляване на характеристиките на потока от грешки по параметри на модела
7.8.1. Оценяване на параметрите на потока от грешки
7.8.2. Оценка на адекватността на модела на потока от грешки
7.9. Марков модели за оценка на QoS на мултимедийни услуги в реално време в Интернет
7.9.1. Концепция за мултимедийни услуги в реално време
7.9.2. Анализ и моделиране на закъснения и загуби
7.10. Модели на потоци от мултимедиен трафик
Контролни въпроси

8 Системи за опашка и тяхното моделиране
8.1. Обща характеристика на системите за опашка
8.2. Структура на системата за опашка
8.3. Системи за опашка с изчакване
8.3.1. Сервизна система M / M / 1
8.3.2. Сервизна система M / G / 1
8.3.3. Мрежи с голям брой възли, свързани чрез комуникационни канали
8.3.4. Приоритетно обслужване
8.3.5. Сервизна система M / M / N / m
8.4. Системи за опашка за отказ
8.5. Общи принципи на моделиране на системи за опашка
8.5.1. Метод на статистически тест
8.5.2. Блокови модели на процесите на функциониране на системите
8.5.3. Характеристики на моделирането с помощта на Q-вериги
Контролни въпроси

9 Моделиране на информационни системи с помощта на типични технически средства
9.1. Системно моделиране и езици за програмиране
9.2. Разбиране на езика на GPSS
9.2.1. Динамични обекти GPSS. Ориентирани към транзакции блокове (оператори)
9.2.2. Хардуерно ориентирани блокове (оператори)
9.2.3. Многоканална услуга
9.2.4. GPSS статистически блокове
9.2.5. Операционни единици GPSS
9.2.6. Други GPSS блокове
9.3. Симулация на ETHERNET мрежата в GPSS среда
Контролни въпроси

10 Моделиране на системи за предаване на информация
10.1. Типична система за предаване на данни
10.2. Имунитет на предаване на дискретни сигнали. Оптимално приемане
10.3. Оценка на вероятността от погрешно приемане на дискретни сигнали с напълно известни параметри
10.4. Имунитет на дискретни сигнали със случайни параметри
10.5. Имунитет на дискретни сигнали с некохерентно приемане
10.6. Имунитет на дискретни сигнали със случайни съществени параметри
10.7. Алгоритми за формиране на дискретни сигнали
10.8. Алгоритъм за оформяне на шума
10.9. Алгоритъм за демодулиране на дискретни сигнали
10.10. Структурата на имитационния комплекс и неговите подпрограми
10.11. Софтуерна среда Mathworks Matlab и пакет за визуално моделиране Simulink
10.11.1. Техническо описание и интерфейс
10.11.2. Пакет за визуална симулация Simulink
10.11.3. Създаване и маскиране на подсистема
10.11.4. Пакет с разширения Communications Toolbox
10.12. Моделиране на блоковете на системата за предаване на данни WiMAX
10.12.1. Симулация на предавател
10.12.2. Моделиране на предавателен канал
10.12.3. Симулация на приемник
10.12.4. Внедряване на модела в системата Mathlab
10.13. Резултати от симулацията на WiMAX системата
Контролни въпроси

11 Самоподобни процеси и тяхното приложение в телекомуникациите
11.1. Основи на теорията на фракталните процеси
11.2. Мултифрактални процеси
11.3. Оценка на степента на Хърст
11.4. Мултифрактален анализ с помощта на софтуер
11.4.1. Описание на софтуера
11.4.2. Примери за оценка на степента на самоподобие
11.5. Алгоритми и софтуер за мултифрактален анализ
11.6. Влияние на самоподобието на трафика върху характеристиките на обслужващата система
11.7. Методи за моделиране на самоподобни процеси в телевизионния трафик
11.8. Изследване на самоподобната структура на Ethernet трафика
11.9. Самоподобен контрол на задръстванията
11.10. Фрактално Брауново движение
11.10.1. RMD алгоритъм за генериране на FBD
11.10.2. Алгоритъм за генериране на SRA FWA
11.12. Фрактален гаусов шум
11.12.1. FFT алгоритъм за FGS синтез
11.12.2. Оценка на резултатите от симулацията
Контролни въпроси

12 Моделиране на телекомуникационен мрежов възел
12.1. Основи на протокола Frame Relay
12.2. Frame Relay Host Design
12.3. Резултати от симулацията на FR рутера с G.728 кодеци на входа
12.4. Влияние на самоподобието на трафика върху QoS
Контролни въпроси

13 Специализирани системи за симулация на компютърни мрежи
13.1. Обща характеристика на специализираните софтуерни пакети за мрежово моделиране
13.2. Общи принципи на моделиране в средата на OPNET Modeler
13.3. Примери за OPNET приложение
13.3.1. Модел за оценка на качеството на услугата
13.3.2. Внедряване на модела на локалната мрежа
Контролни въпроси

14 Симулация с мрежов симулатор 2
14.1. История и архитектура на пакета NS2
14.2. Създайте обект на симулатор
14.3. Създаване на топология на мрежата
14.4. Задаване на параметри на генератора
14.4.1. Експоненциално вкл./изкл
14.4.2. Парето Вкл./Изкл
14.5. Два основни алгоритма за опашка
14.6. Адаптивно маршрутизиране в NS2
14.6.1. API на потребителско ниво
14.6.2. Вътрешна архитектура
14.6.3. Разширения към други класове
14.6.4. недостатъци
14.6.5. Списък с команди, използвани за симулиране на динамични скриптове в NS2
14.6.6. Пример за динамично маршрутизиране в NS2
14.7. Изпълнение на скриптовата програма в NS2
14.8. Процедура за обработка на резултатите от симулацията
14.9. Пример за моделиране на безжична мрежа
14.10. Пример за симулация на качеството на предаване на поточно видео с помощта на пакета NS 2
14.10.1. Структурата на хардуерния и софтуерния комплекс за оценка на качеството на поточно видео
14.10.2. Функционални модули PAK
14.10.3. Оценка на качеството на видеото