SOFTLAB Software Engineering Research in CmpE

1
Software design
What are some basic design principles and how can
you measure design quality?
2
The software landscape

• When systems were not large enough to merit an
  explicit design phase, software was considered to
  encompass all of the forms that were concerned
  with generating executable binary code that was
  intended for execution on a single machine
• The structure of the system was largely fixed
  when the code was compiled and so the idea(s) of
  the designer were directed towards producing a
  single monolithic unit of binary code
• Systems are now large and typically distributed
  across several machines
• The designers now have to decide how
  functionality and data would be partitioned or
  shared between machines, the form of
  communication mechanisms to employ, and the
  likely performance effects of these choices

3
Which Technology?
4
Uyarlama, sürüm yönetimi
Veri madenciligi
Kablosuz
WAP sunucu
Veri tabani
Fatura
E-Mail Sunucu
I n t e r n e t
ORACLE ERP
Irsaliye
Web Sunucu
E S A S
Yerel Veritabani
Operasyon
P S T N
IVR Sunucu
Satis
CRM
Çagri Merkezi Sunucu
I n t r a n e t
Tek giris
Arayüzler (XML, HTTP..)
5
Software design

• The process of design is divided into two
  distinct phases
• Architectural or logical design designer
  develops a highly abstract model of the system in
  which only externally visible properties of the
  model elements are included this black-box
  partitioning is largely concerned with the nature
  and form of the problem and is less strongly
  influenced by the eventual form that will be
  adopted for its solution
• Detailed or physical design the abstract
  chunks of the problem that were identified in
  the first phase are mapped on to
  technologically-based units turning the black-box
  into a white-box

6
Software design

• Following properties of software make the design
  process a challenging task
• Complexity no two parts of a system are alike
  and it may possess very many states during
  execution
• Conformity software is expected to conform to
  the standards imposed by other components
• Changeability software suffers constant need for
  change
• Invisibility this constraints our ability to
  conceptualize the characteristics of software and
  also hinders communication among those involved
  with its development

7
Measuring design quality (1)

• When you can measure what you are speaking
  about, and express it in numbers, you know
  something about it, but when you cannot measure
  it, when you cannot express it numbers, your
  knowledge is of a meager and unsatisfactory
  kind. (Lord Kelvin)
• Ideas about measurement originally emerged
  largely within a community of scientists and
  engineers who were seeking to capture ideas about
  physical properties such as mass, length,
  velocity, etc.
• The scales used for such properties are ratio
  scales they possess well defined intervals and a
  zero point

8
Measuring design quality (1)

• Once we move away from this context, we often are
  limited
• Many of the properties of interest to us are more
  likely to be measured using an ordinal scale
• Measurement is concerned with capturing
  information about the attributes of entities.
  (Fenton and Pfleeger, 1997)

9
Measuring design quality (2)
10
Consider the building architecture (1)

• Structure
• An architecture defines the arrangement of
  structural elements
• Relates to form, function and characteristics
• Architectural style is the underlying structuring
  principle and philosophy
• Space
• Construction is both a physical and spatial
  transformation of a pre-existing situation

11
Consider the building architecture (1)

• Boundaries
• Building has a logical aspect too
• Separates notions of the inside and outside
• Architecture addresses the complex whole of
  interrelationship between such domains

12
Consider the building architecture (2)

• Neighborhoods as Domains
• The logical structure of an architecture is based
  on spatial domains
• Buildings, rooms, etc.
• And connection domains between them
• Streets, alleys, hallways, corridors, doors, etc.
• And how they are configured as a whole
• Logical coupling and cohesion

13
Consider the building architecture (2)

• Neighborhood Boundary
• The strength of the boundary is essential to a
  neighborhood. If the boundary is too weak the
  neighborhood will not be able to maintain its own
  identifiable character
• Encourage the formation of a boundary around each
  neighborhood, to separate it from the next door
  neighborhoods. Form this boundary by closing down
  streets and limiting access to the neighborhood
• Place gateways at those points where the
  restricted access paths cross the boundary and
  make the boundary zone wide enough to contain
  meeting places for the common functions shared by
  several neighborhoods

14
Example

• Consider the squares in the grid to be spaces
  the blue line to be the walls. At B3 is an
  external entrance use exactly 8 other internal
  entrances to connect the rooms so that every room
  is accessible
• The solution you will come up with will have same
  number of external and internal openings the
  difference being the location of cell entrances
• But this radically changes the patterns of
  movement through the buildings
• Which offers more opportunities for private
  space?

15
Dependencies

• Consider rooms A2, B2 and C2 in each of these
  configurations and the routes by which they can
  be reached.
• Which other rooms is each directly dependent on?
• Which other rooms is each indirectly dependent
  upon?
• Which other rooms directly depend on A2, B2 and
  C2?
• Are there any parallels with software?

16
Software and space

• Software does not deal with physical spaces
• But space is not merely a physical construct in
  architecture of the built environment it also
  embodies notions of logical and social spaces
• We can consider modules, packages, components,
  etc. to occupy virtual spaces in software
• And connectors to be access paths to these spaces
  which make them interdependent

17
Object-oriented software construction

