overview of object oriented · overview of object oriented… oo systems designer provides detail...
TRANSCRIPT
Overview of Object Oriented Concepts Bridge between users’ requirements and new
system’s programming
Object-oriented design is process by which detailed object-oriented models are built.
Programmers use design to write code and test new system
Overview of Object Oriented… User interface, network, controls, security, and
database require design tasks and models
Set of objects that cooperate to accomplish result
Object contains program logic and necessary attributes in a single unit
Objects send each other messages and collaborate to support functions of main program
Overview of Object Oriented… OO systems designer provides detail for programmers
A system is viewed as a collection of entities that interact with each other.
Key Concepts:
Abstraction: selective examination of certain aspects of the problem while ignoring the remaining aspects of the problem.
Encapsulation: the property of an object by which it interface with the outside world only through messages.
Overview of Object Oriented… Key Concepts…
Polymorphism: capability to
Genericity: Generic classes and function.
Basic Mechanism:
Objects: represents a tangible real world entity.
Class: collection of similar objects
Methods and messages: operations supported by an object are called methods. The methods of an objects are invoked by sending message to it.
Overview of Object Oriented… Inheritance: this feature allows us to define a new class
by extending or modifying the existing classes.
Advantages of OOD:
Code and design reuse.
Increased productivity.
Ease of testing and maintenance.
Better code and design understandability.
Steps in OOD Review of objects identified in the analysis phase.
Refine the objects in terms of their attributes.
Specification of class dependency.
Analysis of relationship among the classes. Major relationships are:
Inheritance relationship: is_a
Containment relationship: use of an object of a class as a member of another class. has_a
Steps in… Use relationship :
A reads a member of B.
A calls a member of C.
A creates B using new operator.
Organization of class hierarchies.
Create a class hierarchy so that we can reuse as much data/function as possible.
Identify the common attributes and function among the group of related classes and then combining them to form a new class.
Steps in … Design of classes.
Concentrate on the complete details that each class represents.
In addition to the service function a class must have the following functions:
Class management functions: Constructors and destructors.
Class implementation functions: operations performed on the data type of the class.
Class access functions
Class utility functions: exception handling.
Steps in … Other issues:
Access control for the base class Virtual functions/base classes Library classes Design of individual classes.
Guide lines: Public part should contain only functions of the class. Functions should be declared public only when it is required to be
used by the objects of the class. A class should be dependent on as few other classes as possible. Each subordinate class should be designed as a specialization of the
base class with sole purpose of adding additional features. The top class should represent the abstract model of the target
concept.
Steps in … Design of member functions:
Top down functional decomposition technique.
Design of driver program.
The main() function.
Resposibilities:
Receiving data values from the user.
Creating objects from class definitions.
Arranging communication among the objects.
Displaying output results.
Modeling Modeling is a way of thinking about the problems
using models organized around the real world ideas.
A modeling method comprises a language and also a
procedure for using the language to construct models.
modeling is the only way to visualize your design and
check it against requirements before your crew starts
to code.
What is UML Several different notations for describing object-
oriented designs were proposed in the 1980s and 1990s
The Unified Modeling Language is an integration of these notations
It describes notations for a number of different models that may be produced during OO analysis and design
It is now a de facto standard for OO modelling
What is UML.. • Is a language. It is not simply a notation for drawing
diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.
• Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.
• It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).
UML Diagrams: Nine different diagrams to capture diferent views.
UML diagrams can capture the following views of the system:
User’s View:
Defines the functionalities available to the users by the system.
Black-box view.
Central view-all other views must conform with this view.
Structural view:
Static model
Defines the objects important to the understanding of the working of the system.
Captures relationships among the objects
Behavioural View:
Captures object interaction
Implementation View:
Important components of the system and their dependencies
Environmental View:
How diferent components are implemented on diferent hardware
User’s View -Use Case Diagram
Structural View -Class Diagram -Object Diagram
Behavioural View -Sequence -Collaboration -State chart -Activity
Implementation View -Component Diagram
Environmental View -Deployment Diagram
Use case model describes what the user expects the system to do
functional requirements
may describe only the functionalities that are visible to the user requirements view
consists of use case diagrams and textual descriptions
C-S 546 21
Elements of a Use Case diagram
C-S 546 22
actor
Use case
Use case
Use case Use case
generalization
dependency
dependency
System
actor
Definitions System
a black box that describes the system or subsystem that is modeled
example: ATM system, account verification subsystem
represented optionally as a rectangle in the use case diagram, but generally not shown
Actor a role played by an external entity that interacts with
the system
One object may play multiple roles in a context in which case there will be multiple actors example: bank manager as a customer
C-S 546 23
Definitions (continued) Primary actor
an actor who initiates the major, main or important use cases in the system
example : a customer in a banking system
Secondary actor an actor who is involved with one or more use cases but
does not initiate the use cases
example : database
The concepts of primary and secondary actors will be useful in ranking the roles played by the actors
C-S 546 24
Definitions (continued) Generalization between actors
one actor can be a specialization of another actor
based on the same concept as the specialization relationship between classes
example : preferred customer in a bank is a specialization of a customer
C-S 546 25
Definitions (continued) Use case
an important functionality to be implemented and is visible to the actors
an interacting behavior between an actor and the system
Must yield an observable result to the actor
example: “deposit” in a banking system
C-S 546 26
Definitions (continued) Association
an interaction between an actor and a use case
represented by an arrow between an actor and a use case
unidirectional associations must be represented by arrows direction of arrow indicate information flow
bi-directional associations can be represented by double-sided arrows or straight lines
C-S 546 27
Definitions (continued) Generalization between use cases
based on the same concept as generalization between classes; uses the same symbol
one use case can be designated as a specialization of another use case
example: “withdraw with overdraft protection” is a specialization of “withdraw”
C-S 546 28
Definitions (continued) “include” dependency
one use case may include another use case
if use case A includes a use case B, B must be implemented in order to implement A
based on the same concept as modular programming
represented as a dashed arrow from A to B with a label “<<include>>”
example : “withdraw” includes “update account”
C-S 546 29
Definitions (continued) “extend” dependency
one use case may be extended by another use case if use case A is extended by a use case B, then both A
and B can be independently implemented and used A will occasionally use B depending on some constraints
based on the same concept as modular programming represented as a dashed arrow from B to A with a
label “<<extend>>” Notice that the arrow is reversed
example : “withdraw” is extended by “check for privileged customer”
C-S 546 30
Use case Packaging When too many use cases are present at the top level
then we can package the related use cases so that as most 6-7 packages are present at the top level.
Accounts
Query balance
Receive grant
Make payment
Print balance sheet
Constraints in a Use Case model every use case must be connected to an actor or be
included in another use case or extends another use case
every use case connected to an actor must return an observable result to the actor
may be data or confirmation of termination of an action
C-S 546 33
How to find actors? those that interact with the system (provide input,
observe results, provide control information, …) primary actors
those that are used by the system but external to the system secondary actors such as data stores
information about actors can be found in the problem description
generally, users of the system are primary actors
C-S 546 34
How to find use cases? Every requirement is a use case
Every functionality that supports the implementation of a requirement is a use case
design issue
found when the first (abstract) use case model is refined to express a design
C-S 546 35
How to find use case relationships? extracted from the application domain
must be justifiable from the application domain or from the designer’s choice
examples “withdraw” includes “update account” is justifiable from
application domain
“withdraw” is extended by “withdraw with overdraft protection” is a designer’s choice designer can always implement two different versions of
withdrawals
C-S 546 36
Case Study - ATM Model only the transactions
Customer accounts assumed to exist Opening and closing of accounts is handled by another
portion of the system
Include operations “deposit”, withdraw”, “check balance”, “transfer”
If balance is zero or less than the amount to be withdrawn, then withdrawal should fail
C-S 546 37
Tic-Tac-Toe
Play Move
Tic-tac-toe Game
Player
CLASS DIAGRAMS: Represents static behaviour of the system.
Main constituents are classes and their relationships such as generalization, aggregation, association etc.
Representation of class: Solid outline rectangles with compartment.
Mandatory name compartment.
Name starts with an uppercase.
Library Member
Member Name Membership Number Books Issued . .
issueBook(); returnBook(); . .
Attributes name can be folllowed by square brackets, indicating the number of attributes per instances of the class. Eg. Marks[3]
Marks[3]:Float
X:int=0
X=0
issueBook(in bookname):Boolean
Associations and Links Connection between classes.
Relation between two objects are called links.
Links are instances of objects.
Library Member Book 1 * borrowed by
Amit C++ borrowed by 1 *
Usually associations are binary relations.
A class can have association with itself.
Association is represented by drawing a line.
Name of the association is written along the side of the line.
Arrowhead represents the reading directions.
Multiplicity represents how many instances of one classes are associated with other.
Aggregation: Special type of association where the involved classes
represent a whole part relationship.
If an instance of one object contains the instances of the other objects then aggregation relation ship exist between them.
Not reflexive, transitive.
Document Paragraph Line
1 * 1 *
Composition: Stricter form of aggregation.
The parts are existence dependent on the whole.
Life time of each part is tied closely with the life of the whole.
Order Item * 1
Inheritance: Represented by arrow pointing from subclass to super
class.
The combine arrow emphasize the collectivity of the of the subclass.
The set of subclasses of a class having same discriminator is called partition.
Library Boook
Reference Book Set
Reference Single Volume
Book
Issuable Book Set
Issuable Single Volume
Book
Issuable Reference
Dependency: A form of association between two classes which
shows that change in the independent class requires changes in the dependent class.
Dependent Class Independent Class - - - - - - - - - - - - - ->
Constraints Conditions or integrity rule.
Permissible set of values etc.
Enclosed within braces.
Object Diagrams Snapshot of the marks.
(Library Member)
Amit Jain Csm07003 . .
issueBook(); . .