60-322 Object-Oriented Analysis and Design

1. 60-322 Object-Oriented Analysis and Design Jan 26, 2009

2. Ch 7 Glossary

3. Ch 7 Glossary • In its simplest form, the Glossary is a list of noteworthy terms and their definitions. • It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly different ways by different stakeholders; • This needs to be resolved to reduce problems in communication and ambiguous requirements. • Guideline • Start the Glossary early. It will quickly become a useful repository of detailed information related to fine-grained elements.

4. Ch 7 Glossary • In the UP, the Glossary also plays the role of a data dictionary, a document that records data about the data, that is, metadata. • During inception the glossary should be a simple document of terms and descriptions. • During elaboration, it may expand into a data dictionary.

5. Ch 7 Glossary • The Glossary is not only for atomic terms such as "product price." • It can and should include composite elements such as "sale" (which includes other elements, such as date and location) and nicknames used to describe a collection of data transmitted between actors in the use cases. • For example, in the Process Sale use case, consider the following statement: • System sends payment authorization request to an external Payment Authorization Service, and requests payment approval. • "Payment authorization request" is a nickname for an aggregate of data, which needs to be explained in the Glossary.

6. Ch 7 Business Rules (Domain Rules)

7. Ch 7 Business Rules (Domain Rules) • So what are domain rules? • Domain rules dictate how a domain or business may operate. • They are not requirements of any one application, although an application's requirements are often influenced by domain rules. • Company policies, physical laws (such as how oil flows underground), and government laws are common domain rules.

8. Ch 7 Business Rules (Domain Rules) • They are also called business rules, which is the most common type. • It's useful to identify and record domain rules in a separate application-independent artifact - what the UP calls the Business Rules artifact. • So that this analysis can be shared and reused across the organization and across projects, rather than buried within a project-specific document.

9. Ch 7 Business Rules (Domain Rules) • The rules can help clarify ambiguities in the use cases, which emphasize the flow of the story rather than the details. • For example, in the NextGen POS, if someone asks if the Process Sale use case should be written with an alternative to allow credit payments without signature capture, there is a business rule (RULE1) that clarifies whether this will not be allowed by any credit authorization company.

10. Ch 7 Other Requirements • Put all these other requirements into perspective

11. Ch 7 Other Requirements • During Inception • the Vision summarizes the project idea in a form to help decision makers determine if it is worth continuing, and where to start. • Since most requirements analysis occurs during elaboration, the Supplementary Specification should be only lightly developed during inception, highlighting noteworthy quality attributes that expose major risks and challenges • for example, the NextGen POS must have recoverability when external services fail. • Input into these artifacts could be generated during an inception phase requirements workshop.

12. Ch 7 Other Requirements • During Elaboration • Through the elaboration iterations, the "vision" and the Vision are refined, based upon feedback from incrementally building parts of the system, adapting, and multiple requirements workshops held over several development iterations.

13. Ch 7 Other Requirements • During Elaboration • By the end of elaboration, it is feasible to have use cases, a Supplementary Specification, and a Vision that reasonably reflects the stabilized major features and other requirements to be completed for delivery. • Nevertheless, the Supplementary Specification and Vision are not something to freeze and "sign off" on as a fixed specification. • Adaptation - not rigidity - is a core value of iterative development and the UP.

14. Ch 7 Other Requirements • During Elaboration • As software professional, you understand the importance of iterative, evolutionary,…., they all means things are not fixed. • From a business perspective, this is definitely not a good news for any business.

15. Ch 7 Other Requirements • During Elaboration • It is perfectly sensible - at the end of elaboration - to form an agreement with stakeholders about what will be done in the remainder of the project, and to make commitments (perhaps contractual) regarding requirements and schedule. • At some point (the end of elaboration, in the UP), we need a reliable idea of "what, how much, and when." • In that sense, a formal agreement on the requirements is normal and expected. • It is also necessary to have a change control process (one of the explicit best practices in the UP) for formally considered and approved requirements changes, rather than chaotic and uncontrolled change.

16. Ch 7 Other Requirements • During Elaboration • In iterative development and the UP it is understood that no matter how much due diligence is given to requirements specification, some change is inevitable, and should be acceptable. • In iterative development, it is a core value to have continual engagement by the stakeholders to evaluate, provide feedback, and steer the project as they really want it. • It does not benefit stakeholders to "wash their hands" of attentive engagement by signing off on a frozen set of requirements and waiting for the finished product, because they will seldom get what they really needed.

17. Ch 7 Other Requirements • During Construction • By construction, the major requirements- both functional and otherwise-should be stabilized- not finalized, but settled down to minor perturbation. • Therefore, the Supplementary Specification and Vision are unlikely to experience much change in this phase.

