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

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

Міністерство освіти і науки, молоді та спорту України

Васильківський коледж

Національного авіаційного університету

Кафедра програмної інженерії

Спеціальність 5.05010301 РПЗ

Реферат:

«Моделювання життєвого циклу програмного забезпечення обслуговування готелів»

Вступ

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

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

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

Задачі, які потрібно рішити, для досягнення цілі:

- Побудувати схему функціонування системи реєстрації клієнтів;

- Побудувати схему принципу подання резюме;

- Проблеми при реєстрації клієнтів та подання резюме;

- Ідеї, щодо удосконалення роботи системи готелів.

1. Загальні відомості про середовище моделювання та аналітичне моделювання

UML (Unified Modeling Language - уніфікована мова моделювання) - це стандартна нотація візуального моделювання програмних систем (але не тільки програмних систем).

На сьогодні вона підтримується багатьма об'єктно-орієнтованими інструментальними системами, тобто CASE-системами (Computer Aided Software Engineering).

UML - уніфікована мова, вона:

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

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

Історія виникнення і розвиток UML

На середину 1990-х років існувало більше 50 різних об'єктно-орієнтованих методів чи мов моделювання. У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, OMT-2 (Object Modelling Technique) Джима Рамбо (Jim Rumbaugh), Fusion, OOSE (Object-Oriented Software Engineering) Айвера Якобсона (Ivar Jacobson). І розроблювачів ПС, і замовників охоплювало занепокоєння при виборі методу проектування ПС, кожен із яких до того ж, як правило, спирався на власну нотацію. Отже, на часі визріла проблема в стандартизації та уніфікації підходів до моделювання.

Початком розробки UML вважається жовтень 1994 року, коли у Rational Software Corporation силами Греді Буча (Grady Booch) і Джима Рамбо (Jim Rumbaugh) була започаткована робота з уніфікації їх власних методів Booch'93 та OMT. Перша версія Уніфікованого Метода (Unified Method 0.8) була опублікована в жовтні 1995. Трохи згодом, у тому ж 1995 році, до роботи приєднався Айвер Якобсон (Ivar Jacobson), залучаючи до процесу інтеграції й уніфікації ще один метод - власний метод OOSE.

Таким чином, на першому концептуальному етапі UML отримав трьох авторів: Буча, Рамбо і Якобсона, кожен із яких був ідеологом свого власного об'єктно-орієнтованого методу візуального моделювання.

Розвитком UML опікується консорціум Object Managing Group (OMG). OMG опублікував запит на пропозиції щодо створення загальної метамоделі опису переважно ПС. Rational Software Corporation представив специфікацію UML 1.0 (січень 1997) і після її опрацювання членами OMG, групою було створено і прийнято версію UML 1.1 (вересень 1997). Консорціум OMG засновано у 1989 році одинадцятьма компаніями (в основному це були виробники комп'ютерних систем різного рівня й інтегратори зі світовим ім'ям). Основною задачею створення OMG було просування проекту CORBA. OMG пропагує CORBA під девізом "Middleware that's Everywhere" ("Середня ланка - всюди"). Зараз у консорціум входять більш ніж 1000 компаній. Серед них такі, наприклад, як IBM, DEC, Hewlett-Packard, Canon, Sun Microsystems, 3M, Fujitsu, Oracle, Bank of America, Chevron, Ford, Boeing, Hitachi, Xerox, VISA, AT&T, NT&T тощо. Варто зауважити, що більше 40% членів не є розроблювачами програмного забезпечення. Штаб квартира OMG знаходиться у США (більш ніж 60% членів OMG знаходяться у США та Канаді). Microsoft якийсь час тримався осторонь від OMG, проте підтримав UML (у 1997 році - році затвердження UML фактично як стандарту) і наступного 1998 року вступив у консорціум.

Завдання UML.

Мова UML призначена для рішення наступних завдань:

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

2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;

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

4. забезпечити формальну основу для однозначної інтерпретації мови;

5. стимулювати розширення ринку об'єктно-орієнтованих інструментальних засобів створення програмного забезпечення;

6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.

У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) [Kruchten, 2004] - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.

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

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

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

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

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

Застосування імітаційного моделювання

До імітаційного моделювання вдаються, коли:

· дорого або неможливо експериментувати на реальному об'єкті;

· неможливо побудувати аналітичну модель: в системі є час, причинні зв'язки, наслідок, нелінійності, стохастичні (випадкові) змінні;

· необхідно зімітувати поведінку системи в часі.

Мета імітаційного моделювання полягає у відтворенні поведінки досліджуваної системи на основі результатів аналізу найбільш суттєвих взаємозв'язків між її елементами або іншими словами - розробці стимулятора (англ. simulation modeling ) Досліджуваної предметної області для проведення різних експериментів. Імітаційне моделювання дозволяє імітувати поведінку системи в часі. Причому плюсом є те, що часом в моделі можна управляти: уповільнювати у випадку з швидкоплинучими процесами і прискорювати для моделювання систем з повільною мінливістю. Можна імітувати поведінку тих об'єктів, реальні експерименти з якими дороги, неможливі або небезпечні. З настанням епохи персональних комп'ютерів виробництво складних і унікальних виробів, як правило, супроводжується комп'ютерним тривимірним імітаційним моделюванням. Ця точна і відносно швидка технологія дозволяє накопичити всі необхідні знання, обладнання та напівфабрикати для майбутнього виробу до початку виробництва . Комп'ютерне 3D моделювання тепер не рідкість навіть для невеликих компаній.

Імітація, як метод вирішення нетривіальних завдань, отримала початковий розвиток у зв'язку зі створенням ЕОМ в 1950-х - 1960-х роках.

Діаграми класів (class diagrams) описують статичну структуру класів. Дозволяють (на концептуальному рівні) формувати "словник предметної області" та (на рівні специфікацій і рівні реалізацій) визначати структуру класів у програмній реалізації системи. Діаграми класів можуть використовуватись для генерації каркасного програмного коду (в реальній мові програмування).

Рис. 1 Діаграма класів для відвідувачів

Рис. 2 Діаграма класів для робітників

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

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

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

Рис. 3 Діаграма прецедентів для відвідувачів

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

Рис. 4 Діаграма прецедентів для робітників

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

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

Рис. 5 Діаграма послідовностей для відвідувачів

Рис. 6 Діаграма послідовностей для робітника

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

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

Рис. 7 Діаграма кооперацій для відвідувача

Рис.8 Діаграма кооперацій для робітника

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