4-architectural-views

4/21/2020 S. Parsa (www.parsa.iust.ac.ir) 1

Unified Modeling Language (UML) has been available since 1997, and UML 2 was released in
2004, building on an already successful UML 1.x standard. UML 2 comes with 13 basic diagram
types to support Model Driven Architecture (MDA) and Model Driven Development (MDD).
Introduction
UML 2 Diagrams
 There are 13 basic diagrams available in UML 2 Specification.
 UML 2 divides the basic diagram types into two key categories:
• Part I – Structural Diagrams: These diagrams are used to define static architecture.
There are six structural diagrams: Package Diagrams, Class Diagrams, Object Diagrams,
Composite Structure Diagrams, Component Diagrams and Deployment Diagrams.
• Part II – Behavioral Diagrams: These diagrams are used to represent dynamic architecture.
They are used to represent the interactions among various model elements and
instantaneous states over a time period.
There are seven behavioral diagrams: Use Case Diagrams, Activity Diagrams, State Machine
Diagrams, Communication Diagrams, Sequence Diagrams, Timing Diagrams and Interaction
Overview Diagrams.

“Software Architecture is the fundamental organization of a system, embodied
in its components, their relationships to each other and the environment, and
the principles governing its design and evolution.
.
- a Network Engineer would only be interested in the hardware and network
configuration of the system;
- a Project Manager in the key components to be developed and their
timelines;
- a Developer in classes that make up a component; and a Tester in scenarios.
- So we need multiple view points for distinct stakeholders’ needs, showing
what is relevant while masking the details that are irrelevant.

 Use case view
• shows the system functionality and services.
 Logical view
• shows the key abstractions in the system as objects or
object classes.
 Process view
• shows how, at run-time, the system is composed of
interacting processes.
• Component view
• shows how the software is decomposed for development.
• Development view
• shows the system hardware and how software
components are distributed across in the system.

 Architectural views are not independent
 Relationship between views denotes semantics connections
 Process view is related to the design elements of the logical view

Creating Views in Enterprise Architect
The top-level Packages in a model (below the project root nodes) can be created as Views, which are
simply used to structurally partition and extend the model according to specific requirements and
modeling techniques, such as Component View or Dynamic View.
 Use Case View - containing Use Case diagrams and Analysis diagrams,
 Dynamic View -containing Activity diagrams, Communication diagrams, Sequence diagrams and State
Machine diagrams,
 Class View - containing Class diagrams, Code Engineering and Data Models
 Component View - containing Component diagrams
 Deployment View - containing Deployment diagrams
 Simple View - to customize your own type of view

https://www.ece.uvic.ca/~itraore/seng422-06/notes/arch06-3-3.pdf
https://www.ece.uvic.ca/~itraore/seng422-06/notes/arch06-3-2.pdf
https://pubs.opengroup.org/architecture/archimate-doc/ts_archimate/chap9.html

In general only the design model is maintained in the logical view, since the analysis model provides a rough sketch,
which is later refined into design artifacts.
- Is derived from architecturally significant use cases defined in the use case view

 executable: a component that may be executed on a node
 library: a static or dynamic object library
 table: a component that represents a database table
 file: a component that represents a document source code or data
 document: a component that represents a document

 The diagram can be used to trace the impact of changes.
 Changing signal.h will require recompilation of signal.cpp, intep.cpp and transivity device .cpp.

 Models the topology of the hardware on which the system executes:
processor or device on which components may be deployed.

1. Deployment model
2. Deployment of active objects

A set of objects or components that are allocated to a node as a group
is called a distribution unit.
Nodes are locations upon which components are deployed.

 Describes the view of the architecture that includes running processes
and instantiated objects that exist in the system.
 Describes important concurrency and synchronization issues.

For an in-depth understanding of use case issues, it is a good idea to refer
to the book provided by the Founder of Use Cases, Jacobson.
https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2_0_jan11.pdf

Use Case View?
Captures system functionality as seen by users Built in early stages of development
Developed by analysts and domain experts System behavior, that is what functionality it
must provide, is documented in a use case model.
Use Case Model illustrates the system’s intended functions (use cases), its
surroundings (actors), and relationships between the use cases and actors (use
case diagrams)
High level architecture

 Actor ?
 An actor is a person, organization, or external
system that plays a role in one or more
interactions with your system. Actors are
drawn as stick figures.
 Orderer - someone who places an order to buy.
• Warehouse Office Clerk is to assist in
performing the daily administrative
and organizational functions of the
warehouse office.
o Warehouse Clerk is responsible for
ensuring that products are registered and
packed correctly for shipping or storage.

