Добавлен: 21.05.2023
Просмотров: 330
Скачиваний: 5
СОДЕРЖАНИЕ
1.1 Описание предметной области. Постановка задачи
1.2 Предлагаемые мероприятия по улучшению технологии решения задачи
2.1. Выбор средства для моделирования предметной области решаемой задачи
2.1.1 Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
2.1.2 Объектно-ориентированные CASE-средства (RationalRose)
2.2.1. Диаграмма вариантов использования
CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.
Рис. 2.1.1.2 – Окно Designer/2000
Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов.
На этапе реализации создается сама база данных и строятся прикладные системы, которые в дальнейшем тестируются, и проверяются на качество и соответствие требованиям пользователей. Более того, создаётся пользовательская и техническая документация, руководство по эксплуатации. На этапах эксплуатации и сопровождения анализируются производительность и целостность системы, выполняется поддержка и, при необходимости, модификация ИС;
Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий.
2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию
2.2.1. Диаграмма вариантов использования
Диаграмма вариантов использования является исходной концептуальной моделью системы в процессе ее проектирования и разработки. Логическая модель позволяет определить два различных взгляда на системы: статический и динамический.
Основными элементами диаграммы вариантов использования являются
действующие лица, варианты использования и отношения между ними. Действующее лицо - это роль, которую пользователь играет по отношению к системе.
На диаграмме вариантов использования присутствуют три действующих лица: «Пользователь» системой, «Поставщик» и «Покупатель».
Вместе с действующими лицами системы, определяя реальные задачи пользователей и рассматривая альтернативные способы решения этих задач, всегда следует анализировать варианты использования.
Добавим на диаграмму следующие варианты использования: «Заказ и хранение товара», «Идентификация заказа», «Отмена заказа», «Продажа товара», «Идентификация покупки», «Отказ в продаже», «Формирование справочной информации» и «Доступ к базе данных». Основными вариантами использования являются «Заказ и хранение товара» и «Продажа товара», которые далее будут рассмотрены более подробно.
Полученная в результате последующей детализации диаграмма вариантов использования будет содержать 8 вариантов использования и 3 актеров, между которыми установлены ассоциации отношения зависимости. Диаграмма вариантов использования приведена на рис. 2.2.1.1.
Рис. 2.2.1.1. – Диаграмма вариантов использования
2.2.2. Диаграмма последовательности
На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени.
На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни
двух объектов. Сообщения появляются в том порядке, как они показаны на диаграмме (сверху вниз). Каждое сообщение может быть помечено именем.
Диаграммы последовательностей для вариантов использования приведены ниже на рисунках 2.2.2.1 и 2.2.2.2.
Рис. 2.2.1.1. – Диаграмма последовательности для варианта
использования «Заказ и хранение товара»
Данная диаграмма показывает линию жизни объекта класса «Поставщик» символом уничтожения (крестик). То есть «Поставщик» поставляет товар и уходит из рассмотрения и дальнейшая деятельность осуществляется без его участия.
Рис. 2.2.1.2. – Диаграмма последовательности для варианта
использования «Продажа товара»
2.2.3. Диаграмма состояний
Диаграммы состояний являются известным средством описания поведения систем. Главное их предназначение - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла.
Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования. На данной диаграмме изображаются только взаимосвязи структурного характера, не зависящие от времени или реакции системы на внешние события. Однако для большинства физических систем, кроме самых простых и тривиальных, статических представлений совершенно недостаточно для моделирования процессов функционирования подобных систем, как в целом, так и их отдельных подсистем и элементов.
Характеристика состояний системы не зависит (или слабо зависит) от логической структуры, зафиксированной в диаграмме классов. Поэтому при рассмотрении состояний системы приходится на время отвлечься от особенностей ее объектной структуры и мыслить совершенно другими категориями, образующими динамический контекст поведения моделируемой системы.
Процесс начинается с начальной точки, затем следует самый первый переход в состояние «Ожидание поставщика». Простой переход представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий.
Диаграммы состояний представлены на рисунках 2.2.3.1 и 2.2.3.2
Рис. 2.2.3.1. – Диаграмма состояний для варианта использования «Заказ и хранение товара»
Рис. 2.2.3.2. – Диаграмма состояний для варианта использования «Продажа товара»
При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности.
2.2.4. Диаграмма деятельности
Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности.
Диаграммы деятельности обычно используются для описания поведения, включающего в себя множество параллельных процессов, позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.
Диаграмма деятельности отображает поведение проектируемой системы «Учёт товаров» в зависимости от действий пользователя системой.
Проектируя заданную систему, следует внести на диаграмму деятельности следующие элементы: «Ввод данных поставщика», «Заключение договора», «Оплата услуги», «Приём товара на позицию», «Хранение товара», «Проверка срока годности», «Продажа товара», «Приём платежей за товар», «Формирование справочной информации» и «Завершение деятельности». А также необходимо добавить ветвления и переходы. Диаграмма деятельности приведена на рис. 2.2.4.1.
Рис. 2.2.4.1. – Диаграмма деятельности
В процессе проектирования системы «Учёт товаров» средствами RationalRose были созданы такие типы диаграмм как: диаграмма вариантов использования, диаграмма классов, диаграмма коопераций, диаграмма последовательностей, диаграмма состояний и диаграмма деятельности.
2.2.5. Диаграмма классов
Диаграммы классов являются центральным звеном методологии объектно-ориентированных анализа и проектирования. Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта.
Класс в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов.
На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности сущностей, обеспечивающих требуемое поведение системы. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы.
В нашем случае на диаграмму следует нанести такие классы: «Поставщик», «Приём товара», «Товар», «Транзакт», «Продажа товара».
Все классы «Поставщик», «Приём товара», «Товар», «Транзакт», «Продажа товара» имеют стереотип Entity, означающий, что данные классы предназначены для хранения информации, которая должна сохраняться в системе после уничтожения объектов данного класса. Класс «Транзакт» хранит информацию о выполненных пользователем транзакциях.
Зададим для классов значения атрибутов и операции (процессы, реализуемые классом), добавим ассоциации. Все атрибуты будут иметь квантор видимости public. Для класса «Транзакт» квантор видимости private. Диаграмма классов приведена на рисунке 2.2.5.1.
Рис. 2.2.5.1 – Диаграмма классов
Заключение
В данной курсовой работе приведены основные диаграммы (диаграмма вариантов использования, диаграмма классов, диаграммы кооперации, диаграммы последовательности, диаграммы состояний и диаграмма деятельности), которые дают полное наглядное представление о функционировании проектируемой системы «Учёт товаров», а также возможные варианты развития системы в зависимости от воздействия внешних факторов.
Список литературы
1. Вендеров, А. М. Проектирование программного обеспечения экономических информационных систем [Текст] / А. М. Вендеров. - М. : Финансы и статистика, 2002. – 352 с.
2. Кватрани, Т. Rational Rose 2000 и UML. Визуальное моделирование [Текст] / Т. Кватрани. - М. : ДМК Пресс, 2001. - 176 с.
3. Ломакин, В. К. Мировая экономика: Учебник для вузов[Текст] / В. К. Ломакин. — М: ЮНИТИ, 2000. — 727 с.
4. Мацяшек, А. П. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML [Текст] / А. П. Мацяшек, А. Н. Лешек. – М. : Издательский дом «Вильямс», 2002. – 432 с.
5. Проектирование информационных систем: курс лекций [Текст] / В. И. Грекул, Г. Н.Денищенко, Н. Л. Коровкина. - М. : Интернет-Ун-т Информ технологий, 2005. - 304 с.
6. Титова, Н. Е. История экономических учений: курс лекций [Текст] / Н. Е. Титова. — М.: Гуманит. изд. центр ВЛАДОС, 2007. — 288 с.
7. Трофимов, С. А. CASE-технологии: практическая работа в RationalRose [Текст] / С. А. Трофимов. - М. : Бином-Пресс, 2002. - 288 с.
8. Федотова, Д. Э. CASE-технологии: Практикум [Текст] /Д. Э. Федотова, Ю. Д. Семенов, К. Н. Чижик. - М. : Горячая линия-Телеком, 2005.— 160 с.
9. Шишкин, А. Ф. Экономическая теория: Учебное пособие для ву-2-е изд.: В 2 кн. Кн. 1 [Текст] / А. Ф. Шишкин. - М.: Гуманит, изд. зов.центр ВЛАДОС, 2006. - 656 с.