1 / 77

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 5

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 5. Review of Last Lecture. Analysis: Software Architecture. Use Case Realization: Use Case → Sequence Diagrams. Domain Model Refinement: Domain Model → Partial Class Diagram. Overview of This Lecture. Design:

brady-baird
Download Presentation

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 5 CPSC-4360-01, CPSC-5360-01, Lecture 5

  2. Review of Last Lecture • Analysis: • Software Architecture. • Use Case Realization: • Use Case → Sequence Diagrams. • Domain Model Refinement: • Domain Model→ Partial Class Diagram. CPSC-4360-01, CPSC-5360-01, Lecture 5

  3. Overview of This Lecture • Design: • Major activities during design phase. • Tools: • Class Diagram. • Object Diagram. CPSC-4360-01, CPSC-5360-01, Lecture 5

  4. Requirement Analysis Design Implement Test Where are we now? • Flesh out the system design: • Choose the appropriate hardware and software environment. • Detail Class Design. CPSC-4360-01, CPSC-5360-01, Lecture 5

  5. Design: Overview • Inputs: • Software Architecture. • Analysis Class Diagram. • Activities: • Decide and design appropriate classes for other layers in the Software Architecture. • Refine Analysis Class Diagram: • Produce detailed Class Diagram ready for implementation. • Collaboration Diagrams to study interaction between classes. • State Chart to study behavior of a class. • Apply Design Pattern. CPSC-4360-01, CPSC-5360-01, Lecture 5

  6. Design and the Layered Architecture • Analysis shows how business functions can be implemented in the application layer. • Design extends this level of modelling to the other layers, i.e., the Presentation and Storage layers: • Studies interaction using the sequence diagrams. • Infers information about the classes. CPSC-4360-01, CPSC-5360-01, Lecture 5

  7. Design: Presentation Layer • Decide the suitable User Interface and design the classes to support. • Details about designing a good user interface is not the aim of this course. • Important points independent of the chosen User Interface: • Separation between the User Interface and Application. • Relationship between the User Interface and Application. CPSC-4360-01, CPSC-5360-01, Lecture 5

  8. Presentation Layer Revisited • System messages have been shown arriving at the controller in the Application layer: • Questions like “How the user initiates certain events?”, “How do we get this value from the users?” were ignored. • In fact, these messages have been ‘pre-processed’ in the Presentation layer: • The boundary object in the Presentation layer models the system's user interface. • User requests are received and processed before they are redirected to the controller object. • Responsible for interacting with input devices. CPSC-4360-01, CPSC-5360-01, Lecture 5

  9. Case Study 1: Graphical User Interface • Assumption: a window-based application, i.e., a Graphical User Interface will be used. • Possible sequence of initiating the Display Booking use case: • Select an appropriate menu option. • Dialogue box appear. • User enters the date and click the OK button. • Should concentrate on the steps that trigger operations in the Application layer, e.g., the last step above. CPSC-4360-01, CPSC-5360-01, Lecture 5

  10. Case Study 1: Presentation Layer • Packages are included to show the interaction between the layers. • Upon clicking the OK button: • A message submit( ) is generated which is caught by StaffUI in the Presentation Layer. • StaffUI sends a display( ) message to the BookingSystem in the Application Layer. CPSC-4360-01, CPSC-5360-01, Lecture 5

  11. Case Study 1: Mouse Event • Mouse events are handled similarly: • An user interface object translates mouse events into system messages; • Time and Table are derived from mouse coordinates. CPSC-4360-01, CPSC-5360-01, Lecture 5

  12. Case Study 1: Inferring Class Information • For GUI, there exists a series of user generated events for one use case, e.g., Transferring an existing booking by “Drag and Drop” to a new slot. Select a Booking on screen Move the mouse around “Drop” the booking to a new slot CPSC-4360-01, CPSC-5360-01, Lecture 5

  13. Case Study 1: Inferring Class Information • User generated events might not have an one-to-one correspondence with System Message. • The boundary objects may need to keep extra information to: • Remember the state of current interaction. • Deduce when to send a system message. • In the Table Transfer example, the GUI has to: • Remember that Table Transfer is being performed, even when the user moves the mouse around. • Responsible for sending the transfer() message when the mouse button is released. CPSC-4360-01, CPSC-5360-01, Lecture 5

  14. **************************************** Welcome to BR-Booking Reservation System **************************************** Display Booking Record Booking ... ... ... Your Choice -> 1 Please Input Date -> 01/01/2006 Bookings on 01/01/2006 (Sunday): Table 1: 7pm – 9pm: YJ (1234): 4 Persons 9pm – 11pm: WH (5678): 6 Persons ... ... ... ... Although the interface is very different, activities are similar: Design UI. Study Interaction. Design the UI classes. Text Based UIs are slightly easier to design as the order of events is well defined. Case Study 1: Text Based User Interface Restaurant Booking System – Text Based UI CPSC-4360-01, CPSC-5360-01, Lecture 5

  15. :Staff Case Study 1: Text Based User Interface <<Boundary>> :StaffTextUI <<Control>> :BookingSystem :Restaurant displayOpt ( ) readDate ( ) This part is the same as the Sequence Diagram in Lecture 4, Slide 37 display( date ) date getBookings ( date) … … bookings New interactions for the Presentation layer CPSC-4360-01, CPSC-5360-01, Lecture 5

  16. Presentation Layer: Summary • Activities during design phase for Presentation layer: • Decide the appropriate type of User Interface. • Draft the User Interface. • Study the interaction to perform each of the use cases: • Modifying existing sequence diagrams derived during analysis. • Derive the classes needed: • Messages. • Class attributes. • Association with classes in the Application layer. CPSC-4360-01, CPSC-5360-01, Lecture 5

  17. Storage Layer: Revisited • Most systems need persistent data which is: • Not lost when the system closes down. • Stored in the file system or a database. • A few possible choices to provide persistency: • Relational databases (RDBMS). • Object serialization (Java). • Files input/output. • Designer needs to: • Identify what data needs to be persistent. • Identify ways to save/load the data according to the storage choice. CPSC-4360-01, CPSC-5360-01, Lecture 5

  18. Designating Persistent Classes • Case Study 1: • All booking information must be saved. • But not current date, or selected bookings. CPSC-4360-01, CPSC-5360-01, Lecture 5

  19. Designating Persistent Classes • In UML, classes are the unit of persistence. • A persistent class is denoted by a tagged value {persistent}. CPSC-4360-01, CPSC-5360-01, Lecture 5

  20. Saving and Reloading Object • As an object exists only during the program execution, there is no clear counterpart in the static storage, i.e., you cannot save an “object” directly to a file. • Instead, attributes of an object are saved. • Upon reloading, the attributes are read and an object is recreated using the same attributes, giving the illusion that “object” is loaded from a static storage. • This works well for objects that contain only simple values, but what about reference? CPSC-4360-01, CPSC-5360-01, Lecture 5

  21. Preserving Association • An association between objects operates using reference (memory address): • The memory address of an object may be different upon reloading as the object is reallocated. • An identification information to locate an object is needed to restore the association. • A simple way is to assign an unique id to each object. CPSC-4360-01, CPSC-5360-01, Lecture 5

  22. Simple Example • Example to highlight the problem of saving/loading objects. • Given the code fragment below: class A { int AInt; B refB; ... } class B { int BInt; ... } • Assume we instantiated two objects of class A and link them to two objects of class B. • A memory view during execution is on next page. CPSC-4360-01, CPSC-5360-01, Lecture 5

  23. The reference of class B object is kept as a memory address (e.g., 0x00001234) in the object of class A. Simple example (memory view) …… AInt: 11111 Class A Object refB: 0x00001240 …… Class A Object AInt: 22222 refB: 0x00001234 …… Class B Object BInt: 999 …… Class B Object BInt: 888 …… CPSC-4360-01, CPSC-5360-01, Lecture 5

  24. Simple Example (after saving to file) • Suppose we save all object attributes directly to a text file: • Upon reloading, the attributes for each object are read (e.g., the first two lines for class A object). • And a new object of the desired class is instantiated with the information read. • As we have no way to influence where to place an object, the object reference no longer works…. 111110x00001240222220x00001234999888 Text file after saving 4 objects. CPSC-4360-01, CPSC-5360-01, Lecture 5

  25. Simple Example (after reloading) …… • Let us add an oid to each object. • Instead of remembering the reference, the oid is kept instead. • Note: Only one pair of objects A and B is shown on next page to simplify the diagram. Class A Object AInt: 11111 refB: 0x00001240 Class B Object BInt: 888 …… Class B Object BInt: 999 …… AInt: 22222 Class A Object refB: 0x00001234 …… …… CPSC-4360-01, CPSC-5360-01, Lecture 5

  26. Simple Example (with oid ) • The object of class A contains its own oid, as well as the oid for the class B object that it reference (B_oid). • Memory reference is used during runtime to allow quick access. …… AInt: 11111 Class A Object refB: 0x00001240 OID: 1 B_OID: 4 …… …… …… …… BInt: 888 Class B Object OID: 4 CPSC-4360-01, CPSC-5360-01, Lecture 5

  27. Simple Example (Save and Reload with oid) • The identification information oid is saved along with other attributes. • Upon reloading, the objects will be re-instantiated with the attributes saved. • The reference is restored by looking up the object that matches oid. 11111148884 Text file after saving 2 objects CPSC-4360-01, CPSC-5360-01, Lecture 5

  28. Simple Example (Restoring Reference) …… …… AInt: 11111 AInt: 11111 Class A Object Class A Object refB: ?????? refB: 0x001200 OID: 1 OID: 1 B_OID: 4 B_OID: 4 …… …… BInt: 888 BInt: 888 Class B Object Class B Object OID: 4 OID: 4 …… …… …… …… After Restoration Before Restoration CPSC-4360-01, CPSC-5360-01, Lecture 5

  29. Observations • A mapping class is needed: • To map oid to actual memory reference. • To assign oid to objects during new object creation. • Oid behaves just like a key in a database record: • The whole process is equally applicable when using DBMS instead of an I/O file. • Using an oid to identify other objects is equivalent to using a foreign key to identify other record. • DBMS is beyond the scope of this course. • However, the process/steps are still valuable insights. CPSC-4360-01, CPSC-5360-01, Lecture 5

  30. Case Study 1: Adding Persistency Support • Take the Table class as example: • A subclass is added to incorporate the oid. • A mapper class is added. CPSC-4360-01, CPSC-5360-01, Lecture 5

  31. Case Study 1: Adding Persistency Support • The PersistentTable subclass is added so that other classes that depend on the Table class will not be affected. • Incorporating oid directly into the Table class would limit the possible choice of persistency support. • The TableMapper class is responsible for creating objects of the PersistentTable class and restoring them from persistent storage if required. • Apply the same idea to other classes that require persistency support: • Booking • Customer • Etc… CPSC-4360-01, CPSC-5360-01, Lecture 5

  32. Case Study 1: Persistency Architecture • Persistent subclasses and mapper classes depend on the class they are supporting. • So, they must be in the Application layer. • The Restaurant class is dependent on mapper classes: • Restaurant uses the mapper class to create an object with persistency support. • In order to preserve layered architecture: • Split the Application layer into two sub-packages: • Domain sub-package for all classes directly related to problem domain. • Persistency sub-package for persistency support classes has minimal effect on the ‘Domain’ sub-package. • Changing the Persistency sub-package should have a minimum impact on the Domain sub-package. CPSC-4360-01, CPSC-5360-01, Lecture 5

  33. Persistency Architecture CPSC-4360-01, CPSC-5360-01, Lecture 5

  34. Persistency Sub-Package: Possible Questions • One possible way of achieving persistency has been described. • There are other possible questions: • When to save/load objects? • Load on execution starts, Save on exit? • Save on creation/modification? • Load only when needed? • Should the system provide backup? • Should the system be crash-proof? • These constraints should be taken into account when designing the persistency support. CPSC-4360-01, CPSC-5360-01, Lecture 5

  35. Storage Layer: Summary • Activities during design phase for Storage layer: • Identify classes that require persistency support. • Choose appropriate persistency service. • Introduce classes to work with the chosen persistency service. • Additional sequence diagram can be drawn to capture the operations needed. CPSC-4360-01, CPSC-5360-01, Lecture 5

  36. Design Phase: The rest of the journey • At this point, the basic technique/activity during design phase is covered. • Subsequent lectures (up to lecture 8) will take a closer look at the tools (relevant UML diagrams) and one important technique to enhance the design (design patterns). CPSC-4360-01, CPSC-5360-01, Lecture 5

  37. Detailed Class Design • Create a detailed class specification that could be used as a basis for implementation. • Start with analysis class model. • Collect messages from all realizations: • check redundancy, inconsistency, etc. • define the operation interface of class. • specify detailed parameters and return types. CPSC-4360-01, CPSC-5360-01, Lecture 5

  38. Class Name Attributes Operations Class Diagram: Review • Class is represented by: One Class • A relationship between classes is represented by an association with: • Association name. • Role name. • Multiplicity. • Nagivability (direction). CPSC-4360-01, CPSC-5360-01, Lecture 5

  39. Class Multiplicity • Multiplicity notation, e.g.: • 3 (three only, specific number). • 2..8 (two to eight only, specific range). • 1,3,5 (either one, three or five only). • * (zero to many). • Can be applied to class, known as class multiplicity: • Determine the number of instances for a class. • Default class multiplicity is *. • Special cases can be denoted as: This class can have exactly one instance during execution. Class Name 1 CPSC-4360-01, CPSC-5360-01, Lecture 5

  40. Table number: Integer places: Integer Attribute Type • Each attribute should have a type, denoted as: attribute_name: type • Example: • UML defines only Integer, String, Boolean. • Specific Programming Language types are usually allowed, e.g., Float, Double, Char, etc. • UML allows definition of a new type using enumeration. CPSC-4360-01, CPSC-5360-01, Lecture 5

  41. <<enumeration>> Color red amber green TrafficLight currentLight: Color Enumeration • Define a new datatype color with the acceptable values red, amber, green: • Usage example: The traffic light color can be either red, amber or green. The attribute currentLight can only have the values red, green or amber. CPSC-4360-01, CPSC-5360-01, Lecture 5

  42. Table number: Integer places: Integer totalTable: Integer Attribute Scope • Attribute of a class has instance scope by default: • i.e., each instance (object) of the class has an independent copy of the attribute. • There are cases where class scope is needed: • All instances share one copy of the attribute (also known as class attribute in Java). • Denote by underlining the attribute: There is only one copy of totalTableregardless of the number of Tableobjects. CPSC-4360-01, CPSC-5360-01, Lecture 5

  43. Table - number: Integer - places: Integer + totalTable: Integer Attribute Visibility • Equivalent to the accessibilitylevel in languages like C++, Java. • UML defines four levels of accessibility: • public (+): visible to all classes. • protected (#): visible to instances of subclasses. • private (-): visible only in the same class. • package (~): visible to classes in the same package. • numberand placesare private to each object. • totalTableis accessible to everyone. CPSC-4360-01, CPSC-5360-01, Lecture 5

  44. Module - examDate [0..1]: Date - staff [*]: String ... ... Attribute Multiplicity • Attribute multiplicity defines how many values an object stores for an attribute: • default is exactly 1. • optional multiplicity shows possible null values. • arrays modelled by * (many) multiplicity. CPSC-4360-01, CPSC-5360-01, Lecture 5

  45. Table - number: Integer - places: Integer + totalTable: Integer + getNumber( ): Integer + setNumber(n: Integer) + getTotal( ): Integer + Table(n: Integer, p: Integer) Operation • Operation uses the following syntax: Operation_name (parameter: type, …) : return_type • Scope and Accessibility notations are the same as the attribute’s. • Constructor is denoted as Class Scope operation in UML. CPSC-4360-01, CPSC-5360-01, Lecture 5

  46. Constructing Class Diagram • Study relevant structures (usually real world entities) and generalize to class diagram. • May be difficult in complicated cases: • We need a way to study specific examples instead of all possible scenarios. • From a few representative examples, we generalize to a structure that is able to support all cases. • An object diagram is introduced to study specific examples instead of general cases. CPSC-4360-01, CPSC-5360-01, Lecture 5

  47. Object Diagram • Classes in a program describe all possible instances (objects). • During program execution, only a subset of all possible objects are instantiated. • Similarly, UML defines Object Diagrams to examine instances (possible scenarios) of Class Diagrams: • The notation is very similar to a Class Diagram. • Slight difference in terminology. • Can help to understand and refine a Class Diagram. CPSC-4360-01, CPSC-5360-01, Lecture 5

  48. Class Diagram: Describes ALL possible Table Objects. Object Diagram: Describes ONE table object, with specific values. Operations were not included. Example Java Code to create this object: Table tableOne = new Table(1,10); Table tableOne: Table - number: Integer - places: Integer number = 1 places = 10 + getNumber( ): Integer + setNumber(n: Integer) Object Diagram: First Look CPSC-4360-01, CPSC-5360-01, Lecture 5

  49. Object Diagram: Closer Look • An object is given an object name: • Represents the identity of an object. • So that it can be easily referred in the diagram. • Usually it corresponds to the variable name in programming construct for convenient sake: • An object variable in Java is a reference. • Multiple object variable can refer to the same object. • However, one object can have only one object name in UML. • Denoted by: objectName: ClassName CPSC-4360-01, CPSC-5360-01, Lecture 5

  50. Object Diagram: Closer Look • The object name can be omitted when we are not interested in knowing the exact object in action: :Person • The attributes of an object have specific values. • Denoted by: attributeName = value • Operations of an object are not shown as all objects of the same class have the same set of operations. CPSC-4360-01, CPSC-5360-01, Lecture 5

More Related