1 / 74

ECE 355: Software Engineering

ECE 355: Software Engineering. CHAPTER 2 Unit 4 (Part 1). Presentation material based on past ECE 355 notes by Prof. K. Czarneszki. Course outline. Unit 1: Software Engineering Basics Unit 2: Process Models and Software Life Cycles Unit 3: Software Requirements

dobry
Download Presentation

ECE 355: Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECE 355: Software Engineering CHAPTER 2 Unit 4 (Part 1) Presentation material based on past ECE 355 notes by Prof. K. Czarneszki.

  2. Course outline • Unit 1: Software Engineering Basics • Unit 2: Process Models and Software Life Cycles • Unit 3: Software Requirements  Unit 4: Unified Modeling Language (UML) • Unit 5: Design Basics and Software Architecture • Unit 6: OO Analysis and Design • Unit 7: Design Patterns • Unit 8: Testing and Reliability • Unit 9: Software Engineering Management and Economics

  3. What does the system do in response to an event? • In the traditional approach, • a system is viewed as a collection of processes, • processes interact with data elements, and • processes accept inputs and produce outputs. • In the OO approach, • a system is a collection of interacting objects, • objects interact with the outside world and with each other, and • objects send and respond to messages.

  4. Unified Modeling Language (UML) Sources: Largely based on a series of 3 UML Tutorials from OMG, see http://www.omg.org/uml/ UML Specification Document v1.4, see http://www.omg.org/uml/ “The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999)

  5. UML - Outline • Introduction • Behavioral modeling • Structural modeling

  6. What is UML • A graphical language for • visualizing, • specifying, • constructing, and • documenting the artifacts of distributed object systems. • It is not a OO method, but a OO modeling notation only

  7. A brief history of UML • 1989-1994: 50+ OO methods • Clearly prominent methods • Jacobson’s OOSE: support for use cases to capture requirements • Booch: expressive during design/construction • Rumbaugh’s OMT: analysis+ data intensive systems • 1994: Rumbaugh joined Booch at Rational • 1995: Jacobson joined Rational • 1996: UML version 0.9 • 1997: Standardized by OMG • UML 1.1…1.4 (2.0)

  8. UML Goals • Define an easy-to-learn but semantically rich visual modeling language • Unify the Booch, OMT, and Objectory modeling languages • Include ideas from other modeling languages • Data modeling (e.g., ERD) • Business modeling (e.g., workflow modeling) • ... • Incorporate industry best practices • Address contemporary software development issues • scale, distribution, concurrency, executability, etc. • Provide flexibility for applying different processes • Enable model interchange and define repository interfaces

  9. Unifying Concepts • classifier-instance dichotomy • e.g. an object is an instance of a class ORa class is the classifier of an object • specification-realization dichotomy • e.g. an interface is a specification of a class ORa class is a realization of an interface • analysis-time vs. design-time vs. run-time • modeling phases (“process creep”) • usage guidelines suggested, not enforced

  10. Conceptual model of UML UML Building blocks Common mechanisms Rules name, scope, visibility Diagrams Things Relations Class Object Use case Sequence Collaboration Statechart Activity Component Deployment Dependency Association Generalization Realization Structural Behavioral Grouping Annotate Class Interface Active class Component Node Interaction State machine Package Note Use case Collaboration

  11. Summary of diagram kinds in UML (nine concrete kinds) • Structural diagrams • Static structural diagrams • Class diagrams • Object diagrams • Implementation diagrams • Component diagrams • Deployment diagrams • Behavior diagrams • Use case diagrams • Interaction diagrams • Sequence diagrams • Collaboration diagrams • Statechart diagrams • Activity diagrams

  12. What will be covered • Will learn some syntax, semantics, and modeling techniques • Further details of UML can be found in the supplementary text: • Bennet, Sketon, Lunn: UML, Schaum’s Outline Series, McGraw-Hill, 2001 • “The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999) • And in the UML Specification Document and other resources available from http://www.omg.org/uml/

  13. UML - Outline • Introduction • Structural modeling • Behavioral modeling • Use case diagrams • Interaction diagrams • Sequence diagrams and collaboration diagrams • More about collaborations • State diagrams • Activity diagrams

  14. Use Cases • Use-case model describes ways in which an application is to be used. • Requirements are often naturally expressed as an interaction between app and user. • A use case consists of an interaction between actors (user/external systems) and the application.

  15. Use Case Diagram Tour • Shows use cases, actor and their relationships • Use case internals can be specified by text and/or interaction diagrams • Kinds • use case diagram • use case description

  16. Use case diagrams • Diagram of use cases, actors & relationships • Show outwardly visible services. • Uses (2 ways) • Model the context of a system. • Which actors interact with the system. • Model requirements of a system. • What the system should do.

  17. Use Case Modeling: Core Elements

  18. Use Case Modeling: Core Relationships <<extend>>

  19. Use Case Modeling: Core Relationships (cont’d) <<include>>

  20. Use Case Diagram The same person (or system) may play the roles of a number of actors at the same time Billing System Fig. 3-53, UML Notation Guide

  21. Use Case Relationships

  22. Use Case Relationships

  23. Use Case Relationships <<extend>> (set priority) Place rush order Place order Extension points set priority <<include>> Check password Track order <<include>> Validate user Retinal scan

  24. Use Case Model Actors Use Cases ... Use-Case Descriptions Use Case Model: Use Case Diagrams and Descriptions • Name • Brief description • Flows of Events • Preconditions • Postconditions • Interaction, activity and state diagrams • Relationships • Use-Case diagrams • Special requirements • Other diagrams

  25. Flow of events in a use case • Has one normal, basic flow (“Happy Path”) • Several alternative flows • Regular variants • Odd cases • Exceptional flows handling error situations “Happy Path”

  26. Use Case Description: Change Flight • Actors: traveler, client account db, airline reservation system • Preconditions: • Traveler has logged on to the system and selected ‘change flight itinerary’ option • Basic course • System retrieves traveler’s account and flight itinerary from client account database • System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. • System asks traveler for new departure and destination information; traveler provides information. • If flights are available then • … • System displays transaction summary. • Alternative courses • If no flights are available then …

  27. When to model use cases • Model user requirements with use cases. • Model test scenarios with use cases. • If you are using a use-case driven method • start with use cases and derive your structural and behavioral models from it. • If you are not using a use-case driven method • make sure that your use cases are consistent with your structural and behavioral models.

  28. Use-Case Model Design Model Implementation Model Test Model Use case model drives the work from analysis through test Verified by Realized by Implemented by

  29. Model requirements of a system • Establish the context (actors). • Consider behavior expected by an actor. • Name the common behaviors as use cases. • Create use case descriptions. • Factor common behavior into new use cases • Model use cases, actors and their relationships in a use case diagram.

  30. Use Case Modeling Tips • Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers • When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams • Factor out common usages that are required by multiple use cases • If the usage is required use <<include>> • If the base use case is complete and the usage may be optional, consider use <<extend>> • A use case diagram should • contain only use cases at the same level of abstraction • include only actors who are required • Large numbers of use cases should be organized into packages

  31. Using use-cases • First describe flow of events for a use case in text. • With refinement of your understanding, use interaction diagrams to specify these flows. • Use one diagram to specify the main flow. • Use variations of the main diagram to specify exceptional cases.

  32. Further reading • Book “Writing Effective Use Cases” by Alistair Cockburn (Addison-Wesley, 2000) • For a use case description template and other materials see http://www.usecases.org/

  33. UML - Outline • Introduction • Structural modeling • Behavioral modeling • Use case diagrams • Interaction diagrams • Sequence diagrams and collaboration diagrams • More about collaborations • State diagrams • Activity diagrams • Advanced modeling

  34. What are interactions? • Interaction: describes a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instances • The communications are partially ordered (in time)

  35. Interactions: Core Elements Construct Description Syntax Instance (object, data value, component instance etc.) An entity with a unique identity and to which a set of operations can be applied (signals be sent) and which has a state that stores the effects of the operations (the signals). name attr values Action A specification of an executable statement. A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction. textual

  36. Interactions: Core Elements (cont’d) Construct Description Syntax Stimulus A communication between two instances. Operation A declaration of a service that can be requested from an instance to effect behavior. textual Signal A specification of an asynchronous stimulus communicated between instances. «Signal»Name parameters

  37. Interaction: Core Relationships Construct Description Syntax Link A connection between instances. Attribute Link A named slot in an instance, which holds the value of an attribute. textual

  38. Interaction diagram tour • Show interactions between instances in the model • graph of instances (possibly including links) and stimuli • existing instances • creation and deletion of instances • Kinds • sequence diagram (temporal focus) • collaboration diagram (structural focus)

  39. Sequence Diagram Collaboration Diagram x y z 1.1: a1.2: c x y a b 1.1.1: b c z Interaction diagrams

  40. UML - Outline • Introduction • Structural modeling • Behavioral modeling • Use case diagrams • Interaction diagrams • Sequence diagrams and collaboration diagrams • More about collaborations • State diagrams • Activity diagrams • Advanced modeling

  41. object symbol name : Class other lifeline stimulus name (…) activation new (…) : Class delete return create Sequence diagram

  42. 3.7 *[1..5]: move (5, 7) iteration sequence number return value message name argument list 3.7 [ z > 0 ]: move (5, 7) condition Arrow label predecessor sequence-expression return-value := message-name argument-list move (5, 7) Sequence numbering schema: 1 : actionA 1.1. firstSubactionOfActionA 1.2. secondSubactionOfActionA 1.3. thirdSubactionOfActionA 2 : actionB 2.1. firstSubactionOfActionB 2.1. secondSubactionOfActionB ... 3.7.4: move (5, 7) 3.1: res := getLocation (fig)

  43. Procedure call or other kind of nested (synchronous) flow of control (caller waits for the callee to return) Asynchronous flow of control (no waiting, no nesting, caller returns immediately) Return Different kinds of arrows

  44. Nested Flow Asynchronous flow Nested Flow teller : Order : Article teller caller exchange : Order : Article callee getValue lift receiver price getValue dial tone price dial digit getName dial digit getName ringing tone ringing signal lift receiver Example: Different Arrows

  45. value [ x > 0]: getValue () getValue () iterate () Condition, recursion, etc. calculator filter [ x < 0]: transform ()

  46. Sequence diagram with concurrent objects

  47. object symbol link symbol standard stereotype stimulus window : Controller : Window window «parameter» standard stereotype 1: displayPositions (window) standard constraint 1.1.3.1 add (self) wire contents {new} 1.1 *[i := 1..n]: drawSegment (i) {new}: Line «local» line wire :Wire 1.1.2: create (r0, r1)1.1.3: display (window) standard stereotype «self» standard constraint 1.1.1a: r0 := position () 1.1.1b: r1 := position () left : Bead right : Bead Collaboration diagram redisplay ()

  48. Collaboration Diagram with stereotype links

  49. When to Model Interactions • To specify how the instances are to interact with each other. • To identify the interfaces of the classifiers. • To distribute the requirements.

  50. Interaction modeling tips • Set the context for the interaction. • Include only those features of the instances that are relevant. • Express the flow from left to right and from top to bottom. • Put active instances to the left/top and passive ones to the right/bottom. • Use sequence diagrams • to show the explicit ordering between the stimuli • when modeling real-time • Use collaboration diagrams • when structure is important • to concentrate on the effects on the instances

More Related