Lecture 8 Object-Oriented Analysis and Design 20.1 COSC4406: Software Engineering

Learning Objectives Key terms Key terms Use Case Use Case Object Object Object class Object class State State Behavior Behavior Operation Operation Encapsulation Encapsulation Constructor Operation Constructor Operation Query Operation Query Operation Update Operation Update Operation Association Association Multiplicity Multiplicity Abstract Class Concrete Class Class-Scope attribute Abstract operation Method Polymorphism Overriding Aggregation Composition Event State transition Sequence diagram 20.2

Learning Objectives Discuss the concepts and principles underlying the object-oriented approach Discuss the concepts and principles underlying the object-oriented approach Describe the activities in the different phases of the object-oriented development life cycle Describe the activities in the different phases of the object-oriented development life cycle State the advantages of object-oriented modeling versus traditional systems development approaches State the advantages of object-oriented modeling versus traditional systems development approaches Learn to develop requirements models using use- case diagrams Learn to develop requirements models using use- case diagrams Learn to use class diagrams to develop object models of the problem domain Learn to use class diagrams to develop object models of the problem domain Learn to develop dynamic models using state, interaction and activity diagrams Learn to develop dynamic models using state, interaction and activity diagrams Model real-world applications using UML diagrams Model real-world applications using UML diagrams 20.3

RoadMap for Detailed (“D-”) Requirements 1. Select organization for D-requirements 3a. Obtain D-requirements from C-requirements & customer 3b. Outline test plans 4. Validate with customer 5. Release - when unit approved by customer... Apply customer feedback In parallel... 3c. Inspect 2. Create sequence diagrams from use cases -- Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

RoadMap for Detailed (“D-”) Requirements using the OO style 1. Obtain domain classes & objects from sequence diagrams 2. Add additional essential domain classes Inspect the resulting collection of classes 3 For each class, specify the required attributes specify the required functionality specify the specific required objects specify how its objects react to events draft test plans for each inspect the results 4. Inspect against C-requirements 5. Verify with customer where possible When complete: 6. Release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Functional requirements the application's functionality 2. Non-functional requirements 2.1 Performance 2.1 Performance –speed –capacity (traffic rates) –memory usage RAMdisk 2.2 Reliability and availability 2.2 Reliability and availability 2.3 Error handling 2.3 Error handling Types of Requirements 1/2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

2.4 Interface requirements 2.4 Interface requirements how the application interacts with the user, and with other applications 2.5 Constraints 2.5 Constraints –accuracy –tool and language constraints e.g. “FORTRAN 88 must be used” –design constraints –standards to be used –hardware platforms to be used 3. Inverse requirements what the application does not do Types of Requirements 2/2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Write a Detailed Requirement 1 1. Classify requirement as functional or non-functional –IEEE SRS prompts for most non-functional –select method for organizing functional requirements 2. Size carefully –a functional requirement corresponds ± to a method –too large: hard to manage –too small: not worth tracking separately 3. Make trace-able if possible –ensure suitable for tracking through design and implementation 4. Make testable –sketch a specific test that establishes satisfaction Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Write a Detailed Requirement 2 5. Make sure not ambiguous –ensure hard to misunderstand intention 6. Give the requirement a priority –e.g., highest (“essential”); lowest (“optional”); neither (“desirable”) 7. Check that requirement set complete –for each requirement, ensure all other necessary accompanying requirements are also present 8. Include error conditions –state what’s specifically required for non-nominal situations –include programmer errors for critical places 9. Check for consistency –ensure that each requirement does not contradict any aspect of any other requirement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Ways of Organizing Detailed Requirements … Feature … Use case … Class … Function hierarchy … State by... Graphics reproduced with permission from Corel.

Introduction Object-Oriented systems development life cycle –Process of progressively developing representation of a system component (or object) through the phases of analysis, design and implementation –The model is abstract in the early stages –As the model evolves, it becomes more and more detailed

