CS 5150 Software Engineering

1. CS 5150 Software Engineering Lecture 15 Object Oriented Design 1

2. Administration

3. Project Presentations: Scenario Chose scenarios that illustrate the various paths through the overall system, including human processes. Look for complex parts of the system. Depending on the system, they may be: • Complex types of transactions (see next slide) • Special categories of user (e.g., inexperienced, handicapped) • Unusual computing environments (e.g., handheld devices, foreign scripts) • Error recovery and reversal of incorrect transactions • Peak workloads

4. Scenario Example: Human Resources Workflow Tracking for CIS Faculty Complex transactions (real examples) • A department is hiring a new faculty member. If a suitable candidate is found, the appointment may be joint with another department • A department is hiring several faculty members. It is not clear whether there are sufficient funds for two or three junior people. The cost of a senior person is equivalent to two juniors. • A person is retiring, but will have a new part-time appointment. The scenarios should model the complexity in the inter-relationship between the computer system and the human processes to make sure that all administrative steps are correctly followed, e.g., checking budget allocations.

5. Project Presentations: Schedules The schedule must provide time for: • Evaluation (such as user testing) • Deployment and handover Evaluation Requirements first presentation second presentation third presentation Design Implementation

6. Program Design in the Modified Waterfall Model Feasibility study Requirements Requirements System design Design Program design Implementation Implementation (coding) Testing Acceptance & release Operation & maintenance

7. Program Design • The task of program design is to represent the software • system functions in a form that can be transformed into • one or more executable programs. • Given a system architecture, the program design specifies: • programs, components, packages, classes and class hierarchies • interfaces, protocols • algorithms, data structures, security mechanisms, operational procedures • If the program design is done properly, all design • decisions should be made before implementation.

8. UML Models UML models (diagrams and specifications) can be used for almost all aspects of program design • Diagram gives a general overview of the model, showing the principal elements and how they relate to each other. A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Specification provides details about each element of the model. Specification for models used in program design should have sufficient detail that they can be used to write code from.

9. Models: Levels of Abstraction The complexity of a model depends on its level of abstraction: • High-levels of abstraction show the overall system. • Low-levels of abstraction are needed for implementation. Two approaches: • Model entire system at same level of abstraction, but present diagrams with different levels of detail. • Model parts of system at different levels of abstraction.

10. Choice of Models in UML • Use case model shows a set of use cases and actors (a special kind of class) and their relationships. Principally used for requirements. • Component model shows the organization and dependencies among a set of components. Principally used for system architecture. • Deployment model shows the configuration of processing nodes and the components that live on them. Principally used for system architecture.

11. Choice of Models in UML Models that are used for program design: • Class model shows a set of classes, interfaces, and collaborations with their relationships. • Object model shows a set of objects and their relationships.

12. Choice of Models in UML Models for interactive aspects of systems. They can be used for requirements or program design. • Statechart model shows a state machine consisting of states, transitions, events, and activities. • Activity model is a flow chart model that shows the flow from activity to activity within a system. • Interaction model: set of objects and their relationships including messages that may be dispatched among them => Sequence model: time ordering of messages

13. Class Diagrams Window origin size open() close() move() display() name attributes [local, instance, and class (static) variables] operations [methods] responsibilities [optional text] A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

14. The "Hello, World!" Applet import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } } Example from: BJR

15. The HelloWorld Example class HelloWorld paint() name operations

16. Abstraction for HelloWorld g.drawString ("HelloWorld", 0, 10)" class HelloWorld paint() name annotation operations

17. Annotation some text note A noteis a symbol for rendering constraints and comments attached to an element or a collection of elements.

18. Rational Rose: A Typical Class Diagram

19. Specification

20. Specification Fields

21. General Specification Fields

22. Notation: Grouping Business rules A package is a general-purpose mechanism for organizing elements into groups.

23. Packaging Classes applet awt lang java HelloWorld package Graphics

24. Notation: Relationships A dependencyis a semantic relationship between two things in which a change to one may effect the semantics of the other. 0..1 * employer employee An association is a structural relationship that describes a set of links, a link being a connection among objects.

25. Relationships Parking 1 0 ... 1 ParkingSpace location is_available()

26. Notation: Relationships (continued) child parent A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). A realizationis a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

