420 likes | 507 Views
Lecture 5. Session I: Review of UML Diagrams, Intro to Constraints and Invariants Break & discussions Session II: Modeling Adaptive Software - Erika. Project (50%). You will be expected to accomplish one of the following projects at the end of the terms:
E N D
Lecture 5 Session I: Review of UML Diagrams, Intro to Constraints and Invariants Break & discussions Session II: Modeling Adaptive Software - Erika
Project (50%) You will be expected to accomplish one of the following projects at the end of the terms: • Research Track ( a list of candidate projects) • Startup Track • Engineering Track (a given application) • With my approval, your own project
Due Date Signup (project name and team members) 9/23 (Fri) – 7:00pm/dropbox Proposal (problem understanding) 10/10 (Mon) – in class Mid-point check (implementation in-progress) 10/24 (Mon) – in class Final (visible progress) 11/16 (Wed) – in class
Logistics • Group (3 people maximum) • Special FAQ session (Wed 6:00 -7:00pm after class) • Read related work and study the scope of the projects before come to FAQ • Best project award
Accept event action Wait time action Notes for Last Lecture • Acitivity diagram – action node Two kinds of AcceptEventAction: • Signal events • Time events • Object notes: upbound for each object • the maximum number of values that an object node can hold • at runtime, when the upper bound has been reached, the flow is stopped (buffering)
InitializeObject Wait forEvent HandleEvent TerminateObject Notes for Last Lecture • Flowchart: • Sequence of operations • Logic of large software modules
Roadmap • Review of UML Diagrams • OCL (object constraint language) • Modeling Adaptive Software
Lectures 1- 4 UML Diagrams • Walk through an example • Quizzes • Summary
Withdrawal Transaction Use Case Primary Actor: Customer Pre-conditions: The customer must have a valid ATM card and PIN. Post-conditions: The customer receives the cash amount that he wanted to withdraw, with a receipt, if indicated. The customer’s account balance is updated in the system. Normal flow of events: 1. The customer inserts ATM card into the ATM machine and enters PIN. 2. The system validates the ATM card and PIN . 3. The customer selects the ‘Cash Withdrawal’ option from the Options Menu. … Alternate flow of events: 1. The customer has entered invalid PIN; The system prompts the customer to enter a valid PIN. 2. If ATM card is not compatible-The system rejects the ATM card and displays an error message ….
UML Summary • UML: a graphical language for modeling and designing software • Semi-formal models using syntax and semantics • UML 2.0 standard • 3 stages of design before coding: business modeling (initiation), requirement analysis (what to do), architecture (how to do it) • UML as a family of languages: extensibility - UML for real-time systems, e.g., meta-class, constraints • Best open source UML tools: http://apps.open-libraries.com/best-OPEN-source-uml-tools/
UML Diagrams Summary • Use Case Diagram: actor and use cases • 2 usage: mainly for requirement (sometimes business modeling), a communication between users, customers, designers • 4 elements: actor, system boundary, use cases, association • 4 rules to write good use case diagram: less ambiguity, complete, consistent, no design details - cross check with text requirement • 3 use case relations: include, extend, generalization/specialization • 4 key elements in use cases: name, actor, pre/post conditions, flow (main, alternative flows), sometimes relations with other use cases
Extension Point (when extend)
UML Diagrams Summary • Class Diagram: class and class relations • Requirement and architecture design • 3 elements: name, attribute (optional), operation (optional) • 2 types of class relations: association (aggregation/composition), generalization/specialization – inheritance • Identify names in the requirement as classes
UML Diagrams Summary • Sequence diagram: object interactions • Requirement analysis – describe use cases, find more objects • 4 elements: objects (actor), lifetime, activation, messages
UML Diagrams Summary • State diagram: behavior of a class, subsystem, application • Requirement, design • 3 elements: object, state, transition - event [guard]/activity • 4 Rules to construct the diagram • Deterministic • One initial state/>= 1 final states • All the states reachable from the initial state • For each state, there is a path to final state
UML Diagrams Summary • Activity diagram: capture an activity/action -- unit of executable functionality • Business modeling, requirement - both data and control flow, concurrent modeling • 2 types of elements • Activity nodes • Parameter nodes • Action nodes • Control nodes: decision/merge, join/fork, initial/final/flow final • Object nodes (pin): value pin, exceptional pin • Activity edges • Direct, Weight (optional) - the minimum number of tokens that must traverse the edge at the same time • Control /object edges
Final Nodes • Flow final: • destroys the tokens that arrive into it • the activity is terminated when all tokens in the graph are destroyed • Final node: • the activity is terminated when the first token arrives
«local precondition» Have a license To motorway tollgate Go to the station with a friend Catch the ticket Buy the ticket Obliterate the ticket The friend goes home Exit to xxxxx tollgate Get luggage ready Go home with the car Study for 5 minutes Go to Heaven/ Hell ;) Go to Heaven/Hell ;) Fill up with fuel Pay the ticket Get off the train Go home with bus Catch the train Car crash Turn on the car [else] [on car] [the tank is full] [on train] The train derail When the train arrives to xxxxx [else] [xxxxx is a long way]
UML Diagrams Summary • Component diagram: component interface and relations • Architecture design • 2 types of elements: node – component; edge – dependency • Deployment diagram: interaction with physical environment • Design – system staff/deployment team • Extension of component diagram
System Architecture One Version of UML Process Business Models Business Process Models Domain Model Domain Object State Diags. Business Use Cases Activity Diagrams refine Provides context for trace refine Analysis Models refine Behavioral Models Structural Models Analysis Use Cases Analysis Class Diagram State Diagrams Activity Diagrams Provides context for refine trace refine System Architectural Models Structural Models Interaction Diagrams refine refine trace Provides context for Component Diagram Deployment Diagram Design Class Diagrams. Provides context for State Diagrams refine Provides context for Implementation Models
Todo • Project signup due 9/23 Fri 7:00pm • Reading assignment • Formal modeling and analysis of a flash file system in Alloy – Jeff due 9/21 Wed in class • The object constraint language, chapters 1-4 • Submit slides to me • Pi-method: a model driven formal method for architecture-centric software engineering – Alex (9/26 Mon)