Transcript Software Engineering Dr. K. T. Tsang

Software Engineering
Dr. K. T. Tsang
Lecture 4
Object-Oriented concepts
http://www.uic.edu.hk/~kentsang/SWE/SWE.htm
1
Before we write any code, we need
• Establishing Requirements: The goal of this is
to spell out what constitutes a satisfactory
solution to the problem.
• Analysis: The goal here is to understand the
problem (domain) comprehensively.
• Design: The goal here is to develop the overall
structure of a (SW) solution to the problem in
terms of individual (SW) components and their
relationships to one another.
2
How ??
• All these tasks require modeling activities
• To better understand the problem we have, we
need a model for the domain where the SW will
operate on.
• Modeling – building a model that has all
relevant features of the domain area which we
are interested.
• This will help to better understand the domain
and make the Analysis part of the development
process easier.
3
What is Design?
Developing a blueprint (plan) for a SW
architecture that can satisfy the
requirements,
… taking into account all the constraints, &
… making trade-offs between constraints
when they are in conflict.
4
Factors affecting the quality of a
software system
• Complexity:
– The system is so complex that no single programmer can
understand it anymore
– The introduction of one bug fix causes another bug
• Change:
– The “Entropy” of a software system increases with each change:
Each implemented change erodes the structure of the system
which makes the next change even more expensive
– As time goes on, the cost to implement a change will be too high,
and the system will then be unable to support its intended task.
This is true of all systems, independent of their application
domain or technological base.
5
Why are software systems so
complex?
• The problem domain is difficult
• The development process is very difficult to
manage
• Software offers extreme flexibility (complicated)
• Software is a discrete system
– Continuous systems have no hidden surprises
– Discrete systems have!
6
Dealing with Complexity
1. Abstraction
2. Decomposition
3. Hierarchy
7
1. Abstraction
• Inherent human limitation to deal with
complexity
– The 7 +- 2 phenomena
• Chunking: Group collection of objects
• Ignore unessential details: => Models
8
Models are used to provide
abstractions
• System Model:
– Object Model: What is the structure of the system?
What are the objects and how are they related?
– Functional model: What are the functions of the
system? How is data flowing through the system?
– Dynamic model: How does the system react to external
events? How is the event flow in the system ?
• Task Model:
– PERT [Program (or Project) Evaluation and Review Technique]
Chart: What are the dependencies between the tasks?
– Schedule: How can this be done within the time limit?
– Org Chart: What are the roles in the project or organization?
• Issues Model:
– What are the open and closed issues? What constraints were
posed by the client? What resolutions were made?
9
2. Decomposition
• A technique used to master complexity (“divide and
conquer”)
• Functional decomposition
– The system is decomposed into modules
– Each module is a major processing step (function) in
the application domain
– Modules can be decomposed into smaller modules
• Object-oriented decomposition
– The system is decomposed into classes (“objects”)
– Each class is a major abstraction in the application
domain
– Classes can be decomposed into smaller classes
11
Functional Decomposition
System
Function
Read Input
Read Input
Load R10
Transform
Transform
Top Level functions
Produce
Output
Level 1 functions
Level 2 functions
Produce
Output
Add R1, R10
Machine Instructions
12
Functional Decomposition
• Functionality is spread all over the system
• Maintainer must understand the whole
system to make a single change to the
system
• Consequence:
– Codes are hard to understand
– Code that is complex and impossible to
maintain
– User interface is often awkward and nonintuitive
13
Functional Decomposition: Autoshape
Autoshape
Mouse
click
Change
Rectangle
Draw
Change
Change
Oval
Change
Circle
Example: Microsoft Powerpoint’s
Autoshapes
Draw
Rectangle
Draw
Oval
Draw
Circle
14
Structured SW paradigm
• The structured paradigm consists of structured
systems analysis, structured design, structured
programming and structured testing. They were
introduced between 1970 and 1985, and looked promising at the time.
• Two problems with structured paradigm:
– Could not scale up: Good for products with
5,000 or 50,000 LOC (lines of code), but
inadequate for products with 500,000 LOC or
more.
– Could not reduce maintenance costs.
15
Structured SW paradigm
• The reason is that structured techniques
are either action oriented (such as data
flow analysis) or data oriented (such as
Jackson method) but not both.
• Object-oriented paradigm considers data
and action to be of equal importance.
16
Structured paradigm vs. OO
17
What is OO Analysis and Design
• Object-Oriented
Analysis
• Object-Oriented
Design
– Important domain
concepts or objects?
– Design of software
objects
– Domain vocabularies?
– Responsibilities
– Collaborations
– Design patterns
18
History of OO
• Object orientation as a concept has been
around since the 1970's
– as a design concept since 1980
• It was in the 1980's that it started to
develop as a credible alternative to the
structured approach in analysis and
design.
19
Why OO?
• We can identify a number of drivers.
– The emergence of mainstream OO programming
languages like SmallTalk and particularly C++, a pragmatic
OO language derived from C, widely used because of its association
with Unix.
– The development of powerful workstations, and with them
the emergence into the mainstream of windowing operating
user environments. Graphical User Interfaces (GUI) have
an inherent object structure.
– A number of very public major project failures, suggesting
that structured approaches were not satisfactory.
20
OO concepts
• Object-Orientation treats the world as a world
of objects, which contain
– (hidden) information
– Methods (aka behaviors)
– A public interface
• This structure provides encapsulation
– Data & behavior are private; as long as the
public interface remains unchanged, the data &
behavior of an object can be freely modified.
21
3 basic OO concepts
• Encapsulation
• Inheritance- subclasses
• Polymorphism- different implementation
of a particular functionality
22
Benefits
• Two benefits from this approach are
– Understanding of the system is easier as the
semantic gap between the system & reality is
small.
– Modifications to the model tend to be local
as they often result from an individual item,
which is represented by a single object.
23
Message Passing
• Objects communicate with each other via
message passing
– The only way an object can access info
contained in another object
– No data duplication
– Messages sent or received are determined by
objects’ public interfaces
24
Object & class
• Objects are organized into classes by their
common features
– Attributes (aka data)
• Represent the object’s state or capture
associations/relationship with other objects
– Operations/methods (behavior)
• Procedures or services the object can perform
– Invariants (this is new!)
• Specify how the other features of the object are
related
25
Classes
• A class is a collection of objects which share
common attributes & methods
– A template for creating instances (aka objects)
26
Class Identification
•
•
•
•
Class identification is crucial to object-oriented modeling
Basic assumption:
1. We can find the classes for a new software system:
We call this Greenfield Engineering
2. We can identify the classes in an existing system:
We call this Reengineering
3. We can create a class-based interface to any system:
We call this Interface Engineering
Why can we do this? Philosophy, science, experimental
evidence
What are the limitations? Depending on the purpose of
the system different objects might be found
– How can we identify the purpose of a system?
27
What is this Thing?
28
Modeling a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
29
A new Use for a Briefcase
BriefCase
Capacity: Integer
Weight: Integer
Open()
Close()
Carry()
SitOnIt()
30
Questions
• Why did we model the thing as “Briefcase”?
• Why did we not model it as a chair?
• What do we do if the SitOnIt() operation is the
most frequently used operation?
• The briefcase is only used for sitting on it. It is
never opened nor closed.
– Is it a “Chair” or a “Briefcase”?
• How long shall we live with our modeling
mistake?
31
Dealing with Complexity
1. Abstraction
2. Decomposition
3. Hierarchy
32
3. Hierarchy
• We got abstractions and decomposition
– This leads us to chunks (classes, objects) which we
view with object model
• Another way to deal with complexity is to provide
simple relationships between the chunks
• One of the most important relationships is hierarchy
• 2 important hierarchies
– "Part of" hierarchy
– "Is-kind-of" hierarchy
33
Part of Hierarchy
Computer
I/O Devices
CPU
Memory
Cache
ALU
Program
Counter
34
Is-Kind-of Hierarchy
Cell
Muscle Cell
Striate
Smooth
Nerve Cell
Blood Cell
Red
White
Cortical
Pyramidal
35
So where are we right now?
• Three ways to deal with complexity:
– Abstraction
– Decomposition
– Hierarchy
• Object-oriented decomposition is a good methodology
– Unfortunately, depending on the purpose of the
system, different objects can be found
• How can we do it right?
– Many different possibilities
– Our current approach: Start with a description of the
functionality (Use case model), then proceed to the
object model
– This leads us to the software lifecycle
36
Software Lifecycle Activities
...and their models
Requirements
Elicitation
Analysis
Expressed in
Terms Of
System
Design
Structured By
Object
Design
Implementation
Testing
Implemented
By
Realized By
Verified
By
class...
class...
class...
Use Case
Model
Application
Subsystems
Domain
Objects
class....
Solution
Domain
Objects
Source
Code
?
?
Test
Cases
37
UML Overview
• UML is a diagramming standard for
diagrams to aid the design process
– A picture is worth 1000 words (visualization)
– A common picture language helps just like a
common verbal language (English, French,
etc) does.
– UML greatly facilitates object-oriented/architecturecentric design: all of the diagrams but two center on
the object/component structure.
38
History of UML
• A number of researchers (Yourdon, Booch, Rumbaugh,
Jacobson …) proposed OOA&D processes, and with them
different notations.
• During the early 1990's it became clear that these
approaches had many good ideas, often very similar. A
major stumbling block was the diversity of notation, meaning
engineers tended to be familiar with one OOA&D
methodology, rather than the approach in general.
• In the interests of all involved, UML (Unified Modeling
Language) was conceived as a common notation.
39
History of UML (2)
• The original standard was driven by Rational
Software (in which three of the key researchers in
the field, Booch, Jacobson and Rumbaugh were
involved).
• The effort was taken industry wide through the
Object Management Group (OMG), already well
known for the CORBA standard.
• A first proposal, 1.0 was published in early 1997,
with an improved version 1.1 approved that
autumn.
40
What is the UML?
• UML stands for Unified Modeling Language
• The UML combines the best of the best from
– Data Modeling concepts (Entity Relationship Diagrams)
– Business Modeling (work flow)
– Object Modeling
– Component Modeling
• The UML is the standard language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive
system
• It can be used with all processes, throughout the development life
cycle, and across different implementation technologies
41
UML Concepts
• The UML may be used to:
– Display the boundary of a system & its major
functions using use cases and actors
– Illustrate use case realizations with interaction
diagrams
– Represent a static structure of a system using class
diagrams
– Model the behavior of objects with state transition
diagrams
– Reveal the physical implementation architecture with
component & deployment diagrams
– Extend your functionality with stereotypes
42
Three system models in UML
• Class model (static view of objects)
– Class diagram
• State model (dynamic view of objects)
– State diagram
• Interaction model (system behavior/functions,
how objects cooperate)
– Use case (users, actors)
– Sequence diagram
– Activity diagram
43
System models in different views
Interaction model
State model
Class model
44
Class model
• Describes the structure of objects in a
system, a static view
• Class diagram – allows visualization of
individual classes and relationship among
them
45
State model
• Describes aspects (attributes) of objects
that change with time, events that mark
the changes and states that define the
context of events
• State diagram – shows the state & event
sequences permitted for all the classes in
the system
46
Interaction model
• Describes interaction between objects (how
objects collaborate to achieve behavior of the
system as a whole)
• Use case – interaction between system &
actors (7.1.2 in Blaha & Rumbaugh)
• Sequence diagram – time sequence of
interactions between objects (7.2)
• Activity diagram – flow of control during
interaction (7.3)
47
Use-case diagrams 7.1.3
• UML supports a use-case diagram
• It shows the relationships between the
use-cases and the actors (entities
outside the system acting on it)
• For systems with many actors and distinct
activities it can be very helpful
• The symbol for a use case:
48
Actors
• An actor is a type of person - or sometimes another
system – that must use the system that is to be
built.
– Actors are not specific people - they are specific roles
filled by people. Thus, the same person may need to be
regarded as two or more actors if he/she relates to the
system in two or more roles.
– Actors are not part of the system - they are outside the
system boundary and use the system.
– The symbol for an actor:
49
A Use-case diagram contains
• A box representing the system boundary. Use
cases are inside the boundary; actors are
outside. (Note: often, the boundary is omitted,
since the it doesn’t convey any new information)
• The symbol for an actor:
• The symbol for a use case:
• The relationship between an actor and a use
case - a solid line (technically called a
communication association).
50
Use Cases for a Simple
Address Book
51
Example: Address Book
• http://www.cs.gordon.edu/courses/cs211/A
ddressBookExample/index.html
• This is an example to develop an address
book software. It contains all the phases
from requirement to testing &
maintenance.
• Study it carefully.
52
Example: ATM Simulation
• http://www.cs.gordon.edu/courses/cs211/A
TMExample/index.html
• This page is the starting point into a series
of pages that attempt to give a complete
example of object-oriented analysis,
design, and programming applied to a
moderate size problem: the simulation of
an Automated Teller Machine.
53
Example: Stock Brokerage System
• Blaha & Rumbaugh: 8.1.5 p.151
• Actors: customer, security exchange
• Use cases: secure session, manage
account, make trade, validate password…
54
55
Note:
• An actor often is associated with multiple
use cases, and a single use case may be
associated with more than one actor.
• For example, in the ATM System, a
Transaction is associated with both the
Customer and the Bank.
• Use case diagrams can also depict
relationships between use cases.
56
Relationships between use cases
• There are three general ways in which
use cases can be related to each other.
• The generalization relationship is used
when one use case generalizes several
similar use cases. (For example, in the ATM
system the transaction use case is a generalization of
the various specific types of transaction: cash
withdrawal, deposit, etc.)
• UML shows the generalization
relationship by an arrow with its triangular
arrowhead pointing to the parent use case.
57
« include » & « extend » relationships
• The « include » relationship is used when
one use case is contained within another
use case.
• The « extend » relationship is used when
one use case may be extended (under
some circumstances) by some special
behavior that is complex enough to
warrant treating separately.
58
« include »
• « include » is used when the included case
always occurs in the including case, and it
represents a goal the user might actually have,
and/or as common behavior that occurs in
multiple places.
• Example: in an ATM Session, Transaction is an
inclusion, since it represents a customer goal,
and every Session includes one or more
transactions.
• UML notation: a dashed arrow from the base to
the targeted (included) use case.
59
« extend »
• « extend » is used when the extension is
extraordinary (and therefore does not always
occur) and is not actually a user goal.
• Example: in the ATM Session, “Invalid PIN” is an
extension, because it is hard to imagine a
customer having entering an invalid PIN as a
goal, and this does not normally occur as part of
an ATM Session.
• UML notation: a dashed arrow from the
extension to the base use case.
60
Stereotypes
• In UML terminology, « include » and «
exclude » are called stereotypes. You
can think of them as words having special,
technical meanings.
• In UML, stereotypes are always enclosed
in the brackets « ».
61
What use-case diagrams give you
• It can be a very good way to start gathering
the requirements
• They are the "big picture", showing you the
whole system on a single page
• They can help you map fuzzy features onto
more precise use-cases.
62
Use case description
• For each use case, we need to write up a
description of what needs to take place.
This can be done with varying degrees of
formality.
• A simple approach is to create a flow of
events that describes that case.
63
Example use cases: ATM Machine
• Title:Login
Primary Actor: customer
Secondary Actor: bank
Goal: customer gets access to different
account options
• Main Path (Main Scenario)
– insert card
– card id read; prompt and accept PIN input from user
– if correct, display list of choices deposit/withdraw/..
64
Example use cases: ATM Machine (2)
• Title: withdrawal
• Primary Actor: customer
Secondary Actor: bank
Goal: get money from machine
• Main Path (Main Scenario)
–
–
–
–
User presses withdrawal choice
Prompt for checking/savings withdrawal and user indicates
Amount of money entered
Transaction processed and authorized, money is dispensed,
card and receipt returned.
• Alternate Path (Alternate Scenario)
– Transaction not authorized, message displayed
– Card immediately returned
65
Format for Writing Use Cases
• Title which is a capsule summary, and perhaps
a version number
• Actors involved in the use-case (for "actor",
think real-world role, e.g. people: salesperson,
customer; or, computer systems/components:
backend database, web server, etc). The
Primary Actor is the initiator, and the
Secondary(supporting) Actor(s) are any other
actors.
• A Goal stating briefly what the use-case should
do.
• The Pre-Condition of the use-case, a state or
event that causes it to begin.
66
3 kind of actors
• Primary actor
• Supporting actor – providing a service
• Offstage actor – has an interest in the use
case, but not primary or supporting, e.g. a
government tax agency.
67
Format for Writing Use Cases (2)
• The Main Path (Main Scenario) of the use-case,
which is a numbered list of actions described in
English;
• Alternate Paths (Alternate Scenario) of the usecase
• Other things that may be useful to include are
post-conditions that will hold when the case is
all over, UML diagrams associated with the usecase (we cover that below), etc.
68
Stages of requirements engineering
• Requirements elicitation - gathering
information
• Requirements specification - putting the
information into a document
• Requirements validation - checking to
make sure the requirements are consistent
and complete
69
Example
• UIC is planning to build a new science
building.
• The design of the building was based on
input garnered from science division
faculty and others affected by the building
(e.g. the registrar had some input
regarding classroom space, auditorium…).
• A suitable building would have to
incorporate space for various purposes.
70
Requirements Formulation
• The goal is to understand the requirements
placed on the software
• The process goes roughly like this
– Brainstorm, write down some fuzzy ideas and
pictures, then make a feature list;
– Next, make a first pass at the use-cases;
– Check if the features we had in mind were wellcovered; if not, add/modify/refine the use-cases
as well as the GUI sketches, feature list, etc.
71
Feature Lists
You have to start somewhere, so:
• One good first step is to make a feature list, a list
of supported features
• Make some GUI sketches, brainstorm, look at
related software, and produce a feature list.
• This initial data will be helpful in the next step of
refinement, writing out some use-cases.
• Requirement lists are closely related to feature
lists, they are lists of things the software should do,
including features but also including operating
constraints.
72
Vision Statements
• For larger projects you may not even be
able to start with concrete features; at
least start with a vision statement:
• Mainly an English description of what the
application should do.
• This may include a very fuzzy list of
features.
73
Use-cases
• the primary focus of requirements gathering.
• A use-case is a scenario describing a series
of events involving actors which describes
one functionality the system should have.
74
Use Cases drive the development
process
• Before you produce any class designs, you need to
have use cases
• Continually elaborate and expand on the usecases, until they are defined enough to implement.
• Even after implementing you may want to come
back and refine the use-case some more if a
feature was added or missed.
• New use cases will arise as the implementation
evolves, existing use cases may change, and some
use cases may be dropped.
• The project development plan is driven by
implementing use cases:
– "implement these use cases today, those use cases
tomorrow".
75
Requirements & Domain Analysis
• Domain Analysis is a broad term meaning
any activity which increases the
understanding of the underlying domain the
software is working in.
• Most of requirements gathering is in fact
domain analysis.
• One particularly important form of domain
analysis is called domain modeling or
business modeling
76
Domain Modeling
• A Domain model is a conceptual model the
underlying domain, not of the actual program.
• Example: in a restaurant (even without a computer)
the "domain" is the actual, physical restaurant and
some entities in the domain include Orders, Menu
Items, Payments, Receipts, waiters, etc.
• If you want to make a computerized ordering
process it is important to have a precise idea what
is happening in the physical world first.
• One of the best ways to make such a model is to
use UML class and activity diagrams.
77
Domain use cases
• A domain use-case is a use-case which
concerns a process happening in the "real
world" which
– either it needs to be modeled in the software
(e.g. paper invoicing process),
– or the software is to interact with it (e.g. load
pizzas in car, plan route and deliver).
• Domain use cases are, like domain modeling
in general, used to better understand the
application domain.
78
UML and domain modeling
• UML class diagrams are useful for
clarifying the domain entities (real or
imagined) and how they relate.
• UML activity diagrams are useful for
modeling the processes that occur in the
domain.
79
Reading for this lecture
• Chapters 1, 2, 7, 8 Blaha & Rumbaugh
• Study the examples in
– http://www.cs.gordon.edu/courses/cs211/Addr
essBookExample/index.html
– http://www.cs.gordon.edu/courses/cs211/ATM
Example/index.html
80