Use Case ?
A use case is a list of actions or event steps typically defining
the interactions between a role (known in the Unified Modeling
Language (UML) as an actor) and a system to achieve a goal.

1. Association:
 A relationship that represents communication between an actor and a use
case; can be navigable in both ways or in only one way.
2. Uses (includes) and extends are two types of relationships between use cases.
•An extends relationship is used to show:
- Optional behavior
- Behavior that is only run under certain conditions,
- Different flows which may be run based on actor selection
•A uses of includes relationship is used to show:
- functionality shared by multiple use cases.
- can be placed in a separate use case, related to these uses cases by a
uses relationship

1. Kinds:
“Withdraw Cash” is a kind of “Bank ATM Transaction”.

1. The application will record and maintain the product quantity in the
stock in the central database.
2. The storekeeper can remove products from the database.
3. The storekeeper can add products into the database.
4. The storekeeper can change the product quantity in the database.
5. The cashier can bill the item by manually entering the bar code or
with a bar code reader.
6. Only the products recorded in the database can be billed.
7. The billed items can be removed from the bill until it has been closed.
 The retail support application requirements.

8. The billed item removal must be approved by a store manager by
entering his authentication data.
9. The billed items will be printed on the cash desk bill as they are
entered. The bill will consist of the store name, billed items,
information on removed billed items, the total amount of money to
be paid, and date and time.
10. The product price can be entered or modified only by a properly
authenticated store manager.
 The retail support application requirements.
 Consider each use case as a capability to cover one or more requirements

 Consider each use case as a capability to cover one or more requirements

• Each use case is documented with a flow of events, use-case scenario,
which is a description of the events needed to accomplish the required
behavior.
• The scenario is written in the language of the domain and describe what
the system should do and not how the system does it.
• The flow of events should include:
-When and how the use case starts and ends
-What interaction the use case has with the actors
-What data is needed by the use case
-The normal sequence of events for the use case
-The description of any alternate or exceptional flows

 X Flow of Events for the Use Case
 X.1 Preconditions & Postconditions
 X.2 Main Flow
 X.3 Subflows (if applicable)
 X.4 Alternative Flows
 Where X is a number from 1 to the number of use cases

• Main flow of events:
(E1) The use case starts when the system prompts the User for a PIN
number. The User can now enter a
PIN number via the keypad.
(E2) The User commits the entry by pressing the Enter button.
(E3) The system then checks this PIN number to see if it is valid. If the
PIN number is valid, the system acknowledges the entry, thus
ending the use case.
• Subflows:
S1: The system invokes Validate use case.

• Alternative flow of events:
E1: The User can clear a PIN number any time before committing it and
reenter a new PIN number.
E2: The User can cancel a transaction at any time by pressing the Cancel
button, thus restarting the use
case. No changes are made to the User’s account.
E3: If the User enters an invalid PIN number, the use case restarts. If this
happens three times in a row, the
system cancels the entire transaction, preventing the User from
interacting with the ATM for 30
minutes.

Web Customer actor uses some web site to make purchases
online.
Top level use cases are View Items, Make
Purchase and Client Register.
View Items use case could be used by customer as top level use case
if customer only wants to find and see some products. This use case
could also be used as a part of Make Purchase use case.
Client Register use case allows customer to register on the web site,
for example to get some coupons or be invited to private sales.
Note, that
Checkout use case is included use case not available by itself -
checkout is part of making purchase.

4/21/2020 S. Parsa (www.parsa.iust.ac.ir)
53

• View Items use case is extended by several optional use cases -
customer may search for items, browse catalog, view items
recommended for him/her, add items to shopping cart or wish list.
• All these use cases are extending use cases because they provide some
optional functions allowing customer to find item.
• Customer Authentication use case is included in view
Recommended Items and Add to Wish List because both
require the customer to be authenticated.
• At the same time, item could be added to the shopping cart without
user authentication.

• Checkout use case includes several required uses cases.
• Web customer should be authenticated. It could be done through
user login page, user authentication cookie ("Remember me") or
Single Sign-On (SSO).
• Web site authentication service is used in all these use cases, while
SSO also requires participation of external identity provider.
• Checkout use case also includes Payment use case which could be
done either by using credit card and external credit payment service
or with PayPal.

Main functional flow of an online shopping system

 An example of high level sequence
diagram for online bookshop. Online
customer can search book catalog,
view description of a selected book,
add book to shopping cart, do
checkout

