Modern Systems Analysis and Design Fourth Edition Jeffrey

Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Appendix 3 Object-Oriented Analysis and Design © 2005 by Prentice Hall

Learning Objectives 1. Define events, state transitions, and sequence 2. 3. 4. 5. 6. diagrams. Describe concepts and principles of objectorientation. Describe activities of the different phases of objectoriented development. Compare object-oriented modeling with traditional systems development approaches. Develop dynamic models with state, interaction, and activity diagrams. Model real-world applications with UML. Appendix 3 -2 © 2005 by Prentice Hall

The Object-Oriented 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 Appendix 3 -3 © 2005 by Prentice Hall

Object oriented cycle is like an onion, evolving from abstract to detailed, from external qualities to system architecture and algorithms. Appendix 3 -4 © 2005 by Prentice Hall

Object-Oriented Analysis Procedure for Object-Oriented Systems Analysis Step 1. Identify the business events and make an event table. Step 2. Identify the use cases and produce a use case diagram for the system. Step 3. Write a use case narrative describing the system’s response to each business event. Step 4. Draw a system sequence diagram for each use case scenario. Step 5. Produce a domain model showing the concepts, attributes, and associations in the problem domain of the system. Step 6. Write a contract for each system operation. Appendix 3 -5 © 2005 by Prentice Hall

Object-Oriented Design Procedure for Object-Oriented Program Design Step 1. Step 2. Step 3. Step 4. Step 5. Step 6. Step 7. Appendix 3 -6 Produce an interaction diagram for each system operation identified during analysis. Produce a design class diagram showing the operations from the interaction diagrams. Specify the signature and the algorithm for each operation. Design the graphical user interface. Define the interface to the presentation layer. Define the interface to the storage layer. Place the classes in packages. © 2005 by Prentice Hall

Object-Oriented Deliverables and Outcomes 1. 2. 3. 4. 5. 6. 7. The ability to tackle more challenging problem domains Improved communication among users, analysts, designers, and programmers Increased consistency among analysis, design, and programming activities Explicit representation of commonality among system components Robust systems Reusability of analysis, design, and programming results Increased consistency among the models developed during object-oriented analysis, design, and programming Appendix 3 -7 © 2005 by Prentice Hall

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: n n n Appendix 3 -8 Use cases Class diagrams State diagrams Sequence diagrams Activity diagrams © 2005 by Prentice Hall

Use Cases Revisited A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users Full functioning for a specific business purpose Appendix 3 -9 © 2005 by Prentice Hall

UML Use Case Diagram Symbols Use Case Actor Boundary Connection <<include>> Include relationship Extend relationship Appendix 3 -10 © 2005 by Prentice Hall <<extend>>

What is an Actor? Actor is an external entity that interacts with the system. Most actors represent user roles, but actors can also be external systems. An actor is a role, not a specific user; one user may play many roles, and an actor may represent many users. Appendix 3 -11 © 2005 by Prentice Hall

What is a Boundary? A boundary is the dividing line between the system and its environment. Use cases are within the boundary. Actors are outside of the boundary. Appendix 3 -12 © 2005 by Prentice Hall

What is a Connection? A connection is an association between an actor and a use case. Depicts a usage relationship Connection does not indicate data flow Appendix 3 -13 © 2005 by Prentice Hall

What is an <<extend>> Relationship? A connection between two use cases Extends a use case by adding new behavior or actions Specialized use case extends the general use case Appendix 3 -14 © 2005 by Prentice Hall

Appendix 3 -15 © 2005 by Prentice Hall

What is an <<include>> Relationship? A connection between two use cases Indicates a use case that is used (invoked) by another use case Links to general purpose functions, used by many other use cases Appendix 3 -16 © 2005 by Prentice Hall

Appendix 3 -17 © 2005 by Prentice Hall

Written Use Cases Document containing detailed specifications for a use case Contents can be written as simple text or in a specified format Appendix 3 -18 © 2005 by Prentice Hall

Appendix 3 -19 © 2005 by Prentice Hall

Object Modeling Using Class Diagrams Object-oriented approach Based on Unified Modeling Language (UML) Features n n Objects and classes Encapsulation of attributes and operations Polymorphism Inheritance Appendix 3 -20 © 2005 by Prentice Hall

Objects Object: an entity with a well-defined role in an application Each object has: n n n State: encompasses the attributes, their values, and relationships of an object Behavior: represents how an object acts and reacts Identity: uniqueness, no two objects are the same Appendix 3 -21 © 2005 by Prentice Hall

Classes Class: a logical grouping of objects with similar attributes and behaviors Operation: a function or service provided by all instances of a class Encapsulation: the technique of hiding internal implementation details of an object from external view Appendix 3 -22 © 2005 by Prentice Hall

Class Diagram A diagram showing the static structure of an object-oriented model UML classes are analogous to E-R entities Appendix 3 -23 © 2005 by Prentice Hall

Types of Operations Constructor n Creates a new instance of a class Query n Accesses the state of an object Update n Alters the state of an object Scope n Applies to a full class rather than an individual instance Appendix 3 -24 © 2005 by Prentice Hall

Representing Associations Association: a relationship among instances of object classes Association role: the end of an association where it connects to a class Multiplicity: indicates how many objects participate in a give relationship Appendix 3 -25 © 2005 by Prentice Hall

