1. 11 October 2007Kaiser: COMS W4156 Fall 20071 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

2. 11 October 2007Kaiser: COMS W4156 Fall 20072 Software Process Requirements – –As specified by the customer or user Architectural Design – –Selection of architectural elements (components), their interactions (connections), and the constraints on those elements (possibly in part required and/or enforced by component model framework) –Selection should satisfy the requirements –Selection should serve as the base for the modular design Modular Design – –Detailed algorithms and data structures –Should satisfy the requirements and the architecture Implementation – –Representation of algorithms and data structures in code –Should satisfy the requirements, architecture and modular design …

3. 11 October 2007Kaiser: COMS W4156 Fall 20073 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

4. 11 October 2007Kaiser: COMS W4156 Fall 20074 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 …

5. 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

6. 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 D

7. 11 October 2007Kaiser: COMS W4156 Fall 20077 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 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

8. 11 October 2007Kaiser: COMS W4156 Fall 20078 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) –Focus on the internals of a component and computational properties (data structures, algorithms)  Important note: The “component-level design” for the 1 st progress report is here part of what is called “architectural design”

9. Example Architectural design Module design Provided Interface Audio Encoder Required Interface Provided Interface Tuner Required Interface Provided Interface Audio Player Required Interface Compressor Provided Interface EncoderReader Required Interface

10. 11 October 2007Kaiser: COMS W4156 Fall 200710 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

11. Building Architecture Has Many Levels

12. 11 October 2007Kaiser: COMS W4156 Fall 200712 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

13. 11 October 2007Kaiser: COMS W4156 Fall 200713 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

14. 11 October 2007Kaiser: COMS W4156 Fall 200714 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

15. 11 October 2007Kaiser: COMS W4156 Fall 200715 What is the Problem? This is a simple software system!

16. 11 October 2007Kaiser: COMS W4156 Fall 200716 Design Abstraction

17. 11 October 2007Kaiser: COMS W4156 Fall 200717 Architectural Abstraction

18. 11 October 2007Kaiser: COMS W4156 Fall 200718 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

19. 11 October 2007Kaiser: COMS W4156 Fall 200719 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 problems and brittleness –Architectural drift – due to insensitivity about the architecture – leads to inadaptability then disasters

20. 11 October 2007Kaiser: COMS W4156 Fall 200720 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

21. 11 October 2007Kaiser: COMS W4156 Fall 200721 Comparison to Hardware Architecture Two important features: –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.

22. 11 October 2007Kaiser: COMS W4156 Fall 200722 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.

23. 11 October 2007Kaiser: COMS W4156 Fall 200723 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 Component Required Interface Provided Interface Some Component Required Interface Provided Interface One Component Required Interface Provided Interface Mrs. Component Required Interface

24. 11 October 2007Kaiser: COMS W4156 Fall 200724 …But Style Has Proven to Help 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 build as “pipe-and-filter” –Almost all network protocols are build as “layers”

25. 11 October 2007Kaiser: COMS W4156 Fall 200725 Separation of Concerns “The programmer is having to do several things at the same time: 1.describe what is to be computed; 2.organize the computation sequencing into small steps; 3.organize memory management during the computation. Ideally, the programmer should be able to concentrate on one of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks.” [Chris Reade, Elements of Functional Programming, 1989] Component services aim to remove additional administrative tasks (e.g., security, transactions, persistence) from the programmer’s concern

26. 11 October 2007Kaiser: COMS W4156 Fall 200726 Cohesion and Coupling Cohesion is a property or characteristic of an individual unit Coupling is a property of a collection of units High cohesion GOOD, high coupling BAD Design for change –Reduce interdependency (coupling): You don't want a change in one unit to ripple throughout your system –Group functionality (cohesion): Easier to find things, intuitive metaphor aids understanding

27. 11 October 2007Kaiser: COMS W4156 Fall 200727 Cohesion The measure of strength of the association of elements within a unit Cohesion scale: –Functional cohesion (strongest, most desirable) –Sequential cohesion –Communicational cohesion –Procedural cohesion –Temporal cohesion –Logical cohesion –Coincidental cohesion(weakest, undesirable)

