From WICSA Conference Wiki

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

Contents 1 Key ideas 2 Discussion questions 3 Questions that came up during the talks 4 Session Discussions 4.1 State of Practice 4.1.1 Papers 4.1.1.1 Integration Problems of Core Components in a Web Product Line - Rafael Capilla 4.1.1.2 Reflection of Software Architecture Practices - Chung-Horng Lung 4.1.2 Discussion 4.2 Architectural Styles 4.2.1 Papers 4.2.1.1 Vikram Jamwal - Breakable Objects: Bulding blocks for flexible application architectures 4.3 Questions On Paper 4.3.1 Sorana Cimpan - Case Study of Architecture-Centered Design For Monitoring Views at CERN 4.4 Questions on Paper 4.4.1 Rabih Bashroush - Feature-Guided Architecture Development for Embedded System Families 4.5 Questions on Paper 4.5.1 Discussion 4.5.2 Related Questions 4.6 Modelling and Analysis of Software 4.6.1 Papers 4.6.1.1 Jennifer Perez - Coordination in Software Architectures: an Aspect-Oriented Approach 4.7 Questions on Paper 4.7.1 Christian Del Rosso - Dynamic Memory Management for Software Product Family Architectures in Embedded Real-Time Systems 4.8 Questions on Paper 4.8.1 Discussion 4.8.1.1 Concerning Cross-cutting Concerns 4.8.2 Questions 4.9 Modeling and Analysis of Software Qualities 4.9.1 Papers 4.9.2 Discussion 4.10 Discussion the Second Day 4.10.1 Clarifying questions that came up during the talks 4.10.2 Tools 4.10.3 Agile 4.10.4 Documentation 4.10.5 Styles and Patterns 4.10.6 Cross cutting concerns 4.10.7 Modeling Language 5 Post-session Summary 6 Post-mortem

Key ideas

(key ideas, how papers relate to each other and support the session theme)

• key idea 1

Discussion questions

• Other kinds of solutions we should consider?
• What are the successes?
• What are the dead ends?
• What are the promising solutions?
• What are the pressing problems?

Questions that came up during the talks

• How do you deal with performance because it's really tricky?
• How do you deal with the amount of knowledge an architect needs? (Expert system?)
• How do you deal with the amount of domain knowledge an architect needs?
• How can you create architectures that reflect the abilities and strengths of the team?
• Rod's point
• push vs. pull -- do both work?
• application generators vs product lines
• tool-intensive approaches conflict with agile approach

Session Discussions

This section contains notes of the paper presentations and the discussions related to them.

State of Practice

Papers

Integration Problems of Core Components in a Web Product Line - Rafael Capilla

• Maintenance problems in a web product line:
  • Short time to market(impacts maintenance and development quality)
  • Changes in development personnel
  • Big up front modelling not acceptable

• In response set up a lightweight product line for the products
  • Three 3yr programme
  • Core components and web product components

• Problems in 3rd year
  • Lack of documentation
  • Change in staff
  • Pressure from customers
  • New time to market requirements (even shorter!)
  • How to integrate product using the PL
  • How to train new team members

• Comparison of effort between PL teams
  • Two teams, both with undocumented code and basic design information.
  • Evaluated results of the two teams based on project planning documents. Analysed results.
  • Analysis of core assets: 16 vs 31
  • Architecture customisation 4 vs 6
  • Integration tests 25 vs 33
  • Project late by 2 months over 2 years.
• Short time to market is key requirement

• Lessons Learned:
  • Differences in effort in both teams
  • Integration testing may increase depending on number of configuration options needed
  • Documentation of key assets is key aspect to reduce analysis effort by dev team

Reflection of Software Architecture Practices - Chung-Horng Lung

• Output of the Nortel Software Engineering Analysis Lab (SEAL) group from 1995-2001.
• Many techniques used including:
  • SAAM, ATA, QFD, Stakeholder-centric approach, architectural views, architecture recovery, architectural patterns and styles, performance-oriented analysis, architectural visualisation, attribute-driven software decomposition, ...
