CS 432 Object-Oriented Analysis and Design

1
CS 432 Object-Oriented Analysis and Design

• Week 3
• The Design Model

2
(No Transcript)
3
What is Object-Oriented Design?

• The bridge between a users requirements and
  programming for the new system
• Blueprints, or design models, are necessary to
  build systems
• An adaptive approach to development
• Requirements and design are done incrementally
  within an iteration
• A complete set of designs may not be developed at
  one time

4
Overview of Object-Oriented Programs

• Object-oriented programs consist of a set of
  computing objects that cooperate to accomplish a
  result
• Each object has program logic and data
  encapsulated within it
• Objects send each other messages to collaborate
• Most object-oriented programs are event-driven
• Instantiation of a class creates an object based
  on the template provided by the class definition

5
Object-Oriented Design Models

• Identify all objects that must work together to
  carry out a use case
• Divide objects into groups for a multilayer
  design
• Interaction diagrams describe the messages that
  are sent between objects
• Includes sequence and communication diagrams
• Design class diagrams document and describe the
  programming classes

6
Object-Oriented Design Models (continued)

• Statecharts capture information about the valid
  states and transitions of an object
• Package diagrams denote which classes work
  together as a subsystem
• Design information is primarily derived from
• Domain model class diagrams
• Interaction diagrams

7
Object-Oriented Design Process

• Create a first-cut model of the design class
  diagrams
• Develop interaction diagrams for each use case or
  scenario (communication or sequence)
• Update the design class diagrams
• Method names, method parameters, attributes,
  attribute data types, and relationship
  multiplicity
• Partition the design class diagrams into related
  functions using package diagrams

8
Design Classes and Design Class Diagrams

• Design class diagrams are extensions of domain or
  analysis class model diagrams
• Elaborate on attribute details
• Define parameters and return values of methods
• Define the internal logic of methods
• A first-cut design class diagram is based on the
  domain model and engineering design principles
• Interaction diagrams are used to refine a design
  class diagram as development progresses

9
(No Transcript)
10
The Design Workflow

• The input to the design workflow is the set of
  analysis workflow artifacts
• These artifacts are iterated and incremented
  until they can be used by the programmers
• A major aspect of this iteration and
  incrementation is
• The identification of operations or methods
• The identification of method parameters and
  parameter data types
• The identification of attribute types, and
• Their allocation to the appropriate classes
• Relationships between classes type and
  multiplicity

11
The Design Workflow (contd)

• Many other decisions have to be made as part of
  the design workflow, including
• Choice of programming language
• Deciding how much of existing information systems
  to reuse in the new information system
• Level of portability
• The allocation of each software component to its
  hardware component

12
The Design Workflow (contd)

• The case studies in this class are small-scale
  information systems
• Under 5,000 lines of Java or C code in length
• The Unified Process was designed for developing
  large-scale information systems
• 500,000 lines of code or more
• These information systems are at least 100 times
  larger than the case studies presented in this
  class
• Therefore, some aspects of the Unified Process
  are inapplicable to our case studies

13
The Design Workflow (contd)

• During the analysis workflow, a large information
  system is partitioned into analysis packages
• Each analysis package consists of a set of
  related classes that can be implemented as a
  single unit
• Example
• Accounts payable, accounts receivable, and
  general ledger are typical analysis packages
• The concept underlying analysis packages is
• It is easier to develop smaller information
  systems than larger information systems
• A large information system will be easier to
  develop if it can be decomposed into independent
  packages

14
The Design Workflow (contd)

• The idea of decomposing a large workflow into
  independent smaller workflows is carried forward
  to the design workflow
• The objective is to break up the upcoming
  implementation workflow into manageable pieces
• Subsystems

15
The Design Workflow (contd)

• Reasons why subsystems are utilized
• It is easier to implement a number of smaller
  subsystems than one large system
• If the subsystems are independent, they can be
  implemented by programming teams working in
  parallel
• The information system as a whole can then be
  delivered sooner

16
The Design Workflow (contd)

• The architecture of an information system
  includes
• The various component modules
• How they fit together
• The allocation of components to subsystems
• The task of designing the architecture is
  specialized
• It is performed by an information system architect

17
The Design Workflow (contd)

• The architect needs to make trade-offs
• Every information system must satisfy its
  functional requirements (the use cases)
• It also must satisfy its nonfunctional
  requirements, including
• Portability, reliability, robustness,
  maintainability, and security
• It must do all these things within budget and
  within the time constraint
• The architect must assist the client by laying
  out the trade-offs

18
The Design Workflow (contd)

• It is usually impossible to satisfy all the
  requirements, functional and nonfunctional,
  within the cost and time constraints
• Some sort of compromises have to be made
• The client has to
• Relax some of the requirements
• Increase the budget and/or
• Move the delivery deadline

19
The Design Workflow (contd)

• The architecture of an information system is
  critical
• The requirements workflow can be fixed during the
  analysis workflow
• The analysis workflow can be fixed during the
  design workflow
• The design workflow can be fixed during the
  implementation workflow
• But there is no way to recover from suboptimal
  architecture
• The architecture must immediately be redesigned

20
Traditional versus Object-Oriented Design

• In the traditional paradigm, the design phase
  consists of
• Architectural design
• The information system is decomposed into modules
• followed by
• Detailed design
• Algorithms and data structures are designed for
  each module

21
Traditional versus Object-Oriented Design (contd)

• Classes are modules
• Much of traditional architectural design is
  performed as part of class extraction in the
  object-oriented analysis workflow

22
Some Fundamental Design Principles

• Encapsulation
• Each object is a self-contained unit containing
  both data and program logic
• Object reuse
• Standard objects can be used over and over again
  within a system
• Information hiding
• Data associated with an object is not visible
• Methods provide access to data

23
Some Fundamental Design Principles (contd)

• Navigation visibility
• Describes which objects can interact with each
  other
• Coupling
• Measures how closely classes are linked
• Want LOW coupling
• Cohesion
• Measures the consistency of functions in a class
• Want HIGH cohesion
• Separation of responsibilities
• Divides a class into several highly cohesive
  classes

24
University SystemUse Case Diagram
25
Analysis Class Diagram
26
How to Create Design-LevelClass Diagrams

• To create and evolve a design class diagram, you
  need to iteratively model
• Classes
• Responsibilities
• Associations
• Inheritance relationships
• Composition associations
• Association classes
• Interfaces

27
Classes

• An object is any person, place, thing, concept,
  event, screen, or report applicable to your
  system.
• Objects both know things (they have attributes)
  and they do things (they have methods).
• A class is a representation of an object and, in
  many ways, it is simply a template from which
  objects are created.
• Classes form the main building blocks of an
  object-oriented application. 
• Although thousands of students attend the
  university, you would only model one class,
  called Student, which would represent the entire
  collection of students.

28
Classes

• Classes are typically modeled as rectangles with
  three sections
• the top section for the name of the class,
• the middle section for the attributes of the
  class,
• and the bottom section for the methods of the
  class.

29
Attributes Methods

• Attributes are the information stored about an
  object (or at least information  temporarily
  maintained about an object)
• Students have student numbers, names, addresses,
  and phone numbers.
• Methods are the things an object or class do.
• Students also enroll in courses, drop courses,
  and request transcripts.
• You should think of methods as the
  object-oriented equivalent of functions and
  procedures.

30
Responsibilities or Methods

• How to find responsibilities which are methods?
• Ask these questions
• How am I going to be used?
• How am I going to collaborate with other classes?
• How am I described in the context of this
  system's responsibility?
• What do I need to know?
• What state information do I need to remember over
  time?
• What states can I be in?

31
Identifying Responsibilities or Methods

• Methods usually correspond to queries about
  attributes (and sometimes association) of the
  objects.
• Methods are responsible for managing the value of
  attributes such as query, updating, reading and
  writing.

32
Level of Detail

• An important consideration the appropriate level
  of detail.
• Consider the Student class modeled which has an
  attribute called Address.
• Notice how the Address class has been modeled to
  include an attribute for each piece of data it
  comprises and two methods have been added one to
  verify it is a valid address and one to output it
  as a label (perhaps for an envelope).
• By introducing the Address class, the Student
  class has become more cohesive.
• The Address class could now be reused in other
  places, such as the Professor class, reducing
  your overall development costs.
• A student may live in a different location than
  his permanent mailing address, such as a
  dorm¾information the system may need to track.
  Having a separate class to implement addresses
  should make the addition of this behavior easier
  to implement.

33
Level of Detail in a Design-Level Class Diagram
Class information visibility and scope
34
Constructors

• Constructor methods provide a way of initializing
  an object.
• A constructor method has the same name as its
  class and is automatically invoked by the
  object-oriented programming environment (e.g.,
  the Java Virtual Machine) when new instance
  objects of a class are created.
