Разработка модели автоматизированной системы «Обработка заказов на поставку товаров»

Автор работы: Пользователь скрыл имя, 13 Марта 2013 в 19:48, курсовая работа

Описание

Целью курсовой работы является разработка модели автоматизированной системы «Обработка заказов на поставку товаров» на базе case средств в программной среде AllFusion Modeler.
Задачи, решаемые в курсовой работе:
 охарактеризовать АИС;
 рассмотреть подходы к проектированию АИС;
 дать сравнительную характеристику CASE средств;

Работа состоит из  1 файл

Erwin.docx

— 253.37 Кб (Скачать документ)

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

средства  разработки приложений, включая языки 4GL и генераторы кодов;

средства  конфигурационного управления;

средства  документирования;

средства  тестирования;

средства  управления проектом;

средства  реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам  и категориям. Классификация по типам  отражает функциональную ориентацию CASE-средств  на те или иные процессы ЖЦ. Классификация  по категориям определяет степень интегрированности  по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор  частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные  средства, поддерживающие весь ЖЦ ИС и  связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

применяемым методологиям и моделям систем и  БД;

степени интегрированности с СУБД;

доступным платформам.

Классификация по типам в основном совпадает  с компонентным составом CASE-средств  и включает следующие основные типы:

средства  анализа (Upper CASE), предназначенные для  построения и анализа моделей  предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

средства  анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

средства  проектирования баз данных, обеспечивающие моделирование данных и генерацию  схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

средства  разработки приложений. К ним относятся  средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

средства  реинжиниринга, обеспечивающие анализ программных кодов и схем баз  данных и формирование на их основе различных моделей и проектных  спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных  кодов наибольшее распространение  получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

средства  планирования и управления проектом (SE Companion, Microsoft Project и др.);

средства  конфигурационного управления (PVCS (Intersolv));

средства тестирования (Quality Works (Segue Software));

средства  документирования (SoDA (Rational Software)).

Компания Interface Ltd. поставляет все наиболее передовые CASE-средства, существующие на рынке. Компания предоставляет комплексную информационную и техническую поддержку, проводит учебные курсы и бесплатные семинары

Программные продукты Computer Associates

Линейка AllFusion Modeling Suite (ранее: ERwin Modeling Suite) :

AllFusion Process Modeler (ранее: BPwin) - моделирование бизнес-процессов

AllFusion ERwin Data Modeler (ранее: ERwin) - моделирование баз данных и хранилищ данных

AllFusion Data Model Validator (ранее: ERwin Examiner) - проверка структуры СУБД и моделей, созданных в ERwin

AllFusion Model Manager (ранее: ModelMart) - среда для командной работы проектировщиков

AllFusion Component Modeler (ранее: Paradigm Plus) - моделирование приложений и генерация объектного кода

AllFusion Modeling Suite (ранее: ERwin Modeling Suite) - интегрированный  комплекс CASE-средств, обеспечивающий  все потребности компаний-разработчиков  ПО. Данный пакет служит для  проектирования и анализа баз  данных, бизнес-процессов и информационных  систем и включает продукты: AllFusion Process Modeler (ранее: BPwin) , AllFusion ERwin Data Modeler (ранее: ERwin) , AllFusion Data Model Validator (ERwin Examiner) , AllFusion Model Manager (ранее: ModelMart) , AllFusion Component Modeler (Paradigm Plus) , использование которых позволяет сократить расходы и повысить продуктивность процесса разработки.

AllFusion Process Modeler (ранее: BPwin) - ведущий инструмент для моделирования бизнес-процессов. Позволяет оптимизировать деятельность организации и проверить ее на соответствие стандартам ISO9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность. Являясь стандартом де-факто, BPwin поддерживает сразу три нотации моделирования: IDEF0 (федеральный стандарт США), IDEF3 и DFD.

AllFusion ERwin Data Modeler (ранее: ERwin) - лидер среди средств моделирования баз данных и хранилищ данных. Позволяет проектировать, документировать и сопровождать базы данных различных типов. Поддерживая прямое и обратное проектирование для 20 типов СУБД, ERwin повышает качество разрабатываемой БД, производительность труда и скорость разработки. Журнал "КомпьютерПресс" по итогам 2000 года признал ERwin лучшим средством проектирования данных.

