Информационная подсистема движения товаров в магазине проката видеопродукции

 

 

 

 

 

 

 

 

 

 

 

КУРСОВОЙ  ПРОЕКТ

по дисциплине «Проектирование информационных систем»

на тему

«Информационная  подсистема  движения  товаров  в  магазине  проката  видеопродукции»

 

 

 

 

 

 

 

 

 

 

 

 

Выполнили студенты группы ИО-04 Черкасов В.А.

                                                                                        Скрипников Д.В.

 

Принял к.т.н., доцент Федотов Ю.А.

 

 

 

 

 

 

 

 

 

Королёв

2013 

РЕФЕРАТ

Курсовая работа: 56с., 14 рис., 4 табл., 4 источника.

Объектом  и предметом исследования является информационная подсистема движения  товаров  в  магазине  проката  видеопродукции.

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

В процессе работы проведены следующие исследования и разработки:

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

Областью  возможного практического применения являются салоны видеопроката, желающие заняться (или занимающиеся, но желающие модернизировать существующую СУБД) ведением учёта товара с помощью базы данных.

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

                 _______________________

                         ^{(подписи студентов)}

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

Проектирование  экономических информационных систем (ЭИС) — логически сложная, трудоемкая и длительная работа, требующая высокой  квалификации участвующих в ней  специалистов. Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления.  Однако до настоящего времени проектирование ЭИС нередко выполняется на интуитивном уровне неформализованными методами. Под проектированием ЭИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом. С этой точки зрения проектирование ЭИС сводится к последовательности формализации проектных решений на различных стадиях жизненного цикла ЭИС: планирования, анализа требований, технического рабочего проектирования, внедрения и эксплуатации ЭИС. Кроме того, в процессе создания и функционирования ЭИС информационные потребности пользователей постоянно изменяются или уточняются, что еще более усложняет разработку и сопровождение таких систем.

Основная  доля трудозатрат при создании ЭИС  приходится на пдное программное обеспечение и базу данных (БД). Производство ПО сегодня — крупнейшая отрасль мировой экономики, в которой занято около трех миллионов специалистов (программистов, разработчиков ПО и т. п.).

В процессе становления и развития программной инженерии можно  выделить четыре этапа:

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

В 60-е годы возникает идея комплексной автоматизации управления предприятиями и интеграции информационного обеспечения на основе баз данных. Реальностью автоматизированные системы управления стали в 70-е годы на базе ЭВМ 3-го поколения, которые позволили создавать вычислительные системы с распределенной терминальной сетью. Однако недостаточное быстродействие и надежность вычислительных машин, отсутствие гибких средств реализации информационных потребностей пользователей не смогли превратить ЭИС в инструмент коренного повышения эффективности управления предприятиями.

80-годы отмечены внедрением персональных ЭВМ в практику управленческих работников, созданием широкого набора автоматизированных рабочих мест (АРМов) на базе языков 4-го поколения (4GL), позволяющих с помощью генераторов запросов, отчетов, экранных форм, диалога быстро разрабатывать удобные для пользователей приложения. Однако рассредоточение ЭИС в виде АRМов, локальная («островная») автоматизация не способствовали интеграции управленческих функций и, как следствие, существенному повышению эффективности управления предприятием.

Для 90-х годов характерно развитие телекоммуникационных средств, которое привело к созданию гибких локальных и глобальных вычислительных сетей, предопределивших возможность разработки и внедрения корпоративных ЭИС (КЭИС). КЭИС объединяют возможности систем комплексной автоматизации управления 70-х годов и локальной автоматизации 80 - годов. Наличие гибких средств связывания управленческих работников в процессе хозяйственной деятельности, возможность коллективной работы, как непосредственных исполнителей хозяйственных операций, так и менеджеров, принимающих управленческие решения, позволяют во многом пересмотреть принципы управления предприятиями или проводить кардинальный реинжиниринг бизнес-процессов.

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

Для успешной реализации проекта объект проектирования (ПО ЭИС) должен быть, прежде всего, адекватно описан, т.е. должны быть построены полные и непротиворечивые модели архитектуры ПО, обусловливающей  совокупность структурных элементов  системы и связей между ними, поведение  элементов системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих структурные элементы.

Под моделью понимается полное описание системы ПО с определенной точки зрения. Модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы. По мнению одного из авторитетнейших специалистов в области объектно-ориентированного подхода Гради Буча, моделирование является центральным звеном всей деятельности по созданию качественного ПО. Модели строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения.

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

В 70-80-х гг. при разработке ПО достаточно широко применялись структурные  методы, базирующиеся на строгих формализованных  методах описания ПО и принимаемых  технических решений (в настоящее  время такое же распространение  получают объектно-ориентированные  методы). Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО в различных аспектах (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяют разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных ЭИС сдерживалось отсутствием адекватных инструментальных средств, поскольку при неавтоматизированной (ручной) разработке все их преимущества практически сведены к нулю. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы: неадекватная спецификация требований, неспособность обнаруживать ошибки в проектных решениях, низкое качество документации, снижающее эксплуатационные характеристики, затяжной цикл и неудовлетворительные результаты тестирования.

Перечисленные проблемы породили потребность  в программно-технологических средствах  специального класса — CASE(Computer Aided Software Engineering) -средствах, реализующих CASE-технологию создания и сопровождения ПО ЭИС.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ  К ИНФОРМАЦИОННОЙ ПОДСИСТЕМЕ

1. Словесное описание содержания бизнес-процесса

Магазин проката видеопродукции нуждается  в компьютеризованной системе учета так как его ассортимент составляют около 1000 видеокассет и 500 видеодисков. Запас уже заказан у поставщика, Однако директор намерен прибегать к услугам большого числа поставщиков. Все видеокассеты и диски снабжены штрих-кодом, так что сканер, интегрированный в систему, может поддерживать операции выдачи напрокат и возврата видеофильмов. Членские карточки клиентов также снабжены штрих-кодом.

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

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

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

Плата за прокат отличается в зависимости  от видеоносителя: кассета или диск.

Хотя магазин держит в запасе видеодиски только одного формата DVD, пользователи желали бы расширить в будущем  систему проката и на диски  других форматов. Работники ыидеомагазина стремятся запомнить коды наиболее популярных лент. Зачастую при идентификации фильма они используют именно код фильма, а не его название (поскольку фильм с одним названием мог выпускаться разными режиссерами).

Дополнительные требования:

 за кассеты и диски, возвращенные  позже указанного срока, взимается  дополнительная

плата за период, превышающий срок проката;

 каждый видеоноситель обладает уникальным идентификационным номером;

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

Забронировать можно те фильмы, которые заказаны у поставщика и /или все копии которых находятся в прокате, а также фильмы, которых нет в прокате и которые не заказаны у поставщика; при этом с клиента требуется задаток за один период проката.

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

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

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

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

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

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

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

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

Если кассета/диск задержаны более  чем на два дня, клиенту отправляется уведомление о задержке. После отправки двух уведомлений о задержке одной и той же кассеты/диска клиент получает предупреждение о том, что он является “нарушителем” и при следующем обращении его в магазин руководство будет рассматривает вопрос о снятии с него статуса “нарушителя”.

 

 

1.2. Выбор метода моделирования  информационных процессов в хозяйственной  деятельности организации

1.2.1. Описание процессного подхода  к моделированию

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

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

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

• принцип решения сложных проблем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне – так называемый принцип иерархического упорядочения.

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

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

 

1.2.2. Описание объектного подхода  к моделированию

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

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

• абстрагирование (abstraction);

• инкапсуляция (encapsulation);

• модульность (modularity);

• иерархия (hierarchy).

Кроме основных имеются еще три  дополнительных элемента, не являющихся в отличие от основных строго обязательными:

• типизация (typing);

• параллелизм (concurrency);

• устойчивость (persistence).

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

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

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

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

структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу).

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

Параллелизм — свойство объектов находиться в активном или пассивном  состоянии и различать активные и пассивные объекты между  собой.

Устойчивость — свойство объекта  существовать во времени (вне зависимости  от процесса, породившего данный объект) и/или в пространстве (при перемещении  объекта из адресного пространства, в котором он был создан).

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

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

Система объектно-ориентированных моделей  в соответствии с нотациями UML включает в себя следующие диаграммы:

1. Информационная система (Use-case diagram), которая отображает функциональность ЭИС в терминах бизнес-процессов;
2. Диаграммы классов-объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов;
3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5. Диаграммы деятельности (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы);
6. Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы);
7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода;
8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

 

1.2.3. Выбор метода

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

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

Объектная  декомпозиция  имеет  несколько  преимуществ  перед  алгоритмической:

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

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

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

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

 

1.3. Определение требования к  информационной подсистеме.

1.3.1. Варианты использования проектируемой  информационной подсистемы действующими  лицами бизнес-процесса. Требования  к подсистеме.

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

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

Для наглядного представления вариантов использования  применяются диаграммы вариантов  использования.

На диаграмме  вариантов использования показано взаимодействие между вариантами использования  и действующими лицами. Она отражает функциональные требования к системе  с точки зрения пользователя. Таким  образом, варианты использования —  это функции, выполняемые системой, а действующие лица — это заинтересованные лица (stakeholders) по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Направленная от варианта использования к действующему лицу стрелка показывает, что вариант использования предоставляет некоторую информацию, используемую действующим лицом.

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

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

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