Разработка объектно-ориентированной модели информационной системы работника почты

Автор работы: Пользователь скрыл имя, 03 Июля 2015 в 14:47, курсовая работа

Описание работы

Целью данной курсовой работы является создание автоматизированной информационной системы, способной автоматизировать большую часть деятельности складского учета.
Данная система предоставит возможность работникам:
Получение заявок от потребителей;
Оформление заказа на отправку;
Отправка груза потребителю.

Файлы: 1 файл

работа.docx

— 63.24 Кб (Скачать файл)



Содержание

 

 

 

 

 

 

 

 

 

 

 

ВВЕДЕНИЕ

 

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

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

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

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

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

 

1 Краткое описание разрабатываемой ИС

 

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

Данная система предоставит возможность работникам:

  1. Получение заявок от потребителей;
  2. Оформление заказа на отправку;
  3. Отправка груза потребителю.

 

 

 

 

 

 

2 Разработка объектно-ориентированной  модели

2.1 Модель  классов

 

Любая программа отображает в своих данных состояние внешних объектов программирования. Это могут быть как физические объекты внешней среды, так и логические программные сущности (например, файлы). Можно исходить из того, что каждому объекту будет соответствовать своя собственная структура данных, в которой содержатся все элементы описания свойств внешнего объекта программирования. Такую структуру данных можно аналогично назвать объектом. 

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

Объект – структура данных, содержащая описание свойств внешнего объекта программирования.

Метод  – функция, работающая с объектом. 

Класс – описание структуры объекта и методов работы с ним.

Синтаксическое определение объекта и класса - структура со встроенными функциями. 

Синтаксическое определение класса – тип данных, определяемый программистом. Класс представляет собой описание структуры объектов одного вида с набором методов их обработки. Аналогия с типом данных здесь напрашивается сама собой. Тип данных – это форма представления данных с набором операций. Отличие состоит в том, что тип данных либо уже определен в языке, либо формально составляется из уже существующих. Значит, класс можно определить как тип данных, определяемый программистом. Тогда объект – это переменная класса.

 

2.1.1. Диаграмма классов

 

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

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

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

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

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

Для моделируемой системы диаграмма классов выглядит следующим образом:


 

 

 

 

 

 

 

 

 

Рисунок 1 – Диаграмма классов

 

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

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

 

2.2 Модель взаимодействия

 

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

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

 

2.2.1 Диаграмма  вариантов использования

 

Диаграммы вариантов использования (use case diagrams) представляют собой графическое представление взаимодействия пользователя и компьютерной системы. Каждый вариант использования охватывает некоторую очевидную для пользователей функцию системы и решает некоторую дискретную задачу пользователя. Список всех вариантов использования фактически определяет функциональные требования к системе с помощью которых может быть сформулировано техническое задание, поэтому диаграмма вариантов использования является необходимым средством при анализе требований, выдвигаемых по отношению к проектируемой системе.

Диаграмма вариантов использования представляют собой граф, описывающий взаимодействие действующих лиц (actor) с системой, представленное вариантами использования (use case). Действующее лицо - это роль, которую пользователь играет по отношению к системе. Вариант использования представляет собой типичное взаимодействие пользователя и компьютерной системы и решает некую дискретную задачу пользователя.

Каждый вариант использования - это потенциальное требование к системе. Нотация варианта использования не должна содержать в себе подробные описания, достаточно несколькими предложениями описать выдвигаемое требование.

Действующее лицо представляется на диаграмме прямоугольником (аналогично классу) с стереотипом "actor". Но, чаще всего, действующее лицо представляется пиктограммой в виде фигурки человечка, а имя действующего лица располагается под фигуркой.

Вариант использования представляется на диаграмме эллипсом, внутри которого располагается его имя. Имя варианта использования может быть расположено и под эллипсом.

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

сommunicates - показывает участие действующего лица в варианте использования, соединяя символ действующего лица с символом варианта использования сплошной линией. Действующее лицо "общается" с вариантом использования по этой связи;

extends - линия со стереотипом "extends", с незаполненной стрелкой на конце, соединяет базовый вариант использования с вариантом использования, его расширяющим, и называется расширение. Конец с незаполненной стрелкой указывает на вариант использования, являющийся расширением базового варианта использования. Такой тип связи используется, если один варианта использования подобен другому, но несет большую нагрузку. Особенно удобно использовать такой тип связи при описании обработки аварийных ситуаций, возникающих в системе (чтобы не перегружать основной варианта использования, описывающий нормальное поведение системы, излишней логикой);

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

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



 

 


 

 

 

 

 

 

 

Рисунок 2 – Диаграмма вариантов использования

 

 

 

Рисунок 1 – Диаграмма вариантов использования

 

На этой диаграмме два действующих лица. На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами.

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

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

 

2.2.2 Диаграммы  последовательности

 

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

Рассмотрим подробнее каждый из вариантов использования:

 

 

 

 

 

 

 


 

 

 

 

 

 

 

 

 

 

Рисунок 3.1 – Диаграмма последовательности «Отправить посылку»

 

На данной диаграмме действующие лица – Клиент и Работник (Рис. 3.1). Клиент хочет отправить посылку, Работник  информирует его о стоимости отправки, производится оплата посылки и оформление соответствующих документов. Работник получает посылку.


 

 

 

 

 

 

Рисунок 3.2 – Диаграмма последовательности «Оформление заказа»

 

В данной диаграмме действующие лица – Работник и БД (Рис. 3.2). Работник вводит необходимые данные в БД о получателе.


 

 

 

 

 

 

Рисунок 3.3 – Диаграмма последовательности «Отправка на склад»

 

В данной диаграмме действующие лица – Работник и БД (Рис. 3.3). Работник вводит данные в БД, о том, что поступила посылка, и она отправляется на склад.


 

 

 

 

 

 

Рисунок 3.3 – Диаграмма последовательности «Отправка посылки»

 

В данной диаграмме действующие лица – Работник и БД (Рис. 3.3). Работник вводит данные в БД, о том, что посылка, которая находится на складе, должна быть отправлена определенной датой. 

 

 

 

 

 

2.2.3 Диаграммы  деятельности

 

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

Деятельность может содержать  входящие и/или исходящие дуги деятельности, показывающие потоки управления и потоки данных. Если поток соединяет две деятельности, он является потоком управления. Если поток заканчивается объектом, он является потоком данных. 

Информация о работе Разработка объектно-ориентированной модели информационной системы работника почты