Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak
Design Process & Interface Design and implementa6on
•  So2ware design and implementa8on is the stage in the so2ware engineering process at which an executable so2ware system is developed. •  So2ware design and implementa8on ac8vi8es are invariably inter-­‐
•  So2ware design and implementa8on is the stage in the so2ware engineering process at which an executable so2ware system is developed. 2 Build or buy
systems (COTS) that can be adapted and tailored to the users’ requirements. •  For example, if you want to implement a medical records system, you can buy a package that is already used in hospitals. It can be cheaper and faster to use this approach rather than developing a system in a conven8onal programming language. •  When you develop an applica8on in this way, the design process becomes concerned with how to use the configura8on features of that system to deliver the system requirements. 3 An object-­‐oriented design process
number of different system models. •  They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-­‐effec8ve. •  However, for large systems developed by different groups design models are an important communica8on mechanism. 4 Process stages
depend on the organiza8on using the process. •  Common ac8vi8es in these processes include: •  Define the context and modes of use of the system; •  Design the system architecture; •  Iden8fy the principal system objects; •  Develop design models; •  Specify object interfaces. •  Process illustrated here using a design for a wilderness weather sta8on. 5 System context and interac6ons
designed and its external environment is essen8al for deciding how to provide the required system func8onality and how to structure the system to communicate with its environment. •  Understanding of the context also lets you establish the boundaries of the system. SeXng the system boundaries helps you decide what features are implemented in the system being designed and what features are in other associated systems. 6 Context and interac6on models
•  A system context model is a structural model that demonstrates the •  A system context model is a structural model that demonstrates the other systems in the environment of the system being developed. •  An interac8on model is a dynamic model that shows how the system 7 System context for the weather sta6on 1
Control
system
1
1
1..n
Weather
information
system
1
Weather
station
1..n
1
1..n
1
Satellite
1
8 Weather sta6on use cases Report
weather
Weather
information
system
Report status
Restart
Shutdown
Reconfigure
Control
system
Powersave
Remote
control
9 Use case descrip6on—Report weather System Weather sta,on Use case Report weather Actors Weather informa8on system, Weather sta8on Descrip8on The weather sta8on sends a summary of the weather data that has been collected from the instruments in the collec8on period to the weather informa8on system. The data sent are the maximum, minimum, and average ground and air temperatures; the maximum, minimum, and average air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direc8on as sampled at five-­‐minute intervals. S8mulus The weather informa8on system establishes a satellite communica8on link with the weather sta8on and requests transmission of the data. Response The summarized data is sent to the weather informa8on system. Comments Weather sta8ons are usually asked to report once per hour but this frequency may differ from one sta8on to another and may be modified in the future. 10 Architectural design
•  Once interac8ons between the system and its environment have been understood, you use this informa8on for designing the system architecture. •  You iden8fy the major components that make up the system and their interac8ons, and then may organize the components using an architectural pabern such as a layered or client-­‐server model. •  The weather sta8on is composed of independent subsystems that communicate by broadcas8ng messages on a common infrastructure. 11 High-­‐level architecture of the weather sta6on «subsystem»
Fault manager
«subsystem»
Configuration manager
«subsystem»
Power manager
Communication link
«subsystem»
Communications
«subsystem»
Data collection
«subsystem»
Instruments
12 Architecture of data collec6on system Data collection
Transmitter
Receiver
WeatherData
13 Object class iden6fica6on
•  Iden8fying object classes is o2en a difficult part of object oriented design. •  There is no 'magic formula' for object iden8fica8on. It relies on the skill, experience and domain knowledge of system designers. •  Object iden8fica8on is an itera8ve process. You are unlikely to get it right first 8me. 14 Approaches to iden6fica6on
•  Use a gramma8cal approach based on a natural language descrip8on of the system (used in Hood OOD method). •  Base the iden8fica8on on tangible things in the applica8on domain. •  Use a behavioural approach and iden8fy objects based on what par8cipates in what behaviour. •  Use a scenario-­‐based analysis. The objects, abributes and methods in each scenario are iden8fied. 15 Weather sta6on descrip6on
A weather sta8on is a package of so2ware controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected periodically. When a command is issued to transmit the weather data, the weather sta8on processes and summarises the collected data. The summarised data is transmibed to the mapping computer when a request is received. 16 Weather sta6on object classes
based on the tangible hardware and data in the system: •  Ground thermometer, Anemometer, Barometer •  Applica8on domain objects that are ‘hardware’ objects related to the instruments in the system. interac8ons iden8fied in the use-­‐case model. •  Weather data •  Encapsulates the summarized data from the instruments. 17 Weather sta6on object classes WeatherData
WeatherStation
identifier
reportWeather ( )
reportStatus ( )
powerSave (instruments)
remoteControl (commands)
reconfigure (commands)
restart (instruments)
shutdown (instruments)
Ground
thermometer
airTemperatures
groundTemperatures
windSpeeds
windDirections
pressures
rainfall
collect ( )
summarize ( )
Anemometer
Barometer
gt_Ident
temperature
an_Ident
windSpeed
windDirection
bar_Ident
pressure
height
get ( )
test ( )
get ( )
test ( )
get ( )
test ( )
18 Design models
•  Design models show the objects and object classes and rela8onships between these en88es. •  Sta8c models describe the sta8c structure of the system in terms of object classes and rela8onships. •  Dynamic models describe the dynamic interac8ons between objects. 19 Examples of design models
•  Subsystem models that show logical groupings of objects into coherent subsystems. •  Sequence models that show the sequence of object interac8ons. •  State machine models that show how individual objects change their state in response to events. •  Other models include use-­‐case models, aggrega8on models, generalisa8on models, etc. 20 Subsystem models
•  Shows how the design is organised into logically related groups of objects. •  In the UML, these are shown using packages -­‐ an encapsula8on construct. This is a logical model. The actual organisa8on of objects in the system may be different. 21 Sequence models
•  Sequence models show the sequence of object interac8ons that take place •  Objects are arranged horizontally across the top; •  Time is represented ver8cally so models are read top to bobom; •  Interac8ons are represented by labelled arrows, Different styles of arrow represent different types of interac8on; •  A thin rectangle in an object lifeline represents the 8me when the object is the controlling object in the system. 22 Sequence diagram describing data collec6on Weather
information system
:SatComms
:WeatherStation
:Commslink
:WeatherData
request (report)
acknowledge
reportWeather ()
acknowledge
get (summary)
summarize ()
send (report)
reply (report)
acknowledge
acknowledge
23 State diagrams
•  State diagrams are used to show how objects respond to different service requests and the state transi8ons triggered by these requests. •  State diagrams are useful high-­‐level models of a system or an object’s run-­‐8me behavior. •  You don’t usually need a state diagram for all of the objects in the system. Many of the objects in a system are rela8vely simple and a state model adds unnecessary detail to the design. 24 Weather sta6on state diagram Controlled
shutdown()
Shutdown
Operation
remoteControl()
reportStatus()
restart()
Running
configuration done
reconfigure()
powerSave()
transmission done
Testing
test complete
Transmitting
clock
collection
done
reportWeather()
Configuring
Summarizing
weather summary
complete
Collecting
25 Interface specifica6on
•  Object interfaces have to be specified so that the objects and other components can be designed in parallel. •  Designers should avoid designing the interface representa8on but should hide this in the object itself. •  Objects may have several interfaces which are viewpoints on the methods provided. •  The UML uses class diagrams for interface specifica8on but Java may also be used. 26 Weather sta6on interfaces «interface»
Reporting
weatherReport (WS-Ident): Wreport
statusReport (WS-Ident): Sreport
«interface»
Remote Control
startInstrument(instrument): iStatus
stopInstrument (instrument): iStatus
collectData (instrument): iStatus
provideData (instrument ): string
27 Key points
•  So2ware design and implementa8on are inter-­‐leaved ac8vi8es. The level of detail in the design depends on the type of system and whether you are using a plan-­‐driven or agile approach. •  The process of object-­‐oriented design includes ac8vi8es to design the system architecture, iden8fy objects in the system, describe the design using different object models and document the component interfaces. •  A range of different models may be produced during an object-­‐oriented design process. These include sta8c models (class models, generaliza8on models, associa8on models) and dynamic models (sequence models, state machine models). •  Component interfaces must be defined precisely so that other objects can use them. A UML interface stereotype may be used to define interfaces. 28 Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Typical Design Errors"
q lack of consistency
q too much memorization
q no guidance / help
q no context sensitivity
q poor response
q Arcane/unfriendly
30 Golden Rules
•  Place the user in control
•  instead of ? •  Reduce the user’s memory load •  dos vs. windows? •  Make the interface consistent for the user …btw, who’s the user?"
"
Should the user work with the designer, then, during UI design?"
Place the User in Control
•  Define interac8on modes in a way that does not force a user into unnecessary or undesired ac8ons. •  Allow user interac8on to be interrup8ble and undoable. •  Streamline interac8on as skill levels advance and allow the interac8on to be customized. •  linear text vs. pie chart? •  Design for direct interac8on with objects that appear on the screen. •  how? any examples? Reduce the User’s Memory Load
•  Reduce demand on short-­‐term memory. •  how many? •  Establish meaningful defaults. •  Define shortcuts that are intui8ve. •  The visual layout of the interface should be based on a real world metaphor. •  Disclose informa8on in a progressive fashion Make the Interface Consistent
•  Allow the user to put the current task into a meaningful context. •  Maintain consistency across a family of applica8ons. •  If past interac8ve models have created user expecta8ons, do not make changes unless there is a compelling reason to do so. BuRon piSalls
Maintain consistency
n  Don’t make your users think!
n 
User Interface Consistency
•  The Principle of Least Surprise •  Similar things should look and act similar •  Different things should look different •  Other proper8es •  Size, loca8on, color, wording, ordering •  Command/argument order •  Pre-­‐fix vs. post-­‐fix •  Follow planorm standards User Interface Design Process
Interface Analysis
•  Interface analysis means understanding •  the users who will interact with the system through the interface; •  the tasks that end-­‐users must perform to do their work, •  the content that is presented as part of the interface •  the environment in which these tasks will be conducted. User Analysis
•  Are users trained professionals, technician, clerical, or manufacturing workers? •  Are the users capable of learning from wriben materials or have they expressed a desire for classroom training? •  Are users expert typists or keyboard phobic? •  What is the age range, gender, primary spoken language of the user community? •  Is the so2ware to be an integral part of the work users do or will it be used only occasionally? •  Are users experts in the subject maber that is addressed by the system? Task Analysis and Modeling
•  Answers the following ques8ons … •  What work will the user perform in specific circumstances? •  What tasks and subtasks will be performed as the user does the work? •  What specific problem domain objects will the user manipulate as work is performed? •  What is the sequence of work tasks—the workflow? •  Use-­‐cases define basic interac8on •  Task elabora8on refines interac8ve tasks •  Object elabora8on iden8fies interface objects (classes) •  Workflow analysis defines how a work process is completed when several people (and roles) are involved patient
pharmacist
physician
Swimlane Diagram
r e q u e sts th at a
p r e scr ip tio n b e r e f ille d
d e te r min e s statu s o f
p r e scr ip tio n
no refills
remaining
refills
remaining
ch e cks in v e n to r y f o r
r e f ill o r alte r n ativ e
r e ce iv e s o u t o f sto ck
out of stock
ch e cks p atie n t
r e co r d s
approves refill
refill not
allowed
e v alu ate s alte r n ativ e
me d icatio n
n o tif icatio n
alternative
available
in stock
r e ce iv e s tim e /d ate
to p ick u p
p icks u p
p r e scr ip tio n
r e ce iv e s r e q u e st to
co n tact p h y sician
none
f ills
p r e scr ip tio n
Analysis of Display Content
•  Are different types of data assigned to consistent geographic loca8ons on the screen (e.g., photos always appear in the upper right hand corner)? •  Can the user customize the screen loca8on for content? •  Will graphical output be scaled to fit within the bounds of the display device that is used? •  How will color to be used to enhance understanding? •  How will error messages and warning be presented to the user? Why study user interfaces?
•  Good UIs are cri8cal to success •  UI programming is •  easy (sophis8cated algorithms not required) •  straighnorward (can immediately correct mistakes) •  fun (results are immediately visible) •  ra8onal (apply simple rules) •  UI design is not graphic design User Model
Cardinal axiom
•  “A user interface is well-­‐designed when the program behaves exactly how the user thought it would.” – Joel Spolsky •  user is happy = user in control = S/W correctly interprets user’s ac8ons •  loss of control à depression, frustra8on (“Learned Helplessness” [Seligman]) •  All the other rules are just corollaries: •  Golden rules: place user in control, reduce user’s memory load, make interface consistent User and program models
•  User model: User’s idea of what’s happening •  Program model: Program’s idea of what’s happening (i.e., what’s actually happening) •  Successful UI when program model corresponds to user model •  Speak user’s language •  Follow real-­‐world conven8ons, make informa8on appear in natural and logical order •  Use metaphors from real world Example
•  Pictures in documents are •  embedded in word processor (e.g., Word) •  not embedded in HTML •  With WYSIWYG HTML editor (e.g., FrontPage), what do you do? •  change user model (describe in manual, explain with popup dialog box) •  change program model (make copy of picture in subfolder) How do you get the user model?
•  Ask the users! •  The 50-­‐cent usability test •  Usually 5-­‐6 people is enough, will start to see consensus •  Don’t need formal usability lab, or “people off the street” •  Just sketch or prototype and ask your neighbor User models are simple
•  If your program model is nontrivial, it’s probably wrong Click here
This window comes to top!
(“invisible sheets” in Excel)
Choices
•  “Every 8me you provide an op8on, you're asking the user to make a decision.” – Joel Spolsky This is “unequivocally the most
moronic ‘wizard’ dialog in the
history of the Windows operating
system. This dialog is so stupid
that it deserves some kind of
award. A whole new category of
award.”
Too much freedom is dangerous
floating menu bar
huge system tray
How many users want these?
Metaphors
vs.
Also desktop, folders, paintbrush, ... Affordance
afford – to make available or provide naturally (door with metal plate affords pushing) vs.
(30% usability)
(100% usability)
Affordance (cont.)
Where to grab?
Where to click?
What to drag?
Consistency, not crea6vity
•  “A foolish consistency is the hobgoblin of lible minds” – Emerson •  Applica8on should be consistent with itself and with other programs •  Examples: FrontPage, Visio •  Beware of crea8vity: • 
• 
• 
• 
• 
Less like user model More work to implement Do not leverage future/hidden features “Just because Microso2 does it, doesn't mean it's right” Examples: Tab from name to password, Netscape’s reimplementa8on of common controls Make explana6ons brief
•  “Users don’t read the manual” – Spolsky •  May not have the manual (on airplane, demo version) •  Too busy / distracted / impa8ent •  “Users don’t read anything” – Spolsky •  advanced too busy •  novice hope defaults are ok •  in-­‐between try to read but get confused vs.
Many users are in6midated by computers
vs.
vs.
(no dialog)
Which is better for an intimidated user?
Users can’t control the mouse well
•  What’s the problem? • 
• 
• 
• 
sub-­‐op8mal poin8ng devices bad condi8ons (dirty, old, or cheap mouse; crowded desk) medical disabili8es (young, old, arthri8s, ...) in a hurry •  “Mile-­‐high menu bar” •  Macintosh: slam mouse to top, get menu •  Windows: ½ by ¼-­‐inch target •  Easiest places to point: four corners •  (Windows 95 start menu blunder: 2 pixels from corner) •  Programmers generally s8ck to 0, 1, or n •  They want to avoid magic numbers (Why can you only open 20 windows?) •  But all n>1 are not equally likely (window close to edge should snap in place) Don’t tax the user’s memory
•  Make objects, ac8ons, and op8ons visible •  User should not have to remember (too much) informa8on Some bad designs
adaptive
menu
office
“assistant”
What principle
is being violated?
Ac6vity-­‐based UI
•  Two ways of designing UI: •  What features should be there? •  Gree8ng card example: add text, add picture, get predesigned card from library, send by email, print •  What ac8vi8es will users do? •  Gree8ng card example: birthday gree8ng, party invita8on, anniversary gree8ng (leads to unexpected features: remind to send next year) •  Example: •  Excel was designed for financial number-­‐crunching, but many use it for lists •  Improv was to be “killer app” for NeXT •  great for complicated mul8-­‐dimensional financial models •  painful for lists Open-­‐ended vs. sequen6al opera6on
•  History of UI goes back-­‐and-­‐forth b/w •  user-­‐in-­‐control (command-­‐line, Word, ...) •  sequen8al steps (wizards, ...) vs.
Dangers of color
Driving at night in San Jose, where the street lights are yellow
traffic light
is green
traffic light
is yellow
Color Rules
Color Meanings