Comprehensive View-Based Software Architecture Documentation

1. View Based Documentation of Software Architecturesfrom“views and beyond “byClements and lots of people

2. Uses of Documentation • As a means of education – introducing people to the system • As a primary vehicle for communication amongst stakeholders • As a basis for system analysis

3. Component 1 Connector P Component 2 What does the arrow mean? • C1 calls C2 • C1 passes data to C2 via its parameters • C1 obtains a result from C2 • C1 causes C2 to come into existence • C1 cannot execute till C2 terminates • Data flows both ways: two arrows, double headed arrow

4. View types • Architects need to look at software in three ways • How it is structured as a set of implementation units • How it is structured as a set of elements that have runtime behavior and interaction • How it relates to non-software structures and its environment

5. Viewtypes • The module viewtype • Document a system’s principals units of implementations • The componentandconnector viewtype • Document the system’s units of execution • The allocation viewtype • Document the relationship between a system’s software and its development and execution environment

6. Styles • In each view type there are a set of commonly occurring forms and variations – styles • Layered style, client-server, ..

7. Write documentation from the Readers’s Point of view Avoid unnecessary repetition Avoid ambiguity Use a standard of Organisation Record Rationale Keep documentation current but not too current Review Documentation for fitness of purpose Seven rules for sound Documentation

8. Viewtypes and Styles

9. Module Viewtype • A code unit that implements a set of responsibilities • Can be a class, a collection of classes, a layer or any decomposition of the code unit • Has some properties: responsibility, visibility, author..

10. Module Viewtype styles • Decomposition style • Uses style • Generalization style • Layered style

11. Component and connector Viewtype • Express runtime behavior • Described in terms of connectors and components • Objects, processes, collection of objects are components • Pipes, repositories, sockets are connectors • Middleware is a connector

12. C&C Viewtype Styles • Pipe-and-filter • Shared-data • Publish-subscribe • Client-server • Peer-to-peer • Communicating processes

13. Allocation Viewtype • Maps software units to elements of the environment(hardware, development team..) • Deployment style • Implementation style • Work assignment style

14. Overview Elements, relations and properties What it’s for and not for Notations Relation to other views Examples Style Guide

15. LINUX ARCHITECTURE Different Views

16. Basic Definitions • Linux subsystems • Process Scheduler (PS) – responsible for supporting multitasking by deciding which user process executes. • Memory Manager (MM) – provides a separate memory space for each user process. • File System (FS)– provides access to hardware devices • Network Interface (NI)– encapsulates access to network devices

17. Linux subsystems • Inter Process Communication (IPC)– allows user processes to communicate with other processes on the same computer • Initialization (Init)– responsible for initializing the rest of the linux kernel with appropriate usr configured settings • Library (Lib)– the kernel core which stores the routines that are used by other subsystems for their running.

18. MODULE VIEW

19. Module View Linux MM Init PS FS NI IPC Lib

20. File System Broken Down File System System Call Interface Executable Formats Virtual File System File Quota Buffer Cache Device Drivers Logical File System

21. Components & Connector Diagrams

22. CnC View • 1st level of abstraction – This level only gives the corresponding relations between the 7 basic modules that construct the Linux architecture • Relations used – If x y then x depends on y for its running, i.e. for x depends on certain components present inside y for its own running.

23. CnC view FS NI MM IPC PS Init Lib

24. CnC – 2nd Level of Abstractions FS NI MM PS IPC Init Lib

25. Breakdown of FS MM NI • FS Sys Call Interface Virtual FS Init IPC Executable File Format Logical FS Device Driver Buffer Cache File Quota PS Lib

26. Module View

27. Viewtypes • The module viewtype • Document a system’s principals units of implementations • The componentandconnector viewtype • Document the system’s units of execution • The allocation viewtype • Document the relationship between a system’s software and its development and execution environment

28. Module Viewtype • A code unit that implements a set of responsibilities • Can be a class, a collection of classes, a layer or any decomposition of the code unit • Has some properties: responsibility, visibility, author..

29. Module Viewtype styles • Decomposition style • Uses style • Generalization style • Layered style

30. Overview • What is a module? – software units with well defined interfaces providing a set of services • Module vs. component • Both are about decomposition • Module has a design time connotation and component a runtime connotation • 4 common styles • The decomposition style – containment relationship among modules • The uses style – functional dependency relationships among modules • Generalization style – specialization relationships among modules • Layered style – allowed-to-use relation in a restricted fashion among modules

31. What is it for? • Construction – • blueprint for the source code • Modules and physical structures (source code files) will have close mapping • Analysis • Requirements traceability • Impact analysis • Communication – useful for explaining the systems functionality

32. What is it not for? • Cannot make inferences about runtime behavior • Hence not used for analysis of performance, reliability and other runtime qualities; we use c-and-c and allocation views are used

33. Relation to other viewtypes • Module views commonly mapped to c-and-c viewtypes • Sometimes one-to-one or one-to-many but could also be fragments to fragment

34. Module Viewtype styles • Decomposition Style • Uses • Generalization • Layered

35. Decomposition - overview • Focus on the is-part-of relationship between elements and their properties • How system responsibilities are partitioned across how these modules are decomposed into sub modules • All architectures begin with module decomposition style – divide and conquer • Useful for communicating the broad picture to new comers • Since functionality is allocated, modifiability is immediately addressed

36. Criteria for decomposition • Achievement of certain quality attributes • Modifiability • Performance • Build-versus-buy decisions • Product line implementations

37. Elements, Relations, Properties

38. What is it for? • Learning • New comers • Work assignment • What is it not for? • Notations • Named boxes within boxes • Textual notation • Examples of decomposition style

39. From Clements etal

40. Relation to other styles • Module decomposition view can be mapped into component-and-connector view; either one-to-one or one-to-many or fragment to fragment • Closely related to work assignment style of allocation viewtype

41. Module Viewtype styles • Decomposition Style • Uses style • Generalization • Layered

42. Uses - overview • What other modules should exist in order to do their part of the work properly

43. Uses summary

44. Uses style contd. • Can be documented as a two column table • Or any graphical notation • P1 uses P2, if P1’s correctness depend on the correctness of P2 • Two kinds of usage • CALLS but not USES • Exception handling – just pass on the name of caller • CALLS and USES • No CALL yet USES • Expect P2 to leave a variable in a certain state

45. Where is it useful? • Incremental development • Implement part of the total functionality • Sub-setting, debugging, testing, impact analysis

46. From Clements etal

47. Decomposition Styles • Decomposition Style • Uses • Generalization • Layered

48. Overview • Is-a relation is specialized to generalization • Parent is a more general version of the child • In decomposition the parent consists of the child • Useful for extension and evolution of architectures and individual elements • Inheritance of interface and implementation

49. Generalization summary

50. Gen: where is it useful? • Object-oriented designs • Extension and evolution • Local change or variation • Reuse