Предшественники UML
Когда количество объектов информационной системы не превышает 6-8 (то есть психологического критерия, до которого человек еще способен оперировать информацией без записи и дополнительной тренировки), сложности, возникающие при проектировании системы, преодолимы и без специальных средств. Такую информационную систему (для одного рабочего места, для небольшой компании) способен создать один человек. Когда же число объектов достигает тысяч и десятков тысяч, а число состояний и переходов между ними — миллионов, ни один специалист, каким бы образованным и опытным он ни был, не способен охватить систему в целом. К примеру, система навигации должна размещаться на тысячах автомобилей, морских и речных судах, железнодорожных составах, десятках искусственных спутников Земли, использовать тысячи компьютеров и всевозможных сетей связи.
Такие информационные системы под силу создавать только группам разработчиков, как правило, с разделением обязанностей на аналитиков, проектировщиков, программистов, тестеров и, конечно, руководителей. А там, где трудится коллектив, просто необходим понятный всем инструмент общения. Для инженеров-ме- хаников таким инструментом, понятным как его коллегам, так и простым рабочим, являются машиностроительные чертежи, для строителей — всевозможные эскизы, планы и т. д., для инженеров-электронщиков — электрические схемы, топологические чертежи. Для программистов языком такого общения долгое время являлись алгоритмы и естественный человеческий язык. Каждый, кто хоть немного разбирается в программировании, понимает, что, за исключением очень простых примеров, без пояснений практически невозможно разобраться в коде программ, написанных не им самим, а часто и им самим, но давно.
Диаграммы на языке иМИ можно назвать «иллюстрациями к программному коду».
Создание диаграмм аналогично созданию проекта в строительстве — можно обойтись и без него, например, при строительстве сарая на дачном участке, однако чем больше здание, тем труднее это делать и тем неопределеннее конечный результат. Информационная система, описанная иМИ-диаграммами, показывает разработчику результат, который необходимо достичь в процессе проектирования. Проблема коммуникации внутри коллектива разработчиков, требующая документирования результатов проектирования, чтобы иметь возможность в дальнейшем вносить в систему усовершенствования, является не единственной побудительной причиной создания иМИ.
Абсолютное большинство информационных систем, используемых в наши дни, в той или иной степени опираются на объектно-ориентированную технологию. Ключевой в эффективности таких информационных систем является удачно построенная иерархия объектов, позволяющая использовать преимущества объектно-ориентированной технологии, включая инкапсуляцию, наследование и полиморфизм (подробнее об объектно-ориентированной разработке информационных систем см. далее в этой книге).
Выявление объектов-сущностей, их свойств, построение их иерархии является в большинстве случаев нетривиальной задачей, которая решается методами объектно-ориентированного анализа.
Иерархия объектов должна отражать закономерности функционирования предметной области, то есть области деятельности человека, для которой создается информационная система. Прямолинейное проектирование, как правило, не является оптимальным. Из практики известно, что самыми удачными решениями являются системы, авторам которых удалось найти «изящную» комбинацию, неординарный ход, «изюминку» в построении иерархии объектов информационной системы.
Построение иерархии объектов требует опыта и усердной работы аналитиков и сй- стемных проектировщиков, для облегчения интеллектуального труда которых весьма кстати пришлись возможности нотации (лат.
по1аНо — обозначение, система записи), позволяющей легко и понятно фиксировать возникающие идеи. Этой цели служат всевозможные кружочки, квадратики, стрелки и линии, с помощью которых человек пытается зафиксировать свои мысли на листе бумаги или в электронном документе. С появлением соответствующих методик, а впоследствии и имь такая запись становится стандартизированной и понятной другим людям.ПРИМЕЧАНИЕ------------------------------------------------------------------------------
Проблемой, ставящей под угрозу осуществление крупного проекта, является уход из команды разработчиков одного или нескольких ведущих специалистов. Использование стандарта документирования процесса разработки минимизирует риски срыва работы над проектом в таких случаях.
Универсальный язык моделирования возник не на пустом месте. С середины восьмидесятых годов ведутся разработки методик, позволяющих автоматизировать процесс построения иерархий объектов. Некоторые из методик, например С11С- карточки, не потеряли своей актуальности.
Еще по теме Предшественники UML:
- «Куранты»
- Упражнение 1
- ИДЕЯ 19 ЛУЧШЕЕ - ВПЕРЕДИ
- 15.5. ПРИНЦИП "ПАРКА ЮРСКОГО ПЕРИОДА"
- 9.6.2. Прорыв в IDS
- Заключение
- Вопросы для самоконтроля
- Лучшие и худшие черты дракона мученичества
- Традиции и новаторство в творчестве на телевидении.
- 7. ПОЛИТИЧЕСКАЯ КУЛЬТУРА.
- Доктринальные возражения
- Доктринальные возражения
- Места силы