Using UML, Patterns, and JavaObject-Oriented Software EngineeringModeling with UMLChapter 2Object-Oriented Software Engineering:Using UML, Patterns, and Java, 2ndEditionBy B. Bruegge and A. Dutoit Prentice Hall, 2004.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 2What is modeling?+ Modeling is a means of dealing with complexity.+ Modeling consists of building an abstraction of reality.+ Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details.+ What is relevant or irrelevant depends on the purpose of the model.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 3Why build models in software engineering?+ Software is getting increasingly more complex Windows XP > 40 million lines of code A single programmer cannot manage this amount of code in its entirety. + Code is not easily understandable by developers who did not write it+ We need simpler representations for complex systems Modeling is a mean for dealing with complexityModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 4What to Model?+ We need models of the application and solution domains.+ Application Domain (Requirements Analysis): The environment in which the system is operating Application domain models help us define the problem+ Solution Domain (System Design, Object Design): The available technologies to build the system Solution domain models help us address the problem systematicallyModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 5Modeling with UML+ What is UML?+ Use case diagrams+ Class diagrams+ Sequence diagrams+ Statechart diagrams+ Activity diagramsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 6What is UML?+ UML (Unified Modeling Language) An emerging standard for modeling object-oriented software. Resulted from the convergence of notations from three leading object-oriented methods:4 OMT(James Rumbaugh)4 OOSE (Ivar Jacobson)4 Booch (Grady Booch)+ Reference: http://www.uml.org + Supported by several CASE tools Rational ROSE TogetherJModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 7UML: First Pass+ You can model 80% of most problems by using about 20 % UML+ We teach you those 20%Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 8UML First Pass+ Use case diagrams Describe the functional behavior of the system as seen by the user.+ Class diagrams Describe the static structure of the system: Objects, Attributes, Associations+ Sequence diagrams Describe the dynamic behavior between actors and the system and between objects of the system+ Statechart diagrams Describe the dynamic behavior of an individual object(essentially a finite state automaton)+ Activity diagrams Model the dynamic behavior of a system, in particular theworkflow (essentially a flowchart)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 9UML first pass: Use case diagramsWatchUser WatchRepairPersonReadTimeSetTimeChangeBatteryActorUse casePackageWatchUse case diagrams represent the functionality of the systemfrom users point of viewModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 10UML first pass: Class diagrams12push()release()11blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()LCDDisplay Batteryload121Timenow1WatchClassAssociationMultiplicityAttributeOperationsClass diagrams represent the structure of the systemstatePushButtonModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 11UML first pass: Sequence diagram:LCDDisplayblinkHours()blinkMinutes()refresh()commitNewTime():TimeincrementMinutes()stopBlinking():WatchpressButton1()pressButton2()pressButtons1And2()pressButton1():WatchUserObjectMessageActivationSequence diagrams represent the behavior as interactionsActorLifelineModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 12UML first pass: Statechart diagrams for objects with interesting dynamic behaviorB l i n k H o u r sB l i n k M i n u t e sI n c r e m e n t H r sI n c r e m e n t M i n .B l i n k S e c o n d s I n c r e m e n t S e c .S t o p B l i n k i n g[ b u t t o n 1 & 2 P r e s s e d ][ b u t t o n 1 P r e s s e d ][ b u t t o n 2 P r e s s e d ][ b u t t o n 2 P r e s s e d ][ b u t t o n 2 P r e s s e d ][ b u t t o n 1 P r e s s e d ][ b u t t o n 1 & 2 P r e s s e d ][ b u t t o n 1 & 2 P r e s s e d ]StateInitial stateFinal stateTransitionEventRepresent behavior as states and transitionsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 13Other UML NotationsUML provide other notations that we will be introduced in subsequent lectures, as needed.+ Implementation diagrams Component diagrams Deployment diagrams Introduced in lecture on System Design+ Object constraint language Introduced in lecture on Object DesignModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 14UML Core Conventions+ Rectangles are classes or instances+ Ovals are functions or use cases+ Instances are denoted with an underlined names myWatch:SimpleWatch Joe:Firefighter+ Types are denoted with non underlined names SimpleWatch Firefighter+ Diagrams are graphs Nodes are entities Arcs are relationships between entitiesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 15Use Case Diagrams+ Used during requirements elicitation to represent external behavior+ Actors represent roles, that is, a type of user of the system+ Use cases represent a sequence of interaction for atype of functionality+ The use case model isthe set of all use cases. It is a complete description of the functionality of thesystem and its environmentPassengerPurchaseTicketModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 16Actors+ An actor models an external entity which communicates with the system: User External system Physical environment+ An actor has a unique name and an optional description.+ Examples: Passenger: A person in the train GPS satellite: Provides the system withGPS coordinatesPassengerModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 17Use CaseA use case represents a class of functionality provided by the system as an event flow.A use case consists of:+ Unique name+ Participating actors+ Entry conditions+ Flow of events+ Exit conditions+ Special requirementsPurchaseTicketModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 18Use Case Description: ExampleName: Purchase ticketParticipating actor: PassengerEntry condition:+ Passengerstanding in front of ticket distributor.+ Passengerhas sufficient money to purchase ticket.Exit condition:+ Passengerhas ticket.Event flow:1. Passengerselects the number of zones to be traveled.2. Distributor displays the amount due.3. Passengerinserts money, of at least the amount due.4. Distributor returns change.5. Distributor issues ticket.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 19The Relationship+ relationships represent exceptional or seldom invoked cases.+ The exceptional event flows are factored out of the main event flow for clarity.+ Use cases representing exceptional flows can extend more than one use case.+ The direction of a relationship is to the extended use casePassengerPurchaseTicketTimeOut

NoChange

OutOfOrder

Cancel

Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 20The Relationship+ relationship represents behavior that is factored out of the use case.+ behavior is factored out for reuse, not because it is an exception.+ The direction of a relationship is to the using use case (unlike relationships).PassengerPurchaseSingleTicketPurchaseMultiCardNoChange

Cancel

CollectMoney

Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 21Use Case Diagrams: Summary+ Use case diagrams represent external behavior+ Use case diagrams are useful as an index into the use cases+ Use case descriptions provide meat of model, not the use case diagrams.+ All use cases need to be described for the model to be useful.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 22Class Diagrams+ Class diagrams represent the structure of the system.+ Used during requirements analysis to model problem domain concepts during system design to model subsystems and interfaces during object design to model classes.Enumeration getZones()Price getPrice(Zone)TarifSchedule**Tripzone:ZonePrice: PriceModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 23Classes+ A class represent a concept+ A class encapsulates state (attributes) and behavior (operations).+ Each attribute can have a type.+ Each operation can have a signature.+ The class name is the only mandatory information.zone2pricegetZones()getPrice()TarifScheduleTablezone2priceEnumerationgetZones()PricegetPrice(Zone)TarifScheduleNameAttributesOperationsSignatureTarifScheduleModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 24Instances+ An instance represents a phenomenon.+ The name of an instance is underlined and can contain the class of the instance.+ The attributes are represented with their values.zone2price = {{1, .20},{2, .40},{3, .60}}tarif_1974:TarifScheduleModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 25Actor vs Instances+ What is the difference between an actor,a class and an instance?+ Actor: An entity outside the system to be modeled, interacting with the system (Passenger)+ Class: An abstraction modeling an entity in the problem domain, must be modeled inside the system (User)+ Object: A specific instance of a class (Joe, the passenger who is purchasing a ticket from the ticket distributor).Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 26PriceZoneAssociations+ Associations denote relationships between classes.+ The multiplicity of an association end denotes how many objects the source object can legitimately reference.Enumeration getZones()Price getPrice(Zone)TarifScheduleTripLeg**Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 271-to-1 and 1-to-many AssociationsCountryname:StringCityname:StringHas-capitalPolygondraw()Pointx: Integery: IntegerOne-to-one associationOne-to-many association*1 1Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 28Many-to-Many Associations StockExchangeCompanytickerSymbolLists * *StockExchangeCompanyLists 11tickerSymbol SX_IDSX_IDModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 29From Problem Statement ToObject ModelProblem Statement: A stock exchange lists many companies. Each company is uniquely identified by a ticker symbolClass Diagram:StockExchangeCompanytickerSymbolLists* *Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 31Aggregation+ An aggregation is a special case of association denoting a consists of hierarchy.+ The aggregate is the parent class, the components are the children class.+ A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate. (Bill of Material)TicketMachineZoneButton3Exhaust systemMufflerdiameterTailpipediameter10..2Exhaust systemMufflerdiameterTailpipediameter10..2Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 32Qualifiers+ Qualifiers can be used to reduce the multiplicity of an association.DirectoryFilefilenameWithout qualification1 *With qualificationDirectory File011filenameModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 33Inheritance+ The children classes inherit the attributes and operations of the parent class.+ Inheritance simplifies the model by eliminating redundancy.ButtonZoneButton CancelButtonModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 34Packages+ A package is a UML mechanism for organizing elements into groups(usually not an application domain concept)+ Packages are the basic grouping construct with which you may organize UML models to increase their readability.+ A complex system can be decomposed into subsystems, where each subsystem is modeled as a package+ Packages show system and/or subsystem boundaries, thus clarifying the interfaces between a user and the system or between subsystems.DispatcherInterfaceNotificationIncidentManagementModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 35UML sequence diagrams+ Used during requirements analysis To refine use case descriptions to find additional objects (participating objects)+ Used during system design to refine subsystem interfaces+ Classes are represented by columns+ Messages are represented by arrows+ Activations are represented by narrow rectangles+ Lifelines are represented by dashed linesselectZone()pickupChange()pickUpTicket()insertCoins()PassengerTicketMachineModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 36Nested activations+ The source of an arrow indicates the activation which sent the message+ An activation is as long as all nested activations+ Horizontal dashed arrows indicate data flow+ Vertical dashed lines indicate lifelinesselectZone()PassengerZoneButton TarifSchedule DisplaylookupPrice(selection)displayPrice(price)priceDataflowto be continued...Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 37Iteration & condition+ Iteration is denoted by a * preceding the message name+ Condition is denoted by boolean expression in [ ] before the message namePassengerChangeProcessorinsertChange(coin)CoinIdentifier Display CoinDropdisplayPrice(owedAmount)lookupCoin(coin)price[owedAmount Associationfor Use Cases+ Problem: The functionality in the original problem statement needs to be extended.+ Solution: An extend association from a use case A to a use case B indicates that use case B is an extension of use case A.+ Example: The use case ReportEmergency is complete by itself , but can be extended by the use case ConnectionDown for a specific scenario in which the user cannot communicate with the dispatcherReportEmergencyFieldOfficer fConnectionDown

Note: The base use case can be executed without the use case extension in extend associations.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 87Identifying Initial Analysis Objects+ Identify the participating objects to create the initial analysis object model+ Maintaining glossary of objects minimizes potential confusion in terminology between users and developers+ Heuristics Terms the needed clarification (by developer or user) Recurring nouns in use cases Real-world entities and resources that system must track Use cases Data sources or sinks Artifacts with which user interacts Use application domain terms+ Cross-check Eliminate ambiguity: verify that objects with the same name refer to the same concept Maintain consistency: verify that objects do not refer to the same concept using different names Eliminate objects not involved in any use casesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 88Identifying Nonfunctional Requirements(FURPS+ Classification Scheme)+ Quality Requirements Usability Reliability/Dependability4 Safety4 Security4 Survivability Performance4 Response Time4 Throughput4 Availability4 Accuracy Supportability4 Adaptability4 Maintainability4 Portability+ Pseudo Requirements Implementation Interface Operations Packaging LegalModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 89Identifying Nonfunctional Requirements+ Heuristics Use a taxonomy (e.g., FURPS+) to generate checklists Give different checklists to users in appropriate roles Checklists vary depending on application domainModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 90Nonfunctional Requirements: Trigger QuestionsUser interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available, and what are their characteristics?Documentation What kind of documentation is required? What audience is to be addressed by each document?Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 91Nonfunctional Requirements, ctdPerformance characteristics Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system?Error handling and extreme conditions How should the system respond to input errors? How should the system respond to extreme conditions?System interfacing Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 92Nonfunctional Requirements, ctdQuality issues What are the requirements for reliability? Must the system trap faults? What is the maximum time for restarting the system after a failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to different hardware or operating system environments)?System Modifications What parts of the system are likely candidates for later modification? What sorts of modifications are expected?Physical Environment Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields, ...)?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 93Nonfunctional Requirements, ctdSecurity Issues Must access to any data or the system itself be controlled? Is physical security an issue?Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 94Constraints (Pseudo Requirements)+ Constraint: Any client restriction on the solution domain+ Examples: The target platform must be an IBM/360 The implementation language must be COBOL The documentation standard X must be used A dataglove must be used ActiveX must be used The system must interface to a papertape readerModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 95How to Specifya Use Case (Summary)+ Name of Use Case+ Actors Description of Actors involved in use case)+ Entry condition This use case starts when+ Flow of Events Free form,informal natural language+ Exit condition This use cases terminates when+ Exceptions Describe what happens if things go wrong+ Special Requirements Nonfunctional Requirements, ConstraintsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 96Managing Requirements Elicitation+ Negotiating specifications+ Maintaining traceability+ Tool supportModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 97Negotiating Specifications (JAD)+ Use case modeling is useful in requirements elicitation, but it is not the only activity+ Requirements have to be identified and negotiated between different stakeholders+ JAD Joint Application Design+ A moderated meeting with all stakeholders participating Users, clients, developers + trained facilitator+ Leverages group dynamics of face-to-face meetings+ Developers get to understand application domain+ Users get to understand potential solution domain tradeoffsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 98JAD Activities+ Project definition Facilitator determines objectives and scope of project through interviews with project manager and client+ Research Facilitator interviews present and future users Facilitator gathers information about application domain Facilitator creates initial high-level use cases Facilitator creates initial list of problems+ Preparation Facilitator creates Working Document, agenda and presentation materials Facilitator forms team with adequate representation from all stakeholdersModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 99JAD Activities+ Session Facilitator guides team in creating the requirements specification4 Discover new requirements4 Classify and organize requirements4 Prioritize requirements4 Validate requirements4 Derive use cases4 Activities are repeated until closure is achieved+ Final document preparation Facilitator prepares Final Document Team reviews and approves Final DocumentModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 100JAD Facilitator+ Qualifications of JAD facilitator is crucial+ Must keep the discussion within the scope of the project+ Discern wants from needs + Keep the discussion within the application domain to avoid prescribing requirements that restrict the solution space unnecessarily (pushing specific technology, methodology or language)+ Mediate disputes before they get out of hand+ Watch out for political influences and hidden agendasModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 101Maintaining Traceability+ Traceability the ability to follow the life of a requirement as it is translated into design and then implementation and test cases+ The system is complete when all requirements can be traced to implementation+ Traceability also enables developers to uncover the rationale behand certain requirements and design decisions + Traceability is harder for nonfunctional requirements+ Traceability is difficult to maintain manually Need to maintain cross-references between different artifacts (requirements, design documents, code, test plan, user documentation) Need tool supportModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 102Tool Support+ Requirements for Managing Requirements Store requirementsin a shared repository Provide multi-user access Automatically create a system specification document from the repository Allow change management Provide traceability throughout the project lifecycleModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 103Summary+ The requirements process consists of requirements elicitation and analysis.+ The requirements elicitation activity is different for: Greenfield Engineering, Reengineering, Interface Engineering+ Scenarios: Great way to establish communication with client Different types of scenarios: As-Is, visionary, evaluation and training Use cases:Abstraction of scenarios+ Problems with functional decomposition: Leads to unmaintainable code+ Problems with object identification: May lead to wrong objects, wrong attributes, wrong methods+ The key to successful analysis: Start with use cases and then find theparticipating objects If somebody asks What is this?, do not answer right away. Return the question or observe the end user: What is it used for?+ Use case modeling is a part of the requirements elicitation process, not the entire process itself.Using UML, Patterns, and JavaObject-Oriented Software EngineeringRequirements AnalysisChapter 5(Part 1 Object Modeling)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 105Outline+ From use cases to class diagrams+ Model and reality + Activities during object modeling Object identification Object types Heuristics Refinement of object models+ Other issuesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 106Requirements Analysis+ Formalization of requirements elicited from users+ Analysis models Functional model (use cases) Analysis object model (class diagrams) Dynamic model (statechart and sequence diagrams)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 107Analysis Activities+ Identifying entity objects+ Identifying boundary objects+ Identifying control objects+ Mapping use cases to objects with sequence diagrams+ Modeling interactions among objects with CRC cards+ Identifying associations+ Identifying aggregates+ Identifying attributes+ Modeling state-dependent behavior of individual objects+ Modeling inheritance relationships between objects+ Reviewing the analysis modelObject ModelingDynamic ModelingModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 108From Use Cases to ObjectsLevel 1 Use CaseLevel 2 Use CasesLevel 3 Use CasesOperationsParticipatingObjectsLevel 2Level 1Level 2Level 3 Level 3Level 4 Level 4Level 3A BModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 109From Use Cases to Objects: Why Functional Decomposition is not EnoughScenariosLevel 1 Use CasesLevel 2 Use CasesOperationsParticipatingObjectsLevel 2Level 1Level 2Level 3 Level 3Level 4 Level 4Level 3A BModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 110Object Models+ Analysis Object Model Classes and objects that describe the application domain Part of the Requirements Analysis Document (RAD) Examples: BoardGame, Watch+ Solution Object Model Classes and objects that are used to solve the problem Part of the Object Design Document (ODD) Examples: Tree, Hashtable, Widget+ During Requirements Analysis, we focus on building the Analysis Object ModelModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 111Object Models and Dynamic Models+ Object model Focuses on individual concepts manipulated by system Class diagrams represent relationships between classes and objects and properties of those classes and relationships+ Dynamic model Focuses on behavior of the system Sequence diagrams represent interactions between objects within a single use case Statecharts represent behavior within a single objectModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 112Outline+ From use cases to class diagrams+ Model and reality + Activities during object modeling Object identification Object types Heuristics Refinement of object models+ Other issuesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 113Reality and Model+ Reality R: Real Things,People, Processes happening during some time, Relationship between things+ Model M: Abstractions from (really existing or only thought of ) things, people , processes and relationships between these abstractions.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 114Why models? + We use models To abstract away from details in the reality, so we can draw complicated conclusionsin the reality with simple steps in the model To get insights into the past or presence To make predictions about the futureModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 115What is agood model?+ Relationships, which are valid in reality R, are also valid in model M. I : Mapping of real things in reality R to abstractions in the model M (Interpretation) fM: relationship between abstractions in M fR: relationship between real things inR+ In a good model the following diagram is commutative: fMfRMMRRIIModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 116Models are falsifiable+ A model is always an approximation We must say according to our knowledge, or with todays knowledge+ We can only build models from reality, which are true until, we have founda counter example (Principle of Falsification) And even then we might stick with the model (because it works quite well in most settings)+ The falsification principle is the basis of software development The goal of prototypes, reviews and system testing is to falsify the software systemModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 117Modelsof models of models...+ Modeling is relative. We can think of a model as reality and can build another model from it (with additional abstractions). fM1fRM1M1RRRequirementsElicitationI1M2M2AnalysisI2fM2.The development of software systems is a Transformation of Models:Analysis, Design,Implementation,TestingModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 118A small discourse into Philosophy+ Philosophy works on 3major problems Metaphysics: What is reality? Epistemology: What is knowledge? How can we store knowledge in our brain? How far can I describe reality with knowledge? Ethics: What is good, what is bad?+ Metaphysics and epistemology depend on each other: Assertions about reality depend on closely on assertions about knowledge and vice versa.+ Relationshipto software engineering Metaphysics Modeling Epistemology Acquisition of knowledge,knowledge management Ethics: Good and bad practices during software developmentModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 119How do we model complex systems (Natural Systems, Social Systems, Articial Systems)?EpistemologyKnowledge about Causality(Dynamic Model)Describes ourknowledge about the system Knowledge about Functionality(Functional model)Knowledge about Relationships(Object model)Neural NetworksDataFlow Diagrams (SA/SD)Scenarios/Use Cases(Jacobsen)Formal Specications(Liskov)State Diagrams(Harel)Petri Nets(Petri)Inheritance Frames,SemanticNetworks (Minsky)Uncertain KnowledgeFuzzy Sets (Zadeh)Data Relationship(E/R Modeling, Chen)HierarchicalDatabaseModel (IMS)NetworkDatabaseModel(CODASYL)RelationalDatabase Model(Codd)Fuzzy Frames(Graham)Class Diagrams(E/R + Inheritance, Rumbaugh)Sequence Diagrams(Lamport)ActivityDiagrams(good old Flow-chartsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 120Outline+ From use cases to class diagrams+ Model and reality + Activities during object modeling Object identification Object types Heuristics Refinement of object models+ Other issuesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 121Activities during Object Modeling+ Main goal: Find the important abstractions+ What happens if we find the wrong abstractions? Iterate and correct the model+ Steps during object modeling 1. Class identification4 Based on the fundamental assumption that we can find abstractions 2. Find the attributes 3. Find the methods 4. Find the associations between classes+ Order of steps Goal: get the desired abstractions Order of steps secondary, only a heuristic Iteration is importantModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 122Class identification is an ancient problem+ Objects are not just found by taking a picture of a scene or domain+ The application domain has to be analyzed. + Depending on the purpose of the system different objects might be found How can we identify the purpose of a system? Scenarios and use cases+ Another important problem: Define system boundary. What object is inside, what object is outside?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 123Pieces of an Object Model+ Classes+ Associations (Relations) Generic associations Canonical associations4 Part of- Hierarchy (Aggregation)4 Kind of-Hierarchy (Generalization)+ Attributes Detection of attributes Application specific Attributes in one system can be classes in another system Turning attributes to classes+ Operations Detection of operations Generic operations: Get/Set, General world knowledge, design patterns Domain operations: Dynamic model, Functional modelModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 124Object vs. Class+ Object (instance): Exactly one thing+ A class describes a group of objects with similar properties Game,Tournament, mechanic, car, database+ Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata... Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examplesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 125Class identification+ Finding objects is the central piece in object modeling+ Approaches Application domain approach:4 Ask application domain expert to identify relevant abstractions Syntactic approach (today):4 Start with use cases. Extract participating objects from flow of events4 Usenoun-verb analysis (Abbots technique) to identify components of the object model Design patterns approach (Lecture on design patterns)4 Use reusable design patterns Component-based approach (Lecture on object design):4 Identify existing solution classesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 126How do you find classes?+ Finding objects is the central piece in object modeling Learn about problem domain: Observe your client Apply general world knowledge and intuition Take the flow of events and find participating objects in use cases Try to establish a taxonomy Apply design knowledge:4 Distinguish different types of objects4 Apply design patterns (Lecture on design patterns) Do a syntactic analysis of problem statement,scenarioor flow of events Abbott Textual Analysis, 1983, also called noun-verb analysis4 Nouns are good candidates for classes 4 Verbs are good candidates for opeationsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 127Finding Participating Objects in Use Cases+ Pick a use case and look at its flow of events Find terms that developers or users need to clarify in order to understand the flow of events Look for recurring nouns (e.g., Incident), Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource), Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan), Identify data sources or sinks (e.g., Printer) Identify interface artifacts (e.g., PoliceStation)+ Be prepared that some objects are still missing and need to be found: 4 Model the flow of events with a sequence diagram+ Always use the users termsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 128Object Types+ Entity Objects Represent the persistent information tracked by the system (Application domain objects, Business objects)+ Boundary Objects Represent the interaction between the user and the system+ Control Objects: Represent the control tasks performed by the system+ Having three types of objects leads to models that are more resilient to change. The interface of a system changes more likely than the control The control of the system change more likely than the application domain+ Object types originated in Smalltalk: Model, View, Controller (MVC)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 129Example: 2BWatch ObjectsYearMonthDayChangeDateButtonLCDDisplayEntity ObjectsControl Objects Interface ObjectsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 130Naming of Object Types in UML+ UML provides several mechanisms to extend the language+ UML provides the stereotype mechanism to present new modeling elements

