SlideShare a Scribd company logo
1 of 41
Download to read offline
Компьютерная и программная инженерия
Технология разработки программного обеспечения
Тема лекции
Понятия технологии разработки объектно-ориентированных
информационных систем на основе UML 2
ПЛАН
1. Причины неудачных проектов
2. Отсутствие моделей при разработке ПО
3. Лучшие практики разработки ПО
4. Что такое визуальное моделирование?
5. Основные понятия визуального моделирования
6. Классификация проектов по сложности
7. Основные понятия ООП
Причины неудачных проектов
Недостаточно адекватное управление требованиями
Несогласованность требований, проектных решений и
реализации
Жесткая архитектура ПО
Нарастающая сложность ПО
Неточная и противоречивая коммуникация
Недостаточное тестирование
Субъективное отношение к приоритетам отдельных
артефактов проекта
Игнорирование рисков и отсутствие процедур управления
рисками
Бесконтрольное внесение изменений в артефакты проекта
Недостаточное использование CASE-средств и средств
поддержки отдельных этапов проекта
Отсутствие моделей при разработке ПО
Не позволяет справиться с растущей сложностью
разрабатываемых программных систем
Не позволяет эффективно управлять разработкой в
условиях изменяющихся требований
Создает барьеры непонимания: аналитик не понимает
руководителя проекта, разработчик – аналитика,
тестировщик – разработчика и пр.
Не позволяет обеспечить контроль изменений в процессе
выполнения работ
Не позволяет избежать субъективности в оценке качества
разрабатываемых продуктов
Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и
представленная на некотором языке или в графической
форме
Лучшие практики разработки ПО
Использование визуальных моделей при разработке ПО
Итеративная разработка ПО
Управление требованиями
Управление изменениями и конфигурацией артефактов ПО
Использование компонентных архитектур
Непрерывное тестирование и верификация качества ПО
Использование паттернов проектирования
Использование CASE-средств и RAD-средств
Управление рисками:
Технологическими рисками
Связанными с требованиями
Связанными с квалификацией персонала проекта
Политическими рисками
Что такое визуальное моделирование?
Визуальное моделирование есть моделирование с
использованием некоторой графической нотации
На входе –
Неструктурированная
информация
На выходе –
Модели ПО и
бизнес-процессов
Информация от
потребителей
Прибыль
ФинансыПерсоналЭнергия
Продукция
Реклама
Заказы на сырье
Отходы производства
Демонстрация способности
обеспечения качества
ЗаконодательствоСтандарты, технические условия и т.п.
Технологии
Материалы и
комплектующие
Основные понятия визуального
моделирования
Нотация – система условных обозначений для графического
представления визуальных моделей
Семантика – система правил и соглашений, определяющая
смысл и интерпретацию конструкций некоторого языка
Методология – совокупность принципов моделирования и
подходов к логической организации методов и средств
разработки моделей
CASE (Computer Aided Software Engineering) – методология
разработка программного обеспечения, основанная на
комплексном использовании компьютеров не только для
написания исходного кода, но и для анализа и
моделирования соответствующей предметной области
CASE-средства (CASE-tools) – программное обеспечение,
которое предназначено для разработки визуальных моделей
программных систем и генерации исходного кода или схемы
базы данных на некотором языке
CASE-средства
1-е поколение: генерация схем БД (Oracle Designer 2000,
ERwin)
2-е поколение: генерация программного кода (Borland
Together Designer 2005)
3-е поколение: прямая и обратная кодогенерация (IBM
Rational Rose 2002/2003, Borland Together Developer 2005,
Sparx Enterprise Architect)
4-е поколение: синхронизация программного кода и
моделей (IBM Rational Software Architect 6/7, Borland
Together Architect 2006, Borland Development Studio 2006)
Разработка визуальных моделей сложных систем, в виду
значительного объема решаемых задач, должно опираться на
специальные средства программной поддержки
Oracle Designer
BPwin,
ERwin
Rational Rose
Визуальные модели представляют
архитектуру программных систем
Визуальная модель системы не должна
зависеть от языка ее реализации!
Интерфейсы
пользователя
(Delphi,
Visual Basic,
Java)
Бизнес-логика
(C++, Java)
Базы данных
(SQL)
Визуальные модели – основа
многократного использования кода
Моделирование охватывает существенные (основные,
релевантные) аспекты структуры и поведения системы
ERP Системы
Многократно
используемые
компоненты
(Reusable
Components)
Интернет порталы Базы данных
ООП – основные понятия
Объектно-ориентированное программирование (Object-
Oriented Programming) — совокупность принципов, технологии и
инструментальных средств для создания программных систем, в
основу которых закладывается архитектура взаимодействия
объектов
Абстракция — характеристика сущности, которая отличает ее от
других сущностей
Наследование — принцип, в соответствии с которым знание о
более общей категории разрешается применять для более частной
категории
Инкапсуляция — сокрытие отдельных деталей внутреннего
устройства классов от внешних по отношению к нему объектов или
пользователей
Полиморфизм — свойство элементов модели с одинаковыми
именами иметь различное поведение
ООАП – основные понятия
Объектно-ориентированный анализ и проектирование
(Object-Oriented Analysis/Design) — технология разработки
программных систем, в основу которых положена объектно-
ориентированная методология представления предметной
области в виде объектов, являющихся экземплярами
соответствующих классов
Предметная область (domain) – часть реального мира, которая
имеет существенное значение или непосредственное отношение к
процессу функционирования программы
Диаграмма (diagram) — графическое представление совокупности
элементов модели в форме связного графа, вершинам и ребрам
(дугам) которого приписывается определенная семантика
Нотация канонических диаграмм является основным средством
разработки моделей на языке UML
Классификация проектов по сложности
Высокая техническая сложность
• Встроенные системы реального времени
• Распределенные высоконадежные системы
• Высокопроизводительные системы
Низкая техническая сложность
- Использование макроязыков или 4GL
- Реинжиниринг приложений баз данных
- Разработка учетно-расчетных приложений
Высокая
сложность
управления
- Большой масштаб
- Контрактные заказы
- Много пользователей
- «Проекты»
Низкая
сложность
управления
- Малый масштаб
- Неформальные заказы
- Один пользователь
- “Продукты”
Использование
языка UML не
обязательно
Использование
языка UML
обязательно!
Использование
языка UML
обязательно!
Классификация проектов по типу
приложений
роекты для
пользования внутри
мпании (IIT-проекты)
Моно
пользовательские
приложения
Системы
Видео
наблюдения
Текстовые
редакторы
Системы
Ауторизации
доступа
Корпора-
тивные
порталы
Кастомизация
ERP-системБухгалтерские
Системы
Корпоративные
БД
Типовые
Интернет-
магазины
Системы
контроллинга
Локальные БД
роекты в интересах
ешнего заказчика,
тсорсинг
T-проекты)
роекты разработки
оробочных»
риложений
V-проекты)
Web-
приложения
Встроенные
Системы
мониторинга
ERP & MES
Системы
Графические
редакторы
Разработка
коммерческих
ERP-систем
Внедрение
модулей
ERP-систем
Банковские
Информационные
системы
Использование языка UML в проектах по
отраслевой принадлежности
Банки и инвестиционные
фонды
Связь и телекоммуникации
Нефтегазовая
промышленность
Страховые фонды
Энергетика
Машиностроение
Торговля
Фармацевтическая
промышленность
Оборонная промышленность
Федеральная таможенная
служба
Учебные заведения
Средний проект по разработке ПО:
5-10 человек
10-15 месяцев
10-15 внешних интерфейсов
Незначительная
неопределенность и риски
Графические нотации моделирования,
используемые в России
UML (Unified Modeling Language) – отраслевой стандарт
OMG, поддерживают более 50 CASE-средств, основной
инструмент IBM Rational Rose/ IBM RSA (IBM Rational
Software)
IDEF – семейство нотаций, стандарт МО США,
рекомендован Правительством РФ для применения в
государственных учреждениях, основной инструмент
AllFusion Pricess Modeller (Computer Associations)
ARIS (ARchitecture of Integrated Information Systems) –
методология и нотация для профессионального
моделирования бизнес-процессов, инструмент ARIS
Toolset (IDS Scheer AG)
Пример визуальной модели в нотации IDEF
IDEF не объектно-ориентированная нотация!
Стрелки -
объекты
Взаимосвязь нотации UML, методологии и
инструментальных средств
+ дополнительная интеграция с линейкой продуктов IBM Rational
Нотация – UML 1.х
Методология - RUP Средство – IBM Rational Rose
Best
Practices
Взаимосвязь нотации UML, методологии и
инструментальных средств
Методология
ARIS House
of Business
Engineering
(HOBE)
Средство
ARIS Toolset
Методология
MSF (Microsoft
Solutions
Framework)
Средство
MS Visual
Studio/.NET
Нотация – UML 1.х Нотация – UML 1.х
варианты
Взаимосвязь нотации UML, методологии и
инструментальных средств
Нотация – UML 2.х
Методология
ALM (Application
Lifecycle
Management)
Средство
Borland
Together
Architect 2006
Нотация - UML 2.х
Методология
RUP
Средство
IBM Rational
Software
Architect
варианты
Определение языка UML
Unified Modeling Language — унифицированный язык
моделирования для описания, визуализации и
документирования объектно-ориентированных систем в
процессе их анализа и проектирования
Язык UML предоставляет стандартный способ написания проектной
документации на системы, включая концептуальные аспекты, такие как
бизнес процессы и функции системы, а также конкретные аспекты, такие
как выражения языков программирования, схемы баз данных и повторно
используемые компоненты ПО
Язык UML не является методологией
Язык UML не является процессом
Язык UML не является языком программирования
Язык UML не является формальным языком
UML = нотация + семантика !
Назначение языка UML
Предоставить разработчикам легко воспринимаемый и
выразительный язык визуального моделирования, специально
предназначенный для разработки и документирования моделей
сложных систем различного целевого назначения
Снабдить исходные понятия языка UML возможностью
расширения и специализации для более точного представления
моделей систем в конкретной предметной области
Графическое представление моделей в нотации UML не должно
зависеть от конкретных языков программирования и
инструментальных средств проектирования
Описание языка UML должно включать в себя семантический
базис для понимания общих особенностей ООАП
Способствовать распространению объектных технологий и
поощрять развитие рынка программных инструментальных
средств
Интегрировать в себя новейшие и наилучшие достижения практики
ООАП
Особенности
изображения
графического
элементов диаграмм
языка UML
Особенности изображения диаграмм в
нотации UML
Графические узлы на плоскости, которые изображаются с
помощью геометрических фигур и могут иметь различную
высоту и ширину с целью размещения внутри этих фигур
других конструкций языка UML
Пути, которые представляют собой последовательности из
отрезков линий, соединяющих отдельные графические узлы
Значки или пиктограммы. Значок представляет собой
графическую фигуру фиксированного размера и формы,
которая не может увеличивать свои размеры, чтобы
разместить внутри себя дополнительные символы.
Строки текста. Служат для представления различных видов
информации в некоторой грамматической форме.
Общие рекомендации по изображению
диаграмм в нотации языка UML
Каждая диаграмма должна служить законченным
представлением соответствующего фрагмента
моделируемой предметной области
Все сущности на диаграмме модели должны быть одного
концептуального уровня
Вся информация о сущностях должна быть явно
представлена на диаграммах
Диаграммы не должны содержать противоречивой
информации
Диаграммы не следует перегружать текстовой информацией
Каждая диаграмма должна быть само достаточной для
правильной интерпретации всех ее элементов и понимания
семантики всех используемых графических символов
Противоречивость и адекватность
моделей в нотации UML
Модель, соответствующая правилам нотации или семантики
языка UML называется непротиворечивой (well-formed model)
Модель, нарушающая правила нотации или семантики языка
UML называется противоречивой (ill-formed model)
Здесь могут быть использованы формальные критерии –
соответствие спецификации языка UML!
Модель, достаточно полно и правильно отражающая
предметную область или решаемую проблему называется
адекватной
Модель, не достаточно полно или неправильно отражающая
предметную область или решаемую проблему называется не
адекватной
Здесь могут быть использованы только неформальные
критерии – субъективное мнение экспертов!
Моя модель – это не ваша модель, а ваша модель – не моя…
Классификаторы
– основные
элементы языка
UML
Прямоугольник – основной
символ для графического
изображения
классификатора
Классификация моделей в языке UML
Структурные модели (structured models) – модели,
предназначенные для описания статической структуры
сущностей или элементов некоторой системы, включая их
классы, интерфейсы, атрибуты и отношения.
Модели поведения (behavioral models) – модели,
предназначенные для описания процесса функционирования
элементов системы, включая их методы и взаимодействие
между ними, а также процесс изменения состояний
отдельных элементов и системы в целом.
Канонические диаграммы языка UML 2.х
Д и а г р а м м а
Д и а г р а м м а
с т р у к т у р ы
Д и а г р а м м а
п о в е д е н и я
Д и а г р а м м а
к л а с с о в
Д и а г р а м м а
д е я т е л ь н о с т и
Д и а г р а м м а
в а р и а н т о в
и с п о л ь з о в а н и я
Д и а г р а м м а
к о н е ч н о г о
а в т о м а т а
Д и а г р а м м а
о б ъ е к т о в
Д и а г р а м м а
к о м п о н е н т о в
Д и а г р а м м а
к о м п о з и т н о й
с т р у к т у р ы
Д и а г р а м м а
р а з в е р т ы в а н и я
Д и а г р а м м а
п а к е т о в
Д и а г р а м м а
в з а и м о д е й с т в и я
В р е м е н н а я
д и а г р а м м а
Д и а г р а м м а
к о м м у н и к а ц и и
Д и а г р а м м а
о б з о р а
в з а и м о д е й с т в и я
Д и а г р а м м а
п о с л е д о в а т е л ь н о с т и
Взаимосвязь представлений сложной
системы
Ф и з и ч е с к о е п р е д с т а в л е н и е
к о м п о н е н т о в
Л о г и ч е с к о е п р е д с т а в л е н и е
а р х и т е к т у р ы
с и с т е м ы
Л о г и ч е с к о е
п р е д с т а в л е н и е
п р о ц е с с а
ф у н к ц и о н и р о в а н и я
К о н ц е п т у а л ь н о е
п р е д с т а в л е н и е
п о в е д е н и я с и с т е м ы
М О Д Е Л Ь С Л О Ж Н О Й
С И С Т Е М Ы
С т а т и ч е с к а я
м о д е л ь
с л о ж н о й
с и с т е м ы
Д и н а м и -
ч е с к а я
м о д е л ь
с л о ж н о й
с и с т е м ы
О б щ а я м о д е л ь
с л о ж н о й с и с т е м ы
Д е т а л ь н а я м о д е л ь
с л о ж н о й с и с т е м ы
А р х и т е к т о р с и с т е м ы ,
п р о г р а м м и с т
С и с т е м н ы й а н а л и т и к ,
с и с т е м н ы й и н ж е н е р
К о н е ч н ы й п о л ь з о в а т е л ь ,
с и с т е м н ы й а н а л и т и к
С и с т е м н ы й а н а л и т и к ,
а р х и т е к т о р с и с т е м ы
Рекомендации по изображению
диаграмм в нотации языка UML
Количество диаграмм различных типов для модели
конкретного приложения не является строго
фиксированным
Любая из моделей системы должна содержать только те
элементы, которые определены в соответствующей
версии языка UML
Каждая диаграмма в нотации языка UML 2.х имеет
область содержания для изображения графических узлов
и путей между ними, которые представляют собой
собственно элементы модели в нотации UML 2.х
Фрейм в нотации UML 2.х используется в тех случаях,
когда отдельные элементы диаграммы имеют
графическую границу с другими элементами диаграммы
Изображение диаграмм языка UML 2 в
виде фрейма
< О б л а с т ь с о д е р ж а н и я >
< З а г о л о в о к >
Заголовок диаграммы является строкой текста, записанной
в прямоугольнике с обрезанным углом в верхнем левом углу
фрейма и имеющей следующий синтаксис:
[<тип диаграммы>]<имя>[<параметры>]
Теги заголовков и их сокращения для
диаграмм UML 2.х
activity <act> (для фреймов диаграммы деятельности)
class (для фреймов диаграммы классов)
component <cmp> (для фреймов диаграммы компонентов)
interaction <sd> (для фреймов диаграмм взаимодействия)
package <pkg> (для фреймов диаграммы пакетов)
state machine <stm> (для фреймов диаграммы конечного
автомата)
use case <uc> (для фреймов диаграммы вариантов
использования)
Диаграмма вариантов использования
(use case diagram)
диаграмма, на которой изображаются варианты использования
проектируемой системы, заключенные в границу системы, и
внешние актеры, а также определенные отношения между
актерами и вариантами использования
О т к р ы т ь с ч е т
К л и е н т Б а н к а
К а с с и р
П о п о л н и т ь с ч е т
С н я т ь д е н ь г и с о с ч е т а
< < e x te n d > >
а к т е р ы
в а р и а н т ы и с п о л ь з о в а н и я
з а в и с и м о с т ь с т е к с т о в ы м
с т е р е о т и п о ма с с о ц и а ц и и
О п е р а ц и о н и с т З а к р ы т ь с ч е т
< < e x te n d > >
Назначение диаграммы вариантов
использования
Определить общие границы функциональности
проектируемой системы в контексте моделируемой
предметной области.
Специфицировать требования к функциональному
поведению проектируемой системы в форме вариантов
использования.
Разработать исходную концептуальную модель системы для
ее последующей детализации в форме логических и
физических моделей.
Подготовить исходную документацию для взаимодействия
разработчиков системы с ее заказчиками и пользователями
Основные обозначения на диаграмме
вариантов использования
Вариант использования (use case)
– представляет собой общую спецификацию совокупности
выполняемых системой действий с целью предоставления
некоторого наблюдаемого результата, который имеет
значение для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не
отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в
неопределенной форме
П р о в е р к а с о с т о я н и я
т е к у щ е г о с ч е т а к л и е н т а
< < u s e c a s e > >
Ф о р м и р о в а н и е о т ч е т а п о
в ы п о л н е н н ы м з а к а з а м
Ф о р м и р о в а н и е о т ч е т а п о
в ы п о л н е н н ы м з а к а з а м
Актер (actor)
У д а л е н н ы й
п о л ь з о в а т е л ь
< < a c to r > >
П о с е т и т е л ь
И н т е р н е т - м а г а з и н а
К л и е н т б а н к а
– любая внешняя по отношению к проектируемой системе
сущность, которая взаимодействует с системой и использует
ее функциональные возможности для достижения
определенных целей или решения частных задач
Примеры актеров: кассир, клиент банка, банковский
служащий, президент, продавец магазина, менеджер отдела
продаж, пассажир авиарейса, водитель автомобиля,
администратор гостиницы, сотовый телефон
39
ГЛОССАРИЙ:ГЛОССАРИЙ:
1.1. ИСУТП - служат для автоматизации функций
производственного персонала по контролю и управлению
производственными операциями.
2. CASE-средства - создание моделей, их контроль,
преобразование и предоставление в коллективное
пользование осуществляется с использованием специальных
программных инструментов -
3. САПР- предназначены для автоматизации функций
инженеров-проектировщиков, конструкторов, архитекторов,
дизайнеров при создании новой техники или технологии.
М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н
КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА
ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ
40
Вопросы для самоподготовки:Вопросы для самоподготовки:
1. Диаграмма прецедентов1. Диаграмма прецедентов?
2.2. Основные элементы языка UML?
3. Противоречивость и адекватность моделей
в нотации UML?
М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н
КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА
ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ
41
Литература и ссылки наЛитература и ссылки на
интернет ресурсы:интернет ресурсы:
1.1. Леффингуал, Дин, Ундри, Дон.
Принципы работы с требованиями к
ПО. Унифицированный подход. М.,
2002г.
2.2. У. Боггс, М. Боггс. UML, Rational
Rose. М., ЛОРИ, 2000 г.
Сэм Канер и др. Тестирования
программного обеспечения. Киев, 2000
г.
М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н
КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА
ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ

