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

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

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

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

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

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

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

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

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

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

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

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

Сравнение существующих методик

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

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

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

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

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

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

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

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

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

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

Языки объектно-ориентированного моделирования стали появляться между серединой 1970-х и концом 1980-х годов, когда началась разработка подходов к объектно-ориентированному анализу и проектированию (ООАП) систем. К середине 1990-х годов некоторые из методов были существенно улучшены. Известными в этот период становятся: метод Гради Буча (Grady Booch - Воосh"93); метод Джеймса Румбаха (James Rumbaugh - Object Modeling Technique); метод Айвара Джекобсона (IvarJacobson- Object Orienter Software Engineering).

История языка UML (Unified Modeling Language) берет начало с октября 1994 года, когда Буч и Румбах из Rational Software Согрогаtion начали работу по |унификации своих методов. Проект так называемого унифицированного метода версии 0.8 был подготовлен и опубликован в ноябре 1995 года. Осенью того же года к ним присоединился Джекобсон, главный технолог из компании ObjectoryАВ (Швеция), с целью интеграции своего метода ООSЕ с двумя предыдущими.

В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group) – образован в 1989 году. Язык UML приобретает статус второго стратегического направления в работе OMG. Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению документов, содержащих описание собственно языка UML версии 0.9 (1996 г.)

Rational Software Согрогаtion вместе с несколькими организациями, изъявили желание выделить ресурсы для разработки строгого определения языка UML, учредила консорциум партнеров UML В январе 1997 года опубликован документ с описанием языка UML 1.0.

Из более чем 800 компаний и организаций, входящих в настоящее время в состав консорциума OMG, особую роль продолжает играть Rational Software Согрогаtion, которая стояла у истоков разработки языка UML. Эта компания разработала и выпустила в продажу одно из первых инструментальных СА8Е-средств Rational! Rose 98, в котором была реализована нотация различных диаграмм языка UML. В феврале 2003 г. компания Rational Software Согрогаtion была приобретена IBM, и с этого момента она имеет официальное название IBM Rational Software.

В настоящее время все вопросы дальнейшей разработки языка UML скон­центрированы в рамках консорциума OMG. Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3. Следующей версией языка UML стала версия 1.5, специфицированная в марте 2003 г. В 2004 г. вышла версия UML 2.0.

На основе технологии UML компании Microsoft, Rational Software и другие поставщики средств разработки программных систем разработали единую информационную модель, которая получила название UML Information Model. Предполагается, что эта модель даст возможность различным программам, поддерживающим идеологию UML, обмениваться между собой компонентами и описаниями.

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

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

диаграмма вариантов использования (use case diagram)

диаграмма классов (class diagram)

диаграммы поведения (behaviorг diagrams)

диаграммы взаимодействия (interaction diagrams)

диаграмма кооперации (collaboration diagram)

диаграмма последовательности (sequence diagram)

диаграмма состояний (statechart diagram)

диаграмма деятельности (activity diagram)

диаграммы реализации (implementation diagrams)

диаграмма компонентов (component diagram)

диаграмма развертывания (deployment diagram)

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

Диаграмма вариантов использования – функциональное назначение системы

Диаграмма классов – статическая структура модели системы в терминологии классов ООП

Диаграмма кооперации – структурный аспект взаимодействия объектов системы через передачу и прием сообщений

Диаграмма последовательности – временной аспект взаимодействия объектов системы

Диаграмма состояний – описание поведения системы в терминах переходов и состояний

Диаграмма деятельности – моделирование процесса выполнения операций (частный случай диаграммы состояний)

Диаграмма компонентов – описание физического представления системы, определяющее ее архитектуру (первая из двух диаграмм реализации)

Диаграмма развертывания – представление общей конфигурации и топологии распределенной системы (вторая из двух диаграмм реализации)

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

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

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

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

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

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

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

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

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

Формальное описание предметной области с использованием UML основывается на иерархической структуре модельных представлений (см. рис. 4.5), состоящей из четырех уровней: 1) мета-метамодели; 2) мегамо- дели; 3) модели; 4) объектов.

Рис. 4.5.

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

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

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

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

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

• диаграмма вариантов использования (Use Case Diagram );
• диаграмма классов (Class Diagram );
• диаграммы поведения (Behavior Diagrams );
• диаграммы реализации (Implementation Diagrams).

Рис. 4.6.

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

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

• диаграмма состояния (Statechart Diagram );
• диаграмма деятельности {Activity Diagram);
• диаграммы взаимодействия {Interaction Diagrams) :
• - диаграмма последовательности {Sequence Diagram);
• - диаграмма кооперации {Collaboration Diagram).

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

• диаграмма компонентов {Component Diagram);
• диаграмма развертывания {Deployment Diagram).

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

