SE: CHAPTER 6 Considering Objects

1. SE: CHAPTER 6Considering Objects • The Special Nature of OO Development • Use Cases • Using UML • OO System Design • OO Program Design • OO Measurement

2. Considering Objects • We will examine more carefully the concepts involved in Object-Oriented (OO) development • We will show how they are used in requirements capture, system design, and program design • To illustrate these concepts, we will use UML, the Unified Modeling Language • We will see that : Capturing design in UML helps to make problems and the solutions more visible • The design can be improved as we view it from different perspectives

3. 6.1 What Is OO ? • What is OO ? • Object-Oriented is an approach to software development that • Organizes both the problem and its solution as a set of discrete objects • Both data structure and behavior are included in the OO representation • We can recognize an OO representation by its seven characteristics • Identity, abstraction, classification, encapsulation, inheritance, polymorphism and persistence

4. Characteristics of OO • Characteristics of OO • Identity refers to the fact that the system are organized into discrete, distinguishable entities called Objects. • A single object has states and behaviors associated • Each object usually has a Name, also called a Reference or Handle; the Name distinguishes one object from another • OO uses Classification to group objects that have attributes and behaviors in common • We can represent a class using a box such as the one in Fig 6.2 • Class name, attributes, methods • Each object is an instance of a class. Each instance has its own attributes values, but shares attribute names and behaviors with the other instances of the class • A class encapsulates an object’s behaviors and attributes, hiding the implementation details

5. Characteristics of OO • Characteristics of OO • We can organize classes hierarchically • Forming inheritance structures • We can use an abstract class to simply the hierarchy • Where no objects of the abstract class may be defined • A behavior or method is an action or transformation that an object performs or to which it is subjected • The behavior is triggered by receipt of a particular message, or entrance into a particular state • The same behavior may exhibit differently on different classes; this is known as polymorphism

6. Characteristics of OO • Characteristics of OO • See graphic representation of class using UML • Fig 6.3, p.262 • Persistence is the ability of an object’s name, states and behaviors to transient time and space • That is, the object’s name, states and behaviors are saved as the object is transformed

7. 6.2 The OO Development Process • Advantage of OO Development • One of the advantage is its consistency of language • We can describe both the problem and the solution in the same terms : classes, objects, methods, attributes and behaviors • Throughout the development process, we should have consistency of terminology and of perspective • Describing classes requires 3 perspectives • Static, dynamic and restrictive • The static views include descriptions of the objects, attributes, behaviors and relationships • The dynamic views describe communication, control/timing, and the states and state changes • The restrictions describe constraints on the structure and the dynamic behavior

8. The OO Development Process • The difference of development processes • This cross-the-process consistency is a key difference between traditional procedure and the OO development process • OO is a philosophy of problem and solution representation, not a life-cycle by itself • OO can be used in many different software life-cycle • OO is the way to think of objects and classes in terms of their likelihood for reuse • Table 6.1 ,p.263, gives various characteristics of a software product or project

9. OO Requirements • OO development processes • No matter what the life-cycle, • an OO development process requires steps for describing requirements, designing the system, designing the programs, coding and testing. • OO requirements analysis is usually done in the user’s language • And discusses the concepts and scenarios likely in the application domain • The concepts include information, services and responsibilities • The requirements definition can be independent of its representation as objects

10. OO Coding and Testing • OO Coding by OO programming language • Once the design is done, the system is described at a very low level using object models • It is usually necessary to refine the hierarchical structures and make adjustments as the requirements grow and mature • Testing an OO system involves some of the same activities that are performed when testing any kind of system • See Fig 6.4,p.265. • There are some characteristics of OO that require special attention during testing

11. 6.3 Use Cases • Use Cases • It describes particular functionality that a system is supposed to perform or exhibit • By modeling the dialog that a user, external system, or other entity will have with the system to be developed • The entity interacting with the system is called an Actor, and it can be a user, a device, or other system • Each use case describes a possible scenario • Of how the external entity interacts with the system • The use case is represented as a drawing plus a brief textual sketch of how the function is performed

12. Uses Cases • The system functionality • The use cases in their entirety constitute a complete description of all possible ways using the system by all possible entities • The collection of use cases paints a picture of the complete functionality of the system • Use Cases are useful for requirements • They are particularly useful for communicating with customers, designers and testers • Customers read them to make sure the desired functions • Designers use them to lay out the objects in appropriate places • Use cases feed all stages of the life cycle, acting as a means of communication across all roles

