cs330
Chapter 4 Project UML
1.) UML – USE CASE
Elements
System: the software to be developed.
Represented as a rectangle with a name label at the top.
2) Actors: people or other external systems that interact with the system.
Represented as a stick figure with a name label.
Primary actors: who initiate actions appear to the left of the system
Secondary actors: who react to actions appear on the right of the system
All actors should be outside the system
3) Use cases: all possible operations the system can support users with.
Represented as ovals with name label inside.
4) Relationships: links that define how actors and cases are related to each other.
Represented as:
Solid line no arrows: actor to case
Sloid line with empty triangle head: actor to actor or case to case
Dashed-line with an angle arrow head: two types:
Include: base case must run included case always:
Extends: base case runs included case if conditions are detected:
5) Notes: annotations includes in a document shape.
E.g. can define conditions for some include case.
2) UML – CLASS STRUCTURE
1) Client – User: sub – super
2) Admin – User: sub – super
3) User – ATM: directed association User is not a structural part of ATM so cannot use aggregation.
4) User – FamilyCards: must exist in User Cannot exist by it self, so composition is used.
5) FamilyCards – Card: card is part of FamilyCards. It is Team – member relation so, aggregation. Card can exist by it self so it is NOT composition relation.
6) Transaction – ATM: transaction Cannot exist outside ATM it is part Of ATM software design so Composition is used.
7) ATM – Account: same as in ATM – User
8) ATM, Account – JUnitTestible: Interface realization
9) ATM – Bio: dependency
10) BioMetricV – Voice, Iris: nesting (source code inclusion)
11) Account-User: account aggregates one or more users
(Directed)Association vs. Dependency vs. Aggregation vs. Composition
Association is reference based (Field, state, attribute) relationship between two classes. Here a class A holds a class level reference to class B. Association can be represented by a line between these classes with an arrow indicating the navigation direction. In case arrow is on the both sides, association has bidirectional navigation.
Dependency is often confused as Association. Dependency is normally created when you receive a reference to a class as part of a particular operation / method. Dependency indicates that you may invoke one of the APIs of the received class reference and any modification to that class may break your class as well. Dependency is represented by a dashed arrow starting from the dependent class to its dependency. Multiplicity normally doesn’t make sense on a Dependency.
class Die { public void Roll() { … } }
class Player{
public void TakeTurn(Die die)
{ die.Roll(); … }}
Aggregation is same as association and is often seen as redundant relationship. A common perception is that aggregation represents one-to-many / many-to-many / part-whole relationships (i.e. higher multiplicity), which of course can be represented by via association too (hence the redundancy). As aggregation doesn’t convey anything more effective about a software design than an association, there is no separate UML representation for it (though some developers use a hollow diamond to indicate aggregation). You can give aggregation a miss unless you use it to convey something special.
class Asset { … }
class Player {
List assets;
public void AddAsset(Asset newlyPurchasedAsset) {
assets.Add(newlyPurchasedAssest); … }
…}
Composition relates to instance creational responsibility. When class B is composed by class A, class A instance owns the creation or controls lifetime of instance of class B. Needless to say when class instance A instance is destructed (garbage collected), class B instance would meet the same fate. Composition is usually indicated by line connecting two classes with addition of a solid diamond at end of the class who owns the creational responsibility. It’s also a perceived wrong notion that composition is implemented as nested classes. Composition binds lifetime of a specific instance for a given class, while class itself may be accessible by other parts of the system.
public class Piece { … }
public class Player{
//Player owns the responsibility of creating the Piece
Piece piece = new Piece();
Nesting: when a class includes another class as a code (an inner class) in its definition.
public class Employee{
private class PersonalInfo{
}
PersonalInfo info;
Public Employee(){
info = new PersonalInfo();
}
UML – SEQUENCE
Representing Life lines objects using Class Stereotypes:
Boundary: Typically user interface at the boundary of the system
Control: the logic, operation, algorithm of the process, controller, etc.
Entity: database, persistent storage, etc.
4) UML – ACTIVITY DIAGRAM
Chapter 5 System Modelling
System modeling
Developing abstract models of a system, with each model presenting a different view or perspective of that system.
Representing a system using graphical notation, which is now almost always based on UML.
Helps the analyst to understand the functionality of the system and models are used to communicate with system stakeholders: managers, developers, customers, etc.
Existing and planned system models
Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system.
Models of the new system are 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.
In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model.
System perspectives
An external perspective, where you model the context or environment of the system.
An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system.
A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system.
A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.
UML diagram types
Activity diagrams, which show the activities involved in a process or in data processing.
Use case diagrams, which show the interactions between a system and its environment.
Sequence diagrams, which show interactions between actors and the system and between system components.
Class diagrams, which show the object classes in the system and the associations between these classes.
State diagrams, which show how the system reacts to internal and external events.
Use of graphical models
As a means of facilitating discussion about an existing or proposed system
Incomplete and inaccurate models are OK as their role is to support discussion.
As a way of documenting an existing system
Models should be accurate representation of the system but need not be complete.
As a detailed system description that can be used to generate a system implementation
Models to be both accurate and complete.
Context models
Context models are used to illustrate the operational context of a system – they show what lies outside the system boundaries.
Social and organisational concerns may affect the decision on where to position system boundaries.
Architectural models show the system and its relationship with other systems.
System boundaries
System boundaries are established to define what is inside and what is outside the system.
They show other systems that are used or depend on the system being developed.
The position of the system boundary has a profound effect on the system requirements.
Political judgment may influence defining a system boundary
There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization.
Sub-view of ATM context model
}System modeling Limitations of context models
*Context models do not show the types of relationships between the systems in the environment and the system that is being specified.
*External systems might produce data for or consume data from the system.
*They might share data with the system
*They might be connected directly, through a network or not connected at all.
*They might be physically co-located or located in separate physical places.
Dataflow Models
Interaction models
Modeling user interaction is important as it helps to identify user requirements.
Modeling system-to-system interaction highlights the communication problems that may arise.
Modeling component interaction helps us understand:
If a proposed system structure is likely to deliver the required system performance and dependability.
Component to component Interfacing
Use case diagrams and sequence diagrams may be used for interaction modelling.
Use case modeling
Use cases were developed originally to support requirements elicitation and now incorporated into the UML.
Each use case represents a discrete task that involves external interaction with a system.
Actors in a use case may be people or other systems.
Represented diagrammatically to provide an overview of the use case and in a more detailed textual form.
Sequence diagrams
Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system.
A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.
Structural model
Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
Structural models may be static models, which show the structure of the system design, or dynamic models (later section = behavioral models), which show the organization of the system when it is executing.
Class diagrams
Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes.
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 that there is some relationship between these classes.
Generalization
*Generalization is an everyday technique that we use to manage complexity.
*Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes.
*This allows us to infer that different members of these classes have some common characteristics e.g. squirrels and rats are rodents.
*In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization. If changes are proposed, then you do not have to look at all classes in the system to see if they are affected by the change.
*In object-oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the language.
*In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes.
*The lower-level classes are subclasses inherit the attributes and operations from their superclasses. These lower-level classes then add more specific attributes and operations.
A generalization hierarchy
The aggregation association
Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus (data or event) from its environment:
You can think of these stimuli as being of two types:
Data Some data arrives that has to be processed by the system.
Events (typically real-time sys) Some event happens that triggers system processing. Events may have associated data, although this is not always the case.
Data e.g.: phone billing system will accept information about calls made by a customer, calculate the costs of these calls, and generate a bill for that customer.
Event e.g.: a landline phone switching system responds to events such as “handset activated” by generating a dial tone, pressing keys on a handset by capturing the phone number, and so on.
Data-driven modeling
Data-driven models show the sequence of actions involved in processing input data and generating an associated output.
They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system.
Data Flow model as UML activity diagram model of the insulin pump’s operation
Order processing
Alternative way to model sequence of processes in a system is UML sequence diagrams
Event-driven modeling
*Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone.
*Event-driven modeling shows how a system responds to external and internal events.
*It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.
State machine models
These model the behaviour of the system in response to external and internal events.
They show the system’s responses to stimuli so are often used for modelling real-time systems.
State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
Statecharts are an integral part of the UML and are used to represent state machine models.
State diagram of a microwave oven
Model-driven engineering
Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process.
The programs that execute on a hardware/software platform are then generated automatically from the models.
Usage of model-driven engineering
Pros
Allows systems to be considered at higher levels of abstraction
Generating code automatically means that it is cheaper to adapt systems to new platforms.
Cons
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. Meaning: the MDE must support translation for many programming languages to be able to translate a solution to a particular language.
Chapter 6 Architectural Design
Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system.
Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.
Agility and architecture
Refactoring the system architecture is usually expensive because it affects so many components in the system
The architecture of a packing robot control system
Architectural abstraction
Architecture in the small is concerned with the architecture of individual programs.
Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components.
Architecture is the dominant influence on the non-functional system characteristics: robustness, distributability, and maintainability.
Advantages of explicit architecture
Stakeholder communication
*Architecture may be used as a focus of discussion by system stakeholders.
System analysis
*Means that analysis of whether the system can meet its non-functional requirements is possible.
Large-scale reuse
*The architecture may be reusable across a range of systems
*Product-line architectures may be developed.
Box and line diagrams
*Very abstract – they do not show the nature of component relationships nor the externally visible properties of the sub-systems.
*However, useful for communication with stakeholders and for project planning.
Use of architectural models
As a way of facilitating discussion about the system design
A high-level architectural view of a system is useful for communication with system stakeholders and project planning because it is not cluttered with detail. Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail.
As a way of documenting an architecture that has been designed
The aim here is to produce a complete system model that shows the different components in a system, their interfaces and their connections.
Architectural design decisions
Architectural design is a creative process so the process differs depending on the type of system being developed.
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 mechanisms for fault tolerance.
Maintainability
Use fine-grain, replaceable components.
Safety: data/programs integrity, backups, checksums, etc all ensure that the data/programs is safe from failure
Security: protecting data/programs from unauthorized access.
Architectural views
4 + 1 view model of software architecture
A logical view, which shows the key abstractions in the system as objects or object classes. It should be possible to relate the system requirements to entities.
A process view, which shows how, at run-time, the system is composed of interacting processes. non-functional characteristics such as performance and availability.
A development view, which shows how the software is decomposed for development. breakdown of the software into components that are implemented by a single developer or development team. useful for software managers and programmers.
A physical view, which shows the system hardware and how software components are distributed across the processors in the system. Good for systems engineers planning a system deployment.
Scenarios (+1): use cases
Architectural patterns
*Patterns are a means of representing, sharing and reusing knowledge.
An architectural pattern is a stylized description of good design practice, which has been tried and tested in different systems and environments.
*Patterns should include information about when they are and when they are not useful – strengths and weaknesses
Architectural patterns The Model-View-Controller (MVC) pattern
The organization of the Model-View-Controller
Web application architecture using the MVC pattern
Simplified MVC
The Layered architecture pattern
A generic layered architecture
Architectural patterns: Repository architecture
Sub-systems must exchange data. This may be done in two ways:
Indirect (component<->repository): shared data is held in a central database or repository and may be accessed by all sub-systems;
Direct (component<->component): components/subsystem must operate around an agreed repository data model.
The Repository pattern
A repository architecture for an IDE
Architectural patterns: Client-serverarchitecture
Advantages
*The most important advantage of the client–server model is that it is a distributed architecture.
*It is easy to add a new server and integrate it with the rest of the system or
*to upgrade servers transparently without affecting other parts of the system
Architectural patterns: Pipe and filter architecture
Description: The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing.
When used: Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs.
Advantages: Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system.
Disadvantages: The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures.
An example of the pipe and filter architecture used in a payments system
Transaction vs. Batch processing:
Batch data processing: an efficient way of processing high volumes of data is where a group of transactions is collected over a period of time. Data is collected, entered, processed and then the batch results are produced. Batch processing requires separate programs for input, process and output. An example is payroll and billing systems. Transaction processing: is real time data processing involves a continual input, process and output of data. Data must be processed in a short time period (or near real time). Radar systems, customer services and bank ATMs are examples.
Chapter 7 Design and Implementation
Software design is a creative activity in which you identify:
Software components
Structure/organization
Relationships
Behaviors
Operations
Based on a customer’s requirements.
Implementation is the process of realizing the design as a program.
Make: build in-house
Buy: acquire from vendor
Lease: pay for service (as in cloud)
Make Buy Lease Factors
Intellectual property
Privacy
Security
Reliable expertise
Reliable capacity
Feasibility
*An object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state
*Object-oriented design processes involve designing object classes and the relationships between these classes. These classes define the objects in the system and their interactions.
*Changing the implementation of an object or adding services should not affect other system objects.
OOD Process stages
Common activities in these processes include:
Define the context and modes (use cases) of use of the system;
Design the system architecture;
Identify the principal system objects;
Develop design/system models (context, structural, interaction, behaviour …)
Specify object interfaces (methods).
A system context model is a structural model that demonstrates the other systems in the environment of the system being developed.
An interaction model is a dynamic model that shows how the system interacts with its environment as it is used.
System context for the weather station
Weather station use cases
High-level architecture of the weather station
Architecture of data collection subsystem
Approaches to identification
Use a grammatical approach based on a natural language description of the system.
Objects are nouns; operations/services are verbs
Base the identification on tangible things in the application domain.
Physical objects: aircraft, car, machine etc.
Roles: manager, accountant, engineer, receptionist, etc.
Events: request, archive, transaction, etc.
Interactions: meetings, call, response, etc.
Locations: offices, house, cabin etc.
Organizational units: companies, divisions, departments etc.
Use a behavioural approach and identify objects based on what participates in what behaviour.
Use a scenario-based analysis. The objects, attributes and methods in each scenario are identified.
Design models:
Design models show the objects and object classes and relationships between these entities.
There are two kinds of design model:
Structural models describe the static structure of the system in terms of object classes and relationships.
Dynamic models describe the dynamic interactions between objects.
Examples of useful design models
Structural: Subsystem models that show logical groupings of objects into coherent subsystems.
Dynamic: Sequence models that show the sequence of object interactions.
Dynamic: State machine models that show how individual objects change their state in response to events.
Other models include use-case models, aggregation models, generalisation models, etc.
Subsystem models
Shows how the design is organised into logically related groups of objects.
Sequence models show the sequence of object interactions that take place
*Objects are arranged horizontally across the top;
*Time is represented vertically so models are read top to bottom;
*Interactions are represented by labelled 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.
State diagrams:
State diagrams are used to show how objects respond to different service requests and the state transitions triggered by these requests.
State diagrams are useful high-level models of a system or an object’s run-time behavior.
Weather station state diagram:
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.
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.
Host-target development: Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system).
Reuse levels:
The abstraction level
At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software.
The object level
At this level, you directly reuse objects from a library rather than writing the code yourself.
The component level
Components are collections of objects and object classes that you reuse in application systems.
The system level
At this level, you reuse entire application systems.
Reuse costs:
*The costs of the time spent in looking for software to reuse and assessing/testing whether or not it meets your needs.
*Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high.
*The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing.
*The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed.
*Cost of evolution: in-house or vendor provided
Configuration Management activities
Version management: keep track of the different versions of software components.
*Coordinate development by several programmers.
System integration:
*Define versions of components are used to create each version of a system.
*This definition is then used to build a system automatically by compiling and linking the required components.
Problem tracking
*Report bugs and other problems
*Allow all developers to see who is working on these problems and when they are fixed.
Release management:
*Track new versions of a software system released to customers.
*Planning the functionality of new releases
*Organizing the of software for distribution.
Configuration management tool interaction (Arrows are bidirectional)
Host-target development:
Most software is developed on one computer (the host), but runs on a separate machine (the target).
A platform includes: hardware. operating system, compilers, database management system, development platforms.
Development platform usually has different installed software than execution platform; these platforms may have different architectures.
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 projects.
Target system simulator – if available
Component/system deployment factors:
*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.
*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.
*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 other. This reduces the delay between the time a message is sent by one component and received by another.
Open source development:
Open source development is 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.