Announcement

1. Announcement • No CHC visit tomorrow • Team progress / issues survey • list team members, and attendance today • describe progress so far • describe intended path into the future • describe team problems/issues/questions (technical, team-work related or other)

2. Design in context • Recall SADCITDM • Design is the bridge between requirements and code: • design comes after software requirements • design comes before coding Reading: Section 3.5 and Chapter 5 from Code Complete 2 Notes are from: • Software Engineering, A Practitioner’s Approach by Roger Pressman. • Software Engineering by Ian Sommerville • Code Complete 2 by Steve McConnell

3. Types of design • Architectural design • basic structure / major components of system • repository model (centralized data storage) • client-server model (distributed system) • abstract machine model (layered system) • control models • centralized control (e.g. typical single-threaded application) • event-driven • decomposition • object-oriented models (focus on objects) • data-flow models (focus on flow of data and transformation of data as it flows through the system)

4. Types of design • Interface design • internal interfaces: interaction amongst components of the system • external interfaces: interaction with external systems, devices (producers and consumers of information) • user interfaces: interaction with human users

5. Types of design • Component design • a component is a “modular building block” • a component consists of one or typically more than one module / class • a component may already exist (e.g. COTS)

6. Levels of design • Software system • Division into subsystems/packages [ARCHITECTURE] • Division into classes within packages [COMPONENT & (EXTERNAL) INTERFACE DESIGN] • Division into data and routines within classes [CLASS & (INTERNAL) INTERFACE DESIGN] • Internal routine design [ALGORITHM DESIGN] Modified from Code Complete 2

7. Common design principles 1. Abstraction • how we deal with complexity (hierarchy of abstractions) • procedural abstraction (open, insert) vs. data abstraction (door, collection) Example: structure of US government

8. Common design principles 1. Abstraction • how we deal with complexity (hierarchy of abstractions) • procedural abstraction (open, insert) vs. data abstraction (door, collection)

9. Common design principles 1. Abstraction • how we deal with complexity (hierarchy of abstractions) • procedural abstraction (open, insert) vs. data abstraction (door, collection)

10. Common design principles 1. Abstraction • how we deal with complexity (hierarchy of abstractions) • procedural abstraction (open, insert) vs. data abstraction (door, collection)

11. Common design principles 2. Architecture • overall structure of a software system • major components (modules) and their relationships (components exist at different levels of abstraction)

12. Common design principles 3. Patterns • a best-practices solution structure & strategy to a family of problems • GOF patterns represent a very small subset of documented patterns

13. Common design principles 3. Patterns (continued) • Architectural patterns – Design patterns – Coding patterns (idioms) • Frameworks • problem-specific skeletal infrastructure, with hooks for specialized functionality • many 115 labs have a simple framework at their core

14. Common design principles 4. Modularity • modules are cohesive components of the overall software system • perceived complexity of the combination of two problems P and Q is typically greater than of P and Q taken individually: divide & conquer

15. Common design principles 5. Information Hiding • make capabilities visible to users of a module, but • keep algorithms and data structures hidden from users of a module

16. Common design principles 6. Functional Independence • high cohesion (module has a well-defined purpose) • low coupling (module has no unnecessary interactions with other modules)

17. Common design principles 7. Iterative Refinement • process of moving from models with high abstraction to models with low abstraction (more concrete)

18. Common design principles 8. Refactoring • functionality preserving • improves quality (e.g. increases cohesion, decreases coupling, enhances extensibility, reduces modifiability, etc.) • goal of refactoring should be a pattern

19. Common design principles 9. Design classes: types • user-interface classes: abstractions related to user interaction • business domain classes: abstractions that model business domain • process classes: support/implement business domain classes • persistent classes: persistent data storage • system classes: manage non-UI external interactions with the system

20. Common design principles 9. Design classes: characteristics • complete & sufficient • primitiveness • high cohesion • low coupling

21. Use Case Diagram Component Diagram Activity Diagram Statechart Diagram Class Diagram Sequence Diagram Deployment Diagram Full UML specification is available at: www.omg.org Material from: OMG UML Spec v1.5 The Object Primer by Scott Ambler UML Diagrams(selected)

22. Use Case Diagrams • “A use case [represents] a coherent unit of functionality provided by a system” [OMG UML v1.5, p. 3-96] • “An actor defines a coherent set of roles that users of an entity can play when interacting with [it]” [OMG UML v1.5, p. 3-97] • “Use case diagrams show actors and use cases together with their relationships.” [OMG UML v1.5, p. 3-94]

23. Component Diagrams • “…shows the dependencies among software components…” [OMG UML v1.5, p. 3-169] • “A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” [OMG UML v1.5, p. 3-174] • “Although a component does not have its own features […] it acts as a container… Components typically expose a set of interfaces, which represent the services provided by the elements that reside on the component.” [OMG UML v1.5, p. 3-170

24. Activity Diagrams • An activity diagram shows logic of a single use case • nodes represent activities • arcs represent control flow • fork/join • condition (guard)/decision/merge • partitions (swim lanes)

25. Statechart Diagrams • “…describes possible sequences of states and actions through which the element instance [e.g. object] can proceed during its lifetime as a result of reacting to discrete events (for example, signals, operation invocations).” [OMG UMG v1.5, p. 3-135]

26. Class Diagrams • Static structure diagram • shows components and relationships

27. Sequence Diagrams • “…model the flow of logic within your system…” • “…typically used to model the following: • Usage scenarios. […] • The logic of methods. […] • The logic of services. […]” [Ambler, p. 321]

28. Deployment Diagrams • “…show the configuration of run-time processing elements and the software components…that run on them” [OMG UML v1.5, p. 3-171]

29. Broker Model-View-Controller Presentation-Abstraction-Control Microkernel Reflection Layers Pipes and filters Blackboard Some Architecture Patterns(www.rationalrose.com/models/architectural_patterns.htm)

30. Broker pattern • “…can be used to structure distributed software systems with decoupled components that interact by remote service invocations. A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions”

31. Model-View-Controller (MVC) pattern • “…divides an interactive application into three components. The model contains the core functionality and data. View display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.”

32. Presentation-Abstraction-Control (PAC) pattern • “…defines a structure for interactive software systems in the form of a hierarchy of cooperating agents. Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.”

33. Microkernel pattern • “…applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.”

34. Reflection pattern • “…provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior.”

35. Layers pattern • “…helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.”

36. Pipes and Filters pattern • “…provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems.”

37. Blackboard pattern • “…is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems assemble their knowledge to build a possibly partial or approximate solution.”