18. Ch 8 Iteration 1- Basics • We are at Ch. 8. • The Chapter title is “Iteration 1 – Basics” • What iteration and where is the iteration? • Note Ch 8 is the first chapter in Part III of the book. • Part III: Elaboration Iteration 1 – Basics • This is where we are. • What do we do in this part and this chapter?

19. Ch 8 Iteration 1- Basics • Ch. 8 will • Define the first iteration in the elaboration phase. • Motivate the following chapters in this section. • Describe key inception and elaboration phase concepts. • Summarize the iteration 1 requirements of the case studies.

20. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • Iteration-1 of the elaboration phase emphasizes a range of fundamental and common OOA/D skills used in building object systems. • Many other skills and steps, such as database design, usability engineering, and UI design, are of course needed to build software, • But they are out of scope in this introduction focusing on OOA/D and applying the UML.

21. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • Book Iterations vs. Real Project Iterations • Iteration-1 of the case studies in this book is driven by learning goals rather than true project goals. • Therefore, iteration-1 is not architecture-centric or risk-driven. • On a UP project, one would tackle difficult, risky things first. • But in the context of a book helping people learn fundamental OOA/D and UML, we want to start with easier topics.

22. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • The requirements for the first iteration of the NextGen POS application follow: • Implement a basic, key scenario of the Process Sale use case: entering items and receiving a cash payment. • Implement a Start Up use case as necessary to support the initialization needs of the iteration. • Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it. • There is no collaboration with external services, such as a tax calculator or product database. • No complex pricing rules are applied.

23. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • The requirements for the first iteration of the Monopoly application follow: • Implement a basic, key scenario of the Play Monopoly Game use case: players moving around the squares of the board. • Implement a Start Up use case as necessary to support the initialization needs of the iteration. • Two to eight players can play. • A game is played as a series of rounds. During a round, each player takes one turn. In each turn, a player advances his piece clockwise around the board a number of squares equal to the sum of the number rolled on two six-sided dice. • Play the game for only 20 rounds.

24. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • The requirements for the first iteration of the Monopoly application follow: • After the dice are rolled, the name of the player and the roll are displayed. When the player moves and lands on a square, the name of the player and the name of the square that the player landed on are displayed. • In iteration-1 there is no money, no winner or loser, no properties to buy or rent to pay, and no special squares of any kind. • Each square has a name. Every player begins the game with their piece located on the square named "Go." The square names will be Go, Square 1, Square 2, … Square 39 • Run the game as a simulation requiring no user input, other than the number of players. • Subsequent iterations will grow on these foundations.

25. Use cases - Guidelines

26. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • That seems a lot of work to do in iteration 1. • But remember, • In Iterative Development We Don't Implement All the Requirements at Once. • These requirements for iteration-1 are subsets of the complete requirements or use cases. • For example, the NextGen POS iteration-1 requirements are a simplified version of the complete Process Sale use case; they describe one simple cash-only scenario.

27. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • This is a key understanding in iterative lifecycle methods . • We start production-quality programming and testing for a subset of the requirements, and • We start that development before all the requirements analysis is complete, in contrast to a waterfall process. • After all, this is UP, an Iterative, evolutionary approach.

28. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills • Note also that we haven't done all the requirements analysis for the NextGen POS system. • We've only analyzed the Process Sale use case in detail; many others are not yet analyzed. • There will be lots of , lots of work to do, • Don’ t complain

29. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills It is common to work on varying scenarios of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required . On the other hand, short, simple use cases may be completed within one iteration.

30. From inception to Elaboration • In UP terms and our case studies, imagine we have finished the inception phase and are entering the elaboration phase. • Let’s take stock. • What happened in Inception?

31. From inception to Elaboration • Some likely activities and artifacts in inception include: • a short requirements workshop • most actors, goals, and use cases named • most use cases written in brief format; 10-20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity • most influential and risky quality requirements identified • version one of the Vision and Supplementary Specification written

32. From inception to Elaboration • Some likely activities and artifacts in inception include: • risk list • technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements ("Does Java Swing work properly on touch-screen displays?") • user interface-oriented prototypes to clarify the vision of functional requirements

33. From inception to Elaboration • Some likely activities and artifacts in inception include: • recommendations on what components to buy/build/reuse, to be refined in elaboration • For example, a recommendation to buy a tax calculation package. • high-level candidate architecture and components proposed • This is not a detailed architectural description, and it is not meant to be final or correct. Rather, it is brief speculation to use as a starting point of investigation in elaboration. For example, "A Java client-side application, no application server, Oracle for the database, …" In elaboration, it may be proven worthy, or discovered to be a poor idea and rejected. • plan for the first iteration • candidate tools list

