Проектирование системы

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

Проектирование начинается там, где заканчивается анализ.

● Анализ — моделирование, не ограниченное никакой реализацией (аппаратного/программного обеспечения).

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

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

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

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

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

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

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

Реализация

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

Программист — инженер, работающий в двух направлениях. Программирование начинается с преобразования проекта в код. Начальный код не должен программироваться вручную. Используя CASE-средства и IDE-средства (integrated development environments— интегрированные средства разработки), код начинает формироваться (прямое проектирование) из моделей проекта. После того как эта работа будет сделана, произведенный код должен быть скорректирован вручную, чтобы заполнить отсутствующие части (эти «части» существенны и наиболее трудны в программировании). После того как код будет модифицирован программистом, он может обратно воздействовать на модели проекта, корректируя их. Эти технические операции в прямом и обратном направлении называются циклическим проектированием.

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

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

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

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

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

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