Upload
lytuyen
View
221
Download
0
Embed Size (px)
Citation preview
Intro 1
Object-Oriented Analysis & Design
Course Leader
Dr. S. Narayana Prasad
Duration: 8 SessionsSchedule: Wed, Thu, Fri (4 – 20 Jan)
Evaluation:Internal Assessment I (Midterm Test)Internal Assessment II
Intro 2
Text:
Applying UML and Patterns , 3rd Edition, Craig Larman, Pearson.
References:
1. Brown, D.W., An Introduction to Object-Oriented Analysis, Wiley,2nd Ed., 2004.
2. Mark Priestley, Practical Object Oriented Design with UML, TMH,2nd Ed., 2005.
3. Michael Bleha, James Rambaugh, Object-Oriented Modelling &Design with UML, Pearson, 2nd Ed., 2005.
4. Bahrami A., Object Oriented Systems Development using UnifiedModeling Language, McGraw Hill, 1999.
5. Grady Booch et al., Unified Modeling Language User Guide, PearsonEducation, 1999
6. Martin Fowler et al., UML Distilled, Pearson Education, 2000
7. Rebecca Wirfs-Brock et al., Designing Object-Oriented Software,PHI, 1996
8. Bruegge B., Object-Oriented Software Engineering, Pearson, 2000.
Intro 3
Outline• Object-Oriented Technology: Historical Background
• The Object Model: Basic Concepts
• OO Programming
• OO Analysis
• OO Design
• OO Benefits
• Software Development Life Cycle Models
• Iterative & Evolutionary Development
• Agile Models
• Unified Process Model
• UML
• UML Diagrams
• Structural Modeling: Class Diagrams
• Behaviour Modeling: Use Cases, Collaborations &Interaction Diagrams
Intro 4
Introduction to OOT
Intro 5
Object Oriented TechnologyHistorical Background
•Software Engineering: “Programming-in-the-large” OO Programming Languages & OO Programming
Methodology
•User Interface
Graphical objects on the screen
•Databases
Data models (structures & operations for large
data sets)
•Computer Architectures Capability-based architectures for large, interconnected
networks and systems
=> “Object Model”
Intro 6
The Object Model: Basic Concepts
Object: “a tangible entity that exhibits some well-defined behaviour”.
• States: structures (components andinterconnections)
• Behaviour: operations for manipulating thestructures
• Invariants: constraints on structures andoperations.
Objects can model a variety of real-world orapplication domain entities.
Example: An Elevator object has
• States: floors at which it may be positioned
• Behaviour: travel up and down
• Invariants: limited to stopping only at differentfloors
Intro 7
The Object Model: Basic Concepts
Class: a collection of objects that share commonproperties (states, behaviour and invariants).
• Class specification: defines a template of theproperties applicable to objects in the class.
• Objects are “instances” of a class: every object is amember of a class extension and derives its statesand behaviour from the class specification.
Classes and Objects unify:
• Data abstraction: states of objects are hidden andcan only be manipulated indirectly in terms of objectbehaviour.
• Procedural abstraction: A well-defined interfacespecifies the operations and invariants supported byeach object.
Intro 8
Object-Oriented Programming
[Ref: Rentsch, 1982/N-2.1]
“OO programming will be in the 1980s what
structured programming was in the 1970s. Everyone
will be in favour of it. Every vendor will say his
products support it. Every manager will pay lip service
to it. Every programmer will practice it (differently).
And no one will know quite what it is.”
• Evolved to handle the complexity of “programming-
in-the-large”
Intro 9
Object-Oriented Programming
“Programs are organized as cooperative collections ofobjects, each of which is an instance of some class,and whose classes are interrelated by a propertyinheritance relationship”
Features
• Objects (not procedures) are the buildingblocks.
• Objects are instances of classes, and combinedata abstractions (hidden local states) andprocedural abstractions (visible interfaces withspecified behaviour).
Intro 10
Object-Oriented Programming
• Is-a (property inheritance) relationship defines
a class hierarchy: “subclasses” inherit
properties from “superclasses”.
Example: Define classes Rose, Flower and Plant
Is-a relationship (denoted )
Rose Flower Plant
Subclass SuperclassRose FlowerFlower Plant
Intro 11
Object-Oriented Design
OO design involves specifying an “object-oriented
decomposition” of a system in terms of physical
and logical as well as static and dynamic models,
and a notation for defining these specifications.
Models Static (Structures)
Dynamic (Behaviour)
Logical
(Specifications)
Objects, classes, Is-a hierarchy
Operations
Interfaces
Physical
(Implementations)
Modules Processes
Intro 12
Object-Oriented AnalysisOO Analysis involves specifying requirements (applicationand system) in terms of entities (objects), properties(attributes & relationships) and operations (behaviours) inthe problem (application and system) domain.
Example: College Information System
Entities (Attributes):
Students (Name, Address, Qualification, Programme, Year, CGPA)
Teachers (Name, Address< Qualification, Designation)
Courses (Code, Department, Description, Prerequisites)
Relationships:
Course_offering <Courses, Teachers, Term>
Operations:
Enroll (Students, Courses)
Intro 13
Object-Oriented Modeling: Benefits
Object-oriented modeling enables design of well-structured complex systems through the followingattributes:
1. Expressive power of OO languages => improvement inproductivity and quality.
2. Reuse of code as well as design.
3. Flexibility in system structuring => adaptablesystems
4. Easier system integration: due to separation ofbehavioural and implementation specifications.
5. More intuitive modeling => easier understanding ofdesigns and specifications by humans.
Intro 14
Software Development Life Cycle
Intro 15
Software Development Life Cycle
Software Development Process Tasks
• Requirements Specifications
• Systems Analysis & Design
• Programming & Coding
• Verification & Validation
• Cataloguing & Configuration Management
• Project & Program Management
Software Development Process Models
• Traditional Model -> “Waterfall” Model
• Iterative Models
• Agile Models (XP (Extreme Programming), Scrum etc.)
• Unified Process Model
Intro 16
Software Development Life Cycle
Roles in Software Development Lifecycle
• Analyst & End User (Requirements specifications)
• Architect (System analysis and design)
• Developer (Implementation and coding)
• Quality Assurance (Verification and validation)
• Librarian (Cataloguing and Configuration management)
• Project & Program Management (Overall responsibility)
Intro 17
Iterative Development Process Models
Features
• Iterations: short, fixed-duration, mini-projects whichproduce tested & executable system implementationswith part functionality.
• The functionality of the implemented system grows witheach iteration.
Benefits:
• Better productivity
• Early mitigation of project risks
• Better user engagement & feedback during development
Waterfall Models
• Strict separation of the process activities into phases
• Inflexibility with reference to changing requirements
• Little user feedback & collaboration
Intro 18
Agile Process Models
Agile Manifesto
• Individuals & Interactions over Processes & tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract agreements
• Flexible processes over Fixed plans
Methodology
• Use formal & informal models to understandcustomer/system requirements
• Start with simple models; add detail (complexity)incrementally.
• Developers should model (no separation between analyst,designer & programmer roles)
Intro 19
Unified Process
• Workflow: set of activities associated with the differentstages of the software development lifecycle
Development Workflows:– Business Modeling– Requirements Specification– Analysis and Design– Implementation– Testing– Deployment
Supporting Workflows:
– Configuration & Change Management
– Environment
– Project Management
Intro 20
Unified Process
Iteration: a sequence of workflows within one phase, that results in a (internal or external) “release” of a system implementation.
• Phase: a time interval with well defined milestones.
Rational Unified Process (RUP) has 4 phases:
• Inception – Initial/Preliminary that conceives of thesoftware project/product.
• Elaboration: Requirements specification andarchitectural design.
• Construction: detailed design and implementation.
• Transition: system release and user acceptance.
Intro 21
Agile Unified Process
• Start with a small set of workflows & artifacts
• Requirements & design evolve incrementally over
multiple iterations
• Employ a flexible language & tool like UML
• Project Planning
• Phase Plan: high-level plan for the entire project
• Iteration Plan: detailed for each iteration
Intro 22
Software Development with UML
An UML-based software development process is:
• Use Case-driven: use cases are the primary model ofbehaviour.
• Architecture-centric: system modeling is based onthe architectural principles.
• Incremental: system functionality, design andimplementation evolve in incremental stages.
• Iterative: multiple iterations of requirements, designimplementation and release life cycles.
Intro 23
UML
Intro 24
System Modeling
Modeling Basics
• “A model is a simplification of reality”
• “Complex systems cannot be comprehended withoutmodels”
• “Models enable better understanding of the systemunder development”
Examples:
1. Architectural models -> Plan, Elevation, Structureetc. drawings
2. Physical models -> Wind tunnel models of aircraft.
3. Mathematical models -> Weather systems modeledby a set of mathematical equations.
Intro 25
System ModelingPurposes of Models
• Visualization of systems.
• Specification of system structure and behaviour• Template that guides design and construction.
• Documentation and communication of design choices,decisions.
Informal Models• Architecture: Sketch on a blackboard
• Software Development: Class-Responsibility-Collaboration (CRC) cards
Formal Models
• Building Construction: Blueprints showing views
• Electrical System: Circuit diagrams
• Aircraft Design: Wind tunnel scale model
Intro 26
UML History
Object-Oriented Paradigm
• Mid 1970s – Late 1980s -> O-O modeling languages
• 1989 – 1994 -> # of O-O methods grew from 10 to 50
O-O Methodologies
• Booch (Rational): software design and construction
• Jacobson (Objectory): OOSE (Object-Oriented SoftwareEngineering) for requirements specifications, analysis andhigh-level design)
• Rumbaugh (GE): OMT (Object Modeling Technique) foranalysis and data-intensive applications.
• Fusion
• Shlaer-Mellor: Real-time systems.
• Coad-Yourdon: Structured design
Intro 27
UML History
UML resulted from a project to unify the Booch, Jacobsonand Rumbaugh methodologies.
Goals of UML:
1. Model systems from concept to executable systemusing O-O techniques.
2. Provide scalability to handle large, complex andmission-critical systems.
3. Provide a language suitable for human understandingas well as machine processing.
Time line:
Oct 1994: Start of “Unified Method” project by Boochand Rumbaugh at Rational
Intro 28
UML HistoryTime line (continued):
Oct 1995: Draft version 0.8 released; Jacobson joins theteam.
Jan 1997: UML version 1.0 released; Offered to OMG (ObjectManagement Group) for standardization.
Jan – Jul 1997: Group of partners working on the design of thelanguage expanded.
July 1997: UML version 1.1 offered to OMG forstandardization.
Sep 1997: UML accepted by OMG’s ADTF (Analysis & DesignTask Force).
14 Nov 1997: OMG’s Architecture Board accepts UML as astandard
June 1998: OMG RTF (Revision Task Force) releases UML 1.2
Fall 1998: RTF releases UML 1.3
Intro 29
Standard Diagrams in UML Models
Common levels of abstraction: specification mappings
View Diagram
Requirement Specifications Use Case diagram
Design Specifications Collaboration diagrams
Implementation Specifications Component diagram
Deployment Specifications Deployment diagram
• Within each view, further abstraction levels can bedefined.
Intro 30
UML Class Diagrams
• Capture static, structural aspects of the model.
• Primary constituents - Classes, Interfaces,Collaborations and Relationships.
• Additional constituents – Packages, Subsystems,Instances.
• Foundation for component and deployment diagrams.
Modeling simple collaborations
1. Define a mechanism for the collaboration –participating classes, interfaces, collaborations andrelationships.
2. Start by sketching a basic framework.
3. Refine iteratively.
Intro 31
UML Class Diagrams
Data Modeling Example
member
0..1
Company
Department
name: String
Office
address: Stringphone: Integer
Headquarters Person
subset
manager
Location
*1..*
1
*
* *
*
*
1..* 1
Intro 32
UML Class Diagrams
Department
Person
Name: String
employeeID: Integer
Title: String
getPhoto (p: Person)
getContact ()
getPersonRecords ()
ContactInfo
Address: String
PersonnelRecordtaxIDemploymentHistorysalary
IsecureInfo Classes, Interfaces & Relationships
Intro 33
UML Sequence Diagram
: OrderTaker : OrderFulfillment
Submit order
Place order
Acknowledge order
Abstract Level 1
Intro 34
UML Sequence Diagram
: BillingAgent: OrderTaker : OrderFulfillment
Submit order
Place order
Acknowledge order
Abstract Level 2
: CreditCardAgent
ok
Process card
Trigger bill
Intro 35
Basic Behavioral Modeling
Use Cases
A use case:
• Specifies behaviour of the system in a specifiedcontext.
• Typically, corresponds to a single user transaction.
• Is defined in terms of a set sequences ofactions/events the system performs to yield anobservable result of value to an “actor” (an actor is arole played by a user or a system component in thecontext of the use case).
A set of use cases specify the functional requirementsfor the system from a user’s perspective.
Intro 36
Basic Behavioral Modeling
Use Case Diagram
Example: In the context of a Banking system, a “LoanOfficer” is an actor and “Process Loan” is a use case(executed by the actor).
Process Loan
LoanOfficer Use case
Actor
The actor is outside of and not part of the system beingmodeled and developed.
Intro 37
Basic Behavioral Modeling
Use Cases
A use case is defined in terms of a set of sequences or flowsof actions/events.
An action/event is modeled as an interaction among actorsand/or objects (in the system) exchanging messages.
Example: In an ATM system, an “Authenticate User” use case may
be defined by the following main flow of events as follows:
1. Card holder inserts card into the ATM.
2. ATM prompts for PIN number.
3. Card holder enters PIN number.
4. Card holder commits entry.
5. ATM checks validity of PIN.
6. If PIN is valid, ATM acknowledges authentication.
Intro 38
Basic Behavioral Modeling
Use Case
There are also exception flows corresponding to other scenariosduring user authentication:
“Cancel transaction” scenario
1. Card holder cancels transaction.
2. System acknowledges cancellation.
“Edit PIN transaction” scenario
1. Card holder clears entered PIN
2. Card holder reenters PIN.
“Invalid PIN transaction” scenario
1. Increment counter “Attempt_count”
2. If “Attempt_count” > 3, exit.
3. Acknowledge invalid PIN.
4. Reset.
Intro 39
Basic Behavioral ModelingUse Case ScenariosA use case scenario corresponds to one sequence of
events/actions.
• Each scenario represents a variation in or alternativesequence of events/actions.
• Scenarios are instances of a Use Case (just like objectsare instances of a class).
Use Cases and Collaborations
• A use case specifies functionality or behaviour (“what”).
• A collaboration implements a use case in terms of objectsand interactions (“how”).
• A use case is “realized” by a collaboration.
Intro 40
Basic Behavioral Modeling
Example: In an Order Processing system, a collaboration“Order Management” may realize use cases “ PlaceOrder”, “Cancel Order”, and “Track Order”
Place Order
CancelOrder
Track Order
OrderManagement
“Realization” relationship
Intro 41
Basic Behavioral Modeling
Example: An Order Processing system
<<extend>>Set priority
Place OrderExtension point:
Set priority
Place Rush Order
Track Order
Authenticate User
Retinal scan
Check Password
<<include>><<include>>
generalization
Intro 42
Collaborations and Collaboration Diagrams
Collaboration:
• A society of classes, interfaces and otherelements that cooperate together to provide aspecified behaviour.
• Encompass structural and behavioural elements.
• Structural elements -> Classes, Interfaces,Components, Nodes etc.
• Behavioural elements -> Interactions.
• A collaboration does not “own” the elements, butonly references them.
Intro 43
Collaborations and Collaboration Diagrams
Organizing Collaborations
PlaceOrder
OrderManagemen
t
OrderValidation
<<refine>>Use CaseCollaboration
realizes