• Objects and Classes are behavioral abstractions
• We separate objects in Class A from those in
  Class B on the basis of their different behavior
• But in the machine an object instance is a data
  abstraction
• A pointer or reference is returned to the
  objects data variables only
• Objects are therefore logical abstractions
• Dont really exist at the machine level

18
Responsibility driven design (1)

• Designing object systems involves
• Identifying behavioral abstractions (Object
  Types)
• Assigning them responsibilities
• Mapping object types to object classes
• Enforcing encapsulation and information hiding
• Creating interfaces so that client objects know
  how to request executable behavior from server
  objects
• Turning responsibilities into operations
• And the methods that implement them
• Turning collaborating classes into data members
  to hold object IDs

19
Responsibility driven design (2)

• A well established technique for
  responsibility-driven design is CRC cards
• 6x4 index cards
• Divided into 3 fields (Class, Responsibility,
  Collaborators)
• One for each candidate object
• Used to role play scenarios to see if
  responsibilities have been distributed properly
• Cheap and fun way to validate the dynamic
  behavior of object systems prior to coding

20
Encapsulation

• Encapsulation is the hiding of all design
  decisions that the client doesnt need to know
  about. Typically this includes
• Data structures
• Collaborating classes and objects
• Methods
• Private operations, etc.
• An object is therefore a sort of protected
  virtual space
• Like a neighborhood as discussed before

21
Interfaces (1)

• Ideally we would like the classes and objects to
  be completely decoupled from each other
• But references (object IDs) are needed otherwise
  programs wont work
• Collaboration requires some objects to know how
  to call other objects and request their behavior
• Therefore, interfaces are needed
• Compare with gateways and access paths in
  neighborhood boundary
• In Java a special interface construct is provided
• In C an abstract class can be used as a
  protocol class to the same effect

22
Interfaces (2)

• Interfaces should be designed to be stable
• Operation names and parameters of abstract
  behaviors
• Implementation can therefore vary without the
  client object needing to know
• Different methods, even different collaborating
  objects can handle the request for executable
  behavior
• Client only needs guarantee that the behavior
  will be performed correctly in response to the
  request (message)
• Note A class can support 1 or many interfaces

23
Significance of interfaces for architecture

• An interface can be thought of as an access path
  or gateway to an encapsulated space
• Space can be an object instance, a class, a
  package or any logical computational component
• We need to narrow interface bandwidth between
  spaces
• An interface also implies a dependency
• If Class A holds a reference to Class B it is
  dependent upon it
• If the Interface is physically separate from the
  class that realizes it and the reference is to
  the interface the clients only dependent on the
  interface (recommended)
• Interfaces can form a scaffolding for the system

24
Dependency heuristics

• Minimize all dependencies
• As far as possible make dependencies unilateral
• i.e. one way
• Only use bilateral or cyclical dependencies if
  classes are designed to work together in all
  circumstances
• In which case package them together as components

25
Levelization

• Levelization is desirable
• Assuming a bottom level 0, each component in a
  dependency hierarchy can be assigned a unique
  level number
• Implies a structure which is a directed acyclic
  graph (DAG)
• In good OO system structures
• Abstract, stable (unchanging) classes tend to be
  at or near level 0
• Concrete, volatile (often changing) classes tend
  to be at the highest levels
• We want to minimize the number of classes
  dependent on changeable classes

26
Analyzing structure in OO systems (1)

• Simple measurements can be used to measure the
  structural quality of OO systems
• Abstractness
• The total number of abstract classes (and
  interface types in Java) divided by the total
  number of classes and types. The measurement
  range is 0..1
• Stability/Volatility
• The number of efferent (outside) couplings (Ce)
  divided by the number of efferent couplings plus
  the number of afferent (inside) couplings (Ce
  Ca), range is 0..1
• Ce is the number of classes outside a package
  that classes inside the subject package directly
  depend on
• Ca is the number of classes outside the package
  that depend on classes inside the subject package
• Relational Cohesion
• Relational cohesion (H) is the total number of
  internal relationships (R) 1 divided by the
  total classes within the package (N)
• H (R 1) / N

27
Analyzing structure in OO systems (2)

• All of these metrics can be arrived at by mapping
  class relationships on a spreadsheet
• The values of abstractness, stability can be
  plotted on a stability graph

28
Distance from main sequence

• The Main Sequence is idealized by the line (A S
  1)
• Where A abstractness, S stabilty
• Any packages distance from the main sequence can
  be calculated by the formula
• D (A S 1)/SQRT(2)
• This means ignore sign, range is 0..0.7
• Can be normalized to a range 0..1 by
• D (A S 1)
• The value of D or D closer to 0 is better

29
Key points

• Objects are logical structures to which
  responsibilities are allocated in design
• Objects can therefore be thought of as
  architectural spaces
• As can classes, components and packages
• We can apply the lessons of neighborhood boundary
• Use encapsulation, interfaces to minimize
  dependencies
• We can measure the quality of a structure with
  simple dependency metrics

30
References

• D. Budgen, Software Design, Addison-Wesley, 2003.
• R. Wirfs-Brock and A. McKean, Object Design
  Roles, Responsibilities and Collaborations,
  Addison-Wesley, 2003.