1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu https://ase.cs.columbia.edu/ October 11, 2011COMS W41561

2. October 11, 2011COMS W41562 Topics covered in this lecture Introduction to software design Architectural styles Distributed architectures

3. October 11, 2011COMS W41563 Software Design

4. October 11, 2011COMS W41564 What is Design? From Merriam-Webster Online Dictionary ( http://www.m-w.com/dictionary/design) http://www.m-w.com/dictionary/design Main Entry: 1 de·sign Pronunciation: di-'zIn Function: verb Etymology: Middle English, to outline, indicate, mean, from Anglo-French & Medieval Latin; Anglo-French designer to designate, from Medieval Latin designare, from Latin, to mark out, from de- + signare to mark -- more at SIGNSIGN transitive verb 1 : to create, fashion, execute, or construct according to plan : DEVISE, CONTRIVE 2 a : to conceive and plan out in the mind b : to have as a purpose : INTEND c : to devise for a specific function or end 3 archaic : to indicate with a distinctive mark, sign, or name 4 a : to make a drawing, pattern, or sketch of b : to draw the plans for DEVISECONTRIVEINTEND intransitive verb 1 : to conceive or execute a plan 2 : to draw, lay out, or prepare a design - de·sign·ed·ly /-'zI-n&d-lE/ adverb

5. October 11, 2011COMS W41565 What is Design? The realization of an imagined state To work out a solution in one’s mind The specification that guides production The transition from possible solutions to a specific one To devise a solution to a perceived problem …

6. October 11, 2011COMS W41566 Design designerprojectcustomer outcome space design space C D CC D F SP A design product is a point in the design space that represents a set of decisions that together delineate a set of possible outcomes in the outcome space C = conceivable F = feasible D = desirable SP = still possible

7. October 11, 2011COMS W41567 Design designerprojectcustomer outcome space design space C D CC D F C = conceivable F = feasible D = desirable SP = still possible A successful design product restricts the set of still possible outcomes to those that are both feasible and desirable D F SP

8. October 11, 2011COMS W41568 Software Design Concerned with making major decisions, often of a structural nature Shares with programming a concern for abstracting information representation and processing sequences, but at a different level Builds coherent, well-planned representations of programs that concentrate on –the interrelationships of parts at the higher levels –the logical operations at the lower levels

9. October 11, 2011COMS W41569 Software Design Architectural design - “How does it all fit together?” –High-level partitioning of a software system into separate modules (components) –Focus on the interactions among parts (connections) –Focus on structural properties (configuration) Modular design - “How does it work?” –Detailed design of a component (unit, class, file) –Focus on the internals of a component and computational properties (data structures, algorithms)

10. October 11, 2011COMS W415610 Example Architectural design Modular design Provided Interface Audio Encoder Required Interface Provided Interface Tuner Required Interface Provided Interface Audio Player Required Interface Compressor Provided Interface EncoderReader Required Interface

11. October 11, 2011COMS W415611 Compare to Building Architecture Overall shape of the physical structure Manner in which the various components of the building are integrated to form a whole The way in which the building fits into its environment and meshes with other buildings in its vicinity Degree to which the building meets its stated purpose and satisfies the needs of its owner

12. October 11, 2011COMS W415612 Building Architecture Has Many Levels

13. October 11, 2011COMS W415613 Architectural Design Elements Floors Walls Rooms Types Office building Villa Aircraft hanger Elements Components Interfaces Messages Types Office automation Game Space shuttle control Buildings Software

14. October 11, 2011COMS W415614 Architectural Design Styles Colonial Cape Cod Ranch Rules and regulations Electrical Structural Styles Pipe and filter Layered Implicit invocation Rules and regulations Use of interfaces Conforms to Component Model Buildings Software

15. October 11, 2011COMS W415615 Software Architecture A high-level model of a (non-physical) thing –Describes critical aspects of the thing –Understandable to many stakeholders –Allows evaluation of the thing’s properties before it is built –Provides well understood tools and techniques for constructing the thing from its blueprint A representation that enables a software engineer to –Analyze the effectiveness of the design in meeting its stated requirements –Consider architectural alternatives at a stage when making design changes is still relatively easy –Reduce the risks associated with the construction of the software

16. October 11, 2011COMS W415616 What is the Problem? This is a simple software system!

17. October 11, 2011COMS W415617 Design Abstraction

18. October 11, 2011COMS W415618 Architectural Abstraction

19. October 11, 2011COMS W415619 Software Architecture: Essentials Components –What are the main parts? –What aspects of the requirements do they correspond to? –Both processing elements and data elements –Can be simple or composite –Examples: abstract data types, filters, databases, GUIs, servers Connections –How do components communicate? –Model interactions among components and rules that govern those interactions –Don’t forget initialization/finalization dependencies –Examples: shared variables, procedure calls, messages, multicast, pipes

20. October 11, 2011COMS W415620 Software Architecture: Essentials Configurations –What is the topology? –Connected graph of components and connectors that describes architectural structure –Defines proper connectivity, concurrent and distributed properties, adherence to architectural style Constraints on change (“load bearing walls”) –Architectural erosion due to violations of the architecture – increases brittleness –Architectural drift due to insensitivity to the architecture – leads to inadaptability then disasters

21. October 11, 2011COMS W415621 Comparison to Programming (of Modules) ArchitectureModules interaction among parts implementation of parts structural properties computational properties system-level performance algorithmic performance outside module boundary inside module boundary

22. October 11, 2011COMS W415622 Comparison to Hardware Architecture Two important characteristics of hardware: –Relatively small number of design elements. –Scale is achieved by replication of these design elements. Similarity between Software and Hardware Architectures: –Analogies to organization and configuration Differences between Software and Hardware Architectures: –Software requires large number of design elements. –Scale is achieved (in many cases) by adding more distinct elements.

23. October 11, 2011COMS W415623 Comparison to Network Architecture Nodes and Connections act as the design elements. Features: –Two components – Nodes and Connections. –Only a few topologies are considered (star, ring, grid). In software architecture, –Two components – Processes and Interprocess communication. –Large number of possible topologies, many without any proper names.

24. October 11, 2011COMS W415624 We Can Do Anything… Provided Interface Big Component Required Interface Provided Interface Tiny Component Required Interface Provided Interface B Component Required Interface Provided Interface Mr. Component Required Interface Provided Interface A Component Required Interface Provided Interface Yet Another Component Required Interface Provided Interface Some Component Required Interface Provided Interface One Component Required Interface Provided Interface Ms. Component Required Interface

25. October 11, 2011COMS W415625 …But Style Has Proven Helpful Architectural “styles” restrict the way in which components can be connected –Prescribe patterns of interaction –Promote fundamental principles Rigor, separation of concerns, anticipation of change, generality, incrementality Low coupling among elements High cohesion within elements Architectural styles are based on success stories –Almost all compilers are built as “pipe-and-filter” –Almost all network protocols are built as “layers”

26. October 11, 2011COMS W415626 Architectural Styles

27. October 11, 2011COMS W415627 Architectural styles The architectural model of a system may conform to a generic architectural style. An awareness of these styles can simplify the problem of defining system architectures. However, many large systems are heterogeneous and do not follow a single architectural style.

28. October 11, 2011COMS W415628 System organization Reflects the basic strategy that is used to structure a system. Three organizational styles are widely used: –A shared data repository style; –A shared services and servers style; –An abstract machine or layered style.

29. October 11, 2011COMS W415629 Repository model Sub-systems must exchange data. This may be done in two ways: –Shared data is held in a central database (or other kind of repository) and may be accessed by all sub-systems; –Each sub-system maintains its own database and passes data explicitly to other sub-systems. When large amounts of data are to be shared, the repository model of sharing is most commonly used.

30. October 11, 2011COMS W415630 IDE toolset architecture

31. October 11, 2011COMS W415631 Repository model advantages Efficient way to share large amounts of data. Sub-systems need not be concerned with how data is produced. Centralized management, e.g., backup, user authentication, etc. Sharing model is published as the repository schema.

32. October 11, 2011COMS W415632 Repository model disadvantages Sub-systems must agree on a repository data model - inevitably a compromise. Data evolution is difficult and expensive. No provision for specific local policies. Difficult to distribute efficiently.

33. October 11, 2011COMS W415633 Client-server model Distributed system model that dictates how data and processing services are distributed across a range of components. Set of clients that call on these services. Network that allows clients to access servers.

34. October 11, 2011COMS W415634 Film and picture library

35. October 11, 2011COMS W415635 Client-server advantages Distribution of data is straightforward. Makes effective use of networked systems. May allow cheaper hardware (particularly when different services are provided by different servers, as opposed to a single all-in- one server). Easy to add new servers or upgrade existing servers.

36. October 11, 2011COMS W415636 Client-server disadvantages No shared data model so sub-systems use different data organization - data interchange may be inefficient. Redundant management in each server. Not necessarily any central register of names and services - it may be hard to find out what servers and services are available.

37. October 11, 2011COMS W415637 Abstract machine (layered) model Used to model the interfacing of sub-systems. Organizes the system into a set of layers (or abstract machines), each of which provides a set of services. Supports the incremental development of sub- systems in different layers: When a layer interface changes, only the adjacent layer is affected. However, sometimes artificial to structure systems in this way.

38. October 11, 2011COMS W415638 Version management system

39. October 11, 2011COMS W415639 Modular decomposition styles Concerned with decomposing sub-systems into modules. No rigid distinction between system organization and modular decomposition.

40. October 11, 2011COMS W415640 Sub-systems and modules A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. A module is a system component that provides services to other components but would not normally be considered as a separate system.

41. October 11, 2011COMS W415641 Modular decomposition Another structural level where sub-systems are decomposed into modules. Two major modular decomposition models: –An object model where the system is decomposed into interacting objects; –A pipeline or data-flow model where the system is decomposed into functional modules that transform inputs to outputs. If possible, decisions about concurrency should be delayed until modules are implemented.

42. October 11, 2011COMS W415642 Object models Structure the system into a set of loosely coupled objects with well-defined interfaces. Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. When implemented, objects are created from these classes and some control model is used to coordinate object operations.

43. October 11, 2011COMS W415643 Invoice processing system

44. October 11, 2011COMS W415644 Object model characteristics Objects are loosely coupled so their implementations can be modified without affecting other objects. The objects may reflect real-world entities. OO implementation languages are widely used. However, object interface changes may cause problems, and complex entities may be hard to represent as objects.

45. October 11, 2011COMS W415645 Function-oriented pipelining Functional transformations process their inputs to produce outputs. Often referred to as a pipe-and-filter model (as in UNIX shell). When transformations are sequential, this is a batch sequential model - which is extensively used in data processing systems. May not be suitable for interactive systems.

46. October 11, 2011COMS W415646 Invoice processing system

47. October 11, 2011COMS W415647 Pipeline model characteristics Supports transformation reuse. Intuitive organization for stakeholder communication. Easy to add new transformations. Relatively simple to implement as either a concurrent or sequential system. However, requires a common format for data transfer along the pipeline and its difficult to support event-based interaction.

48. October 11, 2011COMS W415648 Control styles Concerned with the control flow between sub- systems (distinct from the system decomposition model). Centralized control –One sub-system has overall responsibility for control, and starts and stops other sub-systems. Event-based control –Each sub-system can respond to externally generated events from other sub-systems or the system’s environment.

49. October 11, 2011COMS W415649 Centralized control A control sub-system takes responsibility for managing the execution of other sub-systems. Call-return model –Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems. Manager model –One system component controls the stopping, starting and coordination of other system processes. Applicable to concurrent systems. Can also be implemented in sequential systems as a case statement.

50. October 11, 2011COMS W415650 Call-return model

51. October 11, 2011COMS W415651 Real-time system control

52. October 11, 2011COMS W415652 Event-driven systems Driven by externally generated events where the timing of each event is outside the control of the sub- systems that process the event. Two principal event-driven models: –Broadcast models - An event is broadcast to all sub- systems. Any sub-system that can handle the event may do so. –Interrupt-driven models - Used in real-time systems (and at OS device driver level) where interrupts are detected by an interrupt handler and passed to some other component for processing. Other event-driven models include spreadsheets and rule-based production systems.

53. October 11, 2011COMS W415653 Broadcast model Effective in integrating sub-systems on different computers in a network. Sub-systems register an interest in specific events. When these occur, control is transferred to the sub- system that can handle the event. Control policy is not embedded in the event and message handler: sub-systems decide on events of interest to them. However, sub-systems don’t know if or when an event (outside their interest) will be handled.

54. October 11, 2011COMS W415654 Selective broadcasting

55. October 11, 2011COMS W415655 Interrupt-driven systems Used in real-time systems where fast response to an event is essential. There are known interrupt types with a handler defined for each type. Each type is associated with a memory location and a hardware switch causes transfer to its handler. Allows fast response but complex to program and difficult to validate.

56. October 11, 2011COMS W415656 Interrupt-driven control

57. October 11, 2011COMS W415657 Distributed Systems Architectures

58. October 11, 2011COMS W415658 System types Personal systems that are not distributed and that are designed to run on a personal computer or workstation. Embedded systems that run on a single processor or on an integrated group of processors. Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.

59. October 11, 2011COMS W415659 Distributed systems Virtually all large software-based systems are now distributed systems. Information processing is distributed over several computers rather than confined to a single machine.

60. October 11, 2011COMS W415660 Distributed system characteristics Resource sharing –Sharing of hardware and software resources. Openness –Use of equipment and software from different vendors. Concurrency –Concurrent processing to enhance performance. Scalability –Increased throughput by adding new resources. Fault tolerance –The ability to continue in operation after a fault has occurred.

61. October 11, 2011COMS W415661 Distributed system disadvantages Complexity –Distributed systems are typically more complex than centralized systems. Security –More susceptible to external attack. Manageability –More effort required for system management. Unpredictability –Unpredictable responses depending on the system organization and network load.

62. October 11, 2011COMS W415662 Distributed systems architectures Client-server architectures –Distributed services that are called on by clients. Servers that provide services are treated differently from clients that use services. Distributed object (peer to peer) architectures –No distinction between clients and servers. Any object on the system may provide and use services from other objects.

63. October 11, 2011COMS W415663 Middleware Software that manages and supports the different components of a distributed system. In essence, it sits in the middle of the system. Middleware is usually off-the-shelf rather than specially written software.  Component model frameworks are designed to provide standard middleware for a wide range of software systems.

64. October 11, 2011COMS W415664 Multiprocessor architectures Simplest distributed system model. System composed of multiple processes, which may (but need not) execute on different processors. Distribution of process to processor may be pre-ordered or may be under the control of a dispatcher.

65. October 11, 2011COMS W415665 A multiprocessor traffic control system

66. October 11, 2011COMS W415666 Client-server architectures The application is modelled as a set of services that are provided by servers and a set of clients that use these services. Clients know of servers but servers need not know of clients. Clients and servers are logical processes. The mapping of processors to processes is not necessarily 1 : 1.

67. October 11, 2011COMS W415667 A client-server system

68. October 11, 2011COMS W415668 Computers in a C/S network

69. October 11, 2011COMS W415669 Layered application architecture Presentation layer –Concerned with presenting the results of a computation to system users and with collecting user inputs. Application processing layer –Concerned with providing application specific functionality, e.g., in a banking system, banking functions such as open account, close account, etc. Data management layer –Concerned with managing the system databases or other repositories.

70. October 11, 2011COMS W415670 Application layers

71. October 11, 2011COMS W415671 Thin and fat clients Thin-client model –In a thin-client model, all of the application processing and data management is carried out on the server. The client is simply responsible for running the presentation software. Fat-client model –In this model, the server is only responsible for data management. The software on the client implements the application logic and the interactions with the system user.

72. October 11, 2011COMS W415672 Thin and fat clients

73. October 11, 2011COMS W415673 Thin client model Often used when legacy systems are migrated to client-server architectures. –The legacy system acts as a server in its own right with a graphical interface implemented on a client. Recently used for web-based applications. A major disadvantage is that it places a heavy processing load on both the server and the network.

74. October 11, 2011COMS W415674 Fat client model More processing is delegated to the client as the application processing is locally executed. Most suitable for new C/S systems where the capabilities of the client system are known in advance. More complex than a thin client model, especially for management. New versions of the application have to be installed on all clients.

75. October 11, 2011COMS W415675 A client-server ATM system

76. October 11, 2011COMS W415676 Three-tier architectures In a three-tier architecture, each of the application architecture layers may execute on a separate processor. Allows for better performance than a thin-client approach and is simpler to manage than a fat- client approach. A more scalable architecture - as demands increase, extra servers can be added.

77. October 11, 2011COMS W415677 A 3-tier C/S architecture

78. October 11, 2011COMS W415678 An Internet banking system

79. October 11, 2011COMS W415679 Distributed object architectures There is no distinction in a distributed object architecture between clients and servers. Each distributable entity is an object that provides services to other objects and receives services from other objects. Object communication through a middleware system, often called an object request broker (ORB). Distributed object architectures are generally more complex to design than C/S systems.

80. October 11, 2011COMS W415680 Distributed object architecture

81. October 11, 2011COMS W415681 Advantages of distributed object architectures Allows the system designer to delay decisions on where and how services should be provided. A very open system architecture that allows new resources to be added as required. Flexible and scaleable. It is possible to reconfigure the system dynamically with objects migrating across the network as required.

82. October 11, 2011COMS W415682 Uses of distributed object architectures As a logical model that allows you to structure and organize the system. In this case, you think about how to provide application functionality solely in terms of services and combinations of services. As a flexible approach to the implementation of client-server systems. The logical model of the system is client-server, but both clients and servers are realized as distributed objects communicating through a common communication framework.

83. October 11, 2011COMS W415683 A data mining system

84. October 11, 2011COMS W415684 Data mining system Allows the number of databases that are accessed to be increased without disrupting the system. Allows new types of relationships to be mined by adding new integrator objects.

85. Upcoming Assignments October 11, 2011COMS W415685

86. Upcoming Assignments First Iteration Plan due Thursday 13 October, 10am First Iteration Plan First Iteration First Progress Report due Thursday 20 October, 10am First Iteration First Progress Report First Iteration Second Progress Report due Thursday 27 October, 10am First Iteration Second Progress Report October 11, 2011COMS W415686

87. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu https://ase.cs.columbia.edu/ October 11, 2011COMS W415687