Session:Documentation--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

Working Session Participants

Migration of Supervisory Machine Control Architectures

Slides Presented by Bas Graaf

  • Reuse knowledge in legacy finite-state designs
  • Activities are modeled as tasks and behaviors
  • FSMs specify designs at design time
  • Transformation rules
  • Mapping between source models and target models
  • Defining meta-models and explicitly thinking about transformation
  • Decrease need for experts
  • In future work, define transformations more formally
  • Question: how do you represent failures and other exceptions in operation?
    • Not yet considered.
  • What language is used to implement the transformation?
    • Using ATL (OCL-like language to specify transformations, comes with execution engine)
  • Discussion:

Bridging the Concrete and Logical Domains for Software Architecture Reconstruction

Slides Presented by Christian Del Rosso

  • Key idea: bridge the concrete and logical views for software architecture reconstruction
  • Reconstruction:
    • Obtain documented architecture
  • Reconstruction is view-based
  • Reconstruct the target view from the source view
  • Additional information extracted from available documentation
  • Question: What kind of documentation?
    • Informal documentation: most of the time cannot find descriptions in ADLs; find any informal documents (e.g., Powerpoint slides).
  • Mis-match between the source view and the target view
  • In the target view, we're trying to reconstruct the logical and runtime dependencies
  • Outline the reference framework for viewpoints
    • At the lowest level, implementation viewpoint
    • Code viewpoint, use Abstract syntax tree/graph (AST/ASG)
    • Design viewpoint: class, method, etc.
    • Architecture Viewpoints: modules, components
  • The Case study
    • Defined target viewpoints:
      • Component viewpoint: addresses the static view of the system
      • Organizational viewpoint: how the organization will develop the software
      • Task viewpoint: task = contains entities (client or server or ...)
      • Development viewpoint: physical files and class and methods found in the source code.
    • Source viewpoint:
  • Question: is this a viewpoint or a meta-model of a viewpoint?
  • Observations:
    • Big gap between the reference design (FAMIX) and architecture viewpoints
    • Question: What is missing? What would help you do that?
  • Reference architecture viewpoints too generic and open to various interpretations
  • Reference design viewpoint: cannot extra things like organizational structure from the source code
  • The reference framework still needs some work.
  • Linking between the logical and concrete domain is manual
  • This can help us define more specific viewpoints.
  • Questions: that the architecture views that we wrote about were not sufficient?
  • What do you main by DSA? That's a style within the category.
  • The recovery process is still heavily manual
  • What is the gap?
  • What does the FAMIX model look like?
    • Some of the entities in there seem to fit on an architectural diagram; others, don't seem like they belong on an architectural diagram
    • It's really just a generic schema for a cross-reference file
  • You cannot get a lot of things automatically; cannot get the abstractions
    • Have to ask the expert what is important.
  • Cannot get organizational things, cannot get deployment.
  • You can develop some heuristics: find things with a high fan-in; this may lead you to an abstraction.


The ADOV Method: an Experience in Selecting the Relevant Views of an Architecture in a Small and Medium size Enterprise

  • Slides Presented by Gentzane Aldekoa
  • Open set of views
  • Select from set of view most "useful" views for a given company
  • No dedicated architect role -- maybe why architecture never gets documented
  • Most "useful" views for that project were:
    • Module
    • C&C
    • Allocation
  • Useful view selection is crucial
  • Different levels of abstraction in the same view
  • Documentation aligned with different goals
  • Discussion
    • We will have to evaluate the benefits of documenting the architecture
    • We plan to keep up with them for a few years and see how it evolves

Semi-Automated Incremental Synchronization between Conceptual and Implementation Level Architectures

  • Slides Presented by Marwan Abi-Antoun

Discussion:

  • What is the difference between ArchJava and module interconnection languages?

