Дипломная работа: Автоматизация "личного кабинета" консультанта по недвижимости (на примере организации Росинформ)
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
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 приведена значительно более сложная диаграмма.
Для любого класса уточняют его назначение в модели с помощью
указания стереотипа и пояснительного текста в форме документации. Далее в
секцию документации данного класса вводят поясняющий текст.
Для отдельного класса можно уточнить также и другие его свойства,
спецификации свойств этого класса. Например, можно задать количество
Источник: https://baza.diplomsite.ru/previewfile/2504