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

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

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

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

Преимущества объектной модели

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

1. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных словно программирование. Страуструп отмечает: "Не всегда очевидно, как в полной мере использовать преимущества такого языка, как С++. Существенно повысить эффективность и качество кода можно просто за счет использования С++ в качестве "улучшившего С" с элементами абстракции данных. Однако намного более значительным достижением является введение иерархии классов в процессе проектирования. Именно это называется объектно-ориентированным проектированием и именно здесь преимущества С++ демонстрируются наилучшим образом". Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, С++, CLOS и Аdа, вне объектной модели, их наиболее сильные бока или игнорируются, или применяются неправильно.
2. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что, в конечном итоге, ведет к созданию среды разработки. Объектно-ориентированные системы часто выходят более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта, за счет использования предыдущих разработок, которое дает выигрыш в стоимости и времени
3. Использование объектной модели приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений. Это дает системе возможность развиваться постепенно и не приводит к полной ее переработке даже в случае существенных змей исходных требований.
4. Объектная модель уменьшает риск разработки сложных систем, в первую очередь потому, что процесс интеграции растягивается на все время разработки, а не превращается в одноразовое событие, Объектный подход состоит из ряда хорошо продуманных этапов проектирования, которое также уменьшает степень риска и повышает уверенность в правильности принятых решений.
5. Объектная модель ориентирована на человеческое восприятие мира, или, по словам Робсона, "много из людей, которые не имеют понятие о том, как работает компьютер, находят полностью естественным объектно-ориентированный подход к системам".

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

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

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

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

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

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

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

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

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

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

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

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

Иерархия - это ранжированная или упорядоченная система абстракций, расположение их по уровням.

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дискриминатор - это атрибут типа "перечисление", показывающий, по какому из свойств объектов сделано данное обобщение.

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

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

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

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

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

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

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

Иногда в подклассе бывает необходимо переопределить операцию, определенную в одном из его суперклассов. Для этого операция, которая может быть получена из суперкласса в результате наследования, определяется и в подклассе; это ее повторное определение "заслоняет" ее определение в суперклассе, так что в подклассе применяется не унаследованная, а переопределенная в нем операция. Напомним, что каждая операция определяется своей сигнатурой; следовательно, сигнатура переопределения операции должна совпадать с сигнатурой операции из суперкласса, которая переопределяется данной операцией.

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

расширение: новая операция расширяет унаследованную операцию, учитывая влияние атрибутов подкласса;

ограничение: новая операция ограничивается выполнением лишь части действий унаследованной операции, используя специфику объектов подкласса;

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

удобство.

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

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

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

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

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

унаследованные операции можно уточнять, добавляя дополнительные действия.

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

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

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

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

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

Актеры – это роли, исполняемые сущностями, непосредственно взаимодействующими с системой.

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

Мне очень понравилось описание понятия «актер» в работе Джима Арлоу и Айла Нейштадта «UML 2 и Унифицированный процесс»: «Для понимания актеров важно понимать концепцию ролей. Роль можно рассматривать как шляпу, которую надевают в определенной ситуации.» (стр 92).

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

Построение объектной модели

Определение классов

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

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

избыточные классы: если два или несколько классов выражают одинаковую информацию, следует сохранить только один из них;

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

нечетко определенные (с точки зрения рассматриваемой проблемы) классы;

атрибуты: некоторым существительным больше соответствуют не классы, а атрибуты; такие существительные, как правило, описывают свойства объектов (например, имя, возраст, вес, адрес и т.п.);

операции: некоторым существительным больше соответствуют не классы, а имена операций (например, телефонный_вызов вряд ли означает какой-либо класс);

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

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

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

Подготовка словаря данных

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

2.3. Определение зависимостей

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

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

Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:

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

нерелевантные зависимости и зависимости, связанные с реализацией, должны быть исключены;

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

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

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

Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:

неверно названные зависимости: их следует переименовать, чтобы смысл их стал понятен;

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

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

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

неучтенные зависимости должны быть выявлены и добавлены в модель.

2.4. Уточнение атрибутов

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

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

Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).

При уточнении атрибутов руководствуются следующими критериями:

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

Квалификаторы. Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором.

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

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

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

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

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

2.5. Выделение подсистем

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

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

и т.д.................

ТЕМА 4: Методология моделирования бизнес-процессов

1.Сущность моделирования и классификация моделей в реинжиниринге

Основные требования к построению моделей бизнес-процессов в компании

Методика построения прецедентной модели

Методика построения объектной модели

Вопрос 1

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

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

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

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

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

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

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

Вопрос 2

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

В модели бизнеса должны найти отражение:

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

2. Архитектура компании , т.е. наиболее важные статические структуры компании. Элементами структур должны быть:

Внешние и внутренние процессы компании;

Функции (отдельные шаги процессов);

Продукция (выход процессов и функций);

Ресурсы, как человеческие, так и технические.

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

Отношения между процессами, отдельными функциями (шагами) процессов;

Отношения между участниками процесса - различного рода ресурсами, средствами и продукцией;

Отношения между людьми (отношения подчиненности, коммуникации и т.д.).

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

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

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

Вопрос 3

Наибольшее распространение получили 2 группы методологий моделирования бизнес-процессов:

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

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

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

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

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

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

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

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

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

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

Рассмотрим для примера описание прецедента "Продажа продукта". Основной поток событий:

1. Продавец получает заявку клиента

2. Если в заявке указывается готовый продукт, то продавец проверяет наличие требуемого продукта на складе. Далее прецедент продолжается с шага 5.

3. Если в заявке указывается заказной продукт, продавец уточняет сведения о заказе и передает их проектировщику продукта

4. Проектировщик модифицирует продукт в соответствии с требованиями клиента

5. Продавец принимает от клиента оплату

6. Продавец сообщает отправителю количество продукта и адрес клиента и заказывает транспорт

7. Отправитель доставляет клиенту продукт.

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

Вопрос 4

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

Выделяются следующие типовые классы объектов:

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

2. Управляющие - активные объекты, управляющие процессами, но не имеющие контакта с окружением. Типичные примеры управляющих объектов в компании - это Разработчик продукции, Менеджер проекта.

3. Объекты-сущности - пассивные объекты, которые обрабатываются бизнесом. Как правило, объекты-сущности не являются человеческими или техническими ресурсами. Типичные примеры сущностей в компании - Продукция, Заказ, Извещение.

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

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

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

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

Для того, чтобы иметь представление обо всех ролях и обязанностях объекта, нужно составить описание объекта . Описание объекта состоит из двух частей: описание состояний и описание поведения. Для составления описания состояний объекта, прежде всего, необходимо выделить все его характеристики, свойства, называемые атрибутами. Атрибут должен иметь имя, диапазон возможных значений, а для экземпляра объекта еще и конкретное текущее значение атрибута. Например, объект "Заказ" может иметь атрибуты, указывающие название заказываемого товара, его характеристики, количество, имя клиента, заказавшего товар и т.д. Как правило, состав атрибутов одинаков для всего класса объекта. Различные экземпляры объекта отличаются лишь набором конкретных значений атрибутов.

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

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-10-11

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

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

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

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

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

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

Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent ). Такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности.

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

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

Процесс построения объектной модели включает в себя следующие этапы:

Определение объектов и классов;

Подготовка словаря данных:

Определение зависимостей между объектами;

Определение свойств объектов и связей;

Организация и упрощение классов при использовании наследования;

Дальнейшее исследования и усовершенствование модели.