Software Architecture A Model Driven View

CSCI 5258 Foundations of Software EngineeringSoftware ArchitectureA Model Driven ViewDong ChenEmail: zaknova@gmail.comUniversity of Colorado, Boulder

Outlinen Software Architecturen Case Study: Model Driven Architecturen Application Case Study: ICDEn Reference

Software Architecturen Definitionn Understandingn Nonfunctional requirementsn Modeling of Architecture and Baselinen Software Architectsn Different software architectures

Software Architecture DefinitionComponents and their interactions:n Architectureis defined by the recommended practice as thefundamental organization of a system, embodied in its components, theirrelationships to each other and the environment, and the principlesgoverning its design and evolution.[ANSI/IEEE Std 1471-2000,Recommended Practice for Architectural Description of SoftwareIntensive Systems]Abstraction:n Thesoftware architecture of a program or computing system is thestructure or structures of the system, which comprise software elements,the externally visible properties of those elements, and the relationshipsamong them. [L.Bass, P.Clements, R.Kazman, Software Architecture inPractice (2nd edition), Addison-Wesley 2003]

Definition Cont Scalability, distribution, etc.n [Softwarearchitecture goes] beyond the algorithms and datastructures of the computation; designing and specifying the overallsystem structure emerges as a new kind of problem. Structural issuesinclude gross organization and global control structure; protocols forcommunication, synchronization, and data access; assignment offunctionality to design elements; physical distribution; composition ofdesign elements; scaling and performance; and selection amongdesign alternatives. [D. Garlan, M. Shaw, An Introduction to SoftwareArchitecture, Advances in Software Engineering and KnowledgeEngineering, Volume I, World Scientific, 1993]

Understanding Architecturen Defines structuresa. Partitioning into components, modules, or any units.b. Minimizing dependencies and loosely coupledn Specifies components communicationPattern specifies certain component communicationse.g. client-server pattern: providing mechanisms forconnection establishment, error handling, serversecurity, etc.

Nonfunctional Requirementsn Three nonfunctional requirements:a. Technical constraints: specifying technologies usedb. Business constraints: specifying business design optionsc. Quality attributes: scalability, availability, portability, etc.n Abstraction:a. Informal description of systems (marketecture)b. Hierarchical decompositionn Architecture viewsLogic view: expressing logic using class diagrams or othersProcess view: describing concurrency and communicationsPhysical view: mapping to the application hardwareDevelopment view: internal organization of software components

Modeling of Software Architectureand Baselinen ModelingUsing use case and class diagrams, dynamically usingsequence , collaboration , state charts , and activity diagramsn BaselineRequirements: critical use cases, system level quality objectives,priority relationships among features and qualities.Design: names, attributes, structures, behavior, groupings, andrelationships of various classes and components.Implementation: source component inventory and bill of materialsof all primitive components.Deployment: executable components, risk associated with thesystem components.

Software architectsn n n Multi-skilled in software engineering, technology, managementand communicationsMapping the abstract patterns to specific implementations tomeet the requirementsPhilippe Krutchen: The life of a software architect is a long(and sometimes painful) succession of sub-optimal decisionsmade partly in the dark

Different software architecturesn Middleware Architecturen Object-Oriented Architecturen Resource-Oriented Architecturen Service-Oriented Architecturen Aspect-Oriented Architecturen Model-Driven Architecturen etc.

Case Study: Model Driven Architecturen MDAn Principles of MDAn Model Transformationn MOF in MDAn Why MDA?n MDA and SOA

Model Driven Architecture (MDA)n Abstraction levels in software industry in past fivedecades: From machine code to assembly language to 3GLsto object-oriented languages and now to modelsn MDA: “an approach to IT system specification thatseparates the specification of functionality from thespecification of the implementation” defined by OMGn Simply a bunch of models and their transformationsn State of art Tools using MDA: AndroMDA, ArcStyler,Eclipse Modeling Framework

Principles of MDAFour principles underlie the OMG's view of MDA:n Modelsexpressed in a well-defined notation are a cornerstone tounderstanding systems for enterprise-scale solutions.n The building of systems can be organized around a set of modelsby imposing a series of transformations between models,organized into an architectural framework of layers andtransformations.n A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformationamong models, and is the basis for automation through tools.n Acceptance and broad adoption of this model-based approachrequires industry standards to provide openness to consumers,and foster competition among vendors.

Model transformationsn Computation Independent Model (CIM)Hide computational and implementation details.System’s environment and requirement are emphasizedn Platform Independent Model (PIM)Transformed from CIM without platform specific information.Possess computational information for the application.n Platform Specific Model (PSM)Transformed from PIM with details on specific platformimplementation