More Related Content

What's hot

INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
 
Практический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UMLПрактический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UMLNikolai Kireev
 
Software Engineering Knowledge Matrix
Software Engineering Knowledge MatrixSoftware Engineering Knowledge Matrix
Software Engineering Knowledge MatrixOlena Syrota
 
3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложенийKewpaN
 
Практический анализ по RUP
Практический анализ по RUPПрактический анализ по RUP
Практический анализ по RUPSQALab
 
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
 
Леонид Воронцов -- инженерия больших радиоэлектронных систем
Леонид Воронцов -- инженерия больших радиоэлектронных системЛеонид Воронцов -- инженерия больших радиоэлектронных систем
Леонид Воронцов -- инженерия больших радиоэлектронных системAnatoly Levenchuk
 
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
 
Uml for students
Uml for studentsUml for students
Uml for studentshrcustis
 
А.Левенчук -- системноинженерное мышление
А.Левенчук -- системноинженерное мышлениеА.Левенчук -- системноинженерное мышление
А.Левенчук -- системноинженерное мышлениеAnatoly Levenchuk
 
Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)Anton Konstantinov
 
О.Савин -- Modelica в архитектурном моделировании
О.Савин -- Modelica в архитектурном моделированииО.Савин -- Modelica в архитектурном моделировании
О.Савин -- Modelica в архитектурном моделированииAnatoly Levenchuk
 
