Simulation Engines TDA571|DIT030 Architecture and design Tommaso - PowerPoint PPT Presentation

Simulation Engines TDA571|DIT030 Architecture and design Tommaso Piazza 1

Software architecture  Today we will examine the subject of software architecture  Examples  Patterns  How do we split our game engine into systems and subsystems?  How does information flow in our system?  How do we minimize dependencies ?  How do we maximize the cohesion ? IDC | Interaction Design Collegium 2

First, some fun! http://www.youtube.com/watch?v=D_p58o6RJ88 IDC | Interaction Design Collegium 3

Definition: Architecture  There is no universally accepted definition  One attempt from “Software Architecture in Practice” (Len Bass, Paul Clements, Rick Kazman )  Definition: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.  In short: Supports analysis and design while still being simple enough to easily overview. IDC | Interaction Design Collegium 4

Definition: Architecture  Another attempt at a definition from “ANSI/IEEE Std 1471-2000”  Definition: Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.  There are hundreds of definitions, but these two cover the subject fairly well IDC | Interaction Design Collegium 5

Example: Three tier architecture  Common architecture for administrative systems  Dependencies only go to the right ( no mutual dependencies )  Allows for the application server to be used with many different clients (multiple platforms etc) Client Server Database presentation model storage IDC | Interaction Design Collegium 6

Example: 3dwm - Chalmers IDC | Interaction Design Collegium 7

Example: Crystal Space IDC | Interaction Design Collegium 8

Example: Ogre3D IDC | Interaction Design Collegium 9

Architecture and design  Creating the architecture is part of the design process  Architecture is the high-level design on the structure of the components in a software system  Defines components involved in the system  Defines interfaces between components  Defines constraints in the system  Does not define an implementation  Leaves many low-level design decisions unbounded IDC | Interaction Design Collegium 10

How to create an architecture  The easiest way is to already have experience in building software architectures  Trial and error!  Study architecture of existing systems  Few well-established methodologies  Curiously non-engineering  Architecture patterns IDC | Interaction Design Collegium 11

How to create an architecture  A few guidelines (a.k.a what do ask yourself)  Visibility  Which components need to know about which other components?  How do you make them accessible to each other?  Do you solve component visibility with a global registry or by sending around references to those that need it?  Abstraction  Can you classify your components into different abstraction layers?  Can you remove mutual dependencies between components of different abstraction levels? IDC | Interaction Design Collegium 12

How to create an architecture  Responsibility  Does every component have a clear responsibility that does not encroach on another component?  Orthogonality  Avoid redundancy and make sure that responsibilities are orthogonal and adequate  Associations  How will information flow between different components?  What is the cardinality of different components? IDC | Interaction Design Collegium 13

Design patterns  From “Pattern Language” (Christopher Alexander), 1997  Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.  Patterns are abstract descriptions of common problems and effective solutions IDC | Interaction Design Collegium 14

Design patterns  Adopted by software engineering in the 90s  “Design patterns: Elements of Reusable Object- oriented software” (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) 1995  Authors known as “The gang of four”  Still the authorative source on design patterns  Catalogue of 23 separate patterns  Name  Problem description  Detailed solution  Nowadays, hundreds of patterns IDC | Interaction Design Collegium 15

Anatomy of a Design pattern  Name  Obviously important since it will be part of the common terminology for all software engineers  Problem  A problem description which tells us when a particular pattern is applicable ( its context )  Solution  A description of the elements that make up the design of the pattern solution, their relationships , responsibilities , and collaborations  Consequences  The results and tradeoffs of using the pattern IDC | Interaction Design Collegium 16

List of Design Patterns  The initial 23 design patterns IDC | Interaction Design Collegium 17

Pattern: Singleton  Problem  Some classes only have one instance in an entire system. In addition, this instance should be easily accessible.  Solution  Make the class itself responsible for keeping track of its sole instance. The class can ensure that no other instance can be created and it can provide a way to access the instance.  Consequences  Controlled access to sole instance. Overuse can case pollution to the global namespace.  Implementation  In C++ (like in Java), we implement the Singleton design pattern using static member functions and variables. IDC | Interaction Design Collegium 18

Pattern: Singleton class PrinterSpooler { private: static PrinterSpooler *_instance; PrinterSpooler(); // private constructor ... public: static PrinterSpooler *instance() { if (_instance == NULL) _instance = new PrinterSpooler(); return _instance; } ...  }; IDC | Interaction Design Collegium 19

Pattern: Bridge  Problem  Capturing different implementations of an abstraction through simple interface inheritance leads to very rigid couplings between the abstraction interface and the implementations. This can result in major maintenance problems and cross-platform issues.  Example  In this example we have a class hierarchy for 3D meshes and want to extend them with support for terrain meshes. There are different implementations for the OpenGL and DirectX versions. IDC | Interaction Design Collegium 20

Pattern: Bridge  We are inadvertently mixing abstractions with implementations . Adding a new mesh will also require platform-specific versions.  Solution  If we separate the abstraction and implementations and create a single bridge between the two, we can avoid these problems.  Consequences  Decouples interface and implementation, improves extensibility, hides implementation details from clients. IDC | Interaction Design Collegium 21

Patterns in general  There are three categories of patterns  Architectural patterns  High-level patterns specifying the fundamental structure of a software system.  Design patterns  Medium-level patterns to organize subsystem-level functionality in a system.  Idioms  Low-level patterns solving implementation-specific problems (often on a language level). IDC | Interaction Design Collegium 22

Patterns in general  Patterns can also be quantified over phases of the development process  Analysis patterns  High-level solutions to commonly recurring problems on the analysis level of software systems.  Design patterns  Medium-level solutions to commonly recurring problems on the design level of software systems.  For more information, read “Analysis Patterns – Reusable object models” by Martin Fowler IDC | Interaction Design Collegium 23

Architectural patterns  Definition  An architectural pattern expresses a fundamental structural organization schema for software systems . It provides a set of pre-defined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.  Different kinds of architectural patterns  Mud to Structure Layers, Pipes and Filters, Blackboard  Distributed Systems Broker, Pipes and Filters, Microkernel  Interactive Systems Model-View-Controller, Presentation- Abstraction-Control  Adaptable Systems Reflection, Microkernel IDC | Interaction Design Collegium 24

Pattern: Layers (Layered system)  Structure applications that can be decomposed into groups of subtasks at specific levels of abstraction. Services of one layer build from the services of the previous layer .  Example  OSI 7-layer network model, Crystal Space, VMs Drawbacks Benefits Changing behavior Reuse of layers Lower efficiency Support for standardization Unnecessary work Dependencies are kept local Difficulty of establishing correct Exchangeability granularity IDC | Interaction Design Collegium 25

OSI-7 IDC | Interaction Design Collegium 26