AllFusion Data Model Validator (ранее: ERwin Examiner) - инструмент  для проверки структуры баз  данных и создаваемых в ERwin моделей, позволяющий выявлять  недочеты и ошибки проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу  поиска и исправления ошибок, одновременно повышая квалификацию  проектировщиков баз данных благодаря  встроенной системе обучения.

AllFusion Model Manager (ранее: ModelMart) - среда для работы группы проектировщиков на ERwin и BPwin. Обеспечивает совместный доступ и редактирование моделей, повышая эффективность и скорость работы проектировщиков, является интегрирующим звеном для ERwin (моделирование баз данных) и BPwin (моделирование бизнес-процессов). Защищает хранимые на собственном сервере модели, позволяя задавать для сотрудников различный уровень доступа к ним. Руководителям же проектов позволяет координировать весь ход работы.

AllFusion Component Modeler (ранее: Paradigm Plus) - мощное CASE-средство для моделирования компонентов программного обеспечения и генерации объектного кода приложений на основе созданных моделей. Продукт можно использовать как при создании новых приложений, так и при изменении или объединении существующих. Благодаря интеграции с BPwin есть возможность использования функциональной модели вместе с объектной. Paradigm Plus поддерживает около десятка стандартных нотаций, таких как UML и Booch, интегрируется с технологиями COM/DCOM, CORBAPlus, Visibroker и др., продуктами CA, Microsoft, Rational Software и др.

Описание  перечисленных CASE-средств приведено  в разделе 5. Кроме того, на рынке  постоянно появляются как новые  для отечественных пользователей  системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые  версии и модификации перечисленных  систем.

2.2 Автоматизированная система «Обработка заказов на поставку товаров» на базе CASE – средства CA AllFusion Modeler.

AllFusion Process Modeler r7 – это мощный инструмент моделирования, который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами AllFusion Process Modeler r7, позволяет четко документировать различные аспекты деятельности - действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Таким образом, формируется целостная картина деятельности предприятия - от моделей организации работы в маленьких отделах до сложных иерархических структур.

AllFusion Process Modeler r7, совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям аналитиков и системных аналитиков. AllFusion Process Modeler r7, позволяет повторно использовать ключевую информацию моделирования с точки зрения базовых аспектов, чтобы определить точки конфликтов и, в конечном счете, достичь их согласования.

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

В результате изучения предметной области  в программной среде Allfusion modeler были созданы диаграммы. Первая диаграмма высшего уровня представлена на рисунке 1.

 

Рисунок 1. Блок " ОБРАБОТКА ЗАКАЗА НА ПОСТАВКУ".

Тип первого блока DFD — Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня и для описания реально существующих в организации потоков данных, диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами.  DFD представляет моделируемую систему как сеть связанных работ. Блок называется обработка заказа на поставку товара.  Первым шагом является построение контекстной диаграммы. В центре диаграммы находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Приёмником данных будет получение заказа от клиента, источником данных будет указание на отправку товара. Для наглядности было решено построить несколько контекстных диаграмм с иерархией. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

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

На  рисунке 2 изображена декомпозиция блока  высшего уровня на подуровни.

 

Рисунок 2. Декомпозиция блока "ОБРАБОТКА ЗАКАЗА НА ПОСТАВКУ".

При детализации должны выполняться  следующие правила:

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

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

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

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

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

Первый  блок получение заказа декомпозирован на блоки IDEF3. Он представлен на рисунке 3.

 

Рисунок 3. Декомпозиция блока "ПОЛУЧЕНИЕ ЗАКАЗА".

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

На  рисунке 4 изображена декомпозиция блока  обработка заказа.

Рисунок 4. Декомпозиция блока "ОБРАБОТКА ЗАКАЗА".

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

 

Рисунок 5. Декомпозиция блока «СКЛАД».

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

  После оплаты заказа клиентом модель завершает своё функционирование.

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

Информация о работе Разработка модели автоматизированной системы «Обработка заказов на поставку товаров»