Session:ADLs--Discussions

From WICSA Conference Wiki

Jump to: navigation, search

Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.

Contents

Attendees

(Please add your name here)

Slide Level Output

(This is the output of our discussion, for the powerpoint slides to be given to Mary Shaw)

Why are ADLs not used in practice? Can we distill what we have into a more concise list?

  • Restrictive
    • They make assumptions that may not match the actual systems
      • eg, functional is all that matters in modern adls, but for some the deployment view is all that works.
  • Single Views
  • Lack of domain focus
  • Lack of a "roll-out" plan
    • Align with trends
    • AKA Technology transfer
  • Simple tool support
    • But this is something that a large amount of effort has to go into to encourage people to use


What would we change to make ADLs work?

  • Specialize generic languages
  • Technology transfer
  • Linkage to Technology
  • Simple tool support
    • Visio, Eclipse and MagicDraw for instance.
      • Tools should support communication amongst the architects and the developers
      • Graphical representation in important: ADLs right now a often textual only
  • User studies seem like a good idea
    • Do ADLs actually support parts of the architect's work cycle?
    • Question/Answer sessions between researchers an practicing architects
  • Align with trends
    • Get into the existing communication chanels
    • Appeal to what the developers/managers are interested in

Feedback from presentation: Mary Shaw pointed out that there was another question we didn't ask: What is the payoff from using ADLs? Our two questions jumped from analysing the causes of the "problem" of their non-use, to assuming that ADLs are the solution. We might want to consider addressing this in the summary. Was it was the sense of the group that the value of ADLs to practicing architects was still an open issue; one that we could address via "user studies"?


Discussion questions

  • Why are ADLs not used in practice? Or are they?
    • Single View
    • No domain focus
    • Formality
    • Constraints
    • Verbose
  • What should an ADL do?
    • Comprehension for managers and programmers
    • Communication, related to comprehension
    • Scalability
    • Extensibility
    • Have a rich vocabulary, you can only say so much with boxes and lines when so many ideas are floating around on the screen
    • Trace-ability, linking with code
    • Support for evolution
    • Helpful for trade off analysis, security, other ilities
  • Where are ADLs useful?
    • Toy/Small case studies
    • Quality specific analysis
    • Automotive
    • Weapons
  • Is UML an ADL?
    • Most say no
    • But people are using it for Arch description whether we like it or not
  • What would make UML a good ADL? Or an ADL that compiled into UML?
    • True extensible meta model
    • Can UML conveniently express the styles in DMA?
    • A variety of representations
    • Domain specific concerns
    • First-class views
  • What is the purpose of an ADL?
    • If it is to analyze then maybe can rule out UML
    • If it is for documentation then perhaps we can improve upon UML.

Pre-session Discussions

  • Discussion with Paul Clements about somehow joining the ADL session and the documentation session. We may do two papers and then join together for some sort of discussion to share what we have learned.
    • They will talk about "how do ADLs help."
    • We will talk about how documentation fits in the overall scheme.

Session Minutes

  • Woods
    • Thanks for coming, I am running the session. Paul is running a related session on documenting soft archs, so we will do sort of a joint thing.
    • We will do two papers today and two tomorrow morning.
    • Mary Shaw tomorrow will briefly report back with all the working groups. I need someone from this session to be there in order to give some of our results to Mary Shaw
    • Owen and Nels will be our Wiki help here.
  • Today's two sessions
    • Dos Santos'
    • Pelliccione's

An MDA Approach for a Multi-Layered Satellite On-board software architecture

  • Walter Dos Santos
    • Phd student at ITA Brazil
    • Systems engineer at INPE in Brazil
    • We see one of the satellites used for atmospheric research
    • introduction, then background into satellites, talk about on-board software, going into UML real-time modeling
      • This was assigned to an ADL session, most other papers talk about connection between ADL and UML. ON this paper he uses UML almost exclusively with rt extensions.
      • Model-Driven architecture
    • main problem of software today: there is much complexity
    • space projects are no different, we have highly complex software, space uses a lot of software and it create much complexity
    • as project evolves we have problems getting new things into the system
    • they used UML for a model-driven arch
    • satellites have payloads, like a data-collecting unit
    • also scientific payloads,
    • There is an on-board computer that communicated with the payload via tel-commands
    • the onboard software is a special kind of rt system
      • they must do things within time constraints
    • the software has OS and application software
    • requirements
      • functional
      • QOS
    • UML using rational rose real-time
    • it provides abstractions for documenting the arch through implementation
    • How did we use model driven arch?
      • they used RUP approach, 4+1 views
      • stakeholders can share domain knowledge
    • used a multilayer software architecture based on GOA, this has been used in the auto industry
      • Physical Layer
      • OS
      • Command and Telemetry
      • Application
    • RECAP
      • in space, is is important to create multi view architectures so the various stakeholders can share their knowledge
      • MDA is considered in a broad sense, code is semi-automatically generated, helps for complex formal analysis
      • it allows round-trip engineering
      • Rational Rose RT was an enabling technology
  • Questions
    • What is the formal analysis used?
      • they modeled the capsules that were then mapped into threads. Threads could then be simulated step-by-step to evaluate deadlocks, other rt constraints
    • What is the contribution of the work?
      • For the space area, these techniques are not often used, MDA on a real project is somewhat of a contribution. Project is ongoing without solid results

