1. CS 240, Prof. Sarwar Slide 1 CS 240: Software Project Fall 2003 Sections 1 & 2 Dr. Badrul M. Sarwar San Jose State University Lecture #9

2. CS 240, Prof. Sarwar Slide 2 Agenda l Requirements document is due 10/06 l Informal presentation of Project proposals l Software Prototyping  Evolutionary Prototypes  Throw-away Prototypes l Architectural Design  system structures  Control Models  Modular Decomposition

3. CS 240, Prof. Sarwar Slide 3 Approaches to prototyping

4. CS 240, Prof. Sarwar Slide 4 Evolutionary prototyping l Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems l Based on techniques which allow rapid system iterations l Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

5. CS 240, Prof. Sarwar Slide 5 Evolutionary prototyping

6. CS 240, Prof. Sarwar Slide 6 Evolutionary prototyping advantages l Accelerated delivery of the system  Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability l User engagement with the system  Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

7. CS 240, Prof. Sarwar Slide 7 Evolutionary prototyping (fundamental properties) l Specification, design and implementation are inter- twined l The system is developed as a series of increments that are delivered to the customer l Techniques for rapid system development are used such as CASE tools and 4GLs l User interfaces are usually developed using a GUI development toolkit

8. CS 240, Prof. Sarwar Slide 8 Evolutionary prototyping problems l Management problems  Existing management processes assume a waterfall model of development  May not be cost-effective to provide full documentation  Specialist skills are required which may not be available in all development teams l Maintenance problems  Continual change tends to corrupt system structure so long-term maintenance is expensive l Contractual problems  Lack of formal specification can lead to problems

9. CS 240, Prof. Sarwar Slide 9 Throw-away prototyping l Used to reduce requirements risk l The prototype is developed from an initial specification, delivered for experiment then discarded l The throw-away prototype should NOT be considered as a final system  Some system characteristics may have been left out  There is no specification for long-term maintenance  The system will be poorly structured and difficult to maintain

10. CS 240, Prof. Sarwar Slide 10 Throw-away prototyping

11. CS 240, Prof. Sarwar Slide 11 Prototype delivery l Developers may be pressurised to deliver a throw- away prototype as a final system l This is not recommended  It may be impossible to tune the prototype to meet non-functional requirements  The prototype is inevitably undocumented  The system structure will be degraded through changes made during development  Normal organisational quality standards may not have been applied

12. CS 240, Prof. Sarwar Slide 12 Rapid prototyping techniques l Various techniques may be used for rapid development. The following are practical for use in industrial-strength prototypes  Dynamic high-level language development  Database programming  Component and application assembly l These are not exclusive techniques - they are often used together l Visual programming is an inherent part of most prototype development systems

13. CS 240, Prof. Sarwar Slide 13 Dynamic high-level languages l Languages which include powerful data management facilities l Need a large run-time support system. Not normally used for large system development l Some languages offer excellent UI development facilities l Some languages have an integrated support environment whose facilities may be used in the prototype

14. CS 240, Prof. Sarwar Slide 14 Choice of prototyping language l What is the application domain of the problem? l What user interaction is required? l What support environment comes with the language? l Different parts of the system may be programmed in different languages. However, there may be problems with language communications

15. CS 240, Prof. Sarwar Slide 15 Database programming l Evolutionary development is standard practice now l All commercial database management systems now support database programming l 4GL refers to both database programming language and its supporting environment l 4GL Tools  A database query language e.g., SQL  An interface generator to create forms and displays  A spreadsheet for numerical information  A Report generator which is used to define and create reports

16. CS 240, Prof. Sarwar Slide 16 Component and application assembly l Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together l The composition mechanism must include control facilities and a mechanism for component communication l The system specification must take into account the availability and functionality of existing components

17. CS 240, Prof. Sarwar Slide 17 Reusable component composition

18. CS 240, Prof. Sarwar Slide 18 Prototyping with reuse l Application level development  Entire application systems are integrated with the prototype so that their functionality can be shared  For example, if text preparation is required, a standard word processor can be used l Component level development  Individual components are integrated within a standard framework to implement the system  Frame work can be a scripting language or an integration framework such as CORBA

19. CS 240, Prof. Sarwar Slide 19 Compound documents l For some applications, a prototype can be created by developing a compound document l This is a document with active elements (such as a spreadsheet) that allow user computations l Each active element has an associated application which is invoked when that element is selected l The document itself is the integrator for the different applications

20. CS 240, Prof. Sarwar Slide 20 Application linking in compound documents

21. CS 240, Prof. Sarwar Slide 21 Visual programming l Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items l A large library of components exists to support this type of development l These may be tailored to suit the specific application requirements