28. 11 October 2007Kaiser: COMS W4156 Fall 200728 Cohesion Coincidental cohesion - elements have no meaningful relationship to one another Logical cohesion - elements perform similar activities, but the activities to be executed are chosen from outside the unit Temporal cohesion - elements are related in time (all should be done together)

29. 11 October 2007Kaiser: COMS W4156 Fall 200729 Cohesion Communicational cohesion - elements perform different functions, but each function references the same input or output information Sequential (or informational) cohesion - elements are related such that output data from one serves as input data to the next Functional cohesion - elements contribute to a single, well-defined task

30. 11 October 2007Kaiser: COMS W4156 Fall 200730 Coupling A measure of the interdependence of one software unit to another Coupling scale –Content coupling(worst) –Common coupling –Control coupling –Stamp coupling –Data coupling(best / minimal needed coupling) –No direct coupling

31. 11 October 2007Kaiser: COMS W4156 Fall 200731 Coupling No Direct Coupling - Independent Data Coupling - Communicate by passing parameters Stamp Coupling - Communicate via a passed data structure that contains more information than necessary for the two units to perform their functions

32. 11 October 2007Kaiser: COMS W4156 Fall 200732 Coupling Control Coupling - Communicate using at least one "control flag" Common Coupling - Share the same global data area Content Coupling – –One unit changes a statement in another (usually applicable only to interpreted languages) –One unit references or alters data contained inside another –One unit branches into another

33. 11 October 2007Kaiser: COMS W4156 Fall 200733 …But Style Has Proven to Help 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 build as “pipe-and-filter” –Almost all network protocols are build as “layers”

34. 11 October 2007Kaiser: COMS W4156 Fall 200734 Hierarchy Connections are function or method calls Provided Interface Main component Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface

35. 11 October 2007Kaiser: COMS W4156 Fall 200735 Client-Server Connections are remote procedure calls or remote method invocations Provided Interface Client Required Interface Provided Interface Client Required Interface Provided Interface Client Required Interface Provided Interface Server Required Interface

36. 11 October 2007Kaiser: COMS W4156 Fall 200736 Blackboard Connections are encapsulated global variables (tuple spaces) Provided Interface Blackboard Provided Interface One “Part” Required Interface Provided Interface My “Bit” Required Interface Provided Interface Her “Piece” Required Interface Provided Interface A “Part” Required Interface Provided Interface Another “Piece” Required Interface Provided Interface His “Bit” Required Interface

37. 11 October 2007Kaiser: COMS W4156 Fall 200737 Peer-to-Peer Connections are remote procedure calls or remote method invocations Provided Interface Peer Required Interface Provided Interface Peer Required Interface Provided Interface Peer Required Interface

38. 11 October 2007Kaiser: COMS W4156 Fall 200738 Pipe-and-Filter Connections are pipes (also called data flows) Provided Interface Filter Required InterfaceProvided Interface Filter Required InterfaceProvided Interface Filter Required InterfaceProvided Interface Filter Required Interface

39. 11 October 2007Kaiser: COMS W4156 Fall 200739 Implicit Invocation Connections are events on the software bus Provided Interface Component Required Interface Provided Interface Component Required Interface Provided Interface Component Required Interface Provided Interface Component Required Interface Provided Interface Bus Required Interface

40. 11 October 2007Kaiser: COMS W4156 Fall 200740 Layers Connections are function or method calls + “something in between” Provided Interface Layer 4 Required Interface Provided Interface Layer 3 Required Interface Provided Interface Layer 2 Required Interface Provided Interface Layer 1 Required Interface Provided Interface Layer 4 Required Interface Provided Interface Layer 3 Required Interface Provided Interface Layer 2 Required Interface Provided Interface Layer 1 Required Interface

41. 11 October 2007Kaiser: COMS W4156 Fall 200741 Another Kind of Layers Connections are function or method calls extended basic core

42. 11 October 2007Kaiser: COMS W4156 Fall 200742 Many Other (Variants of) Styles Interpreters (“little languages”) Batch sequential (degenerate case of pipe/filter) Distribution broker (e.g., CORBA) Plug-in (e.g., web browsers, Eclipse) Representational State Transfer (e.g., Web) Shared Nothing (e.g., google) Three-tier (e.g., application servers) …

43. Example – Compiler SequentialParallel

44. 11 October 2007Kaiser: COMS W4156 Fall 200744 Example - CASE toolset

