TERM PAPER OF SYSTEM ANALYSIS AND DESIGN ON

ANALYSIS OF A PROJECT USING MODEL DRIVEN DEVELOPMENT ANALYSIS

SUBMITTED TO:

SUBMITTED BY:

MS. NEHA TIWARI C.S.E \ I.T DEPT. LPU

KANIKA MONGA B.TECH (HONS) MBA CSE SEC A R146A04

ACKNOWLEDGMENT

First of all I am thereby very thankful to my teacher MS.NEHA TIWARI for giving me the term paper on the topic ANALYSIS O A PRO!ECT USING MODEL DRI"EN ANALYSIS . It has helped me a lot to get knowledge about how a project is developed. The TERM ! ER helped me a lot to enhance my skills" my

practical knowledge and make me confident that I can do anything. #o again I am thanking my teacher for giving me this opportunity... I also want to thanks my friends especially $%&TI" my team mate in this project to help me search out the material and MR.'I(( )!TE# for developing MI*R&#&FT &FFI*E +,,- and most importantly my dad who bought me the laptop..... )&." who continues to look after me despite my flaws.....

CONTENTS
1. MODEL DRI"EN DE"ELOPMENT. AN O"ER"IEW. #. WHY MODEL DRI"EN DE"ELOPMENT$ %. A PROCESS OR MODEL DRI"EN DE"ELOPMENT. A. BOUNDARIES. B. STRUCTURES. C. DOMAIN MODEL. 4. ANALYSIS O IN"ENTORY TRACKING SYSTEM BY USING MDD. A. ARCHITECTURE.
B. MODEL DRI"EN ITS DE"BELOPMENT.

WAREHOUSE MODELLING. CHOOSING THE MODELLING TOOL. MODEL INTERPRETER.

C. ONGOING WORK. D. CONCLUDING REMARKS. &. CONCLUSION. 6. RE ERENCES.

MODEL'DRI"EN DE"ELOPMENT:

&ver the last few years" as tools and technologies have evolved" another option has evolved to define a software/solution0s architecture1 Model/.riven .evelopment 2M..3. M.. gives architects the ability to define and communicate a solution while creating artifacts that become part of the overall solution. It is a system development strategy that emphasizes the drawing of system models to help visualize and analyze problems, define business requirements, and design information systems.

O"ER"IEW:
&ften" the inception of a new software solution is an overwhelming task. Typically" after a number of approvals from management" some high/level re4uirements are handed over to a development organi5ation to define and create the solution. !t this point in the product life cycle" companies often take one of two approaches1

Take time to draw pictures defining the solution" without creating any artifacts that will become part of the actual solution.

'egin coding on the functional re4uirements" without formally defining how the solution will be structured.

Each approach contains its own risks and benefits" and e6perienced software professionals can argue intelligently for either approach in good company. Taking too much time to analy5e the solution initially can result in lost profits and possibly the cancellation of the effort. There is also a risk that issues with implementing the defined architecture might re4uire that the solution take a different path" rendering the e6ercise a waste of time. There are also many risks involved with giving too little thought to the overall structure of the solution7in particular" how the product can be e6tended and maintained in the future. !ny solution of a reasonable si5e or comple6ity usually re4uires some initial analysis and design on how the solution should be implemented. 8ithout some upfront guidelines" a solution might re4uire e6tensive rework in subse4uent releases. !lso" a technically comple6 solution might result in an unmanageable code base" which will be hard to maintain as the project evolves.

WHY MDD$:

!n effective architect plays multiple roles on any given project. 'eyond defining a solution for a business problem" an architect0s responsibilities often include communicating the solution to multiple stakeholders1 business sponsors" potential end users" and development organi5ations. !rchitects usually create a number of diagrams to communicate the solution to each of the different audiences. 9sing a tool for design and development that supports the generation of code and facilitates :;,/degree synchroni5ation between the diagrams and code gives stakeholders a true representation of the solution. #ynchroni5ing the diagrams and code manually is often time/consuming and fruitless" as software solutions rarely sit idle long enough to capture the correct images. <aving a design tool that creates code from models can be used to define a contract between the product sponsors and the development team. ! model for software development that is becoming common in many organi5ations is having an internal architect define and design a product" and then outsource the development of the product. <aving a clear understanding of the solution0s design handed off to the development team eliminates much ambiguity as to the e6pectations of the development team. *ombining M.. with a test/driven development methodology by defining unit tests for the software up front gives the acceptance criteria to the development organi5ation prior to the commencement of development" creating even less doubt of what is e6pected. <aving the ability to generate pictures from the M.. environment allows the history of the product to be documented accurately with a minimal amount of effort. 8ithout any design documentation" there is no historic trail of the solution0s evolution. If this history only e6ists in the heads of the current development team" there is less likelihood of historic accuracy" and lessons learned might be forgotten.

