Система "Деятельность судоходной компании"

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

Государственное бюджетное образовательное учреждение

среднего профессионального образования

«Волгоградский экономико-технический колледж»

ПЦК Информационных технологий

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

по МДК.03.02 Инструментальные средства разработки программного обеспечения

на тему

Проект. ПО «Деятельность судоходной компании»

Студент Петров Е.С.

Группа ХХ1-ПК

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

доцент, к. т. н. Игнатьев А.В.

Волгоград 2014

Оглавление

1. Постановка задачи

2. Моделирование использования

2.1 Выявление действующих лиц

2.2 Выявление вариантов использования системы

2.3 Построение диаграммы использования системы

3. Моделирование поведения

3.1 Реализация вариантов использования в виде текста

3.2 Реализация вариантов использования в виде диаграмм деятельности

4. Моделирование структуры

4.1 Выявление базовых классов

4.2 Создание диаграммы классов

4.3 Создание диаграммы компонентов

4.4 Создание диаграммы развертывания

5. Моделирование базы данных

5.1 Создание концептуальной модели

5.2 Создание логической модели

Заключение

Список литературы

1. Постановка задачи

Разработать прикладное программное обеспечение деятельности судоходной компании «Балтика». Это крупная компания занимается перевозками грузов между континентами. В ее собственности несколько десятков судов различного класса и грузоподъемности. К услугам этой компании обращаются тысячи клиентов из различных стран мира.

На судне может находиться несколько партий грузов для различных грузополучателей из различных стран и городов. Одна партия груза может состоять из нескольких разновидностей грузов. У одной партии может быть только один отправитель и только один получатель.

Судно следует по маршруту. Маршрут разрабатывается главным менеджером компании и проходит через несколько портов. В очередном порту назначения производится лишь частичная погрузка и выгрузка грузов, и судно следует дальше.

2. Моделирование использования

2.1 Выявление действующих лиц

система использование моделирование

В постановке задачи явно указан Главный менеджер - это будет первое действующее лицо.

Вторым действующим лицом будет множество людей, отвечающих за приемку партий грузов в различных городах - Приемщик.

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

2.2 Выявление вариантов использования системы

К значимым для действующих лиц результатам приводят следующие последовательности действий:

- Приемка партии грузов.

- Разработка маршрута судна.

- Формирование загрузки судна.

Соответствующие им варианты использования:

- Принять партию груза.

- Разработать маршрута судна.

- Сформировать загрузку судна.

2.3 Построение диаграммы использования системы

Маршрут разрабатывается главным менеджером компании, а приемка груза осуществляется сотрудниками компании в разных городах (Приемщиками).

Формирование загрузки судна осуществляется ответственными за погрузку груза в городах. Загрузка зависит от очередности приемки грузов.

Для входа в систему каждый пользователь должен пройти авторизацию, поэтому в каждый базовый ВИ включается ВИ «Выполнить авторизацию».

Если отправитель обратился в первый раз или груз отправляется новому получателю, то они должны быть внесены в базу данных, поэтому ВИ «Принять партию груза» может быть расширен за счет ВИ «Добавить отправителя в БД» и «Добавить получателя в БД».

Окончательный вид диаграммы использования представлен на рисунке 1.

Рисунок 1

3. Моделирование поведения

3.1 Реализация вариантов использования в виде текста

Текстовый сценарий для варианта использования «Принять партию груза»:

Приемщик создает новую спецификацию и проверяет обращался ли отправитель ранее. Если обращение первичное, то необходимые сведения об отправителе вносятся в базу данных.

Сведения об отправителе вносится в спецификацию.

Аналогичным образом вносятся сведения о получателе.

Далее в спецификацию вносятся все товары и спецификация закрывается.

3.2 Реализация вариантов использования в виде диаграмм деятельности

Диаграмма деятельности для варианта использования «Принять партию груза» показана на рисунке 2.

Рисунок 2

4. Моделирование структуры

4.1 Выявление базовых классов

Проанализировав текстовый сценарий и диаграмму последовательности для реализации варианта использования «Принять партию груза», выделим следующие базовые классы системы: "Спецификация", "Отправитель", "Получатель" и "Товар". Для корректного внесения товаров в спецификацию необходимо добавить класс "ЗаписьВСпецификации".