Алексей Иванов -- курс по стыку системной и программной инженерий
Алексей Иванов -- курс по стыку системной и программной инженерийАлексей Иванов -- курс по стыку системной и программной инженерий
Алексей Иванов -- курс по стыку системной и программной инженерийAnatoly Levenchuk
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийCUSTIS
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодCUSTIS
 
С.Ковалёв -- теория категорий как математическое основание MBSE
С.Ковалёв -- теория категорий как математическое основание MBSEС.Ковалёв -- теория категорий как математическое основание MBSE
С.Ковалёв -- теория категорий как математическое основание MBSEAnatoly Levenchuk
 
Алексей Иванов -- мультиагентные архитектуры в электроэнергетике
Алексей Иванов -- мультиагентные архитектуры в электроэнергетикеАлексей Иванов -- мультиагентные архитектуры в электроэнергетике
Алексей Иванов -- мультиагентные архитектуры в электроэнергетикеAnatoly Levenchuk
 
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
 
Рабочая учебная программа
Рабочая учебная программаРабочая учебная программа
Рабочая учебная программаRauan Ibraikhan
 

What's hot (20)

INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
 
Практический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UMLПрактический анализ и визуальное моделирование на UML
Практический анализ и визуальное моделирование на UML
 
Software Engineering Knowledge Matrix
Software Engineering Knowledge MatrixSoftware Engineering Knowledge Matrix
Software Engineering Knowledge Matrix
 