Dually: Putting in Synergy UML2.0 and ADLs

  • Patrizio Pelliccione
    • the purpose present a new adl that works between adls and Uml
    • we found problems with both
    • conclusion
      • ADLs are not used in practice
      • no one really knows industrial examples of ADLs in use
      • problem: each adl focuses on one kind of analysis
    • supposed we want to model a certain arch and we are interested in deadlock
      • we must used one adl focused on deadlock analysis
    • now we are interested in performance
      • We must model our system in another ADL, there isn't an adl that does many different types
      • if we find an error in performance, the deadlock model must be changed and then reanalyzed
      • there is a lot of iteration
    • another problem:
      • too formal
      • doesn't support the entire life cycle
      • requires knowledge of languages
    • UML on the other hand
      • de-facto standard
      • semi-formal
      • well used for software archs
    • But
      • modeling for documenting is different from modeling for analysis
    • We need an extensible model, hence DUALLY
    • The idea, analyze the adl to find the core elements that are required
    • provide an extensibility mechanism,
    • we need semantic link mechanisms, to avoid the iteration problems
    • Weaving meta models
      • the idea is to used the meta models and override operators, and other meta operators
      • elements on one meta model can be related to elements on other meta models
      • other examples, inherits, renames...
    • the 'woven' model results from these operations
      • Important elements from both are preserved in woven model
  • Questions
    • Can you do all that weaving inside the UML meta-model?
      • Yes,
      • some find the UML meta model to be constricting
      • we need a core and then extension mechanisms on top of that, along with feedback from one analysis to another,
  • Owen
    • A Citation was added to the main WICSA homepage with works that she will be using
  • How many have been involved in defining an ADL?
    • 4 or 5 people
  • Practicing arch?
    • 4 or 5


    • The primitives used, like db, application server, message queues that are used by Eoin aren't in ADLs
    • Didn't catch on because there is a mismatch between how practicing architects do it. NONE of the ADLs have robust support for multiple views. It is ALL components and connectors.
      • We have to write a lot of stuff even for a basic client-server architecture
      • He mostly uses UML but uses it as a drawing tools
    • Everyone expects something different from an ADL
      • Some people want performance analysis
      • Some people want high level abstractions
      • There is an element of domain specificity here. I would like for ex, and ADL per domain.
    • Should we have ADLs for different quality attributes?
  • Where are ADLs useful?
    • For programmers and managers, to learn more about the system from the, does it help with scalability and understandability. It needs to link tightly with the implementation
    • For communication tool between stakeholders, managers, architects, developers
    • It seems like we are revisiting the same things over and over again
    • ADLs tends towards to dynamic now, because currently ADLs have already captured structural usage
    • Current adls with their idea of components and ports almost imposes and architecture on the architecture
      • They all impose something, ports binding interfaces,
    • Toy/Small case studies
      • But they are meant to be used in large systems*** But there is the gap of actually using them in large systems
      • Eoin used them in practice but it was not so great
    • Quality specific analysis
      • Do we REALLY need one for each property? ADLs are written from one point of view,
    • Weapons
    • Automotive
    • There was a tutorial on AADL (this is automotive), came out of work on MetaH from the SEI, it is very nice
      • This looks a structure, performance
      • It's great for embedded, real-time systems. It could be called domain specific. It does schedule-ability, performance analysis. It is also extensible. You can simulate the architecture. It's quite low-level.
    • Weapons systems may need them apparently
      • Why? Maybe for architecture recovery
  • Is UML and ADL
    • Most people say no,
    • But people are using it for Arch description whether we like it or not
    • When we say UML, we are talking about the base language
    • But UML is often used because it is visual, visual notation that is easy to learn quickly is very important. If UML were written as text, it probably wouldn't be used very often.

