Chapter 2 software architecture
1 / 45

Chapter 2. Software architecture - PowerPoint PPT Presentation

Chapter 2. Software architecture Architecture style OOSE review Software architecture Layered architecture Architecture style System that share a similar high-level structure are said to have a similar architecture style

Related searches for Chapter 2. Software architecture

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Chapter 2. Software architecture ' - Albert_Lan

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 2 software architecture l.jpg

Chapter 2. Software architecture

Architecture style

OOSE review

Software architecture

Layered architecture

Architecture style l.jpg
Architecture style

  • System that share a similar high-level structure are said to have a similar architecture style

  • Approaching reuse without understanding architecture style is like starting to construct a building without knowing if it will be a skyscraper or a garage

  • Software of the same architecture style can be reused easier than those of different architecture styles

Architecture style3 l.jpg
Architecture style

  • An architecture style is defined by the type of constructs that can be reused to engineer a system

  • Definition: the architecture style of a system is the denotation of the modeling languages used when modeling that system

  • Example: UML (which is a modeling language) defines an architecture style

Oose review l.jpg
OOSE review

  • Software reuse in the text book is closely related to OOSE of I. Jacobson. Therefore, we review the OOSE in the following slides

  • Jacobson’s OOSE technique includes the following phases: analysis, construction, and testing

Analysis phase l.jpg
Analysis phase

  • Purposes of analysis:

    • To capture requirements

    • To represent requirements in models

  • Products of the analysis phase

    • Requirement model: to describe system functionality

    • Analysis model: to describe objects that accomplish system functionality

Analysis phase requirement model l.jpg
Analysis phase – requirement model

  • The requirement model describes system functionality

  • The model is composed of use case diagram, interface description, and domain objects

Analysis phase requirement model9 l.jpg
Analysis phase – requirement model

  • The use case diagram is composed of:

    • Actors

    • Use cases

    • Relationships among use cases

  • The interface description describe how the user can use the system.

  • The domain objects are objects identified in the problem domain

Analysis phase analysis model l.jpg
Analysis phase – analysis model

  • The analysis model is a robust model to adapt to change, which uses interface objects, entity objects, and control objects to describe system functionality

  • Creating analysis model corresponding to assigning functionality of use cases to objects (see figure in the next slide)

Analysis phase analysis model14 l.jpg
Analysis phase – analysis model

  • The following functionality should be allocated to interface objects

    • Those present information to actors or request information from actors

    • Those change when actors’ behavior change

    • Those depend on a particular interface type, e.g., changing card types results in changing the input device of the ATM machine

Analysis phase analysis model16 l.jpg
Analysis phase – analysis model

  • Entity objects model the information that a system will handle over a long time

  • Possible entity objects:

    • Those mapped to problem domain objects

    • The information that should be remembered

  • Operations of entity objects can be identified from use case functionality

Analysis phase analysis model17 l.jpg
Analysis phase – analysis model

  • Control objects are used to improve robustness of the analysis model

  • Behaviors that are sensitive to change can be allocated to control objects, e.g., workflow in a MIS

  • Behaviors that are not suitable for other objects can also be allocated to control objects

Analysis phase analysis model18 l.jpg
Analysis phase – analysis model

  • Use cases can be described by analysis objects as shown in the figure of the next slide

Construction phase l.jpg
Construction phase

  • Two models are developed in the construction phase, namely the design model and the implementation model

  • The implementation model is the program code

Construction phase design model l.jpg
Construction phase - design model

  • The design model is developed based on the analysis model; implementation environment is taken into consideration

  • The considered environment factors includes platform, language, DBMS, constraints, reusable components, libraries, and so on

Construction phase design model22 l.jpg
Construction phase -design model

  • Design objects in the design model are different from analysis objects

  • The design model also models design object interactions, design object interface, and design object semantics (i.e., algorithms of design objects’ operations)

Construction phase design model23 l.jpg
Construction phase - design model

  • In the design process, the analysis model is first transferred into the initial design model (figures in the next slides). Then, implementation environment factors are incorporated. For example, the “extend” relationship should be replaced by “invoke” relationship because no OO programming language supports the former

Slide27 l.jpg

Take a deep breath and

be ready for the other


Software architecture l.jpg
Software architecture

  • Software architecture defines system structures, interfaces, and interaction patterns

  • Example architectures: see the next slides

Slide32 l.jpg





Object-oriented architecture

Software architecture34 l.jpg
Software architecture

  • Definition: software architecture defines the static organization of software into subsystems interconnected through interfaces and defines at a significant level how nodes (sites) executing those software subsystems interact with each other.

Software architecture35 l.jpg
Software architecture

  • A good architecture facilitates controlling software complexity and allows large organizations to work on parts in parallel

  • An architecture should be robust. That is, it can be adapted to change (or change should be predicted)

  • A good architecture acts as a guide to which components should be reused during the development of application systems

Layered architecture l.jpg
Layered architecture

  • Before discussing layered architecture, we give some definitions below:

    • Software workproduct: a product or sub-product produced in a software engineering phase. For example, a subsystem of a design document can be regarded as a software workproduct

    • Asset: high-quality software workproductsthat can be reused

Layered architecture37 l.jpg
Layered architecture

  • Some definitions (cont.)

    • Component: an element of a development model (i.e., software) that is loosely coupled and promised to be reusable. Under this definition, all software workproducts are potentially components or sources of components.

    • Component system: a set of related components that accomplish some function larger than that accomplished by a single component. In other words, a component system is a larger component composed of components or component systems. Component systems thus facilitate large-scale reuse.

Layered architecture38 l.jpg
Layered architecture

  • Some definitions (cont.)

    • Facade: an aspect of a component system a reuser needs to know when he/she reuses the component system. A facade exports only those a reuser needed and encapsulates other details of a component system. (Take facade in mind, it is the primary concept in the text book).

Layered architecture39 l.jpg
Layered architecture

  • The sense behind the layered architecture:

    • Application systems can be built from component systems

    • Component systems may in turn be built from components in lower layers

  • The sense above results in a layered system defined by a layered architecture (see the figure in the next slide)

Slide40 l.jpg


System software

Layered architecture41 l.jpg
Layered architecture

  • Definition: a layered architecture is a software architecture that organizes software in layers. Each layer is built on top of another more general layer. A layer can loosely be defined as a set of (sub)systems with the same degree of generality. Upper layers are more application specific and lower are more general

Layered architecture42 l.jpg
Layered architecture

  • The number in a layered architecture may be varied from situation to situation. For example, the business-specific layer (see the figure in the slide before the previous slide) can be composed of more than one layer

Layered architecture43 l.jpg
Layered architecture

  • The topmost layer (application systems layer) contains application systems offering coherent set of use cases to end users. Some application systems may possess more than one version (or variant)

  • The business-specific layer contains a number of component systems specific to the type of business (i.e., specific to a problem domain). Such component systems include use case and object components. This layer is the focus of my presentation.

Layered architecture44 l.jpg
Layered architecture

  • The middleware layer offers components systems providing utility classes and platform-independent services such as distributed object computing in heterogeneous environments. Examples in this layer are GUI builders, DBMS interfaces, CORBA broker, and so on. This layer is the focus of your presentation

Layered architecture45 l.jpg
Layered architecture

  • The system software layer contains the software for the computing and networking infrastructure, such as OS, interfaces to specific hardware (i.e., drivers), sockets, and so on. Some components in this layer are hardware (or platform) dependent

  • Login