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 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) …
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 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 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
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
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