Software Systems Design

Name

A convenient handle for the pattern itself. It should be a name to help remind the user of the intent of the pattern

Use Case Analysis

A technique used to identify the requirements of a system.

UC Exhaustive Alternatives

A use case may have many alternatives. Missing some means that the developers will misunderstand the system's behavior and the system will be deficient. Capture all failure and alternatives that must be handled in the use case.

UC Interrupts as Extensions

An alternative that affects more than one step in a scenario can scatter related details throughout a use case, causing the reader to become confused or lose track of important information. In this case create an extension use case when an alternative course of action interrupts a number of steps in a scenario.

Inheritance

An inheritance hierarchy can be created by factoring common attributes and behaviors from a group of classes to create a super class.

Unified Process

An iterative, incremental development process with 4 major phases: inception, elaboration, construction, and transition.

OOD Understandability

Another designer should be able to easily understand the system design.

Construction (Initial Operational Capability Milestone)

Build the product to the point where it can be delivered to its end-users for the first time.

Frameworks

Cohesive sets of interfaces and classes that collaborate to provide services for the core, unvarying part of a logical subsystem.

Inception (Vision milestone)

Define the vision of the product, scope of the product and the business case. It's not just requirements but feasibility too.

Solution

Describes elements that make up the design. (It does not describe a particular concrete design or implementation, just a general arrangement of how objects and classes solve the problem.

Domain Model

Documents the key concepts and vocabulary of the systems. It is a visual representation of conceptual classes that specify conceptual classes and their attributes and associations via a UML class diagram.

UC Leveled Steps

Excessively large or excessively small use case steps obscure the goal and make the use case difficult to read and comprehend. Each scenario should have 3 to 9 steps. Ideally they are all at similar levels, a level of abstraction just below the use case goal.

System Operation Contracts

For each operation, write Responsibilities (purpose of operation) Pre-Conditions (state of the system before execution of the operation) Post-Conditions (state changes to objects in the conceptual model, e.g., instance creation/deletion; attribute modification, association creation/deletion)

GRASP Patterns

General Responsibility Assignment Software Patterns - a learning aid to help master the basics of OOD such as assigning responsibilities to classes.

UC Complete Single Goal

Improper goals will leave the writers deciding where one use case ends and another begins. Write each use case to address one complete and well-defined goal. That goal may be at any level in the ever unfolding story.

UC Technology Neutral

Including technology constraints and implementation details in a use case description increases the complexity and obscures the goal of the use case. Write each use case in a technology neutral manner.

Design Model

Modeling structure and collaboration via class diagrams and interaction diagrams.

Sequence Diagram

Models dynamic aspects of a system

Use Case Diagram

Models external interaction of the system

Deployment Diagram

Models physical architecture

Class/Object Diagram

Models static structural aspects of a system

Architecture

Organization and structure of a software system into components.

Elaboration (Architecture Milestone)

Refine the definition of the product, define baseline architecture, develop a more precise plan for its development and deployment. High risk issues are mitigated here.

Consequences

Results and trade-offs of applying the pattern.

Problem

States when to apply the pattern. It explains the problem and its context.

OOD Usability

That aspect of application design that enables a user to understand and use the application easily.

UC Scenario Plus Fragments

The reader must be able to easily follow the path through the specific scenario or story that they are interested in, otherwise they are likely to become frustrated or miss important information. Write the success story line as a simple scenario without any consideration to possible failures. Below it, place story fragments that show what alternative condition might have occurred.

Use-case driven

To build a successful system you must know what the users want and need (user could be another system). The use case describes the complete functionality of the system.

Transition (product release milestone)

Transition the product the user community. This includes manufacturing, delivering, training, supporting and maintaining the product.

OOD Maintainability

Where it is easy to extend functionality or fix defects.

UC Common Sub Behavior

Writing the same steps for different use cases is wasteful and makes it more difficult to see common sub-processes within a use case model. Express shared courses of actions with <<included>> use cases. Includes and extends were originally intended to simplify the use case model by collecting common threads in the use case model.

Encapsulation

a class that packages together closely related methods and attributes.

Abstraction

a mechanism and practice to reduce and factor out details to promote understandability and decrease the representation gap between a software system and its problem domain.

Classification

a problem in finding sameness. Classes should group things that have a common structure, exhibit a common behavior, or have the same relationships. Ultimately, a class is a blueprint for creating objects.

OO Realization

a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out.

Inception Checkpoint

a short step to elaboration. It is the first phase in the unified process. It determines basic feasibility, risk, and scope to decide if the project is worth more serious investigation.

Unified Modeling Language (UML)

a standard visual modeling language to express analysis and design artifacts of object-oriented systems.

OO Dependency

a using relationship that states that a change in one object may effect a change in another that uses it, but not necessarily the reverse

Architecture-centric

a view of the whole design with the important characteristics made visible by leaving details aside. Every product has both function and form. Function is to use case and form is to architecture.

Polymorphism

allows objects of varying type, but with the same interfaces, to be substituted for each other at runtime. It also promotes software extensibility; however, it can impact performance and make code difficult to understand. In the example below, the move() method behaves differently in both classes.

Facade Pattern

an object that provides a simple interface to the larger body of code. The Façade hides the complexities of the system and provides an interface so the system can be used. For example, in Java, the interface JDBC can be called a façade. The illustration below will give you an idea as to how this architecture will look.

Actors

are external entities that interact with a system. They define a role played by entities when they interact with a system.

Activity states

can be decomposed and interrupted. The work of an activity is considered to take some duration to complete. An activity state can therefore be considered as a composite whose flow of control is made up of other activity and action states.

Action State

cannot be decomposed or interrupted. The work of an action is considered to take insignificant execution time.

Domain Modeling

captures the most important types of objects in the context of the system. Domain objects represent the "things" that exist or events that transpire in the environment in which the system works.

Implementation model

components representing source code and mapping of the classes to components

Top Level Use Case Diagrams

context diagrams that show the boundary of a system. It shows the interface between the actors and the system and determines the scope of the system by clearly defining its boundary. They are also referred to as the system context diagrams.

business object

could represent something that is manipulated in a business such as orders, accounts, and contracts.

Deployment model

defines physical nodes of computers and the mapping of the components to those nodes

Design Model

defines the static structure of the system as subsystems, classes and interfaces AND defines the use cases realized as collaborations among the subsystems, classes and interfaces.

OOD Reusability

defining generic components that can be reapplied to create new applications.

Test model

describes test cases that verify the use cases

Iterative and incremental

divide the project into smaller slices or miniprojects

OOD Extensibility (modifiability)

ensuring timely customization of new application services and features - planning for future growth such as the extension of the application functionality.

Common vocabulary

for design, each pattern contributing to that vocabulary

Communication Diagram

illustrate object interactions in a graph or network format in which objects can be placed anywhere in the diagram. include: roles, association, and messages flows.

event

is something that will or has transpired such as aircraft arrival, departure or a lunch break.

real-world object

is something the system needs to keep track of, such as enemy aircraft and missiles.

Activity Diagram

models data and control flow through a system

Communication Diagram

models dynamic aspects of a system & is equivalent to the sequence diagram

State Machine Diagram

models dynamic state behavior of an object within a system

Component Diagram

models software architecture

Analysis Model

refine the use cases in more detail AND associate behavior of the system with objects that provide the behavior.

Doing

responsibility for an object could be doing something to itself, initiating an action to other objects, or controlling and coordinating activities in other objects. Example: A Sale is responsible for printing itself.

Knowing

responsibility for an object could be knowing about private encapsulated data, knowing about related objects, or knowing about things it can derive or calculate. Example: A Sale is responsible for recording its date.

Use Case Diagrams

show a set of external actors and the use cases each actor participates in. They use the top level use case diagram to identify use cases for each primary actor. This will include the goals (elementary business processes) and how they use the system (scenarios). It is important to note that the size of use cases and scenarios should be consistent. Too many scenarios does reduce the complexity of the system, but it increases the difficulty to coordinate and schedule the design of the system.

State Machines

shows a sequence of states that an object goes through during its lifetime in response to events, together with those responses. A state is a condition or situation in the life of an object during which it satisfies some condition, it performs some activity, or waits for some event. An event is the specification of a significant occurrence that has a location in time and space.

System Sequence Diagram

shows the sequence of events between the actor and the whole system. It shows one particular scenario of a use case such as the events the actor generates, their order, and intersystem events. Details include roles, lifelines, activations, and messages.

OO Association

structural relationships among objects

Elaboration

system sequence diagrams (describing system behavior), domain models (conceptual model), and system operation contracts are sample artifacts that may be started

Information Hiding

the attributes are only accessible by the methods in the object.

Hierarchy

the implementation of inheritance (kind-of relationship) - then we have a type hierarchy which is interface inheritance (type-of relationship).

Use Case Model

use cases and their relationships to the users

OO Generalization

used to indicate inheritance between super and sub classes

Easier for others to understand

what you have done and why - even if they're not up on the design patterns initially

Makes restructuring easier

when transformation of an application of one pattern to an application of another. Systems designed without patterns in mind can use patterns as targets for class refactorings.

Design reuse

which more powerful than code reuse (although it often brings code reuse with it)