1. Objectives Design Class Diagrams Issues in system design Generalization Review UML papers

2. Design Class diagrams Objectives –create design class diagrams –identify classes, methods, associations

3. Design Class diagrams Definition: illustrates the specifications of software classes in an application dependent on the following activities –interaction diagrams (sequence or collaboration diagrams) are completed –conceptual model showing the concepts Conceptual modeling begins the definition of Class diagrams

4. Design Class diagrams What is the difference between Design Class diagrams and Conceptual model? –Sale in a conceptual represents an abstraction of a real world concept that we are interested in –Sale in a class diagram represents a software class, meaning it includes attributes, attribute types, methods UML does not differentiate these two types

5. Design Class diagrams How to make a Design Class diagram? –Identify all the concepts (classes) by analyzing the interaction diagrams,use cases –identify the methods by analyzing the “messages” being exchanged in interaction diagrams –state diagrams reveal more methods –add type information for attributes

6. Design Class diagrams How to make a Design Class diagram? –Add method return information (attribute and type information) –add associations to indicate dependencies, generalizations –add cardinality information

7. Design Class diagrams POST captures 11 Sale Date isComplete: boolean time captures 11 POST Date isComplete:boolean time Sale Date isComplete:boolean time makeLineItem() Conceptual model Software components

8. Design Class diagrams create is a special language independent UML message to indicate instantiation and initialization. As this is a common operation, it is often omitted from class diagrams. Access methods for class attributes are also omitted from class diagrams to reduce clutter. Messages to a multiobject are not shown as methods in the class whose objects are contained in a multiobject.

9. Design Class diagrams It is recommended that UML syntax be used for method naming. This will keep naming language independent. UML format: methodName(parameterList) Should all type information be shown in a class diagram? –If automatic code generation is desired then YES. –If the sole purpose is to use the diagram as a communication aid, then all type information is not of any significant value.

10. Design Class diagrams captures 11 POST Date isComplete:boolean time Sale Date isComplete:boolean time makeLineItem() POST will likely have an attribute pointing to Sale. Navigability arrow: POST objects are connected uni-directionally to Sale objects. No navigability arrow..Sale does not have connection to POST.

11. Design Class diagrams It is recommended that associations be adorned with navigability arrows. Navigability is determined by visibility. –A sends a message to B. –A creates an instance of B. –A needs to maintain a connection to B. Associations also indicate “persistent” connections

12. Design Class diagrams In UML a dependency relationship indicates that one element has knowledge of another element. It is illustrated with a dashed arrow. Non-attribute visibility…arising from parameters, global, or locally declared items is illustrated by dashed arrows. (Fig 21.11 larman)

13. Issues in system design Design a system architecture in terms of layers and partitions Use UML to illustrate package diagrams Identify and apply common system design principles –Model-View separation –Publish-Subscribe events

14. Issues in system design Often a system is composed of multiple subsystems. Example: –An information system connects to a use interface and a persistent storage mechanism. How does one show subsystems and their interactions in UML ?

15. Issues in System design UPC Cash Quantity Balance Enter ItemEnd SaleMake Payment Object Store x _ Cash Presentation layer Persistent storage Application logic Record SalesAuthorize payments Storage Database

16. Issues in System design 3-tier architecture separates the application logic into a distinct middle layer. Presentation layer (mostly) free of application processing. Middle layer communicates with the back-end layer. Would you prefer a two-tier architecture? (Obtained by placing application logic into the presentation layer.)

17. Application logic Presentation POSTApplet ReportGeneratorDBInterface SalePayment Domain concepts services Storage Database Issues in System design Decomposition

18. Issues in System design Multi-tiered architecture useful when: –The application logic needs to be split and isolated into multiple layers. –The application logic needs to be distributed amongst several computers. –Development of components needs to be distributed amongst various developers.

19. Issues in System design Deployment : –A 3-tier architecture may be deployed in various configurations. Examples: –Presentation and app logic on one computer, database on a server. –Presentation on client computer, app logic on application server, and database on a data server.

20. Domain concepts Issues in System design Core elements Sales

21. Issues in System design Presentation DomainServices Presentation App logic Storage Database

22. Issues in System design Packages guidelines –group elements that provide a common service –usually applicable most during class modeling –coupling and collaboration between elements of various packages should be low –elements within a single package should be strongly related.

23. Issues in System design Layers and Partitions –Layers of an architecture represent vertical tiers. –Partitions represent horizontal tiers, e.g. the Services layer may be divided into Security and Reporting. –Upward and downward communication is feasible across components in a vertical layer. This is also known as a “relaxed layer” architecture.

24. Issues in System design Model-View separation –de-couple domain objects from window objects –design domain classes so that there is no direct coupling to window classes –minimize the impact of changes to requirements to either domain or window interfaces Indirect communication in a system –design for publish-subscribe patterns (polling is to be avoided where possible)

25. Generalization Objectives –create generalization-specialization hierarchies –validate using “Is-a” tests

26. Generalization Inheritance –Generalization : classes with a set of similar features and meaning –the sharing of attributes, operations among classes related by generalization –for example:

27. Generalization

28. Dependency –A dependency exists between two items if changes to one item causes a change to the other item For example: between two classes Account and Interest, a change in interest rate causes changes in the account

29. Generalization Dependency - example

30. Generalization Aggregation –An association that relates a whole to its parts

31. More on Relationships Polymorphism - refers to operations among classes that are logically the same but have more than one implementation method

32. More on Relationships