Данная информационная система включает управление поставкой кондитерских изделий различным заказчикам. Ассортимент изделий очень большой, и для быстрой продажи и доставки ведется учет заказов к различным организациям. Система должна регистрировать заказы, хранить информацию о поставляемых изделиях, список менеджеров предприятия, базы обслуживающих заказчиков, возможность возврата изделия и поддержка своевременного заказа сырья у поставщиков. Заказчик имеет право заказать необходимые изделия или вернуть изделия. Менеджеры предприятия должны в любое время иметь возможность сделать соответствующие коррективы в заказе по запросам и отчетам данной информационной системы. Средства системы должны позволять на основании заказа каждому конкретному заказчику генерировать заказ по каждому конкретному виду изделий, в случае нехватки сырья далее менеджер по сбыту и снабжения передаёт информацию поставщикам о необходимости их поставки. Также система должна поддерживать различные права доступа для менеджеров. Выполненный заказ доставляется к заказчику средствами предприятия в указанные сроки.
Глоссарий
В данной таблице представлено описание основных требований использующихся в информационной системе кондитерского цеха.
Термин | Значение |
Менеджер по работе с заказами | Работник, который регистрирует заказы, поданные клиентом. Анализирует заказы и делает отчёт о заказах. Под анализом заказа понимается, сколько заказов подано, статус клиента и важность самого заказа. |
Анализ заказа | Под анализом заказа понимается, сколько заказов подано, статус клиента и важность самого заказа. |
Заказчик товара | Клиент, который может подать заказ, изменить заказ и просмотреть БД продукция через менеджера по работе с заказами |
Менеджер по сбыту и снабжению | Работник, закупающий сырьё, в свою очередь, связываясь с поставщиком. А так же передаёт готовую продукцию кладовщику, и реализует её через экспедитора. |
Поставщики | Сотрудники, предприятия, поставляющие заказанное сырьё. |
Функциональный анализ информационной системы
Одна из моделей формализации процесса постановки целей и задач проекта была предложена фирмой Rational и вошла в стандарт языка UML. Для этого применяются диаграммы вариантов использования (use-case), иногда называемые диаграммами прецедентов. Вариант использования представляет собой типичное взаимодействие пользователя и проектируемой системы. Варианты использования характеризуются рядом свойств:
- вариант использования охватывает некоторую очевидную для пользователей функцию;
- вариант использования может быть как небольшим, так и достаточно крупным;
- вариант использования решает некоторую дискретную задачу пользователя.
В простейшем случае вариант использования создается в процессе обсуждения с пользователями тех вещей, которые они хотели бы получить от системы. При этом каждой отдельной функции, которую они хотели бы реализовать, присваивается некоторое имя и записывается ее краткое текстовое описание. Действующие лица могут играть различные роли по отношению к варианту использования. Они могут применять его результаты или сами непосредственно в нем участвовать. Хорошим источником для идентификации вариантов использования служат внешние события. Для этого необходимо перечислить все происходящие во внешнем мире события, на которые система должна реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, поможет идентифицировать варианты использования.
Данная диаграмма варианта использования описывает взаимодействие менеджера с заказчиком на основе поданного заказа.
Данная диаграмма вариантов использования показывает, в общем, весь процесс функционирования проектируемой информационной системы.
Заказчик связывается с менеджером по заказам кондитерского цеха по телефону, электронной почте или на предприятии. Заказчик может сделать, вернуть заказ в зависимости от качества продукции. При этом заказчик непосредственно не взаимодействует с информационной системой. Всю поступившую информацию в систему могут вносить только менеджеры. Для того чтобы иметь возможность сделать это, они предварительно регистрируются в системе т.е входят в систему. Менеджер по заказам делает заказ по каждому конкретному заказчику и доставляет заказ им средствами кондитерского цеха, в случае нехватки изделий менеджер по сбыту и снабжению связывается с поставщиками о необходимости поставки сырья.
Вариант использования «Заказ изделия».
Данный вариант использования описывает процесс поступления заявки от заказчика в систему.
Основной поток событий — данный вариант использования начинает выполняться, когда заказчик связывается с менеджером по заказам и собирается сделать какой-либо заказ.
1. Заказчик связывается с менеджером по заказам и делает заявку на покупку изделия.
Альтернативные потоки.
Отсутствуют.
Предусловия.
Отсутствуют.
Постусловия.
Отсутствуют.
Вариант использования «Возврат изделия».
Данный вариант использования описывает процесс возврата изделия обратно на предприятие.
Основной поток событий.
1. Заказчик доставляет возвращаемый изделие на предприятие своими средствами и заявляет менеджеру по сбыту и снабжению о своём намерении его вернуть.
- Менеджер по сбыту и снабжению проверяет, причины возврата товара.
- Если изделие имеет недостатки, то менеджер соглашается с возвратом или обменом заказа.
Альтернативные потоки.
1. Если возвращаемое изделия содержит недостатки со стороны заказчика, то в обмене и возврате данного заказа отказывается.
Предусловия.
Если вариант использования выполнен успешно, заказ будет возвращён заказчиком и в систему введётся соответствующая информация. В противном случае в возврате заказа будет отказано, и состояние системы не изменяется.
Постусловия.
Отсутствуют.
Вариант использования «Войти в систему».
Данный вариант использования описывает процесс входа пользователя в систему.
Основной поток событий — данный вариант использования начинает выполняться, когда менеджер собирается войти в систему.
- Система запрашивает имя пользователя, занимаемую им должность и его персональный пароль.
- Система проверяет правильность введенных данных, запрошенных ею на предыдущем этапе. Если ввод был выполнен верно, то система открывается и разрешает менеджеру работать в соответствии с назначенными для данного пользователя правами доступа.
Альтернативные потоки — если система обнаружит ошибку во введённых менеджером данных, то ему будет отказано во входе в систему. Менеджер может вернуться на начало основного потока или отказаться от входа в систему. При этом выполнение варианта использования завершается.
Предусловия. Отсутствуют.
Постусловия.
Если вариант использования выполнен успешно, менеджер входит в систему. В противном случае состояние системы не изменяется.
Вариант использования «Регистрация сырья».
Данный вариант использования описывает процесс регистрации сырья, поступившего в кондитерский цех от конкретного поставщика.
Основной поток событий — данный вариант использования начинает выполняться, когда менеджер по сбыту и снабжению вносит информацию о принятом сырье по каждому конкретному поставщику.
1. Менеджер при помощи средств проектируемой системы указывает количество поступившего сырья по конкретному поставщику.
Альтернативный поток событий. Отсутствует. Предусловия.
- Для выполнения данного варианта использования необходимо, чтобы информационной системе содержался ассортимент сырья всех поставщиков.
Постусловия.
Отсутствуют.
Вариант использования «Регистрация заказа».
Данный вариант использования описывает процесс регистрации заказа, полученного при варианте использования “Заказ изделия”.
Основной поток событий — данный вариант использования начинает выполняться, когда менеджер по заказам вносит информацию о принятом заказе.
1. Менеджер по заказам при помощи средств проектируемой системы указывает сведения о заказе: необходимое количество изделий по заказчикам и времени доставки.
Альтернативный поток событий. Отсутствует. Предусловия.
- Для выполнения данного варианта использования необходимо, чтобы информационной системе содержался ассортимент изделий для всех заказчиков.
Постусловия.
Отсутствуют.
Диаграмма взаимодействия.
Диаграммы взаимодействия являются моделями, описывающими поведение взаимодействующих групп объектов.
Диаграмма взаимодействия охватывает поведение только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой в рамках данного варианта использования. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagram) и кооперативные диаграммы (collaboration diagram).
На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии.
Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на диаграмме (сверху вниз). Каждое сообщение может быть помечено именем, при желании можно показать также аргументы и некоторую управляющую информацию. Также можно показать самоделегирование — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни. Активизации — прямоугольники на линиях жизни — показывают, когда метод становится активным (во время его выполнения либо при ожидании результата выполнения какой-либо процедуры). Используя механизм активизаций, можно более четко показать смысл самоделегирования. Без них довольно трудно определить, где же выполняются следующие после самоделегирования вызовы — в вызывающем методе или в вызываемом. Активизации вносят ясность в этот вопрос.
Вторым видом диаграмм взаимодействия является кооперативная диаграмма. На кооперативной диаграмме экземпляры объектов показаны в виде пиктограмм. Линии между ними обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования.
Каждый вид диаграмм взаимодействия имеет свои преимущества, выбор обычно осуществляется исходя из предпочтений разработчика. На диаграммах последовательности делается акцент именно на последовательности сообщений, при этом легче наблюдать порядок, в котором происходят различные события. В случае кооперативных диаграмм можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие.
Одним из главных свойств любой диаграммы взаимодействия является ее простота. Посмотрев на диаграмму, можно легко увидеть все сообщения.
Однако при попытке изобразить нечто более сложное, чем единственный последовательный процесс без множества условных переходов или циклов, данный подход может не сработать.
На рисунке 2 изображена диаграмма последовательности для варианта использования «Регистрация заказа»:
Рис. 2. Диаграмма последовательности для варианта использования «Регистрация заказа».
Данная диаграмма взаимодействия иллюстрирует следующую последовательность событий, вначале заказчик связывается с предприятием по телефону, по электронной почте или на предприятии и сообщает необходимые сведения для заказа:
- Менеджер по заказам, получает заказ и регистрируется в системе.
- Менеджер по заказам проверяет наличие изделий.
- если проверка показала, что до изделия в наличии имеется, то менеджер регистрирует заказ, если нет то одновременно регистрирует заказ с указанием даты доставки и оформляется заказ на изготовление изделия, и доставку сырья поставщиком;
- составление заявки на необходимые изделия и предварительная регистрация поступления изготовления.
- затем производится доставка товара сначала поставщиком на оптовую базу и в итоге средствами оптовой базы доставляется заказчику.
Для описанной выше диаграммы последовательности кооперативная диаграмма будет иметь следующий вид:
Диаграмма классов
Диаграммы классов являются центральным звеном методологии объектно-ориентированных анализа и проектирования. Диаграмма классов показывает классы и их отношения, тем самым, представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности сущностей, обеспечивающих требуемое поведение системы. На стадии проектирования диаграммы классов используются, чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя; если имя слишком длинно, его можно сократить или увеличить сам значок на диаграмме. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними.
Имеется два основных вида статических связей:
- ассоциации (например, менеджер может вести несколько проектов),
- подтипы (работник является разновидностью личности).
Идентификация классов, участвующих в реализации потоков событий варианта использования. В потоках событий варианта использования выявляются классы трех типов:
- граничные классы (Boundary) — служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо — вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса — кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации);
- классы-сущности (Entity) — представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования;
- управляющие классы (Control) — обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.
На диаграмме представлены следующие классы:
Управляющим классом, является класс «Заказы», операторами данного класса является предоставление отчёта о заказах и анализ заказов.
Класс «Заказы» взаимодействует со следующими классами:
- Класс-сущность «Заказчик», от данного класса поступают заказы. Операторами «Заказчика» являются: подача заказа, изменение заказа и просмотр заказов.
- Класс-сущность «Менеджер», содержит всю информацию о персонале. Операторами данного класса являются: просмотр менеджеров.
- Класс-сущность «Изделия», представляет собой базу данных о производимых изделиях. Операторами являются: наличие изделий.
Класс «Поставки» взаимодействует со следующими классами:
- Класс-сущность «Сырье», представляет собой базу данных сырья для производства изделий. Операторами являются: просмотр сырья.
- Класс-сущность «Поставщики», ведёт учёт поставщих сырья. Операторами данного класса являются: просмотр поставщиков.
Физическая модель в данной курсовой работе построена при помощи case-средства Erwin.
ERwin — это графический инструментарий для моделирования данных, основной целью которого является помощь аналитику в использовании бизнес-правил и требований к информации при создании логических и физических моделей данных. Как и многие другие инструментальные средства, ERwin следует использовать тому, кто понимает, для чего именно этот инструмент предназначен, и кто способен использовать его наиболее продуктивно.
Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».
Существует два уровня физических моделей: трансформационная модель и модель СУБД. Физические модели содержат информацию, необходимую системным разработчикам для понимания механизма реализации
логической модели в СУБД.
Целью трансформационной модели является предоставление информации администратору БД для создания эффективной структуры хранения, включающей в себя записи, формирующие БД. Трансформационная модель должна помочь-разработчикам выбрать структуру хранения данных и реализовать систему доступа к ним.
Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:
- физическая модель данных должна соответствовать требованиям, предъявляемым к проектируемой системе;
- выбор определенной физической модели должен быть аргументирован;
- должны быть определены возможности наращивания существующей структуры хранения, а также выявлены ее ограничения.
Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД.
Физическая модель состоит из следующих таблиц.
Таблица «Заказчик»
Наименование | Тип |
Номер заказчика | Int(11) |
ФИО заказчика | VarChar(20) |
Адрес | VarChar (20) |
Телефон | VarChar(20) |
Факс | VarChar(20) |
VarChar(20) |
Таблица «Менеджер»
Наименование | Тип |
Номер менеджера | Int(11) |
ФИО | VarChar(50) |
Должность | VarChar(11) |
Телефон | VarChar(5) |
Таблица «Заказы»
Наименование | Тип |
Номер заказа | Int(11) |
Дата заказа | Data |
Номер изделия | Int(11) |
Время заказа | Time |
Заказано | Int(11) |
Продано | Int(11) |
Стоимость | Float |
Номер заказчика | Int(11) |
Таблица «Изделия»
Наименование | Тип |
Номер изделия | Int(11) |
Наименование | VarChar(20) |
Количество | Int(11) |
Содержание | VarChar(100) |
Масса | Float |
Дата изготовления | Data |
Дата годности | Data |
Статус изделия | Boolean |
Таблица «Поставщики»
Наименование | Тип поля |
Номер поставщика | Int(11) |
Название поставщика | VarChar(50) |
Адрес | VarChar(20) |
Телефон | VarChar(20) |
Факс | VarChar(20) |
Таблица «Поставки»
Наименование | Тип поля |
Номер поставки | Int(11) |
Номер поставщика | Int(11) |
Номер сырья | Int(11) |
Количество | Int(11) |
Дата поставки | Data |
Статус сырья | Boolean |
Таблица «Сырье»
Наименование | Тип |
Номер сырья | Int(11) |
Наименование | VarChar(20) |
Производитель | VarChar(50) |
В физической модели главной таблицей является «Заказы» и «Поставки», которая связана с таблицами: «Заказчики», «Изделия», «Менеджер»- «Поставки», «Поставщики», «Сырье».
Диаграмма размещения.
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе.
Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства — в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и большим компьютером.
В целом эти диаграммы полезно применять, чтобы выделить особенные физические характеристики данной системы.
Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:
- узел (node) — вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.)). Для узла можно задать выполняющиеся на нем процессы;
- соединение (connection) — канал взаимодействия узлов (сеть).
В спецификациях процессора можно ввести информацию об его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК). Характеристики процессора — это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.
Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов.
- Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
- Non preemptive (без приоритетах У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
- Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
- Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.
• Manual (вручную). Процессы планируются пользователем.
Распределение процессов по узлам сети производится с учетом следующих факторов:
- используемые образцы распределения (трёхзвенная клиент — серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
- время отклика;
- минимизация сетевого трафика;
- мощность узла;
- надежность оборудования и коммуникаций.
На рисунке 7 изображена диаграмма размещения информационной системы кондитерского цеха:
Заказчики общаются с менеджерами по заказам по телефону, на предприятии и по электронной почте и делают или отзывают заказ с конкретным менеджером. Менеджер принимает заказ и всю полученную от заказчиков информацию он вносит в ИС на рабочей станции, а затем данные отправляется в сервер баз данных. Аналогичным образом происходит взаимодействие менеджера по снабжению и сбыта с ИС.