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

Введение

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

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

Прежде чем приступить к реализации автоматизированной системы управления (АСУ), необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой ИС удобно представлять в виде диаграмм использования 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, товарно-материальные ценности, отражаемые в финансовой отчетности, как правило, классифицируются в соответствии с приведенными выше категориями («Сырье», «Незавершенное производство» и «Готовая продукция»).

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

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

---