Loading...

Course: Software Development Processes - Assignment 3

Open Posted By: surajrudrajnv33 Date: 21/02/2021 Graduate Rewriting & Paraphrasing

 

Please view two attachments for instructions and notes.

Thank You :)

Category: Engineering & Sciences Subjects: Biology Deadline: 12 Hours Budget: $120 - $180 Pages: 2-3 Pages (Short Assignment)

Attachment 1

Chapter 7: Design: Architecture and Methodology

1

Design Topics Covered

Architectural vs. detailed design

“Common” architectural styles, tactics, and reference architectures

Basic techniques for detailed design

Basic issues with user-interface design

2

Design

Starts mostly from/with requirements (evolving mostly from functionalities and other non-functional characteristics).

How is the software solution going to be structured?

What are the main components—(functional comp)?

Often directly from requirements’ functionalities (use cases).

How are these components related?

Possibly re-organize the components (composition/decomposition).

Two main levels of design:

Architectural (high level)

Detailed design

How should we depict design—notation/language?

3

Relationship between Architecture and Design

Detailed Design

Comes from

Requirements &

Architecture

4

Software Architecture

Structure(s) of the solution, comprising:

Major software elements

Their externally visible properties

Relationships among elements

Every software system has an architecture.

May have multiple structures!

Multiple ways of organizing elements, depending on the perspective

External properties of components (and modules)

Component (module) interfaces

Component (module) interactions, rather than internals of components and modules

5

Views and Viewpoints

View – representation of a system structure

4+1 views (by Krutchen)

Logical (OO decomposition – key abstractions)

Process (run-time, concurrency/distribution of functions)

Subsystem decomposition

Physical architecture

+1: use cases

Other classification (Bass, Clements, Kazman)

Module

Run-time

Allocation (mapping to development environment)

Different views for different people

6

Architectural Styles/Patterns

Pipes and filters

Event driven

Client-server

Model-view-controller (MVC)

Layered

Database centric

Three tier

We discuss architectural styles/patterns as

“reusable” starting point for design activities.

7

Pipe-Filter Architecture Style

The high-level design solution is decomposed into two “generic” parts (filters and pipes):

Filter is a service that transforms a stream of input data into a stream of output data.

Pipe is a mechanism or conduit through which the data flows from one filter to another.

Input

time cards

Prepare for

check processing

Process checks

Problems that require batch file processing seem to fit this architecture: e.g., payroll, compilers, month-end accounting.

** Reminds one of DFD without the data store or source sink.**

8

Event Driven (Real Time)

The high-level design solution is based on an event dispatcher, which manages events and the functionalities that depend on those events. These have the following characteristics:

Events may be a simple notification or may include associated data.

Events may be prioritized or be based on constraints such as time.

Events may require synchronous or asynchronous processing.

Events may be “registered” or “unregistered” by components.

Personal (device)

dispatcher

voice

call

text

msg

Image

keypad

Phone

processing

Text

processing

Image

processing

Problems that fit this architecture include real-time systems such as: airplane control,

medical equipment monitor, home monitor, embedded device controller, game, etc.

- - - Try a commercial flight control system - - -

9

Basic Client-Server Style

Application split into client component and server component.

10

Client-Server Style

Client may connect to more than one server (servers are usually independent).

11

Separates model (data) from view.

Controller often integrated with view nowadays.

Model-View-Control (MVC) Style

Most internet web applications fall under this style.

12

The “outer” layer can only ask for service from the “inner” layer; the “upper” layer can only ask for service from the “lower” layer.

− Strict layering: only directly inside or below layers

− Relaxed layering: any inside or below layers

Layered Style

13

Shared Data (DB)-Centric Style

Very popular within the business applications community

14

Three-Tier Style (Mixture)

Clients do not access DB directly.

Better flexibility, integrity. (Why?)

Reminds one of client server or MVC.

15

Architectural Tactics

Tactics (in contrast to architectural style) are for solving “smaller, specific” problems.

Do not affect overall structure of system.

