UNIT I Introduction to OOAD What is OOAD? What is UML?

L? What are the Unified Process (UP) phases - Case study the NextGen POS system, Inception -Use case Modeling - Relating Use cases include, extend and generalization. INTRODUCTION TO OOAD Analysis - emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new online trading system is desired, how will it be used? What are its functions? "Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the requirements) or object-oriented analysis (an investigation of the domain objects). Design - emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. The term is best qualified, as in object-oriented design or database design. Object-oriented systems - An object-oriented system is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves those sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it itself decides what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object. The implementation of "message sending" varies depending on the architecture of the system being modeled, and the location of the objects being communicated with. Object-oriented analysis Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might

exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design. The sources for the analysis can be a written requirements statement, a formal vision document, and interviews with stakeholders or other interested parties. A system may be divided into multiple domains, representing different business, technological, or other areas of interest, each of which are analyzed separately. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams, and a number of interaction diagrams. It may also include some kind of user interface mock-up. The purpose of object oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer defined requirements. Object-oriented design - Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any non-functional technological or environmental constraints, such as transaction throughput, response time, run-time platform, development environment, or programming language. The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain WHAT IS OOAD? Object-oriented analysis and design (OOAD) - is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and runtime deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML).

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. WHAT IS UML? The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems. Three ways to apply UML 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 1) reverse engineering to visualize and better understanding existing code in UML diagrams, or for 2) code generation. 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; one works only in the UML "programming language." Three Perspectives to apply UML Conceptual perspective the diagrams are interpreted as describing things in a situation of the real world or domain of interest. Specification perspective - the diagrams describe software abstractions or components with specifications and interfaces. Implementation Perspective - the diagrams describe software implementations in a particular technology (such as Java).

Figure 1. Different perspectives with UML.

WHAT IS THE UNIFIED PROCESS (UP) PHASES? A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process has emerged as a popular iterative software development process for building object-oriented systems.

The Unified Process divides the project into four phases:

Inception Elaboration Construction Transition

Inception Phase Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