Mapping ADLs Into UML2.0 using a meta ADL

  • Tahar Khammaci
    • Our system works on OO modeling
    • In 2000 we have begun working on the coexistance of ADL and OO modeling
    • Problems
    • UML is semantically poor but supported by many tools and users
    • ADL has little tool support
    • There has been some work already for mapping other ADLs into UML, Garlan, Medvidovic, Goulao
      • This is all at the meta modeling level
    • Our strategy is to model at the meta-meta-modeling level
    • They map MADL to MOF
      • The ADL meta-model maps to the MOF concept in UML
    • Past mappings have been done manual
    • Here, the pasage from MADL to MOF is well-defined
    • This is simplifies because they are mapping subsets from one to the other
    • The first work was to proposed a meta-model for ADL
      • The principle is everything is a component, they use the 4 layers from OMG
      • When we maped the model to the MOF, the idea was to represent each architectual entity with a subclass of MOF, with the same semantics. If this is not possible we choose a stereotyped subclass
      • Eg, meta-component is mapped to a class
      • For example, Acme, a connector can be mapped to an association or an associationCLass in UML 2.0.
      • Style would be represented by a package
    • In summary, our work is at the meta-meta level. ADL concepts must be mapped to the meta-adl, then to MOF, and then finally mapped into UML 2.0. This creates a mapping from the ADL to the UML
  • Discussion
    • Why would you need to do this?
      • Because we know OO modeling, when we use meta ADL we can reuse our OO modeling experience

Architecture-centric Development for Intelligent Instrument Design

  • Sorana Cimpan
    • We have this ADL, so how did we use it to build a domain-specific environment
    • We've used this ADL for monitoring views at CERN
    • How did we use this to model intelligent instuments
    • The issue is not the design of instruments, but how do you construct the desing environment
    • Intelligent Instruments
      • Requires hw/sw, the software has to be made by the hardware maker, so he is not a software expert
    • Their original language was constructed in a rather adhoc way, they anted to try an architectural approach, so they wouldn't have to rebuild the environment
    • They used ArchWareADL, using architectural styles
      • This languages has no components in connectors but rather pi calculus
    • Components and connectors were actually defined as a style
    • The globa model is a layered approach, but we can leave the instrument designer with not knowledge of software, or at least not being a programer
    • The adl iteself
      • Behaviours compose together
      • Composition, decomposition,
      • Can run on a virtual machine, can be used a programming language at some level
    • Dynamism and Dynamic habrious which nromally were a focus of their adl was not used at all
    • They wanted to generate code for embedded devices
  • Conclusion
    • The language was strongly typed, had information for defining properties and verifying specifications
    • They would generate a style with some core ADL, then use that to generate Java
    • Just by changing the style definition, they wouldn't have to change anything else
    • There was actually some trouble because the tools didn't support generic types and some other ideas, so they actually had to create their own tools
    • Using styles, we have the abbilty to create a domain-specific approach
    • She really believes that ADLs can be useful, specifically for defining styles. Particularly she believes that the tools were not user friendly
  • Discussion
    • If I wanted to define mutliple views, could I do that in this ADL?
      • Behavioral is the de facto view, property view comes from the property specification rules, if we spend some time on having a good interface, then we will be okay.
      • Safety is a relative concept that must be defined first

Second Day Discussion

Why are ADLs not used in practice? Can we distill what we have into a more concise list?

  • Restrictive
    • They make assumptions that may not match the actual systems
      • eg, functional is all that matters in modern adls, but for some the deployment view is all that works.
  • Single Views
  • Lack of domain focus
  • Lack of a "roll-out" plan
  • Simple tool support
    • Products need to be tailored to what the practitioners need
    • But this is something that a large amount of effort has to go into to encourage people to use
    • AKA Technology transfer

