Применение объектно ориентированного подхода при проектировании информационной системы

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объектом исследования данной работы является объектно-ориентированный подход к проектированию информационных систем. Предметом исследования является унифицированный язык моделирования.
Цель данной работы является обзор и анализ основных принципов и особенностей объектно-ориентированного подхода, а также его неотъемлемого инструмента унифицированного языка моделирования (UML).

В ходе выполнения работы были решены следующие задачи:

• Обзор основных понятий и концепций объектно-ориентированного подхода;
• Анализ унифицированного процесса разработки информационных систем;
• Обзор основных структур унифицированного языка моделирования;
• Обзор основных понятий унифицированного языка моделирования;

Использование объектно-ориентированного подхода на примере.

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

Сущность объектно-ориентированного подхода

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

Наиболее популярными методологиями, поддерживающими объектно-ориентированный подход, в настоящий момент являются:

унифицированный процесс (Unified Process, UP);

экстремальное программирование (eXtreme Programming, XP);

гибкое моделирование (Agile Modeling, AM).

Базовым средством фиксации (документирования) результатов проектирования систем посредством этих методологий является унифицированный язык моделирования (Unified Modeling Language, UML).

Объектная модель является наиболее естественным способом представления реального мира.

Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula (1967), Smalltalk (1970-е гг.), C++ (1980-е гг.) и языком моделирования UML (1990-е гг.). На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования данных, в особенности модель «сущность—связь».

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

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными принципами ее построения:

• инкапсуляция (encapsulation);

• наследование (inheritance);

• полиморфизм (polymorphism);

• абстрагирование (abstraction);

• модульность (modularity);

• иерархия (hierarchy).

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

Наследование (inheritance) — метод определения объектов, при котором производные объекты (потомки) наследуют свойства (атрибуты и действия) от своих родителей. Наследование свойств в объектно- ориентированном подходе понимается как наследование атрибутов и методов, т. е. возможность использования в производном объекте атрибутов и методов базового объекта.

Полиморфизм (polymorphism) — свойство объектов, при котором действие с одинаковыми именами вызывает различное поведение для различных объектов. Полиморфизм предполагает возможность одинакового именования разных действий. Эта особенность имеет два аспекта:

• возможность одинакового именования статических методов;

• возможность одинакового именования динамических методов

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

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

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

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

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

Модульность (modularity) — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне сильно сцепленных, но слабо связанных между собой подсистем (модулей). Модульность снижает сложность системы, позволяя выполнять независимую разработку отдельных модулей. Инкапсуляция и модульность создают барьеры между абстракциями.

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

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

Проблемы, стимулировавшие развитие ООП:

• необходимость повышения производительности разработки за счет многократного (повторного) использования ПО;

• необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений);

• облегчение проектирования систем (за счет сокращения семантического разрыва между структурой решаемых задач и структурой ПО).

1.2. Преимущества и недостатки объектно-ориентированного подхода

Объектно-ориентированный подход имеет ряд следующих преимуществ:

• 1. Описание системы в виде объектов больше соответствует содержательному смыслу предметной области. Например, при использовании структурного подхода БД должна удовлетворять требованиям нормализации, в соответствии с которыми данные по одному и тому же объекту (сущности из реального мира) могут храниться в нескольких таблицах;
  2. Сущности реального мира, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;
  3. Объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Это облегчает решение проблем:

адаптации системы к изменению существующих или появлению новых требований;

сопровождения системы на разных стадиях жизненного цикла;

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

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

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

К недостаткам объектно-ориентированного подхода относятся:

Усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области и для которых невозможно найти человека, понимающего эту предметную область в целом, также требует использования традиционных подходов в виду их большей доступности для неспециалистов;

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

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ (UML) – КАК СРЕДСТВО ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОНЫХ СИСТЕМ

• 1. Унифицированный процесс разработки информационных систем

Унифицированный процесс должен быть: управляемый вариантами использования, архитектурно-ориентированный, итеративный и инкрементный.

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

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

Унифицированный процесс – ориентирован на архитектуру. Архитектура - это представление всего проекта с выделением ключевых

составляющих и затушевывание деталей. Архитектура вырастает из

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

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

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

Архитектура и варианты использования разрабатываются параллельно. Архитектор выполняет следующие работы:

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

Архитектура определяется в виде представлений всех моделей системы, объединенных (сконфигурированных) в систему.

Существуют архитектурные представления модели вариантов использования, модели анализа, модели проектирования, модели развертывания.

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

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

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

Задачи, которые образуют итерации, выбираются под воздействием двух факторов:

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

Достоинства управляемого итеративного процесса (в управлении рисками):

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

2. Управляемая итерация снижает риски не поставки продукта заказчику в запланированные сроки.

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

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

• 1. Структура и основные понятия унифицированного языка моделирования (UML)

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

Язык UML основан на некотором числе базовых понятий, которые могут быть изучены и применены большинством программистов и разработчиков, знакомых с методами объектно-ориентированного анализа и проектирования (ООАП). При этом базовые понятия могут комбинироваться и расширяться таким образом, что специалисты объектного моделирования получают возможность самостоятельно разрабатывать модели больших и сложных систем в самых различных областях приложений.

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

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

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

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

Семантика языка UML представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

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