ExampleThe following figure represents a Customer and Account. At this level ofabstraction, the model describes important characteristics of the domainin terms of classes and their attributes, but does not describe anyplatform-specific choices about which technologies will be used torepresent them. It also illustrates three specific mappings, ortransformations, defined to create the PSMs, together with the standardsused to express these mappings.

MOF in MDAn Meta-Object Facility (MOF): Create MODF representation ofexisting modeling languages (such as UML) to make themMDA compatible

Why MDA?n Portability:a. High level models are decoupled with low level platformdetails.b. Do not need remodeling but transformation whenunderlying platform changesc. MOF makes models movable across differentenvironmentsn Reusabilitye.g. PIM is mapped to different PSMs for different platforms

Why MDA? Cont n Interoperabilitya. horizontal model mapping and interactions.e.g. two sets of CIM/PIM/PSM for the two systems.First explicit vertical transformation between high levelmodels CIMs and PSMs can be analyzed. The cross platformmodel mappings can be mapped to detailed communicationprotocols or shared databases.b. mapping a single high level model into multiple modelsacross two or more platforms.

MDA and SOAn Difficulty of architecture designSystematically check whether the architecture models fulfill therequirementsn SOA (service-oriented architecture)a. Different perspective:SOA: communication protocols and architecture style perspectiveMDA: general semantic modeling perspectiveb. SOA uses communication protocols, pervasive services, etc, tobridge different systems.MDA applies transformation rules for the high level down to lowlevel

Application Case Study: ICDEn ICDE Systemn Extended Capacity Planningn Reasons for choosing MDAn MDA based Test Generatorn Test Results and Practical Merits

Case Study on ICDEn ICDE (Information Capture and Dissemination Environment) Initialobjective: capture user actions use cases and offer intelligent helpsa. Data Collection: capture users’ activitiesb. Data Store: database storage of event informationc. Data analysis: analysis for the data store

ICDE capacity planningPromote the initial ICDE with network capabilityn Differentdomains and user installations use ICDE in differentwaysn Different installations of ICDE on different hardware platformsn Different application servers have different performancecharacteristicsn Capacityplanning is to execute a test load on specific platforms:then how to make test as efficient and painless as possible?n Ans: applying MDA

Reasons for choosing MDAn MDA provides a generic application model and modelmapping mechanism. MDA possesses portability,interoperability and reusabilityn The reuse of code generation cartridges which aremaintained by a large active user community with highquality is attractiven Use MDA code generation cartridge could achieve sitespecific features

ICDE MDA-based Test Generatorn A UML profile and a tool are designed to automaticallyICDE test suites from that specific description.n The tool is built on top of an open source frameworkAndroMDAn Input: UML based diagrams. Output: benchmarkapplication including monitoring, profiling, and reportingutilities.

Test Model

Test Model Cont n ICDEAPIService : load entry point for test modeln ICDEAPIClient: consisting of a number of testcasesn TrxnData: test data used for calling ICDE APIsrandomly generated to simulates the real workload of the ICDE installationn TranDEck: configure transaction mix for a test

Test resultsn Following figure shows the response time distribution fortwo different application servers. The workload is 150concurrent users.

Practical meritsn A large amount of time is save through automaticallyrepetitive and error prone code generation for differentplatformsn MDA raises the abstraction levels that make it easy toextend and be representedn Seamless integration with other architectures not faraway: e.g. high level semantic system integration andsystems models transformation into low level SOAfacilities

Referencesn Essential Software Architecture 2nd, Ian Gorton, 2011 chapter 1-4and chapter 14n Software Architecture in Practice 2nd Len Bass Paul Clements,Rick Kazman, 2003n L. Zhu, J. Liu, I. Gorton, N. B. Bui. Customized BenchmarkGeneration Using MDA. in Proceedings of the 5th Working IEEE /IFIP Conference on Software Architecture, Pittsburgh, November2005n Object Management Group: http://www.omg.orgn seminar on model-based software architecture.pptn An introduction to Model Driven ional/library/3100.html

For further readingn OMG, MDA Guide Version 1.0.1http://www.omg.org/mda/n Thomas Stahl, Markus Voelter, Model-Driven SoftwareDevelopment: Technology, Engineering, Management,Wiley 2006

Summaryn n n In this lecture, definitions of software architecture are firstintroduced in three different perspectives. Then modelingprocedures and nonfunctional requirements compared withtraditional functional designs are given out.A specific software architecture: Model driven architecture,is analyzed in terms of its model transformation nature,unifying modeling language and three great features(portability, Interoperability, Reusability). Also a briefcomparison between SOA and MDA shows a higher levelabstraction feature of MDA.Finally, capacity planning and test on ICDE system isshown as a case study to take MDA into practice formeeting different platform requirements and environmentconstraints.

Have a Nice Spring Break

A Model Driven View Dong Chen Email: zaknova@gmail.com . Acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, . Model driven architecture, is analyzed in terms of its model transformation nature,