1 / 74

Development of Rigorous Adaptive Information Systems

Development of Rigorous Adaptive Information Systems. Dr. Nasreddine Aoumeur FIN, ITI, DB group aoumeur@iti.cs.uni-magdeburg.de Course Site: wwwiti.cs.uni-magdeburg.de/~aoumeur wwwiti.cs.uni-magdeburg.de/iti_db/lehre/oois/inde. Information Systems: Working definition.

bunny
Download Presentation

Development of Rigorous Adaptive Information Systems

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. Development of Rigorous Adaptive Information Systems Dr. Nasreddine Aoumeur FIN, ITI, DB group aoumeur@iti.cs.uni-magdeburg.de Course Site: wwwiti.cs.uni-magdeburg.de/~aoumeur wwwiti.cs.uni-magdeburg.de/iti_db/lehre/oois/inde ... Information Systems

  2. Information Systems: Working definition • reactive systems (i.e. in continuous interaction with their environment), with • large amount of immutable and non-immutabledata(i.e. fixed and changing) and, with • processes and activities for exhibiting behaviors on these (state-less and –full) data. ... Information Systems

  3. Conceptual Modelling of IS in general Structural aspects State-less and -ful DATA E /R or Object paradigm Behavioural aspects Processes and Rules Petri Nets ... Information Systems

  4. Conceptual Modelling of IS in UML • State-less and stateful DATA • - Use Cases • - Class Diagrams • - Object Diagrams • Object Constraint Language Structural aspects Forall C in …. • Processesand Rules • - Sequence Diagrams • - Collaboration Diagrams • - State Diagrams • Activity Diagrams • Component / deployment diagrams (implementation) Behavioural aspects ... Information Systems

  5. Airport Flight Passenger Conceptual Modelling of IS in UML View-oriented system modelling Information system partial views Use caseArrival Includes Landing Description The plane is landing. Then the passengers deplane and the luggage is unloaded. If the passenger has luggage then the passenger claims its luggage. . . . . UML diagrams ... Information Systems

  6. The origins of UML UML : Overview and History UML resulted from the merging of three very popular OOD methods - ---The three-Amigos Jacobson’s Use-Case approach This focused on the external actors interacting with the system and their functional requirements.. A CASE tool called Objectory is available. Booch’s OOD Booch’s method developed originally in 1991 based on OO Diagrams rather complex and CASE tool support essential. The emphasis here was on design and implementation. Rumbaugh’s OMT Object modeling technique supported by OMTool. Very Straightforward approach with an excellent text book. Widely adopted in academia and industry alike. Focus very much on analysis rather than design and implementation. ... Information Systems

  7. UML : Overview and History . . . What is UML • A Conceptual Modeling • Used to describe asimplified (abstract) view of reality • in order tofacilitate thedesign and then the implementation ofobject-oriented software systems • Conceptual Language • UML is primarilya graphical languagethat follows a precise syntax. • A UNIFIED • As By the start of the 90’s there was a flood of modeling languages, each with itsown strengths and weaknesses. ... Information Systems

  8. UML : Overview and History . . When is UML • In 1994 the UML effort officially began as a collaborative effort between Booch and Rumbaugh. Jacobson was soon after included in the effort. • The goal of UML: • A comprehensive modeling language (all things to all people) that • Promotion of the communication between all members of the development effort. • Version : UML 1.0 …. UML 2.0 (2003) ... Information Systems

  9. UML : Overview and History . . What is UML • UML is a language • Conforms tospecific rules. • Allows the creation of (structural, behavioural, and functional)various models. • Does not tell which models need to be created. • UML is a languagefor visualizing • UML is agraphical language. • Pictures facilitate communication (a picture is worth a thousand words) • UML is a language forconstructing and understanding • UML supports both forward and reverse engineering. • UML is a language forsupporting analysis, specification and design • UML is intended primarily forsoftware-intensive information systems ... Information Systems

  10. UML : Overview and History . . What is UML • Diagrams: • Structural aspects : • Class and object diagrams • Component and deployment (implementation) • OCL (object constraints language)for invariants, pre- and post-conditions. • Behavioural aspects : • Use cases, • Statechart, • Activity diagrams • Sequence diagrams • A set of standardised diagramatic notations for representing different aspects of a (information) system. Containing static structural views, dynamic behavioural views and functional views ... Information Systems

  11. The Unified Modelling Language UML : Overview and History . . UML is NOT • A design method or process, neither is it a methodology. • There is no provision for project management • specification of deliverables or life cycle or provision • for estimation • Users, developers can uses • - Whatever process and life cycle – RAD they want • - Focus on Prototyping / incremental development • - Focus on waterfall or spiral - they wished and • - Provide their own project management and QA • framework. ... Information Systems

  12. UML : Overview and History . . Inside UML • Static, structure diagrams • Class and instance diagrams • These depict the components (classes or instances) within the • system, • Their attributes and methods and their relationships with • each other • The class diagram in particular is the most important single • diagram in the design • Plus OCL constraints on invariants pre- and post-conditions • on methods • Component and subsystem diagrams (implementation) • - How classes are grouped to form large assemblies - • reusable components, sub-systems or packages of classes. • Deployment diagrams (implementation) • - How the software components are deployed across a set • of hardware components. ... Information Systems

  13. UML : Overview and History . . Inside UML • Interaction diagrams • Use-case diagrams • - Show the interface between the system and the outside world • - Identify the actors in the system and their required • functionality. • Sequence diagrams • - Capture the functionality of the system suing the messages • passing between objects. • - Each sequence diagram shows the implementation of one • scenario • Collaboration diagrams • - Based on the instance diagram, it shows how specific • scenarios are implemented by message sequence. • - Similar to sequence diagrams but with more detail ... Information Systems

  14. UML : Overview and History . . Inside UML • Dynamic behaviour of the system • Activity diagrams • - Similar to Petri-nets, • - Provide a view of the way objects interact and changes • their states in consequence • - The emphasis here is on system functionality as • perceived by users • Statecharts • - Harel Statecharts are developed from finite state • notation • - Illustrate the dynamic behaviour of objects. i.e. the way • in which an object evolves through time • - in response to external events. ... Information Systems

  15. UML : Overview and History . . UML for IS • Most diagram types are involved, but principally at the conceptual level : • Conceive a use-case diagram • - identify actors • - identify major functional requirements • Conceive an initial Class diagram • - discover principle classes • - represent important relationships • Event sequence diagrams • - Examine possible object interactions • - Determine class protocols • At Implementation model different refinements are to undertake • - combining or splitting classes, - adding or removing • relationships, -defining the implementation of • relationships, - introducing generalisations, interfaces • - Introduce Component, sub-system and deployment models. ... Information Systems

  16. UML : Use Cases Overview and illustrations A use case ... • Specifies what systemwill be used for, before the defining what system is supposed to do • Describe functionality ofa systemyielding observable results • Details scenarios that describe the interaction/dialog between users of the system and the system itself. Identify who (or what) interacts with the system • Does not indicate how the specified behavior is implemented, only what the abstract behavior is. • Performs a service for someusersof the system. • A user of the system is known as anactor. • An actorcan be a person or another system. • During the conceptual phase • Facilitates communication between the usersand developers of the system. • Facilitates the goal-based understanding of the system ... Information Systems

  17. UML : Use Cases Basic artifacts Actor Relationship UseCaseName An Actor is consistent set of roles that user plays when interacting with the system (e.g. a user or outsider of the system that interacts with the system) A Use Cases a sequence of actions performed by a system that yields a valuable result for a particular actor A link between the actors and the functions (use-cases). Different relationships are possible. ... Information Systems

  18. UML : Use Cases basic artifacts System Systemdefines the boundary between the system and the actors interacting with the system and other systems ... Information Systems

  19. UML : Use Cases---Modelling guidelines • Model with use cases essencial parts of system functionality • Model only those actors who involved in Use Cases • Factor out common functionality using inheritance relationship <<include>>,<<extend>> stereotypes • Describe only those events which are visible for the actor • Eachuse caseshould describes a significant piece of system usage understandable by domain experts • Use nouns and verbs accurately to help deriving objects and messages for interaction diagrams afterwards ... Information Systems

  20. UML : Use Cases basic artifacts Specifies the participation of an actor in a Use Case Actor Association Use Case A taxonomic relationship between a less and a more general Use Case Generalization ... Information Systems

  21. UML : Use Cases basic artifacts Specifies how the behaviour of the extension use cases e can be inserted into the behaviour of the base use case b <<extend>> e b Extend a relationship Specifies how the behaviour of the included p contributes to the behaviour of the base use case b <<include>> b p specialize a relationship ... Information Systems

  22. UML : Use Cases actors illustrations Louis acts as a student Enroll for a course Student Prepare for examination Deposit funds Elen acts as a student ... Information Systems

  23. UML : Use Cases actors illustrations Louis acts as a student Enroll for a Course Student Prepare for Examination Louis acts as a customer customer Deposit funds ... Information Systems

  24. UML : Use Cases --- AIRPORT illustration • Use caseArrival • Includes Landing • Actors plane,passenger • Preconditions non • Description The plane is landing. Then the passengers deplane and the luggage is unloaded. If the passenger has luggage then the passenger claims its luggage. ... Information Systems

  25. Airport Passenger Plane UML : Use Cases --- AIRPORT illustration use case <<include>> use case TakingOff Departure actor actor <<include>> Arrival Landing Flight ... Information Systems

  26. UML : Use Cases --- ATM use illustration Automated Teller Machine (ATM) Withdraw Cash Transfer Funds Bank Consortium Customer Deposit Maintain ATM MaintenanceCrew ... Information Systems

  27. Use Cases Scenarien • Ask the following questions: • What are the primary tasks that the system is supposed to perform? • What data will the actor manipulate (add, store, change or remove) in the system? • Which external changes does the system need to know about? • Which changes or events will the actor of the system need to be informed about? ... Information Systems

  28. UML Structural Modelling ... Information Systems

  29. Use Cases : Introduction ... Information Systems

  30. Use Cases : Introduction • A use case ... • Represents a functional requirement of the system as a whole. • Is graphically represented as an oval with the name of its functionality written inside. • Functionality is always expressed as a verb or a verb phrase. • An actor is most typically represented as a stick figure of a person labeled with its role name. • Individual use cases can exist in relationships with other use cases much in the same way as classes maintain relationships with other classes. ... Information Systems

  31. Terms and Concepts • Names are used to distinguish one use case from another. • Actors … • May be drawn as a stick figure, stereotyped class or a graphical image of your own design. • Are connected to use cases by associations. • May be involved in generalization relationships with other actors. • Exist outside the system boundaries (the environment). ... Information Systems

  32. The Unified Modelling Language Use-case diagrams These depict the Actors in the system and the required functionality. Actors External entities People interested in system Other systems interfacing with the system May or may not be represented by a software component. Represented by stick people or other graphic. Functions Primary functionality of system seen from a users perspective. Linked to the actors involved with/interested in the function. Represented by ovals. ... Information Systems

  33. Terms and Concepts ... Information Systems

  34. Terms and Concepts • Use cases and Flow of Events • A use case, by itself, does not describe the flow of events needed to carry out the use case. • Flow of events can be described using informal text, pseudocode, or activity diagrams. • Use a note to attach flow of events documentation to a use case. ... Information Systems

  35. The Unified Modelling Language manager Staff borrower student borrower Counter staff browser Return late book Use-case for library system Check member status <<uses>> Borrow book Register member <<uses>> Reserve book Usage report Return book Update catalogue Browse catalogue <<extends>> ... Information Systems

  36. Terms and Concepts • Organizing Use Cases • Packagesmay be used to organize (group) use cases. • Generalization between use cases is used to extend the behavior of a parent use case. • An <<include>> relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base. • Sometimes the <<uses> stereotype is used instead of <<include>>. ... Information Systems

  37. Use Case Relationships ... Information Systems

  38. Use Case Relationships ... Information Systems

  39. Use case diagrams • Use case diagrams … • Show a set of actors, use cases, and their relationships. • Facilitate communication between non-technical customers and developers due to their simplistic nature. • Show the functionality of the system from the prospective of each user of the system. • Model the context of the system. • Model the requirements of the system. ... Information Systems

  40. Use Case Diagram ... Information Systems

  41. Generating Use case diagrams • To model the requirements of a system … • Identify all actors (users of the system). • Identify the needs, from the system, of each individual actor. • Make each need a use case. • Identify redundant behavior within your set of use cases, and factor it into common base-class use cases ( generalization ) . • Do the same for actors. • Show the relationships between actors and use cases. ... Information Systems

  42. Modeling System Context ... Information Systems

  43. CMs Generation shift: “Entity To Object” From E/R to “Object-Object Entity Name Attribute1 : Type1 Attribute2 : Type2 .... Attributei : Typei n-m PART i-j Assoc m Entit(ies) data Property1 ..... operations IS-A n Entit(ies) data operations Processes, Operationsand Rules ... Information Systems

  44. First generation of CMs : “Entity first” E/R Conceptual Model (Running) Account Number : Nat Balance : Money Limit : Money History : List[Date,Money] Customer Name : String Birth-Date : Date Address : Address Income : Money 1-2 0-N Own Open-Date Bank IS-A Saving Account Number : Nat Interest : Percent Balance Processes and Rules Account USE : Firstopen --- then deposit – then (withdraw-deposit)* - then Close-or-be-closed ... Information Systems

  45. CMs generation shift : “From Entity to object” From E/R to Object Model : Banking Example (Running) Account Number : Nat Balance : Money Limit : Money History : List[Date,Money] Customer Name : String Birth-Date : Date Address : Address Income : Money 1-2 0-N Own Open-Date Bank Own(account) : Boolean Deposit (amount) Withdraw(Amount) • +open (date, bank) • close(date) • Debit(Amount) • Credit(Amount) +open - close deposit withdraw Processes,operations and Rules Account USE: First open - then deposit–> then (withdraw-deposit)* --> thenClose-or-be-closed ... Information Systems

  46. CM Generation shift : “From Entity to Object” From E/R Model to Object : ATM example Customer Name : String AutomaticTellerMachine ATM-Reference : String Cash : Hidden Bank : String Transaction : List[Money] History :List[Card-Nb,Acnt-Nb,Money Bank-Card Number : Nat Account-Nb: Nat Code : String 1-2 • Withdraw (ac, amount) • deposit (ac, amount) 0-N Withdraw • Create() • Delete() • - Accepted() • Rejected() Amount Date • - Read-card() • Enter-Pin(Code) • Enter-Amount(Money) • Get-Money(Money) Enter-card Enter-code enter-amount Get-money Processes, operations and Rules ATM-use : First enter-card – then enter-code– then enter-transaction— get money ... Information Systems

  47. CM Generation shift: “From Entity to Object” From E/R Model to Object : The Library Example Book Reference : String Name : String Author : String Publisher : String Student Name : String Subscription-Nb Semester Borrow 0-N 0-3 Date-Out Date-Back • Add() • Suppress() • - ToBorrow(Date) • ToReturn(Date) • Subscribe2Library • Unsubscribe • GetCard • ReceivePenalty Subscribe Unsubscribe Borrow Return Penality Processes, operations and Rules First subscribe-- Get library-card – (Borrow – Return –or– Penality)*--(be)Unsubscribe(d) ... Information Systems

  48. Object-Oriented Paradigm : General Overview In real world terms: • An object represents an individual entity or thing. • A class represents a group of objects that exhibit some common characteristics or behavior. • Classes are resulted from classification. OO phylosophy : The real-world consists in a society of interacting objects. • Examples of classes in real world: • Students • Graduate students • Undergraduate students • MS students • Ph.D. students ... Information Systems

  49. Object-Oriented Paradigm : Main concepts • An object has • state: defined by the set of fields or attributes. • behavior: defined by the set of methods oroperationthat can be applied to the object. • identity: determined at the creation time to uniquely referencing the object. • Class • A template for creating objects. • Objects of the same class exhibit the same behavior. • But generally, they posses different states (attribute values) ... Information Systems

  50. Object-Oriented Paradigm : Main conceptsObject and Class Like in real world: • Id : IF-43342 • Title : „Petri Nets“ • Author : „W.Reisig“ • State :{available, borrowed, use..} • borrowed • returned • edited • ..... one can has Book Attributs (state) Methods (behaviour) Object ... Information Systems

More Related