1 / 100

Comprehensive View-Based Software Architecture Documentation

Learn about the importance of documentation in software architectures, including different view types and styles. Examples include Linux architecture and breakdowns of modules and components.

shibata
Download Presentation

Comprehensive View-Based Software Architecture Documentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related