1. CMSC 345 Fall 2000 Design

2. What is Design? Verb: The creative process of transforming the problem into the solution Noun: The description of the solution Typically multiple acceptable soultions Two types of design Conceptual for the customer Technical for the developer

3. Conceptual Design Tells the customer what the system will do Characteristics of Conceptual Design Written in customer language No technical jargon Describes functions of the system Independent of the implementation Links to requirements documents

4. Conceptual Design (2) System defined by its boundaries, entities, attributes and relationships Answer questions: 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?

5. Technical Design More detailed than conceptual design Describes the form the system will take Description of major hardware components and their interactions (if not part of problem space) Hierarchy and function of software components (those not part of problem) Major data structures used within system and data flow through system

6. WHATHOW Customers System builders CONCEPTUAL DESIGN TECHNICAL DESIGN function form System designers

7. CONCEPTUAL DESIGN TECHNICAL DESIGN “The user will be able to route messages to any other user on any other network computer.” Network topology Protocol used Prescribed bps rate...

8. Decomposition and Modularity To design a system is to determine a set of components and interfaces that satisfy the requirements. Many ways to create good design, but…. Every design method involves some kind of decomposition

9. Design Strategies Functional design system is designed from a functional viewpoint and progressively refined The system state is centralized and shared between the functions operating on that state Object-oriented design system is viewed as a collection of objects. Based on the idea of information hiding The system state is de-centralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods

10. Design Stages (Sommerville) Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems into components Data structure design Design data structures to hold problem data Algorithm design Design algorithms for problem functions

11. Design Methods (Wasserman) Modular decomposition: assign functions to components Data-oriented decomposition: based on external data structures. Event-oriented decomposition: based on how events handled by system change the system state Outside-in: black-box approached based on user inputs to the system Object-Oriented : identifies classes of objects and their relationships

12. Top level First level of decomposition Second level of decomposition

13. Architectural Design Architecture: associates system capabilities with components that will implement them, and their interconnections Code: involves algorithms and data structures, primitives and compositions in terms of language primitives Executable: memory allocation, data formats, bit patterns, etc.

14. Architectural Styles Pipes and Filters Object-Oriented Implicit Invocation Layering Repositories Process Control Others…

15. Pipes and Filter Architecture aka Data-Flow model Pipes are streams of data for input and output Filters transform the input to output Filters are independent and “unaware” of other filters

16. FilterPipe

17. Invoice processing system

18. Pipe and Filter Plus and Minus Plus – Filters easily reused Plus – Easy to add/remove filters Plus – Easy to implement as concurrent or sequential system Minus – Not good for interactive systems Minus – Independent filters may duplicate (preparatory) processing Minus – Must maintain correspondence between multiple data streams

19. Object Oriented Architecture Each component is an instance of an ADT. Components must preserve integrity of data representation, keeping hidden from other objects Decompose problem into system loosely coupled objects with well defined interfaces However, each object must know identity of other objects it interacts with, and all objects that invoke a changed object must themselves be changed

20. Invoice processing system

21. OO Plus and Minus Plus – loosely coupled objects allow changing implementation without affecting other objects Plus – objects represent “real world” entities and are therefore reusable Minus – objects must explicitly reference name and interface of other objects, so interface change affects all other objects Minus – complex objects may be difficult to represent

22. Layering Architecture Models the interfacing of subsystems Layers are hierarchical Each layer provides a service to the one outside of it and is a client to the layer inside of it Each layer is an increased level of abstraction

23. Users Cryptography File interface Key management Authentication

24. Layering Plus and Minus Plus – portable and changeable if the interface between layers is preserved Plus – machine dependencies localized in the inner layers Minus – structuring the system in this way may be difficult Minus – multiple layers require multiple levels of command interpretation which may affect performance

25. Client-Server Architecture Distributed system architecture Client requests action or service Server responds to the request Clients must know the name of the available servers and the services they provide Servers need not know the identity of clients or how many there are Clients access services provide by a server through a remote procedure call

26. Film and picture library

27. Client-Server Plus and Minus Plus – clients get information only when they need it. Plus – distribution is straightforward Plus – clients handle presentation details Minus – require sophisticated security, systems management, more resources to implement and support

28. Characteristics of OOD Objects are abstractions of real-world or system entities and manage themselves Objects are independent and encapsulate state and representation information. System functionality is expressed in terms of object services Shared data areas are eliminated. Objects communicate by message passing Objects may be distributed and may execute sequentially or in parallel

29. OOD Structure

30. Advantages of OOD Easier maintenance. Objects may be understood as stand-alone entities Objects are appropriate reusable components For some systems, there may be an obvious mapping from real world entities to system objects

31. OOD Method Commonality The identification of objects, their attributes and services The organization of objects into an aggregation hierarchy The construction of dynamic object-use descriptions which show how services are used The specification of object interfaces

32. Objects, Classes and Inheritance Objects are entities in a software system which represent instances of real-world and system entities Object classes are templates for objects. They may be used to create objects. Object classes may inherit attributes and services from other object classes

33. A Mail_Message Object Class Sender Receiver Sender address Receiveraddress Date sent Date received Route Title Text Send Present File Print Mail message

34. Objects An object is an entity which has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.

35. Object Communication Conceptually, objects communicate by message passing. The name of the service requested by the calling object. Copies of the information required to execute the service and the name of a holder for the result of the service. In practice, messages are often implemented by procedure calls Name = procedure name. Information = parameter list.

36. Inheritance Objects are members of classes which define attribute types and operations Classes may be arranged in a class hierarchy where one class is derived from an existing class (super-class) A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own

37. A Class Hierarchy

38. Advantages of Inheritance It is an abstraction mechanism which may be used to classify entities It is a reuse mechanism at both the design and the programming level The inheritance graph is a source of organizational knowledge about domains and systems

39. Problems with Inheritance Object classes are not self-contained. they cannot be understood without reference to their super-classes Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained

40. Object Identification Identifying objects is the most difficult part of object oriented design. There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative process. You are unlikely to get it right first time

41. Approaches to Identification Use a grammatical approach based on a natural language description of the system Base the identification on tangible things in the application domain Use a behavioral approach and identify objects based on what participates in what behavior Use a scenario-based analysis,

42. Objects and Operations Nouns in the description give pointers to objects in the system Verbs give pointers to operations associated with objects Approach assumes that the designer has a common sense knowledge of the application domain as not all objects and services are likely to be mentioned in the description

43. Static System Structure Object aggregation hierarchy diagrams show the static system structure. They illustrate objects and sub-objects. This is NOT the same as an inheritance hierarchy

44. Aggregation Hierarchy

45. Dynamic System Structure Object-service usage diagrams illustrate how objects use other objects. They show the messages passed (procedures called) between objects

46. Object Interactions

47. Object Interface Design Concerned with specifying the detail of the object interfaces. This means defining attribute types and the signatures and semantics of object operations Representation information should be avoided Precise specification is essential so a programming language description should be used

48. C++ Interface class Weather_station { public: Weather_station () ; ~Weather_station () ; void Transmit_data (computer_id dest) ; void Transmit_status (computer_id dest) ; void Self_test () ; void Shut_down () ; // Access and constructor functions char* Identifier () ; void Put_identifier (char* Id) ; instrument_status Inst_status () ; void Put_instrument_status (Instrument_status ISD) ; weather_data_rec Weather_data () ; void Put_weather_data (weather_data_rec WDR) ; private: char* station_identifier ; weather_data_rec Weather_data ; instrument_status inst_status ; } ;

49. Concurrent Objects The nature of objects as self-contained entities make them suitable for concurrent implementation The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system

50. OO Key Points OOD is design with information hiding. Representations may be changed without extensive system modifications An object has a private state with associated constructor and access operations. Objects provide services (operations) to other objects. Object identification is a difficult process. Identifying nouns and verbs in a natural language description can be a useful starting point for object identification.

51. OO Key Points Object interfaces must be precisely defined. A programming language such as Ada or C++ may be used for this Useful documentation of an OOD include object hierarchy charts and object interaction diagrams