Languages Models Factories

100 %
0 %
Information about Languages Models Factories
Entertainment

Published on November 14, 2007

Author: Haggrid

Source: authorstream.com

Slide1:  Markus Völter voelter@acm.org www.voelter.de Languages, Models, Factories How it all fits together About me:  Markus Völter voelter@acm.org www.voelter.de Independent Consultant Based out of Heidenheim, Germany Focus on Model-Driven Software Development Software Architecture Middleware About me MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Common Concepts and Terminology - Modelling:  Common Concepts and Terminology - Modelling Common Concepts and Terminology - Platform:  Common Concepts and Terminology - Platform Common Concepts and Terminology - Transformations:  Common Concepts and Terminology - Transformations Common Concepts and Terminology – Software System Fam.:  Common Concepts and Terminology – Software System Fam. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) MDA Concept Adoption:  MDA Concept Adoption MDA Concepts:  MDA Concepts Software system families and product lines have no direct equivalent in MDA terminology and the terms are not directly relevant in this context. MDA uses MOF as the meta-metamodel. MDA expects DSLs to be based on MOF. In practice, MDA recommends the use of UML profiles as a concrete syntax for a DSL. Thus the DSL is predisposed at its core to use UML. Static semantics are specified by OCL expressions. Various perspectives on formal models are defined: A domain model can be specific (PSM) or non-specific (PIM) relative to a platform. The MDA recommends multi-step transformations between models, but doesn’t prohibit a direct PIM-to-code transformation. MDA Concepts II:  MDA Concepts II To be able to describe even model-to-platform transformation as a model-to-model transformation, the platform must also be described via a metamodel. The PDMs – Platform Description Models – are used. At this point, a language (almost) exists: Query/Views/Transformations (QVT) is in proposed final draft stage. Its goal is mainly the description of transformations between source and target metamodel for model-to-model transformations. The action semantics of the UML are an essential building block for executable UML (see later) because they allow the specification of algorhithms in an abstract form. When a (tool-specific, since non-standardized) concrete syntax is used, you can use action semantics to program like in any other programming language, although the static model’s information is be integrated. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Executable UML Concepts:  Executable UML Concepts Executable UML is not a formal standard, but a collective term for various endeavors that all pursue the goal of establishing UML as a fully-fledged programming language. Thus, UML must be rid of all redundancy and ambiguities, resulting in executability of UML diagrams. The smaller the metamodel of the modeling language is (here UML), the easier it is to implement a compiler or an interpreter for it. Another necessary ingredient of executable UML is an action language. Action language is necessary to define complete implementations of software systems. It is important to understand that – contrary to the MDSD approach – executable UML is not a domain-specific profile of the UML. The idea is rather to define a universal, UML-based programming language. Further information about executable UML can be found in Steve Mellor's book [Mel02] or in the documentation section of Kennedy Carter's iUML [IUML]. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Action Languages:  Action Languages Today you cannot model a complete software system via UML (or other MOF-based languages) – “business logic” is complicated. To address this problem, the OMG defines the action semantics with UML 2.0 (which can be used with all MOF-based languages). Action semantics allows the modeling of procedural behavior. The OMG does not define a concrete syntax, only the abstract syntax. The action semantics are comprised of the following elements: Variables (instance handles), assigning, reading – also for sets of variables (Sets, Bags, Sequences) The usual arithmetic and logical operations Typical features of sequential programming languages like Switch, If, For, statements, block concept Instance creation, destruction of instances Class extents that can be prompted with SQL-like queries Navigation across associations Creation and deletion of links (instantiation of associations) Generation of signals including parameters Definition of functions with input and output parameters as well as ways of calling them Timers Action Languages II:  Action Languages II Action semantics do not contain structural constructs such as classes, attributes and relationships. These are already defined in the structural part of the model. Action semantics merely define behavioral building blocks Action semantics segments are always associated with elements of the regular UML model, for example with operations of classes or onEntry actions in state machines. Action Languages Example I:  Action Languages Example I Example for the use of action languages. As concrete syntax for the action semantics, we use the syntax that is also used in the tool iUML by Kennedy Carter. First, we implement a “main program” that works with instances of classes from the diagram and create an instance of the class Vehicle, then we assign a value to the make and the model myVWBus = create Vehicle with plate = “HDH-GS 142” myVWBus.make = “Volkswagen” myVWBus.model = “Transporter T4 TDI” Action Languages Example II:  Action Languages Example II The with clause assigns values to the identifying attributes (“id”) as early as during object creation (cf. constructor). Then we can define an instance of Person that will subsequently on become the driver. We can now call the operation drive() to let the driver drive the vehicle. john = create Person with name = “John Doe” [actualDriver] = drive[aVehicle] on john What is still missing, of course, is the implementation of the operation drive(). The least it must do is to instantiate the association R1 (that is, to create a link between the two concerned objects). link this R1 aVehicle Action Languages Example III:  Action Languages Example III Now you can ask the car who is currently driving it. This corresponds with the implementation of the drive() operation of the class Vehicle. Let us assume we wish to find all persons in the system: theCurrentDriver = this.R1.“driver“ {allPersons} = find-all Person The braces state that allPersons is a set of objects instead of just one. One can also limit such a search. For example, all vehicles of the brand Audi can be looked for. {audis} = find Vehicle where make = "Audi“ MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Executable UML Tool Example: Kennedy Carter iUML:  Executable UML Tool Example: Kennedy Carter iUML Picture taken from KennedyCarter‘s iUML tool documentation © Kennedy Carter MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) AC-MDSD Concept Adoption:  AC-MDSD Concept Adoption AC-MDSD Concepts:  AC-MDSD Concepts The domain is architecturally motivated e.g. architecture for business software or component infrastructure for embedded systems. The products to be created are usually complete applications. From the black box view, usually only singe-step model-to-platform transformations exists However, these can be internally (white box) structured, serving modularization purposes for sequential execution of several transformations. The DSL’s metamodel therefore contains architectural concepts that are as abstract as possible i.e. “component” and not “EJB 3 stateless session bean” The DSL is also called design language. Often, UML profiles are used here, sometimes combined with additional textual specifications. The formal models are sometimes also called designs. AC-MDSD Concepts II:  AC-MDSD Concepts II Typically, the model-to-platform transformation is a template that shows great similarity to the generated code and thus can easily be extracted from a reference implementation The transformation does not aim at creating the complete application, but merely an implementation framework containing the architectural infrastructure code (skeleton). The non-generated, implementation code (“business logic”) is manually implemented in the target language (code snippet). For this purpose, the generated skeleton may contain protected regions for supplementing the application logic that will persist after iterative regeneration. Alternatively, generated and non-generated code is integrated using suitable design patterns. Recipe Framework help integrating manually written code:  Recipe Framework help integrating manually written code Cascading „Business“-Stuff onto AC-MDSD Infrastructures:  Cascading „Business“-Stuff onto AC-MDSD Infrastructures MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) GP Domain Model:  GP Domain Model GP Concept Adoption:  GP Concept Adoption GP Concepts:  GP Concepts The idea of the software system family plays a central role in GP. It is (more or less) assumed that a domain is modeled via feature models and single products are generated on this basis. Thus, feature models often serve as a basis for DSL or the metamodel. A feature model instance that is, the specification of the product, assumes the role of the formal model in the context of MDSD. Traditionally, the idea of (UML) modeling is less pronounced. Instead an – often textual – DSL is defined based on domain analysis. The domain is also called problem space, whereas the platform and the components that constitute the product are labeled solution space. The configuration knowledge is stored in a generator, that typically performs a one-step model-to-code transformation. The static semantics (recognition of invalid product configurations) are likewise realized with configuration knowledge. The tools used in GP are often feature modeling tools. Depending on the DSL, other tools can be used as well. For example, in the context of C++ template meta programming, the C++ IDE would be the modeling tool of choice. GP Concepts II:  GP Concepts II Typically, the platform consists of maximally combinable and minimally redundant components GP is thus often routine configuration as opposed to creative construction MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Software Factories Overview:  Software Factories Overview The term Software Factories has been coined by Microsoft and is described extensively in Jack Greenfield and Keith Shorts book of the same name [GS04]. Microsoft is working on making sure the approach is not considered to be a Microsoft-only concept. In a nutshell, a Software Factory is a an IDE specifically configured for the efficient development of a certain kind of application (applications in a certain domain). The configured IDE makes the use of domain specific models and DSLs, frameworks and patterns as simple as possible Since Software Factories looks at the complete product-line engineering process, it is much wider in scope than „just“ Model-Driven Software Development DSLs, modelling and tansformations are an important ingredient. Software Factories Schema:  Software Factories Schema The Factory Schema defines the viewpoints that are useful and necessary for building a system of the respective kind. For example in an enterprise system, there might be the following viewpoints: presentation incl. form layout and workflow component structure and business data model persistence mapping deployment viewpoint For each of these viewpoints, the schema identifies core artefacts as well as the most efficient aay of producing them: manual programming using patterns in specific ways using frameworks that are extended or configured designing and subsequently using DSLs (and then generating stuff). The schema also identifies the commonalities as well as the differences among the applications in the domain addressed by the schema. Software Factories Template:  Software Factories Template In order to be able to configure our development environment for the respective kind of applications we must make the schema tool usable. This configuration for the IDE is called a Software Factory Template. It can be loaded into your IDE (usually Visual Studio) in order to configure the IDE for developing the respective kind of application. For example it provides the necessary frameworks or libraries contributes certain kinds of projects whose structure is suitable for the factory delivers build scripts and extends the IDE with new DSL editors and transformations Also, we need to have the necessary tools to build some of these artifacts in the first place. Building frameworks requires nothing specific from an IDE, this is different for DSLs. Tools for defining metamodels, concrete syntax and transformations are required. The Role of DSLs and the Relationship to MDSD:  The Role of DSLs and the Relationship to MDSD Software Factories use the concepts defined at the beginning of the talk without major changes or renamings. Domain-Specific Languages are used to build models. Those languages are often - but not necessarily - graphical. Visual Studio provides tooling to define the metamodels as well as the concrete syntax and editors (remember the tooling focus). SoFa do not use any of the OMG standards for their infrastructure. DSLs are not UML based. Metamodels are not based on the MOF, rather they use the MDF, the metadata framework for that purpose. QVT does not play a role. Application developer’s perspective: models are first class artifacts in development projects editors and transformations integrate seamlessly with the IDE. Infrastructure developer’s perspective: metamodels, editor definitions and transformations are first class artifacts the tools to build them are seamlessly integrated into the IDE. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) A „page flow editor“ build with MS DSL Tools:  A „page flow editor“ build with MS DSL Tools Taken from http://galilee.microsoft.fr/(ncqibzbvkp2ezr45aevbcqjk)/a17fdcfb90f14a7592045f1c0fc5e97f/sessions/JA2005_BezivinFabro.ppt © Bezivin, Fabro Defining a Metamodel with MDF with the DSL tools:  Defining a Metamodel with MDF with the DSL tools Taken from http://galilee.microsoft.fr/(ncqibzbvkp2ezr45aevbcqjk)/a17fdcfb90f14a7592045f1c0fc5e97f/sessions/JA2005_BezivinFabro.ppt © Bezivin, Fabro MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Model-Integrated Computing Concepts:  Model-Integrated Computing Concepts Started in the technical computing area, more specifically, in Distributed Realtime and Embedded Systems (DRE Systems). Typical Domains are industrial monitoring and control systems defense and avionics. Technically MIC is conceptually quite compatible with MDSD they use real DSLs and not UML profiles They use several models to describe the various aspects of a system. Models are at the center of the complete lifecycle of systems, i.e. not just during their development: Analysis Verification integration and maintenance are also addressed. Model-Integrated Computing Concepts II:  Model-Integrated Computing Concepts II Since MIC is traditionally used for dependable systems, the verification of models is a primary concern, for example using simulation techniques. Model-to-Model transformations are important. Not so much because of the MDA-like multi-step transformation approach, but rather to be able to transform (certain aspects of) models into differnet representations so that various analysis, verification and simulation tools can use them. As exemplified by GME, building meta tools - i.e. tools that can be used to efficiently build modelling tools - is a cornerstone. Note that MIC is now also supported by the OMG. Currently, this comprises the MIC PSIG and the yearly - industry-oriented- workshop. The OMG’s MIC initiative is not related to MDA. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) GME Main Window:  GME Main Window Taken from GME Documentation © ISIS, Vanderbilt University GME: Metamodelling:  GME: Metamodelling Taken from http://www.isis.vanderbilt.edu/Projects/gme/Tutorials/Lesson1.html#1.2 © ISIS, Vanderbilt University GME: Modelling based on the previously defined MM:  GME: Modelling based on the previously defined MM Taken from http://www.isis.vanderbilt.edu/Projects/gme/Tutorials/Lesson1.html#1.2 © ISIS, Vanderbilt University GME: OCL Constraint Validation:  GME: OCL Constraint Validation Taken from GME Documentation © ISIS, Vanderbilt University MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Language-Oriented Programming:  Language-Oriented Programming The term Language-Oriented Programming has recently been used mainly by Sergey Dmitriev and his company JetBrains. They are working on a new product called the MPS, the meta programming system [MPS]. This tool let’s you define your own languages integrated in the MPS IDE. In the context of MPS the languages are typically textual. Domain-specific metamodels play the central part - the metamodel is the first step in defining the languages. Defining a language also entails defining the respective editor, compiler (transformations) and debugging support. Other “Language Workbench Tools” (term coined by Martin Fowler) GME (see MIC section) MetaEdit+ (see DSM section) Xactiums XMF Mosaic. Language-Oriented Programming II:  Language-Oriented Programming II Historically, the Intentional Programming (IP) research project (lead by Charles Simonyi) had the same goals. Charles Simonyi as well as a couple of other people have meanwhile founded a company called Intentional Software. The community expects that they will build a comparable tool. MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) MS IP: Typing Support for Matrices:  MS IP: Typing Support for Matrices Picture Courtesy Krzysztof Czarnecki MS IP: Typing Support for Mathematics in General:  MS IP: Typing Support for Mathematics in General Picture Courtesy Krzysztof Czarnecki MS IP: Editing Support for Logic:  MS IP: Editing Support for Logic Picture Courtesy Krzysztof Czarnecki MS IP: Structured Code:  MS IP: Structured Code Picture Courtesy Krzysztof Czarnecki Internals: Actice Source:  Internals: Actice Source Picture Courtesy Krzysztof Czarnecki int x; x = 1; while ( x < 5 ) ++x; MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) MPS: Example DSL and its editor:  MPS: Example DSL and its editor Picture taken from http://www.martinfowler.com/articles/mpsAgree.html © Martin Fowler MPS: Metamodel Definition:  MPS: Metamodel Definition Picture taken from http://www.martinfowler.com/articles/mpsAgree.html © Martin Fowler MPS: Editor Definition:  MPS: Editor Definition Picture taken from http://www.martinfowler.com/articles/mpsAgree.html © Martin Fowler MPS: Generator Definition:  MPS: Generator Definition Picture taken from http://www.martinfowler.com/articles/mpsAgree.html © Martin Fowler MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) Domain-Specific Modelling:  Domain-Specific Modelling Domain-Specific Modeling (or DSM) is primarily known as the idea of creating models for a domain in a DSL suitable for that domain. In this respect, DSM is mostly about the modeling aspect of MDSD. However, generation techniques have been in use for some time in the DSM community. It can be observed that the discrepancies between DSM and MDSD are beginning to dwindle. One of the best-known players in the DSM space are Metacase Consulting from Finland with their tool MetaEdit+. MetaEdit+:  MetaEdit+ MetaEdit+ and the Method Workbench are an integrated (commercial) toolset by Metacase. MWB allows you to define you own modelling language based on the GOPRR metametamodel. This includes defining the modelling concepts... ...defining the rules for integrating the concepts Pictures taken from MetaEdit+ Documentation © MetaCase Consulting MetaEdit+ II:  MetaEdit+ II ...defining the visual re- presentations for the concepts (as well as state-dependent visual representations) ...and define code genera- tors to „implement“ the DS-models. Pictures taken from MetaEdit+ Documentation © MetaCase Consulting MetaEdit+ III:  MetaEdit+ III The MetaEdit+ tool allows „domain modelers“ to create models based on the previously defined DSL. Several different editors are available for defining your models. Pictures taken from MetaEdit+ Documentation © MetaCase Consulting MDA Concepts:  MDA Concepts Common Concepts: MDSD Model-Driven Architecture (MDA) Executable UML (xUML) Action Semantics iUML Example Architecture-Centric MDSD (AC-MDSD) Generative Programming (GP) Software Factories (SoFa) MS DSL Tools Example Model-Integrated Computing (MIC) GME Example Language-Oriented Programming (LOP) IP Example MPS Example Domain-Specific Modelling (DSM) THE END. Some advertisement :  Some advertisement  For those, who speak (or rather, read) german: Völter, Stahl: Modellgetriebene Softwareentwicklung Technik, Engineering, Management dPunkt, 2005 www.mdsd-buch.de An very much updated translation is under way: Model-Driven Software Development, Wiley, Q2 2006 www.mdsd-book.org