13. Uses Cases • Use Case Diagrams • They are a graphical representation of system functions • They have 4 elements : actors, extensions, and uses • An actor is a role that an entity plays with respect to the system • The case is a depiction of some aspect of the system functionality that is visible to the actors • An extension extents a use case to illustrate a different or deeper perspective • A use is a reuse of an already defined use case • See Fig 6.5, p.266

14. Uses Cases • Use of the Use Case • We use the use case to help to understand the customer and the problems • For each use case diagram, we write a scenario script to describe the system functionality • Example : see Fig 6.6, p.267, for the extension of Fig 6.5, and Fig 6.7, p.267, for the further extension of Fig 6.6, and Fig 6.8, p.268, for the further extension of Fig 6.7 • In each case, we think a participant as a role • We use a set of questions to help to identify participants • The result is a comprehension description of how the system will work • Including its interactions with system beyond its boundary

15. Uses Cases • Alternative ways of system requirements • Sometimes problems are hidden with requirements written in natural language • When we translate them to use cases, these problems surface. • It is a good check on the requirements quality • Once we have use cases, we can examine them further to find existing and potential problems, and • We can ask questions (see p.268-269) for doing so.

16. 6.4 Representing OO: Using UML • UML : Unified Modeling Language • Is a notational approach that is popular for describing OO solutions • OMG (Object Management Group) has adopted UML as the OO notational standard • UML can be used to visualize, specify or document a problem and its solutions • UML diagrams include dynamic view, the static view, restrictions and formalization of systems

17. UML in the Process • UML being used throughout the process • Fig 6.9, p.270, shows how UML can be used in requirements specification, design and coding. • In the requirements process, workflow diagrams define the entire business process • By describing the activities that the business will perform • Use case diagram can also describe the system to be built by describing the general processes that the system must perform • These diagrams can be supplemented with the UML object models

18. UML in the Process • UML being used throughout the process • Once the requirements are in good shape, design begins with UML state diagram and the activity diagram • The activity diagrams display all the activities that can occur in the system as the values of objects change • In concert with the activity diagrams, we use state diagrams to show all possible states that object can take • Object diagrams describes how each class is associated with others, including inheritance relationships

19. UML in the Process • UML being used throughout the process • Sequence diagrams and collaboration diagrams • The interactions among classes are illustrated using interaction diagrams of these 2 types • Sequence diagrams show how messages flow from one object to another, formalizing the information descriptions of events in the requirements • Collaboration diagrams use object and sequence information to show the flow of events between objects • Finally, the design can be implemented using • Package diagrams show how classes are divided into models • Component diagrams reflect the final system modules • Deployment diagrams show the network links involved with the application being built

20. 6.5 OO System Design • We begin with use of UML class diagrams • These diagrams describe the object types and their static relationships • In particular, we want to depict associations among objects and class and subclass relationships • We use the diagrams to illustrate the attributes of each object, their individual behaviors, and restrictions on each class or object

21. Requirements elicitation • We try to extract nouns • To look for particular items that can suggest object classes, we seek • Structures, external systems, devices, roles, operating procedures, places, organizations, … • We can use questions as guidelines about what to include in the list of candidate classes • See questions listed on P.272

22. Requirements elicitation • We try to identify behaviors • From the requirements statements, we extract verbs • We can look for particular items that suggest behaviors • Imperative verbs, passive verbs, actions, events, roles, operating procedures, services provided by various organizations • The behaviors will become actions and responsibilities taken by a class or object, or actions done to a class or object

23. Requirements elicitation • Use UML boxes to describe classes • See Fig 6.10, p.274 • It includes: class name, attributes, operations • See Fig 6.11, p .275 for Inheritance relationship • Class Relationships • Relationships usually consist of 4 types • Generalization, association, aggregation, composition

24. Requirements elicitation • Class Relationships • generalization • The super-class generalizes the subclass • Association • 2 classes are associated when they occur together, and when the relationship must be preserved for some period of time • The association is depicted with a straight line, and • The numbers at each end show the cardinality associated with each member of the relationship

