Model Management Configuration Management Model Management and Configuration

Model Management & Configuration Management Model Management and Configuration Management Nick Crossley, IBM © 2014 IBM Corporation

Product Line Engineering About the Speaker Nick Crossley is the Technical Architect for the IBM Rational solution for Product Line Engineering, including version and variant management, configuration management, and cross-domain baselining. Nick currently leads the OSLC Configuration Management workgroup, and participates in the Core workgroup. Nick has over 40 years of experience with software tools and development, with much of that time in configuration management. © 2014 IBM Corporation

Product Line Engineering What is Configuration Management? § Keeping track of versions of individual artifacts (configuration items) § Keeping track of versions of the system as a whole (baselines) § Tracking who changed what, when, and why (change management) § Managing, monitoring, and enforcing policies for all the above Since with model-based systems engineering, the models are key artifacts, it follows that configuration management must be a key part of MBSE and of model lifecycle management. © 2014 IBM Corporation

Product Line Engineering What is in a configuration? § Obviously, versions of the artifacts – Models, requirements, test plans and test cases, source code, etc. § Revision history, including change comments – who changed what, when, and why. § Links between artifacts – Links need to be versioned just as other properties of artifacts – And then navigated in the context of the relevant configurations (including baselines) § But sometimes that’s not enough. – Type systems, database schemas – Tools, scripts, compilers, library and operating system version and patch information – User environment (options, settings, ini files, config files, etc. ) § Hardware! See requirement #6 in section 3 of the current draft MLM paper: Is your goal just to record what was in a given configuration / baseline, or to be able to reproduce it from scratch? © 2014 IBM Corporation

Product Line Engineering Consistent artifacts § An artifact developed in one configuration must be reusable elsewhere – A developer probably edits the model in some form of workspace – And then submits or publishes the change to a shared configuration – Configuration managers may then promote the change to further configurations – but in all cases, the state of the artifact and its links must remain consistent – Navigation across links must be in the context of the appropriate configuration – Change sets or similar techniques may be required to guarantee coherent changes across multiple artifacts (both within and across tools!) © 2014 IBM Corporation

Product Line Engineering Hierarchies, or systems of systems § Today’s products are complex, with systems, subsystems, components, etc. – Often the different components are produced by different teams, each with their own schedules – Managing this component-based development in a flat or limited set of configurations would be very difficult – The ideal system would support arbitrary hierarchies of component, with arbitrary reuse of those components § This introduces the possibility of version skew – where two or more different versions of the same component or artifact are used in an overall system – Version skew is almost inevitable in a complex system of systems – But many configuration management tools do not support it in a native way – Requiring work-arounds, such as providing different names for file exports of two different versions of a model from a modeling tool, which then obscures from an SCM tool that these are really two different versions of the same thing © 2014 IBM Corporation

Product Line Engineering Parallel Development § Configuration management systems differ in how they handle new versions of artifacts, branching, and merging – Are new versions created on check-out? Check-in of an individual artifact? Commit of a change set? Creation of a baseline? – Can parallel versions of an individual artifact be created? Not at all? Only in separate ‘branches’ created by a configuration manager? By anyone at any time? – If parallel versions are permitted, how can changes be merged? At an artifact level, or across whole branches? Is the merge process interactive? What does it mean to merge models? © 2014 IBM Corporation

Product Line Engineering Access control § Several requirements and scenarios described in the MLM paper mention control over access to information in the configuration management system § This can be a challenge when there are multiple tools, and even more so when there are multiple systems used for authentication. User identifiers may not be the same in those different authentication systems – The user’s email address might a consistent and unique property even across such systems § Users and their access can change over time – But should a user whose access to a tool has been revoked continue to have access to historical configurations? In most scenarios, the appropriate answer is that user should not have such access – A corporation may want to grant support teams access to historical data, but not to versions of products not yet released – So access to configurations needs to be controllable and not treated as a fixed historical property of that configuration, nor limited to all-or-nothing access to a component © 2014 IBM Corporation

Product Line Engineering Subscription and notification § Requirement #3 in the MLM paper states: – A stakeholder responsible for contributing to or curating numerous models has too little spare time to poll each model in their scope of responsibility; this stakeholder needs to be notified when an area of interest within a particular model is subject to access or modification by selected individuals or communities of interest. § This implies the configuration management system should allow users to subscribe to certain artifacts, events, conditions, or configurations, and be notified when changes occur. § This needs to include the capability of being notified when a linked artifact is changed, since that change might invalidate the link and/or require corresponding changes to the subscribed artifact. For example, if a change is made to a requirement held in a separate RM tool, or a test case held in a separate QM tool is marked as having failed, a model stakeholder might need to be notified that the design element may need corresponding changes. © 2014 IBM Corporation

Product Line Engineering Simple file-based approach § Models are edited in tools using file-based storage, or tools that allow export of models to files § Other artifacts are edited in other tools with similar file-based output – Requirements management tools – Source code IDEs – Quality Management tools § Exported files are checked into a file-based SCM system to form complete baselines Problems § Granularity of export to files can be an awkward trade-off § Your configuration management system is not tracking the changes made in the tools – Potential loss of artifact versioning, history, and audit trail – Difficult to enforce, or even monitor, adherence to policies – It might be difficult to run queries and reports on past baselines without extracting the artifacts and reconstructing the data in each of the tools © 2014 IBM Corporation

