Основные этапы разработки информационной системы: анализ, проектирование и реализация. Шаблоны для документов описания требований. Системные сервисы и ограничения, их спецификация. Постройка UML-диаграмм к каждой группе моделей проектируемой системы.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Государственное образовательное учреждение высшего профессионального образования УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Методические указания к лабораторным работам по дисциплине «Архитектура информационных систем» для студентов, обучающихся по специальности 230110165 «Вычислительные машины, комплексы, системы и сети»Заключение ....................................................................................................................................................Разработка информационной системы состоит из трех этапов: анализа, проектирования и реализации, в результате итеративного выполнения которых происходит пошаговое «наращивание» системы. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Цель данных методических указаний - изучение на практике применения в проектировании подходов и методов, позволяющих получать успешные архитектуры информационных систем. Приведенные задания на лабораторные работы могут использоваться в рамках дисциплины «Архитектура информационных систем» для студентов, обучающихся по специальности 23010165 «Вычислительные машины, системы, комплексы и сети».Документ, описывающий требования, является осязаемым результатом этапа установления требований. Большинство организаций вырабатывает документ описания требований в соответствии с заранее определенным шаблоном. Ядро документа описания требований состоит из формулировок (изложения) требований. Формулировки сути сервисов могут быть затем разделены на требования к функциям (function requirements) и требования к данным (data requirements). Не говоря уже о самих требованиях, документ описания требований должен обращаться к проектным вопросам.Хотя документ описания требований может быть как угодно далек от технических решений, все же важно обсудить идеи, касающиеся Документ описания требований должен предоставлять перечень существующих программных пакетов и компонент, которые должны быть в дальнейшем изучены в качестве вариантов возможных решений. Наконец, неплохо в заключение раздела предварительных замечаний к проекту документа описания требований привести обзор оставшейся части документа. Требования к данным можно моделировать с помощью диаграммы бизнес-классов. Требования к интерфейсу определяют, как система взаимодействует с пользователями.Приложения содержат остальную, полезную для понимания требований, информацию. Глоссарий определяет термины, сокращения и аббревиатуры, используемые в документе описания требований. Одна из особенностей, которую часто упускают из виду при составлении документа описания требований, состоит в том, что в проблемной области, определяемой документом, можно довольно неплохо разобраться с помощью изучения документов и форм, используемых в процессах делопроизводства.ИС «Домашняя бухгалтерия» должна быть проста в использовании и не требовать от пользователя знаний бухгалтерского учета. 13 возникает необходимость создания специализированной программы ведения домашней бухгалтерии. ИС «Домашняя Бухгалтерия» получает данные о доходах и расходах от внешней сущности «Домохозяин». В своей работе сущность «Домашняя Бухгалтерия» использует информацию о ценах на товары и тарифах и курсах валют, получаемую от внешних сущностей «База тарифов и цен на товары» и «База курса валют». Результаты своей работы ИС «Домашняя Бухгалтерия» может отображать как внешней сущности «Домохозяин», так и генерировать в виде отчетов формата MS Excel для внешней сущности «MS Excel».Веб-магазин по продаже часов Веб-магазин по продаже фотоаппаратов Веб-магазин по продаже компьютерных комплектующих 15.Веб-магазин по продаже одежды Составить спецификацию установленных в лабораторной работе №1 требований для проектируемой ИС.В типичной ситуации сначала определяются классы-сущности, т. е. классы, которые определяют проблемную область и характеризуются постоянным присутствием в базе данных системы. Классы, которые обслуживают системные события (управляющие классы) и классы, которые представляют GUI-интерфейс (классы представления или пограничные классы), не устанавливаются до тех пор, пока не станут известны поведенческие характеристики системы. Хорошим приемом является установление идентифицирующих атрибутов (ключей), чтобы помочь нам судить о мощности (cardinality) класса (т. е. ожидаемом количестве объектов данного класса в базе данных). Мы пока не уверены, должен ли и каким образом класс Course быть сужен до классов COMPULSORYCOURSE (Обязательный курс) и ELECTIVECOURSE (Выборочный курс).