Discussion questions

  • Is view = model?
    • Or is a view much more than a model?
  • Viewpoints vs. meta-models
  • Enforcement
    • Traceability between the architecture and the code
    • Part of the practice that is still missing
  • Experience of people in documenting or extracting architectures
  • Human factors in reverse engineering
  • We have a clearly documented reference architecture for our product line; how do we find the thin line between reference architecture and target architecture?
    • Mapping between reference architecture and target architecture
  • What kind of tooling is useful for doing this
    • Forward and reverse engineering
    • What is the connection between tooling and mulitple views and viewpoints
    • Can a tool check consistency and completeness between multiple viewpoints?
  • Can we have an expert system help us with specifying and documenting architectures?
  • Why don't architects document?
    • Too costly do make complete specifications
    • How do you do up-front architecting and agile/iterative methodologies
    • How do we cope with uncertainty?
  • What are the inhibitors to documentation
  • Domain-specific tailoring
    • Define your own viewpoints; but it's not an easy thing to do.
  • Can ADLs help with anything?
    • Grady Booch remarks that ADLs are not used in practice
    • Without tool support, ADLs are no better than Visio
    • UML is incorporating concepts
  • In practice, managers don't care about formality at the design level
    • Want to be quick, and expressive, not rigorous. Whereas
    • Languages don't compile, don't support simulations, cannot be enforced
    • If enforcement can be supported, that may be in favors of using ADLs
  • Tracing architectures to code
  • During the greefield stage of the architectural work, things are too fluid
    • Specifying in great detail is not worth the effort if they're going to be changing a lot
  • Better support for Entity-relationship support notations
  • Run for checks, consistency and completeness
  • Economics for tooling for architecture
    • 10% of people on a project are going to be writing architetural document
    • architects talk to management; management is not interested in learning about ADLs
  • developers have their hands full UML and do not want to learn about ADLs
    • ADL is going to be like a flea on the tail of the dog
  • ADL is like any documentation; not write-only.
  • Developers may find them useful to read
  • Formalism happens on the things that we have to compile.
  • We used Rational Rose to draw architectural diagrams
    • Map that manually to a shared rose model used for development
    • Classes in the rose model that precisely corresponded to boxes in the architectural model
    • Why couldn't it be formally enforced?