• Things that worked
  • SAAM and ATA (but scenario coverage can be difficult)
  • Stakeholder-centric approach and QFD (but another skill to learn)
  • Software architecture sensitivity analysis
  • Architecture recovery
  • Views (necessary, but consistency a problem)
  • Performance oriented analysis (but tricky at architecture level)
  • Visualisation (looks great, but expensive)
  • Attribute driven decomposition (looks fine, but not clear that it's needed)
  • Combinatorial theory to scenario analysis (helps to avoid missing concurrent scenarios)

• The gaps in the practice include:
  • Architecture-centric expert systems
  • Generative framework based on well-known components or patterns
  • Architecture and program transformation
  • Ease of use and direct usefulness of techniques and tools

Discussion

• Push vs pull from research to practice is important to consider.
• By limiting the lessons learned to the experience of a single team in a single company, can the lessons learned not be largely influenced by the circumstances (the teams knowledge of the approach, the teams willingness to follow this approach, the specific projects needs, ...)?

Architectural Styles

Papers

Vikram Jamwal - Breakable Objects: Bulding blocks for flexible application architectures

• Motivation
  • Diverse deployment scenarios
  • Need to facilitiate translation of app from one deployment to another
  • Example is email client that needs to support online, disconnected, offline modes.

• New concept is Breakable Objects, the idea being applicable to objects, classes, components, web services etc.

• For a particular interface, some methods are marked as an atomic group ("together").

• Define "split configurations" that break the objects up, respecting the atomic groups of interface methods. This allows an object to be split across a number of deployment targets.

• BODA (the Breakable Object Driven Architecture) is the application development approach to support breakable objects. It includes a Splitting Engine (to break objects based on split configurations), which generates a particular application topology, and a Deployment Engine to distribute the results.

• Case study is an email client supporting online, disconnected and offline modes. Three different deployments are generated by the splitting engine, for for each mode.

• This approach can facilitate refactoring when it is required to support redeployment.

Questions On Paper

• In your analysis of breakable object or flexible application architecture, what were your concerns when you take preference over functions/methods and not features ? Won't feature-oriented breakability be more easily understood and abstracted at the application level ?

Vikram

Any feature based selection has to finally result in appropriate translations to objects/components or methods of objects/components and BoBs. This is the resaon for precedence. Having said that let me say that feature-oriented breakability is a very useful and interesting idea and I would like to explore how it can be implemented.

• How does this architecture take into consideration the dependency issues of different building blocks ? Dependency, I particularly refer to a module(group of functions or interfaces) that depends on another module.

Vikram

The reorganizer takes care of the dependies to a BoB. The splitting engine also buils an Internal Dependency Graph(IDG) to undersand various dependencies within a BoB.

• Do you think this architecture would facilitate and ease the execution of concurrent development of different modules(functions, interfaces or features eventually) that could have been more easily identify as independant and de-coupled ?

Vikram

I think it should. One of the challenges is to design effective BoBs. A good desing guideline (though not a requirment) is to have interface methods as independent as possible. If that is the case, independent develop is facilitated.

• Is this realy an architectural approach? To me it seems to be a flexible code reengineering technique. The same idea could probably be applied on another level (like software architecture) but this is not where the paper is about.

Vikram

It is an architectural approach in my view. The code-reingineering that you mention actually takes place behind the scenes and at a subsequent stage. However, we haven't approached it though, say an ADL. (I would like to discuss it further if you are not satisfied with the answer.)

--> Still it is on a level where all details about classes and operations have to be known and the full source code must be available and the refactoring takes place on this level (the BoB contain which classes will be split on which operations, so all code details are there). So in general I think this is not on an architectural. I think in the perspective of software architecture, the second part of your answer becomes realy interesting, when you say you could apply it on an ADL or on some component language.

• Why decompose (break) objects instead of starting with the pieces and composing them?

Vikram

I would not like to do that. Ya, it is defnitely possible to break the system to finest level of granularity and then to build up from there. However, this results in loosing a lot of architectural information. The way I see it is: Have the objects in some logical form and then also have the flexibility to transform into different sub-objects whenever need be. But, I should agree that composing is an interesting propostion and we are definitely considering it. We call it merging of BoBs - essentially a process by which two arbitrary BoBs (or parts of a BoB) can be combined to produce an entirely new BoB/object/component.

Sorana Cimpan - Case Study of Architecture-Centered Design For Monitoring Views at CERN

• Work is on the particle accelerators at CERN, building the critical control systems that control accelerators.
• Concerns with
  • Standardisation
  • Information selection/filtering for display
  • Requirements capture
  • Need to avoid overloading the views with process documentation

• Project to deal with major breakdown, architecture defined via a set of views. The project was SEAM (Software for the Engineering of Accelerator Monitoring). Aim was to implement a software tool that can support an architecture-centric approach.

• The project ended up being design of a domain specific approach, based on a new architectural style. The aim was to create a vocabulary for the particle accelerator domain, which would make development easier.

• Achieved:
  • the creation of a domain specific vocabulary
  • the definition of the constraints for the style
  • effective enforcement of the style's constraints.

• However they found that achieving easy evolution of the software was more difficult and so the project only partially achieved this.

Questions on Paper

Rabih Bashroush - Feature-Guided Architecture Development for Embedded System Families

• SPL aims to maximise reuse in related systems via comonality and variability analysis.
• 'Feature Modelling' is an approach to help deal with variability in product lines.
• Key view is created from the 'Hierarchical Viewpoint' that shows the options for different features in the PL and the subfeatures that each depends upon.
• The feature modelling provides support for dependencies, interaction, binding time, implementation time, feature/cost trade offs, features that much not be present and so on.
• 4 viewpoint model:
  • Hierarchical
  • Business
  • Dependency/Interaction
  • Intermediate Design
• The approach captures a broader range of information than current PL approaches and the multiple-viewpoint approach is also new.
• The intermediate viewpoint helps to bridge the gap between feature requirements and design.
• A new ADL ("ADL for Industrial Applications" - ALI) has been developed to support the approach.

Questions on Paper

• In your presentation, you highlighted the possibility to provide the different viewpoint models. How is changing the relationship between features using one viewpoint model affects the rest of the viewpoint models ?

• How is each viewpoint model capable of identifying, detecting and highlighting a conflicting modification or change of configuration among the features ?

Discussion

• Tool support is always problematic. For example the project at CERN described by the second paper had the same problems, with CERN unwilling to add more resources to complete and productise the tools.

Related Questions

• Which criteria uses the splitting engine for breaking objects (technical, commercial)?
• How inconsistencies or duplication classes are controlled?

Modelling and Analysis of Software

Papers

Jennifer Perez - Coordination in Software Architectures: an Aspect-Oriented Approach

• Based on PRISMA,an approach for complex software development using software architecture and aspects.
• Architectural aspect is a crosscutting concern across the software system at the architectural level.
• Existing proposals:
  • Aspects as views (each aspect captured as a view)
  • Aspects as connectors (aspects used to "glue" the components together)
• PRISMA defines aspects independently of architectural elements and then import these aspects into the relevant architectural elements (e.g. connectors). Hence a connector contains the aspects for the properties that it requires.
• This has been applied to an industrial robot control system as a case study.
• Further feature is to generate BPEL4WS code
• Conclusions
  • The project provides reusable aspects
  • Ths approach helps to separate concerns inside connectors
  • Connectors created in this way are easier to maintain
  • The resulting architecture better supports "black boxes"
  • Views can be created from the aspects.

Questions on Paper

• In your presentation you sugested there where 2 approaches to modularize concerns in architecture: by using views or by using an connector. In fact there exists a great body of work in AOSD around aspectual components, a special type components encapsulation aspects, very similar to what you presented in your presentation (like Jasco, Caesar, FuseJ, the work of Lieberherr). How does your work relate to it, what are the differences?

Jennifer Pérez

• The differences among these works and PRISMA is presented in the paper "Architectural Aspects of Architectural Aspects" presented in the last European Workshop on Software Architectures (EWSA). In this paper of Carlos Cuesta, the different aspect-oriented models are compared and classified. On the other hand, another difference is the fact that PRISMA is not using a programming language to introduce aspects in components, we use an ADL independent of technology. In this way, using our compiler we will be able to generate aspect-oriented code of software architectures for different programming languages. Finally, the related work about introducing aspects as views or aspects as connectors are those closer to PRISMA because they are extending existing ADLs to provide aspect-oriented capabilities.

Christian Del Rosso - Dynamic Memory Management for Software Product Family Architectures in Embedded Real-Time Systems

• Evaluation and optimisation of architectures requires a lot of knowledge about the domain as well as specific techniques like architecture assessment and performance optimisation.
• This research investigates what is needed to assess PL architectures for performance.
• Performance optimisation in a product family is challenging due to the possible interactions between different members.
• They use a scenario-based approach. Each scenario in a product family situation can apply to all or just some of the family members.
  • Even in cases when the members don't directly share features, there can still be dependencies between them.
  • There is also the complication that a feature can have multiple implementations in a product family.
• Process for optimising memory usage:
  • Select key performance scenarios by working with stakeholders
  • Use a simulator with real execution traces to establish memory usage.
  • Analyse and evaluate the output in terms of size, object allocation/deallocation and so on.
    • This often reveale conflicts between low end and high end products
    • Different techniques needed for each
• The key experience of the case study was that while global optimisations are possible, targeted optimisations are possible and must be considered in order to support the breadth of the product family required.

Questions on Paper

• In your approach where you select key performance scenarios working/holding discussion with stakeholders, how do you ensure that the mainstream of the architecture is maintained and its evolution into its next generation is not overly influenced by a particular business-driven needs of the stakeholder ?

• Answer, Christian:

Scenarios set the focus of the analysis. Key performance scenarios represent the features which influence the most the performance of the system. And yes, the process considers also the business importance of the features. However, the analysis process includes the impact of the changes to the current architecture and the analysis of the tradeoffs in implementing the changes and the optimizations between different quality attributes (performance vs. maintainability). Especially when dealing with product family architectures, the analysis of the tradeoffs is fundamental. The performance of all or a subset of the products in the family are considered. The performance of the products in the family must not be penalized by optimizations made to a subset of the products.

Discussion

Concerning Cross-cutting Concerns

AOP has not really convinced me, but it really pinpoints a very important issue. Cross-cutting concerns are something really important, that should belong at the architectural level - it involves early design desicions with large impact, typically implement some system-wide policy, is in practice the responsibility of the architect etc. But how do we model these things architecturally?

Often, a "concept" in the architecture, or a "concern" if you like (I can find no better term right now), seems to have at least two dimensions: 1) A component embedding some functionality for this (e.g. a logging component, and error handling component, some central guy allocating resources such as threads, memory, files, etc. on request), and 2) some system-wide policy on how to use this component. Perhaps much of these policies could be enforced by static checks of the source code, but even more important are things you are _not_ allowed to do (e.g. open a file whenever you like, allocate your own thread) - and these types of things are much harder to check.

