CIS 231 Software Engineering

1
CIS 231Software Engineering
Objects Object Orientation characteristics ide
ntity abstraction classification encapsulati
on inheritance polymorphism persistence
2
CIS 231Software Engineering
Identity data are organized into discrete,
distinguishable entities called objects a
single object has states and behaviors associated
with it. Each object in an OO system usually has
a name associated with it, also called a
reference or handle that distinguishes one
object from another Abstraction is essential
for building systems whether we use OO or
not. Classification group object with common
attributes or behaviors. Each object is an
instance of a class. each object has its own
attribute values but shares attribute names and
behaviors with other members of the
class. Encapsulation a class encapsulates and
objects behaviors and attributes, hiding
the details of the implementation.
3
CIS 231Software Engineering
We can organize classes hierarchically according
to shared properties. This defines the classes
inheritance structure Subclasses inherit the
properties of their superclass Sometimes we
define an abstract class to simplify the
heirarchy no objects of the abstract class can
be defined. A behavior is an action or
transformation that an object performs ,
usually triggered by receipt of some
message. This behavior may be exhibited
differently on different classes or subclasses,
a property called polymorphism. Persistence
ability of an objects name, state, and behaviors
to transcend time. the objects values are saved
as the object is transformed.
4
Figure 6.1 Examples of objects grouped into
classes.
5
Figure 6.2 Box representing and objects name,
attributes and behaviors.
6
Figure 6.3 forming a hierarchy.
7
Figure 6.4 Relationship of testing types to OO
structure (adapted from Jacobson et al. 1996).
8
CIS 231 Software Engineering
The OO development process One advantage of OO
development is its consistency of language. We
can describe both the problem and the solution in
the same terms. At the next higher level,
describing class using OO requires three
perspectives static dynamic restrictive
9
CIS 231 Software Engineering
Static View include descriptions of the
objects, attributes, behaviors, and
relationships. Dynamic View describe
communications, control/ timing, states and state
changes Restrictions describe constraints on
the structure and the dynamic behavior We will
apply this OO technique to the gas station
problem discussed in the text. A description of
the station requirements is contained in sidebar
6.1 on pages 287-8 Note that requirements are
independent of the way the system is
represented. When using OO development, the OO
problem description is the same as or is similar
to the first steps in finding a solution. Once
the program design is done, the system is
described at a very low level, using models
of objects, attributes, and behaviors. Coding
proceeds by translating the models to an OO
programming language.
10
Use cases To develop a system using object
oriented programming it is useful to describe
requirements with a system known as use
cases A use case describes a particular
functionality that a system is supposed to
perform or exhibit by modeling the dialog that a
user, external system, or other entity will have
with the system We describe some activity
involving the system. The use case describes a
possible scenario of how the external entity
interacts with the system Often presented as a
drawing of objects involved along with a brief
text description. referred to as the scenario
script Useful for describing the functions of
the system to customers, designers, and testers.
11
CIS 231 Software Engineering

