Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
51
го, выявляется неквалифицированная работа операторов, и проводятся меры по подготовке кадров.
После устранения ошибок составляется акт о проведении
опытного внедрения.
На третьем этапе «Сдача проекта в промышленную
эксплуатацию» используют документы:
– договорная документация;
– приказ на разработку ИС;
– ТЭО и ТЗ;
– исправленный технорабочий проект;
– приказ о начале промышленного внедрения;
– программа проведения испытаний;
– требования к научно-техническому уровню проекта системы.
В процессе сдачи проекта в промышленную эксплуата-
цию работы, связанные с проверкой соответствия выполненной
работы договорной документации по времени выполнения, объему проделанной работы и затратам денежных средств, а проектной документации государственным стандартам и т. д. Определяется научно-технический уровень проекта. Составляется акт
сдачи проекта в промышленную эксплуатацию.
1.6. Эксплуатация системы
Целью создания ИС является, естественно, ее эксплуатация. Этот этап жизненного цикла ИС наиболее протяженный во
времени, он занимает от 60 до 80 % времени жизненного цикла
системы в зависимости от качества разработки ИС и области ее
применения
На этапе эксплуатации разработчики участвуют «пассивно». Они сопровождают систему, то есть исправляют ошибки,
обнаруженные при эксплуатации и осуществляют необходимую
модификацию ИС. Проблема любого ПО в том, что при скольконибудь длительной эксплуатации возникает необходимость в
изменениях. Она объективна по своей природе, ведь окружающая среда не остается неизменной. Меняются стандарты, налогообложение, параметры, требования к оформлению и т. д., и
т. п. Поэтому, чтобы разработанное ПО не устарело к моменту
52
своего создания, надо иметь возможность его модифицировать.
Тем более надо иметь возможность модифицировать по мере его
устаревания. Чем более гибкой была создана система, тем дольше она сможет находиться в эксплуатации.
Обычно заказчики заключают с разработчиками договор о
сопровождении системы. Это может быть договор либо на только первое время после внедрения системы, либо на все время
эксплуатации ИС.
Сопровождение системы предполагает.
1. Консультирование персонала, имеющего отношение к
эксплуатации ИС.
2. Исправление ошибок, выявленных в процессе эксплуа-
тации.
3. Модификация или добавление функций ИС.
1.7. Вывод из эксплуатации
С течением времени любое ПО морально устаревает. Возникают новые возможности, принципиально новое и более эффективное АО, новое ПО, которое хочет использовать заказчик
и с которым невозможно увязать старую ИС, поскольку не всякая модификация экономически оправдана. Наступает момент,
когда требуемые изменения настолько кардинальны, что не ложатся в общую концепцию старой ИС. Тогда заказчик принимает решение перейти на новую ИС. Это решение влечет за собой
потерю наработанной базы данных, поскольку полное совпадение формата хранения данных старой БД с форматами новой
нереально.
Задача этого этапа — сохранить наработанную базу данных. Она либо консервируется, либо переводится на новый формат.
Вопросы и задания для самопроверки
1. Перечислите этапы разработки ПО. Какие этапы наибо-
лее длительны и какие наиболее трудоемки для пользователей?
Для разработчиков?
2. Из каких фаз состоит этап системного анализа?
53
3. Что такое требование? Какие требования называются
функциональными? Нефункциональными?
4. Предложите, кто бы мог участвовать в формировании
требований для университетской системы регистрации студентов. Объясните, почему почти неизбежно, что требования,
сформулированные разными лицами, будут противоречивы.
5. Что понимается под управлением требованиями?
6. Объясните, почему не нужно устранять все дефекты в
программе перед ее поставкой заказчику. До каких пор следует
тестировать программу, чтобы удостовериться, что она соответствует своему назначению?
7. Объясните, почему инспектирование программы явля-
ется эффективным методом обнаружения в ней ошибок. Какие
типы ошибок нельзя обнаружить методом инспектирования?
8. Охарактеризуйте понятия верификации, аттестации, ин-
спектирования.
9. Сравните методы тестирования «черного и стеклянного
ящиков».
10. Менеджер решил для оценки специалистов в качестве
исходных данных воспользоваться отчетами о результатах инспектирования программ. В отчетах содержится информация о
том, кто совершил, и кто обнаружил ошибки в программе. Этичны ли действия менеджера? Этично ли заранее проинформировать персонал об этом? Как это решение может повлиять на процесс инспектирования.
11. Один из подходов, широко используемых при тестиро-
вании ПО, состоит в тестировании до тех пор, пока не будут израсходованы все средства, выделенные на тестирование. Затем тема
передается заказчикам. Обсудите этичность такого подхода.
12. Если ПО создано под конкретного заказчика, то при-
менимо к нему бета-тестирование? Альфа-тестирование?
54
ГЛАВА 2. МЕТОДОЛОГИИ И НОТАЦИИ
ПРОЕКТИРОВАНИЯ
По мнению Страуструпа, «цель проектирования — выявление ясной и относительно простой внутренней структуры,
иногда называемой архитектурой». Проектирование подразумевает учет противоречивых требований. Его продуктами являются модели, позволяющие нам понять структуру будущей системы, сбалансировать требования и наметить схему реализации. Ключевым моментом выбора той или иной методологии
проектирования является декомпозиция системы, а именно, что
является элементами структуры.
2.1. Декомпозиция (структурирование) систем
Как отмечает Дейкстра, «способ управления сложными
системами был известен еще в древности — divide et impera
(разделяй и властвуй)». При проектировании сложной программной системы необходимо разделять ее на все меньшие и
меньшие подсистемы, каждую из которых можно совершенствовать независимо. В этом случае мы не превысим пропускной
способности человеческого мозга: для понимания любого уровня системы нам необходимо одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех).
В 60–70-е годы прошлого века было разработано много
методов, помогающих справиться с растущей сложностью программ. Наибольшее распространение получило структурное
проектирование по методу сверху вниз, что идеально для топологии таких языков, как FORTRAN или COBOL. В них основной
базовой единицей является подпрограмма, программа в целом
принимает форму дерева, в котором одни подпрограммы вызывают другие подпрограммы. Структурное проектирование использует именно такой подход: алгоритмическая декомпозиция
применяется для разбиения большой задачи на более мелкие.
Тогда же стали появляться компьютеры еще больших, поистине гигантских возможностей. Значение структурного подхода осталось прежним, но оказалось, что структурный подход
не работает, если объем программы превышает 100 тыс. строк.
55
Итак, можно разделить методы на три основные группы:
1) метод потоков данных;
2) метод структурного проектирования сверху вниз;
3) ОО проектирование.
Какой именно метод применим в конкретном случае,
определяет структурирование систем, а именно что представляют собой элементы структуры системы.
В методе потоков данных программная система рассматривается как преобразователь входных потоков в выходные. Он
(метод потоков данных), как и структурный метод, с успехом
применялся при решении ряда сложных задач, в частности, в
системах информационного обеспечения, где существуют прямые связи между входными и выходными потоками системы и
где не требуется уделять особого внимания быстродействию.
Структурное проектирование подразумевают алгоритмическую (функциональную) декомпозицию. Большинство из нас
формально обучено структурному проектированию «сверху
вниз», и мы воспринимаем декомпозицию как обычное разделение алгоритмов, где каждый модуль системы выполняет одну из
функций (этапов) общего процесса.
Недостатки структурного подхода:
– не позволяет выделить абстракции и обеспечить ограничение доступа к данным;
– не предоставляет достаточных средств для организации
параллелизма;
– не может обеспечить создание предельно сложных систем;
– неэффективен в объектных и ОО языках программирования.
ОО проектирование подразумевает объектно-ориентированную
декомпозицию. Элементами являются различные абстракции
предметной области: определяются объекты, которые заимствуются из словаря предметной области.
Какая декомпозиция сложной системы правильнее по алгоритмам или по объектам? В этом вопросе есть подвох, и правильный ответ на него: важны оба аспекта. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение объ-
56
ектами и (или) субъектами действия. Эти способы по сути своей
ортогональны.
Разделение системы следует начать либо по алгоритмам,
либо по объектам, а затем, используя полученную структуру,
попытаться рассмотреть проблему с другой точки зрения.
Опыт показывает, что полезнее начинать с объектной декомпозиции. Такое начало поможет нам лучше организовать
сложное ПО. Объектная декомпозиция имеет несколько чрезвычайно важных преимуществ.
1. Она уменьшает размер ПО за счет повторного использо-
вания общих механизмов, что приводит к существенной экономии выразительных средств.
2. ОО системы более гибки, их проще изменять со време-
нем, потому что сложное ПО развивается из меньших систем, в
которых разработчик уже уверен.
3. Более того, объектная декомпозиция помогает выбрать
разумное подмножество состояний из большого их количества.
2.2. Методологии проектирования
Проектирование ИС — это разработка нескольких моделей, рассматривающих архитектуру проекта с разных точек зрения. Как правило, процессы разработки моделей накладываются
др. на друга и повторяются для все более детальной разработки.
Обычно строятся следующие модели:
1. Модель структуры — это статическая модель, в кото-
рой проектируемая ИС представляется в виде совокупности относительно независимых подсистем, разрабатываемых в дальнейшем независимо. Определяются функции каждой подсистемы и взаимодействие между ними.
2. Динамическая модель системы — это модель управле-
ния и взаимодействия между подсистемами, отражает динамику
работы ИС.
3. Модульная декомпозиция. Каждая подсистема структур-
ной модели разбивается на отдельные модули, определяются
типы модулей и их взаимосвязи.
57
4. Объектная модель. Система представляется как множе-
ство объектов, определяются классы этих объектов, их атрибуты
(форматы полей) и методы.
Проектирование ИС может быть реализовано в рамках
различных методик, отличающихся, прежде всего, своим подходом к тому, что представляет собой структура моделируемой
системы. В настоящее время наиболее популярны методики объектные и функциональные (или алгоритмические) (см. рис. 2.1).
Методика проектирования непосредственно связана с проблемой выбора языка описания проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования — это нотация, в
основном графическая, которая используется для описания проектов.
Нотации — это совокупность графических символов и
правил их использования для описания чего-либо, например,
языка программирования, архитектуры и т. д. Нотация является
синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой — предоставлять проектировщикам средства достаточно формализованного и однозначного
определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему
программного обеспечения. Применительно к проектированию
ИС нотации являются совокупностью диаграмм, иллюстрирующих отдельные аспекты проекта ИС.
Графическое изображение нередко оказывается наиболее
емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений на всех этапах проектирования (от постановки
задачи до реализации программ на ЭВМ). Трудности возникают
при переходе от этапа анализа системы к этапу проектирования
и особенно к программированию.
58
Рис. 2.1. Классификация методик описания моделей при
проектировании ИС
Функциональные методики, наиболее известной из которых является методика IDEF0 (см. п. 2.3), рассматривают проект
как набор функций, преобразующих поступающий поток информации в выходной поток. Процесс преобразования информации
потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. Эта методика оптимально «ложится» на парадигму структурного программирования, которое широко применялось в 80-х годах прошлого века, а
сейчас вошла составной частью в парадигму ООП и поэтому не
потеряла своей актуальности.
Наиболее известные нотации для описания архитектуры с
использованием функциональных методик — это IDEF0, DFD,
SADT. В функциональных моделях структурными компонентами
являются функции (операции, действия, работы), которые на
диаграммах связываются между собой. Достоинством функциональных моделей является разработка структуры сверху вниз,
когда каждый функциональный объект может быть декомпозирован на множество подфункций и т. д. Эти модели достаточно
наглядны и понятны. При функциональном подходе отдельно
разрабатываются ER-диаграммы (сущность связь).
ER-диаграмма является обязательным следствием изучения предметной области. После разработки ER и IDEF–
диаграмм устанавливаются однозначные связи между объектами
59
и функциональными моделями. Изначально применялись SADT
нотации, потом при незначительном изменении использоваться
IDEF0 нотации.
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов. Объект
определяется как осязаемая реальность — предмет или явление,
имеющие четко определяемое поведение. При объектноориентированном подходе (ООП) изменяется принцип проектирования. Сначала выделяется класс объектов и возможные состояния объектов, а уже потом определяются методы обработки,
которые обеспечивают переход из одного состояния в другое, то
есть ООП модели изначально нацелены на динамику. Еще ООП
предполагает возможность наследования функций, значит, можно абстрагироваться от конкретной реализации процедур, и реализовать их, когда их смысл и их задачи станут детально ясны
(кроме наследования используется полиморфизм). К тому же
данное свойство (возможность доработки функции без переработки предыдущего) повышает адаптивность к применению
предметной области.
Эта методика оптимально «ложится» на ОО программирование, которое является в настоящее время господствующей парадигмой программирования. Методика базируется на языке
UML (см. п. 2.4).
Задача проектирования — описать архитектуру и интерфейс проекта наиболее полным и наглядным образом. Каждая из
представленных методик обладает своими преимуществами.
Функциональное моделирование хорошо работает, когда
структура предметной области находится в процессе изменения
или вообще слабо оформлена. Декомпозиция на выполняемые
функции интуитивно лучше понимается исполнителями.
При функциональном подходе для отображения состава и
иерархии данных отдельно разрабатываются объектные модели
данных в виде ER-диаграмм «объект — свойство — связь», где
данные понимаются не как функции, а как объекты. Устанавливаются взаимно однозначные связи между данными на ERдиаграммах и структурой проекта (функциями). В этом главный
недостаток функциональной методики.
60
В функциональных моделях главными структурными компонентами являются функции, которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу «сверху вниз»,
когда каждый функциональный блок может быть декомпозирован на множество подфункций. Для функциональных моделей
характерны процедурная строгость декомпозиции ИС и наглядность представления.
Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от
друга. Помимо функциональной декомпозиции существует
структура данных, находящаяся на втором плане. Кроме того, не
ясны условия выполнения процессов обработки информации,
которые динамически могут изменяться.
Эти недостатки функциональных моделей снимаются при
применении объектно-ориентированного проектирования (ООП)
благодаря трем основным принципам, на которых основана
ООП, инкапсуляции, наследованию, полиморфизму.
При ООП структура проекта представляется в виде набора
объектов. Объект обладает как набором данных, так и набором
функций, которые можно обрабатывать атрибуты (данные) это
го класса. В этом проявляется свойство инкапсуляции.
Для объектов характерна иерархия, позволяющая осуществлять наследование не только их атрибутов (данных), от
вышестоящего класса объектов к нижестоящему классу, но и
методов (функций). В случае наследования методов можно абстрагироваться от конкретного их текста: к ним можно обращаться, используя общие имена (полиморфизм) методов у родительского и дочернего класса объектов. То есть программный
код повторно используется при модификации ПО. Таким образом, значительно выше адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с
функциональным подходом.
При ОО подходе изменяется и принцип структурирования:
анализируется предметная область, определяются классы, имеющие непосредственное отношение к проекту, из которых и
строится структура разрабатываемого ПО. Далее для каждого
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]