cs 425 625 software engineering system models n.
Skip this Video
Loading SlideShow in 5 Seconds..
CS 425/625 Software Engineering System Models PowerPoint Presentation
Download Presentation
CS 425/625 Software Engineering System Models

CS 425/625 Software Engineering System Models

139 Vues Download Presentation
Télécharger la présentation

CS 425/625 Software Engineering System Models

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CS 425/625 Software EngineeringSystem Models Based on Chapter 7 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6th Ed., Addison-Wesley, 2000 and on Ch7 PowerPoint presentation available at the book’s web-site: September 29, 2003

  2. Outline • System Models • Contextual Models • Behavioral Models • Data Models • Object Models

  3. Introduction. • System models are used to specify the system to be built in a more detailed way • Typically, system models are graphical descriptions of the system, its services and its constraints • Various perspectives for system modeling: • Context • Behavior • Structure

  4. .Introduction • The production of system models is usually guided by methods, e.g., SSA (Structured Systems Analysis), SADT (Structured Analysis and Design Technique), OMT (Object Modeling Technique), etc. • In practice, various models, not bound to methods, could be combined to describe the system and its requirements • Main types of system models: • Data Processing Models • Composition Models • Architectural Models • Classification Models • Stimulus-Response Models

  5. Context Models… • Contextual modelsshow the system and its environment • Ideally, the boundaries between the system and its environment are identified clearly • Dependencies between the computer-based system and systems from the environment are highlighted

  6. .Context Models.. • Various models can be used for context modeling: • Very simple, high level architectural models show the system and its connections with environmental components • High level process models indicate main process activities • High-level data-flow diagrams depict data transformations and data transfers

  7. ..Context Models. • Example of architectural model for system context specification: an ATM system and its environment [Fig. 7.1, Somm00]

  8. …Context Models • Example of process model for system context specification: an equipment procurement system [Fig. 7.2, Somm00]

  9. Behavioral Models……. • Behavioral models specify the overall behavior of the system: • Data-flow models (or data-flow diagrams, DFD) are suitable for data-driven systems • State machine models (or stimulus-response models) are appropriate for event-driven systems

  10. .Behavioral Models…... • Data-flow models show the system in terms of: • Data stores [graphical representation: rectangles] • Data transformations (data processing operations) [graphical representation: rounded rectangles] • Data movements (data transfers) [graphical representation: directed lines]

  11. ..Behavioral Models….. • State machine models describe system behavior using two main modeling elements: • States [represented using rounded rectangles] • Transitions [shown as directed links between states]

  12. …Behavioral Models.... • A DFD example: an order processing system [Fig. 7.3, Somm00]

  13. ….Behavioral Models… • State machine diagrams depict the behavior of the system in terms of responses to events • Real-time systems are essentially event-driven systems • The system is assumed to be in one of its possible states at any given moment of time. A transition to another state is triggered by the occurrence of an event • David Harel’s statechartsare included in the UML (Unified Modeling Language); DFDs are not part of UML

  14. …..Behavioral Models.. • Example of state machine diagram: A microwave oven controller [Fig. 7.5, Somm00]

  15. …...Behavioral Models. • The statecharts notation used in UML allows: • Specification of composite states (states that have sub-states), thus supporting model decomposition • Description of actions performed while in a state: • Entry actions • State actions (activities) • Exit actions • Description of transitions: • Events that trigger the transition • Conditions under which transitions occur • Actions on transitions, if any

  16. …....Behavioral Models • Example of composite state: microwave oven [Fig. 7.7, Somm00]

  17. Semantic Data Models… • Data models describe the logical structure of data processed by the system • The Entity-Relationship-Attribute model, ERA (also known as Entity-Relationship model, ER) shows: • Entities in the system • Relationships between entities • Attributes of entities and relationships • Cardinality constraints (e.g., “one” or “many”)

  18. .Semantic Data Models.. • Data dictionaries are repositories of information pertaining to the elements of the system models. They are useful to manage the namespace of the system models as well as to supply a cross-reference tool for analysis, design, implementation, and evolution.

  19. ..Semantic Data Models. • An ERA example: a software design description [Fig. 7.8, Somm00]

  20. …Semantic Data Models • Data dictionary: examples of data entries [Fig. 7.9, Somm00]

  21. Object Models…….. • Objected-oriented modeling is centered around the concepts of objectand class • An objectis an entity described in terms of attributes (data) and operations (functionality) • A class is a template for objects that have similar features (attributes and operations). • More exactly, the objects that belong to the same class have the same structure and behavior, e.g., davidsAlarmClock is an object (instantiation) of the class AlarmClock

  22. .Object Models……. • The distinguishing principles of object-oriented (OO) technology are: • Encapsulation • Inheritance • Polymorphism

  23. ..Object Models…… • Objects provide more natural ways to model real-life entities • Both structure (class diagrams) and behavior (e.g., interaction diagrams and state diagrams) can be described • A class diagram shows: • Classes • Relationships between classes • Constraints • Annotations

  24. …Object Models….. • The value of OO comes from: • Greater modeling power • Increased reusability and extensibility • Improved control of complexity

  25. ….Object Models…. • Example of class hierarchy: a library system [Fig. 7.10, Somm00]

  26. …..Object Models… • Another example of class hierarchy: Library users [Fig. 7.11, Somm00]

  27. ……Object Models.. • Example of multiple inheritance [Fig. 7.12, Somm00]

  28. …….Object Models. • Example of class structure with aggregation [Fig. 7.13, Somm00]

  29. ……..Object Models • Example of sequence diagram [Fig. 7.14, Somm00]