13
описывает видимую пользователем функцию,
может представлять различные уровни детализации,
обеспечивает достижение конкретной цели, важной для
пользователя.
Прецедент обозначается на диаграмме овалом, связанным с
пользователями, которых принято называть действующими лицами (актеры,
actors). Действующие лица используют систему (или используются системой) в
данном прецеденте. Действующее лицо выполняет некоторую роль в данном
прецеденте. Список всех прецедентов фактически определяет функциональные
требования к ИС, которые лежат в основе разработки технического задания на
создание системы.
На диаграммах прецедентов, кроме связей между действующими
лицами и прецедентами, возможно использование связей между прецедентами:
"использование" Рисунок 2 (include) и "расширение". Связь типа "расширение"
применяется, когда один прецедент подобен другому, но несет несколько
большую функциональную нагрузку. Связь типа "использование" позволяет
выделить некий фрагмент поведения системы и включать его в различные
прецеденты без повторного описания.
Рисунок 2. Функциональная модель системы Росинфом
14
Теперь, глядя на эту диаграмму, мы можем объяснить, для кого и с
какой целью создается (или) уже создана эта система (программное
обеспечение).
Имеются актёры в системе ООО Росинфом. Это люди Клиент-
поставщик, Клиент-потребитель, Консультант (или другие системы или
подсистемы Поисковик, Анализатор, WebРобот). Для них (актёры) требуется
создать инструмент (программное обеспечение) сбора хранения и продажи
коммерческих услуг (например, предложений о продаже недвижимости –
жилья или автомобилей). Информацию система собирает из разных источников
- клиентов поставщиков например, продавцов авто или жилья. Предполагается
несколько способов – каналов получения коммерческих предложений:
- Через консультантов от клиентов-поставщиков (10 сотрудников) в
живом разговоре
- Через отдельный программный компонент системы WWWробот.
WWWробот сканирует сайты Интернет (типа Avito) и анализирует
предложения заполняя хранилище системы.
Второй прецедент содержит обратный функционал - накопленную в
хранилище информацию должна предоставить клиенту – потребителю:
Предполагается несколько способов – каналов предоставления
(продажи) коммерческих предложений:
- Через тех же консультантов (10 сотрудников) в живом телефонном
разговоре;
- Через отдельный программный компонент системы WWWпоиск.
WWWпоиск сканирует организует поиск коммерческих предложений в
хранилище системы по запросу с параметрами интересными для запроса к
хранилищу системы.
PS. Где здесь бизнес, приносящий деньги – нас на этом этапе не
интересует – Заказчик (руководство агенства) видит выгоду – и поэтому и
сформулировал и утвердил такую функциональную модель.
На практике эта модель помогла мне как разработчику
15
1. Принять решение провести декомпозицию всей системы на две
части:
– подсистема ИСКАТЕЛЬ РОСИНФОМ - сбор коммерческих
предложений в хранилище (Рисунок 3);
– получение коммерческих предложений из хранилища по запросам;
2. Увидеть – какие экранные формы необходимо разработать для
каждого актера в модели.
Особенностью модели является наличие связей по управлению, что в
дальнейшем позволит декомпозировать систему на подсистемы последующих
уровней и на стадиях анализа и проектирования эффективно применить
объектные модели и методы для разработки структуры программных
компонент и данных.
Рисунок 3. Подсистема ИСКАТЕЛЬ РОСИНФОМ
В некоторых случаях при моделировании предметной области следует
описать сценарий работы действующего лица с бизнес-сущностями и состояния
бизнес-сущностей.
16
Сценарии функций предметной области могут использоваться при
проектировании сценариев работы пользователя с будущей системой, описание
состояний бизнес-сущностей - для проектирования пользовательского
интерфейса (справочника состояний бизнес-сущностей). К тому же наличие
сценариев бизнес-функций также в дальнейшем позволит уточнить
функциональные требования к системе.
1.2. Логическая модель системы “Личный кабинет консультанта ООО
Росинфом”
Центральное место в методологии SE (программной инженерии)
занимает разработка логической модели системы в виде диаграммы (одной или
чаще нескольких диаграмм классов). Диаграмма классов отражает, в частности,
различные взаимосвязи между отдельными сущностями предметной области,
такими как объекты и подсистемы, а также описывает их внутреннюю
структуру и типы отношений. На диаграмме не указывается информация о
временнЫх (зависящих от времени) аспектах функционирования системы. С
этой точки зрения диаграмма классов может служить дальнейшим развитием
концептуальной модели проектируемой системы
Логический анализ строится непосредственно на конечных результатах
предыдущего этапа (функционального) анализа и создает базис для этапа
физического проектирования. При логическом анализе описывают организацию
элементов, из которых состоит программное решение, и их взаимодействие.
Модель, полученная на стадии логического анализа должна удовлетворять
следующим условиям:
независимость от технологий;
простая модель;
сосредоточенность на структуре.
Цель логического анализа – описание структурных элементов системы,
их связей и того, что можно делать с каждым из этих элементов.
Диаграмма классов (class diagram) — диаграмма языка UML, на которой
представлена совокупность декларативных или статических элементов модели,
17
таких как классы с атрибутами и операциями, а также связывающие их
отношения.
Диаграмма классов предназначена для представления статической
структуры модели системы в терминологии классов объектно-
ориентированного программирования. При этом диаграмма классов может
содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры
классификаторов, такие как объекты и связи. Когда говорят о данной
диаграмме, имеют в виду статическую структурную модель проектируемой
системы, т. е. графическое представление таких структурных взаимосвязей
логической модели системы, которые не зависят от времени.
Диаграмма классов является основным логическим представлением
модели и содержит детальную информацию о внутреннем устройстве объектно-
ориентированной программной системы или, используя современную
терминологию, об архитектуре программной системы.
Продолжая разработку моделей нашего предприятия, построим для этой
модели диаграммы классов.
Поскольку разрабатываемая модель на начальных этапах работы над
проектом используется для анализа общей архитектуры проекта и согласования
ее с различными участниками рабочей группы, имена классов, их атрибутов и
операций для большей наглядности и понимания задают на русском языке.
На (Рисунок 4) приведена в качестве примера одна из диаграмм классов
системы ООО Росинфом. Для наглядности она здесь упрощена для удобства
восприятия и объяснения основных аспектов диаграммы классов. Далее
Рисунок 5 приведена значительно более сложная диаграмма.
Для любого класса уточняют его назначение в модели с помощью
указания стереотипа и пояснительного текста в форме документации. Далее в
секцию документации данного класса вводят поясняющий текст.
Для отдельного класса можно уточнить также и другие его свойства,
спецификации свойств этого класса. Например, можно задать количество
18
объектов или экземпляров данного класса, для чего следует выбрать строку с
буквой n.
Рисунок 4. Логическая модель системы Росинфом
Теперь, глядя на эту диаграмму мы можем объяснить, какие сущности
присутствуют или выявлены в рассматриваемой системе (или фрагменте), а
также связи между ними (ассоциации).
Один пример разъяснения может выглядеть так:
Класс Документ – присутствует в системе и является абстрактным
родителем (в системе не появляются объекты этого класса а только дочерние) .
Его свойства наследуют конкретные дочерние классы – XML документ и
HTML документ.
На Рисунок 5 приведена значительно более сложная диаграмма классов
которая разработана мной для распределения уровней ответственности в трех
уровневой архитектуре. Суть такова – верхний уровень – это множество
классов, которые обеспечивают пользовательский интерфейс. Средний уровень
– классы, обеспечивающие бизнес правила (они главные рабочие лошадки в
19
программном обеспечении). Наконец, нижний – третий уровень- составляют
классы ответственные за хранение информации.
Эта полезная декомпозиция повышает устойчивость разработки слоев
программного обеспечения.
Рисунок 5. Трёхуровневая модель классов
20
1.3. Динамическая модель системы “Личный кабинет консультанта
ООО Росинфом”
Диаграмма Рисунок 6 последовательности (sequence diagram) -
диаграмма, на которой показаны взаимодействия объектов, упорядоченные по
времени их проявления.
Особенности взаимодействия элементов моделируемой системы могут
быть представлены на диаграммах кооперации и последовательности.
Диаграммы кооперации используются для спецификации динамики поведения
систем, хотя время в явном виде в них отсутствует. Однако временной аспект
поведения может иметь существенное значение при моделировании
синхронных процессов, описывающих взаимодействие объектов. Именно для
этой цели в языке UML используются диаграммы последовательности.
На диаграмме последовательности присутствует ось времени, что
позволяет визуализировать временные отношения между передаваемыми
сообщениями. С помощью диаграммы последовательности можно представить
взаимодействие элементов модели как своеобразный временной график
"жизни" всей совокупности объектов, связанных между собой для реализации
варианта использования программной системы, достижения бизнес-цели или
выполнения какой-либо задачи.
Объекты и их изображение на диаграмме последовательности
На диаграмме последовательности также изображаются объекты,
которые непосредственно участвуют во взаимодействии, при этом никакие
статические связи с другими объектами не визуализируются. Для диаграммы
последовательности ключевым моментом является именно динамика
взаимодействия объектов во времени. При этом диаграмма последовательности
имеет как бы два измерения. Одно - слева направо в виде вертикальных линий,
каждая из которых изображает линию жизни отдельного объекта,
участвующего во взаимодействии. Второе измерение диаграммы
последовательности - вертикальная временная ось, направленная сверху вниз.
21
Каждый объект графически изображается в форме значка
(прямоугольника, или особого ярлыка стереотипа) и располагается в верхней
части своей линии жизни. Внутри прямоугольника записываются собственное
имя объекта со строчной буквы и имя класса, разделенные двоеточием. При
этом вся запись подчеркивается, что является признаком объекта, который, как
указывалось ранее, представляет собой экземпляр класса.
Если на диаграмме последовательности отсутствует собственное имя
объекта, то при этом должно быть указано имя класса. Такой объект считается
анонимным. Может отсутствовать и имя класса, но при этом должно быть
указано собственное имя объекта. Такой объект считается сиротой.
Крайним слева на диаграмме изображается объект - инициатор
моделируемого процесса взаимодействия. Правее - другой объект, который
непосредственно взаимодействует с первым. Таким образом, порядок
расположения объектов на диаграмме последовательности определяется
исключительно соображениями удобства визуализации их взаимодействия друг
с другом.
Рисунок 6. Графические элементы диаграммы последовательности
22
Начальному моменту времени соответствует самая верхняя часть
диаграммы. При этом процесс взаимодействия объектов реализуется
посредством сообщений, которые посылаются одними объектами другим.
Сообщения изображаются в виде горизонтальных стрелок с именем сообщения
и образуют определенный порядок относительно времени своей
инициализации. Другими словами, сообщения, расположенные на диаграмме
последовательности выше, передаются раньше тех, которые расположены
ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма
последовательности моделирует лишь временную упорядоченность
взаимодействий типа "раньше-позже".
Линия жизни объекта (object lifeline) - вертикальная линия на диаграмме
последовательности, которая представляет существование объекта в течение
определенного периода времени.
Линия жизни объекта изображается пунктирной вертикальной линией,
ассоциированной с единственным объектом на диаграмме последовательности.
Линия жизни служит для обозначения периода времени, в течение которого
объект существует в системе и, следовательно, может потенциально
участвовать во всех ее взаимодействиях. Если объект существует в системе
постоянно, то и его линия жизни должна продолжаться по всей рабочей области
диаграммы последовательности от самой верхней ее части до самой нижней.
Отдельные объекты, закончив выполнение своих операций, могут быть
уничтожены , чтобы освободить занимаемые ими ресурсы. Для таких объектов
линия жизни обрывается в момент его уничтожения. Для обозначения момента
уничтожения объекта в языке UML применяется специальный символ в форме
латинской буквы "X". Ниже этого символа пунктирная линия не изображается,
поскольку соответствующего объекта в системе уже нет, и этот объект должен
быть исключен из всех последующих взаимодействий
Вовсе не обязательно создавать все объекты в начальный момент
времени. Отдельные объекты в системе могут создаваться по мере
необходимости, существенно экономя ресурсы системы и повышая ее