Object-Oriented Analysis and Design
Baozhong Cheng (Bob Cheng) School of Software Engineering BUPT
Textbook:
<Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design and Iterative Development>, Criag Larman,3nd Ed., 2006
Reference:
[1] <Applying Use Case Driven Object Modeling with UML, an Annotated ECommerce Example>, Doug Rosenberg, 2001, < >
[2] <Object Oritented Software Engineering Using UML,Patterns, and Java>, Bernd Bruegge, 2010, < >
[3] <Use Case Driven Object Modeling with UML/Theory and Practice>,Doug Rosenberg and Matt Stephens, Apress Jan 2007
Software Engineering
Theory (Abstract)
OOAD
OOP (C++, Java, C#, or Objective-C)
Implementation (Concrete)
Bloom's Taxonomy of the Cognitive Domain
SIX LEVELS Level-1: KNOWLEDGE Level-2: COMPREHENSION Level-3: APPLICATION Level-4: ANALYSIS Level-5: SYNTHESIS Level-6: EVALUATION
Lab Project
An OOAD for a library management system for our school Finish the project in a group of two people Functional requirements Record new library book Borrow a book Return a book Search a book Deliverablesa MS Word design document, and a zipped eclipse project file 1. File Name: OS_OOAD_GroupLeadName.zip 2. Use JUDE tool to draw UML diagramscopy & paste into a word doc. Team member names and responsibilities Use case diagram, use case (text) Class diagram (domain model & design class diagram) Sequence diagram State chat diagram 3. A zipped eclipse project file Deadline: 28-JUN-2013. Email the project file to: bobzc@163.com, or bobzc@sohu.com
5
Lecture 1 Introduction to OOAD
Chapter 1 Object-Oriented Analysis & Design
Objectives
Describe the book goals and scope. Define object-oriented analysis and design (OOAD). Illustrate a brief OOA/D example. Overview UML and visual agile modeling.
What Will You Learn? Is it Useful?
OOA/D
Patterns
UML notation
Topics and Skills
Principles and guidelines Iterative development with an agile Unified Process
Requirements analysis
The Most Important Learning Goal
A critical, fundamental ability in OOAD is to skillfully assign responsibilities to software component
GRASP patterns, nine fundamental principles in object design and responsibilities assignment
What is Analysis and Design?
Analysis emphasizes an investigation of the problem rather than how a solution is defined (WHAT?)
Design emphasizes a logical solution, how the system fulfills the requirements (HOW?)
Analysis and Design
Division between A&D is fuzzy A&D activities exist on a continuum Some practitioners can classify an activity as analysis while others put it into design category
More analysis oriented
More design oriented
-what -requirements -investigation of domain -understanding of problem
-how -logical solution -understanding and description of solution
What is OOAD?
The essence of OOAD is to consider a problem domain and logical solution from the perspective of objects (things, concepts, or entities)
OO Analysis emphasizes finding and describing the objects or concepts- in the problem domain
OO Design emphasizes defining logical software objects (things, concepts, or entities) that have attributes and methods
OO Analysis
OOA requires domain knowledge and OOA expertise
Hence, there is a need for both a domain expert and an OO analysis expert Domain expert is always right about decisions relating to problem domain If you are lucky, these two experts are the same person
OOA identifies
Concepts in the problem domain Relationships among those concepts Attributes of those concepts
OO Design
OOD defines a logical software solution for the problem
Solution is defined based on findings of OOA phase It includes definition of class methods that represent a logical software solution New concepts, attributes or relationship among concepts are often discovered during design phase. They are iteratively reflected back into analysis phase
Object vs. Function Oriented Analysis
Library Info System
Decompose by objects and concepts
O-O A&D
Decompose by functions and processes
Structured A&D
System
Catalog
Librarian
Book
Library
Record Loans
Add Resource
Report Fines
Object-Oriented Analysis and Design
Example: a catalog system for my books Analysis: what are the concepts in the problem domain? Book, each with a title. Design: what do (should) the domain concepts do? The Book object should give its own title. Construction: realize the logical solution public class Book { private String title; public void print_title() { }; } // Book implemented in Java
Object-Oriented Analysis and Design
OOAD
Larman
Requirements Analysis
Use Cases
Conceptual Model
System Behavior
Collaboration Diagrams
Class Design Diagrams
Code & Test
Requirements Study
OO Analysis
OO Design
Construction
Object-orientation emphasizes representation of objects
Plane domain concept tailNumber
visualization of domain concept
representation in an object-oriented programming language
public class Plane { private String tailNumber; public List getFlightHistory() {...} }
OOAD Example: A Dice Game
The OOAD Process
Define use cases
Build a domain model
Construct interaction diagrams Develop design class diagram
Define use cases:
Use Case: Play a Dice Game Primary Actor: Player Description: The player picks up and rolls the dice. If the dice total seven, they win, otherwise they lose.
Build a domain model
In OOAD, we want to create a specification of the problem domain so that we can build models of the objects for the solution.
We decompose the problem by identifying things and concepts, the attributes, and their associations; the result is a model of the problem domain which we are dealing with.
Construct interaction diagrams
In OOAD, we go on to investigate how the objects in the domain model may interact in collaboration to work out the solution. In a communication diagram, we illustrate how the objects may pass messages between them.
Construct interaction diagrams
Another kind of interaction diagram is the sequence diagram, which illustrate the sequence of events (due to message passing) between these objects. Sequence diagrams and communication diagrams are collectively known as the interaction diagrams.
Develop logical class diagram
A structure of the model of classes in the solution detailed models of the software constructs. Ready for implementation: organize the classes into modules; implement each class in code (Java, C++, or C#).
What is the UML?
The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems [OMG03a]. It is a notational system aimed at modeling systems using OO concepts not a methodology not a process
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 2. code generation (forward engineering).
Three Ways to Apply UMLcont.)
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. This use of UML requires a practical way to diagram all behavior or logic (probably using interaction or state diagrams), still under development in terms of theory, tool robustness and usability
UML Diagrams
Use Case Diagrams Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package Diagrams Deployment Diagrams
Nodes: Links: Nodes: Links: Nodes: Links: Nodes: Links: Nodes: Links: Nodes: Links: Nodes: Links: Actor, Use (case) Involvement, Extension, Inclusion, Generalization Class Association, Generalization Object Message, Lifeline State, Sub-State Transition Activity Guard, Synchronization Package Dependency Processor, Node Dependency
UML Diagrams
w flo k or s
Use Case
sc en a
rio s
Activity
s r-cla Inte
structures
Interaction
Inte ra sequ ction betw ences een obje cts
Class
ing tur c u str
Int e beh r-clas s avi ors
Package
State
Messages leading to state changes in objects
ors h avi s be
Chapter 2: Iterative, Evolutionary, and Agile
Objectives
1. Provide motivation for the content and order of subsequent chapters
2. Define an iterative and agile process 3. Define fundamental concepts in the Unified Process
Introduction
Iterative development lies at the heart of how OOAD is best practiced Agile Modeling are key to applying the UML in an effective way
Modern approach vs. traditional approach
Iterative and evolutionary development short quick development steps, feedback, and adaptation to clarify the requirements and design.
sequential or waterfall lifecycle promoted big upfront speculative requirements and design steps before programming.
The Most Important UP idea: Iterative Development
Development is organized into a series of short, fixed-length mini-projects called iterations Each iteration has its own requirements analysis, design, implementation, and testing activities
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.
How to Handle Change on an Iterative Project?
Change that occurs in software development is inevitable due to the stakeholders clarify their vision or the marketplace changes, and so on. Iterative and evolutionary development is based on an attitude of embracing change and adaptation as unavoidable and indeed essential driver. Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing, and this leads rapid feedback. For large scale software system, this is the only way to find out what are the requirements, which can really satisfy the end-users need In an iterative project, end-users have a lot of chance to see a partial system, and say Yes, thats what I asked for, but what I really means is something slightly different
Iterations and Convergence
Early iterations are farther from the "true path" of the system. Via feedback and adaptation, the system converges towards the most appropriate requirements and design. In late iterations, a significant change in requirements is rare, but can occur. Such late changes may give an organization a competitive business advantage.
one iteration of design, implement, integrate, and test
Why is the Waterfall so Failure-Prone?
40 35 30
Requirements change
25 20 15 10 5 0 10 100 1000 10000 Project Size in Function Points
...
20
requirements workshops Imagine this will ultimately be a 20iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.
requirements
requirements
software
software
90%
90%
50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5
week 1 M T W Th F
week 2 M T W Th F
week 3 M T W Th F
kickoff meeting clarifying iteration goals with the team. 1 hour
team agile modeling & design, UML whiteboard sketching. 5 hours
start coding & testing
de-scope iteration goals if too much work
final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop
demo and 2-day requirements workshop
next iteration planning meeting; 2 hours
Most OOA/D and applying UML during this period
What is Agile Modeling?
Adopting an agile method does not mean avoiding any modeling The purpose of modeling and models is primarily to support understanding and communication, not documentation. Dont model or apply the UML to all or most of the software design. Use the simplest tool possible.
prefer low energy creativity-enhancing simple tools that support rapid input and change
The Unified Process
development cycle iteration phase
inc.
elaboration
construction
transition
milestone An iteration endpoint when some significant decision or evaluation occurs.
release A stable executable subset of the final product. The end of each iteration is a minor release.
increment The difference (delta) between the releases of 2 subsequent iterations.
final production release At this point, the system is released for production use.
Disciplines (workflow) vs. Iterations
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Sample UP Disciplines Business Modeling Focus of this book Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time. This example is suggestive, not literal.
Case Study Strategy: Iteraltive Development + Iterative Learning
Iteration 1 Iteration 2 Introduces just those analysis and design Additional analysis and skills related to design skills introduced. iteration one. Iteration 3 Likewise.
Book organization is related with UP phases and iterations
The Book Elaboration Iteration 1 Elaboration Iteration 2 Elaboration Iteration 3 Special Topics
Overview
Inception
Object-Oriented Analysis
Object-Oriented Design
Translating Designs to Code
Topics such as OO analysis and OO design are incrementally introduced in iteration 1, 2, and 3.
Chapter 3: Case Studies
What is and isnt in the Case Studies?
Focuses on the core application logic layer
minor focus
User Interface
explore how to connect to other layers
application logic layer
primary focus of case studies Sale Payment explore how to design objects
other layers or components
Logging ...
Database Access ...
secondary focus
Case One: The NextGen POS System
POS Point Of Sale A computerized application used to record sales and handle payments It interfaces to various service applications Bank (credit card system) Inventory control Third party tax calculator
Increasingly must support multiple and varied terminals and interfaces A commercial POS system that will serve different clients with disparate needs in terms of business rule processing
Case Two: The Monopoly Game System