Each customer has unique id, linked to one account.
Account owns shopping cart and orders.
Customer could register as a web user to buy items online.
Customer could purchases by phone or by ordering from catalogues.
Web user has login name which also serves as unique id.
Web user could be in several states - new, active, temporary blocked,
or banned, and be linked to a shopping cart.
Shopping cart belongs to account.

Account owns customer orders. Customer may have no orders.
Each order could refer to several payments, possibly none.
Every payment has unique id and is related to exactly one account.
Both order and shopping cart have line items linked to a specific
product.
Each line item is related to exactly one product. A product could be
associated to many line items or no item at all.

• As shown in the next slide, the webStore subsystem contains three components:
Search Engine, Shopping Cart, and Authentication.
• Search Engine component allows to search or browse items by exposing provided
interface Product Search and uses required interface
• Search Inventory provided by Inventory component.
• Shopping Cart component uses Manage Orders interface provided by Orders
component during checkout.
• Warehouses subsystem provides two interfaces Search Inventory and Manage
Inventory used by other subsystems and wired through dependencies.

UML Deployment Diagram Example

• UML provides no special kind of diagram to describe logical or
physical network architecture of the designed or existing system.
• Deployment diagrams could be used for this purpose with
elements limited mostly to devices with neither artifacts nor actual
deployment shown.
• Warehouses subsystem provides two interfaces Search Inventory
and Manage Inventory used by other subsystems and wired
through dependencies.

Online Shopping
Network Diagram Example

• Package diagrams depict the organization of model elements into Packages
and the dependencies amongst them, including Package imports and
Package extensions. They also provide a visualization of the corresponding
namespaces.

The Nesting connector between ConnSeq and
Controller reflects what the Package contents
reveal. The Package contents can be listed by
clicking on the diagram background to
display the diagram's 'Properties' dialog,
selecting the 'Elements' tab and selecting the
'Package Contents' checkbox in the 'Show
Compartments' panel
The «import» connector indicates that the elements within the
target Integer Package, which in this example is the single Class
Integer, have been imported into the Package Controller
If an element already exists within GenApply, such as Loader
and Time, these elements' definitions are expanded by those
included in the Package Controller. All elements added or
updated by the merge are noted by a generalization
relationship back to that Package.

UML 2 provides an elaborate set of diagrams to create a Logical View:
1. Class Diagrams or Structural Diagrams: These diagrams define the basic building blocks of a model.
They focus on each individual class, the main operations and relationships to other classes’
associations, usage, composition, inheritance etc.
2. Object Diagrams: These diagrams show how instances of structural elements are related. They help
understand the class diagrams when the relationships are complex. The object diagrams were
informally used in the UML 1.x world; in UML 2 they are formal artifacts.
3. Package Diagrams: These diagrams are used to divide the model into logical containers or
‘packages’. They can be used to represent vertical and horizontal divisions as packages.
4. Composite Structure Diagrams: These diagrams help in modeling the parts contained by a class and
the relationships between the parts. When parts are related, such diagrams significantly simplify
the relationships between the classes. Ports are used to represent how a class hooks into the
environment. These diagrams support collaborations that can be used to represent design patterns
of cooperating objects. UML 2 has introduced these diagrams as a major improvement over earlier
structural constructs.
5. State Machine Diagrams: These diagrams are necessary to understand the instant states of an
object defined by a class. These diagrams are optionally used when there is a need to understand
the possible states of a class.

Logical View (Object Oriented Decomposition)
• This view focuses on realizing an application’s functionality in terms of structural
elements, key abstractions and mechanisms, separation of concerns and distribution of
responsibilities. Architects use this view for functional analysis.
• The logical architecture is represented at different levels of abstraction and
progressively evolves in iterations.
1. Vertical and horizontal divisions
– The application can be vertically divided into significant functional areas (i.e., order
capture subsystems, order processing subsystems).
– Or, it can be horizontally divided into a layered architecture distributing responsibilities
among these layers (i.e., presentation layers, services layers, business logic layers, and data
access layers).
2. Representation of structural elements as classes or objects and their relationships.

 Patterns are a means of representing, sharing and reusing knowledge.
 An architectural pattern is a stylized description of good design
practice, which has been tried and tested in different environments.
 Patterns should include information about when they are and when
the are not useful.
 Patterns may be represented using tabular and graphical descriptions.

Sub-systems may exchange data in two ways:
1. Shared data is held in a central database or repository and may be
accessed by all sub-systems;
2. Each sub-system maintains its own database and passes data explicitly
to other sub-systems.
• When to use:
1. large amounts of data are to be shared and stored for a long time.
2. In data-driven systems where the inclusion of data in the repository
triggers an action or tool