22. CS 240, Prof. Sarwar Slide 22 Visual programming with reuse

23. CS 240, Prof. Sarwar Slide 23 Problems with visual development l Difficult to coordinate team-based development l No explicit system architecture l Complex dependencies between parts of the program can cause maintainability problems

24. CS 240, Prof. Sarwar Slide 24 User interface prototyping l It is impossible to pre-specify the look and feel of a user interface in an effective way. prototyping is essential l UI development consumes an increasing part of overall system development costs l User interface generators may be used to ‘draw’ the interface and simulate its functionality with components associated with interface entities l Web interfaces may be prototyped using a web site editor

25. CS 240, Prof. Sarwar Slide 25 Architectural Design l Establishing the overall structure of a software system

26. CS 240, Prof. Sarwar Slide 26 Objectives l To introduce architectural design and to discuss its importance l To explain why multiple models are required to document a software architecture l To describe types of architectural model that may be used l To discuss how domain-specific reference models may be used as a basis for product-lines and to compare software architectures

27. CS 240, Prof. Sarwar Slide 27 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures

28. CS 240, Prof. Sarwar Slide 28 Software architecture l The design process for identifying the sub-systems making up a system and the framework for sub- system control and communication is architectural design l The output of this design process is a description of the software architecture

29. CS 240, Prof. Sarwar Slide 29 Architectural design l An early stage of the system design process l Represents the link between specification and design processes l Often carried out in parallel with some specification activities l It involves identifying major system components and their communications

30. CS 240, Prof. Sarwar Slide 30 Advantages of explicit architecture l Stakeholder communication  Architecture may be used as a focus of discussion by system stakeholders l System analysis  Means that analysis of whether the system can meet its non- functional requirements is possible l Large-scale reuse  The architecture may be reusable across a range of systems

31. CS 240, Prof. Sarwar Slide 31 Architectural design process l System structuring  The system is decomposed into several principal sub-systems and communications between these sub-systems are identified l Control modelling  A model of the control relationships between the different parts of the system is established l Modular decomposition  The identified sub-systems are decomposed into modules

32. CS 240, Prof. Sarwar Slide 32 Sub-systems and modules l There is no clear distinctions: l A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. l A module is a system component that provides services to other components but would not normally be considered as a separate system

33. CS 240, Prof. Sarwar Slide 33 Architectural models l Different architectural models may be produced during the design process l Each model presents different perspectives on the architecture

34. CS 240, Prof. Sarwar Slide 34 Architectural models l Static structural model that shows the major system components l Dynamic process model that shows the process structure of the system l Interface model that defines sub-system interfaces l Relationships model such as a data-flow model

35. CS 240, Prof. Sarwar Slide 35 Architectural styles l The architectural model of a system may conform to a generic architectural model or style l An awareness of these styles can simplify the problem of defining system architectures l However, most large systems are heterogeneous and do not follow a single architectural style

36. CS 240, Prof. Sarwar Slide 36 Architecture attributes l Performance  Localise operations to minimise sub-system communication l Security  Use a layered architecture with critical assets in inner layers l Safety  Isolate safety-critical components l Availability  Include redundant components in the architecture l Maintainability  Use fine-grain, self-contained components

37. CS 240, Prof. Sarwar Slide 37 System structuring l Concerned with decomposing the system into interacting sub-systems l The architectural design is normally expressed as a block diagram presenting an overview of the system structure l More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed

38. CS 240, Prof. Sarwar Slide 38 Packing robot control system

39. CS 240, Prof. Sarwar Slide 39 The repository model l Sub-systems must exchange data. This may be done in two ways:  Shared data is held in a central database or repository and may be accessed by all sub-systems  Each sub-system maintains its own database and passes data explicitly to other sub-systems l When large amounts of data are to be shared, the repository model of sharing is most commonly used

40. CS 240, Prof. Sarwar Slide 40 CASE toolset architecture

41. CS 240, Prof. Sarwar Slide 41 Repository model characteristics l Advantages  Efficient way to share large amounts of data  Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc.  Sharing model is published as the repository schema l Disadvantages  Sub-systems must agree on a repository data model. Inevitably a compromise  Data evolution is difficult and expensive  No scope for specific management policies  Difficult to distribute efficiently

42. CS 240, Prof. Sarwar Slide 42 Client-server architecture l Distributed system model which shows how data and processing is distributed across a range of components l Set of stand-alone servers which provide specific services such as printing, data management, etc. l Set of clients which call on these services l Network which allows clients to access servers

43. CS 240, Prof. Sarwar Slide 43 Film and picture library