3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений3 средства автоматизации проектирования корпоративных приложений
3 средства автоматизации проектирования корпоративных приложений
 
Практический анализ по RUP
Практический анализ по RUPПрактический анализ по RUP
Практический анализ по RUP
 
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
 
Леонид Воронцов -- инженерия больших радиоэлектронных систем
Леонид Воронцов -- инженерия больших радиоэлектронных системЛеонид Воронцов -- инженерия больших радиоэлектронных систем
Леонид Воронцов -- инженерия больших радиоэлектронных систем
 
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
 
Uml for students
Uml for studentsUml for students
Uml for students
 
А.Левенчук -- системноинженерное мышление
А.Левенчук -- системноинженерное мышлениеА.Левенчук -- системноинженерное мышление
А.Левенчук -- системноинженерное мышление
 
Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)Задачи системного аналитика (конспект лекций Школы системного анализа)
Задачи системного аналитика (конспект лекций Школы системного анализа)
 
О.Савин -- Modelica в архитектурном моделировании
О.Савин -- Modelica в архитектурном моделированииО.Савин -- Modelica в архитектурном моделировании
О.Савин -- Modelica в архитектурном моделировании
 
Алексей Иванов -- курс по стыку системной и программной инженерий
Алексей Иванов -- курс по стыку системной и программной инженерийАлексей Иванов -- курс по стыку системной и программной инженерий
Алексей Иванов -- курс по стыку системной и программной инженерий
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требований
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в код
 
С.Ковалёв -- теория категорий как математическое основание MBSE
С.Ковалёв -- теория категорий как математическое основание MBSEС.Ковалёв -- теория категорий как математическое основание MBSE
С.Ковалёв -- теория категорий как математическое основание MBSE
 
Алексей Иванов -- мультиагентные архитектуры в электроэнергетике
Алексей Иванов -- мультиагентные архитектуры в электроэнергетикеАлексей Иванов -- мультиагентные архитектуры в электроэнергетике
Алексей Иванов -- мультиагентные архитектуры в электроэнергетике
 
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
 
Рабочая учебная программа
Рабочая учебная программаРабочая учебная программа
Рабочая учебная программа
 

Viewers also liked

IHC chapter 7 4th edition
IHC chapter 7 4th editionIHC chapter 7 4th edition
IHC chapter 7 4th editionKellyGCDET
 
The framework of political development in the
The framework of political development in theThe framework of political development in the
The framework of political development in theAmit Arya
 
tecnologias de informacion
tecnologias de informaciontecnologias de informacion
tecnologias de informacionHilDita RomeRo
 
Getting a job in 2016: using the internet to your advantage.
Getting a job in 2016: using the internet to your advantage.Getting a job in 2016: using the internet to your advantage.
Getting a job in 2016: using the internet to your advantage.Kenny Soto
 
Some of our recent clients
Some of our recent clientsSome of our recent clients
Some of our recent clientsguest2ce714
 
FFS 2016 Case study_ver. 1
FFS 2016 Case study_ver. 1FFS 2016 Case study_ver. 1
FFS 2016 Case study_ver. 1Kenny Soto
 
CLA Outcomes 2015 Conference - Digital Marketing Master Class
CLA Outcomes 2015 Conference - Digital Marketing Master ClassCLA Outcomes 2015 Conference - Digital Marketing Master Class
CLA Outcomes 2015 Conference - Digital Marketing Master ClassMasterworks
 
презентація верхоляк н.с
презентація верхоляк н.спрезентація верхоляк н.с
презентація верхоляк н.сsemyurihor
 
до 160 річниці від дня народження і.франка
до 160 річниці від дня народження і.франкадо 160 річниці від дня народження і.франка
до 160 річниці від дня народження і.франкаsemyurihor
 
Nullification crisis ppt
Nullification crisis pptNullification crisis ppt
Nullification crisis pptGonzo24
 
Hamilton's plan elastic clause
Hamilton's plan elastic clauseHamilton's plan elastic clause
Hamilton's plan elastic clauseGonzo24
 
Mikulas novotny portfolio 2014
Mikulas novotny portfolio 2014Mikulas novotny portfolio 2014
Mikulas novotny portfolio 2014Mikulas Novotny
 
