Смекни!
smekni.com

Разработка ИС музыкального магазина Аккорд с использованием диаграмм UML (стр. 1 из 4)

Федеральное агентство по образованию

ГОУ ВПО «Санкт-Петербургский государственный

инженерно-экономический университет»

Филиал в г. Чебоксары

Кафедра инженерных наук и информационных технологий

Отчет

по учебной практике по специализации

на тему «Разработка ИС музыкального магазина «Аккорд»

с использованием диаграмм UML»

Выполнил:

студент гр 92-05

Моргалев С. О.

Проверила:

Алякина А. А.

Чебоксары 2010

Содержание

Введение___________________________________________________________4

1. Виды диаграмм UML _____________________________________________6

1.1. Диаграмма прецедентов___________________________________________7

1.2. Диаграмма классов_______________________________________________9

1.3. Диаграмма последовательностей___________________________________10

1.4. Диаграмма состояний____________________________________________11

1.5. Диаграмма деятельности_________________________________________12

2. Разработка ИС музыкального магазина «Аккорд»_____________________14

2.1. Предварительная информация_____________________________________14

2.1.1.Краткая информация о компании_________________________________14

2.2.Видение выполнения проекта______________________________________15

2.3 .Отчет об обследовании___________________________________________15

2.3.1.Анализ существующего уровня автоматизации______________________15

2.3.2.Общие требования к ИС_________________________________________16

2.3.3.Формы документов_____________________________________________17

2.3.4.Описание системы учета_________________________________________18

2.3.5. Список типовых хозяйственных операций и их отражение в провод- ках_______________________________________________________________19

2.3.6.Организационная диаграмма_____________________________________20

2.3.7.Описание состава автоматизируемых бизнес-процессов______________21

2.3.8.Диаграммы прецедентов_________________________________________21

2.3.9.Физическая диаграмма__________________________________________23

2.3.10.Описания бизнес-процессов_____________________________________23

2.3.11.Формирование бизнес-процессов________________________________24

2.3.12. Спецификации настроек ИС____________________________________29

2.3.13. Проектирование реализации операций бизнес-процесса в информационной системе____________________________________________31

Заключение________________________________________________________34

Список использованной литературы___________________________________35

Приложение________________________________________________________36

Введение

В последнее десятилетие в компьютерном мире наметилась тенденция моделирования сложных систем визуальными (наглядными) моделями. Причем в новых методах проектирования сложных компьютерных систем, например ООП и ООАП, наглядные модели очень часто связываются с такими зрительными образами как "взгляды", направленные на сложную систему с различных точек зрения. Набор из нескольких наглядных моделей (модельных взглядов) создает в сознании специалистов интегральный образ сложной компьютерной системы, которую они совместно проектируют. Вместе с тем, наглядные модели служат эффективным средством документирования компьютерных систем и их программных обеспечений, а также языком общения между программистами, системными аналитиками и заказчиками систем.

Наиболее известными визуальными моделями, используемыми для проектирования компьютерных систем и их программных обеспечений, являются диаграммы языка UML и стандарта IDEF0, таблицы и диаграммы стандарта IDEF1X. Эти визуальные модели имеют математическую основу в виде теорий графов, множеств и матриц.

Начальный этап внедрения информационной системы на предприятии – это проработка проекта ИС на этапе консалтинга. На данном этапе необходимо предусмотреть сбор первичных данных, на основе которых будут рассчитываться показатели системы. Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в ИС, должны быть зафиксированы в документах проекта: ролях пользователей, бизнес-процессах, регламентах, требованиях к функционалу.

Также необходимо учесть и юридический аспект. В современных ИС имеются развитые средства реализации финансово-юридических структур предприятий, но для настройки этих средств, структура и документооборот должны быть проанализированы и описаны на этапе формирования проекта. Таким образом, будет достигнута интеграция ИС с финансово-юридическим уровнем системы управления предприятием.

Интеграция информационной системы и системы управления на процедурном уровне обеспечивается на этапе консалтинга путём разработки, оптимизации и согласования бизнес-процессов. Бизнес-процессы разрабатываются в тесной связи с другими документами организационного дизайна компанией. Например, права участников бизнес-процессов должны быть согласованы со структурой управления, а выполняемые функции - с должностными инструкциями. При внедрении ИС необходимо детализировать бизнес-процессы до документов ИС, что позволяет в дальнейшем использовать их, в качестве инструкций операторов, а также для формирования сценариев обучения пользователей.

В результате изучения состава, содержания и процедур формирования основных документов, которые создаются в процессе типового проектирования информационной системы, требуется разработать диаграммы бизнес-процессов на основе их вербального описания, которое получается в результате обследования деятельности гипотетического предприятия «Аккорд».

Целью моей работы является разработка документов, необходимых для настройки типовой ИС, и проектирование реализации операций бизнес-процесса в информационной системе.

1.Виды диаграмм UML

Свою историю унифицированный язык объектно-ориентированного моделирования ведет с конца 80х - начала 90х годов. Собственно создание UML началось в 1994 году. В это время Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали объединять несколько методов объектно-ориентированного моделирования в фирме Rational Software. И уже в 1995 году была представлена спецификация метода, названного Unified Method. Первая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре версия UML 1.1 была принята на вооружение основными компаниями - производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в своих программных продуктах (Paradigm Plus, Microsoft Visual Modeler for Visual Basic, Delphi и др.)

Авторы и разработчики UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы. UML определяет нотацию и метамодель. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.

Универсальный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать любой объектно-ориентированный язык программирования. Он является открытым и позволяет расширять ядро.

Визуальные модели широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации программных информационных систем постоянно приходится решать такие задачи как перераспределение вычислений и данных, обеспечение проведения параллельных вычислений, репликация баз данных, обеспечение безопасности доступа к информационным системам, оптимизация балансировки нагрузки систем, устойчивость к сбоям и многое другое.

Языки и методы моделирования состоят, как правило, из следующих составных частей:

3 Концепции моделирования, их семантика.

4 Визуальное представление элементов моделирования

5 Правила применения элементов моделирования.

Первый компонент - это элементы модели, второй - нотация и третий - принципы использования.

Одной из важных проблем, решаемых при применении визуальных методов моделирования, является все возрастающая сложность систем и проектов. Наступает момент, когда становится невозможным представить всю систему в целом, появляется отрывочность знаний о системе, и происходит потеря управления.

Второе значительное достоинство - упрощение общения заказчика и разработчика. Это связано как с повышенной наглядностью модели, так и с ее гибкостью и динамичностью.

Само собой, решаются вопросы уменьшения времени, затрачиваемого на разработку проекта, его стоимости и повышения качества.

1.1.Диаграмма прецедентов (use case diagram)

На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

• описывает видимую пользователем функцию,

• может представлять различные уровни детализации,

• обеспечивает достижение конкретной цели, важной для пользователя.

Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.

На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: "использование" и "расширение" (рис. 1.1). Связь типа "расширение" применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа "использование" позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.