Engineering

1. Engineering RW344: Software Design ▬▬▬ Bernd Fischer bfischer@cs.sun.ac.za

2. Modeling and Design

3. Topics • UML • class diagrams • sequence diagrams • communication diagrams • design principles • software architecture • design patterns

4. Development Main concern: how should the system work? development: converting the system specification into an executable system

5. Development=Design+Implementation Traditionally broken down into several stages: • architectural design • component design • interface design • data structure design • abstract specification • algorithm design • coding • debugging • development is an iterative process with feedback between the stages • design and implementation are typically interleaved development: converting the system specification into an executable system

6. Design vs.Modeling • guided by design principles • part of development • uses modeling languages • spans requirements and development Designis the process of deciding how the requirementsshould be implemented. Modelingis the process of creating an abstractrepresentation of the domainor the system.

7. UML (Unified Modeling Language) • graphicalmodeling language • standardized by OMG (Object Management Group) • semi-formal • variety of different diagram types • supports object-oriented designs • but no fixed methodology • unified: each diagram gives a different view on the same system • developed by Rumbaugh, Booch, Jacobson et al. • starting early-90’s, unification mid-90’s

8. UML diagram types

9. Structural vs. behavioralmodeling • class diagrams • System = structure + behavior • structural models show the system’s organization in terms of its components and their relationships • can be static (classes) or dynamic (threads) • behavioral models show the system’s dynamic as it is executing and responding to stimuli • can be eventsor data

10. Class Diagrams

11. Class diagram essentials Main elements: • classes: represent the types of the data • attributes: represent the data found in instances • associations: show how instances are related • generalizations: represent inheritance hierarchies • operations: represent the actions by instances Class diagramsdescribe the datafound in a software system.

12. Classes A class describes a collection of instances with common properties and similar behavior. • classname • noun phrase, head singular and countable, PascalCase • attributes • noun phrase, singular, camelCase(verb phrase if Boolean) • operations • verb phrase, camelCase More information: • D. Aguilera, C. Gómez, A.Olivé: A complete set of guidelines for naming UML conceptual schema elements. Data Knowl. Eng. 88: 60-74 (2013).

13. Classes A class describes a collection of instances with common properties and similar behavior. attributes andoperationscan have additional visibility and type information

14. Classes A class describes a collection of instances with common properties and similar behavior. attributes andoperationsare optional

15. Associations An association describes how instances(of two classes) referenceeach other. • associationname • verb phrase, camelCase • reading order • <left entity> <association> <right entity>

16. Multiplicities Multiplicities describe how many instances(of the two classes) are related by an association. • “many” • “optional” . • Symbol at an association end indicates how many instances of this end are related to one instance on the other end

17. Multiplicities Multiplicities describe how many instances(of the two classes) are related by an association. • “non-empty” • NOTE: multiplicities carry a lot of meaning, so they should always be given. .

18. Multiplicities Multiplicities describe how many instances(of the two classes) are related by an association. • “non-empty” • NOTE: multiplicities are difficult to get right, so always read them in both directions. .

19. Typical multiplicities • one-to-many: common, strictly hierarchical relations • many-to-many: common, matrix relations • one-to-one: often abused

20. Typical multiplicities • one-to-many: common, strictly hierarchical relations • many-to-many: common, matrix relations • one-to-one: often abused • better to model class by additional attributes

21. Exercises Model with appropriate multiplicities: • docents teaching courses taken by students • musicians planning performances of different plays at different venues

22. Named association ends • association ends can be named (role names) • associations can be reflexive • role name

23. Association directionality • associations are normally bi-directional: • for each Order, we know Items it contains • for each Item, we know which Order it belongs to • association direction can be restricted (navigable): • can only go from Order to Item • ... but not vice versa • NOTE: directionality limits implementation freedom! • Use it sparingly, add it later.

24. Association classes • some attributes can be difficult to allocate to classes: • where should grade go? • use association class: • association name disappears • each Student-Class link contains an object of type Registration

25. Association classes can be eliminated. • replace association + association class by two (one-to-many) associations: • couldn’t get this working in Astah...