27. Generalization HelloWorld paint() Note that the Applet and Graphics classes are shownelided, i.e., just the name is shown, not the attributes or operations. Applet generalization dependency Graphics

28. Notation: Interface ISpelling An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.

29. Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld

30. Modeling Classes Given a real-life system, how do you decide what classes to use? • What terms do the users and implementers use to describe the system? They are candidates for classes. • Is each candidate class crisply defined? • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes? • What attributes and operations does each class need to carry out its responsibilities?

31. Coupling and Cohesion Coupling is a measure of the dependencies between two part of a system. If two classes are strongly coupled, it is hard to modify one without modifying the other. Cohesion is a measure of dependencies within part of a system. If a class contains many closely related functions its cohesion is high. Aim for high cohesion within classes and weak coupling between them.

32. Candidate Classes: Application Classes and Solution Classes Application classes and solution classes: Application classes represent application concepts. Noun identification is an effective technique to generate candidate application classes. Solution classes represent system concepts, e.g., user interface objects, databases, etc.

33. Noun Identification for Application Classes: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

34. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

35. Candidate Classes Library the name of the system Book Journal Copy ShortTermLoan event LibraryMember Week measure MemberOfLibrary repeat Item book or journal Time abstract term MemberOfStaff System general term Rule general term

36. Relations between Classes Book is an Item Journal is an Item Copy is a copy of a Book LibraryMember Item MemberOfStaff is a LibraryMember Is Item needed?

37. Operations LibraryMember borrows Copy LibraryMember returns Copy MemberOfStaff borrows Journal MemberOfStaff returns Journal Item not needed yet.

38. Class Diagram MemberOfStaff Book Copy Journal LibraryMember 1 1 on loan on loan 0..* 0..12 is a copy of 1..* 1

39. Rough Sketch: Wholesale System A wholesale merchant supplies retail stores from stocks of goods in a warehouse. What classes would you use to model this business?

40. Rough Sketch: Wholesale System RetailStore Order Merchant Product Warehouse Shipment Invoice

41. Rough Sketch: Wholesale System RetailStore name address contactInfo financialInfo Shipment Responsibilities -track status of shipped products Merchant Warehouse Order Product responsibility (text field) Reversal damaged() return() wrongItem() Invoice

42. Expanding a Class: Modeling Financial Information RetailStore association 1 * Transaction Which class is responsible for the financial records for a store? Payment Invoice

43. Modeling Invoice Shipment ??? RetailStore invoiceRecord goodsShipped Invoice invoiceNumber +goodsShipped() -sendInvoice() PartsList adornments + public - private

44. Lessons Learned Design is empirical. There is no single correct design. During the design process: • Eliding: Elements are hidden to simplify the diagram • Incomplete: Elements may be missing. • Inconsistency: The model may not be consistent The diagram is not the whole design. Diagrams must be backed up with specifications.

45. From Candidate Classes to Completed Design Methods used to move to final design: Reuse: Wherever possible use existing components, or class libraries. They may need modification. Restructuring: Change the design to improve, understandability, maintainability, etc. Techniques include merging similar classes, splitting complex classes, etc. Optimization: Ensure that the system meets anticipated performance requirements, e.g., by changed algorithms or restructuring. Completion: Fill all gaps, specify interfaces, etc.

46. An Exam Question: Object Oriented Design A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

47. Exam Question: Noun Identification A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

48. Exam Question: Candidate Classes System general term WeatherMap Data same as MeteorologicalData WeatherStationis this a general term? MeteorologicalDatahow does this relate to WeatherStation? DataSummaryhow does this relate to MeteorologicalData? AreaComputer hardware Database general term DigitizedMap

49. Exam Question: Observations about the Candidate Classes WeatherMap is a DigitizedMap is derived from 1...* DataSummary WeatherStation has a set of MeteorologicalData MeteorologicalData DataSummary is derived from MeteorologicalData DigitizedMap Can Meteorological Data be an attribute of WeatherStation? Can DataSummary be combined with WeatherMap?

50. Exam Question: Attributes and Operations WeatherStation location metereologicalData collectData() getSummary() WeatherMap location date-time geographicData weather gatherData() printMap() DigitizedMap location geographicData printMap() Or should MetereologicalData be a separate object?