1. sports
2. skating
3. figure skating

Software Innovation
Ivan Aaen
Institut for datalogi – Aalborg Universitet
23. oktober 2012
tirsdag 23. oktober 2012
Nogle grundbegreber
•
•
•
•
•
tirsdag 23. oktober 2012
Ide
Kreativitet
Innovation
Problem ≠ opgave
Metode ≠ metodologi
Emphasis on Structures
•
Roles: Personal responsibilities and
knowledge
•
•
Views: Defined common viewpoints
tirsdag 23. oktober 2012
Vision: Representation and maturation of
research and project vision
196 _____________________________________________________________ Components
The Generic Architecture Pattern
You can use the layered architecture to elaborate basic systems that include interface, function, and model components. The model component,
containing the model of the object system, can be the lowest layer, followed
by a system functions layer and, on top, the interface component. You can
often decompose the interface layer into two separate parts: user interface
and system interface. Figure 10.5 shows this simple and basic architecture.
«component»
Interface
«component»
User interface
«component»
System interface
«component»
Function
Project
«component»
Model
«component»
Technical platform
«component»
«component»
«component»
_______________________________________________________________
UIS
DBS
NS
Prioritize _______________________________________________________________ 185
9.4 Prioritize
Method
Having considered the general object-oriented criteria and the specific conditions, you can now prioritize which criteria should govern your design activity. This helps you convert OOA&D to a specific strategy for your project,
supports the planning of evaluation activities, and helps you decide when
the design process is complete. The table in Figure 9.4 can serve as a checklist in this process. You can assign priorities to the classical software-quality criteria, and add criteria that reflect your specific design conditions.
Users
Other
Figure
10.5: The generic architecture pattern
for asystems
system
In most cases, it is a good idea to incorporate components that serve as
well-defined interfaces to certain parts of the technical platform. With the
basic architecture, you can, for example, have an interface to the library
that implements the user interface. This library can be encapsulated in a
separate user-interface system component (UIS). You can do the same
thing with a database system (DBS) that stores the model contents, and
with communication or network software (NS) that implements the systems interface. You can construct
these three components as parts of a layInterface
er, which at the lowest level makes up the interface to, and thus encapsu-
Very important
Functions
Model
System
70 ________________________________________________________________ Structure
Figure
1.2:1 A general system architecture
Customer
Important
Less important
Irrelevant
Easily
fulfilled
Usable
Process
Product
Criterion
Secure
Efficient
Correct
Reliable
Maintainable
Testable
Flexible
Comprehensible
r concentrate our efforts on points
of uncertainty in the system6s imReusable
0..∗
0..∗ to the programming activities.
ntation and leave the rest
Portable
Appointment
reasonable architecture gives us
an overview of the system. Even
1
Interoperable
systems contain so1 many classes and objects that the system easily
Additional
\
1
1..∗
mes unwieldy. AsEmployee
a tool for
handling
system
Day
Schedule complexity, OOA&D uses
criteria
\
\
1
onents, which are groups of classes and objects.
\
entifying the relevant components in a concrete system is a crucial is1..∗
Figure 9.4: Checklist for prioritizing design criteria
object-oriented
The choice of architecture will
always reflect
Apprenticedesign.
Assistant
26 ____________________________________________________________ System Choice
164 _______________________________________________________________
Interfaces
Time Period
ncrete situation, and selecting one is a highly iterative process. In
Quality assurance follows classical plan-do-check-act cycles. These activiDescribe
the Situation
&D, we start with a very basic architecture with three components: a
ties 2.3
underline
the iterative
nature of system development and especially of
Our understanding of the users8 situation must be rich and abundant. To
______________________________________________________
1
design. They are repeated for different parts and versions of the design, and
component, a function component,
and an interface Behavior
component.
achieve this, we must be open and disposed toward discussion. Thus, we
the
termination
of
one
cycle initiates the planning of the next. At this stage,
Free which reflects
Other
gure 1.2 shows this basic Work
architecture,
the system6s
emphasize the following principle:
you should consider how to evaluate (check) the system and its parts. Basixt. The model component contains a dynamic model of the system6s
the situation.
cally, twoPrinciple:
methods Appreciate
are relevant:
reviews and experiments. Given these
Gardener
Figure 4.1:
Class diagram for the Hair Salon System (Chapter 20)
tomer
em
domain. We
structure
the model component to agree with the usmethods, several questions arise. Which quality criteria and which parts of
account opened
By working with Erich pictures,F we can explicate important user views of a
System
ew of thetural
problem
domain,
and update
important
changes ocrelations between
the(date)
classes
and objects it
in when
our model.
Figure 4.1
situation, facilitate debate, and get an overview of the situation quickly.
Application
shows an example
of adomain
class diagram.
n an air traffic
control
system,
the model component contains a repreThe purpose here is not to create a detailed description of all possible ciraccount closed
cumstances, but rather to obtain an overview.
tion of planes,
flight departures, flight corridors, positions, and the re4.1 Object-Oriented Structures(date)
Open
s amongWhen
them.
we extend our problem-domain model with object-oriented strucRich Pictures
tures, we continue to employ the fundamental distinction between object
he function
component contains the facilities through which users upA rich picture is an informal drawing that presents the illustrator8s underand class introduced in Chapter 3.
the concrete
object level, we
ask: What
are the specific
relations
bend use theOn
model
component.
When
planes
change
position
in the airstanding of a situation. Figure 2.2 shows an example of a rich picture from
tween objects in the problem domain? To answer this, we view a phenomea hospital8s system development project. The rich picture describes a
air space,
detects
the
movement
andproperties
sendsthat
a signal
to a system
Problem
domain
nonradar
in the problem
domain
as an
object, with
certain
deterchange from six autonomous wards to a new structure in which the wards
amount
deposited amount withdrawn
Greenhouse1
mine
its
identity,
state,
and
behavior.
For
example,
we
might
consider
a
e function which
changes the
model component6s state. If the model
become part of a larger unit. The purpose of this organizational change is to
amount)
(date,
person (date,
as a company
employee,
butamount)
not as a family member or a person
Find Actors
and Use Cases _______________________________________________ 127
improve coordination and resource sharing among the wards.
onent6s state
shows hobby.
thatIntwo
planes
are
about
toobject,
collide,
a warning
with a particular
viewing
this person
as an
employee
we
122 ___________________________________________________________________Usage
Figure
8.15:
The
context
for
a
greenhouse-monitoring
system
on her name, address, department, and salary. At the same time we
on sendsfocus
a
signal
to
air
traffic
controllers
that
the
planes6
flight
coursignore
such properties
as spouse,
hobbies,
political opinion,
and so
#1
1: A simple
statechart
diagram
forchildren,
a class
JCustomerL
in aclasses
bank
beenon.read.
During
execution,
one
object
from
each
of
these
two
typiTradition vs.
This illustrates
how, through what is denoted as abstraction, we simpliuld be changed
immediately.
insert card
Card inserted
cally exists for each of the devices that should be read. When the device obchange
Choosing the System______________________________________________________ 25
ject performs a read, it calls the operation CmeasurementD in the memory
payment
prompt for code
Individual info.
he result
iswhich
expressed
graphically
in athat
statechart
diagram,
as
#2
object,
takes care
of storing the value
was read. With
regards to
the
rest
of
the
system,
the
memory
object
serves
as
the
interface
to
the
exFigure 5.1.
Waiting for code
«actor»
Paradigm
ternal device through a call to the operation Clatest-value,D which returns a
desired readingFtypically the latest. If more readings must be stored, the
vioral Pattern and Attributes
reject
Exit
name
n entityGreenhouse
with identity,
state, and behavior. In the
class activiClicking here terminates
Greenhouse 1set of second
the system’s
execution an
havior simply
as the unordered
events that
involve
Temperature display
Theactivity,
temperature is shown
behavior
we describe behaviorminute
more precisely by add15 min.
in both digital and analog
24
Choice of period
ve timing
is
defined
by
an event
formof events. An objectFs behavior
hour
User chooses the time
over which the
Choice of display
hibits a certain
ordering of events
over
time: interval
current
average
average should be
User chooses whether to
continuously show the
«actor»
Account
owner
enter code
calculated
race: Acurrent
sequence
value or the of events involving a specific object.
Waiting for amount
choose amount
Liquidity
monitor
Situation
#3
Ideas
cancel
payment
Amount approved
approve amount
«actor»
Creditor
Standard info.
#4
account
information
registration
tirsdag 23. oktober 2012
Resources
#5
Systems
«actor»
Administrator
Amount chosen
monitoring
ce is unique for a specific object; it is the precise event amount
se- not approved
Figure 8.16:
diagram
for a greenhouse
he object is involved
in Window
during
a time
interval.system
For example,
Figure 6.5: Statechart diagram for Ocash withdrawalP
error correction
he class JCustomerL in Figure 5.1 might have the following
uring its lifetime:
in the target system. We delimit a use case based on the specific actors?
Figure 6.3: Use-case diagram for the automatic payment system
object-oriented problem-domain analysis is on objects,
Reorganizing
Personnel info.
credit
information
System definition
Plans
#6
average over the selected
period
pened M amount deposited M amount withdrawn M
t deposited M account closed
Pool
money transfer
Code entered
code accepted
cash withdrawal
Coordinating
New entity
Figure 2.1: Subactivities in choosing a system
viewpoint and application-domain tasks. The goal is to collect the many
an actor table or a use-case diagram. We prefer the actor table, as it
possible ways of using the target system in a few well-chosen either
use cases.
consumes
less space; UML recommends the use-case diagram.
Taken together, your use cases should give an overview; individually
they
The account owner is involved in four use cases: payment, cash withshould be abstractions that are both logical and meaningful to the
involved
drawal, money transfer, and account information. Credit card payments alAs Figure
but
for
actors.
ways occur through the creditorEan interactive process involving both actors.
Cash withdrawals occur at publicly accessible ATM machines, which
You can produce a list of possible use cases by examining the
applica-
2.2 Choosing the System
2.1 shows, system choice is based on three subactivities. The first
Figure 2.2: Example of a rich picture with focus on change
Report
Paradigm
tirsdag 23. oktober 2012
Example:
Little Red Riding Hood App
•
Little Red Riding Hood is either at home
or at her friends’ home. Both places are
too far away from Granny’s house to
walk, so she has to take a bus
•
If Little Red Riding Hood fails to show up
at her Granny’s house at the expected
time, Granny will get very upset and call
anyone from the King down
•
There are three busses available to the
woods, lines A, B, and C
•
•
She must avoid Mr. Wolf and not come
near his house, but some trails in the
woods come dangerously close to it
The parents want to know how things
are going when she is under way to
Granny
•
The parents use laptops and mobile
phones
•
She is great friends with Mr. Hunter, and
he will come to her rescue if alarmed
•
•
Granny is old but young at heart. She is
used to text messages and computers
Little Red Riding Hood is a dashing young
lady sporting a posh, top-of-the-line
smartphone with compass, GPS,
gyroscopes, accelerometers, etc.
•
Still, she is very young and not used to
busses. She might miss a stop, take a
wrong direction, get off the bus too early,
etc.
•
And even though she has a sophisticated
smartphone, she is not a seasoned user
of it
•
tirsdag 23. oktober 2012
Granny dislikes unexpected knocking on
her door, and wants guests to make an
appointment first
Example: Paradigm
tirsdag 23. oktober 2012
Example: Paradigm
iPhone
10:15 PM
iPhone
10:15 PM
NO!
NO!
Ta
k
el
e ft
Ta
k
tra
il
Take GrannyTrail
Silent Alarm
tirsdag 23. oktober 2012
el
eft
tr a
il
Take GrannyTrail
Go normal
Example: Paradigm
In the woods
Safe
Scared
Departure
Arrival
On
track
Lost
Scared
Visible
tirsdag 23. oktober 2012
Hidden
Product
tirsdag 23. oktober 2012
Example: Product
tirsdag 23. oktober 2012
Project
tirsdag 23. oktober 2012
Example: Project
tirsdag 23. oktober 2012
Example: Project Research Strategy
tirsdag 23. oktober 2012
Poka Yoke
strategy?
Feasibility: Can
NFC validate
bus and
payment?
Avoid wrong bus
Validate bus and
payment and
enforce
response
Example: Project Research Strategy
tirsdag 23. oktober 2012
Can Fast Fourier
Transformation
be used?
Feasibility: Can
we see if she is
hurtling?
Can we use gait
to determine if
she is scared?
Hurtling
detection
Example: Project -Vision
as Elevator Pitch
For Little Red Riding Hood and family
Who wants to ensure a safe visit to her granny
The LRRH Travel Aid is a smartphone app
That guides her way, helps calling for help, and keeps her family
informed
Unlike ordinary travel aid apps
Our product has a dual focus on travel aid and safety
tirsdag 23. oktober 2012
Toulmin Structure Vision
Challenge
Grounds
Qualifier
Warrant
tirsdag 23. oktober 2012
Rebuttal
Idea
Process
tirsdag 23. oktober 2012
Example: Process
tirsdag 23. oktober 2012
Example: Process Evaluation
© 2012 Ivan Aaen, draft - do not quote without permission
Strengths
Simple to implement
Effective Poka-Yoke solution
Weaknesses
Requires NFC enabled smartphone
Requires NFC-based ticketing systems
Might frustrate user
Bus data might be inaccurate
Opportunities
Threats
Can prove useful for later travel apps if Privacy and security issues?
we identify a broader market
The bus company may not cooperate
NFC-based ticketing may not be available yet
Figure 6.2: SWOT analysis of Near Field Communication (NFC) research
Value Analysis tries to identify potential gains from the research and this method
therefore is more focused than SWOT. Our example (Figure 6.3) evaluates the
potential in researching panic identification based on step detection.We are contirsdag 23. oktober 2012
Using PMI (Figure 6.5) we list what we think are strengths (Plus), weaknesses
(Minus) and what could be interesting aspects and features (Interesting) of these
three ideas. Our analysis shows that none of these ideas can detect hiding behavior alone. Each idea has severe weaknesses and important strengths, and each of
them may be combined with the others.
Evaluation
Idea
Plus
No movement
Step detection
Standing still may
(few or slow steps) not imply hiding
Stationary GPS
May be combined
with the other two
ideas
Location good for
hiding
Combines GPS
and maps
Position accuracy
Map accuracy
May be combined
with the other two
ideas
Does not detect
hiding with no
movement
May be combined
with the other two
ideas
Furtive movements Step detection
(unique pattern)
GPS (furtive
means slow)
Minus
Interesting
Figure 6.5: PMI-evaluation of ideas for identifying hiding
Based on these observations, the recommendation could be to go on by combining two or three of these ideas into one. No movement and furtive movement
could
easily be combined into one feature. The location idea relies on extirsdag 23.
oktoberprobably
2012
Afrunding
tirsdag 23. oktober 2012
Nogle grundprincipper
•
•
•
•
•
tirsdag 23. oktober 2012
Learning by doing
Diversitet
Eksperimentel udvikling
Inkrementel udvikling
Usikkerheder
Eksempler til
undervisning
•
Fysioterapi i hjemmet ved brug af Kinect
eller WII og Skype
•
Rundvisningsguide til frilandsmuseum
baseret på smartphone
tirsdag 23. oktober 2012