A PROCESS OR MODEL'DRI"EN DE"ELOPMENT:

!long with a number of nonfunctional re4uirements like security and event management" there are three main architectural aspects that must be defined for the functional re4uirements" prior to development. These are the solutions1 =. 'oundaries +. #tructure :. .omain model.

DE INING BOUNDARIES:

rior to creating any artifacts 2code or otherwise3" the architect must understand the intent of the solution" and where that solution fits in the conte6t of the business problem that it is solving. In particular" the architect should have an idea of which objects act as inputs to a solution" and which objects are re4uired for the solution to fulfill the business re4uirements. The architect should also understand the basic flow of the business transactions" as if the transactions were being performed manually. 9nderstanding the boundaries of the solution gives the architect a target to which they can design. It also allows the architect to communicate the scope of the solution" and ensure that the architect envisions the solution as the stakeholders have defined it. It is a critical first step to defining the structure of the solution.

STRUCTURING THE SOLUTION:

<ow the solution will be structured is the first decision7and one of the most critical decisions7that an architect must make. 8ithout defining a solution0s structure and the policies that enforce that structure" a solution can grow unwieldy. The solution can fulfill the business re4uirements without the necessary consistency that will allow for easy e6tension or maintenance.

&ne of the first artifacts to be created is a diagram of the conceptual architecture. The conceptual architecture defines how the functional re4uirements will be fulfilled within the structure that is defined for the solution. The definition of the conceptual architecture should include1 how the solution is e6posed to e6ternal processes" how users will interact with the solution" how transactions will be maintained throughout the solution" how the solution0s domain will be accessed and manipulated" and how the solution will handle events internally and e6ternally. 'y defining the structure of a solution early in the process" the architect can begin to communicate the solution with varying stakeholders. 'usiness sponsors often use a conceptual diagram to begin creating the marketing for a solution. .evelopment managers tend to be appreciative of any early communications to forecast their staffing re4uirements. In most instances" the development team will want to do a steel thread of a functional re4uirement through the solution. ! steel thread is a technical proof of concept that touches all of the technologies in a solution. The steel thread allows the development team to ferret out any technical issues prior to committing to a development schedule. Many times" development can begin on parts of the solution after the structure is defined. 9sing a modeling tool that allows the architect to define the conceptual architecture while building a working thread through the solution can minimi5e any ambiguity as to the intent of the architecture" and can e6pose any technical issues that might arise.

DESIGNING THE DOMAIN MODEL:

The conceptual architecture is a critical first artifact in the architecture of a solution" but it is only a first step. Taking the conceptual architecture to the point where the solution can be developed with an e6tendible and maintainable result re4uires the solution0s domain to be defined in detail. The domain model contains objects that are essential to the fulfillment of the solution0s functional re4uirements. The model also defines relationships between objects. This part of the solution definition also re4uires the architect to consider how to control access to the domain objects" and how to coordinate transactions across the domain. The result of the domain modeling can include any or all of the following1 frameworks" object models" and service definitions.

MODEL-DRIVEN SYSTEM DEVELOPMENT STRATEGY

THE USER COMMUNITY
PROBLEM OPPURTUN ITY DIRECTIVE S

SYSTEM ANALYSIS O IN"ENTORY TRACKING SYSTEM BY OWNERS AND

BUSINES S SOLUTIO NS

USING MODEL'DRI"EN DE"ELOPMENT:

An Inventory Tracking System ITS! is a control and monitoring IMPROVEM system that tracks the flow of ENT OF goods and manages assets of PR warehouses. IT# is commonly used in warehouse management OB%ECTIVE
WORK STATEM

