Методология объектного проектирования на языке UML (UML-диаграммы)
Унифицированный язык моделирования (UnifiedModelingLanguage - UML) - это язык для специфицирования, визуализации, конструирования и документирования на основе объектно-ориентированный подхода разные виды систем: программных, аппаратных, программно-аппаратных, смешанных, явно включающие деятельность людей и т. д.
Помимо прочего, язык UML применяется для проектирования реляционных БД. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности не слишком отличаются от возможностей ER-диаграмм
Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей), не имеющих явного отношения к проектированию БД), а также связей между этими классами. Ограничения могут неформально задаваться на естественном языке или формулироваться на языке объектных ограничений OCL (ObjectConstraintsLanguage).
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. Имя (текстовая строка), служит для идентификации класса.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута).
|
|
|
Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция - это абстракция того, что можно делать с объектом. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса.
В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоциация (association).
Зависимостью называют связь по применению, когда изменение в спецификации одного класса может повлиять на поведение другого класса, использующего первый класс. Если интерфейс второго класса изменяется, это влияет на поведение объектов первого класса. Зависимость показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость.
Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями "is a", имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.
|
|
|
Одиночное наследование, когда у каждого подкласса имеется только один суперкласс) является достаточным в большинстве случаев применения связи-обобщения. Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов.
Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями).1) Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.
С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Ассоциации может быть присвоено имя, характеризующее природу связи. Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса, как и имя конца связи в ER-модели, задается именем, помещаемым под линией ассоциации ближе к данному классу.
|
|
|
В общем случае, для ассоциации могут задаваться и ее собственное имя, и имена ролей классов. Связано это с тем, что класс может играть одну и ту же роль в разных ассоциациях, так что в общем случае пара имен ролей классов не идентифицирует ассоциацию. В простых случаях, когда между двумя классами определяется только одна ассоциация, можно вообще не связывать с ней дополнительные имена.
Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации.
Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Указание "1" говорит о том, что каждый объект класса с данной ролью должен участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать только один объект класса с данной ролью. Указание диапазона "0..1" говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может участвовать только один объект. Аналогично, указание диапазона "1..*" говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должен участвовать хотя бы один объект (верхняя граница не задана). В более сложных случаях определения кратности можно использовать списки диапазонов.
|
|
|
Обычная ассоциация между двумя классами характеризует связь между равноправными сущностями: оба класса находятся на одном концептуальном уровне. Но иногда в диаграмме классов требуется отразить тот факт, что ассоциация между двумя классами имеет специальный вид "часть-целое". В этом случае класс "целое" имеет более высокий концептуальный уровень, чем класс "часть". Ассоциация такого рода называется агрегатной.
Под инвариантом класса в OCL понимается условие, которому должны удовлетворять все объекты данного класса.
КЛАССИФИКАЦИЯ МЕТОДОВ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ
Проектирование алгоритмов и программ - наиболее ответственный этап жизненного цикла программных продуктов, определяющий, насколько создаваемая программа соответствует спецификациям и требованиям со стороны конечных пользователей. Затраты на создание, сопровождение и эксплуатацию программных продуктов, научно-технический уровень разработки, время морального устаревания и многое другое- все это также зависит от проектных решений.
Методы проектирования алгоритмов и программ очень разнообразны, их можно классифицировать по различным признакам, важнейшими из которых являются:
· -степень автоматизации проектных работ;
· -принятая методология процесса разработки.
По степени автоматизации проектирования алгоритмов и программ можно выделить:
· -методы традиционного (неавтоматизированного) проектирования;
· -методы автоматизированного проектирования (CASE-технология и ее элементы).
Неавтоматизированное проектирование алгоритмов и программ преимущественно используется при разработке небольших по трудоемкости и структурной сложности программных продуктов, не требующих участия большого числа разработчиков. Трудоемкость разрабатываемых программных продуктов, как правило, небольшая, а сами программные продукты имеют преимущественно прикладной характер. При нарушении этих ограничений заметно снижается производительность труда разработчиков, падает качество разработки, и, как ни парадоксально, увеличиваются трудозатраты и стоимость программного продукта в целом.
Автоматизированное проектирование алгоритмов и программ возникло с необходимостью уменьшить затраты на проектные работы, сократить сроки их выполнения, создать типовые "заготовки" алгоритмов и программ, многократно тиражируемых для различных разработок, координации работ большого коллектива разработчиков, стандартизации алгоритмов и программ. Автоматизация проектирования может охватывать все или отдельные лапы жизненного цикла программного продукта, при этом работы этапов могут быть изолированы друг от друга либо составлять единый комплекс, выполняемый последовательно во времени. Как правило, автоматизированный подход требует технического и программного "перевооружения" труда самих разработчиков (мощных компьютеров, дорогостоящего программного инструментария, а также повышения квалификации разработчиков и т.п.).
Автоматизированное проектирование алгоритмов и программ под силу лишь крупным фирмам, специализирующимся на разработке определенного класса программных продуктов, занимающих устойчивое положение на рынке программных средств. Проектирование алгоритмов и программ может основываться на различных подходах, среди которых наиболее распространены: -структурное проектирование программных продуктов; -информационное моделирование предметной области и связан-ных с ней приложений; -объектно-ориентированное проектирование программных продуктов. В основе структурного проектирования лежит последовательная декомпозиция, целенаправленное структурирование на отдельные составляющие. Начало развития структурного проектирования алгоритмов и программ падает на 60-е гг. Методы структурного проектирования представляют собой комплекс технических и организационных принципов системного проектирования.
Типичными методами структурного проектирования являются:
· -нисходящее проектирование, кодирование и тестирование программ;
· -модульное программирование;
· -структурное проектирование (программирование) и др.
В зависимости от объекта структурирования различают:
· -функционально-ориентированные методы - последовательное разложение задачи или целостной проблемы на отдельные, достаточно простые составляющие, обладающие функциональной определенностью;
· -методы структурирования данных.
Для функционально-ориентированных методов в первую очередь учитываются заданные функции обработки данных, в соответствии с которыми определяется состав и логика работы (алгоритмы) отдельных компонентов программного продукта. С изменением содержания функций обработки, их состава, соответствующего им информационного входа и выхода требуется перепроектирование программного продукта. Основной упор в структурном подходе делается на моделирование процессов обработки данных. Для методов структурирования данных осуществляется анализ, структурирование и создание моделей данных, применительно к которым устанавливается необходимый состав функций и процедур обработки. Программные продукты тесно связаны со структурой обрабатываемых данных, изменение которой отражается на логике обработки (алгоритмах) и обязательно требует перепроектирования программного продукта. Структурный подход использует: -диаграммы потоков данных (информационно-технологические схемы) - показывают процессы и информационные потоки между ними с учетом "событий", инициирующих процессы обработки; -интегрированную структуру данных предметной области (инфологическая модель, ER- диаграммы); -диаграммы декомпозиции - структура и декомпозиция целей, функций управления, приложений; -структурные схемы - архитектура программного продукта в виде иерархии взаимосвязанных программных модулей с идентификацией связей между ними, детальная логика обработки данных программных модулей (блок-схемы). Для полного представления о программном продукте необходима также текстовая информация описательного характера. Еще большую значимость информационные модели и структуры данных имеют для информационного моделирования предметной области, в основе которого положение об определяющей роли данных при проектировании алгоритмов и программ. Подход появился в условиях развития программных средств организации хранения и обработки данных - СУБД.
Один из основоположников информационной инженерии - Дж. Мартин - выделяет следующие составляющие данного подхода:
· -информационный анализ предметных областей (бизнес - областей);
· -информационное моделирование - построение комплекса взаимосвязанных моделей данных;
· -системное проектирование функций обработки данных;
· -детальное конструирование процедур обработки данных.
Первоначально строятся информационные модели различных уровней представления:
· -информационно-логическая модель, не зависящая от средств программной реализации хранения и обработки данных, отражающая интегрированные структуры данных предметной области;
· -даталогические модели, ориентированные на среду хранения и обработки данных.
Даталогические модели имеют логический и физический уровни представления. Физический уровень соответствует организации хранения данных в памяти компьютера.
Логический уровень данных применительно к СУБД реализован в виде:
· -концептуальной модели базы данных - интегрированные структуры данных под управлением СУБД;
· -внешних моделей данных - подмножество структур данных для реализации приложений.
Средствами структур данных моделируются функции предметной области, прослеживается взаимосвязь функций обработки, уточняется состав входной и выходной информации, логика преобразования входных структур данных в выходные. Алгоритм обработки данных можно представить как совокупность процедур преобразований структур данных в соответствии с внешними моделями данных. Выбор средств реализации базы данных определяет вид даталогических моделей и, следовательно, алгоритмы преобразования данных. В большинстве случаев используется реляционное представление данных базы данных и соответствующие реляционные языки для программирования (манипулирования) обработки данных СУБД и реализации алгоритмов обработки. Данный подход использован во многих CASE-технологиях.
Объектно-ориентированный подход к проектированию программных продуктов основан на:
· -выделении классов объектов;
· -установлении характерных свойств объектов и методов их обработки;
· -создании иерархии классов, наследовании свойств объектов и методов их обработки.
Каждый объект объединяет как данные, так и программу обработки этих данных и относится к определенному классу. С помощью класса один и тот же программный код можно использовать для относящихся к нему различных объектов.
Объектный подход при разработке алгоритмов и программ предполагает:
· -объектно-ориентированный анализ предметной области;
· -объектно-ориентированное проектирование.
Объектно-ориентированный анализ - анализ предметной области и выделение объектов, определение свойств и методов обработки объектов, установление их взаимосвязей. Объектно-ориентированное проектирование соединяет процесс объектной декомпозиции и представления с использованием моделей данных проектируемой системы на логическом и физическом уровнях, в статике и динамике. Для проектирования программных продуктов разработаны объектно-ориентированные технологии, которые включают в себя специализированные языки программирования и инструментальные средства разработки пользовательского интерфейса.
Традиционные подходы к разработке программных продуктов всегда подчеркивали различия между данными и процессами их обработки. Так, технологии, ориентированные на информационное моделирование, сначала специфицируют данные, а затем описывают процессы, использующие эти данные. Технологии структурного подхода ориентированы, в первую очередь, на процессы обработки данных с последующим установлением необходимых для этого данных и организации информационных потоков между связанными процессами. Объектно-ориентированная технология разработки программных продуктов объединяет данные и процессы в логические сущности - объекты, которые имеют способность наследовать характеристики (методы и данные) одного или более объектов, обеспечивая тем самым повторное использование программного кода. Это приводит к значительному уменьшению затрат на создание программных продуктов, повышает эффективность жизненного цикла программных продуктов (сокращается длительность фазы разработки).При выполнении программы объекту посылается сообщение, которое инициирует обработку данных объекта.
21. Техническое задание. Его цели и задачи.
Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Исходное задание выдаётся заказчиком. Основными причинами, заставляющими его обратиться к разработчику, являются отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования).
Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование.
Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:
§ Обеим сторонам:
§ представить (вообразить) готовый продукт,
§ выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
§ уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
§ Заказчику:
§ осознать, что именно ему нужно,
§ в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
§ требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
§ Исполнителю:
§ понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта или автоматизированной системы,
§ спланировать выполнение проекта и работать по намеченному плану,
§ отказаться от выполнения работ, не указанных в ТЗ.
Ряд требований, которые должны выполняться в техническом задании:
· Полнота- как можно более полное описание системы, целей и задач;
· Логичность- описания не должны быть противоречивыми
· Правильность- отсутствие ошибок, которые могут вести к двусмысленности или некорректности;
· Связность- структура документа должна быть подчинена одной цели.
Состав разделов разработчик должен выработать сам, с годами и опытом. Но есть основные разделы технического задания, которые в той или иной степени должны быть отражены:
- Технические требования и стандарты;
- Структура;
- Функциональное содержание отдельных структурных элементов;
- Состав работ и сроки выполнения;
- Стоимость работ.
Если в техническом задании были описаны указанные моменты, то его можно считать достаточно полным.
Правильно поставленная задача уже наполовину решена.
Постановка задачи, функции программного продукта описываются в техническом задании. Этот документ представляет собой, по сути, логическое описание поведения пользователя, его работы с продуктом, технических требований к нему, а также описание требований к управлению информацией и технической поддержки программы.
ТЗ должно быть понятным для всех заинтересованных сторон - как со стороны клиента, так и с позиций разработчиков, в том числе дизайнеров и программистов. Безусловно, описать все мелочи, частные случаи, нюансы невозможно для сложного проекта и чем сложнее проект, тем больше таких мелочей выясняется на финальном этапе по подготовке сайта к рабочей эксплуатации. Это нормальный процесс и к каким-то проблемам со взаимопониманием он не приводит, т.к. время и ресурсы для этого учитываются нами, исходя из опыта и общей оценки сложности проекта.
22. Структура команды разработчиков. Обязанности и ответственности.
Дата добавления: 2018-02-15; просмотров: 1040; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!