CSC 305 Chapter 5-6

Structural models

Display the organization of a system in terms of the components that make up that system and their relationships. May be static (show the structure of system design) or dynamic (show the organization of the system when it is executing)

Process stages

Define the context and modes of use of the system Design the system architecture Identify the principal system objects Develop design models Specify Object interfaces

System context models

Demonstrates the other systems in the environment of the system being developed.

Design model - Dynamic model

Describe the dynamic interactions between objects.

Design model - Structural models

Describe the state structure of the system in terms of object classes and relationships

Implementation issues - Host-target development

Production software does not usually execute on the same computer as the software development environment.

Potential use for - Iterator

Provide a standard way of accessing the elements in a collection, irrespective of how that collection is implemented

Reuse levels - Abstraction

You don't reuse software directly but use knowledge of successful abstractions in the design of your software

Reuse levels - System

You reuse entire application systems

Architectural abstraction

(In the small) Concerned with the way that an individual program is decomposed into components. (In the large) Concerned with the architecture of complex enterprise systems including other systems, programs, and program components which may be distributed over different computers, owned and managed by different companies.

Software design

A creative activity in which you identify software components and their relationships, based on a customer's requirements.

Interaction model

A dynamic model that shows how the system interacts with its environments as it is used.

Open source development

An approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process. The best know open source product is the Linus operating system which is widely used as a server system and, increasingly, as a desktop environment

IDE

A set of software tools that supports different aspects of software development, within some common framework and user interface. Created to support development in a specific programming language. The language IDE may be developed specially, or may be an instantiation of a general-purpose IDE, with specific language-support tools

Architectural patterns

A stylized description of good design practice, which has been tried and tested in different environments Should include information about when they are/are not useful

Design patterns

A way of reusing abstract knowledge about a problem and its solution A description of the problem and the essence of its solution Should be sufficiently abstract to be reused in different settings Usually make use of object-oriented characteristics such as inheritance and polymorphism

Potential use for - Decorator pattern

Allow for the possibility of extending the functionality of an existing class at run-time

Advantages of model-drive engineering

Allows systems to be considered at higher levels of abstractions Generating code automatically means that it is cheaper to adapt systems to new platforms.

Model-driven engineering

An approach to software development where models rather than programs are the principal outputs of the development process. Programs that execute on a hard/software platform are then generated automatically from the models.

Development platform tools

An integrated compiler and syntax-directed editing system that allows you to create, edit and compile code A language debugging system Graphical editing tools, such as tools to edit UML models Testing tools such as Junit that can automatically run a set of tests on a new version of a program Project support tools that help you organize the code for different development project.

Class diagram properties

An object class can be thought of as a general definition of one kind of system object An association is a link between classes that indicates a relationship

Use of architectural models

As a way of facilitating discussion about the system design because it isn't cluttered with detail. As a way of documenting an architecture that has been designed

Open source business

Business model is not reliant on selling a software product but on selling support for that product. They believe that involving the open source community will allow software to be developed more cheaply, more quickly, and will create a community of users for the software.

Reuse levels - Component

Components are collections of objects and object classes that you reuse in application systems

Architectural design

Concerned with understanding how a software system should be organized and designing the overall structure of that system The critical link between design and requirements engineering

Types of stimuli

Data: some data arrives that has to be processes by the system. Events: Some even happens that triggers system processing. Events may have associate data, although it is not always the case.

Client-server architecture

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.

Implementation issues - Configuration management

During the development process, you have to keep track of the many different versions of each software component in a configuration management system

Use case modeling

Each use case represents a discrete task that involves external interaction with a system

System boundaries

Established to define what is inside and what is outside the system The position of the system boundary has a profound effect on the system requirements Defining a system boundary is a political judgment

Component/system deployment factors 2

High availability systems may require components to be deployed on more than one platform. This means that, in the event of platform failure, an alternative implementation of the component is available.

Model driven Architecture -Computation independent model

Model the important domain abstractions used in a system. Sometimes called domain models

Model driven Architecture - Platform independent model

Model the operation of the system without reference to its implementation. Usually described using UML models that show the static system structure and how it responds to external/internal events.

Interaction models

Modeling user interaction helps to identify user requirements, highlights communication problems that may arise

Disadvantages of model-drive engineering

Models for abstraction are not necessarily right for implementation Savings from generating code may be outweighed by the costs of developing translators for new platforms

Behavior models

Models of the dynamic behavior of a system as it is executing. Shows what happens or what is supposed to happen when a system responds to a stimulus from its environment.

Implementation issues - Reuse

Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code.

Host-target development

Most software is developed on one computer (the host), but runs on a separate machine (the target) A platform is more than just hardware, it includes the installed OS plus other supporting software such as a database management system or, for development platforms, an interactive development environment.

Design pattern elements

