Файл: Моделирование предметной области «Учёт продаж» с помощью UML.pdf

ВВЕДЕНИЕ

Различные сферы человеческой деятельности развиваются с применением компьютерной техники и создания различных информационных систем.

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

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

В современное время число автомобилей растёт в геометрической прогрессии, следовательно, растет на них и спрос. Автомобиль - самое популярное средство передвижения. Существует огромное количество автосалонов по продаже автомобилей. При продаже автомобиля необходимо учитывать, что клиент хочет “немедленно” получить автомобиль, т.е. без ожидания. Если этот факт не учитывать, популярность автосалона резко упадет. А ведь главное для автосалона - это клиент, нет клиента, нет и автосалона. Чтобы избежать такую ситуацию, нужно внедрять быструю и качественную информационную систему. Многие фирмы имеют информационные системы, оставляющие желать лучшего. А некоторые и вовсе её не имеют. Чтобы работа автосалона была прибыльной, нужно внедрять только качественные программные продукты, и набирать соответствующий персонал. Бесспорно, в РФ отечественный автомобиль занимает более половины рынка всех автомобилей, значит, на него существует хороший спрос.

Объект исследования: Автосалон по продаже автомобилей.

Предмет исследования: Обеспечение продаж автосалона.

Методы исследования в данной курсовой работе:

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

- Моделирование – это метод, при котором исследуется не сам объект, а его заменитель – модель. Полученные при изучении свойств модели результаты переносят и на сам объект исследования Автосалон по продаже автомобилей.

Работа выполнена на материалах Уэнди и Майкла Боггс [1], Буча Г., Рамбо Д., Джекобсона А. [2], Грехема И. [3], Федотовой Д., Семенова Ю., Чижик К. [5], Маклаковa С.В. [6], Марка Д.А., МакГоуэн К. [7] и других.

При выполнении работы были использованы следующие программно-аппаратные средства: Rational Rose - CASE-средство фирмы Rational Software Corporation.

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

---

Задачи исследования:

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

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

В практической части будут решены следующие вопросы:

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

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

ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

Структурный подход к проектированию информационной системы

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

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

---

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

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

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

В 1990 х годах словосочетание “объектно-ориентированный” в контексте информационных технологий стало синонимом слов “современность”, “высокое качество”, “ценность”.

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

---

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

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

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

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

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

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

Рисунок 1 - Программный продукт Rational Rose

Всем разработчикам, работающим над проектом, понятны созданные на UML диаграммы, и, что немаловажно, не только во время разработки, но и спустя длительное время. Язык UML открыт и имеет средства расширения базового ядра. На языке UML можно содержательно описывать такие элементы, как класс, объект и компонент различных предметных областей, которые могут сильно отличаться друг от друга. Но программный продукт Rational Rose поддерживает не только язык UML, но и другие нотации создания диаграмм - ОМТ или Booch.

---

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

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

Преимуществами применения Rational Rose заключаются в том, что программный продукт может:

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

UML – это диаграммы, которые позволяющие создавать модели сложных информационных систем. [9]

Диаграммы языка UML

В UML используются следующие виды диаграмм:

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

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

• Диаграмма объектов

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

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

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

• Диаграмма кооперации

• Диаграмма компонентов

• Диаграмма размещения

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

---