Наиболее очевидная формализация системного подхода к исследованию сложных систем осуществляется на основе понятия “объект ” как базового элемента системы. Объектным подходом будем называть системный подход, формализованный на основе понятия объект. Технологии, построенные на базе объектного подхода, будем называть объектно-ориентированными технологиями (ООТ).
Объектно-ориентированное моделирование (ООМ) обеспечивает ряд существенных преимуществ:
1. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования уже созданных и подтвердивших свою работоспособность моделей.
2. Использование ООМ приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.
3. Объектно-ориентированные модели часто получаются более компактными. Это означает не только уменьшение объема кода программ, но и удешевление проекта за счет использования предыдущих разработок, что дает выигрыш в стоимости и во времени.
4. Объектная модель снижает риск разработки сложных систем за счет четко определенных этапов проектирования и интеграции процесса создания модели, который растягивается на все время разработки, а не превращается в единовременное событие.
5. Объектная модель позволяет в полной мере использовать выразительные возможности современных объектно-ориентированных языков программирования.
Сравнение определений объекта в литературе позволило выявить важные моменты ООМ:
Объектный анализ выявляет для объектов поведение и структуру;
Неоднозначность в представлении разрешается путем закрепления за понятиями термина «класс» , а за конкретными физическими объектами термина «объект» .
Таким образом, ООМ предполагает поддержку классов и экземпляров (статических и динамических) объектов, инкапсуляцию, наследование и полиморфизм. Понятия класс и экземпляр поддерживаются явно или неявно практически всеми языками имитационного моделирования. В противном случае достаточно сложно моделировать системы с множеством однотипных блоков и невозможно моделировать системы с динамической структурой.
Более сложными понятиями ООМ являются наследование и полиморфизм. Наследование позволяет перенести в описание нового класса элементы описания уже имеющегося класса с добавлением новых. Полиморфизм означает возможность использования вместо экземпляра блока некоторого базового класса экземпляра любого его производного класса.
Еще один принцип ООМ является принцип модульности , подразумевающий разбиение системы на части, называемые модулями, каждый из которых содержит группы классов. Наличие широких библиотек классов является серьезным преимуществом той или иной системы имитационного моделирования. В этом случае модель может строиться механически из экземпляров стандартных классов с их параметрической настройкой. На основе разработанных библиотек классов создаётся банк блоков для конструирования имитационных моделей различных предметных областей.
Объектная форма представления наилучшим образом отвечает задачам имитационного моделирования, так как позволяет поставить в однозначное соответствие каждому предмету, явлению или процессу реального мира и их отношениям соответствующий информационный аналог.
В настоящее время признанным стандартом моделирования сложных систем является унифицированный язык моделирования UML (Unified Modeling Language ). Язык UML был разработан компанией Rational Software и ее партнерами. Он является преемником языков моделирования, основанных на методах объектного анализа и проектирования Буча, OOSE Якобсона, OMT Рэмбо и др.
Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять исследуемую или разрабатываемую систему во всей ее полноте. Сложность систем и проектов продолжает увеличиваться, и поэтому возрастает актуальность создания моделирующих комплексов, использующих технологию визуального моделирования.
Одним из немногих инструментальных средств ИМ, использующих в качестве основы структурные диаграммы UML, является AnyLogic , которое применяется в основном для исследования динамических непрерывных систем, за счет использования «гибридных» карт состояний и активных объектов UML-RT, созданных специально для представления динамических систем реального времени. Система Model Vision Studium является упрощенным (лабораторным) вариантом системы AnyLogic .
В технологии ООП взаимоотношения данных и алгоритма имеют более регулярный характер: во-первых, класс (базовое понятие этой технологии) объединяет в себе данные (структурированная переменная) и методы (функции). Во-вторых, схема взаимодействия функций и данных принципиально иная. Метод (функция), вызываемый для одного объекта, как правило, не вызывает другую функцию непосредственно. Для начала он должен иметь доступ к другому объекту (создать, получить указатель, использовать внутренний объект в текущем и т.д.), после чего он уже может вызвать для него один из известных методов. Таким образом, структура программы определяется взаимодействием объектов различных классов между собой. Как правило, имеет место иерархия классов, а технология ООП иначе может быть названа как программирование "от класса к классу".
Любое программирование осуществляется по одному из четырех принципов:
· принцип модульности
· принцип «от общего к частному»
· принцип пошаговости
· принцип структурирования
Модульное программирование. Принцип модульности формулируется как требование разработки программы в виде совокупности модулей (функций). При этом разделение на модули должно носить не механический характер, а исходить из логики программы:
1. размер модуля должен быть ограничен;
2. модуль должен выполнять логически целостное и завершенное действие;
3. модуль должен быть универсальным, то есть по возможности параметризованным: все изменяемые характеристики выполняемого действия должны передаваться через параметры;
4. входные параметры и результат модуля желательно передавать не через глобальные переменные, а через формальные параметры и результат функции.
Еще одной, но уже физической единицей программы является текстовый файл, содержащий некоторое количество функций и определений типов данных и переменных. Модульное программирование на уровне файлов - это возможность разделить полный текст программы на несколько файлов. Принцип модульности распространяется не только на программы, но и на данные: любой набор параметров, характеризующих логический или физический объект, должен быть представлен в программе в виде единой структуры данных (структурированной переменной).
Олицетворением принципа модульности является библиотека стандартных функций. Она, как правило, обеспечивает полный набор параметризованных действий, используя общие структуры данных. Библиотеки представляют собой аналогичные программы, независимо оттранслированные и помещенные в каталог библиотек.
Нисходящее программирование. Нисходящее проектирование программы заключается в том, что разработка идет от общей неформальной формулировки некоторого действия программы на естественном языке, "от общего к частному": к замене ее одной из трех формальных конструкций языка программирования:
· простой последовательности действий;
· конструкции выбора или оператора if;
· конструкции повторения или цикла.
В записи алгоритма это соответствует движению от внешней (объемлющей) конструкции ко внутренней (вложенной). Эти конструкции также могут содержать в своих частях неформальное описание действий, то есть нисходящее проектирование по своей природе является пошаговым. Отметим основные свойства такого подхода:
· первоначально программа формулируется в виде некоторого неформального действия на естественном языке;
· первоначально определяются входные параметры и результат действия;
· очередной шаг детализации не меняет структуру программы, полученную на предыдущих шагах;
· если в процессе проектирования получаются идентичные действия в различных ветвях, то это означает необходимость оформления этого действия отдельной функцией;
· необходимые структуры данных проектируются одновременно с детализацией программы.
Пошаговое программирование. Нисходящее проектирование по своей природе является пошаговым, ибо предполагает каждый раз замену одной словесной формулировки на единственную конструкцию языка. Но в процессе разработки программы могут быть и другие шаги, связанные с детализацией самой словесной формулировки в более подробную.
То, что этот принцип выделен отдельно, говорит о необходимости предотвратить соблазн детализации программы сразу от начала до конца и развивать умение выделять и сосредоточивать внимание на главных, а не второстепенных деталях алгоритма.
Вообще нисходящее пошаговое проектирование программы не дает гарантии получения "правильной" программы, но позволяет возвратиться при обнаружении тупиковой ситуации к одному из верхних шагов детализации.
Структурное программирование. При нисходящей пошаговой детализации программы необходимые для работы структуры данных и переменные появляются по мере перехода от неформальных определений к конструкциям языка, то есть процессы детализации алгоритма и данных идут параллельно. Однако это касается, прежде всего, отдельных локальных переменных и внутренних параметров. С самой же общей точки зрения предмет (в нашем случае - данные) всегда первичен по отношению к выполняемым с ним действиям (в нашем случае - алгоритм). Поэтому на самом деле способ организации данных в программе более существенно влияет на ее структуру алгоритма, чем что-либо другое, и процесс проектирования структур данных должен опережать процесс проектирования алгоритма их обработки.
Структурное программирование - модульное нисходящее пошаговое проектирование алгоритма и структур данных.
Объектно-ориентированный подход к программированию включает в себя 3 основные компоненты:
· объектно-ориентированный анализ (ООА),
· объектно-ориентированное проектирование (ООД),
· объектно-ориентированное программирование (ООП).
В любой инженерной дисциплине под проектированием обычно понимается некий унифицированный подход, с помощью которого мы ищем пути решения определенной проблемы, обеспечивая выполнение поставленной задачи. В контексте инженерного проектирования цель проектирования определяется как создание системы, которая
· удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;
· согласована с ограничениями, накладываемыми оборудованием;
· удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;
· удовлетворяет явным и неявным критериям дизайна продукта;
· удовлетворяет требованиям к самому процессу разработки, таким, например, как продолжительность и стоимость, а также привлечение дополнительных инструментальных средств.
Проектирование подразумевает учет противоречивых требований. Его продуктами являются модели, позволяющие нам понять структуру будущей системы, сбалансировать требования и наметить схему реализации.
Программа - это числовая модель проектируемой системы.(рис. 1.3.1.)
Рис. 1.3.1.
Важность построения модели. Моделирование широко распространено во всех инженерных дисциплинах, в значительной степени из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии. Каждая модель описывает определенную часть рассматриваемой системы, а мы в свою очередь строим новые модели на базе старых, в которых более или менее уверены. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.
Элементы программного проектирования. Ясно, что не существует такого универсального метода, который бы провел инженера-программиста по пути от требований к сложной программной системе до их выполнения. Проектирование сложной программной системы не сводится к слепому следованию некоему набору рецептов. Скорее это постепенный и итеративный процесс. И, тем не менее, использование методологии проектирования вносит в процесс разработки определенную организованность. Инженеры-программисты разработали десятки различных методов, которые мы можем классифицировать по трем категориям. Несмотря на различия, эти методы имеют что-то общее. Их, в частности, объединяет следующее:
· условные обозначения - язык для описания каждой модели;
· процесс - правила проектирования модели;
· инструменты - средства, которые ускоряют процесс создания моделей, и в которых уже воплощены законы функционирования моделей. Инструменты помогают выявлять ошибки в процессе разработки.
Хороший метод проектирования базируется на прочной теоретической основе и при этом дает программисту известную степень свободы самовыражения.
Объектно-ориентированные модели. Полезнее всего создавать такие модели, которые фокусируют внимание на объектах, найденных в самой предметной области, и образуют то, что называется объектно-ориентированной декомпозицией.
Объектно-ориентированный анализ и проектирование - это метод, логически приводящий к объектно-ориентированной декомпозиции. Применяя объектно-ориентированное проектирование, создаются гибкие программы, написанные экономными средствами. При разумном разделении пространства состояний мы добиваемся большей уверенности в правильности нашей программы. В итоге, мы уменьшаем риск при разработке сложных программных систем.
Так как построение моделей крайне важно при проектировании сложных систем, объектно-ориентированное проектирование предлагает богатый выбор моделей, (представлены на рис. 1.3.2) Объектно-ориентированные модели проектирования отражают иерархию и классов, и объектов системы. Эти модели покрывают весь спектр важнейших конструкторских решений, которые необходимо рассматривать при разработке сложной системы, и таким образом вдохновляют нас на создание проектов, обладающих всеми пятью атрибутами хорошо организованных сложных систем.
Рис. 1.3.2
ООП -- идеология программирования, основанная на объединении данных и процедур, которые могут работать с этими данными в совокупности, называемые классами.
Сутью ООП является использование привычной в обыденной жизни объектной модели. Каждый объект имеет свои свойства и с ним можно совершить характерные для него действия. Класс -- это тип объекта. Класс описывает и реализует те самые свойства и действия. Объект в нашем понимании будет являться переменной, типом который и будет являться какой-то класс. Полями класса мы будем называть его свойства, а методами -- действия, которые можно совершить с экземпляром этого класса (объектом).
Под примером реализации класса рассмотрим реализацию понятия книги с использованием класса для того, чтобы определить представление книги TBook и множества функций для работы с переменными этого типа:
PagesCount: integer;
function CompareWithBook(OtherBook: TBook): integer;
procedure ShowTitle;
constructor Create(NewTitle, New
Познавательные способности человека ограничены; мы можем раздвинуть их рамки, используя декомпозицию, выделение абстракций и создание иерархий.
Сложные системы можно исследовать, концентрируя основное внимание либо на объектах, либо на процессах; имеются веские основания использовать объектно-ориентированную декомпозицию, при которой мир рассматривается как упорядоченная совокупность объектов, которые в процессе взаимодействия друг с другом определяют поведение системы.
Объектно-ориентированный анализ и проектирование - метод, использующий объектную декомпозицию; объектно-ориентированный подход имеет свою систему условных обозначений и предлагает богатый набор логических и физических моделей, с помощью которых мы можем получить представление о различных аспектах рассматриваемой системы.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на 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
Построение диаграмм, добавление деталей к описаниям операций, определение атрибутов классов и порядок генерации программного кода на языке С++ объектно-ориентированной модели информационной подсистемы, автоматизирующей работу регистратуры поликлиники.
Языки объектно-ориентированного моделирования стали появляться между серединой 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. При этом диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является, по своей, сути, логической моделью, отражающей статические аспекты структурного построения сложной системы.
Диаграммы поведения также являются разновидностями логической модели, которые отражают динамические аспекты функционирования сложной системы. И, наконец, диаграммы реализации служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели.
В настоящее время в практику разработки сложных информационных систем всё шире внедряется концепция объектно-ориентированного моделирования. Эта концепция явилась результатом развития концептуального и онтологического моделирования
Концептуальное моделирование. Процесс, целью которого является выявление, анализ и описание релевантных его целям сущностей предметной области, взаимосвязей между ними, ограничений, которым они должны удовлетворять, а также их поведения (в смысле изменения их состояния во времени), называют концептуальным моделированием . По существу, концептуальное моделирование представляет структуру знаний о предметной области системы, являющихся необходимой предпосылкой для квалифицированного проектирования таких систем.
Моделирование на базе онтологий. Понятие концептуального моделирования удалось уточнить и расширить, используя понятие онтологии. Онтология - это структурная спецификация некоторой предметной области, ее формализованное представление, которое включает словарь (или имена) указателей на термины предметной области и логические выражения, которые описывают, как они соотносятся друг с другом. Смена терминологии привела к появлению таких понятий, как онтологическое моделирование и онтологический инжиниринг .
Онтологический инжиниринг – это процесс проектирования и разработки онтологий. Он является ядром концепции «управления (менеджмента) знаниями» и технологий инженерии знаний, охватывающих широкий круг методов – от извлечениязнаний до их структурирования и формализации.
Онтологический инжиниринг возник в середине 90-ых годов в крупных корпорациях, где проблемы обработки информация приобрели особую остроту и стали критическими. Стало очевидным, что основным узким местом в технологиях корпоративного управления является обработка знаний , накопленных специалистами компании, так как именно знания обеспечивают преимущество перед конкурентами. Так появился термин «Управление Знаниями» или «Менеджмент Знаний» (МЗ). МЗ трактуется как совокупность процессов, которые управляют созданием, распространением, обработкой и использованием информации внутри предприятия.
Объектно-ориентированное моделирование. Онтологическое моделирование легло также в основу методологий объектно-ориентированного моделирования (ООМ), которая ориентирована, прежде всего, на создание больших и сложных систем, коллективную их разработку, последующее активное сопровождение при эксплуатации и регулярные модификации. В ООМ включают:
· объектно-ориентированный анализ (Object-Oriented Analysis, OOA),
- объектно-ориентированное проектирование (Object-Oriented Design, OOD),
· объектно-ориентированное программирование (Object-Oriented Programming, OOР).
Методология ООA – это методология анализа сущностей реального(или идеального ) мира на основе понятий класса (как типа объектов) и объекта (как экземпляра класса). Объекты и их отношения, представленные в диаграммах классов, относит эту методологию к категории онтологического моделирования .
Для реализации ОО-моделей разработан объектно-ориентированный унифицированный язык моделирования (Unified Modeling Language, UML). Он используется для спецификации, визуализации и документирования компонентов объектно-ориентированных информационных (программных) систем во время разработки.
Для моделирования таких систем UML предоставляет свыше десятка типов диаграмм, моделирующих структуру и функционирование («поведение») объектных систем с разных точек зрения. Моделирование начинается с анализа и моделирования предметной области программной системы и разработки требований её пользователей. Разработанный список требований представляется Use-Case-диаграмами UML. Затем моделируется структура системы в форме «структурных» диаграмм:
Диаграмм классов (Class Diagram),
Диаграмм программных компонентов (Component) и
Диаграмм развёртывания программных компонентов на программно-аппаратной платформе (Deployment Diagram).
Динамические свойства системы моделируются набором диаграмм «поведенческих» типов, определяющих
Алгоритмы взаимодействия программных объектов (Sequential- и Collaboration-диаграммы),
Поведение дискретных объектов (Statechart-диаграммы),
Процессы, протекающие в объектной системе (Activity-диаграммы.
В качестве примера на рис. 36 представлены требования пользователей к электронному книжному магазину (в форме Use-Case-диаграмм системы Rational Rose).
Рис 36. Use Case-диаграммы Rose-проекта eBookShop
Рис. 37. Диаграмма классов предметной области Rose-проекта eBookShop
Рис. 38. Полная статическая модель Rose-проекта eBookShop (в форме UML-диаграммы Классов)
В основе этой модели лежит модель предметной области книжного магазина, показанная на рис. 37. Полная статическая модель электронного книжного магазина, удовлетворяющая всем требованиям пользователей, показана на рис. 38.
Методики объектно-ориентированного моделирования совершили коренной переворот в архитектуре современных информационных систем. На смену традиционной архитектуры алгоритмической обработки данных пришла архитектура, базирующаяся на (объектных) моделях (Model-Driven Architecture, MDA).