The Object-Oriented Systems Development Life Cycle Analysis Phase –Model of the real-world application is developed showing its important properties –Model specifies the functional behavior of the system independent of implementation details Design Phase –Analysis model is refined and adapted to the environment –Can be separated into two stages System design –Concerned with overall system architecture Object design –Implementation details are added to system design

The Object-Oriented Systems Development Life Cycle Implementation Phase –Design is implemented using a programming language or database management system Outcomes and Deliverables –Diagrams –Repository descriptions

The Object-Oriented Systems Development Life Cycle Benefits of OO modeling 1.The ability to tackle more challenging problem domains 2.Improved communication among users, analysts, designers and programmers 3.Increased consistency among analysis, design and programming activities 4.Explicit representation of commonality among system components 5.Reusability of analysis, design and programming results 6.Increased consistency among the models developed during object-oriented analysis, design, and programming

The Unified Modeling Language (UML) A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models Techniques and notations –Use cases –Class diagrams –State diagrams –Sequence diagrams –Activity diagrams

Use-Case Modeling Applied to analyze functional requirements of the system Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details Use Case –A complete sequence of related actions initiated by an actor Actor –An external entity that interacts with the system

Figure 20-2 Use-case diagram for a university registration system 20.19

Use-Case Modeling Developing Use-Case Diagrams –Use cases are always initiated by an actor –Use cases represent complete functionality of the system Relationships Between Use Cases –Use cases may participate in relationships with other use-cases –Two types Extends –Adds new behaviors or actions to a use case Include –One use case references another use case 20.20

Describe a user case By plain text –The objective –The actor that initiates it –The exchange of information between the actors

Object Modeling Class Diagrams Object –An entity that has a well-defined role in the application domain, and has state, behavior, and identity State –A condition that encompasses an object’s properties and the values those properties have Behavior –A manner that represents how an object acts and reacts Object Class –A set of objects that share a common structure and a common behavior 20.24

Object Modeling Class Diagrams Class Diagram –Class is represented as a rectangle with three compartments –Objects can participate in relationships with objects of the same class 20.25

Object Modeling Object Diagrams Object Diagram –A graph of instances that are compatible with a given class diagram; also called an instance diagram –Object is represented as a rectangle with two compartments Operation –A function or service that is provided by all the instances of a class Encapsulation –The technique of hiding the internal implementation details of an object from its external view 20.26

Object Modeling Object Diagrams Types of Operations –Query An operation that accesses the state of an object but does not alter the state –Update An operation that alters the state of an object –Scope An operation that applies to a class rather than an object instance, (No for C++, Java) –Constructor An operation that creates a new instance of a class 20.27

Figure 20-5 UML class and object diagrams (a) Class diagram showing two classes (b) Object diagram with two instances 20.28

Representing Associations Association –A relationship between object classes –Degree may be unary, binary, ternary or higher –Depicted as a solid line between participating classes Association Role –The end of an association where it connects to a class –Each role has multiplicity, which indicates how many objects participate in a given association relationship 20.29

Representing Association Classes Association Class –An association that has attributes or operations of its own, or that participates in relationships with other classes Figure 20-9 shows one example 20.33

To be continued Representing Derived Attributes, Derived Associations and Derived Roles Representing Generalization Interpreting Inheritance and Overriding Representing Multiple Inheritance Representing Aggregation Dynamic Modeling: State Diagrams Dynamic Modeling: Sequence Diagrams Dynamic Modeling: Activity Diagrams

Representing Derived Attributes, Derived Associations and Derived Roles Derived attributes, associations and roles can be computed from other attributes, associations or roles Shown by placing a slash (/) before the name of the element 20.37

Representing Generalization Generalization –Abstraction of common features among multiple classes, as well as their relationships, into a more general class Superclass –A generalized class that is composed of several subclasses Subclass –A class that has been specialized 20.39

