Описание всех требований, не вошедших в описание прецедентов.
Функциональность.
Описание, относящееся к большинству прецедентов.
Кроме того, описывается, каким образом регистрируются события и обрабатываются ошибки.
Подключение бизнес-правил
Безопасность – аутентификация всех пользователей
удобство использования. Описание человеческих факторов. Быстрая, простая и корректная обработка информации – это главный принцип системы с точки зрения человеческого фактора.
Надежность
Возможность восстановления информации (при сбое в работе внешних системы, в частности бухгалтерской системы, службы автоматизации, необходимо обеспечить возможность локальной обработки данных, сохранение, с последующей передачей внешним системам)
5. Производительность
Время взаимодействия с внешними системами
6. Возможности поддержки
Адаптация системы. Для различных пользователей заранее определяются точки сценария, в которые можно подключать специфические бизнес-правила
Конфигурирование. Сетевые конфигурации различных пользователей могут отличаться (тонкий клиент, толстый клиент, архитектуры различных уровней). Производственные потребности и возможности ресурсов каждого пользователя со временем могут изменяться – система должна быть настраиваемой.
7. Ограничения
Команда разработчиков (команда проекта) может рекомендовать определенную среду разработки
8. Приобретаемые компоненты
Система вычисления налоговых платежей
Бухгалтерская система
9. Интерфейсы
Выбор монитора (например, сенсорный)
Лазерный сканер (для считывания штрих-кода)
Устройство для печати чека
Устройство для считывания данных с кредитной или дебетовой карты
10. Бизнес-правила
Правило №1: Правило вычисления скидок. (Например, работникам компании – 15%, привилегированный покупатель – 10%). Высокая вероятность возможных изменений – каждая торговая организация устанавливает свои скидки. Источником этого правила является политика торговой организации.
Правило №2: Правило вычисления торговых скидок на уровне транзакций. Применяется к общей стоимости покупки (Например, при сумме покупки более, чем на 500 рублей – скидка 3%). Высокая вероятность изменений. Источник – политика торговой организации.
11. Вопросы законодательства
Необходимо учитывать все необходимые налоги
Правила налогообложения могут изменяться довольно часто
12. Информация из предметной области
Ценовая политика. Кроме правил ценообразования каждому товару могут соответствовать исходная цена и постоянная сниженная цена
Обработка платежа по кредитной и дебетовой карточке. Ответственность за обработку платежей по карточкам несет служба авторизации
Налоги могут вычисляться по сложным схемам и суммы отчислений могут изменяться на государственном уровне, ставки налогов могут зависеть от категории покупателя или назначения товаров (товары для детей). Поэтому задачу вычисления налоговых платежей желательно возложить на отдельную программу
Идентификаторы товаров. Система должна поддерживать разные типы идентификаторов товаров: универсальный код товаров, европейская система кодирования товаров, японская система кодирования товаров
Фрагмент документа Видение
1. Введение
Нам видится надежное приложение автоматизации розничной торговли следующего поколения, обеспечивающее гибкую поддержку различных бизнес-правил, механизмы поддержки различных терминалов и интерфейсов пользователя, а также интеграцию с различными внешними вспомогательными системами
2. Позиционирование
Экономические предпосылки. Существующие программные продукты не обеспечивают настройку на потребности различных пользователей (добавление различных бизнес-правил или поддержка разных сетевых архитектур). Существующие продукты плохо масштабируются, не обеспечивают автоматический переход из интерактивного в автономный режим при сбоях внешней системы. Отсутствует простая возможность интеграции с внешними системами. Не поддерживают новые терминальные технологии. Негибкость существующих систем открывает новую нишу на рынке программного обеспечения.
Формулировка проблемы. Традиционные системы не обладают гибкость, не устойчивы к сбоям и не обеспечивают интеграцию с внешними системами. Это приводит к проблемам с оформлением продаж, несоответствию ПО экономическим потребностям предприятия, невозможности точной и своевременной обработки данных и поддержки планирования. Эти проблемы касаются кассиров, менеджеров по продажам, системных администраторов и руководителей предприятий
Место системы. Здесь указать, для кого предназначена система, описать ее свойства и отличия от продуктов конкурирующих организаций
3. Заинтересованные лица.
Указать, для кого предназначена система, и каковы проблемы заинтересованных лиц
Тут же указать заинтересованных лиц, не являющихся пользователями системы, указать пользователей системы и их решаемые проблемы (выполняемые задачи)
Указать основные задачи высокого уровня
4. Перспективы продукта.
Система может устанавливаться в магазинах, мобильных терминалах (вблизи сети магазинов), будет обслуживать пользователей и взаимодействовать с другими системами
ПРЕИМУЩЕСТВА СИСТЕМЫ:
система будет обеспечивать основную функциональность, способствуя быстрой работе торговых точек
автоматически выявлять сбои, переходя в автономный режим, давая возможность продолжения торговли
*Примечание* к документу Видение:
Функции системы можно выразить через ее системные свойства
Свойства – это то, что может делать система. Пример: Система будет выполнять авторизацию платежей
Выделение функциональных свойств можно проводить в лингвистической форме: Система будет выполнять…*авторизации платежей, обработку продажи по кредитной карте, обработку продажи по дебетовой карте* (нужное подчекрнуть )
В документ Видение желательно включать не более 10 свойств. Если этих свойств больше, то желательно их сгруппировать
Словарь терминов
Как правило, в простейшем варианте представляет собой список важных понятий и их определения. Словарь должен начинаться на самых ранних этапах выполнения проекта. На стадии развития проекта словарь терминов можно превратить в словарь данных.
Необходимо дать определения следующим требованиям: товар, продажа, авторизация платежа. Подтверждение гарантии оплаты от внешней службы авторизации платежей
Запрос на авторизацию платежа – это набор элементов, отправляемых по электронной почте службе авторизации платежей обычно в виде массива символов. К этим элементам относятся: идентификатор магазина, номер счета покупателя, сумма платежа и временнАя метка.
Диаграммы видов деятельности (Activity diagram)
Диаграммы видов деятельности отображают последовательные и параллельные процессы. Используется для моделирования бизнес-процессов, последовательностей выполнения задач и потоков данных, а также сложных алгоритмов. На таких диаграммах обозначают действия или деятельность точки ветвления, разделы, объединения и объекты.
Действие – выполнение некоторых операций. После его завершения выполняется автоматический переход.
Переходы – это моделирование потоков управления.
Узел объекта – создаваемый объект или объект, используемый при выполнении различных видов деятельности.
Точка ветвления – один входящий переход и несколько выходных параллельных потоков или переходов.
Точка объединения – несколько входных переходов, потоков и один выходной переход. Выходной переход не инициируется до тех пор, пока точку объединения не достигнут все входные потоки.
Ветвление по условию – выполняется только один из выходящих переходов. (Сторожевое условие…)
Диаграмма деятельности устанавливает основные правила последовательности действий, то есть показывает, что происходит. Для того чтобы диаграмма показывала, кто участвует в соответствующей деятельности, используются разделы.
26-04-10
Диаграммы классов
Диаграммы классов рассматриваются на концептуальном уровне, на уровне анализа и уровне реализации.
Объекты и классы
Объекты и классы являются основными строительными блоками информационной системы. Объекты объединяются данные и функциональность в единый блок. Объект можно представить как единый пакет данных и функций. Вызов операции дает возможность обратиться к данным объекта (прочитать, использовать и т.д.) Каждый объект является экземпляром некоторого класса. Класс определяет общий набор свойств (атрибутов и операций, присущих всем экземплярам данного класса). Каждый объект имеет свой уникальный идентификатор.
Значение атрибутов хранят данные объектов. Вызов операции объекта всегда приводит к изменению значений одного или более атрибутов объекта или отношений с другими объектами. Это обуславливает переход объекта из одного состояния в другое.
Каждый объект обладает свойством
инкапсуляции. Например: объект Account.
Состояние объекта – это набор значений атрибутов в любой момент времени. Состояние объекта с изменением атрибутов изменяется.
Deposit – размещение средств на счете (в объекте Account).
Withdraw – снятие некоторой суммы, что, в свою очередь, изменяет атрибут Баланс
GetOwner – операция запроса (мы обращаемся с запросом к владельцу данного счета)
SetOwner – меняет владельца объекта Account
Поведение объекта определяется его операциями. Фактически, любой вызов операции, приводящий к изменению сути объекта, определяет переход состояний (из состояния Пустой в Кредитоспособный, например)
Обмен сообщениями
Объекты, составляющие систему, формируют поведение системы путем обмена сообщениями по связям. Когда объект получает сообщение, он проверяет набор своих операций в поиске той, сигнатура которой соответствует сигнатуре сообщения.
Объекты системы обмениваются сообщениями, инициируют сервисы друг друга, при этом осуществляются функции.
Нотация объектов в uml
В верхней ячейке – идентификатор объекта всегда подчеркнут. Идентификатор объекта может включать следующие элементы (возможные варианты):
Только имя класса. Имя можно не определять, в случае, его имя еще не определено или не имеет значения. Если используются два объекта, имя должно быть определено.
Только имя объекта. Без указания класса. Только на ранней стадии проектирования
Указывается имя объекта и имя класса.
Имя объекта обычно записывается заглавными или строчными буквами вперемешку, начиная со строчных, не допустимы специальные символы (пробелы и подчеркивания). Значение каждого атрибута записывается следующим образом: Имя:Тип=Значение
Классы
Класс описывает свойства ряда объектов, поэтому класс надо рассматривать как шаблон объектов, поскольку он определяет структуру (набор свойств) всех объектов этого класса. Все объекты одного класса должны иметь одинаковый набор операций, одинаковый набор атрибутов и одинаковый набор отношений.
Значение атрибутов объектов могут быть различными. Атрибуты, описанные классом, в каждом объекте имеют конкретные значения. Каждый объект отвечает на сообщение, инициируя операции, описанные классом.
Все классы, используемые в системе, можно классифицировать по различным вариантам, выделяя подклассы, суперклассы и т.д.
Классификация классов – очень важный аспект анализа и проектирования систем.
Классы и объекты
Отношения объединяют сущности. Между классом и объектами этого класса устанавливается Отношение. Это отношение называется «Создать экземпляр» и отношения Зависимости, которое означает, что изменение сущности поставщика (класс Account) оказывает влияние на сущность – Клиент.
Отношение «instantiate»
Нотация классов в uml
Визуальный синтаксис для класса очень обширный. Чтобы синтаксис был управляемым, существует понятие НЕОБЯЗАТЕЛЬНЫХ ДОПОЛНЕНИЙ.
ОБЯЗАТЕЛЬНОЙ частью является только ячейка именем класса.
При анализе и проектировании классов необходимо показывать только важные ячейки и дополнения. Это зависит от назначения диаграммы. Если рассматривается диаграмма на концептуальном уровне и важны отношения между классами, то достаточно ячейки с именем. Если необходимо показать поведение класса, то необходимо определить ключевые операции. Если диаграмма должна представлять проецирование классов в реляционные таблицы (базы данных), то важны ячейки имени, ячейки атрибутов с соответствующими типами.
Необходимо использовать гибкость такого подхода.
*Примечание*
В аналитических моделях необходимо показывать:
Имя класса
Ключевые атрибуты
Ключевые операции
Обычно не показывают:
Помеченные значения
Параметры операций
Видимость
Исходное значение
Ячейка имени
Существуют общепринятые соглашения.
Имя класса записывается с заглавной буквы, не используются специальные символы (знаки препинания, тире, подчеркивания, знак амперсанда, решетка, слеш). Стиль записи – Upper Camel Case. НИКОГДА НЕ ИСПОЛЬЗУЮТСЯ АББРЕВИАТУРЫ В ИМЕНАХ КЛАССОВ, АТРИБУТОВ ИЛИ ОПЕРАЦИЙ
Имена классов всегда должны отражать имена реальных сущностей без сокращений. Это затрудняет чтение модели и результирующего кода
Могут применяться специальные акронимы предметной области
Ячейка атрибутов
Синтаксис для атрибутов
Имя атрибута обязательно (Low Camel Case). Обычно в качестве имен атрибутов используются имена существительные или именные группы, поскольку указывают на некоторую сущность (например, баланс, депозит, владелец – имена существительные, сущности). Необходимо избегать специальных символов и сокращений.
Видимость
Видимость контролирует доступ к свойствам класса. При анализе диаграммы можно не указывать видимость, поскольку это описание отвечает на вопрос КАК, а не ЧТО.
Языки реализации могут по-разному интерпретировать все типы видимости кроме Public. Видимость в зависимости от языка реализации может быть очень сложной, поэтому на диаграммах анализа нужно использовать видимость, поддерживаемую UML по умолчанию.
Тип
Типом атрибута может быть другой класс или примитивный тип. Спецификация UML поддерживает 4 примитивных типа.
Кратность
Кратность может быть полезной, поскольку может обозначить определенные бизнес-ограничения, касающиеся количества сущностей, участвующих в отношениях. Кратность позволяет моделировать коллекции сущностей (выражение кратности – целое число больше 0 или неопределенные значения)
Начальное значение
Начальное значение позволяет задавать значение атрибута в момент создания объекта. Использование начальных значений везде, где есть возможность, является хорошим стилем проектирования и программирования. Это гарантирует, что состояние создаваемых объектов класса всегда действительные и пригодны к использованию.
Ячейка операций
Операция – это функция, закрепленная за определенными классом. Операция имеет характеристики:
Имя
Список параметров
Возвращаемый тип
Сочетание этих характеристик образует сигнатуру операции
Сигнатура каждой операции класса должна быть уникальной.
Имена операций записываются в стиле Low Camel Case. В качестве имен используются глаголы или глагольные группы, не допускаются специальные символы.
Имена параметров обычно являются именем существительным или именной группой, поскольку обозначают что-то, что передается в операцию. Каждый параметр имеет определенный тип, который является классом или примитивным типом.
Классы анализа можно обозначать в следующем виде:
*Некоторые авторы считают, что это является не обязательным
Лекция 11. 03-05-10
Логическая архитектура и развертывание
При переходе от анализа к проектированию системы необходимо посмотреть на систему в целом «с высоты птичьего полета». На этом уровне абстракции проектирование типичной системы основывается на нескольких архитектурных уровнях.
Логическая архитектура описывает систему в терминах ее принципиальной организации в виде уровней, пакетов, программных классов и подсистем. Архитектура называется логической, так как не определяет способы развертывания этих элементов в различных операционных системах или на физических компьютерах, устройствах сети.
Уровень – это крупномасштабная группа классов, пакетов или подсистем, имеющих сходные обязанности для большинства аспектов системы. Уровни организуются в группы, например: уровень интерфейса пользователя.
Типичные уровни объектно-ориентированной системы – это
Уровень интерфейса пользователя
Уровень приложения или объектов предметной области. Сюда относятся: программные объекты, представляющие понятия предметной области. Например: программный класс SALE (продажи) подсистемы ВЫЧИСЛЕНИЕ НАЛОГОВ и т.д.
Уровень технических служб. Объекты и подсистемы общего назначения, обеспечивающие поддержку взаимодействия с базой данных или журналов регистрации ошибок. Эти службы обычно независимы от приложения, и их можно использовать повторно в нескольких системах.
В жестко структурированных архитектурах объекты каждого уровня могут вызывать службы, расположенные непосредственно под ним (под этим уровнем). В информационных системах обычно поддерживается гибкая многоуровневая архитектура, при которой объекты могут обращаться к нескольким уровням, расположенным ниже. Например, объекты уровня ИНТЕРФЕЙСА могут обращаться к элементам уровня ТЕХНИЧЕСКИХ СЛУЖБ.
Программная архитектура системы – набор важных решений, касающихся организации программы системы, выбора структурных элементов и их интерфейсов, затрагивающие поведение и взаимодействие этих элементов, их группировку в более крупные подсистемы и архитектурный стиль приложения.
Диаграммы пакетов
Диаграммы пакетов UML используют для иллюстрации логической архитектуры. Каждый уровень представлен в виде пакета. В одном пакете могут объединяться различные элементы (пакеты, классы, прецеденты и т.д.) Часто используются вложенные пакеты. Очень часто изображаются зависимости между пакетами для понимания взаимосвязей элементов пакетов системы. Для этого используется связь ЗАВИСИМОСТЬ (dependency) – пунктирная линия со стрелкой, стрелка направлена в сторону НЕЗАВИСИМОГО пакета. Иногда вложенные пакеты размещаются внутри более общего пакета.
При рассмотрении логической архитектуры очень часто используется шаблон уровней (layers).
Основные принципы:
Организация крупномасштабных структурных элементов системы в отдельные уровни со взаимосвязанными обязанностями так, чтобы на нижнем уровне располагались низкоуровневые службы и службы общего назначения, а на более высоком уровне – объекты уровня логики приложения
Взаимодействие и связывание уровней происходит сверху вниз
WARNING: ИЗБЕГАЙТЕ СВЯЗЕЙ СНИЗУ ВВЕРХ
Рис.: Типичные уровни логической архитектуры информационной системы
Использование этого шаблона позволяет решить возможные проблемы:
Изменение исходного кода часто влечет за собой корректировку всех элементов системы
Из-за высокой степени связывания сложно модифицировать функции приложения, масштабирование системы
Общие технические службы тесно связаны с бизнес-логикой приложения, поэтому их нельзя использовать повторно и др.
Преимущества использования шаблона:
Так как происходит разделение разных аспектов, в частности, службы высокого уровня от служб низкого уровня, специализированных функций от общих, то это снижает уровень связывания и зависимости, вносит дополнительную ясность.
Некоторые уровни (предметной области и технических служб) могут быть распределенными
Сложные элементы подвергаются декомпозиции и подлежат инкапсуляции
Логическая сегментация обеспечивает возможность работы над системой группы разработчиков
Обязанности объектов одного уровня должны быть тесно связаны между собой и отличаться от обязанностей объектов других уровней
Объекты уровня ИНТЕРФЕЙСА должны отвечать за создание диалоговых окон, элементов управления, за обработку событий (мыши, клавиатуры и т.д.)
Объекты уровня ЛОГИКИ ПРИЛОЖЕНИЙ должны отражать реализацию функций предметной области (расчет общей стоимости покупки, налога, стоимости заказа и т.п.)
В этом состоит поддержка базового архитектурного принципа – принципа высокого зацепления, т.е. объекты одного уровня должны быть тесно взаимосвязаны, а между уровнями – наоборот, связаны не настолько тесно.
Взаимосвязь уровня и модели предметной области
Модель предметной области служит для выделения имен классов уровня предметной области. Уровень предметной области является частью программной реализации, поэтому, создавая модель предметной области, мы должны сокращать разрыв между реальным миром и его программной реализацией.
Например, концептуальный класс продажи (SALE) из модели предметной области становится прототипом программного класса продажи уровня ЛОГИКИ ПРИЛОЖЕНИЯ.
При построении диаграмм, отражающих логическую архитектуру (диаграммы пакетов), архитектурные уровни представляют собой деление системы по вертикали. В рамках отдельного уровня – по горизонтали – элементы (пакеты) определяют подсистемы или другие службы, выполняющие параллельные функции. Например, уровень СЛУЖБ можно разделить на разделы, отвечающие за безопасность и разделы формирования отчетов
Реализация архитектуры
Реализация архитектуры состоит в определении важных с точки зрения архитектуры компонентов и проецировании их на физическое оборудование. Здесь мы занимаемся моделированием физической структуры и распределением системы.
Реализация архитектуры – создание одной или более диаграмм развертывания.
Диаграмма развертывания
Диаграмма развертывания определяет физическое оборудование, на котором будет выполняться программная система.
Существует две формы диаграмм развертывания:
ДЕСКРИПТОРНАЯ форма. Содержит узлы, отношения между узлами и артефакты
Рис.: Дескрипторная форма диаграммы развёртывания
ЭКЗЕМПЛЯРНАЯ форма. Экземпляры узлов представляют конкретную идентифицируемую часть оборудования
ИмяКомпьютера
Несмотря на то, что диаграмма развертывания рассматривается как деятельность рабочего потока реализации, в первом приближении она часто создается, как часть выбора окончательной аппаратной архитектуры. Сначала создается дескрипторная форма (узлы и взаимосвязи), затем преобразуется в экземплярную форму.
Узлы
По определению языка UML узел представляет тип вычислительного ресурса, на котором могут быть развернуты артефакты для выполнения.
Существуют два стандартных стереотипа для узлов:
Устройство – тип физического устройства (ПК, сервер)
Среда выполнения
Узлы связываются между собой по каналам связи. Информация передается в двух направлениях. Связь АССОЦИАЦИЯ. Диаграммы развертывания являются самой богатой стереотипами частью UML.
Рис.: Визуализированная дескрипторная форма диаграммы развёртывания
Артефакты
Артефакт представляет собой описание реальной сущности. Например, такой как исполняемый файл (bank-accounting.exe) Артефакты развертываются на узлах. Примеры артефактов: исходные файлы, исполняемые файлы, сценарии, таблицы баз данных, документы, результаты процесса разработки, например, UML-модели. Артефакты отображаются со своими взаимосвязями. UML предлагает стандартные стереотипы артефактов в виде разных типов файлов.
Рис.: Стандартные стереотипы артефактов UML
1 код, графическое изображение, схема базы данных, текстовый документ, диаграмма