Post on 20-Jun-2018
transcript
CISC 323Introduction to Software Engineering
Week 3
OOP, UML, Software Process
Lectu re 1 : Software Process
��� � �� �� � �� � � � � �� ��� � � � � � � �� � � � � �� � � � � ���� � � �� � � � � �� � �� � � � � � �� ��
Software Process
• T o m an ag e com p l ex i ty of software, req u i re a process th at cod i fi es th e acti v i ti es of software d esi g n , d ev el op m en t an d v al i d ati on
• T h ere are m an y p rocesses. W h i ch on e i s correct d ep en d s on th e d esi red q u al i ty attri b u tes of th e sy stem u n d er con stru cti on .
• Process m od el : d escri b es p rocess
• R ea d i n g : B ah ram i C h ap ter 3
��� � �� �� � �� � � � � �� ��� � � � � � � �� � � � � �� � � � � ���� � � �� � � � � �� � �� � � � � � �� ��
Examples of Software Processes
• W aterfal l p rocess
• I n crem en tal p rocess
– Microsoft
• …T h e r e a r e m a n y m o r e !
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Ad Hoc Process
• a n a l y s i s - - - > c o d e - - > t e s t - - > c o d e - - > t e s t …
• m a y w o r k f o r s m a l l p r o g r a m , o n e p r o g r a m m e r
• f o r l a r g e r s y s t e m s , d o o m e d t o f a i l u r e
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
���� �� � � �� �� � � �� �� � � � � � ��� � � � � �
� �� � �� � �� �� �� � � �� � �� � � �� � � �
� �� �� � � ! "# $
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
•Description of complete system.
•Boundaries between hardware and software components.
•Example: brakes in a car
•braking system includes •foot pedal•brake pads•software to control brakes.
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
Includes: functional requirementsE.g., depressing the brake slows the car down
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
Includes: non-functional requirements• E.g. performance: brakes must respond within 100 ms of being activated• E.g., availability: if software fails, brakes must still function manually.
��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
• Description of functions the software must fulfill and associated quality attributes.
• Expressed from point of view of a user of the system.
• Does not include implementation decisions such as algorithms, data structures used to address these requirements.
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
Example: for course marks program, functions are:
• Student can access system from any CASLab machine• Student can specify course in which he/she is enrolled and request grades for that course• Grades recorded for that course will be presented to user in a readable format• …etc.
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
• Describes software design meeting the requirements specified above. • Design is external, from point of view of a user of the software. • Shows how requirements are mapped to system features.
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
• May include:• detailed functional design• screen mockups• interaction design.
• Does not describe system implementation, e.g., algorithms, data structures, etc.
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
Describes implementation of software. Includes, e.g.,
• Deployment architecture• Component architecture• Component interfaces• Data model• Protocols (how components communicate with each other.)
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
Actual programming of software.
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
Ensuring software performs to specification. Addresses both function and quality attributes.
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
External Design
InternalDesign
Coding
Testing
Operations
Once software has been delivered, revisions will be required to address
• errors• new requirements
This is called software maintenance
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
SystemRequirements
SoftwareRequirements
Product Design
ProgramDesign
Coding
Testing
Operations
���� �� � � �� �� � � �� �� � � � � � ��� � � � � �
� �� � �� � �� �� �� � � �� � �� � � �� � � �
� �� �� � � ! "# $
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Bahrami's Simplification
What
How
Do It
Test
Use
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Premise of Waterfall Model
• E a c h s t e p c o m p l e t e d s u c c e s s f u l l y p r o v i d e s s t r o n g f o u n d a t i o n f o r n e x t s t e p
• F o r c e s d e v e l o p e r s t o c o p e w i t h d a t a a n d c o n t r o l f l o w s , e r r o r s , p r o b l e m s e a r l i e r i n d e v e l o p m e n t
• E a c h s t e p s h o u l d b e p e r f o r m e d b y t h o s e s k i l l e d i n t h o s e s t e p s
• D o c u m e n t e v e r y t h i n g : s o f t w a r e r e q u i r e m e n t s , p r e l i m i n a r y d e s i g n , i n t e r f a c e d e s i g n , f i n a l d e s i g n , t e s t p l a n / t e s t r e s u l t s , o p e r a t i n g i n s t r u c t i o n s
� �� � �� �� � � � � � � � � � � ���� � � � � � � �� �� � ��� � � � � � � � � � � � � � �
� � � �� � � � � �� � � � � � � � � � � � � � � � � � � � ��� � ! �" � � #
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Relative Cost to Fix or Change Software Throughout Lifecycle
0
20
40
60
80
100
120
140
160
Req Code AcceptTest
Large ProjectSmall Project
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Waterfall Model
• E m p h a s i s o n c a t c h i n g p r o b l e m s e a r l y t h r o u g h r e q u i r e m e n t s , d e s i g n s t a g e s
� � � � �� � � � � � � � � �� �� � � ��� � � � � � � � �� " � � � � �
� � � � � � � � � � � �� � � �
• C l e a r d o c u m e n t a t i o n c r e a t e d i n e a c h p h a s e
� � � � � � � � � �� � � �� � � � � � � � �� �� � �� �
� � � � � " � � �� � � � � � � � � �� � �• W o r k s b e s t f o r w e l l -u n d e r s t o o d s t y l e s o f s o f t w a r e
� � � � �� � " � � �� � � � � � � � � � ��� � �� � � � � � � � � � � � � � � � � �
� �� � � � " � � � � � � � � �" � �� � � � � � � �� � � � � � � � "
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Strengths and Weaknesses of Waterfall Model (1)
• P r i m a r y f u n c t i o n
– d e t e r m i n e o r d e r o f s t a g e s i n s o f t w a r e d e v e l o p m e n t
– s e t t r a n s i t i o n r e q u i r e m e n t s f r o m o n e s t a g e t o a n o t h e r
• W a t e r f a l l M o d e l
– d o c u m e n t ( o r t a s k ) d r i v e n
– b e t t e r t h a n a d -h o c p r o c e s s
– m o s t w i d e l y u s e d p r o c e s s m o d e l i n s t a n d a r d s a n d i n d u s t r y
���� � � � ���� �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Strengths and Weaknesses of Waterfall Model (2)
• w e a k n e s s e s
– e m p h a s i s o n f u l l y e l a b o r a t e d d o c u m e n t s b e f o r e g o i n g o n t o n e x t s t a g e
– o n l y w o r k s f o r w e l l d e f i n e d , m a t u r e , p r e d i c t a b l e t y p e s o f s o f t w a r e
– d o e s n ’ t w o r k f o r h i g h l y i n t e r a c t i v e s o f t w a r e , n e w t e c h n o l o g y , r e s e a r c h
– r e a l p r o j e c t s r a r e l y f o l l o w s e q u e n t i a l f l o w o f m o d e l
���� � � � ���� �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Strengths and Weaknesses of Waterfall Model (3)
• w e a k n e s s e s
– d i f f i c u l t f o r c u s t o m e r t o s t a t e a l l r e q u i r e m e n t s e x p l i c i t l y a t s t a r t o f p r o j e c t
– w o r k i n g v e r s i o n o f p r o g r a m n o t a v a i l a b l e u n t i l v e r y l a t e i n p r o j e c t l i f e -s p a n
– m a j o r b l u n d e r m a y n o t b e d i s c o v e r e d u n t i l v e r y l a t e
– s e q u e n t i a l s t y l e l e a d s t o b o t t l e n e c k s a n d d o e s n ’ t l e n d i t s e l f t o p a r a l l e l a c t i v i t i e s
���� � � � ���� �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Software Prototyping
t r a d i t i o n a l u n d e r s t a n d i n g o f “ p r o t o t y p e ” :
m o c k -u p o f a n e w l y e n g i n e e r e d p r o d u c t
– p r o t o t y p e a i r c r a f t t o t e s t f l y i n g , c h e c k s y s t e m s
– m a k e r e f i n e m e n t s b e f o r e g o i n g i n t o p r o d u c t i o n
– h a v e t o b u i l d n e a r l y w h o l e t h i n g ( a i r f r a m e , e n g i n e s , c o c k p i t c o n t r o l s , h y d r a u l i c s , l a n d i n g g e a r , e l e c t r o n i c s , e t c . ) b e f o r e t e s t
���� � � � ���� �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Software Prototyping
• f o r s o f t w a r e , p r o t o t y p e u s e d t o
– t r y o u t o n c u s t o m e r s
� �� � �� � � � � � � � � � � � � � ��� �� � � � � � � �� � � � � � � � � �
� � �� � � � � ��� �� � � � � � � � � � � � � � �� ��� � � � � � �
� � � �� � � � � �� �� � � � �� � � � � � � �– t r y o u t p o s s i b l e t r o u b l e a r e a s
� � � � � � � �� � �! � � � � � � � � � �� �� � �
� � � � � �" � # � �! � � � �� � � � �$
� � " � � � � $ � � � $ � � � � � � � � � � � � � �
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Key considerations for using Prototypes
• o b j e c t i v e s f o r e a c h p r o t o t y p e a c t i v i t y s h o u l d b e c l e a r l y e s t a b l i s h e d
• d e f i n e t h e p r o t o t y p e p r o c e s s a h e a d ( p r o t o t y p i n g d o e s N O T m e a n h a c k i n g )
• r e s u l t s f r o m p r o t o t y p i n g e f f o r t m u s t b e d o c u m e n t e d a n d a n a l y z e d b e f o r e d e c i s i o n o n h o w t o p r o c e e d
• c o m p l e t e o n e p r o t o t y p e a n d a n a l y z e r e s u l t s b e f o r e s t a r t i n g n e x t i t e r a t i o n
• p r o t o t y p e r e s u l t s c a n b e
� � � � � �! � ��
� � �� �� � � � � � � � �� � � � � �
� � � �� � �� $ � � � � � � � �� � �
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Competing Philosophies on Prototyping (1)
• t h r o w a w a y p r o t o t y p e
� � � � � � � � � � � � � � � � � � � � � � � � � � � � �
� � � � � � � � � � � � � � � � � � � � � � � � � � �� # � � � � � � � � �� � � � �
• q u i c k & d i r t y p r o t o t y p e
� � � � � � � � ��� � � # � � $ � � � � � � �� � � � � � � � � � � � � � � � � �
$ �� � � � � � � �" � �
� � � � � � � � $ � � � � �� � � � � � �� � � � � � � �� � �� �
� � �� � � �� � �� � � � � �� �� � � � � � �� � ��� �
� � �� ���� �� �� � � �� � � ! " ! �# $ ��% �!'&
� ( � � $ � � ) "& � � ( � � � *+ � � � % �� + � % + �� � ,
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Competing Philosophies on Prototyping (2)
• d e t a i l e d d e s i g n -d r i v e n p r o t o t y p e
� *� � ( �� � �� � �� ��� �� � �"! � � ) $% + � �� ( � ) � !
� ( � ) � ! % � ( ! � + � � ) � �� * �% + � � � � � " ! �
� � �# �%$ &"' (*) +, -". / 0 +' 1 23 / 4 & / , 23 ) +' 56 7 3 ' 2 86 , 9 + 0
• n o n -f u n c t i o n i n g m o c k -u p s
: ;< = >@? ACB DFE <G HJI K LI KE M@N ? OQP R
: P N P < SSCT RG KU D H ? N U DN P < S ? V< W R S ? N K L D = RP ON < = H KP O RP ON LG K W
N T N O? W RG K ;? N N ? N
: P N ? H O K L K S S KB L S KB K L O< N XN
: N K W ? O D W ? N K = R < R? G K = SCT KG K = ; K W RP O? G N ;G ? ? =N K = SCT
: ? V< W R S ? N W < =P < S ST RG ? R <G ? H >T H ? U ? S K R? G N
Y , 3 &6 Z6 6 2 Z /6 4 4 . ( , [ / Z Z3 23 5 [ / Z +'
Y , 3 Z ' + 0 / 4 Z 0 3 ' ( +, Z + &
���� � � ����� � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Weaknesses of Prototyping
• w h a t d o w e d o w i t h p r o t o t y p e w h e n i t h a s s e r v e d i t s p u r p o s e ?
• customers see what appears to be a working system
� ! " ##%$ &(' #) *,+ -' * &(' . / 0 * &1 2 &(' / 043 - - 5 " 3 ) 6 " # 0 3 - / 0 .' 7
� 2 ! *,+ 5' . ! ' 8 9' 2 * ! 9 . + *,+ *$ 9' *,+ 6' ) ' # 0;: ' .' ) !$ ! *' 5
� 5 " 3 " -' 5' 3 * 5 "$ 2 + # # " 9 !' *,+ 2 ! * + 5' . ! ) ' 5 " 3 ) !
• d ev el oper has mad e impl ementation compromises
� 043 " 9 9 .+ 9 . 0 " *' < => + . 9 .+ - . " 5 5 043 - # " 3 - " -'
� 5 "$ 6' 2 + 5' " 3 043 *' - . " # 9 " . * + ? * &(' !$ ! *' 5
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
The Incremental Model
• combination of waterf al l mod el and prototyping
• each seq uence of the process
� 9 .+ ) 2' ! " ) ' # 0;: ' . " 6#(' 1 043 2 .' 5' 3 * 7 + ? * &(' ! + ? * / " .'
� 2 " 3 043 2 + . 9 + . " *' * &(' 9 .+ *,+ *$ 9 043 - 9 " . ") 0 - 5• f irst increment is of ten the core prod uct
� 6 " ! 0 2 .' 0 .' 5' 3 * ! 5' *
� ! 9 9 #(' 5' 3 * " .$ ?' " * .' ! 3 ) ' # 0;: ' .' )• ev al uation with user
• pl an f or nex t increment
• repeat until f ul l prod uct d el iv ered
• f ocus on d el iv ery of operational prod uct with each increment
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Evolutionary Rapid Prototyping
• “ an easil y buil t, read il y mod if iabl e, ul timatel y ex tensibl e, partial l y specif ied , working mod el of primary aspects of a proposed system”
• primary obj ectiv e: “ prov id e a cost-ef f ectiv e means of d iscov ering the true and compl ete set of system f unctional req uirements that wil l optimal l y satisf y the l egitimate business need s of the user”
• not throw-away: ev ol v es into f inal system
• not q uick-and -d irty: d etail ed anal ysis and d esign take pl ace
• not mock-up: uses real user d ata
� ��� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Steps in Evolutionary Rapid Prototyping (1)
• * * * P rototype most important aspects of the system f irst* * *
• * * * H av e a prototyping process/ proced ure d ef ined ahead * * *
• d iv id e appl ication into wel l d ef ined pieces
� 9 0' 2' ! * & " * 2 " 3 6' ) ' : ' # + 9' ) 043 ) ' 9' 3 ) ' 3 * #$
• d ecid e ord er of prototyping d if f erent pieces
� + .) ' . 043 - 5 "$ 2 & " 3 -' " ! ) ' : ' # + 9 5' 3 * 9 .+ 2' ' ) !
• pl an prototyping activ ities
�
) ' 2 0) ' + 6� ' 2 * 0 : ' !
�
) + 3 � * -' * 043 *,+ ' 3 )#(' ! ! # + + 9 + ? 9 .+ * + *$ 9 043 -
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Steps in Evolutionary Rapid Prototyping (2)
• get prototype working
• ev al uate your resul ts
� ! & + / 0 * * + ! + 5' + 3 ' �
�
�' ' 9 + 6� ' 2 * 0 : ' ! 043 5 0 3 ) * &(' / & + #(' * 0 5'
• make ref inements
• upd ate req uirements d ocumentation
• f reez e portion of prototype that’ s d one
• mov e on to nex t piece to prototype
• buil d f inal prod uct f rom prototype pieces
�
? 043 " # 9 . + ) 2 * 5 "$ 3 ' ' ) ! + 5' ? 043 ' * 3 043 - *,+ ! " * 0 ! ?$ 9 . + ) 2 *
.' 0 .' 5' 3 * !
�
? 043 " # 9 . + ) 2 * 5 ! * 6' : " # 0) " *' ) " - " 043 ! * 9 .+ � ' 2 * .' 0 .' 5' 3 * !
6' ?+ .' * .3 043 - + : ' . *,+ !' .
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Evolutionary Rapid Prototyping
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Weakness of Evolutionary Rapid Prototyping
• can easil y turn into “ q uick and d irty”
• non-f unctional issues such as perf ormance l ef t until l ast
� 3 + + : ' . " # # ) ' ! 0 - 3 ) + 3 ' *,+ " ) ) .' ! ! * &(' !'• some appl ications d o not l end themsel v es to rapid
prototyping
� + 9' . " * 043 - !$ ! *' 5 !��
*' #(' 2 + 5 5 ! + ? * / " .'�
.' " # * 0 5' !$ ! *' 5 !��
) 6 5 !$ ! *' 5 !��
! 2 0' 3 * 0 ? 0 2 .' !' " . 2 & ! + ? * / " .'
� . " 9 0) 9 .+ *,+ *$ 9 043 - ?+ 2 ! 0 ! + 3 !' . ! " * 0 ! ? " 2 * 0 + 3
CISC 323Introduction to Software Engineering
Week 3
OOP, UML, Software Process
Lectu re 2 : T h e Mi crosoft Process
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
References
• Mi croSoft Secrets; C u su m an o, Sel b y , Si m on & Sch u ster I n c. , 1 9 9 5
• H ow Mi crosoft B u i l d s Software; C u su m an oan d Sel b y , C om m u n i cati on s of th e A C M, J u n e 1 9 9 7
(not required reading)
���� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Philosophy
• M i c r o s o f t s t a r t e d a s s m a l l g r o u p o f " h a c k e r s "• O l d m e a n i n g o f " h a c k e r " : " l o n g -h a i r e d , u n k e m p t
t e c h n i c a l w i z a r d s " h a c k i n g a w a y a t c o d i n g . C r e a t i v e , v e r y g o o d a t g e t t i n g c o d e u p a n d r u n n i n g q u i c k l y .
• A s M i c r o s o f t g r e w , n e e d e d m o r e s t r u c t u r e w i t h o u t s t i f l i n g c r e a t i v i t y a n d t a l e n t
• W a t e r f a l l m o d e l a l s o t o o r i g i d w h e n u s e r r e q u i r e m e n t s c o n s t a n t l y e v o l v i n g
• " S y n c h -a n d -s a v e " m e t h o d o l o g y : a l l o w s d e v e l o p e r s t o w o r k i n s m a l l g r o u p s , f a i r l y i n d e p e n d e n t
• D a i l y b u i l d s a n d c o n s t a n t t e s t i n g k e e p g r o u p s f r o m d i v e r g i n g
� ��� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Interesting Numbers
• W i n d o w s 9 5 c o n t a i n s > 1 1 m i l l i o n l i n e s o f c o d e
• m o r e t h a n 2 0 0 p r o g r a m m e r s & t e s t e r s
���� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
The Microsoft Triangle
• D e c i s i o n m a k i n g f o c u s e s o n t h r e e o f t h e d i m e n s i o n s o f q u a l i t y i n t h e e n d p r o d u c t :
– F u n c t i o n s s u p p o r t e d
– T i m e t o M a r k e t
– I m p l e m e n t a t i o n d e f e c t s r e m a i n i n g
• r a p i d d e v e l o p m e n t , d a i l y b u i l d s , t e s t i n g b u d d i e s
• e v o l v i n g r e q u i r e m e n t s , w o r k f r o m v i s i o n s t a t e m e n t
• h e a v y r e l i a n c e o n t e s t i n g , m u l t i p l e t e s t i n g s t r a t e g i e s
• w e l l e s t a b l i s h e d p l a n s a n d s c h e d u l e s
� ��� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Common Principles
� ��� �� �� �� � � � � ��� �� �
� ��� �� � � � � �� �� � � � � � � ! " � � � � # $ � � � � ��
% & � �' � ( )� � �� * � � � )� + +� �
� ,� # -� � � � �. � � �/ ". �. �/ . � � � � � � � � � # !/ � �� # �
� 01 � � � � # ��� �. �. # � 032 # � � � � $ � � �/ . � � � � � � � � � #
� 4 ! � " � � # 5 ! � �. � � � �. �� � !# �� �. �. . # �. "� 6 �
% 7�98 � � ) � � � 8 �� � � +� � + � �
� 4. �� �� �� �� �. / �� $ �� � �. � � �� 6 � � � �. �. # � � � �. # � 6 � � �. � � � �.
� � �. � # �� �. � � �. � � � �. ". � �� / �� � !� � ��: . �. � 5. � � � �. � �
% ; � �� � � � � )< ' � ( � � � �� � � +� ( �� � � �� �
% = � 8 > � � � � � � �� � �
% ? � (' � � � (' � ��� � 8 +8 � �� � �
@ AB C B A CDE F AB G BH I DJ BK LK B E DJ J DJ
% M * �� 8 � ) � + � < � ( ) � N ' � � �
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Approach
• “ F i x ” p r o j e c t r e s o u r c e s
!#" $ %'& ( ) *'+ & )+ , &
- $ )" . / ) * / 0 $ &
• S e t i n t e n d e d s h i p d a t e
• D e f i n e m i l e s t o n e s b a c k w a r d s f r o m t a r g e t s h i p d a t e
• N o s e p a r a t e m a i n t e n a n c e g r o u p
10#2 & 3 0 .4 ," 5 & 5 0 . . & 2 / + ( ) 56" 4 / (& , & 7 3&
• T h r e e p h a s e s
8 /& ( 7 / 0#9 & 7+ + ( ) 74 :
; , 7 . . 0 .< + : 7 3&>= 5 & 9 & , )+ $ & . / + : 7 3&>= 3 / 7 % 0 , 0#? 7 / 0 ) . + : 7 3&
8 .4 ,6" 5 & %" * *& ( / 0 $ & 7 / & 74 : + : 7 3&
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Microsoft Process
Planning(3-12 months)
Stabilization(3-8 months)
Development(6-12 months)
Stabilization(3-8 months)
Milestone 0
Subproject 1 Subproject 2 Subproject 3
Feature Complete
Visual Freeze
Release
Code Complete
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Microsoft Process
Release
Planning(3-12 months)
Stabilization(3-8 months)
Development(6-12 months)
Stabilization(3-8 months)
Milestone 0
Subproject 1 Subproject 2 Subproject 3
Code, test, optimize, stabilize
(6-10 weeks)
Integration test, debug(2-5 weeks)
Buffer time(2-5
weeks)
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Planning Phase (3-12 months)
• M a r k e t i n g , v i s i o n s t a t e m e n t , d e s i g n g o a l s
• I n i t i a l s p e c i f i c a t i o n
� ) . ,�� + (& , 0 $ 0 . 7 (� )" / , 0 . &
� �� / ) � � � 4 : 7 .< & 3 * ( ) $ 3 / 7 ( / / ) & . 5 ) * + ( ) � & 4 /
� + ( ) � & 4 / $ 7 . 7< & ( 3 & & + 0 / " + / ) 5 7 /&
� 7 . 3� & ( 3� " & 3 / 0 ) . 3 3" 4 : 7 3
� ��� � ��� � ��� �� ��� � � � � � ��� �� � ���� � �
� ��� � � � � � � �� � � � � � � � �� � � � � � ��� �� � ���� � �� � �
• P r o j e c t m a n a g e r s d o e x t e n s i v e p r o t o t y p i n g
! " #$ %&#(') * +, * ' #(-
! .�/ 01 ) '2 / ' 3 #2 " 4 0 #(5 $
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Development Phase (6-12 months)
! 0 / " 1 * # 0 / 1 # +2 ' $ 05 2
/2 +2 * '2 '
$ �� � �� � � � �� � � � % % &�
� � � � �� �
')( *( +-, .( / 0 1 / 23 ( 4, 5 (
6 7( 03 ( / 0 1 / 23 ( 3 ( 03 08 23 ( 0
6 9 0( / ( 5 8 4: 3 2, ; 03 : < < 1 / 2 3 (
5 /: <3 5, 48 = ( ; 3 : 3 2, ;
6 ')( *( +-, .( / 0 < 2?> ( / /, / 0
4, ; 3 2 ; 8 , 8 0 +A@ : 0 3 ( 03 ( / 0 < 2 ; 5
3 B ( =
6 C DE , < 3 , 3 : + 5 ( *( +-, . = ( ; 3
. B : 0( 2 0 FG 8 < <( / H 3 2 = (
6 FI 2 08 : + < /( ( J( H
K LM NPOQ R STQ UPV WTQ XM YT S XQ O Z T V
K XOQ [?T V T X U W O X R STQ T \ R YM W UPO V
]Q O R ^
6 F_ ( : 3 8 /( 4, = . + ( 3 ( H
K X R ``ba X RV Y W UPO V M `
K WT S W S YT V MQ UPO S YM V Q RV
K S W U ` `c M S [ R ] S M V \
^TQ XOQ L M V YT U S S R T S
6 Fd , 5 ( 4, = . + ( 3 ( H
K M ` ` XT M W RQ T S eOQ f M S
\ T S YQ U [?T \ UPV S ^T Y S M V \ R STQ
\?O Y S
K ^O UPV W ec TQ T [ R ] YO RV W
Sc O R ` \ [ T S WT M \ U `ba \ T Y ` UPV UPV ]
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Stabilization Phase (3-8 months)
• 1/3 of total time in project
• E x tens iv e tes ting & d eb u g g ing
• N o new featu res
• “ Z ero b u g releas e”
– n o m o r e h i g h -s e v e r i t y b u g s h a v e b e e n f o u n d
– d e c i s i o n t o p o s t p o n e f i x i n g a l l r e m a i n i n g b u g s u n t i l n e x t r e l e a s e
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Daily Build Process (1)
• C h e c k O u t
!" #%$ & ')( *+ ! # ( , + - , + . " * ( *+ / (
0 -" + 1 * ( 2 '" & 3 #%4 ( / 1 & , ')( " $ ( " , # + 2
0 1 . 3 ' # ! 3 ( / ( $ ( 3 + ! ( " , * & 2 * 5 ( * 6 + . ' , & 1 ( *+ / ( & ' , & 1 ( ' # 1 (
• I m p l e m e n t F e a t u r e
0 / ( $ ( 3 + ! ( " # 1 ! 3 ( 1 ( 2 ' , 5 # , 7 5 ( " + 8 2 * 5 & 29 ( ,
0 *+ . 3 / ' & 6( & -( 8 5 + . " , '+ , ( $ ( " & 3 / &: ,
• B u i l d P r i v a t e R e l e a s e
0 / ( $ ( 3 + ! ( " ; . # 3 / , + 8 2 !" # $ & ' ( *+ !: + - ' 5 ( !" + / . * ' 8 # ' 5 2 ( 8 3<:
# 1 ! 3 ( 1 ( 2 ')( / -( & ' . " ( ,• T e s t P r i v a t e R e l e a s e
0 / ( $ ( 3 + ! ( " ')( , ' , + 8 2 *+ !: + - !" + / . * '
� ��� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Daily Build Process (2)
• S y n c h C o d e C h a n g e s
0 *+ 1 ! & " ( !" #%$ & ')( *+ ! # ( , + - , + . " * ( - # 3 ( , ; & * 6 '+ 1 & , ')( "
$ ( " , # + 2
0 + ' 5 ( " / ( $ ( 3 + ! ( " , 1 &: 5 & $ ( 1 & / ( * 5 & 29 ( , # 2 ' 5 ( 1 ( & 2 ' # 1 (
• M e r g e C o d e C h a n g e s
0 . ! / & ')( !" #%$ & ')( *+ ! # ( , + - ,+ . " * ( - # 3 ( , '+ # 2 * 3 . / ( & 2: * 5 & 29 ( ,
-" + 1 + ' 5 ( " / ( $ ( 3 + ! ( " ,
• B u i l d P r i v a t e R e l e a s e
0 / ( $ ( 3 + ! ( " ; . # 3 / , + 8 2 *+ !: + - !" + / . * ' 8 # ' 5 ;+ ' 5 + 8 2
* 5 & 29 ( , & 2 / * 5 & 29 ( , + - + ' 5 ( " / ( $ ( 3 + ! ( " ,
• T e s t P r i v a t e R e l e a s e
0 ')( , ' '+ 1 & 6( , . " ( 2 ( 8 3 : # 1 ! 3 ( 1 ( 2 ')( / *+ / ( , ' # 3 3 8+ " 6 , 8 # ' 5
+ ' 5 ( " , � * 5 & 29 ( ,
���� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Daily Build Process (3)
• E x e c u t e Q u i c k T e s t
0 / + 2 ( + 2 !" # $ & ')( " ( 3 ( & , (
0 5 #9 5 3 : & . '+ 1 & ')( /
0 1 & 6( , , . " ( 2 ( 8 * 5 & 29 ( ,
/ + 2 + ' # 2 ')( " -( " ( 8 # ' 5
; & , # * - . 2 * ' # + 2 & 3 # ': + -
!" + / . * '
0 / + ( , 2 + '')( , ' 2 ( 8 -( & ' . " (
/ # " ( * ' 3 :
0 ( � 9 �� � . # * 6 ')( , ' + 2 � � � ��
' & 6( , � 1 # 2 . ')( ,
0 & 3 ,+ * & 3 3 ( / , 1 + 6( ')( , ' + "
" ( 9 " ( , , # + 2 ')( , '
• C h e c k i n
0 / ( $ ( 3 + ! ( " + - - # * # & 3 3 :
* 5 ( * 6 , 5 # , !" # $ & ')( *+ ! # ( ,
# 2 '+ ' 5 ( 1 & , ')( " $ ( " , # + 2
0 5 & , '+ ,: 2 * 5 & 2 / 1 ( " 9 (
&9 & # 2 # 2 * & , ( + - - . " ' 5 ( "
* 5 & 29 ( ,
0 # - *+ 2 - 3 # * ' ,� 1 &: 5 & $ ( '+
8 # ' 5 / " & 8 * 5 & 29 ( ,
0 / ( & / 3 # 2 ( -+ " * 5 ( * 6 # 2
� � � �� � ����
�� �
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Daily Build Process (4)
• G e n e r a t e D a i l y B u i l d
– a f t e r c h e c k i n d e a d l i n e
– b u i l d m a s t e r g e n e r a t e s c o m p l e t e b u i l d o f p r o d u c t f r o m m a s t e r v e r s i o n
� ! ""$# % & % ! ' ")( *)+ ' " %,
� ! -. # / 0+ # 0 0 -+ "*)+ ' " %
1 23 24 5 6 27 7 28 9 2 7 : ; < 5 6 : = < 6 2 > 6 27 67
1 < 7 7 5 8 27 ? < 7 9 4 ; 5 @ 4 6 9 : @ < A 9 6CB D :8 E7 4 :8 8 24 6 A B
1 = < E 27 > < 9 A B ? 5 9 A > <F < 9 A < ? A 2 6 : < A A G8 : H 24 6 7 6 < ; ;
� ��� � � ����� � � � � �� � � ��� � � �� � � � � �� � � �� � � � � ���� � � � � � � � �� � �� � � � � � � �� �
Role of Program Managers
• T y p i c a l s t r u c t u r e :
– m a n a g e r s m a k e a l l d e s i g n d e c i s i o n s : s t r u c t u r e o f c o d e a n d h o w t o d i v i d e t a s k s
– d e v e l o p e r s f o l l o w i n s t r u c t i o n s & t u r n d e s i g n i n t o c o d e
• M i c r o s o f t :
– d e v e l o p e r s i n v o l v e d i n d e s i g n
– m a n a g e r o r g a n i z e s , k e e p s r e c o r d s , m a k e s s u r e d e c i s i o n s g e t m a d e
– s u c c e s s d e p e n d s o n p e r s o n a l i t i e s
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Testing (1)
• q u i c k t e s t s o n d a i l y b u i l d
• d e v e l o p e r s c r e a t e d e b u g v e r s i o n s
! " ! # $$&% ')( * +-, . +-/ ', 0/ # $1 # ' # " ' 0 ! 2 ' ! 0, "
3 +-4 5 0( *, 4 , 4 ( 0% ! " #6 , #/ 1 , 7, 2 ! ' + ( / " 5, , 1• u s e a s s e r t i o n s “ i f t h e n ” t e s t s
3 . 8 , / 4 # 9 +/ 6 # " " ! 4 5 ' + ( / " # : ( ! '1 # ' # " ')( 0, 1 , $ ", . 8 , 0, +/
5 0( 6 0 # 4
• i n s t r u m e n t a t i o n f o r u s e r t e s t i n g
3 2 # 5 ' ! 0, " 2 ( 4 4 #/ 1 " ! ", 0 " ", $ , 2 '
3 2 # 5 ' ! 0, " 2 ( 0 0, " 5 ( / 1 +-/ 6 " ( ! 0 2, 2 ( 1 , " ' # ', 4 , / ' " ' 8 # ' 6 , '
, 7, 2 ! ', 1
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Testing (2)
• u s a b i l i t y t e s t i n g
– l a b w i t h “ p e o p l e o f f t h e s t r e e t ”
– u s e r i n t e r f a c e s t e s t e d
• w e e k l y t e s t r e l e a s e s
– t o t e s t i n g g r o u p f o r t h o r o u g h t e s t i n g
– u s e h i g h l y s t r u c t u r e d s c r i p t s
– “ g u e r r i l l a ” t e s t i n g
� ' 0% ')( : 0, # 9 ' 8 , 5 0( 1 ! 2 '
� ��� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Testing (3)
• t e s t i n g b u d d i e s– w o r k s i d e b y s i d e w i t h d e v e l o p e r s
– d e v e l o p e r s h a r e s p r i v a t e r e l e a s e w i t h h i s t e s t i n g b u d d y
– d o p r i v a t e r e l e a s e t e s t i n g b e f o r e c o d e g o e s t o d a i l y b u i l d
• o t h e r k i n d s– p e r f o r m a n c e t e s t i n g
– i n t e r n a l u s a g e
– b e t a t e s t i n g
���� � �� �� � �� � � � � � �� � � � � �� � � � � �� � � � � ���� � � � �� �� � �� � �� � � � � �� ��
Observations From Book (1)
• l i t t l e a r c h i t e c t u r a l d o c u m e n t a t i o n
– s o u r c e c o d e i s o n e m a i n d o c u m e n t
– t r y t o k e e p c o d e a s s i m p l e a s p o s s i b l e
– compartmentalize code
• v e r y l i t t l e c o d e c o m m e n t s
– u s es “ H u ng arian” ru les f or v ariab le naming
� ��� � �� �� �� � ��� �� �� � � ��� �� ��� � ��� � � �� �� � � �� � � �
– h alf lif e of s ou rce code is as little as 1 8 month s
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Observations From Book (2)
• C u s u m a n o & S e l b y r e c o m m e n d :
– m o r e u s e o f m e t r i c s
• d o u s e b u g c o u n t s
– d e s i g n a n d c o d e r e v i e w s
• i n t e n s i v e c o d e i n s p e c t i o n s
• d e t e c t a n d f i x p r o b l e m s b e f o r e i n c o r p o r a t e d i n t o p r o d u c t
• r e f i n e p r o d u c t a r c h i t e c t u r e
• e d u c a t e j u n i o r d e v e l o p e r s
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Observations From Book (3)
• " S y n c h a n d s a v e " m a k e s i t s i m p l e r t o r e a c t t o c u s t o m e r f e e d b a c k t h r o u g h d e v e l o p m e n t
• W o r k s w e l l f o r s o m e k i n d s o f a p p l i c a t i o n s ( W o r d , E x c e l )
• O p e r a t i n g s y s t e m s ( W i n d o w s ) & a p p l i c a t i o n s s u c h a s i n t e r a c t i v e v i d e o a r e m o r e " t i g h t l y c o u p l e d "
� ��� � ��� � � � �� � � � � � ��� �� � ��� � � � ��� � ���
• T h e s e p r o g r a m s w o u l d b e n e f i t f r o m m o r e u p -f r o n t p l a n n i n g
CISC 323Introduction to Software Engineering
Week 3
OOP, UML, Software Process
Lectu re 3 : Last D etai l s, R ev i ew
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��recall abstract classes can contain
• attributes• concrete methods • abstract methods
mixture of abstract and concrete
Topic 1: Interfaces
an interface is like an abstract class but contains only abstract methods – no attributes, no concrete methods
completely abstract
an interface is a skeleton or template for a classspecifies functionality the class must providenothing about implementation
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��public interface Comparable {public int compareTo(Object o);
}
Example From the API
Note: all methods in an interface are abstract.Don't need keyword abstract in declaration
Terminology:you extend an abstract classyou implement an interface
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
String & Comparable
Man y A PI cl asses i m p l em en t ComparableE x am p l e: String implements Comparable
-- it has acompareTo method
public class String implements Comparable { ....// body of class includes a concrete// compareTo method
}
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��Suppose we want to be able to compare 2 employees
on the basis of the amount of pay owed to them
Add acompareTo method to Employee and addimplements Comparable
to the class header
Employee & Comparable
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Employee & Comparable
public class Employee implements Comparable {public int compareTo(Object obj) {
if (obj instanceof Employee) {Employee other = (Employee) obj;if (payOwed == other.payOwed)
return 0;else if (payOwed < other.payOwed)
return -1;else
return 1;}else {
return 1; // arbitrary value} // end if
} // end compareTo.. rest of Employee class
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��recall: a class can extend only one other class
Multiple Inheritance Revisited
but a class can implement many interfaces
distinction between abstract classes & interfacesis Java's answer to multiple inheritance
gives most of functionality of multiple inheritancewithout the implementation headaches
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Multiple Inheritance Revisited
String implements 2 interfaces:ComparableSerializable (related to I/O)
Syntax:public class String implements Comparable, Serializable {
A class can extend another class and implement interfaces:public class Executive extends Employee implements Comparable {
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
UML For Interfaces
One way to show interface in Java:
class box as before, with <<Interface>> stereoty p e
n ote: n o attribu tes com p artm en t
<<interface>>Comparable
compareTo(Object o): int
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Showing "implements"
U se a d ashed g en eraliz ation arrow from a class
to an in terface it im p lem en ts
<<interface>>Comparable
compareTo(Object o): int
Employee
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Another Way to Show Interfaces
Interface is represented by a small circle
w ith name o f interface
S o lid line betw een interface and implementing class
EmployeeComparable
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Generic Code
Interfaces are v ery u sefu l fo r w riting
g eneric ( g eneral-pu rpo se) co de
E x ample: so rting
M eth o d to so rt array o f E mplo yees u sefu l
o nly fo r o ne pu rpo se
A no th er k ind o f o bj ect: mu st w rite a new
so rting meth o d
M u ch better: g eneral meth o d fo r so rting O bj ects
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Generic Sorting
void sort(Object arr[])
p roblem : n eed to k n ow how to com p are p airs of obj ects
n o g en eral an swer
solu tion : we will on ly sort array s of obj ects that hav e a
com p areT o m ethod
– i. e. obj ects that im p lem en t Comparable
n ow sig n atu re is void sort(Comparable arr[])
in sid e m ethod , we can say
if (arr[i].compareTo(arr[j]) < 0) ....
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��API class Arrays provides useful static methods for arrays
(search, sort, fill with value, etc.)
API Sorting Method
one of the methods:static void sort(Comparable[] a)
This class is in the API package java.util.
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Using Arrays.sort
Employee company[] = new Employee[SIZE];
// code to fill company array
Arrays.sort(company);
T his is leg al becau se the Employee class im p lem en ts Comparable
S orts the array accord in g to compareTo m ethod in Employee
S o p erson owed the least m on ey com es first,p erson owed the m ost m on ey com es last
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��Recall Java's rules about constructors.
Rule 1: If your class has no constructors at all, Java creates default: no parameters, does nothing. All fields left at 0 or null.
Topic 2: Details About Constructors
Rule 2: You can define your own constructor, or lots of overloadedconstructors with different numbers & types of parameters.
Rule 3: If you define any constructors, you don't get the default. Ifyou want a no-parameter constructor in addition to others, youmust write it yourself.
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
public class C {int x;... // no constructors in this class
}...
C obj = new C(); // legal, obj.x = 0
Example
public class C {int x;public C (int val) { x = val; }....
}...
C obj1 = new C(13); // legal, obj1.x = 13C obj2 = new C(); // illegal!
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
You've seen that you may call the constructor of parent class using keyword super.
Calling "super" constructor
public Salesperson(String empName, String empTitle, double empWage, double empRate) {
super(empName, empTitle, empWage); // Employee constructorrate = empRate;
} // end constructor
In fact, Java requires a call to a parent constructor.If you don't make one as first line of child class' constructor,
Java adds call to super().
� ��� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��What if parent class doesn't have a no-parameter constructor?
Potential Problem
public Salesperson(String empName, String empTitle, double empWage, double empRate) {
name = empName;title = empTitle;wage = empWage;rate = empRate;
} // end constructor
compiler inserts call to super().
super();
But parent class (Employee) has only 1 constructor and it takes3 parameters! Result: weird error message.
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��You must either:
• give the parent class a no-parameter constructor OR• make sure all child class constructors call super()
as first statement
Moral
���� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Review For Midterm
Topics:– O O P ( som e r e v ie w , som e n e w )– U M L– S of t w a r e P r oce ss
L og ist ics:– M on d a y in se ct ion w h ere y o u are reg istered– w il l b e 2 d if f e r e n t v e r sion s– m a y b r in g a " ch e a t sh e e t " ( 8 . 5 x 1 1 " , b ot h sid e s)– w e w il l b e st r ict a b ou t n oise & m ov e m e n t– pol icy : w e w il l n ot r e v ie w pa pe r s w it h
• e r a se r sm u d g e s• w h it e -ou t
���� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
UML "Cheat Sheet" (1)
Employee
name: Stringwage: double
pay(hours: double)amountToPay(): double
class diagram
Mary: Executive
name = "Mary"wage = 35
object diagram
Employee Officeoccupant workplace
worksIn
association with name, roles, quantifiers
1..* 1
� ��� � �� �� � � � � � �� � � ��� � � �� � � � � � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
UML "Cheat Sheet" (2)
A r r ow s:
�� � ��� � � � � ��
� � �� �� �� � �� � ��� ��� � � ��� ��� � ���� ��� � � ��
� � � � � � � � �� � ���� � � �� � � � � � � �� � � � � � � � �� �
� � � � � � � ��� � � �� � � � � � � � �� � � � �
� � ��� � � � �� � � � � � �� �
��� � � ��� �
���� � � � ���� � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� � �
UML "Cheat Sheet" (3)
Abstract Classes & Methods: use italics or write "abstract"
I n terf ace: use < < in terf ace> > stereoty p e or
rep resen t by sm all circle ( n o m ethods shown )
CD
Song
*
1..*
track number qualifier
Resource
Skill
*
*Experience
association class
���� � � � ���� � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� � �
Use Case Diagram
circles are "use cases"stick figures are "actors"non-human actor:
box with <<actor>>
���� � �� �� � � � � � �� � � ��� � � �� � � �� � � � � �� � � � � ���� � � � � � � � �� � �� � � � � � �� ��
Sequence Diagram
! "# $! &% '(
)% * + ! ,.- ! % / / '0 1% ' 2 ! &% '
1% ' 2 ! &% ' $ 34(
1% ' 2 ! &% ' ' )4# $ 1 5 "! -
Customer Cashier CookPlace order
Give money
Send foodAnnounce price
Give food
Request food
Ask for more money
[until enough money]