UML associations are analogous to E-R relationships. UML multiplicities are analogous to E-R cardinalities. Appendix 3 -26 © 2005 by Prentice Hall

roles multiplicities Multiplicity notation: 0. . 10 means minimum of 0 and maximum of 10 1, 2 means can be either 1 or 2 * means any number Appendix 3 -27 © 2005 by Prentice Hall

Association Class An association with its own attributes, operations, or relationships UML association classes are analogous to E-R associative entities. Appendix 3 -28 © 2005 by Prentice Hall

Derived Attributes, Associations, and Roles Derived attributes are calculated based on other attributes Derived items are represented with a slash (/). Appendix 3 -29 © 2005 by Prentice Hall

Generalization Superclass-subclass relationships Subclass inherits attributes, operations, and associations of the superclass Types of superclasses n n Abstract: cannot have any direct instances Concrete: can have direct instances Appendix 3 -30 © 2005 by Prentice Hall

Generalization and inheritance implemented via superclass/subclasses in UML, supertypes/subtypes in E-R Appendix 3 -31 © 2005 by Prentice Hall

Polymorphic Operations The same operation may apply to two or more classes in different ways Abstract operations n n defined in abstract classes defined the protocol, but not the implementation of an operation Methods n the implementation of an operation Appendix 3 -32 © 2005 by Prentice Hall

Abstraction: Student is an abstract class and calctuition() is an abstract operation (italicized) Polymorphism: Here, each type of student has its own version of calc-tuition() Class scope: tuition. Per. Cred is a class-wide attribute Appendix 3 -33 © 2005 by Prentice Hall

Aggregation and Composition Aggregation n A part-of relationship between a component and an aggregate object Composition n An aggregation in which the part object belongs to only one aggregate object and lives and dies with the aggregate object Appendix 3 -34 © 2005 by Prentice Hall

Aggregation is represented with open diamonds Composition is represented with filled diamonds Appendix 3 -35 © 2005 by Prentice Hall

Appendix 3 -36 © 2005 by Prentice Hall

Dynamic Modeling Representation of activities that occur throughout the lifetime of a system Types of UML dynamic models n n n State diagram: state changes within an object Sequence diagram: time-sequenced interactions between objects Activity diagram: flow of control between activities within an object Appendix 3 -37 © 2005 by Prentice Hall

State Diagrams State n n 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 n 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 n Something that takes place at a certain point in time, triggering a state transition Appendix 3 -38 © 2005 by Prentice Hall

Guard condition Action Guard condition A transition is labeled with a guard condition and/or an action, separated with a forward slash / State diagram: a model of the states of a single object and the events that cause the object to change from one state to another Appendix 3 -39 © 2005 by Prentice Hall

Diagramming Substates and Decomposing States A state can be expanded into substates using nested state diagrams, similar to expansion of processes in different levels of DFDs. Appendix 3 -40 © 2005 by Prentice Hall

Diagramming Substates and Decomposing States An event can be expanded into using nested state diagrams, and may involve substates and subtransitions and events. Appendix 3 -41 © 2005 by Prentice Hall

Dynamic Modeling: Sequence Diagrams A depiction of the interaction among objects during certain periods of time Elements of a sequence diagram n n Objects: represented by boxes at top of diagram Lifeline: the time during which an object exists Activation: the time period during which an object performs an operation Messages: means by which objects communicate with each other Appendix 3 -42 © 2005 by Prentice Hall

Types of Messages in Sequence Diagrams Synchronous message n The caller must wait for the receiving object to finish executing the called operation before it can resume execution itself Asynchronous message n The caller can resume execution right after sending the message, without waiting for the receiver to complete Simple message n A message that transfers control from the sender to the recipient without describing the details of the communication 20. 43 Appendix 3 -43 © 2005 by Prentice Hall

object lifeline message time Appendix 3 -44 activation © 2005 by Prentice Hall

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 Appendix 3 -45 © 2005 by Prentice Hall

Elements of Activity Diagrams Activity: a behavior that an object carries out while in a particular state Transition: a movement from one activity or state to another Branch: a diamond symbol containing a condition whose results provide transitions to different paths of activities Synchronization bar: horizontal or vertical bars denoting parallel or concurrent paths of activities n n Fork: the beginning of parallel activities Join: the end of parallel activities Swimlanes: columns representing different organizatonal units of the system Appendix 3 -46 © 2005 by Prentice Hall

branch activity synchronization bar swimlane Appendix 3 -47 © 2005 by Prentice Hall

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 n A diagram that shows the software components or modules and their dependencies Deployment Diagram n A diagram that shows how the software components, process and objects are deployed into the physical architecture of the system Appendix 3 -48 © 2005 by Prentice Hall

Appendix 3 -49 © 2005 by Prentice Hall

Summary In this chapter you learned how to: 1. 2. 3. 4. 5. 6. Define events, state transitions, and sequence diagrams. Describe concepts and principles of objectorientation. Describe activities of the different phases of object -oriented development. Compare object-oriented modeling with traditional systems development approaches. Develop dynamic models with state, interaction, and activity diagrams. Model real-world applications with UML. Appendix 3 -50 © 2005 by Prentice Hall