4.8. Соглашения по именованию

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

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

Проблемы

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

Во время разработки никакие соглашения по именованию не использовались или использовались неоднородные соглашения.

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

Имена данных не указывают на использование данных; данные те же самые, а имена различные.

Использовались омонимы или синонимы.

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

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

Рекомендуемый подход

Определите существующие соглашения по именованию, используемые для описания даты. Некоторые примеры имен даты дает следующий список.

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

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

- Используемые Copybooks, JCL и общие программы могут существовать как в обновленном, так и в необновленном виде. Необходимо или переименовать эти объекты, или разработать альтернативные библиотеки и компилировать процедуры.

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

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

Логическая модель

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

Физическая модель

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

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

Автоматизированное обновление

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

Ручное обновление

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

Советы

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

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

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