• As the return type of the constructor is always
  the same as the class and the constructors name,
  the return type is often omitted from the UML
  visual representation of the constructor.
• Since a constructor may also have parameters like
  any method, the parameters of a constructor can
  be used to assign initial values to the
  attributes of the object.

35
Constructor Example

• In programming source code, new instance objects
  are created by using the new command, which
  executes any code in the constructor, and returns
  the new object.

// Create a new account object with id 12 and //
assign it to the acct variable. Account acct
new Account(12) // Get the id of the new
account object. int id acct.getId()
36
Refactoring or Class Normalization

• A process in which you refactor the behavior of
  classes to increase their cohesion and/or to
  reduce the coupling between classes.
• A seminar is an offering of a course, for
  example, there could be five seminar offerings of
  the course "CS 208 Introduction to Computer
  Science." 
• The attributes name and fees were moved to the
  Course class and courseNumber was introduced.

37
Course with Accessor and Mutator Methods

• Depicts Course as it would appear with its getter
  and setter methods modeled

38
Associations (Binary Relationships)

• Objects are often associated with, or related to,
  other objects.
• Several associations exist
• Students are ON WAITING LIST for seminars
• Professors INSTRUCT seminars
• Seminars are an OFFERING OF courses
• A professor LIVES AT an address
• Associations are modeled as lines connecting the
  two classes whose instances (objects) are
  involved in the relationship.
• When you model associations in UML class
  diagrams, you show them as a thin line connecting
  two classes
• The label, which is optional, although highly
  recommended, is typically one or two words
  describing the association.
• For example, professors instruct seminars.

39
Associations (contd)

• UML Notation
• You also need to identify the multiplicity of an
  association.
• The multiplicity of the association is labeled on
  either end of the line, one multiplicity
  indicator for each direction

40
Multiplicity Indicators
41
Multiplicity 1-to-1(Bank Example)

• This multiplicity simply indicates that one
  Customer object owns exactly one Account Object,
  and the Account is owned by exactly one customer
  object.

42
Multiplicity Many-to-1(University Example)
43
Inheritance Relationships

• Similarities often exist between different
  classes.
• Very often two or more classes will share the
  same attributes and/or the same methods.
• Because you dont want to have to write the same
  code repeatedly, you want a mechanism that takes
  advantage of these similarities.
• Inheritance models is a and is like
  relationships, enabling you to reuse existing
  data and code easily.
• When A inherits from B, we say A is the subclass
  of B and B is the superclass of A.
• The UML modeling notation for inheritance is a
  line with a closed arrowhead pointing from the
  subclass to the superclass.

44
Inheritance hierarchy
45
Guidelines For Identifying Super-sub
Relationships Top-down

• Look for noun phrases composed of various
  adjectives on class name.
• Example, Military Aircraft and Civilian Aircraft.
• Only specialize when the sub classes have
  significant behavior.

46
Guidelines For Identifying Super-sub
Relationships Bottom-up

• Look for classes with similar attributes or
  methods.
• Group them by moving the common attributes and
  methods to super class.
• Do not force classes to fit a preconceived
  generalization structure.

47
Guidelines For Identifying Super-sub
Relationships Reusability

• Move attributes and methods as high as possible
  in the hierarchy.
• At the same time do not create very specialized
  classes at the top of hierarchy.
• This balancing act can be achieved through
  several iterations.

48
Guidelines For Identifying Super-sub
Relationships Multiple inheritance

• Avoid use of multiple inheritance.
• It is also more difficult to understand programs
  written in multiple inheritance system.
• Java does not support multiple inheritance but
  C does.

49
Multiple Inheritance

• One way to achieve the benefits of multiple
  inheritance is to inherit from the most
  appropriate class and add an object of other
  class as an attribute.
• In essence, a multiple inheritance can be
  represented as an aggregation of a single
  inheritance and aggregation. This
  meta model reflects this
  situation

50
Abstract Classes Inheritance

• The Person class is abstract objects are not
  created directly from it, and it captures the
  similarities between the students and professors.
  
• Abstract classes are modeled with their names in
  italics, as opposed to concrete classes, classes
  from which objects are instantiated, whose names
  are in normal text.
• Both classes had a name, e-mail address, and
  phone number, so these attributes were moved into
  Person.
• The Purchase Parking Pass method is also common
  between the two classes.
• By introducing this inheritance relationship to
  the model, the amount of work to be performed was
  reduced.
• Instead of implementing these responsibilities
  twice, they are implemented once, in the Person
  class, and reused by Student and Professor.

