Магистр физ.-мат. наук (МФТИ), в разное время преподавал в МФТИ курсы «Алгоритмы и структуры данных», «Проектирование программных систем», «Машинное обучение». А также «Концепции языков программирования», «Промышленное программирование». Опыт разработки, проектирования архитектуры и управления проектами более 9 лет.
Email: andrey.andrianov@objectoriented.ru (mailto:andrey.andrianov@objectoriented.ru)
ПРЕДИСЛОВИЕ КО ВТОРОМУ ИЗДАНИЮ
Проектирование – это процесс построения модели объекта, который предполагается разработать или создать. Модели в проектировании играют важную роль: модели используются для уточнения того, что нужно сделать, для прояснения способа реализации, для понимания реализуемости решения и его соответствия требованиям, для передачи знаний и распространения информации о проектируемом объекте, для планирования и ведения работ по реализации.
Во многих инженерных отраслях проектирование занимает важное место и часто регулируется государственными, промышленными стандартами или стандартами уровня предприятия. В сфере разработки программного обеспечение проектирование будущей программной системы происходит как в начале работ, так и по ходу реализации.
Важно понимать, что область знаний проектирования – это отдельная дисциплина, требующая особых навыков работы с моделями, применения методов и практик, которые обычно не используются при реализации создаваемого объекта.
На данный момент в индустрии разработки программного обеспечения сложилось несколько отраслей, каждая из которых использует несколько отличные от других методы проектирования. Среди этого разнообразия в книге уделено больше внимания проектированию прикладных программ, компонентов и приложений с помощью объектно-ориентированных методов и унифицированного языка моделирования UML2.
Овладение этими методами позволит в дальнейшем с легкостью освоить и другие сферы проектирования программных систем, и другие языки моделирования.
В данной книге собрано более сотни задач по проектированию. Авторы приложили все возможные усилия к тому, чтобы задачи помогли читателю понять смысл и освоить те или иные концепции, принципы и методы проектирования. Рассматриваемый перечень тем примерно соответствует программе курса по проектированию программных систем, читаемом авторами в Московском физико-техническом институте на протяжении уже более восьми лет и рекомендациям ACM/IEEE по составу учебных программ по проектированию программного обеспечения.
По сравнению с первым изданием книгу пополнили задачи, предлагавшиеся студентам на контрольных работах по проектированию программного обеспечения, вошел новый раздел по предметно-ориентированному проектированию, добавлены рекомендации по составлению проверочных и контрольных работ по отдельным темам проектирования, а также вошло множество задач разной сложности, которые авторы сочли интересными и важными для освоения дисциплины проектирования.
По сравнению с первым изданием в книге изменился состав авторов, тем не менее, важно отметить вклад Штукатурова А.Н, по согласованию с которым во второе издание вошли подготовленные им задачи 2.5, 3.7, 3.9, 4.4, 5.5, 5.6, 7.5, 8.9. Раздел §9 подготовлен Полежаевым В. А., задачи 6.2, 6.4, 2.3, 2.8, 3.10, 7.11, 7.12, 1.3, 1.4, 2.1, 7.1, 8.1, 3.2 предложены Андриановым А. И., остальные задачи, теоретическая справка и примеры решения задач составлены Хританковым А. С.
Апрель 2017
ПРЕДИСЛОВИЕ К ПЕРВОМУ ИЗДАНИЮ
Предлагаемая читателю книга является сборником задач по курсу проектирования программных систем, преподаваемому авторами в Московском физико-техническом институте.
Сборник включает задачи по проектированию и моделированию с помощью языка UML2. Каждая задача имеет условие, в котором описана заготовка модели, и несколько вопросов к ней. Часть вопросов направлена на уточнение и расширение заготовки модели. Другая часть проверяет понимание смысла построенной модели. Предполагается, что вопросы к задаче будут решаться по порядку.
Задачи сборника направлены на развитие навыков изложения проектных решений средствами UML и устроены таким образом, чтобы в наибольшей степени обеспечить единственность решения. В сложных случаях к задачам даны пояснения и указания по решению.
В сборник включены задачи по объектно-ориентированному моделированию предметной области, в том числе задачи на выделение классов, задачи по моделированию структур времени выполнения и размещения компонентов программных систем. Моделированию поведения систем в сборнике посвящены разделы описания взаимодействий, моделирования с помощью конечных автоматов и представления деятельности.
Разделы сборника снабжены пояснениями по основным понятиям. В конце сборника приведены ответы к задачам с пояснениями, приводятся примеры решения некоторых задач.
Сборник может быть использован при проведении семинаров по курсам объектно-ориентированного моделирования и программирования, проектирования программных систем, а также специализированных курсов по языку UML. Задачи сборника могут предлагаться в качестве примеров, демонстрирующих и поясняющих основные понятия и особенности языка, могут входить в задания для самостоятельной работы, проверочные и контрольные работы, использоваться для самостоятельного изучения методов проектирования и языка UML.
Задачи составлены авторами на основе собственного опыта преподавания, адаптированы из профессиональной практики, проведенных контрольных и проверочных работ, предлагаемых студентам проектов.
Июнь 2012
ГЛАВА 1. ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО МОДЕЛИРОВАНИЯ
Краткая история UML. Унифицированный язык моделирования UML появился в результате объединения нескольких подходов к моделированию в середине 1990-х годов. В отличие от предыдущих попыток, в создании языка участвовали авторы этих подходов, а вследствие стандартизации через организацию OMG, участвовали также заинтересованные компании и исследовательские коллективы из разных отраслей.
Поэтому разные части UML отражают потребности в моделировании в разных отраслях и объединение их в одном языке и на основе одной базовой системы понятий позволяет говорить как раз об унифицированном языке моделирования.
В данной книге унифицированный язык моделирования выбран как основной для выражения проектировочных решений. При решении задач стоит ориентироваться на версию UML 2.4.1, которая была стандартизирована международной организацией по стандартизации ISO как ISO/IEC 19505—1:2012 и ISO/IEC 19505—2:2012.
Уровни использования UML. Выделяют несколько уровней владения и использования UML и моделей в целом при проектировании программных систем. На уровне эскиза модели используются для пояснения решений, неформального общения, документирования и не обладают полнотой, строгостью и могут быть несогласованными. На уровне спецификации модель используется как чертеж или план реализации, в соответствии с которым разрабатывается программная система.
Модели и диаграммы на этом уровне должны следовать нотации языка и быть согласованными (well-formed). Согласованность модели означает соответствие правилам использования языка UML2, определенным в его спецификации (метамодели) [4]. Например, если на диаграмме показан элемент модели, то в модели также должны быть определены все элементы, используемые показанным.
На исполняемом уровне модель представляет собой достаточное описание системы для ее воплощения автоматическими средствами. В этом случае исходный код системы может не сохраняться вовсе и быть промежуточным этапом получения работающей программной системы из исходных моделей.
В данном сборнике задач следует ориентироваться на использование UML на уровне спецификации. В то же время часть задач предполагает владение языком на исполняемом уровне.
Решение задач. Прежде чем приступить к решению задач стоит ознакомиться с рекомендуемой литературой для ознакомления с методами проектирования и нотацией. В помощь читателю в начале каждого раздела приводится краткая справка по используемым в задачах раздела понятиям и демонстрируется нотация языка.
Все задачи построены по единому принципу. В условии дается заготовка модели. Это может быть диаграмма или текстовое описание. В текстовом описании названия элементов модели приведены курсивом для облегчения их восприятия. Далее приводится несколько заданий или вопросов к условию. В качестве решения задания нужно указать по шагам ход рассуждения от условия или предыдущего задания к достижению условий, указанных в задании. Для ответа на вопрос следует привести рассуждение в обоснование полученного ответа и сам ответ. Задания и вопросы к задачам следует выполнять по порядку. Решение следующего задания может зависеть от решения предыдущего. Ответом на задание будет фрагмент диаграммы или нескольких диаграмм с представлением изменений, требуемых в данном задании.
При решении следует руководствоваться условием задачи, знаниями методов решения, нотацией и значением понятий языка моделирования. Часть задач составлена на основе реальных проектов разработки программного обеспечения, другую часть составляю учебные задачи. Такие задачи могут вызывать ассоциации с похожими ситуациями или реальными объектами. В этом случае следует придерживаться условия задачи. Если не указано иное, решение задач не предполагает каких-либо специальных знаний в специализированных областях. При необходимости дается сноска, где можно получить дополнительную информацию.
Задачи и задания повышенной сложности отмечены звездочкой (*), для некоторых задач приведено решение, в этом случае указана страница, на которой оно расположено (см. решение в §11). Перед тем, как приступить к решению задач рекомендуется ознакомиться с примерами решения и понять порядок ведения рассуждения и степень его детальности.
При составлении задач уделялось особое внимание тому, чтобы решение было единственным. При необходимости в заданиях к задачам даются указания по предполагаемому способу решения. Впрочем, вполне возможно, что читатель сможет предложить более удачные или лаконичные решения по некоторым задачам. Возможность существования лучшего решения следует учитывать и не требовать однозначного совпадения решения с ответами, приводимыми авторами сборника.
§1. КЛАССЫ И ОБЪЕКТЫ
ОСНОВНЫЕ ПОНЯТИЯ
Пространство имен (namespace) – это именованный элемент модели, который может содержать другие именованные элементы. Принадлежность пространству имен показывается отношением включения в пространство имен (membership). Полностью квалифицированное имя (fully-qualified name) элемента в модели состоит из последовательности имен всех вложенных пространств имен, в которые включен элемент.
Классификатор (classifier) – это пространство имен в модели, указывает на общие некоторому множеству объектов черты. Черты классификатора могут быть поведенческими, структурными или соединительными.
Класс (class) – это классификатор, который описывает некоторую концепцию моделируемой области. Черты класса могут быть различных видов, наиболее часто для описания функциональности класса используются операции (operation), а для описания хранимых данных или связей с другими классами – свойства (property). Если типом свойства является примитивный тип или тип данных, свойства показывают как атрибуты, класса иначе как часть ассоциации.
Операция (operation) – черта поведения интерфейса, класса или типа данных. Операция задается именем, набором параметров, типом возвращаемого значения и его кратностью. Каждый параметр операции может иметь имя, тип, кратность. В программировании операции будет соответствовать сигнатура метода.
Обратите внимание, что определение операции в классе не влечет определение ее реализации в этом классе. Понятие метода в UML2 обозначает реализацию операции алгоритмом, который не описывается средствами UML или не уточняется в модели. В последнем случае, такую реализацию операции называют нечетким поведением (opaqueBehavior).
Интерфейсом (interface) называют особый вид классификатора, который определяет способ взаимодействия с экземпляром класса, реализующего интерфейс. Интерфейс обычно включает операции, но может включать и свойства. В последнем случае наличие указанных свойств является обязательным для реализующего интерфейс класса.
Экземпляр класса (instance) – это элемент модели с описанием, возможно неполным, объекта, которому в системе приписаны черты данного класса. Для того чтобы указать значения свойствам класса в экземпляре используют слоты.
Связью (link) называется экземпляр ассоциации, соединяющий экземпляры классов. В языке программирования однонаправленной связи соответствует типизированный указатель или ссылка.
Ассоциация (association) – это типизированное отношение между классами, которое указывает на логическую связь между ними. Ассоциация имеет два или более полюсов, по одному у каждого связанного класса. Название полюса обычно указывает на роль, которую класс играет в ассоциации.
Обобщение (generalization) является направленным отношением от более специализированного классификатора к более общему. Специализированный, или дочерний, классификатор наследует черты более общего, или родительского, классификатора. Отношение обобщения уточняется отдельно для каждого вида классификатора, в том числе для классов и интерфейсов.
Украшениями (adornments) называются свойства полюса ассоциации, уточняющие роль участвующего в ассоциации класса. С помощью украшений указываются направление навигации, вид композиции и другие свойства полюса.
Типом данных (data type) называется классификатор, экземпляры которого не обладают индивидуальностью и, при совпадении значений свойств, взаимозаменяемы. Простыми (primitive), или примитивным типами данных, являются предопределенные типы: целое Integer, строка String, логический тип Boolean, числа с плавающей запятой Real и неограниченные натуральные числа UnlimitedNatural, которые используются для моделирования неопределенного количества элементов, например, экземпляров класса, участвующих в ассоциации.
Ограничением (constraint) называется логическое выражение об ограничиваемых элементах модели, вычисляемое в контексте какого-либо элемента. Если выражение ложно, то модель считается противоречивой (ill-formed).
Примеры нотации указанных выше элементов модели приведены на рис. 1 и рис. 2.