Kern Jon GLSEC PragmaticMDA

50 %
50 %
Information about Kern Jon GLSEC PragmaticMDA
Entertainment

Published on August 14, 2007

Author: Gabir

Source: authorstream.com

Pragmatic MDA3 Keys to Software Development Success:  Pragmatic MDA 3 Keys to Software Development Success V1.2 Jon Kern Agile Pragmatist jonkern@comcast.net Blog: http://technicaldebt.com/ 26 October 2006 Great Lakes Software Excellence Conference About Me:  About Me Doing software since 80s, O-O since ~late 80s 10 years DoD consulting, real-time, flight simulation, centrifuge, fighter agility, etc. Formed Lightship Inc in ‘95, clients like IBM… First published agile method in ‘97 Co-author Java Design w/ Peter Coad Joined Peter to form TogetherSoft Sep ’99 Led OO/Java workshops, mentored hundreds Co-author Agile Manifesto, ‘01 Sold out to Borland in late ’02/‘03 Recruited by OptimalJ Team ‘03 Freelance as of mid-October ‘06 Topics:  Topics Building software is hard! Three Keys to Success Modeling Architecture Agile development processes Pragmatic MDA – A very real solution for many cases How do we start with MDA? Some examples What Makes S/W Dev So Hard?:  What Makes S/W Dev So Hard? Ability to meet the demands of the business Shrinking business cycle, need more business agility Clear business vision/goals for the application Ability to meet the demands of development Crazy schedules/death marches Need for application agility Requirements are nebulous, non-prioritized Striving for effective process andamp; productivity Ability to meet the demands of development Deploying a performant system Building the app properly for the expected lifespan How Is Software Built?:  How Is Software Built? People, Process, and Tools! In about that order… Good people will trump poor/non-existent process Good people will either create tools or use tools in an effective manner Process and Tools cannot make up for inadequacies of the development staff Gray matter is a pre-requisite 3 Keys to S/W Development:  3 Keys to S/W Development Separation of Concerns Model the Business Keep technology separate Construction Consistency Application Architecture Consistent application of: Technical architecture Construction guidelines Standards andamp; conventions Agile Development Environment Frequent, working, tangible results Separation of Concerns:  Separation of Concerns Architectural best practice Keep business logic in one place Architect for the future Keep Technology at arm’s length Isolate change #1 No Separation of Concerns?:  No Separation of Concerns? Older applications are 'brittle' – hard to change without causing breakage It takes 80% of the effort just to 'keep the lights on' It is hard to add new features No one can really point to your business model It is very hard to train new developers to work on the application No Separation of Concerns?:  No Separation of Concerns? Older applications are 'brittle' – hard to change without causing breakage It takes 80% of the effort just to 'keep the lights on' It is hard to add new features No one can really point to your business model It is very hard to train new developers to work on the application Technical Debt Construction Craftsmanship:  Construction Craftsmanship Consistent Variable #2 Software Development Processes:  Software Development Processes Predictive / Prescriptive Planned out in detail through a far horizon 'Do these 10 steps…' Know precisely where they are on the roadmap Waterfall is typical Lots of up-front effort prior to any coding Adaptive / Agile Plan only enough to get moving Allow for change Be vague about far-horizon timeframes Be crystal clear about the next two weeks Constantly communicate Agile Development:  Agile Development A state of mind! Shrink waterfall cycle into small iterations Ensure working application and feature progress Make it simpler to embrace change Improve communication between business and IT Deliver business value faster and continuously Make change an asset! #3 Agile Methodologies:  Agile Methodologies SCRUM Mostly a project mgt technique, uses 30-day 'Sprints' to develop software features (form the 'Sprint Backlog') Daily Scrum (stand-up mtg), uncover obstacles, talk about what you did and will do Not much is said about development itself, relies on people DSDM (Dynamic Systems Development Method) Grew from RAD practices, relies heavily on facilitated workshops with active user participation Iterative and incremental frequent delivery of business value Testing is integrated, and ease of feature rollback is a must XP – eXtreme Programming Described later Agile Methodologies (ii):  Agile Methodologies (ii) FDD – Feature-Driven Development Develop an overall model Build a features list Plan by feature Iteratively, in groups per iteration Design by feature Build by feature Others Crystal Methods Lean Development Adaptive Software Development Plotting the Methodologies*:  Unified Process Plotting the Methodologies* * Borrowed from Craig Larman’s excellent 'Agile andamp; Iterative Development – A Manager’s Guide' CEREMONY CYCLES Few docs Few steps Many docs Formal steps Many short iterations One Giant iteration SCRUM (30 days) Strict Waterfall – Length of entire project FDD (2-4 wks) XP (1-4 wks) Waterfall:  Waterfall Widely understood, well known, from 1973 IEEE paper Often disparaged by 'those in the know' Theory was pretty good (esp. considering ’73) Practice proved less than adequate Alluring feature was being predictable and prescriptive Biggest sources of error Being non-iterative Assuming you could build software in a single pass Late-stage design breakage (when integration occurred) Repeating expensive steps (construction) eXtreme Programming:  eXtreme Programming 'Like other agile methodologies, XP attempts to find a route between what its advocates see as the paralyzing effect of rigid, specification-centered project methodologies and the chaos that can result from having no methodology at all. At the same time, it claims to have the potential to avoid personal burnout and develop a more sustainable software development culture. ' XP Values: Communication Simplicity Feedback Courage Respect The 12 XP Practices:  The 12 XP Practices Fine scale feedback Pair Programming Planning Game Test Driven Development Whole Team Continuous process Continuous Integration Design Improvement Small Releases Shared understanding Coding Standard Collective Code Ownership Simple Design System Metaphor Programmer welfare Sustainable Pace Why is Agile Development Here?:  Why is Agile Development Here? Because the majority of software efforts fail! There was a predominance of No methods (hacking) and Heavyweight methods (non-tailored RUP) Some of us had the sense to create and practice 'Lightweight Methods' Successfully combined tried and true techniques Iterative / Incremental Timeboxing (deliver in a fixed period of time) Proving progress through working software Using tests to minimize breakage (JUnit/NUnit) Etc. Agile Manifesto:  Agile Manifesto Individuals and Interactions Working software Customer collaboration Responding to change Processes and Tools Comprehensive documentation Contract negotiation Following a plan While we value the things on the right, we value those on the left more http://agilemanifesto.org over… over… over… over… Running Software:  Running Software Necessary – but not sufficient! Don’t be fooled by running software alone It must be built on a good architectural foundation It must not incur technical debt It must be treated as an important asset Even poorly architected software can give the appearance of being 'good' – at the user interface level. It must meet the goals of the business now, and be in a position to meet the future plans for the business Three Keys!:  Three Keys! MDA – the answer?:  MDA – the answer? Is MDA our 'magic' tool? Let’s take a high-level look… Easy Solution to Our Quest!:  Easy Solution to Our Quest! MDA!! Model app andamp; svcs completely in UML Push some buttons in our MDA tool Presto-magic, your business app is done! “Text Files ‘R Us”:  'Text Files ‘R Us' Yup, that’s what we do, we generate text files for a living If we’re good, we Model out aspects of the solution Especially the domain Often the database Follow an architectural pattern or two Use consistent standards and conventions And build the app iteratively How Does Pragmatic MDA Work?:  How Does Pragmatic MDA Work? Simple recognition that many s/w artifacts Share common code template Have dynamic aspects that can be modeled Have custom bits that can’t be modeled Modeling is used To speed up creation of the mundane artifacts To simplify rapid changes to the application via model properties To implement architecture elements Artifacts are not inexorably tied to the MDA tool Tool does not prohibit normal development activities Working applications are built more quickly, allowing rapid feedback to support iterative development With consistency, quality, architectural best practices built-in The Simplicity of Pragmatic MDA:  The Simplicity of Pragmatic MDA Meta Data Models are used for business Models are used for technical artifacts (e.g., DBMS, build.xml) Transformations Templates/Java used to transform the models to your desired architecture First pass is an Application Model (platform-specific) Second pass is the Code Model (i.e., working app) Intermediate PSM Model Useful Permits using technology: J2EE Security EJB Finders DBMS Logical Model Etc. MDA Simplified:  MDA Simplified Before we get into the gory details, MDA can be thought of simply as The world’s most elegant text generator! (Shockingly simple, eh?) Code / Text Generation:  Code / Text Generation Combination of Metamodels Property slots Models Classes, Tables Transformations Code generation / report generation Meta Data Models:  Meta Data Models Models about your models ('M2') Model of UML classes, etc. Yields the ability to model classes, Tables, UIs Ability to model custom metadata Your own unique artifact types MDA: Models & Meta-models:  MDA: Models andamp; Meta-models Where do Models Fit In?:  Where do Models Fit In? You probably use metamodels more than you might imagine For example: Database modeling IDE wizards Project creation Class creation EJBs All share similar attributes of static text results co-mingled with your dynamic information Transformations:  Model-to-Code Transformations Example of Domain to SQL: Transform a UML model to a Database model Model to Model Transform Database model to SQL Model to Code Classes Tables SQL Code Model-to-Model Real World MDA Example:  Real World MDA Example Or, the story of how MDA is used to simplify the development of an MDA tool (OptimalJ) when it was built on both NetBeans and Eclipse… The Need for Two PSMs:  The Need for Two PSMs For generic preferences dialog, Eclipse and NetBeans need to be supported Preferences: the meta-model:  Preferences: the meta-model Preferences : the model:  Preferences : the model Preferences : code generation:  Preferences : code generation TPL : Simple language to write implementation patterns to generate code (a lot like a report generator) Skeleton file TPL constructs to 'walk' through the model What should be generated? A JavaClass that extends org.eclipse.jface.preference.PreferencePage Containing a generated implementation of the method to create the contents: protected Control createContents(Composite parent); PreferencePage.tpl :  PreferencePage.tpl /** * Eclipse preference page for andlt;module.nameandgt; */ public class andlt;UCF(setting.name)andgt;PreferencePage extends PreferencePage implements IWorkbenchPreferencePage { private Composite mainPanel; protected Control createContents(Composite parent) { mainPanel = new Composite(result, SWT.NONE); ... Composite panel = new Composite(mainPanel, SWT.NONE); ... andlt;BLOCK('createContents')andgt;andlt;/BLOCKandgt; ... } andlt;CREATEWIDGETS(imports, module, setting)andgt; } CreateWidgets.tpl:  CreateWidgets.tpl andlt;TEMPLATE PUBLIC CREATEWIDGETS(Set imports, Module module, Setting setting)andgt; andlt;FOR(Property property IN setting.part)andgt; andlt;IF (Util.hasBooleanType(property))andgt; andlt;BOOLEANWIDGET(imports, setting, property)andgt; andlt;ELSEIF (property.type.name.equals('color'))andgt; andlt;COLORWIDGET(imports, setting, property)andgt; ... andlt;/IFandgt; andlt;/FORandgt; andlt;/TEMPLATEandgt; Generated PreferencePage (java):  Generated PreferencePage (java) /** * Eclipse preference page for Xenon */ public class DiagramPreferencePage extends PreferencePage implements IWorkbenchPreferencePage { private Composite mainPanel; ... protected Control createContents(Composite parent) { mainPanel = new Composite(result, SWT.NONE); ... Composite panel = new Composite(mainPanel, SWT.NONE); ... shadowCheckBox = new Button(panel, SWT.CHECK); shadowCheckBox.setData('Diagram.shadow'); ... textColorColorSelector = new ColorSelector(panel); textColorColorSelector.getButton().setLayoutData(gridData); ... } ColorWidget.tpl:  ColorWidget.tpl andlt;TEMPLATE PUBLIC COLORWIDGET(..., Property property)andgt; ... andlt;APPEND('createContents')andgt; Label andlt;property.nameandgt;Label = new Label(panel, SWT.LEFT); andlt;property.nameandgt;Label.setText(I18N.getString(...)); andlt;property.nameandgt;Label.setToolTipText(I18N.getString(...)); gridData = new GridData(SWT.RIGHT, SWT.NONE, true, false); gridData.horizontalSpan= 2; andlt;property.nameandgt;ColorSelector = new ColorSelector(panel); andlt;property.nameandgt;ColorSelector.getButton().setLayoutData(gridData); andlt;/APPENDandgt; ... andlt;/TEMPLATEandgt; Great! So how do we start?:  Great! So how do we start? What does an agile MDA project look like? How it Works in Practice:  How it Works in Practice Relative Participation By Task Development Cycle Duration / Time Model the Business (Appl. Architecture) Create Technical Architecture (Or re-use existing) Work out Appl. Details (Coding, UI, Integration) Continuous Integration and Testing Design the technical architecture Each Iteration/Release Work out ‘N#’ of features to be delivered. Work out breadth of application’s features Conduct verification of high-risk issuesand#xB;(as often as needed) Wrap-up: 3 Keys to S/W Development:  Wrap-up: 3 Keys to S/W Development Separation of Concerns Construction Consistency/Dual Architecture Agile Development Environment Consider the value of information in models to help development proceed Consider separation of domain IP and architecture/construction Remember, it’s all about the business! Thank You!:  Thank You! Feel Free to contact me: JonKern@comcast.net And visit my new blog: http://TechnicalDebt.com

