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

Презентация на тему Техническое задание. Наименование и область применения, предмет презентации: Информатика. Этот материал содержит 43 слайдов. Красочные слайды и илюстрации помогут Вам заинтересовать свою аудиторию. Для просмотра воспользуйтесь проигрывателем, если материал оказался полезным для Вас - поделитесь им с друзьями с помощью социальных кнопок и добавьте наш сайт презентаций ThePresentation.ru в закладки!

Слайды и текст этой презентации

Слайд 1
Текст слайда:

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


Слайд 2
Текст слайда:

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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


Слайд 3
Текст слайда:

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


Слайд 4
Текст слайда:

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


Слайд 5
Текст слайда:

Диаграмма вариантов использования (use case diagram)

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


Слайд 6
Текст слайда:

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


Слайд 7
Текст слайда:

Вариант использования (use case)

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


Слайд 8
Текст слайда:

Актер (actor)

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


Слайд 9
Текст слайда:

Вопросы для идентификации актеров в системе

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


Слайд 10
Текст слайда:

Отношение ассоциации

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


Слайд 11
Текст слайда:

Отношение включения

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


Слайд 12
Текст слайда:

Отношение расширения

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


Слайд 13
Текст слайда:

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


Слайд 14
Текст слайда:

Отношение обобщения

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


Слайд 15
Текст слайда:

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


Слайд 16
Текст слайда:

Спецификация ВИ с помощью текстовых сценариев

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


Слайд 17
Текст слайда:

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

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


Слайд 18
Текст слайда:

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


Слайд 19
Текст слайда:

Диаграмма деятельности (activity diagram)

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


Слайд 20
Текст слайда:

Узел деятельности (activity node)

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



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


Слайд 21
Текст слайда:

Поток управления (control flow)

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


Слайд 22
Текст слайда:

Поток объектов (object flow)

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


Слайд 23
Текст слайда:

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


Слайд 24
Текст слайда:

Семантика деятельности

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


Слайд 25
Текст слайда:

Семантика действия

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


Слайд 26
Текст слайда:

Узлы управления

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


Слайд 27
Текст слайда:

Узел решения (decision node)

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


Слайд 28
Текст слайда:

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


Слайд 29
Текст слайда:

Узел слияния (merge node)

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


Слайд 30
Текст слайда:

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


Слайд 31
Текст слайда:

Узел разделения (fork node)

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


Слайд 32
Текст слайда:

Узел соединения (join node)

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


Слайд 33
Текст слайда:

Примеры изображения узла соединения

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


Слайд 34
Текст слайда:

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


Слайд 35
Текст слайда:

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

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


Слайд 36
Текст слайда:

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


Слайд 37
Текст слайда:

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


Слайд 38
Текст слайда:

Диаграмма классов — основная логическая модель проектируемой системы

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


Слайд 39
Текст слайда:

Характеристики классификатора

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


Слайд 40
Текст слайда:

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


Слайд 41
Текст слайда:

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


Слайд 42
Текст слайда:

Разновидности классов

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



Слайд 43
Текст слайда:

Вид видимости

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


Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

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


Для правообладателей

Яндекс.Метрика