CSSE 501 ObjectOriented Development

1
CSSE 501 Object-Oriented Development
2
Today

• Chapter 3 Object-Oriented Design

3
Questions

• The rules of any programming language are its
  _____
• A. Syntax
• B. Interpretation
• C. Logic
• D. Customs

4

• A translator that notes whether you have used a
  language correctly might be a ______
• A. Thesaurus
• B. Compiler
• C. Coder
• D. Decoder

5

• Which type of statement does not occur in
  computer program ____
• A. Sequence
• B. Loop
• C. Denial
• D. Selection

6
Programming in the Small and Programming in the
Large
7
Chapter 3 Object-Oriented Design

• Software development
• Ultimate goal deliver software products that are
  oriented towards
• Customer satisfaction
• Customer delight
• Customer ecstasy

8

• Popular software development methodologies
• System Development Life Cycle (SDLC) Model
• Prototyping Model
• Rapid Application Development Model
• Component Assembly Model

9
System Development Life Cycle (SDLC) Model

• Waterfall model

• System/Information
• Engineering and Modeling

2. Software Requirement Analysis
3. System Analysis and Design
4. Code Generation/ Implementation
5. Testing
6. Maintenance
10
Question

• Which activity costs the most?
• System/information engineering and modeling
• Software requirement analysis
• System analysis and design
• Code generation/implementation
• Testing
• Maintenance

11
Prototyping Model

• A cyclic version of the linear model
• Once the requirement analysis is done and the
  design for a prototype is made, the development
  process gets started to create a prototype
• Once the prototype is created, it is given to the
  customer for evaluation
• Many iterations between customers feedback and
  developers refinement until the final software
  package is delivered
• In this methodology, the software is evolved as a
  result of periodic shuttling of information
  between the customer and developer.
• Popular development model in the contemporary IT
  industry. - as it is very difficult to comprehend
  all the requirements of a customer in one shot
• New versions of a software product evolve as a
  result of prototyping.

12
Prototyping Model( many versions)
or
13
Rapid Application Development (RAD) Model

• A "high speed" adaptation of the linear
  sequential model
• Achieved by using a component-based construction
  approach
• The RAD approach encompasses the following
  phases
• Business modeling
• The information flow among business functions is
  modeled in a way that answers the following
  questions
• What information drives the business process?
• what information is generated?
• Who generates it?
• where does the information go?
• who processes it?
• Data modeling
• the information flow defined as part of the
  business modeling phase is refined into a set of
  data objects that are needed to support the
  business
• The characteristic (called attributes) of each
  object is identified and the relationships
  between these objects are defined

14
Rapid Application Development (RAD) Model (Cont.)

• Process modeling
• The data objects defined in the data-modeling
  phase are transformed to achieve the information
  flow necessary to implement a business function
• Processing the descriptions are created for
  adding, modifying, deleting, or retrieving a data
  object
• Application generation
• The RAD model assumes the use of the RAD tools
  like VB, VC, Delphi etc... rather than creating
  software using conventional third generation
  programming languages
• The RAD model works to reuse existing program
  components (when possible) or create reusable
  components (when necessary)
• In all cases, automated tools are used to
  facilitate construction of the software
• Testing and turnover
• Since the RAD process emphasizes reuse, many of
  the program components have already been tested.
  This minimizes the testing and development time

15
Component Assembly Model

• Object technologies provide the technical
  framework for a component-based process model for
  software engineering
• The object oriented paradigm emphasizes the
  creation of classes that encapsulate both data
  and the algorithm that are used to manipulate the
  data
• If properly designed and implemented, object
  oriented classes are reusable across different
  applications and computer based system
  architectures
• Component Assembly Model leads to software
  reusability. The integration/assembly of the
  already existing software components accelerate
  the development process
• Nowadays many component libraries are available
  on the Internet. If the right components are
  chosen, the integration aspect is made much
  simpler

16
What/Why is software design

• Software design sits at the crossroads of all the
  computer disciplines hardware and software
  engineering, programming, human factors research,
  ergonomics. It is the study of the intersection
  of human, machine, and the various
  interfacesphysical, sensory, psychologicalthat
  connect them --- by Association for Software
  Design (ASD) members
