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

Содержание:

Введение

Руководители многих средних и крупных коммерческих организаций на различных этапах своей работы сталкиваются с характерными проблемами:

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

Система управления недостаточно структурирована, происходит «размывание» ответственности между множеством сотрудников компании;

Каждый сотрудник компании работает много, жалуется на перегруз, вместе с тем результаты работы компании не соответствуют ожиданиям;

Штат высокооплачиваемых руководителей подразделений раздут, несмотря на это решения исполняются медленно, компания приобретает неповоротливость, «забюрократизованность»;

Компания постепенно слабо увеличивает или вовсе теряет долю рынка в обостряющейся конкурентной борьбе с более «подвижными» организациями;

Смена и ротация кадров в малой степени решает вышеназванные проблемы.

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

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

Этапы решения поставленной цели:

• Изучить понятие объектно-ориентированного подхода
• Изучить преимущества объектно-ориентированного подхода
• Изучить программы для моделирования бизнес-процессов

Обзор источников.

Семейство стандартов ИСО 9000, перечисленных ниже, было разработано для того, чтобы помочь организациям всех видов и размеров внедрять и обеспечивать функционирование эффективных систем менеджмента качества:

ГОСТ Р ИСО 9000-2001 описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества;

ГОСТ Р ИСО 9001-2001 определяет требования к системам менеджмента качества для тех случаев, когда организации необходимо продемонстрировать свою способность предоставлять продукцию, отвечающую требованиям потребителей и установленным к ней обязательным требованиям, и направлен на повышение удовлетворенности потребителей;

CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.

Приводимые в статье рекомендации могут способствовать успешному внедрению CASE-средств и уменьшить риск неправильных инвестиций.

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

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

Богатин, Ю.В. Экономическое управление бизнесом: учебное пособие для вузов / Ю.В. Богатин, В.А. Швандар. – М.

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

Валдайцев, С.В. Управление инновационным бизнесом: учебное пособие / С.В. Валдайцев. – М.: Юнити_Дана, 2001. 343 с.

Рассматриваются вопросы, касающиеся извлечения прибыли и создания новых технологий и результатов прикладных научно-исследовательских и опытно-конструкторских (проектно-технологических) работ. Подробно освещаются различные формы коммерциализации новых технологий, возможности продажи последних и организации освоения новшеств собственными силами. Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012

Учебное пособие содержит: краткое изложение языка UML — той его части, которая может быть использована как основа языка моделирования сложных динамических систем; описание и возможности предлагаемого ав- торами нового языка моделирования на базе гибридных автоматов, являю- щегося расширением UML; исторический обзор и примеры различных под- ходов к конструированию инструментов моделирования; объектно- ориентированный анализ сложных динамических систем. Книга является второй из трех книг, объединенных общим названием МОДЕЛИРОВАНИЕ СИСТЕМ.

Объектно-ориентированный подход в менеджменте качества - Копнов В.А.

В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн

Глава 1. Понятие и принципы объектно-ориентированного подхода.

Объектно-ориентированный подход - в его основе лежит объектная декомпозиция, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. [Богатин, Ю.В. Экономическое управление бизнесом: учебное пособие для вузов / Ю.В. Богатин, В.А. Швандар. – М.:Юнити_Дана, 2001. – 91 с].

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

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

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

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

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

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

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

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

•типизация (typing);

•параллелизм (concurrency);

•устойчивость (persistence).

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

Сущностью объектно-ориентированного подхода является оптимизация системы корпоративного управления, обеспечение ее прозрачности для руководства, способности гибко реагировать на изменения внешней среды[Валдайцев, С.В. Управление инновационным бизнесом: учебное пособие / С.В. Валдайцев. – М.: Юнити_Дана, 2001. 43 с].

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

Описание подхода

При объектно-ориентированном подходе программа представляет собой описание объектов, их свойств (или атрибутов ), совокупностей (или классов ), отношений между ними, способов их взаимодействия и операций над объектами (или методов ).

