One part of that description is a SDD. Other parts include the use cases and system operation contracts.
System behaves as a “Black Box”.
Interior objects are not shown, as they would be on a Sequence Diagram.
Object: Objects are instances of classes.
Object is represented as a rectangle which contains the name of the object underlined.
Because the system is instantiated, it is shown as an object.
Actor: An Actor is modeled using the ubiquitous symbol, the stick figure.
Lifeline: The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object.
Message: Messages, modeled as horizontal arrows between Activations, indicate the communications between objects.
Constructing a SSD from a Use Case
1. Draw a line representing the system as a black box.
2. Identify each actor that directly operates on the system. Draw a line for each such actor.
3. From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram.
4. Optionally, include the use case text to the left of the diagram.
Fig 11.1: Sample UP artifact influence.
System Operations and the System Interface
Contracts may be defined for system operations – operations that the system as a black box offers in its public interface to handle incoming system events. System operations can be identified by discovering these system events.
The entire set of system operations, across all use cases, defines the public system interface, viewing the system as a single component or class.
In the UML, the system as a whole can be represented as one object of a class named System.
Domain Model And Contracts
A Domain Model is a visual representation of conceptual classes or real-world objects in a domain of interest.
Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed.
Guideline: Keep it Agile
In many, or even most software development projects, operation contracts may be unnecessary. For an agile process, use them only when necessary to add additional detail and understanding.
Example Contract: enterItem
Operation: Name Of operation, and parameters.
Cross References: (optional) Use cases this can occur within.
Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation.
Postconditions: -The state of objects in the Domain Model after completion of the operation.
Postconditions: - A SalesLineItem instance sli was created (instance creation) - sli was associated with the current Sale (association formed) - sli.quantity became quantity (attribute modification) - sli was associated with a ProductSpecification, based on itemID match (association formed)
A UML operation has a signature (name and parameters), and also an operation specification, which describes the effects produced by executing the operation; the postconditions.
A UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation.
Operation Contracts Within the UP
A pre- and postcondition contract is a well-known style to specify an operation. In UML, operations exist at many levels, from top level classes down to fine-grained classes.
Operation specification contracts for the top level classes are part of the Use-Case Model.
Inception – Contracts are not needed during inception – they are too detailed.
Elaboration – If used at all, most contracts will be written during elaboration, when most use cases are written. Only write contracts for the most complex and subtle system operations.
Following the UP guidelines, perhaps 10% of the requirements were investigated in inception, and a slightly deeper investigation was started in this first iteration of elaboration.
Now we shift our emphasis toward designing a solution for this iteration in terms of collaborating software objects.
Iteratively Do the Right Thing, Do the Thing Right
The requirements and object-oriented analysis has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the Next-Gen POS, and related rules and constraints.
In iterative development, a transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration.
Didn’t That Take Weeks To Do? No, Not exactly.
When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to do all the actual modeling that has been explored so far is realistically just a few days.
However that does not mean that only a few days have passed since the start of project. Many other activities such as proof-of-concept programming finding resources (people,software ….) planning,setting up the environment could consume a few weeks of preparations.
On to Object Design
During object design, a logical solution based on the object-oriented paradigm is developed. The heart of this solution is the creation of interaction diagrams which illustrates how objects collaborate to fulfill the requirements.
After-or in parallel with-drawing interaction diagrams, (design) class diagrams can be drawn.
In practice,the creation of interaction and class diagram happens in parallel and synergistically, but their introduction in the textbook case study is linear for simplicity and clarity.
Importance of Object Design Skill vs UML Notation skill
Drawing UML interaction diagrams is the reflection of making decisions about the object design.
The object design skills are what really matter, rather than knowing how to draw UML diagrams.
In software development, architecture is thought of as both noun and a verb.
As a noun, the architecture includes the organization and structure of the major elements of the system.
As a verb, architecture is part investigation and part design work.
Architectural investigation: involves functional and non-functional requirements that have impact on system design.
Some of these are: market trends, performance, cost and points of evolution.
Architectural Design: is the resolution of these requirements in the design of software.
Definition: Software Architecture
There are various forms of it. But the common theme is that it has to do with large scale-the Big Ideas in the forces, organization, styles, patterns, responsibilities, collaborations, connections and motivations of a system and major subsystems.
Architectural Dimension and Views in UP
The common dimensions are:
The logical architecture, describes the system in terms of its conceptual organization in layers, packages, classes, interfaces and subsystems.
The deployment architecture, describes the system in terms of the allocation of process to processing unit and network configurations.
Architectural Layers are a logical view of the architecture
They are not a deployment view of elements to process.
Depending on platform, all layers could be deployed within the same process on same node OR across many computers.
Architectural Patterns and Pattern Categories
Architectural patterns: Relates to large-scale design and typically applied during the early iterations (in elaboration phase).
Design patterns: Relates to small and medium-scale design of objects and frameworks.
Idioms: Relates to language or implementation-oriented low-level design solutions.
Architectural Pattern: Layers
A layer is a coarse grained grouping of classes packages or subsystems that has cohesive responsibility for a major aspect of the system.
Higher layers call upon the services of lower layers.
Strict layered vs. relaxed layered architectures
Idea behind Layer patterns:
Organize the large-scale logical structure of a system into discrete layers of distinct, related responsibilities with a clean, cohesive separation of concerns such that the “lower” layers are low-level and general services, and the higher layers are more application specific.
Collaboration and coupling is from higher to lower layers.
UML Package Diagrams
UML Package Diagrams are often used to show the contents of components, which are often packages in the Java sense.
Each package represents a namespace.
Packages, as components, can be nested inside other packages.
Terminology: Tier, Layers, and Partitions
Tier relates to physical processing node or clusters of node, such as “client tier”.
Layers of an architecture represent the vertical slices.
Partitions represents a horizontal division of relatively parallel subsystems of a layer.