Главная
Коллекция "Revolution"
Программирование, компьютеры и кибернетика
Моделювання роботи програмного додатку для керування базою даних кар’єрного центру
Моделювання роботи програмного додатку для керування базою даних кар’єрного центру
Класифікація програм автоматизації. Моделювання й аналіз інформаційних систем, засоби їх здійснення. Уніфікована мова моделювання UML, розробка моделі програмної системи її засобами. Розробка виду з погляду прецедентів, проектування та реалізації.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 19.09.2017 |
| Размер файла | 390,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
40
Размещено на http://www.allbest.ru/
Зміст
- Введення
- 1. Змістовий огляд предметної області. Основні вимоги до системи
- 2. Уніфікована мова моделювання UML
- 3. Розробка моделі програмної системи засобами UML
- 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. Змістовий огляд предметної області. Основні вимоги до системи
В умовах глобалізації та інформатизації суспільства на державні підприємства, установи, приватні організації обрушився великий потік інформації. Розвиток обчислювальної техніки, всесвітня мережа Інтернет призвели до глобальних змін у процесах створення, розповсюдження та обміну інформацією. У процесі документообігу на сьогоднішній день неможливо ігнорувати все зростаючий потік документів, ведення електронного документообігу. Це змушує запроваджувати роботу з новими джерелами інформації, удосконалювати нові форми документообігу, розробляти процеси автоматизації документообігу. З огляду на вище зазначені факти дійсності обрана тема є надзвичайно актуальною з точки зору сучасних проблем діловодства та потреб впровадження єдиної системи електронного документообігу з метою автоматизації інформаційно-документного забезпечення діяльності будь-якого підприємства.
Організація й робота з різними документами охоплюють усі процеси, які відносяться до запису (фіксування) на різних носіях та оформлення за встановленими правилами інформації, необхідної для здійснення управлінських функцій. Документування здійснюється як природною мовою (рукописні, машинописні документи), так і штучними мовами з використанням нових носіїв. У роботі розглядається використання комп'ютерної техніки для автоматизації ведення діловодства, зокрема для укомплектування каталогів документів.
Організація роботи з документами - головна задача управління у будь-якому закладі: від офісу невеликого підприємства до державної установи або крупної корпорації.
Сучасний документообіг певного підприємства - це не лише паперові документи, а й змішані системи традиційних та електронних ресурсів. На відміну від традиційних фондів, які створюються повільніше, електронні ресурси створюються значно швидше, і вже сьогодні виникає проблема не їх накопичення, а їх зберігання і спільного використання. Документообіг, архів нового типу - віртуальний каталог, де можна знайти не лише те, що складає фонд даного сховища, але й миттєво отримати інформацію щодо історії певного документу, ознайомитися із його повною версією. Таку можливість дає каталогам Інтернет.
Інтернет - це глобальна система, що об'єднує понад 100 тис. локальних, корпоративних і відомчих мереж, більш 10 млн. комп'ютерів і 200 млн. користувачів. Інформаційні ресурси зберігаються в Інтернеті на WWW-серверах, а програмна продукція на FTP-серверах. Для встановлення місцезнаходження потрібної інформації в Інтернеті створено понад 200 спеціалізованих пошукових серверів, які можна розглядати як каталоги ресурсів глобальних комп'ютерних мереж. В Україні понад 1100 серверів. Це досить велика цифра для України.
Сучасні інформаційні Інтернет-технології розвиваються за двома напрямками:
надання доступу до корпоративних каталогів організацій;
створення інформаційних Web-сайтів.
Згідно положенню, яке працює в Технікумі промислової автоматики, "Кар'єрний центр" є структурним підрозділом Технікуму промислової автоматики Одеської національної академії харчових технологій, що здійснює організаційний, інформаційний та документальний супровід заходів в системі працевлаштування студентів і випускників технікуму.
Головною метою діяльності "Кар'єрного центру" є реалізація взаємовідносин технікуму з підприємствами та установами незалежно від форм власності, іншими зацікавленими організаціями, юридичними та фізичними особами у створенні умов для забезпечення права студентів і випускників на працю, їх працевлаштування та надання випускникам першого робочого місця.
Основними завданнями діяльності "Кар'єрного центру" є:
· сприяння працевлаштуванню студентів і випускників технікуму;
· проведення постійного аналізу попиту і пропозицій на ринку праці фахівців, підготовку яких здійснює технікум;
· налагодження співпраці з державною службою зайнятості населення, підприємствами, установами та організаціями незалежно від форм власності, які можуть бути потенційними роботодавцями для студентів і випускників;
· забезпечення координації дій з центральними та місцевими органами виконавчої влади, службами зайнятості населення, підприємствами, установами та організаціями (роботодавцями) щодо оптимального узгодження реальних потреб ринку праці та ринку освітніх послуг;
· запровадження системи зворотного зв'язку між підприємствами, установами та організаціями (роботодавцями) і ТПА ОНАХТ для отримання об'єктивної оцінки якості фахової підготовки;
· інформування студентів і випускників технікуму про вакантні місця на підприємствах, в установах та організаціях, що відповідають їх фаховій підготовці (спеціальності);
· здійснення спільно з державною службою зайнятості населення моніторингу працевлаштування випускників за місцем їх проживання;
· подання державній службі зайнятості населення за місцем проживання випускника, y якого питання працевлаштування залишається невирішеним, відомостей про нього (за його згодою) та здійснення спільних з державною службою зайнятості населення дій, направлених на пошук першого робочого місця.
Завдання Центр виконує через безпосереднє здійснення таких функцій:
· налагодження зв'язків та ділових стосунків технікуму з центральними та місцевими органами виконавчої влади, службами зайнятості населення, підприємствами, установами та організаціями (роботодавцями) з питань професійної підготовки та працевлаштування студентів і випускників;
· організація роз'яснювальної роботи серед студентів і випускників щодо нормативно-правових актів з питань державного регулювання зайнятості та трудових відносин;
· вивчення динаміки попиту на фахівців на ринку праці, надання відповідної інформації та пропозицій керівництву технікуму;
· створення бази даних про студентів і випускників, що звернулися до "Кар'єрного центру" з питань працевлаштування, та накопичення банку місць працевлаштування (потенційних роботодавців) для студентів і випускників;
· організація укладання та облік замовлень роботодавців на працевлаштування студентів і випускників технікуму, контроль виконання роботодавцями умов працевлаштування;
· інформування навчальних структурних підрозділів технікуму (відділень, випускових циклових комісій) про наявні вільні вакансії для подальшого працевлаштування випускників;
· надання інформації студентам і випускникам про вакантні місця роботи відповідно до їх фахової підготовки (спеціальності);
· організація зустрічей роботодавців зі студентами і випускниками з питань їх працевлаштування на конкретних підприємствах, в установах та організаціях, заходів щодо сприяння працевлаштуванню студентів і випускників (дні кар'єри, круглі столи, семінари-практикуми, науково-практичні конференції, ярмарки вакансій, конкурси на заміщення вакантних посад за замовленням роботодавця, проведення зустрічей з кращими випускниками технікуму тощо);
· запровадження системи зворотного зв'язку між підприємствами, установами та організаціями (роботодавцями) і технікумом для отримання об'єктивної оцінки якості фахової підготовки студентів, здійснення моніторингу працевлаштування випускників та відстеження їх кар'єрного зростання;
· надання консультацій випускникам щодо можливостей перепідготовки та підвищення кваліфікації з метою прискорення подальшого працевлаштування;
· налагодження тісної співпраці з органами студентського самоврядування у вирішенні питань працевлаштування;
· планування і координація роботи відділень, випускових циклових комісій щодо організації зайнятості студентів, які бажають працювати у вільний від навчання час;
· ведення обліку студентів, які бажають працевлаштуватись у вільний від навчання час та сприяння працевлаштуванню студентів у літній оздоровчий період;
· здійснення пошуку місця роботи для студентських трудових загонів (бригад), молодіжних трудових об'єднань та сприяння ефективній організації їх роботи;
· організація роз'яснювальної роботи серед студентів та випускників технікуму щодо нормативно-правових актів з питань державного регулювання зайнятості та трудових відносин;
· надання консультацій студентам і випускникам з питань оформлення резюме та розміщення його на сайті ТПА ОНАХТ;
· налагодження тісної співпраці з органами студентського самоврядування у вирішенні питань працевлаштування;
· щорічне інформування Педагогічної ради технікуму про проведену роботу;
· щорічне інформування адміністрації ТПА ОНАХТ та студентів про проведену роботу шляхом розміщення звіту на Інтернет - сайті та інших інформаційних ресурсах;
· розробка інструктивних документів, методичних рекомендацій для організації працевлаштування студентів і випускників;
· підготовка аналітичних звітів, інформаційних довідок, звітних даних ТПА ОНАХТ з питань організації працевлаштування студентів і випускників.
З функцій, визначених для кар'єрного центру, видно, що є потреба в зберіганні та обробці великих масивів інформації, її накопиченні, зберіганні та створенні звітів на основі цієї інформації. Ведення бази даних спрощується при використанні програмних засобів які дозволяють в один клік заповнювати дані, створювати вибірку та звіти. Таким чином, обрана тема є актуальною.
2. Уніфікована мова моделювання UML
Раціональна розробка інформаційної системи припускає глибоке попереднє аналітичне пророблення. Насамперед, необхідно окреслити коло завдань, виконуваних розроблювальною системою, потім, розробити модель системи, і нарешті, визначити способи реалізації. Глибоке пророблення архітектури розроблювальній інформаційній системі на початкових етапах проектування, як правило, окупається в наслідку, особливо при розробці великомасштабних проектів із тривалим супроводом.
Засоби мови моделювання UML (Unified Model Language, - уніфікована мова програмування) дозволяють виразно й досить легко зробити попередню концептуальну розробку інформаційної системи, і при цьому, методично супроводжувати весь хід розробки включаючи й весь подальший життєвий цикл розроблювальної інформаційної системи як програмного продукту.
UML - це мова для візуалізації, спецификування, конструювання й документування артефактів програмних систем, заснований на об'єктно-ориентированом підході.
UML, як і будь-яка інша мова, складається зі словника й правил, що дозволяють комбінувати вхідні в нього слова й одержувати осмислені конструкції. У мові моделювання словник і правила орієнтовані на концептуальне й фізичне подання інформаційних систем. Моделювання необхідно для розуміння системи. При цьому єдиній моделі ніколи не буває досить. Навпроти, для розуміння будь-якої нетривіальної системи доводиться розробляти велика кількість взаємозалежних моделей. У застосуванні до програмних систем це означає, що необхідна мова, за допомогою якого можна з різних точок зору описати подання архітектури системи протягом циклу її розробки.
UML - це мова візуалізації, при цьому UML - це не просто набір графічних символів. За кожним з них стоїть добре певна семантика. Таким чином, модель, написана одним розроблювачем, може бути однозначно інтерпретована іншим або навіть інструментальною програмою.
UML - це мова спецификування. У даному контексті специфицирование означає побудова точних, недвозначних і повних моделей. UML дозволяє специфицировать всі істотні рішення, що стосуються аналізу, проектування й реалізації, які повинні прийматися в процесі розробки й розгортання системи програмного забезпечення.
UML - це мова конструювання. Хоча UML не є мовою візуального програмування, моделі, створені з його допомогою, можуть бути безпосередньо переведені на різні конкретні мови програмування. Іншими словами, UML-Модель можна відобразити на такі мови, як Java, C++, Visual Basic, і навіть на таблиці реляційной бази даних або стійкі об'єкти об'єктно-ориентированой бази даних. Ті поняття, які переважно передавати графічно, так і представляються в UML; ті ж, які краще описувати в текстовому виді, виражаються за допомогою мови програмування.
Подібне відображення моделі на мову програмування дозволяє здійснювати пряме проектування: генерацію коду з моделі UML у якусь конкретну мову. Можна вирішити й обратну задачу: відновити модель по наявній реалізації. Природно, модель і реалізація припускає використання ряду специфічних сутностей. Тому для зворотного проектування необхідні як інструментальні засоби, так і втручання людини. Сполучення прямої генерації коду й зворотного проектування дозволяє працювати як у графічному, так і в текстовому поданні, якщо інструментальні програми забезпечують погодженість між обома поданнями.
Крім прямого відображення в мови програмування, UML у силу своєї виразності й однозначності дозволяє безпосередньо виконувати моделі, імітувати поводження систем і контролювати діючі системи.
UML - це мова документування. Компанія, що випускає програмні засоби, крім коду, що виконується, робить і інші документи, у тому числі:
вимоги до системи;
архітектуру;
проект;
вихідний код;
проектні плани;
тести;
прототипи;
версії, і ін.
Залежно від прийнятої методики розробки виконання одних робіт виробляється більш формально, інших менш. Згадані документи - це не просто складені частини, що поставляються, проекту; вони необхідні для керування, для оцінки результату, а також як засіб спілкування між членами колективу під час розробки системи й після її розгортання.
UML пропонує розроблювачеві й керівництву свій варіант рішення проблеми документування системної архітектури й всіх її деталей, пропонує мова для формулювання вимог до системи й визначення тестів і, нарешті, надає кошти для моделювання робіт на етапі планування проекту й керування версіями.
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 - Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ
Розробка діаграми варіантів використання
Метою побудови діаграми варіантів використання є виявлення дійових осіб - для кого призначене ПЗ, і які дії воно повинне виконувати. Розробка діаграми робиться в три етапи - виявлення дійових осіб - акторів, виявлення варіантів використання системи і побудова діаграми.
Діаграма діяльності
Для моделювання процесу виконання операцій в UML використовуються так звані діаграми діяльності. Застосовувана в них графічна нотація багато в чому схожа на нотацію діаграми станів, оскільки на діаграмах діяльності також присутні позначення станів і переходів. Відмінність полягає в семантиці станів, які використовуються для подання не діяльностей, а дій, і у відсутності на переходах сигнатури подій. Кожен стан на діаграмі діяльності відповідає виконанню деякої елементарної операції, а перехід у наступний стан спрацьовує тільки при завершенні цієї, операції в попередньому стані. Графічно діаграма діяльності представляється у формі графа діяльності, вершинами якого є стани дії, а дугами - переходи від одного стану дії до іншого. Таким чином, діаграми діяльності можна вважати окремим випадком діаграм станів. Саме вони дозволяють реалізувати в UML особливості процедурного і синхронного управління, обумовленого завершенням внутрішніх діяльностей і дій. На діаграмі діяльності відображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увагу фіксується на результаті діяльності. Сам же результат може привести до зміни стану системи або повернення деякого значення.
Діаграма діяльності описує деякий алгоритм виконання роботи. Діаграма містить початкові і кінцеві вершини, які позначаються у вигляді повідомлень.
На рисунку 3.2 відображена діаграма діяльності по предметній області: "Моделювання роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ".
Діаграма станів
Кожна діаграма станів в UML описує усі можливі стани одного екземпляра певного класу і можливі послідовності його переходів з одного стану в інший, тобто моделює усі зміни станів об'єкту як його реакцію на зовнішні дії.
Рисунок 3.2 - Діаграма діяльності “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ ”
Діаграми станів найчастіше використовуються для опису поведінки окремих об'єктів, але також можуть бути застосовані для специфікації функціональності інших компонентів моделей, таких як варіанти використання, актори, підсистеми, операції і методи.
Діаграма станів є графом спеціального виду, який представляє деякий автомат. Вершинами графа є можливі стани автомата, що зображуються відповідними графічними символами, а дуги означають його переходи із стану в стан. Діаграми станів можуть бути вкладені один в одного для детальнішого представлення окремих елементів моделі.
У метамоделі UML автомат є пакетом, в якому визначена безліч понять, необхідних для представлення поведінки модельованій суті у вигляді дискретного простору з кінцевим числом станів і переходів.
Тривалість знаходження системи у будь-якому з можливих станів істотно перевищує час, який витрачається на перехід з одного стану в інший. Передбачається, що в межі час переходу може дорівнювати нулю (якщо додатково не обумовлене інше), тобто зміна станів об'єкту може відбуватися миттєво.
Поведінка автомата моделюється як послідовне переміщення по графові від вершини до вершини з урахуванням орієнтації дуг, що зв'язують їх.
Для автомата повинні виконуватися наступні обов'язкові умови:
ь стан, в який може перейти об'єкт, визначається тільки його поточним станом і не залежить від передісторії;
ь у кожен момент часу автомат може знаходитися тільки в одному зі своїх станів. При цьому, автомат може знаходитися в окремому стані як завгодно довго, якщо не відбувається ніяких подій;
ь час знаходження автомата в тому або іншому стані, а також час досягнення того або іншого стану ніяк не специфікуються;
ь кількість станів автомата має бути кінцевою і усі вони мають бути специфіковані явним чином. Окремі псевдостани можуть не мати специфікацій (початкове і кінцеве стани). В цьому випадку їх призначення і семантика повністю визначаються з контексту моделі і даної діаграми станів;
ь граф автомата не повинен містити ізольованих станів і переходів. Для кожного стану, окрім початкового, має бути визначений попередній стан, а кожен перехід повинен сполучати два стани автомата;
ь автомат не повинен містити конфліктуючих переходів, коли об'єкт одночасно може перейти в два і більше подальші стани (окрім випадку паралельних підавтоматів). У мові UML виключення конфліктів можливе на основі введення сторожових умов.
На рисунку 3.3 відображена діаграма станів по предметній області: “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ”
Рисунок 3.3 - Діаграма станів “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ”
3.2 Вид з погляду проектування
Вид з погляду прецедентів включає наступні типи діаграм:
· діаграма послідовності;
· діаграма класів;
· діаграма кооперацій.
Розглянемо на прикладі предметної області “Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ”, кожну з діаграм більш детально.
Діаграма класів
Діаграми класів використовуються при моделюванні ПЗ найбільш часто. Вони є однією з форм статичного опису системи з точки зору її проектування, показуючи її структуру. Діаграма класів не відображає динамічну поведінку об'єктів зображених на ній класів. На діаграмах класів показуються класи, інтерфейси і відносини між ними.
Клас - це основний будівельний блок ПЗ. Це поняття присутнє і в ГО мовами програмування, тобто між класами UML та програмними класами є відповідність, що є основою для автоматичної генерації програмних кодів або для виконання реінжинірингу. Кожен клас має назву, атрибути і операції. Клас на діаграмі показується у вигляді прямокутника, розділеного на 3 області. У верхній міститься назва класу, в середній - опис атрибутів (властивостей), у нижній - назви операцій - послуг, що надаються об'єктами цього класу.
Атрибути класу визначають склад і структуру даних, що зберігаються в об'єктах цього класу. Кожен атрибут має ім'я і тип, що визначає, які дані він представляє. При реалізації об'єкта в програмному коді для атрибутів буде виділена пам'ять, необхідна для зберігання всіх атрибутів, і кожен атрибут буде мати конкретне значення в будь-який момент часу роботи програми. Об'єктів одного класу в програмі може бути скільки завгодно багато, всі вони мають однаковий набір атрибутів, описаний в класі, але значення атрибутів у кожного об'єкта свої і можуть змінюватися в ході виконання програми.
Для кожного атрибута класу можна задати видимість (прозорість). Ця характеристика показує, чи доступний атрибут для інших класів. В UML визначено такі рівні видимості атрибутів:
ь відкритий (публічне) - атрибут видно для будь-якого іншого класу (об'єкта);
ь захищений (захищений) - атрибут видно для нащадків даного класу;
ь закритий (приватні) - атрибут не видно зовнішніми класами (об'єктами) і може використовуватися лише об'єктом, його містить.
Клас містить оголошення операцій, що представляють собою визначення запитів, які повинні виконувати об'єкти даного класу. Кожна операція має сигнатуру, що містить ім'я операції, тип значення і список параметрів, який може бути порожнім. Реалізація операції у вигляді процедури - це метод, що належить класу. Для операцій, як і для атрибутів класу, визначено поняття "видимість". Закриті операції є внутрішніми для об'єктів класу і недоступні з інших об'єктів. Решта утворюють інтерфейсну частина класу і є засобом інтеграції класу в ПЗ.
На діаграмах класів зазвичай показуються асоціації та узагальнення. Кожна асоціація несе інформацію про зв'язки між об'єктами всередині ПЗ. Найбільш часто використовуються бінарні асоціації, що зв'язують два класи. Асоціація може мати назву, яку має висловлювати суть відображається зв'язку. Крім назви, асоціація може мати таку характеристику, як множинність. Вона показує, скільки об'єктів кожного класу може брати участь в асоціації. Множинність вказується у кожного кінця асоціації (полюса) і задається конкретним числом або діапазоном чисел. Множинність, зазначена у вигляді зірочки, припускає будь-яку кількість (у тому числі, і нуль).
Асоціація сама може мати властивості класу, тобто, мати атрибути та операції. У цьому випадку вона називається клас-асоціацією і може розглядатися як клас, у якого крім явно зазначених атрибутів і операцій є посилання на обидва пов'язують нею класу. Узагальнення на діаграмах класів використовується, щоб показати зв'язок між класом-батьком і класом-нащадком, а також в тому випадку, коли в системі виявляються декілька класів, що володіють схожим поведінкою.
При створенні діаграм класів часто користуються поняттям "стереотип". Надалі мова піде про стереотипи класів. Стереотип класу - це елемент розширення словника UML який позначає відмітні особливості у використанні класу. Стереотип має назву, яка задається у вигляді текстового рядка. При зображенні класу на діаграмі стереотип показується у верхній частині класу в подвійних кутових дужках. Є чотири стандартних стереотипу класів, для яких передбачені спеціальні графічні зображення.
Стереотип використовується для позначення класів-сутностей (класів даних), стреотіп описує прикордонні класи, які є посередниками між ПЗ і зовнішніми по відношенню до неї сутностями - акторами, що позначаються стереотипом. Нарешті, стереотип описує класи та об'єкти, які управляють взаємодіями. Застосування стереотипів дозволяє, зокрема, змінити вид діаграм класів.
На рисунку 3.4 відображена діаграма класів по предметній області: “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ”.
Діаграма послідовності
Діаграма послідовності - другий різновид діаграм взаємодії. Відображаючи сценарій поведінки в системі, ця діаграма забезпечує більш наочне уявлення порядку передачі повідомлень. Головне призначення цієї діаграми - описати можливі послідовності станів і переходів, які в сукупності характеризують поведінку елемента моделі протягом його життєвого циклу.
Рисунок 3.4 - Діаграма класів “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ ”
Діаграма станів представляє динамічну поведінку сутностей, на основі специфікації їх реакції на сприйняття деяких конкретних подій. Для моделювання взаємодії об'єктів в часі в мові UML використовуються діаграми послідовності. У діаграмі послідовності використовують:
ь Об'єкти - на діаграмі послідовності зображаються тільки ті об'єкти, які безпосередньо беруть участь у взаємодії. Ключовим моментом для діаграм послідовності є динаміка взаємодії об'єктів в часі. В UML діаграма послідовності має як би два виміри. Перше зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкта, який бере участь у взаємодії. Крайнім зліва на діаграмі зображується об'єкт, який є ініціатором взаємодії. Правіше зображається інший об'єкт, який безпосередньо взаємодіє з першим. Таким чином, всі об'єкти на діаграмі послідовності утворюють деякий порядок, який визначається черговістю або ступенем активності об'єктів при взаємодії один з одним.
ь Графічно кожен об'єкт зображається прямокутником і розташовується у верхній частині своєї лінії життя. Усередині прямокутника записуються ім'я об'єкту і ім'я класу розділені двокрапкою. При цьому вся запис підкреслюється, що є ознакою об'єкта. Другим виміром діаграми послідовності є вертикальна вісь тимчасова, спрямована зверху вниз. Початковому моменту часу відповідає сама верхня частина діаграми. Взаємодії об'єктів реалізуються за допомогою повідомлень, які надсилаються одними об'єктами іншим. Повідомлення зображуються у вигляді горизонтальних стрілок з ім'ям повідомлення, а їх порядок визначається часом виникнення. Тобто, повідомлення, розташовані на діаграмі послідовності вище, ініціюються раніше тих, що розташовані нижче. Масштаб на осі часу не вказується, оскільки діаграма послідовності моделює лише тимчасову впорядкованість взаємодій типу "раніше-пізніше".
ь Лінія життя об'єкта зображується пунктирною вертикальною лінією, асоційованою з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінія життя повинна тривати по всій площині діаграми послідовності від самої верхньої її частини до самої нижньої. Окремі об'єкти, виконавши свою роль в системі, можуть бути знищені, щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається в момент його знищення. Для позначення моменту знищення об'єкта в мові UML використовується спеціальний символ у формі латинської букви "X". Об'єкт обов'язково створюється зі своєю лінією життя і, можливо, з фокусом управління.
ь Фокус управління-процесі функціонування об'єктно-орієнтованих систем, одні об'єкти можуть перебувати в активному стані, безпосередньо виконуючи певні дії, або стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, у мові UML застосовується спеціальне поняття, що отримало назву фокуса управління (focus of control). Фокус управління зображується у формі витягнутого вузького прямокутника, верхня сторона якого означає початок отримання фокусу управління об'єкта (початок активності), а його нижня сторона - закінчення фокусу управління (закінчення активності). Прямокутник розташовується нижче позначення відповідного об'єкту і може замінювати його лінію життя, якщо на всьому її протязі він є активним. Періоди активності об'єкта можуть чергуватися з періодами його пасивності або очікування. У цьому випадку у такого об'єкта є декілька фокусів управління.
ь Повідомлення - в UML кожне взаємодія описується сукупністю повідомлень, якими беруть участь у ньому об'єкти обмінюються між собою. Повідомлення являє собою закінчений фрагмент інформації, який відправляється одним об'єктом іншого. Прийом повідомлення ініціює виконання певних дій, спрямованих на вирішення окремого завдання тим об'єктом, якому це повідомлення надіслано.
Таким чином, повідомлення не тільки передають деяку інформацію, але і вимагають або припускають виконання очікуваних дій від приймаючого об'єкта. Повідомлення можуть ініціювати виконання операцій об'єктом відповідного класу, а параметри цих операцій передаються разом з повідомленням.
На діаграмі послідовності всі повідомлення впорядковані за часом свого виникнення в системі, що моделюється. У такому контексті кожне повідомлення має напрям від об'єкта, який ініціює і відправляє повідомлення, до об'єкта, який його отримує.
ь Дана діаграма відображає сценарій пов'язаний із використанням однієї з функцій інформаційної системи - пошук інформації користувачем в БД кар'єрного центру. Діаграма містить об'єкти, які беруть участь у взаємодії. Кожен об'єкт позначається прямокутником, всередині пишеться ім'я об'єкту. Кожен об'єкт має лінію життя, яка може закінчитися в будь-який момент, вона позначається пунктирною лінією на діаграмі.
Діаграма кооперацій
Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відносини між об'єктами, які беруть участь у цій взаємодії.
Рисунок 3.5 - Діаграма послідовності для варіанту використання " Пошук інформації в базі даних "
Перш за все, на діаграмі кооперації у вигляді прямокутників зображуються беруть участь у взаємодії об'єкти, що містять ім'я об'єкта, його клас і, можливо, значення атрибутів. Далі, як і на діаграмі класів, вказуються асоціації між об'єктами у вигляді різних сполучних ліній. При цьому можна явно вказати імена асоціації і ролей, які відіграють об'єкти в даній асоціації. Додатково можуть бути зображені динамічні зв'язки - потоки повідомлень. Вони представляються також у вигляді сполучних ліній між об'єктами, над якими розташовується стрілка з вказівкою напряму, імені повідомлення і порядкового номера в загальній послідовності ініціалізації повідомлень.
На відміну від діаграми послідовності, на діаграмі кооперації зображаються тільки відносини між об'єктами, що грають певні ролі у взаємодії. На цій діаграмі не вказується час у вигляді окремого вимірювання. Тому послідовність взаємодій і паралельних потоків може бути визначена за допомогою порядкових номерів. Поняття кооперації (collaboration) є одним з фундаментальних понять у мові UML. Воно служить для позначення множини взаємодіючих з певною метою об'єктів в загальному контексті модельованої системи. Мета самої кооперації полягає в тому, щоб специфікувати особливості реалізації окремих найбільш значущих операцій в системі. Кооперація визначає структуру поведінки системи в термінах взаємодії учасників цієї кооперації.
Кооперація може бути представлена ??на двох рівнях:
ь рівні специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії;
ь рівні прикладів - вказує екземпляри і зв'язку, що утворюють окремі ролі в кооперації
На рисунку 3.6 відображена діаграма кооперацій по предметній області: “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ”
Рисунок 3.6 - Діаграма кооперацій для варіанту використання " Додавання нового студента та обробка введених даних "
3.3 Вид з погляду реалізації
Компонентна діаграма - різновид діаграми реалізації, що моделює фізичні аспекти ОО систем. Вона показує організацію набору компонент і залежності між ними.
Елементами таких діаграм є компоненти і інтерфейси, а також відносини залежності і реалізації.
Компонент - фізична і замінювана частина системи, яка відповідає набору інтерфейсів і забезпечує реалізацію цього набору. Графічно він відображається як прямокутник з вкладками, що зазвичай включає ім'я.
Я показую діаграму реалізації своєї системи у вигляді наборів компонент, за допомогою яких вона буде реалізована.
На рисунку 3.7 відображена діаграма компонентів програми автоматизації процесу роботи з базою даних кар'єрного центру ТПА ОНАХТ.
Рисунок 3.7 - Діаграма компонентів “ Модель роботи програмного додатку для керування базою даних кар'єрного центру ТПА ОНАХТ ”
Висновок
Головною метою курсової роботи є розробка моделі інформаційної системи, яка призначена для автоматизації роботи центру зайнятості. Для вирішення цього завдання ми використали CASE - засіб Rational Rose. Побудована модель допоможе центру зайнятості автоматизувати процес прийому заяв від громадян, працювати швидше і ефективніше і з меншими витратами часу і засобів, ніж без використання сучасних технологій. Автоматизовані системи все сильніше впроваджуються в усі області. Таким чином, ми маємо усі перспективи переходу на повну автоматизацію різних процесів і повсюдний перехід на досконалі інформаційні технології.
Дана система може бути реалізована за допомогою язика високого рівня С++ або Delphi.
В процесі виконання курсової роботи були розглянуті такі теоретичні питання:
§ існуючі програмні засоби моделювання інформаційних систем: Rational Rose, Oracle Designer, AllFusion Process Modeler, AllFusion ERwin Data Modeler, ARIS, Sybase PowerDesigner;
...Подобные документы
Засоби візуального моделювання об'єктно-орієнтованих інформаційних систем. Принципи прикладного системного аналізу. Принцип ієрархічної побудови моделей складних систем. Основні вимоги до системи. Розробка моделі програмної системи засобами UML.
курсовая работа [546,6 K], добавлен 28.02.2012Класифікація інформаційних систем. Дослідження особливостей мови UML як засобу моделювання інформаційних систем. Розробка концептуальної моделі інформаційної системи поліклініки з використанням середи редактора програмування IBM Rational Rose 2003.
дипломная работа [930,4 K], добавлен 26.10.2012Тривимірна модель мобільного робота. Алгоритмізація моделі та її програмної реалізації з використанням бібліотек MFC та OpenGL. Розробка програмного забезпечення. Середовище розробки проекту Microsoft Visual Studio 2010. Керування рухами маніпулятора.
курсовая работа [462,9 K], добавлен 03.04.2014Дослідження сутності UML (уніфікована мова моделювання) - мови графічного опису для об'єктного моделювання в області розробки програмного забезпечення. Передумови й історія виникнення UML. Керована моделями інженерія. Огляд англомовної літератури UML.
реферат [49,4 K], добавлен 19.07.2010Аналіз технічного забезпечення, вибір інструментального програмного забезпечення та середовища розробки програм. Створення класів для реалізації необхідних функцій для роботи програмного засобу. Розробка інтерфейсу для користувача та лістинг програми.
курсовая работа [343,9 K], добавлен 24.08.2012Проектування програми керування мікропроцесорним пристроєм світлової індикації на мові С та Assembler. Розробка алгоритму роботи програми, структурної та електричної принципових схем. Здійснення комп’ютерного моделювання для перевірки розроблених програм.
курсовая работа [710,7 K], добавлен 04.12.2014Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.
курсовая работа [3,5 M], добавлен 28.11.2011Технології об'єктно-орієнтованого аналізу та проектування інформаційних систем. Історія та структура мови UML. Опис функціональної моделі засобами UML. Використання UML в проектуванні програмного забезпечення. Характеристика CASE-засобів Visual Paradigm.
дипломная работа [7,9 M], добавлен 26.05.2012Розробка моделі системи "Автомобільного магазину". Вивчення основи мови моделювання UML. Створення її для визначення, візуалізації, проектування й документування програмних систем. Використання діаграм кооперацій, послідовності, станів та класів.
курсовая работа [257,8 K], добавлен 10.12.2014Загальна характеристика мови моделювання UML. Розробка діаграм UML з метою автоматизації продаж в магазині. Rational Rose як засіб візуального моделювання об'єктно-орієнтованих інформаційних систем. Зворотне проектування як головна перевага Rational Rose.
контрольная работа [1,7 M], добавлен 23.10.2014Розробка програми для реалізації системи, що забезпечує автоматичне управління та моделювання зміни музичних програм на радіостанції з використанням засобів Microsoft Visual. Програмна реалізація інтерфейсу та процесу моделювання роботи системи.
курсовая работа [1,7 M], добавлен 08.01.2012Розробка програми для моделювання роботи алгоритму Дейкстри мовою C# з використанням об’єктно-орієнтованих принципів програмування. Алгоритм побудови робочого поля. Програмування графічного інтерфейсу користувача. Тестування програмного забезпечення.
курсовая работа [991,4 K], добавлен 06.08.2013Опис основних етапів розробки архітектури програмної системи: структурування системи, моделювання управління, декомпозиція підсистем. Ознайомлення із кроками створення інтерфейсу користувачів як однієї із фаз проектування програмного забезпечення.
реферат [20,7 K], добавлен 24.11.2010Розробка інформаційної системи зберігання, обробки і моделювання алгоритмів обчислення статистичних даних для спортивний змагань. Характеристика предметної області, архітектури бази даних, установки і запуску системи, основних етапів роботи користувача.
курсовая работа [2,0 M], добавлен 26.12.2011Технологія проектування та розробка об'єктно-орієнтованих програм. Використання автоматного підходу при реалізації прикладних програм. Програмні продукти для графічного моделювання кінцевих автоматів. Виконуваний UML та SWITCH-технологія, їх принципи.
курсовая работа [27,1 K], добавлен 23.12.2011Висвітлення та розкриття поняття 3д-моделювання, його видів та особливостей. Аналіз основних видів моделювання, їхнє практичне використання, переваги та недоліки кожного виду. Розгляд найпоширеніших програм для створення 3-д зображень та їх функції.
статья [801,7 K], добавлен 18.08.2017Поняття моделювання як процесу, що полягає у відтворенні властивостей тих чи інших предметів і явищ за допомогою абстрактних об’єктів та описів у вигляді зображень, планів, алгоритмів. Системи масового обслуговування. Модель роботи видавничого центру.
курсовая работа [255,8 K], добавлен 15.09.2014Методика проектування бази даних, в якій повинна зберігатися вся інформація про художників, їх картини, епохи, в які картини були написані, музеї, в яких вони зберігаються. Проектування програмної системи за допомогою засобів візуального моделювання.
курсовая работа [4,0 M], добавлен 12.06.2011Автоматизування розрахункових задач проектування (рішення систем рівнянь, побудова графіків залежності, оптимізація, моделі об'єктів) і графічне проектування офісу на підставі вихідних даних. Графічне моделювання офісу Сапр-хімія. Математичне моделювання.
курсовая работа [6,8 M], добавлен 22.11.2010Побудова математичної моделі екосистем. Вхідні та вихідні змінні. Модель поширення забруднення підземних вод за моделлю Фелпса-Стрітера. Вибір програмного продукту. Аналіз результатів моделювання. Оптимальне управління функціонуванням екосистеми.
курсовая работа [1,1 M], добавлен 11.04.2015
