1 / 56

Roadmap

Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling. Roadmap. Lecture 1 rules for class, overview of the topics. Use case and use case diagram Break Challenges and visions for software modeling. Steps Before Coding.

stella
Download Presentation

Roadmap

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. Lecture 2: Session I: Basic Modeling Techniques Session II: Challenges and Visions for Software Modeling

  2. Roadmap Lecture 1 rules for class, overview of the topics • Use case and use case diagram • Break • Challenges and visions for software modeling

  3. Steps Before Coding

  4. Source of Requirements • Initial requirements come from the customer, by: • Documents, such as RFI/RFP • Meetings, reports • Advanced requirements come from the analysts, after studying scope and price • Feasibility (technological, organizational etc) • Prototypes • Final requirements are stabilized in an iterative process.

  5. Types of Requirements • Visible Functional Requirements • “The system will deliver cash to the customer” • “Cash will be delivered after card was taken out” • Qualitative Requirements • “The authorization process will take no more than 1 sec” • “The user interface will be easy to use” • Hidden Requirements • “Database maintenance processes will occur every night”

  6. Intro: Use Case and Use Case Diagram

  7. Use Cases as Means of Communication Customer Designer User The use case should stimulate a discussion about what the system should do, mainly with people who are outside of the development team.

  8. Use Case A use case is a contract of an interaction between the system and an actor. Use Case Diagram: an integration of use cases

  9. Use Case Diagram A use case diagram illustrates a set of use cases for a system, the actors, and the interactions between actors and use cases. A graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases.

  10. Use Case Diagram Objectives • Create a semi-formal model of the functional requirements • 2. Analyze and define: • Scope • External interfaces • Scenarios and reactions

  11. What makes a good Use Case Diagram? Lack of ambiguity - Each requirement must be interpreted in a single manner. Completeness - The collection of all use cases is everything that can be done to/with the system. Consistency - Requirements should not conflict with each other. If there are, tradeoffs must be detected and discussed. Avoid design - Requirements should raise a need, not answer it.

  12. Construct a Use Case Diagram

  13. Finding actors • External objects that produce/consume data: • Must serve as sources and destinations for data • Must be external to the system Humans Machines External systems Sensors

  14. Actor Relationships – Generalization/Specialization Define hierarchy for actors Notation The child actor inherits all use-cases associations Should be used if (and only if), the specific actor has more responsibility than the generalized one (i.e., associated with more use-cases)

  15. Association: Actor and Use Case • Solid line: • Interaction between actors and use case • Arrowhead (optional) • Control flow • Initial invocation, primary actor

  16. Use Case Levels

  17. Use Case Relationships • Goal: enable flexibility in requirements specification • Isolating functionality • Enabling functionality sharing • Breaking functionality into manageable chunks • Relationships • Include • Extend • Generalization

  18. Include Goal: Decomposing complicated behavior Centralizing common behavior the behavior of the included use case is inserted into the behavior of the including use case - The first use case often depends on the outcome of the included use case.

  19. Extend the behavior of the extension use case may be inserted in the extended use case under some conditions Note the direction of the arrow The base use-case does not know which use-case extends it

  20. Example: Amazon Actors? Base Use Cases? Include? Extend?

  21. Generalization use case may have common behaviors, requirements, constraints, and assumptions with a more general use case.

  22. Example: Cellphone Company System Hint - Actors: Phones, Phone Companies

  23. Writing Use Cases • Name: • Actors: • Descriptions: • Precondition • Main flow • Sub flow • Alternative flow

  24. Precondition • What the system needs to be true before running the use-case. • User account exists • User has enough money in her account • There is enough disk space

  25. Main flow The success scenario is the main story-line of the use-case • Assumption: everything is okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case • It is composed of a sequence of subflows Example: Step 1: Administrator enters course name, code and description (interaction) Step 2: System validates course code Step 3: System adds the course to the db and shows a confirmation message (interaction)

  26. Sub flow • Branches: • If the user has more than 10000$ in her account, the system presents a list of commercials • Otherwise… • Repeats: • User enters the name of the item he wishes to buy • System presents the items • User selects items to buy • Systems adds the item to the shopping cart • User repeats steps 1-4 until indicating he is done

  27. Alternative flows • Used to describe exceptional functionality • Examples: • Errors • Unusual or rare cases • Failures • Starting points • Endpoints • Shortcuts

  28. Write Include in User Case Reference

  29. Write Exclude in Use Case Extension Point

  30. Effective Use Cases • Only one side (system or actor) is doing something in a single step • • Write from an “objective” point of view using active tense • • Any step should lead to some progress

  31. Effective Use Cases ATM “Get the amount form the user and give him the money” “User click the enter key”

  32. Effective Use Cases – Common Mistakes • No actor • Too many user interface details “User types ID and password, clicks OK or hits Enter” • Very low goal details • User provides name • User provides address • User provides telephone number

  33. From Use-Case to Use-Case Diagrams • Top down ? Starting with an overview of the system, and then splitting Use-cases • Bottom up ? Starting with throwing all scenarios on the page, and then combining them: Most of the analysis process are actually combined

  34. Common Rules • Number Limit: The diagram should have between 3 to 10 base use-cases. No more than 15 use cases (base + included + extending). ---- If the dependency between two parts of a use-case is weak, they should be divided. • Abstraction: All use-cases should be in similar abstraction levels. • Size: Use cases should be described in half a page or more. - split using include/exclude

  35. When we are done • When every actor is specified. • When every functional requirement has a use-case which satisfies it. • A tractability matrix can help us determine it:

  36. Use Case and Use Case Diagram a Summary • When to use • What is Use Case and Use Case Diagram • How to Construct Use Case Diagram • How to Write Use Case • Questions?

  37. Wild and Crazy Ideas Session Extreme Programming (coding, testing, listening, and designing) vs. Product life cycle …….

  38. Session II: Challenges and Visions of Software Modeling

  39. How to read and present papers • Survey/roadmap papers • Important: Abstract, Subtitles, Conclusions • Reading Notes • What is about? List knowledge learned, vision • Like/Dislike – agree/disagree • Improvement – other visions, correction or addition of the existing knowledge

  40. How to read and present papers • Problem/Solution papers • Important: abstract, intro, conclusion • Reading Notes • What is about? Problems, Challenges, Existing Solutions, New solution, Experiments • Like/Dislike – pros/cons of the solutions • Improvement – Future work: what to do to make it better?

  41. Goals, Challenges, Initiatives • Problem/Solution papers • Important: abstract, intro, conclusion • Reading Notes • What is about? Problems, Challenges, Existing Solutions, New solution, Experiments • Like/Dislike – pros/cons of the solutions • Improvement – Future work: what to do to make it better?

  42. What this paper is about? Challenges of software modeling: • Create software models • Manage software models • Use software models

  43. Create Software Models • Modeling languages • General purpose and domain-specific languages • Formalism • Level of abstraction • Models for software running in different platforms • Model-driven architecture • Views: PIM (computation), CIM (environment), PSM • Models for software consistently changing at runtime (agent) • Modularity, separate concerns

  44. Manage Software Models • Find information from the models (query) • Correctness of the models: • Model consistencies • Model checking models • Transformations • Decomposition • Composition • Between models • Evolutions of models

More Related