Анализ требований разрабатываемой системы является важнейшим среди всех этапов жизненного цикла (ЖЦ). Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, так как если требования не зафиксированы и не доступны для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть простым и понятным заказчику (конечному пользователю).
Во многих аспектах системный анализ является наиболее трудной частью разработки. Попытка возложить эту работу на системного аналитика приводит к трудноразрешимым проблемам:
• аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;
• заказчик, в свою очередь, без CASE-средств не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является вы полнимым, а что – нет;
• аналитик сталкивается с чрезмерным количеством подробных сведений о ПО и новой системе;
• спецификация системы из-за объема и технических терминов часто непонятна для заказчика.
Конечные пользователи наиболее часто применяют следующие CASE-средства:
• для описания диаграмм потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями (Data Flow Diagrams – DFD);
• для описания диаграмм «сущность–связь» (Entity-Relationship Diagrams – ERD).
Рис. 10.1. Компоненты логической модели предметной области
Логическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также определяет хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и описания их компонентов хранятся и анализируются в СД. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация не имеет смысла, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также хранится в СД. Модель данных хранилища раскрывается с помощью ERD. Компоненты логической модели ПО показаны на рис. 10.1.
|
|
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбивают на функциональные компоненты (процессы) и представляют в виде сети, связанной потоками данных. Основное назначение диаграмм – демонстрировать, как каждый процесс преобразует свои входные данные в выходные и показывать отношения между этими процессами.
Для изображения DFD традиционно используют две различные нотации (нотация – язык описания): Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Рассмотрим основные символы DFD (табл. 10.1).
Таблица 10.1. Основные символы диаграммы потоков данных
Потоки данных – механизмы, используемые для моделирования передачи информации (или даже физических компонентов) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация движется в одном направлении, обрабатывается и возвращается назад в источник. Такая ситуация моделируется либо двумя различными потоками, либо одним – двунаправленным.
|
|
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить максимальную высоту). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных или БД позволяет на определенных участках найти данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, используется в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое можно не отражать на диаграмме.
Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например: СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.