• Design is conscious
• Design keeps human concerns in the center
• Design is a dialog with materials
• Design is creative
• Design is communication
• Design is a social activity
• Design has social consequences

17
Basis for Design

• Consider for the moment what aspects of a problem
  (i.e., to develop a system) are known first
• Data Structures
• Functions
• A Formal Specification
• Behavior
• A design technique based on behavior can be
  applied from the very beginning of a problem,
  whereas techniques based on more structural
  properties necessarily require more preliminary
  analysis

18
Design Notations/Modeling Languages

• Many artifacts generated during the process of
  software development
• Requirement specifications
• Design documents
• Source code
• User manual
• Design notations capture design documents
• Informal
• Unified Modeling Languages
• Formal (formal methods, architecture description
  languages)

19
Object-Oriented Design Techniques/Methods

• Object-Oriented Development (OOD)/Booch
• Hierarchical Object-Oriented Design (HOOD)
• The Object Modelling Technique (OMT)
• Responsibility-Driven Design (RDD)/Class-Responsib
  ility-Collaboration (CRC)
• Object-Oriented Analysis (OOA)

20
Object-Oriented Development (OOD)/Booch

• Define the problem
• Develop an informal strategy for the software
  realization of the real world problem domain
• Formalize the strategy
• Identify the classes and objects at a given level
  of abstraction
• Identify the semantics of these classes and
  objects
• Identify the relationships among these classes
  and objects
• Implement these classes and objects

21
Object-Oriented Development (OOD)/Booch (Cont.)

• Major
• Rich notation available
• class diagrams (class structure - static view)
• object diagrams (object structure - static view)
• state transition diagrams (class structure -
  dynamic view)
• timing diagrams (object structure - dynamic view)
  
• module diagrams (module architecture)
• process diagrams (process architecture)

22
Object-Oriented Development (OOD)/Booch (Cont.)
A Booch Class Diagram for a Company
23
The Object Modeling Technique (OMT)

• A method which leads to three models of the
  system corresponding to three different views of
  the system
• The object model, which describes the static
  structure of the objects in a system and their
  relationships. The main concepts are class,
  attribute, operation, inheritance, association
  (i.e. relationship), aggregation
• The dynamic model, which describes the aspects of
  the system that change over time. This model is
  used to specify and implement the control aspects
  of a system. The main concepts are state,
  sub/super state, event, action, activity
• The functional model, which describes the data
  value transformations within a system. The main
  concepts are process, data store, data flow,
  control flow, actor (source/sink)

24
The Object Modeling Technique (OMT)(Cont.)

• The method is divided into four phases, which are
  stages of the development process
• Analysis - the building of a model of the real
  world situation, based on a statement of the
  problem or user requirements
