Software Design and Development

1. Software Design and Development James H. Harrison, Jr., M.D., Ph.D. Center for Biomedical Informatics University of Pittsburgh Medical Center Cancer Pavilion 310 Pittsburgh, PA jhrsn@pitt.edu

2. Outline • General approach to object-oriented design • Large program lifecycle management • Phases of software development and management • Key documents in software development • Analysis and design methods • Older approaches • Modern object-oriented analysis and design • Modeling and UML (Unified Modeling Language) in OO software development

3. Features of Object-Oriented Programs • Each component provides a service or set of services through its interface. • Other components are users or clients of the services. • A client only needs to understand the interface of a service – implementation details are not important, they may be changed and shouldn’t affect the client at all! • This separation of concerns makes the design of complex systems possible.

4. Guidelines for Designing Objects • Look for object candidates • Understand the problem • In a statement of the problem, nouns are often clues to what objects should be created • Things that can be fully represented as basic data types (strings, numbers) should generally not be objects • Look for groupings of related data items (employee data, lab test requirements and parameters) • Define a set of objects helpful in solving the problem

5. Guidelines for Designing Objects • Identify instance variables • What items of information does each object need to do its job? • Often basic data types (strings, numbers) • May also be lists or other objects (classes) • Objects provide a “home” for related data types

6. Guidelines for Designing Objects • Design object interfaces • Interfaces are groups of methods • What operations are required for objects of each class to be useful? • Verbs in the problem statement describe actions that are clues to needed methods • List the methods for each object (may use UML class diagrams or cards) • All manipulation of an object’s data should normally be done through the object’s own methods (provides best object modularity)

7. Guidelines for Designing Objects • Develop and refine non-trivial methods • Some methods require just a few lines of code, and others may require more complex programming • Use top-down design and stepwise refinement for the more difficult methods • As you develop methods, you may find that additional methods are needed in the current class or in other classes • You may also find that some methods and data should be separated into additional classes

8. Guidelines for Designing Objects • Design iteratively • May alternate between adding/refining methods in existing classes, creating new classes and modifying the main program • Progress logically, working on whatever needs attention • It is unusual to design a program top to bottom in a linear, systematic fashion

9. Guidelines for Designing Objects • Try out alternatives • Small alternative code fragments can be tested by typing them into the interactive interpreter • Methods and classes can be tested by importing them into the interactive interpreter or writing tests in the main module • It’s OK to try one approach, then scrap it in favor of a better approach • In a working program, this is called refactoring

10. Guidelines for Designing Objects • Keep it simple • At each step in the design, try to find the simplest approach that will solve the problem. • Don’t design in extra complexity until it is clear that a more complex approach is needed • If your code is becoming complex, that often signals the need to re-think, or to separate code into additional methods or objects

11. Developing Larger Programs

12. Software Lifecycle Process Management • Software process: strategy and set of techniques to manage software and associated information from definition of needs to maintenance in production. • Requirements definition, analysis, design, programming, testing, delivery, maintenance and change control • Up to 85% of software development projects fail • Management of large projects is challenging; adding programmers does not scale up development capacity • Thriving community of consultants and academics developing software process management techniques

13. Key Documents in Software Development • Scope document (Statement of Work, RFP; from users) • Definition of current environment and work processes • High level description of software and how it will work from a users perspective, defines the scope of the project • Any software/hardware requirements or constraints, but no technical design • Requirements document (from users) • Required features in bullet points • May be attached to Scope document • Design document (from developers) • Class model, technical design and development tools, deliverables, hardware, costs, testing strategy, project management model, timeline

14. Our View of Software Development So Far… Main () { printf (“Hellog World”) } Write code in editor [compile] Test program - Run Hellog World Main () { printf (“Hello World”) } Debug Distribute the program Hello.exe 011100010001... Run the executable Hello World

15. The Larger View… Scope Document Analysis Technical Design Document Design Main () { printf (“Hellog World”) } Write code in editor Coding • Development group • Project manager • 1-3 domain experts • 1-4 programmers Test program - Run Hellog World Debug Main () { printf (“Hello World”) } Distribute the program Hello.exe 011100010001... Run the executable Hello World Prototyping/milestone signoff Evaluate Final signoff Acceptance

16. Software Process Management Initiation Construction Delivery Production Justify Define and Validate Initial Requirements Define Initial Management Documents Model Generalize Program Component Testing System Testing Rework Release Support Identify Defects and Enhancements Assess Define Infrastructure Assure quality, Manage the project, Train and educate, Manage people, Manage risk Manage reuse, Manage metrics, Manage deliverables, Manage infrastructure

17. Analysis and Design Patterns • Pattern: a strategy that has been shown to work and to be generalizable (workflow or coding) • Software projects are complex, expensive and difficult to manage; many fail • Cottage industry in designing development strategies to limit risk and avoid failure • Examples: • Waterfall • Iterative • Incremental • OOSP, The Unified Process • Extreme Programming (XP)