34. From inception to Elaboration • Elaboration is the initial series of iterations during which, on a normal project: • the core, risky software architecture is programmed and tested • the majority of requirements are discovered and stabilized • the major risks are mitigated or retired

35. From inception to Elaboration • Serious investigation, implementation, testing, etc happen in this phase, in contrast to inception phase. • Elaboration often consists of two or more iterations. • Each iteration is recommended to be between two and six weeks; prefer the shorter versions unless the team size is massive. • Each iteration is timeboxed.

36. From inception to Elaboration • CAUTION: • Elaboration is not a design phase (such as in waterfall) or a phase when the models are fully developed in preparation for implementation in the construction step, • Do not superimpose waterfall ideas on iterative development and the UP. • The production quality programming and its output is not discardable, it is part of your final system to be delivered to customer.

37. From inception to Elaboration • Elaboration in one sentence: • Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources. • Some key ideas and best practices in elaboration: • do short timeboxed risk-driven iterations • start programming early • adaptively design, implement, and test the core and risky parts of the architecture • test early, often, realistically • adapt based on feedback from tests, users, developers • write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration

38. Artifacts produced in Elaboratoin Our next topic in Ch. 9

39. Ch.9 Domain Model • What is domain model? • A domain model is the most important and classic model in OO analysis. • It illustrates noteworthy concepts in a domain. • It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case studies.

40. Ch.9 Domain Model • In this chapter, • Identify conceptual classes related to the current iteration. • Create an initial domain model. • Model appropriate attributes and associations. • Useful modeling guidelines

41. Sample UP Artifact Relationships Domain Model Ch.9 Domain Model Sales Sale * 1 1 .. Business . . . LineItem Modeling date . . . . . . quantity elaboration of the domain objects , conceptual classes – some terms in attributes , and associations terms , concepts the domain that undergo state changes attributes , associations model Use - Case Model conceptual Process Sale Operation : enterItem ( … ) Cashier : … classes in The related use case concepts and insight of experts will be input to domain mode. Item ID : … the 1 . Customer arrives Post - conditions : ... domain ... . . . - Require - inspire the 2 . ... ments names of 3 . Cashier enters Operation Contracts Glossary some item identifier . software 4 .... The model can in turn influence operation contracts, a glossary, and the Design Model, classes in the design Use Case Text Design Model : Register : ProductCatalog : Sale enterItem ( itemID , quantity ) Design spec = getProductSpec ( itemID ) addLineItem ( spec , quantity ) . . .

42. Ch.9 Domain Model (in UML notation) a partial domain model drawn with UML class diagram notation. It illustrates that the conceptual classes of Payment and Sale are significant in this domain, that a Payment is related to a Sale in a way that is meaningful to note, and that a Sale has a date and time, information attributes we care about.

43. Ch.9 Domain Model • So where do you get information to draw that diagram? • What information? • Identifying a rich set of conceptual classes is at the heart of OO analysis. • If it is done with skill and short time investment (say, no more than a few hours in each early iteration), it usually pays off during design, when it supports better understanding and communication.

44. Ch.9 Domain Model • Guideline • Avoid a waterfall-mindset big-modeling effort to make a thorough or "correct" domain model - it won't ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment. • We were discussing domain model most of the time so far. I thought we should now do object oriented analysis and design (later). • OO analysis vs. domain model?

45. Ch.9 Domain Model • The quintessential object-oriented analysis is • the decomposition of a domain into noteworthy concepts or objects. • This definition seems having nothing to do with domain model.

46. Ch.9 Domain Model • A domain model is a visual representation of conceptual classes or real-situation objects in a domain. • Domain models have also been called • conceptual models • domain object models, and • analysis object models. • OO analysis vs. domain model !

47. Ch.9 Domain Model • In the UP, the term "Domain Model" means a representation of real-situation conceptual classes, not of software objects. • The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities. • In other words, it has nothing to do with programming.

48. Ch.9 Domain Model • Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. • It provides a conceptual perspective of the domain. It may show: • domain objects or conceptual classes • associations between conceptual classes • attributes of conceptual classes

49. Ch.9 Domain Model • We want to emphasize again that: • Domain Model is a visualization of things in a real-situation domain of interest, not of software objects such as Java or C# classes, or software objects with responsibilities . • Therefore, the following elements are not suitable in a domain model: • Software artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces. • Responsibilities or methods.

50. Ch.9 Domain Model