Download UML Design: Class Spec, Interfaces, Coupling, Cohesion, Liskov Substitution and more Slides Object Oriented Programming in PDF only on Docsity!
Detailed Design
Lecture 29
2
Overview
n Good design criteria
n Designing associations
n Integrity constraints
n Designing operations
n Normalization
3
Class Specification
n One of the first tasks in object design is elaboration
of the class details, i.e.
n Attribute types are defined; n Attribute initial values are given; n Operation types are defined; n Operation arguments are given; n Argument names and types are also specified. n Visibility of each attribute and operation is defined, as either: n Public (+, clear) n Protected (#, key) n Private (-, lock) n Implementation (?, bolt)
docsity.com
4
Class Specification (2)
n Each class needs to be defined to the extent so that
it would be possible to generate class interface in a
given programming language, e.g. Java.
5
Interfaces
n Sometimes several classes need to implement the same operations in a different way, e.g. thread’s "run".
n In such cases it is a common practice in programming languages to separate and share class interfaces.
n Class interfaces need to be realized, i.e. all of their operations implemented, by another class.
n Note that component diagrams show interfaces as circles whereas class diagrams as stereotypes.
6
Abstract classes
n In Rational Rose, we can use
stereotypes to indicate that a class or its operation is abstract, or that the operation is implemented by a class.
n Some other UML CASE tools
support special adornments to identify abstract and concrete classes, virtual methods, etc.
docsity.com
10
Design Guidelines
n Design clarity
n Lack of over-design
n Inheritance hierarchy depth and breadth
n Simplicity of messages and operations
n Design volatility
n Scenario validation
n Design by delegation
n Keep classes separate (e.g. in Java)
11
Designing Associations
n Class association may indicate the possibility of
object communication, i.e. existence of a link
between class instances.
n We may wish to restrict access of one associated
object by another by specifying navigation links
(arrow).
n The navigation arrow indicates the permitted
direction of message flows.
12
Designing Associations (2)
n How could access to navigable objects be organized
depending on the class multiplicity?
docsity.com
Constraints
n UML does not have a special notation for constraints. It is recommended to use text boxes to annotate your diagram. n Constraints between classes can also be specified with the use of dependency links (which are also possible between classes themselves).
n Example: employees can be members of some committee. n The committee chair is also a member of the committee. n Should an employee cease to be a member then he or she should also cease to be a chair of that committee.
not covered in class
Designing Operations
n Class operations need to be properly designed to ensure a high quality of the resulting system. n Issues that need to be considered are: n Contracts; n Computational complexity (memory and speed); n Accuracy; n Exceptions; n Any qualifications; n Concurrency; n Other constraints, such as platform dependent constraints; n etc.
n In Rational Rose, operations may be specified in detail using an operation specification dialogue box.
not covered in class
15
Normalization
n Classes can be normalized to ensure their functional dependency. n Persistent classes, i.e. those that are going to be kept in a database, should be normalized when relational models are enforced. n The process of class normalization is exactly the same as database normalisation. n One issue in database management is identification of primary and foreign keys
not covered in class
docsity.com
