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

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

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

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

Например, мы можем дать определение направленным отношений, определение полям и методологической информации. В направленном отношении обозначен адресат сообщения. Например в системе SIG классовый объект "Graphics" посылает сообщения на "Ключевое слово".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

n.1. Тип
n.2. Цель
n.3. Функция
n.4. Подкомпонента
n.5. Связи
n.6. Интерфейсы
n.7. Ресурсы
n.8. Ссылки
n.9. Трансформация
n.10. Данные

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

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

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