OBJECT ORIENTED METHODS UML USE CASE AND CLASS

OBJECT ORIENTED METHODS UML (USE CASE AND CLASS DIAGRAM) Presented by: CHAN LAI SAN (12034569) REBAH DAW SARREB (16033719) FIDA AL-OBAISI (17032975) 08 April 2008 (Tuesday 6 pm – 7: 30 pm)

Introduction to UML • UML is a multipurpose modelling language that provide a standard guideline for modelling a system using its diagrams. • Each diagram carries the specifications and requirement of that same system for use by different people for different purpose. • UML diagrams only shows what is in a system and how it behave. It does not tie to any programming languages. • UML are design to be flexible, easily extendable, and strongly emphasize the concept of reuse, layering, partitioning and modularity. • UML provide guideline to transform one diagram to another diagram while preserving the consistency between models. • It is used widely in all phases of complex software development life cycles, development of many systems engineering, as well as in modelling of many business processes.

Introduction to UML Diagrams • There are thirteen types of UML diagrams: v v v v Class diagram Object diagram Component diagram Static Structure Composite Structure diagram Package diagram Deployment diagram Use Case diagram Activity diagram Behaviour Statechart diagram Sequence diagram Communication diagram Interaction Timing diagram Interaction Overview diagram

USE CASE DIAGRAM � It is graphical overview the functionality and requirement of the system and the interface with outside the system. � It shows the actors and the relationship between the actors and the use cases. � It used to understand the system and what system is. � The use case diagram has four components: 1 - Actor 2 - Use cases 3 - System boundary 4 - Relationship

Use Case Terminologies Actor A role played by a person, other system external system Use case A start-to-finish feature of the system Association The communication among an actor and a use cases Extend The relationship between use cases when use case completely consists the behavior of another use case <<extend>> Include The relationship between use cases when one use case has explicitly contains the behavior of another use case Generalization The relationship between use cases , when the parent use case identify behaviour that its children can inherit Boundary The boundary of the system contain the use cases and the relationships between use cases <<include>>

Relationships �The purpose of the relationship is to explain that an actor is basically involved in a use case. add book record <<include>> Maintain member records Maintain book records Borrow book pay fine <<extend>> Return book Librarian

Class Diagram system static structure documented by class diagram define as a rectangular boxes class Attributes A class building should: [2], [4], [5] Operations() Meet all the system criteria, and realize the use case diagram. Design it in cheap and quick ways. Design a system to easy maintain and flexible to add future requirements. The model design must contain all the description of what should the system do. The class name should be a noun. The attributes are name phrases. The methods have a verb sentences, and the links (association) between that classes contain the exact operations between them such as: is a , part of, contain, has a, check for…etc

Class Diagram Terminologies Name Symbol Class student ID show results () Links Description whole class rectangular contents : -class name (student). -class attributes (such as student ID). -class operations (such as show results). defaulted association between classes bi-directional link composition aggregation interfaces qualified links(association) Multiplicities 1 1. . * 0 0. . 1 constraints the numbers of existence links between classes.

Operations: Relation 1. Association Symbol Member 1. 1 Multiplicity Member 1. 2 Direct association 2. Aggregation 3. Composition Description Library 4. Generalization /inheritance Book 1 Borrow 1. . . * Member Copy Borrow Book Library Book Plants Trees Roses The association established when two classes are connected to each other. <Member can borrow a book> Relation details by give one to one, one to many, many to many. <one or more books can borrowed by a member> The arrowed association gives the one direct relation between classes, because the association by default comes with bidirectional links. Hallow diamond means. If the copy class was damage, the library class still exists. Solid diamond means, if the library class damaged, the book classes also damaged. Tree and roses are part of plants, and they make photosynthesis shared from plants properties.

Relationship between Use Case and Class Diagrams � Following will be some guideline for use case realisation: v Identify possible set of classes that can derived from the use case diagram. v Understand how those classes might relate v Suppressed details not directly related to collaboration. v Ensure the consistency of diagrams during realisation process. � Example of Use Case and Class diagram for library system after realisation: add book record <<include>> Maintain member records Maintain book records Borrow book pay fine <<extend>> Librarian Return book Member member name member ID address Borrow book Return book 1. . n Asked for 1. . * Interested in n 1. . n Librarian librarian ID return book check fines Copy copy ID due date Take a copy() 1. . * part of checked 1 0. . 1 Status book ID book title cat. no Book book ID availability

CONCLUSION o In summary, UML is a simple to use guideline for creating model of a system. Because of its simplicity and flexibility, it is acceptable and applicable in various fields as long as there is a need of building model. o Each of the UML diagrams holds some information of other diagram and can be used to realise the other diagram. o There are many methodologies like Object Oriented that provide guidelines to transform one diagram to another diagram while ensuring the consistency is still preserved. o UML is not only useful in documenting model. In facts, each of its diagrams is helping towards the project design till implementation stage.
![Reference: [1] Introduction to OMG Unified Modelling Language™ (UML®) by OMG, updated on 11/09/2007. Reference: [1] Introduction to OMG Unified Modelling Language™ (UML®) by OMG, updated on 11/09/2007.](http://slidetodoc.com/presentation_image_h/98eff4b18d6c3ffd77d54249a792b959/image-12.jpg)
Reference: [1] Introduction to OMG Unified Modelling Language™ (UML®) by OMG, updated on 11/09/2007. Web link: http: //www. omg. org/gettingstarted/what_is_uml. htm [2] Bennett S. , Mcrobb S. and Farmer R. , Object Oriented System Analysis and Design using UML, Mc. Graw Hill, (2006). [3] Jason T. Roff, 2003, The Mc. Graw-Hill/Osborne, UML A Beginner's Guide. [4] Stevens P. , and Pooley R. , Using UML Software Engineering with Objects and Components, (2000). [5] Sommerville I. , Software Engineering, seventh edition (2004).
- Slides: 12