Busy. Please wait.

show password
Forgot Password?

Don't have an account?  Sign up 

Username is available taken
show password


Make sure to remember your password. If you forget it there is no way for StudyStack to send you a reset link. You would need to create a new account.
We do not share your email address with others. It is only used to allow you to reset your password. For details read our Privacy Policy and Terms of Service.

Already a StudyStack user? Log In

Reset Password
Enter the associated with your account, and we'll email you a link to reset your password.

Remove ads
Don't know
remaining cards
To flip the current card, click it or press the Spacebar key.  To move the current card to one of the three colored boxes, click on the box.  You may also press the UP ARROW key to move the card to the "Know" box, the DOWN ARROW key to move the card to the "Don't know" box, or the RIGHT ARROW key to move the card to the Remaining box.  You may also click on the card displayed in any of the three boxes to bring that card back to the center.

Pass complete!

"Know" box contains:
Time elapsed:
restart all cards

Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.

  Normal Size     Small Size show me how

8) Design

Large System Development

System Design ◦ Decomposing the System ◦ Addressing Design Goals
There are two ways of constructing a software design, Sir Antony Hoare – One way is to make it so simple that there are obviously no deficiencies – The other way is to make it so complicated that there are no obvious deficiencies.
What is Architecture The highest-level breakdown of a system into its parts; the decisions that are hard to change; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is. Fowler
System architect 1) Handles the definition of the overall system and the sub- systems 2) External Architect
Object designer ◦ Handles the sub-system’s interfaces and the internal structures of the sub-systems ◦ Internal architect
Implementer ◦ Handles classes inside the sub-system
System Design Is ◦ Define the design goals of the project ◦ Decompose the system into smaller subsystems that can be realized by individual teams ◦ Select strategies for building the system
Select strategies for building the system " Hardware/software strategy " Persistent data management strategy " Global control flow strategy " Access control policy " Boundary conditions handling
The result of system design is a model that includes a subsystem decomposition and a clear description of each of the mentioned strategies
Analysis results in the requirements model products ◦ Nonfunctional requirements and constraints ◦ Use case model ◦ Object model ◦ Sequence diagram
System design results in the products ◦ Design goals ◦ Software architecture ◦ Boundary use cases
Object Design ”specifying the boundaries between objects” " Interfaces are defined in details
Design Goal Examples • Response time • Throughput • Robustness • Reliability • Availability • Scalability • Fault tolerance • Security • Extensibility • Modifiability • Portability • Recoverability • Traceability • Utility • Usability
System Design Concepts subsystem, service, coupling, cohesion, layering, partitioning
Subsystem a subsystem is a replaceable part of the system with well-defined interfaces that encapsulate the state and behavior of it contained classes
subsystem decomposition The division of the system into subsystems. Each subsystem is described in terms of its services during system design and its API during object design. Subsystem decomposition is part of the system design model.
Component Diagram In the Unified Modeling Language, a component diagram depicts how components are wired together to form larger components and or software systems. They are used to illustrate the structure of arbitrarily complex systems.
Partitions Partitions vertically divide a system into several independent (or weakly- coupled) subsystems that provide services on the same level of abstraction.
Layers A layer is a subsystem that provides subsystem services to a higher layers (level of abstraction)
Subsystem Heuristics (Abbott’s) ◦ Assign objects in one use case to the same subsystem ◦ dedicated subsystem for objects used for moving data among subsystems ◦ Minimize the number of associations crossing subsystems boundaries ◦ All objects in same subsystem funtionally related
Client/Server Architecture 1) Users interact only with the client 2) Client knows the interface of the server (its service)
MVC Architecture "attach multiple views to a model to provide different presentations" (view/model decoupling) "change the way a view responds to user input without changing its visual presentation" (view/controller decoupling)
3-tier Architecture a hierarchy of 3 layers usually called presentation, application and data layer
n-tier Architecture for example 4 tier has the interface broken down to 2 parts
Peer-to-Peer Architecture computing or networking is a distributed application architecture that partitions tasks or work loads between peers. Peers are equally privileged, equipotent participants in the application. They are said to form a peer-to-peer network of nodes.
Component-Based Architecture is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
Event-driven architecture is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
Communication Subsystem provides services for managing connections and functions.
System Design Activities 1) Map subsystems to hardware/software platforms 2) Manage persistent data 3) Define access control policies 4) Select Global control flow 5) Describe boundary conditions
Mapping Subsystems to Hardware ◦ How shall we realize the subsystems: Hardware or Software? ◦ How is the object model mapped on the chosen hardware & software? ◦ Mapping Objects onto Reality: Processor, Memory, Input/Output ◦ Mapping Associations onto Reality: Connectivity
Processor issues ◦ Is the computation rate too demanding for a single processor? ◦ Can we get a speedup by distributing tasks across several processors? ◦ How many processors are required to maintain steady state load?
Memory issues ◦ Is there enough memory to buffer bursts of requests?
I/O issues ◦ Do you need an extra piece of hardware to handle the data generation rate? ◦ Does the response time exceed the available communication bandwidth between subsystems or a task and a piece of hardware?
Designing Global Control Flow 1) Choose implicit control 2) Choose explicit control
Implicit Control (non-procedural, declarative languages) 1) Logic programming 2) Rule-based systems
Explicit Control (procedural languages) 1) Centralized 2) Decentralized
Centralized control 1) Procedure-driven 2) event- driven
Procedure-driven control ◦ Control resides within program code. Example: Main program calling procedures of subsystems. ◦ Simple, easy to build ◦ hard to maintain
Event-driven control ◦ Control resides within a dispatcher calling functions via callbacks. ◦ Very flexible, good for the design of graphical user interfaces, easy to extend ◦ Difficult to control overall flow
Identification of Services " Name the services meaningful " An interface specification of a subsystem defines the role the subsystem plays in cooperation with a specific other subsystem " NOT (operations and attributes)
Boundary Conditions 1) Initialization 2) Termination 3) Failure Create use cased for the user administrator to take care all user non-accounted administration tasks
Initialization The system is brought from a non-initialized state to steady-state
Termination Resources are cleaned up and other systems are notified upon termination
Failure Possible failures: Bugs, errors, external problems Good system design foresees fatal failures and provides mechanisms to deal with them.
Quality assurance of System Design 1) First: Does the System Design follow the design goals? 2) Correct, Complete, Consistent, Realistic, Readable
Sound Documentation from the Reader’sPointofView ! AvoidUnnecessaryRepetition ! AvoidAmbiguity ! ExplainYourNotation ! Use a Standard Organization ! Record Rationale ! Keep Documentation Current but Not Too Current ! Review Documentation for Fitness of Purpose
ATAM ArchitectureTradeoffAnalysisMethod: 1)identified risks early in the life cycle 2)increased communication among stakeholders 3)clarified quality attribute requirements 4)improved architectureDocumentation 5)documented basis for architectural decisions
CBAM Cost Benefit Analysis Method The CBAM enables users to make informed decisions about software requirements and software investments based on an analysis of the economic and architectural implications of those decisions.
Created by: timeakiss