With Sage®, you can use our simulation framework, then select your database access framework, graphics framework, browsers, charting engines and other application infrastructure from a dizzying array of windows application components. You decide the software you will use to create your application, not your simulation vendor.
A framework is a reusable design expressed as a set of behaviors and collaborations, and defined in terms that are typically more generic than the eventual problem to be solved. A framework embodies a solution to a general problem. that problem may be all or part of an intended solution - a user interface framework assists the developer in creating the gui of an application, and a data access framework assists the user in creating the data access layer. many applications are built that use both.
Just as a framework such as Winforms or WPF eliminates the vast majority of Windows gui work, allowing the developer to focus on high level functionality, our simulation frameworks can insulate you from the low level grunge of simulation application development. If your application is a manufacturing simulation, your developers will program in terms of workstations, raw materials and products, rather than queues, locks and servers. However, if the framework is open, as ours is, you can also drill down to the lower levels to augment and modify behaviors where appropriate.
Modern applications are built from modern frameworks for solving each of the key pieces of the application. These modern frameworks address gui development, data access, messaging, and a wide range of other technical details. To build a modern simulation application, use existing frameworks that were designed and broadly used to solve these other problems, and simply add a framework to the picture that is designed to solve the simulation problem.
Frameworks are object oriented, and usually involve low level classes that are generics such as queues and servers, with higher layers' objects aggregating and inheriting from these primitives, specializing their behaviors and providing a more intuitive interface so that they look and behave like a real-world participant in your simulation domain. A queue becomes a tellerline, a server becomes a teller. Queue.AddToken becomes Customer.Join(theLine), and so forth. Complex problem domains are modeled in their own language, making development, validation and maintenance much easier and less expensive.
Many simulation development houses claim to have "generic" solutions that they can "tailor" to your needs. These are almost always simulations that were developed for someone else, that will be copied and modified to suit your needs. There are several problems with this approach:
Frameworks put common code in a foundation class library with clearly defined, standard behavior. unique behavioral aspects of your domain are coded into your implementation layer, and idiosyncrasies of the other guy's, are coded into his implementation layer. Bugs in the foundation layer pertain to standard behaviors, and are fixed once. Bugs in the other guy's implementation layer are fixed there, and cannot cross-pollute into yours. Typically, we find that an implementation layer written on our frameworks is 20% the size of a full custom solution.
Modern software development has been based on saving time and effort, and
boosting quality by aggregating frameworks for many years. Why build your
simulation on someone else's monolithic environment, with bridges and adapters
to access your database, provide graphics, send email, control hardware, etc,