Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

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

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

В начале 70-х гг. в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

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

Только 16% проектов завершились в срок, 52,7% завершились с опозданием, расходы превысили запланированный бюджет.

В числе причин неудач фигурируют: нечеткая и неполная формулировка требований к ПО, недостаточное вовлечение пользователей в работу над проектом, неудовлетворительное планирование и т.п.

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

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

  • рассмотрение сущности и преимуществ объектно-ориентированного подхода;
  • анализ предметной области;
  • применение объектно-ориентированного подхода при проектировании ИС.

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

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

Наиболее популярны два подхода (парадигмы) к анализу и проектированию информационных систем: структурный и объектно-ориентированный.

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

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

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

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

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

В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.

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

  • унифицированный процесс (Unified Process, UP);
  • экстремальное программирование (eXtreme Programming, XP);
  • гибкое моделирование (Agile Modeling, AM).

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

Термин «объект» или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки [6]:

  • архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);
  • объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);
  • объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);
  • теории баз данных (модели «сущность-связь»);
  • систем искусственного интеллекта (фреймы).

При разработке программного обеспечения термин «объект» впервые был введен в языке Simula 67 для моделирования сущностей предметной области.

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

Абстракция (лат. abstractio – отвлечение) – форма познания, основанная на мысленном выделении существенных свойств и связей предмета и отвлечении от других, частных его свойств и связей [5, с. 63]. При этом «существенное» и «частное» должны рассматриваться с точки зрения решаемой задачи (предметной области). В объектно-ориентированном подходе абстракция – это модель сущности, описывающая ее свойства и поведение.

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. Т. е., говоря об объекте «поезд», имеется в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а конкретный грузовой поезд с номером 1025, весом 4600 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 027, состоящий из четырехосных полувагонов с конкретными номерами и т.д.

В то же время степень абстракции с точки зрения решаемой задачи может быть и более высокой. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности в отличии друг от друга электровозов ВЛ80Т с серийными номерами 027 и 028.

Для концептуальной группировки однотипных объектов в объектно-ориентированном подходе используется понятие «класс». Класс – это  множество объектов, имеющих общую структуру и поведение [7, с.39]. Таким образом, класс – это шаблон, на основе которого генерируются (создаются) однотипные объекты. В качестве синонима понятия «объект» часто употребляют понятие «экземпляр класса».

http://ib-t.by/assets/images/1.jpg

Рисунок 1. Основные понятия ООП

Каждый класс и соответственно объект характеризуются строго определенным набором атрибутов и методов. Текущие значения атрибутов четко определяют текущее состояние объекта. Набор методов и их алгоритмическая реализация определяют поведение объекта (класса объектов).

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

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

Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

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

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

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

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

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

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

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

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

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

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

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

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

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

Анализ деятельности предприятия

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

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

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

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

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

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

reserv

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

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

ZIP

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

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

UseCase Diagram2

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


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

Реализация объектно-ориентированного подхода при проектировании ИС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ARIS UML Designer является инструментом, который позволяет бизнес- и IТ-специалистам использовать общий язык моделирования Unified Modeling Language (UML), чтобы скоординировать процесс моделирования бизнес-процессов на всех его этапах.

Многие программные проекты выходят за рамки бюджета или терпят неудачу из-за отсутствия согласованности между отделами менеджмента и IT. ARIS UML Designer является инструментом, который позволяет бизнес- и IТ-специалистам использовать общий язык моделирования Unified Modeling Language (UML), чтобы скоординировать процесс моделирования бизнес-процессов на всех его этапах. 

Преимущества ARIS UML Designer: 

  • Интеграция бизнес-процессов и UML в проектах по разработке программного обеспечения
  • Разработка эффективного программного обеспечения — быстрее и в рамках бюджета
  • Последовательный, всеобъемлющий, бизнес-ориентированный процесс разработки ПО
  • Работа над проектами, которые охватывают группы сотрудников, работающих удаленно
  • Поддержка всех UML-диаграмм

