РАЗРАБОТКА РЕПРЕЗЕНТАТИВНОЙ МОДЕЛИ СЛОЖНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
| Елисейкина Юлия Вячеславовна |
| Государственное профессиональное образовательное учреждение «Донецкий промышленно-экономический колледж» Волков Владимир Александрович |
Аннотация: В статье рассмотрена такая тема, как технология разработки программного обеспечения (ПО).
Цель работы - разработать объектно-ориентированную модель информационной подсистемы для управления, учета, контроля и ведения библиотеки.
Рассмотрено создание диаграммы прецедентов, ее основная характеристика. Рассмотрено создание диаграммы последовательности (sequence diagrams). Рассмотрена диаграмма сотрудничества для прецедента информационной подсистемы «Добавить новую запись о книге». Описана диаграмма классов для прецедента «Добавление новой записи о книге». Приведена и описана диаграмма классов прецедента «Ввод данных о книге», а также рассматриваются основные добавленные атрибуты и операции. Приведены и описаны диаграммы состояний для класса WriteBook. Приведено описание диаграммы компонентов для прецедентов информационной подсистемы «Добавление новой записи о книге». Приведена и описана диаграмма размещения проектируемой информационной подсистемы.
Ключевые слова: UML, ПРОЕКТИРОВАНИЕ, МОДЕЛИРОВАНИЕ, ДИАГРАММЫ, ДИАГРАММА ПРЕЦЕДЕНТОВ, ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ, ДИАГРАММА КЛАССОВ, АТРИБУТЫ, МОДЕЛЬ, АВТОМАТИЗИРОВАННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА.
Вступление
Унифицированный язык моделирования (UML англ. Unified Modeling Language) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем [1].
Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе: явная модель облегчает общение.
Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML - графический язык, что позволяет решить вторую из обозначенных проблем.
UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика. Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой.
В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения.
UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.
В результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированный языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.
Моделирование программного обеспечения
Модель – это абстракция, которая создается с целью постижения чего-либо перед тем, как оно будет создано. Поскольку модель не содержит несущественных деталей, работать с ней оказывается проще, чем с моделируемой сущностью. Проектирования аппаратных и программных систем не является исключением. Чтобы создать сложную систему, разработчик должен абстрагировать разные ее представления, построить модели, используя четкую систему обозначений, проверить, что модели, удовлетворяют требованиям, предъявленным к системе, и постепенно добавлять детали, превращая модели в реализацию.
Модель программных систем (ПС) создается для того, чтобы лучше понимать разрабатываемую систему. Если система достаточно сложная, то другого способа понять ее как единое целое для человека просто нет.
Проектирование ПС начинается с построения модели, описывающей систему с разных точек зрения. Это означает, что полная модель складывается из отдельных проекций, отражающих разные аспекты системы. Выбор проекций модели зависит от подхода к проблеме и принятых решений. Ключом к построению проекций является абстрагирование, когда сосредоточиваются на наиболее существенных деталях, игнорируя при этом менее важные. В дальнейшем для краткости каждую проекцию мы будем называть моделью, указывая ее тип. Например, функциональная модель показывает, что делает система в ответ на запросы пользователя (но не как она это делает), логическая модель описывает основные сущности и отношения между ними.
Модели позволяют свести высокую сложность ПС до уровня, понимаемого человеком. Достигается это за счет иерархического принципа их построения и применения наглядной графической нотации. Иерархия уровней описания системы дает возможность резко сократить количество элементов, которые должен анализировать человек. Каждая модель может быть выражена с разными уровнями детализации. При этом на верхних уровнях иерархии опускаются детали реализации, которые проявляются на более низких уровнях. Руководители проекта могут работать с верхним уровнем модели, где отражаются только основные классы, объекты и связи. Другие разработчики или эксперты имеют возможность опускаться до более мелких, терминальных объектов, их свойств, связей, методов.
В процессе построения модели ПС принимаются наиболее ответственные архитектурные решения, поскольку для этого не требуется детальное кодирование.
Таким образом, происходит разделение труда: моделирование ПС выполняется обычно наиболее квалифицированными разработчиками, способными принять и обосновать кардинальные решения, программную реализацию могут осуществлять программисты среднего уровня, воплощающие принятые и отраженные в модели системные решения в программных кодах.
Построенные модели могут модифицироваться в течение всего жизненного цикла. Причин тому может быть много – изменения требований к системе, устранение ошибок, развитие системы, нахождение более удачных решений и т. д. При этом обязательно соблюдение соответствия между моделями и программными кодами.
Созданная модель является лучшим путеводителем по системе, ее изучение – лучший способ подключения в проект разработки или сопровождения ПС новых сотрудников.
UML обеспечивает поддержку всех этапов жизненного цикла информационной системы и предоставляет для этих целей ряд графических средств – диаграмм.
На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний.
На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.
На рис.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение "является источником входных данных для..." (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML [4].
Рисунок 1 Отношения между различными видами диаграмм
Разработку модели на языке моделирования UML рассмотрим на примере использования диаграммы прецедентов (рис.2).
Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью понятий соответствующего пакета и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования, может быть, подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. Рекомендуемое общее количество актеров в модели – не более 20, а вариантов использования – не более 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм [5].
Семантика построения диаграммы вариантов использования должна определяться следующими особенностями рассмотренных выше элементов модели. Отдельный экземпляр варианта использования по своему содержанию является выполнением последовательности действий, которая инициализируется посредством экземпляра сообщения от экземпляра актера. В качестве отклика или ответной реакции на сообщение актера экземпляр варианта использования выполняет последовательность действий, установленную для данного варианта использования. Экземпляры актеров могут генерировать новые экземпляры сообщений для экземпляров вариантов использования.
Рисунок 2 Диаграмма прецедентов
Подобное взаимодействие будет продолжаться до тех пор, пока не закончится выполнение требуемой последовательности действий экземпляром варианта использования, и соответствующий экземпляр актера (и никакой другой) не получит требуемый экземпляр сервиса. Окончание взаимодействия означает отсутствие инициализации экземпляров сообщений от экземпляров актеров для соответствующих экземпляров вариантов использования.
Варианты использования могут быть специфицированы в виде текста, а в последующем - с помощью операций и методов вместе с атрибутами, в виде графа деятельности, посредством автомата или любого другого механизма описания поведения, включающего предусловия и постусловия. Взаимодействие между вариантами использования и актерами может уточняться на диаграмме кооперации, когда описываются взаимосвязи между сущностью, содержащей эти варианты использования, и окружением или внешней средой этой сущности.
В случае, когда для представления иерархической структуры проектируемой системы используются подсистемы, система может быть определена в виде вариантов использования на всех уровнях. Отдельные подсистемы или классы могут выступать в роли таких вариантов использования. При этом вариант, соответствующий некоторому из этих элементов, в последующем может уточняться множеством более мелких вариантов использования, каждый из которых будет определять сервис элемента модели, содержащийся в сервисе исходной системы. Вариант использования в целом может рассматриваться как суперсервис для уточняющих его подвариантов, которые, в свою очередь, могут рассматриваться как подсервисы исходного варианта использования [6].
Функциональность, определенная для более общего варианта использования, полностью наследуется всеми вариантами нижних уровней. Однако следует заметить, что структура элемента-контейнера не может быть представлена вариантами использования, поскольку они могут представлять только функциональность отдельных элементов модели. Подчиненные варианты использования кооперируются для совместного выполнения суперсервиса варианта использования верхнего уровня. Эта кооперация также может быть представлена на диаграмме кооперации в виде совместных действий отдельных элементов модели.
Отдельные варианты использования нижнего уровня могут участвовать в нескольких кооперациях, т. е. играть определенную роль при выполнении сервисов нескольких вариантов верхнего уровня. Для отдельных таких коопераций могут быть определены соответствующие роли актеров, взаимодействующих с конкретными вариантами использования нижнего уровня.
Эти роли будут играть актеры нижнего уровня модели системы. Хотя некоторые из таких актеров могут быть актерами верхнего уровня, это не противоречит принятым в языке UML семантическим правилам построения диаграмм вариантов использования.
Более того, интерфейсы вариантов использования верхнего уровня могут полностью совпадать по своей структуре с соответствующими интерфейсами вариантов нижнего уровня.
Окружение вариантов использования нижнего уровня является самостоятельным элементом модели, который в свою очередь содержит другие элементы модели, определенные для этих вариантов использования.
Таким образом, с точки зрения общего представления верхнего уровня взаимодействие между вариантами использования нижнего уровня определяет результат выполнения сервиса варианта верхнего уровня. Отсюда следует, что в языке UML вариант использования является элементом-контейнером.
Варианты использования классов соответствуют операциям этого класса, поскольку сервис класса является по существу выполнением операций данного класса.
Некоторые варианты использования могут соответствовать применению только одной операции, в то время как другие - конечного множества операций, определенных в виде последовательности операций. В то же время одна операция может быть необходима для выполнения нескольких сервисов класса и поэтому будет появляться в нескольких вариантах использования этого класса [7].
Реализация варианта использования зависит от типа элемента модели, в котором он определен. Например, поскольку варианты использования класса определяются посредством операций этого класса, они реализуются соответствующими методами.
С другой стороны, варианты использования подсистемы реализуются элементами, из которых состоит данная подсистема. Поскольку подсистема не имеет своего собственного поведения, все предлагаемые подсистемой сервисы должны представлять собой композицию сервисов, предлагаемых отдельными элементами этой подсистемы, т. е., в конечном итоге, классами.
Эти элементы могут взаимодействовать друг с другом для совместного обеспечения требуемого поведения отдельного варианта использования. Такое совместное обеспечение требуемого поведения описывается специальным элементом языка UML - кооперация или сотрудничество, который будет рассмотрен в главе 9, посвященной построению диаграмм кооперации. Здесь лишь отметим, что кооперации используются как для уточнения спецификаций в виде вариантов использования нижних уровней диаграммы, так и для описания особенностей их последующей реализации.
Если в качестве моделируемой сущности выступает система или подсистема самого верхнего уровня, то отдельные пользователи вариантов использования этой системы моделируются актерами. Такие актеры, являясь внутренними по отношению к моделируемым подсистемам нижних уровней, часто в явном виде не указываются, хотя и присутствуют неявно в модели подсистемы.
Вместо этого варианты использования непосредственно обращаются к тем модельным элементам, которые содержат в себе подобные неявные актеры, т. е. экземпляры которых играют роли таких актеров при взаимодействии с вариантами использования. Эти модельные элементы могут содержаться в других пакетах или подсистемах. В последнем случае роли определяются в том пакете, к которому относится соответствующая подсистема [8].
С системно-аналитической точки зрения построение диаграммы вариантов использования специфицирует не только функциональные требования к проектируемой системе, но и выполняет исходную структуризацию предметной области. Последняя задача сочетает в себе не только следование техническим рекомендациям, но и является в некотором роде искусством, умением выделять главное в модели системы.
Хотя рациональный унифицированный процесс не исключает итеративный возврат в последующем к диаграмме вариантов использования для ее модификации, не вызывает сомнений тот факт, что любая подобная модификация потребует, как по цепочке, изменений во всех других представлениях системы. Поэтому всегда необходимо стремиться к возможно более точному представлению модели именно в форме диаграммы вариантов использования.
Если же варианты использования применяются для спецификации части системы, то они будут эквивалентны соответствующим вариантам использования в модели подсистемы для части соответствующего пакета. Важно понимать, что все сервисы системы должны быть явно определены на диаграмме вариантов использования, и никаких других сервисов, которые отсутствуют на данной диаграмме, проектируемая система не может выполнять по определению.
Более того, если для моделирования реализации системы используются сразу несколько моделей (например, модель анализа и модель проектирования), то множество вариантов использования всех пакетов системы должно быть эквивалентно множеству вариантов использования модели в целом.
Вывод
Создание приложения с использованием языка моделирования UML значительно упрощает начальную стадию проектирования. Помогает создать схему, на которой будет показана структура работы приложения. Например, с помощью UML можно создать модель базы данных.
Проектирование базы данных с помощью моделирования данных в UML позволяет визуально отобразить на диаграмме намного больше элементов, чем с помощью традиционных систем обозначений «сущность-связь».
В UML-моделях наряду с такими традиционными элементами, как таблицы, столбцы и связи, можно использовать домены, хранимые процедуры и ограничения. Модель базы данных разрабатывается для многих целей, среди которых построение правильного проекта, контроль над ссылочной целостностью данных, управление повторным использованием стандартных элементов и взаимодействие структур базы данных [9].
Язык моделирования UML является достаточно удобным средством для визуализации конкретной цели – показать работу будущей системы, подсистемы, программного обеспечения и т.д.
Литература
-
Крэг Ларман. Применение UML 2.0 и шаблонов проектирования - Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: Вильямс, 2006. — 736 с. — ISBN 0-13-148906-2.
-
Г. Буч (1999). «UML в действии». Рабочие материалы ACM 42 (10): 26-28.
-
2005. Object-oriented modeling and design with UML.
-
Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство - Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: Вильямс, 2005. — 416 с. — ISBN 0-672-32640-X.
-
Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя - The Unified Modeling Language user guide. — 2-е изд. — М., СПб.: ДМК Пресс, Питер, 2004. — 432 с. — ISBN 5-94074-260-2.
-
Д.О. Романников, А.В. Марков. Пример применения методики разработки ПО с использованием UML диаграмм и сетей Петри // Науч. вестн. НГТУ. - 2012. - №1 (46). - с. 175 – 181.
-
Иан Соммервилл. Инженерия программного обеспечения - Software Engineering. — 6-е изд. — М.: «Вильямс», 2002. — С. 642. — ISBN 5-8459-0330-0.
-
Джек Гринфилд, Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи. Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты - Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. — М.: «Диалектика», 2006. — С. 592. — ISBN 978-5-8459-1181-0.
-
Глинский Б. А. Моделирование как метод научного исследования. М., 1965;
-
Кодрянц И. Г. Философские вопросы математического моделирования. Кишинев, 1978.