API tools faq
paste
pussycontrol

ПиКПО

pussycontrol
Jan 7th, 2020
256
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 51.69 KB | None | 0 0
raw download clone embed print report
  1. SWEBOK (Software Engineering Body of Knowledge) — международный стандарт ISO/IEC TR 19759 от 2015 г., в котором описана общепринятая сумма знаний по программной инженерии.
  2. Документ был создан при сотрудничестве нескольких профессиональных организаций и предприятий и опубликован обществом IEEE Computer Society (IEEE). В 2005 году он был принят как стандарт ISO/IEC TR 19759:2005.
  3. В конце 2013 года был одобрена и опубликована новая версия SWEBOK V3[4], которая стала стандартом ISO/IEC TR 19759:2015.
  4. В 2016 году общество IEEE Computer Society создало комитет SWEBoK Evolution, который будет заниматься дальнейшим развитием документа.
  5. Текущая опубликованная версия SWEBOK V3 включает 15 областей знаний в сфере программной инженерии:
  6. • software requirements — требования к ПО;
  7. • software design — проектирование ПО;
  8. • software construction — конструирование ПО;
  9. • software testing — тестирование ПО;
  10. • software maintenance — сопровождение ПО;
  11. • software configuration management — управление конфигурацией;
  12. • software engineering management — управление IT проектом;
  13. • software engineering process — процесс программной инженерии;
  14. • software engineering models and methods — модели и методы разработки;
  15. • software quality — качество ПО;
  16. • software engineering professional practice — описание критериев профессионализма и компетентности;
  17. • software engineering economics — экономические аспекты разработки ПО;
  18. • computing foundations — основы вычислительных технологий, применимых в разработке ПО;
  19. • mathematical foundations — базовые математические концепции и понятия, применимые в разработке ПО;
  20. • engineering foundations — основы инженерной деятельности.
  21. Кроме того она признает[что?], но не определяет следующие дисциплины:
  22. • Computer engineering
  23. • Systems engineering
  24. • Project management
  25. • Quality management
  26. • General management
  27. • Computer science
  28. • Mathematics
  29.  
  30. Аналогичные инициативы
  31. • Computing Curriculum Software Engineering (CCSE).
  32. • Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. В то время как SWEBOK описывает свод знаний, которыми должен обладать человек после 4 лет практики в сфере программной инженерии, SE2004 описывал свод знаний, которые должен получить студент в университете, обучаясь по специальности программная инженерия (включая знание математики, общих принципов инженерии и прочие сопутствующие навыки).
  33. • 10 лет спустя SE2004 был пересмотрен и из-за растущего объема знаний по теме программной инженерии был разделен на несколько документов: Computer Engineering, Computer Science, Cybersecurity, Information Systems, Information Technology и собственно Software Engineering.
  34. • Основная литература: Curricula Recommendations.
  35.  
  36. Основные понятие проектирования
  37.  
  38. • Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её компонентов называется проектирования.
  39. • Результат процесса проектирования – дизайн
  40. Проектирование программных систем можно рассмотреть как деятельность, результат которой состоит из двух частей:
  41. 1) Архитектурный (высокоуровневый) дизайн – описание структуры системы на самом верхнем уровне, организация компонентов системы
  42. 2) Детализирование архитектуры, описывающей компоненты в том объёме, в котором необходимо для конструирования.
  43. Предлагается следующее разделение видов дизайна:
  44. • D-дизайн (decomposition design) – декомпозиция структуры ПО в виде наборов фрагментов или компонентов.
  45. • FP-дизайн (family pattern) – семейство архитектурных представлений, базируещееся на шаблонах.
  46. • I-дизайн (invention) – создание высокоуровневой концепции ии виденья того, что из себя будет представлять программная система. Этот дизайн является результатом анализа требований анализа и их трансформации в подходы и реализации.
  47.  
  48. Таблица "Проектирование ПО":
  49. https://vk.com/doc150559372_531384852
  50.  
  51. Основы проектирования
  52. • Вводятся концепции, понятия, и терминология в качестве основы для понимания роли и содержания проектирования и дизайна ПО.
  53. • Общие концепции: цель архитектуры, её ограничения, возможные альтернативы, используемые представления и решения.
  54. Цели:
  55.  улучшение, повышение эффективности бизнес-процеса
  56.  уменьшения затрат
  57.  уменьшение рисков улучшение характеристик безопасности
  58.  повышение интероперабельности
  59.  контекст проектирования: для понимания роли проектирования в ПО важно понимать контекст, в котором осуществляется проектирование и используется его результаты.
  60. Для процесса проектирования контекстом является жизненный цикл пр. инж-и (не разобрал сокращение, «программной инженерии» не совсем подходит по контексту). При этом проектирования связано с результатом анализа требований, а также конструирование систем.
  61. Для описания жизненного цикла используется ряд стандартов(ГОСТ-Р 12277).
  62.  
  63. {За это предложение не уверен}Процесс проектирования в основном рассматривается как двухшаговый процесс: архитектурный и детализационный. Результатом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований к ПО.
  64. Техники применения – в первую очередь рассматриваются принципы проектирования.
  65. Абстракция (два механизма – параметризация и специфицирование)
  66. Абстракция через специфицирование бывает трёх видов:
  67. 1) процедурная(динамическая или описание поведения)
  68. 2) абстракция данных(статическая)
  69. 3) абстракция контроля/управления
  70.  
  71. Связность и соединение
  72. Связность определяет силу связи между моделями(coupling).
  73. Соединение – как тот или иной предмет обеспечивает связь внутри модуля или внутреннюю связь.
  74. Связность и соединение становятся важными при использовании сервисной структуры приложения.
  75.  
  76. Декомпозиция и разбиение на модули
  77. Иерархия – способ борьбы со сложностью.
  78.  
  79. Инкапсуляция
  80. {Не разобрал сокращение} Д. концепция предполагает группировку и упаковку элементов и внутренних деталей абстракции в отношении реализации с тем, чтобы эти детали были недоступны «пользователю» этой системы.
  81. В качестве пользователя могут выступать другие компоненты.
  82.  
  83. Разделение интерфейса и реализации
  84. Компонент определяется через специфицирование интерфейса, описанного и доступного клиентам и другим компонентам.
  85.  
  86. Доступность, полнота и простота
  87. Создаваемые программные компоненты обладают всеми необходимыми характеристиками, определёнными абстракцией(моделью), но не более того.(не включает функциональность, которая не определена в модели)
  88. Так же, как и в любой сфере деятельности, представляется в виде рекомендуемых практик.
  89.  
  90. Ключевые вопросы проектирования
  91. • Как проводить декомпозицию?
  92. • Как организовать компоненты в единую систему?
  93. • Как обеспечить необходимую производительность?
  94. • Как обеспечить приемлемое качество системы?
  95. Это минимальный набор типовых вопросов.
  96. 1) Параллелизм(concurrency):
  97. Вопросы, подходы и методы организации процессов, задач, потоков для обеспечения эффективности, {???} атомарности, синхронизации и распределения по времени обработки информации.
  98. 2) Контроль и обработка событий
  99. 3) Распределение компонентов и выполнение по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры, среды исполнения и т.д.
  100. Наиболее сложным и важным вопросом является использование связующего ПО.
  101. 4) Обработка ошибок и исключительных ситуаций, обеспечение отказоустойчивости.
  102. 5) Взаимодействие и представление
  103. Тема касается вопросов представления информации пользователем и взаимодействие пользователя с системой с точки зрения системы и реакций пользователя.(описывает то как система реагирует на действия пользователя и организует отклик).
  104. Эти вопросы не связаны с эргономикой(самим интерфейсом).
  105. 6) Сохраняемость данных(именно сохраняемость, а не сохранность)
  106.  
  107. Структура и архитектура ПО
  108. В строгом значении архитектура ПО означает архитектуру компонент программной системы, а также связей между ними.
  109. Архитектура пытается определить внутреннюю структуру системы, задавая способ, которым система организована и конструируется.
  110. Основной подход – клиент-серверный.
  111. 1) Архитектурные структуры и точки зрения.
  112. Любая система может рассматриваться с разных точек зрения(поведенческая, динамическая, структурная, статическая), логическая(удовлетворённость функциональных требований), физическая(распределённость), реализации(как детали архитектуры, представленные в коде).
  113. В результате мы получаем различные архитектурные представления. Архитектурное представление может быть определённо как частные аспекты программной архитектуры, рассматривающее специфические свойства программной системы.
  114. Существует модель Захмана(Захман фреймворк).
  115. 2) Архитектурные стили
  116. Архитектурный стиль по смыслу – метамодель или шаблон проектирования макроархитектуры.
  117. Например, архитектуры распределённой сервисно-ориентированной системы может строиться в стиле обмена сообщениями через соответствующие очереди сообщений. Другое решение – взаимодействие через общую объектную шину. Третий вариант – использовать концепцию брокера как единого узла пересылки запросов.
  118. В целом, архитектурный стиль – это набор ограничений, который позволяет отсеять архитектурные решения, не подходящие решению.
  119. 3) Шаблоны проектирования
  120. Общий смысл:
  121. Общее решение общей проблемы в заданном контексте.
  122. В отличие от архитектурного стиля(определяет макроархитектуру), шаблоны проектирования задают микроархитектуру, т.е. определяют частные аспекты деталей архитектуры.
  123. 4) Семейство программ и фреймворков.
  124. При разработке систем стремятся к использованию существующего кода.
  125. Один из подходов к повторному использованию архитектурных решений и компонент заключается в выборе дизайна системы. В ООП аналогичную смысловую нагрузку несут те же самые фреймворки.
  126. Анализ качества и оценка программного дизайна
  127. Атрибуты качества:
  128. Тестируемость, переносимость, модифицируемость, производительность, безопасность и т.д.
  129. Как правило, эти атрибуты характеризуют результат проектирования, но не сам процесс.
  130. Большинство атрибутов можно разобрать на следующие группы:
  131. • Применимые по времени системы(Среднее время отклика)
  132. • Ориентированные на этап проектирования вплоть до тестирования(включая тестирование)(средняя нагруженность класса в бизнес-процессе)
  133. • Атрибуты качества архитектурного дизайна как такового, например: концептуальная целостность, непротиворечивость, полнота, завершённость.
  134. Необходимо отличать требования к качеству дизайна и соответствующие атрибуты от атрибутов качества самой системы.
  135. Если рассматривать измеримую часть атрибутов, то для каждого должна быть задана определённая метрика, которая обеспечивает однозначное толкование всеми участниками проектирования
  136. Анализ качества и техники оценки
  137. В программной индустрии используется большое количество инструментов, техник и практик, помогающих добиться {???} начального дизайна.
  138. Обзор дизайна может проходить в разных методиках:
  139. • Статический анализ(трассировка с требованиями)
  140. • Симуляция и прототипирование: динамические техники проверки дизайна в целом или отдельных его атрибутов качества.
  141. • Измерения: важным аспектом в оценке является использование метрик. Они используются для количественных атрибутов.
  142. Все метрики делятся на функционально- и объектно-ориентированные.
  143. 5) Нотации проектирования
  144. Нотация – соглашение о представлении (чаще всего под нотацией понимается визуальное графическое представление)
  145. Способы:
  146. 1. Следование стандартам (UML например)
  147. 2. Общепринятая практика (в экстремальном программировании часто используют карточки функциональной ответственности и связи классов).
  148. 3. Внутренние методы проектной команды
  149. Определённые нотации используют на этапе концептуального проектирования, отдельные нотации применяют для детального дизайна, некоторые могут использоваться на обеих стадиях.
  150. Структурное описание {???}характеристический статический взгляд
  151. • Языки описания архитектуры (как правило это текстовые языки, достаточно часто формальные. Обычно используются для описания программной архитектуры в терминах компонентов.)
  152. • Диаграммы классов и объектов (используются для описания классов и статических связей между ними)
  153. • Диаграммы компонентов (компонент в отличие от класса рассматривается как физически реализуемый объект ПО, несущий самодостаточную логику и реализуется как совокупность интерфейса и его реализация)
  154. • Карточки функциональной ответственности и связей классов. В литературе часто упоминается класс «обязанности-операции»
  155. • Диаграммы развёртывания (используются для представления физических узлов, связей между ними и моделирования других аспектов системы)
  156. • Диаграммы «сущность-связь»
  157. • Языки описания или определения интерфейса (HTML, XML)
  158. • Структурные диаграммы Джексона (используются для описания структур данных в терминах последовательности выборов и операций).
  159. • Структурный схемы, основное назначение которых – описание структуры вызовов в программе.
  160. Поведенческое описание (динамический взгляд)
  161. Используется в том числе для описания дизайна.
  162. • Диаграммы деятельности или операции (описание потоков работ и управления)
  163. • Диаграммы сотрудничества (показывает динамическое взаимодействие происходящее в группе объектов. В этой нотации особое внимание уделяется объектам, связям между ними и сообщениями, передающимися между ними.
  164. • Диаграммы потоков данных
  165. • Таблицы и диаграммы принятия решений (табличная форма использует представления сложных комбинаций условий и действий)
  166. • Блок-схемы и структурированные блок-схемы (для описания потоков управления и действий)
  167. • Диаграммы последовательностей (акцентированное внимание на сообщениях и вызовах)
  168. • Диаграммы перехода и карт состояний (потоки управления переходов между состояниями)
  169. • Формальные языки спецификаций (текстовые языки, использующие основные понятия из математики для строгого и абстрактного определения интерфейсов и поведения программных компонентов часто в терминах пред- и пост- условий.)
  170. • Псевдокод и формальные языки проектирования (языки, использующиеся для описания поведения процедур и методов в основном на стадии детального проектирования)
  171. 6) Стратегии и методы проектирования ПО
  172. Существуют различные общие стратегии, помогающие в проведении работ по проектированию. Кроме этого, существуют методы проектирования, являющиеся более специфичными и, как правило, включающие нотации и процессы, которым необходимо {???} следование в рамках метода.
  173. Общие стратегии:
  174. • «Разделяй и властвуй» и пошаговое уточнение
  175. • «Сверху-вниз» и «снизу-вверх»
  176. • «Абстракция данных» и сокрытие информации
  177. • Иттеративный и инкреметальный подход
  178. • и др.
  179. Структурное проектирование:
  180. Структура программы детализируется и уточняется при движении сверху вниз. При таком подходе часто используют диаграммы потоков данных.
  181. Объектно-ориентированное проектирование
  182. Множество методов проектирования базируется на концепции объектов (главная роль – полиморфизм и инкапсуляция). Идейно ООП выросло из концепции абстракции данных.
  183. Проектирование на основе функциональной ответственности часто рассматривается как противоположный метод ООП.
  184. Проектирование на основе структур данных.
  185. Рассматривается с трёх точек зрения (вход, выход, хранение). Затем строятся функции, управляющие потоками данных.
  186. Компонентное проектирование
  187. Программные компоненты определяются как независимые единицы, которые обладают однозначно определёнными интерфейсами и зависимостями и могут собираться и развёртываться независимо друг от друга.
  188. Такой подход используется для решения задач {???}использования разработки и интеграции компонентов с целью увеличения уровня повторного использования.
  189. Методология IDEF0
  190. Методология функционального моделирования IDEF0 – это технология описания системы в целом как множество взаимно-значимых действий или функций.
  191. Функции системы исследуются независимо от объектов, которые обеспечивают их выполнение.
  192. IDEF0 применяется на ранних этапах разработки проекта(анализ).
  193. Построение модели IDEF0 заключается в следующих действиях:
  194.  Сбор информации об объекте, определение его границ
  195.  Определение цели и точки зрения
  196.  Построение обобщения и декомпозиция диаграмм
  197.  Критическая оценка, рецензирование и комментирование
  198. Модель ICOM
  199. Действие обычно в IDEF0 называется функцией. Их обработка переводит входные данные в выходные.
  200. Функции отображаются на диаграмме как прямоугольники или функциональные блоки.
  201. Для отображения информации существует аббревиатура ICOM
  202. I(Input) – Вход
  203. C(Control) – Управление
  204. O(Output) – Выход
  205. M(Mechanism) – Исполняющий механизм
  206. Рисунок «функциональный блок»:
  207. https://vk.com/doc150559372_531660887
  208. Соединения:
  209. Существует 5 основных видов комбинаций стрелок
  210.  выход – вход
  211.  выход – управление
  212.  выход – механизм
  213.  выход – обратная связь на управление (Аналогично пикче снизу только на управление)
  214.  выход – обратная связь на вход (https://vk.com/doc150559372_531661013)
  215.  
  216. Разбиение и соединение стрелок:
  217. Рисунок: https://vk.com/doc150559372_531786672
  218. Туннели(стрелка, которая возникает только на дочерней диаграмме, но не на родительской)
  219. Рисунок: https://vk.com/doc150559372_531787692
  220. Правила построения диаграмм:
  221. Синтаксис диаграмм определяется следующими правилами:
  222.  Диаграммы содержат блоки и дуги
  223.  Блоки представляют функции
  224.  Количество блоков на диаграмме ограниченно: от 3 до 6
  225.  Блоки имеют доминирование(выражается в ступенчатом расположении, причём доминирующий блок расположен в верхнем левом углу диаграммы)
  226.  Дуги изображают наборы объектов, передаваемые между блоками.
  227.  Дуги изображают взаимосвязи между блоками: выход, управление, выход-вход, обратная связь по управлению/входу, выход-механизм.
  228. Контекстная диаграмма – А0
  229. Детализационная диаграмма – А1, А2,…
  230. Дальнейшая детализация – А11,А12,…
  231. ICOM-коды:
  232. https://vk.com/doc150559372_531789585
  233. Без входа может быть
  234. Без выхода не бывает
  235. Стратегии декомпозиции:
  236. • Функциональная декомпозиция
  237. • Декомпозиция в соответствии с известными стабильными подсистемами
  238. • декомпозиция по физическому процессу
  239. Признаки завершения декомпозиции блока:
  240. 1) Блок содержит достаточно деталей
  241. 2) Необходимо изменить уровень абстракции, чтобы достичь большей детализации блока.
  242. 3) необходимо изменить точку зрения чтобы детализировать блок
  243. 4) блок очень похож на другой блок той же модели или на блок другой модели.
  244. 5) Блок представляет тривиальную функцию
  245. Дополнительные виды диаграмм IDEF0:
  246. • Дерево моделей
  247. • Презентационные диаграммы (FEO (For Exposition Only) diagram)
  248. Часто включаются в модели, чтобы проиллюстрировать другие точки зрения или детали выходящие за рамки традиционного синтаксиса IDEF0.
  249. Виды:
  250. 1) Копия диаграммы IDEF0, которая содержит все функциональные блоки и стрики, относящиеся к одному из функциональных блоков.
  251. 2) копия диаграммы IDEF0, которая содержит функциональные блок и стрелки, относящиеся только к входу и (или) выходу родительского блока.
  252. 3) различные точки зрения, как правило, на глубину одного уровня декомпозиции.
  253. IDEF0 и IDEF1X представляют собой словарь, формируемый из обозначений стрелок на IDEF0, предоставляющих массив терминов, которые являются кандидатами либо на атрибут, либо на сущность.
  254. IDEF1X
  255. Сущность в IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
  256. Независимая (однозначно идентифицируемая) сущность рисуется с прямыми углами. Зависимая (неоднозначно идентифицируемая) рисуется с закруглёнными углами. Идентифицирующая связь – прямая линия, неидентифицирующая – пунктирная.
  257. Уровни моделей IDEF1X
  258. Таблица: https://vk.com/doc150559372_531792566
  259. В IDEF3 основной элемент – единица работы
  260. https://vk.com/doc150559372_531792887
  261. Диаграммы UML
  262. Диаграмма вариантов использования языка UML
  263. https://vk.com/doc150559372_531793075
  264. Проблемы с переводом терминов:
  265. source state – исходной состояние (правильно – состояние-источник)
  266. opaque state – непрозрачное выражение (правильно – неопределённое выражение)
  267. Событие – это описание группы возможных вхождений.
  268. История(трассировка) описывает уникальные объекты и вхождения, но модели имеют дело с потоками, применимыми ко многим объектам и {???} вхождениям. (не точный перевод с английского occurrence)
  269. Линия {???} жизни представляет собой последовательность спецификации вхождений.
  270. Классификация моделей в языке UML:
  271. 1) Структурные модели (structured models) – модели, предназначенные для описания статической структуры сущностей или элементов некоторой системы, их классы, интерфейсы, атрибуты и отношения.
  272. 2) Модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая методы и взаимодействие между ними, а так же изменения состояний отдельных элементов и системы в целом.
  273.  
  274. UML 2.x
  275. Новые типы диаграмм: Composite structure, interaction overview, timing.
  276. Упрощение cooperation diagram и переименование в Communication diagram.
  277.  
  278. Канонические диаграммы UML 2.x
  279. https://vk.com/doc150559372_532015098
  280.  
  281. Взаимосвязь представлений сложной системы
  282. https://vk.com/doc150559372_531925742
  283.  
  284. Общие рекомендации по изображению диаграмм
  285. • Качество диаграмм различных типов для модели концептуального представления не является строго фиксированным.
  286. • Любая из моделей системы должна содержать только те элементы, {???} которые определены в соответствии версии UML.
  287. • Каждая диаграмма в нотации UML 2.х имеет область содержания для изображения {???} представления узлов и путей между ними, которые представляют собой собственно элементы модели в нотации UML 2.х.
  288. • Фрейм в нотации UML 2.x используется в случаях, когда отдельные элементы диаграмм имеют графическую границу с другими элементами системы.
  289.  
  290. Изображение диаграмм UML 2.x в виде фрейма
  291. https://vk.com/doc150559372_531925949
  292.  
  293. Теги заголовков и их сокращения для диаграмм UML 2.x
  294. https://vk.com/doc150559372_531926198
  295.  
  296. Механизмы расширения языка UML
  297. https://vk.com/doc150559372_531926201
  298.  
  299. Стереотипы в языке UML
  300. https://vk.com/doc150559372_531979167
  301.  
  302. Использования стереотипов
  303. https://vk.com/doc150559372_531979191
  304.  
  305. Графические стереотипы компонентов в IBM Rational Rose
  306. https://vk.com/doc150559372_531979219
  307.  
  308. Ограничения в UML
  309. https://vk.com/doc150559372_531982963
  310.  
  311. Помеченные значения в языке UML
  312. https://vk.com/doc150559372_531990667
  313.  
  314. Диаграмма вариантов использования
  315. Диаграммы вариантов использования применяется для модуля статического вида диаграммы с точки зрения вариантов использования этот вид охватывает поведение системы, т.е. видимые сервисы, представляемые системой в контексте окружения.
  316. Конце́пция (от лат. conceptio «система понимания») – определённый способ понимания, трактовки каких-либо явлений; основная точка зрения, руководящая идея для их освещения. Концепция определяет стратегию действий. Различным концепциям соответствует свой терминологический аппарат.
  317. • Диаграмма, на которой изображены варианты использования проект. системы, заключается в границу системы.
  318. • внешние актёры
  319. • а также определяет отношения между актёрами и вариантами использованиями <<extend>>
  320. https://vk.com/doc150559372_532010033
  321.  
  322. Назначение диаграммы вариантов
  323. https://vk.com/doc150559372_532141893
  324.  
  325. Проектируемая система и её окружение
  326. https://vk.com/doc150559372_532141929
  327.  
  328. Основные обозначения на диаграмме вариантов использования
  329. https://vk.com/doc150559372_532141962
  330.  
  331. Вариант использования (use case)
  332. https://vk.com/doc150559372_532142022
  333.  
  334. Актёр(actor)
  335. https://vk.com/doc150559372_532142057
  336.  
  337. Вопросы для идентификации актёров в системе
  338. https://vk.com/doc150559372_532142088
  339.  
  340. Отношения на диаграмме вариантов использования
  341. https://vk.com/doc150559372_532140014
  342.  
  343. Отношение ассоциации
  344. https://vk.com/doc150559372_532142126
  345.  
  346. Отношение включения
  347. https://vk.com/doc150559372_532142161
  348.  
  349. Отношения расширения
  350. https://vk.com/doc150559372_532142191
  351.  
  352. Изображение отношения расширения с условием выполнения
  353. https://vk.com/doc150559372_532142248
  354.  
  355. Отношение обобщения
  356. https://vk.com/doc150559372_532142277
  357.  
  358. Что внутри {???} UC2
  359. https://vk.com/doc150559372_532141575
  360.  
  361. Диаграмма вариантов использования для модели банкомата
  362. https://vk.com/doc150559372_532141581
  363.  
  364. Пример диаграммы ВИ для систем продажи товаров в Интернет-магазине.
  365. https://vk.com/doc150559372_532537620
  366.  
  367. Типичные ошибки при разработке диаграмм вариантов использования
  368. https://vk.com/doc150559372_532537692
  369.  
  370. Формализация функциональных требований с помощью диаграммы ВИ
  371. https://vk.com/doc150559372_532537720
  372.  
  373. Классификация требований - модель FURPS+
  374. https://vk.com/doc150559372_532537592
  375.  
  376. Functionality
  377. https://vk.com/doc150559372_532537547
  378.  
  379. Текстовые сценарии в UML
  380. https://vk.com/doc150559372_532537674
  381.  
  382. Спецификации ВИ с помощью текстовых сценариев
  383. https://vk.com/doc150559372_532537658
  384.  
  385. Шаблон для написания сценария отдельного варианта использования
  386. https://vk.com/doc150559372_532537822
  387. https://vk.com/doc150559372_532537843
  388.  
  389. ГЛАВНЫЙ РАЗДЕЛ сценария выполнения варианта использования «Снятие наличных по кредитной карте»
  390. https://vk.com/doc150559372_532537575
  391.  
  392. Раздел ТИПИЧНЫЙ ход событий сценария выполнения варианта использования Снятие наличный по кредитной карточке
  393. https://vk.com/doc150559372_532537639
  394.  
  395. Раздел ИСКЛЮЧЕНИЯ сценария выполнения варианта использования Снятие наличных по кредитной карточке
  396. https://vk.com/doc150559372_532554923
  397.  
  398. Последовательность разработки вариантов использования
  399. https://vk.com/doc150559372_532554909
  400.  
  401. Показатели качества для модели вариантов использования
  402. https://vk.com/doc150559372_532554905
  403.  
  404. UML Profile for Business Modeling
  405. https://vk.com/doc150559372_532554892
  406. https://vk.com/doc150559372_532554895
  407.  
  408. Диаграммы вариантов использования для системы продаж товаров по каталогу в UML Profile for Business Modeling
  409. https://vk.com/doc150559372_532554900
  410.  
  411. Примеры оформления сценариев
  412. Сценарий №1 выполнения ВИ «Снятие наличных по кредитной карточке»
  413. https://vk.com/doc150559372_532554948
  414.  
  415. Раздел Типичный ход событий
  416. https://vk.com/doc150559372_532554932
  417. https://vk.com/doc150559372_532554939
  418.  
  419. Раздел Исключений
  420. https://vk.com/doc150559372_532554916
  421.  
  422. Сценарий №2 «Получение справки о состоянии счёта»
  423. https://vk.com/doc150559372_532554951
  424.  
  425. Типичный ход событий
  426. https://vk.com/doc150559372_532554884
  427. https://vk.com/doc150559372_532554887
  428.  
  429. Раздел Исключений
  430. https://vk.com/doc150559372_532688076
  431. https://vk.com/doc150559372_532688079
  432. Приведённого описания для базового функционала достаточно
  433.  
  434. Примеры использования диаграммы UC
  435. https://vk.com/doc150559372_532688107. Пользователями такой системы будут различные клиенты системы(бизнес-актёры), поскольку система создаётся именно для них. А сама система будет предоставлять для них бизнес-случаи использования.
  436.  
  437. Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок
  438. https://vk.com/doc150559372_532688102
  439.  
  440. Диаграмма вариантов использования. Бизнес UC
  441. https://vk.com/doc150559372_532688098
  442.  
  443. Диаграмма UC.
  444. Моделирование контекста системы.
  445. https://vk.com/doc150559372_532688085
  446.  
  447. Моделирование требований к системе
  448. (знаю, зашакалено, но имеем что имеем, у Ромы в лекциях эта диаграмма то ли зачёркнута, то ли чо, но вот) https://vk.com/doc150559372_532688091
  449.  
  450. Проектирование и конструирование ПО
  451. Тема 2. Конструирование ПО
  452. Термин конструирование ПО (software construction) описывает детальное создание рабочей программной системы посредством комбинации кодирования, верификации(проверки), модульного тестирования(unit testing), интеграционного тестирования и отладки.
  453. Данная область знаний связана с другими областями. Наиболее сильная связь существует с проектированием (Software Design) и тестированием (Software Testing). Причиной этого является то, что сам по себе процесс конструирования программного обеспечения затрагивает важные аспекты деятельности по проектированию и тестированию. Кроме того, конструирование отталкивается от результатов проектирования, а тестирование (в любой своей форме) предполагает работу с результатами конструирования. Достаточно сложно определить границы между проектированием, конструированием и тестированием, так как все они связаны в единый комплекс процессов жизненного цикла и, в зависимости от выбранной модели жизненного цикла и применяемых методов (методологии), такое разделение может выглядеть по разному.
  454. Хотя ряд операций по проектированию детального дизайна может происходить до стадии конструирования, большой объем такого рода проектных работ происходит параллельно с конструированием или как его часть. Это есть суть связи с областью знаний «Проектирование программного обеспечения».
  455. В свою очередь, на протяжении всей деятельности по конструированию, инженеры используют модульное и интеграционное тестирование. Таким образом, данная область знаний связана с «Тестированием программного обеспечения».
  456. В процессе конструирования обычно создается большая часть активов программного проекта — конфигурационных элементов. Поэтому в реальных проектах просто невозможно рассматривать деятельность по конструированию в отрыве от области знаний «Конфигурационного управления» (Software Configuration Management).
  457. Так как конструирование невозможно без использования соответствующего инструментария и, вероятно, данная деятельность является наиболее инструментально-насыщенной, важную роль в конструировании играет область знаний «Инструменты и методы программной инженерии» (Software Engineering Tools and Methods).
  458. Важны вопросы обеспечения качества, связанные с областью «качество ПО»
  459. Конструирование ПО касается Computer science и Project management
  460. https://vk.com/doc150559372_532688884
  461.  
  462. Основы конструирования
  463. Основная идея конструирования включает:
  464. • минимизацию сложности
  465. • ожидание изменений
  466. • конструирование с возможностью проверки
  467. • стандарты конструирования
  468. Минимизация сложности
  469. Основная причина использования компьютеров – сложная структура и большой объём хранимой информации в течение длительного времени.
  470. В отличии от требований к {??? на всё дальнейшее предложение} диаграммам, формирующий код приложений должен быть простым и легкочитабельным.
  471. Достаточно часто в ущерб эффективности, код делают проще.
  472. В сторону минимизации сложности направлена необходимость следования определённым стандартам.
  473. Ожидание изменений
  474. Большинство ПО меняется с течение времени. Причин этому множество. Это одна из движущих сил конструирования.
  475. Конструирование с возможностью проверки
  476. Данный раздел подразумевает, что построение программных систем должно вестись таким образом, чтобы сама программная система помогала вести поиск причин сбоев, т.е. была прозрачной для применения методов проверки как на стадии тестирования, так и в процессе эксплуатации.
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!