- •Р.А. Файзрахманов, А.В. Архипов
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
- •4.3. Подведение итогов
- •4.4. Контрольные вопросы
- •4.5. Контрольные задачи и упражнения
- •5. ДИАГРАММА КЛАССОВ
- •5.1. Теоретическая часть
- •5.2. Реализация в Rational Rose
- •5.5. Контрольные задачи и упражнения
- •6.1. Теоретическая часть
- •6.2. Реализация в Rational Rose
- •6.3. Подведение итогов
- •6.4. Контрольные вопросы
- •6.5. Контрольная задача
- •7. ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ
- •7.1. Теоретическая часть
- •7.2. Реализация в Rational Rose
- •7.3. Подведение итогов
- •7.4. Контрольные вопросы
- •7.5. Контрольные задачи
- •8. ДИАГРАММА СОТРУДНИЧЕСТВА
- •8.1. Теоретическая часть
- •8.2. Реализация в Rational Rose
- •8.5. Контрольные задачи
- •9. ДИАГРАММА СОСТОЯНИЙ
- •9.1. Теоретическая часть
- •9.3. Подведение итогов
- •9.4. Контрольные вопросы
- •9.5. Контрольные задачи
- •10. ДИАГРАММА ДЕЯТЕЛЬНОСТЕЙ
- •10.1. Теоретическая часть
- •10.3. Подведение итогов
- •10.4. Контрольные вопросы
- •11. ДИАГРАММА КОМПОНЕНТОВ
- •11.1. Теоретическая часть
- •11.4. Контрольные вопросы
- •11.5. Контрольные задачи
- •12.3. Подведение итогов
- •12.4. Контрольные вопросы
- •12.5. Контрольная задача
- •13. ГЕНЕРАЦИЯ КОДА
- •13.1. Алгоритм получения исходного кода C++
- •13.2. Задания для самостоятельного выполнения
- •ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
- •ИСПОЛЬЗОВАНИЕ МОДУЛЯ «RATIONAL ROSE C++ ANALYZER» ДЛЯ ОБРАТНОГО ВОССТАНОВЛЕНИЯ МОДЕЛИ ПО ИСХОДНОМУ КОДУ
- •РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ИСПОЛЬЗОВАНИЕМ UML
- •1. Разработка диаграммы прецедентов
- •2. Разработка диаграммы классов
- •3. Разработка диаграмм взаимодействия
- •4. Разработка диаграммы состояний
- •5. Разработка диаграммы деятельности
- •9. Разработка приложения
- •Контрольные вопросы
- •МОДЕЛЬ РАБОТЫ ПРЕДПРИЯТИЯ ОПТОВОЙ ТОРГОВЛИ. РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
- •ОГЛАВЛЕНИЕ
- •1. Деятельность и структура предприятия
- •2.1. Реализация продукции со склада
- •2.2. Возврат товара клиентом
- •2.3. Закупка продукции
- •3.1. Общие требования и принципы построения системы
- •3.2. Обеспечение связи офис - склад
- •3.3. Требования к персоналу
- •4. Диаграмма прецедентов
- •4.1. Реализация продукции со склада
- •5. Диаграмма классов
- •5.2. Контрагенты предприятия оптовой торговли
- •5.3. Продукция предприятия оптовой торговли
- •5.4. Заказ продукции
- •5.5. Накладная на получение товара
- •6. Диаграмма взаимодействия
- •12. Разработка приложения
- •ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПОДХОДА
Если расстояние между складом и офисом не более 300 м, то сеть должна быть построена по технологии Ethernet 10/100 Мбит/с с ис пользованием повторителей. В противном случае связь может быть установлена по выделенной телефонной линии, скорость передачи 33,6-115,2 Кбит/с (недорогой вариант), либо на оптоволоконной тех нологии, скорость передачи данных от 155 Мбит/с (дорогой вариант).
3.3.Требования к персоналу
Вданном разделе представлены следующие требования к конеч ным пользователям системы (менеджерам, бухгалтерам, кладовщи кам и т.п.):
- практические навыки работы на компьютере; - умение работать с Windows-приложениями.
4.Диаграмма прецедентов
4.1.Реализация продукции со склада
Прежде чем начать построение диаграммы, необходимо опреде лить актеров и прецеденты.
Актер является активным субъектом, взаимодействующим с сис темой. Для того чтобы правильно определить всех актеров, необхо димо внимательно проанализировать все сущности, взаимодейст вующие с системой.
В цепочке операций «Реализация продукции со склада» участву ют четыре сущности: «Клиент», «Менеджер», «Бухгалтер» и «Кла довщик». Каждый из них подходит на роль актера.
Определим прецеденты. Актер «Клиент» должен согласовать свой заказ с актером «Менеджер». Согласовывая заказ с клиентом, менеджер должен убедиться, что затребованные продукты есть в но менклатуре, которая отпускается предприятием, а также проверить фактическое наличие их на складе. Эта последовательность действий объединяется в прецеденте «Согласование заказа».
Используя шаблон Rational Unified Process, определим специфи кацию для прецедента «Согласование заказа» (табл. П3.1).
Если выбрана опция «выделить заказ», то система с помощью манипулятора «мышь» или клавиатуры позволяет выделить один заказ из списка уже существующих заказов. При откры тии формы работы с заказами данная опция автоматически активизируется, по умолчанию всегда выделен последний созданный заказ.
Если выбрана опция «удалить заказ», то система выдает предупреждение о том, что вы деленный заказ (включая все его позиции/строки) будет удален, и запрашивает под тверждение на выполнение операции. После подтверждения заказ удаляется из системы.
Если выбрана опция «поиск заказа», то система выдаст дополнительное окно, в кото ром пользователь системы, т.е. менеджер, смо жет указать критерии поиска желаемого заказа и подтвердить отбор данных (если поиск не вернул ни одного заказа, то активизируется альтернативный поток 2.2.3).
Если выбрана опция «создать строки зака за», то электронная форма отобразит поля для выбора продукта, единицы измерения и его количества. По завершении ввода система про верит, есть ли в наличии достаточное количест во указанного продукта, и создаст новую стро ку заказа (в случае, если данного продукта нет в достаточном количестве, выполнятся альтер нативный поток 2.2.4).
Если выбрана опция «выделить строку за каза», то система с помощью манипулятора «мышь» или клавиатуры позволяет выделить одну из строк текущего заказа. При открытии формы работы с заказами данная опция автома тически активизируется, по умолчанию всегда выделена последняя созданная строка.
Если выбрана опция «удалить строку за каза», то система выдает предупреждение
отом, что выделенная строка будет удалена,
изапрашивает подтверждение на выполнение операции. После подтверждения строка заказа удаляется.
2.2Альтернативные 2.2.1. Затребованной продукции нет на
|
потоки |
складе: менеджер предлагает клиенту продукты |
|
|
(имеющиеся в наличии) иной марки, но с ана |
|
|
логичными потребительскими свойствами либо |
|
|
согласовывает с клиентом вариант долгосроч |
|
|
ного заказа. |
|
|
2.2.2. Некорректный ввод нового заказа: но |
|
|
мер и дата нового заказа совпадают с номером и |
|
|
датой уже существующего. Система очищает по |
|
|
ля ввода и предлагает заполнить их заново. |
|
|
2.2.3. Заказ не обнаруж ен: система инфор |
|
|
мирует о том, что по заданным параметрам по |
|
|
иска не обнаружено ни одного заказа, и предла |
|
|
гает уточнить критерии поиска. |
|
|
2.2.4. Указанного продукта нет в наличии: |
|
|
создание строки заказа отменятся. |
3.0 |
Специальные |
Не определены. |
|
требования |
|
4.0 |
Предусловия |
Не определены. |
5.0 |
Постусловия |
Не определены. |
6.0 |
Дополнительные |
Нет. |
|
замечания |
|
Оплата заказа клиентом производится за наличный или безна личный расчет. В первом случае клиент оплачивает заказ в кассе предприятия сразу после выписки счета, а во втором случае клиент оплачивает свой заказ через банк. Также возможна смешанная оплата заказа. Во всех перечисленных случаях счет на оплату создается сис темой управления складом.
Выписать счет посредством системы управления складом может менеджер либо бухгалтер. В нашем случае мы возложим эту обязан ность на менеджера с целью повысить качество обслуживания клиен та. В таком варианте выписка счета будет являться прецедентом, расширяющим прецедент «Согласование заказа». Дата счета всегда совпадает с датой создания заказа независимо от того, когда распеча тывают этот счет, поскольку цены на продукцию могут изменяться каждый день, и в случае печати счета с более поздней датой, цены этого счета (которые копируются с заказа) будут не совпадать с дей ствующими ценами прайс-листа на более позднюю дату. Специфика ция данного прецедента представлена в табл. П3.2.
1.0 |
Наименование |
Выписка счета |
|
прецедента |
|
|
|
|
1.1 |
Краткое |
Прецедент инициируется актером «Менед |
|
описание |
жер» и используется для выписки счета клиенту. |
2.0Потоки событий
2.1 |
Основной поток |
|
Менеджер |
в электронной |
форме |
«Работа |
||
|
|
с заказами» выделяет заказ и выбирает одну из |
||||||
|
|
дополнительных опций: «печать счета», «печать |
||||||
|
|
счета для оплаты через банк». |
|
|
||||
|
|
|
Если выбрана опция «печать счета», то сис |
|||||
|
|
тема, используя информацию с выбранного зака |
||||||
|
|
за, |
распечатывает счет |
на оплату наличными |
||||
|
|
(в |
случае, |
если |
печать |
счета |
происходит уже |
|
|
|
с оплаченного заказа, активизируется альтерна |
||||||
|
|
тивный поток 2.2). |
|
|
|
|||
|
|
|
Если выбрана опция «печать счета для опла |
|||||
|
|
ты через банк», то система, используя информа |
||||||
|
|
цию с выбранного заказа, распечатывает счет на |
||||||
|
|
оплату через банк (в случае, если печать счета |
||||||
|
|
происходит уже с оплаченного заказа, активизи |
||||||
|
|
руется альтернативный поток 2.2). |
|
|||||
2.2 |
Альтернативные |
|
Выбранный заказ уже оплачен: система ин |
|||||
|
потоки |
формирует о том, что заказ, по которому выписы |
||||||
|
|
вается счет, уже оплачен. Прецедент инициирует |
||||||
|
|
ся снова. |
|
|
|
|
|
|
3.0 |
Специальные |
|
Не определены. |
|
|
|
||
|
требования |
|
|
|
|
|
|
|
4.0 |
Предусловия |
|
Перед |
активизацией прецедента |
должен |
|||
|
|
быть выполнен поток прецедента «Согласование |
||||||
|
|
заказа». |
|
|
|
|
|
|
5.0 |
Постусловия |
|
Не определены. |
|
|
|
||
6.0 |
Дополнительные |
|
Нет. |
|
|
|
|
|
|
замечания |
|
|
|
|
|
|
|
Сама оплата заказа представляет отдельный прецедент, в котором помимо клиента участвует и менеджер, поскольку ему необходимо придать заказу клиента статус оплаченного. Спецификация на дан ный прецедент представлена в табл. ПЗ.З.
1.0 |
Наименование |
Выписка накладной |
|
прецедента |
|
|
|
|
1.1 |
Краткое |
Прецедент инициируется актером «Бухгалтер» |
|
описание |
и используется для выписки товарно-транспортной |
|
|
накладной. |
2.0Потоки событий
2.1 |
Основной поток |
Бухгалтер в бухгалтерском модуле вызывает |
|
электронную форму «Офис. Работа с накладными». |
|
|
Форма содержит список ранее созданных накладных |
|
|
и ряд функциональных кнопок. |
|
|
|
Форма предлагает следующие опции: «создать |
|
накладную», «выделить накладную», «изменить на |
|
|
кладную», «поиск накладной», «удалить наклад |
|
|
ную», «создать строку накладной», «выделить стро |
|
|
ку накладной», «удалить», «печатать накладную». |
|
|
|
Если выбрана опция «создать новую наклад |
|
ную», электронная форма отобразит поля ввода дан |
|
|
ных, |
соответствующие содержанию товарно |
транспортной накладной, а также список оплачен ных заказов, для которых нет выписанных наклад ных на полную сумму заказа. При указании опла ченного заказа (что является обязательным при соз дании новой накладной), часть полей заполняется автоматически с использованием информации о за казе. По завершении ввода система проверит кор ректность заполненных данных и сохранит наклад ную (если введенный номер и дата новой накладной совпадают с уже существующей, то выполняется альтернативный поток 2.2.1). Вновь созданная на кладная получает статус «новая».
Если выбрана опция «выделить накладную», то система с помощью манипулятора «мышь» или кла виатуры позволяет выделить одну из списка уже су ществующих накладных. При открытии формы ра боты с накладными данная опция автоматически активизируется, по умолчанию всегда выделена по следняя созданная накладная.
Если выбрана опция «изменить накладную» и статус накладной «новая», то экранная форма позволит изменить ряд параметров выделенной накладной (если накладная имеет иной статус, то активизируется поток 2.2.2).
Если выбрана опция «поиск накладной», то сис тема выдаст дополнительное окно, в котором бух галтер сможет указать критерии поиска желаемой накладной и подтвердить отбор данных (если поиск не вернул ни одной накладной, то активизируется альтернативный поток 2.2.3).
После того как бухгалтер выписал накладную, она в электронном виде становится доступной кладовщику. Основная форма модуля «АРМ кладовщика» - «Склад. Работа с накладными». Данная форма по делена на четыре части. В первой содержится список накладных к от грузке. Каждая такая накладная имеет статус «выписанная». Во второй части формы содержится список накладных, по которым уже собраны заказы. Каждая накладная в этом списке имеет статус «готовая». В третьей части формы содержится список уже отгруженных накладных. Каждая такая накладная имеет статус «отгруженная». Последняя часть формы содержит список накладных со статусом «приостановленная». В этом списке накладные, отгрузка по которым невозможна по ряду при чин. Каждая накладная может присутствовать только в одном из спи сков, так как каждый список строго соответствует статусу накладной.
Кладовщик, учитывая приоритет и статус накладной, начинает сборку заказа. Спецификация на прецедент «Сборка заказа» пред ставлена в табл. П3.5.
|
|
Т аблица П3.5 |
1.0 |
Наименование |
Сборка заказа |
|
прецедента |
|
|
|
|
1.1 |
Краткое описа |
Прецедент инициируется актером «Кладовщик» |
|
ние |
и используется для сборки заказа. |
2.0Потоки событий
2.1 |
Основной поток |
Кладовщик в модуле «АРМ кладовщика» откры |
|
|
вает форму «Работа с накладными». |
|
|
Кладовщик начинает сборку заказа по тем на |
|
|
кладным, которые находятся вверху списка накладных |
|
|
к отгрузке (список сортируется таким образом, что |
|
|
накладные, которые необходимо отгрузить в первую |
|
|
очередь, находятся вверху списка). |
|
|
Как только заказ будет собран, кладовщик пере |
|
|
водит накладную в разряд готовых (если по каким-то |
|
|
причинам кладовщик не может собрать заказ по дан |
2.2 |
Альтернативные |
ной накладной, то активизируется поток 2.2). |
Накладная не может быть отгружена: кладовщик |
||
|
потоки |
присваивает ей статус «приостановленная», и она попа |
|
|
дает в последний список формы «Работа с накладными». |
3.0 |
Специальные |
Не определены. |
|
требования |
Не определены. |
4.0 |
Предусловия |
|
5.0 |
Постусловия |
Не определены. |
6.0 |
Дополнительные |
Нет. |
|
замечания |
|
По прибытии клиента на склад кладовщик отпускает товар (соб ранный заказ). Спецификация на прецедент «Выдача товара клиенту» приведена в табл. П3.6.
|
|
Т аблиц а П 3.6 |
1.0. |
Наименование |
Выдача товара клиенту |
|
прецедента |
|
|
|
|
1.1 |
Краткое |
Прецедент инициируется актером «Клиент» и за |
|
описание |
ключается в выдаче выполненного заказа. |
2.0Потоки событий
2.1 Основной поток |
Клиент прибывает на склад и обращается к одно |
|
му из кладовщиков. |
|
Кладовщик проверяет наличие накладной клиента |
|
в списке готовых накладных в форме «Работа с на |
|
кладными» системы управления складом (если на |
|
кладной нет в этом списке, то активизируется поток |
|
2.2.). Далее кладовщик выдает товар клиенту и остав |
|
ляет необходимые записи и свою подпись в обоих эк |
|
земплярах накладной. Один экземпляр остается у кла |
|
довщика, а второй у клиента. |
|
В электронном документе кладовщик проставляет |
|
дату фактической отгрузки. Накладная получает ста |
|
тус «отгруженная» и начинает отображаться в третьем |
|
списке формы - отгруженных накладных. |
2.2Альтернативные Накладной нет в списке готовых накладных: по
|
потоки |
накладной еще не собран заказ либо отгрузка приоста |
|
|
новлена. Возникшие в этом случае проблемы решает |
|
|
кладовщик вместе с менеджером, ведущим заказ. |
3.0 |
Специальные |
Не определены. |
|
требования |
|
4.0 |
Предусловия |
Не определены. |
5.0 |
Постусловия |
Не определены. |
6.0Дополнительные Нет. замечания