Name (A meaningful pattern identifier Problem description Solution description (Not a concrete design but a template for a design solution that can be instantiated in different ways) Consequences (The results and trade-offs of applying the pattern)

Interface specification

Object interfaces have to be specified so that the objects and other components can be designed in parallel You should avoid designing the interface representation but should hide this in the object itself.

Architectural Design

Once the interactions between the system and its environment have been understood: Identify the major components that make up the system and their interactions, then organize the components using an architectural pattern

Open source issues

Should the product that is being developed make use of open source components? Should an open source approach be used for the software's development?

State diagrams 2

Show how objects respond to different service requests and the state transitions triggered by these requests Useful as high-level models of a system or an objects run-time behavior

State-machine models

Show system states as nodes and events as arcs between these nodes. When an even occurs, the system moves from one state to another.

Data-driven models

Show the sequence of actions involved in processing input data and generating an associated output. Useful during the analysis of requirements as they can be used to show end-to-end processing in a a system.

Sequence model

Show the sequence of object interactions that take place Objects arranged horizontally across the top Time is represented vertically so models are read top to bottom Interactions are represented by labelling arrows, Different styles of arrow represent different types of interaction A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system.

Event-driven modeling

Shows how a system responds to external and internal events Based on the assumption that a system has a finite number of states and that stimuli may cause a transition from on state to another.

Aggregation models

Shows how classes that are collections are composed of other classes Similar to the part-of relationship in semantic data models

Subsystem models

Shows how the design is organized into logically related groups of objects In UML, shown using packages - an encapsulation construct. This is a logical model. The actual organization of the objects in the system may be different.

Architectural views - Development

Shows how the software is decomposed for development

State diagrams

Shows how the system reacts to internal and external events.

Architectural views - Process

Shows how, at run time, the system is composed of interacting processes

Activity diagram

Shows the activities involved in a process or in data processing.

Use case diagram

Shows the interactions between a system and its environment

Sequence diagram

Shows the interactions between actors and the system and between system components. Objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows.

Architectural views - Logical

Shows the key abstractions in the system as objects of object classes

Class diagrams

Shows the object classes in the system and the associates between the classes

Architectural views - Physical

Shows the system hardware and how software components are distributed across the processors in the system

Advantages of explicit architecture

Stakeholder communication - May be used as a focus of discussion by stakeholders System analysis - Means that analysis of whether the system can meet its non-functional requirements is possible Large-scale reuse - May be reusable across a range of systems. Product-line architectures may be developed.

Repository architecture

Sub-system must exchange data, which may be done 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.

Design model examples

Subsystem models that show logical groupings of objects into coherent subsystems Sequence models that show the sequence of object interactions State machine models that show how individual objects change their state in response to events Other models include use-case models, aggregation models, generalization models, etc.

Generalization

Technique used to manage complexity. Rather than learn detailed characteristic of entities, we learn characteristics of more general classes.

Potential use for - Observer pattern

Tell several objects that the state of some other object has changed

Software Design and Implementation

The stage in the software engineering process at which an executable software system is developed.

Model driven Architecture -Platform specific models

These are transformations of the platform-independent model with a separate PSM for each application platform. There may be layers of PSM, with each layer adding some platform specific detail.

Potential use for - Facade pattern

Tidy up the interfaces to a number of related objects that have often been developed incrementally

Aim of configuration management

To support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system.

Approaches to object identification

Use a grammatical approach based on a natural language description of the system. Base the identification on tangible things in the application domain Use a behavioral approach and identify objects based on what participates in what behavior Use a scenario based analysis. The objects, attributes and methods in each scenario are identified.

Models of a new system

Used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation.

Models of an existing system

Used during requirements engineering. Help to clarify what the existing system does and can be used as a basis for discussing strengths and weaknesses

Context models

Used to illustrate the operational context of a system - they show what lies outside the system boundaries Show the other systems in the environment, not how the system being developed is used in that environment

Layered architecture

Used to model the interfacing of sub-systems. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected

Configuration management activities - Problem tracking

Where support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed.

Configuration management activities - System integration

Where support is provided to help developers define what versions of components are used to create each version of a system. The description is then used to build a system automatically by compiling and linking the required components.

Configuration management activities - Version management

Where support is provided to keep track of the different versions of software components. Includes facilities to coordinate development by several programmers.

System perspectives - External

Where you model the context or environment of the system.

System perspectives - Behavioral

Where you model the dynamic behavior of the system and how it responds to events.

System perspectives - Interaction

Where you model the interactions between a system and its environment, or between the components of a system.

Reuse

Form 1960s to 1990s, most new software was developed from scratch, by writing all code in a high-level programming language Costs and schedule pressure means that this approach became increasingly unviable, especially for commercial and Internet based systems Based around the reuse of existing software emerged and is now generally used for business and scientific software

Component/system deployment factors 1

If a component is designed for a specific hardware architecture, or relies on some other software system, it must obviously be deployed on a platform that provides the required hardware and software support.

Component/system deployment factors 3

If there is a high level of communications traffic between components, it usually makes sense to deploy them on the same platform or on platforms that are physically close to one another. This reduces the delay between the time a message is sent by one component and received by another.

Object-oriented design process

Involve developing a number of different system models Require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost effective For large systems developed by different groups design models are an important communication mechanism

Architecture and system characteristics

Performance - Localize critical operations and minimize communications. Use large rather than fine-grain components. Security - Use a layered architecture with critical assets in the inner layers. Safety - Localize safety critical features in a small number of sub-systems Availability - Include redundant components and mechanism for fault tolerance. Maintainability - Use fine-grain, replaceable components.

Reuse costs

The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that your are developing The costs of integrating reusable software elements with each other

Configuration management

The general process of managing a changing software system

System modeling

The process of developing abstract models of a system, with each model presenting a different view or perspective of that system. Helps the analyst to understand the functionality of the system. Models used to communicate with customers.

Reuse levels - Object

You directly reuse objects from a library rather than writing the code yourself

System perspectives - Structural

Where you model the organization of a system or the structure of the data that is processed by the system

Open source licensing

While the source code is freely available, this does not mean that anyone can do as they wish with that code Legally, the developer of the code (either a company or an individual) still owns the code. They can place restrictions on how it is used by including legally binding conditions in an open source software license.