Тема: Работа с CASE – средствами проектирования программного обеспечения
Цель работы: изучение среды программного инструмента моделирования StarUML, поддерживающего UML, и приобретение навыков по проектированию системы.
Теоретическая часть
По мере завершения анализа фокус моделирования перемещается на проектирование. В принципе анализ и проектирование могут проводиться параллельно. Методология UP рекомендует не разделять функции аналитиков и проектировщиков. За разработку артефактов (таких как прецедент) – от требований через анализ и проектирование до реализации – должна отвечать одна команда
Проектная модель содержит все то же самое, что и аналитическая модель, но все артефакты в ней проработаны более основательно и должны включать детали реализации. Проектная модель базируется на аналитической модели и может считаться просто ее улучшенной и уточненной версией.
В общем случае проектные модели образуются:
- проектными подсистемами;
- проектными классами;
- интерфейсами;
- реализациями проектных прецедентов;
- диаграммой развертывания (в первом приближении).
Объектно-ориентированное проектирование, в частности методология UP, включает два вида деятельности: проектирование архитектуры системы и проектирование элементов системы.
Проектирование архитектуры системы ведется на всех этапах ЖЦ ПО, выполняется архитектором системы и включает в себя: 1) идентификацию архитектурных решений и механизмов, необходимых для проектирования системы; 2) анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов; 3) формирование архитектурных уровней; 4) проектирование структуры потоков управления; 5) проектирование конфигурации системы.
|
|
|
Проектирование элементов системы выполняется проектировщиками и включает в себя: 1) уточнение описания вариантов использования; 2) проектирование классов; 3) проектирование баз данных (диаграммы развёртывания).
С другой стороны, технологический процесс проектирования предусматривает разработку или модификацию
- диаграмм состояний
- диаграмм деятельности.
Архитектор программного обеспечения в первую очередь обращает внимание на объекты предметной области. Программист же концентрируется на поведении этих объектов, пользуясь классами, к которым они принадлежат. Вот поэтому-то диаграмма классов и является одной из важнейших диаграмм UML. Она используется для документирования программных систем, и основным ее компонентом является класс.
Сокрытие от пользователя внутреннего устройства объектов называется инкапсуляцией. Если говорить более "научным" языком, то инкапсуляция - это защита отдельных элементов объекта, не затрагивающих существенных характеристик его как целого. Инкапсуляция нужна не только для того, чтобы создать иллюзию простоты объекта для пользователя (по словам Г. Буча).
|
|
|
В программировании инкапсуляция обеспечивается с помощью т. н. модификаторов видимости. С их помощью можно ограничить доступ к атрибутам и операциям объекта со стороны других объектов. Если атрибут или операция описаны с модификатором private, то доступ к ним можно получить только из операции, определенной в том же классе. Если же атрибут или операция описаны с модификатором видимости public, то к ним можно получить доступ из любой части программы.
Модификатор protected разрешает доступ только из операций этого же класса и классов, создаваемых на его основе. В языках программирования могут встречаться модификаторы видимости, ограничивающие доступ на более высоком уровне, например, к классам или их группам, однако смысл инкапсуляции от этого не изменяется. В UML атрибуты и операции с модификаторами доступа обозначаются специальными символами слева от их имен:
| Символ | Значение |
| + | public - открытый доступ |
| - | private - только из операций того же класса |
Как использовать объекты класса?
Если уж говорить о защите объекта, то чтобы она действительно была эффективной, надо позаботиться о некоем стандартном и безопасном, не зависящим от языка программирования способе доступа к объекту. К тому же такой стандартный способ доступа должен быть простым и с точки зрения использования, и с точки зрения реализации.
|
|
|
Более строго, интерфейс - это логическая группа открытых ( public) операций объекта. Один и тот же объект может иметь несколько интерфейсов.
Интерфейс отражает внешние проявления объекта, показывает, каким образом осуществляется взаимодействие с ним, скрывая остальные детали, не имеющие отношения к процессу взаимодействия.
Интерфейс всегда реализуется некоторым классом, который в таком случае называют классом, поддерживающим интерфейс. Как мы уже говорили ранее, один и тот же объект может иметь несколько интерфейсов. Это означает, что класс этого объекта реализует все операции этих интерфейсов. Многие из существующих технологий программирования (например, COM, CORBA, JavaBeans) не только активно используют механизм интерфейсов, но и, по сути, полностью основаны на нем.
Интерфейс изображается на диаграммах несколькими способами. Первый и самый простой из них - это класс со стереотипом <<interface>> (рис. 1):
|
|
|
Рисунок 1 - Класс со стереотипом
Этот способ хорош, если нужно показать, какие именно операции предоставляет интерфейс. Если же такие подробности в данный момент не важны, предоставляемый интерфейс изображают в виде кружочка или, как говорят, "леденца" ( lollipop ) (рис. 2):
Рисунок 2 - Класс со стереотипом
Обратите внимание на маленький значок на закладке папки ConduitSet. Это обозначение подсистемы, мы могли бы не рисовать его, а просто использовать стереотип <<subsystem>>. Впрочем, об этом мы еще поговорим.
И наконец, еще один способ изображения интерфейса. Он не является альтернативой описанным ранее способам, а используется для изображения интерфейсов, требующихся объекту для выполнения его работы. Обозначается он очень простым и логичным символом.(рис. 3):
Рисунок 3- Способ изображения интерфейса
Наблюдательный читатель уже, наверное, заметил, как логически совмещаются символы предоставляемого и требуемого интерфейсов.
Действительно, на диаграммах довольно часто можно увидеть такую картинку (рис.4):
Рисунок 4 -Совмещение символов предоставляемого и требуемого интерфейсов
Да, кстати, вы заметили, что названия интерфейсов начинаются с буквы I? Эта традиция пошла из языка Java, и, как показывает практика, она весьма облегчает жизнь, если нужно, например, быстро разобраться в сложной диаграмме, составленной другим человеком.
Дата добавления: 2020-04-25; просмотров: 196; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!