Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы (Use case diagram (диаграммы прецедентов))

Содержание:

Введение

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

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

Прежде чем приступить к реализации автоматизированной системы управления (АСУ), необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой ИС удобно представлять в виде диаграмм использования UML (унифицированный язык моделирования). При разработке данного проекта использовался UML и Rational Rose – мощное CASE – средство, помогающее строить модели систем.

При написании данной работы была поставлена цель – спроектировать и разработать информационную систему для автоматизации учета товарно-материальных ценностей. Информационная система должна быть удобной для пользователя, обладать «дружелюбным» интерфейсом.

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

Объект исследования – информационная система учета материальных ценностей.

Предмет исследования – процесс моделирования предметной области.

Теоретические основы моделирования с помощью UML

Унифицированный язык моделирования UML

Процесс разработки структуры информационных систем в соответствии с требованиями пользователей называется проектированием информационных систем. Основные цели проектирования информационных систем заключаются в том, чтобы обеспечить пользователей точными наборами данных, необходимыми им для исполнения своих служебных обязанностей, а также в том, чтобы обеспечить доступ к данным за приемлемое время^[1].

При проектировании информационных систем используется определенная методология, то есть совокупность средств и инструментов, применяемых для последовательной разработки проекта структуры информационных систем. Надо отметить, что методология проектирования информационных систем обладает следующими свойствами^[2]:

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

Проектирование информационных систем включает в себя следующие этапы^[3]:

• Определение предметной области.
• Анализ и описание функций системы средствами UML.
• Проработка требования к БД.
• Проектирование БД.
• Реализация автоматизированной системы управления.

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

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

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

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

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

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

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

Потребность в качестве процесса разработки обуславливает необходимость создания стандартных условных обозначений. Язык UML представляет собой именно такую систему обозначений.

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х – начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML полезен для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться.

Описание UML диаграмм в Rational Rose

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов, а с 1997 года является стандартом OMG в области визуального объектно-ориентированного моделирования и широко используется на практике, будучи реализован в рамках многих CASE-средств^[4].

Rational Rose – мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах^[5]:

Use case diagram (диаграммы прецедентов);

Activity diagram (диаграммы активности);

Sequence diagram (диаграммы последовательностей действий);

Use case diagram (диаграммы прецедентов)

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

Activity diagram (диаграммы активности)

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

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

Sequence diagram (диаграммы последовательностей действий)

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Описание предметной области

Товарно-материальными ценностями считаются активы, которые:

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

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

Согласно IAS, товарно-материальные ценности, отражаемые в финансовой отчетности, как правило, классифицируются в соответствии с приведенными выше категориями («Сырье», «Незавершенное производство» и «Готовая продукция»).

Материальные ценности на предприятии хранятся в специально отведенных для этого местах (складах, хранилищах, подсобных помещениях и т.п.). За хранимые ценности отвечает материально ответственное лицо.

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

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

1. Виды ценностей – хранит информацию о виде материальной ценности.

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

1. Местоположение – хранит информацию о месте хранения ценности.

Место хранения – сущность, определяющая место хранения ценностей. Характеризуется названием (например, склад, спецхран и т.п.).

1. Хранение – дополнительные сведения о хранимой матценности. Содержит информацию о хранении материальных ценностей и характеризуется следующими атрибутами:

• вид ценности,
• место хранения,
• краткое описание (примечание),
• дата постановки на учет.

1. Построение абстрактной модели системы на основе языка UML

Рассмотрим процесс моделирования архитектуры и поведения системы при помощи языка UML.

Диаграмма вариантов использования (Use Case diagram)

Use case diagram (диаграмма вариантов использования) – диаграмма, на которой отражены отношения вариантов взаимодействия компонентов системы. Каждый вариант использования представляет собой некоторое действие которое выполняет система в ответ на какие-то воздействия, которые оказывает внешний объект (таким объектом может быть пользователь). Таким образом, получается, что диаграмма Use Case описывает взаимодействия пользователя с системой.

Система должна обеспечить возможность добавления, удаления и корректировки записей всех трех таблиц. Следовательно, должны присутствовать варианты использования: «Добавить вид ценностей», «Добавить место хранения», «Добавить сведения о ценности» и т.д.

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

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

Диаграмма последовательностей (Sequence diagram)

Sequence diagram (диаграмма последовательностей) – диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Описание системы на основе диаграмм последовательностей предполагают исследование системы с точки зрения того, как взаимодействуют между собой её отдельные элементы в рамках одного варианта использования (Use Case). Каждый вариант использования можно рассматривать в виде взаимодействия компонентов системы. Таким образом, получается, что компоненты системы могут вызывать друг друга и вызывать сами себя. Описание взаимодействия средствами языка UML сводится к построению диаграммы последовательностей.

Построим диаграмму последовательностей для варианта использования (рис.2):

Рис.2. Диаграмма последовательностей (преобразование сущностей между слоями приложения)

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

Структурные диаграммы

Структурные диаграммы (Structure Diagrams) – это диаграммы описывающие систему как набор элементов, а так же взаимодействия между этими элементами.

Диаграмма развертывания (Deployment diagram)

Deployment diagram (диаграмма развертывания) – один из видов структурных диаграмм рассматривающих систему с позиции её аппаратного обеспечения. На диаграммах развертывания можно увидеть, какие аппаратные средства используются в системе и как они между собой взаимосвязаны. Диаграмма развертывания для проектируемой системы будет иметь следующий вид (рис.3):

Рис.3. Диаграмма развертывания для проектируемой системы

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

Диаграмма компонентов (Component diagram)

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

Рис.4. Диаграмма компонентов для проектируемой системы

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

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

Диаграммы классов создаются при логическом моделировании ПС и служат для следующих целей:

• Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
• Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС.
• Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
• Для моделирования логики программных компонент.
• Для моделирования логики обработки данных.

Диаграмма классов для проектируемой системы представлена на рис.5.

Рис.5. Диаграмма классов сервера

Заключение

Главной целью работы было моделирование учета материальных ценостей. Для разработки данной системы был использован унифицированный язык моделирования UML и Rational Rose – case– средство, помогающее строить модели UML.

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

Разработанный АРМ позволяет существенно упростить учет материальных ценностей на предприятии.

Список использованной литературы

1. Введение в системы баз данных – СПб: Издательский дом «Вильямс», 2010. - 848с.
2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. // М.: «Финансы и статистика», 2011.
3. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
4. Информационные системы: Учебник для вузов. 2-е изд. СПб: «Питер», 2010. - 656с.
5. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2009.
6. Кендалл Скотт, Мартин Фаулер - UML. Основы. 192 стр., 2006 г. Издательство: Символ. Серия: Основы. ISBN 5-93286-060-X.
7. Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.
8. Лебедева Н.В., Бычкова С.М. Методы оценки товарно-материальных ценностей - Бухгалтерский учет, 1997 спецвыпуск - с.109-110.
9. Разработка программного обеспечения - СПб: «Питер», 2010. - 592с.
10. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2011 – 400с.
11. Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.

1. Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008. ↑

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010 ↑

3. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006. ↑

4. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006. ↑

5. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010 ↑