Размещено на http://www.allbest.ru/

Оглавление

1. Разработка технического задания

1.1 Общие рекомендации по написанию ТЗ

1.2 Общая структура ТЗ. От абстракции к конкретике

2. Анализ требований и определение спецификации ПО при структурном подходе

2.1 Спецификации ПО при структурном подходе.

2.2 Функциональные диаграммы

2.3 Диаграмма потоков данных.

2.4 Структуры данных и диаграммы отношений компонентов данных.

2.5 Сетевая модель данных.

3. Проектирование программного обеспечения при структурном подходе

3.1 Разработка структурной и функциональной схем.

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

3.3 Структурные карты Константайна.

3.4 Проектирование структур данных.

4. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml

5. Разработка прототипа программного обеспечения

5.1 Создания прототипа.

6. Проектирование интерфейса пользователя

7. Объектно-ориентированное программирование(ооп)

8. Выбор стратегии тестирования и разработка тестов

Вывод

1. Разработка технического задания

Техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы хотим видеть в конечном продукте.

На примере мы разберем ТЗ для разработки web-ресурса. По своей сути -- это база для разработки сайта. В нем указываются все положения, прямо или косвенно касающиеся сайта.

ТЗ, как правило, прилагается к основному договору на работы по созданию web-ресурса, т. к. включает полный перечень всех работ для обязательного выполнения дабы исключить возможные споры между клиентом и исполнителем, которые, как известно все-равно время от времени возникают.

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

Чем детализированнее ТЗ, тем лучше для обеих сторон:

- клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.

- исполнитель - застрахован от множества мелких или крупных корректировок и доработок, опираясь от ТЗ.

1.1 Общие рекомендации по написанию ТЗ

Чем сложнее проект, тем детализирование должно быть ТЗ.

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

В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну.

Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация».

Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, нужно проанализировать сайты с похожим функционалом, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях

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

1.2 Общая структура ТЗ. От абстракции к конкретике

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

1. Общая информация о сайте.

2. Функциональное назначение сайта.

3. Понятия и термины

4. Описание модулей сайта

5. Функциональные характеристики

6. Описание страниц.

7. Резервирование и надежность.

8. Хостинг для сайта.

Общая информация о сайте

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

Функциональное назначение сайта

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

Понятия и термины

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

Описание модулей сайта

Этот раздел включает список модулей, которые используются на сайте. Например форма обратной связи (ФОС). Но, что очень важно -- нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

- Поле «Ваш имя»;

- Поле «Ваш е-mail»;

- Поле «Ваш вопрос»;

- Поле ввода капчи для защиты от спам-роботов.

Функциональные характеристики

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

Описание страниц сайта

Это довольно обширный пункт, где прописываются все страницы сайта и пишутся комментарии к их работе. Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это:

Рисунок 1- сайт-каталога

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

Стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:

Рисунок 2 - пример прототипа

Остальные страницы

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

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

В конец ТЗ в обязательном порядке нужно внести информацию о том, что все работы, не описанные в настоящем ТЗ, выполняется по усмотрению программиста по очевидным причинам. Это наша «маленькая гарантия» от возможных доработок и переделок, выходящих за рамки ТЗ.

2. Анализ требований и определение спецификации по при структурном подходе

программный обеспечение данные детализация

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

2.1 Спецификации ПО при структурном подходе

Спецификация - это полное и точное описание функций и ограничений разрабатываемого ПО.

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

Требования применительно к функциональной спецификации:

1. Требование полноты. Означает, что спецификации должны содержать всю существующую информацию

2. Требование точности. Означает, что спецификации должны однозначно восприниматься заказчиком и разработчиком.

Это требование выполнить достаточно сложно, так как естественный язык для описания спецификации не подходит, так как не обеспечивает необходимой точности. Точность спецификации можно определить, только разработав некоторую формальную модель разрабатываемого ПО.

Формальные модели на этапе определения спецификации делят на 2 группы:

1. модели, зависящие от подхода к разработке (структурного или объектно-ориентированного)

2. модели, не зависящие от него.

В рамках структурного подхода на этапе анализа и определения спецификации используют 3 типа моделей:

1. ориентированные на функции,

2. ориентированные на данные,

3. ориентированные на потоки данных.

Каждую модель целесообразно использовать для своего класса программных разработок.



Рисунок 3 - Классификация моделей разрабатываемого ПО на этапе определения спецификации.

Все функциональные спецификации описывают одни и те же характеристики разрабатываемого ПО:

1. Перечень функций и состав обрабатываемых данных.

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

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

1. диаграммы потоков данных DFD(DataFlowDiagrams) описывает взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе.

2. ERD- диаграммы сущность - связь. Описывают базы данных разрабатываемой системы.

3. STD- диаграммы переходов состояний. Характеризуют поведение системы во времени.

4. спецификация процессов

5. словарь терминов.



Рисунок 4 -Методология структурного анализа ПО.

Кроме этих моделей в состав спецификации могут входить математические модели описания объектов предметной области. Они уточняют основные соотношения анализируемых величин и ограничений.

Диаграмма переходов состояний.

