The Power of Frameworks
Want to define your own design patterns without resorting to someone's "pattern wizard"? Want to give meaning to your stereotypes? Want to impose architectural standards on your models, designs, and code? Read here to learn how frameworks allow you to do all this, and more.
Behavior-driven vs. Data-driven approach
This has been a long-standing controversy in the modeling community. Catalysis offers an approach which, essentially, reduces it to a non-issue.
Capturing rules with Invariants
The Catalysis facilities of actions, effects, and attributes, combined with static and dynamic invariants, provide a powerful foundation to accurately capture most forms of business rules.
This innocuous little things actual plays a surprisingly key role, and not just as a piece of documentation. What it does is take your model (remember, when you draw a Customer and Order, you could be talking about the real world, an abstract model of a software application, or tables in a database), and defines its relationship to the things it represents.
Diagrams versus Models
Is a model a diagram? Is a diagram a model? The answer is no to both. Read here later for more.
Key Abstraction Tools
We all use abstraction to deal with complexity. Catalysis offers a small and effective set of tools for doing this abstraction, and they (too) apply in a fractal way to all levels of development. Here we will summarize those abstraction tools.
The Utility of Convenience Attributes and Effects
Psst! Models and specs getting to complicated? Finding it hard to understand what's going on? Here are some tricks that can greatly simplify your descriptions.
One of the advantages of models and specs is that you don't have to be constrained by programming language limitations. Implementation languages force you to say in one place in your code (e.g. a method body) how you implement everything required of that method (its functional, exception, performance, requirements). (Although, see Aspect-Oriented Programming, or Subject-Oriented Programming for pioneering thinking even at the implementation level).
When working with models and specs, you should be able to separate these different issues; and in one place of your document, you can define the basic functional specs; and "add on" the exception or performance requirements elsewhere. However, if you do this, there must be clear rules about how the different fragments of specs of models "compose". Catalysis provides such rules.