Date post: | 15-Jul-2015 |
Category: |
Documents |
Upload: | garapati-avinash |
View: | 146 times |
Download: | 0 times |
Object Oriented Design & Analysis - Introduction
Overview of Key Concepts
• Object & Classes
• Abstraction, encapsulation, and interface
• Introduction to UML
Objects & Classes
• An object is anything that a system is interested in
• Objects have attributes and behavior
• A class is a blueprint for creating objects having the same set of attributes and behavior
• Characteristics of OO Systems– Abstraction
– Encapsulation
– Interface
Abstraction, Encapsulation, and Interface
• ABSTRACTION = what an object is/ what an object does– Example: ATM device
• Dispenses cash to valid customer• Reports current balance of a customer• Allows fund transfer from one account to another
• ENCAPSULATION = how an object does what it does– Example: ATM device
• How it connects to the bank’s database to verify balance• How it counts currency to dispense
• INTERFACE = how the clients of an object talk to it– Example: ATM device
• The slot for inserting the ATM card• The buttons for the users to specify their options
EXERCISE
• What is the abstraction of a car?
• What is encapsulated?
• What is the interface?
More Formally
• Abstraction = externally visible behavior of an object
• Encapsulation = the internal data structure and implementation that gives rise to the externally visible behavior of an object
• Interface = set of public functions of a class
The Unified Modeling Language (UML)
• What is modeling?– Understanding, visualizing, specifying, and documenting
the requirements of a software system and the way we plan to fulfill them
– The UML provides a rich notation for visualizing our models. This includes a number of key diagrams, such as:• Use case diagrams, to illustrate user interaction with the system
• Class diagram, to illustrate logical structure
• Component diagrams, to illustrate physical structure of the software
• Sequence diagrams, to illustrate behavior of various collaborating classes in a part of the system
Benefits of Visual Modeling
• System requirements can be communicated clearly.
• Models capture the software design unambiguously
• Flaws in architecture and inconsistencies in design can be detected early and more easily
• Unnecessary details are hidden when appropriate, making the handling of complexity easier
• Computerized tools for visual modeling can be used to automate many tasks of analysis and design
• The full specification of UML can be downloaded from the OMG website: www.omg.org
UML Diagrams
• Activity diagram• Use case diagram• Class diagram• Object diagram• State machine diagram• Sequence diagram• Communication diagram• Component diagram• Deployment diagram• Package diagram• Composite structure diagram• Timing diagram• Interaction overview diagram
UML Tools
• IBM Rational: Rational Rose, Rational Software Architect
• Borland: Together Software Architect
• Sparx Systems: Enterprise Architect
• Sybase: PowerDesigner
• Microsoft: Visio
Software Development Life Cycle
• Requirement determination
• Analysis (problem domain)
• Design (solution domain)
• Implementation
• Deployment
Requirement Determination
• Activity diagram
• Actors and use cases
• Use case diagram
• Use case specification
Activity diagram
• Used for modeling– A business process
– Logic for single use case
– Logic for a business rule
• Particularly useful in the early stages of requirements determination to visualize and document our understanding of the overall process of the system. They can also be used to elaborate specific aspects of the workflow in more detail further.
• The activity diagram emphasize the flow of control from one activity to another activity.
Activity digram
Customer places purchase order
Debit customer’s bank account
Place an order on the stock exchange
Deal executed on the stock exchange
Payment to the stock exchange
Delivery of shares (demat) directly to customer’s account
Refund balance amount, if any, to the customer
Customer places/ modifies an order
Stores department dispatches the goods
Ask the customer to modify the order
Accounts department sends the invoice
Customer receives the goods
Customer receives the invoice
Customer makes the payment
Customer Sales Stores Accounts
Customer places/ modifies an order
Ask the customer to modify the order
Customer receives the goods
Customer receives the invoice
Customer makes the payment
Stores department dispatches the goods
Accounts department sends the invoice
Accounts Dept issues receipt for payment
Actors
• Anyone/ anything that interacts with a system is an actor
• Types of actors:
– Human actors (users of the system)
– External applications
– External devices
Use cases
• Functionality provided by the system
• Consist of a series of steps which collectively add value to the user of the system
• Examples– Issue a book to a member
– Receive a book back from a member
– Query the current location of a book
– Maintain member’s information
– Maintain book’s information
Identifying use cases for a system
• What are the tasks of each actor?
• Will any actor create, store, change, remove, or read the information?
• Will any actor need to inform the system about the sudden, external changes?
• Does any actor need to informed about certain occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the use cases?
Use case diagram
• Graphical view of some or all of the actors, use cases, and their interactions identified for a system. Each system typically has a main use case diagram, which is a picture of the system boundary (actor) and the major functionality by the system (use cases). Other use case diagrams may be created as needed.
Use case diagrams
Use case diagrams
Generalization of Actors
Generalization of use cases
The Include Relationship
The Include Relationship
Variations in a Use Case
The Extend relationship
Use case specification
• Description of the desired behavior of a use case• Should describe what the system should do, rather than how it will
do it• The specification for a use case should be documented to clearly
describe the events needed to achieve the required behavior of the use case. The use case specification should be written in terms of what the system is supposed to do, not how the system does it. The specifications should include:– When and how the use case starts and ends– What interaction the use case has with the actors– What data is needed by the use case– The normal sequence of events for the use case– The description of alternate or exceptional flows
Thank you