1 / 42

Software Engineering

Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL Agenda Exam Review Team interactions OO Analysis and Design Team presentations Team Interaction History

omer
Download Presentation

Software Engineering

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. Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL T. E. Potok - University of Tennessee

  2. Agenda • Exam Review • Team interactions • OO Analysis and Design • Team presentations T. E. Potok - University of Tennessee

  3. Team Interaction T. E. Potok - University of Tennessee

  4. History • Most early software productivity studies focused on the software development team as the main factor in increasing productivity. • The goal of a project manager was to hire the people with the most experience, and best talent • However, that was at a time when experience was hard to come by, and there was little formal education T. E. Potok - University of Tennessee

  5. Current Situation • Computer science degrees are common • Software development experience is common • However, demand still out paces the availability of computer skills • Is the software development team still important? T. E. Potok - University of Tennessee

  6. Not to Some • Kitchenham, Lawrence, and Jeffery et al. show that many of the personnel related factors in earlier studies had no effect on productivity in their studies. T. E. Potok - University of Tennessee

  7. What is a team? • A collection of people with a common mission or purpose. • Traditional departmental focus: • Group similar skills on the same teams, architects with architects, programmers with programmers, testers with testers. • Based on mass production efficiency concepts • specialization of labor T. E. Potok - University of Tennessee

  8. Non-traditional Teams • Product focused: • The team is made up of members that can contribute to the completion of the project: • 1 architect • 6 programmers • 2 testers • The team is charged with successfully completing the project T. E. Potok - University of Tennessee

  9. Example • Most universities are organized around departments: • Computer science • Mathematics • Physics • Each department has faculty members who are experts in the department’s field T. E. Potok - University of Tennessee

  10. Example • What if you organized the departments around the students? • The Freshman Engineering Department may look like: • 4 Mathematicians • 2 Physicists • 2 Chemists • 4 English teachers T. E. Potok - University of Tennessee

  11. What drives a team • Locke and Latham’s“goal theory” reports that productivity increases with specific, challenging goals • There is a linear relationship between the degree of difficulty of a goal, and the performance required to achieve it. T. E. Potok - University of Tennessee

  12. Basic Experiment • Participants performing a group of tasks. • Some of the participants are given challenging goals, • others are told to “do their best.” • In most cases, the participants given hard goals significantly out performed the other participants. • This widely accepted theory supports the notion that programmer productivity can be strongly influenced by deadline “goals” set by a project schedule. T. E. Potok - University of Tennessee

  13. Leadership • Look at successful software development efforts and you will find a successful leader • Some characteristics of a leader (Maxwell): • A person of influence, not necessarily from title or position • Has the ability to learn and grow • Has passion and discipline for the task • Has the ability to lead T. E. Potok - University of Tennessee

  14. More on Leadership • Covey’s Seven habits • Proactive • Begin with the end in mind • First things first • Think win-win • Understand, then be understood • Synergize • Sharpen the saw T. E. Potok - University of Tennessee

  15. Five Temptations of a CEO • Focus on career, not company success • Desire to be liked by staff • Desire for correctness over clarity • Desire for harmony • Desire to be invulnerable T. E. Potok - University of Tennessee

  16. Object-Oriented Analysis and Design T. E. Potok - University of Tennessee

  17. Quick Review • Gather requirements • Select a project life-cycle • Plan the project • Build a team • Then start the development of the software T. E. Potok - University of Tennessee

  18. Object-Oriented • Prior to OO was structured analysis • Keep function and data separate in analysis • Use data model for databases, functional models for software • OO combines data and function • Encapsulation • Inheritance • Polymorphism T. E. Potok - University of Tennessee

  19. Encapsulation • Provide a layer between the data of an object, and a calling method • This can insulate a calling method from having to be changed, in the initial data is changed T. E. Potok - University of Tennessee

  20. Example Person Age Weight Height healthIndex healthIndex := Age*(Weight/Height) Person Age (getAge(), setAge(int)) Weight (getWeight(), setWeight(int)) Height (getHeight(), setHeight(int)) healthIndex (getIndex(), setIndex(float)) setIndex(getAge()*(getWeight()/getHeight()) T. E. Potok - University of Tennessee

  21. Encapsulation Example • The setter methods can be used to put bounds on values, age can not be greater than 120, or less than 0 • The getter methods can be used to translate units, height from feet to meters • A change in the bounds, or units will require only a change to a few methods, not all the code that uses the attributes • For big changes, age to birth date, encapsulation does not help T. E. Potok - University of Tennessee

  22. Inheritance • The objects within an OO system can be organized in a class hierarchy • This hierarchy provides two means of inheritance • Method inheritance • Attribute inheritance T. E. Potok - University of Tennessee

  23. Method inheritance • An object can make us of any method that is defined higher in the class hierarchy • The code does not have to be copied, or rewritten, it just works • The method can be overridden if needed T. E. Potok - University of Tennessee

  24. Attribute Inheritance • Attributed from object higher in the hierarchy tree are also inherited • These attribute become available to the object, and do not have to be copied or defined • They can be overridden as well T. E. Potok - University of Tennessee

  25. Inheritance example Object Name Print Copy Collection Name Type Members Print Copy Sort Add(element) Delete(element) Bag Name Type Members Print Copy Sort (Overridden) Add(element) Delete(element) T. E. Potok - University of Tennessee

  26. Multiple Inheritance • Allows methods and attributes to be inherited for multiple object • Highlights the challenge of developing a class hierarchy • Has the potential for name collisions T. E. Potok - University of Tennessee

  27. Name collisions floorWax spread cakeIcing spread Fertilizer spread What spread method does fertilizer inherit from??? T. E. Potok - University of Tennessee

  28. Hierarchy Trees • Several ways to develop • Based on common functions or methods • With a many common methods, there is the opportunity for reuse • Based on common attributed • Common data can be an advantage particularly if you are using databases • Based on frequency of changes • Put stable methods higher in the hierarchy to lower the impact of change T. E. Potok - University of Tennessee

  29. Example • A hardware store can be laid out in a similar way • Based on functionality • Digging tools, cutting tools, hammering tools, ... • Based on data • Metal tools, wooden tools, plastic tools, ... • Based on frequency • Gum, nails, paint, rope, … • Based on domain • Gardening, household, garage, bedroom • No optimum way of doing so T. E. Potok - University of Tennessee

  30. Polymorphism • Calling similar methods in different class the same name • print • new • Not a new concept, used for arithmetic operations in other languages • Widely used in OO T. E. Potok - University of Tennessee

  31. OO Analysis • The development of an Analysis Model in the OO methodology converts: • User requirements • Into a high-level system model • In user terms not computer terms • This analysis is focused on • Defining objects and their interactions T. E. Potok - University of Tennessee

  32. More on OOA • OOA models may be done informally or more formally in object diagrams, ER diagrams, DFD diagrams, state-transition diagrams, or Petri nets • The OOA model consists of an object model, and may include a process model and a state model. • A process model describes the functional interaction of objects. This model is represented by the message paths among objects in an object model. • A state model can be used to determine the valid states for each object in the model. • An object state may change based on messages received from another object T. E. Potok - University of Tennessee

  33. Analysis Approaches • There are two main OO analysis methods used in the industry today • Booch • Rumbaugh NOT Rambaugh! • Booch tends to be less formal • Rumbauch has close similarities to structure analysis T. E. Potok - University of Tennessee

  34. Booch Analysis • Booch’s methodology can be summarized with four basic steps [Booch (1991)]. • 1) Identify the classes and objects for a given level of abstraction. • 2) Identify the semantics of the objects and classes; • 3) Identify relationships among the classes and objects • 4) Design the classes and objects. T. E. Potok - University of Tennessee

  35. Identify Classes and Objects • Assumes that you are given a specification of the problem • From this specification you underline the nouns in the specification • Then the nouns are used to create a list of potential objects in the system • This list is refined to define the objects and attributes T. E. Potok - University of Tennessee

  36. Semantics of Objects and Classes • Once the objects are defined, then the verbs in the specification are underlined • The verbs are listed as potential methods • The methods are added to the appropriate classes to add meaning to the classes T. E. Potok - University of Tennessee

  37. Identify Relationships • Often CRC cards are used: • Class, Responsibilities, Collaborators • 3 x 5 Cards with class information are arranged based on how objects flow in the system • This allows for modeling of the system, and defines how objects relate to each other T. E. Potok - University of Tennessee

  38. Design Classes and Objects • Refine the analysis model converting from real-world terms to computer terms • Expand the objects to include necessary system objects T. E. Potok - University of Tennessee

  39. Booch Summary • The strength of Booch’s methodology is the underlying object model. • This model consists of five diagram types, • class, • object, • state, • process, • module. • The class, object, and state diagrams represent the logical structures. • The process and module diagrams represent physical structures. T. E. Potok - University of Tennessee

  40. Rumbaugh’s OMT • Rumbaugh et al. produced the Object Modeling Technique (OMT) which presents a view of object-oriented development in three parts: • an object model, based on a modified ER diagram that supports inheritance relationships. • dynamic model, a state model based on state transition diagrams • functional model, a data-flow diagram T. E. Potok - University of Tennessee

  41. OMT • OMT defines three basic phases to create a low-level object-oriented design. • the analysis phase, the problem is defined, and solutions represented in object, dynamic, and functional models. • The next phase is the system design where the analysis model is mapped to the physical system. • The last phase is the object design where the analysis model is refined based on system model mapping, producing a low-level, language independent design ready for implementation T. E. Potok - University of Tennessee

  42. Summary • Exam Review • Team interactions • OO Analysis and Design T. E. Potok - University of Tennessee

More Related