44. CS 240, Prof. Sarwar Slide 44 Client-server characteristics l Advantages  Distribution of data is straightforward  Makes effective use of networked systems. May require cheaper hardware  Easy to add new servers or upgrade existing servers l Disadvantages  No shared data model so sub-systems use different data organisation. data interchange may be inefficient  Redundant management in each server  No central register of names and services - it may be hard to find out what servers and services are available

45. CS 240, Prof. Sarwar Slide 45 Abstract machine model l Used to model the interfacing of sub-systems l Organises the system into a set of layers (or abstract machines) each of which provide a set of services l Supports the incremental development of sub- systems in different layers. When a layer interface changes, only the adjacent layer is affected l However, often difficult to structure systems in this way

46. CS 240, Prof. Sarwar Slide 46 Version management system

47. CS 240, Prof. Sarwar Slide 47 Control models l Are concerned with the control flow between sub- systems. Distinct from the system decomposition model l Centralised control  One sub-system has overall responsibility for control and starts and stops other sub-systems l Event-based control  Each sub-system can respond to externally generated events from other sub-systems or the system’s environment

48. CS 240, Prof. Sarwar Slide 48 Centralised control l A control sub-system takes responsibility for managing the execution of other sub-systems l Call-return model  Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems l Manager model  Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement

49. CS 240, Prof. Sarwar Slide 49 Call-return model

50. CS 240, Prof. Sarwar Slide 50 Real-time system control

51. CS 240, Prof. Sarwar Slide 51 Event-driven systems l Driven by externally generated events where the timing of the event is outwith the control of the sub- systems which process the event l Two principal event-driven models  Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so  Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing l Other event driven models include spreadsheets and production systems

52. CS 240, Prof. Sarwar Slide 52 Broadcast model l Effective in integrating sub-systems on different computers in a network l Sub-systems register an interest in specific events. When these occur, control is transferred to the sub- system which can handle the event l Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them l However, sub-systems don’t know if or when an event will be handled

53. CS 240, Prof. Sarwar Slide 53 Selective broadcasting

54. CS 240, Prof. Sarwar Slide 54 Interrupt-driven systems l Used in real-time systems where fast response to an event is essential l There are known interrupt types with a handler defined for each type l Each type is associated with a memory location and a hardware switch causes transfer to its handler l Allows fast response but complex to program and difficult to validate

55. CS 240, Prof. Sarwar Slide 55 Interrupt-driven control

56. CS 240, Prof. Sarwar Slide 56 Modular decomposition l Another structural level where sub-systems are decomposed into modules l Two modular decomposition models covered  An object model where the system is decomposed into interacting objects  A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model l If possible, decisions about concurrency should be delayed until modules are implemented

57. CS 240, Prof. Sarwar Slide 57 Object models l Structure the system into a set of loosely coupled objects with well-defined interfaces l Object-oriented decomposition is concerned with identifying object classes, their attributes and operations l When implemented, objects are created from these classes and some control model used to coordinate object operations

58. CS 240, Prof. Sarwar Slide 58 Invoice processing system

59. CS 240, Prof. Sarwar Slide 59 Data-flow models l Functional transformations process their inputs to produce outputs l May be referred to as a pipe and filter model (as in UNIX shell) l Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems l Not really suitable for interactive systems

60. CS 240, Prof. Sarwar Slide 60 Invoice processing system

61. CS 240, Prof. Sarwar Slide 61 Domain-specific architectures l Architectural models which are specific to some application domain l Two types of domain-specific model  Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems  Reference models which are more abstract, idealised model. Provide a means of information about that class of system and of comparing different architectures l Generic models are usually bottom-up models; Reference models are top-down models

62. CS 240, Prof. Sarwar Slide 62 Generic models l Compiler model is a well-known example although other models exist in more specialised application domains  Lexical analyser  Symbol table  Syntax analyser  Syntax tree  Semantic analyser  Code generator l Generic compiler model may be organised according to different architectural models

63. CS 240, Prof. Sarwar Slide 63 Compiler model

64. CS 240, Prof. Sarwar Slide 64 Language processing system

65. CS 240, Prof. Sarwar Slide 65 Reference architectures l Reference models are derived from a study of the application domain rather than from existing systems l May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated l OSI model is a layered model for communication systems

66. CS 240, Prof. Sarwar Slide 66 OSI reference model Application

67. CS 240, Prof. Sarwar Slide 67 Key points l The software architect is responsible for deriving a structural system model, a control model and a sub- system decomposition model l Large systems rarely conform to a single architectural model l System decomposition models include repository models, client-server models and abstract machine models l Control models include centralised control and event-driven models

68. CS 240, Prof. Sarwar Slide 68 Key points l Modular decomposition models include data-flow and object models l Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models