Раздел: Документация
0 ... 77 78 79 80 81 82 83 ... 96 спецификации состояний объекта, меняющихся в зависимости от развития событий. •Диаграмма действий (Activity Diagram) представляет собой модель, похожую на структурную схему программы. Показывает последовательность выполнения операций (действий). •Диаграмма реализации (Implementation Diagram) показывает структуру созданного программного обеспечения. Имеется два вида диаграмм реализации: диаграмма компонентов (Component Diagram) показывает структуру исходного кода, диаграмма размещения (Deployment Diagram) - структуру исполняемого программного обеспечения. Для объектной методики характерен набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение. В настоящее время наиболее естественно применять набор моделей, входящих в UML (универсальный язык моделирования). Этот язык стандартизован, широко используется и постоянно развивается. Распространенность языка UML можно объяснить тем, что он создан авторами трех самых известных в мире объектных методов (ОМТ, OOSE и Booch method). Прекращение «войны методов» и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей. Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Techology, Rational Software и др. Использование единого языка моделирования позволяет специалистам разных стран «говорить» на одном языке. На таком языке удобно составлять технические спецификации на коммерческие программные продукты. А стандартизация моделей облегчит интеграцию средств моделирования с другими инструментами. 3.4.7. Сравнение основных моделей - плюсы и минусы Для описания технических процессов организации достойной альтернативы диаграмме потоков данных пока не найдено. Конечно, эта модель обладает рядом недостатков, самым главным из которых является невозможность показать последовательность выполнения функций, если они входят в несколько технических процессов. По определению все процессы диаграммы потоков данных выполняются асинхронно, и каждый процесс иерархически вложен ровно в один родительский процесс. Для спецификации последовательности выполнения процессов нужно использовать особую разновидность модели - диаграмму функциональной зависимости. Однако диаграмма потоков данных обеспечивает наглядность преобразования входных данных в выходные, полную картину выполнения совокупности взаимодействующих процессов и возможность детально специфицировать выполнение каждой операции. И поскольку в настоящее время большое значение приобрели технологии анализа и оптимизации технических процессов, а перед созданием большой автоматизированной системы необходимо понять и описать ее место и роль в общем техническом процессе организации, диаграмма потоков данных своей актуальности не потеряла. Диаграмма «сущность - связь» подняла описание информации на качественно новый уровень. Аналитики получили возможность говорить о данных в терминах сущностей предметной области, а не структур хранения автоматизированных систем. В настоящее время имеется более богатая и выразительная модель описания данных -диаграмма классов. Однако диаграмму «сущность - связь» нельзя списывать со счетов. У нее есть одно большое достоинство: конструкции этой модели понятным образом соответствуют конструкциям реляционной модели данных. Наличие единого формализма для описания как сущностей предметной области, так и компонентов реляционной базы данных делает диаграмму «сущность - связь» удобным средством для описания хранимых в информационной системе данных. А простота преобразования модели в структуру базы данных (генерация SQL-кода) и обратно (реверс-инжиниринг базы данных) делает данную модель полезной в процессе сопровождения и развития базы данных иа сервере реляционной СУБД. Диаграмма вариантов использования (use case) очень удобна для описания функциональности автоматизированной системы. Каждый вариант использования - определенный сервис, который должна обеспечить автоматизированная система. В этих понятиях удобно описывать, что должна делать автоматизированная система, что нужно тестировать, что принимать у исполнителя. Также обеспечивается трассировка реализации исходных требований к автоматизированной системе. Большим недостатком данной модели является отсутствие изображения входных и выходных данных, а также информационных связей между вариантами использования. Нет единой картины взаимодействующих функций. Поэтому, как средство описания технического процесса, модель вариантов использования имеет существенные ограничения. Это скорее структурированный список операций, чем модель взаимодействующих функций. Данная модель не может без потери полноты описания заменить диаграмму потоков данных. Каждая из этих моделей обладает своими преимуществами и недостатками. Однозначно выбрать одну из них невозможно. Выбор зависит от того, что в первую очередь пользователь собирается описывать - комплекс взаимодействующих процессов или перечень реализуемых сервисов. Среди рассмотренных моделей диаграмма классов имеет наибольшее число выразительных возможностей. Это помогает при описании автоматизированных систем, но в то же время делает модель сложнее для построения и понимания. Диаграмма классов удобна при описании как предметной области, так и информационной системы. Следует однако заметить, что модель классов программного обеспечения не является развитием модели классов предметной области. Эти модели состоят из принципиально различных классов, существующих в разных мирах - реальной жизни и компьютерной программе. Следует четко различать модели как средство описания и методы их использования. Не следует недостатки отдельных методов распространять на используемые в них модели. Модели на основе структурной методики еще далеки от устаревания и определенная ниша их использования будет сохраняться и в будущем. Объектные модели позволили описать многие аспекты, перед которыми структурные модели бессильны. Но нельзя считать объектные модели современной заменой моделей структурных. Они также обладают рядом недостатков, ограничивающих их применимость. Пока рано говорить о наличии действительно универсального языка описания предметных областей и автоматизирующего их программного обеспечения. Нужно использовать все доступные средства. Чем богаче выбор таких средств, тем лучшего результата можно добиться. 3.4.8. Применение моделей Каждая из моделей имеет уникальные свойства, отсутствующие у других. И если качество работы улучшится при включении в проектные спецификации какой-либо модели, то нет причин от нее отказываться. Совершенно непонятно, почему нужно делить эти полезные средства на два множества (структурные и объектные) и объявлять их не только несовместимыми, но противоречащими друг другу. Ведь, отказываясь от удобных сочетаний моделей разных методик, мы делаем системные спецификации менее выразительными. Наиболее правильным является рассмотрение всей совокупности моделей как единого набора инструментов. При построении каждой АС нужно выбирать те инструменты, которые больше всего подходят в данном конкретном случае, не сковывая себя рамками одного метода, каким бы популярным он ни был. Например, можно выбрать модель технических процессов для описания автоматизируемой деятельности, диаграмму вариантов использования и диаграммы взаимодействия для описания состава ПО, диаграмму «сущность - связь» для описания реляционной базы данных, структурную схему для описания наиболее сложных фрагментов кода. 0 ... 77 78 79 80 81 82 83 ... 96
|
