1. Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 sample solution is posted. Assignment 3 is posted. Due Nov. 6. Today: –Continue Software Analysis. –Start on System Design.

2. Fall 2015CISC/CMPE320 - Prof. McLeod2 Statechart Diagrams A Statechart diagram is the only other diagram that provides a dynamic view. It focuses on just a single object. For example, look at a nested Statechart diagram for the Incident object:

3. Fall 2015CISC/CMPE320 - Prof. McLeod3 Active Reported Assessment ResponseDisengagement Inactive ClosedArchived field officer arrives on site dispatcher allocates resources field officer requests additional resources field officer releases resources all resources deallocated all resources submitted reports when date is greater than one year

4. Fall 2015CISC/CMPE320 - Prof. McLeod4 Statechart Diagrams By concentrating on just a single object it is easier to see if there are any missing use cases. Or if a use case needs more refinement.

5. Fall 2015CISC/CMPE320 - Prof. McLeod5 From Before: Analysis as a UML Class Diagram Use Case Diagram Class Diagram StateChart Diagram Sequence Diagram Functional Model Object Model Dynamic Model Analysis Model

6. Fall 2015CISC/CMPE320 - Prof. McLeod6 Object Model Design You might be using class diagrams to contain information about your classes: Incident dateCreated: Date emergencyLevel: String … setDateCreated() setEmergencyLevel() setOriginatingFieldOfficer() …

7. Fall 2015CISC/CMPE320 - Prof. McLeod7 Interface Specifications You can start by deciding: –What is public, private and protected –The parameters and return types Incident -dateCreated: Date -emergencyLevel: String … +setDateCreated(Date): void +setEmergencyLevel(String): void +setOriginatingFieldOfficer(FieldOfficer): void … - means private + means public # means protected

8. Fall 2015CISC/CMPE320 - Prof. McLeod8 Interface Specifications, Cont. Add Contracts: A contract consists of invariants, pre-conditions and post-conditions. An invariant is something that is true for an attribute or for the entire class or interface. A pre-condition is true before a method is invoked. A post-condition is true after a method is invoked.

9. Fall 2015CISC/CMPE320 - Prof. McLeod9 After Software Analysis Analysis has provided: A set of Nonfunctional Requirements and Constraints A System Model, expressed in: –Use Cases –Object Models –Sequence Diagrams –Statechart Diagrams –…

10. Fall 2015CISC/CMPE320 - Prof. McLeod10 Subsystem Decomposition System Design Object Model Analysis Object Model Non-functional requirements Requirements Elicitation Problem Statement Functional Model Analysis Dynamic Model System Design Design Goals Use Case Diagram Class Diagram Statechart Diagram Sequence Diagram RAD SDD

11. Fall 2015CISC/CMPE320 - Prof. McLeod11 Deliverable System Object Design Model Object Design Implementation Source Code Testing Class Diagram This is not a flowchart. The stages are not necessarily carried out in this order. No iteration or feedback is shown.

12. Fall 2015CISC/CMPE320 - Prof. McLeod12 After System Design End up with: Design Goals –System qualities that need to be optimized Software Architecture –Subsystem decomposed, mapped to hardware, decisions such as control flow, access control and data storage made. Boundary Use Cases –System configuration, startup, shutdown and exception handling.

13. Fall 2015CISC/CMPE320 - Prof. McLeod13 Subsystem Decomposition The aim is to identify and/or create classes (or packages of classes) that can be coded by a single coder. Techniques used are Layering and Partitioning. Concerned about Coupling between subsystems and Cohesion within a subsystem. The Subsystems must address the design goals. Keep refining the Decomposition until the goals are satisfied.

14. Fall 2015CISC/CMPE320 - Prof. McLeod14 Identifying Subsystems A subsystem is like a package in Java – a group of classes related by their functionality. Like classes in a Java package, objects in a subsystem will have some coupling within the subsystem, but should have minimal coupling with other subsystems. What is coupling anyways?

15. Fall 2015CISC/CMPE320 - Prof. McLeod15 Coupling and Cohesion Strong Coupling, Weak Cohesion Strong Cohesion, Weak Coupling

16. Fall 2015CISC/CMPE320 - Prof. McLeod16 Coupling and Cohesion, Cont. Coupling occurs between packages and cohesion occurs between methods. Unlike the bad old days of languages that had (gasp!) goto statements (the horror!), modern OOP languages do their best to enforce strong cohesion and weak coupling. Weak coupling allows you to make changes in one object and minimize the effects on other objects. Strong cohesion means that methods are small and single-purpose.

17. Fall 2015CISC/CMPE320 - Prof. McLeod17 Layering Two general kinds: Open Architecture and Closed Architecture (don’t confuse “Open” with “Non- Proprietary”, here!).

18. Fall 2015CISC/CMPE320 - Prof. McLeod18 Closed Architecture, in General Subsystem A Subsystem BSubsystem CSubsystem D Subsystem ESubsystem F Subsystem G Level 1 Level 2 Level 3 Most Abstract Least Abstract

19. Fall 2015CISC/CMPE320 - Prof. McLeod19 Closed Architecture, Cont. You cannot go from level 3 back to level 1 without going through level 2. Subsystems A, B and E represent a complete Vertical Slice of the architecture, but subsystems D and G would not.

20. Fall 2015CISC/CMPE320 - Prof. McLeod20 Closed Architecture, Cont. A layer can only access the layer immediately above or below it. (In Java you can construct a closed object hierarchy.) In an Open Architecture you can skip layers.

21. Fall 2015CISC/CMPE320 - Prof. McLeod21 Closed Architecture Example – OSI Model Stands for “Open Systems Interconnection” Application Presentation Session Transport Network DataLink Physical Key Connection Message Packet Frame Bit CORBA or Java RMI TCP/IP Ethernet Most Abstract Least Abstract

