Software Design Methodologies - PowerPoint PPT Presentation

1 / 49
About This Presentation
Title:

Software Design Methodologies

Description:

Utility classes are collections of global variables and functions which are ... The problem Occurs when a designer misses the centralized control mechanism of ... – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 50
Provided by: fay6
Category:

less

Transcript and Presenter's Notes

Title: Software Design Methodologies


1
Software Design Methodologies
  • Dr. Mohamed Fayad, Associate Professor
  • Department of Computer Science Engineering
  • University of Nebraska, Lincoln
  • Ferguson Hall, P.O. Box 880115
  • Lincoln, NE 68588-0115
  • http//www.cse.unl.edu/fayad

2
Lesson 8 Object-Oriented Design Heuristics - 2
2
3
Lesson Objectives
  • Overview of Previous Lecture
  • Understand Classes in UML
  • Discuss the following
  • Macho Class Problem
  • Interesting Design Problems
  • Topology Which Needs Accessor Methods
  • The Common Traps of Controller Classes

3
4
Modeling Notation
Notation Again !
4
5
Objects Classes (1)
  • Real-world systems can be decomposed into
    discrete entities called objects
  • Objects represent things, concepts, or
    abstraction with definable boundaries and
    behaviors
  • An object is specific instance of a class to
    which it belongs
  • Classes have attributes and behaviors
  • Individual objects have their own specific values
    for each attribute and share the same behaviors

5
6
Objects Classes (2)
Example Objects Classes Attributes
A computer screen Screen Resolution, of
colors A window Window Size,
location IBM Company Name, location, total
revenue Joe Harris Employee Name, department,
salary
6
7
Objects Classes (3)
  • Objects with the same attributes, behaviors, and
    relationships are grouped together into classes
  • A class describes general attributes and
    behaviors for a group of objects
  • An object is a single instance of its class
    (e.g., IBM is an instance of the Company class)
  • A Class diagram is used to describe the
    attributes and behaviors of a class

7
8
Classes in UML (1)
AbstractClass
Class
ltltStereotypegtgt PackageClass Constraints
Syntax for attributes and operations AttributeCar
dinalityPackageType InitialValue
Constraints Operation(ArgumentList)ReturnType
Constraints
attribute
operation()
ltltutilitygtgt UtilityClass
ltltmetaclassgtgt MetaClass
ltltActiveClassgtgt ActiveClass
8
9
Classes in UML (2)
Class
Class
normalOperation() abstractOperation() /derivedOper
ation() classOperation() publicOperation() protec
tedOperation() -privateOperation()
normalAttribute /derivedAttribute classAttribute p
ublicAttribute protectedAttribute -privateAttribu
te
iElement
Parameterized ClassltParametergt
Parameterized Class
9
10
Classes in UML (3)
  • Related Terms Type
  • Definition Class Attributes Operations
  • A class includes the definition of potential
    constraints, tagged values, and stereotypes.
  • Notation

Class
Class
attribute1 attribute2
operation1() operation2()
Class
attribute1 attribute2
Class
operation1() operation2()
Class
Class
10
attribute1 attribute2
operation1() operation2()
11
Classes in UML (4)
ltltStereotypegtgt PackageClass PropertyValues
attribute TypeInitialValue Constraints
operation(Paramter) Constraints
  • ltlt .. gtgt stereotype
  • .. tagged values
  • separate package and class names

