info 620lecture #61 information systems analysis and design more class modeling; patterns info 620...
TRANSCRIPT
![Page 1: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/1.jpg)
INFO 620 Lecture #6 1
Information Systems Analysis and Design
More Class Modeling; Patterns
INFO 620
Glenn Booker
![Page 2: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/2.jpg)
INFO 620 Lecture #6 2
Object Design
• The rough steps followed so far include:– Define requirements and model with use cases– Create domain model (conceptual class diag.)
• Now to design objects we need to:– Add methods to the classes and define
messaging between objects to fulfill the requirements
– But that last step isn’t trivial!
![Page 3: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/3.jpg)
INFO 620 Lecture #6 3
GRASP Patterns
• GRASP patterns help define normal ways that objects interact with each other– GRASP is Larman’s term; “General
Responsibility Assignment Software Patterns”– We’ll cover five of the patterns in the text– For all 23 standard patterns, see Erich Gamma’s
classic Design Patterns (ISBN 0201633612 or 0201634988)
![Page 4: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/4.jpg)
INFO 620 Lecture #6 4
Responsibilities
• The responsibilities for an object describe what behavior it needs to fulfill
• Doing– Create an object– Perform a calculation– Start action in another object– Control activities in other objects– “Sale is responsible for creating SalesLineItem”
![Page 5: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/5.jpg)
INFO 620 Lecture #6 5
Responsibilities
• Knowing– About private encapsulated data– About related objects– About things it can calculate or derive– “Sale is responsible for knowing its total”– Most ‘knowing’ responsibilities are apparent
from the attributes and associations of the object
![Page 6: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/6.jpg)
INFO 620 Lecture #6 6
Responsibilities
• Translating responsibilities into classes and methods depends on how detailed or general the responsibilities are
• Methods are often implemented to fulfill responsibilities
![Page 7: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/7.jpg)
INFO 620 Lecture #6 7
Getters and Setters
• Detailed object methods often include a lot of getters and setters– Getters ‘get’ some value for the outside world,
e.g. getTotal (a ‘knowing’ responsibility)– Setters ‘set’ some value – like assignment
statements, e.g. setSecurityLevel (a ‘doing’ responsibility)
![Page 8: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/8.jpg)
INFO 620 Lecture #6 8
Responsibilities, Methods related
:Sale
:Payment
makePayment()
create()
From Fig. 16.1, p. 217
makePayment implies Sale objects are responsible for creating Payments
Note Payment shifted down to show its creation
![Page 9: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/9.jpg)
INFO 620 Lecture #6 9
Defining Patterns
• Patterns capture well established “best practices” for design
• Some are very low level; others are architectural
• Each Pattern is defined by its Name, a summary of the Pattern’s Solution, and a description of the Problem it solves
![Page 10: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/10.jpg)
INFO 620 Lecture #6 10
Defining Patterns
• Patterns are not always the best solution
• Good pattern descriptions include when the pattern may not apply, or the pros and cons of the pattern
![Page 11: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/11.jpg)
INFO 620 Lecture #6 11
The First Five GRASP Patterns
• Information Expert
• Creator
• High Cohesion
• Low Coupling
• Controller
![Page 12: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/12.jpg)
INFO 620 Lecture #6 12
Information Expert
• Problem: what is the general principle of assigning responsibilities to objects?
• Solution: assign responsibility to the Information Expert – the class which has the information needed to fulfill the responsibilityor Whoever has the data is responsible for managing and sharing it!
![Page 13: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/13.jpg)
INFO 620 Lecture #6 13
Information Expert
• The domain model should inspire expansion into design classes which will handle all of the data and use it to meet requirements
• A key step is that we have to make up the classes we think we’ll need, based on the system characteristics, and see if they can work correctly
![Page 14: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/14.jpg)
INFO 620 Lecture #6 14
Information Expert
• So if we have a class called Sale (like Shipment in the homework assignments), one responsibility might be to provide the total cost of the Sale
• We know from a typical invoice that a Sale might consists of a bunch of line items, so we might call their class SalesLineItem
![Page 15: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/15.jpg)
INFO 620 Lecture #6 15
Information Expert
• Each SalesLineItem may have a quantity
• And each SalesLineItem needs someplace safe to store its description and price, so we’ll put that in a ProductSpecification
• After defining the associations and multiplicity, we get Figure 16.3 (p. 222), shown on the next slide
![Page 16: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/16.jpg)
INFO 620 Lecture #6 16
Information Expert
-date-time
Sale
-description-price-itemID
ProductSpecification
-quantity
SalesLineItem
1
1..*
Contains
* 1
Described-by
![Page 17: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/17.jpg)
INFO 620 Lecture #6 17
Information Expert
• So at the highest level, we need to get the total cost from Sale
But in order to get that, we need the subtotal of each line item – so get that from the information expert for each line item
:Sale
getTotal()
![Page 18: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/18.jpg)
INFO 620 Lecture #6 18
Information Expert
• So each SalesLineItem can get the subtotal of that line; and the Sale will get those subtotals
But each line item needs the price of each item; get from ProductDescription
:Sale
getTotal()
:SalesLineItem
getSubtotal()
![Page 19: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/19.jpg)
INFO 620 Lecture #6 19
Information Expert
• Omitting variable assignments we have:
Where each object is responsible for providing the data it owns
:Sale
getTotal()
:SalesLineItem
getSubtotal()
:ProductDescription
getPrice()
![Page 20: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/20.jpg)
INFO 620 Lecture #6 20
Information Expert
• The class diagram becomes:
+getTotal()
-date-time
Sale
+getPrice()
-description-price-itemID
ProductSpecification
+getSubtotal()
-quantity
SalesLineItem
1
1..*
Contains
* 1
Described-by
![Page 21: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/21.jpg)
INFO 620 Lecture #6 21
Information Expert
• Information Expert is used very frequently in object design
• May not be suitable when coupling or cohesion dictate otherwise (see later)
![Page 22: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/22.jpg)
INFO 620 Lecture #6 22
Creator
• Problem: Who is responsible for creating a new instance of a class?
• Solution: Let B create instances of A if:– B aggregates (is made up of) A– B contains (holds) A objects– B records instance of A objects– B closely uses A objects– B has data needed when A is created
![Page 23: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/23.jpg)
INFO 620 Lecture #6 23
Creator
• Creation of objects is also a very common activity
• In the previous example, Sale aggregates (contains) many SalesLineItem objects (one object per line in the Sale), hence is makes sense for Sale to be a Creator of SalesLineItem instances
![Page 24: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/24.jpg)
INFO 620 Lecture #6 24
Creator
• Hence a responsibility of the system is that a Sale needs a method to makeLineItem
• If you want add X (quantity) widgets to a shopping cart, then Sale adds them to the cart
![Page 25: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/25.jpg)
INFO 620 Lecture #6 25
Creator
• The sequence diagram would be:
:Register :Sale
:SalesLineItem
makeLineItem()
create()
Fig. 16.8, p. 227
![Page 26: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/26.jpg)
INFO 620 Lecture #6 26
Creator
• If the creation of an object is very complex, then the Factory pattern would be better (see Ch. 23)
![Page 27: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/27.jpg)
INFO 620 Lecture #6 27
Low Coupling
• Problem: How can we support low dependency among classes, low impact of changes, and increase reuse of classes?
• Solution: Assign responsibilities so that coupling remains low
• Coupling describes the extent of interconnection among classes
![Page 28: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/28.jpg)
INFO 620 Lecture #6 28
Low Coupling
• Notice that some coupling is needed – otherwise the classes don’t interact
• Too much coupling means that changes to one class might have unexpected changes elsewhere
• Related to “visibility” – how many other objects does each one need to see?
![Page 29: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/29.jpg)
INFO 620 Lecture #6 29
“Stair” Object Structure
Object1 Object2 Object3 Object4 Object5
Message1()
Message2()
Message3()
Message4()
Message5()
Message6()
Message7()
Message8()
Low coupling (decentralized)Each object sees two other objects at most
![Page 30: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/30.jpg)
INFO 620 Lecture #6 30
“Fork” Object Structure
Object1 Object2 Object3 Object4 Object5
Message1()
Message2()
Message3()
Message4()
Message5()
Message6()
Message7()
Message8()
High coupling (centralized)Object1 must see all other objects
![Page 31: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/31.jpg)
INFO 620 Lecture #6 31
Low Coupling
• The Stair structure is generally preferred where possible
• Might have to use Fork structure if– The sequence of operations may change, and/or– New operations may be needed frequently
• Subclasses are, by definition, high levels of coupling between objects
![Page 32: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/32.jpg)
INFO 620 Lecture #6 32
Low Coupling
• Particularly avoid high coupling for objects which may change interface, implementation, or existence frequently
• Desire for low coupling may conflict with Expert or High Cohesion patterns
• No firm measure of what level of coupling is “good”
![Page 33: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/33.jpg)
INFO 620 Lecture #6 33
High Cohesion
• Problem: how do you keep complexity manageable?
• Solution: Assign responsibilities so that cohesion remains high
• Cohesion is a measure of how closely related an object’s responsibilities are
• High cohesion means a closely related set of narrowly defined responsibilities
![Page 34: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/34.jpg)
INFO 620 Lecture #6 34
High Cohesion
• In other words, don’t make an object do too much work!
• Low cohesion generally results from remaining too abstract when defining responsibilities
• Per Booch, high cohesion is when the elements of a class “all work together to produce some well-bounded behavior”
![Page 35: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/35.jpg)
INFO 620 Lecture #6 35
High Cohesion
• An object which has a kitchen-sink function (it catches all the functions except the kitchen sink) generally has very low cohesion
• A single complex function can result in low cohesion
• Moderate cohesion would have similar, but not closely related, functions together
![Page 36: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/36.jpg)
INFO 620 Lecture #6 36
High Cohesion
• High cohesion classes have some responsibilities in one set of functions, and use other objects to accomplish them
• Modular design is a similar concept as ‘low coupling and high cohesion’
• Conversely, high coupling and low cohesion often appear together
![Page 37: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/37.jpg)
INFO 620 Lecture #6 37
High Cohesion
• Deliberately violating high cohesion is rare
• Might have to do it:– To isolate related functions (rare)– To distribute object to different servers– To manage an external interface
![Page 38: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/38.jpg)
INFO 620 Lecture #6 38
Controller
• Problem: who is responsible for handling external input system events?
• Solution: assign the responsibility to a Controller object– Façade controller represents the entire
subsystem or interface– Session controller handles an entire use case
where some events may occur
![Page 39: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/39.jpg)
INFO 620 Lecture #6 39
Controller
• An ‘input system event’ is some event from an external actor (human or not)
• The Controller object is responsible for deciding what to do with the input system event
![Page 40: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/40.jpg)
INFO 620 Lecture #6 40
Controller
• So the Controller pattern applies to both management of external system interfaces (capture the entire interface in a single controller class), and managing inputs from user interfaces
• User interface controllers generally end with <>Handler, <>Coordinator, or <>Session, where <> = <Use Case Name>
![Page 41: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/41.jpg)
INFO 620 Lecture #6 41
Controller
• Note that user interfaces (e.g. windows, views, or documents) are NOT part of the Controller’s job – those belong to an object at the Interface (or Presentation) Layer
• Controller acts as a façade between interface and the application
• Controllers DELEGATE work to other objects – they don’t do it themselves
![Page 42: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/42.jpg)
INFO 620 Lecture #6 42
BCE Objects
• We can break objects into three major types for many purposes– Boundary objects (user interface window,
buttons, etc.)– Control objects (controllers who make
decisions, here also called ‘use case handlers’)– Entity objects (persistent objects which
contain data)
![Page 43: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/43.jpg)
INFO 620 Lecture #6 43
BCE Objects
• These might be correlated to the kinds of computers involved in processing them– User interface might be at a PC level
(e.g. web browser)– Controller objects might run on an application
server (captures logic, e.g. web server)– Entity objects might run on a database server
(stores data)
![Page 44: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/44.jpg)
INFO 620 Lecture #6 44
Façade Controller
• Façade controllers hide an entire system or subsystem under one class, such as Register or System– Avoid except for simple external systems
• Works well if only a few events to manage; otherwise may need use case controllers to break down system functions into smaller sets (p. 241)
![Page 45: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/45.jpg)
INFO 620 Lecture #6 45
Façade Controller
System
facade externalSystem
Object6
Object7
Object8
Object9
![Page 46: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/46.jpg)
INFO 620 Lecture #6 46
Avoiding Bloated Controllers
• Even a façade controller should generally have more than one class
• Beware of controllers which perform work without calling another class
• Controllers should have few or no attributes
• Fix bloat by adding more controller classes, and/or redesign to delegate more work
![Page 47: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/47.jpg)
INFO 620 Lecture #6 47
Use Case Realization
• Every scenario in a use case can become a ‘use case realization,’ which shows how the design model meets the requirements for that use case
• Use Case Realization is UP term, not UML
• Interaction diagrams help express Use Case Realization
![Page 48: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/48.jpg)
INFO 620 Lecture #6 48
Use Case Realization
• Use case suggests system events shown in system sequence diagram
• Effect of operations may be documented in operation contracts
• Events represent messages which initiate interaction diagrams
• Interaction diagrams describe communication between classes
![Page 49: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/49.jpg)
INFO 620 Lecture #6 49
Interaction Diagrams
• Recall the collaboration diagrams are specific to one use case
• Sequence diagrams generally show one scenario for one use case; might show extensions
• Operations contracts describe the conditions for one event in one use case
![Page 50: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/50.jpg)
INFO 620 Lecture #6 50
Models Don’t Start Perfect
• Expect that early requirements, and the initial domain model (conceptual class diagram) will not be perfect– But that doesn’t mean do them poorly!– Maintain contact with customer and subject
experts to keep improving models
• Conceptual classes inspire design classes– But many additional classes likely needed
![Page 51: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/51.jpg)
INFO 620 Lecture #6 51
Model-View Separation
• Non-GUI objects should not be involved in output tasks
• This reinforces the Boundary/Control/Entity object distinction earlier
• Controllers should know the information to be displayed in output, but actual output is a boundary object’s purpose
![Page 52: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/52.jpg)
INFO 620 Lecture #6 52
More UML Notation
• Constraints are tagged with curly brackets {}. An algorithm may be shown if needed.
• Notes are in text boxes which also have the upper right corner dog-eared
This the the body of a Note box. It also has a Name, which isn't visible.
{s.isComplete = true} <- Constraint
<- Note
![Page 53: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/53.jpg)
INFO 620 Lecture #6 53
Object Constraint Language
• UML supports using a formal Object Constraint Language (OCL) to show constraints on execution of messages– http://www.omg.org/docs/ad/97-08-08.pdf – A newer version of the OCL is under
development as of July 2003
• Any notation may be used, however
![Page 54: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/54.jpg)
INFO 620 Lecture #6 54
Iteration 2
• The text’s second iteration assumes that in iteration 1 everything was done through development of the design class diagram, and major architecturally important parts of the system have been coded and tested
• Iteration 2 is refining the design through additional patterns (which we aren’t covering)
![Page 55: INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker](https://reader030.vdocument.in/reader030/viewer/2022032709/56649eb05503460f94bb59ce/html5/thumbnails/55.jpg)
INFO 620 Lecture #6 55
Iteration 2
• Iteration 2 also adds more scenarios to the foundation already established
• Additional lower priority use cases may be fully defined
• The system sequence diagram may be expanded to include external systems (p. 324)