1. Что такое промышленный программный продукт. Дать определения пакета прикладных программ, программной системы
Этап 3: Определение атрибутов классов
Атрибуты являются свойствами объектов, таких, как имя, вес, скорость или цвет. При выделении атрибутов, следует учитывать следующие определения:
Атрибут должен быть характерен непосредственно для данного класса.
Атрибут должен отображать, одну и только одну характеристику класса. Если выделенный атрибут являлся сложным объектом либо содержит некоторую совокупность характеристик, выделите атрибут в отдельный класс, либо разбейте его на несколько простых атрибутов.
При описании классов, входящих в состав схемы наследования, для каждого атрибута необходимо определить будет ли он общим для классов-наследников или специфичным для определенного класса. В первом случае атрибут включается в базовый класс, во втором – в соответствующий класс-наследник.
Этап 4:
Выделение операторов (методов) классов.
Операторы класса представляют собой действия, функции которые может совершать тот или иной класс.
При выделении операторов, следует учитывать следующие определения:
Метод класса должен быть свойственным тому классу, где он определен.
Отметим, что для обеспечения доступа к методу извне содержащего его класса может быть осуществлен только в том случае, если метод описан с открытыми (Public) правами доступа. Закрытые (Private) методы также обычно инициируются открытыми методами.
Операторы не должны быть слишком сложными, состоящими из множества различных функций. В этом случае необходимо разбить оператор на более простые составляющие.
Исключение из правила принадлежности метода классу составляют методы по созданию и удалению объектов класса. Подобные методы не могут быть включены в класс, так как класс не может вызвать метод создания собственного объекта. Создание объекта класса может произойти лишь извне, то есть из другого класса.
Соблюдайте принцип полноты методов класса. Если, например в классе присутствует метод Добавить запись, то должен быть определен метод Удалить запись. Должна присутствовать возможность сохранения и чтения добавленной записи, следовательно должны присутствовать методы Считать запись и Сохранить запись.
Диаграмма вариантов использования, ее назначение. Рассказать о варианте использования и действующем лице. Правила построения диаграммы вариантов использования.
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
Диаграмма вариантов использования одна из наиболее важных моделей проектирования систем по той причине, что если функционал не вошел в диаграмму, он не будет реализован в системе.
Включает следующие элементы:
Actor (актер)
Данный инструмент используется для создания действующих лиц в системе. На диаграмме Use Case значком actor обозначают пользователей системы, для того чтобы определить задачи, выполняемые пользователями и их взаимодействие.
Обычно значком Actor обозначают объект, который:
• взаимодействует с системой или использует систему;
• передает или принимает информацию в систему;
• является внешним по отношению к системе.
варианты (прецеденты)
Связи
Unidirectional Association (однонаправленная связь)
Данный инструмент позволяет обозначать связи между элементами. На диаграмме Use Case эти связи могут быть определены между use case и actor.
Значок Unidirectional Association позволяет создать однонаправленную связь класса с классом или класса с интерфейсом.
Dependency or instantiates (зависимость или реализация)
Значок Dependency or instantiates позволяет создать связь зависимости. Установка этого типа связей показывает, что класс использует другой класс как параметр в одном из методов.
Generalization (наследование)
Значок Generalization позволяет создать связь наследования, то есть создается подкласс для соединенного этой связью класса, наследуемого из родительского класса.
Типы вариантов использования:
критичные (выбираются из ключевых, ложатся в основу архитектуры)
ключевые (без которых система не имеет смысла)
обычные
Создание диаграммы вариантов использования
Этап 1:
При создании диаграммы вариантов использования начинаем с выделения действующих лиц (или, актеров) участвующих во взаимодействии с системой
Этап 2:
Следующим шагом является выделение возможностей (функций, вариантов использования), которые программа должна предоставлять данным пользователям.
Совет:
Вариантами использования могут быть только те возможности, которые будут реализованы в системе.
Старайтесь не вдаваться в детали методов реализации, которые будут использоваться при реализации данного программного продукта. Старайтесь опираться, прежде всего, на внешнее представление программы, поставьте себя на место конечных пользователей программы, которые «не знают», каким образом работает та или иная функция программы, однако вполне могут пользоваться всеми ее возможностями.
Вариант использования это всегда какое-то действие. Не допускайте имен, обозначающих некие объекты. Вместо этого используйте действия над этими объектами.
При определении количества вариантов использования, размещаемых на диаграмме, придерживайтесь правила «золотой середины». Каждый вариант использования должен быть не слишком обобщенной, а вполне конкретной функцией. Однако большого количества функций также следует избегать, так как схема может потерять свою наглядность. В этом случае, некоторые варианты использования можно объединить.
Этап 3:
Следующим важным шагом является создание связей между Актерами и вариантами использования.
Совет:
Ассоциацию “Пользователь - Вариант использования” отображает связь использования. Обратная ассоциация «Вариант использования – пользователь” показывает, что “Вариант использования” при инициализации передает некоторую информацию пользователю.
Не забывайте о том, что каждый пользователь на диаграмме представляет собой «Роль», которую играет тот или иной внешний объект. Причем один и тот же человек может играть несколько ролей в системе.
Правила построения вариантов использования:
диаграмма вариантов использования не учитывает временную последовательность.
Каждый вариант использования должен быть инициирован действующим лицом за некоторыми исключениями: включения и расширения.
нельзя моделировать связь между действующими лицами
Правила выявления вариантов использования:
что пользователь хочет делать с системой?
будет ли пользователь работать с информацией с помощью системы?
нужно ли информировать о внешних событиях?
должна ли система информировать пользователя о внешних событиях?
Как убедиться в том, что выявлены все варианты использования?
присутствует ли каждое функциональное требование хотя бы в одном варианте использования
учтено ли, как будет работать с системой каждое заинтересованное лицо
какую информацию будет передавать системе каждое заинтересованное лицо
какую информацию будет получать от системы каждое заинтересованное лицо
учтены ли вопросы, связанные с эксплуатацией
учтены ли все внешние системы, которые будут взаимодействовать нашей
какой информацией будет обмениваться каждая внешняя система с нашей
Диаграмма классов. Ее назначение. Что она включает. Рассказать об основных видах связей между классами.
Диаграмма классов - статическая структурная диаграмма, описывающая структуру системы; она демонстрирует классы системы, их атрибуты, операторы и связи между классами. ДК присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. Но отличается от остальных специфичным содержанием.
ДК обычно содержит следующие сущности:
- классы;
- интерфейсы;
- кооперации;
- отношения зависимости, обобщения и ассоциации.
Для ДК используются следующие типы связей:
- Наследование (генерализация)
это связь между общей сущностью – суперклассом, или родителем, и более специализированной разновидностью этой сущности – подклассом, или потомком. Связь иногда называют связью "is a", имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нём могут быть определены дополнительные атрибуты и операции.
- Зависимость
это связь по применению, когда изменение в спецификации одного класса может повлиять на поведение другого класса, использующего первый класс. Если интерфейс 2го класса изменяется, это влияет на поведение объектов 1го класса. Показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость.
- Ассоциация
это структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Допускается, чтобы оба конца ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями). Графически изображается в виде линии, соединяющей класс сам с собой или с другими классами.
С понятием ассоциации связаны 4 важных дополнительных понятия: имя, роль, кратность и агрегация. Ассоциации может быть присвоено имя, характеризующее природу связи. Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации. Роль класса задаётся именем, помещаемым под линией ассоциации ближе к данному классу. Кратность (multiplicity) (мощность) роли ассоциации - характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации. Наиболее распространённым способом задания кратности роли ассоциации является указание конкретного числа или диапазона:
Иногда в требуется отразить то, что ассоциация между двумя классами имеет специальный вид "часть-целое". Тогда класс "целое" имеет более высокий концептуальный уровень, чем класс "часть". Ассоциация такого рода называется агрегатной (агрегацией):
Бывают случаи, когда связь "части" и "целого" настолько сильна, что уничтожение "целого" приводит к уничтожению всех его "частей". Агрегатные ассоциации, обладающие таким свойством, называются композитными (композициями):
Дать определение тестированию и отладке. Особенности и объекты тестирования. Автономное и комплексное тестирование.
Тестирование - процесс поиска, обнаружения ошибок.
Отладка – процесс устранения ошибок, выявленных на стадии тестирования.
Особенности тестирования:
- отсутствует программа-эталон, которой должны соответствовать все результаты тестирования проверяемой программы;
- невозможно создать тестовый набор для исчерпывающей проверки программы;
- следует избегать трудно или невоспроизводимых тестов;
- нужно создавать тесты, которые действительно находили бы ошибки, а не демонстрировали правильность выполнения программы;
- нет формализованных критериев качества программ и процесса их испытания;
- для тестирования нужно привлекать сторонних специалистов.
Наиболее характерными объектами тестирования являются:
требования и спецификация;
программные модули;
группы программ, решающие законченные функциональные возможности.
Автономное тестирование
Это метод, который включает автономную проверку отдельного модуля или подсистемы. Весь программный комплекс не тестируется, проверяется лишь структура компонента и вычисления и преобразования данных внутри него.
Разделяют восходящее и нисходящее направления автономного тестирования.
При восходящем тестируются физические модули самого нижнего уровня, затем – вызывающие их модули, и т.д. до самого высшего.
Плюсы: модули тестируются детально, это позволяет устранить большое количество ошибок; относительная простота подготовки тестов.
Минусы: нужно постоянно обновлять набор тестовых данных при подключении нового модуля; большая вероятность появления новых ошибок при подключении модулей; необходимо имитировать работу вышестоящих модулей.
При нисходящем в первую очередь проверяется главный модуль, затем – модули более низких уровней и т.д.
Плюсы: накапливаются тестовые данные, которые можно не менять при подключении модулей.
Минусы: более трудный поиск ошибок; необходимо имитировать работу нижестоящих модулей.
Существует также раздельное тестирование, являющееся разновидностью восходящего. Оно используется для раздельно компилируемых физических модулей.
Комплексное тестирование
Это метод, который включает исследование структуры всего комплекса, связи между модулями, внешние связи, возможности эксплуатации и т.д. Здесь проверяется решение задач с типовыми исходными данными, исследуется поведение комплекса в критических ситуациях и правильность использования ресурсов памяти и процессора.
Для упрощения процедуры тестирования рекомендуется сначала проводить тестирование по отдельным функциональным группам.
Дополнительный метод тестирования – инспекция кода, когда разработчиком проводится «ручное» тестирование, группа специалистов просматривает код, чтобы устранить типичные ошибки. Метод довольно действенный – позволяет устранить до 70% ошибок.
Дать определение тестированию и отладке. Локализация ошибок. Классификация ошибок.
Тестирование - процесс поиска, обнаружения ошибок.
Отладка – процесс устранения ошибок, выявленных на стадии тестирования.
Отладка включает в себя локализацию ошибки – выяснение её местоположения в программе. Программа что-то принимает на вход и выдаёт что-то на выходе. Первое при локализации ошибки – это понять, где происходит сбой. Для этого можно уменьшать кол-во параметров, подаваемых на вход программы и добиться двух малоразличимых наборов входных параметров, чтобы при одном из них программа работала, а при другом нет.
Классификация ошибок:
- синтаксические
Это неточность написания кода, несоблюдение синтаксиса языка; простейшие ошибки, выявляются компилятором.
- опечатки
Это ошибки программиста при синтаксически верном коде; компилятором пропускаются; обнаружить довольно сложно, для этого используют метод инспекции кода.
- ошибки реализации алгоритма
Это все ошибки, вызванные неверным программированием при верном алгоритме:
ошибки распределения свободной памяти;
ошибки доступа к памяти, доступ по неинициализированному указателю;
использование неинициализированных переменных.
- ошибки алгоритма
Логические ошибки, которые приводят к неверному результату даже при совершенной реализации; трудно обнаружимы, т.к. работают с другими типами ошибок.
- ошибки метода
Неверное описание метода вычисления; тяжело обнаружимы, т.к. нужна высокая квалификация по предметной области; только при полной уверенности в том, что все ошибки реализации устранены и алгоритм правилен, можно предположить, что ошибка заключается в методе.
Для облегчения отладки существует способ, который заключается в том, чтобы в программу при написании встраивать средства обнаружения ошибок и реакции на них. Это называется безопасным программированием.
Оценки ошибок.
Обычно если в программе найдено большое кол-во ошибок, то, скорее всего, их там ещё больше. Поэтому используются методы оценки количества ошибок в программе:
- намеренное внесение ошибок
(N-n) – количество оставшихся ошибок; N – неизвестное кол-во ошибок.
Метод основам на том, что в код программы вносится опред-е кол-во ошибок (S); при этом считается, что % намеренно внесённых и реальных ошибок при тестировании будет одинаков. При тестировании обнаруживается n реальных ошибок и s внесённых. Вычисление строится на основе пропорции.
- объединение модулей
Большинство ошибок содержится в сопряжении модулей и операторах ввода-вывода. Обычно они затрагивают несколько модулей. После того, как проведено тестирование каждого отдельного модуля, они объединяются в систему. В ходе экспериментов выяснено, что в 90% новых модулей и в 15% старых нужно вносить изменения. Причём в ≈15% новых модулей и 6% старых нужно внести более 10ти изменений.
Правила и принципы построения интерфейса пользователя.
Правила:
«Эффективность»
Система не должна мешать эффективной работе пользователей, которые имеют большой опыт работы с ней. (Нарушением правила является ориентирование системы только на новичков или на профессионалов).
«Доступность» (указание)
Система должна быть достаточно понятной, чтобы юзер, никогда раньше ею не пользовавшийся, но хорошо знающий предметную область, мог без помощи начать её использовать.
«Непрерывное движение вперёд»
Система должна способствовать непрерывному росту знаний, умений, навыков юзера и приспосабливаться к его меняющемуся опыту.
«Соблюдение контекста»
Система должна быть согласована со средой, в которой ей предстоит работать.
«Поддержка»
Система должна способствовать более простому и лёгкому решению задач.
Принципы разработки юзерского интерфейса:
1) Человеку свойственно ошибаться
Система должна быть терпима к ошибкам юзера и не падать из-за ошибок входных данных.
2) Чел по меркам компа осознаёт информацию и действует медленнее.
3) «Глаз быстрее руки»
На нажатие клавиши требуется меньше времени, чем на перемещение курсора с одного объекта на другой.
4) Правило «7±2»
В кратковременной памяти заурядный чел держит 5-9 объектов. Если кол-во объектов интерфейса больше, то его труднее воспринимать.
5) Чел быстрее узнаёт что-либо, чем вспоминает, как оно называется.
Проще выбрать из списка.
6) На изучение нового требуется время.
Принципы построения интерфейса:
Принцип простоты
Самые распространённые операции должны выполнятся максимально просто, причём должны быть ссылки на более сложные операции.
Принцип видимости
Все функции и данные, нужные для использования в задаче, должны быть видны, когда юзер выполняет эту задачу.
Принцип толерантности
Система должна быть терпима к ошибкам юзера: минимальный ущерб системе (засчёт отмены и повтора действий), гибкий интерфейс.
Принцип структуризации
Интерфейс дб целесообразно структурирован: родственные части дб связанны, а независимые разделены; похожие элементы должны выглядеть похоже, а непохожие различаться.
Принцип обратной связи
Юзер должен получать сообщение от системы о выполнении её действий. Сообщения дб краткими и понятными.
Принцип повторного использования
Следует многократно использовать внутр. и внеш. компоненты, чтобы способствовать единообразию интерфейса.
Документирование. Состав и содержание документов прилагаемых к программной системе.
Документирование должно начинаться одновременно с началом разработки продукта и в процессе разработки должны быть сформированы следующие документы: текст программ с необходимыми комментариями, описание программы – сведения о конечном продукте, программа и методика испытаний, техническое задание (см №7), пояснительная записка (схема алгоритма, общее описание алгоритма и/или функционирования программы, обоснование принятых решений), руководство пользователя, руководство администратора.
страница 1страница 2страница 3
скачать
Другие похожие работы: