Software Engineering CS 3773
Popular in Course
Popular in ComputerScienence
verified elite notetaker
This 30 page Class Notes was uploaded by Mireya Heidenreich on Thursday October 29, 2015. The Class Notes belongs to CS 3773 at University of Texas at San Antonio taught by Staff in Fall. Since its upload, it has received 14 views. For similar materials see /class/231387/cs-3773-university-of-texas-at-san-antonio in ComputerScienence at University of Texas at San Antonio.
Reviews for Software Engineering
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/29/15
gt Elements of a class diagram 653773 Software Engineering Lecture 04 UML Classes UML Class Diagram Syntax Class represented as a box containing three compartments 0 Name 0 Attributes Operations Relation represented as a line between two classes 0 Association 0 Generalization o Aggregation and com position UTSA 053773 Class and Object Objects are discrete entities with well defined boundaries and encapsulate States 7 behaviors Classes represent types of objects that share a set of n v features attributes operations and relatlo s v Classes describe key concepts involved in the problem domain V Classes are basic building blocks of 00 system UTSA 053773 Class Diagram Perspectives gtgt UML class diagrams can be used in three distinct ways depending on the phase of system development 7 Conceptual Domain Models 0 Ilequir39ements phase The diagram represents the problem that the software should solve classes are realworld concepts in the system 395 env ronment Not necessarily a d rect mapp ng to how these will be mplemented although they may end up being classes n the software system UTSA 053773 Class Diagram Perspectives e Design The diagram is samaieie hm aHribumsaIid apermmns The diagram asp sis an y me interfaces af sanware siasses w siiii aims imaiememaian aeiaiis infarmmian wing e Impiemeriaiiar Thad iagram seams interfaces and impiemenmriansafdasses uisA csam gt ciasses are eaiiiies from ire prabiem domain 7 Aeiurs Mai mieraci Wim sysiem e Anyinfurmahun irai Me sysiem siares araiyzes usinessiransaciiuns phanecunversahuns eic ciasses are named usuaHy byshorismgu arnouns Symax A box Wiih ihree comparimems for names aiiribuies and operaiions respeciiveiy UTSA csam Class Diagram An Example uisA csam Ideniifying Class ciasses are usuaHy derived from ire use cases for ire scenarios currzmiy under deveiapmem gt Brainstorm about IN The zmmzsihaf are rzizvam to the s stem Noun Phrases V 5a irrauar ire use cases and ma aii ire nuun phrases e Waich aui fur ambigumes and reauraam sarsepis uisA csam ATTr ibuTe OperaTion gt OperaTions are The responsibiliTiesservices of an objecT in The class gt OperaTions query or Transform values of objecT39s aTTribuTes change sTaTe gt A class39s aTTribuTes and operaTions documenT The purpose of The class whaT informaTion iT mainTains and how ThaT informaTion can be manipulaTed gt SynTax name parameTers reTurnType UTSA 053773 gt ATTribuTes are simple daTa associaTed wiTh a class e g inTeger seTs daTes gt ATTribuTes are properTies of a class gt ATTribuTes are informaTion ThaT disTinguishes one insTance of The class from anoTher insTance gt They are disTinguishing characTerisTics of The objecTs gt SynTax name Type defaulT value UTsAcsam STaTic ATTribuTe and OperaTion gt STaTic aTTribuTes model daTa values shared by all objecTs of The class e 9 number of objecTs gt STaTic operaTions are classrelaTed operaTions noT offered by insTances of The class e g creaTe 0quot search 0quot gt SynTax underlined aTTribuTe or operaTion UTSA 053773 AssociaTion gt An associaTion is a relaTionship beTween classes gt An associaTion is a name usually shorT verb 7 Some people name every associaTion e OT ers name associaTions only when such names will improve undersTanding e g avoid names like is relaTed Toquot and has gt An associaTion represenTs differenT Types of relaTionships e g daTa flow requesTs parTs of compound class UTSA 053773 AssociaTion SynTax An associaTion may have An associaTion name 7 Association class 7 NavigabiliTy UTSA 053773 MulTipliciTy MulTipliciTies on classes indicaTe how many insTances of The class can be aT run Time v MulTipliciTies consTrain The number of objecTs v SynTax 1 quot eTc aT The Top righT corner of class UTSA 053773 v MulTipliciTy MulTipliciTies on associaTions give lower and upper bound on The number of insTances of The local class ThaT can be linked To one insTance of The remoTe class SynTax1 eTc aT The associaTion end Examples zero or more 1 one or more 1 40 one to 40 5 exachy 5 If no multiplicity is specified the default is1 UTSA 053773 V vv Role Name Is a parT of associaTion Describes how The objecT aT The associaTion end is viewed by The associaTed objecT Is useful for specifying The conTexT of The class SynTax name aT The associaTion end UTSA 053773 Qualified AssociaTion gt Qualified associaTion is an associaTion key ThaT idenTifies The objecT aT The oTher end of The associaTion gt Qualifier is a key or index used To idenTify one or fewer objecTs from seT of many objecTs gt Qualifier is ofTen an aTTribuTe of The class aT The oTher end of The associaTion and The aTTribuTe is recognized as uniquely idenTifying one or fewer objecTs of The class gt SynTax name in box aT The end of an associaTion UTSA 053773 AssociaTion Class gt AssociaTion class allows To add aTTribuTes operaTions To an associaTion gt The associaTion conTains more informaTion gt SynTax class connecTed To The associaTion by a dashed line gt ConsTrainT only one insTance of associaTion class beTween any Two associaTed objecTs UTSA 053773 GeneralizaTion gt IndicaTes an isaquot relaTionship gt All insTances of The subclass are insTances of The super class gt A subclass inheriTs all aTTribuTes operaTions and associaTions of The parenT gt The common aTTribuTes and operaTions are placed in The superclass subclasses exTend The aTTribuTes operaTions and associaTions as They need Them gt SynTax open Triangle aT The superclass end of The associaTion UTSA 053773 AggregaTion gt IndicaTes a loose hasaquot relaTionship gt The compound class is made up of iTs componenT classes gt RepresenTs The wholeparTquot relaTionship in which one objecT consisTs of The associaTed objecTs r The whole conTrols The relaTionship e The parT services requesTs from The whole gt SynTax hollow diamond aT The compound class end of The associaTion UTSA 053773 Aggregation SemarlTics Whole can exisT independenle of The parTs ParT can exisT independenle of The whole Whole is incompleTe if some of The parTs are missing vvvv IT is possible To have shared ownership of The parTs by several wholes UTSA 053773 ComposiTion gt ComposiTion is a parTicular kind of aggregaTion gtgt ComponenT classes are physically parT of The compound class e g a car is composed of an engine wheels eTc gtgt The componenT class dies if The compound class dies gt SynTax filled diamond aT The compound class end of The assoc iaTion UTSA 053773 ComposiTion SemanTics gt ComponenT belong To exachy one compound aT a Time gt Compound is responsible for The creaTion and desTrucTion of all iTs componenTs gt Compound may also release iTs componenTs To oTher compounds gt If The compound is desTroyed iT musT eiTher desTroy all iTs componenTs or give responsibiliTy for Them over To some oTher classes UTSA 053773 Review of Class Diagram Class is a seT of discreTe enTiTies ThaT share The same gt feaTures gt Class encapsulaTes daTa aTTribuTes and funcTions operaTions queries of modifiers gtgt MulTipliciTy consTrains The number of objecTs parTicipaTing in a relaTionship aT any poinT in Time gt RelaTionship represenTs connecTions beTween classes e Association role name qualifier association class navigability e Generalization e Aggregation and composition UTSA 053773 653773 Software Engineering Lecture 7 Basic Modeling Notations Basic Specification Notations Most specification languages are a combination of notations used to describe different aspects of system behavior v Many languages contain variants of the following basic notations 7 Entityrelation diagrams ER Digrams 7 Event Traces 7 State machines 7 Data flow diagrams 7 Logic and functions 7 Algebraic specifications U75A C53773 Modeling Notations Characteristics of agood modeling notation gt Welldefined set of concepts gt CASE tools support gt Resulting in unambiguous clear consistent and concise specification gt Stakeholders understanding them graphical notation is good gt Ability to analyze syntax consistency checking UT5A 053773 Decomposition Strategies Functional decomposition break down a system into functions which complete certain tasks e g date flow diagram gt Process decomposition break down a system into processes that can run concurrently in reaction to events e g state machine gt Object Oriented decomposition break down a system into objects and describe features of each object and their interactions e g ER diagram UTSA 053773 ER Diagram ER diagram entityrelation diagram gt ER diagrams are used for database design gt ER diagrams graphically represent problem domain 7 Entities o bjectsquot r Attributesquotpropertiesquot 7 Relationships often named with verbs gt In 00 terms the problem domain is called the conceptual level of description 7 Origins of class diagrams UML UTSA 083773 ER Diagram Example U78A 083773 ll i ER Diagram Legend Entity class collection of realworld lndlvlduals w common proper es Allrbute properly Relationship between entitles U 78A 083773 gt v ER Diagram Advantages It is simple few symbols It provides an overview of the system Disadvantages What are modeled as entities or attributes May encourage too much detail U 78A 083773 Even r Traces Even i39 Traces graphically describe even i39scommunica i39ion in one scenario gt Show messages be i39ween sys i39em and iTs environmen i39 or among sys i39em en i39i i39ies v Represen i iTera i39i ons v Assume asynchronous communica i39ion nonblocking UTSA 253773 Even r Trace Example Visitor Turnstile coin push UT5A 253773 Even r Trace Legend Legend Objecu Objeth time av vertical line rims line of object horizontal line eventmessage from one 0 men to another UTSA 253773 Even r Trace gt Advan i ages Simple one scenario 7 Easy To undersfand 7 Somewhaf precise alfhough Timing isn39f clear 7 Useful for elicitation and considerafion of endToend sysfem behavior v Disadvan i ages 7 No on efficienf way To represenf behavior UTSA 253773 State Machine State machine describes dialog between system and environment graphically v State machine shows control flow 7 Behavior depends on current state 7 State represents the history of input v State machine compactly represents of a set of event traces UTSA 383773 State Machine Example coinunlock UT SA C 83773 State Machine Legend 0 Stall quotpinnu mislan ni dialog min at nyllnmInvlmnmlnl lEl quot L Stale Tmnsllban ggevad by input event genemles nulpm UTSA c 83773 gt gt State Machine Advantages Most formal least ambiguity Compact way to represent many behaviors Disadvantages More complex Not showing functional decomposition UTSA 383773 Data Flow Diagram Dara ow diagram DFD a sysi em modeis highievei func onaiii y of DFD represer 39s The ow of da ra among componer 39s raphicaiiy UTSA usam Data Flow Diagram Example UTSA usam Data Flow Diagram Legend Dbleci dill suurce u s M rpmaiiy Hard a in sun 039 and n ma aw Pmcess auiian translormamn Mata dam i DilaFiaw ianenemm ma my Data Slme iniemal1gte system dala source or sink NJTa raq cancepi UTSA usam Data Flow Diagram gt Advani39ages mi r am far amianai dzcampasii39ian gt Disadvantages mbigUiTiES r w zndafunc ans gzi39zxzcui zd r IfmuH ipiz mpm39s arz izyaiinudzd cm magma am and mi swig r If mm mm an M aiways gznzmi39zd UTSA usam 653773 Software Engineering Lecture 02 ents Elicitation and Specification Requirements Elicitation Requirements analysts have to understand the problem from each stakeholder39s point of view 7 Stakeholders have different views of the system v Requirements analysts resolve conflicting views 7 Essential requirements 7 Desirable requirements 7 Optional requirements U75A 053773 gt gt Requirements Elicitation Elicitation is to gather 7 Functions that the system should perform 7 Nonfunctional requirements that the system should exhibit Elicitation is critical but difficult 7 Customers are not good at describing what they want 7 Software engineers are not good at understanding what customers want Customers and software engineers speak different languages UT5A 053773 gt gt Understand problems Elicitation Techniques For existing system Review documentation Observe current system Questionnaires and Interviews Apprenticeship For new systems brainstorming UT5A 053773 Analyze Existing System gt What is used what isn39t what39s missing gt What works well what doesn39t gt How the system is used how it was intended to be used what new ways we want it to be used gt Risks 7 Users might not be happy with too much change from the old system 7 Might miss real usage patterns 7 Might miss obvious possible improvements UT5A 053773 Analyze Existing System Review gt Review all available documentation 7 For an automated system review its requirements specifications and user manuals as well as development ocumentation internal memos change histories etc 7 For a manual system review any documented procedures that the workers must follow v Gain knowledge of the system before imposing upon other people39s time before bothering the stakeholders UT5A 053773 Analyze Existing System Observation gt Identify what aspects to keep and to understand the system you are about to change gt System contains a lot of useful functionality that should be included in any future system gt Documentation rarely describes a system completely and not up to date and gt Current operation of the system may differ significantly from what is described UT5A 053773 Analyze Existing System Interview gt Questionnaires are useful when information has to be gathered from a large number of people gt The answers to questions need to be compared or corroborated gt Ask problemoriented questions during interview gt Interview groups of people together to get synergy UT5A 053773 Analyze EXisTing SysTem ApprenTice gt The requiremenTs analysT is The apprenTice and The user is The masTer crafTsman gt The user can 7 Describe The Task precisely 7 Explain why The Task is done This way 7 LisT The excepTions ThaT can occur UT5A 053773 BrainsTorm gt BrainsTorm is used To gaTher ideas from every sTakeholder and prune ideas gt When you have no idea or Too many ideas siT down and Thrash iT ouT buT wiTh some ground rules gt MosT useful early on when Terrain is uncerTain or when you have liTTle experience or when novelTy is imporTanT UT5A 053773 BrainsTorm gt Keep The Tone informal and nonjudgmenTal gt Encourage creaTiviTy gt Keep The number of parTicipanTs quotreasonablequot if Too many consider a playoffquotType filTering gt InviTe back mosT creaTive To mulTiple sessions UT5A 053773 BrainsTorm The STorm gt GeneraTe as many ideas as possible gt QuanTiTy noT qualiTy is goal aT This sTage gt No criTicism or debaTe is permiTTed gt WriTe down all ideas where all can see gt ParTicipanTs should NOT selfcensor or spend Too much Time wondering if an idea is pracTical gt Original lisT does noT geT circulaTed ouTside of The meeTing UT5A 053773 BrainsTorm The Calm gt Go over The isT and explain ideas more carefully gt CaTegorize inTo quotmaybequot and quotnoquot by preagreed consensus meThod gt Be careful abouT Time MeeTings Tend To lose focus afTer 90 To 120 minuTes gt Review consolidaTe combine clarify and expand gt Rank The isT by prioriTy somehow choose a winner UT5A 053773 BrainsTorm Pruning gt VoTe wiTh Threshold 7 Each person voTes up To n Times 7 Keep Those ideas wiTh more Than m voTes 7 Have mulTiple rounds Thereof wiTh smaller n and m v VoTe wiTh campaign speeches 7 Each person voTes up To j lt n Times 7 Keep Those ideas wiTh aT leasT one voTe 7 Have mulTiple rounds Thereof wiTh smaller UT5A 053773 RequiremenTs Analysis gt UndersTand The desired behavior 7 InTerpreT The sTakeholders39 descripTions of requiremenTs 7 Resolve ambiguiTies conTradicTions loose ends eTc gt Build models 7 Use sTandard noTaTions 7 Help us To undersTand The requiremenTs UT5A 053773 RequiremenTs WhaT vs How gt RequiremenTs describe purpose and scope of The sysTem 7 WhaT behavior The cusTomer wanTs 7 NoT how The behavior is realized gt RequiremenTs focus on cusTomer and problems 7 UndersTand The cusTomer39s needs 7 Describe The background and overview of The problem gt RequiremenTs represenT objecTs sTaTes and funcTions gt RequiremenTs include assumpTions of The environmenT UT5A 053773 RequiremenTs SpecificaTion 39 gt Specify requiremenTs 7 DocumenT whaT is required of The sysTem To be developed 7 STaTe The requiremenTs from The perspecTive of The developers 7 May be a formal documenT IEEESRS gt RequiremenTs documenT and specificaTion documenT are differenT 7 RequiremenTs documenT is a conTracT 7 SpecificaTion is a deTailed guideline for developers UT5A 053773 RequiremenTs vs SpecificaTion gt RequiremenTs documenT is 7 A compleTe lisT on whaT cusTomers wanT 7 In Terms of environmerrT wiThouT reference To sysTem 7 A conTracT beTween clienTs and developers v SpecificaTion represenTs 7 SysTem s behavior in Terms of The inpuT and oquuT of a sysTem 7 Which requiremenTs shall be realized by The sysTem 7 How environmerrT enTiTies are conTrolled by The sysTem UT5A 053773 RequiremenTs vs SpecificaTion SpecificaTion DaTa sTrucTures and algoriThms RequiremenTs UT5A 053773 RequiremenTs vs SpecificaTion gt RequiremenTs are a collecTion of sTaTemenTs abouT phenomena in The environmenT ThaT we wanT The sysTem To help make True gt A specificaTion is a collecTion of sTaTemenTs ThaT describe a sysTem39s exTernal behavior as observable Through The InTerface 7 A specificaTion refers only To shared phenomena in The inTerface and whaT The sysTem shall do 7 A r sysTem iTself can conTrol mu me UT5A 053773 Requirements vs Specification ample a turnstile to the park Requirements 1 No one should enter the park without pay ng an entrance fee gtEx 2 For every entrance fee paid the system should not prevent a correspond ng entry 7 Specification When avisitor applies a certain amount of force on an unlocked turnstile the turnstile will rotate till a locked position UT5A 053773 Specification Verification gt Verify the specification against requirements 7 Conforms to the requirement definition 7 Build the system right gt Verification can be done with techniques 7 Simulation 7 Consistency checking 7 Completeness checking e Formal verification model checking or mathematical reasoning U75A 053773 gt v Requirements Validation Validate the requirements against stakeholders 7 Reflect accurately customer39s need 7 Also create systemlevel test plans Validation can be done with techniques 7 Walkthrough Review 7 Prototype 7 Formal inspection UT5A 053773 v v v v Software Requirements Specifications Introduction Overall description Specific requirements Requirements table UT5A 053773 Software Requirements Specification Section 0 Table of Contents Essential for tracing through use cases classes state diagrams Table of Figures Essential for finding each diagram List of Tables Essential for finding each table UT5A 053773 Software Requirements Specification Section 2 General description 2 1 Product perspective the environment Any hardware and software components that interact with the system Overview of the interfaces to other component A block diagram would be nice U75A 053773 Software Requirements Specification Section 1 Introduction 11 Purpose of the SRS e g the intended audience 1 2 Scope 1 3 Acronyms abbreviations notational conventions 1 4 Overview e g the structure of the rest of the SR5 document 15 References Can be put at the end of the document UT5A 053773 Software Requirements Specification Section 2 General description 2 2 Product functions Overview of the system39s main functions No detail description At the level of use case names 2 3 User characteristics Assumptions about the user UT5A 053773 Software Requirements Specification 39 Section 2 General description 2 4 General constraints e g laws hardware limitations Any sources of constraints on requirements or design 2 5 Assumptions and Dependencies Assumptions about the environment Any environmental conditions that could cause the system to fail UT5A 053773 Software Requirements Specification Section 3 Specific requirements 3 1 Functional requirements 3 11 Use case diagrams and detail description in tabular format Number each use case for future reference 312 Class diagrams 313 State diagrams 3 14 Sequence diagrams In each above section 31x give English introduction to each diagram to help the reader understand each diagram UT5A 053773 Software Requirements Specification Section 3 Specific requirements continued 31 Functional requirements continued 3 15 Data dictionary in tabular format classes purpose Attr butes purpose range of values Operations purpose parameters prepost conditions Events purpose source destination parameters 1 UT5A 053773 Software Requirements Specification Section 3 Specific requirements 3 2 User interface requirements Screen shots Purpose of each button menu options etc List of inputoutput events How to navigate among w ndows UT5A 053773 653773 Software Engineering Lecture 0 UML State Machines Siaia Diagram Siaia diagram shows how asysizm or an oszci s behavior changzs over iimz dzpznding on the mpr raith ihan raprasanr 2ndri072nd behavior Shows how asysizm or an oszci rzacis io messages eczivzd r Whioh siaia iha ubJecisnaH ga ia 7 When ii auipuis messages in aiher ubJecis Haw an abject changes iha vaiues uf iis aiiribaias by assignmenis UisAcs iua Siaia Diagram Recaii iha dziays in a sequence diagram baiwaan when an oszci nzczivzs amzssagz and whzn ii ompuis anoihzn message State diagram shows whai iha oszcr does in baiwaan iha rmwing and iha sending of messages show iha behavior of an oszci across severai use cases gt One siaia diagram per ciass io describes possibiz behavior for each instance of H12 ciass uisAcssiua Siaia Diagram An Example uisAcssiua STaTe Diagram gt ElemenTs of a sTaTe diagram STaTe represenTs The mode of The sysTem Always an iniTial sTaTe sTarTing sTaTe SomeTimes a final sTaTe TransiTion describes a change in sTaTe due To The occurrence of an evenT From one sTaTe To anoTher sTaTe UTSA CS5103 TransiTion gt ElemenTs of a TransiTion evenTargs condiTion acTiviTy gt Each of These parTs is opTional gt Form event condactivity src UTSA CS5103 STaTe ParTiTions objecT behavior e g noT being able To check ouT a borrowed book RepresenTs The hisTory of inpuTs so far AffecTs whaT inpuT The objecT will reacT To e g ignoring mosT inpuT in The sTaTe losT Is an assignmenT To a collecTion of aTTribuTes UTSA CS5103 gt An evenT Triggers The TransiTion A change in The environmenT e g offHook A message from anoTher objecT operaTion call A change in a condiTion going from false To True e g whenTemperaTure gt 100 degrees An occurrence of a specific daTeTime or passage of Time e g afTer 20 minuTes UTSA CS5103 CondiTion A condiTion is a Boolean expression gt An evenT occurs insTanTaneously and iT doesn39T persisT gt EvenTs make an objecT change sTaTe gtgt The value of a condiTion persisTs unTil The variables involved gt If The objecT is in a sTaTe and There is no ouTgoing lquot 5 condl or Charge le values TransiTion Triggered by an evenT The evenT is ignored gtgt The TransiTion cannoT fire unless The guard condiTion is gt MulTiple evenTs on a TransiTion label are ORed TogeTher True v m x o 3 391 m in e paTronHasNoOverdueFine UTsAcsaina UTsAcsaina AcTiviTy STaTe AcTiviTies An acTiviTy is whaT an objecT does in response To evenTs gt A sTaTe can have acTiviTies associaTed wiTh iT gt An acTiviTy is simple fasT noninTerrupTible gt Two Types of sTaTe acTiviTies can manipulaTe objecT gt aTTribuTes or oTher variables 7 variable ussignmenT 7 Activity simpie noninTerrupTible send a message to an object Associated wiTh atransition P f d t t t 39t gt MulTiple acTiviTies on aTransiTion are separaTed by quot and o N M o a 22quot ry r 2quot awed sequzn any 7 Do activity interruptible may require much computation AssociaTed wiTh a sTaTe o Interrupted by a transition UTsAcsaina UTsAcsaina State Activities gt States can be annotated wtth entrv or extt acttvtttes tnternat acttvtttes and do acttvtttes entrvacttvttv eventacttvnv wav to descrtbe reacttons to events that don t can a state change W tnternat transtttons exttacttvttv doacttvttv wsAcsstua SelfTransition gt A seifrtt ansttton Wlii cause reactivatton of egtlttt and then entrv events If vou want a seit rtt ansltton That does not acttvate these events you can use an mtet vtai transttton tabeted wtth the event and the assoctated acttvttv e g reqreptv tn state s msAcsstua State Activities gt In a transttton the order of effects 7 Exit aettvtttes at suurc Transtttan aettvtttes Entry aettvtttes at aesttnattan and 7 State aettvtttes wsAcsstua SelfTransition gt Compared to an acttvttv on atransttton one couid achteve the same behavtor as activity m state 7 as activitym anuther spectai state wsAcsstua More on TransiTion If a TransiTion has no evenT label iT can occur once any acTiviTy associaTed wiTh The sTaTe is compleTe v Guards on TransiTions Triggered by The same evenT leaving a sTaTe should be muTually exclusive UT8A 385103 STaTe Hierarchy ComposiTe sTaTe a sTaTe can conTain oTher sTaTes V ComposiTe combines sTaTes and TransiTions ThaT work TogeTher Towards a common goal V If a TransiTion leaves a composiTe sTaTe This TransiTion applies To all The subsTaTes and has higher prioriTy Than The TransiTions wiThin The composiTe sTaTe gt The subsTaTes inheriT The TransiTions of The composiTe sTaTe gt Basic sTaTe a sTaTe do noT conTain oTher sTaTes UT8A 385103 Summary on STaTe and TransiTion State Name event1 condi ion activityi activity2 Entryactivity Exitactivity Eventactivity doactivity UT8A 385103 STaTe Diagram WiThouT ComposiTe STaTe borrow UT8A 385103 sae Diagram wih Composie sae borrow last uTsAcs ma Orhogonal Composie sae v An orthogonal state captures two or more behaviors of the obJeCt that happen concurrently each wtth tts own control thread If there are many orthogonal states for one obJect you shou Id cons obJects ider dividing the behavior between more ursAcsama Orhogonal sae An Example i uTsAcs ma Types of Orhogonal saes gt gt Aggregatlol l concurrenc State dtagram for an aggregate obJecO s a collechon of state dtagrams each of whlch corresponds to a conshtuenl c J2 Synchronization of concurrent actlvltles wtthtn one obJeCt bJecl performs two or mor e acllvlhes concurrently ObJecl completes both clcllvllles before It progress to anther state ursAcsama History Htstory ts amechamsm by whtch a reietttered compostte state can conttnue executmg from the subrstate that was rrent when controt tast transtttoned out at the compostte s at History Htstory ts a pseudostate whose meantng ts to destgnate the tmmedtate subrstates at thts tevet mthe hterarchy that system was tn when the tmmedtate parentstate was tast extted t ttstory state can be the desttnatton state eta transttton A transttton teavtng a htstory state tndtcates what subr states to enter tt the system has ever been tn thts state Syntax utsA csst us gt Deep htstory gt ShaHowhtstory UYSACSStm Deep History gt Appty htstory at GM teyets tn the hterarchy betow the htstory pseudostat gt Enter the subrstates that an ObJBCt was tast m whth the state was extted Syntax UTSA csstus History 5mg An Example utsA csst us History of UML 653773 Software Engineering gt UML appeared in 1997 after many years of modeling war 7 1994 Rumbaugh OMT joined Booch 7 1995 Rational bought Objectory Jacobson OOSE use cases Lecture 03 ML Use Case Modeling 7 Rumbaugh Booch and Jacobson are known as the Three Amigosquot 7 UML GMT Booch 005E UT5A 053773 Introduction Three UML Modes gt Sketch 7 Some aspects of the system 7 For communication purpose Blueprint 7 Complete description of the system 7 For designers Programming language 7 All details of the system 7 For code generation purpose gt UML is a set of modeling notations which include 13 diagrams 7 Static structure of the system Class diagram ERD Object diagram v 7 Dynamic behavior of the system Use case diagram Sequence diagram Event traces State diagram EFSM v U75A 053773 UT5A 053773 O bject Oriented A nalysis Four key steps in OOA gt Define the use cases Describe how users interact with the system gt Define the domain model Find the objects classes gt Define the interaction diagrams Describe the interaction between the objects gt Define design class diagrams UT5A 053773 Use Case Modeling gt Use cases are captured in four steps 7 Find a candidate system boundary 7 Find the actors 7 Find the use cases 0 Specify the use case 0 Identify key alternative scenarios 7 Iterate until use cases actors and system boundary are st le UT5A 053773 Actors gt Actors are external to the system gt An actor specifies a role 7 Users that operate the system directly 7 Other software systems or hardware pieces that interact with the system One person or thing may play many roles in relation to the system simultaneously or over time Actors do not represent specific people or specific things v v UT5A 053773 Use Cases gt Use cases are usages of the system gt Use cases capture the functional requirements 7 Use cases provide the highlevel descriptions of the system s functionality in terms of interactions 7 Use cases show inputs and outputs between the system and the environment 7 Use cases are from the user39s point of view Users and other software systems in the environment UT5A 053773 Use Case An Example gt ATM system 7 Withdraw cash 7 Check account balance 7 Maintain usage statistics UTSA 053773 Actor an entity in the environment that initiates and interacis with the system Q Use case usage of system a set of sequences of actions Association relation between actorand use Cass Includs dependency a sub use case Extends dependency a sequence of use cases UTSA cs3773 UML Use Case Diagram System drawn as a box gt Actars outside the system 7 Relations among actors gt Use cases inside the system 7 Relations among use cases UTSA 053773 Use Case Diagram for ATM AIM sylun Check alance e vwhdvavucash UTSA 053773 Use Case Diagram for ATM ATM System Check alance dude we inciud Cusamev TransferManey i Cuiiectu sagestats WWW pygmyeucum ev UT5A 053773 Process for Identifying Use Cases vvvvvvvv Choose your system boundary Identify primary actors For each actor find their goals Define a use case for each goal Identify the possible variations and error conditions Define relationships among actors Decompose complex use cases into subuse cases Organize normal alternatives as extension use cases UT5A 053773 Description of A Use Case vvvvvvvv Give a unique number for referencing UC Choose an appropriate name Give a brief description Associate with the initiating actor and other actors Identify preconditions assumptions Describe the postcondition Describe the normal scenario as a sequence of steps Identify all possible variations and error conditions for each step UT5A 053773 Scenario v v A use case is a set of scenarios All these scenarios have the same goal A scenario is a sequence of interactions between a user and a system UT5A 053773