Advantages Disadvantages
Components can be independent Problems in the repository affect
the whole system.
Changes made by one component
can be propagated to all
components.
Inefficiencies in organizing all
communication through the
repository.
All data can be managed
consistently (e.g., backups done at
the same time)
Difficulties in distributing the
repository across several
computer

 Distributed system model which shows how data and processing is
distributed across a range of components.
– Can be implemented on a single computer.
– Set of stand-alone servers which provide specific
Services such as printing, data management, etc.
– Set of clients which call on these services.
– Network which allows clients to access servers.
• Used when data in a shared database has to be accessed from a range of
locations.

https://people.utm.my/norsham/files/2015/09/S9-Architectural-Design.pdf
Servers can be distributed
across a network.
Each service is a single point
of failure so susceptible to
denial of service attacks or
server failure.
Changes made by one component
can be propagated to all
components.
Performance may be
unpredictable because it
depends on the network as
well as the system.

 Used when
– building new facilities on top of existing systems,
– the development is spread across several teams
with each team responsibility for a layer of
functionality,
– there is a requirement for multi-level security,
– security is a critical requirement.
 Example: layered security architecture
– a system to provide file security

Each layer is an increasing level
of abstraction.
Not easy to structure a system in
layers.
Layers decompose a problem
into a sequence of more abstract
steps.
The multiple layers of abstraction
are not always evident when
examine a set of requirements.
It’s easy to add or modify a layer
as the need arises
System performance may suffer
from the extra coordination
among the layers

1. Application Layer

1. Application Layer classes inherit the lower levels classes

2. Business services Layer

2. Business Layer classes inherit the lower levels classes

3. Middleware Layer

3. Middleware Layer classes

 Used when
– inputs are processed in separate stages to generate outputs.,
– data flows (as in a pipe) from one component to another for
processing,
– there is a requirement for multi-level security,
– security is a critical requirement.
 Referred as: a pipe and filter model (as in UNIX shell)
– Not really suitable for interactive systems.

Easy to understand and supports
transformation reuse. .
• The format for data transfer has
to be agreed upon
between communicating
transformations.
Workflow style matches the
structure of many business
processes.
Can be implemented as either a
sequential or concurrent
system.
System performance may suffer
from the extra coordination
among the layers

Process View (Process Decomposition)
• Process view considers non-functional aspects such as performance, scalability and throughput.
• It addresses the issues of concurrency, distribution and fault tolerance.
• It shows the main abstractions from the Logical View executing over a thread as an operation.
• 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 executes with collaboration among different structural
elements (from the Logical View).
• Process View also encompasses re-usable interaction patterns to solve recurring problems and
to meet non-functional service levels.

The Process view can be represented by the following UML 2 diagrams:
1. Sequence Diagrams
 Seqence diagram,s Show the sequence of messages passed between the objects on a vertical timeline.
 UML 2 has introduced the fragment types such as loop, assert, break and alt help in diagramming to the level
of detail that keeps code and models in sync – not just in terms of structure, but also in behavior.
2. Communication (collaboration) Diagrams:
 These diagrams show communications between objects at runtime during a collaboration instance.
 These diagrams are closely related to Sequence diagrams.
 UML 2 has made improvements relative to Sequence diagrams.
3. Activity Diagrams:
 These diagrams are similar to flowcharts and have a wide range of uses in different view points.
 UML 2 has made several improvements to represent the time events, external sending and receiving signals
in the Activity Diagrams.

4. Timing Diagrams:
 Timing Diagrams specifically address modeling for performance.
 They depict the amount of time allowed for a participant to receive events and switch between the states,
and how long a participant can stay in a specific state. These
 diagrams were introduced in UML 2 and can be used for performance design.
5. Interaction Overview Diagrams:
 These diagrams provide an overview of how several
 interactions work together to implement a system concern. They are a fusion of
 Activity, Sequence and Timing Diagrams. Each part of an interaction could be
 represented by a distinct diagram type. UML 2 introduces these diagrams and they
 can be used to aid high-level overviews and understand the overall system behavior.

- Components are the units of deployment.
- They are the smallest entities that can be
deployed as part of a system.
- In Java, they are jar files. In Ruby, they are
gem files. In .Net, they are DLLs.
- well-designed components always retain
the ability to be independently deployable
and, therefore, independently
developable.

