Chapter 1 Lecture 1

UsingUML,Patterns,andJava
ObjectOrientedSoftwareEngineering
Chapter1:Introduction
RequirementsforthisClass
Youareproficientinaprogramminglanguage,butyouhaveno
experienceinanalysisordesignofasystem
Youwanttolearnmoreaboutthetechnicalaspectsofanalysisand
designofcomplexsoftwaresystems
BerndBruegge&AllenH.Dutoit
ObjectOrientedSoftwareEngineering:UsingUML,Patterns,andJava
ObjectivesoftheClass
AppreciateSoftwareEngineering:
Buildcomplexsoftwaresystemsinthecontextoffrequentchange
Understandhowto
produceahighqualitysoftwaresystemwithintime
whiledealingwithcomplexityandchange
Acquiretechnicalknowledge(mainemphasis)
Acquiremanagerialknowledge
AcquireTechnicalKnowledge
UnderstandSystemModeling
LearnUML(UnifiedModelingLanguage)
Learndifferentmodelingmethods:
UseCasemodeling
ObjectModeling
DynamicModeling
IssueModeling
LearnhowtouseTools:
CASE(ComputerAidedSoftwareEngineering)
Tool:TogetherJ
ComponentBasedSoftwareEngineering
LearnhowtouseDesignPatternsandFrameworks
AcquireManagerialKnowledge
UnderstandtheSoftwareLifecycle
ProcessvsProduct
Learnaboutdifferentsoftwarelifecycles
GreenfieldEngineering,InterfaceEngineering,Reengineering
Readings
Required:
BerndBruegge,AllenDutoit:ObjectOrientedSoftwareEngineering:
UsingUML,Patterns,andJava,PrenticeHall,2003.
Recommended:
I.Sommerville.SoftwareEngineering.PrenticeHall
UMLeUnifiedProcess.AnalisieProgettazioneObjectOriented.J.Arlow
eI.Neustadt.McGrawHill
J.Rumbaugh,I.Jacobson,G.Booch.TheUnifiedModelingLanguge
ReferenceManual.AddisonWesley
(Perstudentiv.o.)A.Guidi,D.Bordol.GuidaaSQL.Apogeo
OutlineofTodaysLecture
Highqualitysoftware:Stateoftheart
Modelingcomplexsystems
Functionalvs.objectorienteddecomposition
Dealingwithchange:
Softwarelifecyclemodeling
Concludingremarks
Canyoudevelopthis?
LimitationsofNonengineeredSoftware
Requirements
Hereistheproblem!!
Software
SoftwareProductionhasaPoorTrackRecord
Example:SpaceShuttleSoftware
Cost:$10Billion,millionsofdollarsmorethanplanned
Time:3yearslate
Quality:FirstlaunchofColumbiawascancelledbecauseofa
synchronizationproblemwiththeShuttle's5onboardcomputers.
Errorwastracedbacktoachangemade2yearsearlierwhena
programmerchangedadelayfactorinaninterrupthandlerfrom50to80
milliseconds.
Thelikelihoodoftheerrorwassmallenough,thattheerrorcausedno
harmduringthousandsofhoursoftesting.
Substantialerrorsstillexist.
Astronautsaresuppliedwithabookofknownsoftwareproblems
"ProgramNotesandWaivers".
10
SoftwareEngineering:AProblemSolvingActivity
Analysis:Understandthenatureoftheproblemandbreakthe
problemintopieces
Synthesis:Putthepiecestogetherintoalargestructure
Forproblemsolvingweuse
Techniques(methods):
Formalproceduresforproducingresultsusingsomewelldefined
notation
Methodologies:
Collectionoftechniquesappliedacrosssoftwaredevelopmentandunified
byaphilosophicalapproach
Tools:
Instrumentorautomatedsystemstoaccomplishatechnique
11
SoftwareEngineering:Definition
SoftwareEngineeringisacollectionoftechniques,
methodologiesandtoolsthathelpwiththeproductionof
ahighqualitysoftwaresystem
withagivenbudget
beforeagivendeadline
whilechangeoccurs.
12
20
ScientistvsEngineer
ComputerScientist
Provestheoremsaboutalgorithms,designslanguages,definesknowledge
representationschemes
Hasinfinitetime
Engineer
Developsasolutionforanapplicationspecificproblemforaclient
Usescomputers&languages,tools,techniquesandmethods
Hasfinite(usuallyenough)time
SoftwareEngineer
Worksinmultipleapplicationdomains
Hasonly3months...
whilechangesoccursinrequirementsandavailabletechnology
13
Factorsaffectingthequalityofasoftwaresystem
Complexity:
Thesystemissocomplexthatnosingleprogrammercanunderstandit
anymore
Theintroductionofonebugfixcausesanotherbug
Change:
TheEntropyofasoftwaresystemincreaseswitheachchange:Each
implementedchangeerodesthestructureofthesystemwhichmakesthenext
changeevenmoreexpensive(SecondLawofSoftwareDynamics).
Astimegoeson,thecosttoimplementachangewillbetoohigh,andthe
systemwillthenbeunabletosupportitsintendedtask.Thisistrueofall
systems,independentoftheirapplicationdomainortechnologicalbase.
14
Whyaresoftwaresystemssocomplex?
Theproblemdomainisdifficult
Thedevelopmentprocessisverydifficulttomanage
Softwareoffersextremeflexibility
Softwareisadiscretesystem
Continuoussystemshavenohiddensurprises(Parnas)
Discretesystemshave!
15
DealingwithComplexity
1.
2.
3.
Abstraction
Decomposition
Hierarchy
16
1.Abstraction
Inherenthumanlimitationtodealwithcomplexity
The7+2phenomena
Chunking:Groupcollectionofobjects
Ignoreunessentialdetails:=>Models
18
Modelsareusedtoprovideabstractions
SystemModel:
ObjectModel:Whatisthestructureofthesystem?Whataretheobjects
andhowaretheyrelated?
Functionalmodel:Whatarethefunctionsofthesystem?Howisdata
flowingthroughthesystem?
Dynamicmodel:Howdoesthesystemreacttoexternalevents?Howisthe
eventflowinthesystem?
TaskModel:
PERTChart:Whatarethedependenciesbetweenthetasks?
Schedule:Howcanthisbedonewithinthetimelimit?
OrgChart:Whataretherolesintheprojectororganization?
IssuesModel:
Whataretheopenandclosedissues?Whatconstraintswereposedbythe
client?Whatresolutionsweremade?
19
InterdependenciesoftheModels
SystemModel(Structure,
Functionality,
DynamicBehavior)
IssueModel
(Proposals,
Arguments,
Resolutions)
TaskModel
(Organization,
Activities
Schedule)
20
ModelbasedsoftwareEngineering:
Codeisaderivationofobjectmodel
ProblemStatement :Astockexchangelistsmanycompanies.
Eachcompanyisidentifiedbyatickersymbol
Analysis phase results in cbject model (UML Class Diagram):
StockExchange
Lists
Company
tickerSymbol
Implementation phase results in code