Диаграмма переходов состояний является графической формой представления конечного автомата - математической абстракции, используемой для моделирования детерминированного поведения объектов).

На данном этапе эта диаграмма демонстрирует поведение ПО при получении управляющих воздействий. Управляющее воздействие - управление информацией извне. Для построения необходимо определить:

- основные состояния

- управляющие воздействия (условие перехода)

- выполняемые действия

- возможные варианты перехода из одного в другое.

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

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

2.2 Функциональные диаграммы

Отражают взаимосвязи функций разрабатываемого ПО. Пример - активностная модель Д. Росса (1973 г.), он предложил ее в составе методологии SADT(технология структурного анализа и проектирования).

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

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

2.3 Диаграмма потоков данных

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

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

- нотация Йордана,

- нотация Гейна-Сарсона.

2.4 Структуры данных и диаграммы отношений компонентов данных

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

Различают абстрактные структуры данных (для уточнения связи между элементами) и конкретные структуры для предоставления данных в программах.

Абстрактные структуры данных (АСД)

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

В третьем случае существенным являются и связи элементов данных между собой.

Иерархические модели позволяют описывать упорядоченные или неупорядоченные отношения вхождения элементов данных компонент более высокого уровня. К этим моделям относятся модель Джексона-Орра, для графического представления которых можно использовать:

- диаграммы Джексона.

- скобочные диаграммы Орра.

2.5 Сетевая модель данных

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

1. нотация П.Чена;

2. нотация Р.Баркера;

3. нотация IDEF1. Более современный вариант этой нотации используется вcase-системах.

Базовыми понятиями сетевой модели данных являются сущность, атрибут и связь.

3. Проектирование программного обеспечения при структурном подходе

3.1 Разработка структурной и функциональной схем

Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.

Структурная схема разрабатываемого программного обеспечения

Структурной называют схему, отражающую состав и взаимодействие по управлению частей разрабатываемого программного обеспечения.

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

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

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

Структурными компонентами программной системы или программного комплекса могут служить программы, подсистемы, базы данных, библиотеки ресурсов и т. п.

Структурная схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе (рис. 3.1).



Рисунок 5 - Пример структурной схемы программного комплекса.

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

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

Функциональная схема

Функциональная схема или схема данных (ГОСТ 19. 701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов.

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

Структурный подход к программированию в том виде, в котором он был сформулирован в 70-х годах XX в., предлагал осуществлять декомпозицию программ методом пошаговой детализации. Результатом декомпозиции является структурная схема программы, которая представляет собой многоуровневую иерархическую схему взаимодействия подпрограмм по управлению. Минимально такая схема отображает два уровня иерархии, т. е. показывает общую структуру программы. Однако тот же метод позволяет получить структурные схемы с большим количеством уровней.

Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг при этом включает разложение функции на подфункции. Так на первом этапе описывают решение поставленной задачи, выделяя общие подзадачи, на следующем аналогично описывают решение подзадач, формулируя при этом подзадачи следующего уровня. Таким образом, на каждом шаге происходит уточнение функций проектируемого программного обеспечения. Процесс продолжают, пока не доходят до подзадач, алгоритмы, решения которых очевидны.

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

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

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

- не отделять операции инициализации и завершения от соответствующей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

- не проектировать слишком специализированных или слишком универсальных модулей, так как проектирование излишне специальных модулей увеличивает их количество, а проектирование излишне универсальных модулей повышает их сложность;

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

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

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

Разбиение на модули при данном виде проектирования выполняется эвристически, исходя из рекомендуемых размеров модулей (20-60 строк) и сложности структуры (две-три вложенных управляющих конструкции). В принципе в качестве модуля (подпрограммы) можно реализовать решение подзадач, сформулированных на любом шаге процесса детализации, однако определяющую роль при разбиении программы на модули играют принципы обеспечения технологичности модулей.

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

3.3 Структурные карты Константайна

На структурной карте отношения между модулями представляют в виде графа, вершинам которого соответствуют модули и общие области данных, а дугам -- межмодульные вызовы и обращения к общим областям данных.

Различают четыре типа вершин:

- модуль - подпрограмма,

- подсистема - программа,

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

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

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

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

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

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

Структурные карты Константайна позволяют наглядно представить результат декомпозиции программы на модули и оценить ее качество, т. е. соответствие рекомендациям структурного программирования (сцепление и связность).

3.4 Проектирование структур данных

Под проектированием структур данных понимают разработку их представлений в памяти. Основными параметрами, которые необходимо учитывать при проектировании структур данных, являются:

- вид хранимой информации каждого элемента данных;

- связи элементов данных и вложенных структур;

- время хранения данных структуры («время жизни»);

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

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

- целые и вещественные числа различных форматов;

- символы;

- булевские значения: true и false;

- а также некоторые структурные типы данных, например:

- строки;

- записи;

- специально объявленные классы.

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

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

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

4. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml

Концептуальной основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.)

Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению их методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) И. Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями.

Главными в разработке UML были следующие цели:

- предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий им разрабатывать осмысленные модели и обмениваться ими;

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

- обеспечить независимость от конкретных языков программирования и процессов разработки.

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