Add a comment

Related presentations

Related pages

Mechanical-Design-of-Process-System-V2.pdf

Mechanical-Design-of-Process-System-V2.pdf - Free ebook download as PDF File (.pdf), Text file (.txt) or read book online for free.
Read more

Travel around the world — Adventures is cool » Blog ...

john.church@ info@ Tjssr99@ pjboomrt@ dftpnk85@ Thumprific@ prize420@ lottadolly@ ... glsec@ leelippert@ dsssbn616@ flamigni@ khanh-pg@ penepoker@ rat2599 ...
Read more

Wheels and tuning — Super cars » Blog Archive » Allbonita@

john.nnamdii1@ patybear@ unit26658@ pieprmaru@ lil8286341@ lpdmurray@ phish353@ RaptorREt@ maipenrai@ Plusonebabe3@ pbatten@ queenke@ poyerb@ jsones ...
Read more

gmorfesi@

john_h2o@ portaaurea@ gofstr4fun@ rotclove33@ madhukar_r_pai@ ... kernen@ nkilzar@ rtroutt@ mainonriver@ dlselecthomes@ nkarooke1@ rosem@ dianaoje@ keaum ...
Read more

deepblue.lib.umich.edu

... , 1.0 0.5 0.0 1.0 2.0 3.0 1.0 Time/100 glsec Figure 36(d). 9.7% MAPP-Air ... 14. Yoshimine, M., Kern, W.G ... Univ/Dr.John Lee ...
Read more