Software Engineering

1. Software Engineering OO Design

2. Objectives • Describe the Object Oriented design process • Detail the UML models produced during OO design

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. • Difficult to achieve the first time around • All design methods strive for abstraction, information hiding, functional independence and modularity but only OOD can achieve all four without complexity or compromise.

4. OO Design A t t r i b u t e s , o p e r a t i o n s , r e s p o n s i b i l i t i e s c o l l a b o r a t o r s d e s i g n O b j e c t - r e l a t i o n s h i p C R C m o d e l I n d e x C a r d s m e s s a g e d e s i g n U s e c a s e s C l a s s a n d o b j e c t d e s i g n O b j e c t - B e h a v i o r M o d e l s u b s y s t e m d e s i g n THE ANALYSIS MODEL THE DESIGN MODEL

5. c l a s s e s c l a s s e s o b j e c t s o b j e c t s a t t r i b u t e s a t t r i b u t e s d a t a s t r u c t u r e s d a t a s t r u c t u r e s m e t h o d s m e t h o d s a l g o r i t h m s a l g o r i t h m s r e l a t i o n s h i p s r e l a t i o n s h i p s m e s s a g i n g m e s s a g i n g b e h a v i o r b e h a v i o r c o n t r o l c o n t r o l OOA and OOD A n a l y s i s M o d e l D e s i g n M o d e l A n a l y s i s M o d e l D e s i g n M o d e l

6. Design Criteria • decomposability—the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve • composability—the degree to which a 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 are responsible for controlling and coordinating 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. [1] System Design Process • Represent the conceptual software architecture. • Activities: • Partition the analysis model into subsystems • 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 small number of “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 • Concurrency is required if subsystems (or classes) must act on events simultaneously and asynchronously • Determine by examining State and Interaction Diagrams for 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: SafeHome sensor monitoring and dialing of the central station are independent • Concurrency complicates a system; try to avoid if possible

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 • Many of the classes necessary to implement a GUI are available in Visual SDE’s • Details to appear 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: flat file for “sensors”. Each record corresponding to a named instance of sensor with particular values for all attributes. Sensor objects would contain store and retrieve methods.

14. [E] Task Management Component • 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 spec) for subsystems: • 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 Table other subsystems party to the contract client/server or peer to peer subsystem classes (+ relevant methods and formats) to support contract services

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

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 refines 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

20. UML Specification Class Diagrams • 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” • 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 • return-type-expression is an optional language-dependent specification • Example: + latestAmountOf (PhenomenonType value) : Quantity

21. [2] Object Design • Component level design of individual classes • A protocol description establishes the interface of an object by defining each message that the object can receive and the related operation that the object performs • An implementation description shows implementation details for each operation implied by a message that is passed to an object. Contains: • information about the object's private part • internal details about the data structures that describe the object’s attributes • procedural details that describe operations • Output: header files in the target language and message descriptions (e.g. MESSAGE (motion.sensor) read: RETURNS sensor.ID, sensor.status)

22. [3] Design Patterns • Identifying and building reusable patterns • “... you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.”

23. Design Pattern Attributes • The design pattern name is an abstraction that conveys significant meaning about it applicability and intent. • The problem description indicates the environment and conditions that must exist to make the design pattern applicable. • The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate into a variety of problems. • The consequences associated with the use of a design pattern provide an indication of the ramifications of design decisions.