ENG1003 Lecture Notes - Lecture 8: Website Wireframe, Unified Modeling Language, Crystal Computing
30 May 2018
School
Department
Course
Professor
Aim:"""to"create"a"design that"satisfies"the"requirements,
Simple to"build,"maintain,"test"and"extend"&"understand
how"to"implement"required"functionality of"software
high"cohesion,"low"coupling
Why'important to"make"plan"before"coding"right"off"the"bat?
Less"development"effort
•
Code"that"is"easier"to"understand"and"maintain"in"the"long"run
•
Audience:
Software"engineers
Interface"designers
Quality"assurance"testers
Client
Design"artefacts"generally"used"during:
Design"phase
•
Implementation
•
Maintenance/extension"of"
software
•
By"clients"and"software"engineers"
Class'diagrams'(specified"as"part"of"the"Unified"Modelling"Language"specificatn)
="easy-to-read"visual"representation"of"system"structure
Skeleton"of"code"-assists"with"planning
Shared"with"clients
Used"for"discussion on"proposed"system"in"the"analysis"and"design"stages,"and"
then"as"reference in"implementation"phase
Shows"each"class"in"the"system"as"a"rectangle
Visually"explaining"associations"between"classes"using"connecting"lines"
with"additional"annotations
Formal class"diagrams:"close"mapping"to"code"of"the"application
AKA"precisely"denoting"attributes"&"interface"of"class
Eg."representation"of"a"class"lists:
Class"name;"attributes"and"methods;"(sometimes"even)"data"types"of"
method"parameters"and"return"values
Multiplicity
="number"indicating"how"many"objects"of"each"class"are"involved"in"each"
association"connecting"classes
0..1,"0..*,"1..*""[*"being"infinity]
Can"also"be"represented"by"number"of"arrowheads"(1="one,"2="multiple)
[function() : data type]
Terminology
Lehmann/JS Class'diagram'
Class Box
Class"name First"row"of"box
Middle"section"of"each"box
+"
-
Attributes
Public"(by"all"code)
Private"(by"code"within"class)
Third"section"of"each"box:"methods
(---)
Operations
Method"parameters
Relationship Line"of"association"indicating"their"
relationship
ASSOCIATION
Filled-in"diamond"@"Deck"-->"composition/Cards"won't&exist&w/o Deck"-
diff"frm"just"an"arrow
•
Numbers"on"each"end"are"multiplicities"(indicating"1"Deck"obj"always"
contains"52"Card"objs)
•
set value (newValue : Number) --> (single parameter,
data type returned)
Cohesion"and"Coupling (design"goals"for"classes)
Cohesion ="how"conceptually"related"functionality"is
Ideally"high"--- all"data"and"methods"grouped"in"the"class"are"logically"
related
•
Coupling ="dependencies"between"classes
Ideally"low"--- classes"individual"and"self-contained"with"minimal"
dependency
•
Generalisation
="when"one"class"offers"a"superset"of"functionality"of"another"-a"special"
relationship!
Reverse"="specialisation•
Can"be"implemented"via"inheritance"in"code"(inheritee"-->"inheritor)•
Eg."Person"is"a"generalisation"of"Student,"Vehicle"is"a"generalisation"of"
Car/Bus/Bike
Conceptual class"diagrams
="very"informal,"plain-language"versions"often"used"to"model"problem"domains
Often"transitioned"into"formal class"diagrams"by:
Adding"data"types"to"class"attributes,"return"types"and"method"
parameters
•
Describing"any"programming"language"specific"features•
Prototyping'and'UI'Design
Used"by"clients"and"software"engineers"implementing"the"proposed"
interface
Eg."Shade"Dogs,"an"educational"game
Prototyping ="planning"the"layout and"behaviour of"the"user"interface
AKA"mocking"up"simple"representations"of"the"interface
To"demonstrate interaction"and"understand"how the"interface"will"
be"used"for"particular"tasks
Very"useful"for"communicating"ideas
Provides"mechanism"for"testing idea"feasibility,"clarification"
facilitation"and"requirement"validation
Allows"users"or"clients"to"react to"the"design"and"suggest"changes
Wireframing
="sketches"of"user"interfaces"showing"mock"data/skeletal"view
="basically"a"still"from"a"storyboard"with"transitions"removed
Gives"sense"of"user"interface"before"any"code"is"written"(AKA"work"is"
done)
•
Can"be"sketched"by"hand"OR"created"using"simple"drawing"software"
using"lines"and"text"OR"screenshots
•
Very"sketchy"just"to"show"not"finished"yet"-->"get"better"feedback•
Storyboards
="a"sequence"of"user"interface"steps"(wireframe sketches"or"more"
designed"interface"mockups)"and"connecting"transitions"used"for"
simulating"interaction
="essentially"linked"wireframes
Steps"connected"to"each"other"by"arrows"&"annotations
Illustrating"how"user"interaction"results"in"change"to"user"
interface
Show"flow"and"progression"through"a"task•
Gives"understanding"of"navigation,"flow"and"story"of"an"app
Can"be"discussed"w/"clients"and"iterated"btwn"designers"and"
software"engs
○
•
Wireframe VS"interface"
(like"floor'plan VS"house)
Simplistic"view"of"user"interface
where"info"should"be"displayed,"
what"user"needs"to"do"to"access"
settings
Basically"lets"you"work"out"
how"user"interacts"with"
interface
Remb:"for loop"goes"
straight"to"condition"i"
<"5"after"var"i"="0,"and"
can"go"straight"down"to"
NO"without"repeating"
once!
Counter-
controlled
•
while loop:
Sentinel-
controlled
•
Activity'diagrams'
="used"to"document"workflows"and"overall"system"behaviour
AKA"flowcharts"for"software
Can"show"parallel"processing,"or"multiple"users/systems"components"interacting"
simultaneously
•
Week$8:$Software$Design
Sunday,"23"April"2017
15:45
Aim:"""to"create"a"design that"satisfies"the"requirements,
Simple to"build,"maintain,"test"and"extend"&"understand
how"to"implement"required"functionality of"software
high"cohesion,"low"coupling
Why'important to"make"plan"before"coding"right"off"the"bat?
Less"development"effort•
Code"that"is"easier"to"understand"and"maintain"in"the"long"run•
Audience:
Software"engineers Interface"designers Quality"assurance"testers Client
Design"artefacts"generally"used"during:
Design"phase•
Implementation•
Maintenance/extension"of"
software
•
By"clients"and"software"engineers"
Class'diagrams'(specified"as"part"of"the"Unified"Modelling"Language"specificatn)
="easy-to-read"visual"representation"of"system"structure
Skeleton"of"code"-assists"with"planning
Shared"with"clients
Used"for"discussion on"proposed"system"in"the"analysis"and"design"stages,"and"
then"as"reference in"implementation"phase
Shows"each"class"in"the"system"as"a"rectangle
Visually"explaining"associations"between"classes"using"connecting"lines"
with"additional"annotations
Formal class"diagrams:"close"mapping"to"code"of"the"application
AKA"precisely"denoting"attributes"&"interface"of"class
Eg."representation"of"a"class"lists:
Class"name;"attributes"and"methods;"(sometimes"even)"data"types"of"
method"parameters"and"return"values
Multiplicity
="number"indicating"how"many"objects"of"each"class"are"involved"in"each"
association"connecting"classes
0..1,"0..*,"1..*""[*"being"infinity]
Can"also"be"represented"by"number"of"arrowheads"(1="one,"2="multiple)
[function() : data type]
Terminology
Lehmann/JS
Class'diagram'
Class
Box
Class"name
First"row"of"box
Middle"section"of"each"box
+"
-
Attributes
Public"(by"all"code)
Private"(by"code"within"class)
Third"section"of"each"box:"methods
(---)
Operations
Method"parameters
Relationship
Line"of"association"indicating"their"
relationship
ASSOCIATION
Filled-in"diamond"@"Deck"-->"composition/Cards"won't&exist&w/o Deck"-
diff"frm"just"an"arrow
•
Numbers"on"each"end"are"multiplicities"(indicating"1"Deck"obj"always"
contains"52"Card"objs)
•
set value (newValue : Number) --> (single parameter,
data type returned)
Cohesion"and"Coupling (design"goals"for"classes)
Cohesion ="how"conceptually"related"functionality"is
Ideally"high"--- all"data"and"methods"grouped"in"the"class"are"logically"
related
•
Coupling ="dependencies"between"classes
Ideally"low"--- classes"individual"and"self-contained"with"minimal"
dependency
•
Generalisation
="when"one"class"offers"a"superset"of"functionality"of"another"-a"special"
relationship!
Reverse"="specialisation•
Can"be"implemented"via"inheritance"in"code"(inheritee"-->"inheritor)•
Eg."Person"is"a"generalisation"of"Student,"Vehicle"is"a"generalisation"of"
Car/Bus/Bike
Conceptual class"diagrams
="very"informal,"plain-language"versions"often"used"to"model"problem"domains
Often"transitioned"into"formal class"diagrams"by:
Adding"data"types"to"class"attributes,"return"types"and"method"
parameters
•
Describing"any"programming"language"specific"features•
Prototyping'and'UI'Design
Used"by"clients"and"software"engineers"implementing"the"proposed"
interface
Eg."Shade"Dogs,"an"educational"game
Prototyping ="planning"the"layout and"behaviour of"the"user"interface
AKA"mocking"up"simple"representations"of"the"interface
To"demonstrate interaction"and"understand"how the"interface"will"
be"used"for"particular"tasks
Very"useful"for"communicating"ideas
Provides"mechanism"for"testing idea"feasibility,"clarification"
facilitation"and"requirement"validation
Allows"users"or"clients"to"react to"the"design"and"suggest"changes
Wireframing
="sketches"of"user"interfaces"showing"mock"data/skeletal"view
="basically"a"still"from"a"storyboard"with"transitions"removed
Gives"sense"of"user"interface"before"any"code"is"written"(AKA"work"is"
done)
•
Can"be"sketched"by"hand"OR"created"using"simple"drawing"software"
using"lines"and"text"OR"screenshots
•
Very"sketchy"just"to"show"not"finished"yet"-->"get"better"feedback•
Storyboards
="a"sequence"of"user"interface"steps"(wireframe sketches"or"more"
designed"interface"mockups)"and"connecting"transitions"used"for"
simulating"interaction
="essentially"linked"wireframes
Steps"connected"to"each"other"by"arrows"&"annotations
Illustrating"how"user"interaction"results"in"change"to"user"
interface
Show"flow"and"progression"through"a"task•
Gives"understanding"of"navigation,"flow"and"story"of"an"app
Can"be"discussed"w/"clients"and"iterated"btwn"designers"and"
software"engs
○
•
Wireframe VS"interface"
(like"floor'plan VS"house)
Simplistic"view"of"user"interface
where"info"should"be"displayed,"
what"user"needs"to"do"to"access"
settings
Basically"lets"you"work"out"
how"user"interacts"with"
interface
Remb:"for loop"goes"
straight"to"condition"i"
<"5"after"var"i"="0,"and"
can"go"straight"down"to"
NO"without"repeating"
once!
Counter-
controlled
•
while loop:
Sentinel-
controlled
•
Activity'diagrams'
="used"to"document"workflows"and"overall"system"behaviour
AKA"flowcharts"for"software
Can"show"parallel"processing,"or"multiple"users/systems"components"interacting"
simultaneously
•
Week$8:$Software$Design
Sunday,"23"April"2017 15:45
Document Summary
Aim: to create a design that satisfies the requirements, Simple to build, maintain, test and extend & understand how to implement required functionality of software high cohesion, low coupling. Code that is easier to understand and maintain in the long run. Software engineers interface designers quality assurance testers client. Class diagrams (specified as part of the unified modelling language specificatn) Used for discussion on proposed system in the analysis and design stages, and then as reference in implementation phase. Shows each class in the system as a rectangle. Visually explaining associations between classes using connecting lines with additional annotations. Formal class diagrams: close mapping to code of the application. Aka precisely denoting attributes & interface of class. Class name; attributes and methods; (sometimes even) data types of method parameters and return values. = number indicating how many objects of each class are involved in each association connecting classes. Can also be represented by number of arrowheads (1= one, 2= multiple)