USERS

SYSTEM ENT

!CURRENT" SYSTEM OPERATION # MAINTENAN CE

EM systems. The primary goal of an IT# is to provide convenientS and reliable mechanisms to TEM of inventory manage the movement and flow in a timely manner. !n IT# should enable PROBLEM STA

OBL

2.

ANALYSIS operators to configure warehouse storage organi5ation criteria" maintain the set of goods

ENT

known to the system" and track the inventory using )9I/based operator monitoring consoles.
SCO The primary goal of the joint #iemens>I#I# IT# project is to apply the &bject Management REQUIREMENT DEFINITION PE DEFI )roup 2&M)3?s Model .riven !rchitecture 2M.!3 "together with component middleware to OPERATIO NITI NAL ONS configure various aspects of a warehouse SYSTEM # POST document is organi5ed as follows1 AUDIT REVIEW Section 1 introduces the architecture of the REQUIR of this management system. The remainder EMENT STATEM ENTS

1. SCOPE

3.

ANALYSIS

IT# system" including the high level design of

4. LOGIC

major components in the system @ 8. INSTALLATION

AND DELIEVERY

Section 2 discusses the advantages of choosing Microsoft Aisio as our modeling tool" which DESIGN Y OF
SYSTEM is used to develop our warehouse modeling paradigm@
FUNCTIO SYSTEM to # facilitate TRAININ G finally and MATERIA LS N Section 3 discusses our ongoing work on using &M) M.! in conjunction with middleware LOGIC

REPOSITOR

KNOWLEDG E

the component synthesis@ Section 4 provides concluding remarks . .

CONSTRUCTIO N AND TESTING
BP R

$. DECISION ANALYSIS

SYSTEM MODEL & SPECIFICATI ONS

1.ARCHITECTURE: 6. PHYSICAL
DESIGN PROTOT YPEE

DESIGN AND INTEGRATIO N

SYSTE M PROPO SAL

The IT# architecture" illustrated in Figure =" is designed in accordance with the *&R'! *omponent Model 2**M3. Each *&R'! component representing different entities of the warehouse" such as cranes" forklifts and shelves" provides one or more ports that can be connected together with ports e6ported by other components. These ports include event sources and sinks" facets" receptacles" and attributes. The IT# implementation uses the *omponent Integrated !*E &R' 2*I!&3" which is a 4uality of service 2Bo#3/enabled **M middleware implementation developed at 8ashington 9niversity" #t. (ouis and the Institute for #oftware Integrated #ystems 2I#I#3 at Aanderbilt 9niversity" Cashville. ()*+, 1 illustrates the key **M components in the IT# architecture: ()*+, 1: ITS A+-.(/,-/*+,

#. MODEL DRI"EN ITS DE"ELOPMENT

The IT# project is developing and applying a set of modeling tools to automate the following three different aspects of IT# development1 =. 8arehouse modeling that simplifies the warehouse configuration aspect of the IT# system according to the custom e4uipment available in certain warehouses" including roller conveyor and various types of cranes +. Modeling of **M container and &R' configuration aspects that are responsible for delivering the desired 4uality of service 2Bo#3 properties to the IT# system :. Modeling and synthesi5ing the assembly and deployment aspects of the components that implement the IT# functionality.

2.1 Warehouse Modelling

There are two main generic aspects in a warehouse model1 =. Transportation facility network" which includes information" such as the physical location and reachable areas" and properties" such as the to6icity of an item. +. !ppropriate available storage places " including their locations and properties. The two aspects are blended together to give the model developer a convenient overview of the warehouse setup" which is similar to the architectural blue print of the warehouse.Mapping from the architectural blue print to the warehouse model should be intuitive to the domain e6pert" as well as to the model developer" so he>she can reuse the warehouse knowledge efficiently and conveniently. 2.2 Choosing the Modeling Tool !fter evaluating customer re4uirements" we have selected MicrosoftD AisioD as our domain/specific modeling tool. Aisio is a commercially supported graphic drawing tool with meta modeling capability" as well as the following desirable features1 2.2.1 Full Range of Technical Diagramming Capa ilities. In the drawing panel of Aisio" numerous drawing related features are provided. For e6ample" features" such as grid" docking point and object manipulation ability 2resi5e" rotation" connection routing3 are valuable for warehouse modeling. These intuitive features are important for domain e6perts who work on large/scale commercial IT# deployments. 2.2.2 !ntegrated Model !nterpreter "ith #m edded De ugging #n$ironment.