Use case diagrams have four elements actors
the role an entity plays with respect to the
system. case a description of some aspect of
the system functionality that is visible to the
actor whose perspective is reflected by the use
case. extension extends a use case to
illustrate a different perspective use a
reuse of an already-defined use case.
12
CIS 231 Software Engineering
We consider the design of the previously
mentioned gas station. A high level view is
shown in figure 6.5 The service station performs
three types of service to the customer and bills
him. We can extend this use case diagram by
adding new elements figure 6.6 We have added
a new actor station manager and a new service
preventive maintenance Then we extend the
case to reflect that some people will pay with
credit cards. figure 6.7
13
Figure 6.5 Overview of Royal Service Station.
14
Figure 6.6 First extension of Royal Service
Station diagram to include preventive maintenance.
15
Figure 6.7 Second extension of Royal Service
Station diagram to include credit card system.
16
CIS 231 Software Engineering
Finally we extend the system to include all
participants to do that, we look for all
entities in the environment, that means external
to our system. but those that interact with the
system to accomplish a task. These entities can
be human other systems external
organizations external devices. We look at
what the participant does and where in the
systems process the task is accomplished Some
participants initiate events while other
interact with the system as a result of
events. These participants are a role, not a
specific person.example customer not John
Smith or Jane Doe
17
CIS 231 Software Engineering
We can use a set of questions to help us identify
participants. What users or groups use the
system to perform a task? What users or groups
are needed so that the system can perform its
functions. What external systems use the
system What external systems, user, or groups
send info to the system What external systems,
users, or groups Using these questions, we
have, in figure 6.8 included a printer to
print bills fuel ordering system parts
ordering system we added two subsystems as
well accounting to deal with taxes inventory
control. These use cases help us understand or
systems better and perhaps find errors or
omissions in translating the requirements.
18
CIS 231 Software Engineering
Once we define the use cases, we can examine the
asking the following kinds of questions Do the
use cases use the right terminology. are there
two or more terms which describe the same
entity? Do the activities match the
perspectives. is it consistent with the
description Are the descriptions of activities
and participants clear and complete. is there
more than one way to interpret a
descripton. Is there an interaction described
that is missing it complementary participant
description Is there an external system or set
of users described but not actually involved in
an activity or interaction with the system Is
it clear when each activity starts and
ends. Examining these use cases helps us better
understand the system boundaries what is in the
system .. what is outside the
system. what interacts with the
system what is completely separate.
19
Figure 6.8 Third extension of Royal Service
Station diagram to include inventory and
accounting.
20
CIS 231 Software Engineering
UML Universal Modeling Language a notational
approach that is popular for describing OO
solutions. We will look at using UML to produce
a high level design for our service station. In
the requirements process, workflow diagrams
define the entire business process by
describing the activities that the system will
perform. Use cases also describe the system and
the various scenarios we can supplement these
with object models that describe classes of
objects in terms of their functions. The design
process begins with UML state and activity
diagrams. Activity diagrams display all the
activities that can occur in the system as value
of an object change. Different inputs may
produce different activities or types of
results. State diagrams show all possible states
an object can take. The design continues by
addressing the static structure of objects using
structure and object diagrams.
21
CIS 231 Software Engineering
Interactions among classes are illustrated
using sequence diagrams show how messages
flow from one object to another collaboration
diagrams use object and sequence information to
show the flow of events between
objects. Finally the design can be implemented
using package diagrams show how classes are
logically divided into modules. component
diagrams often same as packages but they
reflect the actual final system
modules deployment diagrams show the network
links involved with the application being
built.
22
Requirements
Design
Coding
UML use case descriptions and diagrams
STATES
Object models
CLASS STRUCTURE
Requirements Specifications
Workflow diagrams
INTERACTIONS
Class definitions and relationships
Figure 6.9 How UML supports the development
process.
23
CIS 231 Software Engineering
For our service station, we use the requirements
in sidebar 6.1 We start with UML class diagrams,
these diagrams describe the object types and
their static relationships We want to depict
associations among objects. and illustrate the
attributes of each object, their behaviors and
restrictions. We start with the statement of
requirements and try to identify nouns that
identify items that suggest our first cut at
object classes. We seek structures external
systems devices roles operating
procedures places organizations things that
are manipulated by the system being designed.
24
CIS 231 Software Engineering
Referring to the text on page 301. we might
identify personal check paper bill credit
card customer station manager purchase fuel s
ervices discounts tax parking maintenance cas
h prices The following questions can act as
guidelines for what can or should be included in
a list of candidate classes What needs to be
processed in some way what items have multiple
attributes when do you have more than one
object in a class what is based on the
requirements themselves, not derived from your
understanding of the requirements what
attributes and operations are always applicable
to a class or object. We can use these questions
to group the candidate classes as shown in table
6.2
25
CIS 231 Software Engineering
We can examine other requirements and see how our
analysis changes. page 302 refer to tables 6.2
and 6.3 For the full set of requirements we
refer to table 6.4 The next step in the process
is to identify behaviors that must be included in
our design. We again refer to the requirements
and extract verbs we look for items that
suggest behaviors. imperative verbs passive
verbs actions things or reminded
events roles operating procedures services
provided by an organization These behaviors will
become actions taken by a class or object.
example billing a customer
26
CIS 231 Software Engineering
Figure 6.10 shows a UML box used to illustrate
the components of a class. the upper third of
the box has the class name the middle third
contains the attribute info the bottom third has
the operation descriptions. Each attribute is
described by its name type initial
value Each Operation can be described
by name argument list return type
27
Figure 6.10 Class box representing a bill.
28
CIS 231 Software Engineering
The UML boxes are placed on a page to represent
the relationship of the classes they
represent. When one box is above another,
connected by an arrow, then the upper box is a
superclass of the lower box as in figure
6.11 As you know this inheritance relationship
allows the lower box to inherit the attributes of
the upper. Relationships usually consist of
four types generalization association aggreg
ation composition The superclass generalizes
the subclass Two classes are associated when
they occur together and when the relationship
must be preserved for some period of
time. Association is indicated by a straight
line, the numbers at each end show the
cardinality of each member. Aggregagtion. one
class is part of another. for example an ordered
item is part of an order. indicated using a line
ending with a filled diamond. an unfilled
diamond indicates an aggregation that is not an
inheritance relationship. refer to figure 6.12
29
Figure 6.11 Inheritance relationship.
30
Figure 6.12 Association of classes.
31
Figure 6.13 Types of class relationships.
32
CIS 231 Software Engineering
UML includes other ways of associating classes
with one another notes about a particular
class qualifiers Figure 6.14
33
Figure 6.14 Additional UML notation for notes
and qualifiers.
34
CIS 231 Software Engineering
Using these notations, we can take a first cut at
our service station. Figure 6.15 has 15
boxes We can improve our design by adding a
message class to send notices and letters We
note the fuel class should be connected to the
inventory class since we must track fuel on
hand to know when to order more. We can
simplify the design by eliminating the account
class. we recognize that this class had only
one attribute, we can improve our design by
eliminating account and adding the account number
attribute to the customer class.
35
Figure 6.15 First cut at Royal Service Station
design.
36
Figure 6.16 Second cut at Royal Service Station
design.
37
Figure 6.17 Third and final cut at Royal Service
Station design.
38
CIS 231 Software Engineering
Other UML Diagrams To supplement our systems
design, we need a variety of other
diagrams. Each class must be described in more
detail using a class description
template Template tells us us the position of
the class ( in terms of depth of inheritance) in
the overall heirarchy, the export controls, the
cardinality, and associations with other
classes. It also specifies the operations in the
class and the public interface to the class.
39
CIS 231 Software Engineering
Example class description template for the
refuel class in our design Class name
refuel category service External
documents Export control Public Cardinality
n Hierarchy Superclasses
service Associations fuel in association
name Operation name price Public member of
refuel Documentation // calculates fuel final
price Preconditions gallons gt 0 Object
diagram unspecified Semantics final_price
gallons price Object Diagram
unspecified Concurrency sequential Public
Interface Operations price Private
Interface Attributes gallons price Impl
ementations Attributes gallons price St
ate Machine no Concurrency sequential Persist
ence transient
40
CIS 231 Software Engineering
UML also includes package diagrams These allow
us to view the system as a small collection of
packages which can then be expanded to a larger
set of classes Package diagram is shown on the
next slide. The services package is expanded to
shown the classes therein. Dashed arrows show
the package dependencies.
41
Figure 6.18 Package diagram for the Royal
Service Station.
42
CIS 231 Software Engineering
UML includes Interaction Diagrams Used to
describe how operations and behaviors are handled
by objects in the design We would usually
generate one interaction diagram from each USE
case to identify the messages and operations that
represent the systems overall
functionality. Two types of interaction
diagrams sequence diagram figure 6.19 Show
the sequence in which activities occurs An
object is depicted as a box at the top of a
vertical line, known as the objects lifeline. A
narrow box on the lifeline indicates the start or
end of the message. An arrow between two
lifelines represents a message between the two
objects It is labeled with the messages name
and sometimes with the condition that must be met
for the message to be sent. An asterisk on the
arrow indicates that the message is sent many
times, to several different receiving
objects When the arrow loops back to its
starting box on the same object, the object is
sending to itself called self delegation.
43
Service Station
Purchase
Refuel
Customer
refuel ( )
verify customer (credit_card_ num, amount)
pay_by_cash ( )
cancel credit card transaction
new_purchase (customer, refuel, date, gallons)
new_refuel (customer, date, gallons)
Figure 6.19 Sequence diagram for the refuel use
case.
44
CIS 231 Software Engineering
A collaboration diagram also based on a use
case shows how objects are connected
statically Objects are icons and arrows are
used to depict messages Unlike sequence
diagrams, the sequence of messages is indicated
by a number system Figure 6.20 shows the
parking use case. appears to be an error.
45
Figure 6.20 Collaboration diagram for the
parking use case.
46
CIS 231 Software Engineering
UML allows us to capture dynamic behavior using
state diagrams and activity diagrams Our
previous descriptions were static in
nature. Figures 6.21, 22, and 23 indicate state
diagrams of various processes. The black circle
indicates the starting points White circle with
a black dot in the middle indicates an end
node. These diagrams allow us to graphically
illustrate actions or event that cause changes in
the system. We might also use activity
diagrams as indicated in figures 6.24 and 25. We
can indicate when decisions need to be made.
47
Figure 6.21 State diagram example.
48
amount of fuel lt minimum
amount of fuel gt minimum
Low stock
Normal stock
delivery of new fuel
number of parts gt minimum
amount of parts lt minimum
Low stock
delivery of new parts
Figure 6.22 State diagram for fuel and parts
classes.
49
Figure 6.23 State diagrams for inventory class.
50
Figure 6.24 Activity diagram notation.
51
Figure 6.25 Activity diagram for inventory class.
52
CIS 231 Software Engineering
OO Program design Once we have identified the
objects and classes for our system, we must
embellish and modify them to include more
items. non-functional requirements, such as
performance and I/O constraints reused
components from previous systems reusable
components intended for use in other
systems user interface requirements data
structure and management details there will
usually be more objects in the program design
than in the system design. Many of the program
designs objects are not visible to the user and
have no counterpart in the real world During
program design, we must also specify the features
of each objects interface with the rest of the
world We must name each operation, the objects
it requires as parameters and what is
returned, this is called the operation
signature. An objects interface is the
collection of all of its operation signatures.
53
CIS 231 Software Engineering
No one way of design is best for all
situations Whichever is used, we must design for
change. In addition to a flexible design
strategy, we can use toolkits a set of related
well defined reusable classes Frameworks and
patterns are also design aids a pattern is a
template of abstract architectural elements that
can be used to guide you in generating your
design. A framework is a reuse of part of a
domain specific design. It is more specialized
than a design pattern and it can incorporate
patterns in its specifications.
54
CIS 231 Software Engineering
User interface design Our program must have
some interface to the user. To design the
interface we must consider several
issues define the humans who will interact
with the system. develop scenarios for each way
the system can perform a task designing a
hierarchy of user commands refining the
sequence of user interactions with the
system designing relevant classes in the
hierarchy to implement the user interface design
decisions integrating the user interface
classes in the overall system class
hierarchy Following slide shows how we might
use existing system as a guide for creating our
interface.
55
Figure 6.26 Transition from paper to screen.
56
CIS 231 Software Engineering
If our user screen is acceptable to the customer,
we proceed with the software design. illustrated
in figure 6.27 We must also address the
ways our program design will deal with persistent
objects, we must be able to handle data. A
possible design shown in figure 6.28
57
Figure 6.27 Possible design for new billing
screen.
58
Figure 6.28 Implementing the classes using a
relational database.
59
CIS 231 Software Engineering
Task Management design is a critical part of the
process of program design A task refers to a
process in the system, it can be event driven or
time driven We can design task management in
four steps identify the tasks to be performed
and classify them as event or time
driven determine task priorities. which takes
precedence if two occur simultaneously create
a task to coordinate all other tasks design
objects for each task, and define the
relationship among them. Each task must be
formally defined, so that programmers understand
how to implement it properly. We should
include task name description priority service
s communication mechanism place in the
heirarchy Example on next slide
60
CIS 231 Software Engineering
Task Name order parts Description Purpose
is to order new parts automatically when there
are not enough parts already in
stock. Priority High, it must be activated
when the inventory warns that parts in stock are
low Included services verify
inventory Managed by/ Manages Service station
system Communicates by modem with the
order_parts system. In sidebar 6.3, several
patterns are described that can assist us in
deciding how to manage tasks One of these is
called the observer pattern four
parts subject knows its observers and
provides an interface for attaching and detaching
observer objects. observer main function is
to define an updating interface concrete
subject stores a state of interest to one or
more concrete observer objects concrete
observer maintains a reference to a concrete
subject.
61
observers
Figure 6.29 Relationship among abserver pattern
constructs (Gamma et al. 1995).
62
notify ( )
update ( )
getState ( )
update ( )
getState ( )
Figure 6.30 Sequence diagram for the observer
pattern (Gamma et al. 1995).
63
CIS 231 Software Engineering
The next figure shows an object oriented view of
the service station. The remainder of the
chapter is concerned with measuring the size and
complexity of our design.
64
Figure 6.31 Object-oriented view of the Royal
Service Station.
65
Figure 6.32 Class hierarchy for Royal Serivce
Station, plus Lorenz and Kidd measures.
66
1
1 ..
Figure 6.33 Chidamber-Kemerer metrics applied to
Royal Service Stations system design.
67
1 ..
0 ..
1
1 ..
1
1 ..
0
Figure 6.34 Chidamber-Kemerer metrics applied to
Royal Service Stations program design.
68
Figure 6.35 Measuring from a sequence diagram.
69
Figure 6.36 Data flow diagram as basis for use
cases for the Piccadilly system.
70
Figure 6.37 Class diagrams for the advertising
campaign.