Institute for Practical Informatics at the Leibniz Universität Hannover Institute for Practical Informatics: Software Engineering Group Leibniz Universität Hannover

Research » FLOW Diese Seite auf DeutschDiese Seite auf Deutsch

Project FLOW is concerned with the characterisitics, modelling, analysis, and optimization of information flows in software development. A fundamental feature of FLOW is the distinction between fluid and solid information stores and flows.

Goals

Project FLOW was initiated in 2004 when the Software Engineering Group at Leibniz Universität Hannover was founded.

Definition: FLOW
FLOW is the systematic research on information flows in software development.

FLOW concentrates on characterisitcs, modelling, analysis, and optimization of information flows. The following goals are pursued:

Goals of Project FLOW

Basic Concepts

FLOW research is based on a few fundamental assumptions, that were derived from the goals goals and have been proved reasonable in industry:

Metaphor of State of Information

An essential concept of FLOW is the distinction between solid and fluid information and the respective flows. The metaphor is used so the main characteristics of information flows can be discerned.

Definition: Solid
Information is solid when it is (1) long term accessible, (2) repeatable, and (3) comprehensible by third parties*.

* Third parties do not have to be arbitrary persons, but can be e. g. from the same domain or project.

Definition: Fluid
Information is fluid when it is not solid.

That means that information is fluid whenever one of the solid characteristics is not met.

The following table lists characteristics of solid and fluid information along with typical examples of information stores.

State of InformationCharacteristicExample Store
Solid
  • Storage costs time and effort
  • Access costs time and effort
  • Access is repeatable**
  • Long-term accessible**
  • Third parties can understand it**
  • Information can not be lost or forgotton
  • Context for interpretataion can be attached, at least to a certain level.
  • Document (paper based and electronic)
  • Audio-/Video recordings
  • Screencasts
  • Source code
Fluid
"What someone has in mind."

Fluid information is bound to peoples (previdous) knowledge, the so called context. Information cannot be interpreted correctly without the appropriate context, thus, it cannot be understood.
  • Can be lost (forgotten context) or forgotten
  • Cannot be obtained or reproduced by third parties. The right contet for interpretation is needed.
  • Fast, efficient transfer of information possible
  • People
  • Informal e-mails
  • Text chat protocols
  • Memos, note sheets
  • Notes on whiteboards

** Directly derived from the definition of solid.

Notation

The FLOW notation was developed based on the basic concepts and the information state metaphor. It allows to intuitively illustrate the fundamental aspects of FLOW, in particular the distinction between solid and fluid. Essentially, there are symbols for solid and fluid informations stores and corresponding arrow types for information flows. A symbol for activities complements the notation. It allows to incorporate FLOW models with existing process models like EPCs or UML activity diagrams.

State of InformationStoreFlowActivity
 12..nProject infosExperiences 
Solid Document symbol
<Document>
Documents symbol
<Type of Document>
Solid information flow
<Type of Information>
(optional)
Fluid information flow
<Experience>
(optional)
Aktivität
Fluid Personensymbol
<Person>
Gruppensymbol
<Group>
flüssiger Informationsfluss
<Type of Information>
(optional)
flüssiger Erfahrungsfluss
<Experience>
(optinoal)

Solid

The document symbol represents a solid information store. It was chosen because a document is the most prominent representative of solid information stores in software development. A set of documents (of the same type) is depicted by a triple document. Information flows originating from a solid store are themselves solid. They are depicted by an arrow with a solid line.

Fluid

A smiley symbol represents a fluid information store. It was chosen because fluid information is always bound to people. A group of persons is depicted by a triple smiley. If it is necessary to distinguish between roles and individuals different caption styles can be used, i. e. an underlined caption for roles and a regular one for individuals (for example: "Johnson" as opposed to "Analyst"). Information flows originating from a fluid store are themselves fluid. They are depicted by an arrow with a dashed line.

Experience

In software development experience is an extraordinary valuable type of information. Therefore, FLOW has an explicit means to depict it. Usually a different color for stores and flows is used. For black and white printouts the "color" gray should be used.

Activity

In FLOW models the activity symbol has two functions:

  1. It subsumes information stores and other activities and hides them. Hence, it facilitates hierarchical structured FLOW models. Incoming and outgoing flows, the so called FLOW interface [3], have to be consistent with the underlying detailed (subsumed) model.
  2. It is used to connect FLOW models to process notations. By this aspects of information flows can be integrated in existing process models.

Activity with controlling and project relevant infotmation flows. To depict the difference of information flows that are involved in an activity with regards to content and controlling flows, the flows can be attached to the activity symbol from different sides. Information that controls an activity is connected on top or bottom of the activity symbol. Information that controls something usually is experience. Information that is being or was altered and tranformed in the activity is connected from left or right.

Alternatively, the activity symbol can be used according to IDEF0. There are four connecting points for flows then:

Activity with information flows according to IDEF0
  1. From left all information that is being processed in the activity is attached.
  2. Outgoing flows are attached to the right. By default outgoing flows have a solid line. If it is known that an outgoing flow is fluid it can also be depicted with a dashed line.
  3. From bottom mechanisms that support the execution of an activity are attached. For example this can be a person that performs the activity or a tool like a word processor.
  4. Controoling flows are attached on top of the activity. Examples of controlling flows are experiences in form of checklists or specialized knowledge of a person. Therefore, control flows in activities are usually depicted in gray.

ProFLOW

ProFLOW (German) is the graphical modelling tool for FLOW. It facilitates creation and editing of FLOW models and process models supplemented by FLOW elements. ProFLOW was designed to be an easily extensible modelling framework, so new notations can be tried out with low effort. All new notations can be enriched with FLOW aspects. At the moment EPCs and UML Activity Diagrams are supported. You can download ProFLOW and give it a try on the ProFLOW Website (German in German).

ProFLOW Website: http://www.se.uni-hannover.de/forschung/flow/proflow/ (German in German)

ProFLOW Development Site: https://locke.se.uni-hannover.de/trac/proflow (German in German)

ProFLOW Updatesite: http://www.se.uni-hannover.de/forschung/flow/proflow/

References