Note: We joined with the ADL working session

  • Where are are ADLs useful
  • Combination of things where they might be useful or where they should be useful
    • Small academic case studies? We hope not. But they're really meant for large systems
    • Quality specific analyses
  • Useful for system comprehension
    • AADL: for automative systems (controls-system centric)
  • Coverage of AADL is structure, concurrency and performance
  • Why aren't they useful?
    • ADLs are single-view focused (most of them towards the runtime view); whereas architects typically use multiple views
    • They tend to be too generic; whereas architects want to deal with "entity bean",
    • Usability tends to suffer
      • but we have architectura modeling environments
      • Developers tend to be allergic to graphical notations
      • Developers prefer to deal with the code, because it "compiles"
  • Visual ADLs cannot have a rich enough vocabulary; you ultimately run out of different colors, or arrows.
  • If the diagrams are compilable, or disconnected from the code, their value descends rapidly
  • Have the code back ties to the picture; so you can change the code, and later synchronize them
  • Can 80% benefits for 20% of the work by focusing on the module views, and tring to get those connected to the source code; in selected cases, take viewpackages and map them precisely to correspond. elements in the module view.
  • But all ADLs are about components and connector views. You can do today all the module view stuff in UML; we don't need a new language for that.
  • UML only supports module views at the level of classes
    • UML components, UML packages and UML classes can be used to reprsent module views
  • Doing up-front design in UML is resented by developers, because they think they lose control
    • This goes against agile techniques
  • Vast majority of developers today use some parts of UML; not all diagrams
  • We need to dethrone UML about the de-facto language for describing architectures
    • UML does not know about connectors, layers, ...
    • It's not likely to be dethroned
  • What would make UML a good descriptoin language?
    • An extensible meta-model
      • Kinds of extension: connectors, security policy
    • Can UML conveniently express the styles in DSA?
      • Sometimes it was awkward, sometimes it was easy
    • Textual syntax; a non-graphical notation
  • Underlying issue
    • Different things are expressed better in different notations
    • If you want a human to understand it, you have to represent it as a graph
    • If you want a program to understand it, you have to represent it as text
    • Code generation from UML state diagrams is doomed
  • Can we compile language X into UML and treat UML as the assembly language for architectures?
    • Are we going back to domain-specific architectures?
      • We often come up with project-specific domain-specific styles
    • Why cannot we go back to the Meta-Object Facility (MOF) level
  • In the early versions of UML, there was no specification of the relationship between one diagram and another
    • UML 2.0 still lacks first-class views;
    • UML needs to have graph transformations, etc. to keep views synchronized, condensation, ...
  • A critical issue is the notion of containment (part-of relationship)
    • We can represent component types as UML stereotypes?
    • The interchange language can never exchange the semantics
  • Typed attributes can allow you to pass the semantics
  • What is the goal of ADL Is it just to document? Or to analyze? I still haven't heard an answer.
  • How to bridge the gap between the people using documentation; how to get them to do documentation
    • Promising them to do things once you have a documentation is useful
  • Case study documented by Gail Murphy involving Excel
    • What made the architectural description useful
      • Developer could chose the abstraction relevant to his particular task
      • Tooling support told him what the connections are; tool support let him iterate on the module view
      • Helped the developer figure out the feasibility of the task
  • Just in time documentation
    • How do I know what to produce now
    • Need architectural information as you go
    • De-emphasize whole complete package
      • Agile documentation
        • Will they scale? Agility and scale complexity are not mutually exclusive
  • What to produce-now is based on what you are doing now
    • Task-based documentaton
    • Cannot do completely "just-in-time": if the goal is to protect the architect from geting hit by a bus
    • Does documenting the architecture really protect the project from having the architect run over by a bus?
  • If a document is produced, but not reviewed, does that produce good documentation?
  • Right documentation champion might make things better?
  • Architects spend more time figuring out what to do, than documenting what they already know
  • It's much easier to replace a general than a good horse
  • ADLs come without a rollout plan; how do you do technology transfer?
  • Why cannot ADLs be marketed the same way apache is (grass-roots)?
  • If you have generic ADLs, maybe they should specialized for specific domains
  • Can we have an ADL that supports Java?
  • Simple tool support
    • Starting with Visio; Eclipse plug-ins; VS.net DSL project
  • User studies
    • Surveys
  • Convergence between ADLs
    • Different notations for OO design;
    • Maybe you should align with UML; if that helps with adoption
    • Middle ground: language that's translatable to UML
  • Contrary question: how can we support views with more than "viewpackets"???
    • Packaging of a portion of a view for presentation
      • Use of hierarchy?
      • Except in the case of module views, one diagram is enough
  • Decomposition is most useful in the module views
  • How much tool support should you invest if you're going to have only 4 diagrams per project?
  • Make your ADL a JSR; this might make companies look at it
  • In the open source community, projects often fork off into a different direction, because they don't believe they're doing the "right" thing
  • Seeing others do it first may help with adoption
    • Do we know of significant projects in the open source community who are successfully using ADLs or exprssed the need for one?
    • The open source community is the ideal zero dollar marketing community
    • The open-source community is very skeptical of ADL-like documentation
      • Need to give them compelling reason: the same way there's a compelling reason to do unit testsing
      • Is there an argument for "regression testing" of the architecture?
  • In industry, more top-down approach to adoption; selling an architecture to a peson with a global perspective is suitable; selling an architecture to the guy in the trenches is going to be harder; making the case more challenging
  • We wouldn't use an ADL until you can execute it; generate code; or execute the ADL; make the ADL capable to representing the little things in the architecture that don't rise to the level of architecture, but get put in there.
    • Why should an ADL include non-architectural elements? Make the architectural issues part of the compilable code?
  • Other groups have opposite opinions: we use ADLs as a sketching tools.
  • Asking what the architects do may be the wrong answer: because there are more developers than architects
  • ArchJava language: starts from Java; let's add an architecture. connect statement connects two things; you no longer have to do connection code in ArchJava. In the short term, everyone wants to use tools that work for Java. Integrating the two is not a silver bullet!
  • Is executable architecture and MDA the same thing? MDA is more executable specification.
    • When you get high economic value, having an executable architecture may make sense
    • Hard problem is getting the architectuarl concepts right so you can go ahead and draw the picture
    • Whole point of architecture is wanting to keep the components abstract, not worry about implementation details
  • Architects can use MDA

Pre-session Discussions

Slides provided by the participants

Session Minutes

Post-session Summary

Post-mortem

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