1 / 19

Modeling

Modeling. ECE 417/617: Elements of Software Engineering. Stan Birchfield Clemson University. Overview. Modeling provides abstraction to bridge the gap between High-level (world) Low-level (code) Types of modeling: Analysis modeling Models problem domain (users, world) System modeling

liora
Download Presentation

Modeling

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. Modeling ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. Overview • Modeling provides abstraction to bridge the gap between • High-level (world) • Low-level (code) • Types of modeling: • Analysis modeling • Models problem domain (users, world) • System modeling • Models solution domain (software)

  3. Data flow diagram (DFD) • Data flow diagram (DFD) developed in late 1970s • part of Structured Design (one of the earliest methodologies for software development); aka Structured Systems Analysis and Design Method (SSADM), a waterfall method • invented by Larry Constantine, who also developed concepts of coupling and cohesion • DFD is a forerunner of UML and may complement it • Arcs are data; boxes are processes/actions source code executeunittests reviewtestresults test results review decision test plan

  4. Gane and Sarson notation for DFDs • squares – external entities • round rectangles – processes • arrows – data flow • open-ended rectangles – data stores http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm

  5. Data flow diagram (DFD) • DFDs are refined iteratively • Level 0 is context-level DFD; represents s/w as a single bubble with input and output • Level 1 is achieved by expanding the bubble into additional bubbles; perform grammatical parse on narrative describing bubble • Continue refining until each bubble performs specific function; high cohesion • Components: bubbles are processes, boxes are external entities, arrows are data or control objects, and double lines are data stores • Process specification (PSPEC) describes all flow model processes that appear at the final level of refinement. It is a minispec for each transform at the lowest level of a DFD • Program design language description (PDL) is basically pseudocode. One way to represent PSPEC

  6. CRC modeling • Class Responsibility Collaborator (CRC) is a lightweight model • Write on 3”x5” index cards • Used in extreme programming • Can be used for • detailed object-oriented design • conceptual modeling http://www.agilemodeling.com/artifacts/crcModel.htm

  7. CRC example class is collection of objects • two types of collaboration: • request for information • request to do something responsibility is anything a class knows or does http://www.agilemodeling.com/artifacts/crcModel.htm

  8. Creating CRC cards Iteratively • Find classes • Find responsibilities • Define collaborators • Move the cards around http://www.agilemodeling.com/artifacts/crcModel.htm

  9. Unified modeling language (UML) • Several competing object-oriented notations developed in 1980s and 1990s • Rumbaugh and Booch began working together in 1994 at IBM Rational to standardize their notations (OMT and Booch) • Result was Unified Modeling Language (UML) • Rights owned by Object Management Group (OMG), www.omg.org • Good reference: M. Blaha and J. Rumbaugh, Object-Oriented Modeling and Design with UML, 2nd ed.

  10. UML Unified modeling language (UML) includes three models: • class model – structural aspects of system (class diagrams) • state model – temporal, behavioral aspects of system (state diagrams) • interaction model – collaboration of individual objects (use cases, sequence diagrams, and activity diagrams)

  11. A simple problem to provide brief overview of UML switch 1 W 5 V light

  12. 1. Use Case Diagram SimpleCircuit FlipOn FlipOff ViewLight User Functionality from user’s point of view

  13. 2. Class Diagram Switch Resistor Light Battery 5V Structure of system (objects, attributes, associations, operations)

  14. 3. Sequence Diagram Switch Resistor Battery Light User FlipOn() HeatUp() Drain() Shine() Messages between objects

  15. 3. Collaboration Diagram User 1. FlipOn() 1.1 HeatUp() Switch Resistor 1.2 Shine() 1.3 Drain() Battery Light More compact, but harder to interpret

  16. 4. Statechart Diagram flipSwitchOn Light Off Light On flipSwitchOff Transitions between states of one object (Extension of Finite State Machine (FSM) model)

  17. 4. Statechart Diagram (different objects) flipSwitchOn flipSwitchOn Not Draining Cold Hot Draining flipSwitchOff flipSwitchOff (Resistor) (Battery)

  18. 5. Activity Diagram Flip Switch Off Flip Switch On With swimlanes: Actor1 Actor2 Flip Switch On Read Book Actions are states

  19. Summary We have looked at five UML diagrams: • Use case diagrams [Interaction Model]-- models functionality from user’s point of view • Class diagrams [Class Model]-- models structure of system using objects • Interaction diagrams [Interaction Model](sequence and collaboration)-- models messages passed between objects • Statechart diagrams [State Model]-- models transitions between states • Activity diagrams [Interaction Model]-- models flow control as transitions between activities The actual UML spec has 12 diagrams, but these five will be sufficient for us.

More Related