Questions

Modeling and Analysis of Software Qualities

Papers

Discussion

Discussion the Second Day

Clarifying questions that came up during the talks

Post questions and answers on the wiki.

Tools

• tool-intensive approaches conflict with agile approach

term agile isn't as accurate as evolutionary if this is a one off project then investment my not be necessary

Disagree with premise of question. Agile people use tools but won't do anything that doesn't lead to a running system. But they definitely use code generators. Eclipse, J2EE application server

Clarification by speaker: domain specific environment that we can easily evolve at architecture level. Focus was on application. Also, the environment needs to evolve.

Q: is environment (i.e. tools) relevant? Proof is in the use. If they are not maintained with the running system then that could be an indication that they are no longer relevant.

Where these tools conflicting with the agile process? If you ain't gonna need it you don't do it unless, until you need it. Investing into application generators is seen as unneccesary. Unless you do the same thing for several systems then the investment may be made.

Agile

Japanese tranlsation example offered by Jim Highsmith at Steven's Lecture. Forethought by smart designer to build in points for change. Enough architecture upfront. Also successful project that combined agile and CMM.

Grady Booch keynote: grow an architecture through iterative and incemental release of an architectcure.

What is the penetration of agile methods in architecting? Jim McGovern (and Scott Ambrose) is crusader for agile architecture. Applying agile to enterprise architecture. Barry Boehm has looked at balancing agility and discipline.