9nlike traditional tools that focus on a discrete segment of information" Microsoft Aisio offers an integrated toolset for applications" development" and data modeling. Aisio is shipped with an embedded Aisual 'asicD editor and debugging environment" which simplifies interpreter writing. *EE>*&M objects could be plugged in as well if desired. 2.2.3 #%tensi ilit& Microsoft Aisio provides support for database modeling" which includes complete database design" database schema" and .ata .efinition (anguage 2..(3 script generation from conceptual and physical models . For e6ample" in the warehouse configuration domain" we could connect the physical model with the associated database. Moreover" Aisio is shipped with many domain/specific paradigms 2referred to as drawing types in Aisio3. 'esides the major building blocks needed by the warehouse system" Aisio also provides many other modeling paradigms" such as 9M( diagrams. The meta modeling ability also makes Aisio capable of e6tending the e6isting modeling paradigm to better suit the domain. Figure + represents the Microsoft Aisio screenshot where domain /specific model elements are available from the master panel 2left side3 and the right side contains the drawing representing the warehouse fragment comprising a moving belt" two cranes" storage rack and a forklift. ()*+, #: M(-+0102/ "(1(0 ,34567,

2.3 Model !nterpreter

!fter creating the complete model for a desired warehouse configuration" the corresponding configuration artifacts are generated using the domain/specific model interpreter. The model interpreter we are developing for the IT# project is a Aisual 'asic based macro that be e6ecuted within Aisio. In particular" the interpreter focuses on the following issues1 =. *ertain location/related constraints can be checked inside the interpreter to validate the model" such as ensuring that the physical layout and configuration of the warehouse is legal and meaningful. For e6ample" when a crane is on top of a storage place" we must make sure that the crane is capable of reaching all the storage cells of the place. 9pon discovering potential conflicts" error or warning messages will be issued to the domain e6pert. +. The underlying semantics of the graphic model can be abstracted from the model to populate the databases of the warehouse system. The generated artifacts include the classes used to populate the databases and some the initiali5ation process of the databases. !fter

running the model interpreter" the system is ready to start the component/based assembly and deployment process.

%.ONGOING WORK:
&ne aspect of our ongoing work is the focus on building the run/time interactive model. For the current stage of the IT# development" we regard Aisio as a static design tool. Thus" a model in Aisio is transformed into a data model which will be used by the application. The Aisio model itself will not be used after the static design phase. <owever" for the warehouse system" a dynamic provisioning tool is always desired. For e6ample" with the dynamic provisioning tool" the operator of the system could observe the status of the transportation process being reflected on the )9I model" such as a blinking light indicating the failure of a transportation unit. This capability will allow the operator to dynamically reprovision the system. To provide the features discussed above" we plan to make the domain specific building blocks e6ecutable. *&M ! Is will be used as the technology to implement this capability. In addition to the 8arehouse #ystem .omain #pecific Modeling aradigm" we are also working on a domain/specific modeling tool suite" called *omponent #ynthesis using Model Integrated *omputing 2*o#MI*3 " to model and synthesi5e the deployment and configuration of middleware components and the application?s Bo# re4uirements. In this regard the *o#MI* project is developing domain/specific tools for composing and deploying middleware/based applications. The *o#MI* tool suite is designed to model and analy5e application functionality and Bo# re4uirements and synthesi5e appropriate **M/specific deployment metadata re4uired to provision and enforce end/to/end Bo# both statically and dynamically. 8ith respect to the IT# project" our goal is to integrate the 8arehouse .#M( and *o#MI*?s .#M(# to address the full range of function ality comprising 8arehouse Modeling" component/based distributed middleware configuration and the application assembly and deployment. 'y applying *o#MI* technology" we can take advantage of visual languages to compose components into component servers" which involves generating the directives to assemble semantically compatible application components from reuse repositories and determining the interconnections between these selected components. 8e can also use visual modeling languages to configur e application component containers" which comprise

