Лабораторная работа "Создание диаграммы классов и работа с CASE – средствами проектирования программного обеспечения"
Оценка 4.8

Лабораторная работа "Создание диаграммы классов и работа с CASE – средствами проектирования программного обеспечения"

Оценка 4.8
docx
28.06.2020
Лабораторная работа "Создание диаграммы классов и работа с CASE – средствами проектирования программного обеспечения"
Лабораторная работа №8.docx

Лабораторная работа №8 Создание диаграммы классов и работа с CASE – средствами проектирования программного обеспечения

 

Цель: изучить CASE-средства проектирования программного обеспечения. Разработать диаграмму классов и диаграмму последовательностей.

 

Теоретические сведения

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

Требования к результатам выполнения лабораторного практикума:

-      модель системы должна содержать: диаграмму вариантов использования; диаграмму классов, позволяющая реализовать весь описанный функционал ИС; диаграмму последовательностей процессов

-      для классов указать стереотипы

 

Общие сведения об объектном моделировании ИС

Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект.

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

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

·       является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;

·        содержит механизмы расширения и специализации базовых концепций языка.

UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

·       строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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

 

 

Язык UML

http://unesco.kemsu.ru/study_work/method/po/UMK/lab_pract/lab04.11.gif

Интегрированная модель сложной системы в нотации языка UML

 

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

·      Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)

·      Проектирование структуры программы

·      Кодирование (набор программного кода согласно проектной документации)

·      Тестирование и отладка

·      Внедрение программы

·      Сопровождение программы

·      Утилизация


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

UML — является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/), Visio и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

·      Диаграмма вариантов использования (use case diagram)

·      Диаграмма классов (class diagram)

·      Диаграмма состояний (statechart diagram)

·      Диаграмма последовательности (sequence diagram)

·      Диаграмма кооперации (collaboration diagram)

·      Диаграмма компонентов (component diagram)

·      Диаграмма развертывания (deployment diagram)



Диаграмма вариантов использования (use case diagram)

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

image


Диаграмма классов (class diagram)

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


image


Диаграмма состояний (statechart diagram)

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

image


Диаграмма последовательности (sequence diagram)

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



image


Диаграмма кооперации (collaboration diagram)

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

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


image


Диаграмма компонентов (component diagram)

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



image


Диаграмма развертывания (deployment diagram)

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

Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.



image


Стоит отметить, что процесс проектирования уже давно стал стандартом разработки ПО, но часто приходится сталкиваться с великолепно написанной программой, которая из за отсутствия нормальной документации обрастает ненужным побочным функционалом, костылями, становится громоздкой и теряет былое качество. =(

 

Порядок выполнения работы

1.   Изучить предлагаемый теоретический материал.

2.   Установить выбранное CASE-средство.

3.   Постройте диаграмму вариантов использования для выбранной информационной системы.

4.   Выполните реализацию вариантов использования в терминах взаимодействующих объектов и представляющую собой набор диаграмм:

·      диаграмм классов, реализующих вариант использования;

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

5. Разделить классы по пакетам использую один из механизмов разбиения.

6. Постройте диаграмму состояний для конкретных объектов информационной системы.

7. Построить отчёт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов.

 

Более подробно по ссылкам

http://e.lib.vlsu.ru/bitstream/123456789/747/1/714.pdf

http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl12/gl12.html

http://www.stgau.ru/company/personal/user/8068/files/lib/B.pdf

             

 Содержание отчета:

1. Тема, цель

2. Все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов для вашей ИС (диаграмма классов и диаграмма последовательностей обязательный минимум!)

3. Выводы о назначении и алгоритмах построения различных диаграмм (желательно в виде сравнительной таблицы)

 


 

Скачано с www.znanio.ru

Лабораторная работа №8 Создание диаграммы классов и работа с

Лабораторная работа №8 Создание диаграммы классов и работа с

Язык UML Интегрированная модель сложной системы в нотации языка

Язык UML Интегрированная модель сложной системы в нотации языка

При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой

При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой

Диаграмма состояний (statechart diagram)

Диаграмма состояний (statechart diagram)

Диаграмма кооперации (collaboration diagram)

Диаграмма кооперации (collaboration diagram)

Диаграмма компонентов (component diagram)

Диаграмма компонентов (component diagram)

Стоит отметить, что процесс проектирования уже давно стал стандартом разработки

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