Establish a justification or business case for the project Establish the project scope and boundary conditions Outline the use cases and key requirements that will drive the design tradeoffs Outline one or more candidate architectures Identify risks Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase. Elaboration Phase During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams). The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, time-boxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost. The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. At this point the plan should be accurate and credible; since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase. The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration. Common UML (Unified Modeling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction diagrams. The Initial Operational Capability Milestone marks the end of the Construction phase. Transition Phase The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training. The Product Release Milestone marks the end of the Transition phase. Agile Unified Process (AUP) It is a simplified version of the IBM Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven development (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity

CASE STUDY THE NEXTGEN POS SYSTEM The Case study allows us to concentrate on learning fundamental OOA/D, requirements analysis, UML and patterns, rather than explaining the problems.

NextGen point-of-sale (POS) system. A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as a third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments.

A POS system increasingly must support multiple and varied client-side terminals and interfaces.

INCEPTION

Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical nonfunctional requirement, creation of a business case, and preparation of the development environment. Inception in one sentence: Envision the product scope, vision, and business case. How long is inception? The intent of inception is to establish some initial common vision for the objective of the project, determine if it is feasible and decide if it is worth. It may include the first requirement workshop, Planning for the first iteration and then quickly moving forward to elaboration. What Artifacts may start in Inception? Table 1 lists common inception (or early elaboration) artifacts and indicates the issues they address. Artifact Vision and Business Case Comment Describes the high-level goals and constraints, the business case, and provides an executive Use-Case Model summary. Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases Supplementary Specification will be analyzed in detail. Describes other requirements, mostly nonfunctional. During inception, it is useful to have some idea of the key non-functional requirements that have will have a major Glossary Risk List & Risk Management Plan impact on the architecture. Key domain terminology, and data dictionary. Describes the risks (business, technical, ressource, and schedule) and ideas for their

mitigation or response. Prototypes and proof-of-concepts Iteration Plan Phase Plan & Software Development Plan To clarify the vision, and validate technical ideas. Describes what to do in the first elaboration iteration. Low-precision guess for elaboration phase duration and effort. Tools, people, education, Development Case and other resources. A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project. The purpose of inception is to collect just enough information to establish a common vision, decide if moving forward is feasible, and if the project is worth serious investigation in the elaboration phase. USE CASE MODELINGS The UP defines the Use-Case Model within the Requirements discipline. Primarily, this is the set of all written use cases; it is a model of the system's functionality and environment. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams. A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. Example: such as Create Account or View Account Details. Use cases are requirements, primarily functional or behavioral requirements that indicate what the system will do. Use case defines a contract of how a system will behave. Why use cases?

It is simple and makes it possible for the domain experts or requirement to themselves write use cases. It emphasize the user goals and perspective Strength of use case is the ability to scale both up and down in terms of sophistication and formality. Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior.

A Use Case description will generally includes:

General comments and notes describing the use case. Requirements - The formal functional requirements of things that a Use Case must provide to the end user, such as <ability to update order>. These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.

Constraints - The formal rules and limitations a Use Case operates under, defining what can and cannot be done. These include:

Pre-conditions that must have already occurred or be in place before the use case is run; for example, <create order> must precede <modify order> Post-conditions that must be true once the Use Case is complete; for example, <order is modified and consistent> Invariants that must always be true throughout the time the Use Case operates; for example, an order must always have a customer number.

Scenarios Formal, sequential descriptions of the steps taken to carry out the use case, or the flow of events that occur during a Use Case instance. These can include multiple scenarios, to cater for exceptional circumstances and alternative processing paths. These are usually created in text and correspond to a textual representation of the Sequence Diagram.

Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed. Additional attributes, such as implementation phase, version number, complexity rating, stereotype and status.

Actors Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to define their overall role in the system and the scope of their action.

There are three kinds of external actors.

Primary actor has user goals.

Example: the cashier.

Supporting actor provides a service (for example, information). Example: The automated payment authorization service. Often a computer system, but could be an organization or person.

Offstage actor has an interest in the behavior of the use case Example: a government tax agency.

Use cases can be written in different formats and levels of formality:

brief: Terse one-paragraph summary, usually of the main success scenario. casual: Informal paragraph format. Multiple paragraphs that cover various scenarios. fully dressed: All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.

Fully dressed Use case: Example Process Sale Fully dressed use cases show more detail and are structured; they dig deeper. Various format templates are available for detailed use cases. Here's the template:

Use Case Section Use Case Name Scope Level Primary Actor Stakeholders and Interests Preconditions Success Guarantee

Comment Start with a verb. The system under design. "user-goal" or "subfunction" Calls on the system to deliver its services. Who cares about this use case, and what do they want? What must be true on start, and worth telling the reader? What must be true on successful completion, and worth telling the reader.

Main Success Scenario Extensions Special Requirements Technology and Data Variations List Frequency of Occurrence Miscellaneous What does the Section mean?

A typical, unconditional happy path scenario of success. Alternate scenarios of success or failure. Related non-functional requirements. Varying I/O methods and data formats. Influences investigation, testing, and timing of implementation. Such as open issues.

Scope: The scope bounds the system (or systems) under design EX - Scope: NextGen POS application Level: use cases are classified as at the user-goal level or the sub function level EX - Level: user goal

Primary Actor: The principal actor that calls upon system services to fulfill a goal. EX - Primary Actor: Cashier Stakeholders and Interests List Important: This list is more important and practical than may appear at first glance. It suggests and bounds what the system must do. EX - Stakeholders and Interests: - Cashier: Wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from his/her salary. - Salesperson: Wants sales commissions updated. - Preconditions: state what must always be true before a scenario is begun in the use case. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true.

EX - Preconditions: Cashier is identified and authenticated. Success Guarantees (Postconditions): state what must be true on successful completion of the use case either the main success scenario or some alternate path. The guarantee should meet the needs of all stakeholders. EX - Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Main Success Scenario and Steps (or Basic Flow): Also called Basic Flow" or "Typical Flow." It describes a typical success path that satisfies the interests of the stakeholders. EX - Main Success Scenario: 1. Customer arrives at a POS checkout with items to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. Cashier repeats steps 3-4 until indicates done. 5. Extensions (or Alternate Flows): Extensions are important and normally comprise the majority of the text. They indicate all the other scenarios or branches, both success and failure. EX - Extensions: 3a. Invalid identifier: 1. System signals error and rejects entry. 3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers):

1. Cashier can enter item category identifier and the quantity. Special Requirements: If a non-functional requirement, quality attribute, or constraint relates specifically to a use case, record it with the use case EX - Special Requirements: - Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter. - Credit authorization response within 30 seconds 90% of the time. - Language internationalization on the text displayed. Technology and Data Variations List: Often there are technical variations in how something must be done, but not what, and it is noteworthy to record this in the use case. A common example is a technical constraint imposed by a stakeholder regarding input or output technologies. For example, a stakeholder might say, "The POS system must support credit account input using a card reader and the keyboard." EX - Technology and Data Variations List: 3a. Item identifier entered by laser scanner or keyboard. 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. 7a. Credit account information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture. Relating Use cases include, extend and generalization Include Relationship: This is the most common and important relationship. It is common to have some partial behavior that is common across several use cases.

For example, the description of paying by credit occurs in several use cases, including Process Sale, Process Rental, Contribute to Lay-away Plan, and so forth. Rather than duplicate this text, it is desirable to separate it into its own sub-function use case, and indicate its inclusion. This is simply refactoring and linking text to avoid duplication Example: UC1 Process Sale Main Success Scenario: 1.Customer arrives at a POS checkout with goods and/or services to purchase. 7.Customer pays and System handles payment. Extensions: 7b. Paying by credit: Include Handle Credit Payment. 7c. Paying by check: Include Handle Check Payment. Fig 2 Use case include relationship in the Use-Case Model. Using include with Asynchronous Event Handling: Another use of the include relationship is to describe the handling of an asynchronous event, such as when a user is able to, at any time, select or branch to a particular window, function, or Web page, or within a range of steps. The basic notation is to use the a*, b*, ... style labels in the Extensions section. Example - UC1: Process FooBars Main Success Scenario: 1. Extensions: a*. At any time, Customer selects to edit personal information: Edit Personal Information.

b*. At any time, Customer selects printing help: Present Printing Help. Terminology: Concrete use case: A concrete use case is initiated by an actor and performs the entire behavior desired by the actor. These are the elementary business process use cases. Example - Process Sale is a concrete use case. Abstract use case: An abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case. Example - Handle Credit Payment Base use case: A use case that includes another use case, or that is extended or specialized by another use case is called a base use case. Example - Process Sale Addition use case: The use case that is an inclusion, extension, or specialization is called an addition use case. Example - Handle Credit Payment Addition use cases are usually abstract. Base use cases are usually concrete.

Fig 2. UML notation for the include relationship

Extend Relationship: Suppose a use case's text should not be modified (at least not significantly) for some reason. Perhaps continually modifying the use case with myriad new extensions and conditional steps is a maintenance headache, or the use case has been base lined as a stable artifact, and can't be touched. How to append to the use case without modifying its original text? Example: UC15: Handle Gift Certificate Payment Trigger: Customer wants to pay with gift certificate. Extension Points: Payment in Process Sale. Level: Sub-function Main Success Scenario: 1. Customer gives gift certificate to Cashier.

2. Cashier enters gift certificate ID. Fig 3. UML notation for the extend relationship

Generalization Relationship: The concepts CashPayment, CreditPayment, and CheckPayment are all very similar. In this situation, it is possible (and useful[1]) to organize them (as in Figure 32.1) into a generalization-specialization class hierarchy (or simply class hierarchy) in which the superclass Payment represents a more general concept, and the subclasses more specialized ones. Fig 4. Generalization Specialization Hierarchy

Generalization is the activity of identifying commonality among concepts and defining superclass (generals concept) and subclass (specialized concept) relationships. It is a way to

construct taxonomic classifications among concepts which are then illustrated in class hierarchies. Identifying a superclass and subclasses is of value in a domain model because their presence allows us to understand concepts in more general, refined and abstract terms. It leads to economy of expression, improved comprehension and a reduction in repeated information. In the UML, the generalization relationship between elements is indicated with a large hollow triangle pointing to the more general element from the more specialized one. Either a separate target or shared target arrow style may be used. Fig 5. Class hierarchy with separate and shared arrow notations