Year

Month

Day

ChangeDate

Button

LCDDisplayEntity ObjectsControl Objects Boundary ObjectsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 131Recommended Naming Convention for Object Types+ To distinguish the different object tpyes on a syntactical basis, we recommend suffixes:+ Objects ending with the _Boundary suffix are boundary objects + Objects ending with the _Control suffix are control objects+ Entity objects do not have any suffix appended to their name.YearMonthDayChangeDate_ControlButton_BoundaryLCDDisplay_BoundaryModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 132Identifying Entity Objects+ Entity objects Persistent information tracked by system+ Heuristics Terms that developers or users need to clarify in order to understand the use case Recurring nouns in the use case Real-world entities that the system needs to track Real-world activities that the system needs to track Data sources or sinksModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 133Identifying Boundary Objects+ Boundary objects Interactions between actors and system+ Heuristics Identify user interface controls that the user needs to initiate the use case Identify forms the user needs to enter data into the system Identify notices and messages the system needs to respond to the user Identify actor terminals to refer to the user interface under consideration Do not model the visual aspects of the user interface Use end users termsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 134Identifying Control Objects+ Control objects Realize use cases, encapsulates the behavior of the use case Usually not persistent, exists in the lifetime of the use case Helps clarify the entry and exit conditions of the use case+ Heuristics Identify one control object per use case Identify one control object per actor in the use caseModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 135Example: Flow of events+ The customer enters a store with the intention of buying a toy for his child with the age of n.+ Help must beavailable within less than one minute. + The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. + The customer selects a dangerous toy which is kind of unsuitable for the child.+ The store owner recommends a safer doll. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 136Mapping parts of speech to object model components [Abbott, 1983]Part of speech Model component ExampleProper noun object Jim SmithImproper noun class Toy, dollDoing verb method Buy, recommendbeing verb inheritanceis-a (kind-of)having verb aggregation has anmodal verb constraint must beadjective attribute 3 years oldtransitive verb method enterintransitive verb method (event) depends onModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 138Grammatical construct UML ComponentConcrete Person, Thing Objectnoun classverb OperationClassifying verb InheritancePossessive Verb Aggregationmodal Verb ConstraintAdjective AttributeIntransitive verb Operation (Event)Textual Analysis using Abbots techniqueExampleMonopolytoyentersis a ,either...or, kind ofHas a, consists ofmust be, less than3 years olddepends on.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 139Generation of a class diagram from flow of events+ The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it.An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buys the game and leaves the storetype of toycustomerdepends store entersCustomer?enter()toydaughtersuitable*less than 50 Eurostoreenter()daughteragetoybuy()videogameboardgametoyagevideogamedaughterboardgameFlow of events:toypricebuy()like()buyModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 140Order of activities in modeling1. Formulate a few scenarios with help from the end user and/or application domain expert.2. Extract the use casesfrom the scenarios, with the help ofapplication domain expert.3. Analyze the flow of events, for example with Abbot's textual analysis.4. Generate the class diagrams, which includes the following steps:1. Class identification (textual analysis, domain experts). 2. Identification of attributes and operations (sometimes before the classes are found!)3. Identification of associations between classes4. Identification of multiplicities5. Identification of roles6. Identification of constraintsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 141Identifying Associations+ Association A relationship between two or more classes+ Properties Name describes what the relationship is all about Role the function of each class in the association Multiplicity number of possible instances+ Heuristics Examine verb phrases Name associations and roles precisely Use qualifiers to identify namespaces and keys Eliminate associations that can be derived from other associations Worry about multiplicity later Minimize the number of associationsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 142Qualifiers+ Qualifiers can be used to reduce the multiplicity of an association.DirectoryFilefilenameWithout qualification1 *With qualificationDirectory File011filenameModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 143Identifying Aggregates+ Aggregate An association denoting whole-part relationship+ Composition aggregate Whole and parts cannot exist without each other Denotes is-part-of relationship+ Shared aggregate Whole and parts can exist independently Denotes belongs-to relationship+ Heuristics 1-to-many relationships could potentially be whole-part relationshipsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 144Aggregation+ An aggregation is a special case of association denoting a consists of hierarchy.+ The aggregate is the parent class, the components are the children class.+ A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate. (Bill of Material)TicketMachineZoneButton3Exhaust systemMufflerdiameterTailpipediameter10..2Exhaust systemMufflerdiameterTailpipediameter10..2Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 145Identifying Attributes+ Attributes Properties of individual objects+ Properties Name Type+ Heuristics Examine possessive phrases Represent stored state as an attribute Describe each attributeModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 146Modeling Inheritance Relationships+ Generalization Identification of abstract concepts from lower-level ones+ Specialization Identification of more specific concepts from a high-level one+ Heuristics Look for classes that share similarities Look for groups of classes that appear to be a taxonomyModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 147Outline+ From use cases to class diagrams+ Model and reality + Activities during object modeling Object identification Object types Heuristics Refinement of object models+ Other issues Improving the readability of class diagrams Managing object modeling Analysis and solution object modelsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 148Avoid RavioliModelsCustomerNameCustomerIdAccountAmountDeposit()Withdraw()GetBalance()CustomerIdAccountIdAccountIdBankNameHas**SavingsAccountWithdraw()CheckingAccountWithdraw()MortgageAccountWithdraw()Dont put too many classes into the same package:7+-2 (or even 5+-2)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 149Put Taxonomies on a separateDiagramSavingsAccountWithdraw()CheckingAccountWithdraw()MortgageAccountWithdraw()AccountAmountDeposit()Withdraw()GetBalance()CustomerIdAccountIdAccountIdModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 150Project Management Heuristics+ Explicitly schedule meetings for object identification + First just find objects+ Then try to differentiate them between entity, interface and control objects+ Find associations and their multiplicity Unusual multiplicities usually lead to new objects or categories+ Identify Inheritance: Look for a Taxonomy, Categorize+ Identify Aggregation+ Allow time for brainstorming , Iterate, iterateModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 151Who uses class diagrams?+ Purpose of Class diagrams : The description of the static properties of a system (main purpose)+ Who uses class diagrams?+ The customer and the end user are often not interested in class diagrams. They usually focus more on the functionality of the system. + The application domain expert uses class diagrams to model the application domain+ The developer uses class diagramsduring the development of a system, that is, during analysis, system design, object design and implementation.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 152Class-diagrams have different types of users+ According to the development activity, the developer plays different roles. Analyst System-Designer, Detailed-Designer Implementor.+ In small systems some of the roles do not exist or are played by the same person. + Each of these roles has a different view about the models.+ Before I describe these different views, I want to distinguish the types of classes that appear in class diagrams. Application domain classes Solution domain classesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 153Application domain vs. solution domain+ Application domain: The problem domain (financial services, meteorology, accident management, architecture, ).+ Application domain class: An abstraction in the application domain. If we model business applications, these classes are alsocalled business objects. Example: Board game, Tournament+ Solution domain: Domains that help in the solution ofproblems (telecommunication, data bases, compiler construction, operating systems, .)+ Solution domain class: An abstraction, that is introduced for technical reasons, because it helps in the solution of a problem. Examples:Tree,Hashtable, SchedulerModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 154The Role of the Analyst+ The analyst is interested in application classes: The associations between classes are relationships between abstractions in the application domain. whether the use of inheritance in the model reflect the taxonomies in the application domain. 4 Definition Taxonomy:A hierarchy of abstractions+ The analyst is not interested in the exact signature of operations. in solution classes.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 155Designer+ The designer focuses on the solution of the problem, that is the solution domain. + Design consists ofmany tasks (subsystem decomposition, selection of the hardware platform, data management system, etc.). + An important design problem is the specification ofinterfaces: The designer describes the interface ofclasses (object design) and subsystems (system design). The goal of the designer is usability and reusability of interface4 Design-Usability: the interfaces are usable from as many classes as possible within in the system.4 Design-Reusability: Definition ofinterfaces, such that they can also be used in other (future) software systems. => Class libraries.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 156Three Types of Implementors+ Class implementor: Implements the class. The implementor chooses appropriate data structures (for the attributes) and algorithms (for the operations),and realizes the interface of the class in a programming language.+ Class extender: Extends the class by a subclass, which is needed for a new problem or a new application domain. + Class-user (client): The programmer, who wants to use an existing class (e.g. a class from a class library or a class from another subsystem). The class user is only interested in the Signatures of the class operations and the preconditions,under which they can be invoked. The class user is not so much interested in the implementation of the class. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 157Why do we distinguish these different users of class diagrams?+ Models often dont distinguish between application classes (address book) andsolution class (array, tree). Reason: Modeling languages like UMLallow the use of both types of classes in the same model. Preferred : No solution classes in theanalysis model. + Depending on our role,we look at objects and models from a different perspective. Often we are only interested in limited aspects of a model.+ Depending on our role and the model we have different interpretations for different UML constructs: Different interpretations of associations Different interpretations of attributes Different interpretation of inheritance+ Lets take a look at these different interpretations.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 158Analysis model+ The Analysis modelis constructed during the analysis phase. Main stake holders: End user, Customer, Analyst. The diagram contains only application domain classes.+ The analysis model is the base for communication between analysts, experts in the application domain and end users of the system. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 159Object designmodel+ The object design model (sometimes also called specification model) is created during the object design phase Main stake holdersare classspecifiers, class implementorsandclass users The class diagrams contain applicationand solution domain classes.+ The object design model is the basis ofcommunication between designers and implementors. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 160Summary+ Modeling vs. reality+ System modeling Object model Dynamic model Functional model+ Object modeling is the central activity Class identification is a major activity of object modeling There are some easy syntactic rules to find classes/objects+ Different roles during software developmentUsing UML, Patterns, and JavaObject-Oriented Software EngineeringRequirements Analysis(Part 2 Dynamic Modeling)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 163Outline of the Lecture+ Dynamic modeling Sequence diagrams State diagrams+ Using dynamic modeling for the design of user interfaces+ Analysis example+ Requirements analysis document template+ Requirements analysis model validationModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 164Analysis Activities+ Identifying entity objects+ Identifying boundary objects+ Identifying control objects+ Mapping use cases to objects with sequence diagrams+ Modeling interactions among objects with CRC cards+ Identifying associations+ Identifying aggregates+ Identifying attributes+ Modeling state-dependent behavior of individual objects+ Modeling inheritance relationships between objects+ Reviewing the analysis modelObject ModelingDynamic ModelingModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 165Dynamic Modeling with UML+ Diagrams for dynamic modeling Interaction diagrams describe the dynamic behavior between objects Statecharts describe the dynamic behavior of a single object+ Interaction diagrams Sequence Diagram: 4 Dynamic behavior of a set of objects arranged in time sequence. 4 Good for real-time specifications and complex scenarios Collaboration Diagram : 4 Shows the relationship among objects. Does not show time+ State Chart Diagram: A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events). Activity Diagram: A specialtype of statechart diagram, where all states are action states (Moore Automaton)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 166Dynamic Modeling+ Definition of dynamic model: A collection of multiple state chartdiagrams, one statechart diagram for each classwith important dynamic behavior.+ Purpose: Detect and supply methods for the object model+ How do we do this? Start with use case or scenario Model interaction between objects => sequence diagram Model dynamic behavior of a single object => statechart diagramModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 167What is an Event?+ Something that happens at a point in time+ Relation of events to each other: Causally related: Before, after, Causally unrelated: concurrent+ An event sends information from one object to another + Events can be grouped in event classes with a hierarchical structure. Event is often used in two ways: Instance of an event class: Bob calls Janet. 4 Event classNew call,Subclass Pick up receiver Attribute of an event class4 Call(Bob, Janet)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 168Sequence Diagram+ From the flow of events in the use case or scenario proceed to the sequence diagram + A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (direct acyclic graph) notation+ Relation to object identification: Objects/classes have already beenidentified during object modeling Objects areidentified as a result of dynamic modeling+ Heuristic: A event always has a sender and a receiver. The representation of the event is sometimes called a message Find them for each event => These are the objects participating in the use caseModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 169Start with Flow of Events from Use Case+ Flow of events from Diala Number Use case: Callerlifts receiver Dial tone begins Caller dials Phone rings Callee answers phone Ringing stops ....+ Actors: caller, callee+ Objects: Caller phone, callee phone, network Phone: aggregate of receiver, keypad, ringer, line Network: aggregate of switches, trunks, signaling linksModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 170Heuristics for Sequence Diagrams+ Layout: 1st column: Should correspond to the actor who initiated the use case 2nd column: Should be a boundary object 3rd column: Should be the control object that manages the rest of the use case+ Creation: Control objects are created at the initiation of a use case Boundary objects are created by control objects+ Access: Entity objects are accessed by control and boundary objects, Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects.+ Use CRC cards as first step in defining complex sequence diagramsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 171CRC Cards + CRC class, responsibilities, collaborators Class name of class Responsibilities operations the class is responsible for Collaborators other classes it is associated with+ CRC cards can be used to clarify the scope of a class+ Useful during brainstorming sessions Take vertical slice through a scenario Identify all classes, write each one on a card While examining flow of events, fill in the responsibilities of each class Collaborators are added as dependencies between classes are identified.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 172What else can we get out of sequence diagrams?+ Sequence diagrams are derived from the use cases.We therefore see the structure of the use cases. + The structure of the sequence diagram helps us to determine how decentralized the system is.+ We distinguish two structures for sequence diagrams: Fork and Stair Diagrams (Ivar Jacobsen)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 173Fork Diagram+ Much of the dynamic behavior is placed in a single object, usually the control object. It knows all the other objects and often uses them for direct questions and commands. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 174Stair Diagram+ The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can help with a specific behavior. Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 175Fork or Stair?+ Which of these diagram types should be chosen?+ Object-oriented fans claim that the stair structureis better The more the responsibilityis spread out, the better+ However, this is not always true. Better heuristics:+ Decentralized control structure The operations have a strong connection The operations will always be performed in the same order+ Centralized control structure(better support of change) The operations can change order New operations can be inserted as a result of new requirementsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 176UML Statechart Diagram NotationState2State1Event1(attr) [condition]/actionentry /actionexit/action+ Notation based on work by Harel Added are afew object-oriented modifications+ A UML statechart diagram can be mapped into a finite state machinedo/ActivityAlso: internal transition and deferred eventsEvent triggerWith parametersGuardconditionModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 177Statechart Diagrams+ Graph whose nodes are states and whose directed arcs are transitions labeled by event names.+ We distinguish between two types of operations in statecharts: Activity: Operation that takes time to complete4 associated with states Action: Instantaneous operation 4 associated with events4 associated with states (reduces drawing complexity): Entry, Exit, Internal Action+ A statechart diagram relates events and states for one class Anobject model with a set of objectshasa set of state diagramsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 178State+ An abstraction of the attributes of a class State is the aggregation of several attributes a class+ Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned Example: State of a bank4 A bank is either solvent or insolvent+ State has durationModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 179Nested State Diagram+ Activities in states are composite items denoting other lower-level state diagrams+ A lower-level state diagram corresponds to a sequence of lower-level states and events that are invisible in the higher-level diagram.+ Sets of substates in a nested state diagram denote a superstateare enclosed by a large rounded box, also called contour.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 180Superstates+ Goal:Avoid spaghetti models Reduce the number of lines in a state diagram+ Transitions from other states to the superstate enter the first substate of the superstate.+ Transitions to other states from a superstate are inherited by all the substates (state inheritance)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 181Statechart with superstateModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 182Modeling ConcurrencyTwotypes of concurrency1. System concurrency State of overall system as the aggregation of state diagrams, one for each object. Each state diagram is executing concurrently with the others.2. Object concurrency An object can be partitioned into subsets ofstates (attributes and links) such that each of them has its own subdiagram. The state of the object consists of a set of states: one state from each subdiagram. State diagrams are divided into subdiagrams by dotted lines.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 183Example of Concurrency within an ObjectEmitting Setting ReadyUpto resetDo: DispenseCashDo: EjectCardReadyCash takenCard takenSynchronizationSplitting controlModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 184State Chart Diagram vs Sequence Diagram+ State chart diagrams help to identify:Changes to an individual object over time+ Sequence diagrams help to identifyThe temporal relationship of between objects over timeSequence of operations as a response to one or more eventsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 185Dynamic Modeling of User Interfaces+ Statechart diagrams can be used for the design of user interfaces Also called Navigation Path+ States: Name of screens Graphical layout of the screens associated with the states helps when presenting the dynamic model of a user interface + Activities/actions are shown as bullets under screen name Often only the exit action is shown+ State transitions: Result ofexit action Button click Menu selection Cursor movements+ Good for web-based user interface designModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 186Navigation Path ExampleDiagnostics MenuUser moves cursor to Control Panel or GraphGraph User selects data group and type of graphSelection User selects data group Field site Car Sensor group Time range User selects type of graph time line histogram pie chartVisualize User views graph User can add data groups for being viewedLink User makes a link (doclink)Control panel User selects functionality of sensorsDisable User can disable a sensor event from a list of sensor eventsDefine User defines a sensor eventfrom a list of eventsEnable User can enable a sensor event from a list of sensor eventsList of sensor events User selects sensor event(s)List of events User selects event(s)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 187State diagram, single-page platformFindRooms, Repair, Add ...FindGuest, FindStay ...AddServiceDelService ...FindRoomsBook, CheckinPrintConfirm, CheckoutAddServiceLine ...BookCheckinFindRooms. . .vwServiceList vwBreakfastvwRoomsvwStay(new) vwRoomsvwFindGuestvwRoomsvwStay(rec)pSearchpStay(new)pStay(rec)pBreakfastpServiceListFrom S. Lauesen, User Interface Design: A Software Engineering Perspective, Chapter 7Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 188vwServiceListState diagram, multi-page platformFindGuest, FindStayNewStay, OpenStay ...NewStayOpenStayBook, CheckinPrintConfirmCheckoutAddService ...BookCheckinDeleteStayvwFindGuestvwRoomsFindRooms, RepairBook, CheckinvwStay(new)vwStay(rec)vwBreakfastAddServiceDelService ...OpenBreakfastCloseSCloseSFrom S. Lauesen, User Interface Design: A Software Engineering Perspective, Chapter 7Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 189Practical Tips for Dynamic Modeling+ Construct dynamic models only for classes with significant dynamic behavior Avoid analysis paralysis+ Consider only relevant attributes Use abstraction if necessary+ Look at the granularity of the application when deciding on actions and activities+ Reduce notational clutter Try to put actions into state boxes (look for identical actions on events leading to the same state)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 190+ 1. What are the transformations? Create scenarios anduse case diagrams 4 Talk to client, observe, get historical records, do thought experiments 2. What is the structure of the system?Create class diagramsIdentify objects. What are theassociations between them? What is their multiplicity?What are the attributes of the objects?What operations are defined on the objects?3. What is its behavior? Createsequence diagramsIdentify senders and receiversShow sequence of events exchanged between objects.Identify event dependencies and event concurrency.Createstate diagrams Only for the dynamically interesting objects.Summary: Requirements AnalysisDynamic ModelingFunctional ModelingObject ModelingModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 191Example+ Flow of events from Diala Number Use case: Callerlifts receiver Dial tone begins Caller dials Phone rings Callee answers phone Ringing stops ....+ Actors: caller, callee+ Objects: Caller phone, callee phone, network Phone: aggregate of receiver, keypad, ringer, line Network: aggregate of switches, trunks, signaling linksModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 192Define Use Case: What is the system boundary?Caller CalleecallCalleroriginateCallNetworkCalleeterminateCallNetwork is part of systemNetwork is not part of system(Exceptions are not shown here)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 193Initial ObjectsNetworkInterfaceoriginateCallControlterminateCallControlReceiver Keypad RingerPhoneModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 194Sequence Diagram for Call Origination: Caller : CallercallerPhone : PhonecallerPhone : PhoneliftReceiver()listenDialtone()dialDigit()dialDigit()dialDigit()dialDigit(): originateCallControl: originateCallControlcreate()playDialtone()analyzeDigit()analyzeDigit()analyzeDigit()analyzeDigit(): CallRecord : CallRecordcreate()setupCall(): NetworkInterface: NetworkInterface: Network : NetworksendSetupMessage()originatingOffice : SwitchDBoriginatingOffice : SwitchDBcheckAvailableLine()line(lineno)Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 195Updated List of ObjectsNetworkInterfaceoriginateCallControlterminateCallControlReceiver Keypad RingerPhoneSwitchDBCallRecordModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 196State Chart for originateCallControl ObjectAvailableLineDialtoneCollectDigitsRingingLineIsAvailabledialDigitterminatingLineIdleTalkinghangUpcalleeAnswerdialDigitBusyterminatingLineBusyNoDialtoneLineNotAvailableModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 197When is a model dominant?+ Model dominance: One model having significantly higher importance than the rest+ Object model: The system has objects with nontrivial state.+ Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc.+ Functional model: The model performs complicated transformations (e.g. computations consisting of many steps).+ Which of these models isdominant in the following three cases? Compiler Database system Spreadsheet programModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 198Dominance of models+ Compiler: The functional model most important. (Why?) The dynamic model is trivial because there is only one type input and only a few outputs.+ Database systems: The object model most important. The functional model is trivial, because the purpose of the functions is usually to store, organize and retrieve data.+ Spreadsheet program: The functional model most important. The dynamic model is interesting if the program allows computations on a cell. The object model is trivial, because the spreadsheet values are trivial and cannot be structured further. The only interesting object isthe cell.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 202Requirements Analysis Document Template1. Introduction2. Current system3. Proposed system3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (Pseudo requirements)3.5 System models3.5.1Scenarios3.5.2Use case model3.5.3Object model3.5.3.1 Data dictionary3.5.3.2 Class diagrams3.5.4Dynamic models3.5.5User interface4. GlossaryModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 203Section 3.5 System Model3.5.1 Scenarios- As-is scenarios, visionary scenarios3.5.2 Use case model- Actors and use cases3.5.3 Object model - Data dictionary- Class diagrams (classes, associations, attributes and operations)3.5.4 Dynamic model- State diagrams for classes with significant dynamic behavior- Sequence diagrams for collaborating objects (protocol)3.5.5 User Interface- Navigational Paths, Screen mockupsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 204Section 3.3 Nonfunctional Requirements3.3.1User interface and human factors3.3.2Documentation3.3.3Hardware considerations3.3.4Performance characteristics3.3.5Error handling and extreme conditions3.3.6System interfacing3.3.7Quality issues3.3.8System modifications3.3.9Physical environment3.3.10 Security issues3.3.11 Resources and management issuesModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 205Nonfunctional Requirements: Trigger Questions3.3.1 User interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available, and what are their characteristics?3.3.2 Documentation What kind of documentation is required? What audience is to be addressed by each document?3.3.3 Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 206Nonfunctional Requirements, ctd3.3.4 Performance characteristics Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system?3.3.5 Error handling and extreme conditions How should the system respond to input errors? How should the system respond to extreme conditions?3.3.6 System interfacing Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 207Nonfunctional Requirements, ctd+ 3.3.7 Quality issues What are the requirements for reliability? Must the system trap faults? What is the maximum time for restarting the system after a failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to different hardware or operating system environments)?+ 3.3.8 System Modifications What parts of the system are likely candidates for later modification? What sorts of modifications are expected?+ 3.3.9 Physical Environment Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields, ...)?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 208Nonfunctional Requirements, ctd+ 3.3.10 Security Issues Must access to any data or the system itself be controlled? Is physical security an issue?+ 3.3.11 Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 209Constraints (Pseudo Requirements)+ Constraint: Any client restriction on the solution domain+ Examples: The target platform must be an IBM/360 The implementation language must be COBOL The documentation standard X must be used A dataglove must be used ActiveX must be used The system must interface to a papertape readerModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 210Outline of the Lecture Dynamic modelingSequence diagramsState diagrams Using dynamic modeling for the design of user interfaces Analysis example Requirements analysis document templateC Requirements analysis model validationModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 212Requirements Validation+ Verification is an equivalence check between the transformation of two models: We have two models, is the transformation between them correct?+ Validation is different. We dont have two models, we need to compare one model with reality Reality can also be an artificial system, like an legacy system+ Validation is a critical step in the development process Requirements should be validated with the client and the user. Techniques: Formal and informal reviews (Meetings, requirements review)+ Requirements validation involves the following checks Correctness Completeness Ambiguity RealismModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 213Modeling Checklist for the Review+ Is the model correct? A model is correct if it represents the clients view of the the system: Everything is the model represents an aspect of reality + Is the model complete? Every scenario through the system, including exceptions, is described. + Is the model consistent? The model does not have components that contradict themselves (for example, deliver contradicting results)+ Is the model unambiguous? The model describes one system (one reality), not many+ Is the model realistic? The model can be implemented without problemsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 214Diagram Checklist for the RAD+ One problem with modeling: We describe a system model with many different views (class diagram, use cases, sequence diagrams, )state charts)+ We need to check the equivalence of these views as well + Syntactical check of the models Check for consistent naming of classes, attributes, methods in different subsystems Identify dangling associations (associations pointing to nowhere) Identify double- defined classes Identify missing classes (mentioned in one model but not defined anywhere) Check for classes with the same name but different meanings+ Dont rely on CASEtools for these checks Many of the existing tools dont do all these checks for you.+ Examples for syntactical problems with UML diagramsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 215Project Agreement+ The project agreementrepresents the acceptance of (parts of) the analysis model (as documented by the requirements analysis document) by the client. + The client and the developers converge on a single idea and agree about the functions and features that the system will have. In addition, they agree on: a list of prioritized requirements a revision process a list of criteria that will be used to accept or reject the system a schedule, and a budgetModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 216Prioritizing requirements+ High priority (Core requirements) Must be addressed during analysis, design, and implementation. A high-priority feature must be demonstrated successfully during client acceptance.+ Medium priority (Optional requirements) Must be addressed during analysis and design. Usually implemented and demonstrated in the second iteration of the system development.+ Low priority (Fancy requirements) Must be addressed during analysis (very visionary scenarios). Illustrates how the system is going to be used in the future if not yet available technology enablers are availableModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 217SummaryIn this lecture, we reviewed the construction of the dynamic model from use case and object models. In particular, we described: In particular, we described:+ Sequence and statechart diagrams for identifying new classes and operations.In addition, we described the requirements analysis document and its componentsUsing UML, Patterns, and JavaObject-Oriented Software EngineeringSystem DesignChapters 6-7Object-Oriented Software Engineering:Using UML, Patterns, and Java, 2ndEditionBy B. Bruegge and A. Dutoit Prentice Hall, 2004.Modified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 219Overview+ System Design1. Identifying Design Goals2. Mapping Objects to Subsystems3. Hardware/Software Mapping4. Persistent Data Management5. Global Resource Handling and Access Control6. Software Control and Concurrency7. Boundary Conditions+ Practical MattersModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 220System Design+ Tells the customer what the system will do Where will the data come from? What will happen to the data in the system? What will the system look like to users? What choices will be offered to users? What is the timing of events? What will the reports and screens look like?+ Tells the programmers what the system will do major hardware components and their function hierarchy and functions of software components data structures data flowModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 221How to use the results from the Requirements Analysis for System Design+ Nonfunctional requirements => Activity 1: Design Goals Definition+ Functional model => Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling)+ Object model => Activity 4: Hardware/software mapping Activity 5: Persistent data management+ Dynamic model => Activity 3: Concurrency Activity 6: Global resource handling Activity 7: Software control+ Subsystem Decomposition Activity 8: Boundary conditionsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 222Identifying Design Goals+ Prioritize criteria Performance4 Response time, throughput, memory Dependability4 Robustness, reliability, availability, fault tolerance, security, safety Cost4 Cost of development, deployment, upgrading, maintenance, administration Maintenance4 Extensibility, modifiability, adaptability, portability, readability, traceability of requirements End user4 Utility, usability+ Tradeoffs are decided at this pointModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 223Typical Design Trade-offs+ Functionality vs. Usability+ Cost vs. Robustness+ Efficiency vs. Portability+ Rapid development vs. Functionality+ Cost vs. Reusability+ Backward Compatibility vs. ReadabilityModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 224Overview+ System Design1. Identifying Design Goals2. Subsystem Decomposition3. Hardware/Software Mapping4. Persistent Data Management5. Global Resource Handling and Access Control6. Software Control and Concurrency7. Boundary Conditions+ Practical MattersModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 225Subsystems and Services+ Subsystem (UML: Package) Collection of classes, associations, operations, events and constraints that are interrelated Seed for subsystems: UML Objects and Classes. + (Subsystem) Service: Group of operationsprovided by the subsystem Seed for services: Subsystem use cases+ Service is specified by Subsystem interface: Specifies interaction and information flow from/to subsystem boundaries, but not inside the subsystem. Should be well-defined and small. Often called API: Application programmers interface, but this term should used during implementation,not during System DesignModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 226Software Architecture+ The software architecture explains how the decomposed subsystems are organized.+ Software architecture Defines the system in terms of subsystems and interactions among those subsystems Shows correspondence between requirements and elements of the constructed system Addresses system-level non-functional requirementsModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 227Software Architectural Styles+ Subsystem decomposition Identification of subsystems, services, and their relationship to each other.+ Specification of the system decomposition is critical.+ Patterns for software architecture Repository Client/Server Peer-To-Peer Model/View/Controller Pipes and Filters LayeredModified from originals by Bernd Bruegge & Allen H. DutoitObject-Oriented Software Engineering: Using UML, Patterns, and Java 228Repository Architectural Style+ Subsystems access and modify data from a single data structure+ Subsystems are loosely coupled (interact only through the repository)+ Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchron