Object-Oriented Analysis and Design with UML PDF

www.covenantuniversity.edu.ng Object-Oriented Analysis and Design with UML Dr. A.A. ONI 1  Objectives  To know the concept of object orientation in software design.  To explain how a software design may be...

www.covenantuniversity.edu.ng Object-Oriented Analysis and Design with UML Dr. A.A. ONI 1  Objectives  To know the concept of object orientation in software design.  To explain how a software design may be represented as a set of interacting objects that manage their own state and operations.  To describe the activities in the object-oriented design process.  To understand the function of various UML diagrams. 2  Object-Orientation  Object orientation employs real world concept of Objects in the software development process.  Some arguments towards object-orientation are: – Objects are easier for people to understand – A better medium of communication among specialists – Data and processes that act on data are not separated – Code can be reused more easily – Object orientation is mature and well proven Most new programming languages are object oriented. 3  What is an Object? 1 of 2  An object is a NOUN – Anything that can have its own identity, animate or inanimate  All objects have attributes: – A student has matriculation number, level, a room number, CGPA, etc. – A university has faculty, departments and programmes; a course has title, code and units; task has description, date and duration. – A car has brand name, model, Year and engine specs.  Objects also have behavior: – A student can be promoted, CGPA computed, room assigned; a course can be registered, assigned to a lecturer; a task can be scheduled, assigned to an employee; a car can move from one place to another. 4  What is an Object? – 2 of 2  In object-oriented software development, real world objects are migrated into the code.  Objects become stand-alone independent modules with their own data and process.  For example: – Person Object (name, age, sex), we can later update the knowledge embedded in person to include height and state of origin. – If we use person in an academic context, he/she becomes a student or faculty member, a person in the hospital can be a patient or doctor or nurse etc.  Objects are a good way to model any business process. 5  How Objects are Represented anObject The object’s name Attribute1 – which is underlined Attribute2 Attribute3 Its attributes … – Its knowledge or data Operation1() Operation2() Its operations Operation3() – Its behavior or methods. Operation4() … 6  Key Concepts of Object Orientation  A Class: is a template for building objects and from which object instances evolve. aPerson  A person Object – Attributes (Data about the name person) address Name dateOfBirth Address Date of Birth changeName() – Operations computeAge() Change Name changeAddress() Compute Age Change Address 7  Key Concepts of Object Orientation  A class encapsulates characteristics common to a group of objects.  Every object is an instance of a class  Classes are denoted the same way as objects – Except for that the Class name is not underlined – Class names start with a capital letter. – Class names tend to be short and in the singular. 8  Key Concepts of Object Orientation  Relationships – How objects organize and connect with other objects: Association, Inheritance, Composition and Aggregation  Encapsulation  Polymorphism 9  Links Between Objects  The actual connections between objects are called links.  A link can also be an attribute: the label, or role, indicates the attribute’s name. – For example, aCustomer has an attribute, called address, that links it to an Address object, and another attribute, called name, that links it to the String representing its name. 10 For Example 11 11  Relationships  Even though objects are independent, no object is an island. – A Relationship(s) occur when objects connect (relate) with each other directly or indirectly, loosely or strongly – A system is formed based on the various relationships and interactions among several objects.  Types of Relationships among Objects – Association - Aggregation – Inheritance - Composition 12  Association  Association is a weak or loose form of connection: – The objects may be part of a group, or family, of objects but they’re not completely dependent on each other.  For example, – Consider a car, a driver, a passenger A and another passenger B, how would you describe the relationship among these objects? How would describe relationship among students in a class? 13 Denoting Association 14  Aggregation/Composition  Aggregation and composition associations both denote an ‘is-part-of’ relationship between two classes.  Aggregation means putting objects together to make a bigger object.  For Example manufactured items usually form aggregations: – For example, a Car consist of Engine, Body, Uphostry  Aggregations usually form a part–whole hierarchy and implies strong or close dependency, – Remove the Engine from a Car, it’s no longer a Car 15 Denoting Aggregation 16 16  Aggregation/Composition  Aggregation generally indicates that the part may be shared with other objects – an employee may work for other companies  whilst composition indicates stronger ownership of the part by the whole – the employee may only work for one company. 17  Composition Example  Composition is about expressing relationships between objects. – Example: A chair has a Seat. A chair has a back. And a chair has a set of legs.  The phrase "has a" implies a relationship where the chair owns, or at minimum, uses, another object.  This implies that Chair object itself is composed of an instance of the Back class, an instance of the Seat class and 4 instances of the Leg class. 18  Denoting Composition Chair Seat Back Leg 19  Quick In-class Activity  Which of the following examples are association and which is aggregation? – Houses on a street. – Pages in a book. – Notes in a symphony. – Collection of books on a shelf 20  Generalisation/Specialisation  Generalization/specialization: is the concept of extracting the common attributes and bahviours between object classes in order to abstract them into another class called superclass whose attributes can then be inherited by other object classes (subclass).  Generalisation in the UML is implemented as inheritance in OO programming languages. 21  Inheritance  Inheritance: the concept Person wherein methods and/or -Name -Age attributes defined in a class can -Height be inherited or reused by another class.  The entity that inherits is called the subtype while the one Male Female inherited is called the supertype -Sex -Sex 22  Advantages and Disadvantages of Inheritance  Advantages – Enhances reusability – Supports overriding of base class methods – Makes representation of real world easier  Disadvantages – Subclass and base class can get tight couples 23  Polymorphism  Polymorphism: It a characteristics of object-orientation that allows different objects to interpret the same message differently depending on their individual internal states.  Polymorphism is achieved when a method in a superclass has been overridden by another method with the same name in the subclass. 24  Encapsulation  Encapsulation refers to an object hiding its attributes behind its operations – Objects are black-boxes to other objects, and relate via prescribed interfaces – It seals the attributes in a ‘en’-capsule, with operations on the edge., serving as interfaces – These hidden attributes are said to be private and are only accessible via the operations 25 Summary of Relationships 26  The Concept of Object Hierarchy  Objects, and their associations and aggregations, can be grouped into a hierarchy  Types hierarchy – Graphs A graph is an arbitrary set of connections between objects. Objects in an association often form a graph. – Trees A tree is a special case of a graph: each node in a tree has only one parent node, but it can have any number of children. A parent contains the children, in a part–whole sense 27  Concept of Hierarchy in Classes (1 of 2) Lets Group the following Classes into categories  Concept of Hierarchy in Classes (2 of 2) Inheritance: – Trains inherit the characteristics of land vehicles. Generalization/specialization: – A train is more specialized than a land vehicle; – A land vehicle is more generalized than a train. Parent/child: – Land Vehicle is the parent of Train; Train is a child of Land Vehicle. Superclass/subclass: – Land Vehicle is the superclass of Train; Train is a subclass of Land Vehicle. Base/derived: – Land Vehicle is the base from which Train is derived. 29 Study and Analyse 30  Concept of Inheritance  Inheritance allows us to specify that a class – Gets some of its characteristics from a parent class and then adds its own unique features  Multiple inheritance: Multiple Inheritance happens when an object or class inherits characteristics and features from more than one parent object or parent class. – It introduces complexity (for the designer and the client programmer). – It causes name clashes: Name clashes occur when elements with the same name, but different implementations, are inherited via different routes. – It causes repeated inheritance: Repeated inheritance means inheriting the same element from more than one route. 31  Must Do Task…  Differentiate the following with concrete examples – Inheritance – Composition – Association – Aggregation  What is Polymorphism? 32  Multiplicity  Multiplicity: This concept specifies the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class.  Example: 33  Object-Oriented Analysis and Design  Object-oriented analysis and design – Involves the process of modeling the functionality of a software applications using object-oriented techniques.  OOA models are pictures that illustrate the system’s objects from various perspectives such as structure and behaviour.  The Unified Modeling Language (UML) is the de facto standard notation used in industry for software documentation and OOAD. 34  Object-Oriented Analysis and Design  An object is an encapsulation of data and the set of operation that transforms it. The data attributes are called properties while the operations that transform the data are called methods. 35 Unified Modelling Language (UML)  By the mid-1990s, the best-known methodologies were those invented by – Ivar Jacobson, James Rumbaugh and Grady Booch (Three Amigos) – Each had his own consulting company using his own methodology and his own notation. – By 1996, Jacobson and Rumbaugh had joined Rational Corporation (founded by Booch) – They developed a set of notations which became known as the Unified Modeling Language (UML). 36 3 ‘Amigos’ who developed the UML Ivar Jacobson James Rumbaugh Grady Booch 37 37  Uses of UML  As a brainstorming tool for high-level documentation.  As a pictorial programming language, – Generating code from it or synthesizing it from existing code.  However, UML is a language and notation for – Specification, – Construction, – Visualization, – Documentation of models of software systems. 38  Unified Modeling Language (UML)  UML show the overall system design that enables right decisions to be made early in the process of developing the software.  It enables ease of maintenance by providing more effective visual representations of the system.  UML Categories  UML consist of about 13 types of diagrams representing the structural and behavioral aspect of the system  Structural Diagrams – Emphasize what must be present in the system  Behaviour diagrams – Emphasize events and flow of what must happen in the system 40 Hierarchy of UML Diagrams 41 41  Some UML Structural Diagrams  Structural Diagrams – Class diagram – depicts the system’s object structure. They show classes and their relationships with each other. – Component diagram – depict the physical architecture of the system (components and their relationships). – Deployment diagram – describe the physical architecture of the hardware and software in the system i.e. they depict the software components, processors and devices that make up the system architecture. 42  Some UML Behavioural Diagrams  Behaviour diagrams: – Use case diagram – depicts graphically interaction between external agent (users and other systems) and the system. It shows actors, use cases, and their relationships. – Activity diagram & Object flow diagram Both shows activities, object states, states, state transitions, and events. 43  Some UML Behavioural Diagrams  Behaviour diagrams: – Collaboration/Communication diagram – shows objects and their relationships, including their spatially structured message exchange. – Sequence diagram – shows objects and their relationships, including their chronologically structured message exchange. – State diagram – shows states, state transitions, and events. 44 Overview of Process in OOAD & Key Questions  Focus on – Requirement Gathering Phase Use Case Scenario Use case Diagrams – System Analysis Phase Class Diagrams – System Design Phase System Architecture Component Diagrams 45  Requirements Gathering Phase  Business modeling – Involves understanding the context in which the software will operate Key Question: How does the business process flow?’  System requirements modeling – Involves what capabilities the new software will have. – Functional & Non-functional specifications Key Question: How will the new system or software improve or enhance the business process?’ 46  System Analysis Phase  Analysis means understanding what we’re dealing with. – There is need for clarity on the relevant entities of the system, their properties and their inter- relationships. – Key Question: ‘What entities are we dealing with?’ ‘How can we be sure we have the right ones?’ 47  Analysis Phase  Important Steps – Identify candidate CLASSES relevant to the system Examine the system requirements model Document them in a class diagram. – Identify relationships and multiplicity among classes E.g. association, aggregation, composition and inheritance. – Draw Class Diagram showing relationships and multiplicity – Identify class attributes (properties of the objects) for the classes.  Ensure the classes identified agrees with the use case. 48  Step 1: Identify Classes  Based on the Business and System Requirement models, candidate classes can be easily identified.  Important TIPS – Candidate classes are often indicated by nouns in the use cases. – With a little practice, we can quickly cross out those nouns that represent: Actors, the System itself, Boundaries (interface with actors) 49  Step 2: Identify Relationships  After identification, draw relationship among them.  There are four possible types of relationship: – Inheritance: A subclass inherits all of the attributes and behaviour of its superclass. – Association: Objects of one class are associated with objects of another class. – Aggregation: Strong association – an instance of one class is made up of instances of another class. – Composition: Strong aggregation – the composed object can’t be shared by other objects and dies with its composer.  Important TIPS – Frequency of use should be in this order association > aggregation > inheritance > composition. 50  Multiplicity in Relationships  All relationships except inheritance can indicate at either end the number of run-time objects that are allowed to take part in the relationship (i.e. the multiplicity of the relationship): – n: Exactly n – m..n: Any number in the range m to n (inclusive) – p..*: Any number in the range p to infinity – *: Shorthand for 0..* – 0..1: Optional 51  Book Reference  Object-Oriented Analysis and Design Understanding System Development with UML 2.0 – Mike O’Docherty 52