Prof Anil Thakur Session 2 Object Oriented Methodologies

Prof. Anil Thakur Session 2 §Object Oriented Methodologies §The Unified Approach Modelling §Why Models? §Static and Dynamic Models §Functional Models Model is a simplified version of reality

Object Modeling §Object, Links, Association, inheritance §Grouping Construct §Advantage of Object Modeling §Problem on Object Modeling

Why Do We Model? • We build models to better understand the system we are developing. • Modeling achieves four aims. Modeling: – Helps us to visualize a system as we want it to be. – Permits us to specify the structure or behavior of a system. – Gives us a template that guides us in constructing a system. – Documents the decisions we have made. • We build models of complex systems because we cannot comprehend such a system in its entirety. 3

Object Oriented Methodologies • Technique to do good analysis • Too Many methodologies – 1986 Booch – 1987 Sally Shlaer and Steve Mellor – 1989 Beck and Cunningham – 1991 Jim Rumbaugh – 1991 Peter Coad – 1994 Ivar Jacobson

Rumbaugh ET AL’s Object Modelling Technique • Fast and intuitive approach • Details like class, attributes methods, inheritance and associations expressed easily • Dynamic behaviour of object can be represented • OMT consists of four phases – – Analysis System Design Object Design Implementation

OMT Modeling parts • Object Model – Presented by Object model and Data Dictionary – Describes identity, attributes and operations – Class interconnected by association lines – Association lines represent sets of links from Object to class to the object of another class.

OMT Modelling parts • A Dynamic Model – State diagram and event flow diagram – Depicts state, transitions, events and actions. – Is a network of states and events. – Each state receive one or more events to get transition to other state

The OMT Functional Model • The OMT data flow diagram (DFD) shows flow of data between different process in the business • OMT DFD simple and intuitive • Do not focus on details • One of the strongest tool sets for OOAD • Four primary symbols – The process is any function being performed (Verify password) – Data Flow shows the direction of data movement (PIN Code of ATM) – The data store is a location where data are stored( Account ) – An external entity is a source or destination of data (ATM Card Reader)

The Booch Methodology • • • Widely used Uses Object paradigm Large set of symbols Most symbols used towards the end Consist of following diagrams – – – Class diagram Object Diagram State transition diagram Module diagram Process Diagram Interaction Diagram

Booch prescribes • A Macro Development Process – Technical Management – Corresponds to the requirements – Overall project management – Controlling framework for micro • A Micro Development Process – Day-to-day activity – Could be blurry or transparent to outside viewer.

The Jacobson Methodology • Consist of – Object Oriented Business Engineering (OOBE) – OO Software Engineering (Objectory: Object factory for software development) • Use case driven development • Stress traceability (forward and backward) • begins with a user of the system initiating a sequence of interrelated events

Patterns • Concept of building system from prefabricated and predefined system components. • Documentation to help categorize and communicate about solutions to a recurring problems • A good pattern – – Solves a problem Is a proven concept Describes a relationship Has a significant human component.

Framework • Deliver application development pattern to support best practice sharing during application development • Generic solution to a problem that can be applied to a problem for all levels of software development

The Unified Approach • Create a best practices by unifying all the modeling techniques. • Not a yet another Methodology. • Uses UML to describe Model (documents) • Revolves around following process and concepts – – – Use case driven development Object oriented analysis. Object oriented design Incremental development and prototyping Continuous Testing

The Unified Approach • Methods and technology employed – Unified Modeling Language – Layered Approach – Repository for object oriented system development patterns and frameworks – Component based development

The Unified Modeling Language “The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct, and document the artifacts of a software intensive system. ” • Grady Booch • James Rumbaugh (OMT) • Ivar Jacobson (OOSE) 16

What Is the UML? • The Unified Modeling Language (UML) is a language for • • Specifying Visualizing Constructing Documenting the artifacts of a software-intensive system

UML History

Inputs to UML Booch Rumbaugh Jacobson Meyer Fusion Operation descriptions, Message numbering Before and after conditions Embley Harel Singleton classes, High-level view State charts Gamma, et. al Wirfs-Brock Frameworks, patterns, notes Shlaer - Mellor Object Lifecycles Odell Classification Responsibilities

The UML Provides Standardize Diagrams Use Case Diagrams Activity Diagrams Scenario Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Use Case Diagrams State Diagrams Class Diagrams Model Deployment Diagram State Diagrams Object Diagrams State Diagrams Component Diagrams

A Sample UML Diagram: Use Cases A University Course Registration System Login Registrar Maintain Professor Information View Report Card Student Register for Courses Maintain Student Information Course Catalog Close Registration Select Courses to Teach Professor Submit Grades Billing System

The Value of the UML • Is an open standard • Supports the entire software development lifecycle • Supports diverse applications areas • Is based on experience and needs of the user community • Supported by many tools 22

UML Partners • • • • Rational Software Corporation Hewlett Packard I Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft Objec. Time Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys 23

Overview of the UML • • Modeling elements Relationships Extensibility Mechanisms Diagrams

Modeling Elements • Structural elements – class, interface, collaboration, use case, active class, component, node • Behavioral elements – interaction, state machine • Grouping elements – package, subsystem • Other elements – note 25

Relationships • • Dependency Association Generalization Realization 26

Use Case Diagram • Captures system functionality as seen by users 27

Use Case Diagram • Captures system functionality as seen by users • Built in early stages of development • Purpose – Specify the context of a system – Capture the requirements of a system – Validate a system’s architecture – Drive implementation and generate test cases • Developed by analysts and domain experts 28

Class Diagram • Captures the vocabulary of a system 29

Class Diagram • Captures the vocabulary of a system • Built and refined throughout development • Purpose – Name and model concepts in the system – Specify collaborations – Specify logical database schemas • Developed by analysts, designers, and implementers 30

