Object Oriented Analysis and Design unit 2

1. Unit -2
•Review of Unit -1
•SDLC(Software Dev. Life Cycle)
•Process Model
•Different OO Method for Modeling

2. Object Definition
Two aspects:
 Information:
1) has a unique identity
2) has a description of its structure
3) has a state representing its current condition
 Behavior:
1) what can an object do?
2) what can be done to it?

3. Example of an Object - Printer
1) information:
a) serial number
b) model
c) speed
d) memory
e) status
2) behavior:
a) print file
b) stop printing
c) empty the queue

4.  Class Definition-
1) any uniquely identified abstraction of a set of logically
related instances that share similar characteristics
2) rules that define objects
3) a definition or template that describes how to build an
accurate representation of a specific type of objects
Examples: agency, citizen, car, etc.
Objects are created using class definitions as templates.

6.  Attribute Definition
Attribute is a named property of a class describing a range
of values that instances of the class may hold for that
property.
An attribute has a type and defines the type of its instances.
Only the object is able to change the values of its own
attributes.
The set of attribute values defines the state of the object.

8.  Operation Definition-
Operation is the implementation of a service that can be
requested from any object of a given class.
An operation could be:
1. a question - does not change the values of the
attributes
2. a command – may change the values of the attributes

10.  Relationships:
• between classes (relations)
• between objects (links)
• Three kinds of relations between classes:
1) association
2) aggregation
3) composition

11. 1. the simplest form of Association Name
relation between classes
2. peer-to-peer relations
University
3. one object is aware of the Professor Works for
existence of another
object
4. implemented in objects
as references Association
Class

13. 1. a restrictive form of “part-of” association
2. objects are assembled to create a more complex object
3. assembly may be physical or logical
4. defines a single point of control for participating
objects
5. the aggregate object coordinates its parts

15. 1. a stricter form of aggregation
2. lifespan of individual objects depend on the on
lifespan of the aggregate object.
3. parts cannot exist on their own
4. there is a create-delete dependency of the parts to the
whole

17. 1. a class that lacks a complete implementation provides
operations without implementing some methods.
2. cannot be used to create objects; cannot be
instantiated
3. a concrete sub-class must provide methods for
unimplemented operations

18. 1. has methods for all operations
2. can be instantiated
3. methods may be:
a) defined in the class or
b) inherited from a super-class

19. Discriminator – an
attribute that defines
sub-classes
Example: “status” of
agency staff is a possible
discriminator to derive
“management”, “senior”
and “junior” sub-classes.

20.  Introduction of Software Development Life Cycle
 Different Views of SDLC
 Process Model used in SDLC
 Unified Process Model

21.  Software is like humans.
 It has a life cycle.
 Software in a system is conceptualized first.
 It becomes obsolescent at the end.
 The period in between is called the software life cycle.

22.  SDLC: process of building, deploying, using, and
updating an information system
 Text focus: initial development project
 Chief variations of SDLC
(a) Predictive: project planned entirely in advance
(b) Adaptive: planning leaves room for contingencies
 Pure approaches to SDLC are rare
 Most projects have predictive and adaptive elements

24.  Five activities or phases in a project
Planning, analysis, design, implementation, support
 Pure waterfall approach (predictive SDLC)
Assumes project phases can be sequentially executed
Project drops over the “waterfall” into the next phase
 Modified waterfall approach
 Tempers pure waterfall by recognizing phase overlap
 Informs many current projects and company systems

27.  When there is uncertainty regarding what’s required or how it can be
built
 Assumes requirements are known before design begins
 sometimes needs experience with product before requirements can be fully
understood
 Assumes requirements remain static over development cycle
 product delivered meets delivery-time needs
 Assumes sufficient design knowledge to build product
 best for well-understood product
 in able to cater software special properties or partially understood issues
 doesn’t emphasize or encourage software reuse
 Problem if environment changes
 request changes in programs

28.  Goal is user satisfaction
 how do we determine system is ready for delivery
 is it now an operational system that satisfies users’needs
 is it correct and operating as we thought it should ?
 Does it pass an evaluation process ?

29.  Test according to
 how it has been built
 what it should do
 4 quality measures
 correspondence
 measures how well delivered system matches needs of operational environment,
as described in original requirements statement
 validation
 task of predicting correspondence (true correspondence only determined after
system is in place)
 correctness
 measures consistency of product requirements with respect to design
specification
 verification
 exercise of determining correctness (correctness objective => always possible to
determine if product precisely satisfies requirements of specification)

31.  Verification
 am I building the product right ?
 Begin after specification accepted
 Validation
 am I building the right product ?
 Subjective - is specification appropriate ? Uncover true users’ needs
, therefore establish proper design ?
 Begins as soon as project starts
 Verification & validation independent of each other
 even if product follows spec, it may be a wrong product if
specification is wrong
 eg: report missing, initial design no longer reflect current needs
 If specification informal, difficult to separate verification and
validation

32.  The spiral model: early form of adaptive SDLC
Activities radiate from center starting point
Prototypes are artifacts of each phase
 Iterative problem solving: repeats activities
 Several approaches to structuring iterations
Define and implement the key system functions
Focus on one subsystem at a time
Define by complexity or risk of certain components
Complete parts incrementally

34.  UP life cycle
Includes (4) phases which consist of iterations
Iterations are “mini-projects”
 Inception: develop and refine system vision
 Elaboration: define requirements and core
architecture
 Construction: continue design and implementation
 Transition: move the system into operational mode

37.  Inception (Make the Business Case)
 Elaboration (Define the system architecture)
 Construction (Construct the system)
 Transition (Integrate the system with the using
organization)

38.  System development methodology
Provides guidelines every activity in system
development
Includes specific models, tools, and techniques
 UP is a system development methodology
 Process is a synonym for methodology
 Methodologies supported with documentation

39.  Model abstract (separate) aspects of the real world
 Models come in many forms
Physical analogs, mathematical, graphical
 System development models are highly abstract
Depict inputs, outputs, processes, data, objects,
interactions, locations, networks, and devices
 Unified Modeling Language (UML): standard notation
 PERT or Gantt charts: model project itself

41.  Tool: software used to create models or components
 Example tools-
o Project management software tools (Microsoft Project)
o Integrated development environments (IDEs)
o Code generators
o Computer-aided system engineering (CASE)

42.  Technique
Collection of guidelines
Enables an analyst to complete an activity or task
 Example techniques
Domain-modeling , use case modeling, software
testing, user-interviewing techniques, relational
database design techniques
 Proven techniques are embraced as “Best Practices”