Описание предметной области информационной системы складского имущества

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

В описанной информационной системе можно выделить следующие действующие лица:

  1. заказчик — делает или возвращает заказ;
  2. сотрудник — общается с заказчиками, принимает заказы;
  3. поставщик — принимает от оператора заказ на доставку товара на склад или заказчику.

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

Моделирование системы будем осуществлять как поуровневый спуск от концептуальной модели к логической, а затем к физической модели системы. Концептуальная модель выражается в виде диаграмм вариантов использования (use case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком. Логическая модель позволяет определить два различных взгляда на системы: статический и динамический. Статический подход выражается диаграммами классов (class diagram). Именно диаграммы классов служат основой для генерации программного кода на целевом языке программирования. Динамический подход описывается двумя типами диаграмм: диаграммами взаимодействия объектов и диаграммами последовательности взаимодействий. Динамика конкретного класса может быть выражена с помощью диаграмм перехода состояний, определяющих модель конечного автомата, описывающего поведение класса. Каждое состояние задается своей вершиной; определены входное и выходное состояния, а также условия перехода из одного состояния в другое. Физическая модель задается компонентной диаграммой (component diagram), которая описывает распределение реализации классов по модулям, и диаграммой поставки (deployment diagram).

矵ᔐᙱ矵݈
Рис. 1. Диаграмма вариантов использования для информационной системы оптовой базы

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

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

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

Вариант использования «Заказ товара».

Данный вариант использования описывает процесс поступления заявки от заказчика в систему.

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

1. Заказчик связывается с оптовой базой и делает заявку на приобретения товара.

Альтернативные потоки.

Отсутствуют.

Предусловия.

Отсутствуют.

Постусловия.

Отсутствуют.

Вариант использования «Возврат товара».

Данный вариант использования описывает процесс возврата товара обратно на оптовую базу.

Основной поток событий.

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

  1. Сотрудник проверяет, причины возврата товара.
  2. Сотрудник проверяет товары на содержания брака и вследствие чего возник он по причине заказчика, поставщика.
  3. Если товар содержит брак поставщика, то сотрудник соглашается с возвратом или обменом заказа.

Альтернативные потоки.

1. Если возвращаемый товар содержит брак со стороны заказчика, то в обмене и возврате данного заказа отказывается.

Предусловия.

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

Постусловия.

Отсутствуют.

Вариант использования «Войти в систему».

Данный вариант использования описывает процесс входа пользователя в систему.

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

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

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

Предусловия. Отсутствуют.

Постусловия.

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

Вариант использования «Регистрация товара».

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

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

1. Сотрудник при помощи средств проектируемой системы указывает количество поступившего на оптовую базу по конкретному поставщику.

Альтернативный поток событий. Отсутствует. Предусловия.

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

Постусловия.

Отсутствуют.

Вариант использования «Регистрация заказа».

Данный вариант использования описывает процесс регистрации заказа, полученного при варианте использования “Заказ товара”.

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

1. Сотрудник при помощи средств проектируемой системы указывает сведения о заказе: необходимое количество товара по поставщикам и времени доставки.

Альтернативный поток событий. Отсутствует. Предусловия.

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

Постусловия.

Отсутствуют.

3. Диаграмма взаимодействия.

Диаграммы взаимодействия являются моделями, описывающими поведе­ние взаимодействующих групп объектов.

Диаграмма взаимодействия охватывает поведение только од­ного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой в рамках данного ва­рианта использования. Существует два вида диаграмм взаимодействия: диа­граммы последовательности (sequence diagram) и кооперативные диаграммы (collaboration diagram).

На диаграмме последовательности объект изображается в виде прямо­угольника на вершине пунктирной вертикальной линии.

Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодей­ствия.

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

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

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

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

Однако при попытке изобразить нечто более сложное, чем единственный последовательный процесс без множества условных переходов или циклов, дан­ный подход может не сработать.

На рисунке 2 изображена диаграмма последовательности для варианта использования «Заказ товара»:

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

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

  1. заказчик связывается с оптовой базой по телефону, по электронной почте или на оптовой базе и сообщает необходимые сведения для заказа.
  2. сотрудник, получивший заказ регистрируется в системе.
  3. сотрудник проверяет наличие товара на складе.
  4. если проверка показала, что до товар на складе имеется, то сотрудник регистрирует заказ, если нет то одновременно регистрирует заказ с указанием даты доставки и оформляется заказ на поставку товара поставщиком;
  5. составление заявки на необходимый товар и предварительная регистрация поступления товара.
  6. затем производится доставка товара сначала поставщиком на оптовую базу и в итоге средствами оптовой базы доставляется заказчику.

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

Рис. 3. Кооперативная диаграмма для варианта использования «Изменить (отозвать) заказ»

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

Рис. 4. Диаграмма последовательности для варианта использования «Возврат товара»

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

  1. заказчик доставляет на оптовую базу товар, который вернуть;
  2. прибыв к сотруднику, заказчик сообщает о браке товара и замене данного тавара на идентичный;
  3. далее менеджер входит в систему;
  4. войдя в систему, он проверяет, каким образом доставлялся товар и не было ли его повреждений;
  5. затем сотрудник определяет причины брака товара если возвращаемый товар был испорчен заказчиком, то товар замене не подлежит, в противном случае возвращается подобный товар;
  6. После уточнения причины брака сотрудник вносит сведения в информационную систему о браке.

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

Рис. 5. Кооперативная диаграмма для варианта использования «Возврат товара»

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

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

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

Диаграмма классов показывает классы и их отношения, тем самым, пред­ставляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности сущностей, обеспечи­вающих требуемое поведение системы. На стадии проектирования диаграммы классов используются, чтобы передать структуру классов, формирующих архи­тектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет типы объектов системы и различного рода статические связи, которые существуют между ними. Имеется два основных вида статических связей: ассоциации (на­пример, менеджер может вести несколько проектов) и подтипы (работник явля­ется разновидностью личности). Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офи­сов). Любая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Роль может быть явно поименована с помощью метки. Если такая метка отсутствует, роли присваивается имя класса-цели. Роль также обладает множественностью, которая показывает, сколько объектов может уча­ствовать в данной связи. Для ассоциации может быть указано направление нави­гации. Если навигация указана только в одном направлении, то такая ассоциация называется однонаправленной. У двунаправленной ассоциации навигация указа­на в обоих направлениях

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

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