26. Aggregation Use when • the parts are partOf the aggregate(or the aggregate isComposedOf the parts) • whoever owns or controls the aggregate, also owns or control the parts Aggregations represent part-whole associations between instances. • aggregateclass • implicit partOf association

27. Aggregation hierarchies • aggregation can be arranged hierarchically • NOTE: not the same as inheritance • typicallyone-to-many

28. Composite associations Use when • the part cannot exist without the whole aggregate Composite associations representstrongpart-whole associations between instances. • compositeclass • must be “1”

29. Composite associations vs. attributes • one-to-one composite associations can also bemodeled as attributes (and vice versa)

30. Exercises Which mechanism (association, aggregation, or composition) should be used to model the following relations: • telephone and handset • school and teachers • book and chapters • country and provinces • polygon and lines

31. Generalization Inheritance must obey the isa rule: • “a <subclass> is a <superclass>” must make sense! Generalization represents inheritance hierarchies. This a relation on classes, not an association between instances!

32. Generalization Stereotypes: • <<complete>> indicates that the superclass is abstract (i.e., instances exist only in the subclasses) • <<disjoint>> indicates that each instance can only be instance of one class(opposite: <<overlapping>>) <<disjoint>> <<complete>>

33. Generalization • use a discriminator label to denote the criterion used to distinguish different subclasses • in particular for disjoint generalization

34. Pitfalls – multiple generalization • UML allows multiple inheritance • but Java doesn’t... • and there are problems with repeated attributes

35. Pitfalls – overgeneralization • no difference other than discriminator label • better solution: • object diagram

36. Pitfalls – class change • instances should never change their class!

37. Interfaces • similar to classes, except they lack instance variables and implemented methods An interface describes a portion of the visible behaviour of a set of objects.

38. Domain Class Model

39. Classdiagramscanbeusedtomodelthe problematdifferentlevelsofabstraction. • domain model • developed in domain analysis to understand the domain • models also aspects of the domain that will not be implemented by the system • also called exploratory domain model • system domain model • models only aspects of the domain that are implemented by the system • system model • models also classes outside the domain but usedto build the user interface and system architecture shrink &refine grow &refine

40. Domain class model The domain class model contains: • relevant entities as classes: • physical objects • persons, organizations (actors) • events, processes, abstractions • links between entities as associations: • relations • communications • part/whole relations (aggregation, composition)

41. Domain class model The domain class model should only use a limited set of notations (“boxes and arrows”): • classes • use attributes sparingly • associations with multiplicities • use aggregation and composition sparingly • generalization It should not use: • methods • types • roles

42. Arecipetocookdomainclassmodels... boxes • add classes (without attributes) • identify relevant real system objekts and represent as classes • add generalizations • add associations (with multiplicities) • identify relations between identifed objects • add aggregations and compositions • check whether really necessary • add attributes (no operations) • identify relevante core attributes and add to corresponding classes • stir until done arrows

43. Discovering domain classes Noun phrase analysis: • analyze (textual) documents describing the system • use cases • requirements documents • extract the nouns and noun phrases • eliminate nouns that • are redundant, vague, or highly general • are too specific or represent specific instances • refer to the entire system or objects outside the application • pay attention to nouns that describe different user types or other actors

44. Example: meal ordering system

45. Discovering associations • start with central and most important classes • work outwards towards the less important classes • add an association if one class • possesses or controls • is related to • communicates with • is a part of • is a member of some other class in the model • label it clearly • specify the multiplicity at both ends • KISS: keep it simple • Don’t rely on verb phrases – associations are often left implicit!

46. Example: meal ordering system

47. Pitfalls – transient associations • an association is only legitimate if the links “survive” beyond execution of an operation • links are stored in database • if nothing needs to be stored, rethink the association  • What do you store??

48. Pitfalls – actions as associations • actions should not be modelled as associations but as association classes • store information associated with action • different operations access different attributes 

49. Pitfalls – actions as associations • actions should not be modelled as associations but as association classes • store information associated with action • different operations access different attributes

50. Pitfalls – actions as associations • actions should not be modelled as associations but as association classes • store information associated with action • different operations access different attributes