Software Engineering : OOAD using UML
4 likes3,185 views
This document provides an overview of object-oriented software design using the Unified Modeling Language (UML). It discusses key concepts in object-oriented design like classes, methods, inheritance, and relationships. It also describes UML diagrams for modeling different aspects of a system, including use case diagrams for capturing user requirements, class diagrams for modeling the structural design, and how UML was developed through the merging of earlier object-oriented modeling notations. The document aims to introduce software engineering principles and object-oriented modeling techniques using UML.
![Object Modelling Techniques
UML
Booch’s
Methodology
[Booch 1991]
OOSE
[Jacobson 1992]
OMT [Rumbaugh 1991]](https://image.slidesharecdn.com/sepase4-171112030219/85/Software-Engineering-OOAD-using-UML-9-320.jpg)
Software Engineering : OOAD using UML
- 1. Software Engineering Principles Ajit K Nayak, Ph.D. [email protected] Object oriented Software design using UML
- 2. Acknowledgements • Slides of Prof. Rajib Mall, IIT, KGP
- 3. Introduction • Object-oriented (OO) design techniques are extremely popular: – Inception in early 1980’s and nearing maturity. – Widespread acceptance in industry and academics. – Unified Modelling Language (UML) already an ISO standard (ISO/IEC 19501).
- 4. Object Oriented • A system is designed as a set of interacting objects: – Often, real-world entities: e.g. an employee, a book etc. – Can be conceptual objects also: e.g. Controller, manager, etc. • Objects consists of data (attributes) and functions (methods) that operate on data. – Encapsulation • Hides organization of internal information – Data abstraction
- 5. Model of an Object Data Class m8 m7 m6 m5 m4m3 m2 m1 mi are methods of the class
- 6. Components of Object Model • Class • Methods & Messages • Relations – Inheritance – Association – Aggregation/composition – Dependency • Polymorphism • Genericity
- 7. Advantages of Object-Oriented Development • Code and design reuse • Increased productivity • Ease of testing and maintenance • Better understandability • Elegant design: – Loosely coupled, highly cohesive objects: – Essential for solving large problems. • Initially incurs higher costs – After completion of some projects reduction in cost become possible • Using well-established OO methodology and environment: – Projects can be managed with 20% -- 50% of traditional cost of development.
- 8. Object modelling using UML • Unified Modeling Language is a modelling language – Not a system design or development methodology • Used to document object-oriented analysis and design • Independent of any specific design methodology • UML developed in early 1990s – To standardize the large number of object-oriented modelling notations that existed. • Current version is UML2.0 • Adopted by Object Management Group (OMG) in 1997 – OMG an association of industries that promotes consensus notations and techniques
- 9. Object Modelling Techniques UML Booch’s Methodology [Booch 1991] OOSE [Jacobson 1992] OMT [Rumbaugh 1991]
- 10. Flash Back • Grady Booch was working as Chief Scientist of Rational Software Corporation • Rational Software Corporation hired James Rumbaugh from General Electric in 1994 • Ivar Jacobson joined them at Rational in 1995 • And the History is made Booch Rumbaugh Jacobson
- 11. When you want to build a house!
- 12. What is UML • UML a graphical modelling tool, easy to understand and construct • It provides many diagrams to capture different views of a system – Model is required to capture only important aspects – Helps in managing complexity
- 13. UML 1.x Diagrams • 9 diagrams supporting 5 views User’s View -Use Case Diagram Structural View - Class Diagram - Object Diagram Implementation View - Component Diagram Environmental View - Deployment Diagram Behavioural View - Sequence Diagram - Collaboration Diagram - State-chart Diagram - Activity Diagram
- 14. UML 2.0 Diagrams UML 2.0 Diagram Behavior Diagram Structure Diagram Class Diagram Composite Structure Diagram Object Diagram Activity Diagram Use Case Diagram State Machine Diagram Interaction Diagram Component Diagram Deployment Diagram Package Diagram Sequence Diagram Communication Diagram Interaction Overview Diagram Timing Diagram
- 16. Use Case Model • Consists of a set of “use cases” • It is the central model: – Other models must conform to this model – Not really an object-oriented model – A functional model of the system • Use Cases are the main tasks performed by the users of the system. • Use Cases describe the behavioral aspects of the system. • Use Cases are used to identify how the system will be used. • Use Cases are a convenient way to document the functions that the system must support. • Use Cases are used to identify the components (classes) of the system.
- 17. Use Cases • Normally, use cases are independent of each other • Implicit dependencies may exist • Example: In Library Automation System, renew-book and reserve-book are independent use cases. – But in actual implementation of renew-book--- A check is made to see if any book has been reserved using reserve-book. • Other Possible Use Cases in Library information system – issue-book – query-book – return-book – create-member – add-book, etc.
- 18. Representation of Use Cases • Represented in a use case diagram – A Use Case is represented by an ellipse – System boundary is represented by a rectangle – Users are represented by stick person icons (actor) – Communication relationship between actor and Use Case by a line • External system by a stereotype Tic-tac-toe game Play Move
- 19. Ex1: Draw a Use Case Model • Video Store Information System supports the following business functions: – Recording information about videos the store owns • This database is searchable by staff and all customers – Information about a customer’s borrowed videos • Access by staff and also the customer. It involves video database searching. – Staff can record video rentals and returns by customers. It involves video database searching. – Staff can maintain customer, video and staff information. – Managers of the store can generate various reports.
- 20. Ex1: Solution Maintain Customers Staff Rent/Return Videos Maintain Videos Generate Reports Customer Manager Search for Videos «include» «include» Video Store Information System
- 21. Development of a Use Case Diagram • Identify all of the actors who will use the system. • Interview these actors to identify the functions that they need to perform. (use cases) • Identify scenarios (sequence of steps to accomplish a use case). • Identify common steps within the different scenarios. Separate them into different use cases so that they can easily be included in other scenarios. • Identify relationships between use cases.
- 22. Actors • Actor - an entity external to the system that in some way participates in the use case. Actor represents a role that a user can play. • An actor typically stimulates the system with input events or receives outputs from the system or does both. • Actors are treated like classes and can be generalized. • Primary actor: Use the system to achieve a goal. (found in left side of the use case diagram) • Secondary actor: plays a supporting role to facilitate the primary actor to achieve their goal. (right side)
- 23. Identification of Use Cases • Actor-based: – Identify the actors related to a system or organization. – For each actor, identify the processes they initiate or participate in. • Event-based – Identify the external events that the system must respond to. – Relate the events to actors and use cases.
- 24. Factoring Use Cases • Two main reasons for factoring: – Complex use cases need to be factored into simpler use cases – To represent common behaviour across different use cases • Three ways of factoring: – Generalization – Include – Extend
- 25. Generalization • The child use case inherits the behaviour of the parent use case. – The child may add to or override some of the behavior of its parent. parent child Registration Graduate registration Under-graduate registration
- 26. Include • When you have a piece of behaviour that is similar across many use cases – Break this out as a separate use-case and let the other ones “include” it • Examples of use case include – Validate user interaction – Sanity check on sensor inputs – Check for proper authorization Base use case Common use case <<include>> Issue Book Check Reservation Renew Book <<include>> <<include>>
- 27. Extends • Use when a use-case optionally can do a little bit more: – Capture the normal behaviour – Capture the extra behaviour in a separate use-case – Create extends dependency • Makes it a lot easier to understand Order Item Show Catalog <<extend>>
- 28. Example Place Order Supply Customer Data Order Product Arrange Payment Request Catalog <<include>> <<include>> <<include>> <<extend>> Salesperson asks for catalog Sales Person Cash Payment Credit Payment
- 29. Ex2: Course Management Software • At the beginning of each semester, – Each professor shall register the courses that he is going to teach. • A student can select up to four-course offerings. – During registration a students can request a course catalogue showing course offerings for the semester. – Information about each course such as professor, department and prerequisites would be displayed. – The registration system sends information to the billing system so the students can be billed for the semester. • For each semester, there is a period of time during which dropping of courses is permitted. • Professors must be able to access the system to see which students signed up for each of their course offerings.
- 30. Register offering Show registration Register course Drop Course Student Calendar Course Management Software Ex 2: Solution See Course List Professor <<Extend>> <<External>> Billing System
- 31. Use-Case Model using Packaging
- 33. Thank You
- 34. Class • A class represents a set of objects having similar attributes, operations, relationships and behaviour. • Instances are objects • Template for object creation • Considered as abstract data type (ADT) – Examples: Employees, Books, etc. • Sometimes not intended to produce instances: – Abstract classes
- 35. Methods & Messages • Operations supported by an object: – Means for manipulating the data of other objects. – Invoked by sending a message (method call). – Examples: calculate_salary, issue-book, member_details, etc.
- 36. Inheritance • Allows to define a new class (derived class) by extending or modifying existing class (base class). • Represents generalization- specialization relationship. • Allows redefinition of the existing methods (method overriding). • Types – Single/Simple; multilevel – Multiple LibraryMember ResearchPostGradUnderGrad StaffStudentsFaculty Base Class Derived Classes
- 37. Association • Enables objects to communicate with each other: – Thus one object must “know” the address of the corresponding object in the association. • Usually binary: – But in general can be n-ary. Library Member Book 1 *borrowed by
- 38. Aggregation • Represents whole-part relationship • Represented by a diamond symbol at the composite end • Cannot be reflexive(i.e. recursive) • Not symmetric • It can be transitive Document Line * Paragraph 1 *
- 39. Composition • A stronger form of aggregation – The whole is the sole owner of its part. • A component can belong to only one whole – The life time of the part is dependent upon the whole. • The composite must manage the creation and destruction of its parts. Order 1 * Item
- 40. Dependency • Dependency relationship can arise due to a variety of reasons: – Stereotypes are used to show the precise nature of the dependency. Type of dependency Stereotype Description Abstraction «abstraction» Relates two model elements, that represent the same concept at different levels of abstraction Binding «bind» Connects template arguments to template parameters to create model elements from templates. Realization «realize» Indicates that the client model element is an implementation of the supplier model element Substitution «substitute» Indicates that the client model element takes place of the supplier.
- 41. Polymorphism • Denotes poly (many) morphism (forms). • Under different situations: – Same message to the same object can result in different actions: • Static binding • Dynamic binding
- 42. Genericity Ability to parameterize class definitions. Example: class stack of different types of elements: Integer stack Character stack Floating point stack Define generic class stack: Later instantiate as required
- 43. Thank You