1. Faculty of Civil Engineering Institute of Construction Informatics, Prof. Dr.-Ing. Scherer Institute of Construction Informatics, Prof. Dr.-Ing. Scherer Technische Universität Dresden SoE 1 Software Engineering Management Information Systems Part 1 Prof. Dr.-Ing. Raimar J. Scherer Institute of Construction Informatics Dresden, 10.10.2011

2. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 2 Software Engineering Goals Developing software for a system. In a detailed view a tool for a structural analysis can be seen as a system containing the components for defining the engineering system (load, supports, etc.), for the calculation using different methods and for the graphical representation of the results. Procedure Definition of the system Dividing the problem in subproblems Process for combining the subproblems (In general each solution for a subproblem represents a software system component. Today, such components are often realized as web services.)

3. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 3 Software Engineering Procedure (continuation) Identifying the information flow Identifying, collecting and defining objects Identifying the interaction of the objects  relationships Use Cases (application scenarios): Each application of the software system can lead to different relationships and finally to a different object data network. The object-oriented modeling and programming allows, that the relationships of all system applications can be represented and stored in one data base; but the graphical representation of all these relationships can be too complex and confusing. For this reason the objects and their relationships resulting from different use cases should be developed and stored separately.

4. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 4 Software Engineering Procedure (continuation) Realization  Data base(s)  Calculation modules/tools  Information exchange: Interfaces, data exchange formats  Workflow (process flow on component level) or orchestration, if web services are part of the realization The realization steps have to be repeated for system extensions

5. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 5 UML-Diagram Types Structure Diagrams Class diagramRepresentation of the system behavior using classes and relations Composition structure diag.Representation of the class content and the class interaction Component diagramRepresentation of system components and their interfaces Deployment diagramRepresentation of nodes, artifacts and the deployment relationships Object diagramRepresentation of the system objects at a certain time Package diagramRepresentation of subject modules (grouping of classes) Behavior diagrams Use Case DiagramRepresentation of actors, use cases and their relations Activity diagramRepresentation of the operational process flow within a system UML state machine diag.Representation of the system states Sequence diagramRepresentation of the activity sequences of object interactions Communication diagramRepresentation of the information flow between system objects Interaction overview diag.Representation of sequences of activities (similar to the sequence diag.) Timing diagramRepresentation of the temporal behavior of objects and systems

6. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 6 What is a Management Information System (MIS) ? A Management Information System is an information system which  collects data about a system  processes information from the data and  provides these information to managers They use them for decision making, planning of measurements, program implementation, and control.  MIS concentrates on the use of computer and information technology to solve business problems  MIS is business and management oriented; however, however technical capabilities are required, too.

7. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 7 Goals of a MIS m Provide managers with information to make decisions in particular  Support regular, routine operations  Support Control  Improve Planning for renewal and extensions  improve reactions to malfunctions and accidents

8. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 8 What are systems? m Systems are:  Water supply systems  Power supply systems  Structural systems  HVAC (room climate) systems  Transportation systems  Harbors  Hazard emergency system  Hazard rescue system  Military system (the army)  Construction team

9. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 9 Overall Process of an Engineering System Treatment 1.System Capturing High level definition of the purpose, functions, processes and behaviour Formal Representation of the System (IDEF0) 2.data structure = {O,R} based on a specific meta model (= O-O-Model) development of a data model as an O-O-schema = ideal data structure of the concepts 3.transformation of the conceptual data model in an operational database; today being most appropriate as a relational data structure (approximations) 4.implementation of the schema in a data base software; 5.instantiation of an engineering model = configure the domain-specific engineering model from the data model 6.numerical program for the computation of the system behaviour = simulation = prognosis based on a model + model assumptions + quantitative values (statistics) (= {O-O + Impl.} + {Instantiation} ) 7.Communication M2M: between data base (= information) and computation program (= numerics) = data exchange (data conversion by importing program) M2H: Reports, i.e. graphical and alphanumerical representation of results (output and system changes) but also input, model and model assumptions 8.Monitoring + Evaluation + Reporting

10. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 10 Definition of "System" m A system is an assemblage of related elements comprising a whole and interacting in an organised way to accomplish goals. m A system can be described by a set of entities (objects, elements) which 'act' on each other, and for which one or more models may be constructed encompassing the objects and their allowed relations, resulting in a system topology. m Example: The main elements of a Water Supply System Water Reservoir Supply LinesCustomer consumption  requested storage volumeprovide transport & distribute DoW Discourse of the world

11. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 11 Different Views of Systems System Function Model System Architecture System Layout Technical system shows its function and break down in sub- functions (sub-systems) Water Reservoir Supply Lines Costumer water collection shows its components

12. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 12 Definition of System from Function View FUNCTION InputOutput FUNCTION Input Output FUNCTION InputOutput FUNCTION InputOutput The input must be transformed by the function and the output must be a product of the transformation This is a neural network approach. NN simulates the system behaviour but does not explain the system function. Water InputCustomerElements of Supply System

13. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 13 Customers Distribution Lines Secondary Supply Line Main Supply Line Aggregation of Systems A system is built (aggregated) of elements. The aggregation defines the topology of the system. The aggregation is a hierarchical structure of the elements. Example: Water Supply System Water input Water Reservoirs Main Supply Line Secondary Supply Line Distribution Lines Costumer End Lines Costumer/water consum. Water loss Water Reservoir Water Input

14. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 14 Advantage of System Thinking m Application of concepts to identify requirements for new systems and problems in existing systems m Framework for problem solving and decision making. m Structuring of processes in order to understand how systems are organized and how they work m Reduction of system complexity (simplified models) m Keep managers focused on overall goals and operations of business, whereas engineers deals with details. m Organization of the people involved. Who has to deal with what? m Look at the Whole View, identify the main issues m Control of System Behaviour m Repeated application of the solution (process) for problems which are variations of as standard problem => Analogies

15. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 15 Subsystems by Nesting of Systems The System in the System  Reduction of Complexity  Sub-system, super-system, meta-system  Problem of distinguishing and separating of different points of view Water Supply System Management of Water Supply System Monitoring of Water Supply System Financial Management System (Costs)

16. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 16 Extended Representation of Systems (IDEF0) m Input and Output is not enough for sufficient representation of systems  1) Control 2) Mechanism (Actor) m IDEF0 = modelling language  associated rules and techniques for developing structured graphical representations of a system or enterprise m IDEF0 = Integration Definition Function Modelling, Level 0 m IDEF0 is based on the (US) Air Force Wright Aeronautical Laboratories Integrated Computer-Aided Manufacturing (ICAM) Architecture

17. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 17 History of IDEF0 m During the 1970s, the U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM) sought to increase manufacturing productivity through systematic application of computer technology. m As a result, the ICAM program developed a series of techniques known as the IDEF (ICAM Definition) techniques which included the following:  IDEF0, used to produce a "function model". A function model is a structured representation of the functions, activities or processes within the modelled system or subject area.  IDEF1, used to produce an "information model". An information model represents the structure and semantics of information within the modelled system or subject area.  IDEF2, used to produce a "dynamics model". A dynamics model represents the time- varying behavioural characteristics of the modelled system or subject area. m In 1983, the U.S. Air Force Integrated Information Support System program enhanced the IDEF1 information modelling technique to form IDEF1X (IDEF1 Extended), a semantic data modelling technique. m IDEF0 and IDEF1X techniques are widely used in the government, industrial and commercial sectors, supporting modelling efforts for a wide range of enterprises and application domains. Supporting Text

18. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 18 Applications of IDEF0 m For new systems, to improve design work, IDEF0 may be used first to define the requirements and specify the functions, and then to design an implementation that meets the requirements and performs the functions. m For existing systems, to improve monitoring, IDEF0 can be used to analyze the functions the system performs and to record the mechanisms (means) by which these are done.

19. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 19 Function m An activity, process, or transformation is modelled by IDEF0 as a box m identified by a verb or verb phrase that describes what must be accomplished. Function Name

20. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 20 Input m Real Objects or Data necessary to Perform a Function m Labeled with a Noun or Noun Phrase Function Name Input

21. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 21 Output Function Name Output m Objects or Data Produced as a Result of the Function after Transformation of Input m Labeled with a Noun or Noun Phrase

22. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 22 Control m Conditions (data, information) required to produce correct output, i.e. control the function m Labeled with a Noun or Noun Phrase Function Name Control

23. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 23 Mechanism m Actor (Person, Device) or a method / algorithm which carries out the Function m Labeled with a Noun or Noun Phrase Function Name Mechanism

24. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 24 Extended Representation of Systems (IDEF0) The two primary modelling components are functions and data/objects that inter-relate those functions. Function Name InputOutput Control Mechanism Boxes represent functions that show what must be accomplished. A function name shall be an active verb. Arrows identify data or objects needed or produced by the functions. Each arrow shall be labelled with a noun.

25. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 25 Decomposition in Sub-Systems A0 A-0 Parent Diagram Child Diagram More General More Detailed 0 This box is parent of next diagram 1 2 3 4 A4 Top-Level Context Diagram Sub-Systems can be nested or in sequence Parent Diagrams Represent a Higher Level of Abstraction than Child Diagrams

26. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 26 Top-Level Context Diagram m Each model shall have a top-level context diagram, on which the subject of the model is represented by a single box with its bounding arrows. This is called the A-0 diagram (pronounced A minus zero). The arrows on this diagram interface with functions outside the subject area. They establish the model focus. Since a single box represents the whole subject, the descriptive name written in the box is general. The same is true of the interface arrows since they also represent the complete set of external interfaces to the subject. The A-0 diagram also sets the model scope or boundary and orientation. m The A-0 context diagram also shall present brief statements specifying the model's viewpoint and purpose, which help to guide and constrain the creation of the model. m The most important features come first in the hierarchy, as the whole top- level function is decomposed into sub-function parts that compose it, and those parts, in turn, are further decomposed until all of the relevant detail of the whole viewpoint is adequately exposed. m Each sub-function is modelled individually by a box, with parent boxes detailed by child diagrams at the next lower level. All child diagrams must be within the scope of the top level context diagram. Supporting Text

27. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 27 Child Diagram m The single function represented on the top-level context diagram may be decomposed into its major sub-functions by creating its child diagram. m In turn, each of these sub-functions may be decomposed, each creating another, lower-level child diagram. m On a given diagram, some of the functions, none of the functions or all of the functions may be decomposed. m Each child diagram contains the child boxes and arrows that provide additional detail about the parent box. m The child diagram that results from the decomposition of a function covers the same scope as the parent box it details. Thus, a child diagram may be thought of as being the "inside" of its parent box. Supporting Text

28. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 28 Parent Diagram m A parent diagram is one that contains one or more parent boxes. m Every ordinary (non-context) diagram is also a child diagram, since by definition it details a parent box. m Thus a diagram may be both a parent diagram (containing parent boxes) and a child diagram (detailing its own parent box). m Likewise, a box may be both a parent box (detailed by a child diagram) and a child box (appearing on a child diagram). m The primary hierarchical relationship is between a parent box and the child diagram that details it. Supporting Text

29. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 29 Decomposition in Sub-Systems A4 1 2 3 A43 1 2 3 Node numbers shown here indicate that the box has been detailed. A diagram has a maximum of 6 functions and a minimum of 3

30. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 30 Tunneled Arrows m Tunnelling an arrow where it connects to a box side means that the data or objects expressed by that arrow are not necessary for understanding subsequent level(s) of decomposition, and thus shall not be shown on its child diagram. m An arrow tunnelled at its connected end may be omitted from one or more levels of decomposition and then reappear on another level, in one or more places, tunnelled at the unconnected end. m However, because this arrow does correspond to one on its parent diagram, it is given an ICOM code. ( ) I1 M1 C1 O1

31. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 31 Tunnelled Arrows m Tunnelling an arrow at the unconnected end means that the data or objects are not necessary at the next higher (parent) level and hence shall not be shown connecting to the parent box. m Because this arrow does not correspond to one on its parent diagram, it does not have an ICOM code. ( )

32. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 32 Box Numbers m Each box on a diagram shall be numbered in the lower inside right corner of the box. m This numbering system is required to uniquely identify the boxes within a diagram, and to generate node numbers. m It is also used to cross-reference descriptive entries in the text and glossary to the boxes on a diagram. m The box number for the single box on the A-0 context diagram shall be 0 (zero). m The box numbers for the boxes on all other graphic diagrams shall be 1, 2, 3, to at most 6, to uniquely identify the three to six boxes on each such diagram. 0

33. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 33 Node Numbers m A node number is based on the position of a box in the model hierarchy. A node number is formed by appending a box number to the node number of the diagram on which it appears. m For example, the node number of box 2 on diagram A25 is A252. (All IDEF0 node numbers begin with a capital letter, such as "A".) m When a box is detailed by a child diagram, the node number of the parent box is assigned as the diagram node number  parent box and its child diagram have the same node number. 0 A0

34. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 34 Output m Output can become Control m Output can become Input A A

35. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 35 Bundling and Unbundling Unbundle arrow meaning A into arrow meanings B and C. C B A A B C Bundle arrow meaning B and C to form arrow A Bundling/Unbundling: The combining of arrow meanings into a composite meaning (bundling), or the separation of arrow meanings (unbundling), is expressed by arrow join and fork syntax.

36. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 36 Example: Water-Supply System supply water Collected Water Water needed by consumers Topography, regulations, etc. Provider Boxes represent functions that show what must be accomplished. A function name shall be an active verb. Arrows identify data or objects needed or produced by the functions. Each arrow shall be labelled with a noun.

37. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 37 Definition of Goals and Sub-Goals Flow DataConsumption DataSupply Data RoughnessWastage Costs due to increased pumping and wastage Income Evaluation of Profitability Report  Actual State Goal Sub- Goals Pressure Data Goal Time Topic

38. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 38 Example: Management of Water-Supply System manage life-cycle Operations Data Quality & Quantity Requirements Operator Long-term Profit Top-Level Context Diagram 0 A-0 Monitoring of Water Supply System PURPOSE: Monitoring and Information Retrieval for Maintenance of Water Supply System VIEWPOINT: Maintenance Team and Decision Makers Projected Data A0 Iteration, Minimization of Costs (influencing factors are roughness of pipes and water loss)

39. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 39 Example: Profitability of Water-Supply System The whole process is time-dependent i.e. has to be updated regularly

40. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 40 System-Behaviour System behaviour = Aggregation of behaviour of all Basic Sub-Systems Each Basic Sub-System is an isolated system  1st law of thermodynamics holds  conservation of total energy "Element Pipe" transport water Q 1 h Loss,1 v 1 p 1 Q 2 h Loss,2 v 2 p 2 State Variables State Variables roughness, length, diameter conservation of total energy

41. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 41 Element Behaviour for Basic Element NN EL HGL for steady, inviscid, incompressible flow ELT 12 p = static pressureρ = density v = flow velocityg = acceleration of gravity z = elevation heighth Loss = head loss = friction coefficient L = Length of pipe d h = hydraulic diameter L k = relative roughness of tube or duct wall Re = Reynolds number Conservation of Total Energy μ = dynamic or absolute viscosity

42. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 42 Example: Water-Supply System

43. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 43 Example: Water-Supply System

44. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 44 Example: Water-Supply System

45. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 45 Drawbacks of IDEF0 When utilizing IDEF0 one should be aware of some drawbacks: m Complexity of diagrams. m Distinguishing and separating different viewpoints. m Identifying and distinguishing between controls and inputs.

46. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 46 Literature m Draft Federal Information Processing Standards Publication 183 Announcing the Standard for "INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)", 1993 December 21, http://www.idef.com/pdf/idef0.pdf

47. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 47

48. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 48 Model m A model is a simplified mapping of the reality. m A model is used for representation of a set of components of a system or subject area. m The mapping is restricted to the objects, which are relevant for the investigation m In order to make the model manageable, simplifications must be introduced m Simplifications are irreversible  Detailing only by a new model and new computation Simplification reversion impossible VORLESUNG 2

49. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 49 Levels of Modelling, Model Approximations Physical Model Conservation of energy, steady state incompressible flow 1. Approx. Mathematical Model 2. Approx. Numerical Approximation of the Mathematical Model iterative computation of friction coefficient 3. Approx. Computer: Numerics of finite floating-point numbers 3.1428574. Approx. VORLESUNG 2

50. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 50 4 Step Modelling Process 1.Observation & Measurement 2.Hypothesis 3.Model building 4.Testing/validation VORLESUNG 2

51. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 51 KISS Principle: Keep It Simple Stupid A good model should encompass essential information without becoming too complex The most difficult task in model building is to model a COMPLEX system, but to to keep the model simple VORLESUNG 2

52. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 52 Model Errors m Model Error: The transition from reality to the mathematical model contains the Model Error, that arises e.g. by simplifications or approximations in order to make the problem solvable. Model Errors often are also the consequence of the current state-of-the art, which may not afford a better model. m Methodological Error: Arise from the fact, that every mathematical operation must be traced back to additions. m Rounding Error: Due to the transition from the infinite number of real numbers to the finite domain of floating-point numbers, each number must be truncated from a certain digit. This leads to an error in the last digit. If one has a complex physical system and hence a large mathematical system the number of operations is very high. Every operation causes a rounding error. The accumulation of these rounding errors can cause wrong results and maybe lead to uncertain interpretations. Supporting Text VORLESUNG 2

53. Institute of Construction Informatics, Prof. Dr.-Ing. Scherer SoE Technische Universität Dresden 53 System Behaviour for 1 Element NN EL HGL For steady, inviscid, incompressible flow the total energy ELT remains constant along a stream line as expressed through the Bernoulli Equation: ELT 12 p = static pressureρ = density v = flow velocityg = acceleration of gravity z = elevation heighth Loss = head loss = friction coefficient L = Length of pipe d h = hydraulic diameter L k = relative roughness of tube or duct wall Re = Reynolds number Conservation of Total Energy μ = dynamic or absolute viscosity Übung