Несомненным преимуществом данного подхода является концептуальная близость к предметной области произвольной структуры и назначения. Механизм наследования атрибутов и методов позволяет строить производные понятия на основе базовых и таким образом создавать модель сколь угодно сложной предметной области с заданными свойствами[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

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

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

Объекты, классы и методы могут быть полиморфными, что делает реализованное программное обеспечение более гибким и универсальным[Копнов В.А.Объектно-ориентированный подход в менеджменте качества].

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

Наиболее известным примером объектно-ориентированного языка программирования является язык C++, развившийся из императивного языка С. Другие примеры объектно-ориентированных языков программирования: Visual Basic, Java, Eiffel, Oberon.

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

При этом, в отличие от предыдущих подходов к программированию, объектно-ориентированный подход требует глубокого понимания основных принципов, или, иначе, концепций, на которых он базируется. К числу основополагающих понятий ООП обычно относят абстракцию данных, наследование, инкапсуляцию и полиморфизм[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Инкапсуляция означает "сокрытие" свойств и методов внутри объекта.

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

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

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

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

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

Отличия объектно-ориентированного подхода от структурного:

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

При использовании структурного подхода (первый вид декомпозиции), выполняется функциональная (процедурная, алгоритмическая) декомпозиция системы. Т. е. она представляется в виде иерархии (дерева) взаимосвязанных функций. На высшем уровне система представляется единым целым с наивысшей степенью абстракции и по мере детализации (добавления уровней) разбивается на функциональные компоненты с более конкретным содержанием[Копнов В.А.Объектно-ориентированный подход в менеджменте качества]..

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

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

Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. part-of – часть-целое), т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Глава 2. Объектно-ориентированные case-средства (Rational Rose)

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

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

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX)[ CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.].

Вывод: В результате работы над данной главой были изучены , CASE-технологии, реализующие объектно-ориентированный подход и их использование.

Моделирование предметной области «Управление заявками на техническое обслуживание»

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

Обслуживающая организация ООО «Сервисный центр» образовалась в 2012 году. Компания предоставляет клиентам широкий спектр услуг по ремонту и техническому обслуживанию техники

- Создание комплексных информационных систем;

- Обслуживание парка ПК;

- Продажа программного обеспечения;

- Проектирование и монтаж локальных сетей;

- Информационная защита данных;

- Разработка фирменного стиля.

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

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

Любая деятельность компании ООО «Сервисный центр» сопровождается соответствующей документацией, что отражается в АИС «Управление обслуживающей организации», что дает возможность оперативно получать информацию различного характера[Валдайцев, С.В. Управление инновационным бизнесом: учебное пособие / С.В. Валдайцев. – М.: Юнити_Дана, 2001. 343 с.].

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

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

следующие проблемы:

- В системе отсутствует функция оперативного оповещения сотрудников и руководителя о «горящей» или даже просроченной заявки.

Сотрудник видит все свои заявки, но без напоминания может пропустить срок их исполнения;

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

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

Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы службы техподдержки за определенный период, что очень затруднительно[Богатин, Ю.В. Экономическое управление бизнесом: учебное пособие для вузов / Ю.В. Богатин, В.А. Швандар. – М].

Диаграмма прецедентов

Перед построением диаграммы прецедентов (рис. 1) составим таблицу распределения требований по субъектам и прецедентам:

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

Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.

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

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

Прецеденты считаются важной частью языка UML. Однако удивительно то, что определение прецедентов в UML довольно скудное. В UML ничего не говорится о том, как определять содержимое прецедента. Все, что описано в UML, – это диаграмма прецедентов, которая показывает, как прецеденты связаны друг с другом. Но почти вся ценность прецедентов как раз в их содержании, а диаграмма имеет ограниченное значение[ В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

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

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

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

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

подготовка документации для взаимодействия с заказчиками и пользователями системы[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

Рис. 1 Диаграмма прецедентов

Диаграмма деятельности

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

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

Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.

Состояние действия

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

Графически состояние действия изображается прямоугольником с закругленными углами Внутри этого изображения записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами. Если же действие может быть представлено в некотором формальном виде, то целесообразно записать его на том языке программирования, на котором предполагается реализовывать конкретный проект[CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.].

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

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

Данная диаграмма описывает поток событий, происходящий в системе при выполнении клиентом запроса на оформление заявки.

При приеме техники на обслуживание и ремонт сначала определяется, подлежит ли техника ремонту , если нет, то клиент получает отказ, затем определяется список необходимых запчастей и их стоимость, если клиента она устраивает, то заполняется заявка на ремонт, в противном случае клиент отказывается от обслуживания[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

Рис. 2 Диаграмма деятельности системы

Диаграмма последовательности системы

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

Данная диаграмма описывает последовательность во времени событий, происходящих в системе при выполнении клиентом запроса на оформление заявки[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

Рис.3. диаграмма последовательности

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

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

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

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

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая сущность по запросу актера, то есть определяет способ применения этой сущности. Сервис, который инициализируется по запросу актера, представляет собой законченную неделимую последовательность действий. Это означает, что после того как система закончит обработку запроса, она должна возвратиться в исходное состояние, чтобы быть готовой к выполнению следующих запросов[CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М].

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

Для создания модели взаимодействий сначала определим действующих лиц или актеров.

Для приложения действующими лицами будут Приемщик, Клиент, Бухгалтер.

Варианты работы Сервисного центра (см. рис. 3): 1) Принять технику – Приемщик принимает у клиента технику в ремонт. 2) Определение неисправности – Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти 3)Проверить наличие запчастей –проверка наличия на складе нужных запчастей, определение недостающего количества 4) Заказ запчастей – заказ необходимого количества запчастей и расходных материалов; 5) Оформление заявки - оформление заявки на техническое обслуживание.