sanjieet sarker (SEO EXPERT)
sanjieet sarker (SEO EXPERT)sanjieet sarker (SEO EXPERT)
sanjieet sarker (SEO EXPERT)sanjieet sarker
 
Mill times video norwalk connection
Mill times video  norwalk connectionMill times video  norwalk connection
Mill times video norwalk connectionpenningtonr
 
Jasensenior final
Jasensenior finalJasensenior final
Jasensenior finaljasenbacon
 
DBQ Causes of the Revolution
DBQ Causes of the RevolutionDBQ Causes of the Revolution
DBQ Causes of the Revolutionpenningtonr
 

Viewers also liked (20)

IHC chapter 7 4th edition
IHC chapter 7 4th editionIHC chapter 7 4th edition
IHC chapter 7 4th edition
 
SJA_WINTER_2015_Newsletter
SJA_WINTER_2015_NewsletterSJA_WINTER_2015_Newsletter
SJA_WINTER_2015_Newsletter
 
The framework of political development in the
The framework of political development in theThe framework of political development in the
The framework of political development in the
 
tecnologias de informacion
tecnologias de informaciontecnologias de informacion
tecnologias de informacion
 
Getting a job in 2016: using the internet to your advantage.
Getting a job in 2016: using the internet to your advantage.Getting a job in 2016: using the internet to your advantage.
Getting a job in 2016: using the internet to your advantage.
 
Some of our recent clients
Some of our recent clientsSome of our recent clients
Some of our recent clients
 
FFS 2016 Case study_ver. 1
FFS 2016 Case study_ver. 1FFS 2016 Case study_ver. 1
FFS 2016 Case study_ver. 1
 
CO2 Incubator SCO6AD
CO2 Incubator SCO6ADCO2 Incubator SCO6AD
CO2 Incubator SCO6AD
 
CLA Outcomes 2015 Conference - Digital Marketing Master Class
CLA Outcomes 2015 Conference - Digital Marketing Master ClassCLA Outcomes 2015 Conference - Digital Marketing Master Class
CLA Outcomes 2015 Conference - Digital Marketing Master Class
 
презентація верхоляк н.с
презентація верхоляк н.спрезентація верхоляк н.с
презентація верхоляк н.с
 
до 160 річниці від дня народження і.франка
до 160 річниці від дня народження і.франкадо 160 річниці від дня народження і.франка
до 160 річниці від дня народження і.франка
 
Nullification crisis ppt
Nullification crisis pptNullification crisis ppt
Nullification crisis ppt
 
Hamilton's plan elastic clause
Hamilton's plan elastic clauseHamilton's plan elastic clause
Hamilton's plan elastic clause
 
คอม
คอมคอม
คอม
 
Mikulas novotny portfolio 2014
Mikulas novotny portfolio 2014Mikulas novotny portfolio 2014
Mikulas novotny portfolio 2014
 
sanjieet sarker (SEO EXPERT)
sanjieet sarker (SEO EXPERT)sanjieet sarker (SEO EXPERT)
sanjieet sarker (SEO EXPERT)
 
Packaging
PackagingPackaging
Packaging
 
Mill times video norwalk connection
Mill times video  norwalk connectionMill times video  norwalk connection
Mill times video norwalk connection
 
Jasensenior final
Jasensenior finalJasensenior final
Jasensenior final
 
DBQ Causes of the Revolution
DBQ Causes of the RevolutionDBQ Causes of the Revolution
DBQ Causes of the Revolution
 

Similar to Понятия технологии разработки объектно-ориентированных информационных систем на основе UML 2

Внедрение CASE-технологий
Внедрение CASE-технологийВнедрение CASE-технологий
Внедрение CASE-технологийОтшельник
 
DBD lection 1. Intro in Database Design. In Russian.
DBD lection 1. Intro in Database Design. In Russian.DBD lection 1. Intro in Database Design. In Russian.
DBD lection 1. Intro in Database Design. In Russian.mikhaelsmirnov
 
Симуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииСимуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииSergey Gorshkov
 
МАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UMLМАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UMLSQALab
 
06 Архитектура информационных систем. Паттерны и фреймворки
06 Архитектура информационных систем. Паттерны и фреймворки06 Архитектура информационных систем. Паттерны и фреймворки
06 Архитектура информационных систем. Паттерны и фреймворкиEdward Galiaskarov
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptdinarium2016
 
рит2007 требования и состав работ бесков доронин
рит2007   требования и состав работ   бесков доронинрит2007   требования и состав работ   бесков доронин
рит2007 требования и состав работ бесков доронинMedia Gorod
 
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
2013-04-06 01 Максим Юнусов. Архитектура в agile-проектеОмские ИТ-субботники
 
Архитектура в Agile проекте
Архитектура в Agile проектеАрхитектура в Agile проекте
Архитектура в Agile проектеLuxoftTraining
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)romachka_pole
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)romachka_pole
 
Бизнес и системный анализ весна 2013 лекция 7
Бизнес и системный анализ весна 2013 лекция 7Бизнес и системный анализ весна 2013 лекция 7
Бизнес и системный анализ весна 2013 лекция 7Technopark
 
2012 andieva e_ju_innovative_management_of_complex_software_projects
2012 andieva e_ju_innovative_management_of_complex_software_projects2012 andieva e_ju_innovative_management_of_complex_software_projects
2012 andieva e_ju_innovative_management_of_complex_software_projectsdataomsk
 
C++ осень 2013 лекция 8
C++ осень 2013 лекция 8C++ осень 2013 лекция 8
C++ осень 2013 лекция 8Technopark
 
Интеграция технико-экономических моделей
Интеграция технико-экономических моделейИнтеграция технико-экономических моделей
Интеграция технико-экономических моделейVictor Agroskin
 
C++ осень 2012 лекция 7
C++ осень 2012 лекция 7C++ осень 2012 лекция 7
C++ осень 2012 лекция 7Technopark
 
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...Alexey Neznanov
 

Similar to Понятия технологии разработки объектно-ориентированных информационных систем на основе UML 2 (20)

Внедрение CASE-технологий
Внедрение CASE-технологийВнедрение CASE-технологий
Внедрение CASE-технологий
 
DBD lection 1. Intro in Database Design. In Russian.
DBD lection 1. Intro in Database Design. In Russian.DBD lection 1. Intro in Database Design. In Russian.
DBD lection 1. Intro in Database Design. In Russian.
 
Симуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииСимуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологии
 
МАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UMLМАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UML
 
UML: Kinds of Diagram
UML:  Kinds of DiagramUML:  Kinds of Diagram
UML: Kinds of Diagram
 
06 Архитектура информационных систем. Паттерны и фреймворки
06 Архитектура информационных систем. Паттерны и фреймворки06 Архитектура информационных систем. Паттерны и фреймворки
06 Архитектура информационных систем. Паттерны и фреймворки
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
 