Scott Ambler - article on architecture and agile. Architect must also wrote code. discuss with developers and be part of the team. http://www.agilemodeling.com/essays/agileArchitecture.htm

Experience from session member - team lead, write code 50% of time. Hybrid techniques, some RUP, vertical slice, preliminary architecture. Each iteration the architecture will evolve and adapt.

Are there problems with scaling in terms of number of developers? Any large system will have a divide and conquer approach. COntracts between the groups and interfaces becomes more important. The architecture can facilitate this. Design can be crucial to help communicate and bridge barriers of culture, time zones, etc. Is open source development a different paradigm?

Which views are important for agile development?

Booch - you don't perceive all of the system at once? Put something in place and try it out, and refine.

J2EE is an architecture in itself. When you apply J2EE you get architecture by default. -> is it an architecture or something else? An infrastructure, a style. Once you have chosen J2EE you have a collection of predefined architecture decisions.

How does evaluation differ in plann driven vs agile? Agile is test driven

Complexity and uncertainty. Compleity -> more time on structure uncertainty -> agile

Experience with 2 projects:

1. Nortel project, replace call processing system with new system. Complexity is very high, team of 4 architects. Requirements are well know so plan-driven approach is appropriate.

2. New project, uncertainty is high. Product line manager, talking frequently with customer. No lead architect. Didn't have the term "agile" at the time but that is what they ended up doing.