Определим начальное и конечное события для каждого варианта использования: 1) Принять технику– Начальное событие - Приемщик принимает у клиента технику в ремонт. Конечное событие – Определение неисправности 2) Определение неисправности – Начальное событие - Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти; Конечные события – если техника подлежит ремонту – определение запчастей, если нет – отказ; 3) Проверить наличие запчастей –Начальное событие - проверка наличия на складе нужных запчастей, конечное событие - заказ запчастей; 4) Заказ запчастей – начальное событие - заказ необходимых запчастей, конечное событие - получение запчастей; 5) Оформление заявки – начальное событие – согласование стоимости ремонта – конечное событие – оформление заявки[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

Диаграмма состояний

Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

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

Система может находиться в состояниях: Подлежит ремонту (техника подлежит ремонту), Ремонту не подлежит (Отказ в обслуживании0, Проверить наличие запчастей (Проверка наличия запчастей и расходных материалов), Оформить заявку (Оформление заявки)[ Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

Рис. 5 Диаграмма состояний

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

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

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

Классы

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

Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов или одной диаграммой. Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные без пробелов. Имена классов образуют словарь предметной области[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

Именами классов могут быть такие существительные, как «Сотрудник», «Компания, «Руководитель», «Клиент», «Продавец», «Менеджер», «Офис» и другие, имеющие непосредственное отношение к моделируемой предметной области и функциональному назначению проектируемой системы.

Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется курсив. В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Данное обстоятельство является семантическим аспектом описания соответствующих элементов языка UML[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

Если необходимо явно указать к какому пакету относится тот или иной класс, то используется символ разделитель двойное двоеточие «::». Синтаксис строки имени класса в этом случае будет следующий: <Имя_пакета>::<Имя_класса>. Например, если определен пакет с именем «Банк», то класс «Счет» в этом банке может быть записан в виде: «Банк::Счет».

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:

• «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;
• «#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;
• «-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения атрибута[CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.].

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

[нижняя_граница1 .. верхняя_граница1, нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak .. верхняя_границаk], 

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

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

Тип атрибута представляет собой выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс[Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012].

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

• Клиент
• Вид техники
• Техника
• Заявка
• Неисправности
• Материалы
• Запчасти
• Расходные материалы

Теперь необходимо провести организацию классов при помощи наследования путем выявления их общей структуры. На рис. 6 показана модель классов системы после добавления наследования[В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн].

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

Вывод: С помощью применения процессного подхода был выполнен анализ работы конкретной организации.

Заключение

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

Были решены следующие задачи:

• Изучить понятие объектно-ориентированного подхода
• Изучить преимущества объектно-ориентированного подхода
• Изучить программы для моделирования бизнес-процессов

Список литературы

1. ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь.
2. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования.
3. Yogesh M. Business Process Redesign: An Overview // IEEE Engineering Management Re-view. 1998. Vol. 26. No. 3. http://www.kmbook.com/bpr.htm
4. Богатин, Ю.В. Экономическое управление бизнесом: учебное пособие для вузов / Ю.В. Богатин, В.А. Швандар. – М.:Юнити_Дана, 2001. – 391 с.
5. В.В. Мухортов, В.Ю. Рылов - Объектно-Ориентированное Программирование, Анализ и Дизайн.
6. Валдайцев, С.В. Управление инновационным бизнесом: учебное пособие / С.В. Валдайцев. – М.: Юнити_Дана, 2001. 343 с.
7. Колесов Ю. Б. Сениченко Ю. Б. «Моделирование систем. Объектно-ориентированный подход», Санкт-Петербург, БХВ-Петербург, 2012
8. CASE-технологии. Современные методы и средства проектирования информационных систем / Вендров А.М.
9. Копнов В.А.Объектно-ориентированный подход в менеджменте качества