- стимулировать рост рынка объектно-ориентированных инструментальных средств;

- интегрировать лучший практический опыт.

UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. UML принят на вооружение практически всеми крупнейшими компаниями - производителями ПО (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо IBM Rational Software, поддерживают UML в своих продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler и др.).

Стандарт UML версии 1.1, принятый OMG в 1997 г., содержит следующий набор диаграмм:

1. Структурные (structural) модели:

- диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

- диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

- диаграммы развертывания (deployment diagrams) - для моделирования физической архитектуры системы.

2. Модели поведения (behavioral):

- диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);

- диаграммы взаимодействия (interaction diagrams):

- диаграммы последовательности (sequence diagrams) и диаграммы кооперации (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

- диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

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

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

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом "сценарием варианта использования" или "потоком событий" (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Достоинства модели вариантов использования заключаются в том, что она:

- определяет пользователей и границы системы;

- определяет системный интерфейс;

- удобна для общения пользователей с разработчиками;

- используется для написания тестов;

- является основой для написания пользовательской документации;

- хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

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

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

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

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

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

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

Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.

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

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

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

Диаграмма развертывания показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основными элементами являются узел (вычислительный ресурс) и соединение - канал взаимодействия узлов (сеть).

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

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком.

К его механизмам расширения относятся:

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

- Тегированные (именованные) значения (это пара строк "тег = значение", или "имя = содержимое", в которых хранится дополнительная информация о каком-либо элементе системы, например, время создания, статус разработки или тестирования, время окончания работы над ним);

- Ограничения (это семантическое ограничение, имеющее вид текстового выражения на естественном или формальном языке (OCL - Object Constraint Language), которое невозможно выразить с помощью нотации UML).

Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов

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

Буч отметил также ряд следующих преимуществ ООП:

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

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

- объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

- объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

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

Таким образом, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимствовали то рациональное, что можно было взять из структурного подхода: элементы функциональной декомпозиции в диаграммах вариантов использования, диаграммы состояний, диаграммы деятельности и др. Очевидно, что в конкретном проекте сложной системы невозможно обойтись только одним способом декомпозиции. Можно начать декомпозицию каким-либо одним способом, а затем, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения.

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

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

5. Разработка прототипа программного обеспечения

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

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

5.1 Создания прототипа

Быстрое создание прототипа

При быстром прототипировании (англ. rapid prototyping или throwaway prototyping) предполагается, что создаётся макет, который на каком-то этапе будет оставлен («выброшен») и не станет частью готовой системы.

Основное преимущество такого подхода -- в скорости: в ответ на свои требования заказчик почти сразу получает прототип интерфейса, и сразу может уточнить требования, до того, как начато написание рабочего кода системы. Стоимость изменения требований на этом этапе очень низкая, поскольку нет кода, который нужно было бы переписывать.

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

Быстрое прототипирование не обязательно выполняется в рамках той же платформы и тех же технологий, что и разрабатываемая система. Для прототипа графического интерфейса пользователя (GUI) могут использоваться как стандартные HTML-страницы, либо прототип может подготавливаться в программе, специально предназначенной для создания макетов (например: Axure RP, Microsoft Expression Blend и др.).

Эволюционное создание прототипа

Эволюционное прототипирование (англ. evolutionary prototyping) ставит своей целью последовательно создавать макеты системы, которые будут все ближе и ближе к реальному продукту.

Такой подход имеет то преимущество, что на каждом шаге мы располагаем работающей системой, пусть и не обладающей всей нужной функциональностью, но улучшающейся с каждой итерацией. При этом, не тратятся ресурсы на код, который будет «выброшен».

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

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

6. Проектирование интерфейса пользователя

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

Для создания у пользователя такого ощущения «внутренней свободы» интерфейс должен обладать целым рядом свойств:

- Естественность интерфейса.

- Согласованность интерфейса.

- Дружественность интерфейса (Принцип «прощения пользователя»)

- Принцип «обратной связи».

- Простота интерфейса.

- Гибкость интерфейса.

- Эстетическая привлекательность.

Рисунок 6 - создание интерфейса дальнейшей программы

7. объектно-ориентированное программирование(ооп)

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

Необходимо обратить внимание на следующие важные части этого определения:

1. объектно-ориентированное программирование использует в качестве основных логических конструктивных элементов объекты, а не алгоритмы;

2. каждый объект является экземпляром определенного класса;

3. классы образуют иерархии. Программа считается объектно-ориентированной, только если выполнены все три указанных требования.

Рисунок 7 - использование ООП в проекте

8. Выбор стратегии тестирования и разработка тестов

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

Оптимальная стратегия проектирования тестов:

- На каждую используемую функцию - хотя бы один тест;

- На каждую область и на каждую границу изменения какой-либо входной величины - хотя бы один тест;

- На каждую исключительную ситуацию, указанную в спецификациях - хотя бы один тест.

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

Вывод

В данной работе я больше узнал для себя много нового, и исходя от процесса изучения этих данных создал программу в Borland Delphi 7, которая пригодится мне в будущем.

Размещено на Allbest.ru

...