Introduction to OOA and OOD

1. Introduction to OOA and OOD > Spring 2010, Amirkabir university, CS department Amin Gheibi

2. Topics

3. Why • Owning a hammer doesn't make one an architect • Knowing an object-oriented language (hammer) is a necessary but insufficient first step to create object systems. • Knowing how to "think in objects" is also critical.

4. UML • The UML is a de facto standard diagramming notation. • software blueprints • Is a language as a tool of thought and as a form of communication with others • Case tools

5. OOAD • How should responsibilities be allocated to classes of objects? • How should objects interact? • What classes should do what? • tried-and-true solutions

6. Analysis • Analysis emphasizes an investigation of the problem and requirements, rather than a solution. • A broad term, best qualified: • requirements analysis • object analysis (domain objects) • OOA emphasis on finding and describing the objects—or concepts—in the problem domain

7. Design • Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. • best qualified: • object design • database design • OOD emphasis on defining software objects and how they collaborate to fulfill the requirements

8. An Example (Dice Game) • Take a quick look at the steps.

9. An Example (Dice Game) • First Step is describing related domain processes; • these can be written as use cases • Use cases are not an object-oriented artifact—they are simply written stories • Example: • Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose.

10. An Example (Dice Game)

11. An Example (Analysis) • Creating a description of the domain from the perspective of classification by objects • A decomposition of the domain involves an identification of the concepts, attributes, and associations that are considered noteworthy

12. An Example (Domain Model)

13. An Example (Dice Game)

14. An Example (Interaction)

15. An Example (Interaction) • Software object designs and programs do take some inspiration from real-world domains, but they are not direct models or simulations of the real world

16. An Example (Static View)

17. An Example (Static View)

18. Questions ?

19. Iterative Development and Unified Process

20. Iterative development • Development is organized into a series of short, fixed-length mini-projects called iterations • The outcome of each is a tested, integrated, and executable system (except INCEPTION phase). • Each iteration includes its own requirements analysis, design, implementation, and testing activities.

21. Iterative development

22. Embracing Changes • Rather than fighting the inevitable change • correctly specify, freeze, and "sign off" on a frozen requirement set and design before implementation, • Accept adaptation • It does not encourages an uncontrolled and reactive "feature creep"-driven process • Leads to quick and cyclic feedback

23. Iterative development

24. Benefits • Early rather than late mitigation of high risks • Early visible progress • User engagement • It’s good but I want something new • Early feedback • Managed complexity • Learning within an iteration

25. Additional UP practices • High-risk: first-in • Using OO technology • apply use cases • model software visually • carefully manage requirements • practice change request and configuration management • continuously verify quality;

26. UP phases and schedule-oriented

27. Phases • Inception: approximate vision, scope, vague estimates. • Elaboration: refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. • Construction iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.

28. Phases 4. Transition: beta tests, deployment

29. Phases • It is not waterfall • Inception: feasibility phase • Elaboration: core architecture is iteratively implemented, and high risk issues are mitigated.

30. Some definition • Discipline • Artifact • Functional and non-functional requirements

31. Disciplines

32. Disciplines • Business Modeling: domain object modeling, dynamic modeling of the business processes • Requirements analysis: 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.

33. Process Customization • All activities and artifacts are optional, like a set of medicines in a pharmacy • a team should select a small subset of artifacts that address its particular problems and needs. • The choice of UP artifacts for a project may be written up in a short document called the Development Case

34. HeavyWeight vs. Agile • Predictive vs. adaptive • Formal documentation vs. readable code • Large-scale team vs. small-scale • Central Management vs. Distributed Mng. • Detailed exhaustive planning vs. iterative planning • Some samples: AUP, XP

35. Questions ?

36. Case study • POS (point of sale) system is a computerized application used to record sales and handle payments. • It includes hardware components (a computer and bar code scanner), and a software (client-server). • It interfaces to various service applications (tax calculator and inventory control).

37. IBM sample (retail solution)

38. hp POS (loaded with MS Point of Sale software)

39. Case study • multiple and varied client-side terminals • Web client • Windows client • PDA • we will need a mechanism to provide flexibility and customization for each customer business

40. Case study (Architecture)