Модель роботи інформаційно-довідковох системи для відділу кадрів банківської організації

Размещено на http://www.allbest.ru/

Курсова робота

Тема роботи “ Розробити модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”

студентки групи КС-102 Троцан Є.О.

ЗМІСТ

Введення

1. Уніфікована мова моделювання UML

2. Змістовий огляд предметної області. Основні вимоги до системи

3. Розробка моделі програмної системи засобами

3.1 Вид з погляду прецедентів

3.2 Вид з погляду проектування

3.3 Вид з погляду реалізації

Висновок

Список використаних джерел

ВВЕДЕННЯ

Для скорочення часу, затрачуваного на багаторазово повторювані процедури, існують різні варіанти рішень, одне йз яких - автоматизація бізнес- процесів. За останніх кілька років вона значно вплинула на організацію сучасного бізнесу. Область застосування автоматизації настільки велика, що охоплює майже все бізнес- процеси сучасного підприємства.

Сьогодні більшість сучасних підприємств, серед яких значна частина підприємств ринку нерухомості, використовують програми автоматизації бізнес- процесів для виконання таких важливих завдань, як: підвищення ефективності й безпеки виробничого процесу, поліпшення якості регулювання, підвищення якості керування компанією й т.і.

"Немає нічого неможливого", - таким виреченням можна охарактеризувати функціональність програм автоматизації. Функції цих програм: створення єдиного інформаційного простору агентства нерухомості, внесення, пошук, сортування об'єктів нерухомості, у тому числі й по декількох параметрах, обробка й аналіз інформації, багатокористувальницька робота з базою даних, робота з фотознімками, міжофісний обмін даними, створення звітної документації й т.і. І це ще не всі, функції, як правило, визначаються завданнями підприємства.

Умовно програми автоматизації можна розділити на дві групи. Перша - це готові програми, які удосталь представлені на ринку. В основному вони покликані виконувати стандартні операції й за рахунок цього мають досить невисоку ціну. Як правило, вони продаються як "коробкові" продукти й, отже, у більшості варіантів не припускають подальшої підтримки розроблювачем.

У цей час існує безліч засобів моделювання інформаційних систем і підходів, що лежать у їхній основі. Кожний підхід припускає деяку нотацію опису предметної області в тих або інших термінах.

В Україні для моделювання й аналізу інформаційних систем досить широко використовуються наступні засоби моделювання:Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) і AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer.

BPWin і ERWin компанії Соmputer Associates. Computer Associates International, Inc. (CA) входить у п'ятірку провідних виробників програмного забезпечення, пропонуючи засобу моделювання, резервного копіювання, керування інфраструктурою підприємства (мережами, серверами й т.д.), інформаційної безпеки, business intelligence і т.д. Пакет BPWin заснований на методології IDEF і призначений для функціонального моделювання й аналізу діяльності підприємства. Методологія IDEF, що є офіційним федеральним стандартом США, являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі об'єкта якої-небудь предметної області. Функціональна модель IDEF відображає функціональну структуру об'єкта.

BPwin підтримує відразу три стандартні нотації - IDEF0 (функціональне моделювання), DFD (моделювання потоків даних) і IDEF3 (моделювання потоків робіт). Ці три основних ракурси дозволяють описувати предметну область найбільше комплексно.

Пакет ERWin цей засіб концептуального моделювання БД. Використовується при моделюванні й створенні баз даних довільної складності на основі діаграм "сутність - зв'язок". У цей час ERWin є найбільш популярним пакетом моделювання даних завдяки підтримці широкого спектра СУБД всіляких класів.

Oracle Designer компанії Oracle. Набір інструментальних засобів Oracle Designer пропонує інтегроване рішення для розробки прикладних систем корпоративного рівня для Web і клієнт/серверних додатків. Oracle Designer бере участь у кожній фазі життєвого циклу розробки програмного забезпечення - від моделювання бізнес-процесів до впровадження. Застосування єдиного репозиторія, уможливлює використання будь-яких його компонентів для швидкої розробки надобідь, крос-платформных розподілених додатків. Засоби концептуального моделювання Oracle Designer містять у собі:

ь ER-діаграми (діаграми інформаційної структури предметної області, що представляється у вигляді об'єктів і їхніх взаємозв'язків);

ь діаграми функціональної ієрархії, що описують функції, які виконує система;

ь діаграми потоків даних, що циркулюють на підприємстві.

Такі моделі представляють інформаційні потреби в зручному й наочному для сприйняття виді, що робить їхнім гарним засобом комунікації між проектувальниками й користувачами в процесі уточнення постановки завдань. Oгасlе Designer автоматично створює звіти, які містять всю інформацію про проект і можуть бути використані як набір документів, що відбивають поточний стан проекту.

Rational Rose компанії IBM. IBM Rational Rose - входить до складу пакета IBM Rational Suite і призначений насамперед для моделювання програмних систем з використанням широкого кола інструментальних засобів і платформ. Rational Rose є одним із провідних систем візуального моделювання об'єктно-ориентированных систем у програмній індустрії, завдяки повноцінній підтримці мови UML (Уніфікована мова моделювання) і багатомовній підтримці командної розробки.

Система повністю підтримує компонентно-компонентно-орієнтований процес створення інформаційних систем. Будь-які учасники проекту - аналітики, фахівці з моделювання, розроблювачі й інші можуть використовувати моделі, побудовані в Rational Rose, для більшої ефективності створення кінцевого продукту. Будь-які моделі, створювані за допомогою мови UML, є взаємозалежними: бізнес-модель, функціональна модель, модель аналізу, модель проектування, модель бази даних, модель компонентів і модель фізичного розгортання системи.

Існують розширення Rational Rose, які дозволяють виконувати кістякову (round-trip) розробку ІС, створюваних на базі мов C/C++, Java, Smalltalk, Ada, Object Pascal (Borland Delphi) і ін.