51
Aggregation Relation

• An aggregation is an association that supports a
  loose relation between objects in which one
  object is considered a part of the other object
  in the relation.
• Consider the relation between a Computer and a
  Printer.
• a Computer may be attached to 0 or more
  Printers
• at any one point in time a Printer is connected
  to 0 or 1 Computer
• over time, many Computers may use a given
  Printer
• the Printer may exist even if there are not
  attached Computers
• the Printer is, in a very real sense, independent
  of the Computer.

52
Composition Relation

• A composition relation is a stronger form of
  aggregation that should be used when the part
  class has no independent existence from the
  whole.
• For example, since a customers account would not
  exist in a system without the customer, it
  qualifies as a composite relation. In this
  capacity an Account should be though of as being
  part-of a customer.

53
Composition Relation (contd)

• Another example
• A building is composed of one or more rooms, and
  then, in turn, that a room may be composed of
  several subrooms (you can have recursive
  composition)

54
Customer Order from a Retail Catalog
55
Video Store Example
Multiplicity
Customer
Simple Aggregation
1
Class
Abstract Class
Rental Invoice
1..
Rental Item
1
0..1
Composition
Simple Association
Generalization
Checkout Screen
DVD Movie
VHS Movie
Video Game
56
Association Classes

• The association between the two classes may be
  modeled as a class
• You use this when you have many-to-many
  relationships like the association class in an ERD

57
Interfaces

• The C and Java programming languages allow for
  the creation of interface entities that capture a
  collection of methods representing a public
  interface. (C uses abstract classes)
• An interface is similar to an abstract class that
  does not have any concrete methods at all.
• An interface is simply a collection of method
  signatures.
• A List interface provides a nice example of the
  benefits of using interfaces.

58
Interfaces (contd)
59
Interfaces (contd)

• Interfaces are implemented, realized in UML
  parlance, by classes and components
• To realize an interface a class or component must
  implement the operations. 
• Any given class or component may implement zero
  or more interfaces and one or more classes or
  components can implement the same interface.

60
Polymorphism

• Polymorphism means many forms and concerns the
  ability of an object to dynamically take on a
  different form depending on the runtime context.
• Although technically correct, this definition is
  a bit misleading since the object does not
  exactly change form, but instead the way in which
  its viewed by other objects changes.
• We should also note that polymorphism involves
  the behavior of objects.

61
Polymorphism (contd)

• Consider the following three class fragments
  taken from a graphical user interface
  application.
• The abstract Component class represents a generic
  component that captures the common functionality
  of graphical widgets that can be displayed on a
  canvas/window.
• The Button and TextField classes share the common
  functionality, having an (x, y) position in the
  window and responding to messages requesting them
  to paint themselves on the canvas, erase
  themselves, and move themselves from one location
  to another.

62
Polymorphism (contd)
63
Polymorphism (contd)

• Assume we are given a List of component objects
  which we wish to draw on the screen. The
  following pseudo-code would accomplish this
  desire
• ForEach component In the list Do Send the
  component a paint() message
• Polymorphism concerns the fact that although we
  are sending messages to Component objects, the
  actual method that handles the message will be
  executed as part of a Button or TextField object.
  
• When an object receives a message, the most
  specific method of its parent class or its
  ancestors will execute.
• However, the key point isnt what method
  executes, but what the type of object is
  receiving the message.

64
Signatures and Method Overloading

• A significant difference between procedural
  functions and object-oriented methods concerns
  method overloading, which is based on the concept
  of signatures.
• A method signature is the combination of its
  visibility, name, parameter cardinality (number
  of parameters), the types of these parameters,
  and its return type.
• For example, all of the methods in the following
  list have different signatures
• getId()int OR -getId()int // Visibility
  differs
• getBalance()int // Different name
• withdraw(amountint)void // Different name
• withdraw(amountfloat)void // Parameter type
  differs
• withdraw(id int,amountfloat)void// Different
  parameter cardinality
• Note that current object-oriented programming
  languages require that all methods in the same
  class and with the same name have the same return
  type.

65
Overloading

• An overloaded method occurs when two or more
  methods with the same name in the same class have
  different signatures.
• For example, the Withdraw method in the following
  example class is overloaded.
• In this example the withdraw method is overloaded
  since the parameter type of the single parameter
  is different in each method.
• When an object of this Account class receives a
  withdraw method, the object-oriented execution
  environment (e.g., the Java Virtual Machine) will
  dynamically select and execute the withdraw
  method with the corresponding parameter type.