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

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

виде). Требуется: построить диаграммы вариантов использования, описывающие функциональность системы. Каждое действующее лицо (actor) и вариант использования сопровождается описанием. Все описания составляются на русском языке. Описание действующего лица - короткое (1-2 строки). Описание варианта использования состоит из пояснения, предусловия, потоков событий (основного и альтернативных, если таковые есть) и постусловия. Описания представляют собой либо присоединенные текстовые файлы, либо текст, введенный в поле Documentation спецификации соответствующего элемента диаграммы.

системы, заключенные в границу системы, и внешние актеры, а также определенные отношения между актерами и вариантами использования

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

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

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

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

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

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

что один элемент модели является специальным или частным случаем другого элемента модели

текст, который описывает поведение моделируемой системы в форме последовательности выполняемых действий актеров и самой системы.

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

текстовом виде) и диаграммы вариантов использования. Требуется: выделить прототипные объекты системы и построить диаграммы взаимодействия между объектами (последовательности и кооперативные), соответствующие потокам событий вариантов использования. Для анализа нескольких вариантов использования можно использовать диаграммы деятельности. Названия диаграмм должны совпадать с названиями соответствующих вариантов использования. Все необходимые пояснения должны содержаться в примечаниях диаграмм. На этом этапе проектируются диаграммы взаимодействия в начальном приближении, объекты не соотносятся с классами, сообщения не соотносятся с операциями.

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

потоке деятельности, соединенных дугами



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

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

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

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

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

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

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

альтернативных потоков

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

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

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

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

и диаграммы вариантов использования, диаграммы взаимодействия. Требуется: создать иерархию классов системы, разместить классы по пакетам (использовать деление: пользовательский интерфейс - управление - данные; или другое в зависимости от постановки задачи), связать объекты с классами, сообщения - с операциями (второй этап разработки диаграмм взаимодействия). Каждый класс снабдить описанием. Оно должно включать в себя краткое описание - ответственность класса; описание атрибутов в виде таблицы из 3-х столбцов: имя, описание, тип; таблицу с описанием операций (имя, описание, сигнатура). Для классов указать стереотипы. Построить диаграммы классов системы, отображающие связи между классами. Для описания поведения экземпляров отдельных классов использовать диаграммы состояний.

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

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

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

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