Representing Generalization Discriminator –Shows which property of an object class is being abstracted by a generalization relationship Inheritance –A property that a subclass inherits the features from its superclass Abstract Class –A class that has no direct instances, but whose descendents may have direct instances Concrete Class –A class that can have direct instances 20.42

Representing Generalization Semantic Constraints among Subclasses –Overlapping A descendant may be descended from more than one of the subclasses –Disjoint A descendant may not be descended from more than one of the subclasses –Complete All subclasses have been specified. No additional subclasses are expected –Incomplete Some subclasses have been specified, but the list is known to be incomplete 20.43

Representing Generalization Class-scope Attribute –An attribute of a class which specifies a value common to an entire class, rather than a specific value for an instance. Abstract Operation –Defines the form or protocol of an operation but not its implementation Method –The implementation of an operation Polymorphism –The same operation may apply to two or more classes in different ways 20.45

Interpreting Inheritance and Overriding Overriding –Process of replacing a method inherited from a superclass by a more specific implementation of that method in a subclass –Three Types Overriding for Extension –Operation inherited by a subclass from its superclass is extended by adding some behavior Overriding for restriction –The protocol of the new operation in the subclass is restricted Overriding for optimization –The new operation is implemented with improved code by exploiting the restrictions imposed by a subclass 20.47

Representing Multiple Inheritance Multiple Classification –An object is an instance of more than one class –Use is discouraged and not supported by UML semantics Multiple Inheritance –Allows a class to inherit features from more than one superclass 20.49

Representing Aggregation Aggregation –A part-of relationship between a component object and an aggregate object –Example: Personal computer Composed of CPU, Monitor, Keyboard, etc Composition –A stronger form of aggregation –One component belongs to only one whole object 20.51

Dynamic Modeling: State Diagrams State –A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events –Shown as a rectangle with rounded corners State Transition –The changes in the attribute of an object or in the links an object has with other objects –Shown as a solid arrow –Diagrammed with a guard condition and action Event –Something that takes place at a certain point in time 20.55

Dynamic Modeling: Sequence Diagrams Sequence Diagram –A depiction of the interaction among objects during certain periods of time Activation –The time period during which an object performs an operation Messages –Means by which objects communicate with each other 20.59

Build a Sequence Diagram 1 1. Identify the use case whose sequence diagram you will build 2. Identify which entity initiates the use case –the user, or –an object of a class name the class name the object 3. Draw a rectangle to represent this object at left top –use UML object:Class notation 4. Draw an elongated rectangle beneath this to represent the execution of an operation 5. Draw an arrow pointing right from its top myObject :MyClass Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Build a Sequence Diagram 2 6. Identify which entity handles the operation initiated –an object of a class name the class name the object 7. Label the arrow with the name of the operation –don’t show return 8. Show a process beginning, using an elongated rectangle 9…… Continue with each new statement of the use case. MyObject :MyClass MyObject1 :MyClass1 My operation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Dynamic Modeling Sequence Diagrams Synchronous Message –A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself Simple Message –A message that transfers control from the sender to the recipient without describing the details of the communication 20.62

Sequence diagram for a class registration scenario with prerequisites 20.63

Process Modeling: Activity Diagrams Shows the conditional logic for the sequence of system activities needed to accomplish a business process Clearly shows parallel and alternative behaviors Can be used to show the logic of a use case 20.65

Analysis Versus Design Start with existing set of analysis model Progressively add technical details Design model must be more detailed than analysis model Component Diagram –A diagram that shows the software components or modules and their dependencies Deployment Diagram –A diagram that shows how the software components, process and objects are deployed into the physical architecture of the system 20.67

Summary Object-Oriented modeling approach –Benefits –Unified Modeling Language Use cases Class diagrams State diagrams Sequence diagrams Activity Diagrams Use-case modeling 20.70

Summary Object Modeling: Class Diagrams –Associations –Generalizations –Inheritance and Overriding –Aggregation Dynamic Modeling: State Diagrams Dynamic Modeling: Sequence Diagrams Analysis Versus Design 20.71