- Here an architect addresses how the conceptual solution can be realized by
application code with today's software technologies.
The primary engineering tasks are the following:
- Which modules are necessary to fulfill the actual requirements for implementation,
- How can dependencies between modules be minimized,
- How can reuse of modules and subsystems be maximized?
• What system support/services does it use?
• What techniques can be used to isolate the product from changes in off-the-shelf
components, the underlying infrastructure, or changes to standards?
- • How can testing be supported?

 The Component Model defines how Classes, Artifacts and other low level elements
are collected into high level components, and describes the interfaces and
connections between them.
 The Component diagram is one of the Unified Modeling Language Structural diagrams
that can be used to model the logical components that make up a system
 They can be used to model the applications of an organization including their
Provided and Required Interfaces and the information that is exchanged between the
interfaces.

- Interfaces Components may also expose interfaces. These are the visible entry points or
services that a component is advertising and making available to other software
components and classes.
- Typically a component is made up of many internal classes and packages of classes. It
may even be assembled from a collection of smaller components.

 This diagram demonstrates a number of
components and their inter-relationships.
 Assembly connectors connect the
provided interfaces supplied by Product
and Customer to the required interfaces
specified by Order.
 A Dependency relationship maps a
customer's associated account details to
the required interface Payment, also
specified by Order.

 A Component diagram illustrates the pieces of software, their
organization and dependencies.
 A Component diagram has a higher level of abstraction than a
Class diagram;
 You generate Component diagram elements and connectors
from the 'Component' pages of the Diagram Toolbox
 Usually a component is implemented by one or more Classes
(or Objects) at runtime.

 Ribbon: Design > Diagram > Insert > UML Structural > Component
 Project Browser Toolbar : New Diagram icon > UML Structural > Component
 Project Browser context menu | Add Diagram... > UML Structural >
Component
Where to find the Component Diagram in E.A. ?

• The Second homework

 Component design (also referred as component-level design) refers to the
detailed design task of defining the internal logical structure and behavior of
components.
 That is, refining the structure of components identified during the software
architecture activity.
 In OO, the internal structure of components identified during architecture can be
designed as a single class, numerous classes, or sub components.

This is an important decision, and
requires guidance from good software
engineering principles. Refer to chapter
12 of:
Begin with discussing the three principles of
component cohesion:
 REP: The Reuse/Release Equivalence
Principle
 CCP: The Common Closure Principle
 CRP: The Common Reuse Principle

In this section we will discuss the three
principles of component cohesion:
• REP: The Reuse/Release Equivalence
Principle
• CCP: The Common Closure Principle
• CRP: The Common Reuse Principle
Classes and modules that are formed into a
component must belong to a cohesive group.
Classes and modules that are grouped together
into a component should be releasable together.
1. The Reuse/Release Equivalence Principle (REP)

2. The Common Closure Principle (CCP)
 CCP prompt:
- Gather together in one place all the classes that
are
likely to change for the same reasons.
- If two classes are so tightly bound, either
physically
or conceptually, that they always change
together,
then they belong in the same component.
 CCP Intention:
- To minimize the workload related to
releasing,
revalidating, and redeploying the software.
- To support maintainability by confining
changes
to a single component.

CCP Similarities
 Single Responsibility Principle {SRP):
- Similar to a method or a class, a component
should
have a single responsibility and thereby a single
reason to change.
 Open Closed Principle (OCP):
- The OCP states that classes should be closed for
modification but open for extension.
- Design components such that they are closed to
the
most common kinds of expected or experienced
changes.

2. The Common Reuse Principle (CRP)
 Classes and modules that tend to be reused
together belong in the same component.
 Classes are seldom reused in isolation.
 Reusable classes collaborate with other classes
that are part of the reusable abstraction.
 Classes are reused together because they are
tightly coupled to each other.
 Classes that are not tightly bound to each other
should not be in the same component.

 Coupling is the extent to which a component of your software depends on
other components.
 Orthogonal software requires software components to be loosely coupled
to one another.
 Highly cohesive components that are loosely coupled to each other
produce an orthogonal system.

 Use cases are a very natural way to divide the system into components.
 Each use case uses:
- some UI,
- some application-specific business rules,
- some application-independent business rules, and
- some database functionality.
 Divide the system into horizontal layers,
Also divide the system into thin vertical use cases that cut through those
layers.

 The decoupling of the use cases and layers
also affords a high degree of flexibility in
deployment.
 Adding a new use case could be a simple as
adding a few new jar files or services to the
system while leaving the rest alone.

4-architectural-views

Recommended

Recommended

More Related Content

Similar to 4-architectural-views

Similar to 4-architectural-views (20)

More from Morteza Zakeri

More from Morteza Zakeri (20)

Recently uploaded

Recently uploaded (20)

4-architectural-views

Editor's Notes