18. Waterfall (1970's) Analysis Design Programming Testing Best for large, mission critical systems with well-known requirements Fits procedural development Implementation

19. Waterfall (1970's) Analysis Design Programming Testing Revision of previous steps is difficult Long development time without revision may create out-of-date software Implementation

20. Iterative Development (1980's) Analyze Done Test Design Prototypes into users hands quickly Involves users in design Decreases risk (prototypes can be used) Good when requirements aren't completely known (can evolve) Difficult to define deliverables up front Prototype

21. Requirements Design Coding and Unit testing System integration Operation & maintenance Continuous Development: Spiral Model Evaluate Set Goals Model for continuous software development Addresses business/medical environment with continuous change Movement “out” represents increasingly evolved systems Identify alternatives Risk/benefit analysis Choose solution Implement software

22. Incremental Development • Logical division of a system into small applications that work together • Small apps developed and delivered separately • Delivery schedule is planned at start of project but can be modified • Easier and lower cost than a "big bang" approach • Doesn’t work for all systems (air traffic control)

23. Object-Oriented vs. Procedural Development Object-Oriented Procedural Applications are built from interacting objects that contain data and methods Applications are built from collections of functions and procedures that read & write data Complex systems Systems that are prone to change Graphical user interfaces Client-server systems E-commerce systems Enterprise application integration Large, mainframe based batch-transaction systems Systems where requirements can be specified in detail before development and do not change Systems where OO cannot be used for the entire development

24. The Object-Oriented Software Process Initiation Construction Delivery Production Justify Define and Validate Initial Requirements Define Initial Management Documents Model Generalize Program Component Testing System Testing Rework Release Support Identify Defects and Enhancements Assess Define Infrastructure Assure quality, Manage the project, Train and educate, Manage people, Manage risk Manage reuse, Manage metrics, Manage deliverables, Manage infrastructure

25. The Unified Process • Iterations within major steps create deliverables for testing • Borders between major steps include go/no go decisions • Allows termination of projects that are not progressing Inception Elaboration Construction Transition Production

26. Extreme Programming (XP, ~1996) • Good for poorly-understood or rapidly-changing requirements • Small development teams including users • Write acceptance tests before coding • Write experimental code to test solutions to problems • Many small releases to users with redesign based on feedback • Continually redesigning/rewriting code

27. Extreme Programming Planning Coding Write user stories (use cases) Create the schedule Make frequent small releases Measure progress Divide project into iterations Iteration planning starts each iteration A stand-up meeting starts each day Users are members of the development team Code must be written to agreed standards Tests are written before coding All production code is pair programmed Only one pair integrates code at a time Integrate often Favor simplest solutions Leave optimization till last No overtime Designing Testing Simplicity (simplest model that will work) Use CRC cards for design sessions Create experimental code to test solutions Refactor continuously All code must have unit tests All code must pass all unit tests before it can be released When a bug is found tests are created Acceptance tests are run often and the score is published

28. Data and Process Modeling in OO Design • Modeling is a key distinguishing feature of OO design • Logical models built with users can be translated into code • Data models reflect classes and their attributes • Process models describe a set of actions taken to accomplish a buisness or workflow objective • May reflect interactions between workers or between class instances • Modeling processes is crucial for understanding user activities in complex and/or multiuser systems and translating them into software • Optimal processes for new systems may not be identical to optimal processes with manual or legacy systems (analysis phase of projects)

29. Steps in Object-Oriented Modeling • Create classes representing data entities (these may be physical documents or workers) • Determine the responsibilities of classes • Methods and attributes are derived from these in the coding phase • Determine class interactions • Create a user interface prototype • Modeling is commonly carried out using UML (the Unified Modeling Language) diagramming

30. Components of the UML • Use Case diagrams • Class diagrams • Interaction diagrams • Sequence: instance lifelines, messages • Collaboration: object messaging • State diagrams: lifetime behavior of a single object • Activity diagrams: sequence of actions carried out by a program • Physical diagrams • Deployment: hardware, networking • Component: software components with interactions and dependencies • Often combined

31. Activity Diagram of Existing Practice

32. "Re-engineered" Process Model

33. CRC Cards for Class Modelingclass-responsibility-collaboration Class name Create set of 3x5 cards with class names only Arrange cards in a logical layout and finalize class list Add responsibilities to cards Determine collaborations and add to cards Responsibilities Collaborations Order Example: Check if items in stock Order line Determine price Check for valid payment Customer Dispatch to delivery address

34. Summary • Software management includes the entire lifecycle of a system from design to development and deployment through maintenance and support • Software development is complex, expensive and high risk • All major development projects should include scope and design documents, a timeline with verifiable milestones and frequent user input • A variety of processes with have been proposed for the management of software development • Object-oriented development is useful for complex systems with changing requirements • A key component of object-oriented development is cooperative modeling of workflow and software structure

35. References • Weisfeld, M. The Object-Oriented Thought Process. Indianapolis: Sams Publishing, 2000. • Ambler, SW. The Object Primer, 2nd Edition. Cambridge, UK: The Cambridge University Press, 2001. • Fowler, M. UML Distilled, 2nd Edition. Reading, MA: Addison-Wesley, 2000. • The Extreme Programming Web Site. http://www.extremeprogramming.org/