publicclassStockExchange
{
publicVectorm_Company=newVector();
};
publicclassCompany
{
publicintm_tickerSymbol
publicVectorm_StockExchange=newVector();
};
Agoodsoftwareengineerwritesaslittlecodeaspossible
Agoodsoftwareengineerwritesaslittlecodeaspossible
22
2.Decomposition
Atechniqueusedtomastercomplexity(divideandconquer)
Functionaldecomposition
Thesystemisdecomposedintomodules
Eachmoduleisamajorprocessingstep(function)intheapplication
domain
Modulescanbedecomposedintosmallermodules
Objectorienteddecomposition
Thesystemisdecomposedintoclasses(objects)
Eachclassisamajorabstractionintheapplicationdomain
Classescanbedecomposedintosmallerclasses
Whichdecompositionistherightone?
25
FunctionalDecomposition
System
Function
ReadInput
ReadInput
Transform
LoadR10
Transform
TopLevelfunctions
Produce
Output
Level1functions
Level2functions
Produce
Output
AddR1,R10
MachineInstructions
26
FunctionalDecomposition
Functionalityisspreadalloverthesystem
Maintainermustunderstandthewholesystemtomakeasingle
changetothesystem
Consequence:
Codesarehardtounderstand
Codethatiscomplexandimpossibletomaintain
Userinterfaceisoftenawkwardandnonintuitive
Example:MicrosoftPowerpointsAutoshapes
(seenextpage)
27
FunctionalDecomposition:Autoshape
Autoshape
Mouse
click
Change
Rectangle
Draw
Change
Change
Oval
Change
Circle
Draw
Rectangle
Draw
Circle
Draw
Oval
28
WhatisThis?
29
ModelofanEskimo
Eskimo
Size
Dress()
Smile()
Sleep()
Shoe
Size
Color
Type
Wear()
Coat
Size
Color
Type
Wear()
30
IterativeModelingthenleadsto....
lives in
Cave
Lighting
Enter()
Leave()
Eskimo
Size
Dress()
Smile()
Sleep()
moves
around
Outside
Temperature
Light
Season
Hunt()
Organize()
Entrance
Windhole
Diameter
MainEntrance
Size
butisittherightmodel?
31
AlternativeModel:TheHeadofanIndian
Indian
Hair
Dress()
Smile()
Sleep()
Ear
Size
listen()
Face
Nose
smile()
close_eye()
Mouth
NrOfTeeth
s
Size
open()
speak()
32
ClassIdentification
Classidentificationiscrucialtoobjectorientedmodeling
Basicassumption:
1. Wecanfindtheclassesforanewsoftwaresystem:Wecallthis
GreenfieldEngineering
2. Wecanidentifytheclassesinanexistingsystem:Wecallthis
Reengineering
3. Wecancreateaclassbasedinterfacetoanysystem:Wecallthis
InterfaceEngineering
Whycanwedothis?Philosophy,science,experimentalevidence
Whatarethelimitations?Dependingonthepurposeofthesystem
differentobjectsmightbefound
Howcanweidentifythepurposeofasystem?
33
WhatisthisThing?
34
ModelingaBriefcase
BriefCase
Capacity:Integer
Weight:Integer
Open()
Close()
Carry()
35
AnewUseforaBriefcase
BriefCase
Capacity:Integer
Weight:Integer
Open()
Close()
Carry()
SitOnIt()
36
Questions
WhydidwemodelthethingasBriefcase?
Whydidwenotmodelitasachair?
WhatdowedoiftheSitOnIt()operationisthemost
frequentlyusedoperation?
Thebriefcaseisonlyusedforsittingonit.Itisnever
openednorclosed.
IsitaChairoraBriefcase?
Howlongshallwelivewithourmodelingmistake?
37
3.Hierarchy
Wegotabstractionsanddecomposition
Thisleadsustochunks(classes,objects)whichweviewwithobjectmodel
Anotherwaytodealwithcomplexityistoprovidesimple
relationshipsbetweenthechunks
Oneofthemostimportantrelationshipsishierarchy
2importanthierarchies
"Partof"hierarchy
"Iskindof"hierarchy
38
PartofHierarchy
Computer
I/O Devices
CPU
Cache
ALU
Memory
Program
Counter
39
IsKindofHierarchy(Taxonomy)
Cell
Muscle Cell
Striate
Smooth
Nerve Cell
Blood Cell
Red
White
Cortical
Pyramidal
40
Sowherearewerightnow?
Threewaystodealwithcomplexity:
Abstraction
Decomposition
Hierarchy
Objectorienteddecompositionisagoodmethodology
Unfortunately,dependingonthepurposeofthesystem,differentobjects
canbefound
Howcanwedoitright?
Manydifferentpossibilities
Ourcurrentapproach:Startwithadescriptionofthefunctionality(Use
casemodel),thenproceedtotheobjectmodel
Thisleadsustothesoftwarelifecycle
41
SoftwareLifecycleActivities
Requirements
Elicitation
System
Design
Analysis
Expressed in
Terms Of
Structured By
...andtheirmodels
Object
Design
Implemen
tation
Implemented
By
Realized By
Verified
By
class...
class...
class...
Use Case
Model
Applicatio
Subsystems
n
Domain
Objects
Testing
Solution
Domain
Objects
Source
Code
?
class.... ?
Test
Cases
42
SoftwareLifecycleDefinition
Softwarelifecycle:
Setofactivitiesandtheirrelationshipstoeachothertosupportthe
developmentofasoftwaresystem
TypicalLifecyclequestions:
WhichactivitiesshouldIselectforthesoftwareproject?
Whatarethedependenciesbetweenactivities?
HowshouldIscheduletheactivities?
43
Reusability
Agoodsoftwaredesignsolvesaspecificproblembutisgeneral
enoughtoaddressfutureproblems(forexample,changing
requirements)
Expertsdonotsolveeveryproblemfromfirstprinciples
Theyreusesolutionsthathaveworkedfortheminthepast
Goalforthesoftwareengineer:
Designthesoftwaretobereusableacrossapplicationdomainsanddesigns
How?
Usedesignpatternsandframeworkswheneverpossible
44
DesignPatternsandFrameworks
DesignPattern:
Asmallsetofclassesthatprovideatemplatesolutiontoarecurring
designproblem
Reusabledesignknowledgeonahigherlevelthandatastructures(link
lists,binarytrees,etc)
Framework:
Amoderatelylargesetofclassesthatcollaboratetocarryoutasetof
responsibilitiesinanapplicationdomain.
Examples:UserInterfaceBuilder
Providearchitecturalguidanceduringthedesignphase
Provideafoundationforsoftwarecomponentsindustry
45
Patternsareusedbymanypeople
ChessMaster:
Openings
Middlegames
Endgames
Writer
TragicallyFlawedHero(Macbeth,
Hamlet)
RomanticNovel
UserManual
SoftwareEngineer
CompositePattern:Acollectionof
objectsneedstobetreatedlikea
singleobject
AdapterPattern(Wrapper):
Interfacetoanexistingsystem
BridgePattern:Interfacetoan
existingsystem,butallowittobe
extensible
Architect
OfficeBuilding
CommercialBuilding
PrivateHome
46
Summary
Softwareengineeringisaproblemsolvingactivity
Developingqualitysoftwareforacomplexproblemwithinalimitedtime
whilethingsarechanging
Therearemanywaystodealwithcomplexity
Modeling,decomposition,abstraction,hierarchy
Issuemodels:Showthenegotiationaspects
Systemmodels:Showthetechnicalaspects
Taskmodels:Showtheprojectmanagementaspects
UsePatterns:Reducecomplexityevenfurther
Manywaystododealwithchange
Tailorthesoftwarelifecycletodealwithchangingprojectconditions
Useanonlinearsoftwarelifecycletodealwithchangingrequirementsor
changingtechnology
Provideconfigurationmanagementtodealwithchangingentities
47

Chapter 1 Lecture 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Chapter 1 Lecture 1

Cargado por

Copyright:

Formatos disponibles

UsingUML,Patterns,andJava

Implementation phase results in code

También podría gustarte