Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Agenda for software 1. Expectations 2. Object-oriented approach 3. UML 4. Partitioning 5. Interfaces 6. Throughput and memory 7. Design elements 10. Software 1 1. Expectations Problem 1 Approaches to problem 1 Problem 2 Approaches to problem 2 10. Software 1. Expectations 2 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 10. Software 1. Expectations 3 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 10. Software 1. Expectations 4 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 10. Software 1. Expectations 5 Approaches to problem 2 System spec HWCI System spec CSCI spec VHDL UML Algorithms Higher-product viewpoint HWCI CSCI math Algorithms Lower-product viewpoint -multiple system views and multiple languages --awkward Having a single system viewpoint and language is less awkward 10. Software 1. Expectations 6 2. Object-oriented (OO) approach Reasons for OO approach Objects Communications Classes Observation 10. Software 2. Object-oriented (OO) approach 7 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 10. Software 2. Object-oriented (OO) approach 8 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 10. Software 2. Object-oriented (OO) approach 9 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 10. Software 2. Object-oriented (OO) approach 10 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 10. Software 2. Object-oriented (OO) approach 11 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 10. Software 2. Object-oriented (OO) approach 12 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 10. Software 2. Object-oriented (OO) approach 13 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 10. Software 2. Object-oriented (OO) approach 14 Classes (2 of 4) Associations • The bi-directional connection between classes • Links between objects are instantiations of associations between classes 10. Software 2. Object-oriented (OO) approach 15 Classes (3 of 4) object a link Ms Smith: resident object a link Ms Jones: resident object a link Mr. Hall: resident object New York: city object Pittsburgh: city a link class 10. Software city Mr. Wilson: resident object resident 2. Object-oriented (OO) approach class 16 Classes (4 of 4) Inheritance • A technique to construct a class from one or more classes • Child classes inherit characteristics from their parent classes 10. Software 2. Object-oriented (OO) approach 17 Observation Hardware and systems tend to be objectoriented already so applying OO to them often results in renaming things and concepts with no particular advantage 10. Software 2. Object-oriented (OO) approach 18 3. UML Introduction (1) Use diagrams (2) Sequence diagrams (3) Object diagrams (4) Collaboration diagrams (5) Class diagrams (6) State-chart diagrams (7) Activity diagrams (8) Deployment diagrams (9) Component diagrams 10. Software 3. UML 19 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 10. Software 3. UML 20 Introduction (2 of 3) Practice • Useful • Complicated • Difficult for customer and managers to use 10. Software 3. UML 21 Introduction (3 of 3) Diagrams UML non-UML •Use diagrams •Sequence diagrams •Object diagrams •Collaboration diagrams •Class diagrams •.State-chart diagrams •.Activity diagrams •Deployment diagrams •Component diagrams 10. Software 3. UML •usage •con ops •physical •interface •physical •decision table •con ops •physical •physical 22 (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 10. Software 3. UML 23 (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 10. Software 3. UML 24 (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 actor A 10. Software use-case 2 3. UML actor B 25 (1) Use-case diagrams (4 of 7) Use cases • Use cases are lists of activities the actor performs • The activities are textual sentences 10. Software 3. UML 26 (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 10. Software 3. UML 27 (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 10. Software 3. UML 28 (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 10. Software 3. UML 29 (2) Sequence diagrams (1 of 3) Definition • Sequence diagram display interactions in time among objects • Sequence diagrams are a form of timesequence diagrams 10. Software 3. UML 30 (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 10. Software 3. UML 31 (2) Sequence diagrams (3 of 3) Example example synchronous and asynchronous messages example transmission delay example of an object sending message to itself object A object B synchronous msg asynchronous msg object A object B message object A reflexive message 10. Software 3. UML 32 (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 the either the name of the object, the name and class of the object, or the class 10. Software 3. UML 33 (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 10. Software 3. UML 34 (3) Object diagrams Example :login_display :login :configuration_display supervisor:list_of_people 10. Software 3. UML 35 (4) Collaboration diagrams (1 of 3) Definition • Collaboration diagram shows interaction between objects 10. Software 3. UML 36 (4) Collaboration diagrams (2 of 3) Use • It displays a static relationship showing how objects collaborate 10. Software 3. UML 37 (4) Collaboration diagrams (3 of 3) Example 1. display 2. read 4. hide :login_display :login 5. display :configuration_display 10. Software 3. correct password supervisor:list_of_people 3. UML 38 (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 10. Software 3. UML 39 (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 10. Software 3. UML 40 (5) Class diagrams (3 of 3) Example login_display login configuration_display list_of_people 10. Software 3. UML 41 (6) State-chart diagrams (1 of 3) Definition • A state chart diagram represents a state machine 10. Software 3. UML 42 (6) State-chart diagrams (2 of 3) Use • Used to show logical control among objects and messages 10. Software 3. UML 43 (6) State-chart diagrams (3 of 3) Example login read name name read read password error password read verify connection 10. Software 3. UML 44 (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 10. Software 3. UML 45 (7) Activity diagrams (2 of 3) Use • It helps to expand use-cases 10. Software 3. UML 46 (7) Activity diagrams (3 of 3) Example teacher student board teach learn supervise exams take exams evaluate 10. Software 3. UML 47 (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 10. Software 3. UML 48 (8) Deployment diagrams (2 of 3) Use • Nodes typically represented as cubes 10. Software 3. UML 49 (8) Deployment diagrams (3 of 3) Example comm modem 10. Software PC (control sw) 3. UML IO port Disk (load objects) 50 (9) Component diagrams (1 of 3) Definition • A component diagram describes software components at the time of implementation 10. Software 3. UML 51 (9) Component diagrams (2 of 3) Use • A component has a body and a specification. In C++, the specification is a file with .h extension and the body is a file with extension .cpp 10. Software 3. UML 52 (9) Component diagrams (3 of 3) Example body 10. Software 3. UML specification 53 4. Partitioning Requirement Criteria Choosing criteria Special considerations Most common criteria Cost as a criterion 10. Software 4. Partitioning 54 Requirement Requirement • Common to have no customer requirement for partitioning • Operating system and COTS are exceptions although military emphasis on reuse comes and goes Design • Developer chooses partitioning 10. Software 4. Partitioning 55 Criteria Chose partitioning criteria • Similarity to something done before • Customer satisfaction • Cost • Risk • Schedule • Performance • Reusability and COTS • Functional cohesion and uncoupling • Throughput and memory • Other 10. Software 4. Partitioning 56 Choosing criteria Choice of criteria depends upon what is important to the product being developed Criteria may vary from system to system and may vary among products of the same type within a system 10. Software 4. Partitioning 57 Special considerations Application Parallel processing Available resources Shared resources Available people Subcontracting 10. Software 4. Partitioning 58 Most common criteria Functional cohesion and uncoupling Throughput and memory 10. Software 4. Partitioning 59 Cost as a criterion Although cost is a dominant criterion in systems and hardware, it is less dominant in software because the product of software is lines of code, which doesn’t have the costing problems of hardware 10. Software 4. Partitioning 60 5. Interfaces Introduction Examples 10. Software 5. Interfaces 61 Introduction Interface definition -- The mechanism whereby two products interact Types of interfaces • Physical interfaces • Data interfaces 10. Software 5. Interfaces 62 Introduction (2 of 3) Considerations for physical interfaces • Physical characteristics • Alignment • Self test • Instrumentation • Data extraction • Verification • Format standards • Reuse 10. Software 5. Interfaces 63 Introduction (3 of 3) Considerations for data interfaces • Time tagging • Self test • Instrumentation • Data extraction • Verification • Format standards • Reuse • Throughput 10. Software 5. Interfaces 64 Example -- mechanical alignment subsystem 1 frame mechanical subsystem 2 components Key considerations Alignment Vibration Thermal expansion Installation Maintenance 10. Software 5. Interfaces 65 Example -- cooling subsystem 1 generates heat thermal subsystem 2 heat and cools Subsystems coupled Subsystem 2 may not be able to control heating and cooling 10. Software 5. Interfaces 66 Example -- standard busses DMA RS-232 MIL-STD-1503 FDDI HIPPI Fibre channel 10. Software 5. Interfaces 67 Example -- LANS/MANS/WANS (1 of 3) LAN • Local area network • Privately owned • Short distance -- building, campus, few miles • Ethernet often used 10. Software 5. Interfaces 68 Example -- LANS/MANS/WANS (2 of 3) MAN • Metropolitan area network • Bigger version of LAN • Private or public • Several buildings, a city • Distributed queue dual bus often used 10. Software 5. Interfaces 69 Example -- LANS/MANS/WANS (3 of 3) WAN • Wide area network • Large areas, countries, continents • Complicated arrangement of subnets 10. Software 5. Interfaces 70 Example -- ethernet (1 of 3) IEEE 802.3: Ethernet Used with LANs Protocol • When a station wants to transmit, it listens to the cable • If the cable is busy, it waits; otherwise it transmits • If two stations transmit simultaneously, both stop, wait a random time, and then repeat the process again 10. Software 5. Interfaces 71 Example -- ethernet (2 of 3) repeater linear 10. Software spine tree 5. Interfaces repeater 72 Example -- ethernet (3 of 3) name cable length* nodes* nodes* 10Base5 thin coax 500 m 100 good for backbones 10Base2 thin coax 200 m 30 cheapest 10Base-T twisted pair 100 m 1024 easy to maintain 10Base-F 2000 m 1024 best between buildings fiber optics * per segment 10. Software 5. Interfaces 73 Example -- token bus IEEE Standard 802.4: Token Bus Used with LANs Physical • Linear, 75 ohm broadband cable • 1.5 and 10 Mbps • More complicated than ethernet 10. Software 5. Interfaces 74 Example -- token bus Protocol • Logically arranged as a ring • Highest numbered station ma send first • Then passes token • Token propagates around ring • Only holder of token can transmit • No collisions occur 10. Software 5. Interfaces 75 Example -- token bus station broadband coax cable logical ring 10. Software 5. Interfaces 76 Example -- token ring (1 of 3) IEEE Standard 802.5: Token Ring Used with LANs Physical • Twisted, shielded pairs • 4 Mbps • Manchester coding 10. Software 5. Interfaces 77 Example -- token ring (2 of 3) Protocol • Special bit pattern, the token, circulates when all stations are idle • Station wanting to transmit must seize the token and remove before transmitting • Station replaces ring after transmission 10. Software 5. Interfaces 78 Example -- token ring (3 of 3) ring interface unidirectional ring station one-bit delay at each station 10. Software 5. Interfaces 79 Example -- DQDB (1 of 6) IEEE Standard 802.6: Distributed Queue Dual Bus Used with MANs Physical layout • Two parallel cables up to 160 km each • 44,736 Mbits/sec (T3) • Cells • • • • 10. Software 53 bytes 44 bytes of data 1 busy bit 1 request bit 5. Interfaces 80 Example -- DQDB (2 of 6) A-bus head Station A Station B Station C Station D Station E RC=0 CD=0 RC=0 CD=0 RC=0 CD=0 RC=0 CD=0 RC=0 CD=0 B-bus head Initial conditions Initially, request counter (RC) and CD are zero for stations A-E 10. Software 5. Interfaces 81 Example -- DQDB (3 of 6) A-bus head Station A Station B Station C Station D Station E RC=1 CD=0 RC=1 CD=0 RC=1 CD=0 RC=0 CD=0* RC=0 CD=0 B-bus head request transmits cell D makes a request Stations upstream from D on A-bus increment RC 10. Software 5. Interfaces 82 Example -- DQDB (4 of 6) head Station A Station B Station C Station D Station E RC=2 CD=0 RC=0 CD=1* RC=1 CD=0 RC=0 CD=0* RC=0 CD=0 B-bus request head transmits cell B makes a request Stations upstream from B on A-bus increment RC. B moves RC to CD 10. Software 5. Interfaces 83 Example -- DQDB (5 of 6) data head xmits cell Station A Station B Station C Station D Station E RC=1 CD=0 RC=0 CD=1* RC=1 CD=0 RC=0 CD=0 RC=0 CD=0 B-bus head D sends data Stations upstream from D on A-bus decrement RC and CD 10. Software 5. Interfaces 84 Example -- DQDB (6 of 6) data head xmits cell Station A Station B Station C Station D Station E RC=0 CD=0 RC=0 CD=0 RC=1 CD=0 RC=0 CD=0 RC=0 CD=0 B-bus head B sends data Stations upstream from B on A-bus decrement RC and CD 10. Software 5. Interfaces 85 Example -- OSI messaging (1 of 9) 1 application application protocol application APDU presentation PPDU session SPDU transport TPDU presentation protocol 2 presentation 3 session 4 transport session protocol transport protocol communication subnet 5 network network network network packet 6 data link data link data link data link frame 7 physical physical physical physical bit Host A router router Host B Tanenbaum: Computer Networks 10. Software 5. Interfaces 86 Example -- OSI messaging (2 of 9) Physical layer • Transmits raw bits over a communication channel • Deals with mechanical, electrical, and procedural interfaces • Includes transmission medium 10. Software 5. Interfaces 87 Example -- OSI messaging (3 of 9) Data link layer • Transforms raw data facility into a line that is free of undetected transmission errors • Controls sequence • Breaks data into data frames • Transmits frames sequentially • Acknowledges frames sent by sender 10. Software 5. Interfaces 88 Example -- OSI messaging (4 of 9) Data link layer (continued) • Creates and recognizes frame or packet boundaries • Handles damaged frames by retransmission and resolving duplication • Regulates traffic loads • Handles simplex, half-duplex, duplex, and broadcast operation • Controls access 10. Software 5. Interfaces 89 Example -- OSI messaging (5 of 9) Network layer • Controls operation of the subnet • Routes packets from source to destination • Regulates traffic • Keeps count of traffic flow for billing purposes • Allows different networks to be interconnected • Resolves addressing, size, and protocols 10. Software 5. Interfaces 90 Example -- OSI messaging (6 of 9) Transport layer • Accepts data from session layer, breaks data into smaller layers, sends data to network layer, and ensures all pieces arrive at other end • Creates network session for each transport session; although may use more than one network session or multiplex sessions 10. Software 5. Interfaces 91 Example -- OSI messaging (7 of 9) Session layer • Allows users on different machines to establish sessions • Resolves conflicts when two sessions attempt to do same operation at the same time • Manages flow of large sets of data 10. Software 5. Interfaces 92 Example -- OSI messaging (8 of 9) Presentation layer • Handles functions that are used commonly so that each user doesn’t need to deal with them • Handles syntax of data • Converts nonstandard data structures into form needed by lower layers 10. Software 5. Interfaces 93 Example -- OSI messaging (9 of 9) Application layer • Interfaces between session layer and user • Examples • File transfer • Terminal services 10. Software 5. Interfaces 94 Example -- TCP/IP messaging OSI TCP/IP application presentation session transport network data link physical Tanenbaum: Computer Networks 10. Software application n/a transport network host-to-network 5. Interfaces 95 Example -- TCP/IP messaging application TELNET FTP SMTP TCP UDP DNS transport protocols network IP physical data link networks 10. Software ARPANET SATNET 5. Interfaces packet radio LAN 96 Example -- OS interfaces (1 of 2) MS DOS • Interfaces between user and basic input/output system (BIOS) • Vendor dependent 10. Software 5. Interfaces 97 Example -- OS interfaces (2 of 2) POSIX • Interfaces between user and OS kernel • Broader than typical UNIX kernel interface that are usually library routines • Vendor independent • Supports open systems 10. Software 5. Interfaces 98 6. Throughput and memory Throughput Memory 10. Software 6. Throughput and memory 99 Throughput (1 of 5) Example requirements • All general purpose computers shall have 50 percent spare throughput capacity • All digital signal processors shall have 25 percent spare throughput capacity • All firmware shall have 30 percent spare throughput capacity • All communication channels shall have 40 percent spare throughput capacity • All communication channels shall have 20 percent spare terminals 10. Software 6. Throughput and memory 100 Throughput (2 of 5) There shall be 100 % spare throughput capacity reference capacity throughput-used usage common common capacity 100 MOPS 100 MOPS throughput-used 50 MOPS 50 MOPS spare throughput 50 MOPS 50 MOPS percent spare 50 percent 100 percent pass/fail fail pass There are two ways of interpreting spare throughput capacity based on reference used as denominator 10. Software 6. Throughput and memory 101 Throughput (3 of 5) Availability of spare throughput • Available at the highest-priorityapplication level -- most common • Available at the lowest-priority-application level -- common • Available in proportion to the times spent by each segment of the application -- not common Assuming the spare throughput is available at the highest-priority-application level is the most common assumption 10. Software 6. Throughput and memory 102 Throughput (4 of 5) Throughput capacity is most often verified by test • Analysis -- not common • Time event simulation -- not common • Execution monitor -- common but requires instrumentation code and hardware 10. Software 6. Throughput and memory 103 Throughput (5 of 5) • Execution of a code segment that uses at least the number of spare throughput instructions required -- not common but avoids instrumentation Instrumenting the software to monitor runtime or inserting a code segment that uses at least the spare throughput are two methods of verifying throughput 10. Software 6. Throughput and memory 104 Memory (1 of 3) Example requirements • All general purpose computers shall have 50 percent spare memory capacity • All digital signal processors (DSPs) shall have 25 percent spare on-chip memory capacity • All digital signal processors shall have 30 percent spare off-chip memory capacity • All mass storage units shall have 40 percent spare memory capacity • All firmware shall have 20 percent spare memory capacity 10. Software 6. Throughput and memory 105 Memory (2 of 3) There shall be 50 % spare memory capacity reference capacity memory-used usage common less-common capacity 100 Mbytes 100 Mbytes memory-used 60 Mbytes 60 Mbytes spare memory 40 Mbytes 40 Mbytes percent spare 40 percent 67 percent pass/fail fail pass There are at least two ways of interpreting the meaning of spare memory capacity based on the reference used as the denominator in computing the percentage 10. Software 6. Throughput and memory 106 Memory (3 of 3) Memory capacity is most often verified by analysis of load files Memory capacity is frequently tracked as a technical performance parameter (TPP) Contractors don’t like to consider that firmware is software because firmware is often not developed using software development methodology and firmware is not as likely to grow in the future 10. Software 6. Throughput and memory 107 7. Design elements Introduction Software Hardware tools Hardware 10. Software 7. Design elements 108 Introduction There are commercial, off-the-shelf products and tools to support software design and development Use of these tools increase productivity by shortening development time and providing reliable products 10. Software 7. Design elements 109 Software System engineering tools Real-time operating systems, kernels, and executives Compiler and language products Debuggers Libraries Communications packages Embedded internet packages Java language products Data bases 10. Software 7. Design elements 110 Hardware tools In-circuit emulators BDM/JTAG-based emulators ROM emulators Oscilloscopes Logic and bus analyzers 10. Software 7. Design elements 111 Hardware Integrated circuits • Microcontrollers and embedded microprocessors • Digital signal processors • Flash memory Board-level products • Single-board computers 10. Software 7. Design elements 112