1.
OBJECT ORIENTED ANALYSIS
AND DESIGN
BY
USMAN RAFI

2.
OBJECTIVES
• ITERATIVE DEVELOPMENT
• RATIONAL UNIFIED PROCESS
• SEQUENTIAL WATERFALL MODEL

3.
ITERATIVE DEVELOPMENT
• SKILLFUL DEVELOPMENT APPROACH LIKE UNIFIED PROCESS FOR SOFTWARE
DEVELOPMENT
• SOFTWARE DEVELOPMENT PROCESS DESCRIBES AN APPROACH FOR
DEVELOPING, MAINTAINING AND REPLACING A SOFTWARE SYSTEM
• UNIFIED PROCESS ESPECIALLY RATIONAL UNIFIED PROCESS (RUP)
CONTRIBUTED A LOT IN ITERATIVE SOFTWARE DEVELOPMENT
• UNIFIED PROCESS COMBINES COMMONLY ACCEPTED BEST PRACTICES, SUCH
AS AN ITERATIVE LIFECYCLE AND RISK-DRIVEN DEVELOPMENT, INTO A
COHESIVE AND WELL-DOCUMENTED DESCRIPTION

4.
UNIFIED PROCESS
• MOTIVATION: ITERATIVE DEVELOPMENT
• WORK PROCEEDS THROUGH A SERIES OF STRUCTURED BUILD-FEEDBACK-
ADAPT CYCLES

5.
ITERATIVE DEVELOPMENT APPROACH
• IN THIS APPROACH, DEVELOPMENT IS ORGANIZED INTO A SERIES OF SHORT, FIXED-
LENGTH (FOR EXAMPLE, FOUR WEEK) MINI-PROJECTS CALLED ITERATIONS
• THE OUTCOME OF EACH IS A TESTED, INTEGRATED, AND EXECUTABLE SYSTEM
• EACH ITERATION INCLUDES ITS OWN REQUIREMENTS ANALYSIS, DESIGN,
IMPLEMENTATION, AND TESTING ACTIVITIES
• THE ITERATIVE LIFECYCLE IS BASED ON THE SUCCESSIVE ENLARGEMENT AND
REFINEMENT OF A SYSTEM THROUGH MULTIPLE ITERATIONS, WITH CYCLIC
FEEDBACK AND ADAPTATION AS CORE DRIVERS TO CONVERGE UPON A SUITABLE
SYSTEM
• THE SYSTEM GROWS INCREMENTALLY OVER TIME, ITERATION BY ITERATION, AND
THUS THIS APPROACH IS ALSO KNOWN AS ITERATIVE AND INCREMENTAL
DEVELOPMENT

6.
ITERATIVE DEVELOPMENT PROCESS

7.
EXAMPLE

8.
EXAMPLE – DISCUSSION
• NOTICE IN THIS EXAMPLE THAT THERE IS NEITHER A RUSH TO CODE, NOR A
LONG DRAWN-OUT DESIGN STEP THAT ATTEMPTS TO PERFECT ALL DETAILS
OF THE DESIGN BEFORE PROGRAMMING
• A "LITTLE" FORETHOUGHT REGARDING THE DESIGN WITH VISUAL MODELING
USING ROUGH AND FAST UML DRAWINGS IS DONE; PERHAPS A HALF OR FULL
DAY BY DEVELOPERS DOING DESIGN WORK IN PAIRS

9.
ITERATIVE DEVELOPMENT APPROACH
• THE RESULT OF EACH ITERATION IS AN EXECUTABLE BUT INCOMPLETE SYSTEM; IT IS
NOT READY TO DELIVER INTO PRODUCTION
• THE SYSTEM MAY NOT BE ELIGIBLE FOR PRODUCTION DEPLOYMENT UNTIL AFTER
MANY ITERATIONS
• THE OUTPUT OF AN ITERATION IS NOT AN EXPERIMENTAL OR THROW-AWAY
PROTOTYPE
• ITERATIVE DEVELOPMENT IS NOT PROTOTYPING RATHER THE OUTPUT IS A
PRODUCTION-GRADE SUBSET OF THE FINAL SYSTEM
• IN GENERAL, EACH ITERATION TACKLES NEW REQUIREMENTS AND INCREMENTALLY
EXTENDS THE SYSTEM, AN ITERATION MAY OCCASIONALLY REVISIT EXISTING
SOFTWARE AND IMPROVE IT

10.
ITERATIVE DEVELOPMENT APPROACH
• EACH ITERATION INVOLVES CHOOSING A SMALL SUBSET OF THE REQUIREMENTS,
AND QUICKLY DESIGNING, IMPLEMENTING, AND TESTING
• IN EARLY ITERATIONS THE CHOICE OF REQUIREMENTS AND DESIGN MAY NOT BE
EXACTLY WHAT IS ULTIMATELY DESIRED
• BUT THE ACT OF SWIFTLY TAKING A SMALL STEP, BEFORE ALL REQUIREMENTS ARE
FINALIZED, OR THE ENTIRE DESIGN IS SPECULATIVELY DEFINED, LEADS TO RAPID
FEEDBACK FROM THE USERS, DEVELOPERS, AND TESTS
• THE FEEDBACK FROM REALISTIC BUILDING AND TESTING SOMETHING PROVIDES
CRUCIAL PRACTICAL INSIGHT AND AN OPPORTUNITY TO MODIFY OR ADAPT
UNDERSTANDING OF THE REQUIREMENTS OR DESIGN

11.
WHY THIS APPROACH?
• EMBRACING CHANGE: FEEDBACK AND ADAPTATION
• RATHER THAN FIGHTING THE INEVITABLE CHANGE THAT OCCURS IN
SOFTWARE DEVELOPMENT BY TRYING (USUALLY UNSUCCESSFULLY) TO FULLY
AND CORRECTLY SPECIFY, FREEZE, AND "SIGN OFF" ON A FROZEN
REQUIREMENT SET AND DESIGN BEFORE IMPLEMENTATION
• ITERATIVE DEVELOPMENT IS BASED ON AN ATTITUDE OF EMBRACING
CHANGE AND ADAPTATION AS UNAVOIDABLE AND INDEED ESSENTIAL
DRIVERS

12.
ITERATIONS AND CHANGE

13.
BENEFITS OF ITERATIVE DEVELOPMENT
• EARLY RATHER THAN LATE MITIGATION OF HIGH RISKS (TECHNICAL,
REQUIREMENTS, OBJECTIVES, USABILITY)
• EARLY VISIBLE PROGRESS
• EARLY FEEDBACK, USER ENGAGEMENT, AND ADAPTATION, LEADING TO A
REFINED SYSTEM THAT MORE CLOSELY MEETS THE REAL NEEDS OF THE
STAKEHOLDERS
• MANAGED COMPLEXITY; THE TEAM IS NOT OVERWHELMED BY "ANALYSIS
PARALYSIS" OR VERY LONG AND COMPLEX STEPS
• THE LEARNING WITHIN AN ITERATION CAN BE METHODICALLY USED TO
IMPROVE THE DEVELOPMENT PROCESS ITSELF, ITERATION BY ITERATION

14.
ITERATION LENGTH
• THE UP (AND EXPERIENCED ITERATIVE DEVELOPERS) RECOMMENDS AN
ITERATION LENGTH BETWEEN TWO AND SIX WEEKS
• SMALL STEPS, RAPID FEEDBACK, AND ADAPTATION ARE CENTRAL IDEAS IN
ITERATIVE DEVELOPMENT
• A VERY LONG ITERATION MISSES THE POINT OF ITERATIVE DEVELOPMENT

15.
TIME-BOXING
• A KEY IDEA IS THAT ITERATIONS ARE TIMEBOXED, OR FIXED IN LENGTH
• FOR EXAMPLE, IF THE NEXT ITERATION IS CHOSEN TO BE FOUR WEEKS LONG,
THEN THE PARTIAL SYSTEM SHOULD BE INTEGRATED, TESTED, AND
STABILIZED BY THE SCHEDULED DATE
• DATE SLIPPAGE IS DISCOURAGE
• IF IT SEEMS THAT IT WILL BE DIFFICULT TO MEET THE DEADLINE, THE RECOM-
MENDED RESPONSE IS TO REMOVE TASKS OR REQUIREMENTS FROM THE
ITERATION, AND INCLUDE THEM IN A FUTURE ITERATION, RATHER THAN SLIP
THE COMPLETION DATE

16.
UNIFIED PROCESS – BEST PRACTICES AND CONCEPTS
• ITERATIVE DEVELOPMENT
• TIME-BOXED ITERATIONS
• USE OF OBJECT-ORIENTED TECHNOLOGIES
• TACKLE HIGH-RISK AND HIGH-VALUE ISSUES IN EARLY ITERATIONS
• CONTINUOUSLY ENGAGE USERS FOR EVALUATION, FEEDBACK, AND REQUIREMENTS
• CONTINUOUSLY VERIFY QUALITY; TEST EARLY, OFTEN, AND REALISTICALLY
• APPLY USE CASES
• MODEL SOFTWARE VISUALLY USING UML
• CAREFULLY MANAGE REQUIREMENTS
• PRACTICE CHANGE REQUEST AND CONFIGURATION MANAGEMENT

