2013 Good Design Is Good Business MDD Embedded Systems
•Télécharger en tant que PPT, PDF•
0 j'aime•730 vues
Agenda: 1. Code in the world of model-driven development (MDD) 2. Using model-driven development to accelerate traditional development 3. MDD capabilities and technologies for code centric development
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 2013 Good Design Is Good Business MDD Embedded Systems
Similaire à 2013 Good Design Is Good Business MDD Embedded Systems (20)
Plus de Roger Snook
Plus de Roger Snook (20)
Dernier
Dernier (20)
2013 Good Design Is Good Business MDD Embedded Systems
- 1. © 2011 IBM Corporation Good Design is Good Business (5:50 time mark) Embedded and Real-time Software Development, A Model-Driven Approach Featured Speaker: Manohar Rao, IBM Rational Specialty Architect, raom@us.ibm.com Roger Snook Download Slides! IBM Software, Rational Watch Replay! WorldWide Enablement Leader, Mobile, SOA, Design +1.703.943.1170, RCSnook@us.ibm.com Look for more sessions, Collaborate!
- 2. © 2013 IBM Corporation 2 Agenda Code in the world of model-driven development (MDD) Using model-driven development to accelerate traditional development MDD capabilities and technologies for code centric development Q&A
- 3. © 2013 IBM Corporation 3 Silos of people, process, and projects Organizational BarriersGeographic Barriers Poor communication Language, culture, time Process gaps resulting in rework Infrastructure Barriers Weak collaboration Poor project governance and LOB oversight Security of IP Incompatible tools Unreliable access Lengthy on-boarding Inflexible integration Complexity Creates Development Challenges Leading to cost overruns, schedule slips and quality issues Poor requirements engineering = failed project Paper-based and manual processes hinder efficiency Complex architecture is difficult to textually explain Functionality is poorly distributed across components Hardware/software integration is often late Many organizations lack formalized practices
- 4. © 2013 IBM Corporation 4 Past Modern Approaches for Describing Systems Are Evolving To Better Manage Complexity and Reduce Time-to-market Moving from manual methods to an automated, visual approach Specifications Interface requirements System design Analysis & trade-off Test plans Future UserUser AdminAdmin AccessPointAccessPoint CameraCamera Security System Uc3ConfigureSecurity System Uc2Control Exit Uc1Control Entry readSecurityCard User validateSecurityCard [CardStatusValid][CardStatusValid] scanBiometricData User [else][else] authenticateBiometricData [else] flagBiometricScanFailure [else] [else][else] [else] flagSecurityCardFailure [else] [else][else] [BiometricData Authenticated] logEntryData [BiometricData Authenticated] [BsFailCount==3] disableUserAccount Admin [BsFailCount==3] [ScFailCount==3][ScFailCount==3] displayCardStatus [Timeout BiometricScan][Timeout BiometricScan] displayAuthenticationStatus logAccountData alarm unlockAccesspoint «MessageAction» AccessPoint lockAccesspoint «MessageAction» AccessPoint [Timeout Unlocked][Timeout Unlocked]resetAlarm Admin [else][else] takePicture «MessageAction» Camera [First Request][First Request] User CameraAccessPointUc_Uc1ControlEntry message_0() readSecurityCard() message_1() validateSecurityCard(CardStatus) displayCardStatus(CardStatus) message_2() scanBiometricData() authenticateBiometricData(AuthenticationStatus) displayAuthenticationStatus(AuthenticationStatus) logEntryData() message_3() message_4() message_5() message_6() message_0() readSecurityCard() message_1() validateSecurityCard(CardStatus) displayCardStatus(CardStatus) message_2() scanBiometricData() authenticateBiometricData(AuthenticationStatus) displayAuthenticationStatus(AuthenticationStatus) logEntryData() message_3() message_4() message_5() message_6() Uc1ControlEntryCtrl WaitForEntryRequest UnlockingAndLockingAccessPoint reqTakeSnapshot to pCamera reqReadSecurityCard/ readSecurityCard(); reqProcessAlert("User Access Disabled") to pAdmin ProcessingSecurityCardData Fail3Times ProcessingBiometricData Failed3TimesBsTimeoutAuthenticated [CardStatus=="Valid"] A evAccessPointLocked A /disableUserAccount(); logAccountData(); A WaitForResetAlarm reqResetAlarm/ resetAlarm(); reqReadSecurityCard/ readSecurityCard(); [CardStatus=="Valid"] evAccessPointLocked /disableUserAccount(); logAccountData(); reqResetAlarm/ resetAlarm();
- 5. © 2013 IBM Corporation 5 Challenges facing embedded software development Maintaining consistency between documentation and implementation Depending on hardware availability for software development Increasing productivity while design complexity increases Managing changing requirements Maintaining long life products with long learning curve for staff changes Collaborating with large teams, often globally distributed
- 6. © 2013 IBM Corporation 6 Typical software development today workflow Design and implementation gets out of synch easily Requirements Design Implementation Testing Maintenance
- 7. © 2013 IBM Corporation 7 Code and document driven approaches typically lead to disjoint development processes What if the design was incorrect? What about the incorrect requirements? Requirements Design Implementation Testing Maintenance Becomes out of synch with your end product
- 8. © 2013 IBM Corporation 8 3rd PartyExisting Applications New featuresModified code Typical embedded software development projects Projects consist of new code, modifications to existing code, existing code not changing and third-party libraries Documentation for code is often out of date, if it exists at all
- 9. © 2013 IBM Corporation 9 Agenda Code in the world of model-driven development (MDD) Using model-driven development (MDD) to accelerate traditional development MDD capabilities and technologies for code centric development Q&A
- 10. © 2013 IBM Corporation 10 Executable Models Code in the World of Model Driven Development Model-is-code Everything is done in the model Code is “black box” One-way development flow
- 11. © 2013 IBM Corporation 11 Code Centric Code Centric Code in the World of Model Driven Development Code is the master Everything is done in the code and should stay exactly as-is
- 12. © 2013 IBM Corporation 12 Using implementation language Generating readable code Open framework Model-Code Associativty Model-Code co-Debugging Code in the World of Model Driven Development Code Construction Software Architecture and Design
- 13. © 2013 IBM Corporation 13 Using implementation language Generating readable code Open framework Model-Code Associativty Model-Code co-Debugging Code in the World of Model Driven Development Code Construction Elements with “intuitive” mapping to code Software Architecture and Design
- 14. © 2013 IBM Corporation 14 Using implementation language Generating readable code Open framework Model-Code Associativty Model-Code co-Debugging Code in the World of Model Driven Development Code Construction Use of abstractions such as ports and statecharts Elements with “intuitive” mapping to code Software Architecture and Design
- 15. © 2013 IBM Corporation 15 Code Centric Code Centric Code in the World of Model Driven Development Code is the master Everything is done in the code and should stay exactly as-is Code Construction Software Architecture and Design Using implementation language Generating readable code Open framework Model-Code Associativty Model-Code co-Debugging Model-is-code From the model Code is “black box” One-way development flow Executable Models
- 16. © 2013 IBM Corporation 16 3rd PartyExisting Applications New featuresModified code Typical software development projects and Model Driven Development Projects consist of new code, modifications to existing code, existing code not changing and third-party libraries Documentation for code is often out of date, if it exists at all Executable Models Software Architecture and Design Code Construction Code Centric Code Centric
- 17. © 2013 IBM Corporation 17 Agenda Code in the world of model-driven development (MDD) Using model-driven development (MDD) to accelerate traditional development MDD capabilities and technologies for code centric development Q&A
- 18. © 2013 IBM Corporation 18 UML as the Language of MDD Unified Modeling Language Comprehensive full life-cycle 3rd Generation modeling language – Standardized in 1997 by the OMG – Created by a consortium of 12 companies from various domains – IBM a key contributor to behavioral modeling Incorporates state of the art Software and Systems A&D concepts Matches the growing complexity of real-time systems – Large scale systems, Networking, Web enabling, Data management Extensible and configurable Unprecedented inter-disciplinary market penetration
- 19. © 2013 IBM Corporation 19 UML 2 diagrams Communication Diagrams Sequence Diagrams Interaction Diagrams Class Diagrams Deployment Diagrams Component Diagrams Object Diagrams Structural Diagrams State Machine Diagrams Timing Diagrams Activity Diagrams Behavioral Diagrams Use Case Diagrams Package DiagramsStructure Diagrams Interaction Diagrams
- 20. © 2013 IBM Corporation 20 Code Centric Workflows with MDD Visualize legacy/external code On-going coding with updated documentation Modernize code using MDD Design-with-models; implement-with-coding Model driven structural development Project time line Modeling is used in first stages of the project… But as the project progresses the code is what “matters”
- 21. © 2013 IBM Corporation 21 Visualize Legacy/External Code “We need to understand the structure of this spaghetti code” ”I need to understand the behavior of the library I was given” ”We need to hand-over documentation for this code” Modeling is used to understand the structure The code is stable or otherwise external to the project
- 22. © 2013 IBM Corporation 22 On-Going Coding with Updated Documentation “We need to keep documentation always consistent with the code” “We need to trace back code to requirements” “The developers are using Eclipse to code, but we want to do reviews in a higher level than code” “Management tells us to use UML, but we are happy with our editors” Modeling is used to visualize the code The code is evolved using editors and IDEs
- 23. © 2013 IBM Corporation 23 Modernise Code using MDD “Our legacy code still evolves” “We want to find reusable code in our legacy” “I want to refactor my legacy code” The model receives growing focus Code loses some focus but it still “matters”
- 24. © 2013 IBM Corporation 24 Design-with-Models; Implement-with-Coding “We did high level design with UML, but now we want to code” “Like we did in Rose” Modeling is used in first stages of the project… But as the project progresses the code is what “matters”
- 25. © 2013 IBM Corporation 25 Model Driven Structural Development “We want MDD, but some things are easier to do in the code itself” “We want to use models to drive the structure of the code (code frames)” – “and we don't care about abstractions such as ports or statecharts” “Like we did in Rose” Modeling is used throughout the project But as the project progresses the code is what “matters”
- 26. © 2013 IBM Corporation 26 Code Centric Workflows with MDD Visualize legacy/external code On-going coding with updated documentation Modernize code using MDD design-with-models; IMPLEMENT-WITH-CODING Model driven structural development
- 27. © 2013 IBM Corporation 27 Agenda Code in the world of model-driven development (MDD) Using model-driven development (MDD) to accelerate traditional development MDD capabilities and technologies for code centric development Q&A
- 28. © 2013 IBM Corporation 28 Essential Capabilities and Technologies for MDD Visualization (reverse engineering) Code-centric Support DMCA - Dynamic model-code associativity IDE integrations Simulation / Animation Model based testing
- 29. © 2013 IBM Corporation 29 Summary Different users have different needs in different contexts Models can be useful “even” when code-is-the-king Mix-and-Match across the Model-Centric and Code-Centric scale Code Centric Code Centric Code Construction Software Architecture and Design Executable Models
- 30. © 2013 IBM Corporation 30 Agenda Code in the world of model driven development Using model-driven development (MDD) to accelerate traditional development MDD capabilities and technologies for code centric development Q&A
- 31. © 2013 IBM Corporation 31 Good Design is Good Business Webcast series featuring some IBM Distinguished Engineers and thought leaders. Webcast Title (CLICK to register) - 12:15-1:15PM Dates The Big Picture (Roger Snook) 2/8/2013 IBM and Design (IBM Director UX Design, Karel Vredenburg) 3/7/2013 SOA - Still Going Strong (IBM Distinguished Engineer, Claus Jensen) 4/4/2013 Design Management: Pictures are Worth….(WW Enablement, Jean-Louis Marechaux) 5/2/2013 DevOps: Design and Deliver Your Production Code Faster (Product Manager, Maneesh Goyal) 6/13/2013 Mobile and Smartphone Apps (Roger Snook) 7/11/2013 Rational Software Architect (Roger Snook) 8/8/2013 Industry Models Accelerate Software (Solution Architect Nick Norris) 9/12/2013 Business Design: SA and RSA (dW author, Steve Arnold) 10/17/2013 *NEW DATE* Smarter Devices with Model Driven Development (Specialty Architect, Manohar Rao) 10/4/2013 SysML, Industry Compliance (Standards Leader, Irv Badr) 11/14/2013 Rational Rhapsody (Specialty Architect, Manohar Rao) 12/5/2013
- 32. © 2013 IBM Corporation 32 © Copyright IBM Corporation 2011. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. www.ibm.com/software/rational
Notes de l'éditeur
- So, building a systems competency is really a business-critical imperative in managing cost risk and the pursuit of innovation. When you look at the challenges faced by organizations, you see a variety of factors that add up to doom many projects and programs. Poor requirements engineering = failed projects Customer requirements are missed Capabilities not delivered due to cost/schedule overruns Paper-based and manual processes hinder efficiency Without automation, many processes are slow and unwieldy Impact analysis of changes can be time-consuming and expensive Complex architectures can be difficult to explain Lengthy textual descriptions can overwhelm those trying to transform them into deployable products Functionality is poorly distributed across components Each piece of the system has a role to play – the trick is to avoid overloading any one component when others can pick up the slack Complexity hinders systems efficiency and interoperability Hardware/software integration is often late Often waits until the design is done Mistakes and rework are very expensive Many organizations lack formalized practices Expertise is often in heads of “greybeards” and difficult to replace Difficult to attract and retain talent without defined practices and career paths When you add in the barriers most organizations face in terms of distributed teams and disciplines, it is easy to understand why so many companies struggle to provide the innovation they need to survive.
- Complexity of systems is forcing a shift from document based approaches to model based systems, which are more capable of managing complexity via abstraction. Rather than relying on the organizational abilities of one or two key design team members, the design becomes centrally accessible to the entire team. The models then become the source of the entire design – meaning specifications, interface requirements are generated from the models, test plans can be derived from models, analysis and design can be based on models, and documentation can be automatically generated from the models.
- Electronic device manufacturers are facing a challenging and competitive environment. They are facing the challenges of the current economic climate where there is stiff competition and development costs need to be reduced. Companies need to deliver the right product to market as soon as possible to gain a competitive advantage. But there is an increasing scrutiny by government and industry regulators and this causes added pressure to deliver products. For example there have been some new legislation put forth in the united states congress to hold medical executive accountable for the products they are putting into the market. A medical company cannot afford to resubmit an FDA submission to delay product release or worse have a recall that not only has a direct financial cost but also can ruin the brand reputation of a company. Companies need to provide extensive documentation to prove compliance with guidelines and ensure the product they deliver is not only innovative to capture the market from their competitors but also safe and secure. With the increasing complexity and amount of features packed in today’s devices, teams need to work smarter to scale the resources they have to deliver a successful product to market that meets regulatory guidelines without delays. Teams need to collaborate effectively across many disciplines and geographies. Besides the challenges of language and culture working with a geographic team. Even within the same location different disciplines may talk in a different terminology. The marketing team may communicate a set of requirements but they may not be able to understand software code to determine if the software team has really implemented the requirement until late in development. And communicating technical implementations to regulators can lead to misunderstandings and added delay of submission approvals. Its challenging enough to get regulatory approval in one country but the challenge becomes exponentially difficult if you build products for multiple countries (turn to next slide)
- To begin with… as systems further and further advance, so must the design and implementation methods of those systems advance in order to meet time to market deadlines with increased complexity. So the problems have become more complex, so design methods must mature in order to simply the creation of these systems.. The issue with a traditional that we often see in bleeding edge industries such as the consumer electronics market, is that essentially a waterfall approach quickly gets us to the point where the [CLICK] design and the implementation become disjoint. Typically this is in part to having to rush code out the door and continually fixing issues during the testing phase without updating the design.
- We refer to this approach as simply patching problems. Not that this is related to being lazy, but typically in segments in communications, we see that time to market makes the dynamics of the development environment much different from other markets. [click] Of course this workflow causes many issues downstream especially when architecture components need to be reused for new designs. If the design and requirements are different from the implementation, this makes the art of reusing components very cumbersome and not to mention risky. [CLICK] But even more so is maintenance of products as what’s running inside the system is quite different than the requirements and design. [click] Other issues to consider with this approach is what if the design was incorrect to begin with? [click] Or what about incorrect requirements? Taking the waterfall approach we don’t have a way to validate these phases as usually they are handwritten with no formal semantics that can be tested.
- Typical software development projects consist of code from a few different sources. New code would be created for new features, existing code may be modified to add new functionality. In addition existing code may be leveraged along with third party libraries. Effective reuse requires a good understanding of the code that is to be reused but often documentation for the code is out of synch with the design implementation, if it exists at all. Often the person who wrote the code may have left the company. For new developers on the project it is difficult to come up to speed from the code.
- Model Centric: No production code, Code is “ugly”, Not efficient BUT don’t care about the code Those who believe a model-driven approach to software development is the only answer tend to treat code as most programmers treated assembly language in the past, as a black box, only to be touched or used in extreme situations. Modelers believe everything can and should be done in the model and code derived or generated from the model. There is no two-way mechanism needed since the model is the master and code can always be generated.
- Code Centric: knows their (legacy) code; model used for communication, review etc When code is the master, users believe that models will get in the way or worse, cause errors or inefficiencies to creep in. In this case, there is a great reluctance ot move to using models even for visualizing or documenting the structure or architecture of the software.
- Somewhere in the middle is a place where both model-centric and code-centric developers can live in harmony. There are several keys to making code-centric practitioners move in this direction. These include. Using a language they are familiar with, i.e. a coding language like C, C++, or Java, as the language for specifying behavior in the model environment Generating code that is readable since this makes for easy debugging and is readily used with code-based technology for testing and debugging. An open framework for generating code, including being able to modify the framework to support specific code patterns for domains or standards is critical. Being able to work in either code or model and have the other updated automatically is important to code-centric developers. They need to be assured changes to the model will be reflected in the code and changes in the code will be updated in the model. As well they need to feel safe to update the code and have the changes respected when the model is again updated and code is generated. Being able to transition from a model-based debugging session, where the model is walked through, as in a state-machine, and then diving into the code debugger when a point of interest is reached is a very powerful debugging paradigm.
- Somewhere in the middle is a place where both model-centric and code-centric developers can live in harmony. There are several keys to making code-centric practitioners move in this direction. These include. Using a language they are familiar with, i.e. a coding language like C, C++, or Java, as the language for specifying behavior in the model environment Generating code that is readable since this makes for easy debugging and is readily used with code-based technology for testing and debugging. An open framework for generating code, including being able to modify the framework to support specific code patterns for domains or standards is critical. Being able to work in either code or model and have the other updated automatically is important to code-centric developers. They need to be assured changes to the model will be reflected in the code and changes in the code will be updated in the model. As well they need to feel safe to update the code and have the changes respected when the model is again updated and code is generated. Being able to transition from a model-based debugging session, where the model is walked through, as in a state-machine, and then diving into the code debugger when a point of interest is reached is a very powerful debugging paradigm.
- Somewhere in the middle is a place where both model-centric and code-centric developers can live in harmony. There are several keys to making code-centric practitioners move in this direction. These include. Using a language they are familiar with, i.e. a coding language like C, C++, or Java, as the language for specifying behavior in the model environment Generating code that is readable since this makes for easy debugging and is readily used with code-based technology for testing and debugging. An open framework for generating code, including being able to modify the framework to support specific code patterns for domains or standards is critical. Being able to work in either code or model and have the other updated automatically is important to code-centric developers. They need to be assured changes to the model will be reflected in the code and changes in the code will be updated in the model. As well they need to feel safe to update the code and have the changes respected when the model is again updated and code is generated. Being able to transition from a model-based debugging session, where the model is walked through, as in a state-machine, and then diving into the code debugger when a point of interest is reached is a very powerful debugging paradigm.
- This presentation will focus on the needs of those closer to the right hand side of this continuum. We will explore the capabilities needed in a modeling environment and the benefits that will ensue to help those using a strict code-centric approach to development to move closer to the center. We understand that many who are in the camp where “code is the master” will never move to a totally model-driven, model is master, practice but it is hoped the next few slides will convince many of the significant benefits of a combined approach, involving modeling and code together.
- Typical software development projects consist of code from a few different sources. New code would be created for new features, existing code may be modified to add new functionality. In addition existing code may be leveraged along with third party libraries. Effective reuse requires a good understanding of the code that is to be reused but often documentation for the code is out of synch with the design implementation, if it exists at all. Often the person who wrote the code may have left the company. For new developers on the project it is difficult to come up to speed from the code.
- These are the workflows or scenarios that we need to explore to fully understand the spectrum of users and their concerns moving from model-centric to code-centric developers. <read through the list and mention them>. As you can see, both modeling and code are important to the project but as the project progresses the importance of one decreases while the other gains.
- Since, as we discussed very early on, projects are almost never greenfield development, we often need to understand existing software, the code, before we can extend it or repurpose it for a new project. A few statements that we hear quite frequently are highlighted here, related to the need to visualize existing or external (3 rd party) code. For example, we may have a library (x.lib) and a header file (x.h) describing the interface of a library. One wants to do model driven testing of this library (e.g., library + header file come from supplier) There may be source code (a.cpp + a.h, b.cpp + b.h etc.) which is maintained outside of Rhapsody (e.g. using Visual Studio or some other development environment). We want to do model driven testing of the classes/functions in these source files (since e.g. reqs are based on SDs We need to bring these files into a modeling environment, visualizing their structure, relationships and the dependencies they have on each other. We may indeed find that the software resembles spaghetti or we may find that it is elegantly designed. With anything above a dozen classes, we have a hard time understanding the code and would be hard pressed to say one way or the other.
- Models can indeed be useful in providing a visual record or documentation, with little effort, of the code that is being written. As well, a full-featured modeling environment, like IBM Rational Rhapsody, helps with the linkage of designs to other lifecycle artifiacts like requirements and test plans. Traceability is enhanced when code is visualized in models and these links established. Design reviews are often better done at a graphical level where the structure of the software can be explained and visualized. Further, the use of sequence diagrams, activity diagrams and statecharts help with reviewing of the behavior of complex systems and software. Programmers benefit from up to date documentations, designs traced to requirements, and reviews done at the right level of abstraction all while using their favorite coding environment.
- You have probably heard statements like those above related to evolving software or trying to move applications from one platform to another. Modernizing a software intensive system is hard but model-driven development can greatly increase your odds of success. As we discussed in the last slide, a full-featured modeling environment can help you understand the code, determine the structure and some of the behavioral aspects. Once you have this understanding you can identify what parts of the software need to be updated to meet the new requirements and which parts can be used as is. The newer, evolving aspects of the software are modeled and updated code generated from the model while the existing code, is used as is. Knowing the structure of the existing software, through visualization in diagrams, can help with deriving reusable components as well as refactoring since the relationships can be viewed, searched and manipulated graphically.
- Alcatel: (Design) model was originally designed at the model level to declare classes & relationships among them. Now the model is considered "rather stabilized" by the project team " and "it's only about implementation now" => almost only code-centric development now. No statecharts, activity diagrams or flowcharts.
- For years, Rational Rose was the standard modeling environment and it was successfully used to define the structure of the software and even generate skeleton code. This helps with making sure the design is right at least at the start, but often the model and thus the understanding of the design gets left behind as the coding is done to actually implement the functionality of the software.
- We have just run through the spectrum of workflows or scenarios that we have seen when we start from a code-centric perspective but leverage modeling in the process.
- Let’s examine the critical capabilities needed to support the move from strictly coding to an approach where code is still very important but where modeling takes on a greater role in the development process. These capabilities include <read the list>
- Author Note: Mandatory Rational Closing Slide (includes standard legal disclaimer). Available in English only.