🗊Презентация Техническое задание. Наименование и область применения

Структура домашнего задания

ТЕХНИЧЕСКОЕ ЗАДАНИЕ В разделе "Наименование и область применения" указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. В разделе "Основание для разработки" должны быть указаны: документ (документы), на основании которых ведется разработка; организация, утвердившая этот документ, и дата его утверждения; наименование и (или) условное обозначение темы разработки. В разделе " Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Раздел "Технические требования к программе или программному изделию" должен содержать следующие подразделы: требования к функциональным характеристикам; состав выполняемых функций, организации входных и выходных данных, временные характеристики и т.п. требования к надёжности (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.); условия эксплуатации (интерфейс, а также вид обслуживания, необходимое количество и квалификация персонала.) требования к составу и параметрам технических средств; состав технических средств с указанием их технических характеристик требования к информационной и программной совместимости; (решения, исходные коды, языки программирования) требования к упаковке; требования к транспортированию и хранению; специальные требования. В разделе "Технико-экономические показатели" должны быть указаны: экономическая эффективность, предполагаемая годовая потребность, преимущества разработки по сравнению с аналогами. В разделе "Стадии и этапы разработки" устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей. В разделе "Порядок контроля и приёмки" должны быть указаны виды испытаний и общие требования к приёмке работы.

Особенности изображения графического элементов диаграмм языка UML

Диаграмма вариантов использования (use case diagram) диаграмма, на которой изображаются варианты использования проектируемой системы, заключенные в границу системы, и внешние актеры, а также определенные отношения между актерами и вариантами использования

Основные обозначения на диаграмме вариантов использования

Вариант использования (use case) – представляет собой общую спецификацию совокупности выполняемых системой действий с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?» Имена – отглагольное существительное или глагол в неопределенной форме

Актер (actor) – любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач Примеры актеров: кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон

Вопросы для идентификации актеров в системе Какие организации или лица будут использовать систему Кто будет получать пользу от использования системы Кто будет использовать информацию от системы Будет ли использовать система внешние ресурсы Может ли один пользователь играть несколько ролей при взаимодействии с системой Могут ли различные пользователи играть одну роль при взаимодействии с системой Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми или другими органами

Отношение ассоциации Ассоциация (association) является одним из фундаментальных понятий в языке UML 2.х и может использоваться на различных канонических диаграммах при построении визуальных моделей Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.

Отношение включения Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента Отношение включения (include) специфицирует тот факт, что некоторый вариант использования содержит поведение, определенное в другом варианте использования

Отношение расширения Отношение расширения (extend) определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.

Изображение отношения расширения с условием выполнения

