Frameworks

"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 (or worse, theirs), provide graphics, send email, control hardware, etc, when you can assemble best-of-breed frameworks for each area, and tie them together with an industry standard infrastructure?"

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 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.JoinLine(theLine), and so forth. Complex problem domains are modeled in their own language, making development, validation and maintenance much easier and less expensive.

Canned Solutions

"Ripping out the other guy's idiosyncrasies and adding yours is often far more work (and therefore more expensive) than building from scratch... Typically, we find that an implementation layer written on our frameworks is 20% the size of a full custom solution."

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:

1. The other guy's solution probably does not match your solution. It is designed and built with his unique constraints, and to solve his particular problem. It is also likely that it was designed as a one-off application, rather than a reusable foundation. Ripping out the other guy's idiosyncrasies and adding yours is often far more work (and therefore more expensive) than building from scratch. And with a framework as a starting point, you don't have to build from scratch.
2. It is a maintenance nightmare for you and for the company who would build it for you. As soon as they copy the other guy's solution and start modifying it for you, there is a branch in the code's genealogy, and two (or more) copies that must be kept up to date. Bugs found in one branch (the other guy's code) often don't get fixed in yours, or worse yet, the "fix" gets implemented in your code, causing unforeseen breakage due to your own code.
3. In some cases, your solution could be used as a "template" for someone else's project. Suppose that "other guy" is a competitor?

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, etc, etc?