Software Design and Architecture: Engr Saiqa Anjum Lecturer SE

Software Design and Architecture
Engr Saiqa Anjum

Lecturer SE
Lecture 5
VIEWS IN SOFTWARE ARCHITECTURE
 Systems, architecture, models and views, as well as
their interrelationships, build the basis of
understanding of software architecture' s shape.
 Architecture hides itself behind the implementation
or the design blueprint of a system, simplified by a
number of models, which concerns their
perspectives only.
 Views, through predefined viewpoints, visualize
models and then facilitate architecture description
and communications among stakeholders
Figure-1
 A rather tough problem about defining a view is how to define
semantic of notations clearly and get them public accepted.
What Kruchten said in (Kruchten, 1995) gets this point:
“We all have seen many books and articles in which a single
diagram attempts to capture the gist of a system architecture.
But when you look carefully at the diagram ~ s boxes and arrows,
it becomes clear that the author are struggling to represent
more in one diagram than is practical. Do the boxes represent
running programs? Chunks of source code? Physical computers?
Or merely logical groupings of functionality? Do the arrows
represent compilation dependencies? Control flow? Data flow?
Usually the answer is that they represent a bit of everything.”
 There are four major views of software architecture
 Component & Connector View (C & C View)

 Decomposition View
 Allocation View(Deployment view)
 Behavior View
 The components, connectors and their annexes (such
as their properties, constraints, etc.) are taken as main
elements in architectural models, and thus C&C view
becomes the solo representation.
 The reason for this situation is that we can deduce the
quality attributes from information extracted from this
view in the very early phase of software development,
which, in turn, decrease development risks.
Figure-2
In software architecture, publish–subscribe is
a messaging pattern where senders of messages, called
publishers, do not program the messages to be sent
directly to specific receivers, called subscribers, but
instead characterize published messages into classes
without knowledge of which subscribers, if any, there may
be.
 In Figure 2 C&C view indicates the structure of a source
code version control system.
 C&C view abstracts the runtime scene of a system,
including its main functional units, communication
methods, data flows, etc. Each element has runtime
meaning rather than building blocks.
 For instance, the code repository server may be
implemented through several classes in OO, or
functions with C
 Each element of C&C view should have clear and non-
equivocal meanings, which normally reflected by a notation
specification or a legend.
 The worst thing of view is drawing with notations following
habits and hobbies, which will introduce severe mess and
misunderstanding, evil enough to counteract all the benefits
brought by C&C view.
 Unfortunately, we often see figures, drawn by boxes, lines,
arrow lines, etc. with various colors, in many articles,
reports and even design specifications, which are called by
their authors as "architecture
 In C&C view, components are functional units which
interact with outside through a series of predefined
interfaces (not identical to the interface used in
programming languages such as Java or C# ), which are
organized as ports.
 Through this limited access method, components
encapsulate themselves, and thus become independent
and replaceable. Connectors are far more complex than
what they look like in C&C view, where they abstract
the communication protocols.
Figure-3
C&c view
• Elements
Components – encapsulated and replaceable system
elements that have runtime behavior
Connectors - pathways of interaction between components.
• Relations (in UML notation)
Components have ports with associated connector roles
Ports have associated interfaces
Relations represented as a graph of components and
connector attachments.
E.g., client – server invoke-services role
Interface delegation - component ports may be associated
with one or more “internal” ports
Usage
• Major executing components
• Major shared data stores
• Runtime interaction; e.g., control and data flow, parallelism
Connector mechanisms – e.g., service invocation,
asynchronous messaging, event subscription, …
Constraints
• All attachments are only between components and
connectors
• Attachments must be between compatible ports and roles
 Architectural styles define necessary vocabulary for
describing system' s runtime structure, and provide the
foundation upon which architectural patterns are built,
which solve specific problems under a certain context.
 Architectural tactics, styles and patterns can be
represented through C&C view and then enable
architectural evaluation, because they can reflect the
influence that design makes to system' s expected
quality attributes.
 C&C view and the runtime model it shows are so
important that they are believed as an alternative of
software architecture.
CASCADING STYLE SHEETS (CSS)
References
Multiple sources.
Acknowledgement
Special thanks to all of the computer scientists,
engineers, book authors and others for providing such
a useful information.
HAVE A NICE DAY
Q/A

Software Design and Architecture: Engr Saiqa Anjum Lecturer SE

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Design and Architecture: Engr Saiqa Anjum Lecturer SE

Uploaded by

Copyright:

Available Formats

Software Design and Architecture

Engr Saiqa Anjum

 Component & Connector View (C & C View)

You might also like