Прочитал. Есть некоторые замечания:
1. Стоит более широко рассматривать средства моделирования. Как то мало.
2. Объектно - ориентированный подход сам по себе не повышает надежность.
3. UML никак не связан с ООП.
4. Использование всех диаграмм UML не делает модель лучше, а зачастую ухудшает ее и делает менее прозрачной.
5. Начальным этапом является на мой взгляд не сбор требований, а определение концепции продукта.
6. Не совсем понимаю почему диаграмма классов строится с чьей то точки зрения. Для каждого stakeholder'a свои классы ? Не разу такого не видел.
7. Как Activity diagramm и Use case diagramm соотносятся со структурным моделированием выделенным у вас в первый этап ?
8. Архитектура и платформа тоже определяется на этапе моделирования, а не после кодирования.
1. Выбирал на мой взгляд самые известные и практичные средства визуального моделирования. В том числе те, которыми пользовался на дипломном проектировании.
2. Согласен, что ООП сам по себе не повышает надёжность. Но применение ООП повышает надёжность разрабатываемого ПО - данная информация взята из опубликованного источника, а не просто выдумана.
3. Почему UML не связан с ООП? UML ведь является базовым языком описания/проектирования объектно-ориентированных систем?
4. Согласен с Вашим утверждением по поводу использования всех диаграмм UML.
5. Согласен с вами: определении концепции - сбор требований -> формализация требований -> разработка ТЗ и т.д.
6. Про диаграмму классов. Я имел в виду не чью-то точку зрения на систему (например, человека), а аспект системы вообще, то есть если вся система представляет собой совокупность классов (их огромное множество - для большой системы), то имеет смысл не отображать все классы и отношения между ними, а использовать только необходимые классы и ассоциации между ними для понимания только той определённой части системы.
7. Согласен, что Activity diagramm моделируют поведение системы. Я лишь хотел указать, что вариант использования может быть раскрыт этой диаграммой.
8. Солидарен с Вами.
Просмотр сообщений
