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)
