 |
Профиль прикладного программного обеспечения.
|
|
|
|
Прикладное программное обеспечение всегда является проблемно ориентированной. И определяет основные функции информационной системы. Функциональные профили системы должны включать в себя согласованные базовые стандарты. При использовании функциональных профилей информационных систем данные профили согласуются между собой. Необходимость такого согласования возникает при использовании стандартизованные прикладных программных интерфейсов. В том числе интерфейсов приложений со средой их функционирования и со средствами защиты информации. При согласовании функциональных профилей возможны также уточнение профиля среды системы и профиля встраиваемых инструментальных средств (создание, сопровождение и развитие прикладного программного обеспечения).
Профиль среды информационной системы.
Должен определять ее архитектуру в соответствии с выбранной моделью обработки данных. Стандарты интерфейсы приложений должны быть определены по функциональным областям профиля информационной системы. Декомпозиция структуры среды функционирования системы на составные части выполняемые на стадии проектирования. Позволяет детализировать профиль среды информационной системы последующим функциональным областям эталонной модели открытых систем.
1. Графического пользовательского интерфейса.
2. Объектно-ориентированных СУБД или реляционных.
3. Операционных систем с учетом сетевых функций выполняемых на уровне операционных систем.
4. Телекоммуникационной среды в части услуг и служб прикладного уровня (электронные почты, доступы к удаленным базам данных).
Профиль среды распределенной системы должен включать стандарты протоколов транспортного уровня, стандарты локальных сетей, а так же стандарты средств сопряжения проектированной информационной системы с сетями передачи данных общего назначения. Выбор аппаратных платформ информационных систем связаны с определением их параметров. Вычислительной мощности серверов и рабочих станций. С соответствии с проектными решениями по разделению функций между клиентами и серверами. Степени масштабируемости аппаратных платформ (надежности). Профиль среды должен содержать стандарты определяющий параметры технических средств и способы их измерения. Например стандартные тесты измерения производительности.
|
|
|
Профиль защиты информации.
Профиль защиты информации должен обеспечивать реализацию политики информационной безопасности. В соответствии с требованием категории безопасности и критериями безопасности в заданной с техническом задании на систему. Построение профиля защиты информации в распределенных системах клиент-сервер связано с точным определением компонентов системы ответственных за те или иные функции службы и услуги и средств защиты информации встроенных в эти компоненты. Функциональная область защиты информации включает в себя следующие функции реализуемые разными компонентами системы.
1. Функции, реализуемые операционными системами.
2. Функции защиты от несанкционированного доступа реализуемый на уровне программного обеспечения промежуточного слоя.
3. Функции управления данными реализуемые СУБД.
4. Функции защиты программных средств (включает средство защиты от вирусов).
5. Функции защиты информации при обмене данными в распределенных системах включая криптографические функции.
6. Функции администрирования средств безопасности.
Профиль защиты информации должен включать указания на методы и средства обнаружения применяемых аппаратных и программных средствах не декларированных возможностей. Профиль должен так же включать указания на методы и средства резервного копирования информации и восстановление информации при отказах и сбоях аппаратуры системы.
|
|
|
Профиль инструментальных средств.
Профили инструментальных средств встроенных информационную систему должен отражать решение по выбору методологии и технологии создания, сопровождение и развитие информационной системы. В этом профиле должны содержаться ссылки на описание выбранных методологии и технологии выполненные на стадии проектирования. В состав инструментальных средств определяется на основании решений и нормативных документов в организации, сопровождения и развития информационной системы. При этом должны быть учтены правила и порядок регламентирующие внесения изменений действующей системы. Функциональная область профиля инструментальных средств встроенных в систему охватывает функции централизованного управления и администрирования связанные:
1. С контролем производительности и корректности функционирования системы в целом.
2. Конфигурирование прикладного программного обеспечения тиражированием версий.
3. Управлением доступа пользователя к ресурсам системы и конфигурированием ресурсов.
4. Перенастройка приложений в связи с изменением прикладных функций информационной системы настройкой экранной формой и отчетов.
5. Ведением баз данных системы.
6. Восстановлением работоспособности системы после сбоев и аварии также должны быть учтены ресурсы необходимые для функционирования встроенных инструментальных средств.
Выбор инструментальных средств встроенных в систему должен производиться в соответствии с требованием профиля среды. В этом профиле должны содержаться ссылки на требования к средствам тестирования. Число встроенных средств тестирования должны входить в средства функционального тестирования приложений, тестирования интерфейсов, системного тестирования и тестирования серверов и клиентов максимальной нагрузки.
23 апреля 2011г.
Стандарты и методики.
Одним из важных условий эффективного использования информационных технологий является внедрение корпоративных стандартов. Корпоративные стандарты представляют собой соглашение о единых правилах организации технологии или управления.За основу корпоративных стандартов могут приниматься отраслевые национальные и международные стандарты.
|
|
|
Виды стандартов:
Условно стандарты можно разделить на несколько групп:
1) По предмету стандартизации.К этой группе относятся функциональные стандарты.(стандарты на языки программирования). И стандарты на организацию жизненного цикла, создание и использование Информационных систем и программного обеспечения.
2) По утверждающей организации. Официальные и международные,Официальные и национальные или ведомственные национальные стандарты.
Стандарты международных консорциумов и комитета по стандартизации.
Стандарты фактические.
Фирменные стандарты
3) По методическому источнику к этой группе относиться различного рода методические материалы ведущих фирм разработчиков программного обеспечения фирм консультантов научных центров консорциумов по стандартизации. Методика СDM компании Oracle. 1 из сложившихся направлений деятельности компании Oracle является разработка методологических основ и производства инструментальных средств для автоматизации процессов разработки прикладных систем ориентированных на интенсивное использование баз данных.Составляющие case технологии и инструментальной среды компании Oracle.
1) Методология структурного нисходящего проектирования при которой разработка прикладной системы представляется в виде последовательности четко определённых этапов
2) Поддержка всех этапов жизненного цикла прикладной системы начиная с самых общих описание предметной области до получения сопровождения готового программного продукта.
3) Ориентация на реализацию приложений в архитектуре клиент-сервер с использованием особенностей современных серверов Базы Данных включая ограничения о целостности хранимой процедуры триггеры Баз Данных,С поддержкой клиентской части всех современных стандартов и требование к графическому интерфейсу конечного пользователя.
|
|
|
4) Наличие централизованной Базы данных репозитария предназначен для хранения спецификаций, проекта прикладной системы на всех этапах её разработки.
5) Возможность одновременной работы с репозитарием многих пользователей.Централизованное хранения проекта системы и управление одновременным доступом к нему всех участников разработки поддерживает согласованность действия разработчика
6) Автоматизация последовательного перехода от одного этапа разработки с следующему используя специальное программное обеспечение
7) Автоматизация различных стандартных действий по проектированию и разработки приложения.Предусматривается генерация многочисленных отчетов по содержимым репозитария обеспечивающих полное документирование текущие версий системы на всех этапах её разработки с помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и не протеворечивость.
Общая структура методики CDM.
Методика CDM определяет следующие фазы жизненного цикла ИС.
1)стратегию
2)анализ т.е. формулирование детальных требований
3)проектирование преобразование требований в детальные спецификации системы
4)реализацию
5)внедрение
6)эксплуатацию поддержка сопровождения приложения планирование будущих функциональных расширений.
Первый этап связан описывающий деятельность организации технологической особенности работы. Цели являются построение моделей существующих процессов.Выявление их недостатков и возможных источников совершенствования.
Второй этап разрабатываются детальные концептуальные модели предметной области описывающие информационные потребности организации,особенности функционирования результатом является моделей 2 типов: 1) информационные отражающие структуру и общие закономерности предметной области 2)функциональные описывающие особенности решаемых задач
Третий Этап на основание концептуальных моделей вырабатываются технические спецификации будущей прикладной системы определяется структура состав Базы Данных специфицируется набор программных модулей.
На этапе реализации создаются программы отвечающие всем требованиям проектной спецификации.
Методика CDM выделяет следующие процессы протекающие на протяжении жизненного цикла ИС.
1)определение производственных требований
2) исследование существующих систем
3)определение технической архитектуры.
4)проектирование и построение Базы Данных
5)проектирование и реализация модулей.
6)конвертирование данных
7)документирования
8)тестирование
9)обучение
|
|
|
10)переход к новой системе поддержка и сопровождение.
Особенности методики CDM.
1)степень приспособляемости CDM ограничивается моделями жизненного цикла.
2)Методика не предусматривает включение дополнительных задач которые не оговарены в CDM и привязку к остальным задачам.
3) все модели жизненного цикла являются по сути каскадными
4)методика не является обязательной но считается фирменным стандартом.При формальной применении степень обязательности полностью соотвествуют ограничениям возможностям одоптации.
5)Прикладная система рассматривается в основном как программная техническая система. Возможность выполнения организационных структурных преобразований данной методики отсутсвует
6)Методика CDM в основном операция на эстнрументарий Oracle методика CDM 7)Методика CDM представляет собой конкретный материал детализированный до уровня загатовки пред проектных документов рассчитанных на прямое использование проектных ИС с опорами на инструментарий Oracle.
Он определяет основные.
30 апреля 2011 г.
Язык UML(моделирования)
Уницифицированный язык моделирования это графический язык для визуализации специфицирования конструирования и документирования систем в которых главная роль принадлежит программному обеспечению. С помощью UML можно разработать детальный план создаваемой системы содержащий системные функции,бизнес процессы и конкретные особенности языка,например – классы,схемы БД и так далее.
Принцыпы моделирования:
1) Выбор модели оказывает определяющие влияние на подход к решению проблемы на то как будет выглядеть это решение.
2) Каждая модель может быть представлена с разной степенью точности.
3) Лучшие модели те что ближе к реальности.
4) Нельзя ограничиваться созданием только 1 модели.Наилучший подход это разработки нестандарной системы используют совокупность нескольких моделй почти независимых друг от друга.
Позволяет строить точные не двусмысленные полные модели. UML язык конструирования отображение модели на языке контсроирования позволяет осуществивть прямое проектирование т.е. генерацию кода на языке прогромирования из модели UML возможно и обратное проектирование т.е. восстановление модели UML на основании имеющей реализации. UML предназначен документирования архитектуры системы и всех её деталей, кроме этого это язык для выражения требований к системе и описания тестов.
Наиболее эффективное применение UML в следующих областях коорпаративной информационной системы банковские и финансовые услуги, телекомуникации,транспорт,оборона авиации и космонавтики,розничная торгоавля,медицинская электроника,наука,распределённые веб сервисы.
Концептуальная модель UML.
Структурные блоки UML
1) Словарь UML 3 вида блоков
1.1) Это сущности
1.2) Это связи
1.3) Диаграммы
Сущности это абстракции которые являются основными элементами модели связи соединяют их между собой,а диаграммы группируют представляющие интерес наборы сущности.Существуют 4 вида сущности UML.
1) Структурные сущности
2) Поведенческие
3) Группирующие
4) Аннотирующие
Все они представляют собой базовые объектное ориентированные структурные блоки моделей UML.
Структурные сущности это в основном статические части модели,представляющие либо концептуальные либо физические элементы.
1. Класс это описание набора объектов с одинаковыми атрибутами,операциями, связями,классы реализуют 1 или несколько интерфейсов
2. Интерфейс это набор операций который специфицирует набора услуг класса или компонента.Интерфейс описывает видимое из-вне поведение элементов.Может представлять полное поведение класса в виде компонента либо тока часть такого поведения определяет набор спецификаций операций,но не когда не определяет детали реализации.Интерфейс представляемый классом отображется в виде маленького круга соединенного с рамкой класса,А интерфейс запрашиваемая класса отображающийся в виде маленького полукруга
3. Кооперация определяет взаимодествие и представляет совокупность ролей и других элементов которые функционируют вместе,обеспечивая некоторое совместное поведение,представляющие собой нечто большое чем сумма поведений отдельных элементов.Конткретный класс или объект могут участвовать в нескольких кооперациях.
4. Вариант использования use case описание последовательности действий выполняемой системой и приносящей результат действующему лицу,варианты использования применяются для структурирования поведенческих сущностей моделей.
5. Средство Кооперацией изображается в виде Элипса.
6. Активный класс - это класс объекты которого являются владельцами одного или нескольких процессов или потоков и могут инициировать.
7. Компонент это модульная часть системы которая скрывает свою реализацию за набором внешних интерфейсом.Компоненты системы расделяющие общие интерфейсы могут замещать друг друга сохраняю при этом одинаковое логическое поведение.
8. Артефакт это физическая незамечаемая часть системы несущая физическую информацию. Например фиалы исходного кода,скрипы исполняемые процедуры и т.д.
9. Узел это физический элемент который существует во время исполнения и переставляет вычислительный ресурс имеющий вычислительные возможности и некоторую память.
10. поведенческие сущности это динамические части моделей UML
10.1 взаимодействие. представляет собой поведение которое заключается в обмене сообщениями между наборами объектов или ролей в определённом контексте для достижения некоторых целей.Изображается в виде линий со стрелкой на которых пишутся.Отобразить
10.2 Это автомат представляет собой поведение характеризуемое последовательности состояний объекта которых он оказывается на протяжении своего жизненного цикла в ответ на событие вместе с его реакцией на событие.Поведение индивидуального класса или кооперации классов описывается в терминах автомата.Автомат включает в себя множество разных элементов состояния переходы события и действие.
10.3 Деятельность специфицирует последовательность шагов процесса вычислений.Отдельный шаг деятельности называется действие он изображается точно также как и состояние.
11. Группирующиеся сущности это организационная часть моделей UML главная из группирующих сущностей это пакет.Пакет это механизм общего назначения для организации проектных решений которых упорядочивает конструкции реализации,структурные сущности,поведенческие сущности и другие группирующие сущности могут быть помещены в пакет,пакет изображается в виде в папке с заклаткой.
12. Аннатирущиеся сущности – это поясняющие части UML моделей которые можно применить для описания выделения и пояснения любого элемента модели.
Типы связи в UML
1. Зависимость
2. Ассоциация
3. Обобщение
4. реализация
Связи испольются для хорошего согласование моделей.
1)Зависимость представляет собой связь между 2 элементами моделей в которой изменения элемента независимого может провести к изменению 1 элемента не зависимого может привести к изменению Другова элемента зависимого.
2)ассоциация это структурная связь между классами которая описывает набор связей существующих между объектами экзапляров классов изображается в виде сплошной линии.Это разновидность ассоциаций представляющие собой структурную связь целого с его частями
3) обощение выражает специализацию в которой специализированный элемент,потомок строиться по спецификациям обощенного элемента т.е. предка потомок разделяет структуру и поведения родителя графически представляется в виде сплощной стрелки указывающей на родителя.
4)реализация это связь между классификаторами когда 1 из них специфицирует соглашение,а 2 обязан его придерживаться бывает в 2 случаях между интерфейсами и классами которые реализуют эти интерфейсы а также между вариантами использования и реализующим их кооперациями.
Диаграмма UML.
Это графическое предстваление изображение элементов в виде связанного графа вершин(сущностей) и путей (связи) используется 13 видов диаграмм
Классов
Объектов
Компонентов
Составной структуры
Вариантов использование
Последовательности
Коммуникаций
Состояний
Деятельности
Размещения
Пакетов
Временная
Обзора взаимодействий.
Диаграммы UML.
Диаграмма классов показывает набор классов интерфейсов и коопераций а также их связи.Диаграммы данного вида чаще всего используются для моделирования объектно ориентированных систем. Предназначен для статического. Диаграммы классов включающие активные классы представляют статическое представление процессов системы. Диаграммы компонентов являются разнавидностю диаграммы классов. Диаграмма обьектов показывает набор обьектов и их связи Диаграммы объектов представляют статические копии состояний экзепляров сущности описанных в диаграмме классов,так же представляют статическое представление дизайна или статическое представление процессов системы с точки реальных ситуаций.
Диаграмма копонентов показывает классы и их интерфейсы порты внутренними структурами состоящие из вложенных компонентов и коннектеров. Диаграммы компонентов описывают статическое представление дизайна системы. Диаграмма компонентов применятеся чаще всего при построении больших систем из отдельных модулей.
Диаграмма вари ентов использования демонстрирует набор вариантов использования и действующих лиц а также их связи. Диаграммы этого типа описывают статическое представление. Вариантов использования системы важны для организации и моделирования поведения системы диаграмма взаимодествия показывает взаимодейсмтвие состоящие из набора обьектов и ролей включая сообщения которые могут передоваться между ними. Диаграмма взаимодействия предназначена для динамического представления системы имеет 2 вида диаграмму последовательностей и коммуникаций это разновидность диаграммы показывающий временную последовательность событий диаграмма коммуниакиций показывающий структурою организацию объектов или ролей отправляющих или принимающих сообщения. Диаграмма состояний. Показывает автомат включающая в себя состояния переходы,события и деятельность. Диаграммы состояния описывают деномическое представление обьекта,важны для моделирования поведение интерфеса,классов,или коопераций поддчернкивают событийное произведение обьекта,что бывает удобно для моделирухим систем. Диаграмма деятельности показывает структруру процесса или других вычеслений как пошаговый поток упраления и данных,дигармма деятельности описывают ограниченное представление системы важны при моделировании функции системы и выделяют поток управления между обьектами.
Диаграмма размещения показывает конфигурацию узлов а также размещаемых для них компоненты диаграмма размещения дают статические представление архитектуры системы,узлы как правило содержат 1 или несколько артефактов. Диаграмма артефактов представляет собой физических состав компютерной системы артефакты представляют собой фаилы базы данных и другие подобные обьекты. Диаграммы такого типа преминяются в сочетании с диаграммами размещения так же показывают классы и компоненты реализованные ими.
Диграмма пакетов показывает де композицию самой модели на организационные единицы и их зависимости. Временная диаграмма. Диграмма взаимодействий показывающие реальное время жизни различных обьектов или ролей. Диаграмма обзора взаимодействий. Это гибрид диаграммы деятельности диаграмм последовательности. Правило UML
Правила UML предназначены для создания хороших самосогласованных моделей и согласованных с другими моделями.
UML включает правила для следующих обьектов 1. Имён 2.областей действия видимости целостности т.е. как сущности правильно и отностятся друг к другу. Исполнение что будет при запуске динамической модели и модели.но и модели имеющие по умолчанию элементы могут быть скрыты 2. Не полны т.е. некоторые элементы в них пропущены и не согласованны.Описанные выше модели используют процессе разработки до тех пор пока все детали системы не будут ясны разработчику.
Общие механизмы UML.
1.Спецификации
2.дополнение
3.принятые разделения
4.механизмы расширения.
UML за каждой частью её графической натации стоит спецификация. Содержащая текстовое представление определённого блока.
Дополнение большинство элементов uml имеют уникальную и графическую нотацию которая даёт визуальное представление наиболее важным аспектам элементов.
Обозначение класса разработано так что его легко рисовать. В графической нотации класса показывают что имя,атрибуты и дествие (опреации),но спецификация класса может содержать и другие детали такие как видимость атрибутов и операции. Эти детали изображаются в виде графических или текстовых дополнений базовом прямоугольнику изображающих класс.
Принятые разделения при моделировании объектно ориентированных систем представление о предметной области может быть разделена несколькими способами 1. Существуют разделение на классы и обьекты,класс это обстракция а обьект это конкретная.2 существуют разделения интерфейса и реализаций интерфейс определяет соглашение о реализация представляет его конкретное воплощение UML можно моделировать как интерфейсы так и реализации
3.существуют разделения на тип и роль тип дикларирует классу сущности например обьект атрибут или параметр а роль описывает значение сущности внутри контекста такого как класс компонент и кооперация. Механизм расширения включает в себя стереотипы помеченные значения. Стереотип расширяют слова uml позволяя создавать новые блоки. Помеченное значение расширяет свойство стереотипа позволяет включать новую информацию спецификацию стереотипа. Ограничение Расширяют правила UML позволяя модифицировать существующие правила или добавляя новые.
Архитектура.Визуализация специфирования конструирования и документирвоаиня программных систем требует их представления с рапзличных точек зрения. Разные заинтересованные лица аналитики,разработчики системныве интеграторы тестировщики техническиеписатели менеджеры проекта,заказчики имеют различное представление о проекте и каждый видеть систему в различные виды жизненного цикла.Системная архитектура используется для управления все этими разнообразными точками зрения. И управляет итерационным и пошаговым процессом разработки ИС на протяжении всего жизненного цикла.Архитектура это набор сузественных решений отностиельно 1.организации программной системы
2.выбора структурных элементов
5 архитектукрного стиля определяющего организацию системы т.е. статические и динамические элементы и их интерфейсы. Архитектура програмнного обеспечения касается не только его структуры и поведения но также пользовательских своств функциональностей производительности гибкости возможности повторного использования понятности экономических и технологических ограничений и иных оспекты.
Моделирование системной архитектуры.
Это С точски зрения аналитиков и тестирвоащиков. в языке UML статические оспекты представления передаются диаграммами вариантов использования а динамическими аспектами диаграммами взаимодествий состояний и деятельности.
Вид с точки зрения проектирования охватывает классы интерфейсы и кооперации фармирующий словарь проблемы и её решений это представление в основом поддерживает функциональные требования к тсистеме сервис который должна представлять конечный пользователь. Статические аспекты данного представления передаются диаграммами классов и объектов а динамические диаграммами взаимодействий состояний и деятельности.
21.05.2011
|
|
|
