1. Communication Notation Part V Chapter 15, 16, 18 and 19.

2. Today…. Introduction Diagrams – Data flow Diagrams – Architecture Diagrams Guidelines – Context modeling – Architectural design Break….

3. Communication Notation Services Behavior Communication

4. Modeling Communication Context Models (Analyses) – Communication in environment – Communication between environment and SuD Architectural Models (Design) – Communication between components Stimulus / response pairs – Communication between components and entities in the environment

5. Requirements-level Architecture Environment and requirements Not software platform Not physical system

6. Physical Network Architecture

7. Refining the Physical Architecture

8. Data Flow Diagrams Used to represent software decomposition Old: 1970’ties Widely used Elements matches software: – Data stores – Data transformations

9. Architecture of Training Information System Data stores Data transformations Fragment corresponding to a function of the SuD

10. Requirement-level architecture of the heating controller

11. Tank Controller Control System Architecture: Control processes Interface shown on lower level

12. Electronic Ticket System – Context diagram SuD as black box

13. Representation of SuD Elements Data flow diagrams:No boxes Architecture diagrams:All icons

14. Representing External Entities

15. Time-behavior of flows Values vs. Time

16. Representing Flows

17. Event flow Events can be parameterized Named after effect Causality

18. Semantics of flows Flows are instantaneous and reliable Abstraction of real systems

19. Semantics of stores Remembers data until deletion ERD and dictionary defines content of stores

20. Semantics of processes Input → Output, Events Specified by STT or STD Input → Output, Data Stateless: Triggered by T Stateful: Enable/Disable by E/D Specified by lower level DFD

21. Parameterized DFDs Process names can be combined with process identifiers – Flow names will also carry the process identifiers We can use special notation, e.g., double circles. – But not that easy…

22. Data Flow Diagrams Collection of data stores and processes connected by flows Several kinds of processes – Details can be specified Several kinds of flows – Details can be specified Hierarchy of DFDs

23. Communication Diagrams ‘Just like DFDs, but’: - Type-level diagrams - Variable vs. Database - Subsystem vs. Object - Object classes, types of components

24. Requirement-level Communication Diagram of Heating Controller

25. Instance Diagram of Heating Controller in context

26. Elements of Communication Diagrams Components: – part of SuD that deliver services Data transformation, no state Data store – Variable, single values – Database, collection of values Subsystem, represents lower level communication diag. Object, DFD: Stateful data process Object Class, Objects can be created and removed

27. Communication Channels Like DFDs – Event Channels – Data Channels Addressing: – Channel Addressing, like DFDs – Destination Addressing, like UML

28. Decomposition of systems Channels address all components of S AND-Components, synchronize by broadcast of events

29. Example of AND-component

30. Function Allocation Table

31. Function Flowdown table

32. Communication Diagrams Generalizes DFDs Representation of Objects and Classes Allow Instance level diagrams Support decomposition We can check validity using: – Function Allocation tables – Function Flowdown tables

33. Break... Short or long???

34. Guidelines for Context Modeling Modeling, analysis not design SuD is a black box

35. Finding the System Boundaries: Use function refinement tree – Implementation-independent description Use list of stimuli and response – Behavioral description

36. Environment or SuD??? A and S entails E Environment and SuD implements the Desired System

37. Context Diagrams Relevant entities and communication in the environment – Physical entities – Conceptual entities – Lexical entities ‘Relevant’ means ‘has a clear link to the purpose of the system’

38. Context Diagram

40. Level of abstraction… Do we need to know about the Wire or is the Heater enough? When do you have enough details??

41. Finding the Context Boundaries: SuD goals should be achieved – SuD needs information from the entity – SuD has an effect on the entity Ignore other entities – Effect of SuD is irrelevant – Effect on SuD is irrelevant

42. Structure of the context Provide information about the subject domain – Answer questions, produce reports, … Direct the subject domain – Control, guide, … Manipulate lexical items in the subject domain – Create, change, display, …

43. Example: Information System

44. Example: Directive System

45. Example: Manipulative system

46. Context Modeling Modeling, not design System boundaries – Trade-off Context boundaries – Relevance Typical structures: – Information, directive, or manipulative

47. Requirements-level decomposition Guidelines

48. What is ‘Architecture’? ‘A structure of elements and their properties, and the interaction between these elements that realizes system-level properties’ – Many levels of architectures for a SuD – Elements must have synergy – An architectural style implies a set of constraints

49. Encapsulation vs. Layering Encapsulation and Service delivery Layering and encapsulation can be mixed on different levels Layering can be strict or loose

50. Layered Architectures

51. Layered Context Diagram

52. Guidelines Choose a structure that reflects the structure of the problem Choose a structure which is robust – Keep related data together – Keep related functions together

53. Architectural styles Data flow style: – Not applicable Von Neumann style – Database and application programs Object-oriented style – All components are objects, usually destination addressing

54. Sources of Requirement-level Design Decisions: Functional or Environment

55. Decomposition Guidelines: Functional Decomposition: – Each function is allocated to a different system component Subject-oriented Decomposition: – Each group of subject-domain entities corresponds to a system component

56. Pure Functional Style - Data encapsulated as functions - Inefficient - Hard to relate to subject domain entities

57. Pure Subject-oriented Style - Functions encapsulated as data - Inefficient - Hard to relate to subject domain entities

58. Mixed – Von Neumann Style

59. Decomposition styles Event-oriented Decomposition Device-oriented Decomposition User-oriented Decomposition Behavior-oriented Decomposition

60. Mixing functional and subject-oriented decomposition Batch behavior has been distributed

61. Including Behavior-oriented decomposition

62. Evaluation of Decomposition Realize the system Reason about the models – All data is created, used and deleted – Execute the model – Correctness argument: C 1 and … and C n entails S – Check that quality attributes are realized – Build a prototype, and test it.

63. Requirements-level Modeling Layering or Encapsulation Styles: – Data Flow, Von Neumann or Object-oriented Requirements-level decomposition must correspond to major system aspects and the subject domain: – Functional decomposition – Subject-oriented decomposition – Communication-oriented, event – devices – users, decomposition – Behavior-oriented decomposition