1 / 147

Agenda for software

Agenda for software. 1. Expectations 2. Object-oriented approach 3. UML 4. Partitioning 5. Interfaces 6. Throughput and memory 7. Design elements. 1. Expectations. Problem 1 Approaches to problem 1 Problem 2 Approaches to problem 2. 1. Expectations. Problem 1. Requirement

rossa
Download Presentation

Agenda for software

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. Agenda for software 1. Expectations 2. Object-oriented approach 3. UML 4. Partitioning 5. Interfaces 6. Throughput and memory 7. Design elements

  2. 1. Expectations • Problem 1 • Approaches to problem 1 • Problem 2 • Approaches to problem 2 1. Expectations

  3. Problem 1 • Requirement • Provide a straight-line curve fit to a set of N measurements • Higher-product viewpoint • Provide a turn-key solution that meets the requirement • Software product viewpoint • Provide a solution that meets the equations provided by the higher-product 1. Expectations

  4. Approaches to problem 1 System System CSCI Algorithms Algorithms CSCI Higher-product viewpoint -- workable depends upon CSCI skill level Lower-product viewpoint -- workable depends upon CSCI skill level The algorithm document can be located in either place depending upon the skill of the lower-product developer 1. Expectations

  5. Problem 2 • Requirement • Provide a method for describing requirements for each lower-level product • Higher viewpoint • One higher-product process • Lower-product viewpoint • Each lower-product process defines higher-order process • Example -- System requirements shall be in VHDL or UML 1. Expectations

  6. Approaches to problem 2 System System spec spec spec VHDL UML math HWCI CSCI Algorithms HWCI CSCI Algorithms Higher-product viewpoint Lower-product viewpoint -- multiple system views and multiple languages --awkward Having a single system viewpoint and language is less awkward 1. Expectations

  7. 2. Object-oriented (OO) approach • Reasons for OO approach • Objects • Communications • Classes • Observation 2. Object-oriented (OO) approach

  8. Reasons for OO approach • Merges data and methods that • Reduces coupling • Provides reusability • Allows use of OO design tools, specifically • Design tools such as Object-Team and COOLJEX 2. Object-oriented (OO) approach

  9. Objects • An object is an entity that has • State -- the value of all the attributes at a given time • Behavior -- the actions and reactions of the object in response to external input • Identity -- distinguishes object from other objects • an object is an instantiation of a class 2. Object-oriented (OO) approach

  10. Communications (1 of 4) • Categories of behavior • Clients -- active objects that instigate an interaction • Servers -- passive objects that wait for other objects to require their services • Agents -- objects that can be either be either active or passive 2. Object-oriented (OO) approach

  11. Communications (2 of 4) • Message content • May carry data and/or control • Message types • Constructors -- create objects • Destructors -- delete objects • Selectors -- return all or part of the state • Modifiers -- changes all or part of the state • Iterators -- visits the state of an object 2. Object-oriented (OO) approach

  12. Communications (3 of 4) • Synchronization types • Simple broadcast -- message goes form the active object to the passive object • Synchronous broadcast -- sender is blocked until recipient accepts the message • Rendezvous broadcast -- recipient must go into a wait-for-message mode before sender can send message 2. Object-oriented (OO) approach

  13. Communications (4 of 4) • Synchronization types (continued) • Timed broadcast -- sender waits a period of time for acknowledgment • Asynchronous broadcast -- sender sends message without knowing when or if the recipient will process message 2. Object-oriented (OO) approach

  14. Classes (1 of 4) • Definition • A class is the definition of a set of objects • It specifies the data structure and possible operational methods that apply to each of the objects • Class refers to the software implementation of an object type 2. Object-oriented (OO) approach

  15. Classes (2 of 4) • Associations • The bi-directional connection between classes • Links between objects are instantiations of associations between classes 2. Object-oriented (OO) approach

  16. Classes (3 of 4) Ms Smith: resident object a link object New York: city Ms Jones: resident object a link object Mr. Hall: resident a link object Pittsburgh: city Mr. Wilson: resident object a link city resident class class 2. Object-oriented (OO) approach

  17. Classes (4 of 4) • Inheritance • A technique to construct a class from one or more classes • Child classes inherit characteristics from their parent classes 2. Object-oriented (OO) approach

  18. Observation • Hardware and systems tend to be object-oriented already so applying OO to them often results in renaming things and concepts with no particular advantage 2. Object-oriented (OO) approach

  19. 3. UML Introduction (1) Class diagrams (2) Object diagrams (3) Activity diagrams (4) Use diagrams (5) Sequence diagrams (6) Collaboration diagrams (7) State-chart diagrams (8) Deployment diagrams (9) Component diagrams 3. UML

  20. Introduction (1 of 3) • Goals • Represent complete systems using object-oriented concepts • Couple concepts and executable code • Account for scaling factors needed in complex systems • Make language usable by humans & computers 3. UML

  21. Introduction (2 of 3) • Practice • Useful • Complicated • Difficult for customer and managers to use 3. UML

  22. Introduction (3 of 3) UML non-UML • Diagrams • Use diagrams • Sequence diagrams • Object diagrams • Collaboration diagrams • Class diagrams • .State-chart diagrams • .Activity diagrams • Deployment diagrams • Component diagrams • usage • con ops • physical • interface • physical • decision table • con ops • physical • physical 3. UML

  23. (1) Use-case diagrams (1 of 7) • Definition • Use-case diagrams describe the behavior of a system from the user standpoint by using actions and reactions • Use-case diagrams are usage diagrams 3. UML

  24. (1) Use-case diagrams (2 of 7) • Use • Use-case diagrams provides a technique for specifying requirements that was missing in early objet-oriented methods • Use-case provides an approach for covering product development from requirements to implementation • Defining actors and use-cases defines the system 3. UML

  25. (1) Use-case diagrams (3 of 7) • Example • Use-case model Includes actors, system, and the use cases • System functionality determined by requirements of each actor as expressed in use cases system use-case 1 use-case 2 actor B actor A 3. UML

  26. (1) Use-case diagrams (4 of 7) • Use cases • Use cases are lists of activities the actor performs • The activities are textual sentences 3. UML

  27. (1) Use-case diagrams (5 of 7) • Actors • An actor represents the role played by a person or thing that interacts with the system • Actors determined by observing the main users of the system and other systems that interact with the system • A single physical person may play the role of several actors. Several people may play the same role and be a single actor 3. UML

  28. (1) Use-case diagrams (6 of 7) • Actors (continued) • An actor represents the role played by a person or thing that interacts with the system • Actors determined by observing the main users of the system and other systems that interact with the system • A single physical person may play the role of several actors. Several people may play the same role and be a single actor 3. UML

  29. (1) Use-case diagrams (7 of 7) • Application to verification • Use cases may support verification • Engineers may apply probabilities to each use case and then exercise the product statistically employing the use cases 3. UML

  30. (2) Sequence diagrams (1 of 3) • Definition • Sequence diagram display interactions in time among objects • Sequence diagrams are a form of time-sequence diagrams 3. UML

  31. (2) Sequence diagrams (2 of 3) • Uses • Sequence diagram focuses on showing interactions • Unlike collaboration diagram. Sequence diagram does not explicitly show the context • Sequence diagrams represent an interaction between objects that focuses on messages being broadcast • They are used to document use-cases and to define classes 3. UML

  32. (2) Sequence diagrams (3 of 3) object A object B • Example example synchronous and asynchronous messages synchronous msg asynchronous msg object A object B example transmission delay message object A example of an object sending message to itself reflexive message 3. UML

  33. (3) Object diagrams (1 of 3) • Definition • Object diagrams illustrate objects and links. They are sometimes called instance diagrams. • Object diagrams are physical diagrams • Objects are represented as rectangles with either the name of the object, the name and class of the object, or the class 3. UML

  34. (3) Object diagrams (2 of 3) • Use • Object diagrams describe the system as a set of nodes connected by links • They are a static structure • They are used to show a context 3. UML

  35. (3) Object diagrams • Example :login_display :login :configuration_display supervisor:list_of_people 3. UML

  36. (4) Collaboration diagrams (1 of 3) • Definition • Collaboration diagram shows interaction between objects 3. UML

  37. (4) Collaboration diagrams (2 of 3) • Use • It displays a static relationship showing how objects collaborate 3. UML

  38. (4) Collaboration diagrams (3 of 3) 1. display 2. read 4. hide • Example :login_display :login 5. display 3. correct password :configuration_display supervisor:list_of_people 3. UML

  39. (5) Class diagrams ( 1of 3) • Definition • Class diagrams show the static structure of the system in terms of classes and relations between classes • Class diagrams are physical diagrams 3. UML

  40. (5) Class diagrams (2 of 3) • Use • They’re often determined by generalizing the object diagram • A class diagram doesn’t describe anything specific about links 3. UML

  41. (5) Class diagrams (3 of 3) • Example login_display login configuration_display list_of_people 3. UML

  42. (6) State-chart diagrams (1 of 3) • Definition • A state chart diagram represents a state machine 3. UML

  43. (6) State-chart diagrams (2 of 3) • Use • Used to show logical control among objects and messages 3. UML

  44. (6) State-chart diagrams (3 of 3) • Example login read name name read read password error password read verify connection 3. UML

  45. (7) Activity diagrams (1 of 3) • Definition • An activity diagram is a variant of a state chart • It is simpler than a state chart and doesn’t need to have states 3. UML

  46. (7) Activity diagrams (2 of 3) • Use • It helps to expand use-cases 3. UML

  47. (7) Activity diagrams (3 of 3) • Example teacher student board teach learn supervise exams take exams evaluate 3. UML

  48. (8) Deployment diagrams (1 of 3) • Definition • A deployment diagram shows the physical layout of hardware nodes and the distribution of executable programs to the nodes 3. UML

  49. (8) Deployment diagrams (2 of 3) • Use • Nodes typically represented as cubes 3. UML

  50. (8) Deployment diagrams (3 of 3) • Example modem PC (control sw) Disk (load objects) comm IO port 3. UML

More Related