С точки зрения моделирования бизнес-процессов визуальное моделирование в IJML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей сначала строится модель в форме так называемой диаграммы вариантов использования {Use Case Diagram ), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

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

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

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

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

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

Таблица 4.1

Окончание табл. 4.1

	Обозначение	Назначение
Отношения на диаграмме вариантов использования
Отношение ассоциации (association relationship)		Ассоциация специфицирует семантические особенности взаимодействия акторов и вариантов использования в графической модели системы
Отношение расширения (extend relationship)		Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров
Отношение обобщения (generalization relationship)		Отношение обобщения служит для указания того факта, что некоторый вариант использования Л может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В
Отношение включения (include relationship)		Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования

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

Рис. 4.7.

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

Не вдаваясь в описание семантики языка UML (она хорошо освещена в соответствующей литературе), приведем лишь результаты объектно-ориентированного анализа, показанные на рис. 4.8-4.12.

Нетрудно заметить, что время как важнейший атрибут любой поведенческой модели присутствует на приведенных диаграммах лишь опосредованно. Это означает, что при анализе поведения (или изменения состояний) возможны лишь качественные оценки типа «не раньше, чем...», «только после того, как...» и т.н. Однако при анализе, например, диаграммы состояний (см. рис. 4.9) естественным образом возникают следующие вопросы: «Как часто поступают заказы?», «Как долго они оформляются?», «Каково соотношение количества автоматизированных рабочих мест (АРМ) и числа менеджеров?», «Какой должна быть производительность сервера?» и т.д. Очевидно, что без привлечения аппарата имитационного моделирования получить ответы на эти вопросы по приведенным диаграммам просто невозможно.

Рис. 4.8.

Рис. 4.9.

Рис. 4.10.

Рис. 4.11.

Рис. 4.12.

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

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

Таблица 4.2

Взаимосвязь объектов диаграмм UML и объектов имитационной модели

	Объект диаграммы состояний	Объект имитационной модели

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Контрольная работа

" Объектно-ориентированное моделирование на основе UML "

Студент: Филатов Р.Д.

Липецк 2015

Введение

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

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

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

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

Создание диаграммы прецедентов

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

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

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

Создание диаграммы сотрудничества

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

Создание диаграммы классов

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

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

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

Наконец, применяют комбинацию двух указанных подходов. Для дальнейшей организации классов разрешается вкладывать пакеты друг в друга. На высоком уровне абстракции можно сгруппировать классы по функциональности, создав пакет Security. Внутри него можно создать другие пакеты, сгруппировав отвечающие за безопасность классы по функциональности или по стереотипу. Ознакомившись с классами модели, объединим эти классы в пакеты по стереотипу. Были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы (рисунок А.4).

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

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

Граничные классы (boundary classes) - позволяют действующему лицу взаимодействовать с системой. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать по крайней мере один граничный класс.

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

В данной модели была создана диаграмма классов (рисунок А.4) для сценария "Открыть новый вклад".

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

Создание диаграммы состояний для классов и диаграммы компонентов

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

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

Литература

1. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство "Лори", 2009.- 581 с, ил.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2009.- 432 е., ил. (Серия "для программистов").

3. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом "Вильяме", 2012. - 496 с, ил.

4. Кураев Е.А. Банковские системы: Издательский дом "Глория", 2013.-225 с.,ил (Валютные операции с вкладами)

5. Родионова В.М. Банковские операции: Под ред. Родионовой В.М.,2011 .- 112с, ил (Валютные операции с вкладами)

Размещено на Allbest.ru

Подобные документы

Использование программы Rational Rose 2000 для моделирования информационной подсистемы учета валютных операций с вкладами физических лиц. Создание диаграмм прецедентов, последовательности и сотрудничества. Основные добавленные атрибуты класса "Вклад".

курсовая работа , добавлен 23.06.2011


Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.

курсовая работа , добавлен 29.06.2011


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

курсовая работа , добавлен 25.06.2011


Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.

курсовая работа , добавлен 26.06.2011


Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

курсовая работа , добавлен 23.06.2011


Общая характеристика склада как объекта хозяйственной деятельности. Создание диаграммы прецедентов и последовательности. Построение корпоративной диаграммы сотрудничества. Предназначение диаграммы классов и компонентов. Генерация программного кода C++.

курсовая работа , добавлен 23.06.2011


Разработка модели информационной подсистемы для учета заказов клиентов автосервиса с применением языка UML. Создание диаграммы прецедентов, последовательности, сотрудничества и классов, используя методы Rational Rose 2000. Генерация программного кода C++.

курсовая работа , добавлен 22.06.2011


Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).

курсовая работа , добавлен 13.05.2014


Разработка объектно-ориентированной модели информационной подсистемы учета студентов университета во время экзаменационной сессии с помощью программы Rational Rose 2000, с использованием языка UML. Порядок генерации программного кода на языке С++.

курсовая работа , добавлен 21.06.2011


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