Основные возможности ARIS UML Designer:

  • Один язык для бизнес- и IT-специалистов. UML является всеобъемлющим стандартом моделирования для описания прикладных систем. Он используется для статического и динамического моделирования процессов, таких как архитектура и внутренние потоки организации. UML поддерживает диаграммы и графические символы, а также формат обмена XMI. С помощью XMI информация о модели может быть передана между различными инструментами моделирования и средами разработки. ARIS UML Designer использует язык UML, чтобы объединить работу менеджеров и разработчиков программного обеспечения.
  • Обеспечение высокого качества моделирования. ARIS UML Designer обеспечивает высокое качество моделирования в двух направлениях. Во-первых, решение позволяет создавать UML-диаграммы, используя удобные диалоговые окна. Это гарантирует высокую степень согласованности даже на начальных стадиях создания модели. Кроме того, пользователи могут автоматически создавать новые модели из существующих с помощью семантических преобразований. Во-вторых, встроенная функция online проверки соответствия определяет синтаксические и структурные ошибки моделирования
  • Централизованный репозиторий ARIS. Так как ARIS UML Designer использует тот же репозиторий, что и остальные платформы ARIS, сотрудники, специализирующиеся на UML-моделировании, могут получить доступ к необходимым данным напрямую
  • Масштабируемый web-инструмент. ARIS UML Designer идеально подходит для программных проектов, охватывающих сотрудников из разных стран. Все процессы моделирования и UML-контент доступны через web-браузер. Решение также предлагает поддержку множества языков, возможности разработки отчетов и web-публикаций для упрощения создания и распространения документов

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

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

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

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

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

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

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

UseCase Diagram

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

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

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

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

Sequence Diagram0

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

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

Communication Diagram0

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

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

Activity Diagram2

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

Проектирование базы данных

Проектирование базы данных реализовано при помощи CASE-средства ErWin версии 7.3. С его помощью сначала строится логическая модель базы данных, соответствующая структуре бизнес-процесса, который построен другим CASE-средством JUDE COMMUNITY. Логическая модель показана на рис.10.

Рисунок 10. Логическая модель

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

В сущности «Группа» от ключа «идентификационный_номер_группы» зависят атрибуты: «название», «доплнительная_информация», «идентификатор_для_авторизации», «пароль_для_авторазации», «роль_в_системе». В сущности «Резерв» от ключа «id_резерва» зависят атрибуты: «какая_группа_эксплуатирует», «количество_системных_блоков», «количество_мониторов», «количество_матричных_принтеров», «количество_лазерных_принтеров», «количество_клавиатур», «количество_мышей», «количество_хабов», «количество_сетевых_карт», «количество_патчкордов», «количество_ИБП». В сущности «Заказ» от ключа «идентификационный_номер_заказа» зависят атрибуты: «какой_ЗИП_входит», «какая_группа_заказывает», «количество», «дата_поступления_заявки», «дата_закрытия_заявки», «дополнителная_информация». В сущности «ЗИП» от ключа «идентификационный_номер_ЗИП» зависят атрибуты: «наименование», «код», «наименование_единиц_исчисления», «количество». В сущности «Техника» от ключа «id_техники» зависят атрибуты: «какая_группа_эксплуатирует», «тип_устройства», «модель», «серийный_номер», «инвентарный_номер»,» балансовая_принадлежность». В сущности «Ремонт» от ключа «id_ремонта» зависят атрибуты: «какая_техника_отправлена»,«группа_эксплуатирующая_отправленную_технику», «неисправность», «дата_отправки_с_площадки», «дата_поступления_на_площадку», «дата_отправки_в_ремонт», «дата_получения_из_ремонта», «результат_ремонта», «эксплуатация».

Отношения между сущностями «Группа» и «Резерв», «Группа» и «Заказ», «Группа» и «Техника», «Техника» и «Ремонт», «ЗИП» и «Заказ» представляют собой связи один ко многим.