рит2007 требования и состав работ бесков доронин
рит2007   требования и состав работ   бесков доронинрит2007   требования и состав работ   бесков доронин
рит2007 требования и состав работ бесков доронин
 
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
 
Архитектура в Agile проекте
Архитектура в Agile проектеАрхитектура в Agile проекте
Архитектура в Agile проекте
 
лекция 17
лекция 17лекция 17
лекция 17
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)
 
Бизнес и системный анализ весна 2013 лекция 7
Бизнес и системный анализ весна 2013 лекция 7Бизнес и системный анализ весна 2013 лекция 7
Бизнес и системный анализ весна 2013 лекция 7
 
2012 andieva e_ju_innovative_management_of_complex_software_projects
2012 andieva e_ju_innovative_management_of_complex_software_projects2012 andieva e_ju_innovative_management_of_complex_software_projects
2012 andieva e_ju_innovative_management_of_complex_software_projects
 
C++ осень 2013 лекция 8
C++ осень 2013 лекция 8C++ осень 2013 лекция 8
C++ осень 2013 лекция 8
 
Интеграция технико-экономических моделей
Интеграция технико-экономических моделейИнтеграция технико-экономических моделей
Интеграция технико-экономических моделей
 
C++ осень 2012 лекция 7
C++ осень 2012 лекция 7C++ осень 2012 лекция 7
C++ осень 2012 лекция 7
 
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...
 
лекция № 17
лекция № 17лекция № 17
лекция № 17
 

More from Aimurat Adilbekov

Глобальная сеть
Глобальная  сетьГлобальная  сеть
Глобальная сетьAimurat Adilbekov
 
Однострочные функции
Однострочные функцииОднострочные функции
Однострочные функцииAimurat Adilbekov
 
Ограничение и сортировка выходных данных
Ограничение и сортировка выходных данныхОграничение и сортировка выходных данных
Ограничение и сортировка выходных данныхAimurat Adilbekov
 
Основные команды языка SQL
Основные команды языка SQLОсновные команды языка SQL
Основные команды языка SQLAimurat Adilbekov
 
Возможности сервера Oracle
Возможности сервера OracleВозможности сервера Oracle
Возможности сервера OracleAimurat Adilbekov
 
Oracle базасында қолданушы еңгізу
Oracle базасында қолданушы еңгізуOracle базасында қолданушы еңгізу
Oracle базасында қолданушы еңгізуAimurat Adilbekov
 

More from Aimurat Adilbekov (8)

Глобальная сеть
Глобальная  сетьГлобальная  сеть
Глобальная сеть
 
Однострочные функции
Однострочные функцииОднострочные функции
Однострочные функции
 
Ограничение и сортировка выходных данных
Ограничение и сортировка выходных данныхОграничение и сортировка выходных данных
Ограничение и сортировка выходных данных
 
Основные команды языка SQL
Основные команды языка SQLОсновные команды языка SQL
Основные команды языка SQL
 
Возможности сервера Oracle
Возможности сервера OracleВозможности сервера Oracle
Возможности сервера Oracle
 
Oracle базасында қолданушы еңгізу
Oracle базасында қолданушы еңгізуOracle базасында қолданушы еңгізу
Oracle базасында қолданушы еңгізу
 
Nauriz
NaurizNauriz
Nauriz
 
My home kazakhstan
My home kazakhstanMy home kazakhstan
My home kazakhstan
 