generating Bo# policies" such as threading policies or levels of security and fault tolerance"for the containers hosting the components.

4.CONCLUDING REMARKS:
!n Inventory Tracking #ystem 2IT#3 is an e6ample of a large/scale commercial system with multiple aspects of Bo# re4uirements. This document describes how domain/specific modeling languages and model interpreters can simplify managing different aspec ts of IT# development. &ur modeling tools are currently able to synthesi5e the database configuration and population aspects of IT#. &ur ongoing work comprises using the &M) M.! technology in conjunction with the *&R'! *omponent Model 2**M3 for developing and deploying the components of the IT#. Modeling languages like 9M( and use case reali5ation approaches manifested in our *o#MI* tool suite are used e6tensively for component development while other modeling paradigms are developed to handle the assembly and deployment aspects of IT#..

CONCLUSION:
The productivity gains from M.. are undisputable. 'y creating this e6ample" the solution0s architecture was defined" and tangible artifacts were created that can be added to the code base of the solution. If the time had been taken to create a unit test 2and a lab set up with a set/top bo6 to activate3" a steel thread could have been done to prove the architecture sound. .evelopers would then have a concrete e6ample of how the solution is e6pected to behave. rior to development" the architect can put the solution framework into the )uidance !utomation Toolkit 2)!T3 e6tension to Aisual #tudio +,,F" to communicate the design to the development team with strict guidance on how to implement the solution correctly. The pictures can then be e6ported and inserted into a document to communicate the solution0s architecture to the nondevelopment stakeholders" eliminating a redundant effort of creating the diagrams in another tool.

RE ERENCES:
G=H &bject Management )roup" Model .riven !rchitecture 2M.!3" &M) .ocument ormsc>+,,=/,-/,= edition" $uly +,,=. G+H aul !llen" IModel .riven !rchitecture"J *omponent .evelopment #trategies" vol. =+" no. =" $an. +,,+. G:H &bject Management )roup" *&R'! *omponents" &M) .ocument formal>+,,=/==/,: Edition 2$un. +,,+3. GKH Canbor 8ang" .ouglas *. #chmidt" !niruddha )okhale" *hristopher .. )ill" 'alachandran Catarajan" *raig Rodrigues" $oseph . (oyall" and Richard E. #chant5" ITotal "uality of Service #rovisioning in $iddleware and Applications"J vol. +;" Co. L/=," $an +,,:. GFH 'E! #ystems" et al." %&'(A %omponent $odel )oint 'evised Submission" &bject

Management )roup" &M) .ocument orbos>LL/,-/,= edition" $uly =LLL. G;H Canbor 8ang" Mrishnakumar 'alasubramanian" and *hris )ill" ITowards a real/time corba component model"J in &$* +orkshop &n ,mbedded - 'eal.Time /istributed &b0ect Systems" 8ashington" ..*." $uly +,,+" &bject Management )roup. G-H $anos #5tipanovits and )abor Marsai" IModel/Integrated *omputing"J IEEE *omputer" vol. :," no. K" pp. ==,N==+" !pr. =LL-. GOH !niruddha )okhale" 'alachandran Catarajan" .ouglas *. #chmidt" !ndrey Cechypurenko" Canbor 8ang" $eff )ray" #andeep Ceema" Ted 'apty" and $eff arsons " %oS$I%1 An $/A *enerative Tool for /istributed 'eal.time and ,mbedded %omponent $iddleware and Applications" roceedings of the && #(! +,,+ 8orkshop on )enerative Techni4ues in the *onte6t of Model .riven !rchitecture" #eattle" 8!" Covember +,,+. GLH .ouglas *. #chmidt and Fred Muhns" IAn &verview of the 'eal.time %&'(A Specification"J IEEE *omputer Maga5ine" #pecial Issue on &bject/oriented Real/time *omputing" vol. ::" Co. ;" $une +,,,. G=,H Canbor 8ang" Mrishnakumar 'alasubramanian" and *hris )ill"ITowards a real.time %&'(A component model"J in &M) 8orkshop &n Embedded P Real/Time .istributed &bject #ystems" 8ashington" ..*." $uly +,,+" &bject Management )roup.