1. Технология проектирования информационных систем.
Под проектированием ИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии со стандартами в проект ИС.
В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Так, технологический процесс проектирования ИС в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий. Действия, которые выполняются при проектировании ИС, могут быть определены как неделимые технологические операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными действиями, которые вырабатывают по установленным критериям оценки результатов проектирования.
Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего стало бы ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано.
2. Принципы проектирования сложных объектов.
При проектировании сложных объектов используются следующие принципы:
• декомпозиция и иерархичность построения описаний объектов проектирования;
• многоэтапность и итерационность процесса проектирования;
• типизация и унификация проектных решений.
Описания технических объектов должны быть по сложности согласованы:
1) с возможностями восприятия человеком;
2) с возможностями оперирования описаниями в процессе их преобразования с помощью имеющихся средств проектирования.
3. Математическая модель технического объекта. Особенности параметров в моделях проектируемых объектов.
Математическая модель (ММ) технического объекта — система математических объектов (чисел, переменных, матриц, множеств и т.п.) и отношений между ними, отражающих некоторые свойства технического объекта.
Выделим следующие особенности параметров в моделях проектируемых объектов:
1) Внутренние параметры в моделях k-го иерархического уровня становятся выходными параметрами в моделях более низкого (k +1)-го иерархического уровня. Так, например, трудовые ресурсы являются внутренними при проектировании производственной фирмы и в то же время выходными при проектировании отдела кадров этой фирмы.
2) Выходные параметры или фазовые переменные, фигурирующие в модели одной из подсистем (в одном из аспектов описаний), часто оказываются внешними параметрами в описании других подсистем (других аспектов). Так, например, выходные параметры подсистемы планирования выпуска продукции некоторой компании являются внешними параметрами подсистемы материально-технического снабжения этой компании.
3) Большинство выходных параметров объекта являются функционалами.
4) В техническом задании на проектирование должны фигурировать величины, называемые техническими требованиями к выходным параметрам (нормами выходных параметров). Данные нормы представляют собой границы допустимых диапазонов изменения выходных параметров.
4. Классификация типовых проектных процедур.
Различают проектные процедуры анализа и синтеза. Синтез заключается в создании описания объекта, а анализ — в определении свойств и исследовании работоспособности объекта по его описанию, т.е. при синтезе создаются, а при анализе оцениваются проекты объектов.
Процедуры анализа делятся на процедуры одно- и многовариантного анализа. При одновариантном анализе заданы значения внутренних и внешних параметров, требуется определить значения выходных параметров объекта. Подобная задача обычно сводится к однократному решению уравнений, составляющих математическую модель, что и обуславливает название этого вида анализа. Многовариантный анализ заключается в исследовании свойств объекта в некоторой области пространства внутренних переменных. Такой анализ требует многократного решения систем уравнений (многократного выполнения одновариантного анализа).
Процедуры синтеза делятся на процедуры структурного и параметрического синтеза. Целью структурного синтеза является определение структуры объекта — перечня типов элементов, составляющих объект, и способа связи элементов между собой в составе объекта. Параметрический синтез заключается в определении числовых значений параметров элементов при заданных структуре и условиях работоспособности на выходные параметры объекта, т.е. при параметрическом синтезе нужно найти точку или область в пространстве внутренних параметров, в которых выполняются те или иные условия (обычно условия работоспособности).
5. Сущность структурного подхода к проектированию информационных систем.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции на автоматизируемые функции: т.е. система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, эти подфункции подразделяются на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов:
• принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип иерархического упорядочивания, т.е. принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
• принцип абстрагирования: заключается в выделении существенных аспектов системы и отвлечения от несущественных;
• принцип формализации: заключается в необходимости строгого методического подхода к решению проблемы;
• принцип непротиворечивости: заключается в обоснованности и согласованности элементов;
• принцип структурирования данных: заключается в том, что данные должны быть структурированы и иерархически организованы.
6. Общие сведения о методологии SADT. Понятия субъекта, цели и точки зрения модели.
Методология SADT (Structured Analysis and Design Technique) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система. Однако моделируемая система никогда не существует изолированно: она всегда связана с окружающей средой. Причем зачастую трудно сказать, где кончается система и начинается среда. По этой причине в методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов. Вот почему утверждается, что SADT-модель должна иметь единственный субъект.
С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. С этой фиксированной точки зрения можно создать согласованное описание системы так, чтобы в модели не смешивались бы несвязанные описания.
7. Общие сведения о методологии SADT. Диаграмма и функциональный блок, их связь между собой.
Методология SADT (Structured Analysis and Design Technique) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы— главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показывается с левой стороны блока, а результаты выхода— с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
8. Методология SADT. Типы взаимосвязей между блоками. Разветвление и слияние дуг. ICOM-коды дуг.
Методология SADT (Structured Analysis and Design Technique) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
В методологии SADT требуется только пять типов взаимосвязей между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.
Разветвления дуг, изображаемые в виде расходящихся линий, означают, что все содержимое дуг или его часть может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору.
Слияние дуг в SADT, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения.
В SADT принята система обозначений, позволяющая аналитику точно идентифицировать и проверять связи по дугам между диаграммами. Эта схема кодирования дуг — «ICOM» — получила название по первым буквам английских эквивалентов слов «вход» (Input), «управление» (Control), «выход» (Output), «механизм» (Mechanism). Коды ICOM чрезвычайно эффективны, поскольку они позволяют аналитику быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего блока родительской диаграммы.
9. Общие сведения об объектно-ориентированном проектировании. Этапы жизненного цикла в данном подходе.
Объектно-ориентированное проектирование— это подход к решению задач с использованием моделей, основанных на понятиях реального мира. Фундаментальным элементом является объект, объединяющий структуру данных с поведением. Характеристики объектно-ориентированного подхода включают в себя индивидуальность, классификацию, наследование и полиморфизм.
Описываемая методология включается в себя следующие этапы:
1) Концептуализация системы. Разработка программного обеспечения начинается с бизнес-аналитиков или пользователей, которые придумывают приложение и формируют первичные требования к нему.
2) Анализ. Аналитик тщательно исследует и переформулирует требования, конструируя модели, исходя из концепций системы. Аналитик должен работать с заказчиком, чтобы добиться понимания задачи, потому что формулировки редко оказываются полными и корректными.
3) Проектирование системы. Команда разработчиков продумывает стратегию решения задачи на высшем уровне, определяя архитектуру системы. На этом этапе определяются политики, которые послужат основой для принятия решений на следующих этапах. Проектировщик системы должен выбрать параметры системы, по которым будет проводиться оптимизация, предложить стратегический подход к задаче, провести предварительное распределение ресурсов. Например, проектировщик может решить, что любые изменения изображения на экране рабочей станции должны быть быстрыми и плавными, даже при перемещении и закрытии окон. На основании этого решения он может выбрать подходящий протокол обмена и стратегию буферизации памяти.
4) Проектирование классов. Проектировщик классов уточняет аналитическую модель в соответствии со стратегией проектирования системы. Он прорабатывает объекты предметной области и объекты модели приложения, используя одинаковые объектно-ориентированные концепции и обозначения, несмотря на то, что эти объекты лежат в разных концептуальных плоскостях. Цель проектирования классов состоит в том, чтобы определить, какие структуры данных и алгоритмы требуются для реализации каждого класса.
5) Реализация. Ответственные за реализацию занимаются переводом классов и отношений, образовавшихся на предыдущем этапе, на конкретный язык программирования, воплощением их в базе данных или аппаратном обеспечении. Никаких усложнений на этом этапе быть не должно, потому что все ответственные решения уже были приняты на предыдущих этапах.
10. Основные концепции в объектно-ориентированном проектировании.
Абстракция. Абстракция означает сосредоточение на важнейших аспектах приложения и игнорирование всех остальных. Сначала принимается решение о том, что представляет собой объект и что он делает, а затем подбирается способ его реализации.
Инкапсуляция. Инкапсуляция, или, иначе говоря, сокрытие информации, состоит в отделении внешних аспектов объекта, доступных другим объектам, от деталей внутренней реализации, которые от других объектов скрываются. Инкапсуляция исключает возникновение взаимозависимости участков программы, из-за которых небольшие изменения приводят к значительным непредвиденным последствиям.
Объединение данных и поведения. При вызове операции не нужно беспокоиться о том, сколько реализаций этой операции существует в системе.
Совместное использование. Объектно-ориентированные технологии способствуют совместному использованию сущностей на самых разных уровнях. Наследование структур данных вместе с поведением дает возможность подклассам совместно использовать общий код.
Выделение сущности объекта. Объектно-ориентированная технология выделяет то, чем объект является, а не то, как он используется. Использование объекта зависит от особенностей приложения и часто изменяется в процессе разработки.
Когда целое больше суммы частей. Все объектно-ориентированные языки характеризуются поддержкой концепций индивидуальности, классификации, полиморфизма и наследования. Каждая из этих концепций может использоваться сама по себе, однако вместе они образуют нечто большее
11. Концепции объекта и класса в объектно-ориентированном проектировании.
Объект является экземпляром класса. Класс описывает группу объектов с одинаковыми свойствами (атрибутами), одинаковым поведением (операциями), типами отношений и семантикой. В качестве примеров классов можно привести следующие: «человек», «компания», «процесс» и «окно». Каждый человек имеет имя и дату рождения, а также может где-либо работать. Каждый человек- процесс имеет владельца, приоритет и список необходимых ресурсов. Классы часто бывают именами нарицательными и именными группами, которые используются в описании задач или при общении с пользователями.
Объекты одного класса имеют одинаковые атрибуты и формы поведения. Большинство объектов отличаются друг от друга значениями своих атрибутов и отношениями с другими объектами. Однако возможно существование разных объектов с одинаковыми значениями атрибутов, находящихся в одинаковых отношениях со всеми остальными объектами. Выбор классов зависит от природы и области применения приложения и зачастую является субъективным.
12. Концепции связи и ассоциации в объектно-ориентированном проектировании.
Связь— это физическое или концептуальное соединение между объектами. Например, Джо Смит работает на компанию Симплекс. В большинстве случаев связь соединяет ровно два объекта, но бывают связи, соединяющие большее количество объектов. С математической точки зрения связь является кортежем, то есть списком объектов. Связь— это экземпляр ассоциаций.
Ассоциация— это описание группы связей, обладающих общей структурой и общей семантикой. Например, человек может работать на какую-либо компанию. Связи, являющиеся экземплярами некоторой ассоциации, соединяют объекты тех классов, которые соединены между собой этой ассоциацией. Ассоциация описывает множество потенциальных связей точно так же, как класс описывает множество потенциальных объектов. Связи и ассоциации обычно присутствуют в постановке задачи в виде глаголов.
13. Обобщение и наследование в объектно-ориентированном проектировании.
Обобщение— это отношение между классом (суперклассом) и одной или несколькими его вариациями (подклассами). Обобщение объединяет классы по их общим свойствам, благодаря чему обеспечивается структурирование описания объектов. Суперкласс характеризуется общими атрибутами, операциями и ассоциациями. Подклассы добавляют к ним свои собственные атрибуты, операции и ассоциации. Говорят, что подкласс наследует составляющие суперкласса. Обобщение иногда называется отношением типа «является», поскольку каждый экземпляр подкласса одновременно является экземпляром суперкласса.
Простое обобщение упорядочивает классы в рамках некоторой иерархии. В этом случае каждый подкласс имеет одного непосредственного предка (его суперкласс).
Уровней обобщения может быть много.
14. События в объектно-ориентированном проектировании.
Событие— это происшествие, случившееся в определенный момент времени, например нажатие левой кнопки мыши. Часто события соответствуют глаголам в прошедшем времени (питание было включено, будильник был установлен) или выполнению некоторого условия (опустошился лоток для бумаги) в описании задачи. По определению, событие происходит мгновенно, по крайней мере, во временном масштабе приложения. Событие рассматривается как атомарное и скоротечное происшествие. Неявным атрибутом события является момент его осуществления.
Продолжительные изменения, осуществляющиеся в течение некоторого промежутка времени, хорошо описываются с помощью концепции состояния. Одно событие может логически предшествовать другому или следовать за ним.
События могут быть и несвязанными друг с другом. Несвязанные события называются параллельными. Они никак не влияют друг на друга. Если временная задержка при передаче информации между двумя точками превышает временной интервал между событиями, эти события обязаны быть параллельными, поскольку они никак не могут повлиять друг на друга. При моделировании системы не следует задавать относительный порядок параллельных событий, потому что на практике они могут происходить в любом порядке.
15. Состояния в объектно-ориентированном проектировании.
Состояние— это абстракция значений и связей объекта. Множества значений и связей группируются в состояние в соответствии с массовым поведением объектов. Например, состояние банка может быть «платежеспособный» или «банкрот», в зависимости от того, что больше: активы или обязательства. Состояния часто соответствуют отглагольным формам или деепричастиям (Ожидает, Дозванивается) или выполнению некоторого условия (Включен, НижеТочкиЗамерзания).
Определяя состояния, мы не учитываем атрибуты, не оказывающие влияния на поведение объекта, и объединяем вместе в одно состояние все комбинации значений и связей, характеризующиеся одинаковыми откликами на события. Разумеется, каждый атрибут должен влиять на поведение, иначе он не будет иметь никакого значения, однако достаточно часто некоторые атрибуты не влияют на последовательность управления. Их можно рассматривать просто как значения параметров состояния.
16. Переходы и условия в объектно-ориентированном проектировании.
Переход— это мгновенная смена одного состояния другим. Например, когда вы отвечаете на входящий звонок, телефонная линия переходит из состояния Звонок в состояние Разговор. Говорят, что переход запускается при смене исходного состояния целевым. Исходное и целевое состояния обычно отличаются друг от друга, но могут и совпадать. Переход запускается, когда происходит связанное с ним событие (если только необязательное сторожевое условие не приводит к игнорированию события). Выбор целевого состояния зависит как от исходного состояния, так и от полученного события. Событие может вызвать переходы во множестве объектов. С концептуальной точки зрения эти переходы происходят одновременно.
Сторожевое условие — это логическое выражение, которое должно быть истинным, чтобы переход мог запуститься. Например, сигнал светофора на перекрестке может переключиться только в том случае, если на дороге имеются ожидающие этого машины. Переход со сторожевым условием запускается в тот момент, когда осуществляется соответствующее событие, но только если в этот же момент выполнено его сторожевое условие. Например, «когда будешь выходить из дома (событие), если на улице будет ниже нуля (условие), — надень перчатки (целевое состояние)». Сторожевое условие проверяется только один раз, в тот момент, когда осуществляется событие, и если условие выполняется — происходит переход.
Обратите внимание, что сторожевое условие концептуально отличается от события: условие проверяется только один раз, тогда как наличие события, по сути, проверяется непрерывно.
17. Диаграммы состояний в объектно-ориентированном проектировании. Различия между диаграммами состояний непрерывного цикла и одноразового жизненного цикла.
Диаграмма состояний— это граф, узлами которого являются состояния, а направленными дугами — переходы между состояниями. Диаграмма состояний описывает последовательности состояний, вызываемые последовательностями событий. Названия состояний должны быть уникальными в рамках диаграммы. Все объекты класса следуют диаграмме состояний, описывающей общее для них поведение. Диаграмма состояний может быть реализована непосредственной интерпретацией или преобразованием семантики в эквивалентный программный код.
Диаграммы состояний могут описывать непрерывные циклы или одноразовые жизненные циклы. Диаграмма состояний телефонной линии является непрерывным циклом. Описывая обычные режимы использования телефона, мы не интересуемся тем, каким образом цикл был запущен.
Одноразовые диаграммы состояний описывают объекты с конечным сроком существования. Такие диаграммы имеют начальное и конечное состояния. Сразу после создания объект оказывается в начальном состоянии. Вход в конечное состояние означает уничтожение объекта.
18. Поведение на диаграммах состояний в объектно-ориентированном проектировании.
Диаграммы состояний были бы не слишком полезны, если бы они описывали только события. Полное описание объекта должно указывать, что именно делает объект в ответ на события.
Действие — это ссылка на поведение, выполняемое в ответ на произошедшее событие. Деятельность — это фактическое поведение, которое может вызываться любым количеством действий. Например, деятельность разъединить Линию может выполняться при переходе, при входе в состояние или при выходе из него, а также при наступлении какого-либо иного события в состоянии.
Деятельность может описывать внутренние управляющие операции, например установку атрибутов или порождение других событий. Эта деятельность не имеет аналогов в реальном мире и предназначена для структурирования управления при реализации. Например, программа может увеличивать внутренний счетчик на единицу каждый раз при осуществлении какого-либо события.
Деятельность обозначается косой чертой (/), после которой ставится название или описание деятельности. Деятельность указывается после вызывающего ее события. Ключевое слово «do» используется для обозначений текущей деятельности и не может использоваться в качестве имени события.
19. Модели вариантов использования в объектно-ориентированном проектировании
Различные взаимодействия действующих лиц с системой группируются в варианты использования. Вариант использования— это связный элемент функциональности, представляемый системой при взаимодействии с действующими лицами. Например, лицо Клиент может купить напиток в торговом автомате. Клиент кидает монеты в автомат, выбирает продукт и забирает свой напиток. Ремонтник может провести техническое обслуживание автомата.
В каждом варианте использования участвуют одно или несколько действующих лиц и система. В варианте использования купить напиток участвует лицо Клиент, а в варианте использования провести плановый ремонт участвует лицо Работник. Вариант использования подразумевает обмен последовательностью сообщений между системой и действующими лицами. Например, в варианте использования купить напиток Клиент сначала вставляет монету, а торговый автомат отображает текущий аванс. Эта процедура может быть повторена несколько раз.
Затем клиент нажимает кнопку выбора товара, а автомат выдает заказанный товар и сдачу, если таковая имеется.
Некоторые варианты использования характеризуются фиксированной последовательностью сообщений. Однако чаще последовательность сообщений может варьироваться в определенных пределах. Например, клиент может кинуть в автомат некоторое количество монет (вариант использования купить напиток). В зависимости от количества и номинала монет, а также от выбранного товара автомат может либо вернуть сдачу, либо нет. Вариации последовательностей можно показать, продемонстрировав несколько примеров различающихся между собой последовательностей поведения. Обычно сначала определяется основная последовательность, а затем— необязательные последовательности, повторения и другие вариации.
20. Модели деятельности в объектно-ориентированном проектировании.
Диаграмма деятельности показывает последовательность этапов, образующих сложный процесс, например вычислительный алгоритм или технологический процесс. Диаграммы деятельности особенно полезны на ранних этапах проектирования алгоритмов и технологических процессов.
Диаграмма деятельности похожа на обычную блок-схему, потому что тоже показывает поток управления от этапа к этапу. Однако в отличие от блок-схемы диаграмма деятельности может показывать одновременно параллельную и последовательную деятельность. Это отличие важно для распределенных систем. Диаграммы деятельности часто используются для моделирования организаций, потому что последние состоят из множества объектов (людей и организационных единиц), одновременно выполняющих множество операций.
Элементами диаграммы деятельности являются операции, а именно виды деятельности из модели состояний. Назначение диаграммы деятельности состоит в том, чтобы показать этапы сложного процесса и упорядочивающие ограничения, на них наложенные.
Некоторые виды деятельности выполняются до тех пор, пока не будут прерваны каким-либо внешним событием, однако в большинстве случаев деятельность имеет собственное логическое завершение. Завершение деятельности является событием завершения, которое обычно означает возможность начала выполнения следующей деятельности. Стрелка без надписи, соединяющая две деятельности на диаграмме, означает, что вторая деятельность может начаться только после того, как закончится первая.