agile approaches may help architect assess impact of the architecture

other techniques (iterative construction, formal modeling tools) can be supplement intuition

• changing 10M LOC assets (e.g., porting platforms) introduce problems of scale - are there other paradigms that can help? Such as MDA? Even though you are not locked into platforms, you are locked into the modeling language.

Perception, architecture and the system are the same. There maybe conflict where they differ.

Bad architecting processes will produce a brittle system whether you are agile or plan driven.

Can agile be used for safety-critical system? See Cockburn table or Boehm 5 dimensions that show where agile is appropriate.

Agile Methods intersecting with architecture

Major points:

• there is no fundamental conflict
• you can do enough architecture for the problem at hand and that is a judgement call
• agile covers a wide spectrum

Documentation

Can code take the place of the documentation? Grady Booch raised some issues that need to be documented such as rationale, why is this written in Java?

Do we need more work on representations for architecture? Is what we have good enough? We are practicing architecture in a context. The processed tends to be heavy-weight documentation or none at all.

Jim Highsmith. Documentation as ditigal photos of note cards and flip charts. Experience: difficult to understand how they are connected. Need to create an additional flipchart explaining relationships and photograph that.

Is there an agile version of the "Rational Design Process" (Clements and Parnas)? Process is messy so you need to go back and make it clear for others to understand. Recreate thought process that got you where you are in a concise means. It depends on what you want to do with it. You don't have time to got back and recreate complete history. You need a snapshot.

Booch - architecture archeology. Usually things are not written down.

Even if you have a formal specification, can you really understand it without talking to the architect? There is rational and context that needs to be recreated.

Ideal documentation is the person? Descriptions help, provide vocabualry. Even the architect needs to go back to the documentation to understand why certain decisions were made.

Tools can help but we don't know enough now how to create one.

Can we just tape everything? In certain contexts it can help such as introducing new people to a project. However, it brings up new challenges in retrieval.

How many views do I need? Sometimes it is not clear. Documenting Software Architecture: V&B - analyzing stakeholder needs to determine appropriate views to document.

Styles and Patterns

Booch - patterns are important for organizing architectures. Standardized component models and styles.

Benefits are vocabulary and educational training. Everyone know value.

What about MVC? There are so many manifestations does it lose its meaning? Controller can be implemented in many more concrete patterns. Appropriate in different viewpoints. Architectural tactics focus on resolving a single force and can help understand patterns.

Cross cutting concerns

Many concerns are not captured in components and structures. They are cross cutting. They many be rules, policies that need to be inforced (error calling conventions). There will always be things we cannot localize in the code but are spread throughout.

What is the role of aspects in architecture?

In general there are different types of concerns: The ones you can modularize and the ones you can not. E.g. Performance is damm hard to modularize in a component (or an aspect). These need to be documented if they cannot be represented in the structure.

Idea of perspectives (Woods, Rozanski) is a good idea to handle cross cutting concerns.

If you can't verify a requirement it shouldn't be a requirement. Is there an analog in the architecture. If we can't measure a constraint, should it not be made?

Parasoft- sophisticated static analyis of source code.

Need an architect that is also developing, there will not be a problem since he or she is part of the development team reviewing designs and code. But does this start to be a heavy-weight, enforcement type of approach.

Emphasis should be measurement (giving guidelines and holding people accountable) and not on enforcement.

Architects are first among equals. They have an investments in seeing ideas and team succeed.

Aspects need to be pulled in architecture description. They are successful in certain domains (such as error handling). Need more experience on how to handle this for big systems.

Performance - difficult but we know how to deal with it. There are abstractions (tasks, processes) that help and difficulties are that we don't know the parameters (e.g., delays).

Modeling Language

Would like a unified architecture modeling langauge. UML doesn't work. May need separate langauges for different domains (e.g., EAI patterns). They should be highly domain-specific. Such a language needs:

• messaging, shared memory, semaphores
• components

UML is code description more than architecture description. Many students use UML as a high-level description langauge

Post-session Summary

• TODO

Post-mortem

• TODO