расшифровка скринкаста по use-case

articles/5_1_1_10_uml_use_case.md

@@ -111,10 +111,6 @@
 
 Графически *отношение обобщения* обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
 
-![Отношение обобщения](../img/10012.png)
-
-Рассматривая наш магазин при автосервисе, мы можем применить обобщение для закупок запчастей при тех.обслуживании автомобиля. Понятно, что делает это не клиент, а внутренняя служба, которая потом просто выставляет счёт со списком запчастей (и это еще один прецедент к варианту оплаты).
-
 **Границы проектируемой системы**. В начале лекции про них упоминалось - прямоугольник, который ограничивает проектируемкю модель (т.е. наши варианты использования). Еще раз обращаю внимание, акторы не входят в модель и рисуются за пределами системы.
 
 ![границы проектируемой системы](../img/10013.png)
@@ -123,6 +119,98 @@
 
 Мы рассмотрели только базовые элементы для диаграммы вариантов использования, на самом деле их больше. Но для нашего уровня обучения этого достаточно.
 
+## Разбор скринкаста семинара "Системный анализ и проектирование"
+
+Текст задания:
+
+>Пользователь устанавливает приложение и регистрируется, указав ФИО и лицевой счёт, пароль. Так же пользователь может прикрепить данные банковской карты для быстрой оплаты, но не обязательно.
+>
+>Работа возможна только для авторизованного пользователя.
+>
+>Пользователь может оплатить услуги за электроэнергию, введя показания индивидуального прибора учёта. При введении показаний пользователь может запросить отчёт по оплате своего лицевого счёта, указав период для отчёта.
+>
+>Если карта не "привязана" к аккаунту, то пользователь вводит данные банковской карты и подтверждает оплату. Если карта "привязана", пользователь подтверждает оплату. После оплаты приложение генерирует квитанцию об оплате, которую пользователь может скачать. При закрытии приложения квитанция не сохраняется.
+
+В **Visio** создаёте новый документ и открываете *Дополнительные фигуры* -> *Программы и базы данных* -> *Программное обеспечение* -> *Сценарии выполнения UML*
+
+![](../img/usecase01.png)
+
+>Цвет моих диаграмм отличается от сделанных в **Visio**, т.к. я делаю в [visual-paradigm онлайн](https://online.visual-paradigm.com)
+
+Порядок работы:
+
+* определяем акторов
+* определяем варианты использования
+* определяем виды взаимодействия
+* строим диаграмму
+
+1. Рисуем прямоугольник подсистемы:
+
+    ![](../img/usecase02.png)
+
+2. Определяем акторов
+
+    В нашей системе это обычный **пользователь** и **авторизованный пользователь**. Рисуем их рядом с нашей подсистемой, причём учитываем, что **авторизованный пользователь** наследует (обобщает) свойства обычного **пользователя** (может прикрепить карту) и рисуем связь "обобщение":
+
+    ![](../img/usecase03.png)
+
+3. Определение вариантов использования
+
+    >Обратите внимание: связи между акторами и прецедентами **прямые** и рисуются без всяких стрелок
+
+    * **установка приложения** - такой вариант использования есть в описании предметной области, но т.к. он не относится к подсистеме, то его рисуем за пределами подсистемы
+
+        ![](../img/usecase04.png)
+
+    * у обычного пользователя есть только один вариант использования: **регистрация**
+
+        ![](../img/usecase05.png)
+
+        Но при регистрации возникают дополнительные действия (прецеденты): ввод ФИО, лицевого счёта и пароля, и не обязательный ввод данных карты.
+
+        Для обязательных прецедентов используется отношение **включения**, для не обязательных - **расширения**
+
+        ![](../img/usecase06.png)
+
+    * **оплата услуг** авторизованным пользователем. Причём пользователь **должен** внести показания прибора учета. И **может** запросить отчет с **возможным** выбором периода
+
+        ![](../img/usecase07.png)
+
+        После ввода показаний прибора учёта пользователь **должен** подтвердить оплату (обязательное действие, поэтому делаем включение). Если карта не была привязана в личном кабинете, то добавляем через включение действие **ввод данных карты**. **Visio** не полностью реализует стандарт UML - для альтернативных действий там есть специальные формы прецедентов. Но можно альтернативность прецедента акцентировать надписью на стрелке (тип ассоциации и так понятен по направлению стрелки)        
+
+        ![](../img/usecase08.png)
+
+        После подтверждения оплаты система **генерирует квитанцию** (делает это всегда, поэтому включение). Действия пользователя в этом случае не описаны, но т.к. сказано, что система не хранит квитанции, то напрашивается расширение для **сохранения квитанции**
+
+        ![](../img/usecase09.png)
+     
+    * после всего вспомнили, что обычному пользователю для превращения в авторизованного нужно **авторизоваться** и, хотя этого нет в описании предметной области, добавляем этот прецедент:
+
+        ![](../img/usecase10.png)
+
+Итоговый вариант диаграммы прецедентов:
+
+![](../img/usecase11.png)
+
+# Задание для самостоятельной работы:
+
+>Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения 
+>
+>Предполагается, что в системе фитнес центра будет 3 роли пользователей: клиенты, тренеры, администраторы.
+>Авторизация в системе производится по телефону и паролю.
+>
+>Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол. 
+>
+>Администраторы – пользователи с уже заполненным профилем. Они могут добавлять новых тренеров и записывать их на различные курсы обучения с целью поддержки и улучшения их профессиональной квалификации. Постоянным клиентам администраторы могут предоставлять скидки на тренировки.
+>
+>Любой клиент после авторизации может выбрать себе тренера (если у него нет такового).  В этом случае клиент видит список тренеров с именем, фото, полом, стажем работы и списком достижений. Клиент может отправить заявку любому из тренеров, написав при этом цель, которую он хочет достигнуть при тренировках.
+>
+>Тренер после авторизации видит новые заявки от клиентов и их количество (если таковые имеются).  Тренер может принять заявку или отклонить. В случае отказа, тренер должен указать причину. В случае подтверждения заявки тренер должен выставить план индивидуальных занятий для клиента. Выбрав из списка клиентов без плана тренировок, тренер видит цель клиента, его возраст и планирует даты тренировочного цикла. Для индивидуальных занятий тренер может выбрать упражнения, указывая при этом его вид (приседания, отжимания и т.д.), частоту выполнения (сколько раз в неделю), число подходов и число повторений в каждом подходе.
+>
+>Клиент, отправивший заявку, но не получивший ответа, видит список своих заявок с результатами (в том числе с указанием причины при отказе) и количеством дней ожидания ответа. Получив план тренировок, клиент видит экран с 2 вкладками: план тренировок (дата-список упражнений через запятую) и сегодняшний перечень индивидуальных занятий. Для последней выводится список: вид упражнения, количество повторов и Checkbox, позволяющий отметить выполнения, упражнения. Несмотря на это, упражнение не будет засчитано системой до тех пор, пока клиент не укажет показатель своего пульса во время выполнения упражнения. Сверху выводится сегодняшний прогресс (по количеству выполненных упражнений) в процентах с графическим отображением. 
+>
+>Тренер также может посмотреть список своих текущих клиентов с указанием у каждого: проценты выполнения всего цикла тренировок (зависит от длительности цикла) и процента выполненных упражнений (т.к. некоторые упражнения могут быть пропущены). По каждому клиенту выводится средний показатель пульса во время выполнения упражнений.
+
 <table style="width: 100%;"><tr><td style="width: 40%;">
 <a href="../articles/5_1_1_4_analiz.md">Анализ предметной области. Основные понятия системного и структурного анализа.
 </a></td><td style="width: 20%;">

articles/cs_layout.md

@@ -184,7 +184,7 @@ public string TypeAndName {
 
 ![](../img/01072.png)
 
-Как видим, элементы списка отображаются горизонтальным списком, но нет переноса. Для включения переноса элементов нужно в **ListView** отключить горизонтальный скролл, добавив атрибут `ScrollViewer.HorizontalScrollBarVisibility="Disabled"`:
+Как видим, элементы отображаются горизонтальным списком, но нет переноса. Для включения переноса элементов нужно в **ListView** отключить горизонтальный скролл, добавив атрибут `ScrollViewer.HorizontalScrollBarVisibility="Disabled"`:
 
 ![](../img/01073.png)
 

articles/uml_mp_dc_dd.md

@@ -0,0 +1,23 @@
+# Модель проектирования
+
+## Назначение и состав модели проектирования
+
+Назначение **модели проектирования** заключается в создании полного детализированного описания внутренней архитектуры и алгоритмов работы системы. Рекомендуется разрабатывать данную модель без привязки к конкретным языкам программирования, с помощью которых будет создаваться программный продукт, т.е. разрабатывать логическую модель. Стоит оговориться, что создать модель без оглядки на используемые языки программирования невозможно, но, по крайней мере, необходимо стремиться к этому.
+
+Построение этой модели необходимо:
+
+- для уточнения внутренней архитектуры и вариантов использования системы;
+- для уточнения требований;
+- для определения детализированных алгоритмов работы системы в целом и ее отдельных элементов.
+
+При разработке модели анализа рекомендуется построить следующие диаграммы:
+
+- классов;
+- деятельности.
+
+Основное внимание на данной стадии уделяется проектированию классов (их атрибутов и операций), компоновке классов в подсистемы и определению интерфейсов между классами и подсистемами. Детальное описание операций и взаимодействия между классами выполняется с помощью **диаграмм деятельности**, описывающих алгоритмы работы. В разработке алгоритмов, специфичных для предметной области, непосредственное участие должны принимать эксперты-технологи.
+
+## ДИАГРАММЫ КЛАССОВ
+
+### Назначение и состав диаграммы классов
+

readme.md

@@ -81,6 +81,15 @@ http://sergeyteplyakov.blogspot.com/2014/01/microsoft-fakes-state-verification.h
 
 4. [Спецификация вариантов использования (прецедентов)](articles/5_1_1_10_uml_uc_spec.md)
 
+5. [НЕ ДОПИСАНО! Модель проектирования (диаграммы классов, диаграммы деятельности)](articles/uml_mp_dc_dd.md)
+
+<!-- диаграммы последовательностей,  -->
+
+<!-- диаграммы взаимодействия,  -->
+
+<!-- диаграммы состояний,  -->
+
+
 ### Контрольные вопросы
 
 * назовите основные элементы диаграммы прецедентов
@@ -91,6 +100,8 @@ http://sergeyteplyakov.blogspot.com/2014/01/microsoft-fakes-state-verification.h
 
 ### Лекции
 
+<!-- диаграмма сущностей и связей, нормализация, словарь данных -->
+
 1. [Основы проектирования баз данных.](articles/5_1_1_1_erd2.md)
 
 2. [Словарь данных](articles/5_1_1_1_data_dictionary.md)
@@ -644,4 +655,28 @@ ERD,
 
     10. Лабораторная работа «Тестирование установки»
 
- -->
+ -->
+
+<!-- 
+-- создание базы и пользователя для MSSQL
+DECLARE @userName AS VARCHAR(50) = 'test'
+DECLARE @password AS VARCHAR(50) = 'qzesc'
+-- создаю базу
+DECLARE @createDB AS VARCHAR(50) = 'CREATE DATABASE {userName}'
+SET @createDB = REPLACE(@createDB, '{userName}', @userName)
+EXECUTE (@createDB)
+-- создаю логин
+DECLARE @createLogin AS VARCHAR(150) = 'CREATE LOGIN {userName} WITH PASSWORD=''{password}'', CHECK_POLICY = OFF'
+SET @createLogin = REPLACE(@createLogin, '{userName}', @userName)
+SET @createLogin = REPLACE(@createLogin, '{password}', @password)
+EXECUTE (@createLogin)
+-- создаю пользователя
+DECLARE @createUser AS VARCHAR(MAX) = '
+USE {userName}
+CREATE USER {userName} FOR LOGIN {userName};
+EXEC sp_addrolemember ''db_owner'', ''{userName}'';
+Grant Execute on Schema :: dbo TO [{userName}];
+'
+SET @createUser = REPLACE(@createUser, '{userName}', @userName)
+EXECUTE (@createUser)
+-->