Class

1
08-25-2004
(Lecture 2)
CS8430 OO Analysis and Design MSACSDr. Jose M.
Garrido
Class Will Start Momentarily
2
Software Development Process

• A process for producing the software that
  implements the solution on a computer.
• Guides the developer into a well-defined process
  to be carried out in a disciplined manner and to
  accomplish development of correct software.
• The life cycle is used to organize and manage the
  software development process including the phases
  to maintain and retire the software.

3
Software Life Cycle

• The entire development process consists of a
  sequence of activities or phases that are carried
  out by a team of developers.
• These activities represent the complete life of
  the software from birth to retirement.

4
Understanding Life cycle

• Software development, which includes all the
  phases necessary to carry out the initial
  development of the software product.
• Using the developed software, this includes the
  activities that support the software in
  production.
• Maintenance, which include the activities that
  report defects in the software and the subsequent
  fixes and releases of new versions of the
  software product.
• Retirement, which takes the software off
  production when it can no longer be maintained.

5
Waterfall Model

• One of the earliest and simplest models for the
  software life cycle is the waterfall model.
• This model represents the sequence of activities
  to develop the software system up to installation
  for using the software.
• The activity in a given stage or phase cannot be
  started until the activity of the previous phase
  has been completed.

6
The Waterfall Model
7
Tasks in the Software Development Process

• Analysis
• Design
• Implementation
• Testing
• Deployment

8
Analysis

• Describes what the problem solution is supposed
  to accomplish. The outcomes of this phase are the
  various requirement documents, which include
  specifying the requirements of the problem in a
  more complete, precise, clear, and understandable
  form.
• Entails a thorough understanding of the problem
  and describing the problem in a very precise
  manner and what is to be done.

9
Design

• Describes the structure and behavior of the
  components of the system model. The outcome of
  this phase is a detailed description of the data
  structures and algorithms in each component of
  the model.
• The decomposition of the software into smaller
  parts is usually part of the preliminary design.
  The rationale for this step is that it is much
  easier to manage small pieces of the software
  instead of the whole product.

10
Design (Cont.)

• The detailed design may be the most
  intellectually challenging in program
  development.
• In this phase, one or more solutions to the
  problem are investigated. The data structures and
  the algorithms are designed, written in some
  appropriate notation (i.e., pseudo-code and/or
  flowcharts), and documented.

11
Implementation

• Includes the translation of the design solution
  into a programming language, followed by the
  compilation of the code written.
• This is the actual construction of the program(s)
  for the application. The outcome of this phase is
  the set of programs constructed.

12
Testing

• Verifies the program(s) that the program works
  according to requirements with appropriate data
  according to the set of examples provided.
• This phase includes unit testing, which involves
  the testing of individual components (modules),
  and integration testing, which involves testing
  all the components together.
• The outcome of this phase is the verified
  application software.

13
Moving Target Problem

• While the system is being developed, the
  requirements change
• Frequent changes in requirements affect
  negatively the development of the system

14
Iteration

• Successive versions of an artifact the process
  is iterative
• There are multiple versions of the artifact

15
Incrementation

• Stepwise refinement
• An artifact is constructed piece by piece

16
Limitation of the Waterfall Model

• It is not iterative, which is extremely necessary
  in practice.
• There are some variations proposed for the
  waterfall model. These include returning to the
  previous phase when necessary.
• Recent trends in system development have
  emphasized the iterative approach. In this
  approach, previous stages can be revised and
  enhanced.

17
Other Life cycle Models

• The spiral model of software development is a
  more complete model that incorporates the
  construction of prototypes in the early stages.
• A prototype is an early version of the
  application that does not have all the final
  characteristics.
• Other development approaches involve prototyping
  and rapid application development (RAD).

18
What is the Difference?

• Verification
• Validation

19
Data Abstraction with C

• There is a physical separation of
• The class specification, which is stored in a
  header file (myclass.h)
• The class implementation, which is stored in a
  class file (myclass.cpp)

20
Data Abstraction with Java

• There is no physical separation of the class
  specification from the class implementation
• However, the javadoc tool formats the class
  declarations only to an html file
• Java also supports the interface construct

21
Classes

• A class is an important mechanism for classifying
  objects
• The world is partitioned into objects that have
  properties and behavior (methods)
• A class is a collection of similar objects

22
Modeling

• A model is an abstract representation of a
  system. Three basic issues in modeling are
• Identifying the objects to include in the model
• Describing these objects
• Grouping similar objects into collections

23
Object Analysis

• The process of identifying classes that play a
  role in achieving system goals and requirements,
  are identified
• Identifying classes is the hardest part of object
  oriented analysis

24
Collections of Objects
25
UML Diagram for a Class
26
Importance of Classes

• Classes are important because they represent
  conceptual building blocks for designing systems

27
Classification

• Identify objects in the problem domain
• Check if an object belongs to a category or class
• Classes are an important means to classify
  objects
• It is natural to partition the world into objects
  that have attributes and operations

28
Design Level

• A class is a decomposition unit
• A class is a type for objects
• A class is a specification of a structure,
  behavior, and the description of an object

29
Views of an OO Program

• The static view, which describes the structure of
  the program. Programs are composed of one or more
  modules called classes.
• The dynamic view, which describes the behavior of
  the program while it executes. This behavior
  consists of the set of objects, each one
  exhibiting individual behavior and its
  interaction with other objects.

30
More on Classification

• Carried out via the search for features among
  members of a class
• Can be defined as the categorization of entities
  into identifiable classes by extracting
  significant features

31
Enhance Reusability

• To enhance reusability
• Avoid repetition in specifying ADTs, writing
  code, debugging, etc.
• Extendibility for existing classes
• Specialization of existing classes
• Inheritance is provided in OO languages.

32
Inherited Features

• The features of the parent class are available to
  the derived class
• The extendibility property of inheritance is used
  if the derived class includes additional features
  of its own
• The specialization property of inheritance is
  used if the derived class needs to redefine
  features that were defined in the parent class

33
INHERITANCE

• A subclass (also called derived class) inherits
  the features of the parent class
• Inheritance helps in the reusability and
  maintainability of classes
• Inheritance can be single from a single parent
  class, or multiple from two or more parent
  classes

34
Inheritance
35
Approaches for Identifying Classes

• Noun phrase approach
• Common class patterns approach
• Use case driven approach
• CRC approach

36
Noun Phrase Approach

• Read through the requirements or use cases
  looking for noun phrases
• Nouns in the textual description are considered
  to be classes and verbs to be operations of the
  classes
• Nouns are listed in three categories
• relevant classes
• fuzzy classes
• irrelevant classes

37
Example Bank ATM System

• Account
• Account balance
• Amount
• ATM card
• ATM machine
• Bank
• Bank client
• Card
• Password
• PIN

• Cash
• Check
• Checking account
• Client
• Currency
• Envelope
• Fund
• Invalid PIN
• Message

38
Class Purpose

• Identifying classes that play a role in achieving
  system goals and requirements is a mayor activity
  of object-oriented analysis
• Each class must have a purpose
• The major purpose with the noun phrase approach
  is that it depends on the completeness and
  correctness of the the available documents.

39
Use-case Driven Approach

• Use cases are employed to model the scenarios in
  the system and describe what external actors
  interact with the system processes
• Modeling with use cases is a recommended aid in
  finding the objects of a system
• The modeler then can examine the textual
  description of each scenario for objects.

40
Example Use Cases for Bank ATM System

• Deposit checking
• Deposit savings
• Invalid PIN
• Withdraw checking
• Withdraw move from checking
• Withdraw savings
• Withdraw savings denied

41
Classes Identified

• Bank
• Bank client
• ATM machine
• Account
• Checking account
• Savings account

42
CRC Cards in the Initial OO Analysis

• CRC cards constitute another, more informal
  technique for identifying and defining the
  characteristics of the classes that make up an
  application
• CRC cards are a concrete way of understanding
  exactly what OO development is all about.

43
CRC Cards

• CRC stands for Classes, Responsibilities, and
  Collaborators
• Is based on the idea that that an object either
  can accomplish a certain responsibility by
  itself, or it may require the assistance of other
  objects

44
CRC Cards

• It is a good technique to use with domain
  experts, user representatives, and other
  nonprogrammers during the initial definition of
  the system.

45
CRC Process

• The CRC process consists of three steps
• Identify classes and classes responsibilities
• Assign responsibilities
• Identify collaborators

46
Layout of a CRC Card

• At the top of each card is the class name for the
  class. Classes are generic descriptions of sets
  of objects
• Brief description of the class
• List of attributes

47
CRC Card Layout

• The list of superclasses
• List of derived classes
• Responsibilities are services provided. A
  responsibility is a short phrase, and must
  include a verb.
• A collaborator is the name of another class that
  is used to perform a specific responsibility.

48
Steps in a CRC Session

• Assemble a group
• Review requirements
• Brainstorm a group of classes
• Review the list of classes
• Prepare CRC cards

• Develop class descriptions
• List responsibilities
• List collaborators
• Generate specific scenarios
• Add superclasses
• Add subclasses

49
Example Bank ATM System

• CRC Card for Account class
• Attributes balance, number
• Responsibilities deposit, withdraw, getbalance
• Subclasses Checking Account, Savings Account
• Collaborators Transaction

50
CRC Terms vs UML Terms

• CRC is not an official part of the UML
• CRC cards are like UML classes
• CRC cards are constructed in the context of
  specific scenarios
• UML operations are CRC responsibilities
• Collaborators in CRC are classes that have
  associations in UML.