45. 11 October 2007Kaiser: COMS W4156 Fall 200745 Example - Version management system

46. 11 October 2007Kaiser: COMS W4156 Fall 200746 Example - Film and picture library

47. Example – Packing robot control system

48. 11 October 2007Kaiser: COMS W4156 Fall 200748 Choosing the Right Style Does a certain style makes sense? –The Internet as a blackboard - Does that scale? –Stock exchange as a layers - How to deal with the continuous change? –Math as hierarchy - How to properly call different modules for different functions? Draw a picture of the major entities Look for the natural paradigm Look for what “feels right”

49. 11 October 2007Kaiser: COMS W4156 Fall 200749 Mixing Styles May Be Necessary Blackboard + Client-Server Provided Interface Blackboard Provided Interface One “Part” Required Interface Provided Interface My “Bit” Required Interface Provided Interface Her “Piece” Required Interface Provided Interface A “Part” Required Interface Provided Interface Another “Piece” Required Interface Provided Interface His “Bit” Required Interface

50. 11 October 2007Kaiser: COMS W4156 Fall 200750 Mixing Styles May Be Necessary Blackboard + Implicit Invocation Provided Interface Blackboard Provided Interface One “Part” Required Interface Provided Interface A “Piece” Required Interface Provided Interface Some “Bit” Required Interface Provided Interface Bus Required Interface

51. 11 October 2007Kaiser: COMS W4156 Fall 200751 Mixing Styles May Be Necessary Pipe-and-Filter + Hierarchy Pipe FCalls Provided Interface Audio Encoder Required Interface Provided Interface Tuner Required Interface Provided Interface Audio Player Required Interface

52. 11 October 2007Kaiser: COMS W4156 Fall 200752 Architectural Models Different architectural models may be produced during the design process Each model presents different perspectives on the architecture –Static structural model that shows the major system components –Interface model that defines sub-system interfaces –Dynamic process model that shows the process structure of the system –Deployment model shows the relationship between system elements and hosts  Important note: 1 st iteration progress report seeks all of these

53. 11 October 2007Kaiser: COMS W4156 Fall 200753 Going from Design to Engineering Tasks System design – captures the essence of the solution –describes what the software system should do “how does it fundamentally approach solving the problem?” focuses more on desirability –typically represents an intermediate “design in progress” –typically captures the overall framing of the solution Implementation design – captures the full solution –describes what the implementer should do “how do we make the approach reality?” focuses more on feasibility –typically represents a final “completed design” –typically captures a fully detailed roadmap  Important Note: Your set of engineering tasks likely to be sketchy in 1 st iteration plan, more detailed/specific in 1 st iteration progress report, but unlikely to be “complete” and “fully detailed” until the 1 st iteration final report (expect change, you probably won’t get it right the first time)

54. 11 October 2007Kaiser: COMS W4156 Fall 200754 Going from Requirements to Engineering Tasks At highest level, most of your systems will follow N-tier architecture –Implies certain infrastructure tasks, e.g., set up application server, database, design data schema Each functional requirement implies that some component will implement it –Implies certain design tasks, to group together requirements into cohesive components –Implies certain design tasks, to expose that functionality via interfaces (component interfaces and/or external interfaces)  Important Note: Your set of engineering tasks likely to be sketchy in 1 st iteration plan, more detailed/specific in 1 st iteration progress report, but unlikely to be “complete” and “fully detailed” until the 1 st iteration final report (expect change, you probably won’t get it right the first time)

55. 11 October 2007Kaiser: COMS W4156 Fall 200755 First Iteration Plan Due Next Week! Tuesday 16 October, 10am Assignments posted on course websitecourse website Submit via CourseWorksCourseWorks First Iteration Plan Samples here and here – warning: the assignment has changed somewhat since last year, do not blindly “pattern match”!here

56. 11 October 2007Kaiser: COMS W4156 Fall 200756 Upcoming Deadlines First iteration progress report due October 23 rdFirst iteration progress report First iteration demo week October 30 th – November 8 th First iteration final report due November 9 th Midterm Individual Assessment posted Friday November 9 th Midterm Individual Assessment due Friday November 16 th

57. 11 October 2007Kaiser: COMS W4156 Fall 200757 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/