Solving the Problem

1. Solving the Problem Analysis & Design

2. Requirements PhaseRequirements -- should be an unambiguous description of the external behavior of the system to be built Typical problems : • Contains embedded design decisions (How vs. What). • Vague (must be measurable / testable) • Computer industry language (instead of user's language) • Requirements are not traceable to the system developed

3. Analysis Phase Discover and understand the problem domain • Object-oriented Analysis • decompose a problem by selecting relevant concepts from the vocabulary of the domain. • Develop a Conceptual Model • include class and interaction diagrams.

4. Conceptual Model • contains important real-world conceptsand associations in the vocabulary of the problem domain: includes objects, roles, events, interactions • becomes the foundation for the class model

5. Use Cases • A purposeful user interaction with a system • A narrative description of a sequence of actions required to produce something of value to an actor or organization

6. Use Cases • describe functional requirements of the system • give a clear description of needed system behavior • help customer and developer agree on what the system should do • provide a basis for performing verification tests. • trace requirements to actual classes and operations in the system. • set bounds on the problem space

7. High-level use cases(collected to determine the complete scope of the system) • Use Case – the name is usually a business or domain process (Order a product, register for courses) • Actors -- external agent (person playing a role, computer system, input/output device) • Type -- primary, secondary or optional • Description -- a short narrative description (2 - 3 sentences)

8. Setting Priorities (rank order use cases) • Ranking may involve a combined score including multiple factors: • Impact on the architectural design • Risky, time-critical, or complex functions • New or risky technology • Represent line-of- business processes • Directly support increased revenue or decreased costs. • Or ranking may simply classify use cases as high, medium, or low • The most important use case is then expanded

9. Expanded Use Case(minimal technology references)

10. Object Oriented Design (OOD) Phase • Developer decides how the system will be implemented • Many of the concepts become classes • The design phase elaborates (adds attributes and methods) to the class model • Try this technique • Modify the use case to include new system features

11. Put new system features into the use case

12. Design a User Interface for the user

13. Use screen navigation diagramswhen necessary

14. Plan the first Iteration • Determine how much can be delivered within the first development cycle If necessary, create a simplified use case to fit the first time-box

15. Special Considerations for the first Development Cycle • Try to handle the most difficult parts of the system first. • If the architecture is untested, exercise the functionality of the architecture. • If there is technological risk, exercise all the significant interfaces and interactions among subsystems to assure they are compatible.

16. Architecture – describes the structure of software systems • Architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces. • Describe major subsystems • External software interfaces • User interface • Database organization • Data storage • Key algorithms • Concurrency • Security • Networking • Portability • Programming language • Error handling

17. Plan Future Cycles • In subsequent development cycles, • add functionality to the previously delivered use case or do another use case • update task assignments and milestones for each cycle: • Requirements • Design • User documentation • Test cases • Technical reviews • etc

18. First Cycle: Simplified Use Case

19. Make a minimum conceptual model • concepts relevant to the use case being developed. • A complete conceptual model would be all significant real-world concepts in the problem domain.

20. Find domain concepts in the use case • Who are the actors and what are they trying to do? • What “real world” objects are needed for each use case? • How do the objects work together to complete each use case goal? • Consult with domain experts • Parse for noun and verb phrases • Nouns become objects or attributes • Verbs become operations or associations. • Use a Concept Check List

21. Physical objects Specifications, designs or descriptions of things Places Transactions Transaction line items Roles Things in a container Containers of other things Catalogs Events Organizations Processes Rules and policies Records of finance, work, contracts, legal matters Financial instruments and services Manuals, books External Computer Systems or devices Abstract noun concepts Concept Check List (Craig Larman)

22. Concept Diagram of Buy Items

23. Decide which domain concepts become objects that implement a solution • Try CRC cards to Bridge from Concepts to ClassesCRC cards (Class, Responsibility, Collaboration) • Original paper by Beck and Cunningham at http://c2.com/doc/oopsla89/paper.html

24. CRC Cards • Class Name -- Domain concept or programmer created class • Responsibilities -- Tasks an object can do alone because of its local knowledge • Collaborators -- Tasks done by other objects because of their knowledge

25. Responsibility Responsibilities become class methods • The method accomplishes a task by the object acting alone or with the help of others. Two Basic Responsibilities for objects • Knowing • object’s awareness of its own data, its links to other objects and knowledge it can derive or calculate • Doing • objects ability to modify itself, create and link to other objects, or delete other objects and links, command other objects to take action or control or coordinate activity in other objects

26. CRC Card Procedure • Create cards for each relevant object in the use case -- actors initiating a message to the system -- the first object that receives the message -- every object from the domain used in the solution • Walk through the handling of a system event • Allocate responsibilities by deciding which class handles an event or delegates it to another object -- Put the main responsibilities of each class on the card. -- Put the collaborators of each class on the card

27. Role Play the Class A designer or member of a group can act the part of a "Class" when it is given control in a scenario When role playing a class, determine • what can you do, • how are you dependent on others

28. Scenarios Each use case has a successful outcome and usually one or more failure outcomes. • Failures usually are: • Looking for an object which does not exist (identifier not found) • Creating a new object but the identifier already exists. • Violation of business rules (i.e. Customer withdraws an amount that makes the balance lower than the minimum required by the bank) • Use scenarios to validate the responsibilities of each object. • Events leading to failure and to success

29. Use truth tables to check for completeness

30. Class Diagram

31. Interaction diagrams(sequence)

32. Interaction Diagrams(collaboration)

33. Entity-Relationship Diagrams

34. Free Information for UML and ER diagramming • Introduction to UML Diagramming http://www.togethersoft.com/services/practical_guides/umlonlinecourse/ http://www.rational.com/media/uml/intro_rdn.pdf • Introduction to ER Diagramming http://www.utexas.edu/its/windows/database/datamodeling/index.html