USE CASE: text story of actor using SuD to meet goals. protocols), assignment of responsibilities.

3 Actor Types: Primary (has goals fulfilled by SuD, drive the Static Design Model: Representation of software objects
use case), Supporting (provides service to SuD), Offstage defining class names, attributes and method signatures.
(has interest in behavior of use case) Names and associations are inspired by domain model, to
Useful Use Case Tests: Boss Test (would boss be happy if reduce the Representational Gap (between how
use case was completed in a day’s work), Elementary stakeholders conceive the domain and its representation in
Business Process Test (Performed by one person, in one software – easier to comprehend and to update to
place/time, in response to business event which adds corresponding changes in the domain)
measurable business value and leaves data in consistent Responsibility Driven Design: focus on assigning
state), size test (task is seldom a single action/step; fully responsibilities to software objects. Responsibility:
dressed often require 3 – 10 pages) obligations or behaviours of an object in terms of its role.
Notation: Main success scenario first with N, alternative Two types: Knowing (knowledge of private/encapsulated
scenarios next using letters Nx. Use *x alternative that could data, related objects, things it can derive or calculate).
happen at any point. Doing (doing something itself – creating object or
When partial behaviour common across multiple use cases, calculating something, initiating action in other objects,
use <<include>> and refactor into a subfunction use case. controlling and coordinating activities in other objects). Can
When adding new extensions or conditional steps, use be implemented in collaboration with other objects.
<<extend>> (primary actor interacts with base case which is Dynamic Design Model: Representation of how objects
complete without extension, extension relies on base case) interact via messages.
Diagram: primary actors on left, supporting on right Notation: <<destroy>> -> X; create(constructorArgs)->X (at
(computer systems use box), limit use cases to user-goal height of creation); loop and alt frames can be placed with
level. [guard] and action boxes with plain text placed over lifeline
of object to which it applies. sd and ref and be used to
DOMAIN MODELLING: OO Analysis creates description of define/refer to sub-diagrams (must cover the same lifelines
the problem domain from perspective of objects. Shows and have same name.
conceptual classes, attributes and associations in the Visibility: The scope or ability of an object A to see/access
problem domain. another object B. Four ways (B attribute of A, B parameter
Conceptual Class: representation of real-situation of method in A, B local object in method of A, B has some
conceptual classes (idea/thing/object; {symbol: represents form of global visibility)
class; intension: definition of class; extension: set of Communication vs Sequence Diagram: More layout
examples for which it applies}) options, clearly shows relationships between object
Description Class: contains information that describes instances, combines scenarios to provide complete picture.
something else, used when a group of items share a But More difficult to see message sequencing, fewer
description, and items need to be described even when notation options for expressing message patterns.
there are currently no examples. Map Design to Code: Begin at least coupled classes (so that
Class Identification: use existing models for common more coupled classes can be defined in terms of already
domain problems, use a category list, perform noun mapped classes). For multiplicities, choose the appropriate
extraction. collection that supports requirements (key-based lookup:
Association: relationship that indicates Map, growing ordered list: List). If it implements an
meaningful/interesting connections b/w classes. Include interface declare in terms of the interface.
ones which are significant in domain, knowledge of which
needs to be preserved, or are derived from common GRASP: set of patterns/principles of assigning
associations table. responsibilities to objects. (captures and facilitates reuse of
Generalisation: Define a superclass (with general concept) expertise to make accessible to non-experts, improves
and subclass (with specialized concept), related by set understanding and communication by providing common
membership, to reduce repeated information and improve language.
comprehension. Creator: Who should be responsible for creating a new
Attribute: A logical data value of an object, included in instance of class A? (Doing Responsibility)
classes when requirements imply need to remember Assign class B responsibility to create instances of class A if:
information. Use (/attribute for derived attribute). B ‘contains’ or compositely aggregates A; B records A; B
Use subclass when there are additional attributes of closely uses A; B has the initialising data for A.
interest, or operated on/manipulated/reacted to differently Note: This is useful for low maintenance and high reuse
(else have a type attribute). potential (low coupling). If creation of objects is complex
SSD: Visualisation of system events that external actors (conditionally creating instance from a family of similar
generate and possible inter-system events, showing their classes based on external property) then delegate creation
order for a particular scenario. Captures dynamic context, to (concrete/abstract) Factory helper class.
treating system as black box with reference to domain Information Expert: Given object X, which responsibilities
model. (doing/knowing) can be assigned to X?
Assign responsibility to X if X has the information to fulfill
DESIGN MODELS: a conceptual solution to a problem that that responsibility.
meets requirements, emphasizing defining software objects Note: Sometimes produces undesirable design due to
and their collaboration: structure and connectedness (levels problems with the resulting dependencies.
and architecture), interfaces (methods, datatypes and
Low Coupling: How to support low dependency, low change impact on other elements?
impact, and increased reuse? Identify points of known or predicted variation or instability
Coupling: how strongly one element is connected to (has and assign responsibilities to create a stable interface
knowledge of, or relies on) other elements around them (in the general access sense of ‘interface’).
High Coupling: Hard to understand in isolation, hard to Notes: Two types of points of change: Variation Points
reuse, one change impacts many classes (high impact (variation existing within the current system requirements),
change) Evolution Points (speculative variations that may arise in the
Assign responsibilities to avoid unnecessary coupling and to future). PV is a root principle motivating most patterns in
keep coupling low. Use this to evaluate alternatives. Low design, equivalent to Open Closed principle. However cost
coupling minimises dependencies, making the system more of future proofing at evolution points can outweigh the
maintainable and improving reusability of code. benefits.
Note: High coupling with stable and well understood
elements (Standard Java Libraries) is generally OK. TEST DRIVEN DEVELOPMENT: Test code written before the
High Cohesion: How to keep objects focused, code it will test (acceptance tests at the start of iteration,
understandable, and manageable, and as a side unit tests before the corresponding class), ensure tests are
effect, support Low Coupling? passed before proceeding.
Cohesion: How strongly related/focussed the Pros: Tests actually get written, programmer satisfaction
responsibilities of an element are. leads to more consistent test writing, clarification of
Assign responsibilities to avoid unnecessarily reducing detailed interface and behaviour, proven & repeatable &
cohesion. Use to evaluate alternatives. Improves ease of automated verification, gives developers confidence to
comprehension, simplifies maintainability and make changes.
enhancement. Refactoring: Structured, disciplined method for rewriting or
Note: sometimes low cohesion is necessary for non- restricting existing code without changing its external
functional requirements (performance reasons). behaviour, through a series of small behaviour preserving
Controller: Which first object beyond the UI layer receives transformations after each of which unit tests can be
and coordinates a system operation? redone to prevent regression/failure.
Assign responsibility to one of: STATE MACHINE DIAGRAM: A behaviour model that
[i] Façade controller: representing the overall system. captures the dynamic behaviour of an object in terms of
[ii] Use case or session controller: representing a particular states (condition of object at given moment), events
use case scenario dealing with an event. (significant/noteworthy occurrence), and state transitions
Note: If controller is bloated with low cohesion and too (directed relationship between two states corresponding to
many responsibilities: add more session controllers, or an event). They should be used for state dependent objects
delegate responsibilities if it is violating information expert. (whose response to an event depends on the object’s state,
Indirection: Where to assign a responsibility to avoid direct rather than state independent (/wrt an event) objects)
coupling between two or more things (to maintain low Nested States: inherit the transitions from its superstate,
coupling and increase reuse potential)? and must have their initial state indicated.
Assign the responsibility to an intermediate object to Choice Pseudostate: realises a dynamic conditional branch,
mediate between the other components or services so that evaluating guards of the triggers of its outgoing transitions
they are not directly coupled. and selects only one.
Note: can decrease performance.
Pure Fabrication: Which object should have responsibility GOF DESIGN PATTERNS: three categories of pattern:
when you do not want to violate High-Cohesion and Low- Creational (abstract the process of object instantiation),
Coupling, but solutions offered by other are not Structural (combine classes and objects to form larger
appropriate? structures, describe ways to define relationships between
Assign a highly cohesive set of responsibilities to an artificial classes),
or convenience class that does not represent a problem Behavioural (most specifically concerned with
domain concept. communication/interaction between objects).
Note: Do not overuse, since it increases representational Façade: Require a common, unified interface to a disparate
gap and can adversely affect coupling by increasing set of implementations or interfaces—such as within a
dependencies. subsystem. There may be undesirable coupling to many
Polymorphism: How to handle alternatives based on type objects in the subsystem, or the implementation of the
(conditional variation), and create pluggable software subsystem may change.
components? Define a single point of contact with the subsystem, a
When related alternatives or behaviours vary by type, façade object which wraps the subsystem, and represents a
assign the responsibility for the behaviour to the types for single unified interface responsible for collaborating with
which it varies using polymorphic operation (with a the subsystem components.
common stable interface) Example: need a rule engine subsystem with a currently
Note: This makes the design easily extendible to handle unknown implementation (desire pluggability) in a POS
new variations. Can result in unnecessary effort if applied to system.
speculative points of future variation which are improbable. Decorator: How to dynamically add behaviour or state to
Protected Variations: How to design objects, subsystems, individual objects at run-time without changing the
and systems so that the variations or interface presented to the client?
instability in these elements does not have an undesirable Encapsulate the original concrete object inside an abstract
wrapper interface, and let the decorators (which contain Define classes for composite and atomic objects so that
the dynamic behaviours) also implement this abstract they implement the same interface. If there are multiple
interface. Then let the interface use recursive composition conflicting strategies these can be handled in a singleton
to allow unlimited decorator layers to be added to each composite strategy factory.
core object:

Template: How to build generic components that are easy

to extend and to use without replicating code?
Builder: How can a class (using the same construction Define a family of algorithms, encapsulate each one and
process) create different representations of a complex make them interchangeable. Implement invariant parts in
object? the superclass, and varied behaviour in the subclasses.
Encapsulate creating and assembling parts of the complex Observer: Different kinds of subscriber objects are
object in a separate builder object, instead of creating the interested in the state changes or events of a publisher
objects directly. This hides the internal representation of object, and want to react in their own unique way when the
the object from the client. publisher generates an event. How should this be done to
maintain low coupling between the publisher and
subscribers?
Define a Subscriber interface, which is implemented by
subscribers. The publisher can then dynamically register
subscribers interested in an event and notify them when an
event occurs.

Adapter: How to resolve incompatible interfaces, or provide

a stable interface to similar components with different
interfaces?
Convert the original interface of a component into another
interface through an intermediate adapter object. This
decouples the client from the interface implementation and
encapsulates interface changes within the adapter. Adds a
level of indirection to varying APIs in other components.
(Concrete) Factory: Who should be responsible for creating SOFTWARE ARCHITECTURE: the large-scale organization of
objects when there are special considerations, such as elements in a software system; a design which meets high
complex creation logic or a desire to separate creation impact system requirements, support business logic, and is
responsibilities for better cohesion? straightforward to maintain and evolve. Involves decisions
Create a pure fabrication object called a factory to handle concerning: structural elements (what are the
creation. This also allows the introduction of performance classes/components in the system?), interfaces (how are
enhancing memory management strategies such as object the elements composed together?), collaboration (how
caching or recycling. should these elements work together according to business
Singleton: When precisely one instance of a class is allowed, logic?), composition (How should these elements be
and other objects need a single, global point of access. grouped progressively into larger subsystems?)
Define a static method getInstance() for the class that Architectural Analysis: An activity to identify factors that
returns the singleton (and hide its constructor). will influence architecture, understand their variability and
Note: we do not make all singleton methods static to allow resolve them; identify the system’s non-functional
for polymorphism. requirements in the context of its functional requirements.
Strategy: How to design for varying but related algorithms The goal is to reduce risk of missing a critical factor in the
or policies, and the ability to change them? design of the system, focus effort and high priority
Define each algorithm/policy/strategy in a separate class requirements, and align the product with the business
with a common interface. goals.
Composite: How to treat a group or composition structure Process: Identify and analyse architecturally significant
of objects the same way (polymorphically) as non- requirements (things that can have a large impact on the
composite atomic objects? design, especially if not considered from the beginning),
points of variation and potential points of evolution.
Architecturally Significant Requirements: (components are clients and servers)
Functional: Auditing, Licensing, Mail, Printing, Security etc. Peer-to-peer: Roles of client and server switch between
Non-Functional: Usability (aesthetics, consistency in UI), components.
Reliability (availability, accuracy of calculations, ability to
recover from failure), Performance (throughput, response
time, recovery time etc.), Supportability (testability,
maintainability, scalability, configurability etc.)
Common Steps: Occurs in early elaboration phase. Identify
and analyse architectural factors (requirements with impact
on architecture). For each factor analyse alternatives and
create solutions: architectural decisions.
Priorities: Inflexible constraints (safety, security, legal
compliance), Business goals (eg: competitor driven window
of opportunity), other goals (eg: extendibility for a new Pipeline: Filter components read data from an input Pip and
release every 6 months.) write to an output Pipe. Can be static and linear, or dynamic
Architecture Factor Table: A document which records the and complex.
influence of factors, their priorities and their variability
(immediate need for flexibility and future evolution). It THE SOFTWARE PROCESS: UP is an iterative and
includes the following: Factor, Measures and Quality incremental software development process: inception,
scenarios, Variability, Impact of factor and variability on elaboration, construction, transition.
stakeholders and architecture, Priority for success, Difficulty Inception: The initial short step to establish common vision
or Risk. and basic scope for the project. What is the vision and
Technical Memo: A document that records alternative business case? Is it feasible? Should we buy or build
solutions, decisions, influential factors and motivations for services? Rough budget range? Do stakeholders have basic
the noteworthy issues and decisions. It includes: Issue, agreement on the vision, and is it worth investing in serious
Solution Summary, Factors, Solution, Motivation, investigation?
Unresolved Issues, Alternatives Considered. Should we proceed or stop?
Not Inception if: takes more than a few weeks, most
LOGICAL ARCHITECTURE: The large-scale organization of requirements are defined, estimates expected to be
the software classes into packages, subsystems and layers. reliable, architecture defined, sequence of work planned,
It defines the packages in which software classes are business case/vision not defined, all use cases written or no
defined. use cases written.
Layered Architecture: Course-grained grouping of classes, Artifacts of inception: Vision and Business case: describes
packages and subsystems that has cohesive responsibility high level goals and constraints, business case and provides
for a major aspect of the system. executive summary.
Example: User interface, Application logic + Domain Use-Case Model: Describes functional requirements. Names
Objects, and Technical Services (general purpose objects of most use cases identified, ~10% analysed in detail.
and subsystems that provide supporting technical services Iteration-Plan: Describes what to do in first elaboration
such as database interfaces), Foundation (Core services/ iteration.
infrastructure) are examples of layers in a layered And Optionally:
architecture. Supplementary Specification: describes other requirements
Strict Layered Architecture: A layer only calls upon the (mostly non-functional), to find key non-functional
services of the layer directly below it; not common in requirements of architectural significance.
information systems. Glossary, Prototypes/Proof of Concept, Risk list &
Relaxed Layered Architecture: A higher layer calls upon Management plan, Phase Plan& Development Plan (low
several lower layers; common in information systems. precision guess for elaboration phase duration and effort,
Guidelines: organize large scale logical structure of the tools, people, education and resources), Development Case:
system into distinct cohesive layers from highly application Description of the customized UP steps and artefacts for
specific to low general services. Collaboration and coupling project.
should only go from higher layers to lower layers. Do not Elaboration: The initial series of iterations for building the
show external resources as the bottom layer. core architecture, resolving the high-risk elements, defining
Benefits: Helps address: changes rippling through the most requirements and estimating overall schedule and
system due to coupling, intertwining of application logic resources. ~80% of requirements reliably defined.
and UI (which reduces reuse and restricts distribution Artefacts of Elaboration: Domain model, Design Model,
options), intertwining of general technical services of Software Architecture Document, Data model, Use Case
business logic with application specific logic (reduces reuse, Story boards, UI Prototypes.
restricts distribution options and complicates replacement), Note: Use cases are spread across iterations, inevitable
high coupling across areas of concern (impacts division of changes are provoked early. Do the right thing, to the thing
development work). right.
Distributed Architecture: Components hosted on different
platforms and communicate through network.
Client-Server: Server perpetually listens for client requests,
processes received requests and sends response