Product Line Engineering Problems with file-based approach § Why is checking the model into an SCM system not sufficient? § Consider MLMS requirement #1 in the current draft of the MLM paper: – A stakeholder of a Model/Model Element who is not the editor of the entire set of information within the Model/Model Element needs curated information within the model in order to make decisions or present definitive information to other parties. § This is difficult to achieve with the model checked into an SCM system. The model information is encoded in the files in that system, but probably not in a format understood by that system. Queries and reports probably will not work directly on those files. § Consider a stakeholder who placed one or more user requirements, and wishes to verify that the requirements have been linked to the right model elements in last month’s baseline. The stakeholder may need to be able to check out the model files and load them back into the modeling tool, but - not being the author - he or she might not have the skills, knowledge or tool access to do this. Even if you refine the granularity of the Configuration Items (the files in which the model elements are stored), does the configuration management system reflect the links between model elements and other artifacts? If not, how can the stakeholder make informed decisions on whether or not the model is aligned with the requirements? © 2014 IBM Corporation

Product Line Engineering Single Repository approach § Keep all artifacts – not just models – in single system – Ideally one with built-in versioning or configuration management Problems § This is extremely difficult to achieve, since most engineering organizations use a vast range of tools, not all from a single vendor § Almost impossible to sustain in the presence of mergers and acquisitions § And even if it were technically possible, it is likely to be unacceptable for cooperating but separate corporations © 2014 IBM Corporation

Product Line Engineering Linked Data approach § Allow use of multiple tools from multiple vendors (best of breed) § Use the web-based linked data approach to allow access to the data in those tools – Make each artifact a web resource – Have an http URL for each resource – Provide an RDF representation of the artifact – Link to other artifacts using their URL § Web protocols provide an open and scalable architecture with a proven track record – Including clustering, caching, etc. § Allows loose coupling of systems – Tools can be upgraded independently – Links between different corporations (vendors, partners, etc. ) © 2014 IBM Corporation

Product Line Engineering Open Services for Lifecycle Collaboration (OSLC) § OSLC takes up the inked data approach, and extends it § Defining standard RDF vocabularies for common domains § Defining machine-readable (tool/client readable) descriptions of the representation of artifacts § Contributing basic protocols and principles to the W 3 C Linked Data Platform § Much OSLC work is now transitioning to the better-know OASIS standards body © 2014 IBM Corporation

Product Line Engineering Linked Data approach (continued) § Allow use of multiple tools from multiple vendors § Use the web-based linked data approach to allow access to the data in those tools § Extend those tools to support multiple versions, including parallel variants – Is there a difference between time-based versions and parallel variants? Systems differ. § Extend linked data protocols to handle multiple versions and variants – RDF representations of versioned data – How do we represent links to and from versioned artifacts? § Introduce capabilities to aggregate configurations across multiple cooperating configuration management systems These are some of the topics of the current OSLC Configuration Management effort; the driving scenario for this workgroup is the establishment of cross-domain, cross-tool baselines. Of course, model management is one of the important domains to be covered. © 2014 IBM Corporation

Product Line Engineering OSLC Configuration Management § Define linked data approach to versioned data and configurations – Every tool adopting OSLC Config Mgmt would comply with these requirements § Allow, but do not require, configurations to contain sub-configurations – Some tools allow aggregation of their own configurations as a native capability – Perhaps limited to a single level of sub-configuration, or perhaps allowing a hierarchical § Define a set of protocols for aggregating configurations from an arbitrary mix of contributing configuration management systems – Allows a hierarchy of ‘global configurations’ with contributions from various tools – A global configuration has sub-configurations, but probably no other configuration items Consider a car: you might have a top-level global configuration for the whole car, with member global configurations for each of the major systems such as drive, infotainment, etc. , and then domain-specific contributed configurations within each of those – such as drive requirements, drive models, drive test cases, etc. © 2014 IBM Corporation

Product Line Engineering Simple data model (not yet final) Configuration Change set? 1. . * Component 0. . * unless stated otherwise (though specific tools or policies may suggest or enforce other cardinalities) Configuration Item OSLC Change Request © 2014 IBM Corporation

Product Line Engineering Global configurations for a car Car XLT 2014 Drive Requirements Drive System Infotainment Drive Designs Drive Test Plans Model element 1 Model element 2 Model element 3 … Global configurations Requirements Management tool configurations Model Management tool configurations and CIs Quality Management tool configurations © 2014 IBM Corporation

Product Line Engineering Not in scope for first OSLC Configuration Management specification § Complete management of versions within configuration management tools – We do not address when or how versions are created (or deleted) – We do not specify how parallel development is handled § Top-down creation of cross-tool baselines – Questionable if this would ever make sense: in how many organizations does one person have the authority to create a baseline for all artifacts in all tools? Even if such a person existed, is the lifecycle and workflow such that all tools would be ready for a baseline at exactly the same time? § Process management, subscriptions, notifications § Still under discussion: – Access control (probably not in scope) – Change sets, for integration with OSLC Change Management and use in queries and reports – Branching is in scope, but merging will probably be deferred to a second phase © 2014 IBM Corporation

Product Line Engineering Challenges with Linked Data approach § Gaining critical mass – We need tool vendors to adopt not just OSLC, but the nascent Configuration Management specification § Technical challenges – URLs for versioned data, links between artifacts, consistent navigation in context of configurations – Handling of variants – Handling of version skew – How many versions to keep? – But many of these challenges are not unique to the linked data approach © 2014 IBM Corporation

Product Line Engineering OSLC Configuration Management - status § OSLC workgroup led by Nick Crossley § Still in the early draft specification state § Some work underway in IBM to produce a strawman implementation of aggregated configurations § We expect the specification work to become part of the OASIS CCM TC, just now in the process of forming § And hope to have a specification in the equivalent of the OSLC finalization state later this year © 2014 IBM Corporation

Product Line Engineering Questions? Thank you for listening! © 2014 IBM Corporation