1 / 45

CS428/9: Software Engineering II

CS428/9: Software Engineering II. Darko Marinov (slides from Ralph Johnson). Topics after Spring Break. Covered Component-based software engineering Client-server software engineering Web software engineering Reengineering and maintenance Reverse engineering Today

marcus
Download Presentation

CS428/9: Software Engineering II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS428/9: Software Engineering II Darko Marinov (slides from Ralph Johnson)

  2. Topics after Spring Break • Covered • Component-based software engineering • Client-server software engineering • Web software engineering • Reengineering and maintenance • Reverse engineering • Today • CASE and model-driven software engineering 428-22

  3. CASE Computer Aided Software Engineering • Computer tools for helping a software engineer • Modeling tools, with code generators, simulators, test generators, etc. 428-22

  4. Tools for software engineering • Compilers • Editors • Debuggers • Configuration management • Test suite management • Middleware (CORBA, EJB, MTS) 428-22

  5. Integrated CASE environment • Provide a mechanism for sharing SE information among all tools in the environment • Enable a change to one item of information to be tracked by related information items • Provide version control and configuration management for all SE information 428-22

  6. Integrated CASE environmnet • Allow non-sequential access to any tool • Support the software process • Provide a consistent look and feel • Support communication among software engineers • Collect both management and technical metrics 428-22

  7. CASE in industry • Tools advertised as “CASE” usually focus on analysis and design • CASE tools usually support pictures, but also generate code • Rational Rose • Together (http://www.borland.com/together/index.html) 428-22

  8. Together • Modeling • UML • Patterns • Development • Java/C++/other • “Round trip engineering” (a bit of holy grail) • GUI builder 428-22

  9. Together projects • System is made of one or more projects • Many people can work on one project • Project contains a directory for code and diagrams • Can convert code into package diagram and class diagram for the project • Can convert diagrams into code 428-22

  10. Modeling • Supports all UML diagrams • Most support for class diagram, structure diagram • Library of patterns • Applying a pattern can add class, association, or method 428-22

  11. Code generation • Class diagrams can generate code • Class template describes what is included with each class. • Special templates, e.g. for EJB • Method in diagram includes code for method 428-22

  12. Round trip engineering • Programmers can edit program • “Together” will update diagrams • Solves problem of out of date diagrams 428-22

  13. Together as an example of CASE • Variety of tools • Common project “database” • Changes propagated from code to diagrams • Version control • Multiuser • Some metrics 428-22

  14. Together as an example of CASE • Focus on pictures • UML - general purpose modeling language • Code generation • Patterns - the latest thing • Round-trip engineering, demanded by customers 428-22

  15. Failure of CASE • 1980: CASE will revolutionize software! • Problems • No feedback • Diagrams get out of date • Slow progress without improving quality • “Fool with a tool is still a fool” • 2005-10: CASE used modestly 428-22

  16. Success of CASE • Many kinds of code generators • Compilers • Finite state machines • User interfaces 428-22

  17. Rules for code generation • Never edit generated code • Specify procedures to call • Specify code to include • Generate superclasses, write code in subclasses • Don’t look at generated code • Usually very ugly 428-22

  18. Potential future of CASE • Model-driven architecture (MDA)http://www.omg.org/mdahttp://www.omg.org/docs/omg/03-06-01.pdf • Claim: models will be more reusable than code • A vision, not yet a technology or a process • Describe system with UML + extra info • Generate all code from model 428-22

  19. Example of MDA • Wells Fargo • Big systems, lots of legacy code, many technologies • A UML model of all the business objects • Can generate IDL for CORBA, SOAP, COM from the UML model 428-22

  20. Division of labor • Business Object Services group maintains the model and helps other people understand it • Projects usually have people from client group, BOS group, and backend data group • Model used to generate interfaces for client group 428-22

  21. Reality of MDA • Model defines data and interfaces • Model controls middleware • Model does not describe all the behavior • Use conventional programming languages • UML not good at precise behavioral specification • Many attempts to extend UML so it will be better at specifying behavior 428-22

  22. Promise of MDA • Platform Independent Model (PIM) is transformed to Platform Specific Model (PSM) • A normal UML model is “marked” with extra information to guide code generation • Behavior is described with an “action language” 428-22

  23. Problems of MDA • UML is a modeling language to help you think and talk to other people • UML is not a programming language • How can you make UML be precise while still letting it be easy to use? 428-22

  24. More OMG standards • Finance • Health care • Telecom • E-commerce • Transportation • Space • … 428-22

  25. More details of MDA • Record analysis and design models • Generate as much code as possible from them • Reduces cost of generating code • Change to model quickly can be reflected in code • Models become more accurate • Reuse models for different platforms 428-22

  26. MDA • Based on UML • Focuses more on middleware than on business logic • Aimed at three-tier business systems. 428-22

  27. MDA • Use UML to define a Platform Indendent Model (PIM) • Add “marking” and “annotation” to PIM • Marking is platform independent • Annotation is platform specific • Generate a Platform Specific Model (PSM) and all the IDL for various middleware 428-22

  28. PIM to PSM mapping process PIM Marked PIM Mapping Platform PSM Annotations 428-22

  29. What is a platform? • Operating system • Programming language • Database system • Web server • CORBA/DCOM/SOAP/RMS • Any software package 428-22

  30. Persistence • Are objects stored in a RDBMS or in a flat file? XML? • How do we fetch an object? Does it have an ID? • When do we store it? • UML does not have enough information 428-22

  31. Extending UML • Stereotype – a label on a class, attribute, operation, or other model element • Profile – a set of related stereotypes 428-22

  32. Persistence Profile • <entity> - class that is persistent • <key> - attribute • <get><set> - attribute • <add><remove> - attribute • <generated> 428-22

  33. Vehicle class diagram Garage Vehicle garage capacity: Integer dateAcquired: Date make: String model: String year: Integer price: Float computeAmortizedValue() vehicles 428-22

  34. Stereotypes <entity>Vehicle <entity>Garage garage <key,generated> oid:String <get,set>dateAcquired: Date <get,set>make: String <get,set>model: String <get,set>year: Integer <get,set>price: Float <get,set>/garage:Garage computeAmortizedValue() <generated>Create(): Vehicle capacity: Integer <key,generated> oid: String <generated> Create(): Garage <generated> FindByKey(oid: String) Garage vehicles 428-22

  35. Process of MDA to define application • Define class diagram • Mark class diagram • Specify the target of PSM • Customize PIM with annotation • Generate PSM 428-22

  36. Example mapping to XML Specify the target of PSM XML – JavaXMLMapper Customize PIM with annotation Specify file for each class Default is “garage.xml” for Garage objects, “vehicle.xml” for Vehicle objects Specify tag for each attribute 428-22

  37. Result of storing to XML <?xml version=“1.0” encoding=“UTF-8”?> <java version=“1.4.1_02” Class=“java.beans.XMLDecoder”> <object class =“vehicle.Garage”> <capacity> 2 </capacity> <oid> 342 </oid> <vehicles> <reference oid=“922”> </vehicles> </object> </java> 428-22

  38. EJB as target • Use same marked class diagram • Will create • A Bean interface for each entity class • A Bean class for each entity class • A Bean key class for each entity class • A Home interface for each entity class • A deployment descriptor container 428-22

  39. Annotation for EJB • Information needed • EJB container vendor • Vendor specific information such as session timeout, bean and data cache settings, and local transaction settings • Database • Will create DDL if tables do not exist • Provide mapping to existing tables 428-22

  40. Other profiles • We’ve seen a profile for persistence • Other profiles for • Distribution • Transactions (builds on persistence) • Security 428-22

  41. Transformer • Transformer for each profile/target platform • Transformer is a program • Each new target platform requires a new transformer for each profile 428-22

  42. Impact on organization • Two types of developers • Modelers • Understand the problem domain • Create UML models • Write algorithms in Java/action language/?? • Transformation writers • Understand platform • Write transformations 428-22

  43. Problems • Profiles have to be standardized • Class diagrams get cluttered • Transformations interact • Writing transformers can be hard • UML gets complex • Do we really achieve portability? 428-22

  44. Summary • CASE: Computer-aided Software Engineering • Computer tools for helping in software engineering tasks (modeling tools, with code generators, simulators, test generators, etc.) • MDA: Model-driven Architecture • Write Platform Independent Models (PIM) • Generate Platform Specific Models (PSM) • Limited success in several domains 428-22

More Related