Add a comment

Related presentations

Related pages

Concepts for Model›Driven Design and Evolution of Domain ...

Concepts for Model›Driven Design and Evolution of Domain›Specic Languages Uwe Zdun Department of Information Systems Vienna University of Economics
Read more

Model Factories and Villages

Model Factories and Villages Ideal Conditions of Labour and Housing by Budgett Meakin. ... Language: English: Category: Audits and Surveys: Pages: 478 ...
Read more

Software Factories: Assembling Applications with Patterns ...

Software Factories Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
Read more

Software Factories book

Software Factories significantly increase the level of automation in application ... a general purpose modeling language designed for models used as ...
Read more

Factory (object-oriented programming) - Wikipedia, the ...

In object-oriented programming (OOP), a factory is an object for creating other objects – formally a factory is a function or method that returns objects ...
Read more

Factory method pattern - Wikipedia, the free encyclopedia

The factory method pattern relies on inheritance, ... (a Design Description Language) Consider static factory methods by Joshua Bloch; Factory Method and ...
Read more

A Software Factory Approach To HL7 Version 3 Solutions

A Software Factory Approach To HL7 ... specific language (DSL), because it models concepts ... implement the Software Factory pattern, building languages, ...
Read more

Crazy Factory | online piercing shop

Please set your personal preferences for language, currency ... Cool designs for all the popular mobile phone models from Samsung ... CRAZY FACTORY – THE ...
Read more

Factory Design Software | Factory Design Suite | Autodesk

Factory Design Suite is 3D factory design software that helps you design and visualize more efficient factory and facility layouts before equipment is ...
Read more