Физическая модель базы создается по логической модели при помощи того же ErWin. Так как физическая модель зависит от используемой СУБД, то СУБД указывается перед построением.

Физическая модель базы данных, для разрабатываемого АРМа, спроектированная под MS SQL Server 10.5 (2008), показана на рис.11.

Рисунок 11. Физическая модель

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

По физической модели автоматически построена схема данных для MS SQL Server. Схема показана на рис.12.

Рисунок 12. Схема данных

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

Заключение

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

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

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

      1. Варфоломеева Е.В. Информационные системы в экономике: Учебное пособие / Е.В. Варфоломеева, Т.В. Воропаева и др.; Под ред. Д.В. Чистова - М.: НИЦ ИНФРА-М, 2015. - 234 с.
      2. Вдовенко Л.А. Информационная система предприятия: Учебное пособие/Вдовенко Л. А. - 2 изд., перераб. и доп. - М.: Вузовский учебник, НИЦ ИНФРА-М, 2015. - 304 с.
      3. Гвоздева В.А. Базовые и прикладные информационные технологии: Учебник / Гвоздева В. А. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2015. - 384 с.
  1. Гвоздева В.А. Информатика, автоматизированные информационные технологии и системы: Учебник / В.А. Гвоздева. - М.: ИД ФОРУМ: НИЦ ИНФРА-М, 2015. - 544 с.
  2. Душин, В.К. Теоретические основы информационных процессов и систем : учебник / В.К. Душин .— 5-е изд. — М. : ИТК "Дашков и К", 2014 .— 348с.
  3. Жук А.П. Защита информации: Учебное пособие / А.П. Жук, Е.П. Жук, О.М. Лепешкин, А.И. Тимошкин. - 2-e изд. - М.: ИЦ РИОР: НИЦ ИНФРА-М, 2015. - 392 с.
  4. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. - М.: ИНФРА-М, 2011. - 331 с.
  5. Затонский А.В. Информационные технологии: разработка информационных моделей и систем: Учеб. пос. / А.В.Затонский - М.: ИЦ РИОР: НИЦ ИНФРА-М, 2014 - 344с.
  6. Информационные системы в экономике: Учебник / К.В. Балдин, В.Б. Уткин. - 7-e изд. - М.: Дашков и К, 2012. - 395 с.
  7. Карминский А.М. Методология создания информационных систем: Учебное пособие / А.М. Карминский, Б.В. Черников. - 2-e изд., перераб. и доп. - М.: ИД ФОРУМ: ИНФРА-М, 2012. - 320 с.
  8. Коваленко В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум: НИЦ ИНФРА-М, 2014. - 320 с.
  9. Немцова Т.И. Практикум по информатике: Уч. пос.Ч. 1. / Т.И. Немцова, Ю.В. Назарова; Под ред. Л.Г. Гагариной. - М.: ИД ФОРУМ: ИНФРА-М, 2011. - 320 с.
  10. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум: НИЦ ИНФРА-М, 2014.-432с.
  11. Федотова Е. Информационные технологии и системы: Учебное пособие / Е.Л. Федотова. - М.: ИД ФОРУМ: НИЦ ИНФРА-М, 2014. - 352 с
  12. Федотова Е.Л. Информационные технологии в профессиональной деятельности: Учебное пособие / Е.Л. Федотова. - М.: ИД ФОРУМ: НИЦ ИНФРА-М, 2015. - 368 с.
  13. Черников Б.В. Информационные технологии управления: Учебник / Б.В. Черников. - 2-e изд., перераб. и доп. - М.: ИД ФОРУМ: НИЦ ИНФРА-М, 2014. - 368 с.
  14. Шишов О.В. Современные технологии и технические средства информатизации: Учебник / О.В. Шишов. - М.: НИЦ Инфра-М, 2012. - 462 с.
  1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010