Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN Objectives •Describe the book goals and scope •Define OOA/D (Object-Oriented Analysis and Design) •Illustrate a brief OOA/D example •Overview UML and visual agile modeling “Time is a great teacher, but unfortunately it kills all its pupils.” - Hector Berlioz
67
Embed
Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN Objectives Describe the book goals and scope Define OOA/D (Object-Oriented Analysis and Design) Illustrate.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Chapter 1OBJECT-ORIENTED ANALYSIS AND DESIGN
Objectives•Describe the book goals and scope•Define OOA/D (Object-Oriented Analysis and Design)•Illustrate a brief OOA/D example•Overview UML and visual agile modeling
“Time is a great teacher, but unfortunately it kills all its pupils.”
- Hector Berlioz
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 2
Applying UML and Patterns
Larman’s book is a tool to help developers/students learn core skills in OOA/D.
• These skills are essential for the creation of well-designed, robust, and maintainable software using OO technologies and languages such as Java or C#.
• Knowing an object oriented language is necessary but insufficient first step to create object systems. Knowing how to “think in objects” is critical !
Owning a hammer doesn’t make one an architect” (Proverb)
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 3
Topics and Skills
UML notation
Requirements analysis
Principles and guidelines
Patterns
Iterative development with an agile Unified
Process
OOA/D
Fig. 1.1 Topics and skills covered in the book.
The book illustrates this in the context of long-running case studies that evolve over several iterations.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 4
Analysis
• Analysis emphasizes an investigation of the problem and requirements, rather than a solution.
• In software development, we are primarily concerned with two forms of analysis.– Requirements Analysis is discovering the
requirements that a system must meet in order to be successful.
– Object-Oriented Analysis is investigating the objects in a domain to discover information important to meet the requirements.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 5
Use Cases
• Writing Use Cases is not a specifically OO artifact – they are simply written stories.
• However, they are a best practice for elaborating and understanding requirements.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 6
Design
• Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. – Design ideas often exclude low-level or obvious
details – obvious to the intended consumers.
– There are subsets of design, including • architectural design, • object design, • database design.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 7
Object-Oriented Analysis and Design (OOA/D)
• During OOA, the emphasis is on finding and describing the objects (or concepts) in the problem domain, i.e., domain objects.
• During OOD (or simply object design), the emphasis is on defining software objects and how they collaborate to fulfill the requirements.
• During OOP (OO Programming) or Implementation, design objects are implemented in a programming language. – Implementation is also known as Coding or
Construction.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 8
Plane
tailNumber
public class Plane{private String tailNumber;
public List getFlightHistory() {...}}
domain concept
visualization of domain concept
representation in an object-oriented programming language
Fig. 1.2 Object-orientation emphasizes representation of objects
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 9
Responsibility-Driven Design
• It is the classical OO design metaphor
• The most important skill in OOA/D is assigning responsibilities to objects. – That determines how objects interact and what
classes should perform what operations.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 10
Design Patterns
• Certain tried-and-true solutions to design problems have been expressed as principles of best practice, often in the form of Design Patterns.
• A Design Pattern is a named problem solution formula that apply excellent design principles.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 11
The Unified Process (UP)
• A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development.
– Requirements analysis and OOA/D needs to be presented and practiced in the context of some development process.
– Here, an agile (light, flexible) approach to well-known Unified Process (UP) is used as a sample iterative development process.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 12
Unified Modeling Language (UML)
• UML is the de facto standard diagramming notation for drawing or presenting pictures related to OO software.
• UML is a visual language for specifying, constructing and documenting the artifacts of OO systems.– Knowing UML helps you communicate with others in
creating software.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 13
Three ways people apply UML are ...
• UML as sketch– Informal and incomplete diagrams (often hand sketched on
whiteboards) created to explore difficult parts of the problem or solution space
– Agile modeling emphasizes UML as sketch.
• UML as blueprint– relatively detailed design diagrams used either for reverse
engineering to visualize and better understand existing code,
– or for forward engineering to guide for code generation, either manually or automatically with a tool.
• UML as a programming language– Complete executable specification of a sw system in UML.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 14
Three perspectives to apply UML are ...
• Conceptual perspective – the diagrams are interpreted as describing things in a situation of the real world or domain of interest.
• Specification (software) perspective – the diagrams describe sw abstractions or components with specifications and interfaces, but no commitment to a particular language implementation.
• Implementation perspective – the diagrams describe sw implementations in a particular technology.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 15
Conceptual Perspective(domain model)
Raw UML class diagram notation used to visualize real-world concepts.
Specification or Implementation
Perspective(design class diagram)
Raw UML class diagram notation used to visualize software elements.
2
Die
faceValue : int
getFaceValue() : introll()
DiceGame
die1 : Diedie2 : Die
play()
DiceGame Die
faceValue
Includes 21
Fig. 1.6 Different perspectives with UML
In practice, most software-oriented UML diagramming assumes an implementation perspective and the specification perspective is seldom used for design.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 16
The meaning of “class” in different perspectives
• Conceptual class – real-world concept or thing. A conceptual or essential perspective. – The UP Domain Model contains conceptual classes.
• Software class – a class representing a specification or implementation perspective of a sw development, regardless of the process or method.
• Implementation class – a class implemented in a specific OO language such as Java.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 17
A Short Example
OOA/D steps of a small “Dice Game”:– Define Use Cases– Define a Domain Model– Define Interaction Diagrams– Define Design Class Diagrams
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 18
Use Case: Play a Dice Game
• Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise, player loses.
Define Use Cases
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 19
Player
name
DiceGame
Die
faceValue
Rolls
Plays
Includes
2
2
1
1
1
1
Fig. 1.3 Partial domain model (conceptual object model) of the dice game
Define a Domain Model
Domain model shows the noteworthy domain concepts as objects, their attributes, and associations.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 20
Fig. 1.4 Sequence diagram illustrating messages between software objects
Define Object Responsibilities and Draw Interaction Diagrams
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 21
:DiceGame
play()
die1 : Die
fv1 := getFaceValue()
die2 : Die
roll()
roll()
fv2 := getFaceValue()
Fig. 1.4 Sequence diagram illustrating messages between software objects
A sequence diagram (a kind of UML interaction diagram) shows the flow of messages between software objects and thus the invocation of objects.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 22
2
Die
faceValue : int
getFaceValue() : introll()
DiceGame
die1 : Diedie2 : Die
play()
1
Fig. 1.5 Partial design class diagram (software classes)
Define Design Class Diagrams
A static view of the class (including its attributes and methods) definitions is usefully shown with a UML class diagram.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 23
Chapter 2ITERATIVE, EVOLUTIONARY, AND AGILE
Objectives• Provide motivation for the content and order of
the book• Define an iterative and agile process• Define fundamental concepts in the Unified
Process.
“You should use iterative development only on projects that you want to succeed.”
- Martin Fowler
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 24
Waterfall (Sequential) Lifecycle
• promotes big up-front “speculative” requirements and design steps before programming.
• was historically promoted due to belief or hearsay rather than statistically significant evidence.*– Success/failure studies show that the waterfall is strongly
associated with the highest failure rates for software projects.
– On average, 45% of the features are never used, and early schedules and estimates vary up to 400% from the actuals.
* We should approach to the author’s such claims very carefully! [KD]
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 25
Why the waterfall lifecycle fails?
• The key false assumption:– The specifications are predictable and stable and can
be correctly defined at the start, with low change rates.
– But change is a constant on software projects.• A typical software project experienced a 25% change in
requirements (Boehm and Papaccio 1988)
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 26
Fig. 2.3 Percentage of change on software projects of varying sizes. (Jones 1997)
0
5
10
15
20
25
30
35
40
10 100 1000 10000Project Size in Function Points
Req
uire
men
ts c
hang
e
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 27
Iterative and Evolutionary Development
• involves early programming and testing of a partial system, in repeating cycles.
• relies on short quick development steps (or iterations), feedback and adaptation to clarify the requirements and design so successively enlarging and refining a system.– normally assumes that the development starts before all
requirements are defined in detail, feedback is used to clarify and improve the evolving specifications.
• Each iteration will include requirements, analysis, design, implementation, and test.
Current research demonstrates that iterative methods are associated with higher success and productivity rates, and lower defect levels.*
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 28
Fig. 2.2 Iterative feedback and evolution leads towards the desired system. The requirements and design instability lowers over time.
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
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 29
Timeboxing
• A key idea is that iterations are timeboxed, or fixed in length.– Most iterative methods recommend in iteration
length bw 2 – 6 weeks.
– If it seems that it will be difficult to meet the deadline, the recommended response is to de-scope
• De-scoping: removing tasks or requirements from the iteration, and including them in a future iteration, rather than slipping the completion date.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 30
Requirements
Design
Implementation& Test&Integration&More DesignFinal
Integration & System Test
3 weeks (for example)The system grows incrementally.
Time
Fig. 2.1 Iterative and Evolutionary Development (also known as iterative and inceremental development; spiral development and evolutionary development)
Requirements
Design
Implementation& Test&Integration&More DesignFinal
Integration & System Test
Each iteration is an executable but incomplete system;
A subset of the final system(but not a throw-away prototype!)
Iterations are fixed in length or timeboxed.
Feedback from iteration NLeads to refinement and
adaptation ofThe requirements and
design in İteration N+1
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 31
Fig. 2.4 Evolutionary analysis and design – the majority in early iterations.
Imagine this will ultimately be a 20 -iteration 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 .
1 2 3 4 5 ... 20
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
a 3-week iteration
de-scope iteration goals if too much work
final check-in and code-freeze for the iteration baseline
demo and 2-day requirements workshop
next iteration planning meeting;2 hours
Most OOA/D and applying UML during this period
Use-case modeling during the workshop
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 32
Build-Feedback-Adapt Cycles
In complex changing systems, feedback and adaptation are key ingredients for success:– Feedback from early development, programmers trying to
read specifications, and client demos • to refine the requirements.
– Feedback from tests and developers • to refine the design and models.
– Feedback from the progress of the team tackling early features
• to refine the schedule and estimates.
– Feedback from the client and marketplace to re-prioritize the features
• to tackle in the next iteration.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 33
Benefits to Iterative Development
• Less project failure, better productivity, and lower defect rates
• Early rather than late mitigation of high risks
• Early visible progress• Early feedback, user engagement, and adaptation
• Managed complexity; – the team is not overwhelmed by “analysis paralysis” or
very long and complex steps
• The learning within an iteration can be methodically used to improve the development process itself, iteration by iteration.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 34
The Unified Process (UP)
“People are more important than any process. Good people with a good process will outperform good people with no process any time.”
– Grady Booch
• A software development process describes an approach to building, deploying, and possibly maintaining software.
• UP has emerged as a popular and effective iterative software development process for building OO systems.– In particular, the Rational Unified Process, as
modified at Rational Software, is widely practiced and adopted by industry.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 35
Unified Process (UP)
• encourages a combination of risk-driven and client-driven iterative planning.
• The goals of the early iterations are chosen to– Identify and drive down the highest risks.
• Includes the practice of architecture-centric iterative development - Early iterations focus on building, testing, and stabilizing the core architecture.
• Tackles the difficult things first.
– Build visible features that the client cares most about.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 36
Advantages of UP
The UP puts an emphasis on addressing very early high risks areas.
It does not assume a fixed set of firm requirements at the inception of the project, but allows to refine the requirements as the project evolves.
It does not put either a strong focus on documents or ‘ceremonies’
The main focus remains the software product itself, and its quality.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 37
Fig. 2.6 Schedule-oriented terms in the UP
inc. elaboration construction transition
iteration phase
development cycle
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.
milestone
An iteration end-point when some significant decision or evaluation occurs.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 38
Agile Methods and Attitudes
• Agile development methods usually – apply timeboxed iterative and evolutionary
development, – employ adaptive planning, – promote incremental delivery, – and include other values and practices that
encourage agility – rapid and flexible response to change.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 39
Existing Agile Methods
Rational Unified Process (RUP) Extreme Programming (XP)
Feature Driven Development (FDD) Scrum
Open source software development Crystal Family of Methodologies
Dynamic Systems Development Methods Adaptive software development
Agile Modeling Pragmatic Programming
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 40
The Agile Manifesto
• In 2001 a group interested in iterative and agile methods met to find common ground. Out of this came the Agile Alliance with a manifesto and statement of principles to capture the spirit of agile methods:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 41
The Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying info to and within a development team is face-to-face conversation.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 42
The Agile Principles
7. Working software is the primary measure of progress.8. Agile processes promote sustainable development.9. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.10. Continuous attention to technical excellence and good
design enhances agility.11. Simplicity – the art of maximizing the amount of work
NOT done – is essential.12. The best architectures, requirements, and designs
emerge from self-organizing teams.13. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its behavior accordingly.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 43
Agile Modeling
• The purpose of modeling (sketching UML, …) is primarily to understand, not to document.– The very act of modeling can and should provide a
way to better understand the problem or solution space.
• From this viewpoint, the purpose of “doing UML or OOA/D” is not for a designer to create many detailed UML diagrams that are handed off to a programmer, – but rather to quickly explore alternatives (more
quickly than with code) and the path to a good OO design.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 44
Agile Modeling Principles and Values (Ambler, 2002)
• 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.
• Don’t model or apply the UML to all or most of the software design. Apply UML for the smaller percentage of unusual, difficult, tricky parts of design space.
• Use the simplest tool possible. “Prefer” sketching UML on whiteboards, and capturing the diagrams with a digital camera.
• Don’t model alone, model in pairs (or triads) at the whiteboard, in the awareness that the purpose is to discover, understand, and share that understanding.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 45
Agile Modeling Principles and Values (2)
• Create models in parallel: Dynamic-view vs. static view.
• Use “good enough” simple notation while sketching with a pen on whiteboards. Exact UML details aren’t important.
• Know that all models will be inaccurate, and the final code or design different – than the model. Only tested code demonstrates the true design.
• Developers themselves should do the OO design modeling, for themselves.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 46
Fig. 2.5 A UML sketch of a sequence diagram from a project
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 47
Agile UP
• Prefer a small set of UP activities and artifacts.
• Requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.
• Apply the UML with agile modeling principles.
• There isn’t a detailed plan for the entire project. – There is a high-level plan (called the Phase Plan) that
estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones.
– A detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done adaptively from iteration to iteration.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 48
UP Best Practices
• Get high risk and high value first• Constant user feedback and engagement
• Early cohesive core architecture• Test early, often, and realistically
• Apply use cases where needed• Do some visual modeling with UML
• Manage requirements and scope creep• Manage change requests and configuration
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 49
UP Phases
1 Inception Inception is not a requirements phase; rather a feasibility
phase, where just enough investigation is done to support a decision to continue or stop.
The life-cycle objectives of the project are stated, so that the needs of every stakeholder are considered. Scope and boundary conditions, acceptance criteria and some requirements are established.
Approximate vision, business case, scope, vague estimates.
2 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.
Refined vision, iterative implementation of core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 50
UP Phases (2)
3 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.
– Iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
4 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.
– Beta tests, deployment.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 51
Fig. 2.7 UP disciplines
Iterations
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Focus of this book
Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.
This example is suggestive, not literal.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 52
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 53
Business Modeling Discipline
• The purpose of this discipline is to model the business context and the scope of your system.
• This is done usually in Inception and Elaboration phase.
• Activities include the development of:– A context model showing how the system fits into its
overall environment – A high-level business requirements model eg. use case
model– A domain model e.g. class diagram or data diagram
depicting major business classes or entities – A business process model
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 54
Business Modeling
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 55
Requirements Discipline
• The purpose of this discipline is to engineer the requirements for the project, including their identification, modeling, and documentation.
• The main deliverable of this discipline is the Software Requirements Specification (SRS), also referred to as the Requirements Model, which encompasses the captured requirements.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 56
Requirements
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 57
Analysis & Design Discipline
• The purpose of this discipline is to evolve a robust architecture for the system based on the requirements, to transform the requirements into a design, and to ensure that implementation environment issues are reflected in the design.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 58
Analysis and Design
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 59
Environment Discipline
• The purpose of this discipline is to support development work. Practically all the work in this workflow are done in Inception phase.
• The activities include - implementing and configuring UP , selecting and
acquiring required tools, developing in-house tools- providing software and hardware maintenance and
training.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 60
Environment
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 61
Implementation
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 62
Test
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 63
Chapter 3CASE STUDIES
Objectives• To introduce the chosen case studies.
“Few things are harder to put up with than a good example.”
- Mark Twain
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 64
Ongoing Case Studies
• Case One: The NextGen POS System – A Point of Sale (POS) System is a replacement for a
cash register that adds many computer services to the traditional cash register. Most retail stores now use POS systems.
• Case Two: The Monopoly Game System
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 65
Architectural Layers
• User Interface– (minor topic)
• Application Logic and Domain Objects– Sale and Payment (main topics)
• Technical Services– Log and Persistence (secondary topics)
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 66
Fig. 3.1 Sample layers and objects in an o-o system, and the case study focus
User Interface
Sale Payment
Logging ... Database Access ...
application logic layer
other layers or components
minor focus
explore how to connect to other layers
primary focus of case studies
explore how to design objects
secondary focus
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 67
Iterative Learning/Development
• The text is organized in three iterations.• Each iteration will deliver a product to the customer,
with subsequent iterations adding features to the earlier ones.
• Each iteration will do analysis and design only on the features for the current release of the software.
Overview InceptionElaborationIteration 1
ElaborationIteration 2
ElaborationIteration 3
Object-OrientedAnalysis
Object-OrientedDesign
Translating Designs to Code
The Book
Topics such as OO analysis and OO design are incrementally introduced in iteration 1, 2, and 3.
SpecialTopics
Fig. 2.9 Book organization is related to the UP phases and iterations