25. Requirements elicitation • Class Relationships • composition • An composition is recognized when one class is part of another class • We denote the part-of relationship using a line that ends in a filled diamond • The numbers at each end show the cardinality associated with each member of the relationship • Aggregation • An unfilled diamond shows an aggregation that is not an inheritance relationship • See Fig 6.12, p.275 and Fig 6.13,p.276

26. Requirements elicitation • Other ways of associating classes • Association can be enhanced with • Associative class that depicts the association relations in further details • Qualified association makes the related class object qualified with some attribute values • See Fig 6.14, p.276 • See example of Fig 6.15, p.277 • And Fig 6.16, p.278 • And Fig 6.17, p.279, with cardinality added to the diagram

27. Other UML Diagram • Class Description Template • Each Class is described in more detail using it • See example on p.278-280 • The template lays the groundwork for the program design • It includes information essential for programmers to implement the design as code • Private interface • Public interface

28. Other UML Diagram • Package Diagram • The package diagrams show the dependencies among classes as they belong to different packages • We say that 2 items are dependent if changes to the definition of one may cause changes to the other • 2 packages are dependent if there is a dependency between classes in each of the packages • In this way, we can view a system as a small collection of packages

29. Other UML Diagram • Package Diagram • See Fig 6.18, p.281 for package diagram • The dashed arrows shows the package dependencies • As you can see, package diagram gives a high level overview of the system and notes the high level dependencies

30. Other UML Diagram • Interaction Diagrams • Used to describe how operations and behaviors are handled by the objects in the design • We usually generate one interaction diagram from each use case • There are 2 kinds of interaction diagrams • Sequence diagram shows the sequence in which activities occur • Object’s lifeline; an arrow between 2 lifelines represent a message; a * on the arrow indicates that the message is sent many times. Self-delegation • See Fig 6.19, p.282

31. Other UML Diagram • Interaction Diagrams • Collaboration diagram shows how the objects are connected statically, based on use case • Objects are icons; arrows used to depict messages; the sequence of messages is indicated by a numbering scheme • See Fig 6.20, p.282 • Dynamic Models • State diagrams and activity diagrams

32. Other UML Diagram • State Diagrams • State diagram shows the possible states an object can take, the events that trigger the transition from one state to another, and actions that result from each change • A State diagram is needed only for classes that exhibit dynamic behavior • The state diagram is similar to state transition diagram, see Fig 6.21,p.283, Fig 6.22,p.284, Fig 6.23,p.284 • Start state is represented by a black dot • End state is a smaller black dot inside a white dot • A rectangle represents a state • An arrow shows the transition from one state to another • A condition is noted with a bracket expression next to an arrow

33. Other UML Diagram • Activity Diagrams • Activity diagram is used to model the flow of procedures or activities in a class • It uses a decision node to represent conditional choice • See Fig 6.24, p.285 for notions used • Start node is represented by a black node • The end node is a smaller black dot inside a white dot • A rectangle represents a state • Arrows used to show transitions from one state to another • Horizontal bar allows broadcasting events and parallel activities to be represented • See Fig 6.25, p.285

34. 6.6 OO Program Design • Program design begin with classes & objects • But we must embellish and modify them to include more items, including • Reused components, reusable components, user interfaces, data structure and management details • And there are likely more than in the system design • In this stage, we must make more detailed decisions about the data structures and each object’s interfaces • That is, the levels of abstraction in this stage are different from that of during the system design stage • The interface is a collection of operations • It also allow us to take advantages of polymorphism or dynamic binding.

35. OO Program Design • Design Implementation • The choice of object composition and class inheritance • Inheritance is often called white-box reuse • Composition is often called black-box reuse • It enforces the encapsulation built into the system design • One way to moderate the effects of composition is to allow an object to delegate its operations to another object • The object interfaces must be designed very carefully • Each construction paradigm has advantages and disadvantages

36. Design Aids • Design for Change • The only guideline that applies to all systems is this : Design for Change • There are many OO-related techniques to help make the system more flexible and maintainable • A toolkit is a set of related, reusable classes that provide a well-defined set of functionality • Frameworks and patterns are also design aids • Focused more on design reuse than on code reuse • Example : MVC (Model-View-Controller) pattern • A framework is a reuse of part of a domain-specific design • More specialized than a design pattern • Framework can be expanded to suit the specific problem : frozen points, hot points