What would we change to make ADLs work?

  • Specialize generic languages
  • Technology transfer
  • Align with trends
    • Work in specification processes
  • Linkage to Technology
  • Simple tool support
    • Visio, Eclipse and MagicDraw for instance.
      • VS.net allows you to define model and associate graphical representation
      • Tools should support communication amongst the architects and the developers
    • Graphical representation in important: ADLs right now a often textual only
  • Is it better to use UML as the cocrete syntax and have a product that is harder to use? Or do we want to concentrate on having a really easy to use ADL that then people might not be as willing to document since it wasn't based on UML?
  • User studies seem like a good idea
    • Do ADLs actually support parts of the architect's work cycle?
    • Question/Answer sessions between researchers an practicing architects


How would you publish your research to industry?

  • In france there are dedicated technology tranfer organziations
  • In UK, there are similar organizations, or they do it on a case-by-case basis
  • Instead of worrying about your own methods only, you can dovetail ADLs into existing 'sexy' technologies. For example, roll-out ADLs with agile methods to find the synergies and appeal to developers.
    • As soon as something like an ADL gets into a JCP specification for instance
  • Does the fact that a big name is pushing the idea does that matter?
    • To a certain extent because it makes products compatible

Joint Session with Documenting Software Architectures

Results from Documenting Software Architectures Session

What were their summaries, and topics to pursue

  • Meta-models vs. Views
  • What are the relationships between the architecture and what gets coded?
  • Human factors are involved
  • How do we map between a reference and target arch?
  • Can we do consistency across multiple views?
    • Expert systems?
  • Are ADLs really an effective way to reduce risk?
    • It seems like there may be better ways of dealing with that
    • Why specify if you aren't even sure about anything
  • What are the inhibitors?
  • Why aren't ADLs used?
    • Maybe used by 5-10% of a project
    • Designers and coders just want to see UML, why learn another one
    • Business people don't care to look at it

Results from ADL session

  • AADL has been standardized
    • Is under discussion but maybe not used
  • What about attempts to create systems where you could draw pictures and turn it into code? Is this what we are looking for?
    • Developers tend to really like text, and not graphical notation because they can compile it and check it. But are these two things mutually exclusive?
      • A lot of developers only like pictures in a informal, sketch kind of way
      • They like the code because it's the system, in the ground, running.
    • Developer have had a good experience using Rose class diagrams
      • Eg, a key developer was hired away, and yet because they were using Rose, then a new engineering could come in and take over
      • This is what Marwan's paper will be covering, but there is a lot of other work in this effort

Group Discussion

  • What would make UML a good ADL? Or an ADL that compiled into UML?
    • True extensible meta model
    • Can UML conveniently express the styles in DMA?
    • A variety of representations
      • Textual syntax, for automated tools and analysis
      • Different things can be expressed more or less easily by different forms
    • Why not have tools that compile into UML?
    • Domain specific concerns
    • First-class views
  • What is the purpose of an ADL?
    • If it is to analyze then maybe can rule out UML
    • If it is for documentation then perhaps we can improve upon UML.

Second Day Discussion

  • View packet: Sort of a screenfull of information, a packaging up of a view for sharing of presentation services
    • It seems like typically one diagram is enough
    • Decomposition is largely useful in the module view
    • Do we need more tool support if there really are only 4 or so diagrams will be even used on any one project
    • It often seems like with Open source project, they start off with a core group of people who understand that they might be able to do something better. But they don't do this until they see some other people using the technology. Where is the money? We have to show people that it is useful and why...
      • It would be a great opportunity to get ADLs out there, but is the open source community too pragmatic to be interested in ADLs? Because they are so pragmatic, they would have to be given a compelling reason to use any new technology. So can we do something like that for Architecture? For instance, we hear that people want to have executable ADLs.
      • Eg.) Compelling reason might be regression testing on architecture
      • Making the case to the developers in the trenches.
    • Why can't we save ourselves from writing tons of code when using an ADL.
    • There aren't too many use case studies on using ADL. Asking just what the architects to perhaps limits the applicability of the tool.
    • It's hard to put even the smallest computations into ADL
    • Others say ADL is used as a sketching tool.
    • Integrating architecture and programming language is not necessarily a silver bullet because there is a lot of momentum that goes into defining a language.
    • The point was made that having executable ADLs is really just MDA. This works when the value for getting software out quickly is extremely high.
      • However, if you don't have a physical system that depends on getting the architecutre correct, then you have more flexibility which actually makes the definition of the architecture more important.
    • Is MDA actually executable executable specification not execitable archtiecture? MDA is functional-specification oriented.

Post-session Summary

Post-mortem

Retrieved from "http://wwwp.dnsalias.org/wiki/Session:ADLs--Discussions"
Personal tools