Дополнительноезадание
На тему: «Методологияинформационного моделирования Мартина»
ВВЕДЕНИЕ
На рубеже80-х г.г. Дж. Мартин выступил с проектом, названным новой информационнойтехнологией (НИТ). Необходимость НИТ обуславливалась тем, что длительностьтрадиционных методов разработки информационных систем превосходила времябезусловного морального старения их спецификаций. С момента, когда были сформированыи утверждены требования к будущей системе и до начала ее опытной эксплуатацииэти требования безнадежно устаревали. Для выхода из этой ситуации былопредложено участие в процессе создания и проектирования системы будущихпользователей.
Используя языкипрограммирования сверхвысокого уровня, специальные языки запросов к базамданных, и специальные языки для формальных спецификаций, пользователь, согласнозамыслу автора НИТ, должен был реализовать прототип будущей системы, которыйпредусматривал все нужные функции, но не удовлетворял требованиям эффективностииспользования ресурсов. Это реализовывалось профессиональными программистами,которые формировали ПО будущей системы.
Первый шаг кНИТ был сделан, когда ПЭВМ стали применяться при решении практических задач,таких как, управление деятельностью предприятий, планирование, информационныйпоиск в больших массивах информации, т.е. с появлением качественно нового типа- ИС. Сложился также определенный комплекс требований для ПЭВМ.
Методология информационногомоделирования Мартина
МетодологияМартина предоставляет общую стратегию разработки информационных систем,фокусирующую внимание на стратегическом планировании и бизнес-процессах. В тоже время она является и инженерным подходом к разработке ПО, т.к. обеспечиваетнисходящую пошаговую процедуру построения информационной системы (позволяя приэтом работать с неиерархическими структурами данных). Подход Мартина базируетсяна двух концепциях:
· послойногоцелостного подхода к разработке интегрированных приложений, базирующегося настратегическом плане развития информационных систем;
· первоначальнойнаправленности на моделирование данных, а затем на функциональное моделирование
Основныеэтапы подхода Мартина приведены на рис. 1.
/>
Рис. 1. Основные этапы подхода Мартина
1. Этапстратегического информационного планирования начинается с построениястратегического плана для бизнес-системы, включающего цели и стратегии ихдостижения. Далее строится модель предметной области, отражающая существующуюспецифику и определяющая основные бизнес-процессы и организационную структурубизнес-системы, а также определяется порядок разработки информационной системы.При моделировании используются диаграммы декомпозиции (иерархическиедревовидные структурные диаграммы) и диаграммы «сущность-связь» дляпредставления основных бизнес-процессов и структур данных, соответственно.
2. На этапеанализа основные бизнес-процессы, разработанные на этапе 1), используютсядля разбиения общей задачи на частные, при этом основное внимание уделяетсяопределению информационной и функциональной моделей для частных задач. При этомдиаграммы «сущность-связь» трансформируются в нормализованную модельданных, а диаграммы декомпозиции распределяются по подзадачам. Дляпредставления процессов служат DFD, диаграммы зависимости данных (диалект DFD)и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых этиданные используются, применяются матрицы «сущность/процесс».
3. На этапелогического проектирования IE становится аналогична SE для разработки ПО.Базой для проектирования являются процессы, разработанные на этапе анализа.Используя методики нисходящей функциональной декомпозиции, проектируютсяспецификации обработки в процессах и их логические структуры данных. При этомиспользуются диаграммы структуры данных (диалект ERD), определяющие типысущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности(вид миниспецификации), детализирующие логику процессов. Для согласованиятребований пользователя создаются прототипы пользовательских интерфейсов спомощью схем экранов/отчетов.
На этапе физическогопроектирования и реализации производится преобразование логической моделиИС в физическую и ее реализация.
Для полногопредставления о программном продукте необходима также текстовая информацияописательного характера.
Еще большуюзначимость информационные модели и структуры данных имеют для информационного моделирования предметной области, воснове которого положение об определяющей роли данных при проектированииалгоритмов и программ. Подход появился в условиях развития программных средстворганизации хранения и обработки данных — СУБД.
Основоположников информационной инженерии — Дж. Мартин — выделяет следующие составляющие данного подхода:
· информационныйанализ предметных областей (бизнес — областей);
· информационноемоделирование — построение комплекса взаимосвязанных моделей данных;
· системноепроектирование функций обработки данных;
· детальноеконструирование процедур обработки данных.
Первоначальностроятся информационные модели различных уровней представления:
· информационно-логическаямодель, не зависящая от средств программной реализации хранения и обработкиданных, отражающая интегрированные структуры данных предметной области;
· даталогическиемодели, ориентированные на среду хранения и обработки данных.
Даталогическиемодели имеют логический и физический уровни представления. Физическийуровень соответствует организации хранения данных в памяти компьютера. Логическийуровень данных применительно к СУБД реализован в виде:
· концептуальноймодели базы данных — интегрированные структуры данных под управлением СУБД;
· внешних моделейданных — подмножество структур данных для реализации приложений.
Средствамиструктур данных моделируются функции предметной области, прослеживаетсявзаимосвязь функций обработки, уточняется состав входной и выходной информации,логика преобразования входных структур данных в выходные. Алгоритм обработкиданных можно представить как совокупность процедур преобразований структурданных в соответствии с внешними моделями данных.
Выбор средствреализации базы данных определяет вид даталогические моделей и, следовательно,алгоритмы преобразования данных. В большинстве случаев используется реляционноепредставление данных базы данных и соответствующие реляционные языки дляпрограммирования (манипулирования) обработки данных СУБД и реализацииалгоритмов обработки. Данный подход использован во многих CASE-технологиях.
Объектно-ориентированныйподход кпроектированию программных продуктов основан на:
· выделении классовобъектов;
· установлениихарактерных свойств объектов и методов их обработки;
· создании иерархииклассов, наследовании свойств объектов и методов их обработки.
Каждый объектобъединяет как данные, так и программу обработки этих данных и относится копределенному классу. С помощью класса один и тот же программный код можноиспользовать для относящихся к нему различных объектов.
Объектныйподход приразработке алгоритмов и программ предполагает:
· объектно-ориентированныйанализ предметной области;
· объектно-ориентированноепроектирование.
Объектно-ориентированный анализ — анализ предметной области и выделение объектов,определение свойств и методов обработки объектов, установление их взаимосвязей.
Объектно-ориентированное проектирование соединяет процесс объектнойдекомпозиции и представления с использованием моделей данных проектируемойсистемы на логическом и физическом уровнях, в статике и динамике.
Дляпроектирования программных продуктов разработаны объектно-ориентированныетехнологии, которые включают в себя специализированные языки программирования иинструментальные средства разработки пользовательского интерфейса.
Традиционныеподходы к разработке программных продуктов всегда подчеркивали различия между даннымии процессами их обработки. Так, технологии, ориентированные наинформационное моделирование, сначала специфицируют данные, а затем описываютпроцессы, использующие эти данные. Технологии структурного подходаориентированы, в первую очередь, на процессы обработки данных с последующимустановлением необходимых для этого данных и организации информационных потоковмежду связанными процессами.
Объектно-ориентированнаятехнология разработки программных продуктов объединяет данные и процессы влогические сущности — объекты, которые имеют способность наследоватьхарактеристики (методы и данные) одного или более объектов, обеспечивая темсамым повторное использование программного кода. Это приводит к значительномууменьшению затрат на создание программных продуктов, повышает эффективностьжизненного цикла программных продуктов (сокращается длительность фазыразработки).При выполнении программы объекту посылается сообщение, котороеинициирует обработку данных объекта.
ПакетVisible Analyst Workbench(Visible Systems)
Visible Analyst Workbenchпредставляет собой сетевое многопользовательское средство проектированияинформационных систем, базирующееся на репозитарии, хранимом на сервереSQLBase, Oracle или Informix. Пакет основан на методологии Мартина иподдерживает следующие диаграммные техники:
· диаграммыфункциональной декомпозиции
· диаграммы потоковданных в нотациях Йодана и Гейна-Сарсона
· диаграммы“сущность-связь”
· структурные картыв нотации Константайна.
Пакет обеспечиваетгенерацию схем БД для вышеперечисленных СУБД и поддерживает технологию FRE.Имеется возможность экспорта проектов в системы SQLWindows, PowerBuilder иUniface.
К достоинствам пакетаможет быть отнесено наличие развитых средств верификации проекта, и преждевсего возможностей вертикального и горизонтального балансирования диаграмм. Такфункциональная и информационная модели сильно коррелированы, что позволяетизбавиться от лишних объектов моделей.
ВЫВОД
Деятельность Дж. Мартинапринесла огромное значение. В середине 80-х годов на фирме Du Pontбыл формализован подход к разработке информационных систем, использующийпоследовательный выпуск прототипов системы, жесткие ограничения по времени ивовлечение конечных пользователей системы в ее разработку. После публикации в1991г. книги Дж. Мартина «Rapid Application Development» (быстрая разработкаприложений) этот подход получил широкую известность как RAD-технология.Технология RAD более всего подходит при разработке интерактивных приложений, вкоторых функциональные возможности реализуются на уровне пользовательскогоинтерфейса. Четко определяется группа пользователей такого приложения. Большиеприложения подвергаются разбиению на более мелкие функциональные компоненты.
В основе RAD-технологиилежали следующие положения:
— Пользователиактивно участвуют в разработке системы от начала обследования предметнойобласти до внедрения приложения. Несколько представителей пользователейвключаются непосредственно в команду разработчиков. Представители остальныхпериодически участвуют в сессиях по пересмотру результатов работы, чтопозволяет устранять недопонимание между разработчиками и будущимипользователями системы.
— Не требуетсяполного определения требований к системе, детали могут быть добавлены в ходеразработки. Это позволяет сократить длительность этапа анализа и даетразработчикам определенную свободу в определении требований низкого уровня входе построения прототипов системы и их обсуждения с конечными пользователями.Выявленные в процессе разработки дополнительные требования ранжируются поважности. В условиях жестких временных ограничений менее приоритетныетребования могут быть опущены.
— Системаразрабатывается небольшой командой из 4—б человек, включая 1—2 представителейпользователей. Члены команды должны быть уполномочены принимать необходимыерешения. Во время разработки проекта состав команды практически не меняется,что позволяет уменьшить необходимость в промежуточной документации.
— Разработкаведется итерациями при тесном вовлечении пользователей на протяжении всегоцикла разработки системы. Основную роль играет правило 80/20, которое гласит,что 80 % работы может быть выполнено за 20 % времени, затрачиваемого на всюработу. Это означает, что нет смысла прикладывать усилия на тонкую настройкусистемы, когда еще до конца не определены основные требования к ней. Каждый шагдолжен быть закончен настолько, насколько это необходимо для выполненияследующей работы.
— На срок выпускакаждого прототипа накладываются жесткие ограничения по времени, превышатькоторые не разрешается. По истечении установленного срока прототиппредъявляется заказчику для обсуждения.
— Тестированиевыполняется постепенно на протяжении всего жизненного цикла системы.
— Разрабатываемаясистема разбивается на части, которые бригада из 4-6 человек способнаразработать за З—б месяцев. При наличии нескольких команд возможна параллельнаяразработка системы. В этом случае проводится более тщательный анализ прикладнойобласти.
Одним из важных положенийявляется необходимость сотрудничества между всеми участниками проекта. Сильнаясторона подхода RAD состоит в том, что он позволяет непосредственно в ходеразработки быстро выявлять и уточнять, необходимый набор функциональныхвозможностей .
ИСПОЛЬЗОВАННАЯЛИТЕРАТУРА:
1. Мартин Дж. Организация баз данныхв вычислительных системах. М.: Мир, 1980, 662 с.
2. Мартин Дж. Планирование развитияавтоматизированных систем. — М.: «Финансы и статистика», 1984.
3. www.interface.ru/fset.asp?Url=/case/defs8.htm
4. www.techno.edu.ru:16001/db/msg/15641.html