Contact Us Robert
Cloutier, Ph.D.
|
Music demonstrates repeating patterns to make it easier to learn the tune. Three childhood songs have the same tune – Twinkle, Twinkle Little Star; Baa, Baa Black Sheep and The Alphabet Song. All are from the same Mozart tune. Mathematics is full of patterns – methods to solve similar problems: sum of squares, quadratic equations, and standard integration of common functions. The use of cul-de-sacs by civil engineers/architects in a housing development is another example of a commonly found pattern. Other examples of patterns are geometric forms – a large circle and a small circle differ only by the radius. Patterns have been around in the engineering community for quite some time. Most notably, parts of the software community have been using them for years. Books published in the mid 90’s – Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four, and the POSA series have helped drive that usage. Simply put, a pattern is a model or facsimile of an actual thing or action, which provides some degree of representation (an abstraction) to enable the recreation of that entity over and over again. The existence of patterns is almost universal. One can find patterns everywhere and the human mind seems to perceive patterns without conscious thought. So, what is are systems engineering/system architecture patterns? My current definition is they are models which capture a high-level structure, appropriate to the design of the major components of a system. They express the relation between the context, a problem, and a solution, and document the system attributes and usage guidance. They are time-proven in solving problems similar in nature to the problem under consideration. There are many reasons to use patterns in systems engineering, however the ones I cite most are: 1. Knowledge Management – Enables reuse of good concepts and implementations, and to preserve them for future projects 2. Control Complexity – Architectural patterns may help control the complexity of an architecture by standardizing it on a well known and practiced pattern 3. Common Understanding – Describing parts of the architecture in the context of known and understood architecture patterns results in a common understanding of the architecture 4. Mitigate Risks – Using and applying known architecture patterns in architecture design introduce less risk than a new architecture design I have also found some reasons for not using patterns which include:
– This reuse prevents engineers from having to reinvent, or rediscover the same concept – And, it provides a common vocabulary for the design concepts that a project can share |
