Разработка программного продукта. Этапы проектирования и построение модели

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

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

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

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

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

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

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

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

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

При проектировании возникают новые термины и определения, пополняют запас терминов, которые использовались при анализе.

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

Спецификация состоит из правил формулировки и отображения результатов на программной речи и включает в себя:

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

Спецификация метода должна заменить некоторые методы прямым доступом к свойствам. Например метод GetLastName, SetLastName, представленный во время анализа, должен быть замещен прямым доступом к последнему имени на этапе проектирования. Другая спецификация может принимать форму замещенных атрибутов соответствующих методов. Например, атрибут Возраст или атрибут Прибыль может быть заменен методами, подсчитывают значения: Возраст = Сегодня Дата_нарождения; Прибыль = Загальний_прибуток Кредиты.

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

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

Быстрой разработкой программ называются методы быстрого прототипирования или получения готовых приложений. Срок RAD используется иногда как синоним языков / сред разработки нового поколения (4GL). Примеры RAD-инструментов: Borland Delphi RAD Pack, IBM Visual Age (для Small Talk), Microsoft Access Developer's Toolkit, Microsoft Visual FoxPro Professional, Visual Studio FoxPro, PowerBuilder Desktop, Power + + и другие.

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

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

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

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

Разработка интерфейса стала проще последние годы, поскольку появились много графических инструментов для этой цели. Также существуют системы с управлением интерфейсом, например, Zapp Factory, Visual Basic. Визуальные инструменты дают возможность интерактивно разрабатывать диалоги, окна, меню, поразрядное карты отображения информации и иконы. Они позволяют определить реакцию системы в ответ на различные события, например, сделанные пользователем (выбор записи в меню, перемещение курсора над определенными областями и т.д.), легкое и быстрое генерирование графического проекта, программного или иных кодов.

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

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

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

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

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

Правило 6. Мы должны помнить об отправке подтверждений пользователю. В случае объемных команд пользователь должен получать информацию об отправке ему команды. Изображение может быть выполнено в форме текстовой информации, процентов выполнения команды, термометра.

Правило 7. В системе должна быть простая обработка ошибок. Ошибка должна быть показана, а правильные данные должны использоваться для выполнения следующего задания.

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

Правило 9. Система должна давать возможность пользователю контролировать работу. Пользователи не любят операций, инициируемых без их ведома. Такие операции не должны делаться системой, а реакция на команды Esc, Ctr + C, Break ... должна быть очень быстрой.

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

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

Правило 12. Нужно соблюдать правила Миллера. Правило Миллера 7 + / -2 говорит, что человек может сосредоточиться на 5-9 элементах. Правило должно применяться при проектировании меню, подменю, диалоговых полей и т.д. Правило может быть реализовано путем декомпозиции интерфейса и его дальнейшим группировкой в ​​объединенные группы.

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

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

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

Специфические элементы данных в форме объектов или точной копии могут быть сохранены в одной из форм:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность обозначает частоту отказов. Чем выше надежность тем выше стоимость. Таким образом, должно быть выполнено балансировки надежности (или потребность остановки работы) и затрат.

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

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

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

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

На рис. 1.13. объектно-ориентированную примерное и реляционную модель показывают для одной системы. Объектно-ориентированная модель яснее.

Неудобство в применении реляционной модели также несогласованность интерфейса доступа (например, к SQL) и к языку программирования (например, C + +). Эту несогласованность называют несогласованностью импеданса.

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

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

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

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

Еще одним важным моментом в нахождении узких мест и осторожном обращению с ними есть понимание процедур. Общеизвестно, что 20% кода занимает 80% времени выполнения. Задержки могут быть устранены путем написания часто употребляемых функций на языках низкого уровня, например, C.

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

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

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

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

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

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

· Классы, не имеющие отношения к другим классам, не должны включаться. Но иногда такое случается,

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

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

1. Случайная декомпозиция. Разделение на модули происходит из-за невозможности охватить всю систему в различных задачах.

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

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

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

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

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

# ИМЯ?

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

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

Нефункциональные требования должны быть определены на этапе анализа. На этапе проектирования они систематизируются и формулируются проектные решения.

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

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

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