Рис. 6. Диаграмма классов для информационной системы оптовой базы

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

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

5. Диаграмма состояний

Диаграммы состояний являются хорошо известным средством описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий. В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Хотя и то и другое — это процессы, реализуемые, как правило, некоторым методом класса, они трактуются различным образом. Действия связаны с переходами и рассматриваются, как мгновенные и непрерываемые Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события. Переход может содержать метку. Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: <Событие> [<Условие>]/<Действие>. Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается какая-либо деятельность, связанная с данным состоянием. Условие — это логическое условие, которое может принимать два значения: «истина» или «ложь». Условный переход выполняется только в том случае, если условие принимает значение «истина», в противном случае выполняется переход, не помеченный условием. Из конкретного состояния в данный момент времени может быть осуществлен только один переход; таким образом, условия являются взаимно исключающими для любого события. Существует два особых состояния: вход и выход. Любое действие, связанное с событием входа, выполняется, когда объект входит в данное состояние. Событие выхода выполняется в том случае, когда объект выходит из данного состояния. Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования. Они не слишком пригодны для описания поведения ряда взаимодействующих объектов.

7. Диаграмма размещения.

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

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

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

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

  1. узел (node) — вычислительный ресурс (процессор или другое устройство (дисковая память, контроллеры различных устройств и т.д.)). Для узла можно задать выполняющиеся на нем процессы;
  2. соединение (connection) — канал взаимодействия узлов (сеть).

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

Поле планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов.

  1. Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.
  2. Non preemptive (без приоритетах У процессов не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.
  3. Cyclic (циклический). Управление передается между процессами по кругу. Каждому процессу дается определенное время на его выполнение, затем управление переходит к следующему процессу.
  4. Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.

• Manual (вручную). Процессы планируются пользователем.

Распределение процессов по узлам сети производится с учетом следующих факторов:

  1. используемые образцы распределения (трёхзвенная клиент — серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
  2. время отклика;
  3. минимизация сетевого трафика;
  4. мощность узла;
  5. надежность оборудования и коммуникаций.

На рисунке 8 изображена диаграмма размещения информационной системы оптовой базы:

Рис. 8. Диаграмма размещения информационной системы оптовой базы

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

Leave a Comment

51 + = 60