SWE Architecture and Design Set 2 Marking Guide
SWE Architecture and Design Set 2 Marking Guide
SWE Architecture and Design Set 2 Marking Guide
Response:
1) Multi-tier (j)
2) Peer-to-peer (f)
3) Pipe-and-filter (d)
4) Broker (b)
5) Map-Reduce (i)
Response: An edge-dominant system is one that depends on input from users for its
success. Characteristics can be built-in social media functionality, easy to add functionality
and services, parts or the whole system might be open-source, core software developed by
small group of developers, many users & prosumers.
b) Draw and explain the metropolis structure of an edge-dominant system (3x2=6 Marks)
Response: Metropolis structure: The whole system is based on a stable and high-quality
core developed by a dedicated small team. In the Edge layer, prosumers and developers
will add content and services to the system based on the APIs from the core. This layer is
essential for the survival of the system. The Masses layer is the layer of many users that use
the services and the content created in the Edge layer.
There is also movement between the Masses layer and the Edge layer, but not to the Core.
Page 1 of 5
c) What are the implications of edge-dominant systems for the software architecture?
(3x2=6 Marks)
It is very important that the Core is developed by a small excellent team, which will
produce a core which is highly modular and layered, highly robust with respect to errors,
and can produce high-performance and scalability. Good documentation for the service
APIs must be available. Another implication is that the requirements come from web-
forums and the like. The service layer must be very flexible and at the same time easy to
test and product from harmful activities.
Read the description below and do an architectural design. Your answer must include:
The problem statement defines a set of separate functions with relatively little in common.
They share the communications equipment and a number of current sensor readings.
The software architecture must permit the integration of these loosely coupled functions
(requirement R1).
At the same time, it must respect their priorities and timing constraints (R2).
Clearly the system may be extended further by additional functions (e.g., more sensors) or
that the priorities and timing constraints may be modified. The architecture should
therefore allow modifications to the overall system parameters (R3).
Finally, sea buoys must operate for long periods without maintenance, and they are
numerous enough for cost to be a major consideration. As a result, the architecture should
provide hints for its implementation on the most basic platform (R4).
a) Architectural drivers:
The architecture is based on the Task Control Architectural patterns, which basically is a
way of communicating with various tasks by sending messages to a central server (named
Message Switch in the architecture).
Modifiability:
- Generalized interface for sensors: Makes it easier to add and change sensors
- Increase semantic coherence: Clear separation of concerns and all classes has distinct and
not overlapping responsibilities
- Encapsulation: Interfaces only provides API to methods accessed by other classes. Rest
remain private.
Availability:
- Heartbeat: The Clock of the system is provided by separate hardware and can be used as
a heartbeat and force restart if system does not react within time.
Page 3 of 5
- Exception Handling: Catch exceptions in the system, which can cause a restart of the
system or broadcasting error if unfixable error.
- Simplicity: Keep the system simple to make it easier to test and find errors.
Performance:
- Schedule resources: Use the Clock to trigger events at the right time. Schedule so that
sensors are read in sequence and not at the same time.
c) Process view (there are several possible process view, but the view must show how the
system is operating while running and how the different parts of the system interact).
This process view shows an activity diagram with events and shows how the different parts
of the system interact and that they all are timed by a clock, which outputs a pulse. The
clock synchronizes all sensors as well as the broadcasting of messages. An SOS request
triggered by the Emergency Switch will cause SOS Message send by the Radio
Transmitter.
d) Logical view
Page 4 of 5
e) Architectural rationale
The architecture has focused on modifiability, performance and availability. The Clock
provides both performance by scheduling when various tasks are performed, and is used as
a heartbeat to check that the system is up and running (external hardware unit).
Modifiability is provided through the Task Control Architecture pattern, which makes it
easy to extend and change the design, clear separation of concerns between various parts,
and abstraction for common services for sensors, which makes it easy to replace sensors as
well as adding new sensors in the future.
Page 5 of 5