17.
DISCIPLINE, ARTIFACT AND WORKFLOWS
• DISCIPLINE IS A SET OF ACTIVITIES (AND RELATED ARTIFACTS) IN ONE SUBJECT
AREA
• REQUIREMENT ANALYSIS ACTIVITY
• ARTIFACT IS THE GENERAL TERM FOR ANY WORK PRODUCT
• CODE, WEB GRAPHICS, DATABASE SCHEMA, TEXT DOCUMENTS,
DIAGRAMS, MODELS
• WORKFLOWS ARE WORK ACTIVITIES WITHIN A DISCIPLINE
• WRITING A USE CASE

18.
DISCIPLINES IN UNIFIED PROCESS
• BUSINESS MODELING—WHEN DEVELOPING A SINGLE APPLICATION, THIS
INCLUDES DOMAIN OBJECT MODELING. WHEN ENGAGED IN LARGE-SCALE
BUSINESS ANALYSIS OR BUSINESS PROCESS REENGINEERING, THIS INCLUDES
DYNAMIC MODELING OF THE BUSINESS PROCESSES ACROSS THE ENTIRE
ENTERPRISE
• REQUIREMENTS—REQUIREMENTS ANALYSIS FOR AN APPLICATION, SUCH AS
WRITING USE CASES AND IDENTIFYING NON-FUNCTIONAL REQUIREMENTS
• DESIGN—ALL ASPECTS OF DESIGN, INCLUDING THE OVERALL ARCHITECTURE,
OBJECTS, DATABASES, NETWORKING, AND THE LIKE
• IMPLEMENTATION—PROGRAMMING AND BUILDING THE SYSTEM, NOT
DEPLOYMENT

19.
DISCIPLINES IN UNIFIED PROCESS

20.
DISCIPLINES AND PHASES

21.
INCREMENTAL OOA/OOD

22.
THE DEVELOPMENT CASE
• THE CHOICE OF UP ARTIFACTS FOR A PROJECT MAY BE WRITTEN UP IN A
SHORT DOCUMENT CALLED THE DEVELOPMENT CASE
• EXAMPLE:
• A WEB-BASED E-COMMERCE SYSTEM MAY REQUIRE A FOCUS ON USER
INTERFACE PROTOTYPES
• A MACHINE CONTROL SYSTEM MAY BENEFIT FROM DOING MANY STATE
DIAGRAMS

23.
ARTIFACTS

24.
RATIONAL UNIFIED PROCESS (RUP)
• RUP IS A COMPLETE SOFTWARE-DEVELOPMENT PROCESS FRAMEWORK ,
DEVELOPED BY RATIONAL CORPORATION
• IT’S AN ITERATIVE DEVELOPMENT METHODOLOGY BASED UPON SIX
INDUSTRY-PROVEN BEST PRACTICES
• PROCESSES DERIVED FROM RUP VARY FROM LIGHTWEIGHT—ADDRESSING
THE NEEDS OF SMALL PROJECTS —TO MORE COMPREHENSIVE PROCESSES
ADDRESSING THE NEEDS OF LARGE, POSSIBLY DISTRIBUTED PROJECT TEAMS

25.
PHASES OF RUP
• INCEPTION
• ELABORATION
• CONSTRUCTION
• TRANSITION

26.
PHASES OF RUP

27.
ITERATIONS
• EACH PHASE HAS ITERATIONS, EACH HAVING THE PURPOSE OF PRODUCING A
DEMONSTRABLE PIECE OF SOFTWARE
• THE DURATION OF ITERATION MAY VARY FROM TWO WEEKS OR LESS UP TO
SIX MONTHS
Inception Elaboration Construction Transition
Iterations Iterations IterationsIterations

28.
INCEPTION
• THE LIFE-CYCLE OBJECTIVES OF THE PROJECT ARE STATED, SO THAT THE
NEEDS OF EVERY STAKEHOLDER ARE CONSIDERED
• SCOPE AND BOUNDARY CONDITIONS, ACCEPTANCE CRITERIA AND SOME
REQUIREMENTS ARE ESTABLISHED

