Download DBMS OOAD notesOOAD notesOOAD notesOOAD notes and more Exams Database Management Systems (DBMS) in PDF only on Docsity!
UNIT I (9)
Introduction to OOAD – What is OOAD? – What is UML? What are the United process(UP) phases - Case study – the NextGen POS system, Inception -Use case Modeling - Relating Use cases – include, extend and generalization. UNIT II (9) Elaboration - Domain Models - Finding conceptual classes and description classes – Associations – Attributes – Domain model refinement – Finding conceptual class hierarchies- Aggregation and Composition- UML activity diagrams and modeling
UNIT III (9) System sequence diagrams - Relationship between sequence diagrams and use cases Logical architecture and UML package diagram – Logical architecture refinement - UML class diagrams - UML interaction diagrams UNIT IV (9) GRASP: Designing objects with responsibilities – Creator – Information expert – Low Coupling – Controller – High Cohesion – Designing for visibility - Applying GoF design patterns – adapter, singleton, factory and observer patterns. UNIT V (9) UML state diagrams and modeling - Operation contracts- Mapping design to code -UML deployment and component diagrams
UNIT I
Unit Syllabus: UML DIAGRAMS
Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams– Interaction diagrams – State Diagrams – Activity Diagrams – Package, component and Deployment Diagrams
1.INTRODUCTION TO OOAD:
OOAD: OBJECT ORIENTED ANALYSIS AND DESIGN
Analysis and Design:
Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new computerized library information system is desired, how will it be used? "Analysis" is a broad term, best qualified, as in requirements analysis.
Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Ultimately, designs can be implemented.
Object-Oriented Analysis and Design:
object-oriented analysis, there is an emphasis on finding and describing the objects—or concepts—in the problem domain. For example, in the case of the library information system,
some of the concepts include Book, Library, and Patron.
object-oriented design, there is an emphasis on defining software objects and how they
collaborate to fulfil the requirements. For example, in the library system, a Book software
object may have a title attribute and a get Chapter method.
UML(Unified Modeling Language):
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.
Profile Diagram Composite Structure Object diagram Interaction Overview
2.UP (Unified Process):
Unified Process has emerged as a popular software development process for building object- oriented systems.
Rational Unified Process or RUP: A detailed refinement of the Unified Process.
Benefits of UP: 1. The UP is an iterative process. Iterative development is a valuable
practice that influences how this book introduces OOA/D, and how it is best practiced. 2. UP
practices provide an example structure to talk about how to do—and how to learn—OOA/D.
Iterative Development:
Development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations.
The outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.
The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development
The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system.
Benefits of Iterative Development:
Benefits of iterative development include: Early rather than late mitigation of high risks (technical, requirements,objectives, usability, and so forth). Early visible progress. Early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders Managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps
Iteration Length and Time boxing:
The UP (and experienced iterative developers) recommends an iteration length between two and six weeks. Small steps, rapid feedback, and adaptation are central ideas in iterative development iterations are timeboxed, or fixed in length.
For example, if the next iteration is chosen to be four weeks long, then the partial system should be integrated, tested, and stabilized by the scheduled date—date slippage is discouraged.
ntaining at least a clear formulation of the product vision - the core requirements - in terms of functionality, scope, performance, capacity, technology base.
of the resources required to complete the elaboration phase.
Elaboration
An analysis is done to determine the risks, stability of vision of what the product is to become, stability of architecture and expenditure of resources
Elaboration - Entry criteria
required for the elaboration phase have been allocated.
Elaboration – Activities
Project plan is defined. The process, infrastructure and development environment are described.
To provide a stable basis for the bulk of the design and implementation effort in the construction phase.
Elaboration - Exit criteria
plan, a staffing plan, a phase plan showing the number and contents of the iteration , an iteration plan, and a test plan
e ‘complete’.
Construction
The Construction phase is a manufacturing process. It emphasizes managing resources and controlling operations to optimize costs, schedules and quality. This phase is broken into several iterations.
Construction - Entry criteria
iteration specific goals
Construction – Activities
Components required satisfying the use cases, scenarios, and other functionality for the iteration are built. Unit and integration tests are done on Components. process.
Satisfaction of the goal of iteration is determined.
Construction - Exit Criteria
est cases and results of the tests conducted on the products,
Objective measurable evaluation criteria for assessing the results of the next iteration(s).
Transition
The transition phase is the phase where the product is put in the hands of its end users. It involves issues of marketing, packaging, installing, configuring, supporting the user- community, making corrections, etc.
Transition - Entry criteria
iteration, and in particular a software product sufficiently mature to be put into the hands of its users.
Transition – Activities
Fine tune the product based upon customer feedback liver the final product to the end user -user support material
Transition - Exit criteria
Disciplines and Phases:
Agile UP
Agile process implies a light and adaptive process, nimble in response to changing needs.
Case study: (Next generation POS system)
point-of-sale(POS )
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.
Layers Involved In POS System
User Interface —graphical interface; windows. Application Logic and Domain Objects— software objects representing domain concepts (for example, a software class named Sale) that fulfil application requirements. Technical Services —general purpose objects and subsystems that provide supporting technical services, such as interfacing with a database or error logging. These services are usually application-independent and reusable across several systems.
Inception:
The purpose of the inception step is not to define all the requirements, or generate a believable estimate or project plan. Inception phase should be relatively short for most projects, such as one or a few weeks long. The intent of inception is to establish some initial common vision for the objectives of the project, determine if it is feasible, and decide if it is worth some serious investigation in elaboration.
Interface —constraints imposed by interfacing with external systems. Operations —system management in its operational setting. Packaging Legal —licensing and so forth
3.USE-CASE MODEL
Use cases—stories of using a system—is an excellent technique to understand and describe requirements. The UP defines the Use-Case Model within the Requirements discipline. Essentially, this is the set of all use cases; it is a model of the system's functionality and environment.
Notations:
An actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier.
A scenario is a specific sequence of actions and interactions between actors and the system under discussion; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit card transaction denial.
Informally then, a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal. For example, here is a casual format use case that includes some alternate scenarios:
Handle Returns
Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item ... Alternate Scenarios: If the credit authorization is reject, inform the customer and ask for an alternate payment method. If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). If the system detects failure to communicate with the external tax calculator system, ...
Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing. However, the UML defines a use case diagram to illustrate the names of use cases and actors, and their relationships.
Use Case Types
Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities, which is a common unifying metaphorical theme in object-oriented thinking—software elements have responsibilities and collaborate with other elements that have responsibilities it is possible to specify what the system must do (the functional requirements) without deciding how it will do it (the design).
Formality Types
brief —terse one-paragraph summary, usually of the main success scenario. The prior Process Sale example was brief. casual —informal paragraph format. Multiple paragraphs that cover various scenarios. The prior Handle Returns example was casual. fully dressed —the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.
Fully Dressed Example: Process Sale Fully dressed use cases show more detail and are structured; they are useful in order to obtain a deep understanding of the goals, tasks, and requirements.
Use Case UC1: Process Sale
Primary Actor: Cashier
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.
- Customer: Wants purchase and fast service with minimal effort. Wants proof of purchase to support returns.
- Company: Wants to accurately record transactions and satisfy customer interests.
Preconditions state what must always be true before beginning a scenario in the use case. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true. Typically, a precondition implies a scenario of another use case that has successfully completed, such as logging in, or the more general "cashier is identified and authenticated."
Success guarantees (or 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.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. USE CASE GUIDELINES: essential UI free style Terse use cases Black box use cases Actor and Actor goal perspective How to find use cases
- Choose system boundary
- Find primary actors
- Identify goals
- Define use cases that satisfy the goal
Elementary business processes:
EBP( elementary business processes) is a term from the business process engineering field,defined as: A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. e.g., Approve Credit or Price Order.
RELATING USE CASES:
Use cases can be related to each other. For example, a subfunction use case such as Handle Credit Payment may be part of several regular use cases, such as Process Sale and Process Rental. Organizing use cases into relationships has no impact on the behavior or requirements of the system. Rather, it is simply an organization mechanism to (ideally) improve communication and comprehension of the use cases, reduce duplication of text, and improve management of the use case documents.
3 types : The include Relationship The extend Relationship The generalize Relationship
The include 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. This is simply refactoring and linking text to avoid duplication.
For example: UC1: Process Sale Main Success Scenario:
Customer arrives at a POS checkout with goods and/or services to purchase.
Customer pays and System handles payment. Extensions: 7b. Paying by credit: Include Handle Credit Payment. 7c. Paying by check: Include Handle Check Pavment.
UC7: Process Rental Extensions: 6b. Paying by credit: Include Handle Credit Payment. UC12: Handle Credit Payment Level: Subfunction Main Success Scenario:
- Customer enters their credit account information.
- System sends payment authorization request to an external Payment Authorization
Guideline of when to use the include relationship:
- An idea, thing or object
- Considered in terms of
- Symbol
- Intension
- Extension
HOW TO CREATE DOMAIN MODEL
- Find Conceptual classes
- Draw them as classes in class diagram
- Add associations and attributes
HOW TO FIND CONCEPTUAL CLASSES
- Identify noun phrases
- Use category list
- Reuse/modify existing models CONCEPTUALCLASS
ASSOCIATIONS
- Relationship between classes
- Meaningful and interesting connection
ASSOCIATIONS
DEFINITION
- In UML, associations are defined as semantic relation between two or more classifiers that involve connections among their instances
ASSOCIATION UML NOTATION
- Denoted using a line between classes
- Capitalized association name
- Multiplicity-numerical relationship between instances of classes
- Bidirectional
- Classname-verbphrase-classname format
ASSOCIATION EXAMPLE
