kursach_trpp_skan

ТУЛЬСКИЙ ИНСТИТУТ ЭКОНОМИКИ И ИНФОРМАТИКИ

Кафедра информационных технологий "Учебная дисциплина «РСПСиИТ»

КУРСОВАЯ РАБОТА

На тему

Создание модели покупки компьютера на языке UML.

Выполнил студент: Мишин С. И. ПИвЭ 08

(Ф.И.О., № группы)

^^jg^g7^r

(подпись)

Руководитель:

В.Л. Токарев., Преподаватель кафедры информационных технологий

(Ф.И.О., ученая степень, звание)

Тула, 2011 год.

тульский институт экономики и информатики

Отзыв

о курсовой работе Студента ^Ydn

(Фамилия имя отчество)

Тема курсовой работы

Создание модели покупки компьютера на языке UML.

1 Положительные стороны: (убедительность аргументации, актуальность темы, степень самостоятельности работы и творческого подхода, полнота разработки темы, использование математических методов, формальных моделей, ЭВМ, степень достижения цели)

2 Перечень недостатков курсовой работы:

3 Оценка курсовой работы_

(отлично хорошо удовлетворительно)

Руководитель. ВЛ. Токарев., Преподаватель кафедры информационных технологий

(подпись)

Дата: « <*0eaSZ_tf 20(1 / г.

тульский институт экономики и информатики

Руководитель

20//г.

(дата выдачи задания)

Тема курсовой работы

Создание модели покупки компьютера на языке UML.

Содержание курсовой работы (по главам)

4 Введение

5 ; Глава 1

6 Глава 2

7 Глава 3

8 Глава 4

9 Глава 5

10 Глава 6

13 Заключение

15 Список использованной литературы

Срок сдачи работы « » 20 г.

Руководитель

(подпись)\

Студент

Введение.

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного

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

П рецеденты со стороны покупателя:

1. Выбор компьютера

2. Оплата компьютера

3. Получение компьютера

Прецеденты со стороны продавца консультанта:

1. Консультация покупателя

2. Оформление заказа компьютера Прецедент со стороны кассира:

1. Прием денег

2. Выдача чека

Прецедент со стороны кладовщика:

1. Выдача компьютера

2. Заказ нового компьютера

Р азберем процесс покупки компьютера пошагово.

1. Консультация (покупатель консультируется с продавцом, на счет системных требований и цены)

2. Выбор товара (выбираем товар, который будет отвечать требованиям покупателя)

1. Оформление заказа компьютера

2. Оплата компьютера

3. Выдача чека (покупатель получает чек о покупке)

3. Выдача товара (кладовщик находит нужный товар(компьютер и выдает его покупателю)

4. Получение товара (покупатель получает указанную им модель)

Д ействия со стороны покупателя:

1. Выбор компьютера

2. Оплата компьютера

3. Получение компьютера

Действия со стороны продавца консультанта:

1. Консультация покупателя

2. Оформление заказа

Действия со стороны кассира

1. Прием оплаты

1. Выдача чека

Действия со стороны кладовщика:

1. Учет товаров

1. Выдача товаров.

Глава 4. Диаграмма последовательности.

Рисунок 4 — Диаграмма последовательности процесса работы магазина компьютерной техники

Опишем действия Покупателя компьютера, продавца, кассира и кладовщика пошагово.

1. Продавец консультант консультирует покупателя на счет разных моделей компьютера.

2. Покупатель выбирает нужную ему модель компьютера, которая соответствует всем его требования.

1. Продавец оформляет заказ.

2. Покупатель оплачивает заказ.

3. Кассир выдает чек покупателю.

4. Кладовщик выдает товар покупателю.

5. Покупатель получает товар.

Глава 5. Диаграмма поведения.

Рассмотрим поведения покупателя, продавца, кассира, кладовщика.

1. К онсультация покупателя

2. Выбор компьютера

3. Оформление заказа компьютера

4. Оплата компьютера

5. Выдача чека

6. Оплата компьютера

7. Получение компьютера

В таблицах 1-3 представлены описательные спецификации диаграммы классов.

Таблица 1 - Описание структуры класса «Заказы» (Zakazi)

Наименование	Обозначение в БД	Тин данных
Идентификатор заказа	Zakazijd	integer
Идентификатор клиента	Klientjd	integer
Идентификатор товара	Tovarijd	integer
Идентификатор сотрудника	Sotrudnikijd	integer
Дата заказа	Data_zak	data

Таблица 2 - Описание структуры класса «Клиент» (Klient)

Наименование	Обозначение в БД	Тип данных
Идентификатор клиента	Klientjd	integer
ФИО	FIO	string
Контактные данные	kont_dan	string

Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

Избыточность языка. TJML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.

Неточная семантика. Так как XJML определён комбинацией себя (абстрактный синтаксис), ОСЬ (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, ОСЬ и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

Проблемы при изучении и внедрении. Вьппеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.^111]

Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»).^[12^¹³' В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют моделидля генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и

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

Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).

Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

Список использованной литературы

1. Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство — М: Вильяме, 2005. — 416 с.

2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя 2-е изд. — М., СПб.: ДМК Пресс, Питер, 2004. — 432 с.

3. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд. / Пер. с англ.; Под общей редакцией проф. С. Орлова — СПб.: Питер, 2006. — 736 с.