Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Ознайомлення із середовищем проектування Enterprise Architect
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2012
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Основи автоматизованого проектування складних об’єктів і систем
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 1
«Ознайомлення із середовищем проектування Enterprise Architect»
з дисципліни
«Основи автоматизованого проектування складних об’єктів та систем»
для студентів базового напрямку підготовки за спеціальністю
“Комп’ютерні науки” (шифр 0804)
Львів-2012
Методичні вказівки до лабораторної роботи № 1 “ Ознайомлення із середовищем проектування Enterprise Architect ” з дисципліни “Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності - шифр 0804 “Комп’ютерні науки” Укл. Скрибайло-Леськів Д.Ю., Львів: Національний університет “Львівська політехніка”, 2012.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2012 р.
Завідувач кафедрою АСУ ______________ Медиковський М.О.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2012 р.
Лабораторна робота № 1
Ознайомлення із середовищем проектування
Enterprise Architect
Мета роботи: Ознайомитися із середовищем розробки UML-діаграм (Enterprise Architect), а також освоїти етапи життєвого циклу програмного забезпечення (ПЗ).
Завдання:
Оволодіти навичками роботи у середовищі Enterprise Architect.
Реалізувати технічне завдання для свого проекту (згідно індивідуального завдання).
1. Теоретичні відомості
Виділяють такі основні типи UML - діаграм:
Структурні діаграми:
діаграми класів (class diagrams) призначені для моделювання структури об'єктно-орієнтованих застосувань - класів, їх атрибутів і методів, наслідування, а також зв'язків класів один з одним;
діаграми компонент (component diagrams) використовуються при моделюванні компонентної структури розподілених застосувань; усередині кожна компонента може бути реалізована за допомогою безлічі класів;
діаграми об'єктів (object diagrams) застосовуються для моделювання фрагментів працюючої системи, відображаючи ті, що реально існують в runtime екземпляри класів і значення їх атрибутів;
діаграми композитних структур (composite structure diagrams) використовуються для моделювання складових структурних елементів моделей - кооперацій, композитних компонент і т.д.;
діаграми розгортання (deployment diagrams) призначені для моделювання апаратної частини системи, з якою ПЗ безпосередньо зв'язано (розміщено або взаємодіє);
діаграми пакетів (package diagrams) служать для розбиття об'ємних моделей на складові частини, а також (традиційно) для групування класів модельованого ПЗ, коли його дуже багато.
Поведінкові діаграми:
діаграми активностей (activity diagrams) використовуються для специфікації бізнес-процесів, а також для завдання складних алгоритмів;
діаграми випадків використання або діаграми прецедентів (use case diagrams) призначені для "витягування" вимог до системи з користувачів, замовника і експертів наочної області;
діаграми кінцевих автоматів (state machine diagrams) застосовуються для завдання поведінки реактивних систем;
діаграми взаємодій (interaction diagrams):
діаграми послідовностей (sequence diagrams) використовуються для моделювання тимчасових аспектів внутрішніх і зовнішніх протоколів ПЗ;
діаграми схем взаємодії (interaction overview diagrams) служать для організації ієрархії діаграм послідовностей;
діаграми комунікацій (communication diagrams) є аналогом діаграм послідовностей, але по-іншому зображуються (у звичній манері);
тимчасові діаграми (timing diagrams) є різновидом діаграм послідовностей і дозволяють в наочній формі показувати внутрішню динаміку взаємодії деякого набору компонент системи.
На рис.1 не всі вузли позначають типи діаграм - деякі зображають лише групи діаграм, наприклад, "Структурні", "Поведінкові", "Взаємодій".
Рис.1 Типи діаграм UML 2.0
Відзначимо нові типи діаграм, які з'явилися в UML 2.0 в порівнянні з версією 1.5:
діаграми композитних структур (composite structure diagrams) - сюди, фактично, увійшли два типи діаграм: (1) кооперацій (при цьому кооперації UML 1.5 були сильно розширені); (2) складних компонент, створених на базі компонент мови ROOM;
діаграми схем взаємодій (interaction overview diagrams) - прообразом цього типу діаграм були діаграми MSC overview;
діаграми комунікацій (communication diagrams) - це спрощений варіант діаграм кооперацій UML 1.5;
тимчасові діаграми (timing diagrams) - це новий тип діаграм, призначений для наочного зображення потоку зміни станів декількох об'єктів.
Опис нотації UML структурований по різних типах діаграм, хоча вони і не є строго обов'язковими. Різні конструкції мови можна вставляти в різнотипні діаграми. Наприклад, екземпляри класів можна зображати на одній діаграмі з самими класами, і пакети також можуть показуватися на діаграмах класів. Таким чином, межі між різними типами діаграм розмиваються. Створення діаграм того або іншого типу - всього лише найбільш сталий, традиційний спосіб використання UML, що не виключає, проте, і інших варіантів.
Типи діаграм UML 2.0
Нижче наведені деякі приклади UML 2.0 діаграм, що підтримуються в Enterprise Architect:
Структура діаграми
Динамічні діаграми
Пакет (Package)
Прецедент (Use case)
Клас (Class)
Аналіз (Analysis)
Об'єкт (Object)
Діяльність (Activity)
Складена структура (Composite structure)
Стан (State)
Компонент (Component)
Комунікація (Communication)
Розгортання (Deployment)
Послідовність (Sequence)
Клієнтура (Custom)
Вибір часу (Timing)
Взаємодія (Interaction)
Розробка технічного завдання і специфікації
Однією з найважливіших задач будь-якого проекту є виявлення і систематизація вимог замовника, розробка технологічного рішення. Якісно складені технічне завдання чи специфікація істотно знижують ризики проекту, заощаджують час і ресурси під час розробки, приймання і впровадження проекту. Послуга по складанню технічного завдання виконується як у комплексі з розробкою програмного забезпечення згідно розробленої специфікації, так і окремо.
Аналіз і проектування програмного забезпечення
Метою аналізу і проектування є виявлення відносно простої внутрішньої структури (що іноді називається архітектурою проекту), яка :
задовольняє задані функціональні властивості і специфікації;
погоджена з обмеженнями, що накладені апаратним забезпеченням;
задовольняє явні і неявні експлуатаційні вимоги;
задовольняє явні і неявні критерії дизайну;
задовольняє вимоги до процесу розробки (тривалість, вартість).
Продуктами аналізу і проектування є моделі, що дозволяють розробникам і замовникам зрозуміти структуру майбутньої системи, збалансувати вимоги і узгодити схему реалізації.
У процесі створення таких моделей використовуються сучасні методології й інструменти об’єктно-орієнтованого аналізу і проектування. Це дозволяє йти в ногу зі зростаючими вимогами проектування, реалізовувати складні бізнес- і технологічні процеси.
Розробка програмного забезпечення
Проект виконується в чіткій відповідності зі специфікаціями і термінами, погодженими з замовником на етапі планування робіт і узгодження контракту.
Гнучка система планування і розподілу ресурсів всередині компанії дозволяє з максимальною віддачею реалізовувати проекти і надавати замовникам якісний і сучасний продукт.
Модель взаємодії розробника і замовника визначається відповідно до цілей і задач проекту. За узгодженням сторін може застосовуватися еволюційний підхід, при якому випускають проміжні версії проекту з поступово реалізованими функціональними можливостями.
Контроль якості і тестування програмного забезпечення
Тестування розроблювальних систем і проектів має проводитись відповідно до вимог і рекомендацій міжнародної системи контролю якості.
Процес контролю якості інтегрований у кожен етап розробки програмного забезпечення, починаючи від проектування, складання технічного завдання і до впровадження готових рішень.
Система проміжного тестування, висока кваліфікація фахівців відділу контролю дозволяє досягти максимальної відповідності критеріям і вимогам якості програмних розробок.
Неухильне підвищення якості програмного забезпечення - одна з пріоритетних задач розробників.
Життєвий цикл програмного забезпечення
Процес створення та використання програмної системи включає декілька стадій: від початкової ідеї до остаточного морального застаріння. Цей процес називається життєвим циклом програмного забезпечення [6, 8, 11]. Він складається з наступних 6 етапів:
Специфікація (формулювання) вимог:
а) підготовка повного і чіткого визначення задачі;
б) представлення документів з вимогами до задачі користувачам і аналітикам для погодження.
Аналіз:
а) вивчення задачі, визначення специфікацій (тобто структури вхідних та вихідних даних);
б) оцінка альтернативних методів розв’язання;
в) вибір оптимального методу.
Проектування:
а) визначення структури програмної системи та її проектування;
б) розбиття програмної системи на окремі компоненти та їх проектування з визначенням ключових елементів структури даних.
Реалізація:
а) створення алгоритмів і кодів окремих модулів обраною мовою програмування;
б) створення вихідного текста програми;
в) відлагодження вихідного текста програми.
Тестування і верифікація:
а) тестування вихідного текста;
б) участь користувачів і спеціальних колективів (тестерів) у всіх перевірках системи.
Експлуатація і супровід:
а) використання готової програмної системи;
б) оцінка її ефективності;
в) усунення знайдених в процесі експлуатації помилок;
г) внесення необхідних змін для підтримки актуальності програмної системи;
д) перевірка коректності внесених змін (вони не повинні негативно впливати на функціонування системи).
Життєвий цикл програмного забезпечення є ітеративним, тобто допускає багатократне повторення своїх етапів. В ході розробки (етап 3) можуть виникнути проблеми, які будуть вимагати змін вимог до системи (етап 1); під час реалізації (етап 4) може виникнути необхідність переглянути результати, отримані під час розробки (на етапі 3); під час тестування (етап 5) можуть бути виявлені помилки і так далі (взалежності від самого проекту).
2. Практична частина
Застосування середовища проектування Enterprise Architect
на різних етапах розробки проекту
Як запевняють розробники (Sparx Systems), Enterprise Architect - це програма для UML-моделювання та проектування нового покоління. Ось фраза з їхніх рекламних матеріалів:
«Enterprise Architect існує у варіантах для Windows і Linux і є непоганим засобом для UML-моделювання, з можливістю багатокористувацької роботи і дружнім інтерфейсом. Ви також знайдете в EA безліч функцій, які зазвичай розподілені між кількома додатками. Включаючи відмінні можливості по генерації документації, підтримку плагінів, генерацію XSD-схем, HTML і підтримку для таких мов програмування, як C + +, Java, PHP, Visual Basic, VB.Net, Delphi або C #.»
Можливості Enterprise Architect досить широкі. Ось деякі з них:
нотація UML 2.0 з підтримкою всіх видів діаграм;
підтримка C + +, Java, C #, VB, VB.Net, Delphi, PHP,. NET;
моделювання БД, пряме проектування в DDL і зворотне проектування з ODBC;
завантажувані UML-профілі (наприклад, SPEM), що дозволяють створювати вузькоспеціалізовані моделі;
підтримка паттернів проектування;
генерація документації в форматах HTML і RTF;
багатокористувацька робота, утиліти для менеджера проекту, тестування, глосарій, інші ресурси;
автоматизація інтерфейсу, підтримка макросів;
і багато іншого.
Enterprise Architect існує в трьох редакціях:
EA Desktop Edition
Інтуїтивно зрозуміла утиліта для UML-моделювання, призначена для індивідуальних аналітиків і / або розробників. Найпростіший інструмент проектування, який має деякі обмеження. Відсутні багато, звичні для професіоналів, функції, які, втім, абсолютно не потрібні, якщо ви просто шукаєте інструмент для малювання UML-діаграм. Не підтримується, наприклад, імпорт / експорт коду і DDL, Active X-інтерфейс і спільний доступ до діаграм.
EA Professional Edition
Повнофункціональне середовище UML-моделювання, націлене на групову розробку, підтримує спільний доступ до створених моделей, Active X, XMI, імпорт / експорт коду і DDL, витяг схем БД Oracle, SQL Server і MS Access.
EA Corporate Edition
Найбільш повна редакція, що включає всі можливості настільної і професійної версій плюс можливість з'єднання з MySQL, SQL Server, PostgreSQL, Sybase Adaptive Server Anywhere і Oracle9i. Також ця редакція підтримує авторизацію користувачів, групи користувачів, блокування елементів. Ця версія призначена для великих команд.
Визначення вимог
Застосовуючи засоби UML-моделювання, бізнес-аналітики, крім тексту вимог, який стає потім технічним завданням на розробку продукту, нерідко створюють набір моделей, що дозволяють краще зрозуміти ці вимоги. Такі моделі можуть бути вельми різноманітні: серед них як мінімум можуть бути описи як наявного стану бізнес-процесів, які передбачається автоматизувати (дані моделі називаються AS IS - "як є"), так і стану бізнес-процесів, в якому вони повинні еволюціонувати після впровадження продукту. Крім того, моделі можуть відрізнятися способами опису бізнес-процесів, складових частин проекту і взаємодії з ними користувачів.
Створення нової діаграми:
Нижче наведений приклад додавання діаграми UML, розширеної діаграми або MDG діаграми технології до моделі в Enterprise Architect.
Примітка:
Для розробки програмного забезпечення, системної розробки в останніх версіях Enterprise Architect, ви повинні мати дозвіл створити і управляти новими діаграмами.
Щоб додати нову діаграму до існуючого пакету або елементу, слідують за кроками нижче:
У Project Browser, виберіть відповідний пакет або елемент щоб розмістити діаграму.
Виконайте один із наступних кроків:
У панелі інструментів Project Browser клацніть на іконку New Diagram.
Рис.2. Початкове вікно у середовищі Enterprise Architect
Клацніть правою кнопкою мишки, щоб відкрити контекстне меню і вибрати Add | Add Diagram або Add | Add <type> Diagram вибору графічного меню.
Натисніть [Insert] і виберіть Add | Add Diagram або Add | Add <type> Diagram вибору Графічного меню.
Рис. 3. Діалогове вікно вибору створення нової діаграми у Enterprise Architect
Виберіть Project | Add Diagram вибору Графічного меню. - Нові покази Графічного діалогу. - Типові значення поля ім'я до імені відібраного пакету або елементу; якщо необхідно, - Надрукуйте нове ім'я для нової діаграми.
У групі Вибрати, клацають по відповідному каталогу для діаграми. Група Графічні Типи показує список графічних типів в межах відібраної категорії.
У групі Графічні Типи, клацають по виду діаграми для створення.
Клацніть по кнопці ОК, щоб створити вашу нову діаграму.
Примітка:
Графічний тип визначає панель інструментів, пов'язану з діаграмою і це може з'явитися зі встановленим як дочірний клас іншого елементу в Project Browser (наприклад діаграма послідовності під випадком використання).
З діаграм, що найчастіше включаються бізнес-аналітиками в моделі, що створюються на етапі попереднього аналізу, слід зазначити в першу чергу Use Case-діаграми (діаграми сценаріїв взаємодії (діаграми прецедентів) користувача з продуктом з погляду користувача; рис.4); діаграми кооперації, що описують взаємодію об'єктів один з одним, а також діаграми діяльності, що описують потоки робіт і зміну станів об'єктів.
Рис.4. Use Case-діаграма в Enterprise Architect
Моделі, створені на етапі формулювання вимог, нерідко спрощують розуміння вимог і замовниками і розробниками за рахунок наочнішого представлення процесів, ніж їх текстовий опис, і служать для подальшого проектування додатків. Проте варто відмітити, що багато сучасних інструментів моделювання, зовсім не є просто засобами створення ілюстрацій – роботу над моделями, створеними бізнес-аналітиками, продовжують інші учасники проекту, використовуючи моделі для генерації коду, для генерації проектної документації, для створення планів тестування і навіть для контролю якості створеного застосування.
Проектування
На етапі проектування ухвалюються рішення щодо архітектури і складових частин проекту, що розробляється, а також відбираються технології для його реалізації. Зазвичай на цьому етапі до моделі, створеною бізнес-аналітиками, додаються діаграми компонентів і класів створюваних ужитків і діаграми розгортання створюваного рішення (рис.5), а також модифікуються деякі з вже створених діаграм.
Рис. 5. Діаграма розгортання
На цьому ж етапі у разі необхідності може створюватися логічна модель даних, що містить діаграми "сутність-зв'язок " (рис. 6), на її основі генерується фізична схема даних для конкретної СУБД, вибраної для реалізації проекту.
Рис. 6. Діаграма " сутність-зв'язок "
Створення коду
На етапі створення клієнтського і серверного коду моделювання може застосовуватися вельми активно – практично всі сучасні засоби UML-моделювання можуть здійснювати генерацію коду на різних мовах програмування (цей процес називається forward engineering), а деякі з них можуть здійснювати і зворотне проектування (reverse engineering), створюючи діаграму класів на основі готового ужитку. Крім того, пряма робота з кодом дозволяє природним чином інтегрувати в середовище розробки не лише засоби UML-проектування, але й інструменти рефакторингу, тобто засоби автоматичного перетворення коду з метою оптимізації, спрощення "читабельності" під час перейменування класів або методів.
Тестування
Оскільки під час тестування перевіряється відповідність продукту вимогам, план тестування створюється саме на їх основі, а отже, при його створенні можна застосовувати модель, створену на етапі формулювання вимог. Сценарії взаємодії користувачів з системою виконуються при тестуванні призначених для користувача інтерфейсів і при функціональному тестуванні.
Крім тестування останнім часом немала увага почала приділятися оцінці якості коду.
Створення документації
Окрім діаграм, сучасні засоби моделювання дозволяють створювати різноманітні звіти по моделях і включати їх в проектну документацію. Чим акуратніше велася робота над моделлю, тим простіше цю документацію створювати. В той же час модель може містити практично все, що потрібно відобразити в документації, причому не тільки в керівництві системного адміністратора або адміністратора баз даних, але і в керівництві користувача.
Впровадження і супровід
На етапі впровадження продукту фахівцями з впровадження зазвичай застосовуються діаграми розгортання, створені системними аналітиками на етапі проектування додатку. На етапі ж супроводу продукту відповідним фахівцям може знадобитися практично все, що було зроблено при роботі над проектом, зокрема код і всі створені моделі, особливо якщо на цьому етапі виявляється необхідність якого-небудь доопрацювання продукту.
Колективна розробка додатків
Оскільки моделі можуть застосовуватися практично всіма учасниками проекту і піддаватися постійним змінам, досить серйозною може стати проблема управління версіями однієї і тієї ж моделі. Саме тому сучасні засоби моделювання володіють, як правило, механізмами інтеграції із засобами управління змінами і засобами контролю версій, що, у свою чергу, дозволяє здійснити коректне ужитку однієї моделі колективом учасників проекту.
Приклад технічного завдання на тему:
Інформаційно-аналітична система «Реєстратура готелю»
Технічне завдання
Клієнт виконує пошук в базі даних системи готельний номер, який його цікавить. На цей запит він отримує від системи повний перелік номерів, які задовольняють його вимогам. Якщо ж такі номери вже зайняті іншими клієнтами, система пропонує вибрати номер з переліку всіх вільних номерів або повторити процедуру пошуку.
За результатами пошуку клієнт вирішує чи слід здійснювати замовлення.
Система також надає можливість забронювати номер в готелі. Бронювання виконується по телефону або через Інтернет.
Якщо клієнт вирішив поселитись в номері, він повинен пройти процедуру реєстрації і оплатити проживання в номері. Реєстрація полягає в заповненні реєстраційної форми, яка зберігається до кінця проживання клієнта в готелі. Оплата проводиться в зручній для клієнта формі (готівкою, безготівковою або кредитною картою).
Система постійно проводить обслуговування номерів готелю і клієнтів. Безкоштовні послуги входять у вартість перебування (не потребують додаткової оплати (харчування, бар, та ін.)). Також є можливість замовити платні послуги (масажний кабінет, системи платного телебачення та ін.). Для замовлення платних послуг клієнт повинен послати запит системі. Безкоштовні послуги надаються автоматично. Також клієнт може відмовитись від деяких послуг за своїм бажанням.
Система постійно обновлює базу даних номерів готелю при поселенні, виселенні та бронюванні номерів.
4. Варіанти індивідуальних завдань
Розробити програму «Домашня бібліотека», яка дає можливість зберігати інформацію про авторів, назви книг, їх номери, місце розташування, короткий опис тощо. Створити окремий клас «Вибране», можливість позначати позичені книжки.
Розробити веб-сторінку кафедри АСУ, яка надає інформацію про кафедру, розклад занять , навчальні дисципліни, новини, дозволяє скачати навчальні матеріали.
Розробити веб-сторінку магазину із продажу комп’ютерної техніки. На веб-сторінці можна ознайомитись із новинами магазину, скачати прайс-лист, зареєструватись, зробити замовлення (для зареєстрованих користувачів).
Розробити програму «Домашня відеотека», яка дає можливість зберігати інформацію про назви фільмів, режисерів, акторів, номери фільмів, дисків, місце розташування, короткий опис тощо. Створити окремий клас «Вибране», можливість позначати позичені диски.
Розробити розважальний портал, що надає можливість читати новини, переглядати картинки, скачувати музику, спілкуватись на форумі (для зареєстрованих користувачів).
Розробити власну експертну систему, що дозволяє створювати власні бази знань та бази правил, використовувати їх.
Розробити інформаційно-аналітичну систему «Реєстратура поліклініки», яка дозволяє реєструвати хворих, що поступають, вводити інформацію про хворобу, лікаря, до якого скеровується хворий тощо. Забезпечити можливість переглядати статистику по кількості хворих, що надходили, розподіл за різними хворобами.
Розробити веб-сторінку своєї групи, із можливістю переглянути інформацію про кожного студента групи, його оцінки, рейтинг студентів (додати можливість відображати рейтинг у вигляді діаграми), створити фотогалерею.
Реалізувати проект «Автоматизація кас залізничного вокзалу», який дозволяє реєструвати пасажирів на конкретні рейси поїздів також при необхідності їх видаляти, редагувати тощо. Передбачити можливість звернення до бази даних напрямів, що знаходиться на віддаленому сервері.
Розробити веб-сторінку магазину із продажу мобільних телефонів. На дану сторінку можна заходити лише зареєстрованим користувачам. В ній повинна міститись повна та вичерпна інформація про мобільні телефони, які є у базі даних сторінки. Передбачити можливість здійснення замовлення користувачем.
Розробити програму «Система автоматизації робочого місця аптекаря», яка містить у своїй базі інформацію про перелік наявного товару, назву, номери кожного з них, інформацію про ліцензію тощо.
Автоматизована система управління торговими місцями в торгівельному центрі.
Розробити веб-сторінку кінотеатру, на якій можна би було ознайомитися із показом прем’єр, передбачити можливість замовлення квитків через дану сторінку тощо. Замовлення квитків може здійснювати тільки зареєстрований користувач, не зареєстрований може тільки переглядати дану сторінку.
Автоматизована система центру управління замовленнями маршрутних таксі.
Програма для ведення обліку успішності студентів навчального закладу.
Система управління продукцією пекарні. Система повинна визначати форму та склад продукту, її кількість, якість, повинна вміщувати повну та вичерпну інформацію про процес виготовлення продукції у пекарні тощо.
Розробити веб-сторінку туристичного агентства, передбачити можливість широкого вибору напрямів відпочинку, можливість скасування напряму, уточнення деталей щодо відпочинку тощо. Для здійснення замовлення відпочинку за кордоном клієнт повинен пред’явити закордонний паспорт та інші необхідні документи і т.д.
Система управління та планування екскурсій міста. Дана система повинна здійснювати управління конкретними екскурсіями: визначати напрямок маршруту екскурсії, відповідальних за даний маршрут, кількість груп тощо.
Система підтримки роботи автомагазину: до даної системи повинен мати доступ адміністратор магазину. Система повинна керувати роботою касирів та містити у своїй базі найменування усіх наявних товарів у магазині тощо.
5. Порядок виконання роботи
5.1. Ознайомитися з теоретичною частиною.
5.2. Ознайомитися із середовищем розробки діаграм.
5.3. Розробити технічне завдання для свого індивідуального завдання.
Оформити звіт за результатами виконаної роботи.
Вимоги до звіту
Оформити звіт для захисту лабораторної роботи за зразком:
назва роботи
мета роботи
порядок роботи
короткі теоретичні відомості
розроблене технічне завдання
висновок.
Рекомендована література
Хабуш А., Ткачук Н.В., Исмаилов Р. Применение Web–технологии в информационно-управляющей системе газокомпрессорной станции магистрального газопровода. // Вісник ХДПУ. Харків, ХДПУ, вип. 102, 2000- С.113-117.
Язык UML. Руководство пользователю / Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. 2-е изд., Питер 2004.
Г. С. Иванова. Основы программирования: Учебник для вузов. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. – 416 с.
Лешек А. Мацяшек. Анализ и проектирование информационных систем с помощью UML 2.0 2008 р.
Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML 2002 р.
Методичні вказівки до лабораторної роботи № 1 “ Ознайомлення із середовищем проектування Enterprise Architect ” з дисципліни “ Основи автоматизованого проектування складних об’єктів та систем ” для студентів спеціальності 0804 “Комп’ютерні науки”
Укладач:
Скрибайло-Леськів Д.Ю.
Комп’ютерний набір, верстку та редагування
здійснила ст. гр. КН-41, каф. АСУ, Федевич О.Ю.
01.04.2013 22:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора