Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN

2. Chapter 1OBJECT-ORIENTED ANALYSIS AND DESIGN “Time is a great teacher, but unfortunately it kills all its pupils.” - Hector Berlioz Objectives Describe the book goals and scope Define OOA/D (Object-Oriented Analysis and Design) Illustrate a brief OOA/D example Overview UML and visual agile modeling

3. Applying UML and Patterns Larman’s book is a tool to help developers/students learn core skills in OOA/D. • These skills are essential for the creation of well-designed, robust, and maintainable software using OO technologies and languages such as Java or C#. • Knowing an object oriented language is necessary but insufficient first step to create object systems. Knowing how to “think in objects” is critical ! Owning a hammer doesn’t make one an architect” (Proverb)

4. OOA / D Patterns UML notation Topics and Skills Principles and Requirements guidelines analysis Iterative development with an agile Unified Process Fig. 1.1 Topics and skills covered in the book. The book illustrates this in the context of long-running case studies that evolve over several iterations.

5. Analysis • Analysis emphasizes an investigation of the problem and requirements, rather than a solution. • In software development, we are primarily concerned with two forms of analysis. • Requirements Analysis is discovering the requirements that a system must meet in order to be successful. • Object-Oriented Analysis is investigating the objects in a domain to discover information important to meet the requirements.

6. Use Cases • Writing Use Cases is not a specifically OOartifact – they are simply written stories. • However, they are a best practice for elaborating and understanding requirements.

7. Design • Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. • Design ideas often exclude low-level or obvious details – obvious to the intended consumers. • There are subsets of design, including • architectural design, • object design, • database design. • Do the right thing (analysis), and do the thing right (design).

8. Object-Oriented Analysis and Design (OOA/D) • During OOA, the emphasis is on finding and describing the objects (or concepts) in the problem domain, i.e., domain objects. • During OOD (or simply object design), the emphasis is on defining software objects and how they collaborate to fulfill the requirements. • During OOP (OO Programming)or Implementation, design objects are implemented in a programming language. • Implementation is also known as Coding or Construction.

9. Fig. 1.2 Object-orientation emphasizes representation of objects

10. Responsibility-Driven Design • It is the classical OO design metaphor(symbol) • The most important skill in OOA/D is assigning responsibilities to objects. • That determines how objects interact and what classes should perform what operations.

11. Design Patterns • Certain tried-and-true solutions to design problems have been expressed as principles of best practice, often in the form of Design Patterns. • A Design Pattern is a named problem solution formula that apply excellent design principles.

12. The Unified Process (UP) • A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development. • Requirements analysis and OOA/D needs to be presented and practiced in the context of some development process. • Here, an agile (light, flexible) approach to well-known Unified Process (UP) is used as a sample iterative development process.

13. Unified Modeling Language (UML) • UML is the defactostandard diagramming notation for drawing or presenting pictures related to OO software. • UML is a visual language for specifying, constructing and documenting the artifacts of OO systems. • Knowing UML helps you communicate with others in creating software.

14. Three ways people apply UML are ... • UML as sketch • Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space • Agile modeling emphasizes UML as sketch. • UML as blueprint • relatively detailed design diagrams used either for reverse engineeringto visualize and better understand existing code, • or for forward engineeringto guide for code generation, either manually or automatically with a tool. • UML as a programming language • Complete executable specification of a sw system in UML.

15. Three perspectives to apply UML are ... • Conceptual perspective – the diagrams are interpreted as describing things in a situation of the real world or domain of interest. • Specification (software) perspective – the diagrams describe sw abstractions or components with specifications and interfaces, but no commitment to a particular language implementation. • Implementation perspective – the diagrams describe sw implementations in a particular technology.

16. Fig. 1.6 Different perspectives with UML In practice, most software-oriented UML diagramming assumes an implementation perspective and the specification perspective is often used for design.

17. The meaning of “class” in different perspectives • Conceptual class – real-world concept or thing. A conceptual or essential perspective. • The UP Domain Model contains conceptual classes. • Software class – a class representing a specification or implementation perspective of a sw development, regardless of the process or method. • Implementation class – a class implemented in a specific OO language such as Java.

