Many time we heard about agile in software development. Many times authors wrote that agile provide us to fast and cheapest solutions. It is true but not all the times. Chaos Report (see Standish Group) show us, that is not true all the times.
Few comments…
Generally small projects are not a (big) problem..
Waterfall vs. agile: first one method consume many more time than second one, but we have no time to «big analysis». Second one mean «working too fast», and effect is more prototyping mean cost increasing… many time mean: cancel project before finish caused by budget:
How to improve quality and chance to succeed software project? We need really good person to business analysis role and only one. More than one person in a first stage, mean more problem with merging parts to one completed and unambiguous requirements document :
Disciplined agile, what is it? Using models in agile, why and for what? Modern system analysis and design is not a waterfall and not a agile style? It is science method used for software engineering . Discover the MDA and patterns as a wand for your success in software projects. See the system as a architecture .
More about general systems and SysML notation coming soon ?
Try my courses for improve your skills and your teammates, hire me as a gifted person in your project.
Larman, C. (2005). Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development (3rd ed). Prentice Hall PTR, c2005.
Sharbaf, M., Zamani, B., & Sunyé, G. (2020, October). A Formalism for Specifying Model Merging Conflicts. System Analysis and Modelling (SAM) Conference. https://doi.org/10.1145/3419804.3421447
Graics, B., Molnár, V., Vörös, A., Majzik, I., & Varró, D. (2020). Mixed-semantics composition of statecharts for the component-based design of reactive systems. Software and Systems Modeling. https://doi.org/10.1007/s10270-020–00806‑5
Gharajedaghi, J. (2011). Systems thinking: managing chaos and complexity: a platform for designing business architecture (Third Edition). Elsevier Inc.
Evans, E. (2014). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley.
Fowler, M. (1997). Analysis patterns: reusable object models. Addison Wesley.
Ambler, S. W. (2002). Agile modeling. John Wiley & Sons.
García Díaz, V., Cueva Lovelle, J. M., Pelayo García-Bustelo, B. C., & Sanjuán Martínez, O. (Eds.). (2014). Advances and applications in model-driven engineering. Information Science Reference.
Many analyst and UML practitioner use Use Cases as a “process model”. It is really bad idea. As we say “we use OOAD methods”, it means we use object paradigm. The fundatin of OOAD is hermetization, but «include» and «extend» dependencys break this rule.
A lots of time we see diagrams like this:
Uses Case models with include and extend stereotypes
A few citation (UML specification) :
A UseCase is a kind of Behaviored Classifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (UML, 18.1.3.1 Use Cases and Actors)
Important sentence: without reference to its internal structure (see what encapsulation means below).
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. (UML, 18.1.3.2 Extends)
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. (UML, 18.1.3.3 Includes).
Object oriented paradigm based on main concepts:
object (part of system)
encapsulation (objects hides their implementation)
polymorphism (one operation could be implemented by more then one methods)
coöperation (objects coöperate to achieve the particular goal)
In OOAD «include» and «extend» breaks encapsulation (we can’t use use diagram to modeling any internal application or component structure/architecture). , .
Need more arguments and explanation? Try my courses…
Vogel, S., & Arnold, P. (2020). Towards a more complete object-orientation in graph-based design languages. SN Applied Sciences, 2(7), 1235. https://doi.org/10.1007/s42452-020‑2959‑x