use case
now browsing by tag
Mechanism of operation vs. system model
Most often in the course of analysis we use the term model, less often mechanism. The thing is that the term mechanism appears when we want to explain something, e.g. “the mechanism of generating a discount on an invoice”. The thing is that the term mechanism appears when we want to explain something, e.g. “the mechanism for generating a discount on an invoice”. But here beware! A model (block diagrams, formulae, etc.) is documentation, a copyrighted description. The mechanism is what we understood by reading these documentation (model), because the mechanism is protected know-how. The content of the application to the Patent Office is the model (description), but what we patent is the mechanism invented/developed.
Source: Mechanism of operation vs. system model – Jarosław Żeliński IT-Consulting
Systems analysis and design
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:
A waterfall is not a solution, but agile is not a good remedy for it. A common problem in software design is system size and complexity:
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.
References
Why using extend and include stereotypes in OOAD projects is wrong?
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)
- cooperation (objects cooperate 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…