Понятия технологии разработки объектно-ориентированных информационных систем на основе UML 2

  • 1. Компьютерная и программная инженерия Технология разработки программного обеспечения Тема лекции Понятия технологии разработки объектно-ориентированных информационных систем на основе UML 2
  • 2. ПЛАН 1. Причины неудачных проектов 2. Отсутствие моделей при разработке ПО 3. Лучшие практики разработки ПО 4. Что такое визуальное моделирование? 5. Основные понятия визуального моделирования 6. Классификация проектов по сложности 7. Основные понятия ООП
  • 3. Причины неудачных проектов Недостаточно адекватное управление требованиями Несогласованность требований, проектных решений и реализации Жесткая архитектура ПО Нарастающая сложность ПО Неточная и противоречивая коммуникация Недостаточное тестирование Субъективное отношение к приоритетам отдельных артефактов проекта Игнорирование рисков и отсутствие процедур управления рисками Бесконтрольное внесение изменений в артефакты проекта Недостаточное использование CASE-средств и средств поддержки отдельных этапов проекта
  • 4. Отсутствие моделей при разработке ПО Не позволяет справиться с растущей сложностью разрабатываемых программных систем Не позволяет эффективно управлять разработкой в условиях изменяющихся требований Создает барьеры непонимания: аналитик не понимает руководителя проекта, разработчик – аналитика, тестировщик – разработчика и пр. Не позволяет обеспечить контроль изменений в процессе выполнения работ Не позволяет избежать субъективности в оценке качества разрабатываемых продуктов Модель (model) — абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме
  • 5. Лучшие практики разработки ПО Использование визуальных моделей при разработке ПО Итеративная разработка ПО Управление требованиями Управление изменениями и конфигурацией артефактов ПО Использование компонентных архитектур Непрерывное тестирование и верификация качества ПО Использование паттернов проектирования Использование CASE-средств и RAD-средств Управление рисками: Технологическими рисками Связанными с требованиями Связанными с квалификацией персонала проекта Политическими рисками
  • 6. Что такое визуальное моделирование? Визуальное моделирование есть моделирование с использованием некоторой графической нотации На входе – Неструктурированная информация На выходе – Модели ПО и бизнес-процессов Информация от потребителей Прибыль ФинансыПерсоналЭнергия Продукция Реклама Заказы на сырье Отходы производства Демонстрация способности обеспечения качества ЗаконодательствоСтандарты, технические условия и т.п. Технологии Материалы и комплектующие
  • 7. Основные понятия визуального моделирования Нотация – система условных обозначений для графического представления визуальных моделей Семантика – система правил и соглашений, определяющая смысл и интерпретацию конструкций некоторого языка Методология – совокупность принципов моделирования и подходов к логической организации методов и средств разработки моделей CASE (Computer Aided Software Engineering) – методология разработка программного обеспечения, основанная на комплексном использовании компьютеров не только для написания исходного кода, но и для анализа и моделирования соответствующей предметной области CASE-средства (CASE-tools) – программное обеспечение, которое предназначено для разработки визуальных моделей программных систем и генерации исходного кода или схемы базы данных на некотором языке
  • 8. CASE-средства 1-е поколение: генерация схем БД (Oracle Designer 2000, ERwin) 2-е поколение: генерация программного кода (Borland Together Designer 2005) 3-е поколение: прямая и обратная кодогенерация (IBM Rational Rose 2002/2003, Borland Together Developer 2005, Sparx Enterprise Architect) 4-е поколение: синхронизация программного кода и моделей (IBM Rational Software Architect 6/7, Borland Together Architect 2006, Borland Development Studio 2006) Разработка визуальных моделей сложных систем, в виду значительного объема решаемых задач, должно опираться на специальные средства программной поддержки Oracle Designer BPwin, ERwin Rational Rose
  • 9. Визуальные модели представляют архитектуру программных систем Визуальная модель системы не должна зависеть от языка ее реализации! Интерфейсы пользователя (Delphi, Visual Basic, Java) Бизнес-логика (C++, Java) Базы данных (SQL)
  • 10. Визуальные модели – основа многократного использования кода Моделирование охватывает существенные (основные, релевантные) аспекты структуры и поведения системы ERP Системы Многократно используемые компоненты (Reusable Components) Интернет порталы Базы данных
  • 11. ООП – основные понятия Объектно-ориентированное программирование (Object- Oriented Programming) — совокупность принципов, технологии и инструментальных средств для создания программных систем, в основу которых закладывается архитектура взаимодействия объектов Абстракция — характеристика сущности, которая отличает ее от других сущностей Наследование — принцип, в соответствии с которым знание о более общей категории разрешается применять для более частной категории Инкапсуляция — сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей Полиморфизм — свойство элементов модели с одинаковыми именами иметь различное поведение
  • 12. ООАП – основные понятия Объектно-ориентированный анализ и проектирование (Object-Oriented Analysis/Design) — технология разработки программных систем, в основу которых положена объектно- ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов Предметная область (domain) – часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика Нотация канонических диаграмм является основным средством разработки моделей на языке UML
  • 13. Классификация проектов по сложности Высокая техническая сложность • Встроенные системы реального времени • Распределенные высоконадежные системы • Высокопроизводительные системы Низкая техническая сложность - Использование макроязыков или 4GL - Реинжиниринг приложений баз данных - Разработка учетно-расчетных приложений Высокая сложность управления - Большой масштаб - Контрактные заказы - Много пользователей - «Проекты» Низкая сложность управления - Малый масштаб - Неформальные заказы - Один пользователь - “Продукты” Использование языка UML не обязательно Использование языка UML обязательно!
  • 14. Использование языка UML обязательно! Классификация проектов по типу приложений роекты для пользования внутри мпании (IIT-проекты) Моно пользовательские приложения Системы Видео наблюдения Текстовые редакторы Системы Ауторизации доступа Корпора- тивные порталы Кастомизация ERP-системБухгалтерские Системы Корпоративные БД Типовые Интернет- магазины Системы контроллинга Локальные БД роекты в интересах ешнего заказчика, тсорсинг T-проекты) роекты разработки оробочных» риложений V-проекты) Web- приложения Встроенные Системы мониторинга ERP & MES Системы Графические редакторы Разработка коммерческих ERP-систем Внедрение модулей ERP-систем Банковские Информационные системы
  • 15. Использование языка UML в проектах по отраслевой принадлежности Банки и инвестиционные фонды Связь и телекоммуникации Нефтегазовая промышленность Страховые фонды Энергетика Машиностроение Торговля Фармацевтическая промышленность Оборонная промышленность Федеральная таможенная служба Учебные заведения Средний проект по разработке ПО: 5-10 человек 10-15 месяцев 10-15 внешних интерфейсов Незначительная неопределенность и риски
  • 16. Графические нотации моделирования, используемые в России UML (Unified Modeling Language) – отраслевой стандарт OMG, поддерживают более 50 CASE-средств, основной инструмент IBM Rational Rose/ IBM RSA (IBM Rational Software) IDEF – семейство нотаций, стандарт МО США, рекомендован Правительством РФ для применения в государственных учреждениях, основной инструмент AllFusion Pricess Modeller (Computer Associations) ARIS (ARchitecture of Integrated Information Systems) – методология и нотация для профессионального моделирования бизнес-процессов, инструмент ARIS Toolset (IDS Scheer AG)
  • 17. Пример визуальной модели в нотации IDEF IDEF не объектно-ориентированная нотация! Стрелки - объекты
  • 18. Взаимосвязь нотации UML, методологии и инструментальных средств + дополнительная интеграция с линейкой продуктов IBM Rational Нотация – UML 1.х Методология - RUP Средство – IBM Rational Rose Best Practices
  • 19. Взаимосвязь нотации UML, методологии и инструментальных средств Методология ARIS House of Business Engineering (HOBE) Средство ARIS Toolset Методология MSF (Microsoft Solutions Framework) Средство MS Visual Studio/.NET Нотация – UML 1.х Нотация – UML 1.х варианты
  • 20. Взаимосвязь нотации UML, методологии и инструментальных средств Нотация – UML 2.х Методология ALM (Application Lifecycle Management) Средство Borland Together Architect 2006 Нотация - UML 2.х Методология RUP Средство IBM Rational Software Architect варианты
  • 21. Определение языка UML Unified Modeling Language — унифицированный язык моделирования для описания, визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования Язык UML предоставляет стандартный способ написания проектной документации на системы, включая концептуальные аспекты, такие как бизнес процессы и функции системы, а также конкретные аспекты, такие как выражения языков программирования, схемы баз данных и повторно используемые компоненты ПО Язык UML не является методологией Язык UML не является процессом Язык UML не является языком программирования Язык UML не является формальным языком UML = нотация + семантика !
  • 22. Назначение языка UML Предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем различного целевого назначения Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области Графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП Способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств Интегрировать в себя новейшие и наилучшие достижения практики ООАП
  • 24. Особенности изображения диаграмм в нотации UML Графические узлы на плоскости, которые изображаются с помощью геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические узлы Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы, которая не может увеличивать свои размеры, чтобы разместить внутри себя дополнительные символы. Строки текста. Служат для представления различных видов информации в некоторой грамматической форме.
  • 25. Общие рекомендации по изображению диаграмм в нотации языка UML Каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области Все сущности на диаграмме модели должны быть одного концептуального уровня Вся информация о сущностях должна быть явно представлена на диаграммах Диаграммы не должны содержать противоречивой информации Диаграммы не следует перегружать текстовой информацией Каждая диаграмма должна быть само достаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов
  • 26. Противоречивость и адекватность моделей в нотации UML Модель, соответствующая правилам нотации или семантики языка UML называется непротиворечивой (well-formed model) Модель, нарушающая правила нотации или семантики языка UML называется противоречивой (ill-formed model) Здесь могут быть использованы формальные критерии – соответствие спецификации языка UML! Модель, достаточно полно и правильно отражающая предметную область или решаемую проблему называется адекватной Модель, не достаточно полно или неправильно отражающая предметную область или решаемую проблему называется не адекватной Здесь могут быть использованы только неформальные критерии – субъективное мнение экспертов! Моя модель – это не ваша модель, а ваша модель – не моя…
  • 27. Классификаторы – основные элементы языка UML Прямоугольник – основной символ для графического изображения классификатора
  • 28. Классификация моделей в языке UML Структурные модели (structured models) – модели, предназначенные для описания статической структуры сущностей или элементов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения. Модели поведения (behavioral models) – модели, предназначенные для описания процесса функционирования элементов системы, включая их методы и взаимодействие между ними, а также процесс изменения состояний отдельных элементов и системы в целом.
  • 29. Канонические диаграммы языка UML 2.х Д и а г р а м м а Д и а г р а м м а с т р у к т у р ы Д и а г р а м м а п о в е д е н и я Д и а г р а м м а к л а с с о в Д и а г р а м м а д е я т е л ь н о с т и Д и а г р а м м а в а р и а н т о в и с п о л ь з о в а н и я Д и а г р а м м а к о н е ч н о г о а в т о м а т а Д и а г р а м м а о б ъ е к т о в Д и а г р а м м а к о м п о н е н т о в Д и а г р а м м а к о м п о з и т н о й с т р у к т у р ы Д и а г р а м м а р а з в е р т ы в а н и я Д и а г р а м м а п а к е т о в Д и а г р а м м а в з а и м о д е й с т в и я В р е м е н н а я д и а г р а м м а Д и а г р а м м а к о м м у н и к а ц и и Д и а г р а м м а о б з о р а в з а и м о д е й с т в и я Д и а г р а м м а п о с л е д о в а т е л ь н о с т и
  • 30. Взаимосвязь представлений сложной системы Ф и з и ч е с к о е п р е д с т а в л е н и е к о м п о н е н т о в Л о г и ч е с к о е п р е д с т а в л е н и е а р х и т е к т у р ы с и с т е м ы Л о г и ч е с к о е п р е д с т а в л е н и е п р о ц е с с а ф у н к ц и о н и р о в а н и я К о н ц е п т у а л ь н о е п р е д с т а в л е н и е п о в е д е н и я с и с т е м ы М О Д Е Л Ь С Л О Ж Н О Й С И С Т Е М Ы С т а т и ч е с к а я м о д е л ь с л о ж н о й с и с т е м ы Д и н а м и - ч е с к а я м о д е л ь с л о ж н о й с и с т е м ы О б щ а я м о д е л ь с л о ж н о й с и с т е м ы Д е т а л ь н а я м о д е л ь с л о ж н о й с и с т е м ы А р х и т е к т о р с и с т е м ы , п р о г р а м м и с т С и с т е м н ы й а н а л и т и к , с и с т е м н ы й и н ж е н е р К о н е ч н ы й п о л ь з о в а т е л ь , с и с т е м н ы й а н а л и т и к С и с т е м н ы й а н а л и т и к , а р х и т е к т о р с и с т е м ы
  • 31. Рекомендации по изображению диаграмм в нотации языка UML Количество диаграмм различных типов для модели конкретного приложения не является строго фиксированным Любая из моделей системы должна содержать только те элементы, которые определены в соответствующей версии языка UML Каждая диаграмма в нотации языка UML 2.х имеет область содержания для изображения графических узлов и путей между ними, которые представляют собой собственно элементы модели в нотации UML 2.х Фрейм в нотации UML 2.х используется в тех случаях, когда отдельные элементы диаграммы имеют графическую границу с другими элементами диаграммы
  • 32. Изображение диаграмм языка UML 2 в виде фрейма < О б л а с т ь с о д е р ж а н и я > < З а г о л о в о к > Заголовок диаграммы является строкой текста, записанной в прямоугольнике с обрезанным углом в верхнем левом углу фрейма и имеющей следующий синтаксис: [<тип диаграммы>]<имя>[<параметры>]
  • 33. Теги заголовков и их сокращения для диаграмм UML 2.х activity <act> (для фреймов диаграммы деятельности) class (для фреймов диаграммы классов) component <cmp> (для фреймов диаграммы компонентов) interaction <sd> (для фреймов диаграмм взаимодействия) package <pkg> (для фреймов диаграммы пакетов) state machine <stm> (для фреймов диаграммы конечного автомата) use case <uc> (для фреймов диаграммы вариантов использования)
  • 34. Диаграмма вариантов использования (use case diagram) диаграмма, на которой изображаются варианты использования проектируемой системы, заключенные в границу системы, и внешние актеры, а также определенные отношения между актерами и вариантами использования О т к р ы т ь с ч е т К л и е н т Б а н к а К а с с и р П о п о л н и т ь с ч е т С н я т ь д е н ь г и с о с ч е т а < < e x te n d > > а к т е р ы в а р и а н т ы и с п о л ь з о в а н и я з а в и с и м о с т ь с т е к с т о в ы м с т е р е о т и п о ма с с о ц и а ц и и О п е р а ц и о н и с т З а к р ы т ь с ч е т < < e x te n d > >
  • 35. Назначение диаграммы вариантов использования Определить общие границы функциональности проектируемой системы в контексте моделируемой предметной области. Специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
  • 36. Основные обозначения на диаграмме вариантов использования
  • 37. Вариант использования (use case) – представляет собой общую спецификацию совокупности выполняемых системой действий с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?» Имена – отглагольное существительное или глагол в неопределенной форме П р о в е р к а с о с т о я н и я т е к у щ е г о с ч е т а к л и е н т а < < u s e c a s e > > Ф о р м и р о в а н и е о т ч е т а п о в ы п о л н е н н ы м з а к а з а м Ф о р м и р о в а н и е о т ч е т а п о в ы п о л н е н н ы м з а к а з а м
  • 38. Актер (actor) У д а л е н н ы й п о л ь з о в а т е л ь < < a c to r > > П о с е т и т е л ь И н т е р н е т - м а г а з и н а К л и е н т б а н к а – любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач Примеры актеров: кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон
  • 39. 39 ГЛОССАРИЙ:ГЛОССАРИЙ: 1.1. ИСУТП - служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. 2. CASE-средства - создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - 3. САПР- предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ
  • 40. 40 Вопросы для самоподготовки:Вопросы для самоподготовки: 1. Диаграмма прецедентов1. Диаграмма прецедентов? 2.2. Основные элементы языка UML? 3. Противоречивость и адекватность моделей в нотации UML? М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ
  • 41. 41 Литература и ссылки наЛитература и ссылки на интернет ресурсы:интернет ресурсы: 1.1. Леффингуал, Дин, Ундри, Дон. Принципы работы с требованиями к ПО. Унифицированный подход. М., 2002г. 2.2. У. Боггс, М. Боггс. UML, Rational Rose. М., ЛОРИ, 2000 г. Сэм Канер и др. Тестирования программного обеспечения. Киев, 2000 г. М И Н И С Т Е Р С Т В О О Б Р А З О В А Н И Я И Н А У К И Р Е С П У Б Л И К И К А З А Х С Т А Н КАЗАХСКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ имени К.И. САТПАЕВА ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