«система». Лекция автоматизированные экономические информационные системы
 Скачать 0.87 Mb.
|
ЛЕКЦИЯ 3.МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ АЭИС.Внешнее и внутреннее проектирование АЭИС.Основа методологии разработки АЭИС – учет специфических особенностей, отличающих человеко-машинную систему, какой является АЭИС, от технических систем, соблюдение принципов ее разработки, важнейшим из которых является проведение разработки и внедрения на основе системного анализа. Это означает, что должно быть проведено всестороннее обследование автоматизируемой системы, выполнено ее моделирование, выявлен комплекс автоматизируемых функций, определена структура системы и ее подсистем, выбран наилучший вариант из возможных проектных решений. АСУ 70-80 гг. практически потерпели неудачу из-за того, что применялся частный, локальный, позадачный подход к проектированию АСУ. Предпроектная стадия практически игнорировалась и после самого общего ознакомления с объектом автоматизации по некоторым случайным признакам выбирались отдельные задачи для автоматизации. При этом организационная структура, набор и методы решения задач оставались неизменными. При таком подходе проектирование и внедрение заключается в моделировании отдельных задач, их программировании и внедрении автоматизированных методов обработки. Последовательно наращивая такие задачи, можно получить поэтапное внедрение АСУ. Кажущимися преимуществами такого подхода являются: быстрая автоматизация; получение в короткий срок эффекта от решения задач, который при удачном их выборе может быть достаточно ощутимым; обозримость разработки и внедрения системы; простота управления разработкой. Однако при этом нарушается ряд основных принципов разработки АСУ, что приводит в конечном итоге к низкой эффективности разработанной системы и самого процесса разработки – многократным переделкам и дублированию информации. Одной из важнейших специфических особенностей, отличающих АЭИС от технических систем, является тесная связь с внешней средой. Поэтому при разработке АЭИС выделяются внешнее и внутреннее проектирование. Эти этапы при разработке АЭИС полезно выполнять специалистами различного профиля. Внешнее проектирование формулирует цель и критерий эффективности будущей системы, выявляет ограничения – создается, экспериментально проверяется и корректируется модель системы. Определяются границы системы; фиксируются факторы внешней среды, имеющие значение для системы; определяются существенные связи, виды входных сигналов, на которые должна реагировать система; связанные с ними изменения выходных параметров. Иными словами, это этап выяснения взаимодействия системы с внешней средой, определения того, что и зачем будет делать система, почему она должна действовать так, а не иначе. Внутреннее проектирование определяет содержание самой системы – как, какими способами и средствами будет система выполнять свои функции, кто, где, когда будет выполнять необходимые операции и процедуры. Внешнее и внутреннее проектирование не являются самостоятельными, независимыми друг от друга этапами, они пересекаются и требуют взаимного согласования. Общая идея заключается в том, что сначала проводится внешнее проектирование для некоторых идеальных, ничем не ограниченных внутренних возможностей системы, затем – в первом приближении внутреннее проектирование, выявляя при этом ограничения, не позволяющие системе функционировать так, как это требуется в результате предварительного внешнего проектирования. Согласование заключается в изменении либо требований внешнего проектирования, либо ограничений внутреннего, либо того и другого. После такого согласования переходят к детальной, углубленной проработке вопросов внутреннего проектирования. Общие подходы к разработке информационных системКак можно выразить конкретные различия между большой и малой системами? На некотором уровне различия легко указать. Электронная таблица или приложение для поиска книг в личной библиотеке являются малыми, а приложение, которое планирует производство на машиностроительном заводе, конечно, большое. Таким образом, первый критерий при сравнении больших приложений с малыми - то, насколько трудно построить это приложение. Малые приложения довольно легки в построении, используются доступные инструментальные средства, требуются небольшие временные, материальные, человеческие ресурсы при их построении. Большие приложения трудны в построении даже с использованием доступных инструментальных средств, требуются большие временные, материальные, человеческие ресурсы при их построении. Линия раздела между большими и малыми системами слабо уловима. Тем не менее, два обстоятельства относительно ясны. Большие системы необходимы для больших и среднего размера организаций. Распределенные системы по своей природе более сложные, чем централизованные. Поэтому при проектировании больших распределенных систем необходимо использовать определенную методологическую базу. Прежде чем рассматривать конкретные методологии и технологии разработки ИС, рассмотрим общие подходы проектирования, которые применяются в любой методологии. Один из таких подходов – разделение проектов больших систем на серию малых. Конечно, общая система может все еще оставаться большой, но нужно свести ее ко многим малым частям, каждая из которых понятна. Существует два механизма разделения и управления сложностью в больших приложениях: абстрагирование и инкапсуляция. Абстрагирование - аналитический метод для разделения систем на множество слоев деталей, составляющих систему. Инкапсуляция - процесс объединения информации и поведения системы в некоторую новую сущность, именуемую компонентом. АбстрагированиеАбстракция - это описание, которое идентифицирует существенные свойства некоторого объекта, в то же время, скрывая его конкретные детали. Главным принципом проектирования систем является разработка такой архитектуры, которая обеспечивает множество уровней абстракций. При переходе к обобщению происходит перемещение вверх на один уровень абстракции. Абстракция скрывает второстепенные детали. Это означает, что, используя абстрагирование, можно скрыть множество деталей, которые не нужны на данном уровне приложения. Предположим, вы захотели описать процесс ходьбы. Вы можете описать этот процесс на разных уровнях детализации, которые называются уровнями абстракции. 1. Теоретически вы сможете описать движение миллионов электронов, атомов и молекул в теле идущего человека. Однако такое описание будет непонятным и неприемлемым для разработки. Никто не сможет разобраться в огромном множестве запутанных деталей на атомарном уровне описания идущего человека. 2. На более высоком уровне абстракции тело человека состоит из миллионов клеток, но существуют слишком много клеток для описания идущего человека на этом уровне детализации. 3. На еще более высоком уровне детализации тело состоит из подсистем, таких как скелет, мускулы, нервы, кровеносные сосуды и т.п. Вы сможете описать идущего человека, хотя полученное описание может представлять интерес только для врача. 4. Наконец, на самом высоком уровне детализации тело состоит из частей, которые знает любой ребенок: руки, ноги, ступни, пальцы и т.п. Этот уровень деталей наиболее общий, или наиболее абстрактный. Вы легко сможете описать идущего человека на этом уровне: поднять правую ногу, передвинуть ее вперед, опустить вниз и т.п. Сокращение количества видимых одновременно деталей - очень важный момент при описании и проектировании сложных систем. Как показано в примере, основной метод сокрытия деталей - определение конкретных уровней абстракции в приложении. Элементы абстракцииСлоистая архитектура, базирующаяся на абстракции, имеет три основные характеристики. 1. Ясно определенные слои. Слои должны строиться один на другом так, чтобы каждый новый слой обеспечивал более сложную и комплексную абстракцию по сравнению с нижележащим слоем. Например, клетки - более комплексные и сложные, чем молекулы, скелетная система более комплексная и сложная, чем клетки, из которых она состоит, и т.д. В то же время термин "высший уровень абстракции" использован для формирования конкретного указания о том, как слои абстракции строятся один на другом. 2. Формальные и явные интерфейсы между конкретными слоями. Каждый слой может обращаться к услугам нижележащего слоя. Интерфейсы определяют высокоуровневые действия, которые активизируют более детальное поведение, выполняемое на нижележащем слое. Это аналогично тому, как ваш мозг выдает команды - поднять правую ногу, опустить ее перед левой ногой. Эти высокоуровневые операции переводятся в специфические нервные сигналы, активизирующие группы мышц. Тем не менее, все эти детали скрыты высокоуровневым интерфейсом между вашим мозгом и телом. Эти операции являются доступными для вышележащего слоя, а интерфейс определяет точно, какие аспекты функций внутри данного слоя являются видимыми и доступными для внешнего мира. Например, ваш рациональный рассудок не имеет интерфейсных функций, позволяющих сознанию контролировать биение вашего сердца. В результате контроль пульса рассматривается как функция, недоступная вашему сознанию потому, что ее нет в интерфейсе. 3. Скрытые и защищенные детали внутри каждого слоя. Например, ваш рациональный рассудок обычно "думает" в терминах высокоуровневых действий, которые может выполнить тело; передвинуть руку, сделать шаг и т.п. В то же время ваше тело запрещает вашему рациональному рассудку контролировать его на более детальном уровне. Проиллюстрируем это. Когда вы начинаете бежать, часть вашего мозга, тело и нервная система заставляют сердце увеличить ритм. После того как вы остановились, ваше сердце начинает вновь биться медленнее. Это автоматическое поведение: вы не можете контролировать его вашим рациональным сознанием, даже если захотите. Инкапсуляция.Инкапсуляция - процесс объединения информации и поведения системы в некоторую новую сущность, именуемую компонентом. Чтобы лучше понять сущность инкапсуляции, необходимо обратиться к понятию объекта. Одно важное использование этого термина ориентировано на сочетание «субъект-действие-объект». Люди мыслят категориями объектов, с которыми они работают, перед тем как думают о действиях, которые хотят применить к данным объектам. Так, обычно человек сначала думает о гвозде и только потом о молотке как инструменте для забивания гвоздя в доску. На этом психологическом принципе основаны многие современные программные средства, ориентированные на дружественные интерфейсы пользователя. Объектно-ориентированные интерфейсы позволяют пользователю сначала думать о своей непосредственной работе (например, о составлении отчета или написании служебной записки), без необходимости вспоминать о том, что все это построено на системах обработки текстов, электронных таблицах и т.д. Выберите объект, откройте его - и подходящее действие или инструментальное средство вызывается для вас автоматически. Таким образом, в нашем контексте объектом может служить небольшой фрагмент программного кода приложения, реализующий некоторую функцию делового процесса. Например, это могут быть стандартные функции календаря, выдающие на экран информацию о количестве рабочих дней в месяце. Об объекте можно говорить как о некоторой совокупности данных и операций над ними, которую можно использовать при проектировании приложений, встраивая ее там, где это необходимо. Поток процессов простого приложения может представлять некоторую диаграмму объектов.  На объектном языке каждый процесс становится компонентом, который сотрудничает с другими компонентами. Эти объекты, хоть и велики, зато легко объяснимы и понятны. Представление процессов в виде объектов имеет два преимущества: Каждый объект представляет собой законченный деловой процесс того или иного слоя абстракции, поэтому его можно использовать при разработке больших систем в качестве составляющего элемента. Объекты независимы от языков программирования. Общим смыслом объектной ориентации является инкапсуляция (т.е. объединение) данных и конкретных программ, которые работают на этих данных, внутри одного отдельного объекта. Следовательно, работа с конкретными данными возможна только через интерфейс к соответствующим объектам. Не только полные слои, но даже конкретные компоненты, составляющие эти слои, формируются как объекты. В этом мире интерфейсы являются ключом к конкретным слоям, а также ко всем конкретным компонентам внутри них. До какой степени эти интерфейсы являются проработанными, до такой степени компонент будет в состоянии обеспечивать общие услуги широкому множеству других компонентов; все это является базой для идеи компонентов, которые взаимодействуют друг с другом. |