Человеческий фактор в программировании

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

Разработка хорошей системы обозначений подобна разработке хорошего графического интерфейса. Целью здесь является сокращение нагрузки на человеческую память. Великий закон юзабилити утверждает, что система должна быть доступной для использования человеком, который знает о ее назначении, но не знаком с ее программным обеспечением. При этом не должно возникать необходимости в обучении, помощи или руководствах (Constantine, 1991 [14]). Таким образом, по-настоящему хорошая система обозначений — это такая система, которую опытный разработчик, знающий, как проектировать и писать программы, сможет интуитивно понять без шпаргалок и недельных курсов обучения. Вы не должны запоминать разные условные обозначения (например, то, что прямоугольник с двойной рамкой означает динамический объект, а прямоугольник с флажком в углу — компонент библиотеки).

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

Сильные связи между частями должны выглядеть, как сильные связи; слабые связи должны выглядеть, как более слабые. Устойчивые объекты должны быть показаны сплошными фигурами, а динамические объекты должны выражать смысл активности или изменяемости. Например, наследование одним классом свойств и характеристик другого класса означает, что подкласс в большой степени зависит от родительского класса — подобно тому как генетические особенности ребенка сильно зависят от особенностей обоих родителей. Для точного отражения характеристик программного обеспечения, использующего наследование, этот механизм должен быть показан более четко, чем передача сообщения объекту или ссылка на него как на атрибут (Page-Jones, Constantine и Weiss, 1990 [57]).

Сделать систему обозначений интуитивно понятной и простой в изучении помогут небольшие детали. В системе обозначений для объектно-ориентированных программ, разработанной Джекобсоном (Jacobson и др., 1992 [44]), те объекты, которые взаимодействуют с внешним окружением, на одной стороне имеют символ (- в качестве визуального ключа, обозначающего это взаимодействие. Динамические объекты, которые управляют последовательностью действий, снабжены стрелкой, входящей в границу, что означает цикл или итерацию. В нескольких системах обозначений внутренние элементы компонентов, которые доступны извне, показаны в виде расширений границы компонента.

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

Подумайте об этом.

Из журнала Software Development, том 2, № 3, март 1994 г.

21 Методичное сумасшествие

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

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