ë ë
ë
ëë
ë
Æ
ëë
Æ
ë
OO Concepts
Ú Classes and class hierarchies
P Instances
P Inheritance
P Abstraction and hiding
Ú Objects
P Attributes
P Methods
P Encapsulation
P Polymorphism
Ú Messages
Object
method
#6
method method
#5 #4
es:
ece e obec
bues:
ope
ons:
ope ons:
message:
[sender, return value(s)]
class taxonomies
technical literature
S S reuse standards g AIN
g AIN existing applications g AIN ANALYSIS
KN Lg ANALYSIS functional models gL
customer surveys
domain languages
expert advice
current/future requirements
Domain Analysis Activities (1)
Ú Define the domain to be investigated.
P Isolate the business area, system type, product category
P Extract both OO and non-OO items.
ż OO-items such as: application and support (GUI, DB) classes,
Commercial off-the-shelf (COTS) component libraries and test
cases.
ż Non-OO items such as: policies, procedures, plans, standards
and guidelines; parts of existing non-OO applications, metrics
and COTS non-OO software.
Ú Categorize the items extracted from the domain.
P Organize items into categories.
P Define the general defining characteristics of the
categories.
P Propose a classification scheme for the categories.
P Define naming conventions for each item.
P Establish classification hierarchy when appropriate.
Domain Analysis Activities (2)
Ú Collect a representative sample of applications in
the domain.
P Ensure that the application has items that fit into
categories.
Ú Analyze each application in the sample.
P Identify candidate reusable objects.
P Indicate the reasons that the object has been identified for
reuse.
P Define adaptions to the object that may also be reusable.
P Estimate the percentage of applications in the domain that
make reuse of the object.
P Identify the object by name and use configuration
management techniques to control them (chapter 9).
Ú Develop an analysis model for the objects.
P As a basis for design and construction of domain objects.
OOA- A èeneric View
Ú define use cases
Ú extract candidate classes
Ú establish basic class relationships
Ú define a class hierarchy
Ú identify attributes for each class
Ú specify methods that service the attributes
Ú indicate how classes/objects are related
Ú build a behavioral model
Ú iterate on the first five steps
¦ e OOA Process
Ú The OOA process begins with an
understanding of the manner in which the
system will be used by:
P People, if the system is human-interactive.
P Machines, if the system is involved in process
control.
P Programs, if the system coordinates and controls
applications
Ú Once the scenario of usage has been defined,
the modeling of the software begins.
Ú A series of techniques may be used to gather
basic customer requirements.
Use Cases
OOD
Ú OOD transforms the analysis model created using
OOA into a design model that serves as a
blueprint for software construction.
Ú OOD results in a design that achieves a number of
different levels of modularity.
Ú Subsystems: Major system components.
Ú Objects: Data and the operations.
Ú îour important software design concepts:
P Abstraction
P Information Hiding
P îunctional Independence
P Modularity
OOD
Ú ¦ esubsysemëaye
:
Representation of each of the
subsystems that enable the
software to achieve its customer
defined requirements.
ess ag e
U se cases des ign
C la ss an d o e ct
ect-B eh avio r
des ign
M od e l
su sys te
des ign
¦ L I ML ¦ IG ML
OOA to OOD
n alysis M ood
nalys d el e sign M odel
classes o ects
attri u tes d ata struc tures
eth o d s alg orith s
rela tio n s hips
h ips essag in g
ing
e h a v io r co n tro l
Design ssues
Ú decomposability²the facility with which a design method
helps the designer to decompose a large problem into
subproblems that are easier to solve;
Ú composability²the degree to which a design method
ensures that program components (modules), once designed
and built, can be reused to create other systems;
Ú understandability²the ease with which a program
component can be understood without reference to other
information or other modules;
Ú continuity²the ability to make small changes in a program
and have these changes manifest themselves with
corresponding changes in just one or a very few modules;
Ú protection²a architectural characteristic that will reduce the
propagation of side affects if an error does occur in a given
module.
èeneric Components for OOD
Ú Problem domain component²the subsystems that
are responsible for implementing customer
requirements directly;
Ú Human interaction component ²the subsystems
that implement the user interface (this included
reusable GUI subsystems);
Ú Task Management Component²the subsystems
that are responsible for controlling and
coordinating concurrent tasks that may be
packaged within a subsystem or among different
subsystems;
Ú Data management component²the subsystem
that is responsible for the storage and retrieval of
objects.
Process Flow for OOD
System Design Process
Ú %a
on eanaëys smodeë nosubsysems.
Ú Iden yconcu
ency a sd caedby e
p
obëem.
Ú Aëëocaesubsysemsop
ocesso
sandasks.
Ú Deveëopades gno
euse
ne
ace.
Ú C ooseabas cs
aegyo
mpëemen ngdaa
managemen.
Ú Iden ygëobaë
esou
cesand econ
oë
mec an sms
equ
edoaccess em.
Ú Des gnanapp
op
aecon
oëmec an smo
esysem, ncëud ngaskmanagemen.
Ú Cons de
owbounda
ycond onss ouëdbe
andëed.
Ú Rev ewandcons de
ade
Rev ewandcons de
adeos.
System Design
Subsystem Example
Subsystem Design Criteria
Ú ¦ esubsysems ouëd aveaweëë
de ned ne
ace
oug w c aëë
commun ca onw e
eso e
sysemoccu
s.
Ú W eexcep onoasmaëënumbe
o
commun ca oncëasses,´ ecëasses
w nasubsysems ouëdcoëëabo
ae
onëyw o e
cëassesw n e
subsysem.
Ú ¦ enumbe
osubsysemss ouëdbe
kepsmaëë.
Ú Asubsysemcanbepa
oned
ne
naëëyo eëp
educecompëex y.
Subsystem Collaboration
¦able
Object Design
Ú A ô ô
establishes the
interface of an object by defining each
message that the object can receive and
the related operation that the object
performs
Ú An ô
ô
shows
implementation details for each operation
implied by a message that is passed to an
object.
P information about the object's private part
P internal details about the data structures that
describe the object¶s attributes
P procedural details that describe operations
Design Patterns
Ú add some example