Software architecture view 4+1 model

Transcript
This slide show introduces the 4 + 1 software architecture viewmodel in more
detail. In the last slide show, we have introduced the 4 + 1 model with this overview
figure. Now let's dive into the details of. The individual views. The scenarios or use
case view is the central view of 4 + 1. The description of an architecture that is the
architectural decisions made can be organized around the four other views. Those
other views are illustrated by a few selected use cases or scenarios. The
architecture is in fact partially evolved from these scenarios. The scenarios are use
case here is redundant with the other views. Hence it is called the plus one. It has
two main purposes. It acts as a driver to discover the architectural elements during
the architectural design. As we will describe later, so here we really aim to select
the architecturally relevant scenarios. In addition, it acts in a validation and
illustration role. After this architecture design is complete, how can the scenarios or
use case few be modeled in UML? UML provides the use case diagrams to represent
this view. These diagrams are comprised of use cases and actors. They are usually
closely tied to detailed scenario descriptions. For instance, in text form, as an
architecture view, we are only interested in modeling architecturally significant use
cases. Activity diagrams can also be used to represent scenarios. They are
especially useful to model the detailed scenario flows because the diagrams are
often not complete enough. Usually it's senarios and use cases are detailed in
textual form. Let's consider a UML use case diagram example. An excerpt of A use
case diagram for order handling. Here we can see two actors, the. Customer and
the sales assistant. The customer participates in searching for items, placing orders
and fulfilling orders. The sales assistant. Participates in fulfilling orders and
processing orders. Such diagrams give an overview and the individual use cases are
usually detailed in textual form as here. The place order use case. In this template,
first the use case name. The use case ID and the actors are specified, then a brief
description of the use case follows like here. A customer places an order via the
web interface and then submits it for processing. Next, we can specify preconditions
like. The customer must have registered system and post conditions like the
customers order will be directed to the order processing system for processing.
Next follows the main success scenario. That is this scenario leading to successful
completion of the use case. The main success scenario is usually a sequential order
of tasks like here first the customer selects place order and a new order form and
order ID are generated and displayed. Next, the customer select items from the
catalog and access them. To the order. Then the customer submits the order for
processing and finally the system records the order and forwards it to the order
processing system. You can also give a number of extensions to the main success
scenario. That are possible. For instance, here at anytime the customer can decide
to suspend the ordering process and come back to it later. Or decide to cancel the
order. Finally, additional information are given. For instance, here it is said that the
use case is of high priority. That it should reach a performance target of 10,000 new
orders per day. And that the issue is there any limit on the amount of an order is not
yet resolved by the development team? The next few in 4 + 1 is the logical view.
This view focuses on realizing its applications functionality in terms of the structural
elements key. Abstractions and mechanisms. And separation of concerns and.
Distribution of responsibilities. Usually the logical architecture is represented at
different levels of abstraction and progressively evolves in iterations. Its name is
somewhat inspired from logical database views in the sense that it avoids
development and physical information in UML. If you usually start with class
diagrams to model the key abstractions of the system. These form the core of the
logical view. Many other UML diagrams can optionally be used. Package diagrams
can be used to logically group diagrams. Object diagrams can be used when
relationships between classes need to be explained through instances. Day charts
can be used for modeling internal states of specific classes. Composite structures
when parts of class and relationships between parts are to be modeled for the
starting point for modeling. The logical view is usually the domain model. It can
potentially be refined at different abstraction levels. For instance, in the domain of
order processing, we model abstractions like order, order, item, customer,
customer. Address shipping address item. Product and stock inventory. In addition,
we model the logical relationships of these core abstractions based on logical view
and scenarios. We can start modeling the process. It is used to consider non
functional aspects of the architecture. Such as performance, scalability and
throughput. It addresses issues of. Concurrency distribution and fault tolerance. A
process is a group of tasks that form an executable unit. A software system is
partitioned into sets of tasks. Each task is a thread of control that acts executes
with collaboration among different structural elements. The structural elements are
the obstructions from the logical view. This view can best be modeled in URL using
behavioral diagrams. For instance, you can use sequence diagrams or
communication diagrams for modeling simple interactions. In use case realizations,
optionally you can add activity diagrams to real life scenarios where business logic
is a sequence of actions and then most branching of parallel processing. You can
add timing diagrams when modeling for performance and for complex scenarios
that can be composed of other scenarios. Use interaction overview diagrams. Again
package. Diagrams can be used. For organizing the diagrams. Here is a high. Level
process view of place order as an activity diagram details the steps from the main
success scenario when somebody. Selects place order, a new order ID is generated.
And then a new order form is generated in this. Next number of items from the
catalog are selected and added to the order until the order is. Finished finally 2
steps can be performed. In parallel recording of the order forwarding to water
processing. The next two in the 4 + 1 view model is the development view. Also
called implementation, view or subsystem decomposition view. This is so few of a
system architecture that encompasses the components used to assemble and
release the system. That is the task of this view is to package the software system
into components that can be developed and tested by the development. While the
logical view is at the conceptual level, the diagrams in this view represent the
physical level artifacts that are built by the team. Typically this view is. Modeled by
component diagrams in UML two this diagram. Show different components reports
available and the dependencies on the environment in terms of provided and
required interfaces. As components are some types of class, any elements of class.
Diagrams can be used as well. As in the other views. Package diagrams can be used
for organizing the diagrams. Here is a component diagram for a webshop realizing
the place order scenario. It is successed by users using a component in a web
browser. This component uses a web access connector to reach the web shop tax
values on the connector specified that the number of concurrent users is 1000 and
possible protocols are HTTP and HTTPS. The webshop uses three other components
to realize its functionality. Customer information system or a processor and product
catalog customer information system connects via GDC connector to a database
component. Similarly, if the water processor connects to an order store as well as
the stock inventory. Which is also used by the product catalog. Finally, there is a
message bus connector of the auto processor to an order fulfillment component.
The final view of 4 + 1 is the physical view. Also called deployment view maps
software to hardware that is. This view encompasses the nodes that form the
systems hardware topology on which the system executes. It focuses on.
Distribution, communication and provisioning. The software executes on a network
of computers or processing notes. This view provides all possible hardware
configurations and maps the components from development field to these
configurations. The physical fuel is typically modeled in UML and deployment
diagrams that show the physical disposition of the artifacts in the real world setting
package diagrams are used to structure the deployment diagrams. Yes, an example
deployment diagram for our webshop we see three devices. Two application servers
and the database server. The three databases. Run on the data server on the 1st
the application Server and Jade Execution Environment runs. Which is the web.
Shop the order processing customer information system. Are deployed. Finally,
there's another application server running a Ruby on Rails environment. In which
order fulfillment runs? You can map the artifacts of the deployment diagrams to
components using the manifest relationship. Yeah. For instance, it is shown that the
web shop jar artifact consists of the components web. Shop and product catalog.
This diagram establishes traceability between the development and the physical
views. Establishing traceability is generally advisable when using view based
approaches. In summary in. The slide show we have heard about the details of one
particular view model. The 4 + 1 Architectural view model.