Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Ознайомлення із середовищами проектування Enterprise Architect та Borland Together
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2013
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Інформаційні технології
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра АСУ
Звіт
до лабораторної роботи №1
Ознайомлення із середовищами проектування
Enterprise Architect та Borland Together
Мета роботи: Ознайомитися із середовищем розробки UML-діаграм (Enterprise Architect або Borland Together), а також освоїти етапи життєвого циклу програмного забезпечення (ПЗ).
Завдання:
Оволодіти навичками роботи у середовищі Enterprise Architect або Borland Together.
Реалізувати технічне завдання для свого проекту (згідно індивідуального завдання).
Порядок виконання роботи:
1. Ознайомитися з теоретичною частиною.
2. Ознайомитися із середовищем розробки діаграм.
3. Розробити технічне завдання для свого індивідуального завдання.
4. Оформити звіт за результатами виконаної роботи.
Теоретичні відомості
Виділяють такі основні типи 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) є різновидом діаграм послідовностей і дозволяють в наочній формі показувати внутрішню динаміку взаємодії деякого набору компонент системи.
На рис. не всі вузли позначають типи діаграм - деякі зображають лише групи діаграм, наприклад, "Структурні", "Поведінкові", "Взаємодій".
Рис Типи діаграм UML 2.0
Відзначимо нові типи діаграм, які з'явилися в UML 2.0 в порівнянні з версією 1.5:
діаграми композитних структур (composite structure diagrams) - сюди, фактично, увійшли два типи діаграм: (i) кооперацій (при цьому кооперації UML 1.5 були сильно розширені); (ii) складних компонент, створених на базі компонент мови ROOM;
діаграми схем взаємодій (interaction overview diagrams) - прообразом цього типу діаграм з'явилися діаграми MSC overview;
діаграми комунікацій (communication diagrams) - це спрощений варіант діаграм кооперацій UML 1.5;
тимчасові діаграми (timing diagrams) - це новий тип діаграм, призначений для наочного зображення потоку зміни станів декількох об'єктів.
Я залишу осторонь той факт, що англійські назви деяких типів діаграм змінилися, скажу лише декілька слів про російськомовну UML-термінології. На жаль, вона не є сталою: так, "Use case" переводять то як "варіант використання", то як "випадок використання" або навіть просто як "використання", "deployment" - то як "розміщення", то як "розгортання", "state machine (statechart)" - то як "стани і переходи", то як "кінцеві автомати" і так далі Про всяк випадок для всіх термінів в тексті дається початкова, англомовна назва. Я сподіваюся, що у читача не виникне в голові безнадійної термінологічної плутанини.
Опис нотації 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) можуть бути виявлені помилки і так далі (взалежності від самого проекту).
Варіант індивідуального завдання
Розробити веб-сторінку магазину із продажу комп’ютерної техніки. На веб-сторінці можна ознайомитись із новинами магазину, скачати прайс-лист, зареєструватись, зробити замовлення (для зареєстрованих користувачів).
Технічне завдання
1. Клієнт, відвідавши інтернет-магазин, реєструється, ввівши всі необхідні дані (Ім’я, Прізвище, По-батькові, Адресу, Контактний номер телефону, Номер рахунку в банку). У випадку гостьового візиту, користувач ознайомлюється із новинками магазину, переглядає товар і детальну інформацію про нього, завантажує прас-лист.
2. Після реєстрації/авторизації клієнт ознайомлюється з доступним товаром, переглядає його властивості, можливості, ціну, за необхідності здійснює пошук. Система передбачає пошук за повною назвою товару або за його унікальним кодом, що значно спрощує та пришвидшує процедуру.
3. В процесі пошуку клієнт формує особистий кошик , де зберігає товари, які його зацікавили. При бажанні редагує вміст кошика – додає нові товари чи видаляє непотрібні. За результатами пошуку клієнт вирішує чи слід здійснювати замовлення.
4. Система надає можливість замовити товар по телефону або через інтернет. Замовлення товару полягає в заповненні відповідної заявки, у якій уточнюються особисті дані користувача, вказується адреса і зручний час доставки. Оплата проводиться у зручній для клієнта формі (готівкою, безготівкою чи webmoney).
5. Система передбачає зручну систему знижок для постійних клієнтів, періодичні акції на певні види товару і пропозицію супутніх товарів. При бажанні клієнт має право скасувати замовлення.
6. Система, постійно оновлюючи базу даних товарів, дає користувачам правдиву інформацію про наявність чи відсутність товару на складі.
Висновок :
На даній лабораторній роботі я ознайомився із середовищем розробки UML-діаграм (Enterprise Architect ), освоїв етапи життєвого циклу програмного забезпечення (ПЗ). Крім того, оволодів навичками роботи у середовищі Enterprise Architect та реалізував технічне завдання для свого проекту (веб сторінку магазину із продажу комп’ютерної техніки).
01.02.2013 03:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора