Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Object Oriented
Modeling
A Concept Tutorial
The need
• Corporations are becoming
information based
organizations
• Volume of information is
expanding faster than the
...
Reasons for the Crisis
• Complexity
– requirements are demanding and of contradictory nature
• functionality
• usability
•...
Divide and Rule!
• “The technique of mastering complexity is known since ancient
times: Divide and Rule”
….Dijkstra
Solutions
• Building better Software is a major
challenge!!
• ModularProgramming
Modularization of Procedures and data
– M...
…Solutions
- Modularization of data:
-each subroutine can contain its own data
-data can be stored in external files
-data...
Algorithmic/ Functional Decomposition
• Define the how and what of the goal
• Specifying and decomposing the system functi...
Object Oriented Decomposition
• Decomposing a system into objects, the basic components and
design
• managing complexity i...
The Object Oriented
Approach
• Three keys to the OOtechnology:
– Objects
– Messages
– Classes
Objects
• Software package that contains a
collection of related Procedures and
Data
– Procedures : Methods
– Data element...
Classes
• There may be many objects of a
given type - extremely inefficient to
redefine the same methods in every single
o...
Classes VS. Objects
Class Object
Class is a type/ template
for similar objects
Object is an instance of
the class
Class is...
Classes VS. Objects
Example
class EMPLOYEE // EMPLOYEE is a class
{
char name[30];
void putname(char*n);
void prinname();
...
An Analogy
• Cells are ( organic)
“packages” , like Objects,
that combine information
(data) and behavior
-Encapsulation!!...
Objects as Abstract
Data Types
• OO technology supports data
abstraction.
• An abstract data type consists of a new
class ...
OO Themes
Major themes •Abstraction
•Encapsulation
•Hierarchy/ Inheritance
•Polymorphism
•Modularity
Minor themes •Typing
...
Abstraction
An abstraction denotes the essential characteristics of an object
that distinguishes it from other kinds of ob...
..Abstraction
• EMPLOYEE
Human Resources
System
Payroll System
Name
Designation
Qualification
Skills
.
.
.
Name
Salary
HRA...
Encapsulation
• Promotes hiding of information
- Objects do not “touch” each other’s data
• Facilitates Changes
- Effects ...
Encapsulation
• Act of grouping into a single object - both data and operations
that affect the data
• Apportions complexi...
Accessing Objects-Messages
• Interactions between Objects
- Message from a sender
object asks the receiver
object to execu...
STEP 1:
• Sender ( e.g. client) requests a service by sending “message”
• Message does not specify how the operation is to...
Messages
• Objects interact through messages
• A message has three parts;
{Receiver} { Method} {Parameter}
The response to...
Types of interfaces
• Private:
A declaration that forms a part of the interface of a class and is not
visible to other cla...
Inheritance
• A mechanism by which one class
of objects can be defined as a
special case of a more general
class
– Supercl...
Hierarchy
• Classes can be nested to any
degree, inheritance will
automatically accumulate down
through all the levels
of ...
..Inheritance
• When a class Y inherits from class X:
– X is the base or Super class
– Y is the derived or Sub class
• Y c...
Classes
• Classes allow a programmer to
organize complex systems in a
rational, orderly way.
• When an instance ( object)
...
Class Hierarchies
• An object will search its
Superclass for methods
and variables
• This leads to efficient packaging
of ...
..Inheritance
Example:
Define a class describing polygons:
• Attributes - vertices
• Operation - translation, rotation, di...
..Inheritance
• If we need a new class representing Rectangle, we can derive it
from the class representing Polygon
Common...
..Inheritance
Pseudo- code forrectangle:
class Rectangle inherits Polygon
{
redefines perimeter() from Polygon
and
has fea...
Polymorphism
• Hiding Alternative procedures behind
a common interface is called
Polymorphism
• e.g. The name “DRAW” can b...
.. Polymorphism
• The function “ DRAW” is declared in the base class Polygon
• The function can be redefined in derived cl...
Goals that guide Class Hierarchies
• Build general purpose classes for reuse
• make change easier
• correctly reflect the ...
Modularity
A modularsystemis a system decomposed into a set
of cohesive and loosely decoupled modules
Example:
Insurance P...
Typing
• Typing is enforcement such that objects of different
types may not be interchanged, or, at most may be
interchang...
Persistence
• This is a property by virtue of which
– object continues to exist afterits creatorceases
to exist
Promise of the OO Approach
• Conventional software
– solves a specific problem
– is built from scratch
• Object Oriented s...
Industrialization of
Software
• A striking parallel exists
between the OO approach and
the Industrial revolution-
– Handcr...
Unified Development Process
(UDP)
• UDPis a method of managing OOSoftware Development
• It can be viewed as a Software Dev...
UDP Features
• Templates forall majorartifacts, including:
– RequisitePro templates (requirements tracking)
– Word Templat...
Phases of UP
An Iterative Development Process...
• Recognizes the reality of changing requirements
– Caspers Jones’s research on 8000 p...
An Incremental Development Process...
• Allows forsoftware to evolve, not be produced in one huge effort
• Allows software...
Goals and Features of Each Iteration
• The primary goal of each iteration is to slowly chip away at the risk facing the
pr...
The Development Phases
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase
Inception Phase
• Overriding goal is obtaining buy-in from all interested parties
• Initial requirements capture
• Cost Be...
Elaboration Phase
• Requirements Analysis and Capture
– Use Case Analysis
• Use Case (80% written and reviewed by end of p...
Construction Phase
• Focus is on implementation of the design:
– cumulative increase in functionality
– greater depth of i...
Transition Phase
• The transition phase consists of the transferof the system to the user
community
• It includes manufact...
Elaboration Phase in Detail
• Use Case Analysis
– Find and understand 80% of architecturally significant use cases
and act...
Modeling with UML
What is UML?
Modeling involves
• understanding ( semantics) a subject (system)
and
• capturing and communicating this know...
..What is UML?
• UML is the standard language for visualizing, specifying,
constructing, and documenting the artifacts of ...
Evolution of the UML
• Unification
– Jim Rumbaugh, Grady Booch and Ivar Jacobson joined Rational
Software Corporation to u...
Standardization
• More companies joined the UML partner’s consortium to
contribute their ideas and produce version 1.1 of ...
History of the UML
Nov ‘97 UML approved by the OMG
Scope of UML
• Fusing concepts of Booch, OMT and OOSE.
• Focusing on a standard modeling language (common notation
and sem...
– The UML enables and promotes a use-case-
driven, architecture-centric, iterative, and
incremental process that is object...
The UML Definition
• Defined by a set of documents
– UML Semantics
– UML Notation Guide
The UML Semantics Document
• Constitutes the single, common, formal and comprehensive
specification of the UML (inside vie...
The UML Notation Guide
• Constitutes the notational or visual representation of the UML
and provides examples (o utside vi...
Model Views and UML Diagrams
•Use Case
UserView
Behavioral View
•Sequence
•Collaboration
•State Chart
•Activity
Structural...
UML Diagrams
• Class diagram
For a view of the static structure of the system
• UseCase diagram
For High level business sc...
Library Management System- A Case Study
The Library has:
• three categories of members
• a librarian and assisting staff
•...
..Class Diagram
• Shows the static structure of the system - classes and their
relationships
• Classes
– structure (attrib...
4
5
Class Diagram Notation
Class
Class with a compartment
Realizes Interface
Interface
Constraint
N-ary Association
Binary...
Library
Book
no
VisibilityAttribute TypeScopeInitVal
Title a
Author a
Publisher a
Subject a
Keywords a
edition a
Price a
C...
Relationships
• An association is a bi-directional connection between classes
– An association is shown as a line connecti...
Relationships - contd..
• An association class is an association that also has class properties(or a
class has association...
Association
Teacher
Navigation
Aggregation
Student
Guide RS
1 Guides *
Teacher
DepartmentInstitute
1 *
Composition
Page Frame
1 *
Page Frame
1 *
Page Frame
1 *
Window
Header SliderMenu
Dependency
Window Button
uses
SalaryEmployee
access
Association Classes
CourseTeacher
Offering
No of students
Venue
Slot number
1 Teaches *
Company Employee
Job
Designation
S...
Constraint
CommitteeFaculty
* Member of *
1 Head of *
{ subset }
Realization
AccountImpl
<interface>
Iaccount
Deposit()
wi...
Qualifier
Bank
Customer
Account #
*
*
Factory
Itemproduced
Item #
*
1
…Use Case Diagram
• Represent the interaction between users and the
system
• Identifies users (roles) and external systems...
Use Case Diagram Notation
Actor
Association
Use Case
Use case with Extension points
<<Uses>>
<<Extends>>
Use Case Diagram
..State Chart Diagram
A state chart (transition) diagramis used to show
– The life history of a given class, UseCase, oper...
State Chart Diagram Notation
Interaction Diagram
• Interaction diagrams describe how use cases are realized as
interactions among objects
• Show classe...
..Sequence Diagram
• Is used to elaborate a use case
• Describes a scenario - it is normal that a use case has multiple
sc...
Sequence Diagram Notation
Actor
Class
Synchronous message
Asynchronous message
Return message
Focus of Control
lifeline
Te...
Sequence Diagram
Library
member UI Member Book Copy
..Collaboration Diagram
• describes interactions among Classes ( objects)
• can be drawn instead of a sequence diagram
• M...
Collaboration Diagram Notation
Class
Messages with
sequence
numbers
( “Collaborates
with Class”)
Actor
Collaboration Diagram
State Chart Diagram
..Activity Diagram
Activity diagrams are similar to State Chart diagrams.
However they describe the behavior of a Class in...
Activity Diagram Notation
Activity Diagram
..Component Diagram
• Describe organization and dependency between the software
implementation components
• Components are...
Component
Dependency
Component Diagram Notation
Component Diagram
..Deployment Diagram
• Describe the configuration of processing resource elements and
the mapping of software implementati...
Deployment Diagram Notation
Component
Interface
Dependency
Node
Connector
Deployment Diagram
LibClient2
ClientLibrarian
LibClient1
LibServer
LibMgmtSys
ClientMember
tcp-ip tcp-ip
…Package Diagram
A Package is :
• an application view
• exploded into a set of modules
• linked to the diagrams that model...
Package Diagram Notation
Container package
Package
Dependency
Generalization
Package Diagram
How to perform Modeling Process?
• Break up the system into packages. Draw a high level Package
Diagram for the system.
• ...
.. Modeling Process
• Draw a Class Diagram for each package
– classes will be shared across the entire application model
–...
..Modeling Process
Draw
• State Chart Diagrams or Activity Diagrams for classes that exhibit a
significantly dynamic behav...
Overview of Modeling Process
Application Package Diagram
Component Diagram
Deployment Diagram
Use Case Diagram
Sequence Di...
Use Case Template
• Overview
• Actors
• Stimulus
• Pre and Post Conditions
• Normal Flow
• Logic
• Alternate flow(s)
• Exc...
Use Case Analysis
• What is a Use Case?
– A sequence of actions a system performs that yields a valuable
result for a part...
What’s in a Use Case?
• Define the start state and any preconditions that accompany it
• Define when the Use Case starts
•...
Use Cases Describe Function not Form
• Use Cases describe WHAT the system should do, but never
HOW it will be done
• Use c...
Benefits of Use Cases
• Use cases are the primary vehicle for requirements capture in UP
• Use cases are described using t...
Difficulties with Use Cases
• As functional decompositions, it is often difficult to make the transition from
functional d...
Use Case Model Survey
• The Use Case Model Survey is to illustrate, in graphical form, the
universe of Use Cases that the ...
Sample Use Case Model Survey
Analysis Model
• In Analysis, we analyze and refine the requirements described in the Use Cases in order to
achieve a more...
Why spend time on the Analysis Model, why not just “face the
cliff”?
• By performing analysis, designers can inexpensively...
Boundary Classes
• Boundary classes are used in the Analysis Model to model interactions between the system
and its actors...
Entity Classes
• Entity classes are used within the Analysis Model to model
persistent information
• Often, entity classes...
Upcoming SlideShare
Loading in …5
×

8 oo approach&uml-23_feb

647 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

8 oo approach&uml-23_feb

  1. 1. Object Oriented Modeling A Concept Tutorial
  2. 2. The need • Corporations are becoming information based organizations • Volume of information is expanding faster than the capacity to process it • Where does the fault lie? – Computers are faster and more powerful than ever before! • The Software Crisis!!
  3. 3. Reasons for the Crisis • Complexity – requirements are demanding and of contradictory nature • functionality • usability • cost • reliability • performance • longevity – requirements change during development – problem domains can be complex – Managing the development process is not easy – impedance mismatch between user and developer
  4. 4. Divide and Rule! • “The technique of mastering complexity is known since ancient times: Divide and Rule” ….Dijkstra
  5. 5. Solutions • Building better Software is a major challenge!! • ModularProgramming Modularization of Procedures and data – Modularization of procedures – Subroutines – Structured Programming - Functional decomposition- componentization – Computer Aided Software Engineering ( CASE)
  6. 6. …Solutions - Modularization of data: -each subroutine can contain its own data -data can be stored in external files -database management systems ( DBMSs) – Hierarchic model - tree structures – network model - data interconnected freely, no tree structure necessary – relational model - data stored in simple tables Clearly a new approach must be considered!
  7. 7. Algorithmic/ Functional Decomposition • Define the how and what of the goal • Specifying and decomposing the system functionality • Decompose each task into smaller tasks - ( subroutines… language statements) • Implement the program and the steps that decompose each function Risk: Seems like the most direct way of doing things, but resulting system may be fragile, requirements change may necessitate massive restructuring
  8. 8. Object Oriented Decomposition • Decomposing a system into objects, the basic components and design • managing complexity inherent in the real world problem by abstractions ( of knowledge) and encapsulation (of information and behavior) within objects
  9. 9. The Object Oriented Approach • Three keys to the OOtechnology: – Objects – Messages – Classes
  10. 10. Objects • Software package that contains a collection of related Procedures and Data – Procedures : Methods – Data elements : Variables - Ideal Modules: Objects can be defined and maintained independently E.g. Vehicle - Everything an Object” knows” is expressed in its variables and everything it can “ do” is expressed in its methods- Encapsulation Methods Variables ( DATA MEMBERS)
  11. 11. Classes • There may be many objects of a given type - extremely inefficient to redefine the same methods in every single occurrence of that object • A Class is a Template that defines methods and variables to be included in a particular type of object • Objects that belong to a Class are Instances of the Class Class Methods Variables (Data members) Values
  12. 12. Classes VS. Objects Class Object Class is a type/ template for similar objects Object is an instance of the class Class is purely a static concept, represented by program text Objects are run time / dynamic entities that occupy space in memory
  13. 13. Classes VS. Objects Example class EMPLOYEE // EMPLOYEE is a class { char name[30]; void putname(char*n); void prinname(); } main() { EMPLOYEE emp; // emp is an object emp.putname(“myname”; emp.printname(); }
  14. 14. An Analogy • Cells are ( organic) “packages” , like Objects, that combine information (data) and behavior -Encapsulation!! • Cells, like Objects communicate through Messages( chemical). • Cells are (natural) building blocks- organized in a Hierarchy of specialized types and subtypes Nucleus Membrane Mitochondria( Energy Converters) Endoplasmic Reticulum (Protein Factory)
  15. 15. Objects as Abstract Data Types • OO technology supports data abstraction. • An abstract data type consists of a new class assembled from built in data types, such as numbers and characters Abstract Data Type Built in Data Types
  16. 16. OO Themes Major themes •Abstraction •Encapsulation •Hierarchy/ Inheritance •Polymorphism •Modularity Minor themes •Typing •Persistence OO modeling involves consideration of these themes.
  17. 17. Abstraction An abstraction denotes the essential characteristics of an object that distinguishes it from other kinds of objects. • Note essential details • ignore irrelevant details to manage complexity
  18. 18. ..Abstraction • EMPLOYEE Human Resources System Payroll System Name Designation Qualification Skills . . . Name Salary HRA Conveyance . . .
  19. 19. Encapsulation • Promotes hiding of information - Objects do not “touch” each other’s data • Facilitates Changes - Effects of change are limited to a few classes CAPACITY LOAD LIFT LOAD CONTENTS MoveTo UNLOAD
  20. 20. Encapsulation • Act of grouping into a single object - both data and operations that affect the data • Apportions complexity of the system to individual , pertinent objects • Knowledge encapsulated within an object is “hidden” from an external view • An object has a public interface and a private representation
  21. 21. Accessing Objects-Messages • Interactions between Objects - Message from a sender object asks the receiver object to execute its method. Authors of Simula offered this solution • Typical Structure: – Object Name - Method- Parameter • Example ; “Receiver-MoveTo- Destination” RECEIVER MoveTo LOAD LIFT SIZE SPEED CAPACITY CONTENTS SENDER “Receiver MoveTo Destination”
  22. 22. STEP 1: • Sender ( e.g. client) requests a service by sending “message” • Message does not specify how the operation is to be performed STEP 2: • Receiver ( e.g. server) responds by executing a “method” • Optionally sends some information back to the sender Accessing Objects-Messages
  23. 23. Messages • Objects interact through messages • A message has three parts; {Receiver} { Method} {Parameter} The response to a message is called a Return value TOTAL SENDER RECEIVER Purchase order100 Rs. 1 crore “Rs. 1 crore” “ Purchase order_ 100 TOTAL”
  24. 24. Types of interfaces • Private: A declaration that forms a part of the interface of a class and is not visible to other classes • Public: A declaration that forms a part of the interface of a class and is visible to clients
  25. 25. Inheritance • A mechanism by which one class of objects can be defined as a special case of a more general class – Superclass - subclasses • A subclass inherits all the methods and variables of its superclass Subclass- Motor Superclass- Auto Part Subclass- Chassis
  26. 26. Hierarchy • Classes can be nested to any degree, inheritance will automatically accumulate down through all the levels of the tree structure Connector …. Auto Part Motor Chassis Stepping motor Drive motor Variable speed Drive motor Fixed speed Drive motor …. . . . . . .
  27. 27. ..Inheritance • When a class Y inherits from class X: – X is the base or Super class – Y is the derived or Sub class • Y contains – The part derived from X – new code specific to Y
  28. 28. Classes • Classes allow a programmer to organize complex systems in a rational, orderly way. • When an instance ( object) receives a message, it refers to its Class for its methods and variable types and then applies these to its own unique set of values Look up method and variable definition in the Class DRAW DRAW DRAWTOOL DRAWTOO104L TRIANGL E “DRAWTOOL104 DRAW:TRIANGLE” Use values contained in the instance
  29. 29. Class Hierarchies • An object will search its Superclass for methods and variables • This leads to efficient packaging of information. “A PRINT” INSTANCE” Not here Not here Found it!!
  30. 30. ..Inheritance Example: Define a class describing polygons: • Attributes - vertices • Operation - translation, rotation, display, computation of perimeter
  31. 31. ..Inheritance • If we need a new class representing Rectangle, we can derive it from the class representing Polygon Common features Special features Translation, rotation, display Number of vertices, angle between sides, special formula to compute perimeter
  32. 32. ..Inheritance Pseudo- code forrectangle: class Rectangle inherits Polygon { redefines perimeter() from Polygon and has features specific to Rectangle }
  33. 33. Polymorphism • Hiding Alternative procedures behind a common interface is called Polymorphism • e.g. The name “DRAW” can be used for all the variations of the method- such as “DRAW CIRCLE” and “DRAW RECTANGLE”. DRAW DRAW DRAW “SHAPE DRAW” A DRAWmethod in multiple objects:
  34. 34. .. Polymorphism • The function “ DRAW” is declared in the base class Polygon • The function can be redefined in derived classes to describe specific action/ operation to be performed • Same function name DRAW is used in all the derived classes • The version of DRAW function to be used is decided during runtime by the object
  35. 35. Goals that guide Class Hierarchies • Build general purpose classes for reuse • make change easier • correctly reflect the real world system • TO BUILD SOLID WORKING MODELS
  36. 36. Modularity A modularsystemis a system decomposed into a set of cohesive and loosely decoupled modules Example: Insurance Policy, claim processing, accounts, scheme builder
  37. 37. Typing • Typing is enforcement such that objects of different types may not be interchanged, or, at most may be interchanged only in very restricted ways • Strongly typed languages require type checking of all arguments • Static type checking occurs at compile time • Dynamic type checking occurs at execution time • Strong typing avoids run time errors • Type declarations serve as program documentation
  38. 38. Persistence • This is a property by virtue of which – object continues to exist afterits creatorceases to exist
  39. 39. Promise of the OO Approach • Conventional software – solves a specific problem – is built from scratch • Object Oriented software – models a system – is built by assembly. • modeling has many advantages. – understandability – flexibility – Longevity
  40. 40. Industrialization of Software • A striking parallel exists between the OO approach and the Industrial revolution- – Handcrafting ---> Mass Production - Paradigm shift!! • The goal is Industrial revolution forSoftware • The success depend on development of reusable, standard objects. • The Challenge lies in getting the Classes right. A Class manufacturing instances
  41. 41. Unified Development Process (UDP) • UDPis a method of managing OOSoftware Development • It can be viewed as a Software Development Frameworkwhich is extensible and have features to do the following: – Iterative Development – Requirements Management – Component-Based Architectural Vision – Visual Modeling of Systems – Quality Management – Change Control Management
  42. 42. UDP Features • Templates forall majorartifacts, including: – RequisitePro templates (requirements tracking) – Word Templates forUse Cases – Project Templates forProject Management • Process Manuals describing key processes • Online Repository of Process Information and Description
  43. 43. Phases of UP
  44. 44. An Iterative Development Process... • Recognizes the reality of changing requirements – Caspers Jones’s research on 8000 projects • 40% of final requirements arrived afterthe analysis phase, after development had already begun • Promotes early riskmitigation, by breaking down the systeminto mini-projects and focusing on the riskierelements first • Allows you to “plan a little, design a little, and code a little” • Encourages all participants, including testers, integrators, and technical writers to be involved earlieron • Allows the process itself to modulate with each iteration, allowing you to correct errors soonerand put into practice lessons learned in the prioriteration • Focuses on component architectures, not final big bang deployments
  45. 45. An Incremental Development Process... • Allows forsoftware to evolve, not be produced in one huge effort • Allows software to improve, by giving enough time to the evolutionary process itself • Forces attention on stability, foronly a stable foundation can support multiple additions • Allows the system(a small subset of it) to actually run much soonerthan with otherprocesses • Allows interimprogress to continue through the stubbing of functionality • Allows forthe management of risk, by exposing problems earlieron in the development process
  46. 46. Goals and Features of Each Iteration • The primary goal of each iteration is to slowly chip away at the risk facing the project, namely: – performance risks – integration risks (different vendors, tools, etc.) – conceptual risks (ferret out analysis and design flaws) • Perform a “miniwaterfall” project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctives • Each iteration is risk-driven • The result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach
  47. 47. The Development Phases • Inception Phase • Elaboration Phase • Construction Phase • Transition Phase
  48. 48. Inception Phase • Overriding goal is obtaining buy-in from all interested parties • Initial requirements capture • Cost Benefit Analysis • Initial RiskAnalysis • Project scope definition • Defining a candidate architecture • Development of a disposable prototype • Initial Use Case Model (10% - 20% complete) • First pass at a Domain Model
  49. 49. Elaboration Phase • Requirements Analysis and Capture – Use Case Analysis • Use Case (80% written and reviewed by end of phase) • Use Case Model (80% done) • Scenarios – Sequence and Collaboration Diagrams – Class, Activity, Component, State Diagrams – Glossary (so users and developers can speakcommon vocabulary) – Domain Model • to understand the problem: the system’s requirements as they exist within the context of the problemdomain – RiskAssessment Plan revised – Architecture Document
  50. 50. Construction Phase • Focus is on implementation of the design: – cumulative increase in functionality – greater depth of implementation (stubs fleshed out) – greater stability begins to appear – implement all details, not only those of central architectural value – analysis continues, but design and coding predominate
  51. 51. Transition Phase • The transition phase consists of the transferof the system to the user community • It includes manufacturing, shipping, installation, training, technical support and maintenance • Development team begins to shrink • Control is moved to maintenance team • Alpha, Beta, and final releases • Software updates • Integration with existing systems (legacy, existing versions, etc.)
  52. 52. Elaboration Phase in Detail • Use Case Analysis – Find and understand 80% of architecturally significant use cases and actors – Prototype User Interfaces – Prioritize Use Cases within the Use Case Model – Detail the architecturally significant Use Cases (write and review them) • Prepare Domain Model of architecturally significant classes, and identify their responsibilities and central interfaces (View of Participating Classes)
  53. 53. Modeling with UML
  54. 54. What is UML? Modeling involves • understanding ( semantics) a subject (system) and • capturing and communicating this knowledge The Unified Modeling Language ( UML) is: • A complete language for capturing knowledge (semantics) about a subject (system) and communicating the knowledge (syntax) – the result of unifying the IT industry’s best engineering practices – proposed by Booch, Rumbaugh and Jacobson-the Three Amigos
  55. 55. ..What is UML? • UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system • It can be used with all processes, throughout the development life cycle, and across different implementation technologies • Applicable to not only Software Systems but to any other type of systems
  56. 56. Evolution of the UML • Unification – Jim Rumbaugh, Grady Booch and Ivar Jacobson joined Rational Software Corporation to unify their methods. • Rumbaugh - Analysis oriented (OMT) • Booch - Design and Construction oriented • Jacobson - Use case oriented (OOSE) – Since the independent methods were evolving towards one another, continue evolution by unification. – Identify and incorporate fundamental concepts, building a meta model and a notation to describe them.
  57. 57. Standardization • More companies joined the UML partner’s consortium to contribute their ideas and produce version 1.1 of the UML with – Increased formalism – Improved structural packaging – Improved mapping of notation to semantics • UML 1.1 is accepted by OMG as a standard in fall 1997. • Current version UML 2.0
  58. 58. History of the UML Nov ‘97 UML approved by the OMG
  59. 59. Scope of UML • Fusing concepts of Booch, OMT and OOSE. • Focusing on a standard modeling language (common notation and semantics) • Incorporating the object-oriented community’s consensus on core modeling concepts. • Providing sufficient notation to address contemporary modeling issues directly and economically. • Providing extensibility mechanisms to extend UML for individual projects.
  60. 60. – The UML enables and promotes a use-case- driven, architecture-centric, iterative, and incremental process that is object oriented and component based.
  61. 61. The UML Definition • Defined by a set of documents – UML Semantics – UML Notation Guide
  62. 62. The UML Semantics Document • Constitutes the single, common, formal and comprehensive specification of the UML (inside vie w). • Primarily used by tool vendors. • Specifies the UML’s layered architecture, organization and defines modeling elements. • Enables consistent usage of the UML.
  63. 63. The UML Notation Guide • Constitutes the notational or visual representation of the UML and provides examples (o utside vie w) • Primarily used by practitioners applying the UML • Specifies UML diagrams and their modeling elements
  64. 64. Model Views and UML Diagrams •Use Case UserView Behavioral View •Sequence •Collaboration •State Chart •Activity Structural View •Class •Object Implementation View •Component Environment View •Deployment User view * Use case
  65. 65. UML Diagrams • Class diagram For a view of the static structure of the system • UseCase diagram For High level business scenarios • Sequence diagramorCollaboration diagram For detailed activities within a scenario • State chart diagramorActivity Diagram For classes with a dynamic behavior • Component diagrams For describing organization and dependencies among software components • Deployment diagrams For describing the configuration of resource elements and mapping of software implementation components on to them • Package diagram For Modules
  66. 66. Library Management System- A Case Study The Library has: • three categories of members • a librarian and assisting staff • an accounts section The Library Management System should provide the following functionality: • borrowing and returning of books • querying, reserving and recommending books • acquiring books • issuing overdue notices to members
  67. 67. ..Class Diagram • Shows the static structure of the system - classes and their relationships • Classes – structure (attributes) – behavior (operations) • Relationships – Association, aggregation, dependency, and inheritance – Multiplicity and navigation indicators – names
  68. 68. 4 5 Class Diagram Notation Class Class with a compartment Realizes Interface Interface Constraint N-ary Association Binary Association 1 2 3 4 5 6 7
  69. 69. Library Book no VisibilityAttribute TypeScopeInitVal Title a Author a Publisher a Subject a Keywords a edition a Price a CopyInLib VisibilityAttribute TypeScopeInitVal isReference a accessionNo a isIssued a copyNo a Librarian LibraryMember VisibilityAttribute TypeScopeInitVal name a memberId a Accountant OrderInfo VisibilityAttribute TypeScopeInitVal supplierId a NoOfCopies a hasBooks1 * hasCopies 1 * hasLibrarian 1 1 borrows1 0..5 hasMembers 1 0..200 orders 1 * Class Diagram
  70. 70. Relationships • An association is a bi-directional connection between classes – An association is shown as a line connecting the related classes • An aggregation is a stronger form of relationship where the relationship is between a whole and its parts – An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole • A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier • A dependency is shown as a dashed line pointing from the client to the supplier
  71. 71. Relationships - contd.. • An association class is an association that also has class properties(or a class has association properties) • A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true: otherwise, the system described by the model is invalid • An interface is a specifier for the externally visible operations of a class without specification of internal structure. An interface is formally equivalent to abstract class with no attributes and methods, only abstract operations. • A qualifier is an attribute or set of attributes whose values serve to partition the set of instances associated with an instance across an association.
  72. 72. Association Teacher Navigation Aggregation Student Guide RS 1 Guides * Teacher DepartmentInstitute 1 *
  73. 73. Composition Page Frame 1 * Page Frame 1 * Page Frame 1 * Window Header SliderMenu
  74. 74. Dependency Window Button uses SalaryEmployee access
  75. 75. Association Classes CourseTeacher Offering No of students Venue Slot number 1 Teaches * Company Employee Job Designation Salary 1 employs *
  76. 76. Constraint CommitteeFaculty * Member of * 1 Head of * { subset } Realization AccountImpl <interface> Iaccount Deposit() withdraw()
  77. 77. Qualifier Bank Customer Account # * * Factory Itemproduced Item # * 1
  78. 78. …Use Case Diagram • Represent the interaction between users and the system • Identifies users (roles) and external systems • Determines the functional scope of the package (module)
  79. 79. Use Case Diagram Notation Actor Association Use Case Use case with Extension points <<Uses>> <<Extends>>
  80. 80. Use Case Diagram
  81. 81. ..State Chart Diagram A state chart (transition) diagramis used to show – The life history of a given class, UseCase, operation – The events that cause a transition from one state to another – The actions that result from a state change State transition diagrams are created for objects with significant dynamic behavior
  82. 82. State Chart Diagram Notation
  83. 83. Interaction Diagram • Interaction diagrams describe how use cases are realized as interactions among objects • Show classes, objects, actors and messages between them to achieve the functionality of a UseCase • Two types of interaction diagrams – Sequence diagrams – Collaboration diagrams
  84. 84. ..Sequence Diagram • Is used to elaborate a use case • Describes a scenario - it is normal that a use case has multiple scenarios • Helps to describe the expected system behavior to a user • Follows an event from inception to completion of processing by the system
  85. 85. Sequence Diagram Notation Actor Class Synchronous message Asynchronous message Return message Focus of Control lifeline Termination
  86. 86. Sequence Diagram Library member UI Member Book Copy
  87. 87. ..Collaboration Diagram • describes interactions among Classes ( objects) • can be drawn instead of a sequence diagram • Message sequencing is shown using sequence numbers
  88. 88. Collaboration Diagram Notation Class Messages with sequence numbers ( “Collaborates with Class”) Actor
  89. 89. Collaboration Diagram
  90. 90. State Chart Diagram
  91. 91. ..Activity Diagram Activity diagrams are similar to State Chart diagrams. However they describe the behavior of a Class in response to internal processing. • Transitions are triggered by completion of activity • For describing behavior of Use Cases or operations
  92. 92. Activity Diagram Notation
  93. 93. Activity Diagram
  94. 94. ..Component Diagram • Describe organization and dependency between the software implementation components • Components are distributable physical units -e.g. source code, object code.
  95. 95. Component Dependency Component Diagram Notation
  96. 96. Component Diagram
  97. 97. ..Deployment Diagram • Describe the configuration of processing resource elements and the mapping of software implementation components onto them • contain components - e.g. object code, source code, and nodes - e.g. printer, database, client machine
  98. 98. Deployment Diagram Notation Component Interface Dependency Node Connector
  99. 99. Deployment Diagram LibClient2 ClientLibrarian LibClient1 LibServer LibMgmtSys ClientMember tcp-ip tcp-ip
  100. 100. …Package Diagram A Package is : • an application view • exploded into a set of modules • linked to the diagrams that model that application view
  101. 101. Package Diagram Notation Container package Package Dependency Generalization
  102. 102. Package Diagram
  103. 103. How to perform Modeling Process? • Break up the system into packages. Draw a high level Package Diagram for the system. • Draw Use Case diagrams for each package • Analyze each use case in detail - identifying variations, common use cases, scenarios of interest • Draw a Sequence /Collaboration diagram for each scenario
  104. 104. .. Modeling Process • Draw a Class Diagram for each package – classes will be shared across the entire application model – a class will be owned by a “package” - others will use it • Refine the inheritance hierarchy (this will be across the application) • Identify attributes and keys for the classes
  105. 105. ..Modeling Process Draw • State Chart Diagrams or Activity Diagrams for classes that exhibit a significantly dynamic behavior • Component Diagrams to elucidate the intercomponent dependencies • Deployment Diagrams to describe the configuration of resource elements and mapping of the software implementation components onto them
  106. 106. Overview of Modeling Process Application Package Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Collaboration Diagram Activity Diagram Class Diagram State Chart Diagram
  107. 107. Use Case Template • Overview • Actors • Stimulus • Pre and Post Conditions • Normal Flow • Logic • Alternate flow(s) • Exception(s) • Extends • Uses • Unresolved Issues • Non functional requirements • Future requirements
  108. 108. Use Case Analysis • What is a Use Case? – A sequence of actions a system performs that yields a valuable result for a particular actor. • What is an Actor? – A user or outside system that interacts with the system being designed in order to obtain some value from that interaction • Use Cases describe scenarios that describe the interaction between users of the system and the system itself. • Use Cases describe WHAT the system will do, but never HOW it will be done.
  109. 109. What’s in a Use Case? • Define the start state and any preconditions that accompany it • Define when the Use Case starts • Define the order of activity in the Main Flow of Events • Define any Alternative Flows of Events • Define any Exceptional Flows of Events • Define any Post Conditions and the end state • Mention any design issues as an appendix • Accompanying diagrams: State, Activity, Sequence Diagrams • View of Participating Objects (relevant Analysis Model Classes) • Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case
  110. 110. Use Cases Describe Function not Form • Use Cases describe WHAT the system should do, but never HOW it will be done • Use cases are Analysis products, not design products
  111. 111. Benefits of Use Cases • Use cases are the primary vehicle for requirements capture in UP • Use cases are described using the language of the customer (language of the domain which is defined in the glossary) • Use cases provide a contractual delivery process (UP is Use Case Driven) • Use cases provide an easily-understood communication mechanism • When requirements are traced, they make it difficult for requirements to fall through the cracks • Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.
  112. 112. Difficulties with Use Cases • As functional decompositions, it is often difficult to make the transition from functional description to object description to class design • Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult • Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?) • Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious
  113. 113. Use Case Model Survey • The Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver. • Each Use Case in the system appears in the Survey with a short description of its main function. – Participants: • Domain Expert • Architect • Analyst/Designer (Use Case author) • Testing Engineer
  114. 114. Sample Use Case Model Survey
  115. 115. Analysis Model • In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details • Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer • Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer: – Boundary Classes – Entity Classes – Control Classes
  116. 116. Why spend time on the Analysis Model, why not just “face the cliff”? • By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system • By providing such an abstract overview, newcomers can understand the overall architecture of the systemefficiently, froma ‘bird’s eye view’, without having to get bogged down with implementation details. • The Analysis Model is a simple abstraction of what the systemis going to do fromthe point of view of the developers. By “speaking the developer’s language”, comprehension is improved and by abstracting, simplicity is achieved
  117. 117. Boundary Classes • Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users orexternal systems) • Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.) • Boundary classes can often be abstractions of external APIs (in the case of an external systemactor) • Every boundary class must be associated with at least one actor:
  118. 118. Entity Classes • Entity classes are used within the Analysis Model to model persistent information • Often, entity classes are created from objects within the business object model or domain model

×