1. COP 4009 7 th Lecture October 31, 2005 COP 4009 Component-Based Software Engineering The Art of Design Fall 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Teaching/

2. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 2 Acknowledgements  Dr. George T. Heineman –This course is based on the “CS 509 Design of Software Systems - Spring 2005” by Dr. Heineman with some adjustments to become appropriate for undergraduate students. Dr. Heineman has generously offered his course material (including the slides) and his help during preparation of this course. I am very grateful to him. –The original slides and the course material can be found at:  http://www.cs.wpi.edu/~heineman/html/teaching_/CS509/index.html  Dr. William Councill and other authors of the main textbook  Dr. Clemens Szyperski  Drs. Betty Cheng, Peter Clarke, Bernd Bruegge, and Allen Dutoit

3. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 3 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition  Summary

4. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 4 Motivation “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” - C.A.R. Hoare

5. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 5 Why is Design so Difficult?  Analysis: Focuses on the application domain  Design: Focuses on the solution domain –Design knowledge is a moving target –The reasons for design decisions are changing very rapidly  Halftime knowledge in software engineering: About 3-5 years  What I teach today will be out of date in 3 years  Cost of hardware rapidly sinking  “Design window”: –Time in which design decisions have to be made  Technique –Time-boxed prototyping

6. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 6 The Purpose of System Design  Bridging the gap between desired and existing system in a manageable way  Use Divide and Conquer –We model the new system to be developed as a set of subsystems Problem Existing System New System

7. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 7 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition  Summary

8. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 8 System Design 2. System Layers/Partitions Cohesion/Coupling 5. Data 1. Design Goals Definition Trade-offs 4. Hardware/ Special purpose Software Buy or Build Trade-off Allocation Connectivity 3. Concurrency Data structure Persistent Objects Files Databases Management Access control Security 6. Global Resource Handling 8. Boundary Conditions Initialization Termination Failure Decomposition Mapping 7. Software Control Identification of Threads Monolithic Event-Driven Threads Conc. Processes

9. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 9 Overview  System Design I (this lecture) –0. Overview of System Design –1. Design Goals –2. Subsystem Decomposition  System Design II: Addressing Design Goals (next lecture) –3. Concurrency –4. Hardware/Software Mapping –5. Persistent Data Management –6. Global Resource Handling and Access Control –7. Software Control –8. Boundary Conditions

10. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 10 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition  Summary

11. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 11 List of Design Goals  Reliability  Modifiability  Maintainability  Understandability  Adaptability  Reusability  Efficiency  Portability  Traceability of requirements  Fault tolerance  Backward-compatibility  Cost-effectiveness  Robustness  High-performance  Good documentation  Well-defined interfaces  User-friendliness  Reuse of components  Rapid development  Minimum # of errors  Readability  Ease of learning  Ease of remembering  Ease of use  Increased productivity  Low-cost  Flexibility

12. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 12 Relationship Between Design Goals Reliability Low cost Increased Productivity Backward-Compatibility Traceability of requirements Rapid development Flexibility ClientEnd User Portability Good Documentation Runtime Efficiency Developer Minimum # of errors Modifiability, Readability Reusability, Adaptability Well-defined interfaces Functionality User-friendliness Ease of Use Ease of learning Fault tolerant Robustness Nielson Usability Engineering MMK, HCI Rubin Task Analysis

13. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 13 Typical Design Trade-offs  Functionality vs. Usability  Cost vs. Robustness  Efficiency vs. Portability  Rapid development vs. Functionality  Cost vs. Reusability  Backward Compatibility vs. Readability

14. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 14 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition –Component Modeling –Documentation for Reuse –System Architecture  Summary

15. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 15 Modeling Components  Bad news: –To date, there is no standard for modeling components!  Good news: –We have UML! We use UML  To model the design and implementation representations of components. –To document components for reuse. –UML is becoming more CBSE-aware  UML subsystem (realize multiple interfaces)  UML interfaces (realized by multiple subsystems)

16. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 16 Why no large-scale reuse yet?!  Reuse efforts at implementation level –Technology changes rapidly and standards are only emerging. –No design-level reuse!  Appropriate components are too hard to find  Once found, the documentation is often inadequate  Implementation may differ in execution of key interface responsibilities –If used in a different context, it may not perform as well.  Goal: –To specify the entire realization of a component in such a way that the generation of a particular implementation style can be done automatically. –Distinction between the detailed design and its implementation.

17. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 17 Solution: Using UML to Model  CBSE Promises: –Complexity Management –Encapsulation –Separation of Concerns –Reuse  UML satisfies these promises! –It can model a component’s design and implementation –It can be used as the basis for its reuse documentation

18. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 18 Aspects of Components  Logical aspect –Concerned with its logical abstraction –Its relationship with other logical elements –Its assigned responsibilities  Physical (implementation) aspect –What elements are inside the component –How they realize the contract (interface) of a component –What is the relationship among the elements inside a component –What are the internal and external interactions

19. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 19 Modeling Logical Aspect with UML  UML Subsystems –A design view of the component  A UML Subsystem is a subtype of a UML Package  A subsystem is modeled as –A package annotated with >  An interface is modeled as –A circle –A full rectangle with a small circle in the right top corner –A full rectangle annotated with >  A subsystem is related to the interfaces it realizes –via the realization relationship.

20. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 20 Subsystems & Interfaces «interface» IClipboard + boolean insert (IItem I) + IItem retrieve () «subsystem» Clipboard IClipboard realization

21. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 21 Subsystems and Services  Subsystem (UML: Package) –Collection of classes, associations, operations, events and constraints that are interrelated –Seed for subsystems: UML Objects and Classes.  (Subsystem) Service: –Group of operations provided by the subsystem –Seed for services: Subsystem use cases  Service is specified by Subsystem interface: –Specifies interaction and information flow from/to subsystem boundaries, but not inside the subsystem. –Should be well-defined and small. –Often called API: Application programmer’s interface, but this term should used during implementation, not during System Design

22. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 22 Services and Subsystem Interfaces  Service: A set of related operations that share a common purpose –Notification subsystem service:  LookupChannel()  SubscribeToChannel()  SendNotice()  UnscubscribeFromChannel() –Services are defined in System Design  Subsystem Interface: Set of fully typed related operations. –Subsystem Interfaces are defined in Object Design –Also called application programmer interface (API)

23. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 23 Modeling Physical Aspect with UML  For each realized interface –UML > collaborations can be used –It shows how the subsystem elements interact to satisfy the interface contract. –Inside the collaboration UML diagrams are used to document both the structure and behavioral aspects of the solution:  Class Diagrams –Showing major relationships between subsystem elements –Showing major relationships between other subsystems  Statechart Diagrams –Showing important behavioral aspects of a subsystem as a whole  Interaction Diagrams (Sequence and Collaboration Diagrams) –Showing how the subsystem elements implement the major interface operations

24. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 24 The UML Collaboration  Used to document a “solution to a problem”  Similar to Package –Allows grouping together a set of UML diagrams in order to document how their design satisfies key requirements. –May import and use elements from other namespaces in the model  Unlike a Package –May not own any elements except for a set of placeholders

25. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 25 Internal Structure View «interface» IClipboard + IItem retrieve () + IItem retrieveNth (int n) + IItem retrieve (IDataType type) + IItem retrieveNth (int n, IDataType type) + void clear () + void insert (IItem item) + Enumeration types () + IItem newItemInstance (IDataType t, Object o) + IDataType newDataTypeInstance (String s) «subsystem» Clipboard «interface» IClipboardGUI + setAccessor (IClipboardAccessor i) + showClipboard (boolean b) «interface» IClipboardAccessor + requestClear() + requestCopy() + requestPaste() + requestPasteAll() requires ???

26. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 26 Object Sequence Diagram (copy) aClipboardClient:Clipboard :IClipboardAccessor 1. IDataType newDataTypeInstance (String s) 2. IItem newItemInstance (IDataType t, Object o) 3. Insert (IItem item)

27. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 27 Object Sequence Diagram (paste) aClipboardClient:Clipboard :IClipboardAccessor 1. IItem retrieve ()

28. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 28 Object Sequence Diagram aClipboardClient:Clipboard :IClipboardAccessor :ClipboardGUI 1. void showClipboard (true) 1.1 activateFrame (true) 2. RequestPaste () 2.1 IItem retrieve () show paste

29. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 29 Object Sequence Diagram  Identify interactions at design level – ordering of method invocations – dependencies (causal and data)  Interface associations – generic usage of interface  Component association – specific usage of interface

30. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 30 Object Collaboration Diagram  More compact representation :Ca:Cb :Cc 1. MethodInvocation () 4. somethingElse() 2. MethodY 3. MethodZ

31. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 31 Modeling the Implementation Rep.  Defines how its logical representation is implemented in the chosen environment.  It defines the mapping between subsystems and components in the chosen environment.  We use UML Components for this –Different UML component stereotypes can be used to distinguish different types of implementation elements  >, >, >, >, >, etc. –A UML component is the physical realization of one or more UML subsystems. –Avoid it if there is an obvious mapping.

32. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 32 Mapping subsystem to component  The transformation from design subsystems to components is affected by –The chosen implementation language –The chosen component model, if any –How the components are to be deployed –The source of the component  Bought  Developed  Open source

33. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 33 Modeling of Implementation Rep.  Aspects to be considered in –Development  How the component is developed as opposed to being bought or reused  Modeled using work product components –Source code files, data files, build files, and all other intermediate artifacts. –It enables the visual representation of the compilation dependencies. –Deployment  The final form in which the component will be deployed.  Modeled using deployment components –Depicts the elements that need to be delivered as part of the particular release of a software. –They end up on the nodes of the physical system at runtime. –Executables, shared libraries, non-executable resources.

34. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 34 Component Mapping  Development: Work Product Components –Mapping from a work product component to a subsystem element.  Deployment: Deployment Components –Mapping from a deployment component to a subsystem. CourseCatalogConne ctor Main (from CourseCatalog) + getCourses() + getSections() «subsystem» CourseCatalog ICourseCatalog > CourseCatalog ConnectorMain > CourseCatalog Connector > ICourseCatalog

35. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 35 Component Mapping  Deployment Component to Work Product Component Mapping > CourseCatalog ConnectorMain > CourseCatalog Connector

36. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 36 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition –Component Modeling –Documentation for Reuse –System Architecture  Summary

37. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 37 Documentation for Reuse  It is difficult to find appropriate components  It is even more difficult when you try to reuse them  Why? –Inadequate documentations!  Document the Contractual Semantics of the components, not its actual implementation. –This way you do not violate the principle of encapsulation

38. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 38 Steps in Documentation  Identify and extract the primary artifacts –Deployment components –Definitions of any realized interfaces (incoming interfaces) –Required interfaces (outgoing interfaces) –The key properties of the components.  Identify and extract all related/secondary artifacts –The supplementary assets that help describe the context in which a component was designed –They are important for proper reuse of components. –Component’s reuse context:  Related use case realizations, preconditions and postconditions, quality factors, contextual information –Other secondary artifacts:  Logical representations (UML Subsystems, their associated interface realizations, any major structural elements)  The set of all related work products, if the component was developed.

39. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 39 Steps in Documentation  Document the internal component functionality –Use UML Collaborations  One UML > collaboration for each interface realized by the subsystem or component.  Document and categorize the external component functionality –User’s manual for components can be UML Collaborations. –Informally use class diagrams to show the interfaces in the accompanying context and interaction diagrams that are descriptive rather than rigorous.  Parameterize any dependency if necessary  Catalogue the component –A searchable catalogue entry for the component using all the above information should be created.

40. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 40 Documentation Guidelines  Component Documentation Guidelines (P. 255) – What the component is and does –Run-time characteristics –Constraints and limitations –Requirements from the environment to operate –Instructions for reuse –How the component fulfills its responsibilities  Interface Documentation Guidelines (P. 256) –Interface name –Interface description –Operation definition –Interface documentation: How the operations are used –Test Documentation

41. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 41 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition –Component Modeling –Documentation for Reuse –System Architecture  Summary

42. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 42 Choosing Subsystems  Criteria for subsystem selection: Most of the interaction should be within subsystems, rather than across subsystem boundaries (High cohesion). –Does one subsystem always call the other for the service? –Which of the subsystems call each other for service?  Primary Question: –What kind of service is provided by the subsystems (subsystem interface)?  Secondary Question: – Can the subsystems be hierarchically ordered (layers)?  What kind of model is good for describing layers and partitions?

43. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 43 From Analysis to Design  Cohesion – Logical interaction with a design unit  BADCoincidental  Logical  Temporal  Procedural  Communicational  GOODFunctional  GOOD Informational  Coupling – Physical interactions between design units  BADCommon  Control  IDEALData

44. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 44 Coupling and Cohesion  Goal: Reduction of complexity while change occurs  Cohesion measures the dependence among classes –High cohesion: The classes in the subsystem perform similar tasks and are related to each other (via associations) –Low cohesion: Lots of miscellaneous and auxiliary classes, no associations  Coupling measures dependencies between subsystems –High coupling: Changes to one subsystem will have high impact on the other subsystem (change of model, massive recompilation, etc.) –Low coupling: A change in one subsystem does not affect any other subsystem  Subsystems should have as maximum cohesion and minimum coupling as possible: –How can we achieve high cohesion? –How can we achieve loose coupling?

45. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 45 Partitions and Layers Partitioning and layering are techniques to achieve low coupling. A large system is usually decomposed into subsystems using both, layers and partitions.  Partitions vertically divide a system into several independent (or weakly-coupled) subsystems that provide services on the same level of abstraction.  A layer is a subsystem that provides subsystem services to a higher layers (level of abstraction) –A layer can only depend on lower layers –A layer has no knowledge of higher layers

46. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 46 Subsystem Decomposition into Layers  Subsystem Decomposition Heuristics:  No more than 7+/-2 subsystems –More subsystems increase cohesion but also complexity (more services)  No more than 4+/-2 layers, use 3 layers (good) Layer 1 Layer 2 Layer 3

47. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 47 Relationships between Subsystems  Layer relationship –Layer A “Calls” Layer B (runtime) –Layer A “Depends on” Layer B (“make” dependency, compile time)  Partition relationship –The subsystem have mutual but not deep knowledge about each other –Partition A “Calls” partition B and partition B “Calls” partition A

48. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 48 Layering Example: Virtual Machine  Dijkstra: T.H.E. operating system (1965) –A system should be developed by an ordered set of virtual machines, each built in terms of the ones below it. VM4 VM3 VM2 VM1 Problem Existing System Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr

49. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 49 Virtual Machine  A virtual machine is an abstraction –It provides a set of attributes and operations.  A virtual machine is a subsystem –It is connected to higher and lower level virtual machines by "provides services for" associations.  Virtual machines can implement two types of software architecture –Open Architectures. –Closed Architectures.

50. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 50 Closed Architecture  Also called Opaque Layering  Any layer can only invoke operations from the immediate layer below  Design goal: High maintainability, flexibility VM4 VM3 VM2 VM1 Problem Existing System Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr

51. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 51 Open Architecture  Also called Transparent Layering  Any layer can invoke operations from any layers below  Design goal: Runtime efficiency VM4 VM3 VM2 VM1 Problem Existing System Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr Class attr opr

52. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 52 Properties of Layered Systems  Layered systems are hierarchical.  Hierarchy reduces complexity (low coupling).  Closed architectures are more portable.  Open architectures are more efficient.  If a subsystem is a layer, it is often called a virtual machine.  Chicken-and egg problem –Example: Debugger opening the symbol table when the file system needs to be debugged

53. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 53 Software Architectural Styles  Subsystem decomposition –Identification of subsystems, services, and their relationship to each other.  Specification of the system decomposition is critical.  Patterns for software architecture –Repository –Model/View/Controller –Client/Server –Peer-To-Peer –Three-Tier –Four-Tier –Pipes and Filters

54. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 54 Repository Architectural Style  Subsystems access and modify data from a single data structure  Subsystems are loosely coupled (interact only through the repository)  Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization primitives) Subsystem Repository createData() setData() getData() searchData()

55. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 55 Examples LexicalAnalyzer SyntacticAnalyzer SemanticAnalyzer CodeGenerator Compiler SyntacticEditor ParseTree SymbolTable Repository SourceLevelDebugger Optimizer

56. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 56 Model/View/Controller  Subsystems –Model subsystem  Responsible for application domain knowledge –View subsystem  Responsible for displaying application domain objects –Controller subsystem  Responsible for sequence of interactions.  MVC and Repository Architecture –is a special case of a repository architecture Controller Model subscriber notifier initiator * repository1 1 * View

57. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 57 Client/Server Architectural Style  One or many servers provides services to instances of subsystems, called clients.  Client calls on the server, which performs some service and returns the result –Client knows the interface of the server (its service) –Server does not need to know the interface of the client  Response in general immediately  Users interact only with the client Client Server service1() service2() serviceN() … ** requesterprovider

58. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 58 Client/Server Architectural Style  Often used in database systems: –Front-end: User application (client) –Back end: Database access and manipulation (server)  Functions performed by client: –Customized user interface –Front-end processing of data –Initiation of server remote procedure calls –Access to database server across the network  Functions performed by the database server: –Centralized data management –Data integrity and database consistency –Database security –Concurrent operations (multiple user access) –Centralized processing (for example archiving)

59. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 59 Design Goals for Client/Server Systems  Service Portability –Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments  Transparency, Location-Transparency –The server might itself be distributed (why?), but should provide a single "logical" service to the user  Performance –Client should be customized for interactive display-intensive tasks –Server should provide CPU-intensive operations  Scalability –Server should have spare capacity to handle larger number of clients  Flexibility –The system should be usable for a variety of user interfaces and end devices (e.g., wearable computer and desktop)  Reliability –System should survive node or communication link problems

60. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 60 Problems with Client/Server  Peer-to-peer communication is often needed  Example: Database receives queries from application but also sends notifications to application when data have changed

61. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 61 Peer-to-Peer Architectural Style  Generalization of Client/Server Architecture  Clients can be servers and servers can be clients  More difficult because of possibility of deadlocks

62. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 62 Three-tier architectural style Interface Application Logic Storage Connection Form Query

63. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 63 Four tier architectural style Presentation Server Application Logic Storage Connection Form Query Presentation Client WebBrowser

64. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 64 Pipe and filter architectural style Pipe inputoutput input*1 *1 Filter % ps auxwww | grep dutoit | sort | more psgrepsortmore

65. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 65 Agenda  Motivation  System Design Overview  Design Goals  System Decomposition  Summary

66. Seventh Lecture on October 31, 2005COP-4009: Component-Based Software Engineering 66 Summary  System Design –Reduces the gap between requirements and the (virtual) machine –Decomposes the overall system into manageable parts  Design Goals Definition –Describes and prioritizes the qualities that are important for the system –Defines the value system against which options are evaluated  Subsystem Decomposition –Results into a set of loosely dependent parts which make up the system –Basically we identify and model our components.