18. A Short Example OOA/D steps of a small “Dice Game”: • Define Use Cases • Define a Domain Model • Define Interaction Diagrams • Define Design Class Diagrams

19. Use Case: Play a Dice Game Define Use Cases • Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise, player loses.

20. Define a Domain Model Fig. 1.3 Partial domain model (conceptual object model) of the dice game Domain model shows the noteworthy domain concepts as objects, their attributes, and associations.

21. Define Object Responsibilities and Draw Interaction Diagrams Fig. 1.4 Sequence diagram illustrating messages between software objects

22. Fig. 1.4 Sequence diagram illustrating messages between software objects A sequence diagram (a kind of UML interaction diagram) shows the flow of messages between software objects and thus the invocation of objects.

23. Define Design Class Diagrams Fig. 1.5 Partial design class diagram (software classes) A static view of the class (including its attributes and methods) definitions is usefully shown with a UML class diagram.

24. Chapter 2ITERATIVE, EVOLUTIONARY, AND AGILE “You should use iterative development only on projects that you want to succeed.” - Martin Fowler Objectives • Provide motivation for the content and order of the book • Define an iterative and agile process • Define fundamental concepts in the Unified Process.

25. Waterfall (Sequential) Lifecycle • promotes big up-front “speculative” requirements and design steps before programming. • was historically promoted due to belief or hearsay rather than statistically significant evidence.* • Success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects. • On average, 45% of the features are never used, and early schedules and estimates vary up to 400% from the actuals. * We should approach tothe author’s such claims very carefully! [KD]

26. Why the waterfall lifecycle fails? • The key false assumption: • The specifications are predictable and stable and can be correctly defined at the start, with low change rates. • But change is a constant on software projects. • A typical software project experienced a 25% change in requirements (Boehm and Papaccio 1988)

27. Fig. 2.3 Percentage of change on software projects of varying sizes. (Jones 1997)

28. Iterative and Evolutionary Development • involves early programming and testing of a partial system, in repeating cycles. • relies on short quick development steps (or iterations), feedback and adaptation to clarify the requirements and design so successively enlarging and refining a system. • normally assumes that the development starts before all requirements are defined in detail, feedback is used to clarify and improve the evolving specifications. • Each iteration will include requirements, analysis, design, implementation, and test. Current research demonstrates that iterative methods are associated with higher success and productivity rates, and lower defect levels.*

29. Fig. 2.2 Iterative feedback and evolution leads towards the desired system. The requirements and design instability lowers over time.

30. Timeboxing • A key idea is that iterations are timeboxed, or fixed in length. • Most iterative methods recommend in iteration length bw 2 – 6 weeks. • If it seems that it will be difficult to meet the deadline, the recommended response is to de-scope • De-scoping: removing tasks or requirements from the iteration, and including them in a future iteration, rather than slipping the completion date.

31. Fig. 2.1 Iterative and Evolutionary Development (also known as iterative and inceremental development; spiral development and evolutionary development) Requirements Requirements Feedback from iteration N Leads to refinement and adaptation of The requirements and design in İteration N+1 Design Design Time Implementation& Test&Integration&More Design Implementation& Test&Integration&More Design Final Integration & System Test Final Integration & System Test Each iteration is an executable but incomplete system; A subset of the final system (but not a throw-away prototype!) 3 weeks ( for example) The system grows incrementally Iterations are fixed in length or timeboxed. .

32. Fig. 2.4 Evolutionary analysis and design – the majority in early iterations. 1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20 - s s iteration project . e e t t r r n n a a e e w w m m t t In evolutionary iterative f f e e o o r r i i s s development , the u u q q requirements evolve e e r r over a set of the early iterations , through a series of requirements 90 % 90 % workshops ( for example ). Perhaps after four iterations and 50 % workshops , 90 % of the requirements are 30 % 20 % 20 % defined and refined . 10 % 5 % 8 % Nevertheless , only 2 % 10 % of the software is Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 built . week 1 M week 2 week 3 T W Th F M T W Th F M T W Th F next de - scope final check - in demo and team agile start kickoff meeting iteration iteration and code - 2 - day modeling & coding & clarifying iteration planning goals if freeze for the requirements design , testing goals with the team . meeting ; too much iteration workshop UML 1 hour 2 hours work baseline whiteboard sketching . Most OOA / D and 5 hours Use - case modeling applying UML during during the workshop this period

33. Build-Feedback-Adapt Cycles In complex changing systems,feedback and adaptation are key ingredients for success: • Feedback from early development, programmers trying to read specifications, and client demos • to refine the requirements. • Feedback from tests and developers • to refine the design and models. • Feedback from the progress of the team tackling early features • to refine the schedule and estimates. • Feedback from the client and marketplace to re-prioritize the features • to tackle in the next iteration.

34. Benefits to Iterative Development • Less project failure, better productivity, and lower defect rates • Early rather than late mitigation of high risks • Early visible progress • Early feedback, user engagement, and adaptation • 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.

35. The Unified Process (UP) • A software development process describes an approach to building, deploying, and possibly maintaining software. • UP has emerged as a popular and effective iterative software development process for building OO systems. • In particular, the Rational Unified Process, as modified at Rational Software, is widely practiced and adopted by industry.

36. Unified Process (UP) • encourages a combination of risk-driven and client-driven iterative planning. • The goals of the early iterations are chosen to • Identify and drive down the highest risks. • Includes the practice of architecture-centric iterative development - Early iterations focus on building, testing, and stabilizing the core architecture. • Tackles the difficult things first. • Build visible features that the client cares most about.

37. Advantages of UP • The UP 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 or ‘ceremonies’ • The main focus remains the software product itself, and its quality.

38. Fig. 2.6 Schedule-oriented terms in the UP

39. UP Best Practices • Get high risk and high value first • Constant user feedback and engagement • Early cohesive core architecture • Test early, often, and realistically • Apply use cases where needed • Do some visual modeling with UML • Manage requirements and scope creep • Manage change requests and configuration

40. UP Phases 1 Inception • Inception is not a requirements phase; rather a feasibility phase, where just enough investigation is done to support a decision to continue or stop. • 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. • Approximate vision, business case, scope, vague estimates. 2 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. • Refined vision, iterative implementation of core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.

41. UP Phases (2) 3 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. • Iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. 4 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. • Beta tests, deployment.

42. Fig. 2.7 UP disciplines

44. Business Modeling Discipline • The purpose of this discipline is to model the business context and the scope of your system. • This is done usually in Inception and Elaboration phase. • Activities include the development of: • A context model showing how the system fits into its overall environment • A high-level business requirements model eg. use case model • A domain model e.g. class diagram or data diagram depicting major business classes or entities • A business process model

45. Requirements Discipline • The purpose of this discipline is to engineer the requirements for the project, including their identification, modeling, and documentation. • The main deliverable of this discipline is the Software Requirements Specification (SRS), also referred to as the Requirements Model, which encompasses the captured requirements.

46. Analysis & Design Discipline • The purpose of this discipline is to evolve a robust architecture for the system based on the requirements, to transform the requirements into a design, and to ensure that implementation environment issues are reflected in the design.

47. Environment Discipline • The purpose of this discipline is to support development work. Practically all the work in this workflow are done in Inception phase. • The activities include -implementing and configuring UP , selecting and acquiring required tools, developing in-house tools - providing software and hardware maintenance and training.

48. Agile Methods and Attitudes • Agile development methods usually • apply timeboxed iterative and evolutionary development, • employ adaptive planning, • promote incremental delivery, • and include other values and practices that encourage agility – rapid and flexible response to change.

49. Existing Agile Methods • Rational Unified Process (RUP) • Extreme Programming (XP) • Feature Driven Development (FDD) • Scrum • Open source software development • Crystal Family of Methodologies • Dynamic Systems Development Methods • Adaptive software development • Agile Modeling • Pragmatic Programming

50. The Agile Manifesto • In 2001 a group interested in iterative and agile methods met to find common ground. Out of this came the Agile Alliance with a manifesto and statement of principles to capture the spirit of agile methods: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan