Object Constraint Language (OCL) and Design Process in SDM

1. SDM-Unit 4 By: Ms N S Khairnar

3. Object Constraint Language (OCL) • Definition: The Object Constraint Language (OCL) is a declarative language describing rules applying to Unified Modeling Language (UML) models developed at IBM and is now part of the UML standard. • Why a formal language? • In object-oriented modeling, a graphical model, like a class model, is not enough for a precise and unambiguous specification. • There is a need to describe additional constraints about the objects in the model. • Such constraints are often described in natural language and Practice has shown that this will always result in ambiguities. • To write unambiguous constraints so-called formal languages have been developed.

4. 4 Parts of OCL: • Context: It defines the situation for the design element. The Context is usually the class to which the expression is attached. • Property: It represents the characteristics of the element. • Operation: Various Arithmetical, logical or relational operations. • Keywords: Reserved words. e.g. if, else, not,or,implies

5. Constraints can be applied as: • Guards- applied in Activity and State diagrams. • Invariants – Constraints to attribute • Precondition -Constraints to operation • Post condition- Constraints to operation

6. Constraints • The age of a person is not negative. • A person is younger than its parents. • After a birthday, a person becomes one year older. • A Person has 2 parents at max. • After somebody got a child, his/her child-set is not empty, and it is larger than before. • Only an adult can be owner of a car. • The first registration of a car can not be before it is built.

7. context Person inv: self.age >=0 • context Person inv: self.parents->forAll(p|p.age>self.age) • context Person::hasBirthday() post: self.age=self.age@pre+1 • context Person inv: self.parents->size()<=2 • context Person::getsChild() post: self.childs->notEmpty() and self.childs->size() > self.childs@pre->size() • context Person inv: self.age<18 impliesself.cars->isEmpty() • context Auto inv: self.registration>=self.constructionYear

8. OO Design Process: 1.Design Business Layer • Apply Design axioms to design classes, attributes, methods, associations, structures and protocols, for this follow following steps: • Refine the static class diagram by- • Refine attributes • Representing the methods algorithm by using activity diagram. • Refining association between classes. • Refining Class Hierarchy. • Iterate and Refine again.

9. 1. Designing Well defined class visibility • Specify how attributes and operations are visible in the system. • Public + • Private - • Protected # • Package ~ • Private and Protected Protocol Layers: Internal • Public Protocol Layer: External

10. 2.Refine attributes • Visibility Name : Type Multiplicity =initial value {Property string} • Eg. • + studentName : String [0..1] • –voter: Person[0..*]{unique}

11. Operation syntax: • Visibility Name (parameters) :return type {properties} • eg. +getLength(): void • Parameter Syntax: • Direction parameter name :type[multiplicity]=default value{properties} • Directions can be in or out.

12. Attribute Type • Single Valued • Multi valued • Reference to another object

13. 3. Representing the methods algorithm by using activity diagram.

18. Packages and Managing classes • A package groups and manages the modeling elements, such as classes their associations and their structures.

20. Part 2: Object Relational systems • Programming Model => Objects • Database System=> Relational • To resolve this mismatch, a mapping tool between the application objects and relational data must be established.eg. Java blend( allows developer to access relational data as java objects) • Creating an object model from existing relational database layout(schema)is referred to as ReverseEngineering. • And creating relational schema from existing object model is called Forward Engineering

21. Object Relational Mapping

22. For a tool to be able to define how relational data maps to and from application objects, it must have at least following two way mapping capabilities. • Table class mapping • Table-Multiple classes mapping • Table-inherited classes mapping • Tables-inherited classes mapping

23. 1. Table class mapping • Simple one to one Mapping of table to a class.

24. 2. Table-Multiple classes mapping • Single Table maps to multiple non inheriting Classes. If the value of custId is null, an employee instance is created runtime. Otherwise a customer instance is created.

25. 3. Table-inherited classes mapping • Single Table maps to many classes that have a common super class. • Allows the user to specify columns to be shared among the related classes.

26. II Designing Access layer • It contains following activities: • Mirror the Business class package. • Define Relationships. • Simplify classes and Relationships. • Iterate and Refine.

27. 1 Mirror business class package: • For every business class that has been identified & created, create one access class in the access layer package. • Eg. It there are three business classes Class1, Class2, and Class3 create three access layer classes Class1DB, Class2DB, and Class3DB.

29. 2. Define Relationships. • The same rule as applies among business classes also applies among access classes.

31. 3. Simplify classes and Relationships • The main goal here is to eliminate redundant or unnecessary classes or structures. • In most cases you can combine simple access classes and simplify the super and subclass structures. 3.1 Redundant Classes: If you have more than one class that provides similar services, simply select one and eliminate the others. 3.2 Method Classes: Revisit the classes that consist of only one or two methods to see if they are eliminated or combined with existing classes. If you can find no class from the access layer package, select its associated class from the business package and add the method as a private method to it.

34. Example of Bank System to map with access layer

35. Example: Creating an access class for BankClient class.

38. III Designing View layer • Once the analysis is complete we can start designing the UI objects. • A well defined UI present in the view layer motivates the user to use the application. • UI objects can be designed from users perspective of viewing the system. • View Layer is responsible for • 1) Responding to User interaction • 2)Displaying the business objects.

39. View Layer Design Process: • Macro level UI Design/ Identifying view classes by analyzing use cases • Micro level Design Activities. • Testing Usability and User Satisfaction. • Refining and Iterating a design.

40. 1.Macro level UI Design. • Main objective of macro process is to identify classes that interact with human actors by analyzing the use cases developed in the analysis phase.

41. 2.Micro level UI Design. • To be successful the design of a view layer objects must be user driven or user centric.

42. UI Design Rules: • Making the Interface simple and straightforward: Interface should be so simple so that the users are unaware of the tools and mechanisms that make the application work. • Making the interface transparent and Natural: Interface should be so intuitive and Natural so that the users can anticipate what to do next by applying their previous knowledge of doing task without a computer. • Allowing user to be in a control of the software: User always should feel in control of the software, rather than feeling controlled by software. • Make the Interface Forgiving: User actions should be easily reversed. • Make the interface visual: Design the interface so that users can see rather than recall. • Provide immediate feedback: User should never press a key or select an action without receiving immediate visual or audible feedback or both. When the cursor is on the choice, for example the color, emphasis and selection indicators show users they can select that choice. the color, emphasis and selection indicators change to show users their choice is selected. • Avoid modes whenever possible.: A mode is a state that excludes general interaction or otherwise limit the user to specific interaction. • Make the interface consistent.

43. Prototyping the User Interface • Prototyping involves a no of Iterations. Through each iteration we add a little more to application. • Create the User Interface Objects (such as buttons, Data entry fields) • Link or assign the appropriate behaviors or actions to these use interface objects and their events. • Click debug and add more by going back to step 1. • When you complete the first prototype, meet with the user for an exchange of ideas about how the system will go together. • The user should not feel that you are imposing or even suggesting this design. • You should be very positive about the users system and wishes.