UNITIV Designing Classes Access Layer Object Storage Object
UNIT‐IV Designing Classes – Access Layer ‐ Object Storage ‐ Object Interoperability
Objectives • Students should be able to define and understand – Designing Classes – Designing Protocols and Class Visibility – The UML Object Constraint Language (OCL) – Designing Methods
The Object‐Oriented Design Philosophy • Important activity in building an application, should be to design a set of classes, each of which has a specific expertise and all of which can work together in useful ways.
UML Object Constraint Language • UML is a graphical language with a set of rules and semantics. • The rules and semantics are expressed in English, in a form known Object Constraint Language (OCL). • OCL – Is a specification language. – Uses simple logic for specifying the properties of a system. – UML modeling constructs require expressions. (eg. , type, Boolean values, numbers). – Expressions are stated as strings in OCL.
UML Object Constraint Language Syntax for some common navigational expressions • Item. selector : – The selector is the name of an attribute in the item. (eg. , Jhon. age) • Item. selector[qualifier‐value] : – The selector indicates a qualified association that qualifies the item. The result is the related object selected by the qualifier. – (eg. , John. Phone[2]) • Set ‐> select (Boolean‐expression) : – The Boolean expression is written in terms of objects within the set. – The result is the subset of objects in the set for which the Boolean expression is true. – (eg. , company. employee ‐> salary>30000)
Designing Classes Designing Business Layer classes • 1. 1 Apply design axioms to design classes, their attributes, methods, associations, structures, and protocols. • 1. 2 Refine and complete the UML Class Diagram by adding details. This step consists of Refine attributes, methods, cardinality, visibility, association and class hierarchy. – 1. 2. 1 Refine attributes – 1. 2. 2 Design methods and protocols by utilizing a UML activity diagrams to represent the method’s algorithm. – 1. 2. 3 Refine associations between classes (if required). – 1. 2. 4 Refine class hierarchy and design with inheritance (if required). • 1. 3 Iterate and refine again.
Class Visibility: Designing Well‐Defined Public, Private, and Protected Protocols • Public Protocol Layer: External – Items in this layer define the functionality of the object. • Things to keep in mind when designing class protocols – Good design allows for polymorphism. – Not all protocol should be public.
Designing Classes: Refining Attributes • Attributes identified in OOA must be refined with respect to implementation during OOD. • In Analysis Phase – Attribute Name is sufficient. • In Design Phase – detailed information must be added to the class (defining attributes, operations). Goal • Refine existing attributes (identified in analysis) or • add attributes that can elevate the system into implementation.
• Attribute Types – Single‐value attributes – Multiplicity or multivalue attributes – Reference to another object, or instance – connection
UML Attribute Presentation • OCL can be used to define the class attributes. Syntax • visibility name : type‐expression = initial‐value • where, – Visibility is one of the following • + public visibility • # protected visibility • ‐ private visibility • Type‐expression is a language‐dependent specification of the implementation type of an attribute. • Initial‐value is a language‐dependent expression for the initial value of a newly created object. (optional) • Multiplicity indicator (array) can be represented as Eg. , Names[10]: String points[2. . *] : Point
Designing Classes: Refining Attributes ATM Example
Designing Methods and Protocols Goal • Is to specify the algorithm for methods identified. • Once methods are designed in some formal structure such as UML activity diagrams with an OCL description, they can be converted to programming languages manually or automated • (i. e. , using CASE Tools).
Types of methods • Constructor • Destructor • Conversion method • Copy method • Attribute set • Attribute get • I/O methods • Domain specific methods
• Highly cohesive objects can improve coupling because only a minimal amount of information need to be passed between objects. • Abstraction leads to simplicity and also increases class versatility. • The requirement of simplification, while retaining the functionality, seems to lead to increased utility.
Rules • If it looks messy, then it's probably a bad design. • If it is too complex, then it's probably a bad design. • If it is too big, then it's probably a bad design. • If people don't like it, then it's probably a bad design. • If it doesn't work, then it's probably a bad design
Design Issues : Avoiding Design Pitfalls • Keep a careful eye on the class design and make sure that an object’s role remains well defined. • If an object loses focus, you need to modify the design. Apply Corollary 2 (Single purpose). • Move some functions into new classes that the object would use. Apply Corollary 1 (Uncoupled design with less information content). • Break up the class into two or more classes. Apply Corollary 3 (Large number of simple classes). • Rethink the class definition based on experience gained.
methods UML Operation Presentation • OCL can be used to define the class attributes. Syntax • visibility name : (parameter‐list) : return‐type‐expression where, • Visibility is one of the following – + public visibility – # protected visibility – ‐ private visibility Parameter‐list is a list of parameters, separated by commas, each specified by name : type‐expression = default value • Return‐type‐expression is a language‐dependent specification of the implementation of the value returned by the method. • If return‐type is omitted, the operation does not return a value. •
Packages and Managing Classes • A package groups and manages the modeling elements, such as classes, their associations, and their structures. • package may contain both other packages and ordinary modeling elements.
- Slides: 18