Object-Oriented Component Design Guidelines

1. Chapter 2: Component Level Design

2. Introduction … • Purpose of component-level design:- • Represent algorithm at the level of detail that can be reviewed for quality • The closest design activity to coding

3. Introduction … • What is a component? • OMG Unified Modeling Language Specification defines a component • “a modular, deployable, and replaceable part of a system that encapsulates implementation & exposes a set of interfaces” • OO view: a component contains a set of collaborating classes • Conventional view: logic, the internal data structures – required to implement the processing logic, - interface enables the component to be invoked & data to be passed it

4. Category of Component Level Design • Component level design are divided into two:- • High level design • Low level design

5. High Level Design • The high level design includes such things as decisions about:- • Platform to use (such as desktop, laptop, tablet, or phone) • What data design to use (such as direct access, 2-tier or 3-tier • Interfaces with other system (such as external purchasing systems)

6. Low Level Design • After your high-level design breaks the projects into pieces/modules, you can assign those pieces to groups within the project so that they can work on low level design • For example, the ostrich racing application’s database piece would include an initial design for the database • It should sketch out the tables what will hold the race, ostrich, and jockey information

7. Object-oriented component design … • OO analysis, design & programming are related but is differ • OOD concern with developing an object-oriented system model to implement requirements • Detail description of class attributes, operations, & interfaces required prior to beginning construction activities

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

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

10. Design guidelines … • 1. Components • Establish naming conventions during architectural modeling • Architectural component names should have meaning to stakeholders • Infrastructure component names should reflect implementation specific meaning

11. Design guidelines (cont..) … • 2. Interfaces • Interfaces provide important information about communication & collaboration • 3. Dependencies an Inheritance • It is good idea to model dependencies from left to right & inheritance from bottom (derived classes) to top (base classes)

12. Objects and object classes … • Objects are entities in a software system which represent instances of real-world & 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

13. Objects and object classes … • Object is an entity that has a state & 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. • Object are created according to some object class definition. An object class definition serves as a template for objects. – include declarations of all attributes & services which should be associated with an object of that class.

14. Employee object class (UML) … Employee name:string address:string dateOffer: date employeeNo: integer department: Dept manager:Employee salary: integer status: {current,left,retired} taxCode: integer join() leave() retire() changeDetails() Fig. 1. Object: Employee

15. Object communication … • Conceptually, objects communicate by message passing • Messages: • The name of the service requested by the calling object • Copies of the information required to execute the service & the name of a holder for the result of the service • In practice, messages are often implemented by procedures calls • Name = procedure name; • Information = parameter list

16. Generalization & inheritance … • Objects are members of classes that define attribute types & operations • Classes may be arranged in a class hierarchy where one class (a super class) is a generalization of one or more other classes (sub-class) • A sub-class inherits the attributes & operations from its super class & may add new methods @ attributes of its own • Generalizations in the UML is implemented as inheritance in OO programming languages

17. A generalization hierarchy Employee Manager budgetsControlled dateAppointed Programmer project progLanguages Project Manager projects Dept. Manager dept Strategic Manager responsibilities Fig. 2. Generalization hierarchy

18. Advantages of inheritance • It is an abstraction mechanism which may be used to classify entities • It is reuse mechanism at both the design & the programming level • The inheritance graph is a source of organizational knowledge about domain & systems

19. Problems of inheritance • Not self-contained, they cannot be understood without to their super-classes • Designer have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency • The inheritance graphs of analysis, design & implementation have different functions & should be separately maintained

20. UML associations • Objects & object classes participate in relationships with other objects & object classes • In UML, a generalized relationship is indicated by an association • Associations may be annotated with information that describes the association • Associations are general but may indicate that an attribute of an object is an associated object or that a method relies on an associated object

21. An association model Employee Department is-member-of is-managed-by Department manager Fig. 3. association model

22. An object-oriented design process • Structured design processes involve developing a number of different system models • They require a lot of effort for development & maintenance of these models and, for small system, this may not be cost-effective • However, for large systems developed by different groups design models are an essential communication mechanism

23. Process stages Define the context & nodes of use of the system Design the system architecture 2 1 3 Identify the principal system objects 5 4 Develop design models Specify object interfaces

24. System context & models of use • System context • A static model that describes other systems in the environment • Use a subsystem model to show other systems • Following slide shows the systems around the weather station system • Model of system use • A dynamic model that describes how the system interacts with its environment • Use use-cases to show interactions

25. Case study: “Weather System” • A weather mapping system is required to generate weather maps on a regular basis using data collected from remote, unattended weather stations & other data sources such as weather observes, balloons & satellites. Weather stations transmit their data to the area computer in response to a request from that machine • The area computer system validates the collected data & integrates it with the data from different sources. The integrated data is achieved and, using data from this archive and a digitized map database a set of local weather maps is created. Maps may be printed for distribution on a special-purpose map printer or may be displayed in a number of different formats.

26. Subsystems in the weather mapping system

27. Use-case model • Use-case models are used to represent each interaction with the system • A use case models shows the system features as ellipses and the interacting entity as a stick figure

28. Use-case for the weather station

29. Use-case description

30. Object identification • Identify object is the most difficult part of object oriented design • There is no ‘magic formula’ for object identification. It relies on the skill, experience & domain knowledge of system designers • Object identification is an iterative process.

31. Weather station object classes • Ground thermometer, Anemometer, Barometer • Application domain objects that are ‘hardware’ objects related to the instruments in the system • Weather station • The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model • Weather data • Encapsulates the summarized data from instruments

32. Weather station object classes WeatherStation identifier reportWeather() calibrate(instruments) test() startup shutdown WeatherData airTemperature groundTemparatures windSpeeds windDirections pressures Rainfail startup shutdown Ground thermometer temperature test() calibrate Anemometer windSpeed windDirection test() Barometer pressure height test() calibrate()

33. Design models • Design models show the objects and object classes & relationships between these entities • Static models describe the static structure of the system in terms of objects classes & relationships • Dynamic models describe the dynamic interactions between objects

34. Example of design models • Sub-system models that show logical groupings of objects into coherent subsystems • Sequence models that show the sequence of object interactions • State machine models that show how individual objects change their state in response to events • Other models include use-case models, aggregation models, generalization, etc

35. Subsystem models • Show how the design is organized into logically related groups of objects • In UML, these are shown using packages – an encapsulation construct

36. Weather station subsystems

37. Sequence models

38. State charts • Show how objects respond to different service requests and the state transitions triggered by these requests • If objects state is Shutdown then it responds to a Startup () message • In the waiting state the object is waiting for further messages • If reportWeather() then system moves to summarizing state • If calibrate() the system moves to a calibrating state • A collecting state is entered when a clock signal is received

39. Weather station state diagram

40. Object interface specification • Object interfaces have to be specified so that the objects and other components can be designed in parallel • Designers should avoid designing the interface representation but should hide this in the object itself • Object may have several interfaces which are viewpoints on the method provided • The UML uses class diagram for interface specification but JAVA may also be used

41. Weather station interface

42. Algorithm design model • Represents the algorithm at a level of detail that can be reviewed for quality • Options:- • Graphical (i.e. flowcharts, box diagram) • Pseudocode • Programming language • Decision table • Conduct walkthrough to access quality