37. User Interface Design • Several aspects of OO Program Design • In UI program design, we must consider issues • Defining the humans who will use the system • Developing scenarios of the UIs • Designing a hierarchy of user commands • Refining the sequence of interactions • Designing the relevant classes • Integrating the classes • The 1st step in UI design is to layout the interaction on paper • see Fig 6.26, p.289 • see Fig 6.27, p.290

38. Data Management Design • Address ways to store and recover persistent objects • It takes into account the system requirements concerning performance and space • We can perform this task in 4 steps • Identify the data, data structures and relationships among them • Design services to manage them • Find tools to implement them • Design classes to oversee the management functions • An OO solution can use conventional file or relational databases • See Fig 6.28, p.291 • It might be needed to set up tables and extra tables to capture the relationships

39. Task Management Design • Task management is a critical part • We must scrutinize the requirements and determine how to coordinate the activities the system is to perform • A task refers a process in the system • It may be event-driven or time-driven • A task management is designed in 4 steps • Identify the task and classify them as event- or time-driven • Determine the priorities for the tasks • Create a task to coordinate all other tasks • Design the objects for each task and their relations

40. Task Management Design • Task management is a critical part • Each task must be defined formally • to facilitate the programmers understanding for better implementation • For each task, we include • Task name, description, priority, services, communication mechanism, and place in the hierarchy • Example see p.291 • Design pattern can assist us in deciding how to manage tasks • See design patterns for task management • see Sidebar 6.3

41. Task Management Design • The Observer Pattern • 4 major constructs • A subject :know its registered observers, and provides notice to the observers once something happens • An observer : can register to a subject to express its interesting for a subject • a concrete subject : store a state of interest and notify the observers when the state changes • a concrete observer : once get notified of the change of the state, get the interested state • See Fig 6.29,p.293, Fig 6.30, p.293

42. 6.7 OO Measurement • An OO implementation needs measure • Such as coupling and cohesion • And design complexity • This section will discuss the ways to measure characteristics of OO implementation

43. OO Size Measures • Number of Scenario Scripts (NSS) • It measures the number of scenario scripts in use cases • It is correlated with application size and number of test cases • This measure is useful in at lest 2 ways • As a size measure to predicate project effort or duration • As a test case estimate, it helps team to prepare test cases and allocate resources

44. OO Size Measures • Number of Key Classes • It is intended to evaluate high-level design, suggesting effort needed to build the system • It also tally the number of support classes • This is targeted at low level design • The average number of support classes per key class and number of subsystems • These are useful for tracking the structure of the system • Class size is the sum of the total number of operations and number of attributes • Here we count inherited features as well as features in the particular class

45. OO Size Measures • Specialization Index (SI) • The number of operations overridden by a subclass (NOO) and the number of operations added by a subclass • To evaluate effects of inheritance • From these, we define the Specialization Index • SI = ( NOO × level ) / (total class methods) • Each of these metrics cab be applied during the different stages of development • See Table 6.5, p.295 • See Fig 6.32, p.296

46. OO Design Measures • Design Measures focused on Design than on size • Measuring the coupling between objects, the response for a class, the lack of cohesion in methods • Table 6.6 shows where these metrics can be collected

47. OO Design Measures • Weighted Methods per class • Table 6.6 shows what are these metrics and where they can be collected • Weighted methods per class = ∑ci • Ci is the method complexity • If the complexity of each method is 1, it is simply the number of per class • The number of methods and the complexity of the methods suggest the amount of time and effort needed to build and maintain the class • The larger the number of methods, the more effort and the greater the impact on the children of the class

48. OO Design Measures • Depth of inheritance • It is the maximum length of the path in the hierarchy of the class inheritance • From the class to the root of the inheritance tree • This characteristic makes the class harder to understand and harder to maintain • The number of children • Is the number of immediate subclasses subordinate to the given class • It is another indicator of the ease of maintenance, testing and reuse

49. OO Design Measures • Coupling between classes • It is the number of related classes of a given class • We want to maximum the independence of each class

50. OO Design Measures • Lack of Cohesion in method (LCOM) • It is more complicated • Given a class C with n methods, M1,…,Mn • Suppose {Ii} is the set of instance variables used by the method Mi • There are n such sets, one for each method • We define P to be the collection of pairs (Ir,Is) • Where Ir and Is share no common members • We define Q to be the collection of pairs (Ir,Is) • Where Ir and Is share at least one common members