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. UML Diagrams (selected)
Use Case Diagram
Component Diagram
Activity Diagram
Statechart Diagram
Class Diagram
Sequence Diagram
Deployment Diagram
Full UML specification is available at:
Material from:
OMG UML Spec v1.5
The Object Primer by Scott Ambler

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 ]
“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 ]
“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

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 ]

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 ]

29. Some Architecture Patterns (www. rationalrose
Some Architecture Patterns (
Broker
Model-View-Controller
Presentation-Abstraction-Control
Microkernel
Reflection
Layers
Pipes and filters
Blackboard

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.”