4.2 Создание диаграммы классов

Запись в спецификации является элементом табличной части спецификации, следовательно, классы "ЗаписьВСпецификации и "Спецификация" будут связаны отношением агрегации. Остальные классы связаны отношением ассоциации.

Диаграмма классов с атрибутами и операциями показана на рисунке 3.

Рисунок 3

4.3 Создание диаграммы компонентов

Основное назначение проектируемой информационной системы - хранить данные о принятых партиях грузов и маршрутах судов, и выполнять по указанию пользователя некоторые операции с этими данными. Анализируя состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД (DBMS - Data Base Management System). С точки зрения проектирования информационной системы, обеспечивающей деятельность судоходной компании, СУБД - это готовый компонент с заранее определенными интерфейсами и протоколом взаимодействия, структура которого описана вне нашей модели.

СУБД возьмет на себя все функции по непосредственному манипулированию данными: создание, удаление и поиск записей в таблицах и т.д.

Для манипуляции данными выделим компоненты, реализующие бизнес-логику для каждого из действующих лиц. Структуру компонента «Бизнес-логика АРМ приемщика» изобразим более подробно, указав состав, реализующих ее составных компонент.

Кроме этого, необходимо реализовать компоненты, ответственные за пользовательский интерфейс.

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

У нашего приложения три действующих лица, т.е. три категории пользователей. Допустим, что достаточно разграничить права на уровне категорий пользователей. Тогда можно реализовать три автоматизированных рабочих места. Пользователи, имеющие доступ к АРМу в целом, могут выполнять все операции АРМа и, таким образом, имеют те и только те права на доступ к данным, которые обеспечиваются операциями, реализованными в АРМе.

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

Принятое решение выражается на диаграмме компонентов, представленной на рисунке 4.

Рисунок 4

4.4Создание диаграммы развертывания

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

Для реализации архитектуры системы, приведенной выше на рисунке 5, будет использована "архитектура клиент/сервер с тонким клиентом". В этом случае артефакты, реализующие графический интерфейс, будут размещаться на пользовательских компьютерах. Базу данных необходимо поместить на сервере, предназначенном для хранения корпоративных данных, на котором установлена нужная СУБД, скорее всего, на сервере уже. Остается вопрос о. Здесь же будут размещены артефакты, реализующие бизнес-логику.

В результате получим диаграмму, приведенную на рисунке 5.

На этой диаграмме упор сделан на указание соответствия между компонентами и артефактами, выражающийся в наличии большого количества отношений зависимости со стереотипом «manifest».

Рисунок 5

5. Моделирование базы данных

5.1 Создание концептуальной модели

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

Рисунок 6

5.2 Создание логической модели

На этапе концептуального моделирования нами получены сущности “Спецификация” и “Товар”, связанные отношением “многие - ко - многим”. Учитывая, что при окончательной реализации будет использована реляционная модель хранения данных, необходимо создать сущность “ЗаписьТоварСпецификация”, связанную с сущностями “Спецификация” и “Товар” отношениями “многие - к - одному”.

В результате получим диаграмму, приведенную на рисунке 7.

Рисунок 7

Заключение

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

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

Для формирования модели архитектуры ИС и требований к программному обеспечению были построены диаграммы последовательности, классов, компонент и развертывания.

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

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

Список литературы

1. Гагарина, Л.Г., Виснадул Б.Д., Игошин А.В. Основы технологии разработки программных продуктов // Учебное пособие. -- М.: ФОРУМ: ИНФРА-М, 2006.

2. Кулябов, Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. Пособие. - М.: РУДН, 2008. -- 173 с.

3. Мацяшек, Л.А., Лионг, Б.Л. Практическая программная инженерия на основе учебного примера. Пер. с англ. - М.: БИНОМ. Лаборатория знаний, 2009. - 956 с.

4. Новиков, Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.

5. Рудаков, А.В. Технология разработки программных продуктов. - М.:2010.

6. Химонин Ю. И. Сбор и анализ требований к программному продукту. - Режим доступа: http://pmi.ru/profes/Software_Requirements_Khimonin.pdf.

7. Национальный Открытый Университет «ИНТУИТ» - Режим доступа: http://www.intuit.ru/

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