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

2. 2 Ch 7 Glossary

3. Jan 26, 2009 3 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. Ch 7 Glossary

4. Jan 26, 2009 4 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. Ch 7 Glossary

5. Jan 26, 2009 5 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. Ch 7 Glossary

6. Jan 26, 2009 6 Ch 7 Business Rules (Domain Rules)

7. Jan 26, 2009 7 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. Ch 7 Business Rules (Domain Rules)

8. Jan 26, 2009 8 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. Ch 7 Business Rules (Domain Rules)

9. Jan 26, 2009 9 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. Ch 7 Business Rules (Domain Rules)

10. Jan 26, 2009 10 Put all these other requirements into perspective Ch 7 Other Requirements

11. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 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. Jan 26, 2009 18 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? Ch 8 Iteration 1- Basics

19. Jan 26, 2009 19 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. Ch 8 Iteration 1- Basics

20. Jan 26, 2009 20 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

21. Jan 26, 2009 21 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

22. Jan 26, 2009 22 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

23. Jan 26, 2009 23 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

24. Jan 26, 2009 24 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

25. Jan 26, 2009 25 Use cases - Guidelines

26. Jan 26, 2009 26 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

27. Jan 26, 2009 27 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. Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

28. Jan 26, 2009 28 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 Ch 8 Iteration 1 Requirements and Emphasis: Core OOA/D Skills

29. Jan 26, 2009 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. Jan 26, 2009 30 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? From inception to Elaboration

31. Jan 26, 2009 31 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 From inception to Elaboration

32. Jan 26, 2009 32 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 From inception to Elaboration

33. Jan 26, 2009 33 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 From inception to Elaboration

34. Jan 26, 2009 34 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 From inception to Elaboration

35. Jan 26, 2009 35 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. From inception to Elaboration

36. Jan 26, 2009 36 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. From inception to Elaboration

37. Jan 26, 2009 37 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 From inception to Elaboration

38. Jan 26, 2009 38 Artifacts produced in Elaboratoin Our next topic in Ch. 9

39. Jan 26, 2009 39 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. Ch.9 Domain Model

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

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

42. Jan 26, 2009 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. Jan 26, 2009 43 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. Ch.9 Domain Model

44. Jan 26, 2009 44 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? Ch.9 Domain Model

45. Jan 26, 2009 45 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. Ch.9 Domain Model

46. Jan 26, 2009 46 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 ! Ch.9 Domain Model

47. Jan 26, 2009 47 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. Ch.9 Domain Model

48. Jan 26, 2009 48 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 Ch.9 Domain Model

49. Jan 26, 2009 49 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. Ch.9 Domain Model

50. Jan 26, 2009 50 Ch.9 Domain Model

51. Jan 26, 2009 51 Be aware that the term “Domain Model “ means also something else before. In the UP and thus this chapter, "Domain Model" is a conceptual perspective of objects in a real situation of the world, not a software perspective. It also has been used to mean "the domain layer of software objects." Ch.9 Domain Model

52. Jan 26, 2009 52 Ok, we know that domain model describes conceptual classes in a domain. So what is a conceptual class? Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension Ch.9 Domain Model

53. Jan 26, 2009 53 – Symbol: words or images representing a conceptual class. – Intension: the definition of a conceptual class. – Extension: the set of examples to which the conceptual class applies. – See the figure. Ch.9 Domain Model

54. Jan 26, 2009 54 Ch.9 Domain Model words or images representing a conceptual class. the definition of a conceptual class. the set of examples to which the conceptual class applies.

55. Jan 26, 2009 55 Shall we begin to discuss constructing domain model? We studied what domain model is, some related terms such as conceptual class, etc. We are told to constructed by the UP to construct domain model when we enter elaboration phase? But why create a domain model? We want to know why before we study how? Domain model To help coding? Domain model To help understanding? Ch.9 Domain Model

56. Jan 26, 2009 56 Domain model To help understanding and more… – To understand the key concepts and vocabulary in a domain – To support a lower gap between the software representation and our mental model of the domain. Lower representation Gap with OO modelling A key idea in OO. Ch.9 Domain Model

57. Jan 26, 2009 57 Ch.9 Domain Model supports a low representational gap between our mental and software models. here's a source-code payroll program written in 1953: 1000010101000111101010101010001010101010101111010101 …

58. Jan 26, 2009 58 How to create a domain model? Bounded by the current iteration requirements under design: – Find the conceptual classes – Draw them as classes in a UML class diagram. – Add associations and attributes.associationsattributes Ch.9 Domain Model