Отношение обобщения Отношение обобщения (generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели

Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Спецификация ВИ с помощью текстовых сценариев Сценарий (scenario) – специально написанный текст, который описывает поведение моделируемой системы в форме последовательности выполняемых действий актеров и самой системы.

Типичные ошибки при разработке диаграмм вариантов использования Превращение диаграммы вариантов использования в диаграмму деятельности за счет желания отразить все функциональные действия Инициатором действий является разрабатываемая система Спецификация атрибутов и операций классов до того, как сформулированы все варианты использования Задание слишком кратких имен вариантам использования Описание вариантов использования в терминологии, непонятной пользователям системы или заказчику Отсутствие описаний альтернативных последовательностей действий Тратится слишком много времени на решение вопросов о том, какие стереотипы и ассоциации использовать на диаграмме

Диаграмма деятельности (activity diagram) – диаграмма, которая изображает поведение объекта или системы с использованием моделей потока данных и потока управления Деятельность (activity) является спецификацией параметризованного поведения в форме координируемой последовательности подчиненных единиц, индивидуальными элементами которых являются действия Элементами, из которых состоят деятельности, являются действия Действие (action) представляет собой элементарную единицу спецификации поведения, которая не может быть далее декомпозирована в форме деятельности

Узел деятельности (activity node) - является абстрактным классом для отдельных точек в потоке деятельности, соединенных дугами Дуга деятельности (activity edge) является абстрактным классом для направленных соединений между двумя узлами деятельности

Поток управления (control flow) - представляется в форме дуги деятельности, которая связывает между собой два узла деятельности и по которой передаются только маркеры управления При этом все маркеры управления, которые предлагаются узлом источником, предлагаются узлу цели, а вдоль дуги потока управления не могут следовать объекты и данные

Поток объектов (object flow) - представляется в форме дуги деятельности, по которой передаются только маркеры объектов или данных При этом все маркеры, предлагаемые узлом источником, предлагаются для узла цели с учетом ограничений, которые могут быть дополнительно специфицированы с помощью веса дуги Узлы объектов, соединенные потоком объектов с необязательными промежуточными узлами действий или управления, должны иметь совместимые типы

Варианты нотация для деятельности

Семантика деятельности Семантика деятельности в языке UML 2.х основывается на потоке маркеров Маркер (token) – элемент модели, предназначенный для представления некоторого объекта, данных или управления и существующий на диаграмме деятельности в отдельном узле Каждый маркер отличается от любого другого, даже если он содержит то же значение, что и другой Любой узел деятельности может начать свое выполнение, только если удовлетворены специфицированные условия для его входных маркеров, причем эти условия зависят от вида узла Когда узел начинает свое выполнение, маркеры принимаются из некоторых или всех его входных дуг, а специальный маркер размещается в этом узле Когда узел завершает выполнение, специальный маркер удаляется из этого узла, а другие маркеры предлагаются в некоторых или всех его выходных дугах

Семантика действия Выполнение действия становится возможным, когда удовлетворены предварительные условия для его потоков управления и объектов Выполнение действия поглощает входные маркеры управления и маркеры объектов и удаляет их из источников дуг управления и из входных контактов Если на одной дуге являются доступными несколько маркеров управления, то они все поглощаются Действие продолжает выполнение до тех пор, пока оно не будет завершено После завершения действия оно предлагает маркеры объектов во все его выходные контакты, а маркеры управления во все выходящие из него дуги управления, и на этом формально оно заканчивается После окончания выполнения действия с помощью некоторой реализации должны быть восстановлены его ресурсы

Узлы управления Начальный узел (initial node) является узлом управления, в котором начинается поток при вызове деятельности Узел финала деятельности (activity final node) является узлом управления, который прекращает или останавливает все потоки в деятельности Узел финала потока (flow final node) является финальным узлом, который завершает отдельный поток управления или поток объектов, не завершая содержащей его деятельности

Узел решения (decision node) - является узлом управления, который выбирает между выходящими потоками Если для узла решения при оценивании оказываются справедливыми более одного сторожевого условия, то семантика такого поведения в языке UML 2.х не определена, поскольку среди выходящих дуг возникает состязание за прием маркера При отсутствии дополнительной спецификации это может привести к несостоятельной (ill-formed) модели Чтобы гарантировать выполнение только одного сторожевого условия, иногда удобно использовать процедуру проверки до первого истинного условия

Варианты изображения узла решения

Узел слияния (merge node) - является узлом управления, который соединяет вместе несколько альтернативных потоков

Пример последовательного ветвления

Узел разделения (fork node) - является узлом управления, который расщепляет поток на несколько параллельных потоков Дуги, выходящие из узла разделения, дополнительно могут иметь сторожевые условия, при невыполнении которых могут возникать паузы с передачей маркеров по этим дугам В данном случае предполагается, что никакие из находящихся далее узлов соединения не зависят от прохода маркеров, передающихся через дугу со сторожевым условием Если этого исключить нельзя, то необходимо ввести узел решения с последующим узлом слияния

Узел соединения (join node) - является узлом управления, который синхронизирует несколько потоков Узлы соединения могут иметь дополнительную логическую спецификацию условий, при выполнении которых они должны генерировать маркер на выходе Если для узла соединения существуют маркеры во всех его входящих дугах, то выходящей дуге предлагаются маркеры согласно следующим правилам: Если все маркеры, предлагаемые на входящих дугах, являются маркерами управления, то выходящей дуге предлагается один маркер управления

Примеры изображения узла соединения Если часть маркеров, предлагаемых на входящих дугах, являются маркерами управления, а другие являются маркерами данных, то выходящей дуге предлагаются только маркеры данных Они предлагаются выходящей дуге в том же порядке, в каком предлагаются на входе этого узла соединения

Примеры изображения узла соединения с дополнительной спецификацией

Пример условно-параллельных деятельностей Дуги, выходящие из узла разделения, дополнительно могут иметь сторожевые условия, при невыполнении которых могут возникать паузы с передачей управления по этим дугам

Пример деятельности с входным параметром

Диаграмма классов — основная логическая модель проектируемой системы Диаграмма классов (class diagram) — диаграмма, предназначенная для представления модели статической структуры программной системы в терминологии классов объектно-ориентированного программирования Диаграмма классов представляет собой граф, вершинами или узлами которого являются элементы типа “классификатор”, которые связаны различными типами структурных отношений Классификатор (classifier) – специальное понятие, предназначенное для классификации экземпляров, которые имеют общие характеристики

Характеристики классификатора Характеристика (feature) – понятие, предназначенное для спецификации особенностей структуры и поведения экземпляров классификаторов Структурная характеристика (structural feature) является типизированной характеристикой классификатора, которая специфицирует структуру его экземпляров Характеристика поведения (behavioral feature) является характеристикой классификатора, которая специфицирует некоторый аспект поведения его экземпляров Класс (class) – элемент модели, который описывает множество объектов, имеющих одинаковые спецификации характеристик, ограничений и семантики

Основные обозначения на диаграмме классов

Варианты графического изображения класса на диаграмме классов

Разновидности классов Абстрактный (abstract) класс не имеет экземпляров или объектов, для обозначения его имени используется наклонный шрифт (курсив) Активный класс (active class) – класс, каждый экземпляр которого имеет свою собственную нить управления Пассивный класс (passive class) – класс, каждый экземпляр которого выполняется в контексте некоторого другого объекта Квалифицированное имя (qualified name) используется для того, чтобы явно указать, к какому пакету относится тот или иной класс. Для этого применяется специальный символ в качестве разделителя имени – двойное двоеточие “::” Имя класса без символа разделителя называется простым именем класса

Вид видимости + public (общедоступный). Общедоступный элемент является видимым всеми элементами, который имеют доступ к содержимому пространства имен, который им владеет. - private (закрытый). Закрытый элемент является видимым только внутри пространства имен, который им владеет. # protected (защищенный). Защищенный элемент является видимым для элементов, которые имеют отношение обобщения с пространством имен, который им владеет. ~ package (пакет). Элемент, помеченный как имеющий пакетную видимость, является видимым всеми элементами в ближайшем охватывающем пакете в предположении. За пределами ближайшего охватывающего пакета элемент, помеченный как имеющий пакетную видимость, не является видимым.