Software Engineering

1. Software Engineering Object Oriented Design James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain/courses/SoftEng/

2. Objectives • Describe the Object Oriented design process: • Subsystem Design • Class and Object Design • Message Design • Responsibilities Design • Detail the UML models produced during OO design • Specification Class Diagrams • Package Diagrams

3. The Challenge of OO Design • To create re-usable OO software a designer must: • Find pertinent objects • Factor them into classes of the right granularity • Define class interfaces and inheritance hierarchies • The design should be specific to the problem at hand but general enough to address future problems and requirements. • All design methods strive for: • Abstraction • Information hiding • High cohesion; Low coupling • Modularity • But only OOD can achieve all four without complexity or compromise.

4. OO Design Attributes, Operators, Collaborators r e s p o n s i b i l i t i e s Object-Relationship Model d e s i g n CRC Cards m e s s a g e Use-Cases d e s i g n C l a s s a n d o b j e c t Object-Behaviour Model d e s i g n s u b s y s t e m d e s i g n THE DESIGN MODEL THE ANALYSIS MODEL

5. Design Summary analysis design code test

6. OO Design Criteria • Decomposability • The design method helps the designer to decompose a large problem into subproblems that are easier to solve • Composability • The design method ensures that program components (classes), once designed and built, can be reused to create other systems • Understandability • The ease with which a program component can be understood without reference to other information or other modules • Continuity • The ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few classes • Protection • An architectural characteristic that will reduce the propagation of side affects if an error does occur in a given class

7. Generic Components for OOD • Problem Domain Component • The subsystems that are responsible for implementing customer requirements directly • Human Interaction Component • The subsystems that implement the user interface (this included reusable GUI subsystems) • Task Management Component • The subsystems that control concurrent tasks that may be packaged within a subsystem or among different subsystems • Data Management Component • The subsystem that is responsible for the storage and retrieval of persistent data

8. Human Interface Design System Design Object Design Data Management Design Task Management Design OOD Process

9. System Design Process • Represent the conceptual software architecture. • Activities (from Rambaugh et al.): • Partitioning - Partition the analysis model into subsystems • Concurrency - Identify concurrency that is dictated by the problem and allocate subsystems to processors and tasks • User Interface - Develop a design for the user interface • Data Management - Choose a basic strategy for implementing data management. Identify global resources and the control mechanisms required to access them • Task Management - Design an appropriate control mechanism for the system, including task management • Intersubsystem Communication - Define the collaborations that exist between subsystems • Consider how boundary conditions should be handled • Review and consider trade-offs.

10. [A] Partitioning the Analysis Model • Define subsystems (cohesive collections of classes, relationships and behaviour) • Design Criteria: • The subsystem should have a well-defined interface through which all communication with the rest of the system occurs • With the exception of a few “communication classes”, the classes within a subsystem should collaborate only with other classes within the subsystem • The number of subsystems should be kept small • A subsystem can be partitioned internally to help reduce complexity • Use UML Package notation

11. [B] Concurrency Allocation • Required if subsystems (or classes) must act simultaneously and asynchronously • Determine by examining State and Interaction Diagrams for a single thread of control • Choices: • Allocate each subsystem to an independent processor • Allocate subsystems to the same processor and provide OS concurrency support (e.g. threads) • Example: Digital stereo photography and transmission for a motion-capture system • Concurrency complicates a system; only use if really necessary

12. [C] User Interface Component • Use-cases serve as input to user interface design • Process: iteratively specify the command hierarchy (windows, menu bars, tool palettes) until all use-case scenarios are satisfied • But other more complex user-interactions may be required, especially for interactive systems • Many of the classes necessary to implement a GUI are available in Visual SDE’s • It is vital to do a usability analysis on the final design • Details Forthcoming in the Human-Computer Interaction course

13. [D] Data Management Component • Areas of concern: • Management of application-critical data • An infrastructure for storage and retrieval of objects • Database management system often used as a common data store for all subsystems • Objects should know how to store and retrieve themselves • Example: • GIF or JPEG files for source images and the final mosaic • The mosaic designer system must have store and retrieve methods • Might also use a simpler internal format such as a pixel array of RGB values • Details Forthcoming in the Database course

14. [E] Task Management Component • Concurrency Part II: Designing objects that manage concurrent tasks • The characteristics of the task are determined. • How is the task initiated (event or clock driven)? • What is its priority (high priority tasks must have immediate access to system resources)? • How critical is the task (highly critical tasks must continue to operate under adverse circumstances)? • A coordinator task and associated objects are defined • The coordinator and other tasks are integrated

15. [F] Intersubsystem Communication • Specify contracts (interaction specs) for subsystem interaction: • List each request that can be made by collaborators of the subsystem • For each contract note the operations (both inherited and private) that are required to implement the responsibilities implied by the contract • Considering one contract at a time, create a collaboration table (not UML) • If the modes of interaction between subsystems are complex use a subsystem interaction (collaboration) diagram

16. Subsystem Collaboration Types request server client subsystem subsystem contract request peer peer subsystem subsystem request contract contract

17. Subsystem Collaboration Table other subsystems party to the contract client/server or peer to peer subsystem classes (+ relevant methods and formats) to support contract services

18. Example: Subsystem Collaboration Diagram Request for Status Assign Zone Test Status Control Panel Subsystem Sensor Subsystem Request for system status Periodic status check Request for alarm notification Periodic check-in Central Communication Subsystem

19. UML Outputs • The system design process expands on models produced during analysis • Package diagrams (high-level class diagrams containing only package references) are popular for large complex systems • More detail is added to the Conceptual Class Diagrams to create Specification Class Diagrams • Remember to use the principles of Design: • Refinement and Abstraction • Modularity driven by Coupling and Cohesion • Information Hiding

20. UML Package Diagrams • Mechanism for dividing and grouping model elements (e.g. classes, use-cases) • Group into Packages: • Classes in the same inheritance hierarchy • Classes related via aggregation or composition • Classes with lots of collaboration • Notation: • Package (a named collection of classes) • Dependency (reflects a relationship between any two classes in the participating packages) Package Name

21. Example: Packaging a Class Diagram

22. Image Reference Picture Mosaic Image Mosaic Generator Example: Final Package Diagram

23. Name Attributes Methods UML Specification Class Diagrams • Detail is added to the attribute and methods areas of the class • The class diagram may also be refined • Attributes: • Syntax: visibility name : type = default-value • visibility is + (public) # (protected) or – (private) • name is a string • type language-dependent specification • default-value the initial value of the attribute • Example: # numberPlate : string = “CA 101 010”

24. Operation Syntax • Operations (Methods): • Syntax: visibility name ( parameter-list ) : return-type-expression • visibility and name are the same as for attribute syntax • parameter-list contains optional arguments with the same syntax as attributes (separated by commas) • return-type-expression is an optional language-dependent specification • Example: + latestAmountOf (PhenomenonType value) : Quantity

25. Example: Specification Class Diagram

26. Exercise: Specification Class Diagram • Refine a conceptual class diagram to produce a specification class diagram given the following information: • A triangle consists of three vertices each with a point position, vector direction and r-g-b colour. The vector can be normalized (converted to unit length). • A particle has a point position and a triangle index. It must be able to generate a random position given a triangle index. • A triangle can be drawn and a surface rendered (by making multiple calls to the draw method)

27. Solution: Specification Class Diagram