Object Diagram • Captures instances and links 31

Object Diagram • Shows instances and links • Built during analysis and design • Purpose – Illustrate data/object structures – Specify snapshots • Developed by analysts, designers, and implementers 3

Component Diagram • Captures the physical structure of the implementation 33

Component Diagram • Captures the physical structure of the implementation • Built as part of architectural specification • Purpose – Organize source code – Construct an executable release – Specify a physical database • Developed by architects and programmers 34

Deployment Diagram • Captures the topology of a system’s hardware 3

Deployment Diagram • Captures the topology of a system’s hardware • Built as part of architectural specification • Purpose – Specify the distribution of components – Identify performance bottlenecks • Developed by architects, networking engineers, and system engineers 36

Sequence Diagram • Captures dynamic behavior (time oriented) 37

Sequence Diagram • Captures dynamic behavior (time oriented) • Purpose – Model flow of control – Illustrate typical scenarios 38

Collaboration Diagram • Captures dynamic behavior (message oriented)

Collaboration Diagram • Captures dynamic behavior (message oriented) • Purpose – Model flow of control – Illustrate coordination of object structure and control

Statechart Diagram • Captures dynamic behavior (event oriented)

Statechart Diagram • Captures dynamic behavior (event oriented) • Purpose – Model object lifecycle – Model reactive objects (user interfaces, devices, etc. )

Activity Diagram • Captures dynamic behavior (activity oriented) 43

Activity Diagram • Captures dynamic behavior (activity oriented) • Purpose – Model business workflows – Model operations

Static and Dynamic Model • Static Model – Snapshot of system parameter at rest – Represent static or structural aspect – e. g. UML Class diagram • Dynamic Model – Reflects behaviour of system over time. – How object interact to perform tasks

Lighter moments • Question: What is the difference between an object methodologist and a terrorist? Answer: You can negotiate with the terrorist. • "In C we had to code our own bugs. In C++ we can inherit them. "

OBJECT MODELING • Objects and Classes • Operation – Function or transformation that may be applied to objects – Hire, fire, open, close, hide etc. • Methods – Implementation of operation in the class – Print operation can have multiple methods as for binary or ASCII files.

Links and Associations • Link is a Physical or conceptual connection between object instances. • Association describes a group of links with common structure and common semantics (works-for) • All the links in an association connect object from the same class • Bidirectional (works–for : : employs) • Can be binary, ternary or higher

Multiplicity • Definitions • Possibilities • Examples 49

Definitions • Multiplicity defines how many instances of one class can be associated with the instance of the other class • For example instance of class Store can have zero to many instances of class Product • Also an instance of class Product can be in zero to many instances of class Store 50

Definitions • Minimum number of instances Measures if occurrence is optional • It may be zero or one representing whether at least one instance is required or not • A Store can have zero instances of class Product • Also an Employee can not have less than one instance of class Pay. Rate 51

Definitions • Maximum number of instances Measures the maximum numbers of occurrences • It may be one or many • An Office may not have more than one instance of class employee • A Store can have many instances of class Product 52

Definitions • Thus for each association there is both a minimum and a maximum • Minimum is expressed in Rational Rose as 0. . 1 or 1. . 1 • Often 1. . 1 is shown as simply as 1 • Maximum is expressed in Rational Rose as 0. . * or 1. . * • Often 0. . * is shown as simply as * 53

Definitions • Bi directional The fact that associations are read in both directions • For example instance of class Store associates with many instances of class Product • And instance of class Product associates with many instances of class Store 54

Multiplicity • Unspecified • Exactly one • Zero or more (many, unlimited) 1 0. . * * • • 1. . * One or more Zero or one (optional scalar role)0. . 1 Specified range 2. . 4 Multiple, disjoint ranges 2, 4. . 6

Examples For one to one: • Office 0. . 1 • Account 0. . 1 • Employee 1. . 1 0. . 1 Employee 1. . 1 Customer 1. . 1 Pay Rate 56

Examples For one to many : • Rating 0. . 1 • Father 0. . 1 • Member 1. . 1 • Invoice 1. . 1 0. . * Movie 1. . * Son 0. . * Video Rental 1. . * Invoice Line 57

Examples For many to many : • Student 0. . * • Product 0. . * • Book 1. . * 0. . * Class 1. . * Part 1. . * Author 58

- Aggregation A Part of relationship Special form of association Aggregation (comprises) relationship. Destroying the "whole" does not destroy the parts 59

Generalization and Inheritance • A generalization is a relationship between a general thing and a more specific kind of that thing. Sometimes it is called an ''is a kind of'' relationship. • Each subclass inherit the feature of its superclass • Each piece of equipment feature just once then add details for individual

What is a Component? • A non trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well defined architecture • A component may be OO Principle: – A source code component – A run time components or – An executable component Source File Name <<EXE>> Executable Name Encapsulation Component Interface <<DLL>> Component Name 61

Grouping Construct • Module – Logical construct for grouping classes, associations and generalizations. – Boundaries of a module are somewhat arbitrary. – Helps manage by breaking problems • Sheet – Big & Complex model cannot fit into single sheet of paper. – It’s a mechanism of breaking a large object model into series of pages

Lighter moments • An OO surgeon would hand the knife to the patient and say: "now perform this operation on yourself!". • The nice thing about C++ is that only your friends can handle your private parts.

End of session 2 • Session 3 : Friday 2: 00 - 5: 00 PM – Analysis – Sequence Diagram • Session 4 : Saturday 6: 30 PM onwards – Class Diagram – Design • Session 5 : Sunday 4: 00 PM onwards – Design Classes – Deployment diagram