Example: we add specific functionalities or component (e.g., to increase reliability) in the design for fault detection—especially for distributed systems:

Heartbeat

Ping/echo

16

Reference Architectures

Full-fledged architectures.

Serve as “templates” or as “a reference” for a class of systems.

Example: J2EE reference architecture (MVC2).

There also are “application domain−specific” reference architectures.

17

Detailed Design

Further refine architecture and match with requirements.

How detailed?

How formal?

Maybe of different levels of detail for different views.

18

Functional Decomposition Technique

Dates back to “structured programming” [now (non-OO) Web apps with PHP tool].

Start with: main (task/requirements) --> module.

Refine into sub-modules.

There are alternative decompositions.

19

Possible Decomposition of (Student-Course Management App)

20

“Alternative” Decomposition/Composition

21

Relational Database Design

Most databases use relational technology.

Relations (tables):

Two-dimensional sets

Rows (tuples), columns (attributes)

A row may be an entity; columns may be relationships or attributes.

Primary key (unique identifier) – for search

Foreign keys (connects tables)

22

Database Design

Conceptual modeling (done during analysis/requirement phase) produces ER diagram.

Logical design (to relational).

Physical design (decide data types, etc.).

Deployment/maintenance:

Low-level physical (which hard drive, etc.)

Adjustment of indexes

23

Entity-Relationship Diagrams

Entities (rectangles)

Weak: double lines

Relationships (diamonds)

Attributes (ovals)

Multi-valued: double lines

Identifying: underlined

24

ER Diagram Example

25

Logical DB Design – Entities

Table per entity.

Flatten composite attributes.

For weak entities, add the primary key of the strong entity.

26

Logical DB Design – Multi-Valued

New table needed for multi-valued attributes.

27

Logical DB Design – Relationships

If one side related to just one entity, add foreign key to that side.

For many to many, need new table.

For ternary, need new table.

28

Physical DB Design

Data types for each attribute.

Check which ones your DBMS support.

Encoding.

Decide on indexes.

Searches are faster, updates are slower.

Indexes consume space.

Can always adjust during deployment.

Denormalization done sometimes (avoid).

29

OO Design

First step: review and refine use cases.

Decide:

Which classes to create

How are the classes related

Use UML as the design language.

30

Use Case Diagram

31

Class Design

Classes represent real-world entities or system concepts.

Organized into classes: objects in a class have similar characteristics.

Classes have properties (attributes or data).

Classes also have methods (perform functions).

32

UML Class Diagrams

Association

Composition

Use “no-fill” diamond for aggregation.

33

UML Class Diagrams – Inheritance

34

UML State Diagram

depicting a student’s “status” in school

35

UML “Sequence Diagram”

used to depict a flow of interactions

36

User Interface Design

Most apparent to the user

Two main issues:

Flow of interactions

ii) Look and feel

Types of interfaces

Command-line

Text menus

Graphical (GUI)

37

Flow of Interactions

Prototype screens

Registration:

Select term.

Registration: shows term.

Select first course.

Registration: shows term, course(s) with schedule and cost.

Select *Additional course; *Delete course; *Finish registration.

Registration: shows final schedule.

Select Confirm or Cancel.

38

High Fidelity Prototype

39

User: Screens: Process:

User Interaction Added to the Sequence Diagram

41

Norman’s 7 Stage Model

42

The GOMS Model (an “advanced” topic for UI)

Consider different kinds of users.

Four factors (for the kind of user)

Goals of the user

Operations provided by the system

Methods or the sequence of operations

Selection rules for the methods

43

Other UI Issues

Kinds of users

Heuristics

UI guidelines

Multicultural issues

Metaphors

Multiplatform software

Accessibility

Multimedia interfaces

44

HTML Script Simple Example

45

Model-View-Controller (MVC) Software Project

Model

SQL database

View HTML

Controller PHP

46

Object-Relational Impedance Mismatch (an “advanced” topic)

How do we handle mismatches between object-oriented concepts and relational DB such as:

Typing

Private and public

Inheritance and polymorphism

Nested structure versus table structure

47