надо. Методические указания к выполнению лабораторных работ по курсу «. Методические указания к выполнению лабораторных работ по курсу инструментальные средства информационных систем Для студентов бакалавриата
 Скачать 1.81 Mb.
|
|
Общие сведения об объектном моделировании ИС Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созда- нием программного кода системы. В большинстве случаев эти техно- логии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под кон- кретные проекты оказываются безуспешными. Эти технологии пред- ставлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне от- дельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — пробле- мой организации взаимодействия между различными командами, реа- лизующими проект. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Унифицированный язык объектно-ориентированного мо- делирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует доста- точное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одно- временно, UML является достаточно гибким для настройки и под- держки специфики деятельности различных команд разработчиков. Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объе- динением своих методов OMT и Booch. В настоящее время консорци- ум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристи- ками: является языком визуального моделирования, который обес- печивает разработку репрезентативных моделей для организа- ции взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; содержит механизмы расширения и специализации базовых концепций языка. UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования, ко- торые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности: строить модели на основе средств ядра, без использования ме- ханизмов расширения для большинства типовых приложений; добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ог- раничения для конкретных предметных областей. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Язык UML Рис. 4.1. Интегрированная модель сложной системы в нотации языка UML Стандарт UML предлагает следующий набор диаграмм для моделирования: диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе); диаграммы классов (class diagrams) – для моделирования ста- тической структуры классов системы и связей между ними; диаграммы поведения системы (behavior diagrams): диаграммы взаимодействия (interaction diagrams): диаграммы последовательности (sequence dia- grams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса об- мена сообщениями между объектами; диаграммы состояний (statechart diagrams) – для мо- делирования поведения объектов системы при пере- ходе из одного состояния в другое; диаграммы деятельностей (activity diagrams) – для мо- делирования поведения системы в рамках различ- ных вариантов использования, или моделирования дея- тельностей; Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы развертывания (deployment diagrams) – для моделирования физической архитектуры системы. Диаграммы вариантов использования Понятие варианта использования (use case) впервые ввел Ивар Якобсон и придал ему такую значимость, что в настоящее время вариант использования превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последователь- ность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действую- щим лицом). Вариант использования описывает типичное взаимо- действие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользо- вателем тех функций, которые он хотел бы реализовать. На языке UML вариант использования изображают следующим образом: Рис.4.2. Вариант использования Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Не- смотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, дейст- вующее лицо может также быть внешней системой, которой необ- ходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML действующие лица представляют в виде фигур: Рис.4.3. Действующее лицо (актер) Действующие лица делятся на три основных типа: пользователи; Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко системы; другие системы, взаимодействующие с данной; время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. Связи между вариантами использования и действую- щими лицами В языке UML на диаграммах вариантов использования под- держивается несколько типов связей между элементами диаграм- мы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации – это связь между вариантом исполь- зования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии). Рис.4.4. Пример связи коммуникации Связь включения применяется в тех ситуациях, когда име- ется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких свя- зей обычно моделируют многократно используемую функциональ- ность. Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использова- ния только при необходимости использовать функциональные воз- можности другого. Рис.4.5. Пример связи включения и расширения С помощью связи обобщения показывают, что у несколь- ких действующих лиц имеются общие черты. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис.4.6. Пример связи обобщения Диаграммы взаимодействия (interaction diagrams) Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диа- грамма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме ото- бражается ряд объектов и те сообщения, которыми они обмени- ваются между собой. Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций. Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой информацией для обнов- ления его состояния. Сообщение-запрос (interrogative) – это сообщение, запраши- вающее выдачу некоторой информации об объекте-получателе. Императивное (imperative) сообщение – это сообщение, за- прашивающее у объекта-получателя выполнение некоторых действий. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграм- мы (collaboration diagrams). Диаграмма последовательности (sequence diagrams) Диаграмма последовательности отражает поток событий, про- исходящих в рамках варианта использования. Все действующие лица показаны в верхней части диаграм- мы. Стрелки соответствуют сообщениям, передаваемым между дей- ствующим лицом и объектом или между объектами для выполнения требуемых функций. На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вер- тикальная линия. Эта линия называется линией жизни (lifeline) Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко объекта. Она представляет собой фрагмент жизненного цикла объ- екта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том по- рядке, как они показаны на странице сверху вниз. Каждое сооб- щение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую ин- формацию. Можно показать самоделегирование (self-delegation) – со- общение, которое объект посылает самому себе, при этом стрелка со- общения указывает на ту же самую линию жизни. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 4.7. Пример диаграммы последовательности Диаграмма кооперации (collaboration diagram) Диаграммы кооперации отображают поток событий через конкретный сценарий варианта использования, упорядочены по вре- мени, а кооперативные диаграммы больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче по- нять связи между объектами, однако, труднее уяснить последователь- ность событий. На кооперативной диаграмме так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен кото- рыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообще- ний. Рис. 4.8. Пример диаграммы кооперации Диаграммы классов Общие сведения Диаграмма классов определяет типы классов системы и раз- личного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, опера- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко ции классов и ограничения, которые накладываются на связи меж- ду классами. Диаграмма классов UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а ду- гами - отношения между узлами (ассоциации, наследование, зависи- мости). На диаграмме классов изображаются следующие элементы: Пакет (package) - набор элементов модели, логически связан- ных между собой; Класс (class) - описание общих свойств группы сходных объ- ектов; Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам. Класс Класс - это группа сущностей (объектов), обладающих сход- ными свойствами, а именно, данными и поведением. Отдельный пред- ставитель некоторого класса называется объектом класса или просто объектом. Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объек- та. На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции: Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип). В средней секции содержится список атрибутов В нижней - список операций класса, отражающих его поведе- ние (действия, выполняемые классом). Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутст- вие элементов в ней. На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions). Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Рис. 4.9. Пример диаграммы классов Стереотипы классов Стереотипы классов – это механизм, позволяющий разде- лять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница); Entity (сущность); Control (управление). Граничные классы Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окру- жающей среды. Это экранные формы, отчеты, интерфейсы с аппа- ратурой (такой как принтеры или сканеры) и интерфейсы с другими системами. Чтобы найти граничные классы, надо исследовать диа- граммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответство- вать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. Классы-сущности Классы-сущности (entity classes) содержат хранимую инфор- мацию. Они имеют наибольшее значение для пользователя, и по- тому в их названиях часто используют термины из предметной облас- Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко ти. Обычно для каждого класса-сущности создают таблицу в базе дан- ных. Управляющие классы Управляющие классы (control classes) отвечают за коорди- нацию действий других классов. Обычно у каждого варианта ис- пользования имеется один управляющий класс, контролирующий по- следовательность событий этого варианта использования. Управ- ляющий класс отвечает за координацию, но сам не несет в себе ника- кой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает мно- жество сообщений. Управляющий класс просто делегирует ответст- венность другим классам, по этой причине его часто называют клас- сом-менеджером. В системе могут быть и другие управляющие классы, об- щие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координаци- ей сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функ- ционирования системы, такими как разделение ресурсов, распреде- ленная обработка данных или обработка ошибок. Помимо упомянутых выше стереотипов можно создавать и свои собственные. Атрибуты Атрибут – это элемент информации, связанный с классом. Ат- рибуты хранят инкапсулированные данные класса. Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство назы- вается видимостью атрибута (attribute visibility). У атрибута можно определить четыре возможных значе- ния этого параметра: Public (общий, открытый). Это значение видимости предпола- гает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атри- бута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ». Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозна- чается знаком « – » в соответствии с нотацией UML. Инструментальные средства ИС. Лабораторный практикум. Составитель: Ст. преп. каф. ИТМиУ - Е.А. Миронченко Protected (защищенный). Такой атрибут доступен только са- мому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ». Package or Implementation (пакетный). Предполагает, что дан- ный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком. В общем случае, атрибуты рекомендуется делать закрыты- ми или защищенными. Это позволяет лучше контролировать сам ат- рибут и код. С помощью закрытости или защищенности удается избе- жать ситуации, когда значение атрибута изменяется всеми класса- ми системы. Вместо этого логика изменения атрибута будет за- ключена в том же классе, что и сам этот атрибут. Задаваемые па- раметры видимости повлияют на генерируемый код. Операции Операции реализуют связанное с классом поведение. Опе- рация включает три части – имя, параметры и тип возвращаемого значения. Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату дейст- вия операции. На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвра- щаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена опера- ций, а на других их полную сигнатуру. В языке UML операции имеют следующую нотацию: Имя Операции (аргумент: тип данных аргумента, аргу- мент2:тип данных аргумента2,...): тип возвращаемого значения Следует рассмотреть четыре различных типа операций: Операции реализации; Операции управления; Операции доступа; Вспомогательные операции. |