11 topic 9 ooa
Post on 22-Dec-2014
424 Views
Preview:
DESCRIPTION
TRANSCRIPT
Lecture 14 & 15 1CS540 Software Design
Object-Oriented Paradigm
• Object-oriented paradigm– Reaction to perceived shortcomings in structured
paradigm– Problem of larger products– Data and action treated as equal partners
Lecture 14 & 15 2CS540 Software Design
Object-Oriented Analysis (OOA)• Semi-formal specification technique • Multiplicity of different methods • All essentially equivalent• Nowadays, we represent OOA using UML (unified
modeling language)
Lecture 14 & 15 3CS540 Software Design
The Three Steps of OOA• 1. Use-case modeling
– Determine how the various results are computed by the product (without regard to sequencing)
– Largely action oriented• 2. Class modeling (“object modeling”)
– Determine the classes and their attributes– Purely data-oriented
• 3. Dynamic modeling – Determine the actions performed by or to each class– Purely action-oriented
• Iterative process
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
The Object-Oriented Modeling Approach
• Benefits1. The ability to tackle more challenging problem
domains2. Improved communication among users, analysts,
designers, and programmers3. Reusability of analysis, design, and programming
results4. Increased consistency among the models developed
during object-oriented analysis, design, and programming
A.4A.4
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
The Object-Oriented Modeling Approach (continued)
• Object-Oriented Systems Development Life Cycle– Process of progressively developing
representation of a system component (or object) through the phases of analysis, design, and implementation
– The model is abstract in the early stages– As the model evolves, it becomes more and more
detailed
A.5A.5
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
The Object-Oriented Systems Development Life Cycle
• Analysis Phase– Model of the real-world application is developed showing
its important properties– Model specifies the functional behavior of the system
independent of implementation details• Design Phase
– Analysis model is refined and adapted to the environment• Implementation Phase
– Design is implemented using a programming language or database management system
A.6A.6
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
The Object-Oriented Systems Development Life Cycle (continued)
• Unified Modeling Language (UML)– A notation that allows the modeler to specify, visualize and
construct the artifacts of software systems, as well as business models
– Techniques and notations• Use cases• Class diagrams• State diagrams• Sequence diagrams
A.7A.7
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Use-Case Modeling• Applied to analyze functional requirements of the
system• Performed during the analysis phase to help
developers understand functional requirements of the system without regard for implementation details
• Use Case– A complete sequence of related actions initiated by an
actor• Actor
– An external entity that interacts with the system
A.8A.8
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Use-Case Modeling• Use cases represent complete functionality
of the system• Use cases may participate in relationships
with other use cases• Use cases may also use other use cases
A.9A.9
Lecture 14 & 15 11CS540 Software Design
Elevator Problem: OOA• 1. Use-Case Modeling
– Use case: Generic description of overall functionality
• Get comprehensive insight into behavior of product
Lecture 14 & 15 12CS540 Software Design
Normal Scenario
Lecture 14 & 15 13CS540 Software Design
Exception Scenario
Lecture 14 & 15 14CS540 Software Design
Use Case
• Use Case Name• Actors• Pre-Conditions• Normal Flow• Post-Conditions• Exceptions or Alternate Flows
Lecture 14 & 15 15CS540 Software Design
Class Modeling
• Extract classes and their attributes• Represent them using an entity-relationship
diagram• Deduce the classes from use cases and their
scenarios• Often there are many scenarios
– Possible danger: too many candidate classes
Lecture 14 & 15 16CS540 Software Design
Two Approaches to Class Modeling
• Noun extraction– Always works
• CRC classes– Need to have domain expertise
Lecture 14 & 15 17CS540 Software Design
Noun Extraction
• Stage 1. Concise Problem Definition– Define product in single sentence
• Buttons in elevators and on the floors control the motion of n elevators in a building with m floors.
Lecture 14 & 15 18CS540 Software Design
Noun Extraction (contd)
• Stage 2. Informal Strategy– Incorporate constraints, express result in a
single paragraph • Buttons in elevators and on the floors control
movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.
Lecture 14 & 15 19CS540 Software Design
Noun Extraction (contd)• Stage 3. Formalize the Strategy
– Identify nouns in informal strategy. Use nouns as candidate classes
• Nouns– button, elevator, floor, movement, building, illumination,
door – floor, building, door are outside problem boundary —
exclude– movement and illumination are abstract nouns — exclude
(may become attributes)• Candidate classes: Elevator and Button • Subclasses: Elevator Button and Floor Button
Lecture 14 & 15 20CS540 Software Design
First Iteration of Class Diagram
• Problem– Buttons do not communicate directly with elevators– We need an additional class: Elevator Controller
Lecture 14 & 15 21CS540 Software Design
Second Iteration of Class Diagram
• All relationships are now 1-to-n – Makes design and
implementation easier
Lecture 14 & 15 22CS540 Software Design
CRC Cards• Class Responsibility Collaboration (CRC)• Used since 1989 for OOA• For each class, fill in card showing
– Name of class– Functionality (responsibility)– List of classes it invokes (collaboration)– Now automated (CASE tool component)
• Strength– When acted out by team members, powerful tool for
highlighting missing or incorrect items• Weakness
– Domain expertise is needed
Lecture 14 & 15 23CS540 Software Design
3. Dynamic Modeling
• Produce UML state diagram
• State, event, predicate distributed over state diagram
• UML “guards” are in brackets
Lecture 14 & 15 24CS540 Software Design
Testing during the OOA Phase• CRC cards are an excellent testing technique
Lecture 14 & 15 25CS540 Software Design
CRC Cards• Consider responsibility
– 1. Turn on elevator button
• Totally unacceptable for object-oriented paradigm
• Responsibility-driven design ignored• Information hiding ignored• Responsibility
1. Turn on elevator button
should be1. Send message to Elevator Button to turn itself on
Lecture 14 & 15 26CS540 Software Design
CRC Cards (contd)
• A class has been overlooked– Elevator doors have a state that changes during
execution (class characteristic)– Add class Elevator Doors– Safety considerations
• Reconsider class model• Then reconsider dynamic model, use-case
model
Lecture 14 & 15 27CS540 Software Design
Second Iteration of CRC Card
Lecture 14 & 15 28CS540 Software Design
Third Iteration of Class Diagram
Lecture 14 & 15 29CS540 Software Design
Second Iteration of Normal Scenario
Lecture 14 & 15 30CS540 Software Design
Elevator Problem: OOA (contd)
• All three models are now fine• We should rather say:
– All three models are fine for now• We may need to return to the object-
oriented analysis phase during the object-oriented design phase
Lecture 14 & 15 31CS540 Software Design
Why Is All This Iteration Needed?• Perhaps the method is not yet mature?
– Waterfall model (explicit feedback loops)– Rapid prototyping model (aim: to reduce iteration)– Incremental model, and– Spiral model
• Latter two explicitly reflect iterative approach• Iteration is an intrinsic property of all software
production– Especially for medium- and large-scale products– Expect iteration in the object-oriented paradigm
10.32Figure 10.5 An example of a state diagram
10.33
Use case diagramsA use-case diagram gives the user’s view of a system: it shows how users communicate with the system. A use-case diagram uses four components: system, use cases, actors and relationships. A system, shown by a rectangle, performs a function.
Figure 10.6 An example of use case diagram
10.34
Class diagramsThe next step in analysis is to create a class diagram for the system. For example, we can create a class diagram for our old-style elevator. To do so, we need to think about the entities involved in the system.
Figure 10.7 An example of a class diagram
10.35
State chartAfter the class diagram is finalized, a state chart can be prepared for each class in the class diagram. A state chart in object-oriented analysis plays the same role as the state diagram in procedure-oriented analysis.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Object Modeling:Class Diagrams
• Object– An entity that has a well-defined role in the application domain, and
has state, behavior, and identity• State
– A condition that encompasses an object’s properties and the values those properties have
• Behavior– A manner that represents how an object acts and reacts
• Object Class– A set of objects that share a common structure and a common
behavior
A.36A.36
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Object Modeling:Class Diagrams (continued)
• Class Diagram– Class is represented as a rectangle with three
compartments– Objects can participate in relationships with
objects of the same class
A.37A.37
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Object Modeling:Object Diagrams
• Object Diagram– A graph of instances that are compatible with a given class diagram;
also called an instance diagram– Object is represented as a rectangle with two compartments
• Operation– A function or service that is provided by all the instances of a class
• Encapsulation– The technique of hiding the internal implementation details of an
object from its external view
A.38A.38
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.39A.39
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Representing Associations• Association
– A relationship between object classes– Degree may be unary, binary, ternary or higher– Depicted as a solid line between participating classes
• Association Role– The end of an association where it connects to a class– Each role has multiplicity, which indicates how many
objects participate in a given association relationship
A.40A.40
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.41A.41
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Representing Generalization
• Generalization– Abstraction of common features among multiple classes,
as well as their relationships, into a more general class
• Subclass– A class that has been generalized
• Superclass– A class that is composed of several generalized subclasses
A.42A.42
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Representing Generalization (continued)
• Discriminator– Shows which property of an object class is being
abstracted by a generalization relationship• Inheritance
– A property that a subclass inherits the features from its superclass
• Abstract Class– A class that has no direct instances but whose descendents
may have direct instances• Concrete Class
– A class that can have direct instances
A.43A.43
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.44A.44
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Representing Aggregation
• Aggregation– A part-of relationship between a component
object and an aggregate object– Example: Personal computer
• Composed of CPU, Monitor, Keyboard, etc.
A.45A.45
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Dynamic Modeling:State Diagrams
• State– A condition during the life of an object during which it satisfies some
conditions, performs some actions or waits for some events– Shown as a rectangle with rounded corners
• State Transition– The changes in the attributes of an object or in the links an object has
with other objects– Shown as a solid arrow– Diagrammed with a guard condition and action
• Event– Something that takes place at a certain point in time
A.46A.46
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.47A.47
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Dynamic Modeling:Sequence Diagrams
• Sequence Diagram– A depiction of the interaction among objects during
certain periods of time
• Activation– The time period during which an object performs an
operation
• Messages– Means by which objects communicate with each other
A.48A.48
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Dynamic Modeling:Sequence Diagrams (continued)
• Synchronous Message– A type of message in which the caller has to wait
for the receiving object to finish executing the called operation before it can resume execution itself
• Simple Message– A message that transfers control from the sender
to the recipient without describing the details of the communication
A.49A.49
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.50A.50
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Moving to Design
• Start with existing set of analysis model• Progressively add technical details• Design model must be more detailed than
analysis model• Component Diagram
– A diagram that shows the software components or modules and their dependencies
• Deployment Diagram– A diagram that shows how the software components,
processes and objects are deployed into the physical architecture of the system
A.51A.51
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
A.52A.52
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Summary
• Object-Oriented Modeling Approach– Benefits– Unified Modeling Language
• Use cases• Class diagrams• State diagrams• Sequence diagrams
• Use Case Modeling
A.53A.53
EXAMPLE 2
55
USE CASE:
How do we find the use cases?
• What functions will the actor want from the system?• Does the system store information? What actors will create, read, update.
Or delete that information?• Does the system need to notify an actor about changes in its internal
state?
56
USE CASE:
• Generic format for documenting the use case:
- Pre condition: If any– Use case : Name of the case.– Actors : List of actors(external agents), indicating who
initiates the use case.– Purpose : Intention of the use case.– Overview : Description.– Type : primary / secondary.– Post condition: If any
• Typical Course of Events:
ACTOR ACTION : Numbered actions of the actor.
SYSTEM RESPONSE : Numbered description of system responses.
57
USE CASE:
USE CASE documentation example:• The following use case describes the process of opening a new account in
the bank. Use case :Open new account
Actors :Customer, Cashier, Manager
Purpose :Like to have new saving account.
Description :A customer arrives in the bank to open the new
account. Customer requests for the new account
form, fill the same and submits, along with the
minimal deposit. At the end of complete successful
process customer receives the passbook.
Type :Primary use case.
58
Grouping USE CASES:
• Those use case functionality which are directly dependent on the system environment are placed in interface objects
• Those functionality dealing with storage and handling of information are placed in entity objects
• Functionality's specific to one or few use cases and not naturally placed in any of the other objects are placed in control objects
By performing this division we obtain a structure which helps us to understand the system from logical view
59
OOAD --- USE CASE driven
Capture,clarify& validate use cases
Analysis Design &Implementation
Implement use cases
Use cases make up the glue
Test
Verify that use cases are satisfied
60
SYSTEM BOUNDARY:
What is System Boundary?
• It is shown as a rectangle. • It helps to identify what is external verses internal, and what the
responsibilities of the system are. • The external environment is represented only by actors.
61
RELATIONSHIP:
What is Relationship?
• Relationship between use case and actor. Communicates
• Relationship between two use cases Extends Uses
• Notation used to show the relationships:
<< >>
62
RELATIONSHIP:
• Relationship between use case and actor is often referred as “communicates” .
• Relationship between two use cases is refereed as either uses or extends.
USES: • - Multiple use cases share a piece of same functionality.• - This functionality is placed in a separate use case rather than
documenting in every use case that needs it.
63
RELATIONSHIP:
Contd...• A uses relationship shows behavior that is common to one or
more use cases.
EXTENDS:• It is used to show optional behavior, which is required only
under certain condition.
64
USE CASE diagram:
Use case diagram for the shown functionality.
Balance status report
Withdraw cash
Validation
uses
CustomerClerk
Manager
extends
ATM
65
Objective
• To understand and capture the detailed specification of a system to be developed, from user perspective.
66
Beginning Analysis and Design
• Completion of first version of use case diagram initiates the processes of analysis and design.
• UML provides the framework to carry out the process of analysis and design in form of set of diagrams.
• Every diagram and notation used in the diagram carries the semantics.• First step towards analysis and design is to specify the flow of events.
67
Flow of Events:
• A flow of events document is created for each use case.• Details about what the system must provide to the actor when the use is
executed.• Typical contents
– How the use case starts and ends– Normal flow of events– Alternate flow of events– Exceptional flow of events
• Typical Course of Events has:
Actor Action(AA)
System Response(SR)
68
Normal Flow of Events:
For withdrawal of cash:• 1.(SR) The ATM asks the user to insert a card.• 2.(AA) The user inserts a cash card.• 3.(SR) The ATM accepts the card and reads its serial number.• 4.(SR) The ATM requests the password.• 5.(AA) The user enters 1234.• 6.(SR) The ATM verifies the serial number and password with the
bank and gets the notification accordingly.• 7.(SA)The ATM asks the user to select the kind of transaction.• 8.(AA)User selects the withdrawal.
69
Normal Flow of Events:
Contd...• 9.(SR)The ATM asks for the amount of cash; user enters Rs. 2500/-• 10.(SR)The ATM verifies that the amount of cash is within predefined
policy limits and asks the bank, to process the transaction which eventually confirms success and returns the new account balance.
• 11.(SR) The ATM dispenses cash and asks the user to take it.• 12.(AA) The user takes the cash.• 13.(SR) The ATM asks whether the user wants to continue.• 14.(AA) The user indicates no.
70
Normal Flow of Events:
Contd...• 15.(SR) The ATM prints a receipt, ejects the card and asks the user to take
them• 16.(AA) The user takes the receipt and the card.• 17.(SR) The ATM asks a user to insert a card.
71
Alternative Flow of Events:
For withdrawal of cash use case:• 9. The ATM asks for the amount of cash; the user has change of mind and
hits the “cancel”.
72
Exceptional Flow of Events:
For withdrawal of cash use case:• 3 Suspicious pattern of usage on the card.• 10 The machine is out of cash.• 11 Money gets stuck in the machine.
73
Why flow of events?
• It helps in understanding the functionality of a system to be developed.• Flow of events helps in finding objects of the system to be developed.• Happens to be most important and very first step towards analysis and
design.
74
What is Scenario?
• The functionality of the use case is captured in flow of the
events.• A scenarios is one path through the flow of events for the use
case.• Scenarios are developed to help identify objects, classes and
object interactions for that use case.
75
USE CASE Realizations:
• The use case diagram presents an outside view of the system• Interaction diagrams describe how use cases are realized as interactions
among societies of objects.• Two types of interaction diagrams
– Sequence diagrams– Collaboration diagrams
76
What is Interaction diagram?
• Interaction diagrams are models that describe how groups of objects collaborate in some behavior
• There are 2 kinds of interaction diagrams • Sequence diagram• Collaboration diagram
• Sequence diagrams are a temporal representation of objects and their interactions
• Collaboration diagrams are spatial representation of objects, links and interrelations
77
What is sequence diagram?
• Typically these diagrams capture behaviors of the single scenario.• Shows object interaction arranged in time sequence.• They show sequence of messages among the objects.• It has two dimensions, vertical represents time & horizontal • represents objects.• Components of sequence diagram:
-objects
-object lifeline
-Message
-pre/post conditions.
78
OBJECT & OBJECT LIFE LINE:
•Object are represented by rectangles and name of the objects are underlined.•Object life line are denoted as dashed lines. They are used to model the existence of objects over time.
Name:Class
79
MESSAGES:
• They are used to model the content of communication between objects. They are used to convey information between objects and enable objects to request services of other objects.
• The message instance has a sender, receiver, and possibly other information according to the characteristics of the request.
• Messages are denoted as labeled horizontal arrows between life lines.
• The sender will send the message and receiver will receive the message.
80
MESSAGES:
Contd…• May have square brackets containing a guard conditions. This is a Boolean
condition that must be satisfied to enable the message to be sent.• May have have an asterisk followed by square brackets containing an
iteration specification. This specifies the number of times the message is sent.
• May have return list consisting of a comma -separated list of names that designate the values of returned by the operation.
• Must have a name or identifier string that represents the message.• May have parentheses containing an argument list consisting of a comma
separated list of actual parameters passed to a method.
81
:Customer :ATM :BankRequest password
Verify accountEnter the password
Account o.k.Request option
Enter option
Request amount
Enter the amountUpdate transactionTransaction commit
Insert card
Dispense cashRequest take cash
Take cashRequest continuation
TerminatePrint receipt ,eject card
Request take cardTake card
Display main screen and prompt for the card.
:TransactionCreate Transaction
Transaction complete
Sequence diagram [for withdrawal of cash, normal flow]
82
What is Collaboration diagram?
• Collaboration diagrams illustrate the interaction between the objects, using static spatial structure.
• Unlike sequence diagram the time is not explicitly represented in these diagrams
• In collaboration diagram the sequence of messages is indicated by numbering the messages. The UML uses the decimal numbering scheme.
• In these diagrams, an actor can be displayed in order to represent the triggering of interaction by an element external to the system.
• This helps in representing the interaction, without going into the details of user interface.
83
Components of collaboration diagram:
• Named objects• Links: Links are represented by a continuous line between objects, and
indicates the exchange of messages.• Messages has following attributes:
• Synchronization --thread name, step within thread.• Sequence number• Message labels : The name of the message often corresponds to an operation
defined in the class of the object that is the destination of the message. Message names may have the arguments and return values.
• *[iteration].• It uses decimal notation.• Message direction.
84
Semantics of components:
• Object names identify which objects are participating and the links show which objects collaborate
• A link between two objects must exist for one object to send message to another and vice a versa.
• Messages in the collaboration diagram get transformed to more detailed signature.
• They use the decimal notation system for numbering the messages.• The direction of the message defines the sender and receiver of the
message
85
The elements of message:
• Predecessor• Role names• Message qualifiers
– Iteration expression– Parameters– Return values– Guard– Message stereotypes
• Concurrent thread sequencing• Thread dependencies• Message expression
[Pre] A1:*(expression):doIt(p,r):return value
86
The examples of message:
4:Display(x,y) Simplemessage
3.3.1:Display(x,y) Nestedmessage
4.2:subtract[Today,Birthday]:age Nestedmessage withreturn value
[Age >=18] 6.2:Vote() Conditionalmessage
4.a,b.6/c.1:Turnon(Lamp) Synchro. withother flow ofexecution
1*:wash() Iteration
3.a,3.b/4*||[i:=1..n]:Turnoff() Paralleliteration
87
Collaboration diagram [for withdrawal of cash, normal flow.]
1. Insert cardEnter password, Enter kindEnter amount,Take cash, Take cardcancel,Terminate, Continue
Display main screen unreadable card message,request password,request kind, request amount,canceled message, eject card, failure message,dispense cash, request take cashrequest continuation,print receipt, request take cardbad account message,bad bank account message
Verify account,process transaction
Transaction succeedTransaction failedaccount o.k.bad account,bad password,bad bank code
Create TransactionTransaction completeCUST-
OMER
BANK
ATMTRANSA-CTION
88
Objective of the fifth module
• To know the interaction among the objects in temporal and spatial form. • To know how objects collaborate among each other and hence delegate
the responsibility to the respective objects.• To understand how the messages get matured with more information.
89
Module-5
90
What is Class diagram?
• A class diagram shows the existence of classes and their relationships in the logical view of a system
• UML modeling elements in class diagrams are:– Classes, their structure and behavior.– relationships components among the classes like association,
aggregation, composition, dependency and inheritance– Multiplicity and navigation indicators– Role names or labels.
91
Major Types of classes:
Concrete classes• A concrete class is a class that is instantiable; that is it can have different
instances.• Only concrete classes may be leaf classes in the inheritance tree.Abstract classes• An abstract class is a class that has no direct instance but whose
descendants classes have direct instances.• An abstract class can define the protocol for an operation without
supplying a corresponding method we call this as an abstract operation.• An abstract operation defines the form of operation, for which each
concrete subclass should provide its own implementation.
10.93
10-3 DESIGN PHASE
The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase, all components of the system are defined.
10.94
Procedure-oriented design
In procedure-oriented design we have both procedures and data to design. We discuss a category of design methods that concentrate on procedures. In procedure-oriented design, the whole system is divided into a set of procedures or modules.
10.95
Structure chartsA common tool for illustrating the relations between modules in procedure-oriented design is a structure chart. For example, the elevator system whose state diagram is shown in the previous slides can be designed as a set of modules shown in the structure chart below
A structure chart
10.96
ModularityModularity means breaking a large project into smaller parts that can be understood and handled easily. In other words, modularity means dividing a large task into small tasks that can communicate with each other. The structure chart discussed in the previous section shows the modularity in the elevator system. There are two main concerns when a system is divided into modules: coupling and cohesion.
Coupling is a measure of how tightly two modules are bound to each other.
Coupling between modules in a software systemmust be minimized.
i
10.97
Another issue in modularity is cohesion. Cohesion is a measure of how closely the modules in a system are related. We need to have maximum possible cohesion between modules in a software system.
Cohesion between modules in a software systemmust be maximized.
i
10.98
Object-oriented design
In object-oriented design the design phase continues by elaborating the details of classes. As we mentioned in Chapter 9, a class is made of a set of variables (attributes) and a set of methods. The object-oriented design phase lists details of these attributes and methods. Figure 10.9 shows an example of the details of our four classes used in the design of the old-style elevator.
Figure 10.9 An example of classes with attributes and methods
top related