A formal approach for fostering component reuse and managing - PowerPoint PPT Presentation

A formal approach for fostering component reuse and managing software change Abderrahman MOKNI, Marianne HUCHARD, Christelle URTADO, Sylvain VAUTTIER et Huaxi (Yulin) ZHANG SATToSE 2014 1 11/07/2014

Context and problematic  Component-based software engineering (separation of concerns, software in the large, complex systems, …)  Reduce development time and costs,  Reduce maintenance costs (usually takes 60%).  Challenges:  A better reuse,  A better evolution handling (unanticipated changes),  A better software architecture documentation. => Need for formal mechanisms to improve software reuse and automatically handle architectural changes. SATToSE 2014 2 11/07/2014

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 3 11/07/2014

Definitions  Software Architecture: blueprint of the software system (design decisions, strcucture, interactions).  Components: encapsulates data and functionalities.  Interfaces: abstraction of component services (required and provided).  Connections (connectors): connect components to each other. SATToSE 2014 4 11/07/2014

The reuse approach [Zhang 2010] Component design for reuse Component-based software design by reuse Lifecycle step Production Lifecycle step Production Component System requirement development and analysis documentation Functional & non- Component code & models functional requirements Component code Architecture storage and specification indexation Abstract architecture Component repository Component description search Architecture configuration Concrete architecture Component description instantiate Caption: Instantiated Uses component assembly Produces Instantiated assembly description & software Precedes 5

Architecture levels  Specification level  Architecture as intended by the architect and conform to user requirements  Component roles : partial and ideal description of software components  Used to guide the search for concrete components.  Configuration level  A concrete implementation of the software  Concrete component classes selected from repositories  Assembly level  Description of the architecture at runtime  Parameterized component instances SATToSE 2014 6 11/07/2014

Running example : Home automation software ILight Interface types and their signatures: Light lLight { void switchOn(); void switchOff(); } Time ITime { ITime HomeOrc int getTime(); } hestrator ITherm { Thermometer int getTemp(); } ITherm ICon { void setCondMode(CondMode mode); CoolerHeater CondMode getCondMode(); ICon } Caption Component role Provided interface Required interface SATToSE 2014 7 11/07/2014

Configuration level lPower Interface types and their signatures: Lamp lPower { lIntensity void switchOn(); IClock void switchOff(); AndroidOrc } Clock hestrator IIntensity { void setIntensityLevel(int intensity); ITherm int getIntensityLevel(); } IClock { AirConditioner void setDateTime(int time, Date date); IAirCon int getTime(); Date getDate(); AirConditioner composition } ITherm ITherm { ITemp ICon int getTemp(); Thermost CHEngine } at … … Caption 8 Component class Provided interface Required interface Delegation link

Assembly level Caption Component instance Provided interface airConditioner Required interface 1 lamp2 clock1 lamp1 androidOrchestrator1 SATToSE 2014 9 11/07/2014

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 10 11/07/2014

The formal approach  Formalization based on set theory and first-order logic  B modeling language  Generic concepts: architectures, components, interfaces, signatures, …  Specific concepts: specification, configuration, component roles , component classes, …  Invariants. SATToSE 2014 11 11/07/2014

Example 12

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 13 11/07/2014

Intra-level rules  Substitutability rules  Syntactic definition of signatures (name, types, parameters),  Interface typing with respect to covariance and contravariance rules,  Interface substitutability,  Component substitutability.  Compatibility rules  Between interfaces,  Between components. SATToSE 2014 14 11/07/2014

Example ILanguage IlocationAndGMT getLanguageInfo(): String getLocation() : Point Clock getGMT() : TimeZone ISetting setTime(Time time) setDateFormat(SimpleDateFormat format) ISettingV2 setTime(Time time) ClockV2 ILocation setDateFormat(DateFormat format) getLocation() : Point IInfo getTime() : Time getDate() : Date getDateFormat() : DateFormat Légende DateFormat Component substitutability Interface substitutability Interface subtyping SimpleDateFormat 15 inheritance

Consistency and completeness  Based on the compatibility between interfaces  Consistency:  Correct connections between components,  Connected architectural graph (no isolated components).  Completeness (internal):  All required interfaces are connected SATToSE 2014 16 11/07/2014

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 17 11/07/2014

Inter-level rules Component Abstract architecture role specification <<realizes>> <<implements>> Concrete architecture configuration Component class <<instantiates>> <<instantiates>> Instantiated architecture assembly Component instance 18

The realization rule  Many-to-many relation,  A component class may <<realize>> several roles at once,  A roles may be realized by composing several component classes. => more flexibility while searching for implementation solutions. SATToSE 2014 19 11/07/2014

The realization rule SATToSE 2014 20 11/07/2014

Example I2 Interface typing: sig3 R2 I1 I2 I3 J1 J2 sigB I3 J2 I J sig4 R3 I1 sig1 Signature matching: sig2 R1 sigA sig1 <- > sig1’ J1 sig2 <-> sig2’ sig3 <-> sig3’ sig1’ sig4 <-> sig4’ sig2’ sigA <-> sigA ’ sig3’ sigB <-> sigB ’ I sig4’ sig5 C1 sigA ’ SATToSE 2014 sigB ’ 21 11/07/2014 J

Coherence between a specification and a configuration  A configuration <<implements>> a specification if and only if:  Every role in the specification is realized by a component class in the configuration,  All the specified services in the specification are met in the configuration. SATToSE 2014 22 11/07/2014

Coherence between assembly and configuration  <<Instantiates>> is a many-to-one relation.  An assembly is an instantiation of a configuration iff:  Each component class is instantiated at least once,  Each instance in the assembly is an instantiation of a component class in the configuration. SATToSE 2014 23 11/07/2014

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 24 11/07/2014

Architecture-centric evolution  A process to evolve software system by modifying its architecture.  Issues:  Inconsistencies: (name, interface, behavior , …)  Architecture erosion: integrating architectural changes that violate higher level preconditions.  Architecture drift: integrating architectural changes that are not considered by the higher abstraction level. SATToSE 2014 25 11/07/2014

Evolution rules  Change operations guarded by preconditions,  Three main operations: addition, deletion and substitution,  Defined at:  Specification level to update user requirements,  Configuration level to update software implementation,  Assembly level to change software dynamically.  Change can be initiated externally or triggered by the evolution manger. SATToSE 2014 26 11/07/2014

Example of evolution rule (Instance addition) SATToSE 2014 27 11/07/2014

Evolution process 28

Outline  The reuse approach  The formal approach  Intra-level rules  Inter-level rules  Evolution rules and process  Conclusion and perspectives SATToSE 2014 29 11/07/2014

Conclusion  A formal model for multi-level software architectures,  Intra-level rules to ensure architecture consistency,  Coherence rules between architecture descriptions,  Evolution rules to automatically handle software change and avoid architectural mismatches. SATToSE 2014 30 11/07/2014

Perspectives  Implement an evolution management environement within an eclipse-based platform,  Study and manage software architecture versioning,  Implementing a case study. SATToSE 2014 31 11/07/2014