11
12
Classes in UML (5)
Class name
Constraint
Circle
Attribute names
Initial value
radius radiusgt0 centerpoint Point (10, 10)
Attribute type
Parameters (name type initial value)
display(0 remove() setPosition(pos
Point) setRadius(newRadius)
Operations
Class Example
12
GraphicsCircle
Package name
13
Classes in UML (6) - Metaclasses
  • In Smalltalk and CLOS, classes are simply
    objects, that is, classes can be sent messages,
    and they can include (class) attributes.
  • In C, class attributes and operations can be
    emulated by declaring them as static.
  • However, in C classes cannot be treated like
    objects. An example for a class message or a
    class operation is new, which is used to create a
    new instance of a class.
  • In Smalltalk for example
  • newObject Class new
  • anEmployee Employee new
  • Classes of class objects are called metaclasses
    and similarly to a normal class, noted with a
    stereotype ltltmetaclassgtgt

13
ltltmetaclassgtgt CustomerClass
14
Classes in UML (7) - Metaclasses
  • In UML, metaclass is a class describing itself or
    other classes.
  • In UML, class operations need not be noted within
    the metaclass they may also be contained in the
    class itself, where they are underlined in order
    to distinguish them from normal operations.

ltltmetaclassgtgt PersonClass
Person
ltltinstance ofgtgt
numInstance Integer name String birthDate
Date new(name) age() Integer
numInstance Integer new(name)
14
15
Classes in UML (8) - Parameterized Classes
  • Definition
  • A parameterized class is a template equipped with
    generic formal parameters, which can be used to
    generate common (non-parameterized) classes.
  • The generic parameters serve as placeholders for
    the actual parameters which represent classes or
    simple data types.
  • Description
  • In a parameterized class, no concrete class is
    defined, but only a template for generation of
    classes.
  • These templates are usually a type of macro
    technique which has no special function, apart
    from a text replacement.
  • In statically typed languages, parameterized
    classes are an important means for writing
    re-usable code.
  • C and Eiffel support parameterized classes.

15
16
Classes in UML (9) - Parameterized Classes
  • A class generated with the aid of a parameterized
    class is called a bound element.
  • Notation

WaitingQueueltCargt
WaitingRoom
iElement
WaitingQueue
ltltbindgtgt (Patient)
add() remove()
16
TrafficJam
ltltbindgtgt (Car)
17
Classes in UML (9) - Abstract Classes
  • Related Terms virtual class
  • Definition
  • An Abstract class is never used to generate
    object instances.
  • It is intentionally incomplete and thus forms the
    basis for further subclasses which can have
    instances.
  • Description
  • Abstract classes often represent a general term,
    a generic term for a set of concrete terms.
  • Thus a vehicle can be an abstract generic term
    for bicycle, car, truck, train, and airplane.
  • Vehicle in this case is merely an abstraction, a
    generalization.

17
18
Classes in UML (9) - Abstract Classes
  • An abstract class is always a superclass.
  • An abstract class that has no subclasses makes no
    sense. Either it is superfluous, or it lacks a
    concrete class as subclass.
  • Notation

Class abstract
Class
Class abstract
attributes Operations()
attributes Operations()
18
Class
19
Classes in UML (9) - Abstract Classes
  • Example

GeomFigure
Abstract Class
Concrete Class
19
Triangle
Circle
Rectangle
20
Classes in UML (9) - Utility Classes
  • Utility classes are collections of global
    variables and functions which are combined into a
    class.
  • The stereotype ltltutilitygtgt marks a class as a
    utility class
  • Utility classes are not true classes, but
    collection of global variables and functions
    which are, however, noted in the form of a class.
  • In OO, they are usually not needed.

ltltutilitygtgt MathFun
sin(angle) Real cos(angle) Real tan(angle)
Real cot(angle) Real
20
21
A Useful Analogy From Telephony (1)
  • When designing a telephone system for the United
    States we might suggest putting one big switch in
    Chicago and connecting every phone to it. (assume
    wire is free).
  • The obvious problem is that if anything happens
    to Chicago, the entire phone system is down.
  • We want to distribute the system intelligence
    for fault tolerance.

21
22
A Useful Analogy From Telephony (2)
  • Since we want to distribute the system
    intelligence let us propose a new phone system.
  • We will connect each phone to every other phone
    in each of other houses.
  • The obvious problem here is the complexity of the
    system is so great it prohibits us from adding a
    new phone.

22
23
A Useful Analogy From Telephony (3)
  • We clearly want to distribute the system
    intelligence for fault tolerance, but not too
    much because it will add too much complexity.
  • The same is true in OO design.
  • Fortunately for telephony system there is the
    useful number of call density to determine how
    the distribution should take place.
  • In this case, there is analogy in the domain of
    OO design.
  • This leads us to two largest problems plaguing OO
    designers the Macho Class Problem and the
    Proliferation of Classes Problem.

23
24
Comparison of Macho Class Overly Distributed
Topologies
Overly Distributed System
Macho Class
24
25
The Macho Class Problem
  • A Behavior Macho Class
  • A Data Structure Macho Class

25
26
A Behavior Macho Class
  • The problem Occurs when a designer misses the
    centralized control mechanism of action-oriented
    paradigm and attempts to capture it in a class.
  • The result is a central brain class talking via
    accessor methods (i, e. gets and sets) to a
    number of uninteresting data structures.

set_result()
class5
get_x()
Macho class
class1
get_z()
get_y()
get_q()
26
class2
class3
class4
27
A Data Structure Macho Class
  • The problem Occurs when designers are migrating a
    legacy system to an OO application.
  • The legacy system has a global data block being
    access by many of the systems functions.
  • The designers wrap the data structure in a class
    with an interface of accessor methods and then
    collect the functions into groups within
    controller classes

set_result()
get_x()
controller class5
Macho class
controller class1
get_z()
get_y()
get_q()
27
controller class3
controller class4
controller class2
28
Legacy Systems A Definition
  • Legacy Software is any preexisting software that
    must be replaced by, incorporated into, or
    interfaced with software that is currently being
    developed.
  • Legacy software is typically not OO and the use
    of legacy software on projects developing OO
    software can cause problems due to the impedance
    mismatch between different structures of the
    software.

28
29
The Accessor Method Debate (1)
  • An accessor method is any relatively standard
    small and simple method that is used to either
    get or set the value of an instance attribute
  • Synonyms Accessing Method, Accessing Operation,
    Accessor Operation.
  • Contrast with Accessor Message or Accessing
    Message
  • Accessor Message is any message used to get or
    set the value of instance attribute.

29
30
The Accessor Method Debate (2)
  • Examples from patterns discussion (e-mail) group
  • A message stated that the following class is
    dangerous since it gives away implementation
    details.
  • Another messages agreed with this premise but
    argued that they are useful, necessary, and
    therefore valid.

The Point Class
get_x() get_x() get_y() set_y()
int x int y
30
31
The Accessor Method Debate (3)
  • The point of this example is that the Point class
    does not give a way implementation details.
  • By definition a method hides the details.
  • All this Point class is stating is that it
    possess the abstraction notion of a rectangular
    coordinate system.
  • The actual implementation might be an integer
    radius and a real number theta (polar
    coordinates).
  • The get_x() method simply multiplies radius and
    the cosine of theta.

31
32
The Accessor Method Debate (4)
  • The real questions are
  • Who is getting x and y?
  • Beware of people who state that it is often
    useful to pull an object X from an object Y so
    that object Z can use it directly.
  • We ask an ATM machine to withdraw 100.00 for us,
    we dont ask it for its cash dispenser and then
    use the dispenser directly.

32
33
A Topology Which Needs Accessor Methods
  • OO models User Interfaces
  • Make OO independent of its user interface.
  • The result is use of accessor methods defined on
    the model classes by the user interface classes.
  • The topology does not advocate accessor method
    calls between the classes of the model, only
    those between the model and its user interface

OO Model
User Interface
get/set messages
33
The Model-Interface Application Topology
34
The Common Traps of Controller Classes (1)
  • There are several places in design where
    controller classes seem to provide us with
    solution to a difficult problem.
  • These include the migration of legacy systems and
    the need to hide portions of a classs public
    interface.
  • Consider the following legacy system for handling
    call processing.

34
35
The Common Traps of Controller Classes (2)
CallProcessingBlock
A Legacy Call Processing System
data1 data2 data3
Func1()
Func7()
Func3()
Func5()
Func6()
Func2()
Func4()
  • A collection of global data with separate global
    functions taking direct access.
  • To migrate this system to OO, controller classes
    seem to ease the job.

35
36
Controller Classes the Migration of Legacy
Systems (1)
  • The functions can be grouped into controller
    classes and the global data can be encapsulated
    into a class with accessor methods.
  • The problem with this design is that we have lost
    the ability to ask, I have changed the
    CallProcessing class, who need to be told?
  • This is a violation of encapsulation.

36
37
Controller Classes the Migration of Legacy
Systems (2)
The CallProcessing Class
get_data1() set_data1() get_data2() set_data2() ge
t_data3() set_data3()
CallProcessingBlock
Poor Migration
data1 data2 data3
Func1()
Func3()
Func7()
Func5()
Func2()
Func6()
37
Func4()
ContollerClass1
ContollerClass3
ContollerClass2
38
Controller Classes the Migration of Legacy
Systems (3)
CallProcessingBlock
A Better Migration
Func1()
Func3()
Func7()
Func5()
Func2()
Func6()
38
Func4()
TelephonyClass1
TelephonyClass3
TelephonyClass2
39
Controller Classes the Migration of Legacy
Systems (4)
  • A more difficult
  • But more correct solution
  • Solution is to break up the data structure,
    encapsulating each part with its related behavior.

39
40
Controller Classes Hiding Portions of Public
Interface (1)
  • Another mistaken use of controller classes occurs
    when designers of reusable frameworks need to
    address public interface issues of two or more
    product groups.
  • Consider the following design produced by
    multimedia company. This company had two product
    groups which built there products based on a
    single framework.
  • The framework captured the fact that all of the
    companys products were based on the abstract
    notion of a composition.

40
41
Controller Classes Hiding Portions of Public
Interface (2)
  • A composition was a bunch of tracks (many derived
    classes of track), each track was a bunch of
    clips (many derived classes of clip), and each
    clip was associated with some piece of media.
  • The play application needed operations P, Q, and
    R while the editor application needed operations
    X, Y, and Z.
  • How do I prevent each application from seeing the
    other classes portion of the interface?

41
42
Controller Classes Hiding Portions of Public
Interface (3)
Reuse of Entity Classes Via Controller Classes
The Composition Entity Class
X, Y, Z
gets/sets for the support of P, Q, R, X, Y, Z
P, Q, R
The Editing Controller
The Player Controller
42
The Editing Application
The Player Application
43
Controller Classes Hiding Portions of Public
Interface (4)
  • The problem with the controller class design is
    that we have now given up encapsulation in order
    to minimize access to the public interface of
    composition.
  • The following design maintains this encapsulation.

A Better Design for The Composition Class
The Composition Entity Class
P, Q, R, X, Y, Z
Only uses X, Y, and Z
Only uses P, Q, and R
43
The Editing Application
The Player Application
44
Controller Classes Hiding Portions of Public
Interface (5)
  • If minimizing access to public interface of
    composition is very important, then it is
    possible to encapsulate the Composition class in
    an EditComp and PlayComp classes.
  • This creates two new encapsulated classes which
    only exist to minimize public interface access.

44
45
Heuristics for Avoiding Macho Classes (1)
  • Heuristic 1 Distribute horizontal system
    intelligence as uniformly as possible, i.e. the
    top level classes in a design should share the
    work uniformly.
  • Heuristic 2 Beware of classes that have many
    accessor methods defined in their public
    interfaces.
  • Heuristic 3 Spin off non-related information
    into another class, i.e. non-communicating
    behavior.

45
46
Heuristics for Avoiding Macho Classes (2)
  • Heuristic 4 Most of the methods of a class
    should use most of the data most of the time.
  • Heuristic 5 Keep related data and behavior in
    one place.
  • Heuristic 6 Be suspicious of any class in your
    system whose name contains the substrings driver,
    system, subsystem, or manager.

46
47
Discussion Questions
  • T/F statements
  • 1. Abstract classes are used to generate object
    instances
  • 2. Legacy Software is any preexisting software
    that must be replaced by, incorporated into, or
    interfaced with software that is currently being
    developed
  • 3. Utility class contains global variables and
    functions.
  • 4. Design patterns identify, name, and describe
    common and recurring designs appearing frequently
    in object-oriented systems.
  • Define in UML Abstract Classes, Objects,
    Metaclasses, Parameterized Classes, Utility
    Classes, and Notes

47
48
Questions for the Next Lecture
  • Define
  • Objects
  • Notes
  • Attributes
  • Operations
  • Design patterns
  • The relationships between classes and objects.

48
49
Tasks for Next Lecture
  • Task 1 Problem Statement for team assignments
    are needed (see sample problems on the course web
    site). This is due by the end of his week
    (Final).
  • Task 2 Think About a problem statement for your
    team Project (see sample problems on the course
    web site). This is due on week No. 6 of the
    semester.
  • Task 3 Read Chapter the rest of Chapter 3 UML
    notation and terminology definitions.

49
Write a Comment
User Comments (0)
About PowerShow.com