Файл: Моделирование предметной области «Учет товаров» с помощью UML.pdf
Добавлен: 06.04.2023
Просмотров: 273
Скачиваний: 2
Введение
Этап проектирования структуры программы заключается в разработке детальной схемы будущей программы, на которой указываются классы, их свойства и методы, а также различные взаимосвязи между ними. Результатом данного этапа должна стать детализированная схема программы, на которой указываются все классы и взаимосвязи между ними в процессе функционирования программы, на которой указываются все классы и взаимосвязи между ними в процессе функционирования программы. Согласно методологии объектно-ориентированного анализа и проектирования (ООАП), именно данная схема должна служить исходной информацией для написания программного кода.
Магазин видеопроката занимается выдачей и возвратом фильмов, а также предоставляет возможность клиентам заказать нужный им фильм у поставщика. В данном бизнес-процессе имеются клиент и поставщик – внешние сущности, и они непосредственно взаимодействуют с магазином видеопроката.
Администратор видеопроката является главным звеном в бизнес-процессе, который должен поддерживать актуальную базу фильмов, для большего спроса клиентов. Администратор работает с большим объемом информации, ведет базу клиентов, принимает заявки клиентов на заказы фильмов, непосредственно заказывает фильм у поставщика. Он работает с клиентом, занимается возвратом фильмов.
Тема курсового проекта — «Объектно-ориентированное проектирование информационных систем».
Цель курсового проекта — получение практических навыков построения объектно-ориентированных моделей информационных систем с использованием языка UML.
Задание. Для автоматизации пункта проката построить в case-средстве Rational Rose проект информационной системы.
1. Теоретические основы объектно-ориентированного подхода к проектированию информационных систем
Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE).
Объектно-ориентированная методология (ООМ) создания автоматизированных систем состоит из следующих частей:
- объектно-ориентированный анализ (OOA),
- объектно-ориентированное проектирование (OOD),
- объектно-ориентированное программирование (OOР).
ООА - методология анализа сущностей реального мира на основе понятий класса и объекта, составляющих словарь предметной области, для понимания и объяснения того, как они (сущности) взаимодействуют между собой.
OOР - совокупность идей и понятий, определяющая стиль написания программ, в которой основными концепциями являются понятия объектов и классов.
ООD - методология проектирования, соединяющая в себе процесс объектной декомпозиции, опирающийся на выделение классов и объектов, и приемы представления моделей, отражающих логическую (структура классов и объектов) и физическую (архитектура моделей и процессов) структуру системы.
Основные понятия объектно-ориентированного проектирования: объект, класс, атрибут, операция, полиморфизм, наследование, компонент, связь.
Объект – это сущность предметной области, имеющая четко определяемое поведение. Любой объект обладает состоянием, поведением и индивидуальностью. Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами, оно может меняться со временем. Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение представляется с помощью набора сообщений, воспринимаемых объектом (операций, которые может выполнять объект). Индивидуальность – это свойства объекта, отличающие его от всех других объектов.
Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью свойств, поведения, связей и семантики. Любой объект является экземпляром класса. Определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования.
Атрибут – поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).
Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией или посылкой сообщения. Операция – это реализация услуги, которую можно запросить у любого объекта данного класса. Операции реализуют связанное с классом поведение, его обязанности. Описание операции включает четыре части: имя; список параметров; тип возвращаемого значения; видимость.
Понятие полиморфизма может быть интерпретировано, как способность класса принадлежать более чем одному типу. Полиморфизм - это способность скрывать множество различных реализаций под единственным общим интерфейсом. Интерфейс – это совокупность операций, определяющих набор услуг класса или компонента. Интерфейс не определяет внутреннюю структуру, все его операции открыты.
Наследование – это построение новых классов на основе существующих с возможностью добавления или переопределения свойств (атрибутов) и поведения (операций).
Компонент – это относительно независимая и замещаемая часть системы, выполняющая четко определенную функцию в контексте заданной архитектуры. Виды компонентов: компонент исходного кода; компонент времени выполнения; исполняемый компонент.
Между элементами объектной модели существуют различные виды связей:
- ассоциация – это семантическая связь между классами;
- агрегация – более сильный тип связи между целым и его частями;
- зависимость – связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе;
- обобщение – связь «тип – подтип».
Метод объектно-ориентированного проектирования основывается на:
- модели построения системы как совокупности объектов абстрактного типа данных;
- модульной структуре программ;
- нисходящем проектировании, используемом при выделении объектов.
В объектно-ориентированном проектировании выделяют следующие фундаментальные понятия:
Инкапсуляция.
Концепция сокрытия в как бы "капсуле" всей информации об объекте, то есть объединение в некое целое данных и процедур (методов) их обработки. Единицей инкапсуляции в OOD является объект, в котором содержатся и данные состояния объекта и сообщения, которые объект может обрабатывать. Т.е. Инкапсуляция означает сочетание структур данных с методами их обработки в абстрактных типах данных - классах объектов.
Наследование.
Получение от предшественника - такое соотношение между классами, находящимися в некоторой определенной иерархии, при которой один класс моделирует поведение и свойства другого класса, добавляя свою специфику. Класс поведение которого наследуется называется суперклассом, а класс, который наследует поведение, называется подклассом.
Полиморфизм.
Возможность единообразного обращения (посылки объектам одноименных сообщений) при сохранении уникального поведения объектов. Другими словами, поскольку поведение объектов определяется методами, метод, ассоциированный с одним и тем же именем сообщения, допускает различные реализации для разных классов. Полиморфизм - способность объекта реагировать на запрос (вызов метода) сообразно своему типу, при этом одно и то же имя метода может использоваться для различных классов объектов.
В период между 1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х годов, которая тоже получила название "войны методов".
К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП.
Наиболее известными в этот период становятся:
- Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93).
- Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).
- Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering - OOSE.
Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП. Например, метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений. Метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных системах. Метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.
Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML, эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.
В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.
Специфика языка UML заключается в том, что он определяет семантическую метамодель, а не модель конкретного интерфейса и способы представления или реализации компонентов.
В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML и запросов предложений RFP по его стандартизации. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3.
Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный выше документ защищен законом об авторском праве. В то же время аббревиатура UML, как и некоторые другие, является торговой маркой их законных владельцев, о чем следует упомянуть в данном контексте.
Язык UML ориентирован для применения в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач ООАП. Многие специалисты по методологии, организации и поставщики инструментальных средств обязались использовать язык в своих разработках. При этом термин "унифицированный" в названии UML не является случайным и имеет два аспекта. С одной стороны, он фактически устраняет многие из несущественных различий между известными ранее языками моделирования и методиками построения диаграмм. С другой стороны, создает предпосылки для унификации различных моделей и этапов их разработки для широкого класса систем, не только программного обеспечения, но и бизнес-процессов. Семантика языка UML определена таким образом, что она не является препятствием для последующих усовершенствований при появлении новых концепций моделирования.
Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного моделирования, а также в CASE-средствах самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.