Таким чином, можна згенерувати каркас програмного коду на кожній із зазначених мов або виконати процедуру зворотного проектування, що дозволяє сформувати модель на базі існуючого коду. Інтеграція Rational Rose з Rational TestManager дозволяє створювати сценарії тестування на базі візуальної моделі. Інтеграція Rational Rose з Rational ClearCase дозволяє поставити на версійний контроль модель цілком або почастям. Інтеграція Rational Rose з Rational SoDA дозволяє автоматизувати процес створення документів і звітів по візуальній моделі.

PowerDesigner компанії Sybase. Компанія Sybase від дня своєї підстави традиційно є провідним постачальником інформаційних технологій на світовий ринок фінансових інститутів. PowerDesigner є комплексним рішенням для моделювання й розробки додатків і бізнес-процесів для організацій, які мають потребу у швидкому, послідовному й ефективному з погляду витрат створенні або реінжинірингу бізнесів-додатків. Остання версія продукту, PowerDesigner, має нові можливості по моделюванню бізнес-процесів, об'єктному моделюванню, що базується на UML, і підтримує як традиційні, так і знову, що з'являються технології, моделювання в рамках одного розвитий графічного середовища. ARIS компанії IDS Scheer AG. У цей час спостерігається тенденція інтеграції різноманітних методів моделювання й аналізу систем, що проявляється у формі створення інтегрованих засобів моделювання. Одним з таких засобів є продукт, що носить назву ARIS, розроблений німецькою фірмою IDS Scheer. Основний напрямок - програмне забезпечення й консалтинг. Система ARIS являє собою комплекс засобів аналізу й моделювання діяльності підприємства. Її методичну основу становить сукупність різних методів моделювання, що відбивають різні погляди на досліджувану систему. Та сама модель може розроблятися з використанням декількох методів, що дозволяє використовувати ARIS фахівцям з різними теоретичними знаннями й набудовувати його на роботу із системами, що мають свою специфіку.

Методика моделювання ARIS ґрунтується на розробленої професором Августом Шером теорії побудови інтегрованих ІС, що визначає принципи візуального відображення всіх аспектів функціонування аналізованих компаній. ARIS підтримує чотири типи моделей, що відбивають різні аспекти досліджуваної системи:

ь організаційні моделі, що представляють структуру системи - ієрархію організаційних підрозділів, посад і конкретних осіб, зв'язку між ними, а також територіальну прив'язку структурних підрозділів;

ь функціональні моделі, що містять ієрархію цілей, що коштують перед апаратом керування, із сукупністю дерев функцій, необхідних для досягнення поставлених цілей;

ь інформаційні моделі, що відбивають структуру інформації, необхідної для реалізації всієї сукупності функцій системи;

ь моделі керування, що представляють комплексний погляд на реалізацію бізнес-процесів у рамках системи.

Для побудови перерахованих типів моделей використовуються як власні методи моделювання ARIS, так і різні відомі методи й мови моделювання, зокрема, ER і UML. У процесі моделювання кожний аспект діяльності підприємства спочатку розглядається окремо, а після детального пророблення всіх аспектів будується інтегрована модель, що відбиває всі зв'язки між різними аспектами. ARIS не накладає обмежень на послідовність побудови зазначених вище типів моделей.

Кожний з розглянутих продуктів досить універсальний але має переважне призначення:

ь для моделювання баз даних більше підходять інструменти Erwin, Power Designer і Rational Rose;

ь для моделювання компонентів розроблювальних додатків більше підходять Oracle Designer, Power Designer і Rational Rose;

ь для моделювання бізнес-процесів більше підходять BPwin, ARIS і Rational Rose.

Таким чином, засіб Rational Rose, і відповідно, мова UML будучи універсальним засобом моделювання дозволяє вирішити всі типові завдання моделювання інформаційних систем.

Таблиця 1. - Порівняльна таблица Case засобів моделювання

Найменування	Виробник	Платформа	Мови генерації коду	Мови зворотного інжинірингу
Sybase Power Designer	Sybase	Windows	С#, C++, Java, PowerBuilder, VisualBasic	Java, PowerBuilder, VisualBasic
Erwin	Erwin	Windows	-	-
MS Visio	Microsoft	Windows	-	-
Dia	Alexander Larsson/GNOME Office	GTK+ (cross-platform)	-	-
Smart Draw	Smartdraw	Windows	-	-
Enterprise Architect	Sparx Systems	Windows	C++, Java, C#, VB, VB.Net, Visual Basic , Delphi, PHP, Python	C++, Java, C#, VB, VB.Net, Visual Basic , Delphi, PHP, Python
Umbrello	Umbrello Team	Unix, Linux	C++, Java, C#, PHP, JavaScript, ActionScript, SQL, Pascal, Ada, Python, IDL, XML Schema, Perl	C++, IDL, Pascal/Delphi, Ada, Python, Java, Perl
ArgoUML	tigris.org	Java (cross-platform)	-	-
UModel	Altova	Windows	Java 1.4, Java 5.0, Java 6.0, C# 1.2, C# 2.0, C# 3.0, VB 7.1, VB8.0 и VB 9.0	C#, VB.NET и Java
Rational Rose	Rational Software Corporation	Windows, Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX)	C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro	C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro
Visual Paradigm	Visual Paradigm	Linux, Mac OS X, Windows	C#, VB .NET, Object Definition Language (ODL), Flash ActionScript, Delphi, Perl, Objective-C, Ruby	Java, C++, CORBA IDL, PHP, XML Schema, Ada, Python ,Java class, .NET dll и exe, JDBC
QReal	Кафедра системного програмування СПбГУ	Linux, Mac OS, Windows	C#, .NET	-

1. УНІФІКОВАНА МОВА МОДЕЛЮВАННЯ UML

• Раціональна розробка інформаційної системи припускає глибоке попереднє аналітичне пророблення. Насамперед, необхідно окреслити коло завдань, виконуваних розроблювальною системою, потім, розробити модель системи, і нарешті, визначити способи реалізації. Глибоке пророблення архітектури розроблювальній інформаційній системі на початкових етапах проектування, як правило, окупається в наслідку, особливо при розробці великомасштабних проектів із тривалим супроводом.
• Засоби мови моделювання UML (Unified Model Language, - уніфікована мова програмування ) дозволяють виразно й досить легко зробити попередню концептуальну розробку інформаційної системи, і при цьому, методично супроводжувати весь хід розробки включаючи й весь подальший життєвий цикл розроблювальної інформаційної системи як програмного продукту.
• UML - це мова для візуалізації, спецификування, конструювання й документування артефактів програмних систем, заснований на об'єктно-ориентированом підході.
• UML, як і будь-яка інша мова, складається зі словника й правил, що дозволяють комбінувати вхідні в нього слова й одержувати осмислені конструкції. У мові моделювання словник і правила орієнтовані на концептуальне й фізичне подання інформаційних систем. Моделювання необхідно для розуміння системи. При цьому єдиній моделі ніколи не буває досить. Навпроти, для розуміння будь-якої нетривіальної системи доводиться розробляти велика кількість взаємозалежних моделей. У застосуванні до програмних систем це означає, що необхідна мова, за допомогою якого можна з різних точок зору описати подання архітектури системи протягом циклу її розробки.
• UML - це мова візуалізації, при цьому UML - це не просто набір графічних символів. За кожним з них стоїть добре певна семантика. Таким чином, модель, написана одним розроблювачем, може бути однозначно інтерпретована іншим або навіть інструментальною програмою.
• UML - це мова спецификування. У даному контексті специфицирование означає побудова точних, недвозначних і повних моделей. UML дозволяє специфицировать всі істотні рішення, що стосуються аналізу, проектування й реалізації, які повинні прийматися в процесі розробки й розгортання системи програмного забезпечення.
• UML - це мова конструювання. Хоча UML не є мовою візуального програмування, моделі, створені з його допомогою, можуть бути безпосередньо переведені на різні конкретні мови програмування. Іншими словами, UML-Модель можна відобразити на такі мови, як Java, C++, Visual Basic, і навіть на таблиці реляційной бази даних або стійкі об'єкти об'єктно-ориентированой бази даних. Ті поняття, які переважно передавати графічно, так і представляються в UML; ті ж, які краще описувати в текстовому виді, виражаються за допомогою мови програмування.
• Подібне відображення моделі на мову програмування дозволяє здійснювати пряме проектування: генерацію коду з моделі UML у якусь конкретну мову. Можна вирішити й обратну задачу: відновити модель по наявній реалізації. Природно, модель і реалізація припускає використання ряду специфічних сутностей. Тому для зворотного проектування необхідні як інструментальні засоби, так і втручання людини. Сполучення прямої генерації коду й зворотного проектування дозволяє працювати як у графічному, так і в текстовому поданні, якщо інструментальні програми забезпечують погодженість між обома поданнями.
• Крім прямого відображення в мови програмування, UML у силу своєї виразності й однозначності дозволяє безпосередньо виконувати моделі, імітувати поводження систем і контролювати діючі системи.
• UML - це мова документування. Компанія, що випускає програмні засоби, крім коду, що виконується, робить і інші документи, у тому числі:
• - вимоги до системи;
• - архітектуру;
• - проект;
• - вихідний код;
• - проектні плани;
• - тести;
• - прототипи;
• - версії, і ін.
• Залежно від прийнятої методики розробки виконання одних робіт виробляється більш формально, інших менш. Згадані документи - це не просто складені частини, що поставляються, проекту; вони необхідні для керування, для оцінки результату, а також як засіб спілкування між членами колективу під час розробки системи й після її розгортання.
• UML пропонує розроблювачеві й керівництву свій варіант рішення проблеми документування системної архітектури й всіх її деталей, пропонує мова для формулювання вимог до системи й визначення тестів і, нарешті, надає кошти для моделювання робіт на етапі планування проекту й керування версіями.

2. ЗМІСТОВИЙ ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ. ОСНОВНІ ВИМОГИ ДО СИСТЕМИ

Бамнк (від італ. banco -- лава) -- кредитно-фінансова установа, яка здійснює грошові розрахунки, акумулює грошові кошти та інші цінності, надає кредити та здійснює послуги за фінансовими операціями.

Банківська система в ринковій економіці є звичайно дворівневою і включає центральний банк (емісійний) і комерційні (депозитні) банки різних видів. Основними функціями комерційних банків вважаються залучення внесків (депозитів) і надання кредитів. За допомогою цих операцій комерційні банки можуть створювати гроші, тобто розширювати грошову пропозицію, що відрізняє їх від інших фінансових установ. Банки займаються також купівлею і продажем цінних паперів.

Кредитно-банківська система як сукупність кредитно-фінансових інститутів акумулює вільні грошові капітали, доходи і заощадження різних прошарків населення і надає їх у позичку фірмам, уряду і приватним особам. Кредитно-банківські інститути підрозділяються на:

1) Центральний банк;

2) комерційні банки;

3) спеціалізовані кредитно-фінансові інститути.

Центральний банк (Національний банк України - НБУ) - це банк для уряду і банкірів. Він здійснює одну основну функцію - контроль за грошовою масою і кредитом в економіці. Він займає в кредитно-банківській системі особливе місце і є, як правило, державною установою.

До основних функцій центрального банку відносяться:

1. Емісійна функція (випуск грошей), що зберігає своє значення, оскільки готівка, як і раніше, необхідна для значної частини платежів і забезпечення ліквідності кредитної системи, що повинна мати засоби остаточного погашення боргових зобов'язань.

2. Функція акумулювання і збереження касових резервів для комерційних банків, тобто кожен банк - член національної кредитної системи - зобов'язаний зберігати на резервному рахунку в НБУ суму у певній пропорції до розміру його внесків. Одночасно НБУ за традицією є зберігачем офіційних золотовалютних резервів країни.

3. Функція кредитування комерційних банків. Найменше виявляється в періоди фінансових катастроф.

4. Надання кредитів і виконання розрахункових операцій для урядових органів, тому що в бюджетах різного рівня акумулюється до половини і більш ВВП. Дані засоби накопичуються на рахунках НБУ і витрачаються з них. При цьому, центральні банки ведуть рахунки урядових закладів і організацій. Крім того, вони здійснюють операції з державними цінними паперами, надають державі кредит у формі прямих короткострокових і довгострокових позичок чи покупки державних облігацій. Центральні банки також проводять за дорученням урядових органів операції із золотом і іноземною валютою.

5. Клірингова функція, чи функція проведення безготівкових розрахунків. Так, у ряді країн центральний банк веде операції з загальнонаціонального клірингу, виступаючи посередником між комерційними банками, розташованими в різних районах країни.

Таким чином, центральний банк має певну владу за контролем грошової маси і кредиту. Тільки він може запустити ”паперовий верстат”, або його призупинити. Усі ці дії залежать від економічної ситуації в країні. У цьому суть центральної банківської системи.

Комерційні банки являють собою приватні і державні банки, що здійснюють універсальні операції з кредитування промислових, торгових і інших підприємств головним чином за рахунок тих грошових капіталів, що вони одержують у вигляді внесків. Функції комерційних банків:

· Акумулювання безстрокових депозитів, чи ведення поточних рахунків, і оплата чеків, виписаних на ці банки;

· Надання кредитів підприємцям. Особлива заслуга комерційних банків також полягає в здійсненні розрахунків у масштабах усього національного господарства. На базі їхніх операцій виникають кредитні гроші (чеки, банківські векселі).

Спеціалізовані кредитно-фінансові інститути включають банківські і небанківські організації, що спеціалізуються на певних видах кредитування. Так, зовнішньоторговельні банки спеціалізуються на кредитуванні експорту й імпорту товарів, а іпотечні банки і компанії - на наданні довгострокових позичок під заставу нерухомості (землі і будівель).

До системи кредитно-фінансових інститутів відносяться:

1. Інвестиційні банки, що займаються емісійно-засновницькою діяльністю, тобто провідні операції з випуску і розміщення на фондовому ринку цінних паперів, одержуючи на це доход. Вони не мають право приймати депозити і залучають капітали, як правило, шляхом продажу власних акцій чи за рахунок кредиту комерційних банків. Свій капітал вони використовують для довгострокового кредитування різних галузей господарства.

2. Ощадні установи, які займають важливе місце в кредитній системі завдяки залученню дрібних заощаджень і доходів, що інакше не зможуть функціонувати як капітал.

Існують різні типи ощадних установ:

ощадні банки і каси;

взаємо-ощадні банки (різновид кооперативних банківських установ у США);

довірчо-ощадні банки (у Великобританії);

позичково-ощадні асоціації (США);

кредитні кооперативи (союзи, асоціації) і інші.

3. Страхові компанії, для яких характерна специфічна форма залучення засобів - продаж страхових полісів. Отримані доходи вони вкладають насамперед в облігації й акції інших компаній, державні цінні папери.

4. Пенсійні фонди, що розрізняються за організацією, управлінням і структурою активів. Так, існують застраховані пенсійні фонди (керовані страховими компаніями) і незастраховані (керованими чи підприємствами, чи за їхнім дорученням, банками), фундовані (їхні засоби інвестовані в цінні папери) і нефундовані (пенсії виплачуються з поточних надходжень і доходів) і багато інших.

5. Інвестиційні компанії, що розміщають серед дрібних власників свої зобов'язання (акції) і отримані засоби, які використовують, для покупки цінних паперів народного господарства. Дрібні інвестори охоче купують зобов'язання інвестиційних компаній, тому що через значну диверсифікованість (вкладення засобів у різні підприємства) досягається відоме розосередження активів, знижується небезпека втрати заощаджень через банкрутство фірми, у чиї акції вкладений капітал.

Рисунок 2.1 - Банківська система України



Рисунок 2.2 - Структура інтегрованої банківської системи

3. РОЗРОБКА МОДЕЛІ ПРОГРАМНОЇ СИСТЕМИ ЗАСОБАМИ UML

В UML програми видаються діаграмами. В UML діаграмах представляється загальна архітектура програми або якісь її особливості. Це означає, що в UML-діаграмах створюється тільки модель майбутньої програми. Мова UML є досить високим рівнем абстракції, тому програми, написані на UML, згодом можна реалізувати будь-якою мовою, в якому є достатньо можливостей об'єктно-орієнтованого програмування.

Діаграма - графічне представлення безлічі елементів, найбільш часто зображується як зв'язний граф з вершин (предметів) і дуг (відносин). Діаграми малюються для візуалізації системи з різних точок зору, потім вони відображаються в систему. Зазвичай діаграма дає неповне подання елементів, які складають систему. Хоча один і той же елемент може з'являтися в усіх діаграмах, на практиці він з'являється тільки в деяких діаграмах. Теоретично діаграма може містити будь-яку комбінацію предметів і відносин, на практиці обмежуються малою кількістю комбінацій, які відповідають п'яти уявленням архітектури ПЗ.

UML включає дев'ять видів діаграм:

ь діаграми класів;

ь діаграми об'єктів;

ь діаграми Use Case (діаграми прецедентів);

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

ь діаграми співпраці (кооперації);

ь діаграми схем станів;

ь діаграми діяльності;

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

ь діаграми розміщення (розгортання).

Діаграма класів показує набір класів, інтерфейсів, співробітництв і їх відносин. При моделюванні об'єктно-орієнтованих систем, діаграми класів використовуються найбільш часто. Діаграми класів забезпечують статичне проектне уявлення системи.

Діаграма об'єктів показує набір об'єктів і їх стосунки. Діаграма об'єктів представляє статичний «моментальний знімок» з примірників предметів, які знаходяться в діаграмах класів.