22. Fall 2015CISC/CMPE320 - Prof. McLeod22 Open Architecture Example Application Swing AWT OS You can get improved performance by bypassing the Swing layer. JavaFX represents another layer!

23. Fall 2015CISC/CMPE320 - Prof. McLeod23 Layering and Coupling The emergency response database system: The Database subsystem is directly coupled to the other three subsystems, making these subsystems vulnerable to changes in Database design. ResourceManagement Database MapManagementIncidentManagement

24. Fall 2015CISC/CMPE320 - Prof. McLeod24 Layering and Coupling, Cont. Add a layer: Storage will have a more stable interface. If Database changes then only Storage will have to be modified. Less coupling to Database! ResourceManagement Storage MapManagement IncidentManagement Database

25. Fall 2015CISC/CMPE320 - Prof. McLeod25 Reminder – Coupling and Cohesion Want to minimize coupling between subsystems and maximize cohesion inside the subsystem. If you see classes within a subsystem that are not well coupled to other classes within the subsystem, then partition the subsystem into two smaller subsystems.

26. Fall 2015CISC/CMPE320 - Prof. McLeod26 Coupling and Cohesion, Cont. Usually have a tradeoff. Limit to the number of layers formed by partitioning: “Common Wisdom” says that developers can handle a maximum of 9 layers of abstraction. Often as little as 3 layers is just fine! 7 ± 2

27. Fall 2015CISC/CMPE320 - Prof. McLeod27 Architectural Styles Or Patterns Commonly occurring software architectures. Several hundred of these exist. The idea is that you can incorporate an existing design into your own. Why re-invent the wheel?

28. Fall 2015CISC/CMPE320 - Prof. McLeod28 Repository Architectural Style Subsystem 1 Repository Subsystem 2 Subsystem 3 storeData() getData() sortData() searchData()… ….

29. Fall 2015CISC/CMPE320 - Prof. McLeod29 Repository Architectural Style, Cont. Used by database management systems, for example. Features: –Strong coupling between subsystems and Repository. –Minimal coupling between subsystems. Disadvantages: –Repository acts as performance and modification bottleneck. –Changes in database structure often means many changes to other subsystems.

30. Fall 2015CISC/CMPE320 - Prof. McLeod30 Model / View / Controller Style Also called “MVC” style. Model Controller View * * 1 1 initiator repository notifier subscriber

31. Fall 2015CISC/CMPE320 - Prof. McLeod31 MVC Style, Example

32. Fall 2015CISC/CMPE320 - Prof. McLeod32 MVC Style, Example, Cont. The Model is the underlying file system (or repository) consisting of files and folders. Windows Explorer consists of several Views showing various details of the Model. Several Controller systems allow you to change filenames, copy or delete files, create folders, etc. When things are changed through the Controller subsystems, the Model notifies the Views that they need to update.

33. Fall 2015CISC/CMPE320 - Prof. McLeod33 More Patterns Client/Server Peer to Peer Three Tier Four Tier Pipe and Filter Factory Façade Mediator Proxy Anti-Patterns – the “Blob” …

34. Links to Patterns Portland Pattern Repository: http://c2.com/ppr/ Look up this site in Wikipedia for a history of this important repository. Fall 2015CISC/CMPE320 - Prof. McLeod34

35. Fall 2015CISC/CMPE320 - Prof. McLeod35 Design Goals Are taken from the existing non-functional requirements and from your observations and documentation of the application domain. These goals usually lie in the following categories: –Performance –Dependability –Cost –Maintenance –End User Criteria

36. Fall 2015CISC/CMPE320 - Prof. McLeod36 Design Goals – Performance Response Time –How quickly must the system respond to a user request? Throughput –How many tasks does the system need to complete in a fixed period of time? Memory –How much memory is required when running?

37. Fall 2015CISC/CMPE320 - Prof. McLeod37 Design Goals – Dependability Robustness –Survive invalid user input. Reliability –Does observed behaviour match specified behaviour? Availability –Percentage of time the system is available to perform normal tasks. Fault Tolerance –Ability to continue to operate under erroneous conditions.

38. Fall 2015CISC/CMPE320 - Prof. McLeod38 Design Goals – Dependability, Cont. Security –Ability to withstand malicious attacks. Safety –Avoid human injury even in the presence of errors and failures.

39. Fall 2015CISC/CMPE320 - Prof. McLeod39 Design Goals – Cost Development Cost –Initial system development. Deployment Cost –Cost of installation and user training. Upgrade Cost –Translating data from previous system. Backwards compatibility? Maintenance Cost –Cost of bug fixes and enhancements. Administration Cost –Cost to administer system.

40. Fall 2015CISC/CMPE320 - Prof. McLeod40 Design Goals – Maintenance Extensibility –How easy is it to add functionality or new classes to the system? Modifiability –How easy is it to change functionality? Adaptability –How easy is to port the system to different application domains? Portability –How easy is it to port the system to different platforms?

41. Fall 2015CISC/CMPE320 - Prof. McLeod41 Design Goals – Maintenance, Cont. Readability –How easy is it to understand the system from reading the code? Traceability of Requirements –How easy is it to map the code to specific requirements?

42. Fall 2015CISC/CMPE320 - Prof. McLeod42 Design Goals – End User Criteria Utility –How well does the system support the work of the user? Usability –How easy is it for the user to use the system?

43. Fall 2015CISC/CMPE320 - Prof. McLeod43 Trade-Offs! Of course these goals can beat on each other. For example it might not be possible to have a system that is completely safe and secure but still cheap. For example, you might have to compromise between: –Space and Speed –Delivery Time and Functionality –Delivery Time and Quality –Delivery Time and Staffing