29.
INCEPTION - ACTIVITIES
• FORMULATE THE SCOPE OF THE PROJECT
• NEEDS OF EVERY STAKEHOLDER, SCOPE, BOUNDARY CONDITIONS AND
ACCEPTANCE CRITERIA ESTABLISHED.
• PLAN AND PREPARE THE BUSINESS CASE
• DEFINE RISK MITIGATION STRATEGY, DEVELOP AN INITIAL PROJECT PLAN AND
IDENTIFY KNOWN COST, SCHEDULE, AND PROFITABILITY TRADE-OFFS.
• SYNTHESIZE CANDIDATE ARCHITECTURE
• CANDIDATE ARCHITECTURE IS PICKED FROM VARIOUS POTENTIAL
ARCHITECTURES
• PREPARE THE PROJECT ENVIRONMENT
• INVOLVES SETTING UP DEVELOPMENT ENVIRONMENT AND SETTING UP THE
PROCESS

30.
ELABORATION
• AN ANALYSIS IS DONE TO DETERMINE THE RISKS, STABILITY OF VISION OF
WHAT THE PRODUCT IS TO BECOME, STABILITY OF ARCHITECTURE AND
EXPENDITURE OF RESOURCES

31.
ELABORATION – ACTIVITIES
• DEFINE THE ARCHITECTURE
• PROJECT PLAN IS DEFINED. THE PROCESS, INFRASTRUCTURE AND DEVELOPMENT
ENVIRONMENT ARE DESCRIBED
• VALIDATE THE ARCHITECTURE
• ENSURE THAT THE DEVELOPED ARCHITECTURE WILL FULFILL THE
REQUIREMENTS
• BASELINE THE ARCHITECTURE
• TO PROVIDE A STABLE BASIS FOR THE BULK OF THE DESIGN AND
IMPLEMENTATION EFFORT IN THE CONSTRUCTION PHASE

32.
CONSTRUCTION
• THE CONSTRUCTION PHASE IS A MANUFACTURING PROCESS
• IT EMPHASIZES MANAGING RESOURCES AND CONTROLLING OPERATIONS TO
OPTIMIZE COSTS, SCHEDULES AND QUALITY
• THIS PHASE IS BROKEN INTO SEVERAL ITERATIONS

33.
CONSTRUCTION – ACTIVITIES
• DEVELOP AND TEST COMPONENTS
• COMPONENTS REQUIRED SATISFYING THE USE CASES, SCENARIOS, AND OTHER
FUNCTIONALITY FOR THE ITERATION ARE BUILT
• UNIT AND INTEGRATION TESTS ARE DONE ON COMPONENTS
• MANAGE RESOURCES AND CONTROL PROCESS
• ASSESS THE ITERATION
• SATISFACTION OF THE GOAL OF ITERATION IS DETERMINED.

34.
TRANSITION
• THE TRANSITION PHASE IS THE PHASE WHERE THE PRODUCT IS PUT IN THE
HANDS OF ITS END USERS
• IT INVOLVES ISSUES OF MARKETING, PACKAGING, INSTALLING, CONFIGURING,
SUPPORTING THE USER-COMMUNITY, MAKING CORRECTIONS, ETC

35.
TRANSITION – ACTIVITIES
• TEST THE PRODUCT DELIVERABLE IN A CUSTOMER ENVIRONMENT
• FINE TUNE THE PRODUCT BASED UPON CUSTOMER FEEDBACK
• DELIVER THE FINAL PRODUCT TO THE END USER
• FINALIZE END-USER SUPPORT MATERIAL

36.
ADVANTAGES OF RUP
• THE RUP PUTS AN EMPHASIS ON ADDRESSING VERY EARLY HIGH RISKS AREAS
• IT DOES NOT ASSUME A FIXED SET OF FIRM REQUIREMENTS AT THE
INCEPTION OF THE PROJECT, BUT ALLOWS TO REFINE THE REQUIREMENTS AS
THE PROJECT EVOLVES
• IT DOES NOT PUT EITHER A STRONG FOCUS ON DOCUMENTS
• THE MAIN FOCUS REMAINS THE SOFTWARE PRODUCT ITSELF, AND ITS
QUALITY

37.
THE SEQUENTIAL WATERFALL MODEL
• IN CONTRAST TO THE ITERATIVE LIFECYCLE OF THE UP, AN OLD ALTERNATIVE
WAS THE SEQUENTIAL, LINEAR, OR "WATERFALL" LIFECYCLE
• IT DEFINED STEPS SIMILAR TO THE FOLLOWING
• CLARIFY, RECORD, AND COMMIT TO A SET OF COMPLETE AND FROZEN
REQUIREMENTS
• DESIGN A SYSTEM BASED ON THESE REQUIREMENTS
• IMPLEMENT, BASED ON THE DESIGN