Introduction - SENG 330. Object-Oriented Analysis and Design

Transcription

1 Introduction - SENG 330 Object-Oriented Analysis and Design

2 SENG 330 Fall 2006 Instructor: Alex Thomo Office hours: Office Hours: TWF 12:30-1:30 p.m. Location: ECS 556 Objective: How to create better object-oriented designs through the application of a set of explainable principles and heuristics. How to implement these designs.

3 SENG 330 Fall 2006 Book: Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design, 3d Edition, by Craig Larman Safari at UVic?

4 Owning a hammer doesn t make one an architect Knowing an OO language is a necessary but insufficient first step to create object systems. Learn skills for creation of well-designed, robust, and maintainable software using OO technologies and languages

5 UML It s a standard diagramming notation it s not a method or procedure on how to think in objects. However, we need it as tool for communicating with others. When working visually, we exploit our brain's strength to quickly grasp symbols, units, and relationships in 2D notations. die1 : Die die2 : Die play() DiceGame 1 2 Die facevalue : int getfacevalue() : int roll()

6 OOD Principles and Patterns Responsibility-driven design: How should responsibilities be assigned to classes of objects? How should objects interact? What classes should do what? Tried-and-true solutions to design problems have been expressed as patterns (or formulas). E.g. Suppose there are multiple third-party tax calculators, and each tax calculator has a different interface: TCP socket, SOAP, Java RMI, CORBA, etc. What objects should be responsible for these varying external tax calculator examples? Solution. We should create tax calculator adapters, which handle all low level details, while presenting the same external interface, e.g. gettaxes( Sale ).

7 Analysis and Design? Analysis emphasizes an investigation of the problem and requirements, rather than a solution. Analysis = requirements analysis + object analysis. Requirement analysis is strongly related to OOA/D as a prerequisite activity. Who will use the system? How will it be used? What are the expectations? Object analysis is about finding domain objects and concepts. Design is a conceptual solution that fulfills the requirements. E.g. a description of software objects, and databases schema. Software objects are inspired by domain objects, but not necessary the same.

8 Object Analysis domain concept Plane tailnumber visualization of domain concept representation in an object-oriented programming language public class Plane { private String tailnumber ; } public List getflighthistory() { }

9 Another Example Dice game: A player rolls two die. If the total is seven, they win; Otherwise, they lose. Analysis Define use cases Define a domain model Design Define interaction diagrams Define design class diagrams

10 Uses Cases Requirement analysis describes domain processes: uses cases Use cases are 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.

11 Domain Model Object oriented analysis identifies: domain objects, concepts, attributes and relationships Result is the domain model.

12 Player 1 Rolls 2 Die name facevalue 1 1 Plays 2 DiceGame 1 Includes

13 OOD: Interaction Diagrams OOD is about defining software objects, their responsibilities and collaborations. A common notation for outlining the above is an interaction diagram.

14 :DiceGame die1 : Die die2 : Die play() roll() fv1 := getfacevalue() roll() fv2 := getfacevalue()

15 Or

16 Static View: Design Class Diagrams It s useful also a static view of the class definitions with design class diagrams (DCD s). DCD s are inspired by the domain model, but the classes aren t necessarily the same. E.g. here is no Player class. If the requirements don t ask to remember anything about the person playing, then there is need for such a class.

17 DiceGame Die die1 : Die die2 : Die play() 1 2 facevalue : int getfacevalue() : int roll()

18 Three levels in applying UML Recommended by agile modeling. UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual languages. UML as blueprint Relatively detailed design diagrams used either for code generation (forward engineering) or for reverse engineering to visualize and better understand existing code UML as programming language Complete executable specification of a software system in UML. Executable code will be automatically generated, but is not normally seen or modified by developers;

19 Three perspectives to Apply UML Conceptual Specification Implementation UML describes raw diagram types, such as class diagrams and sequence diagrams. It does not superimpose a modeling perspective on these. For example, the same UML class diagram notation can be used to draw pictures of concepts in the real world or software classes in Java.

20 Iterative Development and the Unified Process

21 (Rational) Unified Process A software development process describes an approach to Software Building Deploying Maintaining There are many activities comprising the above. Recommended to follow: The Unified Process, A procedure for doing the many possible activities from requirements to implementation, and maintenance.

22 Key UP Idea: Iterative Development An iterative development is organized into a series of short, fixed-length mini-projects called iterations. The outcome of each iteration is a tested, integrated, and executable system. Each iteration includes its own requirement analysis, design, implementation, and testing activities.

23 Each iteration involves choosing a small set of requirements, and quickly designing, implementing, and testing. Feedback is from users, developers, and tests (such as load and usability tests). E.g. Feedback from users or stakeholders: You don t differentiate between products when calculating tax! Feedback from programmers: To print in special purpose paper is a daunting task! Is it worthy? Feedback from tests: To ask GoodAsGoldTaxPro calculator is very slow. (load test)

24 Some facts: Why Iterations? Changes in requirements: 35% - 50% Software development is a domain of high change and instability. Software is not a domain of predictable or mass manufacturing. Change is the constant in software projects. Any analysis, modeling, development, or management practice based on the assumption that things are longterm stable (i.e., the waterfall) is fundamentally flawed.

25 How to do Iterative and Evolutionary Analysis and Design? 1. Before iteration-1, hold the first timeboxed requirements workshop (2 days). Business and development people are present. On the morning of day one, identify the names of the use cases. The analysis will not be perfect. Ask the chief architect and business people to pick 10% from this highlevel list (such as 10% of the 30 use case names), which have a blending of three qualities: 1) architecturally significant 2) high business value (features business really cares about) 3) high risk (such as "be able to handle 500 concurrent transactions"). Perhaps three use cases are identified: UC2, UC11, UC14. For the remaining 1.5 days, do intensive detailed analysis for these three use cases (write them up).

26 How to do Iterative and Evolutionary Analysis and Design? 2. Before iteration-1, hold an iteration planning meeting a subset from UC2, UC11, and UC14 are chosen to design, build, and test within a specified time (for example, four-week timeboxed iteration). 3. Do iteration-1 over four weeks. On the first two days, developers and others do modeling and design work in pairs, sketching UML diagrams at many whiteboards in a common war room Then the developers take off their "modeling hats" and put on their "programming hats." Much testing occurs. One week before the end, ask the team if the original iteration goals can be met; if not, de-scope the iteration, putting secondary goals back on the "to do" list. On Tuesday of the last week there's a code freeze; all code must be checked in, integrated, and tested to create the iteration baseline. On Wednesday morning, demo the partial system to external stakeholders, to show early visible progress. Feedback is requested.

27 UP Phases A UP project organizes the iterations across four major phases: Inception approximate vision, business case, scope, vague estimates. Elaboration refined vision iterative implementation resolution of high risks Construction iterative implementation of lower risk elements Transition beta tests deployment

28

29 UP Disciplines UP describes work activities, such as writing a use case, within disciplines (work-codes). There are several disciplines: Business modeling e.g. domain modeling Requirements e.g. writing use cases Design all aspects of design, e.g. objects, databases, networking etc.

30 Disciplines and phases

31 Case Study: The NextGen POS System

32 A POS System A computerized NextGen point-of-sale (POS) system is to: record sales, and handle payments. It includes H/S components such as: Computer Bar code scanner Software It interfaces to various service applications, such as: Third party tax calculators Inventory control It must support multiple and varied client-side terminals and interfaces, such as: A thin Web browser terminal A regular PC with Java Swing graphical UI Touch screen input Wireless PDA s Furthermore, it should support different clients with different business rules.

33 Business rules When you sell a widget, total the monthly sale figures, and decrease the widget inventory. Only a manager can discount blue widgets by 10%.

34 Architectural Layers Inte rfac e minor focus explore how to connect to other layers application logic and domain object layer Sale Payment primary focus of case study explore how to design objects technical services layer Log PersistenceFacade secondary focus explore how to design objects