Діаграма Use Case (діаграма прецедентів) показує набір елементів Use Case, акторів та їх відносин. За допомогою діаграм Use Case для системи створюється статичний уявлення Use Case. Ці діаграми особливо важливі при організації та моделюванні поведінки системи, завданні вимог замовника до системи.

Діаграми послідовності і діаграми співпраці - це різновиди діаграм взаємодії.

Діаграма взаємодії показує взаємодію, що включає набір об'єктів і їх відносин, а також пересилаються між об'єктами повідомлення. Діаграми взаємодії забезпечують динамічне представлення системи.

Діаграма послідовності - це діаграма взаємодії, яка виділяє впорядкування повідомлень за часом.

Діаграма співробітництва (діаграма кооперації) - це діаграма взаємодії, яка виділяє структурну організацію об'єктів, що посилають і приймають повідомлення. Діаграми послідовності і діаграми співпраці ізоморфні, що означає, що одну діаграму можна трансформувати в іншу діаграму.

Діаграма схем станів показує кінцевий автомат, представляє стану, переходи, події і дії. Діаграми схем станів забезпечують динамічне представлення системи. Вони особливо важливі при моделюванні поведінки інтерфейсу, класу або співробітництва. Ці діаграми виділяють таку поведінку об'єкта, що управляється подіями, що особливо корисно при моделюванні реактивних систем.

Діаграма діяльності - спеціальна різновид діаграми схем станів, яка показує потік від дії до дії всередині системи. Діаграми діяльності забезпечують динамічне представлення системи. Вони особливо важливі при моделюванні функціональності системи і виділяють потік управління між об'єктами.

Компонентна діаграма показує організацію набору компонентів і залежності між компонентами. Компонентні діаграми забезпечують статичну уявлення реалізації системи. Вони пов'язані з діаграмами класів в тому сенсі, що в компонент зазвичай відображається один або декілька класів, інтерфейсів або кооперацій.

Діаграма розміщення (діаграма розгортання) показує конфігурацію обробних вузлів періоду виконання, а також компоненти, що живуть в них. Діаграми розміщення забезпечують статичну уявлення розміщення системи. Вони пов'язані з компонентними діаграмами в тому сенсі, що вузол зазвичай включає один або декілька компонентів.

моделювання діаграма автоматизація робота

3.1 Розробка виду з погляду прецендентів

Вид з погляду прецендентів включає наступні типи діаграм:

ь діаграмма прецендентів;

ь діаграма діяльності;

ь діаграма станів.

Розглянемо на прикладі предметної області “Розробити модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”, кожну з діаграм більш детально.

Діаграма прецедентів

Діаграми прецедентів представляють собою один з п'яти типів діаграм, що застосовуються в UML для моделювання динамічних аспектів системи. Діаграми прецедентів відіграють основну роль у моделюванні поведінки системи, підсистеми або класу. Кожна з таких діаграм показує безліч прецедентів, акторів і відносини між ними.

Діаграми прецедентів застосовуються для моделювання вигляду системи з точки зору прецедентів (варіантів використання). Найчастіше це передбачає моделювання контексту системи, підсистеми або класу або моделювання вимог, пропонованих до поведінки зазначених елементів.

Діаграмою прецедентів (use case diagram), називається діаграма, на якій показана сукупність прецедентів та акторів, а також відносини між ними. Діаграми прецедентів володіють стандартними властивостями, притаманними будь-якій діаграмі, ім'ям і графічним змістом, який являє собою одну з проекцій моделі. Діаграма прецедентів відрізняється від інших своїм конкретним змістом. Діаграми прецедентів зазвичай включають в себе:

· прецеденти,

· акторів,

· відносини залежності, узагальнення та асоціації, як і всі інші діаграми, вони можуть містити примітки та обмеження.

Прецедент-специфікація послідовностей дій (варіанти послідовностей і помилкові послідовності) в уніфікована мова моделювання (UML), які може здійснювати система, підсистема або клас, взаємодіючи із зовнішніми акторами.

Актор - це роль об'єкта поза системою, який прямо взаємодіє з її частиною - конкретним елементом (елементом Use Case). Розрізняють акторів і користувачів. Користувач - це фізичний об'єкт, який використовує систему. Він може грати кілька ролей і тому може моделюватися кількома акторами. Справедливо і зворотне - актором можуть бути різні користувачі. Елемента Use Case (Прецедент) - опис послідовності дій (чи декількох послідовностей), виконуваних системою в інтересах окремого актора і виробляють видимий для актора результат. У моделі елемент Use Case застосовується для структурування предметів поведінки. Елемент Use Case реалізується кооперацією.

Розробка діаграми варіантів використання

Метою побудови діаграми варіантів використання є виявлення дійових осіб - для кого призначене ПЗ, і які дії воно повинне виконувати. Розробка діаграми робиться в три етапи - виявлення дійових осіб - акторів, виявлення варіантів використання системи і побудова діаграми.

Рисунок 3.1 - Модель роботи банківської установи

Рисунок 3.2 - Діаграма Use Case “ Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”

Діаграма діяльності

Для моделювання процесу виконання операцій в UML використовуються так звані діаграми діяльності. Застосовувана в них графічна нотація багато в чому схожа на нотацію діаграми станів, оскільки на діаграмах діяльності також присутні позначення станів і переходів. Відмінність полягає в семантиці станів, які використовуються для подання не діяльностей, а дій, і у відсутності на переходах сигнатури подій. Кожен стан на діаграмі діяльності відповідає виконанню деякої елементарної операції, а перехід у наступний стан спрацьовує тільки при завершенні цієї, операції в попередньому стані. Графічно діаграма діяльності представляється у формі графа діяльності, вершинами якого є стани дії, а дугами - переходи від одного стану дії до іншого. Таким чином, діаграми діяльності можна вважати окремим випадком діаграм станів. Саме вони дозволяють реалізувати в UML особливості процедурного і синхронного управління, обумовленого завершенням внутрішніх діяльностей і дій. На діаграмі діяльності відображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увагу фіксується на результаті діяльності. Сам же результат може привести до зміни стану системи або повернення деякого значення.

Діаграма діяльності описує деякий алгоритм виконання роботи. Діаграма містить початкові і кінцеві вершини, які позначаються у вигляді повідомлень.

На рисунку 3.3 відображена діаграма діяльності по предметній області: “Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації.



Рисунок 3.3 - Діаграма діяльності “ Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”

Діаграма станів

Кожна діаграма станів в UML описує усі можливі стани одного екземпляра певного класу і можливі послідовності його переходів з одного стану в інший, тобто моделює усі зміни станів об'єкту як його реакцію на зовнішні дії.

Діаграми станів найчастіше використовуються для опису поведінки окремих об'єктів, але також можуть бути застосовані для специфікації функціональності інших компонентів моделей, таких як варіанти використання, актори, підсистеми, операції і методи.

Діаграма станів є графом спеціального виду, який представляє деякий автомат. Вершинами графа є можливі стани автомата, що зображуються відповідними графічними символами, а дуги означають його переходи із стану в стан. Діаграми станів можуть бути вкладені один в одного для детальнішого представлення окремих елементів моделі.

У метамоделі UML автомат є пакетом, в якому визначена безліч понять, необхідних для представлення поведінки модельованій суті у вигляді дискретного простору з кінцевим числом станів і переходів.

Тривалість знаходження системи у будь-якому з можливих станів істотно перевищує час, який витрачається на перехід з одного стану в інший. Передбачається, що в межі час переходу може дорівнювати нулю (якщо додатково не обумовлене інше), тобто зміна станів об'єкту може відбуватися миттєво.

Поведінка автомата моделюється як послідовне переміщення по графові від вершини до вершини з урахуванням орієнтації дуг, що зв'язують їх.

Для автомата повинні виконуватися наступні обов'язкові умови:

ь стан, в який може перейти об'єкт, визначається тільки його поточним станом і не залежить від передісторії;

ь у кожен момент часу автомат може знаходитися тільки в одному зі своїх станів. При цьому, автомат може знаходитися в окремому стані як завгодно довго, якщо не відбувається ніяких подій;

ь час знаходження автомата в тому або іншому стані, а також час досягнення того або іншого стану ніяк не специфікуються;

ь кількість станів автомата має бути кінцевою і усі вони мають бути специфіковані явним чином. Окремі псевдостани можуть не мати специфікацій (початкове і кінцеве стани). В цьому випадку їх призначення і семантика повністю визначаються з контексту моделі і даної діаграми станів;

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

ь автомат не повинен містити конфліктуючих переходів, коли об'єкт одночасно може перейти в два і більше подальші стани (окрім випадку паралельних підавтоматів). У мові UML виключення конфліктів можливе на основі введення сторожових умов.

На рисунку 3.4 відображена діаграма станів по предметній області: “ Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”

Рисунок 3.4 - Діаграма станів “ Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”

Рисунок 3.5 - Діаграма станів “ Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”: робота з класом DataBase

3.2 Вид з погляду проектування

Вид з погляду прецендентів включає наступні типи діаграм:

· діаграмма послідовності;

· діаграма класів;

· діаграма кооперацій.

Розглянемо на прикладі предметної області “Модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”, кожну з діаграм більш детально.

Діаграма класів

Діаграми класів використовуються при моделюванні ПЗ найбільш часто. Вони є однією з форм статичного опису системи з точки зору її проектування, показуючи її структуру. Діаграма класів не відображає динамічну поведінку об'єктів зображених на ній класів. На діаграмах класів показуються класи, інтерфейси і відносини між ними.

Клас - це основний будівельний блок ПЗ. Це поняття присутнє і в ГО мовами програмування, тобто між класами UML та програмними класами є відповідність, що є основою для автоматичної генерації програмних кодів або для виконання реінжинірингу. Кожен клас має назву, атрибути і операції. Клас на діаграмі показується у вигляді прямокутника, розділеного на 3 області. У верхній міститься назва класу, в середній - опис атрибутів (властивостей), у нижній - назви операцій - послуг, що надаються об'єктами цього класу.

Атрибути класу визначають склад і структуру даних, що зберігаються в об'єктах цього класу. Кожен атрибут має ім'я і тип, що визначає, які дані він представляє. При реалізації об'єкта в програмному коді для атрибутів буде виділена пам'ять, необхідна для зберігання всіх атрибутів, і кожен атрибут буде мати конкретне значення в будь-який момент часу роботи програми. Об'єктів одного класу в програмі може бути скільки завгодно багато, всі вони мають однаковий набір атрибутів, описаний в класі, але значення атрибутів у кожного об'єкта свої і можуть змінюватися в ході виконання програми.

Для кожного атрибута класу можна задати видимість (прозорість). Ця характеристика показує, чи доступний атрибут для інших класів. В UML визначено такі рівні видимості атрибутів:

ь відкритий (публічне) - атрибут видно для будь-якого іншого класу (об'єкта);

ь захищений (захищений) - атрибут видно для нащадків даного класу;

ь закритий (приватні) - атрибут не видно зовнішніми класами (об'єктами) і може використовуватися лише об'єктом, його містить.

Клас містить оголошення операцій, що представляють собою визначення запитів, які повинні виконувати об'єкти даного класу. Кожна операція має сигнатуру, що містить ім'я операції, тип значення і список параметрів, який може бути порожнім. Реалізація операції у вигляді процедури - це метод, що належить класу. Для операцій, як і для атрибутів класу, визначено поняття "видимість". Закриті операції є внутрішніми для об'єктів класу і недоступні з інших об'єктів. Решта утворюють інтерфейсну частина класу і є засобом інтеграції класу в ПЗ.

На діаграмах класів зазвичай показуються асоціації та узагальнення (див. попередню статтю). Кожна асоціація несе інформацію про зв'язки між об'єктами всередині ПЗ. Найбільш часто використовуються бінарні асоціації, що зв'язують два класи. Асоціація може мати назву, яку має висловлювати суть відображається зв'язку. Крім назви, асоціація може мати таку характеристику, як множинність. Вона показує, скільки об'єктів кожного класу може брати участь в асоціації. Множинність вказується у кожного кінця асоціації (полюса) і задається конкретним числом або діапазоном чисел. Множинність, зазначена у вигляді зірочки, припускає будь-яку кількість (у тому числі, і нуль).

Асоціація сама може мати властивості класу, тобто, мати атрибути та операції. У цьому випадку вона називається клас-асоціацією і може розглядатися як клас, у якого крім явно зазначених атрибутів і операцій є посилання на обидва пов'язують нею класу. Узагальнення на діаграмах класів використовується, щоб показати зв'язок між класом-батьком і класом-нащадком, а також в тому випадку, коли в системі виявляються декілька класів, що володіють схожим поведінкою.

При створенні діаграм класів часто користуються поняттям "стереотип". Надалі мова піде про стереотипи класів. Стереотип класу - це елемент розширення словника UML який позначає відмітні особливості у використанні класу. Стереотип має назву, яка задається у вигляді текстового рядка. При зображенні класу на діаграмі стереотип показується у верхній частині класу в подвійних кутових дужках. Є чотири стандартних стереотипу класів, для яких передбачені спеціальні графічні зображення.

Стереотип використовується для позначення класів-сутностей (класів даних), стреотіп описує прикордонні класи, які є посередниками між ПЗ і зовнішніми по відношенню до неї сутностями - акторами, що позначаються стереотипом. Нарешті, стереотип описує класи та об'єкти, які управляють взаємодіями. Застосування стереотипів дозволяє, зокрема, змінити вид діаграм класів.

На рисунку 3.6 відображена діаграма класів по предметній області: “Моделювання процесу підбору персоналу”

Рисунок 3.6 - Діаграма класів “ Моделювання процесу підбору персоналу”



Рисунок 3.7 - Діаграма класів “ Моделювання процесу роботи банківської організації”

Діаграма послідовності

Діаграма послідовності - другий різновид діаграм взаємодії. Відображаючи сценарій поведінки в системі, ця діаграма забезпечує більш наочне уявлення порядку передачі повідомлень. Головне призначення цієї діаграми - описати можливі послідовності станів і переходів, які в сукупності характеризують поведінку елемента моделі протягом його життєвого циклу. Діаграма станів представляє динамічну поведінку сутностей, на основі специфікації їх реакції на сприйняття деяких конкретних подій. Для моделювання взаємодії об'єктів в часі в мові UML використовуються діаграми послідовності. У діаграмі послідовності використовують:

ь Об'єкти-на діаграмі послідовності зображаються тільки ті об'єкти, які безпосередньо беруть участь у взаємодії. Ключовим моментом для діаграм послідовності є динаміка взаємодії об'єктів в часі. В UML діаграма послідовності має як би два виміри. Перше зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкта, який бере участь у взаємодії. Крайнім зліва на діаграмі зображується об'єкт, який є ініціатором взаємодії. Правіше зображається інший об'єкт, який безпосередньо взаємодіє з першим. Таким чином, всі об'єкти на діаграмі послідовності утворюють деякий порядок, який визначається черговістю або ступенем активності об'єктів при взаємодії один з одним.

ь Графічно кожен об'єкт зображається прямокутником і розташовується у верхній частині своєї лінії життя. Усередині прямокутника записуються ім'я об'єкту і ім'я класу розділені двокрапкою. При цьому вся запис підкреслюється, що є ознакою об'єкта. Другим виміром діаграми послідовності є вертикальна вісь тимчасова, спрямована зверху вниз. Початковому моменту часу відповідає сама верхня частина діаграми. Взаємодії об'єктів реалізуються за допомогою повідомлень, які надсилаються одними об'єктами іншим. Повідомлення зображуються у вигляді горизонтальних стрілок з ім'ям повідомлення, а їх порядок визначається часом виникнення. Тобто, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше тих, що розташовані нижче. Масштаб на осі часу не вказується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу «раніше-пізніше».

ь Лінія життя об'єкта-зображується пунктирною вертикальною лінією, асоційованою з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінія життя повинна тривати по всій площині діаграми послідовності від самої верхньої її частини до самої нижньої. Окремі об'єкти, виконавши свою роль в системі, можуть бути знищені, щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається в момент його знищення. Для позначення моменту знищення об'єкта в мові UML використовується спеціальний символ у формі латинської букви «X». Об'єкт обов'язково створюється зі своєю лінією життя і, можливо, з фокусом управління.

ь Фокус управління-процесі функціонування об'єктно-орієнтованих систем, одні об'єкти можуть перебувати в активному стані, безпосередньо виконуючи певні дії, або стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, у мові UML застосовується спеціальне поняття, що отримало назву фокуса управління (focus of control). Фокус управління зображується у формі витягнутого вузького прямокутника, верхня сторона якого означає початок отримання фокусу управління об'єкта (початок активності), а його нижня сторона - закінчення фокусу управління (закінчення активності). Прямокутник розташовується нижче позначення відповідного об'єкту і може замінювати його лінію життя, якщо на всьому її протязі він є активним. Періоди активності об'єкта можуть чергуватися з періодами його пасивності або очікування. У цьому випадку у такого об'єкта є декілька фокусів управління.

ь Повідомлення-в UML кожне взаємодія описується сукупністю повідомлень, якими беруть участь у ньому об'єкти обмінюються між собою. Повідомлення являє собою закінчений фрагмент інформації, який відправляється одним об'єктом іншого. Прийом повідомлення ініціює виконання певних дій, спрямованих на вирішення окремого завдання тим об'єктом, якому це повідомлення надіслано. Таким чином, повідомлення не тільки передають деяку інформацію, але і вимагають або припускають виконання очікуваних дій від приймаючого об'єкта. Повідомлення можуть ініціювати виконання операцій об'єктом відповідного класу, а параметри цих операцій передаються разом з повідомленням. На діаграмі послідовності всі повідомлення впорядковані за часом свого виникнення в моделюється системі. У такому контексті кожне повідомлення має напрям від об'єкта, який ініціює і відправляє повідомлення, до об'єкта, який його отримує.

ь Дана діаграма відображає сценарій пов'язаний із оформленням заказу до будівельної компанії. Діаграма містить об'єктів, які беруть участь у взаємодії. Кожен об'єкт позначається прямокутником, седенині пишеться ім'я об'єкту. Кожен об'єкт має лінію життя, яка може закінчитися в будь-який момент, вона позначається пунктирною лінією на діаграмі.

ь

Рисунок 3.8 - Діаграма послідовності для варіанту використання "Формування звіту керівником відділу кадрів банківської установи"

Діаграма кооперацій

Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відносини між об'єктами, які беруть участь у цій взаємодії. Перш за все, на діаграмі кооперації у вигляді прямокутників зображуються беруть участь у взаємодії об'єкти, що містять ім'я об'єкта, його клас і, можливо, значення атрибутів. Далі, як і на діаграмі класів, вказуються асоціації між об'єктами у вигляді різних сполучних ліній. При цьому можна явно вказати імена асоціації і ролей, які відіграють об'єкти в даній асоціації. Додатково можуть бути зображені динамічні зв'язки - потоки повідомлень. Вони представляються також у вигляді сполучних ліній між об'єктами, над якими розташовується стрілка з вказівкою напряму, імені повідомлення і порядкового номера в загальній послідовності ініціалізації повідомлень.

На відміну від діаграми послідовності, на діаграмі кооперації зображаються тільки відносини між об'єктами, що грають певні ролі у взаємодії. На цій діаграмі не вказується час у вигляді окремого вимірювання. Тому послідовність взаємодій і паралельних потоків може бути визначена за допомогою порядкових номерів. Поняття кооперації (collaboration) є одним з фундаментальних понять у мові UML. Воно служить для позначення множини взаємодіючих з певною метою об'єктів в загальному контексті модельованої системи. Мета самої кооперації полягає в тому, щоб специфікувати особливості реалізації окремих найбільш значущих операцій в системі. Кооперація визначає структуру поведінки системи в термінах взаємодії учасників цієї кооперації.

Кооперація може бути представлена ??на двох рівнях:

ь рівні специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії;

ь рівні прикладів - вказує екземпляри і зв'язку, що утворюють окремі ролі в кооперації

На рисунку 3.9 відображена діаграма кооперацій по предметній області: “ формування звіту керівником відділу кадрів банківської установи ”



Рисунок 3.9 - Діаграма кооперацій для варіанту використання " Формування звіту керівником відділу кадрів банківської установи "

3.3 Вид з погляду реалізації

Компонентна діаграма - різновид діаграми реалізації, що моделює фізичні аспекти ОО систем. Вона показує організацію набору компонент і залежності між ними.

Елементами таких діаграм є компоненти і інтерфейси, а також відносини залежності і реалізації.

Компонент - фізична і замінювана частина системи, яка відповідає набору інтерфейсів і забезпечує реалізацію цього набору. Графічно він відображається як прямокутник з вкладками, що зазвичай включає ім'я.

Я показую діаграму реалізації своєї системи у вигляді наборів компонент, за допомогою яких вона буде реалізована.

На рисунку 3.13 відображена діаграма компонентів програми автоматизації процесу роботи відділу кадрів банківської організації.



Рисунок 3.13 - Діаграма компонентів “ Відділ кадрів банківської організації ”

ВИСНОВОК

Головною метою курсової роботи є розробка моделі процесу ведення обліку успішності студентів. Для вирішення цього завдання ми використали CASE - засіб Rational Rose. Побудована модель допоможе деканату повністю автоматизувати облік успішності студентів, працювати швидше і ефективніше і з меншими витратами часу і засобів, чим без використання сучасних технологій. Автоматизовані системи все сильніше впроваджуються в процес освіти. Таким чином, ми маємо усі перспективи переходу на повну автоматизацію різних процесів і повсюдний перехід на досконалі інформаційні технології.

Дана система може бути реалізована за допомогою язика високого рівня С++ або Delphi.

В процесі виконання курсової роботи були розглянуті такі теоретичні питання:

§ існуючі програмні засоби моделювання інформаційних систем : Rational Rose, Oracle Designer, AllFusion Process Modeler, AllFusion ERwin Data Modeler, ARIS, Sybase PowerDesigner;

§ засоби мови моделювання UML;

§ типи діаграм UML; переваги UML; недоліки UML; аналіз предметної області.

Пояснювальна записка так само включає опис наступних видів діаграм:

§ прецедентів;

§ діяльності;

§ станів;

§ класів;

§ послідовності;

§ кооперацій ;

§ компонентів.

Перелічені вище види діаграм, були побудовані в середовищі Rational Rose 2003 Enterprice по предметній області “ Розробити модель роботи інформаційно-довідкової системи для відділу кадрів банківської організації ”.

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

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. І. О. Чмир та ін., Моделювання систем в середовищі UML: посібник для ВНЗ. Черкаси, 2004

2. М. Фаулер, К. Скотт, Основи. Посібник з уніфікованої мови UML. М: Біном, 2000

3. А. Асоненков, Самовчитель з UML. БХВ-Пітер, 2002

4. Орлов З. А., Технології розробки програмного забезпечення: Підручник для вузів. - Спб.: Пітер, 2004г.

5. І. О. Чмир, А. Ф. Верлань, Об'єктно-орієнтоване моделювання. Посібник. , О:НАДУ, 2005

6. Ambler, S. W. The Object Primer. 2^nd ed. Cambrige University Press, 2001. 541 pp;

7. Кьоу Дж., Джеанини М., Объектно-ориентированное программирование. Учебный курс - СПб: "Питер", 2005.- 238 с.

8. http://www.info-system.ru/designing/methodology/uml/theory.html

9. http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl8/gl8.html

10. http://ru.wikipedia.org/wiki/UML

Размещено на Allbest.ru