• System design - the partitioning of the target
  system into subsystems, based on a combination of
  knowledge of the problem domain and the proposed
  architecture of the target system (solution
  domain
• Object design - construction of a design, based
  on the analysis model enriched with
  implementation detail, including the computer
  domain infrastructure classes
• Implementation - translation of the design into a
  particular language or hardware instantiation,
  with particular emphasis on traceability and
  retaining flexibility and extensibility

25
The Object Modeling Technique (OMT)(Cont.)
An Object Model of a Company
26
Responsibility Driven Design (RDD)

• Developed by Rebecca Wirfs-Brock
• One of object-oriented design techniques, driven
  by an emphasis on behavior at all levels of
  development
• A design technique that has the following
  properties
• Can deal with ambiguous and incomplete
  specifications
• Naturally flows from Analysis to Solution
• Easily integrates with various aspects of
  software development

27
Responsibility Driven Design (RDD)

• Describing the actions and activities for which
  our software is responsible
• Describing the responsibilities in terms that
  both users and developers can understand
• Designing software objects that implement those
  responsibilities

28
Responsibility Driven Design (RDD)

• RDD is not a sequential process
• Steps in RDD
• Software components
• Formalize interfaces
• Designing and representations
• Implementing components
• Integration of components
• Maintenance and evolution

29
Case Study the IIKH

• Briefly, the Intelligent Interactive Kitchen
  Helper (IIKH) will replace the box of index cards
  of recipes in the average kitchen

30
Your Job

• Imagine you are the chief software architect
• Your job is to develop the software that will
  implement the IIKH

31
Abilities of the IIKH

• Here are some of the things a user can do with
  the IIKH
• Browse a database of recipes
• Add a new recipe to the database
• Edit or annotate an existing recipe
• Plan a meal consisting of several courses
• Scale a recipe for some number of users
• Plan a longer period, say a week
• Generate a grocery list that includes all the
  items in all the menus for a period

32
Characterization by Behavior

• Just as an Abstract Data Type is characterized
  more by behavior than by representation, the goal
  in using Responsibility Driven Design will be to
  first characterize the application by behavior
• First capture the behavior of the entire
  application
• Refine this into behavioral descriptions of
  subsystems
• Refine behavior descriptions into code
• This emphasis on behavior is a hallmark of
  Object-Oriented programming

33
Working Through Scenarios

• Because of the ambiguity in the specification,
  the major tool here used to uncover the desired
  behavior is to walk through application scenarios
  
• Pretend there is already a working application
• Walk through the various uses of the system
• Establish the look and feel'' of the system
• Make sure uncover all the intended uses
• Develop descriptive documentation
• Create the high level software design
• The term use-cases'' used for this process of
  developing scenarios by others

34
Example Browsing Scenario

• Alice Smith starts the IIKH
• IIKH displays welcome message
• Alice presses the return button to begin
• Alice is given a choices of a number of options
• Alice selects to browse recipe
• Alice enters keywords to search, e.g., salmon,
  dill weed
• IIKH return two results
• Alice selects the first
• IIKH displays a window, showing everything
  regarding the recipe
• Alice does not want the recipe, returns to the
  search result page
• Alice selects the second recipe
• Alice wants the recipe
• Alice selects quit from the IIKH program menu
• The IIKH program quits

35
Software Components

• A software component is simply an abstract design
  entity with which we can associate
  responsibilities for different tasks
• May eventually be turned into a class, a
  function, a module, or something else
• A component must have a small well defined set of
  responsibilities
• A component should interact with other components
  to the minimal extent possible

36
CRC (Component, Responsibility, Collaborator)
Cards

• Components are most easily described using CRC
  cards
• A CRC card records the name, responsibilities,
  and collaborators of an component
• Inexpensive, Erasable, Physical

37
The first component, The Greeter

• Let us return to the development of the IIKH. The
  first component your team defines is the Greeter
• When the application is started, the Greeter puts
  an informative and friendly welcome window (the
  greeting) on the screen
• Offer the user the choice of several different
  actions
• Casually browse the database of recipes
• Add a new recipe
• Edit or annotate a recipe
• Review a plan for several meals
• Create a plan of meals
• Many of the details concerning exactly how this
  is to be done can be ignored for the moment

38
The Greeter
39
The Recipe Database Component

• Ignoring the planning of meals for the moment,
  your team elects to next explore the recipe
  database component
• Must maintain the database of recipes
• Must allow the user to browse the database
• Must permit the user to edit or annotate an
  existing recipe
• Must permit the user to add a new recipe

40
The Who/What Cycle

• As we walk through scenarios, we go through
  cycles of identifying a what, followed by a who
• What action needs to be performed at this moment
• Who is the component charged with performing the
  action
• Every what must have a who, otherwise it simply
  will not happen
• Sometimes the who might not be obvious at first,
  i.e., who should be in charge of editing a
  recipe?

41
Postponing Decisions

• Many decisions, such as the method of browsing,
  can be ignored for the moment, as they are
  entirely encapsulated within the recipe database
  component, and do not effect other components
• Scroll bars and windows?
• A virtual book'' with thumb-holes and flipping
  pages?
• Keywords and phrases?
• Only need to note that somehow the user can
  manipulate the database to select a specific
  recipe

42
Responsibilities of a Recipe

• We make the recipe itself into an active data
  structure. It maintains information, but also
  performs tasks
• Maintains the list of ingredients and
  transformation algorithm (i.e., ingredients to
  final product)
• Must know how to edit these data values
• Must know how to interactively display itself on
  the output device
• Must know how to print itself
• We will add other actions later (ability to scale
  itself, produce integrate ingredients into a
  grocery list, and so on)

43
The Planner Component

• Returning to the greeter, we start a different
  scenario. This leads to the description of the
  Planner
• Permits the user to select a sequence of dates
  for planning
• Permits the user to edit an existing plan
• Associates with Date object

44
The Date Component

• The Date component holds a sequence of meals for
  an individual date
• User can edit specific meals
• User can annotate information about dates
  (''Bob's Birthday'', Christmas Dinner'', and so
  on)
• Can print out grocery list for entire set of
  meals

45
The Meal Component

• The Meal component holds information about a
  single meal
• Allows user to interact with the recipe database
  to select individual recipes for meals
• User sets number of people to be present at meal,
  recipes are automatically scaled
• Can produce grocery list for entire meal, by
  combining grocery lists from individual scaled
  recipes

46
The Six Components

• Having walked through the various scenarios, you
  team eventually decides everything can be
  accomplished using only six software components
• You can at this point assign the different
  components to different programmers for
  development

47
Interaction Diagrams

• The picture on the previous slide captures static
  relationships, but not the dynamic flow of
  messages in a scenario
• That information can be recorded by an
  interaction diagram

48
Characteristics of Components

• Let us return to the idea of a software component
  
• There are many different aspects to this simple
  idea, we will consider just a few
• Behavior and state
• Instances and classes
• Coupling and cohesion
• Interface and implementation

49
Behavior and State

• All components can be characterized by two
  aspects
• The behavior of a component is the set of actions
  a component can perform. The complete set of
  behavior for a component is sometimes called the
  protocol
• The state of a component represents all the
  information (data values) held within a component
• Notice that it is common for behavior to change
  state. For example, the edit behavior of a recipe
  may change the preparation instructions, which is
  part of the state

50
Instances and Classes

• We can now clarify a point we earlier ignored.
  There are likely many instances of recipe, but
  they will all behave in the same way. We say the
  behavior is common to the class Recipe

51
Coupling and Cohesion

• The separation of tasks into the domains of
  different components should be guided by the
  concepts of coupling and cohesion
• Cohesion is the degree to which the tasks
  assigned to a component seem to form a meaningful
  unit
• Want to maximize cohesion
• Coupling is the degree to which the ability to
  fulfill a certain responsibility depends upon the
  actions of another component
• Want to minimize coupling

52
Interface and Implementation

• We have characterized software components by what
  they can do
• The user of a software component need only know
  what it does, not how it does it
• Ask not what you can do to a data structure, ask
  instead what your data structures can do for
  you''.

53
Two views of a Software System

• This naturally leads to two views of a software
  system
• The term information hiding is used to describe
  the purposeful hiding of implementation details

54
Parnas' Principles

• These ideas were captured by computer scientist
  David Parnas in a pair of rules, which are known
  as Parnas' Principles
• The developer of a software component must
  provide the intended user with all the
  information needed to make effective use of the
  services provided by the component, and should
  provide no other information
• The implementer of a software component must be
  provided with all the information necessary to
  carry out the given responsibilities assigned to
  the component, and should be provided with no
  other information

55
Public and Private View

• In C and Java, Parnas's Principles lead to the
  ideas of a public and private view
• Public view - those features (data or behavior)
  that other components can see and use
• Private view - those features (data or behavior)
  that are used only within the component

56
Next Step - Formalize the Interface

• The next step is to formalize the channels of
  communication between the components
• The general structure of each component is
  identified
• Components with only one behavior may be made
  into functions
• Components with many behaviors are probably more
  easily implemented as classes
• Names are given to each of the responsibilities -
  these will eventually be mapped on to procedure
  names
• Information is assigned to each component and
  accounted for
• Scenarios are replayed in order to ensure all
  data is available

57
Names with Activities

• The selection of names is an important task
• Names should be evocative in the context of the
  problem
• Names should be short
• Names should be pronounceable (read them out
  load)
• Names should be consistent within the project
• Avoid digits within a name

58
Documentation

• Besides CRC cards, it is important that the
  development of other documentation be performed
  almost from the beginning
• The two most important documents are the user
  manual and the design documentation of the
  software system

59
User Manual

• The user manual describes the application as seen
  by the user
• Does not depend upon the implementation, so can
  be developed before the implementation
• Can naturally flow from the process of walking
  through scenarios
• Can be carried back to the clients to make sure
  the users and the implementers have the same
  ideas

60
Quality

• You should always remember that the primary
  measure of quality is the degree to which your
  customers (clients) are satisfied with your
  product
• Since often customers do not know exactly what it
  is they want, it is important to work with the
  client early in the design phase to make sure the
  system your are developing is the desired product
• One very important way to do this is to create
  the user manual even before the software is
  written

61
System Design Documentation

• Record the decisions made during the process of
  system design
• Record the arguments for and against any major
  decision, and the factors influencing the final
  choice
• Record CRC cards for the major components
• Maintain a log or diary of the process schedule
• Important to produce this while the ideas are
  fresh, not in hindsight when many details will
  have been forgotten
• Note the code only records the outcome of
  decisions, not factors that lead up to decisions
  being made

62
Preparing for Change

• Your design team should also keep in mind that
  change is inevitable
• Users requirements change with experience,
  hardware changes, government regulations change
• Try to predict the most likely sources of change,
  and isolate the effect
• Common changes include interfaces, file formats,
  communication protocols
• Isolate interfaces to hardware that is likely to
  change
• Reduce dependency of one software component on
  another
• Keep accurate record of the reasoning behind
  every major decision in the design documentation

63
Next Step - Select Representations for Subsystems

• Next the internal representation of the software
  subsystem corresponding to each component is
  selected
• Knowledge of the classic data structures of
  Computer Science is important here
• Often once data structures have been selected,
  the code is almost self-evident

64
Next Step - Implement and Test Subsystems

• Classic techniques, such as stepwise refinement,
  are used to implement each of the subsystems
• Subsystems are validated in isolation
• Informal proofs of correctness for the subsystem
  are developed
• Identify necessary conditions for correct
  functioning. Try to minimize conditions, and test
  input values whenever possible
• Software testing is used as a confidence building
  measure

65
Step - Integration and Testing

• Components are slowly integrated into completed
  system
• Stubs can be used to perform testing all during
  integration
• Errors discovered during integration to cause
  reinvestigation of validation techniques
  performed at the subsystem level

66
Maintenance and Evolution

• Software does not remain fixed after the first
  working version is released
• Errors or bugs can be discovered. Must be
  corrected
• Requirements may change. Say as a result of
  government regulations, or standardization among
  similar products
• Hardware may change
• Users expectations may change. Greater
  functionality, more features. Often as a result
  of competition from similar products
• Better documentation may be required.
• A good design recognizes the inevitability of
  change, and plans an accommodation for these
  activities from the very beginning

67
Common Design Flaws

• The following categories present some of the more
  common design flaws
• Direct modification
• Components that make direct modification of data
  values in other components are a direct violation
  of encapsulation
• Such coupling makes for inflexible designs
• Too Much Responsibility
• Components with too much responsibility are
  difficult to understand and to use
• Responsibility should be broken into smaller
  meaningful packages and distributed
• No Responsibility
• Components with no responsibility serve no
  purpose
• Often arise when designers equate physical
  existence with logical design existence
• Money is no object''
• Components with unused responsibility
• Usually the result of designing software
  components without thinking about how they will
  be used
• Misleading Names
• Names should be short and unambiguously indicate
  what the responsibilities of the component
  involve

68
Exercise Use RDD to Develop an ATM system

• Describe the behavior (as complete as possible)
• Walking through 2 scenarios
• Software components (CRC cards)
• Interaction between these components