Формальное описание самого языка UML основывается на некоторой общей иерархической структуре модельных представлений, имеющей четыре уровня: метаметамодель; метамодель; модель; объекты пользователя.

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

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

Метамоделъ является экземпляром или конкретизацией метаметамодели. Главная задача этого уровня — определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия языка UML — это понятия уровня метамодели. Примеры таких понятий: класс, атрибут, операция, компонент, ассоциация и многие другие.

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

Конкретизация понятий модели происходит на уровне объектов пользователя. В настоящем контексте объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: “Илья Петров, 18 лет, программист, ул. Пионерская, д. 5, к. 1, кв. 23, тел. 123-45-67”.

3. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ

3.1 Характеристика предприятия

Основной деятельностью компании ОАО «РЖД» является предоставление транспортных услуг. Для обеспечения постоянной и бесперебойной работы организации используется большое количество компьютерного оборудования. Обслуживание компьютерной техники производит отдельный филиал – Главный Вычислительный Центр. Так как территория, которую обслуживает компания, покрывает всю территорию Российской Федерации, для улучшения управляемости филиал разделен на структурные подразделения – информационно-вычислительные центры каждой дороги, в частности, Октябрьскую Железную дорогу обслуживает Санкт-Петербургский Информационно-Вычислительный Центр, который на территории данной зоны ответственности производит полное обслуживание всего комплекса вычислительных систем, сетей и программного обеспечения.

В каждом вычислительном центре существуют Региональные Вычислительные Центры (РВЦ), делящие всю территорию на более мелкие участки. Они занимаются поддержкой пользователей по вопросам, связанным технической работоспособностью вычислительных систем, то есть: либо мелким ремонтом на месте, либо при серьезных неисправностях- отправкой техники в отдел, занимающийся ремонтом (отдел РПО). В отделе РВЦ есть инженер, который занимается снабжением всех удаленных площадок (удаленные площадки (группы) требуются в связи с большой территорией обслуживания) резервом вычислительной техники, всеми необходимыми расходными материалами, а также доставкой из/в ремонт неисправной аппаратуры и ее дальнейшей передачей в отдел РПО для ремонта. Резерв техники необходим для предоставления подмены на оперативных рабочих местах (в основном связанных с безопасностью движения (в соответствии с регламентом)) в случаях невозможности ремонта на месте или невозможности устранения неисправности на месте в установленный срок.

3.2. Обоснование необходимости проектирование ИС

Исходя из вышеописанного, необходимо разработать «АРМ инженера по снабжению», который будет реализовывать взаимодействие между инженером по снабжению и руководителями площадок (групп). Взаимодействие заключается в следующем.

На каждой площадке должен быть оперативный резерв вычислительной техники и комплектующих - значит необходимо спроектировать модуль, с помощью которого можно будет оперативно, в реальном времени отслеживать наличие резерва. Наличие должно отслеживаться по каждой площадке отдельно и по категориям техники (системные блоки, мониторы, принтеры лазерные, принтеры матричные и т. д.). Диаграмма представлена на рис 1.

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

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

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

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

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

Дополнительные требования к АРМу: разграничение уровней доступа (в частности руководитель площадки должен иметь права на регистрацию и просмотр заявок, а инженер по снабжению права на закрытие заявок и т.п.).

4. РЕАЛИЗАЦИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕКТИРОВАНИИ ИС

4.1 Выбор средств объектно-ориентированного подхода

UML (Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна генерация исходного кода.

Для проектирования UML диаграмм приложения использовалось CASE-средство (от Computer Aided Software/System Engineering) Jude Community. Case–средства позволяют моделировать бизнес процессы, компоненты программного обеспечения, структуру и деятельность организаций. Использование CASE-средств оптимизирует эффективность проектирования, снижает вероятность расходы и вероятности ошибок.

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

Преимущества от использования:

• унифицированное средство общения между разработчиками;
• ускорение разработки;
• увеличение продуктивности.

Поскольку проектируемый АРМ будет состоять из программного приложения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производится специализированным case-средством с возможностью генерации исходного кода – ER Win.

4.2. Результаты применения объектно-ориентированного подхода

Диаграмма вариантов использования (Use case diagram) позволяет сделать анализ бизнес-процессов, отображая приложение в статическом состоянии. В диаграмме описываются только функции, выполняемые актерами. Актером является пользователь, выполняющий определенную роль в системе.

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

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

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams).

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

Рис.5. Диаграмма последовательности: составление заявки на ЗИП

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

Рис. 6. Диаграмма сотрудничества

Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции, причем предоставляют для этого больше возможностей, чем "классическая" блок-схема. Диаграммы деятельности описывают переход от одной деятельности к другой, в отличие от диаграмм взаимодействия, где акцент делается на переходах потока управления от объекта к объекту. На рисунке 7 показан данный вид диаграммы.

Рис. 7. Диаграмма активности

ЗАЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Введение в системы баз данных – СПб: Издательский дом "Вильямс", 200. - 848 с.;
2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. // М.: «Финансы и статистика», 2011.
3. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 2009.
4. Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.
5. Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2006. 450 – 490 с.
6. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
7. Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2010. - 656 стр.
8. Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.
9. Разработка программного обеспечения - СПб : "Питер", 20100. - 592 стр.
10. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2011 – 400с.:ил;
11. Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.
12. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru
13. UML спецификация. –main.tpkelbook.com